diff --git a/main/0000-template-protocol/index.html b/main/0000-template-protocol/index.html
index c750f3498..1ad5e8427 100644
--- a/main/0000-template-protocol/index.html
+++ b/main/0000-template-protocol/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -992,7 +992,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -1013,7 +1013,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -1034,7 +1034,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -1055,7 +1055,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -1076,7 +1076,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -1097,7 +1097,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -1118,7 +1118,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -1139,7 +1139,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -1160,7 +1160,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -1181,7 +1181,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1202,7 +1202,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1223,7 +1223,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1244,7 +1244,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1265,7 +1265,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1286,7 +1286,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1307,7 +1307,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1328,7 +1328,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1349,7 +1349,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1370,7 +1370,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1391,7 +1391,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1412,7 +1412,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1454,7 +1454,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1475,7 +1475,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1517,7 +1517,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1538,7 +1538,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1559,7 +1559,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1601,7 +1601,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1622,7 +1622,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1643,7 +1643,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3548,6 +3548,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3716,6 +3737,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3758,6 +3800,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3773,6 +3836,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5148,7 +5253,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/0000-template/index.html b/main/0000-template/index.html
index b680116cd..a8bf27fb7 100644
--- a/main/0000-template/index.html
+++ b/main/0000-template/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -881,7 +881,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -902,7 +902,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -923,7 +923,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -944,7 +944,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -965,7 +965,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -986,7 +986,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -1007,7 +1007,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -1028,7 +1028,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -1049,7 +1049,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -1070,7 +1070,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1091,7 +1091,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1112,7 +1112,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1133,7 +1133,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1154,7 +1154,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1175,7 +1175,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1196,7 +1196,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1217,7 +1217,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1238,7 +1238,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1259,7 +1259,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1280,7 +1280,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1301,7 +1301,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1343,7 +1343,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1364,7 +1364,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1406,7 +1406,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1427,7 +1427,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1448,7 +1448,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1490,7 +1490,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1511,7 +1511,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1532,7 +1532,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3437,6 +3437,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3605,6 +3626,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3647,6 +3689,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3662,6 +3725,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4795,7 +4900,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/404.html b/main/404.html
index 9314f5519..462f031e5 100644
--- a/main/404.html
+++ b/main/404.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="/assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="/assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="/assets/stylesheets/palette.06af60db.min.css">
@@ -184,7 +184,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -402,7 +402,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -746,7 +746,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -767,7 +767,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -788,7 +788,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -809,7 +809,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -830,7 +830,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -851,7 +851,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -872,7 +872,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -893,7 +893,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -914,7 +914,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -935,7 +935,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -956,7 +956,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -977,7 +977,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -998,7 +998,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1019,7 +1019,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1040,7 +1040,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1061,7 +1061,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1082,7 +1082,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1103,7 +1103,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1124,7 +1124,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1145,7 +1145,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1166,7 +1166,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1208,7 +1208,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1229,7 +1229,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1271,7 +1271,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1292,7 +1292,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1313,7 +1313,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1355,7 +1355,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1376,7 +1376,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1397,7 +1397,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3302,6 +3302,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="/concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="/concepts/0559-pppu/" class="md-nav__link">
         
@@ -3470,6 +3491,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="/features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="/concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3512,6 +3554,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="/concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="/concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3527,6 +3590,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="/concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="/features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4416,7 +4521,7 @@ <h1>404 - Not found</h1>
     <script id="__config" type="application/json">{"base": "/", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "/assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="/assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="/assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/LICENSE/index.html b/main/LICENSE/index.html
index 14790c491..297aac3a4 100644
--- a/main/LICENSE/index.html
+++ b/main/LICENSE/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../assets/stylesheets/palette.06af60db.min.css">
@@ -188,7 +188,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -408,7 +408,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -763,7 +763,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -784,7 +784,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -805,7 +805,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -826,7 +826,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -847,7 +847,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -868,7 +868,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -889,7 +889,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -910,7 +910,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -931,7 +931,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -952,7 +952,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -973,7 +973,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -994,7 +994,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1015,7 +1015,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1036,7 +1036,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1057,7 +1057,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1078,7 +1078,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1099,7 +1099,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1120,7 +1120,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1141,7 +1141,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1162,7 +1162,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1183,7 +1183,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1225,7 +1225,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1246,7 +1246,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1288,7 +1288,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1309,7 +1309,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1330,7 +1330,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1372,7 +1372,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1393,7 +1393,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1414,7 +1414,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3319,6 +3319,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3487,6 +3508,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3529,6 +3571,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3544,6 +3607,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4682,7 +4787,7 @@ <h1>License</h1>
     <script id="__config" type="application/json">{"base": "..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/MAINTAINERS/index.html b/main/MAINTAINERS/index.html
index ba988fce2..c08953805 100644
--- a/main/MAINTAINERS/index.html
+++ b/main/MAINTAINERS/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -836,7 +836,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -857,7 +857,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -878,7 +878,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -899,7 +899,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -920,7 +920,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -941,7 +941,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -962,7 +962,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -983,7 +983,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -1004,7 +1004,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -1025,7 +1025,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1046,7 +1046,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1067,7 +1067,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1088,7 +1088,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1109,7 +1109,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1130,7 +1130,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1151,7 +1151,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1172,7 +1172,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1193,7 +1193,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1214,7 +1214,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1235,7 +1235,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1256,7 +1256,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1298,7 +1298,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1319,7 +1319,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1361,7 +1361,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1382,7 +1382,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1403,7 +1403,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1445,7 +1445,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1466,7 +1466,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1487,7 +1487,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3392,6 +3392,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3560,6 +3581,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3602,6 +3644,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3617,6 +3680,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4718,7 +4823,7 @@ <h2 id="removing-maintainers">Removing Maintainers<a class="headerlink" href="#r
     <script id="__config" type="application/json">{"base": "..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/RFCindex/index.html b/main/RFCindex/index.html
index 84bf441fa..1b66a4a79 100644
--- a/main/RFCindex/index.html
+++ b/main/RFCindex/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -854,7 +854,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -875,7 +875,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -896,7 +896,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -917,7 +917,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -938,7 +938,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -959,7 +959,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -980,7 +980,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -1001,7 +1001,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -1022,7 +1022,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -1043,7 +1043,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1064,7 +1064,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1085,7 +1085,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1106,7 +1106,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1127,7 +1127,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1148,7 +1148,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1169,7 +1169,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1190,7 +1190,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1211,7 +1211,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1232,7 +1232,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1253,7 +1253,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1274,7 +1274,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1316,7 +1316,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1337,7 +1337,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1379,7 +1379,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1400,7 +1400,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1421,7 +1421,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1463,7 +1463,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1484,7 +1484,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1505,7 +1505,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3410,6 +3410,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3578,6 +3599,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3620,6 +3662,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3635,6 +3698,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4790,7 +4895,7 @@ <h2 id="retired"><a href="../#retired">RETIRED</a><a class="headerlink" href="#r
     <script id="__config" type="application/json">{"base": "..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/SECURITY/index.html b/main/SECURITY/index.html
index 3ec84a418..a4356c639 100644
--- a/main/SECURITY/index.html
+++ b/main/SECURITY/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -809,7 +809,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -830,7 +830,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -851,7 +851,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -872,7 +872,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -893,7 +893,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -914,7 +914,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -935,7 +935,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -956,7 +956,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -977,7 +977,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -998,7 +998,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1019,7 +1019,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1040,7 +1040,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1061,7 +1061,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1082,7 +1082,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1103,7 +1103,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1124,7 +1124,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1145,7 +1145,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1166,7 +1166,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1187,7 +1187,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1208,7 +1208,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1229,7 +1229,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1271,7 +1271,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1292,7 +1292,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1334,7 +1334,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1355,7 +1355,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1376,7 +1376,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1418,7 +1418,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1439,7 +1439,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1460,7 +1460,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3365,6 +3365,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3533,6 +3554,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3575,6 +3617,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3590,6 +3653,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4528,13 +4633,13 @@ <h2 id="reporting-a-security-bug">Reporting a Security Bug<a class="headerlink"
         
         
           
-          <a href="../aip2/0003-protocols/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0003 Protocols">
+          <a href="../aip2/0003-protocols/" class="md-footer__link md-footer__link--next" aria-label="Next: 0003 Protocols">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0003 Protocols
+                0003 Protocols
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4571,7 +4676,7 @@ <h2 id="reporting-a-security-bug">Reporting a Security Bug<a class="headerlink"
     <script id="__config" type="application/json">{"base": "..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0003-protocols/index.html b/main/aip2/0003-protocols/index.html
index 4d5a40339..4175a3ded 100644
--- a/main/aip2/0003-protocols/index.html
+++ b/main/aip2/0003-protocols/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0003 Protocols - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0003 Protocols - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0003 Protocols
+              0003 Protocols
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -769,7 +769,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -780,7 +780,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -1100,7 +1100,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -1121,7 +1121,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -1142,7 +1142,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -1163,7 +1163,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -1184,7 +1184,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -1205,7 +1205,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -1226,7 +1226,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -1247,7 +1247,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -1268,7 +1268,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1289,7 +1289,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1310,7 +1310,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1331,7 +1331,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1352,7 +1352,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1373,7 +1373,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1394,7 +1394,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1415,7 +1415,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1436,7 +1436,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1457,7 +1457,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1478,7 +1478,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1499,7 +1499,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1541,7 +1541,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1562,7 +1562,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1604,7 +1604,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1625,7 +1625,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1646,7 +1646,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1688,7 +1688,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1709,7 +1709,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1730,7 +1730,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3635,6 +3635,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3803,6 +3824,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3845,6 +3887,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3860,6 +3923,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5693,13 +5798,13 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
         
         
           
-          <a href="../0004-agents/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0004 Agents">
+          <a href="../0004-agents/" class="md-footer__link md-footer__link--next" aria-label="Next: 0004 Agents">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0004 Agents
+                0004 Agents
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -5736,7 +5841,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0003-protocols/roles-participants-etc/index.html b/main/aip2/0003-protocols/roles-participants-etc/index.html
index dda5fd8b4..f7bdbf92b 100644
--- a/main/aip2/0003-protocols/roles-participants-etc/index.html
+++ b/main/aip2/0003-protocols/roles-participants-etc/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4519,7 +4624,7 @@ <h4 id="controllers">Controllers<a class="headerlink" href="#controllers" title=
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0003-protocols/tictactoe/index.html b/main/aip2/0003-protocols/tictactoe/index.html
index 5aea2bcfd..c5a8095bf 100644
--- a/main/aip2/0003-protocols/tictactoe/index.html
+++ b/main/aip2/0003-protocols/tictactoe/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4841,7 +4946,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0004-agents/index.html b/main/aip2/0004-agents/index.html
index 8869a02e1..e6084cd21 100644
--- a/main/aip2/0004-agents/index.html
+++ b/main/aip2/0004-agents/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0004 Agents - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0004 Agents - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0004 Agents
+              0004 Agents
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -790,7 +790,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -801,7 +801,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -887,7 +887,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -908,7 +908,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -929,7 +929,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -950,7 +950,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -971,7 +971,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -992,7 +992,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -1013,7 +1013,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -1034,7 +1034,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1055,7 +1055,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1076,7 +1076,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1097,7 +1097,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1118,7 +1118,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1139,7 +1139,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1160,7 +1160,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1181,7 +1181,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1202,7 +1202,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1223,7 +1223,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1244,7 +1244,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1265,7 +1265,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1307,7 +1307,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1328,7 +1328,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1370,7 +1370,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1391,7 +1391,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1412,7 +1412,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1454,7 +1454,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1475,7 +1475,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1496,7 +1496,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3401,6 +3401,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3569,6 +3590,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3611,6 +3653,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3626,6 +3689,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5004,7 +5109,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0003-protocols/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0003 Protocols">
+          <a href="../0003-protocols/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0003 Protocols">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -5014,20 +5119,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0003 Protocols
+                0003 Protocols
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0005-didcomm/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0005 DID Communication">
+          <a href="../0005-didcomm/" class="md-footer__link md-footer__link--next" aria-label="Next: 0005 DID Communication">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0005 DID Communication
+                0005 DID Communication
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -5064,7 +5169,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0005-didcomm/index.html b/main/aip2/0005-didcomm/index.html
index 8b13aba55..00a07972f 100644
--- a/main/aip2/0005-didcomm/index.html
+++ b/main/aip2/0005-didcomm/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0005 DID Communication - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0005 DID Communication - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0005 DID Communication
+              0005 DID Communication
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -811,7 +811,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -822,7 +822,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -932,7 +932,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -953,7 +953,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -974,7 +974,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -995,7 +995,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -1016,7 +1016,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -1037,7 +1037,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -1058,7 +1058,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1079,7 +1079,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1100,7 +1100,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1121,7 +1121,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1142,7 +1142,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1163,7 +1163,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1184,7 +1184,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1205,7 +1205,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1226,7 +1226,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1247,7 +1247,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1268,7 +1268,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1289,7 +1289,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1331,7 +1331,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1352,7 +1352,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1394,7 +1394,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1415,7 +1415,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1436,7 +1436,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1478,7 +1478,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1499,7 +1499,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1520,7 +1520,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3425,6 +3425,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3593,6 +3614,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3635,6 +3677,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3650,6 +3713,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4807,7 +4912,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0004-agents/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0004 Agents">
+          <a href="../0004-agents/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0004 Agents">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4817,20 +4922,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0004 Agents
+                0004 Agents
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0008-message-id-and-threading/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0008 Message ID and Threading">
+          <a href="../0008-message-id-and-threading/" class="md-footer__link md-footer__link--next" aria-label="Next: 0008 Message ID and Threading">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0008 Message ID and Threading
+                0008 Message ID and Threading
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4867,7 +4972,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0008-message-id-and-threading/index.html b/main/aip2/0008-message-id-and-threading/index.html
index 755cafd02..26b44258a 100644
--- a/main/aip2/0008-message-id-and-threading/index.html
+++ b/main/aip2/0008-message-id-and-threading/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0008 Message ID and Threading - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0008 Message ID and Threading - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0008 Message ID and Threading
+              0008 Message ID and Threading
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -832,7 +832,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -843,7 +843,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -989,7 +989,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -1010,7 +1010,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -1031,7 +1031,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -1052,7 +1052,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -1073,7 +1073,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -1094,7 +1094,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1115,7 +1115,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1136,7 +1136,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1157,7 +1157,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1178,7 +1178,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1199,7 +1199,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1220,7 +1220,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1241,7 +1241,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1262,7 +1262,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1283,7 +1283,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1304,7 +1304,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1325,7 +1325,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1367,7 +1367,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1388,7 +1388,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1430,7 +1430,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1451,7 +1451,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1472,7 +1472,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1514,7 +1514,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1535,7 +1535,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1556,7 +1556,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3461,6 +3461,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3629,6 +3650,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3671,6 +3713,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3686,6 +3749,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4910,7 +5015,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0005-didcomm/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0005 DID Communication">
+          <a href="../0005-didcomm/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0005 DID Communication">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4920,20 +5025,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0005 DID Communication
+                0005 DID Communication
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0011-decorators/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0011 Decorators">
+          <a href="../0011-decorators/" class="md-footer__link md-footer__link--next" aria-label="Next: 0011 Decorators">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0011 Decorators
+                0011 Decorators
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4970,7 +5075,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0011-decorators/index.html b/main/aip2/0011-decorators/index.html
index 79ac3fbbf..1e3becd7d 100644
--- a/main/aip2/0011-decorators/index.html
+++ b/main/aip2/0011-decorators/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0011 Decorators - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0011 Decorators - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0011 Decorators
+              0011 Decorators
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -853,7 +853,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -864,7 +864,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -992,7 +992,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -1013,7 +1013,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -1034,7 +1034,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -1055,7 +1055,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -1076,7 +1076,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1097,7 +1097,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1118,7 +1118,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1139,7 +1139,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1160,7 +1160,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1181,7 +1181,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1202,7 +1202,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1223,7 +1223,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1244,7 +1244,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1265,7 +1265,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1286,7 +1286,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1307,7 +1307,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1349,7 +1349,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1370,7 +1370,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1412,7 +1412,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1433,7 +1433,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1454,7 +1454,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1496,7 +1496,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1517,7 +1517,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1538,7 +1538,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3443,6 +3443,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3611,6 +3632,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3653,6 +3695,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3668,6 +3731,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4917,7 +5022,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0008-message-id-and-threading/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0008 Message ID and Threading">
+          <a href="../0008-message-id-and-threading/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0008 Message ID and Threading">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4927,20 +5032,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0008 Message ID and Threading
+                0008 Message ID and Threading
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0015-acks/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0015 ACKs">
+          <a href="../0015-acks/" class="md-footer__link md-footer__link--next" aria-label="Next: 0015 ACKs">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0015 ACKs
+                0015 ACKs
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4977,7 +5082,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0015-acks/index.html b/main/aip2/0015-acks/index.html
index eee5c7ecf..2ded00705 100644
--- a/main/aip2/0015-acks/index.html
+++ b/main/aip2/0015-acks/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0015 ACKs - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0015 ACKs - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0015 ACKs
+              0015 ACKs
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -874,7 +874,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -885,7 +885,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -1091,7 +1091,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -1112,7 +1112,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -1133,7 +1133,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -1154,7 +1154,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1175,7 +1175,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1196,7 +1196,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1217,7 +1217,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1238,7 +1238,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1259,7 +1259,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1280,7 +1280,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1301,7 +1301,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1322,7 +1322,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1343,7 +1343,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1364,7 +1364,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1385,7 +1385,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1427,7 +1427,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1448,7 +1448,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1490,7 +1490,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1511,7 +1511,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1532,7 +1532,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1574,7 +1574,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1595,7 +1595,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1616,7 +1616,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3521,6 +3521,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3689,6 +3710,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3731,6 +3773,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3746,6 +3809,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4978,7 +5083,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0011-decorators/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0011 Decorators">
+          <a href="../0011-decorators/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0011 Decorators">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4988,20 +5093,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0011 Decorators
+                0011 Decorators
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0017-attachments/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0017 Attachments">
+          <a href="../0017-attachments/" class="md-footer__link md-footer__link--next" aria-label="Next: 0017 Attachments">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0017 Attachments
+                0017 Attachments
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -5038,7 +5143,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0017-attachments/index.html b/main/aip2/0017-attachments/index.html
index 617c1e089..4eb29850d 100644
--- a/main/aip2/0017-attachments/index.html
+++ b/main/aip2/0017-attachments/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0017 Attachments - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0017 Attachments - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0017 Attachments
+              0017 Attachments
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -895,7 +895,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -906,7 +906,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -1094,7 +1094,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -1115,7 +1115,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -1136,7 +1136,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1157,7 +1157,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1178,7 +1178,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1199,7 +1199,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1220,7 +1220,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1241,7 +1241,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1262,7 +1262,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1283,7 +1283,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1304,7 +1304,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1325,7 +1325,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1346,7 +1346,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1367,7 +1367,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1409,7 +1409,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1430,7 +1430,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1472,7 +1472,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1493,7 +1493,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1514,7 +1514,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1556,7 +1556,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1577,7 +1577,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1598,7 +1598,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3503,6 +3503,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3671,6 +3692,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3713,6 +3755,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3728,6 +3791,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5218,7 +5323,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0015-acks/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0015 ACKs">
+          <a href="../0015-acks/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0015 ACKs">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -5228,20 +5333,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0015 ACKs
+                0015 ACKs
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0019-encryption-envelope/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0019 Encryption Envelope">
+          <a href="../0019-encryption-envelope/" class="md-footer__link md-footer__link--next" aria-label="Next: 0019 Encryption Envelope">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0019 Encryption Envelope
+                0019 Encryption Envelope
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -5278,7 +5383,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0019-encryption-envelope/index.html b/main/aip2/0019-encryption-envelope/index.html
index 50a24fa40..aa1a420f1 100644
--- a/main/aip2/0019-encryption-envelope/index.html
+++ b/main/aip2/0019-encryption-envelope/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0019 Encryption Envelope - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0019 Encryption Envelope - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0019 Encryption Envelope
+              0019 Encryption Envelope
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -916,7 +916,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -927,7 +927,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -977,7 +977,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -998,7 +998,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1019,7 +1019,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1040,7 +1040,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1061,7 +1061,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1082,7 +1082,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1103,7 +1103,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1124,7 +1124,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1145,7 +1145,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1166,7 +1166,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1187,7 +1187,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1208,7 +1208,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1229,7 +1229,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1271,7 +1271,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1292,7 +1292,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1334,7 +1334,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1355,7 +1355,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1376,7 +1376,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1418,7 +1418,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1439,7 +1439,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1460,7 +1460,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3365,6 +3365,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3533,6 +3554,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3575,6 +3617,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3590,6 +3653,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4853,7 +4958,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0017-attachments/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0017 Attachments">
+          <a href="../0017-attachments/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0017 Attachments">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4863,20 +4968,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0017 Attachments
+                0017 Attachments
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0020-message-types/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0020 Message Types">
+          <a href="../0020-message-types/" class="md-footer__link md-footer__link--next" aria-label="Next: 0020 Message Types">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0020 Message Types
+                0020 Message Types
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4913,7 +5018,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0019-encryption-envelope/schema/index.html b/main/aip2/0019-encryption-envelope/schema/index.html
index 6aa353564..d748cbe6b 100644
--- a/main/aip2/0019-encryption-envelope/schema/index.html
+++ b/main/aip2/0019-encryption-envelope/schema/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4509,7 +4614,7 @@ <h1 id="schema">Schema<a class="headerlink" href="#schema" title="Permanent link
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0020-message-types/index.html b/main/aip2/0020-message-types/index.html
index 8bf71fbdb..751e864d3 100644
--- a/main/aip2/0020-message-types/index.html
+++ b/main/aip2/0020-message-types/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0020 Message Types - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0020 Message Types - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0020 Message Types
+              0020 Message Types
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -937,7 +937,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -948,7 +948,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -1127,7 +1127,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1148,7 +1148,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1169,7 +1169,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1190,7 +1190,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1211,7 +1211,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1232,7 +1232,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1253,7 +1253,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1274,7 +1274,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1295,7 +1295,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1316,7 +1316,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1337,7 +1337,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1358,7 +1358,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1400,7 +1400,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1421,7 +1421,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1463,7 +1463,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1484,7 +1484,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1505,7 +1505,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1547,7 +1547,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1568,7 +1568,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1589,7 +1589,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3494,6 +3494,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3662,6 +3683,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3704,6 +3746,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3719,6 +3782,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4867,7 +4972,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0019-encryption-envelope/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0019 Encryption Envelope">
+          <a href="../0019-encryption-envelope/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0019 Encryption Envelope">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4877,20 +4982,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0019 Encryption Envelope
+                0019 Encryption Envelope
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0023-did-exchange/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0023 DID Exchange Protocol 1.0">
+          <a href="../0023-did-exchange/" class="md-footer__link md-footer__link--next" aria-label="Next: 0023 DID Exchange Protocol 1.0">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0023 DID Exchange Protocol 1.0
+                0023 DID Exchange Protocol 1.0
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4927,7 +5032,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0023-did-exchange/index.html b/main/aip2/0023-did-exchange/index.html
index ec279a349..6bad2170d 100644
--- a/main/aip2/0023-did-exchange/index.html
+++ b/main/aip2/0023-did-exchange/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0023 DID Exchange Protocol 1.0 - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0023 DID Exchange Protocol 1.0 - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0023 DID Exchange Protocol 1.0
+              0023 DID Exchange Protocol 1.0
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -958,7 +958,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -969,7 +969,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1223,7 +1223,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1244,7 +1244,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1265,7 +1265,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1286,7 +1286,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1307,7 +1307,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1328,7 +1328,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1349,7 +1349,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1370,7 +1370,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1391,7 +1391,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1412,7 +1412,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1433,7 +1433,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1475,7 +1475,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1496,7 +1496,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1538,7 +1538,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1559,7 +1559,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1580,7 +1580,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1622,7 +1622,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1643,7 +1643,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1664,7 +1664,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3569,6 +3569,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3737,6 +3758,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3779,6 +3821,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3794,6 +3857,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5253,7 +5358,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0020-message-types/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0020 Message Types">
+          <a href="../0020-message-types/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0020 Message Types">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -5263,20 +5368,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0020 Message Types
+                0020 Message Types
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0025-didcomm-transports/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0025 DIDComm Transports">
+          <a href="../0025-didcomm-transports/" class="md-footer__link md-footer__link--next" aria-label="Next: 0025 DIDComm Transports">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0025 DIDComm Transports
+                0025 DIDComm Transports
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -5313,7 +5418,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0025-didcomm-transports/index.html b/main/aip2/0025-didcomm-transports/index.html
index 96acf0fd5..ec51ee34d 100644
--- a/main/aip2/0025-didcomm-transports/index.html
+++ b/main/aip2/0025-didcomm-transports/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0025 DIDComm Transports - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0025 DIDComm Transports - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0025 DIDComm Transports
+              0025 DIDComm Transports
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -979,7 +979,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -990,7 +990,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1172,7 +1172,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1193,7 +1193,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1214,7 +1214,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1235,7 +1235,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1256,7 +1256,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1277,7 +1277,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1298,7 +1298,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1319,7 +1319,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1340,7 +1340,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1361,7 +1361,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1403,7 +1403,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1424,7 +1424,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1466,7 +1466,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1487,7 +1487,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1508,7 +1508,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1550,7 +1550,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1571,7 +1571,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1592,7 +1592,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3497,6 +3497,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3665,6 +3686,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3707,6 +3749,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3722,6 +3785,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4844,7 +4949,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0023-did-exchange/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0023 DID Exchange Protocol 1.0">
+          <a href="../0023-did-exchange/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0023 DID Exchange Protocol 1.0">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4854,20 +4959,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0023 DID Exchange Protocol 1.0
+                0023 DID Exchange Protocol 1.0
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0035-report-problem/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0035 Report Problem Protocol 1.0">
+          <a href="../0035-report-problem/" class="md-footer__link md-footer__link--next" aria-label="Next: 0035 Report Problem Protocol 1.0">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0035 Report Problem Protocol 1.0
+                0035 Report Problem Protocol 1.0
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4904,7 +5009,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0035-report-problem/index.html b/main/aip2/0035-report-problem/index.html
index f17af193b..f3911611c 100644
--- a/main/aip2/0035-report-problem/index.html
+++ b/main/aip2/0035-report-problem/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0035 Report Problem Protocol 1.0 - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0035 Report Problem Protocol 1.0 - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0035 Report Problem Protocol 1.0
+              0035 Report Problem Protocol 1.0
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1000,7 +1000,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1011,7 +1011,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1271,7 +1271,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1292,7 +1292,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1313,7 +1313,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1334,7 +1334,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1355,7 +1355,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1376,7 +1376,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1397,7 +1397,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1418,7 +1418,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1439,7 +1439,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1481,7 +1481,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1502,7 +1502,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1544,7 +1544,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1565,7 +1565,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1586,7 +1586,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1628,7 +1628,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1649,7 +1649,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1670,7 +1670,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3575,6 +3575,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3743,6 +3764,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3785,6 +3827,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3800,6 +3863,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5233,7 +5338,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0025-didcomm-transports/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0025 DIDComm Transports">
+          <a href="../0025-didcomm-transports/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0025 DIDComm Transports">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -5243,20 +5348,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0025 DIDComm Transports
+                0025 DIDComm Transports
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0044-didcomm-file-and-mime-types/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0044 DIDComm File and MIME Types">
+          <a href="../0044-didcomm-file-and-mime-types/" class="md-footer__link md-footer__link--next" aria-label="Next: 0044 DIDComm File and MIME Types">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0044 DIDComm File and MIME Types
+                0044 DIDComm File and MIME Types
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -5293,7 +5398,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0044-didcomm-file-and-mime-types/index.html b/main/aip2/0044-didcomm-file-and-mime-types/index.html
index 9cd42fef1..c856af6f6 100644
--- a/main/aip2/0044-didcomm-file-and-mime-types/index.html
+++ b/main/aip2/0044-didcomm-file-and-mime-types/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0044 DIDComm File and MIME Types - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0044 DIDComm File and MIME Types - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0044 DIDComm File and MIME Types
+              0044 DIDComm File and MIME Types
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1021,7 +1021,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1032,7 +1032,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1205,7 +1205,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1226,7 +1226,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1247,7 +1247,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1268,7 +1268,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1289,7 +1289,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1310,7 +1310,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1331,7 +1331,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1352,7 +1352,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1394,7 +1394,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1415,7 +1415,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1457,7 +1457,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1478,7 +1478,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1499,7 +1499,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1541,7 +1541,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1562,7 +1562,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1583,7 +1583,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3488,6 +3488,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3656,6 +3677,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3698,6 +3740,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3713,6 +3776,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4961,7 +5066,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0035-report-problem/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0035 Report Problem Protocol 1.0">
+          <a href="../0035-report-problem/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0035 Report Problem Protocol 1.0">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4971,20 +5076,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0035 Report Problem Protocol 1.0
+                0035 Report Problem Protocol 1.0
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0046-mediators-and-relays/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0046 Mediators and Relays">
+          <a href="../0046-mediators-and-relays/" class="md-footer__link md-footer__link--next" aria-label="Next: 0046 Mediators and Relays">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0046 Mediators and Relays
+                0046 Mediators and Relays
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -5021,7 +5126,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0046-mediators-and-relays/index.html b/main/aip2/0046-mediators-and-relays/index.html
index 6a8bcb179..cc79e996c 100644
--- a/main/aip2/0046-mediators-and-relays/index.html
+++ b/main/aip2/0046-mediators-and-relays/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0046 Mediators and Relays - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0046 Mediators and Relays - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0046 Mediators and Relays
+              0046 Mediators and Relays
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1042,7 +1042,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1053,7 +1053,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1163,7 +1163,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1184,7 +1184,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1205,7 +1205,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1226,7 +1226,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1247,7 +1247,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1268,7 +1268,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1289,7 +1289,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1331,7 +1331,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1352,7 +1352,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1394,7 +1394,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1415,7 +1415,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1436,7 +1436,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1478,7 +1478,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1499,7 +1499,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1520,7 +1520,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3425,6 +3425,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3593,6 +3614,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3635,6 +3677,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3650,6 +3713,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4818,7 +4923,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0044-didcomm-file-and-mime-types/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0044 DIDComm File and MIME Types">
+          <a href="../0044-didcomm-file-and-mime-types/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0044 DIDComm File and MIME Types">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4828,20 +4933,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0044 DIDComm File and MIME Types
+                0044 DIDComm File and MIME Types
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0047-json-ld-compatibility/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0047 JSON-LD Compatibility">
+          <a href="../0047-json-ld-compatibility/" class="md-footer__link md-footer__link--next" aria-label="Next: 0047 JSON-LD Compatibility">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0047 JSON-LD Compatibility
+                0047 JSON-LD Compatibility
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4878,7 +4983,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0047-json-ld-compatibility/index.html b/main/aip2/0047-json-ld-compatibility/index.html
index 91e564f70..776363221 100644
--- a/main/aip2/0047-json-ld-compatibility/index.html
+++ b/main/aip2/0047-json-ld-compatibility/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0047 JSON-LD Compatibility - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0047 JSON-LD Compatibility - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0047 JSON-LD Compatibility
+              0047 JSON-LD Compatibility
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1063,7 +1063,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1074,7 +1074,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1211,7 +1211,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1232,7 +1232,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1253,7 +1253,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1274,7 +1274,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1295,7 +1295,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1316,7 +1316,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1358,7 +1358,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1379,7 +1379,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1421,7 +1421,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1442,7 +1442,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1463,7 +1463,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1505,7 +1505,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1526,7 +1526,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1547,7 +1547,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3452,6 +3452,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3620,6 +3641,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3662,6 +3704,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3677,6 +3740,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4897,7 +5002,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0046-mediators-and-relays/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0046 Mediators and Relays">
+          <a href="../0046-mediators-and-relays/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0046 Mediators and Relays">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4907,20 +5012,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0046 Mediators and Relays
+                0046 Mediators and Relays
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0048-trust-ping/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0048 Trust Ping Protocol 1.0">
+          <a href="../0048-trust-ping/" class="md-footer__link md-footer__link--next" aria-label="Next: 0048 Trust Ping Protocol 1.0">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0048 Trust Ping Protocol 1.0
+                0048 Trust Ping Protocol 1.0
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4957,7 +5062,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0048-trust-ping/index.html b/main/aip2/0048-trust-ping/index.html
index aa322fce2..ee09b993a 100644
--- a/main/aip2/0048-trust-ping/index.html
+++ b/main/aip2/0048-trust-ping/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0048 Trust Ping Protocol 1.0 - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0048 Trust Ping Protocol 1.0 - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0048 Trust Ping Protocol 1.0
+              0048 Trust Ping Protocol 1.0
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1084,7 +1084,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1095,7 +1095,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1205,7 +1205,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1226,7 +1226,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1247,7 +1247,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1268,7 +1268,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1289,7 +1289,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1331,7 +1331,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1352,7 +1352,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1394,7 +1394,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1415,7 +1415,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1436,7 +1436,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1478,7 +1478,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1499,7 +1499,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1520,7 +1520,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3425,6 +3425,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3593,6 +3614,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3635,6 +3677,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3650,6 +3713,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4754,7 +4859,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0047-json-ld-compatibility/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0047 JSON-LD Compatibility">
+          <a href="../0047-json-ld-compatibility/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0047 JSON-LD Compatibility">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4764,20 +4869,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0047 JSON-LD Compatibility
+                0047 JSON-LD Compatibility
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0050-wallets/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0050 Wallets">
+          <a href="../0050-wallets/" class="md-footer__link md-footer__link--next" aria-label="Next: 0050 Wallets">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0050 Wallets
+                0050 Wallets
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4814,7 +4919,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0050-wallets/index.html b/main/aip2/0050-wallets/index.html
index c5ddc0d0f..fde7f7bf1 100644
--- a/main/aip2/0050-wallets/index.html
+++ b/main/aip2/0050-wallets/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0050 Wallets - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0050 Wallets - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0050 Wallets
+              0050 Wallets
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1075,7 +1075,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1105,7 +1105,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1116,7 +1116,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1361,7 +1361,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1382,7 +1382,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1403,7 +1403,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1424,7 +1424,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1466,7 +1466,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1487,7 +1487,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1529,7 +1529,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1550,7 +1550,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1571,7 +1571,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1613,7 +1613,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1634,7 +1634,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1655,7 +1655,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3560,6 +3560,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3728,6 +3749,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3770,6 +3812,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3785,6 +3848,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5267,7 +5372,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0048-trust-ping/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0048 Trust Ping Protocol 1.0">
+          <a href="../0048-trust-ping/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0048 Trust Ping Protocol 1.0">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -5277,20 +5382,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0048 Trust Ping Protocol 1.0
+                0048 Trust Ping Protocol 1.0
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0092-transport-return-route/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0092 Transports Return Route">
+          <a href="../0092-transport-return-route/" class="md-footer__link md-footer__link--next" aria-label="Next: 0092 Transports Return Route">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0092 Transports Return Route
+                0092 Transports Return Route
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -5327,7 +5432,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0092-transport-return-route/index.html b/main/aip2/0092-transport-return-route/index.html
index 9ead17f03..d260a1abe 100644
--- a/main/aip2/0092-transport-return-route/index.html
+++ b/main/aip2/0092-transport-return-route/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0092 Transports Return Route - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0092 Transports Return Route - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0092 Transports Return Route
+              0092 Transports Return Route
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1075,7 +1075,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1096,7 +1096,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1126,7 +1126,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1137,7 +1137,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1250,7 +1250,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1271,7 +1271,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1292,7 +1292,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1334,7 +1334,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1355,7 +1355,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1397,7 +1397,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1418,7 +1418,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1439,7 +1439,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1481,7 +1481,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1502,7 +1502,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1523,7 +1523,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3428,6 +3428,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3596,6 +3617,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3638,6 +3680,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3653,6 +3716,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4686,7 +4791,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0050-wallets/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0050 Wallets">
+          <a href="../0050-wallets/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0050 Wallets">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4696,20 +4801,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0050 Wallets
+                0050 Wallets
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0094-cross-domain-messaging/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0094 Cross-Domain Messaging">
+          <a href="../0094-cross-domain-messaging/" class="md-footer__link md-footer__link--next" aria-label="Next: 0094 Cross-Domain Messaging">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0094 Cross-Domain Messaging
+                0094 Cross-Domain Messaging
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4746,7 +4851,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0094-cross-domain-messaging/index.html b/main/aip2/0094-cross-domain-messaging/index.html
index 654e84443..82f8b2690 100644
--- a/main/aip2/0094-cross-domain-messaging/index.html
+++ b/main/aip2/0094-cross-domain-messaging/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0094 Cross-Domain Messaging - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0094 Cross-Domain Messaging - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0094 Cross-Domain Messaging
+              0094 Cross-Domain Messaging
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1075,7 +1075,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1096,7 +1096,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1117,7 +1117,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1147,7 +1147,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1158,7 +1158,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1373,7 +1373,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1394,7 +1394,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1436,7 +1436,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1457,7 +1457,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1499,7 +1499,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1520,7 +1520,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1541,7 +1541,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1583,7 +1583,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1604,7 +1604,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1625,7 +1625,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3530,6 +3530,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3698,6 +3719,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3740,6 +3782,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3755,6 +3818,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5061,7 +5166,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0092-transport-return-route/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0092 Transports Return Route">
+          <a href="../0092-transport-return-route/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0092 Transports Return Route">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -5071,20 +5176,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0092 Transports Return Route
+                0092 Transports Return Route
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0095-basic-message/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0095 Basic Message Protocol 1.0">
+          <a href="../0095-basic-message/" class="md-footer__link md-footer__link--next" aria-label="Next: 0095 Basic Message Protocol 1.0">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0095 Basic Message Protocol 1.0
+                0095 Basic Message Protocol 1.0
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -5121,7 +5226,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0095-basic-message/index.html b/main/aip2/0095-basic-message/index.html
index 516c2343f..90700f3ab 100644
--- a/main/aip2/0095-basic-message/index.html
+++ b/main/aip2/0095-basic-message/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0095 Basic Message Protocol 1.0 - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0095 Basic Message Protocol 1.0 - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0095 Basic Message Protocol 1.0
+              0095 Basic Message Protocol 1.0
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1075,7 +1075,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1096,7 +1096,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1117,7 +1117,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1138,7 +1138,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1168,7 +1168,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1179,7 +1179,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1301,7 +1301,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1343,7 +1343,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1364,7 +1364,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1406,7 +1406,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1427,7 +1427,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1448,7 +1448,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1490,7 +1490,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1511,7 +1511,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1532,7 +1532,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3437,6 +3437,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3605,6 +3626,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3647,6 +3689,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3662,6 +3725,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4735,7 +4840,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0094-cross-domain-messaging/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0094 Cross-Domain Messaging">
+          <a href="../0094-cross-domain-messaging/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0094 Cross-Domain Messaging">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4745,20 +4850,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0094 Cross-Domain Messaging
+                0094 Cross-Domain Messaging
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0183-revocation-notification/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0183 Revocation Notification 1.0">
+          <a href="../0183-revocation-notification/" class="md-footer__link md-footer__link--next" aria-label="Next: 0183 Revocation Notification 1.0">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0183 Revocation Notification 1.0
+                0183 Revocation Notification 1.0
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4795,7 +4900,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0183-revocation-notification/index.html b/main/aip2/0183-revocation-notification/index.html
index 54cca6401..a4158ea6b 100644
--- a/main/aip2/0183-revocation-notification/index.html
+++ b/main/aip2/0183-revocation-notification/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0183 Revocation Notification 1.0 - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0183 Revocation Notification 1.0 - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0183 Revocation Notification 1.0
+              0183 Revocation Notification 1.0
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1075,7 +1075,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1096,7 +1096,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1117,7 +1117,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1138,7 +1138,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1159,7 +1159,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1189,7 +1189,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1200,7 +1200,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1367,7 +1367,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1388,7 +1388,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1430,7 +1430,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1451,7 +1451,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1472,7 +1472,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1514,7 +1514,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1535,7 +1535,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1556,7 +1556,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3461,6 +3461,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3629,6 +3650,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3671,6 +3713,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3686,6 +3749,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4767,7 +4872,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0095-basic-message/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0095 Basic Message Protocol 1.0">
+          <a href="../0095-basic-message/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0095 Basic Message Protocol 1.0">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4777,7 +4882,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0095 Basic Message Protocol 1.0
+                0095 Basic Message Protocol 1.0
               </div>
             </div>
           </a>
@@ -4827,7 +4932,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0211-route-coordination/index.html b/main/aip2/0211-route-coordination/index.html
index a8da6bdd6..a798d8e9b 100644
--- a/main/aip2/0211-route-coordination/index.html
+++ b/main/aip2/0211-route-coordination/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1075,7 +1075,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1096,7 +1096,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1117,7 +1117,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1138,7 +1138,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1159,7 +1159,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1180,7 +1180,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1445,7 +1445,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1466,7 +1466,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1508,7 +1508,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1529,7 +1529,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1550,7 +1550,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1592,7 +1592,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1613,7 +1613,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1634,7 +1634,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3539,6 +3539,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3707,6 +3728,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3749,6 +3791,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3764,6 +3827,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5000,7 +5105,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0183-revocation-notification/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0183 Revocation Notification 1.0">
+          <a href="../0183-revocation-notification/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0183 Revocation Notification 1.0">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -5010,20 +5115,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0183 Revocation Notification 1.0
+                0183 Revocation Notification 1.0
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0360-use-did-key/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0360 did:key Usage">
+          <a href="../0360-use-did-key/" class="md-footer__link md-footer__link--next" aria-label="Next: 0360 did:key Usage">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0360 did:key Usage
+                0360 did:key Usage
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -5060,7 +5165,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0360-use-did-key/index.html b/main/aip2/0360-use-did-key/index.html
index 9d45403fe..05a70fffa 100644
--- a/main/aip2/0360-use-did-key/index.html
+++ b/main/aip2/0360-use-did-key/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0360 did:key Usage - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0360 did:key Usage - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0360 did:key Usage
+              0360 did:key Usage
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1075,7 +1075,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1096,7 +1096,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1117,7 +1117,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1138,7 +1138,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1159,7 +1159,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1180,7 +1180,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1231,7 +1231,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1242,7 +1242,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1364,7 +1364,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1406,7 +1406,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1427,7 +1427,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1448,7 +1448,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1490,7 +1490,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1511,7 +1511,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1532,7 +1532,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3437,6 +3437,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3605,6 +3626,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3647,6 +3689,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3662,6 +3725,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4752,13 +4857,13 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
         
         
           
-          <a href="../0434-outofband/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0434 Out-of-Band Protocol 1.1">
+          <a href="../0434-outofband/" class="md-footer__link md-footer__link--next" aria-label="Next: 0434 Out-of-Band Protocol 1.1">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0434 Out-of-Band Protocol 1.1
+                0434 Out-of-Band Protocol 1.1
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4795,7 +4900,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0434-outofband/index.html b/main/aip2/0434-outofband/index.html
index 5249131b8..5522983aa 100644
--- a/main/aip2/0434-outofband/index.html
+++ b/main/aip2/0434-outofband/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0434 Out-of-Band Protocol 1.1 - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0434 Out-of-Band Protocol 1.1 - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0434 Out-of-Band Protocol 1.1
+              0434 Out-of-Band Protocol 1.1
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1075,7 +1075,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1096,7 +1096,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1117,7 +1117,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1138,7 +1138,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1159,7 +1159,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1180,7 +1180,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1222,7 +1222,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1252,7 +1252,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1263,7 +1263,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1595,7 +1595,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1616,7 +1616,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1637,7 +1637,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1679,7 +1679,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1700,7 +1700,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1721,7 +1721,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3626,6 +3626,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3794,6 +3815,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3836,6 +3878,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3851,6 +3914,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5480,7 +5585,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0360-use-did-key/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0360 did:key Usage">
+          <a href="../0360-use-did-key/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0360 did:key Usage">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -5490,7 +5595,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0360 did:key Usage
+                0360 did:key Usage
               </div>
             </div>
           </a>
@@ -5540,7 +5645,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0441-present-proof-best-practices/index.html b/main/aip2/0441-present-proof-best-practices/index.html
index 68e451cc3..e0973925e 100644
--- a/main/aip2/0441-present-proof-best-practices/index.html
+++ b/main/aip2/0441-present-proof-best-practices/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1075,7 +1075,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1096,7 +1096,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1117,7 +1117,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1138,7 +1138,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1159,7 +1159,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1180,7 +1180,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1222,7 +1222,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1243,7 +1243,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1412,7 +1412,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1433,7 +1433,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1454,7 +1454,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1496,7 +1496,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1517,7 +1517,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1538,7 +1538,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3443,6 +3443,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3611,6 +3632,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3653,6 +3695,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3668,6 +3731,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4776,7 +4881,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0434-outofband/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0434 Out-of-Band Protocol 1.1">
+          <a href="../0434-outofband/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0434 Out-of-Band Protocol 1.1">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4786,20 +4891,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0434 Out-of-Band Protocol 1.1
+                0434 Out-of-Band Protocol 1.1
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0453-issue-credential-v2/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0453 Issue Credential Protocol 2.0">
+          <a href="../0453-issue-credential-v2/" class="md-footer__link md-footer__link--next" aria-label="Next: 0453 Issue Credential Protocol 2.0">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0453 Issue Credential Protocol 2.0
+                0453 Issue Credential Protocol 2.0
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4836,7 +4941,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0453-issue-credential-v2/index.html b/main/aip2/0453-issue-credential-v2/index.html
index f3b84c689..0446dd85a 100644
--- a/main/aip2/0453-issue-credential-v2/index.html
+++ b/main/aip2/0453-issue-credential-v2/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0453 Issue Credential Protocol 2.0 - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0453 Issue Credential Protocol 2.0 - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0453 Issue Credential Protocol 2.0
+              0453 Issue Credential Protocol 2.0
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1075,7 +1075,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1096,7 +1096,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1117,7 +1117,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1138,7 +1138,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1159,7 +1159,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1180,7 +1180,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1222,7 +1222,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1243,7 +1243,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1294,7 +1294,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1305,7 +1305,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1526,7 +1526,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1547,7 +1547,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1589,7 +1589,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1610,7 +1610,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1631,7 +1631,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3536,6 +3536,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3704,6 +3725,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3746,6 +3788,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3761,6 +3824,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5312,13 +5417,13 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
         
         
           
-          <a href="../0454-present-proof-v2/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0454 Present Proof Protocol 2.0">
+          <a href="../0454-present-proof-v2/" class="md-footer__link md-footer__link--next" aria-label="Next: 0454 Present Proof Protocol 2.0">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0454 Present Proof Protocol 2.0
+                0454 Present Proof Protocol 2.0
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -5355,7 +5460,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0454-present-proof-v2/index.html b/main/aip2/0454-present-proof-v2/index.html
index 75991de0e..988cc1d54 100644
--- a/main/aip2/0454-present-proof-v2/index.html
+++ b/main/aip2/0454-present-proof-v2/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0454 Present Proof Protocol 2.0 - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0454 Present Proof Protocol 2.0 - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0454 Present Proof Protocol 2.0
+              0454 Present Proof Protocol 2.0
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1075,7 +1075,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1096,7 +1096,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1117,7 +1117,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1138,7 +1138,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1159,7 +1159,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1180,7 +1180,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1222,7 +1222,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1243,7 +1243,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1285,7 +1285,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1315,7 +1315,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1326,7 +1326,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1592,7 +1592,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1634,7 +1634,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1655,7 +1655,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1676,7 +1676,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3581,6 +3581,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3749,6 +3770,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3791,6 +3833,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3806,6 +3869,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5252,7 +5357,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0453-issue-credential-v2/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0453 Issue Credential Protocol 2.0">
+          <a href="../0453-issue-credential-v2/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0453 Issue Credential Protocol 2.0">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -5262,20 +5367,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0453 Issue Credential Protocol 2.0
+                0453 Issue Credential Protocol 2.0
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0510-dif-pres-exch-attach/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs">
+          <a href="../0510-dif-pres-exch-attach/" class="md-footer__link md-footer__link--next" aria-label="Next: 0510 Presentation-Exchange Attachment format for requesting and presenting proofs">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+                0510 Presentation-Exchange Attachment format for requesting and presenting proofs
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -5312,7 +5417,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0510-dif-pres-exch-attach/index.html b/main/aip2/0510-dif-pres-exch-attach/index.html
index df9d46539..ed5a81e50 100644
--- a/main/aip2/0510-dif-pres-exch-attach/index.html
+++ b/main/aip2/0510-dif-pres-exch-attach/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0510 Presentation-Exchange Attachment format for requesting and presenting proofs - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+              0510 Presentation-Exchange Attachment format for requesting and presenting proofs
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1075,7 +1075,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1096,7 +1096,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1117,7 +1117,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1138,7 +1138,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1159,7 +1159,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1180,7 +1180,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1222,7 +1222,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1243,7 +1243,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1285,7 +1285,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1306,7 +1306,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1336,7 +1336,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1347,7 +1347,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1541,7 +1541,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1562,7 +1562,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1583,7 +1583,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3488,6 +3488,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3656,6 +3677,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3698,6 +3740,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3713,6 +3776,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5360,7 +5465,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0454-present-proof-v2/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0454 Present Proof Protocol 2.0">
+          <a href="../0454-present-proof-v2/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0454 Present Proof Protocol 2.0">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -5370,7 +5475,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0454 Present Proof Protocol 2.0
+                0454 Present Proof Protocol 2.0
               </div>
             </div>
           </a>
@@ -5420,7 +5525,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0519-goal-codes/index.html b/main/aip2/0519-goal-codes/index.html
index 6be2efa6c..61a200581 100644
--- a/main/aip2/0519-goal-codes/index.html
+++ b/main/aip2/0519-goal-codes/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1075,7 +1075,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1096,7 +1096,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1117,7 +1117,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1138,7 +1138,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1159,7 +1159,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1180,7 +1180,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1222,7 +1222,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1243,7 +1243,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1285,7 +1285,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1306,7 +1306,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1327,7 +1327,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1541,7 +1541,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1562,7 +1562,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1583,7 +1583,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3488,6 +3488,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3656,6 +3677,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3698,6 +3740,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3713,6 +3776,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4870,7 +4975,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0510-dif-pres-exch-attach/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs">
+          <a href="../0510-dif-pres-exch-attach/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0510 Presentation-Exchange Attachment format for requesting and presenting proofs">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4880,20 +4985,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+                0510 Presentation-Exchange Attachment format for requesting and presenting proofs
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0557-discover-features-v2/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0557 Discover Features Protocol v2.x">
+          <a href="../0557-discover-features-v2/" class="md-footer__link md-footer__link--next" aria-label="Next: 0557 Discover Features Protocol v2.x">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0557 Discover Features Protocol v2.x
+                0557 Discover Features Protocol v2.x
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4930,7 +5035,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0557-discover-features-v2/index.html b/main/aip2/0557-discover-features-v2/index.html
index 2e1422d86..7d19d66fa 100644
--- a/main/aip2/0557-discover-features-v2/index.html
+++ b/main/aip2/0557-discover-features-v2/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0557 Discover Features Protocol v2.x - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0557 Discover Features Protocol v2.x - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0557 Discover Features Protocol v2.x
+              0557 Discover Features Protocol v2.x
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1075,7 +1075,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1096,7 +1096,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1117,7 +1117,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1138,7 +1138,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1159,7 +1159,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1180,7 +1180,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1222,7 +1222,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1243,7 +1243,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1285,7 +1285,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1306,7 +1306,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1327,7 +1327,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1378,7 +1378,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1389,7 +1389,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1508,7 +1508,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1529,7 +1529,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3434,6 +3434,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3602,6 +3623,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3644,6 +3686,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3659,6 +3722,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4757,13 +4862,13 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
         
         
           
-          <a href="../0592-indy-attachments/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials">
+          <a href="../0592-indy-attachments/" class="md-footer__link md-footer__link--next" aria-label="Next: 0592 Indy Attachment Formats for Requesting and Presenting Credentials">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+                0592 Indy Attachment Formats for Requesting and Presenting Credentials
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4800,7 +4905,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0592-indy-attachments/index.html b/main/aip2/0592-indy-attachments/index.html
index 22762499c..1a0f03ba4 100644
--- a/main/aip2/0592-indy-attachments/index.html
+++ b/main/aip2/0592-indy-attachments/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0592 Indy Attachment Formats for Requesting and Presenting Credentials - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+              0592 Indy Attachment Formats for Requesting and Presenting Credentials
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1075,7 +1075,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1096,7 +1096,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1117,7 +1117,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1138,7 +1138,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1159,7 +1159,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1180,7 +1180,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1222,7 +1222,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1243,7 +1243,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1285,7 +1285,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1306,7 +1306,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1327,7 +1327,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1369,7 +1369,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1399,7 +1399,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1410,7 +1410,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1565,7 +1565,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3470,6 +3470,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3638,6 +3659,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3680,6 +3722,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3695,6 +3758,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5026,7 +5131,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0557-discover-features-v2/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0557 Discover Features Protocol v2.x">
+          <a href="../0557-discover-features-v2/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0557 Discover Features Protocol v2.x">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -5036,20 +5141,20 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0557 Discover Features Protocol v2.x
+                0557 Discover Features Protocol v2.x
               </div>
             </div>
           </a>
         
         
           
-          <a href="../0593-json-ld-cred-attach/" class="md-footer__link md-footer__link--next" aria-label="Next: Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials">
+          <a href="../0593-json-ld-cred-attach/" class="md-footer__link md-footer__link--next" aria-label="Next: 0593 JSON-LD Credential Attachment format for requesting and issuing credentials">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+                0593 JSON-LD Credential Attachment format for requesting and issuing credentials
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -5086,7 +5191,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/aip2/0593-json-ld-cred-attach/index.html b/main/aip2/0593-json-ld-cred-attach/index.html
index 40ed483c3..a64d931f8 100644
--- a/main/aip2/0593-json-ld-cred-attach/index.html
+++ b/main/aip2/0593-json-ld-cred-attach/index.html
@@ -16,15 +16,15 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
-        <title>Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials - Hyperledger Aries Interoperability Profiles / RFCs</title>
+        <title>0593 JSON-LD Credential Attachment format for requesting and issuing credentials - Hyperledger Aries Interoperability Profiles / RFCs</title>
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -107,7 +107,7 @@
         <div class="md-header__topic" data-md-component="header-topic">
           <span class="md-ellipsis">
             
-              Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+              0593 JSON-LD Credential Attachment format for requesting and issuing credentials
             
           </span>
         </div>
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -760,7 +760,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -781,7 +781,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -802,7 +802,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -823,7 +823,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -844,7 +844,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -865,7 +865,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -886,7 +886,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -907,7 +907,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -928,7 +928,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -949,7 +949,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -970,7 +970,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -991,7 +991,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1012,7 +1012,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1033,7 +1033,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1054,7 +1054,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1075,7 +1075,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1096,7 +1096,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1117,7 +1117,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1138,7 +1138,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1159,7 +1159,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1180,7 +1180,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1222,7 +1222,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1243,7 +1243,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1285,7 +1285,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1306,7 +1306,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1327,7 +1327,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1369,7 +1369,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1390,7 +1390,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1420,7 +1420,7 @@
           
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -1431,7 +1431,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3470,6 +3470,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3638,6 +3659,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3680,6 +3722,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3695,6 +3758,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4935,7 +5040,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0592-indy-attachments/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials">
+          <a href="../0592-indy-attachments/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0592 Indy Attachment Formats for Requesting and Presenting Credentials">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4945,7 +5050,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+                0592 Indy Attachment Formats for Requesting and Presenting Credentials
               </div>
             </div>
           </a>
@@ -4995,7 +5100,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/assets/javascripts/bundle.525ec568.min.js b/main/assets/javascripts/bundle.88dd0f4e.min.js
similarity index 66%
rename from main/assets/javascripts/bundle.525ec568.min.js
rename to main/assets/javascripts/bundle.88dd0f4e.min.js
index 4b08eae40..fb8f31090 100644
--- a/main/assets/javascripts/bundle.525ec568.min.js
+++ b/main/assets/javascripts/bundle.88dd0f4e.min.js
@@ -11,6 +11,6 @@
  * Licensed MIT © Zeno Rocha
  */(function(t,r){typeof It=="object"&&typeof Yr=="object"?Yr.exports=r():typeof define=="function"&&define.amd?define([],r):typeof It=="object"?It.ClipboardJS=r():t.ClipboardJS=r()})(It,function(){return function(){var e={686:function(o,n,i){"use strict";i.d(n,{default:function(){return Ui}});var a=i(279),s=i.n(a),p=i(370),c=i.n(p),l=i(817),f=i.n(l);function u(V){try{return document.execCommand(V)}catch(A){return!1}}var d=function(A){var M=f()(A);return u("cut"),M},y=d;function L(V){var A=document.documentElement.getAttribute("dir")==="rtl",M=document.createElement("textarea");M.style.fontSize="12pt",M.style.border="0",M.style.padding="0",M.style.margin="0",M.style.position="absolute",M.style[A?"right":"left"]="-9999px";var F=window.pageYOffset||document.documentElement.scrollTop;return M.style.top="".concat(F,"px"),M.setAttribute("readonly",""),M.value=V,M}var X=function(A,M){var F=L(A);M.container.appendChild(F);var D=f()(F);return u("copy"),F.remove(),D},te=function(A){var M=arguments.length>1&&arguments[1]!==void 0?arguments[1]:{container:document.body},F="";return typeof A=="string"?F=X(A,M):A instanceof HTMLInputElement&&!["text","search","url","tel","password"].includes(A==null?void 0:A.type)?F=X(A.value,M):(F=f()(A),u("copy")),F},J=te;function k(V){"@babel/helpers - typeof";return typeof Symbol=="function"&&typeof Symbol.iterator=="symbol"?k=function(M){return typeof M}:k=function(M){return M&&typeof Symbol=="function"&&M.constructor===Symbol&&M!==Symbol.prototype?"symbol":typeof M},k(V)}var ft=function(){var A=arguments.length>0&&arguments[0]!==void 0?arguments[0]:{},M=A.action,F=M===void 0?"copy":M,D=A.container,Y=A.target,$e=A.text;if(F!=="copy"&&F!=="cut")throw new Error('Invalid "action" value, use either "copy" or "cut"');if(Y!==void 0)if(Y&&k(Y)==="object"&&Y.nodeType===1){if(F==="copy"&&Y.hasAttribute("disabled"))throw new Error('Invalid "target" attribute. Please use "readonly" instead of "disabled" attribute');if(F==="cut"&&(Y.hasAttribute("readonly")||Y.hasAttribute("disabled")))throw new Error(`Invalid "target" attribute. You can't cut text from elements with "readonly" or "disabled" attributes`)}else throw new Error('Invalid "target" value, use a valid Element');if($e)return J($e,{container:D});if(Y)return F==="cut"?y(Y):J(Y,{container:D})},qe=ft;function Fe(V){"@babel/helpers - typeof";return typeof Symbol=="function"&&typeof Symbol.iterator=="symbol"?Fe=function(M){return typeof M}:Fe=function(M){return M&&typeof Symbol=="function"&&M.constructor===Symbol&&M!==Symbol.prototype?"symbol":typeof M},Fe(V)}function ki(V,A){if(!(V instanceof A))throw new TypeError("Cannot call a class as a function")}function no(V,A){for(var M=0;M<A.length;M++){var F=A[M];F.enumerable=F.enumerable||!1,F.configurable=!0,"value"in F&&(F.writable=!0),Object.defineProperty(V,F.key,F)}}function Hi(V,A,M){return A&&no(V.prototype,A),M&&no(V,M),V}function $i(V,A){if(typeof A!="function"&&A!==null)throw new TypeError("Super expression must either be null or a function");V.prototype=Object.create(A&&A.prototype,{constructor:{value:V,writable:!0,configurable:!0}}),A&&br(V,A)}function br(V,A){return br=Object.setPrototypeOf||function(F,D){return F.__proto__=D,F},br(V,A)}function Pi(V){var A=ji();return function(){var F=Wt(V),D;if(A){var Y=Wt(this).constructor;D=Reflect.construct(F,arguments,Y)}else D=F.apply(this,arguments);return Ri(this,D)}}function Ri(V,A){return A&&(Fe(A)==="object"||typeof A=="function")?A:Ii(V)}function Ii(V){if(V===void 0)throw new ReferenceError("this hasn't been initialised - super() hasn't been called");return V}function ji(){if(typeof Reflect=="undefined"||!Reflect.construct||Reflect.construct.sham)return!1;if(typeof Proxy=="function")return!0;try{return Date.prototype.toString.call(Reflect.construct(Date,[],function(){})),!0}catch(V){return!1}}function Wt(V){return Wt=Object.setPrototypeOf?Object.getPrototypeOf:function(M){return M.__proto__||Object.getPrototypeOf(M)},Wt(V)}function vr(V,A){var M="data-clipboard-".concat(V);if(A.hasAttribute(M))return A.getAttribute(M)}var Fi=function(V){$i(M,V);var A=Pi(M);function M(F,D){var Y;return ki(this,M),Y=A.call(this),Y.resolveOptions(D),Y.listenClick(F),Y}return Hi(M,[{key:"resolveOptions",value:function(){var D=arguments.length>0&&arguments[0]!==void 0?arguments[0]:{};this.action=typeof D.action=="function"?D.action:this.defaultAction,this.target=typeof D.target=="function"?D.target:this.defaultTarget,this.text=typeof D.text=="function"?D.text:this.defaultText,this.container=Fe(D.container)==="object"?D.container:document.body}},{key:"listenClick",value:function(D){var Y=this;this.listener=c()(D,"click",function($e){return Y.onClick($e)})}},{key:"onClick",value:function(D){var Y=D.delegateTarget||D.currentTarget,$e=this.action(Y)||"copy",Dt=qe({action:$e,container:this.container,target:this.target(Y),text:this.text(Y)});this.emit(Dt?"success":"error",{action:$e,text:Dt,trigger:Y,clearSelection:function(){Y&&Y.focus(),window.getSelection().removeAllRanges()}})}},{key:"defaultAction",value:function(D){return vr("action",D)}},{key:"defaultTarget",value:function(D){var Y=vr("target",D);if(Y)return document.querySelector(Y)}},{key:"defaultText",value:function(D){return vr("text",D)}},{key:"destroy",value:function(){this.listener.destroy()}}],[{key:"copy",value:function(D){var Y=arguments.length>1&&arguments[1]!==void 0?arguments[1]:{container:document.body};return J(D,Y)}},{key:"cut",value:function(D){return y(D)}},{key:"isSupported",value:function(){var D=arguments.length>0&&arguments[0]!==void 0?arguments[0]:["copy","cut"],Y=typeof D=="string"?[D]:D,$e=!!document.queryCommandSupported;return Y.forEach(function(Dt){$e=$e&&!!document.queryCommandSupported(Dt)}),$e}}]),M}(s()),Ui=Fi},828:function(o){var n=9;if(typeof Element!="undefined"&&!Element.prototype.matches){var i=Element.prototype;i.matches=i.matchesSelector||i.mozMatchesSelector||i.msMatchesSelector||i.oMatchesSelector||i.webkitMatchesSelector}function a(s,p){for(;s&&s.nodeType!==n;){if(typeof s.matches=="function"&&s.matches(p))return s;s=s.parentNode}}o.exports=a},438:function(o,n,i){var a=i(828);function s(l,f,u,d,y){var L=c.apply(this,arguments);return l.addEventListener(u,L,y),{destroy:function(){l.removeEventListener(u,L,y)}}}function p(l,f,u,d,y){return typeof l.addEventListener=="function"?s.apply(null,arguments):typeof u=="function"?s.bind(null,document).apply(null,arguments):(typeof l=="string"&&(l=document.querySelectorAll(l)),Array.prototype.map.call(l,function(L){return s(L,f,u,d,y)}))}function c(l,f,u,d){return function(y){y.delegateTarget=a(y.target,f),y.delegateTarget&&d.call(l,y)}}o.exports=p},879:function(o,n){n.node=function(i){return i!==void 0&&i instanceof HTMLElement&&i.nodeType===1},n.nodeList=function(i){var a=Object.prototype.toString.call(i);return i!==void 0&&(a==="[object NodeList]"||a==="[object HTMLCollection]")&&"length"in i&&(i.length===0||n.node(i[0]))},n.string=function(i){return typeof i=="string"||i instanceof String},n.fn=function(i){var a=Object.prototype.toString.call(i);return a==="[object Function]"}},370:function(o,n,i){var a=i(879),s=i(438);function p(u,d,y){if(!u&&!d&&!y)throw new Error("Missing required arguments");if(!a.string(d))throw new TypeError("Second argument must be a String");if(!a.fn(y))throw new TypeError("Third argument must be a Function");if(a.node(u))return c(u,d,y);if(a.nodeList(u))return l(u,d,y);if(a.string(u))return f(u,d,y);throw new TypeError("First argument must be a String, HTMLElement, HTMLCollection, or NodeList")}function c(u,d,y){return u.addEventListener(d,y),{destroy:function(){u.removeEventListener(d,y)}}}function l(u,d,y){return Array.prototype.forEach.call(u,function(L){L.addEventListener(d,y)}),{destroy:function(){Array.prototype.forEach.call(u,function(L){L.removeEventListener(d,y)})}}}function f(u,d,y){return s(document.body,u,d,y)}o.exports=p},817:function(o){function n(i){var a;if(i.nodeName==="SELECT")i.focus(),a=i.value;else if(i.nodeName==="INPUT"||i.nodeName==="TEXTAREA"){var s=i.hasAttribute("readonly");s||i.setAttribute("readonly",""),i.select(),i.setSelectionRange(0,i.value.length),s||i.removeAttribute("readonly"),a=i.value}else{i.hasAttribute("contenteditable")&&i.focus();var p=window.getSelection(),c=document.createRange();c.selectNodeContents(i),p.removeAllRanges(),p.addRange(c),a=p.toString()}return a}o.exports=n},279:function(o){function n(){}n.prototype={on:function(i,a,s){var p=this.e||(this.e={});return(p[i]||(p[i]=[])).push({fn:a,ctx:s}),this},once:function(i,a,s){var p=this;function c(){p.off(i,c),a.apply(s,arguments)}return c._=a,this.on(i,c,s)},emit:function(i){var a=[].slice.call(arguments,1),s=((this.e||(this.e={}))[i]||[]).slice(),p=0,c=s.length;for(p;p<c;p++)s[p].fn.apply(s[p].ctx,a);return this},off:function(i,a){var s=this.e||(this.e={}),p=s[i],c=[];if(p&&a)for(var l=0,f=p.length;l<f;l++)p[l].fn!==a&&p[l].fn._!==a&&c.push(p[l]);return c.length?s[i]=c:delete s[i],this}},o.exports=n,o.exports.TinyEmitter=n}},t={};function r(o){if(t[o])return t[o].exports;var n=t[o]={exports:{}};return e[o](n,n.exports,r),n.exports}return function(){r.n=function(o){var n=o&&o.__esModule?function(){return o.default}:function(){return o};return r.d(n,{a:n}),n}}(),function(){r.d=function(o,n){for(var i in n)r.o(n,i)&&!r.o(o,i)&&Object.defineProperty(o,i,{enumerable:!0,get:n[i]})}}(),function(){r.o=function(o,n){return Object.prototype.hasOwnProperty.call(o,n)}}(),r(686)}().default})});var lL=Mt(lo());var wr=function(e,t){return wr=Object.setPrototypeOf||{__proto__:[]}instanceof Array&&function(r,o){r.__proto__=o}||function(r,o){for(var n in o)Object.prototype.hasOwnProperty.call(o,n)&&(r[n]=o[n])},wr(e,t)};function oe(e,t){if(typeof t!="function"&&t!==null)throw new TypeError("Class extends value "+String(t)+" is not a constructor or null");wr(e,t);function r(){this.constructor=e}e.prototype=t===null?Object.create(t):(r.prototype=t.prototype,new r)}function mo(e,t,r,o){function n(i){return i instanceof r?i:new r(function(a){a(i)})}return new(r||(r=Promise))(function(i,a){function s(l){try{c(o.next(l))}catch(f){a(f)}}function p(l){try{c(o.throw(l))}catch(f){a(f)}}function c(l){l.done?i(l.value):n(l.value).then(s,p)}c((o=o.apply(e,t||[])).next())})}function Nt(e,t){var r={label:0,sent:function(){if(i[0]&1)throw i[1];return i[1]},trys:[],ops:[]},o,n,i,a=Object.create((typeof Iterator=="function"?Iterator:Object).prototype);return a.next=s(0),a.throw=s(1),a.return=s(2),typeof Symbol=="function"&&(a[Symbol.iterator]=function(){return this}),a;function s(c){return function(l){return p([c,l])}}function p(c){if(o)throw new TypeError("Generator is already executing.");for(;a&&(a=0,c[0]&&(r=0)),r;)try{if(o=1,n&&(i=c[0]&2?n.return:c[0]?n.throw||((i=n.return)&&i.call(n),0):n.next)&&!(i=i.call(n,c[1])).done)return i;switch(n=0,i&&(c=[c[0]&2,i.value]),c[0]){case 0:case 1:i=c;break;case 4:return r.label++,{value:c[1],done:!1};case 5:r.label++,n=c[1],c=[0];continue;case 7:c=r.ops.pop(),r.trys.pop();continue;default:if(i=r.trys,!(i=i.length>0&&i[i.length-1])&&(c[0]===6||c[0]===2)){r=0;continue}if(c[0]===3&&(!i||c[1]>i[0]&&c[1]<i[3])){r.label=c[1];break}if(c[0]===6&&r.label<i[1]){r.label=i[1],i=c;break}if(i&&r.label<i[2]){r.label=i[2],r.ops.push(c);break}i[2]&&r.ops.pop(),r.trys.pop();continue}c=t.call(e,r)}catch(l){c=[6,l],n=0}finally{o=i=0}if(c[0]&5)throw c[1];return{value:c[0]?c[1]:void 0,done:!0}}}function he(e){var t=typeof Symbol=="function"&&Symbol.iterator,r=t&&e[t],o=0;if(r)return r.call(e);if(e&&typeof e.length=="number")return{next:function(){return e&&o>=e.length&&(e=void 0),{value:e&&e[o++],done:!e}}};throw new TypeError(t?"Object is not iterable.":"Symbol.iterator is not defined.")}function N(e,t){var r=typeof Symbol=="function"&&e[Symbol.iterator];if(!r)return e;var o=r.call(e),n,i=[],a;try{for(;(t===void 0||t-- >0)&&!(n=o.next()).done;)i.push(n.value)}catch(s){a={error:s}}finally{try{n&&!n.done&&(r=o.return)&&r.call(o)}finally{if(a)throw a.error}}return i}function q(e,t,r){if(r||arguments.length===2)for(var o=0,n=t.length,i;o<n;o++)(i||!(o in t))&&(i||(i=Array.prototype.slice.call(t,0,o)),i[o]=t[o]);return e.concat(i||Array.prototype.slice.call(t))}function nt(e){return this instanceof nt?(this.v=e,this):new nt(e)}function fo(e,t,r){if(!Symbol.asyncIterator)throw new TypeError("Symbol.asyncIterator is not defined.");var o=r.apply(e,t||[]),n,i=[];return n=Object.create((typeof AsyncIterator=="function"?AsyncIterator:Object).prototype),s("next"),s("throw"),s("return",a),n[Symbol.asyncIterator]=function(){return this},n;function a(d){return function(y){return Promise.resolve(y).then(d,f)}}function s(d,y){o[d]&&(n[d]=function(L){return new Promise(function(X,te){i.push([d,L,X,te])>1||p(d,L)})},y&&(n[d]=y(n[d])))}function p(d,y){try{c(o[d](y))}catch(L){u(i[0][3],L)}}function c(d){d.value instanceof nt?Promise.resolve(d.value.v).then(l,f):u(i[0][2],d)}function l(d){p("next",d)}function f(d){p("throw",d)}function u(d,y){d(y),i.shift(),i.length&&p(i[0][0],i[0][1])}}function uo(e){if(!Symbol.asyncIterator)throw new TypeError("Symbol.asyncIterator is not defined.");var t=e[Symbol.asyncIterator],r;return t?t.call(e):(e=typeof he=="function"?he(e):e[Symbol.iterator](),r={},o("next"),o("throw"),o("return"),r[Symbol.asyncIterator]=function(){return this},r);function o(i){r[i]=e[i]&&function(a){return new Promise(function(s,p){a=e[i](a),n(s,p,a.done,a.value)})}}function n(i,a,s,p){Promise.resolve(p).then(function(c){i({value:c,done:s})},a)}}function H(e){return typeof e=="function"}function ut(e){var t=function(o){Error.call(o),o.stack=new Error().stack},r=e(t);return r.prototype=Object.create(Error.prototype),r.prototype.constructor=r,r}var zt=ut(function(e){return function(r){e(this),this.message=r?r.length+` errors occurred during unsubscription:
 `+r.map(function(o,n){return n+1+") "+o.toString()}).join(`
-  `):"",this.name="UnsubscriptionError",this.errors=r}});function Qe(e,t){if(e){var r=e.indexOf(t);0<=r&&e.splice(r,1)}}var Ue=function(){function e(t){this.initialTeardown=t,this.closed=!1,this._parentage=null,this._finalizers=null}return e.prototype.unsubscribe=function(){var t,r,o,n,i;if(!this.closed){this.closed=!0;var a=this._parentage;if(a)if(this._parentage=null,Array.isArray(a))try{for(var s=he(a),p=s.next();!p.done;p=s.next()){var c=p.value;c.remove(this)}}catch(L){t={error:L}}finally{try{p&&!p.done&&(r=s.return)&&r.call(s)}finally{if(t)throw t.error}}else a.remove(this);var l=this.initialTeardown;if(H(l))try{l()}catch(L){i=L instanceof zt?L.errors:[L]}var f=this._finalizers;if(f){this._finalizers=null;try{for(var u=he(f),d=u.next();!d.done;d=u.next()){var y=d.value;try{ho(y)}catch(L){i=i!=null?i:[],L instanceof zt?i=q(q([],N(i)),N(L.errors)):i.push(L)}}}catch(L){o={error:L}}finally{try{d&&!d.done&&(n=u.return)&&n.call(u)}finally{if(o)throw o.error}}}if(i)throw new zt(i)}},e.prototype.add=function(t){var r;if(t&&t!==this)if(this.closed)ho(t);else{if(t instanceof e){if(t.closed||t._hasParent(this))return;t._addParent(this)}(this._finalizers=(r=this._finalizers)!==null&&r!==void 0?r:[]).push(t)}},e.prototype._hasParent=function(t){var r=this._parentage;return r===t||Array.isArray(r)&&r.includes(t)},e.prototype._addParent=function(t){var r=this._parentage;this._parentage=Array.isArray(r)?(r.push(t),r):r?[r,t]:t},e.prototype._removeParent=function(t){var r=this._parentage;r===t?this._parentage=null:Array.isArray(r)&&Qe(r,t)},e.prototype.remove=function(t){var r=this._finalizers;r&&Qe(r,t),t instanceof e&&t._removeParent(this)},e.EMPTY=function(){var t=new e;return t.closed=!0,t}(),e}();var Tr=Ue.EMPTY;function qt(e){return e instanceof Ue||e&&"closed"in e&&H(e.remove)&&H(e.add)&&H(e.unsubscribe)}function ho(e){H(e)?e():e.unsubscribe()}var Pe={onUnhandledError:null,onStoppedNotification:null,Promise:void 0,useDeprecatedSynchronousErrorHandling:!1,useDeprecatedNextContext:!1};var dt={setTimeout:function(e,t){for(var r=[],o=2;o<arguments.length;o++)r[o-2]=arguments[o];var n=dt.delegate;return n!=null&&n.setTimeout?n.setTimeout.apply(n,q([e,t],N(r))):setTimeout.apply(void 0,q([e,t],N(r)))},clearTimeout:function(e){var t=dt.delegate;return((t==null?void 0:t.clearTimeout)||clearTimeout)(e)},delegate:void 0};function Qt(e){dt.setTimeout(function(){var t=Pe.onUnhandledError;if(t)t(e);else throw e})}function be(){}var bo=function(){return Sr("C",void 0,void 0)}();function vo(e){return Sr("E",void 0,e)}function go(e){return Sr("N",e,void 0)}function Sr(e,t,r){return{kind:e,value:t,error:r}}var it=null;function ht(e){if(Pe.useDeprecatedSynchronousErrorHandling){var t=!it;if(t&&(it={errorThrown:!1,error:null}),e(),t){var r=it,o=r.errorThrown,n=r.error;if(it=null,o)throw n}}else e()}function yo(e){Pe.useDeprecatedSynchronousErrorHandling&&it&&(it.errorThrown=!0,it.error=e)}var _t=function(e){oe(t,e);function t(r){var o=e.call(this)||this;return o.isStopped=!1,r?(o.destination=r,qt(r)&&r.add(o)):o.destination=Yi,o}return t.create=function(r,o,n){return new at(r,o,n)},t.prototype.next=function(r){this.isStopped?Lr(go(r),this):this._next(r)},t.prototype.error=function(r){this.isStopped?Lr(vo(r),this):(this.isStopped=!0,this._error(r))},t.prototype.complete=function(){this.isStopped?Lr(bo,this):(this.isStopped=!0,this._complete())},t.prototype.unsubscribe=function(){this.closed||(this.isStopped=!0,e.prototype.unsubscribe.call(this),this.destination=null)},t.prototype._next=function(r){this.destination.next(r)},t.prototype._error=function(r){try{this.destination.error(r)}finally{this.unsubscribe()}},t.prototype._complete=function(){try{this.destination.complete()}finally{this.unsubscribe()}},t}(Ue);var qi=Function.prototype.bind;function Or(e,t){return qi.call(e,t)}var Qi=function(){function e(t){this.partialObserver=t}return e.prototype.next=function(t){var r=this.partialObserver;if(r.next)try{r.next(t)}catch(o){Kt(o)}},e.prototype.error=function(t){var r=this.partialObserver;if(r.error)try{r.error(t)}catch(o){Kt(o)}else Kt(t)},e.prototype.complete=function(){var t=this.partialObserver;if(t.complete)try{t.complete()}catch(r){Kt(r)}},e}(),at=function(e){oe(t,e);function t(r,o,n){var i=e.call(this)||this,a;if(H(r)||!r)a={next:r!=null?r:void 0,error:o!=null?o:void 0,complete:n!=null?n:void 0};else{var s;i&&Pe.useDeprecatedNextContext?(s=Object.create(r),s.unsubscribe=function(){return i.unsubscribe()},a={next:r.next&&Or(r.next,s),error:r.error&&Or(r.error,s),complete:r.complete&&Or(r.complete,s)}):a=r}return i.destination=new Qi(a),i}return t}(_t);function Kt(e){Pe.useDeprecatedSynchronousErrorHandling?yo(e):Qt(e)}function Ki(e){throw e}function Lr(e,t){var r=Pe.onStoppedNotification;r&&dt.setTimeout(function(){return r(e,t)})}var Yi={closed:!0,next:be,error:Ki,complete:be};var bt=function(){return typeof Symbol=="function"&&Symbol.observable||"@@observable"}();function le(e){return e}function xo(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];return Mr(e)}function Mr(e){return e.length===0?le:e.length===1?e[0]:function(r){return e.reduce(function(o,n){return n(o)},r)}}var j=function(){function e(t){t&&(this._subscribe=t)}return e.prototype.lift=function(t){var r=new e;return r.source=this,r.operator=t,r},e.prototype.subscribe=function(t,r,o){var n=this,i=Gi(t)?t:new at(t,r,o);return ht(function(){var a=n,s=a.operator,p=a.source;i.add(s?s.call(i,p):p?n._subscribe(i):n._trySubscribe(i))}),i},e.prototype._trySubscribe=function(t){try{return this._subscribe(t)}catch(r){t.error(r)}},e.prototype.forEach=function(t,r){var o=this;return r=Eo(r),new r(function(n,i){var a=new at({next:function(s){try{t(s)}catch(p){i(p),a.unsubscribe()}},error:i,complete:n});o.subscribe(a)})},e.prototype._subscribe=function(t){var r;return(r=this.source)===null||r===void 0?void 0:r.subscribe(t)},e.prototype[bt]=function(){return this},e.prototype.pipe=function(){for(var t=[],r=0;r<arguments.length;r++)t[r]=arguments[r];return Mr(t)(this)},e.prototype.toPromise=function(t){var r=this;return t=Eo(t),new t(function(o,n){var i;r.subscribe(function(a){return i=a},function(a){return n(a)},function(){return o(i)})})},e.create=function(t){return new e(t)},e}();function Eo(e){var t;return(t=e!=null?e:Pe.Promise)!==null&&t!==void 0?t:Promise}function Bi(e){return e&&H(e.next)&&H(e.error)&&H(e.complete)}function Gi(e){return e&&e instanceof _t||Bi(e)&&qt(e)}function Ji(e){return H(e==null?void 0:e.lift)}function E(e){return function(t){if(Ji(t))return t.lift(function(r){try{return e(r,this)}catch(o){this.error(o)}});throw new TypeError("Unable to lift unknown Observable type")}}function T(e,t,r,o,n){return new Xi(e,t,r,o,n)}var Xi=function(e){oe(t,e);function t(r,o,n,i,a,s){var p=e.call(this,r)||this;return p.onFinalize=a,p.shouldUnsubscribe=s,p._next=o?function(c){try{o(c)}catch(l){r.error(l)}}:e.prototype._next,p._error=i?function(c){try{i(c)}catch(l){r.error(l)}finally{this.unsubscribe()}}:e.prototype._error,p._complete=n?function(){try{n()}catch(c){r.error(c)}finally{this.unsubscribe()}}:e.prototype._complete,p}return t.prototype.unsubscribe=function(){var r;if(!this.shouldUnsubscribe||this.shouldUnsubscribe()){var o=this.closed;e.prototype.unsubscribe.call(this),!o&&((r=this.onFinalize)===null||r===void 0||r.call(this))}},t}(_t);var vt={schedule:function(e){var t=requestAnimationFrame,r=cancelAnimationFrame,o=vt.delegate;o&&(t=o.requestAnimationFrame,r=o.cancelAnimationFrame);var n=t(function(i){r=void 0,e(i)});return new Ue(function(){return r==null?void 0:r(n)})},requestAnimationFrame:function(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=vt.delegate;return((r==null?void 0:r.requestAnimationFrame)||requestAnimationFrame).apply(void 0,q([],N(e)))},cancelAnimationFrame:function(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=vt.delegate;return((r==null?void 0:r.cancelAnimationFrame)||cancelAnimationFrame).apply(void 0,q([],N(e)))},delegate:void 0};var wo=ut(function(e){return function(){e(this),this.name="ObjectUnsubscribedError",this.message="object unsubscribed"}});var g=function(e){oe(t,e);function t(){var r=e.call(this)||this;return r.closed=!1,r.currentObservers=null,r.observers=[],r.isStopped=!1,r.hasError=!1,r.thrownError=null,r}return t.prototype.lift=function(r){var o=new To(this,this);return o.operator=r,o},t.prototype._throwIfClosed=function(){if(this.closed)throw new wo},t.prototype.next=function(r){var o=this;ht(function(){var n,i;if(o._throwIfClosed(),!o.isStopped){o.currentObservers||(o.currentObservers=Array.from(o.observers));try{for(var a=he(o.currentObservers),s=a.next();!s.done;s=a.next()){var p=s.value;p.next(r)}}catch(c){n={error:c}}finally{try{s&&!s.done&&(i=a.return)&&i.call(a)}finally{if(n)throw n.error}}}})},t.prototype.error=function(r){var o=this;ht(function(){if(o._throwIfClosed(),!o.isStopped){o.hasError=o.isStopped=!0,o.thrownError=r;for(var n=o.observers;n.length;)n.shift().error(r)}})},t.prototype.complete=function(){var r=this;ht(function(){if(r._throwIfClosed(),!r.isStopped){r.isStopped=!0;for(var o=r.observers;o.length;)o.shift().complete()}})},t.prototype.unsubscribe=function(){this.isStopped=this.closed=!0,this.observers=this.currentObservers=null},Object.defineProperty(t.prototype,"observed",{get:function(){var r;return((r=this.observers)===null||r===void 0?void 0:r.length)>0},enumerable:!1,configurable:!0}),t.prototype._trySubscribe=function(r){return this._throwIfClosed(),e.prototype._trySubscribe.call(this,r)},t.prototype._subscribe=function(r){return this._throwIfClosed(),this._checkFinalizedStatuses(r),this._innerSubscribe(r)},t.prototype._innerSubscribe=function(r){var o=this,n=this,i=n.hasError,a=n.isStopped,s=n.observers;return i||a?Tr:(this.currentObservers=null,s.push(r),new Ue(function(){o.currentObservers=null,Qe(s,r)}))},t.prototype._checkFinalizedStatuses=function(r){var o=this,n=o.hasError,i=o.thrownError,a=o.isStopped;n?r.error(i):a&&r.complete()},t.prototype.asObservable=function(){var r=new j;return r.source=this,r},t.create=function(r,o){return new To(r,o)},t}(j);var To=function(e){oe(t,e);function t(r,o){var n=e.call(this)||this;return n.destination=r,n.source=o,n}return t.prototype.next=function(r){var o,n;(n=(o=this.destination)===null||o===void 0?void 0:o.next)===null||n===void 0||n.call(o,r)},t.prototype.error=function(r){var o,n;(n=(o=this.destination)===null||o===void 0?void 0:o.error)===null||n===void 0||n.call(o,r)},t.prototype.complete=function(){var r,o;(o=(r=this.destination)===null||r===void 0?void 0:r.complete)===null||o===void 0||o.call(r)},t.prototype._subscribe=function(r){var o,n;return(n=(o=this.source)===null||o===void 0?void 0:o.subscribe(r))!==null&&n!==void 0?n:Tr},t}(g);var _r=function(e){oe(t,e);function t(r){var o=e.call(this)||this;return o._value=r,o}return Object.defineProperty(t.prototype,"value",{get:function(){return this.getValue()},enumerable:!1,configurable:!0}),t.prototype._subscribe=function(r){var o=e.prototype._subscribe.call(this,r);return!o.closed&&r.next(this._value),o},t.prototype.getValue=function(){var r=this,o=r.hasError,n=r.thrownError,i=r._value;if(o)throw n;return this._throwIfClosed(),i},t.prototype.next=function(r){e.prototype.next.call(this,this._value=r)},t}(g);var At={now:function(){return(At.delegate||Date).now()},delegate:void 0};var Ct=function(e){oe(t,e);function t(r,o,n){r===void 0&&(r=1/0),o===void 0&&(o=1/0),n===void 0&&(n=At);var i=e.call(this)||this;return i._bufferSize=r,i._windowTime=o,i._timestampProvider=n,i._buffer=[],i._infiniteTimeWindow=!0,i._infiniteTimeWindow=o===1/0,i._bufferSize=Math.max(1,r),i._windowTime=Math.max(1,o),i}return t.prototype.next=function(r){var o=this,n=o.isStopped,i=o._buffer,a=o._infiniteTimeWindow,s=o._timestampProvider,p=o._windowTime;n||(i.push(r),!a&&i.push(s.now()+p)),this._trimBuffer(),e.prototype.next.call(this,r)},t.prototype._subscribe=function(r){this._throwIfClosed(),this._trimBuffer();for(var o=this._innerSubscribe(r),n=this,i=n._infiniteTimeWindow,a=n._buffer,s=a.slice(),p=0;p<s.length&&!r.closed;p+=i?1:2)r.next(s[p]);return this._checkFinalizedStatuses(r),o},t.prototype._trimBuffer=function(){var r=this,o=r._bufferSize,n=r._timestampProvider,i=r._buffer,a=r._infiniteTimeWindow,s=(a?1:2)*o;if(o<1/0&&s<i.length&&i.splice(0,i.length-s),!a){for(var p=n.now(),c=0,l=1;l<i.length&&i[l]<=p;l+=2)c=l;c&&i.splice(0,c+1)}},t}(g);var So=function(e){oe(t,e);function t(r,o){return e.call(this)||this}return t.prototype.schedule=function(r,o){return o===void 0&&(o=0),this},t}(Ue);var kt={setInterval:function(e,t){for(var r=[],o=2;o<arguments.length;o++)r[o-2]=arguments[o];var n=kt.delegate;return n!=null&&n.setInterval?n.setInterval.apply(n,q([e,t],N(r))):setInterval.apply(void 0,q([e,t],N(r)))},clearInterval:function(e){var t=kt.delegate;return((t==null?void 0:t.clearInterval)||clearInterval)(e)},delegate:void 0};var gt=function(e){oe(t,e);function t(r,o){var n=e.call(this,r,o)||this;return n.scheduler=r,n.work=o,n.pending=!1,n}return t.prototype.schedule=function(r,o){var n;if(o===void 0&&(o=0),this.closed)return this;this.state=r;var i=this.id,a=this.scheduler;return i!=null&&(this.id=this.recycleAsyncId(a,i,o)),this.pending=!0,this.delay=o,this.id=(n=this.id)!==null&&n!==void 0?n:this.requestAsyncId(a,this.id,o),this},t.prototype.requestAsyncId=function(r,o,n){return n===void 0&&(n=0),kt.setInterval(r.flush.bind(r,this),n)},t.prototype.recycleAsyncId=function(r,o,n){if(n===void 0&&(n=0),n!=null&&this.delay===n&&this.pending===!1)return o;o!=null&&kt.clearInterval(o)},t.prototype.execute=function(r,o){if(this.closed)return new Error("executing a cancelled action");this.pending=!1;var n=this._execute(r,o);if(n)return n;this.pending===!1&&this.id!=null&&(this.id=this.recycleAsyncId(this.scheduler,this.id,null))},t.prototype._execute=function(r,o){var n=!1,i;try{this.work(r)}catch(a){n=!0,i=a||new Error("Scheduled action threw falsy error")}if(n)return this.unsubscribe(),i},t.prototype.unsubscribe=function(){if(!this.closed){var r=this,o=r.id,n=r.scheduler,i=n.actions;this.work=this.state=this.scheduler=null,this.pending=!1,Qe(i,this),o!=null&&(this.id=this.recycleAsyncId(n,o,null)),this.delay=null,e.prototype.unsubscribe.call(this)}},t}(So);var Ar=function(){function e(t,r){r===void 0&&(r=e.now),this.schedulerActionCtor=t,this.now=r}return e.prototype.schedule=function(t,r,o){return r===void 0&&(r=0),new this.schedulerActionCtor(this,t).schedule(o,r)},e.now=At.now,e}();var yt=function(e){oe(t,e);function t(r,o){o===void 0&&(o=Ar.now);var n=e.call(this,r,o)||this;return n.actions=[],n._active=!1,n}return t.prototype.flush=function(r){var o=this.actions;if(this._active){o.push(r);return}var n;this._active=!0;do if(n=r.execute(r.state,r.delay))break;while(r=o.shift());if(this._active=!1,n){for(;r=o.shift();)r.unsubscribe();throw n}},t}(Ar);var se=new yt(gt),Cr=se;var Oo=function(e){oe(t,e);function t(r,o){var n=e.call(this,r,o)||this;return n.scheduler=r,n.work=o,n}return t.prototype.schedule=function(r,o){return o===void 0&&(o=0),o>0?e.prototype.schedule.call(this,r,o):(this.delay=o,this.state=r,this.scheduler.flush(this),this)},t.prototype.execute=function(r,o){return o>0||this.closed?e.prototype.execute.call(this,r,o):this._execute(r,o)},t.prototype.requestAsyncId=function(r,o,n){return n===void 0&&(n=0),n!=null&&n>0||n==null&&this.delay>0?e.prototype.requestAsyncId.call(this,r,o,n):(r.flush(this),0)},t}(gt);var Lo=function(e){oe(t,e);function t(){return e!==null&&e.apply(this,arguments)||this}return t}(yt);var kr=new Lo(Oo);var Mo=function(e){oe(t,e);function t(r,o){var n=e.call(this,r,o)||this;return n.scheduler=r,n.work=o,n}return t.prototype.requestAsyncId=function(r,o,n){return n===void 0&&(n=0),n!==null&&n>0?e.prototype.requestAsyncId.call(this,r,o,n):(r.actions.push(this),r._scheduled||(r._scheduled=vt.requestAnimationFrame(function(){return r.flush(void 0)})))},t.prototype.recycleAsyncId=function(r,o,n){var i;if(n===void 0&&(n=0),n!=null?n>0:this.delay>0)return e.prototype.recycleAsyncId.call(this,r,o,n);var a=r.actions;o!=null&&((i=a[a.length-1])===null||i===void 0?void 0:i.id)!==o&&(vt.cancelAnimationFrame(o),r._scheduled=void 0)},t}(gt);var _o=function(e){oe(t,e);function t(){return e!==null&&e.apply(this,arguments)||this}return t.prototype.flush=function(r){this._active=!0;var o=this._scheduled;this._scheduled=void 0;var n=this.actions,i;r=r||n.shift();do if(i=r.execute(r.state,r.delay))break;while((r=n[0])&&r.id===o&&n.shift());if(this._active=!1,i){for(;(r=n[0])&&r.id===o&&n.shift();)r.unsubscribe();throw i}},t}(yt);var me=new _o(Mo);var S=new j(function(e){return e.complete()});function Yt(e){return e&&H(e.schedule)}function Hr(e){return e[e.length-1]}function Xe(e){return H(Hr(e))?e.pop():void 0}function ke(e){return Yt(Hr(e))?e.pop():void 0}function Bt(e,t){return typeof Hr(e)=="number"?e.pop():t}var xt=function(e){return e&&typeof e.length=="number"&&typeof e!="function"};function Gt(e){return H(e==null?void 0:e.then)}function Jt(e){return H(e[bt])}function Xt(e){return Symbol.asyncIterator&&H(e==null?void 0:e[Symbol.asyncIterator])}function Zt(e){return new TypeError("You provided "+(e!==null&&typeof e=="object"?"an invalid object":"'"+e+"'")+" where a stream was expected. You can provide an Observable, Promise, ReadableStream, Array, AsyncIterable, or Iterable.")}function Zi(){return typeof Symbol!="function"||!Symbol.iterator?"@@iterator":Symbol.iterator}var er=Zi();function tr(e){return H(e==null?void 0:e[er])}function rr(e){return fo(this,arguments,function(){var r,o,n,i;return Nt(this,function(a){switch(a.label){case 0:r=e.getReader(),a.label=1;case 1:a.trys.push([1,,9,10]),a.label=2;case 2:return[4,nt(r.read())];case 3:return o=a.sent(),n=o.value,i=o.done,i?[4,nt(void 0)]:[3,5];case 4:return[2,a.sent()];case 5:return[4,nt(n)];case 6:return[4,a.sent()];case 7:return a.sent(),[3,2];case 8:return[3,10];case 9:return r.releaseLock(),[7];case 10:return[2]}})})}function or(e){return H(e==null?void 0:e.getReader)}function U(e){if(e instanceof j)return e;if(e!=null){if(Jt(e))return ea(e);if(xt(e))return ta(e);if(Gt(e))return ra(e);if(Xt(e))return Ao(e);if(tr(e))return oa(e);if(or(e))return na(e)}throw Zt(e)}function ea(e){return new j(function(t){var r=e[bt]();if(H(r.subscribe))return r.subscribe(t);throw new TypeError("Provided object does not correctly implement Symbol.observable")})}function ta(e){return new j(function(t){for(var r=0;r<e.length&&!t.closed;r++)t.next(e[r]);t.complete()})}function ra(e){return new j(function(t){e.then(function(r){t.closed||(t.next(r),t.complete())},function(r){return t.error(r)}).then(null,Qt)})}function oa(e){return new j(function(t){var r,o;try{for(var n=he(e),i=n.next();!i.done;i=n.next()){var a=i.value;if(t.next(a),t.closed)return}}catch(s){r={error:s}}finally{try{i&&!i.done&&(o=n.return)&&o.call(n)}finally{if(r)throw r.error}}t.complete()})}function Ao(e){return new j(function(t){ia(e,t).catch(function(r){return t.error(r)})})}function na(e){return Ao(rr(e))}function ia(e,t){var r,o,n,i;return mo(this,void 0,void 0,function(){var a,s;return Nt(this,function(p){switch(p.label){case 0:p.trys.push([0,5,6,11]),r=uo(e),p.label=1;case 1:return[4,r.next()];case 2:if(o=p.sent(),!!o.done)return[3,4];if(a=o.value,t.next(a),t.closed)return[2];p.label=3;case 3:return[3,1];case 4:return[3,11];case 5:return s=p.sent(),n={error:s},[3,11];case 6:return p.trys.push([6,,9,10]),o&&!o.done&&(i=r.return)?[4,i.call(r)]:[3,8];case 7:p.sent(),p.label=8;case 8:return[3,10];case 9:if(n)throw n.error;return[7];case 10:return[7];case 11:return t.complete(),[2]}})})}function we(e,t,r,o,n){o===void 0&&(o=0),n===void 0&&(n=!1);var i=t.schedule(function(){r(),n?e.add(this.schedule(null,o)):this.unsubscribe()},o);if(e.add(i),!n)return i}function ve(e,t){return t===void 0&&(t=0),E(function(r,o){r.subscribe(T(o,function(n){return we(o,e,function(){return o.next(n)},t)},function(){return we(o,e,function(){return o.complete()},t)},function(n){return we(o,e,function(){return o.error(n)},t)}))})}function Ke(e,t){return t===void 0&&(t=0),E(function(r,o){o.add(e.schedule(function(){return r.subscribe(o)},t))})}function Co(e,t){return U(e).pipe(Ke(t),ve(t))}function ko(e,t){return U(e).pipe(Ke(t),ve(t))}function Ho(e,t){return new j(function(r){var o=0;return t.schedule(function(){o===e.length?r.complete():(r.next(e[o++]),r.closed||this.schedule())})})}function $o(e,t){return new j(function(r){var o;return we(r,t,function(){o=e[er](),we(r,t,function(){var n,i,a;try{n=o.next(),i=n.value,a=n.done}catch(s){r.error(s);return}a?r.complete():r.next(i)},0,!0)}),function(){return H(o==null?void 0:o.return)&&o.return()}})}function nr(e,t){if(!e)throw new Error("Iterable cannot be null");return new j(function(r){we(r,t,function(){var o=e[Symbol.asyncIterator]();we(r,t,function(){o.next().then(function(n){n.done?r.complete():r.next(n.value)})},0,!0)})})}function Po(e,t){return nr(rr(e),t)}function Ro(e,t){if(e!=null){if(Jt(e))return Co(e,t);if(xt(e))return Ho(e,t);if(Gt(e))return ko(e,t);if(Xt(e))return nr(e,t);if(tr(e))return $o(e,t);if(or(e))return Po(e,t)}throw Zt(e)}function ue(e,t){return t?Ro(e,t):U(e)}function I(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=ke(e);return ue(e,r)}function $r(e,t){var r=H(e)?e:function(){return e},o=function(n){return n.error(r())};return new j(t?function(n){return t.schedule(o,0,n)}:o)}var ir=ut(function(e){return function(){e(this),this.name="EmptyError",this.message="no elements in sequence"}});function Io(e){return e instanceof Date&&!isNaN(e)}function m(e,t){return E(function(r,o){var n=0;r.subscribe(T(o,function(i){o.next(e.call(t,i,n++))}))})}var aa=Array.isArray;function sa(e,t){return aa(t)?e.apply(void 0,q([],N(t))):e(t)}function Ze(e){return m(function(t){return sa(e,t)})}var ca=Array.isArray,pa=Object.getPrototypeOf,la=Object.prototype,ma=Object.keys;function jo(e){if(e.length===1){var t=e[0];if(ca(t))return{args:t,keys:null};if(fa(t)){var r=ma(t);return{args:r.map(function(o){return t[o]}),keys:r}}}return{args:e,keys:null}}function fa(e){return e&&typeof e=="object"&&pa(e)===la}function Fo(e,t){return e.reduce(function(r,o,n){return r[o]=t[n],r},{})}function z(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=ke(e),o=Xe(e),n=jo(e),i=n.args,a=n.keys;if(i.length===0)return ue([],r);var s=new j(Pr(i,r,a?function(p){return Fo(a,p)}:le));return o?s.pipe(Ze(o)):s}function Pr(e,t,r){return r===void 0&&(r=le),function(o){Uo(t,function(){for(var n=e.length,i=new Array(n),a=n,s=n,p=function(l){Uo(t,function(){var f=ue(e[l],t),u=!1;f.subscribe(T(o,function(d){i[l]=d,u||(u=!0,s--),s||o.next(r(i.slice()))},function(){--a||o.complete()}))},o)},c=0;c<n;c++)p(c)},o)}}function Uo(e,t,r){e?we(r,e,t):t()}function Wo(e,t,r,o,n,i,a,s){var p=[],c=0,l=0,f=!1,u=function(){f&&!p.length&&!c&&t.complete()},d=function(L){return c<o?y(L):p.push(L)},y=function(L){i&&t.next(L),c++;var X=!1;U(r(L,l++)).subscribe(T(t,function(te){n==null||n(te),i?d(te):t.next(te)},function(){X=!0},void 0,function(){if(X)try{c--;for(var te=function(){var J=p.shift();a?we(t,a,function(){return y(J)}):y(J)};p.length&&c<o;)te();u()}catch(J){t.error(J)}}))};return e.subscribe(T(t,d,function(){f=!0,u()})),function(){s==null||s()}}function ne(e,t,r){return r===void 0&&(r=1/0),H(t)?ne(function(o,n){return m(function(i,a){return t(o,i,n,a)})(U(e(o,n)))},r):(typeof t=="number"&&(r=t),E(function(o,n){return Wo(o,n,e,r)}))}function Et(e){return e===void 0&&(e=1/0),ne(le,e)}function Do(){return Et(1)}function We(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];return Do()(ue(e,ke(e)))}function C(e){return new j(function(t){U(e()).subscribe(t)})}var ua=["addListener","removeListener"],da=["addEventListener","removeEventListener"],ha=["on","off"];function h(e,t,r,o){if(H(r)&&(o=r,r=void 0),o)return h(e,t,r).pipe(Ze(o));var n=N(ga(e)?da.map(function(s){return function(p){return e[s](t,p,r)}}):ba(e)?ua.map(Vo(e,t)):va(e)?ha.map(Vo(e,t)):[],2),i=n[0],a=n[1];if(!i&&xt(e))return ne(function(s){return h(s,t,r)})(U(e));if(!i)throw new TypeError("Invalid event target");return new j(function(s){var p=function(){for(var c=[],l=0;l<arguments.length;l++)c[l]=arguments[l];return s.next(1<c.length?c:c[0])};return i(p),function(){return a(p)}})}function Vo(e,t){return function(r){return function(o){return e[r](t,o)}}}function ba(e){return H(e.addListener)&&H(e.removeListener)}function va(e){return H(e.on)&&H(e.off)}function ga(e){return H(e.addEventListener)&&H(e.removeEventListener)}function ar(e,t,r){return r?ar(e,t).pipe(Ze(r)):new j(function(o){var n=function(){for(var a=[],s=0;s<arguments.length;s++)a[s]=arguments[s];return o.next(a.length===1?a[0]:a)},i=e(n);return H(t)?function(){return t(n,i)}:void 0})}function Le(e,t,r){e===void 0&&(e=0),r===void 0&&(r=Cr);var o=-1;return t!=null&&(Yt(t)?r=t:o=t),new j(function(n){var i=Io(e)?+e-r.now():e;i<0&&(i=0);var a=0;return r.schedule(function(){n.closed||(n.next(a++),0<=o?this.schedule(void 0,o):n.complete())},i)})}function O(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=ke(e),o=Bt(e,1/0),n=e;return n.length?n.length===1?U(n[0]):Et(o)(ue(n,r)):S}var Ye=new j(be);var ya=Array.isArray;function wt(e){return e.length===1&&ya(e[0])?e[0]:e}function b(e,t){return E(function(r,o){var n=0;r.subscribe(T(o,function(i){return e.call(t,i,n++)&&o.next(i)}))})}function st(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=Xe(e),o=wt(e);return o.length?new j(function(n){var i=o.map(function(){return[]}),a=o.map(function(){return!1});n.add(function(){i=a=null});for(var s=function(c){U(o[c]).subscribe(T(n,function(l){if(i[c].push(l),i.every(function(u){return u.length})){var f=i.map(function(u){return u.shift()});n.next(r?r.apply(void 0,q([],N(f))):f),i.some(function(u,d){return!u.length&&a[d]})&&n.complete()}},function(){a[c]=!0,!i[c].length&&n.complete()}))},p=0;!n.closed&&p<o.length;p++)s(p);return function(){i=a=null}}):S}function No(e){return E(function(t,r){var o=!1,n=null,i=null,a=!1,s=function(){if(i==null||i.unsubscribe(),i=null,o){o=!1;var c=n;n=null,r.next(c)}a&&r.complete()},p=function(){i=null,a&&r.complete()};t.subscribe(T(r,function(c){o=!0,n=c,i||U(e(c)).subscribe(i=T(r,s,p))},function(){a=!0,(!o||!i||i.closed)&&r.complete()}))})}function Me(e,t){return t===void 0&&(t=se),No(function(){return Le(e,t)})}function Be(e,t){return t===void 0&&(t=null),t=t!=null?t:e,E(function(r,o){var n=[],i=0;r.subscribe(T(o,function(a){var s,p,c,l,f=null;i++%t===0&&n.push([]);try{for(var u=he(n),d=u.next();!d.done;d=u.next()){var y=d.value;y.push(a),e<=y.length&&(f=f!=null?f:[],f.push(y))}}catch(te){s={error:te}}finally{try{d&&!d.done&&(p=u.return)&&p.call(u)}finally{if(s)throw s.error}}if(f)try{for(var L=he(f),X=L.next();!X.done;X=L.next()){var y=X.value;Qe(n,y),o.next(y)}}catch(te){c={error:te}}finally{try{X&&!X.done&&(l=L.return)&&l.call(L)}finally{if(c)throw c.error}}},function(){var a,s;try{for(var p=he(n),c=p.next();!c.done;c=p.next()){var l=c.value;o.next(l)}}catch(f){a={error:f}}finally{try{c&&!c.done&&(s=p.return)&&s.call(p)}finally{if(a)throw a.error}}o.complete()},void 0,function(){n=null}))})}function de(e){return E(function(t,r){var o=null,n=!1,i;o=t.subscribe(T(r,void 0,void 0,function(a){i=U(e(a,de(e)(t))),o?(o.unsubscribe(),o=null,i.subscribe(r)):n=!0})),n&&(o.unsubscribe(),o=null,i.subscribe(r))})}function zo(e,t,r,o,n){return function(i,a){var s=r,p=t,c=0;i.subscribe(T(a,function(l){var f=c++;p=s?e(p,l,f):(s=!0,l),o&&a.next(p)},n&&function(){s&&a.next(p),a.complete()}))}}function Rr(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=Xe(e);return r?xo(Rr.apply(void 0,q([],N(e))),Ze(r)):E(function(o,n){Pr(q([o],N(wt(e))))(n)})}function He(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];return Rr.apply(void 0,q([],N(e)))}function Ht(e){return E(function(t,r){var o=!1,n=null,i=null,a=function(){if(i==null||i.unsubscribe(),i=null,o){o=!1;var s=n;n=null,r.next(s)}};t.subscribe(T(r,function(s){i==null||i.unsubscribe(),o=!0,n=s,i=T(r,a,be),U(e(s)).subscribe(i)},function(){a(),r.complete()},void 0,function(){n=i=null}))})}function _e(e,t){return t===void 0&&(t=se),E(function(r,o){var n=null,i=null,a=null,s=function(){if(n){n.unsubscribe(),n=null;var c=i;i=null,o.next(c)}};function p(){var c=a+e,l=t.now();if(l<c){n=this.schedule(void 0,c-l),o.add(n);return}s()}r.subscribe(T(o,function(c){i=c,a=t.now(),n||(n=t.schedule(p,e),o.add(n))},function(){s(),o.complete()},void 0,function(){i=n=null}))})}function De(e){return E(function(t,r){var o=!1;t.subscribe(T(r,function(n){o=!0,r.next(n)},function(){o||r.next(e),r.complete()}))})}function Te(e){return e<=0?function(){return S}:E(function(t,r){var o=0;t.subscribe(T(r,function(n){++o<=e&&(r.next(n),e<=o&&r.complete())}))})}function Z(){return E(function(e,t){e.subscribe(T(t,be))})}function qo(e){return m(function(){return e})}function Ir(e,t){return t?function(r){return We(t.pipe(Te(1),Z()),r.pipe(Ir(e)))}:ne(function(r,o){return U(e(r,o)).pipe(Te(1),qo(r))})}function Ge(e,t){t===void 0&&(t=se);var r=Le(e,t);return Ir(function(){return r})}function K(e,t){return t===void 0&&(t=le),e=e!=null?e:xa,E(function(r,o){var n,i=!0;r.subscribe(T(o,function(a){var s=t(a);(i||!e(n,s))&&(i=!1,n=s,o.next(a))}))})}function xa(e,t){return e===t}function ee(e,t){return K(function(r,o){return t?t(r[e],o[e]):r[e]===o[e]})}function Qo(e){return e===void 0&&(e=Ea),E(function(t,r){var o=!1;t.subscribe(T(r,function(n){o=!0,r.next(n)},function(){return o?r.complete():r.error(e())}))})}function Ea(){return new ir}function ie(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];return function(r){return We(r,I.apply(void 0,q([],N(e))))}}function _(e){return E(function(t,r){try{t.subscribe(r)}finally{r.add(e)}})}function Ae(e,t){var r=arguments.length>=2;return function(o){return o.pipe(e?b(function(n,i){return e(n,i,o)}):le,Te(1),r?De(t):Qo(function(){return new ir}))}}function jr(e){return e<=0?function(){return S}:E(function(t,r){var o=[];t.subscribe(T(r,function(n){o.push(n),e<o.length&&o.shift()},function(){var n,i;try{for(var a=he(o),s=a.next();!s.done;s=a.next()){var p=s.value;r.next(p)}}catch(c){n={error:c}}finally{try{s&&!s.done&&(i=a.return)&&i.call(a)}finally{if(n)throw n.error}}r.complete()},void 0,function(){o=null}))})}function Ko(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=ke(e),o=Bt(e,1/0);return e=wt(e),E(function(n,i){Et(o)(ue(q([n],N(e)),r)).subscribe(i)})}function Re(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];return Ko.apply(void 0,q([],N(e)))}function ct(e){var t,r=1/0,o;return e!=null&&(typeof e=="object"?(t=e.count,r=t===void 0?1/0:t,o=e.delay):r=e),r<=0?function(){return S}:E(function(n,i){var a=0,s,p=function(){if(s==null||s.unsubscribe(),s=null,o!=null){var l=typeof o=="number"?Le(o):U(o(a)),f=T(i,function(){f.unsubscribe(),c()});l.subscribe(f)}else c()},c=function(){var l=!1;s=n.subscribe(T(i,void 0,function(){++a<r?s?p():l=!0:i.complete()})),l&&p()};c()})}function Fr(e,t){return E(zo(e,t,arguments.length>=2,!0))}function pe(e){e===void 0&&(e={});var t=e.connector,r=t===void 0?function(){return new g}:t,o=e.resetOnError,n=o===void 0?!0:o,i=e.resetOnComplete,a=i===void 0?!0:i,s=e.resetOnRefCountZero,p=s===void 0?!0:s;return function(c){var l,f,u,d=0,y=!1,L=!1,X=function(){f==null||f.unsubscribe(),f=void 0},te=function(){X(),l=u=void 0,y=L=!1},J=function(){var k=l;te(),k==null||k.unsubscribe()};return E(function(k,ft){d++,!L&&!y&&X();var qe=u=u!=null?u:r();ft.add(function(){d--,d===0&&!L&&!y&&(f=Ur(J,p))}),qe.subscribe(ft),!l&&d>0&&(l=new at({next:function(Fe){return qe.next(Fe)},error:function(Fe){L=!0,X(),f=Ur(te,n,Fe),qe.error(Fe)},complete:function(){y=!0,X(),f=Ur(te,a),qe.complete()}}),U(k).subscribe(l))})(c)}}function Ur(e,t){for(var r=[],o=2;o<arguments.length;o++)r[o-2]=arguments[o];if(t===!0){e();return}if(t!==!1){var n=new at({next:function(){n.unsubscribe(),e()}});return U(t.apply(void 0,q([],N(r)))).subscribe(n)}}function G(e,t,r){var o,n,i,a,s=!1;return e&&typeof e=="object"?(o=e.bufferSize,a=o===void 0?1/0:o,n=e.windowTime,t=n===void 0?1/0:n,i=e.refCount,s=i===void 0?!1:i,r=e.scheduler):a=e!=null?e:1/0,pe({connector:function(){return new Ct(a,t,r)},resetOnError:!0,resetOnComplete:!1,resetOnRefCountZero:s})}function Ce(e){return b(function(t,r){return e<=r})}function Wr(e){return E(function(t,r){var o=!1,n=T(r,function(){n==null||n.unsubscribe(),o=!0},be);U(e).subscribe(n),t.subscribe(T(r,function(i){return o&&r.next(i)}))})}function Q(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=ke(e);return E(function(o,n){(r?We(e,o,r):We(e,o)).subscribe(n)})}function v(e,t){return E(function(r,o){var n=null,i=0,a=!1,s=function(){return a&&!n&&o.complete()};r.subscribe(T(o,function(p){n==null||n.unsubscribe();var c=0,l=i++;U(e(p,l)).subscribe(n=T(o,function(f){return o.next(t?t(p,f,l,c++):f)},function(){n=null,s()}))},function(){a=!0,s()}))})}function W(e){return E(function(t,r){U(e).subscribe(T(r,function(){return r.complete()},be)),!r.closed&&t.subscribe(r)})}function Dr(e,t){return t===void 0&&(t=!1),E(function(r,o){var n=0;r.subscribe(T(o,function(i){var a=e(i,n++);(a||t)&&o.next(i),!a&&o.complete()}))})}function w(e,t,r){var o=H(e)||t||r?{next:e,error:t,complete:r}:e;return o?E(function(n,i){var a;(a=o.subscribe)===null||a===void 0||a.call(o);var s=!0;n.subscribe(T(i,function(p){var c;(c=o.next)===null||c===void 0||c.call(o,p),i.next(p)},function(){var p;s=!1,(p=o.complete)===null||p===void 0||p.call(o),i.complete()},function(p){var c;s=!1,(c=o.error)===null||c===void 0||c.call(o,p),i.error(p)},function(){var p,c;s&&((p=o.unsubscribe)===null||p===void 0||p.call(o)),(c=o.finalize)===null||c===void 0||c.call(o)}))}):le}function Yo(e,t){return E(function(r,o){var n=t!=null?t:{},i=n.leading,a=i===void 0?!0:i,s=n.trailing,p=s===void 0?!1:s,c=!1,l=null,f=null,u=!1,d=function(){f==null||f.unsubscribe(),f=null,p&&(X(),u&&o.complete())},y=function(){f=null,u&&o.complete()},L=function(te){return f=U(e(te)).subscribe(T(o,d,y))},X=function(){if(c){c=!1;var te=l;l=null,o.next(te),!u&&L(te)}};r.subscribe(T(o,function(te){c=!0,l=te,!(f&&!f.closed)&&(a?X():L(te))},function(){u=!0,!(p&&c&&f&&!f.closed)&&o.complete()}))})}function pt(e,t,r){t===void 0&&(t=se);var o=Le(e,t);return Yo(function(){return o},r)}function re(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=Xe(e);return E(function(o,n){for(var i=e.length,a=new Array(i),s=e.map(function(){return!1}),p=!1,c=function(f){U(e[f]).subscribe(T(n,function(u){a[f]=u,!p&&!s[f]&&(s[f]=!0,(p=s.every(le))&&(s=null))},be))},l=0;l<i;l++)c(l);o.subscribe(T(n,function(f){if(p){var u=q([f],N(a));n.next(r?r.apply(void 0,q([],N(u))):u)}}))})}function Bo(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];return E(function(r,o){st.apply(void 0,q([r],N(e))).subscribe(o)})}function Vr(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];return Bo.apply(void 0,q([],N(e)))}function Go(){let e=new Ct(1);return h(document,"DOMContentLoaded",{once:!0}).subscribe(()=>e.next(document)),e}function P(e,t=document){return Array.from(t.querySelectorAll(e))}function R(e,t=document){let r=fe(e,t);if(typeof r=="undefined")throw new ReferenceError(`Missing element: expected "${e}" to be present`);return r}function fe(e,t=document){return t.querySelector(e)||void 0}function Ie(){var e,t,r,o;return(o=(r=(t=(e=document.activeElement)==null?void 0:e.shadowRoot)==null?void 0:t.activeElement)!=null?r:document.activeElement)!=null?o:void 0}var wa=O(h(document.body,"focusin"),h(document.body,"focusout")).pipe(_e(1),Q(void 0),m(()=>Ie()||document.body),G(1));function et(e){return wa.pipe(m(t=>e.contains(t)),K())}function $t(e,t){return C(()=>O(h(e,"mouseenter").pipe(m(()=>!0)),h(e,"mouseleave").pipe(m(()=>!1))).pipe(t?Ht(r=>Le(+!r*t)):le,Q(e.matches(":hover"))))}function Jo(e,t){if(typeof t=="string"||typeof t=="number")e.innerHTML+=t.toString();else if(t instanceof Node)e.appendChild(t);else if(Array.isArray(t))for(let r of t)Jo(e,r)}function x(e,t,...r){let o=document.createElement(e);if(t)for(let n of Object.keys(t))typeof t[n]!="undefined"&&(typeof t[n]!="boolean"?o.setAttribute(n,t[n]):o.setAttribute(n,""));for(let n of r)Jo(o,n);return o}function sr(e){if(e>999){let t=+((e-950)%1e3>99);return`${((e+1e-6)/1e3).toFixed(t)}k`}else return e.toString()}function Tt(e){let t=x("script",{src:e});return C(()=>(document.head.appendChild(t),O(h(t,"load"),h(t,"error").pipe(v(()=>$r(()=>new ReferenceError(`Invalid script: ${e}`))))).pipe(m(()=>{}),_(()=>document.head.removeChild(t)),Te(1))))}var Xo=new g,Ta=C(()=>typeof ResizeObserver=="undefined"?Tt("https://unpkg.com/resize-observer-polyfill"):I(void 0)).pipe(m(()=>new ResizeObserver(e=>e.forEach(t=>Xo.next(t)))),v(e=>O(Ye,I(e)).pipe(_(()=>e.disconnect()))),G(1));function ce(e){return{width:e.offsetWidth,height:e.offsetHeight}}function ge(e){let t=e;for(;t.clientWidth===0&&t.parentElement;)t=t.parentElement;return Ta.pipe(w(r=>r.observe(t)),v(r=>Xo.pipe(b(o=>o.target===t),_(()=>r.unobserve(t)))),m(()=>ce(e)),Q(ce(e)))}function St(e){return{width:e.scrollWidth,height:e.scrollHeight}}function cr(e){let t=e.parentElement;for(;t&&(e.scrollWidth<=t.scrollWidth&&e.scrollHeight<=t.scrollHeight);)t=(e=t).parentElement;return t?e:void 0}function Zo(e){let t=[],r=e.parentElement;for(;r;)(e.clientWidth>r.clientWidth||e.clientHeight>r.clientHeight)&&t.push(r),r=(e=r).parentElement;return t.length===0&&t.push(document.documentElement),t}function Ve(e){return{x:e.offsetLeft,y:e.offsetTop}}function en(e){let t=e.getBoundingClientRect();return{x:t.x+window.scrollX,y:t.y+window.scrollY}}function tn(e){return O(h(window,"load"),h(window,"resize")).pipe(Me(0,me),m(()=>Ve(e)),Q(Ve(e)))}function pr(e){return{x:e.scrollLeft,y:e.scrollTop}}function Ne(e){return O(h(e,"scroll"),h(window,"scroll"),h(window,"resize")).pipe(Me(0,me),m(()=>pr(e)),Q(pr(e)))}var rn=new g,Sa=C(()=>I(new IntersectionObserver(e=>{for(let t of e)rn.next(t)},{threshold:0}))).pipe(v(e=>O(Ye,I(e)).pipe(_(()=>e.disconnect()))),G(1));function tt(e){return Sa.pipe(w(t=>t.observe(e)),v(t=>rn.pipe(b(({target:r})=>r===e),_(()=>t.unobserve(e)),m(({isIntersecting:r})=>r))))}function on(e,t=16){return Ne(e).pipe(m(({y:r})=>{let o=ce(e),n=St(e);return r>=n.height-o.height-t}),K())}var lr={drawer:R("[data-md-toggle=drawer]"),search:R("[data-md-toggle=search]")};function nn(e){return lr[e].checked}function Je(e,t){lr[e].checked!==t&&lr[e].click()}function ze(e){let t=lr[e];return h(t,"change").pipe(m(()=>t.checked),Q(t.checked))}function Oa(e,t){switch(e.constructor){case HTMLInputElement:return e.type==="radio"?/^Arrow/.test(t):!0;case HTMLSelectElement:case HTMLTextAreaElement:return!0;default:return e.isContentEditable}}function La(){return O(h(window,"compositionstart").pipe(m(()=>!0)),h(window,"compositionend").pipe(m(()=>!1))).pipe(Q(!1))}function an(){let e=h(window,"keydown").pipe(b(t=>!(t.metaKey||t.ctrlKey)),m(t=>({mode:nn("search")?"search":"global",type:t.key,claim(){t.preventDefault(),t.stopPropagation()}})),b(({mode:t,type:r})=>{if(t==="global"){let o=Ie();if(typeof o!="undefined")return!Oa(o,r)}return!0}),pe());return La().pipe(v(t=>t?S:e))}function ye(){return new URL(location.href)}function lt(e,t=!1){if(B("navigation.instant")&&!t){let r=x("a",{href:e.href});document.body.appendChild(r),r.click(),r.remove()}else location.href=e.href}function sn(){return new g}function cn(){return location.hash.slice(1)}function pn(e){let t=x("a",{href:e});t.addEventListener("click",r=>r.stopPropagation()),t.click()}function Ma(e){return O(h(window,"hashchange"),e).pipe(m(cn),Q(cn()),b(t=>t.length>0),G(1))}function ln(e){return Ma(e).pipe(m(t=>fe(`[id="${t}"]`)),b(t=>typeof t!="undefined"))}function Pt(e){let t=matchMedia(e);return ar(r=>t.addListener(()=>r(t.matches))).pipe(Q(t.matches))}function mn(){let e=matchMedia("print");return O(h(window,"beforeprint").pipe(m(()=>!0)),h(window,"afterprint").pipe(m(()=>!1))).pipe(Q(e.matches))}function Nr(e,t){return e.pipe(v(r=>r?t():S))}function zr(e,t){return new j(r=>{let o=new XMLHttpRequest;return o.open("GET",`${e}`),o.responseType="blob",o.addEventListener("load",()=>{o.status>=200&&o.status<300?(r.next(o.response),r.complete()):r.error(new Error(o.statusText))}),o.addEventListener("error",()=>{r.error(new Error("Network error"))}),o.addEventListener("abort",()=>{r.complete()}),typeof(t==null?void 0:t.progress$)!="undefined"&&(o.addEventListener("progress",n=>{var i;if(n.lengthComputable)t.progress$.next(n.loaded/n.total*100);else{let a=(i=o.getResponseHeader("Content-Length"))!=null?i:0;t.progress$.next(n.loaded/+a*100)}}),t.progress$.next(5)),o.send(),()=>o.abort()})}function je(e,t){return zr(e,t).pipe(v(r=>r.text()),m(r=>JSON.parse(r)),G(1))}function fn(e,t){let r=new DOMParser;return zr(e,t).pipe(v(o=>o.text()),m(o=>r.parseFromString(o,"text/html")),G(1))}function un(e,t){let r=new DOMParser;return zr(e,t).pipe(v(o=>o.text()),m(o=>r.parseFromString(o,"text/xml")),G(1))}function dn(){return{x:Math.max(0,scrollX),y:Math.max(0,scrollY)}}function hn(){return O(h(window,"scroll",{passive:!0}),h(window,"resize",{passive:!0})).pipe(m(dn),Q(dn()))}function bn(){return{width:innerWidth,height:innerHeight}}function vn(){return h(window,"resize",{passive:!0}).pipe(m(bn),Q(bn()))}function gn(){return z([hn(),vn()]).pipe(m(([e,t])=>({offset:e,size:t})),G(1))}function mr(e,{viewport$:t,header$:r}){let o=t.pipe(ee("size")),n=z([o,r]).pipe(m(()=>Ve(e)));return z([r,t,n]).pipe(m(([{height:i},{offset:a,size:s},{x:p,y:c}])=>({offset:{x:a.x-p,y:a.y-c+i},size:s})))}function _a(e){return h(e,"message",t=>t.data)}function Aa(e){let t=new g;return t.subscribe(r=>e.postMessage(r)),t}function yn(e,t=new Worker(e)){let r=_a(t),o=Aa(t),n=new g;n.subscribe(o);let i=o.pipe(Z(),ie(!0));return n.pipe(Z(),Re(r.pipe(W(i))),pe())}var Ca=R("#__config"),Ot=JSON.parse(Ca.textContent);Ot.base=`${new URL(Ot.base,ye())}`;function xe(){return Ot}function B(e){return Ot.features.includes(e)}function Ee(e,t){return typeof t!="undefined"?Ot.translations[e].replace("#",t.toString()):Ot.translations[e]}function Se(e,t=document){return R(`[data-md-component=${e}]`,t)}function ae(e,t=document){return P(`[data-md-component=${e}]`,t)}function ka(e){let t=R(".md-typeset > :first-child",e);return h(t,"click",{once:!0}).pipe(m(()=>R(".md-typeset",e)),m(r=>({hash:__md_hash(r.innerHTML)})))}function xn(e){if(!B("announce.dismiss")||!e.childElementCount)return S;if(!e.hidden){let t=R(".md-typeset",e);__md_hash(t.innerHTML)===__md_get("__announce")&&(e.hidden=!0)}return C(()=>{let t=new g;return t.subscribe(({hash:r})=>{e.hidden=!0,__md_set("__announce",r)}),ka(e).pipe(w(r=>t.next(r)),_(()=>t.complete()),m(r=>$({ref:e},r)))})}function Ha(e,{target$:t}){return t.pipe(m(r=>({hidden:r!==e})))}function En(e,t){let r=new g;return r.subscribe(({hidden:o})=>{e.hidden=o}),Ha(e,t).pipe(w(o=>r.next(o)),_(()=>r.complete()),m(o=>$({ref:e},o)))}function Rt(e,t){return t==="inline"?x("div",{class:"md-tooltip md-tooltip--inline",id:e,role:"tooltip"},x("div",{class:"md-tooltip__inner md-typeset"})):x("div",{class:"md-tooltip",id:e,role:"tooltip"},x("div",{class:"md-tooltip__inner md-typeset"}))}function wn(...e){return x("div",{class:"md-tooltip2",role:"tooltip"},x("div",{class:"md-tooltip2__inner md-typeset"},e))}function Tn(e,t){if(t=t?`${t}_annotation_${e}`:void 0,t){let r=t?`#${t}`:void 0;return x("aside",{class:"md-annotation",tabIndex:0},Rt(t),x("a",{href:r,class:"md-annotation__index",tabIndex:-1},x("span",{"data-md-annotation-id":e})))}else return x("aside",{class:"md-annotation",tabIndex:0},Rt(t),x("span",{class:"md-annotation__index",tabIndex:-1},x("span",{"data-md-annotation-id":e})))}function Sn(e){return x("button",{class:"md-clipboard md-icon",title:Ee("clipboard.copy"),"data-clipboard-target":`#${e} > code`})}var Ln=Mt(qr());function Qr(e,t){let r=t&2,o=t&1,n=Object.keys(e.terms).filter(p=>!e.terms[p]).reduce((p,c)=>[...p,x("del",null,(0,Ln.default)(c))," "],[]).slice(0,-1),i=xe(),a=new URL(e.location,i.base);B("search.highlight")&&a.searchParams.set("h",Object.entries(e.terms).filter(([,p])=>p).reduce((p,[c])=>`${p} ${c}`.trim(),""));let{tags:s}=xe();return x("a",{href:`${a}`,class:"md-search-result__link",tabIndex:-1},x("article",{class:"md-search-result__article md-typeset","data-md-score":e.score.toFixed(2)},r>0&&x("div",{class:"md-search-result__icon md-icon"}),r>0&&x("h1",null,e.title),r<=0&&x("h2",null,e.title),o>0&&e.text.length>0&&e.text,e.tags&&x("nav",{class:"md-tags"},e.tags.map(p=>{let c=s?p in s?`md-tag-icon md-tag--${s[p]}`:"md-tag-icon":"";return x("span",{class:`md-tag ${c}`},p)})),o>0&&n.length>0&&x("p",{class:"md-search-result__terms"},Ee("search.result.term.missing"),": ",...n)))}function Mn(e){let t=e[0].score,r=[...e],o=xe(),n=r.findIndex(l=>!`${new URL(l.location,o.base)}`.includes("#")),[i]=r.splice(n,1),a=r.findIndex(l=>l.score<t);a===-1&&(a=r.length);let s=r.slice(0,a),p=r.slice(a),c=[Qr(i,2|+(!n&&a===0)),...s.map(l=>Qr(l,1)),...p.length?[x("details",{class:"md-search-result__more"},x("summary",{tabIndex:-1},x("div",null,p.length>0&&p.length===1?Ee("search.result.more.one"):Ee("search.result.more.other",p.length))),...p.map(l=>Qr(l,1)))]:[]];return x("li",{class:"md-search-result__item"},c)}function _n(e){return x("ul",{class:"md-source__facts"},Object.entries(e).map(([t,r])=>x("li",{class:`md-source__fact md-source__fact--${t}`},typeof r=="number"?sr(r):r)))}function Kr(e){let t=`tabbed-control tabbed-control--${e}`;return x("div",{class:t,hidden:!0},x("button",{class:"tabbed-button",tabIndex:-1,"aria-hidden":"true"}))}function An(e){return x("div",{class:"md-typeset__scrollwrap"},x("div",{class:"md-typeset__table"},e))}function Ra(e){var o;let t=xe(),r=new URL(`../${e.version}/`,t.base);return x("li",{class:"md-version__item"},x("a",{href:`${r}`,class:"md-version__link"},e.title,((o=t.version)==null?void 0:o.alias)&&e.aliases.length>0&&x("span",{class:"md-version__alias"},e.aliases[0])))}function Cn(e,t){var o;let r=xe();return e=e.filter(n=>{var i;return!((i=n.properties)!=null&&i.hidden)}),x("div",{class:"md-version"},x("button",{class:"md-version__current","aria-label":Ee("select.version")},t.title,((o=r.version)==null?void 0:o.alias)&&t.aliases.length>0&&x("span",{class:"md-version__alias"},t.aliases[0])),x("ul",{class:"md-version__list"},e.map(Ra)))}var Ia=0;function ja(e){let t=z([et(e),$t(e)]).pipe(m(([o,n])=>o||n),K()),r=C(()=>Zo(e)).pipe(ne(Ne),pt(1),He(t),m(()=>en(e)));return t.pipe(Ae(o=>o),v(()=>z([t,r])),m(([o,n])=>({active:o,offset:n})),pe())}function Fa(e,t){let{content$:r,viewport$:o}=t,n=`__tooltip2_${Ia++}`;return C(()=>{let i=new g,a=new _r(!1);i.pipe(Z(),ie(!1)).subscribe(a);let s=a.pipe(Ht(c=>Le(+!c*250,kr)),K(),v(c=>c?r:S),w(c=>c.id=n),pe());z([i.pipe(m(({active:c})=>c)),s.pipe(v(c=>$t(c,250)),Q(!1))]).pipe(m(c=>c.some(l=>l))).subscribe(a);let p=a.pipe(b(c=>c),re(s,o),m(([c,l,{size:f}])=>{let u=e.getBoundingClientRect(),d=u.width/2;if(l.role==="tooltip")return{x:d,y:8+u.height};if(u.y>=f.height/2){let{height:y}=ce(l);return{x:d,y:-16-y}}else return{x:d,y:16+u.height}}));return z([s,i,p]).subscribe(([c,{offset:l},f])=>{c.style.setProperty("--md-tooltip-host-x",`${l.x}px`),c.style.setProperty("--md-tooltip-host-y",`${l.y}px`),c.style.setProperty("--md-tooltip-x",`${f.x}px`),c.style.setProperty("--md-tooltip-y",`${f.y}px`),c.classList.toggle("md-tooltip2--top",f.y<0),c.classList.toggle("md-tooltip2--bottom",f.y>=0)}),a.pipe(b(c=>c),re(s,(c,l)=>l),b(c=>c.role==="tooltip")).subscribe(c=>{let l=ce(R(":scope > *",c));c.style.setProperty("--md-tooltip-width",`${l.width}px`),c.style.setProperty("--md-tooltip-tail","0px")}),a.pipe(K(),ve(me),re(s)).subscribe(([c,l])=>{l.classList.toggle("md-tooltip2--active",c)}),z([a.pipe(b(c=>c)),s]).subscribe(([c,l])=>{l.role==="dialog"?(e.setAttribute("aria-controls",n),e.setAttribute("aria-haspopup","dialog")):e.setAttribute("aria-describedby",n)}),a.pipe(b(c=>!c)).subscribe(()=>{e.removeAttribute("aria-controls"),e.removeAttribute("aria-describedby"),e.removeAttribute("aria-haspopup")}),ja(e).pipe(w(c=>i.next(c)),_(()=>i.complete()),m(c=>$({ref:e},c)))})}function mt(e,{viewport$:t},r=document.body){return Fa(e,{content$:new j(o=>{let n=e.title,i=wn(n);return o.next(i),e.removeAttribute("title"),r.append(i),()=>{i.remove(),e.setAttribute("title",n)}}),viewport$:t})}function Ua(e,t){let r=C(()=>z([tn(e),Ne(t)])).pipe(m(([{x:o,y:n},i])=>{let{width:a,height:s}=ce(e);return{x:o-i.x+a/2,y:n-i.y+s/2}}));return et(e).pipe(v(o=>r.pipe(m(n=>({active:o,offset:n})),Te(+!o||1/0))))}function kn(e,t,{target$:r}){let[o,n]=Array.from(e.children);return C(()=>{let i=new g,a=i.pipe(Z(),ie(!0));return i.subscribe({next({offset:s}){e.style.setProperty("--md-tooltip-x",`${s.x}px`),e.style.setProperty("--md-tooltip-y",`${s.y}px`)},complete(){e.style.removeProperty("--md-tooltip-x"),e.style.removeProperty("--md-tooltip-y")}}),tt(e).pipe(W(a)).subscribe(s=>{e.toggleAttribute("data-md-visible",s)}),O(i.pipe(b(({active:s})=>s)),i.pipe(_e(250),b(({active:s})=>!s))).subscribe({next({active:s}){s?e.prepend(o):o.remove()},complete(){e.prepend(o)}}),i.pipe(Me(16,me)).subscribe(({active:s})=>{o.classList.toggle("md-tooltip--active",s)}),i.pipe(pt(125,me),b(()=>!!e.offsetParent),m(()=>e.offsetParent.getBoundingClientRect()),m(({x:s})=>s)).subscribe({next(s){s?e.style.setProperty("--md-tooltip-0",`${-s}px`):e.style.removeProperty("--md-tooltip-0")},complete(){e.style.removeProperty("--md-tooltip-0")}}),h(n,"click").pipe(W(a),b(s=>!(s.metaKey||s.ctrlKey))).subscribe(s=>{s.stopPropagation(),s.preventDefault()}),h(n,"mousedown").pipe(W(a),re(i)).subscribe(([s,{active:p}])=>{var c;if(s.button!==0||s.metaKey||s.ctrlKey)s.preventDefault();else if(p){s.preventDefault();let l=e.parentElement.closest(".md-annotation");l instanceof HTMLElement?l.focus():(c=Ie())==null||c.blur()}}),r.pipe(W(a),b(s=>s===o),Ge(125)).subscribe(()=>e.focus()),Ua(e,t).pipe(w(s=>i.next(s)),_(()=>i.complete()),m(s=>$({ref:e},s)))})}function Wa(e){return e.tagName==="CODE"?P(".c, .c1, .cm",e):[e]}function Da(e){let t=[];for(let r of Wa(e)){let o=[],n=document.createNodeIterator(r,NodeFilter.SHOW_TEXT);for(let i=n.nextNode();i;i=n.nextNode())o.push(i);for(let i of o){let a;for(;a=/(\(\d+\))(!)?/.exec(i.textContent);){let[,s,p]=a;if(typeof p=="undefined"){let c=i.splitText(a.index);i=c.splitText(s.length),t.push(c)}else{i.textContent=s,t.push(i);break}}}}return t}function Hn(e,t){t.append(...Array.from(e.childNodes))}function fr(e,t,{target$:r,print$:o}){let n=t.closest("[id]"),i=n==null?void 0:n.id,a=new Map;for(let s of Da(t)){let[,p]=s.textContent.match(/\((\d+)\)/);fe(`:scope > li:nth-child(${p})`,e)&&(a.set(p,Tn(p,i)),s.replaceWith(a.get(p)))}return a.size===0?S:C(()=>{let s=new g,p=s.pipe(Z(),ie(!0)),c=[];for(let[l,f]of a)c.push([R(".md-typeset",f),R(`:scope > li:nth-child(${l})`,e)]);return o.pipe(W(p)).subscribe(l=>{e.hidden=!l,e.classList.toggle("md-annotation-list",l);for(let[f,u]of c)l?Hn(f,u):Hn(u,f)}),O(...[...a].map(([,l])=>kn(l,t,{target$:r}))).pipe(_(()=>s.complete()),pe())})}function $n(e){if(e.nextElementSibling){let t=e.nextElementSibling;if(t.tagName==="OL")return t;if(t.tagName==="P"&&!t.children.length)return $n(t)}}function Pn(e,t){return C(()=>{let r=$n(e);return typeof r!="undefined"?fr(r,e,t):S})}var Rn=Mt(Br());var Va=0;function In(e){if(e.nextElementSibling){let t=e.nextElementSibling;if(t.tagName==="OL")return t;if(t.tagName==="P"&&!t.children.length)return In(t)}}function Na(e){return ge(e).pipe(m(({width:t})=>({scrollable:St(e).width>t})),ee("scrollable"))}function jn(e,t){let{matches:r}=matchMedia("(hover)"),o=C(()=>{let n=new g,i=n.pipe(jr(1));n.subscribe(({scrollable:c})=>{c&&r?e.setAttribute("tabindex","0"):e.removeAttribute("tabindex")});let a=[];if(Rn.default.isSupported()&&(e.closest(".copy")||B("content.code.copy")&&!e.closest(".no-copy"))){let c=e.closest("pre");c.id=`__code_${Va++}`;let l=Sn(c.id);c.insertBefore(l,e),B("content.tooltips")&&a.push(mt(l,{viewport$}))}let s=e.closest(".highlight");if(s instanceof HTMLElement){let c=In(s);if(typeof c!="undefined"&&(s.classList.contains("annotate")||B("content.code.annotate"))){let l=fr(c,e,t);a.push(ge(s).pipe(W(i),m(({width:f,height:u})=>f&&u),K(),v(f=>f?l:S)))}}return P(":scope > span[id]",e).length&&e.classList.add("md-code__content"),Na(e).pipe(w(c=>n.next(c)),_(()=>n.complete()),m(c=>$({ref:e},c)),Re(...a))});return B("content.lazy")?tt(e).pipe(b(n=>n),Te(1),v(()=>o)):o}function za(e,{target$:t,print$:r}){let o=!0;return O(t.pipe(m(n=>n.closest("details:not([open])")),b(n=>e===n),m(()=>({action:"open",reveal:!0}))),r.pipe(b(n=>n||!o),w(()=>o=e.open),m(n=>({action:n?"open":"close"}))))}function Fn(e,t){return C(()=>{let r=new g;return r.subscribe(({action:o,reveal:n})=>{e.toggleAttribute("open",o==="open"),n&&e.scrollIntoView()}),za(e,t).pipe(w(o=>r.next(o)),_(()=>r.complete()),m(o=>$({ref:e},o)))})}var Un=".node circle,.node ellipse,.node path,.node polygon,.node rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}marker{fill:var(--md-mermaid-edge-color)!important}.edgeLabel .label rect{fill:#0000}.label{color:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.label foreignObject{line-height:normal;overflow:visible}.label div .edgeLabel{color:var(--md-mermaid-label-fg-color)}.edgeLabel,.edgeLabel p,.label div .edgeLabel{background-color:var(--md-mermaid-label-bg-color)}.edgeLabel,.edgeLabel p{fill:var(--md-mermaid-label-bg-color);color:var(--md-mermaid-edge-color)}.edgePath .path,.flowchart-link{stroke:var(--md-mermaid-edge-color);stroke-width:.05rem}.edgePath .arrowheadPath{fill:var(--md-mermaid-edge-color);stroke:none}.cluster rect{fill:var(--md-default-fg-color--lightest);stroke:var(--md-default-fg-color--lighter)}.cluster span{color:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}g #flowchart-circleEnd,g #flowchart-circleStart,g #flowchart-crossEnd,g #flowchart-crossStart,g #flowchart-pointEnd,g #flowchart-pointStart{stroke:none}g.classGroup line,g.classGroup rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}g.classGroup text{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.classLabel .box{fill:var(--md-mermaid-label-bg-color);background-color:var(--md-mermaid-label-bg-color);opacity:1}.classLabel .label{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.node .divider{stroke:var(--md-mermaid-node-fg-color)}.relation{stroke:var(--md-mermaid-edge-color)}.cardinality{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.cardinality text{fill:inherit!important}defs #classDiagram-compositionEnd,defs #classDiagram-compositionStart,defs #classDiagram-dependencyEnd,defs #classDiagram-dependencyStart,defs #classDiagram-extensionEnd,defs #classDiagram-extensionStart{fill:var(--md-mermaid-edge-color)!important;stroke:var(--md-mermaid-edge-color)!important}defs #classDiagram-aggregationEnd,defs #classDiagram-aggregationStart{fill:var(--md-mermaid-label-bg-color)!important;stroke:var(--md-mermaid-edge-color)!important}g.stateGroup rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}g.stateGroup .state-title{fill:var(--md-mermaid-label-fg-color)!important;font-family:var(--md-mermaid-font-family)}g.stateGroup .composit{fill:var(--md-mermaid-label-bg-color)}.nodeLabel,.nodeLabel p{color:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}a .nodeLabel{text-decoration:underline}.node circle.state-end,.node circle.state-start,.start-state{fill:var(--md-mermaid-edge-color);stroke:none}.end-state-inner,.end-state-outer{fill:var(--md-mermaid-edge-color)}.end-state-inner,.node circle.state-end{stroke:var(--md-mermaid-label-bg-color)}.transition{stroke:var(--md-mermaid-edge-color)}[id^=state-fork] rect,[id^=state-join] rect{fill:var(--md-mermaid-edge-color)!important;stroke:none!important}.statediagram-cluster.statediagram-cluster .inner{fill:var(--md-default-bg-color)}.statediagram-cluster rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}.statediagram-state rect.divider{fill:var(--md-default-fg-color--lightest);stroke:var(--md-default-fg-color--lighter)}defs #statediagram-barbEnd{stroke:var(--md-mermaid-edge-color)}.attributeBoxEven,.attributeBoxOdd{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}.entityBox{fill:var(--md-mermaid-label-bg-color);stroke:var(--md-mermaid-node-fg-color)}.entityLabel{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.relationshipLabelBox{fill:var(--md-mermaid-label-bg-color);fill-opacity:1;background-color:var(--md-mermaid-label-bg-color);opacity:1}.relationshipLabel{fill:var(--md-mermaid-label-fg-color)}.relationshipLine{stroke:var(--md-mermaid-edge-color)}defs #ONE_OR_MORE_END *,defs #ONE_OR_MORE_START *,defs #ONLY_ONE_END *,defs #ONLY_ONE_START *,defs #ZERO_OR_MORE_END *,defs #ZERO_OR_MORE_START *,defs #ZERO_OR_ONE_END *,defs #ZERO_OR_ONE_START *{stroke:var(--md-mermaid-edge-color)!important}defs #ZERO_OR_MORE_END circle,defs #ZERO_OR_MORE_START circle{fill:var(--md-mermaid-label-bg-color)}.actor{fill:var(--md-mermaid-sequence-actor-bg-color);stroke:var(--md-mermaid-sequence-actor-border-color)}text.actor>tspan{fill:var(--md-mermaid-sequence-actor-fg-color);font-family:var(--md-mermaid-font-family)}line{stroke:var(--md-mermaid-sequence-actor-line-color)}.actor-man circle,.actor-man line{fill:var(--md-mermaid-sequence-actorman-bg-color);stroke:var(--md-mermaid-sequence-actorman-line-color)}.messageLine0,.messageLine1{stroke:var(--md-mermaid-sequence-message-line-color)}.note{fill:var(--md-mermaid-sequence-note-bg-color);stroke:var(--md-mermaid-sequence-note-border-color)}.loopText,.loopText>tspan,.messageText,.noteText>tspan{stroke:none;font-family:var(--md-mermaid-font-family)!important}.messageText{fill:var(--md-mermaid-sequence-message-fg-color)}.loopText,.loopText>tspan{fill:var(--md-mermaid-sequence-loop-fg-color)}.noteText>tspan{fill:var(--md-mermaid-sequence-note-fg-color)}#arrowhead path{fill:var(--md-mermaid-sequence-message-line-color);stroke:none}.loopLine{fill:var(--md-mermaid-sequence-loop-bg-color);stroke:var(--md-mermaid-sequence-loop-border-color)}.labelBox{fill:var(--md-mermaid-sequence-label-bg-color);stroke:none}.labelText,.labelText>span{fill:var(--md-mermaid-sequence-label-fg-color);font-family:var(--md-mermaid-font-family)}.sequenceNumber{fill:var(--md-mermaid-sequence-number-fg-color)}rect.rect{fill:var(--md-mermaid-sequence-box-bg-color);stroke:none}rect.rect+text.text{fill:var(--md-mermaid-sequence-box-fg-color)}defs #sequencenumber{fill:var(--md-mermaid-sequence-number-bg-color)!important}";var Gr,Qa=0;function Ka(){return typeof mermaid=="undefined"||mermaid instanceof Element?Tt("https://unpkg.com/mermaid@11/dist/mermaid.min.js"):I(void 0)}function Wn(e){return e.classList.remove("mermaid"),Gr||(Gr=Ka().pipe(w(()=>mermaid.initialize({startOnLoad:!1,themeCSS:Un,sequence:{actorFontSize:"16px",messageFontSize:"16px",noteFontSize:"16px"}})),m(()=>{}),G(1))),Gr.subscribe(()=>co(this,null,function*(){e.classList.add("mermaid");let t=`__mermaid_${Qa++}`,r=x("div",{class:"mermaid"}),o=e.textContent,{svg:n,fn:i}=yield mermaid.render(t,o),a=r.attachShadow({mode:"closed"});a.innerHTML=n,e.replaceWith(r),i==null||i(a)})),Gr.pipe(m(()=>({ref:e})))}var Dn=x("table");function Vn(e){return e.replaceWith(Dn),Dn.replaceWith(An(e)),I({ref:e})}function Ya(e){let t=e.find(r=>r.checked)||e[0];return O(...e.map(r=>h(r,"change").pipe(m(()=>R(`label[for="${r.id}"]`))))).pipe(Q(R(`label[for="${t.id}"]`)),m(r=>({active:r})))}function Nn(e,{viewport$:t,target$:r}){let o=R(".tabbed-labels",e),n=P(":scope > input",e),i=Kr("prev");e.append(i);let a=Kr("next");return e.append(a),C(()=>{let s=new g,p=s.pipe(Z(),ie(!0));z([s,ge(e),tt(e)]).pipe(W(p),Me(1,me)).subscribe({next([{active:c},l]){let f=Ve(c),{width:u}=ce(c);e.style.setProperty("--md-indicator-x",`${f.x}px`),e.style.setProperty("--md-indicator-width",`${u}px`);let d=pr(o);(f.x<d.x||f.x+u>d.x+l.width)&&o.scrollTo({left:Math.max(0,f.x-16),behavior:"smooth"})},complete(){e.style.removeProperty("--md-indicator-x"),e.style.removeProperty("--md-indicator-width")}}),z([Ne(o),ge(o)]).pipe(W(p)).subscribe(([c,l])=>{let f=St(o);i.hidden=c.x<16,a.hidden=c.x>f.width-l.width-16}),O(h(i,"click").pipe(m(()=>-1)),h(a,"click").pipe(m(()=>1))).pipe(W(p)).subscribe(c=>{let{width:l}=ce(o);o.scrollBy({left:l*c,behavior:"smooth"})}),r.pipe(W(p),b(c=>n.includes(c))).subscribe(c=>c.click()),o.classList.add("tabbed-labels--linked");for(let c of n){let l=R(`label[for="${c.id}"]`);l.replaceChildren(x("a",{href:`#${l.htmlFor}`,tabIndex:-1},...Array.from(l.childNodes))),h(l.firstElementChild,"click").pipe(W(p),b(f=>!(f.metaKey||f.ctrlKey)),w(f=>{f.preventDefault(),f.stopPropagation()})).subscribe(()=>{history.replaceState({},"",`#${l.htmlFor}`),l.click()})}return B("content.tabs.link")&&s.pipe(Ce(1),re(t)).subscribe(([{active:c},{offset:l}])=>{let f=c.innerText.trim();if(c.hasAttribute("data-md-switching"))c.removeAttribute("data-md-switching");else{let u=e.offsetTop-l.y;for(let y of P("[data-tabs]"))for(let L of P(":scope > input",y)){let X=R(`label[for="${L.id}"]`);if(X!==c&&X.innerText.trim()===f){X.setAttribute("data-md-switching",""),L.click();break}}window.scrollTo({top:e.offsetTop-u});let d=__md_get("__tabs")||[];__md_set("__tabs",[...new Set([f,...d])])}}),s.pipe(W(p)).subscribe(()=>{for(let c of P("audio, video",e))c.pause()}),Ya(n).pipe(w(c=>s.next(c)),_(()=>s.complete()),m(c=>$({ref:e},c)))}).pipe(Ke(se))}function zn(e,{viewport$:t,target$:r,print$:o}){return O(...P(".annotate:not(.highlight)",e).map(n=>Pn(n,{target$:r,print$:o})),...P("pre:not(.mermaid) > code",e).map(n=>jn(n,{target$:r,print$:o})),...P("pre.mermaid",e).map(n=>Wn(n)),...P("table:not([class])",e).map(n=>Vn(n)),...P("details",e).map(n=>Fn(n,{target$:r,print$:o})),...P("[data-tabs]",e).map(n=>Nn(n,{viewport$:t,target$:r})),...P("[title]",e).filter(()=>B("content.tooltips")).map(n=>mt(n,{viewport$:t})))}function Ba(e,{alert$:t}){return t.pipe(v(r=>O(I(!0),I(!1).pipe(Ge(2e3))).pipe(m(o=>({message:r,active:o})))))}function qn(e,t){let r=R(".md-typeset",e);return C(()=>{let o=new g;return o.subscribe(({message:n,active:i})=>{e.classList.toggle("md-dialog--active",i),r.textContent=n}),Ba(e,t).pipe(w(n=>o.next(n)),_(()=>o.complete()),m(n=>$({ref:e},n)))})}var Ga=0;function Ja(e,t){document.body.append(e);let{width:r}=ce(e);e.style.setProperty("--md-tooltip-width",`${r}px`),e.remove();let o=cr(t),n=typeof o!="undefined"?Ne(o):I({x:0,y:0}),i=O(et(t),$t(t)).pipe(K());return z([i,n]).pipe(m(([a,s])=>{let{x:p,y:c}=Ve(t),l=ce(t),f=t.closest("table");return f&&t.parentElement&&(p+=f.offsetLeft+t.parentElement.offsetLeft,c+=f.offsetTop+t.parentElement.offsetTop),{active:a,offset:{x:p-s.x+l.width/2-r/2,y:c-s.y+l.height+8}}}))}function Qn(e){let t=e.title;if(!t.length)return S;let r=`__tooltip_${Ga++}`,o=Rt(r,"inline"),n=R(".md-typeset",o);return n.innerHTML=t,C(()=>{let i=new g;return i.subscribe({next({offset:a}){o.style.setProperty("--md-tooltip-x",`${a.x}px`),o.style.setProperty("--md-tooltip-y",`${a.y}px`)},complete(){o.style.removeProperty("--md-tooltip-x"),o.style.removeProperty("--md-tooltip-y")}}),O(i.pipe(b(({active:a})=>a)),i.pipe(_e(250),b(({active:a})=>!a))).subscribe({next({active:a}){a?(e.insertAdjacentElement("afterend",o),e.setAttribute("aria-describedby",r),e.removeAttribute("title")):(o.remove(),e.removeAttribute("aria-describedby"),e.setAttribute("title",t))},complete(){o.remove(),e.removeAttribute("aria-describedby"),e.setAttribute("title",t)}}),i.pipe(Me(16,me)).subscribe(({active:a})=>{o.classList.toggle("md-tooltip--active",a)}),i.pipe(pt(125,me),b(()=>!!e.offsetParent),m(()=>e.offsetParent.getBoundingClientRect()),m(({x:a})=>a)).subscribe({next(a){a?o.style.setProperty("--md-tooltip-0",`${-a}px`):o.style.removeProperty("--md-tooltip-0")},complete(){o.style.removeProperty("--md-tooltip-0")}}),Ja(o,e).pipe(w(a=>i.next(a)),_(()=>i.complete()),m(a=>$({ref:e},a)))}).pipe(Ke(se))}function Xa({viewport$:e}){if(!B("header.autohide"))return I(!1);let t=e.pipe(m(({offset:{y:n}})=>n),Be(2,1),m(([n,i])=>[n<i,i]),ee(0)),r=z([e,t]).pipe(b(([{offset:n},[,i]])=>Math.abs(i-n.y)>100),m(([,[n]])=>n),K()),o=ze("search");return z([e,o]).pipe(m(([{offset:n},i])=>n.y>400&&!i),K(),v(n=>n?r:I(!1)),Q(!1))}function Kn(e,t){return C(()=>z([ge(e),Xa(t)])).pipe(m(([{height:r},o])=>({height:r,hidden:o})),K((r,o)=>r.height===o.height&&r.hidden===o.hidden),G(1))}function Yn(e,{header$:t,main$:r}){return C(()=>{let o=new g,n=o.pipe(Z(),ie(!0));o.pipe(ee("active"),He(t)).subscribe(([{active:a},{hidden:s}])=>{e.classList.toggle("md-header--shadow",a&&!s),e.hidden=s});let i=ue(P("[title]",e)).pipe(b(()=>B("content.tooltips")),ne(a=>Qn(a)));return r.subscribe(o),t.pipe(W(n),m(a=>$({ref:e},a)),Re(i.pipe(W(n))))})}function Za(e,{viewport$:t,header$:r}){return mr(e,{viewport$:t,header$:r}).pipe(m(({offset:{y:o}})=>{let{height:n}=ce(e);return{active:o>=n}}),ee("active"))}function Bn(e,t){return C(()=>{let r=new g;r.subscribe({next({active:n}){e.classList.toggle("md-header__title--active",n)},complete(){e.classList.remove("md-header__title--active")}});let o=fe(".md-content h1");return typeof o=="undefined"?S:Za(o,t).pipe(w(n=>r.next(n)),_(()=>r.complete()),m(n=>$({ref:e},n)))})}function Gn(e,{viewport$:t,header$:r}){let o=r.pipe(m(({height:i})=>i),K()),n=o.pipe(v(()=>ge(e).pipe(m(({height:i})=>({top:e.offsetTop,bottom:e.offsetTop+i})),ee("bottom"))));return z([o,n,t]).pipe(m(([i,{top:a,bottom:s},{offset:{y:p},size:{height:c}}])=>(c=Math.max(0,c-Math.max(0,a-p,i)-Math.max(0,c+p-s)),{offset:a-i,height:c,active:a-i<=p})),K((i,a)=>i.offset===a.offset&&i.height===a.height&&i.active===a.active))}function es(e){let t=__md_get("__palette")||{index:e.findIndex(o=>matchMedia(o.getAttribute("data-md-color-media")).matches)},r=Math.max(0,Math.min(t.index,e.length-1));return I(...e).pipe(ne(o=>h(o,"change").pipe(m(()=>o))),Q(e[r]),m(o=>({index:e.indexOf(o),color:{media:o.getAttribute("data-md-color-media"),scheme:o.getAttribute("data-md-color-scheme"),primary:o.getAttribute("data-md-color-primary"),accent:o.getAttribute("data-md-color-accent")}})),G(1))}function Jn(e){let t=P("input",e),r=x("meta",{name:"theme-color"});document.head.appendChild(r);let o=x("meta",{name:"color-scheme"});document.head.appendChild(o);let n=Pt("(prefers-color-scheme: light)");return C(()=>{let i=new g;return i.subscribe(a=>{if(document.body.setAttribute("data-md-color-switching",""),a.color.media==="(prefers-color-scheme)"){let s=matchMedia("(prefers-color-scheme: light)"),p=document.querySelector(s.matches?"[data-md-color-media='(prefers-color-scheme: light)']":"[data-md-color-media='(prefers-color-scheme: dark)']");a.color.scheme=p.getAttribute("data-md-color-scheme"),a.color.primary=p.getAttribute("data-md-color-primary"),a.color.accent=p.getAttribute("data-md-color-accent")}for(let[s,p]of Object.entries(a.color))document.body.setAttribute(`data-md-color-${s}`,p);for(let s=0;s<t.length;s++){let p=t[s].nextElementSibling;p instanceof HTMLElement&&(p.hidden=a.index!==s)}__md_set("__palette",a)}),h(e,"keydown").pipe(b(a=>a.key==="Enter"),re(i,(a,s)=>s)).subscribe(({index:a})=>{a=(a+1)%t.length,t[a].click(),t[a].focus()}),i.pipe(m(()=>{let a=Se("header"),s=window.getComputedStyle(a);return o.content=s.colorScheme,s.backgroundColor.match(/\d+/g).map(p=>(+p).toString(16).padStart(2,"0")).join("")})).subscribe(a=>r.content=`#${a}`),i.pipe(ve(se)).subscribe(()=>{document.body.removeAttribute("data-md-color-switching")}),es(t).pipe(W(n.pipe(Ce(1))),ct(),w(a=>i.next(a)),_(()=>i.complete()),m(a=>$({ref:e},a)))})}function Xn(e,{progress$:t}){return C(()=>{let r=new g;return r.subscribe(({value:o})=>{e.style.setProperty("--md-progress-value",`${o}`)}),t.pipe(w(o=>r.next({value:o})),_(()=>r.complete()),m(o=>({ref:e,value:o})))})}var Jr=Mt(Br());function ts(e){e.setAttribute("data-md-copying","");let t=e.closest("[data-copy]"),r=t?t.getAttribute("data-copy"):e.innerText;return e.removeAttribute("data-md-copying"),r.trimEnd()}function Zn({alert$:e}){Jr.default.isSupported()&&new j(t=>{new Jr.default("[data-clipboard-target], [data-clipboard-text]",{text:r=>r.getAttribute("data-clipboard-text")||ts(R(r.getAttribute("data-clipboard-target")))}).on("success",r=>t.next(r))}).pipe(w(t=>{t.trigger.focus()}),m(()=>Ee("clipboard.copied"))).subscribe(e)}function ei(e,t){return e.protocol=t.protocol,e.hostname=t.hostname,e}function rs(e,t){let r=new Map;for(let o of P("url",e)){let n=R("loc",o),i=[ei(new URL(n.textContent),t)];r.set(`${i[0]}`,i);for(let a of P("[rel=alternate]",o)){let s=a.getAttribute("href");s!=null&&i.push(ei(new URL(s),t))}}return r}function ur(e){return un(new URL("sitemap.xml",e)).pipe(m(t=>rs(t,new URL(e))),de(()=>I(new Map)))}function os(e,t){if(!(e.target instanceof Element))return S;let r=e.target.closest("a");if(r===null)return S;if(r.target||e.metaKey||e.ctrlKey)return S;let o=new URL(r.href);return o.search=o.hash="",t.has(`${o}`)?(e.preventDefault(),I(new URL(r.href))):S}function ti(e){let t=new Map;for(let r of P(":scope > *",e.head))t.set(r.outerHTML,r);return t}function ri(e){for(let t of P("[href], [src]",e))for(let r of["href","src"]){let o=t.getAttribute(r);if(o&&!/^(?:[a-z]+:)?\/\//i.test(o)){t[r]=t[r];break}}return I(e)}function ns(e){for(let o of["[data-md-component=announce]","[data-md-component=container]","[data-md-component=header-topic]","[data-md-component=outdated]","[data-md-component=logo]","[data-md-component=skip]",...B("navigation.tabs.sticky")?["[data-md-component=tabs]"]:[]]){let n=fe(o),i=fe(o,e);typeof n!="undefined"&&typeof i!="undefined"&&n.replaceWith(i)}let t=ti(document);for(let[o,n]of ti(e))t.has(o)?t.delete(o):document.head.appendChild(n);for(let o of t.values()){let n=o.getAttribute("name");n!=="theme-color"&&n!=="color-scheme"&&o.remove()}let r=Se("container");return We(P("script",r)).pipe(v(o=>{let n=e.createElement("script");if(o.src){for(let i of o.getAttributeNames())n.setAttribute(i,o.getAttribute(i));return o.replaceWith(n),new j(i=>{n.onload=()=>i.complete()})}else return n.textContent=o.textContent,o.replaceWith(n),S}),Z(),ie(document))}function oi({location$:e,viewport$:t,progress$:r}){let o=xe();if(location.protocol==="file:")return S;let n=ur(o.base);I(document).subscribe(ri);let i=h(document.body,"click").pipe(He(n),v(([p,c])=>os(p,c)),pe()),a=h(window,"popstate").pipe(m(ye),pe());i.pipe(re(t)).subscribe(([p,{offset:c}])=>{history.replaceState(c,""),history.pushState(null,"",p)}),O(i,a).subscribe(e);let s=e.pipe(ee("pathname"),v(p=>fn(p,{progress$:r}).pipe(de(()=>(lt(p,!0),S)))),v(ri),v(ns),pe());return O(s.pipe(re(e,(p,c)=>c)),s.pipe(v(()=>e),ee("pathname"),v(()=>e),ee("hash")),e.pipe(K((p,c)=>p.pathname===c.pathname&&p.hash===c.hash),v(()=>i),w(()=>history.back()))).subscribe(p=>{var c,l;history.state!==null||!p.hash?window.scrollTo(0,(l=(c=history.state)==null?void 0:c.y)!=null?l:0):(history.scrollRestoration="auto",pn(p.hash),history.scrollRestoration="manual")}),e.subscribe(()=>{history.scrollRestoration="manual"}),h(window,"beforeunload").subscribe(()=>{history.scrollRestoration="auto"}),t.pipe(ee("offset"),_e(100)).subscribe(({offset:p})=>{history.replaceState(p,"")}),s}var ni=Mt(qr());function ii(e){let t=e.separator.split("|").map(n=>n.replace(/(\(\?[!=<][^)]+\))/g,"").length===0?"\uFFFD":n).join("|"),r=new RegExp(t,"img"),o=(n,i,a)=>`${i}<mark data-md-highlight>${a}</mark>`;return n=>{n=n.replace(/[\s*+\-:~^]+/g," ").trim();let i=new RegExp(`(^|${e.separator}|)(${n.replace(/[|\\{}()[\]^$+*?.-]/g,"\\$&").replace(r,"|")})`,"img");return a=>(0,ni.default)(a).replace(i,o).replace(/<\/mark>(\s+)<mark[^>]*>/img,"$1")}}function jt(e){return e.type===1}function dr(e){return e.type===3}function ai(e,t){let r=yn(e);return O(I(location.protocol!=="file:"),ze("search")).pipe(Ae(o=>o),v(()=>t)).subscribe(({config:o,docs:n})=>r.next({type:0,data:{config:o,docs:n,options:{suggest:B("search.suggest")}}})),r}function si(e){var l;let{selectedVersionSitemap:t,selectedVersionBaseURL:r,currentLocation:o,currentBaseURL:n}=e,i=(l=Xr(n))==null?void 0:l.pathname;if(i===void 0)return;let a=ss(o.pathname,i);if(a===void 0)return;let s=ps(t.keys());if(!t.has(s))return;let p=Xr(a,s);if(!p||!t.has(p.href))return;let c=Xr(a,r);if(c)return c.hash=o.hash,c.search=o.search,c}function Xr(e,t){try{return new URL(e,t)}catch(r){return}}function ss(e,t){if(e.startsWith(t))return e.slice(t.length)}function cs(e,t){let r=Math.min(e.length,t.length),o;for(o=0;o<r&&e[o]===t[o];++o);return o}function ps(e){let t;for(let r of e)t===void 0?t=r:t=t.slice(0,cs(t,r));return t!=null?t:""}function ci({document$:e}){let t=xe(),r=je(new URL("../versions.json",t.base)).pipe(de(()=>S)),o=r.pipe(m(n=>{let[,i]=t.base.match(/([^/]+)\/?$/);return n.find(({version:a,aliases:s})=>a===i||s.includes(i))||n[0]}));r.pipe(m(n=>new Map(n.map(i=>[`${new URL(`../${i.version}/`,t.base)}`,i]))),v(n=>h(document.body,"click").pipe(b(i=>!i.metaKey&&!i.ctrlKey),re(o),v(([i,a])=>{if(i.target instanceof Element){let s=i.target.closest("a");if(s&&!s.target&&n.has(s.href)){let p=s.href;return!i.target.closest(".md-version")&&n.get(p)===a?S:(i.preventDefault(),I(new URL(p)))}}return S}),v(i=>ur(i).pipe(m(a=>{var s;return(s=si({selectedVersionSitemap:a,selectedVersionBaseURL:i,currentLocation:ye(),currentBaseURL:t.base}))!=null?s:i})))))).subscribe(n=>lt(n,!0)),z([r,o]).subscribe(([n,i])=>{R(".md-header__topic").appendChild(Cn(n,i))}),e.pipe(v(()=>o)).subscribe(n=>{var a;let i=__md_get("__outdated",sessionStorage);if(i===null){i=!0;let s=((a=t.version)==null?void 0:a.default)||"latest";Array.isArray(s)||(s=[s]);e:for(let p of s)for(let c of n.aliases.concat(n.version))if(new RegExp(p,"i").test(c)){i=!1;break e}__md_set("__outdated",i,sessionStorage)}if(i)for(let s of ae("outdated"))s.hidden=!1})}function ls(e,{worker$:t}){let{searchParams:r}=ye();r.has("q")&&(Je("search",!0),e.value=r.get("q"),e.focus(),ze("search").pipe(Ae(i=>!i)).subscribe(()=>{let i=ye();i.searchParams.delete("q"),history.replaceState({},"",`${i}`)}));let o=et(e),n=O(t.pipe(Ae(jt)),h(e,"keyup"),o).pipe(m(()=>e.value),K());return z([n,o]).pipe(m(([i,a])=>({value:i,focus:a})),G(1))}function pi(e,{worker$:t}){let r=new g,o=r.pipe(Z(),ie(!0));z([t.pipe(Ae(jt)),r],(i,a)=>a).pipe(ee("value")).subscribe(({value:i})=>t.next({type:2,data:i})),r.pipe(ee("focus")).subscribe(({focus:i})=>{i&&Je("search",i)}),h(e.form,"reset").pipe(W(o)).subscribe(()=>e.focus());let n=R("header [for=__search]");return h(n,"click").subscribe(()=>e.focus()),ls(e,{worker$:t}).pipe(w(i=>r.next(i)),_(()=>r.complete()),m(i=>$({ref:e},i)),G(1))}function li(e,{worker$:t,query$:r}){let o=new g,n=on(e.parentElement).pipe(b(Boolean)),i=e.parentElement,a=R(":scope > :first-child",e),s=R(":scope > :last-child",e);ze("search").subscribe(l=>s.setAttribute("role",l?"list":"presentation")),o.pipe(re(r),Wr(t.pipe(Ae(jt)))).subscribe(([{items:l},{value:f}])=>{switch(l.length){case 0:a.textContent=f.length?Ee("search.result.none"):Ee("search.result.placeholder");break;case 1:a.textContent=Ee("search.result.one");break;default:let u=sr(l.length);a.textContent=Ee("search.result.other",u)}});let p=o.pipe(w(()=>s.innerHTML=""),v(({items:l})=>O(I(...l.slice(0,10)),I(...l.slice(10)).pipe(Be(4),Vr(n),v(([f])=>f)))),m(Mn),pe());return p.subscribe(l=>s.appendChild(l)),p.pipe(ne(l=>{let f=fe("details",l);return typeof f=="undefined"?S:h(f,"toggle").pipe(W(o),m(()=>f))})).subscribe(l=>{l.open===!1&&l.offsetTop<=i.scrollTop&&i.scrollTo({top:l.offsetTop})}),t.pipe(b(dr),m(({data:l})=>l)).pipe(w(l=>o.next(l)),_(()=>o.complete()),m(l=>$({ref:e},l)))}function ms(e,{query$:t}){return t.pipe(m(({value:r})=>{let o=ye();return o.hash="",r=r.replace(/\s+/g,"+").replace(/&/g,"%26").replace(/=/g,"%3D"),o.search=`q=${r}`,{url:o}}))}function mi(e,t){let r=new g,o=r.pipe(Z(),ie(!0));return r.subscribe(({url:n})=>{e.setAttribute("data-clipboard-text",e.href),e.href=`${n}`}),h(e,"click").pipe(W(o)).subscribe(n=>n.preventDefault()),ms(e,t).pipe(w(n=>r.next(n)),_(()=>r.complete()),m(n=>$({ref:e},n)))}function fi(e,{worker$:t,keyboard$:r}){let o=new g,n=Se("search-query"),i=O(h(n,"keydown"),h(n,"focus")).pipe(ve(se),m(()=>n.value),K());return o.pipe(He(i),m(([{suggest:s},p])=>{let c=p.split(/([\s-]+)/);if(s!=null&&s.length&&c[c.length-1]){let l=s[s.length-1];l.startsWith(c[c.length-1])&&(c[c.length-1]=l)}else c.length=0;return c})).subscribe(s=>e.innerHTML=s.join("").replace(/\s/g,"&nbsp;")),r.pipe(b(({mode:s})=>s==="search")).subscribe(s=>{switch(s.type){case"ArrowRight":e.innerText.length&&n.selectionStart===n.value.length&&(n.value=e.innerText);break}}),t.pipe(b(dr),m(({data:s})=>s)).pipe(w(s=>o.next(s)),_(()=>o.complete()),m(()=>({ref:e})))}function ui(e,{index$:t,keyboard$:r}){let o=xe();try{let n=ai(o.search,t),i=Se("search-query",e),a=Se("search-result",e);h(e,"click").pipe(b(({target:p})=>p instanceof Element&&!!p.closest("a"))).subscribe(()=>Je("search",!1)),r.pipe(b(({mode:p})=>p==="search")).subscribe(p=>{let c=Ie();switch(p.type){case"Enter":if(c===i){let l=new Map;for(let f of P(":first-child [href]",a)){let u=f.firstElementChild;l.set(f,parseFloat(u.getAttribute("data-md-score")))}if(l.size){let[[f]]=[...l].sort(([,u],[,d])=>d-u);f.click()}p.claim()}break;case"Escape":case"Tab":Je("search",!1),i.blur();break;case"ArrowUp":case"ArrowDown":if(typeof c=="undefined")i.focus();else{let l=[i,...P(":not(details) > [href], summary, details[open] [href]",a)],f=Math.max(0,(Math.max(0,l.indexOf(c))+l.length+(p.type==="ArrowUp"?-1:1))%l.length);l[f].focus()}p.claim();break;default:i!==Ie()&&i.focus()}}),r.pipe(b(({mode:p})=>p==="global")).subscribe(p=>{switch(p.type){case"f":case"s":case"/":i.focus(),i.select(),p.claim();break}});let s=pi(i,{worker$:n});return O(s,li(a,{worker$:n,query$:s})).pipe(Re(...ae("search-share",e).map(p=>mi(p,{query$:s})),...ae("search-suggest",e).map(p=>fi(p,{worker$:n,keyboard$:r}))))}catch(n){return e.hidden=!0,Ye}}function di(e,{index$:t,location$:r}){return z([t,r.pipe(Q(ye()),b(o=>!!o.searchParams.get("h")))]).pipe(m(([o,n])=>ii(o.config)(n.searchParams.get("h"))),m(o=>{var a;let n=new Map,i=document.createNodeIterator(e,NodeFilter.SHOW_TEXT);for(let s=i.nextNode();s;s=i.nextNode())if((a=s.parentElement)!=null&&a.offsetHeight){let p=s.textContent,c=o(p);c.length>p.length&&n.set(s,c)}for(let[s,p]of n){let{childNodes:c}=x("span",null,p);s.replaceWith(...Array.from(c))}return{ref:e,nodes:n}}))}function fs(e,{viewport$:t,main$:r}){let o=e.closest(".md-grid"),n=o.offsetTop-o.parentElement.offsetTop;return z([r,t]).pipe(m(([{offset:i,height:a},{offset:{y:s}}])=>(a=a+Math.min(n,Math.max(0,s-i))-n,{height:a,locked:s>=i+n})),K((i,a)=>i.height===a.height&&i.locked===a.locked))}function Zr(e,o){var n=o,{header$:t}=n,r=so(n,["header$"]);let i=R(".md-sidebar__scrollwrap",e),{y:a}=Ve(i);return C(()=>{let s=new g,p=s.pipe(Z(),ie(!0)),c=s.pipe(Me(0,me));return c.pipe(re(t)).subscribe({next([{height:l},{height:f}]){i.style.height=`${l-2*a}px`,e.style.top=`${f}px`},complete(){i.style.height="",e.style.top=""}}),c.pipe(Ae()).subscribe(()=>{for(let l of P(".md-nav__link--active[href]",e)){if(!l.clientHeight)continue;let f=l.closest(".md-sidebar__scrollwrap");if(typeof f!="undefined"){let u=l.offsetTop-f.offsetTop,{height:d}=ce(f);f.scrollTo({top:u-d/2})}}}),ue(P("label[tabindex]",e)).pipe(ne(l=>h(l,"click").pipe(ve(se),m(()=>l),W(p)))).subscribe(l=>{let f=R(`[id="${l.htmlFor}"]`);R(`[aria-labelledby="${l.id}"]`).setAttribute("aria-expanded",`${f.checked}`)}),fs(e,r).pipe(w(l=>s.next(l)),_(()=>s.complete()),m(l=>$({ref:e},l)))})}function hi(e,t){if(typeof t!="undefined"){let r=`https://api.github.com/repos/${e}/${t}`;return st(je(`${r}/releases/latest`).pipe(de(()=>S),m(o=>({version:o.tag_name})),De({})),je(r).pipe(de(()=>S),m(o=>({stars:o.stargazers_count,forks:o.forks_count})),De({}))).pipe(m(([o,n])=>$($({},o),n)))}else{let r=`https://api.github.com/users/${e}`;return je(r).pipe(m(o=>({repositories:o.public_repos})),De({}))}}function bi(e,t){let r=`https://${e}/api/v4/projects/${encodeURIComponent(t)}`;return st(je(`${r}/releases/permalink/latest`).pipe(de(()=>S),m(({tag_name:o})=>({version:o})),De({})),je(r).pipe(de(()=>S),m(({star_count:o,forks_count:n})=>({stars:o,forks:n})),De({}))).pipe(m(([o,n])=>$($({},o),n)))}function vi(e){let t=e.match(/^.+github\.com\/([^/]+)\/?([^/]+)?/i);if(t){let[,r,o]=t;return hi(r,o)}if(t=e.match(/^.+?([^/]*gitlab[^/]+)\/(.+?)\/?$/i),t){let[,r,o]=t;return bi(r,o)}return S}var us;function ds(e){return us||(us=C(()=>{let t=__md_get("__source",sessionStorage);if(t)return I(t);if(ae("consent").length){let o=__md_get("__consent");if(!(o&&o.github))return S}return vi(e.href).pipe(w(o=>__md_set("__source",o,sessionStorage)))}).pipe(de(()=>S),b(t=>Object.keys(t).length>0),m(t=>({facts:t})),G(1)))}function gi(e){let t=R(":scope > :last-child",e);return C(()=>{let r=new g;return r.subscribe(({facts:o})=>{t.appendChild(_n(o)),t.classList.add("md-source__repository--active")}),ds(e).pipe(w(o=>r.next(o)),_(()=>r.complete()),m(o=>$({ref:e},o)))})}function hs(e,{viewport$:t,header$:r}){return ge(document.body).pipe(v(()=>mr(e,{header$:r,viewport$:t})),m(({offset:{y:o}})=>({hidden:o>=10})),ee("hidden"))}function yi(e,t){return C(()=>{let r=new g;return r.subscribe({next({hidden:o}){e.hidden=o},complete(){e.hidden=!1}}),(B("navigation.tabs.sticky")?I({hidden:!1}):hs(e,t)).pipe(w(o=>r.next(o)),_(()=>r.complete()),m(o=>$({ref:e},o)))})}function bs(e,{viewport$:t,header$:r}){let o=new Map,n=P(".md-nav__link",e);for(let s of n){let p=decodeURIComponent(s.hash.substring(1)),c=fe(`[id="${p}"]`);typeof c!="undefined"&&o.set(s,c)}let i=r.pipe(ee("height"),m(({height:s})=>{let p=Se("main"),c=R(":scope > :first-child",p);return s+.8*(c.offsetTop-p.offsetTop)}),pe());return ge(document.body).pipe(ee("height"),v(s=>C(()=>{let p=[];return I([...o].reduce((c,[l,f])=>{for(;p.length&&o.get(p[p.length-1]).tagName>=f.tagName;)p.pop();let u=f.offsetTop;for(;!u&&f.parentElement;)f=f.parentElement,u=f.offsetTop;let d=f.offsetParent;for(;d;d=d.offsetParent)u+=d.offsetTop;return c.set([...p=[...p,l]].reverse(),u)},new Map))}).pipe(m(p=>new Map([...p].sort(([,c],[,l])=>c-l))),He(i),v(([p,c])=>t.pipe(Fr(([l,f],{offset:{y:u},size:d})=>{let y=u+d.height>=Math.floor(s.height);for(;f.length;){let[,L]=f[0];if(L-c<u||y)l=[...l,f.shift()];else break}for(;l.length;){let[,L]=l[l.length-1];if(L-c>=u&&!y)f=[l.pop(),...f];else break}return[l,f]},[[],[...p]]),K((l,f)=>l[0]===f[0]&&l[1]===f[1])))))).pipe(m(([s,p])=>({prev:s.map(([c])=>c),next:p.map(([c])=>c)})),Q({prev:[],next:[]}),Be(2,1),m(([s,p])=>s.prev.length<p.prev.length?{prev:p.prev.slice(Math.max(0,s.prev.length-1),p.prev.length),next:[]}:{prev:p.prev.slice(-1),next:p.next.slice(0,p.next.length-s.next.length)}))}function xi(e,{viewport$:t,header$:r,main$:o,target$:n}){return C(()=>{let i=new g,a=i.pipe(Z(),ie(!0));if(i.subscribe(({prev:s,next:p})=>{for(let[c]of p)c.classList.remove("md-nav__link--passed"),c.classList.remove("md-nav__link--active");for(let[c,[l]]of s.entries())l.classList.add("md-nav__link--passed"),l.classList.toggle("md-nav__link--active",c===s.length-1)}),B("toc.follow")){let s=O(t.pipe(_e(1),m(()=>{})),t.pipe(_e(250),m(()=>"smooth")));i.pipe(b(({prev:p})=>p.length>0),He(o.pipe(ve(se))),re(s)).subscribe(([[{prev:p}],c])=>{let[l]=p[p.length-1];if(l.offsetHeight){let f=cr(l);if(typeof f!="undefined"){let u=l.offsetTop-f.offsetTop,{height:d}=ce(f);f.scrollTo({top:u-d/2,behavior:c})}}})}return B("navigation.tracking")&&t.pipe(W(a),ee("offset"),_e(250),Ce(1),W(n.pipe(Ce(1))),ct({delay:250}),re(i)).subscribe(([,{prev:s}])=>{let p=ye(),c=s[s.length-1];if(c&&c.length){let[l]=c,{hash:f}=new URL(l.href);p.hash!==f&&(p.hash=f,history.replaceState({},"",`${p}`))}else p.hash="",history.replaceState({},"",`${p}`)}),bs(e,{viewport$:t,header$:r}).pipe(w(s=>i.next(s)),_(()=>i.complete()),m(s=>$({ref:e},s)))})}function vs(e,{viewport$:t,main$:r,target$:o}){let n=t.pipe(m(({offset:{y:a}})=>a),Be(2,1),m(([a,s])=>a>s&&s>0),K()),i=r.pipe(m(({active:a})=>a));return z([i,n]).pipe(m(([a,s])=>!(a&&s)),K(),W(o.pipe(Ce(1))),ie(!0),ct({delay:250}),m(a=>({hidden:a})))}function Ei(e,{viewport$:t,header$:r,main$:o,target$:n}){let i=new g,a=i.pipe(Z(),ie(!0));return i.subscribe({next({hidden:s}){e.hidden=s,s?(e.setAttribute("tabindex","-1"),e.blur()):e.removeAttribute("tabindex")},complete(){e.style.top="",e.hidden=!0,e.removeAttribute("tabindex")}}),r.pipe(W(a),ee("height")).subscribe(({height:s})=>{e.style.top=`${s+16}px`}),h(e,"click").subscribe(s=>{s.preventDefault(),window.scrollTo({top:0})}),vs(e,{viewport$:t,main$:o,target$:n}).pipe(w(s=>i.next(s)),_(()=>i.complete()),m(s=>$({ref:e},s)))}function wi({document$:e,viewport$:t}){e.pipe(v(()=>P(".md-ellipsis")),ne(r=>tt(r).pipe(W(e.pipe(Ce(1))),b(o=>o),m(()=>r),Te(1))),b(r=>r.offsetWidth<r.scrollWidth),ne(r=>{let o=r.innerText,n=r.closest("a")||r;return n.title=o,B("content.tooltips")?mt(n,{viewport$:t}).pipe(W(e.pipe(Ce(1))),_(()=>n.removeAttribute("title"))):S})).subscribe(),B("content.tooltips")&&e.pipe(v(()=>P(".md-status")),ne(r=>mt(r,{viewport$:t}))).subscribe()}function Ti({document$:e,tablet$:t}){e.pipe(v(()=>P(".md-toggle--indeterminate")),w(r=>{r.indeterminate=!0,r.checked=!1}),ne(r=>h(r,"change").pipe(Dr(()=>r.classList.contains("md-toggle--indeterminate")),m(()=>r))),re(t)).subscribe(([r,o])=>{r.classList.remove("md-toggle--indeterminate"),o&&(r.checked=!1)})}function gs(){return/(iPad|iPhone|iPod)/.test(navigator.userAgent)}function Si({document$:e}){e.pipe(v(()=>P("[data-md-scrollfix]")),w(t=>t.removeAttribute("data-md-scrollfix")),b(gs),ne(t=>h(t,"touchstart").pipe(m(()=>t)))).subscribe(t=>{let r=t.scrollTop;r===0?t.scrollTop=1:r+t.offsetHeight===t.scrollHeight&&(t.scrollTop=r-1)})}function Oi({viewport$:e,tablet$:t}){z([ze("search"),t]).pipe(m(([r,o])=>r&&!o),v(r=>I(r).pipe(Ge(r?400:100))),re(e)).subscribe(([r,{offset:{y:o}}])=>{if(r)document.body.setAttribute("data-md-scrolllock",""),document.body.style.top=`-${o}px`;else{let n=-1*parseInt(document.body.style.top,10);document.body.removeAttribute("data-md-scrolllock"),document.body.style.top="",n&&window.scrollTo(0,n)}})}Object.entries||(Object.entries=function(e){let t=[];for(let r of Object.keys(e))t.push([r,e[r]]);return t});Object.values||(Object.values=function(e){let t=[];for(let r of Object.keys(e))t.push(e[r]);return t});typeof Element!="undefined"&&(Element.prototype.scrollTo||(Element.prototype.scrollTo=function(e,t){typeof e=="object"?(this.scrollLeft=e.left,this.scrollTop=e.top):(this.scrollLeft=e,this.scrollTop=t)}),Element.prototype.replaceWith||(Element.prototype.replaceWith=function(...e){let t=this.parentNode;if(t){e.length===0&&t.removeChild(this);for(let r=e.length-1;r>=0;r--){let o=e[r];typeof o=="string"?o=document.createTextNode(o):o.parentNode&&o.parentNode.removeChild(o),r?t.insertBefore(this.previousSibling,o):t.replaceChild(o,this)}}}));function ys(){return location.protocol==="file:"?Tt(`${new URL("search/search_index.js",eo.base)}`).pipe(m(()=>__index),G(1)):je(new URL("search/search_index.json",eo.base))}document.documentElement.classList.remove("no-js");document.documentElement.classList.add("js");var ot=Go(),Ut=sn(),Lt=ln(Ut),to=an(),Oe=gn(),hr=Pt("(min-width: 960px)"),Mi=Pt("(min-width: 1220px)"),_i=mn(),eo=xe(),Ai=document.forms.namedItem("search")?ys():Ye,ro=new g;Zn({alert$:ro});var oo=new g;B("navigation.instant")&&oi({location$:Ut,viewport$:Oe,progress$:oo}).subscribe(ot);var Li;((Li=eo.version)==null?void 0:Li.provider)==="mike"&&ci({document$:ot});O(Ut,Lt).pipe(Ge(125)).subscribe(()=>{Je("drawer",!1),Je("search",!1)});to.pipe(b(({mode:e})=>e==="global")).subscribe(e=>{switch(e.type){case"p":case",":let t=fe("link[rel=prev]");typeof t!="undefined"&&lt(t);break;case"n":case".":let r=fe("link[rel=next]");typeof r!="undefined"&&lt(r);break;case"Enter":let o=Ie();o instanceof HTMLLabelElement&&o.click()}});wi({viewport$:Oe,document$:ot});Ti({document$:ot,tablet$:hr});Si({document$:ot});Oi({viewport$:Oe,tablet$:hr});var rt=Kn(Se("header"),{viewport$:Oe}),Ft=ot.pipe(m(()=>Se("main")),v(e=>Gn(e,{viewport$:Oe,header$:rt})),G(1)),xs=O(...ae("consent").map(e=>En(e,{target$:Lt})),...ae("dialog").map(e=>qn(e,{alert$:ro})),...ae("header").map(e=>Yn(e,{viewport$:Oe,header$:rt,main$:Ft})),...ae("palette").map(e=>Jn(e)),...ae("progress").map(e=>Xn(e,{progress$:oo})),...ae("search").map(e=>ui(e,{index$:Ai,keyboard$:to})),...ae("source").map(e=>gi(e))),Es=C(()=>O(...ae("announce").map(e=>xn(e)),...ae("content").map(e=>zn(e,{viewport$:Oe,target$:Lt,print$:_i})),...ae("content").map(e=>B("search.highlight")?di(e,{index$:Ai,location$:Ut}):S),...ae("header-title").map(e=>Bn(e,{viewport$:Oe,header$:rt})),...ae("sidebar").map(e=>e.getAttribute("data-md-type")==="navigation"?Nr(Mi,()=>Zr(e,{viewport$:Oe,header$:rt,main$:Ft})):Nr(hr,()=>Zr(e,{viewport$:Oe,header$:rt,main$:Ft}))),...ae("tabs").map(e=>yi(e,{viewport$:Oe,header$:rt})),...ae("toc").map(e=>xi(e,{viewport$:Oe,header$:rt,main$:Ft,target$:Lt})),...ae("top").map(e=>Ei(e,{viewport$:Oe,header$:rt,main$:Ft,target$:Lt})))),Ci=ot.pipe(v(()=>Es),Re(xs),G(1));Ci.subscribe();window.document$=ot;window.location$=Ut;window.target$=Lt;window.keyboard$=to;window.viewport$=Oe;window.tablet$=hr;window.screen$=Mi;window.print$=_i;window.alert$=ro;window.progress$=oo;window.component$=Ci;})();
-//# sourceMappingURL=bundle.525ec568.min.js.map
+  `):"",this.name="UnsubscriptionError",this.errors=r}});function Qe(e,t){if(e){var r=e.indexOf(t);0<=r&&e.splice(r,1)}}var Ue=function(){function e(t){this.initialTeardown=t,this.closed=!1,this._parentage=null,this._finalizers=null}return e.prototype.unsubscribe=function(){var t,r,o,n,i;if(!this.closed){this.closed=!0;var a=this._parentage;if(a)if(this._parentage=null,Array.isArray(a))try{for(var s=he(a),p=s.next();!p.done;p=s.next()){var c=p.value;c.remove(this)}}catch(L){t={error:L}}finally{try{p&&!p.done&&(r=s.return)&&r.call(s)}finally{if(t)throw t.error}}else a.remove(this);var l=this.initialTeardown;if(H(l))try{l()}catch(L){i=L instanceof zt?L.errors:[L]}var f=this._finalizers;if(f){this._finalizers=null;try{for(var u=he(f),d=u.next();!d.done;d=u.next()){var y=d.value;try{ho(y)}catch(L){i=i!=null?i:[],L instanceof zt?i=q(q([],N(i)),N(L.errors)):i.push(L)}}}catch(L){o={error:L}}finally{try{d&&!d.done&&(n=u.return)&&n.call(u)}finally{if(o)throw o.error}}}if(i)throw new zt(i)}},e.prototype.add=function(t){var r;if(t&&t!==this)if(this.closed)ho(t);else{if(t instanceof e){if(t.closed||t._hasParent(this))return;t._addParent(this)}(this._finalizers=(r=this._finalizers)!==null&&r!==void 0?r:[]).push(t)}},e.prototype._hasParent=function(t){var r=this._parentage;return r===t||Array.isArray(r)&&r.includes(t)},e.prototype._addParent=function(t){var r=this._parentage;this._parentage=Array.isArray(r)?(r.push(t),r):r?[r,t]:t},e.prototype._removeParent=function(t){var r=this._parentage;r===t?this._parentage=null:Array.isArray(r)&&Qe(r,t)},e.prototype.remove=function(t){var r=this._finalizers;r&&Qe(r,t),t instanceof e&&t._removeParent(this)},e.EMPTY=function(){var t=new e;return t.closed=!0,t}(),e}();var Tr=Ue.EMPTY;function qt(e){return e instanceof Ue||e&&"closed"in e&&H(e.remove)&&H(e.add)&&H(e.unsubscribe)}function ho(e){H(e)?e():e.unsubscribe()}var Pe={onUnhandledError:null,onStoppedNotification:null,Promise:void 0,useDeprecatedSynchronousErrorHandling:!1,useDeprecatedNextContext:!1};var dt={setTimeout:function(e,t){for(var r=[],o=2;o<arguments.length;o++)r[o-2]=arguments[o];var n=dt.delegate;return n!=null&&n.setTimeout?n.setTimeout.apply(n,q([e,t],N(r))):setTimeout.apply(void 0,q([e,t],N(r)))},clearTimeout:function(e){var t=dt.delegate;return((t==null?void 0:t.clearTimeout)||clearTimeout)(e)},delegate:void 0};function Qt(e){dt.setTimeout(function(){var t=Pe.onUnhandledError;if(t)t(e);else throw e})}function be(){}var bo=function(){return Sr("C",void 0,void 0)}();function vo(e){return Sr("E",void 0,e)}function go(e){return Sr("N",e,void 0)}function Sr(e,t,r){return{kind:e,value:t,error:r}}var it=null;function ht(e){if(Pe.useDeprecatedSynchronousErrorHandling){var t=!it;if(t&&(it={errorThrown:!1,error:null}),e(),t){var r=it,o=r.errorThrown,n=r.error;if(it=null,o)throw n}}else e()}function yo(e){Pe.useDeprecatedSynchronousErrorHandling&&it&&(it.errorThrown=!0,it.error=e)}var _t=function(e){oe(t,e);function t(r){var o=e.call(this)||this;return o.isStopped=!1,r?(o.destination=r,qt(r)&&r.add(o)):o.destination=Yi,o}return t.create=function(r,o,n){return new at(r,o,n)},t.prototype.next=function(r){this.isStopped?Lr(go(r),this):this._next(r)},t.prototype.error=function(r){this.isStopped?Lr(vo(r),this):(this.isStopped=!0,this._error(r))},t.prototype.complete=function(){this.isStopped?Lr(bo,this):(this.isStopped=!0,this._complete())},t.prototype.unsubscribe=function(){this.closed||(this.isStopped=!0,e.prototype.unsubscribe.call(this),this.destination=null)},t.prototype._next=function(r){this.destination.next(r)},t.prototype._error=function(r){try{this.destination.error(r)}finally{this.unsubscribe()}},t.prototype._complete=function(){try{this.destination.complete()}finally{this.unsubscribe()}},t}(Ue);var qi=Function.prototype.bind;function Or(e,t){return qi.call(e,t)}var Qi=function(){function e(t){this.partialObserver=t}return e.prototype.next=function(t){var r=this.partialObserver;if(r.next)try{r.next(t)}catch(o){Kt(o)}},e.prototype.error=function(t){var r=this.partialObserver;if(r.error)try{r.error(t)}catch(o){Kt(o)}else Kt(t)},e.prototype.complete=function(){var t=this.partialObserver;if(t.complete)try{t.complete()}catch(r){Kt(r)}},e}(),at=function(e){oe(t,e);function t(r,o,n){var i=e.call(this)||this,a;if(H(r)||!r)a={next:r!=null?r:void 0,error:o!=null?o:void 0,complete:n!=null?n:void 0};else{var s;i&&Pe.useDeprecatedNextContext?(s=Object.create(r),s.unsubscribe=function(){return i.unsubscribe()},a={next:r.next&&Or(r.next,s),error:r.error&&Or(r.error,s),complete:r.complete&&Or(r.complete,s)}):a=r}return i.destination=new Qi(a),i}return t}(_t);function Kt(e){Pe.useDeprecatedSynchronousErrorHandling?yo(e):Qt(e)}function Ki(e){throw e}function Lr(e,t){var r=Pe.onStoppedNotification;r&&dt.setTimeout(function(){return r(e,t)})}var Yi={closed:!0,next:be,error:Ki,complete:be};var bt=function(){return typeof Symbol=="function"&&Symbol.observable||"@@observable"}();function le(e){return e}function xo(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];return Mr(e)}function Mr(e){return e.length===0?le:e.length===1?e[0]:function(r){return e.reduce(function(o,n){return n(o)},r)}}var j=function(){function e(t){t&&(this._subscribe=t)}return e.prototype.lift=function(t){var r=new e;return r.source=this,r.operator=t,r},e.prototype.subscribe=function(t,r,o){var n=this,i=Gi(t)?t:new at(t,r,o);return ht(function(){var a=n,s=a.operator,p=a.source;i.add(s?s.call(i,p):p?n._subscribe(i):n._trySubscribe(i))}),i},e.prototype._trySubscribe=function(t){try{return this._subscribe(t)}catch(r){t.error(r)}},e.prototype.forEach=function(t,r){var o=this;return r=Eo(r),new r(function(n,i){var a=new at({next:function(s){try{t(s)}catch(p){i(p),a.unsubscribe()}},error:i,complete:n});o.subscribe(a)})},e.prototype._subscribe=function(t){var r;return(r=this.source)===null||r===void 0?void 0:r.subscribe(t)},e.prototype[bt]=function(){return this},e.prototype.pipe=function(){for(var t=[],r=0;r<arguments.length;r++)t[r]=arguments[r];return Mr(t)(this)},e.prototype.toPromise=function(t){var r=this;return t=Eo(t),new t(function(o,n){var i;r.subscribe(function(a){return i=a},function(a){return n(a)},function(){return o(i)})})},e.create=function(t){return new e(t)},e}();function Eo(e){var t;return(t=e!=null?e:Pe.Promise)!==null&&t!==void 0?t:Promise}function Bi(e){return e&&H(e.next)&&H(e.error)&&H(e.complete)}function Gi(e){return e&&e instanceof _t||Bi(e)&&qt(e)}function Ji(e){return H(e==null?void 0:e.lift)}function E(e){return function(t){if(Ji(t))return t.lift(function(r){try{return e(r,this)}catch(o){this.error(o)}});throw new TypeError("Unable to lift unknown Observable type")}}function T(e,t,r,o,n){return new Xi(e,t,r,o,n)}var Xi=function(e){oe(t,e);function t(r,o,n,i,a,s){var p=e.call(this,r)||this;return p.onFinalize=a,p.shouldUnsubscribe=s,p._next=o?function(c){try{o(c)}catch(l){r.error(l)}}:e.prototype._next,p._error=i?function(c){try{i(c)}catch(l){r.error(l)}finally{this.unsubscribe()}}:e.prototype._error,p._complete=n?function(){try{n()}catch(c){r.error(c)}finally{this.unsubscribe()}}:e.prototype._complete,p}return t.prototype.unsubscribe=function(){var r;if(!this.shouldUnsubscribe||this.shouldUnsubscribe()){var o=this.closed;e.prototype.unsubscribe.call(this),!o&&((r=this.onFinalize)===null||r===void 0||r.call(this))}},t}(_t);var vt={schedule:function(e){var t=requestAnimationFrame,r=cancelAnimationFrame,o=vt.delegate;o&&(t=o.requestAnimationFrame,r=o.cancelAnimationFrame);var n=t(function(i){r=void 0,e(i)});return new Ue(function(){return r==null?void 0:r(n)})},requestAnimationFrame:function(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=vt.delegate;return((r==null?void 0:r.requestAnimationFrame)||requestAnimationFrame).apply(void 0,q([],N(e)))},cancelAnimationFrame:function(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=vt.delegate;return((r==null?void 0:r.cancelAnimationFrame)||cancelAnimationFrame).apply(void 0,q([],N(e)))},delegate:void 0};var wo=ut(function(e){return function(){e(this),this.name="ObjectUnsubscribedError",this.message="object unsubscribed"}});var g=function(e){oe(t,e);function t(){var r=e.call(this)||this;return r.closed=!1,r.currentObservers=null,r.observers=[],r.isStopped=!1,r.hasError=!1,r.thrownError=null,r}return t.prototype.lift=function(r){var o=new To(this,this);return o.operator=r,o},t.prototype._throwIfClosed=function(){if(this.closed)throw new wo},t.prototype.next=function(r){var o=this;ht(function(){var n,i;if(o._throwIfClosed(),!o.isStopped){o.currentObservers||(o.currentObservers=Array.from(o.observers));try{for(var a=he(o.currentObservers),s=a.next();!s.done;s=a.next()){var p=s.value;p.next(r)}}catch(c){n={error:c}}finally{try{s&&!s.done&&(i=a.return)&&i.call(a)}finally{if(n)throw n.error}}}})},t.prototype.error=function(r){var o=this;ht(function(){if(o._throwIfClosed(),!o.isStopped){o.hasError=o.isStopped=!0,o.thrownError=r;for(var n=o.observers;n.length;)n.shift().error(r)}})},t.prototype.complete=function(){var r=this;ht(function(){if(r._throwIfClosed(),!r.isStopped){r.isStopped=!0;for(var o=r.observers;o.length;)o.shift().complete()}})},t.prototype.unsubscribe=function(){this.isStopped=this.closed=!0,this.observers=this.currentObservers=null},Object.defineProperty(t.prototype,"observed",{get:function(){var r;return((r=this.observers)===null||r===void 0?void 0:r.length)>0},enumerable:!1,configurable:!0}),t.prototype._trySubscribe=function(r){return this._throwIfClosed(),e.prototype._trySubscribe.call(this,r)},t.prototype._subscribe=function(r){return this._throwIfClosed(),this._checkFinalizedStatuses(r),this._innerSubscribe(r)},t.prototype._innerSubscribe=function(r){var o=this,n=this,i=n.hasError,a=n.isStopped,s=n.observers;return i||a?Tr:(this.currentObservers=null,s.push(r),new Ue(function(){o.currentObservers=null,Qe(s,r)}))},t.prototype._checkFinalizedStatuses=function(r){var o=this,n=o.hasError,i=o.thrownError,a=o.isStopped;n?r.error(i):a&&r.complete()},t.prototype.asObservable=function(){var r=new j;return r.source=this,r},t.create=function(r,o){return new To(r,o)},t}(j);var To=function(e){oe(t,e);function t(r,o){var n=e.call(this)||this;return n.destination=r,n.source=o,n}return t.prototype.next=function(r){var o,n;(n=(o=this.destination)===null||o===void 0?void 0:o.next)===null||n===void 0||n.call(o,r)},t.prototype.error=function(r){var o,n;(n=(o=this.destination)===null||o===void 0?void 0:o.error)===null||n===void 0||n.call(o,r)},t.prototype.complete=function(){var r,o;(o=(r=this.destination)===null||r===void 0?void 0:r.complete)===null||o===void 0||o.call(r)},t.prototype._subscribe=function(r){var o,n;return(n=(o=this.source)===null||o===void 0?void 0:o.subscribe(r))!==null&&n!==void 0?n:Tr},t}(g);var _r=function(e){oe(t,e);function t(r){var o=e.call(this)||this;return o._value=r,o}return Object.defineProperty(t.prototype,"value",{get:function(){return this.getValue()},enumerable:!1,configurable:!0}),t.prototype._subscribe=function(r){var o=e.prototype._subscribe.call(this,r);return!o.closed&&r.next(this._value),o},t.prototype.getValue=function(){var r=this,o=r.hasError,n=r.thrownError,i=r._value;if(o)throw n;return this._throwIfClosed(),i},t.prototype.next=function(r){e.prototype.next.call(this,this._value=r)},t}(g);var At={now:function(){return(At.delegate||Date).now()},delegate:void 0};var Ct=function(e){oe(t,e);function t(r,o,n){r===void 0&&(r=1/0),o===void 0&&(o=1/0),n===void 0&&(n=At);var i=e.call(this)||this;return i._bufferSize=r,i._windowTime=o,i._timestampProvider=n,i._buffer=[],i._infiniteTimeWindow=!0,i._infiniteTimeWindow=o===1/0,i._bufferSize=Math.max(1,r),i._windowTime=Math.max(1,o),i}return t.prototype.next=function(r){var o=this,n=o.isStopped,i=o._buffer,a=o._infiniteTimeWindow,s=o._timestampProvider,p=o._windowTime;n||(i.push(r),!a&&i.push(s.now()+p)),this._trimBuffer(),e.prototype.next.call(this,r)},t.prototype._subscribe=function(r){this._throwIfClosed(),this._trimBuffer();for(var o=this._innerSubscribe(r),n=this,i=n._infiniteTimeWindow,a=n._buffer,s=a.slice(),p=0;p<s.length&&!r.closed;p+=i?1:2)r.next(s[p]);return this._checkFinalizedStatuses(r),o},t.prototype._trimBuffer=function(){var r=this,o=r._bufferSize,n=r._timestampProvider,i=r._buffer,a=r._infiniteTimeWindow,s=(a?1:2)*o;if(o<1/0&&s<i.length&&i.splice(0,i.length-s),!a){for(var p=n.now(),c=0,l=1;l<i.length&&i[l]<=p;l+=2)c=l;c&&i.splice(0,c+1)}},t}(g);var So=function(e){oe(t,e);function t(r,o){return e.call(this)||this}return t.prototype.schedule=function(r,o){return o===void 0&&(o=0),this},t}(Ue);var kt={setInterval:function(e,t){for(var r=[],o=2;o<arguments.length;o++)r[o-2]=arguments[o];var n=kt.delegate;return n!=null&&n.setInterval?n.setInterval.apply(n,q([e,t],N(r))):setInterval.apply(void 0,q([e,t],N(r)))},clearInterval:function(e){var t=kt.delegate;return((t==null?void 0:t.clearInterval)||clearInterval)(e)},delegate:void 0};var gt=function(e){oe(t,e);function t(r,o){var n=e.call(this,r,o)||this;return n.scheduler=r,n.work=o,n.pending=!1,n}return t.prototype.schedule=function(r,o){var n;if(o===void 0&&(o=0),this.closed)return this;this.state=r;var i=this.id,a=this.scheduler;return i!=null&&(this.id=this.recycleAsyncId(a,i,o)),this.pending=!0,this.delay=o,this.id=(n=this.id)!==null&&n!==void 0?n:this.requestAsyncId(a,this.id,o),this},t.prototype.requestAsyncId=function(r,o,n){return n===void 0&&(n=0),kt.setInterval(r.flush.bind(r,this),n)},t.prototype.recycleAsyncId=function(r,o,n){if(n===void 0&&(n=0),n!=null&&this.delay===n&&this.pending===!1)return o;o!=null&&kt.clearInterval(o)},t.prototype.execute=function(r,o){if(this.closed)return new Error("executing a cancelled action");this.pending=!1;var n=this._execute(r,o);if(n)return n;this.pending===!1&&this.id!=null&&(this.id=this.recycleAsyncId(this.scheduler,this.id,null))},t.prototype._execute=function(r,o){var n=!1,i;try{this.work(r)}catch(a){n=!0,i=a||new Error("Scheduled action threw falsy error")}if(n)return this.unsubscribe(),i},t.prototype.unsubscribe=function(){if(!this.closed){var r=this,o=r.id,n=r.scheduler,i=n.actions;this.work=this.state=this.scheduler=null,this.pending=!1,Qe(i,this),o!=null&&(this.id=this.recycleAsyncId(n,o,null)),this.delay=null,e.prototype.unsubscribe.call(this)}},t}(So);var Ar=function(){function e(t,r){r===void 0&&(r=e.now),this.schedulerActionCtor=t,this.now=r}return e.prototype.schedule=function(t,r,o){return r===void 0&&(r=0),new this.schedulerActionCtor(this,t).schedule(o,r)},e.now=At.now,e}();var yt=function(e){oe(t,e);function t(r,o){o===void 0&&(o=Ar.now);var n=e.call(this,r,o)||this;return n.actions=[],n._active=!1,n}return t.prototype.flush=function(r){var o=this.actions;if(this._active){o.push(r);return}var n;this._active=!0;do if(n=r.execute(r.state,r.delay))break;while(r=o.shift());if(this._active=!1,n){for(;r=o.shift();)r.unsubscribe();throw n}},t}(Ar);var se=new yt(gt),Cr=se;var Oo=function(e){oe(t,e);function t(r,o){var n=e.call(this,r,o)||this;return n.scheduler=r,n.work=o,n}return t.prototype.schedule=function(r,o){return o===void 0&&(o=0),o>0?e.prototype.schedule.call(this,r,o):(this.delay=o,this.state=r,this.scheduler.flush(this),this)},t.prototype.execute=function(r,o){return o>0||this.closed?e.prototype.execute.call(this,r,o):this._execute(r,o)},t.prototype.requestAsyncId=function(r,o,n){return n===void 0&&(n=0),n!=null&&n>0||n==null&&this.delay>0?e.prototype.requestAsyncId.call(this,r,o,n):(r.flush(this),0)},t}(gt);var Lo=function(e){oe(t,e);function t(){return e!==null&&e.apply(this,arguments)||this}return t}(yt);var kr=new Lo(Oo);var Mo=function(e){oe(t,e);function t(r,o){var n=e.call(this,r,o)||this;return n.scheduler=r,n.work=o,n}return t.prototype.requestAsyncId=function(r,o,n){return n===void 0&&(n=0),n!==null&&n>0?e.prototype.requestAsyncId.call(this,r,o,n):(r.actions.push(this),r._scheduled||(r._scheduled=vt.requestAnimationFrame(function(){return r.flush(void 0)})))},t.prototype.recycleAsyncId=function(r,o,n){var i;if(n===void 0&&(n=0),n!=null?n>0:this.delay>0)return e.prototype.recycleAsyncId.call(this,r,o,n);var a=r.actions;o!=null&&((i=a[a.length-1])===null||i===void 0?void 0:i.id)!==o&&(vt.cancelAnimationFrame(o),r._scheduled=void 0)},t}(gt);var _o=function(e){oe(t,e);function t(){return e!==null&&e.apply(this,arguments)||this}return t.prototype.flush=function(r){this._active=!0;var o=this._scheduled;this._scheduled=void 0;var n=this.actions,i;r=r||n.shift();do if(i=r.execute(r.state,r.delay))break;while((r=n[0])&&r.id===o&&n.shift());if(this._active=!1,i){for(;(r=n[0])&&r.id===o&&n.shift();)r.unsubscribe();throw i}},t}(yt);var me=new _o(Mo);var S=new j(function(e){return e.complete()});function Yt(e){return e&&H(e.schedule)}function Hr(e){return e[e.length-1]}function Xe(e){return H(Hr(e))?e.pop():void 0}function ke(e){return Yt(Hr(e))?e.pop():void 0}function Bt(e,t){return typeof Hr(e)=="number"?e.pop():t}var xt=function(e){return e&&typeof e.length=="number"&&typeof e!="function"};function Gt(e){return H(e==null?void 0:e.then)}function Jt(e){return H(e[bt])}function Xt(e){return Symbol.asyncIterator&&H(e==null?void 0:e[Symbol.asyncIterator])}function Zt(e){return new TypeError("You provided "+(e!==null&&typeof e=="object"?"an invalid object":"'"+e+"'")+" where a stream was expected. You can provide an Observable, Promise, ReadableStream, Array, AsyncIterable, or Iterable.")}function Zi(){return typeof Symbol!="function"||!Symbol.iterator?"@@iterator":Symbol.iterator}var er=Zi();function tr(e){return H(e==null?void 0:e[er])}function rr(e){return fo(this,arguments,function(){var r,o,n,i;return Nt(this,function(a){switch(a.label){case 0:r=e.getReader(),a.label=1;case 1:a.trys.push([1,,9,10]),a.label=2;case 2:return[4,nt(r.read())];case 3:return o=a.sent(),n=o.value,i=o.done,i?[4,nt(void 0)]:[3,5];case 4:return[2,a.sent()];case 5:return[4,nt(n)];case 6:return[4,a.sent()];case 7:return a.sent(),[3,2];case 8:return[3,10];case 9:return r.releaseLock(),[7];case 10:return[2]}})})}function or(e){return H(e==null?void 0:e.getReader)}function U(e){if(e instanceof j)return e;if(e!=null){if(Jt(e))return ea(e);if(xt(e))return ta(e);if(Gt(e))return ra(e);if(Xt(e))return Ao(e);if(tr(e))return oa(e);if(or(e))return na(e)}throw Zt(e)}function ea(e){return new j(function(t){var r=e[bt]();if(H(r.subscribe))return r.subscribe(t);throw new TypeError("Provided object does not correctly implement Symbol.observable")})}function ta(e){return new j(function(t){for(var r=0;r<e.length&&!t.closed;r++)t.next(e[r]);t.complete()})}function ra(e){return new j(function(t){e.then(function(r){t.closed||(t.next(r),t.complete())},function(r){return t.error(r)}).then(null,Qt)})}function oa(e){return new j(function(t){var r,o;try{for(var n=he(e),i=n.next();!i.done;i=n.next()){var a=i.value;if(t.next(a),t.closed)return}}catch(s){r={error:s}}finally{try{i&&!i.done&&(o=n.return)&&o.call(n)}finally{if(r)throw r.error}}t.complete()})}function Ao(e){return new j(function(t){ia(e,t).catch(function(r){return t.error(r)})})}function na(e){return Ao(rr(e))}function ia(e,t){var r,o,n,i;return mo(this,void 0,void 0,function(){var a,s;return Nt(this,function(p){switch(p.label){case 0:p.trys.push([0,5,6,11]),r=uo(e),p.label=1;case 1:return[4,r.next()];case 2:if(o=p.sent(),!!o.done)return[3,4];if(a=o.value,t.next(a),t.closed)return[2];p.label=3;case 3:return[3,1];case 4:return[3,11];case 5:return s=p.sent(),n={error:s},[3,11];case 6:return p.trys.push([6,,9,10]),o&&!o.done&&(i=r.return)?[4,i.call(r)]:[3,8];case 7:p.sent(),p.label=8;case 8:return[3,10];case 9:if(n)throw n.error;return[7];case 10:return[7];case 11:return t.complete(),[2]}})})}function we(e,t,r,o,n){o===void 0&&(o=0),n===void 0&&(n=!1);var i=t.schedule(function(){r(),n?e.add(this.schedule(null,o)):this.unsubscribe()},o);if(e.add(i),!n)return i}function ve(e,t){return t===void 0&&(t=0),E(function(r,o){r.subscribe(T(o,function(n){return we(o,e,function(){return o.next(n)},t)},function(){return we(o,e,function(){return o.complete()},t)},function(n){return we(o,e,function(){return o.error(n)},t)}))})}function Ke(e,t){return t===void 0&&(t=0),E(function(r,o){o.add(e.schedule(function(){return r.subscribe(o)},t))})}function Co(e,t){return U(e).pipe(Ke(t),ve(t))}function ko(e,t){return U(e).pipe(Ke(t),ve(t))}function Ho(e,t){return new j(function(r){var o=0;return t.schedule(function(){o===e.length?r.complete():(r.next(e[o++]),r.closed||this.schedule())})})}function $o(e,t){return new j(function(r){var o;return we(r,t,function(){o=e[er](),we(r,t,function(){var n,i,a;try{n=o.next(),i=n.value,a=n.done}catch(s){r.error(s);return}a?r.complete():r.next(i)},0,!0)}),function(){return H(o==null?void 0:o.return)&&o.return()}})}function nr(e,t){if(!e)throw new Error("Iterable cannot be null");return new j(function(r){we(r,t,function(){var o=e[Symbol.asyncIterator]();we(r,t,function(){o.next().then(function(n){n.done?r.complete():r.next(n.value)})},0,!0)})})}function Po(e,t){return nr(rr(e),t)}function Ro(e,t){if(e!=null){if(Jt(e))return Co(e,t);if(xt(e))return Ho(e,t);if(Gt(e))return ko(e,t);if(Xt(e))return nr(e,t);if(tr(e))return $o(e,t);if(or(e))return Po(e,t)}throw Zt(e)}function ue(e,t){return t?Ro(e,t):U(e)}function I(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=ke(e);return ue(e,r)}function $r(e,t){var r=H(e)?e:function(){return e},o=function(n){return n.error(r())};return new j(t?function(n){return t.schedule(o,0,n)}:o)}var ir=ut(function(e){return function(){e(this),this.name="EmptyError",this.message="no elements in sequence"}});function Io(e){return e instanceof Date&&!isNaN(e)}function m(e,t){return E(function(r,o){var n=0;r.subscribe(T(o,function(i){o.next(e.call(t,i,n++))}))})}var aa=Array.isArray;function sa(e,t){return aa(t)?e.apply(void 0,q([],N(t))):e(t)}function Ze(e){return m(function(t){return sa(e,t)})}var ca=Array.isArray,pa=Object.getPrototypeOf,la=Object.prototype,ma=Object.keys;function jo(e){if(e.length===1){var t=e[0];if(ca(t))return{args:t,keys:null};if(fa(t)){var r=ma(t);return{args:r.map(function(o){return t[o]}),keys:r}}}return{args:e,keys:null}}function fa(e){return e&&typeof e=="object"&&pa(e)===la}function Fo(e,t){return e.reduce(function(r,o,n){return r[o]=t[n],r},{})}function z(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=ke(e),o=Xe(e),n=jo(e),i=n.args,a=n.keys;if(i.length===0)return ue([],r);var s=new j(Pr(i,r,a?function(p){return Fo(a,p)}:le));return o?s.pipe(Ze(o)):s}function Pr(e,t,r){return r===void 0&&(r=le),function(o){Uo(t,function(){for(var n=e.length,i=new Array(n),a=n,s=n,p=function(l){Uo(t,function(){var f=ue(e[l],t),u=!1;f.subscribe(T(o,function(d){i[l]=d,u||(u=!0,s--),s||o.next(r(i.slice()))},function(){--a||o.complete()}))},o)},c=0;c<n;c++)p(c)},o)}}function Uo(e,t,r){e?we(r,e,t):t()}function Wo(e,t,r,o,n,i,a,s){var p=[],c=0,l=0,f=!1,u=function(){f&&!p.length&&!c&&t.complete()},d=function(L){return c<o?y(L):p.push(L)},y=function(L){i&&t.next(L),c++;var X=!1;U(r(L,l++)).subscribe(T(t,function(te){n==null||n(te),i?d(te):t.next(te)},function(){X=!0},void 0,function(){if(X)try{c--;for(var te=function(){var J=p.shift();a?we(t,a,function(){return y(J)}):y(J)};p.length&&c<o;)te();u()}catch(J){t.error(J)}}))};return e.subscribe(T(t,d,function(){f=!0,u()})),function(){s==null||s()}}function ne(e,t,r){return r===void 0&&(r=1/0),H(t)?ne(function(o,n){return m(function(i,a){return t(o,i,n,a)})(U(e(o,n)))},r):(typeof t=="number"&&(r=t),E(function(o,n){return Wo(o,n,e,r)}))}function Et(e){return e===void 0&&(e=1/0),ne(le,e)}function Do(){return Et(1)}function We(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];return Do()(ue(e,ke(e)))}function C(e){return new j(function(t){U(e()).subscribe(t)})}var ua=["addListener","removeListener"],da=["addEventListener","removeEventListener"],ha=["on","off"];function h(e,t,r,o){if(H(r)&&(o=r,r=void 0),o)return h(e,t,r).pipe(Ze(o));var n=N(ga(e)?da.map(function(s){return function(p){return e[s](t,p,r)}}):ba(e)?ua.map(Vo(e,t)):va(e)?ha.map(Vo(e,t)):[],2),i=n[0],a=n[1];if(!i&&xt(e))return ne(function(s){return h(s,t,r)})(U(e));if(!i)throw new TypeError("Invalid event target");return new j(function(s){var p=function(){for(var c=[],l=0;l<arguments.length;l++)c[l]=arguments[l];return s.next(1<c.length?c:c[0])};return i(p),function(){return a(p)}})}function Vo(e,t){return function(r){return function(o){return e[r](t,o)}}}function ba(e){return H(e.addListener)&&H(e.removeListener)}function va(e){return H(e.on)&&H(e.off)}function ga(e){return H(e.addEventListener)&&H(e.removeEventListener)}function ar(e,t,r){return r?ar(e,t).pipe(Ze(r)):new j(function(o){var n=function(){for(var a=[],s=0;s<arguments.length;s++)a[s]=arguments[s];return o.next(a.length===1?a[0]:a)},i=e(n);return H(t)?function(){return t(n,i)}:void 0})}function Le(e,t,r){e===void 0&&(e=0),r===void 0&&(r=Cr);var o=-1;return t!=null&&(Yt(t)?r=t:o=t),new j(function(n){var i=Io(e)?+e-r.now():e;i<0&&(i=0);var a=0;return r.schedule(function(){n.closed||(n.next(a++),0<=o?this.schedule(void 0,o):n.complete())},i)})}function O(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=ke(e),o=Bt(e,1/0),n=e;return n.length?n.length===1?U(n[0]):Et(o)(ue(n,r)):S}var Ye=new j(be);var ya=Array.isArray;function wt(e){return e.length===1&&ya(e[0])?e[0]:e}function b(e,t){return E(function(r,o){var n=0;r.subscribe(T(o,function(i){return e.call(t,i,n++)&&o.next(i)}))})}function st(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=Xe(e),o=wt(e);return o.length?new j(function(n){var i=o.map(function(){return[]}),a=o.map(function(){return!1});n.add(function(){i=a=null});for(var s=function(c){U(o[c]).subscribe(T(n,function(l){if(i[c].push(l),i.every(function(u){return u.length})){var f=i.map(function(u){return u.shift()});n.next(r?r.apply(void 0,q([],N(f))):f),i.some(function(u,d){return!u.length&&a[d]})&&n.complete()}},function(){a[c]=!0,!i[c].length&&n.complete()}))},p=0;!n.closed&&p<o.length;p++)s(p);return function(){i=a=null}}):S}function No(e){return E(function(t,r){var o=!1,n=null,i=null,a=!1,s=function(){if(i==null||i.unsubscribe(),i=null,o){o=!1;var c=n;n=null,r.next(c)}a&&r.complete()},p=function(){i=null,a&&r.complete()};t.subscribe(T(r,function(c){o=!0,n=c,i||U(e(c)).subscribe(i=T(r,s,p))},function(){a=!0,(!o||!i||i.closed)&&r.complete()}))})}function Me(e,t){return t===void 0&&(t=se),No(function(){return Le(e,t)})}function Be(e,t){return t===void 0&&(t=null),t=t!=null?t:e,E(function(r,o){var n=[],i=0;r.subscribe(T(o,function(a){var s,p,c,l,f=null;i++%t===0&&n.push([]);try{for(var u=he(n),d=u.next();!d.done;d=u.next()){var y=d.value;y.push(a),e<=y.length&&(f=f!=null?f:[],f.push(y))}}catch(te){s={error:te}}finally{try{d&&!d.done&&(p=u.return)&&p.call(u)}finally{if(s)throw s.error}}if(f)try{for(var L=he(f),X=L.next();!X.done;X=L.next()){var y=X.value;Qe(n,y),o.next(y)}}catch(te){c={error:te}}finally{try{X&&!X.done&&(l=L.return)&&l.call(L)}finally{if(c)throw c.error}}},function(){var a,s;try{for(var p=he(n),c=p.next();!c.done;c=p.next()){var l=c.value;o.next(l)}}catch(f){a={error:f}}finally{try{c&&!c.done&&(s=p.return)&&s.call(p)}finally{if(a)throw a.error}}o.complete()},void 0,function(){n=null}))})}function de(e){return E(function(t,r){var o=null,n=!1,i;o=t.subscribe(T(r,void 0,void 0,function(a){i=U(e(a,de(e)(t))),o?(o.unsubscribe(),o=null,i.subscribe(r)):n=!0})),n&&(o.unsubscribe(),o=null,i.subscribe(r))})}function zo(e,t,r,o,n){return function(i,a){var s=r,p=t,c=0;i.subscribe(T(a,function(l){var f=c++;p=s?e(p,l,f):(s=!0,l),o&&a.next(p)},n&&function(){s&&a.next(p),a.complete()}))}}function Rr(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=Xe(e);return r?xo(Rr.apply(void 0,q([],N(e))),Ze(r)):E(function(o,n){Pr(q([o],N(wt(e))))(n)})}function He(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];return Rr.apply(void 0,q([],N(e)))}function Ht(e){return E(function(t,r){var o=!1,n=null,i=null,a=function(){if(i==null||i.unsubscribe(),i=null,o){o=!1;var s=n;n=null,r.next(s)}};t.subscribe(T(r,function(s){i==null||i.unsubscribe(),o=!0,n=s,i=T(r,a,be),U(e(s)).subscribe(i)},function(){a(),r.complete()},void 0,function(){n=i=null}))})}function _e(e,t){return t===void 0&&(t=se),E(function(r,o){var n=null,i=null,a=null,s=function(){if(n){n.unsubscribe(),n=null;var c=i;i=null,o.next(c)}};function p(){var c=a+e,l=t.now();if(l<c){n=this.schedule(void 0,c-l),o.add(n);return}s()}r.subscribe(T(o,function(c){i=c,a=t.now(),n||(n=t.schedule(p,e),o.add(n))},function(){s(),o.complete()},void 0,function(){i=n=null}))})}function De(e){return E(function(t,r){var o=!1;t.subscribe(T(r,function(n){o=!0,r.next(n)},function(){o||r.next(e),r.complete()}))})}function Te(e){return e<=0?function(){return S}:E(function(t,r){var o=0;t.subscribe(T(r,function(n){++o<=e&&(r.next(n),e<=o&&r.complete())}))})}function Z(){return E(function(e,t){e.subscribe(T(t,be))})}function qo(e){return m(function(){return e})}function Ir(e,t){return t?function(r){return We(t.pipe(Te(1),Z()),r.pipe(Ir(e)))}:ne(function(r,o){return U(e(r,o)).pipe(Te(1),qo(r))})}function Ge(e,t){t===void 0&&(t=se);var r=Le(e,t);return Ir(function(){return r})}function K(e,t){return t===void 0&&(t=le),e=e!=null?e:xa,E(function(r,o){var n,i=!0;r.subscribe(T(o,function(a){var s=t(a);(i||!e(n,s))&&(i=!1,n=s,o.next(a))}))})}function xa(e,t){return e===t}function ee(e,t){return K(function(r,o){return t?t(r[e],o[e]):r[e]===o[e]})}function Qo(e){return e===void 0&&(e=Ea),E(function(t,r){var o=!1;t.subscribe(T(r,function(n){o=!0,r.next(n)},function(){return o?r.complete():r.error(e())}))})}function Ea(){return new ir}function ie(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];return function(r){return We(r,I.apply(void 0,q([],N(e))))}}function _(e){return E(function(t,r){try{t.subscribe(r)}finally{r.add(e)}})}function Ae(e,t){var r=arguments.length>=2;return function(o){return o.pipe(e?b(function(n,i){return e(n,i,o)}):le,Te(1),r?De(t):Qo(function(){return new ir}))}}function jr(e){return e<=0?function(){return S}:E(function(t,r){var o=[];t.subscribe(T(r,function(n){o.push(n),e<o.length&&o.shift()},function(){var n,i;try{for(var a=he(o),s=a.next();!s.done;s=a.next()){var p=s.value;r.next(p)}}catch(c){n={error:c}}finally{try{s&&!s.done&&(i=a.return)&&i.call(a)}finally{if(n)throw n.error}}r.complete()},void 0,function(){o=null}))})}function Ko(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=ke(e),o=Bt(e,1/0);return e=wt(e),E(function(n,i){Et(o)(ue(q([n],N(e)),r)).subscribe(i)})}function Re(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];return Ko.apply(void 0,q([],N(e)))}function ct(e){var t,r=1/0,o;return e!=null&&(typeof e=="object"?(t=e.count,r=t===void 0?1/0:t,o=e.delay):r=e),r<=0?function(){return S}:E(function(n,i){var a=0,s,p=function(){if(s==null||s.unsubscribe(),s=null,o!=null){var l=typeof o=="number"?Le(o):U(o(a)),f=T(i,function(){f.unsubscribe(),c()});l.subscribe(f)}else c()},c=function(){var l=!1;s=n.subscribe(T(i,void 0,function(){++a<r?s?p():l=!0:i.complete()})),l&&p()};c()})}function Fr(e,t){return E(zo(e,t,arguments.length>=2,!0))}function pe(e){e===void 0&&(e={});var t=e.connector,r=t===void 0?function(){return new g}:t,o=e.resetOnError,n=o===void 0?!0:o,i=e.resetOnComplete,a=i===void 0?!0:i,s=e.resetOnRefCountZero,p=s===void 0?!0:s;return function(c){var l,f,u,d=0,y=!1,L=!1,X=function(){f==null||f.unsubscribe(),f=void 0},te=function(){X(),l=u=void 0,y=L=!1},J=function(){var k=l;te(),k==null||k.unsubscribe()};return E(function(k,ft){d++,!L&&!y&&X();var qe=u=u!=null?u:r();ft.add(function(){d--,d===0&&!L&&!y&&(f=Ur(J,p))}),qe.subscribe(ft),!l&&d>0&&(l=new at({next:function(Fe){return qe.next(Fe)},error:function(Fe){L=!0,X(),f=Ur(te,n,Fe),qe.error(Fe)},complete:function(){y=!0,X(),f=Ur(te,a),qe.complete()}}),U(k).subscribe(l))})(c)}}function Ur(e,t){for(var r=[],o=2;o<arguments.length;o++)r[o-2]=arguments[o];if(t===!0){e();return}if(t!==!1){var n=new at({next:function(){n.unsubscribe(),e()}});return U(t.apply(void 0,q([],N(r)))).subscribe(n)}}function G(e,t,r){var o,n,i,a,s=!1;return e&&typeof e=="object"?(o=e.bufferSize,a=o===void 0?1/0:o,n=e.windowTime,t=n===void 0?1/0:n,i=e.refCount,s=i===void 0?!1:i,r=e.scheduler):a=e!=null?e:1/0,pe({connector:function(){return new Ct(a,t,r)},resetOnError:!0,resetOnComplete:!1,resetOnRefCountZero:s})}function Ce(e){return b(function(t,r){return e<=r})}function Wr(e){return E(function(t,r){var o=!1,n=T(r,function(){n==null||n.unsubscribe(),o=!0},be);U(e).subscribe(n),t.subscribe(T(r,function(i){return o&&r.next(i)}))})}function Q(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=ke(e);return E(function(o,n){(r?We(e,o,r):We(e,o)).subscribe(n)})}function v(e,t){return E(function(r,o){var n=null,i=0,a=!1,s=function(){return a&&!n&&o.complete()};r.subscribe(T(o,function(p){n==null||n.unsubscribe();var c=0,l=i++;U(e(p,l)).subscribe(n=T(o,function(f){return o.next(t?t(p,f,l,c++):f)},function(){n=null,s()}))},function(){a=!0,s()}))})}function W(e){return E(function(t,r){U(e).subscribe(T(r,function(){return r.complete()},be)),!r.closed&&t.subscribe(r)})}function Dr(e,t){return t===void 0&&(t=!1),E(function(r,o){var n=0;r.subscribe(T(o,function(i){var a=e(i,n++);(a||t)&&o.next(i),!a&&o.complete()}))})}function w(e,t,r){var o=H(e)||t||r?{next:e,error:t,complete:r}:e;return o?E(function(n,i){var a;(a=o.subscribe)===null||a===void 0||a.call(o);var s=!0;n.subscribe(T(i,function(p){var c;(c=o.next)===null||c===void 0||c.call(o,p),i.next(p)},function(){var p;s=!1,(p=o.complete)===null||p===void 0||p.call(o),i.complete()},function(p){var c;s=!1,(c=o.error)===null||c===void 0||c.call(o,p),i.error(p)},function(){var p,c;s&&((p=o.unsubscribe)===null||p===void 0||p.call(o)),(c=o.finalize)===null||c===void 0||c.call(o)}))}):le}function Yo(e,t){return E(function(r,o){var n=t!=null?t:{},i=n.leading,a=i===void 0?!0:i,s=n.trailing,p=s===void 0?!1:s,c=!1,l=null,f=null,u=!1,d=function(){f==null||f.unsubscribe(),f=null,p&&(X(),u&&o.complete())},y=function(){f=null,u&&o.complete()},L=function(te){return f=U(e(te)).subscribe(T(o,d,y))},X=function(){if(c){c=!1;var te=l;l=null,o.next(te),!u&&L(te)}};r.subscribe(T(o,function(te){c=!0,l=te,!(f&&!f.closed)&&(a?X():L(te))},function(){u=!0,!(p&&c&&f&&!f.closed)&&o.complete()}))})}function pt(e,t,r){t===void 0&&(t=se);var o=Le(e,t);return Yo(function(){return o},r)}function re(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];var r=Xe(e);return E(function(o,n){for(var i=e.length,a=new Array(i),s=e.map(function(){return!1}),p=!1,c=function(f){U(e[f]).subscribe(T(n,function(u){a[f]=u,!p&&!s[f]&&(s[f]=!0,(p=s.every(le))&&(s=null))},be))},l=0;l<i;l++)c(l);o.subscribe(T(n,function(f){if(p){var u=q([f],N(a));n.next(r?r.apply(void 0,q([],N(u))):u)}}))})}function Bo(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];return E(function(r,o){st.apply(void 0,q([r],N(e))).subscribe(o)})}function Vr(){for(var e=[],t=0;t<arguments.length;t++)e[t]=arguments[t];return Bo.apply(void 0,q([],N(e)))}function Go(){let e=new Ct(1);return h(document,"DOMContentLoaded",{once:!0}).subscribe(()=>e.next(document)),e}function P(e,t=document){return Array.from(t.querySelectorAll(e))}function R(e,t=document){let r=fe(e,t);if(typeof r=="undefined")throw new ReferenceError(`Missing element: expected "${e}" to be present`);return r}function fe(e,t=document){return t.querySelector(e)||void 0}function Ie(){var e,t,r,o;return(o=(r=(t=(e=document.activeElement)==null?void 0:e.shadowRoot)==null?void 0:t.activeElement)!=null?r:document.activeElement)!=null?o:void 0}var wa=O(h(document.body,"focusin"),h(document.body,"focusout")).pipe(_e(1),Q(void 0),m(()=>Ie()||document.body),G(1));function et(e){return wa.pipe(m(t=>e.contains(t)),K())}function $t(e,t){return C(()=>O(h(e,"mouseenter").pipe(m(()=>!0)),h(e,"mouseleave").pipe(m(()=>!1))).pipe(t?Ht(r=>Le(+!r*t)):le,Q(e.matches(":hover"))))}function Jo(e,t){if(typeof t=="string"||typeof t=="number")e.innerHTML+=t.toString();else if(t instanceof Node)e.appendChild(t);else if(Array.isArray(t))for(let r of t)Jo(e,r)}function x(e,t,...r){let o=document.createElement(e);if(t)for(let n of Object.keys(t))typeof t[n]!="undefined"&&(typeof t[n]!="boolean"?o.setAttribute(n,t[n]):o.setAttribute(n,""));for(let n of r)Jo(o,n);return o}function sr(e){if(e>999){let t=+((e-950)%1e3>99);return`${((e+1e-6)/1e3).toFixed(t)}k`}else return e.toString()}function Tt(e){let t=x("script",{src:e});return C(()=>(document.head.appendChild(t),O(h(t,"load"),h(t,"error").pipe(v(()=>$r(()=>new ReferenceError(`Invalid script: ${e}`))))).pipe(m(()=>{}),_(()=>document.head.removeChild(t)),Te(1))))}var Xo=new g,Ta=C(()=>typeof ResizeObserver=="undefined"?Tt("https://unpkg.com/resize-observer-polyfill"):I(void 0)).pipe(m(()=>new ResizeObserver(e=>e.forEach(t=>Xo.next(t)))),v(e=>O(Ye,I(e)).pipe(_(()=>e.disconnect()))),G(1));function ce(e){return{width:e.offsetWidth,height:e.offsetHeight}}function ge(e){let t=e;for(;t.clientWidth===0&&t.parentElement;)t=t.parentElement;return Ta.pipe(w(r=>r.observe(t)),v(r=>Xo.pipe(b(o=>o.target===t),_(()=>r.unobserve(t)))),m(()=>ce(e)),Q(ce(e)))}function St(e){return{width:e.scrollWidth,height:e.scrollHeight}}function cr(e){let t=e.parentElement;for(;t&&(e.scrollWidth<=t.scrollWidth&&e.scrollHeight<=t.scrollHeight);)t=(e=t).parentElement;return t?e:void 0}function Zo(e){let t=[],r=e.parentElement;for(;r;)(e.clientWidth>r.clientWidth||e.clientHeight>r.clientHeight)&&t.push(r),r=(e=r).parentElement;return t.length===0&&t.push(document.documentElement),t}function Ve(e){return{x:e.offsetLeft,y:e.offsetTop}}function en(e){let t=e.getBoundingClientRect();return{x:t.x+window.scrollX,y:t.y+window.scrollY}}function tn(e){return O(h(window,"load"),h(window,"resize")).pipe(Me(0,me),m(()=>Ve(e)),Q(Ve(e)))}function pr(e){return{x:e.scrollLeft,y:e.scrollTop}}function Ne(e){return O(h(e,"scroll"),h(window,"scroll"),h(window,"resize")).pipe(Me(0,me),m(()=>pr(e)),Q(pr(e)))}var rn=new g,Sa=C(()=>I(new IntersectionObserver(e=>{for(let t of e)rn.next(t)},{threshold:0}))).pipe(v(e=>O(Ye,I(e)).pipe(_(()=>e.disconnect()))),G(1));function tt(e){return Sa.pipe(w(t=>t.observe(e)),v(t=>rn.pipe(b(({target:r})=>r===e),_(()=>t.unobserve(e)),m(({isIntersecting:r})=>r))))}function on(e,t=16){return Ne(e).pipe(m(({y:r})=>{let o=ce(e),n=St(e);return r>=n.height-o.height-t}),K())}var lr={drawer:R("[data-md-toggle=drawer]"),search:R("[data-md-toggle=search]")};function nn(e){return lr[e].checked}function Je(e,t){lr[e].checked!==t&&lr[e].click()}function ze(e){let t=lr[e];return h(t,"change").pipe(m(()=>t.checked),Q(t.checked))}function Oa(e,t){switch(e.constructor){case HTMLInputElement:return e.type==="radio"?/^Arrow/.test(t):!0;case HTMLSelectElement:case HTMLTextAreaElement:return!0;default:return e.isContentEditable}}function La(){return O(h(window,"compositionstart").pipe(m(()=>!0)),h(window,"compositionend").pipe(m(()=>!1))).pipe(Q(!1))}function an(){let e=h(window,"keydown").pipe(b(t=>!(t.metaKey||t.ctrlKey)),m(t=>({mode:nn("search")?"search":"global",type:t.key,claim(){t.preventDefault(),t.stopPropagation()}})),b(({mode:t,type:r})=>{if(t==="global"){let o=Ie();if(typeof o!="undefined")return!Oa(o,r)}return!0}),pe());return La().pipe(v(t=>t?S:e))}function ye(){return new URL(location.href)}function lt(e,t=!1){if(B("navigation.instant")&&!t){let r=x("a",{href:e.href});document.body.appendChild(r),r.click(),r.remove()}else location.href=e.href}function sn(){return new g}function cn(){return location.hash.slice(1)}function pn(e){let t=x("a",{href:e});t.addEventListener("click",r=>r.stopPropagation()),t.click()}function Ma(e){return O(h(window,"hashchange"),e).pipe(m(cn),Q(cn()),b(t=>t.length>0),G(1))}function ln(e){return Ma(e).pipe(m(t=>fe(`[id="${t}"]`)),b(t=>typeof t!="undefined"))}function Pt(e){let t=matchMedia(e);return ar(r=>t.addListener(()=>r(t.matches))).pipe(Q(t.matches))}function mn(){let e=matchMedia("print");return O(h(window,"beforeprint").pipe(m(()=>!0)),h(window,"afterprint").pipe(m(()=>!1))).pipe(Q(e.matches))}function Nr(e,t){return e.pipe(v(r=>r?t():S))}function zr(e,t){return new j(r=>{let o=new XMLHttpRequest;return o.open("GET",`${e}`),o.responseType="blob",o.addEventListener("load",()=>{o.status>=200&&o.status<300?(r.next(o.response),r.complete()):r.error(new Error(o.statusText))}),o.addEventListener("error",()=>{r.error(new Error("Network error"))}),o.addEventListener("abort",()=>{r.complete()}),typeof(t==null?void 0:t.progress$)!="undefined"&&(o.addEventListener("progress",n=>{var i;if(n.lengthComputable)t.progress$.next(n.loaded/n.total*100);else{let a=(i=o.getResponseHeader("Content-Length"))!=null?i:0;t.progress$.next(n.loaded/+a*100)}}),t.progress$.next(5)),o.send(),()=>o.abort()})}function je(e,t){return zr(e,t).pipe(v(r=>r.text()),m(r=>JSON.parse(r)),G(1))}function fn(e,t){let r=new DOMParser;return zr(e,t).pipe(v(o=>o.text()),m(o=>r.parseFromString(o,"text/html")),G(1))}function un(e,t){let r=new DOMParser;return zr(e,t).pipe(v(o=>o.text()),m(o=>r.parseFromString(o,"text/xml")),G(1))}function dn(){return{x:Math.max(0,scrollX),y:Math.max(0,scrollY)}}function hn(){return O(h(window,"scroll",{passive:!0}),h(window,"resize",{passive:!0})).pipe(m(dn),Q(dn()))}function bn(){return{width:innerWidth,height:innerHeight}}function vn(){return h(window,"resize",{passive:!0}).pipe(m(bn),Q(bn()))}function gn(){return z([hn(),vn()]).pipe(m(([e,t])=>({offset:e,size:t})),G(1))}function mr(e,{viewport$:t,header$:r}){let o=t.pipe(ee("size")),n=z([o,r]).pipe(m(()=>Ve(e)));return z([r,t,n]).pipe(m(([{height:i},{offset:a,size:s},{x:p,y:c}])=>({offset:{x:a.x-p,y:a.y-c+i},size:s})))}function _a(e){return h(e,"message",t=>t.data)}function Aa(e){let t=new g;return t.subscribe(r=>e.postMessage(r)),t}function yn(e,t=new Worker(e)){let r=_a(t),o=Aa(t),n=new g;n.subscribe(o);let i=o.pipe(Z(),ie(!0));return n.pipe(Z(),Re(r.pipe(W(i))),pe())}var Ca=R("#__config"),Ot=JSON.parse(Ca.textContent);Ot.base=`${new URL(Ot.base,ye())}`;function xe(){return Ot}function B(e){return Ot.features.includes(e)}function Ee(e,t){return typeof t!="undefined"?Ot.translations[e].replace("#",t.toString()):Ot.translations[e]}function Se(e,t=document){return R(`[data-md-component=${e}]`,t)}function ae(e,t=document){return P(`[data-md-component=${e}]`,t)}function ka(e){let t=R(".md-typeset > :first-child",e);return h(t,"click",{once:!0}).pipe(m(()=>R(".md-typeset",e)),m(r=>({hash:__md_hash(r.innerHTML)})))}function xn(e){if(!B("announce.dismiss")||!e.childElementCount)return S;if(!e.hidden){let t=R(".md-typeset",e);__md_hash(t.innerHTML)===__md_get("__announce")&&(e.hidden=!0)}return C(()=>{let t=new g;return t.subscribe(({hash:r})=>{e.hidden=!0,__md_set("__announce",r)}),ka(e).pipe(w(r=>t.next(r)),_(()=>t.complete()),m(r=>$({ref:e},r)))})}function Ha(e,{target$:t}){return t.pipe(m(r=>({hidden:r!==e})))}function En(e,t){let r=new g;return r.subscribe(({hidden:o})=>{e.hidden=o}),Ha(e,t).pipe(w(o=>r.next(o)),_(()=>r.complete()),m(o=>$({ref:e},o)))}function Rt(e,t){return t==="inline"?x("div",{class:"md-tooltip md-tooltip--inline",id:e,role:"tooltip"},x("div",{class:"md-tooltip__inner md-typeset"})):x("div",{class:"md-tooltip",id:e,role:"tooltip"},x("div",{class:"md-tooltip__inner md-typeset"}))}function wn(...e){return x("div",{class:"md-tooltip2",role:"tooltip"},x("div",{class:"md-tooltip2__inner md-typeset"},e))}function Tn(e,t){if(t=t?`${t}_annotation_${e}`:void 0,t){let r=t?`#${t}`:void 0;return x("aside",{class:"md-annotation",tabIndex:0},Rt(t),x("a",{href:r,class:"md-annotation__index",tabIndex:-1},x("span",{"data-md-annotation-id":e})))}else return x("aside",{class:"md-annotation",tabIndex:0},Rt(t),x("span",{class:"md-annotation__index",tabIndex:-1},x("span",{"data-md-annotation-id":e})))}function Sn(e){return x("button",{class:"md-clipboard md-icon",title:Ee("clipboard.copy"),"data-clipboard-target":`#${e} > code`})}var Ln=Mt(qr());function Qr(e,t){let r=t&2,o=t&1,n=Object.keys(e.terms).filter(p=>!e.terms[p]).reduce((p,c)=>[...p,x("del",null,(0,Ln.default)(c))," "],[]).slice(0,-1),i=xe(),a=new URL(e.location,i.base);B("search.highlight")&&a.searchParams.set("h",Object.entries(e.terms).filter(([,p])=>p).reduce((p,[c])=>`${p} ${c}`.trim(),""));let{tags:s}=xe();return x("a",{href:`${a}`,class:"md-search-result__link",tabIndex:-1},x("article",{class:"md-search-result__article md-typeset","data-md-score":e.score.toFixed(2)},r>0&&x("div",{class:"md-search-result__icon md-icon"}),r>0&&x("h1",null,e.title),r<=0&&x("h2",null,e.title),o>0&&e.text.length>0&&e.text,e.tags&&x("nav",{class:"md-tags"},e.tags.map(p=>{let c=s?p in s?`md-tag-icon md-tag--${s[p]}`:"md-tag-icon":"";return x("span",{class:`md-tag ${c}`},p)})),o>0&&n.length>0&&x("p",{class:"md-search-result__terms"},Ee("search.result.term.missing"),": ",...n)))}function Mn(e){let t=e[0].score,r=[...e],o=xe(),n=r.findIndex(l=>!`${new URL(l.location,o.base)}`.includes("#")),[i]=r.splice(n,1),a=r.findIndex(l=>l.score<t);a===-1&&(a=r.length);let s=r.slice(0,a),p=r.slice(a),c=[Qr(i,2|+(!n&&a===0)),...s.map(l=>Qr(l,1)),...p.length?[x("details",{class:"md-search-result__more"},x("summary",{tabIndex:-1},x("div",null,p.length>0&&p.length===1?Ee("search.result.more.one"):Ee("search.result.more.other",p.length))),...p.map(l=>Qr(l,1)))]:[]];return x("li",{class:"md-search-result__item"},c)}function _n(e){return x("ul",{class:"md-source__facts"},Object.entries(e).map(([t,r])=>x("li",{class:`md-source__fact md-source__fact--${t}`},typeof r=="number"?sr(r):r)))}function Kr(e){let t=`tabbed-control tabbed-control--${e}`;return x("div",{class:t,hidden:!0},x("button",{class:"tabbed-button",tabIndex:-1,"aria-hidden":"true"}))}function An(e){return x("div",{class:"md-typeset__scrollwrap"},x("div",{class:"md-typeset__table"},e))}function Ra(e){var o;let t=xe(),r=new URL(`../${e.version}/`,t.base);return x("li",{class:"md-version__item"},x("a",{href:`${r}`,class:"md-version__link"},e.title,((o=t.version)==null?void 0:o.alias)&&e.aliases.length>0&&x("span",{class:"md-version__alias"},e.aliases[0])))}function Cn(e,t){var o;let r=xe();return e=e.filter(n=>{var i;return!((i=n.properties)!=null&&i.hidden)}),x("div",{class:"md-version"},x("button",{class:"md-version__current","aria-label":Ee("select.version")},t.title,((o=r.version)==null?void 0:o.alias)&&t.aliases.length>0&&x("span",{class:"md-version__alias"},t.aliases[0])),x("ul",{class:"md-version__list"},e.map(Ra)))}var Ia=0;function ja(e){let t=z([et(e),$t(e)]).pipe(m(([o,n])=>o||n),K()),r=C(()=>Zo(e)).pipe(ne(Ne),pt(1),He(t),m(()=>en(e)));return t.pipe(Ae(o=>o),v(()=>z([t,r])),m(([o,n])=>({active:o,offset:n})),pe())}function Fa(e,t){let{content$:r,viewport$:o}=t,n=`__tooltip2_${Ia++}`;return C(()=>{let i=new g,a=new _r(!1);i.pipe(Z(),ie(!1)).subscribe(a);let s=a.pipe(Ht(c=>Le(+!c*250,kr)),K(),v(c=>c?r:S),w(c=>c.id=n),pe());z([i.pipe(m(({active:c})=>c)),s.pipe(v(c=>$t(c,250)),Q(!1))]).pipe(m(c=>c.some(l=>l))).subscribe(a);let p=a.pipe(b(c=>c),re(s,o),m(([c,l,{size:f}])=>{let u=e.getBoundingClientRect(),d=u.width/2;if(l.role==="tooltip")return{x:d,y:8+u.height};if(u.y>=f.height/2){let{height:y}=ce(l);return{x:d,y:-16-y}}else return{x:d,y:16+u.height}}));return z([s,i,p]).subscribe(([c,{offset:l},f])=>{c.style.setProperty("--md-tooltip-host-x",`${l.x}px`),c.style.setProperty("--md-tooltip-host-y",`${l.y}px`),c.style.setProperty("--md-tooltip-x",`${f.x}px`),c.style.setProperty("--md-tooltip-y",`${f.y}px`),c.classList.toggle("md-tooltip2--top",f.y<0),c.classList.toggle("md-tooltip2--bottom",f.y>=0)}),a.pipe(b(c=>c),re(s,(c,l)=>l),b(c=>c.role==="tooltip")).subscribe(c=>{let l=ce(R(":scope > *",c));c.style.setProperty("--md-tooltip-width",`${l.width}px`),c.style.setProperty("--md-tooltip-tail","0px")}),a.pipe(K(),ve(me),re(s)).subscribe(([c,l])=>{l.classList.toggle("md-tooltip2--active",c)}),z([a.pipe(b(c=>c)),s]).subscribe(([c,l])=>{l.role==="dialog"?(e.setAttribute("aria-controls",n),e.setAttribute("aria-haspopup","dialog")):e.setAttribute("aria-describedby",n)}),a.pipe(b(c=>!c)).subscribe(()=>{e.removeAttribute("aria-controls"),e.removeAttribute("aria-describedby"),e.removeAttribute("aria-haspopup")}),ja(e).pipe(w(c=>i.next(c)),_(()=>i.complete()),m(c=>$({ref:e},c)))})}function mt(e,{viewport$:t},r=document.body){return Fa(e,{content$:new j(o=>{let n=e.title,i=wn(n);return o.next(i),e.removeAttribute("title"),r.append(i),()=>{i.remove(),e.setAttribute("title",n)}}),viewport$:t})}function Ua(e,t){let r=C(()=>z([tn(e),Ne(t)])).pipe(m(([{x:o,y:n},i])=>{let{width:a,height:s}=ce(e);return{x:o-i.x+a/2,y:n-i.y+s/2}}));return et(e).pipe(v(o=>r.pipe(m(n=>({active:o,offset:n})),Te(+!o||1/0))))}function kn(e,t,{target$:r}){let[o,n]=Array.from(e.children);return C(()=>{let i=new g,a=i.pipe(Z(),ie(!0));return i.subscribe({next({offset:s}){e.style.setProperty("--md-tooltip-x",`${s.x}px`),e.style.setProperty("--md-tooltip-y",`${s.y}px`)},complete(){e.style.removeProperty("--md-tooltip-x"),e.style.removeProperty("--md-tooltip-y")}}),tt(e).pipe(W(a)).subscribe(s=>{e.toggleAttribute("data-md-visible",s)}),O(i.pipe(b(({active:s})=>s)),i.pipe(_e(250),b(({active:s})=>!s))).subscribe({next({active:s}){s?e.prepend(o):o.remove()},complete(){e.prepend(o)}}),i.pipe(Me(16,me)).subscribe(({active:s})=>{o.classList.toggle("md-tooltip--active",s)}),i.pipe(pt(125,me),b(()=>!!e.offsetParent),m(()=>e.offsetParent.getBoundingClientRect()),m(({x:s})=>s)).subscribe({next(s){s?e.style.setProperty("--md-tooltip-0",`${-s}px`):e.style.removeProperty("--md-tooltip-0")},complete(){e.style.removeProperty("--md-tooltip-0")}}),h(n,"click").pipe(W(a),b(s=>!(s.metaKey||s.ctrlKey))).subscribe(s=>{s.stopPropagation(),s.preventDefault()}),h(n,"mousedown").pipe(W(a),re(i)).subscribe(([s,{active:p}])=>{var c;if(s.button!==0||s.metaKey||s.ctrlKey)s.preventDefault();else if(p){s.preventDefault();let l=e.parentElement.closest(".md-annotation");l instanceof HTMLElement?l.focus():(c=Ie())==null||c.blur()}}),r.pipe(W(a),b(s=>s===o),Ge(125)).subscribe(()=>e.focus()),Ua(e,t).pipe(w(s=>i.next(s)),_(()=>i.complete()),m(s=>$({ref:e},s)))})}function Wa(e){return e.tagName==="CODE"?P(".c, .c1, .cm",e):[e]}function Da(e){let t=[];for(let r of Wa(e)){let o=[],n=document.createNodeIterator(r,NodeFilter.SHOW_TEXT);for(let i=n.nextNode();i;i=n.nextNode())o.push(i);for(let i of o){let a;for(;a=/(\(\d+\))(!)?/.exec(i.textContent);){let[,s,p]=a;if(typeof p=="undefined"){let c=i.splitText(a.index);i=c.splitText(s.length),t.push(c)}else{i.textContent=s,t.push(i);break}}}}return t}function Hn(e,t){t.append(...Array.from(e.childNodes))}function fr(e,t,{target$:r,print$:o}){let n=t.closest("[id]"),i=n==null?void 0:n.id,a=new Map;for(let s of Da(t)){let[,p]=s.textContent.match(/\((\d+)\)/);fe(`:scope > li:nth-child(${p})`,e)&&(a.set(p,Tn(p,i)),s.replaceWith(a.get(p)))}return a.size===0?S:C(()=>{let s=new g,p=s.pipe(Z(),ie(!0)),c=[];for(let[l,f]of a)c.push([R(".md-typeset",f),R(`:scope > li:nth-child(${l})`,e)]);return o.pipe(W(p)).subscribe(l=>{e.hidden=!l,e.classList.toggle("md-annotation-list",l);for(let[f,u]of c)l?Hn(f,u):Hn(u,f)}),O(...[...a].map(([,l])=>kn(l,t,{target$:r}))).pipe(_(()=>s.complete()),pe())})}function $n(e){if(e.nextElementSibling){let t=e.nextElementSibling;if(t.tagName==="OL")return t;if(t.tagName==="P"&&!t.children.length)return $n(t)}}function Pn(e,t){return C(()=>{let r=$n(e);return typeof r!="undefined"?fr(r,e,t):S})}var Rn=Mt(Br());var Va=0;function In(e){if(e.nextElementSibling){let t=e.nextElementSibling;if(t.tagName==="OL")return t;if(t.tagName==="P"&&!t.children.length)return In(t)}}function Na(e){return ge(e).pipe(m(({width:t})=>({scrollable:St(e).width>t})),ee("scrollable"))}function jn(e,t){let{matches:r}=matchMedia("(hover)"),o=C(()=>{let n=new g,i=n.pipe(jr(1));n.subscribe(({scrollable:c})=>{c&&r?e.setAttribute("tabindex","0"):e.removeAttribute("tabindex")});let a=[];if(Rn.default.isSupported()&&(e.closest(".copy")||B("content.code.copy")&&!e.closest(".no-copy"))){let c=e.closest("pre");c.id=`__code_${Va++}`;let l=Sn(c.id);c.insertBefore(l,e),B("content.tooltips")&&a.push(mt(l,{viewport$}))}let s=e.closest(".highlight");if(s instanceof HTMLElement){let c=In(s);if(typeof c!="undefined"&&(s.classList.contains("annotate")||B("content.code.annotate"))){let l=fr(c,e,t);a.push(ge(s).pipe(W(i),m(({width:f,height:u})=>f&&u),K(),v(f=>f?l:S)))}}return P(":scope > span[id]",e).length&&e.classList.add("md-code__content"),Na(e).pipe(w(c=>n.next(c)),_(()=>n.complete()),m(c=>$({ref:e},c)),Re(...a))});return B("content.lazy")?tt(e).pipe(b(n=>n),Te(1),v(()=>o)):o}function za(e,{target$:t,print$:r}){let o=!0;return O(t.pipe(m(n=>n.closest("details:not([open])")),b(n=>e===n),m(()=>({action:"open",reveal:!0}))),r.pipe(b(n=>n||!o),w(()=>o=e.open),m(n=>({action:n?"open":"close"}))))}function Fn(e,t){return C(()=>{let r=new g;return r.subscribe(({action:o,reveal:n})=>{e.toggleAttribute("open",o==="open"),n&&e.scrollIntoView()}),za(e,t).pipe(w(o=>r.next(o)),_(()=>r.complete()),m(o=>$({ref:e},o)))})}var Un=".node circle,.node ellipse,.node path,.node polygon,.node rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}marker{fill:var(--md-mermaid-edge-color)!important}.edgeLabel .label rect{fill:#0000}.flowchartTitleText{fill:var(--md-mermaid-label-fg-color)}.label{color:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.label foreignObject{line-height:normal;overflow:visible}.label div .edgeLabel{color:var(--md-mermaid-label-fg-color)}.edgeLabel,.edgeLabel p,.label div .edgeLabel{background-color:var(--md-mermaid-label-bg-color)}.edgeLabel,.edgeLabel p{fill:var(--md-mermaid-label-bg-color);color:var(--md-mermaid-edge-color)}.edgePath .path,.flowchart-link{stroke:var(--md-mermaid-edge-color);stroke-width:.05rem}.edgePath .arrowheadPath{fill:var(--md-mermaid-edge-color);stroke:none}.cluster rect{fill:var(--md-default-fg-color--lightest);stroke:var(--md-default-fg-color--lighter)}.cluster span{color:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}g #flowchart-circleEnd,g #flowchart-circleStart,g #flowchart-crossEnd,g #flowchart-crossStart,g #flowchart-pointEnd,g #flowchart-pointStart{stroke:none}.classDiagramTitleText{fill:var(--md-mermaid-label-fg-color)}g.classGroup line,g.classGroup rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}g.classGroup text{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.classLabel .box{fill:var(--md-mermaid-label-bg-color);background-color:var(--md-mermaid-label-bg-color);opacity:1}.classLabel .label{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.node .divider{stroke:var(--md-mermaid-node-fg-color)}.relation{stroke:var(--md-mermaid-edge-color)}.cardinality{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.cardinality text{fill:inherit!important}defs #classDiagram-compositionEnd,defs #classDiagram-compositionStart,defs #classDiagram-dependencyEnd,defs #classDiagram-dependencyStart,defs #classDiagram-extensionEnd,defs #classDiagram-extensionStart{fill:var(--md-mermaid-edge-color)!important;stroke:var(--md-mermaid-edge-color)!important}defs #classDiagram-aggregationEnd,defs #classDiagram-aggregationStart{fill:var(--md-mermaid-label-bg-color)!important;stroke:var(--md-mermaid-edge-color)!important}.statediagramTitleText{fill:var(--md-mermaid-label-fg-color)}g.stateGroup rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}g.stateGroup .state-title{fill:var(--md-mermaid-label-fg-color)!important;font-family:var(--md-mermaid-font-family)}g.stateGroup .composit{fill:var(--md-mermaid-label-bg-color)}.nodeLabel,.nodeLabel p{color:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}a .nodeLabel{text-decoration:underline}.node circle.state-end,.node circle.state-start,.start-state{fill:var(--md-mermaid-edge-color);stroke:none}.end-state-inner,.end-state-outer{fill:var(--md-mermaid-edge-color)}.end-state-inner,.node circle.state-end{stroke:var(--md-mermaid-label-bg-color)}.transition{stroke:var(--md-mermaid-edge-color)}[id^=state-fork] rect,[id^=state-join] rect{fill:var(--md-mermaid-edge-color)!important;stroke:none!important}.statediagram-cluster.statediagram-cluster .inner{fill:var(--md-default-bg-color)}.statediagram-cluster rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}.statediagram-state rect.divider{fill:var(--md-default-fg-color--lightest);stroke:var(--md-default-fg-color--lighter)}defs #statediagram-barbEnd{stroke:var(--md-mermaid-edge-color)}.entityTitleText{fill:var(--md-mermaid-label-fg-color)}.attributeBoxEven,.attributeBoxOdd{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}.entityBox{fill:var(--md-mermaid-label-bg-color);stroke:var(--md-mermaid-node-fg-color)}.entityLabel{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.relationshipLabelBox{fill:var(--md-mermaid-label-bg-color);fill-opacity:1;background-color:var(--md-mermaid-label-bg-color);opacity:1}.relationshipLabel{fill:var(--md-mermaid-label-fg-color)}.relationshipLine{stroke:var(--md-mermaid-edge-color)}defs #ONE_OR_MORE_END *,defs #ONE_OR_MORE_START *,defs #ONLY_ONE_END *,defs #ONLY_ONE_START *,defs #ZERO_OR_MORE_END *,defs #ZERO_OR_MORE_START *,defs #ZERO_OR_ONE_END *,defs #ZERO_OR_ONE_START *{stroke:var(--md-mermaid-edge-color)!important}defs #ZERO_OR_MORE_END circle,defs #ZERO_OR_MORE_START circle{fill:var(--md-mermaid-label-bg-color)}text:not([class]):last-child{fill:var(--md-mermaid-label-fg-color)}.actor{fill:var(--md-mermaid-sequence-actor-bg-color);stroke:var(--md-mermaid-sequence-actor-border-color)}text.actor>tspan{fill:var(--md-mermaid-sequence-actor-fg-color);font-family:var(--md-mermaid-font-family)}line{stroke:var(--md-mermaid-sequence-actor-line-color)}.actor-man circle,.actor-man line{fill:var(--md-mermaid-sequence-actorman-bg-color);stroke:var(--md-mermaid-sequence-actorman-line-color)}.messageLine0,.messageLine1{stroke:var(--md-mermaid-sequence-message-line-color)}.note{fill:var(--md-mermaid-sequence-note-bg-color);stroke:var(--md-mermaid-sequence-note-border-color)}.loopText,.loopText>tspan,.messageText,.noteText>tspan{stroke:none;font-family:var(--md-mermaid-font-family)!important}.messageText{fill:var(--md-mermaid-sequence-message-fg-color)}.loopText,.loopText>tspan{fill:var(--md-mermaid-sequence-loop-fg-color)}.noteText>tspan{fill:var(--md-mermaid-sequence-note-fg-color)}#arrowhead path{fill:var(--md-mermaid-sequence-message-line-color);stroke:none}.loopLine{fill:var(--md-mermaid-sequence-loop-bg-color);stroke:var(--md-mermaid-sequence-loop-border-color)}.labelBox{fill:var(--md-mermaid-sequence-label-bg-color);stroke:none}.labelText,.labelText>span{fill:var(--md-mermaid-sequence-label-fg-color);font-family:var(--md-mermaid-font-family)}.sequenceNumber{fill:var(--md-mermaid-sequence-number-fg-color)}rect.rect{fill:var(--md-mermaid-sequence-box-bg-color);stroke:none}rect.rect+text.text{fill:var(--md-mermaid-sequence-box-fg-color)}defs #sequencenumber{fill:var(--md-mermaid-sequence-number-bg-color)!important}";var Gr,Qa=0;function Ka(){return typeof mermaid=="undefined"||mermaid instanceof Element?Tt("https://unpkg.com/mermaid@11/dist/mermaid.min.js"):I(void 0)}function Wn(e){return e.classList.remove("mermaid"),Gr||(Gr=Ka().pipe(w(()=>mermaid.initialize({startOnLoad:!1,themeCSS:Un,sequence:{actorFontSize:"16px",messageFontSize:"16px",noteFontSize:"16px"}})),m(()=>{}),G(1))),Gr.subscribe(()=>co(this,null,function*(){e.classList.add("mermaid");let t=`__mermaid_${Qa++}`,r=x("div",{class:"mermaid"}),o=e.textContent,{svg:n,fn:i}=yield mermaid.render(t,o),a=r.attachShadow({mode:"closed"});a.innerHTML=n,e.replaceWith(r),i==null||i(a)})),Gr.pipe(m(()=>({ref:e})))}var Dn=x("table");function Vn(e){return e.replaceWith(Dn),Dn.replaceWith(An(e)),I({ref:e})}function Ya(e){let t=e.find(r=>r.checked)||e[0];return O(...e.map(r=>h(r,"change").pipe(m(()=>R(`label[for="${r.id}"]`))))).pipe(Q(R(`label[for="${t.id}"]`)),m(r=>({active:r})))}function Nn(e,{viewport$:t,target$:r}){let o=R(".tabbed-labels",e),n=P(":scope > input",e),i=Kr("prev");e.append(i);let a=Kr("next");return e.append(a),C(()=>{let s=new g,p=s.pipe(Z(),ie(!0));z([s,ge(e),tt(e)]).pipe(W(p),Me(1,me)).subscribe({next([{active:c},l]){let f=Ve(c),{width:u}=ce(c);e.style.setProperty("--md-indicator-x",`${f.x}px`),e.style.setProperty("--md-indicator-width",`${u}px`);let d=pr(o);(f.x<d.x||f.x+u>d.x+l.width)&&o.scrollTo({left:Math.max(0,f.x-16),behavior:"smooth"})},complete(){e.style.removeProperty("--md-indicator-x"),e.style.removeProperty("--md-indicator-width")}}),z([Ne(o),ge(o)]).pipe(W(p)).subscribe(([c,l])=>{let f=St(o);i.hidden=c.x<16,a.hidden=c.x>f.width-l.width-16}),O(h(i,"click").pipe(m(()=>-1)),h(a,"click").pipe(m(()=>1))).pipe(W(p)).subscribe(c=>{let{width:l}=ce(o);o.scrollBy({left:l*c,behavior:"smooth"})}),r.pipe(W(p),b(c=>n.includes(c))).subscribe(c=>c.click()),o.classList.add("tabbed-labels--linked");for(let c of n){let l=R(`label[for="${c.id}"]`);l.replaceChildren(x("a",{href:`#${l.htmlFor}`,tabIndex:-1},...Array.from(l.childNodes))),h(l.firstElementChild,"click").pipe(W(p),b(f=>!(f.metaKey||f.ctrlKey)),w(f=>{f.preventDefault(),f.stopPropagation()})).subscribe(()=>{history.replaceState({},"",`#${l.htmlFor}`),l.click()})}return B("content.tabs.link")&&s.pipe(Ce(1),re(t)).subscribe(([{active:c},{offset:l}])=>{let f=c.innerText.trim();if(c.hasAttribute("data-md-switching"))c.removeAttribute("data-md-switching");else{let u=e.offsetTop-l.y;for(let y of P("[data-tabs]"))for(let L of P(":scope > input",y)){let X=R(`label[for="${L.id}"]`);if(X!==c&&X.innerText.trim()===f){X.setAttribute("data-md-switching",""),L.click();break}}window.scrollTo({top:e.offsetTop-u});let d=__md_get("__tabs")||[];__md_set("__tabs",[...new Set([f,...d])])}}),s.pipe(W(p)).subscribe(()=>{for(let c of P("audio, video",e))c.pause()}),Ya(n).pipe(w(c=>s.next(c)),_(()=>s.complete()),m(c=>$({ref:e},c)))}).pipe(Ke(se))}function zn(e,{viewport$:t,target$:r,print$:o}){return O(...P(".annotate:not(.highlight)",e).map(n=>Pn(n,{target$:r,print$:o})),...P("pre:not(.mermaid) > code",e).map(n=>jn(n,{target$:r,print$:o})),...P("pre.mermaid",e).map(n=>Wn(n)),...P("table:not([class])",e).map(n=>Vn(n)),...P("details",e).map(n=>Fn(n,{target$:r,print$:o})),...P("[data-tabs]",e).map(n=>Nn(n,{viewport$:t,target$:r})),...P("[title]",e).filter(()=>B("content.tooltips")).map(n=>mt(n,{viewport$:t})))}function Ba(e,{alert$:t}){return t.pipe(v(r=>O(I(!0),I(!1).pipe(Ge(2e3))).pipe(m(o=>({message:r,active:o})))))}function qn(e,t){let r=R(".md-typeset",e);return C(()=>{let o=new g;return o.subscribe(({message:n,active:i})=>{e.classList.toggle("md-dialog--active",i),r.textContent=n}),Ba(e,t).pipe(w(n=>o.next(n)),_(()=>o.complete()),m(n=>$({ref:e},n)))})}var Ga=0;function Ja(e,t){document.body.append(e);let{width:r}=ce(e);e.style.setProperty("--md-tooltip-width",`${r}px`),e.remove();let o=cr(t),n=typeof o!="undefined"?Ne(o):I({x:0,y:0}),i=O(et(t),$t(t)).pipe(K());return z([i,n]).pipe(m(([a,s])=>{let{x:p,y:c}=Ve(t),l=ce(t),f=t.closest("table");return f&&t.parentElement&&(p+=f.offsetLeft+t.parentElement.offsetLeft,c+=f.offsetTop+t.parentElement.offsetTop),{active:a,offset:{x:p-s.x+l.width/2-r/2,y:c-s.y+l.height+8}}}))}function Qn(e){let t=e.title;if(!t.length)return S;let r=`__tooltip_${Ga++}`,o=Rt(r,"inline"),n=R(".md-typeset",o);return n.innerHTML=t,C(()=>{let i=new g;return i.subscribe({next({offset:a}){o.style.setProperty("--md-tooltip-x",`${a.x}px`),o.style.setProperty("--md-tooltip-y",`${a.y}px`)},complete(){o.style.removeProperty("--md-tooltip-x"),o.style.removeProperty("--md-tooltip-y")}}),O(i.pipe(b(({active:a})=>a)),i.pipe(_e(250),b(({active:a})=>!a))).subscribe({next({active:a}){a?(e.insertAdjacentElement("afterend",o),e.setAttribute("aria-describedby",r),e.removeAttribute("title")):(o.remove(),e.removeAttribute("aria-describedby"),e.setAttribute("title",t))},complete(){o.remove(),e.removeAttribute("aria-describedby"),e.setAttribute("title",t)}}),i.pipe(Me(16,me)).subscribe(({active:a})=>{o.classList.toggle("md-tooltip--active",a)}),i.pipe(pt(125,me),b(()=>!!e.offsetParent),m(()=>e.offsetParent.getBoundingClientRect()),m(({x:a})=>a)).subscribe({next(a){a?o.style.setProperty("--md-tooltip-0",`${-a}px`):o.style.removeProperty("--md-tooltip-0")},complete(){o.style.removeProperty("--md-tooltip-0")}}),Ja(o,e).pipe(w(a=>i.next(a)),_(()=>i.complete()),m(a=>$({ref:e},a)))}).pipe(Ke(se))}function Xa({viewport$:e}){if(!B("header.autohide"))return I(!1);let t=e.pipe(m(({offset:{y:n}})=>n),Be(2,1),m(([n,i])=>[n<i,i]),ee(0)),r=z([e,t]).pipe(b(([{offset:n},[,i]])=>Math.abs(i-n.y)>100),m(([,[n]])=>n),K()),o=ze("search");return z([e,o]).pipe(m(([{offset:n},i])=>n.y>400&&!i),K(),v(n=>n?r:I(!1)),Q(!1))}function Kn(e,t){return C(()=>z([ge(e),Xa(t)])).pipe(m(([{height:r},o])=>({height:r,hidden:o})),K((r,o)=>r.height===o.height&&r.hidden===o.hidden),G(1))}function Yn(e,{header$:t,main$:r}){return C(()=>{let o=new g,n=o.pipe(Z(),ie(!0));o.pipe(ee("active"),He(t)).subscribe(([{active:a},{hidden:s}])=>{e.classList.toggle("md-header--shadow",a&&!s),e.hidden=s});let i=ue(P("[title]",e)).pipe(b(()=>B("content.tooltips")),ne(a=>Qn(a)));return r.subscribe(o),t.pipe(W(n),m(a=>$({ref:e},a)),Re(i.pipe(W(n))))})}function Za(e,{viewport$:t,header$:r}){return mr(e,{viewport$:t,header$:r}).pipe(m(({offset:{y:o}})=>{let{height:n}=ce(e);return{active:o>=n}}),ee("active"))}function Bn(e,t){return C(()=>{let r=new g;r.subscribe({next({active:n}){e.classList.toggle("md-header__title--active",n)},complete(){e.classList.remove("md-header__title--active")}});let o=fe(".md-content h1");return typeof o=="undefined"?S:Za(o,t).pipe(w(n=>r.next(n)),_(()=>r.complete()),m(n=>$({ref:e},n)))})}function Gn(e,{viewport$:t,header$:r}){let o=r.pipe(m(({height:i})=>i),K()),n=o.pipe(v(()=>ge(e).pipe(m(({height:i})=>({top:e.offsetTop,bottom:e.offsetTop+i})),ee("bottom"))));return z([o,n,t]).pipe(m(([i,{top:a,bottom:s},{offset:{y:p},size:{height:c}}])=>(c=Math.max(0,c-Math.max(0,a-p,i)-Math.max(0,c+p-s)),{offset:a-i,height:c,active:a-i<=p})),K((i,a)=>i.offset===a.offset&&i.height===a.height&&i.active===a.active))}function es(e){let t=__md_get("__palette")||{index:e.findIndex(o=>matchMedia(o.getAttribute("data-md-color-media")).matches)},r=Math.max(0,Math.min(t.index,e.length-1));return I(...e).pipe(ne(o=>h(o,"change").pipe(m(()=>o))),Q(e[r]),m(o=>({index:e.indexOf(o),color:{media:o.getAttribute("data-md-color-media"),scheme:o.getAttribute("data-md-color-scheme"),primary:o.getAttribute("data-md-color-primary"),accent:o.getAttribute("data-md-color-accent")}})),G(1))}function Jn(e){let t=P("input",e),r=x("meta",{name:"theme-color"});document.head.appendChild(r);let o=x("meta",{name:"color-scheme"});document.head.appendChild(o);let n=Pt("(prefers-color-scheme: light)");return C(()=>{let i=new g;return i.subscribe(a=>{if(document.body.setAttribute("data-md-color-switching",""),a.color.media==="(prefers-color-scheme)"){let s=matchMedia("(prefers-color-scheme: light)"),p=document.querySelector(s.matches?"[data-md-color-media='(prefers-color-scheme: light)']":"[data-md-color-media='(prefers-color-scheme: dark)']");a.color.scheme=p.getAttribute("data-md-color-scheme"),a.color.primary=p.getAttribute("data-md-color-primary"),a.color.accent=p.getAttribute("data-md-color-accent")}for(let[s,p]of Object.entries(a.color))document.body.setAttribute(`data-md-color-${s}`,p);for(let s=0;s<t.length;s++){let p=t[s].nextElementSibling;p instanceof HTMLElement&&(p.hidden=a.index!==s)}__md_set("__palette",a)}),h(e,"keydown").pipe(b(a=>a.key==="Enter"),re(i,(a,s)=>s)).subscribe(({index:a})=>{a=(a+1)%t.length,t[a].click(),t[a].focus()}),i.pipe(m(()=>{let a=Se("header"),s=window.getComputedStyle(a);return o.content=s.colorScheme,s.backgroundColor.match(/\d+/g).map(p=>(+p).toString(16).padStart(2,"0")).join("")})).subscribe(a=>r.content=`#${a}`),i.pipe(ve(se)).subscribe(()=>{document.body.removeAttribute("data-md-color-switching")}),es(t).pipe(W(n.pipe(Ce(1))),ct(),w(a=>i.next(a)),_(()=>i.complete()),m(a=>$({ref:e},a)))})}function Xn(e,{progress$:t}){return C(()=>{let r=new g;return r.subscribe(({value:o})=>{e.style.setProperty("--md-progress-value",`${o}`)}),t.pipe(w(o=>r.next({value:o})),_(()=>r.complete()),m(o=>({ref:e,value:o})))})}var Jr=Mt(Br());function ts(e){e.setAttribute("data-md-copying","");let t=e.closest("[data-copy]"),r=t?t.getAttribute("data-copy"):e.innerText;return e.removeAttribute("data-md-copying"),r.trimEnd()}function Zn({alert$:e}){Jr.default.isSupported()&&new j(t=>{new Jr.default("[data-clipboard-target], [data-clipboard-text]",{text:r=>r.getAttribute("data-clipboard-text")||ts(R(r.getAttribute("data-clipboard-target")))}).on("success",r=>t.next(r))}).pipe(w(t=>{t.trigger.focus()}),m(()=>Ee("clipboard.copied"))).subscribe(e)}function ei(e,t){return e.protocol=t.protocol,e.hostname=t.hostname,e}function rs(e,t){let r=new Map;for(let o of P("url",e)){let n=R("loc",o),i=[ei(new URL(n.textContent),t)];r.set(`${i[0]}`,i);for(let a of P("[rel=alternate]",o)){let s=a.getAttribute("href");s!=null&&i.push(ei(new URL(s),t))}}return r}function ur(e){return un(new URL("sitemap.xml",e)).pipe(m(t=>rs(t,new URL(e))),de(()=>I(new Map)))}function os(e,t){if(!(e.target instanceof Element))return S;let r=e.target.closest("a");if(r===null)return S;if(r.target||e.metaKey||e.ctrlKey)return S;let o=new URL(r.href);return o.search=o.hash="",t.has(`${o}`)?(e.preventDefault(),I(new URL(r.href))):S}function ti(e){let t=new Map;for(let r of P(":scope > *",e.head))t.set(r.outerHTML,r);return t}function ri(e){for(let t of P("[href], [src]",e))for(let r of["href","src"]){let o=t.getAttribute(r);if(o&&!/^(?:[a-z]+:)?\/\//i.test(o)){t[r]=t[r];break}}return I(e)}function ns(e){for(let o of["[data-md-component=announce]","[data-md-component=container]","[data-md-component=header-topic]","[data-md-component=outdated]","[data-md-component=logo]","[data-md-component=skip]",...B("navigation.tabs.sticky")?["[data-md-component=tabs]"]:[]]){let n=fe(o),i=fe(o,e);typeof n!="undefined"&&typeof i!="undefined"&&n.replaceWith(i)}let t=ti(document);for(let[o,n]of ti(e))t.has(o)?t.delete(o):document.head.appendChild(n);for(let o of t.values()){let n=o.getAttribute("name");n!=="theme-color"&&n!=="color-scheme"&&o.remove()}let r=Se("container");return We(P("script",r)).pipe(v(o=>{let n=e.createElement("script");if(o.src){for(let i of o.getAttributeNames())n.setAttribute(i,o.getAttribute(i));return o.replaceWith(n),new j(i=>{n.onload=()=>i.complete()})}else return n.textContent=o.textContent,o.replaceWith(n),S}),Z(),ie(document))}function oi({location$:e,viewport$:t,progress$:r}){let o=xe();if(location.protocol==="file:")return S;let n=ur(o.base);I(document).subscribe(ri);let i=h(document.body,"click").pipe(He(n),v(([p,c])=>os(p,c)),pe()),a=h(window,"popstate").pipe(m(ye),pe());i.pipe(re(t)).subscribe(([p,{offset:c}])=>{history.replaceState(c,""),history.pushState(null,"",p)}),O(i,a).subscribe(e);let s=e.pipe(ee("pathname"),v(p=>fn(p,{progress$:r}).pipe(de(()=>(lt(p,!0),S)))),v(ri),v(ns),pe());return O(s.pipe(re(e,(p,c)=>c)),s.pipe(v(()=>e),ee("pathname"),v(()=>e),ee("hash")),e.pipe(K((p,c)=>p.pathname===c.pathname&&p.hash===c.hash),v(()=>i),w(()=>history.back()))).subscribe(p=>{var c,l;history.state!==null||!p.hash?window.scrollTo(0,(l=(c=history.state)==null?void 0:c.y)!=null?l:0):(history.scrollRestoration="auto",pn(p.hash),history.scrollRestoration="manual")}),e.subscribe(()=>{history.scrollRestoration="manual"}),h(window,"beforeunload").subscribe(()=>{history.scrollRestoration="auto"}),t.pipe(ee("offset"),_e(100)).subscribe(({offset:p})=>{history.replaceState(p,"")}),s}var ni=Mt(qr());function ii(e){let t=e.separator.split("|").map(n=>n.replace(/(\(\?[!=<][^)]+\))/g,"").length===0?"\uFFFD":n).join("|"),r=new RegExp(t,"img"),o=(n,i,a)=>`${i}<mark data-md-highlight>${a}</mark>`;return n=>{n=n.replace(/[\s*+\-:~^]+/g," ").trim();let i=new RegExp(`(^|${e.separator}|)(${n.replace(/[|\\{}()[\]^$+*?.-]/g,"\\$&").replace(r,"|")})`,"img");return a=>(0,ni.default)(a).replace(i,o).replace(/<\/mark>(\s+)<mark[^>]*>/img,"$1")}}function jt(e){return e.type===1}function dr(e){return e.type===3}function ai(e,t){let r=yn(e);return O(I(location.protocol!=="file:"),ze("search")).pipe(Ae(o=>o),v(()=>t)).subscribe(({config:o,docs:n})=>r.next({type:0,data:{config:o,docs:n,options:{suggest:B("search.suggest")}}})),r}function si(e){var l;let{selectedVersionSitemap:t,selectedVersionBaseURL:r,currentLocation:o,currentBaseURL:n}=e,i=(l=Xr(n))==null?void 0:l.pathname;if(i===void 0)return;let a=ss(o.pathname,i);if(a===void 0)return;let s=ps(t.keys());if(!t.has(s))return;let p=Xr(a,s);if(!p||!t.has(p.href))return;let c=Xr(a,r);if(c)return c.hash=o.hash,c.search=o.search,c}function Xr(e,t){try{return new URL(e,t)}catch(r){return}}function ss(e,t){if(e.startsWith(t))return e.slice(t.length)}function cs(e,t){let r=Math.min(e.length,t.length),o;for(o=0;o<r&&e[o]===t[o];++o);return o}function ps(e){let t;for(let r of e)t===void 0?t=r:t=t.slice(0,cs(t,r));return t!=null?t:""}function ci({document$:e}){let t=xe(),r=je(new URL("../versions.json",t.base)).pipe(de(()=>S)),o=r.pipe(m(n=>{let[,i]=t.base.match(/([^/]+)\/?$/);return n.find(({version:a,aliases:s})=>a===i||s.includes(i))||n[0]}));r.pipe(m(n=>new Map(n.map(i=>[`${new URL(`../${i.version}/`,t.base)}`,i]))),v(n=>h(document.body,"click").pipe(b(i=>!i.metaKey&&!i.ctrlKey),re(o),v(([i,a])=>{if(i.target instanceof Element){let s=i.target.closest("a");if(s&&!s.target&&n.has(s.href)){let p=s.href;return!i.target.closest(".md-version")&&n.get(p)===a?S:(i.preventDefault(),I(new URL(p)))}}return S}),v(i=>ur(i).pipe(m(a=>{var s;return(s=si({selectedVersionSitemap:a,selectedVersionBaseURL:i,currentLocation:ye(),currentBaseURL:t.base}))!=null?s:i})))))).subscribe(n=>lt(n,!0)),z([r,o]).subscribe(([n,i])=>{R(".md-header__topic").appendChild(Cn(n,i))}),e.pipe(v(()=>o)).subscribe(n=>{var a;let i=__md_get("__outdated",sessionStorage);if(i===null){i=!0;let s=((a=t.version)==null?void 0:a.default)||"latest";Array.isArray(s)||(s=[s]);e:for(let p of s)for(let c of n.aliases.concat(n.version))if(new RegExp(p,"i").test(c)){i=!1;break e}__md_set("__outdated",i,sessionStorage)}if(i)for(let s of ae("outdated"))s.hidden=!1})}function ls(e,{worker$:t}){let{searchParams:r}=ye();r.has("q")&&(Je("search",!0),e.value=r.get("q"),e.focus(),ze("search").pipe(Ae(i=>!i)).subscribe(()=>{let i=ye();i.searchParams.delete("q"),history.replaceState({},"",`${i}`)}));let o=et(e),n=O(t.pipe(Ae(jt)),h(e,"keyup"),o).pipe(m(()=>e.value),K());return z([n,o]).pipe(m(([i,a])=>({value:i,focus:a})),G(1))}function pi(e,{worker$:t}){let r=new g,o=r.pipe(Z(),ie(!0));z([t.pipe(Ae(jt)),r],(i,a)=>a).pipe(ee("value")).subscribe(({value:i})=>t.next({type:2,data:i})),r.pipe(ee("focus")).subscribe(({focus:i})=>{i&&Je("search",i)}),h(e.form,"reset").pipe(W(o)).subscribe(()=>e.focus());let n=R("header [for=__search]");return h(n,"click").subscribe(()=>e.focus()),ls(e,{worker$:t}).pipe(w(i=>r.next(i)),_(()=>r.complete()),m(i=>$({ref:e},i)),G(1))}function li(e,{worker$:t,query$:r}){let o=new g,n=on(e.parentElement).pipe(b(Boolean)),i=e.parentElement,a=R(":scope > :first-child",e),s=R(":scope > :last-child",e);ze("search").subscribe(l=>s.setAttribute("role",l?"list":"presentation")),o.pipe(re(r),Wr(t.pipe(Ae(jt)))).subscribe(([{items:l},{value:f}])=>{switch(l.length){case 0:a.textContent=f.length?Ee("search.result.none"):Ee("search.result.placeholder");break;case 1:a.textContent=Ee("search.result.one");break;default:let u=sr(l.length);a.textContent=Ee("search.result.other",u)}});let p=o.pipe(w(()=>s.innerHTML=""),v(({items:l})=>O(I(...l.slice(0,10)),I(...l.slice(10)).pipe(Be(4),Vr(n),v(([f])=>f)))),m(Mn),pe());return p.subscribe(l=>s.appendChild(l)),p.pipe(ne(l=>{let f=fe("details",l);return typeof f=="undefined"?S:h(f,"toggle").pipe(W(o),m(()=>f))})).subscribe(l=>{l.open===!1&&l.offsetTop<=i.scrollTop&&i.scrollTo({top:l.offsetTop})}),t.pipe(b(dr),m(({data:l})=>l)).pipe(w(l=>o.next(l)),_(()=>o.complete()),m(l=>$({ref:e},l)))}function ms(e,{query$:t}){return t.pipe(m(({value:r})=>{let o=ye();return o.hash="",r=r.replace(/\s+/g,"+").replace(/&/g,"%26").replace(/=/g,"%3D"),o.search=`q=${r}`,{url:o}}))}function mi(e,t){let r=new g,o=r.pipe(Z(),ie(!0));return r.subscribe(({url:n})=>{e.setAttribute("data-clipboard-text",e.href),e.href=`${n}`}),h(e,"click").pipe(W(o)).subscribe(n=>n.preventDefault()),ms(e,t).pipe(w(n=>r.next(n)),_(()=>r.complete()),m(n=>$({ref:e},n)))}function fi(e,{worker$:t,keyboard$:r}){let o=new g,n=Se("search-query"),i=O(h(n,"keydown"),h(n,"focus")).pipe(ve(se),m(()=>n.value),K());return o.pipe(He(i),m(([{suggest:s},p])=>{let c=p.split(/([\s-]+)/);if(s!=null&&s.length&&c[c.length-1]){let l=s[s.length-1];l.startsWith(c[c.length-1])&&(c[c.length-1]=l)}else c.length=0;return c})).subscribe(s=>e.innerHTML=s.join("").replace(/\s/g,"&nbsp;")),r.pipe(b(({mode:s})=>s==="search")).subscribe(s=>{switch(s.type){case"ArrowRight":e.innerText.length&&n.selectionStart===n.value.length&&(n.value=e.innerText);break}}),t.pipe(b(dr),m(({data:s})=>s)).pipe(w(s=>o.next(s)),_(()=>o.complete()),m(()=>({ref:e})))}function ui(e,{index$:t,keyboard$:r}){let o=xe();try{let n=ai(o.search,t),i=Se("search-query",e),a=Se("search-result",e);h(e,"click").pipe(b(({target:p})=>p instanceof Element&&!!p.closest("a"))).subscribe(()=>Je("search",!1)),r.pipe(b(({mode:p})=>p==="search")).subscribe(p=>{let c=Ie();switch(p.type){case"Enter":if(c===i){let l=new Map;for(let f of P(":first-child [href]",a)){let u=f.firstElementChild;l.set(f,parseFloat(u.getAttribute("data-md-score")))}if(l.size){let[[f]]=[...l].sort(([,u],[,d])=>d-u);f.click()}p.claim()}break;case"Escape":case"Tab":Je("search",!1),i.blur();break;case"ArrowUp":case"ArrowDown":if(typeof c=="undefined")i.focus();else{let l=[i,...P(":not(details) > [href], summary, details[open] [href]",a)],f=Math.max(0,(Math.max(0,l.indexOf(c))+l.length+(p.type==="ArrowUp"?-1:1))%l.length);l[f].focus()}p.claim();break;default:i!==Ie()&&i.focus()}}),r.pipe(b(({mode:p})=>p==="global")).subscribe(p=>{switch(p.type){case"f":case"s":case"/":i.focus(),i.select(),p.claim();break}});let s=pi(i,{worker$:n});return O(s,li(a,{worker$:n,query$:s})).pipe(Re(...ae("search-share",e).map(p=>mi(p,{query$:s})),...ae("search-suggest",e).map(p=>fi(p,{worker$:n,keyboard$:r}))))}catch(n){return e.hidden=!0,Ye}}function di(e,{index$:t,location$:r}){return z([t,r.pipe(Q(ye()),b(o=>!!o.searchParams.get("h")))]).pipe(m(([o,n])=>ii(o.config)(n.searchParams.get("h"))),m(o=>{var a;let n=new Map,i=document.createNodeIterator(e,NodeFilter.SHOW_TEXT);for(let s=i.nextNode();s;s=i.nextNode())if((a=s.parentElement)!=null&&a.offsetHeight){let p=s.textContent,c=o(p);c.length>p.length&&n.set(s,c)}for(let[s,p]of n){let{childNodes:c}=x("span",null,p);s.replaceWith(...Array.from(c))}return{ref:e,nodes:n}}))}function fs(e,{viewport$:t,main$:r}){let o=e.closest(".md-grid"),n=o.offsetTop-o.parentElement.offsetTop;return z([r,t]).pipe(m(([{offset:i,height:a},{offset:{y:s}}])=>(a=a+Math.min(n,Math.max(0,s-i))-n,{height:a,locked:s>=i+n})),K((i,a)=>i.height===a.height&&i.locked===a.locked))}function Zr(e,o){var n=o,{header$:t}=n,r=so(n,["header$"]);let i=R(".md-sidebar__scrollwrap",e),{y:a}=Ve(i);return C(()=>{let s=new g,p=s.pipe(Z(),ie(!0)),c=s.pipe(Me(0,me));return c.pipe(re(t)).subscribe({next([{height:l},{height:f}]){i.style.height=`${l-2*a}px`,e.style.top=`${f}px`},complete(){i.style.height="",e.style.top=""}}),c.pipe(Ae()).subscribe(()=>{for(let l of P(".md-nav__link--active[href]",e)){if(!l.clientHeight)continue;let f=l.closest(".md-sidebar__scrollwrap");if(typeof f!="undefined"){let u=l.offsetTop-f.offsetTop,{height:d}=ce(f);f.scrollTo({top:u-d/2})}}}),ue(P("label[tabindex]",e)).pipe(ne(l=>h(l,"click").pipe(ve(se),m(()=>l),W(p)))).subscribe(l=>{let f=R(`[id="${l.htmlFor}"]`);R(`[aria-labelledby="${l.id}"]`).setAttribute("aria-expanded",`${f.checked}`)}),fs(e,r).pipe(w(l=>s.next(l)),_(()=>s.complete()),m(l=>$({ref:e},l)))})}function hi(e,t){if(typeof t!="undefined"){let r=`https://api.github.com/repos/${e}/${t}`;return st(je(`${r}/releases/latest`).pipe(de(()=>S),m(o=>({version:o.tag_name})),De({})),je(r).pipe(de(()=>S),m(o=>({stars:o.stargazers_count,forks:o.forks_count})),De({}))).pipe(m(([o,n])=>$($({},o),n)))}else{let r=`https://api.github.com/users/${e}`;return je(r).pipe(m(o=>({repositories:o.public_repos})),De({}))}}function bi(e,t){let r=`https://${e}/api/v4/projects/${encodeURIComponent(t)}`;return st(je(`${r}/releases/permalink/latest`).pipe(de(()=>S),m(({tag_name:o})=>({version:o})),De({})),je(r).pipe(de(()=>S),m(({star_count:o,forks_count:n})=>({stars:o,forks:n})),De({}))).pipe(m(([o,n])=>$($({},o),n)))}function vi(e){let t=e.match(/^.+github\.com\/([^/]+)\/?([^/]+)?/i);if(t){let[,r,o]=t;return hi(r,o)}if(t=e.match(/^.+?([^/]*gitlab[^/]+)\/(.+?)\/?$/i),t){let[,r,o]=t;return bi(r,o)}return S}var us;function ds(e){return us||(us=C(()=>{let t=__md_get("__source",sessionStorage);if(t)return I(t);if(ae("consent").length){let o=__md_get("__consent");if(!(o&&o.github))return S}return vi(e.href).pipe(w(o=>__md_set("__source",o,sessionStorage)))}).pipe(de(()=>S),b(t=>Object.keys(t).length>0),m(t=>({facts:t})),G(1)))}function gi(e){let t=R(":scope > :last-child",e);return C(()=>{let r=new g;return r.subscribe(({facts:o})=>{t.appendChild(_n(o)),t.classList.add("md-source__repository--active")}),ds(e).pipe(w(o=>r.next(o)),_(()=>r.complete()),m(o=>$({ref:e},o)))})}function hs(e,{viewport$:t,header$:r}){return ge(document.body).pipe(v(()=>mr(e,{header$:r,viewport$:t})),m(({offset:{y:o}})=>({hidden:o>=10})),ee("hidden"))}function yi(e,t){return C(()=>{let r=new g;return r.subscribe({next({hidden:o}){e.hidden=o},complete(){e.hidden=!1}}),(B("navigation.tabs.sticky")?I({hidden:!1}):hs(e,t)).pipe(w(o=>r.next(o)),_(()=>r.complete()),m(o=>$({ref:e},o)))})}function bs(e,{viewport$:t,header$:r}){let o=new Map,n=P(".md-nav__link",e);for(let s of n){let p=decodeURIComponent(s.hash.substring(1)),c=fe(`[id="${p}"]`);typeof c!="undefined"&&o.set(s,c)}let i=r.pipe(ee("height"),m(({height:s})=>{let p=Se("main"),c=R(":scope > :first-child",p);return s+.8*(c.offsetTop-p.offsetTop)}),pe());return ge(document.body).pipe(ee("height"),v(s=>C(()=>{let p=[];return I([...o].reduce((c,[l,f])=>{for(;p.length&&o.get(p[p.length-1]).tagName>=f.tagName;)p.pop();let u=f.offsetTop;for(;!u&&f.parentElement;)f=f.parentElement,u=f.offsetTop;let d=f.offsetParent;for(;d;d=d.offsetParent)u+=d.offsetTop;return c.set([...p=[...p,l]].reverse(),u)},new Map))}).pipe(m(p=>new Map([...p].sort(([,c],[,l])=>c-l))),He(i),v(([p,c])=>t.pipe(Fr(([l,f],{offset:{y:u},size:d})=>{let y=u+d.height>=Math.floor(s.height);for(;f.length;){let[,L]=f[0];if(L-c<u||y)l=[...l,f.shift()];else break}for(;l.length;){let[,L]=l[l.length-1];if(L-c>=u&&!y)f=[l.pop(),...f];else break}return[l,f]},[[],[...p]]),K((l,f)=>l[0]===f[0]&&l[1]===f[1])))))).pipe(m(([s,p])=>({prev:s.map(([c])=>c),next:p.map(([c])=>c)})),Q({prev:[],next:[]}),Be(2,1),m(([s,p])=>s.prev.length<p.prev.length?{prev:p.prev.slice(Math.max(0,s.prev.length-1),p.prev.length),next:[]}:{prev:p.prev.slice(-1),next:p.next.slice(0,p.next.length-s.next.length)}))}function xi(e,{viewport$:t,header$:r,main$:o,target$:n}){return C(()=>{let i=new g,a=i.pipe(Z(),ie(!0));if(i.subscribe(({prev:s,next:p})=>{for(let[c]of p)c.classList.remove("md-nav__link--passed"),c.classList.remove("md-nav__link--active");for(let[c,[l]]of s.entries())l.classList.add("md-nav__link--passed"),l.classList.toggle("md-nav__link--active",c===s.length-1)}),B("toc.follow")){let s=O(t.pipe(_e(1),m(()=>{})),t.pipe(_e(250),m(()=>"smooth")));i.pipe(b(({prev:p})=>p.length>0),He(o.pipe(ve(se))),re(s)).subscribe(([[{prev:p}],c])=>{let[l]=p[p.length-1];if(l.offsetHeight){let f=cr(l);if(typeof f!="undefined"){let u=l.offsetTop-f.offsetTop,{height:d}=ce(f);f.scrollTo({top:u-d/2,behavior:c})}}})}return B("navigation.tracking")&&t.pipe(W(a),ee("offset"),_e(250),Ce(1),W(n.pipe(Ce(1))),ct({delay:250}),re(i)).subscribe(([,{prev:s}])=>{let p=ye(),c=s[s.length-1];if(c&&c.length){let[l]=c,{hash:f}=new URL(l.href);p.hash!==f&&(p.hash=f,history.replaceState({},"",`${p}`))}else p.hash="",history.replaceState({},"",`${p}`)}),bs(e,{viewport$:t,header$:r}).pipe(w(s=>i.next(s)),_(()=>i.complete()),m(s=>$({ref:e},s)))})}function vs(e,{viewport$:t,main$:r,target$:o}){let n=t.pipe(m(({offset:{y:a}})=>a),Be(2,1),m(([a,s])=>a>s&&s>0),K()),i=r.pipe(m(({active:a})=>a));return z([i,n]).pipe(m(([a,s])=>!(a&&s)),K(),W(o.pipe(Ce(1))),ie(!0),ct({delay:250}),m(a=>({hidden:a})))}function Ei(e,{viewport$:t,header$:r,main$:o,target$:n}){let i=new g,a=i.pipe(Z(),ie(!0));return i.subscribe({next({hidden:s}){e.hidden=s,s?(e.setAttribute("tabindex","-1"),e.blur()):e.removeAttribute("tabindex")},complete(){e.style.top="",e.hidden=!0,e.removeAttribute("tabindex")}}),r.pipe(W(a),ee("height")).subscribe(({height:s})=>{e.style.top=`${s+16}px`}),h(e,"click").subscribe(s=>{s.preventDefault(),window.scrollTo({top:0})}),vs(e,{viewport$:t,main$:o,target$:n}).pipe(w(s=>i.next(s)),_(()=>i.complete()),m(s=>$({ref:e},s)))}function wi({document$:e,viewport$:t}){e.pipe(v(()=>P(".md-ellipsis")),ne(r=>tt(r).pipe(W(e.pipe(Ce(1))),b(o=>o),m(()=>r),Te(1))),b(r=>r.offsetWidth<r.scrollWidth),ne(r=>{let o=r.innerText,n=r.closest("a")||r;return n.title=o,B("content.tooltips")?mt(n,{viewport$:t}).pipe(W(e.pipe(Ce(1))),_(()=>n.removeAttribute("title"))):S})).subscribe(),B("content.tooltips")&&e.pipe(v(()=>P(".md-status")),ne(r=>mt(r,{viewport$:t}))).subscribe()}function Ti({document$:e,tablet$:t}){e.pipe(v(()=>P(".md-toggle--indeterminate")),w(r=>{r.indeterminate=!0,r.checked=!1}),ne(r=>h(r,"change").pipe(Dr(()=>r.classList.contains("md-toggle--indeterminate")),m(()=>r))),re(t)).subscribe(([r,o])=>{r.classList.remove("md-toggle--indeterminate"),o&&(r.checked=!1)})}function gs(){return/(iPad|iPhone|iPod)/.test(navigator.userAgent)}function Si({document$:e}){e.pipe(v(()=>P("[data-md-scrollfix]")),w(t=>t.removeAttribute("data-md-scrollfix")),b(gs),ne(t=>h(t,"touchstart").pipe(m(()=>t)))).subscribe(t=>{let r=t.scrollTop;r===0?t.scrollTop=1:r+t.offsetHeight===t.scrollHeight&&(t.scrollTop=r-1)})}function Oi({viewport$:e,tablet$:t}){z([ze("search"),t]).pipe(m(([r,o])=>r&&!o),v(r=>I(r).pipe(Ge(r?400:100))),re(e)).subscribe(([r,{offset:{y:o}}])=>{if(r)document.body.setAttribute("data-md-scrolllock",""),document.body.style.top=`-${o}px`;else{let n=-1*parseInt(document.body.style.top,10);document.body.removeAttribute("data-md-scrolllock"),document.body.style.top="",n&&window.scrollTo(0,n)}})}Object.entries||(Object.entries=function(e){let t=[];for(let r of Object.keys(e))t.push([r,e[r]]);return t});Object.values||(Object.values=function(e){let t=[];for(let r of Object.keys(e))t.push(e[r]);return t});typeof Element!="undefined"&&(Element.prototype.scrollTo||(Element.prototype.scrollTo=function(e,t){typeof e=="object"?(this.scrollLeft=e.left,this.scrollTop=e.top):(this.scrollLeft=e,this.scrollTop=t)}),Element.prototype.replaceWith||(Element.prototype.replaceWith=function(...e){let t=this.parentNode;if(t){e.length===0&&t.removeChild(this);for(let r=e.length-1;r>=0;r--){let o=e[r];typeof o=="string"?o=document.createTextNode(o):o.parentNode&&o.parentNode.removeChild(o),r?t.insertBefore(this.previousSibling,o):t.replaceChild(o,this)}}}));function ys(){return location.protocol==="file:"?Tt(`${new URL("search/search_index.js",eo.base)}`).pipe(m(()=>__index),G(1)):je(new URL("search/search_index.json",eo.base))}document.documentElement.classList.remove("no-js");document.documentElement.classList.add("js");var ot=Go(),Ut=sn(),Lt=ln(Ut),to=an(),Oe=gn(),hr=Pt("(min-width: 960px)"),Mi=Pt("(min-width: 1220px)"),_i=mn(),eo=xe(),Ai=document.forms.namedItem("search")?ys():Ye,ro=new g;Zn({alert$:ro});var oo=new g;B("navigation.instant")&&oi({location$:Ut,viewport$:Oe,progress$:oo}).subscribe(ot);var Li;((Li=eo.version)==null?void 0:Li.provider)==="mike"&&ci({document$:ot});O(Ut,Lt).pipe(Ge(125)).subscribe(()=>{Je("drawer",!1),Je("search",!1)});to.pipe(b(({mode:e})=>e==="global")).subscribe(e=>{switch(e.type){case"p":case",":let t=fe("link[rel=prev]");typeof t!="undefined"&&lt(t);break;case"n":case".":let r=fe("link[rel=next]");typeof r!="undefined"&&lt(r);break;case"Enter":let o=Ie();o instanceof HTMLLabelElement&&o.click()}});wi({viewport$:Oe,document$:ot});Ti({document$:ot,tablet$:hr});Si({document$:ot});Oi({viewport$:Oe,tablet$:hr});var rt=Kn(Se("header"),{viewport$:Oe}),Ft=ot.pipe(m(()=>Se("main")),v(e=>Gn(e,{viewport$:Oe,header$:rt})),G(1)),xs=O(...ae("consent").map(e=>En(e,{target$:Lt})),...ae("dialog").map(e=>qn(e,{alert$:ro})),...ae("palette").map(e=>Jn(e)),...ae("progress").map(e=>Xn(e,{progress$:oo})),...ae("search").map(e=>ui(e,{index$:Ai,keyboard$:to})),...ae("source").map(e=>gi(e))),Es=C(()=>O(...ae("announce").map(e=>xn(e)),...ae("content").map(e=>zn(e,{viewport$:Oe,target$:Lt,print$:_i})),...ae("content").map(e=>B("search.highlight")?di(e,{index$:Ai,location$:Ut}):S),...ae("header").map(e=>Yn(e,{viewport$:Oe,header$:rt,main$:Ft})),...ae("header-title").map(e=>Bn(e,{viewport$:Oe,header$:rt})),...ae("sidebar").map(e=>e.getAttribute("data-md-type")==="navigation"?Nr(Mi,()=>Zr(e,{viewport$:Oe,header$:rt,main$:Ft})):Nr(hr,()=>Zr(e,{viewport$:Oe,header$:rt,main$:Ft}))),...ae("tabs").map(e=>yi(e,{viewport$:Oe,header$:rt})),...ae("toc").map(e=>xi(e,{viewport$:Oe,header$:rt,main$:Ft,target$:Lt})),...ae("top").map(e=>Ei(e,{viewport$:Oe,header$:rt,main$:Ft,target$:Lt})))),Ci=ot.pipe(v(()=>Es),Re(xs),G(1));Ci.subscribe();window.document$=ot;window.location$=Ut;window.target$=Lt;window.keyboard$=to;window.viewport$=Oe;window.tablet$=hr;window.screen$=Mi;window.print$=_i;window.alert$=ro;window.progress$=oo;window.component$=Ci;})();
+//# sourceMappingURL=bundle.88dd0f4e.min.js.map
 
diff --git a/main/assets/javascripts/bundle.525ec568.min.js.map b/main/assets/javascripts/bundle.88dd0f4e.min.js.map
similarity index 82%
rename from main/assets/javascripts/bundle.525ec568.min.js.map
rename to main/assets/javascripts/bundle.88dd0f4e.min.js.map
index ef5d8d34a..dab2a8754 100644
--- a/main/assets/javascripts/bundle.525ec568.min.js.map
+++ b/main/assets/javascripts/bundle.88dd0f4e.min.js.map
@@ -1,7 +1,7 @@
 {
   "version": 3,
   "sources": ["node_modules/focus-visible/dist/focus-visible.js", "node_modules/escape-html/index.js", "node_modules/clipboard/dist/clipboard.js", "src/templates/assets/javascripts/bundle.ts", "node_modules/tslib/tslib.es6.mjs", "node_modules/rxjs/src/internal/util/isFunction.ts", "node_modules/rxjs/src/internal/util/createErrorClass.ts", "node_modules/rxjs/src/internal/util/UnsubscriptionError.ts", "node_modules/rxjs/src/internal/util/arrRemove.ts", "node_modules/rxjs/src/internal/Subscription.ts", "node_modules/rxjs/src/internal/config.ts", "node_modules/rxjs/src/internal/scheduler/timeoutProvider.ts", "node_modules/rxjs/src/internal/util/reportUnhandledError.ts", "node_modules/rxjs/src/internal/util/noop.ts", "node_modules/rxjs/src/internal/NotificationFactories.ts", "node_modules/rxjs/src/internal/util/errorContext.ts", "node_modules/rxjs/src/internal/Subscriber.ts", "node_modules/rxjs/src/internal/symbol/observable.ts", "node_modules/rxjs/src/internal/util/identity.ts", "node_modules/rxjs/src/internal/util/pipe.ts", "node_modules/rxjs/src/internal/Observable.ts", "node_modules/rxjs/src/internal/util/lift.ts", "node_modules/rxjs/src/internal/operators/OperatorSubscriber.ts", "node_modules/rxjs/src/internal/scheduler/animationFrameProvider.ts", "node_modules/rxjs/src/internal/util/ObjectUnsubscribedError.ts", "node_modules/rxjs/src/internal/Subject.ts", "node_modules/rxjs/src/internal/BehaviorSubject.ts", "node_modules/rxjs/src/internal/scheduler/dateTimestampProvider.ts", "node_modules/rxjs/src/internal/ReplaySubject.ts", "node_modules/rxjs/src/internal/scheduler/Action.ts", "node_modules/rxjs/src/internal/scheduler/intervalProvider.ts", "node_modules/rxjs/src/internal/scheduler/AsyncAction.ts", "node_modules/rxjs/src/internal/Scheduler.ts", "node_modules/rxjs/src/internal/scheduler/AsyncScheduler.ts", "node_modules/rxjs/src/internal/scheduler/async.ts", "node_modules/rxjs/src/internal/scheduler/QueueAction.ts", "node_modules/rxjs/src/internal/scheduler/QueueScheduler.ts", "node_modules/rxjs/src/internal/scheduler/queue.ts", "node_modules/rxjs/src/internal/scheduler/AnimationFrameAction.ts", "node_modules/rxjs/src/internal/scheduler/AnimationFrameScheduler.ts", "node_modules/rxjs/src/internal/scheduler/animationFrame.ts", "node_modules/rxjs/src/internal/observable/empty.ts", "node_modules/rxjs/src/internal/util/isScheduler.ts", "node_modules/rxjs/src/internal/util/args.ts", "node_modules/rxjs/src/internal/util/isArrayLike.ts", "node_modules/rxjs/src/internal/util/isPromise.ts", "node_modules/rxjs/src/internal/util/isInteropObservable.ts", "node_modules/rxjs/src/internal/util/isAsyncIterable.ts", "node_modules/rxjs/src/internal/util/throwUnobservableError.ts", "node_modules/rxjs/src/internal/symbol/iterator.ts", "node_modules/rxjs/src/internal/util/isIterable.ts", "node_modules/rxjs/src/internal/util/isReadableStreamLike.ts", "node_modules/rxjs/src/internal/observable/innerFrom.ts", "node_modules/rxjs/src/internal/util/executeSchedule.ts", "node_modules/rxjs/src/internal/operators/observeOn.ts", "node_modules/rxjs/src/internal/operators/subscribeOn.ts", "node_modules/rxjs/src/internal/scheduled/scheduleObservable.ts", "node_modules/rxjs/src/internal/scheduled/schedulePromise.ts", "node_modules/rxjs/src/internal/scheduled/scheduleArray.ts", "node_modules/rxjs/src/internal/scheduled/scheduleIterable.ts", "node_modules/rxjs/src/internal/scheduled/scheduleAsyncIterable.ts", "node_modules/rxjs/src/internal/scheduled/scheduleReadableStreamLike.ts", "node_modules/rxjs/src/internal/scheduled/scheduled.ts", "node_modules/rxjs/src/internal/observable/from.ts", "node_modules/rxjs/src/internal/observable/of.ts", "node_modules/rxjs/src/internal/observable/throwError.ts", "node_modules/rxjs/src/internal/util/EmptyError.ts", "node_modules/rxjs/src/internal/util/isDate.ts", "node_modules/rxjs/src/internal/operators/map.ts", "node_modules/rxjs/src/internal/util/mapOneOrManyArgs.ts", "node_modules/rxjs/src/internal/util/argsArgArrayOrObject.ts", "node_modules/rxjs/src/internal/util/createObject.ts", "node_modules/rxjs/src/internal/observable/combineLatest.ts", "node_modules/rxjs/src/internal/operators/mergeInternals.ts", "node_modules/rxjs/src/internal/operators/mergeMap.ts", "node_modules/rxjs/src/internal/operators/mergeAll.ts", "node_modules/rxjs/src/internal/operators/concatAll.ts", "node_modules/rxjs/src/internal/observable/concat.ts", "node_modules/rxjs/src/internal/observable/defer.ts", "node_modules/rxjs/src/internal/observable/fromEvent.ts", "node_modules/rxjs/src/internal/observable/fromEventPattern.ts", "node_modules/rxjs/src/internal/observable/timer.ts", "node_modules/rxjs/src/internal/observable/merge.ts", "node_modules/rxjs/src/internal/observable/never.ts", "node_modules/rxjs/src/internal/util/argsOrArgArray.ts", "node_modules/rxjs/src/internal/operators/filter.ts", "node_modules/rxjs/src/internal/observable/zip.ts", "node_modules/rxjs/src/internal/operators/audit.ts", "node_modules/rxjs/src/internal/operators/auditTime.ts", "node_modules/rxjs/src/internal/operators/bufferCount.ts", "node_modules/rxjs/src/internal/operators/catchError.ts", "node_modules/rxjs/src/internal/operators/scanInternals.ts", "node_modules/rxjs/src/internal/operators/combineLatest.ts", "node_modules/rxjs/src/internal/operators/combineLatestWith.ts", "node_modules/rxjs/src/internal/operators/debounce.ts", "node_modules/rxjs/src/internal/operators/debounceTime.ts", "node_modules/rxjs/src/internal/operators/defaultIfEmpty.ts", "node_modules/rxjs/src/internal/operators/take.ts", "node_modules/rxjs/src/internal/operators/ignoreElements.ts", "node_modules/rxjs/src/internal/operators/mapTo.ts", "node_modules/rxjs/src/internal/operators/delayWhen.ts", "node_modules/rxjs/src/internal/operators/delay.ts", "node_modules/rxjs/src/internal/operators/distinctUntilChanged.ts", "node_modules/rxjs/src/internal/operators/distinctUntilKeyChanged.ts", "node_modules/rxjs/src/internal/operators/throwIfEmpty.ts", "node_modules/rxjs/src/internal/operators/endWith.ts", "node_modules/rxjs/src/internal/operators/finalize.ts", "node_modules/rxjs/src/internal/operators/first.ts", "node_modules/rxjs/src/internal/operators/takeLast.ts", "node_modules/rxjs/src/internal/operators/merge.ts", "node_modules/rxjs/src/internal/operators/mergeWith.ts", "node_modules/rxjs/src/internal/operators/repeat.ts", "node_modules/rxjs/src/internal/operators/scan.ts", "node_modules/rxjs/src/internal/operators/share.ts", "node_modules/rxjs/src/internal/operators/shareReplay.ts", "node_modules/rxjs/src/internal/operators/skip.ts", "node_modules/rxjs/src/internal/operators/skipUntil.ts", "node_modules/rxjs/src/internal/operators/startWith.ts", "node_modules/rxjs/src/internal/operators/switchMap.ts", "node_modules/rxjs/src/internal/operators/takeUntil.ts", "node_modules/rxjs/src/internal/operators/takeWhile.ts", "node_modules/rxjs/src/internal/operators/tap.ts", "node_modules/rxjs/src/internal/operators/throttle.ts", "node_modules/rxjs/src/internal/operators/throttleTime.ts", "node_modules/rxjs/src/internal/operators/withLatestFrom.ts", "node_modules/rxjs/src/internal/operators/zip.ts", "node_modules/rxjs/src/internal/operators/zipWith.ts", "src/templates/assets/javascripts/browser/document/index.ts", "src/templates/assets/javascripts/browser/element/_/index.ts", "src/templates/assets/javascripts/browser/element/focus/index.ts", "src/templates/assets/javascripts/browser/element/hover/index.ts", "src/templates/assets/javascripts/utilities/h/index.ts", "src/templates/assets/javascripts/utilities/round/index.ts", "src/templates/assets/javascripts/browser/script/index.ts", "src/templates/assets/javascripts/browser/element/size/_/index.ts", "src/templates/assets/javascripts/browser/element/size/content/index.ts", "src/templates/assets/javascripts/browser/element/offset/_/index.ts", "src/templates/assets/javascripts/browser/element/offset/content/index.ts", "src/templates/assets/javascripts/browser/element/visibility/index.ts", "src/templates/assets/javascripts/browser/toggle/index.ts", "src/templates/assets/javascripts/browser/keyboard/index.ts", "src/templates/assets/javascripts/browser/location/_/index.ts", "src/templates/assets/javascripts/browser/location/hash/index.ts", "src/templates/assets/javascripts/browser/media/index.ts", "src/templates/assets/javascripts/browser/request/index.ts", "src/templates/assets/javascripts/browser/viewport/offset/index.ts", "src/templates/assets/javascripts/browser/viewport/size/index.ts", "src/templates/assets/javascripts/browser/viewport/_/index.ts", "src/templates/assets/javascripts/browser/viewport/at/index.ts", "src/templates/assets/javascripts/browser/worker/index.ts", "src/templates/assets/javascripts/_/index.ts", "src/templates/assets/javascripts/components/_/index.ts", "src/templates/assets/javascripts/components/announce/index.ts", "src/templates/assets/javascripts/components/consent/index.ts", "src/templates/assets/javascripts/templates/tooltip/index.tsx", "src/templates/assets/javascripts/templates/annotation/index.tsx", "src/templates/assets/javascripts/templates/clipboard/index.tsx", "src/templates/assets/javascripts/templates/search/index.tsx", "src/templates/assets/javascripts/templates/source/index.tsx", "src/templates/assets/javascripts/templates/tabbed/index.tsx", "src/templates/assets/javascripts/templates/table/index.tsx", "src/templates/assets/javascripts/templates/version/index.tsx", "src/templates/assets/javascripts/components/tooltip2/index.ts", "src/templates/assets/javascripts/components/content/annotation/_/index.ts", "src/templates/assets/javascripts/components/content/annotation/list/index.ts", "src/templates/assets/javascripts/components/content/annotation/block/index.ts", "src/templates/assets/javascripts/components/content/code/_/index.ts", "src/templates/assets/javascripts/components/content/details/index.ts", "src/templates/assets/javascripts/components/content/mermaid/index.css", "src/templates/assets/javascripts/components/content/mermaid/index.ts", "src/templates/assets/javascripts/components/content/table/index.ts", "src/templates/assets/javascripts/components/content/tabs/index.ts", "src/templates/assets/javascripts/components/content/_/index.ts", "src/templates/assets/javascripts/components/dialog/index.ts", "src/templates/assets/javascripts/components/tooltip/index.ts", "src/templates/assets/javascripts/components/header/_/index.ts", "src/templates/assets/javascripts/components/header/title/index.ts", "src/templates/assets/javascripts/components/main/index.ts", "src/templates/assets/javascripts/components/palette/index.ts", "src/templates/assets/javascripts/components/progress/index.ts", "src/templates/assets/javascripts/integrations/clipboard/index.ts", "src/templates/assets/javascripts/integrations/sitemap/index.ts", "src/templates/assets/javascripts/integrations/instant/index.ts", "src/templates/assets/javascripts/integrations/search/highlighter/index.ts", "src/templates/assets/javascripts/integrations/search/worker/message/index.ts", "src/templates/assets/javascripts/integrations/search/worker/_/index.ts", "src/templates/assets/javascripts/integrations/version/findurl/index.ts", "src/templates/assets/javascripts/integrations/version/index.ts", "src/templates/assets/javascripts/components/search/query/index.ts", "src/templates/assets/javascripts/components/search/result/index.ts", "src/templates/assets/javascripts/components/search/share/index.ts", "src/templates/assets/javascripts/components/search/suggest/index.ts", "src/templates/assets/javascripts/components/search/_/index.ts", "src/templates/assets/javascripts/components/search/highlight/index.ts", "src/templates/assets/javascripts/components/sidebar/index.ts", "src/templates/assets/javascripts/components/source/facts/github/index.ts", "src/templates/assets/javascripts/components/source/facts/gitlab/index.ts", "src/templates/assets/javascripts/components/source/facts/_/index.ts", "src/templates/assets/javascripts/components/source/_/index.ts", "src/templates/assets/javascripts/components/tabs/index.ts", "src/templates/assets/javascripts/components/toc/index.ts", "src/templates/assets/javascripts/components/top/index.ts", "src/templates/assets/javascripts/patches/ellipsis/index.ts", "src/templates/assets/javascripts/patches/indeterminate/index.ts", "src/templates/assets/javascripts/patches/scrollfix/index.ts", "src/templates/assets/javascripts/patches/scrolllock/index.ts", "src/templates/assets/javascripts/polyfills/index.ts"],
-  "sourcesContent": ["(function (global, factory) {\n  typeof exports === 'object' && typeof module !== 'undefined' ? factory() :\n  typeof define === 'function' && define.amd ? define(factory) :\n  (factory());\n}(this, (function () { 'use strict';\n\n  /**\n   * Applies the :focus-visible polyfill at the given scope.\n   * A scope in this case is either the top-level Document or a Shadow Root.\n   *\n   * @param {(Document|ShadowRoot)} scope\n   * @see https://github.com/WICG/focus-visible\n   */\n  function applyFocusVisiblePolyfill(scope) {\n    var hadKeyboardEvent = true;\n    var hadFocusVisibleRecently = false;\n    var hadFocusVisibleRecentlyTimeout = null;\n\n    var inputTypesAllowlist = {\n      text: true,\n      search: true,\n      url: true,\n      tel: true,\n      email: true,\n      password: true,\n      number: true,\n      date: true,\n      month: true,\n      week: true,\n      time: true,\n      datetime: true,\n      'datetime-local': true\n    };\n\n    /**\n     * Helper function for legacy browsers and iframes which sometimes focus\n     * elements like document, body, and non-interactive SVG.\n     * @param {Element} el\n     */\n    function isValidFocusTarget(el) {\n      if (\n        el &&\n        el !== document &&\n        el.nodeName !== 'HTML' &&\n        el.nodeName !== 'BODY' &&\n        'classList' in el &&\n        'contains' in el.classList\n      ) {\n        return true;\n      }\n      return false;\n    }\n\n    /**\n     * Computes whether the given element should automatically trigger the\n     * `focus-visible` class being added, i.e. whether it should always match\n     * `:focus-visible` when focused.\n     * @param {Element} el\n     * @return {boolean}\n     */\n    function focusTriggersKeyboardModality(el) {\n      var type = el.type;\n      var tagName = el.tagName;\n\n      if (tagName === 'INPUT' && inputTypesAllowlist[type] && !el.readOnly) {\n        return true;\n      }\n\n      if (tagName === 'TEXTAREA' && !el.readOnly) {\n        return true;\n      }\n\n      if (el.isContentEditable) {\n        return true;\n      }\n\n      return false;\n    }\n\n    /**\n     * Add the `focus-visible` class to the given element if it was not added by\n     * the author.\n     * @param {Element} el\n     */\n    function addFocusVisibleClass(el) {\n      if (el.classList.contains('focus-visible')) {\n        return;\n      }\n      el.classList.add('focus-visible');\n      el.setAttribute('data-focus-visible-added', '');\n    }\n\n    /**\n     * Remove the `focus-visible` class from the given element if it was not\n     * originally added by the author.\n     * @param {Element} el\n     */\n    function removeFocusVisibleClass(el) {\n      if (!el.hasAttribute('data-focus-visible-added')) {\n        return;\n      }\n      el.classList.remove('focus-visible');\n      el.removeAttribute('data-focus-visible-added');\n    }\n\n    /**\n     * If the most recent user interaction was via the keyboard;\n     * and the key press did not include a meta, alt/option, or control key;\n     * then the modality is keyboard. Otherwise, the modality is not keyboard.\n     * Apply `focus-visible` to any current active element and keep track\n     * of our keyboard modality state with `hadKeyboardEvent`.\n     * @param {KeyboardEvent} e\n     */\n    function onKeyDown(e) {\n      if (e.metaKey || e.altKey || e.ctrlKey) {\n        return;\n      }\n\n      if (isValidFocusTarget(scope.activeElement)) {\n        addFocusVisibleClass(scope.activeElement);\n      }\n\n      hadKeyboardEvent = true;\n    }\n\n    /**\n     * If at any point a user clicks with a pointing device, ensure that we change\n     * the modality away from keyboard.\n     * This avoids the situation where a user presses a key on an already focused\n     * element, and then clicks on a different element, focusing it with a\n     * pointing device, while we still think we're in keyboard modality.\n     * @param {Event} e\n     */\n    function onPointerDown(e) {\n      hadKeyboardEvent = false;\n    }\n\n    /**\n     * On `focus`, add the `focus-visible` class to the target if:\n     * - the target received focus as a result of keyboard navigation, or\n     * - the event target is an element that will likely require interaction\n     *   via the keyboard (e.g. a text box)\n     * @param {Event} e\n     */\n    function onFocus(e) {\n      // Prevent IE from focusing the document or HTML element.\n      if (!isValidFocusTarget(e.target)) {\n        return;\n      }\n\n      if (hadKeyboardEvent || focusTriggersKeyboardModality(e.target)) {\n        addFocusVisibleClass(e.target);\n      }\n    }\n\n    /**\n     * On `blur`, remove the `focus-visible` class from the target.\n     * @param {Event} e\n     */\n    function onBlur(e) {\n      if (!isValidFocusTarget(e.target)) {\n        return;\n      }\n\n      if (\n        e.target.classList.contains('focus-visible') ||\n        e.target.hasAttribute('data-focus-visible-added')\n      ) {\n        // To detect a tab/window switch, we look for a blur event followed\n        // rapidly by a visibility change.\n        // If we don't see a visibility change within 100ms, it's probably a\n        // regular focus change.\n        hadFocusVisibleRecently = true;\n        window.clearTimeout(hadFocusVisibleRecentlyTimeout);\n        hadFocusVisibleRecentlyTimeout = window.setTimeout(function() {\n          hadFocusVisibleRecently = false;\n        }, 100);\n        removeFocusVisibleClass(e.target);\n      }\n    }\n\n    /**\n     * If the user changes tabs, keep track of whether or not the previously\n     * focused element had .focus-visible.\n     * @param {Event} e\n     */\n    function onVisibilityChange(e) {\n      if (document.visibilityState === 'hidden') {\n        // If the tab becomes active again, the browser will handle calling focus\n        // on the element (Safari actually calls it twice).\n        // If this tab change caused a blur on an element with focus-visible,\n        // re-apply the class when the user switches back to the tab.\n        if (hadFocusVisibleRecently) {\n          hadKeyboardEvent = true;\n        }\n        addInitialPointerMoveListeners();\n      }\n    }\n\n    /**\n     * Add a group of listeners to detect usage of any pointing devices.\n     * These listeners will be added when the polyfill first loads, and anytime\n     * the window is blurred, so that they are active when the window regains\n     * focus.\n     */\n    function addInitialPointerMoveListeners() {\n      document.addEventListener('mousemove', onInitialPointerMove);\n      document.addEventListener('mousedown', onInitialPointerMove);\n      document.addEventListener('mouseup', onInitialPointerMove);\n      document.addEventListener('pointermove', onInitialPointerMove);\n      document.addEventListener('pointerdown', onInitialPointerMove);\n      document.addEventListener('pointerup', onInitialPointerMove);\n      document.addEventListener('touchmove', onInitialPointerMove);\n      document.addEventListener('touchstart', onInitialPointerMove);\n      document.addEventListener('touchend', onInitialPointerMove);\n    }\n\n    function removeInitialPointerMoveListeners() {\n      document.removeEventListener('mousemove', onInitialPointerMove);\n      document.removeEventListener('mousedown', onInitialPointerMove);\n      document.removeEventListener('mouseup', onInitialPointerMove);\n      document.removeEventListener('pointermove', onInitialPointerMove);\n      document.removeEventListener('pointerdown', onInitialPointerMove);\n      document.removeEventListener('pointerup', onInitialPointerMove);\n      document.removeEventListener('touchmove', onInitialPointerMove);\n      document.removeEventListener('touchstart', onInitialPointerMove);\n      document.removeEventListener('touchend', onInitialPointerMove);\n    }\n\n    /**\n     * When the polfyill first loads, assume the user is in keyboard modality.\n     * If any event is received from a pointing device (e.g. mouse, pointer,\n     * touch), turn off keyboard modality.\n     * This accounts for situations where focus enters the page from the URL bar.\n     * @param {Event} e\n     */\n    function onInitialPointerMove(e) {\n      // Work around a Safari quirk that fires a mousemove on <html> whenever the\n      // window blurs, even if you're tabbing out of the page. \u00AF\\_(\u30C4)_/\u00AF\n      if (e.target.nodeName && e.target.nodeName.toLowerCase() === 'html') {\n        return;\n      }\n\n      hadKeyboardEvent = false;\n      removeInitialPointerMoveListeners();\n    }\n\n    // For some kinds of state, we are interested in changes at the global scope\n    // only. For example, global pointer input, global key presses and global\n    // visibility change should affect the state at every scope:\n    document.addEventListener('keydown', onKeyDown, true);\n    document.addEventListener('mousedown', onPointerDown, true);\n    document.addEventListener('pointerdown', onPointerDown, true);\n    document.addEventListener('touchstart', onPointerDown, true);\n    document.addEventListener('visibilitychange', onVisibilityChange, true);\n\n    addInitialPointerMoveListeners();\n\n    // For focus and blur, we specifically care about state changes in the local\n    // scope. This is because focus / blur events that originate from within a\n    // shadow root are not re-dispatched from the host element if it was already\n    // the active element in its own scope:\n    scope.addEventListener('focus', onFocus, true);\n    scope.addEventListener('blur', onBlur, true);\n\n    // We detect that a node is a ShadowRoot by ensuring that it is a\n    // DocumentFragment and also has a host property. This check covers native\n    // implementation and polyfill implementation transparently. If we only cared\n    // about the native implementation, we could just check if the scope was\n    // an instance of a ShadowRoot.\n    if (scope.nodeType === Node.DOCUMENT_FRAGMENT_NODE && scope.host) {\n      // Since a ShadowRoot is a special kind of DocumentFragment, it does not\n      // have a root element to add a class to. So, we add this attribute to the\n      // host element instead:\n      scope.host.setAttribute('data-js-focus-visible', '');\n    } else if (scope.nodeType === Node.DOCUMENT_NODE) {\n      document.documentElement.classList.add('js-focus-visible');\n      document.documentElement.setAttribute('data-js-focus-visible', '');\n    }\n  }\n\n  // It is important to wrap all references to global window and document in\n  // these checks to support server-side rendering use cases\n  // @see https://github.com/WICG/focus-visible/issues/199\n  if (typeof window !== 'undefined' && typeof document !== 'undefined') {\n    // Make the polyfill helper globally available. This can be used as a signal\n    // to interested libraries that wish to coordinate with the polyfill for e.g.,\n    // applying the polyfill to a shadow root:\n    window.applyFocusVisiblePolyfill = applyFocusVisiblePolyfill;\n\n    // Notify interested libraries of the polyfill's presence, in case the\n    // polyfill was loaded lazily:\n    var event;\n\n    try {\n      event = new CustomEvent('focus-visible-polyfill-ready');\n    } catch (error) {\n      // IE11 does not support using CustomEvent as a constructor directly:\n      event = document.createEvent('CustomEvent');\n      event.initCustomEvent('focus-visible-polyfill-ready', false, false, {});\n    }\n\n    window.dispatchEvent(event);\n  }\n\n  if (typeof document !== 'undefined') {\n    // Apply the polyfill to the global document, so that no JavaScript\n    // coordination is required to use the polyfill in the top-level document:\n    applyFocusVisiblePolyfill(document);\n  }\n\n})));\n", "/*!\n * escape-html\n * Copyright(c) 2012-2013 TJ Holowaychuk\n * Copyright(c) 2015 Andreas Lubbe\n * Copyright(c) 2015 Tiancheng \"Timothy\" Gu\n * MIT Licensed\n */\n\n'use strict';\n\n/**\n * Module variables.\n * @private\n */\n\nvar matchHtmlRegExp = /[\"'&<>]/;\n\n/**\n * Module exports.\n * @public\n */\n\nmodule.exports = escapeHtml;\n\n/**\n * Escape special characters in the given string of html.\n *\n * @param  {string} string The string to escape for inserting into HTML\n * @return {string}\n * @public\n */\n\nfunction escapeHtml(string) {\n  var str = '' + string;\n  var match = matchHtmlRegExp.exec(str);\n\n  if (!match) {\n    return str;\n  }\n\n  var escape;\n  var html = '';\n  var index = 0;\n  var lastIndex = 0;\n\n  for (index = match.index; index < str.length; index++) {\n    switch (str.charCodeAt(index)) {\n      case 34: // \"\n        escape = '&quot;';\n        break;\n      case 38: // &\n        escape = '&amp;';\n        break;\n      case 39: // '\n        escape = '&#39;';\n        break;\n      case 60: // <\n        escape = '&lt;';\n        break;\n      case 62: // >\n        escape = '&gt;';\n        break;\n      default:\n        continue;\n    }\n\n    if (lastIndex !== index) {\n      html += str.substring(lastIndex, index);\n    }\n\n    lastIndex = index + 1;\n    html += escape;\n  }\n\n  return lastIndex !== index\n    ? html + str.substring(lastIndex, index)\n    : html;\n}\n", "/*!\n * clipboard.js v2.0.11\n * https://clipboardjs.com/\n *\n * Licensed MIT \u00A9 Zeno Rocha\n */\n(function webpackUniversalModuleDefinition(root, factory) {\n\tif(typeof exports === 'object' && typeof module === 'object')\n\t\tmodule.exports = factory();\n\telse if(typeof define === 'function' && define.amd)\n\t\tdefine([], factory);\n\telse if(typeof exports === 'object')\n\t\texports[\"ClipboardJS\"] = factory();\n\telse\n\t\troot[\"ClipboardJS\"] = factory();\n})(this, function() {\nreturn /******/ (function() { // webpackBootstrap\n/******/ \tvar __webpack_modules__ = ({\n\n/***/ 686:\n/***/ (function(__unused_webpack_module, __webpack_exports__, __webpack_require__) {\n\n\"use strict\";\n\n// EXPORTS\n__webpack_require__.d(__webpack_exports__, {\n  \"default\": function() { return /* binding */ clipboard; }\n});\n\n// EXTERNAL MODULE: ./node_modules/tiny-emitter/index.js\nvar tiny_emitter = __webpack_require__(279);\nvar tiny_emitter_default = /*#__PURE__*/__webpack_require__.n(tiny_emitter);\n// EXTERNAL MODULE: ./node_modules/good-listener/src/listen.js\nvar listen = __webpack_require__(370);\nvar listen_default = /*#__PURE__*/__webpack_require__.n(listen);\n// EXTERNAL MODULE: ./node_modules/select/src/select.js\nvar src_select = __webpack_require__(817);\nvar select_default = /*#__PURE__*/__webpack_require__.n(src_select);\n;// CONCATENATED MODULE: ./src/common/command.js\n/**\n * Executes a given operation type.\n * @param {String} type\n * @return {Boolean}\n */\nfunction command(type) {\n  try {\n    return document.execCommand(type);\n  } catch (err) {\n    return false;\n  }\n}\n;// CONCATENATED MODULE: ./src/actions/cut.js\n\n\n/**\n * Cut action wrapper.\n * @param {String|HTMLElement} target\n * @return {String}\n */\n\nvar ClipboardActionCut = function ClipboardActionCut(target) {\n  var selectedText = select_default()(target);\n  command('cut');\n  return selectedText;\n};\n\n/* harmony default export */ var actions_cut = (ClipboardActionCut);\n;// CONCATENATED MODULE: ./src/common/create-fake-element.js\n/**\n * Creates a fake textarea element with a value.\n * @param {String} value\n * @return {HTMLElement}\n */\nfunction createFakeElement(value) {\n  var isRTL = document.documentElement.getAttribute('dir') === 'rtl';\n  var fakeElement = document.createElement('textarea'); // Prevent zooming on iOS\n\n  fakeElement.style.fontSize = '12pt'; // Reset box model\n\n  fakeElement.style.border = '0';\n  fakeElement.style.padding = '0';\n  fakeElement.style.margin = '0'; // Move element out of screen horizontally\n\n  fakeElement.style.position = 'absolute';\n  fakeElement.style[isRTL ? 'right' : 'left'] = '-9999px'; // Move element to the same position vertically\n\n  var yPosition = window.pageYOffset || document.documentElement.scrollTop;\n  fakeElement.style.top = \"\".concat(yPosition, \"px\");\n  fakeElement.setAttribute('readonly', '');\n  fakeElement.value = value;\n  return fakeElement;\n}\n;// CONCATENATED MODULE: ./src/actions/copy.js\n\n\n\n/**\n * Create fake copy action wrapper using a fake element.\n * @param {String} target\n * @param {Object} options\n * @return {String}\n */\n\nvar fakeCopyAction = function fakeCopyAction(value, options) {\n  var fakeElement = createFakeElement(value);\n  options.container.appendChild(fakeElement);\n  var selectedText = select_default()(fakeElement);\n  command('copy');\n  fakeElement.remove();\n  return selectedText;\n};\n/**\n * Copy action wrapper.\n * @param {String|HTMLElement} target\n * @param {Object} options\n * @return {String}\n */\n\n\nvar ClipboardActionCopy = function ClipboardActionCopy(target) {\n  var options = arguments.length > 1 && arguments[1] !== undefined ? arguments[1] : {\n    container: document.body\n  };\n  var selectedText = '';\n\n  if (typeof target === 'string') {\n    selectedText = fakeCopyAction(target, options);\n  } else if (target instanceof HTMLInputElement && !['text', 'search', 'url', 'tel', 'password'].includes(target === null || target === void 0 ? void 0 : target.type)) {\n    // If input type doesn't support `setSelectionRange`. Simulate it. https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/setSelectionRange\n    selectedText = fakeCopyAction(target.value, options);\n  } else {\n    selectedText = select_default()(target);\n    command('copy');\n  }\n\n  return selectedText;\n};\n\n/* harmony default export */ var actions_copy = (ClipboardActionCopy);\n;// CONCATENATED MODULE: ./src/actions/default.js\nfunction _typeof(obj) { \"@babel/helpers - typeof\"; if (typeof Symbol === \"function\" && typeof Symbol.iterator === \"symbol\") { _typeof = function _typeof(obj) { return typeof obj; }; } else { _typeof = function _typeof(obj) { return obj && typeof Symbol === \"function\" && obj.constructor === Symbol && obj !== Symbol.prototype ? \"symbol\" : typeof obj; }; } return _typeof(obj); }\n\n\n\n/**\n * Inner function which performs selection from either `text` or `target`\n * properties and then executes copy or cut operations.\n * @param {Object} options\n */\n\nvar ClipboardActionDefault = function ClipboardActionDefault() {\n  var options = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : {};\n  // Defines base properties passed from constructor.\n  var _options$action = options.action,\n      action = _options$action === void 0 ? 'copy' : _options$action,\n      container = options.container,\n      target = options.target,\n      text = options.text; // Sets the `action` to be performed which can be either 'copy' or 'cut'.\n\n  if (action !== 'copy' && action !== 'cut') {\n    throw new Error('Invalid \"action\" value, use either \"copy\" or \"cut\"');\n  } // Sets the `target` property using an element that will be have its content copied.\n\n\n  if (target !== undefined) {\n    if (target && _typeof(target) === 'object' && target.nodeType === 1) {\n      if (action === 'copy' && target.hasAttribute('disabled')) {\n        throw new Error('Invalid \"target\" attribute. Please use \"readonly\" instead of \"disabled\" attribute');\n      }\n\n      if (action === 'cut' && (target.hasAttribute('readonly') || target.hasAttribute('disabled'))) {\n        throw new Error('Invalid \"target\" attribute. You can\\'t cut text from elements with \"readonly\" or \"disabled\" attributes');\n      }\n    } else {\n      throw new Error('Invalid \"target\" value, use a valid Element');\n    }\n  } // Define selection strategy based on `text` property.\n\n\n  if (text) {\n    return actions_copy(text, {\n      container: container\n    });\n  } // Defines which selection strategy based on `target` property.\n\n\n  if (target) {\n    return action === 'cut' ? actions_cut(target) : actions_copy(target, {\n      container: container\n    });\n  }\n};\n\n/* harmony default export */ var actions_default = (ClipboardActionDefault);\n;// CONCATENATED MODULE: ./src/clipboard.js\nfunction clipboard_typeof(obj) { \"@babel/helpers - typeof\"; if (typeof Symbol === \"function\" && typeof Symbol.iterator === \"symbol\") { clipboard_typeof = function _typeof(obj) { return typeof obj; }; } else { clipboard_typeof = function _typeof(obj) { return obj && typeof Symbol === \"function\" && obj.constructor === Symbol && obj !== Symbol.prototype ? \"symbol\" : typeof obj; }; } return clipboard_typeof(obj); }\n\nfunction _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError(\"Cannot call a class as a function\"); } }\n\nfunction _defineProperties(target, props) { for (var i = 0; i < props.length; i++) { var descriptor = props[i]; descriptor.enumerable = descriptor.enumerable || false; descriptor.configurable = true; if (\"value\" in descriptor) descriptor.writable = true; Object.defineProperty(target, descriptor.key, descriptor); } }\n\nfunction _createClass(Constructor, protoProps, staticProps) { if (protoProps) _defineProperties(Constructor.prototype, protoProps); if (staticProps) _defineProperties(Constructor, staticProps); return Constructor; }\n\nfunction _inherits(subClass, superClass) { if (typeof superClass !== \"function\" && superClass !== null) { throw new TypeError(\"Super expression must either be null or a function\"); } subClass.prototype = Object.create(superClass && superClass.prototype, { constructor: { value: subClass, writable: true, configurable: true } }); if (superClass) _setPrototypeOf(subClass, superClass); }\n\nfunction _setPrototypeOf(o, p) { _setPrototypeOf = Object.setPrototypeOf || function _setPrototypeOf(o, p) { o.__proto__ = p; return o; }; return _setPrototypeOf(o, p); }\n\nfunction _createSuper(Derived) { var hasNativeReflectConstruct = _isNativeReflectConstruct(); return function _createSuperInternal() { var Super = _getPrototypeOf(Derived), result; if (hasNativeReflectConstruct) { var NewTarget = _getPrototypeOf(this).constructor; result = Reflect.construct(Super, arguments, NewTarget); } else { result = Super.apply(this, arguments); } return _possibleConstructorReturn(this, result); }; }\n\nfunction _possibleConstructorReturn(self, call) { if (call && (clipboard_typeof(call) === \"object\" || typeof call === \"function\")) { return call; } return _assertThisInitialized(self); }\n\nfunction _assertThisInitialized(self) { if (self === void 0) { throw new ReferenceError(\"this hasn't been initialised - super() hasn't been called\"); } return self; }\n\nfunction _isNativeReflectConstruct() { if (typeof Reflect === \"undefined\" || !Reflect.construct) return false; if (Reflect.construct.sham) return false; if (typeof Proxy === \"function\") return true; try { Date.prototype.toString.call(Reflect.construct(Date, [], function () {})); return true; } catch (e) { return false; } }\n\nfunction _getPrototypeOf(o) { _getPrototypeOf = Object.setPrototypeOf ? Object.getPrototypeOf : function _getPrototypeOf(o) { return o.__proto__ || Object.getPrototypeOf(o); }; return _getPrototypeOf(o); }\n\n\n\n\n\n\n/**\n * Helper function to retrieve attribute value.\n * @param {String} suffix\n * @param {Element} element\n */\n\nfunction getAttributeValue(suffix, element) {\n  var attribute = \"data-clipboard-\".concat(suffix);\n\n  if (!element.hasAttribute(attribute)) {\n    return;\n  }\n\n  return element.getAttribute(attribute);\n}\n/**\n * Base class which takes one or more elements, adds event listeners to them,\n * and instantiates a new `ClipboardAction` on each click.\n */\n\n\nvar Clipboard = /*#__PURE__*/function (_Emitter) {\n  _inherits(Clipboard, _Emitter);\n\n  var _super = _createSuper(Clipboard);\n\n  /**\n   * @param {String|HTMLElement|HTMLCollection|NodeList} trigger\n   * @param {Object} options\n   */\n  function Clipboard(trigger, options) {\n    var _this;\n\n    _classCallCheck(this, Clipboard);\n\n    _this = _super.call(this);\n\n    _this.resolveOptions(options);\n\n    _this.listenClick(trigger);\n\n    return _this;\n  }\n  /**\n   * Defines if attributes would be resolved using internal setter functions\n   * or custom functions that were passed in the constructor.\n   * @param {Object} options\n   */\n\n\n  _createClass(Clipboard, [{\n    key: \"resolveOptions\",\n    value: function resolveOptions() {\n      var options = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : {};\n      this.action = typeof options.action === 'function' ? options.action : this.defaultAction;\n      this.target = typeof options.target === 'function' ? options.target : this.defaultTarget;\n      this.text = typeof options.text === 'function' ? options.text : this.defaultText;\n      this.container = clipboard_typeof(options.container) === 'object' ? options.container : document.body;\n    }\n    /**\n     * Adds a click event listener to the passed trigger.\n     * @param {String|HTMLElement|HTMLCollection|NodeList} trigger\n     */\n\n  }, {\n    key: \"listenClick\",\n    value: function listenClick(trigger) {\n      var _this2 = this;\n\n      this.listener = listen_default()(trigger, 'click', function (e) {\n        return _this2.onClick(e);\n      });\n    }\n    /**\n     * Defines a new `ClipboardAction` on each click event.\n     * @param {Event} e\n     */\n\n  }, {\n    key: \"onClick\",\n    value: function onClick(e) {\n      var trigger = e.delegateTarget || e.currentTarget;\n      var action = this.action(trigger) || 'copy';\n      var text = actions_default({\n        action: action,\n        container: this.container,\n        target: this.target(trigger),\n        text: this.text(trigger)\n      }); // Fires an event based on the copy operation result.\n\n      this.emit(text ? 'success' : 'error', {\n        action: action,\n        text: text,\n        trigger: trigger,\n        clearSelection: function clearSelection() {\n          if (trigger) {\n            trigger.focus();\n          }\n\n          window.getSelection().removeAllRanges();\n        }\n      });\n    }\n    /**\n     * Default `action` lookup function.\n     * @param {Element} trigger\n     */\n\n  }, {\n    key: \"defaultAction\",\n    value: function defaultAction(trigger) {\n      return getAttributeValue('action', trigger);\n    }\n    /**\n     * Default `target` lookup function.\n     * @param {Element} trigger\n     */\n\n  }, {\n    key: \"defaultTarget\",\n    value: function defaultTarget(trigger) {\n      var selector = getAttributeValue('target', trigger);\n\n      if (selector) {\n        return document.querySelector(selector);\n      }\n    }\n    /**\n     * Allow fire programmatically a copy action\n     * @param {String|HTMLElement} target\n     * @param {Object} options\n     * @returns Text copied.\n     */\n\n  }, {\n    key: \"defaultText\",\n\n    /**\n     * Default `text` lookup function.\n     * @param {Element} trigger\n     */\n    value: function defaultText(trigger) {\n      return getAttributeValue('text', trigger);\n    }\n    /**\n     * Destroy lifecycle.\n     */\n\n  }, {\n    key: \"destroy\",\n    value: function destroy() {\n      this.listener.destroy();\n    }\n  }], [{\n    key: \"copy\",\n    value: function copy(target) {\n      var options = arguments.length > 1 && arguments[1] !== undefined ? arguments[1] : {\n        container: document.body\n      };\n      return actions_copy(target, options);\n    }\n    /**\n     * Allow fire programmatically a cut action\n     * @param {String|HTMLElement} target\n     * @returns Text cutted.\n     */\n\n  }, {\n    key: \"cut\",\n    value: function cut(target) {\n      return actions_cut(target);\n    }\n    /**\n     * Returns the support of the given action, or all actions if no action is\n     * given.\n     * @param {String} [action]\n     */\n\n  }, {\n    key: \"isSupported\",\n    value: function isSupported() {\n      var action = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : ['copy', 'cut'];\n      var actions = typeof action === 'string' ? [action] : action;\n      var support = !!document.queryCommandSupported;\n      actions.forEach(function (action) {\n        support = support && !!document.queryCommandSupported(action);\n      });\n      return support;\n    }\n  }]);\n\n  return Clipboard;\n}((tiny_emitter_default()));\n\n/* harmony default export */ var clipboard = (Clipboard);\n\n/***/ }),\n\n/***/ 828:\n/***/ (function(module) {\n\nvar DOCUMENT_NODE_TYPE = 9;\n\n/**\n * A polyfill for Element.matches()\n */\nif (typeof Element !== 'undefined' && !Element.prototype.matches) {\n    var proto = Element.prototype;\n\n    proto.matches = proto.matchesSelector ||\n                    proto.mozMatchesSelector ||\n                    proto.msMatchesSelector ||\n                    proto.oMatchesSelector ||\n                    proto.webkitMatchesSelector;\n}\n\n/**\n * Finds the closest parent that matches a selector.\n *\n * @param {Element} element\n * @param {String} selector\n * @return {Function}\n */\nfunction closest (element, selector) {\n    while (element && element.nodeType !== DOCUMENT_NODE_TYPE) {\n        if (typeof element.matches === 'function' &&\n            element.matches(selector)) {\n          return element;\n        }\n        element = element.parentNode;\n    }\n}\n\nmodule.exports = closest;\n\n\n/***/ }),\n\n/***/ 438:\n/***/ (function(module, __unused_webpack_exports, __webpack_require__) {\n\nvar closest = __webpack_require__(828);\n\n/**\n * Delegates event to a selector.\n *\n * @param {Element} element\n * @param {String} selector\n * @param {String} type\n * @param {Function} callback\n * @param {Boolean} useCapture\n * @return {Object}\n */\nfunction _delegate(element, selector, type, callback, useCapture) {\n    var listenerFn = listener.apply(this, arguments);\n\n    element.addEventListener(type, listenerFn, useCapture);\n\n    return {\n        destroy: function() {\n            element.removeEventListener(type, listenerFn, useCapture);\n        }\n    }\n}\n\n/**\n * Delegates event to a selector.\n *\n * @param {Element|String|Array} [elements]\n * @param {String} selector\n * @param {String} type\n * @param {Function} callback\n * @param {Boolean} useCapture\n * @return {Object}\n */\nfunction delegate(elements, selector, type, callback, useCapture) {\n    // Handle the regular Element usage\n    if (typeof elements.addEventListener === 'function') {\n        return _delegate.apply(null, arguments);\n    }\n\n    // Handle Element-less usage, it defaults to global delegation\n    if (typeof type === 'function') {\n        // Use `document` as the first parameter, then apply arguments\n        // This is a short way to .unshift `arguments` without running into deoptimizations\n        return _delegate.bind(null, document).apply(null, arguments);\n    }\n\n    // Handle Selector-based usage\n    if (typeof elements === 'string') {\n        elements = document.querySelectorAll(elements);\n    }\n\n    // Handle Array-like based usage\n    return Array.prototype.map.call(elements, function (element) {\n        return _delegate(element, selector, type, callback, useCapture);\n    });\n}\n\n/**\n * Finds closest match and invokes callback.\n *\n * @param {Element} element\n * @param {String} selector\n * @param {String} type\n * @param {Function} callback\n * @return {Function}\n */\nfunction listener(element, selector, type, callback) {\n    return function(e) {\n        e.delegateTarget = closest(e.target, selector);\n\n        if (e.delegateTarget) {\n            callback.call(element, e);\n        }\n    }\n}\n\nmodule.exports = delegate;\n\n\n/***/ }),\n\n/***/ 879:\n/***/ (function(__unused_webpack_module, exports) {\n\n/**\n * Check if argument is a HTML element.\n *\n * @param {Object} value\n * @return {Boolean}\n */\nexports.node = function(value) {\n    return value !== undefined\n        && value instanceof HTMLElement\n        && value.nodeType === 1;\n};\n\n/**\n * Check if argument is a list of HTML elements.\n *\n * @param {Object} value\n * @return {Boolean}\n */\nexports.nodeList = function(value) {\n    var type = Object.prototype.toString.call(value);\n\n    return value !== undefined\n        && (type === '[object NodeList]' || type === '[object HTMLCollection]')\n        && ('length' in value)\n        && (value.length === 0 || exports.node(value[0]));\n};\n\n/**\n * Check if argument is a string.\n *\n * @param {Object} value\n * @return {Boolean}\n */\nexports.string = function(value) {\n    return typeof value === 'string'\n        || value instanceof String;\n};\n\n/**\n * Check if argument is a function.\n *\n * @param {Object} value\n * @return {Boolean}\n */\nexports.fn = function(value) {\n    var type = Object.prototype.toString.call(value);\n\n    return type === '[object Function]';\n};\n\n\n/***/ }),\n\n/***/ 370:\n/***/ (function(module, __unused_webpack_exports, __webpack_require__) {\n\nvar is = __webpack_require__(879);\nvar delegate = __webpack_require__(438);\n\n/**\n * Validates all params and calls the right\n * listener function based on its target type.\n *\n * @param {String|HTMLElement|HTMLCollection|NodeList} target\n * @param {String} type\n * @param {Function} callback\n * @return {Object}\n */\nfunction listen(target, type, callback) {\n    if (!target && !type && !callback) {\n        throw new Error('Missing required arguments');\n    }\n\n    if (!is.string(type)) {\n        throw new TypeError('Second argument must be a String');\n    }\n\n    if (!is.fn(callback)) {\n        throw new TypeError('Third argument must be a Function');\n    }\n\n    if (is.node(target)) {\n        return listenNode(target, type, callback);\n    }\n    else if (is.nodeList(target)) {\n        return listenNodeList(target, type, callback);\n    }\n    else if (is.string(target)) {\n        return listenSelector(target, type, callback);\n    }\n    else {\n        throw new TypeError('First argument must be a String, HTMLElement, HTMLCollection, or NodeList');\n    }\n}\n\n/**\n * Adds an event listener to a HTML element\n * and returns a remove listener function.\n *\n * @param {HTMLElement} node\n * @param {String} type\n * @param {Function} callback\n * @return {Object}\n */\nfunction listenNode(node, type, callback) {\n    node.addEventListener(type, callback);\n\n    return {\n        destroy: function() {\n            node.removeEventListener(type, callback);\n        }\n    }\n}\n\n/**\n * Add an event listener to a list of HTML elements\n * and returns a remove listener function.\n *\n * @param {NodeList|HTMLCollection} nodeList\n * @param {String} type\n * @param {Function} callback\n * @return {Object}\n */\nfunction listenNodeList(nodeList, type, callback) {\n    Array.prototype.forEach.call(nodeList, function(node) {\n        node.addEventListener(type, callback);\n    });\n\n    return {\n        destroy: function() {\n            Array.prototype.forEach.call(nodeList, function(node) {\n                node.removeEventListener(type, callback);\n            });\n        }\n    }\n}\n\n/**\n * Add an event listener to a selector\n * and returns a remove listener function.\n *\n * @param {String} selector\n * @param {String} type\n * @param {Function} callback\n * @return {Object}\n */\nfunction listenSelector(selector, type, callback) {\n    return delegate(document.body, selector, type, callback);\n}\n\nmodule.exports = listen;\n\n\n/***/ }),\n\n/***/ 817:\n/***/ (function(module) {\n\nfunction select(element) {\n    var selectedText;\n\n    if (element.nodeName === 'SELECT') {\n        element.focus();\n\n        selectedText = element.value;\n    }\n    else if (element.nodeName === 'INPUT' || element.nodeName === 'TEXTAREA') {\n        var isReadOnly = element.hasAttribute('readonly');\n\n        if (!isReadOnly) {\n            element.setAttribute('readonly', '');\n        }\n\n        element.select();\n        element.setSelectionRange(0, element.value.length);\n\n        if (!isReadOnly) {\n            element.removeAttribute('readonly');\n        }\n\n        selectedText = element.value;\n    }\n    else {\n        if (element.hasAttribute('contenteditable')) {\n            element.focus();\n        }\n\n        var selection = window.getSelection();\n        var range = document.createRange();\n\n        range.selectNodeContents(element);\n        selection.removeAllRanges();\n        selection.addRange(range);\n\n        selectedText = selection.toString();\n    }\n\n    return selectedText;\n}\n\nmodule.exports = select;\n\n\n/***/ }),\n\n/***/ 279:\n/***/ (function(module) {\n\nfunction E () {\n  // Keep this empty so it's easier to inherit from\n  // (via https://github.com/lipsmack from https://github.com/scottcorgan/tiny-emitter/issues/3)\n}\n\nE.prototype = {\n  on: function (name, callback, ctx) {\n    var e = this.e || (this.e = {});\n\n    (e[name] || (e[name] = [])).push({\n      fn: callback,\n      ctx: ctx\n    });\n\n    return this;\n  },\n\n  once: function (name, callback, ctx) {\n    var self = this;\n    function listener () {\n      self.off(name, listener);\n      callback.apply(ctx, arguments);\n    };\n\n    listener._ = callback\n    return this.on(name, listener, ctx);\n  },\n\n  emit: function (name) {\n    var data = [].slice.call(arguments, 1);\n    var evtArr = ((this.e || (this.e = {}))[name] || []).slice();\n    var i = 0;\n    var len = evtArr.length;\n\n    for (i; i < len; i++) {\n      evtArr[i].fn.apply(evtArr[i].ctx, data);\n    }\n\n    return this;\n  },\n\n  off: function (name, callback) {\n    var e = this.e || (this.e = {});\n    var evts = e[name];\n    var liveEvents = [];\n\n    if (evts && callback) {\n      for (var i = 0, len = evts.length; i < len; i++) {\n        if (evts[i].fn !== callback && evts[i].fn._ !== callback)\n          liveEvents.push(evts[i]);\n      }\n    }\n\n    // Remove event from queue to prevent memory leak\n    // Suggested by https://github.com/lazd\n    // Ref: https://github.com/scottcorgan/tiny-emitter/commit/c6ebfaa9bc973b33d110a84a307742b7cf94c953#commitcomment-5024910\n\n    (liveEvents.length)\n      ? e[name] = liveEvents\n      : delete e[name];\n\n    return this;\n  }\n};\n\nmodule.exports = E;\nmodule.exports.TinyEmitter = E;\n\n\n/***/ })\n\n/******/ \t});\n/************************************************************************/\n/******/ \t// The module cache\n/******/ \tvar __webpack_module_cache__ = {};\n/******/ \t\n/******/ \t// The require function\n/******/ \tfunction __webpack_require__(moduleId) {\n/******/ \t\t// Check if module is in cache\n/******/ \t\tif(__webpack_module_cache__[moduleId]) {\n/******/ \t\t\treturn __webpack_module_cache__[moduleId].exports;\n/******/ \t\t}\n/******/ \t\t// Create a new module (and put it into the cache)\n/******/ \t\tvar module = __webpack_module_cache__[moduleId] = {\n/******/ \t\t\t// no module.id needed\n/******/ \t\t\t// no module.loaded needed\n/******/ \t\t\texports: {}\n/******/ \t\t};\n/******/ \t\n/******/ \t\t// Execute the module function\n/******/ \t\t__webpack_modules__[moduleId](module, module.exports, __webpack_require__);\n/******/ \t\n/******/ \t\t// Return the exports of the module\n/******/ \t\treturn module.exports;\n/******/ \t}\n/******/ \t\n/************************************************************************/\n/******/ \t/* webpack/runtime/compat get default export */\n/******/ \t!function() {\n/******/ \t\t// getDefaultExport function for compatibility with non-harmony modules\n/******/ \t\t__webpack_require__.n = function(module) {\n/******/ \t\t\tvar getter = module && module.__esModule ?\n/******/ \t\t\t\tfunction() { return module['default']; } :\n/******/ \t\t\t\tfunction() { return module; };\n/******/ \t\t\t__webpack_require__.d(getter, { a: getter });\n/******/ \t\t\treturn getter;\n/******/ \t\t};\n/******/ \t}();\n/******/ \t\n/******/ \t/* webpack/runtime/define property getters */\n/******/ \t!function() {\n/******/ \t\t// define getter functions for harmony exports\n/******/ \t\t__webpack_require__.d = function(exports, definition) {\n/******/ \t\t\tfor(var key in definition) {\n/******/ \t\t\t\tif(__webpack_require__.o(definition, key) && !__webpack_require__.o(exports, key)) {\n/******/ \t\t\t\t\tObject.defineProperty(exports, key, { enumerable: true, get: definition[key] });\n/******/ \t\t\t\t}\n/******/ \t\t\t}\n/******/ \t\t};\n/******/ \t}();\n/******/ \t\n/******/ \t/* webpack/runtime/hasOwnProperty shorthand */\n/******/ \t!function() {\n/******/ \t\t__webpack_require__.o = function(obj, prop) { return Object.prototype.hasOwnProperty.call(obj, prop); }\n/******/ \t}();\n/******/ \t\n/************************************************************************/\n/******/ \t// module exports must be returned from runtime so entry inlining is disabled\n/******/ \t// startup\n/******/ \t// Load entry module and return exports\n/******/ \treturn __webpack_require__(686);\n/******/ })()\n.default;\n});", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport \"focus-visible\"\n\nimport {\n  EMPTY,\n  NEVER,\n  Observable,\n  Subject,\n  defer,\n  delay,\n  filter,\n  map,\n  merge,\n  mergeWith,\n  shareReplay,\n  switchMap\n} from \"rxjs\"\n\nimport { configuration, feature } from \"./_\"\nimport {\n  at,\n  getActiveElement,\n  getOptionalElement,\n  requestJSON,\n  setLocation,\n  setToggle,\n  watchDocument,\n  watchKeyboard,\n  watchLocation,\n  watchLocationTarget,\n  watchMedia,\n  watchPrint,\n  watchScript,\n  watchViewport\n} from \"./browser\"\nimport {\n  getComponentElement,\n  getComponentElements,\n  mountAnnounce,\n  mountBackToTop,\n  mountConsent,\n  mountContent,\n  mountDialog,\n  mountHeader,\n  mountHeaderTitle,\n  mountPalette,\n  mountProgress,\n  mountSearch,\n  mountSearchHiglight,\n  mountSidebar,\n  mountSource,\n  mountTableOfContents,\n  mountTabs,\n  watchHeader,\n  watchMain\n} from \"./components\"\nimport {\n  SearchIndex,\n  setupClipboardJS,\n  setupInstantNavigation,\n  setupVersionSelector\n} from \"./integrations\"\nimport {\n  patchEllipsis,\n  patchIndeterminate,\n  patchScrollfix,\n  patchScrolllock\n} from \"./patches\"\nimport \"./polyfills\"\n\n/* ----------------------------------------------------------------------------\n * Functions - @todo refactor\n * ------------------------------------------------------------------------- */\n\n/**\n * Fetch search index\n *\n * @returns Search index observable\n */\nfunction fetchSearchIndex(): Observable<SearchIndex> {\n  if (location.protocol === \"file:\") {\n    return watchScript(\n      `${new URL(\"search/search_index.js\", config.base)}`\n    )\n      .pipe(\n        // @ts-ignore - @todo fix typings\n        map(() => __index),\n        shareReplay(1)\n      )\n  } else {\n    return requestJSON<SearchIndex>(\n      new URL(\"search/search_index.json\", config.base)\n    )\n  }\n}\n\n/* ----------------------------------------------------------------------------\n * Application\n * ------------------------------------------------------------------------- */\n\n/* Yay, JavaScript is available */\ndocument.documentElement.classList.remove(\"no-js\")\ndocument.documentElement.classList.add(\"js\")\n\n/* Set up navigation observables and subjects */\nconst document$ = watchDocument()\nconst location$ = watchLocation()\nconst target$   = watchLocationTarget(location$)\nconst keyboard$ = watchKeyboard()\n\n/* Set up media observables */\nconst viewport$ = watchViewport()\nconst tablet$   = watchMedia(\"(min-width: 960px)\")\nconst screen$   = watchMedia(\"(min-width: 1220px)\")\nconst print$    = watchPrint()\n\n/* Retrieve search index, if search is enabled */\nconst config = configuration()\nconst index$ = document.forms.namedItem(\"search\")\n  ? fetchSearchIndex()\n  : NEVER\n\n/* Set up Clipboard.js integration */\nconst alert$ = new Subject<string>()\nsetupClipboardJS({ alert$ })\n\n/* Set up progress indicator */\nconst progress$ = new Subject<number>()\n\n/* Set up instant navigation, if enabled */\nif (feature(\"navigation.instant\"))\n  setupInstantNavigation({ location$, viewport$, progress$ })\n    .subscribe(document$)\n\n/* Set up version selector */\nif (config.version?.provider === \"mike\")\n  setupVersionSelector({ document$ })\n\n/* Always close drawer and search on navigation */\nmerge(location$, target$)\n  .pipe(\n    delay(125)\n  )\n    .subscribe(() => {\n      setToggle(\"drawer\", false)\n      setToggle(\"search\", false)\n    })\n\n/* Set up global keyboard handlers */\nkeyboard$\n  .pipe(\n    filter(({ mode }) => mode === \"global\")\n  )\n    .subscribe(key => {\n      switch (key.type) {\n\n        /* Go to previous page */\n        case \"p\":\n        case \",\":\n          const prev = getOptionalElement<HTMLLinkElement>(\"link[rel=prev]\")\n          if (typeof prev !== \"undefined\")\n            setLocation(prev)\n          break\n\n        /* Go to next page */\n        case \"n\":\n        case \".\":\n          const next = getOptionalElement<HTMLLinkElement>(\"link[rel=next]\")\n          if (typeof next !== \"undefined\")\n            setLocation(next)\n          break\n\n        /* Expand navigation, see https://bit.ly/3ZjG5io */\n        case \"Enter\":\n          const active = getActiveElement()\n          if (active instanceof HTMLLabelElement)\n            active.click()\n      }\n    })\n\n/* Set up patches */\npatchEllipsis({ viewport$, document$ })\npatchIndeterminate({ document$, tablet$ })\npatchScrollfix({ document$ })\npatchScrolllock({ viewport$, tablet$ })\n\n/* Set up header and main area observable */\nconst header$ = watchHeader(getComponentElement(\"header\"), { viewport$ })\nconst main$ = document$\n  .pipe(\n    map(() => getComponentElement(\"main\")),\n    switchMap(el => watchMain(el, { viewport$, header$ })),\n    shareReplay(1)\n  )\n\n/* Set up control component observables */\nconst control$ = merge(\n\n  /* Consent */\n  ...getComponentElements(\"consent\")\n    .map(el => mountConsent(el, { target$ })),\n\n  /* Dialog */\n  ...getComponentElements(\"dialog\")\n    .map(el => mountDialog(el, { alert$ })),\n\n  /* Header */\n  ...getComponentElements(\"header\")\n    .map(el => mountHeader(el, { viewport$, header$, main$ })),\n\n  /* Color palette */\n  ...getComponentElements(\"palette\")\n    .map(el => mountPalette(el)),\n\n  /* Progress bar */\n  ...getComponentElements(\"progress\")\n    .map(el => mountProgress(el, { progress$ })),\n\n  /* Search */\n  ...getComponentElements(\"search\")\n    .map(el => mountSearch(el, { index$, keyboard$ })),\n\n  /* Repository information */\n  ...getComponentElements(\"source\")\n    .map(el => mountSource(el))\n)\n\n/* Set up content component observables */\nconst content$ = defer(() => merge(\n\n  /* Announcement bar */\n  ...getComponentElements(\"announce\")\n    .map(el => mountAnnounce(el)),\n\n  /* Content */\n  ...getComponentElements(\"content\")\n    .map(el => mountContent(el, { viewport$, target$, print$ })),\n\n  /* Search highlighting */\n  ...getComponentElements(\"content\")\n    .map(el => feature(\"search.highlight\")\n      ? mountSearchHiglight(el, { index$, location$ })\n      : EMPTY\n    ),\n\n  /* Header title */\n  ...getComponentElements(\"header-title\")\n    .map(el => mountHeaderTitle(el, { viewport$, header$ })),\n\n  /* Sidebar */\n  ...getComponentElements(\"sidebar\")\n    .map(el => el.getAttribute(\"data-md-type\") === \"navigation\"\n      ? at(screen$, () => mountSidebar(el, { viewport$, header$, main$ }))\n      : at(tablet$, () => mountSidebar(el, { viewport$, header$, main$ }))\n    ),\n\n  /* Navigation tabs */\n  ...getComponentElements(\"tabs\")\n    .map(el => mountTabs(el, { viewport$, header$ })),\n\n  /* Table of contents */\n  ...getComponentElements(\"toc\")\n    .map(el => mountTableOfContents(el, {\n      viewport$, header$, main$, target$\n    })),\n\n  /* Back-to-top button */\n  ...getComponentElements(\"top\")\n    .map(el => mountBackToTop(el, { viewport$, header$, main$, target$ }))\n))\n\n/* Set up component observables */\nconst component$ = document$\n  .pipe(\n    switchMap(() => content$),\n    mergeWith(control$),\n    shareReplay(1)\n  )\n\n/* Subscribe to all components */\ncomponent$.subscribe()\n\n/* ----------------------------------------------------------------------------\n * Exports\n * ------------------------------------------------------------------------- */\n\nwindow.document$  = document$          /* Document observable */\nwindow.location$  = location$          /* Location subject */\nwindow.target$    = target$            /* Location target observable */\nwindow.keyboard$  = keyboard$          /* Keyboard observable */\nwindow.viewport$  = viewport$          /* Viewport observable */\nwindow.tablet$    = tablet$            /* Media tablet observable */\nwindow.screen$    = screen$            /* Media screen observable */\nwindow.print$     = print$             /* Media print observable */\nwindow.alert$     = alert$             /* Alert subject */\nwindow.progress$  = progress$          /* Progress indicator subject */\nwindow.component$ = component$         /* Component observable */\n", "/******************************************************************************\nCopyright (c) Microsoft Corporation.\n\nPermission to use, copy, modify, and/or distribute this software for any\npurpose with or without fee is hereby granted.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH\nREGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY\nAND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT,\nINDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM\nLOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR\nOTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR\nPERFORMANCE OF THIS SOFTWARE.\n***************************************************************************** */\n/* global Reflect, Promise, SuppressedError, Symbol, Iterator */\n\nvar extendStatics = function(d, b) {\n  extendStatics = Object.setPrototypeOf ||\n      ({ __proto__: [] } instanceof Array && function (d, b) { d.__proto__ = b; }) ||\n      function (d, b) { for (var p in b) if (Object.prototype.hasOwnProperty.call(b, p)) d[p] = b[p]; };\n  return extendStatics(d, b);\n};\n\nexport function __extends(d, b) {\n  if (typeof b !== \"function\" && b !== null)\n      throw new TypeError(\"Class extends value \" + String(b) + \" is not a constructor or null\");\n  extendStatics(d, b);\n  function __() { this.constructor = d; }\n  d.prototype = b === null ? Object.create(b) : (__.prototype = b.prototype, new __());\n}\n\nexport var __assign = function() {\n  __assign = Object.assign || function __assign(t) {\n      for (var s, i = 1, n = arguments.length; i < n; i++) {\n          s = arguments[i];\n          for (var p in s) if (Object.prototype.hasOwnProperty.call(s, p)) t[p] = s[p];\n      }\n      return t;\n  }\n  return __assign.apply(this, arguments);\n}\n\nexport function __rest(s, e) {\n  var t = {};\n  for (var p in s) if (Object.prototype.hasOwnProperty.call(s, p) && e.indexOf(p) < 0)\n      t[p] = s[p];\n  if (s != null && typeof Object.getOwnPropertySymbols === \"function\")\n      for (var i = 0, p = Object.getOwnPropertySymbols(s); i < p.length; i++) {\n          if (e.indexOf(p[i]) < 0 && Object.prototype.propertyIsEnumerable.call(s, p[i]))\n              t[p[i]] = s[p[i]];\n      }\n  return t;\n}\n\nexport function __decorate(decorators, target, key, desc) {\n  var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;\n  if (typeof Reflect === \"object\" && typeof Reflect.decorate === \"function\") r = Reflect.decorate(decorators, target, key, desc);\n  else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;\n  return c > 3 && r && Object.defineProperty(target, key, r), r;\n}\n\nexport function __param(paramIndex, decorator) {\n  return function (target, key) { decorator(target, key, paramIndex); }\n}\n\nexport function __esDecorate(ctor, descriptorIn, decorators, contextIn, initializers, extraInitializers) {\n  function accept(f) { if (f !== void 0 && typeof f !== \"function\") throw new TypeError(\"Function expected\"); return f; }\n  var kind = contextIn.kind, key = kind === \"getter\" ? \"get\" : kind === \"setter\" ? \"set\" : \"value\";\n  var target = !descriptorIn && ctor ? contextIn[\"static\"] ? ctor : ctor.prototype : null;\n  var descriptor = descriptorIn || (target ? Object.getOwnPropertyDescriptor(target, contextIn.name) : {});\n  var _, done = false;\n  for (var i = decorators.length - 1; i >= 0; i--) {\n      var context = {};\n      for (var p in contextIn) context[p] = p === \"access\" ? {} : contextIn[p];\n      for (var p in contextIn.access) context.access[p] = contextIn.access[p];\n      context.addInitializer = function (f) { if (done) throw new TypeError(\"Cannot add initializers after decoration has completed\"); extraInitializers.push(accept(f || null)); };\n      var result = (0, decorators[i])(kind === \"accessor\" ? { get: descriptor.get, set: descriptor.set } : descriptor[key], context);\n      if (kind === \"accessor\") {\n          if (result === void 0) continue;\n          if (result === null || typeof result !== \"object\") throw new TypeError(\"Object expected\");\n          if (_ = accept(result.get)) descriptor.get = _;\n          if (_ = accept(result.set)) descriptor.set = _;\n          if (_ = accept(result.init)) initializers.unshift(_);\n      }\n      else if (_ = accept(result)) {\n          if (kind === \"field\") initializers.unshift(_);\n          else descriptor[key] = _;\n      }\n  }\n  if (target) Object.defineProperty(target, contextIn.name, descriptor);\n  done = true;\n};\n\nexport function __runInitializers(thisArg, initializers, value) {\n  var useValue = arguments.length > 2;\n  for (var i = 0; i < initializers.length; i++) {\n      value = useValue ? initializers[i].call(thisArg, value) : initializers[i].call(thisArg);\n  }\n  return useValue ? value : void 0;\n};\n\nexport function __propKey(x) {\n  return typeof x === \"symbol\" ? x : \"\".concat(x);\n};\n\nexport function __setFunctionName(f, name, prefix) {\n  if (typeof name === \"symbol\") name = name.description ? \"[\".concat(name.description, \"]\") : \"\";\n  return Object.defineProperty(f, \"name\", { configurable: true, value: prefix ? \"\".concat(prefix, \" \", name) : name });\n};\n\nexport function __metadata(metadataKey, metadataValue) {\n  if (typeof Reflect === \"object\" && typeof Reflect.metadata === \"function\") return Reflect.metadata(metadataKey, metadataValue);\n}\n\nexport function __awaiter(thisArg, _arguments, P, generator) {\n  function adopt(value) { return value instanceof P ? value : new P(function (resolve) { resolve(value); }); }\n  return new (P || (P = Promise))(function (resolve, reject) {\n      function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }\n      function rejected(value) { try { step(generator[\"throw\"](value)); } catch (e) { reject(e); } }\n      function step(result) { result.done ? resolve(result.value) : adopt(result.value).then(fulfilled, rejected); }\n      step((generator = generator.apply(thisArg, _arguments || [])).next());\n  });\n}\n\nexport function __generator(thisArg, body) {\n  var _ = { label: 0, sent: function() { if (t[0] & 1) throw t[1]; return t[1]; }, trys: [], ops: [] }, f, y, t, g = Object.create((typeof Iterator === \"function\" ? Iterator : Object).prototype);\n  return g.next = verb(0), g[\"throw\"] = verb(1), g[\"return\"] = verb(2), typeof Symbol === \"function\" && (g[Symbol.iterator] = function() { return this; }), g;\n  function verb(n) { return function (v) { return step([n, v]); }; }\n  function step(op) {\n      if (f) throw new TypeError(\"Generator is already executing.\");\n      while (g && (g = 0, op[0] && (_ = 0)), _) try {\n          if (f = 1, y && (t = op[0] & 2 ? y[\"return\"] : op[0] ? y[\"throw\"] || ((t = y[\"return\"]) && t.call(y), 0) : y.next) && !(t = t.call(y, op[1])).done) return t;\n          if (y = 0, t) op = [op[0] & 2, t.value];\n          switch (op[0]) {\n              case 0: case 1: t = op; break;\n              case 4: _.label++; return { value: op[1], done: false };\n              case 5: _.label++; y = op[1]; op = [0]; continue;\n              case 7: op = _.ops.pop(); _.trys.pop(); continue;\n              default:\n                  if (!(t = _.trys, t = t.length > 0 && t[t.length - 1]) && (op[0] === 6 || op[0] === 2)) { _ = 0; continue; }\n                  if (op[0] === 3 && (!t || (op[1] > t[0] && op[1] < t[3]))) { _.label = op[1]; break; }\n                  if (op[0] === 6 && _.label < t[1]) { _.label = t[1]; t = op; break; }\n                  if (t && _.label < t[2]) { _.label = t[2]; _.ops.push(op); break; }\n                  if (t[2]) _.ops.pop();\n                  _.trys.pop(); continue;\n          }\n          op = body.call(thisArg, _);\n      } catch (e) { op = [6, e]; y = 0; } finally { f = t = 0; }\n      if (op[0] & 5) throw op[1]; return { value: op[0] ? op[1] : void 0, done: true };\n  }\n}\n\nexport var __createBinding = Object.create ? (function(o, m, k, k2) {\n  if (k2 === undefined) k2 = k;\n  var desc = Object.getOwnPropertyDescriptor(m, k);\n  if (!desc || (\"get\" in desc ? !m.__esModule : desc.writable || desc.configurable)) {\n      desc = { enumerable: true, get: function() { return m[k]; } };\n  }\n  Object.defineProperty(o, k2, desc);\n}) : (function(o, m, k, k2) {\n  if (k2 === undefined) k2 = k;\n  o[k2] = m[k];\n});\n\nexport function __exportStar(m, o) {\n  for (var p in m) if (p !== \"default\" && !Object.prototype.hasOwnProperty.call(o, p)) __createBinding(o, m, p);\n}\n\nexport function __values(o) {\n  var s = typeof Symbol === \"function\" && Symbol.iterator, m = s && o[s], i = 0;\n  if (m) return m.call(o);\n  if (o && typeof o.length === \"number\") return {\n      next: function () {\n          if (o && i >= o.length) o = void 0;\n          return { value: o && o[i++], done: !o };\n      }\n  };\n  throw new TypeError(s ? \"Object is not iterable.\" : \"Symbol.iterator is not defined.\");\n}\n\nexport function __read(o, n) {\n  var m = typeof Symbol === \"function\" && o[Symbol.iterator];\n  if (!m) return o;\n  var i = m.call(o), r, ar = [], e;\n  try {\n      while ((n === void 0 || n-- > 0) && !(r = i.next()).done) ar.push(r.value);\n  }\n  catch (error) { e = { error: error }; }\n  finally {\n      try {\n          if (r && !r.done && (m = i[\"return\"])) m.call(i);\n      }\n      finally { if (e) throw e.error; }\n  }\n  return ar;\n}\n\n/** @deprecated */\nexport function __spread() {\n  for (var ar = [], i = 0; i < arguments.length; i++)\n      ar = ar.concat(__read(arguments[i]));\n  return ar;\n}\n\n/** @deprecated */\nexport function __spreadArrays() {\n  for (var s = 0, i = 0, il = arguments.length; i < il; i++) s += arguments[i].length;\n  for (var r = Array(s), k = 0, i = 0; i < il; i++)\n      for (var a = arguments[i], j = 0, jl = a.length; j < jl; j++, k++)\n          r[k] = a[j];\n  return r;\n}\n\nexport function __spreadArray(to, from, pack) {\n  if (pack || arguments.length === 2) for (var i = 0, l = from.length, ar; i < l; i++) {\n      if (ar || !(i in from)) {\n          if (!ar) ar = Array.prototype.slice.call(from, 0, i);\n          ar[i] = from[i];\n      }\n  }\n  return to.concat(ar || Array.prototype.slice.call(from));\n}\n\nexport function __await(v) {\n  return this instanceof __await ? (this.v = v, this) : new __await(v);\n}\n\nexport function __asyncGenerator(thisArg, _arguments, generator) {\n  if (!Symbol.asyncIterator) throw new TypeError(\"Symbol.asyncIterator is not defined.\");\n  var g = generator.apply(thisArg, _arguments || []), i, q = [];\n  return i = Object.create((typeof AsyncIterator === \"function\" ? AsyncIterator : Object).prototype), verb(\"next\"), verb(\"throw\"), verb(\"return\", awaitReturn), i[Symbol.asyncIterator] = function () { return this; }, i;\n  function awaitReturn(f) { return function (v) { return Promise.resolve(v).then(f, reject); }; }\n  function verb(n, f) { if (g[n]) { i[n] = function (v) { return new Promise(function (a, b) { q.push([n, v, a, b]) > 1 || resume(n, v); }); }; if (f) i[n] = f(i[n]); } }\n  function resume(n, v) { try { step(g[n](v)); } catch (e) { settle(q[0][3], e); } }\n  function step(r) { r.value instanceof __await ? Promise.resolve(r.value.v).then(fulfill, reject) : settle(q[0][2], r); }\n  function fulfill(value) { resume(\"next\", value); }\n  function reject(value) { resume(\"throw\", value); }\n  function settle(f, v) { if (f(v), q.shift(), q.length) resume(q[0][0], q[0][1]); }\n}\n\nexport function __asyncDelegator(o) {\n  var i, p;\n  return i = {}, verb(\"next\"), verb(\"throw\", function (e) { throw e; }), verb(\"return\"), i[Symbol.iterator] = function () { return this; }, i;\n  function verb(n, f) { i[n] = o[n] ? function (v) { return (p = !p) ? { value: __await(o[n](v)), done: false } : f ? f(v) : v; } : f; }\n}\n\nexport function __asyncValues(o) {\n  if (!Symbol.asyncIterator) throw new TypeError(\"Symbol.asyncIterator is not defined.\");\n  var m = o[Symbol.asyncIterator], i;\n  return m ? m.call(o) : (o = typeof __values === \"function\" ? __values(o) : o[Symbol.iterator](), i = {}, verb(\"next\"), verb(\"throw\"), verb(\"return\"), i[Symbol.asyncIterator] = function () { return this; }, i);\n  function verb(n) { i[n] = o[n] && function (v) { return new Promise(function (resolve, reject) { v = o[n](v), settle(resolve, reject, v.done, v.value); }); }; }\n  function settle(resolve, reject, d, v) { Promise.resolve(v).then(function(v) { resolve({ value: v, done: d }); }, reject); }\n}\n\nexport function __makeTemplateObject(cooked, raw) {\n  if (Object.defineProperty) { Object.defineProperty(cooked, \"raw\", { value: raw }); } else { cooked.raw = raw; }\n  return cooked;\n};\n\nvar __setModuleDefault = Object.create ? (function(o, v) {\n  Object.defineProperty(o, \"default\", { enumerable: true, value: v });\n}) : function(o, v) {\n  o[\"default\"] = v;\n};\n\nexport function __importStar(mod) {\n  if (mod && mod.__esModule) return mod;\n  var result = {};\n  if (mod != null) for (var k in mod) if (k !== \"default\" && Object.prototype.hasOwnProperty.call(mod, k)) __createBinding(result, mod, k);\n  __setModuleDefault(result, mod);\n  return result;\n}\n\nexport function __importDefault(mod) {\n  return (mod && mod.__esModule) ? mod : { default: mod };\n}\n\nexport function __classPrivateFieldGet(receiver, state, kind, f) {\n  if (kind === \"a\" && !f) throw new TypeError(\"Private accessor was defined without a getter\");\n  if (typeof state === \"function\" ? receiver !== state || !f : !state.has(receiver)) throw new TypeError(\"Cannot read private member from an object whose class did not declare it\");\n  return kind === \"m\" ? f : kind === \"a\" ? f.call(receiver) : f ? f.value : state.get(receiver);\n}\n\nexport function __classPrivateFieldSet(receiver, state, value, kind, f) {\n  if (kind === \"m\") throw new TypeError(\"Private method is not writable\");\n  if (kind === \"a\" && !f) throw new TypeError(\"Private accessor was defined without a setter\");\n  if (typeof state === \"function\" ? receiver !== state || !f : !state.has(receiver)) throw new TypeError(\"Cannot write private member to an object whose class did not declare it\");\n  return (kind === \"a\" ? f.call(receiver, value) : f ? f.value = value : state.set(receiver, value)), value;\n}\n\nexport function __classPrivateFieldIn(state, receiver) {\n  if (receiver === null || (typeof receiver !== \"object\" && typeof receiver !== \"function\")) throw new TypeError(\"Cannot use 'in' operator on non-object\");\n  return typeof state === \"function\" ? receiver === state : state.has(receiver);\n}\n\nexport function __addDisposableResource(env, value, async) {\n  if (value !== null && value !== void 0) {\n    if (typeof value !== \"object\" && typeof value !== \"function\") throw new TypeError(\"Object expected.\");\n    var dispose, inner;\n    if (async) {\n      if (!Symbol.asyncDispose) throw new TypeError(\"Symbol.asyncDispose is not defined.\");\n      dispose = value[Symbol.asyncDispose];\n    }\n    if (dispose === void 0) {\n      if (!Symbol.dispose) throw new TypeError(\"Symbol.dispose is not defined.\");\n      dispose = value[Symbol.dispose];\n      if (async) inner = dispose;\n    }\n    if (typeof dispose !== \"function\") throw new TypeError(\"Object not disposable.\");\n    if (inner) dispose = function() { try { inner.call(this); } catch (e) { return Promise.reject(e); } };\n    env.stack.push({ value: value, dispose: dispose, async: async });\n  }\n  else if (async) {\n    env.stack.push({ async: true });\n  }\n  return value;\n}\n\nvar _SuppressedError = typeof SuppressedError === \"function\" ? SuppressedError : function (error, suppressed, message) {\n  var e = new Error(message);\n  return e.name = \"SuppressedError\", e.error = error, e.suppressed = suppressed, e;\n};\n\nexport function __disposeResources(env) {\n  function fail(e) {\n    env.error = env.hasError ? new _SuppressedError(e, env.error, \"An error was suppressed during disposal.\") : e;\n    env.hasError = true;\n  }\n  var r, s = 0;\n  function next() {\n    while (r = env.stack.pop()) {\n      try {\n        if (!r.async && s === 1) return s = 0, env.stack.push(r), Promise.resolve().then(next);\n        if (r.dispose) {\n          var result = r.dispose.call(r.value);\n          if (r.async) return s |= 2, Promise.resolve(result).then(next, function(e) { fail(e); return next(); });\n        }\n        else s |= 1;\n      }\n      catch (e) {\n        fail(e);\n      }\n    }\n    if (s === 1) return env.hasError ? Promise.reject(env.error) : Promise.resolve();\n    if (env.hasError) throw env.error;\n  }\n  return next();\n}\n\nexport default {\n  __extends,\n  __assign,\n  __rest,\n  __decorate,\n  __param,\n  __metadata,\n  __awaiter,\n  __generator,\n  __createBinding,\n  __exportStar,\n  __values,\n  __read,\n  __spread,\n  __spreadArrays,\n  __spreadArray,\n  __await,\n  __asyncGenerator,\n  __asyncDelegator,\n  __asyncValues,\n  __makeTemplateObject,\n  __importStar,\n  __importDefault,\n  __classPrivateFieldGet,\n  __classPrivateFieldSet,\n  __classPrivateFieldIn,\n  __addDisposableResource,\n  __disposeResources,\n};\n", "/**\n * Returns true if the object is a function.\n * @param value The value to check\n */\nexport function isFunction(value: any): value is (...args: any[]) => any {\n  return typeof value === 'function';\n}\n", "/**\n * Used to create Error subclasses until the community moves away from ES5.\n *\n * This is because compiling from TypeScript down to ES5 has issues with subclassing Errors\n * as well as other built-in types: https://github.com/Microsoft/TypeScript/issues/12123\n *\n * @param createImpl A factory function to create the actual constructor implementation. The returned\n * function should be a named function that calls `_super` internally.\n */\nexport function createErrorClass<T>(createImpl: (_super: any) => any): T {\n  const _super = (instance: any) => {\n    Error.call(instance);\n    instance.stack = new Error().stack;\n  };\n\n  const ctorFunc = createImpl(_super);\n  ctorFunc.prototype = Object.create(Error.prototype);\n  ctorFunc.prototype.constructor = ctorFunc;\n  return ctorFunc;\n}\n", "import { createErrorClass } from './createErrorClass';\n\nexport interface UnsubscriptionError extends Error {\n  readonly errors: any[];\n}\n\nexport interface UnsubscriptionErrorCtor {\n  /**\n   * @deprecated Internal implementation detail. Do not construct error instances.\n   * Cannot be tagged as internal: https://github.com/ReactiveX/rxjs/issues/6269\n   */\n  new (errors: any[]): UnsubscriptionError;\n}\n\n/**\n * An error thrown when one or more errors have occurred during the\n * `unsubscribe` of a {@link Subscription}.\n */\nexport const UnsubscriptionError: UnsubscriptionErrorCtor = createErrorClass(\n  (_super) =>\n    function UnsubscriptionErrorImpl(this: any, errors: (Error | string)[]) {\n      _super(this);\n      this.message = errors\n        ? `${errors.length} errors occurred during unsubscription:\n${errors.map((err, i) => `${i + 1}) ${err.toString()}`).join('\\n  ')}`\n        : '';\n      this.name = 'UnsubscriptionError';\n      this.errors = errors;\n    }\n);\n", "/**\n * Removes an item from an array, mutating it.\n * @param arr The array to remove the item from\n * @param item The item to remove\n */\nexport function arrRemove<T>(arr: T[] | undefined | null, item: T) {\n  if (arr) {\n    const index = arr.indexOf(item);\n    0 <= index && arr.splice(index, 1);\n  }\n}\n", "import { isFunction } from './util/isFunction';\nimport { UnsubscriptionError } from './util/UnsubscriptionError';\nimport { SubscriptionLike, TeardownLogic, Unsubscribable } from './types';\nimport { arrRemove } from './util/arrRemove';\n\n/**\n * Represents a disposable resource, such as the execution of an Observable. A\n * Subscription has one important method, `unsubscribe`, that takes no argument\n * and just disposes the resource held by the subscription.\n *\n * Additionally, subscriptions may be grouped together through the `add()`\n * method, which will attach a child Subscription to the current Subscription.\n * When a Subscription is unsubscribed, all its children (and its grandchildren)\n * will be unsubscribed as well.\n *\n * @class Subscription\n */\nexport class Subscription implements SubscriptionLike {\n  /** @nocollapse */\n  public static EMPTY = (() => {\n    const empty = new Subscription();\n    empty.closed = true;\n    return empty;\n  })();\n\n  /**\n   * A flag to indicate whether this Subscription has already been unsubscribed.\n   */\n  public closed = false;\n\n  private _parentage: Subscription[] | Subscription | null = null;\n\n  /**\n   * The list of registered finalizers to execute upon unsubscription. Adding and removing from this\n   * list occurs in the {@link #add} and {@link #remove} methods.\n   */\n  private _finalizers: Exclude<TeardownLogic, void>[] | null = null;\n\n  /**\n   * @param initialTeardown A function executed first as part of the finalization\n   * process that is kicked off when {@link #unsubscribe} is called.\n   */\n  constructor(private initialTeardown?: () => void) {}\n\n  /**\n   * Disposes the resources held by the subscription. May, for instance, cancel\n   * an ongoing Observable execution or cancel any other type of work that\n   * started when the Subscription was created.\n   * @return {void}\n   */\n  unsubscribe(): void {\n    let errors: any[] | undefined;\n\n    if (!this.closed) {\n      this.closed = true;\n\n      // Remove this from it's parents.\n      const { _parentage } = this;\n      if (_parentage) {\n        this._parentage = null;\n        if (Array.isArray(_parentage)) {\n          for (const parent of _parentage) {\n            parent.remove(this);\n          }\n        } else {\n          _parentage.remove(this);\n        }\n      }\n\n      const { initialTeardown: initialFinalizer } = this;\n      if (isFunction(initialFinalizer)) {\n        try {\n          initialFinalizer();\n        } catch (e) {\n          errors = e instanceof UnsubscriptionError ? e.errors : [e];\n        }\n      }\n\n      const { _finalizers } = this;\n      if (_finalizers) {\n        this._finalizers = null;\n        for (const finalizer of _finalizers) {\n          try {\n            execFinalizer(finalizer);\n          } catch (err) {\n            errors = errors ?? [];\n            if (err instanceof UnsubscriptionError) {\n              errors = [...errors, ...err.errors];\n            } else {\n              errors.push(err);\n            }\n          }\n        }\n      }\n\n      if (errors) {\n        throw new UnsubscriptionError(errors);\n      }\n    }\n  }\n\n  /**\n   * Adds a finalizer to this subscription, so that finalization will be unsubscribed/called\n   * when this subscription is unsubscribed. If this subscription is already {@link #closed},\n   * because it has already been unsubscribed, then whatever finalizer is passed to it\n   * will automatically be executed (unless the finalizer itself is also a closed subscription).\n   *\n   * Closed Subscriptions cannot be added as finalizers to any subscription. Adding a closed\n   * subscription to a any subscription will result in no operation. (A noop).\n   *\n   * Adding a subscription to itself, or adding `null` or `undefined` will not perform any\n   * operation at all. (A noop).\n   *\n   * `Subscription` instances that are added to this instance will automatically remove themselves\n   * if they are unsubscribed. Functions and {@link Unsubscribable} objects that you wish to remove\n   * will need to be removed manually with {@link #remove}\n   *\n   * @param teardown The finalization logic to add to this subscription.\n   */\n  add(teardown: TeardownLogic): void {\n    // Only add the finalizer if it's not undefined\n    // and don't add a subscription to itself.\n    if (teardown && teardown !== this) {\n      if (this.closed) {\n        // If this subscription is already closed,\n        // execute whatever finalizer is handed to it automatically.\n        execFinalizer(teardown);\n      } else {\n        if (teardown instanceof Subscription) {\n          // We don't add closed subscriptions, and we don't add the same subscription\n          // twice. Subscription unsubscribe is idempotent.\n          if (teardown.closed || teardown._hasParent(this)) {\n            return;\n          }\n          teardown._addParent(this);\n        }\n        (this._finalizers = this._finalizers ?? []).push(teardown);\n      }\n    }\n  }\n\n  /**\n   * Checks to see if a this subscription already has a particular parent.\n   * This will signal that this subscription has already been added to the parent in question.\n   * @param parent the parent to check for\n   */\n  private _hasParent(parent: Subscription) {\n    const { _parentage } = this;\n    return _parentage === parent || (Array.isArray(_parentage) && _parentage.includes(parent));\n  }\n\n  /**\n   * Adds a parent to this subscription so it can be removed from the parent if it\n   * unsubscribes on it's own.\n   *\n   * NOTE: THIS ASSUMES THAT {@link _hasParent} HAS ALREADY BEEN CHECKED.\n   * @param parent The parent subscription to add\n   */\n  private _addParent(parent: Subscription) {\n    const { _parentage } = this;\n    this._parentage = Array.isArray(_parentage) ? (_parentage.push(parent), _parentage) : _parentage ? [_parentage, parent] : parent;\n  }\n\n  /**\n   * Called on a child when it is removed via {@link #remove}.\n   * @param parent The parent to remove\n   */\n  private _removeParent(parent: Subscription) {\n    const { _parentage } = this;\n    if (_parentage === parent) {\n      this._parentage = null;\n    } else if (Array.isArray(_parentage)) {\n      arrRemove(_parentage, parent);\n    }\n  }\n\n  /**\n   * Removes a finalizer from this subscription that was previously added with the {@link #add} method.\n   *\n   * Note that `Subscription` instances, when unsubscribed, will automatically remove themselves\n   * from every other `Subscription` they have been added to. This means that using the `remove` method\n   * is not a common thing and should be used thoughtfully.\n   *\n   * If you add the same finalizer instance of a function or an unsubscribable object to a `Subscription` instance\n   * more than once, you will need to call `remove` the same number of times to remove all instances.\n   *\n   * All finalizer instances are removed to free up memory upon unsubscription.\n   *\n   * @param teardown The finalizer to remove from this subscription\n   */\n  remove(teardown: Exclude<TeardownLogic, void>): void {\n    const { _finalizers } = this;\n    _finalizers && arrRemove(_finalizers, teardown);\n\n    if (teardown instanceof Subscription) {\n      teardown._removeParent(this);\n    }\n  }\n}\n\nexport const EMPTY_SUBSCRIPTION = Subscription.EMPTY;\n\nexport function isSubscription(value: any): value is Subscription {\n  return (\n    value instanceof Subscription ||\n    (value && 'closed' in value && isFunction(value.remove) && isFunction(value.add) && isFunction(value.unsubscribe))\n  );\n}\n\nfunction execFinalizer(finalizer: Unsubscribable | (() => void)) {\n  if (isFunction(finalizer)) {\n    finalizer();\n  } else {\n    finalizer.unsubscribe();\n  }\n}\n", "import { Subscriber } from './Subscriber';\nimport { ObservableNotification } from './types';\n\n/**\n * The {@link GlobalConfig} object for RxJS. It is used to configure things\n * like how to react on unhandled errors.\n */\nexport const config: GlobalConfig = {\n  onUnhandledError: null,\n  onStoppedNotification: null,\n  Promise: undefined,\n  useDeprecatedSynchronousErrorHandling: false,\n  useDeprecatedNextContext: false,\n};\n\n/**\n * The global configuration object for RxJS, used to configure things\n * like how to react on unhandled errors. Accessible via {@link config}\n * object.\n */\nexport interface GlobalConfig {\n  /**\n   * A registration point for unhandled errors from RxJS. These are errors that\n   * cannot were not handled by consuming code in the usual subscription path. For\n   * example, if you have this configured, and you subscribe to an observable without\n   * providing an error handler, errors from that subscription will end up here. This\n   * will _always_ be called asynchronously on another job in the runtime. This is because\n   * we do not want errors thrown in this user-configured handler to interfere with the\n   * behavior of the library.\n   */\n  onUnhandledError: ((err: any) => void) | null;\n\n  /**\n   * A registration point for notifications that cannot be sent to subscribers because they\n   * have completed, errored or have been explicitly unsubscribed. By default, next, complete\n   * and error notifications sent to stopped subscribers are noops. However, sometimes callers\n   * might want a different behavior. For example, with sources that attempt to report errors\n   * to stopped subscribers, a caller can configure RxJS to throw an unhandled error instead.\n   * This will _always_ be called asynchronously on another job in the runtime. This is because\n   * we do not want errors thrown in this user-configured handler to interfere with the\n   * behavior of the library.\n   */\n  onStoppedNotification: ((notification: ObservableNotification<any>, subscriber: Subscriber<any>) => void) | null;\n\n  /**\n   * The promise constructor used by default for {@link Observable#toPromise toPromise} and {@link Observable#forEach forEach}\n   * methods.\n   *\n   * @deprecated As of version 8, RxJS will no longer support this sort of injection of a\n   * Promise constructor. If you need a Promise implementation other than native promises,\n   * please polyfill/patch Promise as you see appropriate. Will be removed in v8.\n   */\n  Promise?: PromiseConstructorLike;\n\n  /**\n   * If true, turns on synchronous error rethrowing, which is a deprecated behavior\n   * in v6 and higher. This behavior enables bad patterns like wrapping a subscribe\n   * call in a try/catch block. It also enables producer interference, a nasty bug\n   * where a multicast can be broken for all observers by a downstream consumer with\n   * an unhandled error. DO NOT USE THIS FLAG UNLESS IT'S NEEDED TO BUY TIME\n   * FOR MIGRATION REASONS.\n   *\n   * @deprecated As of version 8, RxJS will no longer support synchronous throwing\n   * of unhandled errors. All errors will be thrown on a separate call stack to prevent bad\n   * behaviors described above. Will be removed in v8.\n   */\n  useDeprecatedSynchronousErrorHandling: boolean;\n\n  /**\n   * If true, enables an as-of-yet undocumented feature from v5: The ability to access\n   * `unsubscribe()` via `this` context in `next` functions created in observers passed\n   * to `subscribe`.\n   *\n   * This is being removed because the performance was severely problematic, and it could also cause\n   * issues when types other than POJOs are passed to subscribe as subscribers, as they will likely have\n   * their `this` context overwritten.\n   *\n   * @deprecated As of version 8, RxJS will no longer support altering the\n   * context of next functions provided as part of an observer to Subscribe. Instead,\n   * you will have access to a subscription or a signal or token that will allow you to do things like\n   * unsubscribe and test closed status. Will be removed in v8.\n   */\n  useDeprecatedNextContext: boolean;\n}\n", "import type { TimerHandle } from './timerHandle';\ntype SetTimeoutFunction = (handler: () => void, timeout?: number, ...args: any[]) => TimerHandle;\ntype ClearTimeoutFunction = (handle: TimerHandle) => void;\n\ninterface TimeoutProvider {\n  setTimeout: SetTimeoutFunction;\n  clearTimeout: ClearTimeoutFunction;\n  delegate:\n    | {\n        setTimeout: SetTimeoutFunction;\n        clearTimeout: ClearTimeoutFunction;\n      }\n    | undefined;\n}\n\nexport const timeoutProvider: TimeoutProvider = {\n  // When accessing the delegate, use the variable rather than `this` so that\n  // the functions can be called without being bound to the provider.\n  setTimeout(handler: () => void, timeout?: number, ...args) {\n    const { delegate } = timeoutProvider;\n    if (delegate?.setTimeout) {\n      return delegate.setTimeout(handler, timeout, ...args);\n    }\n    return setTimeout(handler, timeout, ...args);\n  },\n  clearTimeout(handle) {\n    const { delegate } = timeoutProvider;\n    return (delegate?.clearTimeout || clearTimeout)(handle as any);\n  },\n  delegate: undefined,\n};\n", "import { config } from '../config';\nimport { timeoutProvider } from '../scheduler/timeoutProvider';\n\n/**\n * Handles an error on another job either with the user-configured {@link onUnhandledError},\n * or by throwing it on that new job so it can be picked up by `window.onerror`, `process.on('error')`, etc.\n *\n * This should be called whenever there is an error that is out-of-band with the subscription\n * or when an error hits a terminal boundary of the subscription and no error handler was provided.\n *\n * @param err the error to report\n */\nexport function reportUnhandledError(err: any) {\n  timeoutProvider.setTimeout(() => {\n    const { onUnhandledError } = config;\n    if (onUnhandledError) {\n      // Execute the user-configured error handler.\n      onUnhandledError(err);\n    } else {\n      // Throw so it is picked up by the runtime's uncaught error mechanism.\n      throw err;\n    }\n  });\n}\n", "/* tslint:disable:no-empty */\nexport function noop() { }\n", "import { CompleteNotification, NextNotification, ErrorNotification } from './types';\n\n/**\n * A completion object optimized for memory use and created to be the\n * same \"shape\" as other notifications in v8.\n * @internal\n */\nexport const COMPLETE_NOTIFICATION = (() => createNotification('C', undefined, undefined) as CompleteNotification)();\n\n/**\n * Internal use only. Creates an optimized error notification that is the same \"shape\"\n * as other notifications.\n * @internal\n */\nexport function errorNotification(error: any): ErrorNotification {\n  return createNotification('E', undefined, error) as any;\n}\n\n/**\n * Internal use only. Creates an optimized next notification that is the same \"shape\"\n * as other notifications.\n * @internal\n */\nexport function nextNotification<T>(value: T) {\n  return createNotification('N', value, undefined) as NextNotification<T>;\n}\n\n/**\n * Ensures that all notifications created internally have the same \"shape\" in v8.\n *\n * TODO: This is only exported to support a crazy legacy test in `groupBy`.\n * @internal\n */\nexport function createNotification(kind: 'N' | 'E' | 'C', value: any, error: any) {\n  return {\n    kind,\n    value,\n    error,\n  };\n}\n", "import { config } from '../config';\n\nlet context: { errorThrown: boolean; error: any } | null = null;\n\n/**\n * Handles dealing with errors for super-gross mode. Creates a context, in which\n * any synchronously thrown errors will be passed to {@link captureError}. Which\n * will record the error such that it will be rethrown after the call back is complete.\n * TODO: Remove in v8\n * @param cb An immediately executed function.\n */\nexport function errorContext(cb: () => void) {\n  if (config.useDeprecatedSynchronousErrorHandling) {\n    const isRoot = !context;\n    if (isRoot) {\n      context = { errorThrown: false, error: null };\n    }\n    cb();\n    if (isRoot) {\n      const { errorThrown, error } = context!;\n      context = null;\n      if (errorThrown) {\n        throw error;\n      }\n    }\n  } else {\n    // This is the general non-deprecated path for everyone that\n    // isn't crazy enough to use super-gross mode (useDeprecatedSynchronousErrorHandling)\n    cb();\n  }\n}\n\n/**\n * Captures errors only in super-gross mode.\n * @param err the error to capture\n */\nexport function captureError(err: any) {\n  if (config.useDeprecatedSynchronousErrorHandling && context) {\n    context.errorThrown = true;\n    context.error = err;\n  }\n}\n", "import { isFunction } from './util/isFunction';\nimport { Observer, ObservableNotification } from './types';\nimport { isSubscription, Subscription } from './Subscription';\nimport { config } from './config';\nimport { reportUnhandledError } from './util/reportUnhandledError';\nimport { noop } from './util/noop';\nimport { nextNotification, errorNotification, COMPLETE_NOTIFICATION } from './NotificationFactories';\nimport { timeoutProvider } from './scheduler/timeoutProvider';\nimport { captureError } from './util/errorContext';\n\n/**\n * Implements the {@link Observer} interface and extends the\n * {@link Subscription} class. While the {@link Observer} is the public API for\n * consuming the values of an {@link Observable}, all Observers get converted to\n * a Subscriber, in order to provide Subscription-like capabilities such as\n * `unsubscribe`. Subscriber is a common type in RxJS, and crucial for\n * implementing operators, but it is rarely used as a public API.\n *\n * @class Subscriber<T>\n */\nexport class Subscriber<T> extends Subscription implements Observer<T> {\n  /**\n   * A static factory for a Subscriber, given a (potentially partial) definition\n   * of an Observer.\n   * @param next The `next` callback of an Observer.\n   * @param error The `error` callback of an\n   * Observer.\n   * @param complete The `complete` callback of an\n   * Observer.\n   * @return A Subscriber wrapping the (partially defined)\n   * Observer represented by the given arguments.\n   * @nocollapse\n   * @deprecated Do not use. Will be removed in v8. There is no replacement for this\n   * method, and there is no reason to be creating instances of `Subscriber` directly.\n   * If you have a specific use case, please file an issue.\n   */\n  static create<T>(next?: (x?: T) => void, error?: (e?: any) => void, complete?: () => void): Subscriber<T> {\n    return new SafeSubscriber(next, error, complete);\n  }\n\n  /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n  protected isStopped: boolean = false;\n  /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n  protected destination: Subscriber<any> | Observer<any>; // this `any` is the escape hatch to erase extra type param (e.g. R)\n\n  /**\n   * @deprecated Internal implementation detail, do not use directly. Will be made internal in v8.\n   * There is no reason to directly create an instance of Subscriber. This type is exported for typings reasons.\n   */\n  constructor(destination?: Subscriber<any> | Observer<any>) {\n    super();\n    if (destination) {\n      this.destination = destination;\n      // Automatically chain subscriptions together here.\n      // if destination is a Subscription, then it is a Subscriber.\n      if (isSubscription(destination)) {\n        destination.add(this);\n      }\n    } else {\n      this.destination = EMPTY_OBSERVER;\n    }\n  }\n\n  /**\n   * The {@link Observer} callback to receive notifications of type `next` from\n   * the Observable, with a value. The Observable may call this method 0 or more\n   * times.\n   * @param {T} [value] The `next` value.\n   * @return {void}\n   */\n  next(value?: T): void {\n    if (this.isStopped) {\n      handleStoppedNotification(nextNotification(value), this);\n    } else {\n      this._next(value!);\n    }\n  }\n\n  /**\n   * The {@link Observer} callback to receive notifications of type `error` from\n   * the Observable, with an attached `Error`. Notifies the Observer that\n   * the Observable has experienced an error condition.\n   * @param {any} [err] The `error` exception.\n   * @return {void}\n   */\n  error(err?: any): void {\n    if (this.isStopped) {\n      handleStoppedNotification(errorNotification(err), this);\n    } else {\n      this.isStopped = true;\n      this._error(err);\n    }\n  }\n\n  /**\n   * The {@link Observer} callback to receive a valueless notification of type\n   * `complete` from the Observable. Notifies the Observer that the Observable\n   * has finished sending push-based notifications.\n   * @return {void}\n   */\n  complete(): void {\n    if (this.isStopped) {\n      handleStoppedNotification(COMPLETE_NOTIFICATION, this);\n    } else {\n      this.isStopped = true;\n      this._complete();\n    }\n  }\n\n  unsubscribe(): void {\n    if (!this.closed) {\n      this.isStopped = true;\n      super.unsubscribe();\n      this.destination = null!;\n    }\n  }\n\n  protected _next(value: T): void {\n    this.destination.next(value);\n  }\n\n  protected _error(err: any): void {\n    try {\n      this.destination.error(err);\n    } finally {\n      this.unsubscribe();\n    }\n  }\n\n  protected _complete(): void {\n    try {\n      this.destination.complete();\n    } finally {\n      this.unsubscribe();\n    }\n  }\n}\n\n/**\n * This bind is captured here because we want to be able to have\n * compatibility with monoid libraries that tend to use a method named\n * `bind`. In particular, a library called Monio requires this.\n */\nconst _bind = Function.prototype.bind;\n\nfunction bind<Fn extends (...args: any[]) => any>(fn: Fn, thisArg: any): Fn {\n  return _bind.call(fn, thisArg);\n}\n\n/**\n * Internal optimization only, DO NOT EXPOSE.\n * @internal\n */\nclass ConsumerObserver<T> implements Observer<T> {\n  constructor(private partialObserver: Partial<Observer<T>>) {}\n\n  next(value: T): void {\n    const { partialObserver } = this;\n    if (partialObserver.next) {\n      try {\n        partialObserver.next(value);\n      } catch (error) {\n        handleUnhandledError(error);\n      }\n    }\n  }\n\n  error(err: any): void {\n    const { partialObserver } = this;\n    if (partialObserver.error) {\n      try {\n        partialObserver.error(err);\n      } catch (error) {\n        handleUnhandledError(error);\n      }\n    } else {\n      handleUnhandledError(err);\n    }\n  }\n\n  complete(): void {\n    const { partialObserver } = this;\n    if (partialObserver.complete) {\n      try {\n        partialObserver.complete();\n      } catch (error) {\n        handleUnhandledError(error);\n      }\n    }\n  }\n}\n\nexport class SafeSubscriber<T> extends Subscriber<T> {\n  constructor(\n    observerOrNext?: Partial<Observer<T>> | ((value: T) => void) | null,\n    error?: ((e?: any) => void) | null,\n    complete?: (() => void) | null\n  ) {\n    super();\n\n    let partialObserver: Partial<Observer<T>>;\n    if (isFunction(observerOrNext) || !observerOrNext) {\n      // The first argument is a function, not an observer. The next\n      // two arguments *could* be observers, or they could be empty.\n      partialObserver = {\n        next: (observerOrNext ?? undefined) as (((value: T) => void) | undefined),\n        error: error ?? undefined,\n        complete: complete ?? undefined,\n      };\n    } else {\n      // The first argument is a partial observer.\n      let context: any;\n      if (this && config.useDeprecatedNextContext) {\n        // This is a deprecated path that made `this.unsubscribe()` available in\n        // next handler functions passed to subscribe. This only exists behind a flag\n        // now, as it is *very* slow.\n        context = Object.create(observerOrNext);\n        context.unsubscribe = () => this.unsubscribe();\n        partialObserver = {\n          next: observerOrNext.next && bind(observerOrNext.next, context),\n          error: observerOrNext.error && bind(observerOrNext.error, context),\n          complete: observerOrNext.complete && bind(observerOrNext.complete, context),\n        };\n      } else {\n        // The \"normal\" path. Just use the partial observer directly.\n        partialObserver = observerOrNext;\n      }\n    }\n\n    // Wrap the partial observer to ensure it's a full observer, and\n    // make sure proper error handling is accounted for.\n    this.destination = new ConsumerObserver(partialObserver);\n  }\n}\n\nfunction handleUnhandledError(error: any) {\n  if (config.useDeprecatedSynchronousErrorHandling) {\n    captureError(error);\n  } else {\n    // Ideal path, we report this as an unhandled error,\n    // which is thrown on a new call stack.\n    reportUnhandledError(error);\n  }\n}\n\n/**\n * An error handler used when no error handler was supplied\n * to the SafeSubscriber -- meaning no error handler was supplied\n * do the `subscribe` call on our observable.\n * @param err The error to handle\n */\nfunction defaultErrorHandler(err: any) {\n  throw err;\n}\n\n/**\n * A handler for notifications that cannot be sent to a stopped subscriber.\n * @param notification The notification being sent\n * @param subscriber The stopped subscriber\n */\nfunction handleStoppedNotification(notification: ObservableNotification<any>, subscriber: Subscriber<any>) {\n  const { onStoppedNotification } = config;\n  onStoppedNotification && timeoutProvider.setTimeout(() => onStoppedNotification(notification, subscriber));\n}\n\n/**\n * The observer used as a stub for subscriptions where the user did not\n * pass any arguments to `subscribe`. Comes with the default error handling\n * behavior.\n */\nexport const EMPTY_OBSERVER: Readonly<Observer<any>> & { closed: true } = {\n  closed: true,\n  next: noop,\n  error: defaultErrorHandler,\n  complete: noop,\n};\n", "/**\n * Symbol.observable or a string \"@@observable\". Used for interop\n *\n * @deprecated We will no longer be exporting this symbol in upcoming versions of RxJS.\n * Instead polyfill and use Symbol.observable directly *or* use https://www.npmjs.com/package/symbol-observable\n */\nexport const observable: string | symbol = (() => (typeof Symbol === 'function' && Symbol.observable) || '@@observable')();\n", "/**\n * This function takes one parameter and just returns it. Simply put,\n * this is like `<T>(x: T): T => x`.\n *\n * ## Examples\n *\n * This is useful in some cases when using things like `mergeMap`\n *\n * ```ts\n * import { interval, take, map, range, mergeMap, identity } from 'rxjs';\n *\n * const source$ = interval(1000).pipe(take(5));\n *\n * const result$ = source$.pipe(\n *   map(i => range(i)),\n *   mergeMap(identity) // same as mergeMap(x => x)\n * );\n *\n * result$.subscribe({\n *   next: console.log\n * });\n * ```\n *\n * Or when you want to selectively apply an operator\n *\n * ```ts\n * import { interval, take, identity } from 'rxjs';\n *\n * const shouldLimit = () => Math.random() < 0.5;\n *\n * const source$ = interval(1000);\n *\n * const result$ = source$.pipe(shouldLimit() ? take(5) : identity);\n *\n * result$.subscribe({\n *   next: console.log\n * });\n * ```\n *\n * @param x Any value that is returned by this function\n * @returns The value passed as the first parameter to this function\n */\nexport function identity<T>(x: T): T {\n  return x;\n}\n", "import { identity } from './identity';\nimport { UnaryFunction } from '../types';\n\nexport function pipe(): typeof identity;\nexport function pipe<T, A>(fn1: UnaryFunction<T, A>): UnaryFunction<T, A>;\nexport function pipe<T, A, B>(fn1: UnaryFunction<T, A>, fn2: UnaryFunction<A, B>): UnaryFunction<T, B>;\nexport function pipe<T, A, B, C>(fn1: UnaryFunction<T, A>, fn2: UnaryFunction<A, B>, fn3: UnaryFunction<B, C>): UnaryFunction<T, C>;\nexport function pipe<T, A, B, C, D>(\n  fn1: UnaryFunction<T, A>,\n  fn2: UnaryFunction<A, B>,\n  fn3: UnaryFunction<B, C>,\n  fn4: UnaryFunction<C, D>\n): UnaryFunction<T, D>;\nexport function pipe<T, A, B, C, D, E>(\n  fn1: UnaryFunction<T, A>,\n  fn2: UnaryFunction<A, B>,\n  fn3: UnaryFunction<B, C>,\n  fn4: UnaryFunction<C, D>,\n  fn5: UnaryFunction<D, E>\n): UnaryFunction<T, E>;\nexport function pipe<T, A, B, C, D, E, F>(\n  fn1: UnaryFunction<T, A>,\n  fn2: UnaryFunction<A, B>,\n  fn3: UnaryFunction<B, C>,\n  fn4: UnaryFunction<C, D>,\n  fn5: UnaryFunction<D, E>,\n  fn6: UnaryFunction<E, F>\n): UnaryFunction<T, F>;\nexport function pipe<T, A, B, C, D, E, F, G>(\n  fn1: UnaryFunction<T, A>,\n  fn2: UnaryFunction<A, B>,\n  fn3: UnaryFunction<B, C>,\n  fn4: UnaryFunction<C, D>,\n  fn5: UnaryFunction<D, E>,\n  fn6: UnaryFunction<E, F>,\n  fn7: UnaryFunction<F, G>\n): UnaryFunction<T, G>;\nexport function pipe<T, A, B, C, D, E, F, G, H>(\n  fn1: UnaryFunction<T, A>,\n  fn2: UnaryFunction<A, B>,\n  fn3: UnaryFunction<B, C>,\n  fn4: UnaryFunction<C, D>,\n  fn5: UnaryFunction<D, E>,\n  fn6: UnaryFunction<E, F>,\n  fn7: UnaryFunction<F, G>,\n  fn8: UnaryFunction<G, H>\n): UnaryFunction<T, H>;\nexport function pipe<T, A, B, C, D, E, F, G, H, I>(\n  fn1: UnaryFunction<T, A>,\n  fn2: UnaryFunction<A, B>,\n  fn3: UnaryFunction<B, C>,\n  fn4: UnaryFunction<C, D>,\n  fn5: UnaryFunction<D, E>,\n  fn6: UnaryFunction<E, F>,\n  fn7: UnaryFunction<F, G>,\n  fn8: UnaryFunction<G, H>,\n  fn9: UnaryFunction<H, I>\n): UnaryFunction<T, I>;\nexport function pipe<T, A, B, C, D, E, F, G, H, I>(\n  fn1: UnaryFunction<T, A>,\n  fn2: UnaryFunction<A, B>,\n  fn3: UnaryFunction<B, C>,\n  fn4: UnaryFunction<C, D>,\n  fn5: UnaryFunction<D, E>,\n  fn6: UnaryFunction<E, F>,\n  fn7: UnaryFunction<F, G>,\n  fn8: UnaryFunction<G, H>,\n  fn9: UnaryFunction<H, I>,\n  ...fns: UnaryFunction<any, any>[]\n): UnaryFunction<T, unknown>;\n\n/**\n * pipe() can be called on one or more functions, each of which can take one argument (\"UnaryFunction\")\n * and uses it to return a value.\n * It returns a function that takes one argument, passes it to the first UnaryFunction, and then\n * passes the result to the next one, passes that result to the next one, and so on.  \n */\nexport function pipe(...fns: Array<UnaryFunction<any, any>>): UnaryFunction<any, any> {\n  return pipeFromArray(fns);\n}\n\n/** @internal */\nexport function pipeFromArray<T, R>(fns: Array<UnaryFunction<T, R>>): UnaryFunction<T, R> {\n  if (fns.length === 0) {\n    return identity as UnaryFunction<any, any>;\n  }\n\n  if (fns.length === 1) {\n    return fns[0];\n  }\n\n  return function piped(input: T): R {\n    return fns.reduce((prev: any, fn: UnaryFunction<T, R>) => fn(prev), input as any);\n  };\n}\n", "import { Operator } from './Operator';\nimport { SafeSubscriber, Subscriber } from './Subscriber';\nimport { isSubscription, Subscription } from './Subscription';\nimport { TeardownLogic, OperatorFunction, Subscribable, Observer } from './types';\nimport { observable as Symbol_observable } from './symbol/observable';\nimport { pipeFromArray } from './util/pipe';\nimport { config } from './config';\nimport { isFunction } from './util/isFunction';\nimport { errorContext } from './util/errorContext';\n\n/**\n * A representation of any set of values over any amount of time. This is the most basic building block\n * of RxJS.\n *\n * @class Observable<T>\n */\nexport class Observable<T> implements Subscribable<T> {\n  /**\n   * @deprecated Internal implementation detail, do not use directly. Will be made internal in v8.\n   */\n  source: Observable<any> | undefined;\n\n  /**\n   * @deprecated Internal implementation detail, do not use directly. Will be made internal in v8.\n   */\n  operator: Operator<any, T> | undefined;\n\n  /**\n   * @constructor\n   * @param {Function} subscribe the function that is called when the Observable is\n   * initially subscribed to. This function is given a Subscriber, to which new values\n   * can be `next`ed, or an `error` method can be called to raise an error, or\n   * `complete` can be called to notify of a successful completion.\n   */\n  constructor(subscribe?: (this: Observable<T>, subscriber: Subscriber<T>) => TeardownLogic) {\n    if (subscribe) {\n      this._subscribe = subscribe;\n    }\n  }\n\n  // HACK: Since TypeScript inherits static properties too, we have to\n  // fight against TypeScript here so Subject can have a different static create signature\n  /**\n   * Creates a new Observable by calling the Observable constructor\n   * @owner Observable\n   * @method create\n   * @param {Function} subscribe? the subscriber function to be passed to the Observable constructor\n   * @return {Observable} a new observable\n   * @nocollapse\n   * @deprecated Use `new Observable()` instead. Will be removed in v8.\n   */\n  static create: (...args: any[]) => any = <T>(subscribe?: (subscriber: Subscriber<T>) => TeardownLogic) => {\n    return new Observable<T>(subscribe);\n  };\n\n  /**\n   * Creates a new Observable, with this Observable instance as the source, and the passed\n   * operator defined as the new observable's operator.\n   * @method lift\n   * @param operator the operator defining the operation to take on the observable\n   * @return a new observable with the Operator applied\n   * @deprecated Internal implementation detail, do not use directly. Will be made internal in v8.\n   * If you have implemented an operator using `lift`, it is recommended that you create an\n   * operator by simply returning `new Observable()` directly. See \"Creating new operators from\n   * scratch\" section here: https://rxjs.dev/guide/operators\n   */\n  lift<R>(operator?: Operator<T, R>): Observable<R> {\n    const observable = new Observable<R>();\n    observable.source = this;\n    observable.operator = operator;\n    return observable;\n  }\n\n  subscribe(observerOrNext?: Partial<Observer<T>> | ((value: T) => void)): Subscription;\n  /** @deprecated Instead of passing separate callback arguments, use an observer argument. Signatures taking separate callback arguments will be removed in v8. Details: https://rxjs.dev/deprecations/subscribe-arguments */\n  subscribe(next?: ((value: T) => void) | null, error?: ((error: any) => void) | null, complete?: (() => void) | null): Subscription;\n  /**\n   * Invokes an execution of an Observable and registers Observer handlers for notifications it will emit.\n   *\n   * <span class=\"informal\">Use it when you have all these Observables, but still nothing is happening.</span>\n   *\n   * `subscribe` is not a regular operator, but a method that calls Observable's internal `subscribe` function. It\n   * might be for example a function that you passed to Observable's constructor, but most of the time it is\n   * a library implementation, which defines what will be emitted by an Observable, and when it be will emitted. This means\n   * that calling `subscribe` is actually the moment when Observable starts its work, not when it is created, as it is often\n   * the thought.\n   *\n   * Apart from starting the execution of an Observable, this method allows you to listen for values\n   * that an Observable emits, as well as for when it completes or errors. You can achieve this in two\n   * of the following ways.\n   *\n   * The first way is creating an object that implements {@link Observer} interface. It should have methods\n   * defined by that interface, but note that it should be just a regular JavaScript object, which you can create\n   * yourself in any way you want (ES6 class, classic function constructor, object literal etc.). In particular, do\n   * not attempt to use any RxJS implementation details to create Observers - you don't need them. Remember also\n   * that your object does not have to implement all methods. If you find yourself creating a method that doesn't\n   * do anything, you can simply omit it. Note however, if the `error` method is not provided and an error happens,\n   * it will be thrown asynchronously. Errors thrown asynchronously cannot be caught using `try`/`catch`. Instead,\n   * use the {@link onUnhandledError} configuration option or use a runtime handler (like `window.onerror` or\n   * `process.on('error)`) to be notified of unhandled errors. Because of this, it's recommended that you provide\n   * an `error` method to avoid missing thrown errors.\n   *\n   * The second way is to give up on Observer object altogether and simply provide callback functions in place of its methods.\n   * This means you can provide three functions as arguments to `subscribe`, where the first function is equivalent\n   * of a `next` method, the second of an `error` method and the third of a `complete` method. Just as in case of an Observer,\n   * if you do not need to listen for something, you can omit a function by passing `undefined` or `null`,\n   * since `subscribe` recognizes these functions by where they were placed in function call. When it comes\n   * to the `error` function, as with an Observer, if not provided, errors emitted by an Observable will be thrown asynchronously.\n   *\n   * You can, however, subscribe with no parameters at all. This may be the case where you're not interested in terminal events\n   * and you also handled emissions internally by using operators (e.g. using `tap`).\n   *\n   * Whichever style of calling `subscribe` you use, in both cases it returns a Subscription object.\n   * This object allows you to call `unsubscribe` on it, which in turn will stop the work that an Observable does and will clean\n   * up all resources that an Observable used. Note that cancelling a subscription will not call `complete` callback\n   * provided to `subscribe` function, which is reserved for a regular completion signal that comes from an Observable.\n   *\n   * Remember that callbacks provided to `subscribe` are not guaranteed to be called asynchronously.\n   * It is an Observable itself that decides when these functions will be called. For example {@link of}\n   * by default emits all its values synchronously. Always check documentation for how given Observable\n   * will behave when subscribed and if its default behavior can be modified with a `scheduler`.\n   *\n   * #### Examples\n   *\n   * Subscribe with an {@link guide/observer Observer}\n   *\n   * ```ts\n   * import { of } from 'rxjs';\n   *\n   * const sumObserver = {\n   *   sum: 0,\n   *   next(value) {\n   *     console.log('Adding: ' + value);\n   *     this.sum = this.sum + value;\n   *   },\n   *   error() {\n   *     // We actually could just remove this method,\n   *     // since we do not really care about errors right now.\n   *   },\n   *   complete() {\n   *     console.log('Sum equals: ' + this.sum);\n   *   }\n   * };\n   *\n   * of(1, 2, 3) // Synchronously emits 1, 2, 3 and then completes.\n   *   .subscribe(sumObserver);\n   *\n   * // Logs:\n   * // 'Adding: 1'\n   * // 'Adding: 2'\n   * // 'Adding: 3'\n   * // 'Sum equals: 6'\n   * ```\n   *\n   * Subscribe with functions ({@link deprecations/subscribe-arguments deprecated})\n   *\n   * ```ts\n   * import { of } from 'rxjs'\n   *\n   * let sum = 0;\n   *\n   * of(1, 2, 3).subscribe(\n   *   value => {\n   *     console.log('Adding: ' + value);\n   *     sum = sum + value;\n   *   },\n   *   undefined,\n   *   () => console.log('Sum equals: ' + sum)\n   * );\n   *\n   * // Logs:\n   * // 'Adding: 1'\n   * // 'Adding: 2'\n   * // 'Adding: 3'\n   * // 'Sum equals: 6'\n   * ```\n   *\n   * Cancel a subscription\n   *\n   * ```ts\n   * import { interval } from 'rxjs';\n   *\n   * const subscription = interval(1000).subscribe({\n   *   next(num) {\n   *     console.log(num)\n   *   },\n   *   complete() {\n   *     // Will not be called, even when cancelling subscription.\n   *     console.log('completed!');\n   *   }\n   * });\n   *\n   * setTimeout(() => {\n   *   subscription.unsubscribe();\n   *   console.log('unsubscribed!');\n   * }, 2500);\n   *\n   * // Logs:\n   * // 0 after 1s\n   * // 1 after 2s\n   * // 'unsubscribed!' after 2.5s\n   * ```\n   *\n   * @param {Observer|Function} observerOrNext (optional) Either an observer with methods to be called,\n   * or the first of three possible handlers, which is the handler for each value emitted from the subscribed\n   * Observable.\n   * @param {Function} error (optional) A handler for a terminal event resulting from an error. If no error handler is provided,\n   * the error will be thrown asynchronously as unhandled.\n   * @param {Function} complete (optional) A handler for a terminal event resulting from successful completion.\n   * @return {Subscription} a subscription reference to the registered handlers\n   * @method subscribe\n   */\n  subscribe(\n    observerOrNext?: Partial<Observer<T>> | ((value: T) => void) | null,\n    error?: ((error: any) => void) | null,\n    complete?: (() => void) | null\n  ): Subscription {\n    const subscriber = isSubscriber(observerOrNext) ? observerOrNext : new SafeSubscriber(observerOrNext, error, complete);\n\n    errorContext(() => {\n      const { operator, source } = this;\n      subscriber.add(\n        operator\n          ? // We're dealing with a subscription in the\n            // operator chain to one of our lifted operators.\n            operator.call(subscriber, source)\n          : source\n          ? // If `source` has a value, but `operator` does not, something that\n            // had intimate knowledge of our API, like our `Subject`, must have\n            // set it. We're going to just call `_subscribe` directly.\n            this._subscribe(subscriber)\n          : // In all other cases, we're likely wrapping a user-provided initializer\n            // function, so we need to catch errors and handle them appropriately.\n            this._trySubscribe(subscriber)\n      );\n    });\n\n    return subscriber;\n  }\n\n  /** @internal */\n  protected _trySubscribe(sink: Subscriber<T>): TeardownLogic {\n    try {\n      return this._subscribe(sink);\n    } catch (err) {\n      // We don't need to return anything in this case,\n      // because it's just going to try to `add()` to a subscription\n      // above.\n      sink.error(err);\n    }\n  }\n\n  /**\n   * Used as a NON-CANCELLABLE means of subscribing to an observable, for use with\n   * APIs that expect promises, like `async/await`. You cannot unsubscribe from this.\n   *\n   * **WARNING**: Only use this with observables you *know* will complete. If the source\n   * observable does not complete, you will end up with a promise that is hung up, and\n   * potentially all of the state of an async function hanging out in memory. To avoid\n   * this situation, look into adding something like {@link timeout}, {@link take},\n   * {@link takeWhile}, or {@link takeUntil} amongst others.\n   *\n   * #### Example\n   *\n   * ```ts\n   * import { interval, take } from 'rxjs';\n   *\n   * const source$ = interval(1000).pipe(take(4));\n   *\n   * async function getTotal() {\n   *   let total = 0;\n   *\n   *   await source$.forEach(value => {\n   *     total += value;\n   *     console.log('observable -> ' + value);\n   *   });\n   *\n   *   return total;\n   * }\n   *\n   * getTotal().then(\n   *   total => console.log('Total: ' + total)\n   * );\n   *\n   * // Expected:\n   * // 'observable -> 0'\n   * // 'observable -> 1'\n   * // 'observable -> 2'\n   * // 'observable -> 3'\n   * // 'Total: 6'\n   * ```\n   *\n   * @param next a handler for each value emitted by the observable\n   * @return a promise that either resolves on observable completion or\n   *  rejects with the handled error\n   */\n  forEach(next: (value: T) => void): Promise<void>;\n\n  /**\n   * @param next a handler for each value emitted by the observable\n   * @param promiseCtor a constructor function used to instantiate the Promise\n   * @return a promise that either resolves on observable completion or\n   *  rejects with the handled error\n   * @deprecated Passing a Promise constructor will no longer be available\n   * in upcoming versions of RxJS. This is because it adds weight to the library, for very\n   * little benefit. If you need this functionality, it is recommended that you either\n   * polyfill Promise, or you create an adapter to convert the returned native promise\n   * to whatever promise implementation you wanted. Will be removed in v8.\n   */\n  forEach(next: (value: T) => void, promiseCtor: PromiseConstructorLike): Promise<void>;\n\n  forEach(next: (value: T) => void, promiseCtor?: PromiseConstructorLike): Promise<void> {\n    promiseCtor = getPromiseCtor(promiseCtor);\n\n    return new promiseCtor<void>((resolve, reject) => {\n      const subscriber = new SafeSubscriber<T>({\n        next: (value) => {\n          try {\n            next(value);\n          } catch (err) {\n            reject(err);\n            subscriber.unsubscribe();\n          }\n        },\n        error: reject,\n        complete: resolve,\n      });\n      this.subscribe(subscriber);\n    }) as Promise<void>;\n  }\n\n  /** @internal */\n  protected _subscribe(subscriber: Subscriber<any>): TeardownLogic {\n    return this.source?.subscribe(subscriber);\n  }\n\n  /**\n   * An interop point defined by the es7-observable spec https://github.com/zenparsing/es-observable\n   * @method Symbol.observable\n   * @return {Observable} this instance of the observable\n   */\n  [Symbol_observable]() {\n    return this;\n  }\n\n  /* tslint:disable:max-line-length */\n  pipe(): Observable<T>;\n  pipe<A>(op1: OperatorFunction<T, A>): Observable<A>;\n  pipe<A, B>(op1: OperatorFunction<T, A>, op2: OperatorFunction<A, B>): Observable<B>;\n  pipe<A, B, C>(op1: OperatorFunction<T, A>, op2: OperatorFunction<A, B>, op3: OperatorFunction<B, C>): Observable<C>;\n  pipe<A, B, C, D>(\n    op1: OperatorFunction<T, A>,\n    op2: OperatorFunction<A, B>,\n    op3: OperatorFunction<B, C>,\n    op4: OperatorFunction<C, D>\n  ): Observable<D>;\n  pipe<A, B, C, D, E>(\n    op1: OperatorFunction<T, A>,\n    op2: OperatorFunction<A, B>,\n    op3: OperatorFunction<B, C>,\n    op4: OperatorFunction<C, D>,\n    op5: OperatorFunction<D, E>\n  ): Observable<E>;\n  pipe<A, B, C, D, E, F>(\n    op1: OperatorFunction<T, A>,\n    op2: OperatorFunction<A, B>,\n    op3: OperatorFunction<B, C>,\n    op4: OperatorFunction<C, D>,\n    op5: OperatorFunction<D, E>,\n    op6: OperatorFunction<E, F>\n  ): Observable<F>;\n  pipe<A, B, C, D, E, F, G>(\n    op1: OperatorFunction<T, A>,\n    op2: OperatorFunction<A, B>,\n    op3: OperatorFunction<B, C>,\n    op4: OperatorFunction<C, D>,\n    op5: OperatorFunction<D, E>,\n    op6: OperatorFunction<E, F>,\n    op7: OperatorFunction<F, G>\n  ): Observable<G>;\n  pipe<A, B, C, D, E, F, G, H>(\n    op1: OperatorFunction<T, A>,\n    op2: OperatorFunction<A, B>,\n    op3: OperatorFunction<B, C>,\n    op4: OperatorFunction<C, D>,\n    op5: OperatorFunction<D, E>,\n    op6: OperatorFunction<E, F>,\n    op7: OperatorFunction<F, G>,\n    op8: OperatorFunction<G, H>\n  ): Observable<H>;\n  pipe<A, B, C, D, E, F, G, H, I>(\n    op1: OperatorFunction<T, A>,\n    op2: OperatorFunction<A, B>,\n    op3: OperatorFunction<B, C>,\n    op4: OperatorFunction<C, D>,\n    op5: OperatorFunction<D, E>,\n    op6: OperatorFunction<E, F>,\n    op7: OperatorFunction<F, G>,\n    op8: OperatorFunction<G, H>,\n    op9: OperatorFunction<H, I>\n  ): Observable<I>;\n  pipe<A, B, C, D, E, F, G, H, I>(\n    op1: OperatorFunction<T, A>,\n    op2: OperatorFunction<A, B>,\n    op3: OperatorFunction<B, C>,\n    op4: OperatorFunction<C, D>,\n    op5: OperatorFunction<D, E>,\n    op6: OperatorFunction<E, F>,\n    op7: OperatorFunction<F, G>,\n    op8: OperatorFunction<G, H>,\n    op9: OperatorFunction<H, I>,\n    ...operations: OperatorFunction<any, any>[]\n  ): Observable<unknown>;\n  /* tslint:enable:max-line-length */\n\n  /**\n   * Used to stitch together functional operators into a chain.\n   * @method pipe\n   * @return {Observable} the Observable result of all of the operators having\n   * been called in the order they were passed in.\n   *\n   * ## Example\n   *\n   * ```ts\n   * import { interval, filter, map, scan } from 'rxjs';\n   *\n   * interval(1000)\n   *   .pipe(\n   *     filter(x => x % 2 === 0),\n   *     map(x => x + x),\n   *     scan((acc, x) => acc + x)\n   *   )\n   *   .subscribe(x => console.log(x));\n   * ```\n   */\n  pipe(...operations: OperatorFunction<any, any>[]): Observable<any> {\n    return pipeFromArray(operations)(this);\n  }\n\n  /* tslint:disable:max-line-length */\n  /** @deprecated Replaced with {@link firstValueFrom} and {@link lastValueFrom}. Will be removed in v8. Details: https://rxjs.dev/deprecations/to-promise */\n  toPromise(): Promise<T | undefined>;\n  /** @deprecated Replaced with {@link firstValueFrom} and {@link lastValueFrom}. Will be removed in v8. Details: https://rxjs.dev/deprecations/to-promise */\n  toPromise(PromiseCtor: typeof Promise): Promise<T | undefined>;\n  /** @deprecated Replaced with {@link firstValueFrom} and {@link lastValueFrom}. Will be removed in v8. Details: https://rxjs.dev/deprecations/to-promise */\n  toPromise(PromiseCtor: PromiseConstructorLike): Promise<T | undefined>;\n  /* tslint:enable:max-line-length */\n\n  /**\n   * Subscribe to this Observable and get a Promise resolving on\n   * `complete` with the last emission (if any).\n   *\n   * **WARNING**: Only use this with observables you *know* will complete. If the source\n   * observable does not complete, you will end up with a promise that is hung up, and\n   * potentially all of the state of an async function hanging out in memory. To avoid\n   * this situation, look into adding something like {@link timeout}, {@link take},\n   * {@link takeWhile}, or {@link takeUntil} amongst others.\n   *\n   * @method toPromise\n   * @param [promiseCtor] a constructor function used to instantiate\n   * the Promise\n   * @return A Promise that resolves with the last value emit, or\n   * rejects on an error. If there were no emissions, Promise\n   * resolves with undefined.\n   * @deprecated Replaced with {@link firstValueFrom} and {@link lastValueFrom}. Will be removed in v8. Details: https://rxjs.dev/deprecations/to-promise\n   */\n  toPromise(promiseCtor?: PromiseConstructorLike): Promise<T | undefined> {\n    promiseCtor = getPromiseCtor(promiseCtor);\n\n    return new promiseCtor((resolve, reject) => {\n      let value: T | undefined;\n      this.subscribe(\n        (x: T) => (value = x),\n        (err: any) => reject(err),\n        () => resolve(value)\n      );\n    }) as Promise<T | undefined>;\n  }\n}\n\n/**\n * Decides between a passed promise constructor from consuming code,\n * A default configured promise constructor, and the native promise\n * constructor and returns it. If nothing can be found, it will throw\n * an error.\n * @param promiseCtor The optional promise constructor to passed by consuming code\n */\nfunction getPromiseCtor(promiseCtor: PromiseConstructorLike | undefined) {\n  return promiseCtor ?? config.Promise ?? Promise;\n}\n\nfunction isObserver<T>(value: any): value is Observer<T> {\n  return value && isFunction(value.next) && isFunction(value.error) && isFunction(value.complete);\n}\n\nfunction isSubscriber<T>(value: any): value is Subscriber<T> {\n  return (value && value instanceof Subscriber) || (isObserver(value) && isSubscription(value));\n}\n", "import { Observable } from '../Observable';\nimport { Subscriber } from '../Subscriber';\nimport { OperatorFunction } from '../types';\nimport { isFunction } from './isFunction';\n\n/**\n * Used to determine if an object is an Observable with a lift function.\n */\nexport function hasLift(source: any): source is { lift: InstanceType<typeof Observable>['lift'] } {\n  return isFunction(source?.lift);\n}\n\n/**\n * Creates an `OperatorFunction`. Used to define operators throughout the library in a concise way.\n * @param init The logic to connect the liftedSource to the subscriber at the moment of subscription.\n */\nexport function operate<T, R>(\n  init: (liftedSource: Observable<T>, subscriber: Subscriber<R>) => (() => void) | void\n): OperatorFunction<T, R> {\n  return (source: Observable<T>) => {\n    if (hasLift(source)) {\n      return source.lift(function (this: Subscriber<R>, liftedSource: Observable<T>) {\n        try {\n          return init(liftedSource, this);\n        } catch (err) {\n          this.error(err);\n        }\n      });\n    }\n    throw new TypeError('Unable to lift unknown Observable type');\n  };\n}\n", "import { Subscriber } from '../Subscriber';\n\n/**\n * Creates an instance of an `OperatorSubscriber`.\n * @param destination The downstream subscriber.\n * @param onNext Handles next values, only called if this subscriber is not stopped or closed. Any\n * error that occurs in this function is caught and sent to the `error` method of this subscriber.\n * @param onError Handles errors from the subscription, any errors that occur in this handler are caught\n * and send to the `destination` error handler.\n * @param onComplete Handles completion notification from the subscription. Any errors that occur in\n * this handler are sent to the `destination` error handler.\n * @param onFinalize Additional teardown logic here. This will only be called on teardown if the\n * subscriber itself is not already closed. This is called after all other teardown logic is executed.\n */\nexport function createOperatorSubscriber<T>(\n  destination: Subscriber<any>,\n  onNext?: (value: T) => void,\n  onComplete?: () => void,\n  onError?: (err: any) => void,\n  onFinalize?: () => void\n): Subscriber<T> {\n  return new OperatorSubscriber(destination, onNext, onComplete, onError, onFinalize);\n}\n\n/**\n * A generic helper for allowing operators to be created with a Subscriber and\n * use closures to capture necessary state from the operator function itself.\n */\nexport class OperatorSubscriber<T> extends Subscriber<T> {\n  /**\n   * Creates an instance of an `OperatorSubscriber`.\n   * @param destination The downstream subscriber.\n   * @param onNext Handles next values, only called if this subscriber is not stopped or closed. Any\n   * error that occurs in this function is caught and sent to the `error` method of this subscriber.\n   * @param onError Handles errors from the subscription, any errors that occur in this handler are caught\n   * and send to the `destination` error handler.\n   * @param onComplete Handles completion notification from the subscription. Any errors that occur in\n   * this handler are sent to the `destination` error handler.\n   * @param onFinalize Additional finalization logic here. This will only be called on finalization if the\n   * subscriber itself is not already closed. This is called after all other finalization logic is executed.\n   * @param shouldUnsubscribe An optional check to see if an unsubscribe call should truly unsubscribe.\n   * NOTE: This currently **ONLY** exists to support the strange behavior of {@link groupBy}, where unsubscription\n   * to the resulting observable does not actually disconnect from the source if there are active subscriptions\n   * to any grouped observable. (DO NOT EXPOSE OR USE EXTERNALLY!!!)\n   */\n  constructor(\n    destination: Subscriber<any>,\n    onNext?: (value: T) => void,\n    onComplete?: () => void,\n    onError?: (err: any) => void,\n    private onFinalize?: () => void,\n    private shouldUnsubscribe?: () => boolean\n  ) {\n    // It's important - for performance reasons - that all of this class's\n    // members are initialized and that they are always initialized in the same\n    // order. This will ensure that all OperatorSubscriber instances have the\n    // same hidden class in V8. This, in turn, will help keep the number of\n    // hidden classes involved in property accesses within the base class as\n    // low as possible. If the number of hidden classes involved exceeds four,\n    // the property accesses will become megamorphic and performance penalties\n    // will be incurred - i.e. inline caches won't be used.\n    //\n    // The reasons for ensuring all instances have the same hidden class are\n    // further discussed in this blog post from Benedikt Meurer:\n    // https://benediktmeurer.de/2018/03/23/impact-of-polymorphism-on-component-based-frameworks-like-react/\n    super(destination);\n    this._next = onNext\n      ? function (this: OperatorSubscriber<T>, value: T) {\n          try {\n            onNext(value);\n          } catch (err) {\n            destination.error(err);\n          }\n        }\n      : super._next;\n    this._error = onError\n      ? function (this: OperatorSubscriber<T>, err: any) {\n          try {\n            onError(err);\n          } catch (err) {\n            // Send any errors that occur down stream.\n            destination.error(err);\n          } finally {\n            // Ensure finalization.\n            this.unsubscribe();\n          }\n        }\n      : super._error;\n    this._complete = onComplete\n      ? function (this: OperatorSubscriber<T>) {\n          try {\n            onComplete();\n          } catch (err) {\n            // Send any errors that occur down stream.\n            destination.error(err);\n          } finally {\n            // Ensure finalization.\n            this.unsubscribe();\n          }\n        }\n      : super._complete;\n  }\n\n  unsubscribe() {\n    if (!this.shouldUnsubscribe || this.shouldUnsubscribe()) {\n      const { closed } = this;\n      super.unsubscribe();\n      // Execute additional teardown if we have any and we didn't already do so.\n      !closed && this.onFinalize?.();\n    }\n  }\n}\n", "import { Subscription } from '../Subscription';\n\ninterface AnimationFrameProvider {\n  schedule(callback: FrameRequestCallback): Subscription;\n  requestAnimationFrame: typeof requestAnimationFrame;\n  cancelAnimationFrame: typeof cancelAnimationFrame;\n  delegate:\n    | {\n        requestAnimationFrame: typeof requestAnimationFrame;\n        cancelAnimationFrame: typeof cancelAnimationFrame;\n      }\n    | undefined;\n}\n\nexport const animationFrameProvider: AnimationFrameProvider = {\n  // When accessing the delegate, use the variable rather than `this` so that\n  // the functions can be called without being bound to the provider.\n  schedule(callback) {\n    let request = requestAnimationFrame;\n    let cancel: typeof cancelAnimationFrame | undefined = cancelAnimationFrame;\n    const { delegate } = animationFrameProvider;\n    if (delegate) {\n      request = delegate.requestAnimationFrame;\n      cancel = delegate.cancelAnimationFrame;\n    }\n    const handle = request((timestamp) => {\n      // Clear the cancel function. The request has been fulfilled, so\n      // attempting to cancel the request upon unsubscription would be\n      // pointless.\n      cancel = undefined;\n      callback(timestamp);\n    });\n    return new Subscription(() => cancel?.(handle));\n  },\n  requestAnimationFrame(...args) {\n    const { delegate } = animationFrameProvider;\n    return (delegate?.requestAnimationFrame || requestAnimationFrame)(...args);\n  },\n  cancelAnimationFrame(...args) {\n    const { delegate } = animationFrameProvider;\n    return (delegate?.cancelAnimationFrame || cancelAnimationFrame)(...args);\n  },\n  delegate: undefined,\n};\n", "import { createErrorClass } from './createErrorClass';\n\nexport interface ObjectUnsubscribedError extends Error {}\n\nexport interface ObjectUnsubscribedErrorCtor {\n  /**\n   * @deprecated Internal implementation detail. Do not construct error instances.\n   * Cannot be tagged as internal: https://github.com/ReactiveX/rxjs/issues/6269\n   */\n  new (): ObjectUnsubscribedError;\n}\n\n/**\n * An error thrown when an action is invalid because the object has been\n * unsubscribed.\n *\n * @see {@link Subject}\n * @see {@link BehaviorSubject}\n *\n * @class ObjectUnsubscribedError\n */\nexport const ObjectUnsubscribedError: ObjectUnsubscribedErrorCtor = createErrorClass(\n  (_super) =>\n    function ObjectUnsubscribedErrorImpl(this: any) {\n      _super(this);\n      this.name = 'ObjectUnsubscribedError';\n      this.message = 'object unsubscribed';\n    }\n);\n", "import { Operator } from './Operator';\nimport { Observable } from './Observable';\nimport { Subscriber } from './Subscriber';\nimport { Subscription, EMPTY_SUBSCRIPTION } from './Subscription';\nimport { Observer, SubscriptionLike, TeardownLogic } from './types';\nimport { ObjectUnsubscribedError } from './util/ObjectUnsubscribedError';\nimport { arrRemove } from './util/arrRemove';\nimport { errorContext } from './util/errorContext';\n\n/**\n * A Subject is a special type of Observable that allows values to be\n * multicasted to many Observers. Subjects are like EventEmitters.\n *\n * Every Subject is an Observable and an Observer. You can subscribe to a\n * Subject, and you can call next to feed values as well as error and complete.\n */\nexport class Subject<T> extends Observable<T> implements SubscriptionLike {\n  closed = false;\n\n  private currentObservers: Observer<T>[] | null = null;\n\n  /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n  observers: Observer<T>[] = [];\n  /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n  isStopped = false;\n  /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n  hasError = false;\n  /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n  thrownError: any = null;\n\n  /**\n   * Creates a \"subject\" by basically gluing an observer to an observable.\n   *\n   * @nocollapse\n   * @deprecated Recommended you do not use. Will be removed at some point in the future. Plans for replacement still under discussion.\n   */\n  static create: (...args: any[]) => any = <T>(destination: Observer<T>, source: Observable<T>): AnonymousSubject<T> => {\n    return new AnonymousSubject<T>(destination, source);\n  };\n\n  constructor() {\n    // NOTE: This must be here to obscure Observable's constructor.\n    super();\n  }\n\n  /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n  lift<R>(operator: Operator<T, R>): Observable<R> {\n    const subject = new AnonymousSubject(this, this);\n    subject.operator = operator as any;\n    return subject as any;\n  }\n\n  /** @internal */\n  protected _throwIfClosed() {\n    if (this.closed) {\n      throw new ObjectUnsubscribedError();\n    }\n  }\n\n  next(value: T) {\n    errorContext(() => {\n      this._throwIfClosed();\n      if (!this.isStopped) {\n        if (!this.currentObservers) {\n          this.currentObservers = Array.from(this.observers);\n        }\n        for (const observer of this.currentObservers) {\n          observer.next(value);\n        }\n      }\n    });\n  }\n\n  error(err: any) {\n    errorContext(() => {\n      this._throwIfClosed();\n      if (!this.isStopped) {\n        this.hasError = this.isStopped = true;\n        this.thrownError = err;\n        const { observers } = this;\n        while (observers.length) {\n          observers.shift()!.error(err);\n        }\n      }\n    });\n  }\n\n  complete() {\n    errorContext(() => {\n      this._throwIfClosed();\n      if (!this.isStopped) {\n        this.isStopped = true;\n        const { observers } = this;\n        while (observers.length) {\n          observers.shift()!.complete();\n        }\n      }\n    });\n  }\n\n  unsubscribe() {\n    this.isStopped = this.closed = true;\n    this.observers = this.currentObservers = null!;\n  }\n\n  get observed() {\n    return this.observers?.length > 0;\n  }\n\n  /** @internal */\n  protected _trySubscribe(subscriber: Subscriber<T>): TeardownLogic {\n    this._throwIfClosed();\n    return super._trySubscribe(subscriber);\n  }\n\n  /** @internal */\n  protected _subscribe(subscriber: Subscriber<T>): Subscription {\n    this._throwIfClosed();\n    this._checkFinalizedStatuses(subscriber);\n    return this._innerSubscribe(subscriber);\n  }\n\n  /** @internal */\n  protected _innerSubscribe(subscriber: Subscriber<any>) {\n    const { hasError, isStopped, observers } = this;\n    if (hasError || isStopped) {\n      return EMPTY_SUBSCRIPTION;\n    }\n    this.currentObservers = null;\n    observers.push(subscriber);\n    return new Subscription(() => {\n      this.currentObservers = null;\n      arrRemove(observers, subscriber);\n    });\n  }\n\n  /** @internal */\n  protected _checkFinalizedStatuses(subscriber: Subscriber<any>) {\n    const { hasError, thrownError, isStopped } = this;\n    if (hasError) {\n      subscriber.error(thrownError);\n    } else if (isStopped) {\n      subscriber.complete();\n    }\n  }\n\n  /**\n   * Creates a new Observable with this Subject as the source. You can do this\n   * to create custom Observer-side logic of the Subject and conceal it from\n   * code that uses the Observable.\n   * @return {Observable} Observable that the Subject casts to\n   */\n  asObservable(): Observable<T> {\n    const observable: any = new Observable<T>();\n    observable.source = this;\n    return observable;\n  }\n}\n\n/**\n * @class AnonymousSubject<T>\n */\nexport class AnonymousSubject<T> extends Subject<T> {\n  constructor(\n    /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n    public destination?: Observer<T>,\n    source?: Observable<T>\n  ) {\n    super();\n    this.source = source;\n  }\n\n  next(value: T) {\n    this.destination?.next?.(value);\n  }\n\n  error(err: any) {\n    this.destination?.error?.(err);\n  }\n\n  complete() {\n    this.destination?.complete?.();\n  }\n\n  /** @internal */\n  protected _subscribe(subscriber: Subscriber<T>): Subscription {\n    return this.source?.subscribe(subscriber) ?? EMPTY_SUBSCRIPTION;\n  }\n}\n", "import { Subject } from './Subject';\nimport { Subscriber } from './Subscriber';\nimport { Subscription } from './Subscription';\n\n/**\n * A variant of Subject that requires an initial value and emits its current\n * value whenever it is subscribed to.\n *\n * @class BehaviorSubject<T>\n */\nexport class BehaviorSubject<T> extends Subject<T> {\n  constructor(private _value: T) {\n    super();\n  }\n\n  get value(): T {\n    return this.getValue();\n  }\n\n  /** @internal */\n  protected _subscribe(subscriber: Subscriber<T>): Subscription {\n    const subscription = super._subscribe(subscriber);\n    !subscription.closed && subscriber.next(this._value);\n    return subscription;\n  }\n\n  getValue(): T {\n    const { hasError, thrownError, _value } = this;\n    if (hasError) {\n      throw thrownError;\n    }\n    this._throwIfClosed();\n    return _value;\n  }\n\n  next(value: T): void {\n    super.next((this._value = value));\n  }\n}\n", "import { TimestampProvider } from '../types';\n\ninterface DateTimestampProvider extends TimestampProvider {\n  delegate: TimestampProvider | undefined;\n}\n\nexport const dateTimestampProvider: DateTimestampProvider = {\n  now() {\n    // Use the variable rather than `this` so that the function can be called\n    // without being bound to the provider.\n    return (dateTimestampProvider.delegate || Date).now();\n  },\n  delegate: undefined,\n};\n", "import { Subject } from './Subject';\nimport { TimestampProvider } from './types';\nimport { Subscriber } from './Subscriber';\nimport { Subscription } from './Subscription';\nimport { dateTimestampProvider } from './scheduler/dateTimestampProvider';\n\n/**\n * A variant of {@link Subject} that \"replays\" old values to new subscribers by emitting them when they first subscribe.\n *\n * `ReplaySubject` has an internal buffer that will store a specified number of values that it has observed. Like `Subject`,\n * `ReplaySubject` \"observes\" values by having them passed to its `next` method. When it observes a value, it will store that\n * value for a time determined by the configuration of the `ReplaySubject`, as passed to its constructor.\n *\n * When a new subscriber subscribes to the `ReplaySubject` instance, it will synchronously emit all values in its buffer in\n * a First-In-First-Out (FIFO) manner. The `ReplaySubject` will also complete, if it has observed completion; and it will\n * error if it has observed an error.\n *\n * There are two main configuration items to be concerned with:\n *\n * 1. `bufferSize` - This will determine how many items are stored in the buffer, defaults to infinite.\n * 2. `windowTime` - The amount of time to hold a value in the buffer before removing it from the buffer.\n *\n * Both configurations may exist simultaneously. So if you would like to buffer a maximum of 3 values, as long as the values\n * are less than 2 seconds old, you could do so with a `new ReplaySubject(3, 2000)`.\n *\n * ### Differences with BehaviorSubject\n *\n * `BehaviorSubject` is similar to `new ReplaySubject(1)`, with a couple of exceptions:\n *\n * 1. `BehaviorSubject` comes \"primed\" with a single value upon construction.\n * 2. `ReplaySubject` will replay values, even after observing an error, where `BehaviorSubject` will not.\n *\n * @see {@link Subject}\n * @see {@link BehaviorSubject}\n * @see {@link shareReplay}\n */\nexport class ReplaySubject<T> extends Subject<T> {\n  private _buffer: (T | number)[] = [];\n  private _infiniteTimeWindow = true;\n\n  /**\n   * @param bufferSize The size of the buffer to replay on subscription\n   * @param windowTime The amount of time the buffered items will stay buffered\n   * @param timestampProvider An object with a `now()` method that provides the current timestamp. This is used to\n   * calculate the amount of time something has been buffered.\n   */\n  constructor(\n    private _bufferSize = Infinity,\n    private _windowTime = Infinity,\n    private _timestampProvider: TimestampProvider = dateTimestampProvider\n  ) {\n    super();\n    this._infiniteTimeWindow = _windowTime === Infinity;\n    this._bufferSize = Math.max(1, _bufferSize);\n    this._windowTime = Math.max(1, _windowTime);\n  }\n\n  next(value: T): void {\n    const { isStopped, _buffer, _infiniteTimeWindow, _timestampProvider, _windowTime } = this;\n    if (!isStopped) {\n      _buffer.push(value);\n      !_infiniteTimeWindow && _buffer.push(_timestampProvider.now() + _windowTime);\n    }\n    this._trimBuffer();\n    super.next(value);\n  }\n\n  /** @internal */\n  protected _subscribe(subscriber: Subscriber<T>): Subscription {\n    this._throwIfClosed();\n    this._trimBuffer();\n\n    const subscription = this._innerSubscribe(subscriber);\n\n    const { _infiniteTimeWindow, _buffer } = this;\n    // We use a copy here, so reentrant code does not mutate our array while we're\n    // emitting it to a new subscriber.\n    const copy = _buffer.slice();\n    for (let i = 0; i < copy.length && !subscriber.closed; i += _infiniteTimeWindow ? 1 : 2) {\n      subscriber.next(copy[i] as T);\n    }\n\n    this._checkFinalizedStatuses(subscriber);\n\n    return subscription;\n  }\n\n  private _trimBuffer() {\n    const { _bufferSize, _timestampProvider, _buffer, _infiniteTimeWindow } = this;\n    // If we don't have an infinite buffer size, and we're over the length,\n    // use splice to truncate the old buffer values off. Note that we have to\n    // double the size for instances where we're not using an infinite time window\n    // because we're storing the values and the timestamps in the same array.\n    const adjustedBufferSize = (_infiniteTimeWindow ? 1 : 2) * _bufferSize;\n    _bufferSize < Infinity && adjustedBufferSize < _buffer.length && _buffer.splice(0, _buffer.length - adjustedBufferSize);\n\n    // Now, if we're not in an infinite time window, remove all values where the time is\n    // older than what is allowed.\n    if (!_infiniteTimeWindow) {\n      const now = _timestampProvider.now();\n      let last = 0;\n      // Search the array for the first timestamp that isn't expired and\n      // truncate the buffer up to that point.\n      for (let i = 1; i < _buffer.length && (_buffer[i] as number) <= now; i += 2) {\n        last = i;\n      }\n      last && _buffer.splice(0, last + 1);\n    }\n  }\n}\n", "import { Scheduler } from '../Scheduler';\nimport { Subscription } from '../Subscription';\nimport { SchedulerAction } from '../types';\n\n/**\n * A unit of work to be executed in a `scheduler`. An action is typically\n * created from within a {@link SchedulerLike} and an RxJS user does not need to concern\n * themselves about creating and manipulating an Action.\n *\n * ```ts\n * class Action<T> extends Subscription {\n *   new (scheduler: Scheduler, work: (state?: T) => void);\n *   schedule(state?: T, delay: number = 0): Subscription;\n * }\n * ```\n *\n * @class Action<T>\n */\nexport class Action<T> extends Subscription {\n  constructor(scheduler: Scheduler, work: (this: SchedulerAction<T>, state?: T) => void) {\n    super();\n  }\n  /**\n   * Schedules this action on its parent {@link SchedulerLike} for execution. May be passed\n   * some context object, `state`. May happen at some point in the future,\n   * according to the `delay` parameter, if specified.\n   * @param {T} [state] Some contextual data that the `work` function uses when\n   * called by the Scheduler.\n   * @param {number} [delay] Time to wait before executing the work, where the\n   * time unit is implicit and defined by the Scheduler.\n   * @return {void}\n   */\n  public schedule(state?: T, delay: number = 0): Subscription {\n    return this;\n  }\n}\n", "import type { TimerHandle } from './timerHandle';\ntype SetIntervalFunction = (handler: () => void, timeout?: number, ...args: any[]) => TimerHandle;\ntype ClearIntervalFunction = (handle: TimerHandle) => void;\n\ninterface IntervalProvider {\n  setInterval: SetIntervalFunction;\n  clearInterval: ClearIntervalFunction;\n  delegate:\n    | {\n        setInterval: SetIntervalFunction;\n        clearInterval: ClearIntervalFunction;\n      }\n    | undefined;\n}\n\nexport const intervalProvider: IntervalProvider = {\n  // When accessing the delegate, use the variable rather than `this` so that\n  // the functions can be called without being bound to the provider.\n  setInterval(handler: () => void, timeout?: number, ...args) {\n    const { delegate } = intervalProvider;\n    if (delegate?.setInterval) {\n      return delegate.setInterval(handler, timeout, ...args);\n    }\n    return setInterval(handler, timeout, ...args);\n  },\n  clearInterval(handle) {\n    const { delegate } = intervalProvider;\n    return (delegate?.clearInterval || clearInterval)(handle as any);\n  },\n  delegate: undefined,\n};\n", "import { Action } from './Action';\nimport { SchedulerAction } from '../types';\nimport { Subscription } from '../Subscription';\nimport { AsyncScheduler } from './AsyncScheduler';\nimport { intervalProvider } from './intervalProvider';\nimport { arrRemove } from '../util/arrRemove';\nimport { TimerHandle } from './timerHandle';\n\nexport class AsyncAction<T> extends Action<T> {\n  public id: TimerHandle | undefined;\n  public state?: T;\n  // @ts-ignore: Property has no initializer and is not definitely assigned\n  public delay: number;\n  protected pending: boolean = false;\n\n  constructor(protected scheduler: AsyncScheduler, protected work: (this: SchedulerAction<T>, state?: T) => void) {\n    super(scheduler, work);\n  }\n\n  public schedule(state?: T, delay: number = 0): Subscription {\n    if (this.closed) {\n      return this;\n    }\n\n    // Always replace the current state with the new state.\n    this.state = state;\n\n    const id = this.id;\n    const scheduler = this.scheduler;\n\n    //\n    // Important implementation note:\n    //\n    // Actions only execute once by default, unless rescheduled from within the\n    // scheduled callback. This allows us to implement single and repeat\n    // actions via the same code path, without adding API surface area, as well\n    // as mimic traditional recursion but across asynchronous boundaries.\n    //\n    // However, JS runtimes and timers distinguish between intervals achieved by\n    // serial `setTimeout` calls vs. a single `setInterval` call. An interval of\n    // serial `setTimeout` calls can be individually delayed, which delays\n    // scheduling the next `setTimeout`, and so on. `setInterval` attempts to\n    // guarantee the interval callback will be invoked more precisely to the\n    // interval period, regardless of load.\n    //\n    // Therefore, we use `setInterval` to schedule single and repeat actions.\n    // If the action reschedules itself with the same delay, the interval is not\n    // canceled. If the action doesn't reschedule, or reschedules with a\n    // different delay, the interval will be canceled after scheduled callback\n    // execution.\n    //\n    if (id != null) {\n      this.id = this.recycleAsyncId(scheduler, id, delay);\n    }\n\n    // Set the pending flag indicating that this action has been scheduled, or\n    // has recursively rescheduled itself.\n    this.pending = true;\n\n    this.delay = delay;\n    // If this action has already an async Id, don't request a new one.\n    this.id = this.id ?? this.requestAsyncId(scheduler, this.id, delay);\n\n    return this;\n  }\n\n  protected requestAsyncId(scheduler: AsyncScheduler, _id?: TimerHandle, delay: number = 0): TimerHandle {\n    return intervalProvider.setInterval(scheduler.flush.bind(scheduler, this), delay);\n  }\n\n  protected recycleAsyncId(_scheduler: AsyncScheduler, id?: TimerHandle, delay: number | null = 0): TimerHandle | undefined {\n    // If this action is rescheduled with the same delay time, don't clear the interval id.\n    if (delay != null && this.delay === delay && this.pending === false) {\n      return id;\n    }\n    // Otherwise, if the action's delay time is different from the current delay,\n    // or the action has been rescheduled before it's executed, clear the interval id\n    if (id != null) {\n      intervalProvider.clearInterval(id);\n    }\n\n    return undefined;\n  }\n\n  /**\n   * Immediately executes this action and the `work` it contains.\n   * @return {any}\n   */\n  public execute(state: T, delay: number): any {\n    if (this.closed) {\n      return new Error('executing a cancelled action');\n    }\n\n    this.pending = false;\n    const error = this._execute(state, delay);\n    if (error) {\n      return error;\n    } else if (this.pending === false && this.id != null) {\n      // Dequeue if the action didn't reschedule itself. Don't call\n      // unsubscribe(), because the action could reschedule later.\n      // For example:\n      // ```\n      // scheduler.schedule(function doWork(counter) {\n      //   /* ... I'm a busy worker bee ... */\n      //   var originalAction = this;\n      //   /* wait 100ms before rescheduling the action */\n      //   setTimeout(function () {\n      //     originalAction.schedule(counter + 1);\n      //   }, 100);\n      // }, 1000);\n      // ```\n      this.id = this.recycleAsyncId(this.scheduler, this.id, null);\n    }\n  }\n\n  protected _execute(state: T, _delay: number): any {\n    let errored: boolean = false;\n    let errorValue: any;\n    try {\n      this.work(state);\n    } catch (e) {\n      errored = true;\n      // HACK: Since code elsewhere is relying on the \"truthiness\" of the\n      // return here, we can't have it return \"\" or 0 or false.\n      // TODO: Clean this up when we refactor schedulers mid-version-8 or so.\n      errorValue = e ? e : new Error('Scheduled action threw falsy error');\n    }\n    if (errored) {\n      this.unsubscribe();\n      return errorValue;\n    }\n  }\n\n  unsubscribe() {\n    if (!this.closed) {\n      const { id, scheduler } = this;\n      const { actions } = scheduler;\n\n      this.work = this.state = this.scheduler = null!;\n      this.pending = false;\n\n      arrRemove(actions, this);\n      if (id != null) {\n        this.id = this.recycleAsyncId(scheduler, id, null);\n      }\n\n      this.delay = null!;\n      super.unsubscribe();\n    }\n  }\n}\n", "import { Action } from './scheduler/Action';\nimport { Subscription } from './Subscription';\nimport { SchedulerLike, SchedulerAction } from './types';\nimport { dateTimestampProvider } from './scheduler/dateTimestampProvider';\n\n/**\n * An execution context and a data structure to order tasks and schedule their\n * execution. Provides a notion of (potentially virtual) time, through the\n * `now()` getter method.\n *\n * Each unit of work in a Scheduler is called an `Action`.\n *\n * ```ts\n * class Scheduler {\n *   now(): number;\n *   schedule(work, delay?, state?): Subscription;\n * }\n * ```\n *\n * @class Scheduler\n * @deprecated Scheduler is an internal implementation detail of RxJS, and\n * should not be used directly. Rather, create your own class and implement\n * {@link SchedulerLike}. Will be made internal in v8.\n */\nexport class Scheduler implements SchedulerLike {\n  public static now: () => number = dateTimestampProvider.now;\n\n  constructor(private schedulerActionCtor: typeof Action, now: () => number = Scheduler.now) {\n    this.now = now;\n  }\n\n  /**\n   * A getter method that returns a number representing the current time\n   * (at the time this function was called) according to the scheduler's own\n   * internal clock.\n   * @return {number} A number that represents the current time. May or may not\n   * have a relation to wall-clock time. May or may not refer to a time unit\n   * (e.g. milliseconds).\n   */\n  public now: () => number;\n\n  /**\n   * Schedules a function, `work`, for execution. May happen at some point in\n   * the future, according to the `delay` parameter, if specified. May be passed\n   * some context object, `state`, which will be passed to the `work` function.\n   *\n   * The given arguments will be processed an stored as an Action object in a\n   * queue of actions.\n   *\n   * @param {function(state: ?T): ?Subscription} work A function representing a\n   * task, or some unit of work to be executed by the Scheduler.\n   * @param {number} [delay] Time to wait before executing the work, where the\n   * time unit is implicit and defined by the Scheduler itself.\n   * @param {T} [state] Some contextual data that the `work` function uses when\n   * called by the Scheduler.\n   * @return {Subscription} A subscription in order to be able to unsubscribe\n   * the scheduled work.\n   */\n  public schedule<T>(work: (this: SchedulerAction<T>, state?: T) => void, delay: number = 0, state?: T): Subscription {\n    return new this.schedulerActionCtor<T>(this, work).schedule(state, delay);\n  }\n}\n", "import { Scheduler } from '../Scheduler';\nimport { Action } from './Action';\nimport { AsyncAction } from './AsyncAction';\nimport { TimerHandle } from './timerHandle';\n\nexport class AsyncScheduler extends Scheduler {\n  public actions: Array<AsyncAction<any>> = [];\n  /**\n   * A flag to indicate whether the Scheduler is currently executing a batch of\n   * queued actions.\n   * @type {boolean}\n   * @internal\n   */\n  public _active: boolean = false;\n  /**\n   * An internal ID used to track the latest asynchronous task such as those\n   * coming from `setTimeout`, `setInterval`, `requestAnimationFrame`, and\n   * others.\n   * @type {any}\n   * @internal\n   */\n  public _scheduled: TimerHandle | undefined;\n\n  constructor(SchedulerAction: typeof Action, now: () => number = Scheduler.now) {\n    super(SchedulerAction, now);\n  }\n\n  public flush(action: AsyncAction<any>): void {\n    const { actions } = this;\n\n    if (this._active) {\n      actions.push(action);\n      return;\n    }\n\n    let error: any;\n    this._active = true;\n\n    do {\n      if ((error = action.execute(action.state, action.delay))) {\n        break;\n      }\n    } while ((action = actions.shift()!)); // exhaust the scheduler queue\n\n    this._active = false;\n\n    if (error) {\n      while ((action = actions.shift()!)) {\n        action.unsubscribe();\n      }\n      throw error;\n    }\n  }\n}\n", "import { AsyncAction } from './AsyncAction';\nimport { AsyncScheduler } from './AsyncScheduler';\n\n/**\n *\n * Async Scheduler\n *\n * <span class=\"informal\">Schedule task as if you used setTimeout(task, duration)</span>\n *\n * `async` scheduler schedules tasks asynchronously, by putting them on the JavaScript\n * event loop queue. It is best used to delay tasks in time or to schedule tasks repeating\n * in intervals.\n *\n * If you just want to \"defer\" task, that is to perform it right after currently\n * executing synchronous code ends (commonly achieved by `setTimeout(deferredTask, 0)`),\n * better choice will be the {@link asapScheduler} scheduler.\n *\n * ## Examples\n * Use async scheduler to delay task\n * ```ts\n * import { asyncScheduler } from 'rxjs';\n *\n * const task = () => console.log('it works!');\n *\n * asyncScheduler.schedule(task, 2000);\n *\n * // After 2 seconds logs:\n * // \"it works!\"\n * ```\n *\n * Use async scheduler to repeat task in intervals\n * ```ts\n * import { asyncScheduler } from 'rxjs';\n *\n * function task(state) {\n *   console.log(state);\n *   this.schedule(state + 1, 1000); // `this` references currently executing Action,\n *                                   // which we reschedule with new state and delay\n * }\n *\n * asyncScheduler.schedule(task, 3000, 0);\n *\n * // Logs:\n * // 0 after 3s\n * // 1 after 4s\n * // 2 after 5s\n * // 3 after 6s\n * ```\n */\n\nexport const asyncScheduler = new AsyncScheduler(AsyncAction);\n\n/**\n * @deprecated Renamed to {@link asyncScheduler}. Will be removed in v8.\n */\nexport const async = asyncScheduler;\n", "import { AsyncAction } from './AsyncAction';\nimport { Subscription } from '../Subscription';\nimport { QueueScheduler } from './QueueScheduler';\nimport { SchedulerAction } from '../types';\nimport { TimerHandle } from './timerHandle';\n\nexport class QueueAction<T> extends AsyncAction<T> {\n  constructor(protected scheduler: QueueScheduler, protected work: (this: SchedulerAction<T>, state?: T) => void) {\n    super(scheduler, work);\n  }\n\n  public schedule(state?: T, delay: number = 0): Subscription {\n    if (delay > 0) {\n      return super.schedule(state, delay);\n    }\n    this.delay = delay;\n    this.state = state;\n    this.scheduler.flush(this);\n    return this;\n  }\n\n  public execute(state: T, delay: number): any {\n    return delay > 0 || this.closed ? super.execute(state, delay) : this._execute(state, delay);\n  }\n\n  protected requestAsyncId(scheduler: QueueScheduler, id?: TimerHandle, delay: number = 0): TimerHandle {\n    // If delay exists and is greater than 0, or if the delay is null (the\n    // action wasn't rescheduled) but was originally scheduled as an async\n    // action, then recycle as an async action.\n\n    if ((delay != null && delay > 0) || (delay == null && this.delay > 0)) {\n      return super.requestAsyncId(scheduler, id, delay);\n    }\n\n    // Otherwise flush the scheduler starting with this action.\n    scheduler.flush(this);\n\n    // HACK: In the past, this was returning `void`. However, `void` isn't a valid\n    // `TimerHandle`, and generally the return value here isn't really used. So the\n    // compromise is to return `0` which is both \"falsy\" and a valid `TimerHandle`,\n    // as opposed to refactoring every other instanceo of `requestAsyncId`.\n    return 0;\n  }\n}\n", "import { AsyncScheduler } from './AsyncScheduler';\n\nexport class QueueScheduler extends AsyncScheduler {\n}\n", "import { QueueAction } from './QueueAction';\nimport { QueueScheduler } from './QueueScheduler';\n\n/**\n *\n * Queue Scheduler\n *\n * <span class=\"informal\">Put every next task on a queue, instead of executing it immediately</span>\n *\n * `queue` scheduler, when used with delay, behaves the same as {@link asyncScheduler} scheduler.\n *\n * When used without delay, it schedules given task synchronously - executes it right when\n * it is scheduled. However when called recursively, that is when inside the scheduled task,\n * another task is scheduled with queue scheduler, instead of executing immediately as well,\n * that task will be put on a queue and wait for current one to finish.\n *\n * This means that when you execute task with `queue` scheduler, you are sure it will end\n * before any other task scheduled with that scheduler will start.\n *\n * ## Examples\n * Schedule recursively first, then do something\n * ```ts\n * import { queueScheduler } from 'rxjs';\n *\n * queueScheduler.schedule(() => {\n *   queueScheduler.schedule(() => console.log('second')); // will not happen now, but will be put on a queue\n *\n *   console.log('first');\n * });\n *\n * // Logs:\n * // \"first\"\n * // \"second\"\n * ```\n *\n * Reschedule itself recursively\n * ```ts\n * import { queueScheduler } from 'rxjs';\n *\n * queueScheduler.schedule(function(state) {\n *   if (state !== 0) {\n *     console.log('before', state);\n *     this.schedule(state - 1); // `this` references currently executing Action,\n *                               // which we reschedule with new state\n *     console.log('after', state);\n *   }\n * }, 0, 3);\n *\n * // In scheduler that runs recursively, you would expect:\n * // \"before\", 3\n * // \"before\", 2\n * // \"before\", 1\n * // \"after\", 1\n * // \"after\", 2\n * // \"after\", 3\n *\n * // But with queue it logs:\n * // \"before\", 3\n * // \"after\", 3\n * // \"before\", 2\n * // \"after\", 2\n * // \"before\", 1\n * // \"after\", 1\n * ```\n */\n\nexport const queueScheduler = new QueueScheduler(QueueAction);\n\n/**\n * @deprecated Renamed to {@link queueScheduler}. Will be removed in v8.\n */\nexport const queue = queueScheduler;\n", "import { AsyncAction } from './AsyncAction';\nimport { AnimationFrameScheduler } from './AnimationFrameScheduler';\nimport { SchedulerAction } from '../types';\nimport { animationFrameProvider } from './animationFrameProvider';\nimport { TimerHandle } from './timerHandle';\n\nexport class AnimationFrameAction<T> extends AsyncAction<T> {\n  constructor(protected scheduler: AnimationFrameScheduler, protected work: (this: SchedulerAction<T>, state?: T) => void) {\n    super(scheduler, work);\n  }\n\n  protected requestAsyncId(scheduler: AnimationFrameScheduler, id?: TimerHandle, delay: number = 0): TimerHandle {\n    // If delay is greater than 0, request as an async action.\n    if (delay !== null && delay > 0) {\n      return super.requestAsyncId(scheduler, id, delay);\n    }\n    // Push the action to the end of the scheduler queue.\n    scheduler.actions.push(this);\n    // If an animation frame has already been requested, don't request another\n    // one. If an animation frame hasn't been requested yet, request one. Return\n    // the current animation frame request id.\n    return scheduler._scheduled || (scheduler._scheduled = animationFrameProvider.requestAnimationFrame(() => scheduler.flush(undefined)));\n  }\n\n  protected recycleAsyncId(scheduler: AnimationFrameScheduler, id?: TimerHandle, delay: number = 0): TimerHandle | undefined {\n    // If delay exists and is greater than 0, or if the delay is null (the\n    // action wasn't rescheduled) but was originally scheduled as an async\n    // action, then recycle as an async action.\n    if (delay != null ? delay > 0 : this.delay > 0) {\n      return super.recycleAsyncId(scheduler, id, delay);\n    }\n    // If the scheduler queue has no remaining actions with the same async id,\n    // cancel the requested animation frame and set the scheduled flag to\n    // undefined so the next AnimationFrameAction will request its own.\n    const { actions } = scheduler;\n    if (id != null && actions[actions.length - 1]?.id !== id) {\n      animationFrameProvider.cancelAnimationFrame(id as number);\n      scheduler._scheduled = undefined;\n    }\n    // Return undefined so the action knows to request a new async id if it's rescheduled.\n    return undefined;\n  }\n}\n", "import { AsyncAction } from './AsyncAction';\nimport { AsyncScheduler } from './AsyncScheduler';\n\nexport class AnimationFrameScheduler extends AsyncScheduler {\n  public flush(action?: AsyncAction<any>): void {\n    this._active = true;\n    // The async id that effects a call to flush is stored in _scheduled.\n    // Before executing an action, it's necessary to check the action's async\n    // id to determine whether it's supposed to be executed in the current\n    // flush.\n    // Previous implementations of this method used a count to determine this,\n    // but that was unsound, as actions that are unsubscribed - i.e. cancelled -\n    // are removed from the actions array and that can shift actions that are\n    // scheduled to be executed in a subsequent flush into positions at which\n    // they are executed within the current flush.\n    const flushId = this._scheduled;\n    this._scheduled = undefined;\n\n    const { actions } = this;\n    let error: any;\n    action = action || actions.shift()!;\n\n    do {\n      if ((error = action.execute(action.state, action.delay))) {\n        break;\n      }\n    } while ((action = actions[0]) && action.id === flushId && actions.shift());\n\n    this._active = false;\n\n    if (error) {\n      while ((action = actions[0]) && action.id === flushId && actions.shift()) {\n        action.unsubscribe();\n      }\n      throw error;\n    }\n  }\n}\n", "import { AnimationFrameAction } from './AnimationFrameAction';\nimport { AnimationFrameScheduler } from './AnimationFrameScheduler';\n\n/**\n *\n * Animation Frame Scheduler\n *\n * <span class=\"informal\">Perform task when `window.requestAnimationFrame` would fire</span>\n *\n * When `animationFrame` scheduler is used with delay, it will fall back to {@link asyncScheduler} scheduler\n * behaviour.\n *\n * Without delay, `animationFrame` scheduler can be used to create smooth browser animations.\n * It makes sure scheduled task will happen just before next browser content repaint,\n * thus performing animations as efficiently as possible.\n *\n * ## Example\n * Schedule div height animation\n * ```ts\n * // html: <div style=\"background: #0ff;\"></div>\n * import { animationFrameScheduler } from 'rxjs';\n *\n * const div = document.querySelector('div');\n *\n * animationFrameScheduler.schedule(function(height) {\n *   div.style.height = height + \"px\";\n *\n *   this.schedule(height + 1);  // `this` references currently executing Action,\n *                               // which we reschedule with new state\n * }, 0, 0);\n *\n * // You will see a div element growing in height\n * ```\n */\n\nexport const animationFrameScheduler = new AnimationFrameScheduler(AnimationFrameAction);\n\n/**\n * @deprecated Renamed to {@link animationFrameScheduler}. Will be removed in v8.\n */\nexport const animationFrame = animationFrameScheduler;\n", "import { Observable } from '../Observable';\nimport { SchedulerLike } from '../types';\n\n/**\n * A simple Observable that emits no items to the Observer and immediately\n * emits a complete notification.\n *\n * <span class=\"informal\">Just emits 'complete', and nothing else.</span>\n *\n * ![](empty.png)\n *\n * A simple Observable that only emits the complete notification. It can be used\n * for composing with other Observables, such as in a {@link mergeMap}.\n *\n * ## Examples\n *\n * Log complete notification\n *\n * ```ts\n * import { EMPTY } from 'rxjs';\n *\n * EMPTY.subscribe({\n *   next: () => console.log('Next'),\n *   complete: () => console.log('Complete!')\n * });\n *\n * // Outputs\n * // Complete!\n * ```\n *\n * Emit the number 7, then complete\n *\n * ```ts\n * import { EMPTY, startWith } from 'rxjs';\n *\n * const result = EMPTY.pipe(startWith(7));\n * result.subscribe(x => console.log(x));\n *\n * // Outputs\n * // 7\n * ```\n *\n * Map and flatten only odd numbers to the sequence `'a'`, `'b'`, `'c'`\n *\n * ```ts\n * import { interval, mergeMap, of, EMPTY } from 'rxjs';\n *\n * const interval$ = interval(1000);\n * const result = interval$.pipe(\n *   mergeMap(x => x % 2 === 1 ? of('a', 'b', 'c') : EMPTY),\n * );\n * result.subscribe(x => console.log(x));\n *\n * // Results in the following to the console:\n * // x is equal to the count on the interval, e.g. (0, 1, 2, 3, ...)\n * // x will occur every 1000ms\n * // if x % 2 is equal to 1, print a, b, c (each on its own)\n * // if x % 2 is not equal to 1, nothing will be output\n * ```\n *\n * @see {@link Observable}\n * @see {@link NEVER}\n * @see {@link of}\n * @see {@link throwError}\n */\nexport const EMPTY = new Observable<never>((subscriber) => subscriber.complete());\n\n/**\n * @param scheduler A {@link SchedulerLike} to use for scheduling\n * the emission of the complete notification.\n * @deprecated Replaced with the {@link EMPTY} constant or {@link scheduled} (e.g. `scheduled([], scheduler)`). Will be removed in v8.\n */\nexport function empty(scheduler?: SchedulerLike) {\n  return scheduler ? emptyScheduled(scheduler) : EMPTY;\n}\n\nfunction emptyScheduled(scheduler: SchedulerLike) {\n  return new Observable<never>((subscriber) => scheduler.schedule(() => subscriber.complete()));\n}\n", "import { SchedulerLike } from '../types';\nimport { isFunction } from './isFunction';\n\nexport function isScheduler(value: any): value is SchedulerLike {\n  return value && isFunction(value.schedule);\n}\n", "import { SchedulerLike } from '../types';\nimport { isFunction } from './isFunction';\nimport { isScheduler } from './isScheduler';\n\nfunction last<T>(arr: T[]): T | undefined {\n  return arr[arr.length - 1];\n}\n\nexport function popResultSelector(args: any[]): ((...args: unknown[]) => unknown) | undefined {\n  return isFunction(last(args)) ? args.pop() : undefined;\n}\n\nexport function popScheduler(args: any[]): SchedulerLike | undefined {\n  return isScheduler(last(args)) ? args.pop() : undefined;\n}\n\nexport function popNumber(args: any[], defaultValue: number): number {\n  return typeof last(args) === 'number' ? args.pop()! : defaultValue;\n}\n", "export const isArrayLike = (<T>(x: any): x is ArrayLike<T> => x && typeof x.length === 'number' && typeof x !== 'function');", "import { isFunction } from \"./isFunction\";\n\n/**\n * Tests to see if the object is \"thennable\".\n * @param value the object to test\n */\nexport function isPromise(value: any): value is PromiseLike<any> {\n  return isFunction(value?.then);\n}\n", "import { InteropObservable } from '../types';\nimport { observable as Symbol_observable } from '../symbol/observable';\nimport { isFunction } from './isFunction';\n\n/** Identifies an input as being Observable (but not necessary an Rx Observable) */\nexport function isInteropObservable(input: any): input is InteropObservable<any> {\n  return isFunction(input[Symbol_observable]);\n}\n", "import { isFunction } from './isFunction';\n\nexport function isAsyncIterable<T>(obj: any): obj is AsyncIterable<T> {\n  return Symbol.asyncIterator && isFunction(obj?.[Symbol.asyncIterator]);\n}\n", "/**\n * Creates the TypeError to throw if an invalid object is passed to `from` or `scheduled`.\n * @param input The object that was passed.\n */\nexport function createInvalidObservableTypeError(input: any) {\n  // TODO: We should create error codes that can be looked up, so this can be less verbose.\n  return new TypeError(\n    `You provided ${\n      input !== null && typeof input === 'object' ? 'an invalid object' : `'${input}'`\n    } where a stream was expected. You can provide an Observable, Promise, ReadableStream, Array, AsyncIterable, or Iterable.`\n  );\n}\n", "export function getSymbolIterator(): symbol {\n  if (typeof Symbol !== 'function' || !Symbol.iterator) {\n    return '@@iterator' as any;\n  }\n\n  return Symbol.iterator;\n}\n\nexport const iterator = getSymbolIterator();\n", "import { iterator as Symbol_iterator } from '../symbol/iterator';\nimport { isFunction } from './isFunction';\n\n/** Identifies an input as being an Iterable */\nexport function isIterable(input: any): input is Iterable<any> {\n  return isFunction(input?.[Symbol_iterator]);\n}\n", "import { ReadableStreamLike } from '../types';\nimport { isFunction } from './isFunction';\n\nexport async function* readableStreamLikeToAsyncGenerator<T>(readableStream: ReadableStreamLike<T>): AsyncGenerator<T> {\n  const reader = readableStream.getReader();\n  try {\n    while (true) {\n      const { value, done } = await reader.read();\n      if (done) {\n        return;\n      }\n      yield value!;\n    }\n  } finally {\n    reader.releaseLock();\n  }\n}\n\nexport function isReadableStreamLike<T>(obj: any): obj is ReadableStreamLike<T> {\n  // We don't want to use instanceof checks because they would return\n  // false for instances from another Realm, like an <iframe>.\n  return isFunction(obj?.getReader);\n}\n", "import { isArrayLike } from '../util/isArrayLike';\nimport { isPromise } from '../util/isPromise';\nimport { Observable } from '../Observable';\nimport { ObservableInput, ObservedValueOf, ReadableStreamLike } from '../types';\nimport { isInteropObservable } from '../util/isInteropObservable';\nimport { isAsyncIterable } from '../util/isAsyncIterable';\nimport { createInvalidObservableTypeError } from '../util/throwUnobservableError';\nimport { isIterable } from '../util/isIterable';\nimport { isReadableStreamLike, readableStreamLikeToAsyncGenerator } from '../util/isReadableStreamLike';\nimport { Subscriber } from '../Subscriber';\nimport { isFunction } from '../util/isFunction';\nimport { reportUnhandledError } from '../util/reportUnhandledError';\nimport { observable as Symbol_observable } from '../symbol/observable';\n\nexport function innerFrom<O extends ObservableInput<any>>(input: O): Observable<ObservedValueOf<O>>;\nexport function innerFrom<T>(input: ObservableInput<T>): Observable<T> {\n  if (input instanceof Observable) {\n    return input;\n  }\n  if (input != null) {\n    if (isInteropObservable(input)) {\n      return fromInteropObservable(input);\n    }\n    if (isArrayLike(input)) {\n      return fromArrayLike(input);\n    }\n    if (isPromise(input)) {\n      return fromPromise(input);\n    }\n    if (isAsyncIterable(input)) {\n      return fromAsyncIterable(input);\n    }\n    if (isIterable(input)) {\n      return fromIterable(input);\n    }\n    if (isReadableStreamLike(input)) {\n      return fromReadableStreamLike(input);\n    }\n  }\n\n  throw createInvalidObservableTypeError(input);\n}\n\n/**\n * Creates an RxJS Observable from an object that implements `Symbol.observable`.\n * @param obj An object that properly implements `Symbol.observable`.\n */\nexport function fromInteropObservable<T>(obj: any) {\n  return new Observable((subscriber: Subscriber<T>) => {\n    const obs = obj[Symbol_observable]();\n    if (isFunction(obs.subscribe)) {\n      return obs.subscribe(subscriber);\n    }\n    // Should be caught by observable subscribe function error handling.\n    throw new TypeError('Provided object does not correctly implement Symbol.observable');\n  });\n}\n\n/**\n * Synchronously emits the values of an array like and completes.\n * This is exported because there are creation functions and operators that need to\n * make direct use of the same logic, and there's no reason to make them run through\n * `from` conditionals because we *know* they're dealing with an array.\n * @param array The array to emit values from\n */\nexport function fromArrayLike<T>(array: ArrayLike<T>) {\n  return new Observable((subscriber: Subscriber<T>) => {\n    // Loop over the array and emit each value. Note two things here:\n    // 1. We're making sure that the subscriber is not closed on each loop.\n    //    This is so we don't continue looping over a very large array after\n    //    something like a `take`, `takeWhile`, or other synchronous unsubscription\n    //    has already unsubscribed.\n    // 2. In this form, reentrant code can alter that array we're looping over.\n    //    This is a known issue, but considered an edge case. The alternative would\n    //    be to copy the array before executing the loop, but this has\n    //    performance implications.\n    for (let i = 0; i < array.length && !subscriber.closed; i++) {\n      subscriber.next(array[i]);\n    }\n    subscriber.complete();\n  });\n}\n\nexport function fromPromise<T>(promise: PromiseLike<T>) {\n  return new Observable((subscriber: Subscriber<T>) => {\n    promise\n      .then(\n        (value) => {\n          if (!subscriber.closed) {\n            subscriber.next(value);\n            subscriber.complete();\n          }\n        },\n        (err: any) => subscriber.error(err)\n      )\n      .then(null, reportUnhandledError);\n  });\n}\n\nexport function fromIterable<T>(iterable: Iterable<T>) {\n  return new Observable((subscriber: Subscriber<T>) => {\n    for (const value of iterable) {\n      subscriber.next(value);\n      if (subscriber.closed) {\n        return;\n      }\n    }\n    subscriber.complete();\n  });\n}\n\nexport function fromAsyncIterable<T>(asyncIterable: AsyncIterable<T>) {\n  return new Observable((subscriber: Subscriber<T>) => {\n    process(asyncIterable, subscriber).catch((err) => subscriber.error(err));\n  });\n}\n\nexport function fromReadableStreamLike<T>(readableStream: ReadableStreamLike<T>) {\n  return fromAsyncIterable(readableStreamLikeToAsyncGenerator(readableStream));\n}\n\nasync function process<T>(asyncIterable: AsyncIterable<T>, subscriber: Subscriber<T>) {\n  for await (const value of asyncIterable) {\n    subscriber.next(value);\n    // A side-effect may have closed our subscriber,\n    // check before the next iteration.\n    if (subscriber.closed) {\n      return;\n    }\n  }\n  subscriber.complete();\n}\n", "import { Subscription } from '../Subscription';\nimport { SchedulerAction, SchedulerLike } from '../types';\n\nexport function executeSchedule(\n  parentSubscription: Subscription,\n  scheduler: SchedulerLike,\n  work: () => void,\n  delay: number,\n  repeat: true\n): void;\nexport function executeSchedule(\n  parentSubscription: Subscription,\n  scheduler: SchedulerLike,\n  work: () => void,\n  delay?: number,\n  repeat?: false\n): Subscription;\n\nexport function executeSchedule(\n  parentSubscription: Subscription,\n  scheduler: SchedulerLike,\n  work: () => void,\n  delay = 0,\n  repeat = false\n): Subscription | void {\n  const scheduleSubscription = scheduler.schedule(function (this: SchedulerAction<any>) {\n    work();\n    if (repeat) {\n      parentSubscription.add(this.schedule(null, delay));\n    } else {\n      this.unsubscribe();\n    }\n  }, delay);\n\n  parentSubscription.add(scheduleSubscription);\n\n  if (!repeat) {\n    // Because user-land scheduler implementations are unlikely to properly reuse\n    // Actions for repeat scheduling, we can't trust that the returned subscription\n    // will control repeat subscription scenarios. So we're trying to avoid using them\n    // incorrectly within this library.\n    return scheduleSubscription;\n  }\n}\n", "/** @prettier */\nimport { MonoTypeOperatorFunction, SchedulerLike } from '../types';\nimport { executeSchedule } from '../util/executeSchedule';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * Re-emits all notifications from source Observable with specified scheduler.\n *\n * <span class=\"informal\">Ensure a specific scheduler is used, from outside of an Observable.</span>\n *\n * `observeOn` is an operator that accepts a scheduler as a first parameter, which will be used to reschedule\n * notifications emitted by the source Observable. It might be useful, if you do not have control over\n * internal scheduler of a given Observable, but want to control when its values are emitted nevertheless.\n *\n * Returned Observable emits the same notifications (nexted values, complete and error events) as the source Observable,\n * but rescheduled with provided scheduler. Note that this doesn't mean that source Observables internal\n * scheduler will be replaced in any way. Original scheduler still will be used, but when the source Observable emits\n * notification, it will be immediately scheduled again - this time with scheduler passed to `observeOn`.\n * An anti-pattern would be calling `observeOn` on Observable that emits lots of values synchronously, to split\n * that emissions into asynchronous chunks. For this to happen, scheduler would have to be passed into the source\n * Observable directly (usually into the operator that creates it). `observeOn` simply delays notifications a\n * little bit more, to ensure that they are emitted at expected moments.\n *\n * As a matter of fact, `observeOn` accepts second parameter, which specifies in milliseconds with what delay notifications\n * will be emitted. The main difference between {@link delay} operator and `observeOn` is that `observeOn`\n * will delay all notifications - including error notifications - while `delay` will pass through error\n * from source Observable immediately when it is emitted. In general it is highly recommended to use `delay` operator\n * for any kind of delaying of values in the stream, while using `observeOn` to specify which scheduler should be used\n * for notification emissions in general.\n *\n * ## Example\n *\n * Ensure values in subscribe are called just before browser repaint\n *\n * ```ts\n * import { interval, observeOn, animationFrameScheduler } from 'rxjs';\n *\n * const someDiv = document.createElement('div');\n * someDiv.style.cssText = 'width: 200px;background: #09c';\n * document.body.appendChild(someDiv);\n * const intervals = interval(10);      // Intervals are scheduled\n *                                      // with async scheduler by default...\n * intervals.pipe(\n *   observeOn(animationFrameScheduler) // ...but we will observe on animationFrame\n * )                                    // scheduler to ensure smooth animation.\n * .subscribe(val => {\n *   someDiv.style.height = val + 'px';\n * });\n * ```\n *\n * @see {@link delay}\n *\n * @param scheduler Scheduler that will be used to reschedule notifications from source Observable.\n * @param delay Number of milliseconds that states with what delay every notification should be rescheduled.\n * @return A function that returns an Observable that emits the same\n * notifications as the source Observable, but with provided scheduler.\n */\nexport function observeOn<T>(scheduler: SchedulerLike, delay = 0): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value) => executeSchedule(subscriber, scheduler, () => subscriber.next(value), delay),\n        () => executeSchedule(subscriber, scheduler, () => subscriber.complete(), delay),\n        (err) => executeSchedule(subscriber, scheduler, () => subscriber.error(err), delay)\n      )\n    );\n  });\n}\n", "import { MonoTypeOperatorFunction, SchedulerLike } from '../types';\nimport { operate } from '../util/lift';\n\n/**\n * Asynchronously subscribes Observers to this Observable on the specified {@link SchedulerLike}.\n *\n * With `subscribeOn` you can decide what type of scheduler a specific Observable will be using when it is subscribed to.\n *\n * Schedulers control the speed and order of emissions to observers from an Observable stream.\n *\n * ![](subscribeOn.png)\n *\n * ## Example\n *\n * Given the following code:\n *\n * ```ts\n * import { of, merge } from 'rxjs';\n *\n * const a = of(1, 2, 3);\n * const b = of(4, 5, 6);\n *\n * merge(a, b).subscribe(console.log);\n *\n * // Outputs\n * // 1\n * // 2\n * // 3\n * // 4\n * // 5\n * // 6\n * ```\n *\n * Both Observable `a` and `b` will emit their values directly and synchronously once they are subscribed to.\n *\n * If we instead use the `subscribeOn` operator declaring that we want to use the {@link asyncScheduler} for values emitted by Observable `a`:\n *\n * ```ts\n * import { of, subscribeOn, asyncScheduler, merge } from 'rxjs';\n *\n * const a = of(1, 2, 3).pipe(subscribeOn(asyncScheduler));\n * const b = of(4, 5, 6);\n *\n * merge(a, b).subscribe(console.log);\n *\n * // Outputs\n * // 4\n * // 5\n * // 6\n * // 1\n * // 2\n * // 3\n * ```\n *\n * The reason for this is that Observable `b` emits its values directly and synchronously like before\n * but the emissions from `a` are scheduled on the event loop because we are now using the {@link asyncScheduler} for that specific Observable.\n *\n * @param scheduler The {@link SchedulerLike} to perform subscription actions on.\n * @param delay A delay to pass to the scheduler to delay subscriptions\n * @return A function that returns an Observable modified so that its\n * subscriptions happen on the specified {@link SchedulerLike}.\n */\nexport function subscribeOn<T>(scheduler: SchedulerLike, delay: number = 0): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    subscriber.add(scheduler.schedule(() => source.subscribe(subscriber), delay));\n  });\n}\n", "import { innerFrom } from '../observable/innerFrom';\nimport { observeOn } from '../operators/observeOn';\nimport { subscribeOn } from '../operators/subscribeOn';\nimport { InteropObservable, SchedulerLike } from '../types';\n\nexport function scheduleObservable<T>(input: InteropObservable<T>, scheduler: SchedulerLike) {\n  return innerFrom(input).pipe(subscribeOn(scheduler), observeOn(scheduler));\n}\n", "import { innerFrom } from '../observable/innerFrom';\nimport { observeOn } from '../operators/observeOn';\nimport { subscribeOn } from '../operators/subscribeOn';\nimport { SchedulerLike } from '../types';\n\nexport function schedulePromise<T>(input: PromiseLike<T>, scheduler: SchedulerLike) {\n  return innerFrom(input).pipe(subscribeOn(scheduler), observeOn(scheduler));\n}\n", "import { Observable } from '../Observable';\nimport { SchedulerLike } from '../types';\n\nexport function scheduleArray<T>(input: ArrayLike<T>, scheduler: SchedulerLike) {\n  return new Observable<T>((subscriber) => {\n    // The current array index.\n    let i = 0;\n    // Start iterating over the array like on a schedule.\n    return scheduler.schedule(function () {\n      if (i === input.length) {\n        // If we have hit the end of the array like in the\n        // previous job, we can complete.\n        subscriber.complete();\n      } else {\n        // Otherwise let's next the value at the current index,\n        // then increment our index.\n        subscriber.next(input[i++]);\n        // If the last emission didn't cause us to close the subscriber\n        // (via take or some side effect), reschedule the job and we'll\n        // make another pass.\n        if (!subscriber.closed) {\n          this.schedule();\n        }\n      }\n    });\n  });\n}\n", "import { Observable } from '../Observable';\nimport { SchedulerLike } from '../types';\nimport { iterator as Symbol_iterator } from '../symbol/iterator';\nimport { isFunction } from '../util/isFunction';\nimport { executeSchedule } from '../util/executeSchedule';\n\n/**\n * Used in {@link scheduled} to create an observable from an Iterable.\n * @param input The iterable to create an observable from\n * @param scheduler The scheduler to use\n */\nexport function scheduleIterable<T>(input: Iterable<T>, scheduler: SchedulerLike) {\n  return new Observable<T>((subscriber) => {\n    let iterator: Iterator<T, T>;\n\n    // Schedule the initial creation of the iterator from\n    // the iterable. This is so the code in the iterable is\n    // not called until the scheduled job fires.\n    executeSchedule(subscriber, scheduler, () => {\n      // Create the iterator.\n      iterator = (input as any)[Symbol_iterator]();\n\n      executeSchedule(\n        subscriber,\n        scheduler,\n        () => {\n          let value: T;\n          let done: boolean | undefined;\n          try {\n            // Pull the value out of the iterator\n            ({ value, done } = iterator.next());\n          } catch (err) {\n            // We got an error while pulling from the iterator\n            subscriber.error(err);\n            return;\n          }\n\n          if (done) {\n            // If it is \"done\" we just complete. This mimics the\n            // behavior of JavaScript's `for..of` consumption of\n            // iterables, which will not emit the value from an iterator\n            // result of `{ done: true: value: 'here' }`.\n            subscriber.complete();\n          } else {\n            // The iterable is not done, emit the value.\n            subscriber.next(value);\n          }\n        },\n        0,\n        true\n      );\n    });\n\n    // During finalization, if we see this iterator has a `return` method,\n    // then we know it is a Generator, and not just an Iterator. So we call\n    // the `return()` function. This will ensure that any `finally { }` blocks\n    // inside of the generator we can hit will be hit properly.\n    return () => isFunction(iterator?.return) && iterator.return();\n  });\n}\n", "import { SchedulerLike } from '../types';\nimport { Observable } from '../Observable';\nimport { executeSchedule } from '../util/executeSchedule';\n\nexport function scheduleAsyncIterable<T>(input: AsyncIterable<T>, scheduler: SchedulerLike) {\n  if (!input) {\n    throw new Error('Iterable cannot be null');\n  }\n  return new Observable<T>((subscriber) => {\n    executeSchedule(subscriber, scheduler, () => {\n      const iterator = input[Symbol.asyncIterator]();\n      executeSchedule(\n        subscriber,\n        scheduler,\n        () => {\n          iterator.next().then((result) => {\n            if (result.done) {\n              // This will remove the subscriptions from\n              // the parent subscription.\n              subscriber.complete();\n            } else {\n              subscriber.next(result.value);\n            }\n          });\n        },\n        0,\n        true\n      );\n    });\n  });\n}\n", "import { SchedulerLike, ReadableStreamLike } from '../types';\nimport { Observable } from '../Observable';\nimport { scheduleAsyncIterable } from './scheduleAsyncIterable';\nimport { readableStreamLikeToAsyncGenerator } from '../util/isReadableStreamLike';\n\nexport function scheduleReadableStreamLike<T>(input: ReadableStreamLike<T>, scheduler: SchedulerLike): Observable<T> {\n  return scheduleAsyncIterable(readableStreamLikeToAsyncGenerator(input), scheduler);\n}\n", "import { scheduleObservable } from './scheduleObservable';\nimport { schedulePromise } from './schedulePromise';\nimport { scheduleArray } from './scheduleArray';\nimport { scheduleIterable } from './scheduleIterable';\nimport { scheduleAsyncIterable } from './scheduleAsyncIterable';\nimport { isInteropObservable } from '../util/isInteropObservable';\nimport { isPromise } from '../util/isPromise';\nimport { isArrayLike } from '../util/isArrayLike';\nimport { isIterable } from '../util/isIterable';\nimport { ObservableInput, SchedulerLike } from '../types';\nimport { Observable } from '../Observable';\nimport { isAsyncIterable } from '../util/isAsyncIterable';\nimport { createInvalidObservableTypeError } from '../util/throwUnobservableError';\nimport { isReadableStreamLike } from '../util/isReadableStreamLike';\nimport { scheduleReadableStreamLike } from './scheduleReadableStreamLike';\n\n/**\n * Converts from a common {@link ObservableInput} type to an observable where subscription and emissions\n * are scheduled on the provided scheduler.\n *\n * @see {@link from}\n * @see {@link of}\n *\n * @param input The observable, array, promise, iterable, etc you would like to schedule\n * @param scheduler The scheduler to use to schedule the subscription and emissions from\n * the returned observable.\n */\nexport function scheduled<T>(input: ObservableInput<T>, scheduler: SchedulerLike): Observable<T> {\n  if (input != null) {\n    if (isInteropObservable(input)) {\n      return scheduleObservable(input, scheduler);\n    }\n    if (isArrayLike(input)) {\n      return scheduleArray(input, scheduler);\n    }\n    if (isPromise(input)) {\n      return schedulePromise(input, scheduler);\n    }\n    if (isAsyncIterable(input)) {\n      return scheduleAsyncIterable(input, scheduler);\n    }\n    if (isIterable(input)) {\n      return scheduleIterable(input, scheduler);\n    }\n    if (isReadableStreamLike(input)) {\n      return scheduleReadableStreamLike(input, scheduler);\n    }\n  }\n  throw createInvalidObservableTypeError(input);\n}\n", "import { Observable } from '../Observable';\nimport { ObservableInput, SchedulerLike, ObservedValueOf } from '../types';\nimport { scheduled } from '../scheduled/scheduled';\nimport { innerFrom } from './innerFrom';\n\nexport function from<O extends ObservableInput<any>>(input: O): Observable<ObservedValueOf<O>>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function from<O extends ObservableInput<any>>(input: O, scheduler: SchedulerLike | undefined): Observable<ObservedValueOf<O>>;\n\n/**\n * Creates an Observable from an Array, an array-like object, a Promise, an iterable object, or an Observable-like object.\n *\n * <span class=\"informal\">Converts almost anything to an Observable.</span>\n *\n * ![](from.png)\n *\n * `from` converts various other objects and data types into Observables. It also converts a Promise, an array-like, or an\n * <a href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols#iterable\" target=\"_blank\">iterable</a>\n * object into an Observable that emits the items in that promise, array, or iterable. A String, in this context, is treated\n * as an array of characters. Observable-like objects (contains a function named with the ES2015 Symbol for Observable) can also be\n * converted through this operator.\n *\n * ## Examples\n *\n * Converts an array to an Observable\n *\n * ```ts\n * import { from } from 'rxjs';\n *\n * const array = [10, 20, 30];\n * const result = from(array);\n *\n * result.subscribe(x => console.log(x));\n *\n * // Logs:\n * // 10\n * // 20\n * // 30\n * ```\n *\n * Convert an infinite iterable (from a generator) to an Observable\n *\n * ```ts\n * import { from, take } from 'rxjs';\n *\n * function* generateDoubles(seed) {\n *    let i = seed;\n *    while (true) {\n *      yield i;\n *      i = 2 * i; // double it\n *    }\n * }\n *\n * const iterator = generateDoubles(3);\n * const result = from(iterator).pipe(take(10));\n *\n * result.subscribe(x => console.log(x));\n *\n * // Logs:\n * // 3\n * // 6\n * // 12\n * // 24\n * // 48\n * // 96\n * // 192\n * // 384\n * // 768\n * // 1536\n * ```\n *\n * With `asyncScheduler`\n *\n * ```ts\n * import { from, asyncScheduler } from 'rxjs';\n *\n * console.log('start');\n *\n * const array = [10, 20, 30];\n * const result = from(array, asyncScheduler);\n *\n * result.subscribe(x => console.log(x));\n *\n * console.log('end');\n *\n * // Logs:\n * // 'start'\n * // 'end'\n * // 10\n * // 20\n * // 30\n * ```\n *\n * @see {@link fromEvent}\n * @see {@link fromEventPattern}\n *\n * @param {ObservableInput<T>} A subscription object, a Promise, an Observable-like,\n * an Array, an iterable, or an array-like object to be converted.\n * @param {SchedulerLike} An optional {@link SchedulerLike} on which to schedule the emission of values.\n * @return {Observable<T>}\n */\nexport function from<T>(input: ObservableInput<T>, scheduler?: SchedulerLike): Observable<T> {\n  return scheduler ? scheduled(input, scheduler) : innerFrom(input);\n}\n", "import { SchedulerLike, ValueFromArray } from '../types';\nimport { Observable } from '../Observable';\nimport { popScheduler } from '../util/args';\nimport { from } from './from';\n\n// Devs are more likely to pass null or undefined than they are a scheduler\n// without accompanying values. To make things easier for (naughty) devs who\n// use the `strictNullChecks: false` TypeScript compiler option, these\n// overloads with explicit null and undefined values are included.\n\nexport function of(value: null): Observable<null>;\nexport function of(value: undefined): Observable<undefined>;\n\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function of(scheduler: SchedulerLike): Observable<never>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function of<A extends readonly unknown[]>(...valuesAndScheduler: [...A, SchedulerLike]): Observable<ValueFromArray<A>>;\n\nexport function of(): Observable<never>;\n/** @deprecated Do not specify explicit type parameters. Signatures with type parameters that cannot be inferred will be removed in v8. */\nexport function of<T>(): Observable<T>;\nexport function of<T>(value: T): Observable<T>;\nexport function of<A extends readonly unknown[]>(...values: A): Observable<ValueFromArray<A>>;\n\n/**\n * Converts the arguments to an observable sequence.\n *\n * <span class=\"informal\">Each argument becomes a `next` notification.</span>\n *\n * ![](of.png)\n *\n * Unlike {@link from}, it does not do any flattening and emits each argument in whole\n * as a separate `next` notification.\n *\n * ## Examples\n *\n * Emit the values `10, 20, 30`\n *\n * ```ts\n * import { of } from 'rxjs';\n *\n * of(10, 20, 30)\n *   .subscribe({\n *     next: value => console.log('next:', value),\n *     error: err => console.log('error:', err),\n *     complete: () => console.log('the end'),\n *   });\n *\n * // Outputs\n * // next: 10\n * // next: 20\n * // next: 30\n * // the end\n * ```\n *\n * Emit the array `[1, 2, 3]`\n *\n * ```ts\n * import { of } from 'rxjs';\n *\n * of([1, 2, 3])\n *   .subscribe({\n *     next: value => console.log('next:', value),\n *     error: err => console.log('error:', err),\n *     complete: () => console.log('the end'),\n *   });\n *\n * // Outputs\n * // next: [1, 2, 3]\n * // the end\n * ```\n *\n * @see {@link from}\n * @see {@link range}\n *\n * @param {...T} values A comma separated list of arguments you want to be emitted\n * @return {Observable} An Observable that emits the arguments\n * described above and then completes.\n */\nexport function of<T>(...args: Array<T | SchedulerLike>): Observable<T> {\n  const scheduler = popScheduler(args);\n  return from(args as T[], scheduler);\n}\n", "import { Observable } from '../Observable';\nimport { Subscriber } from '../Subscriber';\nimport { SchedulerLike } from '../types';\nimport { isFunction } from '../util/isFunction';\n\n/**\n * Creates an observable that will create an error instance and push it to the consumer as an error\n * immediately upon subscription.\n *\n * <span class=\"informal\">Just errors and does nothing else</span>\n *\n * ![](throw.png)\n *\n * This creation function is useful for creating an observable that will create an error and error every\n * time it is subscribed to. Generally, inside of most operators when you might want to return an errored\n * observable, this is unnecessary. In most cases, such as in the inner return of {@link concatMap},\n * {@link mergeMap}, {@link defer}, and many others, you can simply throw the error, and RxJS will pick\n * that up and notify the consumer of the error.\n *\n * ## Example\n *\n * Create a simple observable that will create a new error with a timestamp and log it\n * and the message every time you subscribe to it\n *\n * ```ts\n * import { throwError } from 'rxjs';\n *\n * let errorCount = 0;\n *\n * const errorWithTimestamp$ = throwError(() => {\n *   const error: any = new Error(`This is error number ${ ++errorCount }`);\n *   error.timestamp = Date.now();\n *   return error;\n * });\n *\n * errorWithTimestamp$.subscribe({\n *   error: err => console.log(err.timestamp, err.message)\n * });\n *\n * errorWithTimestamp$.subscribe({\n *   error: err => console.log(err.timestamp, err.message)\n * });\n *\n * // Logs the timestamp and a new error message for each subscription\n * ```\n *\n * ### Unnecessary usage\n *\n * Using `throwError` inside of an operator or creation function\n * with a callback, is usually not necessary\n *\n * ```ts\n * import { of, concatMap, timer, throwError } from 'rxjs';\n *\n * const delays$ = of(1000, 2000, Infinity, 3000);\n *\n * delays$.pipe(\n *   concatMap(ms => {\n *     if (ms < 10000) {\n *       return timer(ms);\n *     } else {\n *       // This is probably overkill.\n *       return throwError(() => new Error(`Invalid time ${ ms }`));\n *     }\n *   })\n * )\n * .subscribe({\n *   next: console.log,\n *   error: console.error\n * });\n * ```\n *\n * You can just throw the error instead\n *\n * ```ts\n * import { of, concatMap, timer } from 'rxjs';\n *\n * const delays$ = of(1000, 2000, Infinity, 3000);\n *\n * delays$.pipe(\n *   concatMap(ms => {\n *     if (ms < 10000) {\n *       return timer(ms);\n *     } else {\n *       // Cleaner and easier to read for most folks.\n *       throw new Error(`Invalid time ${ ms }`);\n *     }\n *   })\n * )\n * .subscribe({\n *   next: console.log,\n *   error: console.error\n * });\n * ```\n *\n * @param errorFactory A factory function that will create the error instance that is pushed.\n */\nexport function throwError(errorFactory: () => any): Observable<never>;\n\n/**\n * Returns an observable that will error with the specified error immediately upon subscription.\n *\n * @param error The error instance to emit\n * @deprecated Support for passing an error value will be removed in v8. Instead, pass a factory function to `throwError(() => new Error('test'))`. This is\n * because it will create the error at the moment it should be created and capture a more appropriate stack trace. If\n * for some reason you need to create the error ahead of time, you can still do that: `const err = new Error('test'); throwError(() => err);`.\n */\nexport function throwError(error: any): Observable<never>;\n\n/**\n * Notifies the consumer of an error using a given scheduler by scheduling it at delay `0` upon subscription.\n *\n * @param errorOrErrorFactory An error instance or error factory\n * @param scheduler A scheduler to use to schedule the error notification\n * @deprecated The `scheduler` parameter will be removed in v8.\n * Use `throwError` in combination with {@link observeOn}: `throwError(() => new Error('test')).pipe(observeOn(scheduler));`.\n * Details: https://rxjs.dev/deprecations/scheduler-argument\n */\nexport function throwError(errorOrErrorFactory: any, scheduler: SchedulerLike): Observable<never>;\n\nexport function throwError(errorOrErrorFactory: any, scheduler?: SchedulerLike): Observable<never> {\n  const errorFactory = isFunction(errorOrErrorFactory) ? errorOrErrorFactory : () => errorOrErrorFactory;\n  const init = (subscriber: Subscriber<never>) => subscriber.error(errorFactory());\n  return new Observable(scheduler ? (subscriber) => scheduler.schedule(init as any, 0, subscriber) : init);\n}\n", "import { createErrorClass } from './createErrorClass';\n\nexport interface EmptyError extends Error {}\n\nexport interface EmptyErrorCtor {\n  /**\n   * @deprecated Internal implementation detail. Do not construct error instances.\n   * Cannot be tagged as internal: https://github.com/ReactiveX/rxjs/issues/6269\n   */\n  new (): EmptyError;\n}\n\n/**\n * An error thrown when an Observable or a sequence was queried but has no\n * elements.\n *\n * @see {@link first}\n * @see {@link last}\n * @see {@link single}\n * @see {@link firstValueFrom}\n * @see {@link lastValueFrom}\n *\n * @class EmptyError\n */\nexport const EmptyError: EmptyErrorCtor = createErrorClass((_super) => function EmptyErrorImpl(this: any) {\n  _super(this);\n  this.name = 'EmptyError';\n  this.message = 'no elements in sequence';\n});\n", "/**\n * Checks to see if a value is not only a `Date` object,\n * but a *valid* `Date` object that can be converted to a\n * number. For example, `new Date('blah')` is indeed an\n * `instanceof Date`, however it cannot be converted to a\n * number.\n */\nexport function isValidDate(value: any): value is Date {\n  return value instanceof Date && !isNaN(value as any);\n}\n", "import { OperatorFunction } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\nexport function map<T, R>(project: (value: T, index: number) => R): OperatorFunction<T, R>;\n/** @deprecated Use a closure instead of a `thisArg`. Signatures accepting a `thisArg` will be removed in v8. */\nexport function map<T, R, A>(project: (this: A, value: T, index: number) => R, thisArg: A): OperatorFunction<T, R>;\n\n/**\n * Applies a given `project` function to each value emitted by the source\n * Observable, and emits the resulting values as an Observable.\n *\n * <span class=\"informal\">Like [Array.prototype.map()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map),\n * it passes each source value through a transformation function to get\n * corresponding output values.</span>\n *\n * ![](map.png)\n *\n * Similar to the well known `Array.prototype.map` function, this operator\n * applies a projection to each value and emits that projection in the output\n * Observable.\n *\n * ## Example\n *\n * Map every click to the `clientX` position of that click\n *\n * ```ts\n * import { fromEvent, map } from 'rxjs';\n *\n * const clicks = fromEvent<PointerEvent>(document, 'click');\n * const positions = clicks.pipe(map(ev => ev.clientX));\n *\n * positions.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link mapTo}\n * @see {@link pluck}\n *\n * @param {function(value: T, index: number): R} project The function to apply\n * to each `value` emitted by the source Observable. The `index` parameter is\n * the number `i` for the i-th emission that has happened since the\n * subscription, starting from the number `0`.\n * @param {any} [thisArg] An optional argument to define what `this` is in the\n * `project` function.\n * @return A function that returns an Observable that emits the values from the\n * source Observable transformed by the given `project` function.\n */\nexport function map<T, R>(project: (value: T, index: number) => R, thisArg?: any): OperatorFunction<T, R> {\n  return operate((source, subscriber) => {\n    // The index of the value from the source. Used with projection.\n    let index = 0;\n    // Subscribe to the source, all errors and completions are sent along\n    // to the consumer.\n    source.subscribe(\n      createOperatorSubscriber(subscriber, (value: T) => {\n        // Call the projection function with the appropriate this context,\n        // and send the resulting value to the consumer.\n        subscriber.next(project.call(thisArg, value, index++));\n      })\n    );\n  });\n}\n", "import { OperatorFunction } from \"../types\";\nimport { map } from \"../operators/map\";\n\nconst { isArray } = Array;\n\nfunction callOrApply<T, R>(fn: ((...values: T[]) => R), args: T|T[]): R {\n    return isArray(args) ? fn(...args) : fn(args);\n}\n\n/**\n * Used in several -- mostly deprecated -- situations where we need to \n * apply a list of arguments or a single argument to a result selector.\n */\nexport function mapOneOrManyArgs<T, R>(fn: ((...values: T[]) => R)): OperatorFunction<T|T[], R> {\n    return map(args => callOrApply(fn, args))\n}", "const { isArray } = Array;\nconst { getPrototypeOf, prototype: objectProto, keys: getKeys } = Object;\n\n/**\n * Used in functions where either a list of arguments, a single array of arguments, or a\n * dictionary of arguments can be returned. Returns an object with an `args` property with\n * the arguments in an array, if it is a dictionary, it will also return the `keys` in another\n * property.\n */\nexport function argsArgArrayOrObject<T, O extends Record<string, T>>(args: T[] | [O] | [T[]]): { args: T[]; keys: string[] | null } {\n  if (args.length === 1) {\n    const first = args[0];\n    if (isArray(first)) {\n      return { args: first, keys: null };\n    }\n    if (isPOJO(first)) {\n      const keys = getKeys(first);\n      return {\n        args: keys.map((key) => first[key]),\n        keys,\n      };\n    }\n  }\n\n  return { args: args as T[], keys: null };\n}\n\nfunction isPOJO(obj: any): obj is object {\n  return obj && typeof obj === 'object' && getPrototypeOf(obj) === objectProto;\n}\n", "export function createObject(keys: string[], values: any[]) {\n  return keys.reduce((result, key, i) => ((result[key] = values[i]), result), {} as any);\n}\n", "import { Observable } from '../Observable';\nimport { ObservableInput, SchedulerLike, ObservedValueOf, ObservableInputTuple } from '../types';\nimport { argsArgArrayOrObject } from '../util/argsArgArrayOrObject';\nimport { Subscriber } from '../Subscriber';\nimport { from } from './from';\nimport { identity } from '../util/identity';\nimport { Subscription } from '../Subscription';\nimport { mapOneOrManyArgs } from '../util/mapOneOrManyArgs';\nimport { popResultSelector, popScheduler } from '../util/args';\nimport { createObject } from '../util/createObject';\nimport { createOperatorSubscriber } from '../operators/OperatorSubscriber';\nimport { AnyCatcher } from '../AnyCatcher';\nimport { executeSchedule } from '../util/executeSchedule';\n\n// combineLatest(any)\n// We put this first because we need to catch cases where the user has supplied\n// _exactly `any`_ as the argument. Since `any` literally matches _anything_,\n// we don't want it to randomly hit one of the other type signatures below,\n// as we have no idea at build-time what type we should be returning when given an any.\n\n/**\n * You have passed `any` here, we can't figure out if it is\n * an array or an object, so you're getting `unknown`. Use better types.\n * @param arg Something typed as `any`\n */\nexport function combineLatest<T extends AnyCatcher>(arg: T): Observable<unknown>;\n\n// combineLatest([a, b, c])\nexport function combineLatest(sources: []): Observable<never>;\nexport function combineLatest<A extends readonly unknown[]>(sources: readonly [...ObservableInputTuple<A>]): Observable<A>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `combineLatestAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function combineLatest<A extends readonly unknown[], R>(\n  sources: readonly [...ObservableInputTuple<A>],\n  resultSelector: (...values: A) => R,\n  scheduler: SchedulerLike\n): Observable<R>;\nexport function combineLatest<A extends readonly unknown[], R>(\n  sources: readonly [...ObservableInputTuple<A>],\n  resultSelector: (...values: A) => R\n): Observable<R>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `combineLatestAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function combineLatest<A extends readonly unknown[]>(\n  sources: readonly [...ObservableInputTuple<A>],\n  scheduler: SchedulerLike\n): Observable<A>;\n\n// combineLatest(a, b, c)\n/** @deprecated Pass an array of sources instead. The rest-parameters signature will be removed in v8. Details: https://rxjs.dev/deprecations/array-argument */\nexport function combineLatest<A extends readonly unknown[]>(...sources: [...ObservableInputTuple<A>]): Observable<A>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `combineLatestAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function combineLatest<A extends readonly unknown[], R>(\n  ...sourcesAndResultSelectorAndScheduler: [...ObservableInputTuple<A>, (...values: A) => R, SchedulerLike]\n): Observable<R>;\n/** @deprecated Pass an array of sources instead. The rest-parameters signature will be removed in v8. Details: https://rxjs.dev/deprecations/array-argument */\nexport function combineLatest<A extends readonly unknown[], R>(\n  ...sourcesAndResultSelector: [...ObservableInputTuple<A>, (...values: A) => R]\n): Observable<R>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `combineLatestAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function combineLatest<A extends readonly unknown[]>(\n  ...sourcesAndScheduler: [...ObservableInputTuple<A>, SchedulerLike]\n): Observable<A>;\n\n// combineLatest({a, b, c})\nexport function combineLatest(sourcesObject: { [K in any]: never }): Observable<never>;\nexport function combineLatest<T extends Record<string, ObservableInput<any>>>(\n  sourcesObject: T\n): Observable<{ [K in keyof T]: ObservedValueOf<T[K]> }>;\n\n/**\n * Combines multiple Observables to create an Observable whose values are\n * calculated from the latest values of each of its input Observables.\n *\n * <span class=\"informal\">Whenever any input Observable emits a value, it\n * computes a formula using the latest values from all the inputs, then emits\n * the output of that formula.</span>\n *\n * ![](combineLatest.png)\n *\n * `combineLatest` combines the values from all the Observables passed in the\n * observables array. This is done by subscribing to each Observable in order and,\n * whenever any Observable emits, collecting an array of the most recent\n * values from each Observable. So if you pass `n` Observables to this operator,\n * the returned Observable will always emit an array of `n` values, in an order\n * corresponding to the order of the passed Observables (the value from the first Observable\n * will be at index 0 of the array and so on).\n *\n * Static version of `combineLatest` accepts an array of Observables. Note that an array of\n * Observables is a good choice, if you don't know beforehand how many Observables\n * you will combine. Passing an empty array will result in an Observable that\n * completes immediately.\n *\n * To ensure the output array always has the same length, `combineLatest` will\n * actually wait for all input Observables to emit at least once,\n * before it starts emitting results. This means if some Observable emits\n * values before other Observables started emitting, all these values but the last\n * will be lost. On the other hand, if some Observable does not emit a value but\n * completes, resulting Observable will complete at the same moment without\n * emitting anything, since it will now be impossible to include a value from the\n * completed Observable in the resulting array. Also, if some input Observable does\n * not emit any value and never completes, `combineLatest` will also never emit\n * and never complete, since, again, it will wait for all streams to emit some\n * value.\n *\n * If at least one Observable was passed to `combineLatest` and all passed Observables\n * emitted something, the resulting Observable will complete when all combined\n * streams complete. So even if some Observable completes, the result of\n * `combineLatest` will still emit values when other Observables do. In case\n * of a completed Observable, its value from now on will always be the last\n * emitted value. On the other hand, if any Observable errors, `combineLatest`\n * will error immediately as well, and all other Observables will be unsubscribed.\n *\n * ## Examples\n *\n * Combine two timer Observables\n *\n * ```ts\n * import { timer, combineLatest } from 'rxjs';\n *\n * const firstTimer = timer(0, 1000); // emit 0, 1, 2... after every second, starting from now\n * const secondTimer = timer(500, 1000); // emit 0, 1, 2... after every second, starting 0,5s from now\n * const combinedTimers = combineLatest([firstTimer, secondTimer]);\n * combinedTimers.subscribe(value => console.log(value));\n * // Logs\n * // [0, 0] after 0.5s\n * // [1, 0] after 1s\n * // [1, 1] after 1.5s\n * // [2, 1] after 2s\n * ```\n *\n * Combine a dictionary of Observables\n *\n * ```ts\n * import { of, delay, startWith, combineLatest } from 'rxjs';\n *\n * const observables = {\n *   a: of(1).pipe(delay(1000), startWith(0)),\n *   b: of(5).pipe(delay(5000), startWith(0)),\n *   c: of(10).pipe(delay(10000), startWith(0))\n * };\n * const combined = combineLatest(observables);\n * combined.subscribe(value => console.log(value));\n * // Logs\n * // { a: 0, b: 0, c: 0 } immediately\n * // { a: 1, b: 0, c: 0 } after 1s\n * // { a: 1, b: 5, c: 0 } after 5s\n * // { a: 1, b: 5, c: 10 } after 10s\n * ```\n *\n * Combine an array of Observables\n *\n * ```ts\n * import { of, delay, startWith, combineLatest } from 'rxjs';\n *\n * const observables = [1, 5, 10].map(\n *   n => of(n).pipe(\n *     delay(n * 1000), // emit 0 and then emit n after n seconds\n *     startWith(0)\n *   )\n * );\n * const combined = combineLatest(observables);\n * combined.subscribe(value => console.log(value));\n * // Logs\n * // [0, 0, 0] immediately\n * // [1, 0, 0] after 1s\n * // [1, 5, 0] after 5s\n * // [1, 5, 10] after 10s\n * ```\n *\n * Use map operator to dynamically calculate the Body-Mass Index\n *\n * ```ts\n * import { of, combineLatest, map } from 'rxjs';\n *\n * const weight = of(70, 72, 76, 79, 75);\n * const height = of(1.76, 1.77, 1.78);\n * const bmi = combineLatest([weight, height]).pipe(\n *   map(([w, h]) => w / (h * h)),\n * );\n * bmi.subscribe(x => console.log('BMI is ' + x));\n *\n * // With output to console:\n * // BMI is 24.212293388429753\n * // BMI is 23.93948099205209\n * // BMI is 23.671253629592222\n * ```\n *\n * @see {@link combineLatestAll}\n * @see {@link merge}\n * @see {@link withLatestFrom}\n *\n * @param {ObservableInput} [observables] An array of input Observables to combine with each other.\n * An array of Observables must be given as the first argument.\n * @param {function} [project] An optional function to project the values from\n * the combined latest values into a new value on the output Observable.\n * @param {SchedulerLike} [scheduler=null] The {@link SchedulerLike} to use for subscribing to\n * each input Observable.\n * @return {Observable} An Observable of projected values from the most recent\n * values from each input Observable, or an array of the most recent values from\n * each input Observable.\n */\nexport function combineLatest<O extends ObservableInput<any>, R>(...args: any[]): Observable<R> | Observable<ObservedValueOf<O>[]> {\n  const scheduler = popScheduler(args);\n  const resultSelector = popResultSelector(args);\n\n  const { args: observables, keys } = argsArgArrayOrObject(args);\n\n  if (observables.length === 0) {\n    // If no observables are passed, or someone has passed an empty array\n    // of observables, or even an empty object POJO, we need to just\n    // complete (EMPTY), but we have to honor the scheduler provided if any.\n    return from([], scheduler as any);\n  }\n\n  const result = new Observable<ObservedValueOf<O>[]>(\n    combineLatestInit(\n      observables as ObservableInput<ObservedValueOf<O>>[],\n      scheduler,\n      keys\n        ? // A handler for scrubbing the array of args into a dictionary.\n          (values) => createObject(keys, values)\n        : // A passthrough to just return the array\n          identity\n    )\n  );\n\n  return resultSelector ? (result.pipe(mapOneOrManyArgs(resultSelector)) as Observable<R>) : result;\n}\n\nexport function combineLatestInit(\n  observables: ObservableInput<any>[],\n  scheduler?: SchedulerLike,\n  valueTransform: (values: any[]) => any = identity\n) {\n  return (subscriber: Subscriber<any>) => {\n    // The outer subscription. We're capturing this in a function\n    // because we may have to schedule it.\n    maybeSchedule(\n      scheduler,\n      () => {\n        const { length } = observables;\n        // A store for the values each observable has emitted so far. We match observable to value on index.\n        const values = new Array(length);\n        // The number of currently active subscriptions, as they complete, we decrement this number to see if\n        // we are all done combining values, so we can complete the result.\n        let active = length;\n        // The number of inner sources that still haven't emitted the first value\n        // We need to track this because all sources need to emit one value in order\n        // to start emitting values.\n        let remainingFirstValues = length;\n        // The loop to kick off subscription. We're keying everything on index `i` to relate the observables passed\n        // in to the slot in the output array or the key in the array of keys in the output dictionary.\n        for (let i = 0; i < length; i++) {\n          maybeSchedule(\n            scheduler,\n            () => {\n              const source = from(observables[i], scheduler as any);\n              let hasFirstValue = false;\n              source.subscribe(\n                createOperatorSubscriber(\n                  subscriber,\n                  (value) => {\n                    // When we get a value, record it in our set of values.\n                    values[i] = value;\n                    if (!hasFirstValue) {\n                      // If this is our first value, record that.\n                      hasFirstValue = true;\n                      remainingFirstValues--;\n                    }\n                    if (!remainingFirstValues) {\n                      // We're not waiting for any more\n                      // first values, so we can emit!\n                      subscriber.next(valueTransform(values.slice()));\n                    }\n                  },\n                  () => {\n                    if (!--active) {\n                      // We only complete the result if we have no more active\n                      // inner observables.\n                      subscriber.complete();\n                    }\n                  }\n                )\n              );\n            },\n            subscriber\n          );\n        }\n      },\n      subscriber\n    );\n  };\n}\n\n/**\n * A small utility to handle the couple of locations where we want to schedule if a scheduler was provided,\n * but we don't if there was no scheduler.\n */\nfunction maybeSchedule(scheduler: SchedulerLike | undefined, execute: () => void, subscription: Subscription) {\n  if (scheduler) {\n    executeSchedule(subscription, scheduler, execute);\n  } else {\n    execute();\n  }\n}\n", "import { Observable } from '../Observable';\nimport { innerFrom } from '../observable/innerFrom';\nimport { Subscriber } from '../Subscriber';\nimport { ObservableInput, SchedulerLike } from '../types';\nimport { executeSchedule } from '../util/executeSchedule';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * A process embodying the general \"merge\" strategy. This is used in\n * `mergeMap` and `mergeScan` because the logic is otherwise nearly identical.\n * @param source The original source observable\n * @param subscriber The consumer subscriber\n * @param project The projection function to get our inner sources\n * @param concurrent The number of concurrent inner subscriptions\n * @param onBeforeNext Additional logic to apply before nexting to our consumer\n * @param expand If `true` this will perform an \"expand\" strategy, which differs only\n * in that it recurses, and the inner subscription must be schedule-able.\n * @param innerSubScheduler A scheduler to use to schedule inner subscriptions,\n * this is to support the expand strategy, mostly, and should be deprecated\n */\nexport function mergeInternals<T, R>(\n  source: Observable<T>,\n  subscriber: Subscriber<R>,\n  project: (value: T, index: number) => ObservableInput<R>,\n  concurrent: number,\n  onBeforeNext?: (innerValue: R) => void,\n  expand?: boolean,\n  innerSubScheduler?: SchedulerLike,\n  additionalFinalizer?: () => void\n) {\n  // Buffered values, in the event of going over our concurrency limit\n  const buffer: T[] = [];\n  // The number of active inner subscriptions.\n  let active = 0;\n  // An index to pass to our accumulator function\n  let index = 0;\n  // Whether or not the outer source has completed.\n  let isComplete = false;\n\n  /**\n   * Checks to see if we can complete our result or not.\n   */\n  const checkComplete = () => {\n    // If the outer has completed, and nothing is left in the buffer,\n    // and we don't have any active inner subscriptions, then we can\n    // Emit the state and complete.\n    if (isComplete && !buffer.length && !active) {\n      subscriber.complete();\n    }\n  };\n\n  // If we're under our concurrency limit, just start the inner subscription, otherwise buffer and wait.\n  const outerNext = (value: T) => (active < concurrent ? doInnerSub(value) : buffer.push(value));\n\n  const doInnerSub = (value: T) => {\n    // If we're expanding, we need to emit the outer values and the inner values\n    // as the inners will \"become outers\" in a way as they are recursively fed\n    // back to the projection mechanism.\n    expand && subscriber.next(value as any);\n\n    // Increment the number of active subscriptions so we can track it\n    // against our concurrency limit later.\n    active++;\n\n    // A flag used to show that the inner observable completed.\n    // This is checked during finalization to see if we should\n    // move to the next item in the buffer, if there is on.\n    let innerComplete = false;\n\n    // Start our inner subscription.\n    innerFrom(project(value, index++)).subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (innerValue) => {\n          // `mergeScan` has additional handling here. For example\n          // taking the inner value and updating state.\n          onBeforeNext?.(innerValue);\n\n          if (expand) {\n            // If we're expanding, then just recurse back to our outer\n            // handler. It will emit the value first thing.\n            outerNext(innerValue as any);\n          } else {\n            // Otherwise, emit the inner value.\n            subscriber.next(innerValue);\n          }\n        },\n        () => {\n          // Flag that we have completed, so we know to check the buffer\n          // during finalization.\n          innerComplete = true;\n        },\n        // Errors are passed to the destination.\n        undefined,\n        () => {\n          // During finalization, if the inner completed (it wasn't errored or\n          // cancelled), then we want to try the next item in the buffer if\n          // there is one.\n          if (innerComplete) {\n            // We have to wrap this in a try/catch because it happens during\n            // finalization, possibly asynchronously, and we want to pass\n            // any errors that happen (like in a projection function) to\n            // the outer Subscriber.\n            try {\n              // INNER SOURCE COMPLETE\n              // Decrement the active count to ensure that the next time\n              // we try to call `doInnerSub`, the number is accurate.\n              active--;\n              // If we have more values in the buffer, try to process those\n              // Note that this call will increment `active` ahead of the\n              // next conditional, if there were any more inner subscriptions\n              // to start.\n              while (buffer.length && active < concurrent) {\n                const bufferedValue = buffer.shift()!;\n                // Particularly for `expand`, we need to check to see if a scheduler was provided\n                // for when we want to start our inner subscription. Otherwise, we just start\n                // are next inner subscription.\n                if (innerSubScheduler) {\n                  executeSchedule(subscriber, innerSubScheduler, () => doInnerSub(bufferedValue));\n                } else {\n                  doInnerSub(bufferedValue);\n                }\n              }\n              // Check to see if we can complete, and complete if so.\n              checkComplete();\n            } catch (err) {\n              subscriber.error(err);\n            }\n          }\n        }\n      )\n    );\n  };\n\n  // Subscribe to our source observable.\n  source.subscribe(\n    createOperatorSubscriber(subscriber, outerNext, () => {\n      // Outer completed, make a note of it, and check to see if we can complete everything.\n      isComplete = true;\n      checkComplete();\n    })\n  );\n\n  // Additional finalization (for when the destination is torn down).\n  // Other finalization is added implicitly via subscription above.\n  return () => {\n    additionalFinalizer?.();\n  };\n}\n", "import { ObservableInput, OperatorFunction, ObservedValueOf } from '../types';\nimport { map } from './map';\nimport { innerFrom } from '../observable/innerFrom';\nimport { operate } from '../util/lift';\nimport { mergeInternals } from './mergeInternals';\nimport { isFunction } from '../util/isFunction';\n\n/* tslint:disable:max-line-length */\nexport function mergeMap<T, O extends ObservableInput<any>>(\n  project: (value: T, index: number) => O,\n  concurrent?: number\n): OperatorFunction<T, ObservedValueOf<O>>;\n/** @deprecated The `resultSelector` parameter will be removed in v8. Use an inner `map` instead. Details: https://rxjs.dev/deprecations/resultSelector */\nexport function mergeMap<T, O extends ObservableInput<any>>(\n  project: (value: T, index: number) => O,\n  resultSelector: undefined,\n  concurrent?: number\n): OperatorFunction<T, ObservedValueOf<O>>;\n/** @deprecated The `resultSelector` parameter will be removed in v8. Use an inner `map` instead. Details: https://rxjs.dev/deprecations/resultSelector */\nexport function mergeMap<T, R, O extends ObservableInput<any>>(\n  project: (value: T, index: number) => O,\n  resultSelector: (outerValue: T, innerValue: ObservedValueOf<O>, outerIndex: number, innerIndex: number) => R,\n  concurrent?: number\n): OperatorFunction<T, R>;\n/* tslint:enable:max-line-length */\n\n/**\n * Projects each source value to an Observable which is merged in the output\n * Observable.\n *\n * <span class=\"informal\">Maps each value to an Observable, then flattens all of\n * these inner Observables using {@link mergeAll}.</span>\n *\n * ![](mergeMap.png)\n *\n * Returns an Observable that emits items based on applying a function that you\n * supply to each item emitted by the source Observable, where that function\n * returns an Observable, and then merging those resulting Observables and\n * emitting the results of this merger.\n *\n * ## Example\n *\n * Map and flatten each letter to an Observable ticking every 1 second\n *\n * ```ts\n * import { of, mergeMap, interval, map } from 'rxjs';\n *\n * const letters = of('a', 'b', 'c');\n * const result = letters.pipe(\n *   mergeMap(x => interval(1000).pipe(map(i => x + i)))\n * );\n *\n * result.subscribe(x => console.log(x));\n *\n * // Results in the following:\n * // a0\n * // b0\n * // c0\n * // a1\n * // b1\n * // c1\n * // continues to list a, b, c every second with respective ascending integers\n * ```\n *\n * @see {@link concatMap}\n * @see {@link exhaustMap}\n * @see {@link merge}\n * @see {@link mergeAll}\n * @see {@link mergeMapTo}\n * @see {@link mergeScan}\n * @see {@link switchMap}\n *\n * @param {function(value: T, ?index: number): ObservableInput} project A function\n * that, when applied to an item emitted by the source Observable, returns an\n * Observable.\n * @param {number} [concurrent=Infinity] Maximum number of input\n * Observables being subscribed to concurrently.\n * @return A function that returns an Observable that emits the result of\n * applying the projection function (and the optional deprecated\n * `resultSelector`) to each item emitted by the source Observable and merging\n * the results of the Observables obtained from this transformation.\n */\nexport function mergeMap<T, R, O extends ObservableInput<any>>(\n  project: (value: T, index: number) => O,\n  resultSelector?: ((outerValue: T, innerValue: ObservedValueOf<O>, outerIndex: number, innerIndex: number) => R) | number,\n  concurrent: number = Infinity\n): OperatorFunction<T, ObservedValueOf<O> | R> {\n  if (isFunction(resultSelector)) {\n    // DEPRECATED PATH\n    return mergeMap((a, i) => map((b: any, ii: number) => resultSelector(a, b, i, ii))(innerFrom(project(a, i))), concurrent);\n  } else if (typeof resultSelector === 'number') {\n    concurrent = resultSelector;\n  }\n\n  return operate((source, subscriber) => mergeInternals(source, subscriber, project, concurrent));\n}\n", "import { mergeMap } from './mergeMap';\nimport { identity } from '../util/identity';\nimport { OperatorFunction, ObservableInput, ObservedValueOf } from '../types';\n\n/**\n * Converts a higher-order Observable into a first-order Observable which\n * concurrently delivers all values that are emitted on the inner Observables.\n *\n * <span class=\"informal\">Flattens an Observable-of-Observables.</span>\n *\n * ![](mergeAll.png)\n *\n * `mergeAll` subscribes to an Observable that emits Observables, also known as\n * a higher-order Observable. Each time it observes one of these emitted inner\n * Observables, it subscribes to that and delivers all the values from the\n * inner Observable on the output Observable. The output Observable only\n * completes once all inner Observables have completed. Any error delivered by\n * a inner Observable will be immediately emitted on the output Observable.\n *\n * ## Examples\n *\n * Spawn a new interval Observable for each click event, and blend their outputs as one Observable\n *\n * ```ts\n * import { fromEvent, map, interval, mergeAll } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const higherOrder = clicks.pipe(map(() => interval(1000)));\n * const firstOrder = higherOrder.pipe(mergeAll());\n *\n * firstOrder.subscribe(x => console.log(x));\n * ```\n *\n * Count from 0 to 9 every second for each click, but only allow 2 concurrent timers\n *\n * ```ts\n * import { fromEvent, map, interval, take, mergeAll } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const higherOrder = clicks.pipe(\n *   map(() => interval(1000).pipe(take(10)))\n * );\n * const firstOrder = higherOrder.pipe(mergeAll(2));\n *\n * firstOrder.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link combineLatestAll}\n * @see {@link concatAll}\n * @see {@link exhaustAll}\n * @see {@link merge}\n * @see {@link mergeMap}\n * @see {@link mergeMapTo}\n * @see {@link mergeScan}\n * @see {@link switchAll}\n * @see {@link switchMap}\n * @see {@link zipAll}\n *\n * @param {number} [concurrent=Infinity] Maximum number of inner\n * Observables being subscribed to concurrently.\n * @return A function that returns an Observable that emits values coming from\n * all the inner Observables emitted by the source Observable.\n */\nexport function mergeAll<O extends ObservableInput<any>>(concurrent: number = Infinity): OperatorFunction<O, ObservedValueOf<O>> {\n  return mergeMap(identity, concurrent);\n}\n", "import { mergeAll } from './mergeAll';\nimport { OperatorFunction, ObservableInput, ObservedValueOf } from '../types';\n\n/**\n * Converts a higher-order Observable into a first-order Observable by\n * concatenating the inner Observables in order.\n *\n * <span class=\"informal\">Flattens an Observable-of-Observables by putting one\n * inner Observable after the other.</span>\n *\n * ![](concatAll.svg)\n *\n * Joins every Observable emitted by the source (a higher-order Observable), in\n * a serial fashion. It subscribes to each inner Observable only after the\n * previous inner Observable has completed, and merges all of their values into\n * the returned observable.\n *\n * __Warning:__ If the source Observable emits Observables quickly and\n * endlessly, and the inner Observables it emits generally complete slower than\n * the source emits, you can run into memory issues as the incoming Observables\n * collect in an unbounded buffer.\n *\n * Note: `concatAll` is equivalent to `mergeAll` with concurrency parameter set\n * to `1`.\n *\n * ## Example\n *\n * For each click event, tick every second from 0 to 3, with no concurrency\n *\n * ```ts\n * import { fromEvent, map, interval, take, concatAll } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const higherOrder = clicks.pipe(\n *   map(() => interval(1000).pipe(take(4)))\n * );\n * const firstOrder = higherOrder.pipe(concatAll());\n * firstOrder.subscribe(x => console.log(x));\n *\n * // Results in the following:\n * // (results are not concurrent)\n * // For every click on the \"document\" it will emit values 0 to 3 spaced\n * // on a 1000ms interval\n * // one click = 1000ms-> 0 -1000ms-> 1 -1000ms-> 2 -1000ms-> 3\n * ```\n *\n * @see {@link combineLatestAll}\n * @see {@link concat}\n * @see {@link concatMap}\n * @see {@link concatMapTo}\n * @see {@link exhaustAll}\n * @see {@link mergeAll}\n * @see {@link switchAll}\n * @see {@link switchMap}\n * @see {@link zipAll}\n *\n * @return A function that returns an Observable emitting values from all the\n * inner Observables concatenated.\n */\nexport function concatAll<O extends ObservableInput<any>>(): OperatorFunction<O, ObservedValueOf<O>> {\n  return mergeAll(1);\n}\n", "import { Observable } from '../Observable';\nimport { ObservableInputTuple, SchedulerLike } from '../types';\nimport { concatAll } from '../operators/concatAll';\nimport { popScheduler } from '../util/args';\nimport { from } from './from';\n\nexport function concat<T extends readonly unknown[]>(...inputs: [...ObservableInputTuple<T>]): Observable<T[number]>;\nexport function concat<T extends readonly unknown[]>(\n  ...inputsAndScheduler: [...ObservableInputTuple<T>, SchedulerLike]\n): Observable<T[number]>;\n\n/**\n * Creates an output Observable which sequentially emits all values from the first given\n * Observable and then moves on to the next.\n *\n * <span class=\"informal\">Concatenates multiple Observables together by\n * sequentially emitting their values, one Observable after the other.</span>\n *\n * ![](concat.png)\n *\n * `concat` joins multiple Observables together, by subscribing to them one at a time and\n * merging their results into the output Observable. You can pass either an array of\n * Observables, or put them directly as arguments. Passing an empty array will result\n * in Observable that completes immediately.\n *\n * `concat` will subscribe to first input Observable and emit all its values, without\n * changing or affecting them in any way. When that Observable completes, it will\n * subscribe to then next Observable passed and, again, emit its values. This will be\n * repeated, until the operator runs out of Observables. When last input Observable completes,\n * `concat` will complete as well. At any given moment only one Observable passed to operator\n * emits values. If you would like to emit values from passed Observables concurrently, check out\n * {@link merge} instead, especially with optional `concurrent` parameter. As a matter of fact,\n * `concat` is an equivalent of `merge` operator with `concurrent` parameter set to `1`.\n *\n * Note that if some input Observable never completes, `concat` will also never complete\n * and Observables following the one that did not complete will never be subscribed. On the other\n * hand, if some Observable simply completes immediately after it is subscribed, it will be\n * invisible for `concat`, which will just move on to the next Observable.\n *\n * If any Observable in chain errors, instead of passing control to the next Observable,\n * `concat` will error immediately as well. Observables that would be subscribed after\n * the one that emitted error, never will.\n *\n * If you pass to `concat` the same Observable many times, its stream of values\n * will be \"replayed\" on every subscription, which means you can repeat given Observable\n * as many times as you like. If passing the same Observable to `concat` 1000 times becomes tedious,\n * you can always use {@link repeat}.\n *\n * ## Examples\n *\n * Concatenate a timer counting from 0 to 3 with a synchronous sequence from 1 to 10\n *\n * ```ts\n * import { interval, take, range, concat } from 'rxjs';\n *\n * const timer = interval(1000).pipe(take(4));\n * const sequence = range(1, 10);\n * const result = concat(timer, sequence);\n * result.subscribe(x => console.log(x));\n *\n * // results in:\n * // 0 -1000ms-> 1 -1000ms-> 2 -1000ms-> 3 -immediate-> 1 ... 10\n * ```\n *\n * Concatenate 3 Observables\n *\n * ```ts\n * import { interval, take, concat } from 'rxjs';\n *\n * const timer1 = interval(1000).pipe(take(10));\n * const timer2 = interval(2000).pipe(take(6));\n * const timer3 = interval(500).pipe(take(10));\n *\n * const result = concat(timer1, timer2, timer3);\n * result.subscribe(x => console.log(x));\n *\n * // results in the following:\n * // (Prints to console sequentially)\n * // -1000ms-> 0 -1000ms-> 1 -1000ms-> ... 9\n * // -2000ms-> 0 -2000ms-> 1 -2000ms-> ... 5\n * // -500ms-> 0 -500ms-> 1 -500ms-> ... 9\n * ```\n *\n * Concatenate the same Observable to repeat it\n *\n * ```ts\n * import { interval, take, concat } from 'rxjs';\n *\n * const timer = interval(1000).pipe(take(2));\n *\n * concat(timer, timer) // concatenating the same Observable!\n *   .subscribe({\n *     next: value => console.log(value),\n *     complete: () => console.log('...and it is done!')\n *   });\n *\n * // Logs:\n * // 0 after 1s\n * // 1 after 2s\n * // 0 after 3s\n * // 1 after 4s\n * // '...and it is done!' also after 4s\n * ```\n *\n * @see {@link concatAll}\n * @see {@link concatMap}\n * @see {@link concatMapTo}\n * @see {@link startWith}\n * @see {@link endWith}\n *\n * @param args Input Observables to concatenate.\n */\nexport function concat(...args: any[]): Observable<unknown> {\n  return concatAll()(from(args, popScheduler(args)));\n}\n", "import { Observable } from '../Observable';\nimport { ObservedValueOf, ObservableInput } from '../types';\nimport { innerFrom } from './innerFrom';\n\n/**\n * Creates an Observable that, on subscribe, calls an Observable factory to\n * make an Observable for each new Observer.\n *\n * <span class=\"informal\">Creates the Observable lazily, that is, only when it\n * is subscribed.\n * </span>\n *\n * ![](defer.png)\n *\n * `defer` allows you to create an Observable only when the Observer\n * subscribes. It waits until an Observer subscribes to it, calls the given\n * factory function to get an Observable -- where a factory function typically\n * generates a new Observable -- and subscribes the Observer to this Observable.\n * In case the factory function returns a falsy value, then EMPTY is used as\n * Observable instead. Last but not least, an exception during the factory\n * function call is transferred to the Observer by calling `error`.\n *\n * ## Example\n *\n * Subscribe to either an Observable of clicks or an Observable of interval, at random\n *\n * ```ts\n * import { defer, fromEvent, interval } from 'rxjs';\n *\n * const clicksOrInterval = defer(() => {\n *   return Math.random() > 0.5\n *     ? fromEvent(document, 'click')\n *     : interval(1000);\n * });\n * clicksOrInterval.subscribe(x => console.log(x));\n *\n * // Results in the following behavior:\n * // If the result of Math.random() is greater than 0.5 it will listen\n * // for clicks anywhere on the \"document\"; when document is clicked it\n * // will log a MouseEvent object to the console. If the result is less\n * // than 0.5 it will emit ascending numbers, one every second(1000ms).\n * ```\n *\n * @see {@link Observable}\n *\n * @param {function(): ObservableInput} observableFactory The Observable\n * factory function to invoke for each Observer that subscribes to the output\n * Observable. May also return a Promise, which will be converted on the fly\n * to an Observable.\n * @return {Observable} An Observable whose Observers' subscriptions trigger\n * an invocation of the given Observable factory function.\n */\nexport function defer<R extends ObservableInput<any>>(observableFactory: () => R): Observable<ObservedValueOf<R>> {\n  return new Observable<ObservedValueOf<R>>((subscriber) => {\n    innerFrom(observableFactory()).subscribe(subscriber);\n  });\n}\n", "import { innerFrom } from '../observable/innerFrom';\nimport { Observable } from '../Observable';\nimport { mergeMap } from '../operators/mergeMap';\nimport { isArrayLike } from '../util/isArrayLike';\nimport { isFunction } from '../util/isFunction';\nimport { mapOneOrManyArgs } from '../util/mapOneOrManyArgs';\n\n// These constants are used to create handler registry functions using array mapping below.\nconst nodeEventEmitterMethods = ['addListener', 'removeListener'] as const;\nconst eventTargetMethods = ['addEventListener', 'removeEventListener'] as const;\nconst jqueryMethods = ['on', 'off'] as const;\n\nexport interface NodeStyleEventEmitter {\n  addListener(eventName: string | symbol, handler: NodeEventHandler): this;\n  removeListener(eventName: string | symbol, handler: NodeEventHandler): this;\n}\n\nexport type NodeEventHandler = (...args: any[]) => void;\n\n// For APIs that implement `addListener` and `removeListener` methods that may\n// not use the same arguments or return EventEmitter values\n// such as React Native\nexport interface NodeCompatibleEventEmitter {\n  addListener(eventName: string, handler: NodeEventHandler): void | {};\n  removeListener(eventName: string, handler: NodeEventHandler): void | {};\n}\n\n// Use handler types like those in @types/jquery. See:\n// https://github.com/DefinitelyTyped/DefinitelyTyped/blob/847731ba1d7fa6db6b911c0e43aa0afe596e7723/types/jquery/misc.d.ts#L6395\nexport interface JQueryStyleEventEmitter<TContext, T> {\n  on(eventName: string, handler: (this: TContext, t: T, ...args: any[]) => any): void;\n  off(eventName: string, handler: (this: TContext, t: T, ...args: any[]) => any): void;\n}\n\nexport interface EventListenerObject<E> {\n  handleEvent(evt: E): void;\n}\n\nexport interface HasEventTargetAddRemove<E> {\n  addEventListener(\n    type: string,\n    listener: ((evt: E) => void) | EventListenerObject<E> | null,\n    options?: boolean | AddEventListenerOptions\n  ): void;\n  removeEventListener(\n    type: string,\n    listener: ((evt: E) => void) | EventListenerObject<E> | null,\n    options?: EventListenerOptions | boolean\n  ): void;\n}\n\nexport interface EventListenerOptions {\n  capture?: boolean;\n  passive?: boolean;\n  once?: boolean;\n}\n\nexport interface AddEventListenerOptions extends EventListenerOptions {\n  once?: boolean;\n  passive?: boolean;\n}\n\nexport function fromEvent<T>(target: HasEventTargetAddRemove<T> | ArrayLike<HasEventTargetAddRemove<T>>, eventName: string): Observable<T>;\nexport function fromEvent<T, R>(\n  target: HasEventTargetAddRemove<T> | ArrayLike<HasEventTargetAddRemove<T>>,\n  eventName: string,\n  resultSelector: (event: T) => R\n): Observable<R>;\nexport function fromEvent<T>(\n  target: HasEventTargetAddRemove<T> | ArrayLike<HasEventTargetAddRemove<T>>,\n  eventName: string,\n  options: EventListenerOptions\n): Observable<T>;\nexport function fromEvent<T, R>(\n  target: HasEventTargetAddRemove<T> | ArrayLike<HasEventTargetAddRemove<T>>,\n  eventName: string,\n  options: EventListenerOptions,\n  resultSelector: (event: T) => R\n): Observable<R>;\n\nexport function fromEvent(target: NodeStyleEventEmitter | ArrayLike<NodeStyleEventEmitter>, eventName: string): Observable<unknown>;\n/** @deprecated Do not specify explicit type parameters. Signatures with type parameters that cannot be inferred will be removed in v8. */\nexport function fromEvent<T>(target: NodeStyleEventEmitter | ArrayLike<NodeStyleEventEmitter>, eventName: string): Observable<T>;\nexport function fromEvent<R>(\n  target: NodeStyleEventEmitter | ArrayLike<NodeStyleEventEmitter>,\n  eventName: string,\n  resultSelector: (...args: any[]) => R\n): Observable<R>;\n\nexport function fromEvent(\n  target: NodeCompatibleEventEmitter | ArrayLike<NodeCompatibleEventEmitter>,\n  eventName: string\n): Observable<unknown>;\n/** @deprecated Do not specify explicit type parameters. Signatures with type parameters that cannot be inferred will be removed in v8. */\nexport function fromEvent<T>(target: NodeCompatibleEventEmitter | ArrayLike<NodeCompatibleEventEmitter>, eventName: string): Observable<T>;\nexport function fromEvent<R>(\n  target: NodeCompatibleEventEmitter | ArrayLike<NodeCompatibleEventEmitter>,\n  eventName: string,\n  resultSelector: (...args: any[]) => R\n): Observable<R>;\n\nexport function fromEvent<T>(\n  target: JQueryStyleEventEmitter<any, T> | ArrayLike<JQueryStyleEventEmitter<any, T>>,\n  eventName: string\n): Observable<T>;\nexport function fromEvent<T, R>(\n  target: JQueryStyleEventEmitter<any, T> | ArrayLike<JQueryStyleEventEmitter<any, T>>,\n  eventName: string,\n  resultSelector: (value: T, ...args: any[]) => R\n): Observable<R>;\n\n/**\n * Creates an Observable that emits events of a specific type coming from the\n * given event target.\n *\n * <span class=\"informal\">Creates an Observable from DOM events, or Node.js\n * EventEmitter events or others.</span>\n *\n * ![](fromEvent.png)\n *\n * `fromEvent` accepts as a first argument event target, which is an object with methods\n * for registering event handler functions. As a second argument it takes string that indicates\n * type of event we want to listen for. `fromEvent` supports selected types of event targets,\n * which are described in detail below. If your event target does not match any of the ones listed,\n * you should use {@link fromEventPattern}, which can be used on arbitrary APIs.\n * When it comes to APIs supported by `fromEvent`, their methods for adding and removing event\n * handler functions have different names, but they all accept a string describing event type\n * and function itself, which will be called whenever said event happens.\n *\n * Every time resulting Observable is subscribed, event handler function will be registered\n * to event target on given event type. When that event fires, value\n * passed as a first argument to registered function will be emitted by output Observable.\n * When Observable is unsubscribed, function will be unregistered from event target.\n *\n * Note that if event target calls registered function with more than one argument, second\n * and following arguments will not appear in resulting stream. In order to get access to them,\n * you can pass to `fromEvent` optional project function, which will be called with all arguments\n * passed to event handler. Output Observable will then emit value returned by project function,\n * instead of the usual value.\n *\n * Remember that event targets listed below are checked via duck typing. It means that\n * no matter what kind of object you have and no matter what environment you work in,\n * you can safely use `fromEvent` on that object if it exposes described methods (provided\n * of course they behave as was described above). So for example if Node.js library exposes\n * event target which has the same method names as DOM EventTarget, `fromEvent` is still\n * a good choice.\n *\n * If the API you use is more callback then event handler oriented (subscribed\n * callback function fires only once and thus there is no need to manually\n * unregister it), you should use {@link bindCallback} or {@link bindNodeCallback}\n * instead.\n *\n * `fromEvent` supports following types of event targets:\n *\n * **DOM EventTarget**\n *\n * This is an object with `addEventListener` and `removeEventListener` methods.\n *\n * In the browser, `addEventListener` accepts - apart from event type string and event\n * handler function arguments - optional third parameter, which is either an object or boolean,\n * both used for additional configuration how and when passed function will be called. When\n * `fromEvent` is used with event target of that type, you can provide this values\n * as third parameter as well.\n *\n * **Node.js EventEmitter**\n *\n * An object with `addListener` and `removeListener` methods.\n *\n * **JQuery-style event target**\n *\n * An object with `on` and `off` methods\n *\n * **DOM NodeList**\n *\n * List of DOM Nodes, returned for example by `document.querySelectorAll` or `Node.childNodes`.\n *\n * Although this collection is not event target in itself, `fromEvent` will iterate over all Nodes\n * it contains and install event handler function in every of them. When returned Observable\n * is unsubscribed, function will be removed from all Nodes.\n *\n * **DOM HtmlCollection**\n *\n * Just as in case of NodeList it is a collection of DOM nodes. Here as well event handler function is\n * installed and removed in each of elements.\n *\n *\n * ## Examples\n *\n * Emit clicks happening on the DOM document\n *\n * ```ts\n * import { fromEvent } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * clicks.subscribe(x => console.log(x));\n *\n * // Results in:\n * // MouseEvent object logged to console every time a click\n * // occurs on the document.\n * ```\n *\n * Use `addEventListener` with capture option\n *\n * ```ts\n * import { fromEvent } from 'rxjs';\n *\n * const div = document.createElement('div');\n * div.style.cssText = 'width: 200px; height: 200px; background: #09c;';\n * document.body.appendChild(div);\n *\n * // note optional configuration parameter which will be passed to addEventListener\n * const clicksInDocument = fromEvent(document, 'click', { capture: true });\n * const clicksInDiv = fromEvent(div, 'click');\n *\n * clicksInDocument.subscribe(() => console.log('document'));\n * clicksInDiv.subscribe(() => console.log('div'));\n *\n * // By default events bubble UP in DOM tree, so normally\n * // when we would click on div in document\n * // \"div\" would be logged first and then \"document\".\n * // Since we specified optional `capture` option, document\n * // will catch event when it goes DOWN DOM tree, so console\n * // will log \"document\" and then \"div\".\n * ```\n *\n * @see {@link bindCallback}\n * @see {@link bindNodeCallback}\n * @see {@link fromEventPattern}\n *\n * @param {FromEventTarget<T>} target The DOM EventTarget, Node.js\n * EventEmitter, JQuery-like event target, NodeList or HTMLCollection to attach the event handler to.\n * @param {string} eventName The event name of interest, being emitted by the\n * `target`.\n * @param {EventListenerOptions} [options] Options to pass through to addEventListener\n * @return {Observable<T>}\n */\nexport function fromEvent<T>(\n  target: any,\n  eventName: string,\n  options?: EventListenerOptions | ((...args: any[]) => T),\n  resultSelector?: (...args: any[]) => T\n): Observable<T> {\n  if (isFunction(options)) {\n    resultSelector = options;\n    options = undefined;\n  }\n  if (resultSelector) {\n    return fromEvent<T>(target, eventName, options as EventListenerOptions).pipe(mapOneOrManyArgs(resultSelector));\n  }\n\n  // Figure out our add and remove methods. In order to do this,\n  // we are going to analyze the target in a preferred order, if\n  // the target matches a given signature, we take the two \"add\" and \"remove\"\n  // method names and apply them to a map to create opposite versions of the\n  // same function. This is because they all operate in duplicate pairs,\n  // `addListener(name, handler)`, `removeListener(name, handler)`, for example.\n  // The call only differs by method name, as to whether or not you're adding or removing.\n  const [add, remove] =\n    // If it is an EventTarget, we need to use a slightly different method than the other two patterns.\n    isEventTarget(target)\n      ? eventTargetMethods.map((methodName) => (handler: any) => target[methodName](eventName, handler, options as EventListenerOptions))\n      : // In all other cases, the call pattern is identical with the exception of the method names.\n      isNodeStyleEventEmitter(target)\n      ? nodeEventEmitterMethods.map(toCommonHandlerRegistry(target, eventName))\n      : isJQueryStyleEventEmitter(target)\n      ? jqueryMethods.map(toCommonHandlerRegistry(target, eventName))\n      : [];\n\n  // If add is falsy, it's because we didn't match a pattern above.\n  // Check to see if it is an ArrayLike, because if it is, we want to\n  // try to apply fromEvent to all of it's items. We do this check last,\n  // because there are may be some types that are both ArrayLike *and* implement\n  // event registry points, and we'd rather delegate to that when possible.\n  if (!add) {\n    if (isArrayLike(target)) {\n      return mergeMap((subTarget: any) => fromEvent(subTarget, eventName, options as EventListenerOptions))(\n        innerFrom(target)\n      ) as Observable<T>;\n    }\n  }\n\n  // If add is falsy and we made it here, it's because we didn't\n  // match any valid target objects above.\n  if (!add) {\n    throw new TypeError('Invalid event target');\n  }\n\n  return new Observable<T>((subscriber) => {\n    // The handler we are going to register. Forwards the event object, by itself, or\n    // an array of arguments to the event handler, if there is more than one argument,\n    // to the consumer.\n    const handler = (...args: any[]) => subscriber.next(1 < args.length ? args : args[0]);\n    // Do the work of adding the handler to the target.\n    add(handler);\n    // When we finalize, we want to remove the handler and free up memory.\n    return () => remove!(handler);\n  });\n}\n\n/**\n * Used to create `add` and `remove` functions to register and unregister event handlers\n * from a target in the most common handler pattern, where there are only two arguments.\n * (e.g.  `on(name, fn)`, `off(name, fn)`, `addListener(name, fn)`, or `removeListener(name, fn)`)\n * @param target The target we're calling methods on\n * @param eventName The event name for the event we're creating register or unregister functions for\n */\nfunction toCommonHandlerRegistry(target: any, eventName: string) {\n  return (methodName: string) => (handler: any) => target[methodName](eventName, handler);\n}\n\n/**\n * Checks to see if the target implements the required node-style EventEmitter methods\n * for adding and removing event handlers.\n * @param target the object to check\n */\nfunction isNodeStyleEventEmitter(target: any): target is NodeStyleEventEmitter {\n  return isFunction(target.addListener) && isFunction(target.removeListener);\n}\n\n/**\n * Checks to see if the target implements the required jQuery-style EventEmitter methods\n * for adding and removing event handlers.\n * @param target the object to check\n */\nfunction isJQueryStyleEventEmitter(target: any): target is JQueryStyleEventEmitter<any, any> {\n  return isFunction(target.on) && isFunction(target.off);\n}\n\n/**\n * Checks to see if the target implements the required EventTarget methods\n * for adding and removing event handlers.\n * @param target the object to check\n */\nfunction isEventTarget(target: any): target is HasEventTargetAddRemove<any> {\n  return isFunction(target.addEventListener) && isFunction(target.removeEventListener);\n}\n", "import { Observable } from '../Observable';\nimport { isFunction } from '../util/isFunction';\nimport { NodeEventHandler } from './fromEvent';\nimport { mapOneOrManyArgs } from '../util/mapOneOrManyArgs';\n\n/* tslint:disable:max-line-length */\nexport function fromEventPattern<T>(\n  addHandler: (handler: NodeEventHandler) => any,\n  removeHandler?: (handler: NodeEventHandler, signal?: any) => void\n): Observable<T>;\nexport function fromEventPattern<T>(\n  addHandler: (handler: NodeEventHandler) => any,\n  removeHandler?: (handler: NodeEventHandler, signal?: any) => void,\n  resultSelector?: (...args: any[]) => T\n): Observable<T>;\n/* tslint:enable:max-line-length */\n\n/**\n * Creates an Observable from an arbitrary API for registering event handlers.\n *\n * <span class=\"informal\">When that method for adding event handler was something {@link fromEvent}\n * was not prepared for.</span>\n *\n * ![](fromEventPattern.png)\n *\n * `fromEventPattern` allows you to convert into an Observable any API that supports registering handler functions\n * for events. It is similar to {@link fromEvent}, but far\n * more flexible. In fact, all use cases of {@link fromEvent} could be easily handled by\n * `fromEventPattern` (although in slightly more verbose way).\n *\n * This operator accepts as a first argument an `addHandler` function, which will be injected with\n * handler parameter. That handler is actually an event handler function that you now can pass\n * to API expecting it. `addHandler` will be called whenever Observable\n * returned by the operator is subscribed, so registering handler in API will not\n * necessarily happen when `fromEventPattern` is called.\n *\n * After registration, every time an event that we listen to happens,\n * Observable returned by `fromEventPattern` will emit value that event handler\n * function was called with. Note that if event handler was called with more\n * than one argument, second and following arguments will not appear in the Observable.\n *\n * If API you are using allows to unregister event handlers as well, you can pass to `fromEventPattern`\n * another function - `removeHandler` - as a second parameter. It will be injected\n * with the same handler function as before, which now you can use to unregister\n * it from the API. `removeHandler` will be called when consumer of resulting Observable\n * unsubscribes from it.\n *\n * In some APIs unregistering is actually handled differently. Method registering an event handler\n * returns some kind of token, which is later used to identify which function should\n * be unregistered or it itself has method that unregisters event handler.\n * If that is the case with your API, make sure token returned\n * by registering method is returned by `addHandler`. Then it will be passed\n * as a second argument to `removeHandler`, where you will be able to use it.\n *\n * If you need access to all event handler parameters (not only the first one),\n * or you need to transform them in any way, you can call `fromEventPattern` with optional\n * third parameter - project function which will accept all arguments passed to\n * event handler when it is called. Whatever is returned from project function will appear on\n * resulting stream instead of usual event handlers first argument. This means\n * that default project can be thought of as function that takes its first parameter\n * and ignores the rest.\n *\n * ## Examples\n *\n * Emits clicks happening on the DOM document\n *\n * ```ts\n * import { fromEventPattern } from 'rxjs';\n *\n * function addClickHandler(handler) {\n *   document.addEventListener('click', handler);\n * }\n *\n * function removeClickHandler(handler) {\n *   document.removeEventListener('click', handler);\n * }\n *\n * const clicks = fromEventPattern(\n *   addClickHandler,\n *   removeClickHandler\n * );\n * clicks.subscribe(x => console.log(x));\n *\n * // Whenever you click anywhere in the browser, DOM MouseEvent\n * // object will be logged.\n * ```\n *\n * Use with API that returns cancellation token\n *\n * ```ts\n * import { fromEventPattern } from 'rxjs';\n *\n * const token = someAPI.registerEventHandler(function() {});\n * someAPI.unregisterEventHandler(token); // this APIs cancellation method accepts\n *                                        // not handler itself, but special token.\n *\n * const someAPIObservable = fromEventPattern(\n *   function(handler) { return someAPI.registerEventHandler(handler); }, // Note that we return the token here...\n *   function(handler, token) { someAPI.unregisterEventHandler(token); }  // ...to then use it here.\n * );\n * ```\n *\n * Use with project function\n *\n * ```ts\n * import { fromEventPattern } from 'rxjs';\n *\n * someAPI.registerEventHandler((eventType, eventMessage) => {\n *   console.log(eventType, eventMessage); // Logs 'EVENT_TYPE' 'EVENT_MESSAGE' to console.\n * });\n *\n * const someAPIObservable = fromEventPattern(\n *   handler => someAPI.registerEventHandler(handler),\n *   handler => someAPI.unregisterEventHandler(handler)\n *   (eventType, eventMessage) => eventType + ' --- ' + eventMessage // without that function only 'EVENT_TYPE'\n * );                                                                // would be emitted by the Observable\n *\n * someAPIObservable.subscribe(value => console.log(value));\n *\n * // Logs:\n * // 'EVENT_TYPE --- EVENT_MESSAGE'\n * ```\n *\n * @see {@link fromEvent}\n * @see {@link bindCallback}\n * @see {@link bindNodeCallback}\n *\n * @param {function(handler: Function): any} addHandler A function that takes\n * a `handler` function as argument and attaches it somehow to the actual\n * source of events.\n * @param {function(handler: Function, token?: any): void} [removeHandler] A function that\n * takes a `handler` function as an argument and removes it from the event source. If `addHandler`\n * returns some kind of token, `removeHandler` function will have it as a second parameter.\n * @param {function(...args: any): T} [project] A function to\n * transform results. It takes the arguments from the event handler and\n * should return a single value.\n * @return {Observable<T>} Observable which, when an event happens, emits first parameter\n * passed to registered event handler. Alternatively it emits whatever project function returns\n * at that moment.\n */\nexport function fromEventPattern<T>(\n  addHandler: (handler: NodeEventHandler) => any,\n  removeHandler?: (handler: NodeEventHandler, signal?: any) => void,\n  resultSelector?: (...args: any[]) => T\n): Observable<T | T[]> {\n  if (resultSelector) {\n    return fromEventPattern<T>(addHandler, removeHandler).pipe(mapOneOrManyArgs(resultSelector));\n  }\n\n  return new Observable<T | T[]>((subscriber) => {\n    const handler = (...e: T[]) => subscriber.next(e.length === 1 ? e[0] : e);\n    const retValue = addHandler(handler);\n    return isFunction(removeHandler) ? () => removeHandler(handler, retValue) : undefined;\n  });\n}\n", "import { Observable } from '../Observable';\nimport { SchedulerLike } from '../types';\nimport { async as asyncScheduler } from '../scheduler/async';\nimport { isScheduler } from '../util/isScheduler';\nimport { isValidDate } from '../util/isDate';\n\n/**\n * Creates an observable that will wait for a specified time period, or exact date, before\n * emitting the number 0.\n *\n * <span class=\"informal\">Used to emit a notification after a delay.</span>\n *\n * This observable is useful for creating delays in code, or racing against other values\n * for ad-hoc timeouts.\n *\n * The `delay` is specified by default in milliseconds, however providing a custom scheduler could\n * create a different behavior.\n *\n * ## Examples\n *\n * Wait 3 seconds and start another observable\n *\n * You might want to use `timer` to delay subscription to an\n * observable by a set amount of time. Here we use a timer with\n * {@link concatMapTo} or {@link concatMap} in order to wait\n * a few seconds and start a subscription to a source.\n *\n * ```ts\n * import { of, timer, concatMap } from 'rxjs';\n *\n * // This could be any observable\n * const source = of(1, 2, 3);\n *\n * timer(3000)\n *   .pipe(concatMap(() => source))\n *   .subscribe(console.log);\n * ```\n *\n * Take all values until the start of the next minute\n *\n * Using a `Date` as the trigger for the first emission, you can\n * do things like wait until midnight to fire an event, or in this case,\n * wait until a new minute starts (chosen so the example wouldn't take\n * too long to run) in order to stop watching a stream. Leveraging\n * {@link takeUntil}.\n *\n * ```ts\n * import { interval, takeUntil, timer } from 'rxjs';\n *\n * // Build a Date object that marks the\n * // next minute.\n * const currentDate = new Date();\n * const startOfNextMinute = new Date(\n *   currentDate.getFullYear(),\n *   currentDate.getMonth(),\n *   currentDate.getDate(),\n *   currentDate.getHours(),\n *   currentDate.getMinutes() + 1\n * );\n *\n * // This could be any observable stream\n * const source = interval(1000);\n *\n * const result = source.pipe(\n *   takeUntil(timer(startOfNextMinute))\n * );\n *\n * result.subscribe(console.log);\n * ```\n *\n * ### Known Limitations\n *\n * - The {@link asyncScheduler} uses `setTimeout` which has limitations for how far in the future it can be scheduled.\n *\n * - If a `scheduler` is provided that returns a timestamp other than an epoch from `now()`, and\n * a `Date` object is passed to the `dueTime` argument, the calculation for when the first emission\n * should occur will be incorrect. In this case, it would be best to do your own calculations\n * ahead of time, and pass a `number` in as the `dueTime`.\n *\n * @param due If a `number`, the amount of time in milliseconds to wait before emitting.\n * If a `Date`, the exact time at which to emit.\n * @param scheduler The scheduler to use to schedule the delay. Defaults to {@link asyncScheduler}.\n */\nexport function timer(due: number | Date, scheduler?: SchedulerLike): Observable<0>;\n\n/**\n * Creates an observable that starts an interval after a specified delay, emitting incrementing numbers -- starting at `0` --\n * on each interval after words.\n *\n * The `delay` and `intervalDuration` are specified by default in milliseconds, however providing a custom scheduler could\n * create a different behavior.\n *\n * ## Example\n *\n * ### Start an interval that starts right away\n *\n * Since {@link interval} waits for the passed delay before starting,\n * sometimes that's not ideal. You may want to start an interval immediately.\n * `timer` works well for this. Here we have both side-by-side so you can\n * see them in comparison.\n *\n * Note that this observable will never complete.\n *\n * ```ts\n * import { timer, interval } from 'rxjs';\n *\n * timer(0, 1000).subscribe(n => console.log('timer', n));\n * interval(1000).subscribe(n => console.log('interval', n));\n * ```\n *\n * ### Known Limitations\n *\n * - The {@link asyncScheduler} uses `setTimeout` which has limitations for how far in the future it can be scheduled.\n *\n * - If a `scheduler` is provided that returns a timestamp other than an epoch from `now()`, and\n * a `Date` object is passed to the `dueTime` argument, the calculation for when the first emission\n * should occur will be incorrect. In this case, it would be best to do your own calculations\n * ahead of time, and pass a `number` in as the `startDue`.\n * @param startDue If a `number`, is the time to wait before starting the interval.\n * If a `Date`, is the exact time at which to start the interval.\n * @param intervalDuration The delay between each value emitted in the interval. Passing a\n * negative number here will result in immediate completion after the first value is emitted, as though\n * no `intervalDuration` was passed at all.\n * @param scheduler The scheduler to use to schedule the delay. Defaults to {@link asyncScheduler}.\n */\nexport function timer(startDue: number | Date, intervalDuration: number, scheduler?: SchedulerLike): Observable<number>;\n\n/**\n * @deprecated The signature allowing `undefined` to be passed for `intervalDuration` will be removed in v8. Use the `timer(dueTime, scheduler?)` signature instead.\n */\nexport function timer(dueTime: number | Date, unused: undefined, scheduler?: SchedulerLike): Observable<0>;\n\nexport function timer(\n  dueTime: number | Date = 0,\n  intervalOrScheduler?: number | SchedulerLike,\n  scheduler: SchedulerLike = asyncScheduler\n): Observable<number> {\n  // Since negative intervalDuration is treated as though no\n  // interval was specified at all, we start with a negative number.\n  let intervalDuration = -1;\n\n  if (intervalOrScheduler != null) {\n    // If we have a second argument, and it's a scheduler,\n    // override the scheduler we had defaulted. Otherwise,\n    // it must be an interval.\n    if (isScheduler(intervalOrScheduler)) {\n      scheduler = intervalOrScheduler;\n    } else {\n      // Note that this *could* be negative, in which case\n      // it's like not passing an intervalDuration at all.\n      intervalDuration = intervalOrScheduler;\n    }\n  }\n\n  return new Observable((subscriber) => {\n    // If a valid date is passed, calculate how long to wait before\n    // executing the first value... otherwise, if it's a number just schedule\n    // that many milliseconds (or scheduler-specified unit size) in the future.\n    let due = isValidDate(dueTime) ? +dueTime - scheduler!.now() : dueTime;\n\n    if (due < 0) {\n      // Ensure we don't schedule in the future.\n      due = 0;\n    }\n\n    // The incrementing value we emit.\n    let n = 0;\n\n    // Start the timer.\n    return scheduler.schedule(function () {\n      if (!subscriber.closed) {\n        // Emit the next value and increment.\n        subscriber.next(n++);\n\n        if (0 <= intervalDuration) {\n          // If we have a interval after the initial timer,\n          // reschedule with the period.\n          this.schedule(undefined, intervalDuration);\n        } else {\n          // We didn't have an interval. So just complete.\n          subscriber.complete();\n        }\n      }\n    }, due);\n  });\n}\n", "import { Observable } from '../Observable';\nimport { ObservableInput, ObservableInputTuple, SchedulerLike } from '../types';\nimport { mergeAll } from '../operators/mergeAll';\nimport { innerFrom } from './innerFrom';\nimport { EMPTY } from './empty';\nimport { popNumber, popScheduler } from '../util/args';\nimport { from } from './from';\n\nexport function merge<A extends readonly unknown[]>(...sources: [...ObservableInputTuple<A>]): Observable<A[number]>;\nexport function merge<A extends readonly unknown[]>(...sourcesAndConcurrency: [...ObservableInputTuple<A>, number?]): Observable<A[number]>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `mergeAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function merge<A extends readonly unknown[]>(\n  ...sourcesAndScheduler: [...ObservableInputTuple<A>, SchedulerLike?]\n): Observable<A[number]>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `mergeAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function merge<A extends readonly unknown[]>(\n  ...sourcesAndConcurrencyAndScheduler: [...ObservableInputTuple<A>, number?, SchedulerLike?]\n): Observable<A[number]>;\n\n/**\n * Creates an output Observable which concurrently emits all values from every\n * given input Observable.\n *\n * <span class=\"informal\">Flattens multiple Observables together by blending\n * their values into one Observable.</span>\n *\n * ![](merge.png)\n *\n * `merge` subscribes to each given input Observable (as arguments), and simply\n * forwards (without doing any transformation) all the values from all the input\n * Observables to the output Observable. The output Observable only completes\n * once all input Observables have completed. Any error delivered by an input\n * Observable will be immediately emitted on the output Observable.\n *\n * ## Examples\n *\n * Merge together two Observables: 1s interval and clicks\n *\n * ```ts\n * import { merge, fromEvent, interval } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const timer = interval(1000);\n * const clicksOrTimer = merge(clicks, timer);\n * clicksOrTimer.subscribe(x => console.log(x));\n *\n * // Results in the following:\n * // timer will emit ascending values, one every second(1000ms) to console\n * // clicks logs MouseEvents to console every time the \"document\" is clicked\n * // Since the two streams are merged you see these happening\n * // as they occur.\n * ```\n *\n * Merge together 3 Observables, but run only 2 concurrently\n *\n * ```ts\n * import { interval, take, merge } from 'rxjs';\n *\n * const timer1 = interval(1000).pipe(take(10));\n * const timer2 = interval(2000).pipe(take(6));\n * const timer3 = interval(500).pipe(take(10));\n *\n * const concurrent = 2; // the argument\n * const merged = merge(timer1, timer2, timer3, concurrent);\n * merged.subscribe(x => console.log(x));\n *\n * // Results in the following:\n * // - First timer1 and timer2 will run concurrently\n * // - timer1 will emit a value every 1000ms for 10 iterations\n * // - timer2 will emit a value every 2000ms for 6 iterations\n * // - after timer1 hits its max iteration, timer2 will\n * //   continue, and timer3 will start to run concurrently with timer2\n * // - when timer2 hits its max iteration it terminates, and\n * //   timer3 will continue to emit a value every 500ms until it is complete\n * ```\n *\n * @see {@link mergeAll}\n * @see {@link mergeMap}\n * @see {@link mergeMapTo}\n * @see {@link mergeScan}\n *\n * @param {...ObservableInput} observables Input Observables to merge together.\n * @param {number} [concurrent=Infinity] Maximum number of input\n * Observables being subscribed to concurrently.\n * @param {SchedulerLike} [scheduler=null] The {@link SchedulerLike} to use for managing\n * concurrency of input Observables.\n * @return {Observable} an Observable that emits items that are the result of\n * every input Observable.\n */\nexport function merge(...args: (ObservableInput<unknown> | number | SchedulerLike)[]): Observable<unknown> {\n  const scheduler = popScheduler(args);\n  const concurrent = popNumber(args, Infinity);\n  const sources = args as ObservableInput<unknown>[];\n  return !sources.length\n    ? // No source provided\n      EMPTY\n    : sources.length === 1\n    ? // One source? Just return it.\n      innerFrom(sources[0])\n    : // Merge all sources\n      mergeAll(concurrent)(from(sources, scheduler));\n}\n", "import { Observable } from '../Observable';\nimport { noop } from '../util/noop';\n\n/**\n * An Observable that emits no items to the Observer and never completes.\n *\n * ![](never.png)\n *\n * A simple Observable that emits neither values nor errors nor the completion\n * notification. It can be used for testing purposes or for composing with other\n * Observables. Please note that by never emitting a complete notification, this\n * Observable keeps the subscription from being disposed automatically.\n * Subscriptions need to be manually disposed.\n *\n * ##  Example\n *\n * Emit the number 7, then never emit anything else (not even complete)\n *\n * ```ts\n * import { NEVER, startWith } from 'rxjs';\n *\n * const info = () => console.log('Will not be called');\n *\n * const result = NEVER.pipe(startWith(7));\n * result.subscribe({\n *   next: x => console.log(x),\n *   error: info,\n *   complete: info\n * });\n * ```\n *\n * @see {@link Observable}\n * @see {@link EMPTY}\n * @see {@link of}\n * @see {@link throwError}\n */\nexport const NEVER = new Observable<never>(noop);\n\n/**\n * @deprecated Replaced with the {@link NEVER} constant. Will be removed in v8.\n */\nexport function never() {\n  return NEVER;\n}\n", "const { isArray } = Array;\n\n/**\n * Used in operators and functions that accept either a list of arguments, or an array of arguments\n * as a single argument.\n */\nexport function argsOrArgArray<T>(args: (T | T[])[]): T[] {\n  return args.length === 1 && isArray(args[0]) ? args[0] : (args as T[]);\n}\n", "import { OperatorFunction, MonoTypeOperatorFunction, TruthyTypesOf } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/** @deprecated Use a closure instead of a `thisArg`. Signatures accepting a `thisArg` will be removed in v8. */\nexport function filter<T, S extends T, A>(predicate: (this: A, value: T, index: number) => value is S, thisArg: A): OperatorFunction<T, S>;\nexport function filter<T, S extends T>(predicate: (value: T, index: number) => value is S): OperatorFunction<T, S>;\nexport function filter<T>(predicate: BooleanConstructor): OperatorFunction<T, TruthyTypesOf<T>>;\n/** @deprecated Use a closure instead of a `thisArg`. Signatures accepting a `thisArg` will be removed in v8. */\nexport function filter<T, A>(predicate: (this: A, value: T, index: number) => boolean, thisArg: A): MonoTypeOperatorFunction<T>;\nexport function filter<T>(predicate: (value: T, index: number) => boolean): MonoTypeOperatorFunction<T>;\n\n/**\n * Filter items emitted by the source Observable by only emitting those that\n * satisfy a specified predicate.\n *\n * <span class=\"informal\">Like\n * [Array.prototype.filter()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/filter),\n * it only emits a value from the source if it passes a criterion function.</span>\n *\n * ![](filter.png)\n *\n * Similar to the well-known `Array.prototype.filter` method, this operator\n * takes values from the source Observable, passes them through a `predicate`\n * function and only emits those values that yielded `true`.\n *\n * ## Example\n *\n * Emit only click events whose target was a DIV element\n *\n * ```ts\n * import { fromEvent, filter } from 'rxjs';\n *\n * const div = document.createElement('div');\n * div.style.cssText = 'width: 200px; height: 200px; background: #09c;';\n * document.body.appendChild(div);\n *\n * const clicks = fromEvent(document, 'click');\n * const clicksOnDivs = clicks.pipe(filter(ev => (<HTMLElement>ev.target).tagName === 'DIV'));\n * clicksOnDivs.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link distinct}\n * @see {@link distinctUntilChanged}\n * @see {@link distinctUntilKeyChanged}\n * @see {@link ignoreElements}\n * @see {@link partition}\n * @see {@link skip}\n *\n * @param predicate A function that\n * evaluates each value emitted by the source Observable. If it returns `true`,\n * the value is emitted, if `false` the value is not passed to the output\n * Observable. The `index` parameter is the number `i` for the i-th source\n * emission that has happened since the subscription, starting from the number\n * `0`.\n * @param thisArg An optional argument to determine the value of `this`\n * in the `predicate` function.\n * @return A function that returns an Observable that emits items from the\n * source Observable that satisfy the specified `predicate`.\n */\nexport function filter<T>(predicate: (value: T, index: number) => boolean, thisArg?: any): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    // An index passed to our predicate function on each call.\n    let index = 0;\n\n    // Subscribe to the source, all errors and completions are\n    // forwarded to the consumer.\n    source.subscribe(\n      // Call the predicate with the appropriate `this` context,\n      // if the predicate returns `true`, then send the value\n      // to the consumer.\n      createOperatorSubscriber(subscriber, (value) => predicate.call(thisArg, value, index++) && subscriber.next(value))\n    );\n  });\n}\n", "import { Observable } from '../Observable';\nimport { ObservableInputTuple } from '../types';\nimport { innerFrom } from './innerFrom';\nimport { argsOrArgArray } from '../util/argsOrArgArray';\nimport { EMPTY } from './empty';\nimport { createOperatorSubscriber } from '../operators/OperatorSubscriber';\nimport { popResultSelector } from '../util/args';\n\nexport function zip<A extends readonly unknown[]>(sources: [...ObservableInputTuple<A>]): Observable<A>;\nexport function zip<A extends readonly unknown[], R>(\n  sources: [...ObservableInputTuple<A>],\n  resultSelector: (...values: A) => R\n): Observable<R>;\nexport function zip<A extends readonly unknown[]>(...sources: [...ObservableInputTuple<A>]): Observable<A>;\nexport function zip<A extends readonly unknown[], R>(\n  ...sourcesAndResultSelector: [...ObservableInputTuple<A>, (...values: A) => R]\n): Observable<R>;\n\n/**\n * Combines multiple Observables to create an Observable whose values are calculated from the values, in order, of each\n * of its input Observables.\n *\n * If the last parameter is a function, this function is used to compute the created value from the input values.\n * Otherwise, an array of the input values is returned.\n *\n * ## Example\n *\n * Combine age and name from different sources\n *\n * ```ts\n * import { of, zip, map } from 'rxjs';\n *\n * const age$ = of(27, 25, 29);\n * const name$ = of('Foo', 'Bar', 'Beer');\n * const isDev$ = of(true, true, false);\n *\n * zip(age$, name$, isDev$).pipe(\n *   map(([age, name, isDev]) => ({ age, name, isDev }))\n * )\n * .subscribe(x => console.log(x));\n *\n * // Outputs\n * // { age: 27, name: 'Foo', isDev: true }\n * // { age: 25, name: 'Bar', isDev: true }\n * // { age: 29, name: 'Beer', isDev: false }\n * ```\n *\n * @param sources\n * @return {Observable<R>}\n */\nexport function zip(...args: unknown[]): Observable<unknown> {\n  const resultSelector = popResultSelector(args);\n\n  const sources = argsOrArgArray(args) as Observable<unknown>[];\n\n  return sources.length\n    ? new Observable<unknown[]>((subscriber) => {\n        // A collection of buffers of values from each source.\n        // Keyed by the same index with which the sources were passed in.\n        let buffers: unknown[][] = sources.map(() => []);\n\n        // An array of flags of whether or not the sources have completed.\n        // This is used to check to see if we should complete the result.\n        // Keyed by the same index with which the sources were passed in.\n        let completed = sources.map(() => false);\n\n        // When everything is done, release the arrays above.\n        subscriber.add(() => {\n          buffers = completed = null!;\n        });\n\n        // Loop over our sources and subscribe to each one. The index `i` is\n        // especially important here, because we use it in closures below to\n        // access the related buffers and completion properties\n        for (let sourceIndex = 0; !subscriber.closed && sourceIndex < sources.length; sourceIndex++) {\n          innerFrom(sources[sourceIndex]).subscribe(\n            createOperatorSubscriber(\n              subscriber,\n              (value) => {\n                buffers[sourceIndex].push(value);\n                // if every buffer has at least one value in it, then we\n                // can shift out the oldest value from each buffer and emit\n                // them as an array.\n                if (buffers.every((buffer) => buffer.length)) {\n                  const result: any = buffers.map((buffer) => buffer.shift()!);\n                  // Emit the array. If theres' a result selector, use that.\n                  subscriber.next(resultSelector ? resultSelector(...result) : result);\n                  // If any one of the sources is both complete and has an empty buffer\n                  // then we complete the result. This is because we cannot possibly have\n                  // any more values to zip together.\n                  if (buffers.some((buffer, i) => !buffer.length && completed[i])) {\n                    subscriber.complete();\n                  }\n                }\n              },\n              () => {\n                // This source completed. Mark it as complete so we can check it later\n                // if we have to.\n                completed[sourceIndex] = true;\n                // But, if this complete source has nothing in its buffer, then we\n                // can complete the result, because we can't possibly have any more\n                // values from this to zip together with the other values.\n                !buffers[sourceIndex].length && subscriber.complete();\n              }\n            )\n          );\n        }\n\n        // When everything is done, release the arrays above.\n        return () => {\n          buffers = completed = null!;\n        };\n      })\n    : EMPTY;\n}\n", "import { Subscriber } from '../Subscriber';\nimport { MonoTypeOperatorFunction, ObservableInput } from '../types';\n\nimport { operate } from '../util/lift';\nimport { innerFrom } from '../observable/innerFrom';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * Ignores source values for a duration determined by another Observable, then\n * emits the most recent value from the source Observable, then repeats this\n * process.\n *\n * <span class=\"informal\">It's like {@link auditTime}, but the silencing\n * duration is determined by a second Observable.</span>\n *\n * ![](audit.svg)\n *\n * `audit` is similar to `throttle`, but emits the last value from the silenced\n * time window, instead of the first value. `audit` emits the most recent value\n * from the source Observable on the output Observable as soon as its internal\n * timer becomes disabled, and ignores source values while the timer is enabled.\n * Initially, the timer is disabled. As soon as the first source value arrives,\n * the timer is enabled by calling the `durationSelector` function with the\n * source value, which returns the \"duration\" Observable. When the duration\n * Observable emits a value, the timer is disabled, then the most\n * recent source value is emitted on the output Observable, and this process\n * repeats for the next source value.\n *\n * ## Example\n *\n * Emit clicks at a rate of at most one click per second\n *\n * ```ts\n * import { fromEvent, audit, interval } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(audit(ev => interval(1000)));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link auditTime}\n * @see {@link debounce}\n * @see {@link delayWhen}\n * @see {@link sample}\n * @see {@link throttle}\n *\n * @param durationSelector A function\n * that receives a value from the source Observable, for computing the silencing\n * duration, returned as an Observable or a Promise.\n * @return A function that returns an Observable that performs rate-limiting of\n * emissions from the source Observable.\n */\nexport function audit<T>(durationSelector: (value: T) => ObservableInput<any>): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    let hasValue = false;\n    let lastValue: T | null = null;\n    let durationSubscriber: Subscriber<any> | null = null;\n    let isComplete = false;\n\n    const endDuration = () => {\n      durationSubscriber?.unsubscribe();\n      durationSubscriber = null;\n      if (hasValue) {\n        hasValue = false;\n        const value = lastValue!;\n        lastValue = null;\n        subscriber.next(value);\n      }\n      isComplete && subscriber.complete();\n    };\n\n    const cleanupDuration = () => {\n      durationSubscriber = null;\n      isComplete && subscriber.complete();\n    };\n\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value) => {\n          hasValue = true;\n          lastValue = value;\n          if (!durationSubscriber) {\n            innerFrom(durationSelector(value)).subscribe(\n              (durationSubscriber = createOperatorSubscriber(subscriber, endDuration, cleanupDuration))\n            );\n          }\n        },\n        () => {\n          isComplete = true;\n          (!hasValue || !durationSubscriber || durationSubscriber.closed) && subscriber.complete();\n        }\n      )\n    );\n  });\n}\n", "import { asyncScheduler } from '../scheduler/async';\nimport { audit } from './audit';\nimport { timer } from '../observable/timer';\nimport { MonoTypeOperatorFunction, SchedulerLike } from '../types';\n\n/**\n * Ignores source values for `duration` milliseconds, then emits the most recent\n * value from the source Observable, then repeats this process.\n *\n * <span class=\"informal\">When it sees a source value, it ignores that plus\n * the next ones for `duration` milliseconds, and then it emits the most recent\n * value from the source.</span>\n *\n * ![](auditTime.png)\n *\n * `auditTime` is similar to `throttleTime`, but emits the last value from the\n * silenced time window, instead of the first value. `auditTime` emits the most\n * recent value from the source Observable on the output Observable as soon as\n * its internal timer becomes disabled, and ignores source values while the\n * timer is enabled. Initially, the timer is disabled. As soon as the first\n * source value arrives, the timer is enabled. After `duration` milliseconds (or\n * the time unit determined internally by the optional `scheduler`) has passed,\n * the timer is disabled, then the most recent source value is emitted on the\n * output Observable, and this process repeats for the next source value.\n * Optionally takes a {@link SchedulerLike} for managing timers.\n *\n * ## Example\n *\n * Emit clicks at a rate of at most one click per second\n *\n * ```ts\n * import { fromEvent, auditTime } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(auditTime(1000));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link audit}\n * @see {@link debounceTime}\n * @see {@link delay}\n * @see {@link sampleTime}\n * @see {@link throttleTime}\n *\n * @param {number} duration Time to wait before emitting the most recent source\n * value, measured in milliseconds or the time unit determined internally\n * by the optional `scheduler`.\n * @param {SchedulerLike} [scheduler=async] The {@link SchedulerLike} to use for\n * managing the timers that handle the rate-limiting behavior.\n * @return A function that returns an Observable that performs rate-limiting of\n * emissions from the source Observable.\n */\nexport function auditTime<T>(duration: number, scheduler: SchedulerLike = asyncScheduler): MonoTypeOperatorFunction<T> {\n  return audit(() => timer(duration, scheduler));\n}\n", "import { OperatorFunction } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { arrRemove } from '../util/arrRemove';\n\n/**\n * Buffers the source Observable values until the size hits the maximum\n * `bufferSize` given.\n *\n * <span class=\"informal\">Collects values from the past as an array, and emits\n * that array only when its size reaches `bufferSize`.</span>\n *\n * ![](bufferCount.png)\n *\n * Buffers a number of values from the source Observable by `bufferSize` then\n * emits the buffer and clears it, and starts a new buffer each\n * `startBufferEvery` values. If `startBufferEvery` is not provided or is\n * `null`, then new buffers are started immediately at the start of the source\n * and when each buffer closes and is emitted.\n *\n * ## Examples\n *\n * Emit the last two click events as an array\n *\n * ```ts\n * import { fromEvent, bufferCount } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const buffered = clicks.pipe(bufferCount(2));\n * buffered.subscribe(x => console.log(x));\n * ```\n *\n * On every click, emit the last two click events as an array\n *\n * ```ts\n * import { fromEvent, bufferCount } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const buffered = clicks.pipe(bufferCount(2, 1));\n * buffered.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link buffer}\n * @see {@link bufferTime}\n * @see {@link bufferToggle}\n * @see {@link bufferWhen}\n * @see {@link pairwise}\n * @see {@link windowCount}\n *\n * @param {number} bufferSize The maximum size of the buffer emitted.\n * @param {number} [startBufferEvery] Interval at which to start a new buffer.\n * For example if `startBufferEvery` is `2`, then a new buffer will be started\n * on every other value from the source. A new buffer is started at the\n * beginning of the source by default.\n * @return A function that returns an Observable of arrays of buffered values.\n */\nexport function bufferCount<T>(bufferSize: number, startBufferEvery: number | null = null): OperatorFunction<T, T[]> {\n  // If no `startBufferEvery` value was supplied, then we're\n  // opening and closing on the bufferSize itself.\n  startBufferEvery = startBufferEvery ?? bufferSize;\n\n  return operate((source, subscriber) => {\n    let buffers: T[][] = [];\n    let count = 0;\n\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value) => {\n          let toEmit: T[][] | null = null;\n\n          // Check to see if we need to start a buffer.\n          // This will start one at the first value, and then\n          // a new one every N after that.\n          if (count++ % startBufferEvery! === 0) {\n            buffers.push([]);\n          }\n\n          // Push our value into our active buffers.\n          for (const buffer of buffers) {\n            buffer.push(value);\n            // Check to see if we're over the bufferSize\n            // if we are, record it so we can emit it later.\n            // If we emitted it now and removed it, it would\n            // mutate the `buffers` array while we're looping\n            // over it.\n            if (bufferSize <= buffer.length) {\n              toEmit = toEmit ?? [];\n              toEmit.push(buffer);\n            }\n          }\n\n          if (toEmit) {\n            // We have found some buffers that are over the\n            // `bufferSize`. Emit them, and remove them from our\n            // buffers list.\n            for (const buffer of toEmit) {\n              arrRemove(buffers, buffer);\n              subscriber.next(buffer);\n            }\n          }\n        },\n        () => {\n          // When the source completes, emit all of our\n          // active buffers.\n          for (const buffer of buffers) {\n            subscriber.next(buffer);\n          }\n          subscriber.complete();\n        },\n        // Pass all errors through to consumer.\n        undefined,\n        () => {\n          // Clean up our memory when we finalize\n          buffers = null!;\n        }\n      )\n    );\n  });\n}\n", "import { Observable } from '../Observable';\n\nimport { ObservableInput, OperatorFunction, ObservedValueOf } from '../types';\nimport { Subscription } from '../Subscription';\nimport { innerFrom } from '../observable/innerFrom';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { operate } from '../util/lift';\n\n/* tslint:disable:max-line-length */\nexport function catchError<T, O extends ObservableInput<any>>(\n  selector: (err: any, caught: Observable<T>) => O\n): OperatorFunction<T, T | ObservedValueOf<O>>;\n/* tslint:enable:max-line-length */\n\n/**\n * Catches errors on the observable to be handled by returning a new observable or throwing an error.\n *\n * <span class=\"informal\">\n * It only listens to the error channel and ignores notifications.\n * Handles errors from the source observable, and maps them to a new observable.\n * The error may also be rethrown, or a new error can be thrown to emit an error from the result.\n * </span>\n *\n * ![](catch.png)\n *\n * This operator handles errors, but forwards along all other events to the resulting observable.\n * If the source observable terminates with an error, it will map that error to a new observable,\n * subscribe to it, and forward all of its events to the resulting observable.\n *\n * ## Examples\n *\n * Continue with a different Observable when there's an error\n *\n * ```ts\n * import { of, map, catchError } from 'rxjs';\n *\n * of(1, 2, 3, 4, 5)\n *   .pipe(\n *     map(n => {\n *       if (n === 4) {\n *         throw 'four!';\n *       }\n *       return n;\n *     }),\n *     catchError(err => of('I', 'II', 'III', 'IV', 'V'))\n *   )\n *   .subscribe(x => console.log(x));\n *   // 1, 2, 3, I, II, III, IV, V\n * ```\n *\n * Retry the caught source Observable again in case of error, similar to `retry()` operator\n *\n * ```ts\n * import { of, map, catchError, take } from 'rxjs';\n *\n * of(1, 2, 3, 4, 5)\n *   .pipe(\n *     map(n => {\n *       if (n === 4) {\n *         throw 'four!';\n *       }\n *       return n;\n *     }),\n *     catchError((err, caught) => caught),\n *     take(30)\n *   )\n *   .subscribe(x => console.log(x));\n *   // 1, 2, 3, 1, 2, 3, ...\n * ```\n *\n * Throw a new error when the source Observable throws an error\n *\n * ```ts\n * import { of, map, catchError } from 'rxjs';\n *\n * of(1, 2, 3, 4, 5)\n *   .pipe(\n *     map(n => {\n *       if (n === 4) {\n *         throw 'four!';\n *       }\n *       return n;\n *     }),\n *     catchError(err => {\n *       throw 'error in source. Details: ' + err;\n *     })\n *   )\n *   .subscribe({\n *     next: x => console.log(x),\n *     error: err => console.log(err)\n *   });\n *   // 1, 2, 3, error in source. Details: four!\n * ```\n *\n * @see {@link onErrorResumeNext}\n * @see {@link repeat}\n * @see {@link repeatWhen}\n * @see {@link retry }\n * @see {@link retryWhen}\n *\n * @param {function} selector a function that takes as arguments `err`, which is the error, and `caught`, which\n * is the source observable, in case you'd like to \"retry\" that observable by returning it again. Whatever observable\n * is returned by the `selector` will be used to continue the observable chain.\n * @return A function that returns an Observable that originates from either\n * the source or the Observable returned by the `selector` function.\n */\nexport function catchError<T, O extends ObservableInput<any>>(\n  selector: (err: any, caught: Observable<T>) => O\n): OperatorFunction<T, T | ObservedValueOf<O>> {\n  return operate((source, subscriber) => {\n    let innerSub: Subscription | null = null;\n    let syncUnsub = false;\n    let handledResult: Observable<ObservedValueOf<O>>;\n\n    innerSub = source.subscribe(\n      createOperatorSubscriber(subscriber, undefined, undefined, (err) => {\n        handledResult = innerFrom(selector(err, catchError(selector)(source)));\n        if (innerSub) {\n          innerSub.unsubscribe();\n          innerSub = null;\n          handledResult.subscribe(subscriber);\n        } else {\n          // We don't have an innerSub yet, that means the error was synchronous\n          // because the subscribe call hasn't returned yet.\n          syncUnsub = true;\n        }\n      })\n    );\n\n    if (syncUnsub) {\n      // We have a synchronous error, we need to make sure to\n      // finalize right away. This ensures that callbacks in the `finalize` operator are called\n      // at the right time, and that finalization occurs at the expected\n      // time between the source error and the subscription to the\n      // next observable.\n      innerSub.unsubscribe();\n      innerSub = null;\n      handledResult!.subscribe(subscriber);\n    }\n  });\n}\n", "import { Observable } from '../Observable';\nimport { Subscriber } from '../Subscriber';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * A basic scan operation. This is used for `scan` and `reduce`.\n * @param accumulator The accumulator to use\n * @param seed The seed value for the state to accumulate\n * @param hasSeed Whether or not a seed was provided\n * @param emitOnNext Whether or not to emit the state on next\n * @param emitBeforeComplete Whether or not to emit the before completion\n */\n\nexport function scanInternals<V, A, S>(\n  accumulator: (acc: V | A | S, value: V, index: number) => A,\n  seed: S,\n  hasSeed: boolean,\n  emitOnNext: boolean,\n  emitBeforeComplete?: undefined | true\n) {\n  return (source: Observable<V>, subscriber: Subscriber<any>) => {\n    // Whether or not we have state yet. This will only be\n    // false before the first value arrives if we didn't get\n    // a seed value.\n    let hasState = hasSeed;\n    // The state that we're tracking, starting with the seed,\n    // if there is one, and then updated by the return value\n    // from the accumulator on each emission.\n    let state: any = seed;\n    // An index to pass to the accumulator function.\n    let index = 0;\n\n    // Subscribe to our source. All errors and completions are passed through.\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value) => {\n          // Always increment the index.\n          const i = index++;\n          // Set the state\n          state = hasState\n            ? // We already have state, so we can get the new state from the accumulator\n              accumulator(state, value, i)\n            : // We didn't have state yet, a seed value was not provided, so\n\n              // we set the state to the first value, and mark that we have state now\n              ((hasState = true), value);\n\n          // Maybe send it to the consumer.\n          emitOnNext && subscriber.next(state);\n        },\n        // If an onComplete was given, call it, otherwise\n        // just pass through the complete notification to the consumer.\n        emitBeforeComplete &&\n          (() => {\n            hasState && subscriber.next(state);\n            subscriber.complete();\n          })\n      )\n    );\n  };\n}\n", "import { combineLatestInit } from '../observable/combineLatest';\nimport { ObservableInput, ObservableInputTuple, OperatorFunction } from '../types';\nimport { operate } from '../util/lift';\nimport { argsOrArgArray } from '../util/argsOrArgArray';\nimport { mapOneOrManyArgs } from '../util/mapOneOrManyArgs';\nimport { pipe } from '../util/pipe';\nimport { popResultSelector } from '../util/args';\n\n/** @deprecated Replaced with {@link combineLatestWith}. Will be removed in v8. */\nexport function combineLatest<T, A extends readonly unknown[], R>(\n  sources: [...ObservableInputTuple<A>],\n  project: (...values: [T, ...A]) => R\n): OperatorFunction<T, R>;\n/** @deprecated Replaced with {@link combineLatestWith}. Will be removed in v8. */\nexport function combineLatest<T, A extends readonly unknown[], R>(sources: [...ObservableInputTuple<A>]): OperatorFunction<T, [T, ...A]>;\n\n/** @deprecated Replaced with {@link combineLatestWith}. Will be removed in v8. */\nexport function combineLatest<T, A extends readonly unknown[], R>(\n  ...sourcesAndProject: [...ObservableInputTuple<A>, (...values: [T, ...A]) => R]\n): OperatorFunction<T, R>;\n/** @deprecated Replaced with {@link combineLatestWith}. Will be removed in v8. */\nexport function combineLatest<T, A extends readonly unknown[], R>(...sources: [...ObservableInputTuple<A>]): OperatorFunction<T, [T, ...A]>;\n\n/**\n * @deprecated Replaced with {@link combineLatestWith}. Will be removed in v8.\n */\nexport function combineLatest<T, R>(...args: (ObservableInput<any> | ((...values: any[]) => R))[]): OperatorFunction<T, unknown> {\n  const resultSelector = popResultSelector(args);\n  return resultSelector\n    ? pipe(combineLatest(...(args as Array<ObservableInput<any>>)), mapOneOrManyArgs(resultSelector))\n    : operate((source, subscriber) => {\n        combineLatestInit([source, ...argsOrArgArray(args)])(subscriber);\n      });\n}\n", "import { ObservableInputTuple, OperatorFunction, Cons } from '../types';\nimport { combineLatest } from './combineLatest';\n\n/**\n * Create an observable that combines the latest values from all passed observables and the source\n * into arrays and emits them.\n *\n * Returns an observable, that when subscribed to, will subscribe to the source observable and all\n * sources provided as arguments. Once all sources emit at least one value, all of the latest values\n * will be emitted as an array. After that, every time any source emits a value, all of the latest values\n * will be emitted as an array.\n *\n * This is a useful operator for eagerly calculating values based off of changed inputs.\n *\n * ## Example\n *\n * Simple concatenation of values from two inputs\n *\n * ```ts\n * import { fromEvent, combineLatestWith, map } from 'rxjs';\n *\n * // Setup: Add two inputs to the page\n * const input1 = document.createElement('input');\n * document.body.appendChild(input1);\n * const input2 = document.createElement('input');\n * document.body.appendChild(input2);\n *\n * // Get streams of changes\n * const input1Changes$ = fromEvent(input1, 'change');\n * const input2Changes$ = fromEvent(input2, 'change');\n *\n * // Combine the changes by adding them together\n * input1Changes$.pipe(\n *   combineLatestWith(input2Changes$),\n *   map(([e1, e2]) => (<HTMLInputElement>e1.target).value + ' - ' + (<HTMLInputElement>e2.target).value)\n * )\n * .subscribe(x => console.log(x));\n * ```\n *\n * @param otherSources the other sources to subscribe to.\n * @return A function that returns an Observable that emits the latest\n * emissions from both source and provided Observables.\n */\nexport function combineLatestWith<T, A extends readonly unknown[]>(\n  ...otherSources: [...ObservableInputTuple<A>]\n): OperatorFunction<T, Cons<T, A>> {\n  return combineLatest(...otherSources);\n}\n", "import { Subscriber } from '../Subscriber';\nimport { MonoTypeOperatorFunction, ObservableInput } from '../types';\nimport { operate } from '../util/lift';\nimport { noop } from '../util/noop';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { innerFrom } from '../observable/innerFrom';\n\n/**\n * Emits a notification from the source Observable only after a particular time span\n * determined by another Observable has passed without another source emission.\n *\n * <span class=\"informal\">It's like {@link debounceTime}, but the time span of\n * emission silence is determined by a second Observable.</span>\n *\n * ![](debounce.svg)\n *\n * `debounce` delays notifications emitted by the source Observable, but drops previous\n * pending delayed emissions if a new notification arrives on the source Observable.\n * This operator keeps track of the most recent notification from the source\n * Observable, and spawns a duration Observable by calling the\n * `durationSelector` function. The notification is emitted only when the duration\n * Observable emits a next notification, and if no other notification was emitted on\n * the source Observable since the duration Observable was spawned. If a new\n * notification appears before the duration Observable emits, the previous notification will\n * not be emitted and a new duration is scheduled from `durationSelector` is scheduled.\n * If the completing event happens during the scheduled duration the last cached notification\n * is emitted before the completion event is forwarded to the output observable.\n * If the error event happens during the scheduled duration or after it only the error event is\n * forwarded to the output observable. The cache notification is not emitted in this case.\n *\n * Like {@link debounceTime}, this is a rate-limiting operator, and also a\n * delay-like operator since output emissions do not necessarily occur at the\n * same time as they did on the source Observable.\n *\n * ## Example\n *\n * Emit the most recent click after a burst of clicks\n *\n * ```ts\n * import { fromEvent, scan, debounce, interval } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(\n *   scan(i => ++i, 1),\n *   debounce(i => interval(200 * i))\n * );\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link audit}\n * @see {@link auditTime}\n * @see {@link debounceTime}\n * @see {@link delay}\n * @see {@link sample}\n * @see {@link sampleTime}\n * @see {@link throttle}\n * @see {@link throttleTime}\n *\n * @param durationSelector A function\n * that receives a value from the source Observable, for computing the timeout\n * duration for each source value, returned as an Observable or a Promise.\n * @return A function that returns an Observable that delays the emissions of\n * the source Observable by the specified duration Observable returned by\n * `durationSelector`, and may drop some values if they occur too frequently.\n */\nexport function debounce<T>(durationSelector: (value: T) => ObservableInput<any>): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    let hasValue = false;\n    let lastValue: T | null = null;\n    // The subscriber/subscription for the current debounce, if there is one.\n    let durationSubscriber: Subscriber<any> | null = null;\n\n    const emit = () => {\n      // Unsubscribe any current debounce subscription we have,\n      // we only cared about the first notification from it, and we\n      // want to clean that subscription up as soon as possible.\n      durationSubscriber?.unsubscribe();\n      durationSubscriber = null;\n      if (hasValue) {\n        // We have a value! Free up memory first, then emit the value.\n        hasValue = false;\n        const value = lastValue!;\n        lastValue = null;\n        subscriber.next(value);\n      }\n    };\n\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value: T) => {\n          // Cancel any pending debounce duration. We don't\n          // need to null it out here yet tho, because we're just going\n          // to create another one in a few lines.\n          durationSubscriber?.unsubscribe();\n          hasValue = true;\n          lastValue = value;\n          // Capture our duration subscriber, so we can unsubscribe it when we're notified\n          // and we're going to emit the value.\n          durationSubscriber = createOperatorSubscriber(subscriber, emit, noop);\n          // Subscribe to the duration.\n          innerFrom(durationSelector(value)).subscribe(durationSubscriber);\n        },\n        () => {\n          // Source completed.\n          // Emit any pending debounced values then complete\n          emit();\n          subscriber.complete();\n        },\n        // Pass all errors through to consumer\n        undefined,\n        () => {\n          // Finalization.\n          lastValue = durationSubscriber = null;\n        }\n      )\n    );\n  });\n}\n", "import { asyncScheduler } from '../scheduler/async';\nimport { Subscription } from '../Subscription';\nimport { MonoTypeOperatorFunction, SchedulerAction, SchedulerLike } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * Emits a notification from the source Observable only after a particular time span\n * has passed without another source emission.\n *\n * <span class=\"informal\">It's like {@link delay}, but passes only the most\n * recent notification from each burst of emissions.</span>\n *\n * ![](debounceTime.png)\n *\n * `debounceTime` delays notifications emitted by the source Observable, but drops\n * previous pending delayed emissions if a new notification arrives on the source\n * Observable. This operator keeps track of the most recent notification from the\n * source Observable, and emits that only when `dueTime` has passed\n * without any other notification appearing on the source Observable. If a new value\n * appears before `dueTime` silence occurs, the previous notification will be dropped\n * and will not be emitted and a new `dueTime` is scheduled.\n * If the completing event happens during `dueTime` the last cached notification\n * is emitted before the completion event is forwarded to the output observable.\n * If the error event happens during `dueTime` or after it only the error event is\n * forwarded to the output observable. The cache notification is not emitted in this case.\n *\n * This is a rate-limiting operator, because it is impossible for more than one\n * notification to be emitted in any time window of duration `dueTime`, but it is also\n * a delay-like operator since output emissions do not occur at the same time as\n * they did on the source Observable. Optionally takes a {@link SchedulerLike} for\n * managing timers.\n *\n * ## Example\n *\n * Emit the most recent click after a burst of clicks\n *\n * ```ts\n * import { fromEvent, debounceTime } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(debounceTime(1000));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link audit}\n * @see {@link auditTime}\n * @see {@link debounce}\n * @see {@link sample}\n * @see {@link sampleTime}\n * @see {@link throttle}\n * @see {@link throttleTime}\n *\n * @param {number} dueTime The timeout duration in milliseconds (or the time\n * unit determined internally by the optional `scheduler`) for the window of\n * time required to wait for emission silence before emitting the most recent\n * source value.\n * @param {SchedulerLike} [scheduler=async] The {@link SchedulerLike} to use for\n * managing the timers that handle the timeout for each value.\n * @return A function that returns an Observable that delays the emissions of\n * the source Observable by the specified `dueTime`, and may drop some values\n * if they occur too frequently.\n */\nexport function debounceTime<T>(dueTime: number, scheduler: SchedulerLike = asyncScheduler): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    let activeTask: Subscription | null = null;\n    let lastValue: T | null = null;\n    let lastTime: number | null = null;\n\n    const emit = () => {\n      if (activeTask) {\n        // We have a value! Free up memory first, then emit the value.\n        activeTask.unsubscribe();\n        activeTask = null;\n        const value = lastValue!;\n        lastValue = null;\n        subscriber.next(value);\n      }\n    };\n    function emitWhenIdle(this: SchedulerAction<unknown>) {\n      // This is called `dueTime` after the first value\n      // but we might have received new values during this window!\n\n      const targetTime = lastTime! + dueTime;\n      const now = scheduler.now();\n      if (now < targetTime) {\n        // On that case, re-schedule to the new target\n        activeTask = this.schedule(undefined, targetTime - now);\n        subscriber.add(activeTask);\n        return;\n      }\n\n      emit();\n    }\n\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value: T) => {\n          lastValue = value;\n          lastTime = scheduler.now();\n\n          // Only set up a task if it's not already up\n          if (!activeTask) {\n            activeTask = scheduler.schedule(emitWhenIdle, dueTime);\n            subscriber.add(activeTask);\n          }\n        },\n        () => {\n          // Source completed.\n          // Emit any pending debounced values then complete\n          emit();\n          subscriber.complete();\n        },\n        // Pass all errors through to consumer.\n        undefined,\n        () => {\n          // Finalization.\n          lastValue = activeTask = null;\n        }\n      )\n    );\n  });\n}\n", "import { OperatorFunction } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * Emits a given value if the source Observable completes without emitting any\n * `next` value, otherwise mirrors the source Observable.\n *\n * <span class=\"informal\">If the source Observable turns out to be empty, then\n * this operator will emit a default value.</span>\n *\n * ![](defaultIfEmpty.png)\n *\n * `defaultIfEmpty` emits the values emitted by the source Observable or a\n * specified default value if the source Observable is empty (completes without\n * having emitted any `next` value).\n *\n * ## Example\n *\n * If no clicks happen in 5 seconds, then emit 'no clicks'\n *\n * ```ts\n * import { fromEvent, takeUntil, interval, defaultIfEmpty } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const clicksBeforeFive = clicks.pipe(takeUntil(interval(5000)));\n * const result = clicksBeforeFive.pipe(defaultIfEmpty('no clicks'));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link empty}\n * @see {@link last}\n *\n * @param defaultValue The default value used if the source\n * Observable is empty.\n * @return A function that returns an Observable that emits either the\n * specified `defaultValue` if the source Observable emits no items, or the\n * values emitted by the source Observable.\n */\nexport function defaultIfEmpty<T, R>(defaultValue: R): OperatorFunction<T, T | R> {\n  return operate((source, subscriber) => {\n    let hasValue = false;\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value) => {\n          hasValue = true;\n          subscriber.next(value);\n        },\n        () => {\n          if (!hasValue) {\n            subscriber.next(defaultValue!);\n          }\n          subscriber.complete();\n        }\n      )\n    );\n  });\n}\n", "import { MonoTypeOperatorFunction } from '../types';\nimport { EMPTY } from '../observable/empty';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * Emits only the first `count` values emitted by the source Observable.\n *\n * <span class=\"informal\">Takes the first `count` values from the source, then\n * completes.</span>\n *\n * ![](take.png)\n *\n * `take` returns an Observable that emits only the first `count` values emitted\n * by the source Observable. If the source emits fewer than `count` values then\n * all of its values are emitted. After that, it completes, regardless if the\n * source completes.\n *\n * ## Example\n *\n * Take the first 5 seconds of an infinite 1-second interval Observable\n *\n * ```ts\n * import { interval, take } from 'rxjs';\n *\n * const intervalCount = interval(1000);\n * const takeFive = intervalCount.pipe(take(5));\n * takeFive.subscribe(x => console.log(x));\n *\n * // Logs:\n * // 0\n * // 1\n * // 2\n * // 3\n * // 4\n * ```\n *\n * @see {@link takeLast}\n * @see {@link takeUntil}\n * @see {@link takeWhile}\n * @see {@link skip}\n *\n * @param count The maximum number of `next` values to emit.\n * @return A function that returns an Observable that emits only the first\n * `count` values emitted by the source Observable, or all of the values from\n * the source if the source emits fewer than `count` values.\n */\nexport function take<T>(count: number): MonoTypeOperatorFunction<T> {\n  return count <= 0\n    ? // If we are taking no values, that's empty.\n      () => EMPTY\n    : operate((source, subscriber) => {\n        let seen = 0;\n        source.subscribe(\n          createOperatorSubscriber(subscriber, (value) => {\n            // Increment the number of values we have seen,\n            // then check it against the allowed count to see\n            // if we are still letting values through.\n            if (++seen <= count) {\n              subscriber.next(value);\n              // If we have met or passed our allowed count,\n              // we need to complete. We have to do <= here,\n              // because re-entrant code will increment `seen` twice.\n              if (count <= seen) {\n                subscriber.complete();\n              }\n            }\n          })\n        );\n      });\n}\n", "import { OperatorFunction } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { noop } from '../util/noop';\n\n/**\n * Ignores all items emitted by the source Observable and only passes calls of `complete` or `error`.\n *\n * ![](ignoreElements.png)\n *\n * The `ignoreElements` operator suppresses all items emitted by the source Observable,\n * but allows its termination notification (either `error` or `complete`) to pass through unchanged.\n *\n * If you do not care about the items being emitted by an Observable, but you do want to be notified\n * when it completes or when it terminates with an error, you can apply the `ignoreElements` operator\n * to the Observable, which will ensure that it will never call its observers\u2019 `next` handlers.\n *\n * ## Example\n *\n * Ignore all `next` emissions from the source\n *\n * ```ts\n * import { of, ignoreElements } from 'rxjs';\n *\n * of('you', 'talking', 'to', 'me')\n *   .pipe(ignoreElements())\n *   .subscribe({\n *     next: word => console.log(word),\n *     error: err => console.log('error:', err),\n *     complete: () => console.log('the end'),\n *   });\n *\n * // result:\n * // 'the end'\n * ```\n *\n * @return A function that returns an empty Observable that only calls\n * `complete` or `error`, based on which one is called by the source\n * Observable.\n */\nexport function ignoreElements(): OperatorFunction<unknown, never> {\n  return operate((source, subscriber) => {\n    source.subscribe(createOperatorSubscriber(subscriber, noop));\n  });\n}\n", "import { OperatorFunction } from '../types';\nimport { map } from './map';\n\n/** @deprecated To be removed in v9. Use {@link map} instead: `map(() => value)`. */\nexport function mapTo<R>(value: R): OperatorFunction<unknown, R>;\n/**\n * @deprecated Do not specify explicit type parameters. Signatures with type parameters\n * that cannot be inferred will be removed in v8. `mapTo` itself will be removed in v9,\n * use {@link map} instead: `map(() => value)`.\n * */\nexport function mapTo<T, R>(value: R): OperatorFunction<T, R>;\n\n/**\n * Emits the given constant value on the output Observable every time the source\n * Observable emits a value.\n *\n * <span class=\"informal\">Like {@link map}, but it maps every source value to\n * the same output value every time.</span>\n *\n * ![](mapTo.png)\n *\n * Takes a constant `value` as argument, and emits that whenever the source\n * Observable emits a value. In other words, ignores the actual source value,\n * and simply uses the emission moment to know when to emit the given `value`.\n *\n * ## Example\n *\n * Map every click to the string `'Hi'`\n *\n * ```ts\n * import { fromEvent, mapTo } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const greetings = clicks.pipe(mapTo('Hi'));\n *\n * greetings.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link map}\n *\n * @param value The value to map each source value to.\n * @return A function that returns an Observable that emits the given `value`\n * every time the source Observable emits.\n * @deprecated To be removed in v9. Use {@link map} instead: `map(() => value)`.\n */\nexport function mapTo<R>(value: R): OperatorFunction<unknown, R> {\n  return map(() => value);\n}\n", "import { Observable } from '../Observable';\nimport { MonoTypeOperatorFunction, ObservableInput } from '../types';\nimport { concat } from '../observable/concat';\nimport { take } from './take';\nimport { ignoreElements } from './ignoreElements';\nimport { mapTo } from './mapTo';\nimport { mergeMap } from './mergeMap';\nimport { innerFrom } from '../observable/innerFrom';\n\n/** @deprecated The `subscriptionDelay` parameter will be removed in v8. */\nexport function delayWhen<T>(\n  delayDurationSelector: (value: T, index: number) => ObservableInput<any>,\n  subscriptionDelay: Observable<any>\n): MonoTypeOperatorFunction<T>;\nexport function delayWhen<T>(delayDurationSelector: (value: T, index: number) => ObservableInput<any>): MonoTypeOperatorFunction<T>;\n\n/**\n * Delays the emission of items from the source Observable by a given time span\n * determined by the emissions of another Observable.\n *\n * <span class=\"informal\">It's like {@link delay}, but the time span of the\n * delay duration is determined by a second Observable.</span>\n *\n * ![](delayWhen.png)\n *\n * `delayWhen` operator shifts each emitted value from the source Observable by\n * a time span determined by another Observable. When the source emits a value,\n * the `delayDurationSelector` function is called with the value emitted from\n * the source Observable as the first argument to the `delayDurationSelector`.\n * The `delayDurationSelector` function should return an {@link ObservableInput},\n * that is internally converted to an Observable that is called the \"duration\"\n * Observable.\n *\n * The source value is emitted on the output Observable only when the \"duration\"\n * Observable emits ({@link guide/glossary-and-semantics#next next}s) any value.\n * Upon that, the \"duration\" Observable gets unsubscribed.\n *\n * Before RxJS V7, the {@link guide/glossary-and-semantics#complete completion}\n * of the \"duration\" Observable would have been triggering the emission of the\n * source value to the output Observable, but with RxJS V7, this is not the case\n * anymore.\n *\n * Only next notifications (from the \"duration\" Observable) trigger values from\n * the source Observable to be passed to the output Observable. If the \"duration\"\n * Observable only emits the complete notification (without next), the value\n * emitted by the source Observable will never get to the output Observable - it\n * will be swallowed. If the \"duration\" Observable errors, the error will be\n * propagated to the output Observable.\n *\n * Optionally, `delayWhen` takes a second argument, `subscriptionDelay`, which\n * is an Observable. When `subscriptionDelay` emits its first value or\n * completes, the source Observable is subscribed to and starts behaving like\n * described in the previous paragraph. If `subscriptionDelay` is not provided,\n * `delayWhen` will subscribe to the source Observable as soon as the output\n * Observable is subscribed.\n *\n * ## Example\n *\n * Delay each click by a random amount of time, between 0 and 5 seconds\n *\n * ```ts\n * import { fromEvent, delayWhen, interval } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const delayedClicks = clicks.pipe(\n *   delayWhen(() => interval(Math.random() * 5000))\n * );\n * delayedClicks.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link delay}\n * @see {@link throttle}\n * @see {@link throttleTime}\n * @see {@link debounce}\n * @see {@link debounceTime}\n * @see {@link sample}\n * @see {@link sampleTime}\n * @see {@link audit}\n * @see {@link auditTime}\n *\n * @param delayDurationSelector A function that returns an `ObservableInput` for\n * each `value` emitted by the source Observable, which is then used to delay the\n * emission of that `value` on the output Observable until the `ObservableInput`\n * returned from this function emits a next value. When called, beside `value`,\n * this function receives a zero-based `index` of the emission order.\n * @param subscriptionDelay An Observable that triggers the subscription to the\n * source Observable once it emits any value.\n * @return A function that returns an Observable that delays the emissions of\n * the source Observable by an amount of time specified by the Observable\n * returned by `delayDurationSelector`.\n */\nexport function delayWhen<T>(\n  delayDurationSelector: (value: T, index: number) => ObservableInput<any>,\n  subscriptionDelay?: Observable<any>\n): MonoTypeOperatorFunction<T> {\n  if (subscriptionDelay) {\n    // DEPRECATED PATH\n    return (source: Observable<T>) =>\n      concat(subscriptionDelay.pipe(take(1), ignoreElements()), source.pipe(delayWhen(delayDurationSelector)));\n  }\n\n  return mergeMap((value, index) => innerFrom(delayDurationSelector(value, index)).pipe(take(1), mapTo(value)));\n}\n", "import { asyncScheduler } from '../scheduler/async';\nimport { MonoTypeOperatorFunction, SchedulerLike } from '../types';\nimport { delayWhen } from './delayWhen';\nimport { timer } from '../observable/timer';\n\n/**\n * Delays the emission of items from the source Observable by a given timeout or\n * until a given Date.\n *\n * <span class=\"informal\">Time shifts each item by some specified amount of\n * milliseconds.</span>\n *\n * ![](delay.svg)\n *\n * If the delay argument is a Number, this operator time shifts the source\n * Observable by that amount of time expressed in milliseconds. The relative\n * time intervals between the values are preserved.\n *\n * If the delay argument is a Date, this operator time shifts the start of the\n * Observable execution until the given date occurs.\n *\n * ## Examples\n *\n * Delay each click by one second\n *\n * ```ts\n * import { fromEvent, delay } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const delayedClicks = clicks.pipe(delay(1000)); // each click emitted after 1 second\n * delayedClicks.subscribe(x => console.log(x));\n * ```\n *\n * Delay all clicks until a future date happens\n *\n * ```ts\n * import { fromEvent, delay } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const date = new Date('March 15, 2050 12:00:00'); // in the future\n * const delayedClicks = clicks.pipe(delay(date)); // click emitted only after that date\n * delayedClicks.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link delayWhen}\n * @see {@link throttle}\n * @see {@link throttleTime}\n * @see {@link debounce}\n * @see {@link debounceTime}\n * @see {@link sample}\n * @see {@link sampleTime}\n * @see {@link audit}\n * @see {@link auditTime}\n *\n * @param {number|Date} due The delay duration in milliseconds (a `number`) or\n * a `Date` until which the emission of the source items is delayed.\n * @param {SchedulerLike} [scheduler=async] The {@link SchedulerLike} to use for\n * managing the timers that handle the time-shift for each item.\n * @return A function that returns an Observable that delays the emissions of\n * the source Observable by the specified timeout or Date.\n */\nexport function delay<T>(due: number | Date, scheduler: SchedulerLike = asyncScheduler): MonoTypeOperatorFunction<T> {\n  const duration = timer(due, scheduler);\n  return delayWhen(() => duration);\n}\n", "import { MonoTypeOperatorFunction } from '../types';\nimport { identity } from '../util/identity';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\nexport function distinctUntilChanged<T>(comparator?: (previous: T, current: T) => boolean): MonoTypeOperatorFunction<T>;\nexport function distinctUntilChanged<T, K>(\n  comparator: (previous: K, current: K) => boolean,\n  keySelector: (value: T) => K\n): MonoTypeOperatorFunction<T>;\n\n/**\n * Returns a result {@link Observable} that emits all values pushed by the source observable if they\n * are distinct in comparison to the last value the result observable emitted.\n *\n * When provided without parameters or with the first parameter (`{@link distinctUntilChanged#comparator comparator}`),\n * it behaves like this:\n *\n * 1. It will always emit the first value from the source.\n * 2. For all subsequent values pushed by the source, they will be compared to the previously emitted values\n *    using the provided `comparator` or an `===` equality check.\n * 3. If the value pushed by the source is determined to be unequal by this check, that value is emitted and\n *    becomes the new \"previously emitted value\" internally.\n *\n * When the second parameter (`{@link distinctUntilChanged#keySelector keySelector}`) is provided, the behavior\n * changes:\n *\n * 1. It will always emit the first value from the source.\n * 2. The `keySelector` will be run against all values, including the first value.\n * 3. For all values after the first, the selected key will be compared against the key selected from\n *    the previously emitted value using the `comparator`.\n * 4. If the keys are determined to be unequal by this check, the value (not the key), is emitted\n *    and the selected key from that value is saved for future comparisons against other keys.\n *\n * ## Examples\n *\n * A very basic example with no `{@link distinctUntilChanged#comparator comparator}`. Note that `1` is emitted more than once,\n * because it's distinct in comparison to the _previously emitted_ value,\n * not in comparison to _all other emitted values_.\n *\n * ```ts\n * import { of, distinctUntilChanged } from 'rxjs';\n *\n * of(1, 1, 1, 2, 2, 2, 1, 1, 3, 3)\n *   .pipe(distinctUntilChanged())\n *   .subscribe(console.log);\n * // Logs: 1, 2, 1, 3\n * ```\n *\n * With a `{@link distinctUntilChanged#comparator comparator}`, you can do custom comparisons. Let's say\n * you only want to emit a value when all of its components have\n * changed:\n *\n * ```ts\n * import { of, distinctUntilChanged } from 'rxjs';\n *\n * const totallyDifferentBuilds$ = of(\n *   { engineVersion: '1.1.0', transmissionVersion: '1.2.0' },\n *   { engineVersion: '1.1.0', transmissionVersion: '1.4.0' },\n *   { engineVersion: '1.3.0', transmissionVersion: '1.4.0' },\n *   { engineVersion: '1.3.0', transmissionVersion: '1.5.0' },\n *   { engineVersion: '2.0.0', transmissionVersion: '1.5.0' }\n * ).pipe(\n *   distinctUntilChanged((prev, curr) => {\n *     return (\n *       prev.engineVersion === curr.engineVersion ||\n *       prev.transmissionVersion === curr.transmissionVersion\n *     );\n *   })\n * );\n *\n * totallyDifferentBuilds$.subscribe(console.log);\n *\n * // Logs:\n * // { engineVersion: '1.1.0', transmissionVersion: '1.2.0' }\n * // { engineVersion: '1.3.0', transmissionVersion: '1.4.0' }\n * // { engineVersion: '2.0.0', transmissionVersion: '1.5.0' }\n * ```\n *\n * You can also provide a custom `{@link distinctUntilChanged#comparator comparator}` to check that emitted\n * changes are only in one direction. Let's say you only want to get\n * the next record temperature:\n *\n * ```ts\n * import { of, distinctUntilChanged } from 'rxjs';\n *\n * const temps$ = of(30, 31, 20, 34, 33, 29, 35, 20);\n *\n * const recordHighs$ = temps$.pipe(\n *   distinctUntilChanged((prevHigh, temp) => {\n *     // If the current temp is less than\n *     // or the same as the previous record,\n *     // the record hasn't changed.\n *     return temp <= prevHigh;\n *   })\n * );\n *\n * recordHighs$.subscribe(console.log);\n * // Logs: 30, 31, 34, 35\n * ```\n *\n * Selecting update events only when the `updatedBy` field shows\n * the account changed hands.\n *\n * ```ts\n * import { of, distinctUntilChanged } from 'rxjs';\n *\n * // A stream of updates to a given account\n * const accountUpdates$ = of(\n *   { updatedBy: 'blesh', data: [] },\n *   { updatedBy: 'blesh', data: [] },\n *   { updatedBy: 'ncjamieson', data: [] },\n *   { updatedBy: 'ncjamieson', data: [] },\n *   { updatedBy: 'blesh', data: [] }\n * );\n *\n * // We only want the events where it changed hands\n * const changedHands$ = accountUpdates$.pipe(\n *   distinctUntilChanged(undefined, update => update.updatedBy)\n * );\n *\n * changedHands$.subscribe(console.log);\n * // Logs:\n * // { updatedBy: 'blesh', data: Array[0] }\n * // { updatedBy: 'ncjamieson', data: Array[0] }\n * // { updatedBy: 'blesh', data: Array[0] }\n * ```\n *\n * @see {@link distinct}\n * @see {@link distinctUntilKeyChanged}\n *\n * @param comparator A function used to compare the previous and current keys for\n * equality. Defaults to a `===` check.\n * @param keySelector Used to select a key value to be passed to the `comparator`.\n *\n * @return A function that returns an Observable that emits items from the\n * source Observable with distinct values.\n */\nexport function distinctUntilChanged<T, K>(\n  comparator?: (previous: K, current: K) => boolean,\n  keySelector: (value: T) => K = identity as (value: T) => K\n): MonoTypeOperatorFunction<T> {\n  // We've been allowing `null` do be passed as the `compare`, so we can't do\n  // a default value for the parameter, because that will only work\n  // for `undefined`.\n  comparator = comparator ?? defaultCompare;\n\n  return operate((source, subscriber) => {\n    // The previous key, used to compare against keys selected\n    // from new arrivals to determine \"distinctiveness\".\n    let previousKey: K;\n    // Whether or not this is the first value we've gotten.\n    let first = true;\n\n    source.subscribe(\n      createOperatorSubscriber(subscriber, (value) => {\n        // We always call the key selector.\n        const currentKey = keySelector(value);\n\n        // If it's the first value, we always emit it.\n        // Otherwise, we compare this key to the previous key, and\n        // if the comparer returns false, we emit.\n        if (first || !comparator!(previousKey, currentKey)) {\n          // Update our state *before* we emit the value\n          // as emission can be the source of re-entrant code\n          // in functional libraries like this. We only really\n          // need to do this if it's the first value, or if the\n          // key we're tracking in previous needs to change.\n          first = false;\n          previousKey = currentKey;\n\n          // Emit the value!\n          subscriber.next(value);\n        }\n      })\n    );\n  });\n}\n\nfunction defaultCompare(a: any, b: any) {\n  return a === b;\n}\n", "import { distinctUntilChanged } from './distinctUntilChanged';\nimport { MonoTypeOperatorFunction } from '../types';\n\n/* tslint:disable:max-line-length */\nexport function distinctUntilKeyChanged<T>(key: keyof T): MonoTypeOperatorFunction<T>;\nexport function distinctUntilKeyChanged<T, K extends keyof T>(key: K, compare: (x: T[K], y: T[K]) => boolean): MonoTypeOperatorFunction<T>;\n/* tslint:enable:max-line-length */\n\n/**\n * Returns an Observable that emits all items emitted by the source Observable that are distinct by comparison from the previous item,\n * using a property accessed by using the key provided to check if the two items are distinct.\n *\n * If a comparator function is provided, then it will be called for each item to test for whether or not that value should be emitted.\n *\n * If a comparator function is not provided, an equality check is used by default.\n *\n * ## Examples\n *\n * An example comparing the name of persons\n *\n * ```ts\n * import { of, distinctUntilKeyChanged } from 'rxjs';\n *\n * of(\n *   { age: 4, name: 'Foo' },\n *   { age: 7, name: 'Bar' },\n *   { age: 5, name: 'Foo' },\n *   { age: 6, name: 'Foo' }\n * ).pipe(\n *   distinctUntilKeyChanged('name')\n * )\n * .subscribe(x => console.log(x));\n *\n * // displays:\n * // { age: 4, name: 'Foo' }\n * // { age: 7, name: 'Bar' }\n * // { age: 5, name: 'Foo' }\n * ```\n *\n * An example comparing the first letters of the name\n *\n * ```ts\n * import { of, distinctUntilKeyChanged } from 'rxjs';\n *\n * of(\n *   { age: 4, name: 'Foo1' },\n *   { age: 7, name: 'Bar' },\n *   { age: 5, name: 'Foo2' },\n *   { age: 6, name: 'Foo3' }\n * ).pipe(\n *   distinctUntilKeyChanged('name', (x, y) => x.substring(0, 3) === y.substring(0, 3))\n * )\n * .subscribe(x => console.log(x));\n *\n * // displays:\n * // { age: 4, name: 'Foo1' }\n * // { age: 7, name: 'Bar' }\n * // { age: 5, name: 'Foo2' }\n * ```\n *\n * @see {@link distinct}\n * @see {@link distinctUntilChanged}\n *\n * @param {string} key String key for object property lookup on each item.\n * @param {function} [compare] Optional comparison function called to test if an item is distinct from the previous item in the source.\n * @return A function that returns an Observable that emits items from the\n * source Observable with distinct values based on the key specified.\n */\nexport function distinctUntilKeyChanged<T, K extends keyof T>(key: K, compare?: (x: T[K], y: T[K]) => boolean): MonoTypeOperatorFunction<T> {\n  return distinctUntilChanged((x: T, y: T) => compare ? compare(x[key], y[key]) : x[key] === y[key]);\n}\n", "import { EmptyError } from '../util/EmptyError';\nimport { MonoTypeOperatorFunction } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * If the source observable completes without emitting a value, it will emit\n * an error. The error will be created at that time by the optional\n * `errorFactory` argument, otherwise, the error will be {@link EmptyError}.\n *\n * ![](throwIfEmpty.png)\n *\n * ## Example\n *\n * Throw an error if the document wasn't clicked within 1 second\n *\n * ```ts\n * import { fromEvent, takeUntil, timer, throwIfEmpty } from 'rxjs';\n *\n * const click$ = fromEvent(document, 'click');\n *\n * click$.pipe(\n *   takeUntil(timer(1000)),\n *   throwIfEmpty(() => new Error('The document was not clicked within 1 second'))\n * )\n * .subscribe({\n *   next() {\n *    console.log('The document was clicked');\n *   },\n *   error(err) {\n *     console.error(err.message);\n *   }\n * });\n * ```\n *\n * @param errorFactory A factory function called to produce the\n * error to be thrown when the source observable completes without emitting a\n * value.\n * @return A function that returns an Observable that throws an error if the\n * source Observable completed without emitting.\n */\nexport function throwIfEmpty<T>(errorFactory: () => any = defaultErrorFactory): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    let hasValue = false;\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value) => {\n          hasValue = true;\n          subscriber.next(value);\n        },\n        () => (hasValue ? subscriber.complete() : subscriber.error(errorFactory()))\n      )\n    );\n  });\n}\n\nfunction defaultErrorFactory() {\n  return new EmptyError();\n}\n", "/** prettier */\nimport { Observable } from '../Observable';\nimport { concat } from '../observable/concat';\nimport { of } from '../observable/of';\nimport { MonoTypeOperatorFunction, SchedulerLike, OperatorFunction, ValueFromArray } from '../types';\n\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `concatAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function endWith<T>(scheduler: SchedulerLike): MonoTypeOperatorFunction<T>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `concatAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function endWith<T, A extends unknown[] = T[]>(\n  ...valuesAndScheduler: [...A, SchedulerLike]\n): OperatorFunction<T, T | ValueFromArray<A>>;\n\nexport function endWith<T, A extends unknown[] = T[]>(...values: A): OperatorFunction<T, T | ValueFromArray<A>>;\n\n/**\n * Returns an observable that will emit all values from the source, then synchronously emit\n * the provided value(s) immediately after the source completes.\n *\n * NOTE: Passing a last argument of a Scheduler is _deprecated_, and may result in incorrect\n * types in TypeScript.\n *\n * This is useful for knowing when an observable ends. Particularly when paired with an\n * operator like {@link takeUntil}\n *\n * ![](endWith.png)\n *\n * ## Example\n *\n * Emit values to know when an interval starts and stops. The interval will\n * stop when a user clicks anywhere on the document.\n *\n * ```ts\n * import { interval, map, fromEvent, startWith, takeUntil, endWith } from 'rxjs';\n *\n * const ticker$ = interval(5000).pipe(\n *   map(() => 'tick')\n * );\n *\n * const documentClicks$ = fromEvent(document, 'click');\n *\n * ticker$.pipe(\n *   startWith('interval started'),\n *   takeUntil(documentClicks$),\n *   endWith('interval ended by click')\n * )\n * .subscribe(x => console.log(x));\n *\n * // Result (assuming a user clicks after 15 seconds)\n * // 'interval started'\n * // 'tick'\n * // 'tick'\n * // 'tick'\n * // 'interval ended by click'\n * ```\n *\n * @see {@link startWith}\n * @see {@link concat}\n * @see {@link takeUntil}\n *\n * @param values Items you want the modified Observable to emit last.\n * @return A function that returns an Observable that emits all values from the\n * source, then synchronously emits the provided value(s) immediately after the\n * source completes.\n */\nexport function endWith<T>(...values: Array<T | SchedulerLike>): MonoTypeOperatorFunction<T> {\n  return (source: Observable<T>) => concat(source, of(...values)) as Observable<T>;\n}\n", "import { MonoTypeOperatorFunction } from '../types';\nimport { operate } from '../util/lift';\n\n/**\n * Returns an Observable that mirrors the source Observable, but will call a specified function when\n * the source terminates on complete or error.\n * The specified function will also be called when the subscriber explicitly unsubscribes.\n *\n * ## Examples\n *\n * Execute callback function when the observable completes\n *\n * ```ts\n * import { interval, take, finalize } from 'rxjs';\n *\n * // emit value in sequence every 1 second\n * const source = interval(1000);\n * const example = source.pipe(\n *   take(5), //take only the first 5 values\n *   finalize(() => console.log('Sequence complete')) // Execute when the observable completes\n * );\n * const subscribe = example.subscribe(val => console.log(val));\n *\n * // results:\n * // 0\n * // 1\n * // 2\n * // 3\n * // 4\n * // 'Sequence complete'\n * ```\n *\n * Execute callback function when the subscriber explicitly unsubscribes\n *\n * ```ts\n * import { interval, finalize, tap, noop, timer } from 'rxjs';\n *\n * const source = interval(100).pipe(\n *   finalize(() => console.log('[finalize] Called')),\n *   tap({\n *     next: () => console.log('[next] Called'),\n *     error: () => console.log('[error] Not called'),\n *     complete: () => console.log('[tap complete] Not called')\n *   })\n * );\n *\n * const sub = source.subscribe({\n *   next: x => console.log(x),\n *   error: noop,\n *   complete: () => console.log('[complete] Not called')\n * });\n *\n * timer(150).subscribe(() => sub.unsubscribe());\n *\n * // results:\n * // '[next] Called'\n * // 0\n * // '[finalize] Called'\n * ```\n *\n * @param {function} callback Function to be called when source terminates.\n * @return A function that returns an Observable that mirrors the source, but\n * will call the specified function on termination.\n */\nexport function finalize<T>(callback: () => void): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    // TODO: This try/finally was only added for `useDeprecatedSynchronousErrorHandling`.\n    // REMOVE THIS WHEN THAT HOT GARBAGE IS REMOVED IN V8.\n    try {\n      source.subscribe(subscriber);\n    } finally {\n      subscriber.add(callback);\n    }\n  });\n}\n", "import { Observable } from '../Observable';\nimport { EmptyError } from '../util/EmptyError';\nimport { OperatorFunction, TruthyTypesOf } from '../types';\nimport { filter } from './filter';\nimport { take } from './take';\nimport { defaultIfEmpty } from './defaultIfEmpty';\nimport { throwIfEmpty } from './throwIfEmpty';\nimport { identity } from '../util/identity';\n\nexport function first<T, D = T>(predicate?: null, defaultValue?: D): OperatorFunction<T, T | D>;\nexport function first<T>(predicate: BooleanConstructor): OperatorFunction<T, TruthyTypesOf<T>>;\nexport function first<T, D>(predicate: BooleanConstructor, defaultValue: D): OperatorFunction<T, TruthyTypesOf<T> | D>;\nexport function first<T, S extends T>(\n  predicate: (value: T, index: number, source: Observable<T>) => value is S,\n  defaultValue?: S\n): OperatorFunction<T, S>;\nexport function first<T, S extends T, D>(\n  predicate: (value: T, index: number, source: Observable<T>) => value is S,\n  defaultValue: D\n): OperatorFunction<T, S | D>;\nexport function first<T, D = T>(\n  predicate: (value: T, index: number, source: Observable<T>) => boolean,\n  defaultValue?: D\n): OperatorFunction<T, T | D>;\n\n/**\n * Emits only the first value (or the first value that meets some condition)\n * emitted by the source Observable.\n *\n * <span class=\"informal\">Emits only the first value. Or emits only the first\n * value that passes some test.</span>\n *\n * ![](first.png)\n *\n * If called with no arguments, `first` emits the first value of the source\n * Observable, then completes. If called with a `predicate` function, `first`\n * emits the first value of the source that matches the specified condition. Throws an error if\n * `defaultValue` was not provided and a matching element is not found.\n *\n * ## Examples\n *\n * Emit only the first click that happens on the DOM\n *\n * ```ts\n * import { fromEvent, first } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(first());\n * result.subscribe(x => console.log(x));\n * ```\n *\n * Emits the first click that happens on a DIV\n *\n * ```ts\n * import { fromEvent, first } from 'rxjs';\n *\n * const div = document.createElement('div');\n * div.style.cssText = 'width: 200px; height: 200px; background: #09c;';\n * document.body.appendChild(div);\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(first(ev => (<HTMLElement>ev.target).tagName === 'DIV'));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link filter}\n * @see {@link find}\n * @see {@link take}\n *\n * @throws {EmptyError} Delivers an EmptyError to the Observer's `error`\n * callback if the Observable completes before any `next` notification was sent.\n * This is how `first()` is different from {@link take}(1) which completes instead.\n *\n * @param {function(value: T, index: number, source: Observable<T>): boolean} [predicate]\n * An optional function called with each item to test for condition matching.\n * @param {D} [defaultValue] The default value emitted in case no valid value\n * was found on the source.\n * @return A function that returns an Observable that emits the first item that\n * matches the condition.\n */\nexport function first<T, D>(\n  predicate?: ((value: T, index: number, source: Observable<T>) => boolean) | null,\n  defaultValue?: D\n): OperatorFunction<T, T | D> {\n  const hasDefaultValue = arguments.length >= 2;\n  return (source: Observable<T>) =>\n    source.pipe(\n      predicate ? filter((v, i) => predicate(v, i, source)) : identity,\n      take(1),\n      hasDefaultValue ? defaultIfEmpty(defaultValue!) : throwIfEmpty(() => new EmptyError())\n    );\n}\n", "import { EMPTY } from '../observable/empty';\nimport { MonoTypeOperatorFunction } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * Waits for the source to complete, then emits the last N values from the source,\n * as specified by the `count` argument.\n *\n * ![](takeLast.png)\n *\n * `takeLast` results in an observable that will hold values up to `count` values in memory,\n * until the source completes. It then pushes all values in memory to the consumer, in the\n * order they were received from the source, then notifies the consumer that it is\n * complete.\n *\n * If for some reason the source completes before the `count` supplied to `takeLast` is reached,\n * all values received until that point are emitted, and then completion is notified.\n *\n * **Warning**: Using `takeLast` with an observable that never completes will result\n * in an observable that never emits a value.\n *\n * ## Example\n *\n * Take the last 3 values of an Observable with many values\n *\n * ```ts\n * import { range, takeLast } from 'rxjs';\n *\n * const many = range(1, 100);\n * const lastThree = many.pipe(takeLast(3));\n * lastThree.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link take}\n * @see {@link takeUntil}\n * @see {@link takeWhile}\n * @see {@link skip}\n *\n * @param count The maximum number of values to emit from the end of\n * the sequence of values emitted by the source Observable.\n * @return A function that returns an Observable that emits at most the last\n * `count` values emitted by the source Observable.\n */\nexport function takeLast<T>(count: number): MonoTypeOperatorFunction<T> {\n  return count <= 0\n    ? () => EMPTY\n    : operate((source, subscriber) => {\n        // This buffer will hold the values we are going to emit\n        // when the source completes. Since we only want to take the\n        // last N values, we can't emit until we're sure we're not getting\n        // any more values.\n        let buffer: T[] = [];\n        source.subscribe(\n          createOperatorSubscriber(\n            subscriber,\n            (value) => {\n              // Add the most recent value onto the end of our buffer.\n              buffer.push(value);\n              // If our buffer is now larger than the number of values we\n              // want to take, we remove the oldest value from the buffer.\n              count < buffer.length && buffer.shift();\n            },\n            () => {\n              // The source completed, we now know what are last values\n              // are, emit them in the order they were received.\n              for (const value of buffer) {\n                subscriber.next(value);\n              }\n              subscriber.complete();\n            },\n            // Errors are passed through to the consumer\n            undefined,\n            () => {\n              // During finalization release the values in our buffer.\n              buffer = null!;\n            }\n          )\n        );\n      });\n}\n", "import { ObservableInput, ObservableInputTuple, OperatorFunction, SchedulerLike } from '../types';\nimport { operate } from '../util/lift';\nimport { argsOrArgArray } from '../util/argsOrArgArray';\nimport { mergeAll } from './mergeAll';\nimport { popNumber, popScheduler } from '../util/args';\nimport { from } from '../observable/from';\n\n/** @deprecated Replaced with {@link mergeWith}. Will be removed in v8. */\nexport function merge<T, A extends readonly unknown[]>(...sources: [...ObservableInputTuple<A>]): OperatorFunction<T, T | A[number]>;\n/** @deprecated Replaced with {@link mergeWith}. Will be removed in v8. */\nexport function merge<T, A extends readonly unknown[]>(\n  ...sourcesAndConcurrency: [...ObservableInputTuple<A>, number]\n): OperatorFunction<T, T | A[number]>;\n/** @deprecated Replaced with {@link mergeWith}. Will be removed in v8. */\nexport function merge<T, A extends readonly unknown[]>(\n  ...sourcesAndScheduler: [...ObservableInputTuple<A>, SchedulerLike]\n): OperatorFunction<T, T | A[number]>;\n/** @deprecated Replaced with {@link mergeWith}. Will be removed in v8. */\nexport function merge<T, A extends readonly unknown[]>(\n  ...sourcesAndConcurrencyAndScheduler: [...ObservableInputTuple<A>, number, SchedulerLike]\n): OperatorFunction<T, T | A[number]>;\n\nexport function merge<T>(...args: unknown[]): OperatorFunction<T, unknown> {\n  const scheduler = popScheduler(args);\n  const concurrent = popNumber(args, Infinity);\n  args = argsOrArgArray(args);\n\n  return operate((source, subscriber) => {\n    mergeAll(concurrent)(from([source, ...(args as ObservableInput<T>[])], scheduler)).subscribe(subscriber);\n  });\n}\n", "import { ObservableInputTuple, OperatorFunction } from '../types';\nimport { merge } from './merge';\n\n/**\n * Merge the values from all observables to a single observable result.\n *\n * Creates an observable, that when subscribed to, subscribes to the source\n * observable, and all other sources provided as arguments. All values from\n * every source are emitted from the resulting subscription.\n *\n * When all sources complete, the resulting observable will complete.\n *\n * When any source errors, the resulting observable will error.\n *\n * ## Example\n *\n * Joining all outputs from multiple user input event streams\n *\n * ```ts\n * import { fromEvent, map, mergeWith } from 'rxjs';\n *\n * const clicks$ = fromEvent(document, 'click').pipe(map(() => 'click'));\n * const mousemoves$ = fromEvent(document, 'mousemove').pipe(map(() => 'mousemove'));\n * const dblclicks$ = fromEvent(document, 'dblclick').pipe(map(() => 'dblclick'));\n *\n * mousemoves$\n *   .pipe(mergeWith(clicks$, dblclicks$))\n *   .subscribe(x => console.log(x));\n *\n * // result (assuming user interactions)\n * // 'mousemove'\n * // 'mousemove'\n * // 'mousemove'\n * // 'click'\n * // 'click'\n * // 'dblclick'\n * ```\n *\n * @see {@link merge}\n *\n * @param otherSources the sources to combine the current source with.\n * @return A function that returns an Observable that merges the values from\n * all given Observables.\n */\nexport function mergeWith<T, A extends readonly unknown[]>(\n  ...otherSources: [...ObservableInputTuple<A>]\n): OperatorFunction<T, T | A[number]> {\n  return merge(...otherSources);\n}\n", "import { Subscription } from '../Subscription';\nimport { EMPTY } from '../observable/empty';\nimport { operate } from '../util/lift';\nimport { MonoTypeOperatorFunction, ObservableInput } from '../types';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { innerFrom } from '../observable/innerFrom';\nimport { timer } from '../observable/timer';\n\nexport interface RepeatConfig {\n  /**\n   * The number of times to repeat the source. Defaults to `Infinity`.\n   */\n  count?: number;\n\n  /**\n   * If a `number`, will delay the repeat of the source by that number of milliseconds.\n   * If a function, it will provide the number of times the source has been subscribed to,\n   * and the return value should be a valid observable input that will notify when the source\n   * should be repeated. If the notifier observable is empty, the result will complete.\n   */\n  delay?: number | ((count: number) => ObservableInput<any>);\n}\n\n/**\n * Returns an Observable that will resubscribe to the source stream when the source stream completes.\n *\n * <span class=\"informal\">Repeats all values emitted on the source. It's like {@link retry}, but for non error cases.</span>\n *\n * ![](repeat.png)\n *\n * Repeat will output values from a source until the source completes, then it will resubscribe to the\n * source a specified number of times, with a specified delay. Repeat can be particularly useful in\n * combination with closing operators like {@link take}, {@link takeUntil}, {@link first}, or {@link takeWhile},\n * as it can be used to restart a source again from scratch.\n *\n * Repeat is very similar to {@link retry}, where {@link retry} will resubscribe to the source in the error case, but\n * `repeat` will resubscribe if the source completes.\n *\n * Note that `repeat` will _not_ catch errors. Use {@link retry} for that.\n *\n * - `repeat(0)` returns an empty observable\n * - `repeat()` will repeat forever\n * - `repeat({ delay: 200 })` will repeat forever, with a delay of 200ms between repetitions.\n * - `repeat({ count: 2, delay: 400 })` will repeat twice, with a delay of 400ms between repetitions.\n * - `repeat({ delay: (count) => timer(count * 1000) })` will repeat forever, but will have a delay that grows by one second for each repetition.\n *\n * ## Example\n *\n * Repeat a message stream\n *\n * ```ts\n * import { of, repeat } from 'rxjs';\n *\n * const source = of('Repeat message');\n * const result = source.pipe(repeat(3));\n *\n * result.subscribe(x => console.log(x));\n *\n * // Results\n * // 'Repeat message'\n * // 'Repeat message'\n * // 'Repeat message'\n * ```\n *\n * Repeat 3 values, 2 times\n *\n * ```ts\n * import { interval, take, repeat } from 'rxjs';\n *\n * const source = interval(1000);\n * const result = source.pipe(take(3), repeat(2));\n *\n * result.subscribe(x => console.log(x));\n *\n * // Results every second\n * // 0\n * // 1\n * // 2\n * // 0\n * // 1\n * // 2\n * ```\n *\n * Defining two complex repeats with delays on the same source.\n * Note that the second repeat cannot be called until the first\n * repeat as exhausted it's count.\n *\n * ```ts\n * import { defer, of, repeat } from 'rxjs';\n *\n * const source = defer(() => {\n *    return of(`Hello, it is ${new Date()}`)\n * });\n *\n * source.pipe(\n *    // Repeat 3 times with a delay of 1 second between repetitions\n *    repeat({\n *      count: 3,\n *      delay: 1000,\n *    }),\n *\n *    // *Then* repeat forever, but with an exponential step-back\n *    // maxing out at 1 minute.\n *    repeat({\n *      delay: (count) => timer(Math.min(60000, 2 ^ count * 1000))\n *    })\n * )\n * ```\n *\n * @see {@link repeatWhen}\n * @see {@link retry}\n *\n * @param count The number of times the source Observable items are repeated, a count of 0 will yield\n * an empty Observable.\n */\nexport function repeat<T>(countOrConfig?: number | RepeatConfig): MonoTypeOperatorFunction<T> {\n  let count = Infinity;\n  let delay: RepeatConfig['delay'];\n\n  if (countOrConfig != null) {\n    if (typeof countOrConfig === 'object') {\n      ({ count = Infinity, delay } = countOrConfig);\n    } else {\n      count = countOrConfig;\n    }\n  }\n\n  return count <= 0\n    ? () => EMPTY\n    : operate((source, subscriber) => {\n        let soFar = 0;\n        let sourceSub: Subscription | null;\n\n        const resubscribe = () => {\n          sourceSub?.unsubscribe();\n          sourceSub = null;\n          if (delay != null) {\n            const notifier = typeof delay === 'number' ? timer(delay) : innerFrom(delay(soFar));\n            const notifierSubscriber = createOperatorSubscriber(subscriber, () => {\n              notifierSubscriber.unsubscribe();\n              subscribeToSource();\n            });\n            notifier.subscribe(notifierSubscriber);\n          } else {\n            subscribeToSource();\n          }\n        };\n\n        const subscribeToSource = () => {\n          let syncUnsub = false;\n          sourceSub = source.subscribe(\n            createOperatorSubscriber(subscriber, undefined, () => {\n              if (++soFar < count) {\n                if (sourceSub) {\n                  resubscribe();\n                } else {\n                  syncUnsub = true;\n                }\n              } else {\n                subscriber.complete();\n              }\n            })\n          );\n\n          if (syncUnsub) {\n            resubscribe();\n          }\n        };\n\n        subscribeToSource();\n      });\n}\n", "import { OperatorFunction } from '../types';\nimport { operate } from '../util/lift';\nimport { scanInternals } from './scanInternals';\n\nexport function scan<V, A = V>(accumulator: (acc: A | V, value: V, index: number) => A): OperatorFunction<V, V | A>;\nexport function scan<V, A>(accumulator: (acc: A, value: V, index: number) => A, seed: A): OperatorFunction<V, A>;\nexport function scan<V, A, S>(accumulator: (acc: A | S, value: V, index: number) => A, seed: S): OperatorFunction<V, A>;\n\n// TODO: link to a \"redux pattern\" section in the guide (location TBD)\n\n/**\n * Useful for encapsulating and managing state. Applies an accumulator (or \"reducer function\")\n * to each value from the source after an initial state is established -- either via\n * a `seed` value (second argument), or from the first value from the source.\n *\n * <span class=\"informal\">It's like {@link reduce}, but emits the current\n * accumulation state after each update</span>\n *\n * ![](scan.png)\n *\n * This operator maintains an internal state and emits it after processing each value as follows:\n *\n * 1. First value arrives\n *   - If a `seed` value was supplied (as the second argument to `scan`), let `state = seed` and `value = firstValue`.\n *   - If NO `seed` value was supplied (no second argument), let `state = firstValue` and go to 3.\n * 2. Let `state = accumulator(state, value)`.\n *   - If an error is thrown by `accumulator`, notify the consumer of an error. The process ends.\n * 3. Emit `state`.\n * 4. Next value arrives, let `value = nextValue`, go to 2.\n *\n * ## Examples\n *\n * An average of previous numbers. This example shows how\n * not providing a `seed` can prime the stream with the\n * first value from the source.\n *\n * ```ts\n * import { of, scan, map } from 'rxjs';\n *\n * const numbers$ = of(1, 2, 3);\n *\n * numbers$\n *   .pipe(\n *     // Get the sum of the numbers coming in.\n *     scan((total, n) => total + n),\n *     // Get the average by dividing the sum by the total number\n *     // received so far (which is 1 more than the zero-based index).\n *     map((sum, index) => sum / (index + 1))\n *   )\n *   .subscribe(console.log);\n * ```\n *\n * The Fibonacci sequence. This example shows how you can use\n * a seed to prime accumulation process. Also... you know... Fibonacci.\n * So important to like, computers and stuff that its whiteboarded\n * in job interviews. Now you can show them the Rx version! (Please don't, haha)\n *\n * ```ts\n * import { interval, scan, map, startWith } from 'rxjs';\n *\n * const firstTwoFibs = [0, 1];\n * // An endless stream of Fibonacci numbers.\n * const fibonacci$ = interval(1000).pipe(\n *   // Scan to get the fibonacci numbers (after 0, 1)\n *   scan(([a, b]) => [b, a + b], firstTwoFibs),\n *   // Get the second number in the tuple, it's the one you calculated\n *   map(([, n]) => n),\n *   // Start with our first two digits :)\n *   startWith(...firstTwoFibs)\n * );\n *\n * fibonacci$.subscribe(console.log);\n * ```\n *\n * @see {@link expand}\n * @see {@link mergeScan}\n * @see {@link reduce}\n * @see {@link switchScan}\n *\n * @param accumulator A \"reducer function\". This will be called for each value after an initial state is\n * acquired.\n * @param seed The initial state. If this is not provided, the first value from the source will\n * be used as the initial state, and emitted without going through the accumulator. All subsequent values\n * will be processed by the accumulator function. If this is provided, all values will go through\n * the accumulator function.\n * @return A function that returns an Observable of the accumulated values.\n */\nexport function scan<V, A, S>(accumulator: (acc: V | A | S, value: V, index: number) => A, seed?: S): OperatorFunction<V, V | A> {\n  // providing a seed of `undefined` *should* be valid and trigger\n  // hasSeed! so don't use `seed !== undefined` checks!\n  // For this reason, we have to check it here at the original call site\n  // otherwise inside Operator/Subscriber we won't know if `undefined`\n  // means they didn't provide anything or if they literally provided `undefined`\n  return operate(scanInternals(accumulator, seed as S, arguments.length >= 2, true));\n}\n", "import { innerFrom } from '../observable/innerFrom';\nimport { Subject } from '../Subject';\nimport { SafeSubscriber } from '../Subscriber';\nimport { Subscription } from '../Subscription';\nimport { MonoTypeOperatorFunction, SubjectLike, ObservableInput } from '../types';\nimport { operate } from '../util/lift';\n\nexport interface ShareConfig<T> {\n  /**\n   * The factory used to create the subject that will connect the source observable to\n   * multicast consumers.\n   */\n  connector?: () => SubjectLike<T>;\n  /**\n   * If `true`, the resulting observable will reset internal state on error from source and return to a \"cold\" state. This\n   * allows the resulting observable to be \"retried\" in the event of an error.\n   * If `false`, when an error comes from the source it will push the error into the connecting subject, and the subject\n   * will remain the connecting subject, meaning the resulting observable will not go \"cold\" again, and subsequent retries\n   * or resubscriptions will resubscribe to that same subject. In all cases, RxJS subjects will emit the same error again, however\n   * {@link ReplaySubject} will also push its buffered values before pushing the error.\n   * It is also possible to pass a notifier factory returning an `ObservableInput` instead which grants more fine-grained\n   * control over how and when the reset should happen. This allows behaviors like conditional or delayed resets.\n   */\n  resetOnError?: boolean | ((error: any) => ObservableInput<any>);\n  /**\n   * If `true`, the resulting observable will reset internal state on completion from source and return to a \"cold\" state. This\n   * allows the resulting observable to be \"repeated\" after it is done.\n   * If `false`, when the source completes, it will push the completion through the connecting subject, and the subject\n   * will remain the connecting subject, meaning the resulting observable will not go \"cold\" again, and subsequent repeats\n   * or resubscriptions will resubscribe to that same subject.\n   * It is also possible to pass a notifier factory returning an `ObservableInput` instead which grants more fine-grained\n   * control over how and when the reset should happen. This allows behaviors like conditional or delayed resets.\n   */\n  resetOnComplete?: boolean | (() => ObservableInput<any>);\n  /**\n   * If `true`, when the number of subscribers to the resulting observable reaches zero due to those subscribers unsubscribing, the\n   * internal state will be reset and the resulting observable will return to a \"cold\" state. This means that the next\n   * time the resulting observable is subscribed to, a new subject will be created and the source will be subscribed to\n   * again.\n   * If `false`, when the number of subscribers to the resulting observable reaches zero due to unsubscription, the subject\n   * will remain connected to the source, and new subscriptions to the result will be connected through that same subject.\n   * It is also possible to pass a notifier factory returning an `ObservableInput` instead which grants more fine-grained\n   * control over how and when the reset should happen. This allows behaviors like conditional or delayed resets.\n   */\n  resetOnRefCountZero?: boolean | (() => ObservableInput<any>);\n}\n\nexport function share<T>(): MonoTypeOperatorFunction<T>;\n\nexport function share<T>(options: ShareConfig<T>): MonoTypeOperatorFunction<T>;\n\n/**\n * Returns a new Observable that multicasts (shares) the original Observable. As long as there is at least one\n * Subscriber this Observable will be subscribed and emitting data. When all subscribers have unsubscribed it will\n * unsubscribe from the source Observable. Because the Observable is multicasting it makes the stream `hot`.\n * This is an alias for `multicast(() => new Subject()), refCount()`.\n *\n * The subscription to the underlying source Observable can be reset (unsubscribe and resubscribe for new subscribers),\n * if the subscriber count to the shared observable drops to 0, or if the source Observable errors or completes. It is\n * possible to use notifier factories for the resets to allow for behaviors like conditional or delayed resets. Please\n * note that resetting on error or complete of the source Observable does not behave like a transparent retry or restart\n * of the source because the error or complete will be forwarded to all subscribers and their subscription will be\n * closed. Only new subscribers after a reset on error or complete happened will cause a fresh subscription to the\n * source. To achieve transparent retries or restarts pipe the source through appropriate operators before sharing.\n *\n * ![](share.png)\n *\n * ## Example\n *\n * Generate new multicast Observable from the `source` Observable value\n *\n * ```ts\n * import { interval, tap, map, take, share } from 'rxjs';\n *\n * const source = interval(1000).pipe(\n *   tap(x => console.log('Processing: ', x)),\n *   map(x => x * x),\n *   take(6),\n *   share()\n * );\n *\n * source.subscribe(x => console.log('subscription 1: ', x));\n * source.subscribe(x => console.log('subscription 2: ', x));\n *\n * // Logs:\n * // Processing: 0\n * // subscription 1: 0\n * // subscription 2: 0\n * // Processing: 1\n * // subscription 1: 1\n * // subscription 2: 1\n * // Processing: 2\n * // subscription 1: 4\n * // subscription 2: 4\n * // Processing: 3\n * // subscription 1: 9\n * // subscription 2: 9\n * // Processing: 4\n * // subscription 1: 16\n * // subscription 2: 16\n * // Processing: 5\n * // subscription 1: 25\n * // subscription 2: 25\n * ```\n *\n * ## Example with notifier factory: Delayed reset\n *\n * ```ts\n * import { interval, take, share, timer } from 'rxjs';\n *\n * const source = interval(1000).pipe(\n *   take(3),\n *   share({\n *     resetOnRefCountZero: () => timer(1000)\n *   })\n * );\n *\n * const subscriptionOne = source.subscribe(x => console.log('subscription 1: ', x));\n * setTimeout(() => subscriptionOne.unsubscribe(), 1300);\n *\n * setTimeout(() => source.subscribe(x => console.log('subscription 2: ', x)), 1700);\n *\n * setTimeout(() => source.subscribe(x => console.log('subscription 3: ', x)), 5000);\n *\n * // Logs:\n * // subscription 1:  0\n * // (subscription 1 unsubscribes here)\n * // (subscription 2 subscribes here ~400ms later, source was not reset)\n * // subscription 2:  1\n * // subscription 2:  2\n * // (subscription 2 unsubscribes here)\n * // (subscription 3 subscribes here ~2000ms later, source did reset before)\n * // subscription 3:  0\n * // subscription 3:  1\n * // subscription 3:  2\n * ```\n *\n * @see {@link shareReplay}\n *\n * @return A function that returns an Observable that mirrors the source.\n */\nexport function share<T>(options: ShareConfig<T> = {}): MonoTypeOperatorFunction<T> {\n  const { connector = () => new Subject<T>(), resetOnError = true, resetOnComplete = true, resetOnRefCountZero = true } = options;\n  // It's necessary to use a wrapper here, as the _operator_ must be\n  // referentially transparent. Otherwise, it cannot be used in calls to the\n  // static `pipe` function - to create a partial pipeline.\n  //\n  // The _operator function_ - the function returned by the _operator_ - will\n  // not be referentially transparent - as it shares its source - but the\n  // _operator function_ is called when the complete pipeline is composed via a\n  // call to a source observable's `pipe` method - not when the static `pipe`\n  // function is called.\n  return (wrapperSource) => {\n    let connection: SafeSubscriber<T> | undefined;\n    let resetConnection: Subscription | undefined;\n    let subject: SubjectLike<T> | undefined;\n    let refCount = 0;\n    let hasCompleted = false;\n    let hasErrored = false;\n\n    const cancelReset = () => {\n      resetConnection?.unsubscribe();\n      resetConnection = undefined;\n    };\n    // Used to reset the internal state to a \"cold\"\n    // state, as though it had never been subscribed to.\n    const reset = () => {\n      cancelReset();\n      connection = subject = undefined;\n      hasCompleted = hasErrored = false;\n    };\n    const resetAndUnsubscribe = () => {\n      // We need to capture the connection before\n      // we reset (if we need to reset).\n      const conn = connection;\n      reset();\n      conn?.unsubscribe();\n    };\n\n    return operate<T, T>((source, subscriber) => {\n      refCount++;\n      if (!hasErrored && !hasCompleted) {\n        cancelReset();\n      }\n\n      // Create the subject if we don't have one yet. Grab a local reference to\n      // it as well, which avoids non-null assertions when using it and, if we\n      // connect to it now, then error/complete need a reference after it was\n      // reset.\n      const dest = (subject = subject ?? connector());\n\n      // Add the finalization directly to the subscriber - instead of returning it -\n      // so that the handling of the subscriber's unsubscription will be wired\n      // up _before_ the subscription to the source occurs. This is done so that\n      // the assignment to the source connection's `closed` property will be seen\n      // by synchronous firehose sources.\n      subscriber.add(() => {\n        refCount--;\n\n        // If we're resetting on refCount === 0, and it's 0, we only want to do\n        // that on \"unsubscribe\", really. Resetting on error or completion is a different\n        // configuration.\n        if (refCount === 0 && !hasErrored && !hasCompleted) {\n          resetConnection = handleReset(resetAndUnsubscribe, resetOnRefCountZero);\n        }\n      });\n\n      // The following line adds the subscription to the subscriber passed.\n      // Basically, `subscriber === dest.subscribe(subscriber)` is `true`.\n      dest.subscribe(subscriber);\n\n      if (\n        !connection &&\n        // Check this shareReplay is still activate - it can be reset to 0\n        // and be \"unsubscribed\" _before_ it actually subscribes.\n        // If we were to subscribe then, it'd leak and get stuck.\n        refCount > 0\n      ) {\n        // We need to create a subscriber here - rather than pass an observer and\n        // assign the returned subscription to connection - because it's possible\n        // for reentrant subscriptions to the shared observable to occur and in\n        // those situations we want connection to be already-assigned so that we\n        // don't create another connection to the source.\n        connection = new SafeSubscriber({\n          next: (value) => dest.next(value),\n          error: (err) => {\n            hasErrored = true;\n            cancelReset();\n            resetConnection = handleReset(reset, resetOnError, err);\n            dest.error(err);\n          },\n          complete: () => {\n            hasCompleted = true;\n            cancelReset();\n            resetConnection = handleReset(reset, resetOnComplete);\n            dest.complete();\n          },\n        });\n        innerFrom(source).subscribe(connection);\n      }\n    })(wrapperSource);\n  };\n}\n\nfunction handleReset<T extends unknown[] = never[]>(\n  reset: () => void,\n  on: boolean | ((...args: T) => ObservableInput<any>),\n  ...args: T\n): Subscription | undefined {\n  if (on === true) {\n    reset();\n    return;\n  }\n\n  if (on === false) {\n    return;\n  }\n\n  const onSubscriber = new SafeSubscriber({\n    next: () => {\n      onSubscriber.unsubscribe();\n      reset();\n    },\n  });\n\n  return innerFrom(on(...args)).subscribe(onSubscriber);\n}\n", "import { ReplaySubject } from '../ReplaySubject';\nimport { MonoTypeOperatorFunction, SchedulerLike } from '../types';\nimport { share } from './share';\n\nexport interface ShareReplayConfig {\n  bufferSize?: number;\n  windowTime?: number;\n  refCount: boolean;\n  scheduler?: SchedulerLike;\n}\n\nexport function shareReplay<T>(config: ShareReplayConfig): MonoTypeOperatorFunction<T>;\nexport function shareReplay<T>(bufferSize?: number, windowTime?: number, scheduler?: SchedulerLike): MonoTypeOperatorFunction<T>;\n\n/**\n * Share source and replay specified number of emissions on subscription.\n *\n * This operator is a specialization of `replay` that connects to a source observable\n * and multicasts through a `ReplaySubject` constructed with the specified arguments.\n * A successfully completed source will stay cached in the `shareReplay`ed observable forever,\n * but an errored source can be retried.\n *\n * ## Why use `shareReplay`?\n *\n * You generally want to use `shareReplay` when you have side-effects or taxing computations\n * that you do not wish to be executed amongst multiple subscribers.\n * It may also be valuable in situations where you know you will have late subscribers to\n * a stream that need access to previously emitted values.\n * This ability to replay values on subscription is what differentiates {@link share} and `shareReplay`.\n *\n * ## Reference counting\n *\n * By default `shareReplay` will use `refCount` of false, meaning that it will _not_ unsubscribe the\n * source when the reference counter drops to zero, i.e. the inner `ReplaySubject` will _not_ be unsubscribed\n * (and potentially run for ever).\n * This is the default as it is expected that `shareReplay` is often used to keep around expensive to setup\n * observables which we want to keep running instead of having to do the expensive setup again.\n *\n * As of RXJS version 6.4.0 a new overload signature was added to allow for manual control over what\n * happens when the operators internal reference counter drops to zero.\n * If `refCount` is true, the source will be unsubscribed from once the reference count drops to zero, i.e.\n * the inner `ReplaySubject` will be unsubscribed. All new subscribers will receive value emissions from a\n * new `ReplaySubject` which in turn will cause a new subscription to the source observable.\n *\n * ## Examples\n *\n * Example with a third subscriber coming late to the party\n *\n * ```ts\n * import { interval, take, shareReplay } from 'rxjs';\n *\n * const shared$ = interval(2000).pipe(\n *   take(6),\n *   shareReplay(3)\n * );\n *\n * shared$.subscribe(x => console.log('sub A: ', x));\n * shared$.subscribe(y => console.log('sub B: ', y));\n *\n * setTimeout(() => {\n *   shared$.subscribe(y => console.log('sub C: ', y));\n * }, 11000);\n *\n * // Logs:\n * // (after ~2000 ms)\n * // sub A: 0\n * // sub B: 0\n * // (after ~4000 ms)\n * // sub A: 1\n * // sub B: 1\n * // (after ~6000 ms)\n * // sub A: 2\n * // sub B: 2\n * // (after ~8000 ms)\n * // sub A: 3\n * // sub B: 3\n * // (after ~10000 ms)\n * // sub A: 4\n * // sub B: 4\n * // (after ~11000 ms, sub C gets the last 3 values)\n * // sub C: 2\n * // sub C: 3\n * // sub C: 4\n * // (after ~12000 ms)\n * // sub A: 5\n * // sub B: 5\n * // sub C: 5\n * ```\n *\n * Example for `refCount` usage\n *\n * ```ts\n * import { Observable, tap, interval, shareReplay, take } from 'rxjs';\n *\n * const log = <T>(name: string, source: Observable<T>) => source.pipe(\n *   tap({\n *     subscribe: () => console.log(`${ name }: subscribed`),\n *     next: value => console.log(`${ name }: ${ value }`),\n *     complete: () => console.log(`${ name }: completed`),\n *     finalize: () => console.log(`${ name }: unsubscribed`)\n *   })\n * );\n *\n * const obs$ = log('source', interval(1000));\n *\n * const shared$ = log('shared', obs$.pipe(\n *   shareReplay({ bufferSize: 1, refCount: true }),\n *   take(2)\n * ));\n *\n * shared$.subscribe(x => console.log('sub A: ', x));\n * shared$.subscribe(y => console.log('sub B: ', y));\n *\n * // PRINTS:\n * // shared: subscribed <-- reference count = 1\n * // source: subscribed\n * // shared: subscribed <-- reference count = 2\n * // source: 0\n * // shared: 0\n * // sub A: 0\n * // shared: 0\n * // sub B: 0\n * // source: 1\n * // shared: 1\n * // sub A: 1\n * // shared: completed <-- take(2) completes the subscription for sub A\n * // shared: unsubscribed <-- reference count = 1\n * // shared: 1\n * // sub B: 1\n * // shared: completed <-- take(2) completes the subscription for sub B\n * // shared: unsubscribed <-- reference count = 0\n * // source: unsubscribed <-- replaySubject unsubscribes from source observable because the reference count dropped to 0 and refCount is true\n *\n * // In case of refCount being false, the unsubscribe is never called on the source and the source would keep on emitting, even if no subscribers\n * // are listening.\n * // source: 2\n * // source: 3\n * // source: 4\n * // ...\n * ```\n *\n * @see {@link publish}\n * @see {@link share}\n * @see {@link publishReplay}\n *\n * @param configOrBufferSize Maximum element count of the replay buffer or {@link ShareReplayConfig configuration}\n * object.\n * @param windowTime Maximum time length of the replay buffer in milliseconds.\n * @param scheduler Scheduler where connected observers within the selector function\n * will be invoked on.\n * @return A function that returns an Observable sequence that contains the\n * elements of a sequence produced by multicasting the source sequence within a\n * selector function.\n */\nexport function shareReplay<T>(\n  configOrBufferSize?: ShareReplayConfig | number,\n  windowTime?: number,\n  scheduler?: SchedulerLike\n): MonoTypeOperatorFunction<T> {\n  let bufferSize: number;\n  let refCount = false;\n  if (configOrBufferSize && typeof configOrBufferSize === 'object') {\n    ({ bufferSize = Infinity, windowTime = Infinity, refCount = false, scheduler } = configOrBufferSize);\n  } else {\n    bufferSize = (configOrBufferSize ?? Infinity) as number;\n  }\n  return share<T>({\n    connector: () => new ReplaySubject(bufferSize, windowTime, scheduler),\n    resetOnError: true,\n    resetOnComplete: false,\n    resetOnRefCountZero: refCount,\n  });\n}\n", "import { MonoTypeOperatorFunction } from '../types';\nimport { filter } from './filter';\n\n/**\n * Returns an Observable that skips the first `count` items emitted by the source Observable.\n *\n * ![](skip.png)\n *\n * Skips the values until the sent notifications are equal or less than provided skip count. It raises\n * an error if skip count is equal or more than the actual number of emits and source raises an error.\n *\n * ## Example\n *\n * Skip the values before the emission\n *\n * ```ts\n * import { interval, skip } from 'rxjs';\n *\n * // emit every half second\n * const source = interval(500);\n * // skip the first 10 emitted values\n * const result = source.pipe(skip(10));\n *\n * result.subscribe(value => console.log(value));\n * // output: 10...11...12...13...\n * ```\n *\n * @see {@link last}\n * @see {@link skipWhile}\n * @see {@link skipUntil}\n * @see {@link skipLast}\n *\n * @param {Number} count - The number of times, items emitted by source Observable should be skipped.\n * @return A function that returns an Observable that skips the first `count`\n * values emitted by the source Observable.\n */\nexport function skip<T>(count: number): MonoTypeOperatorFunction<T> {\n  return filter((_, index) => count <= index);\n}\n", "import { MonoTypeOperatorFunction, ObservableInput } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { innerFrom } from '../observable/innerFrom';\nimport { noop } from '../util/noop';\n\n/**\n * Returns an Observable that skips items emitted by the source Observable until a second Observable emits an item.\n *\n * The `skipUntil` operator causes the observable stream to skip the emission of values until the passed in observable\n * emits the first value. This can be particularly useful in combination with user interactions, responses of HTTP\n * requests or waiting for specific times to pass by.\n *\n * ![](skipUntil.png)\n *\n * Internally, the `skipUntil` operator subscribes to the passed in `notifier` `ObservableInput` (which gets converted\n * to an Observable) in order to recognize the emission of its first value. When `notifier` emits next, the operator\n * unsubscribes from it and starts emitting the values of the *source* observable until it completes or errors. It\n * will never let the *source* observable emit any values if the `notifier` completes or throws an error without\n * emitting a value before.\n *\n * ## Example\n *\n * In the following example, all emitted values of the interval observable are skipped until the user clicks anywhere\n * within the page\n *\n * ```ts\n * import { interval, fromEvent, skipUntil } from 'rxjs';\n *\n * const intervalObservable = interval(1000);\n * const click = fromEvent(document, 'click');\n *\n * const emitAfterClick = intervalObservable.pipe(\n *   skipUntil(click)\n * );\n * // clicked at 4.6s. output: 5...6...7...8........ or\n * // clicked at 7.3s. output: 8...9...10..11.......\n * emitAfterClick.subscribe(value => console.log(value));\n * ```\n *\n * @see {@link last}\n * @see {@link skip}\n * @see {@link skipWhile}\n * @see {@link skipLast}\n *\n * @param notifier An `ObservableInput` that has to emit an item before the source Observable elements begin to\n * be mirrored by the resulting Observable.\n * @return A function that returns an Observable that skips items from the\n * source Observable until the `notifier` Observable emits an item, then emits the\n * remaining items.\n */\nexport function skipUntil<T>(notifier: ObservableInput<any>): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    let taking = false;\n\n    const skipSubscriber = createOperatorSubscriber(\n      subscriber,\n      () => {\n        skipSubscriber?.unsubscribe();\n        taking = true;\n      },\n      noop\n    );\n\n    innerFrom(notifier).subscribe(skipSubscriber);\n\n    source.subscribe(createOperatorSubscriber(subscriber, (value) => taking && subscriber.next(value)));\n  });\n}\n", "import { concat } from '../observable/concat';\nimport { OperatorFunction, SchedulerLike, ValueFromArray } from '../types';\nimport { popScheduler } from '../util/args';\nimport { operate } from '../util/lift';\n\n// Devs are more likely to pass null or undefined than they are a scheduler\n// without accompanying values. To make things easier for (naughty) devs who\n// use the `strictNullChecks: false` TypeScript compiler option, these\n// overloads with explicit null and undefined values are included.\n\nexport function startWith<T>(value: null): OperatorFunction<T, T | null>;\nexport function startWith<T>(value: undefined): OperatorFunction<T, T | undefined>;\n\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `concatAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function startWith<T, A extends readonly unknown[] = T[]>(\n  ...valuesAndScheduler: [...A, SchedulerLike]\n): OperatorFunction<T, T | ValueFromArray<A>>;\nexport function startWith<T, A extends readonly unknown[] = T[]>(...values: A): OperatorFunction<T, T | ValueFromArray<A>>;\n\n/**\n * Returns an observable that, at the moment of subscription, will synchronously emit all\n * values provided to this operator, then subscribe to the source and mirror all of its emissions\n * to subscribers.\n *\n * This is a useful way to know when subscription has occurred on an existing observable.\n *\n * <span class=\"informal\">First emits its arguments in order, and then any\n * emissions from the source.</span>\n *\n * ![](startWith.png)\n *\n * ## Examples\n *\n * Emit a value when a timer starts.\n *\n * ```ts\n * import { timer, map, startWith } from 'rxjs';\n *\n * timer(1000)\n *   .pipe(\n *     map(() => 'timer emit'),\n *     startWith('timer start')\n *   )\n *   .subscribe(x => console.log(x));\n *\n * // results:\n * // 'timer start'\n * // 'timer emit'\n * ```\n *\n * @param values Items you want the modified Observable to emit first.\n * @return A function that returns an Observable that synchronously emits\n * provided values before subscribing to the source Observable.\n *\n * @see {@link endWith}\n * @see {@link finalize}\n * @see {@link concat}\n */\nexport function startWith<T, D>(...values: D[]): OperatorFunction<T, T | D> {\n  const scheduler = popScheduler(values);\n  return operate((source, subscriber) => {\n    // Here we can't pass `undefined` as a scheduler, because if we did, the\n    // code inside of `concat` would be confused by the `undefined`, and treat it\n    // like an invalid observable. So we have to split it two different ways.\n    (scheduler ? concat(values, source, scheduler) : concat(values, source)).subscribe(subscriber);\n  });\n}\n", "import { Subscriber } from '../Subscriber';\nimport { ObservableInput, OperatorFunction, ObservedValueOf } from '../types';\nimport { innerFrom } from '../observable/innerFrom';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/* tslint:disable:max-line-length */\nexport function switchMap<T, O extends ObservableInput<any>>(\n  project: (value: T, index: number) => O\n): OperatorFunction<T, ObservedValueOf<O>>;\n/** @deprecated The `resultSelector` parameter will be removed in v8. Use an inner `map` instead. Details: https://rxjs.dev/deprecations/resultSelector */\nexport function switchMap<T, O extends ObservableInput<any>>(\n  project: (value: T, index: number) => O,\n  resultSelector: undefined\n): OperatorFunction<T, ObservedValueOf<O>>;\n/** @deprecated The `resultSelector` parameter will be removed in v8. Use an inner `map` instead. Details: https://rxjs.dev/deprecations/resultSelector */\nexport function switchMap<T, R, O extends ObservableInput<any>>(\n  project: (value: T, index: number) => O,\n  resultSelector: (outerValue: T, innerValue: ObservedValueOf<O>, outerIndex: number, innerIndex: number) => R\n): OperatorFunction<T, R>;\n/* tslint:enable:max-line-length */\n\n/**\n * Projects each source value to an Observable which is merged in the output\n * Observable, emitting values only from the most recently projected Observable.\n *\n * <span class=\"informal\">Maps each value to an Observable, then flattens all of\n * these inner Observables using {@link switchAll}.</span>\n *\n * ![](switchMap.png)\n *\n * Returns an Observable that emits items based on applying a function that you\n * supply to each item emitted by the source Observable, where that function\n * returns an (so-called \"inner\") Observable. Each time it observes one of these\n * inner Observables, the output Observable begins emitting the items emitted by\n * that inner Observable. When a new inner Observable is emitted, `switchMap`\n * stops emitting items from the earlier-emitted inner Observable and begins\n * emitting items from the new one. It continues to behave like this for\n * subsequent inner Observables.\n *\n * ## Example\n *\n * Generate new Observable according to source Observable values\n *\n * ```ts\n * import { of, switchMap } from 'rxjs';\n *\n * const switched = of(1, 2, 3).pipe(switchMap(x => of(x, x ** 2, x ** 3)));\n * switched.subscribe(x => console.log(x));\n * // outputs\n * // 1\n * // 1\n * // 1\n * // 2\n * // 4\n * // 8\n * // 3\n * // 9\n * // 27\n * ```\n *\n * Restart an interval Observable on every click event\n *\n * ```ts\n * import { fromEvent, switchMap, interval } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(switchMap(() => interval(1000)));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link concatMap}\n * @see {@link exhaustMap}\n * @see {@link mergeMap}\n * @see {@link switchAll}\n * @see {@link switchMapTo}\n *\n * @param {function(value: T, index: number): ObservableInput} project A function\n * that, when applied to an item emitted by the source Observable, returns an\n * Observable.\n * @return A function that returns an Observable that emits the result of\n * applying the projection function (and the optional deprecated\n * `resultSelector`) to each item emitted by the source Observable and taking\n * only the values from the most recently projected inner Observable.\n */\nexport function switchMap<T, R, O extends ObservableInput<any>>(\n  project: (value: T, index: number) => O,\n  resultSelector?: (outerValue: T, innerValue: ObservedValueOf<O>, outerIndex: number, innerIndex: number) => R\n): OperatorFunction<T, ObservedValueOf<O> | R> {\n  return operate((source, subscriber) => {\n    let innerSubscriber: Subscriber<ObservedValueOf<O>> | null = null;\n    let index = 0;\n    // Whether or not the source subscription has completed\n    let isComplete = false;\n\n    // We only complete the result if the source is complete AND we don't have an active inner subscription.\n    // This is called both when the source completes and when the inners complete.\n    const checkComplete = () => isComplete && !innerSubscriber && subscriber.complete();\n\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value) => {\n          // Cancel the previous inner subscription if there was one\n          innerSubscriber?.unsubscribe();\n          let innerIndex = 0;\n          const outerIndex = index++;\n          // Start the next inner subscription\n          innerFrom(project(value, outerIndex)).subscribe(\n            (innerSubscriber = createOperatorSubscriber(\n              subscriber,\n              // When we get a new inner value, next it through. Note that this is\n              // handling the deprecate result selector here. This is because with this architecture\n              // it ends up being smaller than using the map operator.\n              (innerValue) => subscriber.next(resultSelector ? resultSelector(value, innerValue, outerIndex, innerIndex++) : innerValue),\n              () => {\n                // The inner has completed. Null out the inner subscriber to\n                // free up memory and to signal that we have no inner subscription\n                // currently.\n                innerSubscriber = null!;\n                checkComplete();\n              }\n            ))\n          );\n        },\n        () => {\n          isComplete = true;\n          checkComplete();\n        }\n      )\n    );\n  });\n}\n", "import { MonoTypeOperatorFunction, ObservableInput } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { innerFrom } from '../observable/innerFrom';\nimport { noop } from '../util/noop';\n\n/**\n * Emits the values emitted by the source Observable until a `notifier`\n * Observable emits a value.\n *\n * <span class=\"informal\">Lets values pass until a second Observable,\n * `notifier`, emits a value. Then, it completes.</span>\n *\n * ![](takeUntil.png)\n *\n * `takeUntil` subscribes and begins mirroring the source Observable. It also\n * monitors a second Observable, `notifier` that you provide. If the `notifier`\n * emits a value, the output Observable stops mirroring the source Observable\n * and completes. If the `notifier` doesn't emit any value and completes\n * then `takeUntil` will pass all values.\n *\n * ## Example\n *\n * Tick every second until the first click happens\n *\n * ```ts\n * import { interval, fromEvent, takeUntil } from 'rxjs';\n *\n * const source = interval(1000);\n * const clicks = fromEvent(document, 'click');\n * const result = source.pipe(takeUntil(clicks));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link take}\n * @see {@link takeLast}\n * @see {@link takeWhile}\n * @see {@link skip}\n *\n * @param {Observable} notifier The Observable whose first emitted value will\n * cause the output Observable of `takeUntil` to stop emitting values from the\n * source Observable.\n * @return A function that returns an Observable that emits the values from the\n * source Observable until `notifier` emits its first value.\n */\nexport function takeUntil<T>(notifier: ObservableInput<any>): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    innerFrom(notifier).subscribe(createOperatorSubscriber(subscriber, () => subscriber.complete(), noop));\n    !subscriber.closed && source.subscribe(subscriber);\n  });\n}\n", "import { OperatorFunction, MonoTypeOperatorFunction, TruthyTypesOf } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\nexport function takeWhile<T>(predicate: BooleanConstructor, inclusive: true): MonoTypeOperatorFunction<T>;\nexport function takeWhile<T>(predicate: BooleanConstructor, inclusive: false): OperatorFunction<T, TruthyTypesOf<T>>;\nexport function takeWhile<T>(predicate: BooleanConstructor): OperatorFunction<T, TruthyTypesOf<T>>;\nexport function takeWhile<T, S extends T>(predicate: (value: T, index: number) => value is S): OperatorFunction<T, S>;\nexport function takeWhile<T, S extends T>(predicate: (value: T, index: number) => value is S, inclusive: false): OperatorFunction<T, S>;\nexport function takeWhile<T>(predicate: (value: T, index: number) => boolean, inclusive?: boolean): MonoTypeOperatorFunction<T>;\n\n/**\n * Emits values emitted by the source Observable so long as each value satisfies\n * the given `predicate`, and then completes as soon as this `predicate` is not\n * satisfied.\n *\n * <span class=\"informal\">Takes values from the source only while they pass the\n * condition given. When the first value does not satisfy, it completes.</span>\n *\n * ![](takeWhile.png)\n *\n * `takeWhile` subscribes and begins mirroring the source Observable. Each value\n * emitted on the source is given to the `predicate` function which returns a\n * boolean, representing a condition to be satisfied by the source values. The\n * output Observable emits the source values until such time as the `predicate`\n * returns false, at which point `takeWhile` stops mirroring the source\n * Observable and completes the output Observable.\n *\n * ## Example\n *\n * Emit click events only while the clientX property is greater than 200\n *\n * ```ts\n * import { fromEvent, takeWhile } from 'rxjs';\n *\n * const clicks = fromEvent<PointerEvent>(document, 'click');\n * const result = clicks.pipe(takeWhile(ev => ev.clientX > 200));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link take}\n * @see {@link takeLast}\n * @see {@link takeUntil}\n * @see {@link skip}\n *\n * @param {function(value: T, index: number): boolean} predicate A function that\n * evaluates a value emitted by the source Observable and returns a boolean.\n * Also takes the (zero-based) index as the second argument.\n * @param {boolean} inclusive When set to `true` the value that caused\n * `predicate` to return `false` will also be emitted.\n * @return A function that returns an Observable that emits values from the\n * source Observable so long as each value satisfies the condition defined by\n * the `predicate`, then completes.\n */\nexport function takeWhile<T>(predicate: (value: T, index: number) => boolean, inclusive = false): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    let index = 0;\n    source.subscribe(\n      createOperatorSubscriber(subscriber, (value) => {\n        const result = predicate(value, index++);\n        (result || inclusive) && subscriber.next(value);\n        !result && subscriber.complete();\n      })\n    );\n  });\n}\n", "import { MonoTypeOperatorFunction, Observer } from '../types';\nimport { isFunction } from '../util/isFunction';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { identity } from '../util/identity';\n\n/**\n * An extension to the {@link Observer} interface used only by the {@link tap} operator.\n *\n * It provides a useful set of callbacks a user can register to do side-effects in\n * cases other than what the usual {@link Observer} callbacks are\n * ({@link guide/glossary-and-semantics#next next},\n * {@link guide/glossary-and-semantics#error error} and/or\n * {@link guide/glossary-and-semantics#complete complete}).\n *\n * ## Example\n *\n * ```ts\n * import { fromEvent, switchMap, tap, interval, take } from 'rxjs';\n *\n * const source$ = fromEvent(document, 'click');\n * const result$ = source$.pipe(\n *   switchMap((_, i) => i % 2 === 0\n *     ? fromEvent(document, 'mousemove').pipe(\n *         tap({\n *           subscribe: () => console.log('Subscribed to the mouse move events after click #' + i),\n *           unsubscribe: () => console.log('Mouse move events #' + i + ' unsubscribed'),\n *           finalize: () => console.log('Mouse move events #' + i + ' finalized')\n *         })\n *       )\n *     : interval(1_000).pipe(\n *         take(5),\n *         tap({\n *           subscribe: () => console.log('Subscribed to the 1-second interval events after click #' + i),\n *           unsubscribe: () => console.log('1-second interval events #' + i + ' unsubscribed'),\n *           finalize: () => console.log('1-second interval events #' + i + ' finalized')\n *         })\n *       )\n *   )\n * );\n *\n * const subscription = result$.subscribe({\n *   next: console.log\n * });\n *\n * setTimeout(() => {\n *   console.log('Unsubscribe after 60 seconds');\n *   subscription.unsubscribe();\n * }, 60_000);\n * ```\n */\nexport interface TapObserver<T> extends Observer<T> {\n  /**\n   * The callback that `tap` operator invokes at the moment when the source Observable\n   * gets subscribed to.\n   */\n  subscribe: () => void;\n  /**\n   * The callback that `tap` operator invokes when an explicit\n   * {@link guide/glossary-and-semantics#unsubscription unsubscribe} happens. It won't get invoked on\n   * `error` or `complete` events.\n   */\n  unsubscribe: () => void;\n  /**\n   * The callback that `tap` operator invokes when any kind of\n   * {@link guide/glossary-and-semantics#finalization finalization} happens - either when\n   * the source Observable `error`s or `complete`s or when it gets explicitly unsubscribed\n   * by the user. There is no difference in using this callback or the {@link finalize}\n   * operator, but if you're already using `tap` operator, you can use this callback\n   * instead. You'd get the same result in either case.\n   */\n  finalize: () => void;\n}\nexport function tap<T>(observerOrNext?: Partial<TapObserver<T>> | ((value: T) => void)): MonoTypeOperatorFunction<T>;\n/** @deprecated Instead of passing separate callback arguments, use an observer argument. Signatures taking separate callback arguments will be removed in v8. Details: https://rxjs.dev/deprecations/subscribe-arguments */\nexport function tap<T>(\n  next?: ((value: T) => void) | null,\n  error?: ((error: any) => void) | null,\n  complete?: (() => void) | null\n): MonoTypeOperatorFunction<T>;\n\n/**\n * Used to perform side-effects for notifications from the source observable\n *\n * <span class=\"informal\">Used when you want to affect outside state with a notification without altering the notification</span>\n *\n * ![](tap.png)\n *\n * Tap is designed to allow the developer a designated place to perform side effects. While you _could_ perform side-effects\n * inside of a `map` or a `mergeMap`, that would make their mapping functions impure, which isn't always a big deal, but will\n * make it so you can't do things like memoize those functions. The `tap` operator is designed solely for such side-effects to\n * help you remove side-effects from other operations.\n *\n * For any notification, next, error, or complete, `tap` will call the appropriate callback you have provided to it, via a function\n * reference, or a partial observer, then pass that notification down the stream.\n *\n * The observable returned by `tap` is an exact mirror of the source, with one exception: Any error that occurs -- synchronously -- in a handler\n * provided to `tap` will be emitted as an error from the returned observable.\n *\n * > Be careful! You can mutate objects as they pass through the `tap` operator's handlers.\n *\n * The most common use of `tap` is actually for debugging. You can place a `tap(console.log)` anywhere\n * in your observable `pipe`, log out the notifications as they are emitted by the source returned by the previous\n * operation.\n *\n * ## Examples\n *\n * Check a random number before it is handled. Below is an observable that will use a random number between 0 and 1,\n * and emit `'big'` or `'small'` depending on the size of that number. But we wanted to log what the original number\n * was, so we have added a `tap(console.log)`.\n *\n * ```ts\n * import { of, tap, map } from 'rxjs';\n *\n * of(Math.random()).pipe(\n *   tap(console.log),\n *   map(n => n > 0.5 ? 'big' : 'small')\n * ).subscribe(console.log);\n * ```\n *\n * Using `tap` to analyze a value and force an error. Below is an observable where in our system we only\n * want to emit numbers 3 or less we get from another source. We can force our observable to error\n * using `tap`.\n *\n * ```ts\n * import { of, tap } from 'rxjs';\n *\n * const source = of(1, 2, 3, 4, 5);\n *\n * source.pipe(\n *   tap(n => {\n *     if (n > 3) {\n *       throw new TypeError(`Value ${ n } is greater than 3`);\n *     }\n *   })\n * )\n * .subscribe({ next: console.log, error: err => console.log(err.message) });\n * ```\n *\n * We want to know when an observable completes before moving on to the next observable. The system\n * below will emit a random series of `'X'` characters from 3 different observables in sequence. The\n * only way we know when one observable completes and moves to the next one, in this case, is because\n * we have added a `tap` with the side effect of logging to console.\n *\n * ```ts\n * import { of, concatMap, interval, take, map, tap } from 'rxjs';\n *\n * of(1, 2, 3).pipe(\n *   concatMap(n => interval(1000).pipe(\n *     take(Math.round(Math.random() * 10)),\n *     map(() => 'X'),\n *     tap({ complete: () => console.log(`Done with ${ n }`) })\n *   ))\n * )\n * .subscribe(console.log);\n * ```\n *\n * @see {@link finalize}\n * @see {@link TapObserver}\n *\n * @param observerOrNext A next handler or partial observer\n * @param error An error handler\n * @param complete A completion handler\n * @return A function that returns an Observable identical to the source, but\n * runs the specified Observer or callback(s) for each item.\n */\nexport function tap<T>(\n  observerOrNext?: Partial<TapObserver<T>> | ((value: T) => void) | null,\n  error?: ((e: any) => void) | null,\n  complete?: (() => void) | null\n): MonoTypeOperatorFunction<T> {\n  // We have to check to see not only if next is a function,\n  // but if error or complete were passed. This is because someone\n  // could technically call tap like `tap(null, fn)` or `tap(null, null, fn)`.\n  const tapObserver =\n    isFunction(observerOrNext) || error || complete\n      ? // tslint:disable-next-line: no-object-literal-type-assertion\n        ({ next: observerOrNext as Exclude<typeof observerOrNext, Partial<TapObserver<T>>>, error, complete } as Partial<TapObserver<T>>)\n      : observerOrNext;\n\n  return tapObserver\n    ? operate((source, subscriber) => {\n        tapObserver.subscribe?.();\n        let isUnsub = true;\n        source.subscribe(\n          createOperatorSubscriber(\n            subscriber,\n            (value) => {\n              tapObserver.next?.(value);\n              subscriber.next(value);\n            },\n            () => {\n              isUnsub = false;\n              tapObserver.complete?.();\n              subscriber.complete();\n            },\n            (err) => {\n              isUnsub = false;\n              tapObserver.error?.(err);\n              subscriber.error(err);\n            },\n            () => {\n              if (isUnsub) {\n                tapObserver.unsubscribe?.();\n              }\n              tapObserver.finalize?.();\n            }\n          )\n        );\n      })\n    : // Tap was called with no valid tap observer or handler\n      // (e.g. `tap(null, null, null)` or `tap(null)` or `tap()`)\n      // so we're going to just mirror the source.\n      identity;\n}\n", "import { Subscription } from '../Subscription';\n\nimport { MonoTypeOperatorFunction, ObservableInput } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { innerFrom } from '../observable/innerFrom';\n\n/**\n * An object interface used by {@link throttle} or {@link throttleTime} that ensure\n * configuration options of these operators.\n *\n * @see {@link throttle}\n * @see {@link throttleTime}\n */\nexport interface ThrottleConfig {\n  /**\n   * If `true`, the resulting Observable will emit the first value from the source\n   * Observable at the **start** of the \"throttling\" process (when starting an\n   * internal timer that prevents other emissions from the source to pass through).\n   * If `false`, it will not emit the first value from the source Observable at the\n   * start of the \"throttling\" process.\n   *\n   * If not provided, defaults to: `true`.\n   */\n  leading?: boolean;\n  /**\n   * If `true`, the resulting Observable will emit the last value from the source\n   * Observable at the **end** of the \"throttling\" process (when ending an internal\n   * timer that prevents other emissions from the source to pass through).\n   * If `false`, it will not emit the last value from the source Observable at the\n   * end of the \"throttling\" process.\n   *\n   * If not provided, defaults to: `false`.\n   */\n  trailing?: boolean;\n}\n\n/**\n * Emits a value from the source Observable, then ignores subsequent source\n * values for a duration determined by another Observable, then repeats this\n * process.\n *\n * <span class=\"informal\">It's like {@link throttleTime}, but the silencing\n * duration is determined by a second Observable.</span>\n *\n * ![](throttle.svg)\n *\n * `throttle` emits the source Observable values on the output Observable\n * when its internal timer is disabled, and ignores source values when the timer\n * is enabled. Initially, the timer is disabled. As soon as the first source\n * value arrives, it is forwarded to the output Observable, and then the timer\n * is enabled by calling the `durationSelector` function with the source value,\n * which returns the \"duration\" Observable. When the duration Observable emits a\n * value, the timer is disabled, and this process repeats for the\n * next source value.\n *\n * ## Example\n *\n * Emit clicks at a rate of at most one click per second\n *\n * ```ts\n * import { fromEvent, throttle, interval } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(throttle(() => interval(1000)));\n *\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link audit}\n * @see {@link debounce}\n * @see {@link delayWhen}\n * @see {@link sample}\n * @see {@link throttleTime}\n *\n * @param durationSelector A function that receives a value from the source\n * Observable, for computing the silencing duration for each source value,\n * returned as an `ObservableInput`.\n * @param config A configuration object to define `leading` and `trailing`\n * behavior. Defaults to `{ leading: true, trailing: false }`.\n * @return A function that returns an Observable that performs the throttle\n * operation to limit the rate of emissions from the source.\n */\nexport function throttle<T>(durationSelector: (value: T) => ObservableInput<any>, config?: ThrottleConfig): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    const { leading = true, trailing = false } = config ?? {};\n    let hasValue = false;\n    let sendValue: T | null = null;\n    let throttled: Subscription | null = null;\n    let isComplete = false;\n\n    const endThrottling = () => {\n      throttled?.unsubscribe();\n      throttled = null;\n      if (trailing) {\n        send();\n        isComplete && subscriber.complete();\n      }\n    };\n\n    const cleanupThrottling = () => {\n      throttled = null;\n      isComplete && subscriber.complete();\n    };\n\n    const startThrottle = (value: T) =>\n      (throttled = innerFrom(durationSelector(value)).subscribe(createOperatorSubscriber(subscriber, endThrottling, cleanupThrottling)));\n\n    const send = () => {\n      if (hasValue) {\n        // Ensure we clear out our value and hasValue flag\n        // before we emit, otherwise reentrant code can cause\n        // issues here.\n        hasValue = false;\n        const value = sendValue!;\n        sendValue = null;\n        // Emit the value.\n        subscriber.next(value);\n        !isComplete && startThrottle(value);\n      }\n    };\n\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        // Regarding the presence of throttled.closed in the following\n        // conditions, if a synchronous duration selector is specified - weird,\n        // but legal - an already-closed subscription will be assigned to\n        // throttled, so the subscription's closed property needs to be checked,\n        // too.\n        (value) => {\n          hasValue = true;\n          sendValue = value;\n          !(throttled && !throttled.closed) && (leading ? send() : startThrottle(value));\n        },\n        () => {\n          isComplete = true;\n          !(trailing && hasValue && throttled && !throttled.closed) && subscriber.complete();\n        }\n      )\n    );\n  });\n}\n", "import { asyncScheduler } from '../scheduler/async';\nimport { throttle, ThrottleConfig } from './throttle';\nimport { MonoTypeOperatorFunction, SchedulerLike } from '../types';\nimport { timer } from '../observable/timer';\n\n/**\n * Emits a value from the source Observable, then ignores subsequent source\n * values for `duration` milliseconds, then repeats this process.\n *\n * <span class=\"informal\">Lets a value pass, then ignores source values for the\n * next `duration` milliseconds.</span>\n *\n * ![](throttleTime.png)\n *\n * `throttleTime` emits the source Observable values on the output Observable\n * when its internal timer is disabled, and ignores source values when the timer\n * is enabled. Initially, the timer is disabled. As soon as the first source\n * value arrives, it is forwarded to the output Observable, and then the timer\n * is enabled. After `duration` milliseconds (or the time unit determined\n * internally by the optional `scheduler`) has passed, the timer is disabled,\n * and this process repeats for the next source value. Optionally takes a\n * {@link SchedulerLike} for managing timers.\n *\n * ## Examples\n *\n * ### Limit click rate\n *\n * Emit clicks at a rate of at most one click per second\n *\n * ```ts\n * import { fromEvent, throttleTime } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(throttleTime(1000));\n *\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link auditTime}\n * @see {@link debounceTime}\n * @see {@link delay}\n * @see {@link sampleTime}\n * @see {@link throttle}\n *\n * @param duration Time to wait before emitting another value after\n * emitting the last value, measured in milliseconds or the time unit determined\n * internally by the optional `scheduler`.\n * @param scheduler The {@link SchedulerLike} to use for\n * managing the timers that handle the throttling. Defaults to {@link asyncScheduler}.\n * @param config A configuration object to define `leading` and\n * `trailing` behavior. Defaults to `{ leading: true, trailing: false }`.\n * @return A function that returns an Observable that performs the throttle\n * operation to limit the rate of emissions from the source.\n */\nexport function throttleTime<T>(\n  duration: number,\n  scheduler: SchedulerLike = asyncScheduler,\n  config?: ThrottleConfig\n): MonoTypeOperatorFunction<T> {\n  const duration$ = timer(duration, scheduler);\n  return throttle(() => duration$, config);\n}\n", "import { OperatorFunction, ObservableInputTuple } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { innerFrom } from '../observable/innerFrom';\nimport { identity } from '../util/identity';\nimport { noop } from '../util/noop';\nimport { popResultSelector } from '../util/args';\n\nexport function withLatestFrom<T, O extends unknown[]>(...inputs: [...ObservableInputTuple<O>]): OperatorFunction<T, [T, ...O]>;\n\nexport function withLatestFrom<T, O extends unknown[], R>(\n  ...inputs: [...ObservableInputTuple<O>, (...value: [T, ...O]) => R]\n): OperatorFunction<T, R>;\n\n/**\n * Combines the source Observable with other Observables to create an Observable\n * whose values are calculated from the latest values of each, only when the\n * source emits.\n *\n * <span class=\"informal\">Whenever the source Observable emits a value, it\n * computes a formula using that value plus the latest values from other input\n * Observables, then emits the output of that formula.</span>\n *\n * ![](withLatestFrom.png)\n *\n * `withLatestFrom` combines each value from the source Observable (the\n * instance) with the latest values from the other input Observables only when\n * the source emits a value, optionally using a `project` function to determine\n * the value to be emitted on the output Observable. All input Observables must\n * emit at least one value before the output Observable will emit a value.\n *\n * ## Example\n *\n * On every click event, emit an array with the latest timer event plus the click event\n *\n * ```ts\n * import { fromEvent, interval, withLatestFrom } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const timer = interval(1000);\n * const result = clicks.pipe(withLatestFrom(timer));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link combineLatest}\n *\n * @param {ObservableInput} other An input Observable to combine with the source\n * Observable. More than one input Observables may be given as argument.\n * @param {Function} [project] Projection function for combining values\n * together. Receives all values in order of the Observables passed, where the\n * first parameter is a value from the source Observable. (e.g.\n * `a.pipe(withLatestFrom(b, c), map(([a1, b1, c1]) => a1 + b1 + c1))`). If this is not\n * passed, arrays will be emitted on the output Observable.\n * @return A function that returns an Observable of projected values from the\n * most recent values from each input Observable, or an array of the most\n * recent values from each input Observable.\n */\nexport function withLatestFrom<T, R>(...inputs: any[]): OperatorFunction<T, R | any[]> {\n  const project = popResultSelector(inputs) as ((...args: any[]) => R) | undefined;\n\n  return operate((source, subscriber) => {\n    const len = inputs.length;\n    const otherValues = new Array(len);\n    // An array of whether or not the other sources have emitted. Matched with them by index.\n    // TODO: At somepoint, we should investigate the performance implications here, and look\n    // into using a `Set()` and checking the `size` to see if we're ready.\n    let hasValue = inputs.map(() => false);\n    // Flipped true when we have at least one value from all other sources and\n    // we are ready to start emitting values.\n    let ready = false;\n\n    // Other sources. Note that here we are not checking `subscriber.closed`,\n    // this causes all inputs to be subscribed to, even if nothing can be emitted\n    // from them. This is an important distinction because subscription constitutes\n    // a side-effect.\n    for (let i = 0; i < len; i++) {\n      innerFrom(inputs[i]).subscribe(\n        createOperatorSubscriber(\n          subscriber,\n          (value) => {\n            otherValues[i] = value;\n            if (!ready && !hasValue[i]) {\n              // If we're not ready yet, flag to show this observable has emitted.\n              hasValue[i] = true;\n              // Intentionally terse code.\n              // If all of our other observables have emitted, set `ready` to `true`,\n              // so we know we can start emitting values, then clean up the `hasValue` array,\n              // because we don't need it anymore.\n              (ready = hasValue.every(identity)) && (hasValue = null!);\n            }\n          },\n          // Completing one of the other sources has\n          // no bearing on the completion of our result.\n          noop\n        )\n      );\n    }\n\n    // Source subscription\n    source.subscribe(\n      createOperatorSubscriber(subscriber, (value) => {\n        if (ready) {\n          // We have at least one value from the other sources. Go ahead and emit.\n          const values = [value, ...otherValues];\n          subscriber.next(project ? project(...values) : values);\n        }\n      })\n    );\n  });\n}\n", "import { zip as zipStatic } from '../observable/zip';\nimport { ObservableInput, ObservableInputTuple, OperatorFunction, Cons } from '../types';\nimport { operate } from '../util/lift';\n\n/** @deprecated Replaced with {@link zipWith}. Will be removed in v8. */\nexport function zip<T, A extends readonly unknown[]>(otherInputs: [...ObservableInputTuple<A>]): OperatorFunction<T, Cons<T, A>>;\n/** @deprecated Replaced with {@link zipWith}. Will be removed in v8. */\nexport function zip<T, A extends readonly unknown[], R>(\n  otherInputsAndProject: [...ObservableInputTuple<A>],\n  project: (...values: Cons<T, A>) => R\n): OperatorFunction<T, R>;\n/** @deprecated Replaced with {@link zipWith}. Will be removed in v8. */\nexport function zip<T, A extends readonly unknown[]>(...otherInputs: [...ObservableInputTuple<A>]): OperatorFunction<T, Cons<T, A>>;\n/** @deprecated Replaced with {@link zipWith}. Will be removed in v8. */\nexport function zip<T, A extends readonly unknown[], R>(\n  ...otherInputsAndProject: [...ObservableInputTuple<A>, (...values: Cons<T, A>) => R]\n): OperatorFunction<T, R>;\n\n/**\n * @deprecated Replaced with {@link zipWith}. Will be removed in v8.\n */\nexport function zip<T, R>(...sources: Array<ObservableInput<any> | ((...values: Array<any>) => R)>): OperatorFunction<T, any> {\n  return operate((source, subscriber) => {\n    zipStatic(source as ObservableInput<any>, ...(sources as Array<ObservableInput<any>>)).subscribe(subscriber);\n  });\n}\n", "import { ObservableInputTuple, OperatorFunction, Cons } from '../types';\nimport { zip } from './zip';\n\n/**\n * Subscribes to the source, and the observable inputs provided as arguments, and combines their values, by index, into arrays.\n *\n * What is meant by \"combine by index\": The first value from each will be made into a single array, then emitted,\n * then the second value from each will be combined into a single array and emitted, then the third value\n * from each will be combined into a single array and emitted, and so on.\n *\n * This will continue until it is no longer able to combine values of the same index into an array.\n *\n * After the last value from any one completed source is emitted in an array, the resulting observable will complete,\n * as there is no way to continue \"zipping\" values together by index.\n *\n * Use-cases for this operator are limited. There are memory concerns if one of the streams is emitting\n * values at a much faster rate than the others. Usage should likely be limited to streams that emit\n * at a similar pace, or finite streams of known length.\n *\n * In many cases, authors want `combineLatestWith` and not `zipWith`.\n *\n * @param otherInputs other observable inputs to collate values from.\n * @return A function that returns an Observable that emits items by index\n * combined from the source Observable and provided Observables, in form of an\n * array.\n */\nexport function zipWith<T, A extends readonly unknown[]>(...otherInputs: [...ObservableInputTuple<A>]): OperatorFunction<T, Cons<T, A>> {\n  return zip(...otherInputs);\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  ReplaySubject,\n  Subject,\n  fromEvent\n} from \"rxjs\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch document\n *\n * Documents are implemented as subjects, so all downstream observables are\n * automatically updated when a new document is emitted.\n *\n * @returns Document subject\n */\nexport function watchDocument(): Subject<Document> {\n  const document$ = new ReplaySubject<Document>(1)\n  fromEvent(document, \"DOMContentLoaded\", { once: true })\n    .subscribe(() => document$.next(document))\n\n  /* Return document */\n  return document$\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve all elements matching the query selector\n *\n * @template T - Element type\n *\n * @param selector - Query selector\n * @param node - Node of reference\n *\n * @returns Elements\n */\nexport function getElements<T extends keyof HTMLElementTagNameMap>(\n  selector: T, node?: ParentNode\n): HTMLElementTagNameMap[T][]\n\nexport function getElements<T extends HTMLElement>(\n  selector: string, node?: ParentNode\n): T[]\n\nexport function getElements<T extends HTMLElement>(\n  selector: string, node: ParentNode = document\n): T[] {\n  return Array.from(node.querySelectorAll<T>(selector))\n}\n\n/**\n * Retrieve an element matching a query selector or throw a reference error\n *\n * Note that this function assumes that the element is present. If unsure if an\n * element is existent, use the `getOptionalElement` function instead.\n *\n * @template T - Element type\n *\n * @param selector - Query selector\n * @param node - Node of reference\n *\n * @returns Element\n */\nexport function getElement<T extends keyof HTMLElementTagNameMap>(\n  selector: T, node?: ParentNode\n): HTMLElementTagNameMap[T]\n\nexport function getElement<T extends HTMLElement>(\n  selector: string, node?: ParentNode\n): T\n\nexport function getElement<T extends HTMLElement>(\n  selector: string, node: ParentNode = document\n): T {\n  const el = getOptionalElement<T>(selector, node)\n  if (typeof el === \"undefined\")\n    throw new ReferenceError(\n      `Missing element: expected \"${selector}\" to be present`\n    )\n\n  /* Return element */\n  return el\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Retrieve an optional element matching the query selector\n *\n * @template T - Element type\n *\n * @param selector - Query selector\n * @param node - Node of reference\n *\n * @returns Element or nothing\n */\nexport function getOptionalElement<T extends keyof HTMLElementTagNameMap>(\n  selector: T, node?: ParentNode\n): HTMLElementTagNameMap[T] | undefined\n\nexport function getOptionalElement<T extends HTMLElement>(\n  selector: string, node?: ParentNode\n): T | undefined\n\nexport function getOptionalElement<T extends HTMLElement>(\n  selector: string, node: ParentNode = document\n): T | undefined {\n  return node.querySelector<T>(selector) || undefined\n}\n\n/**\n * Retrieve the currently active element\n *\n * @returns Element or nothing\n */\nexport function getActiveElement(): HTMLElement | undefined {\n  return (\n    document.activeElement?.shadowRoot?.activeElement as HTMLElement ??\n    document.activeElement as HTMLElement ??\n    undefined\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  debounceTime,\n  distinctUntilChanged,\n  fromEvent,\n  map,\n  merge,\n  shareReplay,\n  startWith\n} from \"rxjs\"\n\nimport { getActiveElement } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Focus observable\n *\n * Previously, this observer used `focus` and `blur` events to determine whether\n * an element is focused, but this doesn't work if there are focusable elements\n * within the elements itself. A better solutions are `focusin` and `focusout`\n * events, which bubble up the tree and allow for more fine-grained control.\n *\n * `debounceTime` is necessary, because when a focus change happens inside an\n * element, the observable would first emit `false` and then `true` again.\n */\nconst observer$ = merge(\n  fromEvent(document.body, \"focusin\"),\n  fromEvent(document.body, \"focusout\")\n)\n  .pipe(\n    debounceTime(1),\n    startWith(undefined),\n    map(() => getActiveElement() || document.body),\n    shareReplay(1)\n  )\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch element focus\n *\n * @param el - Element\n *\n * @returns Element focus observable\n */\nexport function watchElementFocus(\n  el: HTMLElement\n): Observable<boolean> {\n  return observer$\n    .pipe(\n      map(active => el.contains(active)),\n      distinctUntilChanged()\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  debounce,\n  defer,\n  fromEvent,\n  identity,\n  map,\n  merge,\n  startWith,\n  timer\n} from \"rxjs\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch element hover\n *\n * The second parameter allows to specify a timeout in milliseconds after which\n * the hover state will be reset to `false`. This is useful for tooltips which\n * should disappear after a certain amount of time, in order to allow the user\n * to move the cursor from the host to the tooltip.\n *\n * @param el - Element\n * @param timeout - Timeout\n *\n * @returns Element hover observable\n */\nexport function watchElementHover(\n  el: HTMLElement, timeout?: number\n): Observable<boolean> {\n  return defer(() => merge(\n    fromEvent(el, \"mouseenter\").pipe(map(() => true)),\n    fromEvent(el, \"mouseleave\").pipe(map(() => false))\n  )\n    .pipe(\n      timeout ? debounce(active => timer(+!active * timeout)) : identity,\n      startWith(el.matches(\":hover\"))\n    )\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { JSX as JSXInternal } from \"preact\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * HTML attributes\n */\ntype Attributes =\n  & JSXInternal.HTMLAttributes\n  & JSXInternal.SVGAttributes\n  & Record<string, any>\n\n/**\n * Child element\n */\ntype Child =\n  | ChildNode\n  | HTMLElement\n  | Text\n  | string\n  | number\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Append a child node to an element\n *\n * @param el - Element\n * @param child - Child node(s)\n */\nfunction appendChild(el: HTMLElement, child: Child | Child[]): void {\n\n  /* Handle primitive types (including raw HTML) */\n  if (typeof child === \"string\" || typeof child === \"number\") {\n    el.innerHTML += child.toString()\n\n  /* Handle nodes */\n  } else if (child instanceof Node) {\n    el.appendChild(child)\n\n  /* Handle nested children */\n  } else if (Array.isArray(child)) {\n    for (const node of child)\n      appendChild(el, node)\n  }\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * JSX factory\n *\n * @template T - Element type\n *\n * @param tag - HTML tag\n * @param attributes - HTML attributes\n * @param children - Child elements\n *\n * @returns Element\n */\nexport function h<T extends keyof HTMLElementTagNameMap>(\n  tag: T, attributes?: Attributes | null, ...children: Child[]\n): HTMLElementTagNameMap[T]\n\nexport function h<T extends h.JSX.Element>(\n  tag: string, attributes?: Attributes | null, ...children: Child[]\n): T\n\nexport function h<T extends h.JSX.Element>(\n  tag: string, attributes?: Attributes | null, ...children: Child[]\n): T {\n  const el = document.createElement(tag)\n\n  /* Set attributes, if any */\n  if (attributes)\n    for (const attr of Object.keys(attributes)) {\n      if (typeof attributes[attr] === \"undefined\")\n        continue\n\n      /* Set default attribute or boolean */\n      if (typeof attributes[attr] !== \"boolean\")\n        el.setAttribute(attr, attributes[attr])\n      else\n        el.setAttribute(attr, \"\")\n    }\n\n  /* Append child nodes */\n  for (const child of children)\n    appendChild(el, child)\n\n  /* Return element */\n  return el as T\n}\n\n/* ----------------------------------------------------------------------------\n * Namespace\n * ------------------------------------------------------------------------- */\n\nexport declare namespace h {\n  namespace JSX {\n    type Element = HTMLElement\n    type IntrinsicElements = JSXInternal.IntrinsicElements\n  }\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Round a number for display with repository facts\n *\n * This is a reverse-engineered version of GitHub's weird rounding algorithm\n * for stars, forks and all other numbers. While all numbers below `1,000` are\n * returned as-is, bigger numbers are converted to fixed numbers:\n *\n * - `1,049` => `1k`\n * - `1,050` => `1.1k`\n * - `1,949` => `1.9k`\n * - `1,950` => `2k`\n *\n * @param value - Original value\n *\n * @returns Rounded value\n */\nexport function round(value: number): string {\n  if (value > 999) {\n    const digits = +((value - 950) % 1000 > 99)\n    return `${((value + 0.000001) / 1000).toFixed(digits)}k`\n  } else {\n    return value.toString()\n  }\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  defer,\n  finalize,\n  fromEvent,\n  map,\n  merge,\n  switchMap,\n  take,\n  throwError\n} from \"rxjs\"\n\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Create and load a `script` element\n *\n * This function returns an observable that will emit when the script was\n * successfully loaded, or throw an error if it wasn't.\n *\n * @param src - Script URL\n *\n * @returns Script observable\n */\nexport function watchScript(src: string): Observable<void> {\n  const script = h(\"script\", { src })\n  return defer(() => {\n    document.head.appendChild(script)\n    return merge(\n      fromEvent(script, \"load\"),\n      fromEvent(script, \"error\")\n        .pipe(\n          switchMap(() => (\n            throwError(() => new ReferenceError(`Invalid script: ${src}`))\n          ))\n        )\n    )\n      .pipe(\n        map(() => undefined),\n        finalize(() => document.head.removeChild(script)),\n        take(1)\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  NEVER,\n  Observable,\n  Subject,\n  defer,\n  filter,\n  finalize,\n  map,\n  merge,\n  of,\n  shareReplay,\n  startWith,\n  switchMap,\n  tap\n} from \"rxjs\"\n\nimport { watchScript } from \"../../../script\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Element offset\n */\nexport interface ElementSize {\n  width: number                        /* Element width */\n  height: number                       /* Element height */\n}\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Resize observer entry subject\n */\nconst entry$ = new Subject<ResizeObserverEntry>()\n\n/**\n * Resize observer observable\n *\n * This observable will create a `ResizeObserver` on the first subscription\n * and will automatically terminate it when there are no more subscribers.\n * It's quite important to centralize observation in a single `ResizeObserver`,\n * as the performance difference can be quite dramatic, as the link shows.\n *\n * If the browser doesn't have a `ResizeObserver` implementation available, a\n * polyfill is automatically downloaded from unpkg.com. This is also compatible\n * with the built-in privacy plugin, which will download the polyfill and put\n * it alongside the built site for self-hosting.\n *\n * @see https://bit.ly/3iIYfEm - Google Groups on performance\n */\nconst observer$ = defer(() => (\n  typeof ResizeObserver === \"undefined\"\n    ? watchScript(\"https://unpkg.com/resize-observer-polyfill\")\n    : of(undefined)\n))\n  .pipe(\n    map(() => new ResizeObserver(entries => (\n      entries.forEach(entry => entry$.next(entry))\n    ))),\n    switchMap(observer => merge(NEVER, of(observer)).pipe(\n      finalize(() => observer.disconnect())\n    )),\n    shareReplay(1)\n  )\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve element size\n *\n * @param el - Element\n *\n * @returns Element size\n */\nexport function getElementSize(\n  el: HTMLElement\n): ElementSize {\n  return {\n    width:  el.offsetWidth,\n    height: el.offsetHeight\n  }\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Watch element size\n *\n * This function returns an observable that subscribes to a single internal\n * instance of `ResizeObserver` upon subscription, and emit resize events until\n * termination. Note that this function should not be called with the same\n * element twice, as the first unsubscription will terminate observation.\n *\n * Sadly, we can't use the `DOMRect` objects returned by the observer, because\n * we need the emitted values to be consistent with `getElementSize`, which will\n * return the used values (rounded) and not actual values (unrounded). Thus, we\n * use the `offset*` properties. See the linked GitHub issue.\n *\n * @see https://bit.ly/3m0k3he - GitHub issue\n *\n * @param el - Element\n *\n * @returns Element size observable\n */\nexport function watchElementSize(\n  el: HTMLElement\n): Observable<ElementSize> {\n\n  // Compute target element - since inline elements cannot be observed by the\n  // current `ResizeObserver` implementation as provided by browsers, we need\n  // to determine the first containing parent element and use that one as a\n  // target, while we always compute the actual size from the element.\n  let target = el\n  while (target.clientWidth === 0)\n    if (target.parentElement)\n      target = target.parentElement\n    else\n      break\n\n  // Observe target element and recompute element size on resize - as described\n  // above, the target element is not necessarily the element of interest\n  return observer$.pipe(\n    tap(observer => observer.observe(target)),\n    switchMap(observer => entry$.pipe(\n      filter(entry => entry.target === target),\n      finalize(() => observer.unobserve(target))\n    )),\n    map(() => getElementSize(el)),\n    startWith(getElementSize(el))\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { ElementSize } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve element content size (= scroll width and height)\n *\n * @param el - Element\n *\n * @returns Element content size\n */\nexport function getElementContentSize(\n  el: HTMLElement\n): ElementSize {\n  return {\n    width:  el.scrollWidth,\n    height: el.scrollHeight\n  }\n}\n\n/**\n * Retrieve the overflowing container of an element, if any\n *\n * @param el - Element\n *\n * @returns Overflowing container or nothing\n */\nexport function getElementContainer(\n  el: HTMLElement\n): HTMLElement | undefined {\n  let parent = el.parentElement\n  while (parent)\n    if (\n      el.scrollWidth  <= parent.scrollWidth &&\n      el.scrollHeight <= parent.scrollHeight\n    )\n      parent = (el = parent).parentElement\n    else\n      break\n\n  /* Return overflowing container */\n  return parent ? el : undefined\n}\n\n/**\n * Retrieve all overflowing containers of an element, if any\n *\n * Note that this function has a slightly different behavior, so we should at\n * some point consider refactoring how overflowing containers are handled.\n *\n * @param el - Element\n *\n * @returns Overflowing containers\n */\nexport function getElementContainers(\n  el: HTMLElement\n): HTMLElement[] {\n  const containers: HTMLElement[] = []\n\n  // Walk up the DOM tree until we find an overflowing container\n  let parent = el.parentElement\n  while (parent) {\n    if (\n      el.clientWidth  > parent.clientWidth ||\n      el.clientHeight > parent.clientHeight\n    )\n      containers.push(parent)\n\n    // Continue with parent element\n    parent = (el = parent).parentElement\n  }\n\n  // If the page is short, the body might not be overflowing and there might be\n  // no other containers, which is why we need to make sure the body is present\n  if (containers.length === 0)\n    containers.push(document.documentElement)\n\n  // Return overflowing containers\n  return containers\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  animationFrameScheduler,\n  auditTime,\n  fromEvent,\n  map,\n  merge,\n  startWith\n} from \"rxjs\"\n\nimport { watchElementSize } from \"../../size\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Element offset\n */\nexport interface ElementOffset {\n  x: number                            /* Horizontal offset */\n  y: number                            /* Vertical offset */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve element offset\n *\n * @param el - Element\n *\n * @returns Element offset\n */\nexport function getElementOffset(\n  el: HTMLElement\n): ElementOffset {\n  return {\n    x: el.offsetLeft,\n    y: el.offsetTop\n  }\n}\n\n/**\n * Retrieve absolute element offset\n *\n * @param el - Element\n *\n * @returns Element offset\n */\nexport function getElementOffsetAbsolute(\n  el: HTMLElement\n): ElementOffset {\n  const rect = el.getBoundingClientRect()\n  return {\n    x: rect.x + window.scrollX,\n    y: rect.y + window.scrollY\n  }\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Watch element offset\n *\n * @param el - Element\n *\n * @returns Element offset observable\n */\nexport function watchElementOffset(\n  el: HTMLElement\n): Observable<ElementOffset> {\n  return merge(\n    fromEvent(window, \"load\"),\n    fromEvent(window, \"resize\")\n  )\n    .pipe(\n      auditTime(0, animationFrameScheduler),\n      map(() => getElementOffset(el)),\n      startWith(getElementOffset(el))\n    )\n}\n\n/**\n * Watch absolute element offset\n *\n * @param el - Element\n *\n * @returns Element offset observable\n */\nexport function watchElementOffsetAbsolute(\n  el: HTMLElement\n): Observable<ElementOffset> {\n  return merge(\n    watchElementOffset(el),\n    watchElementSize(document.body) // @todo find a better way for this\n  )\n    .pipe(\n      map(() => getElementOffsetAbsolute(el)),\n      startWith(getElementOffsetAbsolute(el))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  animationFrameScheduler,\n  auditTime,\n  fromEvent,\n  map,\n  merge,\n  startWith\n} from \"rxjs\"\n\nimport { ElementOffset } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve element content offset (= scroll offset)\n *\n * @param el - Element\n *\n * @returns Element content offset\n */\nexport function getElementContentOffset(\n  el: HTMLElement\n): ElementOffset {\n  return {\n    x: el.scrollLeft,\n    y: el.scrollTop\n  }\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Watch element content offset\n *\n * @param el - Element\n *\n * @returns Element content offset observable\n */\nexport function watchElementContentOffset(\n  el: HTMLElement\n): Observable<ElementOffset> {\n  return merge(\n    fromEvent(el, \"scroll\"),\n    fromEvent(window, \"scroll\"),\n    fromEvent(window, \"resize\")\n  )\n    .pipe(\n      auditTime(0, animationFrameScheduler),\n      map(() => getElementContentOffset(el)),\n      startWith(getElementContentOffset(el))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  NEVER,\n  Observable,\n  Subject,\n  defer,\n  distinctUntilChanged,\n  filter,\n  finalize,\n  map,\n  merge,\n  of,\n  shareReplay,\n  switchMap,\n  tap\n} from \"rxjs\"\n\nimport {\n  getElementContentSize,\n  getElementSize,\n  watchElementContentOffset\n} from \"~/browser\"\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Intersection observer entry subject\n */\nconst entry$ = new Subject<IntersectionObserverEntry>()\n\n/**\n * Intersection observer observable\n *\n * This observable will create an `IntersectionObserver` on first subscription\n * and will automatically terminate it when there are no more subscribers.\n *\n * @see https://bit.ly/3iIYfEm - Google Groups on performance\n */\nconst observer$ = defer(() => of(\n  new IntersectionObserver(entries => {\n    for (const entry of entries)\n      entry$.next(entry)\n  }, {\n    threshold: 0\n  })\n))\n  .pipe(\n    switchMap(observer => merge(NEVER, of(observer))\n      .pipe(\n        finalize(() => observer.disconnect())\n      )\n    ),\n    shareReplay(1)\n  )\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch element visibility\n *\n * @param el - Element\n *\n * @returns Element visibility observable\n */\nexport function watchElementVisibility(\n  el: HTMLElement\n): Observable<boolean> {\n  return observer$\n    .pipe(\n      tap(observer => observer.observe(el)),\n      switchMap(observer => entry$\n        .pipe(\n          filter(({ target }) => target === el),\n          finalize(() => observer.unobserve(el)),\n          map(({ isIntersecting }) => isIntersecting)\n        )\n      )\n    )\n}\n\n/**\n * Watch element boundary\n *\n * This function returns an observable which emits whether the bottom content\n * boundary (= scroll offset) of an element is within a certain threshold.\n *\n * @param el - Element\n * @param threshold - Threshold\n *\n * @returns Element boundary observable\n */\nexport function watchElementBoundary(\n  el: HTMLElement, threshold = 16\n): Observable<boolean> {\n  return watchElementContentOffset(el)\n    .pipe(\n      map(({ y }) => {\n        const visible = getElementSize(el)\n        const content = getElementContentSize(el)\n        return y >= (\n          content.height - visible.height - threshold\n        )\n      }),\n      distinctUntilChanged()\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  fromEvent,\n  map,\n  startWith\n} from \"rxjs\"\n\nimport { getElement } from \"../element\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Toggle\n */\nexport type Toggle =\n  | \"drawer\"                           /* Toggle for drawer */\n  | \"search\"                           /* Toggle for search */\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Toggle map\n */\nconst toggles: Record<Toggle, HTMLInputElement> = {\n  drawer: getElement(\"[data-md-toggle=drawer]\"),\n  search: getElement(\"[data-md-toggle=search]\")\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve the value of a toggle\n *\n * @param name - Toggle\n *\n * @returns Toggle value\n */\nexport function getToggle(name: Toggle): boolean {\n  return toggles[name].checked\n}\n\n/**\n * Set toggle\n *\n * Simulating a click event seems to be the most cross-browser compatible way\n * of changing the value while also emitting a `change` event. Before, Material\n * used `CustomEvent` to programmatically change the value of a toggle, but this\n * is a much simpler and cleaner solution which doesn't require a polyfill.\n *\n * @param name - Toggle\n * @param value - Toggle value\n */\nexport function setToggle(name: Toggle, value: boolean): void {\n  if (toggles[name].checked !== value)\n    toggles[name].click()\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Watch toggle\n *\n * @param name - Toggle\n *\n * @returns Toggle value observable\n */\nexport function watchToggle(name: Toggle): Observable<boolean> {\n  const el = toggles[name]\n  return fromEvent(el, \"change\")\n    .pipe(\n      map(() => el.checked),\n      startWith(el.checked)\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  filter,\n  fromEvent,\n  map,\n  merge,\n  share,\n  startWith,\n  switchMap\n} from \"rxjs\"\n\nimport { getActiveElement } from \"../element\"\nimport { getToggle } from \"../toggle\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Keyboard mode\n */\nexport type KeyboardMode =\n  | \"global\"                           /* Global */\n  | \"search\"                           /* Search is open */\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Keyboard\n */\nexport interface Keyboard {\n  mode: KeyboardMode                   /* Keyboard mode */\n  type: string                         /* Key type */\n  claim(): void                        /* Key claim */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Check whether an element may receive keyboard input\n *\n * @param el - Element\n * @param type - Key type\n *\n * @returns Test result\n */\nfunction isSusceptibleToKeyboard(\n  el: HTMLElement, type: string\n): boolean {\n  switch (el.constructor) {\n\n    /* Input elements */\n    case HTMLInputElement:\n      /* @ts-expect-error - omit unnecessary type cast */\n      if (el.type === \"radio\")\n        return /^Arrow/.test(type)\n      else\n        return true\n\n    /* Select element and textarea */\n    case HTMLSelectElement:\n    case HTMLTextAreaElement:\n      return true\n\n    /* Everything else */\n    default:\n      return el.isContentEditable\n  }\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch composition events\n *\n * @returns Composition observable\n */\nexport function watchComposition(): Observable<boolean> {\n  return merge(\n    fromEvent(window, \"compositionstart\").pipe(map(() => true)),\n    fromEvent(window, \"compositionend\").pipe(map(() => false))\n  )\n    .pipe(\n      startWith(false)\n    )\n}\n\n/**\n * Watch keyboard\n *\n * @returns Keyboard observable\n */\nexport function watchKeyboard(): Observable<Keyboard> {\n  const keyboard$ = fromEvent<KeyboardEvent>(window, \"keydown\")\n    .pipe(\n      filter(ev => !(ev.metaKey || ev.ctrlKey)),\n      map(ev => ({\n        mode: getToggle(\"search\") ? \"search\" : \"global\",\n        type: ev.key,\n        claim() {\n          ev.preventDefault()\n          ev.stopPropagation()\n        }\n      } as Keyboard)),\n      filter(({ mode, type }) => {\n        if (mode === \"global\") {\n          const active = getActiveElement()\n          if (typeof active !== \"undefined\")\n            return !isSusceptibleToKeyboard(active, type)\n        }\n        return true\n      }),\n      share()\n    )\n\n  /* Don't emit during composition events - see https://bit.ly/3te3Wl8 */\n  return watchComposition()\n    .pipe(\n      switchMap(active => !active ? keyboard$ : EMPTY)\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { Subject } from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve location\n *\n * This function returns a `URL` object (and not `Location`) to normalize the\n * typings across the application. Furthermore, locations need to be tracked\n * without setting them and `Location` is a singleton which represents the\n * current location.\n *\n * @returns URL\n */\nexport function getLocation(): URL {\n  return new URL(location.href)\n}\n\n/**\n * Set location\n *\n * If instant navigation is enabled, this function creates a temporary anchor\n * element, sets the `href` attribute, appends it to the body, clicks it, and\n * then removes it again. The event will bubble up the DOM and trigger be\n * intercepted by the instant loading business logic.\n *\n * Note that we must append and remove the anchor element, or the event will\n * not bubble up the DOM, making it impossible to intercept it.\n *\n * @param url - URL to navigate to\n * @param navigate - Force navigation\n */\nexport function setLocation(\n  url: URL | HTMLLinkElement, navigate = false\n): void {\n  if (feature(\"navigation.instant\") && !navigate) {\n    const el = h(\"a\", { href: url.href })\n    document.body.appendChild(el)\n    el.click()\n    el.remove()\n\n  // If we're not using instant navigation, and the page should not be reloaded\n  // just instruct the browser to navigate to the given URL\n  } else {\n    location.href = url.href\n  }\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Watch location\n *\n * @returns Location subject\n */\nexport function watchLocation(): Subject<URL> {\n  return new Subject<URL>()\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  filter,\n  fromEvent,\n  map,\n  merge,\n  shareReplay,\n  startWith\n} from \"rxjs\"\n\nimport { getOptionalElement } from \"~/browser\"\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve location hash\n *\n * @returns Location hash\n */\nexport function getLocationHash(): string {\n  return location.hash.slice(1)\n}\n\n/**\n * Set location hash\n *\n * Setting a new fragment identifier via `location.hash` will have no effect\n * if the value doesn't change. When a new fragment identifier is set, we want\n * the browser to target the respective element at all times, which is why we\n * use this dirty little trick.\n *\n * @param hash - Location hash\n */\nexport function setLocationHash(hash: string): void {\n  const el = h(\"a\", { href: hash })\n  el.addEventListener(\"click\", ev => ev.stopPropagation())\n  el.click()\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Watch location hash\n *\n * @param location$ - Location observable\n *\n * @returns Location hash observable\n */\nexport function watchLocationHash(\n  location$: Observable<URL>\n): Observable<string> {\n  return merge(\n    fromEvent<HashChangeEvent>(window, \"hashchange\"),\n    location$\n  )\n    .pipe(\n      map(getLocationHash),\n      startWith(getLocationHash()),\n      filter(hash => hash.length > 0),\n      shareReplay(1)\n    )\n}\n\n/**\n * Watch location target\n *\n * @param location$ - Location observable\n *\n * @returns Location target observable\n */\nexport function watchLocationTarget(\n  location$: Observable<URL>\n): Observable<HTMLElement> {\n  return watchLocationHash(location$)\n    .pipe(\n      map(id => getOptionalElement(`[id=\"${id}\"]`)!),\n      filter(el => typeof el !== \"undefined\")\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  fromEvent,\n  fromEventPattern,\n  map,\n  merge,\n  startWith,\n  switchMap\n} from \"rxjs\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch media query\n *\n * Note that although `MediaQueryList.addListener` is deprecated we have to\n * use it, because it's the only way to ensure proper downward compatibility.\n *\n * @see https://bit.ly/3dUBH2m - GitHub issue\n *\n * @param query - Media query\n *\n * @returns Media observable\n */\nexport function watchMedia(query: string): Observable<boolean> {\n  const media = matchMedia(query)\n  return fromEventPattern<boolean>(next => (\n    media.addListener(() => next(media.matches))\n  ))\n    .pipe(\n      startWith(media.matches)\n    )\n}\n\n/**\n * Watch print mode\n *\n * @returns Print observable\n */\nexport function watchPrint(): Observable<boolean> {\n  const media = matchMedia(\"print\")\n  return merge(\n    fromEvent(window, \"beforeprint\").pipe(map(() => true)),\n    fromEvent(window, \"afterprint\").pipe(map(() => false))\n  )\n    .pipe(\n      startWith(media.matches)\n    )\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Toggle an observable with a media observable\n *\n * @template T - Data type\n *\n * @param query$ - Media observable\n * @param factory - Observable factory\n *\n * @returns Toggled observable\n */\nexport function at<T>(\n  query$: Observable<boolean>, factory: () => Observable<T>\n): Observable<T> {\n  return query$\n    .pipe(\n      switchMap(active => active ? factory() : EMPTY)\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  map,\n  shareReplay,\n  switchMap\n} from \"rxjs\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Options\n */\ninterface Options {\n  progress$?: Subject<number>          // Progress subject\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Fetch the given URL\n *\n * This function returns an observable that emits the response as a blob and\n * completes, or emits an error if the request failed. The caller can cancel\n * the request by unsubscribing at any time, which will automatically abort\n * the inflight request and complete the observable.\n *\n * Note that we use `XMLHTTPRequest` not because we're nostalgic, but because\n * it's the only way to get progress events for downloads and also allow for\n * cancellation of requests, as the official Fetch API does not support this\n * yet, even though we're already in 2024.\n *\n * @param url - Request URL\n * @param options - Options\n *\n * @returns Data observable\n */\nexport function request(\n  url: URL | string, options?: Options\n): Observable<Blob> {\n  return new Observable<Blob>(observer => {\n    const req = new XMLHttpRequest()\n    req.open(\"GET\", `${url}`)\n    req.responseType = \"blob\"\n\n    // Handle response\n    req.addEventListener(\"load\", () => {\n      if (req.status >= 200 && req.status < 300) {\n        observer.next(req.response)\n        observer.complete()\n\n      // Every response that is not in the 2xx range is considered an error\n      } else {\n        observer.error(new Error(req.statusText))\n      }\n    })\n\n    // Handle network errors\n    req.addEventListener(\"error\", () => {\n      observer.error(new Error(\"Network error\"))\n    })\n\n    // Handle aborted requests\n    req.addEventListener(\"abort\", () => {\n      observer.complete()\n    })\n\n    // Handle download progress\n    if (typeof options?.progress$ !== \"undefined\") {\n      req.addEventListener(\"progress\", event => {\n        if (event.lengthComputable) {\n          options.progress$!.next((event.loaded / event.total) * 100)\n\n        // Hack: Chromium doesn't report the total number of bytes if content\n        // is compressed, so we need this fallback - see https://t.ly/ZXofI\n        } else {\n          const length = req.getResponseHeader(\"Content-Length\") ?? 0\n          options.progress$!.next((event.loaded / +length) * 100)\n        }\n      })\n\n      // Immediately set progress to 5% to indicate that we're loading\n      options.progress$.next(5)\n    }\n\n    // Send request and automatically abort request upon unsubscription\n    req.send()\n    return () => req.abort()\n  })\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Fetch JSON from the given URL\n *\n * @template T - Data type\n *\n * @param url - Request URL\n * @param options - Options\n *\n * @returns Data observable\n */\nexport function requestJSON<T>(\n  url: URL | string, options?: Options\n): Observable<T> {\n  return request(url, options)\n    .pipe(\n      switchMap(res => res.text()),\n      map(body => JSON.parse(body) as T),\n      shareReplay(1)\n    )\n}\n\n/**\n * Fetch HTML from the given URL\n *\n * @param url - Request URL\n * @param options - Options\n *\n * @returns Data observable\n */\nexport function requestHTML(\n  url: URL | string, options?: Options\n): Observable<Document> {\n  const dom = new DOMParser()\n  return request(url, options)\n    .pipe(\n      switchMap(res => res.text()),\n      map(res => dom.parseFromString(res, \"text/html\")),\n      shareReplay(1)\n    )\n}\n\n/**\n * Fetch XML from the given URL\n *\n * @param url - Request URL\n * @param options - Options\n *\n * @returns Data observable\n */\nexport function requestXML(\n  url: URL | string, options?: Options\n): Observable<Document> {\n  const dom = new DOMParser()\n  return request(url, options)\n    .pipe(\n      switchMap(res => res.text()),\n      map(res => dom.parseFromString(res, \"text/xml\")),\n      shareReplay(1)\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  fromEvent,\n  map,\n  merge,\n  startWith\n} from \"rxjs\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Viewport offset\n */\nexport interface ViewportOffset {\n  x: number                            /* Horizontal offset */\n  y: number                            /* Vertical offset */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve viewport offset\n *\n * On iOS Safari, viewport offset can be negative due to overflow scrolling.\n * As this may induce strange behaviors downstream, we'll just limit it to 0.\n *\n * @returns Viewport offset\n */\nexport function getViewportOffset(): ViewportOffset {\n  return {\n    x: Math.max(0, scrollX),\n    y: Math.max(0, scrollY)\n  }\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Watch viewport offset\n *\n * @returns Viewport offset observable\n */\nexport function watchViewportOffset(): Observable<ViewportOffset> {\n  return merge(\n    fromEvent(window, \"scroll\", { passive: true }),\n    fromEvent(window, \"resize\", { passive: true })\n  )\n    .pipe(\n      map(getViewportOffset),\n      startWith(getViewportOffset())\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  fromEvent,\n  map,\n  startWith\n} from \"rxjs\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Viewport size\n */\nexport interface ViewportSize {\n  width: number                        /* Viewport width */\n  height: number                       /* Viewport height */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve viewport size\n *\n * @returns Viewport size\n */\nexport function getViewportSize(): ViewportSize {\n  return {\n    width:  innerWidth,\n    height: innerHeight\n  }\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Watch viewport size\n *\n * @returns Viewport size observable\n */\nexport function watchViewportSize(): Observable<ViewportSize> {\n  return fromEvent(window, \"resize\", { passive: true })\n    .pipe(\n      map(getViewportSize),\n      startWith(getViewportSize())\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  combineLatest,\n  map,\n  shareReplay\n} from \"rxjs\"\n\nimport {\n  ViewportOffset,\n  watchViewportOffset\n} from \"../offset\"\nimport {\n  ViewportSize,\n  watchViewportSize\n} from \"../size\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Viewport\n */\nexport interface Viewport {\n  offset: ViewportOffset               /* Viewport offset */\n  size: ViewportSize                   /* Viewport size */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch viewport\n *\n * @returns Viewport observable\n */\nexport function watchViewport(): Observable<Viewport> {\n  return combineLatest([\n    watchViewportOffset(),\n    watchViewportSize()\n  ])\n    .pipe(\n      map(([offset, size]) => ({ offset, size })),\n      shareReplay(1)\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  combineLatest,\n  distinctUntilKeyChanged,\n  map\n} from \"rxjs\"\n\nimport { Header } from \"~/components\"\n\nimport { getElementOffset } from \"../../element\"\nimport { Viewport } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch viewport relative to element\n *\n * @param el - Element\n * @param options - Options\n *\n * @returns Viewport observable\n */\nexport function watchViewportAt(\n  el: HTMLElement, { viewport$, header$ }: WatchOptions\n): Observable<Viewport> {\n  const size$ = viewport$\n    .pipe(\n      distinctUntilKeyChanged(\"size\")\n    )\n\n  /* Compute element offset */\n  const offset$ = combineLatest([size$, header$])\n    .pipe(\n      map(() => getElementOffset(el))\n    )\n\n  /* Compute relative viewport, return hot observable */\n  return combineLatest([header$, viewport$, offset$])\n    .pipe(\n      map(([{ height }, { offset, size }, { x, y }]) => ({\n        offset: {\n          x: offset.x - x,\n          y: offset.y - y + height\n        },\n        size\n      }))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  endWith,\n  fromEvent,\n  ignoreElements,\n  mergeWith,\n  share,\n  takeUntil\n} from \"rxjs\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Worker message\n */\nexport interface WorkerMessage {\n  type: unknown                        /* Message type */\n  data?: unknown                       /* Message data */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Create an observable for receiving from a web worker\n *\n * @template T - Data type\n *\n * @param worker - Web worker\n *\n * @returns Message observable\n */\nfunction recv<T>(worker: Worker): Observable<T> {\n  return fromEvent<MessageEvent<T>, T>(worker, \"message\", ev => ev.data)\n}\n\n/**\n * Create a subject for sending to a web worker\n *\n * @template T - Data type\n *\n * @param worker - Web worker\n *\n * @returns Message subject\n */\nfunction send<T>(worker: Worker): Subject<T> {\n  const send$ = new Subject<T>()\n  send$.subscribe(data => worker.postMessage(data))\n\n  /* Return message subject */\n  return send$\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Create a bidirectional communication channel to a web worker\n *\n * @template T - Data type\n *\n * @param url - Worker URL\n * @param worker - Worker\n *\n * @returns Worker subject\n */\nexport function watchWorker<T extends WorkerMessage>(\n  url: string, worker = new Worker(url)\n): Subject<T> {\n  const recv$ = recv<T>(worker)\n  const send$ = send<T>(worker)\n\n  /* Create worker subject and forward messages */\n  const worker$ = new Subject<T>()\n  worker$.subscribe(send$)\n\n  /* Return worker subject */\n  const done$ = send$.pipe(ignoreElements(), endWith(true))\n  return worker$\n    .pipe(\n      ignoreElements(),\n      mergeWith(recv$.pipe(takeUntil(done$))),\n      share()\n    ) as Subject<T>\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { getElement, getLocation } from \"~/browser\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Feature flag\n */\nexport type Flag =\n  | \"announce.dismiss\"                 /* Dismissable announcement bar */\n  | \"content.code.annotate\"            /* Code annotations */\n  | \"content.code.copy\"                /* Code copy button */\n  | \"content.lazy\"                     /* Lazy content elements */\n  | \"content.tabs.link\"                /* Link content tabs */\n  | \"content.tooltips\"                 /* Tooltips */\n  | \"header.autohide\"                  /* Hide header */\n  | \"navigation.expand\"                /* Automatic expansion */\n  | \"navigation.indexes\"               /* Section pages */\n  | \"navigation.instant\"               /* Instant navigation */\n  | \"navigation.instant.progress\"      /* Instant navigation progress */\n  | \"navigation.sections\"              /* Section navigation */\n  | \"navigation.tabs\"                  /* Tabs navigation */\n  | \"navigation.tabs.sticky\"           /* Tabs navigation (sticky) */\n  | \"navigation.top\"                   /* Back-to-top button */\n  | \"navigation.tracking\"              /* Anchor tracking */\n  | \"search.highlight\"                 /* Search highlighting */\n  | \"search.share\"                     /* Search sharing */\n  | \"search.suggest\"                   /* Search suggestions */\n  | \"toc.follow\"                       /* Following table of contents */\n  | \"toc.integrate\"                    /* Integrated table of contents */\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Translation\n */\nexport type Translation =\n  | \"clipboard.copy\"                   /* Copy to clipboard */\n  | \"clipboard.copied\"                 /* Copied to clipboard */\n  | \"search.result.placeholder\"        /* Type to start searching */\n  | \"search.result.none\"               /* No matching documents */\n  | \"search.result.one\"                /* 1 matching document */\n  | \"search.result.other\"              /* # matching documents */\n  | \"search.result.more.one\"           /* 1 more on this page */\n  | \"search.result.more.other\"         /* # more on this page */\n  | \"search.result.term.missing\"       /* Missing */\n  | \"select.version\"                   /* Version selector */\n\n/**\n * Translations\n */\nexport type Translations =\n  Record<Translation, string>\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Versioning\n */\nexport interface Versioning {\n  provider: \"mike\"                     /* Version provider */\n  default?: string | string[]          /* Default version */\n  alias?: boolean                      /* Show alias */\n}\n\n/**\n * Configuration\n */\nexport interface Config {\n  base: string                         /* Base URL */\n  features: Flag[]                     /* Feature flags */\n  translations: Translations           /* Translations */\n  search: string                       /* Search worker URL */\n  tags?: Record<string, string>        /* Tags mapping */\n  version?: Versioning                 /* Versioning */\n}\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve global configuration and make base URL absolute\n */\nconst script = getElement(\"#__config\")\nconst config: Config = JSON.parse(script.textContent!)\nconfig.base = `${new URL(config.base, getLocation())}`\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve global configuration\n *\n * @returns Global configuration\n */\nexport function configuration(): Config {\n  return config\n}\n\n/**\n * Check whether a feature flag is enabled\n *\n * @param flag - Feature flag\n *\n * @returns Test result\n */\nexport function feature(flag: Flag): boolean {\n  return config.features.includes(flag)\n}\n\n/**\n * Retrieve the translation for the given key\n *\n * @param key - Key to be translated\n * @param value - Positional value, if any\n *\n * @returns Translation\n */\nexport function translation(\n  key: Translation, value?: string | number\n): string {\n  return typeof value !== \"undefined\"\n    ? config.translations[key].replace(\"#\", value.toString())\n    : config.translations[key]\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { getElement, getElements } from \"~/browser\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Component type\n */\nexport type ComponentType =\n  | \"announce\"                         /* Announcement bar */\n  | \"container\"                        /* Container */\n  | \"consent\"                          /* Consent */\n  | \"content\"                          /* Content */\n  | \"dialog\"                           /* Dialog */\n  | \"header\"                           /* Header */\n  | \"header-title\"                     /* Header title */\n  | \"header-topic\"                     /* Header topic */\n  | \"main\"                             /* Main area */\n  | \"outdated\"                         /* Version warning */\n  | \"palette\"                          /* Color palette */\n  | \"progress\"                         /* Progress indicator */\n  | \"search\"                           /* Search */\n  | \"search-query\"                     /* Search input */\n  | \"search-result\"                    /* Search results */\n  | \"search-share\"                     /* Search sharing */\n  | \"search-suggest\"                   /* Search suggestions */\n  | \"sidebar\"                          /* Sidebar */\n  | \"skip\"                             /* Skip link */\n  | \"source\"                           /* Repository information */\n  | \"tabs\"                             /* Navigation tabs */\n  | \"toc\"                              /* Table of contents */\n  | \"top\"                              /* Back-to-top button */\n\n/**\n * Component\n *\n * @template T - Component type\n * @template U - Reference type\n */\nexport type Component<\n  T extends {} = {},\n  U extends HTMLElement = HTMLElement\n> =\n  T & {\n    ref: U                             /* Component reference */\n  }\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Component type map\n */\ninterface ComponentTypeMap {\n  \"announce\": HTMLElement              /* Announcement bar */\n  \"container\": HTMLElement             /* Container */\n  \"consent\": HTMLElement               /* Consent */\n  \"content\": HTMLElement               /* Content */\n  \"dialog\": HTMLElement                /* Dialog */\n  \"header\": HTMLElement                /* Header */\n  \"header-title\": HTMLElement          /* Header title */\n  \"header-topic\": HTMLElement          /* Header topic */\n  \"main\": HTMLElement                  /* Main area */\n  \"outdated\": HTMLElement              /* Version warning */\n  \"palette\": HTMLElement               /* Color palette */\n  \"progress\": HTMLElement              /* Progress indicator */\n  \"search\": HTMLElement                /* Search */\n  \"search-query\": HTMLInputElement     /* Search input */\n  \"search-result\": HTMLElement         /* Search results */\n  \"search-share\": HTMLAnchorElement    /* Search sharing */\n  \"search-suggest\": HTMLElement        /* Search suggestions */\n  \"sidebar\": HTMLElement               /* Sidebar */\n  \"skip\": HTMLAnchorElement            /* Skip link */\n  \"source\": HTMLAnchorElement          /* Repository information */\n  \"tabs\": HTMLElement                  /* Navigation tabs */\n  \"toc\": HTMLElement                   /* Table of contents */\n  \"top\": HTMLAnchorElement             /* Back-to-top button */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve the element for a given component or throw a reference error\n *\n * @template T - Component type\n *\n * @param type - Component type\n * @param node - Node of reference\n *\n * @returns Element\n */\nexport function getComponentElement<T extends ComponentType>(\n  type: T, node: ParentNode = document\n): ComponentTypeMap[T] {\n  return getElement(`[data-md-component=${type}]`, node)\n}\n\n/**\n * Retrieve all elements for a given component\n *\n * @template T - Component type\n *\n * @param type - Component type\n * @param node - Node of reference\n *\n * @returns Elements\n */\nexport function getComponentElements<T extends ComponentType>(\n  type: T, node: ParentNode = document\n): ComponentTypeMap[T][] {\n  return getElements(`[data-md-component=${type}]`, node)\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  Subject,\n  defer,\n  finalize,\n  fromEvent,\n  map,\n  tap\n} from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport { getElement } from \"~/browser\"\n\nimport { Component } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Announcement bar\n */\nexport interface Announce {\n  hash: number                        /* Content hash */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch announcement bar\n *\n * @param el - Announcement bar element\n *\n * @returns Announcement bar observable\n */\nexport function watchAnnounce(\n  el: HTMLElement\n): Observable<Announce> {\n  const button = getElement(\".md-typeset > :first-child\", el)\n  return fromEvent(button, \"click\", { once: true })\n    .pipe(\n      map(() => getElement(\".md-typeset\", el)),\n      map(content => ({ hash: __md_hash(content.innerHTML) }))\n    )\n}\n\n/**\n * Mount announcement bar\n *\n * @param el - Announcement bar element\n *\n * @returns Announcement bar component observable\n */\nexport function mountAnnounce(\n  el: HTMLElement\n): Observable<Component<Announce>> {\n  if (!feature(\"announce.dismiss\") || !el.childElementCount)\n    return EMPTY\n\n  /* Support instant navigation - see https://t.ly/3FTme */\n  if (!el.hidden) {\n    const content = getElement(\".md-typeset\", el)\n    if (__md_hash(content.innerHTML) === __md_get(\"__announce\"))\n      el.hidden = true\n  }\n\n  /* Mount component on subscription */\n  return defer(() => {\n    const push$ = new Subject<Announce>()\n    push$.subscribe(({ hash }) => {\n      el.hidden = true\n\n      /* Persist preference in local storage */\n      __md_set<number>(\"__announce\", hash)\n    })\n\n    /* Create and return component */\n    return watchAnnounce(el)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  finalize,\n  map,\n  tap\n} from \"rxjs\"\n\nimport { Component } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Consent\n */\nexport interface Consent {\n  hidden: boolean                      /* Consent is hidden */\n}\n\n/**\n * Consent defaults\n */\nexport interface ConsentDefaults {\n  analytics?: boolean                  /* Consent for Analytics */\n  github?: boolean                     /* Consent for GitHub */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  target$: Observable<HTMLElement>     /* Target observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  target$: Observable<HTMLElement>     /* Target observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch consent\n *\n * @param el - Consent element\n * @param options - Options\n *\n * @returns Consent observable\n */\nexport function watchConsent(\n  el: HTMLElement, { target$ }: WatchOptions\n): Observable<Consent> {\n  return target$\n    .pipe(\n      map(target => ({ hidden: target !== el }))\n    )\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Mount consent\n *\n * @param el - Consent element\n * @param options - Options\n *\n * @returns Consent component observable\n */\nexport function mountConsent(\n  el: HTMLElement, options: MountOptions\n): Observable<Component<Consent>> {\n  const internal$ = new Subject<Consent>()\n  internal$.subscribe(({ hidden }) => {\n    el.hidden = hidden\n  })\n\n  /* Create and return component */\n  return watchConsent(el, options)\n    .pipe(\n      tap(state => internal$.next(state)),\n      finalize(() => internal$.complete()),\n      map(state => ({ ref: el, ...state }))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { ComponentChild } from \"preact\"\n\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Tooltip style\n */\nexport type TooltipStyle =\n  | \"inline\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render a tooltip\n *\n * @param id - Tooltip identifier\n * @param style - Tooltip style\n *\n * @returns Element\n */\nexport function renderTooltip(\n  id?: string, style?: TooltipStyle\n): HTMLElement {\n  if (style === \"inline\") { // @todo refactor control flow\n    return (\n      <div class=\"md-tooltip md-tooltip--inline\" id={id} role=\"tooltip\">\n        <div class=\"md-tooltip__inner md-typeset\"></div>\n      </div>\n    )\n  } else {\n    return (\n      <div class=\"md-tooltip\" id={id} role=\"tooltip\">\n        <div class=\"md-tooltip__inner md-typeset\"></div>\n      </div>\n    )\n  }\n}\n\n// @todo: rename\nexport function renderInlineTooltip2(\n  ...children: ComponentChild[]\n): HTMLElement {\n  return (\n    <div class=\"md-tooltip2\" role=\"tooltip\">\n      <div class=\"md-tooltip2__inner md-typeset\">\n        {children}\n      </div>\n    </div>\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { h } from \"~/utilities\"\n\nimport { renderTooltip } from \"../tooltip\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render an annotation\n *\n * @param id - Annotation identifier\n * @param prefix - Tooltip identifier prefix\n *\n * @returns Element\n */\nexport function renderAnnotation(\n  id: string | number, prefix?: string\n): HTMLElement {\n  prefix = prefix ? `${prefix}_annotation_${id}` : undefined\n\n  /* Render tooltip with anchor, if given */\n  if (prefix) {\n    const anchor = prefix ? `#${prefix}` : undefined\n    return (\n      <aside class=\"md-annotation\" tabIndex={0}>\n        {renderTooltip(prefix)}\n        <a href={anchor} class=\"md-annotation__index\" tabIndex={-1}>\n          <span data-md-annotation-id={id}></span>\n        </a>\n      </aside>\n    )\n  } else {\n    return (\n      <aside class=\"md-annotation\" tabIndex={0}>\n        {renderTooltip(prefix)}\n        <span class=\"md-annotation__index\" tabIndex={-1}>\n          <span data-md-annotation-id={id}></span>\n        </span>\n      </aside>\n    )\n  }\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { translation } from \"~/_\"\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render a 'copy-to-clipboard' button\n *\n * @param id - Unique identifier\n *\n * @returns Element\n */\nexport function renderClipboardButton(id: string): HTMLElement {\n  return (\n    <button\n      class=\"md-clipboard md-icon\"\n      title={translation(\"clipboard.copy\")}\n      data-clipboard-target={`#${id} > code`}\n    ></button>\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport escapeHTML from \"escape-html\"\nimport { ComponentChild } from \"preact\"\n\nimport { configuration, feature, translation } from \"~/_\"\nimport { SearchItem } from \"~/integrations/search\"\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Render flag\n */\nconst enum Flag {\n  TEASER = 1,                          /* Render teaser */\n  PARENT = 2                           /* Render as parent */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper function\n * ------------------------------------------------------------------------- */\n\n/**\n * Render a search document\n *\n * @param document - Search document\n * @param flag - Render flags\n *\n * @returns Element\n */\nfunction renderSearchDocument(\n  document: SearchItem, flag: Flag\n): HTMLElement {\n  const parent = flag & Flag.PARENT\n  const teaser = flag & Flag.TEASER\n\n  /* Render missing query terms */\n  const missing = Object.keys(document.terms)\n    .filter(key => !document.terms[key])\n    .reduce<ComponentChild[]>((list, key) => [\n      ...list, <del>{escapeHTML(key)}</del>, \" \"\n    ], [])\n    .slice(0, -1)\n\n  /* Assemble query string for highlighting */\n  const config = configuration()\n  const url = new URL(document.location, config.base)\n  if (feature(\"search.highlight\"))\n    url.searchParams.set(\"h\", Object.entries(document.terms)\n      .filter(([, match]) => match)\n      .reduce((highlight, [value]) => `${highlight} ${value}`.trim(), \"\")\n    )\n\n  /* Render article or section, depending on flags */\n  const { tags } = configuration()\n  return (\n    <a href={`${url}`} class=\"md-search-result__link\" tabIndex={-1}>\n      <article\n        class=\"md-search-result__article md-typeset\"\n        data-md-score={document.score.toFixed(2)}\n      >\n        {parent > 0 && <div class=\"md-search-result__icon md-icon\"></div>}\n        {parent > 0 && <h1>{document.title}</h1>}\n        {parent <= 0 && <h2>{document.title}</h2>}\n        {teaser > 0 && document.text.length > 0 &&\n          document.text\n        }\n        {document.tags && (\n          <nav class=\"md-tags\">\n            {document.tags.map(tag => {\n              const type = tags\n                ? tag in tags\n                  ? `md-tag-icon md-tag--${tags[tag]}`\n                  : \"md-tag-icon\"\n                : \"\"\n              return (\n                <span class={`md-tag ${type}`}>{tag}</span>\n              )\n            })}\n          </nav>\n        )}\n        {teaser > 0 && missing.length > 0 &&\n          <p class=\"md-search-result__terms\">\n            {translation(\"search.result.term.missing\")}: {...missing}\n          </p>\n        }\n      </article>\n    </a>\n  )\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render a search result\n *\n * @param result - Search result\n *\n * @returns Element\n */\nexport function renderSearchResultItem(\n  result: SearchItem[]\n): HTMLElement {\n  const threshold = result[0].score\n  const docs = [...result]\n\n  const config = configuration()\n\n  /* Find and extract parent article */\n  const parent = docs.findIndex(doc => {\n    const l = `${new URL(doc.location, config.base)}` // @todo hacky\n    return !l.includes(\"#\")\n  })\n  const [article] = docs.splice(parent, 1)\n\n  /* Determine last index above threshold */\n  let index = docs.findIndex(doc => doc.score < threshold)\n  if (index === -1)\n    index = docs.length\n\n  /* Partition sections */\n  const best = docs.slice(0, index)\n  const more = docs.slice(index)\n\n  /* Render children */\n  const children = [\n    renderSearchDocument(article, Flag.PARENT | +(!parent && index === 0)),\n    ...best.map(section => renderSearchDocument(section, Flag.TEASER)),\n    ...more.length ? [\n      <details class=\"md-search-result__more\">\n        <summary tabIndex={-1}>\n          <div>\n            {more.length > 0 && more.length === 1\n              ? translation(\"search.result.more.one\")\n              : translation(\"search.result.more.other\", more.length)\n            }\n          </div>\n        </summary>\n        {...more.map(section => renderSearchDocument(section, Flag.TEASER))}\n      </details>\n    ] : []\n  ]\n\n  /* Render search result */\n  return (\n    <li class=\"md-search-result__item\">\n      {children}\n    </li>\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { SourceFacts } from \"~/components\"\nimport { h, round } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render repository facts\n *\n * @param facts - Repository facts\n *\n * @returns Element\n */\nexport function renderSourceFacts(facts: SourceFacts): HTMLElement {\n  return (\n    <ul class=\"md-source__facts\">\n      {Object.entries(facts).map(([key, value]) => (\n        <li class={`md-source__fact md-source__fact--${key}`}>\n          {typeof value === \"number\" ? round(value) : value}\n        </li>\n      ))}\n    </ul>\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Tabbed control type\n */\ntype TabbedControlType =\n  | \"prev\"\n  | \"next\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render control for content tabs\n *\n * @param type - Control type\n *\n * @returns Element\n */\nexport function renderTabbedControl(\n  type: TabbedControlType\n): HTMLElement {\n  const classes = `tabbed-control tabbed-control--${type}`\n  return (\n    <div class={classes} hidden>\n      <button class=\"tabbed-button\" tabIndex={-1} aria-hidden=\"true\"></button>\n    </div>\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render a table inside a wrapper to improve scrolling on mobile\n *\n * @param table - Table element\n *\n * @returns Element\n */\nexport function renderTable(table: HTMLElement): HTMLElement {\n  return (\n    <div class=\"md-typeset__scrollwrap\">\n      <div class=\"md-typeset__table\">\n        {table}\n      </div>\n    </div>\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { configuration, translation } from \"~/_\"\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Version properties\n */\nexport interface VersionProperties {\n  hidden?: boolean                     /* Version is hidden */\n}\n\n/**\n * Version\n */\nexport interface Version {\n  version: string                      /* Version identifier */\n  title: string                        /* Version title */\n  aliases: string[]                    /* Version aliases */\n  properties?: VersionProperties       /* Version properties */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render a version\n *\n * @param version - Version\n *\n * @returns Element\n */\nfunction renderVersion(version: Version): HTMLElement {\n  const config = configuration()\n\n  /* Ensure trailing slash - see https://bit.ly/3rL5u3f */\n  const url = new URL(`../${version.version}/`, config.base)\n  return (\n    <li class=\"md-version__item\">\n      <a href={`${url}`} class=\"md-version__link\">\n        {version.title}\n        {config.version?.alias && version.aliases.length > 0 && (\n          <span class=\"md-version__alias\">\n            {version.aliases[0]}\n          </span>\n        )}\n      </a>\n    </li>\n  )\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render a version selector\n *\n * @param versions - Versions\n * @param active - Active version\n *\n * @returns Element\n */\nexport function renderVersionSelector(\n  versions: Version[], active: Version\n): HTMLElement {\n  const config = configuration()\n  versions = versions.filter(version => !version.properties?.hidden)\n  return (\n    <div class=\"md-version\">\n      <button\n        class=\"md-version__current\"\n        aria-label={translation(\"select.version\")}\n      >\n        {active.title}\n        {config.version?.alias && active.aliases.length > 0 && (\n          <span class=\"md-version__alias\">\n            {active.aliases[0]}\n          </span>\n        )}\n      </button>\n      <ul class=\"md-version__list\">\n        {versions.map(renderVersion)}\n      </ul>\n    </div>\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  BehaviorSubject,\n  EMPTY,\n  Observable,\n  Subject,\n  animationFrameScheduler,\n  combineLatest,\n  combineLatestWith,\n  debounce,\n  defer,\n  distinctUntilChanged,\n  endWith,\n  filter,\n  finalize,\n  first,\n  ignoreElements,\n  map,\n  mergeMap,\n  observeOn,\n  queueScheduler,\n  share,\n  startWith,\n  switchMap,\n  tap,\n  throttleTime,\n  timer,\n  withLatestFrom\n} from \"rxjs\"\n\nimport {\n  ElementOffset,\n  Viewport,\n  getElement,\n  getElementContainers,\n  getElementOffsetAbsolute,\n  getElementSize,\n  watchElementContentOffset,\n  watchElementFocus,\n  watchElementHover\n} from \"~/browser\"\nimport { renderInlineTooltip2 } from \"~/templates\"\n\nimport { Component } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Tooltip\n */\nexport interface Tooltip {\n  active: boolean                      // Tooltip is active\n  offset: ElementOffset                // Tooltip offset\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Dependencies\n */\ninterface Dependencies {\n  content$: Observable<HTMLElement>    // Tooltip content observable\n  viewport$: Observable<Viewport>      // Viewport observable\n}\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Global sequence number for tooltips\n */\nlet sequence = 0\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch tooltip\n *\n * This function tracks the tooltip host element, and deduces the active state\n * and offset of the tooltip from it. The active state is determined by whether\n * the host element is focused or hovered, and the offset is determined by the\n * host element's absolute position in the document.\n *\n * @param el - Tooltip host element\n *\n * @returns Tooltip observable\n */\nexport function watchTooltip2(\n  el: HTMLElement\n): Observable<Tooltip> {\n\n  // Compute whether tooltip should be shown - we need to watch both focus and\n  // hover events on the host element and emit if one of them is active. In case\n  // of a hover event, we keep the element visible for a short amount of time\n  // after the pointer left the host element for a better user experience.\n  const active$ =\n    combineLatest([\n      watchElementFocus(el),\n      watchElementHover(el)\n    ])\n      .pipe(\n        map(([focus, hover]) => focus || hover),\n        distinctUntilChanged()\n      )\n\n  // We need to determine all parent elements of the host element that are\n  // currently scrollable, as they might affect the position of the tooltip\n  // depending on their horizontal of vertical offset. We must track all of\n  // them and recompute the position of the tooltip if they change.\n  const offset$ =\n    defer(() => getElementContainers(el)).pipe(\n      mergeMap(watchElementContentOffset),\n      throttleTime(1),\n      // Note that we need to poll the value again if the active state changes,\n      // as otherwise the tooltip might be misplaced. This particularly happens\n      // when using third-party integrations like tablesort that change the\n      // position of elements \u2013 see https://t.ly/Y-V7X\n      combineLatestWith(active$),\n      map(() => getElementOffsetAbsolute(el)),\n    )\n\n  // Only track parent elements and compute offset of the tooltip host if the\n  // tooltip should be shown - we defer the computation of the offset until the\n  // tooltip becomes active for the first time. This is necessary, because we\n  // must also keep the tooltip active as long as it is focused or hovered.\n  return active$.pipe(\n    first(active => active),\n    switchMap(() => combineLatest([active$, offset$])),\n    map(([active, offset]) => ({ active, offset })),\n    share()\n  )\n}\n\n/**\n * Mount tooltip\n *\n * This function renders a tooltip with the content from the provided `content$`\n * observable as passed via the dependencies. If the returned element has a role\n * of type `dialog`, the tooltip is considered to be interactive, and rendered\n * either above or below the host element, depending on the available space.\n *\n * If the returned element has a role of type `tooltip`, the tooltip is always\n * rendered below the host element and considered to be non-interactive. This\n * allows us to reuse the same positioning logic for both interactive and\n * non-interactive tooltips, as it is largely the same.\n *\n * @param el - Tooltip host element\n * @param dependencies - Dependencies\n *\n * @returns Tooltip component observable\n */\nexport function mountTooltip2(\n  el: HTMLElement, dependencies: Dependencies\n): Observable<Component<Tooltip>> {\n  const { content$, viewport$ } = dependencies\n\n  // Compute unique tooltip id - this is necessary to associate the tooltip host\n  // element with the tooltip element for ARIA purposes\n  const id = `__tooltip2_${sequence++}`\n\n  // Create component on subscription\n  return defer(() => {\n    const push$ = new Subject<Tooltip>()\n\n    // Create subject to track tooltip presence and visibility - we use another\n    // purely internal subject to track the tooltip's presence and visibility,\n    // as the tooltip should be visible if the host element or tooltip itself\n    // is focused or hovered to allow for smooth pointer migration\n    const show$ = new BehaviorSubject(false)\n    push$.pipe(ignoreElements(), endWith(false))\n      .subscribe(show$)\n\n    // Create observable controlling tooltip element - we create and attach the\n    // tooltip only if it is actually present, in order to keep the number of\n    // elements low. We need to keep the tooltip visible for a short time after\n    // the pointer left the host element or tooltip itself. For this, we use an\n    // inner subscription to the tooltip observable, which we terminate when the\n    // tooltip should not be shown, automatically removing the element. Moreover\n    // we use the queue scheduler, which will schedule synchronously in case the\n    // tooltip should be shown, and asynchronously if it should be hidden.\n    const node$ = show$.pipe(\n      debounce(active => timer(+!active * 250, queueScheduler)),\n      distinctUntilChanged(),\n      switchMap(active => active ? content$ : EMPTY),\n      tap(node => node.id = id),\n      share()\n    )\n\n    // Compute tooltip presence and visibility - the tooltip should be shown if\n    // the host element or the tooltip itself is focused or hovered\n    combineLatest([\n      push$.pipe(map(({ active }) => active)),\n      node$.pipe(\n        switchMap(node => watchElementHover(node, 250)),\n        startWith(false)\n      )\n    ])\n      .pipe(map(states => states.some(active => active)))\n      .subscribe(show$)\n\n    // Compute tooltip origin - we need to compute the tooltip origin depending\n    // on the position of the host element, the viewport size, as well as the\n    // actual size of the tooltip, if positioned above. The tooltip must about\n    // to be rendered for this to be correct, which is why we do it here.\n    const origin$ = show$.pipe(\n      filter(active => active),\n      withLatestFrom(node$, viewport$),\n      map(([_, node, { size }]) => {\n        const host = el.getBoundingClientRect()\n        const x = host.width / 2\n\n        // If the tooltip is non-interactive, we always render it below the\n        // actual element because all operating systems do it that way\n        if (node.role === \"tooltip\") {\n          return { x, y: 8 + host.height }\n\n        // Otherwise, we determine where there is more space, and render the\n        // tooltip either above or below the host element\n        } else if (host.y >= size.height / 2) {\n          const { height } = getElementSize(node)\n          return { x, y: -16 - height }\n        } else {\n          return { x, y: +16 + host.height }\n        }\n      })\n    )\n\n    // Update tooltip position - we always need to update the position of the\n    // tooltip, as it might change depending on the viewport offset of the host\n    combineLatest([node$, push$, origin$])\n      .subscribe(([node, { offset }, origin]) => {\n        node.style.setProperty(\"--md-tooltip-host-x\", `${offset.x}px`)\n        node.style.setProperty(\"--md-tooltip-host-y\", `${offset.y}px`)\n\n        // Update tooltip origin - this is mainly set to determine the position\n        // of the tooltip tail, to show the direction it is originating from\n        node.style.setProperty(\"--md-tooltip-x\", `${origin.x}px`)\n        node.style.setProperty(\"--md-tooltip-y\", `${origin.y}px`)\n\n        // Update tooltip render location, i.e., whether the tooltip is shown\n        // above or below the host element, depending on the available space\n        node.classList.toggle(\"md-tooltip2--top\",    origin.y <  0)\n        node.classList.toggle(\"md-tooltip2--bottom\", origin.y >= 0)\n      })\n\n    // Update tooltip width - we only explicitly set the width of the tooltip\n    // if it is non-interactive, in case it should always be rendered centered\n    show$.pipe(\n      filter(active => active),\n      withLatestFrom(node$, (_, node) => node),\n      filter(node => node.role === \"tooltip\")\n    )\n      .subscribe(node => {\n        const size = getElementSize(getElement(\":scope > *\", node))\n\n        // Set tooltip width and remove tail by setting it to a width of zero -\n        // if authors want to keep the tail, we can move this to CSS later\n        node.style.setProperty(\"--md-tooltip-width\", `${size.width}px`)\n        node.style.setProperty(\"--md-tooltip-tail\",  `${0}px`)\n      })\n\n    // Update tooltip visibility - we defer to the next animation frame, because\n    // the tooltip must first be added to the document before we make it appear,\n    // or it will appear instantly without delay. Additionally, we need to keep\n    // the tooltip visible for a short time after the pointer left the host.\n    show$.pipe(\n      distinctUntilChanged(),\n      observeOn(animationFrameScheduler),\n      withLatestFrom(node$)\n    )\n      .subscribe(([active, node]) => {\n        node.classList.toggle(\"md-tooltip2--active\", active)\n      })\n\n    // Set up ARIA attributes when tooltip is visible\n    combineLatest([\n      show$.pipe(filter(active => active)),\n      node$\n    ])\n      .subscribe(([_, node]) => {\n        if (node.role === \"dialog\") {\n          el.setAttribute(\"aria-controls\", id)\n          el.setAttribute(\"aria-haspopup\", \"dialog\")\n        } else {\n          el.setAttribute(\"aria-describedby\", id)\n        }\n      })\n\n    // Remove ARIA attributes when tooltip is hidden\n    show$.pipe(filter(active => !active))\n      .subscribe(() => {\n        el.removeAttribute(\"aria-controls\")\n        el.removeAttribute(\"aria-describedby\")\n        el.removeAttribute(\"aria-haspopup\")\n      })\n\n    // Create and return component\n    return watchTooltip2(el)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n\n// ----------------------------------------------------------------------------\n\n/**\n * Mount inline tooltip\n *\n * @todo refactor this function\n *\n * @param el - Tooltip host element\n * @param dependencies - Dependencies\n * @param container - Container\n *\n * @returns Tooltip component observable\n */\nexport function mountInlineTooltip2(\n  el: HTMLElement, { viewport$ }: { viewport$: Observable<Viewport> },\n  container = document.body\n): Observable<Component<Tooltip>> {\n  return mountTooltip2(el, {\n    content$: new Observable<HTMLElement>(observer => {\n      const title = el.title\n      const node = renderInlineTooltip2(title)\n      observer.next(node)\n      el.removeAttribute(\"title\")\n      // Append tooltip and remove on unsubscription\n      container.append(node)\n      return () => {\n        node.remove()\n        el.setAttribute(\"title\", title)\n      }\n    }),\n    viewport$\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  animationFrameScheduler,\n  auditTime,\n  combineLatest,\n  debounceTime,\n  defer,\n  delay,\n  endWith,\n  filter,\n  finalize,\n  fromEvent,\n  ignoreElements,\n  map,\n  merge,\n  switchMap,\n  take,\n  takeUntil,\n  tap,\n  throttleTime,\n  withLatestFrom\n} from \"rxjs\"\n\nimport {\n  ElementOffset,\n  getActiveElement,\n  getElementSize,\n  watchElementContentOffset,\n  watchElementFocus,\n  watchElementOffset,\n  watchElementVisibility\n} from \"~/browser\"\n\nimport { Component } from \"../../../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Annotation\n */\nexport interface Annotation {\n  active: boolean                      /* Annotation is active */\n  offset: ElementOffset                /* Annotation offset */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  target$: Observable<HTMLElement>     /* Location target observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch annotation\n *\n * @param el - Annotation element\n * @param container - Containing element\n *\n * @returns Annotation observable\n */\nexport function watchAnnotation(\n  el: HTMLElement, container: HTMLElement\n): Observable<Annotation> {\n  const offset$ = defer(() => combineLatest([\n    watchElementOffset(el),\n    watchElementContentOffset(container)\n  ]))\n    .pipe(\n      map(([{ x, y }, scroll]): ElementOffset => {\n        const { width, height } = getElementSize(el)\n        return ({\n          x: x - scroll.x + width  / 2,\n          y: y - scroll.y + height / 2\n        })\n      })\n    )\n\n  /* Actively watch annotation on focus */\n  return watchElementFocus(el)\n    .pipe(\n      switchMap(active => offset$\n        .pipe(\n          map(offset => ({ active, offset })),\n          take(+!active || Infinity)\n        )\n      )\n    )\n}\n\n/**\n * Mount annotation\n *\n * @param el - Annotation element\n * @param container - Containing element\n * @param options - Options\n *\n * @returns Annotation component observable\n */\nexport function mountAnnotation(\n  el: HTMLElement, container: HTMLElement, { target$ }: MountOptions\n): Observable<Component<Annotation>> {\n  const [tooltip, index] = Array.from(el.children)\n\n  /* Mount component on subscription */\n  return defer(() => {\n    const push$ = new Subject<Annotation>()\n    const done$ = push$.pipe(ignoreElements(), endWith(true))\n    push$.subscribe({\n\n      /* Handle emission */\n      next({ offset }) {\n        el.style.setProperty(\"--md-tooltip-x\", `${offset.x}px`)\n        el.style.setProperty(\"--md-tooltip-y\", `${offset.y}px`)\n      },\n\n      /* Handle complete */\n      complete() {\n        el.style.removeProperty(\"--md-tooltip-x\")\n        el.style.removeProperty(\"--md-tooltip-y\")\n      }\n    })\n\n    /* Start animation only when annotation is visible */\n    watchElementVisibility(el)\n      .pipe(\n        takeUntil(done$)\n      )\n        .subscribe(visible => {\n          el.toggleAttribute(\"data-md-visible\", visible)\n        })\n\n    /* Toggle tooltip presence to mitigate empty lines when copying */\n    merge(\n      push$.pipe(filter(({ active }) => active)),\n      push$.pipe(debounceTime(250), filter(({ active }) => !active))\n    )\n      .subscribe({\n\n        /* Handle emission */\n        next({ active }) {\n          if (active)\n            el.prepend(tooltip)\n          else\n            tooltip.remove()\n        },\n\n        /* Handle complete */\n        complete() {\n          el.prepend(tooltip)\n        }\n      })\n\n    /* Toggle tooltip visibility */\n    push$\n      .pipe(\n        auditTime(16, animationFrameScheduler)\n      )\n        .subscribe(({ active }) => {\n          tooltip.classList.toggle(\"md-tooltip--active\", active)\n        })\n\n    /* Track relative origin of tooltip */\n    push$\n      .pipe(\n        throttleTime(125, animationFrameScheduler),\n        filter(() => !!el.offsetParent),\n        map(() => el.offsetParent!.getBoundingClientRect()),\n        map(({ x }) => x)\n      )\n        .subscribe({\n\n          /* Handle emission */\n          next(origin) {\n            if (origin)\n              el.style.setProperty(\"--md-tooltip-0\", `${-origin}px`)\n            else\n              el.style.removeProperty(\"--md-tooltip-0\")\n          },\n\n          /* Handle complete */\n          complete() {\n            el.style.removeProperty(\"--md-tooltip-0\")\n          }\n        })\n\n    /* Allow to copy link without scrolling to anchor */\n    fromEvent<MouseEvent>(index, \"click\")\n      .pipe(\n        takeUntil(done$),\n        filter(ev => !(ev.metaKey || ev.ctrlKey))\n      )\n        .subscribe(ev => {\n          ev.stopPropagation()\n          ev.preventDefault()\n        })\n\n    /* Allow to open link in new tab or blur on close */\n    fromEvent<MouseEvent>(index, \"mousedown\")\n      .pipe(\n        takeUntil(done$),\n        withLatestFrom(push$)\n      )\n        .subscribe(([ev, { active }]) => {\n\n          /* Open in new tab */\n          if (ev.button !== 0 || ev.metaKey || ev.ctrlKey) {\n            ev.preventDefault()\n\n          /* Close annotation */\n          } else if (active) {\n            ev.preventDefault()\n\n            /* Focus parent annotation, if any */\n            const parent = el.parentElement!.closest(\".md-annotation\")\n            if (parent instanceof HTMLElement)\n              parent.focus()\n            else\n              getActiveElement()?.blur()\n          }\n        })\n\n    /* Open and focus annotation on location target */\n    target$\n      .pipe(\n        takeUntil(done$),\n        filter(target => target === tooltip),\n        delay(125)\n      )\n        .subscribe(() => el.focus())\n\n    /* Create and return component */\n    return watchAnnotation(el, container)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  Subject,\n  defer,\n  endWith,\n  finalize,\n  ignoreElements,\n  merge,\n  share,\n  takeUntil\n} from \"rxjs\"\n\nimport {\n  getElement,\n  getElements,\n  getOptionalElement\n} from \"~/browser\"\nimport { renderAnnotation } from \"~/templates\"\n\nimport { Component } from \"../../../_\"\nimport {\n  Annotation,\n  mountAnnotation\n} from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  target$: Observable<HTMLElement>     /* Location target observable */\n  print$: Observable<boolean>          /* Media print observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Find all annotation hosts in the containing element\n *\n * @param container - Containing element\n *\n * @returns Annotation hosts\n */\nfunction findHosts(container: HTMLElement): HTMLElement[] {\n  return container.tagName === \"CODE\"\n    ? getElements(\".c, .c1, .cm\", container)\n    : [container]\n}\n\n/**\n * Find all annotation markers in the containing element\n *\n * @param container - Containing element\n *\n * @returns Annotation markers\n */\nfunction findMarkers(container: HTMLElement): Text[] {\n  const markers: Text[] = []\n  for (const el of findHosts(container)) {\n    const nodes: Text[] = []\n\n    /* Find all text nodes in current element */\n    const it = document.createNodeIterator(el, NodeFilter.SHOW_TEXT)\n    for (let node = it.nextNode(); node; node = it.nextNode())\n      nodes.push(node as Text)\n\n    /* Find all markers in each text node */\n    for (let text of nodes) {\n      let match: RegExpExecArray | null\n\n      /* Split text at marker and add to list */\n      while ((match = /(\\(\\d+\\))(!)?/.exec(text.textContent!))) {\n        const [, id, force] = match\n        if (typeof force === \"undefined\") {\n          const marker = text.splitText(match.index)\n          text = marker.splitText(id.length)\n          markers.push(marker)\n\n        /* Replace entire text with marker */\n        } else {\n          text.textContent = id\n          markers.push(text)\n          break\n        }\n      }\n    }\n  }\n  return markers\n}\n\n/**\n * Swap the child nodes of two elements\n *\n * @param source - Source element\n * @param target - Target element\n */\nfunction swap(source: HTMLElement, target: HTMLElement): void {\n  target.append(...Array.from(source.childNodes))\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount annotation list\n *\n * This function analyzes the containing code block and checks for markers\n * referring to elements in the given annotation list. If no markers are found,\n * the list is left untouched. Otherwise, list elements are rendered as\n * annotations inside the code block.\n *\n * @param el - Annotation list element\n * @param container - Containing element\n * @param options - Options\n *\n * @returns Annotation component observable\n */\nexport function mountAnnotationList(\n  el: HTMLElement, container: HTMLElement, { target$, print$ }: MountOptions\n): Observable<Component<Annotation>> {\n\n  /* Compute prefix for tooltip anchors */\n  const parent = container.closest(\"[id]\")\n  const prefix = parent?.id\n\n  /* Find and replace all markers with empty annotations */\n  const annotations = new Map<string, HTMLElement>()\n  for (const marker of findMarkers(container)) {\n    const [, id] = marker.textContent!.match(/\\((\\d+)\\)/)!\n    if (getOptionalElement(`:scope > li:nth-child(${id})`, el)) {\n      annotations.set(id, renderAnnotation(id, prefix))\n      marker.replaceWith(annotations.get(id)!)\n    }\n  }\n\n  /* Keep list if there are no annotations to render */\n  if (annotations.size === 0)\n    return EMPTY\n\n  /* Mount component on subscription */\n  return defer(() => {\n    const push$ = new Subject()\n    const done$ = push$.pipe(ignoreElements(), endWith(true))\n\n    /* Retrieve container pairs for swapping */\n    const pairs: [HTMLElement, HTMLElement][] = []\n    for (const [id, annotation] of annotations)\n      pairs.push([\n        getElement(\".md-typeset\", annotation),\n        getElement(`:scope > li:nth-child(${id})`, el)\n      ])\n\n    /* Handle print mode - see https://bit.ly/3rgPdpt */\n    print$.pipe(takeUntil(done$))\n      .subscribe(active => {\n        el.hidden = !active\n\n        /* Add class to discern list element */\n        el.classList.toggle(\"md-annotation-list\", active)\n\n        /* Show annotations in code block or list (print) */\n        for (const [inner, child] of pairs)\n          if (!active)\n            swap(child, inner)\n          else\n            swap(inner, child)\n      })\n\n    /* Create and return component */\n    return merge(...[...annotations]\n      .map(([, annotation]) => (\n        mountAnnotation(annotation, container, { target$ })\n      ))\n    )\n      .pipe(\n        finalize(() => push$.complete()),\n        share()\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { EMPTY, Observable, defer } from \"rxjs\"\n\nimport { Component } from \"../../../_\"\nimport { Annotation } from \"../_\"\nimport { mountAnnotationList } from \"../list\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  target$: Observable<HTMLElement>     /* Location target observable */\n  print$: Observable<boolean>          /* Media print observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Find list element directly following a block\n *\n * @param el - Annotation block element\n *\n * @returns List element or nothing\n */\nfunction findList(el: HTMLElement): HTMLElement | undefined {\n  if (el.nextElementSibling) {\n    const sibling = el.nextElementSibling as HTMLElement\n    if (sibling.tagName === \"OL\")\n      return sibling\n\n    /* Skip empty paragraphs - see https://bit.ly/3r4ZJ2O */\n    else if (sibling.tagName === \"P\" && !sibling.children.length)\n      return findList(sibling)\n  }\n\n  /* Everything else */\n  return undefined\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount annotation block\n *\n * @param el - Annotation block element\n * @param options - Options\n *\n * @returns Annotation component observable\n */\nexport function mountAnnotationBlock(\n  el: HTMLElement, options: MountOptions\n): Observable<Component<Annotation>> {\n  return defer(() => {\n    const list = findList(el)\n    return typeof list !== \"undefined\"\n      ? mountAnnotationList(list, el, options)\n      : EMPTY\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport ClipboardJS from \"clipboard\"\nimport {\n  EMPTY,\n  Observable,\n  Subject,\n  defer,\n  distinctUntilChanged,\n  distinctUntilKeyChanged,\n  filter,\n  finalize,\n  map,\n  mergeWith,\n  switchMap,\n  take,\n  takeLast,\n  takeUntil,\n  tap\n} from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport {\n  getElementContentSize,\n  getElements,\n  watchElementSize,\n  watchElementVisibility\n} from \"~/browser\"\nimport {\n  Tooltip,\n  mountInlineTooltip2\n} from \"~/components/tooltip2\"\nimport { renderClipboardButton } from \"~/templates\"\n\nimport { Component } from \"../../../_\"\nimport {\n  Annotation,\n  mountAnnotationList\n} from \"../../annotation\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Code block overflow\n */\nexport interface Overflow {\n  scrollable: boolean                  /* Code block overflows */\n}\n\n/**\n * Code block\n */\nexport type CodeBlock =\n  | Overflow\n  | Annotation\n  | Tooltip\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  target$: Observable<HTMLElement>     /* Location target observable */\n  print$: Observable<boolean>          /* Media print observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Global sequence number for code blocks\n */\nlet sequence = 0\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Find candidate list element directly following a code block\n *\n * @param el - Code block element\n *\n * @returns List element or nothing\n */\nfunction findCandidateList(el: HTMLElement): HTMLElement | undefined {\n  if (el.nextElementSibling) {\n    const sibling = el.nextElementSibling as HTMLElement\n    if (sibling.tagName === \"OL\")\n      return sibling\n\n    /* Skip empty paragraphs - see https://bit.ly/3r4ZJ2O */\n    else if (sibling.tagName === \"P\" && !sibling.children.length)\n      return findCandidateList(sibling)\n  }\n\n  /* Everything else */\n  return undefined\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch code block\n *\n * This function monitors size changes of the viewport, as well as switches of\n * content tabs with embedded code blocks, as both may trigger overflow.\n *\n * @param el - Code block element\n *\n * @returns Code block observable\n */\nexport function watchCodeBlock(\n  el: HTMLElement\n): Observable<Overflow> {\n  return watchElementSize(el)\n    .pipe(\n      map(({ width }) => {\n        const content = getElementContentSize(el)\n        return {\n          scrollable: content.width > width\n        }\n      }),\n      distinctUntilKeyChanged(\"scrollable\")\n    )\n}\n\n/**\n * Mount code block\n *\n * This function ensures that an overflowing code block is focusable through\n * keyboard, so it can be scrolled without a mouse to improve on accessibility.\n * Furthermore, if code annotations are enabled, they are mounted if and only\n * if the code block is currently visible, e.g., not in a hidden content tab.\n *\n * Note that code blocks may be mounted eagerly or lazily. If they're mounted\n * lazily (on first visibility), code annotation anchor links will not work,\n * as they are evaluated on initial page load, and code annotations in general\n * might feel a little bumpier.\n *\n * @param el - Code block element\n * @param options - Options\n *\n * @returns Code block and annotation component observable\n */\nexport function mountCodeBlock(\n  el: HTMLElement, options: MountOptions\n): Observable<Component<CodeBlock>> {\n  const { matches: hover } = matchMedia(\"(hover)\")\n\n  /* Defer mounting of code block - see https://bit.ly/3vHVoVD */\n  const factory$ = defer(() => {\n    const push$ = new Subject<Overflow>()\n    const done$ = push$.pipe(takeLast(1))\n    push$.subscribe(({ scrollable }) => {\n      if (scrollable && hover)\n        el.setAttribute(\"tabindex\", \"0\")\n      else\n        el.removeAttribute(\"tabindex\")\n    })\n\n    /* Render button for Clipboard.js integration */\n    const content$: Array<Observable<Component<CodeBlock>>> = []\n    if (ClipboardJS.isSupported()) {\n      if (el.closest(\".copy\") || (\n        feature(\"content.code.copy\") && !el.closest(\".no-copy\")\n      )) {\n        const parent = el.closest(\"pre\")!\n        parent.id = `__code_${sequence++}`\n\n        /* Mount tooltip, if enabled */\n        const button = renderClipboardButton(parent.id)\n        parent.insertBefore(button, el)\n        if (feature(\"content.tooltips\"))\n          content$.push(mountInlineTooltip2(button, { viewport$ }))\n      }\n    }\n\n    /* Handle code annotations */\n    const container = el.closest(\".highlight\")\n    if (container instanceof HTMLElement) {\n      const list = findCandidateList(container)\n\n      /* Mount code annotations, if enabled */\n      if (typeof list !== \"undefined\" && (\n        container.classList.contains(\"annotate\") ||\n        feature(\"content.code.annotate\")\n      )) {\n        const annotations$ = mountAnnotationList(list, el, options)\n        content$.push(\n          watchElementSize(container)\n            .pipe(\n              takeUntil(done$),\n              map(({ width, height }) => width && height),\n              distinctUntilChanged(),\n              switchMap(active => active ? annotations$ : EMPTY)\n            )\n        )\n      }\n    }\n\n    // If the code block has line spans, we can add this additional class to\n    // the code block element, which fixes the problem for highlighted code\n    // lines not stretching to the entirety of the screen when the code block\n    // overflows, e.g., on mobile - see\n    const spans = getElements(\":scope > span[id]\", el)\n    if (spans.length)\n      el.classList.add(\"md-code__content\")\n\n    /* Create and return component */\n    return watchCodeBlock(el)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state })),\n        mergeWith(...content$)\n      )\n  })\n\n  /* Mount code block lazily */\n  if (feature(\"content.lazy\"))\n    return watchElementVisibility(el)\n      .pipe(\n        filter(visible => visible),\n        take(1),\n        switchMap(() => factory$)\n      )\n\n  /* Mount code block */\n  return factory$\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  defer,\n  filter,\n  finalize,\n  map,\n  merge,\n  tap\n} from \"rxjs\"\n\nimport { Component } from \"../../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Details\n */\nexport interface Details {\n  action: \"open\" | \"close\"             /* Details state */\n  reveal?: boolean                     /* Details is revealed */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  target$: Observable<HTMLElement>     /* Location target observable */\n  print$: Observable<boolean>          /* Media print observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  target$: Observable<HTMLElement>     /* Location target observable */\n  print$: Observable<boolean>          /* Media print observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch details\n *\n * @param el - Details element\n * @param options - Options\n *\n * @returns Details observable\n */\nexport function watchDetails(\n  el: HTMLDetailsElement, { target$, print$ }: WatchOptions\n): Observable<Details> {\n  let open = true\n  return merge(\n\n    /* Open and focus details on location target */\n    target$\n      .pipe(\n        map(target => target.closest(\"details:not([open])\")!),\n        filter(details => el === details),\n        map(() => ({\n          action: \"open\", reveal: true\n        }) as Details)\n      ),\n\n    /* Open details on print and close afterwards */\n    print$\n      .pipe(\n        filter(active => active || !open),\n        tap(() => open = el.open),\n        map(active => ({\n          action: active ? \"open\" : \"close\"\n        }) as Details)\n      )\n  )\n}\n\n/**\n * Mount details\n *\n * This function ensures that `details` tags are opened on anchor jumps and\n * prior to printing, so the whole content of the page is visible.\n *\n * @param el - Details element\n * @param options - Options\n *\n * @returns Details component observable\n */\nexport function mountDetails(\n  el: HTMLDetailsElement, options: MountOptions\n): Observable<Component<Details>> {\n  return defer(() => {\n    const push$ = new Subject<Details>()\n    push$.subscribe(({ action, reveal }) => {\n      el.toggleAttribute(\"open\", action === \"open\")\n      if (reveal)\n        el.scrollIntoView()\n    })\n\n    /* Create and return component */\n    return watchDetails(el, options)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", ".node circle,.node ellipse,.node path,.node polygon,.node rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}marker{fill:var(--md-mermaid-edge-color)!important}.edgeLabel .label rect{fill:#0000}.label{color:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.label foreignObject{line-height:normal;overflow:visible}.label div .edgeLabel{color:var(--md-mermaid-label-fg-color)}.edgeLabel,.edgeLabel p,.label div .edgeLabel{background-color:var(--md-mermaid-label-bg-color)}.edgeLabel,.edgeLabel p{fill:var(--md-mermaid-label-bg-color);color:var(--md-mermaid-edge-color)}.edgePath .path,.flowchart-link{stroke:var(--md-mermaid-edge-color);stroke-width:.05rem}.edgePath .arrowheadPath{fill:var(--md-mermaid-edge-color);stroke:none}.cluster rect{fill:var(--md-default-fg-color--lightest);stroke:var(--md-default-fg-color--lighter)}.cluster span{color:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}g #flowchart-circleEnd,g #flowchart-circleStart,g #flowchart-crossEnd,g #flowchart-crossStart,g #flowchart-pointEnd,g #flowchart-pointStart{stroke:none}g.classGroup line,g.classGroup rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}g.classGroup text{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.classLabel .box{fill:var(--md-mermaid-label-bg-color);background-color:var(--md-mermaid-label-bg-color);opacity:1}.classLabel .label{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.node .divider{stroke:var(--md-mermaid-node-fg-color)}.relation{stroke:var(--md-mermaid-edge-color)}.cardinality{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.cardinality text{fill:inherit!important}defs #classDiagram-compositionEnd,defs #classDiagram-compositionStart,defs #classDiagram-dependencyEnd,defs #classDiagram-dependencyStart,defs #classDiagram-extensionEnd,defs #classDiagram-extensionStart{fill:var(--md-mermaid-edge-color)!important;stroke:var(--md-mermaid-edge-color)!important}defs #classDiagram-aggregationEnd,defs #classDiagram-aggregationStart{fill:var(--md-mermaid-label-bg-color)!important;stroke:var(--md-mermaid-edge-color)!important}g.stateGroup rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}g.stateGroup .state-title{fill:var(--md-mermaid-label-fg-color)!important;font-family:var(--md-mermaid-font-family)}g.stateGroup .composit{fill:var(--md-mermaid-label-bg-color)}.nodeLabel,.nodeLabel p{color:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}a .nodeLabel{text-decoration:underline}.node circle.state-end,.node circle.state-start,.start-state{fill:var(--md-mermaid-edge-color);stroke:none}.end-state-inner,.end-state-outer{fill:var(--md-mermaid-edge-color)}.end-state-inner,.node circle.state-end{stroke:var(--md-mermaid-label-bg-color)}.transition{stroke:var(--md-mermaid-edge-color)}[id^=state-fork] rect,[id^=state-join] rect{fill:var(--md-mermaid-edge-color)!important;stroke:none!important}.statediagram-cluster.statediagram-cluster .inner{fill:var(--md-default-bg-color)}.statediagram-cluster rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}.statediagram-state rect.divider{fill:var(--md-default-fg-color--lightest);stroke:var(--md-default-fg-color--lighter)}defs #statediagram-barbEnd{stroke:var(--md-mermaid-edge-color)}.attributeBoxEven,.attributeBoxOdd{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}.entityBox{fill:var(--md-mermaid-label-bg-color);stroke:var(--md-mermaid-node-fg-color)}.entityLabel{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.relationshipLabelBox{fill:var(--md-mermaid-label-bg-color);fill-opacity:1;background-color:var(--md-mermaid-label-bg-color);opacity:1}.relationshipLabel{fill:var(--md-mermaid-label-fg-color)}.relationshipLine{stroke:var(--md-mermaid-edge-color)}defs #ONE_OR_MORE_END *,defs #ONE_OR_MORE_START *,defs #ONLY_ONE_END *,defs #ONLY_ONE_START *,defs #ZERO_OR_MORE_END *,defs #ZERO_OR_MORE_START *,defs #ZERO_OR_ONE_END *,defs #ZERO_OR_ONE_START *{stroke:var(--md-mermaid-edge-color)!important}defs #ZERO_OR_MORE_END circle,defs #ZERO_OR_MORE_START circle{fill:var(--md-mermaid-label-bg-color)}.actor{fill:var(--md-mermaid-sequence-actor-bg-color);stroke:var(--md-mermaid-sequence-actor-border-color)}text.actor>tspan{fill:var(--md-mermaid-sequence-actor-fg-color);font-family:var(--md-mermaid-font-family)}line{stroke:var(--md-mermaid-sequence-actor-line-color)}.actor-man circle,.actor-man line{fill:var(--md-mermaid-sequence-actorman-bg-color);stroke:var(--md-mermaid-sequence-actorman-line-color)}.messageLine0,.messageLine1{stroke:var(--md-mermaid-sequence-message-line-color)}.note{fill:var(--md-mermaid-sequence-note-bg-color);stroke:var(--md-mermaid-sequence-note-border-color)}.loopText,.loopText>tspan,.messageText,.noteText>tspan{stroke:none;font-family:var(--md-mermaid-font-family)!important}.messageText{fill:var(--md-mermaid-sequence-message-fg-color)}.loopText,.loopText>tspan{fill:var(--md-mermaid-sequence-loop-fg-color)}.noteText>tspan{fill:var(--md-mermaid-sequence-note-fg-color)}#arrowhead path{fill:var(--md-mermaid-sequence-message-line-color);stroke:none}.loopLine{fill:var(--md-mermaid-sequence-loop-bg-color);stroke:var(--md-mermaid-sequence-loop-border-color)}.labelBox{fill:var(--md-mermaid-sequence-label-bg-color);stroke:none}.labelText,.labelText>span{fill:var(--md-mermaid-sequence-label-fg-color);font-family:var(--md-mermaid-font-family)}.sequenceNumber{fill:var(--md-mermaid-sequence-number-fg-color)}rect.rect{fill:var(--md-mermaid-sequence-box-bg-color);stroke:none}rect.rect+text.text{fill:var(--md-mermaid-sequence-box-fg-color)}defs #sequencenumber{fill:var(--md-mermaid-sequence-number-bg-color)!important}", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  map,\n  of,\n  shareReplay,\n  tap\n} from \"rxjs\"\n\nimport { watchScript } from \"~/browser\"\nimport { h } from \"~/utilities\"\n\nimport { Component } from \"../../_\"\n\nimport themeCSS from \"./index.css\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mermaid diagram\n */\nexport interface Mermaid {}\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Mermaid instance observable\n */\nlet mermaid$: Observable<void>\n\n/**\n * Global sequence number for diagrams\n */\nlet sequence = 0\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Fetch Mermaid script\n *\n * @returns Mermaid scripts observable\n */\nfunction fetchScripts(): Observable<void> {\n  return typeof mermaid === \"undefined\" || mermaid instanceof Element\n    ? watchScript(\"https://unpkg.com/mermaid@11/dist/mermaid.min.js\")\n    : of(undefined)\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount Mermaid diagram\n *\n * @param el - Code block element\n *\n * @returns Mermaid diagram component observable\n */\nexport function mountMermaid(\n  el: HTMLElement\n): Observable<Component<Mermaid>> {\n  el.classList.remove(\"mermaid\") // Hack: mitigate https://bit.ly/3CiN6Du\n  mermaid$ ||= fetchScripts()\n    .pipe(\n      tap(() => mermaid.initialize({\n        startOnLoad: false,\n        themeCSS,\n        sequence: {\n          actorFontSize: \"16px\", // Hack: mitigate https://bit.ly/3y0NEi3\n          messageFontSize: \"16px\",\n          noteFontSize: \"16px\"\n        }\n      })),\n      map(() => undefined),\n      shareReplay(1)\n    )\n\n  /* Render diagram */\n  mermaid$.subscribe(async () => {\n    el.classList.add(\"mermaid\") // Hack: mitigate https://bit.ly/3CiN6Du\n    const id = `__mermaid_${sequence++}`\n\n    /* Create host element to replace code block */\n    const host = h(\"div\", { class: \"mermaid\" })\n    const text = el.textContent\n\n    /* Render and inject diagram */\n    const { svg, fn } = await mermaid.render(id, text)\n\n    /* Create a shadow root and inject diagram */\n    const shadow = host.attachShadow({ mode: \"closed\" })\n    shadow.innerHTML = svg\n\n    /* Replace code block with diagram and bind functions */\n    el.replaceWith(host)\n    fn?.(shadow)\n  })\n\n  /* Create and return component */\n  return mermaid$\n    .pipe(\n      map(() => ({ ref: el }))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { Observable, of } from \"rxjs\"\n\nimport { renderTable } from \"~/templates\"\nimport { h } from \"~/utilities\"\n\nimport { Component } from \"../../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Data table\n */\nexport interface DataTable {}\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Sentinel for replacement\n */\nconst sentinel = h(\"table\")\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount data table\n *\n * This function wraps a data table in another scrollable container, so it can\n * be smoothly scrolled on smaller screen sizes and won't break the layout.\n *\n * @param el - Data table element\n *\n * @returns Data table component observable\n */\nexport function mountDataTable(\n  el: HTMLElement\n): Observable<Component<DataTable>> {\n  el.replaceWith(sentinel)\n  sentinel.replaceWith(renderTable(el))\n\n  /* Create and return component */\n  return of({ ref: el })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  animationFrameScheduler,\n  asyncScheduler,\n  auditTime,\n  combineLatest,\n  defer,\n  endWith,\n  filter,\n  finalize,\n  fromEvent,\n  ignoreElements,\n  map,\n  merge,\n  skip,\n  startWith,\n  subscribeOn,\n  takeUntil,\n  tap,\n  withLatestFrom\n} from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport {\n  Viewport,\n  getElement,\n  getElementContentOffset,\n  getElementContentSize,\n  getElementOffset,\n  getElementSize,\n  getElements,\n  watchElementContentOffset,\n  watchElementSize,\n  watchElementVisibility\n} from \"~/browser\"\nimport { renderTabbedControl } from \"~/templates\"\nimport { h } from \"~/utilities\"\n\nimport { Component } from \"../../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Content tabs\n */\nexport interface ContentTabs {\n  active: HTMLLabelElement             /* Active tab label */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  target$: Observable<HTMLElement>     /* Location target observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch content tabs\n *\n * @param inputs - Content tabs input elements\n *\n * @returns Content tabs observable\n */\nexport function watchContentTabs(\n  inputs: HTMLInputElement[]\n): Observable<ContentTabs> {\n  const initial = inputs.find(input => input.checked) || inputs[0]\n  return merge(...inputs.map(input => fromEvent(input, \"change\")\n    .pipe(\n      map(() => getElement<HTMLLabelElement>(`label[for=\"${input.id}\"]`))\n    )\n  ))\n    .pipe(\n      startWith(getElement<HTMLLabelElement>(`label[for=\"${initial.id}\"]`)),\n      map(active => ({ active }))\n    )\n}\n\n/**\n * Mount content tabs\n *\n * @param el - Content tabs element\n * @param options - Options\n *\n * @returns Content tabs component observable\n */\nexport function mountContentTabs(\n  el: HTMLElement, { viewport$, target$ }: MountOptions\n): Observable<Component<ContentTabs>> {\n  const container = getElement(\".tabbed-labels\", el)\n  const inputs = getElements<HTMLInputElement>(\":scope > input\", el)\n\n  /* Render content tab previous button for pagination */\n  const prev = renderTabbedControl(\"prev\")\n  el.append(prev)\n\n  /* Render content tab next button for pagination */\n  const next = renderTabbedControl(\"next\")\n  el.append(next)\n\n  /* Mount component on subscription */\n  return defer(() => {\n    const push$ = new Subject<ContentTabs>()\n    const done$ = push$.pipe(ignoreElements(), endWith(true))\n    combineLatest([push$, watchElementSize(el), watchElementVisibility(el)])\n      .pipe(\n        takeUntil(done$),\n        auditTime(1, animationFrameScheduler)\n      )\n        .subscribe({\n\n          /* Handle emission */\n          next([{ active }, size]) {\n            const offset = getElementOffset(active)\n            const { width } = getElementSize(active)\n\n            /* Set tab indicator offset and width */\n            el.style.setProperty(\"--md-indicator-x\", `${offset.x}px`)\n            el.style.setProperty(\"--md-indicator-width\", `${width}px`)\n\n            /* Scroll container to active content tab */\n            const content = getElementContentOffset(container)\n            if (\n              offset.x         < content.x              ||\n              offset.x + width > content.x + size.width\n            )\n              container.scrollTo({\n                left: Math.max(0, offset.x - 16),\n                behavior: \"smooth\"\n              })\n          },\n\n          /* Handle complete */\n          complete() {\n            el.style.removeProperty(\"--md-indicator-x\")\n            el.style.removeProperty(\"--md-indicator-width\")\n          }\n        })\n\n    /* Hide content tab buttons on borders */\n    combineLatest([\n      watchElementContentOffset(container),\n      watchElementSize(container)\n    ])\n      .pipe(\n        takeUntil(done$)\n      )\n        .subscribe(([offset, size]) => {\n          const content = getElementContentSize(container)\n          prev.hidden = offset.x < 16\n          next.hidden = offset.x > content.width - size.width - 16\n        })\n\n    /* Paginate content tab container on click */\n    merge(\n      fromEvent(prev, \"click\").pipe(map(() => -1)),\n      fromEvent(next, \"click\").pipe(map(() => +1))\n    )\n      .pipe(\n        takeUntil(done$)\n      )\n        .subscribe(direction => {\n          const { width } = getElementSize(container)\n          container.scrollBy({\n            left: width * direction,\n            behavior: \"smooth\"\n          })\n        })\n\n    /* Switch to content tab target */\n    target$\n      .pipe(\n        takeUntil(done$),\n        filter(input => inputs.includes(input as HTMLInputElement))\n      )\n        .subscribe(input => input.click())\n\n    /* Add link to each content tab label */\n    container.classList.add(\"tabbed-labels--linked\")\n    for (const input of inputs) {\n      const label = getElement<HTMLLabelElement>(`label[for=\"${input.id}\"]`)\n      label.replaceChildren(h(\"a\", {\n        href: `#${label.htmlFor}`,\n        tabIndex: -1\n      }, ...Array.from(label.childNodes)))\n\n      /* Allow to copy link without scrolling to anchor */\n      fromEvent<MouseEvent>(label.firstElementChild!, \"click\")\n        .pipe(\n          takeUntil(done$),\n          filter(ev => !(ev.metaKey || ev.ctrlKey)),\n          tap(ev => {\n            ev.preventDefault()\n            ev.stopPropagation()\n          })\n        )\n          // @todo we might need to remove the anchor link on complete\n          .subscribe(() => {\n            history.replaceState({}, \"\", `#${label.htmlFor}`)\n            label.click()\n          })\n    }\n\n    /* Set up linking of content tabs, if enabled */\n    if (feature(\"content.tabs.link\"))\n      push$.pipe(\n        skip(1),\n        withLatestFrom(viewport$)\n      )\n        .subscribe(([{ active }, { offset }]) => {\n          const tab = active.innerText.trim()\n          if (active.hasAttribute(\"data-md-switching\")) {\n            active.removeAttribute(\"data-md-switching\")\n\n          /* Determine viewport offset of active tab */\n          } else {\n            const y = el.offsetTop - offset.y\n\n            /* Passively activate other tabs */\n            for (const set of getElements(\"[data-tabs]\"))\n              for (const input of getElements<HTMLInputElement>(\n                \":scope > input\", set\n              )) {\n                const label = getElement(`label[for=\"${input.id}\"]`)\n                if (\n                  label !== active &&\n                  label.innerText.trim() === tab\n                ) {\n                  label.setAttribute(\"data-md-switching\", \"\")\n                  input.click()\n                  break\n                }\n              }\n\n            /* Bring active tab into view */\n            window.scrollTo({\n              top: el.offsetTop - y\n            })\n\n            /* Persist active tabs in local storage */\n            const tabs = __md_get<string[]>(\"__tabs\") || []\n            __md_set(\"__tabs\", [...new Set([tab, ...tabs])])\n          }\n        })\n\n    /* Pause media (audio, video) on switch - see https://bit.ly/3Bk6cel */\n    push$.pipe(takeUntil(done$))\n      .subscribe(() => {\n        for (const media of getElements<HTMLAudioElement>(\"audio, video\", el))\n          media.pause()\n      })\n\n    /* Create and return component */\n    return watchContentTabs(inputs)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n    .pipe(\n      subscribeOn(asyncScheduler)\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { Observable, merge } from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport { Viewport, getElements } from \"~/browser\"\n\nimport { Component } from \"../../_\"\nimport {\n  Tooltip,\n  mountInlineTooltip2\n} from \"../../tooltip2\"\nimport {\n  Annotation,\n  mountAnnotationBlock\n} from \"../annotation\"\nimport {\n  CodeBlock,\n  mountCodeBlock\n} from \"../code\"\nimport {\n  Details,\n  mountDetails\n} from \"../details\"\nimport {\n  Mermaid,\n  mountMermaid\n} from \"../mermaid\"\nimport {\n  DataTable,\n  mountDataTable\n} from \"../table\"\nimport {\n  ContentTabs,\n  mountContentTabs\n} from \"../tabs\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Content\n */\nexport type Content =\n  | Annotation\n  | CodeBlock\n  | ContentTabs\n  | DataTable\n  | Details\n  | Mermaid\n  | Tooltip\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  target$: Observable<HTMLElement>     /* Location target observable */\n  print$: Observable<boolean>          /* Media print observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount content\n *\n * This function mounts all components that are found in the content of the\n * actual article, including code blocks, data tables and details.\n *\n * @param el - Content element\n * @param options - Options\n *\n * @returns Content component observable\n */\nexport function mountContent(\n  el: HTMLElement, { viewport$, target$, print$ }: MountOptions\n): Observable<Component<Content>> {\n  return merge(\n\n    /* Annotations */\n    ...getElements(\".annotate:not(.highlight)\", el)\n      .map(child => mountAnnotationBlock(child, { target$, print$ })),\n\n    /* Code blocks */\n    ...getElements(\"pre:not(.mermaid) > code\", el)\n      .map(child => mountCodeBlock(child, { target$, print$ })),\n\n    /* Mermaid diagrams */\n    ...getElements(\"pre.mermaid\", el)\n      .map(child => mountMermaid(child)),\n\n    /* Data tables */\n    ...getElements(\"table:not([class])\", el)\n      .map(child => mountDataTable(child)),\n\n    /* Details */\n    ...getElements(\"details\", el)\n      .map(child => mountDetails(child, { target$, print$ })),\n\n    /* Content tabs */\n    ...getElements(\"[data-tabs]\", el)\n      .map(child => mountContentTabs(child, { viewport$, target$ })),\n\n    /* Tooltips */\n    ...getElements(\"[title]\", el)\n      .filter(() => feature(\"content.tooltips\"))\n      .map(child => mountInlineTooltip2(child, { viewport$ }))\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  defer,\n  delay,\n  finalize,\n  map,\n  merge,\n  of,\n  switchMap,\n  tap\n} from \"rxjs\"\n\nimport { getElement } from \"~/browser\"\n\nimport { Component } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Dialog\n */\nexport interface Dialog {\n  message: string                      /* Dialog message */\n  active: boolean                      /* Dialog is active */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  alert$: Subject<string>              /* Alert subject */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  alert$: Subject<string>              /* Alert subject */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch dialog\n *\n * @param _el - Dialog element\n * @param options - Options\n *\n * @returns Dialog observable\n */\nexport function watchDialog(\n  _el: HTMLElement, { alert$ }: WatchOptions\n): Observable<Dialog> {\n  return alert$\n    .pipe(\n      switchMap(message => merge(\n        of(true),\n        of(false).pipe(delay(2000))\n      )\n        .pipe(\n          map(active => ({ message, active }))\n        )\n      )\n    )\n}\n\n/**\n * Mount dialog\n *\n * This function reveals the dialog in the right corner when a new alert is\n * emitted through the subject that is passed as part of the options.\n *\n * @param el - Dialog element\n * @param options - Options\n *\n * @returns Dialog component observable\n */\nexport function mountDialog(\n  el: HTMLElement, options: MountOptions\n): Observable<Component<Dialog>> {\n  const inner = getElement(\".md-typeset\", el)\n  return defer(() => {\n    const push$ = new Subject<Dialog>()\n    push$.subscribe(({ message, active }) => {\n      el.classList.toggle(\"md-dialog--active\", active)\n      inner.textContent = message\n    })\n\n    /* Create and return component */\n    return watchDialog(el, options)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  Subject,\n  animationFrameScheduler,\n  asyncScheduler,\n  auditTime,\n  combineLatest,\n  debounceTime,\n  defer,\n  distinctUntilChanged,\n  filter,\n  finalize,\n  map,\n  merge,\n  of,\n  subscribeOn,\n  tap,\n  throttleTime\n} from \"rxjs\"\n\nimport {\n  ElementOffset,\n  getElement,\n  getElementContainer,\n  getElementOffset,\n  getElementSize,\n  watchElementContentOffset,\n  watchElementFocus,\n  watchElementHover\n} from \"~/browser\"\nimport { renderTooltip } from \"~/templates\"\n\nimport { Component } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Tooltip\n */\nexport interface Tooltip {\n  active: boolean                      /* Tooltip is active */\n  offset: ElementOffset                /* Tooltip offset */\n}\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Global sequence number for tooltips\n */\nlet sequence = 0\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch tooltip\n *\n * This function will append the tooltip temporarily to compute its width,\n * which is necessary for correct centering, and then removing it again.\n *\n * @param el - Tooltip element\n * @param host - Host element\n *\n * @returns Tooltip observable\n */\nexport function watchTooltip(\n  el: HTMLElement, host: HTMLElement\n): Observable<Tooltip> {\n  document.body.append(el)\n\n  /* Compute width and remove tooltip immediately */\n  const { width } = getElementSize(el)\n  el.style.setProperty(\"--md-tooltip-width\", `${width}px`)\n  el.remove()\n\n  /* Retrieve and watch containing element */\n  const container = getElementContainer(host)\n  const scroll$ =\n    typeof container !== \"undefined\"\n      ? watchElementContentOffset(container)\n      : of({ x: 0, y: 0 })\n\n  /* Compute tooltip visibility */\n  const active$ = merge(\n    watchElementFocus(host),\n    watchElementHover(host)\n  )\n    .pipe(\n      distinctUntilChanged()\n    )\n\n  /* Compute tooltip offset */\n  return combineLatest([active$, scroll$])\n    .pipe(\n      map(([active, scroll]) => {\n        let { x, y } = getElementOffset(host)\n        const size = getElementSize(host)\n\n        /**\n         * Experimental: fix handling of tables - see https://bit.ly/3TQEj5O\n         *\n         * If this proves to be a viable fix, we should refactor tooltip\n         * positioning and somehow streamline the current process. This might\n         * also fix positioning for annotations inside tables, which is another\n         * limitation.\n         */\n        const table = host.closest(\"table\")\n        if (table && host.parentElement) {\n          x += table.offsetLeft + host.parentElement.offsetLeft\n          y += table.offsetTop  + host.parentElement.offsetTop\n        }\n        return {\n          active,\n          offset: {\n            x: x - scroll.x + size.width  / 2 - width / 2,\n            y: y - scroll.y + size.height + 8\n          }\n        }\n      })\n    )\n}\n\n/**\n * Mount tooltip\n *\n * @param el - Host element\n *\n * @returns Tooltip component observable\n */\nexport function mountTooltip(\n  el: HTMLElement\n): Observable<Component<Tooltip>> {\n  const title = el.title\n  if (!title.length)\n    return EMPTY\n\n  /* Render tooltip and set title from host element */\n  const id = `__tooltip_${sequence++}`\n  const tooltip = renderTooltip(id, \"inline\")\n  const typeset = getElement(\".md-typeset\", tooltip)\n  typeset.innerHTML = title\n\n  /* Mount component on subscription */\n  return defer(() => {\n    const push$ = new Subject<Tooltip>()\n    push$.subscribe({\n\n      /* Handle emission */\n      next({ offset }) {\n        tooltip.style.setProperty(\"--md-tooltip-x\", `${offset.x}px`)\n        tooltip.style.setProperty(\"--md-tooltip-y\", `${offset.y}px`)\n      },\n\n      /* Handle complete */\n      complete() {\n        tooltip.style.removeProperty(\"--md-tooltip-x\")\n        tooltip.style.removeProperty(\"--md-tooltip-y\")\n      }\n    })\n\n    /* Toggle tooltip presence to mitigate empty lines when copying */\n    merge(\n      push$.pipe(filter(({ active }) => active)),\n      push$.pipe(debounceTime(250), filter(({ active }) => !active))\n    )\n      .subscribe({\n\n        /* Handle emission */\n        next({ active }) {\n          if (active) {\n            el.insertAdjacentElement(\"afterend\", tooltip)\n            el.setAttribute(\"aria-describedby\", id)\n            el.removeAttribute(\"title\")\n          } else {\n            tooltip.remove()\n            el.removeAttribute(\"aria-describedby\")\n            el.setAttribute(\"title\", title)\n          }\n        },\n\n        /* Handle complete */\n        complete() {\n          tooltip.remove()\n          el.removeAttribute(\"aria-describedby\")\n          el.setAttribute(\"title\", title)\n        }\n      })\n\n    /* Toggle tooltip visibility */\n    push$\n      .pipe(\n        auditTime(16, animationFrameScheduler)\n      )\n        .subscribe(({ active }) => {\n          tooltip.classList.toggle(\"md-tooltip--active\", active)\n        })\n\n    // @todo - refactor positioning together with annotations \u2013 there are\n    // several things that overlap and are identical in handling\n\n    /* Track relative origin of tooltip */\n    push$\n      .pipe(\n        throttleTime(125, animationFrameScheduler),\n        filter(() => !!el.offsetParent),\n        map(() => el.offsetParent!.getBoundingClientRect()),\n        map(({ x }) => x)\n      )\n      .subscribe({\n\n        /* Handle emission */\n        next(origin) {\n          if (origin)\n            tooltip.style.setProperty(\"--md-tooltip-0\", `${-origin}px`)\n          else\n            tooltip.style.removeProperty(\"--md-tooltip-0\")\n        },\n\n        /* Handle complete */\n        complete() {\n          tooltip.style.removeProperty(\"--md-tooltip-0\")\n        }\n      })\n\n    /* Create and return component */\n    return watchTooltip(tooltip, el)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n    .pipe(\n      subscribeOn(asyncScheduler)\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  bufferCount,\n  combineLatest,\n  combineLatestWith,\n  defer,\n  distinctUntilChanged,\n  distinctUntilKeyChanged,\n  endWith,\n  filter,\n  from,\n  ignoreElements,\n  map,\n  mergeMap,\n  mergeWith,\n  of,\n  shareReplay,\n  startWith,\n  switchMap,\n  takeUntil\n} from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport {\n  Viewport,\n  getElements,\n  watchElementSize,\n  watchToggle\n} from \"~/browser\"\n\nimport { Component } from \"../../_\"\nimport { Main } from \"../../main\"\nimport {\n  Tooltip,\n  mountTooltip\n} from \"../../tooltip\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Header\n */\nexport interface Header {\n  height: number                       /* Header visible height */\n  hidden: boolean                      /* Header is hidden */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n  main$: Observable<Main>              /* Main area observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Compute whether the header is hidden\n *\n * If the user scrolls past a certain threshold, the header can be hidden when\n * scrolling down, and shown when scrolling up.\n *\n * @param options - Options\n *\n * @returns Toggle observable\n */\nfunction isHidden({ viewport$ }: WatchOptions): Observable<boolean> {\n  if (!feature(\"header.autohide\"))\n    return of(false)\n\n  /* Compute direction and turning point */\n  const direction$ = viewport$\n    .pipe(\n      map(({ offset: { y } }) => y),\n      bufferCount(2, 1),\n      map(([a, b]) => [a < b, b] as const),\n      distinctUntilKeyChanged(0)\n    )\n\n  /* Compute whether header should be hidden */\n  const hidden$ = combineLatest([viewport$, direction$])\n    .pipe(\n      filter(([{ offset }, [, y]]) => Math.abs(y - offset.y) > 100),\n      map(([, [direction]]) => direction),\n      distinctUntilChanged()\n    )\n\n  /* Compute threshold for hiding */\n  const search$ = watchToggle(\"search\")\n  return combineLatest([viewport$, search$])\n    .pipe(\n      map(([{ offset }, search]) => offset.y > 400 && !search),\n      distinctUntilChanged(),\n      switchMap(active => active ? hidden$ : of(false)),\n      startWith(false)\n    )\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch header\n *\n * @param el - Header element\n * @param options - Options\n *\n * @returns Header observable\n */\nexport function watchHeader(\n  el: HTMLElement, options: WatchOptions\n): Observable<Header> {\n  return defer(() => combineLatest([\n    watchElementSize(el),\n    isHidden(options)\n  ]))\n    .pipe(\n      map(([{ height }, hidden]) => ({\n        height,\n        hidden\n      })),\n      distinctUntilChanged((a, b) => (\n        a.height === b.height &&\n        a.hidden === b.hidden\n      )),\n      shareReplay(1)\n    )\n}\n\n/**\n * Mount header\n *\n * This function manages the different states of the header, i.e. whether it's\n * hidden or rendered with a shadow. This depends heavily on the main area.\n *\n * @param el - Header element\n * @param options - Options\n *\n * @returns Header component observable\n */\nexport function mountHeader(\n  el: HTMLElement, { header$, main$ }: MountOptions\n): Observable<Component<Header | Tooltip>> {\n  return defer(() => {\n    const push$ = new Subject<Main>()\n    const done$ = push$.pipe(ignoreElements(), endWith(true))\n    push$\n      .pipe(\n        distinctUntilKeyChanged(\"active\"),\n        combineLatestWith(header$)\n      )\n        .subscribe(([{ active }, { hidden }]) => {\n          el.classList.toggle(\"md-header--shadow\", active && !hidden)\n          el.hidden = hidden\n        })\n\n    /* Mount tooltips, if enabled */\n    const tooltips = from(getElements(\"[title]\", el))\n      .pipe(\n        filter(() => feature(\"content.tooltips\")),\n        mergeMap(child => mountTooltip(child))\n      )\n\n    /* Link to main area */\n    main$.subscribe(push$)\n\n    /* Create and return component */\n    return header$\n      .pipe(\n        takeUntil(done$),\n        map(state => ({ ref: el, ...state })),\n        mergeWith(tooltips.pipe(takeUntil(done$)))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  Subject,\n  defer,\n  distinctUntilKeyChanged,\n  finalize,\n  map,\n  tap\n} from \"rxjs\"\n\nimport {\n  Viewport,\n  getElementSize,\n  getOptionalElement,\n  watchViewportAt\n} from \"~/browser\"\n\nimport { Component } from \"../../_\"\nimport { Header } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Header\n */\nexport interface HeaderTitle {\n  active: boolean                      /* Header title is active */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch header title\n *\n * @param el - Heading element\n * @param options - Options\n *\n * @returns Header title observable\n */\nexport function watchHeaderTitle(\n  el: HTMLElement, { viewport$, header$ }: WatchOptions\n): Observable<HeaderTitle> {\n  return watchViewportAt(el, { viewport$, header$ })\n    .pipe(\n      map(({ offset: { y } }) => {\n        const { height } = getElementSize(el)\n        return {\n          active: y >= height\n        }\n      }),\n      distinctUntilKeyChanged(\"active\")\n    )\n}\n\n/**\n * Mount header title\n *\n * This function swaps the header title from the site title to the title of the\n * current page when the user scrolls past the first headline.\n *\n * @param el - Header title element\n * @param options - Options\n *\n * @returns Header title component observable\n */\nexport function mountHeaderTitle(\n  el: HTMLElement, options: MountOptions\n): Observable<Component<HeaderTitle>> {\n  return defer(() => {\n    const push$ = new Subject<HeaderTitle>()\n    push$.subscribe({\n\n      /* Handle emission */\n      next({ active }) {\n        el.classList.toggle(\"md-header__title--active\", active)\n      },\n\n      /* Handle complete */\n      complete() {\n        el.classList.remove(\"md-header__title--active\")\n      }\n    })\n\n    /* Obtain headline, if any */\n    const heading = getOptionalElement(\".md-content h1\")\n    if (typeof heading === \"undefined\")\n      return EMPTY\n\n    /* Create and return component */\n    return watchHeaderTitle(heading, options)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  combineLatest,\n  distinctUntilChanged,\n  distinctUntilKeyChanged,\n  map,\n  switchMap\n} from \"rxjs\"\n\nimport {\n  Viewport,\n  watchElementSize\n} from \"~/browser\"\n\nimport { Header } from \"../header\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Main area\n */\nexport interface Main {\n  offset: number                       /* Main area top offset */\n  height: number                       /* Main area visible height */\n  active: boolean                      /* Main area is active */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch main area\n *\n * This function returns an observable that computes the visual parameters of\n * the main area which depends on the viewport vertical offset and height, as\n * well as the height of the header element, if the header is fixed.\n *\n * @param el - Main area element\n * @param options - Options\n *\n * @returns Main area observable\n */\nexport function watchMain(\n  el: HTMLElement, { viewport$, header$ }: WatchOptions\n): Observable<Main> {\n\n  /* Compute necessary adjustment for header */\n  const adjust$ = header$\n    .pipe(\n      map(({ height }) => height),\n      distinctUntilChanged()\n    )\n\n  /* Compute the main area's top and bottom borders */\n  const border$ = adjust$\n    .pipe(\n      switchMap(() => watchElementSize(el)\n        .pipe(\n          map(({ height }) => ({\n            top:    el.offsetTop,\n            bottom: el.offsetTop + height\n          })),\n          distinctUntilKeyChanged(\"bottom\")\n        )\n      )\n    )\n\n  /* Compute the main area's offset, visible height and if we scrolled past */\n  return combineLatest([adjust$, border$, viewport$])\n    .pipe(\n      map(([header, { top, bottom }, { offset: { y }, size: { height } }]) => {\n        height = Math.max(0, height\n          - Math.max(0, top    - y,  header)\n          - Math.max(0, height + y - bottom)\n        )\n        return {\n          offset: top - header,\n          height,\n          active: top - header <= y\n        }\n      }),\n      distinctUntilChanged((a, b) => (\n        a.offset === b.offset &&\n        a.height === b.height &&\n        a.active === b.active\n      ))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  asyncScheduler,\n  defer,\n  filter,\n  finalize,\n  fromEvent,\n  map,\n  mergeMap,\n  observeOn,\n  of,\n  repeat,\n  shareReplay,\n  skip,\n  startWith,\n  takeUntil,\n  tap,\n  withLatestFrom\n} from \"rxjs\"\n\nimport { getElements, watchMedia } from \"~/browser\"\nimport { h } from \"~/utilities\"\n\nimport {\n  Component,\n  getComponentElement\n} from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Palette colors\n */\nexport interface PaletteColor {\n  media?: string                       /* Media query */\n  scheme?: string                      /* Color scheme */\n  primary?: string                     /* Primary color */\n  accent?: string                      /* Accent color */\n}\n\n/**\n * Palette\n */\nexport interface Palette {\n  index: number                        /* Palette index */\n  color: PaletteColor                  /* Palette colors */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch color palette\n *\n * @param inputs - Color palette element\n *\n * @returns Color palette observable\n */\nexport function watchPalette(\n  inputs: HTMLInputElement[]\n): Observable<Palette> {\n  const current = __md_get<Palette>(\"__palette\") || {\n    index: inputs.findIndex(input => matchMedia(\n      input.getAttribute(\"data-md-color-media\")!\n    ).matches)\n  }\n\n  /* Emit changes in color palette */\n  const index = Math.max(0, Math.min(current.index, inputs.length - 1))\n  return of(...inputs)\n    .pipe(\n      mergeMap(input => fromEvent(input, \"change\").pipe(map(() => input))),\n      startWith(inputs[index]),\n      map(input => ({\n        index: inputs.indexOf(input),\n        color: {\n          media:   input.getAttribute(\"data-md-color-media\"),\n          scheme:  input.getAttribute(\"data-md-color-scheme\"),\n          primary: input.getAttribute(\"data-md-color-primary\"),\n          accent:  input.getAttribute(\"data-md-color-accent\")\n        }\n      } as Palette)),\n      shareReplay(1)\n    )\n}\n\n/**\n * Mount color palette\n *\n * @param el - Color palette element\n *\n * @returns Color palette component observable\n */\nexport function mountPalette(\n  el: HTMLElement\n): Observable<Component<Palette>> {\n  const inputs = getElements<HTMLInputElement>(\"input\", el)\n  const meta = h(\"meta\", { name: \"theme-color\" })\n  document.head.appendChild(meta)\n\n  // Add color scheme meta tag\n  const scheme = h(\"meta\", { name: \"color-scheme\" })\n  document.head.appendChild(scheme)\n\n  /* Mount component on subscription */\n  const media$ = watchMedia(\"(prefers-color-scheme: light)\")\n  return defer(() => {\n    const push$ = new Subject<Palette>()\n    push$.subscribe(palette => {\n      document.body.setAttribute(\"data-md-color-switching\", \"\")\n\n      /* Retrieve color palette for system preference */\n      if (palette.color.media === \"(prefers-color-scheme)\") {\n        const media = matchMedia(\"(prefers-color-scheme: light)\")\n        const input = document.querySelector(media.matches\n          ? \"[data-md-color-media='(prefers-color-scheme: light)']\"\n          : \"[data-md-color-media='(prefers-color-scheme: dark)']\"\n        )!\n\n        /* Retrieve colors for system preference */\n        palette.color.scheme  = input.getAttribute(\"data-md-color-scheme\")!\n        palette.color.primary = input.getAttribute(\"data-md-color-primary\")!\n        palette.color.accent  = input.getAttribute(\"data-md-color-accent\")!\n      }\n\n      /* Set color palette */\n      for (const [key, value] of Object.entries(palette.color))\n        document.body.setAttribute(`data-md-color-${key}`, value)\n\n      /* Set toggle visibility */\n      for (let index = 0; index < inputs.length; index++) {\n        const label = inputs[index].nextElementSibling\n        if (label instanceof HTMLElement)\n          label.hidden = palette.index !== index\n      }\n\n      /* Persist preference in local storage */\n      __md_set(\"__palette\", palette)\n    })\n\n    // Handle color switch on Enter or Space - see https://t.ly/YIhVj\n    fromEvent<KeyboardEvent>(el, \"keydown\").pipe(\n      filter(ev => ev.key === \"Enter\"),\n      withLatestFrom(push$, (_, palette) => palette)\n    )\n      .subscribe(({ index }) => {\n        index = (index + 1) % inputs.length\n        inputs[index].click()\n        inputs[index].focus()\n      })\n\n    /* Update theme-color meta tag */\n    push$\n      .pipe(\n        map(() => {\n          const header = getComponentElement(\"header\")\n          const style  = window.getComputedStyle(header)\n\n          // Set color scheme\n          scheme.content = style.colorScheme\n\n          /* Return color in hexadecimal format */\n          return style.backgroundColor.match(/\\d+/g)!\n            .map(value => (+value).toString(16).padStart(2, \"0\"))\n            .join(\"\")\n        })\n      )\n        .subscribe(color => meta.content = `#${color}`)\n\n    /* Revert transition durations after color switch */\n    push$.pipe(observeOn(asyncScheduler))\n      .subscribe(() => {\n        document.body.removeAttribute(\"data-md-color-switching\")\n      })\n\n    /* Create and return component */\n    return watchPalette(inputs)\n      .pipe(\n        takeUntil(media$.pipe(skip(1))),\n        repeat(),\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  defer,\n  finalize,\n  map,\n  tap\n} from \"rxjs\"\n\nimport { Component } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Progress indicator\n */\nexport interface Progress {\n  value: number                        // Progress value\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  progress$: Subject<number>           // Progress subject\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount progress indicator\n *\n * @param el - Progress indicator element\n * @param options - Options\n *\n * @returns Progress indicator component observable\n */\nexport function mountProgress(\n  el: HTMLElement, { progress$ }: MountOptions\n): Observable<Component<Progress>> {\n\n  // Mount component on subscription\n  return defer(() => {\n    const push$ = new Subject<Progress>()\n    push$.subscribe(({ value }) => {\n      el.style.setProperty(\"--md-progress-value\", `${value}`)\n    })\n\n    // Create and return component\n    return progress$\n      .pipe(\n        tap(value => push$.next({ value })),\n        finalize(() => push$.complete()),\n        map(value => ({ ref: el, value }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport ClipboardJS from \"clipboard\"\nimport {\n  Observable,\n  Subject,\n  map,\n  tap\n} from \"rxjs\"\n\nimport { translation } from \"~/_\"\nimport { getElement } from \"~/browser\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Setup options\n */\ninterface SetupOptions {\n  alert$: Subject<string>              /* Alert subject */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Extract text to copy\n *\n * @param el - HTML element\n *\n * @returns Extracted text\n */\nfunction extract(el: HTMLElement): string {\n  el.setAttribute(\"data-md-copying\", \"\")\n  const copy = el.closest(\"[data-copy]\")\n  const text = copy\n    ? copy.getAttribute(\"data-copy\")!\n    : el.innerText\n  el.removeAttribute(\"data-md-copying\")\n  return text.trimEnd()\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Set up Clipboard.js integration\n *\n * @param options - Options\n */\nexport function setupClipboardJS(\n  { alert$ }: SetupOptions\n): void {\n  if (ClipboardJS.isSupported()) {\n    new Observable<ClipboardJS.Event>(subscriber => {\n      new ClipboardJS(\"[data-clipboard-target], [data-clipboard-text]\", {\n        text: el => (\n          el.getAttribute(\"data-clipboard-text\")! ||\n          extract(getElement(\n            el.getAttribute(\"data-clipboard-target\")!\n          ))\n        )\n      })\n        .on(\"success\", ev => subscriber.next(ev))\n    })\n      .pipe(\n        tap(ev => {\n          const trigger = ev.trigger as HTMLElement\n          trigger.focus()\n        }),\n        map(() => translation(\"clipboard.copied\"))\n      )\n        .subscribe(alert$)\n  }\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  catchError,\n  map,\n  of\n} from \"rxjs\"\n\nimport {\n  getElement,\n  getElements,\n  requestXML\n} from \"~/browser\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Sitemap, i.e. a list of URLs\n */\nexport type Sitemap = Map<string, URL[]>\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Resolve URL to the given base URL\n *\n * When serving the site with instant navigation, MkDocs will set the hostname\n * to the value as specified in `dev_addr`, but the browser allows for several\n * hostnames to be used: `localhost`, `127.0.0.1` or even `0.0.0.0`, depending\n * on configuration. This function resolves the URL to the given hostname.\n *\n * @param url - URL\n * @param base - Base URL\n *\n * @returns Resolved URL\n */\nfunction resolve(url: URL, base: URL) {\n  url.protocol = base.protocol\n  url.hostname = base.hostname\n  return url\n}\n\n/**\n * Extract sitemap from document\n *\n * This function extracts the URLs and alternate links from the document, and\n * associates alternate links to the original URL as found in `loc`, allowing\n * the browser to navigate to the correct page when switching languages. The\n * format of the sitemap is expected to adhere to:\n *\n * ``` xml\n * <urlset>\n *   <url>\n *     <loc>...</loc>\n *     <xhtml:link rel=\"alternate\" hreflang=\"en\" href=\"...\"/>\n *     <xhtml:link rel=\"alternate\" hreflang=\"de\" href=\"...\"/>\n *     ...\n *   </url>\n *   ...\n * </urlset>\n * ```\n *\n * @param document - Document\n * @param base - Base URL\n *\n * @returns Sitemap\n */\nfunction extract(document: Document, base: URL): Sitemap {\n  const sitemap: Sitemap = new Map()\n  for (const el of getElements(\"url\", document)) {\n    const url = getElement(\"loc\", el)\n\n    // Create entry for location and add it to the list of links\n    const links = [resolve(new URL(url.textContent!), base)]\n    sitemap.set(`${links[0]}`, links)\n\n    // Attach alternate links to current entry\n    for (const link of getElements(\"[rel=alternate]\", el)) {\n      const href = link.getAttribute(\"href\")\n      if (href != null)\n        links.push(resolve(new URL(href), base))\n    }\n  }\n\n  // Return sitemap\n  return sitemap\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Fetch the sitemap for the given base URL\n *\n * If a network or parsing error occurs, we just default to an empty sitemap,\n * which means the caller should fall back to regular navigation.\n *\n * @param base - Base URL\n *\n * @returns Sitemap observable\n */\nexport function fetchSitemap(base: URL | string): Observable<Sitemap> {\n  return requestXML(new URL(\"sitemap.xml\", base))\n    .pipe(\n      map(document => extract(document, new URL(base))),\n      catchError(() => of(new Map())),\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  Subject,\n  catchError,\n  combineLatestWith,\n  concat,\n  debounceTime,\n  distinctUntilChanged,\n  distinctUntilKeyChanged,\n  endWith,\n  fromEvent,\n  ignoreElements,\n  map,\n  merge,\n  of,\n  share,\n  switchMap,\n  tap,\n  withLatestFrom\n} from \"rxjs\"\n\nimport { configuration, feature } from \"~/_\"\nimport {\n  Viewport,\n  getElements,\n  getLocation,\n  getOptionalElement,\n  requestHTML,\n  setLocation,\n  setLocationHash\n} from \"~/browser\"\nimport { getComponentElement } from \"~/components\"\n\nimport { Sitemap, fetchSitemap } from \"../sitemap\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Setup options\n */\ninterface SetupOptions {\n  location$: Subject<URL>              // Location subject\n  viewport$: Observable<Viewport>      // Viewport observable\n  progress$: Subject<number>           // Progress subject\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Handle clicks on internal URLs while skipping external URLs\n *\n * @param ev - Mouse event\n * @param sitemap - Sitemap\n *\n * @returns URL observable\n */\nfunction handle(\n  ev: MouseEvent, sitemap: Sitemap\n): Observable<URL> {\n  if (!(ev.target instanceof Element))\n    return EMPTY\n\n  // Skip, as target is not within a link - clicks on non-link elements are\n  // also captured, which we need to exclude from processing\n  const el = ev.target.closest(\"a\")\n  if (el === null)\n    return EMPTY\n\n  // Skip, as link opens in new window - we now know we have captured a click\n  // on a link, but the link either has a `target` property defined, or the\n  // user pressed the `meta` or `ctrl` key to open it in a new window. Thus,\n  // we need to filter this event as well.\n  if (el.target || ev.metaKey || ev.ctrlKey)\n    return EMPTY\n\n  // Next, we must check if the URL is relevant for us, i.e., if it's an\n  // internal link to a page that is managed by MkDocs. Only then we can be\n  // sure that the structure of the page to be loaded adheres to the current\n  // document structure and can subsequently be injected into it without doing\n  // a full reload. For this reason, we must canonicalize the URL by removing\n  // all search parameters and hash fragments.\n  const url = new URL(el.href)\n  url.search = url.hash = \"\"\n\n  // Skip, if URL is not included in the sitemap - this could be the case when\n  // linking between versions or languages, or to another page that the author\n  // included as part of the build, but that is not managed by MkDocs. In that\n  // case we must not continue with instant navigation.\n  if (!sitemap.has(`${url}`))\n    return EMPTY\n\n  // We now know that we have a link to an internal page, so we prevent the\n  // browser from navigation and emit the URL for instant navigation. Note that\n  // this also includes anchor links, which means we need to implement anchor\n  // positioning ourselves. The reason for this is that if we wouldn't manage\n  // anchor links as well, scroll restoration will not work correctly (e.g.\n  // following an anchor link and scrolling).\n  ev.preventDefault()\n  return of(new URL(el.href))\n}\n\n/**\n * Create a map of head elements for lookup and replacement\n *\n * @param document - Document\n *\n * @returns Tag map\n */\nfunction head(document: Document): Map<string, HTMLElement> {\n  const tags = new Map<string, HTMLElement>()\n  for (const el of getElements(\":scope > *\", document.head))\n    tags.set(el.outerHTML, el)\n\n  // Return tag map\n  return tags\n}\n\n/**\n * Resolve relative URLs in the given document\n *\n * This function resolves relative `href` and `src` attributes, which can belong\n * to all sorts of tags, like meta tags, links, images, scripts and more.\n *\n * @param document - Document\n *\n * @returns Document observable\n */\nfunction resolve(document: Document): Observable<Document> {\n  for (const el of getElements(\"[href], [src]\", document))\n    for (const key of [\"href\", \"src\"]) {\n      const value = el.getAttribute(key)\n      if (value && !/^(?:[a-z]+:)?\\/\\//i.test(value)) {\n        // @ts-expect-error - trick: self-assign to resolve URL\n        el[key] = el[key]\n        break\n      }\n    }\n\n  // Return document observable\n  return of(document)\n}\n\n/**\n * Inject the contents of a document into the current one\n *\n * @param next - Next document\n *\n * @returns Document observable\n */\nfunction inject(next: Document): Observable<Document> {\n  for (const selector of [\n    \"[data-md-component=announce]\",\n    \"[data-md-component=container]\",\n    \"[data-md-component=header-topic]\",\n    \"[data-md-component=outdated]\",\n    \"[data-md-component=logo]\",\n    \"[data-md-component=skip]\",\n    ...feature(\"navigation.tabs.sticky\")\n      ? [\"[data-md-component=tabs]\"]\n      : []\n  ]) {\n    const source = getOptionalElement(selector)\n    const target = getOptionalElement(selector, next)\n    if (\n      typeof source !== \"undefined\" &&\n      typeof target !== \"undefined\"\n    ) {\n      source.replaceWith(target)\n    }\n  }\n\n  // Update meta tags\n  const tags = head(document)\n  for (const [html, el] of head(next))\n    if (tags.has(html))\n      tags.delete(html)\n    else\n      document.head.appendChild(el)\n\n  // Remove meta tags that are not present in the new document\n  for (const el of tags.values()) {\n    const name = el.getAttribute(\"name\")\n    // @todo - find a better way to handle attributes we add dynamically in\n    // other components without mounting components on every navigation, as\n    // this might impact overall performance - see https://t.ly/ehp_O\n    if (name !== \"theme-color\" && name !== \"color-scheme\")\n      el.remove()\n  }\n\n  // After components and meta tags were replaced, re-evaluate scripts\n  // that were provided by the author as part of Markdown files\n  const container = getComponentElement(\"container\")\n  return concat(getElements(\"script\", container))\n    .pipe(\n      switchMap(el => {\n        const script = next.createElement(\"script\")\n        if (el.src) {\n          for (const name of el.getAttributeNames())\n            script.setAttribute(name, el.getAttribute(name)!)\n          el.replaceWith(script)\n\n          // Complete when script is loaded\n          return new Observable(observer => {\n            script.onload = () => observer.complete()\n          })\n\n        // Complete immediately\n        } else {\n          script.textContent = el.textContent\n          el.replaceWith(script)\n          return EMPTY\n        }\n      }),\n      ignoreElements(),\n      endWith(document)\n    )\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Set up instant navigation\n *\n * This is a heavily orchestrated operation - see inline comments to learn how\n * this works with Material for MkDocs, and how you can hook into it.\n *\n * @param options - Options\n *\n * @returns Document observable\n */\nexport function setupInstantNavigation(\n  { location$, viewport$, progress$ }: SetupOptions\n): Observable<Document> {\n  const config = configuration()\n  if (location.protocol === \"file:\")\n    return EMPTY\n\n  // Load sitemap immediately, so we have it available when the user initiates\n  // the first navigation request without any perceivable delay\n  const sitemap$ = fetchSitemap(config.base)\n\n  // Since we might be on a slow connection, the user might trigger multiple\n  // instant navigation events that overlap. MkDocs produces relative URLs for\n  // all internal links, which becomes a problem in this case, because we need\n  // to change the base URL the moment the user clicks a link that should be\n  // intercepted in order to be consistent with popstate, which means that the\n  // base URL would now be incorrect when resolving another relative link from\n  // the same site. For this reason we always resolve all relative links to\n  // absolute links, so we can be sure this never happens.\n  of(document)\n    .subscribe(resolve)\n\n  // --------------------------------------------------------------------------\n  // Navigation interception\n  // --------------------------------------------------------------------------\n\n  // Intercept navigation - to keep the number of event listeners down we use\n  // the fact that uncaptured events bubble up to the body. This has the nice\n  // property that we don't need to detach and then re-attach event listeners\n  // when the document is replaced after a navigation event.\n  const instant$ =\n    fromEvent<MouseEvent>(document.body, \"click\")\n      .pipe(\n        combineLatestWith(sitemap$),\n        switchMap(([ev, sitemap]) => handle(ev, sitemap)),\n        share()\n      )\n\n  // Intercept history change events, e.g. when the user uses the browser's\n  // back or forward buttons, and emit new location for fetching and parsing\n  const history$ =\n    fromEvent<PopStateEvent>(window, \"popstate\")\n      .pipe(\n        map(getLocation),\n        share()\n      )\n\n  // While it would be better UX to defer navigation events until the document\n  // is fully fetched and parsed, we must schedule it here to synchronize with\n  // popstate events, as they are emitted immediately. Moreover we need to\n  // store the current viewport offset for scroll restoration later on.\n  instant$.pipe(withLatestFrom(viewport$))\n    .subscribe(([url, { offset }]) => {\n      history.replaceState(offset, \"\")\n      history.pushState(null, \"\", url)\n    })\n\n  // Emit URLs that should be fetched via instant navigation on location subject\n  // which was passed into this function. The state of instant navigation can be\n  // intercepted by other parts of the application, which can synchronously back\n  // up or restore state before or after instant navigation happens.\n  merge(instant$, history$)\n    .subscribe(location$)\n\n  // --------------------------------------------------------------------------\n  // Fetching and parsing\n  // --------------------------------------------------------------------------\n\n  // Fetch document - we deduplicate requests to the same location, so we don't\n  // end up with multiple requests for the same page. We use `switchMap`, since\n  // we want to cancel the previous request when a new one is triggered, which\n  // is automatically handled by the observable returned by `request`. This is\n  // essential to ensure a good user experience, as we don't want to load pages\n  // that are not needed anymore, e.g., when the user clicks multiple links in\n  // quick succession or on slow connections. If the request fails for some\n  // reason, we fall back and use regular navigation, forcing a reload.\n  const document$ =\n    location$.pipe(\n      distinctUntilKeyChanged(\"pathname\"),\n      switchMap(url => requestHTML(url, { progress$ })\n        .pipe(\n          catchError(() => {\n            setLocation(url, true)\n            return EMPTY\n          })\n        )\n      ),\n\n      // The document was successfully fetched and parsed, so we can inject its\n      // contents into the currently active document\n      switchMap(resolve),\n      switchMap(inject),\n      share()\n    )\n\n  // --------------------------------------------------------------------------\n  // Scroll restoration\n  // --------------------------------------------------------------------------\n\n  // Handle scroll restoration - we must restore the viewport offset after the\n  // document has been fetched and injected, and every time the user clicks an\n  // anchor that leads to an element on the same page, which might also happen\n  // when the user uses the back or forward button.\n  merge(\n    document$.pipe(withLatestFrom(location$, (_, url) => url)),\n\n    // Handle instant navigation events that are triggered by the user clicking\n    // on an anchor link with a hash fragment different from the current one, as\n    // well as from popstate events, which are emitted when the user navigates\n    // back and forth between pages. We use a two-layered subscription to scope\n    // the scroll restoration to the current page, as we don't need to restore\n    // the viewport offset when the user navigates to a different page, as this\n    // is already handled by the previous observable.\n    document$.pipe(\n      switchMap(() => location$),\n      distinctUntilKeyChanged(\"pathname\"),\n      switchMap(() => location$),\n      distinctUntilKeyChanged(\"hash\")\n    ),\n\n    // Handle instant navigation events that are triggered by the user clicking\n    // on an anchor link with the same hash fragment as the current one in the\n    // URL. It is essential that we only intercept those from instant navigation\n    // events and not from history change events, or we'll end up in and endless\n    // loop. The top-level history entry must be removed, as it will be replaced\n    // with a new one, which would otherwise lead to a duplicate entry.\n    location$.pipe(\n      distinctUntilChanged((a, b) => (\n        a.pathname === b.pathname &&\n        a.hash     === b.hash\n      )),\n      switchMap(() => instant$),\n      tap(() => history.back())\n    )\n  )\n    .subscribe(url => {\n\n      // Check if the current history entry has a state, which happens when the\n      // user presses the back or forward button to visit a page we've already\n      // seen. If there's no state, it means a new page was visited and we must\n      // scroll to the top, unless an anchor is given.\n      if (history.state !== null || !url.hash) {\n        window.scrollTo(0, history.state?.y ?? 0)\n      } else {\n        history.scrollRestoration = \"auto\"\n        setLocationHash(url.hash)\n        history.scrollRestoration = \"manual\"\n      }\n    })\n\n  // Disable scroll restoration when an instant navigation event occurs, so the\n  // browser does not immediately set the viewport offset to the prior history\n  // entry, scrolling to the position on the same page, which would look odd.\n  // Instead, we manually restore the position once the page has loaded.\n  location$.subscribe(() => {\n    history.scrollRestoration = \"manual\"\n  })\n\n  // Enable scroll restoration before window unloads - this is essential to\n  // ensure that full reloads (F5) restore the viewport offset correctly. If\n  // only popstate events wouldn't reset the viewport offset prior to their\n  // emission, we could just reset this in popstate. Meh.\n  fromEvent(window, \"beforeunload\")\n    .subscribe(() => {\n      history.scrollRestoration = \"auto\"\n    })\n\n  // Track viewport offset, so we can restore it when the user navigates back\n  // and forth between pages. Note that this must be debounced and cannot be\n  // done in popstate, as popstate has already removed the entry from the\n  // history, which means it is too late.\n  viewport$.pipe(\n    distinctUntilKeyChanged(\"offset\"),\n    debounceTime(100)\n  )\n    .subscribe(({ offset }) => {\n      history.replaceState(offset, \"\")\n    })\n\n  // Return document observable\n  return document$\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport escapeHTML from \"escape-html\"\n\nimport { SearchConfig } from \"../config\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Search highlight function\n *\n * @param value - Value\n *\n * @returns Highlighted value\n */\nexport type SearchHighlightFn = (value: string) => string\n\n/**\n * Search highlight factory function\n *\n * @param query - Query value\n *\n * @returns Search highlight function\n */\nexport type SearchHighlightFactoryFn = (query: string) => SearchHighlightFn\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Create a search highlighter\n *\n * @param config - Search configuration\n *\n * @returns Search highlight factory function\n */\nexport function setupSearchHighlighter(\n  config: SearchConfig\n): SearchHighlightFactoryFn {\n  // Hack: temporarily remove pure lookaheads and lookbehinds\n  const regex = config.separator.split(\"|\").map(term => {\n    const temp = term.replace(/(\\(\\?[!=<][^)]+\\))/g, \"\")\n    return temp.length === 0 ? \"\uFFFD\" : term\n  })\n    .join(\"|\")\n\n  const separator = new RegExp(regex, \"img\")\n  const highlight = (_: unknown, data: string, term: string) => {\n    return `${data}<mark data-md-highlight>${term}</mark>`\n  }\n\n  /* Return factory function */\n  return (query: string) => {\n    query = query\n      .replace(/[\\s*+\\-:~^]+/g, \" \")\n      .trim()\n\n    /* Create search term match expression */\n    const match = new RegExp(`(^|${config.separator}|)(${\n      query\n        .replace(/[|\\\\{}()[\\]^$+*?.-]/g, \"\\\\$&\")\n        .replace(separator, \"|\")\n    })`, \"img\")\n\n    /* Highlight string value */\n    return value => escapeHTML(value)\n      .replace(match, highlight)\n      .replace(/<\\/mark>(\\s+)<mark[^>]*>/img, \"$1\")\n  }\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A RTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { SearchResult } from \"../../_\"\nimport { SearchIndex } from \"../../config\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Search message type\n */\nexport const enum SearchMessageType {\n  SETUP,                               /* Search index setup */\n  READY,                               /* Search index ready */\n  QUERY,                               /* Search query */\n  RESULT                               /* Search results */\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Message containing the data necessary to setup the search index\n */\nexport interface SearchSetupMessage {\n  type: SearchMessageType.SETUP        /* Message type */\n  data: SearchIndex                    /* Message data */\n}\n\n/**\n * Message indicating the search index is ready\n */\nexport interface SearchReadyMessage {\n  type: SearchMessageType.READY        /* Message type */\n}\n\n/**\n * Message containing a search query\n */\nexport interface SearchQueryMessage {\n  type: SearchMessageType.QUERY        /* Message type */\n  data: string                         /* Message data */\n}\n\n/**\n * Message containing results for a search query\n */\nexport interface SearchResultMessage {\n  type: SearchMessageType.RESULT       /* Message type */\n  data: SearchResult                   /* Message data */\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Message exchanged with the search worker\n */\nexport type SearchMessage =\n  | SearchSetupMessage\n  | SearchReadyMessage\n  | SearchQueryMessage\n  | SearchResultMessage\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Type guard for search ready messages\n *\n * @param message - Search worker message\n *\n * @returns Test result\n */\nexport function isSearchReadyMessage(\n  message: SearchMessage\n): message is SearchReadyMessage {\n  return message.type === SearchMessageType.READY\n}\n\n/**\n * Type guard for search result messages\n *\n * @param message - Search worker message\n *\n * @returns Test result\n */\nexport function isSearchResultMessage(\n  message: SearchMessage\n): message is SearchResultMessage {\n  return message.type === SearchMessageType.RESULT\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A RTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  ObservableInput,\n  Subject,\n  first,\n  merge,\n  of,\n  switchMap\n} from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport { watchToggle, watchWorker } from \"~/browser\"\n\nimport { SearchIndex } from \"../../config\"\nimport {\n  SearchMessage,\n  SearchMessageType\n} from \"../message\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Set up search worker\n *\n * This function creates and initializes a web worker that is used for search,\n * so that the user interface doesn't freeze. In general, the application does\n * not care how search is implemented, as long as the web worker conforms to\n * the format expected by the application as defined in `SearchMessage`. This\n * allows the author to implement custom search functionality, by providing a\n * custom web worker via configuration.\n *\n * Material for MkDocs' built-in search implementation makes use of Lunr.js, an\n * efficient and fast implementation for client-side search. Leveraging a tiny\n * iframe-based web worker shim, search is even supported for the `file://`\n * protocol, enabling search for local non-hosted builds.\n *\n * If the protocol is `file://`, search initialization is deferred to mitigate\n * freezing, as it's now synchronous by design - see https://bit.ly/3C521EO\n *\n * @see https://bit.ly/3igvtQv - How to implement custom search\n *\n * @param url - Worker URL\n * @param index$ - Search index observable input\n *\n * @returns Search worker\n */\nexport function setupSearchWorker(\n  url: string, index$: ObservableInput<SearchIndex>\n): Subject<SearchMessage> {\n  const worker$ = watchWorker<SearchMessage>(url)\n  merge(\n    of(location.protocol !== \"file:\"),\n    watchToggle(\"search\")\n  )\n    .pipe(\n      first(active => active),\n      switchMap(() => index$)\n    )\n      .subscribe(({ config, docs }) => worker$.next({\n        type: SearchMessageType.SETUP,\n        data: {\n          config,\n          docs,\n          options: {\n            suggest: feature(\"search.suggest\")\n          }\n        }\n      }))\n\n  /* Return search worker */\n  return worker$\n}\n", "import { Sitemap } from \"../../sitemap\"\n\n/** See docstring for `selectedVersionCorrespondingURL` for the meaning of these fields. */\ntype CorrespondingURLParams = {\n  selectedVersionSitemap: Sitemap\n  selectedVersionBaseURL: URL\n  currentLocation: URL\n  currentBaseURL: string\n}\n\n/**\n * Choose a URL to navigate to when the user chooses a version in the version\n * selector.\n *\n * The parameters in `params` are named as follows, in order to make it clearer\n * which parameter means what when invoking the function:\n *\n *  - selectedVersionSitemap: Sitemap - as obtained by fetchSitemap from `${selectedVersionBaseURL}/sitemap.xml`\n *\n *  - selectedVersionBaseURL: URL - usually `${currentBaseURL}/../selectedVersion`\n *\n *  - currentLocation: URL - current web browser location\n *\n *  - currentBaseURL: string - as obtained from `config.base`\n *\n * @param params - arguments with the meanings explained above.\n * @returns the URL to navigate to or null if we can't be sure that the\n * corresponding page to the current page exists in the selected version\n */\nexport function selectedVersionCorrespondingURL(\n  params: CorrespondingURLParams\n): URL | undefined {\n  const {selectedVersionSitemap,\n    selectedVersionBaseURL,\n    currentLocation,\n    currentBaseURL} = params\n  const current_path = safeURLParse(currentBaseURL)?.pathname\n  if (current_path === undefined) {\n    return\n  }\n  const currentRelativePath = stripPrefix(currentLocation.pathname, current_path)\n  if (currentRelativePath === undefined) {\n    return\n  }\n  const sitemapCommonPrefix = shortestCommonPrefix(selectedVersionSitemap.keys())\n  if (!selectedVersionSitemap.has(sitemapCommonPrefix)) {\n    // We could also check that `commonSitemapPrefix` ends in the canonical version,\n    // similarly to https://github.com/squidfunk/mkdocs-material/pull/7227. However,\n    // I don't believe that Mike/MkDocs ever generate sitemaps where it would matter\n    return\n  }\n\n  const potentialSitemapURL = safeURLParse(currentRelativePath, sitemapCommonPrefix)\n  if (!potentialSitemapURL || !selectedVersionSitemap.has(potentialSitemapURL.href)) {\n    return\n  }\n\n  const result = safeURLParse(currentRelativePath, selectedVersionBaseURL)\n  if (!result) {\n    return\n  }\n  result.hash = currentLocation.hash\n  result.search = currentLocation.search\n  return result\n}\n\n/**\n * A version of `new URL` that never throws. A polyfill for URL.parse() which is\n * not yet ubuquitous.\n *\n * @param url - passed to `new URL` constructor\n * @param base - passed to `new URL` constructor\n *\n * @returns `new URL(url, base)` or undefined if the URL is invalid.\n */\nfunction safeURLParse(url: string|URL, base?: string|URL): URL | undefined {\n  try {\n    return new URL(url, base)\n  } catch {\n    return\n  }\n}\n\n// Basic string manipulation\n\n/** Strip a given prefix from a function\n *\n * @param s - string\n * @param prefix - prefix to strip\n *\n * @returns either the string with the prefix stripped or undefined if the\n * string did not begin with the prefix.\n */\nexport function stripPrefix(s: string, prefix: string): string | undefined {\n  if (s.startsWith(prefix)) {\n    return s.slice(prefix.length)\n  }\n  return undefined\n}\n\n/** Find the length of the longest common prefix of two strings\n *\n * @param s1 - first string\n * @param s2 - second string\n *\n * @returns - the length of the longest common prefix of the two strings.\n */\nfunction commonPrefixLen(s1: string, s2: string): number {\n  const max = Math.min(s1.length, s2.length)\n  let result\n  for (result = 0; result < max; ++result) {\n    if (s1[result] !== s2[result]) {\n      break\n    }\n  }\n  return result\n}\n\n/** Find the longest common prefix of any number of strings\n *\n * @param strs - an iterable of strings\n *\n * @returns the longest common prefix of all the strings\n */\nexport function shortestCommonPrefix(strs: Iterable<string>): string {\n  let result  // Undefined if no iterations happened\n  for (const s of strs) {\n    if (result === undefined) {\n      result = s\n    } else {\n      result = result.slice(0, commonPrefixLen(result, s))\n    }\n  }\n  return result ?? \"\"\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Subject,\n  catchError,\n  combineLatest,\n  filter,\n  fromEvent,\n  map,\n  of,\n  switchMap,\n  withLatestFrom\n} from \"rxjs\"\n\nimport { configuration } from \"~/_\"\nimport {\n  getElement,\n  getLocation,\n  requestJSON,\n  setLocation\n} from \"~/browser\"\nimport { getComponentElements } from \"~/components\"\nimport {\n  Version,\n  renderVersionSelector\n} from \"~/templates\"\n\nimport { fetchSitemap } from \"../sitemap\"\n\nimport { selectedVersionCorrespondingURL } from \"./findurl\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Setup options\n */\ninterface SetupOptions {\n  document$: Subject<Document>         /* Document subject */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Set up version selector\n *\n * @param options - Options\n */\nexport function setupVersionSelector(\n  { document$ }: SetupOptions\n): void {\n  const config = configuration()\n  const versions$ = requestJSON<Version[]>(\n    new URL(\"../versions.json\", config.base)\n  )\n    .pipe(\n      catchError(() => EMPTY) // @todo refactor instant loading\n    )\n\n  /* Determine current version */\n  const current$ = versions$\n    .pipe(\n      map(versions => {\n        const [, current] = config.base.match(/([^/]+)\\/?$/)!\n        return versions.find(({ version, aliases }) => (\n          version === current || aliases.includes(current)\n        )) || versions[0]\n      })\n    )\n\n  /* Intercept inter-version navigation */\n  versions$\n    .pipe(\n      map(versions => new Map(versions.map(version => [\n        `${new URL(`../${version.version}/`, config.base)}`,\n        version\n      ]))),\n      switchMap(urls => fromEvent<MouseEvent>(document.body, \"click\")\n        .pipe(\n          filter(ev => !ev.metaKey && !ev.ctrlKey),\n          withLatestFrom(current$),\n          switchMap(([ev, current]) => {\n            if (ev.target instanceof Element) {\n              const el = ev.target.closest(\"a\")\n              if (el && !el.target && urls.has(el.href)) {\n                const url = el.href\n                // This is a temporary hack to detect if a version inside the\n                // version selector or on another part of the site was clicked.\n                // If we're inside the version selector, we definitely want to\n                // find the same page, as we might have different deployments\n                // due to aliases. However, if we're outside the version\n                // selector, we must abort here, because we might otherwise\n                // interfere with instant navigation. We need to refactor this\n                // at some point together with instant navigation.\n                //\n                // See https://github.com/squidfunk/mkdocs-material/issues/4012\n                if (!ev.target.closest(\".md-version\")) {\n                  const version = urls.get(url)!\n                  if (version === current)\n                    return EMPTY\n                }\n                ev.preventDefault()\n                return of(new URL(url))\n              }\n            }\n            return EMPTY\n          }),\n          switchMap(selectedVersionBaseURL => {\n            return fetchSitemap(selectedVersionBaseURL).pipe(\n              map(\n                sitemap =>\n                  selectedVersionCorrespondingURL({\n                    selectedVersionSitemap: sitemap,\n                    selectedVersionBaseURL,\n                    currentLocation: getLocation(),\n                    currentBaseURL: config.base\n                  }) ?? selectedVersionBaseURL,\n              ),\n            )\n          })\n        )\n      )\n    )\n      .subscribe(url => setLocation(url, true))\n\n  /* Render version selector and warning */\n  combineLatest([versions$, current$])\n    .subscribe(([versions, current]) => {\n      const topic = getElement(\".md-header__topic\")\n      topic.appendChild(renderVersionSelector(versions, current))\n    })\n\n  /* Integrate outdated version banner with instant navigation */\n  document$.pipe(switchMap(() => current$))\n    .subscribe(current => {\n\n      /* Check if version state was already determined */\n      let outdated = __md_get(\"__outdated\", sessionStorage)\n      if (outdated === null) {\n        outdated = true\n\n        /* Obtain and normalize default versions */\n        let ignored = config.version?.default || \"latest\"\n        if (!Array.isArray(ignored))\n          ignored = [ignored]\n\n        /* Check if version is considered a default */\n        main: for (const ignore of ignored)\n          for (const version of current.aliases.concat(current.version))\n            if (new RegExp(ignore, \"i\").test(version)) {\n              outdated = false\n              break main\n            }\n\n        /* Persist version state in session storage */\n        __md_set(\"__outdated\", outdated, sessionStorage)\n      }\n\n      /* Unhide outdated version banner */\n      if (outdated)\n        for (const warning of getComponentElements(\"outdated\"))\n          warning.hidden = false\n    })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  combineLatest,\n  distinctUntilChanged,\n  distinctUntilKeyChanged,\n  endWith,\n  finalize,\n  first,\n  fromEvent,\n  ignoreElements,\n  map,\n  merge,\n  shareReplay,\n  takeUntil,\n  tap\n} from \"rxjs\"\n\nimport {\n  getElement,\n  getLocation,\n  setToggle,\n  watchElementFocus,\n  watchToggle\n} from \"~/browser\"\nimport {\n  SearchMessage,\n  SearchMessageType,\n  isSearchReadyMessage\n} from \"~/integrations\"\n\nimport { Component } from \"../../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Search query\n */\nexport interface SearchQuery {\n  value: string                        /* Query value */\n  focus: boolean                       /* Query focus */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  worker$: Subject<SearchMessage>      /* Search worker */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  worker$: Subject<SearchMessage>      /* Search worker */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch search query\n *\n * Note that the focus event which triggers re-reading the current query value\n * is delayed by `1ms` so the input's empty state is allowed to propagate.\n *\n * @param el - Search query element\n * @param options - Options\n *\n * @returns Search query observable\n */\nexport function watchSearchQuery(\n  el: HTMLInputElement, { worker$ }: WatchOptions\n): Observable<SearchQuery> {\n\n  /* Support search deep linking */\n  const { searchParams } = getLocation()\n  if (searchParams.has(\"q\")) {\n    setToggle(\"search\", true)\n\n    /* Set query from parameter */\n    el.value = searchParams.get(\"q\")!\n    el.focus()\n\n    /* Remove query parameter on close */\n    watchToggle(\"search\")\n      .pipe(\n        first(active => !active)\n      )\n        .subscribe(() => {\n          const url = getLocation()\n          url.searchParams.delete(\"q\")\n          history.replaceState({}, \"\", `${url}`)\n        })\n  }\n\n  /* Intercept focus and input events */\n  const focus$ = watchElementFocus(el)\n  const value$ = merge(\n    worker$.pipe(first(isSearchReadyMessage)),\n    fromEvent(el, \"keyup\"),\n    focus$\n  )\n    .pipe(\n      map(() => el.value),\n      distinctUntilChanged()\n    )\n\n  /* Combine into single observable */\n  return combineLatest([value$, focus$])\n    .pipe(\n      map(([value, focus]) => ({ value, focus })),\n      shareReplay(1)\n    )\n}\n\n/**\n * Mount search query\n *\n * @param el - Search query element\n * @param options - Options\n *\n * @returns Search query component observable\n */\nexport function mountSearchQuery(\n  el: HTMLInputElement, { worker$ }: MountOptions\n): Observable<Component<SearchQuery, HTMLInputElement>> {\n  const push$ = new Subject<SearchQuery>()\n  const done$ = push$.pipe(ignoreElements(), endWith(true))\n\n  /* Handle value change */\n  combineLatest([\n    worker$.pipe(first(isSearchReadyMessage)),\n    push$\n  ], (_, query) => query)\n    .pipe(\n      distinctUntilKeyChanged(\"value\")\n    )\n      .subscribe(({ value }) => worker$.next({\n        type: SearchMessageType.QUERY,\n        data: value\n      }))\n\n  /* Handle focus change */\n  push$\n    .pipe(\n      distinctUntilKeyChanged(\"focus\")\n    )\n      .subscribe(({ focus }) => {\n        if (focus)\n          setToggle(\"search\", focus)\n      })\n\n  /* Handle reset */\n  fromEvent(el.form!, \"reset\")\n    .pipe(\n      takeUntil(done$)\n    )\n      .subscribe(() => el.focus())\n\n  // Focus search query on label click - note that this is necessary to bring\n  // up the keyboard on iOS and other mobile platforms, as the search dialog is\n  // not visible at first, and programatically focusing an input element must\n  // be triggered by a user interaction - see https://t.ly/Cb30n\n  const label = getElement(\"header [for=__search]\")\n  fromEvent(label, \"click\")\n    .subscribe(() => el.focus())\n\n  /* Create and return component */\n  return watchSearchQuery(el, { worker$ })\n    .pipe(\n      tap(state => push$.next(state)),\n      finalize(() => push$.complete()),\n      map(state => ({ ref: el, ...state })),\n      shareReplay(1)\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  Subject,\n  bufferCount,\n  filter,\n  finalize,\n  first,\n  fromEvent,\n  map,\n  merge,\n  mergeMap,\n  of,\n  share,\n  skipUntil,\n  switchMap,\n  takeUntil,\n  tap,\n  withLatestFrom,\n  zipWith\n} from \"rxjs\"\n\nimport { translation } from \"~/_\"\nimport {\n  getElement,\n  getOptionalElement,\n  watchElementBoundary,\n  watchToggle\n} from \"~/browser\"\nimport {\n  SearchMessage,\n  SearchResult,\n  isSearchReadyMessage,\n  isSearchResultMessage\n} from \"~/integrations\"\nimport { renderSearchResultItem } from \"~/templates\"\nimport { round } from \"~/utilities\"\n\nimport { Component } from \"../../_\"\nimport { SearchQuery } from \"../query\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  query$: Observable<SearchQuery>      /* Search query observable */\n  worker$: Subject<SearchMessage>      /* Search worker */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount search result list\n *\n * This function performs a lazy rendering of the search results, depending on\n * the vertical offset of the search result container.\n *\n * @param el - Search result list element\n * @param options - Options\n *\n * @returns Search result list component observable\n */\nexport function mountSearchResult(\n  el: HTMLElement, { worker$, query$ }: MountOptions\n): Observable<Component<SearchResult>> {\n  const push$ = new Subject<SearchResult>()\n  const boundary$ = watchElementBoundary(el.parentElement!)\n    .pipe(\n      filter(Boolean)\n    )\n\n  /* Retrieve container */\n  const container = el.parentElement!\n\n  /* Retrieve nested components */\n  const meta = getElement(\":scope > :first-child\", el)\n  const list = getElement(\":scope > :last-child\", el)\n\n  /* Reveal to accessibility tree \u2013 see https://bit.ly/3iAA7t8 */\n  watchToggle(\"search\")\n    .subscribe(active => list.setAttribute(\n      \"role\", active ? \"list\" : \"presentation\"\n    ))\n\n  /* Update search result metadata */\n  push$\n    .pipe(\n      withLatestFrom(query$),\n      skipUntil(worker$.pipe(first(isSearchReadyMessage)))\n    )\n      .subscribe(([{ items }, { value }]) => {\n        switch (items.length) {\n\n          /* No results */\n          case 0:\n            meta.textContent = value.length\n              ? translation(\"search.result.none\")\n              : translation(\"search.result.placeholder\")\n            break\n\n          /* One result */\n          case 1:\n            meta.textContent = translation(\"search.result.one\")\n            break\n\n          /* Multiple result */\n          default:\n            const count = round(items.length)\n            meta.textContent = translation(\"search.result.other\", count)\n        }\n      })\n\n  /* Render search result item */\n  const render$ = push$\n    .pipe(\n      tap(() => list.innerHTML = \"\"),\n      switchMap(({ items }) => merge(\n        of(...items.slice(0, 10)),\n        of(...items.slice(10))\n          .pipe(\n            bufferCount(4),\n            zipWith(boundary$),\n            switchMap(([chunk]) => chunk)\n          )\n      )),\n      map(renderSearchResultItem),\n      share()\n    )\n\n  /* Update search result list */\n  render$.subscribe(item => list.appendChild(item))\n  render$\n    .pipe(\n      mergeMap(item => {\n        const details = getOptionalElement(\"details\", item)\n        if (typeof details === \"undefined\")\n          return EMPTY\n\n        /* Keep position of details element stable */\n        return fromEvent(details, \"toggle\")\n          .pipe(\n            takeUntil(push$),\n            map(() => details)\n          )\n      })\n    )\n      .subscribe(details => {\n        if (\n          details.open === false &&\n          details.offsetTop <= container.scrollTop\n        )\n          container.scrollTo({ top: details.offsetTop })\n      })\n\n  /* Filter search result message */\n  const result$ = worker$\n    .pipe(\n      filter(isSearchResultMessage),\n      map(({ data }) => data)\n    )\n\n  /* Create and return component */\n  return result$\n    .pipe(\n      tap(state => push$.next(state)),\n      finalize(() => push$.complete()),\n      map(state => ({ ref: el, ...state }))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  endWith,\n  finalize,\n  fromEvent,\n  ignoreElements,\n  map,\n  takeUntil,\n  tap\n} from \"rxjs\"\n\nimport { getLocation } from \"~/browser\"\n\nimport { Component } from \"../../_\"\nimport { SearchQuery } from \"../query\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Search sharing\n */\nexport interface SearchShare {\n  url: URL                             /* Deep link for sharing */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  query$: Observable<SearchQuery>      /* Search query observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  query$: Observable<SearchQuery>      /* Search query observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount search sharing\n *\n * @param _el - Search sharing element\n * @param options - Options\n *\n * @returns Search sharing observable\n */\nexport function watchSearchShare(\n  _el: HTMLElement, { query$ }: WatchOptions\n): Observable<SearchShare> {\n  return query$\n    .pipe(\n      map(({ value }) => {\n        const url = getLocation()\n        url.hash = \"\"\n\n        /* Compute readable query strings */\n        value = value\n          .replace(/\\s+/g, \"+\")        /* Collapse whitespace */\n          .replace(/&/g, \"%26\")        /* Escape '&' character */\n          .replace(/=/g, \"%3D\")        /* Escape '=' character */\n\n        /* Replace query string */\n        url.search = `q=${value}`\n        return { url }\n      })\n    )\n}\n\n/**\n * Mount search sharing\n *\n * @param el - Search sharing element\n * @param options - Options\n *\n * @returns Search sharing component observable\n */\nexport function mountSearchShare(\n  el: HTMLAnchorElement, options: MountOptions\n): Observable<Component<SearchShare>> {\n  const push$ = new Subject<SearchShare>()\n  const done$ = push$.pipe(ignoreElements(), endWith(true))\n  push$.subscribe(({ url }) => {\n    el.setAttribute(\"data-clipboard-text\", el.href)\n    el.href = `${url}`\n  })\n\n  /* Prevent following of link */\n  fromEvent(el, \"click\")\n    .pipe(\n      takeUntil(done$)\n    )\n      .subscribe(ev => ev.preventDefault())\n\n  /* Create and return component */\n  return watchSearchShare(el, options)\n    .pipe(\n      tap(state => push$.next(state)),\n      finalize(() => push$.complete()),\n      map(state => ({ ref: el, ...state }))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  asyncScheduler,\n  combineLatestWith,\n  distinctUntilChanged,\n  filter,\n  finalize,\n  fromEvent,\n  map,\n  merge,\n  observeOn,\n  tap\n} from \"rxjs\"\n\nimport { Keyboard } from \"~/browser\"\nimport {\n  SearchMessage,\n  SearchResult,\n  isSearchResultMessage\n} from \"~/integrations\"\n\nimport { Component, getComponentElement } from \"../../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Search suggestions\n */\nexport interface SearchSuggest {}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  keyboard$: Observable<Keyboard>      /* Keyboard observable */\n  worker$: Subject<SearchMessage>      /* Search worker */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount search suggestions\n *\n * This function will perform a lazy rendering of the search results, depending\n * on the vertical offset of the search result container.\n *\n * @param el - Search result list element\n * @param options - Options\n *\n * @returns Search result list component observable\n */\nexport function mountSearchSuggest(\n  el: HTMLElement, { worker$, keyboard$ }: MountOptions\n): Observable<Component<SearchSuggest>> {\n  const push$ = new Subject<SearchResult>()\n\n  /* Retrieve query component and track all changes */\n  const query  = getComponentElement(\"search-query\")\n  const query$ = merge(\n    fromEvent(query, \"keydown\"),\n    fromEvent(query, \"focus\")\n  )\n    .pipe(\n      observeOn(asyncScheduler),\n      map(() => query.value),\n      distinctUntilChanged(),\n    )\n\n  /* Update search suggestions */\n  push$\n    .pipe(\n      combineLatestWith(query$),\n      map(([{ suggest }, value]) => {\n        const words = value.split(/([\\s-]+)/)\n        if (suggest?.length && words[words.length - 1]) {\n          const last = suggest[suggest.length - 1]\n          if (last.startsWith(words[words.length - 1]))\n            words[words.length - 1] = last\n        } else {\n          words.length = 0\n        }\n        return words\n      })\n    )\n      .subscribe(words => el.innerHTML = words\n        .join(\"\")\n        .replace(/\\s/g, \"&nbsp;\")\n      )\n\n  /* Set up search keyboard handlers */\n  keyboard$\n    .pipe(\n      filter(({ mode }) => mode === \"search\")\n    )\n      .subscribe(key => {\n        switch (key.type) {\n\n          /* Right arrow: accept current suggestion */\n          case \"ArrowRight\":\n            if (\n              el.innerText.length &&\n              query.selectionStart === query.value.length\n            )\n              query.value = el.innerText\n            break\n        }\n      })\n\n  /* Filter search result message */\n  const result$ = worker$\n    .pipe(\n      filter(isSearchResultMessage),\n      map(({ data }) => data)\n    )\n\n  /* Create and return component */\n  return result$\n    .pipe(\n      tap(state => push$.next(state)),\n      finalize(() => push$.complete()),\n      map(() => ({ ref: el }))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  NEVER,\n  Observable,\n  ObservableInput,\n  filter,\n  fromEvent,\n  merge,\n  mergeWith\n} from \"rxjs\"\n\nimport { configuration } from \"~/_\"\nimport {\n  Keyboard,\n  getActiveElement,\n  getElements,\n  setToggle\n} from \"~/browser\"\nimport {\n  SearchIndex,\n  SearchResult,\n  setupSearchWorker\n} from \"~/integrations\"\n\nimport {\n  Component,\n  getComponentElement,\n  getComponentElements\n} from \"../../_\"\nimport {\n  SearchQuery,\n  mountSearchQuery\n} from \"../query\"\nimport { mountSearchResult } from \"../result\"\nimport {\n  SearchShare,\n  mountSearchShare\n} from \"../share\"\nimport {\n  SearchSuggest,\n  mountSearchSuggest\n} from \"../suggest\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Search\n */\nexport type Search =\n  | SearchQuery\n  | SearchResult\n  | SearchShare\n  | SearchSuggest\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  index$: ObservableInput<SearchIndex> /* Search index observable */\n  keyboard$: Observable<Keyboard>      /* Keyboard observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount search\n *\n * This function sets up the search functionality, including the underlying\n * web worker and all keyboard bindings.\n *\n * @param el - Search element\n * @param options - Options\n *\n * @returns Search component observable\n */\nexport function mountSearch(\n  el: HTMLElement, { index$, keyboard$ }: MountOptions\n): Observable<Component<Search>> {\n  const config = configuration()\n  try {\n    const worker$ = setupSearchWorker(config.search, index$)\n\n    /* Retrieve query and result components */\n    const query  = getComponentElement(\"search-query\", el)\n    const result = getComponentElement(\"search-result\", el)\n\n    /* Always close search on result selection */\n    fromEvent<PointerEvent>(el, \"click\")\n      .pipe(\n        filter(({ target }) => (\n          target instanceof Element && !!target.closest(\"a\")\n        ))\n      )\n        .subscribe(() => setToggle(\"search\", false))\n\n    /* Set up search keyboard handlers */\n    keyboard$\n      .pipe(\n        filter(({ mode }) => mode === \"search\")\n      )\n        .subscribe(key => {\n          const active = getActiveElement()\n          switch (key.type) {\n\n            /* Enter: go to first (best) result */\n            case \"Enter\":\n              if (active === query) {\n                const anchors = new Map<HTMLAnchorElement, number>()\n                for (const anchor of getElements<HTMLAnchorElement>(\n                  \":first-child [href]\", result\n                )) {\n                  const article = anchor.firstElementChild!\n                  anchors.set(anchor, parseFloat(\n                    article.getAttribute(\"data-md-score\")!\n                  ))\n                }\n\n                /* Go to result with highest score, if any */\n                if (anchors.size) {\n                  const [[best]] = [...anchors].sort(([, a], [, b]) => b - a)\n                  best.click()\n                }\n\n                /* Otherwise omit form submission */\n                key.claim()\n              }\n              break\n\n            /* Escape or Tab: close search */\n            case \"Escape\":\n            case \"Tab\":\n              setToggle(\"search\", false)\n              query.blur()\n              break\n\n            /* Vertical arrows: select previous or next search result */\n            case \"ArrowUp\":\n            case \"ArrowDown\":\n              if (typeof active === \"undefined\") {\n                query.focus()\n              } else {\n                const els = [query, ...getElements(\n                  \":not(details) > [href], summary, details[open] [href]\",\n                  result\n                )]\n                const i = Math.max(0, (\n                  Math.max(0, els.indexOf(active)) + els.length + (\n                    key.type === \"ArrowUp\" ? -1 : +1\n                  )\n                ) % els.length)\n                els[i].focus()\n              }\n\n              /* Prevent scrolling of page */\n              key.claim()\n              break\n\n            /* All other keys: hand to search query */\n            default:\n              if (query !== getActiveElement())\n                query.focus()\n          }\n        })\n\n    /* Set up global keyboard handlers */\n    keyboard$\n      .pipe(\n        filter(({ mode }) => mode === \"global\")\n      )\n        .subscribe(key => {\n          switch (key.type) {\n\n            /* Open search and select query */\n            case \"f\":\n            case \"s\":\n            case \"/\":\n              query.focus()\n              query.select()\n\n              /* Prevent scrolling of page */\n              key.claim()\n              break\n          }\n        })\n\n    /* Create and return component */\n    const query$ = mountSearchQuery(query, { worker$ })\n    return merge(\n      query$,\n      mountSearchResult(result, { worker$, query$ })\n    )\n      .pipe(\n        mergeWith(\n\n          /* Search sharing */\n          ...getComponentElements(\"search-share\", el)\n            .map(child => mountSearchShare(child, { query$ })),\n\n          /* Search suggestions */\n          ...getComponentElements(\"search-suggest\", el)\n            .map(child => mountSearchSuggest(child, { worker$, keyboard$ }))\n        )\n      )\n\n  /* Gracefully handle broken search */\n  } catch (err) {\n    el.hidden = true\n    return NEVER\n  }\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  ObservableInput,\n  combineLatest,\n  filter,\n  map,\n  startWith\n} from \"rxjs\"\n\nimport { getLocation } from \"~/browser\"\nimport {\n  SearchIndex,\n  setupSearchHighlighter\n} from \"~/integrations\"\nimport { h } from \"~/utilities\"\n\nimport { Component } from \"../../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Search highlighting\n */\nexport interface SearchHighlight {\n  nodes: Map<ChildNode, string>        /* Map of replacements */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  index$: ObservableInput<SearchIndex> /* Search index observable */\n  location$: Observable<URL>           /* Location observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount search highlighting\n *\n * @param el - Content element\n * @param options - Options\n *\n * @returns Search highlighting component observable\n */\nexport function mountSearchHiglight(\n  el: HTMLElement, { index$, location$ }: MountOptions\n): Observable<Component<SearchHighlight>> {\n  return combineLatest([\n    index$,\n    location$\n      .pipe(\n        startWith(getLocation()),\n        filter(url => !!url.searchParams.get(\"h\"))\n      )\n  ])\n    .pipe(\n      map(([index, url]) => setupSearchHighlighter(index.config)(\n        url.searchParams.get(\"h\")!\n      )),\n      map(fn => {\n        const nodes = new Map<ChildNode, string>()\n\n        /* Traverse text nodes and collect matches */\n        const it = document.createNodeIterator(el, NodeFilter.SHOW_TEXT)\n        for (let node = it.nextNode(); node; node = it.nextNode()) {\n          if (node.parentElement?.offsetHeight) {\n            const original = node.textContent!\n            const replaced = fn(original)\n            if (replaced.length > original.length)\n              nodes.set(node as ChildNode, replaced)\n          }\n        }\n\n        /* Replace original nodes with matches */\n        for (const [node, text] of nodes) {\n          const { childNodes } = h(\"span\", null, text)\n          node.replaceWith(...Array.from(childNodes))\n        }\n\n        /* Return component */\n        return { ref: el, nodes }\n      })\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  animationFrameScheduler,\n  asyncScheduler,\n  auditTime,\n  combineLatest,\n  defer,\n  distinctUntilChanged,\n  endWith,\n  finalize,\n  first,\n  from,\n  fromEvent,\n  ignoreElements,\n  map,\n  mergeMap,\n  observeOn,\n  takeUntil,\n  tap,\n  withLatestFrom\n} from \"rxjs\"\n\nimport {\n  Viewport,\n  getElement,\n  getElementOffset,\n  getElementSize,\n  getElements\n} from \"~/browser\"\n\nimport { Component } from \"../_\"\nimport { Header } from \"../header\"\nimport { Main } from \"../main\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Sidebar\n */\nexport interface Sidebar {\n  height: number                       /* Sidebar height */\n  locked: boolean                      /* Sidebar is locked */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  main$: Observable<Main>              /* Main area observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n  main$: Observable<Main>              /* Main area observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch sidebar\n *\n * This function returns an observable that computes the visual parameters of\n * the sidebar which depends on the vertical viewport offset, as well as the\n * height of the main area. When the page is scrolled beyond the header, the\n * sidebar is locked and fills the remaining space.\n *\n * @param el - Sidebar element\n * @param options - Options\n *\n * @returns Sidebar observable\n */\nexport function watchSidebar(\n  el: HTMLElement, { viewport$, main$ }: WatchOptions\n): Observable<Sidebar> {\n  const parent = el.closest<HTMLElement>(\".md-grid\")!\n  const adjust =\n    parent.offsetTop -\n    parent.parentElement!.offsetTop\n\n  /* Compute the sidebar's available height and if it should be locked */\n  return combineLatest([main$, viewport$])\n    .pipe(\n      map(([{ offset, height }, { offset: { y } }]) => {\n        height = height\n          + Math.min(adjust, Math.max(0, y - offset))\n          - adjust\n        return {\n          height,\n          locked: y >= offset + adjust\n        }\n      }),\n      distinctUntilChanged((a, b) => (\n        a.height === b.height &&\n        a.locked === b.locked\n      ))\n    )\n}\n\n/**\n * Mount sidebar\n *\n * This function doesn't set the height of the actual sidebar, but of its first\n * child \u2013 the `.md-sidebar__scrollwrap` element in order to mitigiate jittery\n * sidebars when the footer is scrolled into view. At some point we switched\n * from `absolute` / `fixed` positioning to `sticky` positioning, significantly\n * reducing jitter in some browsers (respectively Firefox and Safari) when\n * scrolling from the top. However, top-aligned sticky positioning means that\n * the sidebar snaps to the bottom when the end of the container is reached.\n * This is what leads to the mentioned jitter, as the sidebar's height may be\n * updated too slowly.\n *\n * This behaviour can be mitigiated by setting the height of the sidebar to `0`\n * while preserving the padding, and the height on its first element.\n *\n * @param el - Sidebar element\n * @param options - Options\n *\n * @returns Sidebar component observable\n */\nexport function mountSidebar(\n  el: HTMLElement, { header$, ...options }: MountOptions\n): Observable<Component<Sidebar>> {\n  const inner = getElement(\".md-sidebar__scrollwrap\", el)\n  const { y } = getElementOffset(inner)\n  return defer(() => {\n    const push$ = new Subject<Sidebar>()\n    const done$ = push$.pipe(ignoreElements(), endWith(true))\n    const next$ = push$\n      .pipe(\n        auditTime(0, animationFrameScheduler)\n      )\n\n    /* Update sidebar height and offset */\n    next$.pipe(withLatestFrom(header$))\n      .subscribe({\n\n        /* Handle emission */\n        next([{ height }, { height: offset }]) {\n          inner.style.height = `${height - 2 * y}px`\n          el.style.top       = `${offset}px`\n        },\n\n        /* Handle complete */\n        complete() {\n          inner.style.height = \"\"\n          el.style.top       = \"\"\n        }\n      })\n\n    /* Bring active item into view on initial load */\n    next$.pipe(first())\n      .subscribe(() => {\n        for (const item of getElements(\".md-nav__link--active[href]\", el)) {\n          if (!item.clientHeight) // skip invisible toc in left sidebar\n            continue\n          const container = item.closest<HTMLElement>(\".md-sidebar__scrollwrap\")!\n          if (typeof container !== \"undefined\") {\n            const offset = item.offsetTop - container.offsetTop\n            const { height } = getElementSize(container)\n            container.scrollTo({\n              top: offset - height / 2\n            })\n          }\n        }\n      })\n\n    /* Handle accessibility for expandable items, see https://bit.ly/3jaod9p */\n    from(getElements<HTMLLabelElement>(\"label[tabindex]\", el))\n      .pipe(\n        mergeMap(label => fromEvent(label, \"click\")\n          .pipe(\n            observeOn(asyncScheduler),\n            map(() => label),\n            takeUntil(done$)\n          )\n        )\n      )\n        .subscribe(label => {\n          const input = getElement<HTMLInputElement>(`[id=\"${label.htmlFor}\"]`)\n          const nav = getElement(`[aria-labelledby=\"${label.id}\"]`)\n          nav.setAttribute(\"aria-expanded\", `${input.checked}`)\n        })\n\n    /* Create and return component */\n    return watchSidebar(el, options)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { Repo, User } from \"github-types\"\nimport {\n  EMPTY,\n  Observable,\n  catchError,\n  defaultIfEmpty,\n  map,\n  zip\n} from \"rxjs\"\n\nimport { requestJSON } from \"~/browser\"\n\nimport { SourceFacts } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * GitHub release (partial)\n */\ninterface Release {\n  tag_name: string                     /* Tag name */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Fetch GitHub repository facts\n *\n * @param user - GitHub user or organization\n * @param repo - GitHub repository\n *\n * @returns Repository facts observable\n */\nexport function fetchSourceFactsFromGitHub(\n  user: string, repo?: string\n): Observable<SourceFacts> {\n  if (typeof repo !== \"undefined\") {\n    const url = `https://api.github.com/repos/${user}/${repo}`\n    return zip(\n\n      /* Fetch version */\n      requestJSON<Release>(`${url}/releases/latest`)\n        .pipe(\n          catchError(() => EMPTY), // @todo refactor instant loading\n          map(release => ({\n            version: release.tag_name\n          })),\n          defaultIfEmpty({})\n        ),\n\n      /* Fetch stars and forks */\n      requestJSON<Repo>(url)\n        .pipe(\n          catchError(() => EMPTY), // @todo refactor instant loading\n          map(info => ({\n            stars: info.stargazers_count,\n            forks: info.forks_count\n          })),\n          defaultIfEmpty({})\n        )\n    )\n      .pipe(\n        map(([release, info]) => ({ ...release, ...info }))\n      )\n\n  /* User or organization */\n  } else {\n    const url = `https://api.github.com/users/${user}`\n    return requestJSON<User>(url)\n      .pipe(\n        map(info => ({\n          repositories: info.public_repos\n        })),\n        defaultIfEmpty({})\n      )\n  }\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { ProjectSchema } from \"gitlab\"\nimport {\n  EMPTY,\n  Observable,\n  catchError,\n  defaultIfEmpty,\n  map,\n  zip\n} from \"rxjs\"\n\nimport { requestJSON } from \"~/browser\"\n\nimport { SourceFacts } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * GitLab release (partial)\n */\ninterface Release { // @todo remove and use the ReleaseSchema type instead after switching from gitlab to @gitbeaker/rest\n  tag_name: string                     /* Tag name */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Fetch GitLab repository facts\n *\n * @param base - GitLab base\n * @param project - GitLab project\n *\n * @returns Repository facts observable\n */\nexport function fetchSourceFactsFromGitLab(\n  base: string, project: string\n): Observable<SourceFacts> {\n  const url = `https://${base}/api/v4/projects/${encodeURIComponent(project)}`\n  return zip(\n\n    /* Fetch version */\n    requestJSON<Release>(`${url}/releases/permalink/latest`)\n      .pipe(\n        catchError(() => EMPTY), // @todo refactor instant loading\n        map(({ tag_name }) => ({\n          version: tag_name\n        })),\n        defaultIfEmpty({})\n      ),\n\n    /* Fetch stars and forks */\n    requestJSON<ProjectSchema>(url)\n      .pipe(\n        catchError(() => EMPTY), // @todo refactor instant loading\n        map(({ star_count, forks_count }) => ({\n          stars: star_count,\n          forks: forks_count\n        })),\n        defaultIfEmpty({})\n      )\n  )\n    .pipe(\n      map(([release, info]) => ({ ...release, ...info }))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { EMPTY, Observable } from \"rxjs\"\n\nimport { fetchSourceFactsFromGitHub } from \"../github\"\nimport { fetchSourceFactsFromGitLab } from \"../gitlab\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Repository facts for repositories\n */\nexport interface RepositoryFacts {\n  stars?: number                       /* Number of stars */\n  forks?: number                       /* Number of forks */\n  version?: string                     /* Latest version */\n}\n\n/**\n * Repository facts for organizations\n */\nexport interface OrganizationFacts {\n  repositories?: number                /* Number of repositories */\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Repository facts\n */\nexport type SourceFacts =\n  | RepositoryFacts\n  | OrganizationFacts\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Fetch repository facts\n *\n * @param url - Repository URL\n *\n * @returns Repository facts observable\n */\nexport function fetchSourceFacts(\n  url: string\n): Observable<SourceFacts> {\n\n  /* Try to match GitHub repository */\n  let match = url.match(/^.+github\\.com\\/([^/]+)\\/?([^/]+)?/i)\n  if (match) {\n    const [, user, repo] = match\n    return fetchSourceFactsFromGitHub(user, repo)\n  }\n\n  /* Try to match GitLab repository */\n  match = url.match(/^.+?([^/]*gitlab[^/]+)\\/(.+?)\\/?$/i)\n  if (match) {\n    const [, base, slug] = match\n    return fetchSourceFactsFromGitLab(base, slug)\n  }\n\n  /* Fallback */\n  return EMPTY\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  Subject,\n  catchError,\n  defer,\n  filter,\n  finalize,\n  map,\n  of,\n  shareReplay,\n  tap\n} from \"rxjs\"\n\nimport { getElement } from \"~/browser\"\nimport { ConsentDefaults } from \"~/components/consent\"\nimport { renderSourceFacts } from \"~/templates\"\n\nimport {\n  Component,\n  getComponentElements\n} from \"../../_\"\nimport {\n  SourceFacts,\n  fetchSourceFacts\n} from \"../facts\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Repository information\n */\nexport interface Source {\n  facts: SourceFacts                   /* Repository facts */\n}\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Repository information observable\n */\nlet fetch$: Observable<Source>\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch repository information\n *\n * This function tries to read the repository facts from session storage, and\n * if unsuccessful, fetches them from the underlying provider.\n *\n * @param el - Repository information element\n *\n * @returns Repository information observable\n */\nexport function watchSource(\n  el: HTMLAnchorElement\n): Observable<Source> {\n  return fetch$ ||= defer(() => {\n    const cached = __md_get<SourceFacts>(\"__source\", sessionStorage)\n    if (cached) {\n      return of(cached)\n    } else {\n\n      /* Check if consent is configured and was given */\n      const els = getComponentElements(\"consent\")\n      if (els.length) {\n        const consent = __md_get<ConsentDefaults>(\"__consent\")\n        if (!(consent && consent.github))\n          return EMPTY\n      }\n\n      /* Fetch repository facts */\n      return fetchSourceFacts(el.href)\n        .pipe(\n          tap(facts => __md_set(\"__source\", facts, sessionStorage))\n        )\n    }\n  })\n    .pipe(\n      catchError(() => EMPTY),\n      filter(facts => Object.keys(facts).length > 0),\n      map(facts => ({ facts })),\n      shareReplay(1)\n    )\n}\n\n/**\n * Mount repository information\n *\n * @param el - Repository information element\n *\n * @returns Repository information component observable\n */\nexport function mountSource(\n  el: HTMLAnchorElement\n): Observable<Component<Source>> {\n  const inner = getElement(\":scope > :last-child\", el)\n  return defer(() => {\n    const push$ = new Subject<Source>()\n    push$.subscribe(({ facts }) => {\n      inner.appendChild(renderSourceFacts(facts))\n      inner.classList.add(\"md-source__repository--active\")\n    })\n\n    /* Create and return component */\n    return watchSource(el)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  defer,\n  distinctUntilKeyChanged,\n  finalize,\n  map,\n  of,\n  switchMap,\n  tap\n} from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport {\n  Viewport,\n  watchElementSize,\n  watchViewportAt\n} from \"~/browser\"\n\nimport { Component } from \"../_\"\nimport { Header } from \"../header\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Navigation tabs\n */\nexport interface Tabs {\n  hidden: boolean                      /* Navigation tabs are hidden */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch navigation tabs\n *\n * @param el - Navigation tabs element\n * @param options - Options\n *\n * @returns Navigation tabs observable\n */\nexport function watchTabs(\n  el: HTMLElement, { viewport$, header$ }: WatchOptions\n): Observable<Tabs> {\n  return watchElementSize(document.body)\n    .pipe(\n      switchMap(() => watchViewportAt(el, { header$, viewport$ })),\n      map(({ offset: { y } }) => {\n        return {\n          hidden: y >= 10\n        }\n      }),\n      distinctUntilKeyChanged(\"hidden\")\n    )\n}\n\n/**\n * Mount navigation tabs\n *\n * This function hides the navigation tabs when scrolling past the threshold\n * and makes them reappear in a nice CSS animation when scrolling back up.\n *\n * @param el - Navigation tabs element\n * @param options - Options\n *\n * @returns Navigation tabs component observable\n */\nexport function mountTabs(\n  el: HTMLElement, options: MountOptions\n): Observable<Component<Tabs>> {\n  return defer(() => {\n    const push$ = new Subject<Tabs>()\n    push$.subscribe({\n\n      /* Handle emission */\n      next({ hidden }) {\n        el.hidden = hidden\n      },\n\n      /* Handle complete */\n      complete() {\n        el.hidden = false\n      }\n    })\n\n    /* Create and return component */\n    return (\n      feature(\"navigation.tabs.sticky\")\n        ? of({ hidden: false })\n        : watchTabs(el, options)\n    )\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  asyncScheduler,\n  bufferCount,\n  combineLatestWith,\n  debounceTime,\n  defer,\n  distinctUntilChanged,\n  distinctUntilKeyChanged,\n  endWith,\n  filter,\n  finalize,\n  ignoreElements,\n  map,\n  merge,\n  observeOn,\n  of,\n  repeat,\n  scan,\n  share,\n  skip,\n  startWith,\n  switchMap,\n  takeUntil,\n  tap,\n  withLatestFrom\n} from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport {\n  Viewport,\n  getElement,\n  getElementContainer,\n  getElementSize,\n  getElements,\n  getLocation,\n  getOptionalElement,\n  watchElementSize\n} from \"~/browser\"\n\nimport {\n  Component,\n  getComponentElement\n} from \"../_\"\nimport { Header } from \"../header\"\nimport { Main } from \"../main\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Table of contents\n */\nexport interface TableOfContents {\n  prev: HTMLAnchorElement[][]          /* Anchors (previous) */\n  next: HTMLAnchorElement[][]          /* Anchors (next) */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n  main$: Observable<Main>              /* Main area observable */\n  target$: Observable<HTMLElement>     /* Location target observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch table of contents\n *\n * This is effectively a scroll spy implementation which will account for the\n * fixed header and automatically re-calculate anchor offsets when the viewport\n * is resized. The returned observable will only emit if the table of contents\n * needs to be repainted.\n *\n * This implementation tracks an anchor element's entire path starting from its\n * level up to the top-most anchor element, e.g. `[h3, h2, h1]`. Although the\n * Material theme currently doesn't make use of this information, it enables\n * the styling of the entire hierarchy through customization.\n *\n * Note that the current anchor is the last item of the `prev` anchor list.\n *\n * @param el - Table of contents element\n * @param options - Options\n *\n * @returns Table of contents observable\n */\nexport function watchTableOfContents(\n  el: HTMLElement, { viewport$, header$ }: WatchOptions\n): Observable<TableOfContents> {\n  const table = new Map<HTMLAnchorElement, HTMLElement>()\n\n  /* Compute anchor-to-target mapping */\n  const anchors = getElements<HTMLAnchorElement>(\".md-nav__link\", el)\n  for (const anchor of anchors) {\n    const id = decodeURIComponent(anchor.hash.substring(1))\n    const target = getOptionalElement(`[id=\"${id}\"]`)\n    if (typeof target !== \"undefined\")\n      table.set(anchor, target)\n  }\n\n  /* Compute necessary adjustment for header */\n  const adjust$ = header$\n    .pipe(\n      distinctUntilKeyChanged(\"height\"),\n      map(({ height }) => {\n        const main = getComponentElement(\"main\")\n        const grid = getElement(\":scope > :first-child\", main)\n        return height + 0.8 * (\n          grid.offsetTop -\n          main.offsetTop\n        )\n      }),\n      share()\n    )\n\n  /* Compute partition of previous and next anchors */\n  const partition$ = watchElementSize(document.body)\n    .pipe(\n      distinctUntilKeyChanged(\"height\"),\n\n      /* Build index to map anchor paths to vertical offsets */\n      switchMap(body => defer(() => {\n        let path: HTMLAnchorElement[] = []\n        return of([...table].reduce((index, [anchor, target]) => {\n          while (path.length) {\n            const last = table.get(path[path.length - 1])!\n            if (last.tagName >= target.tagName) {\n              path.pop()\n            } else {\n              break\n            }\n          }\n\n          /* If the current anchor is hidden, continue with its parent */\n          let offset = target.offsetTop\n          while (!offset && target.parentElement) {\n            target = target.parentElement\n            offset = target.offsetTop\n          }\n\n          /* Fix anchor offsets in tables - see https://bit.ly/3CUFOcn */\n          let parent = target.offsetParent as HTMLElement\n          for (; parent; parent = parent.offsetParent as HTMLElement)\n            offset += parent.offsetTop\n\n          /* Map reversed anchor path to vertical offset */\n          return index.set(\n            [...path = [...path, anchor]].reverse(),\n            offset\n          )\n        }, new Map<HTMLAnchorElement[], number>()))\n      })\n        .pipe(\n\n          /* Sort index by vertical offset (see https://bit.ly/30z6QSO) */\n          map(index => new Map([...index].sort(([, a], [, b]) => a - b))),\n          combineLatestWith(adjust$),\n\n          /* Re-compute partition when viewport offset changes */\n          switchMap(([index, adjust]) => viewport$\n            .pipe(\n              scan(([prev, next], { offset: { y }, size }) => {\n                const last = y + size.height >= Math.floor(body.height)\n\n                /* Look forward */\n                while (next.length) {\n                  const [, offset] = next[0]\n                  if (offset - adjust < y || last) {\n                    prev = [...prev, next.shift()!]\n                  } else {\n                    break\n                  }\n                }\n\n                /* Look backward */\n                while (prev.length) {\n                  const [, offset] = prev[prev.length - 1]\n                  if (offset - adjust >= y && !last) {\n                    next = [prev.pop()!, ...next]\n                  } else {\n                    break\n                  }\n                }\n\n                /* Return partition */\n                return [prev, next]\n              }, [[], [...index]]),\n              distinctUntilChanged((a, b) => (\n                a[0] === b[0] &&\n                a[1] === b[1]\n              ))\n            )\n          )\n        )\n      )\n    )\n\n  /* Compute and return anchor list migrations */\n  return partition$\n    .pipe(\n      map(([prev, next]) => ({\n        prev: prev.map(([path]) => path),\n        next: next.map(([path]) => path)\n      })),\n\n      /* Extract anchor list migrations */\n      startWith({ prev: [], next: [] }),\n      bufferCount(2, 1),\n      map(([a, b]) => {\n\n        /* Moving down */\n        if (a.prev.length < b.prev.length) {\n          return {\n            prev: b.prev.slice(Math.max(0, a.prev.length - 1), b.prev.length),\n            next: []\n          }\n\n        /* Moving up */\n        } else {\n          return {\n            prev: b.prev.slice(-1),\n            next: b.next.slice(0, b.next.length - a.next.length)\n          }\n        }\n      })\n    )\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Mount table of contents\n *\n * @param el - Table of contents element\n * @param options - Options\n *\n * @returns Table of contents component observable\n */\nexport function mountTableOfContents(\n  el: HTMLElement, { viewport$, header$, main$, target$ }: MountOptions\n): Observable<Component<TableOfContents>> {\n  return defer(() => {\n    const push$ = new Subject<TableOfContents>()\n    const done$ = push$.pipe(ignoreElements(), endWith(true))\n    push$.subscribe(({ prev, next }) => {\n\n      /* Look forward */\n      for (const [anchor] of next) {\n        anchor.classList.remove(\"md-nav__link--passed\")\n        anchor.classList.remove(\"md-nav__link--active\")\n      }\n\n      /* Look backward */\n      for (const [index, [anchor]] of prev.entries()) {\n        anchor.classList.add(\"md-nav__link--passed\")\n        anchor.classList.toggle(\n          \"md-nav__link--active\",\n          index === prev.length - 1\n        )\n      }\n    })\n\n    /* Set up following, if enabled */\n    if (feature(\"toc.follow\")) {\n\n      /* Toggle smooth scrolling only for anchor clicks */\n      const smooth$ = merge(\n        viewport$.pipe(debounceTime(1), map(() => undefined)),\n        viewport$.pipe(debounceTime(250), map(() => \"smooth\" as const))\n      )\n\n      /* Bring active anchor into view */ // @todo: refactor\n      push$\n        .pipe(\n          filter(({ prev }) => prev.length > 0),\n          combineLatestWith(main$.pipe(observeOn(asyncScheduler))),\n          withLatestFrom(smooth$)\n        )\n          .subscribe(([[{ prev }], behavior]) => {\n            const [anchor] = prev[prev.length - 1]\n            if (anchor.offsetHeight) {\n\n              /* Retrieve overflowing container and scroll */\n              const container = getElementContainer(anchor)\n              if (typeof container !== \"undefined\") {\n                const offset = anchor.offsetTop - container.offsetTop\n                const { height } = getElementSize(container)\n                container.scrollTo({\n                  top: offset - height / 2,\n                  behavior\n                })\n              }\n            }\n          })\n    }\n\n    /* Set up anchor tracking, if enabled */\n    if (feature(\"navigation.tracking\"))\n      viewport$\n        .pipe(\n          takeUntil(done$),\n          distinctUntilKeyChanged(\"offset\"),\n          debounceTime(250),\n          skip(1),\n          takeUntil(target$.pipe(skip(1))),\n          repeat({ delay: 250 }),\n          withLatestFrom(push$)\n        )\n          .subscribe(([, { prev }]) => {\n            const url = getLocation()\n\n            /* Set hash fragment to active anchor */\n            const anchor = prev[prev.length - 1]\n            if (anchor && anchor.length) {\n              const [active] = anchor\n              const { hash } = new URL(active.href)\n              if (url.hash !== hash) {\n                url.hash = hash\n                history.replaceState({}, \"\", `${url}`)\n              }\n\n            /* Reset anchor when at the top */\n            } else {\n              url.hash = \"\"\n              history.replaceState({}, \"\", `${url}`)\n            }\n          })\n\n    /* Create and return component */\n    return watchTableOfContents(el, { viewport$, header$ })\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  bufferCount,\n  combineLatest,\n  distinctUntilChanged,\n  distinctUntilKeyChanged,\n  endWith,\n  finalize,\n  fromEvent,\n  ignoreElements,\n  map,\n  repeat,\n  skip,\n  takeUntil,\n  tap\n} from \"rxjs\"\n\nimport { Viewport } from \"~/browser\"\n\nimport { Component } from \"../_\"\nimport { Header } from \"../header\"\nimport { Main } from \"../main\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Back-to-top button\n */\nexport interface BackToTop {\n  hidden: boolean                      /* Back-to-top button is hidden */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  main$: Observable<Main>              /* Main area observable */\n  target$: Observable<HTMLElement>     /* Location target observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n  main$: Observable<Main>              /* Main area observable */\n  target$: Observable<HTMLElement>     /* Location target observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch back-to-top\n *\n * @param _el - Back-to-top element\n * @param options - Options\n *\n * @returns Back-to-top observable\n */\nexport function watchBackToTop(\n  _el: HTMLElement, { viewport$, main$, target$ }: WatchOptions\n): Observable<BackToTop> {\n\n  /* Compute direction */\n  const direction$ = viewport$\n    .pipe(\n      map(({ offset: { y } }) => y),\n      bufferCount(2, 1),\n      map(([a, b]) => a > b && b > 0),\n      distinctUntilChanged()\n    )\n\n  /* Compute whether main area is active */\n  const active$ = main$\n    .pipe(\n      map(({ active }) => active)\n    )\n\n  /* Compute threshold for hiding */\n  return combineLatest([active$, direction$])\n    .pipe(\n      map(([active, direction]) => !(active && direction)),\n      distinctUntilChanged(),\n      takeUntil(target$.pipe(skip(1))),\n      endWith(true),\n      repeat({ delay: 250 }),\n      map(hidden => ({ hidden }))\n    )\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Mount back-to-top\n *\n * @param el - Back-to-top element\n * @param options - Options\n *\n * @returns Back-to-top component observable\n */\nexport function mountBackToTop(\n  el: HTMLElement, { viewport$, header$, main$, target$ }: MountOptions\n): Observable<Component<BackToTop>> {\n  const push$ = new Subject<BackToTop>()\n  const done$ = push$.pipe(ignoreElements(), endWith(true))\n  push$.subscribe({\n\n    /* Handle emission */\n    next({ hidden }) {\n      el.hidden = hidden\n      if (hidden) {\n        el.setAttribute(\"tabindex\", \"-1\")\n        el.blur()\n      } else {\n        el.removeAttribute(\"tabindex\")\n      }\n    },\n\n    /* Handle complete */\n    complete() {\n      el.style.top = \"\"\n      el.hidden = true\n      el.removeAttribute(\"tabindex\")\n    }\n  })\n\n  /* Watch header height */\n  header$\n    .pipe(\n      takeUntil(done$),\n      distinctUntilKeyChanged(\"height\")\n    )\n      .subscribe(({ height }) => {\n        el.style.top = `${height + 16}px`\n      })\n\n  /* Go back to top */\n  fromEvent(el, \"click\")\n    .subscribe(ev => {\n      ev.preventDefault()\n      window.scrollTo({ top: 0 })\n    })\n\n  /* Create and return component */\n  return watchBackToTop(el, { viewport$, main$, target$ })\n    .pipe(\n      tap(state => push$.next(state)),\n      finalize(() => push$.complete()),\n      map(state => ({ ref: el, ...state }))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  filter,\n  finalize,\n  map,\n  mergeMap,\n  skip,\n  switchMap,\n  take,\n  takeUntil\n} from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport {\n  Viewport,\n  getElements,\n  watchElementVisibility\n} from \"~/browser\"\nimport { mountInlineTooltip2 } from \"~/components/tooltip2\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Patch options\n */\ninterface PatchOptions {\n  document$: Observable<Document>      /* Document observable */\n  viewport$: Observable<Viewport>      /* Viewport observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Patch ellipsis\n *\n * This function will fetch all elements that are shortened with ellipsis, and\n * filter those which are visible. Once they become visible, they stay in that\n * state, even though they may be hidden again. This optimization is necessary\n * to reduce pressure on the browser, with elements fading in and out of view.\n *\n * @param options - Options\n */\nexport function patchEllipsis(\n  { document$, viewport$ }: PatchOptions\n): void {\n  document$\n    .pipe(\n      switchMap(() => getElements(\".md-ellipsis\")),\n      mergeMap(el => watchElementVisibility(el)\n        .pipe(\n          takeUntil(document$.pipe(skip(1))),\n          filter(visible => visible),\n          map(() => el),\n          take(1)\n        )\n      ),\n      filter(el => el.offsetWidth < el.scrollWidth),\n      mergeMap(el => {\n        const text = el.innerText\n        const host = el.closest(\"a\") || el\n        host.title = text\n\n        // Do not mount improved tooltip if feature is disabled\n        if (!feature(\"content.tooltips\"))\n          return EMPTY\n\n        /* Mount tooltip */\n        return mountInlineTooltip2(host, { viewport$ })\n          .pipe(\n            takeUntil(document$.pipe(skip(1))),\n            finalize(() => host.removeAttribute(\"title\"))\n          )\n      })\n    )\n      .subscribe()\n\n  // @todo move this outside of here and fix memleaks\n  if (feature(\"content.tooltips\"))\n    document$\n      .pipe(\n        switchMap(() => getElements(\".md-status\")),\n        mergeMap(el => mountInlineTooltip2(el, { viewport$ }))\n      )\n        .subscribe()\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  fromEvent,\n  map,\n  mergeMap,\n  switchMap,\n  takeWhile,\n  tap,\n  withLatestFrom\n} from \"rxjs\"\n\nimport { getElements } from \"~/browser\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Patch options\n */\ninterface PatchOptions {\n  document$: Observable<Document>      /* Document observable */\n  tablet$: Observable<boolean>         /* Media tablet observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Patch indeterminate checkboxes\n *\n * This function replaces the indeterminate \"pseudo state\" with the actual\n * indeterminate state, which is used to keep navigation always expanded.\n *\n * @param options - Options\n */\nexport function patchIndeterminate(\n  { document$, tablet$ }: PatchOptions\n): void {\n  document$\n    .pipe(\n      switchMap(() => getElements<HTMLInputElement>(\n        \".md-toggle--indeterminate\"\n      )),\n      tap(el => {\n        el.indeterminate = true\n        el.checked = false\n      }),\n      mergeMap(el => fromEvent(el, \"change\")\n        .pipe(\n          takeWhile(() => el.classList.contains(\"md-toggle--indeterminate\")),\n          map(() => el)\n        )\n      ),\n      withLatestFrom(tablet$)\n    )\n      .subscribe(([el, tablet]) => {\n        el.classList.remove(\"md-toggle--indeterminate\")\n        if (tablet)\n          el.checked = false\n      })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  filter,\n  fromEvent,\n  map,\n  mergeMap,\n  switchMap,\n  tap\n} from \"rxjs\"\n\nimport { getElements } from \"~/browser\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Patch options\n */\ninterface PatchOptions {\n  document$: Observable<Document>      /* Document observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Check whether the given device is an Apple device\n *\n * @returns Test result\n */\nfunction isAppleDevice(): boolean {\n  return /(iPad|iPhone|iPod)/.test(navigator.userAgent)\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Patch all elements with `data-md-scrollfix` attributes\n *\n * This is a year-old patch which ensures that overflow scrolling works at the\n * top and bottom of containers on iOS by ensuring a `1px` scroll offset upon\n * the start of a touch event.\n *\n * @see https://bit.ly/2SCtAOO - Original source\n *\n * @param options - Options\n */\nexport function patchScrollfix(\n  { document$ }: PatchOptions\n): void {\n  document$\n    .pipe(\n      switchMap(() => getElements(\"[data-md-scrollfix]\")),\n      tap(el => el.removeAttribute(\"data-md-scrollfix\")),\n      filter(isAppleDevice),\n      mergeMap(el => fromEvent(el, \"touchstart\")\n        .pipe(\n          map(() => el)\n        )\n      )\n    )\n      .subscribe(el => {\n        const top = el.scrollTop\n\n        /* We're at the top of the container */\n        if (top === 0) {\n          el.scrollTop = 1\n\n        /* We're at the bottom of the container */\n        } else if (top + el.offsetHeight === el.scrollHeight) {\n          el.scrollTop = top - 1\n        }\n      })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  combineLatest,\n  delay,\n  map,\n  of,\n  switchMap,\n  withLatestFrom\n} from \"rxjs\"\n\nimport {\n  Viewport,\n  watchToggle\n} from \"~/browser\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Patch options\n */\ninterface PatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  tablet$: Observable<boolean>         /* Media tablet observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Patch the document body to lock when search is open\n *\n * For mobile and tablet viewports, the search is rendered full screen, which\n * leads to scroll leaking when at the top or bottom of the search result. This\n * function locks the body when the search is in full screen mode, and restores\n * the scroll position when leaving.\n *\n * @param options - Options\n */\nexport function patchScrolllock(\n  { viewport$, tablet$ }: PatchOptions\n): void {\n  combineLatest([watchToggle(\"search\"), tablet$])\n    .pipe(\n      map(([active, tablet]) => active && !tablet),\n      switchMap(active => of(active)\n        .pipe(\n          delay(active ? 400 : 100)\n        )\n      ),\n      withLatestFrom(viewport$)\n    )\n      .subscribe(([active, { offset: { y }}]) => {\n        if (active) {\n          document.body.setAttribute(\"data-md-scrolllock\", \"\")\n          document.body.style.top = `-${y}px`\n        } else {\n          const value = -1 * parseInt(document.body.style.top, 10)\n          document.body.removeAttribute(\"data-md-scrolllock\")\n          document.body.style.top = \"\"\n          if (value)\n            window.scrollTo(0, value)\n        }\n      })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\n/* ----------------------------------------------------------------------------\n * Polyfills\n * ------------------------------------------------------------------------- */\n\n/* Polyfill `Object.entries` */\nif (!Object.entries)\n  Object.entries = function (obj: object) {\n    const data: [string, string][] = []\n    for (const key of Object.keys(obj))\n      // @ts-expect-error - ignore property access warning\n      data.push([key, obj[key]])\n\n    /* Return entries */\n    return data\n  }\n\n/* Polyfill `Object.values` */\nif (!Object.values)\n  Object.values = function (obj: object) {\n    const data: string[] = []\n    for (const key of Object.keys(obj))\n      // @ts-expect-error - ignore property access warning\n      data.push(obj[key])\n\n    /* Return values */\n    return data\n  }\n\n/* ------------------------------------------------------------------------- */\n\n/* Polyfills for `Element` */\nif (typeof Element !== \"undefined\") {\n\n  /* Polyfill `Element.scrollTo` */\n  if (!Element.prototype.scrollTo)\n    Element.prototype.scrollTo = function (\n      x?: ScrollToOptions | number, y?: number\n    ): void {\n      if (typeof x === \"object\") {\n        this.scrollLeft = x.left!\n        this.scrollTop = x.top!\n      } else {\n        this.scrollLeft = x!\n        this.scrollTop = y!\n      }\n    }\n\n  /* Polyfill `Element.replaceWith` */\n  if (!Element.prototype.replaceWith)\n    Element.prototype.replaceWith = function (\n      ...nodes: Array<string | Node>\n    ): void {\n      const parent = this.parentNode\n      if (parent) {\n        if (nodes.length === 0)\n          parent.removeChild(this)\n\n        /* Replace children and create text nodes */\n        for (let i = nodes.length - 1; i >= 0; i--) {\n          let node = nodes[i]\n          if (typeof node === \"string\")\n            node = document.createTextNode(node)\n          else if (node.parentNode)\n            node.parentNode.removeChild(node)\n\n          /* Replace child or insert before previous sibling */\n          if (!i)\n            parent.replaceChild(node, this)\n          else\n            parent.insertBefore(this.previousSibling!, node)\n        }\n      }\n    }\n}\n"],
-  "mappings": "2rCAAA,IAAAA,GAAAC,GAAA,CAAAC,GAAAC,KAAA,EAAC,SAAUC,EAAQC,EAAS,CAC1B,OAAOH,IAAY,UAAY,OAAOC,IAAW,YAAcE,EAAQ,EACvE,OAAO,QAAW,YAAc,OAAO,IAAM,OAAOA,CAAO,EAC1DA,EAAQ,CACX,GAAEH,GAAO,UAAY,CAAE,aASrB,SAASI,EAA0BC,EAAO,CACxC,IAAIC,EAAmB,GACnBC,EAA0B,GAC1BC,EAAiC,KAEjCC,EAAsB,CACxB,KAAM,GACN,OAAQ,GACR,IAAK,GACL,IAAK,GACL,MAAO,GACP,SAAU,GACV,OAAQ,GACR,KAAM,GACN,MAAO,GACP,KAAM,GACN,KAAM,GACN,SAAU,GACV,iBAAkB,EACpB,EAOA,SAASC,EAAmBC,EAAI,CAC9B,MACE,GAAAA,GACAA,IAAO,UACPA,EAAG,WAAa,QAChBA,EAAG,WAAa,QAChB,cAAeA,GACf,aAAcA,EAAG,UAKrB,CASA,SAASC,EAA8BD,EAAI,CACzC,IAAIE,GAAOF,EAAG,KACVG,GAAUH,EAAG,QAUjB,MARI,GAAAG,KAAY,SAAWL,EAAoBI,EAAI,GAAK,CAACF,EAAG,UAIxDG,KAAY,YAAc,CAACH,EAAG,UAI9BA,EAAG,kBAKT,CAOA,SAASI,EAAqBJ,EAAI,CAC5BA,EAAG,UAAU,SAAS,eAAe,IAGzCA,EAAG,UAAU,IAAI,eAAe,EAChCA,EAAG,aAAa,2BAA4B,EAAE,EAChD,CAOA,SAASK,EAAwBL,EAAI,CAC9BA,EAAG,aAAa,0BAA0B,IAG/CA,EAAG,UAAU,OAAO,eAAe,EACnCA,EAAG,gBAAgB,0BAA0B,EAC/C,CAUA,SAASM,EAAUC,EAAG,CAChBA,EAAE,SAAWA,EAAE,QAAUA,EAAE,UAI3BR,EAAmBL,EAAM,aAAa,GACxCU,EAAqBV,EAAM,aAAa,EAG1CC,EAAmB,GACrB,CAUA,SAASa,EAAcD,EAAG,CACxBZ,EAAmB,EACrB,CASA,SAASc,EAAQF,EAAG,CAEbR,EAAmBQ,EAAE,MAAM,IAI5BZ,GAAoBM,EAA8BM,EAAE,MAAM,IAC5DH,EAAqBG,EAAE,MAAM,CAEjC,CAMA,SAASG,EAAOH,EAAG,CACZR,EAAmBQ,EAAE,MAAM,IAK9BA,EAAE,OAAO,UAAU,SAAS,eAAe,GAC3CA,EAAE,OAAO,aAAa,0BAA0B,KAMhDX,EAA0B,GAC1B,OAAO,aAAaC,CAA8B,EAClDA,EAAiC,OAAO,WAAW,UAAW,CAC5DD,EAA0B,EAC5B,EAAG,GAAG,EACNS,EAAwBE,EAAE,MAAM,EAEpC,CAOA,SAASI,EAAmBJ,EAAG,CACzB,SAAS,kBAAoB,WAK3BX,IACFD,EAAmB,IAErBiB,EAA+B,EAEnC,CAQA,SAASA,GAAiC,CACxC,SAAS,iBAAiB,YAAaC,CAAoB,EAC3D,SAAS,iBAAiB,YAAaA,CAAoB,EAC3D,SAAS,iBAAiB,UAAWA,CAAoB,EACzD,SAAS,iBAAiB,cAAeA,CAAoB,EAC7D,SAAS,iBAAiB,cAAeA,CAAoB,EAC7D,SAAS,iBAAiB,YAAaA,CAAoB,EAC3D,SAAS,iBAAiB,YAAaA,CAAoB,EAC3D,SAAS,iBAAiB,aAAcA,CAAoB,EAC5D,SAAS,iBAAiB,WAAYA,CAAoB,CAC5D,CAEA,SAASC,IAAoC,CAC3C,SAAS,oBAAoB,YAAaD,CAAoB,EAC9D,SAAS,oBAAoB,YAAaA,CAAoB,EAC9D,SAAS,oBAAoB,UAAWA,CAAoB,EAC5D,SAAS,oBAAoB,cAAeA,CAAoB,EAChE,SAAS,oBAAoB,cAAeA,CAAoB,EAChE,SAAS,oBAAoB,YAAaA,CAAoB,EAC9D,SAAS,oBAAoB,YAAaA,CAAoB,EAC9D,SAAS,oBAAoB,aAAcA,CAAoB,EAC/D,SAAS,oBAAoB,WAAYA,CAAoB,CAC/D,CASA,SAASA,EAAqBN,EAAG,CAG3BA,EAAE,OAAO,UAAYA,EAAE,OAAO,SAAS,YAAY,IAAM,SAI7DZ,EAAmB,GACnBmB,GAAkC,EACpC,CAKA,SAAS,iBAAiB,UAAWR,EAAW,EAAI,EACpD,SAAS,iBAAiB,YAAaE,EAAe,EAAI,EAC1D,SAAS,iBAAiB,cAAeA,EAAe,EAAI,EAC5D,SAAS,iBAAiB,aAAcA,EAAe,EAAI,EAC3D,SAAS,iBAAiB,mBAAoBG,EAAoB,EAAI,EAEtEC,EAA+B,EAM/BlB,EAAM,iBAAiB,QAASe,EAAS,EAAI,EAC7Cf,EAAM,iBAAiB,OAAQgB,EAAQ,EAAI,EAOvChB,EAAM,WAAa,KAAK,wBAA0BA,EAAM,KAI1DA,EAAM,KAAK,aAAa,wBAAyB,EAAE,EAC1CA,EAAM,WAAa,KAAK,gBACjC,SAAS,gBAAgB,UAAU,IAAI,kBAAkB,EACzD,SAAS,gBAAgB,aAAa,wBAAyB,EAAE,EAErE,CAKA,GAAI,OAAO,QAAW,aAAe,OAAO,UAAa,YAAa,CAIpE,OAAO,0BAA4BD,EAInC,IAAIsB,EAEJ,GAAI,CACFA,EAAQ,IAAI,YAAY,8BAA8B,CACxD,OAASC,EAAO,CAEdD,EAAQ,SAAS,YAAY,aAAa,EAC1CA,EAAM,gBAAgB,+BAAgC,GAAO,GAAO,CAAC,CAAC,CACxE,CAEA,OAAO,cAAcA,CAAK,CAC5B,CAEI,OAAO,UAAa,aAGtBtB,EAA0B,QAAQ,CAGtC,CAAE,ICvTF,IAAAwB,GAAAC,GAAA,CAAAC,GAAAC,KAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,GAeA,IAAIC,GAAkB,UAOtBD,GAAO,QAAUE,GAUjB,SAASA,GAAWC,EAAQ,CAC1B,IAAIC,EAAM,GAAKD,EACXE,EAAQJ,GAAgB,KAAKG,CAAG,EAEpC,GAAI,CAACC,EACH,OAAOD,EAGT,IAAIE,EACAC,EAAO,GACPC,EAAQ,EACRC,EAAY,EAEhB,IAAKD,EAAQH,EAAM,MAAOG,EAAQJ,EAAI,OAAQI,IAAS,CACrD,OAAQJ,EAAI,WAAWI,CAAK,EAAG,CAC7B,IAAK,IACHF,EAAS,SACT,MACF,IAAK,IACHA,EAAS,QACT,MACF,IAAK,IACHA,EAAS,QACT,MACF,IAAK,IACHA,EAAS,OACT,MACF,IAAK,IACHA,EAAS,OACT,MACF,QACE,QACJ,CAEIG,IAAcD,IAChBD,GAAQH,EAAI,UAAUK,EAAWD,CAAK,GAGxCC,EAAYD,EAAQ,EACpBD,GAAQD,CACV,CAEA,OAAOG,IAAcD,EACjBD,EAAOH,EAAI,UAAUK,EAAWD,CAAK,EACrCD,CACN,IC7EA,IAAAG,GAAAC,GAAA,CAAAC,GAAAC,KAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAMC,SAA0CC,EAAMC,EAAS,CACtD,OAAOH,IAAY,UAAY,OAAOC,IAAW,SACnDA,GAAO,QAAUE,EAAQ,EAClB,OAAO,QAAW,YAAc,OAAO,IAC9C,OAAO,CAAC,EAAGA,CAAO,EACX,OAAOH,IAAY,SAC1BA,GAAQ,YAAiBG,EAAQ,EAEjCD,EAAK,YAAiBC,EAAQ,CAChC,GAAGH,GAAM,UAAW,CACpB,OAAiB,UAAW,CAClB,IAAII,EAAuB,CAE/B,IACC,SAASC,EAAyBC,EAAqBC,EAAqB,CAEnF,aAGAA,EAAoB,EAAED,EAAqB,CACzC,QAAW,UAAW,CAAE,OAAqBE,EAAW,CAC1D,CAAC,EAGD,IAAIC,EAAeF,EAAoB,GAAG,EACtCG,EAAoCH,EAAoB,EAAEE,CAAY,EAEtEE,EAASJ,EAAoB,GAAG,EAChCK,EAA8BL,EAAoB,EAAEI,CAAM,EAE1DE,EAAaN,EAAoB,GAAG,EACpCO,EAA8BP,EAAoB,EAAEM,CAAU,EAOlE,SAASE,EAAQC,EAAM,CACrB,GAAI,CACF,OAAO,SAAS,YAAYA,CAAI,CAClC,OAASC,EAAK,CACZ,MAAO,EACT,CACF,CAUA,IAAIC,EAAqB,SAA4BC,EAAQ,CAC3D,IAAIC,EAAeN,EAAe,EAAEK,CAAM,EAC1C,OAAAJ,EAAQ,KAAK,EACNK,CACT,EAEiCC,EAAeH,EAOhD,SAASI,EAAkBC,EAAO,CAChC,IAAIC,EAAQ,SAAS,gBAAgB,aAAa,KAAK,IAAM,MACzDC,EAAc,SAAS,cAAc,UAAU,EAEnDA,EAAY,MAAM,SAAW,OAE7BA,EAAY,MAAM,OAAS,IAC3BA,EAAY,MAAM,QAAU,IAC5BA,EAAY,MAAM,OAAS,IAE3BA,EAAY,MAAM,SAAW,WAC7BA,EAAY,MAAMD,EAAQ,QAAU,MAAM,EAAI,UAE9C,IAAIE,EAAY,OAAO,aAAe,SAAS,gBAAgB,UAC/D,OAAAD,EAAY,MAAM,IAAM,GAAG,OAAOC,EAAW,IAAI,EACjDD,EAAY,aAAa,WAAY,EAAE,EACvCA,EAAY,MAAQF,EACbE,CACT,CAYA,IAAIE,EAAiB,SAAwBJ,EAAOK,EAAS,CAC3D,IAAIH,EAAcH,EAAkBC,CAAK,EACzCK,EAAQ,UAAU,YAAYH,CAAW,EACzC,IAAIL,EAAeN,EAAe,EAAEW,CAAW,EAC/C,OAAAV,EAAQ,MAAM,EACdU,EAAY,OAAO,EACZL,CACT,EASIS,GAAsB,SAA6BV,EAAQ,CAC7D,IAAIS,EAAU,UAAU,OAAS,GAAK,UAAU,CAAC,IAAM,OAAY,UAAU,CAAC,EAAI,CAChF,UAAW,SAAS,IACtB,EACIR,EAAe,GAEnB,OAAI,OAAOD,GAAW,SACpBC,EAAeO,EAAeR,EAAQS,CAAO,EACpCT,aAAkB,kBAAoB,CAAC,CAAC,OAAQ,SAAU,MAAO,MAAO,UAAU,EAAE,SAASA,GAAW,KAA4B,OAASA,EAAO,IAAI,EAEjKC,EAAeO,EAAeR,EAAO,MAAOS,CAAO,GAEnDR,EAAeN,EAAe,EAAEK,CAAM,EACtCJ,EAAQ,MAAM,GAGTK,CACT,EAEiCU,EAAgBD,GAEjD,SAASE,EAAQC,EAAK,CAAE,0BAA2B,OAAI,OAAO,QAAW,YAAc,OAAO,OAAO,UAAa,SAAYD,EAAU,SAAiBC,EAAK,CAAE,OAAO,OAAOA,CAAK,EAAYD,EAAU,SAAiBC,EAAK,CAAE,OAAOA,GAAO,OAAO,QAAW,YAAcA,EAAI,cAAgB,QAAUA,IAAQ,OAAO,UAAY,SAAW,OAAOA,CAAK,EAAYD,EAAQC,CAAG,CAAG,CAUzX,IAAIC,GAAyB,UAAkC,CAC7D,IAAIL,EAAU,UAAU,OAAS,GAAK,UAAU,CAAC,IAAM,OAAY,UAAU,CAAC,EAAI,CAAC,EAE/EM,EAAkBN,EAAQ,OAC1BO,EAASD,IAAoB,OAAS,OAASA,EAC/CE,EAAYR,EAAQ,UACpBT,EAASS,EAAQ,OACjBS,GAAOT,EAAQ,KAEnB,GAAIO,IAAW,QAAUA,IAAW,MAClC,MAAM,IAAI,MAAM,oDAAoD,EAItE,GAAIhB,IAAW,OACb,GAAIA,GAAUY,EAAQZ,CAAM,IAAM,UAAYA,EAAO,WAAa,EAAG,CACnE,GAAIgB,IAAW,QAAUhB,EAAO,aAAa,UAAU,EACrD,MAAM,IAAI,MAAM,mFAAmF,EAGrG,GAAIgB,IAAW,QAAUhB,EAAO,aAAa,UAAU,GAAKA,EAAO,aAAa,UAAU,GACxF,MAAM,IAAI,MAAM,uGAAwG,CAE5H,KACE,OAAM,IAAI,MAAM,6CAA6C,EAKjE,GAAIkB,GACF,OAAOP,EAAaO,GAAM,CACxB,UAAWD,CACb,CAAC,EAIH,GAAIjB,EACF,OAAOgB,IAAW,MAAQd,EAAYF,CAAM,EAAIW,EAAaX,EAAQ,CACnE,UAAWiB,CACb,CAAC,CAEL,EAEiCE,GAAmBL,GAEpD,SAASM,GAAiBP,EAAK,CAAE,0BAA2B,OAAI,OAAO,QAAW,YAAc,OAAO,OAAO,UAAa,SAAYO,GAAmB,SAAiBP,EAAK,CAAE,OAAO,OAAOA,CAAK,EAAYO,GAAmB,SAAiBP,EAAK,CAAE,OAAOA,GAAO,OAAO,QAAW,YAAcA,EAAI,cAAgB,QAAUA,IAAQ,OAAO,UAAY,SAAW,OAAOA,CAAK,EAAYO,GAAiBP,CAAG,CAAG,CAE7Z,SAASQ,GAAgBC,EAAUC,EAAa,CAAE,GAAI,EAAED,aAAoBC,GAAgB,MAAM,IAAI,UAAU,mCAAmC,CAAK,CAExJ,SAASC,GAAkBxB,EAAQyB,EAAO,CAAE,QAASC,EAAI,EAAGA,EAAID,EAAM,OAAQC,IAAK,CAAE,IAAIC,EAAaF,EAAMC,CAAC,EAAGC,EAAW,WAAaA,EAAW,YAAc,GAAOA,EAAW,aAAe,GAAU,UAAWA,IAAYA,EAAW,SAAW,IAAM,OAAO,eAAe3B,EAAQ2B,EAAW,IAAKA,CAAU,CAAG,CAAE,CAE5T,SAASC,GAAaL,EAAaM,EAAYC,EAAa,CAAE,OAAID,GAAYL,GAAkBD,EAAY,UAAWM,CAAU,EAAOC,GAAaN,GAAkBD,EAAaO,CAAW,EAAUP,CAAa,CAEtN,SAASQ,GAAUC,EAAUC,EAAY,CAAE,GAAI,OAAOA,GAAe,YAAcA,IAAe,KAAQ,MAAM,IAAI,UAAU,oDAAoD,EAAKD,EAAS,UAAY,OAAO,OAAOC,GAAcA,EAAW,UAAW,CAAE,YAAa,CAAE,MAAOD,EAAU,SAAU,GAAM,aAAc,EAAK,CAAE,CAAC,EAAOC,GAAYC,GAAgBF,EAAUC,CAAU,CAAG,CAEhY,SAASC,GAAgBC,EAAGC,EAAG,CAAE,OAAAF,GAAkB,OAAO,gBAAkB,SAAyBC,EAAGC,EAAG,CAAE,OAAAD,EAAE,UAAYC,EAAUD,CAAG,EAAUD,GAAgBC,EAAGC,CAAC,CAAG,CAEzK,SAASC,GAAaC,EAAS,CAAE,IAAIC,EAA4BC,GAA0B,EAAG,OAAO,UAAgC,CAAE,IAAIC,EAAQC,GAAgBJ,CAAO,EAAGK,EAAQ,GAAIJ,EAA2B,CAAE,IAAIK,EAAYF,GAAgB,IAAI,EAAE,YAAaC,EAAS,QAAQ,UAAUF,EAAO,UAAWG,CAAS,CAAG,MAASD,EAASF,EAAM,MAAM,KAAM,SAAS,EAAK,OAAOI,GAA2B,KAAMF,CAAM,CAAG,CAAG,CAExa,SAASE,GAA2BC,EAAMC,EAAM,CAAE,OAAIA,IAAS3B,GAAiB2B,CAAI,IAAM,UAAY,OAAOA,GAAS,YAAsBA,EAAeC,GAAuBF,CAAI,CAAG,CAEzL,SAASE,GAAuBF,EAAM,CAAE,GAAIA,IAAS,OAAU,MAAM,IAAI,eAAe,2DAA2D,EAAK,OAAOA,CAAM,CAErK,SAASN,IAA4B,CAA0E,GAApE,OAAO,SAAY,aAAe,CAAC,QAAQ,WAA6B,QAAQ,UAAU,KAAM,MAAO,GAAO,GAAI,OAAO,OAAU,WAAY,MAAO,GAAM,GAAI,CAAE,YAAK,UAAU,SAAS,KAAK,QAAQ,UAAU,KAAM,CAAC,EAAG,UAAY,CAAC,CAAC,CAAC,EAAU,EAAM,OAASS,EAAG,CAAE,MAAO,EAAO,CAAE,CAEnU,SAASP,GAAgBP,EAAG,CAAE,OAAAO,GAAkB,OAAO,eAAiB,OAAO,eAAiB,SAAyBP,EAAG,CAAE,OAAOA,EAAE,WAAa,OAAO,eAAeA,CAAC,CAAG,EAAUO,GAAgBP,CAAC,CAAG,CAa5M,SAASe,GAAkBC,EAAQC,EAAS,CAC1C,IAAIC,EAAY,kBAAkB,OAAOF,CAAM,EAE/C,GAAKC,EAAQ,aAAaC,CAAS,EAInC,OAAOD,EAAQ,aAAaC,CAAS,CACvC,CAOA,IAAIC,GAAyB,SAAUC,EAAU,CAC/CxB,GAAUuB,EAAWC,CAAQ,EAE7B,IAAIC,EAASnB,GAAaiB,CAAS,EAMnC,SAASA,EAAUG,EAAShD,EAAS,CACnC,IAAIiD,EAEJ,OAAArC,GAAgB,KAAMiC,CAAS,EAE/BI,EAAQF,EAAO,KAAK,IAAI,EAExBE,EAAM,eAAejD,CAAO,EAE5BiD,EAAM,YAAYD,CAAO,EAElBC,CACT,CAQA,OAAA9B,GAAa0B,EAAW,CAAC,CACvB,IAAK,iBACL,MAAO,UAA0B,CAC/B,IAAI7C,EAAU,UAAU,OAAS,GAAK,UAAU,CAAC,IAAM,OAAY,UAAU,CAAC,EAAI,CAAC,EACnF,KAAK,OAAS,OAAOA,EAAQ,QAAW,WAAaA,EAAQ,OAAS,KAAK,cAC3E,KAAK,OAAS,OAAOA,EAAQ,QAAW,WAAaA,EAAQ,OAAS,KAAK,cAC3E,KAAK,KAAO,OAAOA,EAAQ,MAAS,WAAaA,EAAQ,KAAO,KAAK,YACrE,KAAK,UAAYW,GAAiBX,EAAQ,SAAS,IAAM,SAAWA,EAAQ,UAAY,SAAS,IACnG,CAMF,EAAG,CACD,IAAK,cACL,MAAO,SAAqBgD,EAAS,CACnC,IAAIE,EAAS,KAEb,KAAK,SAAWlE,EAAe,EAAEgE,EAAS,QAAS,SAAUR,GAAG,CAC9D,OAAOU,EAAO,QAAQV,EAAC,CACzB,CAAC,CACH,CAMF,EAAG,CACD,IAAK,UACL,MAAO,SAAiBA,EAAG,CACzB,IAAIQ,EAAUR,EAAE,gBAAkBA,EAAE,cAChCjC,GAAS,KAAK,OAAOyC,CAAO,GAAK,OACjCvC,GAAOC,GAAgB,CACzB,OAAQH,GACR,UAAW,KAAK,UAChB,OAAQ,KAAK,OAAOyC,CAAO,EAC3B,KAAM,KAAK,KAAKA,CAAO,CACzB,CAAC,EAED,KAAK,KAAKvC,GAAO,UAAY,QAAS,CACpC,OAAQF,GACR,KAAME,GACN,QAASuC,EACT,eAAgB,UAA0B,CACpCA,GACFA,EAAQ,MAAM,EAGhB,OAAO,aAAa,EAAE,gBAAgB,CACxC,CACF,CAAC,CACH,CAMF,EAAG,CACD,IAAK,gBACL,MAAO,SAAuBA,EAAS,CACrC,OAAOP,GAAkB,SAAUO,CAAO,CAC5C,CAMF,EAAG,CACD,IAAK,gBACL,MAAO,SAAuBA,EAAS,CACrC,IAAIG,EAAWV,GAAkB,SAAUO,CAAO,EAElD,GAAIG,EACF,OAAO,SAAS,cAAcA,CAAQ,CAE1C,CAQF,EAAG,CACD,IAAK,cAML,MAAO,SAAqBH,EAAS,CACnC,OAAOP,GAAkB,OAAQO,CAAO,CAC1C,CAKF,EAAG,CACD,IAAK,UACL,MAAO,UAAmB,CACxB,KAAK,SAAS,QAAQ,CACxB,CACF,CAAC,EAAG,CAAC,CACH,IAAK,OACL,MAAO,SAAczD,EAAQ,CAC3B,IAAIS,EAAU,UAAU,OAAS,GAAK,UAAU,CAAC,IAAM,OAAY,UAAU,CAAC,EAAI,CAChF,UAAW,SAAS,IACtB,EACA,OAAOE,EAAaX,EAAQS,CAAO,CACrC,CAOF,EAAG,CACD,IAAK,MACL,MAAO,SAAaT,EAAQ,CAC1B,OAAOE,EAAYF,CAAM,CAC3B,CAOF,EAAG,CACD,IAAK,cACL,MAAO,UAAuB,CAC5B,IAAIgB,EAAS,UAAU,OAAS,GAAK,UAAU,CAAC,IAAM,OAAY,UAAU,CAAC,EAAI,CAAC,OAAQ,KAAK,EAC3F6C,EAAU,OAAO7C,GAAW,SAAW,CAACA,CAAM,EAAIA,EAClD8C,GAAU,CAAC,CAAC,SAAS,sBACzB,OAAAD,EAAQ,QAAQ,SAAU7C,GAAQ,CAChC8C,GAAUA,IAAW,CAAC,CAAC,SAAS,sBAAsB9C,EAAM,CAC9D,CAAC,EACM8C,EACT,CACF,CAAC,CAAC,EAEKR,CACT,EAAG/D,EAAqB,CAAE,EAEOF,GAAaiE,EAExC,EAEA,IACC,SAASxE,EAAQ,CAExB,IAAIiF,EAAqB,EAKzB,GAAI,OAAO,SAAY,aAAe,CAAC,QAAQ,UAAU,QAAS,CAC9D,IAAIC,EAAQ,QAAQ,UAEpBA,EAAM,QAAUA,EAAM,iBACNA,EAAM,oBACNA,EAAM,mBACNA,EAAM,kBACNA,EAAM,qBAC1B,CASA,SAASC,EAASb,EAASQ,EAAU,CACjC,KAAOR,GAAWA,EAAQ,WAAaW,GAAoB,CACvD,GAAI,OAAOX,EAAQ,SAAY,YAC3BA,EAAQ,QAAQQ,CAAQ,EAC1B,OAAOR,EAETA,EAAUA,EAAQ,UACtB,CACJ,CAEAtE,EAAO,QAAUmF,CAGX,EAEA,IACC,SAASnF,EAAQoF,EAA0B9E,EAAqB,CAEvE,IAAI6E,EAAU7E,EAAoB,GAAG,EAYrC,SAAS+E,EAAUf,EAASQ,EAAU/D,EAAMuE,EAAUC,EAAY,CAC9D,IAAIC,EAAaC,EAAS,MAAM,KAAM,SAAS,EAE/C,OAAAnB,EAAQ,iBAAiBvD,EAAMyE,EAAYD,CAAU,EAE9C,CACH,QAAS,UAAW,CAChBjB,EAAQ,oBAAoBvD,EAAMyE,EAAYD,CAAU,CAC5D,CACJ,CACJ,CAYA,SAASG,EAASC,EAAUb,EAAU/D,EAAMuE,EAAUC,EAAY,CAE9D,OAAI,OAAOI,EAAS,kBAAqB,WAC9BN,EAAU,MAAM,KAAM,SAAS,EAItC,OAAOtE,GAAS,WAGTsE,EAAU,KAAK,KAAM,QAAQ,EAAE,MAAM,KAAM,SAAS,GAI3D,OAAOM,GAAa,WACpBA,EAAW,SAAS,iBAAiBA,CAAQ,GAI1C,MAAM,UAAU,IAAI,KAAKA,EAAU,SAAUrB,EAAS,CACzD,OAAOe,EAAUf,EAASQ,EAAU/D,EAAMuE,EAAUC,CAAU,CAClE,CAAC,EACL,CAWA,SAASE,EAASnB,EAASQ,EAAU/D,EAAMuE,EAAU,CACjD,OAAO,SAASnB,EAAG,CACfA,EAAE,eAAiBgB,EAAQhB,EAAE,OAAQW,CAAQ,EAEzCX,EAAE,gBACFmB,EAAS,KAAKhB,EAASH,CAAC,CAEhC,CACJ,CAEAnE,EAAO,QAAU0F,CAGX,EAEA,IACC,SAAStF,EAAyBL,EAAS,CAQlDA,EAAQ,KAAO,SAASuB,EAAO,CAC3B,OAAOA,IAAU,QACVA,aAAiB,aACjBA,EAAM,WAAa,CAC9B,EAQAvB,EAAQ,SAAW,SAASuB,EAAO,CAC/B,IAAIP,EAAO,OAAO,UAAU,SAAS,KAAKO,CAAK,EAE/C,OAAOA,IAAU,SACTP,IAAS,qBAAuBA,IAAS,4BACzC,WAAYO,IACZA,EAAM,SAAW,GAAKvB,EAAQ,KAAKuB,EAAM,CAAC,CAAC,EACvD,EAQAvB,EAAQ,OAAS,SAASuB,EAAO,CAC7B,OAAO,OAAOA,GAAU,UACjBA,aAAiB,MAC5B,EAQAvB,EAAQ,GAAK,SAASuB,EAAO,CACzB,IAAIP,EAAO,OAAO,UAAU,SAAS,KAAKO,CAAK,EAE/C,OAAOP,IAAS,mBACpB,CAGM,EAEA,IACC,SAASf,EAAQoF,EAA0B9E,EAAqB,CAEvE,IAAIsF,EAAKtF,EAAoB,GAAG,EAC5BoF,EAAWpF,EAAoB,GAAG,EAWtC,SAASI,EAAOQ,EAAQH,EAAMuE,EAAU,CACpC,GAAI,CAACpE,GAAU,CAACH,GAAQ,CAACuE,EACrB,MAAM,IAAI,MAAM,4BAA4B,EAGhD,GAAI,CAACM,EAAG,OAAO7E,CAAI,EACf,MAAM,IAAI,UAAU,kCAAkC,EAG1D,GAAI,CAAC6E,EAAG,GAAGN,CAAQ,EACf,MAAM,IAAI,UAAU,mCAAmC,EAG3D,GAAIM,EAAG,KAAK1E,CAAM,EACd,OAAO2E,EAAW3E,EAAQH,EAAMuE,CAAQ,EAEvC,GAAIM,EAAG,SAAS1E,CAAM,EACvB,OAAO4E,EAAe5E,EAAQH,EAAMuE,CAAQ,EAE3C,GAAIM,EAAG,OAAO1E,CAAM,EACrB,OAAO6E,EAAe7E,EAAQH,EAAMuE,CAAQ,EAG5C,MAAM,IAAI,UAAU,2EAA2E,CAEvG,CAWA,SAASO,EAAWG,EAAMjF,EAAMuE,EAAU,CACtC,OAAAU,EAAK,iBAAiBjF,EAAMuE,CAAQ,EAE7B,CACH,QAAS,UAAW,CAChBU,EAAK,oBAAoBjF,EAAMuE,CAAQ,CAC3C,CACJ,CACJ,CAWA,SAASQ,EAAeG,EAAUlF,EAAMuE,EAAU,CAC9C,aAAM,UAAU,QAAQ,KAAKW,EAAU,SAASD,EAAM,CAClDA,EAAK,iBAAiBjF,EAAMuE,CAAQ,CACxC,CAAC,EAEM,CACH,QAAS,UAAW,CAChB,MAAM,UAAU,QAAQ,KAAKW,EAAU,SAASD,EAAM,CAClDA,EAAK,oBAAoBjF,EAAMuE,CAAQ,CAC3C,CAAC,CACL,CACJ,CACJ,CAWA,SAASS,EAAejB,EAAU/D,EAAMuE,EAAU,CAC9C,OAAOI,EAAS,SAAS,KAAMZ,EAAU/D,EAAMuE,CAAQ,CAC3D,CAEAtF,EAAO,QAAUU,CAGX,EAEA,IACC,SAASV,EAAQ,CAExB,SAASkG,EAAO5B,EAAS,CACrB,IAAInD,EAEJ,GAAImD,EAAQ,WAAa,SACrBA,EAAQ,MAAM,EAEdnD,EAAemD,EAAQ,cAElBA,EAAQ,WAAa,SAAWA,EAAQ,WAAa,WAAY,CACtE,IAAI6B,EAAa7B,EAAQ,aAAa,UAAU,EAE3C6B,GACD7B,EAAQ,aAAa,WAAY,EAAE,EAGvCA,EAAQ,OAAO,EACfA,EAAQ,kBAAkB,EAAGA,EAAQ,MAAM,MAAM,EAE5C6B,GACD7B,EAAQ,gBAAgB,UAAU,EAGtCnD,EAAemD,EAAQ,KAC3B,KACK,CACGA,EAAQ,aAAa,iBAAiB,GACtCA,EAAQ,MAAM,EAGlB,IAAI8B,EAAY,OAAO,aAAa,EAChCC,EAAQ,SAAS,YAAY,EAEjCA,EAAM,mBAAmB/B,CAAO,EAChC8B,EAAU,gBAAgB,EAC1BA,EAAU,SAASC,CAAK,EAExBlF,EAAeiF,EAAU,SAAS,CACtC,CAEA,OAAOjF,CACX,CAEAnB,EAAO,QAAUkG,CAGX,EAEA,IACC,SAASlG,EAAQ,CAExB,SAASsG,GAAK,CAGd,CAEAA,EAAE,UAAY,CACZ,GAAI,SAAUC,EAAMjB,EAAUkB,EAAK,CACjC,IAAIrC,EAAI,KAAK,IAAM,KAAK,EAAI,CAAC,GAE7B,OAACA,EAAEoC,CAAI,IAAMpC,EAAEoC,CAAI,EAAI,CAAC,IAAI,KAAK,CAC/B,GAAIjB,EACJ,IAAKkB,CACP,CAAC,EAEM,IACT,EAEA,KAAM,SAAUD,EAAMjB,EAAUkB,EAAK,CACnC,IAAIxC,EAAO,KACX,SAASyB,GAAY,CACnBzB,EAAK,IAAIuC,EAAMd,CAAQ,EACvBH,EAAS,MAAMkB,EAAK,SAAS,CAC/B,CAEA,OAAAf,EAAS,EAAIH,EACN,KAAK,GAAGiB,EAAMd,EAAUe,CAAG,CACpC,EAEA,KAAM,SAAUD,EAAM,CACpB,IAAIE,EAAO,CAAC,EAAE,MAAM,KAAK,UAAW,CAAC,EACjCC,IAAW,KAAK,IAAM,KAAK,EAAI,CAAC,IAAIH,CAAI,GAAK,CAAC,GAAG,MAAM,EACvD3D,EAAI,EACJ+D,EAAMD,EAAO,OAEjB,IAAK9D,EAAGA,EAAI+D,EAAK/D,IACf8D,EAAO9D,CAAC,EAAE,GAAG,MAAM8D,EAAO9D,CAAC,EAAE,IAAK6D,CAAI,EAGxC,OAAO,IACT,EAEA,IAAK,SAAUF,EAAMjB,EAAU,CAC7B,IAAInB,EAAI,KAAK,IAAM,KAAK,EAAI,CAAC,GACzByC,EAAOzC,EAAEoC,CAAI,EACbM,EAAa,CAAC,EAElB,GAAID,GAAQtB,EACV,QAAS1C,EAAI,EAAG+D,EAAMC,EAAK,OAAQhE,EAAI+D,EAAK/D,IACtCgE,EAAKhE,CAAC,EAAE,KAAO0C,GAAYsB,EAAKhE,CAAC,EAAE,GAAG,IAAM0C,GAC9CuB,EAAW,KAAKD,EAAKhE,CAAC,CAAC,EAQ7B,OAACiE,EAAW,OACR1C,EAAEoC,CAAI,EAAIM,EACV,OAAO1C,EAAEoC,CAAI,EAEV,IACT,CACF,EAEAvG,EAAO,QAAUsG,EACjBtG,EAAO,QAAQ,YAAcsG,CAGvB,CAEI,EAGIQ,EAA2B,CAAC,EAGhC,SAASxG,EAAoByG,EAAU,CAEtC,GAAGD,EAAyBC,CAAQ,EACnC,OAAOD,EAAyBC,CAAQ,EAAE,QAG3C,IAAI/G,EAAS8G,EAAyBC,CAAQ,EAAI,CAGjD,QAAS,CAAC,CACX,EAGA,OAAA5G,EAAoB4G,CAAQ,EAAE/G,EAAQA,EAAO,QAASM,CAAmB,EAGlEN,EAAO,OACf,CAIA,OAAC,UAAW,CAEXM,EAAoB,EAAI,SAASN,EAAQ,CACxC,IAAIgH,EAAShH,GAAUA,EAAO,WAC7B,UAAW,CAAE,OAAOA,EAAO,OAAY,EACvC,UAAW,CAAE,OAAOA,CAAQ,EAC7B,OAAAM,EAAoB,EAAE0G,EAAQ,CAAE,EAAGA,CAAO,CAAC,EACpCA,CACR,CACD,EAAE,EAGD,UAAW,CAEX1G,EAAoB,EAAI,SAASP,EAASkH,EAAY,CACrD,QAAQC,KAAOD,EACX3G,EAAoB,EAAE2G,EAAYC,CAAG,GAAK,CAAC5G,EAAoB,EAAEP,EAASmH,CAAG,GAC/E,OAAO,eAAenH,EAASmH,EAAK,CAAE,WAAY,GAAM,IAAKD,EAAWC,CAAG,CAAE,CAAC,CAGjF,CACD,EAAE,EAGD,UAAW,CACX5G,EAAoB,EAAI,SAASyB,EAAKoF,EAAM,CAAE,OAAO,OAAO,UAAU,eAAe,KAAKpF,EAAKoF,CAAI,CAAG,CACvG,EAAE,EAMK7G,EAAoB,GAAG,CAC/B,EAAG,EACX,OACD,CAAC,ICn2BD,IAAA8G,GAAO,SCNP,IAAIC,GAAgB,SAASC,EAAGC,EAAG,CACjC,OAAAF,GAAgB,OAAO,gBAClB,CAAE,UAAW,CAAC,CAAE,YAAa,OAAS,SAAUC,EAAGC,EAAG,CAAED,EAAE,UAAYC,CAAG,GAC1E,SAAUD,EAAGC,EAAG,CAAE,QAASC,KAAKD,EAAO,OAAO,UAAU,eAAe,KAAKA,EAAGC,CAAC,IAAGF,EAAEE,CAAC,EAAID,EAAEC,CAAC,EAAG,EAC7FH,GAAcC,EAAGC,CAAC,CAC3B,EAEO,SAASE,GAAUH,EAAGC,EAAG,CAC9B,GAAI,OAAOA,GAAM,YAAcA,IAAM,KACjC,MAAM,IAAI,UAAU,uBAAyB,OAAOA,CAAC,EAAI,+BAA+B,EAC5FF,GAAcC,EAAGC,CAAC,EAClB,SAASG,GAAK,CAAE,KAAK,YAAcJ,CAAG,CACtCA,EAAE,UAAYC,IAAM,KAAO,OAAO,OAAOA,CAAC,GAAKG,EAAG,UAAYH,EAAE,UAAW,IAAIG,EACjF,CAqFO,SAASC,GAAUC,EAASC,EAAYC,EAAGC,EAAW,CAC3D,SAASC,EAAMC,EAAO,CAAE,OAAOA,aAAiBH,EAAIG,EAAQ,IAAIH,EAAE,SAAUI,EAAS,CAAEA,EAAQD,CAAK,CAAG,CAAC,CAAG,CAC3G,OAAO,IAAKH,IAAMA,EAAI,UAAU,SAAUI,EAASC,EAAQ,CACvD,SAASC,EAAUH,EAAO,CAAE,GAAI,CAAEI,EAAKN,EAAU,KAAKE,CAAK,CAAC,CAAG,OAASK,EAAG,CAAEH,EAAOG,CAAC,CAAG,CAAE,CAC1F,SAASC,EAASN,EAAO,CAAE,GAAI,CAAEI,EAAKN,EAAU,MAASE,CAAK,CAAC,CAAG,OAASK,EAAG,CAAEH,EAAOG,CAAC,CAAG,CAAE,CAC7F,SAASD,EAAKG,EAAQ,CAAEA,EAAO,KAAON,EAAQM,EAAO,KAAK,EAAIR,EAAMQ,EAAO,KAAK,EAAE,KAAKJ,EAAWG,CAAQ,CAAG,CAC7GF,GAAMN,EAAYA,EAAU,MAAMH,EAASC,GAAc,CAAC,CAAC,GAAG,KAAK,CAAC,CACxE,CAAC,CACH,CAEO,SAASY,GAAYb,EAASc,EAAM,CACzC,IAAIC,EAAI,CAAE,MAAO,EAAG,KAAM,UAAW,CAAE,GAAIC,EAAE,CAAC,EAAI,EAAG,MAAMA,EAAE,CAAC,EAAG,OAAOA,EAAE,CAAC,CAAG,EAAG,KAAM,CAAC,EAAG,IAAK,CAAC,CAAE,EAAGC,EAAGC,EAAGF,EAAGG,EAAI,OAAO,QAAQ,OAAO,UAAa,WAAa,SAAW,QAAQ,SAAS,EAC/L,OAAOA,EAAE,KAAOC,EAAK,CAAC,EAAGD,EAAE,MAAWC,EAAK,CAAC,EAAGD,EAAE,OAAYC,EAAK,CAAC,EAAG,OAAO,QAAW,aAAeD,EAAE,OAAO,QAAQ,EAAI,UAAW,CAAE,OAAO,IAAM,GAAIA,EAC1J,SAASC,EAAKC,EAAG,CAAE,OAAO,SAAUC,EAAG,CAAE,OAAOb,EAAK,CAACY,EAAGC,CAAC,CAAC,CAAG,CAAG,CACjE,SAASb,EAAKc,EAAI,CACd,GAAIN,EAAG,MAAM,IAAI,UAAU,iCAAiC,EAC5D,KAAOE,IAAMA,EAAI,EAAGI,EAAG,CAAC,IAAMR,EAAI,IAAKA,GAAG,GAAI,CAC1C,GAAIE,EAAI,EAAGC,IAAMF,EAAIO,EAAG,CAAC,EAAI,EAAIL,EAAE,OAAYK,EAAG,CAAC,EAAIL,EAAE,SAAcF,EAAIE,EAAE,SAAcF,EAAE,KAAKE,CAAC,EAAG,GAAKA,EAAE,OAAS,EAAEF,EAAIA,EAAE,KAAKE,EAAGK,EAAG,CAAC,CAAC,GAAG,KAAM,OAAOP,EAE3J,OADIE,EAAI,EAAGF,IAAGO,EAAK,CAACA,EAAG,CAAC,EAAI,EAAGP,EAAE,KAAK,GAC9BO,EAAG,CAAC,EAAG,CACX,IAAK,GAAG,IAAK,GAAGP,EAAIO,EAAI,MACxB,IAAK,GAAG,OAAAR,EAAE,QAAgB,CAAE,MAAOQ,EAAG,CAAC,EAAG,KAAM,EAAM,EACtD,IAAK,GAAGR,EAAE,QAASG,EAAIK,EAAG,CAAC,EAAGA,EAAK,CAAC,CAAC,EAAG,SACxC,IAAK,GAAGA,EAAKR,EAAE,IAAI,IAAI,EAAGA,EAAE,KAAK,IAAI,EAAG,SACxC,QACI,GAAMC,EAAID,EAAE,KAAM,EAAAC,EAAIA,EAAE,OAAS,GAAKA,EAAEA,EAAE,OAAS,CAAC,KAAOO,EAAG,CAAC,IAAM,GAAKA,EAAG,CAAC,IAAM,GAAI,CAAER,EAAI,EAAG,QAAU,CAC3G,GAAIQ,EAAG,CAAC,IAAM,IAAM,CAACP,GAAMO,EAAG,CAAC,EAAIP,EAAE,CAAC,GAAKO,EAAG,CAAC,EAAIP,EAAE,CAAC,GAAK,CAAED,EAAE,MAAQQ,EAAG,CAAC,EAAG,KAAO,CACrF,GAAIA,EAAG,CAAC,IAAM,GAAKR,EAAE,MAAQC,EAAE,CAAC,EAAG,CAAED,EAAE,MAAQC,EAAE,CAAC,EAAGA,EAAIO,EAAI,KAAO,CACpE,GAAIP,GAAKD,EAAE,MAAQC,EAAE,CAAC,EAAG,CAAED,EAAE,MAAQC,EAAE,CAAC,EAAGD,EAAE,IAAI,KAAKQ,CAAE,EAAG,KAAO,CAC9DP,EAAE,CAAC,GAAGD,EAAE,IAAI,IAAI,EACpBA,EAAE,KAAK,IAAI,EAAG,QACtB,CACAQ,EAAKT,EAAK,KAAKd,EAASe,CAAC,CAC7B,OAASL,EAAG,CAAEa,EAAK,CAAC,EAAGb,CAAC,EAAGQ,EAAI,CAAG,QAAE,CAAUD,EAAID,EAAI,CAAG,CACzD,GAAIO,EAAG,CAAC,EAAI,EAAG,MAAMA,EAAG,CAAC,EAAG,MAAO,CAAE,MAAOA,EAAG,CAAC,EAAIA,EAAG,CAAC,EAAI,OAAQ,KAAM,EAAK,CACnF,CACF,CAkBO,SAASC,GAASC,EAAG,CAC1B,IAAIC,EAAI,OAAO,QAAW,YAAc,OAAO,SAAUC,EAAID,GAAKD,EAAEC,CAAC,EAAGE,EAAI,EAC5E,GAAID,EAAG,OAAOA,EAAE,KAAKF,CAAC,EACtB,GAAIA,GAAK,OAAOA,EAAE,QAAW,SAAU,MAAO,CAC1C,KAAM,UAAY,CACd,OAAIA,GAAKG,GAAKH,EAAE,SAAQA,EAAI,QACrB,CAAE,MAAOA,GAAKA,EAAEG,GAAG,EAAG,KAAM,CAACH,CAAE,CAC1C,CACJ,EACA,MAAM,IAAI,UAAUC,EAAI,0BAA4B,iCAAiC,CACvF,CAEO,SAASG,EAAOJ,EAAGK,EAAG,CAC3B,IAAIH,EAAI,OAAO,QAAW,YAAcF,EAAE,OAAO,QAAQ,EACzD,GAAI,CAACE,EAAG,OAAOF,EACf,IAAIG,EAAID,EAAE,KAAKF,CAAC,EAAGM,EAAGC,EAAK,CAAC,EAAGC,EAC/B,GAAI,CACA,MAAQH,IAAM,QAAUA,KAAM,IAAM,EAAEC,EAAIH,EAAE,KAAK,GAAG,MAAMI,EAAG,KAAKD,EAAE,KAAK,CAC7E,OACOG,EAAO,CAAED,EAAI,CAAE,MAAOC,CAAM,CAAG,QACtC,CACI,GAAI,CACIH,GAAK,CAACA,EAAE,OAASJ,EAAIC,EAAE,SAAYD,EAAE,KAAKC,CAAC,CACnD,QACA,CAAU,GAAIK,EAAG,MAAMA,EAAE,KAAO,CACpC,CACA,OAAOD,CACT,CAkBO,SAASG,EAAcC,EAAIC,EAAMC,EAAM,CAC5C,GAAIA,GAAQ,UAAU,SAAW,EAAG,QAASC,EAAI,EAAGC,EAAIH,EAAK,OAAQI,EAAIF,EAAIC,EAAGD,KACxEE,GAAM,EAAEF,KAAKF,MACRI,IAAIA,EAAK,MAAM,UAAU,MAAM,KAAKJ,EAAM,EAAGE,CAAC,GACnDE,EAAGF,CAAC,EAAIF,EAAKE,CAAC,GAGtB,OAAOH,EAAG,OAAOK,GAAM,MAAM,UAAU,MAAM,KAAKJ,CAAI,CAAC,CACzD,CAEO,SAASK,GAAQC,EAAG,CACzB,OAAO,gBAAgBD,IAAW,KAAK,EAAIC,EAAG,MAAQ,IAAID,GAAQC,CAAC,CACrE,CAEO,SAASC,GAAiBC,EAASC,EAAYC,EAAW,CAC/D,GAAI,CAAC,OAAO,cAAe,MAAM,IAAI,UAAU,sCAAsC,EACrF,IAAIC,EAAID,EAAU,MAAMF,EAASC,GAAc,CAAC,CAAC,EAAGP,EAAGU,EAAI,CAAC,EAC5D,OAAOV,EAAI,OAAO,QAAQ,OAAO,eAAkB,WAAa,cAAgB,QAAQ,SAAS,EAAGW,EAAK,MAAM,EAAGA,EAAK,OAAO,EAAGA,EAAK,SAAUC,CAAW,EAAGZ,EAAE,OAAO,aAAa,EAAI,UAAY,CAAE,OAAO,IAAM,EAAGA,EACtN,SAASY,EAAYC,EAAG,CAAE,OAAO,SAAUT,EAAG,CAAE,OAAO,QAAQ,QAAQA,CAAC,EAAE,KAAKS,EAAGC,CAAM,CAAG,CAAG,CAC9F,SAASH,EAAKI,EAAGF,EAAG,CAAMJ,EAAEM,CAAC,IAAKf,EAAEe,CAAC,EAAI,SAAUX,EAAG,CAAE,OAAO,IAAI,QAAQ,SAAUY,EAAGC,GAAG,CAAEP,EAAE,KAAK,CAACK,EAAGX,EAAGY,EAAGC,EAAC,CAAC,EAAI,GAAKC,EAAOH,EAAGX,CAAC,CAAG,CAAC,CAAG,EAAOS,IAAGb,EAAEe,CAAC,EAAIF,EAAEb,EAAEe,CAAC,CAAC,GAAK,CACvK,SAASG,EAAOH,EAAGX,EAAG,CAAE,GAAI,CAAEe,EAAKV,EAAEM,CAAC,EAAEX,CAAC,CAAC,CAAG,OAASgB,EAAG,CAAEC,EAAOX,EAAE,CAAC,EAAE,CAAC,EAAGU,CAAC,CAAG,CAAE,CACjF,SAASD,EAAKG,EAAG,CAAEA,EAAE,iBAAiBnB,GAAU,QAAQ,QAAQmB,EAAE,MAAM,CAAC,EAAE,KAAKC,EAAST,CAAM,EAAIO,EAAOX,EAAE,CAAC,EAAE,CAAC,EAAGY,CAAC,CAAG,CACvH,SAASC,EAAQC,EAAO,CAAEN,EAAO,OAAQM,CAAK,CAAG,CACjD,SAASV,EAAOU,EAAO,CAAEN,EAAO,QAASM,CAAK,CAAG,CACjD,SAASH,EAAOR,EAAGT,EAAG,CAAMS,EAAET,CAAC,EAAGM,EAAE,MAAM,EAAGA,EAAE,QAAQQ,EAAOR,EAAE,CAAC,EAAE,CAAC,EAAGA,EAAE,CAAC,EAAE,CAAC,CAAC,CAAG,CACnF,CAQO,SAASe,GAAcC,EAAG,CAC/B,GAAI,CAAC,OAAO,cAAe,MAAM,IAAI,UAAU,sCAAsC,EACrF,IAAIC,EAAID,EAAE,OAAO,aAAa,EAAGE,EACjC,OAAOD,EAAIA,EAAE,KAAKD,CAAC,GAAKA,EAAI,OAAOG,IAAa,WAAaA,GAASH,CAAC,EAAIA,EAAE,OAAO,QAAQ,EAAE,EAAGE,EAAI,CAAC,EAAGE,EAAK,MAAM,EAAGA,EAAK,OAAO,EAAGA,EAAK,QAAQ,EAAGF,EAAE,OAAO,aAAa,EAAI,UAAY,CAAE,OAAO,IAAM,EAAGA,GAC9M,SAASE,EAAKC,EAAG,CAAEH,EAAEG,CAAC,EAAIL,EAAEK,CAAC,GAAK,SAAUC,EAAG,CAAE,OAAO,IAAI,QAAQ,SAAUC,EAASC,EAAQ,CAAEF,EAAIN,EAAEK,CAAC,EAAEC,CAAC,EAAGG,EAAOF,EAASC,EAAQF,EAAE,KAAMA,EAAE,KAAK,CAAG,CAAC,CAAG,CAAG,CAC/J,SAASG,EAAOF,EAASC,EAAQE,EAAGJ,EAAG,CAAE,QAAQ,QAAQA,CAAC,EAAE,KAAK,SAASA,EAAG,CAAEC,EAAQ,CAAE,MAAOD,EAAG,KAAMI,CAAE,CAAC,CAAG,EAAGF,CAAM,CAAG,CAC7H,CCxPM,SAAUG,EAAWC,EAAU,CACnC,OAAO,OAAOA,GAAU,UAC1B,CCGM,SAAUC,GAAoBC,EAAgC,CAClE,IAAMC,EAAS,SAACC,EAAa,CAC3B,MAAM,KAAKA,CAAQ,EACnBA,EAAS,MAAQ,IAAI,MAAK,EAAG,KAC/B,EAEMC,EAAWH,EAAWC,CAAM,EAClC,OAAAE,EAAS,UAAY,OAAO,OAAO,MAAM,SAAS,EAClDA,EAAS,UAAU,YAAcA,EAC1BA,CACT,CCDO,IAAMC,GAA+CC,GAC1D,SAACC,EAAM,CACL,OAAA,SAA4CC,EAA0B,CACpED,EAAO,IAAI,EACX,KAAK,QAAUC,EACRA,EAAO,OAAM;EACxBA,EAAO,IAAI,SAACC,EAAKC,EAAC,CAAK,OAAGA,EAAI,EAAC,KAAKD,EAAI,SAAQ,CAAzB,CAA6B,EAAE,KAAK;GAAM,EACzD,GACJ,KAAK,KAAO,sBACZ,KAAK,OAASD,CAChB,CARA,CAQC,ECvBC,SAAUG,GAAaC,EAA6BC,EAAO,CAC/D,GAAID,EAAK,CACP,IAAME,EAAQF,EAAI,QAAQC,CAAI,EAC9B,GAAKC,GAASF,EAAI,OAAOE,EAAO,CAAC,EAErC,CCOA,IAAAC,GAAA,UAAA,CAyBE,SAAAA,EAAoBC,EAA4B,CAA5B,KAAA,gBAAAA,EAdb,KAAA,OAAS,GAER,KAAA,WAAmD,KAMnD,KAAA,YAAqD,IAMV,CAQnD,OAAAD,EAAA,UAAA,YAAA,UAAA,aACME,EAEJ,GAAI,CAAC,KAAK,OAAQ,CAChB,KAAK,OAAS,GAGN,IAAAC,EAAe,KAAI,WAC3B,GAAIA,EAEF,GADA,KAAK,WAAa,KACd,MAAM,QAAQA,CAAU,MAC1B,QAAqBC,EAAAC,GAAAF,CAAU,EAAAG,EAAAF,EAAA,KAAA,EAAA,CAAAE,EAAA,KAAAA,EAAAF,EAAA,KAAA,EAAE,CAA5B,IAAMG,EAAMD,EAAA,MACfC,EAAO,OAAO,IAAI,yGAGpBJ,EAAW,OAAO,IAAI,EAIlB,IAAiBK,EAAqB,KAAI,gBAClD,GAAIC,EAAWD,CAAgB,EAC7B,GAAI,CACFA,EAAgB,QACTE,EAAG,CACVR,EAASQ,aAAaC,GAAsBD,EAAE,OAAS,CAACA,CAAC,EAIrD,IAAAE,EAAgB,KAAI,YAC5B,GAAIA,EAAa,CACf,KAAK,YAAc,SACnB,QAAwBC,EAAAR,GAAAO,CAAW,EAAAE,EAAAD,EAAA,KAAA,EAAA,CAAAC,EAAA,KAAAA,EAAAD,EAAA,KAAA,EAAE,CAAhC,IAAME,EAASD,EAAA,MAClB,GAAI,CACFE,GAAcD,CAAS,QAChBE,EAAK,CACZf,EAASA,GAAM,KAANA,EAAU,CAAA,EACfe,aAAeN,GACjBT,EAAMgB,EAAAA,EAAA,CAAA,EAAAC,EAAOjB,CAAM,CAAA,EAAAiB,EAAKF,EAAI,MAAM,CAAA,EAElCf,EAAO,KAAKe,CAAG,sGAMvB,GAAIf,EACF,MAAM,IAAIS,GAAoBT,CAAM,EAG1C,EAoBAF,EAAA,UAAA,IAAA,SAAIoB,EAAuB,OAGzB,GAAIA,GAAYA,IAAa,KAC3B,GAAI,KAAK,OAGPJ,GAAcI,CAAQ,MACjB,CACL,GAAIA,aAAoBpB,EAAc,CAGpC,GAAIoB,EAAS,QAAUA,EAAS,WAAW,IAAI,EAC7C,OAEFA,EAAS,WAAW,IAAI,GAEzB,KAAK,aAAcC,EAAA,KAAK,eAAW,MAAAA,IAAA,OAAAA,EAAI,CAAA,GAAI,KAAKD,CAAQ,EAG/D,EAOQpB,EAAA,UAAA,WAAR,SAAmBsB,EAAoB,CAC7B,IAAAnB,EAAe,KAAI,WAC3B,OAAOA,IAAemB,GAAW,MAAM,QAAQnB,CAAU,GAAKA,EAAW,SAASmB,CAAM,CAC1F,EASQtB,EAAA,UAAA,WAAR,SAAmBsB,EAAoB,CAC7B,IAAAnB,EAAe,KAAI,WAC3B,KAAK,WAAa,MAAM,QAAQA,CAAU,GAAKA,EAAW,KAAKmB,CAAM,EAAGnB,GAAcA,EAAa,CAACA,EAAYmB,CAAM,EAAIA,CAC5H,EAMQtB,EAAA,UAAA,cAAR,SAAsBsB,EAAoB,CAChC,IAAAnB,EAAe,KAAI,WACvBA,IAAemB,EACjB,KAAK,WAAa,KACT,MAAM,QAAQnB,CAAU,GACjCoB,GAAUpB,EAAYmB,CAAM,CAEhC,EAgBAtB,EAAA,UAAA,OAAA,SAAOoB,EAAsC,CACnC,IAAAR,EAAgB,KAAI,YAC5BA,GAAeW,GAAUX,EAAaQ,CAAQ,EAE1CA,aAAoBpB,GACtBoB,EAAS,cAAc,IAAI,CAE/B,EAlLcpB,EAAA,MAAS,UAAA,CACrB,IAAMwB,EAAQ,IAAIxB,EAClB,OAAAwB,EAAM,OAAS,GACRA,CACT,EAAE,EA+KJxB,GArLA,EAuLO,IAAMyB,GAAqBC,GAAa,MAEzC,SAAUC,GAAeC,EAAU,CACvC,OACEA,aAAiBF,IAChBE,GAAS,WAAYA,GAASC,EAAWD,EAAM,MAAM,GAAKC,EAAWD,EAAM,GAAG,GAAKC,EAAWD,EAAM,WAAW,CAEpH,CAEA,SAASE,GAAcC,EAAwC,CACzDF,EAAWE,CAAS,EACtBA,EAAS,EAETA,EAAU,YAAW,CAEzB,CChNO,IAAMC,GAAuB,CAClC,iBAAkB,KAClB,sBAAuB,KACvB,QAAS,OACT,sCAAuC,GACvC,yBAA0B,ICGrB,IAAMC,GAAmC,CAG9C,WAAA,SAAWC,EAAqBC,EAAgB,SAAEC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,EAAA,CAAA,EAAA,UAAAA,CAAA,EACxC,IAAAC,EAAaL,GAAe,SACpC,OAAIK,GAAQ,MAARA,EAAU,WACLA,EAAS,WAAU,MAAnBA,EAAQC,EAAA,CAAYL,EAASC,CAAO,EAAAK,EAAKJ,CAAI,CAAA,CAAA,EAE/C,WAAU,MAAA,OAAAG,EAAA,CAACL,EAASC,CAAO,EAAAK,EAAKJ,CAAI,CAAA,CAAA,CAC7C,EACA,aAAA,SAAaK,EAAM,CACT,IAAAH,EAAaL,GAAe,SACpC,QAAQK,GAAQ,KAAA,OAARA,EAAU,eAAgB,cAAcG,CAAa,CAC/D,EACA,SAAU,QCjBN,SAAUC,GAAqBC,EAAQ,CAC3CC,GAAgB,WAAW,UAAA,CACjB,IAAAC,EAAqBC,GAAM,iBACnC,GAAID,EAEFA,EAAiBF,CAAG,MAGpB,OAAMA,CAEV,CAAC,CACH,CCtBM,SAAUI,IAAI,CAAK,CCMlB,IAAMC,GAAyB,UAAA,CAAM,OAAAC,GAAmB,IAAK,OAAW,MAAS,CAA5C,EAAsE,EAO5G,SAAUC,GAAkBC,EAAU,CAC1C,OAAOF,GAAmB,IAAK,OAAWE,CAAK,CACjD,CAOM,SAAUC,GAAoBC,EAAQ,CAC1C,OAAOJ,GAAmB,IAAKI,EAAO,MAAS,CACjD,CAQM,SAAUJ,GAAmBK,EAAuBD,EAAYF,EAAU,CAC9E,MAAO,CACL,KAAIG,EACJ,MAAKD,EACL,MAAKF,EAET,CCrCA,IAAII,GAAuD,KASrD,SAAUC,GAAaC,EAAc,CACzC,GAAIC,GAAO,sCAAuC,CAChD,IAAMC,EAAS,CAACJ,GAKhB,GAJII,IACFJ,GAAU,CAAE,YAAa,GAAO,MAAO,IAAI,GAE7CE,EAAE,EACEE,EAAQ,CACJ,IAAAC,EAAyBL,GAAvBM,EAAWD,EAAA,YAAEE,EAAKF,EAAA,MAE1B,GADAL,GAAU,KACNM,EACF,MAAMC,QAMVL,EAAE,CAEN,CAMM,SAAUM,GAAaC,EAAQ,CAC/BN,GAAO,uCAAyCH,KAClDA,GAAQ,YAAc,GACtBA,GAAQ,MAAQS,EAEpB,CCrBA,IAAAC,GAAA,SAAAC,EAAA,CAAmCC,GAAAF,EAAAC,CAAA,EA6BjC,SAAAD,EAAYG,EAA6C,CAAzD,IAAAC,EACEH,EAAA,KAAA,IAAA,GAAO,KATC,OAAAG,EAAA,UAAqB,GAUzBD,GACFC,EAAK,YAAcD,EAGfE,GAAeF,CAAW,GAC5BA,EAAY,IAAIC,CAAI,GAGtBA,EAAK,YAAcE,IAEvB,CAzBO,OAAAN,EAAA,OAAP,SAAiBO,EAAwBC,EAA2BC,EAAqB,CACvF,OAAO,IAAIC,GAAeH,EAAMC,EAAOC,CAAQ,CACjD,EAgCAT,EAAA,UAAA,KAAA,SAAKW,EAAS,CACR,KAAK,UACPC,GAA0BC,GAAiBF,CAAK,EAAG,IAAI,EAEvD,KAAK,MAAMA,CAAM,CAErB,EASAX,EAAA,UAAA,MAAA,SAAMc,EAAS,CACT,KAAK,UACPF,GAA0BG,GAAkBD,CAAG,EAAG,IAAI,GAEtD,KAAK,UAAY,GACjB,KAAK,OAAOA,CAAG,EAEnB,EAQAd,EAAA,UAAA,SAAA,UAAA,CACM,KAAK,UACPY,GAA0BI,GAAuB,IAAI,GAErD,KAAK,UAAY,GACjB,KAAK,UAAS,EAElB,EAEAhB,EAAA,UAAA,YAAA,UAAA,CACO,KAAK,SACR,KAAK,UAAY,GACjBC,EAAA,UAAM,YAAW,KAAA,IAAA,EACjB,KAAK,YAAc,KAEvB,EAEUD,EAAA,UAAA,MAAV,SAAgBW,EAAQ,CACtB,KAAK,YAAY,KAAKA,CAAK,CAC7B,EAEUX,EAAA,UAAA,OAAV,SAAiBc,EAAQ,CACvB,GAAI,CACF,KAAK,YAAY,MAAMA,CAAG,UAE1B,KAAK,YAAW,EAEpB,EAEUd,EAAA,UAAA,UAAV,UAAA,CACE,GAAI,CACF,KAAK,YAAY,SAAQ,UAEzB,KAAK,YAAW,EAEpB,EACFA,CAAA,EApHmCiB,EAAY,EA2H/C,IAAMC,GAAQ,SAAS,UAAU,KAEjC,SAASC,GAAyCC,EAAQC,EAAY,CACpE,OAAOH,GAAM,KAAKE,EAAIC,CAAO,CAC/B,CAMA,IAAAC,GAAA,UAAA,CACE,SAAAA,EAAoBC,EAAqC,CAArC,KAAA,gBAAAA,CAAwC,CAE5D,OAAAD,EAAA,UAAA,KAAA,SAAKE,EAAQ,CACH,IAAAD,EAAoB,KAAI,gBAChC,GAAIA,EAAgB,KAClB,GAAI,CACFA,EAAgB,KAAKC,CAAK,QACnBC,EAAO,CACdC,GAAqBD,CAAK,EAGhC,EAEAH,EAAA,UAAA,MAAA,SAAMK,EAAQ,CACJ,IAAAJ,EAAoB,KAAI,gBAChC,GAAIA,EAAgB,MAClB,GAAI,CACFA,EAAgB,MAAMI,CAAG,QAClBF,EAAO,CACdC,GAAqBD,CAAK,OAG5BC,GAAqBC,CAAG,CAE5B,EAEAL,EAAA,UAAA,SAAA,UAAA,CACU,IAAAC,EAAoB,KAAI,gBAChC,GAAIA,EAAgB,SAClB,GAAI,CACFA,EAAgB,SAAQ,QACjBE,EAAO,CACdC,GAAqBD,CAAK,EAGhC,EACFH,CAAA,EArCA,EAuCAM,GAAA,SAAAC,EAAA,CAAuCC,GAAAF,EAAAC,CAAA,EACrC,SAAAD,EACEG,EACAN,EACAO,EAA8B,CAHhC,IAAAC,EAKEJ,EAAA,KAAA,IAAA,GAAO,KAEHN,EACJ,GAAIW,EAAWH,CAAc,GAAK,CAACA,EAGjCR,EAAkB,CAChB,KAAOQ,GAAc,KAAdA,EAAkB,OACzB,MAAON,GAAK,KAALA,EAAS,OAChB,SAAUO,GAAQ,KAARA,EAAY,YAEnB,CAEL,IAAIG,EACAF,GAAQG,GAAO,0BAIjBD,EAAU,OAAO,OAAOJ,CAAc,EACtCI,EAAQ,YAAc,UAAA,CAAM,OAAAF,EAAK,YAAW,CAAhB,EAC5BV,EAAkB,CAChB,KAAMQ,EAAe,MAAQZ,GAAKY,EAAe,KAAMI,CAAO,EAC9D,MAAOJ,EAAe,OAASZ,GAAKY,EAAe,MAAOI,CAAO,EACjE,SAAUJ,EAAe,UAAYZ,GAAKY,EAAe,SAAUI,CAAO,IAI5EZ,EAAkBQ,EAMtB,OAAAE,EAAK,YAAc,IAAIX,GAAiBC,CAAe,GACzD,CACF,OAAAK,CAAA,EAzCuCS,EAAU,EA2CjD,SAASC,GAAqBC,EAAU,CAClCC,GAAO,sCACTC,GAAaF,CAAK,EAIlBG,GAAqBH,CAAK,CAE9B,CAQA,SAASI,GAAoBC,EAAQ,CACnC,MAAMA,CACR,CAOA,SAASC,GAA0BC,EAA2CC,EAA2B,CAC/F,IAAAC,EAA0BR,GAAM,sBACxCQ,GAAyBC,GAAgB,WAAW,UAAA,CAAM,OAAAD,EAAsBF,EAAcC,CAAU,CAA9C,CAA+C,CAC3G,CAOO,IAAMG,GAA6D,CACxE,OAAQ,GACR,KAAMC,GACN,MAAOR,GACP,SAAUQ,IC5QL,IAAMC,GAA+B,UAAA,CAAM,OAAC,OAAO,QAAW,YAAc,OAAO,YAAe,cAAvD,EAAsE,ECoClH,SAAUC,GAAYC,EAAI,CAC9B,OAAOA,CACT,CCiCM,SAAUC,IAAI,SAACC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACnB,OAAOC,GAAcF,CAAG,CAC1B,CAGM,SAAUE,GAAoBF,EAA+B,CACjE,OAAIA,EAAI,SAAW,EACVG,GAGLH,EAAI,SAAW,EACVA,EAAI,CAAC,EAGP,SAAeI,EAAQ,CAC5B,OAAOJ,EAAI,OAAO,SAACK,EAAWC,EAAuB,CAAK,OAAAA,EAAGD,CAAI,CAAP,EAAUD,CAAY,CAClF,CACF,CC9EA,IAAAG,EAAA,UAAA,CAkBE,SAAAA,EAAYC,EAA6E,CACnFA,IACF,KAAK,WAAaA,EAEtB,CA4BA,OAAAD,EAAA,UAAA,KAAA,SAAQE,EAAyB,CAC/B,IAAMC,EAAa,IAAIH,EACvB,OAAAG,EAAW,OAAS,KACpBA,EAAW,SAAWD,EACfC,CACT,EA6IAH,EAAA,UAAA,UAAA,SACEI,EACAC,EACAC,EAA8B,CAHhC,IAAAC,EAAA,KAKQC,EAAaC,GAAaL,CAAc,EAAIA,EAAiB,IAAIM,GAAeN,EAAgBC,EAAOC,CAAQ,EAErH,OAAAK,GAAa,UAAA,CACL,IAAAC,EAAuBL,EAArBL,EAAQU,EAAA,SAAEC,EAAMD,EAAA,OACxBJ,EAAW,IACTN,EAGIA,EAAS,KAAKM,EAAYK,CAAM,EAChCA,EAIAN,EAAK,WAAWC,CAAU,EAG1BD,EAAK,cAAcC,CAAU,CAAC,CAEtC,CAAC,EAEMA,CACT,EAGUR,EAAA,UAAA,cAAV,SAAwBc,EAAmB,CACzC,GAAI,CACF,OAAO,KAAK,WAAWA,CAAI,QACpBC,EAAK,CAIZD,EAAK,MAAMC,CAAG,EAElB,EA6DAf,EAAA,UAAA,QAAA,SAAQgB,EAA0BC,EAAoC,CAAtE,IAAAV,EAAA,KACE,OAAAU,EAAcC,GAAeD,CAAW,EAEjC,IAAIA,EAAkB,SAACE,EAASC,EAAM,CAC3C,IAAMZ,EAAa,IAAIE,GAAkB,CACvC,KAAM,SAACW,EAAK,CACV,GAAI,CACFL,EAAKK,CAAK,QACHN,EAAK,CACZK,EAAOL,CAAG,EACVP,EAAW,YAAW,EAE1B,EACA,MAAOY,EACP,SAAUD,EACX,EACDZ,EAAK,UAAUC,CAAU,CAC3B,CAAC,CACH,EAGUR,EAAA,UAAA,WAAV,SAAqBQ,EAA2B,OAC9C,OAAOI,EAAA,KAAK,UAAM,MAAAA,IAAA,OAAA,OAAAA,EAAE,UAAUJ,CAAU,CAC1C,EAOAR,EAAA,UAACG,EAAiB,EAAlB,UAAA,CACE,OAAO,IACT,EA4FAH,EAAA,UAAA,KAAA,UAAA,SAAKsB,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACH,OAAOC,GAAcF,CAAU,EAAE,IAAI,CACvC,EA6BAtB,EAAA,UAAA,UAAA,SAAUiB,EAAoC,CAA9C,IAAAV,EAAA,KACE,OAAAU,EAAcC,GAAeD,CAAW,EAEjC,IAAIA,EAAY,SAACE,EAASC,EAAM,CACrC,IAAIC,EACJd,EAAK,UACH,SAACkB,EAAI,CAAK,OAACJ,EAAQI,CAAT,EACV,SAACV,EAAQ,CAAK,OAAAK,EAAOL,CAAG,CAAV,EACd,UAAA,CAAM,OAAAI,EAAQE,CAAK,CAAb,CAAc,CAExB,CAAC,CACH,EA1aOrB,EAAA,OAAkC,SAAIC,EAAwD,CACnG,OAAO,IAAID,EAAcC,CAAS,CACpC,EAyaFD,GA9cA,EAudA,SAAS0B,GAAeC,EAA+C,OACrE,OAAOC,EAAAD,GAAW,KAAXA,EAAeE,GAAO,WAAO,MAAAD,IAAA,OAAAA,EAAI,OAC1C,CAEA,SAASE,GAAcC,EAAU,CAC/B,OAAOA,GAASC,EAAWD,EAAM,IAAI,GAAKC,EAAWD,EAAM,KAAK,GAAKC,EAAWD,EAAM,QAAQ,CAChG,CAEA,SAASE,GAAgBF,EAAU,CACjC,OAAQA,GAASA,aAAiBG,IAAgBJ,GAAWC,CAAK,GAAKI,GAAeJ,CAAK,CAC7F,CCzeM,SAAUK,GAAQC,EAAW,CACjC,OAAOC,EAAWD,GAAM,KAAA,OAANA,EAAQ,IAAI,CAChC,CAMM,SAAUE,EACdC,EAAqF,CAErF,OAAO,SAACH,EAAqB,CAC3B,GAAID,GAAQC,CAAM,EAChB,OAAOA,EAAO,KAAK,SAA+BI,EAA2B,CAC3E,GAAI,CACF,OAAOD,EAAKC,EAAc,IAAI,QACvBC,EAAK,CACZ,KAAK,MAAMA,CAAG,EAElB,CAAC,EAEH,MAAM,IAAI,UAAU,wCAAwC,CAC9D,CACF,CCjBM,SAAUC,EACdC,EACAC,EACAC,EACAC,EACAC,EAAuB,CAEvB,OAAO,IAAIC,GAAmBL,EAAaC,EAAQC,EAAYC,EAASC,CAAU,CACpF,CAMA,IAAAC,GAAA,SAAAC,EAAA,CAA2CC,GAAAF,EAAAC,CAAA,EAiBzC,SAAAD,EACEL,EACAC,EACAC,EACAC,EACQC,EACAI,EAAiC,CAN3C,IAAAC,EAoBEH,EAAA,KAAA,KAAMN,CAAW,GAAC,KAfV,OAAAS,EAAA,WAAAL,EACAK,EAAA,kBAAAD,EAeRC,EAAK,MAAQR,EACT,SAAuCS,EAAQ,CAC7C,GAAI,CACFT,EAAOS,CAAK,QACLC,EAAK,CACZX,EAAY,MAAMW,CAAG,EAEzB,EACAL,EAAA,UAAM,MACVG,EAAK,OAASN,EACV,SAAuCQ,EAAQ,CAC7C,GAAI,CACFR,EAAQQ,CAAG,QACJA,EAAK,CAEZX,EAAY,MAAMW,CAAG,UAGrB,KAAK,YAAW,EAEpB,EACAL,EAAA,UAAM,OACVG,EAAK,UAAYP,EACb,UAAA,CACE,GAAI,CACFA,EAAU,QACHS,EAAK,CAEZX,EAAY,MAAMW,CAAG,UAGrB,KAAK,YAAW,EAEpB,EACAL,EAAA,UAAM,WACZ,CAEA,OAAAD,EAAA,UAAA,YAAA,UAAA,OACE,GAAI,CAAC,KAAK,mBAAqB,KAAK,kBAAiB,EAAI,CAC/C,IAAAO,EAAW,KAAI,OACvBN,EAAA,UAAM,YAAW,KAAA,IAAA,EAEjB,CAACM,KAAUC,EAAA,KAAK,cAAU,MAAAA,IAAA,QAAAA,EAAA,KAAf,IAAI,GAEnB,EACFR,CAAA,EAnF2CS,EAAU,ECd9C,IAAMC,GAAiD,CAG5D,SAAA,SAASC,EAAQ,CACf,IAAIC,EAAU,sBACVC,EAAkD,qBAC9CC,EAAaJ,GAAsB,SACvCI,IACFF,EAAUE,EAAS,sBACnBD,EAASC,EAAS,sBAEpB,IAAMC,EAASH,EAAQ,SAACI,EAAS,CAI/BH,EAAS,OACTF,EAASK,CAAS,CACpB,CAAC,EACD,OAAO,IAAIC,GAAa,UAAA,CAAM,OAAAJ,GAAM,KAAA,OAANA,EAASE,CAAM,CAAf,CAAgB,CAChD,EACA,sBAAqB,UAAA,SAACG,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACZ,IAAAL,EAAaJ,GAAsB,SAC3C,QAAQI,GAAQ,KAAA,OAARA,EAAU,wBAAyB,uBAAsB,MAAA,OAAAM,EAAA,CAAA,EAAAC,EAAIH,CAAI,CAAA,CAAA,CAC3E,EACA,qBAAoB,UAAA,SAACA,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACX,IAAAL,EAAaJ,GAAsB,SAC3C,QAAQI,GAAQ,KAAA,OAARA,EAAU,uBAAwB,sBAAqB,MAAA,OAAAM,EAAA,CAAA,EAAAC,EAAIH,CAAI,CAAA,CAAA,CACzE,EACA,SAAU,QCrBL,IAAMI,GAAuDC,GAClE,SAACC,EAAM,CACL,OAAA,UAAoC,CAClCA,EAAO,IAAI,EACX,KAAK,KAAO,0BACZ,KAAK,QAAU,qBACjB,CAJA,CAIC,ECXL,IAAAC,EAAA,SAAAC,EAAA,CAAgCC,GAAAF,EAAAC,CAAA,EAwB9B,SAAAD,GAAA,CAAA,IAAAG,EAEEF,EAAA,KAAA,IAAA,GAAO,KAzBT,OAAAE,EAAA,OAAS,GAEDA,EAAA,iBAAyC,KAGjDA,EAAA,UAA2B,CAAA,EAE3BA,EAAA,UAAY,GAEZA,EAAA,SAAW,GAEXA,EAAA,YAAmB,MAenB,CAGA,OAAAH,EAAA,UAAA,KAAA,SAAQI,EAAwB,CAC9B,IAAMC,EAAU,IAAIC,GAAiB,KAAM,IAAI,EAC/C,OAAAD,EAAQ,SAAWD,EACZC,CACT,EAGUL,EAAA,UAAA,eAAV,UAAA,CACE,GAAI,KAAK,OACP,MAAM,IAAIO,EAEd,EAEAP,EAAA,UAAA,KAAA,SAAKQ,EAAQ,CAAb,IAAAL,EAAA,KACEM,GAAa,UAAA,SAEX,GADAN,EAAK,eAAc,EACf,CAACA,EAAK,UAAW,CACdA,EAAK,mBACRA,EAAK,iBAAmB,MAAM,KAAKA,EAAK,SAAS,OAEnD,QAAuBO,EAAAC,GAAAR,EAAK,gBAAgB,EAAAS,EAAAF,EAAA,KAAA,EAAA,CAAAE,EAAA,KAAAA,EAAAF,EAAA,KAAA,EAAE,CAAzC,IAAMG,EAAQD,EAAA,MACjBC,EAAS,KAAKL,CAAK,qGAGzB,CAAC,CACH,EAEAR,EAAA,UAAA,MAAA,SAAMc,EAAQ,CAAd,IAAAX,EAAA,KACEM,GAAa,UAAA,CAEX,GADAN,EAAK,eAAc,EACf,CAACA,EAAK,UAAW,CACnBA,EAAK,SAAWA,EAAK,UAAY,GACjCA,EAAK,YAAcW,EAEnB,QADQC,EAAcZ,EAAI,UACnBY,EAAU,QACfA,EAAU,MAAK,EAAI,MAAMD,CAAG,EAGlC,CAAC,CACH,EAEAd,EAAA,UAAA,SAAA,UAAA,CAAA,IAAAG,EAAA,KACEM,GAAa,UAAA,CAEX,GADAN,EAAK,eAAc,EACf,CAACA,EAAK,UAAW,CACnBA,EAAK,UAAY,GAEjB,QADQY,EAAcZ,EAAI,UACnBY,EAAU,QACfA,EAAU,MAAK,EAAI,SAAQ,EAGjC,CAAC,CACH,EAEAf,EAAA,UAAA,YAAA,UAAA,CACE,KAAK,UAAY,KAAK,OAAS,GAC/B,KAAK,UAAY,KAAK,iBAAmB,IAC3C,EAEA,OAAA,eAAIA,EAAA,UAAA,WAAQ,KAAZ,UAAA,OACE,QAAOgB,EAAA,KAAK,aAAS,MAAAA,IAAA,OAAA,OAAAA,EAAE,QAAS,CAClC,kCAGUhB,EAAA,UAAA,cAAV,SAAwBiB,EAAyB,CAC/C,YAAK,eAAc,EACZhB,EAAA,UAAM,cAAa,KAAA,KAACgB,CAAU,CACvC,EAGUjB,EAAA,UAAA,WAAV,SAAqBiB,EAAyB,CAC5C,YAAK,eAAc,EACnB,KAAK,wBAAwBA,CAAU,EAChC,KAAK,gBAAgBA,CAAU,CACxC,EAGUjB,EAAA,UAAA,gBAAV,SAA0BiB,EAA2B,CAArD,IAAAd,EAAA,KACQa,EAAqC,KAAnCE,EAAQF,EAAA,SAAEG,EAASH,EAAA,UAAED,EAASC,EAAA,UACtC,OAAIE,GAAYC,EACPC,IAET,KAAK,iBAAmB,KACxBL,EAAU,KAAKE,CAAU,EAClB,IAAII,GAAa,UAAA,CACtBlB,EAAK,iBAAmB,KACxBmB,GAAUP,EAAWE,CAAU,CACjC,CAAC,EACH,EAGUjB,EAAA,UAAA,wBAAV,SAAkCiB,EAA2B,CACrD,IAAAD,EAAuC,KAArCE,EAAQF,EAAA,SAAEO,EAAWP,EAAA,YAAEG,EAASH,EAAA,UACpCE,EACFD,EAAW,MAAMM,CAAW,EACnBJ,GACTF,EAAW,SAAQ,CAEvB,EAQAjB,EAAA,UAAA,aAAA,UAAA,CACE,IAAMwB,EAAkB,IAAIC,EAC5B,OAAAD,EAAW,OAAS,KACbA,CACT,EAxHOxB,EAAA,OAAkC,SAAI0B,EAA0BC,EAAqB,CAC1F,OAAO,IAAIrB,GAAoBoB,EAAaC,CAAM,CACpD,EAuHF3B,GA7IgCyB,CAAU,EAkJ1C,IAAAG,GAAA,SAAAC,EAAA,CAAyCC,GAAAF,EAAAC,CAAA,EACvC,SAAAD,EAESG,EACPC,EAAsB,CAHxB,IAAAC,EAKEJ,EAAA,KAAA,IAAA,GAAO,KAHA,OAAAI,EAAA,YAAAF,EAIPE,EAAK,OAASD,GAChB,CAEA,OAAAJ,EAAA,UAAA,KAAA,SAAKM,EAAQ,UACXC,GAAAC,EAAA,KAAK,eAAW,MAAAA,IAAA,OAAA,OAAAA,EAAE,QAAI,MAAAD,IAAA,QAAAA,EAAA,KAAAC,EAAGF,CAAK,CAChC,EAEAN,EAAA,UAAA,MAAA,SAAMS,EAAQ,UACZF,GAAAC,EAAA,KAAK,eAAW,MAAAA,IAAA,OAAA,OAAAA,EAAE,SAAK,MAAAD,IAAA,QAAAA,EAAA,KAAAC,EAAGC,CAAG,CAC/B,EAEAT,EAAA,UAAA,SAAA,UAAA,UACEO,GAAAC,EAAA,KAAK,eAAW,MAAAA,IAAA,OAAA,OAAAA,EAAE,YAAQ,MAAAD,IAAA,QAAAA,EAAA,KAAAC,CAAA,CAC5B,EAGUR,EAAA,UAAA,WAAV,SAAqBU,EAAyB,SAC5C,OAAOH,GAAAC,EAAA,KAAK,UAAM,MAAAA,IAAA,OAAA,OAAAA,EAAE,UAAUE,CAAU,KAAC,MAAAH,IAAA,OAAAA,EAAII,EAC/C,EACFX,CAAA,EA1ByCY,CAAO,ECxJhD,IAAAC,GAAA,SAAAC,EAAA,CAAwCC,GAAAF,EAAAC,CAAA,EACtC,SAAAD,EAAoBG,EAAS,CAA7B,IAAAC,EACEH,EAAA,KAAA,IAAA,GAAO,KADW,OAAAG,EAAA,OAAAD,GAEpB,CAEA,cAAA,eAAIH,EAAA,UAAA,QAAK,KAAT,UAAA,CACE,OAAO,KAAK,SAAQ,CACtB,kCAGUA,EAAA,UAAA,WAAV,SAAqBK,EAAyB,CAC5C,IAAMC,EAAeL,EAAA,UAAM,WAAU,KAAA,KAACI,CAAU,EAChD,OAACC,EAAa,QAAUD,EAAW,KAAK,KAAK,MAAM,EAC5CC,CACT,EAEAN,EAAA,UAAA,SAAA,UAAA,CACQ,IAAAO,EAAoC,KAAlCC,EAAQD,EAAA,SAAEE,EAAWF,EAAA,YAAEJ,EAAMI,EAAA,OACrC,GAAIC,EACF,MAAMC,EAER,YAAK,eAAc,EACZN,CACT,EAEAH,EAAA,UAAA,KAAA,SAAKU,EAAQ,CACXT,EAAA,UAAM,KAAI,KAAA,KAAE,KAAK,OAASS,CAAM,CAClC,EACFV,CAAA,EA5BwCW,CAAO,ECJxC,IAAMC,GAA+C,CAC1D,IAAG,UAAA,CAGD,OAAQA,GAAsB,UAAY,MAAM,IAAG,CACrD,EACA,SAAU,QCwBZ,IAAAC,GAAA,SAAAC,EAAA,CAAsCC,GAAAF,EAAAC,CAAA,EAUpC,SAAAD,EACUG,EACAC,EACAC,EAA6D,CAF7DF,IAAA,SAAAA,EAAA,KACAC,IAAA,SAAAA,EAAA,KACAC,IAAA,SAAAA,EAAAC,IAHV,IAAAC,EAKEN,EAAA,KAAA,IAAA,GAAO,KAJC,OAAAM,EAAA,YAAAJ,EACAI,EAAA,YAAAH,EACAG,EAAA,mBAAAF,EAZFE,EAAA,QAA0B,CAAA,EAC1BA,EAAA,oBAAsB,GAc5BA,EAAK,oBAAsBH,IAAgB,IAC3CG,EAAK,YAAc,KAAK,IAAI,EAAGJ,CAAW,EAC1CI,EAAK,YAAc,KAAK,IAAI,EAAGH,CAAW,GAC5C,CAEA,OAAAJ,EAAA,UAAA,KAAA,SAAKQ,EAAQ,CACL,IAAAC,EAA+E,KAA7EC,EAASD,EAAA,UAAEE,EAAOF,EAAA,QAAEG,EAAmBH,EAAA,oBAAEJ,EAAkBI,EAAA,mBAAEL,EAAWK,EAAA,YAC3EC,IACHC,EAAQ,KAAKH,CAAK,EAClB,CAACI,GAAuBD,EAAQ,KAAKN,EAAmB,IAAG,EAAKD,CAAW,GAE7E,KAAK,YAAW,EAChBH,EAAA,UAAM,KAAI,KAAA,KAACO,CAAK,CAClB,EAGUR,EAAA,UAAA,WAAV,SAAqBa,EAAyB,CAC5C,KAAK,eAAc,EACnB,KAAK,YAAW,EAQhB,QANMC,EAAe,KAAK,gBAAgBD,CAAU,EAE9CJ,EAAmC,KAAjCG,EAAmBH,EAAA,oBAAEE,EAAOF,EAAA,QAG9BM,EAAOJ,EAAQ,MAAK,EACjBK,EAAI,EAAGA,EAAID,EAAK,QAAU,CAACF,EAAW,OAAQG,GAAKJ,EAAsB,EAAI,EACpFC,EAAW,KAAKE,EAAKC,CAAC,CAAM,EAG9B,YAAK,wBAAwBH,CAAU,EAEhCC,CACT,EAEQd,EAAA,UAAA,YAAR,UAAA,CACQ,IAAAS,EAAoE,KAAlEN,EAAWM,EAAA,YAAEJ,EAAkBI,EAAA,mBAAEE,EAAOF,EAAA,QAAEG,EAAmBH,EAAA,oBAK/DQ,GAAsBL,EAAsB,EAAI,GAAKT,EAK3D,GAJAA,EAAc,KAAYc,EAAqBN,EAAQ,QAAUA,EAAQ,OAAO,EAAGA,EAAQ,OAASM,CAAkB,EAIlH,CAACL,EAAqB,CAKxB,QAJMM,EAAMb,EAAmB,IAAG,EAC9Bc,EAAO,EAGFH,EAAI,EAAGA,EAAIL,EAAQ,QAAWA,EAAQK,CAAC,GAAgBE,EAAKF,GAAK,EACxEG,EAAOH,EAETG,GAAQR,EAAQ,OAAO,EAAGQ,EAAO,CAAC,EAEtC,EACFnB,CAAA,EAzEsCoB,CAAO,EClB7C,IAAAC,GAAA,SAAAC,EAAA,CAA+BC,GAAAF,EAAAC,CAAA,EAC7B,SAAAD,EAAYG,EAAsBC,EAAmD,QACnFH,EAAA,KAAA,IAAA,GAAO,IACT,CAWO,OAAAD,EAAA,UAAA,SAAP,SAAgBK,EAAWC,EAAiB,CAAjB,OAAAA,IAAA,SAAAA,EAAA,GAClB,IACT,EACFN,CAAA,EAjB+BO,EAAY,ECHpC,IAAMC,GAAqC,CAGhD,YAAA,SAAYC,EAAqBC,EAAgB,SAAEC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,EAAA,CAAA,EAAA,UAAAA,CAAA,EACzC,IAAAC,EAAaL,GAAgB,SACrC,OAAIK,GAAQ,MAARA,EAAU,YACLA,EAAS,YAAW,MAApBA,EAAQC,EAAA,CAAaL,EAASC,CAAO,EAAAK,EAAKJ,CAAI,CAAA,CAAA,EAEhD,YAAW,MAAA,OAAAG,EAAA,CAACL,EAASC,CAAO,EAAAK,EAAKJ,CAAI,CAAA,CAAA,CAC9C,EACA,cAAA,SAAcK,EAAM,CACV,IAAAH,EAAaL,GAAgB,SACrC,QAAQK,GAAQ,KAAA,OAARA,EAAU,gBAAiB,eAAeG,CAAa,CACjE,EACA,SAAU,QCrBZ,IAAAC,GAAA,SAAAC,EAAA,CAAoCC,GAAAF,EAAAC,CAAA,EAOlC,SAAAD,EAAsBG,EAAqCC,EAAmD,CAA9G,IAAAC,EACEJ,EAAA,KAAA,KAAME,EAAWC,CAAI,GAAC,KADF,OAAAC,EAAA,UAAAF,EAAqCE,EAAA,KAAAD,EAFjDC,EAAA,QAAmB,IAI7B,CAEO,OAAAL,EAAA,UAAA,SAAP,SAAgBM,EAAWC,EAAiB,OAC1C,GADyBA,IAAA,SAAAA,EAAA,GACrB,KAAK,OACP,OAAO,KAIT,KAAK,MAAQD,EAEb,IAAME,EAAK,KAAK,GACVL,EAAY,KAAK,UAuBvB,OAAIK,GAAM,OACR,KAAK,GAAK,KAAK,eAAeL,EAAWK,EAAID,CAAK,GAKpD,KAAK,QAAU,GAEf,KAAK,MAAQA,EAEb,KAAK,IAAKE,EAAA,KAAK,MAAE,MAAAA,IAAA,OAAAA,EAAI,KAAK,eAAeN,EAAW,KAAK,GAAII,CAAK,EAE3D,IACT,EAEUP,EAAA,UAAA,eAAV,SAAyBG,EAA2BO,EAAmBH,EAAiB,CAAjB,OAAAA,IAAA,SAAAA,EAAA,GAC9DI,GAAiB,YAAYR,EAAU,MAAM,KAAKA,EAAW,IAAI,EAAGI,CAAK,CAClF,EAEUP,EAAA,UAAA,eAAV,SAAyBY,EAA4BJ,EAAkBD,EAAwB,CAE7F,GAFqEA,IAAA,SAAAA,EAAA,GAEjEA,GAAS,MAAQ,KAAK,QAAUA,GAAS,KAAK,UAAY,GAC5D,OAAOC,EAILA,GAAM,MACRG,GAAiB,cAAcH,CAAE,CAIrC,EAMOR,EAAA,UAAA,QAAP,SAAeM,EAAUC,EAAa,CACpC,GAAI,KAAK,OACP,OAAO,IAAI,MAAM,8BAA8B,EAGjD,KAAK,QAAU,GACf,IAAMM,EAAQ,KAAK,SAASP,EAAOC,CAAK,EACxC,GAAIM,EACF,OAAOA,EACE,KAAK,UAAY,IAAS,KAAK,IAAM,OAc9C,KAAK,GAAK,KAAK,eAAe,KAAK,UAAW,KAAK,GAAI,IAAI,EAE/D,EAEUb,EAAA,UAAA,SAAV,SAAmBM,EAAUQ,EAAc,CACzC,IAAIC,EAAmB,GACnBC,EACJ,GAAI,CACF,KAAK,KAAKV,CAAK,QACRW,EAAG,CACVF,EAAU,GAIVC,EAAaC,GAAQ,IAAI,MAAM,oCAAoC,EAErE,GAAIF,EACF,YAAK,YAAW,EACTC,CAEX,EAEAhB,EAAA,UAAA,YAAA,UAAA,CACE,GAAI,CAAC,KAAK,OAAQ,CACV,IAAAS,EAAoB,KAAlBD,EAAEC,EAAA,GAAEN,EAASM,EAAA,UACbS,EAAYf,EAAS,QAE7B,KAAK,KAAO,KAAK,MAAQ,KAAK,UAAY,KAC1C,KAAK,QAAU,GAEfgB,GAAUD,EAAS,IAAI,EACnBV,GAAM,OACR,KAAK,GAAK,KAAK,eAAeL,EAAWK,EAAI,IAAI,GAGnD,KAAK,MAAQ,KACbP,EAAA,UAAM,YAAW,KAAA,IAAA,EAErB,EACFD,CAAA,EA9IoCoB,EAAM,ECgB1C,IAAAC,GAAA,UAAA,CAGE,SAAAA,EAAoBC,EAAoCC,EAAiC,CAAjCA,IAAA,SAAAA,EAAoBF,EAAU,KAAlE,KAAA,oBAAAC,EAClB,KAAK,IAAMC,CACb,CA6BO,OAAAF,EAAA,UAAA,SAAP,SAAmBG,EAAqDC,EAAmBC,EAAS,CAA5B,OAAAD,IAAA,SAAAA,EAAA,GAC/D,IAAI,KAAK,oBAAuB,KAAMD,CAAI,EAAE,SAASE,EAAOD,CAAK,CAC1E,EAnCcJ,EAAA,IAAoBM,GAAsB,IAoC1DN,GArCA,ECnBA,IAAAO,GAAA,SAAAC,EAAA,CAAoCC,GAAAF,EAAAC,CAAA,EAkBlC,SAAAD,EAAYG,EAAgCC,EAAiC,CAAjCA,IAAA,SAAAA,EAAoBC,GAAU,KAA1E,IAAAC,EACEL,EAAA,KAAA,KAAME,EAAiBC,CAAG,GAAC,KAlBtB,OAAAE,EAAA,QAAmC,CAAA,EAOnCA,EAAA,QAAmB,IAY1B,CAEO,OAAAN,EAAA,UAAA,MAAP,SAAaO,EAAwB,CAC3B,IAAAC,EAAY,KAAI,QAExB,GAAI,KAAK,QAAS,CAChBA,EAAQ,KAAKD,CAAM,EACnB,OAGF,IAAIE,EACJ,KAAK,QAAU,GAEf,EACE,IAAKA,EAAQF,EAAO,QAAQA,EAAO,MAAOA,EAAO,KAAK,EACpD,YAEMA,EAASC,EAAQ,MAAK,GAIhC,GAFA,KAAK,QAAU,GAEXC,EAAO,CACT,KAAQF,EAASC,EAAQ,MAAK,GAC5BD,EAAO,YAAW,EAEpB,MAAME,EAEV,EACFT,CAAA,EAhDoCK,EAAS,EC6CtC,IAAMK,GAAiB,IAAIC,GAAeC,EAAW,EAK/CC,GAAQH,GCjDrB,IAAAI,GAAA,SAAAC,EAAA,CAAoCC,GAAAF,EAAAC,CAAA,EAClC,SAAAD,EAAsBG,EAAqCC,EAAmD,CAA9G,IAAAC,EACEJ,EAAA,KAAA,KAAME,EAAWC,CAAI,GAAC,KADF,OAAAC,EAAA,UAAAF,EAAqCE,EAAA,KAAAD,GAE3D,CAEO,OAAAJ,EAAA,UAAA,SAAP,SAAgBM,EAAWC,EAAiB,CAC1C,OADyBA,IAAA,SAAAA,EAAA,GACrBA,EAAQ,EACHN,EAAA,UAAM,SAAQ,KAAA,KAACK,EAAOC,CAAK,GAEpC,KAAK,MAAQA,EACb,KAAK,MAAQD,EACb,KAAK,UAAU,MAAM,IAAI,EAClB,KACT,EAEON,EAAA,UAAA,QAAP,SAAeM,EAAUC,EAAa,CACpC,OAAOA,EAAQ,GAAK,KAAK,OAASN,EAAA,UAAM,QAAO,KAAA,KAACK,EAAOC,CAAK,EAAI,KAAK,SAASD,EAAOC,CAAK,CAC5F,EAEUP,EAAA,UAAA,eAAV,SAAyBG,EAA2BK,EAAkBD,EAAiB,CAKrF,OALoEA,IAAA,SAAAA,EAAA,GAK/DA,GAAS,MAAQA,EAAQ,GAAOA,GAAS,MAAQ,KAAK,MAAQ,EAC1DN,EAAA,UAAM,eAAc,KAAA,KAACE,EAAWK,EAAID,CAAK,GAIlDJ,EAAU,MAAM,IAAI,EAMb,EACT,EACFH,CAAA,EArCoCS,EAAW,ECJ/C,IAAAC,GAAA,SAAAC,EAAA,CAAoCC,GAAAF,EAAAC,CAAA,EAApC,SAAAD,GAAA,+CACA,CAAA,OAAAA,CAAA,EADoCG,EAAc,ECgE3C,IAAMC,GAAiB,IAAIC,GAAeC,EAAW,EC5D5D,IAAAC,GAAA,SAAAC,EAAA,CAA6CC,GAAAF,EAAAC,CAAA,EAC3C,SAAAD,EAAsBG,EAA8CC,EAAmD,CAAvH,IAAAC,EACEJ,EAAA,KAAA,KAAME,EAAWC,CAAI,GAAC,KADF,OAAAC,EAAA,UAAAF,EAA8CE,EAAA,KAAAD,GAEpE,CAEU,OAAAJ,EAAA,UAAA,eAAV,SAAyBG,EAAoCG,EAAkBC,EAAiB,CAE9F,OAF6EA,IAAA,SAAAA,EAAA,GAEzEA,IAAU,MAAQA,EAAQ,EACrBN,EAAA,UAAM,eAAc,KAAA,KAACE,EAAWG,EAAIC,CAAK,GAGlDJ,EAAU,QAAQ,KAAK,IAAI,EAIpBA,EAAU,aAAeA,EAAU,WAAaK,GAAuB,sBAAsB,UAAA,CAAM,OAAAL,EAAU,MAAM,MAAS,CAAzB,CAA0B,GACtI,EAEUH,EAAA,UAAA,eAAV,SAAyBG,EAAoCG,EAAkBC,EAAiB,OAI9F,GAJ6EA,IAAA,SAAAA,EAAA,GAIzEA,GAAS,KAAOA,EAAQ,EAAI,KAAK,MAAQ,EAC3C,OAAON,EAAA,UAAM,eAAc,KAAA,KAACE,EAAWG,EAAIC,CAAK,EAK1C,IAAAE,EAAYN,EAAS,QACzBG,GAAM,QAAQI,EAAAD,EAAQA,EAAQ,OAAS,CAAC,KAAC,MAAAC,IAAA,OAAA,OAAAA,EAAE,MAAOJ,IACpDE,GAAuB,qBAAqBF,CAAY,EACxDH,EAAU,WAAa,OAI3B,EACFH,CAAA,EApC6CW,EAAW,ECHxD,IAAAC,GAAA,SAAAC,EAAA,CAA6CC,GAAAF,EAAAC,CAAA,EAA7C,SAAAD,GAAA,+CAkCA,CAjCS,OAAAA,EAAA,UAAA,MAAP,SAAaG,EAAyB,CACpC,KAAK,QAAU,GAUf,IAAMC,EAAU,KAAK,WACrB,KAAK,WAAa,OAEV,IAAAC,EAAY,KAAI,QACpBC,EACJH,EAASA,GAAUE,EAAQ,MAAK,EAEhC,EACE,IAAKC,EAAQH,EAAO,QAAQA,EAAO,MAAOA,EAAO,KAAK,EACpD,aAEMA,EAASE,EAAQ,CAAC,IAAMF,EAAO,KAAOC,GAAWC,EAAQ,MAAK,GAIxE,GAFA,KAAK,QAAU,GAEXC,EAAO,CACT,MAAQH,EAASE,EAAQ,CAAC,IAAMF,EAAO,KAAOC,GAAWC,EAAQ,MAAK,GACpEF,EAAO,YAAW,EAEpB,MAAMG,EAEV,EACFN,CAAA,EAlC6CO,EAAc,ECgCpD,IAAMC,GAA0B,IAAIC,GAAwBC,EAAoB,EC8BhF,IAAMC,EAAQ,IAAIC,EAAkB,SAACC,EAAU,CAAK,OAAAA,EAAW,SAAQ,CAAnB,CAAqB,EC9D1E,SAAUC,GAAYC,EAAU,CACpC,OAAOA,GAASC,EAAWD,EAAM,QAAQ,CAC3C,CCDA,SAASE,GAAQC,EAAQ,CACvB,OAAOA,EAAIA,EAAI,OAAS,CAAC,CAC3B,CAEM,SAAUC,GAAkBC,EAAW,CAC3C,OAAOC,EAAWJ,GAAKG,CAAI,CAAC,EAAIA,EAAK,IAAG,EAAK,MAC/C,CAEM,SAAUE,GAAaF,EAAW,CACtC,OAAOG,GAAYN,GAAKG,CAAI,CAAC,EAAIA,EAAK,IAAG,EAAK,MAChD,CAEM,SAAUI,GAAUJ,EAAaK,EAAoB,CACzD,OAAO,OAAOR,GAAKG,CAAI,GAAM,SAAWA,EAAK,IAAG,EAAMK,CACxD,CClBO,IAAMC,GAAe,SAAIC,EAAM,CAAwB,OAAAA,GAAK,OAAOA,EAAE,QAAW,UAAY,OAAOA,GAAM,UAAlD,ECMxD,SAAUC,GAAUC,EAAU,CAClC,OAAOC,EAAWD,GAAK,KAAA,OAALA,EAAO,IAAI,CAC/B,CCHM,SAAUE,GAAoBC,EAAU,CAC5C,OAAOC,EAAWD,EAAME,EAAiB,CAAC,CAC5C,CCLM,SAAUC,GAAmBC,EAAQ,CACzC,OAAO,OAAO,eAAiBC,EAAWD,GAAG,KAAA,OAAHA,EAAM,OAAO,aAAa,CAAC,CACvE,CCAM,SAAUE,GAAiCC,EAAU,CAEzD,OAAO,IAAI,UACT,iBACEA,IAAU,MAAQ,OAAOA,GAAU,SAAW,oBAAsB,IAAIA,EAAK,KAAG,0HACwC,CAE9H,CCXM,SAAUC,IAAiB,CAC/B,OAAI,OAAO,QAAW,YAAc,CAAC,OAAO,SACnC,aAGF,OAAO,QAChB,CAEO,IAAMC,GAAWD,GAAiB,ECJnC,SAAUE,GAAWC,EAAU,CACnC,OAAOC,EAAWD,GAAK,KAAA,OAALA,EAAQE,EAAe,CAAC,CAC5C,CCHM,SAAiBC,GAAsCC,EAAqC,mGAC1FC,EAASD,EAAe,UAAS,2DAGX,MAAA,CAAA,EAAAE,GAAMD,EAAO,KAAI,CAAE,CAAA,gBAArCE,EAAkBC,EAAA,KAAA,EAAhBC,EAAKF,EAAA,MAAEG,EAAIH,EAAA,KACfG,iBAAA,CAAA,EAAA,CAAA,SACF,MAAA,CAAA,EAAAF,EAAA,KAAA,CAAA,qBAEIC,CAAM,CAAA,SAAZ,MAAA,CAAA,EAAAD,EAAA,KAAA,CAAA,SAAA,OAAAA,EAAA,KAAA,mCAGF,OAAAH,EAAO,YAAW,6BAIhB,SAAUM,GAAwBC,EAAQ,CAG9C,OAAOC,EAAWD,GAAG,KAAA,OAAHA,EAAK,SAAS,CAClC,CCPM,SAAUE,EAAaC,EAAyB,CACpD,GAAIA,aAAiBC,EACnB,OAAOD,EAET,GAAIA,GAAS,KAAM,CACjB,GAAIE,GAAoBF,CAAK,EAC3B,OAAOG,GAAsBH,CAAK,EAEpC,GAAII,GAAYJ,CAAK,EACnB,OAAOK,GAAcL,CAAK,EAE5B,GAAIM,GAAUN,CAAK,EACjB,OAAOO,GAAYP,CAAK,EAE1B,GAAIQ,GAAgBR,CAAK,EACvB,OAAOS,GAAkBT,CAAK,EAEhC,GAAIU,GAAWV,CAAK,EAClB,OAAOW,GAAaX,CAAK,EAE3B,GAAIY,GAAqBZ,CAAK,EAC5B,OAAOa,GAAuBb,CAAK,EAIvC,MAAMc,GAAiCd,CAAK,CAC9C,CAMM,SAAUG,GAAyBY,EAAQ,CAC/C,OAAO,IAAId,EAAW,SAACe,EAAyB,CAC9C,IAAMC,EAAMF,EAAIG,EAAiB,EAAC,EAClC,GAAIC,EAAWF,EAAI,SAAS,EAC1B,OAAOA,EAAI,UAAUD,CAAU,EAGjC,MAAM,IAAI,UAAU,gEAAgE,CACtF,CAAC,CACH,CASM,SAAUX,GAAiBe,EAAmB,CAClD,OAAO,IAAInB,EAAW,SAACe,EAAyB,CAU9C,QAASK,EAAI,EAAGA,EAAID,EAAM,QAAU,CAACJ,EAAW,OAAQK,IACtDL,EAAW,KAAKI,EAAMC,CAAC,CAAC,EAE1BL,EAAW,SAAQ,CACrB,CAAC,CACH,CAEM,SAAUT,GAAee,EAAuB,CACpD,OAAO,IAAIrB,EAAW,SAACe,EAAyB,CAC9CM,EACG,KACC,SAACC,EAAK,CACCP,EAAW,SACdA,EAAW,KAAKO,CAAK,EACrBP,EAAW,SAAQ,EAEvB,EACA,SAACQ,EAAQ,CAAK,OAAAR,EAAW,MAAMQ,CAAG,CAApB,CAAqB,EAEpC,KAAK,KAAMC,EAAoB,CACpC,CAAC,CACH,CAEM,SAAUd,GAAgBe,EAAqB,CACnD,OAAO,IAAIzB,EAAW,SAACe,EAAyB,aAC9C,QAAoBW,EAAAC,GAAAF,CAAQ,EAAAG,EAAAF,EAAA,KAAA,EAAA,CAAAE,EAAA,KAAAA,EAAAF,EAAA,KAAA,EAAE,CAAzB,IAAMJ,EAAKM,EAAA,MAEd,GADAb,EAAW,KAAKO,CAAK,EACjBP,EAAW,OACb,yGAGJA,EAAW,SAAQ,CACrB,CAAC,CACH,CAEM,SAAUP,GAAqBqB,EAA+B,CAClE,OAAO,IAAI7B,EAAW,SAACe,EAAyB,CAC9Ce,GAAQD,EAAed,CAAU,EAAE,MAAM,SAACQ,EAAG,CAAK,OAAAR,EAAW,MAAMQ,CAAG,CAApB,CAAqB,CACzE,CAAC,CACH,CAEM,SAAUX,GAA0BmB,EAAqC,CAC7E,OAAOvB,GAAkBwB,GAAmCD,CAAc,CAAC,CAC7E,CAEA,SAAeD,GAAWD,EAAiCd,EAAyB,uIACxDkB,EAAAC,GAAAL,CAAa,gFAIrC,GAJeP,EAAKa,EAAA,MACpBpB,EAAW,KAAKO,CAAK,EAGjBP,EAAW,OACb,MAAA,CAAA,CAAA,6RAGJ,OAAAA,EAAW,SAAQ,WChHf,SAAUqB,GACdC,EACAC,EACAC,EACAC,EACAC,EAAc,CADdD,IAAA,SAAAA,EAAA,GACAC,IAAA,SAAAA,EAAA,IAEA,IAAMC,EAAuBJ,EAAU,SAAS,UAAA,CAC9CC,EAAI,EACAE,EACFJ,EAAmB,IAAI,KAAK,SAAS,KAAMG,CAAK,CAAC,EAEjD,KAAK,YAAW,CAEpB,EAAGA,CAAK,EAIR,GAFAH,EAAmB,IAAIK,CAAoB,EAEvC,CAACD,EAKH,OAAOC,CAEX,CCeM,SAAUC,GAAaC,EAA0BC,EAAS,CAAT,OAAAA,IAAA,SAAAA,EAAA,GAC9CC,EAAQ,SAACC,EAAQC,EAAU,CAChCD,EAAO,UACLE,EACED,EACA,SAACE,EAAK,CAAK,OAAAC,GAAgBH,EAAYJ,EAAW,UAAA,CAAM,OAAAI,EAAW,KAAKE,CAAK,CAArB,EAAwBL,CAAK,CAA1E,EACX,UAAA,CAAM,OAAAM,GAAgBH,EAAYJ,EAAW,UAAA,CAAM,OAAAI,EAAW,SAAQ,CAAnB,EAAuBH,CAAK,CAAzE,EACN,SAACO,EAAG,CAAK,OAAAD,GAAgBH,EAAYJ,EAAW,UAAA,CAAM,OAAAI,EAAW,MAAMI,CAAG,CAApB,EAAuBP,CAAK,CAAzE,CAA0E,CACpF,CAEL,CAAC,CACH,CCPM,SAAUQ,GAAeC,EAA0BC,EAAiB,CAAjB,OAAAA,IAAA,SAAAA,EAAA,GAChDC,EAAQ,SAACC,EAAQC,EAAU,CAChCA,EAAW,IAAIJ,EAAU,SAAS,UAAA,CAAM,OAAAG,EAAO,UAAUC,CAAU,CAA3B,EAA8BH,CAAK,CAAC,CAC9E,CAAC,CACH,CC7DM,SAAUI,GAAsBC,EAA6BC,EAAwB,CACzF,OAAOC,EAAUF,CAAK,EAAE,KAAKG,GAAYF,CAAS,EAAGG,GAAUH,CAAS,CAAC,CAC3E,CCFM,SAAUI,GAAmBC,EAAuBC,EAAwB,CAChF,OAAOC,EAAUF,CAAK,EAAE,KAAKG,GAAYF,CAAS,EAAGG,GAAUH,CAAS,CAAC,CAC3E,CCJM,SAAUI,GAAiBC,EAAqBC,EAAwB,CAC5E,OAAO,IAAIC,EAAc,SAACC,EAAU,CAElC,IAAIC,EAAI,EAER,OAAOH,EAAU,SAAS,UAAA,CACpBG,IAAMJ,EAAM,OAGdG,EAAW,SAAQ,GAInBA,EAAW,KAAKH,EAAMI,GAAG,CAAC,EAIrBD,EAAW,QACd,KAAK,SAAQ,EAGnB,CAAC,CACH,CAAC,CACH,CCfM,SAAUE,GAAoBC,EAAoBC,EAAwB,CAC9E,OAAO,IAAIC,EAAc,SAACC,EAAU,CAClC,IAAIC,EAKJ,OAAAC,GAAgBF,EAAYF,EAAW,UAAA,CAErCG,EAAYJ,EAAcI,EAAe,EAAC,EAE1CC,GACEF,EACAF,EACA,UAAA,OACMK,EACAC,EACJ,GAAI,CAEDC,EAAkBJ,EAAS,KAAI,EAA7BE,EAAKE,EAAA,MAAED,EAAIC,EAAA,WACPC,EAAK,CAEZN,EAAW,MAAMM,CAAG,EACpB,OAGEF,EAKFJ,EAAW,SAAQ,EAGnBA,EAAW,KAAKG,CAAK,CAEzB,EACA,EACA,EAAI,CAER,CAAC,EAMM,UAAA,CAAM,OAAAI,EAAWN,GAAQ,KAAA,OAARA,EAAU,MAAM,GAAKA,EAAS,OAAM,CAA/C,CACf,CAAC,CACH,CCvDM,SAAUO,GAAyBC,EAAyBC,EAAwB,CACxF,GAAI,CAACD,EACH,MAAM,IAAI,MAAM,yBAAyB,EAE3C,OAAO,IAAIE,EAAc,SAACC,EAAU,CAClCC,GAAgBD,EAAYF,EAAW,UAAA,CACrC,IAAMI,EAAWL,EAAM,OAAO,aAAa,EAAC,EAC5CI,GACED,EACAF,EACA,UAAA,CACEI,EAAS,KAAI,EAAG,KAAK,SAACC,EAAM,CACtBA,EAAO,KAGTH,EAAW,SAAQ,EAEnBA,EAAW,KAAKG,EAAO,KAAK,CAEhC,CAAC,CACH,EACA,EACA,EAAI,CAER,CAAC,CACH,CAAC,CACH,CCzBM,SAAUC,GAA8BC,EAA8BC,EAAwB,CAClG,OAAOC,GAAsBC,GAAmCH,CAAK,EAAGC,CAAS,CACnF,CCoBM,SAAUG,GAAaC,EAA2BC,EAAwB,CAC9E,GAAID,GAAS,KAAM,CACjB,GAAIE,GAAoBF,CAAK,EAC3B,OAAOG,GAAmBH,EAAOC,CAAS,EAE5C,GAAIG,GAAYJ,CAAK,EACnB,OAAOK,GAAcL,EAAOC,CAAS,EAEvC,GAAIK,GAAUN,CAAK,EACjB,OAAOO,GAAgBP,EAAOC,CAAS,EAEzC,GAAIO,GAAgBR,CAAK,EACvB,OAAOS,GAAsBT,EAAOC,CAAS,EAE/C,GAAIS,GAAWV,CAAK,EAClB,OAAOW,GAAiBX,EAAOC,CAAS,EAE1C,GAAIW,GAAqBZ,CAAK,EAC5B,OAAOa,GAA2Bb,EAAOC,CAAS,EAGtD,MAAMa,GAAiCd,CAAK,CAC9C,CCoDM,SAAUe,GAAQC,EAA2BC,EAAyB,CAC1E,OAAOA,EAAYC,GAAUF,EAAOC,CAAS,EAAIE,EAAUH,CAAK,CAClE,CCxBM,SAAUI,GAAE,SAAIC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACpB,IAAMC,EAAYC,GAAaH,CAAI,EACnC,OAAOI,GAAKJ,EAAaE,CAAS,CACpC,CCsCM,SAAUG,GAAWC,EAA0BC,EAAyB,CAC5E,IAAMC,EAAeC,EAAWH,CAAmB,EAAIA,EAAsB,UAAA,CAAM,OAAAA,CAAA,EAC7EI,EAAO,SAACC,EAA6B,CAAK,OAAAA,EAAW,MAAMH,EAAY,CAAE,CAA/B,EAChD,OAAO,IAAII,EAAWL,EAAY,SAACI,EAAU,CAAK,OAAAJ,EAAU,SAASG,EAAa,EAAGC,CAAU,CAA7C,EAAiDD,CAAI,CACzG,CCpGO,IAAMG,GAA6BC,GAAiB,SAACC,EAAM,CAAK,OAAA,UAAuB,CAC5FA,EAAO,IAAI,EACX,KAAK,KAAO,aACZ,KAAK,QAAU,yBACjB,CAJuE,CAItE,ECrBK,SAAUC,GAAYC,EAAU,CACpC,OAAOA,aAAiB,MAAQ,CAAC,MAAMA,CAAY,CACrD,CCsCM,SAAUC,EAAUC,EAAyCC,EAAa,CAC9E,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAEhC,IAAIC,EAAQ,EAGZF,EAAO,UACLG,EAAyBF,EAAY,SAACG,EAAQ,CAG5CH,EAAW,KAAKJ,EAAQ,KAAKC,EAASM,EAAOF,GAAO,CAAC,CACvD,CAAC,CAAC,CAEN,CAAC,CACH,CC1DQ,IAAAG,GAAY,MAAK,QAEzB,SAASC,GAAkBC,EAA6BC,EAAW,CAC/D,OAAOH,GAAQG,CAAI,EAAID,EAAE,MAAA,OAAAE,EAAA,CAAA,EAAAC,EAAIF,CAAI,CAAA,CAAA,EAAID,EAAGC,CAAI,CAChD,CAMM,SAAUG,GAAuBJ,EAA2B,CAC9D,OAAOK,EAAI,SAAAJ,EAAI,CAAI,OAAAF,GAAYC,EAAIC,CAAI,CAApB,CAAqB,CAC5C,CCfQ,IAAAK,GAAY,MAAK,QACjBC,GAA0D,OAAM,eAArCC,GAA+B,OAAM,UAAlBC,GAAY,OAAM,KAQlE,SAAUC,GAAqDC,EAAuB,CAC1F,GAAIA,EAAK,SAAW,EAAG,CACrB,IAAMC,EAAQD,EAAK,CAAC,EACpB,GAAIL,GAAQM,CAAK,EACf,MAAO,CAAE,KAAMA,EAAO,KAAM,IAAI,EAElC,GAAIC,GAAOD,CAAK,EAAG,CACjB,IAAME,EAAOL,GAAQG,CAAK,EAC1B,MAAO,CACL,KAAME,EAAK,IAAI,SAACC,EAAG,CAAK,OAAAH,EAAMG,CAAG,CAAT,CAAU,EAClC,KAAID,IAKV,MAAO,CAAE,KAAMH,EAAa,KAAM,IAAI,CACxC,CAEA,SAASE,GAAOG,EAAQ,CACtB,OAAOA,GAAO,OAAOA,GAAQ,UAAYT,GAAeS,CAAG,IAAMR,EACnE,CC7BM,SAAUS,GAAaC,EAAgBC,EAAa,CACxD,OAAOD,EAAK,OAAO,SAACE,EAAQC,EAAKC,EAAC,CAAK,OAAEF,EAAOC,CAAG,EAAIF,EAAOG,CAAC,EAAIF,CAA5B,EAAqC,CAAA,CAAS,CACvF,CCsMM,SAAUG,GAAa,SAAoCC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EAC/D,IAAMC,EAAYC,GAAaH,CAAI,EAC7BI,EAAiBC,GAAkBL,CAAI,EAEvCM,EAA8BC,GAAqBP,CAAI,EAA/CQ,EAAWF,EAAA,KAAEG,EAAIH,EAAA,KAE/B,GAAIE,EAAY,SAAW,EAIzB,OAAOE,GAAK,CAAA,EAAIR,CAAgB,EAGlC,IAAMS,EAAS,IAAIC,EACjBC,GACEL,EACAN,EACAO,EAEI,SAACK,EAAM,CAAK,OAAAC,GAAaN,EAAMK,CAAM,CAAzB,EAEZE,EAAQ,CACb,EAGH,OAAOZ,EAAkBO,EAAO,KAAKM,GAAiBb,CAAc,CAAC,EAAsBO,CAC7F,CAEM,SAAUE,GACdL,EACAN,EACAgB,EAAiD,CAAjD,OAAAA,IAAA,SAAAA,EAAAF,IAEO,SAACG,EAA2B,CAGjCC,GACElB,EACA,UAAA,CAaE,QAZQmB,EAAWb,EAAW,OAExBM,EAAS,IAAI,MAAMO,CAAM,EAG3BC,EAASD,EAITE,EAAuBF,aAGlBG,EAAC,CACRJ,GACElB,EACA,UAAA,CACE,IAAMuB,EAASf,GAAKF,EAAYgB,CAAC,EAAGtB,CAAgB,EAChDwB,EAAgB,GACpBD,EAAO,UACLE,EACER,EACA,SAACS,EAAK,CAEJd,EAAOU,CAAC,EAAII,EACPF,IAEHA,EAAgB,GAChBH,KAEGA,GAGHJ,EAAW,KAAKD,EAAeJ,EAAO,MAAK,CAAE,CAAC,CAElD,EACA,UAAA,CACO,EAAEQ,GAGLH,EAAW,SAAQ,CAEvB,CAAC,CACF,CAEL,EACAA,CAAU,GAjCLK,EAAI,EAAGA,EAAIH,EAAQG,MAAnBA,CAAC,CAoCZ,EACAL,CAAU,CAEd,CACF,CAMA,SAASC,GAAclB,EAAsC2B,EAAqBC,EAA0B,CACtG5B,EACF6B,GAAgBD,EAAc5B,EAAW2B,CAAO,EAEhDA,EAAO,CAEX,CC3RM,SAAUG,GACdC,EACAC,EACAC,EACAC,EACAC,EACAC,EACAC,EACAC,EAAgC,CAGhC,IAAMC,EAAc,CAAA,EAEhBC,EAAS,EAETC,EAAQ,EAERC,EAAa,GAKXC,EAAgB,UAAA,CAIhBD,GAAc,CAACH,EAAO,QAAU,CAACC,GACnCR,EAAW,SAAQ,CAEvB,EAGMY,EAAY,SAACC,EAAQ,CAAK,OAACL,EAASN,EAAaY,EAAWD,CAAK,EAAIN,EAAO,KAAKM,CAAK,CAA5D,EAE1BC,EAAa,SAACD,EAAQ,CAI1BT,GAAUJ,EAAW,KAAKa,CAAY,EAItCL,IAKA,IAAIO,EAAgB,GAGpBC,EAAUf,EAAQY,EAAOJ,GAAO,CAAC,EAAE,UACjCQ,EACEjB,EACA,SAACkB,GAAU,CAGTf,GAAY,MAAZA,EAAee,EAAU,EAErBd,EAGFQ,EAAUM,EAAiB,EAG3BlB,EAAW,KAAKkB,EAAU,CAE9B,EACA,UAAA,CAGEH,EAAgB,EAClB,EAEA,OACA,UAAA,CAIE,GAAIA,EAKF,GAAI,CAIFP,IAKA,sBACE,IAAMW,EAAgBZ,EAAO,MAAK,EAI9BF,EACFe,GAAgBpB,EAAYK,EAAmB,UAAA,CAAM,OAAAS,EAAWK,CAAa,CAAxB,CAAyB,EAE9EL,EAAWK,CAAa,GARrBZ,EAAO,QAAUC,EAASN,QAYjCS,EAAa,QACNU,EAAK,CACZrB,EAAW,MAAMqB,CAAG,EAG1B,CAAC,CACF,CAEL,EAGA,OAAAtB,EAAO,UACLkB,EAAyBjB,EAAYY,EAAW,UAAA,CAE9CF,EAAa,GACbC,EAAa,CACf,CAAC,CAAC,EAKG,UAAA,CACLL,GAAmB,MAAnBA,EAAmB,CACrB,CACF,CClEM,SAAUgB,GACdC,EACAC,EACAC,EAA6B,CAE7B,OAFAA,IAAA,SAAAA,EAAA,KAEIC,EAAWF,CAAc,EAEpBF,GAAS,SAACK,EAAGC,EAAC,CAAK,OAAAC,EAAI,SAACC,EAAQC,EAAU,CAAK,OAAAP,EAAeG,EAAGG,EAAGF,EAAGG,CAAE,CAA1B,CAA2B,EAAEC,EAAUT,EAAQI,EAAGC,CAAC,CAAC,CAAC,CAAjF,EAAoFH,CAAU,GAC/G,OAAOD,GAAmB,WACnCC,EAAaD,GAGRS,EAAQ,SAACC,EAAQC,EAAU,CAAK,OAAAC,GAAeF,EAAQC,EAAYZ,EAASE,CAAU,CAAtD,CAAuD,EAChG,CChCM,SAAUY,GAAyCC,EAA6B,CAA7B,OAAAA,IAAA,SAAAA,EAAA,KAChDC,GAASC,GAAUF,CAAU,CACtC,CCNM,SAAUG,IAAS,CACvB,OAAOC,GAAS,CAAC,CACnB,CCmDM,SAAUC,IAAM,SAACC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACrB,OAAOC,GAAS,EAAGC,GAAKH,EAAMI,GAAaJ,CAAI,CAAC,CAAC,CACnD,CC9DM,SAAUK,EAAsCC,EAA0B,CAC9E,OAAO,IAAIC,EAA+B,SAACC,EAAU,CACnDC,EAAUH,EAAiB,CAAE,EAAE,UAAUE,CAAU,CACrD,CAAC,CACH,CChDA,IAAME,GAA0B,CAAC,cAAe,gBAAgB,EAC1DC,GAAqB,CAAC,mBAAoB,qBAAqB,EAC/DC,GAAgB,CAAC,KAAM,KAAK,EAkO5B,SAAUC,EACdC,EACAC,EACAC,EACAC,EAAsC,CAMtC,GAJIC,EAAWF,CAAO,IACpBC,EAAiBD,EACjBA,EAAU,QAERC,EACF,OAAOJ,EAAaC,EAAQC,EAAWC,CAA+B,EAAE,KAAKG,GAAiBF,CAAc,CAAC,EAUzG,IAAAG,EAAAC,EAEJC,GAAcR,CAAM,EAChBH,GAAmB,IAAI,SAACY,EAAU,CAAK,OAAA,SAACC,EAAY,CAAK,OAAAV,EAAOS,CAAU,EAAER,EAAWS,EAASR,CAA+B,CAAtE,CAAlB,CAAyF,EAElIS,GAAwBX,CAAM,EAC5BJ,GAAwB,IAAIgB,GAAwBZ,EAAQC,CAAS,CAAC,EACtEY,GAA0Bb,CAAM,EAChCF,GAAc,IAAIc,GAAwBZ,EAAQC,CAAS,CAAC,EAC5D,CAAA,EAAE,CAAA,EATDa,EAAGR,EAAA,CAAA,EAAES,EAAMT,EAAA,CAAA,EAgBlB,GAAI,CAACQ,GACCE,GAAYhB,CAAM,EACpB,OAAOiB,GAAS,SAACC,EAAc,CAAK,OAAAnB,EAAUmB,EAAWjB,EAAWC,CAA+B,CAA/D,CAAgE,EAClGiB,EAAUnB,CAAM,CAAC,EAOvB,GAAI,CAACc,EACH,MAAM,IAAI,UAAU,sBAAsB,EAG5C,OAAO,IAAIM,EAAc,SAACC,EAAU,CAIlC,IAAMX,EAAU,UAAA,SAACY,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EAAmB,OAAAF,EAAW,KAAK,EAAIC,EAAK,OAASA,EAAOA,EAAK,CAAC,CAAC,CAAhD,EAEpC,OAAAR,EAAIJ,CAAO,EAEJ,UAAA,CAAM,OAAAK,EAAQL,CAAO,CAAf,CACf,CAAC,CACH,CASA,SAASE,GAAwBZ,EAAaC,EAAiB,CAC7D,OAAO,SAACQ,EAAkB,CAAK,OAAA,SAACC,EAAY,CAAK,OAAAV,EAAOS,CAAU,EAAER,EAAWS,CAAO,CAArC,CAAlB,CACjC,CAOA,SAASC,GAAwBX,EAAW,CAC1C,OAAOI,EAAWJ,EAAO,WAAW,GAAKI,EAAWJ,EAAO,cAAc,CAC3E,CAOA,SAASa,GAA0Bb,EAAW,CAC5C,OAAOI,EAAWJ,EAAO,EAAE,GAAKI,EAAWJ,EAAO,GAAG,CACvD,CAOA,SAASQ,GAAcR,EAAW,CAChC,OAAOI,EAAWJ,EAAO,gBAAgB,GAAKI,EAAWJ,EAAO,mBAAmB,CACrF,CCnMM,SAAUwB,GACdC,EACAC,EACAC,EAAsC,CAEtC,OAAIA,EACKH,GAAoBC,EAAYC,CAAa,EAAE,KAAKE,GAAiBD,CAAc,CAAC,EAGtF,IAAIE,EAAoB,SAACC,EAAU,CACxC,IAAMC,EAAU,UAAA,SAACC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EAAc,OAAAH,EAAW,KAAKE,EAAE,SAAW,EAAIA,EAAE,CAAC,EAAIA,CAAC,CAAzC,EACzBE,EAAWT,EAAWM,CAAO,EACnC,OAAOI,EAAWT,CAAa,EAAI,UAAA,CAAM,OAAAA,EAAcK,EAASG,CAAQ,CAA/B,EAAmC,MAC9E,CAAC,CACH,CCtBM,SAAUE,GACdC,EACAC,EACAC,EAAyC,CAFzCF,IAAA,SAAAA,EAAA,GAEAE,IAAA,SAAAA,EAAAC,IAIA,IAAIC,EAAmB,GAEvB,OAAIH,GAAuB,OAIrBI,GAAYJ,CAAmB,EACjCC,EAAYD,EAIZG,EAAmBH,GAIhB,IAAIK,EAAW,SAACC,EAAU,CAI/B,IAAIC,EAAMC,GAAYT,CAAO,EAAI,CAACA,EAAUE,EAAW,IAAG,EAAKF,EAE3DQ,EAAM,IAERA,EAAM,GAIR,IAAIE,EAAI,EAGR,OAAOR,EAAU,SAAS,UAAA,CACnBK,EAAW,SAEdA,EAAW,KAAKG,GAAG,EAEf,GAAKN,EAGP,KAAK,SAAS,OAAWA,CAAgB,EAGzCG,EAAW,SAAQ,EAGzB,EAAGC,CAAG,CACR,CAAC,CACH,CChGM,SAAUG,GAAK,SAACC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACpB,IAAMC,EAAYC,GAAaH,CAAI,EAC7BI,EAAaC,GAAUL,EAAM,GAAQ,EACrCM,EAAUN,EAChB,OAAQM,EAAQ,OAGZA,EAAQ,SAAW,EAEnBC,EAAUD,EAAQ,CAAC,CAAC,EAEpBE,GAASJ,CAAU,EAAEK,GAAKH,EAASJ,CAAS,CAAC,EAL7CQ,CAMN,CCjEO,IAAMC,GAAQ,IAAIC,EAAkBC,EAAI,ECpCvC,IAAAC,GAAY,MAAK,QAMnB,SAAUC,GAAkBC,EAAiB,CACjD,OAAOA,EAAK,SAAW,GAAKF,GAAQE,EAAK,CAAC,CAAC,EAAIA,EAAK,CAAC,EAAKA,CAC5D,CCoDM,SAAUC,EAAUC,EAAiDC,EAAa,CACtF,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAEhC,IAAIC,EAAQ,EAIZF,EAAO,UAILG,EAAyBF,EAAY,SAACG,EAAK,CAAK,OAAAP,EAAU,KAAKC,EAASM,EAAOF,GAAO,GAAKD,EAAW,KAAKG,CAAK,CAAhE,CAAiE,CAAC,CAEtH,CAAC,CACH,CCxBM,SAAUC,IAAG,SAACC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EAClB,IAAMC,EAAiBC,GAAkBH,CAAI,EAEvCI,EAAUC,GAAeL,CAAI,EAEnC,OAAOI,EAAQ,OACX,IAAIE,EAAsB,SAACC,EAAU,CAGnC,IAAIC,EAAuBJ,EAAQ,IAAI,UAAA,CAAM,MAAA,CAAA,CAAA,CAAE,EAK3CK,EAAYL,EAAQ,IAAI,UAAA,CAAM,MAAA,EAAA,CAAK,EAGvCG,EAAW,IAAI,UAAA,CACbC,EAAUC,EAAY,IACxB,CAAC,EAKD,mBAASC,EAAW,CAClBC,EAAUP,EAAQM,CAAW,CAAC,EAAE,UAC9BE,EACEL,EACA,SAACM,EAAK,CAKJ,GAJAL,EAAQE,CAAW,EAAE,KAAKG,CAAK,EAI3BL,EAAQ,MAAM,SAACM,EAAM,CAAK,OAAAA,EAAO,MAAP,CAAa,EAAG,CAC5C,IAAMC,EAAcP,EAAQ,IAAI,SAACM,EAAM,CAAK,OAAAA,EAAO,MAAK,CAAZ,CAAe,EAE3DP,EAAW,KAAKL,EAAiBA,EAAc,MAAA,OAAAc,EAAA,CAAA,EAAAC,EAAIF,CAAM,CAAA,CAAA,EAAIA,CAAM,EAI/DP,EAAQ,KAAK,SAACM,EAAQI,EAAC,CAAK,MAAA,CAACJ,EAAO,QAAUL,EAAUS,CAAC,CAA7B,CAA8B,GAC5DX,EAAW,SAAQ,EAGzB,EACA,UAAA,CAGEE,EAAUC,CAAW,EAAI,GAIzB,CAACF,EAAQE,CAAW,EAAE,QAAUH,EAAW,SAAQ,CACrD,CAAC,CACF,GA9BIG,EAAc,EAAG,CAACH,EAAW,QAAUG,EAAcN,EAAQ,OAAQM,MAArEA,CAAW,EAmCpB,OAAO,UAAA,CACLF,EAAUC,EAAY,IACxB,CACF,CAAC,EACDU,CACN,CC9DM,SAAUC,GAASC,EAAoD,CAC3E,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAW,GACXC,EAAsB,KACtBC,EAA6C,KAC7CC,EAAa,GAEXC,EAAc,UAAA,CAGlB,GAFAF,GAAkB,MAAlBA,EAAoB,YAAW,EAC/BA,EAAqB,KACjBF,EAAU,CACZA,EAAW,GACX,IAAMK,EAAQJ,EACdA,EAAY,KACZF,EAAW,KAAKM,CAAK,EAEvBF,GAAcJ,EAAW,SAAQ,CACnC,EAEMO,EAAkB,UAAA,CACtBJ,EAAqB,KACrBC,GAAcJ,EAAW,SAAQ,CACnC,EAEAD,EAAO,UACLS,EACER,EACA,SAACM,EAAK,CACJL,EAAW,GACXC,EAAYI,EACPH,GACHM,EAAUZ,EAAiBS,CAAK,CAAC,EAAE,UAChCH,EAAqBK,EAAyBR,EAAYK,EAAaE,CAAe,CAAE,CAG/F,EACA,UAAA,CACEH,EAAa,IACZ,CAACH,GAAY,CAACE,GAAsBA,EAAmB,SAAWH,EAAW,SAAQ,CACxF,CAAC,CACF,CAEL,CAAC,CACH,CC3CM,SAAUU,GAAaC,EAAkBC,EAAyC,CAAzC,OAAAA,IAAA,SAAAA,EAAAC,IACtCC,GAAM,UAAA,CAAM,OAAAC,GAAMJ,EAAUC,CAAS,CAAzB,CAA0B,CAC/C,CCEM,SAAUI,GAAeC,EAAoBC,EAAsC,CAAtC,OAAAA,IAAA,SAAAA,EAAA,MAGjDA,EAAmBA,GAAgB,KAAhBA,EAAoBD,EAEhCE,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAiB,CAAA,EACjBC,EAAQ,EAEZH,EAAO,UACLI,EACEH,EACA,SAACI,EAAK,aACAC,EAAuB,KAKvBH,IAAUL,IAAsB,GAClCI,EAAQ,KAAK,CAAA,CAAE,MAIjB,QAAqBK,EAAAC,GAAAN,CAAO,EAAAO,EAAAF,EAAA,KAAA,EAAA,CAAAE,EAAA,KAAAA,EAAAF,EAAA,KAAA,EAAE,CAAzB,IAAMG,EAAMD,EAAA,MACfC,EAAO,KAAKL,CAAK,EAMbR,GAAca,EAAO,SACvBJ,EAASA,GAAM,KAANA,EAAU,CAAA,EACnBA,EAAO,KAAKI,CAAM,uGAItB,GAAIJ,MAIF,QAAqBK,EAAAH,GAAAF,CAAM,EAAAM,EAAAD,EAAA,KAAA,EAAA,CAAAC,EAAA,KAAAA,EAAAD,EAAA,KAAA,EAAE,CAAxB,IAAMD,EAAME,EAAA,MACfC,GAAUX,EAASQ,CAAM,EACzBT,EAAW,KAAKS,CAAM,sGAG5B,EACA,UAAA,aAGE,QAAqBI,EAAAN,GAAAN,CAAO,EAAAa,EAAAD,EAAA,KAAA,EAAA,CAAAC,EAAA,KAAAA,EAAAD,EAAA,KAAA,EAAE,CAAzB,IAAMJ,EAAMK,EAAA,MACfd,EAAW,KAAKS,CAAM,oGAExBT,EAAW,SAAQ,CACrB,EAEA,OACA,UAAA,CAEEC,EAAU,IACZ,CAAC,CACF,CAEL,CAAC,CACH,CCbM,SAAUc,GACdC,EAAgD,CAEhD,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAgC,KAChCC,EAAY,GACZC,EAEJF,EAAWF,EAAO,UAChBK,EAAyBJ,EAAY,OAAW,OAAW,SAACK,EAAG,CAC7DF,EAAgBG,EAAUT,EAASQ,EAAKT,GAAWC,CAAQ,EAAEE,CAAM,CAAC,CAAC,EACjEE,GACFA,EAAS,YAAW,EACpBA,EAAW,KACXE,EAAc,UAAUH,CAAU,GAIlCE,EAAY,EAEhB,CAAC,CAAC,EAGAA,IAMFD,EAAS,YAAW,EACpBA,EAAW,KACXE,EAAe,UAAUH,CAAU,EAEvC,CAAC,CACH,CC/HM,SAAUO,GACdC,EACAC,EACAC,EACAC,EACAC,EAAqC,CAErC,OAAO,SAACC,EAAuBC,EAA2B,CAIxD,IAAIC,EAAWL,EAIXM,EAAaP,EAEbQ,EAAQ,EAGZJ,EAAO,UACLK,EACEJ,EACA,SAACK,EAAK,CAEJ,IAAMC,EAAIH,IAEVD,EAAQD,EAEJP,EAAYQ,EAAOG,EAAOC,CAAC,GAIzBL,EAAW,GAAOI,GAGxBR,GAAcG,EAAW,KAAKE,CAAK,CACrC,EAGAJ,GACG,UAAA,CACCG,GAAYD,EAAW,KAAKE,CAAK,EACjCF,EAAW,SAAQ,CACrB,CAAE,CACL,CAEL,CACF,CCnCM,SAAUO,IAAa,SAAOC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EAClC,IAAMC,EAAiBC,GAAkBH,CAAI,EAC7C,OAAOE,EACHE,GAAKL,GAAa,MAAA,OAAAM,EAAA,CAAA,EAAAC,EAAKN,CAAoC,CAAA,CAAA,EAAGO,GAAiBL,CAAc,CAAC,EAC9FM,EAAQ,SAACC,EAAQC,EAAU,CACzBC,GAAiBN,EAAA,CAAEI,CAAM,EAAAH,EAAKM,GAAeZ,CAAI,CAAC,CAAA,CAAA,EAAGU,CAAU,CACjE,CAAC,CACP,CCUM,SAAUG,IAAiB,SAC/BC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EAEA,OAAOC,GAAa,MAAA,OAAAC,EAAA,CAAA,EAAAC,EAAIJ,CAAY,CAAA,CAAA,CACtC,CCkBM,SAAUK,GAAYC,EAAoD,CAC9E,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAW,GACXC,EAAsB,KAEtBC,EAA6C,KAE3CC,EAAO,UAAA,CAMX,GAFAD,GAAkB,MAAlBA,EAAoB,YAAW,EAC/BA,EAAqB,KACjBF,EAAU,CAEZA,EAAW,GACX,IAAMI,EAAQH,EACdA,EAAY,KACZF,EAAW,KAAKK,CAAK,EAEzB,EAEAN,EAAO,UACLO,EACEN,EACA,SAACK,EAAQ,CAIPF,GAAkB,MAAlBA,EAAoB,YAAW,EAC/BF,EAAW,GACXC,EAAYG,EAGZF,EAAqBG,EAAyBN,EAAYI,EAAMG,EAAI,EAEpEC,EAAUX,EAAiBQ,CAAK,CAAC,EAAE,UAAUF,CAAkB,CACjE,EACA,UAAA,CAGEC,EAAI,EACJJ,EAAW,SAAQ,CACrB,EAEA,OACA,UAAA,CAEEE,EAAYC,EAAqB,IACnC,CAAC,CACF,CAEL,CAAC,CACH,CCvDM,SAAUM,GAAgBC,EAAiBC,EAAyC,CAAzC,OAAAA,IAAA,SAAAA,EAAAC,IACxCC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAkC,KAClCC,EAAsB,KACtBC,EAA0B,KAExBC,EAAO,UAAA,CACX,GAAIH,EAAY,CAEdA,EAAW,YAAW,EACtBA,EAAa,KACb,IAAMI,EAAQH,EACdA,EAAY,KACZF,EAAW,KAAKK,CAAK,EAEzB,EACA,SAASC,GAAY,CAInB,IAAMC,EAAaJ,EAAYR,EACzBa,EAAMZ,EAAU,IAAG,EACzB,GAAIY,EAAMD,EAAY,CAEpBN,EAAa,KAAK,SAAS,OAAWM,EAAaC,CAAG,EACtDR,EAAW,IAAIC,CAAU,EACzB,OAGFG,EAAI,CACN,CAEAL,EAAO,UACLU,EACET,EACA,SAACK,EAAQ,CACPH,EAAYG,EACZF,EAAWP,EAAU,IAAG,EAGnBK,IACHA,EAAaL,EAAU,SAASU,EAAcX,CAAO,EACrDK,EAAW,IAAIC,CAAU,EAE7B,EACA,UAAA,CAGEG,EAAI,EACJJ,EAAW,SAAQ,CACrB,EAEA,OACA,UAAA,CAEEE,EAAYD,EAAa,IAC3B,CAAC,CACF,CAEL,CAAC,CACH,CCpFM,SAAUS,GAAqBC,EAAe,CAClD,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAW,GACfF,EAAO,UACLG,EACEF,EACA,SAACG,EAAK,CACJF,EAAW,GACXD,EAAW,KAAKG,CAAK,CACvB,EACA,UAAA,CACOF,GACHD,EAAW,KAAKH,CAAa,EAE/BG,EAAW,SAAQ,CACrB,CAAC,CACF,CAEL,CAAC,CACH,CCXM,SAAUI,GAAQC,EAAa,CACnC,OAAOA,GAAS,EAEZ,UAAA,CAAM,OAAAC,CAAA,EACNC,EAAQ,SAACC,EAAQC,EAAU,CACzB,IAAIC,EAAO,EACXF,EAAO,UACLG,EAAyBF,EAAY,SAACG,EAAK,CAIrC,EAAEF,GAAQL,IACZI,EAAW,KAAKG,CAAK,EAIjBP,GAASK,GACXD,EAAW,SAAQ,EAGzB,CAAC,CAAC,CAEN,CAAC,CACP,CC9BM,SAAUI,GAAc,CAC5B,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChCD,EAAO,UAAUE,EAAyBD,EAAYE,EAAI,CAAC,CAC7D,CAAC,CACH,CCCM,SAAUC,GAASC,EAAQ,CAC/B,OAAOC,EAAI,UAAA,CAAM,OAAAD,CAAA,CAAK,CACxB,CC4CM,SAAUE,GACdC,EACAC,EAAmC,CAEnC,OAAIA,EAEK,SAACC,EAAqB,CAC3B,OAAAC,GAAOF,EAAkB,KAAKG,GAAK,CAAC,EAAGC,EAAc,CAAE,EAAGH,EAAO,KAAKH,GAAUC,CAAqB,CAAC,CAAC,CAAvG,EAGGM,GAAS,SAACC,EAAOC,EAAK,CAAK,OAAAC,EAAUT,EAAsBO,EAAOC,CAAK,CAAC,EAAE,KAAKJ,GAAK,CAAC,EAAGM,GAAMH,CAAK,CAAC,CAAzE,CAA0E,CAC9G,CCzCM,SAAUI,GAASC,EAAoBC,EAAyC,CAAzCA,IAAA,SAAAA,EAAAC,IAC3C,IAAMC,EAAWC,GAAMJ,EAAKC,CAAS,EACrC,OAAOI,GAAU,UAAA,CAAM,OAAAF,CAAA,CAAQ,CACjC,CC0EM,SAAUG,EACdC,EACAC,EAA0D,CAA1D,OAAAA,IAAA,SAAAA,EAA+BC,IAK/BF,EAAaA,GAAU,KAAVA,EAAcG,GAEpBC,EAAQ,SAACC,EAAQC,EAAU,CAGhC,IAAIC,EAEAC,EAAQ,GAEZH,EAAO,UACLI,EAAyBH,EAAY,SAACI,EAAK,CAEzC,IAAMC,EAAaV,EAAYS,CAAK,GAKhCF,GAAS,CAACR,EAAYO,EAAaI,CAAU,KAM/CH,EAAQ,GACRD,EAAcI,EAGdL,EAAW,KAAKI,CAAK,EAEzB,CAAC,CAAC,CAEN,CAAC,CACH,CAEA,SAASP,GAAeS,EAAQC,EAAM,CACpC,OAAOD,IAAMC,CACf,CCjHM,SAAUC,GAA8CC,EAAQC,EAAuC,CAC3G,OAAOC,EAAqB,SAACC,EAAMC,EAAI,CAAK,OAAAH,EAAUA,EAAQE,EAAEH,CAAG,EAAGI,EAAEJ,CAAG,CAAC,EAAIG,EAAEH,CAAG,IAAMI,EAAEJ,CAAG,CAApD,CAAqD,CACnG,CC7BM,SAAUK,GAAgBC,EAA6C,CAA7C,OAAAA,IAAA,SAAAA,EAAAC,IACvBC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAW,GACfF,EAAO,UACLG,EACEF,EACA,SAACG,EAAK,CACJF,EAAW,GACXD,EAAW,KAAKG,CAAK,CACvB,EACA,UAAA,CAAM,OAACF,EAAWD,EAAW,SAAQ,EAAKA,EAAW,MAAMJ,EAAY,CAAE,CAAnE,CAAqE,CAC5E,CAEL,CAAC,CACH,CAEA,SAASC,IAAmB,CAC1B,OAAO,IAAIO,EACb,CCMM,SAAUC,IAAO,SAAIC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACzB,OAAO,SAACC,EAAqB,CAAK,OAAAC,GAAOD,EAAQE,EAAE,MAAA,OAAAC,EAAA,CAAA,EAAAC,EAAIN,CAAM,CAAA,CAAA,CAAA,CAA3B,CACpC,CCHM,SAAUO,EAAYC,EAAoB,CAC9C,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAGhC,GAAI,CACFD,EAAO,UAAUC,CAAU,UAE3BA,EAAW,IAAIH,CAAQ,EAE3B,CAAC,CACH,CCMM,SAAUI,GACdC,EACAC,EAAgB,CAEhB,IAAMC,EAAkB,UAAU,QAAU,EAC5C,OAAO,SAACC,EAAqB,CAC3B,OAAAA,EAAO,KACLH,EAAYI,EAAO,SAACC,EAAG,EAAC,CAAK,OAAAL,EAAUK,EAAG,EAAGF,CAAM,CAAtB,CAAuB,EAAIG,GACxDC,GAAK,CAAC,EACNL,EAAkBM,GAAeP,CAAa,EAAIQ,GAAa,UAAA,CAAM,OAAA,IAAIC,EAAJ,CAAgB,CAAC,CAHxF,CAKJ,CC/CM,SAAUC,GAAYC,EAAa,CACvC,OAAOA,GAAS,EACZ,UAAA,CAAM,OAAAC,CAAA,EACNC,EAAQ,SAACC,EAAQC,EAAU,CAKzB,IAAIC,EAAc,CAAA,EAClBF,EAAO,UACLG,EACEF,EACA,SAACG,EAAK,CAEJF,EAAO,KAAKE,CAAK,EAGjBP,EAAQK,EAAO,QAAUA,EAAO,MAAK,CACvC,EACA,UAAA,aAGE,QAAoBG,EAAAC,GAAAJ,CAAM,EAAAK,EAAAF,EAAA,KAAA,EAAA,CAAAE,EAAA,KAAAA,EAAAF,EAAA,KAAA,EAAE,CAAvB,IAAMD,EAAKG,EAAA,MACdN,EAAW,KAAKG,CAAK,oGAEvBH,EAAW,SAAQ,CACrB,EAEA,OACA,UAAA,CAEEC,EAAS,IACX,CAAC,CACF,CAEL,CAAC,CACP,CC1DM,SAAUM,IAAK,SAAIC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACvB,IAAMC,EAAYC,GAAaH,CAAI,EAC7BI,EAAaC,GAAUL,EAAM,GAAQ,EAC3C,OAAAA,EAAOM,GAAeN,CAAI,EAEnBO,EAAQ,SAACC,EAAQC,EAAU,CAChCC,GAASN,CAAU,EAAEO,GAAIC,EAAA,CAAEJ,CAAM,EAAAK,EAAMb,CAA6B,CAAA,EAAGE,CAAS,CAAC,EAAE,UAAUO,CAAU,CACzG,CAAC,CACH,CCcM,SAAUK,IAAS,SACvBC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EAEA,OAAOC,GAAK,MAAA,OAAAC,EAAA,CAAA,EAAAC,EAAIJ,CAAY,CAAA,CAAA,CAC9B,CCmEM,SAAUK,GAAUC,EAAqC,OACzDC,EAAQ,IACRC,EAEJ,OAAIF,GAAiB,OACf,OAAOA,GAAkB,UACxBG,EAA4BH,EAAa,MAAzCC,EAAKE,IAAA,OAAG,IAAQA,EAAED,EAAUF,EAAa,OAE5CC,EAAQD,GAILC,GAAS,EACZ,UAAA,CAAM,OAAAG,CAAA,EACNC,EAAQ,SAACC,EAAQC,EAAU,CACzB,IAAIC,EAAQ,EACRC,EAEEC,EAAc,UAAA,CAGlB,GAFAD,GAAS,MAATA,EAAW,YAAW,EACtBA,EAAY,KACRP,GAAS,KAAM,CACjB,IAAMS,EAAW,OAAOT,GAAU,SAAWU,GAAMV,CAAK,EAAIW,EAAUX,EAAMM,CAAK,CAAC,EAC5EM,EAAqBC,EAAyBR,EAAY,UAAA,CAC9DO,EAAmB,YAAW,EAC9BE,EAAiB,CACnB,CAAC,EACDL,EAAS,UAAUG,CAAkB,OAErCE,EAAiB,CAErB,EAEMA,EAAoB,UAAA,CACxB,IAAIC,EAAY,GAChBR,EAAYH,EAAO,UACjBS,EAAyBR,EAAY,OAAW,UAAA,CAC1C,EAAEC,EAAQP,EACRQ,EACFC,EAAW,EAEXO,EAAY,GAGdV,EAAW,SAAQ,CAEvB,CAAC,CAAC,EAGAU,GACFP,EAAW,CAEf,EAEAM,EAAiB,CACnB,CAAC,CACP,CCpFM,SAAUE,GAAcC,EAA6DC,EAAQ,CAMjG,OAAOC,EAAQC,GAAcH,EAAaC,EAAW,UAAU,QAAU,EAAG,EAAI,CAAC,CACnF,CC+CM,SAAUG,GAASC,EAA4B,CAA5BA,IAAA,SAAAA,EAAA,CAAA,GACf,IAAAC,EAAgHD,EAAO,UAAvHE,EAASD,IAAA,OAAG,UAAA,CAAM,OAAA,IAAIE,CAAJ,EAAgBF,EAAEG,EAA4EJ,EAAO,aAAnFK,EAAYD,IAAA,OAAG,GAAIA,EAAEE,EAAuDN,EAAO,gBAA9DO,EAAeD,IAAA,OAAG,GAAIA,EAAEE,EAA+BR,EAAO,oBAAtCS,EAAmBD,IAAA,OAAG,GAAIA,EAUnH,OAAO,SAACE,EAAa,CACnB,IAAIC,EACAC,EACAC,EACAC,EAAW,EACXC,EAAe,GACfC,EAAa,GAEXC,EAAc,UAAA,CAClBL,GAAe,MAAfA,EAAiB,YAAW,EAC5BA,EAAkB,MACpB,EAGMM,GAAQ,UAAA,CACZD,EAAW,EACXN,EAAaE,EAAU,OACvBE,EAAeC,EAAa,EAC9B,EACMG,EAAsB,UAAA,CAG1B,IAAMC,EAAOT,EACbO,GAAK,EACLE,GAAI,MAAJA,EAAM,YAAW,CACnB,EAEA,OAAOC,EAAc,SAACC,EAAQC,GAAU,CACtCT,IACI,CAACE,GAAc,CAACD,GAClBE,EAAW,EAOb,IAAMO,GAAQX,EAAUA,GAAO,KAAPA,EAAWX,EAAS,EAO5CqB,GAAW,IAAI,UAAA,CACbT,IAKIA,IAAa,GAAK,CAACE,GAAc,CAACD,IACpCH,EAAkBa,GAAYN,EAAqBV,CAAmB,EAE1E,CAAC,EAIDe,GAAK,UAAUD,EAAU,EAGvB,CAACZ,GAIDG,EAAW,IAOXH,EAAa,IAAIe,GAAe,CAC9B,KAAM,SAACC,GAAK,CAAK,OAAAH,GAAK,KAAKG,EAAK,CAAf,EACjB,MAAO,SAACC,GAAG,CACTZ,EAAa,GACbC,EAAW,EACXL,EAAkBa,GAAYP,GAAOb,EAAcuB,EAAG,EACtDJ,GAAK,MAAMI,EAAG,CAChB,EACA,SAAU,UAAA,CACRb,EAAe,GACfE,EAAW,EACXL,EAAkBa,GAAYP,GAAOX,CAAe,EACpDiB,GAAK,SAAQ,CACf,EACD,EACDK,EAAUP,CAAM,EAAE,UAAUX,CAAU,EAE1C,CAAC,EAAED,CAAa,CAClB,CACF,CAEA,SAASe,GACPP,EACAY,EAAoD,SACpDC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,EAAA,CAAA,EAAA,UAAAA,CAAA,EAEA,GAAIF,IAAO,GAAM,CACfZ,EAAK,EACL,OAGF,GAAIY,IAAO,GAIX,KAAMG,EAAe,IAAIP,GAAe,CACtC,KAAM,UAAA,CACJO,EAAa,YAAW,EACxBf,EAAK,CACP,EACD,EAED,OAAOW,EAAUC,EAAE,MAAA,OAAAI,EAAA,CAAA,EAAAC,EAAIJ,CAAI,CAAA,CAAA,CAAA,EAAG,UAAUE,CAAY,EACtD,CChHM,SAAUG,EACdC,EACAC,EACAC,EAAyB,WAErBC,EACAC,EAAW,GACf,OAAIJ,GAAsB,OAAOA,GAAuB,UACnDK,EAA8EL,EAAkB,WAAhGG,EAAUE,IAAA,OAAG,IAAQA,EAAEC,EAAuDN,EAAkB,WAAzEC,EAAUK,IAAA,OAAG,IAAQA,EAAEC,EAAgCP,EAAkB,SAAlDI,EAAQG,IAAA,OAAG,GAAKA,EAAEL,EAAcF,EAAkB,WAEnGG,EAAcH,GAAkB,KAAlBA,EAAsB,IAE/BQ,GAAS,CACd,UAAW,UAAA,CAAM,OAAA,IAAIC,GAAcN,EAAYF,EAAYC,CAAS,CAAnD,EACjB,aAAc,GACd,gBAAiB,GACjB,oBAAqBE,EACtB,CACH,CCxIM,SAAUM,GAAQC,EAAa,CACnC,OAAOC,EAAO,SAACC,EAAGC,EAAK,CAAK,OAAAH,GAASG,CAAT,CAAc,CAC5C,CCaM,SAAUC,GAAaC,EAA8B,CACzD,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAS,GAEPC,EAAiBC,EACrBH,EACA,UAAA,CACEE,GAAc,MAAdA,EAAgB,YAAW,EAC3BD,EAAS,EACX,EACAG,EAAI,EAGNC,EAAUR,CAAQ,EAAE,UAAUK,CAAc,EAE5CH,EAAO,UAAUI,EAAyBH,EAAY,SAACM,EAAK,CAAK,OAAAL,GAAUD,EAAW,KAAKM,CAAK,CAA/B,CAAgC,CAAC,CACpG,CAAC,CACH,CCVM,SAAUC,GAAS,SAAOC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EAC9B,IAAMC,EAAYC,GAAaH,CAAM,EACrC,OAAOI,EAAQ,SAACC,EAAQC,EAAU,EAI/BJ,EAAYK,GAAOP,EAAQK,EAAQH,CAAS,EAAIK,GAAOP,EAAQK,CAAM,GAAG,UAAUC,CAAU,CAC/F,CAAC,CACH,CCmBM,SAAUE,EACdC,EACAC,EAA6G,CAE7G,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAyD,KACzDC,EAAQ,EAERC,EAAa,GAIXC,EAAgB,UAAA,CAAM,OAAAD,GAAc,CAACF,GAAmBD,EAAW,SAAQ,CAArD,EAE5BD,EAAO,UACLM,EACEL,EACA,SAACM,EAAK,CAEJL,GAAe,MAAfA,EAAiB,YAAW,EAC5B,IAAIM,EAAa,EACXC,EAAaN,IAEnBO,EAAUb,EAAQU,EAAOE,CAAU,CAAC,EAAE,UACnCP,EAAkBI,EACjBL,EAIA,SAACU,EAAU,CAAK,OAAAV,EAAW,KAAKH,EAAiBA,EAAeS,EAAOI,EAAYF,EAAYD,GAAY,EAAIG,CAAU,CAAzG,EAChB,UAAA,CAIET,EAAkB,KAClBG,EAAa,CACf,CAAC,CACD,CAEN,EACA,UAAA,CACED,EAAa,GACbC,EAAa,CACf,CAAC,CACF,CAEL,CAAC,CACH,CCvFM,SAAUO,EAAaC,EAA8B,CACzD,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChCC,EAAUJ,CAAQ,EAAE,UAAUK,EAAyBF,EAAY,UAAA,CAAM,OAAAA,EAAW,SAAQ,CAAnB,EAAuBG,EAAI,CAAC,EACrG,CAACH,EAAW,QAAUD,EAAO,UAAUC,CAAU,CACnD,CAAC,CACH,CCIM,SAAUI,GAAaC,EAAiDC,EAAiB,CAAjB,OAAAA,IAAA,SAAAA,EAAA,IACrEC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAQ,EACZF,EAAO,UACLG,EAAyBF,EAAY,SAACG,EAAK,CACzC,IAAMC,EAASR,EAAUO,EAAOF,GAAO,GACtCG,GAAUP,IAAcG,EAAW,KAAKG,CAAK,EAC9C,CAACC,GAAUJ,EAAW,SAAQ,CAChC,CAAC,CAAC,CAEN,CAAC,CACH,CCqGM,SAAUK,EACdC,EACAC,EACAC,EAA8B,CAK9B,IAAMC,EACJC,EAAWJ,CAAc,GAAKC,GAASC,EAElC,CAAE,KAAMF,EAA2E,MAAKC,EAAE,SAAQC,CAAA,EACnGF,EAEN,OAAOG,EACHE,EAAQ,SAACC,EAAQC,EAAU,QACzBC,EAAAL,EAAY,aAAS,MAAAK,IAAA,QAAAA,EAAA,KAArBL,CAAW,EACX,IAAIM,EAAU,GACdH,EAAO,UACLI,EACEH,EACA,SAACI,EAAK,QACJH,EAAAL,EAAY,QAAI,MAAAK,IAAA,QAAAA,EAAA,KAAhBL,EAAmBQ,CAAK,EACxBJ,EAAW,KAAKI,CAAK,CACvB,EACA,UAAA,OACEF,EAAU,IACVD,EAAAL,EAAY,YAAQ,MAAAK,IAAA,QAAAA,EAAA,KAApBL,CAAW,EACXI,EAAW,SAAQ,CACrB,EACA,SAACK,EAAG,OACFH,EAAU,IACVD,EAAAL,EAAY,SAAK,MAAAK,IAAA,QAAAA,EAAA,KAAjBL,EAAoBS,CAAG,EACvBL,EAAW,MAAMK,CAAG,CACtB,EACA,UAAA,SACMH,KACFD,EAAAL,EAAY,eAAW,MAAAK,IAAA,QAAAA,EAAA,KAAvBL,CAAW,IAEbU,EAAAV,EAAY,YAAQ,MAAAU,IAAA,QAAAA,EAAA,KAApBV,CAAW,CACb,CAAC,CACF,CAEL,CAAC,EAIDW,EACN,CCnIM,SAAUC,GAAYC,EAAsDC,EAAuB,CACvG,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAC1B,IAAAC,EAAuCJ,GAAM,KAANA,EAAU,CAAA,EAA/CK,EAAAD,EAAA,QAAAE,EAAOD,IAAA,OAAG,GAAIA,EAAEE,EAAAH,EAAA,SAAAI,EAAQD,IAAA,OAAG,GAAKA,EACpCE,EAAW,GACXC,EAAsB,KACtBC,EAAiC,KACjCC,EAAa,GAEXC,EAAgB,UAAA,CACpBF,GAAS,MAATA,EAAW,YAAW,EACtBA,EAAY,KACRH,IACFM,EAAI,EACJF,GAAcT,EAAW,SAAQ,EAErC,EAEMY,EAAoB,UAAA,CACxBJ,EAAY,KACZC,GAAcT,EAAW,SAAQ,CACnC,EAEMa,EAAgB,SAACC,GAAQ,CAC7B,OAACN,EAAYO,EAAUnB,EAAiBkB,EAAK,CAAC,EAAE,UAAUE,EAAyBhB,EAAYU,EAAeE,CAAiB,CAAC,CAAhI,EAEID,EAAO,UAAA,CACX,GAAIL,EAAU,CAIZA,EAAW,GACX,IAAMQ,GAAQP,EACdA,EAAY,KAEZP,EAAW,KAAKc,EAAK,EACrB,CAACL,GAAcI,EAAcC,EAAK,EAEtC,EAEAf,EAAO,UACLiB,EACEhB,EAMA,SAACc,GAAK,CACJR,EAAW,GACXC,EAAYO,GACZ,EAAEN,GAAa,CAACA,EAAU,UAAYL,EAAUQ,EAAI,EAAKE,EAAcC,EAAK,EAC9E,EACA,UAAA,CACEL,EAAa,GACb,EAAEJ,GAAYC,GAAYE,GAAa,CAACA,EAAU,SAAWR,EAAW,SAAQ,CAClF,CAAC,CACF,CAEL,CAAC,CACH,CCxFM,SAAUiB,GACdC,EACAC,EACAC,EAAuB,CADvBD,IAAA,SAAAA,EAAAE,IAGA,IAAMC,EAAYC,GAAML,EAAUC,CAAS,EAC3C,OAAOK,GAAS,UAAA,CAAM,OAAAF,CAAA,EAAWF,CAAM,CACzC,CCJM,SAAUK,IAAc,SAAOC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACnC,IAAMC,EAAUC,GAAkBH,CAAM,EAExC,OAAOI,EAAQ,SAACC,EAAQC,EAAU,CAehC,QAdMC,EAAMP,EAAO,OACbQ,EAAc,IAAI,MAAMD,CAAG,EAI7BE,EAAWT,EAAO,IAAI,UAAA,CAAM,MAAA,EAAA,CAAK,EAGjCU,EAAQ,cAMHC,EAAC,CACRC,EAAUZ,EAAOW,CAAC,CAAC,EAAE,UACnBE,EACEP,EACA,SAACQ,EAAK,CACJN,EAAYG,CAAC,EAAIG,EACb,CAACJ,GAAS,CAACD,EAASE,CAAC,IAEvBF,EAASE,CAAC,EAAI,IAKbD,EAAQD,EAAS,MAAMM,EAAQ,KAAON,EAAW,MAEtD,EAGAO,EAAI,CACL,GAnBIL,EAAI,EAAGA,EAAIJ,EAAKI,MAAhBA,CAAC,EAwBVN,EAAO,UACLQ,EAAyBP,EAAY,SAACQ,EAAK,CACzC,GAAIJ,EAAO,CAET,IAAMO,EAAMC,EAAA,CAAIJ,CAAK,EAAAK,EAAKX,CAAW,CAAA,EACrCF,EAAW,KAAKJ,EAAUA,EAAO,MAAA,OAAAgB,EAAA,CAAA,EAAAC,EAAIF,CAAM,CAAA,CAAA,EAAIA,CAAM,EAEzD,CAAC,CAAC,CAEN,CAAC,CACH,CCxFM,SAAUG,IAAG,SAAOC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACxB,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChCL,GAAS,MAAA,OAAAM,EAAA,CAACF,CAA8B,EAAAG,EAAMN,CAAuC,CAAA,CAAA,EAAE,UAAUI,CAAU,CAC7G,CAAC,CACH,CCCM,SAAUG,IAAO,SAAkCC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACvD,OAAOC,GAAG,MAAA,OAAAC,EAAA,CAAA,EAAAC,EAAIJ,CAAW,CAAA,CAAA,CAC3B,CCYO,SAASK,IAAmC,CACjD,IAAMC,EAAY,IAAIC,GAAwB,CAAC,EAC/C,OAAAC,EAAU,SAAU,mBAAoB,CAAE,KAAM,EAAK,CAAC,EACnD,UAAU,IAAMF,EAAU,KAAK,QAAQ,CAAC,EAGpCA,CACT,CCHO,SAASG,EACdC,EAAkBC,EAAmB,SAChC,CACL,OAAO,MAAM,KAAKA,EAAK,iBAAoBD,CAAQ,CAAC,CACtD,CAuBO,SAASE,EACdF,EAAkBC,EAAmB,SAClC,CACH,IAAME,EAAKC,GAAsBJ,EAAUC,CAAI,EAC/C,GAAI,OAAOE,GAAO,YAChB,MAAM,IAAI,eACR,8BAA8BH,CAAQ,iBACxC,EAGF,OAAOG,CACT,CAsBO,SAASC,GACdJ,EAAkBC,EAAmB,SACtB,CACf,OAAOA,EAAK,cAAiBD,CAAQ,GAAK,MAC5C,CAOO,SAASK,IAA4C,CAnH5D,IAAAC,EAAAC,EAAAC,EAAAC,EAoHE,OACEA,GAAAD,GAAAD,GAAAD,EAAA,SAAS,gBAAT,YAAAA,EAAwB,aAAxB,YAAAC,EAAoC,gBAApC,KAAAC,EACA,SAAS,gBADT,KAAAC,EAEA,MAEJ,CCvEA,IAAMC,GAAYC,EAChBC,EAAU,SAAS,KAAM,SAAS,EAClCA,EAAU,SAAS,KAAM,UAAU,CACrC,EACG,KACCC,GAAa,CAAC,EACdC,EAAU,MAAS,EACnBC,EAAI,IAAMC,GAAiB,GAAK,SAAS,IAAI,EAC7CC,EAAY,CAAC,CACf,EAaK,SAASC,GACdC,EACqB,CACrB,OAAOT,GACJ,KACCK,EAAIK,GAAUD,EAAG,SAASC,CAAM,CAAC,EACjCC,EAAqB,CACvB,CACJ,CC7BO,SAASC,GACdC,EAAiBC,EACI,CACrB,OAAOC,EAAM,IAAMC,EACjBC,EAAUJ,EAAI,YAAY,EAAE,KAAKK,EAAI,IAAM,EAAI,CAAC,EAChDD,EAAUJ,EAAI,YAAY,EAAE,KAAKK,EAAI,IAAM,EAAK,CAAC,CACnD,EACG,KACCJ,EAAUK,GAASC,GAAUC,GAAM,CAAC,CAACD,EAASN,CAAO,CAAC,EAAIQ,GAC1DC,EAAUV,EAAG,QAAQ,QAAQ,CAAC,CAChC,CACF,CACF,CCPA,SAASW,GAAYC,EAAiBC,EAA8B,CAGlE,GAAI,OAAOA,GAAU,UAAY,OAAOA,GAAU,SAChDD,EAAG,WAAaC,EAAM,SAAS,UAGtBA,aAAiB,KAC1BD,EAAG,YAAYC,CAAK,UAGX,MAAM,QAAQA,CAAK,EAC5B,QAAWC,KAAQD,EACjBF,GAAYC,EAAIE,CAAI,CAE1B,CAyBO,SAASC,EACdC,EAAaC,KAAmCC,EAC7C,CACH,IAAMN,EAAK,SAAS,cAAcI,CAAG,EAGrC,GAAIC,EACF,QAAWE,KAAQ,OAAO,KAAKF,CAAU,EACnC,OAAOA,EAAWE,CAAI,GAAM,cAI5B,OAAOF,EAAWE,CAAI,GAAM,UAC9BP,EAAG,aAAaO,EAAMF,EAAWE,CAAI,CAAC,EAEtCP,EAAG,aAAaO,EAAM,EAAE,GAI9B,QAAWN,KAASK,EAClBP,GAAYC,EAAIC,CAAK,EAGvB,OAAOD,CACT,CC9EO,SAASQ,GAAMC,EAAuB,CAC3C,GAAIA,EAAQ,IAAK,CACf,IAAMC,EAAS,GAAGD,EAAQ,KAAO,IAAO,IACxC,MAAO,KAAKA,EAAQ,MAAY,KAAM,QAAQC,CAAM,CAAC,GACvD,KACE,QAAOD,EAAM,SAAS,CAE1B,CCCO,SAASE,GAAYC,EAA+B,CACzD,IAAMC,EAASC,EAAE,SAAU,CAAE,IAAAF,CAAI,CAAC,EAClC,OAAOG,EAAM,KACX,SAAS,KAAK,YAAYF,CAAM,EACzBG,EACLC,EAAUJ,EAAQ,MAAM,EACxBI,EAAUJ,EAAQ,OAAO,EACtB,KACCK,EAAU,IACRC,GAAW,IAAM,IAAI,eAAe,mBAAmBP,CAAG,EAAE,CAAC,CAC9D,CACH,CACJ,EACG,KACCQ,EAAI,IAAG,EAAY,EACnBC,EAAS,IAAM,SAAS,KAAK,YAAYR,CAAM,CAAC,EAChDS,GAAK,CAAC,CACR,EACH,CACH,CCVA,IAAMC,GAAS,IAAIC,EAiBbC,GAAYC,EAAM,IACtB,OAAO,gBAAmB,YACtBC,GAAY,4CAA4C,EACxDC,EAAG,MAAS,CACjB,EACE,KACCC,EAAI,IAAM,IAAI,eAAeC,GAC3BA,EAAQ,QAAQC,GAASR,GAAO,KAAKQ,CAAK,CAAC,CAC5C,CAAC,EACFC,EAAUC,GAAYC,EAAMC,GAAOP,EAAGK,CAAQ,CAAC,EAAE,KAC/CG,EAAS,IAAMH,EAAS,WAAW,CAAC,CACtC,CAAC,EACDI,EAAY,CAAC,CACf,EAaK,SAASC,GACdC,EACa,CACb,MAAO,CACL,MAAQA,EAAG,YACX,OAAQA,EAAG,YACb,CACF,CAuBO,SAASC,GACdD,EACyB,CAMzB,IAAIE,EAASF,EACb,KAAOE,EAAO,cAAgB,GACxBA,EAAO,eACTA,EAASA,EAAO,cAMpB,OAAOhB,GAAU,KACfiB,EAAIT,GAAYA,EAAS,QAAQQ,CAAM,CAAC,EACxCT,EAAUC,GAAYV,GAAO,KAC3BoB,EAAOZ,GAASA,EAAM,SAAWU,CAAM,EACvCL,EAAS,IAAMH,EAAS,UAAUQ,CAAM,CAAC,CAC3C,CAAC,EACDZ,EAAI,IAAMS,GAAeC,CAAE,CAAC,EAC5BK,EAAUN,GAAeC,CAAE,CAAC,CAC9B,CACF,CC3HO,SAASM,GACdC,EACa,CACb,MAAO,CACL,MAAQA,EAAG,YACX,OAAQA,EAAG,YACb,CACF,CASO,SAASC,GACdD,EACyB,CACzB,IAAIE,EAASF,EAAG,cAChB,KAAOE,IAEHF,EAAG,aAAgBE,EAAO,aAC1BF,EAAG,cAAgBE,EAAO,eAE1BA,GAAUF,EAAKE,GAAQ,cAK3B,OAAOA,EAASF,EAAK,MACvB,CAYO,SAASG,GACdH,EACe,CACf,IAAMI,EAA4B,CAAC,EAG/BF,EAASF,EAAG,cAChB,KAAOE,IAEHF,EAAG,YAAeE,EAAO,aACzBF,EAAG,aAAeE,EAAO,eAEzBE,EAAW,KAAKF,CAAM,EAGxBA,GAAUF,EAAKE,GAAQ,cAKzB,OAAIE,EAAW,SAAW,GACxBA,EAAW,KAAK,SAAS,eAAe,EAGnCA,CACT,CC9CO,SAASC,GACdC,EACe,CACf,MAAO,CACL,EAAGA,EAAG,WACN,EAAGA,EAAG,SACR,CACF,CASO,SAASC,GACdD,EACe,CACf,IAAME,EAAOF,EAAG,sBAAsB,EACtC,MAAO,CACL,EAAGE,EAAK,EAAI,OAAO,QACnB,EAAGA,EAAK,EAAI,OAAO,OACrB,CACF,CAWO,SAASC,GACdH,EAC2B,CAC3B,OAAOI,EACLC,EAAU,OAAQ,MAAM,EACxBA,EAAU,OAAQ,QAAQ,CAC5B,EACG,KACCC,GAAU,EAAGC,EAAuB,EACpCC,EAAI,IAAMT,GAAiBC,CAAE,CAAC,EAC9BS,EAAUV,GAAiBC,CAAE,CAAC,CAChC,CACJ,CC3DO,SAASU,GACdC,EACe,CACf,MAAO,CACL,EAAGA,EAAG,WACN,EAAGA,EAAG,SACR,CACF,CAWO,SAASC,GACdD,EAC2B,CAC3B,OAAOE,EACLC,EAAUH,EAAI,QAAQ,EACtBG,EAAU,OAAQ,QAAQ,EAC1BA,EAAU,OAAQ,QAAQ,CAC5B,EACG,KACCC,GAAU,EAAGC,EAAuB,EACpCC,EAAI,IAAMP,GAAwBC,CAAE,CAAC,EACrCO,EAAUR,GAAwBC,CAAE,CAAC,CACvC,CACJ,CCzBA,IAAMQ,GAAS,IAAIC,EAUbC,GAAYC,EAAM,IAAMC,EAC5B,IAAI,qBAAqBC,GAAW,CAClC,QAAWC,KAASD,EAClBL,GAAO,KAAKM,CAAK,CACrB,EAAG,CACD,UAAW,CACb,CAAC,CACH,CAAC,EACE,KACCC,EAAUC,GAAYC,EAAMC,GAAON,EAAGI,CAAQ,CAAC,EAC5C,KACCG,EAAS,IAAMH,EAAS,WAAW,CAAC,CACtC,CACF,EACAI,EAAY,CAAC,CACf,EAaK,SAASC,GACdC,EACqB,CACrB,OAAOZ,GACJ,KACCa,EAAIP,GAAYA,EAAS,QAAQM,CAAE,CAAC,EACpCP,EAAUC,GAAYR,GACnB,KACCgB,EAAO,CAAC,CAAE,OAAAC,CAAO,IAAMA,IAAWH,CAAE,EACpCH,EAAS,IAAMH,EAAS,UAAUM,CAAE,CAAC,EACrCI,EAAI,CAAC,CAAE,eAAAC,CAAe,IAAMA,CAAc,CAC5C,CACF,CACF,CACJ,CAaO,SAASC,GACdN,EAAiBO,EAAY,GACR,CACrB,OAAOC,GAA0BR,CAAE,EAChC,KACCI,EAAI,CAAC,CAAE,EAAAK,CAAE,IAAM,CACb,IAAMC,EAAUC,GAAeX,CAAE,EAC3BY,EAAUC,GAAsBb,CAAE,EACxC,OAAOS,GACLG,EAAQ,OAASF,EAAQ,OAASH,CAEtC,CAAC,EACDO,EAAqB,CACvB,CACJ,CCjFA,IAAMC,GAA4C,CAChD,OAAQC,EAAW,yBAAyB,EAC5C,OAAQA,EAAW,yBAAyB,CAC9C,EAaO,SAASC,GAAUC,EAAuB,CAC/C,OAAOH,GAAQG,CAAI,EAAE,OACvB,CAaO,SAASC,GAAUD,EAAcE,EAAsB,CACxDL,GAAQG,CAAI,EAAE,UAAYE,GAC5BL,GAAQG,CAAI,EAAE,MAAM,CACxB,CAWO,SAASG,GAAYH,EAAmC,CAC7D,IAAMI,EAAKP,GAAQG,CAAI,EACvB,OAAOK,EAAUD,EAAI,QAAQ,EAC1B,KACCE,EAAI,IAAMF,EAAG,OAAO,EACpBG,EAAUH,EAAG,OAAO,CACtB,CACJ,CC9BA,SAASI,GACPC,EAAiBC,EACR,CACT,OAAQD,EAAG,YAAa,CAGtB,KAAK,iBAEH,OAAIA,EAAG,OAAS,QACP,SAAS,KAAKC,CAAI,EAElB,GAGX,KAAK,kBACL,KAAK,oBACH,MAAO,GAGT,QACE,OAAOD,EAAG,iBACd,CACF,CAWO,SAASE,IAAwC,CACtD,OAAOC,EACLC,EAAU,OAAQ,kBAAkB,EAAE,KAAKC,EAAI,IAAM,EAAI,CAAC,EAC1DD,EAAU,OAAQ,gBAAgB,EAAE,KAAKC,EAAI,IAAM,EAAK,CAAC,CAC3D,EACG,KACCC,EAAU,EAAK,CACjB,CACJ,CAOO,SAASC,IAAsC,CACpD,IAAMC,EAAYJ,EAAyB,OAAQ,SAAS,EACzD,KACCK,EAAOC,GAAM,EAAEA,EAAG,SAAWA,EAAG,QAAQ,EACxCL,EAAIK,IAAO,CACT,KAAMC,GAAU,QAAQ,EAAI,SAAW,SACvC,KAAMD,EAAG,IACT,OAAQ,CACNA,EAAG,eAAe,EAClBA,EAAG,gBAAgB,CACrB,CACF,EAAc,EACdD,EAAO,CAAC,CAAE,KAAAG,EAAM,KAAAX,CAAK,IAAM,CACzB,GAAIW,IAAS,SAAU,CACrB,IAAMC,EAASC,GAAiB,EAChC,GAAI,OAAOD,GAAW,YACpB,MAAO,CAACd,GAAwBc,EAAQZ,CAAI,CAChD,CACA,MAAO,EACT,CAAC,EACDc,GAAM,CACR,EAGF,OAAOb,GAAiB,EACrB,KACCc,EAAUH,GAAWA,EAAqBI,EAAZT,CAAiB,CACjD,CACJ,CC1GO,SAASU,IAAmB,CACjC,OAAO,IAAI,IAAI,SAAS,IAAI,CAC9B,CAgBO,SAASC,GACdC,EAA4BC,EAAW,GACjC,CACN,GAAIC,EAAQ,oBAAoB,GAAK,CAACD,EAAU,CAC9C,IAAME,EAAKC,EAAE,IAAK,CAAE,KAAMJ,EAAI,IAAK,CAAC,EACpC,SAAS,KAAK,YAAYG,CAAE,EAC5BA,EAAG,MAAM,EACTA,EAAG,OAAO,CAIZ,MACE,SAAS,KAAOH,EAAI,IAExB,CASO,SAASK,IAA8B,CAC5C,OAAO,IAAIC,CACb,CCxCO,SAASC,IAA0B,CACxC,OAAO,SAAS,KAAK,MAAM,CAAC,CAC9B,CAYO,SAASC,GAAgBC,EAAoB,CAClD,IAAMC,EAAKC,EAAE,IAAK,CAAE,KAAMF,CAAK,CAAC,EAChCC,EAAG,iBAAiB,QAASE,GAAMA,EAAG,gBAAgB,CAAC,EACvDF,EAAG,MAAM,CACX,CAWO,SAASG,GACdC,EACoB,CACpB,OAAOC,EACLC,EAA2B,OAAQ,YAAY,EAC/CF,CACF,EACG,KACCG,EAAIV,EAAe,EACnBW,EAAUX,GAAgB,CAAC,EAC3BY,EAAOV,GAAQA,EAAK,OAAS,CAAC,EAC9BW,EAAY,CAAC,CACf,CACJ,CASO,SAASC,GACdP,EACyB,CACzB,OAAOD,GAAkBC,CAAS,EAC/B,KACCG,EAAIK,GAAMC,GAAmB,QAAQD,CAAE,IAAI,CAAE,EAC7CH,EAAOT,GAAM,OAAOA,GAAO,WAAW,CACxC,CACJ,CCtDO,SAASc,GAAWC,EAAoC,CAC7D,IAAMC,EAAQ,WAAWD,CAAK,EAC9B,OAAOE,GAA0BC,GAC/BF,EAAM,YAAY,IAAME,EAAKF,EAAM,OAAO,CAAC,CAC5C,EACE,KACCG,EAAUH,EAAM,OAAO,CACzB,CACJ,CAOO,SAASI,IAAkC,CAChD,IAAMJ,EAAQ,WAAW,OAAO,EAChC,OAAOK,EACLC,EAAU,OAAQ,aAAa,EAAE,KAAKC,EAAI,IAAM,EAAI,CAAC,EACrDD,EAAU,OAAQ,YAAY,EAAE,KAAKC,EAAI,IAAM,EAAK,CAAC,CACvD,EACG,KACCJ,EAAUH,EAAM,OAAO,CACzB,CACJ,CAcO,SAASQ,GACdC,EAA6BC,EACd,CACf,OAAOD,EACJ,KACCE,EAAUC,GAAUA,EAASF,EAAQ,EAAIG,CAAK,CAChD,CACJ,CC/BO,SAASC,GACdC,EAAmBC,EACD,CAClB,OAAO,IAAIC,EAAiBC,GAAY,CACtC,IAAMC,EAAM,IAAI,eAChB,OAAAA,EAAI,KAAK,MAAO,GAAGJ,CAAG,EAAE,EACxBI,EAAI,aAAe,OAGnBA,EAAI,iBAAiB,OAAQ,IAAM,CAC7BA,EAAI,QAAU,KAAOA,EAAI,OAAS,KACpCD,EAAS,KAAKC,EAAI,QAAQ,EAC1BD,EAAS,SAAS,GAIlBA,EAAS,MAAM,IAAI,MAAMC,EAAI,UAAU,CAAC,CAE5C,CAAC,EAGDA,EAAI,iBAAiB,QAAS,IAAM,CAClCD,EAAS,MAAM,IAAI,MAAM,eAAe,CAAC,CAC3C,CAAC,EAGDC,EAAI,iBAAiB,QAAS,IAAM,CAClCD,EAAS,SAAS,CACpB,CAAC,EAGG,OAAOF,GAAA,YAAAA,EAAS,YAAc,cAChCG,EAAI,iBAAiB,WAAYC,GAAS,CA/FhD,IAAAC,EAgGQ,GAAID,EAAM,iBACRJ,EAAQ,UAAW,KAAMI,EAAM,OAASA,EAAM,MAAS,GAAG,MAIrD,CACL,IAAME,GAASD,EAAAF,EAAI,kBAAkB,gBAAgB,IAAtC,KAAAE,EAA2C,EAC1DL,EAAQ,UAAW,KAAMI,EAAM,OAAS,CAACE,EAAU,GAAG,CACxD,CACF,CAAC,EAGDN,EAAQ,UAAU,KAAK,CAAC,GAI1BG,EAAI,KAAK,EACF,IAAMA,EAAI,MAAM,CACzB,CAAC,CACH,CAcO,SAASI,GACdR,EAAmBC,EACJ,CACf,OAAOF,GAAQC,EAAKC,CAAO,EACxB,KACCQ,EAAUC,GAAOA,EAAI,KAAK,CAAC,EAC3BC,EAAIC,GAAQ,KAAK,MAAMA,CAAI,CAAM,EACjCC,EAAY,CAAC,CACf,CACJ,CAUO,SAASC,GACdd,EAAmBC,EACG,CACtB,IAAMc,EAAM,IAAI,UAChB,OAAOhB,GAAQC,EAAKC,CAAO,EACxB,KACCQ,EAAUC,GAAOA,EAAI,KAAK,CAAC,EAC3BC,EAAID,GAAOK,EAAI,gBAAgBL,EAAK,WAAW,CAAC,EAChDG,EAAY,CAAC,CACf,CACJ,CAUO,SAASG,GACdhB,EAAmBC,EACG,CACtB,IAAMc,EAAM,IAAI,UAChB,OAAOhB,GAAQC,EAAKC,CAAO,EACxB,KACCQ,EAAUC,GAAOA,EAAI,KAAK,CAAC,EAC3BC,EAAID,GAAOK,EAAI,gBAAgBL,EAAK,UAAU,CAAC,EAC/CG,EAAY,CAAC,CACf,CACJ,CC5HO,SAASI,IAAoC,CAClD,MAAO,CACL,EAAG,KAAK,IAAI,EAAG,OAAO,EACtB,EAAG,KAAK,IAAI,EAAG,OAAO,CACxB,CACF,CASO,SAASC,IAAkD,CAChE,OAAOC,EACLC,EAAU,OAAQ,SAAU,CAAE,QAAS,EAAK,CAAC,EAC7CA,EAAU,OAAQ,SAAU,CAAE,QAAS,EAAK,CAAC,CAC/C,EACG,KACCC,EAAIJ,EAAiB,EACrBK,EAAUL,GAAkB,CAAC,CAC/B,CACJ,CC3BO,SAASM,IAAgC,CAC9C,MAAO,CACL,MAAQ,WACR,OAAQ,WACV,CACF,CASO,SAASC,IAA8C,CAC5D,OAAOC,EAAU,OAAQ,SAAU,CAAE,QAAS,EAAK,CAAC,EACjD,KACCC,EAAIH,EAAe,EACnBI,EAAUJ,GAAgB,CAAC,CAC7B,CACJ,CCXO,SAASK,IAAsC,CACpD,OAAOC,EAAc,CACnBC,GAAoB,EACpBC,GAAkB,CACpB,CAAC,EACE,KACCC,EAAI,CAAC,CAACC,EAAQC,CAAI,KAAO,CAAE,OAAAD,EAAQ,KAAAC,CAAK,EAAE,EAC1CC,EAAY,CAAC,CACf,CACJ,CCVO,SAASC,GACdC,EAAiB,CAAE,UAAAC,EAAW,QAAAC,CAAQ,EAChB,CACtB,IAAMC,EAAQF,EACX,KACCG,GAAwB,MAAM,CAChC,EAGIC,EAAUC,EAAc,CAACH,EAAOD,CAAO,CAAC,EAC3C,KACCK,EAAI,IAAMC,GAAiBR,CAAE,CAAC,CAChC,EAGF,OAAOM,EAAc,CAACJ,EAASD,EAAWI,CAAO,CAAC,EAC/C,KACCE,EAAI,CAAC,CAAC,CAAE,OAAAE,CAAO,EAAG,CAAE,OAAAC,EAAQ,KAAAC,CAAK,EAAG,CAAE,EAAAC,EAAG,EAAAC,CAAE,CAAC,KAAO,CACjD,OAAQ,CACN,EAAGH,EAAO,EAAIE,EACd,EAAGF,EAAO,EAAIG,EAAIJ,CACpB,EACA,KAAAE,CACF,EAAE,CACJ,CACJ,CCzBA,SAASG,GAAQC,EAA+B,CAC9C,OAAOC,EAA8BD,EAAQ,UAAWE,GAAMA,EAAG,IAAI,CACvE,CAWA,SAASC,GAAQH,EAA4B,CAC3C,IAAMI,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAUE,GAAQN,EAAO,YAAYM,CAAI,CAAC,EAGzCF,CACT,CAgBO,SAASG,GACdC,EAAaR,EAAS,IAAI,OAAOQ,CAAG,EACxB,CACZ,IAAMC,EAAQV,GAAQC,CAAM,EACtBI,EAAQD,GAAQH,CAAM,EAGtBU,EAAU,IAAIL,EACpBK,EAAQ,UAAUN,CAAK,EAGvB,IAAMO,EAAQP,EAAM,KAAKQ,EAAe,EAAGC,GAAQ,EAAI,CAAC,EACxD,OAAOH,EACJ,KACCE,EAAe,EACfE,GAAUL,EAAM,KAAKM,EAAUJ,CAAK,CAAC,CAAC,EACtCK,GAAM,CACR,CACJ,CCJA,IAAMC,GAASC,EAAW,WAAW,EAC/BC,GAAiB,KAAK,MAAMF,GAAO,WAAY,EACrDE,GAAO,KAAO,GAAG,IAAI,IAAIA,GAAO,KAAMC,GAAY,CAAC,CAAC,GAW7C,SAASC,IAAwB,CACtC,OAAOF,EACT,CASO,SAASG,EAAQC,EAAqB,CAC3C,OAAOJ,GAAO,SAAS,SAASI,CAAI,CACtC,CAUO,SAASC,GACdC,EAAkBC,EACV,CACR,OAAO,OAAOA,GAAU,YACpBP,GAAO,aAAaM,CAAG,EAAE,QAAQ,IAAKC,EAAM,SAAS,CAAC,EACtDP,GAAO,aAAaM,CAAG,CAC7B,CChCO,SAASE,GACdC,EAASC,EAAmB,SACP,CACrB,OAAOC,EAAW,sBAAsBF,CAAI,IAAKC,CAAI,CACvD,CAYO,SAASE,GACdH,EAASC,EAAmB,SACL,CACvB,OAAOG,EAAY,sBAAsBJ,CAAI,IAAKC,CAAI,CACxD,CC7EO,SAASI,GACdC,EACsB,CACtB,IAAMC,EAASC,EAAW,6BAA8BF,CAAE,EAC1D,OAAOG,EAAUF,EAAQ,QAAS,CAAE,KAAM,EAAK,CAAC,EAC7C,KACCG,EAAI,IAAMF,EAAW,cAAeF,CAAE,CAAC,EACvCI,EAAIC,IAAY,CAAE,KAAM,UAAUA,EAAQ,SAAS,CAAE,EAAE,CACzD,CACJ,CASO,SAASC,GACdN,EACiC,CACjC,GAAI,CAACO,EAAQ,kBAAkB,GAAK,CAACP,EAAG,kBACtC,OAAOQ,EAGT,GAAI,CAACR,EAAG,OAAQ,CACd,IAAMK,EAAUH,EAAW,cAAeF,CAAE,EACxC,UAAUK,EAAQ,SAAS,IAAM,SAAS,YAAY,IACxDL,EAAG,OAAS,GAChB,CAGA,OAAOS,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAU,CAAC,CAAE,KAAAE,CAAK,IAAM,CAC5BZ,EAAG,OAAS,GAGZ,SAAiB,aAAcY,CAAI,CACrC,CAAC,EAGMb,GAAcC,CAAE,EACpB,KACCa,EAAIC,GAASJ,EAAM,KAAKI,CAAK,CAAC,EAC9BC,EAAS,IAAML,EAAM,SAAS,CAAC,EAC/BN,EAAIU,GAAUE,EAAA,CAAE,IAAKhB,GAAOc,EAAQ,CACtC,CACJ,CAAC,CACH,CC5BO,SAASG,GACdC,EAAiB,CAAE,QAAAC,CAAQ,EACN,CACrB,OAAOA,EACJ,KACCC,EAAIC,IAAW,CAAE,OAAQA,IAAWH,CAAG,EAAE,CAC3C,CACJ,CAYO,SAASI,GACdJ,EAAiBK,EACe,CAChC,IAAMC,EAAY,IAAIC,EACtB,OAAAD,EAAU,UAAU,CAAC,CAAE,OAAAE,CAAO,IAAM,CAClCR,EAAG,OAASQ,CACd,CAAC,EAGMT,GAAaC,EAAIK,CAAO,EAC5B,KACCI,EAAIC,GAASJ,EAAU,KAAKI,CAAK,CAAC,EAClCC,EAAS,IAAML,EAAU,SAAS,CAAC,EACnCJ,EAAIQ,GAAUE,EAAA,CAAE,IAAKZ,GAAOU,EAAQ,CACtC,CACJ,CCnEO,SAASG,GACdC,EAAaC,EACA,CACb,OAAIA,IAAU,SAEVC,EAAC,OAAI,MAAM,gCAAgC,GAAIF,EAAI,KAAK,WACtDE,EAAC,OAAI,MAAM,+BAA+B,CAC5C,EAIAA,EAAC,OAAI,MAAM,aAAa,GAAIF,EAAI,KAAK,WACnCE,EAAC,OAAI,MAAM,+BAA+B,CAC5C,CAGN,CAGO,SAASC,MACXC,EACU,CACb,OACEF,EAAC,OAAI,MAAM,cAAc,KAAK,WAC5BA,EAAC,OAAI,MAAM,iCACRE,CACH,CACF,CAEJ,CCvCO,SAASC,GACdC,EAAqBC,EACR,CAIb,GAHAA,EAASA,EAAS,GAAGA,CAAM,eAAeD,CAAE,GAAK,OAG7CC,EAAQ,CACV,IAAMC,EAASD,EAAS,IAAIA,CAAM,GAAK,OACvC,OACEE,EAAC,SAAM,MAAM,gBAAgB,SAAU,GACpCC,GAAcH,CAAM,EACrBE,EAAC,KAAE,KAAMD,EAAQ,MAAM,uBAAuB,SAAU,IACtDC,EAAC,QAAK,wBAAuBH,EAAI,CACnC,CACF,CAEJ,KACE,QACEG,EAAC,SAAM,MAAM,gBAAgB,SAAU,GACpCC,GAAcH,CAAM,EACrBE,EAAC,QAAK,MAAM,uBAAuB,SAAU,IAC3CA,EAAC,QAAK,wBAAuBH,EAAI,CACnC,CACF,CAGN,CC5BO,SAASK,GAAsBC,EAAyB,CAC7D,OACEC,EAAC,UACC,MAAM,uBACN,MAAOC,GAAY,gBAAgB,EACnC,wBAAuB,IAAIF,CAAE,UAC9B,CAEL,CCtBA,IAAAG,GAAuB,SA+BvB,SAASC,GACPC,EAAsBC,EACT,CACb,IAAMC,EAASD,EAAO,EAChBE,EAASF,EAAO,EAGhBG,EAAU,OAAO,KAAKJ,EAAS,KAAK,EACvC,OAAOK,GAAO,CAACL,EAAS,MAAMK,CAAG,CAAC,EAClC,OAAyB,CAACC,EAAMD,IAAQ,CACvC,GAAGC,EAAMC,EAAC,cAAK,GAAAC,SAAWH,CAAG,CAAE,EAAQ,GACzC,EAAG,CAAC,CAAC,EACJ,MAAM,EAAG,EAAE,EAGRI,EAASC,GAAc,EACvBC,EAAM,IAAI,IAAIX,EAAS,SAAUS,EAAO,IAAI,EAC9CG,EAAQ,kBAAkB,GAC5BD,EAAI,aAAa,IAAI,IAAK,OAAO,QAAQX,EAAS,KAAK,EACpD,OAAO,CAAC,CAAC,CAAEa,CAAK,IAAMA,CAAK,EAC3B,OAAO,CAACC,EAAW,CAACC,CAAK,IAAM,GAAGD,CAAS,IAAIC,CAAK,GAAG,KAAK,EAAG,EAAE,CACpE,EAGF,GAAM,CAAE,KAAAC,CAAK,EAAIN,GAAc,EAC/B,OACEH,EAAC,KAAE,KAAM,GAAGI,CAAG,GAAI,MAAM,yBAAyB,SAAU,IAC1DJ,EAAC,WACC,MAAM,uCACN,gBAAeP,EAAS,MAAM,QAAQ,CAAC,GAEtCE,EAAS,GAAKK,EAAC,OAAI,MAAM,iCAAiC,EAC1DL,EAAS,GAAKK,EAAC,UAAIP,EAAS,KAAM,EAClCE,GAAU,GAAKK,EAAC,UAAIP,EAAS,KAAM,EACnCG,EAAS,GAAKH,EAAS,KAAK,OAAS,GACpCA,EAAS,KAEVA,EAAS,MACRO,EAAC,OAAI,MAAM,WACRP,EAAS,KAAK,IAAIiB,GAAO,CACxB,IAAMC,EAAOF,EACTC,KAAOD,EACL,uBAAuBA,EAAKC,CAAG,CAAC,GAChC,cACF,GACJ,OACEV,EAAC,QAAK,MAAO,UAAUW,CAAI,IAAKD,CAAI,CAExC,CAAC,CACH,EAEDd,EAAS,GAAKC,EAAQ,OAAS,GAC9BG,EAAC,KAAE,MAAM,2BACNY,GAAY,4BAA4B,EAAE,KAAG,GAAGf,CACnD,CAEJ,CACF,CAEJ,CAaO,SAASgB,GACdC,EACa,CACb,IAAMC,EAAYD,EAAO,CAAC,EAAE,MACtBE,EAAO,CAAC,GAAGF,CAAM,EAEjBZ,EAASC,GAAc,EAGvBR,EAASqB,EAAK,UAAUC,GAErB,CADG,GAAG,IAAI,IAAIA,EAAI,SAAUf,EAAO,IAAI,CAAC,GACrC,SAAS,GAAG,CACvB,EACK,CAACgB,CAAO,EAAIF,EAAK,OAAOrB,EAAQ,CAAC,EAGnCwB,EAAQH,EAAK,UAAUC,GAAOA,EAAI,MAAQF,CAAS,EACnDI,IAAU,KACZA,EAAQH,EAAK,QAGf,IAAMI,EAAOJ,EAAK,MAAM,EAAGG,CAAK,EAC1BE,EAAOL,EAAK,MAAMG,CAAK,EAGvBG,EAAW,CACf9B,GAAqB0B,EAAS,EAAc,EAAE,CAACvB,GAAUwB,IAAU,EAAE,EACrE,GAAGC,EAAK,IAAIG,GAAW/B,GAAqB+B,EAAS,CAAW,CAAC,EACjE,GAAGF,EAAK,OAAS,CACfrB,EAAC,WAAQ,MAAM,0BACbA,EAAC,WAAQ,SAAU,IACjBA,EAAC,WACEqB,EAAK,OAAS,GAAKA,EAAK,SAAW,EAChCT,GAAY,wBAAwB,EACpCA,GAAY,2BAA4BS,EAAK,MAAM,CAEzD,CACF,EACC,GAAGA,EAAK,IAAIE,GAAW/B,GAAqB+B,EAAS,CAAW,CAAC,CACpE,CACF,EAAI,CAAC,CACP,EAGA,OACEvB,EAAC,MAAG,MAAM,0BACPsB,CACH,CAEJ,CC1IO,SAASE,GAAkBC,EAAiC,CACjE,OACEC,EAAC,MAAG,MAAM,oBACP,OAAO,QAAQD,CAAK,EAAE,IAAI,CAAC,CAACE,EAAKC,CAAK,IACrCF,EAAC,MAAG,MAAO,oCAAoCC,CAAG,IAC/C,OAAOC,GAAU,SAAWC,GAAMD,CAAK,EAAIA,CAC9C,CACD,CACH,CAEJ,CCAO,SAASE,GACdC,EACa,CACb,IAAMC,EAAU,kCAAkCD,CAAI,GACtD,OACEE,EAAC,OAAI,MAAOD,EAAS,OAAM,IACzBC,EAAC,UAAO,MAAM,gBAAgB,SAAU,GAAI,cAAY,OAAO,CACjE,CAEJ,CCpBO,SAASC,GAAYC,EAAiC,CAC3D,OACEC,EAAC,OAAI,MAAM,0BACTA,EAAC,OAAI,MAAM,qBACRD,CACH,CACF,CAEJ,CCcA,SAASE,GAAcC,EAA+B,CAzDtD,IAAAC,EA0DE,IAAMC,EAASC,GAAc,EAGvBC,EAAM,IAAI,IAAI,MAAMJ,EAAQ,OAAO,IAAKE,EAAO,IAAI,EACzD,OACEG,EAAC,MAAG,MAAM,oBACRA,EAAC,KAAE,KAAM,GAAGD,CAAG,GAAI,MAAM,oBACtBJ,EAAQ,QACRC,EAAAC,EAAO,UAAP,YAAAD,EAAgB,QAASD,EAAQ,QAAQ,OAAS,GACjDK,EAAC,QAAK,MAAM,qBACTL,EAAQ,QAAQ,CAAC,CACpB,CAEJ,CACF,CAEJ,CAcO,SAASM,GACdC,EAAqBC,EACR,CA1Ff,IAAAP,EA2FE,IAAMC,EAASC,GAAc,EAC7B,OAAAI,EAAWA,EAAS,OAAOP,GAAQ,CA5FrC,IAAAC,EA4FwC,SAACA,EAAAD,EAAQ,aAAR,MAAAC,EAAoB,QAAM,EAE/DI,EAAC,OAAI,MAAM,cACTA,EAAC,UACC,MAAM,sBACN,aAAYI,GAAY,gBAAgB,GAEvCD,EAAO,QACPP,EAAAC,EAAO,UAAP,YAAAD,EAAgB,QAASO,EAAO,QAAQ,OAAS,GAChDH,EAAC,QAAK,MAAM,qBACTG,EAAO,QAAQ,CAAC,CACnB,CAEJ,EACAH,EAAC,MAAG,MAAM,oBACPE,EAAS,IAAIR,EAAa,CAC7B,CACF,CAEJ,CCdA,IAAIW,GAAW,EAkBR,SAASC,GACdC,EACqB,CAMrB,IAAMC,EACJC,EAAc,CACZC,GAAkBH,CAAE,EACpBI,GAAkBJ,CAAE,CACtB,CAAC,EACE,KACCK,EAAI,CAAC,CAACC,EAAOC,CAAK,IAAMD,GAASC,CAAK,EACtCC,EAAqB,CACvB,EAMEC,EACJC,EAAM,IAAMC,GAAqBX,CAAE,CAAC,EAAE,KACpCY,GAASC,EAAyB,EAClCC,GAAa,CAAC,EAKdC,GAAkBd,CAAO,EACzBI,EAAI,IAAMW,GAAyBhB,CAAE,CAAC,CACxC,EAMF,OAAOC,EAAQ,KACbgB,GAAMC,GAAUA,CAAM,EACtBC,EAAU,IAAMjB,EAAc,CAACD,EAASQ,CAAO,CAAC,CAAC,EACjDJ,EAAI,CAAC,CAACa,EAAQE,CAAM,KAAO,CAAE,OAAAF,EAAQ,OAAAE,CAAO,EAAE,EAC9CC,GAAM,CACR,CACF,CAoBO,SAASC,GACdtB,EAAiBuB,EACe,CAChC,GAAM,CAAE,SAAAC,EAAU,UAAAC,CAAU,EAAIF,EAI1BG,EAAK,cAAc5B,IAAU,GAGnC,OAAOY,EAAM,IAAM,CACjB,IAAMiB,EAAQ,IAAIC,EAMZC,EAAQ,IAAIC,GAAgB,EAAK,EACvCH,EAAM,KAAKI,EAAe,EAAGC,GAAQ,EAAK,CAAC,EACxC,UAAUH,CAAK,EAUlB,IAAMI,EAAQJ,EAAM,KAClBK,GAAShB,GAAUiB,GAAM,CAAC,CAACjB,EAAS,IAAKkB,EAAc,CAAC,EACxD5B,EAAqB,EACrBW,EAAUD,GAAUA,EAASM,EAAWa,CAAK,EAC7CC,EAAIC,GAAQA,EAAK,GAAKb,CAAE,EACxBL,GAAM,CACR,EAIAnB,EAAc,CACZyB,EAAM,KAAKtB,EAAI,CAAC,CAAE,OAAAa,CAAO,IAAMA,CAAM,CAAC,EACtCe,EAAM,KACJd,EAAUoB,GAAQnC,GAAkBmC,EAAM,GAAG,CAAC,EAC9CC,EAAU,EAAK,CACjB,CACF,CAAC,EACE,KAAKnC,EAAIoC,GAAUA,EAAO,KAAKvB,GAAUA,CAAM,CAAC,CAAC,EACjD,UAAUW,CAAK,EAMlB,IAAMa,EAAUb,EAAM,KACpBc,EAAOzB,GAAUA,CAAM,EACvB0B,GAAeX,EAAOR,CAAS,EAC/BpB,EAAI,CAAC,CAACwC,EAAGN,EAAM,CAAE,KAAAO,CAAK,CAAC,IAAM,CAC3B,IAAMC,EAAO/C,EAAG,sBAAsB,EAChCgD,EAAID,EAAK,MAAQ,EAIvB,GAAIR,EAAK,OAAS,UAChB,MAAO,CAAE,EAAAS,EAAG,EAAG,EAAID,EAAK,MAAO,EAI1B,GAAIA,EAAK,GAAKD,EAAK,OAAS,EAAG,CACpC,GAAM,CAAE,OAAAG,CAAO,EAAIC,GAAeX,CAAI,EACtC,MAAO,CAAE,EAAAS,EAAG,EAAG,IAAMC,CAAO,CAC9B,KACE,OAAO,CAAE,EAAAD,EAAG,EAAG,GAAMD,EAAK,MAAO,CAErC,CAAC,CACH,EAIA,OAAA7C,EAAc,CAAC+B,EAAON,EAAOe,CAAO,CAAC,EAClC,UAAU,CAAC,CAACH,EAAM,CAAE,OAAAnB,CAAO,EAAG+B,CAAM,IAAM,CACzCZ,EAAK,MAAM,YAAY,sBAAuB,GAAGnB,EAAO,CAAC,IAAI,EAC7DmB,EAAK,MAAM,YAAY,sBAAuB,GAAGnB,EAAO,CAAC,IAAI,EAI7DmB,EAAK,MAAM,YAAY,iBAAkB,GAAGY,EAAO,CAAC,IAAI,EACxDZ,EAAK,MAAM,YAAY,iBAAkB,GAAGY,EAAO,CAAC,IAAI,EAIxDZ,EAAK,UAAU,OAAO,mBAAuBY,EAAO,EAAK,CAAC,EAC1DZ,EAAK,UAAU,OAAO,sBAAuBY,EAAO,GAAK,CAAC,CAC5D,CAAC,EAIHtB,EAAM,KACJc,EAAOzB,GAAUA,CAAM,EACvB0B,GAAeX,EAAO,CAACY,EAAGN,IAASA,CAAI,EACvCI,EAAOJ,GAAQA,EAAK,OAAS,SAAS,CACxC,EACG,UAAUA,GAAQ,CACjB,IAAMO,EAAOI,GAAeE,EAAW,aAAcb,CAAI,CAAC,EAI1DA,EAAK,MAAM,YAAY,qBAAsB,GAAGO,EAAK,KAAK,IAAI,EAC9DP,EAAK,MAAM,YAAY,oBAAsB,KAAQ,CACvD,CAAC,EAMHV,EAAM,KACJrB,EAAqB,EACrB6C,GAAUC,EAAuB,EACjCV,GAAeX,CAAK,CACtB,EACG,UAAU,CAAC,CAACf,EAAQqB,CAAI,IAAM,CAC7BA,EAAK,UAAU,OAAO,sBAAuBrB,CAAM,CACrD,CAAC,EAGHhB,EAAc,CACZ2B,EAAM,KAAKc,EAAOzB,GAAUA,CAAM,CAAC,EACnCe,CACF,CAAC,EACE,UAAU,CAAC,CAACY,EAAGN,CAAI,IAAM,CACpBA,EAAK,OAAS,UAChBvC,EAAG,aAAa,gBAAiB0B,CAAE,EACnC1B,EAAG,aAAa,gBAAiB,QAAQ,GAEzCA,EAAG,aAAa,mBAAoB0B,CAAE,CAE1C,CAAC,EAGHG,EAAM,KAAKc,EAAOzB,GAAU,CAACA,CAAM,CAAC,EACjC,UAAU,IAAM,CACflB,EAAG,gBAAgB,eAAe,EAClCA,EAAG,gBAAgB,kBAAkB,EACrCA,EAAG,gBAAgB,eAAe,CACpC,CAAC,EAGID,GAAcC,CAAE,EACpB,KACCsC,EAAIiB,GAAS5B,EAAM,KAAK4B,CAAK,CAAC,EAC9BC,EAAS,IAAM7B,EAAM,SAAS,CAAC,EAC/BtB,EAAIkD,GAAUE,EAAA,CAAE,IAAKzD,GAAOuD,EAAQ,CACtC,CACJ,CAAC,CACH,CAeO,SAASG,GACd1D,EAAiB,CAAE,UAAAyB,CAAU,EAC7BkC,EAAY,SAAS,KACW,CAChC,OAAOrC,GAActB,EAAI,CACvB,SAAU,IAAI4D,EAAwBC,GAAY,CAChD,IAAMC,EAAQ9D,EAAG,MACXuC,EAAOwB,GAAqBD,CAAK,EACvC,OAAAD,EAAS,KAAKtB,CAAI,EAClBvC,EAAG,gBAAgB,OAAO,EAE1B2D,EAAU,OAAOpB,CAAI,EACd,IAAM,CACXA,EAAK,OAAO,EACZvC,EAAG,aAAa,QAAS8D,CAAK,CAChC,CACF,CAAC,EACD,UAAArC,CACF,CAAC,CACH,CCjRO,SAASuC,GACdC,EAAiBC,EACO,CACxB,IAAMC,EAAUC,EAAM,IAAMC,EAAc,CACxCC,GAAmBL,CAAE,EACrBM,GAA0BL,CAAS,CACrC,CAAC,CAAC,EACC,KACCM,EAAI,CAAC,CAAC,CAAE,EAAAC,EAAG,EAAAC,CAAE,EAAGC,CAAM,IAAqB,CACzC,GAAM,CAAE,MAAAC,EAAO,OAAAC,CAAO,EAAIC,GAAeb,CAAE,EAC3C,MAAQ,CACN,EAAGQ,EAAIE,EAAO,EAAIC,EAAS,EAC3B,EAAGF,EAAIC,EAAO,EAAIE,EAAS,CAC7B,CACF,CAAC,CACH,EAGF,OAAOE,GAAkBd,CAAE,EACxB,KACCe,EAAUC,GAAUd,EACjB,KACCK,EAAIU,IAAW,CAAE,OAAAD,EAAQ,OAAAC,CAAO,EAAE,EAClCC,GAAK,CAAC,CAACF,GAAU,GAAQ,CAC3B,CACF,CACF,CACJ,CAWO,SAASG,GACdnB,EAAiBC,EAAwB,CAAE,QAAAmB,CAAQ,EAChB,CACnC,GAAM,CAACC,EAASC,CAAK,EAAI,MAAM,KAAKtB,EAAG,QAAQ,EAG/C,OAAOG,EAAM,IAAM,CACjB,IAAMoB,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGC,GAAQ,EAAI,CAAC,EACxD,OAAAJ,EAAM,UAAU,CAGd,KAAK,CAAE,OAAAN,CAAO,EAAG,CACfjB,EAAG,MAAM,YAAY,iBAAkB,GAAGiB,EAAO,CAAC,IAAI,EACtDjB,EAAG,MAAM,YAAY,iBAAkB,GAAGiB,EAAO,CAAC,IAAI,CACxD,EAGA,UAAW,CACTjB,EAAG,MAAM,eAAe,gBAAgB,EACxCA,EAAG,MAAM,eAAe,gBAAgB,CAC1C,CACF,CAAC,EAGD4B,GAAuB5B,CAAE,EACtB,KACC6B,EAAUJ,CAAK,CACjB,EACG,UAAUK,GAAW,CACpB9B,EAAG,gBAAgB,kBAAmB8B,CAAO,CAC/C,CAAC,EAGLC,EACER,EAAM,KAAKS,EAAO,CAAC,CAAE,OAAAhB,CAAO,IAAMA,CAAM,CAAC,EACzCO,EAAM,KAAKU,GAAa,GAAG,EAAGD,EAAO,CAAC,CAAE,OAAAhB,CAAO,IAAM,CAACA,CAAM,CAAC,CAC/D,EACG,UAAU,CAGT,KAAK,CAAE,OAAAA,CAAO,EAAG,CACXA,EACFhB,EAAG,QAAQqB,CAAO,EAElBA,EAAQ,OAAO,CACnB,EAGA,UAAW,CACTrB,EAAG,QAAQqB,CAAO,CACpB,CACF,CAAC,EAGHE,EACG,KACCW,GAAU,GAAIC,EAAuB,CACvC,EACG,UAAU,CAAC,CAAE,OAAAnB,CAAO,IAAM,CACzBK,EAAQ,UAAU,OAAO,qBAAsBL,CAAM,CACvD,CAAC,EAGLO,EACG,KACCa,GAAa,IAAKD,EAAuB,EACzCH,EAAO,IAAM,CAAC,CAAChC,EAAG,YAAY,EAC9BO,EAAI,IAAMP,EAAG,aAAc,sBAAsB,CAAC,EAClDO,EAAI,CAAC,CAAE,EAAAC,CAAE,IAAMA,CAAC,CAClB,EACG,UAAU,CAGT,KAAK6B,EAAQ,CACPA,EACFrC,EAAG,MAAM,YAAY,iBAAkB,GAAG,CAACqC,CAAM,IAAI,EAErDrC,EAAG,MAAM,eAAe,gBAAgB,CAC5C,EAGA,UAAW,CACTA,EAAG,MAAM,eAAe,gBAAgB,CAC1C,CACF,CAAC,EAGLsC,EAAsBhB,EAAO,OAAO,EACjC,KACCO,EAAUJ,CAAK,EACfO,EAAOO,GAAM,EAAEA,EAAG,SAAWA,EAAG,QAAQ,CAC1C,EACG,UAAUA,GAAM,CACfA,EAAG,gBAAgB,EACnBA,EAAG,eAAe,CACpB,CAAC,EAGLD,EAAsBhB,EAAO,WAAW,EACrC,KACCO,EAAUJ,CAAK,EACfe,GAAejB,CAAK,CACtB,EACG,UAAU,CAAC,CAACgB,EAAI,CAAE,OAAAvB,CAAO,CAAC,IAAM,CA3OzC,IAAAyB,EA8OU,GAAIF,EAAG,SAAW,GAAKA,EAAG,SAAWA,EAAG,QACtCA,EAAG,eAAe,UAGTvB,EAAQ,CACjBuB,EAAG,eAAe,EAGlB,IAAMG,EAAS1C,EAAG,cAAe,QAAQ,gBAAgB,EACrD0C,aAAkB,YACpBA,EAAO,MAAM,GAEbD,EAAAE,GAAiB,IAAjB,MAAAF,EAAoB,MACxB,CACF,CAAC,EAGLrB,EACG,KACCS,EAAUJ,CAAK,EACfO,EAAOY,GAAUA,IAAWvB,CAAO,EACnCwB,GAAM,GAAG,CACX,EACG,UAAU,IAAM7C,EAAG,MAAM,CAAC,EAGxBD,GAAgBC,EAAIC,CAAS,EACjC,KACC6C,EAAIC,GAASxB,EAAM,KAAKwB,CAAK,CAAC,EAC9BC,EAAS,IAAMzB,EAAM,SAAS,CAAC,EAC/BhB,EAAIwC,GAAUE,EAAA,CAAE,IAAKjD,GAAO+C,EAAQ,CACtC,CACJ,CAAC,CACH,CCxMA,SAASG,GAAUC,EAAuC,CACxD,OAAOA,EAAU,UAAY,OACzBC,EAAY,eAAgBD,CAAS,EACrC,CAACA,CAAS,CAChB,CASA,SAASE,GAAYF,EAAgC,CACnD,IAAMG,EAAkB,CAAC,EACzB,QAAWC,KAAML,GAAUC,CAAS,EAAG,CACrC,IAAMK,EAAgB,CAAC,EAGjBC,EAAK,SAAS,mBAAmBF,EAAI,WAAW,SAAS,EAC/D,QAASG,EAAOD,EAAG,SAAS,EAAGC,EAAMA,EAAOD,EAAG,SAAS,EACtDD,EAAM,KAAKE,CAAY,EAGzB,QAASC,KAAQH,EAAO,CACtB,IAAII,EAGJ,KAAQA,EAAQ,gBAAgB,KAAKD,EAAK,WAAY,GAAI,CACxD,GAAM,CAAC,CAAEE,EAAIC,CAAK,EAAIF,EACtB,GAAI,OAAOE,GAAU,YAAa,CAChC,IAAMC,EAASJ,EAAK,UAAUC,EAAM,KAAK,EACzCD,EAAOI,EAAO,UAAUF,EAAG,MAAM,EACjCP,EAAQ,KAAKS,CAAM,CAGrB,KAAO,CACLJ,EAAK,YAAcE,EACnBP,EAAQ,KAAKK,CAAI,EACjB,KACF,CACF,CACF,CACF,CACA,OAAOL,CACT,CAQA,SAASU,GAAKC,EAAqBC,EAA2B,CAC5DA,EAAO,OAAO,GAAG,MAAM,KAAKD,EAAO,UAAU,CAAC,CAChD,CAoBO,SAASE,GACdZ,EAAiBJ,EAAwB,CAAE,QAAAiB,EAAS,OAAAC,CAAO,EACxB,CAGnC,IAAMC,EAASnB,EAAU,QAAQ,MAAM,EACjCoB,EAASD,GAAA,YAAAA,EAAQ,GAGjBE,EAAc,IAAI,IACxB,QAAWT,KAAUV,GAAYF,CAAS,EAAG,CAC3C,GAAM,CAAC,CAAEU,CAAE,EAAIE,EAAO,YAAa,MAAM,WAAW,EAChDU,GAAmB,yBAAyBZ,CAAE,IAAKN,CAAE,IACvDiB,EAAY,IAAIX,EAAIa,GAAiBb,EAAIU,CAAM,CAAC,EAChDR,EAAO,YAAYS,EAAY,IAAIX,CAAE,CAAE,EAE3C,CAGA,OAAIW,EAAY,OAAS,EAChBG,EAGFC,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGC,GAAQ,EAAI,CAAC,EAGlDC,EAAsC,CAAC,EAC7C,OAAW,CAACrB,EAAIsB,CAAU,IAAKX,EAC7BU,EAAM,KAAK,CACTE,EAAW,cAAeD,CAAU,EACpCC,EAAW,yBAAyBvB,CAAE,IAAKN,CAAE,CAC/C,CAAC,EAGH,OAAAc,EAAO,KAAKgB,EAAUN,CAAK,CAAC,EACzB,UAAUO,GAAU,CACnB/B,EAAG,OAAS,CAAC+B,EAGb/B,EAAG,UAAU,OAAO,qBAAsB+B,CAAM,EAGhD,OAAW,CAACC,EAAOC,CAAK,IAAKN,EACtBI,EAGHtB,GAAKuB,EAAOC,CAAK,EAFjBxB,GAAKwB,EAAOD,CAAK,CAGvB,CAAC,EAGIE,EAAM,GAAG,CAAC,GAAGjB,CAAW,EAC5B,IAAI,CAAC,CAAC,CAAEW,CAAU,IACjBO,GAAgBP,EAAYhC,EAAW,CAAE,QAAAiB,CAAQ,CAAC,CACnD,CACH,EACG,KACCuB,EAAS,IAAMd,EAAM,SAAS,CAAC,EAC/Be,GAAM,CACR,CACJ,CAAC,CACH,CC7JA,SAASC,GAASC,EAA0C,CAC1D,GAAIA,EAAG,mBAAoB,CACzB,IAAMC,EAAUD,EAAG,mBACnB,GAAIC,EAAQ,UAAY,KACtB,OAAOA,EAGJ,GAAIA,EAAQ,UAAY,KAAO,CAACA,EAAQ,SAAS,OACpD,OAAOF,GAASE,CAAO,CAC3B,CAIF,CAcO,SAASC,GACdF,EAAiBG,EACkB,CACnC,OAAOC,EAAM,IAAM,CACjB,IAAMC,EAAON,GAASC,CAAE,EACxB,OAAO,OAAOK,GAAS,YACnBC,GAAoBD,EAAML,EAAIG,CAAO,EACrCI,CACN,CAAC,CACH,CCjEA,IAAAC,GAAwB,SA4ExB,IAAIC,GAAW,EAaf,SAASC,GAAkBC,EAA0C,CACnE,GAAIA,EAAG,mBAAoB,CACzB,IAAMC,EAAUD,EAAG,mBACnB,GAAIC,EAAQ,UAAY,KACtB,OAAOA,EAGJ,GAAIA,EAAQ,UAAY,KAAO,CAACA,EAAQ,SAAS,OACpD,OAAOF,GAAkBE,CAAO,CACpC,CAIF,CAgBO,SAASC,GACdF,EACsB,CACtB,OAAOG,GAAiBH,CAAE,EACvB,KACCI,EAAI,CAAC,CAAE,MAAAC,CAAM,KAEJ,CACL,WAFcC,GAAsBN,CAAE,EAElB,MAAQK,CAC9B,EACD,EACDE,GAAwB,YAAY,CACtC,CACJ,CAoBO,SAASC,GACdR,EAAiBS,EACiB,CAClC,GAAM,CAAE,QAASC,CAAM,EAAI,WAAW,SAAS,EAGzCC,EAAWC,EAAM,IAAM,CAC3B,IAAMC,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,GAAS,CAAC,CAAC,EACpCH,EAAM,UAAU,CAAC,CAAE,WAAAI,CAAW,IAAM,CAC9BA,GAAcP,EAChBV,EAAG,aAAa,WAAY,GAAG,EAE/BA,EAAG,gBAAgB,UAAU,CACjC,CAAC,EAGD,IAAMkB,EAAoD,CAAC,EAC3D,GAAI,GAAAC,QAAY,YAAY,IACtBnB,EAAG,QAAQ,OAAO,GACpBoB,EAAQ,mBAAmB,GAAK,CAACpB,EAAG,QAAQ,UAAU,GACrD,CACD,IAAMqB,EAASrB,EAAG,QAAQ,KAAK,EAC/BqB,EAAO,GAAK,UAAUvB,IAAU,GAGhC,IAAMwB,EAASC,GAAsBF,EAAO,EAAE,EAC9CA,EAAO,aAAaC,EAAQtB,CAAE,EAC1BoB,EAAQ,kBAAkB,GAC5BF,EAAS,KAAKM,GAAoBF,EAAQ,CAAE,SAAU,CAAC,CAAC,CAC5D,CAIF,IAAMG,EAAYzB,EAAG,QAAQ,YAAY,EACzC,GAAIyB,aAAqB,YAAa,CACpC,IAAMC,EAAO3B,GAAkB0B,CAAS,EAGxC,GAAI,OAAOC,GAAS,cAClBD,EAAU,UAAU,SAAS,UAAU,GACvCL,EAAQ,uBAAuB,GAC9B,CACD,IAAMO,EAAeC,GAAoBF,EAAM1B,EAAIS,CAAO,EAC1DS,EAAS,KACPf,GAAiBsB,CAAS,EACvB,KACCI,EAAUd,CAAK,EACfX,EAAI,CAAC,CAAE,MAAAC,EAAO,OAAAyB,CAAO,IAAMzB,GAASyB,CAAM,EAC1CC,EAAqB,EACrBC,EAAUC,GAAUA,EAASN,EAAeO,CAAK,CACnD,CACJ,CACF,CACF,CAOA,OADcC,EAAY,oBAAqBnC,CAAE,EACvC,QACRA,EAAG,UAAU,IAAI,kBAAkB,EAG9BE,GAAeF,CAAE,EACrB,KACCoC,EAAIC,GAASxB,EAAM,KAAKwB,CAAK,CAAC,EAC9BC,EAAS,IAAMzB,EAAM,SAAS,CAAC,EAC/BT,EAAIiC,GAAUE,EAAA,CAAE,IAAKvC,GAAOqC,EAAQ,EACpCG,GAAU,GAAGtB,CAAQ,CACvB,CACJ,CAAC,EAGD,OAAIE,EAAQ,cAAc,EACjBqB,GAAuBzC,CAAE,EAC7B,KACC0C,EAAOC,GAAWA,CAAO,EACzBC,GAAK,CAAC,EACNZ,EAAU,IAAMrB,CAAQ,CAC1B,EAGGA,CACT,CCnLO,SAASkC,GACdC,EAAwB,CAAE,QAAAC,EAAS,OAAAC,CAAO,EACrB,CACrB,IAAIC,EAAO,GACX,OAAOC,EAGLH,EACG,KACCI,EAAIC,GAAUA,EAAO,QAAQ,qBAAqB,CAAE,EACpDC,EAAOC,GAAWR,IAAOQ,CAAO,EAChCH,EAAI,KAAO,CACT,OAAQ,OAAQ,OAAQ,EAC1B,EAAa,CACf,EAGFH,EACG,KACCK,EAAOE,GAAUA,GAAU,CAACN,CAAI,EAChCO,EAAI,IAAMP,EAAOH,EAAG,IAAI,EACxBK,EAAII,IAAW,CACb,OAAQA,EAAS,OAAS,OAC5B,EAAa,CACf,CACJ,CACF,CAaO,SAASE,GACdX,EAAwBY,EACQ,CAChC,OAAOC,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAU,CAAC,CAAE,OAAAE,EAAQ,OAAAC,CAAO,IAAM,CACtCjB,EAAG,gBAAgB,OAAQgB,IAAW,MAAM,EACxCC,GACFjB,EAAG,eAAe,CACtB,CAAC,EAGMD,GAAaC,EAAIY,CAAO,EAC5B,KACCF,EAAIQ,GAASJ,EAAM,KAAKI,CAAK,CAAC,EAC9BC,EAAS,IAAML,EAAM,SAAS,CAAC,EAC/BT,EAAIa,GAAUE,EAAA,CAAE,IAAKpB,GAAOkB,EAAQ,CACtC,CACJ,CAAC,CACH,CCzIA,IAAAG,GAAA,mvLCqDA,IAAIC,GAKAC,GAAW,EAWf,SAASC,IAAiC,CACxC,OAAO,OAAO,SAAY,aAAe,mBAAmB,QACxDC,GAAY,kDAAkD,EAC9DC,EAAG,MAAS,CAClB,CAaO,SAASC,GACdC,EACgC,CAChC,OAAAA,EAAG,UAAU,OAAO,SAAS,EAC7BN,QAAaE,GAAa,EACvB,KACCK,EAAI,IAAM,QAAQ,WAAW,CAC3B,YAAa,GACb,SAAAC,GACA,SAAU,CACR,cAAe,OACf,gBAAiB,OACjB,aAAc,MAChB,CACF,CAAC,CAAC,EACFC,EAAI,IAAG,EAAY,EACnBC,EAAY,CAAC,CACf,GAGFV,GAAS,UAAU,IAAYW,GAAA,sBAC7BL,EAAG,UAAU,IAAI,SAAS,EAC1B,IAAMM,EAAK,aAAaX,IAAU,GAG5BY,EAAOC,EAAE,MAAO,CAAE,MAAO,SAAU,CAAC,EACpCC,EAAOT,EAAG,YAGV,CAAE,IAAAU,EAAK,GAAAC,CAAG,EAAI,MAAM,QAAQ,OAAOL,EAAIG,CAAI,EAG3CG,EAASL,EAAK,aAAa,CAAE,KAAM,QAAS,CAAC,EACnDK,EAAO,UAAYF,EAGnBV,EAAG,YAAYO,CAAI,EACnBI,GAAA,MAAAA,EAAKC,EACP,EAAC,EAGMlB,GACJ,KACCS,EAAI,KAAO,CAAE,IAAKH,CAAG,EAAE,CACzB,CACJ,CCtFA,IAAMa,GAAWC,EAAE,OAAO,EAgBnB,SAASC,GACdC,EACkC,CAClC,OAAAA,EAAG,YAAYH,EAAQ,EACvBA,GAAS,YAAYI,GAAYD,CAAE,CAAC,EAG7BE,EAAG,CAAE,IAAKF,CAAG,CAAC,CACvB,CC4BO,SAASG,GACdC,EACyB,CACzB,IAAMC,EAAUD,EAAO,KAAKE,GAASA,EAAM,OAAO,GAAKF,EAAO,CAAC,EAC/D,OAAOG,EAAM,GAAGH,EAAO,IAAIE,GAASE,EAAUF,EAAO,QAAQ,EAC1D,KACCG,EAAI,IAAMC,EAA6B,cAAcJ,EAAM,EAAE,IAAI,CAAC,CACpE,CACF,CAAC,EACE,KACCK,EAAUD,EAA6B,cAAcL,EAAQ,EAAE,IAAI,CAAC,EACpEI,EAAIG,IAAW,CAAE,OAAAA,CAAO,EAAE,CAC5B,CACJ,CAUO,SAASC,GACdC,EAAiB,CAAE,UAAAC,EAAW,QAAAC,CAAQ,EACF,CACpC,IAAMC,EAAYP,EAAW,iBAAkBI,CAAE,EAC3CV,EAASc,EAA8B,iBAAkBJ,CAAE,EAG3DK,EAAOC,GAAoB,MAAM,EACvCN,EAAG,OAAOK,CAAI,EAGd,IAAME,EAAOD,GAAoB,MAAM,EACvC,OAAAN,EAAG,OAAOO,CAAI,EAGPC,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGC,GAAQ,EAAI,CAAC,EACxDC,EAAc,CAACL,EAAOM,GAAiBf,CAAE,EAAGgB,GAAuBhB,CAAE,CAAC,CAAC,EACpE,KACCiB,EAAUN,CAAK,EACfO,GAAU,EAAGC,EAAuB,CACtC,EACG,UAAU,CAGT,KAAK,CAAC,CAAE,OAAArB,CAAO,EAAGsB,CAAI,EAAG,CACvB,IAAMC,EAASC,GAAiBxB,CAAM,EAChC,CAAE,MAAAyB,CAAM,EAAIC,GAAe1B,CAAM,EAGvCE,EAAG,MAAM,YAAY,mBAAoB,GAAGqB,EAAO,CAAC,IAAI,EACxDrB,EAAG,MAAM,YAAY,uBAAwB,GAAGuB,CAAK,IAAI,EAGzD,IAAME,EAAUC,GAAwBvB,CAAS,GAE/CkB,EAAO,EAAYI,EAAQ,GAC3BJ,EAAO,EAAIE,EAAQE,EAAQ,EAAIL,EAAK,QAEpCjB,EAAU,SAAS,CACjB,KAAM,KAAK,IAAI,EAAGkB,EAAO,EAAI,EAAE,EAC/B,SAAU,QACZ,CAAC,CACL,EAGA,UAAW,CACTrB,EAAG,MAAM,eAAe,kBAAkB,EAC1CA,EAAG,MAAM,eAAe,sBAAsB,CAChD,CACF,CAAC,EAGLc,EAAc,CACZa,GAA0BxB,CAAS,EACnCY,GAAiBZ,CAAS,CAC5B,CAAC,EACE,KACCc,EAAUN,CAAK,CACjB,EACG,UAAU,CAAC,CAACU,EAAQD,CAAI,IAAM,CAC7B,IAAMK,EAAUG,GAAsBzB,CAAS,EAC/CE,EAAK,OAASgB,EAAO,EAAI,GACzBd,EAAK,OAASc,EAAO,EAAII,EAAQ,MAAQL,EAAK,MAAQ,EACxD,CAAC,EAGL3B,EACEC,EAAUW,EAAM,OAAO,EAAE,KAAKV,EAAI,IAAM,EAAE,CAAC,EAC3CD,EAAUa,EAAM,OAAO,EAAE,KAAKZ,EAAI,IAAM,CAAE,CAAC,CAC7C,EACG,KACCsB,EAAUN,CAAK,CACjB,EACG,UAAUkB,GAAa,CACtB,GAAM,CAAE,MAAAN,CAAM,EAAIC,GAAerB,CAAS,EAC1CA,EAAU,SAAS,CACjB,KAAMoB,EAAQM,EACd,SAAU,QACZ,CAAC,CACH,CAAC,EAGL3B,EACG,KACCe,EAAUN,CAAK,EACfmB,EAAOtC,GAASF,EAAO,SAASE,CAAyB,CAAC,CAC5D,EACG,UAAUA,GAASA,EAAM,MAAM,CAAC,EAGrCW,EAAU,UAAU,IAAI,uBAAuB,EAC/C,QAAWX,KAASF,EAAQ,CAC1B,IAAMyC,EAAQnC,EAA6B,cAAcJ,EAAM,EAAE,IAAI,EACrEuC,EAAM,gBAAgBC,EAAE,IAAK,CAC3B,KAAM,IAAID,EAAM,OAAO,GACvB,SAAU,EACZ,EAAG,GAAG,MAAM,KAAKA,EAAM,UAAU,CAAC,CAAC,EAGnCrC,EAAsBqC,EAAM,kBAAoB,OAAO,EACpD,KACCd,EAAUN,CAAK,EACfmB,EAAOG,GAAM,EAAEA,EAAG,SAAWA,EAAG,QAAQ,EACxCC,EAAID,GAAM,CACRA,EAAG,eAAe,EAClBA,EAAG,gBAAgB,CACrB,CAAC,CACH,EAEG,UAAU,IAAM,CACf,QAAQ,aAAa,CAAC,EAAG,GAAI,IAAIF,EAAM,OAAO,EAAE,EAChDA,EAAM,MAAM,CACd,CAAC,CACP,CAGA,OAAII,EAAQ,mBAAmB,GAC7B1B,EAAM,KACJ2B,GAAK,CAAC,EACNC,GAAepC,CAAS,CAC1B,EACG,UAAU,CAAC,CAAC,CAAE,OAAAH,CAAO,EAAG,CAAE,OAAAuB,CAAO,CAAC,IAAM,CACvC,IAAMiB,EAAMxC,EAAO,UAAU,KAAK,EAClC,GAAIA,EAAO,aAAa,mBAAmB,EACzCA,EAAO,gBAAgB,mBAAmB,MAGrC,CACL,IAAMyC,EAAIvC,EAAG,UAAYqB,EAAO,EAGhC,QAAWmB,KAAOpC,EAAY,aAAa,EACzC,QAAWZ,KAASY,EAClB,iBAAkBoC,CACpB,EAAG,CACD,IAAMT,EAAQnC,EAAW,cAAcJ,EAAM,EAAE,IAAI,EACnD,GACEuC,IAAUjC,GACViC,EAAM,UAAU,KAAK,IAAMO,EAC3B,CACAP,EAAM,aAAa,oBAAqB,EAAE,EAC1CvC,EAAM,MAAM,EACZ,KACF,CACF,CAGF,OAAO,SAAS,CACd,IAAKQ,EAAG,UAAYuC,CACtB,CAAC,EAGD,IAAME,EAAO,SAAmB,QAAQ,GAAK,CAAC,EAC9C,SAAS,SAAU,CAAC,GAAG,IAAI,IAAI,CAACH,EAAK,GAAGG,CAAI,CAAC,CAAC,CAAC,CACjD,CACF,CAAC,EAGLhC,EAAM,KAAKQ,EAAUN,CAAK,CAAC,EACxB,UAAU,IAAM,CACf,QAAW+B,KAAStC,EAA8B,eAAgBJ,CAAE,EAClE0C,EAAM,MAAM,CAChB,CAAC,EAGIrD,GAAiBC,CAAM,EAC3B,KACC4C,EAAIS,GAASlC,EAAM,KAAKkC,CAAK,CAAC,EAC9BC,EAAS,IAAMnC,EAAM,SAAS,CAAC,EAC/Bd,EAAIgD,GAAUE,EAAA,CAAE,IAAK7C,GAAO2C,EAAQ,CACtC,CACJ,CAAC,EACE,KACCG,GAAYC,EAAc,CAC5B,CACJ,CCpMO,SAASC,GACdC,EAAiB,CAAE,UAAAC,EAAW,QAAAC,EAAS,OAAAC,CAAO,EACd,CAChC,OAAOC,EAGL,GAAGC,EAAY,4BAA6BL,CAAE,EAC3C,IAAIM,GAASC,GAAqBD,EAAO,CAAE,QAAAJ,EAAS,OAAAC,CAAO,CAAC,CAAC,EAGhE,GAAGE,EAAY,2BAA4BL,CAAE,EAC1C,IAAIM,GAASE,GAAeF,EAAO,CAAE,QAAAJ,EAAS,OAAAC,CAAO,CAAC,CAAC,EAG1D,GAAGE,EAAY,cAAeL,CAAE,EAC7B,IAAIM,GAASG,GAAaH,CAAK,CAAC,EAGnC,GAAGD,EAAY,qBAAsBL,CAAE,EACpC,IAAIM,GAASI,GAAeJ,CAAK,CAAC,EAGrC,GAAGD,EAAY,UAAWL,CAAE,EACzB,IAAIM,GAASK,GAAaL,EAAO,CAAE,QAAAJ,EAAS,OAAAC,CAAO,CAAC,CAAC,EAGxD,GAAGE,EAAY,cAAeL,CAAE,EAC7B,IAAIM,GAASM,GAAiBN,EAAO,CAAE,UAAAL,EAAW,QAAAC,CAAQ,CAAC,CAAC,EAG/D,GAAGG,EAAY,UAAWL,CAAE,EACzB,OAAO,IAAMa,EAAQ,kBAAkB,CAAC,EACxC,IAAIP,GAASQ,GAAoBR,EAAO,CAAE,UAAAL,CAAU,CAAC,CAAC,CAC3D,CACF,CCtDO,SAASc,GACdC,EAAkB,CAAE,OAAAC,CAAO,EACP,CACpB,OAAOA,EACJ,KACCC,EAAUC,GAAWC,EACnBC,EAAG,EAAI,EACPA,EAAG,EAAK,EAAE,KAAKC,GAAM,GAAI,CAAC,CAC5B,EACG,KACCC,EAAIC,IAAW,CAAE,QAAAL,EAAS,OAAAK,CAAO,EAAE,CACrC,CACF,CACF,CACJ,CAaO,SAASC,GACdC,EAAiBC,EACc,CAC/B,IAAMC,EAAQC,EAAW,cAAeH,CAAE,EAC1C,OAAOI,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAU,CAAC,CAAE,QAAAZ,EAAS,OAAAK,CAAO,IAAM,CACvCE,EAAG,UAAU,OAAO,oBAAqBF,CAAM,EAC/CI,EAAM,YAAcT,CACtB,CAAC,EAGMJ,GAAYW,EAAIC,CAAO,EAC3B,KACCM,EAAIC,GAASH,EAAM,KAAKG,CAAK,CAAC,EAC9BC,EAAS,IAAMJ,EAAM,SAAS,CAAC,EAC/BR,EAAIW,GAAUE,EAAA,CAAE,IAAKV,GAAOQ,EAAQ,CACtC,CACJ,CAAC,CACH,CCnDA,IAAIG,GAAW,EAiBR,SAASC,GACdC,EAAiBC,EACI,CACrB,SAAS,KAAK,OAAOD,CAAE,EAGvB,GAAM,CAAE,MAAAE,CAAM,EAAIC,GAAeH,CAAE,EACnCA,EAAG,MAAM,YAAY,qBAAsB,GAAGE,CAAK,IAAI,EACvDF,EAAG,OAAO,EAGV,IAAMI,EAAYC,GAAoBJ,CAAI,EACpCK,EACJ,OAAOF,GAAc,YACjBG,GAA0BH,CAAS,EACnCI,EAAG,CAAE,EAAG,EAAG,EAAG,CAAE,CAAC,EAGjBC,EAAUC,EACdC,GAAkBV,CAAI,EACtBW,GAAkBX,CAAI,CACxB,EACG,KACCY,EAAqB,CACvB,EAGF,OAAOC,EAAc,CAACL,EAASH,CAAO,CAAC,EACpC,KACCS,EAAI,CAAC,CAACC,EAAQC,CAAM,IAAM,CACxB,GAAI,CAAE,EAAAC,EAAG,EAAAC,CAAE,EAAIC,GAAiBnB,CAAI,EAC9BoB,EAAOlB,GAAeF,CAAI,EAU1BqB,EAAQrB,EAAK,QAAQ,OAAO,EAClC,OAAIqB,GAASrB,EAAK,gBAChBiB,GAAKI,EAAM,WAAarB,EAAK,cAAc,WAC3CkB,GAAKG,EAAM,UAAarB,EAAK,cAAc,WAEtC,CACL,OAAAe,EACA,OAAQ,CACN,EAAGE,EAAID,EAAO,EAAII,EAAK,MAAS,EAAInB,EAAQ,EAC5C,EAAGiB,EAAIF,EAAO,EAAII,EAAK,OAAS,CAClC,CACF,CACF,CAAC,CACH,CACJ,CASO,SAASE,GACdvB,EACgC,CAChC,IAAMwB,EAAQxB,EAAG,MACjB,GAAI,CAACwB,EAAM,OACT,OAAOC,EAGT,IAAMC,EAAK,aAAa5B,IAAU,GAC5B6B,EAAUC,GAAcF,EAAI,QAAQ,EACpCG,EAAUC,EAAW,cAAeH,CAAO,EACjD,OAAAE,EAAQ,UAAYL,EAGbO,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAU,CAGd,KAAK,CAAE,OAAAE,CAAO,EAAG,CACfP,EAAQ,MAAM,YAAY,iBAAkB,GAAGO,EAAO,CAAC,IAAI,EAC3DP,EAAQ,MAAM,YAAY,iBAAkB,GAAGO,EAAO,CAAC,IAAI,CAC7D,EAGA,UAAW,CACTP,EAAQ,MAAM,eAAe,gBAAgB,EAC7CA,EAAQ,MAAM,eAAe,gBAAgB,CAC/C,CACF,CAAC,EAGDjB,EACEsB,EAAM,KAAKG,EAAO,CAAC,CAAE,OAAAnB,CAAO,IAAMA,CAAM,CAAC,EACzCgB,EAAM,KAAKI,GAAa,GAAG,EAAGD,EAAO,CAAC,CAAE,OAAAnB,CAAO,IAAM,CAACA,CAAM,CAAC,CAC/D,EACG,UAAU,CAGT,KAAK,CAAE,OAAAA,CAAO,EAAG,CACXA,GACFhB,EAAG,sBAAsB,WAAY2B,CAAO,EAC5C3B,EAAG,aAAa,mBAAoB0B,CAAE,EACtC1B,EAAG,gBAAgB,OAAO,IAE1B2B,EAAQ,OAAO,EACf3B,EAAG,gBAAgB,kBAAkB,EACrCA,EAAG,aAAa,QAASwB,CAAK,EAElC,EAGA,UAAW,CACTG,EAAQ,OAAO,EACf3B,EAAG,gBAAgB,kBAAkB,EACrCA,EAAG,aAAa,QAASwB,CAAK,CAChC,CACF,CAAC,EAGHQ,EACG,KACCK,GAAU,GAAIC,EAAuB,CACvC,EACG,UAAU,CAAC,CAAE,OAAAtB,CAAO,IAAM,CACzBW,EAAQ,UAAU,OAAO,qBAAsBX,CAAM,CACvD,CAAC,EAMLgB,EACG,KACCO,GAAa,IAAKD,EAAuB,EACzCH,EAAO,IAAM,CAAC,CAACnC,EAAG,YAAY,EAC9Be,EAAI,IAAMf,EAAG,aAAc,sBAAsB,CAAC,EAClDe,EAAI,CAAC,CAAE,EAAAG,CAAE,IAAMA,CAAC,CAClB,EACC,UAAU,CAGT,KAAKsB,EAAQ,CACPA,EACFb,EAAQ,MAAM,YAAY,iBAAkB,GAAG,CAACa,CAAM,IAAI,EAE1Db,EAAQ,MAAM,eAAe,gBAAgB,CACjD,EAGA,UAAW,CACTA,EAAQ,MAAM,eAAe,gBAAgB,CAC/C,CACF,CAAC,EAGI5B,GAAa4B,EAAS3B,CAAE,EAC5B,KACCyC,EAAIC,GAASV,EAAM,KAAKU,CAAK,CAAC,EAC9BC,EAAS,IAAMX,EAAM,SAAS,CAAC,EAC/BjB,EAAI2B,GAAUE,EAAA,CAAE,IAAK5C,GAAO0C,EAAQ,CACtC,CACJ,CAAC,EACE,KACCG,GAAYC,EAAc,CAC5B,CACJ,CC7JA,SAASC,GAAS,CAAE,UAAAC,CAAU,EAAsC,CAClE,GAAI,CAACC,EAAQ,iBAAiB,EAC5B,OAAOC,EAAG,EAAK,EAGjB,IAAMC,EAAaH,EAChB,KACCI,EAAI,CAAC,CAAE,OAAQ,CAAE,EAAAC,CAAE,CAAE,IAAMA,CAAC,EAC5BC,GAAY,EAAG,CAAC,EAChBF,EAAI,CAAC,CAACG,EAAGC,CAAC,IAAM,CAACD,EAAIC,EAAGA,CAAC,CAAU,EACnCC,GAAwB,CAAC,CAC3B,EAGIC,EAAUC,EAAc,CAACX,EAAWG,CAAU,CAAC,EAClD,KACCS,EAAO,CAAC,CAAC,CAAE,OAAAC,CAAO,EAAG,CAAC,CAAER,CAAC,CAAC,IAAM,KAAK,IAAIA,EAAIQ,EAAO,CAAC,EAAI,GAAG,EAC5DT,EAAI,CAAC,CAAC,CAAE,CAACU,CAAS,CAAC,IAAMA,CAAS,EAClCC,EAAqB,CACvB,EAGIC,EAAUC,GAAY,QAAQ,EACpC,OAAON,EAAc,CAACX,EAAWgB,CAAO,CAAC,EACtC,KACCZ,EAAI,CAAC,CAAC,CAAE,OAAAS,CAAO,EAAGK,CAAM,IAAML,EAAO,EAAI,KAAO,CAACK,CAAM,EACvDH,EAAqB,EACrBI,EAAUC,GAAUA,EAASV,EAAUR,EAAG,EAAK,CAAC,EAChDmB,EAAU,EAAK,CACjB,CACJ,CAcO,SAASC,GACdC,EAAiBC,EACG,CACpB,OAAOC,EAAM,IAAMd,EAAc,CAC/Be,GAAiBH,CAAE,EACnBxB,GAASyB,CAAO,CAClB,CAAC,CAAC,EACC,KACCpB,EAAI,CAAC,CAAC,CAAE,OAAAuB,CAAO,EAAGC,CAAM,KAAO,CAC7B,OAAAD,EACA,OAAAC,CACF,EAAE,EACFb,EAAqB,CAACR,EAAGC,IACvBD,EAAE,SAAWC,EAAE,QACfD,EAAE,SAAWC,EAAE,MAChB,EACDqB,EAAY,CAAC,CACf,CACJ,CAaO,SAASC,GACdP,EAAiB,CAAE,QAAAQ,EAAS,MAAAC,CAAM,EACO,CACzC,OAAOP,EAAM,IAAM,CACjB,IAAMQ,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGC,GAAQ,EAAI,CAAC,EACxDJ,EACG,KACCxB,GAAwB,QAAQ,EAChC6B,GAAkBP,CAAO,CAC3B,EACG,UAAU,CAAC,CAAC,CAAE,OAAAX,CAAO,EAAG,CAAE,OAAAQ,CAAO,CAAC,IAAM,CACvCL,EAAG,UAAU,OAAO,oBAAqBH,GAAU,CAACQ,CAAM,EAC1DL,EAAG,OAASK,CACd,CAAC,EAGL,IAAMW,EAAWC,GAAKC,EAAY,UAAWlB,CAAE,CAAC,EAC7C,KACCX,EAAO,IAAMX,EAAQ,kBAAkB,CAAC,EACxCyC,GAASC,GAASC,GAAaD,CAAK,CAAC,CACvC,EAGF,OAAAX,EAAM,UAAUC,CAAK,EAGdF,EACJ,KACCc,EAAUV,CAAK,EACf/B,EAAI0C,GAAUC,EAAA,CAAE,IAAKxB,GAAOuB,EAAQ,EACpCE,GAAUT,EAAS,KAAKM,EAAUV,CAAK,CAAC,CAAC,CAC3C,CACJ,CAAC,CACH,CCjIO,SAASc,GACdC,EAAiB,CAAE,UAAAC,EAAW,QAAAC,CAAQ,EACb,CACzB,OAAOC,GAAgBH,EAAI,CAAE,UAAAC,EAAW,QAAAC,CAAQ,CAAC,EAC9C,KACCE,EAAI,CAAC,CAAE,OAAQ,CAAE,EAAAC,CAAE,CAAE,IAAM,CACzB,GAAM,CAAE,OAAAC,CAAO,EAAIC,GAAeP,CAAE,EACpC,MAAO,CACL,OAAQK,GAAKC,CACf,CACF,CAAC,EACDE,GAAwB,QAAQ,CAClC,CACJ,CAaO,SAASC,GACdT,EAAiBU,EACmB,CACpC,OAAOC,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EAClBD,EAAM,UAAU,CAGd,KAAK,CAAE,OAAAE,CAAO,EAAG,CACfd,EAAG,UAAU,OAAO,2BAA4Bc,CAAM,CACxD,EAGA,UAAW,CACTd,EAAG,UAAU,OAAO,0BAA0B,CAChD,CACF,CAAC,EAGD,IAAMe,EAAUC,GAAmB,gBAAgB,EACnD,OAAI,OAAOD,GAAY,YACdE,EAGFlB,GAAiBgB,EAASL,CAAO,EACrC,KACCQ,EAAIC,GAASP,EAAM,KAAKO,CAAK,CAAC,EAC9BC,EAAS,IAAMR,EAAM,SAAS,CAAC,EAC/BR,EAAIe,GAAUE,EAAA,CAAE,IAAKrB,GAAOmB,EAAQ,CACtC,CACJ,CAAC,CACH,CChEO,SAASG,GACdC,EAAiB,CAAE,UAAAC,EAAW,QAAAC,CAAQ,EACpB,CAGlB,IAAMC,EAAUD,EACb,KACCE,EAAI,CAAC,CAAE,OAAAC,CAAO,IAAMA,CAAM,EAC1BC,EAAqB,CACvB,EAGIC,EAAUJ,EACb,KACCK,EAAU,IAAMC,GAAiBT,CAAE,EAChC,KACCI,EAAI,CAAC,CAAE,OAAAC,CAAO,KAAO,CACnB,IAAQL,EAAG,UACX,OAAQA,EAAG,UAAYK,CACzB,EAAE,EACFK,GAAwB,QAAQ,CAClC,CACF,CACF,EAGF,OAAOC,EAAc,CAACR,EAASI,EAASN,CAAS,CAAC,EAC/C,KACCG,EAAI,CAAC,CAACQ,EAAQ,CAAE,IAAAC,EAAK,OAAAC,CAAO,EAAG,CAAE,OAAQ,CAAE,EAAAC,CAAE,EAAG,KAAM,CAAE,OAAAV,CAAO,CAAE,CAAC,KAChEA,EAAS,KAAK,IAAI,EAAGA,EACjB,KAAK,IAAI,EAAGQ,EAASE,EAAIH,CAAM,EAC/B,KAAK,IAAI,EAAGP,EAASU,EAAID,CAAM,CACnC,EACO,CACL,OAAQD,EAAMD,EACd,OAAAP,EACA,OAAQQ,EAAMD,GAAUG,CAC1B,EACD,EACDT,EAAqB,CAACU,EAAGC,IACvBD,EAAE,SAAWC,EAAE,QACfD,EAAE,SAAWC,EAAE,QACfD,EAAE,SAAWC,EAAE,MAChB,CACH,CACJ,CCxCO,SAASC,GACdC,EACqB,CACrB,IAAMC,EAAU,SAAkB,WAAW,GAAK,CAChD,MAAOD,EAAO,UAAUE,GAAS,WAC/BA,EAAM,aAAa,qBAAqB,CAC1C,EAAE,OAAO,CACX,EAGMC,EAAQ,KAAK,IAAI,EAAG,KAAK,IAAIF,EAAQ,MAAOD,EAAO,OAAS,CAAC,CAAC,EACpE,OAAOI,EAAG,GAAGJ,CAAM,EAChB,KACCK,GAASH,GAASI,EAAUJ,EAAO,QAAQ,EAAE,KAAKK,EAAI,IAAML,CAAK,CAAC,CAAC,EACnEM,EAAUR,EAAOG,CAAK,CAAC,EACvBI,EAAIL,IAAU,CACZ,MAAOF,EAAO,QAAQE,CAAK,EAC3B,MAAO,CACL,MAASA,EAAM,aAAa,qBAAqB,EACjD,OAASA,EAAM,aAAa,sBAAsB,EAClD,QAASA,EAAM,aAAa,uBAAuB,EACnD,OAASA,EAAM,aAAa,sBAAsB,CACpD,CACF,EAAa,EACbO,EAAY,CAAC,CACf,CACJ,CASO,SAASC,GACdC,EACgC,CAChC,IAAMX,EAASY,EAA8B,QAASD,CAAE,EAClDE,EAAOC,EAAE,OAAQ,CAAE,KAAM,aAAc,CAAC,EAC9C,SAAS,KAAK,YAAYD,CAAI,EAG9B,IAAME,EAASD,EAAE,OAAQ,CAAE,KAAM,cAAe,CAAC,EACjD,SAAS,KAAK,YAAYC,CAAM,EAGhC,IAAMC,EAASC,GAAW,+BAA+B,EACzD,OAAOC,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAUE,GAAW,CAIzB,GAHA,SAAS,KAAK,aAAa,0BAA2B,EAAE,EAGpDA,EAAQ,MAAM,QAAU,yBAA0B,CACpD,IAAMC,EAAQ,WAAW,+BAA+B,EAClDpB,EAAQ,SAAS,cAAcoB,EAAM,QACvC,wDACA,sDACJ,EAGAD,EAAQ,MAAM,OAAUnB,EAAM,aAAa,sBAAsB,EACjEmB,EAAQ,MAAM,QAAUnB,EAAM,aAAa,uBAAuB,EAClEmB,EAAQ,MAAM,OAAUnB,EAAM,aAAa,sBAAsB,CACnE,CAGA,OAAW,CAACqB,EAAKC,CAAK,IAAK,OAAO,QAAQH,EAAQ,KAAK,EACrD,SAAS,KAAK,aAAa,iBAAiBE,CAAG,GAAIC,CAAK,EAG1D,QAASrB,EAAQ,EAAGA,EAAQH,EAAO,OAAQG,IAAS,CAClD,IAAMsB,EAAQzB,EAAOG,CAAK,EAAE,mBACxBsB,aAAiB,cACnBA,EAAM,OAASJ,EAAQ,QAAUlB,EACrC,CAGA,SAAS,YAAakB,CAAO,CAC/B,CAAC,EAGDf,EAAyBK,EAAI,SAAS,EAAE,KACtCe,EAAOC,GAAMA,EAAG,MAAQ,OAAO,EAC/BC,GAAeT,EAAO,CAACU,EAAGR,IAAYA,CAAO,CAC/C,EACG,UAAU,CAAC,CAAE,MAAAlB,CAAM,IAAM,CACxBA,GAASA,EAAQ,GAAKH,EAAO,OAC7BA,EAAOG,CAAK,EAAE,MAAM,EACpBH,EAAOG,CAAK,EAAE,MAAM,CACtB,CAAC,EAGHgB,EACG,KACCZ,EAAI,IAAM,CACR,IAAMuB,EAASC,GAAoB,QAAQ,EACrCC,EAAS,OAAO,iBAAiBF,CAAM,EAG7C,OAAAf,EAAO,QAAUiB,EAAM,YAGhBA,EAAM,gBAAgB,MAAM,MAAM,EACtC,IAAIR,IAAU,CAACA,GAAO,SAAS,EAAE,EAAE,SAAS,EAAG,GAAG,CAAC,EACnD,KAAK,EAAE,CACZ,CAAC,CACH,EACG,UAAUS,GAASpB,EAAK,QAAU,IAAIoB,CAAK,EAAE,EAGlDd,EAAM,KAAKe,GAAUC,EAAc,CAAC,EACjC,UAAU,IAAM,CACf,SAAS,KAAK,gBAAgB,yBAAyB,CACzD,CAAC,EAGIpC,GAAaC,CAAM,EACvB,KACCoC,EAAUpB,EAAO,KAAKqB,GAAK,CAAC,CAAC,CAAC,EAC9BC,GAAO,EACPC,EAAIC,GAASrB,EAAM,KAAKqB,CAAK,CAAC,EAC9BC,EAAS,IAAMtB,EAAM,SAAS,CAAC,EAC/BZ,EAAIiC,GAAUE,EAAA,CAAE,IAAK/B,GAAO6B,EAAQ,CACtC,CACJ,CAAC,CACH,CChJO,SAASG,GACdC,EAAiB,CAAE,UAAAC,CAAU,EACI,CAGjC,OAAOC,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAU,CAAC,CAAE,MAAAE,CAAM,IAAM,CAC7BL,EAAG,MAAM,YAAY,sBAAuB,GAAGK,CAAK,EAAE,CACxD,CAAC,EAGMJ,EACJ,KACCK,EAAID,GAASF,EAAM,KAAK,CAAE,MAAAE,CAAM,CAAC,CAAC,EAClCE,EAAS,IAAMJ,EAAM,SAAS,CAAC,EAC/BK,EAAIH,IAAU,CAAE,IAAKL,EAAI,MAAAK,CAAM,EAAE,CACnC,CACJ,CAAC,CACH,CChEA,IAAAI,GAAwB,SAiCxB,SAASC,GAAQC,EAAyB,CACxCA,EAAG,aAAa,kBAAmB,EAAE,EACrC,IAAMC,EAAOD,EAAG,QAAQ,aAAa,EAC/BE,EAAOD,EACTA,EAAK,aAAa,WAAW,EAC7BD,EAAG,UACP,OAAAA,EAAG,gBAAgB,iBAAiB,EAC7BE,EAAK,QAAQ,CACtB,CAWO,SAASC,GACd,CAAE,OAAAC,CAAO,EACH,CACF,GAAAC,QAAY,YAAY,GAC1B,IAAIC,EAA8BC,GAAc,CAC9C,IAAI,GAAAF,QAAY,iDAAkD,CAChE,KAAML,GACJA,EAAG,aAAa,qBAAqB,GACrCD,GAAQS,EACNR,EAAG,aAAa,uBAAuB,CACzC,CAAC,CAEL,CAAC,EACE,GAAG,UAAWS,GAAMF,EAAW,KAAKE,CAAE,CAAC,CAC5C,CAAC,EACE,KACCC,EAAID,GAAM,CACQA,EAAG,QACX,MAAM,CAChB,CAAC,EACDE,EAAI,IAAMC,GAAY,kBAAkB,CAAC,CAC3C,EACG,UAAUR,CAAM,CAEzB,CCrCA,SAASS,GAAQC,EAAUC,EAAW,CACpC,OAAAD,EAAI,SAAWC,EAAK,SACpBD,EAAI,SAAWC,EAAK,SACbD,CACT,CA2BA,SAASE,GAAQC,EAAoBF,EAAoB,CACvD,IAAMG,EAAmB,IAAI,IAC7B,QAAWC,KAAMC,EAAY,MAAOH,CAAQ,EAAG,CAC7C,IAAMH,EAAMO,EAAW,MAAOF,CAAE,EAG1BG,EAAQ,CAACT,GAAQ,IAAI,IAAIC,EAAI,WAAY,EAAGC,CAAI,CAAC,EACvDG,EAAQ,IAAI,GAAGI,EAAM,CAAC,CAAC,GAAIA,CAAK,EAGhC,QAAWC,KAAQH,EAAY,kBAAmBD,CAAE,EAAG,CACrD,IAAMK,EAAOD,EAAK,aAAa,MAAM,EACjCC,GAAQ,MACVF,EAAM,KAAKT,GAAQ,IAAI,IAAIW,CAAI,EAAGT,CAAI,CAAC,CAC3C,CACF,CAGA,OAAOG,CACT,CAgBO,SAASO,GAAaV,EAAyC,CACpE,OAAOW,GAAW,IAAI,IAAI,cAAeX,CAAI,CAAC,EAC3C,KACCY,EAAIV,GAAYD,GAAQC,EAAU,IAAI,IAAIF,CAAI,CAAC,CAAC,EAChDa,GAAW,IAAMC,EAAG,IAAI,GAAK,CAAC,CAChC,CACJ,CClDA,SAASC,GACPC,EAAgBC,EACC,CACjB,GAAI,EAAED,EAAG,kBAAkB,SACzB,OAAOE,EAIT,IAAMC,EAAKH,EAAG,OAAO,QAAQ,GAAG,EAChC,GAAIG,IAAO,KACT,OAAOD,EAMT,GAAIC,EAAG,QAAUH,EAAG,SAAWA,EAAG,QAChC,OAAOE,EAQT,IAAME,EAAM,IAAI,IAAID,EAAG,IAAI,EAO3B,OANAC,EAAI,OAASA,EAAI,KAAO,GAMnBH,EAAQ,IAAI,GAAGG,CAAG,EAAE,GASzBJ,EAAG,eAAe,EACXK,EAAG,IAAI,IAAIF,EAAG,IAAI,CAAC,GATjBD,CAUX,CASA,SAASI,GAAKC,EAA8C,CAC1D,IAAMC,EAAO,IAAI,IACjB,QAAWL,KAAMM,EAAY,aAAcF,EAAS,IAAI,EACtDC,EAAK,IAAIL,EAAG,UAAWA,CAAE,EAG3B,OAAOK,CACT,CAYA,SAASE,GAAQH,EAA0C,CACzD,QAAWJ,KAAMM,EAAY,gBAAiBF,CAAQ,EACpD,QAAWI,IAAO,CAAC,OAAQ,KAAK,EAAG,CACjC,IAAMC,EAAQT,EAAG,aAAaQ,CAAG,EACjC,GAAIC,GAAS,CAAC,qBAAqB,KAAKA,CAAK,EAAG,CAE9CT,EAAGQ,CAAG,EAAIR,EAAGQ,CAAG,EAChB,KACF,CACF,CAGF,OAAON,EAAGE,CAAQ,CACpB,CASA,SAASM,GAAOC,EAAsC,CACpD,QAAWC,IAAY,CACrB,+BACA,gCACA,mCACA,+BACA,2BACA,2BACA,GAAGC,EAAQ,wBAAwB,EAC/B,CAAC,0BAA0B,EAC3B,CAAC,CACP,EAAG,CACD,IAAMC,EAASC,GAAmBH,CAAQ,EACpCI,EAASD,GAAmBH,EAAUD,CAAI,EAE9C,OAAOG,GAAW,aAClB,OAAOE,GAAW,aAElBF,EAAO,YAAYE,CAAM,CAE7B,CAGA,IAAMX,EAAOF,GAAK,QAAQ,EAC1B,OAAW,CAACc,EAAMjB,CAAE,IAAKG,GAAKQ,CAAI,EAC5BN,EAAK,IAAIY,CAAI,EACfZ,EAAK,OAAOY,CAAI,EAEhB,SAAS,KAAK,YAAYjB,CAAE,EAGhC,QAAWA,KAAMK,EAAK,OAAO,EAAG,CAC9B,IAAMa,EAAOlB,EAAG,aAAa,MAAM,EAI/BkB,IAAS,eAAiBA,IAAS,gBACrClB,EAAG,OAAO,CACd,CAIA,IAAMmB,EAAYC,GAAoB,WAAW,EACjD,OAAOC,GAAOf,EAAY,SAAUa,CAAS,CAAC,EAC3C,KACCG,EAAUtB,GAAM,CACd,IAAMuB,EAASZ,EAAK,cAAc,QAAQ,EAC1C,GAAIX,EAAG,IAAK,CACV,QAAWkB,KAAQlB,EAAG,kBAAkB,EACtCuB,EAAO,aAAaL,EAAMlB,EAAG,aAAakB,CAAI,CAAE,EAClD,OAAAlB,EAAG,YAAYuB,CAAM,EAGd,IAAIC,EAAWC,GAAY,CAChCF,EAAO,OAAS,IAAME,EAAS,SAAS,CAC1C,CAAC,CAGH,KACE,QAAAF,EAAO,YAAcvB,EAAG,YACxBA,EAAG,YAAYuB,CAAM,EACdxB,CAEX,CAAC,EACD2B,EAAe,EACfC,GAAQ,QAAQ,CAClB,CACJ,CAgBO,SAASC,GACd,CAAE,UAAAC,EAAW,UAAAC,EAAW,UAAAC,CAAU,EACZ,CACtB,IAAMC,EAASC,GAAc,EAC7B,GAAI,SAAS,WAAa,QACxB,OAAOlC,EAIT,IAAMmC,EAAWC,GAAaH,EAAO,IAAI,EAUzC9B,EAAG,QAAQ,EACR,UAAUK,EAAO,EAUpB,IAAM6B,EACJC,EAAsB,SAAS,KAAM,OAAO,EACzC,KACCC,GAAkBJ,CAAQ,EAC1BZ,EAAU,CAAC,CAACzB,EAAIC,CAAO,IAAMF,GAAOC,EAAIC,CAAO,CAAC,EAChDyC,GAAM,CACR,EAIEC,EACJH,EAAyB,OAAQ,UAAU,EACxC,KACCI,EAAIC,EAAW,EACfH,GAAM,CACR,EAMJH,EAAS,KAAKO,GAAeb,CAAS,CAAC,EACpC,UAAU,CAAC,CAAC7B,EAAK,CAAE,OAAA2C,CAAO,CAAC,IAAM,CAChC,QAAQ,aAAaA,EAAQ,EAAE,EAC/B,QAAQ,UAAU,KAAM,GAAI3C,CAAG,CACjC,CAAC,EAMH4C,EAAMT,EAAUI,CAAQ,EACrB,UAAUX,CAAS,EActB,IAAMiB,EACJjB,EAAU,KACRkB,GAAwB,UAAU,EAClCzB,EAAUrB,GAAO+C,GAAY/C,EAAK,CAAE,UAAA8B,CAAU,CAAC,EAC5C,KACCkB,GAAW,KACTC,GAAYjD,EAAK,EAAI,EACdF,EACR,CACH,CACF,EAIAuB,EAAUf,EAAO,EACjBe,EAAUZ,EAAM,EAChB6B,GAAM,CACR,EAUF,OAAAM,EACEC,EAAU,KAAKH,GAAed,EAAW,CAACsB,EAAGlD,IAAQA,CAAG,CAAC,EASzD6C,EAAU,KACRxB,EAAU,IAAMO,CAAS,EACzBkB,GAAwB,UAAU,EAClCzB,EAAU,IAAMO,CAAS,EACzBkB,GAAwB,MAAM,CAChC,EAQAlB,EAAU,KACRuB,EAAqB,CAACC,EAAGC,IACvBD,EAAE,WAAaC,EAAE,UACjBD,EAAE,OAAaC,EAAE,IAClB,EACDhC,EAAU,IAAMc,CAAQ,EACxBmB,EAAI,IAAM,QAAQ,KAAK,CAAC,CAC1B,CACF,EACG,UAAUtD,GAAO,CA1YtB,IAAAuD,EAAAC,EAgZU,QAAQ,QAAU,MAAQ,CAACxD,EAAI,KACjC,OAAO,SAAS,GAAGwD,GAAAD,EAAA,QAAQ,QAAR,YAAAA,EAAe,IAAf,KAAAC,EAAoB,CAAC,GAExC,QAAQ,kBAAoB,OAC5BC,GAAgBzD,EAAI,IAAI,EACxB,QAAQ,kBAAoB,SAEhC,CAAC,EAMH4B,EAAU,UAAU,IAAM,CACxB,QAAQ,kBAAoB,QAC9B,CAAC,EAMDQ,EAAU,OAAQ,cAAc,EAC7B,UAAU,IAAM,CACf,QAAQ,kBAAoB,MAC9B,CAAC,EAMHP,EAAU,KACRiB,GAAwB,QAAQ,EAChCY,GAAa,GAAG,CAClB,EACG,UAAU,CAAC,CAAE,OAAAf,CAAO,IAAM,CACzB,QAAQ,aAAaA,EAAQ,EAAE,CACjC,CAAC,EAGIE,CACT,CClaA,IAAAc,GAAuB,SAqChB,SAASC,GACdC,EAC0B,CAE1B,IAAMC,EAAQD,EAAO,UAAU,MAAM,GAAG,EAAE,IAAIE,GAC/BA,EAAK,QAAQ,sBAAuB,EAAE,EACvC,SAAW,EAAI,SAAMA,CAClC,EACE,KAAK,GAAG,EAELC,EAAY,IAAI,OAAOF,EAAO,KAAK,EACnCG,EAAY,CAACC,EAAYC,EAAcJ,IACpC,GAAGI,CAAI,2BAA2BJ,CAAI,UAI/C,OAAQK,GAAkB,CACxBA,EAAQA,EACL,QAAQ,gBAAiB,GAAG,EAC5B,KAAK,EAGR,IAAMC,EAAQ,IAAI,OAAO,MAAMR,EAAO,SAAS,MAC7CO,EACG,QAAQ,uBAAwB,MAAM,EACtC,QAAQJ,EAAW,GAAG,CAC3B,IAAK,KAAK,EAGV,OAAOM,MAAS,GAAAC,SAAWD,CAAK,EAC7B,QAAQD,EAAOJ,CAAS,EACxB,QAAQ,8BAA+B,IAAI,CAChD,CACF,CCEO,SAASO,GACdC,EAC+B,CAC/B,OAAOA,EAAQ,OAAS,CAC1B,CASO,SAASC,GACdD,EACgC,CAChC,OAAOA,EAAQ,OAAS,CAC1B,CC1CO,SAASE,GACdC,EAAaC,EACW,CACxB,IAAMC,EAAUC,GAA2BH,CAAG,EAC9C,OAAAI,EACEC,EAAG,SAAS,WAAa,OAAO,EAChCC,GAAY,QAAQ,CACtB,EACG,KACCC,GAAMC,GAAUA,CAAM,EACtBC,EAAU,IAAMR,CAAM,CACxB,EACG,UAAU,CAAC,CAAE,OAAAS,EAAQ,KAAAC,CAAK,IAAMT,EAAQ,KAAK,CAC5C,OACA,KAAM,CACJ,OAAAQ,EACA,KAAAC,EACA,QAAS,CACP,QAASC,EAAQ,gBAAgB,CACnC,CACF,CACF,CAAC,CAAC,EAGCV,CACT,CCjEO,SAASW,GACdC,EACiB,CA/BnB,IAAAC,EAgCE,GAAM,CAAC,uBAAAC,EACL,uBAAAC,EACA,gBAAAC,EACA,eAAAC,CAAc,EAAIL,EACdM,GAAeL,EAAAM,GAAaF,CAAc,IAA3B,YAAAJ,EAA8B,SACnD,GAAIK,IAAiB,OACnB,OAEF,IAAME,EAAsBC,GAAYL,EAAgB,SAAUE,CAAY,EAC9E,GAAIE,IAAwB,OAC1B,OAEF,IAAME,EAAsBC,GAAqBT,EAAuB,KAAK,CAAC,EAC9E,GAAI,CAACA,EAAuB,IAAIQ,CAAmB,EAIjD,OAGF,IAAME,EAAsBL,GAAaC,EAAqBE,CAAmB,EACjF,GAAI,CAACE,GAAuB,CAACV,EAAuB,IAAIU,EAAoB,IAAI,EAC9E,OAGF,IAAMC,EAASN,GAAaC,EAAqBL,CAAsB,EACvE,GAAKU,EAGL,OAAAA,EAAO,KAAOT,EAAgB,KAC9BS,EAAO,OAAST,EAAgB,OACzBS,CACT,CAWA,SAASN,GAAaO,EAAiBC,EAAoC,CACzE,GAAI,CACF,OAAO,IAAI,IAAID,EAAKC,CAAI,CAC1B,OAAQC,EAAA,CACN,MACF,CACF,CAYO,SAASP,GAAYQ,EAAWC,EAAoC,CACzE,GAAID,EAAE,WAAWC,CAAM,EACrB,OAAOD,EAAE,MAAMC,EAAO,MAAM,CAGhC,CASA,SAASC,GAAgBC,EAAYC,EAAoB,CACvD,IAAMC,EAAM,KAAK,IAAIF,EAAG,OAAQC,EAAG,MAAM,EACrCR,EACJ,IAAKA,EAAS,EAAGA,EAASS,GACpBF,EAAGP,CAAM,IAAMQ,EAAGR,CAAM,EADC,EAAEA,EAC/B,CAIF,OAAOA,CACT,CAQO,SAASF,GAAqBY,EAAgC,CACnE,IAAIV,EACJ,QAAWI,KAAKM,EACVV,IAAW,OACbA,EAASI,EAETJ,EAASA,EAAO,MAAM,EAAGM,GAAgBN,EAAQI,CAAC,CAAC,EAGvD,OAAOJ,GAAA,KAAAA,EAAU,EACnB,CC9DO,SAASW,GACd,CAAE,UAAAC,CAAU,EACN,CACN,IAAMC,EAASC,GAAc,EACvBC,EAAYC,GAChB,IAAI,IAAI,mBAAoBH,EAAO,IAAI,CACzC,EACG,KACCI,GAAW,IAAMC,CAAK,CACxB,EAGIC,EAAWJ,EACd,KACCK,EAAIC,GAAY,CACd,GAAM,CAAC,CAAEC,CAAO,EAAIT,EAAO,KAAK,MAAM,aAAa,EACnD,OAAOQ,EAAS,KAAK,CAAC,CAAE,QAAAE,EAAS,QAAAC,CAAQ,IACvCD,IAAYD,GAAWE,EAAQ,SAASF,CAAO,CAChD,GAAKD,EAAS,CAAC,CAClB,CAAC,CACH,EAGFN,EACG,KACCK,EAAIC,GAAY,IAAI,IAAIA,EAAS,IAAIE,GAAW,CAC9C,GAAG,IAAI,IAAI,MAAMA,EAAQ,OAAO,IAAKV,EAAO,IAAI,CAAC,GACjDU,CACF,CAAC,CAAC,CAAC,EACHE,EAAUC,GAAQC,EAAsB,SAAS,KAAM,OAAO,EAC3D,KACCC,EAAOC,GAAM,CAACA,EAAG,SAAW,CAACA,EAAG,OAAO,EACvCC,GAAeX,CAAQ,EACvBM,EAAU,CAAC,CAACI,EAAIP,CAAO,IAAM,CAC3B,GAAIO,EAAG,kBAAkB,QAAS,CAChC,IAAME,EAAKF,EAAG,OAAO,QAAQ,GAAG,EAChC,GAAIE,GAAM,CAACA,EAAG,QAAUL,EAAK,IAAIK,EAAG,IAAI,EAAG,CACzC,IAAMC,EAAMD,EAAG,KAWf,MAAI,CAACF,EAAG,OAAO,QAAQ,aAAa,GAClBH,EAAK,IAAIM,CAAG,IACZV,EACPJ,GAEXW,EAAG,eAAe,EACXI,EAAG,IAAI,IAAID,CAAG,CAAC,EACxB,CACF,CACA,OAAOd,CACT,CAAC,EACDO,EAAUS,GACDC,GAAaD,CAAsB,EAAE,KAC1Cd,EACEgB,GAAQ,CAtIxB,IAAAC,EAuIkB,OAAAA,EAAAC,GAAgC,CAC9B,uBAAwBF,EACxB,uBAAAF,EACA,gBAAiBK,GAAY,EAC7B,eAAgB1B,EAAO,IACzB,CAAC,IALD,KAAAwB,EAKMH,EACV,CACF,CACD,CACH,CACF,CACF,EACG,UAAUF,GAAOQ,GAAYR,EAAK,EAAI,CAAC,EAG5CS,EAAc,CAAC1B,EAAWI,CAAQ,CAAC,EAChC,UAAU,CAAC,CAACE,EAAUC,CAAO,IAAM,CACpBoB,EAAW,mBAAmB,EACtC,YAAYC,GAAsBtB,EAAUC,CAAO,CAAC,CAC5D,CAAC,EAGHV,EAAU,KAAKa,EAAU,IAAMN,CAAQ,CAAC,EACrC,UAAUG,GAAW,CA9J1B,IAAAe,EAiKM,IAAIO,EAAW,SAAS,aAAc,cAAc,EACpD,GAAIA,IAAa,KAAM,CACrBA,EAAW,GAGX,IAAIC,IAAUR,EAAAxB,EAAO,UAAP,YAAAwB,EAAgB,UAAW,SACpC,MAAM,QAAQQ,CAAO,IACxBA,EAAU,CAACA,CAAO,GAGpBC,EAAM,QAAWC,KAAUF,EACzB,QAAWtB,KAAWD,EAAQ,QAAQ,OAAOA,EAAQ,OAAO,EAC1D,GAAI,IAAI,OAAOyB,EAAQ,GAAG,EAAE,KAAKxB,CAAO,EAAG,CACzCqB,EAAW,GACX,MAAME,CACR,CAGJ,SAAS,aAAcF,EAAU,cAAc,CACjD,CAGA,GAAIA,EACF,QAAWI,KAAWC,GAAqB,UAAU,EACnDD,EAAQ,OAAS,EACvB,CAAC,CACL,CCvFO,SAASE,GACdC,EAAsB,CAAE,QAAAC,CAAQ,EACP,CAGzB,GAAM,CAAE,aAAAC,CAAa,EAAIC,GAAY,EACjCD,EAAa,IAAI,GAAG,IACtBE,GAAU,SAAU,EAAI,EAGxBJ,EAAG,MAAQE,EAAa,IAAI,GAAG,EAC/BF,EAAG,MAAM,EAGTK,GAAY,QAAQ,EACjB,KACCC,GAAMC,GAAU,CAACA,CAAM,CACzB,EACG,UAAU,IAAM,CACf,IAAMC,EAAML,GAAY,EACxBK,EAAI,aAAa,OAAO,GAAG,EAC3B,QAAQ,aAAa,CAAC,EAAG,GAAI,GAAGA,CAAG,EAAE,CACvC,CAAC,GAIP,IAAMC,EAASC,GAAkBV,CAAE,EAC7BW,EAASC,EACbX,EAAQ,KAAKK,GAAMO,EAAoB,CAAC,EACxCC,EAAUd,EAAI,OAAO,EACrBS,CACF,EACG,KACCM,EAAI,IAAMf,EAAG,KAAK,EAClBgB,EAAqB,CACvB,EAGF,OAAOC,EAAc,CAACN,EAAQF,CAAM,CAAC,EAClC,KACCM,EAAI,CAAC,CAACG,EAAOC,CAAK,KAAO,CAAE,MAAAD,EAAO,MAAAC,CAAM,EAAE,EAC1CC,EAAY,CAAC,CACf,CACJ,CAUO,SAASC,GACdrB,EAAsB,CAAE,QAAAC,CAAQ,EACsB,CACtD,IAAMqB,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGC,GAAQ,EAAI,CAAC,EAGxDT,EAAc,CACZhB,EAAQ,KAAKK,GAAMO,EAAoB,CAAC,EACxCS,CACF,EAAG,CAACK,EAAGC,IAAUA,CAAK,EACnB,KACCC,GAAwB,OAAO,CACjC,EACG,UAAU,CAAC,CAAE,MAAAX,CAAM,IAAMjB,EAAQ,KAAK,CACrC,OACA,KAAMiB,CACR,CAAC,CAAC,EAGNI,EACG,KACCO,GAAwB,OAAO,CACjC,EACG,UAAU,CAAC,CAAE,MAAAV,CAAM,IAAM,CACpBA,GACFf,GAAU,SAAUe,CAAK,CAC7B,CAAC,EAGLL,EAAUd,EAAG,KAAO,OAAO,EACxB,KACC8B,EAAUN,CAAK,CACjB,EACG,UAAU,IAAMxB,EAAG,MAAM,CAAC,EAM/B,IAAM+B,EAAQC,EAAW,uBAAuB,EAChD,OAAAlB,EAAUiB,EAAO,OAAO,EACrB,UAAU,IAAM/B,EAAG,MAAM,CAAC,EAGtBD,GAAiBC,EAAI,CAAE,QAAAC,CAAQ,CAAC,EACpC,KACCgC,EAAIC,GAASZ,EAAM,KAAKY,CAAK,CAAC,EAC9BC,EAAS,IAAMb,EAAM,SAAS,CAAC,EAC/BP,EAAImB,GAAUE,EAAA,CAAE,IAAKpC,GAAOkC,EAAQ,EACpCd,EAAY,CAAC,CACf,CACJ,CCnHO,SAASiB,GACdC,EAAiB,CAAE,QAAAC,EAAS,OAAAC,CAAO,EACE,CACrC,IAAMC,EAAQ,IAAIC,EACZC,EAAYC,GAAqBN,EAAG,aAAc,EACrD,KACCO,EAAO,OAAO,CAChB,EAGIC,EAAYR,EAAG,cAGfS,EAAOC,EAAW,wBAAyBV,CAAE,EAC7CW,EAAOD,EAAW,uBAAwBV,CAAE,EAGlDY,GAAY,QAAQ,EACjB,UAAUC,GAAUF,EAAK,aACxB,OAAQE,EAAS,OAAS,cAC5B,CAAC,EAGHV,EACG,KACCW,GAAeZ,CAAM,EACrBa,GAAUd,EAAQ,KAAKe,GAAMC,EAAoB,CAAC,CAAC,CACrD,EACG,UAAU,CAAC,CAAC,CAAE,MAAAC,CAAM,EAAG,CAAE,MAAAC,CAAM,CAAC,IAAM,CACrC,OAAQD,EAAM,OAAQ,CAGpB,IAAK,GACHT,EAAK,YAAcU,EAAM,OACrBC,GAAY,oBAAoB,EAChCA,GAAY,2BAA2B,EAC3C,MAGF,IAAK,GACHX,EAAK,YAAcW,GAAY,mBAAmB,EAClD,MAGF,QACE,IAAMC,EAAQC,GAAMJ,EAAM,MAAM,EAChCT,EAAK,YAAcW,GAAY,sBAAuBC,CAAK,CAC/D,CACF,CAAC,EAGL,IAAME,EAAUpB,EACb,KACCqB,EAAI,IAAMb,EAAK,UAAY,EAAE,EAC7Bc,EAAU,CAAC,CAAE,MAAAP,CAAM,IAAMQ,EACvBC,EAAG,GAAGT,EAAM,MAAM,EAAG,EAAE,CAAC,EACxBS,EAAG,GAAGT,EAAM,MAAM,EAAE,CAAC,EAClB,KACCU,GAAY,CAAC,EACbC,GAAQxB,CAAS,EACjBoB,EAAU,CAAC,CAACK,CAAK,IAAMA,CAAK,CAC9B,CACJ,CAAC,EACDC,EAAIC,EAAsB,EAC1BC,GAAM,CACR,EAGF,OAAAV,EAAQ,UAAUW,GAAQvB,EAAK,YAAYuB,CAAI,CAAC,EAChDX,EACG,KACCY,GAASD,GAAQ,CACf,IAAME,EAAUC,GAAmB,UAAWH,CAAI,EAClD,OAAI,OAAOE,GAAY,YACdE,EAGFC,EAAUH,EAAS,QAAQ,EAC/B,KACCI,EAAUrC,CAAK,EACf4B,EAAI,IAAMK,CAAO,CACnB,CACJ,CAAC,CACH,EACG,UAAUA,GAAW,CAElBA,EAAQ,OAAS,IACjBA,EAAQ,WAAa5B,EAAU,WAE/BA,EAAU,SAAS,CAAE,IAAK4B,EAAQ,SAAU,CAAC,CACjD,CAAC,EAGWnC,EACb,KACCM,EAAOkC,EAAqB,EAC5BV,EAAI,CAAC,CAAE,KAAAW,CAAK,IAAMA,CAAI,CACxB,EAIC,KACClB,EAAImB,GAASxC,EAAM,KAAKwC,CAAK,CAAC,EAC9BC,EAAS,IAAMzC,EAAM,SAAS,CAAC,EAC/B4B,EAAIY,GAAUE,EAAA,CAAE,IAAK7C,GAAO2C,EAAQ,CACtC,CACJ,CCpHO,SAASG,GACdC,EAAkB,CAAE,OAAAC,CAAO,EACF,CACzB,OAAOA,EACJ,KACCC,EAAI,CAAC,CAAE,MAAAC,CAAM,IAAM,CACjB,IAAMC,EAAMC,GAAY,EACxB,OAAAD,EAAI,KAAO,GAGXD,EAAQA,EACL,QAAQ,OAAQ,GAAG,EACnB,QAAQ,KAAM,KAAK,EACnB,QAAQ,KAAM,KAAK,EAGtBC,EAAI,OAAS,KAAKD,CAAK,GAChB,CAAE,IAAAC,CAAI,CACf,CAAC,CACH,CACJ,CAUO,SAASE,GACdC,EAAuBC,EACa,CACpC,IAAMC,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGC,GAAQ,EAAI,CAAC,EACxD,OAAAJ,EAAM,UAAU,CAAC,CAAE,IAAAL,CAAI,IAAM,CAC3BG,EAAG,aAAa,sBAAuBA,EAAG,IAAI,EAC9CA,EAAG,KAAO,GAAGH,CAAG,EAClB,CAAC,EAGDU,EAAUP,EAAI,OAAO,EAClB,KACCQ,EAAUJ,CAAK,CACjB,EACG,UAAUK,GAAMA,EAAG,eAAe,CAAC,EAGjCjB,GAAiBQ,EAAIC,CAAO,EAChC,KACCS,EAAIC,GAAST,EAAM,KAAKS,CAAK,CAAC,EAC9BC,EAAS,IAAMV,EAAM,SAAS,CAAC,EAC/BP,EAAIgB,GAAUE,EAAA,CAAE,IAAKb,GAAOW,EAAQ,CACtC,CACJ,CCpDO,SAASG,GACdC,EAAiB,CAAE,QAAAC,EAAS,UAAAC,CAAU,EACA,CACtC,IAAMC,EAAQ,IAAIC,EAGZC,EAASC,GAAoB,cAAc,EAC3CC,EAASC,EACbC,EAAUJ,EAAO,SAAS,EAC1BI,EAAUJ,EAAO,OAAO,CAC1B,EACG,KACCK,GAAUC,EAAc,EACxBC,EAAI,IAAMP,EAAM,KAAK,EACrBQ,EAAqB,CACvB,EAGF,OAAAV,EACG,KACCW,GAAkBP,CAAM,EACxBK,EAAI,CAAC,CAAC,CAAE,QAAAG,CAAQ,EAAGC,CAAK,IAAM,CAC5B,IAAMC,EAAQD,EAAM,MAAM,UAAU,EACpC,GAAID,GAAA,MAAAA,EAAS,QAAUE,EAAMA,EAAM,OAAS,CAAC,EAAG,CAC9C,IAAMC,EAAOH,EAAQA,EAAQ,OAAS,CAAC,EACnCG,EAAK,WAAWD,EAAMA,EAAM,OAAS,CAAC,CAAC,IACzCA,EAAMA,EAAM,OAAS,CAAC,EAAIC,EAC9B,MACED,EAAM,OAAS,EAEjB,OAAOA,CACT,CAAC,CACH,EACG,UAAUA,GAASjB,EAAG,UAAYiB,EAChC,KAAK,EAAE,EACP,QAAQ,MAAO,QAAQ,CAC1B,EAGJf,EACG,KACCiB,EAAO,CAAC,CAAE,KAAAC,CAAK,IAAMA,IAAS,QAAQ,CACxC,EACG,UAAUC,GAAO,CAChB,OAAQA,EAAI,KAAM,CAGhB,IAAK,aAEDrB,EAAG,UAAU,QACbK,EAAM,iBAAmBA,EAAM,MAAM,SAErCA,EAAM,MAAQL,EAAG,WACnB,KACJ,CACF,CAAC,EAGWC,EACb,KACCkB,EAAOG,EAAqB,EAC5BV,EAAI,CAAC,CAAE,KAAAW,CAAK,IAAMA,CAAI,CACxB,EAIC,KACCC,EAAIC,GAAStB,EAAM,KAAKsB,CAAK,CAAC,EAC9BC,EAAS,IAAMvB,EAAM,SAAS,CAAC,EAC/BS,EAAI,KAAO,CAAE,IAAKZ,CAAG,EAAE,CACzB,CACJ,CCjDO,SAAS2B,GACdC,EAAiB,CAAE,OAAAC,EAAQ,UAAAC,CAAU,EACN,CAC/B,IAAMC,EAASC,GAAc,EAC7B,GAAI,CACF,IAAMC,EAAUC,GAAkBH,EAAO,OAAQF,CAAM,EAGjDM,EAASC,GAAoB,eAAgBR,CAAE,EAC/CS,EAASD,GAAoB,gBAAiBR,CAAE,EAGtDU,EAAwBV,EAAI,OAAO,EAChC,KACCW,EAAO,CAAC,CAAE,OAAAC,CAAO,IACfA,aAAkB,SAAW,CAAC,CAACA,EAAO,QAAQ,GAAG,CAClD,CACH,EACG,UAAU,IAAMC,GAAU,SAAU,EAAK,CAAC,EAG/CX,EACG,KACCS,EAAO,CAAC,CAAE,KAAAG,CAAK,IAAMA,IAAS,QAAQ,CACxC,EACG,UAAUC,GAAO,CAChB,IAAMC,EAASC,GAAiB,EAChC,OAAQF,EAAI,KAAM,CAGhB,IAAK,QACH,GAAIC,IAAWT,EAAO,CACpB,IAAMW,EAAU,IAAI,IACpB,QAAWC,KAAUC,EACnB,sBAAuBX,CACzB,EAAG,CACD,IAAMY,EAAUF,EAAO,kBACvBD,EAAQ,IAAIC,EAAQ,WAClBE,EAAQ,aAAa,eAAe,CACtC,CAAC,CACH,CAGA,GAAIH,EAAQ,KAAM,CAChB,GAAM,CAAC,CAACI,CAAI,CAAC,EAAI,CAAC,GAAGJ,CAAO,EAAE,KAAK,CAAC,CAAC,CAAEK,CAAC,EAAG,CAAC,CAAEC,CAAC,IAAMA,EAAID,CAAC,EAC1DD,EAAK,MAAM,CACb,CAGAP,EAAI,MAAM,CACZ,CACA,MAGF,IAAK,SACL,IAAK,MACHF,GAAU,SAAU,EAAK,EACzBN,EAAM,KAAK,EACX,MAGF,IAAK,UACL,IAAK,YACH,GAAI,OAAOS,GAAW,YACpBT,EAAM,MAAM,MACP,CACL,IAAMkB,EAAM,CAAClB,EAAO,GAAGa,EACrB,wDACAX,CACF,CAAC,EACKiB,EAAI,KAAK,IAAI,GACjB,KAAK,IAAI,EAAGD,EAAI,QAAQT,CAAM,CAAC,EAAIS,EAAI,QACrCV,EAAI,OAAS,UAAY,GAAK,IAE9BU,EAAI,MAAM,EACdA,EAAIC,CAAC,EAAE,MAAM,CACf,CAGAX,EAAI,MAAM,EACV,MAGF,QACMR,IAAUU,GAAiB,GAC7BV,EAAM,MAAM,CAClB,CACF,CAAC,EAGLL,EACG,KACCS,EAAO,CAAC,CAAE,KAAAG,CAAK,IAAMA,IAAS,QAAQ,CACxC,EACG,UAAUC,GAAO,CAChB,OAAQA,EAAI,KAAM,CAGhB,IAAK,IACL,IAAK,IACL,IAAK,IACHR,EAAM,MAAM,EACZA,EAAM,OAAO,EAGbQ,EAAI,MAAM,EACV,KACJ,CACF,CAAC,EAGL,IAAMY,EAASC,GAAiBrB,EAAO,CAAE,QAAAF,CAAQ,CAAC,EAClD,OAAOwB,EACLF,EACAG,GAAkBrB,EAAQ,CAAE,QAAAJ,EAAS,OAAAsB,CAAO,CAAC,CAC/C,EACG,KACCI,GAGE,GAAGC,GAAqB,eAAgBhC,CAAE,EACvC,IAAIiC,GAASC,GAAiBD,EAAO,CAAE,OAAAN,CAAO,CAAC,CAAC,EAGnD,GAAGK,GAAqB,iBAAkBhC,CAAE,EACzC,IAAIiC,GAASE,GAAmBF,EAAO,CAAE,QAAA5B,EAAS,UAAAH,CAAU,CAAC,CAAC,CACnE,CACF,CAGJ,OAASkC,EAAK,CACZ,OAAApC,EAAG,OAAS,GACLqC,EACT,CACF,CCnKO,SAASC,GACdC,EAAiB,CAAE,OAAAC,EAAQ,UAAAC,CAAU,EACG,CACxC,OAAOC,EAAc,CACnBF,EACAC,EACG,KACCE,EAAUC,GAAY,CAAC,EACvBC,EAAOC,GAAO,CAAC,CAACA,EAAI,aAAa,IAAI,GAAG,CAAC,CAC3C,CACJ,CAAC,EACE,KACCC,EAAI,CAAC,CAACC,EAAOF,CAAG,IAAMG,GAAuBD,EAAM,MAAM,EACvDF,EAAI,aAAa,IAAI,GAAG,CAC1B,CAAC,EACDC,EAAIG,GAAM,CA1FhB,IAAAC,EA2FQ,IAAMC,EAAQ,IAAI,IAGZC,EAAK,SAAS,mBAAmBd,EAAI,WAAW,SAAS,EAC/D,QAASe,EAAOD,EAAG,SAAS,EAAGC,EAAMA,EAAOD,EAAG,SAAS,EACtD,IAAIF,EAAAG,EAAK,gBAAL,MAAAH,EAAoB,aAAc,CACpC,IAAMI,EAAWD,EAAK,YAChBE,EAAWN,EAAGK,CAAQ,EACxBC,EAAS,OAASD,EAAS,QAC7BH,EAAM,IAAIE,EAAmBE,CAAQ,CACzC,CAIF,OAAW,CAACF,EAAMG,CAAI,IAAKL,EAAO,CAChC,GAAM,CAAE,WAAAM,CAAW,EAAIC,EAAE,OAAQ,KAAMF,CAAI,EAC3CH,EAAK,YAAY,GAAG,MAAM,KAAKI,CAAU,CAAC,CAC5C,CAGA,MAAO,CAAE,IAAKnB,EAAI,MAAAa,CAAM,CAC1B,CAAC,CACH,CACJ,CCPO,SAASQ,GACdC,EAAiB,CAAE,UAAAC,EAAW,MAAAC,CAAM,EACf,CACrB,IAAMC,EAASH,EAAG,QAAqB,UAAU,EAC3CI,EACJD,EAAO,UACPA,EAAO,cAAe,UAGxB,OAAOE,EAAc,CAACH,EAAOD,CAAS,CAAC,EACpC,KACCK,EAAI,CAAC,CAAC,CAAE,OAAAC,EAAQ,OAAAC,CAAO,EAAG,CAAE,OAAQ,CAAE,EAAAC,CAAE,CAAE,CAAC,KACzCD,EAASA,EACL,KAAK,IAAIJ,EAAQ,KAAK,IAAI,EAAGK,EAAIF,CAAM,CAAC,EACxCH,EACG,CACL,OAAAI,EACA,OAAQC,GAAKF,EAASH,CACxB,EACD,EACDM,EAAqB,CAACC,EAAGC,IACvBD,EAAE,SAAWC,EAAE,QACfD,EAAE,SAAWC,EAAE,MAChB,CACH,CACJ,CAuBO,SAASC,GACdb,EAAiBc,EACe,CADf,IAAAC,EAAAD,EAAE,SAAAE,CA5JrB,EA4JmBD,EAAcE,EAAAC,GAAdH,EAAc,CAAZ,YAEnB,IAAMI,EAAQC,EAAW,0BAA2BpB,CAAE,EAChD,CAAE,EAAAS,CAAE,EAAIY,GAAiBF,CAAK,EACpC,OAAOG,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGC,GAAQ,EAAI,CAAC,EAClDC,EAAQL,EACX,KACCM,GAAU,EAAGC,EAAuB,CACtC,EAGF,OAAAF,EAAM,KAAKG,GAAef,CAAO,CAAC,EAC/B,UAAU,CAGT,KAAK,CAAC,CAAE,OAAAR,CAAO,EAAG,CAAE,OAAQD,CAAO,CAAC,EAAG,CACrCY,EAAM,MAAM,OAAS,GAAGX,EAAS,EAAIC,CAAC,KACtCT,EAAG,MAAM,IAAY,GAAGO,CAAM,IAChC,EAGA,UAAW,CACTY,EAAM,MAAM,OAAS,GACrBnB,EAAG,MAAM,IAAY,EACvB,CACF,CAAC,EAGH4B,EAAM,KAAKI,GAAM,CAAC,EACf,UAAU,IAAM,CACf,QAAWC,KAAQC,EAAY,8BAA+BlC,CAAE,EAAG,CACjE,GAAI,CAACiC,EAAK,aACR,SACF,IAAME,EAAYF,EAAK,QAAqB,yBAAyB,EACrE,GAAI,OAAOE,GAAc,YAAa,CACpC,IAAM5B,EAAS0B,EAAK,UAAYE,EAAU,UACpC,CAAE,OAAA3B,CAAO,EAAI4B,GAAeD,CAAS,EAC3CA,EAAU,SAAS,CACjB,IAAK5B,EAASC,EAAS,CACzB,CAAC,CACH,CACF,CACF,CAAC,EAGH6B,GAAKH,EAA8B,kBAAmBlC,CAAE,CAAC,EACtD,KACCsC,GAASC,GAASC,EAAUD,EAAO,OAAO,EACvC,KACCE,GAAUC,EAAc,EACxBpC,EAAI,IAAMiC,CAAK,EACfI,EAAUlB,CAAK,CACjB,CACF,CACF,EACG,UAAUc,GAAS,CAClB,IAAMK,EAAQxB,EAA6B,QAAQmB,EAAM,OAAO,IAAI,EACxDnB,EAAW,qBAAqBmB,EAAM,EAAE,IAAI,EACpD,aAAa,gBAAiB,GAAGK,EAAM,OAAO,EAAE,CACtD,CAAC,EAGE7C,GAAaC,EAAIiB,CAAO,EAC5B,KACC4B,EAAIC,GAASvB,EAAM,KAAKuB,CAAK,CAAC,EAC9BC,EAAS,IAAMxB,EAAM,SAAS,CAAC,EAC/BjB,EAAIwC,GAAUE,EAAA,CAAE,IAAKhD,GAAO8C,EAAQ,CACtC,CACJ,CAAC,CACH,CCxKO,SAASG,GACdC,EAAcC,EACW,CACzB,GAAI,OAAOA,GAAS,YAAa,CAC/B,IAAMC,EAAM,gCAAgCF,CAAI,IAAIC,CAAI,GACxD,OAAOE,GAGLC,GAAqB,GAAGF,CAAG,kBAAkB,EAC1C,KACCG,GAAW,IAAMC,CAAK,EACtBC,EAAIC,IAAY,CACd,QAASA,EAAQ,QACnB,EAAE,EACFC,GAAe,CAAC,CAAC,CACnB,EAGFL,GAAkBF,CAAG,EAClB,KACCG,GAAW,IAAMC,CAAK,EACtBC,EAAIG,IAAS,CACX,MAAOA,EAAK,iBACZ,MAAOA,EAAK,WACd,EAAE,EACFD,GAAe,CAAC,CAAC,CACnB,CACJ,EACG,KACCF,EAAI,CAAC,CAACC,EAASE,CAAI,IAAOC,IAAA,GAAKH,GAAYE,EAAO,CACpD,CAGJ,KAAO,CACL,IAAMR,EAAM,gCAAgCF,CAAI,GAChD,OAAOI,GAAkBF,CAAG,EACzB,KACCK,EAAIG,IAAS,CACX,aAAcA,EAAK,YACrB,EAAE,EACFD,GAAe,CAAC,CAAC,CACnB,CACJ,CACF,CC3CO,SAASG,GACdC,EAAcC,EACW,CACzB,IAAMC,EAAM,WAAWF,CAAI,oBAAoB,mBAAmBC,CAAO,CAAC,GAC1E,OAAOE,GAGLC,GAAqB,GAAGF,CAAG,4BAA4B,EACpD,KACCG,GAAW,IAAMC,CAAK,EACtBC,EAAI,CAAC,CAAE,SAAAC,CAAS,KAAO,CACrB,QAASA,CACX,EAAE,EACFC,GAAe,CAAC,CAAC,CACnB,EAGFL,GAA2BF,CAAG,EAC3B,KACCG,GAAW,IAAMC,CAAK,EACtBC,EAAI,CAAC,CAAE,WAAAG,EAAY,YAAAC,CAAY,KAAO,CACpC,MAAOD,EACP,MAAOC,CACT,EAAE,EACFF,GAAe,CAAC,CAAC,CACnB,CACJ,EACG,KACCF,EAAI,CAAC,CAACK,EAASC,CAAI,IAAOC,IAAA,GAAKF,GAAYC,EAAO,CACpD,CACJ,CCtBO,SAASE,GACdC,EACyB,CAGzB,IAAIC,EAAQD,EAAI,MAAM,qCAAqC,EAC3D,GAAIC,EAAO,CACT,GAAM,CAAC,CAAEC,EAAMC,CAAI,EAAIF,EACvB,OAAOG,GAA2BF,EAAMC,CAAI,CAC9C,CAIA,GADAF,EAAQD,EAAI,MAAM,oCAAoC,EAClDC,EAAO,CACT,GAAM,CAAC,CAAEI,EAAMC,CAAI,EAAIL,EACvB,OAAOM,GAA2BF,EAAMC,CAAI,CAC9C,CAGA,OAAOE,CACT,CCpBA,IAAIC,GAgBG,SAASC,GACdC,EACoB,CACpB,OAAOF,QAAWG,EAAM,IAAM,CAC5B,IAAMC,EAAS,SAAsB,WAAY,cAAc,EAC/D,GAAIA,EACF,OAAOC,EAAGD,CAAM,EAKhB,GADYE,GAAqB,SAAS,EAClC,OAAQ,CACd,IAAMC,EAAU,SAA0B,WAAW,EACrD,GAAI,EAAEA,GAAWA,EAAQ,QACvB,OAAOC,CACX,CAGA,OAAOC,GAAiBP,EAAG,IAAI,EAC5B,KACCQ,EAAIC,GAAS,SAAS,WAAYA,EAAO,cAAc,CAAC,CAC1D,CAEN,CAAC,EACE,KACCC,GAAW,IAAMJ,CAAK,EACtBK,EAAOF,GAAS,OAAO,KAAKA,CAAK,EAAE,OAAS,CAAC,EAC7CG,EAAIH,IAAU,CAAE,MAAAA,CAAM,EAAE,EACxBI,EAAY,CAAC,CACf,EACJ,CASO,SAASC,GACdd,EAC+B,CAC/B,IAAMe,EAAQC,EAAW,uBAAwBhB,CAAE,EACnD,OAAOC,EAAM,IAAM,CACjB,IAAMgB,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAU,CAAC,CAAE,MAAAR,CAAM,IAAM,CAC7BM,EAAM,YAAYI,GAAkBV,CAAK,CAAC,EAC1CM,EAAM,UAAU,IAAI,+BAA+B,CACrD,CAAC,EAGMhB,GAAYC,CAAE,EAClB,KACCQ,EAAIY,GAASH,EAAM,KAAKG,CAAK,CAAC,EAC9BC,EAAS,IAAMJ,EAAM,SAAS,CAAC,EAC/BL,EAAIQ,GAAUE,EAAA,CAAE,IAAKtB,GAAOoB,EAAQ,CACtC,CACJ,CAAC,CACH,CCtDO,SAASG,GACdC,EAAiB,CAAE,UAAAC,EAAW,QAAAC,CAAQ,EACpB,CAClB,OAAOC,GAAiB,SAAS,IAAI,EAClC,KACCC,EAAU,IAAMC,GAAgBL,EAAI,CAAE,QAAAE,EAAS,UAAAD,CAAU,CAAC,CAAC,EAC3DK,EAAI,CAAC,CAAE,OAAQ,CAAE,EAAAC,CAAE,CAAE,KACZ,CACL,OAAQA,GAAK,EACf,EACD,EACDC,GAAwB,QAAQ,CAClC,CACJ,CAaO,SAASC,GACdT,EAAiBU,EACY,CAC7B,OAAOC,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAU,CAGd,KAAK,CAAE,OAAAE,CAAO,EAAG,CACfd,EAAG,OAASc,CACd,EAGA,UAAW,CACTd,EAAG,OAAS,EACd,CACF,CAAC,GAICe,EAAQ,wBAAwB,EAC5BC,EAAG,CAAE,OAAQ,EAAM,CAAC,EACpBjB,GAAUC,EAAIU,CAAO,GAExB,KACCO,EAAIC,GAASN,EAAM,KAAKM,CAAK,CAAC,EAC9BC,EAAS,IAAMP,EAAM,SAAS,CAAC,EAC/BN,EAAIY,GAAUE,EAAA,CAAE,IAAKpB,GAAOkB,EAAQ,CACtC,CACJ,CAAC,CACH,CCfO,SAASG,GACdC,EAAiB,CAAE,UAAAC,EAAW,QAAAC,CAAQ,EACT,CAC7B,IAAMC,EAAQ,IAAI,IAGZC,EAAUC,EAA+B,gBAAiBL,CAAE,EAClE,QAAWM,KAAUF,EAAS,CAC5B,IAAMG,EAAK,mBAAmBD,EAAO,KAAK,UAAU,CAAC,CAAC,EAChDE,EAASC,GAAmB,QAAQF,CAAE,IAAI,EAC5C,OAAOC,GAAW,aACpBL,EAAM,IAAIG,EAAQE,CAAM,CAC5B,CAGA,IAAME,EAAUR,EACb,KACCS,GAAwB,QAAQ,EAChCC,EAAI,CAAC,CAAE,OAAAC,CAAO,IAAM,CAClB,IAAMC,EAAOC,GAAoB,MAAM,EACjCC,EAAOC,EAAW,wBAAyBH,CAAI,EACrD,OAAOD,EAAS,IACdG,EAAK,UACLF,EAAK,UAET,CAAC,EACDI,GAAM,CACR,EAqFF,OAlFmBC,GAAiB,SAAS,IAAI,EAC9C,KACCR,GAAwB,QAAQ,EAGhCS,EAAUC,GAAQC,EAAM,IAAM,CAC5B,IAAIC,EAA4B,CAAC,EACjC,OAAOC,EAAG,CAAC,GAAGrB,CAAK,EAAE,OAAO,CAACsB,EAAO,CAACnB,EAAQE,CAAM,IAAM,CACvD,KAAOe,EAAK,QACGpB,EAAM,IAAIoB,EAAKA,EAAK,OAAS,CAAC,CAAC,EACnC,SAAWf,EAAO,SACzBe,EAAK,IAAI,EAOb,IAAIG,EAASlB,EAAO,UACpB,KAAO,CAACkB,GAAUlB,EAAO,eACvBA,EAASA,EAAO,cAChBkB,EAASlB,EAAO,UAIlB,IAAImB,EAASnB,EAAO,aACpB,KAAOmB,EAAQA,EAASA,EAAO,aAC7BD,GAAUC,EAAO,UAGnB,OAAOF,EAAM,IACX,CAAC,GAAGF,EAAO,CAAC,GAAGA,EAAMjB,CAAM,CAAC,EAAE,QAAQ,EACtCoB,CACF,CACF,EAAG,IAAI,GAAkC,CAAC,CAC5C,CAAC,EACE,KAGCd,EAAIa,GAAS,IAAI,IAAI,CAAC,GAAGA,CAAK,EAAE,KAAK,CAAC,CAAC,CAAEG,CAAC,EAAG,CAAC,CAAEC,CAAC,IAAMD,EAAIC,CAAC,CAAC,CAAC,EAC9DC,GAAkBpB,CAAO,EAGzBU,EAAU,CAAC,CAACK,EAAOM,CAAM,IAAM9B,EAC5B,KACC+B,GAAK,CAAC,CAACC,EAAMC,CAAI,EAAG,CAAE,OAAQ,CAAE,EAAAC,CAAE,EAAG,KAAAC,CAAK,IAAM,CAC9C,IAAMC,EAAOF,EAAIC,EAAK,QAAU,KAAK,MAAMf,EAAK,MAAM,EAGtD,KAAOa,EAAK,QAAQ,CAClB,GAAM,CAAC,CAAER,CAAM,EAAIQ,EAAK,CAAC,EACzB,GAAIR,EAASK,EAASI,GAAKE,EACzBJ,EAAO,CAAC,GAAGA,EAAMC,EAAK,MAAM,CAAE,MAE9B,MAEJ,CAGA,KAAOD,EAAK,QAAQ,CAClB,GAAM,CAAC,CAAEP,CAAM,EAAIO,EAAKA,EAAK,OAAS,CAAC,EACvC,GAAIP,EAASK,GAAUI,GAAK,CAACE,EAC3BH,EAAO,CAACD,EAAK,IAAI,EAAI,GAAGC,CAAI,MAE5B,MAEJ,CAGA,MAAO,CAACD,EAAMC,CAAI,CACpB,EAAG,CAAC,CAAC,EAAG,CAAC,GAAGT,CAAK,CAAC,CAAC,EACnBa,EAAqB,CAACV,EAAGC,IACvBD,EAAE,CAAC,IAAMC,EAAE,CAAC,GACZD,EAAE,CAAC,IAAMC,EAAE,CAAC,CACb,CACH,CACF,CACF,CACF,CACF,EAIC,KACCjB,EAAI,CAAC,CAACqB,EAAMC,CAAI,KAAO,CACrB,KAAMD,EAAK,IAAI,CAAC,CAACV,CAAI,IAAMA,CAAI,EAC/B,KAAMW,EAAK,IAAI,CAAC,CAACX,CAAI,IAAMA,CAAI,CACjC,EAAE,EAGFgB,EAAU,CAAE,KAAM,CAAC,EAAG,KAAM,CAAC,CAAE,CAAC,EAChCC,GAAY,EAAG,CAAC,EAChB5B,EAAI,CAAC,CAACgB,EAAGC,CAAC,IAGJD,EAAE,KAAK,OAASC,EAAE,KAAK,OAClB,CACL,KAAMA,EAAE,KAAK,MAAM,KAAK,IAAI,EAAGD,EAAE,KAAK,OAAS,CAAC,EAAGC,EAAE,KAAK,MAAM,EAChE,KAAM,CAAC,CACT,EAIO,CACL,KAAMA,EAAE,KAAK,MAAM,EAAE,EACrB,KAAMA,EAAE,KAAK,MAAM,EAAGA,EAAE,KAAK,OAASD,EAAE,KAAK,MAAM,CACrD,CAEH,CACH,CACJ,CAYO,SAASa,GACdzC,EAAiB,CAAE,UAAAC,EAAW,QAAAC,EAAS,MAAAwC,EAAO,QAAAC,CAAQ,EACd,CACxC,OAAOrB,EAAM,IAAM,CACjB,IAAMsB,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGC,GAAQ,EAAI,CAAC,EAoBxD,GAnBAJ,EAAM,UAAU,CAAC,CAAE,KAAAX,EAAM,KAAAC,CAAK,IAAM,CAGlC,OAAW,CAAC5B,CAAM,IAAK4B,EACrB5B,EAAO,UAAU,OAAO,sBAAsB,EAC9CA,EAAO,UAAU,OAAO,sBAAsB,EAIhD,OAAW,CAACmB,EAAO,CAACnB,CAAM,CAAC,IAAK2B,EAAK,QAAQ,EAC3C3B,EAAO,UAAU,IAAI,sBAAsB,EAC3CA,EAAO,UAAU,OACf,uBACAmB,IAAUQ,EAAK,OAAS,CAC1B,CAEJ,CAAC,EAGGgB,EAAQ,YAAY,EAAG,CAGzB,IAAMC,EAAUC,EACdlD,EAAU,KAAKmD,GAAa,CAAC,EAAGxC,EAAI,IAAG,EAAY,CAAC,EACpDX,EAAU,KAAKmD,GAAa,GAAG,EAAGxC,EAAI,IAAM,QAAiB,CAAC,CAChE,EAGAgC,EACG,KACCS,EAAO,CAAC,CAAE,KAAApB,CAAK,IAAMA,EAAK,OAAS,CAAC,EACpCH,GAAkBY,EAAM,KAAKY,GAAUC,EAAc,CAAC,CAAC,EACvDC,GAAeN,CAAO,CACxB,EACG,UAAU,CAAC,CAAC,CAAC,CAAE,KAAAjB,CAAK,CAAC,EAAGwB,CAAQ,IAAM,CACrC,GAAM,CAACnD,CAAM,EAAI2B,EAAKA,EAAK,OAAS,CAAC,EACrC,GAAI3B,EAAO,aAAc,CAGvB,IAAMoD,EAAYC,GAAoBrD,CAAM,EAC5C,GAAI,OAAOoD,GAAc,YAAa,CACpC,IAAMhC,EAASpB,EAAO,UAAYoD,EAAU,UACtC,CAAE,OAAA7C,CAAO,EAAI+C,GAAeF,CAAS,EAC3CA,EAAU,SAAS,CACjB,IAAKhC,EAASb,EAAS,EACvB,SAAA4C,CACF,CAAC,CACH,CACF,CACF,CAAC,CACP,CAGA,OAAIR,EAAQ,qBAAqB,GAC/BhD,EACG,KACC4D,EAAUf,CAAK,EACfnC,GAAwB,QAAQ,EAChCyC,GAAa,GAAG,EAChBU,GAAK,CAAC,EACND,EAAUlB,EAAQ,KAAKmB,GAAK,CAAC,CAAC,CAAC,EAC/BC,GAAO,CAAE,MAAO,GAAI,CAAC,EACrBP,GAAeZ,CAAK,CACtB,EACG,UAAU,CAAC,CAAC,CAAE,CAAE,KAAAX,CAAK,CAAC,IAAM,CAC3B,IAAM+B,EAAMC,GAAY,EAGlB3D,EAAS2B,EAAKA,EAAK,OAAS,CAAC,EACnC,GAAI3B,GAAUA,EAAO,OAAQ,CAC3B,GAAM,CAAC4D,CAAM,EAAI5D,EACX,CAAE,KAAA6D,CAAK,EAAI,IAAI,IAAID,EAAO,IAAI,EAChCF,EAAI,OAASG,IACfH,EAAI,KAAOG,EACX,QAAQ,aAAa,CAAC,EAAG,GAAI,GAAGH,CAAG,EAAE,EAIzC,MACEA,EAAI,KAAO,GACX,QAAQ,aAAa,CAAC,EAAG,GAAI,GAAGA,CAAG,EAAE,CAEzC,CAAC,EAGAjE,GAAqBC,EAAI,CAAE,UAAAC,EAAW,QAAAC,CAAQ,CAAC,EACnD,KACCkE,EAAIC,GAASzB,EAAM,KAAKyB,CAAK,CAAC,EAC9BC,EAAS,IAAM1B,EAAM,SAAS,CAAC,EAC/BhC,EAAIyD,GAAUE,EAAA,CAAE,IAAKvE,GAAOqE,EAAQ,CACtC,CACJ,CAAC,CACH,CC9RO,SAASG,GACdC,EAAkB,CAAE,UAAAC,EAAW,MAAAC,EAAO,QAAAC,CAAQ,EACvB,CAGvB,IAAMC,EAAaH,EAChB,KACCI,EAAI,CAAC,CAAE,OAAQ,CAAE,EAAAC,CAAE,CAAE,IAAMA,CAAC,EAC5BC,GAAY,EAAG,CAAC,EAChBF,EAAI,CAAC,CAAC,EAAGG,CAAC,IAAM,EAAIA,GAAKA,EAAI,CAAC,EAC9BC,EAAqB,CACvB,EAGIC,EAAUR,EACb,KACCG,EAAI,CAAC,CAAE,OAAAM,CAAO,IAAMA,CAAM,CAC5B,EAGF,OAAOC,EAAc,CAACF,EAASN,CAAU,CAAC,EACvC,KACCC,EAAI,CAAC,CAACM,EAAQE,CAAS,IAAM,EAAEF,GAAUE,EAAU,EACnDJ,EAAqB,EACrBK,EAAUX,EAAQ,KAAKY,GAAK,CAAC,CAAC,CAAC,EAC/BC,GAAQ,EAAI,EACZC,GAAO,CAAE,MAAO,GAAI,CAAC,EACrBZ,EAAIa,IAAW,CAAE,OAAAA,CAAO,EAAE,CAC5B,CACJ,CAYO,SAASC,GACdC,EAAiB,CAAE,UAAAnB,EAAW,QAAAoB,EAAS,MAAAnB,EAAO,QAAAC,CAAQ,EACpB,CAClC,IAAMmB,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGT,GAAQ,EAAI,CAAC,EACxD,OAAAM,EAAM,UAAU,CAGd,KAAK,CAAE,OAAAJ,CAAO,EAAG,CACfE,EAAG,OAASF,EACRA,GACFE,EAAG,aAAa,WAAY,IAAI,EAChCA,EAAG,KAAK,GAERA,EAAG,gBAAgB,UAAU,CAEjC,EAGA,UAAW,CACTA,EAAG,MAAM,IAAM,GACfA,EAAG,OAAS,GACZA,EAAG,gBAAgB,UAAU,CAC/B,CACF,CAAC,EAGDC,EACG,KACCP,EAAUU,CAAK,EACfE,GAAwB,QAAQ,CAClC,EACG,UAAU,CAAC,CAAE,OAAAC,CAAO,IAAM,CACzBP,EAAG,MAAM,IAAM,GAAGO,EAAS,EAAE,IAC/B,CAAC,EAGLC,EAAUR,EAAI,OAAO,EAClB,UAAUS,GAAM,CACfA,EAAG,eAAe,EAClB,OAAO,SAAS,CAAE,IAAK,CAAE,CAAC,CAC5B,CAAC,EAGI9B,GAAeqB,EAAI,CAAE,UAAAnB,EAAW,MAAAC,EAAO,QAAAC,CAAQ,CAAC,EACpD,KACC2B,EAAIC,GAAST,EAAM,KAAKS,CAAK,CAAC,EAC9BC,EAAS,IAAMV,EAAM,SAAS,CAAC,EAC/BjB,EAAI0B,GAAUE,EAAA,CAAE,IAAKb,GAAOW,EAAQ,CACtC,CACJ,CClHO,SAASG,GACd,CAAE,UAAAC,EAAW,UAAAC,CAAU,EACjB,CACND,EACG,KACCE,EAAU,IAAMC,EAAY,cAAc,CAAC,EAC3CC,GAASC,GAAMC,GAAuBD,CAAE,EACrC,KACCE,EAAUP,EAAU,KAAKQ,GAAK,CAAC,CAAC,CAAC,EACjCC,EAAOC,GAAWA,CAAO,EACzBC,EAAI,IAAMN,CAAE,EACZO,GAAK,CAAC,CACR,CACF,EACAH,EAAOJ,GAAMA,EAAG,YAAcA,EAAG,WAAW,EAC5CD,GAASC,GAAM,CACb,IAAMQ,EAAOR,EAAG,UACVS,EAAOT,EAAG,QAAQ,GAAG,GAAKA,EAIhC,OAHAS,EAAK,MAAQD,EAGRE,EAAQ,kBAAkB,EAIxBC,GAAoBF,EAAM,CAAE,UAAAb,CAAU,CAAC,EAC3C,KACCM,EAAUP,EAAU,KAAKQ,GAAK,CAAC,CAAC,CAAC,EACjCS,EAAS,IAAMH,EAAK,gBAAgB,OAAO,CAAC,CAC9C,EAPOI,CAQX,CAAC,CACH,EACG,UAAU,EAGXH,EAAQ,kBAAkB,GAC5Bf,EACG,KACCE,EAAU,IAAMC,EAAY,YAAY,CAAC,EACzCC,GAASC,GAAMW,GAAoBX,EAAI,CAAE,UAAAJ,CAAU,CAAC,CAAC,CACvD,EACG,UAAU,CACnB,CCpDO,SAASkB,GACd,CAAE,UAAAC,EAAW,QAAAC,CAAQ,EACf,CACND,EACG,KACCE,EAAU,IAAMC,EACd,2BACF,CAAC,EACDC,EAAIC,GAAM,CACRA,EAAG,cAAgB,GACnBA,EAAG,QAAU,EACf,CAAC,EACDC,GAASD,GAAME,EAAUF,EAAI,QAAQ,EAClC,KACCG,GAAU,IAAMH,EAAG,UAAU,SAAS,0BAA0B,CAAC,EACjEI,EAAI,IAAMJ,CAAE,CACd,CACF,EACAK,GAAeT,CAAO,CACxB,EACG,UAAU,CAAC,CAACI,EAAIM,CAAM,IAAM,CAC3BN,EAAG,UAAU,OAAO,0BAA0B,EAC1CM,IACFN,EAAG,QAAU,GACjB,CAAC,CACP,CC9BA,SAASO,IAAyB,CAChC,MAAO,qBAAqB,KAAK,UAAU,SAAS,CACtD,CAiBO,SAASC,GACd,CAAE,UAAAC,CAAU,EACN,CACNA,EACG,KACCC,EAAU,IAAMC,EAAY,qBAAqB,CAAC,EAClDC,EAAIC,GAAMA,EAAG,gBAAgB,mBAAmB,CAAC,EACjDC,EAAOP,EAAa,EACpBQ,GAASF,GAAMG,EAAUH,EAAI,YAAY,EACtC,KACCI,EAAI,IAAMJ,CAAE,CACd,CACF,CACF,EACG,UAAUA,GAAM,CACf,IAAMK,EAAML,EAAG,UAGXK,IAAQ,EACVL,EAAG,UAAY,EAGNK,EAAML,EAAG,eAAiBA,EAAG,eACtCA,EAAG,UAAYK,EAAM,EAEzB,CAAC,CACP,CCpCO,SAASC,GACd,CAAE,UAAAC,EAAW,QAAAC,CAAQ,EACf,CACNC,EAAc,CAACC,GAAY,QAAQ,EAAGF,CAAO,CAAC,EAC3C,KACCG,EAAI,CAAC,CAACC,EAAQC,CAAM,IAAMD,GAAU,CAACC,CAAM,EAC3CC,EAAUF,GAAUG,EAAGH,CAAM,EAC1B,KACCI,GAAMJ,EAAS,IAAM,GAAG,CAC1B,CACF,EACAK,GAAeV,CAAS,CAC1B,EACG,UAAU,CAAC,CAACK,EAAQ,CAAE,OAAQ,CAAE,EAAAM,CAAE,CAAC,CAAC,IAAM,CACzC,GAAIN,EACF,SAAS,KAAK,aAAa,qBAAsB,EAAE,EACnD,SAAS,KAAK,MAAM,IAAM,IAAIM,CAAC,SAC1B,CACL,IAAMC,EAAQ,GAAK,SAAS,SAAS,KAAK,MAAM,IAAK,EAAE,EACvD,SAAS,KAAK,gBAAgB,oBAAoB,EAClD,SAAS,KAAK,MAAM,IAAM,GACtBA,GACF,OAAO,SAAS,EAAGA,CAAK,CAC5B,CACF,CAAC,CACP,CC7DK,OAAO,UACV,OAAO,QAAU,SAAUC,EAAa,CACtC,IAAMC,EAA2B,CAAC,EAClC,QAAWC,KAAO,OAAO,KAAKF,CAAG,EAE/BC,EAAK,KAAK,CAACC,EAAKF,EAAIE,CAAG,CAAC,CAAC,EAG3B,OAAOD,CACT,GAGG,OAAO,SACV,OAAO,OAAS,SAAUD,EAAa,CACrC,IAAMC,EAAiB,CAAC,EACxB,QAAWC,KAAO,OAAO,KAAKF,CAAG,EAE/BC,EAAK,KAAKD,EAAIE,CAAG,CAAC,EAGpB,OAAOD,CACT,GAKE,OAAO,SAAY,cAGhB,QAAQ,UAAU,WACrB,QAAQ,UAAU,SAAW,SAC3BE,EAA8BC,EACxB,CACF,OAAOD,GAAM,UACf,KAAK,WAAaA,EAAE,KACpB,KAAK,UAAYA,EAAE,MAEnB,KAAK,WAAaA,EAClB,KAAK,UAAYC,EAErB,GAGG,QAAQ,UAAU,cACrB,QAAQ,UAAU,YAAc,YAC3BC,EACG,CACN,IAAMC,EAAS,KAAK,WACpB,GAAIA,EAAQ,CACND,EAAM,SAAW,GACnBC,EAAO,YAAY,IAAI,EAGzB,QAASC,EAAIF,EAAM,OAAS,EAAGE,GAAK,EAAGA,IAAK,CAC1C,IAAIC,EAAOH,EAAME,CAAC,EACd,OAAOC,GAAS,SAClBA,EAAO,SAAS,eAAeA,CAAI,EAC5BA,EAAK,YACZA,EAAK,WAAW,YAAYA,CAAI,EAG7BD,EAGHD,EAAO,aAAa,KAAK,gBAAkBE,CAAI,EAF/CF,EAAO,aAAaE,EAAM,IAAI,CAGlC,CACF,CACF,I3MMJ,SAASC,IAA4C,CACnD,OAAI,SAAS,WAAa,QACjBC,GACL,GAAG,IAAI,IAAI,yBAA0BC,GAAO,IAAI,CAAC,EACnD,EACG,KAECC,EAAI,IAAM,OAAO,EACjBC,EAAY,CAAC,CACf,EAEKC,GACL,IAAI,IAAI,2BAA4BH,GAAO,IAAI,CACjD,CAEJ,CAOA,SAAS,gBAAgB,UAAU,OAAO,OAAO,EACjD,SAAS,gBAAgB,UAAU,IAAI,IAAI,EAG3C,IAAMI,GAAYC,GAAc,EAC1BC,GAAYC,GAAc,EAC1BC,GAAYC,GAAoBH,EAAS,EACzCI,GAAYC,GAAc,EAG1BC,GAAYC,GAAc,EAC1BC,GAAYC,GAAW,oBAAoB,EAC3CC,GAAYD,GAAW,qBAAqB,EAC5CE,GAAYC,GAAW,EAGvBlB,GAASmB,GAAc,EACvBC,GAAS,SAAS,MAAM,UAAU,QAAQ,EAC5CtB,GAAiB,EACjBuB,GAGEC,GAAS,IAAIC,EACnBC,GAAiB,CAAE,OAAAF,EAAO,CAAC,EAG3B,IAAMG,GAAY,IAAIF,EAGlBG,EAAQ,oBAAoB,GAC9BC,GAAuB,CAAE,UAAArB,GAAW,UAAAM,GAAW,UAAAa,EAAU,CAAC,EACvD,UAAUrB,EAAS,EAzJxB,IAAAwB,KA4JIA,GAAA5B,GAAO,UAAP,YAAA4B,GAAgB,YAAa,QAC/BC,GAAqB,CAAE,UAAAzB,EAAU,CAAC,EAGpC0B,EAAMxB,GAAWE,EAAO,EACrB,KACCuB,GAAM,GAAG,CACX,EACG,UAAU,IAAM,CACfC,GAAU,SAAU,EAAK,EACzBA,GAAU,SAAU,EAAK,CAC3B,CAAC,EAGLtB,GACG,KACCuB,EAAO,CAAC,CAAE,KAAAC,CAAK,IAAMA,IAAS,QAAQ,CACxC,EACG,UAAUC,GAAO,CAChB,OAAQA,EAAI,KAAM,CAGhB,IAAK,IACL,IAAK,IACH,IAAMC,EAAOC,GAAoC,gBAAgB,EAC7D,OAAOD,GAAS,aAClBE,GAAYF,CAAI,EAClB,MAGF,IAAK,IACL,IAAK,IACH,IAAMG,EAAOF,GAAoC,gBAAgB,EAC7D,OAAOE,GAAS,aAClBD,GAAYC,CAAI,EAClB,MAGF,IAAK,QACH,IAAMC,EAASC,GAAiB,EAC5BD,aAAkB,kBACpBA,EAAO,MAAM,CACnB,CACF,CAAC,EAGLE,GAAc,CAAE,UAAA9B,GAAW,UAAAR,EAAU,CAAC,EACtCuC,GAAmB,CAAE,UAAAvC,GAAW,QAAAU,EAAQ,CAAC,EACzC8B,GAAe,CAAE,UAAAxC,EAAU,CAAC,EAC5ByC,GAAgB,CAAE,UAAAjC,GAAW,QAAAE,EAAQ,CAAC,EAGtC,IAAMgC,GAAUC,GAAYC,GAAoB,QAAQ,EAAG,CAAE,UAAApC,EAAU,CAAC,EAClEqC,GAAQ7C,GACX,KACCH,EAAI,IAAM+C,GAAoB,MAAM,CAAC,EACrCE,EAAUC,GAAMC,GAAUD,EAAI,CAAE,UAAAvC,GAAW,QAAAkC,EAAQ,CAAC,CAAC,EACrD5C,EAAY,CAAC,CACf,EAGImD,GAAWvB,EAGf,GAAGwB,GAAqB,SAAS,EAC9B,IAAIH,GAAMI,GAAaJ,EAAI,CAAE,QAAA3C,EAAQ,CAAC,CAAC,EAG1C,GAAG8C,GAAqB,QAAQ,EAC7B,IAAIH,GAAMK,GAAYL,EAAI,CAAE,OAAA7B,EAAO,CAAC,CAAC,EAGxC,GAAGgC,GAAqB,QAAQ,EAC7B,IAAIH,GAAMM,GAAYN,EAAI,CAAE,UAAAvC,GAAW,QAAAkC,GAAS,MAAAG,EAAM,CAAC,CAAC,EAG3D,GAAGK,GAAqB,SAAS,EAC9B,IAAIH,GAAMO,GAAaP,CAAE,CAAC,EAG7B,GAAGG,GAAqB,UAAU,EAC/B,IAAIH,GAAMQ,GAAcR,EAAI,CAAE,UAAA1B,EAAU,CAAC,CAAC,EAG7C,GAAG6B,GAAqB,QAAQ,EAC7B,IAAIH,GAAMS,GAAYT,EAAI,CAAE,OAAA/B,GAAQ,UAAAV,EAAU,CAAC,CAAC,EAGnD,GAAG4C,GAAqB,QAAQ,EAC7B,IAAIH,GAAMU,GAAYV,CAAE,CAAC,CAC9B,EAGMW,GAAWC,EAAM,IAAMjC,EAG3B,GAAGwB,GAAqB,UAAU,EAC/B,IAAIH,GAAMa,GAAcb,CAAE,CAAC,EAG9B,GAAGG,GAAqB,SAAS,EAC9B,IAAIH,GAAMc,GAAad,EAAI,CAAE,UAAAvC,GAAW,QAAAJ,GAAS,OAAAS,EAAO,CAAC,CAAC,EAG7D,GAAGqC,GAAqB,SAAS,EAC9B,IAAIH,GAAMzB,EAAQ,kBAAkB,EACjCwC,GAAoBf,EAAI,CAAE,OAAA/B,GAAQ,UAAAd,EAAU,CAAC,EAC7C6D,CACJ,EAGF,GAAGb,GAAqB,cAAc,EACnC,IAAIH,GAAMiB,GAAiBjB,EAAI,CAAE,UAAAvC,GAAW,QAAAkC,EAAQ,CAAC,CAAC,EAGzD,GAAGQ,GAAqB,SAAS,EAC9B,IAAIH,GAAMA,EAAG,aAAa,cAAc,IAAM,aAC3CkB,GAAGrD,GAAS,IAAMsD,GAAanB,EAAI,CAAE,UAAAvC,GAAW,QAAAkC,GAAS,MAAAG,EAAM,CAAC,CAAC,EACjEoB,GAAGvD,GAAS,IAAMwD,GAAanB,EAAI,CAAE,UAAAvC,GAAW,QAAAkC,GAAS,MAAAG,EAAM,CAAC,CAAC,CACrE,EAGF,GAAGK,GAAqB,MAAM,EAC3B,IAAIH,GAAMoB,GAAUpB,EAAI,CAAE,UAAAvC,GAAW,QAAAkC,EAAQ,CAAC,CAAC,EAGlD,GAAGQ,GAAqB,KAAK,EAC1B,IAAIH,GAAMqB,GAAqBrB,EAAI,CAClC,UAAAvC,GAAW,QAAAkC,GAAS,MAAAG,GAAO,QAAAzC,EAC7B,CAAC,CAAC,EAGJ,GAAG8C,GAAqB,KAAK,EAC1B,IAAIH,GAAMsB,GAAetB,EAAI,CAAE,UAAAvC,GAAW,QAAAkC,GAAS,MAAAG,GAAO,QAAAzC,EAAQ,CAAC,CAAC,CACzE,CAAC,EAGKkE,GAAatE,GAChB,KACC8C,EAAU,IAAMY,EAAQ,EACxBa,GAAUtB,EAAQ,EAClBnD,EAAY,CAAC,CACf,EAGFwE,GAAW,UAAU,EAMrB,OAAO,UAAatE,GACpB,OAAO,UAAaE,GACpB,OAAO,QAAaE,GACpB,OAAO,UAAaE,GACpB,OAAO,UAAaE,GACpB,OAAO,QAAaE,GACpB,OAAO,QAAaE,GACpB,OAAO,OAAaC,GACpB,OAAO,OAAaK,GACpB,OAAO,UAAaG,GACpB,OAAO,WAAaiD",
-  "names": ["require_focus_visible", "__commonJSMin", "exports", "module", "global", "factory", "applyFocusVisiblePolyfill", "scope", "hadKeyboardEvent", "hadFocusVisibleRecently", "hadFocusVisibleRecentlyTimeout", "inputTypesAllowlist", "isValidFocusTarget", "el", "focusTriggersKeyboardModality", "type", "tagName", "addFocusVisibleClass", "removeFocusVisibleClass", "onKeyDown", "e", "onPointerDown", "onFocus", "onBlur", "onVisibilityChange", "addInitialPointerMoveListeners", "onInitialPointerMove", "removeInitialPointerMoveListeners", "event", "error", "require_escape_html", "__commonJSMin", "exports", "module", "matchHtmlRegExp", "escapeHtml", "string", "str", "match", "escape", "html", "index", "lastIndex", "require_clipboard", "__commonJSMin", "exports", "module", "root", "factory", "__webpack_modules__", "__unused_webpack_module", "__webpack_exports__", "__webpack_require__", "clipboard", "tiny_emitter", "tiny_emitter_default", "listen", "listen_default", "src_select", "select_default", "command", "type", "err", "ClipboardActionCut", "target", "selectedText", "actions_cut", "createFakeElement", "value", "isRTL", "fakeElement", "yPosition", "fakeCopyAction", "options", "ClipboardActionCopy", "actions_copy", "_typeof", "obj", "ClipboardActionDefault", "_options$action", "action", "container", "text", "actions_default", "clipboard_typeof", "_classCallCheck", "instance", "Constructor", "_defineProperties", "props", "i", "descriptor", "_createClass", "protoProps", "staticProps", "_inherits", "subClass", "superClass", "_setPrototypeOf", "o", "p", "_createSuper", "Derived", "hasNativeReflectConstruct", "_isNativeReflectConstruct", "Super", "_getPrototypeOf", "result", "NewTarget", "_possibleConstructorReturn", "self", "call", "_assertThisInitialized", "e", "getAttributeValue", "suffix", "element", "attribute", "Clipboard", "_Emitter", "_super", "trigger", "_this", "_this2", "selector", "actions", "support", "DOCUMENT_NODE_TYPE", "proto", "closest", "__unused_webpack_exports", "_delegate", "callback", "useCapture", "listenerFn", "listener", "delegate", "elements", "is", "listenNode", "listenNodeList", "listenSelector", "node", "nodeList", "select", "isReadOnly", "selection", "range", "E", "name", "ctx", "data", "evtArr", "len", "evts", "liveEvents", "__webpack_module_cache__", "moduleId", "getter", "definition", "key", "prop", "import_focus_visible", "extendStatics", "d", "b", "p", "__extends", "__", "__awaiter", "thisArg", "_arguments", "P", "generator", "adopt", "value", "resolve", "reject", "fulfilled", "step", "e", "rejected", "result", "__generator", "body", "_", "t", "f", "y", "g", "verb", "n", "v", "op", "__values", "o", "s", "m", "i", "__read", "n", "r", "ar", "e", "error", "__spreadArray", "to", "from", "pack", "i", "l", "ar", "__await", "v", "__asyncGenerator", "thisArg", "_arguments", "generator", "g", "q", "verb", "awaitReturn", "f", "reject", "n", "a", "b", "resume", "step", "e", "settle", "r", "fulfill", "value", "__asyncValues", "o", "m", "i", "__values", "verb", "n", "v", "resolve", "reject", "settle", "d", "isFunction", "value", "createErrorClass", "createImpl", "_super", "instance", "ctorFunc", "UnsubscriptionError", "createErrorClass", "_super", "errors", "err", "i", "arrRemove", "arr", "item", "index", "Subscription", "initialTeardown", "errors", "_parentage", "_parentage_1", "__values", "_parentage_1_1", "parent_1", "initialFinalizer", "isFunction", "e", "UnsubscriptionError", "_finalizers", "_finalizers_1", "_finalizers_1_1", "finalizer", "execFinalizer", "err", "__spreadArray", "__read", "teardown", "_a", "parent", "arrRemove", "empty", "EMPTY_SUBSCRIPTION", "Subscription", "isSubscription", "value", "isFunction", "execFinalizer", "finalizer", "config", "timeoutProvider", "handler", "timeout", "args", "_i", "delegate", "__spreadArray", "__read", "handle", "reportUnhandledError", "err", "timeoutProvider", "onUnhandledError", "config", "noop", "COMPLETE_NOTIFICATION", "createNotification", "errorNotification", "error", "nextNotification", "value", "kind", "context", "errorContext", "cb", "config", "isRoot", "_a", "errorThrown", "error", "captureError", "err", "Subscriber", "_super", "__extends", "destination", "_this", "isSubscription", "EMPTY_OBSERVER", "next", "error", "complete", "SafeSubscriber", "value", "handleStoppedNotification", "nextNotification", "err", "errorNotification", "COMPLETE_NOTIFICATION", "Subscription", "_bind", "bind", "fn", "thisArg", "ConsumerObserver", "partialObserver", "value", "error", "handleUnhandledError", "err", "SafeSubscriber", "_super", "__extends", "observerOrNext", "complete", "_this", "isFunction", "context_1", "config", "Subscriber", "handleUnhandledError", "error", "config", "captureError", "reportUnhandledError", "defaultErrorHandler", "err", "handleStoppedNotification", "notification", "subscriber", "onStoppedNotification", "timeoutProvider", "EMPTY_OBSERVER", "noop", "observable", "identity", "x", "pipe", "fns", "_i", "pipeFromArray", "identity", "input", "prev", "fn", "Observable", "subscribe", "operator", "observable", "observerOrNext", "error", "complete", "_this", "subscriber", "isSubscriber", "SafeSubscriber", "errorContext", "_a", "source", "sink", "err", "next", "promiseCtor", "getPromiseCtor", "resolve", "reject", "value", "operations", "_i", "pipeFromArray", "x", "getPromiseCtor", "promiseCtor", "_a", "config", "isObserver", "value", "isFunction", "isSubscriber", "Subscriber", "isSubscription", "hasLift", "source", "isFunction", "operate", "init", "liftedSource", "err", "createOperatorSubscriber", "destination", "onNext", "onComplete", "onError", "onFinalize", "OperatorSubscriber", "_super", "__extends", "shouldUnsubscribe", "_this", "value", "err", "closed_1", "_a", "Subscriber", "animationFrameProvider", "callback", "request", "cancel", "delegate", "handle", "timestamp", "Subscription", "args", "_i", "__spreadArray", "__read", "ObjectUnsubscribedError", "createErrorClass", "_super", "Subject", "_super", "__extends", "_this", "operator", "subject", "AnonymousSubject", "ObjectUnsubscribedError", "value", "errorContext", "_b", "__values", "_c", "observer", "err", "observers", "_a", "subscriber", "hasError", "isStopped", "EMPTY_SUBSCRIPTION", "Subscription", "arrRemove", "thrownError", "observable", "Observable", "destination", "source", "AnonymousSubject", "_super", "__extends", "destination", "source", "_this", "value", "_b", "_a", "err", "subscriber", "EMPTY_SUBSCRIPTION", "Subject", "BehaviorSubject", "_super", "__extends", "_value", "_this", "subscriber", "subscription", "_a", "hasError", "thrownError", "value", "Subject", "dateTimestampProvider", "ReplaySubject", "_super", "__extends", "_bufferSize", "_windowTime", "_timestampProvider", "dateTimestampProvider", "_this", "value", "_a", "isStopped", "_buffer", "_infiniteTimeWindow", "subscriber", "subscription", "copy", "i", "adjustedBufferSize", "now", "last", "Subject", "Action", "_super", "__extends", "scheduler", "work", "state", "delay", "Subscription", "intervalProvider", "handler", "timeout", "args", "_i", "delegate", "__spreadArray", "__read", "handle", "AsyncAction", "_super", "__extends", "scheduler", "work", "_this", "state", "delay", "id", "_a", "_id", "intervalProvider", "_scheduler", "error", "_delay", "errored", "errorValue", "e", "actions", "arrRemove", "Action", "Scheduler", "schedulerActionCtor", "now", "work", "delay", "state", "dateTimestampProvider", "AsyncScheduler", "_super", "__extends", "SchedulerAction", "now", "Scheduler", "_this", "action", "actions", "error", "asyncScheduler", "AsyncScheduler", "AsyncAction", "async", "QueueAction", "_super", "__extends", "scheduler", "work", "_this", "state", "delay", "id", "AsyncAction", "QueueScheduler", "_super", "__extends", "AsyncScheduler", "queueScheduler", "QueueScheduler", "QueueAction", "AnimationFrameAction", "_super", "__extends", "scheduler", "work", "_this", "id", "delay", "animationFrameProvider", "actions", "_a", "AsyncAction", "AnimationFrameScheduler", "_super", "__extends", "action", "flushId", "actions", "error", "AsyncScheduler", "animationFrameScheduler", "AnimationFrameScheduler", "AnimationFrameAction", "EMPTY", "Observable", "subscriber", "isScheduler", "value", "isFunction", "last", "arr", "popResultSelector", "args", "isFunction", "popScheduler", "isScheduler", "popNumber", "defaultValue", "isArrayLike", "x", "isPromise", "value", "isFunction", "isInteropObservable", "input", "isFunction", "observable", "isAsyncIterable", "obj", "isFunction", "createInvalidObservableTypeError", "input", "getSymbolIterator", "iterator", "isIterable", "input", "isFunction", "iterator", "readableStreamLikeToAsyncGenerator", "readableStream", "reader", "__await", "_a", "_b", "value", "done", "isReadableStreamLike", "obj", "isFunction", "innerFrom", "input", "Observable", "isInteropObservable", "fromInteropObservable", "isArrayLike", "fromArrayLike", "isPromise", "fromPromise", "isAsyncIterable", "fromAsyncIterable", "isIterable", "fromIterable", "isReadableStreamLike", "fromReadableStreamLike", "createInvalidObservableTypeError", "obj", "subscriber", "obs", "observable", "isFunction", "array", "i", "promise", "value", "err", "reportUnhandledError", "iterable", "iterable_1", "__values", "iterable_1_1", "asyncIterable", "process", "readableStream", "readableStreamLikeToAsyncGenerator", "asyncIterable_1", "__asyncValues", "asyncIterable_1_1", "executeSchedule", "parentSubscription", "scheduler", "work", "delay", "repeat", "scheduleSubscription", "observeOn", "scheduler", "delay", "operate", "source", "subscriber", "createOperatorSubscriber", "value", "executeSchedule", "err", "subscribeOn", "scheduler", "delay", "operate", "source", "subscriber", "scheduleObservable", "input", "scheduler", "innerFrom", "subscribeOn", "observeOn", "schedulePromise", "input", "scheduler", "innerFrom", "subscribeOn", "observeOn", "scheduleArray", "input", "scheduler", "Observable", "subscriber", "i", "scheduleIterable", "input", "scheduler", "Observable", "subscriber", "iterator", "executeSchedule", "value", "done", "_a", "err", "isFunction", "scheduleAsyncIterable", "input", "scheduler", "Observable", "subscriber", "executeSchedule", "iterator", "result", "scheduleReadableStreamLike", "input", "scheduler", "scheduleAsyncIterable", "readableStreamLikeToAsyncGenerator", "scheduled", "input", "scheduler", "isInteropObservable", "scheduleObservable", "isArrayLike", "scheduleArray", "isPromise", "schedulePromise", "isAsyncIterable", "scheduleAsyncIterable", "isIterable", "scheduleIterable", "isReadableStreamLike", "scheduleReadableStreamLike", "createInvalidObservableTypeError", "from", "input", "scheduler", "scheduled", "innerFrom", "of", "args", "_i", "scheduler", "popScheduler", "from", "throwError", "errorOrErrorFactory", "scheduler", "errorFactory", "isFunction", "init", "subscriber", "Observable", "EmptyError", "createErrorClass", "_super", "isValidDate", "value", "map", "project", "thisArg", "operate", "source", "subscriber", "index", "createOperatorSubscriber", "value", "isArray", "callOrApply", "fn", "args", "__spreadArray", "__read", "mapOneOrManyArgs", "map", "isArray", "getPrototypeOf", "objectProto", "getKeys", "argsArgArrayOrObject", "args", "first_1", "isPOJO", "keys", "key", "obj", "createObject", "keys", "values", "result", "key", "i", "combineLatest", "args", "_i", "scheduler", "popScheduler", "resultSelector", "popResultSelector", "_a", "argsArgArrayOrObject", "observables", "keys", "from", "result", "Observable", "combineLatestInit", "values", "createObject", "identity", "mapOneOrManyArgs", "valueTransform", "subscriber", "maybeSchedule", "length", "active", "remainingFirstValues", "i", "source", "hasFirstValue", "createOperatorSubscriber", "value", "execute", "subscription", "executeSchedule", "mergeInternals", "source", "subscriber", "project", "concurrent", "onBeforeNext", "expand", "innerSubScheduler", "additionalFinalizer", "buffer", "active", "index", "isComplete", "checkComplete", "outerNext", "value", "doInnerSub", "innerComplete", "innerFrom", "createOperatorSubscriber", "innerValue", "bufferedValue", "executeSchedule", "err", "mergeMap", "project", "resultSelector", "concurrent", "isFunction", "a", "i", "map", "b", "ii", "innerFrom", "operate", "source", "subscriber", "mergeInternals", "mergeAll", "concurrent", "mergeMap", "identity", "concatAll", "mergeAll", "concat", "args", "_i", "concatAll", "from", "popScheduler", "defer", "observableFactory", "Observable", "subscriber", "innerFrom", "nodeEventEmitterMethods", "eventTargetMethods", "jqueryMethods", "fromEvent", "target", "eventName", "options", "resultSelector", "isFunction", "mapOneOrManyArgs", "_a", "__read", "isEventTarget", "methodName", "handler", "isNodeStyleEventEmitter", "toCommonHandlerRegistry", "isJQueryStyleEventEmitter", "add", "remove", "isArrayLike", "mergeMap", "subTarget", "innerFrom", "Observable", "subscriber", "args", "_i", "fromEventPattern", "addHandler", "removeHandler", "resultSelector", "mapOneOrManyArgs", "Observable", "subscriber", "handler", "e", "_i", "retValue", "isFunction", "timer", "dueTime", "intervalOrScheduler", "scheduler", "async", "intervalDuration", "isScheduler", "Observable", "subscriber", "due", "isValidDate", "n", "merge", "args", "_i", "scheduler", "popScheduler", "concurrent", "popNumber", "sources", "innerFrom", "mergeAll", "from", "EMPTY", "NEVER", "Observable", "noop", "isArray", "argsOrArgArray", "args", "filter", "predicate", "thisArg", "operate", "source", "subscriber", "index", "createOperatorSubscriber", "value", "zip", "args", "_i", "resultSelector", "popResultSelector", "sources", "argsOrArgArray", "Observable", "subscriber", "buffers", "completed", "sourceIndex", "innerFrom", "createOperatorSubscriber", "value", "buffer", "result", "__spreadArray", "__read", "i", "EMPTY", "audit", "durationSelector", "operate", "source", "subscriber", "hasValue", "lastValue", "durationSubscriber", "isComplete", "endDuration", "value", "cleanupDuration", "createOperatorSubscriber", "innerFrom", "auditTime", "duration", "scheduler", "asyncScheduler", "audit", "timer", "bufferCount", "bufferSize", "startBufferEvery", "operate", "source", "subscriber", "buffers", "count", "createOperatorSubscriber", "value", "toEmit", "buffers_1", "__values", "buffers_1_1", "buffer", "toEmit_1", "toEmit_1_1", "arrRemove", "buffers_2", "buffers_2_1", "catchError", "selector", "operate", "source", "subscriber", "innerSub", "syncUnsub", "handledResult", "createOperatorSubscriber", "err", "innerFrom", "scanInternals", "accumulator", "seed", "hasSeed", "emitOnNext", "emitBeforeComplete", "source", "subscriber", "hasState", "state", "index", "createOperatorSubscriber", "value", "i", "combineLatest", "args", "_i", "resultSelector", "popResultSelector", "pipe", "__spreadArray", "__read", "mapOneOrManyArgs", "operate", "source", "subscriber", "combineLatestInit", "argsOrArgArray", "combineLatestWith", "otherSources", "_i", "combineLatest", "__spreadArray", "__read", "debounce", "durationSelector", "operate", "source", "subscriber", "hasValue", "lastValue", "durationSubscriber", "emit", "value", "createOperatorSubscriber", "noop", "innerFrom", "debounceTime", "dueTime", "scheduler", "asyncScheduler", "operate", "source", "subscriber", "activeTask", "lastValue", "lastTime", "emit", "value", "emitWhenIdle", "targetTime", "now", "createOperatorSubscriber", "defaultIfEmpty", "defaultValue", "operate", "source", "subscriber", "hasValue", "createOperatorSubscriber", "value", "take", "count", "EMPTY", "operate", "source", "subscriber", "seen", "createOperatorSubscriber", "value", "ignoreElements", "operate", "source", "subscriber", "createOperatorSubscriber", "noop", "mapTo", "value", "map", "delayWhen", "delayDurationSelector", "subscriptionDelay", "source", "concat", "take", "ignoreElements", "mergeMap", "value", "index", "innerFrom", "mapTo", "delay", "due", "scheduler", "asyncScheduler", "duration", "timer", "delayWhen", "distinctUntilChanged", "comparator", "keySelector", "identity", "defaultCompare", "operate", "source", "subscriber", "previousKey", "first", "createOperatorSubscriber", "value", "currentKey", "a", "b", "distinctUntilKeyChanged", "key", "compare", "distinctUntilChanged", "x", "y", "throwIfEmpty", "errorFactory", "defaultErrorFactory", "operate", "source", "subscriber", "hasValue", "createOperatorSubscriber", "value", "EmptyError", "endWith", "values", "_i", "source", "concat", "of", "__spreadArray", "__read", "finalize", "callback", "operate", "source", "subscriber", "first", "predicate", "defaultValue", "hasDefaultValue", "source", "filter", "v", "identity", "take", "defaultIfEmpty", "throwIfEmpty", "EmptyError", "takeLast", "count", "EMPTY", "operate", "source", "subscriber", "buffer", "createOperatorSubscriber", "value", "buffer_1", "__values", "buffer_1_1", "merge", "args", "_i", "scheduler", "popScheduler", "concurrent", "popNumber", "argsOrArgArray", "operate", "source", "subscriber", "mergeAll", "from", "__spreadArray", "__read", "mergeWith", "otherSources", "_i", "merge", "__spreadArray", "__read", "repeat", "countOrConfig", "count", "delay", "_a", "EMPTY", "operate", "source", "subscriber", "soFar", "sourceSub", "resubscribe", "notifier", "timer", "innerFrom", "notifierSubscriber_1", "createOperatorSubscriber", "subscribeToSource", "syncUnsub", "scan", "accumulator", "seed", "operate", "scanInternals", "share", "options", "_a", "connector", "Subject", "_b", "resetOnError", "_c", "resetOnComplete", "_d", "resetOnRefCountZero", "wrapperSource", "connection", "resetConnection", "subject", "refCount", "hasCompleted", "hasErrored", "cancelReset", "reset", "resetAndUnsubscribe", "conn", "operate", "source", "subscriber", "dest", "handleReset", "SafeSubscriber", "value", "err", "innerFrom", "on", "args", "_i", "onSubscriber", "__spreadArray", "__read", "shareReplay", "configOrBufferSize", "windowTime", "scheduler", "bufferSize", "refCount", "_a", "_b", "_c", "share", "ReplaySubject", "skip", "count", "filter", "_", "index", "skipUntil", "notifier", "operate", "source", "subscriber", "taking", "skipSubscriber", "createOperatorSubscriber", "noop", "innerFrom", "value", "startWith", "values", "_i", "scheduler", "popScheduler", "operate", "source", "subscriber", "concat", "switchMap", "project", "resultSelector", "operate", "source", "subscriber", "innerSubscriber", "index", "isComplete", "checkComplete", "createOperatorSubscriber", "value", "innerIndex", "outerIndex", "innerFrom", "innerValue", "takeUntil", "notifier", "operate", "source", "subscriber", "innerFrom", "createOperatorSubscriber", "noop", "takeWhile", "predicate", "inclusive", "operate", "source", "subscriber", "index", "createOperatorSubscriber", "value", "result", "tap", "observerOrNext", "error", "complete", "tapObserver", "isFunction", "operate", "source", "subscriber", "_a", "isUnsub", "createOperatorSubscriber", "value", "err", "_b", "identity", "throttle", "durationSelector", "config", "operate", "source", "subscriber", "_a", "_b", "leading", "_c", "trailing", "hasValue", "sendValue", "throttled", "isComplete", "endThrottling", "send", "cleanupThrottling", "startThrottle", "value", "innerFrom", "createOperatorSubscriber", "throttleTime", "duration", "scheduler", "config", "asyncScheduler", "duration$", "timer", "throttle", "withLatestFrom", "inputs", "_i", "project", "popResultSelector", "operate", "source", "subscriber", "len", "otherValues", "hasValue", "ready", "i", "innerFrom", "createOperatorSubscriber", "value", "identity", "noop", "values", "__spreadArray", "__read", "zip", "sources", "_i", "operate", "source", "subscriber", "__spreadArray", "__read", "zipWith", "otherInputs", "_i", "zip", "__spreadArray", "__read", "watchDocument", "document$", "ReplaySubject", "fromEvent", "getElements", "selector", "node", "getElement", "el", "getOptionalElement", "getActiveElement", "_a", "_b", "_c", "_d", "observer$", "merge", "fromEvent", "debounceTime", "startWith", "map", "getActiveElement", "shareReplay", "watchElementFocus", "el", "active", "distinctUntilChanged", "watchElementHover", "el", "timeout", "defer", "merge", "fromEvent", "map", "debounce", "active", "timer", "identity", "startWith", "appendChild", "el", "child", "node", "h", "tag", "attributes", "children", "attr", "round", "value", "digits", "watchScript", "src", "script", "h", "defer", "merge", "fromEvent", "switchMap", "throwError", "map", "finalize", "take", "entry$", "Subject", "observer$", "defer", "watchScript", "of", "map", "entries", "entry", "switchMap", "observer", "merge", "NEVER", "finalize", "shareReplay", "getElementSize", "el", "watchElementSize", "target", "tap", "filter", "startWith", "getElementContentSize", "el", "getElementContainer", "parent", "getElementContainers", "containers", "getElementOffset", "el", "getElementOffsetAbsolute", "rect", "watchElementOffset", "merge", "fromEvent", "auditTime", "animationFrameScheduler", "map", "startWith", "getElementContentOffset", "el", "watchElementContentOffset", "merge", "fromEvent", "auditTime", "animationFrameScheduler", "map", "startWith", "entry$", "Subject", "observer$", "defer", "of", "entries", "entry", "switchMap", "observer", "merge", "NEVER", "finalize", "shareReplay", "watchElementVisibility", "el", "tap", "filter", "target", "map", "isIntersecting", "watchElementBoundary", "threshold", "watchElementContentOffset", "y", "visible", "getElementSize", "content", "getElementContentSize", "distinctUntilChanged", "toggles", "getElement", "getToggle", "name", "setToggle", "value", "watchToggle", "el", "fromEvent", "map", "startWith", "isSusceptibleToKeyboard", "el", "type", "watchComposition", "merge", "fromEvent", "map", "startWith", "watchKeyboard", "keyboard$", "filter", "ev", "getToggle", "mode", "active", "getActiveElement", "share", "switchMap", "EMPTY", "getLocation", "setLocation", "url", "navigate", "feature", "el", "h", "watchLocation", "Subject", "getLocationHash", "setLocationHash", "hash", "el", "h", "ev", "watchLocationHash", "location$", "merge", "fromEvent", "map", "startWith", "filter", "shareReplay", "watchLocationTarget", "id", "getOptionalElement", "watchMedia", "query", "media", "fromEventPattern", "next", "startWith", "watchPrint", "merge", "fromEvent", "map", "at", "query$", "factory", "switchMap", "active", "EMPTY", "request", "url", "options", "Observable", "observer", "req", "event", "_a", "length", "requestJSON", "switchMap", "res", "map", "body", "shareReplay", "requestHTML", "dom", "requestXML", "getViewportOffset", "watchViewportOffset", "merge", "fromEvent", "map", "startWith", "getViewportSize", "watchViewportSize", "fromEvent", "map", "startWith", "watchViewport", "combineLatest", "watchViewportOffset", "watchViewportSize", "map", "offset", "size", "shareReplay", "watchViewportAt", "el", "viewport$", "header$", "size$", "distinctUntilKeyChanged", "offset$", "combineLatest", "map", "getElementOffset", "height", "offset", "size", "x", "y", "recv", "worker", "fromEvent", "ev", "send", "send$", "Subject", "data", "watchWorker", "url", "recv$", "worker$", "done$", "ignoreElements", "endWith", "mergeWith", "takeUntil", "share", "script", "getElement", "config", "getLocation", "configuration", "feature", "flag", "translation", "key", "value", "getComponentElement", "type", "node", "getElement", "getComponentElements", "getElements", "watchAnnounce", "el", "button", "getElement", "fromEvent", "map", "content", "mountAnnounce", "feature", "EMPTY", "defer", "push$", "Subject", "hash", "tap", "state", "finalize", "__spreadValues", "watchConsent", "el", "target$", "map", "target", "mountConsent", "options", "internal$", "Subject", "hidden", "tap", "state", "finalize", "__spreadValues", "renderTooltip", "id", "style", "h", "renderInlineTooltip2", "children", "renderAnnotation", "id", "prefix", "anchor", "h", "renderTooltip", "renderClipboardButton", "id", "h", "translation", "import_escape_html", "renderSearchDocument", "document", "flag", "parent", "teaser", "missing", "key", "list", "h", "escapeHTML", "config", "configuration", "url", "feature", "match", "highlight", "value", "tags", "tag", "type", "translation", "renderSearchResultItem", "result", "threshold", "docs", "doc", "article", "index", "best", "more", "children", "section", "renderSourceFacts", "facts", "h", "key", "value", "round", "renderTabbedControl", "type", "classes", "h", "renderTable", "table", "h", "renderVersion", "version", "_a", "config", "configuration", "url", "h", "renderVersionSelector", "versions", "active", "translation", "sequence", "watchTooltip2", "el", "active$", "combineLatest", "watchElementFocus", "watchElementHover", "map", "focus", "hover", "distinctUntilChanged", "offset$", "defer", "getElementContainers", "mergeMap", "watchElementContentOffset", "throttleTime", "combineLatestWith", "getElementOffsetAbsolute", "first", "active", "switchMap", "offset", "share", "mountTooltip2", "dependencies", "content$", "viewport$", "id", "push$", "Subject", "show$", "BehaviorSubject", "ignoreElements", "endWith", "node$", "debounce", "timer", "queueScheduler", "EMPTY", "tap", "node", "startWith", "states", "origin$", "filter", "withLatestFrom", "_", "size", "host", "x", "height", "getElementSize", "origin", "getElement", "observeOn", "animationFrameScheduler", "state", "finalize", "__spreadValues", "mountInlineTooltip2", "container", "Observable", "observer", "title", "renderInlineTooltip2", "watchAnnotation", "el", "container", "offset$", "defer", "combineLatest", "watchElementOffset", "watchElementContentOffset", "map", "x", "y", "scroll", "width", "height", "getElementSize", "watchElementFocus", "switchMap", "active", "offset", "take", "mountAnnotation", "target$", "tooltip", "index", "push$", "Subject", "done$", "ignoreElements", "endWith", "watchElementVisibility", "takeUntil", "visible", "merge", "filter", "debounceTime", "auditTime", "animationFrameScheduler", "throttleTime", "origin", "fromEvent", "ev", "withLatestFrom", "_a", "parent", "getActiveElement", "target", "delay", "tap", "state", "finalize", "__spreadValues", "findHosts", "container", "getElements", "findMarkers", "markers", "el", "nodes", "it", "node", "text", "match", "id", "force", "marker", "swap", "source", "target", "mountAnnotationList", "target$", "print$", "parent", "prefix", "annotations", "getOptionalElement", "renderAnnotation", "EMPTY", "defer", "push$", "Subject", "done$", "ignoreElements", "endWith", "pairs", "annotation", "getElement", "takeUntil", "active", "inner", "child", "merge", "mountAnnotation", "finalize", "share", "findList", "el", "sibling", "mountAnnotationBlock", "options", "defer", "list", "mountAnnotationList", "EMPTY", "import_clipboard", "sequence", "findCandidateList", "el", "sibling", "watchCodeBlock", "watchElementSize", "map", "width", "getElementContentSize", "distinctUntilKeyChanged", "mountCodeBlock", "options", "hover", "factory$", "defer", "push$", "Subject", "done$", "takeLast", "scrollable", "content$", "ClipboardJS", "feature", "parent", "button", "renderClipboardButton", "mountInlineTooltip2", "container", "list", "annotations$", "mountAnnotationList", "takeUntil", "height", "distinctUntilChanged", "switchMap", "active", "EMPTY", "getElements", "tap", "state", "finalize", "__spreadValues", "mergeWith", "watchElementVisibility", "filter", "visible", "take", "watchDetails", "el", "target$", "print$", "open", "merge", "map", "target", "filter", "details", "active", "tap", "mountDetails", "options", "defer", "push$", "Subject", "action", "reveal", "state", "finalize", "__spreadValues", "mermaid_default", "mermaid$", "sequence", "fetchScripts", "watchScript", "of", "mountMermaid", "el", "tap", "mermaid_default", "map", "shareReplay", "__async", "id", "host", "h", "text", "svg", "fn", "shadow", "sentinel", "h", "mountDataTable", "el", "renderTable", "of", "watchContentTabs", "inputs", "initial", "input", "merge", "fromEvent", "map", "getElement", "startWith", "active", "mountContentTabs", "el", "viewport$", "target$", "container", "getElements", "prev", "renderTabbedControl", "next", "defer", "push$", "Subject", "done$", "ignoreElements", "endWith", "combineLatest", "watchElementSize", "watchElementVisibility", "takeUntil", "auditTime", "animationFrameScheduler", "size", "offset", "getElementOffset", "width", "getElementSize", "content", "getElementContentOffset", "watchElementContentOffset", "getElementContentSize", "direction", "filter", "label", "h", "ev", "tap", "feature", "skip", "withLatestFrom", "tab", "y", "set", "tabs", "media", "state", "finalize", "__spreadValues", "subscribeOn", "asyncScheduler", "mountContent", "el", "viewport$", "target$", "print$", "merge", "getElements", "child", "mountAnnotationBlock", "mountCodeBlock", "mountMermaid", "mountDataTable", "mountDetails", "mountContentTabs", "feature", "mountInlineTooltip2", "watchDialog", "_el", "alert$", "switchMap", "message", "merge", "of", "delay", "map", "active", "mountDialog", "el", "options", "inner", "getElement", "defer", "push$", "Subject", "tap", "state", "finalize", "__spreadValues", "sequence", "watchTooltip", "el", "host", "width", "getElementSize", "container", "getElementContainer", "scroll$", "watchElementContentOffset", "of", "active$", "merge", "watchElementFocus", "watchElementHover", "distinctUntilChanged", "combineLatest", "map", "active", "scroll", "x", "y", "getElementOffset", "size", "table", "mountTooltip", "title", "EMPTY", "id", "tooltip", "renderTooltip", "typeset", "getElement", "defer", "push$", "Subject", "offset", "filter", "debounceTime", "auditTime", "animationFrameScheduler", "throttleTime", "origin", "tap", "state", "finalize", "__spreadValues", "subscribeOn", "asyncScheduler", "isHidden", "viewport$", "feature", "of", "direction$", "map", "y", "bufferCount", "a", "b", "distinctUntilKeyChanged", "hidden$", "combineLatest", "filter", "offset", "direction", "distinctUntilChanged", "search$", "watchToggle", "search", "switchMap", "active", "startWith", "watchHeader", "el", "options", "defer", "watchElementSize", "height", "hidden", "shareReplay", "mountHeader", "header$", "main$", "push$", "Subject", "done$", "ignoreElements", "endWith", "combineLatestWith", "tooltips", "from", "getElements", "mergeMap", "child", "mountTooltip", "takeUntil", "state", "__spreadValues", "mergeWith", "watchHeaderTitle", "el", "viewport$", "header$", "watchViewportAt", "map", "y", "height", "getElementSize", "distinctUntilKeyChanged", "mountHeaderTitle", "options", "defer", "push$", "Subject", "active", "heading", "getOptionalElement", "EMPTY", "tap", "state", "finalize", "__spreadValues", "watchMain", "el", "viewport$", "header$", "adjust$", "map", "height", "distinctUntilChanged", "border$", "switchMap", "watchElementSize", "distinctUntilKeyChanged", "combineLatest", "header", "top", "bottom", "y", "a", "b", "watchPalette", "inputs", "current", "input", "index", "of", "mergeMap", "fromEvent", "map", "startWith", "shareReplay", "mountPalette", "el", "getElements", "meta", "h", "scheme", "media$", "watchMedia", "defer", "push$", "Subject", "palette", "media", "key", "value", "label", "filter", "ev", "withLatestFrom", "_", "header", "getComponentElement", "style", "color", "observeOn", "asyncScheduler", "takeUntil", "skip", "repeat", "tap", "state", "finalize", "__spreadValues", "mountProgress", "el", "progress$", "defer", "push$", "Subject", "value", "tap", "finalize", "map", "import_clipboard", "extract", "el", "copy", "text", "setupClipboardJS", "alert$", "ClipboardJS", "Observable", "subscriber", "getElement", "ev", "tap", "map", "translation", "resolve", "url", "base", "extract", "document", "sitemap", "el", "getElements", "getElement", "links", "link", "href", "fetchSitemap", "requestXML", "map", "catchError", "of", "handle", "ev", "sitemap", "EMPTY", "el", "url", "of", "head", "document", "tags", "getElements", "resolve", "key", "value", "inject", "next", "selector", "feature", "source", "getOptionalElement", "target", "html", "name", "container", "getComponentElement", "concat", "switchMap", "script", "Observable", "observer", "ignoreElements", "endWith", "setupInstantNavigation", "location$", "viewport$", "progress$", "config", "configuration", "sitemap$", "fetchSitemap", "instant$", "fromEvent", "combineLatestWith", "share", "history$", "map", "getLocation", "withLatestFrom", "offset", "merge", "document$", "distinctUntilKeyChanged", "requestHTML", "catchError", "setLocation", "_", "distinctUntilChanged", "a", "b", "tap", "_a", "_b", "setLocationHash", "debounceTime", "import_escape_html", "setupSearchHighlighter", "config", "regex", "term", "separator", "highlight", "_", "data", "query", "match", "value", "escapeHTML", "isSearchReadyMessage", "message", "isSearchResultMessage", "setupSearchWorker", "url", "index$", "worker$", "watchWorker", "merge", "of", "watchToggle", "first", "active", "switchMap", "config", "docs", "feature", "selectedVersionCorrespondingURL", "params", "_a", "selectedVersionSitemap", "selectedVersionBaseURL", "currentLocation", "currentBaseURL", "current_path", "safeURLParse", "currentRelativePath", "stripPrefix", "sitemapCommonPrefix", "shortestCommonPrefix", "potentialSitemapURL", "result", "url", "base", "e", "s", "prefix", "commonPrefixLen", "s1", "s2", "max", "strs", "setupVersionSelector", "document$", "config", "configuration", "versions$", "requestJSON", "catchError", "EMPTY", "current$", "map", "versions", "current", "version", "aliases", "switchMap", "urls", "fromEvent", "filter", "ev", "withLatestFrom", "el", "url", "of", "selectedVersionBaseURL", "fetchSitemap", "sitemap", "_a", "selectedVersionCorrespondingURL", "getLocation", "setLocation", "combineLatest", "getElement", "renderVersionSelector", "outdated", "ignored", "main", "ignore", "warning", "getComponentElements", "watchSearchQuery", "el", "worker$", "searchParams", "getLocation", "setToggle", "watchToggle", "first", "active", "url", "focus$", "watchElementFocus", "value$", "merge", "isSearchReadyMessage", "fromEvent", "map", "distinctUntilChanged", "combineLatest", "value", "focus", "shareReplay", "mountSearchQuery", "push$", "Subject", "done$", "ignoreElements", "endWith", "_", "query", "distinctUntilKeyChanged", "takeUntil", "label", "getElement", "tap", "state", "finalize", "__spreadValues", "mountSearchResult", "el", "worker$", "query$", "push$", "Subject", "boundary$", "watchElementBoundary", "filter", "container", "meta", "getElement", "list", "watchToggle", "active", "withLatestFrom", "skipUntil", "first", "isSearchReadyMessage", "items", "value", "translation", "count", "round", "render$", "tap", "switchMap", "merge", "of", "bufferCount", "zipWith", "chunk", "map", "renderSearchResultItem", "share", "item", "mergeMap", "details", "getOptionalElement", "EMPTY", "fromEvent", "takeUntil", "isSearchResultMessage", "data", "state", "finalize", "__spreadValues", "watchSearchShare", "_el", "query$", "map", "value", "url", "getLocation", "mountSearchShare", "el", "options", "push$", "Subject", "done$", "ignoreElements", "endWith", "fromEvent", "takeUntil", "ev", "tap", "state", "finalize", "__spreadValues", "mountSearchSuggest", "el", "worker$", "keyboard$", "push$", "Subject", "query", "getComponentElement", "query$", "merge", "fromEvent", "observeOn", "asyncScheduler", "map", "distinctUntilChanged", "combineLatestWith", "suggest", "value", "words", "last", "filter", "mode", "key", "isSearchResultMessage", "data", "tap", "state", "finalize", "mountSearch", "el", "index$", "keyboard$", "config", "configuration", "worker$", "setupSearchWorker", "query", "getComponentElement", "result", "fromEvent", "filter", "target", "setToggle", "mode", "key", "active", "getActiveElement", "anchors", "anchor", "getElements", "article", "best", "a", "b", "els", "i", "query$", "mountSearchQuery", "merge", "mountSearchResult", "mergeWith", "getComponentElements", "child", "mountSearchShare", "mountSearchSuggest", "err", "NEVER", "mountSearchHiglight", "el", "index$", "location$", "combineLatest", "startWith", "getLocation", "filter", "url", "map", "index", "setupSearchHighlighter", "fn", "_a", "nodes", "it", "node", "original", "replaced", "text", "childNodes", "h", "watchSidebar", "el", "viewport$", "main$", "parent", "adjust", "combineLatest", "map", "offset", "height", "y", "distinctUntilChanged", "a", "b", "mountSidebar", "_a", "_b", "header$", "options", "__objRest", "inner", "getElement", "getElementOffset", "defer", "push$", "Subject", "done$", "ignoreElements", "endWith", "next$", "auditTime", "animationFrameScheduler", "withLatestFrom", "first", "item", "getElements", "container", "getElementSize", "from", "mergeMap", "label", "fromEvent", "observeOn", "asyncScheduler", "takeUntil", "input", "tap", "state", "finalize", "__spreadValues", "fetchSourceFactsFromGitHub", "user", "repo", "url", "zip", "requestJSON", "catchError", "EMPTY", "map", "release", "defaultIfEmpty", "info", "__spreadValues", "fetchSourceFactsFromGitLab", "base", "project", "url", "zip", "requestJSON", "catchError", "EMPTY", "map", "tag_name", "defaultIfEmpty", "star_count", "forks_count", "release", "info", "__spreadValues", "fetchSourceFacts", "url", "match", "user", "repo", "fetchSourceFactsFromGitHub", "base", "slug", "fetchSourceFactsFromGitLab", "EMPTY", "fetch$", "watchSource", "el", "defer", "cached", "of", "getComponentElements", "consent", "EMPTY", "fetchSourceFacts", "tap", "facts", "catchError", "filter", "map", "shareReplay", "mountSource", "inner", "getElement", "push$", "Subject", "renderSourceFacts", "state", "finalize", "__spreadValues", "watchTabs", "el", "viewport$", "header$", "watchElementSize", "switchMap", "watchViewportAt", "map", "y", "distinctUntilKeyChanged", "mountTabs", "options", "defer", "push$", "Subject", "hidden", "feature", "of", "tap", "state", "finalize", "__spreadValues", "watchTableOfContents", "el", "viewport$", "header$", "table", "anchors", "getElements", "anchor", "id", "target", "getOptionalElement", "adjust$", "distinctUntilKeyChanged", "map", "height", "main", "getComponentElement", "grid", "getElement", "share", "watchElementSize", "switchMap", "body", "defer", "path", "of", "index", "offset", "parent", "a", "b", "combineLatestWith", "adjust", "scan", "prev", "next", "y", "size", "last", "distinctUntilChanged", "startWith", "bufferCount", "mountTableOfContents", "main$", "target$", "push$", "Subject", "done$", "ignoreElements", "endWith", "feature", "smooth$", "merge", "debounceTime", "filter", "observeOn", "asyncScheduler", "withLatestFrom", "behavior", "container", "getElementContainer", "getElementSize", "takeUntil", "skip", "repeat", "url", "getLocation", "active", "hash", "tap", "state", "finalize", "__spreadValues", "watchBackToTop", "_el", "viewport$", "main$", "target$", "direction$", "map", "y", "bufferCount", "b", "distinctUntilChanged", "active$", "active", "combineLatest", "direction", "takeUntil", "skip", "endWith", "repeat", "hidden", "mountBackToTop", "el", "header$", "push$", "Subject", "done$", "ignoreElements", "distinctUntilKeyChanged", "height", "fromEvent", "ev", "tap", "state", "finalize", "__spreadValues", "patchEllipsis", "document$", "viewport$", "switchMap", "getElements", "mergeMap", "el", "watchElementVisibility", "takeUntil", "skip", "filter", "visible", "map", "take", "text", "host", "feature", "mountInlineTooltip2", "finalize", "EMPTY", "patchIndeterminate", "document$", "tablet$", "switchMap", "getElements", "tap", "el", "mergeMap", "fromEvent", "takeWhile", "map", "withLatestFrom", "tablet", "isAppleDevice", "patchScrollfix", "document$", "switchMap", "getElements", "tap", "el", "filter", "mergeMap", "fromEvent", "map", "top", "patchScrolllock", "viewport$", "tablet$", "combineLatest", "watchToggle", "map", "active", "tablet", "switchMap", "of", "delay", "withLatestFrom", "y", "value", "obj", "data", "key", "x", "y", "nodes", "parent", "i", "node", "fetchSearchIndex", "watchScript", "config", "map", "shareReplay", "requestJSON", "document$", "watchDocument", "location$", "watchLocation", "target$", "watchLocationTarget", "keyboard$", "watchKeyboard", "viewport$", "watchViewport", "tablet$", "watchMedia", "screen$", "print$", "watchPrint", "configuration", "index$", "NEVER", "alert$", "Subject", "setupClipboardJS", "progress$", "feature", "setupInstantNavigation", "_a", "setupVersionSelector", "merge", "delay", "setToggle", "filter", "mode", "key", "prev", "getOptionalElement", "setLocation", "next", "active", "getActiveElement", "patchEllipsis", "patchIndeterminate", "patchScrollfix", "patchScrolllock", "header$", "watchHeader", "getComponentElement", "main$", "switchMap", "el", "watchMain", "control$", "getComponentElements", "mountConsent", "mountDialog", "mountHeader", "mountPalette", "mountProgress", "mountSearch", "mountSource", "content$", "defer", "mountAnnounce", "mountContent", "mountSearchHiglight", "EMPTY", "mountHeaderTitle", "at", "mountSidebar", "mountTabs", "mountTableOfContents", "mountBackToTop", "component$", "mergeWith"]
+  "sourcesContent": ["(function (global, factory) {\n  typeof exports === 'object' && typeof module !== 'undefined' ? factory() :\n  typeof define === 'function' && define.amd ? define(factory) :\n  (factory());\n}(this, (function () { 'use strict';\n\n  /**\n   * Applies the :focus-visible polyfill at the given scope.\n   * A scope in this case is either the top-level Document or a Shadow Root.\n   *\n   * @param {(Document|ShadowRoot)} scope\n   * @see https://github.com/WICG/focus-visible\n   */\n  function applyFocusVisiblePolyfill(scope) {\n    var hadKeyboardEvent = true;\n    var hadFocusVisibleRecently = false;\n    var hadFocusVisibleRecentlyTimeout = null;\n\n    var inputTypesAllowlist = {\n      text: true,\n      search: true,\n      url: true,\n      tel: true,\n      email: true,\n      password: true,\n      number: true,\n      date: true,\n      month: true,\n      week: true,\n      time: true,\n      datetime: true,\n      'datetime-local': true\n    };\n\n    /**\n     * Helper function for legacy browsers and iframes which sometimes focus\n     * elements like document, body, and non-interactive SVG.\n     * @param {Element} el\n     */\n    function isValidFocusTarget(el) {\n      if (\n        el &&\n        el !== document &&\n        el.nodeName !== 'HTML' &&\n        el.nodeName !== 'BODY' &&\n        'classList' in el &&\n        'contains' in el.classList\n      ) {\n        return true;\n      }\n      return false;\n    }\n\n    /**\n     * Computes whether the given element should automatically trigger the\n     * `focus-visible` class being added, i.e. whether it should always match\n     * `:focus-visible` when focused.\n     * @param {Element} el\n     * @return {boolean}\n     */\n    function focusTriggersKeyboardModality(el) {\n      var type = el.type;\n      var tagName = el.tagName;\n\n      if (tagName === 'INPUT' && inputTypesAllowlist[type] && !el.readOnly) {\n        return true;\n      }\n\n      if (tagName === 'TEXTAREA' && !el.readOnly) {\n        return true;\n      }\n\n      if (el.isContentEditable) {\n        return true;\n      }\n\n      return false;\n    }\n\n    /**\n     * Add the `focus-visible` class to the given element if it was not added by\n     * the author.\n     * @param {Element} el\n     */\n    function addFocusVisibleClass(el) {\n      if (el.classList.contains('focus-visible')) {\n        return;\n      }\n      el.classList.add('focus-visible');\n      el.setAttribute('data-focus-visible-added', '');\n    }\n\n    /**\n     * Remove the `focus-visible` class from the given element if it was not\n     * originally added by the author.\n     * @param {Element} el\n     */\n    function removeFocusVisibleClass(el) {\n      if (!el.hasAttribute('data-focus-visible-added')) {\n        return;\n      }\n      el.classList.remove('focus-visible');\n      el.removeAttribute('data-focus-visible-added');\n    }\n\n    /**\n     * If the most recent user interaction was via the keyboard;\n     * and the key press did not include a meta, alt/option, or control key;\n     * then the modality is keyboard. Otherwise, the modality is not keyboard.\n     * Apply `focus-visible` to any current active element and keep track\n     * of our keyboard modality state with `hadKeyboardEvent`.\n     * @param {KeyboardEvent} e\n     */\n    function onKeyDown(e) {\n      if (e.metaKey || e.altKey || e.ctrlKey) {\n        return;\n      }\n\n      if (isValidFocusTarget(scope.activeElement)) {\n        addFocusVisibleClass(scope.activeElement);\n      }\n\n      hadKeyboardEvent = true;\n    }\n\n    /**\n     * If at any point a user clicks with a pointing device, ensure that we change\n     * the modality away from keyboard.\n     * This avoids the situation where a user presses a key on an already focused\n     * element, and then clicks on a different element, focusing it with a\n     * pointing device, while we still think we're in keyboard modality.\n     * @param {Event} e\n     */\n    function onPointerDown(e) {\n      hadKeyboardEvent = false;\n    }\n\n    /**\n     * On `focus`, add the `focus-visible` class to the target if:\n     * - the target received focus as a result of keyboard navigation, or\n     * - the event target is an element that will likely require interaction\n     *   via the keyboard (e.g. a text box)\n     * @param {Event} e\n     */\n    function onFocus(e) {\n      // Prevent IE from focusing the document or HTML element.\n      if (!isValidFocusTarget(e.target)) {\n        return;\n      }\n\n      if (hadKeyboardEvent || focusTriggersKeyboardModality(e.target)) {\n        addFocusVisibleClass(e.target);\n      }\n    }\n\n    /**\n     * On `blur`, remove the `focus-visible` class from the target.\n     * @param {Event} e\n     */\n    function onBlur(e) {\n      if (!isValidFocusTarget(e.target)) {\n        return;\n      }\n\n      if (\n        e.target.classList.contains('focus-visible') ||\n        e.target.hasAttribute('data-focus-visible-added')\n      ) {\n        // To detect a tab/window switch, we look for a blur event followed\n        // rapidly by a visibility change.\n        // If we don't see a visibility change within 100ms, it's probably a\n        // regular focus change.\n        hadFocusVisibleRecently = true;\n        window.clearTimeout(hadFocusVisibleRecentlyTimeout);\n        hadFocusVisibleRecentlyTimeout = window.setTimeout(function() {\n          hadFocusVisibleRecently = false;\n        }, 100);\n        removeFocusVisibleClass(e.target);\n      }\n    }\n\n    /**\n     * If the user changes tabs, keep track of whether or not the previously\n     * focused element had .focus-visible.\n     * @param {Event} e\n     */\n    function onVisibilityChange(e) {\n      if (document.visibilityState === 'hidden') {\n        // If the tab becomes active again, the browser will handle calling focus\n        // on the element (Safari actually calls it twice).\n        // If this tab change caused a blur on an element with focus-visible,\n        // re-apply the class when the user switches back to the tab.\n        if (hadFocusVisibleRecently) {\n          hadKeyboardEvent = true;\n        }\n        addInitialPointerMoveListeners();\n      }\n    }\n\n    /**\n     * Add a group of listeners to detect usage of any pointing devices.\n     * These listeners will be added when the polyfill first loads, and anytime\n     * the window is blurred, so that they are active when the window regains\n     * focus.\n     */\n    function addInitialPointerMoveListeners() {\n      document.addEventListener('mousemove', onInitialPointerMove);\n      document.addEventListener('mousedown', onInitialPointerMove);\n      document.addEventListener('mouseup', onInitialPointerMove);\n      document.addEventListener('pointermove', onInitialPointerMove);\n      document.addEventListener('pointerdown', onInitialPointerMove);\n      document.addEventListener('pointerup', onInitialPointerMove);\n      document.addEventListener('touchmove', onInitialPointerMove);\n      document.addEventListener('touchstart', onInitialPointerMove);\n      document.addEventListener('touchend', onInitialPointerMove);\n    }\n\n    function removeInitialPointerMoveListeners() {\n      document.removeEventListener('mousemove', onInitialPointerMove);\n      document.removeEventListener('mousedown', onInitialPointerMove);\n      document.removeEventListener('mouseup', onInitialPointerMove);\n      document.removeEventListener('pointermove', onInitialPointerMove);\n      document.removeEventListener('pointerdown', onInitialPointerMove);\n      document.removeEventListener('pointerup', onInitialPointerMove);\n      document.removeEventListener('touchmove', onInitialPointerMove);\n      document.removeEventListener('touchstart', onInitialPointerMove);\n      document.removeEventListener('touchend', onInitialPointerMove);\n    }\n\n    /**\n     * When the polfyill first loads, assume the user is in keyboard modality.\n     * If any event is received from a pointing device (e.g. mouse, pointer,\n     * touch), turn off keyboard modality.\n     * This accounts for situations where focus enters the page from the URL bar.\n     * @param {Event} e\n     */\n    function onInitialPointerMove(e) {\n      // Work around a Safari quirk that fires a mousemove on <html> whenever the\n      // window blurs, even if you're tabbing out of the page. \u00AF\\_(\u30C4)_/\u00AF\n      if (e.target.nodeName && e.target.nodeName.toLowerCase() === 'html') {\n        return;\n      }\n\n      hadKeyboardEvent = false;\n      removeInitialPointerMoveListeners();\n    }\n\n    // For some kinds of state, we are interested in changes at the global scope\n    // only. For example, global pointer input, global key presses and global\n    // visibility change should affect the state at every scope:\n    document.addEventListener('keydown', onKeyDown, true);\n    document.addEventListener('mousedown', onPointerDown, true);\n    document.addEventListener('pointerdown', onPointerDown, true);\n    document.addEventListener('touchstart', onPointerDown, true);\n    document.addEventListener('visibilitychange', onVisibilityChange, true);\n\n    addInitialPointerMoveListeners();\n\n    // For focus and blur, we specifically care about state changes in the local\n    // scope. This is because focus / blur events that originate from within a\n    // shadow root are not re-dispatched from the host element if it was already\n    // the active element in its own scope:\n    scope.addEventListener('focus', onFocus, true);\n    scope.addEventListener('blur', onBlur, true);\n\n    // We detect that a node is a ShadowRoot by ensuring that it is a\n    // DocumentFragment and also has a host property. This check covers native\n    // implementation and polyfill implementation transparently. If we only cared\n    // about the native implementation, we could just check if the scope was\n    // an instance of a ShadowRoot.\n    if (scope.nodeType === Node.DOCUMENT_FRAGMENT_NODE && scope.host) {\n      // Since a ShadowRoot is a special kind of DocumentFragment, it does not\n      // have a root element to add a class to. So, we add this attribute to the\n      // host element instead:\n      scope.host.setAttribute('data-js-focus-visible', '');\n    } else if (scope.nodeType === Node.DOCUMENT_NODE) {\n      document.documentElement.classList.add('js-focus-visible');\n      document.documentElement.setAttribute('data-js-focus-visible', '');\n    }\n  }\n\n  // It is important to wrap all references to global window and document in\n  // these checks to support server-side rendering use cases\n  // @see https://github.com/WICG/focus-visible/issues/199\n  if (typeof window !== 'undefined' && typeof document !== 'undefined') {\n    // Make the polyfill helper globally available. This can be used as a signal\n    // to interested libraries that wish to coordinate with the polyfill for e.g.,\n    // applying the polyfill to a shadow root:\n    window.applyFocusVisiblePolyfill = applyFocusVisiblePolyfill;\n\n    // Notify interested libraries of the polyfill's presence, in case the\n    // polyfill was loaded lazily:\n    var event;\n\n    try {\n      event = new CustomEvent('focus-visible-polyfill-ready');\n    } catch (error) {\n      // IE11 does not support using CustomEvent as a constructor directly:\n      event = document.createEvent('CustomEvent');\n      event.initCustomEvent('focus-visible-polyfill-ready', false, false, {});\n    }\n\n    window.dispatchEvent(event);\n  }\n\n  if (typeof document !== 'undefined') {\n    // Apply the polyfill to the global document, so that no JavaScript\n    // coordination is required to use the polyfill in the top-level document:\n    applyFocusVisiblePolyfill(document);\n  }\n\n})));\n", "/*!\n * escape-html\n * Copyright(c) 2012-2013 TJ Holowaychuk\n * Copyright(c) 2015 Andreas Lubbe\n * Copyright(c) 2015 Tiancheng \"Timothy\" Gu\n * MIT Licensed\n */\n\n'use strict';\n\n/**\n * Module variables.\n * @private\n */\n\nvar matchHtmlRegExp = /[\"'&<>]/;\n\n/**\n * Module exports.\n * @public\n */\n\nmodule.exports = escapeHtml;\n\n/**\n * Escape special characters in the given string of html.\n *\n * @param  {string} string The string to escape for inserting into HTML\n * @return {string}\n * @public\n */\n\nfunction escapeHtml(string) {\n  var str = '' + string;\n  var match = matchHtmlRegExp.exec(str);\n\n  if (!match) {\n    return str;\n  }\n\n  var escape;\n  var html = '';\n  var index = 0;\n  var lastIndex = 0;\n\n  for (index = match.index; index < str.length; index++) {\n    switch (str.charCodeAt(index)) {\n      case 34: // \"\n        escape = '&quot;';\n        break;\n      case 38: // &\n        escape = '&amp;';\n        break;\n      case 39: // '\n        escape = '&#39;';\n        break;\n      case 60: // <\n        escape = '&lt;';\n        break;\n      case 62: // >\n        escape = '&gt;';\n        break;\n      default:\n        continue;\n    }\n\n    if (lastIndex !== index) {\n      html += str.substring(lastIndex, index);\n    }\n\n    lastIndex = index + 1;\n    html += escape;\n  }\n\n  return lastIndex !== index\n    ? html + str.substring(lastIndex, index)\n    : html;\n}\n", "/*!\n * clipboard.js v2.0.11\n * https://clipboardjs.com/\n *\n * Licensed MIT \u00A9 Zeno Rocha\n */\n(function webpackUniversalModuleDefinition(root, factory) {\n\tif(typeof exports === 'object' && typeof module === 'object')\n\t\tmodule.exports = factory();\n\telse if(typeof define === 'function' && define.amd)\n\t\tdefine([], factory);\n\telse if(typeof exports === 'object')\n\t\texports[\"ClipboardJS\"] = factory();\n\telse\n\t\troot[\"ClipboardJS\"] = factory();\n})(this, function() {\nreturn /******/ (function() { // webpackBootstrap\n/******/ \tvar __webpack_modules__ = ({\n\n/***/ 686:\n/***/ (function(__unused_webpack_module, __webpack_exports__, __webpack_require__) {\n\n\"use strict\";\n\n// EXPORTS\n__webpack_require__.d(__webpack_exports__, {\n  \"default\": function() { return /* binding */ clipboard; }\n});\n\n// EXTERNAL MODULE: ./node_modules/tiny-emitter/index.js\nvar tiny_emitter = __webpack_require__(279);\nvar tiny_emitter_default = /*#__PURE__*/__webpack_require__.n(tiny_emitter);\n// EXTERNAL MODULE: ./node_modules/good-listener/src/listen.js\nvar listen = __webpack_require__(370);\nvar listen_default = /*#__PURE__*/__webpack_require__.n(listen);\n// EXTERNAL MODULE: ./node_modules/select/src/select.js\nvar src_select = __webpack_require__(817);\nvar select_default = /*#__PURE__*/__webpack_require__.n(src_select);\n;// CONCATENATED MODULE: ./src/common/command.js\n/**\n * Executes a given operation type.\n * @param {String} type\n * @return {Boolean}\n */\nfunction command(type) {\n  try {\n    return document.execCommand(type);\n  } catch (err) {\n    return false;\n  }\n}\n;// CONCATENATED MODULE: ./src/actions/cut.js\n\n\n/**\n * Cut action wrapper.\n * @param {String|HTMLElement} target\n * @return {String}\n */\n\nvar ClipboardActionCut = function ClipboardActionCut(target) {\n  var selectedText = select_default()(target);\n  command('cut');\n  return selectedText;\n};\n\n/* harmony default export */ var actions_cut = (ClipboardActionCut);\n;// CONCATENATED MODULE: ./src/common/create-fake-element.js\n/**\n * Creates a fake textarea element with a value.\n * @param {String} value\n * @return {HTMLElement}\n */\nfunction createFakeElement(value) {\n  var isRTL = document.documentElement.getAttribute('dir') === 'rtl';\n  var fakeElement = document.createElement('textarea'); // Prevent zooming on iOS\n\n  fakeElement.style.fontSize = '12pt'; // Reset box model\n\n  fakeElement.style.border = '0';\n  fakeElement.style.padding = '0';\n  fakeElement.style.margin = '0'; // Move element out of screen horizontally\n\n  fakeElement.style.position = 'absolute';\n  fakeElement.style[isRTL ? 'right' : 'left'] = '-9999px'; // Move element to the same position vertically\n\n  var yPosition = window.pageYOffset || document.documentElement.scrollTop;\n  fakeElement.style.top = \"\".concat(yPosition, \"px\");\n  fakeElement.setAttribute('readonly', '');\n  fakeElement.value = value;\n  return fakeElement;\n}\n;// CONCATENATED MODULE: ./src/actions/copy.js\n\n\n\n/**\n * Create fake copy action wrapper using a fake element.\n * @param {String} target\n * @param {Object} options\n * @return {String}\n */\n\nvar fakeCopyAction = function fakeCopyAction(value, options) {\n  var fakeElement = createFakeElement(value);\n  options.container.appendChild(fakeElement);\n  var selectedText = select_default()(fakeElement);\n  command('copy');\n  fakeElement.remove();\n  return selectedText;\n};\n/**\n * Copy action wrapper.\n * @param {String|HTMLElement} target\n * @param {Object} options\n * @return {String}\n */\n\n\nvar ClipboardActionCopy = function ClipboardActionCopy(target) {\n  var options = arguments.length > 1 && arguments[1] !== undefined ? arguments[1] : {\n    container: document.body\n  };\n  var selectedText = '';\n\n  if (typeof target === 'string') {\n    selectedText = fakeCopyAction(target, options);\n  } else if (target instanceof HTMLInputElement && !['text', 'search', 'url', 'tel', 'password'].includes(target === null || target === void 0 ? void 0 : target.type)) {\n    // If input type doesn't support `setSelectionRange`. Simulate it. https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/setSelectionRange\n    selectedText = fakeCopyAction(target.value, options);\n  } else {\n    selectedText = select_default()(target);\n    command('copy');\n  }\n\n  return selectedText;\n};\n\n/* harmony default export */ var actions_copy = (ClipboardActionCopy);\n;// CONCATENATED MODULE: ./src/actions/default.js\nfunction _typeof(obj) { \"@babel/helpers - typeof\"; if (typeof Symbol === \"function\" && typeof Symbol.iterator === \"symbol\") { _typeof = function _typeof(obj) { return typeof obj; }; } else { _typeof = function _typeof(obj) { return obj && typeof Symbol === \"function\" && obj.constructor === Symbol && obj !== Symbol.prototype ? \"symbol\" : typeof obj; }; } return _typeof(obj); }\n\n\n\n/**\n * Inner function which performs selection from either `text` or `target`\n * properties and then executes copy or cut operations.\n * @param {Object} options\n */\n\nvar ClipboardActionDefault = function ClipboardActionDefault() {\n  var options = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : {};\n  // Defines base properties passed from constructor.\n  var _options$action = options.action,\n      action = _options$action === void 0 ? 'copy' : _options$action,\n      container = options.container,\n      target = options.target,\n      text = options.text; // Sets the `action` to be performed which can be either 'copy' or 'cut'.\n\n  if (action !== 'copy' && action !== 'cut') {\n    throw new Error('Invalid \"action\" value, use either \"copy\" or \"cut\"');\n  } // Sets the `target` property using an element that will be have its content copied.\n\n\n  if (target !== undefined) {\n    if (target && _typeof(target) === 'object' && target.nodeType === 1) {\n      if (action === 'copy' && target.hasAttribute('disabled')) {\n        throw new Error('Invalid \"target\" attribute. Please use \"readonly\" instead of \"disabled\" attribute');\n      }\n\n      if (action === 'cut' && (target.hasAttribute('readonly') || target.hasAttribute('disabled'))) {\n        throw new Error('Invalid \"target\" attribute. You can\\'t cut text from elements with \"readonly\" or \"disabled\" attributes');\n      }\n    } else {\n      throw new Error('Invalid \"target\" value, use a valid Element');\n    }\n  } // Define selection strategy based on `text` property.\n\n\n  if (text) {\n    return actions_copy(text, {\n      container: container\n    });\n  } // Defines which selection strategy based on `target` property.\n\n\n  if (target) {\n    return action === 'cut' ? actions_cut(target) : actions_copy(target, {\n      container: container\n    });\n  }\n};\n\n/* harmony default export */ var actions_default = (ClipboardActionDefault);\n;// CONCATENATED MODULE: ./src/clipboard.js\nfunction clipboard_typeof(obj) { \"@babel/helpers - typeof\"; if (typeof Symbol === \"function\" && typeof Symbol.iterator === \"symbol\") { clipboard_typeof = function _typeof(obj) { return typeof obj; }; } else { clipboard_typeof = function _typeof(obj) { return obj && typeof Symbol === \"function\" && obj.constructor === Symbol && obj !== Symbol.prototype ? \"symbol\" : typeof obj; }; } return clipboard_typeof(obj); }\n\nfunction _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError(\"Cannot call a class as a function\"); } }\n\nfunction _defineProperties(target, props) { for (var i = 0; i < props.length; i++) { var descriptor = props[i]; descriptor.enumerable = descriptor.enumerable || false; descriptor.configurable = true; if (\"value\" in descriptor) descriptor.writable = true; Object.defineProperty(target, descriptor.key, descriptor); } }\n\nfunction _createClass(Constructor, protoProps, staticProps) { if (protoProps) _defineProperties(Constructor.prototype, protoProps); if (staticProps) _defineProperties(Constructor, staticProps); return Constructor; }\n\nfunction _inherits(subClass, superClass) { if (typeof superClass !== \"function\" && superClass !== null) { throw new TypeError(\"Super expression must either be null or a function\"); } subClass.prototype = Object.create(superClass && superClass.prototype, { constructor: { value: subClass, writable: true, configurable: true } }); if (superClass) _setPrototypeOf(subClass, superClass); }\n\nfunction _setPrototypeOf(o, p) { _setPrototypeOf = Object.setPrototypeOf || function _setPrototypeOf(o, p) { o.__proto__ = p; return o; }; return _setPrototypeOf(o, p); }\n\nfunction _createSuper(Derived) { var hasNativeReflectConstruct = _isNativeReflectConstruct(); return function _createSuperInternal() { var Super = _getPrototypeOf(Derived), result; if (hasNativeReflectConstruct) { var NewTarget = _getPrototypeOf(this).constructor; result = Reflect.construct(Super, arguments, NewTarget); } else { result = Super.apply(this, arguments); } return _possibleConstructorReturn(this, result); }; }\n\nfunction _possibleConstructorReturn(self, call) { if (call && (clipboard_typeof(call) === \"object\" || typeof call === \"function\")) { return call; } return _assertThisInitialized(self); }\n\nfunction _assertThisInitialized(self) { if (self === void 0) { throw new ReferenceError(\"this hasn't been initialised - super() hasn't been called\"); } return self; }\n\nfunction _isNativeReflectConstruct() { if (typeof Reflect === \"undefined\" || !Reflect.construct) return false; if (Reflect.construct.sham) return false; if (typeof Proxy === \"function\") return true; try { Date.prototype.toString.call(Reflect.construct(Date, [], function () {})); return true; } catch (e) { return false; } }\n\nfunction _getPrototypeOf(o) { _getPrototypeOf = Object.setPrototypeOf ? Object.getPrototypeOf : function _getPrototypeOf(o) { return o.__proto__ || Object.getPrototypeOf(o); }; return _getPrototypeOf(o); }\n\n\n\n\n\n\n/**\n * Helper function to retrieve attribute value.\n * @param {String} suffix\n * @param {Element} element\n */\n\nfunction getAttributeValue(suffix, element) {\n  var attribute = \"data-clipboard-\".concat(suffix);\n\n  if (!element.hasAttribute(attribute)) {\n    return;\n  }\n\n  return element.getAttribute(attribute);\n}\n/**\n * Base class which takes one or more elements, adds event listeners to them,\n * and instantiates a new `ClipboardAction` on each click.\n */\n\n\nvar Clipboard = /*#__PURE__*/function (_Emitter) {\n  _inherits(Clipboard, _Emitter);\n\n  var _super = _createSuper(Clipboard);\n\n  /**\n   * @param {String|HTMLElement|HTMLCollection|NodeList} trigger\n   * @param {Object} options\n   */\n  function Clipboard(trigger, options) {\n    var _this;\n\n    _classCallCheck(this, Clipboard);\n\n    _this = _super.call(this);\n\n    _this.resolveOptions(options);\n\n    _this.listenClick(trigger);\n\n    return _this;\n  }\n  /**\n   * Defines if attributes would be resolved using internal setter functions\n   * or custom functions that were passed in the constructor.\n   * @param {Object} options\n   */\n\n\n  _createClass(Clipboard, [{\n    key: \"resolveOptions\",\n    value: function resolveOptions() {\n      var options = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : {};\n      this.action = typeof options.action === 'function' ? options.action : this.defaultAction;\n      this.target = typeof options.target === 'function' ? options.target : this.defaultTarget;\n      this.text = typeof options.text === 'function' ? options.text : this.defaultText;\n      this.container = clipboard_typeof(options.container) === 'object' ? options.container : document.body;\n    }\n    /**\n     * Adds a click event listener to the passed trigger.\n     * @param {String|HTMLElement|HTMLCollection|NodeList} trigger\n     */\n\n  }, {\n    key: \"listenClick\",\n    value: function listenClick(trigger) {\n      var _this2 = this;\n\n      this.listener = listen_default()(trigger, 'click', function (e) {\n        return _this2.onClick(e);\n      });\n    }\n    /**\n     * Defines a new `ClipboardAction` on each click event.\n     * @param {Event} e\n     */\n\n  }, {\n    key: \"onClick\",\n    value: function onClick(e) {\n      var trigger = e.delegateTarget || e.currentTarget;\n      var action = this.action(trigger) || 'copy';\n      var text = actions_default({\n        action: action,\n        container: this.container,\n        target: this.target(trigger),\n        text: this.text(trigger)\n      }); // Fires an event based on the copy operation result.\n\n      this.emit(text ? 'success' : 'error', {\n        action: action,\n        text: text,\n        trigger: trigger,\n        clearSelection: function clearSelection() {\n          if (trigger) {\n            trigger.focus();\n          }\n\n          window.getSelection().removeAllRanges();\n        }\n      });\n    }\n    /**\n     * Default `action` lookup function.\n     * @param {Element} trigger\n     */\n\n  }, {\n    key: \"defaultAction\",\n    value: function defaultAction(trigger) {\n      return getAttributeValue('action', trigger);\n    }\n    /**\n     * Default `target` lookup function.\n     * @param {Element} trigger\n     */\n\n  }, {\n    key: \"defaultTarget\",\n    value: function defaultTarget(trigger) {\n      var selector = getAttributeValue('target', trigger);\n\n      if (selector) {\n        return document.querySelector(selector);\n      }\n    }\n    /**\n     * Allow fire programmatically a copy action\n     * @param {String|HTMLElement} target\n     * @param {Object} options\n     * @returns Text copied.\n     */\n\n  }, {\n    key: \"defaultText\",\n\n    /**\n     * Default `text` lookup function.\n     * @param {Element} trigger\n     */\n    value: function defaultText(trigger) {\n      return getAttributeValue('text', trigger);\n    }\n    /**\n     * Destroy lifecycle.\n     */\n\n  }, {\n    key: \"destroy\",\n    value: function destroy() {\n      this.listener.destroy();\n    }\n  }], [{\n    key: \"copy\",\n    value: function copy(target) {\n      var options = arguments.length > 1 && arguments[1] !== undefined ? arguments[1] : {\n        container: document.body\n      };\n      return actions_copy(target, options);\n    }\n    /**\n     * Allow fire programmatically a cut action\n     * @param {String|HTMLElement} target\n     * @returns Text cutted.\n     */\n\n  }, {\n    key: \"cut\",\n    value: function cut(target) {\n      return actions_cut(target);\n    }\n    /**\n     * Returns the support of the given action, or all actions if no action is\n     * given.\n     * @param {String} [action]\n     */\n\n  }, {\n    key: \"isSupported\",\n    value: function isSupported() {\n      var action = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : ['copy', 'cut'];\n      var actions = typeof action === 'string' ? [action] : action;\n      var support = !!document.queryCommandSupported;\n      actions.forEach(function (action) {\n        support = support && !!document.queryCommandSupported(action);\n      });\n      return support;\n    }\n  }]);\n\n  return Clipboard;\n}((tiny_emitter_default()));\n\n/* harmony default export */ var clipboard = (Clipboard);\n\n/***/ }),\n\n/***/ 828:\n/***/ (function(module) {\n\nvar DOCUMENT_NODE_TYPE = 9;\n\n/**\n * A polyfill for Element.matches()\n */\nif (typeof Element !== 'undefined' && !Element.prototype.matches) {\n    var proto = Element.prototype;\n\n    proto.matches = proto.matchesSelector ||\n                    proto.mozMatchesSelector ||\n                    proto.msMatchesSelector ||\n                    proto.oMatchesSelector ||\n                    proto.webkitMatchesSelector;\n}\n\n/**\n * Finds the closest parent that matches a selector.\n *\n * @param {Element} element\n * @param {String} selector\n * @return {Function}\n */\nfunction closest (element, selector) {\n    while (element && element.nodeType !== DOCUMENT_NODE_TYPE) {\n        if (typeof element.matches === 'function' &&\n            element.matches(selector)) {\n          return element;\n        }\n        element = element.parentNode;\n    }\n}\n\nmodule.exports = closest;\n\n\n/***/ }),\n\n/***/ 438:\n/***/ (function(module, __unused_webpack_exports, __webpack_require__) {\n\nvar closest = __webpack_require__(828);\n\n/**\n * Delegates event to a selector.\n *\n * @param {Element} element\n * @param {String} selector\n * @param {String} type\n * @param {Function} callback\n * @param {Boolean} useCapture\n * @return {Object}\n */\nfunction _delegate(element, selector, type, callback, useCapture) {\n    var listenerFn = listener.apply(this, arguments);\n\n    element.addEventListener(type, listenerFn, useCapture);\n\n    return {\n        destroy: function() {\n            element.removeEventListener(type, listenerFn, useCapture);\n        }\n    }\n}\n\n/**\n * Delegates event to a selector.\n *\n * @param {Element|String|Array} [elements]\n * @param {String} selector\n * @param {String} type\n * @param {Function} callback\n * @param {Boolean} useCapture\n * @return {Object}\n */\nfunction delegate(elements, selector, type, callback, useCapture) {\n    // Handle the regular Element usage\n    if (typeof elements.addEventListener === 'function') {\n        return _delegate.apply(null, arguments);\n    }\n\n    // Handle Element-less usage, it defaults to global delegation\n    if (typeof type === 'function') {\n        // Use `document` as the first parameter, then apply arguments\n        // This is a short way to .unshift `arguments` without running into deoptimizations\n        return _delegate.bind(null, document).apply(null, arguments);\n    }\n\n    // Handle Selector-based usage\n    if (typeof elements === 'string') {\n        elements = document.querySelectorAll(elements);\n    }\n\n    // Handle Array-like based usage\n    return Array.prototype.map.call(elements, function (element) {\n        return _delegate(element, selector, type, callback, useCapture);\n    });\n}\n\n/**\n * Finds closest match and invokes callback.\n *\n * @param {Element} element\n * @param {String} selector\n * @param {String} type\n * @param {Function} callback\n * @return {Function}\n */\nfunction listener(element, selector, type, callback) {\n    return function(e) {\n        e.delegateTarget = closest(e.target, selector);\n\n        if (e.delegateTarget) {\n            callback.call(element, e);\n        }\n    }\n}\n\nmodule.exports = delegate;\n\n\n/***/ }),\n\n/***/ 879:\n/***/ (function(__unused_webpack_module, exports) {\n\n/**\n * Check if argument is a HTML element.\n *\n * @param {Object} value\n * @return {Boolean}\n */\nexports.node = function(value) {\n    return value !== undefined\n        && value instanceof HTMLElement\n        && value.nodeType === 1;\n};\n\n/**\n * Check if argument is a list of HTML elements.\n *\n * @param {Object} value\n * @return {Boolean}\n */\nexports.nodeList = function(value) {\n    var type = Object.prototype.toString.call(value);\n\n    return value !== undefined\n        && (type === '[object NodeList]' || type === '[object HTMLCollection]')\n        && ('length' in value)\n        && (value.length === 0 || exports.node(value[0]));\n};\n\n/**\n * Check if argument is a string.\n *\n * @param {Object} value\n * @return {Boolean}\n */\nexports.string = function(value) {\n    return typeof value === 'string'\n        || value instanceof String;\n};\n\n/**\n * Check if argument is a function.\n *\n * @param {Object} value\n * @return {Boolean}\n */\nexports.fn = function(value) {\n    var type = Object.prototype.toString.call(value);\n\n    return type === '[object Function]';\n};\n\n\n/***/ }),\n\n/***/ 370:\n/***/ (function(module, __unused_webpack_exports, __webpack_require__) {\n\nvar is = __webpack_require__(879);\nvar delegate = __webpack_require__(438);\n\n/**\n * Validates all params and calls the right\n * listener function based on its target type.\n *\n * @param {String|HTMLElement|HTMLCollection|NodeList} target\n * @param {String} type\n * @param {Function} callback\n * @return {Object}\n */\nfunction listen(target, type, callback) {\n    if (!target && !type && !callback) {\n        throw new Error('Missing required arguments');\n    }\n\n    if (!is.string(type)) {\n        throw new TypeError('Second argument must be a String');\n    }\n\n    if (!is.fn(callback)) {\n        throw new TypeError('Third argument must be a Function');\n    }\n\n    if (is.node(target)) {\n        return listenNode(target, type, callback);\n    }\n    else if (is.nodeList(target)) {\n        return listenNodeList(target, type, callback);\n    }\n    else if (is.string(target)) {\n        return listenSelector(target, type, callback);\n    }\n    else {\n        throw new TypeError('First argument must be a String, HTMLElement, HTMLCollection, or NodeList');\n    }\n}\n\n/**\n * Adds an event listener to a HTML element\n * and returns a remove listener function.\n *\n * @param {HTMLElement} node\n * @param {String} type\n * @param {Function} callback\n * @return {Object}\n */\nfunction listenNode(node, type, callback) {\n    node.addEventListener(type, callback);\n\n    return {\n        destroy: function() {\n            node.removeEventListener(type, callback);\n        }\n    }\n}\n\n/**\n * Add an event listener to a list of HTML elements\n * and returns a remove listener function.\n *\n * @param {NodeList|HTMLCollection} nodeList\n * @param {String} type\n * @param {Function} callback\n * @return {Object}\n */\nfunction listenNodeList(nodeList, type, callback) {\n    Array.prototype.forEach.call(nodeList, function(node) {\n        node.addEventListener(type, callback);\n    });\n\n    return {\n        destroy: function() {\n            Array.prototype.forEach.call(nodeList, function(node) {\n                node.removeEventListener(type, callback);\n            });\n        }\n    }\n}\n\n/**\n * Add an event listener to a selector\n * and returns a remove listener function.\n *\n * @param {String} selector\n * @param {String} type\n * @param {Function} callback\n * @return {Object}\n */\nfunction listenSelector(selector, type, callback) {\n    return delegate(document.body, selector, type, callback);\n}\n\nmodule.exports = listen;\n\n\n/***/ }),\n\n/***/ 817:\n/***/ (function(module) {\n\nfunction select(element) {\n    var selectedText;\n\n    if (element.nodeName === 'SELECT') {\n        element.focus();\n\n        selectedText = element.value;\n    }\n    else if (element.nodeName === 'INPUT' || element.nodeName === 'TEXTAREA') {\n        var isReadOnly = element.hasAttribute('readonly');\n\n        if (!isReadOnly) {\n            element.setAttribute('readonly', '');\n        }\n\n        element.select();\n        element.setSelectionRange(0, element.value.length);\n\n        if (!isReadOnly) {\n            element.removeAttribute('readonly');\n        }\n\n        selectedText = element.value;\n    }\n    else {\n        if (element.hasAttribute('contenteditable')) {\n            element.focus();\n        }\n\n        var selection = window.getSelection();\n        var range = document.createRange();\n\n        range.selectNodeContents(element);\n        selection.removeAllRanges();\n        selection.addRange(range);\n\n        selectedText = selection.toString();\n    }\n\n    return selectedText;\n}\n\nmodule.exports = select;\n\n\n/***/ }),\n\n/***/ 279:\n/***/ (function(module) {\n\nfunction E () {\n  // Keep this empty so it's easier to inherit from\n  // (via https://github.com/lipsmack from https://github.com/scottcorgan/tiny-emitter/issues/3)\n}\n\nE.prototype = {\n  on: function (name, callback, ctx) {\n    var e = this.e || (this.e = {});\n\n    (e[name] || (e[name] = [])).push({\n      fn: callback,\n      ctx: ctx\n    });\n\n    return this;\n  },\n\n  once: function (name, callback, ctx) {\n    var self = this;\n    function listener () {\n      self.off(name, listener);\n      callback.apply(ctx, arguments);\n    };\n\n    listener._ = callback\n    return this.on(name, listener, ctx);\n  },\n\n  emit: function (name) {\n    var data = [].slice.call(arguments, 1);\n    var evtArr = ((this.e || (this.e = {}))[name] || []).slice();\n    var i = 0;\n    var len = evtArr.length;\n\n    for (i; i < len; i++) {\n      evtArr[i].fn.apply(evtArr[i].ctx, data);\n    }\n\n    return this;\n  },\n\n  off: function (name, callback) {\n    var e = this.e || (this.e = {});\n    var evts = e[name];\n    var liveEvents = [];\n\n    if (evts && callback) {\n      for (var i = 0, len = evts.length; i < len; i++) {\n        if (evts[i].fn !== callback && evts[i].fn._ !== callback)\n          liveEvents.push(evts[i]);\n      }\n    }\n\n    // Remove event from queue to prevent memory leak\n    // Suggested by https://github.com/lazd\n    // Ref: https://github.com/scottcorgan/tiny-emitter/commit/c6ebfaa9bc973b33d110a84a307742b7cf94c953#commitcomment-5024910\n\n    (liveEvents.length)\n      ? e[name] = liveEvents\n      : delete e[name];\n\n    return this;\n  }\n};\n\nmodule.exports = E;\nmodule.exports.TinyEmitter = E;\n\n\n/***/ })\n\n/******/ \t});\n/************************************************************************/\n/******/ \t// The module cache\n/******/ \tvar __webpack_module_cache__ = {};\n/******/ \t\n/******/ \t// The require function\n/******/ \tfunction __webpack_require__(moduleId) {\n/******/ \t\t// Check if module is in cache\n/******/ \t\tif(__webpack_module_cache__[moduleId]) {\n/******/ \t\t\treturn __webpack_module_cache__[moduleId].exports;\n/******/ \t\t}\n/******/ \t\t// Create a new module (and put it into the cache)\n/******/ \t\tvar module = __webpack_module_cache__[moduleId] = {\n/******/ \t\t\t// no module.id needed\n/******/ \t\t\t// no module.loaded needed\n/******/ \t\t\texports: {}\n/******/ \t\t};\n/******/ \t\n/******/ \t\t// Execute the module function\n/******/ \t\t__webpack_modules__[moduleId](module, module.exports, __webpack_require__);\n/******/ \t\n/******/ \t\t// Return the exports of the module\n/******/ \t\treturn module.exports;\n/******/ \t}\n/******/ \t\n/************************************************************************/\n/******/ \t/* webpack/runtime/compat get default export */\n/******/ \t!function() {\n/******/ \t\t// getDefaultExport function for compatibility with non-harmony modules\n/******/ \t\t__webpack_require__.n = function(module) {\n/******/ \t\t\tvar getter = module && module.__esModule ?\n/******/ \t\t\t\tfunction() { return module['default']; } :\n/******/ \t\t\t\tfunction() { return module; };\n/******/ \t\t\t__webpack_require__.d(getter, { a: getter });\n/******/ \t\t\treturn getter;\n/******/ \t\t};\n/******/ \t}();\n/******/ \t\n/******/ \t/* webpack/runtime/define property getters */\n/******/ \t!function() {\n/******/ \t\t// define getter functions for harmony exports\n/******/ \t\t__webpack_require__.d = function(exports, definition) {\n/******/ \t\t\tfor(var key in definition) {\n/******/ \t\t\t\tif(__webpack_require__.o(definition, key) && !__webpack_require__.o(exports, key)) {\n/******/ \t\t\t\t\tObject.defineProperty(exports, key, { enumerable: true, get: definition[key] });\n/******/ \t\t\t\t}\n/******/ \t\t\t}\n/******/ \t\t};\n/******/ \t}();\n/******/ \t\n/******/ \t/* webpack/runtime/hasOwnProperty shorthand */\n/******/ \t!function() {\n/******/ \t\t__webpack_require__.o = function(obj, prop) { return Object.prototype.hasOwnProperty.call(obj, prop); }\n/******/ \t}();\n/******/ \t\n/************************************************************************/\n/******/ \t// module exports must be returned from runtime so entry inlining is disabled\n/******/ \t// startup\n/******/ \t// Load entry module and return exports\n/******/ \treturn __webpack_require__(686);\n/******/ })()\n.default;\n});", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport \"focus-visible\"\n\nimport {\n  EMPTY,\n  NEVER,\n  Observable,\n  Subject,\n  defer,\n  delay,\n  filter,\n  map,\n  merge,\n  mergeWith,\n  shareReplay,\n  switchMap\n} from \"rxjs\"\n\nimport { configuration, feature } from \"./_\"\nimport {\n  at,\n  getActiveElement,\n  getOptionalElement,\n  requestJSON,\n  setLocation,\n  setToggle,\n  watchDocument,\n  watchKeyboard,\n  watchLocation,\n  watchLocationTarget,\n  watchMedia,\n  watchPrint,\n  watchScript,\n  watchViewport\n} from \"./browser\"\nimport {\n  getComponentElement,\n  getComponentElements,\n  mountAnnounce,\n  mountBackToTop,\n  mountConsent,\n  mountContent,\n  mountDialog,\n  mountHeader,\n  mountHeaderTitle,\n  mountPalette,\n  mountProgress,\n  mountSearch,\n  mountSearchHiglight,\n  mountSidebar,\n  mountSource,\n  mountTableOfContents,\n  mountTabs,\n  watchHeader,\n  watchMain\n} from \"./components\"\nimport {\n  SearchIndex,\n  setupClipboardJS,\n  setupInstantNavigation,\n  setupVersionSelector\n} from \"./integrations\"\nimport {\n  patchEllipsis,\n  patchIndeterminate,\n  patchScrollfix,\n  patchScrolllock\n} from \"./patches\"\nimport \"./polyfills\"\n\n/* ----------------------------------------------------------------------------\n * Functions - @todo refactor\n * ------------------------------------------------------------------------- */\n\n/**\n * Fetch search index\n *\n * @returns Search index observable\n */\nfunction fetchSearchIndex(): Observable<SearchIndex> {\n  if (location.protocol === \"file:\") {\n    return watchScript(\n      `${new URL(\"search/search_index.js\", config.base)}`\n    )\n      .pipe(\n        // @ts-ignore - @todo fix typings\n        map(() => __index),\n        shareReplay(1)\n      )\n  } else {\n    return requestJSON<SearchIndex>(\n      new URL(\"search/search_index.json\", config.base)\n    )\n  }\n}\n\n/* ----------------------------------------------------------------------------\n * Application\n * ------------------------------------------------------------------------- */\n\n/* Yay, JavaScript is available */\ndocument.documentElement.classList.remove(\"no-js\")\ndocument.documentElement.classList.add(\"js\")\n\n/* Set up navigation observables and subjects */\nconst document$ = watchDocument()\nconst location$ = watchLocation()\nconst target$   = watchLocationTarget(location$)\nconst keyboard$ = watchKeyboard()\n\n/* Set up media observables */\nconst viewport$ = watchViewport()\nconst tablet$   = watchMedia(\"(min-width: 960px)\")\nconst screen$   = watchMedia(\"(min-width: 1220px)\")\nconst print$    = watchPrint()\n\n/* Retrieve search index, if search is enabled */\nconst config = configuration()\nconst index$ = document.forms.namedItem(\"search\")\n  ? fetchSearchIndex()\n  : NEVER\n\n/* Set up Clipboard.js integration */\nconst alert$ = new Subject<string>()\nsetupClipboardJS({ alert$ })\n\n/* Set up progress indicator */\nconst progress$ = new Subject<number>()\n\n/* Set up instant navigation, if enabled */\nif (feature(\"navigation.instant\"))\n  setupInstantNavigation({ location$, viewport$, progress$ })\n    .subscribe(document$)\n\n/* Set up version selector */\nif (config.version?.provider === \"mike\")\n  setupVersionSelector({ document$ })\n\n/* Always close drawer and search on navigation */\nmerge(location$, target$)\n  .pipe(\n    delay(125)\n  )\n    .subscribe(() => {\n      setToggle(\"drawer\", false)\n      setToggle(\"search\", false)\n    })\n\n/* Set up global keyboard handlers */\nkeyboard$\n  .pipe(\n    filter(({ mode }) => mode === \"global\")\n  )\n    .subscribe(key => {\n      switch (key.type) {\n\n        /* Go to previous page */\n        case \"p\":\n        case \",\":\n          const prev = getOptionalElement<HTMLLinkElement>(\"link[rel=prev]\")\n          if (typeof prev !== \"undefined\")\n            setLocation(prev)\n          break\n\n        /* Go to next page */\n        case \"n\":\n        case \".\":\n          const next = getOptionalElement<HTMLLinkElement>(\"link[rel=next]\")\n          if (typeof next !== \"undefined\")\n            setLocation(next)\n          break\n\n        /* Expand navigation, see https://bit.ly/3ZjG5io */\n        case \"Enter\":\n          const active = getActiveElement()\n          if (active instanceof HTMLLabelElement)\n            active.click()\n      }\n    })\n\n/* Set up patches */\npatchEllipsis({ viewport$, document$ })\npatchIndeterminate({ document$, tablet$ })\npatchScrollfix({ document$ })\npatchScrolllock({ viewport$, tablet$ })\n\n/* Set up header and main area observable */\nconst header$ = watchHeader(getComponentElement(\"header\"), { viewport$ })\nconst main$ = document$\n  .pipe(\n    map(() => getComponentElement(\"main\")),\n    switchMap(el => watchMain(el, { viewport$, header$ })),\n    shareReplay(1)\n  )\n\n/* Set up control component observables */\nconst control$ = merge(\n\n  /* Consent */\n  ...getComponentElements(\"consent\")\n    .map(el => mountConsent(el, { target$ })),\n\n  /* Dialog */\n  ...getComponentElements(\"dialog\")\n    .map(el => mountDialog(el, { alert$ })),\n\n  /* Color palette */\n  ...getComponentElements(\"palette\")\n    .map(el => mountPalette(el)),\n\n  /* Progress bar */\n  ...getComponentElements(\"progress\")\n    .map(el => mountProgress(el, { progress$ })),\n\n  /* Search */\n  ...getComponentElements(\"search\")\n    .map(el => mountSearch(el, { index$, keyboard$ })),\n\n  /* Repository information */\n  ...getComponentElements(\"source\")\n    .map(el => mountSource(el))\n)\n\n/* Set up content component observables */\nconst content$ = defer(() => merge(\n\n  /* Announcement bar */\n  ...getComponentElements(\"announce\")\n    .map(el => mountAnnounce(el)),\n\n  /* Content */\n  ...getComponentElements(\"content\")\n    .map(el => mountContent(el, { viewport$, target$, print$ })),\n\n  /* Search highlighting */\n  ...getComponentElements(\"content\")\n    .map(el => feature(\"search.highlight\")\n      ? mountSearchHiglight(el, { index$, location$ })\n      : EMPTY\n    ),\n\n  /* Header */\n  ...getComponentElements(\"header\")\n    .map(el => mountHeader(el, { viewport$, header$, main$ })),\n\n  /* Header title */\n  ...getComponentElements(\"header-title\")\n    .map(el => mountHeaderTitle(el, { viewport$, header$ })),\n\n  /* Sidebar */\n  ...getComponentElements(\"sidebar\")\n    .map(el => el.getAttribute(\"data-md-type\") === \"navigation\"\n      ? at(screen$, () => mountSidebar(el, { viewport$, header$, main$ }))\n      : at(tablet$, () => mountSidebar(el, { viewport$, header$, main$ }))\n    ),\n\n  /* Navigation tabs */\n  ...getComponentElements(\"tabs\")\n    .map(el => mountTabs(el, { viewport$, header$ })),\n\n  /* Table of contents */\n  ...getComponentElements(\"toc\")\n    .map(el => mountTableOfContents(el, {\n      viewport$, header$, main$, target$\n    })),\n\n  /* Back-to-top button */\n  ...getComponentElements(\"top\")\n    .map(el => mountBackToTop(el, { viewport$, header$, main$, target$ }))\n))\n\n/* Set up component observables */\nconst component$ = document$\n  .pipe(\n    switchMap(() => content$),\n    mergeWith(control$),\n    shareReplay(1)\n  )\n\n/* Subscribe to all components */\ncomponent$.subscribe()\n\n/* ----------------------------------------------------------------------------\n * Exports\n * ------------------------------------------------------------------------- */\n\nwindow.document$  = document$          /* Document observable */\nwindow.location$  = location$          /* Location subject */\nwindow.target$    = target$            /* Location target observable */\nwindow.keyboard$  = keyboard$          /* Keyboard observable */\nwindow.viewport$  = viewport$          /* Viewport observable */\nwindow.tablet$    = tablet$            /* Media tablet observable */\nwindow.screen$    = screen$            /* Media screen observable */\nwindow.print$     = print$             /* Media print observable */\nwindow.alert$     = alert$             /* Alert subject */\nwindow.progress$  = progress$          /* Progress indicator subject */\nwindow.component$ = component$         /* Component observable */\n", "/******************************************************************************\nCopyright (c) Microsoft Corporation.\n\nPermission to use, copy, modify, and/or distribute this software for any\npurpose with or without fee is hereby granted.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH\nREGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY\nAND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT,\nINDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM\nLOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR\nOTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR\nPERFORMANCE OF THIS SOFTWARE.\n***************************************************************************** */\n/* global Reflect, Promise, SuppressedError, Symbol, Iterator */\n\nvar extendStatics = function(d, b) {\n  extendStatics = Object.setPrototypeOf ||\n      ({ __proto__: [] } instanceof Array && function (d, b) { d.__proto__ = b; }) ||\n      function (d, b) { for (var p in b) if (Object.prototype.hasOwnProperty.call(b, p)) d[p] = b[p]; };\n  return extendStatics(d, b);\n};\n\nexport function __extends(d, b) {\n  if (typeof b !== \"function\" && b !== null)\n      throw new TypeError(\"Class extends value \" + String(b) + \" is not a constructor or null\");\n  extendStatics(d, b);\n  function __() { this.constructor = d; }\n  d.prototype = b === null ? Object.create(b) : (__.prototype = b.prototype, new __());\n}\n\nexport var __assign = function() {\n  __assign = Object.assign || function __assign(t) {\n      for (var s, i = 1, n = arguments.length; i < n; i++) {\n          s = arguments[i];\n          for (var p in s) if (Object.prototype.hasOwnProperty.call(s, p)) t[p] = s[p];\n      }\n      return t;\n  }\n  return __assign.apply(this, arguments);\n}\n\nexport function __rest(s, e) {\n  var t = {};\n  for (var p in s) if (Object.prototype.hasOwnProperty.call(s, p) && e.indexOf(p) < 0)\n      t[p] = s[p];\n  if (s != null && typeof Object.getOwnPropertySymbols === \"function\")\n      for (var i = 0, p = Object.getOwnPropertySymbols(s); i < p.length; i++) {\n          if (e.indexOf(p[i]) < 0 && Object.prototype.propertyIsEnumerable.call(s, p[i]))\n              t[p[i]] = s[p[i]];\n      }\n  return t;\n}\n\nexport function __decorate(decorators, target, key, desc) {\n  var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;\n  if (typeof Reflect === \"object\" && typeof Reflect.decorate === \"function\") r = Reflect.decorate(decorators, target, key, desc);\n  else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;\n  return c > 3 && r && Object.defineProperty(target, key, r), r;\n}\n\nexport function __param(paramIndex, decorator) {\n  return function (target, key) { decorator(target, key, paramIndex); }\n}\n\nexport function __esDecorate(ctor, descriptorIn, decorators, contextIn, initializers, extraInitializers) {\n  function accept(f) { if (f !== void 0 && typeof f !== \"function\") throw new TypeError(\"Function expected\"); return f; }\n  var kind = contextIn.kind, key = kind === \"getter\" ? \"get\" : kind === \"setter\" ? \"set\" : \"value\";\n  var target = !descriptorIn && ctor ? contextIn[\"static\"] ? ctor : ctor.prototype : null;\n  var descriptor = descriptorIn || (target ? Object.getOwnPropertyDescriptor(target, contextIn.name) : {});\n  var _, done = false;\n  for (var i = decorators.length - 1; i >= 0; i--) {\n      var context = {};\n      for (var p in contextIn) context[p] = p === \"access\" ? {} : contextIn[p];\n      for (var p in contextIn.access) context.access[p] = contextIn.access[p];\n      context.addInitializer = function (f) { if (done) throw new TypeError(\"Cannot add initializers after decoration has completed\"); extraInitializers.push(accept(f || null)); };\n      var result = (0, decorators[i])(kind === \"accessor\" ? { get: descriptor.get, set: descriptor.set } : descriptor[key], context);\n      if (kind === \"accessor\") {\n          if (result === void 0) continue;\n          if (result === null || typeof result !== \"object\") throw new TypeError(\"Object expected\");\n          if (_ = accept(result.get)) descriptor.get = _;\n          if (_ = accept(result.set)) descriptor.set = _;\n          if (_ = accept(result.init)) initializers.unshift(_);\n      }\n      else if (_ = accept(result)) {\n          if (kind === \"field\") initializers.unshift(_);\n          else descriptor[key] = _;\n      }\n  }\n  if (target) Object.defineProperty(target, contextIn.name, descriptor);\n  done = true;\n};\n\nexport function __runInitializers(thisArg, initializers, value) {\n  var useValue = arguments.length > 2;\n  for (var i = 0; i < initializers.length; i++) {\n      value = useValue ? initializers[i].call(thisArg, value) : initializers[i].call(thisArg);\n  }\n  return useValue ? value : void 0;\n};\n\nexport function __propKey(x) {\n  return typeof x === \"symbol\" ? x : \"\".concat(x);\n};\n\nexport function __setFunctionName(f, name, prefix) {\n  if (typeof name === \"symbol\") name = name.description ? \"[\".concat(name.description, \"]\") : \"\";\n  return Object.defineProperty(f, \"name\", { configurable: true, value: prefix ? \"\".concat(prefix, \" \", name) : name });\n};\n\nexport function __metadata(metadataKey, metadataValue) {\n  if (typeof Reflect === \"object\" && typeof Reflect.metadata === \"function\") return Reflect.metadata(metadataKey, metadataValue);\n}\n\nexport function __awaiter(thisArg, _arguments, P, generator) {\n  function adopt(value) { return value instanceof P ? value : new P(function (resolve) { resolve(value); }); }\n  return new (P || (P = Promise))(function (resolve, reject) {\n      function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }\n      function rejected(value) { try { step(generator[\"throw\"](value)); } catch (e) { reject(e); } }\n      function step(result) { result.done ? resolve(result.value) : adopt(result.value).then(fulfilled, rejected); }\n      step((generator = generator.apply(thisArg, _arguments || [])).next());\n  });\n}\n\nexport function __generator(thisArg, body) {\n  var _ = { label: 0, sent: function() { if (t[0] & 1) throw t[1]; return t[1]; }, trys: [], ops: [] }, f, y, t, g = Object.create((typeof Iterator === \"function\" ? Iterator : Object).prototype);\n  return g.next = verb(0), g[\"throw\"] = verb(1), g[\"return\"] = verb(2), typeof Symbol === \"function\" && (g[Symbol.iterator] = function() { return this; }), g;\n  function verb(n) { return function (v) { return step([n, v]); }; }\n  function step(op) {\n      if (f) throw new TypeError(\"Generator is already executing.\");\n      while (g && (g = 0, op[0] && (_ = 0)), _) try {\n          if (f = 1, y && (t = op[0] & 2 ? y[\"return\"] : op[0] ? y[\"throw\"] || ((t = y[\"return\"]) && t.call(y), 0) : y.next) && !(t = t.call(y, op[1])).done) return t;\n          if (y = 0, t) op = [op[0] & 2, t.value];\n          switch (op[0]) {\n              case 0: case 1: t = op; break;\n              case 4: _.label++; return { value: op[1], done: false };\n              case 5: _.label++; y = op[1]; op = [0]; continue;\n              case 7: op = _.ops.pop(); _.trys.pop(); continue;\n              default:\n                  if (!(t = _.trys, t = t.length > 0 && t[t.length - 1]) && (op[0] === 6 || op[0] === 2)) { _ = 0; continue; }\n                  if (op[0] === 3 && (!t || (op[1] > t[0] && op[1] < t[3]))) { _.label = op[1]; break; }\n                  if (op[0] === 6 && _.label < t[1]) { _.label = t[1]; t = op; break; }\n                  if (t && _.label < t[2]) { _.label = t[2]; _.ops.push(op); break; }\n                  if (t[2]) _.ops.pop();\n                  _.trys.pop(); continue;\n          }\n          op = body.call(thisArg, _);\n      } catch (e) { op = [6, e]; y = 0; } finally { f = t = 0; }\n      if (op[0] & 5) throw op[1]; return { value: op[0] ? op[1] : void 0, done: true };\n  }\n}\n\nexport var __createBinding = Object.create ? (function(o, m, k, k2) {\n  if (k2 === undefined) k2 = k;\n  var desc = Object.getOwnPropertyDescriptor(m, k);\n  if (!desc || (\"get\" in desc ? !m.__esModule : desc.writable || desc.configurable)) {\n      desc = { enumerable: true, get: function() { return m[k]; } };\n  }\n  Object.defineProperty(o, k2, desc);\n}) : (function(o, m, k, k2) {\n  if (k2 === undefined) k2 = k;\n  o[k2] = m[k];\n});\n\nexport function __exportStar(m, o) {\n  for (var p in m) if (p !== \"default\" && !Object.prototype.hasOwnProperty.call(o, p)) __createBinding(o, m, p);\n}\n\nexport function __values(o) {\n  var s = typeof Symbol === \"function\" && Symbol.iterator, m = s && o[s], i = 0;\n  if (m) return m.call(o);\n  if (o && typeof o.length === \"number\") return {\n      next: function () {\n          if (o && i >= o.length) o = void 0;\n          return { value: o && o[i++], done: !o };\n      }\n  };\n  throw new TypeError(s ? \"Object is not iterable.\" : \"Symbol.iterator is not defined.\");\n}\n\nexport function __read(o, n) {\n  var m = typeof Symbol === \"function\" && o[Symbol.iterator];\n  if (!m) return o;\n  var i = m.call(o), r, ar = [], e;\n  try {\n      while ((n === void 0 || n-- > 0) && !(r = i.next()).done) ar.push(r.value);\n  }\n  catch (error) { e = { error: error }; }\n  finally {\n      try {\n          if (r && !r.done && (m = i[\"return\"])) m.call(i);\n      }\n      finally { if (e) throw e.error; }\n  }\n  return ar;\n}\n\n/** @deprecated */\nexport function __spread() {\n  for (var ar = [], i = 0; i < arguments.length; i++)\n      ar = ar.concat(__read(arguments[i]));\n  return ar;\n}\n\n/** @deprecated */\nexport function __spreadArrays() {\n  for (var s = 0, i = 0, il = arguments.length; i < il; i++) s += arguments[i].length;\n  for (var r = Array(s), k = 0, i = 0; i < il; i++)\n      for (var a = arguments[i], j = 0, jl = a.length; j < jl; j++, k++)\n          r[k] = a[j];\n  return r;\n}\n\nexport function __spreadArray(to, from, pack) {\n  if (pack || arguments.length === 2) for (var i = 0, l = from.length, ar; i < l; i++) {\n      if (ar || !(i in from)) {\n          if (!ar) ar = Array.prototype.slice.call(from, 0, i);\n          ar[i] = from[i];\n      }\n  }\n  return to.concat(ar || Array.prototype.slice.call(from));\n}\n\nexport function __await(v) {\n  return this instanceof __await ? (this.v = v, this) : new __await(v);\n}\n\nexport function __asyncGenerator(thisArg, _arguments, generator) {\n  if (!Symbol.asyncIterator) throw new TypeError(\"Symbol.asyncIterator is not defined.\");\n  var g = generator.apply(thisArg, _arguments || []), i, q = [];\n  return i = Object.create((typeof AsyncIterator === \"function\" ? AsyncIterator : Object).prototype), verb(\"next\"), verb(\"throw\"), verb(\"return\", awaitReturn), i[Symbol.asyncIterator] = function () { return this; }, i;\n  function awaitReturn(f) { return function (v) { return Promise.resolve(v).then(f, reject); }; }\n  function verb(n, f) { if (g[n]) { i[n] = function (v) { return new Promise(function (a, b) { q.push([n, v, a, b]) > 1 || resume(n, v); }); }; if (f) i[n] = f(i[n]); } }\n  function resume(n, v) { try { step(g[n](v)); } catch (e) { settle(q[0][3], e); } }\n  function step(r) { r.value instanceof __await ? Promise.resolve(r.value.v).then(fulfill, reject) : settle(q[0][2], r); }\n  function fulfill(value) { resume(\"next\", value); }\n  function reject(value) { resume(\"throw\", value); }\n  function settle(f, v) { if (f(v), q.shift(), q.length) resume(q[0][0], q[0][1]); }\n}\n\nexport function __asyncDelegator(o) {\n  var i, p;\n  return i = {}, verb(\"next\"), verb(\"throw\", function (e) { throw e; }), verb(\"return\"), i[Symbol.iterator] = function () { return this; }, i;\n  function verb(n, f) { i[n] = o[n] ? function (v) { return (p = !p) ? { value: __await(o[n](v)), done: false } : f ? f(v) : v; } : f; }\n}\n\nexport function __asyncValues(o) {\n  if (!Symbol.asyncIterator) throw new TypeError(\"Symbol.asyncIterator is not defined.\");\n  var m = o[Symbol.asyncIterator], i;\n  return m ? m.call(o) : (o = typeof __values === \"function\" ? __values(o) : o[Symbol.iterator](), i = {}, verb(\"next\"), verb(\"throw\"), verb(\"return\"), i[Symbol.asyncIterator] = function () { return this; }, i);\n  function verb(n) { i[n] = o[n] && function (v) { return new Promise(function (resolve, reject) { v = o[n](v), settle(resolve, reject, v.done, v.value); }); }; }\n  function settle(resolve, reject, d, v) { Promise.resolve(v).then(function(v) { resolve({ value: v, done: d }); }, reject); }\n}\n\nexport function __makeTemplateObject(cooked, raw) {\n  if (Object.defineProperty) { Object.defineProperty(cooked, \"raw\", { value: raw }); } else { cooked.raw = raw; }\n  return cooked;\n};\n\nvar __setModuleDefault = Object.create ? (function(o, v) {\n  Object.defineProperty(o, \"default\", { enumerable: true, value: v });\n}) : function(o, v) {\n  o[\"default\"] = v;\n};\n\nexport function __importStar(mod) {\n  if (mod && mod.__esModule) return mod;\n  var result = {};\n  if (mod != null) for (var k in mod) if (k !== \"default\" && Object.prototype.hasOwnProperty.call(mod, k)) __createBinding(result, mod, k);\n  __setModuleDefault(result, mod);\n  return result;\n}\n\nexport function __importDefault(mod) {\n  return (mod && mod.__esModule) ? mod : { default: mod };\n}\n\nexport function __classPrivateFieldGet(receiver, state, kind, f) {\n  if (kind === \"a\" && !f) throw new TypeError(\"Private accessor was defined without a getter\");\n  if (typeof state === \"function\" ? receiver !== state || !f : !state.has(receiver)) throw new TypeError(\"Cannot read private member from an object whose class did not declare it\");\n  return kind === \"m\" ? f : kind === \"a\" ? f.call(receiver) : f ? f.value : state.get(receiver);\n}\n\nexport function __classPrivateFieldSet(receiver, state, value, kind, f) {\n  if (kind === \"m\") throw new TypeError(\"Private method is not writable\");\n  if (kind === \"a\" && !f) throw new TypeError(\"Private accessor was defined without a setter\");\n  if (typeof state === \"function\" ? receiver !== state || !f : !state.has(receiver)) throw new TypeError(\"Cannot write private member to an object whose class did not declare it\");\n  return (kind === \"a\" ? f.call(receiver, value) : f ? f.value = value : state.set(receiver, value)), value;\n}\n\nexport function __classPrivateFieldIn(state, receiver) {\n  if (receiver === null || (typeof receiver !== \"object\" && typeof receiver !== \"function\")) throw new TypeError(\"Cannot use 'in' operator on non-object\");\n  return typeof state === \"function\" ? receiver === state : state.has(receiver);\n}\n\nexport function __addDisposableResource(env, value, async) {\n  if (value !== null && value !== void 0) {\n    if (typeof value !== \"object\" && typeof value !== \"function\") throw new TypeError(\"Object expected.\");\n    var dispose, inner;\n    if (async) {\n      if (!Symbol.asyncDispose) throw new TypeError(\"Symbol.asyncDispose is not defined.\");\n      dispose = value[Symbol.asyncDispose];\n    }\n    if (dispose === void 0) {\n      if (!Symbol.dispose) throw new TypeError(\"Symbol.dispose is not defined.\");\n      dispose = value[Symbol.dispose];\n      if (async) inner = dispose;\n    }\n    if (typeof dispose !== \"function\") throw new TypeError(\"Object not disposable.\");\n    if (inner) dispose = function() { try { inner.call(this); } catch (e) { return Promise.reject(e); } };\n    env.stack.push({ value: value, dispose: dispose, async: async });\n  }\n  else if (async) {\n    env.stack.push({ async: true });\n  }\n  return value;\n}\n\nvar _SuppressedError = typeof SuppressedError === \"function\" ? SuppressedError : function (error, suppressed, message) {\n  var e = new Error(message);\n  return e.name = \"SuppressedError\", e.error = error, e.suppressed = suppressed, e;\n};\n\nexport function __disposeResources(env) {\n  function fail(e) {\n    env.error = env.hasError ? new _SuppressedError(e, env.error, \"An error was suppressed during disposal.\") : e;\n    env.hasError = true;\n  }\n  var r, s = 0;\n  function next() {\n    while (r = env.stack.pop()) {\n      try {\n        if (!r.async && s === 1) return s = 0, env.stack.push(r), Promise.resolve().then(next);\n        if (r.dispose) {\n          var result = r.dispose.call(r.value);\n          if (r.async) return s |= 2, Promise.resolve(result).then(next, function(e) { fail(e); return next(); });\n        }\n        else s |= 1;\n      }\n      catch (e) {\n        fail(e);\n      }\n    }\n    if (s === 1) return env.hasError ? Promise.reject(env.error) : Promise.resolve();\n    if (env.hasError) throw env.error;\n  }\n  return next();\n}\n\nexport default {\n  __extends,\n  __assign,\n  __rest,\n  __decorate,\n  __param,\n  __metadata,\n  __awaiter,\n  __generator,\n  __createBinding,\n  __exportStar,\n  __values,\n  __read,\n  __spread,\n  __spreadArrays,\n  __spreadArray,\n  __await,\n  __asyncGenerator,\n  __asyncDelegator,\n  __asyncValues,\n  __makeTemplateObject,\n  __importStar,\n  __importDefault,\n  __classPrivateFieldGet,\n  __classPrivateFieldSet,\n  __classPrivateFieldIn,\n  __addDisposableResource,\n  __disposeResources,\n};\n", "/**\n * Returns true if the object is a function.\n * @param value The value to check\n */\nexport function isFunction(value: any): value is (...args: any[]) => any {\n  return typeof value === 'function';\n}\n", "/**\n * Used to create Error subclasses until the community moves away from ES5.\n *\n * This is because compiling from TypeScript down to ES5 has issues with subclassing Errors\n * as well as other built-in types: https://github.com/Microsoft/TypeScript/issues/12123\n *\n * @param createImpl A factory function to create the actual constructor implementation. The returned\n * function should be a named function that calls `_super` internally.\n */\nexport function createErrorClass<T>(createImpl: (_super: any) => any): T {\n  const _super = (instance: any) => {\n    Error.call(instance);\n    instance.stack = new Error().stack;\n  };\n\n  const ctorFunc = createImpl(_super);\n  ctorFunc.prototype = Object.create(Error.prototype);\n  ctorFunc.prototype.constructor = ctorFunc;\n  return ctorFunc;\n}\n", "import { createErrorClass } from './createErrorClass';\n\nexport interface UnsubscriptionError extends Error {\n  readonly errors: any[];\n}\n\nexport interface UnsubscriptionErrorCtor {\n  /**\n   * @deprecated Internal implementation detail. Do not construct error instances.\n   * Cannot be tagged as internal: https://github.com/ReactiveX/rxjs/issues/6269\n   */\n  new (errors: any[]): UnsubscriptionError;\n}\n\n/**\n * An error thrown when one or more errors have occurred during the\n * `unsubscribe` of a {@link Subscription}.\n */\nexport const UnsubscriptionError: UnsubscriptionErrorCtor = createErrorClass(\n  (_super) =>\n    function UnsubscriptionErrorImpl(this: any, errors: (Error | string)[]) {\n      _super(this);\n      this.message = errors\n        ? `${errors.length} errors occurred during unsubscription:\n${errors.map((err, i) => `${i + 1}) ${err.toString()}`).join('\\n  ')}`\n        : '';\n      this.name = 'UnsubscriptionError';\n      this.errors = errors;\n    }\n);\n", "/**\n * Removes an item from an array, mutating it.\n * @param arr The array to remove the item from\n * @param item The item to remove\n */\nexport function arrRemove<T>(arr: T[] | undefined | null, item: T) {\n  if (arr) {\n    const index = arr.indexOf(item);\n    0 <= index && arr.splice(index, 1);\n  }\n}\n", "import { isFunction } from './util/isFunction';\nimport { UnsubscriptionError } from './util/UnsubscriptionError';\nimport { SubscriptionLike, TeardownLogic, Unsubscribable } from './types';\nimport { arrRemove } from './util/arrRemove';\n\n/**\n * Represents a disposable resource, such as the execution of an Observable. A\n * Subscription has one important method, `unsubscribe`, that takes no argument\n * and just disposes the resource held by the subscription.\n *\n * Additionally, subscriptions may be grouped together through the `add()`\n * method, which will attach a child Subscription to the current Subscription.\n * When a Subscription is unsubscribed, all its children (and its grandchildren)\n * will be unsubscribed as well.\n *\n * @class Subscription\n */\nexport class Subscription implements SubscriptionLike {\n  /** @nocollapse */\n  public static EMPTY = (() => {\n    const empty = new Subscription();\n    empty.closed = true;\n    return empty;\n  })();\n\n  /**\n   * A flag to indicate whether this Subscription has already been unsubscribed.\n   */\n  public closed = false;\n\n  private _parentage: Subscription[] | Subscription | null = null;\n\n  /**\n   * The list of registered finalizers to execute upon unsubscription. Adding and removing from this\n   * list occurs in the {@link #add} and {@link #remove} methods.\n   */\n  private _finalizers: Exclude<TeardownLogic, void>[] | null = null;\n\n  /**\n   * @param initialTeardown A function executed first as part of the finalization\n   * process that is kicked off when {@link #unsubscribe} is called.\n   */\n  constructor(private initialTeardown?: () => void) {}\n\n  /**\n   * Disposes the resources held by the subscription. May, for instance, cancel\n   * an ongoing Observable execution or cancel any other type of work that\n   * started when the Subscription was created.\n   * @return {void}\n   */\n  unsubscribe(): void {\n    let errors: any[] | undefined;\n\n    if (!this.closed) {\n      this.closed = true;\n\n      // Remove this from it's parents.\n      const { _parentage } = this;\n      if (_parentage) {\n        this._parentage = null;\n        if (Array.isArray(_parentage)) {\n          for (const parent of _parentage) {\n            parent.remove(this);\n          }\n        } else {\n          _parentage.remove(this);\n        }\n      }\n\n      const { initialTeardown: initialFinalizer } = this;\n      if (isFunction(initialFinalizer)) {\n        try {\n          initialFinalizer();\n        } catch (e) {\n          errors = e instanceof UnsubscriptionError ? e.errors : [e];\n        }\n      }\n\n      const { _finalizers } = this;\n      if (_finalizers) {\n        this._finalizers = null;\n        for (const finalizer of _finalizers) {\n          try {\n            execFinalizer(finalizer);\n          } catch (err) {\n            errors = errors ?? [];\n            if (err instanceof UnsubscriptionError) {\n              errors = [...errors, ...err.errors];\n            } else {\n              errors.push(err);\n            }\n          }\n        }\n      }\n\n      if (errors) {\n        throw new UnsubscriptionError(errors);\n      }\n    }\n  }\n\n  /**\n   * Adds a finalizer to this subscription, so that finalization will be unsubscribed/called\n   * when this subscription is unsubscribed. If this subscription is already {@link #closed},\n   * because it has already been unsubscribed, then whatever finalizer is passed to it\n   * will automatically be executed (unless the finalizer itself is also a closed subscription).\n   *\n   * Closed Subscriptions cannot be added as finalizers to any subscription. Adding a closed\n   * subscription to a any subscription will result in no operation. (A noop).\n   *\n   * Adding a subscription to itself, or adding `null` or `undefined` will not perform any\n   * operation at all. (A noop).\n   *\n   * `Subscription` instances that are added to this instance will automatically remove themselves\n   * if they are unsubscribed. Functions and {@link Unsubscribable} objects that you wish to remove\n   * will need to be removed manually with {@link #remove}\n   *\n   * @param teardown The finalization logic to add to this subscription.\n   */\n  add(teardown: TeardownLogic): void {\n    // Only add the finalizer if it's not undefined\n    // and don't add a subscription to itself.\n    if (teardown && teardown !== this) {\n      if (this.closed) {\n        // If this subscription is already closed,\n        // execute whatever finalizer is handed to it automatically.\n        execFinalizer(teardown);\n      } else {\n        if (teardown instanceof Subscription) {\n          // We don't add closed subscriptions, and we don't add the same subscription\n          // twice. Subscription unsubscribe is idempotent.\n          if (teardown.closed || teardown._hasParent(this)) {\n            return;\n          }\n          teardown._addParent(this);\n        }\n        (this._finalizers = this._finalizers ?? []).push(teardown);\n      }\n    }\n  }\n\n  /**\n   * Checks to see if a this subscription already has a particular parent.\n   * This will signal that this subscription has already been added to the parent in question.\n   * @param parent the parent to check for\n   */\n  private _hasParent(parent: Subscription) {\n    const { _parentage } = this;\n    return _parentage === parent || (Array.isArray(_parentage) && _parentage.includes(parent));\n  }\n\n  /**\n   * Adds a parent to this subscription so it can be removed from the parent if it\n   * unsubscribes on it's own.\n   *\n   * NOTE: THIS ASSUMES THAT {@link _hasParent} HAS ALREADY BEEN CHECKED.\n   * @param parent The parent subscription to add\n   */\n  private _addParent(parent: Subscription) {\n    const { _parentage } = this;\n    this._parentage = Array.isArray(_parentage) ? (_parentage.push(parent), _parentage) : _parentage ? [_parentage, parent] : parent;\n  }\n\n  /**\n   * Called on a child when it is removed via {@link #remove}.\n   * @param parent The parent to remove\n   */\n  private _removeParent(parent: Subscription) {\n    const { _parentage } = this;\n    if (_parentage === parent) {\n      this._parentage = null;\n    } else if (Array.isArray(_parentage)) {\n      arrRemove(_parentage, parent);\n    }\n  }\n\n  /**\n   * Removes a finalizer from this subscription that was previously added with the {@link #add} method.\n   *\n   * Note that `Subscription` instances, when unsubscribed, will automatically remove themselves\n   * from every other `Subscription` they have been added to. This means that using the `remove` method\n   * is not a common thing and should be used thoughtfully.\n   *\n   * If you add the same finalizer instance of a function or an unsubscribable object to a `Subscription` instance\n   * more than once, you will need to call `remove` the same number of times to remove all instances.\n   *\n   * All finalizer instances are removed to free up memory upon unsubscription.\n   *\n   * @param teardown The finalizer to remove from this subscription\n   */\n  remove(teardown: Exclude<TeardownLogic, void>): void {\n    const { _finalizers } = this;\n    _finalizers && arrRemove(_finalizers, teardown);\n\n    if (teardown instanceof Subscription) {\n      teardown._removeParent(this);\n    }\n  }\n}\n\nexport const EMPTY_SUBSCRIPTION = Subscription.EMPTY;\n\nexport function isSubscription(value: any): value is Subscription {\n  return (\n    value instanceof Subscription ||\n    (value && 'closed' in value && isFunction(value.remove) && isFunction(value.add) && isFunction(value.unsubscribe))\n  );\n}\n\nfunction execFinalizer(finalizer: Unsubscribable | (() => void)) {\n  if (isFunction(finalizer)) {\n    finalizer();\n  } else {\n    finalizer.unsubscribe();\n  }\n}\n", "import { Subscriber } from './Subscriber';\nimport { ObservableNotification } from './types';\n\n/**\n * The {@link GlobalConfig} object for RxJS. It is used to configure things\n * like how to react on unhandled errors.\n */\nexport const config: GlobalConfig = {\n  onUnhandledError: null,\n  onStoppedNotification: null,\n  Promise: undefined,\n  useDeprecatedSynchronousErrorHandling: false,\n  useDeprecatedNextContext: false,\n};\n\n/**\n * The global configuration object for RxJS, used to configure things\n * like how to react on unhandled errors. Accessible via {@link config}\n * object.\n */\nexport interface GlobalConfig {\n  /**\n   * A registration point for unhandled errors from RxJS. These are errors that\n   * cannot were not handled by consuming code in the usual subscription path. For\n   * example, if you have this configured, and you subscribe to an observable without\n   * providing an error handler, errors from that subscription will end up here. This\n   * will _always_ be called asynchronously on another job in the runtime. This is because\n   * we do not want errors thrown in this user-configured handler to interfere with the\n   * behavior of the library.\n   */\n  onUnhandledError: ((err: any) => void) | null;\n\n  /**\n   * A registration point for notifications that cannot be sent to subscribers because they\n   * have completed, errored or have been explicitly unsubscribed. By default, next, complete\n   * and error notifications sent to stopped subscribers are noops. However, sometimes callers\n   * might want a different behavior. For example, with sources that attempt to report errors\n   * to stopped subscribers, a caller can configure RxJS to throw an unhandled error instead.\n   * This will _always_ be called asynchronously on another job in the runtime. This is because\n   * we do not want errors thrown in this user-configured handler to interfere with the\n   * behavior of the library.\n   */\n  onStoppedNotification: ((notification: ObservableNotification<any>, subscriber: Subscriber<any>) => void) | null;\n\n  /**\n   * The promise constructor used by default for {@link Observable#toPromise toPromise} and {@link Observable#forEach forEach}\n   * methods.\n   *\n   * @deprecated As of version 8, RxJS will no longer support this sort of injection of a\n   * Promise constructor. If you need a Promise implementation other than native promises,\n   * please polyfill/patch Promise as you see appropriate. Will be removed in v8.\n   */\n  Promise?: PromiseConstructorLike;\n\n  /**\n   * If true, turns on synchronous error rethrowing, which is a deprecated behavior\n   * in v6 and higher. This behavior enables bad patterns like wrapping a subscribe\n   * call in a try/catch block. It also enables producer interference, a nasty bug\n   * where a multicast can be broken for all observers by a downstream consumer with\n   * an unhandled error. DO NOT USE THIS FLAG UNLESS IT'S NEEDED TO BUY TIME\n   * FOR MIGRATION REASONS.\n   *\n   * @deprecated As of version 8, RxJS will no longer support synchronous throwing\n   * of unhandled errors. All errors will be thrown on a separate call stack to prevent bad\n   * behaviors described above. Will be removed in v8.\n   */\n  useDeprecatedSynchronousErrorHandling: boolean;\n\n  /**\n   * If true, enables an as-of-yet undocumented feature from v5: The ability to access\n   * `unsubscribe()` via `this` context in `next` functions created in observers passed\n   * to `subscribe`.\n   *\n   * This is being removed because the performance was severely problematic, and it could also cause\n   * issues when types other than POJOs are passed to subscribe as subscribers, as they will likely have\n   * their `this` context overwritten.\n   *\n   * @deprecated As of version 8, RxJS will no longer support altering the\n   * context of next functions provided as part of an observer to Subscribe. Instead,\n   * you will have access to a subscription or a signal or token that will allow you to do things like\n   * unsubscribe and test closed status. Will be removed in v8.\n   */\n  useDeprecatedNextContext: boolean;\n}\n", "import type { TimerHandle } from './timerHandle';\ntype SetTimeoutFunction = (handler: () => void, timeout?: number, ...args: any[]) => TimerHandle;\ntype ClearTimeoutFunction = (handle: TimerHandle) => void;\n\ninterface TimeoutProvider {\n  setTimeout: SetTimeoutFunction;\n  clearTimeout: ClearTimeoutFunction;\n  delegate:\n    | {\n        setTimeout: SetTimeoutFunction;\n        clearTimeout: ClearTimeoutFunction;\n      }\n    | undefined;\n}\n\nexport const timeoutProvider: TimeoutProvider = {\n  // When accessing the delegate, use the variable rather than `this` so that\n  // the functions can be called without being bound to the provider.\n  setTimeout(handler: () => void, timeout?: number, ...args) {\n    const { delegate } = timeoutProvider;\n    if (delegate?.setTimeout) {\n      return delegate.setTimeout(handler, timeout, ...args);\n    }\n    return setTimeout(handler, timeout, ...args);\n  },\n  clearTimeout(handle) {\n    const { delegate } = timeoutProvider;\n    return (delegate?.clearTimeout || clearTimeout)(handle as any);\n  },\n  delegate: undefined,\n};\n", "import { config } from '../config';\nimport { timeoutProvider } from '../scheduler/timeoutProvider';\n\n/**\n * Handles an error on another job either with the user-configured {@link onUnhandledError},\n * or by throwing it on that new job so it can be picked up by `window.onerror`, `process.on('error')`, etc.\n *\n * This should be called whenever there is an error that is out-of-band with the subscription\n * or when an error hits a terminal boundary of the subscription and no error handler was provided.\n *\n * @param err the error to report\n */\nexport function reportUnhandledError(err: any) {\n  timeoutProvider.setTimeout(() => {\n    const { onUnhandledError } = config;\n    if (onUnhandledError) {\n      // Execute the user-configured error handler.\n      onUnhandledError(err);\n    } else {\n      // Throw so it is picked up by the runtime's uncaught error mechanism.\n      throw err;\n    }\n  });\n}\n", "/* tslint:disable:no-empty */\nexport function noop() { }\n", "import { CompleteNotification, NextNotification, ErrorNotification } from './types';\n\n/**\n * A completion object optimized for memory use and created to be the\n * same \"shape\" as other notifications in v8.\n * @internal\n */\nexport const COMPLETE_NOTIFICATION = (() => createNotification('C', undefined, undefined) as CompleteNotification)();\n\n/**\n * Internal use only. Creates an optimized error notification that is the same \"shape\"\n * as other notifications.\n * @internal\n */\nexport function errorNotification(error: any): ErrorNotification {\n  return createNotification('E', undefined, error) as any;\n}\n\n/**\n * Internal use only. Creates an optimized next notification that is the same \"shape\"\n * as other notifications.\n * @internal\n */\nexport function nextNotification<T>(value: T) {\n  return createNotification('N', value, undefined) as NextNotification<T>;\n}\n\n/**\n * Ensures that all notifications created internally have the same \"shape\" in v8.\n *\n * TODO: This is only exported to support a crazy legacy test in `groupBy`.\n * @internal\n */\nexport function createNotification(kind: 'N' | 'E' | 'C', value: any, error: any) {\n  return {\n    kind,\n    value,\n    error,\n  };\n}\n", "import { config } from '../config';\n\nlet context: { errorThrown: boolean; error: any } | null = null;\n\n/**\n * Handles dealing with errors for super-gross mode. Creates a context, in which\n * any synchronously thrown errors will be passed to {@link captureError}. Which\n * will record the error such that it will be rethrown after the call back is complete.\n * TODO: Remove in v8\n * @param cb An immediately executed function.\n */\nexport function errorContext(cb: () => void) {\n  if (config.useDeprecatedSynchronousErrorHandling) {\n    const isRoot = !context;\n    if (isRoot) {\n      context = { errorThrown: false, error: null };\n    }\n    cb();\n    if (isRoot) {\n      const { errorThrown, error } = context!;\n      context = null;\n      if (errorThrown) {\n        throw error;\n      }\n    }\n  } else {\n    // This is the general non-deprecated path for everyone that\n    // isn't crazy enough to use super-gross mode (useDeprecatedSynchronousErrorHandling)\n    cb();\n  }\n}\n\n/**\n * Captures errors only in super-gross mode.\n * @param err the error to capture\n */\nexport function captureError(err: any) {\n  if (config.useDeprecatedSynchronousErrorHandling && context) {\n    context.errorThrown = true;\n    context.error = err;\n  }\n}\n", "import { isFunction } from './util/isFunction';\nimport { Observer, ObservableNotification } from './types';\nimport { isSubscription, Subscription } from './Subscription';\nimport { config } from './config';\nimport { reportUnhandledError } from './util/reportUnhandledError';\nimport { noop } from './util/noop';\nimport { nextNotification, errorNotification, COMPLETE_NOTIFICATION } from './NotificationFactories';\nimport { timeoutProvider } from './scheduler/timeoutProvider';\nimport { captureError } from './util/errorContext';\n\n/**\n * Implements the {@link Observer} interface and extends the\n * {@link Subscription} class. While the {@link Observer} is the public API for\n * consuming the values of an {@link Observable}, all Observers get converted to\n * a Subscriber, in order to provide Subscription-like capabilities such as\n * `unsubscribe`. Subscriber is a common type in RxJS, and crucial for\n * implementing operators, but it is rarely used as a public API.\n *\n * @class Subscriber<T>\n */\nexport class Subscriber<T> extends Subscription implements Observer<T> {\n  /**\n   * A static factory for a Subscriber, given a (potentially partial) definition\n   * of an Observer.\n   * @param next The `next` callback of an Observer.\n   * @param error The `error` callback of an\n   * Observer.\n   * @param complete The `complete` callback of an\n   * Observer.\n   * @return A Subscriber wrapping the (partially defined)\n   * Observer represented by the given arguments.\n   * @nocollapse\n   * @deprecated Do not use. Will be removed in v8. There is no replacement for this\n   * method, and there is no reason to be creating instances of `Subscriber` directly.\n   * If you have a specific use case, please file an issue.\n   */\n  static create<T>(next?: (x?: T) => void, error?: (e?: any) => void, complete?: () => void): Subscriber<T> {\n    return new SafeSubscriber(next, error, complete);\n  }\n\n  /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n  protected isStopped: boolean = false;\n  /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n  protected destination: Subscriber<any> | Observer<any>; // this `any` is the escape hatch to erase extra type param (e.g. R)\n\n  /**\n   * @deprecated Internal implementation detail, do not use directly. Will be made internal in v8.\n   * There is no reason to directly create an instance of Subscriber. This type is exported for typings reasons.\n   */\n  constructor(destination?: Subscriber<any> | Observer<any>) {\n    super();\n    if (destination) {\n      this.destination = destination;\n      // Automatically chain subscriptions together here.\n      // if destination is a Subscription, then it is a Subscriber.\n      if (isSubscription(destination)) {\n        destination.add(this);\n      }\n    } else {\n      this.destination = EMPTY_OBSERVER;\n    }\n  }\n\n  /**\n   * The {@link Observer} callback to receive notifications of type `next` from\n   * the Observable, with a value. The Observable may call this method 0 or more\n   * times.\n   * @param {T} [value] The `next` value.\n   * @return {void}\n   */\n  next(value?: T): void {\n    if (this.isStopped) {\n      handleStoppedNotification(nextNotification(value), this);\n    } else {\n      this._next(value!);\n    }\n  }\n\n  /**\n   * The {@link Observer} callback to receive notifications of type `error` from\n   * the Observable, with an attached `Error`. Notifies the Observer that\n   * the Observable has experienced an error condition.\n   * @param {any} [err] The `error` exception.\n   * @return {void}\n   */\n  error(err?: any): void {\n    if (this.isStopped) {\n      handleStoppedNotification(errorNotification(err), this);\n    } else {\n      this.isStopped = true;\n      this._error(err);\n    }\n  }\n\n  /**\n   * The {@link Observer} callback to receive a valueless notification of type\n   * `complete` from the Observable. Notifies the Observer that the Observable\n   * has finished sending push-based notifications.\n   * @return {void}\n   */\n  complete(): void {\n    if (this.isStopped) {\n      handleStoppedNotification(COMPLETE_NOTIFICATION, this);\n    } else {\n      this.isStopped = true;\n      this._complete();\n    }\n  }\n\n  unsubscribe(): void {\n    if (!this.closed) {\n      this.isStopped = true;\n      super.unsubscribe();\n      this.destination = null!;\n    }\n  }\n\n  protected _next(value: T): void {\n    this.destination.next(value);\n  }\n\n  protected _error(err: any): void {\n    try {\n      this.destination.error(err);\n    } finally {\n      this.unsubscribe();\n    }\n  }\n\n  protected _complete(): void {\n    try {\n      this.destination.complete();\n    } finally {\n      this.unsubscribe();\n    }\n  }\n}\n\n/**\n * This bind is captured here because we want to be able to have\n * compatibility with monoid libraries that tend to use a method named\n * `bind`. In particular, a library called Monio requires this.\n */\nconst _bind = Function.prototype.bind;\n\nfunction bind<Fn extends (...args: any[]) => any>(fn: Fn, thisArg: any): Fn {\n  return _bind.call(fn, thisArg);\n}\n\n/**\n * Internal optimization only, DO NOT EXPOSE.\n * @internal\n */\nclass ConsumerObserver<T> implements Observer<T> {\n  constructor(private partialObserver: Partial<Observer<T>>) {}\n\n  next(value: T): void {\n    const { partialObserver } = this;\n    if (partialObserver.next) {\n      try {\n        partialObserver.next(value);\n      } catch (error) {\n        handleUnhandledError(error);\n      }\n    }\n  }\n\n  error(err: any): void {\n    const { partialObserver } = this;\n    if (partialObserver.error) {\n      try {\n        partialObserver.error(err);\n      } catch (error) {\n        handleUnhandledError(error);\n      }\n    } else {\n      handleUnhandledError(err);\n    }\n  }\n\n  complete(): void {\n    const { partialObserver } = this;\n    if (partialObserver.complete) {\n      try {\n        partialObserver.complete();\n      } catch (error) {\n        handleUnhandledError(error);\n      }\n    }\n  }\n}\n\nexport class SafeSubscriber<T> extends Subscriber<T> {\n  constructor(\n    observerOrNext?: Partial<Observer<T>> | ((value: T) => void) | null,\n    error?: ((e?: any) => void) | null,\n    complete?: (() => void) | null\n  ) {\n    super();\n\n    let partialObserver: Partial<Observer<T>>;\n    if (isFunction(observerOrNext) || !observerOrNext) {\n      // The first argument is a function, not an observer. The next\n      // two arguments *could* be observers, or they could be empty.\n      partialObserver = {\n        next: (observerOrNext ?? undefined) as (((value: T) => void) | undefined),\n        error: error ?? undefined,\n        complete: complete ?? undefined,\n      };\n    } else {\n      // The first argument is a partial observer.\n      let context: any;\n      if (this && config.useDeprecatedNextContext) {\n        // This is a deprecated path that made `this.unsubscribe()` available in\n        // next handler functions passed to subscribe. This only exists behind a flag\n        // now, as it is *very* slow.\n        context = Object.create(observerOrNext);\n        context.unsubscribe = () => this.unsubscribe();\n        partialObserver = {\n          next: observerOrNext.next && bind(observerOrNext.next, context),\n          error: observerOrNext.error && bind(observerOrNext.error, context),\n          complete: observerOrNext.complete && bind(observerOrNext.complete, context),\n        };\n      } else {\n        // The \"normal\" path. Just use the partial observer directly.\n        partialObserver = observerOrNext;\n      }\n    }\n\n    // Wrap the partial observer to ensure it's a full observer, and\n    // make sure proper error handling is accounted for.\n    this.destination = new ConsumerObserver(partialObserver);\n  }\n}\n\nfunction handleUnhandledError(error: any) {\n  if (config.useDeprecatedSynchronousErrorHandling) {\n    captureError(error);\n  } else {\n    // Ideal path, we report this as an unhandled error,\n    // which is thrown on a new call stack.\n    reportUnhandledError(error);\n  }\n}\n\n/**\n * An error handler used when no error handler was supplied\n * to the SafeSubscriber -- meaning no error handler was supplied\n * do the `subscribe` call on our observable.\n * @param err The error to handle\n */\nfunction defaultErrorHandler(err: any) {\n  throw err;\n}\n\n/**\n * A handler for notifications that cannot be sent to a stopped subscriber.\n * @param notification The notification being sent\n * @param subscriber The stopped subscriber\n */\nfunction handleStoppedNotification(notification: ObservableNotification<any>, subscriber: Subscriber<any>) {\n  const { onStoppedNotification } = config;\n  onStoppedNotification && timeoutProvider.setTimeout(() => onStoppedNotification(notification, subscriber));\n}\n\n/**\n * The observer used as a stub for subscriptions where the user did not\n * pass any arguments to `subscribe`. Comes with the default error handling\n * behavior.\n */\nexport const EMPTY_OBSERVER: Readonly<Observer<any>> & { closed: true } = {\n  closed: true,\n  next: noop,\n  error: defaultErrorHandler,\n  complete: noop,\n};\n", "/**\n * Symbol.observable or a string \"@@observable\". Used for interop\n *\n * @deprecated We will no longer be exporting this symbol in upcoming versions of RxJS.\n * Instead polyfill and use Symbol.observable directly *or* use https://www.npmjs.com/package/symbol-observable\n */\nexport const observable: string | symbol = (() => (typeof Symbol === 'function' && Symbol.observable) || '@@observable')();\n", "/**\n * This function takes one parameter and just returns it. Simply put,\n * this is like `<T>(x: T): T => x`.\n *\n * ## Examples\n *\n * This is useful in some cases when using things like `mergeMap`\n *\n * ```ts\n * import { interval, take, map, range, mergeMap, identity } from 'rxjs';\n *\n * const source$ = interval(1000).pipe(take(5));\n *\n * const result$ = source$.pipe(\n *   map(i => range(i)),\n *   mergeMap(identity) // same as mergeMap(x => x)\n * );\n *\n * result$.subscribe({\n *   next: console.log\n * });\n * ```\n *\n * Or when you want to selectively apply an operator\n *\n * ```ts\n * import { interval, take, identity } from 'rxjs';\n *\n * const shouldLimit = () => Math.random() < 0.5;\n *\n * const source$ = interval(1000);\n *\n * const result$ = source$.pipe(shouldLimit() ? take(5) : identity);\n *\n * result$.subscribe({\n *   next: console.log\n * });\n * ```\n *\n * @param x Any value that is returned by this function\n * @returns The value passed as the first parameter to this function\n */\nexport function identity<T>(x: T): T {\n  return x;\n}\n", "import { identity } from './identity';\nimport { UnaryFunction } from '../types';\n\nexport function pipe(): typeof identity;\nexport function pipe<T, A>(fn1: UnaryFunction<T, A>): UnaryFunction<T, A>;\nexport function pipe<T, A, B>(fn1: UnaryFunction<T, A>, fn2: UnaryFunction<A, B>): UnaryFunction<T, B>;\nexport function pipe<T, A, B, C>(fn1: UnaryFunction<T, A>, fn2: UnaryFunction<A, B>, fn3: UnaryFunction<B, C>): UnaryFunction<T, C>;\nexport function pipe<T, A, B, C, D>(\n  fn1: UnaryFunction<T, A>,\n  fn2: UnaryFunction<A, B>,\n  fn3: UnaryFunction<B, C>,\n  fn4: UnaryFunction<C, D>\n): UnaryFunction<T, D>;\nexport function pipe<T, A, B, C, D, E>(\n  fn1: UnaryFunction<T, A>,\n  fn2: UnaryFunction<A, B>,\n  fn3: UnaryFunction<B, C>,\n  fn4: UnaryFunction<C, D>,\n  fn5: UnaryFunction<D, E>\n): UnaryFunction<T, E>;\nexport function pipe<T, A, B, C, D, E, F>(\n  fn1: UnaryFunction<T, A>,\n  fn2: UnaryFunction<A, B>,\n  fn3: UnaryFunction<B, C>,\n  fn4: UnaryFunction<C, D>,\n  fn5: UnaryFunction<D, E>,\n  fn6: UnaryFunction<E, F>\n): UnaryFunction<T, F>;\nexport function pipe<T, A, B, C, D, E, F, G>(\n  fn1: UnaryFunction<T, A>,\n  fn2: UnaryFunction<A, B>,\n  fn3: UnaryFunction<B, C>,\n  fn4: UnaryFunction<C, D>,\n  fn5: UnaryFunction<D, E>,\n  fn6: UnaryFunction<E, F>,\n  fn7: UnaryFunction<F, G>\n): UnaryFunction<T, G>;\nexport function pipe<T, A, B, C, D, E, F, G, H>(\n  fn1: UnaryFunction<T, A>,\n  fn2: UnaryFunction<A, B>,\n  fn3: UnaryFunction<B, C>,\n  fn4: UnaryFunction<C, D>,\n  fn5: UnaryFunction<D, E>,\n  fn6: UnaryFunction<E, F>,\n  fn7: UnaryFunction<F, G>,\n  fn8: UnaryFunction<G, H>\n): UnaryFunction<T, H>;\nexport function pipe<T, A, B, C, D, E, F, G, H, I>(\n  fn1: UnaryFunction<T, A>,\n  fn2: UnaryFunction<A, B>,\n  fn3: UnaryFunction<B, C>,\n  fn4: UnaryFunction<C, D>,\n  fn5: UnaryFunction<D, E>,\n  fn6: UnaryFunction<E, F>,\n  fn7: UnaryFunction<F, G>,\n  fn8: UnaryFunction<G, H>,\n  fn9: UnaryFunction<H, I>\n): UnaryFunction<T, I>;\nexport function pipe<T, A, B, C, D, E, F, G, H, I>(\n  fn1: UnaryFunction<T, A>,\n  fn2: UnaryFunction<A, B>,\n  fn3: UnaryFunction<B, C>,\n  fn4: UnaryFunction<C, D>,\n  fn5: UnaryFunction<D, E>,\n  fn6: UnaryFunction<E, F>,\n  fn7: UnaryFunction<F, G>,\n  fn8: UnaryFunction<G, H>,\n  fn9: UnaryFunction<H, I>,\n  ...fns: UnaryFunction<any, any>[]\n): UnaryFunction<T, unknown>;\n\n/**\n * pipe() can be called on one or more functions, each of which can take one argument (\"UnaryFunction\")\n * and uses it to return a value.\n * It returns a function that takes one argument, passes it to the first UnaryFunction, and then\n * passes the result to the next one, passes that result to the next one, and so on.  \n */\nexport function pipe(...fns: Array<UnaryFunction<any, any>>): UnaryFunction<any, any> {\n  return pipeFromArray(fns);\n}\n\n/** @internal */\nexport function pipeFromArray<T, R>(fns: Array<UnaryFunction<T, R>>): UnaryFunction<T, R> {\n  if (fns.length === 0) {\n    return identity as UnaryFunction<any, any>;\n  }\n\n  if (fns.length === 1) {\n    return fns[0];\n  }\n\n  return function piped(input: T): R {\n    return fns.reduce((prev: any, fn: UnaryFunction<T, R>) => fn(prev), input as any);\n  };\n}\n", "import { Operator } from './Operator';\nimport { SafeSubscriber, Subscriber } from './Subscriber';\nimport { isSubscription, Subscription } from './Subscription';\nimport { TeardownLogic, OperatorFunction, Subscribable, Observer } from './types';\nimport { observable as Symbol_observable } from './symbol/observable';\nimport { pipeFromArray } from './util/pipe';\nimport { config } from './config';\nimport { isFunction } from './util/isFunction';\nimport { errorContext } from './util/errorContext';\n\n/**\n * A representation of any set of values over any amount of time. This is the most basic building block\n * of RxJS.\n *\n * @class Observable<T>\n */\nexport class Observable<T> implements Subscribable<T> {\n  /**\n   * @deprecated Internal implementation detail, do not use directly. Will be made internal in v8.\n   */\n  source: Observable<any> | undefined;\n\n  /**\n   * @deprecated Internal implementation detail, do not use directly. Will be made internal in v8.\n   */\n  operator: Operator<any, T> | undefined;\n\n  /**\n   * @constructor\n   * @param {Function} subscribe the function that is called when the Observable is\n   * initially subscribed to. This function is given a Subscriber, to which new values\n   * can be `next`ed, or an `error` method can be called to raise an error, or\n   * `complete` can be called to notify of a successful completion.\n   */\n  constructor(subscribe?: (this: Observable<T>, subscriber: Subscriber<T>) => TeardownLogic) {\n    if (subscribe) {\n      this._subscribe = subscribe;\n    }\n  }\n\n  // HACK: Since TypeScript inherits static properties too, we have to\n  // fight against TypeScript here so Subject can have a different static create signature\n  /**\n   * Creates a new Observable by calling the Observable constructor\n   * @owner Observable\n   * @method create\n   * @param {Function} subscribe? the subscriber function to be passed to the Observable constructor\n   * @return {Observable} a new observable\n   * @nocollapse\n   * @deprecated Use `new Observable()` instead. Will be removed in v8.\n   */\n  static create: (...args: any[]) => any = <T>(subscribe?: (subscriber: Subscriber<T>) => TeardownLogic) => {\n    return new Observable<T>(subscribe);\n  };\n\n  /**\n   * Creates a new Observable, with this Observable instance as the source, and the passed\n   * operator defined as the new observable's operator.\n   * @method lift\n   * @param operator the operator defining the operation to take on the observable\n   * @return a new observable with the Operator applied\n   * @deprecated Internal implementation detail, do not use directly. Will be made internal in v8.\n   * If you have implemented an operator using `lift`, it is recommended that you create an\n   * operator by simply returning `new Observable()` directly. See \"Creating new operators from\n   * scratch\" section here: https://rxjs.dev/guide/operators\n   */\n  lift<R>(operator?: Operator<T, R>): Observable<R> {\n    const observable = new Observable<R>();\n    observable.source = this;\n    observable.operator = operator;\n    return observable;\n  }\n\n  subscribe(observerOrNext?: Partial<Observer<T>> | ((value: T) => void)): Subscription;\n  /** @deprecated Instead of passing separate callback arguments, use an observer argument. Signatures taking separate callback arguments will be removed in v8. Details: https://rxjs.dev/deprecations/subscribe-arguments */\n  subscribe(next?: ((value: T) => void) | null, error?: ((error: any) => void) | null, complete?: (() => void) | null): Subscription;\n  /**\n   * Invokes an execution of an Observable and registers Observer handlers for notifications it will emit.\n   *\n   * <span class=\"informal\">Use it when you have all these Observables, but still nothing is happening.</span>\n   *\n   * `subscribe` is not a regular operator, but a method that calls Observable's internal `subscribe` function. It\n   * might be for example a function that you passed to Observable's constructor, but most of the time it is\n   * a library implementation, which defines what will be emitted by an Observable, and when it be will emitted. This means\n   * that calling `subscribe` is actually the moment when Observable starts its work, not when it is created, as it is often\n   * the thought.\n   *\n   * Apart from starting the execution of an Observable, this method allows you to listen for values\n   * that an Observable emits, as well as for when it completes or errors. You can achieve this in two\n   * of the following ways.\n   *\n   * The first way is creating an object that implements {@link Observer} interface. It should have methods\n   * defined by that interface, but note that it should be just a regular JavaScript object, which you can create\n   * yourself in any way you want (ES6 class, classic function constructor, object literal etc.). In particular, do\n   * not attempt to use any RxJS implementation details to create Observers - you don't need them. Remember also\n   * that your object does not have to implement all methods. If you find yourself creating a method that doesn't\n   * do anything, you can simply omit it. Note however, if the `error` method is not provided and an error happens,\n   * it will be thrown asynchronously. Errors thrown asynchronously cannot be caught using `try`/`catch`. Instead,\n   * use the {@link onUnhandledError} configuration option or use a runtime handler (like `window.onerror` or\n   * `process.on('error)`) to be notified of unhandled errors. Because of this, it's recommended that you provide\n   * an `error` method to avoid missing thrown errors.\n   *\n   * The second way is to give up on Observer object altogether and simply provide callback functions in place of its methods.\n   * This means you can provide three functions as arguments to `subscribe`, where the first function is equivalent\n   * of a `next` method, the second of an `error` method and the third of a `complete` method. Just as in case of an Observer,\n   * if you do not need to listen for something, you can omit a function by passing `undefined` or `null`,\n   * since `subscribe` recognizes these functions by where they were placed in function call. When it comes\n   * to the `error` function, as with an Observer, if not provided, errors emitted by an Observable will be thrown asynchronously.\n   *\n   * You can, however, subscribe with no parameters at all. This may be the case where you're not interested in terminal events\n   * and you also handled emissions internally by using operators (e.g. using `tap`).\n   *\n   * Whichever style of calling `subscribe` you use, in both cases it returns a Subscription object.\n   * This object allows you to call `unsubscribe` on it, which in turn will stop the work that an Observable does and will clean\n   * up all resources that an Observable used. Note that cancelling a subscription will not call `complete` callback\n   * provided to `subscribe` function, which is reserved for a regular completion signal that comes from an Observable.\n   *\n   * Remember that callbacks provided to `subscribe` are not guaranteed to be called asynchronously.\n   * It is an Observable itself that decides when these functions will be called. For example {@link of}\n   * by default emits all its values synchronously. Always check documentation for how given Observable\n   * will behave when subscribed and if its default behavior can be modified with a `scheduler`.\n   *\n   * #### Examples\n   *\n   * Subscribe with an {@link guide/observer Observer}\n   *\n   * ```ts\n   * import { of } from 'rxjs';\n   *\n   * const sumObserver = {\n   *   sum: 0,\n   *   next(value) {\n   *     console.log('Adding: ' + value);\n   *     this.sum = this.sum + value;\n   *   },\n   *   error() {\n   *     // We actually could just remove this method,\n   *     // since we do not really care about errors right now.\n   *   },\n   *   complete() {\n   *     console.log('Sum equals: ' + this.sum);\n   *   }\n   * };\n   *\n   * of(1, 2, 3) // Synchronously emits 1, 2, 3 and then completes.\n   *   .subscribe(sumObserver);\n   *\n   * // Logs:\n   * // 'Adding: 1'\n   * // 'Adding: 2'\n   * // 'Adding: 3'\n   * // 'Sum equals: 6'\n   * ```\n   *\n   * Subscribe with functions ({@link deprecations/subscribe-arguments deprecated})\n   *\n   * ```ts\n   * import { of } from 'rxjs'\n   *\n   * let sum = 0;\n   *\n   * of(1, 2, 3).subscribe(\n   *   value => {\n   *     console.log('Adding: ' + value);\n   *     sum = sum + value;\n   *   },\n   *   undefined,\n   *   () => console.log('Sum equals: ' + sum)\n   * );\n   *\n   * // Logs:\n   * // 'Adding: 1'\n   * // 'Adding: 2'\n   * // 'Adding: 3'\n   * // 'Sum equals: 6'\n   * ```\n   *\n   * Cancel a subscription\n   *\n   * ```ts\n   * import { interval } from 'rxjs';\n   *\n   * const subscription = interval(1000).subscribe({\n   *   next(num) {\n   *     console.log(num)\n   *   },\n   *   complete() {\n   *     // Will not be called, even when cancelling subscription.\n   *     console.log('completed!');\n   *   }\n   * });\n   *\n   * setTimeout(() => {\n   *   subscription.unsubscribe();\n   *   console.log('unsubscribed!');\n   * }, 2500);\n   *\n   * // Logs:\n   * // 0 after 1s\n   * // 1 after 2s\n   * // 'unsubscribed!' after 2.5s\n   * ```\n   *\n   * @param {Observer|Function} observerOrNext (optional) Either an observer with methods to be called,\n   * or the first of three possible handlers, which is the handler for each value emitted from the subscribed\n   * Observable.\n   * @param {Function} error (optional) A handler for a terminal event resulting from an error. If no error handler is provided,\n   * the error will be thrown asynchronously as unhandled.\n   * @param {Function} complete (optional) A handler for a terminal event resulting from successful completion.\n   * @return {Subscription} a subscription reference to the registered handlers\n   * @method subscribe\n   */\n  subscribe(\n    observerOrNext?: Partial<Observer<T>> | ((value: T) => void) | null,\n    error?: ((error: any) => void) | null,\n    complete?: (() => void) | null\n  ): Subscription {\n    const subscriber = isSubscriber(observerOrNext) ? observerOrNext : new SafeSubscriber(observerOrNext, error, complete);\n\n    errorContext(() => {\n      const { operator, source } = this;\n      subscriber.add(\n        operator\n          ? // We're dealing with a subscription in the\n            // operator chain to one of our lifted operators.\n            operator.call(subscriber, source)\n          : source\n          ? // If `source` has a value, but `operator` does not, something that\n            // had intimate knowledge of our API, like our `Subject`, must have\n            // set it. We're going to just call `_subscribe` directly.\n            this._subscribe(subscriber)\n          : // In all other cases, we're likely wrapping a user-provided initializer\n            // function, so we need to catch errors and handle them appropriately.\n            this._trySubscribe(subscriber)\n      );\n    });\n\n    return subscriber;\n  }\n\n  /** @internal */\n  protected _trySubscribe(sink: Subscriber<T>): TeardownLogic {\n    try {\n      return this._subscribe(sink);\n    } catch (err) {\n      // We don't need to return anything in this case,\n      // because it's just going to try to `add()` to a subscription\n      // above.\n      sink.error(err);\n    }\n  }\n\n  /**\n   * Used as a NON-CANCELLABLE means of subscribing to an observable, for use with\n   * APIs that expect promises, like `async/await`. You cannot unsubscribe from this.\n   *\n   * **WARNING**: Only use this with observables you *know* will complete. If the source\n   * observable does not complete, you will end up with a promise that is hung up, and\n   * potentially all of the state of an async function hanging out in memory. To avoid\n   * this situation, look into adding something like {@link timeout}, {@link take},\n   * {@link takeWhile}, or {@link takeUntil} amongst others.\n   *\n   * #### Example\n   *\n   * ```ts\n   * import { interval, take } from 'rxjs';\n   *\n   * const source$ = interval(1000).pipe(take(4));\n   *\n   * async function getTotal() {\n   *   let total = 0;\n   *\n   *   await source$.forEach(value => {\n   *     total += value;\n   *     console.log('observable -> ' + value);\n   *   });\n   *\n   *   return total;\n   * }\n   *\n   * getTotal().then(\n   *   total => console.log('Total: ' + total)\n   * );\n   *\n   * // Expected:\n   * // 'observable -> 0'\n   * // 'observable -> 1'\n   * // 'observable -> 2'\n   * // 'observable -> 3'\n   * // 'Total: 6'\n   * ```\n   *\n   * @param next a handler for each value emitted by the observable\n   * @return a promise that either resolves on observable completion or\n   *  rejects with the handled error\n   */\n  forEach(next: (value: T) => void): Promise<void>;\n\n  /**\n   * @param next a handler for each value emitted by the observable\n   * @param promiseCtor a constructor function used to instantiate the Promise\n   * @return a promise that either resolves on observable completion or\n   *  rejects with the handled error\n   * @deprecated Passing a Promise constructor will no longer be available\n   * in upcoming versions of RxJS. This is because it adds weight to the library, for very\n   * little benefit. If you need this functionality, it is recommended that you either\n   * polyfill Promise, or you create an adapter to convert the returned native promise\n   * to whatever promise implementation you wanted. Will be removed in v8.\n   */\n  forEach(next: (value: T) => void, promiseCtor: PromiseConstructorLike): Promise<void>;\n\n  forEach(next: (value: T) => void, promiseCtor?: PromiseConstructorLike): Promise<void> {\n    promiseCtor = getPromiseCtor(promiseCtor);\n\n    return new promiseCtor<void>((resolve, reject) => {\n      const subscriber = new SafeSubscriber<T>({\n        next: (value) => {\n          try {\n            next(value);\n          } catch (err) {\n            reject(err);\n            subscriber.unsubscribe();\n          }\n        },\n        error: reject,\n        complete: resolve,\n      });\n      this.subscribe(subscriber);\n    }) as Promise<void>;\n  }\n\n  /** @internal */\n  protected _subscribe(subscriber: Subscriber<any>): TeardownLogic {\n    return this.source?.subscribe(subscriber);\n  }\n\n  /**\n   * An interop point defined by the es7-observable spec https://github.com/zenparsing/es-observable\n   * @method Symbol.observable\n   * @return {Observable} this instance of the observable\n   */\n  [Symbol_observable]() {\n    return this;\n  }\n\n  /* tslint:disable:max-line-length */\n  pipe(): Observable<T>;\n  pipe<A>(op1: OperatorFunction<T, A>): Observable<A>;\n  pipe<A, B>(op1: OperatorFunction<T, A>, op2: OperatorFunction<A, B>): Observable<B>;\n  pipe<A, B, C>(op1: OperatorFunction<T, A>, op2: OperatorFunction<A, B>, op3: OperatorFunction<B, C>): Observable<C>;\n  pipe<A, B, C, D>(\n    op1: OperatorFunction<T, A>,\n    op2: OperatorFunction<A, B>,\n    op3: OperatorFunction<B, C>,\n    op4: OperatorFunction<C, D>\n  ): Observable<D>;\n  pipe<A, B, C, D, E>(\n    op1: OperatorFunction<T, A>,\n    op2: OperatorFunction<A, B>,\n    op3: OperatorFunction<B, C>,\n    op4: OperatorFunction<C, D>,\n    op5: OperatorFunction<D, E>\n  ): Observable<E>;\n  pipe<A, B, C, D, E, F>(\n    op1: OperatorFunction<T, A>,\n    op2: OperatorFunction<A, B>,\n    op3: OperatorFunction<B, C>,\n    op4: OperatorFunction<C, D>,\n    op5: OperatorFunction<D, E>,\n    op6: OperatorFunction<E, F>\n  ): Observable<F>;\n  pipe<A, B, C, D, E, F, G>(\n    op1: OperatorFunction<T, A>,\n    op2: OperatorFunction<A, B>,\n    op3: OperatorFunction<B, C>,\n    op4: OperatorFunction<C, D>,\n    op5: OperatorFunction<D, E>,\n    op6: OperatorFunction<E, F>,\n    op7: OperatorFunction<F, G>\n  ): Observable<G>;\n  pipe<A, B, C, D, E, F, G, H>(\n    op1: OperatorFunction<T, A>,\n    op2: OperatorFunction<A, B>,\n    op3: OperatorFunction<B, C>,\n    op4: OperatorFunction<C, D>,\n    op5: OperatorFunction<D, E>,\n    op6: OperatorFunction<E, F>,\n    op7: OperatorFunction<F, G>,\n    op8: OperatorFunction<G, H>\n  ): Observable<H>;\n  pipe<A, B, C, D, E, F, G, H, I>(\n    op1: OperatorFunction<T, A>,\n    op2: OperatorFunction<A, B>,\n    op3: OperatorFunction<B, C>,\n    op4: OperatorFunction<C, D>,\n    op5: OperatorFunction<D, E>,\n    op6: OperatorFunction<E, F>,\n    op7: OperatorFunction<F, G>,\n    op8: OperatorFunction<G, H>,\n    op9: OperatorFunction<H, I>\n  ): Observable<I>;\n  pipe<A, B, C, D, E, F, G, H, I>(\n    op1: OperatorFunction<T, A>,\n    op2: OperatorFunction<A, B>,\n    op3: OperatorFunction<B, C>,\n    op4: OperatorFunction<C, D>,\n    op5: OperatorFunction<D, E>,\n    op6: OperatorFunction<E, F>,\n    op7: OperatorFunction<F, G>,\n    op8: OperatorFunction<G, H>,\n    op9: OperatorFunction<H, I>,\n    ...operations: OperatorFunction<any, any>[]\n  ): Observable<unknown>;\n  /* tslint:enable:max-line-length */\n\n  /**\n   * Used to stitch together functional operators into a chain.\n   * @method pipe\n   * @return {Observable} the Observable result of all of the operators having\n   * been called in the order they were passed in.\n   *\n   * ## Example\n   *\n   * ```ts\n   * import { interval, filter, map, scan } from 'rxjs';\n   *\n   * interval(1000)\n   *   .pipe(\n   *     filter(x => x % 2 === 0),\n   *     map(x => x + x),\n   *     scan((acc, x) => acc + x)\n   *   )\n   *   .subscribe(x => console.log(x));\n   * ```\n   */\n  pipe(...operations: OperatorFunction<any, any>[]): Observable<any> {\n    return pipeFromArray(operations)(this);\n  }\n\n  /* tslint:disable:max-line-length */\n  /** @deprecated Replaced with {@link firstValueFrom} and {@link lastValueFrom}. Will be removed in v8. Details: https://rxjs.dev/deprecations/to-promise */\n  toPromise(): Promise<T | undefined>;\n  /** @deprecated Replaced with {@link firstValueFrom} and {@link lastValueFrom}. Will be removed in v8. Details: https://rxjs.dev/deprecations/to-promise */\n  toPromise(PromiseCtor: typeof Promise): Promise<T | undefined>;\n  /** @deprecated Replaced with {@link firstValueFrom} and {@link lastValueFrom}. Will be removed in v8. Details: https://rxjs.dev/deprecations/to-promise */\n  toPromise(PromiseCtor: PromiseConstructorLike): Promise<T | undefined>;\n  /* tslint:enable:max-line-length */\n\n  /**\n   * Subscribe to this Observable and get a Promise resolving on\n   * `complete` with the last emission (if any).\n   *\n   * **WARNING**: Only use this with observables you *know* will complete. If the source\n   * observable does not complete, you will end up with a promise that is hung up, and\n   * potentially all of the state of an async function hanging out in memory. To avoid\n   * this situation, look into adding something like {@link timeout}, {@link take},\n   * {@link takeWhile}, or {@link takeUntil} amongst others.\n   *\n   * @method toPromise\n   * @param [promiseCtor] a constructor function used to instantiate\n   * the Promise\n   * @return A Promise that resolves with the last value emit, or\n   * rejects on an error. If there were no emissions, Promise\n   * resolves with undefined.\n   * @deprecated Replaced with {@link firstValueFrom} and {@link lastValueFrom}. Will be removed in v8. Details: https://rxjs.dev/deprecations/to-promise\n   */\n  toPromise(promiseCtor?: PromiseConstructorLike): Promise<T | undefined> {\n    promiseCtor = getPromiseCtor(promiseCtor);\n\n    return new promiseCtor((resolve, reject) => {\n      let value: T | undefined;\n      this.subscribe(\n        (x: T) => (value = x),\n        (err: any) => reject(err),\n        () => resolve(value)\n      );\n    }) as Promise<T | undefined>;\n  }\n}\n\n/**\n * Decides between a passed promise constructor from consuming code,\n * A default configured promise constructor, and the native promise\n * constructor and returns it. If nothing can be found, it will throw\n * an error.\n * @param promiseCtor The optional promise constructor to passed by consuming code\n */\nfunction getPromiseCtor(promiseCtor: PromiseConstructorLike | undefined) {\n  return promiseCtor ?? config.Promise ?? Promise;\n}\n\nfunction isObserver<T>(value: any): value is Observer<T> {\n  return value && isFunction(value.next) && isFunction(value.error) && isFunction(value.complete);\n}\n\nfunction isSubscriber<T>(value: any): value is Subscriber<T> {\n  return (value && value instanceof Subscriber) || (isObserver(value) && isSubscription(value));\n}\n", "import { Observable } from '../Observable';\nimport { Subscriber } from '../Subscriber';\nimport { OperatorFunction } from '../types';\nimport { isFunction } from './isFunction';\n\n/**\n * Used to determine if an object is an Observable with a lift function.\n */\nexport function hasLift(source: any): source is { lift: InstanceType<typeof Observable>['lift'] } {\n  return isFunction(source?.lift);\n}\n\n/**\n * Creates an `OperatorFunction`. Used to define operators throughout the library in a concise way.\n * @param init The logic to connect the liftedSource to the subscriber at the moment of subscription.\n */\nexport function operate<T, R>(\n  init: (liftedSource: Observable<T>, subscriber: Subscriber<R>) => (() => void) | void\n): OperatorFunction<T, R> {\n  return (source: Observable<T>) => {\n    if (hasLift(source)) {\n      return source.lift(function (this: Subscriber<R>, liftedSource: Observable<T>) {\n        try {\n          return init(liftedSource, this);\n        } catch (err) {\n          this.error(err);\n        }\n      });\n    }\n    throw new TypeError('Unable to lift unknown Observable type');\n  };\n}\n", "import { Subscriber } from '../Subscriber';\n\n/**\n * Creates an instance of an `OperatorSubscriber`.\n * @param destination The downstream subscriber.\n * @param onNext Handles next values, only called if this subscriber is not stopped or closed. Any\n * error that occurs in this function is caught and sent to the `error` method of this subscriber.\n * @param onError Handles errors from the subscription, any errors that occur in this handler are caught\n * and send to the `destination` error handler.\n * @param onComplete Handles completion notification from the subscription. Any errors that occur in\n * this handler are sent to the `destination` error handler.\n * @param onFinalize Additional teardown logic here. This will only be called on teardown if the\n * subscriber itself is not already closed. This is called after all other teardown logic is executed.\n */\nexport function createOperatorSubscriber<T>(\n  destination: Subscriber<any>,\n  onNext?: (value: T) => void,\n  onComplete?: () => void,\n  onError?: (err: any) => void,\n  onFinalize?: () => void\n): Subscriber<T> {\n  return new OperatorSubscriber(destination, onNext, onComplete, onError, onFinalize);\n}\n\n/**\n * A generic helper for allowing operators to be created with a Subscriber and\n * use closures to capture necessary state from the operator function itself.\n */\nexport class OperatorSubscriber<T> extends Subscriber<T> {\n  /**\n   * Creates an instance of an `OperatorSubscriber`.\n   * @param destination The downstream subscriber.\n   * @param onNext Handles next values, only called if this subscriber is not stopped or closed. Any\n   * error that occurs in this function is caught and sent to the `error` method of this subscriber.\n   * @param onError Handles errors from the subscription, any errors that occur in this handler are caught\n   * and send to the `destination` error handler.\n   * @param onComplete Handles completion notification from the subscription. Any errors that occur in\n   * this handler are sent to the `destination` error handler.\n   * @param onFinalize Additional finalization logic here. This will only be called on finalization if the\n   * subscriber itself is not already closed. This is called after all other finalization logic is executed.\n   * @param shouldUnsubscribe An optional check to see if an unsubscribe call should truly unsubscribe.\n   * NOTE: This currently **ONLY** exists to support the strange behavior of {@link groupBy}, where unsubscription\n   * to the resulting observable does not actually disconnect from the source if there are active subscriptions\n   * to any grouped observable. (DO NOT EXPOSE OR USE EXTERNALLY!!!)\n   */\n  constructor(\n    destination: Subscriber<any>,\n    onNext?: (value: T) => void,\n    onComplete?: () => void,\n    onError?: (err: any) => void,\n    private onFinalize?: () => void,\n    private shouldUnsubscribe?: () => boolean\n  ) {\n    // It's important - for performance reasons - that all of this class's\n    // members are initialized and that they are always initialized in the same\n    // order. This will ensure that all OperatorSubscriber instances have the\n    // same hidden class in V8. This, in turn, will help keep the number of\n    // hidden classes involved in property accesses within the base class as\n    // low as possible. If the number of hidden classes involved exceeds four,\n    // the property accesses will become megamorphic and performance penalties\n    // will be incurred - i.e. inline caches won't be used.\n    //\n    // The reasons for ensuring all instances have the same hidden class are\n    // further discussed in this blog post from Benedikt Meurer:\n    // https://benediktmeurer.de/2018/03/23/impact-of-polymorphism-on-component-based-frameworks-like-react/\n    super(destination);\n    this._next = onNext\n      ? function (this: OperatorSubscriber<T>, value: T) {\n          try {\n            onNext(value);\n          } catch (err) {\n            destination.error(err);\n          }\n        }\n      : super._next;\n    this._error = onError\n      ? function (this: OperatorSubscriber<T>, err: any) {\n          try {\n            onError(err);\n          } catch (err) {\n            // Send any errors that occur down stream.\n            destination.error(err);\n          } finally {\n            // Ensure finalization.\n            this.unsubscribe();\n          }\n        }\n      : super._error;\n    this._complete = onComplete\n      ? function (this: OperatorSubscriber<T>) {\n          try {\n            onComplete();\n          } catch (err) {\n            // Send any errors that occur down stream.\n            destination.error(err);\n          } finally {\n            // Ensure finalization.\n            this.unsubscribe();\n          }\n        }\n      : super._complete;\n  }\n\n  unsubscribe() {\n    if (!this.shouldUnsubscribe || this.shouldUnsubscribe()) {\n      const { closed } = this;\n      super.unsubscribe();\n      // Execute additional teardown if we have any and we didn't already do so.\n      !closed && this.onFinalize?.();\n    }\n  }\n}\n", "import { Subscription } from '../Subscription';\n\ninterface AnimationFrameProvider {\n  schedule(callback: FrameRequestCallback): Subscription;\n  requestAnimationFrame: typeof requestAnimationFrame;\n  cancelAnimationFrame: typeof cancelAnimationFrame;\n  delegate:\n    | {\n        requestAnimationFrame: typeof requestAnimationFrame;\n        cancelAnimationFrame: typeof cancelAnimationFrame;\n      }\n    | undefined;\n}\n\nexport const animationFrameProvider: AnimationFrameProvider = {\n  // When accessing the delegate, use the variable rather than `this` so that\n  // the functions can be called without being bound to the provider.\n  schedule(callback) {\n    let request = requestAnimationFrame;\n    let cancel: typeof cancelAnimationFrame | undefined = cancelAnimationFrame;\n    const { delegate } = animationFrameProvider;\n    if (delegate) {\n      request = delegate.requestAnimationFrame;\n      cancel = delegate.cancelAnimationFrame;\n    }\n    const handle = request((timestamp) => {\n      // Clear the cancel function. The request has been fulfilled, so\n      // attempting to cancel the request upon unsubscription would be\n      // pointless.\n      cancel = undefined;\n      callback(timestamp);\n    });\n    return new Subscription(() => cancel?.(handle));\n  },\n  requestAnimationFrame(...args) {\n    const { delegate } = animationFrameProvider;\n    return (delegate?.requestAnimationFrame || requestAnimationFrame)(...args);\n  },\n  cancelAnimationFrame(...args) {\n    const { delegate } = animationFrameProvider;\n    return (delegate?.cancelAnimationFrame || cancelAnimationFrame)(...args);\n  },\n  delegate: undefined,\n};\n", "import { createErrorClass } from './createErrorClass';\n\nexport interface ObjectUnsubscribedError extends Error {}\n\nexport interface ObjectUnsubscribedErrorCtor {\n  /**\n   * @deprecated Internal implementation detail. Do not construct error instances.\n   * Cannot be tagged as internal: https://github.com/ReactiveX/rxjs/issues/6269\n   */\n  new (): ObjectUnsubscribedError;\n}\n\n/**\n * An error thrown when an action is invalid because the object has been\n * unsubscribed.\n *\n * @see {@link Subject}\n * @see {@link BehaviorSubject}\n *\n * @class ObjectUnsubscribedError\n */\nexport const ObjectUnsubscribedError: ObjectUnsubscribedErrorCtor = createErrorClass(\n  (_super) =>\n    function ObjectUnsubscribedErrorImpl(this: any) {\n      _super(this);\n      this.name = 'ObjectUnsubscribedError';\n      this.message = 'object unsubscribed';\n    }\n);\n", "import { Operator } from './Operator';\nimport { Observable } from './Observable';\nimport { Subscriber } from './Subscriber';\nimport { Subscription, EMPTY_SUBSCRIPTION } from './Subscription';\nimport { Observer, SubscriptionLike, TeardownLogic } from './types';\nimport { ObjectUnsubscribedError } from './util/ObjectUnsubscribedError';\nimport { arrRemove } from './util/arrRemove';\nimport { errorContext } from './util/errorContext';\n\n/**\n * A Subject is a special type of Observable that allows values to be\n * multicasted to many Observers. Subjects are like EventEmitters.\n *\n * Every Subject is an Observable and an Observer. You can subscribe to a\n * Subject, and you can call next to feed values as well as error and complete.\n */\nexport class Subject<T> extends Observable<T> implements SubscriptionLike {\n  closed = false;\n\n  private currentObservers: Observer<T>[] | null = null;\n\n  /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n  observers: Observer<T>[] = [];\n  /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n  isStopped = false;\n  /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n  hasError = false;\n  /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n  thrownError: any = null;\n\n  /**\n   * Creates a \"subject\" by basically gluing an observer to an observable.\n   *\n   * @nocollapse\n   * @deprecated Recommended you do not use. Will be removed at some point in the future. Plans for replacement still under discussion.\n   */\n  static create: (...args: any[]) => any = <T>(destination: Observer<T>, source: Observable<T>): AnonymousSubject<T> => {\n    return new AnonymousSubject<T>(destination, source);\n  };\n\n  constructor() {\n    // NOTE: This must be here to obscure Observable's constructor.\n    super();\n  }\n\n  /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n  lift<R>(operator: Operator<T, R>): Observable<R> {\n    const subject = new AnonymousSubject(this, this);\n    subject.operator = operator as any;\n    return subject as any;\n  }\n\n  /** @internal */\n  protected _throwIfClosed() {\n    if (this.closed) {\n      throw new ObjectUnsubscribedError();\n    }\n  }\n\n  next(value: T) {\n    errorContext(() => {\n      this._throwIfClosed();\n      if (!this.isStopped) {\n        if (!this.currentObservers) {\n          this.currentObservers = Array.from(this.observers);\n        }\n        for (const observer of this.currentObservers) {\n          observer.next(value);\n        }\n      }\n    });\n  }\n\n  error(err: any) {\n    errorContext(() => {\n      this._throwIfClosed();\n      if (!this.isStopped) {\n        this.hasError = this.isStopped = true;\n        this.thrownError = err;\n        const { observers } = this;\n        while (observers.length) {\n          observers.shift()!.error(err);\n        }\n      }\n    });\n  }\n\n  complete() {\n    errorContext(() => {\n      this._throwIfClosed();\n      if (!this.isStopped) {\n        this.isStopped = true;\n        const { observers } = this;\n        while (observers.length) {\n          observers.shift()!.complete();\n        }\n      }\n    });\n  }\n\n  unsubscribe() {\n    this.isStopped = this.closed = true;\n    this.observers = this.currentObservers = null!;\n  }\n\n  get observed() {\n    return this.observers?.length > 0;\n  }\n\n  /** @internal */\n  protected _trySubscribe(subscriber: Subscriber<T>): TeardownLogic {\n    this._throwIfClosed();\n    return super._trySubscribe(subscriber);\n  }\n\n  /** @internal */\n  protected _subscribe(subscriber: Subscriber<T>): Subscription {\n    this._throwIfClosed();\n    this._checkFinalizedStatuses(subscriber);\n    return this._innerSubscribe(subscriber);\n  }\n\n  /** @internal */\n  protected _innerSubscribe(subscriber: Subscriber<any>) {\n    const { hasError, isStopped, observers } = this;\n    if (hasError || isStopped) {\n      return EMPTY_SUBSCRIPTION;\n    }\n    this.currentObservers = null;\n    observers.push(subscriber);\n    return new Subscription(() => {\n      this.currentObservers = null;\n      arrRemove(observers, subscriber);\n    });\n  }\n\n  /** @internal */\n  protected _checkFinalizedStatuses(subscriber: Subscriber<any>) {\n    const { hasError, thrownError, isStopped } = this;\n    if (hasError) {\n      subscriber.error(thrownError);\n    } else if (isStopped) {\n      subscriber.complete();\n    }\n  }\n\n  /**\n   * Creates a new Observable with this Subject as the source. You can do this\n   * to create custom Observer-side logic of the Subject and conceal it from\n   * code that uses the Observable.\n   * @return {Observable} Observable that the Subject casts to\n   */\n  asObservable(): Observable<T> {\n    const observable: any = new Observable<T>();\n    observable.source = this;\n    return observable;\n  }\n}\n\n/**\n * @class AnonymousSubject<T>\n */\nexport class AnonymousSubject<T> extends Subject<T> {\n  constructor(\n    /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n    public destination?: Observer<T>,\n    source?: Observable<T>\n  ) {\n    super();\n    this.source = source;\n  }\n\n  next(value: T) {\n    this.destination?.next?.(value);\n  }\n\n  error(err: any) {\n    this.destination?.error?.(err);\n  }\n\n  complete() {\n    this.destination?.complete?.();\n  }\n\n  /** @internal */\n  protected _subscribe(subscriber: Subscriber<T>): Subscription {\n    return this.source?.subscribe(subscriber) ?? EMPTY_SUBSCRIPTION;\n  }\n}\n", "import { Subject } from './Subject';\nimport { Subscriber } from './Subscriber';\nimport { Subscription } from './Subscription';\n\n/**\n * A variant of Subject that requires an initial value and emits its current\n * value whenever it is subscribed to.\n *\n * @class BehaviorSubject<T>\n */\nexport class BehaviorSubject<T> extends Subject<T> {\n  constructor(private _value: T) {\n    super();\n  }\n\n  get value(): T {\n    return this.getValue();\n  }\n\n  /** @internal */\n  protected _subscribe(subscriber: Subscriber<T>): Subscription {\n    const subscription = super._subscribe(subscriber);\n    !subscription.closed && subscriber.next(this._value);\n    return subscription;\n  }\n\n  getValue(): T {\n    const { hasError, thrownError, _value } = this;\n    if (hasError) {\n      throw thrownError;\n    }\n    this._throwIfClosed();\n    return _value;\n  }\n\n  next(value: T): void {\n    super.next((this._value = value));\n  }\n}\n", "import { TimestampProvider } from '../types';\n\ninterface DateTimestampProvider extends TimestampProvider {\n  delegate: TimestampProvider | undefined;\n}\n\nexport const dateTimestampProvider: DateTimestampProvider = {\n  now() {\n    // Use the variable rather than `this` so that the function can be called\n    // without being bound to the provider.\n    return (dateTimestampProvider.delegate || Date).now();\n  },\n  delegate: undefined,\n};\n", "import { Subject } from './Subject';\nimport { TimestampProvider } from './types';\nimport { Subscriber } from './Subscriber';\nimport { Subscription } from './Subscription';\nimport { dateTimestampProvider } from './scheduler/dateTimestampProvider';\n\n/**\n * A variant of {@link Subject} that \"replays\" old values to new subscribers by emitting them when they first subscribe.\n *\n * `ReplaySubject` has an internal buffer that will store a specified number of values that it has observed. Like `Subject`,\n * `ReplaySubject` \"observes\" values by having them passed to its `next` method. When it observes a value, it will store that\n * value for a time determined by the configuration of the `ReplaySubject`, as passed to its constructor.\n *\n * When a new subscriber subscribes to the `ReplaySubject` instance, it will synchronously emit all values in its buffer in\n * a First-In-First-Out (FIFO) manner. The `ReplaySubject` will also complete, if it has observed completion; and it will\n * error if it has observed an error.\n *\n * There are two main configuration items to be concerned with:\n *\n * 1. `bufferSize` - This will determine how many items are stored in the buffer, defaults to infinite.\n * 2. `windowTime` - The amount of time to hold a value in the buffer before removing it from the buffer.\n *\n * Both configurations may exist simultaneously. So if you would like to buffer a maximum of 3 values, as long as the values\n * are less than 2 seconds old, you could do so with a `new ReplaySubject(3, 2000)`.\n *\n * ### Differences with BehaviorSubject\n *\n * `BehaviorSubject` is similar to `new ReplaySubject(1)`, with a couple of exceptions:\n *\n * 1. `BehaviorSubject` comes \"primed\" with a single value upon construction.\n * 2. `ReplaySubject` will replay values, even after observing an error, where `BehaviorSubject` will not.\n *\n * @see {@link Subject}\n * @see {@link BehaviorSubject}\n * @see {@link shareReplay}\n */\nexport class ReplaySubject<T> extends Subject<T> {\n  private _buffer: (T | number)[] = [];\n  private _infiniteTimeWindow = true;\n\n  /**\n   * @param bufferSize The size of the buffer to replay on subscription\n   * @param windowTime The amount of time the buffered items will stay buffered\n   * @param timestampProvider An object with a `now()` method that provides the current timestamp. This is used to\n   * calculate the amount of time something has been buffered.\n   */\n  constructor(\n    private _bufferSize = Infinity,\n    private _windowTime = Infinity,\n    private _timestampProvider: TimestampProvider = dateTimestampProvider\n  ) {\n    super();\n    this._infiniteTimeWindow = _windowTime === Infinity;\n    this._bufferSize = Math.max(1, _bufferSize);\n    this._windowTime = Math.max(1, _windowTime);\n  }\n\n  next(value: T): void {\n    const { isStopped, _buffer, _infiniteTimeWindow, _timestampProvider, _windowTime } = this;\n    if (!isStopped) {\n      _buffer.push(value);\n      !_infiniteTimeWindow && _buffer.push(_timestampProvider.now() + _windowTime);\n    }\n    this._trimBuffer();\n    super.next(value);\n  }\n\n  /** @internal */\n  protected _subscribe(subscriber: Subscriber<T>): Subscription {\n    this._throwIfClosed();\n    this._trimBuffer();\n\n    const subscription = this._innerSubscribe(subscriber);\n\n    const { _infiniteTimeWindow, _buffer } = this;\n    // We use a copy here, so reentrant code does not mutate our array while we're\n    // emitting it to a new subscriber.\n    const copy = _buffer.slice();\n    for (let i = 0; i < copy.length && !subscriber.closed; i += _infiniteTimeWindow ? 1 : 2) {\n      subscriber.next(copy[i] as T);\n    }\n\n    this._checkFinalizedStatuses(subscriber);\n\n    return subscription;\n  }\n\n  private _trimBuffer() {\n    const { _bufferSize, _timestampProvider, _buffer, _infiniteTimeWindow } = this;\n    // If we don't have an infinite buffer size, and we're over the length,\n    // use splice to truncate the old buffer values off. Note that we have to\n    // double the size for instances where we're not using an infinite time window\n    // because we're storing the values and the timestamps in the same array.\n    const adjustedBufferSize = (_infiniteTimeWindow ? 1 : 2) * _bufferSize;\n    _bufferSize < Infinity && adjustedBufferSize < _buffer.length && _buffer.splice(0, _buffer.length - adjustedBufferSize);\n\n    // Now, if we're not in an infinite time window, remove all values where the time is\n    // older than what is allowed.\n    if (!_infiniteTimeWindow) {\n      const now = _timestampProvider.now();\n      let last = 0;\n      // Search the array for the first timestamp that isn't expired and\n      // truncate the buffer up to that point.\n      for (let i = 1; i < _buffer.length && (_buffer[i] as number) <= now; i += 2) {\n        last = i;\n      }\n      last && _buffer.splice(0, last + 1);\n    }\n  }\n}\n", "import { Scheduler } from '../Scheduler';\nimport { Subscription } from '../Subscription';\nimport { SchedulerAction } from '../types';\n\n/**\n * A unit of work to be executed in a `scheduler`. An action is typically\n * created from within a {@link SchedulerLike} and an RxJS user does not need to concern\n * themselves about creating and manipulating an Action.\n *\n * ```ts\n * class Action<T> extends Subscription {\n *   new (scheduler: Scheduler, work: (state?: T) => void);\n *   schedule(state?: T, delay: number = 0): Subscription;\n * }\n * ```\n *\n * @class Action<T>\n */\nexport class Action<T> extends Subscription {\n  constructor(scheduler: Scheduler, work: (this: SchedulerAction<T>, state?: T) => void) {\n    super();\n  }\n  /**\n   * Schedules this action on its parent {@link SchedulerLike} for execution. May be passed\n   * some context object, `state`. May happen at some point in the future,\n   * according to the `delay` parameter, if specified.\n   * @param {T} [state] Some contextual data that the `work` function uses when\n   * called by the Scheduler.\n   * @param {number} [delay] Time to wait before executing the work, where the\n   * time unit is implicit and defined by the Scheduler.\n   * @return {void}\n   */\n  public schedule(state?: T, delay: number = 0): Subscription {\n    return this;\n  }\n}\n", "import type { TimerHandle } from './timerHandle';\ntype SetIntervalFunction = (handler: () => void, timeout?: number, ...args: any[]) => TimerHandle;\ntype ClearIntervalFunction = (handle: TimerHandle) => void;\n\ninterface IntervalProvider {\n  setInterval: SetIntervalFunction;\n  clearInterval: ClearIntervalFunction;\n  delegate:\n    | {\n        setInterval: SetIntervalFunction;\n        clearInterval: ClearIntervalFunction;\n      }\n    | undefined;\n}\n\nexport const intervalProvider: IntervalProvider = {\n  // When accessing the delegate, use the variable rather than `this` so that\n  // the functions can be called without being bound to the provider.\n  setInterval(handler: () => void, timeout?: number, ...args) {\n    const { delegate } = intervalProvider;\n    if (delegate?.setInterval) {\n      return delegate.setInterval(handler, timeout, ...args);\n    }\n    return setInterval(handler, timeout, ...args);\n  },\n  clearInterval(handle) {\n    const { delegate } = intervalProvider;\n    return (delegate?.clearInterval || clearInterval)(handle as any);\n  },\n  delegate: undefined,\n};\n", "import { Action } from './Action';\nimport { SchedulerAction } from '../types';\nimport { Subscription } from '../Subscription';\nimport { AsyncScheduler } from './AsyncScheduler';\nimport { intervalProvider } from './intervalProvider';\nimport { arrRemove } from '../util/arrRemove';\nimport { TimerHandle } from './timerHandle';\n\nexport class AsyncAction<T> extends Action<T> {\n  public id: TimerHandle | undefined;\n  public state?: T;\n  // @ts-ignore: Property has no initializer and is not definitely assigned\n  public delay: number;\n  protected pending: boolean = false;\n\n  constructor(protected scheduler: AsyncScheduler, protected work: (this: SchedulerAction<T>, state?: T) => void) {\n    super(scheduler, work);\n  }\n\n  public schedule(state?: T, delay: number = 0): Subscription {\n    if (this.closed) {\n      return this;\n    }\n\n    // Always replace the current state with the new state.\n    this.state = state;\n\n    const id = this.id;\n    const scheduler = this.scheduler;\n\n    //\n    // Important implementation note:\n    //\n    // Actions only execute once by default, unless rescheduled from within the\n    // scheduled callback. This allows us to implement single and repeat\n    // actions via the same code path, without adding API surface area, as well\n    // as mimic traditional recursion but across asynchronous boundaries.\n    //\n    // However, JS runtimes and timers distinguish between intervals achieved by\n    // serial `setTimeout` calls vs. a single `setInterval` call. An interval of\n    // serial `setTimeout` calls can be individually delayed, which delays\n    // scheduling the next `setTimeout`, and so on. `setInterval` attempts to\n    // guarantee the interval callback will be invoked more precisely to the\n    // interval period, regardless of load.\n    //\n    // Therefore, we use `setInterval` to schedule single and repeat actions.\n    // If the action reschedules itself with the same delay, the interval is not\n    // canceled. If the action doesn't reschedule, or reschedules with a\n    // different delay, the interval will be canceled after scheduled callback\n    // execution.\n    //\n    if (id != null) {\n      this.id = this.recycleAsyncId(scheduler, id, delay);\n    }\n\n    // Set the pending flag indicating that this action has been scheduled, or\n    // has recursively rescheduled itself.\n    this.pending = true;\n\n    this.delay = delay;\n    // If this action has already an async Id, don't request a new one.\n    this.id = this.id ?? this.requestAsyncId(scheduler, this.id, delay);\n\n    return this;\n  }\n\n  protected requestAsyncId(scheduler: AsyncScheduler, _id?: TimerHandle, delay: number = 0): TimerHandle {\n    return intervalProvider.setInterval(scheduler.flush.bind(scheduler, this), delay);\n  }\n\n  protected recycleAsyncId(_scheduler: AsyncScheduler, id?: TimerHandle, delay: number | null = 0): TimerHandle | undefined {\n    // If this action is rescheduled with the same delay time, don't clear the interval id.\n    if (delay != null && this.delay === delay && this.pending === false) {\n      return id;\n    }\n    // Otherwise, if the action's delay time is different from the current delay,\n    // or the action has been rescheduled before it's executed, clear the interval id\n    if (id != null) {\n      intervalProvider.clearInterval(id);\n    }\n\n    return undefined;\n  }\n\n  /**\n   * Immediately executes this action and the `work` it contains.\n   * @return {any}\n   */\n  public execute(state: T, delay: number): any {\n    if (this.closed) {\n      return new Error('executing a cancelled action');\n    }\n\n    this.pending = false;\n    const error = this._execute(state, delay);\n    if (error) {\n      return error;\n    } else if (this.pending === false && this.id != null) {\n      // Dequeue if the action didn't reschedule itself. Don't call\n      // unsubscribe(), because the action could reschedule later.\n      // For example:\n      // ```\n      // scheduler.schedule(function doWork(counter) {\n      //   /* ... I'm a busy worker bee ... */\n      //   var originalAction = this;\n      //   /* wait 100ms before rescheduling the action */\n      //   setTimeout(function () {\n      //     originalAction.schedule(counter + 1);\n      //   }, 100);\n      // }, 1000);\n      // ```\n      this.id = this.recycleAsyncId(this.scheduler, this.id, null);\n    }\n  }\n\n  protected _execute(state: T, _delay: number): any {\n    let errored: boolean = false;\n    let errorValue: any;\n    try {\n      this.work(state);\n    } catch (e) {\n      errored = true;\n      // HACK: Since code elsewhere is relying on the \"truthiness\" of the\n      // return here, we can't have it return \"\" or 0 or false.\n      // TODO: Clean this up when we refactor schedulers mid-version-8 or so.\n      errorValue = e ? e : new Error('Scheduled action threw falsy error');\n    }\n    if (errored) {\n      this.unsubscribe();\n      return errorValue;\n    }\n  }\n\n  unsubscribe() {\n    if (!this.closed) {\n      const { id, scheduler } = this;\n      const { actions } = scheduler;\n\n      this.work = this.state = this.scheduler = null!;\n      this.pending = false;\n\n      arrRemove(actions, this);\n      if (id != null) {\n        this.id = this.recycleAsyncId(scheduler, id, null);\n      }\n\n      this.delay = null!;\n      super.unsubscribe();\n    }\n  }\n}\n", "import { Action } from './scheduler/Action';\nimport { Subscription } from './Subscription';\nimport { SchedulerLike, SchedulerAction } from './types';\nimport { dateTimestampProvider } from './scheduler/dateTimestampProvider';\n\n/**\n * An execution context and a data structure to order tasks and schedule their\n * execution. Provides a notion of (potentially virtual) time, through the\n * `now()` getter method.\n *\n * Each unit of work in a Scheduler is called an `Action`.\n *\n * ```ts\n * class Scheduler {\n *   now(): number;\n *   schedule(work, delay?, state?): Subscription;\n * }\n * ```\n *\n * @class Scheduler\n * @deprecated Scheduler is an internal implementation detail of RxJS, and\n * should not be used directly. Rather, create your own class and implement\n * {@link SchedulerLike}. Will be made internal in v8.\n */\nexport class Scheduler implements SchedulerLike {\n  public static now: () => number = dateTimestampProvider.now;\n\n  constructor(private schedulerActionCtor: typeof Action, now: () => number = Scheduler.now) {\n    this.now = now;\n  }\n\n  /**\n   * A getter method that returns a number representing the current time\n   * (at the time this function was called) according to the scheduler's own\n   * internal clock.\n   * @return {number} A number that represents the current time. May or may not\n   * have a relation to wall-clock time. May or may not refer to a time unit\n   * (e.g. milliseconds).\n   */\n  public now: () => number;\n\n  /**\n   * Schedules a function, `work`, for execution. May happen at some point in\n   * the future, according to the `delay` parameter, if specified. May be passed\n   * some context object, `state`, which will be passed to the `work` function.\n   *\n   * The given arguments will be processed an stored as an Action object in a\n   * queue of actions.\n   *\n   * @param {function(state: ?T): ?Subscription} work A function representing a\n   * task, or some unit of work to be executed by the Scheduler.\n   * @param {number} [delay] Time to wait before executing the work, where the\n   * time unit is implicit and defined by the Scheduler itself.\n   * @param {T} [state] Some contextual data that the `work` function uses when\n   * called by the Scheduler.\n   * @return {Subscription} A subscription in order to be able to unsubscribe\n   * the scheduled work.\n   */\n  public schedule<T>(work: (this: SchedulerAction<T>, state?: T) => void, delay: number = 0, state?: T): Subscription {\n    return new this.schedulerActionCtor<T>(this, work).schedule(state, delay);\n  }\n}\n", "import { Scheduler } from '../Scheduler';\nimport { Action } from './Action';\nimport { AsyncAction } from './AsyncAction';\nimport { TimerHandle } from './timerHandle';\n\nexport class AsyncScheduler extends Scheduler {\n  public actions: Array<AsyncAction<any>> = [];\n  /**\n   * A flag to indicate whether the Scheduler is currently executing a batch of\n   * queued actions.\n   * @type {boolean}\n   * @internal\n   */\n  public _active: boolean = false;\n  /**\n   * An internal ID used to track the latest asynchronous task such as those\n   * coming from `setTimeout`, `setInterval`, `requestAnimationFrame`, and\n   * others.\n   * @type {any}\n   * @internal\n   */\n  public _scheduled: TimerHandle | undefined;\n\n  constructor(SchedulerAction: typeof Action, now: () => number = Scheduler.now) {\n    super(SchedulerAction, now);\n  }\n\n  public flush(action: AsyncAction<any>): void {\n    const { actions } = this;\n\n    if (this._active) {\n      actions.push(action);\n      return;\n    }\n\n    let error: any;\n    this._active = true;\n\n    do {\n      if ((error = action.execute(action.state, action.delay))) {\n        break;\n      }\n    } while ((action = actions.shift()!)); // exhaust the scheduler queue\n\n    this._active = false;\n\n    if (error) {\n      while ((action = actions.shift()!)) {\n        action.unsubscribe();\n      }\n      throw error;\n    }\n  }\n}\n", "import { AsyncAction } from './AsyncAction';\nimport { AsyncScheduler } from './AsyncScheduler';\n\n/**\n *\n * Async Scheduler\n *\n * <span class=\"informal\">Schedule task as if you used setTimeout(task, duration)</span>\n *\n * `async` scheduler schedules tasks asynchronously, by putting them on the JavaScript\n * event loop queue. It is best used to delay tasks in time or to schedule tasks repeating\n * in intervals.\n *\n * If you just want to \"defer\" task, that is to perform it right after currently\n * executing synchronous code ends (commonly achieved by `setTimeout(deferredTask, 0)`),\n * better choice will be the {@link asapScheduler} scheduler.\n *\n * ## Examples\n * Use async scheduler to delay task\n * ```ts\n * import { asyncScheduler } from 'rxjs';\n *\n * const task = () => console.log('it works!');\n *\n * asyncScheduler.schedule(task, 2000);\n *\n * // After 2 seconds logs:\n * // \"it works!\"\n * ```\n *\n * Use async scheduler to repeat task in intervals\n * ```ts\n * import { asyncScheduler } from 'rxjs';\n *\n * function task(state) {\n *   console.log(state);\n *   this.schedule(state + 1, 1000); // `this` references currently executing Action,\n *                                   // which we reschedule with new state and delay\n * }\n *\n * asyncScheduler.schedule(task, 3000, 0);\n *\n * // Logs:\n * // 0 after 3s\n * // 1 after 4s\n * // 2 after 5s\n * // 3 after 6s\n * ```\n */\n\nexport const asyncScheduler = new AsyncScheduler(AsyncAction);\n\n/**\n * @deprecated Renamed to {@link asyncScheduler}. Will be removed in v8.\n */\nexport const async = asyncScheduler;\n", "import { AsyncAction } from './AsyncAction';\nimport { Subscription } from '../Subscription';\nimport { QueueScheduler } from './QueueScheduler';\nimport { SchedulerAction } from '../types';\nimport { TimerHandle } from './timerHandle';\n\nexport class QueueAction<T> extends AsyncAction<T> {\n  constructor(protected scheduler: QueueScheduler, protected work: (this: SchedulerAction<T>, state?: T) => void) {\n    super(scheduler, work);\n  }\n\n  public schedule(state?: T, delay: number = 0): Subscription {\n    if (delay > 0) {\n      return super.schedule(state, delay);\n    }\n    this.delay = delay;\n    this.state = state;\n    this.scheduler.flush(this);\n    return this;\n  }\n\n  public execute(state: T, delay: number): any {\n    return delay > 0 || this.closed ? super.execute(state, delay) : this._execute(state, delay);\n  }\n\n  protected requestAsyncId(scheduler: QueueScheduler, id?: TimerHandle, delay: number = 0): TimerHandle {\n    // If delay exists and is greater than 0, or if the delay is null (the\n    // action wasn't rescheduled) but was originally scheduled as an async\n    // action, then recycle as an async action.\n\n    if ((delay != null && delay > 0) || (delay == null && this.delay > 0)) {\n      return super.requestAsyncId(scheduler, id, delay);\n    }\n\n    // Otherwise flush the scheduler starting with this action.\n    scheduler.flush(this);\n\n    // HACK: In the past, this was returning `void`. However, `void` isn't a valid\n    // `TimerHandle`, and generally the return value here isn't really used. So the\n    // compromise is to return `0` which is both \"falsy\" and a valid `TimerHandle`,\n    // as opposed to refactoring every other instanceo of `requestAsyncId`.\n    return 0;\n  }\n}\n", "import { AsyncScheduler } from './AsyncScheduler';\n\nexport class QueueScheduler extends AsyncScheduler {\n}\n", "import { QueueAction } from './QueueAction';\nimport { QueueScheduler } from './QueueScheduler';\n\n/**\n *\n * Queue Scheduler\n *\n * <span class=\"informal\">Put every next task on a queue, instead of executing it immediately</span>\n *\n * `queue` scheduler, when used with delay, behaves the same as {@link asyncScheduler} scheduler.\n *\n * When used without delay, it schedules given task synchronously - executes it right when\n * it is scheduled. However when called recursively, that is when inside the scheduled task,\n * another task is scheduled with queue scheduler, instead of executing immediately as well,\n * that task will be put on a queue and wait for current one to finish.\n *\n * This means that when you execute task with `queue` scheduler, you are sure it will end\n * before any other task scheduled with that scheduler will start.\n *\n * ## Examples\n * Schedule recursively first, then do something\n * ```ts\n * import { queueScheduler } from 'rxjs';\n *\n * queueScheduler.schedule(() => {\n *   queueScheduler.schedule(() => console.log('second')); // will not happen now, but will be put on a queue\n *\n *   console.log('first');\n * });\n *\n * // Logs:\n * // \"first\"\n * // \"second\"\n * ```\n *\n * Reschedule itself recursively\n * ```ts\n * import { queueScheduler } from 'rxjs';\n *\n * queueScheduler.schedule(function(state) {\n *   if (state !== 0) {\n *     console.log('before', state);\n *     this.schedule(state - 1); // `this` references currently executing Action,\n *                               // which we reschedule with new state\n *     console.log('after', state);\n *   }\n * }, 0, 3);\n *\n * // In scheduler that runs recursively, you would expect:\n * // \"before\", 3\n * // \"before\", 2\n * // \"before\", 1\n * // \"after\", 1\n * // \"after\", 2\n * // \"after\", 3\n *\n * // But with queue it logs:\n * // \"before\", 3\n * // \"after\", 3\n * // \"before\", 2\n * // \"after\", 2\n * // \"before\", 1\n * // \"after\", 1\n * ```\n */\n\nexport const queueScheduler = new QueueScheduler(QueueAction);\n\n/**\n * @deprecated Renamed to {@link queueScheduler}. Will be removed in v8.\n */\nexport const queue = queueScheduler;\n", "import { AsyncAction } from './AsyncAction';\nimport { AnimationFrameScheduler } from './AnimationFrameScheduler';\nimport { SchedulerAction } from '../types';\nimport { animationFrameProvider } from './animationFrameProvider';\nimport { TimerHandle } from './timerHandle';\n\nexport class AnimationFrameAction<T> extends AsyncAction<T> {\n  constructor(protected scheduler: AnimationFrameScheduler, protected work: (this: SchedulerAction<T>, state?: T) => void) {\n    super(scheduler, work);\n  }\n\n  protected requestAsyncId(scheduler: AnimationFrameScheduler, id?: TimerHandle, delay: number = 0): TimerHandle {\n    // If delay is greater than 0, request as an async action.\n    if (delay !== null && delay > 0) {\n      return super.requestAsyncId(scheduler, id, delay);\n    }\n    // Push the action to the end of the scheduler queue.\n    scheduler.actions.push(this);\n    // If an animation frame has already been requested, don't request another\n    // one. If an animation frame hasn't been requested yet, request one. Return\n    // the current animation frame request id.\n    return scheduler._scheduled || (scheduler._scheduled = animationFrameProvider.requestAnimationFrame(() => scheduler.flush(undefined)));\n  }\n\n  protected recycleAsyncId(scheduler: AnimationFrameScheduler, id?: TimerHandle, delay: number = 0): TimerHandle | undefined {\n    // If delay exists and is greater than 0, or if the delay is null (the\n    // action wasn't rescheduled) but was originally scheduled as an async\n    // action, then recycle as an async action.\n    if (delay != null ? delay > 0 : this.delay > 0) {\n      return super.recycleAsyncId(scheduler, id, delay);\n    }\n    // If the scheduler queue has no remaining actions with the same async id,\n    // cancel the requested animation frame and set the scheduled flag to\n    // undefined so the next AnimationFrameAction will request its own.\n    const { actions } = scheduler;\n    if (id != null && actions[actions.length - 1]?.id !== id) {\n      animationFrameProvider.cancelAnimationFrame(id as number);\n      scheduler._scheduled = undefined;\n    }\n    // Return undefined so the action knows to request a new async id if it's rescheduled.\n    return undefined;\n  }\n}\n", "import { AsyncAction } from './AsyncAction';\nimport { AsyncScheduler } from './AsyncScheduler';\n\nexport class AnimationFrameScheduler extends AsyncScheduler {\n  public flush(action?: AsyncAction<any>): void {\n    this._active = true;\n    // The async id that effects a call to flush is stored in _scheduled.\n    // Before executing an action, it's necessary to check the action's async\n    // id to determine whether it's supposed to be executed in the current\n    // flush.\n    // Previous implementations of this method used a count to determine this,\n    // but that was unsound, as actions that are unsubscribed - i.e. cancelled -\n    // are removed from the actions array and that can shift actions that are\n    // scheduled to be executed in a subsequent flush into positions at which\n    // they are executed within the current flush.\n    const flushId = this._scheduled;\n    this._scheduled = undefined;\n\n    const { actions } = this;\n    let error: any;\n    action = action || actions.shift()!;\n\n    do {\n      if ((error = action.execute(action.state, action.delay))) {\n        break;\n      }\n    } while ((action = actions[0]) && action.id === flushId && actions.shift());\n\n    this._active = false;\n\n    if (error) {\n      while ((action = actions[0]) && action.id === flushId && actions.shift()) {\n        action.unsubscribe();\n      }\n      throw error;\n    }\n  }\n}\n", "import { AnimationFrameAction } from './AnimationFrameAction';\nimport { AnimationFrameScheduler } from './AnimationFrameScheduler';\n\n/**\n *\n * Animation Frame Scheduler\n *\n * <span class=\"informal\">Perform task when `window.requestAnimationFrame` would fire</span>\n *\n * When `animationFrame` scheduler is used with delay, it will fall back to {@link asyncScheduler} scheduler\n * behaviour.\n *\n * Without delay, `animationFrame` scheduler can be used to create smooth browser animations.\n * It makes sure scheduled task will happen just before next browser content repaint,\n * thus performing animations as efficiently as possible.\n *\n * ## Example\n * Schedule div height animation\n * ```ts\n * // html: <div style=\"background: #0ff;\"></div>\n * import { animationFrameScheduler } from 'rxjs';\n *\n * const div = document.querySelector('div');\n *\n * animationFrameScheduler.schedule(function(height) {\n *   div.style.height = height + \"px\";\n *\n *   this.schedule(height + 1);  // `this` references currently executing Action,\n *                               // which we reschedule with new state\n * }, 0, 0);\n *\n * // You will see a div element growing in height\n * ```\n */\n\nexport const animationFrameScheduler = new AnimationFrameScheduler(AnimationFrameAction);\n\n/**\n * @deprecated Renamed to {@link animationFrameScheduler}. Will be removed in v8.\n */\nexport const animationFrame = animationFrameScheduler;\n", "import { Observable } from '../Observable';\nimport { SchedulerLike } from '../types';\n\n/**\n * A simple Observable that emits no items to the Observer and immediately\n * emits a complete notification.\n *\n * <span class=\"informal\">Just emits 'complete', and nothing else.</span>\n *\n * ![](empty.png)\n *\n * A simple Observable that only emits the complete notification. It can be used\n * for composing with other Observables, such as in a {@link mergeMap}.\n *\n * ## Examples\n *\n * Log complete notification\n *\n * ```ts\n * import { EMPTY } from 'rxjs';\n *\n * EMPTY.subscribe({\n *   next: () => console.log('Next'),\n *   complete: () => console.log('Complete!')\n * });\n *\n * // Outputs\n * // Complete!\n * ```\n *\n * Emit the number 7, then complete\n *\n * ```ts\n * import { EMPTY, startWith } from 'rxjs';\n *\n * const result = EMPTY.pipe(startWith(7));\n * result.subscribe(x => console.log(x));\n *\n * // Outputs\n * // 7\n * ```\n *\n * Map and flatten only odd numbers to the sequence `'a'`, `'b'`, `'c'`\n *\n * ```ts\n * import { interval, mergeMap, of, EMPTY } from 'rxjs';\n *\n * const interval$ = interval(1000);\n * const result = interval$.pipe(\n *   mergeMap(x => x % 2 === 1 ? of('a', 'b', 'c') : EMPTY),\n * );\n * result.subscribe(x => console.log(x));\n *\n * // Results in the following to the console:\n * // x is equal to the count on the interval, e.g. (0, 1, 2, 3, ...)\n * // x will occur every 1000ms\n * // if x % 2 is equal to 1, print a, b, c (each on its own)\n * // if x % 2 is not equal to 1, nothing will be output\n * ```\n *\n * @see {@link Observable}\n * @see {@link NEVER}\n * @see {@link of}\n * @see {@link throwError}\n */\nexport const EMPTY = new Observable<never>((subscriber) => subscriber.complete());\n\n/**\n * @param scheduler A {@link SchedulerLike} to use for scheduling\n * the emission of the complete notification.\n * @deprecated Replaced with the {@link EMPTY} constant or {@link scheduled} (e.g. `scheduled([], scheduler)`). Will be removed in v8.\n */\nexport function empty(scheduler?: SchedulerLike) {\n  return scheduler ? emptyScheduled(scheduler) : EMPTY;\n}\n\nfunction emptyScheduled(scheduler: SchedulerLike) {\n  return new Observable<never>((subscriber) => scheduler.schedule(() => subscriber.complete()));\n}\n", "import { SchedulerLike } from '../types';\nimport { isFunction } from './isFunction';\n\nexport function isScheduler(value: any): value is SchedulerLike {\n  return value && isFunction(value.schedule);\n}\n", "import { SchedulerLike } from '../types';\nimport { isFunction } from './isFunction';\nimport { isScheduler } from './isScheduler';\n\nfunction last<T>(arr: T[]): T | undefined {\n  return arr[arr.length - 1];\n}\n\nexport function popResultSelector(args: any[]): ((...args: unknown[]) => unknown) | undefined {\n  return isFunction(last(args)) ? args.pop() : undefined;\n}\n\nexport function popScheduler(args: any[]): SchedulerLike | undefined {\n  return isScheduler(last(args)) ? args.pop() : undefined;\n}\n\nexport function popNumber(args: any[], defaultValue: number): number {\n  return typeof last(args) === 'number' ? args.pop()! : defaultValue;\n}\n", "export const isArrayLike = (<T>(x: any): x is ArrayLike<T> => x && typeof x.length === 'number' && typeof x !== 'function');", "import { isFunction } from \"./isFunction\";\n\n/**\n * Tests to see if the object is \"thennable\".\n * @param value the object to test\n */\nexport function isPromise(value: any): value is PromiseLike<any> {\n  return isFunction(value?.then);\n}\n", "import { InteropObservable } from '../types';\nimport { observable as Symbol_observable } from '../symbol/observable';\nimport { isFunction } from './isFunction';\n\n/** Identifies an input as being Observable (but not necessary an Rx Observable) */\nexport function isInteropObservable(input: any): input is InteropObservable<any> {\n  return isFunction(input[Symbol_observable]);\n}\n", "import { isFunction } from './isFunction';\n\nexport function isAsyncIterable<T>(obj: any): obj is AsyncIterable<T> {\n  return Symbol.asyncIterator && isFunction(obj?.[Symbol.asyncIterator]);\n}\n", "/**\n * Creates the TypeError to throw if an invalid object is passed to `from` or `scheduled`.\n * @param input The object that was passed.\n */\nexport function createInvalidObservableTypeError(input: any) {\n  // TODO: We should create error codes that can be looked up, so this can be less verbose.\n  return new TypeError(\n    `You provided ${\n      input !== null && typeof input === 'object' ? 'an invalid object' : `'${input}'`\n    } where a stream was expected. You can provide an Observable, Promise, ReadableStream, Array, AsyncIterable, or Iterable.`\n  );\n}\n", "export function getSymbolIterator(): symbol {\n  if (typeof Symbol !== 'function' || !Symbol.iterator) {\n    return '@@iterator' as any;\n  }\n\n  return Symbol.iterator;\n}\n\nexport const iterator = getSymbolIterator();\n", "import { iterator as Symbol_iterator } from '../symbol/iterator';\nimport { isFunction } from './isFunction';\n\n/** Identifies an input as being an Iterable */\nexport function isIterable(input: any): input is Iterable<any> {\n  return isFunction(input?.[Symbol_iterator]);\n}\n", "import { ReadableStreamLike } from '../types';\nimport { isFunction } from './isFunction';\n\nexport async function* readableStreamLikeToAsyncGenerator<T>(readableStream: ReadableStreamLike<T>): AsyncGenerator<T> {\n  const reader = readableStream.getReader();\n  try {\n    while (true) {\n      const { value, done } = await reader.read();\n      if (done) {\n        return;\n      }\n      yield value!;\n    }\n  } finally {\n    reader.releaseLock();\n  }\n}\n\nexport function isReadableStreamLike<T>(obj: any): obj is ReadableStreamLike<T> {\n  // We don't want to use instanceof checks because they would return\n  // false for instances from another Realm, like an <iframe>.\n  return isFunction(obj?.getReader);\n}\n", "import { isArrayLike } from '../util/isArrayLike';\nimport { isPromise } from '../util/isPromise';\nimport { Observable } from '../Observable';\nimport { ObservableInput, ObservedValueOf, ReadableStreamLike } from '../types';\nimport { isInteropObservable } from '../util/isInteropObservable';\nimport { isAsyncIterable } from '../util/isAsyncIterable';\nimport { createInvalidObservableTypeError } from '../util/throwUnobservableError';\nimport { isIterable } from '../util/isIterable';\nimport { isReadableStreamLike, readableStreamLikeToAsyncGenerator } from '../util/isReadableStreamLike';\nimport { Subscriber } from '../Subscriber';\nimport { isFunction } from '../util/isFunction';\nimport { reportUnhandledError } from '../util/reportUnhandledError';\nimport { observable as Symbol_observable } from '../symbol/observable';\n\nexport function innerFrom<O extends ObservableInput<any>>(input: O): Observable<ObservedValueOf<O>>;\nexport function innerFrom<T>(input: ObservableInput<T>): Observable<T> {\n  if (input instanceof Observable) {\n    return input;\n  }\n  if (input != null) {\n    if (isInteropObservable(input)) {\n      return fromInteropObservable(input);\n    }\n    if (isArrayLike(input)) {\n      return fromArrayLike(input);\n    }\n    if (isPromise(input)) {\n      return fromPromise(input);\n    }\n    if (isAsyncIterable(input)) {\n      return fromAsyncIterable(input);\n    }\n    if (isIterable(input)) {\n      return fromIterable(input);\n    }\n    if (isReadableStreamLike(input)) {\n      return fromReadableStreamLike(input);\n    }\n  }\n\n  throw createInvalidObservableTypeError(input);\n}\n\n/**\n * Creates an RxJS Observable from an object that implements `Symbol.observable`.\n * @param obj An object that properly implements `Symbol.observable`.\n */\nexport function fromInteropObservable<T>(obj: any) {\n  return new Observable((subscriber: Subscriber<T>) => {\n    const obs = obj[Symbol_observable]();\n    if (isFunction(obs.subscribe)) {\n      return obs.subscribe(subscriber);\n    }\n    // Should be caught by observable subscribe function error handling.\n    throw new TypeError('Provided object does not correctly implement Symbol.observable');\n  });\n}\n\n/**\n * Synchronously emits the values of an array like and completes.\n * This is exported because there are creation functions and operators that need to\n * make direct use of the same logic, and there's no reason to make them run through\n * `from` conditionals because we *know* they're dealing with an array.\n * @param array The array to emit values from\n */\nexport function fromArrayLike<T>(array: ArrayLike<T>) {\n  return new Observable((subscriber: Subscriber<T>) => {\n    // Loop over the array and emit each value. Note two things here:\n    // 1. We're making sure that the subscriber is not closed on each loop.\n    //    This is so we don't continue looping over a very large array after\n    //    something like a `take`, `takeWhile`, or other synchronous unsubscription\n    //    has already unsubscribed.\n    // 2. In this form, reentrant code can alter that array we're looping over.\n    //    This is a known issue, but considered an edge case. The alternative would\n    //    be to copy the array before executing the loop, but this has\n    //    performance implications.\n    for (let i = 0; i < array.length && !subscriber.closed; i++) {\n      subscriber.next(array[i]);\n    }\n    subscriber.complete();\n  });\n}\n\nexport function fromPromise<T>(promise: PromiseLike<T>) {\n  return new Observable((subscriber: Subscriber<T>) => {\n    promise\n      .then(\n        (value) => {\n          if (!subscriber.closed) {\n            subscriber.next(value);\n            subscriber.complete();\n          }\n        },\n        (err: any) => subscriber.error(err)\n      )\n      .then(null, reportUnhandledError);\n  });\n}\n\nexport function fromIterable<T>(iterable: Iterable<T>) {\n  return new Observable((subscriber: Subscriber<T>) => {\n    for (const value of iterable) {\n      subscriber.next(value);\n      if (subscriber.closed) {\n        return;\n      }\n    }\n    subscriber.complete();\n  });\n}\n\nexport function fromAsyncIterable<T>(asyncIterable: AsyncIterable<T>) {\n  return new Observable((subscriber: Subscriber<T>) => {\n    process(asyncIterable, subscriber).catch((err) => subscriber.error(err));\n  });\n}\n\nexport function fromReadableStreamLike<T>(readableStream: ReadableStreamLike<T>) {\n  return fromAsyncIterable(readableStreamLikeToAsyncGenerator(readableStream));\n}\n\nasync function process<T>(asyncIterable: AsyncIterable<T>, subscriber: Subscriber<T>) {\n  for await (const value of asyncIterable) {\n    subscriber.next(value);\n    // A side-effect may have closed our subscriber,\n    // check before the next iteration.\n    if (subscriber.closed) {\n      return;\n    }\n  }\n  subscriber.complete();\n}\n", "import { Subscription } from '../Subscription';\nimport { SchedulerAction, SchedulerLike } from '../types';\n\nexport function executeSchedule(\n  parentSubscription: Subscription,\n  scheduler: SchedulerLike,\n  work: () => void,\n  delay: number,\n  repeat: true\n): void;\nexport function executeSchedule(\n  parentSubscription: Subscription,\n  scheduler: SchedulerLike,\n  work: () => void,\n  delay?: number,\n  repeat?: false\n): Subscription;\n\nexport function executeSchedule(\n  parentSubscription: Subscription,\n  scheduler: SchedulerLike,\n  work: () => void,\n  delay = 0,\n  repeat = false\n): Subscription | void {\n  const scheduleSubscription = scheduler.schedule(function (this: SchedulerAction<any>) {\n    work();\n    if (repeat) {\n      parentSubscription.add(this.schedule(null, delay));\n    } else {\n      this.unsubscribe();\n    }\n  }, delay);\n\n  parentSubscription.add(scheduleSubscription);\n\n  if (!repeat) {\n    // Because user-land scheduler implementations are unlikely to properly reuse\n    // Actions for repeat scheduling, we can't trust that the returned subscription\n    // will control repeat subscription scenarios. So we're trying to avoid using them\n    // incorrectly within this library.\n    return scheduleSubscription;\n  }\n}\n", "/** @prettier */\nimport { MonoTypeOperatorFunction, SchedulerLike } from '../types';\nimport { executeSchedule } from '../util/executeSchedule';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * Re-emits all notifications from source Observable with specified scheduler.\n *\n * <span class=\"informal\">Ensure a specific scheduler is used, from outside of an Observable.</span>\n *\n * `observeOn` is an operator that accepts a scheduler as a first parameter, which will be used to reschedule\n * notifications emitted by the source Observable. It might be useful, if you do not have control over\n * internal scheduler of a given Observable, but want to control when its values are emitted nevertheless.\n *\n * Returned Observable emits the same notifications (nexted values, complete and error events) as the source Observable,\n * but rescheduled with provided scheduler. Note that this doesn't mean that source Observables internal\n * scheduler will be replaced in any way. Original scheduler still will be used, but when the source Observable emits\n * notification, it will be immediately scheduled again - this time with scheduler passed to `observeOn`.\n * An anti-pattern would be calling `observeOn` on Observable that emits lots of values synchronously, to split\n * that emissions into asynchronous chunks. For this to happen, scheduler would have to be passed into the source\n * Observable directly (usually into the operator that creates it). `observeOn` simply delays notifications a\n * little bit more, to ensure that they are emitted at expected moments.\n *\n * As a matter of fact, `observeOn` accepts second parameter, which specifies in milliseconds with what delay notifications\n * will be emitted. The main difference between {@link delay} operator and `observeOn` is that `observeOn`\n * will delay all notifications - including error notifications - while `delay` will pass through error\n * from source Observable immediately when it is emitted. In general it is highly recommended to use `delay` operator\n * for any kind of delaying of values in the stream, while using `observeOn` to specify which scheduler should be used\n * for notification emissions in general.\n *\n * ## Example\n *\n * Ensure values in subscribe are called just before browser repaint\n *\n * ```ts\n * import { interval, observeOn, animationFrameScheduler } from 'rxjs';\n *\n * const someDiv = document.createElement('div');\n * someDiv.style.cssText = 'width: 200px;background: #09c';\n * document.body.appendChild(someDiv);\n * const intervals = interval(10);      // Intervals are scheduled\n *                                      // with async scheduler by default...\n * intervals.pipe(\n *   observeOn(animationFrameScheduler) // ...but we will observe on animationFrame\n * )                                    // scheduler to ensure smooth animation.\n * .subscribe(val => {\n *   someDiv.style.height = val + 'px';\n * });\n * ```\n *\n * @see {@link delay}\n *\n * @param scheduler Scheduler that will be used to reschedule notifications from source Observable.\n * @param delay Number of milliseconds that states with what delay every notification should be rescheduled.\n * @return A function that returns an Observable that emits the same\n * notifications as the source Observable, but with provided scheduler.\n */\nexport function observeOn<T>(scheduler: SchedulerLike, delay = 0): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value) => executeSchedule(subscriber, scheduler, () => subscriber.next(value), delay),\n        () => executeSchedule(subscriber, scheduler, () => subscriber.complete(), delay),\n        (err) => executeSchedule(subscriber, scheduler, () => subscriber.error(err), delay)\n      )\n    );\n  });\n}\n", "import { MonoTypeOperatorFunction, SchedulerLike } from '../types';\nimport { operate } from '../util/lift';\n\n/**\n * Asynchronously subscribes Observers to this Observable on the specified {@link SchedulerLike}.\n *\n * With `subscribeOn` you can decide what type of scheduler a specific Observable will be using when it is subscribed to.\n *\n * Schedulers control the speed and order of emissions to observers from an Observable stream.\n *\n * ![](subscribeOn.png)\n *\n * ## Example\n *\n * Given the following code:\n *\n * ```ts\n * import { of, merge } from 'rxjs';\n *\n * const a = of(1, 2, 3);\n * const b = of(4, 5, 6);\n *\n * merge(a, b).subscribe(console.log);\n *\n * // Outputs\n * // 1\n * // 2\n * // 3\n * // 4\n * // 5\n * // 6\n * ```\n *\n * Both Observable `a` and `b` will emit their values directly and synchronously once they are subscribed to.\n *\n * If we instead use the `subscribeOn` operator declaring that we want to use the {@link asyncScheduler} for values emitted by Observable `a`:\n *\n * ```ts\n * import { of, subscribeOn, asyncScheduler, merge } from 'rxjs';\n *\n * const a = of(1, 2, 3).pipe(subscribeOn(asyncScheduler));\n * const b = of(4, 5, 6);\n *\n * merge(a, b).subscribe(console.log);\n *\n * // Outputs\n * // 4\n * // 5\n * // 6\n * // 1\n * // 2\n * // 3\n * ```\n *\n * The reason for this is that Observable `b` emits its values directly and synchronously like before\n * but the emissions from `a` are scheduled on the event loop because we are now using the {@link asyncScheduler} for that specific Observable.\n *\n * @param scheduler The {@link SchedulerLike} to perform subscription actions on.\n * @param delay A delay to pass to the scheduler to delay subscriptions\n * @return A function that returns an Observable modified so that its\n * subscriptions happen on the specified {@link SchedulerLike}.\n */\nexport function subscribeOn<T>(scheduler: SchedulerLike, delay: number = 0): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    subscriber.add(scheduler.schedule(() => source.subscribe(subscriber), delay));\n  });\n}\n", "import { innerFrom } from '../observable/innerFrom';\nimport { observeOn } from '../operators/observeOn';\nimport { subscribeOn } from '../operators/subscribeOn';\nimport { InteropObservable, SchedulerLike } from '../types';\n\nexport function scheduleObservable<T>(input: InteropObservable<T>, scheduler: SchedulerLike) {\n  return innerFrom(input).pipe(subscribeOn(scheduler), observeOn(scheduler));\n}\n", "import { innerFrom } from '../observable/innerFrom';\nimport { observeOn } from '../operators/observeOn';\nimport { subscribeOn } from '../operators/subscribeOn';\nimport { SchedulerLike } from '../types';\n\nexport function schedulePromise<T>(input: PromiseLike<T>, scheduler: SchedulerLike) {\n  return innerFrom(input).pipe(subscribeOn(scheduler), observeOn(scheduler));\n}\n", "import { Observable } from '../Observable';\nimport { SchedulerLike } from '../types';\n\nexport function scheduleArray<T>(input: ArrayLike<T>, scheduler: SchedulerLike) {\n  return new Observable<T>((subscriber) => {\n    // The current array index.\n    let i = 0;\n    // Start iterating over the array like on a schedule.\n    return scheduler.schedule(function () {\n      if (i === input.length) {\n        // If we have hit the end of the array like in the\n        // previous job, we can complete.\n        subscriber.complete();\n      } else {\n        // Otherwise let's next the value at the current index,\n        // then increment our index.\n        subscriber.next(input[i++]);\n        // If the last emission didn't cause us to close the subscriber\n        // (via take or some side effect), reschedule the job and we'll\n        // make another pass.\n        if (!subscriber.closed) {\n          this.schedule();\n        }\n      }\n    });\n  });\n}\n", "import { Observable } from '../Observable';\nimport { SchedulerLike } from '../types';\nimport { iterator as Symbol_iterator } from '../symbol/iterator';\nimport { isFunction } from '../util/isFunction';\nimport { executeSchedule } from '../util/executeSchedule';\n\n/**\n * Used in {@link scheduled} to create an observable from an Iterable.\n * @param input The iterable to create an observable from\n * @param scheduler The scheduler to use\n */\nexport function scheduleIterable<T>(input: Iterable<T>, scheduler: SchedulerLike) {\n  return new Observable<T>((subscriber) => {\n    let iterator: Iterator<T, T>;\n\n    // Schedule the initial creation of the iterator from\n    // the iterable. This is so the code in the iterable is\n    // not called until the scheduled job fires.\n    executeSchedule(subscriber, scheduler, () => {\n      // Create the iterator.\n      iterator = (input as any)[Symbol_iterator]();\n\n      executeSchedule(\n        subscriber,\n        scheduler,\n        () => {\n          let value: T;\n          let done: boolean | undefined;\n          try {\n            // Pull the value out of the iterator\n            ({ value, done } = iterator.next());\n          } catch (err) {\n            // We got an error while pulling from the iterator\n            subscriber.error(err);\n            return;\n          }\n\n          if (done) {\n            // If it is \"done\" we just complete. This mimics the\n            // behavior of JavaScript's `for..of` consumption of\n            // iterables, which will not emit the value from an iterator\n            // result of `{ done: true: value: 'here' }`.\n            subscriber.complete();\n          } else {\n            // The iterable is not done, emit the value.\n            subscriber.next(value);\n          }\n        },\n        0,\n        true\n      );\n    });\n\n    // During finalization, if we see this iterator has a `return` method,\n    // then we know it is a Generator, and not just an Iterator. So we call\n    // the `return()` function. This will ensure that any `finally { }` blocks\n    // inside of the generator we can hit will be hit properly.\n    return () => isFunction(iterator?.return) && iterator.return();\n  });\n}\n", "import { SchedulerLike } from '../types';\nimport { Observable } from '../Observable';\nimport { executeSchedule } from '../util/executeSchedule';\n\nexport function scheduleAsyncIterable<T>(input: AsyncIterable<T>, scheduler: SchedulerLike) {\n  if (!input) {\n    throw new Error('Iterable cannot be null');\n  }\n  return new Observable<T>((subscriber) => {\n    executeSchedule(subscriber, scheduler, () => {\n      const iterator = input[Symbol.asyncIterator]();\n      executeSchedule(\n        subscriber,\n        scheduler,\n        () => {\n          iterator.next().then((result) => {\n            if (result.done) {\n              // This will remove the subscriptions from\n              // the parent subscription.\n              subscriber.complete();\n            } else {\n              subscriber.next(result.value);\n            }\n          });\n        },\n        0,\n        true\n      );\n    });\n  });\n}\n", "import { SchedulerLike, ReadableStreamLike } from '../types';\nimport { Observable } from '../Observable';\nimport { scheduleAsyncIterable } from './scheduleAsyncIterable';\nimport { readableStreamLikeToAsyncGenerator } from '../util/isReadableStreamLike';\n\nexport function scheduleReadableStreamLike<T>(input: ReadableStreamLike<T>, scheduler: SchedulerLike): Observable<T> {\n  return scheduleAsyncIterable(readableStreamLikeToAsyncGenerator(input), scheduler);\n}\n", "import { scheduleObservable } from './scheduleObservable';\nimport { schedulePromise } from './schedulePromise';\nimport { scheduleArray } from './scheduleArray';\nimport { scheduleIterable } from './scheduleIterable';\nimport { scheduleAsyncIterable } from './scheduleAsyncIterable';\nimport { isInteropObservable } from '../util/isInteropObservable';\nimport { isPromise } from '../util/isPromise';\nimport { isArrayLike } from '../util/isArrayLike';\nimport { isIterable } from '../util/isIterable';\nimport { ObservableInput, SchedulerLike } from '../types';\nimport { Observable } from '../Observable';\nimport { isAsyncIterable } from '../util/isAsyncIterable';\nimport { createInvalidObservableTypeError } from '../util/throwUnobservableError';\nimport { isReadableStreamLike } from '../util/isReadableStreamLike';\nimport { scheduleReadableStreamLike } from './scheduleReadableStreamLike';\n\n/**\n * Converts from a common {@link ObservableInput} type to an observable where subscription and emissions\n * are scheduled on the provided scheduler.\n *\n * @see {@link from}\n * @see {@link of}\n *\n * @param input The observable, array, promise, iterable, etc you would like to schedule\n * @param scheduler The scheduler to use to schedule the subscription and emissions from\n * the returned observable.\n */\nexport function scheduled<T>(input: ObservableInput<T>, scheduler: SchedulerLike): Observable<T> {\n  if (input != null) {\n    if (isInteropObservable(input)) {\n      return scheduleObservable(input, scheduler);\n    }\n    if (isArrayLike(input)) {\n      return scheduleArray(input, scheduler);\n    }\n    if (isPromise(input)) {\n      return schedulePromise(input, scheduler);\n    }\n    if (isAsyncIterable(input)) {\n      return scheduleAsyncIterable(input, scheduler);\n    }\n    if (isIterable(input)) {\n      return scheduleIterable(input, scheduler);\n    }\n    if (isReadableStreamLike(input)) {\n      return scheduleReadableStreamLike(input, scheduler);\n    }\n  }\n  throw createInvalidObservableTypeError(input);\n}\n", "import { Observable } from '../Observable';\nimport { ObservableInput, SchedulerLike, ObservedValueOf } from '../types';\nimport { scheduled } from '../scheduled/scheduled';\nimport { innerFrom } from './innerFrom';\n\nexport function from<O extends ObservableInput<any>>(input: O): Observable<ObservedValueOf<O>>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function from<O extends ObservableInput<any>>(input: O, scheduler: SchedulerLike | undefined): Observable<ObservedValueOf<O>>;\n\n/**\n * Creates an Observable from an Array, an array-like object, a Promise, an iterable object, or an Observable-like object.\n *\n * <span class=\"informal\">Converts almost anything to an Observable.</span>\n *\n * ![](from.png)\n *\n * `from` converts various other objects and data types into Observables. It also converts a Promise, an array-like, or an\n * <a href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols#iterable\" target=\"_blank\">iterable</a>\n * object into an Observable that emits the items in that promise, array, or iterable. A String, in this context, is treated\n * as an array of characters. Observable-like objects (contains a function named with the ES2015 Symbol for Observable) can also be\n * converted through this operator.\n *\n * ## Examples\n *\n * Converts an array to an Observable\n *\n * ```ts\n * import { from } from 'rxjs';\n *\n * const array = [10, 20, 30];\n * const result = from(array);\n *\n * result.subscribe(x => console.log(x));\n *\n * // Logs:\n * // 10\n * // 20\n * // 30\n * ```\n *\n * Convert an infinite iterable (from a generator) to an Observable\n *\n * ```ts\n * import { from, take } from 'rxjs';\n *\n * function* generateDoubles(seed) {\n *    let i = seed;\n *    while (true) {\n *      yield i;\n *      i = 2 * i; // double it\n *    }\n * }\n *\n * const iterator = generateDoubles(3);\n * const result = from(iterator).pipe(take(10));\n *\n * result.subscribe(x => console.log(x));\n *\n * // Logs:\n * // 3\n * // 6\n * // 12\n * // 24\n * // 48\n * // 96\n * // 192\n * // 384\n * // 768\n * // 1536\n * ```\n *\n * With `asyncScheduler`\n *\n * ```ts\n * import { from, asyncScheduler } from 'rxjs';\n *\n * console.log('start');\n *\n * const array = [10, 20, 30];\n * const result = from(array, asyncScheduler);\n *\n * result.subscribe(x => console.log(x));\n *\n * console.log('end');\n *\n * // Logs:\n * // 'start'\n * // 'end'\n * // 10\n * // 20\n * // 30\n * ```\n *\n * @see {@link fromEvent}\n * @see {@link fromEventPattern}\n *\n * @param {ObservableInput<T>} A subscription object, a Promise, an Observable-like,\n * an Array, an iterable, or an array-like object to be converted.\n * @param {SchedulerLike} An optional {@link SchedulerLike} on which to schedule the emission of values.\n * @return {Observable<T>}\n */\nexport function from<T>(input: ObservableInput<T>, scheduler?: SchedulerLike): Observable<T> {\n  return scheduler ? scheduled(input, scheduler) : innerFrom(input);\n}\n", "import { SchedulerLike, ValueFromArray } from '../types';\nimport { Observable } from '../Observable';\nimport { popScheduler } from '../util/args';\nimport { from } from './from';\n\n// Devs are more likely to pass null or undefined than they are a scheduler\n// without accompanying values. To make things easier for (naughty) devs who\n// use the `strictNullChecks: false` TypeScript compiler option, these\n// overloads with explicit null and undefined values are included.\n\nexport function of(value: null): Observable<null>;\nexport function of(value: undefined): Observable<undefined>;\n\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function of(scheduler: SchedulerLike): Observable<never>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function of<A extends readonly unknown[]>(...valuesAndScheduler: [...A, SchedulerLike]): Observable<ValueFromArray<A>>;\n\nexport function of(): Observable<never>;\n/** @deprecated Do not specify explicit type parameters. Signatures with type parameters that cannot be inferred will be removed in v8. */\nexport function of<T>(): Observable<T>;\nexport function of<T>(value: T): Observable<T>;\nexport function of<A extends readonly unknown[]>(...values: A): Observable<ValueFromArray<A>>;\n\n/**\n * Converts the arguments to an observable sequence.\n *\n * <span class=\"informal\">Each argument becomes a `next` notification.</span>\n *\n * ![](of.png)\n *\n * Unlike {@link from}, it does not do any flattening and emits each argument in whole\n * as a separate `next` notification.\n *\n * ## Examples\n *\n * Emit the values `10, 20, 30`\n *\n * ```ts\n * import { of } from 'rxjs';\n *\n * of(10, 20, 30)\n *   .subscribe({\n *     next: value => console.log('next:', value),\n *     error: err => console.log('error:', err),\n *     complete: () => console.log('the end'),\n *   });\n *\n * // Outputs\n * // next: 10\n * // next: 20\n * // next: 30\n * // the end\n * ```\n *\n * Emit the array `[1, 2, 3]`\n *\n * ```ts\n * import { of } from 'rxjs';\n *\n * of([1, 2, 3])\n *   .subscribe({\n *     next: value => console.log('next:', value),\n *     error: err => console.log('error:', err),\n *     complete: () => console.log('the end'),\n *   });\n *\n * // Outputs\n * // next: [1, 2, 3]\n * // the end\n * ```\n *\n * @see {@link from}\n * @see {@link range}\n *\n * @param {...T} values A comma separated list of arguments you want to be emitted\n * @return {Observable} An Observable that emits the arguments\n * described above and then completes.\n */\nexport function of<T>(...args: Array<T | SchedulerLike>): Observable<T> {\n  const scheduler = popScheduler(args);\n  return from(args as T[], scheduler);\n}\n", "import { Observable } from '../Observable';\nimport { Subscriber } from '../Subscriber';\nimport { SchedulerLike } from '../types';\nimport { isFunction } from '../util/isFunction';\n\n/**\n * Creates an observable that will create an error instance and push it to the consumer as an error\n * immediately upon subscription.\n *\n * <span class=\"informal\">Just errors and does nothing else</span>\n *\n * ![](throw.png)\n *\n * This creation function is useful for creating an observable that will create an error and error every\n * time it is subscribed to. Generally, inside of most operators when you might want to return an errored\n * observable, this is unnecessary. In most cases, such as in the inner return of {@link concatMap},\n * {@link mergeMap}, {@link defer}, and many others, you can simply throw the error, and RxJS will pick\n * that up and notify the consumer of the error.\n *\n * ## Example\n *\n * Create a simple observable that will create a new error with a timestamp and log it\n * and the message every time you subscribe to it\n *\n * ```ts\n * import { throwError } from 'rxjs';\n *\n * let errorCount = 0;\n *\n * const errorWithTimestamp$ = throwError(() => {\n *   const error: any = new Error(`This is error number ${ ++errorCount }`);\n *   error.timestamp = Date.now();\n *   return error;\n * });\n *\n * errorWithTimestamp$.subscribe({\n *   error: err => console.log(err.timestamp, err.message)\n * });\n *\n * errorWithTimestamp$.subscribe({\n *   error: err => console.log(err.timestamp, err.message)\n * });\n *\n * // Logs the timestamp and a new error message for each subscription\n * ```\n *\n * ### Unnecessary usage\n *\n * Using `throwError` inside of an operator or creation function\n * with a callback, is usually not necessary\n *\n * ```ts\n * import { of, concatMap, timer, throwError } from 'rxjs';\n *\n * const delays$ = of(1000, 2000, Infinity, 3000);\n *\n * delays$.pipe(\n *   concatMap(ms => {\n *     if (ms < 10000) {\n *       return timer(ms);\n *     } else {\n *       // This is probably overkill.\n *       return throwError(() => new Error(`Invalid time ${ ms }`));\n *     }\n *   })\n * )\n * .subscribe({\n *   next: console.log,\n *   error: console.error\n * });\n * ```\n *\n * You can just throw the error instead\n *\n * ```ts\n * import { of, concatMap, timer } from 'rxjs';\n *\n * const delays$ = of(1000, 2000, Infinity, 3000);\n *\n * delays$.pipe(\n *   concatMap(ms => {\n *     if (ms < 10000) {\n *       return timer(ms);\n *     } else {\n *       // Cleaner and easier to read for most folks.\n *       throw new Error(`Invalid time ${ ms }`);\n *     }\n *   })\n * )\n * .subscribe({\n *   next: console.log,\n *   error: console.error\n * });\n * ```\n *\n * @param errorFactory A factory function that will create the error instance that is pushed.\n */\nexport function throwError(errorFactory: () => any): Observable<never>;\n\n/**\n * Returns an observable that will error with the specified error immediately upon subscription.\n *\n * @param error The error instance to emit\n * @deprecated Support for passing an error value will be removed in v8. Instead, pass a factory function to `throwError(() => new Error('test'))`. This is\n * because it will create the error at the moment it should be created and capture a more appropriate stack trace. If\n * for some reason you need to create the error ahead of time, you can still do that: `const err = new Error('test'); throwError(() => err);`.\n */\nexport function throwError(error: any): Observable<never>;\n\n/**\n * Notifies the consumer of an error using a given scheduler by scheduling it at delay `0` upon subscription.\n *\n * @param errorOrErrorFactory An error instance or error factory\n * @param scheduler A scheduler to use to schedule the error notification\n * @deprecated The `scheduler` parameter will be removed in v8.\n * Use `throwError` in combination with {@link observeOn}: `throwError(() => new Error('test')).pipe(observeOn(scheduler));`.\n * Details: https://rxjs.dev/deprecations/scheduler-argument\n */\nexport function throwError(errorOrErrorFactory: any, scheduler: SchedulerLike): Observable<never>;\n\nexport function throwError(errorOrErrorFactory: any, scheduler?: SchedulerLike): Observable<never> {\n  const errorFactory = isFunction(errorOrErrorFactory) ? errorOrErrorFactory : () => errorOrErrorFactory;\n  const init = (subscriber: Subscriber<never>) => subscriber.error(errorFactory());\n  return new Observable(scheduler ? (subscriber) => scheduler.schedule(init as any, 0, subscriber) : init);\n}\n", "import { createErrorClass } from './createErrorClass';\n\nexport interface EmptyError extends Error {}\n\nexport interface EmptyErrorCtor {\n  /**\n   * @deprecated Internal implementation detail. Do not construct error instances.\n   * Cannot be tagged as internal: https://github.com/ReactiveX/rxjs/issues/6269\n   */\n  new (): EmptyError;\n}\n\n/**\n * An error thrown when an Observable or a sequence was queried but has no\n * elements.\n *\n * @see {@link first}\n * @see {@link last}\n * @see {@link single}\n * @see {@link firstValueFrom}\n * @see {@link lastValueFrom}\n *\n * @class EmptyError\n */\nexport const EmptyError: EmptyErrorCtor = createErrorClass((_super) => function EmptyErrorImpl(this: any) {\n  _super(this);\n  this.name = 'EmptyError';\n  this.message = 'no elements in sequence';\n});\n", "/**\n * Checks to see if a value is not only a `Date` object,\n * but a *valid* `Date` object that can be converted to a\n * number. For example, `new Date('blah')` is indeed an\n * `instanceof Date`, however it cannot be converted to a\n * number.\n */\nexport function isValidDate(value: any): value is Date {\n  return value instanceof Date && !isNaN(value as any);\n}\n", "import { OperatorFunction } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\nexport function map<T, R>(project: (value: T, index: number) => R): OperatorFunction<T, R>;\n/** @deprecated Use a closure instead of a `thisArg`. Signatures accepting a `thisArg` will be removed in v8. */\nexport function map<T, R, A>(project: (this: A, value: T, index: number) => R, thisArg: A): OperatorFunction<T, R>;\n\n/**\n * Applies a given `project` function to each value emitted by the source\n * Observable, and emits the resulting values as an Observable.\n *\n * <span class=\"informal\">Like [Array.prototype.map()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map),\n * it passes each source value through a transformation function to get\n * corresponding output values.</span>\n *\n * ![](map.png)\n *\n * Similar to the well known `Array.prototype.map` function, this operator\n * applies a projection to each value and emits that projection in the output\n * Observable.\n *\n * ## Example\n *\n * Map every click to the `clientX` position of that click\n *\n * ```ts\n * import { fromEvent, map } from 'rxjs';\n *\n * const clicks = fromEvent<PointerEvent>(document, 'click');\n * const positions = clicks.pipe(map(ev => ev.clientX));\n *\n * positions.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link mapTo}\n * @see {@link pluck}\n *\n * @param {function(value: T, index: number): R} project The function to apply\n * to each `value` emitted by the source Observable. The `index` parameter is\n * the number `i` for the i-th emission that has happened since the\n * subscription, starting from the number `0`.\n * @param {any} [thisArg] An optional argument to define what `this` is in the\n * `project` function.\n * @return A function that returns an Observable that emits the values from the\n * source Observable transformed by the given `project` function.\n */\nexport function map<T, R>(project: (value: T, index: number) => R, thisArg?: any): OperatorFunction<T, R> {\n  return operate((source, subscriber) => {\n    // The index of the value from the source. Used with projection.\n    let index = 0;\n    // Subscribe to the source, all errors and completions are sent along\n    // to the consumer.\n    source.subscribe(\n      createOperatorSubscriber(subscriber, (value: T) => {\n        // Call the projection function with the appropriate this context,\n        // and send the resulting value to the consumer.\n        subscriber.next(project.call(thisArg, value, index++));\n      })\n    );\n  });\n}\n", "import { OperatorFunction } from \"../types\";\nimport { map } from \"../operators/map\";\n\nconst { isArray } = Array;\n\nfunction callOrApply<T, R>(fn: ((...values: T[]) => R), args: T|T[]): R {\n    return isArray(args) ? fn(...args) : fn(args);\n}\n\n/**\n * Used in several -- mostly deprecated -- situations where we need to \n * apply a list of arguments or a single argument to a result selector.\n */\nexport function mapOneOrManyArgs<T, R>(fn: ((...values: T[]) => R)): OperatorFunction<T|T[], R> {\n    return map(args => callOrApply(fn, args))\n}", "const { isArray } = Array;\nconst { getPrototypeOf, prototype: objectProto, keys: getKeys } = Object;\n\n/**\n * Used in functions where either a list of arguments, a single array of arguments, or a\n * dictionary of arguments can be returned. Returns an object with an `args` property with\n * the arguments in an array, if it is a dictionary, it will also return the `keys` in another\n * property.\n */\nexport function argsArgArrayOrObject<T, O extends Record<string, T>>(args: T[] | [O] | [T[]]): { args: T[]; keys: string[] | null } {\n  if (args.length === 1) {\n    const first = args[0];\n    if (isArray(first)) {\n      return { args: first, keys: null };\n    }\n    if (isPOJO(first)) {\n      const keys = getKeys(first);\n      return {\n        args: keys.map((key) => first[key]),\n        keys,\n      };\n    }\n  }\n\n  return { args: args as T[], keys: null };\n}\n\nfunction isPOJO(obj: any): obj is object {\n  return obj && typeof obj === 'object' && getPrototypeOf(obj) === objectProto;\n}\n", "export function createObject(keys: string[], values: any[]) {\n  return keys.reduce((result, key, i) => ((result[key] = values[i]), result), {} as any);\n}\n", "import { Observable } from '../Observable';\nimport { ObservableInput, SchedulerLike, ObservedValueOf, ObservableInputTuple } from '../types';\nimport { argsArgArrayOrObject } from '../util/argsArgArrayOrObject';\nimport { Subscriber } from '../Subscriber';\nimport { from } from './from';\nimport { identity } from '../util/identity';\nimport { Subscription } from '../Subscription';\nimport { mapOneOrManyArgs } from '../util/mapOneOrManyArgs';\nimport { popResultSelector, popScheduler } from '../util/args';\nimport { createObject } from '../util/createObject';\nimport { createOperatorSubscriber } from '../operators/OperatorSubscriber';\nimport { AnyCatcher } from '../AnyCatcher';\nimport { executeSchedule } from '../util/executeSchedule';\n\n// combineLatest(any)\n// We put this first because we need to catch cases where the user has supplied\n// _exactly `any`_ as the argument. Since `any` literally matches _anything_,\n// we don't want it to randomly hit one of the other type signatures below,\n// as we have no idea at build-time what type we should be returning when given an any.\n\n/**\n * You have passed `any` here, we can't figure out if it is\n * an array or an object, so you're getting `unknown`. Use better types.\n * @param arg Something typed as `any`\n */\nexport function combineLatest<T extends AnyCatcher>(arg: T): Observable<unknown>;\n\n// combineLatest([a, b, c])\nexport function combineLatest(sources: []): Observable<never>;\nexport function combineLatest<A extends readonly unknown[]>(sources: readonly [...ObservableInputTuple<A>]): Observable<A>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `combineLatestAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function combineLatest<A extends readonly unknown[], R>(\n  sources: readonly [...ObservableInputTuple<A>],\n  resultSelector: (...values: A) => R,\n  scheduler: SchedulerLike\n): Observable<R>;\nexport function combineLatest<A extends readonly unknown[], R>(\n  sources: readonly [...ObservableInputTuple<A>],\n  resultSelector: (...values: A) => R\n): Observable<R>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `combineLatestAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function combineLatest<A extends readonly unknown[]>(\n  sources: readonly [...ObservableInputTuple<A>],\n  scheduler: SchedulerLike\n): Observable<A>;\n\n// combineLatest(a, b, c)\n/** @deprecated Pass an array of sources instead. The rest-parameters signature will be removed in v8. Details: https://rxjs.dev/deprecations/array-argument */\nexport function combineLatest<A extends readonly unknown[]>(...sources: [...ObservableInputTuple<A>]): Observable<A>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `combineLatestAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function combineLatest<A extends readonly unknown[], R>(\n  ...sourcesAndResultSelectorAndScheduler: [...ObservableInputTuple<A>, (...values: A) => R, SchedulerLike]\n): Observable<R>;\n/** @deprecated Pass an array of sources instead. The rest-parameters signature will be removed in v8. Details: https://rxjs.dev/deprecations/array-argument */\nexport function combineLatest<A extends readonly unknown[], R>(\n  ...sourcesAndResultSelector: [...ObservableInputTuple<A>, (...values: A) => R]\n): Observable<R>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `combineLatestAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function combineLatest<A extends readonly unknown[]>(\n  ...sourcesAndScheduler: [...ObservableInputTuple<A>, SchedulerLike]\n): Observable<A>;\n\n// combineLatest({a, b, c})\nexport function combineLatest(sourcesObject: { [K in any]: never }): Observable<never>;\nexport function combineLatest<T extends Record<string, ObservableInput<any>>>(\n  sourcesObject: T\n): Observable<{ [K in keyof T]: ObservedValueOf<T[K]> }>;\n\n/**\n * Combines multiple Observables to create an Observable whose values are\n * calculated from the latest values of each of its input Observables.\n *\n * <span class=\"informal\">Whenever any input Observable emits a value, it\n * computes a formula using the latest values from all the inputs, then emits\n * the output of that formula.</span>\n *\n * ![](combineLatest.png)\n *\n * `combineLatest` combines the values from all the Observables passed in the\n * observables array. This is done by subscribing to each Observable in order and,\n * whenever any Observable emits, collecting an array of the most recent\n * values from each Observable. So if you pass `n` Observables to this operator,\n * the returned Observable will always emit an array of `n` values, in an order\n * corresponding to the order of the passed Observables (the value from the first Observable\n * will be at index 0 of the array and so on).\n *\n * Static version of `combineLatest` accepts an array of Observables. Note that an array of\n * Observables is a good choice, if you don't know beforehand how many Observables\n * you will combine. Passing an empty array will result in an Observable that\n * completes immediately.\n *\n * To ensure the output array always has the same length, `combineLatest` will\n * actually wait for all input Observables to emit at least once,\n * before it starts emitting results. This means if some Observable emits\n * values before other Observables started emitting, all these values but the last\n * will be lost. On the other hand, if some Observable does not emit a value but\n * completes, resulting Observable will complete at the same moment without\n * emitting anything, since it will now be impossible to include a value from the\n * completed Observable in the resulting array. Also, if some input Observable does\n * not emit any value and never completes, `combineLatest` will also never emit\n * and never complete, since, again, it will wait for all streams to emit some\n * value.\n *\n * If at least one Observable was passed to `combineLatest` and all passed Observables\n * emitted something, the resulting Observable will complete when all combined\n * streams complete. So even if some Observable completes, the result of\n * `combineLatest` will still emit values when other Observables do. In case\n * of a completed Observable, its value from now on will always be the last\n * emitted value. On the other hand, if any Observable errors, `combineLatest`\n * will error immediately as well, and all other Observables will be unsubscribed.\n *\n * ## Examples\n *\n * Combine two timer Observables\n *\n * ```ts\n * import { timer, combineLatest } from 'rxjs';\n *\n * const firstTimer = timer(0, 1000); // emit 0, 1, 2... after every second, starting from now\n * const secondTimer = timer(500, 1000); // emit 0, 1, 2... after every second, starting 0,5s from now\n * const combinedTimers = combineLatest([firstTimer, secondTimer]);\n * combinedTimers.subscribe(value => console.log(value));\n * // Logs\n * // [0, 0] after 0.5s\n * // [1, 0] after 1s\n * // [1, 1] after 1.5s\n * // [2, 1] after 2s\n * ```\n *\n * Combine a dictionary of Observables\n *\n * ```ts\n * import { of, delay, startWith, combineLatest } from 'rxjs';\n *\n * const observables = {\n *   a: of(1).pipe(delay(1000), startWith(0)),\n *   b: of(5).pipe(delay(5000), startWith(0)),\n *   c: of(10).pipe(delay(10000), startWith(0))\n * };\n * const combined = combineLatest(observables);\n * combined.subscribe(value => console.log(value));\n * // Logs\n * // { a: 0, b: 0, c: 0 } immediately\n * // { a: 1, b: 0, c: 0 } after 1s\n * // { a: 1, b: 5, c: 0 } after 5s\n * // { a: 1, b: 5, c: 10 } after 10s\n * ```\n *\n * Combine an array of Observables\n *\n * ```ts\n * import { of, delay, startWith, combineLatest } from 'rxjs';\n *\n * const observables = [1, 5, 10].map(\n *   n => of(n).pipe(\n *     delay(n * 1000), // emit 0 and then emit n after n seconds\n *     startWith(0)\n *   )\n * );\n * const combined = combineLatest(observables);\n * combined.subscribe(value => console.log(value));\n * // Logs\n * // [0, 0, 0] immediately\n * // [1, 0, 0] after 1s\n * // [1, 5, 0] after 5s\n * // [1, 5, 10] after 10s\n * ```\n *\n * Use map operator to dynamically calculate the Body-Mass Index\n *\n * ```ts\n * import { of, combineLatest, map } from 'rxjs';\n *\n * const weight = of(70, 72, 76, 79, 75);\n * const height = of(1.76, 1.77, 1.78);\n * const bmi = combineLatest([weight, height]).pipe(\n *   map(([w, h]) => w / (h * h)),\n * );\n * bmi.subscribe(x => console.log('BMI is ' + x));\n *\n * // With output to console:\n * // BMI is 24.212293388429753\n * // BMI is 23.93948099205209\n * // BMI is 23.671253629592222\n * ```\n *\n * @see {@link combineLatestAll}\n * @see {@link merge}\n * @see {@link withLatestFrom}\n *\n * @param {ObservableInput} [observables] An array of input Observables to combine with each other.\n * An array of Observables must be given as the first argument.\n * @param {function} [project] An optional function to project the values from\n * the combined latest values into a new value on the output Observable.\n * @param {SchedulerLike} [scheduler=null] The {@link SchedulerLike} to use for subscribing to\n * each input Observable.\n * @return {Observable} An Observable of projected values from the most recent\n * values from each input Observable, or an array of the most recent values from\n * each input Observable.\n */\nexport function combineLatest<O extends ObservableInput<any>, R>(...args: any[]): Observable<R> | Observable<ObservedValueOf<O>[]> {\n  const scheduler = popScheduler(args);\n  const resultSelector = popResultSelector(args);\n\n  const { args: observables, keys } = argsArgArrayOrObject(args);\n\n  if (observables.length === 0) {\n    // If no observables are passed, or someone has passed an empty array\n    // of observables, or even an empty object POJO, we need to just\n    // complete (EMPTY), but we have to honor the scheduler provided if any.\n    return from([], scheduler as any);\n  }\n\n  const result = new Observable<ObservedValueOf<O>[]>(\n    combineLatestInit(\n      observables as ObservableInput<ObservedValueOf<O>>[],\n      scheduler,\n      keys\n        ? // A handler for scrubbing the array of args into a dictionary.\n          (values) => createObject(keys, values)\n        : // A passthrough to just return the array\n          identity\n    )\n  );\n\n  return resultSelector ? (result.pipe(mapOneOrManyArgs(resultSelector)) as Observable<R>) : result;\n}\n\nexport function combineLatestInit(\n  observables: ObservableInput<any>[],\n  scheduler?: SchedulerLike,\n  valueTransform: (values: any[]) => any = identity\n) {\n  return (subscriber: Subscriber<any>) => {\n    // The outer subscription. We're capturing this in a function\n    // because we may have to schedule it.\n    maybeSchedule(\n      scheduler,\n      () => {\n        const { length } = observables;\n        // A store for the values each observable has emitted so far. We match observable to value on index.\n        const values = new Array(length);\n        // The number of currently active subscriptions, as they complete, we decrement this number to see if\n        // we are all done combining values, so we can complete the result.\n        let active = length;\n        // The number of inner sources that still haven't emitted the first value\n        // We need to track this because all sources need to emit one value in order\n        // to start emitting values.\n        let remainingFirstValues = length;\n        // The loop to kick off subscription. We're keying everything on index `i` to relate the observables passed\n        // in to the slot in the output array or the key in the array of keys in the output dictionary.\n        for (let i = 0; i < length; i++) {\n          maybeSchedule(\n            scheduler,\n            () => {\n              const source = from(observables[i], scheduler as any);\n              let hasFirstValue = false;\n              source.subscribe(\n                createOperatorSubscriber(\n                  subscriber,\n                  (value) => {\n                    // When we get a value, record it in our set of values.\n                    values[i] = value;\n                    if (!hasFirstValue) {\n                      // If this is our first value, record that.\n                      hasFirstValue = true;\n                      remainingFirstValues--;\n                    }\n                    if (!remainingFirstValues) {\n                      // We're not waiting for any more\n                      // first values, so we can emit!\n                      subscriber.next(valueTransform(values.slice()));\n                    }\n                  },\n                  () => {\n                    if (!--active) {\n                      // We only complete the result if we have no more active\n                      // inner observables.\n                      subscriber.complete();\n                    }\n                  }\n                )\n              );\n            },\n            subscriber\n          );\n        }\n      },\n      subscriber\n    );\n  };\n}\n\n/**\n * A small utility to handle the couple of locations where we want to schedule if a scheduler was provided,\n * but we don't if there was no scheduler.\n */\nfunction maybeSchedule(scheduler: SchedulerLike | undefined, execute: () => void, subscription: Subscription) {\n  if (scheduler) {\n    executeSchedule(subscription, scheduler, execute);\n  } else {\n    execute();\n  }\n}\n", "import { Observable } from '../Observable';\nimport { innerFrom } from '../observable/innerFrom';\nimport { Subscriber } from '../Subscriber';\nimport { ObservableInput, SchedulerLike } from '../types';\nimport { executeSchedule } from '../util/executeSchedule';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * A process embodying the general \"merge\" strategy. This is used in\n * `mergeMap` and `mergeScan` because the logic is otherwise nearly identical.\n * @param source The original source observable\n * @param subscriber The consumer subscriber\n * @param project The projection function to get our inner sources\n * @param concurrent The number of concurrent inner subscriptions\n * @param onBeforeNext Additional logic to apply before nexting to our consumer\n * @param expand If `true` this will perform an \"expand\" strategy, which differs only\n * in that it recurses, and the inner subscription must be schedule-able.\n * @param innerSubScheduler A scheduler to use to schedule inner subscriptions,\n * this is to support the expand strategy, mostly, and should be deprecated\n */\nexport function mergeInternals<T, R>(\n  source: Observable<T>,\n  subscriber: Subscriber<R>,\n  project: (value: T, index: number) => ObservableInput<R>,\n  concurrent: number,\n  onBeforeNext?: (innerValue: R) => void,\n  expand?: boolean,\n  innerSubScheduler?: SchedulerLike,\n  additionalFinalizer?: () => void\n) {\n  // Buffered values, in the event of going over our concurrency limit\n  const buffer: T[] = [];\n  // The number of active inner subscriptions.\n  let active = 0;\n  // An index to pass to our accumulator function\n  let index = 0;\n  // Whether or not the outer source has completed.\n  let isComplete = false;\n\n  /**\n   * Checks to see if we can complete our result or not.\n   */\n  const checkComplete = () => {\n    // If the outer has completed, and nothing is left in the buffer,\n    // and we don't have any active inner subscriptions, then we can\n    // Emit the state and complete.\n    if (isComplete && !buffer.length && !active) {\n      subscriber.complete();\n    }\n  };\n\n  // If we're under our concurrency limit, just start the inner subscription, otherwise buffer and wait.\n  const outerNext = (value: T) => (active < concurrent ? doInnerSub(value) : buffer.push(value));\n\n  const doInnerSub = (value: T) => {\n    // If we're expanding, we need to emit the outer values and the inner values\n    // as the inners will \"become outers\" in a way as they are recursively fed\n    // back to the projection mechanism.\n    expand && subscriber.next(value as any);\n\n    // Increment the number of active subscriptions so we can track it\n    // against our concurrency limit later.\n    active++;\n\n    // A flag used to show that the inner observable completed.\n    // This is checked during finalization to see if we should\n    // move to the next item in the buffer, if there is on.\n    let innerComplete = false;\n\n    // Start our inner subscription.\n    innerFrom(project(value, index++)).subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (innerValue) => {\n          // `mergeScan` has additional handling here. For example\n          // taking the inner value and updating state.\n          onBeforeNext?.(innerValue);\n\n          if (expand) {\n            // If we're expanding, then just recurse back to our outer\n            // handler. It will emit the value first thing.\n            outerNext(innerValue as any);\n          } else {\n            // Otherwise, emit the inner value.\n            subscriber.next(innerValue);\n          }\n        },\n        () => {\n          // Flag that we have completed, so we know to check the buffer\n          // during finalization.\n          innerComplete = true;\n        },\n        // Errors are passed to the destination.\n        undefined,\n        () => {\n          // During finalization, if the inner completed (it wasn't errored or\n          // cancelled), then we want to try the next item in the buffer if\n          // there is one.\n          if (innerComplete) {\n            // We have to wrap this in a try/catch because it happens during\n            // finalization, possibly asynchronously, and we want to pass\n            // any errors that happen (like in a projection function) to\n            // the outer Subscriber.\n            try {\n              // INNER SOURCE COMPLETE\n              // Decrement the active count to ensure that the next time\n              // we try to call `doInnerSub`, the number is accurate.\n              active--;\n              // If we have more values in the buffer, try to process those\n              // Note that this call will increment `active` ahead of the\n              // next conditional, if there were any more inner subscriptions\n              // to start.\n              while (buffer.length && active < concurrent) {\n                const bufferedValue = buffer.shift()!;\n                // Particularly for `expand`, we need to check to see if a scheduler was provided\n                // for when we want to start our inner subscription. Otherwise, we just start\n                // are next inner subscription.\n                if (innerSubScheduler) {\n                  executeSchedule(subscriber, innerSubScheduler, () => doInnerSub(bufferedValue));\n                } else {\n                  doInnerSub(bufferedValue);\n                }\n              }\n              // Check to see if we can complete, and complete if so.\n              checkComplete();\n            } catch (err) {\n              subscriber.error(err);\n            }\n          }\n        }\n      )\n    );\n  };\n\n  // Subscribe to our source observable.\n  source.subscribe(\n    createOperatorSubscriber(subscriber, outerNext, () => {\n      // Outer completed, make a note of it, and check to see if we can complete everything.\n      isComplete = true;\n      checkComplete();\n    })\n  );\n\n  // Additional finalization (for when the destination is torn down).\n  // Other finalization is added implicitly via subscription above.\n  return () => {\n    additionalFinalizer?.();\n  };\n}\n", "import { ObservableInput, OperatorFunction, ObservedValueOf } from '../types';\nimport { map } from './map';\nimport { innerFrom } from '../observable/innerFrom';\nimport { operate } from '../util/lift';\nimport { mergeInternals } from './mergeInternals';\nimport { isFunction } from '../util/isFunction';\n\n/* tslint:disable:max-line-length */\nexport function mergeMap<T, O extends ObservableInput<any>>(\n  project: (value: T, index: number) => O,\n  concurrent?: number\n): OperatorFunction<T, ObservedValueOf<O>>;\n/** @deprecated The `resultSelector` parameter will be removed in v8. Use an inner `map` instead. Details: https://rxjs.dev/deprecations/resultSelector */\nexport function mergeMap<T, O extends ObservableInput<any>>(\n  project: (value: T, index: number) => O,\n  resultSelector: undefined,\n  concurrent?: number\n): OperatorFunction<T, ObservedValueOf<O>>;\n/** @deprecated The `resultSelector` parameter will be removed in v8. Use an inner `map` instead. Details: https://rxjs.dev/deprecations/resultSelector */\nexport function mergeMap<T, R, O extends ObservableInput<any>>(\n  project: (value: T, index: number) => O,\n  resultSelector: (outerValue: T, innerValue: ObservedValueOf<O>, outerIndex: number, innerIndex: number) => R,\n  concurrent?: number\n): OperatorFunction<T, R>;\n/* tslint:enable:max-line-length */\n\n/**\n * Projects each source value to an Observable which is merged in the output\n * Observable.\n *\n * <span class=\"informal\">Maps each value to an Observable, then flattens all of\n * these inner Observables using {@link mergeAll}.</span>\n *\n * ![](mergeMap.png)\n *\n * Returns an Observable that emits items based on applying a function that you\n * supply to each item emitted by the source Observable, where that function\n * returns an Observable, and then merging those resulting Observables and\n * emitting the results of this merger.\n *\n * ## Example\n *\n * Map and flatten each letter to an Observable ticking every 1 second\n *\n * ```ts\n * import { of, mergeMap, interval, map } from 'rxjs';\n *\n * const letters = of('a', 'b', 'c');\n * const result = letters.pipe(\n *   mergeMap(x => interval(1000).pipe(map(i => x + i)))\n * );\n *\n * result.subscribe(x => console.log(x));\n *\n * // Results in the following:\n * // a0\n * // b0\n * // c0\n * // a1\n * // b1\n * // c1\n * // continues to list a, b, c every second with respective ascending integers\n * ```\n *\n * @see {@link concatMap}\n * @see {@link exhaustMap}\n * @see {@link merge}\n * @see {@link mergeAll}\n * @see {@link mergeMapTo}\n * @see {@link mergeScan}\n * @see {@link switchMap}\n *\n * @param {function(value: T, ?index: number): ObservableInput} project A function\n * that, when applied to an item emitted by the source Observable, returns an\n * Observable.\n * @param {number} [concurrent=Infinity] Maximum number of input\n * Observables being subscribed to concurrently.\n * @return A function that returns an Observable that emits the result of\n * applying the projection function (and the optional deprecated\n * `resultSelector`) to each item emitted by the source Observable and merging\n * the results of the Observables obtained from this transformation.\n */\nexport function mergeMap<T, R, O extends ObservableInput<any>>(\n  project: (value: T, index: number) => O,\n  resultSelector?: ((outerValue: T, innerValue: ObservedValueOf<O>, outerIndex: number, innerIndex: number) => R) | number,\n  concurrent: number = Infinity\n): OperatorFunction<T, ObservedValueOf<O> | R> {\n  if (isFunction(resultSelector)) {\n    // DEPRECATED PATH\n    return mergeMap((a, i) => map((b: any, ii: number) => resultSelector(a, b, i, ii))(innerFrom(project(a, i))), concurrent);\n  } else if (typeof resultSelector === 'number') {\n    concurrent = resultSelector;\n  }\n\n  return operate((source, subscriber) => mergeInternals(source, subscriber, project, concurrent));\n}\n", "import { mergeMap } from './mergeMap';\nimport { identity } from '../util/identity';\nimport { OperatorFunction, ObservableInput, ObservedValueOf } from '../types';\n\n/**\n * Converts a higher-order Observable into a first-order Observable which\n * concurrently delivers all values that are emitted on the inner Observables.\n *\n * <span class=\"informal\">Flattens an Observable-of-Observables.</span>\n *\n * ![](mergeAll.png)\n *\n * `mergeAll` subscribes to an Observable that emits Observables, also known as\n * a higher-order Observable. Each time it observes one of these emitted inner\n * Observables, it subscribes to that and delivers all the values from the\n * inner Observable on the output Observable. The output Observable only\n * completes once all inner Observables have completed. Any error delivered by\n * a inner Observable will be immediately emitted on the output Observable.\n *\n * ## Examples\n *\n * Spawn a new interval Observable for each click event, and blend their outputs as one Observable\n *\n * ```ts\n * import { fromEvent, map, interval, mergeAll } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const higherOrder = clicks.pipe(map(() => interval(1000)));\n * const firstOrder = higherOrder.pipe(mergeAll());\n *\n * firstOrder.subscribe(x => console.log(x));\n * ```\n *\n * Count from 0 to 9 every second for each click, but only allow 2 concurrent timers\n *\n * ```ts\n * import { fromEvent, map, interval, take, mergeAll } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const higherOrder = clicks.pipe(\n *   map(() => interval(1000).pipe(take(10)))\n * );\n * const firstOrder = higherOrder.pipe(mergeAll(2));\n *\n * firstOrder.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link combineLatestAll}\n * @see {@link concatAll}\n * @see {@link exhaustAll}\n * @see {@link merge}\n * @see {@link mergeMap}\n * @see {@link mergeMapTo}\n * @see {@link mergeScan}\n * @see {@link switchAll}\n * @see {@link switchMap}\n * @see {@link zipAll}\n *\n * @param {number} [concurrent=Infinity] Maximum number of inner\n * Observables being subscribed to concurrently.\n * @return A function that returns an Observable that emits values coming from\n * all the inner Observables emitted by the source Observable.\n */\nexport function mergeAll<O extends ObservableInput<any>>(concurrent: number = Infinity): OperatorFunction<O, ObservedValueOf<O>> {\n  return mergeMap(identity, concurrent);\n}\n", "import { mergeAll } from './mergeAll';\nimport { OperatorFunction, ObservableInput, ObservedValueOf } from '../types';\n\n/**\n * Converts a higher-order Observable into a first-order Observable by\n * concatenating the inner Observables in order.\n *\n * <span class=\"informal\">Flattens an Observable-of-Observables by putting one\n * inner Observable after the other.</span>\n *\n * ![](concatAll.svg)\n *\n * Joins every Observable emitted by the source (a higher-order Observable), in\n * a serial fashion. It subscribes to each inner Observable only after the\n * previous inner Observable has completed, and merges all of their values into\n * the returned observable.\n *\n * __Warning:__ If the source Observable emits Observables quickly and\n * endlessly, and the inner Observables it emits generally complete slower than\n * the source emits, you can run into memory issues as the incoming Observables\n * collect in an unbounded buffer.\n *\n * Note: `concatAll` is equivalent to `mergeAll` with concurrency parameter set\n * to `1`.\n *\n * ## Example\n *\n * For each click event, tick every second from 0 to 3, with no concurrency\n *\n * ```ts\n * import { fromEvent, map, interval, take, concatAll } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const higherOrder = clicks.pipe(\n *   map(() => interval(1000).pipe(take(4)))\n * );\n * const firstOrder = higherOrder.pipe(concatAll());\n * firstOrder.subscribe(x => console.log(x));\n *\n * // Results in the following:\n * // (results are not concurrent)\n * // For every click on the \"document\" it will emit values 0 to 3 spaced\n * // on a 1000ms interval\n * // one click = 1000ms-> 0 -1000ms-> 1 -1000ms-> 2 -1000ms-> 3\n * ```\n *\n * @see {@link combineLatestAll}\n * @see {@link concat}\n * @see {@link concatMap}\n * @see {@link concatMapTo}\n * @see {@link exhaustAll}\n * @see {@link mergeAll}\n * @see {@link switchAll}\n * @see {@link switchMap}\n * @see {@link zipAll}\n *\n * @return A function that returns an Observable emitting values from all the\n * inner Observables concatenated.\n */\nexport function concatAll<O extends ObservableInput<any>>(): OperatorFunction<O, ObservedValueOf<O>> {\n  return mergeAll(1);\n}\n", "import { Observable } from '../Observable';\nimport { ObservableInputTuple, SchedulerLike } from '../types';\nimport { concatAll } from '../operators/concatAll';\nimport { popScheduler } from '../util/args';\nimport { from } from './from';\n\nexport function concat<T extends readonly unknown[]>(...inputs: [...ObservableInputTuple<T>]): Observable<T[number]>;\nexport function concat<T extends readonly unknown[]>(\n  ...inputsAndScheduler: [...ObservableInputTuple<T>, SchedulerLike]\n): Observable<T[number]>;\n\n/**\n * Creates an output Observable which sequentially emits all values from the first given\n * Observable and then moves on to the next.\n *\n * <span class=\"informal\">Concatenates multiple Observables together by\n * sequentially emitting their values, one Observable after the other.</span>\n *\n * ![](concat.png)\n *\n * `concat` joins multiple Observables together, by subscribing to them one at a time and\n * merging their results into the output Observable. You can pass either an array of\n * Observables, or put them directly as arguments. Passing an empty array will result\n * in Observable that completes immediately.\n *\n * `concat` will subscribe to first input Observable and emit all its values, without\n * changing or affecting them in any way. When that Observable completes, it will\n * subscribe to then next Observable passed and, again, emit its values. This will be\n * repeated, until the operator runs out of Observables. When last input Observable completes,\n * `concat` will complete as well. At any given moment only one Observable passed to operator\n * emits values. If you would like to emit values from passed Observables concurrently, check out\n * {@link merge} instead, especially with optional `concurrent` parameter. As a matter of fact,\n * `concat` is an equivalent of `merge` operator with `concurrent` parameter set to `1`.\n *\n * Note that if some input Observable never completes, `concat` will also never complete\n * and Observables following the one that did not complete will never be subscribed. On the other\n * hand, if some Observable simply completes immediately after it is subscribed, it will be\n * invisible for `concat`, which will just move on to the next Observable.\n *\n * If any Observable in chain errors, instead of passing control to the next Observable,\n * `concat` will error immediately as well. Observables that would be subscribed after\n * the one that emitted error, never will.\n *\n * If you pass to `concat` the same Observable many times, its stream of values\n * will be \"replayed\" on every subscription, which means you can repeat given Observable\n * as many times as you like. If passing the same Observable to `concat` 1000 times becomes tedious,\n * you can always use {@link repeat}.\n *\n * ## Examples\n *\n * Concatenate a timer counting from 0 to 3 with a synchronous sequence from 1 to 10\n *\n * ```ts\n * import { interval, take, range, concat } from 'rxjs';\n *\n * const timer = interval(1000).pipe(take(4));\n * const sequence = range(1, 10);\n * const result = concat(timer, sequence);\n * result.subscribe(x => console.log(x));\n *\n * // results in:\n * // 0 -1000ms-> 1 -1000ms-> 2 -1000ms-> 3 -immediate-> 1 ... 10\n * ```\n *\n * Concatenate 3 Observables\n *\n * ```ts\n * import { interval, take, concat } from 'rxjs';\n *\n * const timer1 = interval(1000).pipe(take(10));\n * const timer2 = interval(2000).pipe(take(6));\n * const timer3 = interval(500).pipe(take(10));\n *\n * const result = concat(timer1, timer2, timer3);\n * result.subscribe(x => console.log(x));\n *\n * // results in the following:\n * // (Prints to console sequentially)\n * // -1000ms-> 0 -1000ms-> 1 -1000ms-> ... 9\n * // -2000ms-> 0 -2000ms-> 1 -2000ms-> ... 5\n * // -500ms-> 0 -500ms-> 1 -500ms-> ... 9\n * ```\n *\n * Concatenate the same Observable to repeat it\n *\n * ```ts\n * import { interval, take, concat } from 'rxjs';\n *\n * const timer = interval(1000).pipe(take(2));\n *\n * concat(timer, timer) // concatenating the same Observable!\n *   .subscribe({\n *     next: value => console.log(value),\n *     complete: () => console.log('...and it is done!')\n *   });\n *\n * // Logs:\n * // 0 after 1s\n * // 1 after 2s\n * // 0 after 3s\n * // 1 after 4s\n * // '...and it is done!' also after 4s\n * ```\n *\n * @see {@link concatAll}\n * @see {@link concatMap}\n * @see {@link concatMapTo}\n * @see {@link startWith}\n * @see {@link endWith}\n *\n * @param args Input Observables to concatenate.\n */\nexport function concat(...args: any[]): Observable<unknown> {\n  return concatAll()(from(args, popScheduler(args)));\n}\n", "import { Observable } from '../Observable';\nimport { ObservedValueOf, ObservableInput } from '../types';\nimport { innerFrom } from './innerFrom';\n\n/**\n * Creates an Observable that, on subscribe, calls an Observable factory to\n * make an Observable for each new Observer.\n *\n * <span class=\"informal\">Creates the Observable lazily, that is, only when it\n * is subscribed.\n * </span>\n *\n * ![](defer.png)\n *\n * `defer` allows you to create an Observable only when the Observer\n * subscribes. It waits until an Observer subscribes to it, calls the given\n * factory function to get an Observable -- where a factory function typically\n * generates a new Observable -- and subscribes the Observer to this Observable.\n * In case the factory function returns a falsy value, then EMPTY is used as\n * Observable instead. Last but not least, an exception during the factory\n * function call is transferred to the Observer by calling `error`.\n *\n * ## Example\n *\n * Subscribe to either an Observable of clicks or an Observable of interval, at random\n *\n * ```ts\n * import { defer, fromEvent, interval } from 'rxjs';\n *\n * const clicksOrInterval = defer(() => {\n *   return Math.random() > 0.5\n *     ? fromEvent(document, 'click')\n *     : interval(1000);\n * });\n * clicksOrInterval.subscribe(x => console.log(x));\n *\n * // Results in the following behavior:\n * // If the result of Math.random() is greater than 0.5 it will listen\n * // for clicks anywhere on the \"document\"; when document is clicked it\n * // will log a MouseEvent object to the console. If the result is less\n * // than 0.5 it will emit ascending numbers, one every second(1000ms).\n * ```\n *\n * @see {@link Observable}\n *\n * @param {function(): ObservableInput} observableFactory The Observable\n * factory function to invoke for each Observer that subscribes to the output\n * Observable. May also return a Promise, which will be converted on the fly\n * to an Observable.\n * @return {Observable} An Observable whose Observers' subscriptions trigger\n * an invocation of the given Observable factory function.\n */\nexport function defer<R extends ObservableInput<any>>(observableFactory: () => R): Observable<ObservedValueOf<R>> {\n  return new Observable<ObservedValueOf<R>>((subscriber) => {\n    innerFrom(observableFactory()).subscribe(subscriber);\n  });\n}\n", "import { innerFrom } from '../observable/innerFrom';\nimport { Observable } from '../Observable';\nimport { mergeMap } from '../operators/mergeMap';\nimport { isArrayLike } from '../util/isArrayLike';\nimport { isFunction } from '../util/isFunction';\nimport { mapOneOrManyArgs } from '../util/mapOneOrManyArgs';\n\n// These constants are used to create handler registry functions using array mapping below.\nconst nodeEventEmitterMethods = ['addListener', 'removeListener'] as const;\nconst eventTargetMethods = ['addEventListener', 'removeEventListener'] as const;\nconst jqueryMethods = ['on', 'off'] as const;\n\nexport interface NodeStyleEventEmitter {\n  addListener(eventName: string | symbol, handler: NodeEventHandler): this;\n  removeListener(eventName: string | symbol, handler: NodeEventHandler): this;\n}\n\nexport type NodeEventHandler = (...args: any[]) => void;\n\n// For APIs that implement `addListener` and `removeListener` methods that may\n// not use the same arguments or return EventEmitter values\n// such as React Native\nexport interface NodeCompatibleEventEmitter {\n  addListener(eventName: string, handler: NodeEventHandler): void | {};\n  removeListener(eventName: string, handler: NodeEventHandler): void | {};\n}\n\n// Use handler types like those in @types/jquery. See:\n// https://github.com/DefinitelyTyped/DefinitelyTyped/blob/847731ba1d7fa6db6b911c0e43aa0afe596e7723/types/jquery/misc.d.ts#L6395\nexport interface JQueryStyleEventEmitter<TContext, T> {\n  on(eventName: string, handler: (this: TContext, t: T, ...args: any[]) => any): void;\n  off(eventName: string, handler: (this: TContext, t: T, ...args: any[]) => any): void;\n}\n\nexport interface EventListenerObject<E> {\n  handleEvent(evt: E): void;\n}\n\nexport interface HasEventTargetAddRemove<E> {\n  addEventListener(\n    type: string,\n    listener: ((evt: E) => void) | EventListenerObject<E> | null,\n    options?: boolean | AddEventListenerOptions\n  ): void;\n  removeEventListener(\n    type: string,\n    listener: ((evt: E) => void) | EventListenerObject<E> | null,\n    options?: EventListenerOptions | boolean\n  ): void;\n}\n\nexport interface EventListenerOptions {\n  capture?: boolean;\n  passive?: boolean;\n  once?: boolean;\n}\n\nexport interface AddEventListenerOptions extends EventListenerOptions {\n  once?: boolean;\n  passive?: boolean;\n}\n\nexport function fromEvent<T>(target: HasEventTargetAddRemove<T> | ArrayLike<HasEventTargetAddRemove<T>>, eventName: string): Observable<T>;\nexport function fromEvent<T, R>(\n  target: HasEventTargetAddRemove<T> | ArrayLike<HasEventTargetAddRemove<T>>,\n  eventName: string,\n  resultSelector: (event: T) => R\n): Observable<R>;\nexport function fromEvent<T>(\n  target: HasEventTargetAddRemove<T> | ArrayLike<HasEventTargetAddRemove<T>>,\n  eventName: string,\n  options: EventListenerOptions\n): Observable<T>;\nexport function fromEvent<T, R>(\n  target: HasEventTargetAddRemove<T> | ArrayLike<HasEventTargetAddRemove<T>>,\n  eventName: string,\n  options: EventListenerOptions,\n  resultSelector: (event: T) => R\n): Observable<R>;\n\nexport function fromEvent(target: NodeStyleEventEmitter | ArrayLike<NodeStyleEventEmitter>, eventName: string): Observable<unknown>;\n/** @deprecated Do not specify explicit type parameters. Signatures with type parameters that cannot be inferred will be removed in v8. */\nexport function fromEvent<T>(target: NodeStyleEventEmitter | ArrayLike<NodeStyleEventEmitter>, eventName: string): Observable<T>;\nexport function fromEvent<R>(\n  target: NodeStyleEventEmitter | ArrayLike<NodeStyleEventEmitter>,\n  eventName: string,\n  resultSelector: (...args: any[]) => R\n): Observable<R>;\n\nexport function fromEvent(\n  target: NodeCompatibleEventEmitter | ArrayLike<NodeCompatibleEventEmitter>,\n  eventName: string\n): Observable<unknown>;\n/** @deprecated Do not specify explicit type parameters. Signatures with type parameters that cannot be inferred will be removed in v8. */\nexport function fromEvent<T>(target: NodeCompatibleEventEmitter | ArrayLike<NodeCompatibleEventEmitter>, eventName: string): Observable<T>;\nexport function fromEvent<R>(\n  target: NodeCompatibleEventEmitter | ArrayLike<NodeCompatibleEventEmitter>,\n  eventName: string,\n  resultSelector: (...args: any[]) => R\n): Observable<R>;\n\nexport function fromEvent<T>(\n  target: JQueryStyleEventEmitter<any, T> | ArrayLike<JQueryStyleEventEmitter<any, T>>,\n  eventName: string\n): Observable<T>;\nexport function fromEvent<T, R>(\n  target: JQueryStyleEventEmitter<any, T> | ArrayLike<JQueryStyleEventEmitter<any, T>>,\n  eventName: string,\n  resultSelector: (value: T, ...args: any[]) => R\n): Observable<R>;\n\n/**\n * Creates an Observable that emits events of a specific type coming from the\n * given event target.\n *\n * <span class=\"informal\">Creates an Observable from DOM events, or Node.js\n * EventEmitter events or others.</span>\n *\n * ![](fromEvent.png)\n *\n * `fromEvent` accepts as a first argument event target, which is an object with methods\n * for registering event handler functions. As a second argument it takes string that indicates\n * type of event we want to listen for. `fromEvent` supports selected types of event targets,\n * which are described in detail below. If your event target does not match any of the ones listed,\n * you should use {@link fromEventPattern}, which can be used on arbitrary APIs.\n * When it comes to APIs supported by `fromEvent`, their methods for adding and removing event\n * handler functions have different names, but they all accept a string describing event type\n * and function itself, which will be called whenever said event happens.\n *\n * Every time resulting Observable is subscribed, event handler function will be registered\n * to event target on given event type. When that event fires, value\n * passed as a first argument to registered function will be emitted by output Observable.\n * When Observable is unsubscribed, function will be unregistered from event target.\n *\n * Note that if event target calls registered function with more than one argument, second\n * and following arguments will not appear in resulting stream. In order to get access to them,\n * you can pass to `fromEvent` optional project function, which will be called with all arguments\n * passed to event handler. Output Observable will then emit value returned by project function,\n * instead of the usual value.\n *\n * Remember that event targets listed below are checked via duck typing. It means that\n * no matter what kind of object you have and no matter what environment you work in,\n * you can safely use `fromEvent` on that object if it exposes described methods (provided\n * of course they behave as was described above). So for example if Node.js library exposes\n * event target which has the same method names as DOM EventTarget, `fromEvent` is still\n * a good choice.\n *\n * If the API you use is more callback then event handler oriented (subscribed\n * callback function fires only once and thus there is no need to manually\n * unregister it), you should use {@link bindCallback} or {@link bindNodeCallback}\n * instead.\n *\n * `fromEvent` supports following types of event targets:\n *\n * **DOM EventTarget**\n *\n * This is an object with `addEventListener` and `removeEventListener` methods.\n *\n * In the browser, `addEventListener` accepts - apart from event type string and event\n * handler function arguments - optional third parameter, which is either an object or boolean,\n * both used for additional configuration how and when passed function will be called. When\n * `fromEvent` is used with event target of that type, you can provide this values\n * as third parameter as well.\n *\n * **Node.js EventEmitter**\n *\n * An object with `addListener` and `removeListener` methods.\n *\n * **JQuery-style event target**\n *\n * An object with `on` and `off` methods\n *\n * **DOM NodeList**\n *\n * List of DOM Nodes, returned for example by `document.querySelectorAll` or `Node.childNodes`.\n *\n * Although this collection is not event target in itself, `fromEvent` will iterate over all Nodes\n * it contains and install event handler function in every of them. When returned Observable\n * is unsubscribed, function will be removed from all Nodes.\n *\n * **DOM HtmlCollection**\n *\n * Just as in case of NodeList it is a collection of DOM nodes. Here as well event handler function is\n * installed and removed in each of elements.\n *\n *\n * ## Examples\n *\n * Emit clicks happening on the DOM document\n *\n * ```ts\n * import { fromEvent } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * clicks.subscribe(x => console.log(x));\n *\n * // Results in:\n * // MouseEvent object logged to console every time a click\n * // occurs on the document.\n * ```\n *\n * Use `addEventListener` with capture option\n *\n * ```ts\n * import { fromEvent } from 'rxjs';\n *\n * const div = document.createElement('div');\n * div.style.cssText = 'width: 200px; height: 200px; background: #09c;';\n * document.body.appendChild(div);\n *\n * // note optional configuration parameter which will be passed to addEventListener\n * const clicksInDocument = fromEvent(document, 'click', { capture: true });\n * const clicksInDiv = fromEvent(div, 'click');\n *\n * clicksInDocument.subscribe(() => console.log('document'));\n * clicksInDiv.subscribe(() => console.log('div'));\n *\n * // By default events bubble UP in DOM tree, so normally\n * // when we would click on div in document\n * // \"div\" would be logged first and then \"document\".\n * // Since we specified optional `capture` option, document\n * // will catch event when it goes DOWN DOM tree, so console\n * // will log \"document\" and then \"div\".\n * ```\n *\n * @see {@link bindCallback}\n * @see {@link bindNodeCallback}\n * @see {@link fromEventPattern}\n *\n * @param {FromEventTarget<T>} target The DOM EventTarget, Node.js\n * EventEmitter, JQuery-like event target, NodeList or HTMLCollection to attach the event handler to.\n * @param {string} eventName The event name of interest, being emitted by the\n * `target`.\n * @param {EventListenerOptions} [options] Options to pass through to addEventListener\n * @return {Observable<T>}\n */\nexport function fromEvent<T>(\n  target: any,\n  eventName: string,\n  options?: EventListenerOptions | ((...args: any[]) => T),\n  resultSelector?: (...args: any[]) => T\n): Observable<T> {\n  if (isFunction(options)) {\n    resultSelector = options;\n    options = undefined;\n  }\n  if (resultSelector) {\n    return fromEvent<T>(target, eventName, options as EventListenerOptions).pipe(mapOneOrManyArgs(resultSelector));\n  }\n\n  // Figure out our add and remove methods. In order to do this,\n  // we are going to analyze the target in a preferred order, if\n  // the target matches a given signature, we take the two \"add\" and \"remove\"\n  // method names and apply them to a map to create opposite versions of the\n  // same function. This is because they all operate in duplicate pairs,\n  // `addListener(name, handler)`, `removeListener(name, handler)`, for example.\n  // The call only differs by method name, as to whether or not you're adding or removing.\n  const [add, remove] =\n    // If it is an EventTarget, we need to use a slightly different method than the other two patterns.\n    isEventTarget(target)\n      ? eventTargetMethods.map((methodName) => (handler: any) => target[methodName](eventName, handler, options as EventListenerOptions))\n      : // In all other cases, the call pattern is identical with the exception of the method names.\n      isNodeStyleEventEmitter(target)\n      ? nodeEventEmitterMethods.map(toCommonHandlerRegistry(target, eventName))\n      : isJQueryStyleEventEmitter(target)\n      ? jqueryMethods.map(toCommonHandlerRegistry(target, eventName))\n      : [];\n\n  // If add is falsy, it's because we didn't match a pattern above.\n  // Check to see if it is an ArrayLike, because if it is, we want to\n  // try to apply fromEvent to all of it's items. We do this check last,\n  // because there are may be some types that are both ArrayLike *and* implement\n  // event registry points, and we'd rather delegate to that when possible.\n  if (!add) {\n    if (isArrayLike(target)) {\n      return mergeMap((subTarget: any) => fromEvent(subTarget, eventName, options as EventListenerOptions))(\n        innerFrom(target)\n      ) as Observable<T>;\n    }\n  }\n\n  // If add is falsy and we made it here, it's because we didn't\n  // match any valid target objects above.\n  if (!add) {\n    throw new TypeError('Invalid event target');\n  }\n\n  return new Observable<T>((subscriber) => {\n    // The handler we are going to register. Forwards the event object, by itself, or\n    // an array of arguments to the event handler, if there is more than one argument,\n    // to the consumer.\n    const handler = (...args: any[]) => subscriber.next(1 < args.length ? args : args[0]);\n    // Do the work of adding the handler to the target.\n    add(handler);\n    // When we finalize, we want to remove the handler and free up memory.\n    return () => remove!(handler);\n  });\n}\n\n/**\n * Used to create `add` and `remove` functions to register and unregister event handlers\n * from a target in the most common handler pattern, where there are only two arguments.\n * (e.g.  `on(name, fn)`, `off(name, fn)`, `addListener(name, fn)`, or `removeListener(name, fn)`)\n * @param target The target we're calling methods on\n * @param eventName The event name for the event we're creating register or unregister functions for\n */\nfunction toCommonHandlerRegistry(target: any, eventName: string) {\n  return (methodName: string) => (handler: any) => target[methodName](eventName, handler);\n}\n\n/**\n * Checks to see if the target implements the required node-style EventEmitter methods\n * for adding and removing event handlers.\n * @param target the object to check\n */\nfunction isNodeStyleEventEmitter(target: any): target is NodeStyleEventEmitter {\n  return isFunction(target.addListener) && isFunction(target.removeListener);\n}\n\n/**\n * Checks to see if the target implements the required jQuery-style EventEmitter methods\n * for adding and removing event handlers.\n * @param target the object to check\n */\nfunction isJQueryStyleEventEmitter(target: any): target is JQueryStyleEventEmitter<any, any> {\n  return isFunction(target.on) && isFunction(target.off);\n}\n\n/**\n * Checks to see if the target implements the required EventTarget methods\n * for adding and removing event handlers.\n * @param target the object to check\n */\nfunction isEventTarget(target: any): target is HasEventTargetAddRemove<any> {\n  return isFunction(target.addEventListener) && isFunction(target.removeEventListener);\n}\n", "import { Observable } from '../Observable';\nimport { isFunction } from '../util/isFunction';\nimport { NodeEventHandler } from './fromEvent';\nimport { mapOneOrManyArgs } from '../util/mapOneOrManyArgs';\n\n/* tslint:disable:max-line-length */\nexport function fromEventPattern<T>(\n  addHandler: (handler: NodeEventHandler) => any,\n  removeHandler?: (handler: NodeEventHandler, signal?: any) => void\n): Observable<T>;\nexport function fromEventPattern<T>(\n  addHandler: (handler: NodeEventHandler) => any,\n  removeHandler?: (handler: NodeEventHandler, signal?: any) => void,\n  resultSelector?: (...args: any[]) => T\n): Observable<T>;\n/* tslint:enable:max-line-length */\n\n/**\n * Creates an Observable from an arbitrary API for registering event handlers.\n *\n * <span class=\"informal\">When that method for adding event handler was something {@link fromEvent}\n * was not prepared for.</span>\n *\n * ![](fromEventPattern.png)\n *\n * `fromEventPattern` allows you to convert into an Observable any API that supports registering handler functions\n * for events. It is similar to {@link fromEvent}, but far\n * more flexible. In fact, all use cases of {@link fromEvent} could be easily handled by\n * `fromEventPattern` (although in slightly more verbose way).\n *\n * This operator accepts as a first argument an `addHandler` function, which will be injected with\n * handler parameter. That handler is actually an event handler function that you now can pass\n * to API expecting it. `addHandler` will be called whenever Observable\n * returned by the operator is subscribed, so registering handler in API will not\n * necessarily happen when `fromEventPattern` is called.\n *\n * After registration, every time an event that we listen to happens,\n * Observable returned by `fromEventPattern` will emit value that event handler\n * function was called with. Note that if event handler was called with more\n * than one argument, second and following arguments will not appear in the Observable.\n *\n * If API you are using allows to unregister event handlers as well, you can pass to `fromEventPattern`\n * another function - `removeHandler` - as a second parameter. It will be injected\n * with the same handler function as before, which now you can use to unregister\n * it from the API. `removeHandler` will be called when consumer of resulting Observable\n * unsubscribes from it.\n *\n * In some APIs unregistering is actually handled differently. Method registering an event handler\n * returns some kind of token, which is later used to identify which function should\n * be unregistered or it itself has method that unregisters event handler.\n * If that is the case with your API, make sure token returned\n * by registering method is returned by `addHandler`. Then it will be passed\n * as a second argument to `removeHandler`, where you will be able to use it.\n *\n * If you need access to all event handler parameters (not only the first one),\n * or you need to transform them in any way, you can call `fromEventPattern` with optional\n * third parameter - project function which will accept all arguments passed to\n * event handler when it is called. Whatever is returned from project function will appear on\n * resulting stream instead of usual event handlers first argument. This means\n * that default project can be thought of as function that takes its first parameter\n * and ignores the rest.\n *\n * ## Examples\n *\n * Emits clicks happening on the DOM document\n *\n * ```ts\n * import { fromEventPattern } from 'rxjs';\n *\n * function addClickHandler(handler) {\n *   document.addEventListener('click', handler);\n * }\n *\n * function removeClickHandler(handler) {\n *   document.removeEventListener('click', handler);\n * }\n *\n * const clicks = fromEventPattern(\n *   addClickHandler,\n *   removeClickHandler\n * );\n * clicks.subscribe(x => console.log(x));\n *\n * // Whenever you click anywhere in the browser, DOM MouseEvent\n * // object will be logged.\n * ```\n *\n * Use with API that returns cancellation token\n *\n * ```ts\n * import { fromEventPattern } from 'rxjs';\n *\n * const token = someAPI.registerEventHandler(function() {});\n * someAPI.unregisterEventHandler(token); // this APIs cancellation method accepts\n *                                        // not handler itself, but special token.\n *\n * const someAPIObservable = fromEventPattern(\n *   function(handler) { return someAPI.registerEventHandler(handler); }, // Note that we return the token here...\n *   function(handler, token) { someAPI.unregisterEventHandler(token); }  // ...to then use it here.\n * );\n * ```\n *\n * Use with project function\n *\n * ```ts\n * import { fromEventPattern } from 'rxjs';\n *\n * someAPI.registerEventHandler((eventType, eventMessage) => {\n *   console.log(eventType, eventMessage); // Logs 'EVENT_TYPE' 'EVENT_MESSAGE' to console.\n * });\n *\n * const someAPIObservable = fromEventPattern(\n *   handler => someAPI.registerEventHandler(handler),\n *   handler => someAPI.unregisterEventHandler(handler)\n *   (eventType, eventMessage) => eventType + ' --- ' + eventMessage // without that function only 'EVENT_TYPE'\n * );                                                                // would be emitted by the Observable\n *\n * someAPIObservable.subscribe(value => console.log(value));\n *\n * // Logs:\n * // 'EVENT_TYPE --- EVENT_MESSAGE'\n * ```\n *\n * @see {@link fromEvent}\n * @see {@link bindCallback}\n * @see {@link bindNodeCallback}\n *\n * @param {function(handler: Function): any} addHandler A function that takes\n * a `handler` function as argument and attaches it somehow to the actual\n * source of events.\n * @param {function(handler: Function, token?: any): void} [removeHandler] A function that\n * takes a `handler` function as an argument and removes it from the event source. If `addHandler`\n * returns some kind of token, `removeHandler` function will have it as a second parameter.\n * @param {function(...args: any): T} [project] A function to\n * transform results. It takes the arguments from the event handler and\n * should return a single value.\n * @return {Observable<T>} Observable which, when an event happens, emits first parameter\n * passed to registered event handler. Alternatively it emits whatever project function returns\n * at that moment.\n */\nexport function fromEventPattern<T>(\n  addHandler: (handler: NodeEventHandler) => any,\n  removeHandler?: (handler: NodeEventHandler, signal?: any) => void,\n  resultSelector?: (...args: any[]) => T\n): Observable<T | T[]> {\n  if (resultSelector) {\n    return fromEventPattern<T>(addHandler, removeHandler).pipe(mapOneOrManyArgs(resultSelector));\n  }\n\n  return new Observable<T | T[]>((subscriber) => {\n    const handler = (...e: T[]) => subscriber.next(e.length === 1 ? e[0] : e);\n    const retValue = addHandler(handler);\n    return isFunction(removeHandler) ? () => removeHandler(handler, retValue) : undefined;\n  });\n}\n", "import { Observable } from '../Observable';\nimport { SchedulerLike } from '../types';\nimport { async as asyncScheduler } from '../scheduler/async';\nimport { isScheduler } from '../util/isScheduler';\nimport { isValidDate } from '../util/isDate';\n\n/**\n * Creates an observable that will wait for a specified time period, or exact date, before\n * emitting the number 0.\n *\n * <span class=\"informal\">Used to emit a notification after a delay.</span>\n *\n * This observable is useful for creating delays in code, or racing against other values\n * for ad-hoc timeouts.\n *\n * The `delay` is specified by default in milliseconds, however providing a custom scheduler could\n * create a different behavior.\n *\n * ## Examples\n *\n * Wait 3 seconds and start another observable\n *\n * You might want to use `timer` to delay subscription to an\n * observable by a set amount of time. Here we use a timer with\n * {@link concatMapTo} or {@link concatMap} in order to wait\n * a few seconds and start a subscription to a source.\n *\n * ```ts\n * import { of, timer, concatMap } from 'rxjs';\n *\n * // This could be any observable\n * const source = of(1, 2, 3);\n *\n * timer(3000)\n *   .pipe(concatMap(() => source))\n *   .subscribe(console.log);\n * ```\n *\n * Take all values until the start of the next minute\n *\n * Using a `Date` as the trigger for the first emission, you can\n * do things like wait until midnight to fire an event, or in this case,\n * wait until a new minute starts (chosen so the example wouldn't take\n * too long to run) in order to stop watching a stream. Leveraging\n * {@link takeUntil}.\n *\n * ```ts\n * import { interval, takeUntil, timer } from 'rxjs';\n *\n * // Build a Date object that marks the\n * // next minute.\n * const currentDate = new Date();\n * const startOfNextMinute = new Date(\n *   currentDate.getFullYear(),\n *   currentDate.getMonth(),\n *   currentDate.getDate(),\n *   currentDate.getHours(),\n *   currentDate.getMinutes() + 1\n * );\n *\n * // This could be any observable stream\n * const source = interval(1000);\n *\n * const result = source.pipe(\n *   takeUntil(timer(startOfNextMinute))\n * );\n *\n * result.subscribe(console.log);\n * ```\n *\n * ### Known Limitations\n *\n * - The {@link asyncScheduler} uses `setTimeout` which has limitations for how far in the future it can be scheduled.\n *\n * - If a `scheduler` is provided that returns a timestamp other than an epoch from `now()`, and\n * a `Date` object is passed to the `dueTime` argument, the calculation for when the first emission\n * should occur will be incorrect. In this case, it would be best to do your own calculations\n * ahead of time, and pass a `number` in as the `dueTime`.\n *\n * @param due If a `number`, the amount of time in milliseconds to wait before emitting.\n * If a `Date`, the exact time at which to emit.\n * @param scheduler The scheduler to use to schedule the delay. Defaults to {@link asyncScheduler}.\n */\nexport function timer(due: number | Date, scheduler?: SchedulerLike): Observable<0>;\n\n/**\n * Creates an observable that starts an interval after a specified delay, emitting incrementing numbers -- starting at `0` --\n * on each interval after words.\n *\n * The `delay` and `intervalDuration` are specified by default in milliseconds, however providing a custom scheduler could\n * create a different behavior.\n *\n * ## Example\n *\n * ### Start an interval that starts right away\n *\n * Since {@link interval} waits for the passed delay before starting,\n * sometimes that's not ideal. You may want to start an interval immediately.\n * `timer` works well for this. Here we have both side-by-side so you can\n * see them in comparison.\n *\n * Note that this observable will never complete.\n *\n * ```ts\n * import { timer, interval } from 'rxjs';\n *\n * timer(0, 1000).subscribe(n => console.log('timer', n));\n * interval(1000).subscribe(n => console.log('interval', n));\n * ```\n *\n * ### Known Limitations\n *\n * - The {@link asyncScheduler} uses `setTimeout` which has limitations for how far in the future it can be scheduled.\n *\n * - If a `scheduler` is provided that returns a timestamp other than an epoch from `now()`, and\n * a `Date` object is passed to the `dueTime` argument, the calculation for when the first emission\n * should occur will be incorrect. In this case, it would be best to do your own calculations\n * ahead of time, and pass a `number` in as the `startDue`.\n * @param startDue If a `number`, is the time to wait before starting the interval.\n * If a `Date`, is the exact time at which to start the interval.\n * @param intervalDuration The delay between each value emitted in the interval. Passing a\n * negative number here will result in immediate completion after the first value is emitted, as though\n * no `intervalDuration` was passed at all.\n * @param scheduler The scheduler to use to schedule the delay. Defaults to {@link asyncScheduler}.\n */\nexport function timer(startDue: number | Date, intervalDuration: number, scheduler?: SchedulerLike): Observable<number>;\n\n/**\n * @deprecated The signature allowing `undefined` to be passed for `intervalDuration` will be removed in v8. Use the `timer(dueTime, scheduler?)` signature instead.\n */\nexport function timer(dueTime: number | Date, unused: undefined, scheduler?: SchedulerLike): Observable<0>;\n\nexport function timer(\n  dueTime: number | Date = 0,\n  intervalOrScheduler?: number | SchedulerLike,\n  scheduler: SchedulerLike = asyncScheduler\n): Observable<number> {\n  // Since negative intervalDuration is treated as though no\n  // interval was specified at all, we start with a negative number.\n  let intervalDuration = -1;\n\n  if (intervalOrScheduler != null) {\n    // If we have a second argument, and it's a scheduler,\n    // override the scheduler we had defaulted. Otherwise,\n    // it must be an interval.\n    if (isScheduler(intervalOrScheduler)) {\n      scheduler = intervalOrScheduler;\n    } else {\n      // Note that this *could* be negative, in which case\n      // it's like not passing an intervalDuration at all.\n      intervalDuration = intervalOrScheduler;\n    }\n  }\n\n  return new Observable((subscriber) => {\n    // If a valid date is passed, calculate how long to wait before\n    // executing the first value... otherwise, if it's a number just schedule\n    // that many milliseconds (or scheduler-specified unit size) in the future.\n    let due = isValidDate(dueTime) ? +dueTime - scheduler!.now() : dueTime;\n\n    if (due < 0) {\n      // Ensure we don't schedule in the future.\n      due = 0;\n    }\n\n    // The incrementing value we emit.\n    let n = 0;\n\n    // Start the timer.\n    return scheduler.schedule(function () {\n      if (!subscriber.closed) {\n        // Emit the next value and increment.\n        subscriber.next(n++);\n\n        if (0 <= intervalDuration) {\n          // If we have a interval after the initial timer,\n          // reschedule with the period.\n          this.schedule(undefined, intervalDuration);\n        } else {\n          // We didn't have an interval. So just complete.\n          subscriber.complete();\n        }\n      }\n    }, due);\n  });\n}\n", "import { Observable } from '../Observable';\nimport { ObservableInput, ObservableInputTuple, SchedulerLike } from '../types';\nimport { mergeAll } from '../operators/mergeAll';\nimport { innerFrom } from './innerFrom';\nimport { EMPTY } from './empty';\nimport { popNumber, popScheduler } from '../util/args';\nimport { from } from './from';\n\nexport function merge<A extends readonly unknown[]>(...sources: [...ObservableInputTuple<A>]): Observable<A[number]>;\nexport function merge<A extends readonly unknown[]>(...sourcesAndConcurrency: [...ObservableInputTuple<A>, number?]): Observable<A[number]>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `mergeAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function merge<A extends readonly unknown[]>(\n  ...sourcesAndScheduler: [...ObservableInputTuple<A>, SchedulerLike?]\n): Observable<A[number]>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `mergeAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function merge<A extends readonly unknown[]>(\n  ...sourcesAndConcurrencyAndScheduler: [...ObservableInputTuple<A>, number?, SchedulerLike?]\n): Observable<A[number]>;\n\n/**\n * Creates an output Observable which concurrently emits all values from every\n * given input Observable.\n *\n * <span class=\"informal\">Flattens multiple Observables together by blending\n * their values into one Observable.</span>\n *\n * ![](merge.png)\n *\n * `merge` subscribes to each given input Observable (as arguments), and simply\n * forwards (without doing any transformation) all the values from all the input\n * Observables to the output Observable. The output Observable only completes\n * once all input Observables have completed. Any error delivered by an input\n * Observable will be immediately emitted on the output Observable.\n *\n * ## Examples\n *\n * Merge together two Observables: 1s interval and clicks\n *\n * ```ts\n * import { merge, fromEvent, interval } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const timer = interval(1000);\n * const clicksOrTimer = merge(clicks, timer);\n * clicksOrTimer.subscribe(x => console.log(x));\n *\n * // Results in the following:\n * // timer will emit ascending values, one every second(1000ms) to console\n * // clicks logs MouseEvents to console every time the \"document\" is clicked\n * // Since the two streams are merged you see these happening\n * // as they occur.\n * ```\n *\n * Merge together 3 Observables, but run only 2 concurrently\n *\n * ```ts\n * import { interval, take, merge } from 'rxjs';\n *\n * const timer1 = interval(1000).pipe(take(10));\n * const timer2 = interval(2000).pipe(take(6));\n * const timer3 = interval(500).pipe(take(10));\n *\n * const concurrent = 2; // the argument\n * const merged = merge(timer1, timer2, timer3, concurrent);\n * merged.subscribe(x => console.log(x));\n *\n * // Results in the following:\n * // - First timer1 and timer2 will run concurrently\n * // - timer1 will emit a value every 1000ms for 10 iterations\n * // - timer2 will emit a value every 2000ms for 6 iterations\n * // - after timer1 hits its max iteration, timer2 will\n * //   continue, and timer3 will start to run concurrently with timer2\n * // - when timer2 hits its max iteration it terminates, and\n * //   timer3 will continue to emit a value every 500ms until it is complete\n * ```\n *\n * @see {@link mergeAll}\n * @see {@link mergeMap}\n * @see {@link mergeMapTo}\n * @see {@link mergeScan}\n *\n * @param {...ObservableInput} observables Input Observables to merge together.\n * @param {number} [concurrent=Infinity] Maximum number of input\n * Observables being subscribed to concurrently.\n * @param {SchedulerLike} [scheduler=null] The {@link SchedulerLike} to use for managing\n * concurrency of input Observables.\n * @return {Observable} an Observable that emits items that are the result of\n * every input Observable.\n */\nexport function merge(...args: (ObservableInput<unknown> | number | SchedulerLike)[]): Observable<unknown> {\n  const scheduler = popScheduler(args);\n  const concurrent = popNumber(args, Infinity);\n  const sources = args as ObservableInput<unknown>[];\n  return !sources.length\n    ? // No source provided\n      EMPTY\n    : sources.length === 1\n    ? // One source? Just return it.\n      innerFrom(sources[0])\n    : // Merge all sources\n      mergeAll(concurrent)(from(sources, scheduler));\n}\n", "import { Observable } from '../Observable';\nimport { noop } from '../util/noop';\n\n/**\n * An Observable that emits no items to the Observer and never completes.\n *\n * ![](never.png)\n *\n * A simple Observable that emits neither values nor errors nor the completion\n * notification. It can be used for testing purposes or for composing with other\n * Observables. Please note that by never emitting a complete notification, this\n * Observable keeps the subscription from being disposed automatically.\n * Subscriptions need to be manually disposed.\n *\n * ##  Example\n *\n * Emit the number 7, then never emit anything else (not even complete)\n *\n * ```ts\n * import { NEVER, startWith } from 'rxjs';\n *\n * const info = () => console.log('Will not be called');\n *\n * const result = NEVER.pipe(startWith(7));\n * result.subscribe({\n *   next: x => console.log(x),\n *   error: info,\n *   complete: info\n * });\n * ```\n *\n * @see {@link Observable}\n * @see {@link EMPTY}\n * @see {@link of}\n * @see {@link throwError}\n */\nexport const NEVER = new Observable<never>(noop);\n\n/**\n * @deprecated Replaced with the {@link NEVER} constant. Will be removed in v8.\n */\nexport function never() {\n  return NEVER;\n}\n", "const { isArray } = Array;\n\n/**\n * Used in operators and functions that accept either a list of arguments, or an array of arguments\n * as a single argument.\n */\nexport function argsOrArgArray<T>(args: (T | T[])[]): T[] {\n  return args.length === 1 && isArray(args[0]) ? args[0] : (args as T[]);\n}\n", "import { OperatorFunction, MonoTypeOperatorFunction, TruthyTypesOf } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/** @deprecated Use a closure instead of a `thisArg`. Signatures accepting a `thisArg` will be removed in v8. */\nexport function filter<T, S extends T, A>(predicate: (this: A, value: T, index: number) => value is S, thisArg: A): OperatorFunction<T, S>;\nexport function filter<T, S extends T>(predicate: (value: T, index: number) => value is S): OperatorFunction<T, S>;\nexport function filter<T>(predicate: BooleanConstructor): OperatorFunction<T, TruthyTypesOf<T>>;\n/** @deprecated Use a closure instead of a `thisArg`. Signatures accepting a `thisArg` will be removed in v8. */\nexport function filter<T, A>(predicate: (this: A, value: T, index: number) => boolean, thisArg: A): MonoTypeOperatorFunction<T>;\nexport function filter<T>(predicate: (value: T, index: number) => boolean): MonoTypeOperatorFunction<T>;\n\n/**\n * Filter items emitted by the source Observable by only emitting those that\n * satisfy a specified predicate.\n *\n * <span class=\"informal\">Like\n * [Array.prototype.filter()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/filter),\n * it only emits a value from the source if it passes a criterion function.</span>\n *\n * ![](filter.png)\n *\n * Similar to the well-known `Array.prototype.filter` method, this operator\n * takes values from the source Observable, passes them through a `predicate`\n * function and only emits those values that yielded `true`.\n *\n * ## Example\n *\n * Emit only click events whose target was a DIV element\n *\n * ```ts\n * import { fromEvent, filter } from 'rxjs';\n *\n * const div = document.createElement('div');\n * div.style.cssText = 'width: 200px; height: 200px; background: #09c;';\n * document.body.appendChild(div);\n *\n * const clicks = fromEvent(document, 'click');\n * const clicksOnDivs = clicks.pipe(filter(ev => (<HTMLElement>ev.target).tagName === 'DIV'));\n * clicksOnDivs.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link distinct}\n * @see {@link distinctUntilChanged}\n * @see {@link distinctUntilKeyChanged}\n * @see {@link ignoreElements}\n * @see {@link partition}\n * @see {@link skip}\n *\n * @param predicate A function that\n * evaluates each value emitted by the source Observable. If it returns `true`,\n * the value is emitted, if `false` the value is not passed to the output\n * Observable. The `index` parameter is the number `i` for the i-th source\n * emission that has happened since the subscription, starting from the number\n * `0`.\n * @param thisArg An optional argument to determine the value of `this`\n * in the `predicate` function.\n * @return A function that returns an Observable that emits items from the\n * source Observable that satisfy the specified `predicate`.\n */\nexport function filter<T>(predicate: (value: T, index: number) => boolean, thisArg?: any): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    // An index passed to our predicate function on each call.\n    let index = 0;\n\n    // Subscribe to the source, all errors and completions are\n    // forwarded to the consumer.\n    source.subscribe(\n      // Call the predicate with the appropriate `this` context,\n      // if the predicate returns `true`, then send the value\n      // to the consumer.\n      createOperatorSubscriber(subscriber, (value) => predicate.call(thisArg, value, index++) && subscriber.next(value))\n    );\n  });\n}\n", "import { Observable } from '../Observable';\nimport { ObservableInputTuple } from '../types';\nimport { innerFrom } from './innerFrom';\nimport { argsOrArgArray } from '../util/argsOrArgArray';\nimport { EMPTY } from './empty';\nimport { createOperatorSubscriber } from '../operators/OperatorSubscriber';\nimport { popResultSelector } from '../util/args';\n\nexport function zip<A extends readonly unknown[]>(sources: [...ObservableInputTuple<A>]): Observable<A>;\nexport function zip<A extends readonly unknown[], R>(\n  sources: [...ObservableInputTuple<A>],\n  resultSelector: (...values: A) => R\n): Observable<R>;\nexport function zip<A extends readonly unknown[]>(...sources: [...ObservableInputTuple<A>]): Observable<A>;\nexport function zip<A extends readonly unknown[], R>(\n  ...sourcesAndResultSelector: [...ObservableInputTuple<A>, (...values: A) => R]\n): Observable<R>;\n\n/**\n * Combines multiple Observables to create an Observable whose values are calculated from the values, in order, of each\n * of its input Observables.\n *\n * If the last parameter is a function, this function is used to compute the created value from the input values.\n * Otherwise, an array of the input values is returned.\n *\n * ## Example\n *\n * Combine age and name from different sources\n *\n * ```ts\n * import { of, zip, map } from 'rxjs';\n *\n * const age$ = of(27, 25, 29);\n * const name$ = of('Foo', 'Bar', 'Beer');\n * const isDev$ = of(true, true, false);\n *\n * zip(age$, name$, isDev$).pipe(\n *   map(([age, name, isDev]) => ({ age, name, isDev }))\n * )\n * .subscribe(x => console.log(x));\n *\n * // Outputs\n * // { age: 27, name: 'Foo', isDev: true }\n * // { age: 25, name: 'Bar', isDev: true }\n * // { age: 29, name: 'Beer', isDev: false }\n * ```\n *\n * @param sources\n * @return {Observable<R>}\n */\nexport function zip(...args: unknown[]): Observable<unknown> {\n  const resultSelector = popResultSelector(args);\n\n  const sources = argsOrArgArray(args) as Observable<unknown>[];\n\n  return sources.length\n    ? new Observable<unknown[]>((subscriber) => {\n        // A collection of buffers of values from each source.\n        // Keyed by the same index with which the sources were passed in.\n        let buffers: unknown[][] = sources.map(() => []);\n\n        // An array of flags of whether or not the sources have completed.\n        // This is used to check to see if we should complete the result.\n        // Keyed by the same index with which the sources were passed in.\n        let completed = sources.map(() => false);\n\n        // When everything is done, release the arrays above.\n        subscriber.add(() => {\n          buffers = completed = null!;\n        });\n\n        // Loop over our sources and subscribe to each one. The index `i` is\n        // especially important here, because we use it in closures below to\n        // access the related buffers and completion properties\n        for (let sourceIndex = 0; !subscriber.closed && sourceIndex < sources.length; sourceIndex++) {\n          innerFrom(sources[sourceIndex]).subscribe(\n            createOperatorSubscriber(\n              subscriber,\n              (value) => {\n                buffers[sourceIndex].push(value);\n                // if every buffer has at least one value in it, then we\n                // can shift out the oldest value from each buffer and emit\n                // them as an array.\n                if (buffers.every((buffer) => buffer.length)) {\n                  const result: any = buffers.map((buffer) => buffer.shift()!);\n                  // Emit the array. If theres' a result selector, use that.\n                  subscriber.next(resultSelector ? resultSelector(...result) : result);\n                  // If any one of the sources is both complete and has an empty buffer\n                  // then we complete the result. This is because we cannot possibly have\n                  // any more values to zip together.\n                  if (buffers.some((buffer, i) => !buffer.length && completed[i])) {\n                    subscriber.complete();\n                  }\n                }\n              },\n              () => {\n                // This source completed. Mark it as complete so we can check it later\n                // if we have to.\n                completed[sourceIndex] = true;\n                // But, if this complete source has nothing in its buffer, then we\n                // can complete the result, because we can't possibly have any more\n                // values from this to zip together with the other values.\n                !buffers[sourceIndex].length && subscriber.complete();\n              }\n            )\n          );\n        }\n\n        // When everything is done, release the arrays above.\n        return () => {\n          buffers = completed = null!;\n        };\n      })\n    : EMPTY;\n}\n", "import { Subscriber } from '../Subscriber';\nimport { MonoTypeOperatorFunction, ObservableInput } from '../types';\n\nimport { operate } from '../util/lift';\nimport { innerFrom } from '../observable/innerFrom';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * Ignores source values for a duration determined by another Observable, then\n * emits the most recent value from the source Observable, then repeats this\n * process.\n *\n * <span class=\"informal\">It's like {@link auditTime}, but the silencing\n * duration is determined by a second Observable.</span>\n *\n * ![](audit.svg)\n *\n * `audit` is similar to `throttle`, but emits the last value from the silenced\n * time window, instead of the first value. `audit` emits the most recent value\n * from the source Observable on the output Observable as soon as its internal\n * timer becomes disabled, and ignores source values while the timer is enabled.\n * Initially, the timer is disabled. As soon as the first source value arrives,\n * the timer is enabled by calling the `durationSelector` function with the\n * source value, which returns the \"duration\" Observable. When the duration\n * Observable emits a value, the timer is disabled, then the most\n * recent source value is emitted on the output Observable, and this process\n * repeats for the next source value.\n *\n * ## Example\n *\n * Emit clicks at a rate of at most one click per second\n *\n * ```ts\n * import { fromEvent, audit, interval } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(audit(ev => interval(1000)));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link auditTime}\n * @see {@link debounce}\n * @see {@link delayWhen}\n * @see {@link sample}\n * @see {@link throttle}\n *\n * @param durationSelector A function\n * that receives a value from the source Observable, for computing the silencing\n * duration, returned as an Observable or a Promise.\n * @return A function that returns an Observable that performs rate-limiting of\n * emissions from the source Observable.\n */\nexport function audit<T>(durationSelector: (value: T) => ObservableInput<any>): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    let hasValue = false;\n    let lastValue: T | null = null;\n    let durationSubscriber: Subscriber<any> | null = null;\n    let isComplete = false;\n\n    const endDuration = () => {\n      durationSubscriber?.unsubscribe();\n      durationSubscriber = null;\n      if (hasValue) {\n        hasValue = false;\n        const value = lastValue!;\n        lastValue = null;\n        subscriber.next(value);\n      }\n      isComplete && subscriber.complete();\n    };\n\n    const cleanupDuration = () => {\n      durationSubscriber = null;\n      isComplete && subscriber.complete();\n    };\n\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value) => {\n          hasValue = true;\n          lastValue = value;\n          if (!durationSubscriber) {\n            innerFrom(durationSelector(value)).subscribe(\n              (durationSubscriber = createOperatorSubscriber(subscriber, endDuration, cleanupDuration))\n            );\n          }\n        },\n        () => {\n          isComplete = true;\n          (!hasValue || !durationSubscriber || durationSubscriber.closed) && subscriber.complete();\n        }\n      )\n    );\n  });\n}\n", "import { asyncScheduler } from '../scheduler/async';\nimport { audit } from './audit';\nimport { timer } from '../observable/timer';\nimport { MonoTypeOperatorFunction, SchedulerLike } from '../types';\n\n/**\n * Ignores source values for `duration` milliseconds, then emits the most recent\n * value from the source Observable, then repeats this process.\n *\n * <span class=\"informal\">When it sees a source value, it ignores that plus\n * the next ones for `duration` milliseconds, and then it emits the most recent\n * value from the source.</span>\n *\n * ![](auditTime.png)\n *\n * `auditTime` is similar to `throttleTime`, but emits the last value from the\n * silenced time window, instead of the first value. `auditTime` emits the most\n * recent value from the source Observable on the output Observable as soon as\n * its internal timer becomes disabled, and ignores source values while the\n * timer is enabled. Initially, the timer is disabled. As soon as the first\n * source value arrives, the timer is enabled. After `duration` milliseconds (or\n * the time unit determined internally by the optional `scheduler`) has passed,\n * the timer is disabled, then the most recent source value is emitted on the\n * output Observable, and this process repeats for the next source value.\n * Optionally takes a {@link SchedulerLike} for managing timers.\n *\n * ## Example\n *\n * Emit clicks at a rate of at most one click per second\n *\n * ```ts\n * import { fromEvent, auditTime } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(auditTime(1000));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link audit}\n * @see {@link debounceTime}\n * @see {@link delay}\n * @see {@link sampleTime}\n * @see {@link throttleTime}\n *\n * @param {number} duration Time to wait before emitting the most recent source\n * value, measured in milliseconds or the time unit determined internally\n * by the optional `scheduler`.\n * @param {SchedulerLike} [scheduler=async] The {@link SchedulerLike} to use for\n * managing the timers that handle the rate-limiting behavior.\n * @return A function that returns an Observable that performs rate-limiting of\n * emissions from the source Observable.\n */\nexport function auditTime<T>(duration: number, scheduler: SchedulerLike = asyncScheduler): MonoTypeOperatorFunction<T> {\n  return audit(() => timer(duration, scheduler));\n}\n", "import { OperatorFunction } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { arrRemove } from '../util/arrRemove';\n\n/**\n * Buffers the source Observable values until the size hits the maximum\n * `bufferSize` given.\n *\n * <span class=\"informal\">Collects values from the past as an array, and emits\n * that array only when its size reaches `bufferSize`.</span>\n *\n * ![](bufferCount.png)\n *\n * Buffers a number of values from the source Observable by `bufferSize` then\n * emits the buffer and clears it, and starts a new buffer each\n * `startBufferEvery` values. If `startBufferEvery` is not provided or is\n * `null`, then new buffers are started immediately at the start of the source\n * and when each buffer closes and is emitted.\n *\n * ## Examples\n *\n * Emit the last two click events as an array\n *\n * ```ts\n * import { fromEvent, bufferCount } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const buffered = clicks.pipe(bufferCount(2));\n * buffered.subscribe(x => console.log(x));\n * ```\n *\n * On every click, emit the last two click events as an array\n *\n * ```ts\n * import { fromEvent, bufferCount } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const buffered = clicks.pipe(bufferCount(2, 1));\n * buffered.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link buffer}\n * @see {@link bufferTime}\n * @see {@link bufferToggle}\n * @see {@link bufferWhen}\n * @see {@link pairwise}\n * @see {@link windowCount}\n *\n * @param {number} bufferSize The maximum size of the buffer emitted.\n * @param {number} [startBufferEvery] Interval at which to start a new buffer.\n * For example if `startBufferEvery` is `2`, then a new buffer will be started\n * on every other value from the source. A new buffer is started at the\n * beginning of the source by default.\n * @return A function that returns an Observable of arrays of buffered values.\n */\nexport function bufferCount<T>(bufferSize: number, startBufferEvery: number | null = null): OperatorFunction<T, T[]> {\n  // If no `startBufferEvery` value was supplied, then we're\n  // opening and closing on the bufferSize itself.\n  startBufferEvery = startBufferEvery ?? bufferSize;\n\n  return operate((source, subscriber) => {\n    let buffers: T[][] = [];\n    let count = 0;\n\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value) => {\n          let toEmit: T[][] | null = null;\n\n          // Check to see if we need to start a buffer.\n          // This will start one at the first value, and then\n          // a new one every N after that.\n          if (count++ % startBufferEvery! === 0) {\n            buffers.push([]);\n          }\n\n          // Push our value into our active buffers.\n          for (const buffer of buffers) {\n            buffer.push(value);\n            // Check to see if we're over the bufferSize\n            // if we are, record it so we can emit it later.\n            // If we emitted it now and removed it, it would\n            // mutate the `buffers` array while we're looping\n            // over it.\n            if (bufferSize <= buffer.length) {\n              toEmit = toEmit ?? [];\n              toEmit.push(buffer);\n            }\n          }\n\n          if (toEmit) {\n            // We have found some buffers that are over the\n            // `bufferSize`. Emit them, and remove them from our\n            // buffers list.\n            for (const buffer of toEmit) {\n              arrRemove(buffers, buffer);\n              subscriber.next(buffer);\n            }\n          }\n        },\n        () => {\n          // When the source completes, emit all of our\n          // active buffers.\n          for (const buffer of buffers) {\n            subscriber.next(buffer);\n          }\n          subscriber.complete();\n        },\n        // Pass all errors through to consumer.\n        undefined,\n        () => {\n          // Clean up our memory when we finalize\n          buffers = null!;\n        }\n      )\n    );\n  });\n}\n", "import { Observable } from '../Observable';\n\nimport { ObservableInput, OperatorFunction, ObservedValueOf } from '../types';\nimport { Subscription } from '../Subscription';\nimport { innerFrom } from '../observable/innerFrom';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { operate } from '../util/lift';\n\n/* tslint:disable:max-line-length */\nexport function catchError<T, O extends ObservableInput<any>>(\n  selector: (err: any, caught: Observable<T>) => O\n): OperatorFunction<T, T | ObservedValueOf<O>>;\n/* tslint:enable:max-line-length */\n\n/**\n * Catches errors on the observable to be handled by returning a new observable or throwing an error.\n *\n * <span class=\"informal\">\n * It only listens to the error channel and ignores notifications.\n * Handles errors from the source observable, and maps them to a new observable.\n * The error may also be rethrown, or a new error can be thrown to emit an error from the result.\n * </span>\n *\n * ![](catch.png)\n *\n * This operator handles errors, but forwards along all other events to the resulting observable.\n * If the source observable terminates with an error, it will map that error to a new observable,\n * subscribe to it, and forward all of its events to the resulting observable.\n *\n * ## Examples\n *\n * Continue with a different Observable when there's an error\n *\n * ```ts\n * import { of, map, catchError } from 'rxjs';\n *\n * of(1, 2, 3, 4, 5)\n *   .pipe(\n *     map(n => {\n *       if (n === 4) {\n *         throw 'four!';\n *       }\n *       return n;\n *     }),\n *     catchError(err => of('I', 'II', 'III', 'IV', 'V'))\n *   )\n *   .subscribe(x => console.log(x));\n *   // 1, 2, 3, I, II, III, IV, V\n * ```\n *\n * Retry the caught source Observable again in case of error, similar to `retry()` operator\n *\n * ```ts\n * import { of, map, catchError, take } from 'rxjs';\n *\n * of(1, 2, 3, 4, 5)\n *   .pipe(\n *     map(n => {\n *       if (n === 4) {\n *         throw 'four!';\n *       }\n *       return n;\n *     }),\n *     catchError((err, caught) => caught),\n *     take(30)\n *   )\n *   .subscribe(x => console.log(x));\n *   // 1, 2, 3, 1, 2, 3, ...\n * ```\n *\n * Throw a new error when the source Observable throws an error\n *\n * ```ts\n * import { of, map, catchError } from 'rxjs';\n *\n * of(1, 2, 3, 4, 5)\n *   .pipe(\n *     map(n => {\n *       if (n === 4) {\n *         throw 'four!';\n *       }\n *       return n;\n *     }),\n *     catchError(err => {\n *       throw 'error in source. Details: ' + err;\n *     })\n *   )\n *   .subscribe({\n *     next: x => console.log(x),\n *     error: err => console.log(err)\n *   });\n *   // 1, 2, 3, error in source. Details: four!\n * ```\n *\n * @see {@link onErrorResumeNext}\n * @see {@link repeat}\n * @see {@link repeatWhen}\n * @see {@link retry }\n * @see {@link retryWhen}\n *\n * @param {function} selector a function that takes as arguments `err`, which is the error, and `caught`, which\n * is the source observable, in case you'd like to \"retry\" that observable by returning it again. Whatever observable\n * is returned by the `selector` will be used to continue the observable chain.\n * @return A function that returns an Observable that originates from either\n * the source or the Observable returned by the `selector` function.\n */\nexport function catchError<T, O extends ObservableInput<any>>(\n  selector: (err: any, caught: Observable<T>) => O\n): OperatorFunction<T, T | ObservedValueOf<O>> {\n  return operate((source, subscriber) => {\n    let innerSub: Subscription | null = null;\n    let syncUnsub = false;\n    let handledResult: Observable<ObservedValueOf<O>>;\n\n    innerSub = source.subscribe(\n      createOperatorSubscriber(subscriber, undefined, undefined, (err) => {\n        handledResult = innerFrom(selector(err, catchError(selector)(source)));\n        if (innerSub) {\n          innerSub.unsubscribe();\n          innerSub = null;\n          handledResult.subscribe(subscriber);\n        } else {\n          // We don't have an innerSub yet, that means the error was synchronous\n          // because the subscribe call hasn't returned yet.\n          syncUnsub = true;\n        }\n      })\n    );\n\n    if (syncUnsub) {\n      // We have a synchronous error, we need to make sure to\n      // finalize right away. This ensures that callbacks in the `finalize` operator are called\n      // at the right time, and that finalization occurs at the expected\n      // time between the source error and the subscription to the\n      // next observable.\n      innerSub.unsubscribe();\n      innerSub = null;\n      handledResult!.subscribe(subscriber);\n    }\n  });\n}\n", "import { Observable } from '../Observable';\nimport { Subscriber } from '../Subscriber';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * A basic scan operation. This is used for `scan` and `reduce`.\n * @param accumulator The accumulator to use\n * @param seed The seed value for the state to accumulate\n * @param hasSeed Whether or not a seed was provided\n * @param emitOnNext Whether or not to emit the state on next\n * @param emitBeforeComplete Whether or not to emit the before completion\n */\n\nexport function scanInternals<V, A, S>(\n  accumulator: (acc: V | A | S, value: V, index: number) => A,\n  seed: S,\n  hasSeed: boolean,\n  emitOnNext: boolean,\n  emitBeforeComplete?: undefined | true\n) {\n  return (source: Observable<V>, subscriber: Subscriber<any>) => {\n    // Whether or not we have state yet. This will only be\n    // false before the first value arrives if we didn't get\n    // a seed value.\n    let hasState = hasSeed;\n    // The state that we're tracking, starting with the seed,\n    // if there is one, and then updated by the return value\n    // from the accumulator on each emission.\n    let state: any = seed;\n    // An index to pass to the accumulator function.\n    let index = 0;\n\n    // Subscribe to our source. All errors and completions are passed through.\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value) => {\n          // Always increment the index.\n          const i = index++;\n          // Set the state\n          state = hasState\n            ? // We already have state, so we can get the new state from the accumulator\n              accumulator(state, value, i)\n            : // We didn't have state yet, a seed value was not provided, so\n\n              // we set the state to the first value, and mark that we have state now\n              ((hasState = true), value);\n\n          // Maybe send it to the consumer.\n          emitOnNext && subscriber.next(state);\n        },\n        // If an onComplete was given, call it, otherwise\n        // just pass through the complete notification to the consumer.\n        emitBeforeComplete &&\n          (() => {\n            hasState && subscriber.next(state);\n            subscriber.complete();\n          })\n      )\n    );\n  };\n}\n", "import { combineLatestInit } from '../observable/combineLatest';\nimport { ObservableInput, ObservableInputTuple, OperatorFunction } from '../types';\nimport { operate } from '../util/lift';\nimport { argsOrArgArray } from '../util/argsOrArgArray';\nimport { mapOneOrManyArgs } from '../util/mapOneOrManyArgs';\nimport { pipe } from '../util/pipe';\nimport { popResultSelector } from '../util/args';\n\n/** @deprecated Replaced with {@link combineLatestWith}. Will be removed in v8. */\nexport function combineLatest<T, A extends readonly unknown[], R>(\n  sources: [...ObservableInputTuple<A>],\n  project: (...values: [T, ...A]) => R\n): OperatorFunction<T, R>;\n/** @deprecated Replaced with {@link combineLatestWith}. Will be removed in v8. */\nexport function combineLatest<T, A extends readonly unknown[], R>(sources: [...ObservableInputTuple<A>]): OperatorFunction<T, [T, ...A]>;\n\n/** @deprecated Replaced with {@link combineLatestWith}. Will be removed in v8. */\nexport function combineLatest<T, A extends readonly unknown[], R>(\n  ...sourcesAndProject: [...ObservableInputTuple<A>, (...values: [T, ...A]) => R]\n): OperatorFunction<T, R>;\n/** @deprecated Replaced with {@link combineLatestWith}. Will be removed in v8. */\nexport function combineLatest<T, A extends readonly unknown[], R>(...sources: [...ObservableInputTuple<A>]): OperatorFunction<T, [T, ...A]>;\n\n/**\n * @deprecated Replaced with {@link combineLatestWith}. Will be removed in v8.\n */\nexport function combineLatest<T, R>(...args: (ObservableInput<any> | ((...values: any[]) => R))[]): OperatorFunction<T, unknown> {\n  const resultSelector = popResultSelector(args);\n  return resultSelector\n    ? pipe(combineLatest(...(args as Array<ObservableInput<any>>)), mapOneOrManyArgs(resultSelector))\n    : operate((source, subscriber) => {\n        combineLatestInit([source, ...argsOrArgArray(args)])(subscriber);\n      });\n}\n", "import { ObservableInputTuple, OperatorFunction, Cons } from '../types';\nimport { combineLatest } from './combineLatest';\n\n/**\n * Create an observable that combines the latest values from all passed observables and the source\n * into arrays and emits them.\n *\n * Returns an observable, that when subscribed to, will subscribe to the source observable and all\n * sources provided as arguments. Once all sources emit at least one value, all of the latest values\n * will be emitted as an array. After that, every time any source emits a value, all of the latest values\n * will be emitted as an array.\n *\n * This is a useful operator for eagerly calculating values based off of changed inputs.\n *\n * ## Example\n *\n * Simple concatenation of values from two inputs\n *\n * ```ts\n * import { fromEvent, combineLatestWith, map } from 'rxjs';\n *\n * // Setup: Add two inputs to the page\n * const input1 = document.createElement('input');\n * document.body.appendChild(input1);\n * const input2 = document.createElement('input');\n * document.body.appendChild(input2);\n *\n * // Get streams of changes\n * const input1Changes$ = fromEvent(input1, 'change');\n * const input2Changes$ = fromEvent(input2, 'change');\n *\n * // Combine the changes by adding them together\n * input1Changes$.pipe(\n *   combineLatestWith(input2Changes$),\n *   map(([e1, e2]) => (<HTMLInputElement>e1.target).value + ' - ' + (<HTMLInputElement>e2.target).value)\n * )\n * .subscribe(x => console.log(x));\n * ```\n *\n * @param otherSources the other sources to subscribe to.\n * @return A function that returns an Observable that emits the latest\n * emissions from both source and provided Observables.\n */\nexport function combineLatestWith<T, A extends readonly unknown[]>(\n  ...otherSources: [...ObservableInputTuple<A>]\n): OperatorFunction<T, Cons<T, A>> {\n  return combineLatest(...otherSources);\n}\n", "import { Subscriber } from '../Subscriber';\nimport { MonoTypeOperatorFunction, ObservableInput } from '../types';\nimport { operate } from '../util/lift';\nimport { noop } from '../util/noop';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { innerFrom } from '../observable/innerFrom';\n\n/**\n * Emits a notification from the source Observable only after a particular time span\n * determined by another Observable has passed without another source emission.\n *\n * <span class=\"informal\">It's like {@link debounceTime}, but the time span of\n * emission silence is determined by a second Observable.</span>\n *\n * ![](debounce.svg)\n *\n * `debounce` delays notifications emitted by the source Observable, but drops previous\n * pending delayed emissions if a new notification arrives on the source Observable.\n * This operator keeps track of the most recent notification from the source\n * Observable, and spawns a duration Observable by calling the\n * `durationSelector` function. The notification is emitted only when the duration\n * Observable emits a next notification, and if no other notification was emitted on\n * the source Observable since the duration Observable was spawned. If a new\n * notification appears before the duration Observable emits, the previous notification will\n * not be emitted and a new duration is scheduled from `durationSelector` is scheduled.\n * If the completing event happens during the scheduled duration the last cached notification\n * is emitted before the completion event is forwarded to the output observable.\n * If the error event happens during the scheduled duration or after it only the error event is\n * forwarded to the output observable. The cache notification is not emitted in this case.\n *\n * Like {@link debounceTime}, this is a rate-limiting operator, and also a\n * delay-like operator since output emissions do not necessarily occur at the\n * same time as they did on the source Observable.\n *\n * ## Example\n *\n * Emit the most recent click after a burst of clicks\n *\n * ```ts\n * import { fromEvent, scan, debounce, interval } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(\n *   scan(i => ++i, 1),\n *   debounce(i => interval(200 * i))\n * );\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link audit}\n * @see {@link auditTime}\n * @see {@link debounceTime}\n * @see {@link delay}\n * @see {@link sample}\n * @see {@link sampleTime}\n * @see {@link throttle}\n * @see {@link throttleTime}\n *\n * @param durationSelector A function\n * that receives a value from the source Observable, for computing the timeout\n * duration for each source value, returned as an Observable or a Promise.\n * @return A function that returns an Observable that delays the emissions of\n * the source Observable by the specified duration Observable returned by\n * `durationSelector`, and may drop some values if they occur too frequently.\n */\nexport function debounce<T>(durationSelector: (value: T) => ObservableInput<any>): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    let hasValue = false;\n    let lastValue: T | null = null;\n    // The subscriber/subscription for the current debounce, if there is one.\n    let durationSubscriber: Subscriber<any> | null = null;\n\n    const emit = () => {\n      // Unsubscribe any current debounce subscription we have,\n      // we only cared about the first notification from it, and we\n      // want to clean that subscription up as soon as possible.\n      durationSubscriber?.unsubscribe();\n      durationSubscriber = null;\n      if (hasValue) {\n        // We have a value! Free up memory first, then emit the value.\n        hasValue = false;\n        const value = lastValue!;\n        lastValue = null;\n        subscriber.next(value);\n      }\n    };\n\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value: T) => {\n          // Cancel any pending debounce duration. We don't\n          // need to null it out here yet tho, because we're just going\n          // to create another one in a few lines.\n          durationSubscriber?.unsubscribe();\n          hasValue = true;\n          lastValue = value;\n          // Capture our duration subscriber, so we can unsubscribe it when we're notified\n          // and we're going to emit the value.\n          durationSubscriber = createOperatorSubscriber(subscriber, emit, noop);\n          // Subscribe to the duration.\n          innerFrom(durationSelector(value)).subscribe(durationSubscriber);\n        },\n        () => {\n          // Source completed.\n          // Emit any pending debounced values then complete\n          emit();\n          subscriber.complete();\n        },\n        // Pass all errors through to consumer\n        undefined,\n        () => {\n          // Finalization.\n          lastValue = durationSubscriber = null;\n        }\n      )\n    );\n  });\n}\n", "import { asyncScheduler } from '../scheduler/async';\nimport { Subscription } from '../Subscription';\nimport { MonoTypeOperatorFunction, SchedulerAction, SchedulerLike } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * Emits a notification from the source Observable only after a particular time span\n * has passed without another source emission.\n *\n * <span class=\"informal\">It's like {@link delay}, but passes only the most\n * recent notification from each burst of emissions.</span>\n *\n * ![](debounceTime.png)\n *\n * `debounceTime` delays notifications emitted by the source Observable, but drops\n * previous pending delayed emissions if a new notification arrives on the source\n * Observable. This operator keeps track of the most recent notification from the\n * source Observable, and emits that only when `dueTime` has passed\n * without any other notification appearing on the source Observable. If a new value\n * appears before `dueTime` silence occurs, the previous notification will be dropped\n * and will not be emitted and a new `dueTime` is scheduled.\n * If the completing event happens during `dueTime` the last cached notification\n * is emitted before the completion event is forwarded to the output observable.\n * If the error event happens during `dueTime` or after it only the error event is\n * forwarded to the output observable. The cache notification is not emitted in this case.\n *\n * This is a rate-limiting operator, because it is impossible for more than one\n * notification to be emitted in any time window of duration `dueTime`, but it is also\n * a delay-like operator since output emissions do not occur at the same time as\n * they did on the source Observable. Optionally takes a {@link SchedulerLike} for\n * managing timers.\n *\n * ## Example\n *\n * Emit the most recent click after a burst of clicks\n *\n * ```ts\n * import { fromEvent, debounceTime } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(debounceTime(1000));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link audit}\n * @see {@link auditTime}\n * @see {@link debounce}\n * @see {@link sample}\n * @see {@link sampleTime}\n * @see {@link throttle}\n * @see {@link throttleTime}\n *\n * @param {number} dueTime The timeout duration in milliseconds (or the time\n * unit determined internally by the optional `scheduler`) for the window of\n * time required to wait for emission silence before emitting the most recent\n * source value.\n * @param {SchedulerLike} [scheduler=async] The {@link SchedulerLike} to use for\n * managing the timers that handle the timeout for each value.\n * @return A function that returns an Observable that delays the emissions of\n * the source Observable by the specified `dueTime`, and may drop some values\n * if they occur too frequently.\n */\nexport function debounceTime<T>(dueTime: number, scheduler: SchedulerLike = asyncScheduler): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    let activeTask: Subscription | null = null;\n    let lastValue: T | null = null;\n    let lastTime: number | null = null;\n\n    const emit = () => {\n      if (activeTask) {\n        // We have a value! Free up memory first, then emit the value.\n        activeTask.unsubscribe();\n        activeTask = null;\n        const value = lastValue!;\n        lastValue = null;\n        subscriber.next(value);\n      }\n    };\n    function emitWhenIdle(this: SchedulerAction<unknown>) {\n      // This is called `dueTime` after the first value\n      // but we might have received new values during this window!\n\n      const targetTime = lastTime! + dueTime;\n      const now = scheduler.now();\n      if (now < targetTime) {\n        // On that case, re-schedule to the new target\n        activeTask = this.schedule(undefined, targetTime - now);\n        subscriber.add(activeTask);\n        return;\n      }\n\n      emit();\n    }\n\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value: T) => {\n          lastValue = value;\n          lastTime = scheduler.now();\n\n          // Only set up a task if it's not already up\n          if (!activeTask) {\n            activeTask = scheduler.schedule(emitWhenIdle, dueTime);\n            subscriber.add(activeTask);\n          }\n        },\n        () => {\n          // Source completed.\n          // Emit any pending debounced values then complete\n          emit();\n          subscriber.complete();\n        },\n        // Pass all errors through to consumer.\n        undefined,\n        () => {\n          // Finalization.\n          lastValue = activeTask = null;\n        }\n      )\n    );\n  });\n}\n", "import { OperatorFunction } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * Emits a given value if the source Observable completes without emitting any\n * `next` value, otherwise mirrors the source Observable.\n *\n * <span class=\"informal\">If the source Observable turns out to be empty, then\n * this operator will emit a default value.</span>\n *\n * ![](defaultIfEmpty.png)\n *\n * `defaultIfEmpty` emits the values emitted by the source Observable or a\n * specified default value if the source Observable is empty (completes without\n * having emitted any `next` value).\n *\n * ## Example\n *\n * If no clicks happen in 5 seconds, then emit 'no clicks'\n *\n * ```ts\n * import { fromEvent, takeUntil, interval, defaultIfEmpty } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const clicksBeforeFive = clicks.pipe(takeUntil(interval(5000)));\n * const result = clicksBeforeFive.pipe(defaultIfEmpty('no clicks'));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link empty}\n * @see {@link last}\n *\n * @param defaultValue The default value used if the source\n * Observable is empty.\n * @return A function that returns an Observable that emits either the\n * specified `defaultValue` if the source Observable emits no items, or the\n * values emitted by the source Observable.\n */\nexport function defaultIfEmpty<T, R>(defaultValue: R): OperatorFunction<T, T | R> {\n  return operate((source, subscriber) => {\n    let hasValue = false;\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value) => {\n          hasValue = true;\n          subscriber.next(value);\n        },\n        () => {\n          if (!hasValue) {\n            subscriber.next(defaultValue!);\n          }\n          subscriber.complete();\n        }\n      )\n    );\n  });\n}\n", "import { MonoTypeOperatorFunction } from '../types';\nimport { EMPTY } from '../observable/empty';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * Emits only the first `count` values emitted by the source Observable.\n *\n * <span class=\"informal\">Takes the first `count` values from the source, then\n * completes.</span>\n *\n * ![](take.png)\n *\n * `take` returns an Observable that emits only the first `count` values emitted\n * by the source Observable. If the source emits fewer than `count` values then\n * all of its values are emitted. After that, it completes, regardless if the\n * source completes.\n *\n * ## Example\n *\n * Take the first 5 seconds of an infinite 1-second interval Observable\n *\n * ```ts\n * import { interval, take } from 'rxjs';\n *\n * const intervalCount = interval(1000);\n * const takeFive = intervalCount.pipe(take(5));\n * takeFive.subscribe(x => console.log(x));\n *\n * // Logs:\n * // 0\n * // 1\n * // 2\n * // 3\n * // 4\n * ```\n *\n * @see {@link takeLast}\n * @see {@link takeUntil}\n * @see {@link takeWhile}\n * @see {@link skip}\n *\n * @param count The maximum number of `next` values to emit.\n * @return A function that returns an Observable that emits only the first\n * `count` values emitted by the source Observable, or all of the values from\n * the source if the source emits fewer than `count` values.\n */\nexport function take<T>(count: number): MonoTypeOperatorFunction<T> {\n  return count <= 0\n    ? // If we are taking no values, that's empty.\n      () => EMPTY\n    : operate((source, subscriber) => {\n        let seen = 0;\n        source.subscribe(\n          createOperatorSubscriber(subscriber, (value) => {\n            // Increment the number of values we have seen,\n            // then check it against the allowed count to see\n            // if we are still letting values through.\n            if (++seen <= count) {\n              subscriber.next(value);\n              // If we have met or passed our allowed count,\n              // we need to complete. We have to do <= here,\n              // because re-entrant code will increment `seen` twice.\n              if (count <= seen) {\n                subscriber.complete();\n              }\n            }\n          })\n        );\n      });\n}\n", "import { OperatorFunction } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { noop } from '../util/noop';\n\n/**\n * Ignores all items emitted by the source Observable and only passes calls of `complete` or `error`.\n *\n * ![](ignoreElements.png)\n *\n * The `ignoreElements` operator suppresses all items emitted by the source Observable,\n * but allows its termination notification (either `error` or `complete`) to pass through unchanged.\n *\n * If you do not care about the items being emitted by an Observable, but you do want to be notified\n * when it completes or when it terminates with an error, you can apply the `ignoreElements` operator\n * to the Observable, which will ensure that it will never call its observers\u2019 `next` handlers.\n *\n * ## Example\n *\n * Ignore all `next` emissions from the source\n *\n * ```ts\n * import { of, ignoreElements } from 'rxjs';\n *\n * of('you', 'talking', 'to', 'me')\n *   .pipe(ignoreElements())\n *   .subscribe({\n *     next: word => console.log(word),\n *     error: err => console.log('error:', err),\n *     complete: () => console.log('the end'),\n *   });\n *\n * // result:\n * // 'the end'\n * ```\n *\n * @return A function that returns an empty Observable that only calls\n * `complete` or `error`, based on which one is called by the source\n * Observable.\n */\nexport function ignoreElements(): OperatorFunction<unknown, never> {\n  return operate((source, subscriber) => {\n    source.subscribe(createOperatorSubscriber(subscriber, noop));\n  });\n}\n", "import { OperatorFunction } from '../types';\nimport { map } from './map';\n\n/** @deprecated To be removed in v9. Use {@link map} instead: `map(() => value)`. */\nexport function mapTo<R>(value: R): OperatorFunction<unknown, R>;\n/**\n * @deprecated Do not specify explicit type parameters. Signatures with type parameters\n * that cannot be inferred will be removed in v8. `mapTo` itself will be removed in v9,\n * use {@link map} instead: `map(() => value)`.\n * */\nexport function mapTo<T, R>(value: R): OperatorFunction<T, R>;\n\n/**\n * Emits the given constant value on the output Observable every time the source\n * Observable emits a value.\n *\n * <span class=\"informal\">Like {@link map}, but it maps every source value to\n * the same output value every time.</span>\n *\n * ![](mapTo.png)\n *\n * Takes a constant `value` as argument, and emits that whenever the source\n * Observable emits a value. In other words, ignores the actual source value,\n * and simply uses the emission moment to know when to emit the given `value`.\n *\n * ## Example\n *\n * Map every click to the string `'Hi'`\n *\n * ```ts\n * import { fromEvent, mapTo } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const greetings = clicks.pipe(mapTo('Hi'));\n *\n * greetings.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link map}\n *\n * @param value The value to map each source value to.\n * @return A function that returns an Observable that emits the given `value`\n * every time the source Observable emits.\n * @deprecated To be removed in v9. Use {@link map} instead: `map(() => value)`.\n */\nexport function mapTo<R>(value: R): OperatorFunction<unknown, R> {\n  return map(() => value);\n}\n", "import { Observable } from '../Observable';\nimport { MonoTypeOperatorFunction, ObservableInput } from '../types';\nimport { concat } from '../observable/concat';\nimport { take } from './take';\nimport { ignoreElements } from './ignoreElements';\nimport { mapTo } from './mapTo';\nimport { mergeMap } from './mergeMap';\nimport { innerFrom } from '../observable/innerFrom';\n\n/** @deprecated The `subscriptionDelay` parameter will be removed in v8. */\nexport function delayWhen<T>(\n  delayDurationSelector: (value: T, index: number) => ObservableInput<any>,\n  subscriptionDelay: Observable<any>\n): MonoTypeOperatorFunction<T>;\nexport function delayWhen<T>(delayDurationSelector: (value: T, index: number) => ObservableInput<any>): MonoTypeOperatorFunction<T>;\n\n/**\n * Delays the emission of items from the source Observable by a given time span\n * determined by the emissions of another Observable.\n *\n * <span class=\"informal\">It's like {@link delay}, but the time span of the\n * delay duration is determined by a second Observable.</span>\n *\n * ![](delayWhen.png)\n *\n * `delayWhen` operator shifts each emitted value from the source Observable by\n * a time span determined by another Observable. When the source emits a value,\n * the `delayDurationSelector` function is called with the value emitted from\n * the source Observable as the first argument to the `delayDurationSelector`.\n * The `delayDurationSelector` function should return an {@link ObservableInput},\n * that is internally converted to an Observable that is called the \"duration\"\n * Observable.\n *\n * The source value is emitted on the output Observable only when the \"duration\"\n * Observable emits ({@link guide/glossary-and-semantics#next next}s) any value.\n * Upon that, the \"duration\" Observable gets unsubscribed.\n *\n * Before RxJS V7, the {@link guide/glossary-and-semantics#complete completion}\n * of the \"duration\" Observable would have been triggering the emission of the\n * source value to the output Observable, but with RxJS V7, this is not the case\n * anymore.\n *\n * Only next notifications (from the \"duration\" Observable) trigger values from\n * the source Observable to be passed to the output Observable. If the \"duration\"\n * Observable only emits the complete notification (without next), the value\n * emitted by the source Observable will never get to the output Observable - it\n * will be swallowed. If the \"duration\" Observable errors, the error will be\n * propagated to the output Observable.\n *\n * Optionally, `delayWhen` takes a second argument, `subscriptionDelay`, which\n * is an Observable. When `subscriptionDelay` emits its first value or\n * completes, the source Observable is subscribed to and starts behaving like\n * described in the previous paragraph. If `subscriptionDelay` is not provided,\n * `delayWhen` will subscribe to the source Observable as soon as the output\n * Observable is subscribed.\n *\n * ## Example\n *\n * Delay each click by a random amount of time, between 0 and 5 seconds\n *\n * ```ts\n * import { fromEvent, delayWhen, interval } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const delayedClicks = clicks.pipe(\n *   delayWhen(() => interval(Math.random() * 5000))\n * );\n * delayedClicks.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link delay}\n * @see {@link throttle}\n * @see {@link throttleTime}\n * @see {@link debounce}\n * @see {@link debounceTime}\n * @see {@link sample}\n * @see {@link sampleTime}\n * @see {@link audit}\n * @see {@link auditTime}\n *\n * @param delayDurationSelector A function that returns an `ObservableInput` for\n * each `value` emitted by the source Observable, which is then used to delay the\n * emission of that `value` on the output Observable until the `ObservableInput`\n * returned from this function emits a next value. When called, beside `value`,\n * this function receives a zero-based `index` of the emission order.\n * @param subscriptionDelay An Observable that triggers the subscription to the\n * source Observable once it emits any value.\n * @return A function that returns an Observable that delays the emissions of\n * the source Observable by an amount of time specified by the Observable\n * returned by `delayDurationSelector`.\n */\nexport function delayWhen<T>(\n  delayDurationSelector: (value: T, index: number) => ObservableInput<any>,\n  subscriptionDelay?: Observable<any>\n): MonoTypeOperatorFunction<T> {\n  if (subscriptionDelay) {\n    // DEPRECATED PATH\n    return (source: Observable<T>) =>\n      concat(subscriptionDelay.pipe(take(1), ignoreElements()), source.pipe(delayWhen(delayDurationSelector)));\n  }\n\n  return mergeMap((value, index) => innerFrom(delayDurationSelector(value, index)).pipe(take(1), mapTo(value)));\n}\n", "import { asyncScheduler } from '../scheduler/async';\nimport { MonoTypeOperatorFunction, SchedulerLike } from '../types';\nimport { delayWhen } from './delayWhen';\nimport { timer } from '../observable/timer';\n\n/**\n * Delays the emission of items from the source Observable by a given timeout or\n * until a given Date.\n *\n * <span class=\"informal\">Time shifts each item by some specified amount of\n * milliseconds.</span>\n *\n * ![](delay.svg)\n *\n * If the delay argument is a Number, this operator time shifts the source\n * Observable by that amount of time expressed in milliseconds. The relative\n * time intervals between the values are preserved.\n *\n * If the delay argument is a Date, this operator time shifts the start of the\n * Observable execution until the given date occurs.\n *\n * ## Examples\n *\n * Delay each click by one second\n *\n * ```ts\n * import { fromEvent, delay } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const delayedClicks = clicks.pipe(delay(1000)); // each click emitted after 1 second\n * delayedClicks.subscribe(x => console.log(x));\n * ```\n *\n * Delay all clicks until a future date happens\n *\n * ```ts\n * import { fromEvent, delay } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const date = new Date('March 15, 2050 12:00:00'); // in the future\n * const delayedClicks = clicks.pipe(delay(date)); // click emitted only after that date\n * delayedClicks.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link delayWhen}\n * @see {@link throttle}\n * @see {@link throttleTime}\n * @see {@link debounce}\n * @see {@link debounceTime}\n * @see {@link sample}\n * @see {@link sampleTime}\n * @see {@link audit}\n * @see {@link auditTime}\n *\n * @param {number|Date} due The delay duration in milliseconds (a `number`) or\n * a `Date` until which the emission of the source items is delayed.\n * @param {SchedulerLike} [scheduler=async] The {@link SchedulerLike} to use for\n * managing the timers that handle the time-shift for each item.\n * @return A function that returns an Observable that delays the emissions of\n * the source Observable by the specified timeout or Date.\n */\nexport function delay<T>(due: number | Date, scheduler: SchedulerLike = asyncScheduler): MonoTypeOperatorFunction<T> {\n  const duration = timer(due, scheduler);\n  return delayWhen(() => duration);\n}\n", "import { MonoTypeOperatorFunction } from '../types';\nimport { identity } from '../util/identity';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\nexport function distinctUntilChanged<T>(comparator?: (previous: T, current: T) => boolean): MonoTypeOperatorFunction<T>;\nexport function distinctUntilChanged<T, K>(\n  comparator: (previous: K, current: K) => boolean,\n  keySelector: (value: T) => K\n): MonoTypeOperatorFunction<T>;\n\n/**\n * Returns a result {@link Observable} that emits all values pushed by the source observable if they\n * are distinct in comparison to the last value the result observable emitted.\n *\n * When provided without parameters or with the first parameter (`{@link distinctUntilChanged#comparator comparator}`),\n * it behaves like this:\n *\n * 1. It will always emit the first value from the source.\n * 2. For all subsequent values pushed by the source, they will be compared to the previously emitted values\n *    using the provided `comparator` or an `===` equality check.\n * 3. If the value pushed by the source is determined to be unequal by this check, that value is emitted and\n *    becomes the new \"previously emitted value\" internally.\n *\n * When the second parameter (`{@link distinctUntilChanged#keySelector keySelector}`) is provided, the behavior\n * changes:\n *\n * 1. It will always emit the first value from the source.\n * 2. The `keySelector` will be run against all values, including the first value.\n * 3. For all values after the first, the selected key will be compared against the key selected from\n *    the previously emitted value using the `comparator`.\n * 4. If the keys are determined to be unequal by this check, the value (not the key), is emitted\n *    and the selected key from that value is saved for future comparisons against other keys.\n *\n * ## Examples\n *\n * A very basic example with no `{@link distinctUntilChanged#comparator comparator}`. Note that `1` is emitted more than once,\n * because it's distinct in comparison to the _previously emitted_ value,\n * not in comparison to _all other emitted values_.\n *\n * ```ts\n * import { of, distinctUntilChanged } from 'rxjs';\n *\n * of(1, 1, 1, 2, 2, 2, 1, 1, 3, 3)\n *   .pipe(distinctUntilChanged())\n *   .subscribe(console.log);\n * // Logs: 1, 2, 1, 3\n * ```\n *\n * With a `{@link distinctUntilChanged#comparator comparator}`, you can do custom comparisons. Let's say\n * you only want to emit a value when all of its components have\n * changed:\n *\n * ```ts\n * import { of, distinctUntilChanged } from 'rxjs';\n *\n * const totallyDifferentBuilds$ = of(\n *   { engineVersion: '1.1.0', transmissionVersion: '1.2.0' },\n *   { engineVersion: '1.1.0', transmissionVersion: '1.4.0' },\n *   { engineVersion: '1.3.0', transmissionVersion: '1.4.0' },\n *   { engineVersion: '1.3.0', transmissionVersion: '1.5.0' },\n *   { engineVersion: '2.0.0', transmissionVersion: '1.5.0' }\n * ).pipe(\n *   distinctUntilChanged((prev, curr) => {\n *     return (\n *       prev.engineVersion === curr.engineVersion ||\n *       prev.transmissionVersion === curr.transmissionVersion\n *     );\n *   })\n * );\n *\n * totallyDifferentBuilds$.subscribe(console.log);\n *\n * // Logs:\n * // { engineVersion: '1.1.0', transmissionVersion: '1.2.0' }\n * // { engineVersion: '1.3.0', transmissionVersion: '1.4.0' }\n * // { engineVersion: '2.0.0', transmissionVersion: '1.5.0' }\n * ```\n *\n * You can also provide a custom `{@link distinctUntilChanged#comparator comparator}` to check that emitted\n * changes are only in one direction. Let's say you only want to get\n * the next record temperature:\n *\n * ```ts\n * import { of, distinctUntilChanged } from 'rxjs';\n *\n * const temps$ = of(30, 31, 20, 34, 33, 29, 35, 20);\n *\n * const recordHighs$ = temps$.pipe(\n *   distinctUntilChanged((prevHigh, temp) => {\n *     // If the current temp is less than\n *     // or the same as the previous record,\n *     // the record hasn't changed.\n *     return temp <= prevHigh;\n *   })\n * );\n *\n * recordHighs$.subscribe(console.log);\n * // Logs: 30, 31, 34, 35\n * ```\n *\n * Selecting update events only when the `updatedBy` field shows\n * the account changed hands.\n *\n * ```ts\n * import { of, distinctUntilChanged } from 'rxjs';\n *\n * // A stream of updates to a given account\n * const accountUpdates$ = of(\n *   { updatedBy: 'blesh', data: [] },\n *   { updatedBy: 'blesh', data: [] },\n *   { updatedBy: 'ncjamieson', data: [] },\n *   { updatedBy: 'ncjamieson', data: [] },\n *   { updatedBy: 'blesh', data: [] }\n * );\n *\n * // We only want the events where it changed hands\n * const changedHands$ = accountUpdates$.pipe(\n *   distinctUntilChanged(undefined, update => update.updatedBy)\n * );\n *\n * changedHands$.subscribe(console.log);\n * // Logs:\n * // { updatedBy: 'blesh', data: Array[0] }\n * // { updatedBy: 'ncjamieson', data: Array[0] }\n * // { updatedBy: 'blesh', data: Array[0] }\n * ```\n *\n * @see {@link distinct}\n * @see {@link distinctUntilKeyChanged}\n *\n * @param comparator A function used to compare the previous and current keys for\n * equality. Defaults to a `===` check.\n * @param keySelector Used to select a key value to be passed to the `comparator`.\n *\n * @return A function that returns an Observable that emits items from the\n * source Observable with distinct values.\n */\nexport function distinctUntilChanged<T, K>(\n  comparator?: (previous: K, current: K) => boolean,\n  keySelector: (value: T) => K = identity as (value: T) => K\n): MonoTypeOperatorFunction<T> {\n  // We've been allowing `null` do be passed as the `compare`, so we can't do\n  // a default value for the parameter, because that will only work\n  // for `undefined`.\n  comparator = comparator ?? defaultCompare;\n\n  return operate((source, subscriber) => {\n    // The previous key, used to compare against keys selected\n    // from new arrivals to determine \"distinctiveness\".\n    let previousKey: K;\n    // Whether or not this is the first value we've gotten.\n    let first = true;\n\n    source.subscribe(\n      createOperatorSubscriber(subscriber, (value) => {\n        // We always call the key selector.\n        const currentKey = keySelector(value);\n\n        // If it's the first value, we always emit it.\n        // Otherwise, we compare this key to the previous key, and\n        // if the comparer returns false, we emit.\n        if (first || !comparator!(previousKey, currentKey)) {\n          // Update our state *before* we emit the value\n          // as emission can be the source of re-entrant code\n          // in functional libraries like this. We only really\n          // need to do this if it's the first value, or if the\n          // key we're tracking in previous needs to change.\n          first = false;\n          previousKey = currentKey;\n\n          // Emit the value!\n          subscriber.next(value);\n        }\n      })\n    );\n  });\n}\n\nfunction defaultCompare(a: any, b: any) {\n  return a === b;\n}\n", "import { distinctUntilChanged } from './distinctUntilChanged';\nimport { MonoTypeOperatorFunction } from '../types';\n\n/* tslint:disable:max-line-length */\nexport function distinctUntilKeyChanged<T>(key: keyof T): MonoTypeOperatorFunction<T>;\nexport function distinctUntilKeyChanged<T, K extends keyof T>(key: K, compare: (x: T[K], y: T[K]) => boolean): MonoTypeOperatorFunction<T>;\n/* tslint:enable:max-line-length */\n\n/**\n * Returns an Observable that emits all items emitted by the source Observable that are distinct by comparison from the previous item,\n * using a property accessed by using the key provided to check if the two items are distinct.\n *\n * If a comparator function is provided, then it will be called for each item to test for whether or not that value should be emitted.\n *\n * If a comparator function is not provided, an equality check is used by default.\n *\n * ## Examples\n *\n * An example comparing the name of persons\n *\n * ```ts\n * import { of, distinctUntilKeyChanged } from 'rxjs';\n *\n * of(\n *   { age: 4, name: 'Foo' },\n *   { age: 7, name: 'Bar' },\n *   { age: 5, name: 'Foo' },\n *   { age: 6, name: 'Foo' }\n * ).pipe(\n *   distinctUntilKeyChanged('name')\n * )\n * .subscribe(x => console.log(x));\n *\n * // displays:\n * // { age: 4, name: 'Foo' }\n * // { age: 7, name: 'Bar' }\n * // { age: 5, name: 'Foo' }\n * ```\n *\n * An example comparing the first letters of the name\n *\n * ```ts\n * import { of, distinctUntilKeyChanged } from 'rxjs';\n *\n * of(\n *   { age: 4, name: 'Foo1' },\n *   { age: 7, name: 'Bar' },\n *   { age: 5, name: 'Foo2' },\n *   { age: 6, name: 'Foo3' }\n * ).pipe(\n *   distinctUntilKeyChanged('name', (x, y) => x.substring(0, 3) === y.substring(0, 3))\n * )\n * .subscribe(x => console.log(x));\n *\n * // displays:\n * // { age: 4, name: 'Foo1' }\n * // { age: 7, name: 'Bar' }\n * // { age: 5, name: 'Foo2' }\n * ```\n *\n * @see {@link distinct}\n * @see {@link distinctUntilChanged}\n *\n * @param {string} key String key for object property lookup on each item.\n * @param {function} [compare] Optional comparison function called to test if an item is distinct from the previous item in the source.\n * @return A function that returns an Observable that emits items from the\n * source Observable with distinct values based on the key specified.\n */\nexport function distinctUntilKeyChanged<T, K extends keyof T>(key: K, compare?: (x: T[K], y: T[K]) => boolean): MonoTypeOperatorFunction<T> {\n  return distinctUntilChanged((x: T, y: T) => compare ? compare(x[key], y[key]) : x[key] === y[key]);\n}\n", "import { EmptyError } from '../util/EmptyError';\nimport { MonoTypeOperatorFunction } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * If the source observable completes without emitting a value, it will emit\n * an error. The error will be created at that time by the optional\n * `errorFactory` argument, otherwise, the error will be {@link EmptyError}.\n *\n * ![](throwIfEmpty.png)\n *\n * ## Example\n *\n * Throw an error if the document wasn't clicked within 1 second\n *\n * ```ts\n * import { fromEvent, takeUntil, timer, throwIfEmpty } from 'rxjs';\n *\n * const click$ = fromEvent(document, 'click');\n *\n * click$.pipe(\n *   takeUntil(timer(1000)),\n *   throwIfEmpty(() => new Error('The document was not clicked within 1 second'))\n * )\n * .subscribe({\n *   next() {\n *    console.log('The document was clicked');\n *   },\n *   error(err) {\n *     console.error(err.message);\n *   }\n * });\n * ```\n *\n * @param errorFactory A factory function called to produce the\n * error to be thrown when the source observable completes without emitting a\n * value.\n * @return A function that returns an Observable that throws an error if the\n * source Observable completed without emitting.\n */\nexport function throwIfEmpty<T>(errorFactory: () => any = defaultErrorFactory): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    let hasValue = false;\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value) => {\n          hasValue = true;\n          subscriber.next(value);\n        },\n        () => (hasValue ? subscriber.complete() : subscriber.error(errorFactory()))\n      )\n    );\n  });\n}\n\nfunction defaultErrorFactory() {\n  return new EmptyError();\n}\n", "/** prettier */\nimport { Observable } from '../Observable';\nimport { concat } from '../observable/concat';\nimport { of } from '../observable/of';\nimport { MonoTypeOperatorFunction, SchedulerLike, OperatorFunction, ValueFromArray } from '../types';\n\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `concatAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function endWith<T>(scheduler: SchedulerLike): MonoTypeOperatorFunction<T>;\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `concatAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function endWith<T, A extends unknown[] = T[]>(\n  ...valuesAndScheduler: [...A, SchedulerLike]\n): OperatorFunction<T, T | ValueFromArray<A>>;\n\nexport function endWith<T, A extends unknown[] = T[]>(...values: A): OperatorFunction<T, T | ValueFromArray<A>>;\n\n/**\n * Returns an observable that will emit all values from the source, then synchronously emit\n * the provided value(s) immediately after the source completes.\n *\n * NOTE: Passing a last argument of a Scheduler is _deprecated_, and may result in incorrect\n * types in TypeScript.\n *\n * This is useful for knowing when an observable ends. Particularly when paired with an\n * operator like {@link takeUntil}\n *\n * ![](endWith.png)\n *\n * ## Example\n *\n * Emit values to know when an interval starts and stops. The interval will\n * stop when a user clicks anywhere on the document.\n *\n * ```ts\n * import { interval, map, fromEvent, startWith, takeUntil, endWith } from 'rxjs';\n *\n * const ticker$ = interval(5000).pipe(\n *   map(() => 'tick')\n * );\n *\n * const documentClicks$ = fromEvent(document, 'click');\n *\n * ticker$.pipe(\n *   startWith('interval started'),\n *   takeUntil(documentClicks$),\n *   endWith('interval ended by click')\n * )\n * .subscribe(x => console.log(x));\n *\n * // Result (assuming a user clicks after 15 seconds)\n * // 'interval started'\n * // 'tick'\n * // 'tick'\n * // 'tick'\n * // 'interval ended by click'\n * ```\n *\n * @see {@link startWith}\n * @see {@link concat}\n * @see {@link takeUntil}\n *\n * @param values Items you want the modified Observable to emit last.\n * @return A function that returns an Observable that emits all values from the\n * source, then synchronously emits the provided value(s) immediately after the\n * source completes.\n */\nexport function endWith<T>(...values: Array<T | SchedulerLike>): MonoTypeOperatorFunction<T> {\n  return (source: Observable<T>) => concat(source, of(...values)) as Observable<T>;\n}\n", "import { MonoTypeOperatorFunction } from '../types';\nimport { operate } from '../util/lift';\n\n/**\n * Returns an Observable that mirrors the source Observable, but will call a specified function when\n * the source terminates on complete or error.\n * The specified function will also be called when the subscriber explicitly unsubscribes.\n *\n * ## Examples\n *\n * Execute callback function when the observable completes\n *\n * ```ts\n * import { interval, take, finalize } from 'rxjs';\n *\n * // emit value in sequence every 1 second\n * const source = interval(1000);\n * const example = source.pipe(\n *   take(5), //take only the first 5 values\n *   finalize(() => console.log('Sequence complete')) // Execute when the observable completes\n * );\n * const subscribe = example.subscribe(val => console.log(val));\n *\n * // results:\n * // 0\n * // 1\n * // 2\n * // 3\n * // 4\n * // 'Sequence complete'\n * ```\n *\n * Execute callback function when the subscriber explicitly unsubscribes\n *\n * ```ts\n * import { interval, finalize, tap, noop, timer } from 'rxjs';\n *\n * const source = interval(100).pipe(\n *   finalize(() => console.log('[finalize] Called')),\n *   tap({\n *     next: () => console.log('[next] Called'),\n *     error: () => console.log('[error] Not called'),\n *     complete: () => console.log('[tap complete] Not called')\n *   })\n * );\n *\n * const sub = source.subscribe({\n *   next: x => console.log(x),\n *   error: noop,\n *   complete: () => console.log('[complete] Not called')\n * });\n *\n * timer(150).subscribe(() => sub.unsubscribe());\n *\n * // results:\n * // '[next] Called'\n * // 0\n * // '[finalize] Called'\n * ```\n *\n * @param {function} callback Function to be called when source terminates.\n * @return A function that returns an Observable that mirrors the source, but\n * will call the specified function on termination.\n */\nexport function finalize<T>(callback: () => void): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    // TODO: This try/finally was only added for `useDeprecatedSynchronousErrorHandling`.\n    // REMOVE THIS WHEN THAT HOT GARBAGE IS REMOVED IN V8.\n    try {\n      source.subscribe(subscriber);\n    } finally {\n      subscriber.add(callback);\n    }\n  });\n}\n", "import { Observable } from '../Observable';\nimport { EmptyError } from '../util/EmptyError';\nimport { OperatorFunction, TruthyTypesOf } from '../types';\nimport { filter } from './filter';\nimport { take } from './take';\nimport { defaultIfEmpty } from './defaultIfEmpty';\nimport { throwIfEmpty } from './throwIfEmpty';\nimport { identity } from '../util/identity';\n\nexport function first<T, D = T>(predicate?: null, defaultValue?: D): OperatorFunction<T, T | D>;\nexport function first<T>(predicate: BooleanConstructor): OperatorFunction<T, TruthyTypesOf<T>>;\nexport function first<T, D>(predicate: BooleanConstructor, defaultValue: D): OperatorFunction<T, TruthyTypesOf<T> | D>;\nexport function first<T, S extends T>(\n  predicate: (value: T, index: number, source: Observable<T>) => value is S,\n  defaultValue?: S\n): OperatorFunction<T, S>;\nexport function first<T, S extends T, D>(\n  predicate: (value: T, index: number, source: Observable<T>) => value is S,\n  defaultValue: D\n): OperatorFunction<T, S | D>;\nexport function first<T, D = T>(\n  predicate: (value: T, index: number, source: Observable<T>) => boolean,\n  defaultValue?: D\n): OperatorFunction<T, T | D>;\n\n/**\n * Emits only the first value (or the first value that meets some condition)\n * emitted by the source Observable.\n *\n * <span class=\"informal\">Emits only the first value. Or emits only the first\n * value that passes some test.</span>\n *\n * ![](first.png)\n *\n * If called with no arguments, `first` emits the first value of the source\n * Observable, then completes. If called with a `predicate` function, `first`\n * emits the first value of the source that matches the specified condition. Throws an error if\n * `defaultValue` was not provided and a matching element is not found.\n *\n * ## Examples\n *\n * Emit only the first click that happens on the DOM\n *\n * ```ts\n * import { fromEvent, first } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(first());\n * result.subscribe(x => console.log(x));\n * ```\n *\n * Emits the first click that happens on a DIV\n *\n * ```ts\n * import { fromEvent, first } from 'rxjs';\n *\n * const div = document.createElement('div');\n * div.style.cssText = 'width: 200px; height: 200px; background: #09c;';\n * document.body.appendChild(div);\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(first(ev => (<HTMLElement>ev.target).tagName === 'DIV'));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link filter}\n * @see {@link find}\n * @see {@link take}\n *\n * @throws {EmptyError} Delivers an EmptyError to the Observer's `error`\n * callback if the Observable completes before any `next` notification was sent.\n * This is how `first()` is different from {@link take}(1) which completes instead.\n *\n * @param {function(value: T, index: number, source: Observable<T>): boolean} [predicate]\n * An optional function called with each item to test for condition matching.\n * @param {D} [defaultValue] The default value emitted in case no valid value\n * was found on the source.\n * @return A function that returns an Observable that emits the first item that\n * matches the condition.\n */\nexport function first<T, D>(\n  predicate?: ((value: T, index: number, source: Observable<T>) => boolean) | null,\n  defaultValue?: D\n): OperatorFunction<T, T | D> {\n  const hasDefaultValue = arguments.length >= 2;\n  return (source: Observable<T>) =>\n    source.pipe(\n      predicate ? filter((v, i) => predicate(v, i, source)) : identity,\n      take(1),\n      hasDefaultValue ? defaultIfEmpty(defaultValue!) : throwIfEmpty(() => new EmptyError())\n    );\n}\n", "import { EMPTY } from '../observable/empty';\nimport { MonoTypeOperatorFunction } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/**\n * Waits for the source to complete, then emits the last N values from the source,\n * as specified by the `count` argument.\n *\n * ![](takeLast.png)\n *\n * `takeLast` results in an observable that will hold values up to `count` values in memory,\n * until the source completes. It then pushes all values in memory to the consumer, in the\n * order they were received from the source, then notifies the consumer that it is\n * complete.\n *\n * If for some reason the source completes before the `count` supplied to `takeLast` is reached,\n * all values received until that point are emitted, and then completion is notified.\n *\n * **Warning**: Using `takeLast` with an observable that never completes will result\n * in an observable that never emits a value.\n *\n * ## Example\n *\n * Take the last 3 values of an Observable with many values\n *\n * ```ts\n * import { range, takeLast } from 'rxjs';\n *\n * const many = range(1, 100);\n * const lastThree = many.pipe(takeLast(3));\n * lastThree.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link take}\n * @see {@link takeUntil}\n * @see {@link takeWhile}\n * @see {@link skip}\n *\n * @param count The maximum number of values to emit from the end of\n * the sequence of values emitted by the source Observable.\n * @return A function that returns an Observable that emits at most the last\n * `count` values emitted by the source Observable.\n */\nexport function takeLast<T>(count: number): MonoTypeOperatorFunction<T> {\n  return count <= 0\n    ? () => EMPTY\n    : operate((source, subscriber) => {\n        // This buffer will hold the values we are going to emit\n        // when the source completes. Since we only want to take the\n        // last N values, we can't emit until we're sure we're not getting\n        // any more values.\n        let buffer: T[] = [];\n        source.subscribe(\n          createOperatorSubscriber(\n            subscriber,\n            (value) => {\n              // Add the most recent value onto the end of our buffer.\n              buffer.push(value);\n              // If our buffer is now larger than the number of values we\n              // want to take, we remove the oldest value from the buffer.\n              count < buffer.length && buffer.shift();\n            },\n            () => {\n              // The source completed, we now know what are last values\n              // are, emit them in the order they were received.\n              for (const value of buffer) {\n                subscriber.next(value);\n              }\n              subscriber.complete();\n            },\n            // Errors are passed through to the consumer\n            undefined,\n            () => {\n              // During finalization release the values in our buffer.\n              buffer = null!;\n            }\n          )\n        );\n      });\n}\n", "import { ObservableInput, ObservableInputTuple, OperatorFunction, SchedulerLike } from '../types';\nimport { operate } from '../util/lift';\nimport { argsOrArgArray } from '../util/argsOrArgArray';\nimport { mergeAll } from './mergeAll';\nimport { popNumber, popScheduler } from '../util/args';\nimport { from } from '../observable/from';\n\n/** @deprecated Replaced with {@link mergeWith}. Will be removed in v8. */\nexport function merge<T, A extends readonly unknown[]>(...sources: [...ObservableInputTuple<A>]): OperatorFunction<T, T | A[number]>;\n/** @deprecated Replaced with {@link mergeWith}. Will be removed in v8. */\nexport function merge<T, A extends readonly unknown[]>(\n  ...sourcesAndConcurrency: [...ObservableInputTuple<A>, number]\n): OperatorFunction<T, T | A[number]>;\n/** @deprecated Replaced with {@link mergeWith}. Will be removed in v8. */\nexport function merge<T, A extends readonly unknown[]>(\n  ...sourcesAndScheduler: [...ObservableInputTuple<A>, SchedulerLike]\n): OperatorFunction<T, T | A[number]>;\n/** @deprecated Replaced with {@link mergeWith}. Will be removed in v8. */\nexport function merge<T, A extends readonly unknown[]>(\n  ...sourcesAndConcurrencyAndScheduler: [...ObservableInputTuple<A>, number, SchedulerLike]\n): OperatorFunction<T, T | A[number]>;\n\nexport function merge<T>(...args: unknown[]): OperatorFunction<T, unknown> {\n  const scheduler = popScheduler(args);\n  const concurrent = popNumber(args, Infinity);\n  args = argsOrArgArray(args);\n\n  return operate((source, subscriber) => {\n    mergeAll(concurrent)(from([source, ...(args as ObservableInput<T>[])], scheduler)).subscribe(subscriber);\n  });\n}\n", "import { ObservableInputTuple, OperatorFunction } from '../types';\nimport { merge } from './merge';\n\n/**\n * Merge the values from all observables to a single observable result.\n *\n * Creates an observable, that when subscribed to, subscribes to the source\n * observable, and all other sources provided as arguments. All values from\n * every source are emitted from the resulting subscription.\n *\n * When all sources complete, the resulting observable will complete.\n *\n * When any source errors, the resulting observable will error.\n *\n * ## Example\n *\n * Joining all outputs from multiple user input event streams\n *\n * ```ts\n * import { fromEvent, map, mergeWith } from 'rxjs';\n *\n * const clicks$ = fromEvent(document, 'click').pipe(map(() => 'click'));\n * const mousemoves$ = fromEvent(document, 'mousemove').pipe(map(() => 'mousemove'));\n * const dblclicks$ = fromEvent(document, 'dblclick').pipe(map(() => 'dblclick'));\n *\n * mousemoves$\n *   .pipe(mergeWith(clicks$, dblclicks$))\n *   .subscribe(x => console.log(x));\n *\n * // result (assuming user interactions)\n * // 'mousemove'\n * // 'mousemove'\n * // 'mousemove'\n * // 'click'\n * // 'click'\n * // 'dblclick'\n * ```\n *\n * @see {@link merge}\n *\n * @param otherSources the sources to combine the current source with.\n * @return A function that returns an Observable that merges the values from\n * all given Observables.\n */\nexport function mergeWith<T, A extends readonly unknown[]>(\n  ...otherSources: [...ObservableInputTuple<A>]\n): OperatorFunction<T, T | A[number]> {\n  return merge(...otherSources);\n}\n", "import { Subscription } from '../Subscription';\nimport { EMPTY } from '../observable/empty';\nimport { operate } from '../util/lift';\nimport { MonoTypeOperatorFunction, ObservableInput } from '../types';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { innerFrom } from '../observable/innerFrom';\nimport { timer } from '../observable/timer';\n\nexport interface RepeatConfig {\n  /**\n   * The number of times to repeat the source. Defaults to `Infinity`.\n   */\n  count?: number;\n\n  /**\n   * If a `number`, will delay the repeat of the source by that number of milliseconds.\n   * If a function, it will provide the number of times the source has been subscribed to,\n   * and the return value should be a valid observable input that will notify when the source\n   * should be repeated. If the notifier observable is empty, the result will complete.\n   */\n  delay?: number | ((count: number) => ObservableInput<any>);\n}\n\n/**\n * Returns an Observable that will resubscribe to the source stream when the source stream completes.\n *\n * <span class=\"informal\">Repeats all values emitted on the source. It's like {@link retry}, but for non error cases.</span>\n *\n * ![](repeat.png)\n *\n * Repeat will output values from a source until the source completes, then it will resubscribe to the\n * source a specified number of times, with a specified delay. Repeat can be particularly useful in\n * combination with closing operators like {@link take}, {@link takeUntil}, {@link first}, or {@link takeWhile},\n * as it can be used to restart a source again from scratch.\n *\n * Repeat is very similar to {@link retry}, where {@link retry} will resubscribe to the source in the error case, but\n * `repeat` will resubscribe if the source completes.\n *\n * Note that `repeat` will _not_ catch errors. Use {@link retry} for that.\n *\n * - `repeat(0)` returns an empty observable\n * - `repeat()` will repeat forever\n * - `repeat({ delay: 200 })` will repeat forever, with a delay of 200ms between repetitions.\n * - `repeat({ count: 2, delay: 400 })` will repeat twice, with a delay of 400ms between repetitions.\n * - `repeat({ delay: (count) => timer(count * 1000) })` will repeat forever, but will have a delay that grows by one second for each repetition.\n *\n * ## Example\n *\n * Repeat a message stream\n *\n * ```ts\n * import { of, repeat } from 'rxjs';\n *\n * const source = of('Repeat message');\n * const result = source.pipe(repeat(3));\n *\n * result.subscribe(x => console.log(x));\n *\n * // Results\n * // 'Repeat message'\n * // 'Repeat message'\n * // 'Repeat message'\n * ```\n *\n * Repeat 3 values, 2 times\n *\n * ```ts\n * import { interval, take, repeat } from 'rxjs';\n *\n * const source = interval(1000);\n * const result = source.pipe(take(3), repeat(2));\n *\n * result.subscribe(x => console.log(x));\n *\n * // Results every second\n * // 0\n * // 1\n * // 2\n * // 0\n * // 1\n * // 2\n * ```\n *\n * Defining two complex repeats with delays on the same source.\n * Note that the second repeat cannot be called until the first\n * repeat as exhausted it's count.\n *\n * ```ts\n * import { defer, of, repeat } from 'rxjs';\n *\n * const source = defer(() => {\n *    return of(`Hello, it is ${new Date()}`)\n * });\n *\n * source.pipe(\n *    // Repeat 3 times with a delay of 1 second between repetitions\n *    repeat({\n *      count: 3,\n *      delay: 1000,\n *    }),\n *\n *    // *Then* repeat forever, but with an exponential step-back\n *    // maxing out at 1 minute.\n *    repeat({\n *      delay: (count) => timer(Math.min(60000, 2 ^ count * 1000))\n *    })\n * )\n * ```\n *\n * @see {@link repeatWhen}\n * @see {@link retry}\n *\n * @param count The number of times the source Observable items are repeated, a count of 0 will yield\n * an empty Observable.\n */\nexport function repeat<T>(countOrConfig?: number | RepeatConfig): MonoTypeOperatorFunction<T> {\n  let count = Infinity;\n  let delay: RepeatConfig['delay'];\n\n  if (countOrConfig != null) {\n    if (typeof countOrConfig === 'object') {\n      ({ count = Infinity, delay } = countOrConfig);\n    } else {\n      count = countOrConfig;\n    }\n  }\n\n  return count <= 0\n    ? () => EMPTY\n    : operate((source, subscriber) => {\n        let soFar = 0;\n        let sourceSub: Subscription | null;\n\n        const resubscribe = () => {\n          sourceSub?.unsubscribe();\n          sourceSub = null;\n          if (delay != null) {\n            const notifier = typeof delay === 'number' ? timer(delay) : innerFrom(delay(soFar));\n            const notifierSubscriber = createOperatorSubscriber(subscriber, () => {\n              notifierSubscriber.unsubscribe();\n              subscribeToSource();\n            });\n            notifier.subscribe(notifierSubscriber);\n          } else {\n            subscribeToSource();\n          }\n        };\n\n        const subscribeToSource = () => {\n          let syncUnsub = false;\n          sourceSub = source.subscribe(\n            createOperatorSubscriber(subscriber, undefined, () => {\n              if (++soFar < count) {\n                if (sourceSub) {\n                  resubscribe();\n                } else {\n                  syncUnsub = true;\n                }\n              } else {\n                subscriber.complete();\n              }\n            })\n          );\n\n          if (syncUnsub) {\n            resubscribe();\n          }\n        };\n\n        subscribeToSource();\n      });\n}\n", "import { OperatorFunction } from '../types';\nimport { operate } from '../util/lift';\nimport { scanInternals } from './scanInternals';\n\nexport function scan<V, A = V>(accumulator: (acc: A | V, value: V, index: number) => A): OperatorFunction<V, V | A>;\nexport function scan<V, A>(accumulator: (acc: A, value: V, index: number) => A, seed: A): OperatorFunction<V, A>;\nexport function scan<V, A, S>(accumulator: (acc: A | S, value: V, index: number) => A, seed: S): OperatorFunction<V, A>;\n\n// TODO: link to a \"redux pattern\" section in the guide (location TBD)\n\n/**\n * Useful for encapsulating and managing state. Applies an accumulator (or \"reducer function\")\n * to each value from the source after an initial state is established -- either via\n * a `seed` value (second argument), or from the first value from the source.\n *\n * <span class=\"informal\">It's like {@link reduce}, but emits the current\n * accumulation state after each update</span>\n *\n * ![](scan.png)\n *\n * This operator maintains an internal state and emits it after processing each value as follows:\n *\n * 1. First value arrives\n *   - If a `seed` value was supplied (as the second argument to `scan`), let `state = seed` and `value = firstValue`.\n *   - If NO `seed` value was supplied (no second argument), let `state = firstValue` and go to 3.\n * 2. Let `state = accumulator(state, value)`.\n *   - If an error is thrown by `accumulator`, notify the consumer of an error. The process ends.\n * 3. Emit `state`.\n * 4. Next value arrives, let `value = nextValue`, go to 2.\n *\n * ## Examples\n *\n * An average of previous numbers. This example shows how\n * not providing a `seed` can prime the stream with the\n * first value from the source.\n *\n * ```ts\n * import { of, scan, map } from 'rxjs';\n *\n * const numbers$ = of(1, 2, 3);\n *\n * numbers$\n *   .pipe(\n *     // Get the sum of the numbers coming in.\n *     scan((total, n) => total + n),\n *     // Get the average by dividing the sum by the total number\n *     // received so far (which is 1 more than the zero-based index).\n *     map((sum, index) => sum / (index + 1))\n *   )\n *   .subscribe(console.log);\n * ```\n *\n * The Fibonacci sequence. This example shows how you can use\n * a seed to prime accumulation process. Also... you know... Fibonacci.\n * So important to like, computers and stuff that its whiteboarded\n * in job interviews. Now you can show them the Rx version! (Please don't, haha)\n *\n * ```ts\n * import { interval, scan, map, startWith } from 'rxjs';\n *\n * const firstTwoFibs = [0, 1];\n * // An endless stream of Fibonacci numbers.\n * const fibonacci$ = interval(1000).pipe(\n *   // Scan to get the fibonacci numbers (after 0, 1)\n *   scan(([a, b]) => [b, a + b], firstTwoFibs),\n *   // Get the second number in the tuple, it's the one you calculated\n *   map(([, n]) => n),\n *   // Start with our first two digits :)\n *   startWith(...firstTwoFibs)\n * );\n *\n * fibonacci$.subscribe(console.log);\n * ```\n *\n * @see {@link expand}\n * @see {@link mergeScan}\n * @see {@link reduce}\n * @see {@link switchScan}\n *\n * @param accumulator A \"reducer function\". This will be called for each value after an initial state is\n * acquired.\n * @param seed The initial state. If this is not provided, the first value from the source will\n * be used as the initial state, and emitted without going through the accumulator. All subsequent values\n * will be processed by the accumulator function. If this is provided, all values will go through\n * the accumulator function.\n * @return A function that returns an Observable of the accumulated values.\n */\nexport function scan<V, A, S>(accumulator: (acc: V | A | S, value: V, index: number) => A, seed?: S): OperatorFunction<V, V | A> {\n  // providing a seed of `undefined` *should* be valid and trigger\n  // hasSeed! so don't use `seed !== undefined` checks!\n  // For this reason, we have to check it here at the original call site\n  // otherwise inside Operator/Subscriber we won't know if `undefined`\n  // means they didn't provide anything or if they literally provided `undefined`\n  return operate(scanInternals(accumulator, seed as S, arguments.length >= 2, true));\n}\n", "import { innerFrom } from '../observable/innerFrom';\nimport { Subject } from '../Subject';\nimport { SafeSubscriber } from '../Subscriber';\nimport { Subscription } from '../Subscription';\nimport { MonoTypeOperatorFunction, SubjectLike, ObservableInput } from '../types';\nimport { operate } from '../util/lift';\n\nexport interface ShareConfig<T> {\n  /**\n   * The factory used to create the subject that will connect the source observable to\n   * multicast consumers.\n   */\n  connector?: () => SubjectLike<T>;\n  /**\n   * If `true`, the resulting observable will reset internal state on error from source and return to a \"cold\" state. This\n   * allows the resulting observable to be \"retried\" in the event of an error.\n   * If `false`, when an error comes from the source it will push the error into the connecting subject, and the subject\n   * will remain the connecting subject, meaning the resulting observable will not go \"cold\" again, and subsequent retries\n   * or resubscriptions will resubscribe to that same subject. In all cases, RxJS subjects will emit the same error again, however\n   * {@link ReplaySubject} will also push its buffered values before pushing the error.\n   * It is also possible to pass a notifier factory returning an `ObservableInput` instead which grants more fine-grained\n   * control over how and when the reset should happen. This allows behaviors like conditional or delayed resets.\n   */\n  resetOnError?: boolean | ((error: any) => ObservableInput<any>);\n  /**\n   * If `true`, the resulting observable will reset internal state on completion from source and return to a \"cold\" state. This\n   * allows the resulting observable to be \"repeated\" after it is done.\n   * If `false`, when the source completes, it will push the completion through the connecting subject, and the subject\n   * will remain the connecting subject, meaning the resulting observable will not go \"cold\" again, and subsequent repeats\n   * or resubscriptions will resubscribe to that same subject.\n   * It is also possible to pass a notifier factory returning an `ObservableInput` instead which grants more fine-grained\n   * control over how and when the reset should happen. This allows behaviors like conditional or delayed resets.\n   */\n  resetOnComplete?: boolean | (() => ObservableInput<any>);\n  /**\n   * If `true`, when the number of subscribers to the resulting observable reaches zero due to those subscribers unsubscribing, the\n   * internal state will be reset and the resulting observable will return to a \"cold\" state. This means that the next\n   * time the resulting observable is subscribed to, a new subject will be created and the source will be subscribed to\n   * again.\n   * If `false`, when the number of subscribers to the resulting observable reaches zero due to unsubscription, the subject\n   * will remain connected to the source, and new subscriptions to the result will be connected through that same subject.\n   * It is also possible to pass a notifier factory returning an `ObservableInput` instead which grants more fine-grained\n   * control over how and when the reset should happen. This allows behaviors like conditional or delayed resets.\n   */\n  resetOnRefCountZero?: boolean | (() => ObservableInput<any>);\n}\n\nexport function share<T>(): MonoTypeOperatorFunction<T>;\n\nexport function share<T>(options: ShareConfig<T>): MonoTypeOperatorFunction<T>;\n\n/**\n * Returns a new Observable that multicasts (shares) the original Observable. As long as there is at least one\n * Subscriber this Observable will be subscribed and emitting data. When all subscribers have unsubscribed it will\n * unsubscribe from the source Observable. Because the Observable is multicasting it makes the stream `hot`.\n * This is an alias for `multicast(() => new Subject()), refCount()`.\n *\n * The subscription to the underlying source Observable can be reset (unsubscribe and resubscribe for new subscribers),\n * if the subscriber count to the shared observable drops to 0, or if the source Observable errors or completes. It is\n * possible to use notifier factories for the resets to allow for behaviors like conditional or delayed resets. Please\n * note that resetting on error or complete of the source Observable does not behave like a transparent retry or restart\n * of the source because the error or complete will be forwarded to all subscribers and their subscription will be\n * closed. Only new subscribers after a reset on error or complete happened will cause a fresh subscription to the\n * source. To achieve transparent retries or restarts pipe the source through appropriate operators before sharing.\n *\n * ![](share.png)\n *\n * ## Example\n *\n * Generate new multicast Observable from the `source` Observable value\n *\n * ```ts\n * import { interval, tap, map, take, share } from 'rxjs';\n *\n * const source = interval(1000).pipe(\n *   tap(x => console.log('Processing: ', x)),\n *   map(x => x * x),\n *   take(6),\n *   share()\n * );\n *\n * source.subscribe(x => console.log('subscription 1: ', x));\n * source.subscribe(x => console.log('subscription 2: ', x));\n *\n * // Logs:\n * // Processing: 0\n * // subscription 1: 0\n * // subscription 2: 0\n * // Processing: 1\n * // subscription 1: 1\n * // subscription 2: 1\n * // Processing: 2\n * // subscription 1: 4\n * // subscription 2: 4\n * // Processing: 3\n * // subscription 1: 9\n * // subscription 2: 9\n * // Processing: 4\n * // subscription 1: 16\n * // subscription 2: 16\n * // Processing: 5\n * // subscription 1: 25\n * // subscription 2: 25\n * ```\n *\n * ## Example with notifier factory: Delayed reset\n *\n * ```ts\n * import { interval, take, share, timer } from 'rxjs';\n *\n * const source = interval(1000).pipe(\n *   take(3),\n *   share({\n *     resetOnRefCountZero: () => timer(1000)\n *   })\n * );\n *\n * const subscriptionOne = source.subscribe(x => console.log('subscription 1: ', x));\n * setTimeout(() => subscriptionOne.unsubscribe(), 1300);\n *\n * setTimeout(() => source.subscribe(x => console.log('subscription 2: ', x)), 1700);\n *\n * setTimeout(() => source.subscribe(x => console.log('subscription 3: ', x)), 5000);\n *\n * // Logs:\n * // subscription 1:  0\n * // (subscription 1 unsubscribes here)\n * // (subscription 2 subscribes here ~400ms later, source was not reset)\n * // subscription 2:  1\n * // subscription 2:  2\n * // (subscription 2 unsubscribes here)\n * // (subscription 3 subscribes here ~2000ms later, source did reset before)\n * // subscription 3:  0\n * // subscription 3:  1\n * // subscription 3:  2\n * ```\n *\n * @see {@link shareReplay}\n *\n * @return A function that returns an Observable that mirrors the source.\n */\nexport function share<T>(options: ShareConfig<T> = {}): MonoTypeOperatorFunction<T> {\n  const { connector = () => new Subject<T>(), resetOnError = true, resetOnComplete = true, resetOnRefCountZero = true } = options;\n  // It's necessary to use a wrapper here, as the _operator_ must be\n  // referentially transparent. Otherwise, it cannot be used in calls to the\n  // static `pipe` function - to create a partial pipeline.\n  //\n  // The _operator function_ - the function returned by the _operator_ - will\n  // not be referentially transparent - as it shares its source - but the\n  // _operator function_ is called when the complete pipeline is composed via a\n  // call to a source observable's `pipe` method - not when the static `pipe`\n  // function is called.\n  return (wrapperSource) => {\n    let connection: SafeSubscriber<T> | undefined;\n    let resetConnection: Subscription | undefined;\n    let subject: SubjectLike<T> | undefined;\n    let refCount = 0;\n    let hasCompleted = false;\n    let hasErrored = false;\n\n    const cancelReset = () => {\n      resetConnection?.unsubscribe();\n      resetConnection = undefined;\n    };\n    // Used to reset the internal state to a \"cold\"\n    // state, as though it had never been subscribed to.\n    const reset = () => {\n      cancelReset();\n      connection = subject = undefined;\n      hasCompleted = hasErrored = false;\n    };\n    const resetAndUnsubscribe = () => {\n      // We need to capture the connection before\n      // we reset (if we need to reset).\n      const conn = connection;\n      reset();\n      conn?.unsubscribe();\n    };\n\n    return operate<T, T>((source, subscriber) => {\n      refCount++;\n      if (!hasErrored && !hasCompleted) {\n        cancelReset();\n      }\n\n      // Create the subject if we don't have one yet. Grab a local reference to\n      // it as well, which avoids non-null assertions when using it and, if we\n      // connect to it now, then error/complete need a reference after it was\n      // reset.\n      const dest = (subject = subject ?? connector());\n\n      // Add the finalization directly to the subscriber - instead of returning it -\n      // so that the handling of the subscriber's unsubscription will be wired\n      // up _before_ the subscription to the source occurs. This is done so that\n      // the assignment to the source connection's `closed` property will be seen\n      // by synchronous firehose sources.\n      subscriber.add(() => {\n        refCount--;\n\n        // If we're resetting on refCount === 0, and it's 0, we only want to do\n        // that on \"unsubscribe\", really. Resetting on error or completion is a different\n        // configuration.\n        if (refCount === 0 && !hasErrored && !hasCompleted) {\n          resetConnection = handleReset(resetAndUnsubscribe, resetOnRefCountZero);\n        }\n      });\n\n      // The following line adds the subscription to the subscriber passed.\n      // Basically, `subscriber === dest.subscribe(subscriber)` is `true`.\n      dest.subscribe(subscriber);\n\n      if (\n        !connection &&\n        // Check this shareReplay is still activate - it can be reset to 0\n        // and be \"unsubscribed\" _before_ it actually subscribes.\n        // If we were to subscribe then, it'd leak and get stuck.\n        refCount > 0\n      ) {\n        // We need to create a subscriber here - rather than pass an observer and\n        // assign the returned subscription to connection - because it's possible\n        // for reentrant subscriptions to the shared observable to occur and in\n        // those situations we want connection to be already-assigned so that we\n        // don't create another connection to the source.\n        connection = new SafeSubscriber({\n          next: (value) => dest.next(value),\n          error: (err) => {\n            hasErrored = true;\n            cancelReset();\n            resetConnection = handleReset(reset, resetOnError, err);\n            dest.error(err);\n          },\n          complete: () => {\n            hasCompleted = true;\n            cancelReset();\n            resetConnection = handleReset(reset, resetOnComplete);\n            dest.complete();\n          },\n        });\n        innerFrom(source).subscribe(connection);\n      }\n    })(wrapperSource);\n  };\n}\n\nfunction handleReset<T extends unknown[] = never[]>(\n  reset: () => void,\n  on: boolean | ((...args: T) => ObservableInput<any>),\n  ...args: T\n): Subscription | undefined {\n  if (on === true) {\n    reset();\n    return;\n  }\n\n  if (on === false) {\n    return;\n  }\n\n  const onSubscriber = new SafeSubscriber({\n    next: () => {\n      onSubscriber.unsubscribe();\n      reset();\n    },\n  });\n\n  return innerFrom(on(...args)).subscribe(onSubscriber);\n}\n", "import { ReplaySubject } from '../ReplaySubject';\nimport { MonoTypeOperatorFunction, SchedulerLike } from '../types';\nimport { share } from './share';\n\nexport interface ShareReplayConfig {\n  bufferSize?: number;\n  windowTime?: number;\n  refCount: boolean;\n  scheduler?: SchedulerLike;\n}\n\nexport function shareReplay<T>(config: ShareReplayConfig): MonoTypeOperatorFunction<T>;\nexport function shareReplay<T>(bufferSize?: number, windowTime?: number, scheduler?: SchedulerLike): MonoTypeOperatorFunction<T>;\n\n/**\n * Share source and replay specified number of emissions on subscription.\n *\n * This operator is a specialization of `replay` that connects to a source observable\n * and multicasts through a `ReplaySubject` constructed with the specified arguments.\n * A successfully completed source will stay cached in the `shareReplay`ed observable forever,\n * but an errored source can be retried.\n *\n * ## Why use `shareReplay`?\n *\n * You generally want to use `shareReplay` when you have side-effects or taxing computations\n * that you do not wish to be executed amongst multiple subscribers.\n * It may also be valuable in situations where you know you will have late subscribers to\n * a stream that need access to previously emitted values.\n * This ability to replay values on subscription is what differentiates {@link share} and `shareReplay`.\n *\n * ## Reference counting\n *\n * By default `shareReplay` will use `refCount` of false, meaning that it will _not_ unsubscribe the\n * source when the reference counter drops to zero, i.e. the inner `ReplaySubject` will _not_ be unsubscribed\n * (and potentially run for ever).\n * This is the default as it is expected that `shareReplay` is often used to keep around expensive to setup\n * observables which we want to keep running instead of having to do the expensive setup again.\n *\n * As of RXJS version 6.4.0 a new overload signature was added to allow for manual control over what\n * happens when the operators internal reference counter drops to zero.\n * If `refCount` is true, the source will be unsubscribed from once the reference count drops to zero, i.e.\n * the inner `ReplaySubject` will be unsubscribed. All new subscribers will receive value emissions from a\n * new `ReplaySubject` which in turn will cause a new subscription to the source observable.\n *\n * ## Examples\n *\n * Example with a third subscriber coming late to the party\n *\n * ```ts\n * import { interval, take, shareReplay } from 'rxjs';\n *\n * const shared$ = interval(2000).pipe(\n *   take(6),\n *   shareReplay(3)\n * );\n *\n * shared$.subscribe(x => console.log('sub A: ', x));\n * shared$.subscribe(y => console.log('sub B: ', y));\n *\n * setTimeout(() => {\n *   shared$.subscribe(y => console.log('sub C: ', y));\n * }, 11000);\n *\n * // Logs:\n * // (after ~2000 ms)\n * // sub A: 0\n * // sub B: 0\n * // (after ~4000 ms)\n * // sub A: 1\n * // sub B: 1\n * // (after ~6000 ms)\n * // sub A: 2\n * // sub B: 2\n * // (after ~8000 ms)\n * // sub A: 3\n * // sub B: 3\n * // (after ~10000 ms)\n * // sub A: 4\n * // sub B: 4\n * // (after ~11000 ms, sub C gets the last 3 values)\n * // sub C: 2\n * // sub C: 3\n * // sub C: 4\n * // (after ~12000 ms)\n * // sub A: 5\n * // sub B: 5\n * // sub C: 5\n * ```\n *\n * Example for `refCount` usage\n *\n * ```ts\n * import { Observable, tap, interval, shareReplay, take } from 'rxjs';\n *\n * const log = <T>(name: string, source: Observable<T>) => source.pipe(\n *   tap({\n *     subscribe: () => console.log(`${ name }: subscribed`),\n *     next: value => console.log(`${ name }: ${ value }`),\n *     complete: () => console.log(`${ name }: completed`),\n *     finalize: () => console.log(`${ name }: unsubscribed`)\n *   })\n * );\n *\n * const obs$ = log('source', interval(1000));\n *\n * const shared$ = log('shared', obs$.pipe(\n *   shareReplay({ bufferSize: 1, refCount: true }),\n *   take(2)\n * ));\n *\n * shared$.subscribe(x => console.log('sub A: ', x));\n * shared$.subscribe(y => console.log('sub B: ', y));\n *\n * // PRINTS:\n * // shared: subscribed <-- reference count = 1\n * // source: subscribed\n * // shared: subscribed <-- reference count = 2\n * // source: 0\n * // shared: 0\n * // sub A: 0\n * // shared: 0\n * // sub B: 0\n * // source: 1\n * // shared: 1\n * // sub A: 1\n * // shared: completed <-- take(2) completes the subscription for sub A\n * // shared: unsubscribed <-- reference count = 1\n * // shared: 1\n * // sub B: 1\n * // shared: completed <-- take(2) completes the subscription for sub B\n * // shared: unsubscribed <-- reference count = 0\n * // source: unsubscribed <-- replaySubject unsubscribes from source observable because the reference count dropped to 0 and refCount is true\n *\n * // In case of refCount being false, the unsubscribe is never called on the source and the source would keep on emitting, even if no subscribers\n * // are listening.\n * // source: 2\n * // source: 3\n * // source: 4\n * // ...\n * ```\n *\n * @see {@link publish}\n * @see {@link share}\n * @see {@link publishReplay}\n *\n * @param configOrBufferSize Maximum element count of the replay buffer or {@link ShareReplayConfig configuration}\n * object.\n * @param windowTime Maximum time length of the replay buffer in milliseconds.\n * @param scheduler Scheduler where connected observers within the selector function\n * will be invoked on.\n * @return A function that returns an Observable sequence that contains the\n * elements of a sequence produced by multicasting the source sequence within a\n * selector function.\n */\nexport function shareReplay<T>(\n  configOrBufferSize?: ShareReplayConfig | number,\n  windowTime?: number,\n  scheduler?: SchedulerLike\n): MonoTypeOperatorFunction<T> {\n  let bufferSize: number;\n  let refCount = false;\n  if (configOrBufferSize && typeof configOrBufferSize === 'object') {\n    ({ bufferSize = Infinity, windowTime = Infinity, refCount = false, scheduler } = configOrBufferSize);\n  } else {\n    bufferSize = (configOrBufferSize ?? Infinity) as number;\n  }\n  return share<T>({\n    connector: () => new ReplaySubject(bufferSize, windowTime, scheduler),\n    resetOnError: true,\n    resetOnComplete: false,\n    resetOnRefCountZero: refCount,\n  });\n}\n", "import { MonoTypeOperatorFunction } from '../types';\nimport { filter } from './filter';\n\n/**\n * Returns an Observable that skips the first `count` items emitted by the source Observable.\n *\n * ![](skip.png)\n *\n * Skips the values until the sent notifications are equal or less than provided skip count. It raises\n * an error if skip count is equal or more than the actual number of emits and source raises an error.\n *\n * ## Example\n *\n * Skip the values before the emission\n *\n * ```ts\n * import { interval, skip } from 'rxjs';\n *\n * // emit every half second\n * const source = interval(500);\n * // skip the first 10 emitted values\n * const result = source.pipe(skip(10));\n *\n * result.subscribe(value => console.log(value));\n * // output: 10...11...12...13...\n * ```\n *\n * @see {@link last}\n * @see {@link skipWhile}\n * @see {@link skipUntil}\n * @see {@link skipLast}\n *\n * @param {Number} count - The number of times, items emitted by source Observable should be skipped.\n * @return A function that returns an Observable that skips the first `count`\n * values emitted by the source Observable.\n */\nexport function skip<T>(count: number): MonoTypeOperatorFunction<T> {\n  return filter((_, index) => count <= index);\n}\n", "import { MonoTypeOperatorFunction, ObservableInput } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { innerFrom } from '../observable/innerFrom';\nimport { noop } from '../util/noop';\n\n/**\n * Returns an Observable that skips items emitted by the source Observable until a second Observable emits an item.\n *\n * The `skipUntil` operator causes the observable stream to skip the emission of values until the passed in observable\n * emits the first value. This can be particularly useful in combination with user interactions, responses of HTTP\n * requests or waiting for specific times to pass by.\n *\n * ![](skipUntil.png)\n *\n * Internally, the `skipUntil` operator subscribes to the passed in `notifier` `ObservableInput` (which gets converted\n * to an Observable) in order to recognize the emission of its first value. When `notifier` emits next, the operator\n * unsubscribes from it and starts emitting the values of the *source* observable until it completes or errors. It\n * will never let the *source* observable emit any values if the `notifier` completes or throws an error without\n * emitting a value before.\n *\n * ## Example\n *\n * In the following example, all emitted values of the interval observable are skipped until the user clicks anywhere\n * within the page\n *\n * ```ts\n * import { interval, fromEvent, skipUntil } from 'rxjs';\n *\n * const intervalObservable = interval(1000);\n * const click = fromEvent(document, 'click');\n *\n * const emitAfterClick = intervalObservable.pipe(\n *   skipUntil(click)\n * );\n * // clicked at 4.6s. output: 5...6...7...8........ or\n * // clicked at 7.3s. output: 8...9...10..11.......\n * emitAfterClick.subscribe(value => console.log(value));\n * ```\n *\n * @see {@link last}\n * @see {@link skip}\n * @see {@link skipWhile}\n * @see {@link skipLast}\n *\n * @param notifier An `ObservableInput` that has to emit an item before the source Observable elements begin to\n * be mirrored by the resulting Observable.\n * @return A function that returns an Observable that skips items from the\n * source Observable until the `notifier` Observable emits an item, then emits the\n * remaining items.\n */\nexport function skipUntil<T>(notifier: ObservableInput<any>): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    let taking = false;\n\n    const skipSubscriber = createOperatorSubscriber(\n      subscriber,\n      () => {\n        skipSubscriber?.unsubscribe();\n        taking = true;\n      },\n      noop\n    );\n\n    innerFrom(notifier).subscribe(skipSubscriber);\n\n    source.subscribe(createOperatorSubscriber(subscriber, (value) => taking && subscriber.next(value)));\n  });\n}\n", "import { concat } from '../observable/concat';\nimport { OperatorFunction, SchedulerLike, ValueFromArray } from '../types';\nimport { popScheduler } from '../util/args';\nimport { operate } from '../util/lift';\n\n// Devs are more likely to pass null or undefined than they are a scheduler\n// without accompanying values. To make things easier for (naughty) devs who\n// use the `strictNullChecks: false` TypeScript compiler option, these\n// overloads with explicit null and undefined values are included.\n\nexport function startWith<T>(value: null): OperatorFunction<T, T | null>;\nexport function startWith<T>(value: undefined): OperatorFunction<T, T | undefined>;\n\n/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `concatAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */\nexport function startWith<T, A extends readonly unknown[] = T[]>(\n  ...valuesAndScheduler: [...A, SchedulerLike]\n): OperatorFunction<T, T | ValueFromArray<A>>;\nexport function startWith<T, A extends readonly unknown[] = T[]>(...values: A): OperatorFunction<T, T | ValueFromArray<A>>;\n\n/**\n * Returns an observable that, at the moment of subscription, will synchronously emit all\n * values provided to this operator, then subscribe to the source and mirror all of its emissions\n * to subscribers.\n *\n * This is a useful way to know when subscription has occurred on an existing observable.\n *\n * <span class=\"informal\">First emits its arguments in order, and then any\n * emissions from the source.</span>\n *\n * ![](startWith.png)\n *\n * ## Examples\n *\n * Emit a value when a timer starts.\n *\n * ```ts\n * import { timer, map, startWith } from 'rxjs';\n *\n * timer(1000)\n *   .pipe(\n *     map(() => 'timer emit'),\n *     startWith('timer start')\n *   )\n *   .subscribe(x => console.log(x));\n *\n * // results:\n * // 'timer start'\n * // 'timer emit'\n * ```\n *\n * @param values Items you want the modified Observable to emit first.\n * @return A function that returns an Observable that synchronously emits\n * provided values before subscribing to the source Observable.\n *\n * @see {@link endWith}\n * @see {@link finalize}\n * @see {@link concat}\n */\nexport function startWith<T, D>(...values: D[]): OperatorFunction<T, T | D> {\n  const scheduler = popScheduler(values);\n  return operate((source, subscriber) => {\n    // Here we can't pass `undefined` as a scheduler, because if we did, the\n    // code inside of `concat` would be confused by the `undefined`, and treat it\n    // like an invalid observable. So we have to split it two different ways.\n    (scheduler ? concat(values, source, scheduler) : concat(values, source)).subscribe(subscriber);\n  });\n}\n", "import { Subscriber } from '../Subscriber';\nimport { ObservableInput, OperatorFunction, ObservedValueOf } from '../types';\nimport { innerFrom } from '../observable/innerFrom';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\n/* tslint:disable:max-line-length */\nexport function switchMap<T, O extends ObservableInput<any>>(\n  project: (value: T, index: number) => O\n): OperatorFunction<T, ObservedValueOf<O>>;\n/** @deprecated The `resultSelector` parameter will be removed in v8. Use an inner `map` instead. Details: https://rxjs.dev/deprecations/resultSelector */\nexport function switchMap<T, O extends ObservableInput<any>>(\n  project: (value: T, index: number) => O,\n  resultSelector: undefined\n): OperatorFunction<T, ObservedValueOf<O>>;\n/** @deprecated The `resultSelector` parameter will be removed in v8. Use an inner `map` instead. Details: https://rxjs.dev/deprecations/resultSelector */\nexport function switchMap<T, R, O extends ObservableInput<any>>(\n  project: (value: T, index: number) => O,\n  resultSelector: (outerValue: T, innerValue: ObservedValueOf<O>, outerIndex: number, innerIndex: number) => R\n): OperatorFunction<T, R>;\n/* tslint:enable:max-line-length */\n\n/**\n * Projects each source value to an Observable which is merged in the output\n * Observable, emitting values only from the most recently projected Observable.\n *\n * <span class=\"informal\">Maps each value to an Observable, then flattens all of\n * these inner Observables using {@link switchAll}.</span>\n *\n * ![](switchMap.png)\n *\n * Returns an Observable that emits items based on applying a function that you\n * supply to each item emitted by the source Observable, where that function\n * returns an (so-called \"inner\") Observable. Each time it observes one of these\n * inner Observables, the output Observable begins emitting the items emitted by\n * that inner Observable. When a new inner Observable is emitted, `switchMap`\n * stops emitting items from the earlier-emitted inner Observable and begins\n * emitting items from the new one. It continues to behave like this for\n * subsequent inner Observables.\n *\n * ## Example\n *\n * Generate new Observable according to source Observable values\n *\n * ```ts\n * import { of, switchMap } from 'rxjs';\n *\n * const switched = of(1, 2, 3).pipe(switchMap(x => of(x, x ** 2, x ** 3)));\n * switched.subscribe(x => console.log(x));\n * // outputs\n * // 1\n * // 1\n * // 1\n * // 2\n * // 4\n * // 8\n * // 3\n * // 9\n * // 27\n * ```\n *\n * Restart an interval Observable on every click event\n *\n * ```ts\n * import { fromEvent, switchMap, interval } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(switchMap(() => interval(1000)));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link concatMap}\n * @see {@link exhaustMap}\n * @see {@link mergeMap}\n * @see {@link switchAll}\n * @see {@link switchMapTo}\n *\n * @param {function(value: T, index: number): ObservableInput} project A function\n * that, when applied to an item emitted by the source Observable, returns an\n * Observable.\n * @return A function that returns an Observable that emits the result of\n * applying the projection function (and the optional deprecated\n * `resultSelector`) to each item emitted by the source Observable and taking\n * only the values from the most recently projected inner Observable.\n */\nexport function switchMap<T, R, O extends ObservableInput<any>>(\n  project: (value: T, index: number) => O,\n  resultSelector?: (outerValue: T, innerValue: ObservedValueOf<O>, outerIndex: number, innerIndex: number) => R\n): OperatorFunction<T, ObservedValueOf<O> | R> {\n  return operate((source, subscriber) => {\n    let innerSubscriber: Subscriber<ObservedValueOf<O>> | null = null;\n    let index = 0;\n    // Whether or not the source subscription has completed\n    let isComplete = false;\n\n    // We only complete the result if the source is complete AND we don't have an active inner subscription.\n    // This is called both when the source completes and when the inners complete.\n    const checkComplete = () => isComplete && !innerSubscriber && subscriber.complete();\n\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        (value) => {\n          // Cancel the previous inner subscription if there was one\n          innerSubscriber?.unsubscribe();\n          let innerIndex = 0;\n          const outerIndex = index++;\n          // Start the next inner subscription\n          innerFrom(project(value, outerIndex)).subscribe(\n            (innerSubscriber = createOperatorSubscriber(\n              subscriber,\n              // When we get a new inner value, next it through. Note that this is\n              // handling the deprecate result selector here. This is because with this architecture\n              // it ends up being smaller than using the map operator.\n              (innerValue) => subscriber.next(resultSelector ? resultSelector(value, innerValue, outerIndex, innerIndex++) : innerValue),\n              () => {\n                // The inner has completed. Null out the inner subscriber to\n                // free up memory and to signal that we have no inner subscription\n                // currently.\n                innerSubscriber = null!;\n                checkComplete();\n              }\n            ))\n          );\n        },\n        () => {\n          isComplete = true;\n          checkComplete();\n        }\n      )\n    );\n  });\n}\n", "import { MonoTypeOperatorFunction, ObservableInput } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { innerFrom } from '../observable/innerFrom';\nimport { noop } from '../util/noop';\n\n/**\n * Emits the values emitted by the source Observable until a `notifier`\n * Observable emits a value.\n *\n * <span class=\"informal\">Lets values pass until a second Observable,\n * `notifier`, emits a value. Then, it completes.</span>\n *\n * ![](takeUntil.png)\n *\n * `takeUntil` subscribes and begins mirroring the source Observable. It also\n * monitors a second Observable, `notifier` that you provide. If the `notifier`\n * emits a value, the output Observable stops mirroring the source Observable\n * and completes. If the `notifier` doesn't emit any value and completes\n * then `takeUntil` will pass all values.\n *\n * ## Example\n *\n * Tick every second until the first click happens\n *\n * ```ts\n * import { interval, fromEvent, takeUntil } from 'rxjs';\n *\n * const source = interval(1000);\n * const clicks = fromEvent(document, 'click');\n * const result = source.pipe(takeUntil(clicks));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link take}\n * @see {@link takeLast}\n * @see {@link takeWhile}\n * @see {@link skip}\n *\n * @param {Observable} notifier The Observable whose first emitted value will\n * cause the output Observable of `takeUntil` to stop emitting values from the\n * source Observable.\n * @return A function that returns an Observable that emits the values from the\n * source Observable until `notifier` emits its first value.\n */\nexport function takeUntil<T>(notifier: ObservableInput<any>): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    innerFrom(notifier).subscribe(createOperatorSubscriber(subscriber, () => subscriber.complete(), noop));\n    !subscriber.closed && source.subscribe(subscriber);\n  });\n}\n", "import { OperatorFunction, MonoTypeOperatorFunction, TruthyTypesOf } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\n\nexport function takeWhile<T>(predicate: BooleanConstructor, inclusive: true): MonoTypeOperatorFunction<T>;\nexport function takeWhile<T>(predicate: BooleanConstructor, inclusive: false): OperatorFunction<T, TruthyTypesOf<T>>;\nexport function takeWhile<T>(predicate: BooleanConstructor): OperatorFunction<T, TruthyTypesOf<T>>;\nexport function takeWhile<T, S extends T>(predicate: (value: T, index: number) => value is S): OperatorFunction<T, S>;\nexport function takeWhile<T, S extends T>(predicate: (value: T, index: number) => value is S, inclusive: false): OperatorFunction<T, S>;\nexport function takeWhile<T>(predicate: (value: T, index: number) => boolean, inclusive?: boolean): MonoTypeOperatorFunction<T>;\n\n/**\n * Emits values emitted by the source Observable so long as each value satisfies\n * the given `predicate`, and then completes as soon as this `predicate` is not\n * satisfied.\n *\n * <span class=\"informal\">Takes values from the source only while they pass the\n * condition given. When the first value does not satisfy, it completes.</span>\n *\n * ![](takeWhile.png)\n *\n * `takeWhile` subscribes and begins mirroring the source Observable. Each value\n * emitted on the source is given to the `predicate` function which returns a\n * boolean, representing a condition to be satisfied by the source values. The\n * output Observable emits the source values until such time as the `predicate`\n * returns false, at which point `takeWhile` stops mirroring the source\n * Observable and completes the output Observable.\n *\n * ## Example\n *\n * Emit click events only while the clientX property is greater than 200\n *\n * ```ts\n * import { fromEvent, takeWhile } from 'rxjs';\n *\n * const clicks = fromEvent<PointerEvent>(document, 'click');\n * const result = clicks.pipe(takeWhile(ev => ev.clientX > 200));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link take}\n * @see {@link takeLast}\n * @see {@link takeUntil}\n * @see {@link skip}\n *\n * @param {function(value: T, index: number): boolean} predicate A function that\n * evaluates a value emitted by the source Observable and returns a boolean.\n * Also takes the (zero-based) index as the second argument.\n * @param {boolean} inclusive When set to `true` the value that caused\n * `predicate` to return `false` will also be emitted.\n * @return A function that returns an Observable that emits values from the\n * source Observable so long as each value satisfies the condition defined by\n * the `predicate`, then completes.\n */\nexport function takeWhile<T>(predicate: (value: T, index: number) => boolean, inclusive = false): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    let index = 0;\n    source.subscribe(\n      createOperatorSubscriber(subscriber, (value) => {\n        const result = predicate(value, index++);\n        (result || inclusive) && subscriber.next(value);\n        !result && subscriber.complete();\n      })\n    );\n  });\n}\n", "import { MonoTypeOperatorFunction, Observer } from '../types';\nimport { isFunction } from '../util/isFunction';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { identity } from '../util/identity';\n\n/**\n * An extension to the {@link Observer} interface used only by the {@link tap} operator.\n *\n * It provides a useful set of callbacks a user can register to do side-effects in\n * cases other than what the usual {@link Observer} callbacks are\n * ({@link guide/glossary-and-semantics#next next},\n * {@link guide/glossary-and-semantics#error error} and/or\n * {@link guide/glossary-and-semantics#complete complete}).\n *\n * ## Example\n *\n * ```ts\n * import { fromEvent, switchMap, tap, interval, take } from 'rxjs';\n *\n * const source$ = fromEvent(document, 'click');\n * const result$ = source$.pipe(\n *   switchMap((_, i) => i % 2 === 0\n *     ? fromEvent(document, 'mousemove').pipe(\n *         tap({\n *           subscribe: () => console.log('Subscribed to the mouse move events after click #' + i),\n *           unsubscribe: () => console.log('Mouse move events #' + i + ' unsubscribed'),\n *           finalize: () => console.log('Mouse move events #' + i + ' finalized')\n *         })\n *       )\n *     : interval(1_000).pipe(\n *         take(5),\n *         tap({\n *           subscribe: () => console.log('Subscribed to the 1-second interval events after click #' + i),\n *           unsubscribe: () => console.log('1-second interval events #' + i + ' unsubscribed'),\n *           finalize: () => console.log('1-second interval events #' + i + ' finalized')\n *         })\n *       )\n *   )\n * );\n *\n * const subscription = result$.subscribe({\n *   next: console.log\n * });\n *\n * setTimeout(() => {\n *   console.log('Unsubscribe after 60 seconds');\n *   subscription.unsubscribe();\n * }, 60_000);\n * ```\n */\nexport interface TapObserver<T> extends Observer<T> {\n  /**\n   * The callback that `tap` operator invokes at the moment when the source Observable\n   * gets subscribed to.\n   */\n  subscribe: () => void;\n  /**\n   * The callback that `tap` operator invokes when an explicit\n   * {@link guide/glossary-and-semantics#unsubscription unsubscribe} happens. It won't get invoked on\n   * `error` or `complete` events.\n   */\n  unsubscribe: () => void;\n  /**\n   * The callback that `tap` operator invokes when any kind of\n   * {@link guide/glossary-and-semantics#finalization finalization} happens - either when\n   * the source Observable `error`s or `complete`s or when it gets explicitly unsubscribed\n   * by the user. There is no difference in using this callback or the {@link finalize}\n   * operator, but if you're already using `tap` operator, you can use this callback\n   * instead. You'd get the same result in either case.\n   */\n  finalize: () => void;\n}\nexport function tap<T>(observerOrNext?: Partial<TapObserver<T>> | ((value: T) => void)): MonoTypeOperatorFunction<T>;\n/** @deprecated Instead of passing separate callback arguments, use an observer argument. Signatures taking separate callback arguments will be removed in v8. Details: https://rxjs.dev/deprecations/subscribe-arguments */\nexport function tap<T>(\n  next?: ((value: T) => void) | null,\n  error?: ((error: any) => void) | null,\n  complete?: (() => void) | null\n): MonoTypeOperatorFunction<T>;\n\n/**\n * Used to perform side-effects for notifications from the source observable\n *\n * <span class=\"informal\">Used when you want to affect outside state with a notification without altering the notification</span>\n *\n * ![](tap.png)\n *\n * Tap is designed to allow the developer a designated place to perform side effects. While you _could_ perform side-effects\n * inside of a `map` or a `mergeMap`, that would make their mapping functions impure, which isn't always a big deal, but will\n * make it so you can't do things like memoize those functions. The `tap` operator is designed solely for such side-effects to\n * help you remove side-effects from other operations.\n *\n * For any notification, next, error, or complete, `tap` will call the appropriate callback you have provided to it, via a function\n * reference, or a partial observer, then pass that notification down the stream.\n *\n * The observable returned by `tap` is an exact mirror of the source, with one exception: Any error that occurs -- synchronously -- in a handler\n * provided to `tap` will be emitted as an error from the returned observable.\n *\n * > Be careful! You can mutate objects as they pass through the `tap` operator's handlers.\n *\n * The most common use of `tap` is actually for debugging. You can place a `tap(console.log)` anywhere\n * in your observable `pipe`, log out the notifications as they are emitted by the source returned by the previous\n * operation.\n *\n * ## Examples\n *\n * Check a random number before it is handled. Below is an observable that will use a random number between 0 and 1,\n * and emit `'big'` or `'small'` depending on the size of that number. But we wanted to log what the original number\n * was, so we have added a `tap(console.log)`.\n *\n * ```ts\n * import { of, tap, map } from 'rxjs';\n *\n * of(Math.random()).pipe(\n *   tap(console.log),\n *   map(n => n > 0.5 ? 'big' : 'small')\n * ).subscribe(console.log);\n * ```\n *\n * Using `tap` to analyze a value and force an error. Below is an observable where in our system we only\n * want to emit numbers 3 or less we get from another source. We can force our observable to error\n * using `tap`.\n *\n * ```ts\n * import { of, tap } from 'rxjs';\n *\n * const source = of(1, 2, 3, 4, 5);\n *\n * source.pipe(\n *   tap(n => {\n *     if (n > 3) {\n *       throw new TypeError(`Value ${ n } is greater than 3`);\n *     }\n *   })\n * )\n * .subscribe({ next: console.log, error: err => console.log(err.message) });\n * ```\n *\n * We want to know when an observable completes before moving on to the next observable. The system\n * below will emit a random series of `'X'` characters from 3 different observables in sequence. The\n * only way we know when one observable completes and moves to the next one, in this case, is because\n * we have added a `tap` with the side effect of logging to console.\n *\n * ```ts\n * import { of, concatMap, interval, take, map, tap } from 'rxjs';\n *\n * of(1, 2, 3).pipe(\n *   concatMap(n => interval(1000).pipe(\n *     take(Math.round(Math.random() * 10)),\n *     map(() => 'X'),\n *     tap({ complete: () => console.log(`Done with ${ n }`) })\n *   ))\n * )\n * .subscribe(console.log);\n * ```\n *\n * @see {@link finalize}\n * @see {@link TapObserver}\n *\n * @param observerOrNext A next handler or partial observer\n * @param error An error handler\n * @param complete A completion handler\n * @return A function that returns an Observable identical to the source, but\n * runs the specified Observer or callback(s) for each item.\n */\nexport function tap<T>(\n  observerOrNext?: Partial<TapObserver<T>> | ((value: T) => void) | null,\n  error?: ((e: any) => void) | null,\n  complete?: (() => void) | null\n): MonoTypeOperatorFunction<T> {\n  // We have to check to see not only if next is a function,\n  // but if error or complete were passed. This is because someone\n  // could technically call tap like `tap(null, fn)` or `tap(null, null, fn)`.\n  const tapObserver =\n    isFunction(observerOrNext) || error || complete\n      ? // tslint:disable-next-line: no-object-literal-type-assertion\n        ({ next: observerOrNext as Exclude<typeof observerOrNext, Partial<TapObserver<T>>>, error, complete } as Partial<TapObserver<T>>)\n      : observerOrNext;\n\n  return tapObserver\n    ? operate((source, subscriber) => {\n        tapObserver.subscribe?.();\n        let isUnsub = true;\n        source.subscribe(\n          createOperatorSubscriber(\n            subscriber,\n            (value) => {\n              tapObserver.next?.(value);\n              subscriber.next(value);\n            },\n            () => {\n              isUnsub = false;\n              tapObserver.complete?.();\n              subscriber.complete();\n            },\n            (err) => {\n              isUnsub = false;\n              tapObserver.error?.(err);\n              subscriber.error(err);\n            },\n            () => {\n              if (isUnsub) {\n                tapObserver.unsubscribe?.();\n              }\n              tapObserver.finalize?.();\n            }\n          )\n        );\n      })\n    : // Tap was called with no valid tap observer or handler\n      // (e.g. `tap(null, null, null)` or `tap(null)` or `tap()`)\n      // so we're going to just mirror the source.\n      identity;\n}\n", "import { Subscription } from '../Subscription';\n\nimport { MonoTypeOperatorFunction, ObservableInput } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { innerFrom } from '../observable/innerFrom';\n\n/**\n * An object interface used by {@link throttle} or {@link throttleTime} that ensure\n * configuration options of these operators.\n *\n * @see {@link throttle}\n * @see {@link throttleTime}\n */\nexport interface ThrottleConfig {\n  /**\n   * If `true`, the resulting Observable will emit the first value from the source\n   * Observable at the **start** of the \"throttling\" process (when starting an\n   * internal timer that prevents other emissions from the source to pass through).\n   * If `false`, it will not emit the first value from the source Observable at the\n   * start of the \"throttling\" process.\n   *\n   * If not provided, defaults to: `true`.\n   */\n  leading?: boolean;\n  /**\n   * If `true`, the resulting Observable will emit the last value from the source\n   * Observable at the **end** of the \"throttling\" process (when ending an internal\n   * timer that prevents other emissions from the source to pass through).\n   * If `false`, it will not emit the last value from the source Observable at the\n   * end of the \"throttling\" process.\n   *\n   * If not provided, defaults to: `false`.\n   */\n  trailing?: boolean;\n}\n\n/**\n * Emits a value from the source Observable, then ignores subsequent source\n * values for a duration determined by another Observable, then repeats this\n * process.\n *\n * <span class=\"informal\">It's like {@link throttleTime}, but the silencing\n * duration is determined by a second Observable.</span>\n *\n * ![](throttle.svg)\n *\n * `throttle` emits the source Observable values on the output Observable\n * when its internal timer is disabled, and ignores source values when the timer\n * is enabled. Initially, the timer is disabled. As soon as the first source\n * value arrives, it is forwarded to the output Observable, and then the timer\n * is enabled by calling the `durationSelector` function with the source value,\n * which returns the \"duration\" Observable. When the duration Observable emits a\n * value, the timer is disabled, and this process repeats for the\n * next source value.\n *\n * ## Example\n *\n * Emit clicks at a rate of at most one click per second\n *\n * ```ts\n * import { fromEvent, throttle, interval } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(throttle(() => interval(1000)));\n *\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link audit}\n * @see {@link debounce}\n * @see {@link delayWhen}\n * @see {@link sample}\n * @see {@link throttleTime}\n *\n * @param durationSelector A function that receives a value from the source\n * Observable, for computing the silencing duration for each source value,\n * returned as an `ObservableInput`.\n * @param config A configuration object to define `leading` and `trailing`\n * behavior. Defaults to `{ leading: true, trailing: false }`.\n * @return A function that returns an Observable that performs the throttle\n * operation to limit the rate of emissions from the source.\n */\nexport function throttle<T>(durationSelector: (value: T) => ObservableInput<any>, config?: ThrottleConfig): MonoTypeOperatorFunction<T> {\n  return operate((source, subscriber) => {\n    const { leading = true, trailing = false } = config ?? {};\n    let hasValue = false;\n    let sendValue: T | null = null;\n    let throttled: Subscription | null = null;\n    let isComplete = false;\n\n    const endThrottling = () => {\n      throttled?.unsubscribe();\n      throttled = null;\n      if (trailing) {\n        send();\n        isComplete && subscriber.complete();\n      }\n    };\n\n    const cleanupThrottling = () => {\n      throttled = null;\n      isComplete && subscriber.complete();\n    };\n\n    const startThrottle = (value: T) =>\n      (throttled = innerFrom(durationSelector(value)).subscribe(createOperatorSubscriber(subscriber, endThrottling, cleanupThrottling)));\n\n    const send = () => {\n      if (hasValue) {\n        // Ensure we clear out our value and hasValue flag\n        // before we emit, otherwise reentrant code can cause\n        // issues here.\n        hasValue = false;\n        const value = sendValue!;\n        sendValue = null;\n        // Emit the value.\n        subscriber.next(value);\n        !isComplete && startThrottle(value);\n      }\n    };\n\n    source.subscribe(\n      createOperatorSubscriber(\n        subscriber,\n        // Regarding the presence of throttled.closed in the following\n        // conditions, if a synchronous duration selector is specified - weird,\n        // but legal - an already-closed subscription will be assigned to\n        // throttled, so the subscription's closed property needs to be checked,\n        // too.\n        (value) => {\n          hasValue = true;\n          sendValue = value;\n          !(throttled && !throttled.closed) && (leading ? send() : startThrottle(value));\n        },\n        () => {\n          isComplete = true;\n          !(trailing && hasValue && throttled && !throttled.closed) && subscriber.complete();\n        }\n      )\n    );\n  });\n}\n", "import { asyncScheduler } from '../scheduler/async';\nimport { throttle, ThrottleConfig } from './throttle';\nimport { MonoTypeOperatorFunction, SchedulerLike } from '../types';\nimport { timer } from '../observable/timer';\n\n/**\n * Emits a value from the source Observable, then ignores subsequent source\n * values for `duration` milliseconds, then repeats this process.\n *\n * <span class=\"informal\">Lets a value pass, then ignores source values for the\n * next `duration` milliseconds.</span>\n *\n * ![](throttleTime.png)\n *\n * `throttleTime` emits the source Observable values on the output Observable\n * when its internal timer is disabled, and ignores source values when the timer\n * is enabled. Initially, the timer is disabled. As soon as the first source\n * value arrives, it is forwarded to the output Observable, and then the timer\n * is enabled. After `duration` milliseconds (or the time unit determined\n * internally by the optional `scheduler`) has passed, the timer is disabled,\n * and this process repeats for the next source value. Optionally takes a\n * {@link SchedulerLike} for managing timers.\n *\n * ## Examples\n *\n * ### Limit click rate\n *\n * Emit clicks at a rate of at most one click per second\n *\n * ```ts\n * import { fromEvent, throttleTime } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const result = clicks.pipe(throttleTime(1000));\n *\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link auditTime}\n * @see {@link debounceTime}\n * @see {@link delay}\n * @see {@link sampleTime}\n * @see {@link throttle}\n *\n * @param duration Time to wait before emitting another value after\n * emitting the last value, measured in milliseconds or the time unit determined\n * internally by the optional `scheduler`.\n * @param scheduler The {@link SchedulerLike} to use for\n * managing the timers that handle the throttling. Defaults to {@link asyncScheduler}.\n * @param config A configuration object to define `leading` and\n * `trailing` behavior. Defaults to `{ leading: true, trailing: false }`.\n * @return A function that returns an Observable that performs the throttle\n * operation to limit the rate of emissions from the source.\n */\nexport function throttleTime<T>(\n  duration: number,\n  scheduler: SchedulerLike = asyncScheduler,\n  config?: ThrottleConfig\n): MonoTypeOperatorFunction<T> {\n  const duration$ = timer(duration, scheduler);\n  return throttle(() => duration$, config);\n}\n", "import { OperatorFunction, ObservableInputTuple } from '../types';\nimport { operate } from '../util/lift';\nimport { createOperatorSubscriber } from './OperatorSubscriber';\nimport { innerFrom } from '../observable/innerFrom';\nimport { identity } from '../util/identity';\nimport { noop } from '../util/noop';\nimport { popResultSelector } from '../util/args';\n\nexport function withLatestFrom<T, O extends unknown[]>(...inputs: [...ObservableInputTuple<O>]): OperatorFunction<T, [T, ...O]>;\n\nexport function withLatestFrom<T, O extends unknown[], R>(\n  ...inputs: [...ObservableInputTuple<O>, (...value: [T, ...O]) => R]\n): OperatorFunction<T, R>;\n\n/**\n * Combines the source Observable with other Observables to create an Observable\n * whose values are calculated from the latest values of each, only when the\n * source emits.\n *\n * <span class=\"informal\">Whenever the source Observable emits a value, it\n * computes a formula using that value plus the latest values from other input\n * Observables, then emits the output of that formula.</span>\n *\n * ![](withLatestFrom.png)\n *\n * `withLatestFrom` combines each value from the source Observable (the\n * instance) with the latest values from the other input Observables only when\n * the source emits a value, optionally using a `project` function to determine\n * the value to be emitted on the output Observable. All input Observables must\n * emit at least one value before the output Observable will emit a value.\n *\n * ## Example\n *\n * On every click event, emit an array with the latest timer event plus the click event\n *\n * ```ts\n * import { fromEvent, interval, withLatestFrom } from 'rxjs';\n *\n * const clicks = fromEvent(document, 'click');\n * const timer = interval(1000);\n * const result = clicks.pipe(withLatestFrom(timer));\n * result.subscribe(x => console.log(x));\n * ```\n *\n * @see {@link combineLatest}\n *\n * @param {ObservableInput} other An input Observable to combine with the source\n * Observable. More than one input Observables may be given as argument.\n * @param {Function} [project] Projection function for combining values\n * together. Receives all values in order of the Observables passed, where the\n * first parameter is a value from the source Observable. (e.g.\n * `a.pipe(withLatestFrom(b, c), map(([a1, b1, c1]) => a1 + b1 + c1))`). If this is not\n * passed, arrays will be emitted on the output Observable.\n * @return A function that returns an Observable of projected values from the\n * most recent values from each input Observable, or an array of the most\n * recent values from each input Observable.\n */\nexport function withLatestFrom<T, R>(...inputs: any[]): OperatorFunction<T, R | any[]> {\n  const project = popResultSelector(inputs) as ((...args: any[]) => R) | undefined;\n\n  return operate((source, subscriber) => {\n    const len = inputs.length;\n    const otherValues = new Array(len);\n    // An array of whether or not the other sources have emitted. Matched with them by index.\n    // TODO: At somepoint, we should investigate the performance implications here, and look\n    // into using a `Set()` and checking the `size` to see if we're ready.\n    let hasValue = inputs.map(() => false);\n    // Flipped true when we have at least one value from all other sources and\n    // we are ready to start emitting values.\n    let ready = false;\n\n    // Other sources. Note that here we are not checking `subscriber.closed`,\n    // this causes all inputs to be subscribed to, even if nothing can be emitted\n    // from them. This is an important distinction because subscription constitutes\n    // a side-effect.\n    for (let i = 0; i < len; i++) {\n      innerFrom(inputs[i]).subscribe(\n        createOperatorSubscriber(\n          subscriber,\n          (value) => {\n            otherValues[i] = value;\n            if (!ready && !hasValue[i]) {\n              // If we're not ready yet, flag to show this observable has emitted.\n              hasValue[i] = true;\n              // Intentionally terse code.\n              // If all of our other observables have emitted, set `ready` to `true`,\n              // so we know we can start emitting values, then clean up the `hasValue` array,\n              // because we don't need it anymore.\n              (ready = hasValue.every(identity)) && (hasValue = null!);\n            }\n          },\n          // Completing one of the other sources has\n          // no bearing on the completion of our result.\n          noop\n        )\n      );\n    }\n\n    // Source subscription\n    source.subscribe(\n      createOperatorSubscriber(subscriber, (value) => {\n        if (ready) {\n          // We have at least one value from the other sources. Go ahead and emit.\n          const values = [value, ...otherValues];\n          subscriber.next(project ? project(...values) : values);\n        }\n      })\n    );\n  });\n}\n", "import { zip as zipStatic } from '../observable/zip';\nimport { ObservableInput, ObservableInputTuple, OperatorFunction, Cons } from '../types';\nimport { operate } from '../util/lift';\n\n/** @deprecated Replaced with {@link zipWith}. Will be removed in v8. */\nexport function zip<T, A extends readonly unknown[]>(otherInputs: [...ObservableInputTuple<A>]): OperatorFunction<T, Cons<T, A>>;\n/** @deprecated Replaced with {@link zipWith}. Will be removed in v8. */\nexport function zip<T, A extends readonly unknown[], R>(\n  otherInputsAndProject: [...ObservableInputTuple<A>],\n  project: (...values: Cons<T, A>) => R\n): OperatorFunction<T, R>;\n/** @deprecated Replaced with {@link zipWith}. Will be removed in v8. */\nexport function zip<T, A extends readonly unknown[]>(...otherInputs: [...ObservableInputTuple<A>]): OperatorFunction<T, Cons<T, A>>;\n/** @deprecated Replaced with {@link zipWith}. Will be removed in v8. */\nexport function zip<T, A extends readonly unknown[], R>(\n  ...otherInputsAndProject: [...ObservableInputTuple<A>, (...values: Cons<T, A>) => R]\n): OperatorFunction<T, R>;\n\n/**\n * @deprecated Replaced with {@link zipWith}. Will be removed in v8.\n */\nexport function zip<T, R>(...sources: Array<ObservableInput<any> | ((...values: Array<any>) => R)>): OperatorFunction<T, any> {\n  return operate((source, subscriber) => {\n    zipStatic(source as ObservableInput<any>, ...(sources as Array<ObservableInput<any>>)).subscribe(subscriber);\n  });\n}\n", "import { ObservableInputTuple, OperatorFunction, Cons } from '../types';\nimport { zip } from './zip';\n\n/**\n * Subscribes to the source, and the observable inputs provided as arguments, and combines their values, by index, into arrays.\n *\n * What is meant by \"combine by index\": The first value from each will be made into a single array, then emitted,\n * then the second value from each will be combined into a single array and emitted, then the third value\n * from each will be combined into a single array and emitted, and so on.\n *\n * This will continue until it is no longer able to combine values of the same index into an array.\n *\n * After the last value from any one completed source is emitted in an array, the resulting observable will complete,\n * as there is no way to continue \"zipping\" values together by index.\n *\n * Use-cases for this operator are limited. There are memory concerns if one of the streams is emitting\n * values at a much faster rate than the others. Usage should likely be limited to streams that emit\n * at a similar pace, or finite streams of known length.\n *\n * In many cases, authors want `combineLatestWith` and not `zipWith`.\n *\n * @param otherInputs other observable inputs to collate values from.\n * @return A function that returns an Observable that emits items by index\n * combined from the source Observable and provided Observables, in form of an\n * array.\n */\nexport function zipWith<T, A extends readonly unknown[]>(...otherInputs: [...ObservableInputTuple<A>]): OperatorFunction<T, Cons<T, A>> {\n  return zip(...otherInputs);\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  ReplaySubject,\n  Subject,\n  fromEvent\n} from \"rxjs\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch document\n *\n * Documents are implemented as subjects, so all downstream observables are\n * automatically updated when a new document is emitted.\n *\n * @returns Document subject\n */\nexport function watchDocument(): Subject<Document> {\n  const document$ = new ReplaySubject<Document>(1)\n  fromEvent(document, \"DOMContentLoaded\", { once: true })\n    .subscribe(() => document$.next(document))\n\n  /* Return document */\n  return document$\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve all elements matching the query selector\n *\n * @template T - Element type\n *\n * @param selector - Query selector\n * @param node - Node of reference\n *\n * @returns Elements\n */\nexport function getElements<T extends keyof HTMLElementTagNameMap>(\n  selector: T, node?: ParentNode\n): HTMLElementTagNameMap[T][]\n\nexport function getElements<T extends HTMLElement>(\n  selector: string, node?: ParentNode\n): T[]\n\nexport function getElements<T extends HTMLElement>(\n  selector: string, node: ParentNode = document\n): T[] {\n  return Array.from(node.querySelectorAll<T>(selector))\n}\n\n/**\n * Retrieve an element matching a query selector or throw a reference error\n *\n * Note that this function assumes that the element is present. If unsure if an\n * element is existent, use the `getOptionalElement` function instead.\n *\n * @template T - Element type\n *\n * @param selector - Query selector\n * @param node - Node of reference\n *\n * @returns Element\n */\nexport function getElement<T extends keyof HTMLElementTagNameMap>(\n  selector: T, node?: ParentNode\n): HTMLElementTagNameMap[T]\n\nexport function getElement<T extends HTMLElement>(\n  selector: string, node?: ParentNode\n): T\n\nexport function getElement<T extends HTMLElement>(\n  selector: string, node: ParentNode = document\n): T {\n  const el = getOptionalElement<T>(selector, node)\n  if (typeof el === \"undefined\")\n    throw new ReferenceError(\n      `Missing element: expected \"${selector}\" to be present`\n    )\n\n  /* Return element */\n  return el\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Retrieve an optional element matching the query selector\n *\n * @template T - Element type\n *\n * @param selector - Query selector\n * @param node - Node of reference\n *\n * @returns Element or nothing\n */\nexport function getOptionalElement<T extends keyof HTMLElementTagNameMap>(\n  selector: T, node?: ParentNode\n): HTMLElementTagNameMap[T] | undefined\n\nexport function getOptionalElement<T extends HTMLElement>(\n  selector: string, node?: ParentNode\n): T | undefined\n\nexport function getOptionalElement<T extends HTMLElement>(\n  selector: string, node: ParentNode = document\n): T | undefined {\n  return node.querySelector<T>(selector) || undefined\n}\n\n/**\n * Retrieve the currently active element\n *\n * @returns Element or nothing\n */\nexport function getActiveElement(): HTMLElement | undefined {\n  return (\n    document.activeElement?.shadowRoot?.activeElement as HTMLElement ??\n    document.activeElement as HTMLElement ??\n    undefined\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  debounceTime,\n  distinctUntilChanged,\n  fromEvent,\n  map,\n  merge,\n  shareReplay,\n  startWith\n} from \"rxjs\"\n\nimport { getActiveElement } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Focus observable\n *\n * Previously, this observer used `focus` and `blur` events to determine whether\n * an element is focused, but this doesn't work if there are focusable elements\n * within the elements itself. A better solutions are `focusin` and `focusout`\n * events, which bubble up the tree and allow for more fine-grained control.\n *\n * `debounceTime` is necessary, because when a focus change happens inside an\n * element, the observable would first emit `false` and then `true` again.\n */\nconst observer$ = merge(\n  fromEvent(document.body, \"focusin\"),\n  fromEvent(document.body, \"focusout\")\n)\n  .pipe(\n    debounceTime(1),\n    startWith(undefined),\n    map(() => getActiveElement() || document.body),\n    shareReplay(1)\n  )\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch element focus\n *\n * @param el - Element\n *\n * @returns Element focus observable\n */\nexport function watchElementFocus(\n  el: HTMLElement\n): Observable<boolean> {\n  return observer$\n    .pipe(\n      map(active => el.contains(active)),\n      distinctUntilChanged()\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  debounce,\n  defer,\n  fromEvent,\n  identity,\n  map,\n  merge,\n  startWith,\n  timer\n} from \"rxjs\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch element hover\n *\n * The second parameter allows to specify a timeout in milliseconds after which\n * the hover state will be reset to `false`. This is useful for tooltips which\n * should disappear after a certain amount of time, in order to allow the user\n * to move the cursor from the host to the tooltip.\n *\n * @param el - Element\n * @param timeout - Timeout\n *\n * @returns Element hover observable\n */\nexport function watchElementHover(\n  el: HTMLElement, timeout?: number\n): Observable<boolean> {\n  return defer(() => merge(\n    fromEvent(el, \"mouseenter\").pipe(map(() => true)),\n    fromEvent(el, \"mouseleave\").pipe(map(() => false))\n  )\n    .pipe(\n      timeout ? debounce(active => timer(+!active * timeout)) : identity,\n      startWith(el.matches(\":hover\"))\n    )\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { JSX as JSXInternal } from \"preact\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * HTML attributes\n */\ntype Attributes =\n  & JSXInternal.HTMLAttributes\n  & JSXInternal.SVGAttributes\n  & Record<string, any>\n\n/**\n * Child element\n */\ntype Child =\n  | ChildNode\n  | HTMLElement\n  | Text\n  | string\n  | number\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Append a child node to an element\n *\n * @param el - Element\n * @param child - Child node(s)\n */\nfunction appendChild(el: HTMLElement, child: Child | Child[]): void {\n\n  /* Handle primitive types (including raw HTML) */\n  if (typeof child === \"string\" || typeof child === \"number\") {\n    el.innerHTML += child.toString()\n\n  /* Handle nodes */\n  } else if (child instanceof Node) {\n    el.appendChild(child)\n\n  /* Handle nested children */\n  } else if (Array.isArray(child)) {\n    for (const node of child)\n      appendChild(el, node)\n  }\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * JSX factory\n *\n * @template T - Element type\n *\n * @param tag - HTML tag\n * @param attributes - HTML attributes\n * @param children - Child elements\n *\n * @returns Element\n */\nexport function h<T extends keyof HTMLElementTagNameMap>(\n  tag: T, attributes?: Attributes | null, ...children: Child[]\n): HTMLElementTagNameMap[T]\n\nexport function h<T extends h.JSX.Element>(\n  tag: string, attributes?: Attributes | null, ...children: Child[]\n): T\n\nexport function h<T extends h.JSX.Element>(\n  tag: string, attributes?: Attributes | null, ...children: Child[]\n): T {\n  const el = document.createElement(tag)\n\n  /* Set attributes, if any */\n  if (attributes)\n    for (const attr of Object.keys(attributes)) {\n      if (typeof attributes[attr] === \"undefined\")\n        continue\n\n      /* Set default attribute or boolean */\n      if (typeof attributes[attr] !== \"boolean\")\n        el.setAttribute(attr, attributes[attr])\n      else\n        el.setAttribute(attr, \"\")\n    }\n\n  /* Append child nodes */\n  for (const child of children)\n    appendChild(el, child)\n\n  /* Return element */\n  return el as T\n}\n\n/* ----------------------------------------------------------------------------\n * Namespace\n * ------------------------------------------------------------------------- */\n\nexport declare namespace h {\n  namespace JSX {\n    type Element = HTMLElement\n    type IntrinsicElements = JSXInternal.IntrinsicElements\n  }\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Round a number for display with repository facts\n *\n * This is a reverse-engineered version of GitHub's weird rounding algorithm\n * for stars, forks and all other numbers. While all numbers below `1,000` are\n * returned as-is, bigger numbers are converted to fixed numbers:\n *\n * - `1,049` => `1k`\n * - `1,050` => `1.1k`\n * - `1,949` => `1.9k`\n * - `1,950` => `2k`\n *\n * @param value - Original value\n *\n * @returns Rounded value\n */\nexport function round(value: number): string {\n  if (value > 999) {\n    const digits = +((value - 950) % 1000 > 99)\n    return `${((value + 0.000001) / 1000).toFixed(digits)}k`\n  } else {\n    return value.toString()\n  }\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  defer,\n  finalize,\n  fromEvent,\n  map,\n  merge,\n  switchMap,\n  take,\n  throwError\n} from \"rxjs\"\n\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Create and load a `script` element\n *\n * This function returns an observable that will emit when the script was\n * successfully loaded, or throw an error if it wasn't.\n *\n * @param src - Script URL\n *\n * @returns Script observable\n */\nexport function watchScript(src: string): Observable<void> {\n  const script = h(\"script\", { src })\n  return defer(() => {\n    document.head.appendChild(script)\n    return merge(\n      fromEvent(script, \"load\"),\n      fromEvent(script, \"error\")\n        .pipe(\n          switchMap(() => (\n            throwError(() => new ReferenceError(`Invalid script: ${src}`))\n          ))\n        )\n    )\n      .pipe(\n        map(() => undefined),\n        finalize(() => document.head.removeChild(script)),\n        take(1)\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  NEVER,\n  Observable,\n  Subject,\n  defer,\n  filter,\n  finalize,\n  map,\n  merge,\n  of,\n  shareReplay,\n  startWith,\n  switchMap,\n  tap\n} from \"rxjs\"\n\nimport { watchScript } from \"../../../script\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Element offset\n */\nexport interface ElementSize {\n  width: number                        /* Element width */\n  height: number                       /* Element height */\n}\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Resize observer entry subject\n */\nconst entry$ = new Subject<ResizeObserverEntry>()\n\n/**\n * Resize observer observable\n *\n * This observable will create a `ResizeObserver` on the first subscription\n * and will automatically terminate it when there are no more subscribers.\n * It's quite important to centralize observation in a single `ResizeObserver`,\n * as the performance difference can be quite dramatic, as the link shows.\n *\n * If the browser doesn't have a `ResizeObserver` implementation available, a\n * polyfill is automatically downloaded from unpkg.com. This is also compatible\n * with the built-in privacy plugin, which will download the polyfill and put\n * it alongside the built site for self-hosting.\n *\n * @see https://bit.ly/3iIYfEm - Google Groups on performance\n */\nconst observer$ = defer(() => (\n  typeof ResizeObserver === \"undefined\"\n    ? watchScript(\"https://unpkg.com/resize-observer-polyfill\")\n    : of(undefined)\n))\n  .pipe(\n    map(() => new ResizeObserver(entries => (\n      entries.forEach(entry => entry$.next(entry))\n    ))),\n    switchMap(observer => merge(NEVER, of(observer)).pipe(\n      finalize(() => observer.disconnect())\n    )),\n    shareReplay(1)\n  )\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve element size\n *\n * @param el - Element\n *\n * @returns Element size\n */\nexport function getElementSize(\n  el: HTMLElement\n): ElementSize {\n  return {\n    width:  el.offsetWidth,\n    height: el.offsetHeight\n  }\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Watch element size\n *\n * This function returns an observable that subscribes to a single internal\n * instance of `ResizeObserver` upon subscription, and emit resize events until\n * termination. Note that this function should not be called with the same\n * element twice, as the first unsubscription will terminate observation.\n *\n * Sadly, we can't use the `DOMRect` objects returned by the observer, because\n * we need the emitted values to be consistent with `getElementSize`, which will\n * return the used values (rounded) and not actual values (unrounded). Thus, we\n * use the `offset*` properties. See the linked GitHub issue.\n *\n * @see https://bit.ly/3m0k3he - GitHub issue\n *\n * @param el - Element\n *\n * @returns Element size observable\n */\nexport function watchElementSize(\n  el: HTMLElement\n): Observable<ElementSize> {\n\n  // Compute target element - since inline elements cannot be observed by the\n  // current `ResizeObserver` implementation as provided by browsers, we need\n  // to determine the first containing parent element and use that one as a\n  // target, while we always compute the actual size from the element.\n  let target = el\n  while (target.clientWidth === 0)\n    if (target.parentElement)\n      target = target.parentElement\n    else\n      break\n\n  // Observe target element and recompute element size on resize - as described\n  // above, the target element is not necessarily the element of interest\n  return observer$.pipe(\n    tap(observer => observer.observe(target)),\n    switchMap(observer => entry$.pipe(\n      filter(entry => entry.target === target),\n      finalize(() => observer.unobserve(target))\n    )),\n    map(() => getElementSize(el)),\n    startWith(getElementSize(el))\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { ElementSize } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve element content size (= scroll width and height)\n *\n * @param el - Element\n *\n * @returns Element content size\n */\nexport function getElementContentSize(\n  el: HTMLElement\n): ElementSize {\n  return {\n    width:  el.scrollWidth,\n    height: el.scrollHeight\n  }\n}\n\n/**\n * Retrieve the overflowing container of an element, if any\n *\n * @param el - Element\n *\n * @returns Overflowing container or nothing\n */\nexport function getElementContainer(\n  el: HTMLElement\n): HTMLElement | undefined {\n  let parent = el.parentElement\n  while (parent)\n    if (\n      el.scrollWidth  <= parent.scrollWidth &&\n      el.scrollHeight <= parent.scrollHeight\n    )\n      parent = (el = parent).parentElement\n    else\n      break\n\n  /* Return overflowing container */\n  return parent ? el : undefined\n}\n\n/**\n * Retrieve all overflowing containers of an element, if any\n *\n * Note that this function has a slightly different behavior, so we should at\n * some point consider refactoring how overflowing containers are handled.\n *\n * @param el - Element\n *\n * @returns Overflowing containers\n */\nexport function getElementContainers(\n  el: HTMLElement\n): HTMLElement[] {\n  const containers: HTMLElement[] = []\n\n  // Walk up the DOM tree until we find an overflowing container\n  let parent = el.parentElement\n  while (parent) {\n    if (\n      el.clientWidth  > parent.clientWidth ||\n      el.clientHeight > parent.clientHeight\n    )\n      containers.push(parent)\n\n    // Continue with parent element\n    parent = (el = parent).parentElement\n  }\n\n  // If the page is short, the body might not be overflowing and there might be\n  // no other containers, which is why we need to make sure the body is present\n  if (containers.length === 0)\n    containers.push(document.documentElement)\n\n  // Return overflowing containers\n  return containers\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  animationFrameScheduler,\n  auditTime,\n  fromEvent,\n  map,\n  merge,\n  startWith\n} from \"rxjs\"\n\nimport { watchElementSize } from \"../../size\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Element offset\n */\nexport interface ElementOffset {\n  x: number                            /* Horizontal offset */\n  y: number                            /* Vertical offset */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve element offset\n *\n * @param el - Element\n *\n * @returns Element offset\n */\nexport function getElementOffset(\n  el: HTMLElement\n): ElementOffset {\n  return {\n    x: el.offsetLeft,\n    y: el.offsetTop\n  }\n}\n\n/**\n * Retrieve absolute element offset\n *\n * @param el - Element\n *\n * @returns Element offset\n */\nexport function getElementOffsetAbsolute(\n  el: HTMLElement\n): ElementOffset {\n  const rect = el.getBoundingClientRect()\n  return {\n    x: rect.x + window.scrollX,\n    y: rect.y + window.scrollY\n  }\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Watch element offset\n *\n * @param el - Element\n *\n * @returns Element offset observable\n */\nexport function watchElementOffset(\n  el: HTMLElement\n): Observable<ElementOffset> {\n  return merge(\n    fromEvent(window, \"load\"),\n    fromEvent(window, \"resize\")\n  )\n    .pipe(\n      auditTime(0, animationFrameScheduler),\n      map(() => getElementOffset(el)),\n      startWith(getElementOffset(el))\n    )\n}\n\n/**\n * Watch absolute element offset\n *\n * @param el - Element\n *\n * @returns Element offset observable\n */\nexport function watchElementOffsetAbsolute(\n  el: HTMLElement\n): Observable<ElementOffset> {\n  return merge(\n    watchElementOffset(el),\n    watchElementSize(document.body) // @todo find a better way for this\n  )\n    .pipe(\n      map(() => getElementOffsetAbsolute(el)),\n      startWith(getElementOffsetAbsolute(el))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  animationFrameScheduler,\n  auditTime,\n  fromEvent,\n  map,\n  merge,\n  startWith\n} from \"rxjs\"\n\nimport { ElementOffset } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve element content offset (= scroll offset)\n *\n * @param el - Element\n *\n * @returns Element content offset\n */\nexport function getElementContentOffset(\n  el: HTMLElement\n): ElementOffset {\n  return {\n    x: el.scrollLeft,\n    y: el.scrollTop\n  }\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Watch element content offset\n *\n * @param el - Element\n *\n * @returns Element content offset observable\n */\nexport function watchElementContentOffset(\n  el: HTMLElement\n): Observable<ElementOffset> {\n  return merge(\n    fromEvent(el, \"scroll\"),\n    fromEvent(window, \"scroll\"),\n    fromEvent(window, \"resize\")\n  )\n    .pipe(\n      auditTime(0, animationFrameScheduler),\n      map(() => getElementContentOffset(el)),\n      startWith(getElementContentOffset(el))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  NEVER,\n  Observable,\n  Subject,\n  defer,\n  distinctUntilChanged,\n  filter,\n  finalize,\n  map,\n  merge,\n  of,\n  shareReplay,\n  switchMap,\n  tap\n} from \"rxjs\"\n\nimport {\n  getElementContentSize,\n  getElementSize,\n  watchElementContentOffset\n} from \"~/browser\"\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Intersection observer entry subject\n */\nconst entry$ = new Subject<IntersectionObserverEntry>()\n\n/**\n * Intersection observer observable\n *\n * This observable will create an `IntersectionObserver` on first subscription\n * and will automatically terminate it when there are no more subscribers.\n *\n * @see https://bit.ly/3iIYfEm - Google Groups on performance\n */\nconst observer$ = defer(() => of(\n  new IntersectionObserver(entries => {\n    for (const entry of entries)\n      entry$.next(entry)\n  }, {\n    threshold: 0\n  })\n))\n  .pipe(\n    switchMap(observer => merge(NEVER, of(observer))\n      .pipe(\n        finalize(() => observer.disconnect())\n      )\n    ),\n    shareReplay(1)\n  )\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch element visibility\n *\n * @param el - Element\n *\n * @returns Element visibility observable\n */\nexport function watchElementVisibility(\n  el: HTMLElement\n): Observable<boolean> {\n  return observer$\n    .pipe(\n      tap(observer => observer.observe(el)),\n      switchMap(observer => entry$\n        .pipe(\n          filter(({ target }) => target === el),\n          finalize(() => observer.unobserve(el)),\n          map(({ isIntersecting }) => isIntersecting)\n        )\n      )\n    )\n}\n\n/**\n * Watch element boundary\n *\n * This function returns an observable which emits whether the bottom content\n * boundary (= scroll offset) of an element is within a certain threshold.\n *\n * @param el - Element\n * @param threshold - Threshold\n *\n * @returns Element boundary observable\n */\nexport function watchElementBoundary(\n  el: HTMLElement, threshold = 16\n): Observable<boolean> {\n  return watchElementContentOffset(el)\n    .pipe(\n      map(({ y }) => {\n        const visible = getElementSize(el)\n        const content = getElementContentSize(el)\n        return y >= (\n          content.height - visible.height - threshold\n        )\n      }),\n      distinctUntilChanged()\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  fromEvent,\n  map,\n  startWith\n} from \"rxjs\"\n\nimport { getElement } from \"../element\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Toggle\n */\nexport type Toggle =\n  | \"drawer\"                           /* Toggle for drawer */\n  | \"search\"                           /* Toggle for search */\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Toggle map\n */\nconst toggles: Record<Toggle, HTMLInputElement> = {\n  drawer: getElement(\"[data-md-toggle=drawer]\"),\n  search: getElement(\"[data-md-toggle=search]\")\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve the value of a toggle\n *\n * @param name - Toggle\n *\n * @returns Toggle value\n */\nexport function getToggle(name: Toggle): boolean {\n  return toggles[name].checked\n}\n\n/**\n * Set toggle\n *\n * Simulating a click event seems to be the most cross-browser compatible way\n * of changing the value while also emitting a `change` event. Before, Material\n * used `CustomEvent` to programmatically change the value of a toggle, but this\n * is a much simpler and cleaner solution which doesn't require a polyfill.\n *\n * @param name - Toggle\n * @param value - Toggle value\n */\nexport function setToggle(name: Toggle, value: boolean): void {\n  if (toggles[name].checked !== value)\n    toggles[name].click()\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Watch toggle\n *\n * @param name - Toggle\n *\n * @returns Toggle value observable\n */\nexport function watchToggle(name: Toggle): Observable<boolean> {\n  const el = toggles[name]\n  return fromEvent(el, \"change\")\n    .pipe(\n      map(() => el.checked),\n      startWith(el.checked)\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  filter,\n  fromEvent,\n  map,\n  merge,\n  share,\n  startWith,\n  switchMap\n} from \"rxjs\"\n\nimport { getActiveElement } from \"../element\"\nimport { getToggle } from \"../toggle\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Keyboard mode\n */\nexport type KeyboardMode =\n  | \"global\"                           /* Global */\n  | \"search\"                           /* Search is open */\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Keyboard\n */\nexport interface Keyboard {\n  mode: KeyboardMode                   /* Keyboard mode */\n  type: string                         /* Key type */\n  claim(): void                        /* Key claim */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Check whether an element may receive keyboard input\n *\n * @param el - Element\n * @param type - Key type\n *\n * @returns Test result\n */\nfunction isSusceptibleToKeyboard(\n  el: HTMLElement, type: string\n): boolean {\n  switch (el.constructor) {\n\n    /* Input elements */\n    case HTMLInputElement:\n      /* @ts-expect-error - omit unnecessary type cast */\n      if (el.type === \"radio\")\n        return /^Arrow/.test(type)\n      else\n        return true\n\n    /* Select element and textarea */\n    case HTMLSelectElement:\n    case HTMLTextAreaElement:\n      return true\n\n    /* Everything else */\n    default:\n      return el.isContentEditable\n  }\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch composition events\n *\n * @returns Composition observable\n */\nexport function watchComposition(): Observable<boolean> {\n  return merge(\n    fromEvent(window, \"compositionstart\").pipe(map(() => true)),\n    fromEvent(window, \"compositionend\").pipe(map(() => false))\n  )\n    .pipe(\n      startWith(false)\n    )\n}\n\n/**\n * Watch keyboard\n *\n * @returns Keyboard observable\n */\nexport function watchKeyboard(): Observable<Keyboard> {\n  const keyboard$ = fromEvent<KeyboardEvent>(window, \"keydown\")\n    .pipe(\n      filter(ev => !(ev.metaKey || ev.ctrlKey)),\n      map(ev => ({\n        mode: getToggle(\"search\") ? \"search\" : \"global\",\n        type: ev.key,\n        claim() {\n          ev.preventDefault()\n          ev.stopPropagation()\n        }\n      } as Keyboard)),\n      filter(({ mode, type }) => {\n        if (mode === \"global\") {\n          const active = getActiveElement()\n          if (typeof active !== \"undefined\")\n            return !isSusceptibleToKeyboard(active, type)\n        }\n        return true\n      }),\n      share()\n    )\n\n  /* Don't emit during composition events - see https://bit.ly/3te3Wl8 */\n  return watchComposition()\n    .pipe(\n      switchMap(active => !active ? keyboard$ : EMPTY)\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { Subject } from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve location\n *\n * This function returns a `URL` object (and not `Location`) to normalize the\n * typings across the application. Furthermore, locations need to be tracked\n * without setting them and `Location` is a singleton which represents the\n * current location.\n *\n * @returns URL\n */\nexport function getLocation(): URL {\n  return new URL(location.href)\n}\n\n/**\n * Set location\n *\n * If instant navigation is enabled, this function creates a temporary anchor\n * element, sets the `href` attribute, appends it to the body, clicks it, and\n * then removes it again. The event will bubble up the DOM and trigger be\n * intercepted by the instant loading business logic.\n *\n * Note that we must append and remove the anchor element, or the event will\n * not bubble up the DOM, making it impossible to intercept it.\n *\n * @param url - URL to navigate to\n * @param navigate - Force navigation\n */\nexport function setLocation(\n  url: URL | HTMLLinkElement, navigate = false\n): void {\n  if (feature(\"navigation.instant\") && !navigate) {\n    const el = h(\"a\", { href: url.href })\n    document.body.appendChild(el)\n    el.click()\n    el.remove()\n\n  // If we're not using instant navigation, and the page should not be reloaded\n  // just instruct the browser to navigate to the given URL\n  } else {\n    location.href = url.href\n  }\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Watch location\n *\n * @returns Location subject\n */\nexport function watchLocation(): Subject<URL> {\n  return new Subject<URL>()\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  filter,\n  fromEvent,\n  map,\n  merge,\n  shareReplay,\n  startWith\n} from \"rxjs\"\n\nimport { getOptionalElement } from \"~/browser\"\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve location hash\n *\n * @returns Location hash\n */\nexport function getLocationHash(): string {\n  return location.hash.slice(1)\n}\n\n/**\n * Set location hash\n *\n * Setting a new fragment identifier via `location.hash` will have no effect\n * if the value doesn't change. When a new fragment identifier is set, we want\n * the browser to target the respective element at all times, which is why we\n * use this dirty little trick.\n *\n * @param hash - Location hash\n */\nexport function setLocationHash(hash: string): void {\n  const el = h(\"a\", { href: hash })\n  el.addEventListener(\"click\", ev => ev.stopPropagation())\n  el.click()\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Watch location hash\n *\n * @param location$ - Location observable\n *\n * @returns Location hash observable\n */\nexport function watchLocationHash(\n  location$: Observable<URL>\n): Observable<string> {\n  return merge(\n    fromEvent<HashChangeEvent>(window, \"hashchange\"),\n    location$\n  )\n    .pipe(\n      map(getLocationHash),\n      startWith(getLocationHash()),\n      filter(hash => hash.length > 0),\n      shareReplay(1)\n    )\n}\n\n/**\n * Watch location target\n *\n * @param location$ - Location observable\n *\n * @returns Location target observable\n */\nexport function watchLocationTarget(\n  location$: Observable<URL>\n): Observable<HTMLElement> {\n  return watchLocationHash(location$)\n    .pipe(\n      map(id => getOptionalElement(`[id=\"${id}\"]`)!),\n      filter(el => typeof el !== \"undefined\")\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  fromEvent,\n  fromEventPattern,\n  map,\n  merge,\n  startWith,\n  switchMap\n} from \"rxjs\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch media query\n *\n * Note that although `MediaQueryList.addListener` is deprecated we have to\n * use it, because it's the only way to ensure proper downward compatibility.\n *\n * @see https://bit.ly/3dUBH2m - GitHub issue\n *\n * @param query - Media query\n *\n * @returns Media observable\n */\nexport function watchMedia(query: string): Observable<boolean> {\n  const media = matchMedia(query)\n  return fromEventPattern<boolean>(next => (\n    media.addListener(() => next(media.matches))\n  ))\n    .pipe(\n      startWith(media.matches)\n    )\n}\n\n/**\n * Watch print mode\n *\n * @returns Print observable\n */\nexport function watchPrint(): Observable<boolean> {\n  const media = matchMedia(\"print\")\n  return merge(\n    fromEvent(window, \"beforeprint\").pipe(map(() => true)),\n    fromEvent(window, \"afterprint\").pipe(map(() => false))\n  )\n    .pipe(\n      startWith(media.matches)\n    )\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Toggle an observable with a media observable\n *\n * @template T - Data type\n *\n * @param query$ - Media observable\n * @param factory - Observable factory\n *\n * @returns Toggled observable\n */\nexport function at<T>(\n  query$: Observable<boolean>, factory: () => Observable<T>\n): Observable<T> {\n  return query$\n    .pipe(\n      switchMap(active => active ? factory() : EMPTY)\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  map,\n  shareReplay,\n  switchMap\n} from \"rxjs\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Options\n */\ninterface Options {\n  progress$?: Subject<number>          // Progress subject\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Fetch the given URL\n *\n * This function returns an observable that emits the response as a blob and\n * completes, or emits an error if the request failed. The caller can cancel\n * the request by unsubscribing at any time, which will automatically abort\n * the inflight request and complete the observable.\n *\n * Note that we use `XMLHTTPRequest` not because we're nostalgic, but because\n * it's the only way to get progress events for downloads and also allow for\n * cancellation of requests, as the official Fetch API does not support this\n * yet, even though we're already in 2024.\n *\n * @param url - Request URL\n * @param options - Options\n *\n * @returns Data observable\n */\nexport function request(\n  url: URL | string, options?: Options\n): Observable<Blob> {\n  return new Observable<Blob>(observer => {\n    const req = new XMLHttpRequest()\n    req.open(\"GET\", `${url}`)\n    req.responseType = \"blob\"\n\n    // Handle response\n    req.addEventListener(\"load\", () => {\n      if (req.status >= 200 && req.status < 300) {\n        observer.next(req.response)\n        observer.complete()\n\n      // Every response that is not in the 2xx range is considered an error\n      } else {\n        observer.error(new Error(req.statusText))\n      }\n    })\n\n    // Handle network errors\n    req.addEventListener(\"error\", () => {\n      observer.error(new Error(\"Network error\"))\n    })\n\n    // Handle aborted requests\n    req.addEventListener(\"abort\", () => {\n      observer.complete()\n    })\n\n    // Handle download progress\n    if (typeof options?.progress$ !== \"undefined\") {\n      req.addEventListener(\"progress\", event => {\n        if (event.lengthComputable) {\n          options.progress$!.next((event.loaded / event.total) * 100)\n\n        // Hack: Chromium doesn't report the total number of bytes if content\n        // is compressed, so we need this fallback - see https://t.ly/ZXofI\n        } else {\n          const length = req.getResponseHeader(\"Content-Length\") ?? 0\n          options.progress$!.next((event.loaded / +length) * 100)\n        }\n      })\n\n      // Immediately set progress to 5% to indicate that we're loading\n      options.progress$.next(5)\n    }\n\n    // Send request and automatically abort request upon unsubscription\n    req.send()\n    return () => req.abort()\n  })\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Fetch JSON from the given URL\n *\n * @template T - Data type\n *\n * @param url - Request URL\n * @param options - Options\n *\n * @returns Data observable\n */\nexport function requestJSON<T>(\n  url: URL | string, options?: Options\n): Observable<T> {\n  return request(url, options)\n    .pipe(\n      switchMap(res => res.text()),\n      map(body => JSON.parse(body) as T),\n      shareReplay(1)\n    )\n}\n\n/**\n * Fetch HTML from the given URL\n *\n * @param url - Request URL\n * @param options - Options\n *\n * @returns Data observable\n */\nexport function requestHTML(\n  url: URL | string, options?: Options\n): Observable<Document> {\n  const dom = new DOMParser()\n  return request(url, options)\n    .pipe(\n      switchMap(res => res.text()),\n      map(res => dom.parseFromString(res, \"text/html\")),\n      shareReplay(1)\n    )\n}\n\n/**\n * Fetch XML from the given URL\n *\n * @param url - Request URL\n * @param options - Options\n *\n * @returns Data observable\n */\nexport function requestXML(\n  url: URL | string, options?: Options\n): Observable<Document> {\n  const dom = new DOMParser()\n  return request(url, options)\n    .pipe(\n      switchMap(res => res.text()),\n      map(res => dom.parseFromString(res, \"text/xml\")),\n      shareReplay(1)\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  fromEvent,\n  map,\n  merge,\n  startWith\n} from \"rxjs\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Viewport offset\n */\nexport interface ViewportOffset {\n  x: number                            /* Horizontal offset */\n  y: number                            /* Vertical offset */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve viewport offset\n *\n * On iOS Safari, viewport offset can be negative due to overflow scrolling.\n * As this may induce strange behaviors downstream, we'll just limit it to 0.\n *\n * @returns Viewport offset\n */\nexport function getViewportOffset(): ViewportOffset {\n  return {\n    x: Math.max(0, scrollX),\n    y: Math.max(0, scrollY)\n  }\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Watch viewport offset\n *\n * @returns Viewport offset observable\n */\nexport function watchViewportOffset(): Observable<ViewportOffset> {\n  return merge(\n    fromEvent(window, \"scroll\", { passive: true }),\n    fromEvent(window, \"resize\", { passive: true })\n  )\n    .pipe(\n      map(getViewportOffset),\n      startWith(getViewportOffset())\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  fromEvent,\n  map,\n  startWith\n} from \"rxjs\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Viewport size\n */\nexport interface ViewportSize {\n  width: number                        /* Viewport width */\n  height: number                       /* Viewport height */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve viewport size\n *\n * @returns Viewport size\n */\nexport function getViewportSize(): ViewportSize {\n  return {\n    width:  innerWidth,\n    height: innerHeight\n  }\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Watch viewport size\n *\n * @returns Viewport size observable\n */\nexport function watchViewportSize(): Observable<ViewportSize> {\n  return fromEvent(window, \"resize\", { passive: true })\n    .pipe(\n      map(getViewportSize),\n      startWith(getViewportSize())\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  combineLatest,\n  map,\n  shareReplay\n} from \"rxjs\"\n\nimport {\n  ViewportOffset,\n  watchViewportOffset\n} from \"../offset\"\nimport {\n  ViewportSize,\n  watchViewportSize\n} from \"../size\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Viewport\n */\nexport interface Viewport {\n  offset: ViewportOffset               /* Viewport offset */\n  size: ViewportSize                   /* Viewport size */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch viewport\n *\n * @returns Viewport observable\n */\nexport function watchViewport(): Observable<Viewport> {\n  return combineLatest([\n    watchViewportOffset(),\n    watchViewportSize()\n  ])\n    .pipe(\n      map(([offset, size]) => ({ offset, size })),\n      shareReplay(1)\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  combineLatest,\n  distinctUntilKeyChanged,\n  map\n} from \"rxjs\"\n\nimport { Header } from \"~/components\"\n\nimport { getElementOffset } from \"../../element\"\nimport { Viewport } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch viewport relative to element\n *\n * @param el - Element\n * @param options - Options\n *\n * @returns Viewport observable\n */\nexport function watchViewportAt(\n  el: HTMLElement, { viewport$, header$ }: WatchOptions\n): Observable<Viewport> {\n  const size$ = viewport$\n    .pipe(\n      distinctUntilKeyChanged(\"size\")\n    )\n\n  /* Compute element offset */\n  const offset$ = combineLatest([size$, header$])\n    .pipe(\n      map(() => getElementOffset(el))\n    )\n\n  /* Compute relative viewport, return hot observable */\n  return combineLatest([header$, viewport$, offset$])\n    .pipe(\n      map(([{ height }, { offset, size }, { x, y }]) => ({\n        offset: {\n          x: offset.x - x,\n          y: offset.y - y + height\n        },\n        size\n      }))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  endWith,\n  fromEvent,\n  ignoreElements,\n  mergeWith,\n  share,\n  takeUntil\n} from \"rxjs\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Worker message\n */\nexport interface WorkerMessage {\n  type: unknown                        /* Message type */\n  data?: unknown                       /* Message data */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Create an observable for receiving from a web worker\n *\n * @template T - Data type\n *\n * @param worker - Web worker\n *\n * @returns Message observable\n */\nfunction recv<T>(worker: Worker): Observable<T> {\n  return fromEvent<MessageEvent<T>, T>(worker, \"message\", ev => ev.data)\n}\n\n/**\n * Create a subject for sending to a web worker\n *\n * @template T - Data type\n *\n * @param worker - Web worker\n *\n * @returns Message subject\n */\nfunction send<T>(worker: Worker): Subject<T> {\n  const send$ = new Subject<T>()\n  send$.subscribe(data => worker.postMessage(data))\n\n  /* Return message subject */\n  return send$\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Create a bidirectional communication channel to a web worker\n *\n * @template T - Data type\n *\n * @param url - Worker URL\n * @param worker - Worker\n *\n * @returns Worker subject\n */\nexport function watchWorker<T extends WorkerMessage>(\n  url: string, worker = new Worker(url)\n): Subject<T> {\n  const recv$ = recv<T>(worker)\n  const send$ = send<T>(worker)\n\n  /* Create worker subject and forward messages */\n  const worker$ = new Subject<T>()\n  worker$.subscribe(send$)\n\n  /* Return worker subject */\n  const done$ = send$.pipe(ignoreElements(), endWith(true))\n  return worker$\n    .pipe(\n      ignoreElements(),\n      mergeWith(recv$.pipe(takeUntil(done$))),\n      share()\n    ) as Subject<T>\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { getElement, getLocation } from \"~/browser\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Feature flag\n */\nexport type Flag =\n  | \"announce.dismiss\"                 /* Dismissable announcement bar */\n  | \"content.code.annotate\"            /* Code annotations */\n  | \"content.code.copy\"                /* Code copy button */\n  | \"content.lazy\"                     /* Lazy content elements */\n  | \"content.tabs.link\"                /* Link content tabs */\n  | \"content.tooltips\"                 /* Tooltips */\n  | \"header.autohide\"                  /* Hide header */\n  | \"navigation.expand\"                /* Automatic expansion */\n  | \"navigation.indexes\"               /* Section pages */\n  | \"navigation.instant\"               /* Instant navigation */\n  | \"navigation.instant.progress\"      /* Instant navigation progress */\n  | \"navigation.sections\"              /* Section navigation */\n  | \"navigation.tabs\"                  /* Tabs navigation */\n  | \"navigation.tabs.sticky\"           /* Tabs navigation (sticky) */\n  | \"navigation.top\"                   /* Back-to-top button */\n  | \"navigation.tracking\"              /* Anchor tracking */\n  | \"search.highlight\"                 /* Search highlighting */\n  | \"search.share\"                     /* Search sharing */\n  | \"search.suggest\"                   /* Search suggestions */\n  | \"toc.follow\"                       /* Following table of contents */\n  | \"toc.integrate\"                    /* Integrated table of contents */\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Translation\n */\nexport type Translation =\n  | \"clipboard.copy\"                   /* Copy to clipboard */\n  | \"clipboard.copied\"                 /* Copied to clipboard */\n  | \"search.result.placeholder\"        /* Type to start searching */\n  | \"search.result.none\"               /* No matching documents */\n  | \"search.result.one\"                /* 1 matching document */\n  | \"search.result.other\"              /* # matching documents */\n  | \"search.result.more.one\"           /* 1 more on this page */\n  | \"search.result.more.other\"         /* # more on this page */\n  | \"search.result.term.missing\"       /* Missing */\n  | \"select.version\"                   /* Version selector */\n\n/**\n * Translations\n */\nexport type Translations =\n  Record<Translation, string>\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Versioning\n */\nexport interface Versioning {\n  provider: \"mike\"                     /* Version provider */\n  default?: string | string[]          /* Default version */\n  alias?: boolean                      /* Show alias */\n}\n\n/**\n * Configuration\n */\nexport interface Config {\n  base: string                         /* Base URL */\n  features: Flag[]                     /* Feature flags */\n  translations: Translations           /* Translations */\n  search: string                       /* Search worker URL */\n  tags?: Record<string, string>        /* Tags mapping */\n  version?: Versioning                 /* Versioning */\n}\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve global configuration and make base URL absolute\n */\nconst script = getElement(\"#__config\")\nconst config: Config = JSON.parse(script.textContent!)\nconfig.base = `${new URL(config.base, getLocation())}`\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve global configuration\n *\n * @returns Global configuration\n */\nexport function configuration(): Config {\n  return config\n}\n\n/**\n * Check whether a feature flag is enabled\n *\n * @param flag - Feature flag\n *\n * @returns Test result\n */\nexport function feature(flag: Flag): boolean {\n  return config.features.includes(flag)\n}\n\n/**\n * Retrieve the translation for the given key\n *\n * @param key - Key to be translated\n * @param value - Positional value, if any\n *\n * @returns Translation\n */\nexport function translation(\n  key: Translation, value?: string | number\n): string {\n  return typeof value !== \"undefined\"\n    ? config.translations[key].replace(\"#\", value.toString())\n    : config.translations[key]\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { getElement, getElements } from \"~/browser\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Component type\n */\nexport type ComponentType =\n  | \"announce\"                         /* Announcement bar */\n  | \"container\"                        /* Container */\n  | \"consent\"                          /* Consent */\n  | \"content\"                          /* Content */\n  | \"dialog\"                           /* Dialog */\n  | \"header\"                           /* Header */\n  | \"header-title\"                     /* Header title */\n  | \"header-topic\"                     /* Header topic */\n  | \"main\"                             /* Main area */\n  | \"outdated\"                         /* Version warning */\n  | \"palette\"                          /* Color palette */\n  | \"progress\"                         /* Progress indicator */\n  | \"search\"                           /* Search */\n  | \"search-query\"                     /* Search input */\n  | \"search-result\"                    /* Search results */\n  | \"search-share\"                     /* Search sharing */\n  | \"search-suggest\"                   /* Search suggestions */\n  | \"sidebar\"                          /* Sidebar */\n  | \"skip\"                             /* Skip link */\n  | \"source\"                           /* Repository information */\n  | \"tabs\"                             /* Navigation tabs */\n  | \"toc\"                              /* Table of contents */\n  | \"top\"                              /* Back-to-top button */\n\n/**\n * Component\n *\n * @template T - Component type\n * @template U - Reference type\n */\nexport type Component<\n  T extends {} = {},\n  U extends HTMLElement = HTMLElement\n> =\n  T & {\n    ref: U                             /* Component reference */\n  }\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Component type map\n */\ninterface ComponentTypeMap {\n  \"announce\": HTMLElement              /* Announcement bar */\n  \"container\": HTMLElement             /* Container */\n  \"consent\": HTMLElement               /* Consent */\n  \"content\": HTMLElement               /* Content */\n  \"dialog\": HTMLElement                /* Dialog */\n  \"header\": HTMLElement                /* Header */\n  \"header-title\": HTMLElement          /* Header title */\n  \"header-topic\": HTMLElement          /* Header topic */\n  \"main\": HTMLElement                  /* Main area */\n  \"outdated\": HTMLElement              /* Version warning */\n  \"palette\": HTMLElement               /* Color palette */\n  \"progress\": HTMLElement              /* Progress indicator */\n  \"search\": HTMLElement                /* Search */\n  \"search-query\": HTMLInputElement     /* Search input */\n  \"search-result\": HTMLElement         /* Search results */\n  \"search-share\": HTMLAnchorElement    /* Search sharing */\n  \"search-suggest\": HTMLElement        /* Search suggestions */\n  \"sidebar\": HTMLElement               /* Sidebar */\n  \"skip\": HTMLAnchorElement            /* Skip link */\n  \"source\": HTMLAnchorElement          /* Repository information */\n  \"tabs\": HTMLElement                  /* Navigation tabs */\n  \"toc\": HTMLElement                   /* Table of contents */\n  \"top\": HTMLAnchorElement             /* Back-to-top button */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Retrieve the element for a given component or throw a reference error\n *\n * @template T - Component type\n *\n * @param type - Component type\n * @param node - Node of reference\n *\n * @returns Element\n */\nexport function getComponentElement<T extends ComponentType>(\n  type: T, node: ParentNode = document\n): ComponentTypeMap[T] {\n  return getElement(`[data-md-component=${type}]`, node)\n}\n\n/**\n * Retrieve all elements for a given component\n *\n * @template T - Component type\n *\n * @param type - Component type\n * @param node - Node of reference\n *\n * @returns Elements\n */\nexport function getComponentElements<T extends ComponentType>(\n  type: T, node: ParentNode = document\n): ComponentTypeMap[T][] {\n  return getElements(`[data-md-component=${type}]`, node)\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  Subject,\n  defer,\n  finalize,\n  fromEvent,\n  map,\n  tap\n} from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport { getElement } from \"~/browser\"\n\nimport { Component } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Announcement bar\n */\nexport interface Announce {\n  hash: number                        /* Content hash */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch announcement bar\n *\n * @param el - Announcement bar element\n *\n * @returns Announcement bar observable\n */\nexport function watchAnnounce(\n  el: HTMLElement\n): Observable<Announce> {\n  const button = getElement(\".md-typeset > :first-child\", el)\n  return fromEvent(button, \"click\", { once: true })\n    .pipe(\n      map(() => getElement(\".md-typeset\", el)),\n      map(content => ({ hash: __md_hash(content.innerHTML) }))\n    )\n}\n\n/**\n * Mount announcement bar\n *\n * @param el - Announcement bar element\n *\n * @returns Announcement bar component observable\n */\nexport function mountAnnounce(\n  el: HTMLElement\n): Observable<Component<Announce>> {\n  if (!feature(\"announce.dismiss\") || !el.childElementCount)\n    return EMPTY\n\n  /* Support instant navigation - see https://t.ly/3FTme */\n  if (!el.hidden) {\n    const content = getElement(\".md-typeset\", el)\n    if (__md_hash(content.innerHTML) === __md_get(\"__announce\"))\n      el.hidden = true\n  }\n\n  /* Mount component on subscription */\n  return defer(() => {\n    const push$ = new Subject<Announce>()\n    push$.subscribe(({ hash }) => {\n      el.hidden = true\n\n      /* Persist preference in local storage */\n      __md_set<number>(\"__announce\", hash)\n    })\n\n    /* Create and return component */\n    return watchAnnounce(el)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  finalize,\n  map,\n  tap\n} from \"rxjs\"\n\nimport { Component } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Consent\n */\nexport interface Consent {\n  hidden: boolean                      /* Consent is hidden */\n}\n\n/**\n * Consent defaults\n */\nexport interface ConsentDefaults {\n  analytics?: boolean                  /* Consent for Analytics */\n  github?: boolean                     /* Consent for GitHub */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  target$: Observable<HTMLElement>     /* Target observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  target$: Observable<HTMLElement>     /* Target observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch consent\n *\n * @param el - Consent element\n * @param options - Options\n *\n * @returns Consent observable\n */\nexport function watchConsent(\n  el: HTMLElement, { target$ }: WatchOptions\n): Observable<Consent> {\n  return target$\n    .pipe(\n      map(target => ({ hidden: target !== el }))\n    )\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Mount consent\n *\n * @param el - Consent element\n * @param options - Options\n *\n * @returns Consent component observable\n */\nexport function mountConsent(\n  el: HTMLElement, options: MountOptions\n): Observable<Component<Consent>> {\n  const internal$ = new Subject<Consent>()\n  internal$.subscribe(({ hidden }) => {\n    el.hidden = hidden\n  })\n\n  /* Create and return component */\n  return watchConsent(el, options)\n    .pipe(\n      tap(state => internal$.next(state)),\n      finalize(() => internal$.complete()),\n      map(state => ({ ref: el, ...state }))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { ComponentChild } from \"preact\"\n\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Tooltip style\n */\nexport type TooltipStyle =\n  | \"inline\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render a tooltip\n *\n * @param id - Tooltip identifier\n * @param style - Tooltip style\n *\n * @returns Element\n */\nexport function renderTooltip(\n  id?: string, style?: TooltipStyle\n): HTMLElement {\n  if (style === \"inline\") { // @todo refactor control flow\n    return (\n      <div class=\"md-tooltip md-tooltip--inline\" id={id} role=\"tooltip\">\n        <div class=\"md-tooltip__inner md-typeset\"></div>\n      </div>\n    )\n  } else {\n    return (\n      <div class=\"md-tooltip\" id={id} role=\"tooltip\">\n        <div class=\"md-tooltip__inner md-typeset\"></div>\n      </div>\n    )\n  }\n}\n\n// @todo: rename\nexport function renderInlineTooltip2(\n  ...children: ComponentChild[]\n): HTMLElement {\n  return (\n    <div class=\"md-tooltip2\" role=\"tooltip\">\n      <div class=\"md-tooltip2__inner md-typeset\">\n        {children}\n      </div>\n    </div>\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { h } from \"~/utilities\"\n\nimport { renderTooltip } from \"../tooltip\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render an annotation\n *\n * @param id - Annotation identifier\n * @param prefix - Tooltip identifier prefix\n *\n * @returns Element\n */\nexport function renderAnnotation(\n  id: string | number, prefix?: string\n): HTMLElement {\n  prefix = prefix ? `${prefix}_annotation_${id}` : undefined\n\n  /* Render tooltip with anchor, if given */\n  if (prefix) {\n    const anchor = prefix ? `#${prefix}` : undefined\n    return (\n      <aside class=\"md-annotation\" tabIndex={0}>\n        {renderTooltip(prefix)}\n        <a href={anchor} class=\"md-annotation__index\" tabIndex={-1}>\n          <span data-md-annotation-id={id}></span>\n        </a>\n      </aside>\n    )\n  } else {\n    return (\n      <aside class=\"md-annotation\" tabIndex={0}>\n        {renderTooltip(prefix)}\n        <span class=\"md-annotation__index\" tabIndex={-1}>\n          <span data-md-annotation-id={id}></span>\n        </span>\n      </aside>\n    )\n  }\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { translation } from \"~/_\"\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render a 'copy-to-clipboard' button\n *\n * @param id - Unique identifier\n *\n * @returns Element\n */\nexport function renderClipboardButton(id: string): HTMLElement {\n  return (\n    <button\n      class=\"md-clipboard md-icon\"\n      title={translation(\"clipboard.copy\")}\n      data-clipboard-target={`#${id} > code`}\n    ></button>\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport escapeHTML from \"escape-html\"\nimport { ComponentChild } from \"preact\"\n\nimport { configuration, feature, translation } from \"~/_\"\nimport { SearchItem } from \"~/integrations/search\"\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Render flag\n */\nconst enum Flag {\n  TEASER = 1,                          /* Render teaser */\n  PARENT = 2                           /* Render as parent */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper function\n * ------------------------------------------------------------------------- */\n\n/**\n * Render a search document\n *\n * @param document - Search document\n * @param flag - Render flags\n *\n * @returns Element\n */\nfunction renderSearchDocument(\n  document: SearchItem, flag: Flag\n): HTMLElement {\n  const parent = flag & Flag.PARENT\n  const teaser = flag & Flag.TEASER\n\n  /* Render missing query terms */\n  const missing = Object.keys(document.terms)\n    .filter(key => !document.terms[key])\n    .reduce<ComponentChild[]>((list, key) => [\n      ...list, <del>{escapeHTML(key)}</del>, \" \"\n    ], [])\n    .slice(0, -1)\n\n  /* Assemble query string for highlighting */\n  const config = configuration()\n  const url = new URL(document.location, config.base)\n  if (feature(\"search.highlight\"))\n    url.searchParams.set(\"h\", Object.entries(document.terms)\n      .filter(([, match]) => match)\n      .reduce((highlight, [value]) => `${highlight} ${value}`.trim(), \"\")\n    )\n\n  /* Render article or section, depending on flags */\n  const { tags } = configuration()\n  return (\n    <a href={`${url}`} class=\"md-search-result__link\" tabIndex={-1}>\n      <article\n        class=\"md-search-result__article md-typeset\"\n        data-md-score={document.score.toFixed(2)}\n      >\n        {parent > 0 && <div class=\"md-search-result__icon md-icon\"></div>}\n        {parent > 0 && <h1>{document.title}</h1>}\n        {parent <= 0 && <h2>{document.title}</h2>}\n        {teaser > 0 && document.text.length > 0 &&\n          document.text\n        }\n        {document.tags && (\n          <nav class=\"md-tags\">\n            {document.tags.map(tag => {\n              const type = tags\n                ? tag in tags\n                  ? `md-tag-icon md-tag--${tags[tag]}`\n                  : \"md-tag-icon\"\n                : \"\"\n              return (\n                <span class={`md-tag ${type}`}>{tag}</span>\n              )\n            })}\n          </nav>\n        )}\n        {teaser > 0 && missing.length > 0 &&\n          <p class=\"md-search-result__terms\">\n            {translation(\"search.result.term.missing\")}: {...missing}\n          </p>\n        }\n      </article>\n    </a>\n  )\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render a search result\n *\n * @param result - Search result\n *\n * @returns Element\n */\nexport function renderSearchResultItem(\n  result: SearchItem[]\n): HTMLElement {\n  const threshold = result[0].score\n  const docs = [...result]\n\n  const config = configuration()\n\n  /* Find and extract parent article */\n  const parent = docs.findIndex(doc => {\n    const l = `${new URL(doc.location, config.base)}` // @todo hacky\n    return !l.includes(\"#\")\n  })\n  const [article] = docs.splice(parent, 1)\n\n  /* Determine last index above threshold */\n  let index = docs.findIndex(doc => doc.score < threshold)\n  if (index === -1)\n    index = docs.length\n\n  /* Partition sections */\n  const best = docs.slice(0, index)\n  const more = docs.slice(index)\n\n  /* Render children */\n  const children = [\n    renderSearchDocument(article, Flag.PARENT | +(!parent && index === 0)),\n    ...best.map(section => renderSearchDocument(section, Flag.TEASER)),\n    ...more.length ? [\n      <details class=\"md-search-result__more\">\n        <summary tabIndex={-1}>\n          <div>\n            {more.length > 0 && more.length === 1\n              ? translation(\"search.result.more.one\")\n              : translation(\"search.result.more.other\", more.length)\n            }\n          </div>\n        </summary>\n        {...more.map(section => renderSearchDocument(section, Flag.TEASER))}\n      </details>\n    ] : []\n  ]\n\n  /* Render search result */\n  return (\n    <li class=\"md-search-result__item\">\n      {children}\n    </li>\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { SourceFacts } from \"~/components\"\nimport { h, round } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render repository facts\n *\n * @param facts - Repository facts\n *\n * @returns Element\n */\nexport function renderSourceFacts(facts: SourceFacts): HTMLElement {\n  return (\n    <ul class=\"md-source__facts\">\n      {Object.entries(facts).map(([key, value]) => (\n        <li class={`md-source__fact md-source__fact--${key}`}>\n          {typeof value === \"number\" ? round(value) : value}\n        </li>\n      ))}\n    </ul>\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Tabbed control type\n */\ntype TabbedControlType =\n  | \"prev\"\n  | \"next\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render control for content tabs\n *\n * @param type - Control type\n *\n * @returns Element\n */\nexport function renderTabbedControl(\n  type: TabbedControlType\n): HTMLElement {\n  const classes = `tabbed-control tabbed-control--${type}`\n  return (\n    <div class={classes} hidden>\n      <button class=\"tabbed-button\" tabIndex={-1} aria-hidden=\"true\"></button>\n    </div>\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render a table inside a wrapper to improve scrolling on mobile\n *\n * @param table - Table element\n *\n * @returns Element\n */\nexport function renderTable(table: HTMLElement): HTMLElement {\n  return (\n    <div class=\"md-typeset__scrollwrap\">\n      <div class=\"md-typeset__table\">\n        {table}\n      </div>\n    </div>\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { configuration, translation } from \"~/_\"\nimport { h } from \"~/utilities\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Version properties\n */\nexport interface VersionProperties {\n  hidden?: boolean                     /* Version is hidden */\n}\n\n/**\n * Version\n */\nexport interface Version {\n  version: string                      /* Version identifier */\n  title: string                        /* Version title */\n  aliases: string[]                    /* Version aliases */\n  properties?: VersionProperties       /* Version properties */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render a version\n *\n * @param version - Version\n *\n * @returns Element\n */\nfunction renderVersion(version: Version): HTMLElement {\n  const config = configuration()\n\n  /* Ensure trailing slash - see https://bit.ly/3rL5u3f */\n  const url = new URL(`../${version.version}/`, config.base)\n  return (\n    <li class=\"md-version__item\">\n      <a href={`${url}`} class=\"md-version__link\">\n        {version.title}\n        {config.version?.alias && version.aliases.length > 0 && (\n          <span class=\"md-version__alias\">\n            {version.aliases[0]}\n          </span>\n        )}\n      </a>\n    </li>\n  )\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Render a version selector\n *\n * @param versions - Versions\n * @param active - Active version\n *\n * @returns Element\n */\nexport function renderVersionSelector(\n  versions: Version[], active: Version\n): HTMLElement {\n  const config = configuration()\n  versions = versions.filter(version => !version.properties?.hidden)\n  return (\n    <div class=\"md-version\">\n      <button\n        class=\"md-version__current\"\n        aria-label={translation(\"select.version\")}\n      >\n        {active.title}\n        {config.version?.alias && active.aliases.length > 0 && (\n          <span class=\"md-version__alias\">\n            {active.aliases[0]}\n          </span>\n        )}\n      </button>\n      <ul class=\"md-version__list\">\n        {versions.map(renderVersion)}\n      </ul>\n    </div>\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  BehaviorSubject,\n  EMPTY,\n  Observable,\n  Subject,\n  animationFrameScheduler,\n  combineLatest,\n  combineLatestWith,\n  debounce,\n  defer,\n  distinctUntilChanged,\n  endWith,\n  filter,\n  finalize,\n  first,\n  ignoreElements,\n  map,\n  mergeMap,\n  observeOn,\n  queueScheduler,\n  share,\n  startWith,\n  switchMap,\n  tap,\n  throttleTime,\n  timer,\n  withLatestFrom\n} from \"rxjs\"\n\nimport {\n  ElementOffset,\n  Viewport,\n  getElement,\n  getElementContainers,\n  getElementOffsetAbsolute,\n  getElementSize,\n  watchElementContentOffset,\n  watchElementFocus,\n  watchElementHover\n} from \"~/browser\"\nimport { renderInlineTooltip2 } from \"~/templates\"\n\nimport { Component } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Tooltip\n */\nexport interface Tooltip {\n  active: boolean                      // Tooltip is active\n  offset: ElementOffset                // Tooltip offset\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Dependencies\n */\ninterface Dependencies {\n  content$: Observable<HTMLElement>    // Tooltip content observable\n  viewport$: Observable<Viewport>      // Viewport observable\n}\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Global sequence number for tooltips\n */\nlet sequence = 0\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch tooltip\n *\n * This function tracks the tooltip host element, and deduces the active state\n * and offset of the tooltip from it. The active state is determined by whether\n * the host element is focused or hovered, and the offset is determined by the\n * host element's absolute position in the document.\n *\n * @param el - Tooltip host element\n *\n * @returns Tooltip observable\n */\nexport function watchTooltip2(\n  el: HTMLElement\n): Observable<Tooltip> {\n\n  // Compute whether tooltip should be shown - we need to watch both focus and\n  // hover events on the host element and emit if one of them is active. In case\n  // of a hover event, we keep the element visible for a short amount of time\n  // after the pointer left the host element for a better user experience.\n  const active$ =\n    combineLatest([\n      watchElementFocus(el),\n      watchElementHover(el)\n    ])\n      .pipe(\n        map(([focus, hover]) => focus || hover),\n        distinctUntilChanged()\n      )\n\n  // We need to determine all parent elements of the host element that are\n  // currently scrollable, as they might affect the position of the tooltip\n  // depending on their horizontal of vertical offset. We must track all of\n  // them and recompute the position of the tooltip if they change.\n  const offset$ =\n    defer(() => getElementContainers(el)).pipe(\n      mergeMap(watchElementContentOffset),\n      throttleTime(1),\n      // Note that we need to poll the value again if the active state changes,\n      // as otherwise the tooltip might be misplaced. This particularly happens\n      // when using third-party integrations like tablesort that change the\n      // position of elements \u2013 see https://t.ly/Y-V7X\n      combineLatestWith(active$),\n      map(() => getElementOffsetAbsolute(el)),\n    )\n\n  // Only track parent elements and compute offset of the tooltip host if the\n  // tooltip should be shown - we defer the computation of the offset until the\n  // tooltip becomes active for the first time. This is necessary, because we\n  // must also keep the tooltip active as long as it is focused or hovered.\n  return active$.pipe(\n    first(active => active),\n    switchMap(() => combineLatest([active$, offset$])),\n    map(([active, offset]) => ({ active, offset })),\n    share()\n  )\n}\n\n/**\n * Mount tooltip\n *\n * This function renders a tooltip with the content from the provided `content$`\n * observable as passed via the dependencies. If the returned element has a role\n * of type `dialog`, the tooltip is considered to be interactive, and rendered\n * either above or below the host element, depending on the available space.\n *\n * If the returned element has a role of type `tooltip`, the tooltip is always\n * rendered below the host element and considered to be non-interactive. This\n * allows us to reuse the same positioning logic for both interactive and\n * non-interactive tooltips, as it is largely the same.\n *\n * @param el - Tooltip host element\n * @param dependencies - Dependencies\n *\n * @returns Tooltip component observable\n */\nexport function mountTooltip2(\n  el: HTMLElement, dependencies: Dependencies\n): Observable<Component<Tooltip>> {\n  const { content$, viewport$ } = dependencies\n\n  // Compute unique tooltip id - this is necessary to associate the tooltip host\n  // element with the tooltip element for ARIA purposes\n  const id = `__tooltip2_${sequence++}`\n\n  // Create component on subscription\n  return defer(() => {\n    const push$ = new Subject<Tooltip>()\n\n    // Create subject to track tooltip presence and visibility - we use another\n    // purely internal subject to track the tooltip's presence and visibility,\n    // as the tooltip should be visible if the host element or tooltip itself\n    // is focused or hovered to allow for smooth pointer migration\n    const show$ = new BehaviorSubject(false)\n    push$.pipe(ignoreElements(), endWith(false))\n      .subscribe(show$)\n\n    // Create observable controlling tooltip element - we create and attach the\n    // tooltip only if it is actually present, in order to keep the number of\n    // elements low. We need to keep the tooltip visible for a short time after\n    // the pointer left the host element or tooltip itself. For this, we use an\n    // inner subscription to the tooltip observable, which we terminate when the\n    // tooltip should not be shown, automatically removing the element. Moreover\n    // we use the queue scheduler, which will schedule synchronously in case the\n    // tooltip should be shown, and asynchronously if it should be hidden.\n    const node$ = show$.pipe(\n      debounce(active => timer(+!active * 250, queueScheduler)),\n      distinctUntilChanged(),\n      switchMap(active => active ? content$ : EMPTY),\n      tap(node => node.id = id),\n      share()\n    )\n\n    // Compute tooltip presence and visibility - the tooltip should be shown if\n    // the host element or the tooltip itself is focused or hovered\n    combineLatest([\n      push$.pipe(map(({ active }) => active)),\n      node$.pipe(\n        switchMap(node => watchElementHover(node, 250)),\n        startWith(false)\n      )\n    ])\n      .pipe(map(states => states.some(active => active)))\n      .subscribe(show$)\n\n    // Compute tooltip origin - we need to compute the tooltip origin depending\n    // on the position of the host element, the viewport size, as well as the\n    // actual size of the tooltip, if positioned above. The tooltip must about\n    // to be rendered for this to be correct, which is why we do it here.\n    const origin$ = show$.pipe(\n      filter(active => active),\n      withLatestFrom(node$, viewport$),\n      map(([_, node, { size }]) => {\n        const host = el.getBoundingClientRect()\n        const x = host.width / 2\n\n        // If the tooltip is non-interactive, we always render it below the\n        // actual element because all operating systems do it that way\n        if (node.role === \"tooltip\") {\n          return { x, y: 8 + host.height }\n\n        // Otherwise, we determine where there is more space, and render the\n        // tooltip either above or below the host element\n        } else if (host.y >= size.height / 2) {\n          const { height } = getElementSize(node)\n          return { x, y: -16 - height }\n        } else {\n          return { x, y: +16 + host.height }\n        }\n      })\n    )\n\n    // Update tooltip position - we always need to update the position of the\n    // tooltip, as it might change depending on the viewport offset of the host\n    combineLatest([node$, push$, origin$])\n      .subscribe(([node, { offset }, origin]) => {\n        node.style.setProperty(\"--md-tooltip-host-x\", `${offset.x}px`)\n        node.style.setProperty(\"--md-tooltip-host-y\", `${offset.y}px`)\n\n        // Update tooltip origin - this is mainly set to determine the position\n        // of the tooltip tail, to show the direction it is originating from\n        node.style.setProperty(\"--md-tooltip-x\", `${origin.x}px`)\n        node.style.setProperty(\"--md-tooltip-y\", `${origin.y}px`)\n\n        // Update tooltip render location, i.e., whether the tooltip is shown\n        // above or below the host element, depending on the available space\n        node.classList.toggle(\"md-tooltip2--top\",    origin.y <  0)\n        node.classList.toggle(\"md-tooltip2--bottom\", origin.y >= 0)\n      })\n\n    // Update tooltip width - we only explicitly set the width of the tooltip\n    // if it is non-interactive, in case it should always be rendered centered\n    show$.pipe(\n      filter(active => active),\n      withLatestFrom(node$, (_, node) => node),\n      filter(node => node.role === \"tooltip\")\n    )\n      .subscribe(node => {\n        const size = getElementSize(getElement(\":scope > *\", node))\n\n        // Set tooltip width and remove tail by setting it to a width of zero -\n        // if authors want to keep the tail, we can move this to CSS later\n        node.style.setProperty(\"--md-tooltip-width\", `${size.width}px`)\n        node.style.setProperty(\"--md-tooltip-tail\",  `${0}px`)\n      })\n\n    // Update tooltip visibility - we defer to the next animation frame, because\n    // the tooltip must first be added to the document before we make it appear,\n    // or it will appear instantly without delay. Additionally, we need to keep\n    // the tooltip visible for a short time after the pointer left the host.\n    show$.pipe(\n      distinctUntilChanged(),\n      observeOn(animationFrameScheduler),\n      withLatestFrom(node$)\n    )\n      .subscribe(([active, node]) => {\n        node.classList.toggle(\"md-tooltip2--active\", active)\n      })\n\n    // Set up ARIA attributes when tooltip is visible\n    combineLatest([\n      show$.pipe(filter(active => active)),\n      node$\n    ])\n      .subscribe(([_, node]) => {\n        if (node.role === \"dialog\") {\n          el.setAttribute(\"aria-controls\", id)\n          el.setAttribute(\"aria-haspopup\", \"dialog\")\n        } else {\n          el.setAttribute(\"aria-describedby\", id)\n        }\n      })\n\n    // Remove ARIA attributes when tooltip is hidden\n    show$.pipe(filter(active => !active))\n      .subscribe(() => {\n        el.removeAttribute(\"aria-controls\")\n        el.removeAttribute(\"aria-describedby\")\n        el.removeAttribute(\"aria-haspopup\")\n      })\n\n    // Create and return component\n    return watchTooltip2(el)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n\n// ----------------------------------------------------------------------------\n\n/**\n * Mount inline tooltip\n *\n * @todo refactor this function\n *\n * @param el - Tooltip host element\n * @param dependencies - Dependencies\n * @param container - Container\n *\n * @returns Tooltip component observable\n */\nexport function mountInlineTooltip2(\n  el: HTMLElement, { viewport$ }: { viewport$: Observable<Viewport> },\n  container = document.body\n): Observable<Component<Tooltip>> {\n  return mountTooltip2(el, {\n    content$: new Observable<HTMLElement>(observer => {\n      const title = el.title\n      const node = renderInlineTooltip2(title)\n      observer.next(node)\n      el.removeAttribute(\"title\")\n      // Append tooltip and remove on unsubscription\n      container.append(node)\n      return () => {\n        node.remove()\n        el.setAttribute(\"title\", title)\n      }\n    }),\n    viewport$\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  animationFrameScheduler,\n  auditTime,\n  combineLatest,\n  debounceTime,\n  defer,\n  delay,\n  endWith,\n  filter,\n  finalize,\n  fromEvent,\n  ignoreElements,\n  map,\n  merge,\n  switchMap,\n  take,\n  takeUntil,\n  tap,\n  throttleTime,\n  withLatestFrom\n} from \"rxjs\"\n\nimport {\n  ElementOffset,\n  getActiveElement,\n  getElementSize,\n  watchElementContentOffset,\n  watchElementFocus,\n  watchElementOffset,\n  watchElementVisibility\n} from \"~/browser\"\n\nimport { Component } from \"../../../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Annotation\n */\nexport interface Annotation {\n  active: boolean                      /* Annotation is active */\n  offset: ElementOffset                /* Annotation offset */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  target$: Observable<HTMLElement>     /* Location target observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch annotation\n *\n * @param el - Annotation element\n * @param container - Containing element\n *\n * @returns Annotation observable\n */\nexport function watchAnnotation(\n  el: HTMLElement, container: HTMLElement\n): Observable<Annotation> {\n  const offset$ = defer(() => combineLatest([\n    watchElementOffset(el),\n    watchElementContentOffset(container)\n  ]))\n    .pipe(\n      map(([{ x, y }, scroll]): ElementOffset => {\n        const { width, height } = getElementSize(el)\n        return ({\n          x: x - scroll.x + width  / 2,\n          y: y - scroll.y + height / 2\n        })\n      })\n    )\n\n  /* Actively watch annotation on focus */\n  return watchElementFocus(el)\n    .pipe(\n      switchMap(active => offset$\n        .pipe(\n          map(offset => ({ active, offset })),\n          take(+!active || Infinity)\n        )\n      )\n    )\n}\n\n/**\n * Mount annotation\n *\n * @param el - Annotation element\n * @param container - Containing element\n * @param options - Options\n *\n * @returns Annotation component observable\n */\nexport function mountAnnotation(\n  el: HTMLElement, container: HTMLElement, { target$ }: MountOptions\n): Observable<Component<Annotation>> {\n  const [tooltip, index] = Array.from(el.children)\n\n  /* Mount component on subscription */\n  return defer(() => {\n    const push$ = new Subject<Annotation>()\n    const done$ = push$.pipe(ignoreElements(), endWith(true))\n    push$.subscribe({\n\n      /* Handle emission */\n      next({ offset }) {\n        el.style.setProperty(\"--md-tooltip-x\", `${offset.x}px`)\n        el.style.setProperty(\"--md-tooltip-y\", `${offset.y}px`)\n      },\n\n      /* Handle complete */\n      complete() {\n        el.style.removeProperty(\"--md-tooltip-x\")\n        el.style.removeProperty(\"--md-tooltip-y\")\n      }\n    })\n\n    /* Start animation only when annotation is visible */\n    watchElementVisibility(el)\n      .pipe(\n        takeUntil(done$)\n      )\n        .subscribe(visible => {\n          el.toggleAttribute(\"data-md-visible\", visible)\n        })\n\n    /* Toggle tooltip presence to mitigate empty lines when copying */\n    merge(\n      push$.pipe(filter(({ active }) => active)),\n      push$.pipe(debounceTime(250), filter(({ active }) => !active))\n    )\n      .subscribe({\n\n        /* Handle emission */\n        next({ active }) {\n          if (active)\n            el.prepend(tooltip)\n          else\n            tooltip.remove()\n        },\n\n        /* Handle complete */\n        complete() {\n          el.prepend(tooltip)\n        }\n      })\n\n    /* Toggle tooltip visibility */\n    push$\n      .pipe(\n        auditTime(16, animationFrameScheduler)\n      )\n        .subscribe(({ active }) => {\n          tooltip.classList.toggle(\"md-tooltip--active\", active)\n        })\n\n    /* Track relative origin of tooltip */\n    push$\n      .pipe(\n        throttleTime(125, animationFrameScheduler),\n        filter(() => !!el.offsetParent),\n        map(() => el.offsetParent!.getBoundingClientRect()),\n        map(({ x }) => x)\n      )\n        .subscribe({\n\n          /* Handle emission */\n          next(origin) {\n            if (origin)\n              el.style.setProperty(\"--md-tooltip-0\", `${-origin}px`)\n            else\n              el.style.removeProperty(\"--md-tooltip-0\")\n          },\n\n          /* Handle complete */\n          complete() {\n            el.style.removeProperty(\"--md-tooltip-0\")\n          }\n        })\n\n    /* Allow to copy link without scrolling to anchor */\n    fromEvent<MouseEvent>(index, \"click\")\n      .pipe(\n        takeUntil(done$),\n        filter(ev => !(ev.metaKey || ev.ctrlKey))\n      )\n        .subscribe(ev => {\n          ev.stopPropagation()\n          ev.preventDefault()\n        })\n\n    /* Allow to open link in new tab or blur on close */\n    fromEvent<MouseEvent>(index, \"mousedown\")\n      .pipe(\n        takeUntil(done$),\n        withLatestFrom(push$)\n      )\n        .subscribe(([ev, { active }]) => {\n\n          /* Open in new tab */\n          if (ev.button !== 0 || ev.metaKey || ev.ctrlKey) {\n            ev.preventDefault()\n\n          /* Close annotation */\n          } else if (active) {\n            ev.preventDefault()\n\n            /* Focus parent annotation, if any */\n            const parent = el.parentElement!.closest(\".md-annotation\")\n            if (parent instanceof HTMLElement)\n              parent.focus()\n            else\n              getActiveElement()?.blur()\n          }\n        })\n\n    /* Open and focus annotation on location target */\n    target$\n      .pipe(\n        takeUntil(done$),\n        filter(target => target === tooltip),\n        delay(125)\n      )\n        .subscribe(() => el.focus())\n\n    /* Create and return component */\n    return watchAnnotation(el, container)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  Subject,\n  defer,\n  endWith,\n  finalize,\n  ignoreElements,\n  merge,\n  share,\n  takeUntil\n} from \"rxjs\"\n\nimport {\n  getElement,\n  getElements,\n  getOptionalElement\n} from \"~/browser\"\nimport { renderAnnotation } from \"~/templates\"\n\nimport { Component } from \"../../../_\"\nimport {\n  Annotation,\n  mountAnnotation\n} from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  target$: Observable<HTMLElement>     /* Location target observable */\n  print$: Observable<boolean>          /* Media print observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Find all annotation hosts in the containing element\n *\n * @param container - Containing element\n *\n * @returns Annotation hosts\n */\nfunction findHosts(container: HTMLElement): HTMLElement[] {\n  return container.tagName === \"CODE\"\n    ? getElements(\".c, .c1, .cm\", container)\n    : [container]\n}\n\n/**\n * Find all annotation markers in the containing element\n *\n * @param container - Containing element\n *\n * @returns Annotation markers\n */\nfunction findMarkers(container: HTMLElement): Text[] {\n  const markers: Text[] = []\n  for (const el of findHosts(container)) {\n    const nodes: Text[] = []\n\n    /* Find all text nodes in current element */\n    const it = document.createNodeIterator(el, NodeFilter.SHOW_TEXT)\n    for (let node = it.nextNode(); node; node = it.nextNode())\n      nodes.push(node as Text)\n\n    /* Find all markers in each text node */\n    for (let text of nodes) {\n      let match: RegExpExecArray | null\n\n      /* Split text at marker and add to list */\n      while ((match = /(\\(\\d+\\))(!)?/.exec(text.textContent!))) {\n        const [, id, force] = match\n        if (typeof force === \"undefined\") {\n          const marker = text.splitText(match.index)\n          text = marker.splitText(id.length)\n          markers.push(marker)\n\n        /* Replace entire text with marker */\n        } else {\n          text.textContent = id\n          markers.push(text)\n          break\n        }\n      }\n    }\n  }\n  return markers\n}\n\n/**\n * Swap the child nodes of two elements\n *\n * @param source - Source element\n * @param target - Target element\n */\nfunction swap(source: HTMLElement, target: HTMLElement): void {\n  target.append(...Array.from(source.childNodes))\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount annotation list\n *\n * This function analyzes the containing code block and checks for markers\n * referring to elements in the given annotation list. If no markers are found,\n * the list is left untouched. Otherwise, list elements are rendered as\n * annotations inside the code block.\n *\n * @param el - Annotation list element\n * @param container - Containing element\n * @param options - Options\n *\n * @returns Annotation component observable\n */\nexport function mountAnnotationList(\n  el: HTMLElement, container: HTMLElement, { target$, print$ }: MountOptions\n): Observable<Component<Annotation>> {\n\n  /* Compute prefix for tooltip anchors */\n  const parent = container.closest(\"[id]\")\n  const prefix = parent?.id\n\n  /* Find and replace all markers with empty annotations */\n  const annotations = new Map<string, HTMLElement>()\n  for (const marker of findMarkers(container)) {\n    const [, id] = marker.textContent!.match(/\\((\\d+)\\)/)!\n    if (getOptionalElement(`:scope > li:nth-child(${id})`, el)) {\n      annotations.set(id, renderAnnotation(id, prefix))\n      marker.replaceWith(annotations.get(id)!)\n    }\n  }\n\n  /* Keep list if there are no annotations to render */\n  if (annotations.size === 0)\n    return EMPTY\n\n  /* Mount component on subscription */\n  return defer(() => {\n    const push$ = new Subject()\n    const done$ = push$.pipe(ignoreElements(), endWith(true))\n\n    /* Retrieve container pairs for swapping */\n    const pairs: [HTMLElement, HTMLElement][] = []\n    for (const [id, annotation] of annotations)\n      pairs.push([\n        getElement(\".md-typeset\", annotation),\n        getElement(`:scope > li:nth-child(${id})`, el)\n      ])\n\n    /* Handle print mode - see https://bit.ly/3rgPdpt */\n    print$.pipe(takeUntil(done$))\n      .subscribe(active => {\n        el.hidden = !active\n\n        /* Add class to discern list element */\n        el.classList.toggle(\"md-annotation-list\", active)\n\n        /* Show annotations in code block or list (print) */\n        for (const [inner, child] of pairs)\n          if (!active)\n            swap(child, inner)\n          else\n            swap(inner, child)\n      })\n\n    /* Create and return component */\n    return merge(...[...annotations]\n      .map(([, annotation]) => (\n        mountAnnotation(annotation, container, { target$ })\n      ))\n    )\n      .pipe(\n        finalize(() => push$.complete()),\n        share()\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { EMPTY, Observable, defer } from \"rxjs\"\n\nimport { Component } from \"../../../_\"\nimport { Annotation } from \"../_\"\nimport { mountAnnotationList } from \"../list\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  target$: Observable<HTMLElement>     /* Location target observable */\n  print$: Observable<boolean>          /* Media print observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Find list element directly following a block\n *\n * @param el - Annotation block element\n *\n * @returns List element or nothing\n */\nfunction findList(el: HTMLElement): HTMLElement | undefined {\n  if (el.nextElementSibling) {\n    const sibling = el.nextElementSibling as HTMLElement\n    if (sibling.tagName === \"OL\")\n      return sibling\n\n    /* Skip empty paragraphs - see https://bit.ly/3r4ZJ2O */\n    else if (sibling.tagName === \"P\" && !sibling.children.length)\n      return findList(sibling)\n  }\n\n  /* Everything else */\n  return undefined\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount annotation block\n *\n * @param el - Annotation block element\n * @param options - Options\n *\n * @returns Annotation component observable\n */\nexport function mountAnnotationBlock(\n  el: HTMLElement, options: MountOptions\n): Observable<Component<Annotation>> {\n  return defer(() => {\n    const list = findList(el)\n    return typeof list !== \"undefined\"\n      ? mountAnnotationList(list, el, options)\n      : EMPTY\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport ClipboardJS from \"clipboard\"\nimport {\n  EMPTY,\n  Observable,\n  Subject,\n  defer,\n  distinctUntilChanged,\n  distinctUntilKeyChanged,\n  filter,\n  finalize,\n  map,\n  mergeWith,\n  switchMap,\n  take,\n  takeLast,\n  takeUntil,\n  tap\n} from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport {\n  getElementContentSize,\n  getElements,\n  watchElementSize,\n  watchElementVisibility\n} from \"~/browser\"\nimport {\n  Tooltip,\n  mountInlineTooltip2\n} from \"~/components/tooltip2\"\nimport { renderClipboardButton } from \"~/templates\"\n\nimport { Component } from \"../../../_\"\nimport {\n  Annotation,\n  mountAnnotationList\n} from \"../../annotation\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Code block overflow\n */\nexport interface Overflow {\n  scrollable: boolean                  /* Code block overflows */\n}\n\n/**\n * Code block\n */\nexport type CodeBlock =\n  | Overflow\n  | Annotation\n  | Tooltip\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  target$: Observable<HTMLElement>     /* Location target observable */\n  print$: Observable<boolean>          /* Media print observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Global sequence number for code blocks\n */\nlet sequence = 0\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Find candidate list element directly following a code block\n *\n * @param el - Code block element\n *\n * @returns List element or nothing\n */\nfunction findCandidateList(el: HTMLElement): HTMLElement | undefined {\n  if (el.nextElementSibling) {\n    const sibling = el.nextElementSibling as HTMLElement\n    if (sibling.tagName === \"OL\")\n      return sibling\n\n    /* Skip empty paragraphs - see https://bit.ly/3r4ZJ2O */\n    else if (sibling.tagName === \"P\" && !sibling.children.length)\n      return findCandidateList(sibling)\n  }\n\n  /* Everything else */\n  return undefined\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch code block\n *\n * This function monitors size changes of the viewport, as well as switches of\n * content tabs with embedded code blocks, as both may trigger overflow.\n *\n * @param el - Code block element\n *\n * @returns Code block observable\n */\nexport function watchCodeBlock(\n  el: HTMLElement\n): Observable<Overflow> {\n  return watchElementSize(el)\n    .pipe(\n      map(({ width }) => {\n        const content = getElementContentSize(el)\n        return {\n          scrollable: content.width > width\n        }\n      }),\n      distinctUntilKeyChanged(\"scrollable\")\n    )\n}\n\n/**\n * Mount code block\n *\n * This function ensures that an overflowing code block is focusable through\n * keyboard, so it can be scrolled without a mouse to improve on accessibility.\n * Furthermore, if code annotations are enabled, they are mounted if and only\n * if the code block is currently visible, e.g., not in a hidden content tab.\n *\n * Note that code blocks may be mounted eagerly or lazily. If they're mounted\n * lazily (on first visibility), code annotation anchor links will not work,\n * as they are evaluated on initial page load, and code annotations in general\n * might feel a little bumpier.\n *\n * @param el - Code block element\n * @param options - Options\n *\n * @returns Code block and annotation component observable\n */\nexport function mountCodeBlock(\n  el: HTMLElement, options: MountOptions\n): Observable<Component<CodeBlock>> {\n  const { matches: hover } = matchMedia(\"(hover)\")\n\n  /* Defer mounting of code block - see https://bit.ly/3vHVoVD */\n  const factory$ = defer(() => {\n    const push$ = new Subject<Overflow>()\n    const done$ = push$.pipe(takeLast(1))\n    push$.subscribe(({ scrollable }) => {\n      if (scrollable && hover)\n        el.setAttribute(\"tabindex\", \"0\")\n      else\n        el.removeAttribute(\"tabindex\")\n    })\n\n    /* Render button for Clipboard.js integration */\n    const content$: Array<Observable<Component<CodeBlock>>> = []\n    if (ClipboardJS.isSupported()) {\n      if (el.closest(\".copy\") || (\n        feature(\"content.code.copy\") && !el.closest(\".no-copy\")\n      )) {\n        const parent = el.closest(\"pre\")!\n        parent.id = `__code_${sequence++}`\n\n        /* Mount tooltip, if enabled */\n        const button = renderClipboardButton(parent.id)\n        parent.insertBefore(button, el)\n        if (feature(\"content.tooltips\"))\n          content$.push(mountInlineTooltip2(button, { viewport$ }))\n      }\n    }\n\n    /* Handle code annotations */\n    const container = el.closest(\".highlight\")\n    if (container instanceof HTMLElement) {\n      const list = findCandidateList(container)\n\n      /* Mount code annotations, if enabled */\n      if (typeof list !== \"undefined\" && (\n        container.classList.contains(\"annotate\") ||\n        feature(\"content.code.annotate\")\n      )) {\n        const annotations$ = mountAnnotationList(list, el, options)\n        content$.push(\n          watchElementSize(container)\n            .pipe(\n              takeUntil(done$),\n              map(({ width, height }) => width && height),\n              distinctUntilChanged(),\n              switchMap(active => active ? annotations$ : EMPTY)\n            )\n        )\n      }\n    }\n\n    // If the code block has line spans, we can add this additional class to\n    // the code block element, which fixes the problem for highlighted code\n    // lines not stretching to the entirety of the screen when the code block\n    // overflows, e.g., on mobile - see\n    const spans = getElements(\":scope > span[id]\", el)\n    if (spans.length)\n      el.classList.add(\"md-code__content\")\n\n    /* Create and return component */\n    return watchCodeBlock(el)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state })),\n        mergeWith(...content$)\n      )\n  })\n\n  /* Mount code block lazily */\n  if (feature(\"content.lazy\"))\n    return watchElementVisibility(el)\n      .pipe(\n        filter(visible => visible),\n        take(1),\n        switchMap(() => factory$)\n      )\n\n  /* Mount code block */\n  return factory$\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  defer,\n  filter,\n  finalize,\n  map,\n  merge,\n  tap\n} from \"rxjs\"\n\nimport { Component } from \"../../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Details\n */\nexport interface Details {\n  action: \"open\" | \"close\"             /* Details state */\n  reveal?: boolean                     /* Details is revealed */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  target$: Observable<HTMLElement>     /* Location target observable */\n  print$: Observable<boolean>          /* Media print observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  target$: Observable<HTMLElement>     /* Location target observable */\n  print$: Observable<boolean>          /* Media print observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch details\n *\n * @param el - Details element\n * @param options - Options\n *\n * @returns Details observable\n */\nexport function watchDetails(\n  el: HTMLDetailsElement, { target$, print$ }: WatchOptions\n): Observable<Details> {\n  let open = true\n  return merge(\n\n    /* Open and focus details on location target */\n    target$\n      .pipe(\n        map(target => target.closest(\"details:not([open])\")!),\n        filter(details => el === details),\n        map(() => ({\n          action: \"open\", reveal: true\n        }) as Details)\n      ),\n\n    /* Open details on print and close afterwards */\n    print$\n      .pipe(\n        filter(active => active || !open),\n        tap(() => open = el.open),\n        map(active => ({\n          action: active ? \"open\" : \"close\"\n        }) as Details)\n      )\n  )\n}\n\n/**\n * Mount details\n *\n * This function ensures that `details` tags are opened on anchor jumps and\n * prior to printing, so the whole content of the page is visible.\n *\n * @param el - Details element\n * @param options - Options\n *\n * @returns Details component observable\n */\nexport function mountDetails(\n  el: HTMLDetailsElement, options: MountOptions\n): Observable<Component<Details>> {\n  return defer(() => {\n    const push$ = new Subject<Details>()\n    push$.subscribe(({ action, reveal }) => {\n      el.toggleAttribute(\"open\", action === \"open\")\n      if (reveal)\n        el.scrollIntoView()\n    })\n\n    /* Create and return component */\n    return watchDetails(el, options)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", ".node circle,.node ellipse,.node path,.node polygon,.node rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}marker{fill:var(--md-mermaid-edge-color)!important}.edgeLabel .label rect{fill:#0000}.flowchartTitleText{fill:var(--md-mermaid-label-fg-color)}.label{color:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.label foreignObject{line-height:normal;overflow:visible}.label div .edgeLabel{color:var(--md-mermaid-label-fg-color)}.edgeLabel,.edgeLabel p,.label div .edgeLabel{background-color:var(--md-mermaid-label-bg-color)}.edgeLabel,.edgeLabel p{fill:var(--md-mermaid-label-bg-color);color:var(--md-mermaid-edge-color)}.edgePath .path,.flowchart-link{stroke:var(--md-mermaid-edge-color);stroke-width:.05rem}.edgePath .arrowheadPath{fill:var(--md-mermaid-edge-color);stroke:none}.cluster rect{fill:var(--md-default-fg-color--lightest);stroke:var(--md-default-fg-color--lighter)}.cluster span{color:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}g #flowchart-circleEnd,g #flowchart-circleStart,g #flowchart-crossEnd,g #flowchart-crossStart,g #flowchart-pointEnd,g #flowchart-pointStart{stroke:none}.classDiagramTitleText{fill:var(--md-mermaid-label-fg-color)}g.classGroup line,g.classGroup rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}g.classGroup text{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.classLabel .box{fill:var(--md-mermaid-label-bg-color);background-color:var(--md-mermaid-label-bg-color);opacity:1}.classLabel .label{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.node .divider{stroke:var(--md-mermaid-node-fg-color)}.relation{stroke:var(--md-mermaid-edge-color)}.cardinality{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.cardinality text{fill:inherit!important}defs #classDiagram-compositionEnd,defs #classDiagram-compositionStart,defs #classDiagram-dependencyEnd,defs #classDiagram-dependencyStart,defs #classDiagram-extensionEnd,defs #classDiagram-extensionStart{fill:var(--md-mermaid-edge-color)!important;stroke:var(--md-mermaid-edge-color)!important}defs #classDiagram-aggregationEnd,defs #classDiagram-aggregationStart{fill:var(--md-mermaid-label-bg-color)!important;stroke:var(--md-mermaid-edge-color)!important}.statediagramTitleText{fill:var(--md-mermaid-label-fg-color)}g.stateGroup rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}g.stateGroup .state-title{fill:var(--md-mermaid-label-fg-color)!important;font-family:var(--md-mermaid-font-family)}g.stateGroup .composit{fill:var(--md-mermaid-label-bg-color)}.nodeLabel,.nodeLabel p{color:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}a .nodeLabel{text-decoration:underline}.node circle.state-end,.node circle.state-start,.start-state{fill:var(--md-mermaid-edge-color);stroke:none}.end-state-inner,.end-state-outer{fill:var(--md-mermaid-edge-color)}.end-state-inner,.node circle.state-end{stroke:var(--md-mermaid-label-bg-color)}.transition{stroke:var(--md-mermaid-edge-color)}[id^=state-fork] rect,[id^=state-join] rect{fill:var(--md-mermaid-edge-color)!important;stroke:none!important}.statediagram-cluster.statediagram-cluster .inner{fill:var(--md-default-bg-color)}.statediagram-cluster rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}.statediagram-state rect.divider{fill:var(--md-default-fg-color--lightest);stroke:var(--md-default-fg-color--lighter)}defs #statediagram-barbEnd{stroke:var(--md-mermaid-edge-color)}.entityTitleText{fill:var(--md-mermaid-label-fg-color)}.attributeBoxEven,.attributeBoxOdd{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}.entityBox{fill:var(--md-mermaid-label-bg-color);stroke:var(--md-mermaid-node-fg-color)}.entityLabel{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.relationshipLabelBox{fill:var(--md-mermaid-label-bg-color);fill-opacity:1;background-color:var(--md-mermaid-label-bg-color);opacity:1}.relationshipLabel{fill:var(--md-mermaid-label-fg-color)}.relationshipLine{stroke:var(--md-mermaid-edge-color)}defs #ONE_OR_MORE_END *,defs #ONE_OR_MORE_START *,defs #ONLY_ONE_END *,defs #ONLY_ONE_START *,defs #ZERO_OR_MORE_END *,defs #ZERO_OR_MORE_START *,defs #ZERO_OR_ONE_END *,defs #ZERO_OR_ONE_START *{stroke:var(--md-mermaid-edge-color)!important}defs #ZERO_OR_MORE_END circle,defs #ZERO_OR_MORE_START circle{fill:var(--md-mermaid-label-bg-color)}text:not([class]):last-child{fill:var(--md-mermaid-label-fg-color)}.actor{fill:var(--md-mermaid-sequence-actor-bg-color);stroke:var(--md-mermaid-sequence-actor-border-color)}text.actor>tspan{fill:var(--md-mermaid-sequence-actor-fg-color);font-family:var(--md-mermaid-font-family)}line{stroke:var(--md-mermaid-sequence-actor-line-color)}.actor-man circle,.actor-man line{fill:var(--md-mermaid-sequence-actorman-bg-color);stroke:var(--md-mermaid-sequence-actorman-line-color)}.messageLine0,.messageLine1{stroke:var(--md-mermaid-sequence-message-line-color)}.note{fill:var(--md-mermaid-sequence-note-bg-color);stroke:var(--md-mermaid-sequence-note-border-color)}.loopText,.loopText>tspan,.messageText,.noteText>tspan{stroke:none;font-family:var(--md-mermaid-font-family)!important}.messageText{fill:var(--md-mermaid-sequence-message-fg-color)}.loopText,.loopText>tspan{fill:var(--md-mermaid-sequence-loop-fg-color)}.noteText>tspan{fill:var(--md-mermaid-sequence-note-fg-color)}#arrowhead path{fill:var(--md-mermaid-sequence-message-line-color);stroke:none}.loopLine{fill:var(--md-mermaid-sequence-loop-bg-color);stroke:var(--md-mermaid-sequence-loop-border-color)}.labelBox{fill:var(--md-mermaid-sequence-label-bg-color);stroke:none}.labelText,.labelText>span{fill:var(--md-mermaid-sequence-label-fg-color);font-family:var(--md-mermaid-font-family)}.sequenceNumber{fill:var(--md-mermaid-sequence-number-fg-color)}rect.rect{fill:var(--md-mermaid-sequence-box-bg-color);stroke:none}rect.rect+text.text{fill:var(--md-mermaid-sequence-box-fg-color)}defs #sequencenumber{fill:var(--md-mermaid-sequence-number-bg-color)!important}", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  map,\n  of,\n  shareReplay,\n  tap\n} from \"rxjs\"\n\nimport { watchScript } from \"~/browser\"\nimport { h } from \"~/utilities\"\n\nimport { Component } from \"../../_\"\n\nimport themeCSS from \"./index.css\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mermaid diagram\n */\nexport interface Mermaid {}\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Mermaid instance observable\n */\nlet mermaid$: Observable<void>\n\n/**\n * Global sequence number for diagrams\n */\nlet sequence = 0\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Fetch Mermaid script\n *\n * @returns Mermaid scripts observable\n */\nfunction fetchScripts(): Observable<void> {\n  return typeof mermaid === \"undefined\" || mermaid instanceof Element\n    ? watchScript(\"https://unpkg.com/mermaid@11/dist/mermaid.min.js\")\n    : of(undefined)\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount Mermaid diagram\n *\n * @param el - Code block element\n *\n * @returns Mermaid diagram component observable\n */\nexport function mountMermaid(\n  el: HTMLElement\n): Observable<Component<Mermaid>> {\n  el.classList.remove(\"mermaid\") // Hack: mitigate https://bit.ly/3CiN6Du\n  mermaid$ ||= fetchScripts()\n    .pipe(\n      tap(() => mermaid.initialize({\n        startOnLoad: false,\n        themeCSS,\n        sequence: {\n          actorFontSize: \"16px\", // Hack: mitigate https://bit.ly/3y0NEi3\n          messageFontSize: \"16px\",\n          noteFontSize: \"16px\"\n        }\n      })),\n      map(() => undefined),\n      shareReplay(1)\n    )\n\n  /* Render diagram */\n  mermaid$.subscribe(async () => {\n    el.classList.add(\"mermaid\") // Hack: mitigate https://bit.ly/3CiN6Du\n    const id = `__mermaid_${sequence++}`\n\n    /* Create host element to replace code block */\n    const host = h(\"div\", { class: \"mermaid\" })\n    const text = el.textContent\n\n    /* Render and inject diagram */\n    const { svg, fn } = await mermaid.render(id, text)\n\n    /* Create a shadow root and inject diagram */\n    const shadow = host.attachShadow({ mode: \"closed\" })\n    shadow.innerHTML = svg\n\n    /* Replace code block with diagram and bind functions */\n    el.replaceWith(host)\n    fn?.(shadow)\n  })\n\n  /* Create and return component */\n  return mermaid$\n    .pipe(\n      map(() => ({ ref: el }))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { Observable, of } from \"rxjs\"\n\nimport { renderTable } from \"~/templates\"\nimport { h } from \"~/utilities\"\n\nimport { Component } from \"../../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Data table\n */\nexport interface DataTable {}\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Sentinel for replacement\n */\nconst sentinel = h(\"table\")\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount data table\n *\n * This function wraps a data table in another scrollable container, so it can\n * be smoothly scrolled on smaller screen sizes and won't break the layout.\n *\n * @param el - Data table element\n *\n * @returns Data table component observable\n */\nexport function mountDataTable(\n  el: HTMLElement\n): Observable<Component<DataTable>> {\n  el.replaceWith(sentinel)\n  sentinel.replaceWith(renderTable(el))\n\n  /* Create and return component */\n  return of({ ref: el })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  animationFrameScheduler,\n  asyncScheduler,\n  auditTime,\n  combineLatest,\n  defer,\n  endWith,\n  filter,\n  finalize,\n  fromEvent,\n  ignoreElements,\n  map,\n  merge,\n  skip,\n  startWith,\n  subscribeOn,\n  takeUntil,\n  tap,\n  withLatestFrom\n} from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport {\n  Viewport,\n  getElement,\n  getElementContentOffset,\n  getElementContentSize,\n  getElementOffset,\n  getElementSize,\n  getElements,\n  watchElementContentOffset,\n  watchElementSize,\n  watchElementVisibility\n} from \"~/browser\"\nimport { renderTabbedControl } from \"~/templates\"\nimport { h } from \"~/utilities\"\n\nimport { Component } from \"../../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Content tabs\n */\nexport interface ContentTabs {\n  active: HTMLLabelElement             /* Active tab label */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  target$: Observable<HTMLElement>     /* Location target observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch content tabs\n *\n * @param inputs - Content tabs input elements\n *\n * @returns Content tabs observable\n */\nexport function watchContentTabs(\n  inputs: HTMLInputElement[]\n): Observable<ContentTabs> {\n  const initial = inputs.find(input => input.checked) || inputs[0]\n  return merge(...inputs.map(input => fromEvent(input, \"change\")\n    .pipe(\n      map(() => getElement<HTMLLabelElement>(`label[for=\"${input.id}\"]`))\n    )\n  ))\n    .pipe(\n      startWith(getElement<HTMLLabelElement>(`label[for=\"${initial.id}\"]`)),\n      map(active => ({ active }))\n    )\n}\n\n/**\n * Mount content tabs\n *\n * @param el - Content tabs element\n * @param options - Options\n *\n * @returns Content tabs component observable\n */\nexport function mountContentTabs(\n  el: HTMLElement, { viewport$, target$ }: MountOptions\n): Observable<Component<ContentTabs>> {\n  const container = getElement(\".tabbed-labels\", el)\n  const inputs = getElements<HTMLInputElement>(\":scope > input\", el)\n\n  /* Render content tab previous button for pagination */\n  const prev = renderTabbedControl(\"prev\")\n  el.append(prev)\n\n  /* Render content tab next button for pagination */\n  const next = renderTabbedControl(\"next\")\n  el.append(next)\n\n  /* Mount component on subscription */\n  return defer(() => {\n    const push$ = new Subject<ContentTabs>()\n    const done$ = push$.pipe(ignoreElements(), endWith(true))\n    combineLatest([push$, watchElementSize(el), watchElementVisibility(el)])\n      .pipe(\n        takeUntil(done$),\n        auditTime(1, animationFrameScheduler)\n      )\n        .subscribe({\n\n          /* Handle emission */\n          next([{ active }, size]) {\n            const offset = getElementOffset(active)\n            const { width } = getElementSize(active)\n\n            /* Set tab indicator offset and width */\n            el.style.setProperty(\"--md-indicator-x\", `${offset.x}px`)\n            el.style.setProperty(\"--md-indicator-width\", `${width}px`)\n\n            /* Scroll container to active content tab */\n            const content = getElementContentOffset(container)\n            if (\n              offset.x         < content.x              ||\n              offset.x + width > content.x + size.width\n            )\n              container.scrollTo({\n                left: Math.max(0, offset.x - 16),\n                behavior: \"smooth\"\n              })\n          },\n\n          /* Handle complete */\n          complete() {\n            el.style.removeProperty(\"--md-indicator-x\")\n            el.style.removeProperty(\"--md-indicator-width\")\n          }\n        })\n\n    /* Hide content tab buttons on borders */\n    combineLatest([\n      watchElementContentOffset(container),\n      watchElementSize(container)\n    ])\n      .pipe(\n        takeUntil(done$)\n      )\n        .subscribe(([offset, size]) => {\n          const content = getElementContentSize(container)\n          prev.hidden = offset.x < 16\n          next.hidden = offset.x > content.width - size.width - 16\n        })\n\n    /* Paginate content tab container on click */\n    merge(\n      fromEvent(prev, \"click\").pipe(map(() => -1)),\n      fromEvent(next, \"click\").pipe(map(() => +1))\n    )\n      .pipe(\n        takeUntil(done$)\n      )\n        .subscribe(direction => {\n          const { width } = getElementSize(container)\n          container.scrollBy({\n            left: width * direction,\n            behavior: \"smooth\"\n          })\n        })\n\n    /* Switch to content tab target */\n    target$\n      .pipe(\n        takeUntil(done$),\n        filter(input => inputs.includes(input as HTMLInputElement))\n      )\n        .subscribe(input => input.click())\n\n    /* Add link to each content tab label */\n    container.classList.add(\"tabbed-labels--linked\")\n    for (const input of inputs) {\n      const label = getElement<HTMLLabelElement>(`label[for=\"${input.id}\"]`)\n      label.replaceChildren(h(\"a\", {\n        href: `#${label.htmlFor}`,\n        tabIndex: -1\n      }, ...Array.from(label.childNodes)))\n\n      /* Allow to copy link without scrolling to anchor */\n      fromEvent<MouseEvent>(label.firstElementChild!, \"click\")\n        .pipe(\n          takeUntil(done$),\n          filter(ev => !(ev.metaKey || ev.ctrlKey)),\n          tap(ev => {\n            ev.preventDefault()\n            ev.stopPropagation()\n          })\n        )\n          // @todo we might need to remove the anchor link on complete\n          .subscribe(() => {\n            history.replaceState({}, \"\", `#${label.htmlFor}`)\n            label.click()\n          })\n    }\n\n    /* Set up linking of content tabs, if enabled */\n    if (feature(\"content.tabs.link\"))\n      push$.pipe(\n        skip(1),\n        withLatestFrom(viewport$)\n      )\n        .subscribe(([{ active }, { offset }]) => {\n          const tab = active.innerText.trim()\n          if (active.hasAttribute(\"data-md-switching\")) {\n            active.removeAttribute(\"data-md-switching\")\n\n          /* Determine viewport offset of active tab */\n          } else {\n            const y = el.offsetTop - offset.y\n\n            /* Passively activate other tabs */\n            for (const set of getElements(\"[data-tabs]\"))\n              for (const input of getElements<HTMLInputElement>(\n                \":scope > input\", set\n              )) {\n                const label = getElement(`label[for=\"${input.id}\"]`)\n                if (\n                  label !== active &&\n                  label.innerText.trim() === tab\n                ) {\n                  label.setAttribute(\"data-md-switching\", \"\")\n                  input.click()\n                  break\n                }\n              }\n\n            /* Bring active tab into view */\n            window.scrollTo({\n              top: el.offsetTop - y\n            })\n\n            /* Persist active tabs in local storage */\n            const tabs = __md_get<string[]>(\"__tabs\") || []\n            __md_set(\"__tabs\", [...new Set([tab, ...tabs])])\n          }\n        })\n\n    /* Pause media (audio, video) on switch - see https://bit.ly/3Bk6cel */\n    push$.pipe(takeUntil(done$))\n      .subscribe(() => {\n        for (const media of getElements<HTMLAudioElement>(\"audio, video\", el))\n          media.pause()\n      })\n\n    /* Create and return component */\n    return watchContentTabs(inputs)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n    .pipe(\n      subscribeOn(asyncScheduler)\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { Observable, merge } from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport { Viewport, getElements } from \"~/browser\"\n\nimport { Component } from \"../../_\"\nimport {\n  Tooltip,\n  mountInlineTooltip2\n} from \"../../tooltip2\"\nimport {\n  Annotation,\n  mountAnnotationBlock\n} from \"../annotation\"\nimport {\n  CodeBlock,\n  mountCodeBlock\n} from \"../code\"\nimport {\n  Details,\n  mountDetails\n} from \"../details\"\nimport {\n  Mermaid,\n  mountMermaid\n} from \"../mermaid\"\nimport {\n  DataTable,\n  mountDataTable\n} from \"../table\"\nimport {\n  ContentTabs,\n  mountContentTabs\n} from \"../tabs\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Content\n */\nexport type Content =\n  | Annotation\n  | CodeBlock\n  | ContentTabs\n  | DataTable\n  | Details\n  | Mermaid\n  | Tooltip\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  target$: Observable<HTMLElement>     /* Location target observable */\n  print$: Observable<boolean>          /* Media print observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount content\n *\n * This function mounts all components that are found in the content of the\n * actual article, including code blocks, data tables and details.\n *\n * @param el - Content element\n * @param options - Options\n *\n * @returns Content component observable\n */\nexport function mountContent(\n  el: HTMLElement, { viewport$, target$, print$ }: MountOptions\n): Observable<Component<Content>> {\n  return merge(\n\n    /* Annotations */\n    ...getElements(\".annotate:not(.highlight)\", el)\n      .map(child => mountAnnotationBlock(child, { target$, print$ })),\n\n    /* Code blocks */\n    ...getElements(\"pre:not(.mermaid) > code\", el)\n      .map(child => mountCodeBlock(child, { target$, print$ })),\n\n    /* Mermaid diagrams */\n    ...getElements(\"pre.mermaid\", el)\n      .map(child => mountMermaid(child)),\n\n    /* Data tables */\n    ...getElements(\"table:not([class])\", el)\n      .map(child => mountDataTable(child)),\n\n    /* Details */\n    ...getElements(\"details\", el)\n      .map(child => mountDetails(child, { target$, print$ })),\n\n    /* Content tabs */\n    ...getElements(\"[data-tabs]\", el)\n      .map(child => mountContentTabs(child, { viewport$, target$ })),\n\n    /* Tooltips */\n    ...getElements(\"[title]\", el)\n      .filter(() => feature(\"content.tooltips\"))\n      .map(child => mountInlineTooltip2(child, { viewport$ }))\n  )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  defer,\n  delay,\n  finalize,\n  map,\n  merge,\n  of,\n  switchMap,\n  tap\n} from \"rxjs\"\n\nimport { getElement } from \"~/browser\"\n\nimport { Component } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Dialog\n */\nexport interface Dialog {\n  message: string                      /* Dialog message */\n  active: boolean                      /* Dialog is active */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  alert$: Subject<string>              /* Alert subject */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  alert$: Subject<string>              /* Alert subject */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch dialog\n *\n * @param _el - Dialog element\n * @param options - Options\n *\n * @returns Dialog observable\n */\nexport function watchDialog(\n  _el: HTMLElement, { alert$ }: WatchOptions\n): Observable<Dialog> {\n  return alert$\n    .pipe(\n      switchMap(message => merge(\n        of(true),\n        of(false).pipe(delay(2000))\n      )\n        .pipe(\n          map(active => ({ message, active }))\n        )\n      )\n    )\n}\n\n/**\n * Mount dialog\n *\n * This function reveals the dialog in the right corner when a new alert is\n * emitted through the subject that is passed as part of the options.\n *\n * @param el - Dialog element\n * @param options - Options\n *\n * @returns Dialog component observable\n */\nexport function mountDialog(\n  el: HTMLElement, options: MountOptions\n): Observable<Component<Dialog>> {\n  const inner = getElement(\".md-typeset\", el)\n  return defer(() => {\n    const push$ = new Subject<Dialog>()\n    push$.subscribe(({ message, active }) => {\n      el.classList.toggle(\"md-dialog--active\", active)\n      inner.textContent = message\n    })\n\n    /* Create and return component */\n    return watchDialog(el, options)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  Subject,\n  animationFrameScheduler,\n  asyncScheduler,\n  auditTime,\n  combineLatest,\n  debounceTime,\n  defer,\n  distinctUntilChanged,\n  filter,\n  finalize,\n  map,\n  merge,\n  of,\n  subscribeOn,\n  tap,\n  throttleTime\n} from \"rxjs\"\n\nimport {\n  ElementOffset,\n  getElement,\n  getElementContainer,\n  getElementOffset,\n  getElementSize,\n  watchElementContentOffset,\n  watchElementFocus,\n  watchElementHover\n} from \"~/browser\"\nimport { renderTooltip } from \"~/templates\"\n\nimport { Component } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Tooltip\n */\nexport interface Tooltip {\n  active: boolean                      /* Tooltip is active */\n  offset: ElementOffset                /* Tooltip offset */\n}\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Global sequence number for tooltips\n */\nlet sequence = 0\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch tooltip\n *\n * This function will append the tooltip temporarily to compute its width,\n * which is necessary for correct centering, and then removing it again.\n *\n * @param el - Tooltip element\n * @param host - Host element\n *\n * @returns Tooltip observable\n */\nexport function watchTooltip(\n  el: HTMLElement, host: HTMLElement\n): Observable<Tooltip> {\n  document.body.append(el)\n\n  /* Compute width and remove tooltip immediately */\n  const { width } = getElementSize(el)\n  el.style.setProperty(\"--md-tooltip-width\", `${width}px`)\n  el.remove()\n\n  /* Retrieve and watch containing element */\n  const container = getElementContainer(host)\n  const scroll$ =\n    typeof container !== \"undefined\"\n      ? watchElementContentOffset(container)\n      : of({ x: 0, y: 0 })\n\n  /* Compute tooltip visibility */\n  const active$ = merge(\n    watchElementFocus(host),\n    watchElementHover(host)\n  )\n    .pipe(\n      distinctUntilChanged()\n    )\n\n  /* Compute tooltip offset */\n  return combineLatest([active$, scroll$])\n    .pipe(\n      map(([active, scroll]) => {\n        let { x, y } = getElementOffset(host)\n        const size = getElementSize(host)\n\n        /**\n         * Experimental: fix handling of tables - see https://bit.ly/3TQEj5O\n         *\n         * If this proves to be a viable fix, we should refactor tooltip\n         * positioning and somehow streamline the current process. This might\n         * also fix positioning for annotations inside tables, which is another\n         * limitation.\n         */\n        const table = host.closest(\"table\")\n        if (table && host.parentElement) {\n          x += table.offsetLeft + host.parentElement.offsetLeft\n          y += table.offsetTop  + host.parentElement.offsetTop\n        }\n        return {\n          active,\n          offset: {\n            x: x - scroll.x + size.width  / 2 - width / 2,\n            y: y - scroll.y + size.height + 8\n          }\n        }\n      })\n    )\n}\n\n/**\n * Mount tooltip\n *\n * @param el - Host element\n *\n * @returns Tooltip component observable\n */\nexport function mountTooltip(\n  el: HTMLElement\n): Observable<Component<Tooltip>> {\n  const title = el.title\n  if (!title.length)\n    return EMPTY\n\n  /* Render tooltip and set title from host element */\n  const id = `__tooltip_${sequence++}`\n  const tooltip = renderTooltip(id, \"inline\")\n  const typeset = getElement(\".md-typeset\", tooltip)\n  typeset.innerHTML = title\n\n  /* Mount component on subscription */\n  return defer(() => {\n    const push$ = new Subject<Tooltip>()\n    push$.subscribe({\n\n      /* Handle emission */\n      next({ offset }) {\n        tooltip.style.setProperty(\"--md-tooltip-x\", `${offset.x}px`)\n        tooltip.style.setProperty(\"--md-tooltip-y\", `${offset.y}px`)\n      },\n\n      /* Handle complete */\n      complete() {\n        tooltip.style.removeProperty(\"--md-tooltip-x\")\n        tooltip.style.removeProperty(\"--md-tooltip-y\")\n      }\n    })\n\n    /* Toggle tooltip presence to mitigate empty lines when copying */\n    merge(\n      push$.pipe(filter(({ active }) => active)),\n      push$.pipe(debounceTime(250), filter(({ active }) => !active))\n    )\n      .subscribe({\n\n        /* Handle emission */\n        next({ active }) {\n          if (active) {\n            el.insertAdjacentElement(\"afterend\", tooltip)\n            el.setAttribute(\"aria-describedby\", id)\n            el.removeAttribute(\"title\")\n          } else {\n            tooltip.remove()\n            el.removeAttribute(\"aria-describedby\")\n            el.setAttribute(\"title\", title)\n          }\n        },\n\n        /* Handle complete */\n        complete() {\n          tooltip.remove()\n          el.removeAttribute(\"aria-describedby\")\n          el.setAttribute(\"title\", title)\n        }\n      })\n\n    /* Toggle tooltip visibility */\n    push$\n      .pipe(\n        auditTime(16, animationFrameScheduler)\n      )\n        .subscribe(({ active }) => {\n          tooltip.classList.toggle(\"md-tooltip--active\", active)\n        })\n\n    // @todo - refactor positioning together with annotations \u2013 there are\n    // several things that overlap and are identical in handling\n\n    /* Track relative origin of tooltip */\n    push$\n      .pipe(\n        throttleTime(125, animationFrameScheduler),\n        filter(() => !!el.offsetParent),\n        map(() => el.offsetParent!.getBoundingClientRect()),\n        map(({ x }) => x)\n      )\n      .subscribe({\n\n        /* Handle emission */\n        next(origin) {\n          if (origin)\n            tooltip.style.setProperty(\"--md-tooltip-0\", `${-origin}px`)\n          else\n            tooltip.style.removeProperty(\"--md-tooltip-0\")\n        },\n\n        /* Handle complete */\n        complete() {\n          tooltip.style.removeProperty(\"--md-tooltip-0\")\n        }\n      })\n\n    /* Create and return component */\n    return watchTooltip(tooltip, el)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n    .pipe(\n      subscribeOn(asyncScheduler)\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  bufferCount,\n  combineLatest,\n  combineLatestWith,\n  defer,\n  distinctUntilChanged,\n  distinctUntilKeyChanged,\n  endWith,\n  filter,\n  from,\n  ignoreElements,\n  map,\n  mergeMap,\n  mergeWith,\n  of,\n  shareReplay,\n  startWith,\n  switchMap,\n  takeUntil\n} from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport {\n  Viewport,\n  getElements,\n  watchElementSize,\n  watchToggle\n} from \"~/browser\"\n\nimport { Component } from \"../../_\"\nimport { Main } from \"../../main\"\nimport {\n  Tooltip,\n  mountTooltip\n} from \"../../tooltip\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Header\n */\nexport interface Header {\n  height: number                       /* Header visible height */\n  hidden: boolean                      /* Header is hidden */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n  main$: Observable<Main>              /* Main area observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Compute whether the header is hidden\n *\n * If the user scrolls past a certain threshold, the header can be hidden when\n * scrolling down, and shown when scrolling up.\n *\n * @param options - Options\n *\n * @returns Toggle observable\n */\nfunction isHidden({ viewport$ }: WatchOptions): Observable<boolean> {\n  if (!feature(\"header.autohide\"))\n    return of(false)\n\n  /* Compute direction and turning point */\n  const direction$ = viewport$\n    .pipe(\n      map(({ offset: { y } }) => y),\n      bufferCount(2, 1),\n      map(([a, b]) => [a < b, b] as const),\n      distinctUntilKeyChanged(0)\n    )\n\n  /* Compute whether header should be hidden */\n  const hidden$ = combineLatest([viewport$, direction$])\n    .pipe(\n      filter(([{ offset }, [, y]]) => Math.abs(y - offset.y) > 100),\n      map(([, [direction]]) => direction),\n      distinctUntilChanged()\n    )\n\n  /* Compute threshold for hiding */\n  const search$ = watchToggle(\"search\")\n  return combineLatest([viewport$, search$])\n    .pipe(\n      map(([{ offset }, search]) => offset.y > 400 && !search),\n      distinctUntilChanged(),\n      switchMap(active => active ? hidden$ : of(false)),\n      startWith(false)\n    )\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch header\n *\n * @param el - Header element\n * @param options - Options\n *\n * @returns Header observable\n */\nexport function watchHeader(\n  el: HTMLElement, options: WatchOptions\n): Observable<Header> {\n  return defer(() => combineLatest([\n    watchElementSize(el),\n    isHidden(options)\n  ]))\n    .pipe(\n      map(([{ height }, hidden]) => ({\n        height,\n        hidden\n      })),\n      distinctUntilChanged((a, b) => (\n        a.height === b.height &&\n        a.hidden === b.hidden\n      )),\n      shareReplay(1)\n    )\n}\n\n/**\n * Mount header\n *\n * This function manages the different states of the header, i.e. whether it's\n * hidden or rendered with a shadow. This depends heavily on the main area.\n *\n * @param el - Header element\n * @param options - Options\n *\n * @returns Header component observable\n */\nexport function mountHeader(\n  el: HTMLElement, { header$, main$ }: MountOptions\n): Observable<Component<Header | Tooltip>> {\n  return defer(() => {\n    const push$ = new Subject<Main>()\n    const done$ = push$.pipe(ignoreElements(), endWith(true))\n    push$\n      .pipe(\n        distinctUntilKeyChanged(\"active\"),\n        combineLatestWith(header$)\n      )\n        .subscribe(([{ active }, { hidden }]) => {\n          el.classList.toggle(\"md-header--shadow\", active && !hidden)\n          el.hidden = hidden\n        })\n\n    /* Mount tooltips, if enabled */\n    const tooltips = from(getElements(\"[title]\", el))\n      .pipe(\n        filter(() => feature(\"content.tooltips\")),\n        mergeMap(child => mountTooltip(child))\n      )\n\n    /* Link to main area */\n    main$.subscribe(push$)\n\n    /* Create and return component */\n    return header$\n      .pipe(\n        takeUntil(done$),\n        map(state => ({ ref: el, ...state })),\n        mergeWith(tooltips.pipe(takeUntil(done$)))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  Subject,\n  defer,\n  distinctUntilKeyChanged,\n  finalize,\n  map,\n  tap\n} from \"rxjs\"\n\nimport {\n  Viewport,\n  getElementSize,\n  getOptionalElement,\n  watchViewportAt\n} from \"~/browser\"\n\nimport { Component } from \"../../_\"\nimport { Header } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Header\n */\nexport interface HeaderTitle {\n  active: boolean                      /* Header title is active */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch header title\n *\n * @param el - Heading element\n * @param options - Options\n *\n * @returns Header title observable\n */\nexport function watchHeaderTitle(\n  el: HTMLElement, { viewport$, header$ }: WatchOptions\n): Observable<HeaderTitle> {\n  return watchViewportAt(el, { viewport$, header$ })\n    .pipe(\n      map(({ offset: { y } }) => {\n        const { height } = getElementSize(el)\n        return {\n          active: y >= height\n        }\n      }),\n      distinctUntilKeyChanged(\"active\")\n    )\n}\n\n/**\n * Mount header title\n *\n * This function swaps the header title from the site title to the title of the\n * current page when the user scrolls past the first headline.\n *\n * @param el - Header title element\n * @param options - Options\n *\n * @returns Header title component observable\n */\nexport function mountHeaderTitle(\n  el: HTMLElement, options: MountOptions\n): Observable<Component<HeaderTitle>> {\n  return defer(() => {\n    const push$ = new Subject<HeaderTitle>()\n    push$.subscribe({\n\n      /* Handle emission */\n      next({ active }) {\n        el.classList.toggle(\"md-header__title--active\", active)\n      },\n\n      /* Handle complete */\n      complete() {\n        el.classList.remove(\"md-header__title--active\")\n      }\n    })\n\n    /* Obtain headline, if any */\n    const heading = getOptionalElement(\".md-content h1\")\n    if (typeof heading === \"undefined\")\n      return EMPTY\n\n    /* Create and return component */\n    return watchHeaderTitle(heading, options)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  combineLatest,\n  distinctUntilChanged,\n  distinctUntilKeyChanged,\n  map,\n  switchMap\n} from \"rxjs\"\n\nimport {\n  Viewport,\n  watchElementSize\n} from \"~/browser\"\n\nimport { Header } from \"../header\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Main area\n */\nexport interface Main {\n  offset: number                       /* Main area top offset */\n  height: number                       /* Main area visible height */\n  active: boolean                      /* Main area is active */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch main area\n *\n * This function returns an observable that computes the visual parameters of\n * the main area which depends on the viewport vertical offset and height, as\n * well as the height of the header element, if the header is fixed.\n *\n * @param el - Main area element\n * @param options - Options\n *\n * @returns Main area observable\n */\nexport function watchMain(\n  el: HTMLElement, { viewport$, header$ }: WatchOptions\n): Observable<Main> {\n\n  /* Compute necessary adjustment for header */\n  const adjust$ = header$\n    .pipe(\n      map(({ height }) => height),\n      distinctUntilChanged()\n    )\n\n  /* Compute the main area's top and bottom borders */\n  const border$ = adjust$\n    .pipe(\n      switchMap(() => watchElementSize(el)\n        .pipe(\n          map(({ height }) => ({\n            top:    el.offsetTop,\n            bottom: el.offsetTop + height\n          })),\n          distinctUntilKeyChanged(\"bottom\")\n        )\n      )\n    )\n\n  /* Compute the main area's offset, visible height and if we scrolled past */\n  return combineLatest([adjust$, border$, viewport$])\n    .pipe(\n      map(([header, { top, bottom }, { offset: { y }, size: { height } }]) => {\n        height = Math.max(0, height\n          - Math.max(0, top    - y,  header)\n          - Math.max(0, height + y - bottom)\n        )\n        return {\n          offset: top - header,\n          height,\n          active: top - header <= y\n        }\n      }),\n      distinctUntilChanged((a, b) => (\n        a.offset === b.offset &&\n        a.height === b.height &&\n        a.active === b.active\n      ))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  asyncScheduler,\n  defer,\n  filter,\n  finalize,\n  fromEvent,\n  map,\n  mergeMap,\n  observeOn,\n  of,\n  repeat,\n  shareReplay,\n  skip,\n  startWith,\n  takeUntil,\n  tap,\n  withLatestFrom\n} from \"rxjs\"\n\nimport { getElements, watchMedia } from \"~/browser\"\nimport { h } from \"~/utilities\"\n\nimport {\n  Component,\n  getComponentElement\n} from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Palette colors\n */\nexport interface PaletteColor {\n  media?: string                       /* Media query */\n  scheme?: string                      /* Color scheme */\n  primary?: string                     /* Primary color */\n  accent?: string                      /* Accent color */\n}\n\n/**\n * Palette\n */\nexport interface Palette {\n  index: number                        /* Palette index */\n  color: PaletteColor                  /* Palette colors */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch color palette\n *\n * @param inputs - Color palette element\n *\n * @returns Color palette observable\n */\nexport function watchPalette(\n  inputs: HTMLInputElement[]\n): Observable<Palette> {\n  const current = __md_get<Palette>(\"__palette\") || {\n    index: inputs.findIndex(input => matchMedia(\n      input.getAttribute(\"data-md-color-media\")!\n    ).matches)\n  }\n\n  /* Emit changes in color palette */\n  const index = Math.max(0, Math.min(current.index, inputs.length - 1))\n  return of(...inputs)\n    .pipe(\n      mergeMap(input => fromEvent(input, \"change\").pipe(map(() => input))),\n      startWith(inputs[index]),\n      map(input => ({\n        index: inputs.indexOf(input),\n        color: {\n          media:   input.getAttribute(\"data-md-color-media\"),\n          scheme:  input.getAttribute(\"data-md-color-scheme\"),\n          primary: input.getAttribute(\"data-md-color-primary\"),\n          accent:  input.getAttribute(\"data-md-color-accent\")\n        }\n      } as Palette)),\n      shareReplay(1)\n    )\n}\n\n/**\n * Mount color palette\n *\n * @param el - Color palette element\n *\n * @returns Color palette component observable\n */\nexport function mountPalette(\n  el: HTMLElement\n): Observable<Component<Palette>> {\n  const inputs = getElements<HTMLInputElement>(\"input\", el)\n  const meta = h(\"meta\", { name: \"theme-color\" })\n  document.head.appendChild(meta)\n\n  // Add color scheme meta tag\n  const scheme = h(\"meta\", { name: \"color-scheme\" })\n  document.head.appendChild(scheme)\n\n  /* Mount component on subscription */\n  const media$ = watchMedia(\"(prefers-color-scheme: light)\")\n  return defer(() => {\n    const push$ = new Subject<Palette>()\n    push$.subscribe(palette => {\n      document.body.setAttribute(\"data-md-color-switching\", \"\")\n\n      /* Retrieve color palette for system preference */\n      if (palette.color.media === \"(prefers-color-scheme)\") {\n        const media = matchMedia(\"(prefers-color-scheme: light)\")\n        const input = document.querySelector(media.matches\n          ? \"[data-md-color-media='(prefers-color-scheme: light)']\"\n          : \"[data-md-color-media='(prefers-color-scheme: dark)']\"\n        )!\n\n        /* Retrieve colors for system preference */\n        palette.color.scheme  = input.getAttribute(\"data-md-color-scheme\")!\n        palette.color.primary = input.getAttribute(\"data-md-color-primary\")!\n        palette.color.accent  = input.getAttribute(\"data-md-color-accent\")!\n      }\n\n      /* Set color palette */\n      for (const [key, value] of Object.entries(palette.color))\n        document.body.setAttribute(`data-md-color-${key}`, value)\n\n      /* Set toggle visibility */\n      for (let index = 0; index < inputs.length; index++) {\n        const label = inputs[index].nextElementSibling\n        if (label instanceof HTMLElement)\n          label.hidden = palette.index !== index\n      }\n\n      /* Persist preference in local storage */\n      __md_set(\"__palette\", palette)\n    })\n\n    // Handle color switch on Enter or Space - see https://t.ly/YIhVj\n    fromEvent<KeyboardEvent>(el, \"keydown\").pipe(\n      filter(ev => ev.key === \"Enter\"),\n      withLatestFrom(push$, (_, palette) => palette)\n    )\n      .subscribe(({ index }) => {\n        index = (index + 1) % inputs.length\n        inputs[index].click()\n        inputs[index].focus()\n      })\n\n    /* Update theme-color meta tag */\n    push$\n      .pipe(\n        map(() => {\n          const header = getComponentElement(\"header\")\n          const style  = window.getComputedStyle(header)\n\n          // Set color scheme\n          scheme.content = style.colorScheme\n\n          /* Return color in hexadecimal format */\n          return style.backgroundColor.match(/\\d+/g)!\n            .map(value => (+value).toString(16).padStart(2, \"0\"))\n            .join(\"\")\n        })\n      )\n        .subscribe(color => meta.content = `#${color}`)\n\n    /* Revert transition durations after color switch */\n    push$.pipe(observeOn(asyncScheduler))\n      .subscribe(() => {\n        document.body.removeAttribute(\"data-md-color-switching\")\n      })\n\n    /* Create and return component */\n    return watchPalette(inputs)\n      .pipe(\n        takeUntil(media$.pipe(skip(1))),\n        repeat(),\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  defer,\n  finalize,\n  map,\n  tap\n} from \"rxjs\"\n\nimport { Component } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Progress indicator\n */\nexport interface Progress {\n  value: number                        // Progress value\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  progress$: Subject<number>           // Progress subject\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount progress indicator\n *\n * @param el - Progress indicator element\n * @param options - Options\n *\n * @returns Progress indicator component observable\n */\nexport function mountProgress(\n  el: HTMLElement, { progress$ }: MountOptions\n): Observable<Component<Progress>> {\n\n  // Mount component on subscription\n  return defer(() => {\n    const push$ = new Subject<Progress>()\n    push$.subscribe(({ value }) => {\n      el.style.setProperty(\"--md-progress-value\", `${value}`)\n    })\n\n    // Create and return component\n    return progress$\n      .pipe(\n        tap(value => push$.next({ value })),\n        finalize(() => push$.complete()),\n        map(value => ({ ref: el, value }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport ClipboardJS from \"clipboard\"\nimport {\n  Observable,\n  Subject,\n  map,\n  tap\n} from \"rxjs\"\n\nimport { translation } from \"~/_\"\nimport { getElement } from \"~/browser\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Setup options\n */\ninterface SetupOptions {\n  alert$: Subject<string>              /* Alert subject */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Extract text to copy\n *\n * @param el - HTML element\n *\n * @returns Extracted text\n */\nfunction extract(el: HTMLElement): string {\n  el.setAttribute(\"data-md-copying\", \"\")\n  const copy = el.closest(\"[data-copy]\")\n  const text = copy\n    ? copy.getAttribute(\"data-copy\")!\n    : el.innerText\n  el.removeAttribute(\"data-md-copying\")\n  return text.trimEnd()\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Set up Clipboard.js integration\n *\n * @param options - Options\n */\nexport function setupClipboardJS(\n  { alert$ }: SetupOptions\n): void {\n  if (ClipboardJS.isSupported()) {\n    new Observable<ClipboardJS.Event>(subscriber => {\n      new ClipboardJS(\"[data-clipboard-target], [data-clipboard-text]\", {\n        text: el => (\n          el.getAttribute(\"data-clipboard-text\")! ||\n          extract(getElement(\n            el.getAttribute(\"data-clipboard-target\")!\n          ))\n        )\n      })\n        .on(\"success\", ev => subscriber.next(ev))\n    })\n      .pipe(\n        tap(ev => {\n          const trigger = ev.trigger as HTMLElement\n          trigger.focus()\n        }),\n        map(() => translation(\"clipboard.copied\"))\n      )\n        .subscribe(alert$)\n  }\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  catchError,\n  map,\n  of\n} from \"rxjs\"\n\nimport {\n  getElement,\n  getElements,\n  requestXML\n} from \"~/browser\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Sitemap, i.e. a list of URLs\n */\nexport type Sitemap = Map<string, URL[]>\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Resolve URL to the given base URL\n *\n * When serving the site with instant navigation, MkDocs will set the hostname\n * to the value as specified in `dev_addr`, but the browser allows for several\n * hostnames to be used: `localhost`, `127.0.0.1` or even `0.0.0.0`, depending\n * on configuration. This function resolves the URL to the given hostname.\n *\n * @param url - URL\n * @param base - Base URL\n *\n * @returns Resolved URL\n */\nfunction resolve(url: URL, base: URL) {\n  url.protocol = base.protocol\n  url.hostname = base.hostname\n  return url\n}\n\n/**\n * Extract sitemap from document\n *\n * This function extracts the URLs and alternate links from the document, and\n * associates alternate links to the original URL as found in `loc`, allowing\n * the browser to navigate to the correct page when switching languages. The\n * format of the sitemap is expected to adhere to:\n *\n * ``` xml\n * <urlset>\n *   <url>\n *     <loc>...</loc>\n *     <xhtml:link rel=\"alternate\" hreflang=\"en\" href=\"...\"/>\n *     <xhtml:link rel=\"alternate\" hreflang=\"de\" href=\"...\"/>\n *     ...\n *   </url>\n *   ...\n * </urlset>\n * ```\n *\n * @param document - Document\n * @param base - Base URL\n *\n * @returns Sitemap\n */\nfunction extract(document: Document, base: URL): Sitemap {\n  const sitemap: Sitemap = new Map()\n  for (const el of getElements(\"url\", document)) {\n    const url = getElement(\"loc\", el)\n\n    // Create entry for location and add it to the list of links\n    const links = [resolve(new URL(url.textContent!), base)]\n    sitemap.set(`${links[0]}`, links)\n\n    // Attach alternate links to current entry\n    for (const link of getElements(\"[rel=alternate]\", el)) {\n      const href = link.getAttribute(\"href\")\n      if (href != null)\n        links.push(resolve(new URL(href), base))\n    }\n  }\n\n  // Return sitemap\n  return sitemap\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Fetch the sitemap for the given base URL\n *\n * If a network or parsing error occurs, we just default to an empty sitemap,\n * which means the caller should fall back to regular navigation.\n *\n * @param base - Base URL\n *\n * @returns Sitemap observable\n */\nexport function fetchSitemap(base: URL | string): Observable<Sitemap> {\n  return requestXML(new URL(\"sitemap.xml\", base))\n    .pipe(\n      map(document => extract(document, new URL(base))),\n      catchError(() => of(new Map())),\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  Subject,\n  catchError,\n  combineLatestWith,\n  concat,\n  debounceTime,\n  distinctUntilChanged,\n  distinctUntilKeyChanged,\n  endWith,\n  fromEvent,\n  ignoreElements,\n  map,\n  merge,\n  of,\n  share,\n  switchMap,\n  tap,\n  withLatestFrom\n} from \"rxjs\"\n\nimport { configuration, feature } from \"~/_\"\nimport {\n  Viewport,\n  getElements,\n  getLocation,\n  getOptionalElement,\n  requestHTML,\n  setLocation,\n  setLocationHash\n} from \"~/browser\"\nimport { getComponentElement } from \"~/components\"\n\nimport { Sitemap, fetchSitemap } from \"../sitemap\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Setup options\n */\ninterface SetupOptions {\n  location$: Subject<URL>              // Location subject\n  viewport$: Observable<Viewport>      // Viewport observable\n  progress$: Subject<number>           // Progress subject\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Handle clicks on internal URLs while skipping external URLs\n *\n * @param ev - Mouse event\n * @param sitemap - Sitemap\n *\n * @returns URL observable\n */\nfunction handle(\n  ev: MouseEvent, sitemap: Sitemap\n): Observable<URL> {\n  if (!(ev.target instanceof Element))\n    return EMPTY\n\n  // Skip, as target is not within a link - clicks on non-link elements are\n  // also captured, which we need to exclude from processing\n  const el = ev.target.closest(\"a\")\n  if (el === null)\n    return EMPTY\n\n  // Skip, as link opens in new window - we now know we have captured a click\n  // on a link, but the link either has a `target` property defined, or the\n  // user pressed the `meta` or `ctrl` key to open it in a new window. Thus,\n  // we need to filter this event as well.\n  if (el.target || ev.metaKey || ev.ctrlKey)\n    return EMPTY\n\n  // Next, we must check if the URL is relevant for us, i.e., if it's an\n  // internal link to a page that is managed by MkDocs. Only then we can be\n  // sure that the structure of the page to be loaded adheres to the current\n  // document structure and can subsequently be injected into it without doing\n  // a full reload. For this reason, we must canonicalize the URL by removing\n  // all search parameters and hash fragments.\n  const url = new URL(el.href)\n  url.search = url.hash = \"\"\n\n  // Skip, if URL is not included in the sitemap - this could be the case when\n  // linking between versions or languages, or to another page that the author\n  // included as part of the build, but that is not managed by MkDocs. In that\n  // case we must not continue with instant navigation.\n  if (!sitemap.has(`${url}`))\n    return EMPTY\n\n  // We now know that we have a link to an internal page, so we prevent the\n  // browser from navigation and emit the URL for instant navigation. Note that\n  // this also includes anchor links, which means we need to implement anchor\n  // positioning ourselves. The reason for this is that if we wouldn't manage\n  // anchor links as well, scroll restoration will not work correctly (e.g.\n  // following an anchor link and scrolling).\n  ev.preventDefault()\n  return of(new URL(el.href))\n}\n\n/**\n * Create a map of head elements for lookup and replacement\n *\n * @param document - Document\n *\n * @returns Tag map\n */\nfunction head(document: Document): Map<string, HTMLElement> {\n  const tags = new Map<string, HTMLElement>()\n  for (const el of getElements(\":scope > *\", document.head))\n    tags.set(el.outerHTML, el)\n\n  // Return tag map\n  return tags\n}\n\n/**\n * Resolve relative URLs in the given document\n *\n * This function resolves relative `href` and `src` attributes, which can belong\n * to all sorts of tags, like meta tags, links, images, scripts and more.\n *\n * @param document - Document\n *\n * @returns Document observable\n */\nfunction resolve(document: Document): Observable<Document> {\n  for (const el of getElements(\"[href], [src]\", document))\n    for (const key of [\"href\", \"src\"]) {\n      const value = el.getAttribute(key)\n      if (value && !/^(?:[a-z]+:)?\\/\\//i.test(value)) {\n        // @ts-expect-error - trick: self-assign to resolve URL\n        el[key] = el[key]\n        break\n      }\n    }\n\n  // Return document observable\n  return of(document)\n}\n\n/**\n * Inject the contents of a document into the current one\n *\n * @param next - Next document\n *\n * @returns Document observable\n */\nfunction inject(next: Document): Observable<Document> {\n  for (const selector of [\n    \"[data-md-component=announce]\",\n    \"[data-md-component=container]\",\n    \"[data-md-component=header-topic]\",\n    \"[data-md-component=outdated]\",\n    \"[data-md-component=logo]\",\n    \"[data-md-component=skip]\",\n    ...feature(\"navigation.tabs.sticky\")\n      ? [\"[data-md-component=tabs]\"]\n      : []\n  ]) {\n    const source = getOptionalElement(selector)\n    const target = getOptionalElement(selector, next)\n    if (\n      typeof source !== \"undefined\" &&\n      typeof target !== \"undefined\"\n    ) {\n      source.replaceWith(target)\n    }\n  }\n\n  // Update meta tags\n  const tags = head(document)\n  for (const [html, el] of head(next))\n    if (tags.has(html))\n      tags.delete(html)\n    else\n      document.head.appendChild(el)\n\n  // Remove meta tags that are not present in the new document\n  for (const el of tags.values()) {\n    const name = el.getAttribute(\"name\")\n    // @todo - find a better way to handle attributes we add dynamically in\n    // other components without mounting components on every navigation, as\n    // this might impact overall performance - see https://t.ly/ehp_O\n    if (name !== \"theme-color\" && name !== \"color-scheme\")\n      el.remove()\n  }\n\n  // After components and meta tags were replaced, re-evaluate scripts\n  // that were provided by the author as part of Markdown files\n  const container = getComponentElement(\"container\")\n  return concat(getElements(\"script\", container))\n    .pipe(\n      switchMap(el => {\n        const script = next.createElement(\"script\")\n        if (el.src) {\n          for (const name of el.getAttributeNames())\n            script.setAttribute(name, el.getAttribute(name)!)\n          el.replaceWith(script)\n\n          // Complete when script is loaded\n          return new Observable(observer => {\n            script.onload = () => observer.complete()\n          })\n\n        // Complete immediately\n        } else {\n          script.textContent = el.textContent\n          el.replaceWith(script)\n          return EMPTY\n        }\n      }),\n      ignoreElements(),\n      endWith(document)\n    )\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Set up instant navigation\n *\n * This is a heavily orchestrated operation - see inline comments to learn how\n * this works with Material for MkDocs, and how you can hook into it.\n *\n * @param options - Options\n *\n * @returns Document observable\n */\nexport function setupInstantNavigation(\n  { location$, viewport$, progress$ }: SetupOptions\n): Observable<Document> {\n  const config = configuration()\n  if (location.protocol === \"file:\")\n    return EMPTY\n\n  // Load sitemap immediately, so we have it available when the user initiates\n  // the first navigation request without any perceivable delay\n  const sitemap$ = fetchSitemap(config.base)\n\n  // Since we might be on a slow connection, the user might trigger multiple\n  // instant navigation events that overlap. MkDocs produces relative URLs for\n  // all internal links, which becomes a problem in this case, because we need\n  // to change the base URL the moment the user clicks a link that should be\n  // intercepted in order to be consistent with popstate, which means that the\n  // base URL would now be incorrect when resolving another relative link from\n  // the same site. For this reason we always resolve all relative links to\n  // absolute links, so we can be sure this never happens.\n  of(document)\n    .subscribe(resolve)\n\n  // --------------------------------------------------------------------------\n  // Navigation interception\n  // --------------------------------------------------------------------------\n\n  // Intercept navigation - to keep the number of event listeners down we use\n  // the fact that uncaptured events bubble up to the body. This has the nice\n  // property that we don't need to detach and then re-attach event listeners\n  // when the document is replaced after a navigation event.\n  const instant$ =\n    fromEvent<MouseEvent>(document.body, \"click\")\n      .pipe(\n        combineLatestWith(sitemap$),\n        switchMap(([ev, sitemap]) => handle(ev, sitemap)),\n        share()\n      )\n\n  // Intercept history change events, e.g. when the user uses the browser's\n  // back or forward buttons, and emit new location for fetching and parsing\n  const history$ =\n    fromEvent<PopStateEvent>(window, \"popstate\")\n      .pipe(\n        map(getLocation),\n        share()\n      )\n\n  // While it would be better UX to defer navigation events until the document\n  // is fully fetched and parsed, we must schedule it here to synchronize with\n  // popstate events, as they are emitted immediately. Moreover we need to\n  // store the current viewport offset for scroll restoration later on.\n  instant$.pipe(withLatestFrom(viewport$))\n    .subscribe(([url, { offset }]) => {\n      history.replaceState(offset, \"\")\n      history.pushState(null, \"\", url)\n    })\n\n  // Emit URLs that should be fetched via instant navigation on location subject\n  // which was passed into this function. The state of instant navigation can be\n  // intercepted by other parts of the application, which can synchronously back\n  // up or restore state before or after instant navigation happens.\n  merge(instant$, history$)\n    .subscribe(location$)\n\n  // --------------------------------------------------------------------------\n  // Fetching and parsing\n  // --------------------------------------------------------------------------\n\n  // Fetch document - we deduplicate requests to the same location, so we don't\n  // end up with multiple requests for the same page. We use `switchMap`, since\n  // we want to cancel the previous request when a new one is triggered, which\n  // is automatically handled by the observable returned by `request`. This is\n  // essential to ensure a good user experience, as we don't want to load pages\n  // that are not needed anymore, e.g., when the user clicks multiple links in\n  // quick succession or on slow connections. If the request fails for some\n  // reason, we fall back and use regular navigation, forcing a reload.\n  const document$ =\n    location$.pipe(\n      distinctUntilKeyChanged(\"pathname\"),\n      switchMap(url => requestHTML(url, { progress$ })\n        .pipe(\n          catchError(() => {\n            setLocation(url, true)\n            return EMPTY\n          })\n        )\n      ),\n\n      // The document was successfully fetched and parsed, so we can inject its\n      // contents into the currently active document\n      switchMap(resolve),\n      switchMap(inject),\n      share()\n    )\n\n  // --------------------------------------------------------------------------\n  // Scroll restoration\n  // --------------------------------------------------------------------------\n\n  // Handle scroll restoration - we must restore the viewport offset after the\n  // document has been fetched and injected, and every time the user clicks an\n  // anchor that leads to an element on the same page, which might also happen\n  // when the user uses the back or forward button.\n  merge(\n    document$.pipe(withLatestFrom(location$, (_, url) => url)),\n\n    // Handle instant navigation events that are triggered by the user clicking\n    // on an anchor link with a hash fragment different from the current one, as\n    // well as from popstate events, which are emitted when the user navigates\n    // back and forth between pages. We use a two-layered subscription to scope\n    // the scroll restoration to the current page, as we don't need to restore\n    // the viewport offset when the user navigates to a different page, as this\n    // is already handled by the previous observable.\n    document$.pipe(\n      switchMap(() => location$),\n      distinctUntilKeyChanged(\"pathname\"),\n      switchMap(() => location$),\n      distinctUntilKeyChanged(\"hash\")\n    ),\n\n    // Handle instant navigation events that are triggered by the user clicking\n    // on an anchor link with the same hash fragment as the current one in the\n    // URL. It is essential that we only intercept those from instant navigation\n    // events and not from history change events, or we'll end up in and endless\n    // loop. The top-level history entry must be removed, as it will be replaced\n    // with a new one, which would otherwise lead to a duplicate entry.\n    location$.pipe(\n      distinctUntilChanged((a, b) => (\n        a.pathname === b.pathname &&\n        a.hash     === b.hash\n      )),\n      switchMap(() => instant$),\n      tap(() => history.back())\n    )\n  )\n    .subscribe(url => {\n\n      // Check if the current history entry has a state, which happens when the\n      // user presses the back or forward button to visit a page we've already\n      // seen. If there's no state, it means a new page was visited and we must\n      // scroll to the top, unless an anchor is given.\n      if (history.state !== null || !url.hash) {\n        window.scrollTo(0, history.state?.y ?? 0)\n      } else {\n        history.scrollRestoration = \"auto\"\n        setLocationHash(url.hash)\n        history.scrollRestoration = \"manual\"\n      }\n    })\n\n  // Disable scroll restoration when an instant navigation event occurs, so the\n  // browser does not immediately set the viewport offset to the prior history\n  // entry, scrolling to the position on the same page, which would look odd.\n  // Instead, we manually restore the position once the page has loaded.\n  location$.subscribe(() => {\n    history.scrollRestoration = \"manual\"\n  })\n\n  // Enable scroll restoration before window unloads - this is essential to\n  // ensure that full reloads (F5) restore the viewport offset correctly. If\n  // only popstate events wouldn't reset the viewport offset prior to their\n  // emission, we could just reset this in popstate. Meh.\n  fromEvent(window, \"beforeunload\")\n    .subscribe(() => {\n      history.scrollRestoration = \"auto\"\n    })\n\n  // Track viewport offset, so we can restore it when the user navigates back\n  // and forth between pages. Note that this must be debounced and cannot be\n  // done in popstate, as popstate has already removed the entry from the\n  // history, which means it is too late.\n  viewport$.pipe(\n    distinctUntilKeyChanged(\"offset\"),\n    debounceTime(100)\n  )\n    .subscribe(({ offset }) => {\n      history.replaceState(offset, \"\")\n    })\n\n  // Return document observable\n  return document$\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport escapeHTML from \"escape-html\"\n\nimport { SearchConfig } from \"../config\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Search highlight function\n *\n * @param value - Value\n *\n * @returns Highlighted value\n */\nexport type SearchHighlightFn = (value: string) => string\n\n/**\n * Search highlight factory function\n *\n * @param query - Query value\n *\n * @returns Search highlight function\n */\nexport type SearchHighlightFactoryFn = (query: string) => SearchHighlightFn\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Create a search highlighter\n *\n * @param config - Search configuration\n *\n * @returns Search highlight factory function\n */\nexport function setupSearchHighlighter(\n  config: SearchConfig\n): SearchHighlightFactoryFn {\n  // Hack: temporarily remove pure lookaheads and lookbehinds\n  const regex = config.separator.split(\"|\").map(term => {\n    const temp = term.replace(/(\\(\\?[!=<][^)]+\\))/g, \"\")\n    return temp.length === 0 ? \"\uFFFD\" : term\n  })\n    .join(\"|\")\n\n  const separator = new RegExp(regex, \"img\")\n  const highlight = (_: unknown, data: string, term: string) => {\n    return `${data}<mark data-md-highlight>${term}</mark>`\n  }\n\n  /* Return factory function */\n  return (query: string) => {\n    query = query\n      .replace(/[\\s*+\\-:~^]+/g, \" \")\n      .trim()\n\n    /* Create search term match expression */\n    const match = new RegExp(`(^|${config.separator}|)(${\n      query\n        .replace(/[|\\\\{}()[\\]^$+*?.-]/g, \"\\\\$&\")\n        .replace(separator, \"|\")\n    })`, \"img\")\n\n    /* Highlight string value */\n    return value => escapeHTML(value)\n      .replace(match, highlight)\n      .replace(/<\\/mark>(\\s+)<mark[^>]*>/img, \"$1\")\n  }\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A RTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { SearchResult } from \"../../_\"\nimport { SearchIndex } from \"../../config\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Search message type\n */\nexport const enum SearchMessageType {\n  SETUP,                               /* Search index setup */\n  READY,                               /* Search index ready */\n  QUERY,                               /* Search query */\n  RESULT                               /* Search results */\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Message containing the data necessary to setup the search index\n */\nexport interface SearchSetupMessage {\n  type: SearchMessageType.SETUP        /* Message type */\n  data: SearchIndex                    /* Message data */\n}\n\n/**\n * Message indicating the search index is ready\n */\nexport interface SearchReadyMessage {\n  type: SearchMessageType.READY        /* Message type */\n}\n\n/**\n * Message containing a search query\n */\nexport interface SearchQueryMessage {\n  type: SearchMessageType.QUERY        /* Message type */\n  data: string                         /* Message data */\n}\n\n/**\n * Message containing results for a search query\n */\nexport interface SearchResultMessage {\n  type: SearchMessageType.RESULT       /* Message type */\n  data: SearchResult                   /* Message data */\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Message exchanged with the search worker\n */\nexport type SearchMessage =\n  | SearchSetupMessage\n  | SearchReadyMessage\n  | SearchQueryMessage\n  | SearchResultMessage\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Type guard for search ready messages\n *\n * @param message - Search worker message\n *\n * @returns Test result\n */\nexport function isSearchReadyMessage(\n  message: SearchMessage\n): message is SearchReadyMessage {\n  return message.type === SearchMessageType.READY\n}\n\n/**\n * Type guard for search result messages\n *\n * @param message - Search worker message\n *\n * @returns Test result\n */\nexport function isSearchResultMessage(\n  message: SearchMessage\n): message is SearchResultMessage {\n  return message.type === SearchMessageType.RESULT\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A RTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  ObservableInput,\n  Subject,\n  first,\n  merge,\n  of,\n  switchMap\n} from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport { watchToggle, watchWorker } from \"~/browser\"\n\nimport { SearchIndex } from \"../../config\"\nimport {\n  SearchMessage,\n  SearchMessageType\n} from \"../message\"\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Set up search worker\n *\n * This function creates and initializes a web worker that is used for search,\n * so that the user interface doesn't freeze. In general, the application does\n * not care how search is implemented, as long as the web worker conforms to\n * the format expected by the application as defined in `SearchMessage`. This\n * allows the author to implement custom search functionality, by providing a\n * custom web worker via configuration.\n *\n * Material for MkDocs' built-in search implementation makes use of Lunr.js, an\n * efficient and fast implementation for client-side search. Leveraging a tiny\n * iframe-based web worker shim, search is even supported for the `file://`\n * protocol, enabling search for local non-hosted builds.\n *\n * If the protocol is `file://`, search initialization is deferred to mitigate\n * freezing, as it's now synchronous by design - see https://bit.ly/3C521EO\n *\n * @see https://bit.ly/3igvtQv - How to implement custom search\n *\n * @param url - Worker URL\n * @param index$ - Search index observable input\n *\n * @returns Search worker\n */\nexport function setupSearchWorker(\n  url: string, index$: ObservableInput<SearchIndex>\n): Subject<SearchMessage> {\n  const worker$ = watchWorker<SearchMessage>(url)\n  merge(\n    of(location.protocol !== \"file:\"),\n    watchToggle(\"search\")\n  )\n    .pipe(\n      first(active => active),\n      switchMap(() => index$)\n    )\n      .subscribe(({ config, docs }) => worker$.next({\n        type: SearchMessageType.SETUP,\n        data: {\n          config,\n          docs,\n          options: {\n            suggest: feature(\"search.suggest\")\n          }\n        }\n      }))\n\n  /* Return search worker */\n  return worker$\n}\n", "import { Sitemap } from \"../../sitemap\"\n\n/** See docstring for `selectedVersionCorrespondingURL` for the meaning of these fields. */\ntype CorrespondingURLParams = {\n  selectedVersionSitemap: Sitemap\n  selectedVersionBaseURL: URL\n  currentLocation: URL\n  currentBaseURL: string\n}\n\n/**\n * Choose a URL to navigate to when the user chooses a version in the version\n * selector.\n *\n * The parameters in `params` are named as follows, in order to make it clearer\n * which parameter means what when invoking the function:\n *\n *  - selectedVersionSitemap: Sitemap - as obtained by fetchSitemap from `${selectedVersionBaseURL}/sitemap.xml`\n *\n *  - selectedVersionBaseURL: URL - usually `${currentBaseURL}/../selectedVersion`\n *\n *  - currentLocation: URL - current web browser location\n *\n *  - currentBaseURL: string - as obtained from `config.base`\n *\n * @param params - arguments with the meanings explained above.\n * @returns the URL to navigate to or null if we can't be sure that the\n * corresponding page to the current page exists in the selected version\n */\nexport function selectedVersionCorrespondingURL(\n  params: CorrespondingURLParams\n): URL | undefined {\n  const {selectedVersionSitemap,\n    selectedVersionBaseURL,\n    currentLocation,\n    currentBaseURL} = params\n  const current_path = safeURLParse(currentBaseURL)?.pathname\n  if (current_path === undefined) {\n    return\n  }\n  const currentRelativePath = stripPrefix(currentLocation.pathname, current_path)\n  if (currentRelativePath === undefined) {\n    return\n  }\n  const sitemapCommonPrefix = shortestCommonPrefix(selectedVersionSitemap.keys())\n  if (!selectedVersionSitemap.has(sitemapCommonPrefix)) {\n    // We could also check that `commonSitemapPrefix` ends in the canonical version,\n    // similarly to https://github.com/squidfunk/mkdocs-material/pull/7227. However,\n    // I don't believe that Mike/MkDocs ever generate sitemaps where it would matter\n    return\n  }\n\n  const potentialSitemapURL = safeURLParse(currentRelativePath, sitemapCommonPrefix)\n  if (!potentialSitemapURL || !selectedVersionSitemap.has(potentialSitemapURL.href)) {\n    return\n  }\n\n  const result = safeURLParse(currentRelativePath, selectedVersionBaseURL)\n  if (!result) {\n    return\n  }\n  result.hash = currentLocation.hash\n  result.search = currentLocation.search\n  return result\n}\n\n/**\n * A version of `new URL` that never throws. A polyfill for URL.parse() which is\n * not yet ubuquitous.\n *\n * @param url - passed to `new URL` constructor\n * @param base - passed to `new URL` constructor\n *\n * @returns `new URL(url, base)` or undefined if the URL is invalid.\n */\nfunction safeURLParse(url: string|URL, base?: string|URL): URL | undefined {\n  try {\n    return new URL(url, base)\n  } catch {\n    return\n  }\n}\n\n// Basic string manipulation\n\n/** Strip a given prefix from a function\n *\n * @param s - string\n * @param prefix - prefix to strip\n *\n * @returns either the string with the prefix stripped or undefined if the\n * string did not begin with the prefix.\n */\nexport function stripPrefix(s: string, prefix: string): string | undefined {\n  if (s.startsWith(prefix)) {\n    return s.slice(prefix.length)\n  }\n  return undefined\n}\n\n/** Find the length of the longest common prefix of two strings\n *\n * @param s1 - first string\n * @param s2 - second string\n *\n * @returns - the length of the longest common prefix of the two strings.\n */\nfunction commonPrefixLen(s1: string, s2: string): number {\n  const max = Math.min(s1.length, s2.length)\n  let result\n  for (result = 0; result < max; ++result) {\n    if (s1[result] !== s2[result]) {\n      break\n    }\n  }\n  return result\n}\n\n/** Find the longest common prefix of any number of strings\n *\n * @param strs - an iterable of strings\n *\n * @returns the longest common prefix of all the strings\n */\nexport function shortestCommonPrefix(strs: Iterable<string>): string {\n  let result  // Undefined if no iterations happened\n  for (const s of strs) {\n    if (result === undefined) {\n      result = s\n    } else {\n      result = result.slice(0, commonPrefixLen(result, s))\n    }\n  }\n  return result ?? \"\"\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Subject,\n  catchError,\n  combineLatest,\n  filter,\n  fromEvent,\n  map,\n  of,\n  switchMap,\n  withLatestFrom\n} from \"rxjs\"\n\nimport { configuration } from \"~/_\"\nimport {\n  getElement,\n  getLocation,\n  requestJSON,\n  setLocation\n} from \"~/browser\"\nimport { getComponentElements } from \"~/components\"\nimport {\n  Version,\n  renderVersionSelector\n} from \"~/templates\"\n\nimport { fetchSitemap } from \"../sitemap\"\n\nimport { selectedVersionCorrespondingURL } from \"./findurl\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Setup options\n */\ninterface SetupOptions {\n  document$: Subject<Document>         /* Document subject */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Set up version selector\n *\n * @param options - Options\n */\nexport function setupVersionSelector(\n  { document$ }: SetupOptions\n): void {\n  const config = configuration()\n  const versions$ = requestJSON<Version[]>(\n    new URL(\"../versions.json\", config.base)\n  )\n    .pipe(\n      catchError(() => EMPTY) // @todo refactor instant loading\n    )\n\n  /* Determine current version */\n  const current$ = versions$\n    .pipe(\n      map(versions => {\n        const [, current] = config.base.match(/([^/]+)\\/?$/)!\n        return versions.find(({ version, aliases }) => (\n          version === current || aliases.includes(current)\n        )) || versions[0]\n      })\n    )\n\n  /* Intercept inter-version navigation */\n  versions$\n    .pipe(\n      map(versions => new Map(versions.map(version => [\n        `${new URL(`../${version.version}/`, config.base)}`,\n        version\n      ]))),\n      switchMap(urls => fromEvent<MouseEvent>(document.body, \"click\")\n        .pipe(\n          filter(ev => !ev.metaKey && !ev.ctrlKey),\n          withLatestFrom(current$),\n          switchMap(([ev, current]) => {\n            if (ev.target instanceof Element) {\n              const el = ev.target.closest(\"a\")\n              if (el && !el.target && urls.has(el.href)) {\n                const url = el.href\n                // This is a temporary hack to detect if a version inside the\n                // version selector or on another part of the site was clicked.\n                // If we're inside the version selector, we definitely want to\n                // find the same page, as we might have different deployments\n                // due to aliases. However, if we're outside the version\n                // selector, we must abort here, because we might otherwise\n                // interfere with instant navigation. We need to refactor this\n                // at some point together with instant navigation.\n                //\n                // See https://github.com/squidfunk/mkdocs-material/issues/4012\n                if (!ev.target.closest(\".md-version\")) {\n                  const version = urls.get(url)!\n                  if (version === current)\n                    return EMPTY\n                }\n                ev.preventDefault()\n                return of(new URL(url))\n              }\n            }\n            return EMPTY\n          }),\n          switchMap(selectedVersionBaseURL => {\n            return fetchSitemap(selectedVersionBaseURL).pipe(\n              map(\n                sitemap =>\n                  selectedVersionCorrespondingURL({\n                    selectedVersionSitemap: sitemap,\n                    selectedVersionBaseURL,\n                    currentLocation: getLocation(),\n                    currentBaseURL: config.base\n                  }) ?? selectedVersionBaseURL,\n              ),\n            )\n          })\n        )\n      )\n    )\n      .subscribe(url => setLocation(url, true))\n\n  /* Render version selector and warning */\n  combineLatest([versions$, current$])\n    .subscribe(([versions, current]) => {\n      const topic = getElement(\".md-header__topic\")\n      topic.appendChild(renderVersionSelector(versions, current))\n    })\n\n  /* Integrate outdated version banner with instant navigation */\n  document$.pipe(switchMap(() => current$))\n    .subscribe(current => {\n\n      /* Check if version state was already determined */\n      let outdated = __md_get(\"__outdated\", sessionStorage)\n      if (outdated === null) {\n        outdated = true\n\n        /* Obtain and normalize default versions */\n        let ignored = config.version?.default || \"latest\"\n        if (!Array.isArray(ignored))\n          ignored = [ignored]\n\n        /* Check if version is considered a default */\n        main: for (const ignore of ignored)\n          for (const version of current.aliases.concat(current.version))\n            if (new RegExp(ignore, \"i\").test(version)) {\n              outdated = false\n              break main\n            }\n\n        /* Persist version state in session storage */\n        __md_set(\"__outdated\", outdated, sessionStorage)\n      }\n\n      /* Unhide outdated version banner */\n      if (outdated)\n        for (const warning of getComponentElements(\"outdated\"))\n          warning.hidden = false\n    })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  combineLatest,\n  distinctUntilChanged,\n  distinctUntilKeyChanged,\n  endWith,\n  finalize,\n  first,\n  fromEvent,\n  ignoreElements,\n  map,\n  merge,\n  shareReplay,\n  takeUntil,\n  tap\n} from \"rxjs\"\n\nimport {\n  getElement,\n  getLocation,\n  setToggle,\n  watchElementFocus,\n  watchToggle\n} from \"~/browser\"\nimport {\n  SearchMessage,\n  SearchMessageType,\n  isSearchReadyMessage\n} from \"~/integrations\"\n\nimport { Component } from \"../../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Search query\n */\nexport interface SearchQuery {\n  value: string                        /* Query value */\n  focus: boolean                       /* Query focus */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  worker$: Subject<SearchMessage>      /* Search worker */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  worker$: Subject<SearchMessage>      /* Search worker */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch search query\n *\n * Note that the focus event which triggers re-reading the current query value\n * is delayed by `1ms` so the input's empty state is allowed to propagate.\n *\n * @param el - Search query element\n * @param options - Options\n *\n * @returns Search query observable\n */\nexport function watchSearchQuery(\n  el: HTMLInputElement, { worker$ }: WatchOptions\n): Observable<SearchQuery> {\n\n  /* Support search deep linking */\n  const { searchParams } = getLocation()\n  if (searchParams.has(\"q\")) {\n    setToggle(\"search\", true)\n\n    /* Set query from parameter */\n    el.value = searchParams.get(\"q\")!\n    el.focus()\n\n    /* Remove query parameter on close */\n    watchToggle(\"search\")\n      .pipe(\n        first(active => !active)\n      )\n        .subscribe(() => {\n          const url = getLocation()\n          url.searchParams.delete(\"q\")\n          history.replaceState({}, \"\", `${url}`)\n        })\n  }\n\n  /* Intercept focus and input events */\n  const focus$ = watchElementFocus(el)\n  const value$ = merge(\n    worker$.pipe(first(isSearchReadyMessage)),\n    fromEvent(el, \"keyup\"),\n    focus$\n  )\n    .pipe(\n      map(() => el.value),\n      distinctUntilChanged()\n    )\n\n  /* Combine into single observable */\n  return combineLatest([value$, focus$])\n    .pipe(\n      map(([value, focus]) => ({ value, focus })),\n      shareReplay(1)\n    )\n}\n\n/**\n * Mount search query\n *\n * @param el - Search query element\n * @param options - Options\n *\n * @returns Search query component observable\n */\nexport function mountSearchQuery(\n  el: HTMLInputElement, { worker$ }: MountOptions\n): Observable<Component<SearchQuery, HTMLInputElement>> {\n  const push$ = new Subject<SearchQuery>()\n  const done$ = push$.pipe(ignoreElements(), endWith(true))\n\n  /* Handle value change */\n  combineLatest([\n    worker$.pipe(first(isSearchReadyMessage)),\n    push$\n  ], (_, query) => query)\n    .pipe(\n      distinctUntilKeyChanged(\"value\")\n    )\n      .subscribe(({ value }) => worker$.next({\n        type: SearchMessageType.QUERY,\n        data: value\n      }))\n\n  /* Handle focus change */\n  push$\n    .pipe(\n      distinctUntilKeyChanged(\"focus\")\n    )\n      .subscribe(({ focus }) => {\n        if (focus)\n          setToggle(\"search\", focus)\n      })\n\n  /* Handle reset */\n  fromEvent(el.form!, \"reset\")\n    .pipe(\n      takeUntil(done$)\n    )\n      .subscribe(() => el.focus())\n\n  // Focus search query on label click - note that this is necessary to bring\n  // up the keyboard on iOS and other mobile platforms, as the search dialog is\n  // not visible at first, and programatically focusing an input element must\n  // be triggered by a user interaction - see https://t.ly/Cb30n\n  const label = getElement(\"header [for=__search]\")\n  fromEvent(label, \"click\")\n    .subscribe(() => el.focus())\n\n  /* Create and return component */\n  return watchSearchQuery(el, { worker$ })\n    .pipe(\n      tap(state => push$.next(state)),\n      finalize(() => push$.complete()),\n      map(state => ({ ref: el, ...state })),\n      shareReplay(1)\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  Subject,\n  bufferCount,\n  filter,\n  finalize,\n  first,\n  fromEvent,\n  map,\n  merge,\n  mergeMap,\n  of,\n  share,\n  skipUntil,\n  switchMap,\n  takeUntil,\n  tap,\n  withLatestFrom,\n  zipWith\n} from \"rxjs\"\n\nimport { translation } from \"~/_\"\nimport {\n  getElement,\n  getOptionalElement,\n  watchElementBoundary,\n  watchToggle\n} from \"~/browser\"\nimport {\n  SearchMessage,\n  SearchResult,\n  isSearchReadyMessage,\n  isSearchResultMessage\n} from \"~/integrations\"\nimport { renderSearchResultItem } from \"~/templates\"\nimport { round } from \"~/utilities\"\n\nimport { Component } from \"../../_\"\nimport { SearchQuery } from \"../query\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  query$: Observable<SearchQuery>      /* Search query observable */\n  worker$: Subject<SearchMessage>      /* Search worker */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount search result list\n *\n * This function performs a lazy rendering of the search results, depending on\n * the vertical offset of the search result container.\n *\n * @param el - Search result list element\n * @param options - Options\n *\n * @returns Search result list component observable\n */\nexport function mountSearchResult(\n  el: HTMLElement, { worker$, query$ }: MountOptions\n): Observable<Component<SearchResult>> {\n  const push$ = new Subject<SearchResult>()\n  const boundary$ = watchElementBoundary(el.parentElement!)\n    .pipe(\n      filter(Boolean)\n    )\n\n  /* Retrieve container */\n  const container = el.parentElement!\n\n  /* Retrieve nested components */\n  const meta = getElement(\":scope > :first-child\", el)\n  const list = getElement(\":scope > :last-child\", el)\n\n  /* Reveal to accessibility tree \u2013 see https://bit.ly/3iAA7t8 */\n  watchToggle(\"search\")\n    .subscribe(active => list.setAttribute(\n      \"role\", active ? \"list\" : \"presentation\"\n    ))\n\n  /* Update search result metadata */\n  push$\n    .pipe(\n      withLatestFrom(query$),\n      skipUntil(worker$.pipe(first(isSearchReadyMessage)))\n    )\n      .subscribe(([{ items }, { value }]) => {\n        switch (items.length) {\n\n          /* No results */\n          case 0:\n            meta.textContent = value.length\n              ? translation(\"search.result.none\")\n              : translation(\"search.result.placeholder\")\n            break\n\n          /* One result */\n          case 1:\n            meta.textContent = translation(\"search.result.one\")\n            break\n\n          /* Multiple result */\n          default:\n            const count = round(items.length)\n            meta.textContent = translation(\"search.result.other\", count)\n        }\n      })\n\n  /* Render search result item */\n  const render$ = push$\n    .pipe(\n      tap(() => list.innerHTML = \"\"),\n      switchMap(({ items }) => merge(\n        of(...items.slice(0, 10)),\n        of(...items.slice(10))\n          .pipe(\n            bufferCount(4),\n            zipWith(boundary$),\n            switchMap(([chunk]) => chunk)\n          )\n      )),\n      map(renderSearchResultItem),\n      share()\n    )\n\n  /* Update search result list */\n  render$.subscribe(item => list.appendChild(item))\n  render$\n    .pipe(\n      mergeMap(item => {\n        const details = getOptionalElement(\"details\", item)\n        if (typeof details === \"undefined\")\n          return EMPTY\n\n        /* Keep position of details element stable */\n        return fromEvent(details, \"toggle\")\n          .pipe(\n            takeUntil(push$),\n            map(() => details)\n          )\n      })\n    )\n      .subscribe(details => {\n        if (\n          details.open === false &&\n          details.offsetTop <= container.scrollTop\n        )\n          container.scrollTo({ top: details.offsetTop })\n      })\n\n  /* Filter search result message */\n  const result$ = worker$\n    .pipe(\n      filter(isSearchResultMessage),\n      map(({ data }) => data)\n    )\n\n  /* Create and return component */\n  return result$\n    .pipe(\n      tap(state => push$.next(state)),\n      finalize(() => push$.complete()),\n      map(state => ({ ref: el, ...state }))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  endWith,\n  finalize,\n  fromEvent,\n  ignoreElements,\n  map,\n  takeUntil,\n  tap\n} from \"rxjs\"\n\nimport { getLocation } from \"~/browser\"\n\nimport { Component } from \"../../_\"\nimport { SearchQuery } from \"../query\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Search sharing\n */\nexport interface SearchShare {\n  url: URL                             /* Deep link for sharing */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  query$: Observable<SearchQuery>      /* Search query observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  query$: Observable<SearchQuery>      /* Search query observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount search sharing\n *\n * @param _el - Search sharing element\n * @param options - Options\n *\n * @returns Search sharing observable\n */\nexport function watchSearchShare(\n  _el: HTMLElement, { query$ }: WatchOptions\n): Observable<SearchShare> {\n  return query$\n    .pipe(\n      map(({ value }) => {\n        const url = getLocation()\n        url.hash = \"\"\n\n        /* Compute readable query strings */\n        value = value\n          .replace(/\\s+/g, \"+\")        /* Collapse whitespace */\n          .replace(/&/g, \"%26\")        /* Escape '&' character */\n          .replace(/=/g, \"%3D\")        /* Escape '=' character */\n\n        /* Replace query string */\n        url.search = `q=${value}`\n        return { url }\n      })\n    )\n}\n\n/**\n * Mount search sharing\n *\n * @param el - Search sharing element\n * @param options - Options\n *\n * @returns Search sharing component observable\n */\nexport function mountSearchShare(\n  el: HTMLAnchorElement, options: MountOptions\n): Observable<Component<SearchShare>> {\n  const push$ = new Subject<SearchShare>()\n  const done$ = push$.pipe(ignoreElements(), endWith(true))\n  push$.subscribe(({ url }) => {\n    el.setAttribute(\"data-clipboard-text\", el.href)\n    el.href = `${url}`\n  })\n\n  /* Prevent following of link */\n  fromEvent(el, \"click\")\n    .pipe(\n      takeUntil(done$)\n    )\n      .subscribe(ev => ev.preventDefault())\n\n  /* Create and return component */\n  return watchSearchShare(el, options)\n    .pipe(\n      tap(state => push$.next(state)),\n      finalize(() => push$.complete()),\n      map(state => ({ ref: el, ...state }))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  asyncScheduler,\n  combineLatestWith,\n  distinctUntilChanged,\n  filter,\n  finalize,\n  fromEvent,\n  map,\n  merge,\n  observeOn,\n  tap\n} from \"rxjs\"\n\nimport { Keyboard } from \"~/browser\"\nimport {\n  SearchMessage,\n  SearchResult,\n  isSearchResultMessage\n} from \"~/integrations\"\n\nimport { Component, getComponentElement } from \"../../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Search suggestions\n */\nexport interface SearchSuggest {}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  keyboard$: Observable<Keyboard>      /* Keyboard observable */\n  worker$: Subject<SearchMessage>      /* Search worker */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount search suggestions\n *\n * This function will perform a lazy rendering of the search results, depending\n * on the vertical offset of the search result container.\n *\n * @param el - Search result list element\n * @param options - Options\n *\n * @returns Search result list component observable\n */\nexport function mountSearchSuggest(\n  el: HTMLElement, { worker$, keyboard$ }: MountOptions\n): Observable<Component<SearchSuggest>> {\n  const push$ = new Subject<SearchResult>()\n\n  /* Retrieve query component and track all changes */\n  const query  = getComponentElement(\"search-query\")\n  const query$ = merge(\n    fromEvent(query, \"keydown\"),\n    fromEvent(query, \"focus\")\n  )\n    .pipe(\n      observeOn(asyncScheduler),\n      map(() => query.value),\n      distinctUntilChanged(),\n    )\n\n  /* Update search suggestions */\n  push$\n    .pipe(\n      combineLatestWith(query$),\n      map(([{ suggest }, value]) => {\n        const words = value.split(/([\\s-]+)/)\n        if (suggest?.length && words[words.length - 1]) {\n          const last = suggest[suggest.length - 1]\n          if (last.startsWith(words[words.length - 1]))\n            words[words.length - 1] = last\n        } else {\n          words.length = 0\n        }\n        return words\n      })\n    )\n      .subscribe(words => el.innerHTML = words\n        .join(\"\")\n        .replace(/\\s/g, \"&nbsp;\")\n      )\n\n  /* Set up search keyboard handlers */\n  keyboard$\n    .pipe(\n      filter(({ mode }) => mode === \"search\")\n    )\n      .subscribe(key => {\n        switch (key.type) {\n\n          /* Right arrow: accept current suggestion */\n          case \"ArrowRight\":\n            if (\n              el.innerText.length &&\n              query.selectionStart === query.value.length\n            )\n              query.value = el.innerText\n            break\n        }\n      })\n\n  /* Filter search result message */\n  const result$ = worker$\n    .pipe(\n      filter(isSearchResultMessage),\n      map(({ data }) => data)\n    )\n\n  /* Create and return component */\n  return result$\n    .pipe(\n      tap(state => push$.next(state)),\n      finalize(() => push$.complete()),\n      map(() => ({ ref: el }))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  NEVER,\n  Observable,\n  ObservableInput,\n  filter,\n  fromEvent,\n  merge,\n  mergeWith\n} from \"rxjs\"\n\nimport { configuration } from \"~/_\"\nimport {\n  Keyboard,\n  getActiveElement,\n  getElements,\n  setToggle\n} from \"~/browser\"\nimport {\n  SearchIndex,\n  SearchResult,\n  setupSearchWorker\n} from \"~/integrations\"\n\nimport {\n  Component,\n  getComponentElement,\n  getComponentElements\n} from \"../../_\"\nimport {\n  SearchQuery,\n  mountSearchQuery\n} from \"../query\"\nimport { mountSearchResult } from \"../result\"\nimport {\n  SearchShare,\n  mountSearchShare\n} from \"../share\"\nimport {\n  SearchSuggest,\n  mountSearchSuggest\n} from \"../suggest\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Search\n */\nexport type Search =\n  | SearchQuery\n  | SearchResult\n  | SearchShare\n  | SearchSuggest\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  index$: ObservableInput<SearchIndex> /* Search index observable */\n  keyboard$: Observable<Keyboard>      /* Keyboard observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount search\n *\n * This function sets up the search functionality, including the underlying\n * web worker and all keyboard bindings.\n *\n * @param el - Search element\n * @param options - Options\n *\n * @returns Search component observable\n */\nexport function mountSearch(\n  el: HTMLElement, { index$, keyboard$ }: MountOptions\n): Observable<Component<Search>> {\n  const config = configuration()\n  try {\n    const worker$ = setupSearchWorker(config.search, index$)\n\n    /* Retrieve query and result components */\n    const query  = getComponentElement(\"search-query\", el)\n    const result = getComponentElement(\"search-result\", el)\n\n    /* Always close search on result selection */\n    fromEvent<PointerEvent>(el, \"click\")\n      .pipe(\n        filter(({ target }) => (\n          target instanceof Element && !!target.closest(\"a\")\n        ))\n      )\n        .subscribe(() => setToggle(\"search\", false))\n\n    /* Set up search keyboard handlers */\n    keyboard$\n      .pipe(\n        filter(({ mode }) => mode === \"search\")\n      )\n        .subscribe(key => {\n          const active = getActiveElement()\n          switch (key.type) {\n\n            /* Enter: go to first (best) result */\n            case \"Enter\":\n              if (active === query) {\n                const anchors = new Map<HTMLAnchorElement, number>()\n                for (const anchor of getElements<HTMLAnchorElement>(\n                  \":first-child [href]\", result\n                )) {\n                  const article = anchor.firstElementChild!\n                  anchors.set(anchor, parseFloat(\n                    article.getAttribute(\"data-md-score\")!\n                  ))\n                }\n\n                /* Go to result with highest score, if any */\n                if (anchors.size) {\n                  const [[best]] = [...anchors].sort(([, a], [, b]) => b - a)\n                  best.click()\n                }\n\n                /* Otherwise omit form submission */\n                key.claim()\n              }\n              break\n\n            /* Escape or Tab: close search */\n            case \"Escape\":\n            case \"Tab\":\n              setToggle(\"search\", false)\n              query.blur()\n              break\n\n            /* Vertical arrows: select previous or next search result */\n            case \"ArrowUp\":\n            case \"ArrowDown\":\n              if (typeof active === \"undefined\") {\n                query.focus()\n              } else {\n                const els = [query, ...getElements(\n                  \":not(details) > [href], summary, details[open] [href]\",\n                  result\n                )]\n                const i = Math.max(0, (\n                  Math.max(0, els.indexOf(active)) + els.length + (\n                    key.type === \"ArrowUp\" ? -1 : +1\n                  )\n                ) % els.length)\n                els[i].focus()\n              }\n\n              /* Prevent scrolling of page */\n              key.claim()\n              break\n\n            /* All other keys: hand to search query */\n            default:\n              if (query !== getActiveElement())\n                query.focus()\n          }\n        })\n\n    /* Set up global keyboard handlers */\n    keyboard$\n      .pipe(\n        filter(({ mode }) => mode === \"global\")\n      )\n        .subscribe(key => {\n          switch (key.type) {\n\n            /* Open search and select query */\n            case \"f\":\n            case \"s\":\n            case \"/\":\n              query.focus()\n              query.select()\n\n              /* Prevent scrolling of page */\n              key.claim()\n              break\n          }\n        })\n\n    /* Create and return component */\n    const query$ = mountSearchQuery(query, { worker$ })\n    return merge(\n      query$,\n      mountSearchResult(result, { worker$, query$ })\n    )\n      .pipe(\n        mergeWith(\n\n          /* Search sharing */\n          ...getComponentElements(\"search-share\", el)\n            .map(child => mountSearchShare(child, { query$ })),\n\n          /* Search suggestions */\n          ...getComponentElements(\"search-suggest\", el)\n            .map(child => mountSearchSuggest(child, { worker$, keyboard$ }))\n        )\n      )\n\n  /* Gracefully handle broken search */\n  } catch (err) {\n    el.hidden = true\n    return NEVER\n  }\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  ObservableInput,\n  combineLatest,\n  filter,\n  map,\n  startWith\n} from \"rxjs\"\n\nimport { getLocation } from \"~/browser\"\nimport {\n  SearchIndex,\n  setupSearchHighlighter\n} from \"~/integrations\"\nimport { h } from \"~/utilities\"\n\nimport { Component } from \"../../_\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Search highlighting\n */\nexport interface SearchHighlight {\n  nodes: Map<ChildNode, string>        /* Map of replacements */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  index$: ObservableInput<SearchIndex> /* Search index observable */\n  location$: Observable<URL>           /* Location observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Mount search highlighting\n *\n * @param el - Content element\n * @param options - Options\n *\n * @returns Search highlighting component observable\n */\nexport function mountSearchHiglight(\n  el: HTMLElement, { index$, location$ }: MountOptions\n): Observable<Component<SearchHighlight>> {\n  return combineLatest([\n    index$,\n    location$\n      .pipe(\n        startWith(getLocation()),\n        filter(url => !!url.searchParams.get(\"h\"))\n      )\n  ])\n    .pipe(\n      map(([index, url]) => setupSearchHighlighter(index.config)(\n        url.searchParams.get(\"h\")!\n      )),\n      map(fn => {\n        const nodes = new Map<ChildNode, string>()\n\n        /* Traverse text nodes and collect matches */\n        const it = document.createNodeIterator(el, NodeFilter.SHOW_TEXT)\n        for (let node = it.nextNode(); node; node = it.nextNode()) {\n          if (node.parentElement?.offsetHeight) {\n            const original = node.textContent!\n            const replaced = fn(original)\n            if (replaced.length > original.length)\n              nodes.set(node as ChildNode, replaced)\n          }\n        }\n\n        /* Replace original nodes with matches */\n        for (const [node, text] of nodes) {\n          const { childNodes } = h(\"span\", null, text)\n          node.replaceWith(...Array.from(childNodes))\n        }\n\n        /* Return component */\n        return { ref: el, nodes }\n      })\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  animationFrameScheduler,\n  asyncScheduler,\n  auditTime,\n  combineLatest,\n  defer,\n  distinctUntilChanged,\n  endWith,\n  finalize,\n  first,\n  from,\n  fromEvent,\n  ignoreElements,\n  map,\n  mergeMap,\n  observeOn,\n  takeUntil,\n  tap,\n  withLatestFrom\n} from \"rxjs\"\n\nimport {\n  Viewport,\n  getElement,\n  getElementOffset,\n  getElementSize,\n  getElements\n} from \"~/browser\"\n\nimport { Component } from \"../_\"\nimport { Header } from \"../header\"\nimport { Main } from \"../main\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Sidebar\n */\nexport interface Sidebar {\n  height: number                       /* Sidebar height */\n  locked: boolean                      /* Sidebar is locked */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  main$: Observable<Main>              /* Main area observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n  main$: Observable<Main>              /* Main area observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch sidebar\n *\n * This function returns an observable that computes the visual parameters of\n * the sidebar which depends on the vertical viewport offset, as well as the\n * height of the main area. When the page is scrolled beyond the header, the\n * sidebar is locked and fills the remaining space.\n *\n * @param el - Sidebar element\n * @param options - Options\n *\n * @returns Sidebar observable\n */\nexport function watchSidebar(\n  el: HTMLElement, { viewport$, main$ }: WatchOptions\n): Observable<Sidebar> {\n  const parent = el.closest<HTMLElement>(\".md-grid\")!\n  const adjust =\n    parent.offsetTop -\n    parent.parentElement!.offsetTop\n\n  /* Compute the sidebar's available height and if it should be locked */\n  return combineLatest([main$, viewport$])\n    .pipe(\n      map(([{ offset, height }, { offset: { y } }]) => {\n        height = height\n          + Math.min(adjust, Math.max(0, y - offset))\n          - adjust\n        return {\n          height,\n          locked: y >= offset + adjust\n        }\n      }),\n      distinctUntilChanged((a, b) => (\n        a.height === b.height &&\n        a.locked === b.locked\n      ))\n    )\n}\n\n/**\n * Mount sidebar\n *\n * This function doesn't set the height of the actual sidebar, but of its first\n * child \u2013 the `.md-sidebar__scrollwrap` element in order to mitigiate jittery\n * sidebars when the footer is scrolled into view. At some point we switched\n * from `absolute` / `fixed` positioning to `sticky` positioning, significantly\n * reducing jitter in some browsers (respectively Firefox and Safari) when\n * scrolling from the top. However, top-aligned sticky positioning means that\n * the sidebar snaps to the bottom when the end of the container is reached.\n * This is what leads to the mentioned jitter, as the sidebar's height may be\n * updated too slowly.\n *\n * This behaviour can be mitigiated by setting the height of the sidebar to `0`\n * while preserving the padding, and the height on its first element.\n *\n * @param el - Sidebar element\n * @param options - Options\n *\n * @returns Sidebar component observable\n */\nexport function mountSidebar(\n  el: HTMLElement, { header$, ...options }: MountOptions\n): Observable<Component<Sidebar>> {\n  const inner = getElement(\".md-sidebar__scrollwrap\", el)\n  const { y } = getElementOffset(inner)\n  return defer(() => {\n    const push$ = new Subject<Sidebar>()\n    const done$ = push$.pipe(ignoreElements(), endWith(true))\n    const next$ = push$\n      .pipe(\n        auditTime(0, animationFrameScheduler)\n      )\n\n    /* Update sidebar height and offset */\n    next$.pipe(withLatestFrom(header$))\n      .subscribe({\n\n        /* Handle emission */\n        next([{ height }, { height: offset }]) {\n          inner.style.height = `${height - 2 * y}px`\n          el.style.top       = `${offset}px`\n        },\n\n        /* Handle complete */\n        complete() {\n          inner.style.height = \"\"\n          el.style.top       = \"\"\n        }\n      })\n\n    /* Bring active item into view on initial load */\n    next$.pipe(first())\n      .subscribe(() => {\n        for (const item of getElements(\".md-nav__link--active[href]\", el)) {\n          if (!item.clientHeight) // skip invisible toc in left sidebar\n            continue\n          const container = item.closest<HTMLElement>(\".md-sidebar__scrollwrap\")!\n          if (typeof container !== \"undefined\") {\n            const offset = item.offsetTop - container.offsetTop\n            const { height } = getElementSize(container)\n            container.scrollTo({\n              top: offset - height / 2\n            })\n          }\n        }\n      })\n\n    /* Handle accessibility for expandable items, see https://bit.ly/3jaod9p */\n    from(getElements<HTMLLabelElement>(\"label[tabindex]\", el))\n      .pipe(\n        mergeMap(label => fromEvent(label, \"click\")\n          .pipe(\n            observeOn(asyncScheduler),\n            map(() => label),\n            takeUntil(done$)\n          )\n        )\n      )\n        .subscribe(label => {\n          const input = getElement<HTMLInputElement>(`[id=\"${label.htmlFor}\"]`)\n          const nav = getElement(`[aria-labelledby=\"${label.id}\"]`)\n          nav.setAttribute(\"aria-expanded\", `${input.checked}`)\n        })\n\n    /* Create and return component */\n    return watchSidebar(el, options)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { Repo, User } from \"github-types\"\nimport {\n  EMPTY,\n  Observable,\n  catchError,\n  defaultIfEmpty,\n  map,\n  zip\n} from \"rxjs\"\n\nimport { requestJSON } from \"~/browser\"\n\nimport { SourceFacts } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * GitHub release (partial)\n */\ninterface Release {\n  tag_name: string                     /* Tag name */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Fetch GitHub repository facts\n *\n * @param user - GitHub user or organization\n * @param repo - GitHub repository\n *\n * @returns Repository facts observable\n */\nexport function fetchSourceFactsFromGitHub(\n  user: string, repo?: string\n): Observable<SourceFacts> {\n  if (typeof repo !== \"undefined\") {\n    const url = `https://api.github.com/repos/${user}/${repo}`\n    return zip(\n\n      /* Fetch version */\n      requestJSON<Release>(`${url}/releases/latest`)\n        .pipe(\n          catchError(() => EMPTY), // @todo refactor instant loading\n          map(release => ({\n            version: release.tag_name\n          })),\n          defaultIfEmpty({})\n        ),\n\n      /* Fetch stars and forks */\n      requestJSON<Repo>(url)\n        .pipe(\n          catchError(() => EMPTY), // @todo refactor instant loading\n          map(info => ({\n            stars: info.stargazers_count,\n            forks: info.forks_count\n          })),\n          defaultIfEmpty({})\n        )\n    )\n      .pipe(\n        map(([release, info]) => ({ ...release, ...info }))\n      )\n\n  /* User or organization */\n  } else {\n    const url = `https://api.github.com/users/${user}`\n    return requestJSON<User>(url)\n      .pipe(\n        map(info => ({\n          repositories: info.public_repos\n        })),\n        defaultIfEmpty({})\n      )\n  }\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { ProjectSchema } from \"gitlab\"\nimport {\n  EMPTY,\n  Observable,\n  catchError,\n  defaultIfEmpty,\n  map,\n  zip\n} from \"rxjs\"\n\nimport { requestJSON } from \"~/browser\"\n\nimport { SourceFacts } from \"../_\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * GitLab release (partial)\n */\ninterface Release { // @todo remove and use the ReleaseSchema type instead after switching from gitlab to @gitbeaker/rest\n  tag_name: string                     /* Tag name */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Fetch GitLab repository facts\n *\n * @param base - GitLab base\n * @param project - GitLab project\n *\n * @returns Repository facts observable\n */\nexport function fetchSourceFactsFromGitLab(\n  base: string, project: string\n): Observable<SourceFacts> {\n  const url = `https://${base}/api/v4/projects/${encodeURIComponent(project)}`\n  return zip(\n\n    /* Fetch version */\n    requestJSON<Release>(`${url}/releases/permalink/latest`)\n      .pipe(\n        catchError(() => EMPTY), // @todo refactor instant loading\n        map(({ tag_name }) => ({\n          version: tag_name\n        })),\n        defaultIfEmpty({})\n      ),\n\n    /* Fetch stars and forks */\n    requestJSON<ProjectSchema>(url)\n      .pipe(\n        catchError(() => EMPTY), // @todo refactor instant loading\n        map(({ star_count, forks_count }) => ({\n          stars: star_count,\n          forks: forks_count\n        })),\n        defaultIfEmpty({})\n      )\n  )\n    .pipe(\n      map(([release, info]) => ({ ...release, ...info }))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport { EMPTY, Observable } from \"rxjs\"\n\nimport { fetchSourceFactsFromGitHub } from \"../github\"\nimport { fetchSourceFactsFromGitLab } from \"../gitlab\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Repository facts for repositories\n */\nexport interface RepositoryFacts {\n  stars?: number                       /* Number of stars */\n  forks?: number                       /* Number of forks */\n  version?: string                     /* Latest version */\n}\n\n/**\n * Repository facts for organizations\n */\nexport interface OrganizationFacts {\n  repositories?: number                /* Number of repositories */\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Repository facts\n */\nexport type SourceFacts =\n  | RepositoryFacts\n  | OrganizationFacts\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Fetch repository facts\n *\n * @param url - Repository URL\n *\n * @returns Repository facts observable\n */\nexport function fetchSourceFacts(\n  url: string\n): Observable<SourceFacts> {\n\n  /* Try to match GitHub repository */\n  let match = url.match(/^.+github\\.com\\/([^/]+)\\/?([^/]+)?/i)\n  if (match) {\n    const [, user, repo] = match\n    return fetchSourceFactsFromGitHub(user, repo)\n  }\n\n  /* Try to match GitLab repository */\n  match = url.match(/^.+?([^/]*gitlab[^/]+)\\/(.+?)\\/?$/i)\n  if (match) {\n    const [, base, slug] = match\n    return fetchSourceFactsFromGitLab(base, slug)\n  }\n\n  /* Fallback */\n  return EMPTY\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  Subject,\n  catchError,\n  defer,\n  filter,\n  finalize,\n  map,\n  of,\n  shareReplay,\n  tap\n} from \"rxjs\"\n\nimport { getElement } from \"~/browser\"\nimport { ConsentDefaults } from \"~/components/consent\"\nimport { renderSourceFacts } from \"~/templates\"\n\nimport {\n  Component,\n  getComponentElements\n} from \"../../_\"\nimport {\n  SourceFacts,\n  fetchSourceFacts\n} from \"../facts\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Repository information\n */\nexport interface Source {\n  facts: SourceFacts                   /* Repository facts */\n}\n\n/* ----------------------------------------------------------------------------\n * Data\n * ------------------------------------------------------------------------- */\n\n/**\n * Repository information observable\n */\nlet fetch$: Observable<Source>\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch repository information\n *\n * This function tries to read the repository facts from session storage, and\n * if unsuccessful, fetches them from the underlying provider.\n *\n * @param el - Repository information element\n *\n * @returns Repository information observable\n */\nexport function watchSource(\n  el: HTMLAnchorElement\n): Observable<Source> {\n  return fetch$ ||= defer(() => {\n    const cached = __md_get<SourceFacts>(\"__source\", sessionStorage)\n    if (cached) {\n      return of(cached)\n    } else {\n\n      /* Check if consent is configured and was given */\n      const els = getComponentElements(\"consent\")\n      if (els.length) {\n        const consent = __md_get<ConsentDefaults>(\"__consent\")\n        if (!(consent && consent.github))\n          return EMPTY\n      }\n\n      /* Fetch repository facts */\n      return fetchSourceFacts(el.href)\n        .pipe(\n          tap(facts => __md_set(\"__source\", facts, sessionStorage))\n        )\n    }\n  })\n    .pipe(\n      catchError(() => EMPTY),\n      filter(facts => Object.keys(facts).length > 0),\n      map(facts => ({ facts })),\n      shareReplay(1)\n    )\n}\n\n/**\n * Mount repository information\n *\n * @param el - Repository information element\n *\n * @returns Repository information component observable\n */\nexport function mountSource(\n  el: HTMLAnchorElement\n): Observable<Component<Source>> {\n  const inner = getElement(\":scope > :last-child\", el)\n  return defer(() => {\n    const push$ = new Subject<Source>()\n    push$.subscribe(({ facts }) => {\n      inner.appendChild(renderSourceFacts(facts))\n      inner.classList.add(\"md-source__repository--active\")\n    })\n\n    /* Create and return component */\n    return watchSource(el)\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  defer,\n  distinctUntilKeyChanged,\n  finalize,\n  map,\n  of,\n  switchMap,\n  tap\n} from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport {\n  Viewport,\n  watchElementSize,\n  watchViewportAt\n} from \"~/browser\"\n\nimport { Component } from \"../_\"\nimport { Header } from \"../header\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Navigation tabs\n */\nexport interface Tabs {\n  hidden: boolean                      /* Navigation tabs are hidden */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch navigation tabs\n *\n * @param el - Navigation tabs element\n * @param options - Options\n *\n * @returns Navigation tabs observable\n */\nexport function watchTabs(\n  el: HTMLElement, { viewport$, header$ }: WatchOptions\n): Observable<Tabs> {\n  return watchElementSize(document.body)\n    .pipe(\n      switchMap(() => watchViewportAt(el, { header$, viewport$ })),\n      map(({ offset: { y } }) => {\n        return {\n          hidden: y >= 10\n        }\n      }),\n      distinctUntilKeyChanged(\"hidden\")\n    )\n}\n\n/**\n * Mount navigation tabs\n *\n * This function hides the navigation tabs when scrolling past the threshold\n * and makes them reappear in a nice CSS animation when scrolling back up.\n *\n * @param el - Navigation tabs element\n * @param options - Options\n *\n * @returns Navigation tabs component observable\n */\nexport function mountTabs(\n  el: HTMLElement, options: MountOptions\n): Observable<Component<Tabs>> {\n  return defer(() => {\n    const push$ = new Subject<Tabs>()\n    push$.subscribe({\n\n      /* Handle emission */\n      next({ hidden }) {\n        el.hidden = hidden\n      },\n\n      /* Handle complete */\n      complete() {\n        el.hidden = false\n      }\n    })\n\n    /* Create and return component */\n    return (\n      feature(\"navigation.tabs.sticky\")\n        ? of({ hidden: false })\n        : watchTabs(el, options)\n    )\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  asyncScheduler,\n  bufferCount,\n  combineLatestWith,\n  debounceTime,\n  defer,\n  distinctUntilChanged,\n  distinctUntilKeyChanged,\n  endWith,\n  filter,\n  finalize,\n  ignoreElements,\n  map,\n  merge,\n  observeOn,\n  of,\n  repeat,\n  scan,\n  share,\n  skip,\n  startWith,\n  switchMap,\n  takeUntil,\n  tap,\n  withLatestFrom\n} from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport {\n  Viewport,\n  getElement,\n  getElementContainer,\n  getElementSize,\n  getElements,\n  getLocation,\n  getOptionalElement,\n  watchElementSize\n} from \"~/browser\"\n\nimport {\n  Component,\n  getComponentElement\n} from \"../_\"\nimport { Header } from \"../header\"\nimport { Main } from \"../main\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Table of contents\n */\nexport interface TableOfContents {\n  prev: HTMLAnchorElement[][]          /* Anchors (previous) */\n  next: HTMLAnchorElement[][]          /* Anchors (next) */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n  main$: Observable<Main>              /* Main area observable */\n  target$: Observable<HTMLElement>     /* Location target observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch table of contents\n *\n * This is effectively a scroll spy implementation which will account for the\n * fixed header and automatically re-calculate anchor offsets when the viewport\n * is resized. The returned observable will only emit if the table of contents\n * needs to be repainted.\n *\n * This implementation tracks an anchor element's entire path starting from its\n * level up to the top-most anchor element, e.g. `[h3, h2, h1]`. Although the\n * Material theme currently doesn't make use of this information, it enables\n * the styling of the entire hierarchy through customization.\n *\n * Note that the current anchor is the last item of the `prev` anchor list.\n *\n * @param el - Table of contents element\n * @param options - Options\n *\n * @returns Table of contents observable\n */\nexport function watchTableOfContents(\n  el: HTMLElement, { viewport$, header$ }: WatchOptions\n): Observable<TableOfContents> {\n  const table = new Map<HTMLAnchorElement, HTMLElement>()\n\n  /* Compute anchor-to-target mapping */\n  const anchors = getElements<HTMLAnchorElement>(\".md-nav__link\", el)\n  for (const anchor of anchors) {\n    const id = decodeURIComponent(anchor.hash.substring(1))\n    const target = getOptionalElement(`[id=\"${id}\"]`)\n    if (typeof target !== \"undefined\")\n      table.set(anchor, target)\n  }\n\n  /* Compute necessary adjustment for header */\n  const adjust$ = header$\n    .pipe(\n      distinctUntilKeyChanged(\"height\"),\n      map(({ height }) => {\n        const main = getComponentElement(\"main\")\n        const grid = getElement(\":scope > :first-child\", main)\n        return height + 0.8 * (\n          grid.offsetTop -\n          main.offsetTop\n        )\n      }),\n      share()\n    )\n\n  /* Compute partition of previous and next anchors */\n  const partition$ = watchElementSize(document.body)\n    .pipe(\n      distinctUntilKeyChanged(\"height\"),\n\n      /* Build index to map anchor paths to vertical offsets */\n      switchMap(body => defer(() => {\n        let path: HTMLAnchorElement[] = []\n        return of([...table].reduce((index, [anchor, target]) => {\n          while (path.length) {\n            const last = table.get(path[path.length - 1])!\n            if (last.tagName >= target.tagName) {\n              path.pop()\n            } else {\n              break\n            }\n          }\n\n          /* If the current anchor is hidden, continue with its parent */\n          let offset = target.offsetTop\n          while (!offset && target.parentElement) {\n            target = target.parentElement\n            offset = target.offsetTop\n          }\n\n          /* Fix anchor offsets in tables - see https://bit.ly/3CUFOcn */\n          let parent = target.offsetParent as HTMLElement\n          for (; parent; parent = parent.offsetParent as HTMLElement)\n            offset += parent.offsetTop\n\n          /* Map reversed anchor path to vertical offset */\n          return index.set(\n            [...path = [...path, anchor]].reverse(),\n            offset\n          )\n        }, new Map<HTMLAnchorElement[], number>()))\n      })\n        .pipe(\n\n          /* Sort index by vertical offset (see https://bit.ly/30z6QSO) */\n          map(index => new Map([...index].sort(([, a], [, b]) => a - b))),\n          combineLatestWith(adjust$),\n\n          /* Re-compute partition when viewport offset changes */\n          switchMap(([index, adjust]) => viewport$\n            .pipe(\n              scan(([prev, next], { offset: { y }, size }) => {\n                const last = y + size.height >= Math.floor(body.height)\n\n                /* Look forward */\n                while (next.length) {\n                  const [, offset] = next[0]\n                  if (offset - adjust < y || last) {\n                    prev = [...prev, next.shift()!]\n                  } else {\n                    break\n                  }\n                }\n\n                /* Look backward */\n                while (prev.length) {\n                  const [, offset] = prev[prev.length - 1]\n                  if (offset - adjust >= y && !last) {\n                    next = [prev.pop()!, ...next]\n                  } else {\n                    break\n                  }\n                }\n\n                /* Return partition */\n                return [prev, next]\n              }, [[], [...index]]),\n              distinctUntilChanged((a, b) => (\n                a[0] === b[0] &&\n                a[1] === b[1]\n              ))\n            )\n          )\n        )\n      )\n    )\n\n  /* Compute and return anchor list migrations */\n  return partition$\n    .pipe(\n      map(([prev, next]) => ({\n        prev: prev.map(([path]) => path),\n        next: next.map(([path]) => path)\n      })),\n\n      /* Extract anchor list migrations */\n      startWith({ prev: [], next: [] }),\n      bufferCount(2, 1),\n      map(([a, b]) => {\n\n        /* Moving down */\n        if (a.prev.length < b.prev.length) {\n          return {\n            prev: b.prev.slice(Math.max(0, a.prev.length - 1), b.prev.length),\n            next: []\n          }\n\n        /* Moving up */\n        } else {\n          return {\n            prev: b.prev.slice(-1),\n            next: b.next.slice(0, b.next.length - a.next.length)\n          }\n        }\n      })\n    )\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Mount table of contents\n *\n * @param el - Table of contents element\n * @param options - Options\n *\n * @returns Table of contents component observable\n */\nexport function mountTableOfContents(\n  el: HTMLElement, { viewport$, header$, main$, target$ }: MountOptions\n): Observable<Component<TableOfContents>> {\n  return defer(() => {\n    const push$ = new Subject<TableOfContents>()\n    const done$ = push$.pipe(ignoreElements(), endWith(true))\n    push$.subscribe(({ prev, next }) => {\n\n      /* Look forward */\n      for (const [anchor] of next) {\n        anchor.classList.remove(\"md-nav__link--passed\")\n        anchor.classList.remove(\"md-nav__link--active\")\n      }\n\n      /* Look backward */\n      for (const [index, [anchor]] of prev.entries()) {\n        anchor.classList.add(\"md-nav__link--passed\")\n        anchor.classList.toggle(\n          \"md-nav__link--active\",\n          index === prev.length - 1\n        )\n      }\n    })\n\n    /* Set up following, if enabled */\n    if (feature(\"toc.follow\")) {\n\n      /* Toggle smooth scrolling only for anchor clicks */\n      const smooth$ = merge(\n        viewport$.pipe(debounceTime(1), map(() => undefined)),\n        viewport$.pipe(debounceTime(250), map(() => \"smooth\" as const))\n      )\n\n      /* Bring active anchor into view */ // @todo: refactor\n      push$\n        .pipe(\n          filter(({ prev }) => prev.length > 0),\n          combineLatestWith(main$.pipe(observeOn(asyncScheduler))),\n          withLatestFrom(smooth$)\n        )\n          .subscribe(([[{ prev }], behavior]) => {\n            const [anchor] = prev[prev.length - 1]\n            if (anchor.offsetHeight) {\n\n              /* Retrieve overflowing container and scroll */\n              const container = getElementContainer(anchor)\n              if (typeof container !== \"undefined\") {\n                const offset = anchor.offsetTop - container.offsetTop\n                const { height } = getElementSize(container)\n                container.scrollTo({\n                  top: offset - height / 2,\n                  behavior\n                })\n              }\n            }\n          })\n    }\n\n    /* Set up anchor tracking, if enabled */\n    if (feature(\"navigation.tracking\"))\n      viewport$\n        .pipe(\n          takeUntil(done$),\n          distinctUntilKeyChanged(\"offset\"),\n          debounceTime(250),\n          skip(1),\n          takeUntil(target$.pipe(skip(1))),\n          repeat({ delay: 250 }),\n          withLatestFrom(push$)\n        )\n          .subscribe(([, { prev }]) => {\n            const url = getLocation()\n\n            /* Set hash fragment to active anchor */\n            const anchor = prev[prev.length - 1]\n            if (anchor && anchor.length) {\n              const [active] = anchor\n              const { hash } = new URL(active.href)\n              if (url.hash !== hash) {\n                url.hash = hash\n                history.replaceState({}, \"\", `${url}`)\n              }\n\n            /* Reset anchor when at the top */\n            } else {\n              url.hash = \"\"\n              history.replaceState({}, \"\", `${url}`)\n            }\n          })\n\n    /* Create and return component */\n    return watchTableOfContents(el, { viewport$, header$ })\n      .pipe(\n        tap(state => push$.next(state)),\n        finalize(() => push$.complete()),\n        map(state => ({ ref: el, ...state }))\n      )\n  })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  Subject,\n  bufferCount,\n  combineLatest,\n  distinctUntilChanged,\n  distinctUntilKeyChanged,\n  endWith,\n  finalize,\n  fromEvent,\n  ignoreElements,\n  map,\n  repeat,\n  skip,\n  takeUntil,\n  tap\n} from \"rxjs\"\n\nimport { Viewport } from \"~/browser\"\n\nimport { Component } from \"../_\"\nimport { Header } from \"../header\"\nimport { Main } from \"../main\"\n\n/* ----------------------------------------------------------------------------\n * Types\n * ------------------------------------------------------------------------- */\n\n/**\n * Back-to-top button\n */\nexport interface BackToTop {\n  hidden: boolean                      /* Back-to-top button is hidden */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch options\n */\ninterface WatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  main$: Observable<Main>              /* Main area observable */\n  target$: Observable<HTMLElement>     /* Location target observable */\n}\n\n/**\n * Mount options\n */\ninterface MountOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  header$: Observable<Header>          /* Header observable */\n  main$: Observable<Main>              /* Main area observable */\n  target$: Observable<HTMLElement>     /* Location target observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Watch back-to-top\n *\n * @param _el - Back-to-top element\n * @param options - Options\n *\n * @returns Back-to-top observable\n */\nexport function watchBackToTop(\n  _el: HTMLElement, { viewport$, main$, target$ }: WatchOptions\n): Observable<BackToTop> {\n\n  /* Compute direction */\n  const direction$ = viewport$\n    .pipe(\n      map(({ offset: { y } }) => y),\n      bufferCount(2, 1),\n      map(([a, b]) => a > b && b > 0),\n      distinctUntilChanged()\n    )\n\n  /* Compute whether main area is active */\n  const active$ = main$\n    .pipe(\n      map(({ active }) => active)\n    )\n\n  /* Compute threshold for hiding */\n  return combineLatest([active$, direction$])\n    .pipe(\n      map(([active, direction]) => !(active && direction)),\n      distinctUntilChanged(),\n      takeUntil(target$.pipe(skip(1))),\n      endWith(true),\n      repeat({ delay: 250 }),\n      map(hidden => ({ hidden }))\n    )\n}\n\n/* ------------------------------------------------------------------------- */\n\n/**\n * Mount back-to-top\n *\n * @param el - Back-to-top element\n * @param options - Options\n *\n * @returns Back-to-top component observable\n */\nexport function mountBackToTop(\n  el: HTMLElement, { viewport$, header$, main$, target$ }: MountOptions\n): Observable<Component<BackToTop>> {\n  const push$ = new Subject<BackToTop>()\n  const done$ = push$.pipe(ignoreElements(), endWith(true))\n  push$.subscribe({\n\n    /* Handle emission */\n    next({ hidden }) {\n      el.hidden = hidden\n      if (hidden) {\n        el.setAttribute(\"tabindex\", \"-1\")\n        el.blur()\n      } else {\n        el.removeAttribute(\"tabindex\")\n      }\n    },\n\n    /* Handle complete */\n    complete() {\n      el.style.top = \"\"\n      el.hidden = true\n      el.removeAttribute(\"tabindex\")\n    }\n  })\n\n  /* Watch header height */\n  header$\n    .pipe(\n      takeUntil(done$),\n      distinctUntilKeyChanged(\"height\")\n    )\n      .subscribe(({ height }) => {\n        el.style.top = `${height + 16}px`\n      })\n\n  /* Go back to top */\n  fromEvent(el, \"click\")\n    .subscribe(ev => {\n      ev.preventDefault()\n      window.scrollTo({ top: 0 })\n    })\n\n  /* Create and return component */\n  return watchBackToTop(el, { viewport$, main$, target$ })\n    .pipe(\n      tap(state => push$.next(state)),\n      finalize(() => push$.complete()),\n      map(state => ({ ref: el, ...state }))\n    )\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  EMPTY,\n  Observable,\n  filter,\n  finalize,\n  map,\n  mergeMap,\n  skip,\n  switchMap,\n  take,\n  takeUntil\n} from \"rxjs\"\n\nimport { feature } from \"~/_\"\nimport {\n  Viewport,\n  getElements,\n  watchElementVisibility\n} from \"~/browser\"\nimport { mountInlineTooltip2 } from \"~/components/tooltip2\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Patch options\n */\ninterface PatchOptions {\n  document$: Observable<Document>      /* Document observable */\n  viewport$: Observable<Viewport>      /* Viewport observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Patch ellipsis\n *\n * This function will fetch all elements that are shortened with ellipsis, and\n * filter those which are visible. Once they become visible, they stay in that\n * state, even though they may be hidden again. This optimization is necessary\n * to reduce pressure on the browser, with elements fading in and out of view.\n *\n * @param options - Options\n */\nexport function patchEllipsis(\n  { document$, viewport$ }: PatchOptions\n): void {\n  document$\n    .pipe(\n      switchMap(() => getElements(\".md-ellipsis\")),\n      mergeMap(el => watchElementVisibility(el)\n        .pipe(\n          takeUntil(document$.pipe(skip(1))),\n          filter(visible => visible),\n          map(() => el),\n          take(1)\n        )\n      ),\n      filter(el => el.offsetWidth < el.scrollWidth),\n      mergeMap(el => {\n        const text = el.innerText\n        const host = el.closest(\"a\") || el\n        host.title = text\n\n        // Do not mount improved tooltip if feature is disabled\n        if (!feature(\"content.tooltips\"))\n          return EMPTY\n\n        /* Mount tooltip */\n        return mountInlineTooltip2(host, { viewport$ })\n          .pipe(\n            takeUntil(document$.pipe(skip(1))),\n            finalize(() => host.removeAttribute(\"title\"))\n          )\n      })\n    )\n      .subscribe()\n\n  // @todo move this outside of here and fix memleaks\n  if (feature(\"content.tooltips\"))\n    document$\n      .pipe(\n        switchMap(() => getElements(\".md-status\")),\n        mergeMap(el => mountInlineTooltip2(el, { viewport$ }))\n      )\n        .subscribe()\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  fromEvent,\n  map,\n  mergeMap,\n  switchMap,\n  takeWhile,\n  tap,\n  withLatestFrom\n} from \"rxjs\"\n\nimport { getElements } from \"~/browser\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Patch options\n */\ninterface PatchOptions {\n  document$: Observable<Document>      /* Document observable */\n  tablet$: Observable<boolean>         /* Media tablet observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Patch indeterminate checkboxes\n *\n * This function replaces the indeterminate \"pseudo state\" with the actual\n * indeterminate state, which is used to keep navigation always expanded.\n *\n * @param options - Options\n */\nexport function patchIndeterminate(\n  { document$, tablet$ }: PatchOptions\n): void {\n  document$\n    .pipe(\n      switchMap(() => getElements<HTMLInputElement>(\n        \".md-toggle--indeterminate\"\n      )),\n      tap(el => {\n        el.indeterminate = true\n        el.checked = false\n      }),\n      mergeMap(el => fromEvent(el, \"change\")\n        .pipe(\n          takeWhile(() => el.classList.contains(\"md-toggle--indeterminate\")),\n          map(() => el)\n        )\n      ),\n      withLatestFrom(tablet$)\n    )\n      .subscribe(([el, tablet]) => {\n        el.classList.remove(\"md-toggle--indeterminate\")\n        if (tablet)\n          el.checked = false\n      })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  filter,\n  fromEvent,\n  map,\n  mergeMap,\n  switchMap,\n  tap\n} from \"rxjs\"\n\nimport { getElements } from \"~/browser\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Patch options\n */\ninterface PatchOptions {\n  document$: Observable<Document>      /* Document observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Helper functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Check whether the given device is an Apple device\n *\n * @returns Test result\n */\nfunction isAppleDevice(): boolean {\n  return /(iPad|iPhone|iPod)/.test(navigator.userAgent)\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Patch all elements with `data-md-scrollfix` attributes\n *\n * This is a year-old patch which ensures that overflow scrolling works at the\n * top and bottom of containers on iOS by ensuring a `1px` scroll offset upon\n * the start of a touch event.\n *\n * @see https://bit.ly/2SCtAOO - Original source\n *\n * @param options - Options\n */\nexport function patchScrollfix(\n  { document$ }: PatchOptions\n): void {\n  document$\n    .pipe(\n      switchMap(() => getElements(\"[data-md-scrollfix]\")),\n      tap(el => el.removeAttribute(\"data-md-scrollfix\")),\n      filter(isAppleDevice),\n      mergeMap(el => fromEvent(el, \"touchstart\")\n        .pipe(\n          map(() => el)\n        )\n      )\n    )\n      .subscribe(el => {\n        const top = el.scrollTop\n\n        /* We're at the top of the container */\n        if (top === 0) {\n          el.scrollTop = 1\n\n        /* We're at the bottom of the container */\n        } else if (top + el.offsetHeight === el.scrollHeight) {\n          el.scrollTop = top - 1\n        }\n      })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport {\n  Observable,\n  combineLatest,\n  delay,\n  map,\n  of,\n  switchMap,\n  withLatestFrom\n} from \"rxjs\"\n\nimport {\n  Viewport,\n  watchToggle\n} from \"~/browser\"\n\n/* ----------------------------------------------------------------------------\n * Helper types\n * ------------------------------------------------------------------------- */\n\n/**\n * Patch options\n */\ninterface PatchOptions {\n  viewport$: Observable<Viewport>      /* Viewport observable */\n  tablet$: Observable<boolean>         /* Media tablet observable */\n}\n\n/* ----------------------------------------------------------------------------\n * Functions\n * ------------------------------------------------------------------------- */\n\n/**\n * Patch the document body to lock when search is open\n *\n * For mobile and tablet viewports, the search is rendered full screen, which\n * leads to scroll leaking when at the top or bottom of the search result. This\n * function locks the body when the search is in full screen mode, and restores\n * the scroll position when leaving.\n *\n * @param options - Options\n */\nexport function patchScrolllock(\n  { viewport$, tablet$ }: PatchOptions\n): void {\n  combineLatest([watchToggle(\"search\"), tablet$])\n    .pipe(\n      map(([active, tablet]) => active && !tablet),\n      switchMap(active => of(active)\n        .pipe(\n          delay(active ? 400 : 100)\n        )\n      ),\n      withLatestFrom(viewport$)\n    )\n      .subscribe(([active, { offset: { y }}]) => {\n        if (active) {\n          document.body.setAttribute(\"data-md-scrolllock\", \"\")\n          document.body.style.top = `-${y}px`\n        } else {\n          const value = -1 * parseInt(document.body.style.top, 10)\n          document.body.removeAttribute(\"data-md-scrolllock\")\n          document.body.style.top = \"\"\n          if (value)\n            window.scrollTo(0, value)\n        }\n      })\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath <martin.donath@squidfunk.com>\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\n/* ----------------------------------------------------------------------------\n * Polyfills\n * ------------------------------------------------------------------------- */\n\n/* Polyfill `Object.entries` */\nif (!Object.entries)\n  Object.entries = function (obj: object) {\n    const data: [string, string][] = []\n    for (const key of Object.keys(obj))\n      // @ts-expect-error - ignore property access warning\n      data.push([key, obj[key]])\n\n    /* Return entries */\n    return data\n  }\n\n/* Polyfill `Object.values` */\nif (!Object.values)\n  Object.values = function (obj: object) {\n    const data: string[] = []\n    for (const key of Object.keys(obj))\n      // @ts-expect-error - ignore property access warning\n      data.push(obj[key])\n\n    /* Return values */\n    return data\n  }\n\n/* ------------------------------------------------------------------------- */\n\n/* Polyfills for `Element` */\nif (typeof Element !== \"undefined\") {\n\n  /* Polyfill `Element.scrollTo` */\n  if (!Element.prototype.scrollTo)\n    Element.prototype.scrollTo = function (\n      x?: ScrollToOptions | number, y?: number\n    ): void {\n      if (typeof x === \"object\") {\n        this.scrollLeft = x.left!\n        this.scrollTop = x.top!\n      } else {\n        this.scrollLeft = x!\n        this.scrollTop = y!\n      }\n    }\n\n  /* Polyfill `Element.replaceWith` */\n  if (!Element.prototype.replaceWith)\n    Element.prototype.replaceWith = function (\n      ...nodes: Array<string | Node>\n    ): void {\n      const parent = this.parentNode\n      if (parent) {\n        if (nodes.length === 0)\n          parent.removeChild(this)\n\n        /* Replace children and create text nodes */\n        for (let i = nodes.length - 1; i >= 0; i--) {\n          let node = nodes[i]\n          if (typeof node === \"string\")\n            node = document.createTextNode(node)\n          else if (node.parentNode)\n            node.parentNode.removeChild(node)\n\n          /* Replace child or insert before previous sibling */\n          if (!i)\n            parent.replaceChild(node, this)\n          else\n            parent.insertBefore(this.previousSibling!, node)\n        }\n      }\n    }\n}\n"],
+  "mappings": "2rCAAA,IAAAA,GAAAC,GAAA,CAAAC,GAAAC,KAAA,EAAC,SAAUC,EAAQC,EAAS,CAC1B,OAAOH,IAAY,UAAY,OAAOC,IAAW,YAAcE,EAAQ,EACvE,OAAO,QAAW,YAAc,OAAO,IAAM,OAAOA,CAAO,EAC1DA,EAAQ,CACX,GAAEH,GAAO,UAAY,CAAE,aASrB,SAASI,EAA0BC,EAAO,CACxC,IAAIC,EAAmB,GACnBC,EAA0B,GAC1BC,EAAiC,KAEjCC,EAAsB,CACxB,KAAM,GACN,OAAQ,GACR,IAAK,GACL,IAAK,GACL,MAAO,GACP,SAAU,GACV,OAAQ,GACR,KAAM,GACN,MAAO,GACP,KAAM,GACN,KAAM,GACN,SAAU,GACV,iBAAkB,EACpB,EAOA,SAASC,EAAmBC,EAAI,CAC9B,MACE,GAAAA,GACAA,IAAO,UACPA,EAAG,WAAa,QAChBA,EAAG,WAAa,QAChB,cAAeA,GACf,aAAcA,EAAG,UAKrB,CASA,SAASC,EAA8BD,EAAI,CACzC,IAAIE,GAAOF,EAAG,KACVG,GAAUH,EAAG,QAUjB,MARI,GAAAG,KAAY,SAAWL,EAAoBI,EAAI,GAAK,CAACF,EAAG,UAIxDG,KAAY,YAAc,CAACH,EAAG,UAI9BA,EAAG,kBAKT,CAOA,SAASI,EAAqBJ,EAAI,CAC5BA,EAAG,UAAU,SAAS,eAAe,IAGzCA,EAAG,UAAU,IAAI,eAAe,EAChCA,EAAG,aAAa,2BAA4B,EAAE,EAChD,CAOA,SAASK,EAAwBL,EAAI,CAC9BA,EAAG,aAAa,0BAA0B,IAG/CA,EAAG,UAAU,OAAO,eAAe,EACnCA,EAAG,gBAAgB,0BAA0B,EAC/C,CAUA,SAASM,EAAUC,EAAG,CAChBA,EAAE,SAAWA,EAAE,QAAUA,EAAE,UAI3BR,EAAmBL,EAAM,aAAa,GACxCU,EAAqBV,EAAM,aAAa,EAG1CC,EAAmB,GACrB,CAUA,SAASa,EAAcD,EAAG,CACxBZ,EAAmB,EACrB,CASA,SAASc,EAAQF,EAAG,CAEbR,EAAmBQ,EAAE,MAAM,IAI5BZ,GAAoBM,EAA8BM,EAAE,MAAM,IAC5DH,EAAqBG,EAAE,MAAM,CAEjC,CAMA,SAASG,EAAOH,EAAG,CACZR,EAAmBQ,EAAE,MAAM,IAK9BA,EAAE,OAAO,UAAU,SAAS,eAAe,GAC3CA,EAAE,OAAO,aAAa,0BAA0B,KAMhDX,EAA0B,GAC1B,OAAO,aAAaC,CAA8B,EAClDA,EAAiC,OAAO,WAAW,UAAW,CAC5DD,EAA0B,EAC5B,EAAG,GAAG,EACNS,EAAwBE,EAAE,MAAM,EAEpC,CAOA,SAASI,EAAmBJ,EAAG,CACzB,SAAS,kBAAoB,WAK3BX,IACFD,EAAmB,IAErBiB,EAA+B,EAEnC,CAQA,SAASA,GAAiC,CACxC,SAAS,iBAAiB,YAAaC,CAAoB,EAC3D,SAAS,iBAAiB,YAAaA,CAAoB,EAC3D,SAAS,iBAAiB,UAAWA,CAAoB,EACzD,SAAS,iBAAiB,cAAeA,CAAoB,EAC7D,SAAS,iBAAiB,cAAeA,CAAoB,EAC7D,SAAS,iBAAiB,YAAaA,CAAoB,EAC3D,SAAS,iBAAiB,YAAaA,CAAoB,EAC3D,SAAS,iBAAiB,aAAcA,CAAoB,EAC5D,SAAS,iBAAiB,WAAYA,CAAoB,CAC5D,CAEA,SAASC,IAAoC,CAC3C,SAAS,oBAAoB,YAAaD,CAAoB,EAC9D,SAAS,oBAAoB,YAAaA,CAAoB,EAC9D,SAAS,oBAAoB,UAAWA,CAAoB,EAC5D,SAAS,oBAAoB,cAAeA,CAAoB,EAChE,SAAS,oBAAoB,cAAeA,CAAoB,EAChE,SAAS,oBAAoB,YAAaA,CAAoB,EAC9D,SAAS,oBAAoB,YAAaA,CAAoB,EAC9D,SAAS,oBAAoB,aAAcA,CAAoB,EAC/D,SAAS,oBAAoB,WAAYA,CAAoB,CAC/D,CASA,SAASA,EAAqBN,EAAG,CAG3BA,EAAE,OAAO,UAAYA,EAAE,OAAO,SAAS,YAAY,IAAM,SAI7DZ,EAAmB,GACnBmB,GAAkC,EACpC,CAKA,SAAS,iBAAiB,UAAWR,EAAW,EAAI,EACpD,SAAS,iBAAiB,YAAaE,EAAe,EAAI,EAC1D,SAAS,iBAAiB,cAAeA,EAAe,EAAI,EAC5D,SAAS,iBAAiB,aAAcA,EAAe,EAAI,EAC3D,SAAS,iBAAiB,mBAAoBG,EAAoB,EAAI,EAEtEC,EAA+B,EAM/BlB,EAAM,iBAAiB,QAASe,EAAS,EAAI,EAC7Cf,EAAM,iBAAiB,OAAQgB,EAAQ,EAAI,EAOvChB,EAAM,WAAa,KAAK,wBAA0BA,EAAM,KAI1DA,EAAM,KAAK,aAAa,wBAAyB,EAAE,EAC1CA,EAAM,WAAa,KAAK,gBACjC,SAAS,gBAAgB,UAAU,IAAI,kBAAkB,EACzD,SAAS,gBAAgB,aAAa,wBAAyB,EAAE,EAErE,CAKA,GAAI,OAAO,QAAW,aAAe,OAAO,UAAa,YAAa,CAIpE,OAAO,0BAA4BD,EAInC,IAAIsB,EAEJ,GAAI,CACFA,EAAQ,IAAI,YAAY,8BAA8B,CACxD,OAASC,EAAO,CAEdD,EAAQ,SAAS,YAAY,aAAa,EAC1CA,EAAM,gBAAgB,+BAAgC,GAAO,GAAO,CAAC,CAAC,CACxE,CAEA,OAAO,cAAcA,CAAK,CAC5B,CAEI,OAAO,UAAa,aAGtBtB,EAA0B,QAAQ,CAGtC,CAAE,ICvTF,IAAAwB,GAAAC,GAAA,CAAAC,GAAAC,KAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,GAeA,IAAIC,GAAkB,UAOtBD,GAAO,QAAUE,GAUjB,SAASA,GAAWC,EAAQ,CAC1B,IAAIC,EAAM,GAAKD,EACXE,EAAQJ,GAAgB,KAAKG,CAAG,EAEpC,GAAI,CAACC,EACH,OAAOD,EAGT,IAAIE,EACAC,EAAO,GACPC,EAAQ,EACRC,EAAY,EAEhB,IAAKD,EAAQH,EAAM,MAAOG,EAAQJ,EAAI,OAAQI,IAAS,CACrD,OAAQJ,EAAI,WAAWI,CAAK,EAAG,CAC7B,IAAK,IACHF,EAAS,SACT,MACF,IAAK,IACHA,EAAS,QACT,MACF,IAAK,IACHA,EAAS,QACT,MACF,IAAK,IACHA,EAAS,OACT,MACF,IAAK,IACHA,EAAS,OACT,MACF,QACE,QACJ,CAEIG,IAAcD,IAChBD,GAAQH,EAAI,UAAUK,EAAWD,CAAK,GAGxCC,EAAYD,EAAQ,EACpBD,GAAQD,CACV,CAEA,OAAOG,IAAcD,EACjBD,EAAOH,EAAI,UAAUK,EAAWD,CAAK,EACrCD,CACN,IC7EA,IAAAG,GAAAC,GAAA,CAAAC,GAAAC,KAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAMC,SAA0CC,EAAMC,EAAS,CACtD,OAAOH,IAAY,UAAY,OAAOC,IAAW,SACnDA,GAAO,QAAUE,EAAQ,EAClB,OAAO,QAAW,YAAc,OAAO,IAC9C,OAAO,CAAC,EAAGA,CAAO,EACX,OAAOH,IAAY,SAC1BA,GAAQ,YAAiBG,EAAQ,EAEjCD,EAAK,YAAiBC,EAAQ,CAChC,GAAGH,GAAM,UAAW,CACpB,OAAiB,UAAW,CAClB,IAAII,EAAuB,CAE/B,IACC,SAASC,EAAyBC,EAAqBC,EAAqB,CAEnF,aAGAA,EAAoB,EAAED,EAAqB,CACzC,QAAW,UAAW,CAAE,OAAqBE,EAAW,CAC1D,CAAC,EAGD,IAAIC,EAAeF,EAAoB,GAAG,EACtCG,EAAoCH,EAAoB,EAAEE,CAAY,EAEtEE,EAASJ,EAAoB,GAAG,EAChCK,EAA8BL,EAAoB,EAAEI,CAAM,EAE1DE,EAAaN,EAAoB,GAAG,EACpCO,EAA8BP,EAAoB,EAAEM,CAAU,EAOlE,SAASE,EAAQC,EAAM,CACrB,GAAI,CACF,OAAO,SAAS,YAAYA,CAAI,CAClC,OAASC,EAAK,CACZ,MAAO,EACT,CACF,CAUA,IAAIC,EAAqB,SAA4BC,EAAQ,CAC3D,IAAIC,EAAeN,EAAe,EAAEK,CAAM,EAC1C,OAAAJ,EAAQ,KAAK,EACNK,CACT,EAEiCC,EAAeH,EAOhD,SAASI,EAAkBC,EAAO,CAChC,IAAIC,EAAQ,SAAS,gBAAgB,aAAa,KAAK,IAAM,MACzDC,EAAc,SAAS,cAAc,UAAU,EAEnDA,EAAY,MAAM,SAAW,OAE7BA,EAAY,MAAM,OAAS,IAC3BA,EAAY,MAAM,QAAU,IAC5BA,EAAY,MAAM,OAAS,IAE3BA,EAAY,MAAM,SAAW,WAC7BA,EAAY,MAAMD,EAAQ,QAAU,MAAM,EAAI,UAE9C,IAAIE,EAAY,OAAO,aAAe,SAAS,gBAAgB,UAC/D,OAAAD,EAAY,MAAM,IAAM,GAAG,OAAOC,EAAW,IAAI,EACjDD,EAAY,aAAa,WAAY,EAAE,EACvCA,EAAY,MAAQF,EACbE,CACT,CAYA,IAAIE,EAAiB,SAAwBJ,EAAOK,EAAS,CAC3D,IAAIH,EAAcH,EAAkBC,CAAK,EACzCK,EAAQ,UAAU,YAAYH,CAAW,EACzC,IAAIL,EAAeN,EAAe,EAAEW,CAAW,EAC/C,OAAAV,EAAQ,MAAM,EACdU,EAAY,OAAO,EACZL,CACT,EASIS,GAAsB,SAA6BV,EAAQ,CAC7D,IAAIS,EAAU,UAAU,OAAS,GAAK,UAAU,CAAC,IAAM,OAAY,UAAU,CAAC,EAAI,CAChF,UAAW,SAAS,IACtB,EACIR,EAAe,GAEnB,OAAI,OAAOD,GAAW,SACpBC,EAAeO,EAAeR,EAAQS,CAAO,EACpCT,aAAkB,kBAAoB,CAAC,CAAC,OAAQ,SAAU,MAAO,MAAO,UAAU,EAAE,SAASA,GAAW,KAA4B,OAASA,EAAO,IAAI,EAEjKC,EAAeO,EAAeR,EAAO,MAAOS,CAAO,GAEnDR,EAAeN,EAAe,EAAEK,CAAM,EACtCJ,EAAQ,MAAM,GAGTK,CACT,EAEiCU,EAAgBD,GAEjD,SAASE,EAAQC,EAAK,CAAE,0BAA2B,OAAI,OAAO,QAAW,YAAc,OAAO,OAAO,UAAa,SAAYD,EAAU,SAAiBC,EAAK,CAAE,OAAO,OAAOA,CAAK,EAAYD,EAAU,SAAiBC,EAAK,CAAE,OAAOA,GAAO,OAAO,QAAW,YAAcA,EAAI,cAAgB,QAAUA,IAAQ,OAAO,UAAY,SAAW,OAAOA,CAAK,EAAYD,EAAQC,CAAG,CAAG,CAUzX,IAAIC,GAAyB,UAAkC,CAC7D,IAAIL,EAAU,UAAU,OAAS,GAAK,UAAU,CAAC,IAAM,OAAY,UAAU,CAAC,EAAI,CAAC,EAE/EM,EAAkBN,EAAQ,OAC1BO,EAASD,IAAoB,OAAS,OAASA,EAC/CE,EAAYR,EAAQ,UACpBT,EAASS,EAAQ,OACjBS,GAAOT,EAAQ,KAEnB,GAAIO,IAAW,QAAUA,IAAW,MAClC,MAAM,IAAI,MAAM,oDAAoD,EAItE,GAAIhB,IAAW,OACb,GAAIA,GAAUY,EAAQZ,CAAM,IAAM,UAAYA,EAAO,WAAa,EAAG,CACnE,GAAIgB,IAAW,QAAUhB,EAAO,aAAa,UAAU,EACrD,MAAM,IAAI,MAAM,mFAAmF,EAGrG,GAAIgB,IAAW,QAAUhB,EAAO,aAAa,UAAU,GAAKA,EAAO,aAAa,UAAU,GACxF,MAAM,IAAI,MAAM,uGAAwG,CAE5H,KACE,OAAM,IAAI,MAAM,6CAA6C,EAKjE,GAAIkB,GACF,OAAOP,EAAaO,GAAM,CACxB,UAAWD,CACb,CAAC,EAIH,GAAIjB,EACF,OAAOgB,IAAW,MAAQd,EAAYF,CAAM,EAAIW,EAAaX,EAAQ,CACnE,UAAWiB,CACb,CAAC,CAEL,EAEiCE,GAAmBL,GAEpD,SAASM,GAAiBP,EAAK,CAAE,0BAA2B,OAAI,OAAO,QAAW,YAAc,OAAO,OAAO,UAAa,SAAYO,GAAmB,SAAiBP,EAAK,CAAE,OAAO,OAAOA,CAAK,EAAYO,GAAmB,SAAiBP,EAAK,CAAE,OAAOA,GAAO,OAAO,QAAW,YAAcA,EAAI,cAAgB,QAAUA,IAAQ,OAAO,UAAY,SAAW,OAAOA,CAAK,EAAYO,GAAiBP,CAAG,CAAG,CAE7Z,SAASQ,GAAgBC,EAAUC,EAAa,CAAE,GAAI,EAAED,aAAoBC,GAAgB,MAAM,IAAI,UAAU,mCAAmC,CAAK,CAExJ,SAASC,GAAkBxB,EAAQyB,EAAO,CAAE,QAASC,EAAI,EAAGA,EAAID,EAAM,OAAQC,IAAK,CAAE,IAAIC,EAAaF,EAAMC,CAAC,EAAGC,EAAW,WAAaA,EAAW,YAAc,GAAOA,EAAW,aAAe,GAAU,UAAWA,IAAYA,EAAW,SAAW,IAAM,OAAO,eAAe3B,EAAQ2B,EAAW,IAAKA,CAAU,CAAG,CAAE,CAE5T,SAASC,GAAaL,EAAaM,EAAYC,EAAa,CAAE,OAAID,GAAYL,GAAkBD,EAAY,UAAWM,CAAU,EAAOC,GAAaN,GAAkBD,EAAaO,CAAW,EAAUP,CAAa,CAEtN,SAASQ,GAAUC,EAAUC,EAAY,CAAE,GAAI,OAAOA,GAAe,YAAcA,IAAe,KAAQ,MAAM,IAAI,UAAU,oDAAoD,EAAKD,EAAS,UAAY,OAAO,OAAOC,GAAcA,EAAW,UAAW,CAAE,YAAa,CAAE,MAAOD,EAAU,SAAU,GAAM,aAAc,EAAK,CAAE,CAAC,EAAOC,GAAYC,GAAgBF,EAAUC,CAAU,CAAG,CAEhY,SAASC,GAAgBC,EAAGC,EAAG,CAAE,OAAAF,GAAkB,OAAO,gBAAkB,SAAyBC,EAAGC,EAAG,CAAE,OAAAD,EAAE,UAAYC,EAAUD,CAAG,EAAUD,GAAgBC,EAAGC,CAAC,CAAG,CAEzK,SAASC,GAAaC,EAAS,CAAE,IAAIC,EAA4BC,GAA0B,EAAG,OAAO,UAAgC,CAAE,IAAIC,EAAQC,GAAgBJ,CAAO,EAAGK,EAAQ,GAAIJ,EAA2B,CAAE,IAAIK,EAAYF,GAAgB,IAAI,EAAE,YAAaC,EAAS,QAAQ,UAAUF,EAAO,UAAWG,CAAS,CAAG,MAASD,EAASF,EAAM,MAAM,KAAM,SAAS,EAAK,OAAOI,GAA2B,KAAMF,CAAM,CAAG,CAAG,CAExa,SAASE,GAA2BC,EAAMC,EAAM,CAAE,OAAIA,IAAS3B,GAAiB2B,CAAI,IAAM,UAAY,OAAOA,GAAS,YAAsBA,EAAeC,GAAuBF,CAAI,CAAG,CAEzL,SAASE,GAAuBF,EAAM,CAAE,GAAIA,IAAS,OAAU,MAAM,IAAI,eAAe,2DAA2D,EAAK,OAAOA,CAAM,CAErK,SAASN,IAA4B,CAA0E,GAApE,OAAO,SAAY,aAAe,CAAC,QAAQ,WAA6B,QAAQ,UAAU,KAAM,MAAO,GAAO,GAAI,OAAO,OAAU,WAAY,MAAO,GAAM,GAAI,CAAE,YAAK,UAAU,SAAS,KAAK,QAAQ,UAAU,KAAM,CAAC,EAAG,UAAY,CAAC,CAAC,CAAC,EAAU,EAAM,OAASS,EAAG,CAAE,MAAO,EAAO,CAAE,CAEnU,SAASP,GAAgBP,EAAG,CAAE,OAAAO,GAAkB,OAAO,eAAiB,OAAO,eAAiB,SAAyBP,EAAG,CAAE,OAAOA,EAAE,WAAa,OAAO,eAAeA,CAAC,CAAG,EAAUO,GAAgBP,CAAC,CAAG,CAa5M,SAASe,GAAkBC,EAAQC,EAAS,CAC1C,IAAIC,EAAY,kBAAkB,OAAOF,CAAM,EAE/C,GAAKC,EAAQ,aAAaC,CAAS,EAInC,OAAOD,EAAQ,aAAaC,CAAS,CACvC,CAOA,IAAIC,GAAyB,SAAUC,EAAU,CAC/CxB,GAAUuB,EAAWC,CAAQ,EAE7B,IAAIC,EAASnB,GAAaiB,CAAS,EAMnC,SAASA,EAAUG,EAAShD,EAAS,CACnC,IAAIiD,EAEJ,OAAArC,GAAgB,KAAMiC,CAAS,EAE/BI,EAAQF,EAAO,KAAK,IAAI,EAExBE,EAAM,eAAejD,CAAO,EAE5BiD,EAAM,YAAYD,CAAO,EAElBC,CACT,CAQA,OAAA9B,GAAa0B,EAAW,CAAC,CACvB,IAAK,iBACL,MAAO,UAA0B,CAC/B,IAAI7C,EAAU,UAAU,OAAS,GAAK,UAAU,CAAC,IAAM,OAAY,UAAU,CAAC,EAAI,CAAC,EACnF,KAAK,OAAS,OAAOA,EAAQ,QAAW,WAAaA,EAAQ,OAAS,KAAK,cAC3E,KAAK,OAAS,OAAOA,EAAQ,QAAW,WAAaA,EAAQ,OAAS,KAAK,cAC3E,KAAK,KAAO,OAAOA,EAAQ,MAAS,WAAaA,EAAQ,KAAO,KAAK,YACrE,KAAK,UAAYW,GAAiBX,EAAQ,SAAS,IAAM,SAAWA,EAAQ,UAAY,SAAS,IACnG,CAMF,EAAG,CACD,IAAK,cACL,MAAO,SAAqBgD,EAAS,CACnC,IAAIE,EAAS,KAEb,KAAK,SAAWlE,EAAe,EAAEgE,EAAS,QAAS,SAAUR,GAAG,CAC9D,OAAOU,EAAO,QAAQV,EAAC,CACzB,CAAC,CACH,CAMF,EAAG,CACD,IAAK,UACL,MAAO,SAAiBA,EAAG,CACzB,IAAIQ,EAAUR,EAAE,gBAAkBA,EAAE,cAChCjC,GAAS,KAAK,OAAOyC,CAAO,GAAK,OACjCvC,GAAOC,GAAgB,CACzB,OAAQH,GACR,UAAW,KAAK,UAChB,OAAQ,KAAK,OAAOyC,CAAO,EAC3B,KAAM,KAAK,KAAKA,CAAO,CACzB,CAAC,EAED,KAAK,KAAKvC,GAAO,UAAY,QAAS,CACpC,OAAQF,GACR,KAAME,GACN,QAASuC,EACT,eAAgB,UAA0B,CACpCA,GACFA,EAAQ,MAAM,EAGhB,OAAO,aAAa,EAAE,gBAAgB,CACxC,CACF,CAAC,CACH,CAMF,EAAG,CACD,IAAK,gBACL,MAAO,SAAuBA,EAAS,CACrC,OAAOP,GAAkB,SAAUO,CAAO,CAC5C,CAMF,EAAG,CACD,IAAK,gBACL,MAAO,SAAuBA,EAAS,CACrC,IAAIG,EAAWV,GAAkB,SAAUO,CAAO,EAElD,GAAIG,EACF,OAAO,SAAS,cAAcA,CAAQ,CAE1C,CAQF,EAAG,CACD,IAAK,cAML,MAAO,SAAqBH,EAAS,CACnC,OAAOP,GAAkB,OAAQO,CAAO,CAC1C,CAKF,EAAG,CACD,IAAK,UACL,MAAO,UAAmB,CACxB,KAAK,SAAS,QAAQ,CACxB,CACF,CAAC,EAAG,CAAC,CACH,IAAK,OACL,MAAO,SAAczD,EAAQ,CAC3B,IAAIS,EAAU,UAAU,OAAS,GAAK,UAAU,CAAC,IAAM,OAAY,UAAU,CAAC,EAAI,CAChF,UAAW,SAAS,IACtB,EACA,OAAOE,EAAaX,EAAQS,CAAO,CACrC,CAOF,EAAG,CACD,IAAK,MACL,MAAO,SAAaT,EAAQ,CAC1B,OAAOE,EAAYF,CAAM,CAC3B,CAOF,EAAG,CACD,IAAK,cACL,MAAO,UAAuB,CAC5B,IAAIgB,EAAS,UAAU,OAAS,GAAK,UAAU,CAAC,IAAM,OAAY,UAAU,CAAC,EAAI,CAAC,OAAQ,KAAK,EAC3F6C,EAAU,OAAO7C,GAAW,SAAW,CAACA,CAAM,EAAIA,EAClD8C,GAAU,CAAC,CAAC,SAAS,sBACzB,OAAAD,EAAQ,QAAQ,SAAU7C,GAAQ,CAChC8C,GAAUA,IAAW,CAAC,CAAC,SAAS,sBAAsB9C,EAAM,CAC9D,CAAC,EACM8C,EACT,CACF,CAAC,CAAC,EAEKR,CACT,EAAG/D,EAAqB,CAAE,EAEOF,GAAaiE,EAExC,EAEA,IACC,SAASxE,EAAQ,CAExB,IAAIiF,EAAqB,EAKzB,GAAI,OAAO,SAAY,aAAe,CAAC,QAAQ,UAAU,QAAS,CAC9D,IAAIC,EAAQ,QAAQ,UAEpBA,EAAM,QAAUA,EAAM,iBACNA,EAAM,oBACNA,EAAM,mBACNA,EAAM,kBACNA,EAAM,qBAC1B,CASA,SAASC,EAASb,EAASQ,EAAU,CACjC,KAAOR,GAAWA,EAAQ,WAAaW,GAAoB,CACvD,GAAI,OAAOX,EAAQ,SAAY,YAC3BA,EAAQ,QAAQQ,CAAQ,EAC1B,OAAOR,EAETA,EAAUA,EAAQ,UACtB,CACJ,CAEAtE,EAAO,QAAUmF,CAGX,EAEA,IACC,SAASnF,EAAQoF,EAA0B9E,EAAqB,CAEvE,IAAI6E,EAAU7E,EAAoB,GAAG,EAYrC,SAAS+E,EAAUf,EAASQ,EAAU/D,EAAMuE,EAAUC,EAAY,CAC9D,IAAIC,EAAaC,EAAS,MAAM,KAAM,SAAS,EAE/C,OAAAnB,EAAQ,iBAAiBvD,EAAMyE,EAAYD,CAAU,EAE9C,CACH,QAAS,UAAW,CAChBjB,EAAQ,oBAAoBvD,EAAMyE,EAAYD,CAAU,CAC5D,CACJ,CACJ,CAYA,SAASG,EAASC,EAAUb,EAAU/D,EAAMuE,EAAUC,EAAY,CAE9D,OAAI,OAAOI,EAAS,kBAAqB,WAC9BN,EAAU,MAAM,KAAM,SAAS,EAItC,OAAOtE,GAAS,WAGTsE,EAAU,KAAK,KAAM,QAAQ,EAAE,MAAM,KAAM,SAAS,GAI3D,OAAOM,GAAa,WACpBA,EAAW,SAAS,iBAAiBA,CAAQ,GAI1C,MAAM,UAAU,IAAI,KAAKA,EAAU,SAAUrB,EAAS,CACzD,OAAOe,EAAUf,EAASQ,EAAU/D,EAAMuE,EAAUC,CAAU,CAClE,CAAC,EACL,CAWA,SAASE,EAASnB,EAASQ,EAAU/D,EAAMuE,EAAU,CACjD,OAAO,SAASnB,EAAG,CACfA,EAAE,eAAiBgB,EAAQhB,EAAE,OAAQW,CAAQ,EAEzCX,EAAE,gBACFmB,EAAS,KAAKhB,EAASH,CAAC,CAEhC,CACJ,CAEAnE,EAAO,QAAU0F,CAGX,EAEA,IACC,SAAStF,EAAyBL,EAAS,CAQlDA,EAAQ,KAAO,SAASuB,EAAO,CAC3B,OAAOA,IAAU,QACVA,aAAiB,aACjBA,EAAM,WAAa,CAC9B,EAQAvB,EAAQ,SAAW,SAASuB,EAAO,CAC/B,IAAIP,EAAO,OAAO,UAAU,SAAS,KAAKO,CAAK,EAE/C,OAAOA,IAAU,SACTP,IAAS,qBAAuBA,IAAS,4BACzC,WAAYO,IACZA,EAAM,SAAW,GAAKvB,EAAQ,KAAKuB,EAAM,CAAC,CAAC,EACvD,EAQAvB,EAAQ,OAAS,SAASuB,EAAO,CAC7B,OAAO,OAAOA,GAAU,UACjBA,aAAiB,MAC5B,EAQAvB,EAAQ,GAAK,SAASuB,EAAO,CACzB,IAAIP,EAAO,OAAO,UAAU,SAAS,KAAKO,CAAK,EAE/C,OAAOP,IAAS,mBACpB,CAGM,EAEA,IACC,SAASf,EAAQoF,EAA0B9E,EAAqB,CAEvE,IAAIsF,EAAKtF,EAAoB,GAAG,EAC5BoF,EAAWpF,EAAoB,GAAG,EAWtC,SAASI,EAAOQ,EAAQH,EAAMuE,EAAU,CACpC,GAAI,CAACpE,GAAU,CAACH,GAAQ,CAACuE,EACrB,MAAM,IAAI,MAAM,4BAA4B,EAGhD,GAAI,CAACM,EAAG,OAAO7E,CAAI,EACf,MAAM,IAAI,UAAU,kCAAkC,EAG1D,GAAI,CAAC6E,EAAG,GAAGN,CAAQ,EACf,MAAM,IAAI,UAAU,mCAAmC,EAG3D,GAAIM,EAAG,KAAK1E,CAAM,EACd,OAAO2E,EAAW3E,EAAQH,EAAMuE,CAAQ,EAEvC,GAAIM,EAAG,SAAS1E,CAAM,EACvB,OAAO4E,EAAe5E,EAAQH,EAAMuE,CAAQ,EAE3C,GAAIM,EAAG,OAAO1E,CAAM,EACrB,OAAO6E,EAAe7E,EAAQH,EAAMuE,CAAQ,EAG5C,MAAM,IAAI,UAAU,2EAA2E,CAEvG,CAWA,SAASO,EAAWG,EAAMjF,EAAMuE,EAAU,CACtC,OAAAU,EAAK,iBAAiBjF,EAAMuE,CAAQ,EAE7B,CACH,QAAS,UAAW,CAChBU,EAAK,oBAAoBjF,EAAMuE,CAAQ,CAC3C,CACJ,CACJ,CAWA,SAASQ,EAAeG,EAAUlF,EAAMuE,EAAU,CAC9C,aAAM,UAAU,QAAQ,KAAKW,EAAU,SAASD,EAAM,CAClDA,EAAK,iBAAiBjF,EAAMuE,CAAQ,CACxC,CAAC,EAEM,CACH,QAAS,UAAW,CAChB,MAAM,UAAU,QAAQ,KAAKW,EAAU,SAASD,EAAM,CAClDA,EAAK,oBAAoBjF,EAAMuE,CAAQ,CAC3C,CAAC,CACL,CACJ,CACJ,CAWA,SAASS,EAAejB,EAAU/D,EAAMuE,EAAU,CAC9C,OAAOI,EAAS,SAAS,KAAMZ,EAAU/D,EAAMuE,CAAQ,CAC3D,CAEAtF,EAAO,QAAUU,CAGX,EAEA,IACC,SAASV,EAAQ,CAExB,SAASkG,EAAO5B,EAAS,CACrB,IAAInD,EAEJ,GAAImD,EAAQ,WAAa,SACrBA,EAAQ,MAAM,EAEdnD,EAAemD,EAAQ,cAElBA,EAAQ,WAAa,SAAWA,EAAQ,WAAa,WAAY,CACtE,IAAI6B,EAAa7B,EAAQ,aAAa,UAAU,EAE3C6B,GACD7B,EAAQ,aAAa,WAAY,EAAE,EAGvCA,EAAQ,OAAO,EACfA,EAAQ,kBAAkB,EAAGA,EAAQ,MAAM,MAAM,EAE5C6B,GACD7B,EAAQ,gBAAgB,UAAU,EAGtCnD,EAAemD,EAAQ,KAC3B,KACK,CACGA,EAAQ,aAAa,iBAAiB,GACtCA,EAAQ,MAAM,EAGlB,IAAI8B,EAAY,OAAO,aAAa,EAChCC,EAAQ,SAAS,YAAY,EAEjCA,EAAM,mBAAmB/B,CAAO,EAChC8B,EAAU,gBAAgB,EAC1BA,EAAU,SAASC,CAAK,EAExBlF,EAAeiF,EAAU,SAAS,CACtC,CAEA,OAAOjF,CACX,CAEAnB,EAAO,QAAUkG,CAGX,EAEA,IACC,SAASlG,EAAQ,CAExB,SAASsG,GAAK,CAGd,CAEAA,EAAE,UAAY,CACZ,GAAI,SAAUC,EAAMjB,EAAUkB,EAAK,CACjC,IAAIrC,EAAI,KAAK,IAAM,KAAK,EAAI,CAAC,GAE7B,OAACA,EAAEoC,CAAI,IAAMpC,EAAEoC,CAAI,EAAI,CAAC,IAAI,KAAK,CAC/B,GAAIjB,EACJ,IAAKkB,CACP,CAAC,EAEM,IACT,EAEA,KAAM,SAAUD,EAAMjB,EAAUkB,EAAK,CACnC,IAAIxC,EAAO,KACX,SAASyB,GAAY,CACnBzB,EAAK,IAAIuC,EAAMd,CAAQ,EACvBH,EAAS,MAAMkB,EAAK,SAAS,CAC/B,CAEA,OAAAf,EAAS,EAAIH,EACN,KAAK,GAAGiB,EAAMd,EAAUe,CAAG,CACpC,EAEA,KAAM,SAAUD,EAAM,CACpB,IAAIE,EAAO,CAAC,EAAE,MAAM,KAAK,UAAW,CAAC,EACjCC,IAAW,KAAK,IAAM,KAAK,EAAI,CAAC,IAAIH,CAAI,GAAK,CAAC,GAAG,MAAM,EACvD3D,EAAI,EACJ+D,EAAMD,EAAO,OAEjB,IAAK9D,EAAGA,EAAI+D,EAAK/D,IACf8D,EAAO9D,CAAC,EAAE,GAAG,MAAM8D,EAAO9D,CAAC,EAAE,IAAK6D,CAAI,EAGxC,OAAO,IACT,EAEA,IAAK,SAAUF,EAAMjB,EAAU,CAC7B,IAAInB,EAAI,KAAK,IAAM,KAAK,EAAI,CAAC,GACzByC,EAAOzC,EAAEoC,CAAI,EACbM,EAAa,CAAC,EAElB,GAAID,GAAQtB,EACV,QAAS1C,EAAI,EAAG+D,EAAMC,EAAK,OAAQhE,EAAI+D,EAAK/D,IACtCgE,EAAKhE,CAAC,EAAE,KAAO0C,GAAYsB,EAAKhE,CAAC,EAAE,GAAG,IAAM0C,GAC9CuB,EAAW,KAAKD,EAAKhE,CAAC,CAAC,EAQ7B,OAACiE,EAAW,OACR1C,EAAEoC,CAAI,EAAIM,EACV,OAAO1C,EAAEoC,CAAI,EAEV,IACT,CACF,EAEAvG,EAAO,QAAUsG,EACjBtG,EAAO,QAAQ,YAAcsG,CAGvB,CAEI,EAGIQ,EAA2B,CAAC,EAGhC,SAASxG,EAAoByG,EAAU,CAEtC,GAAGD,EAAyBC,CAAQ,EACnC,OAAOD,EAAyBC,CAAQ,EAAE,QAG3C,IAAI/G,EAAS8G,EAAyBC,CAAQ,EAAI,CAGjD,QAAS,CAAC,CACX,EAGA,OAAA5G,EAAoB4G,CAAQ,EAAE/G,EAAQA,EAAO,QAASM,CAAmB,EAGlEN,EAAO,OACf,CAIA,OAAC,UAAW,CAEXM,EAAoB,EAAI,SAASN,EAAQ,CACxC,IAAIgH,EAAShH,GAAUA,EAAO,WAC7B,UAAW,CAAE,OAAOA,EAAO,OAAY,EACvC,UAAW,CAAE,OAAOA,CAAQ,EAC7B,OAAAM,EAAoB,EAAE0G,EAAQ,CAAE,EAAGA,CAAO,CAAC,EACpCA,CACR,CACD,EAAE,EAGD,UAAW,CAEX1G,EAAoB,EAAI,SAASP,EAASkH,EAAY,CACrD,QAAQC,KAAOD,EACX3G,EAAoB,EAAE2G,EAAYC,CAAG,GAAK,CAAC5G,EAAoB,EAAEP,EAASmH,CAAG,GAC/E,OAAO,eAAenH,EAASmH,EAAK,CAAE,WAAY,GAAM,IAAKD,EAAWC,CAAG,CAAE,CAAC,CAGjF,CACD,EAAE,EAGD,UAAW,CACX5G,EAAoB,EAAI,SAASyB,EAAKoF,EAAM,CAAE,OAAO,OAAO,UAAU,eAAe,KAAKpF,EAAKoF,CAAI,CAAG,CACvG,EAAE,EAMK7G,EAAoB,GAAG,CAC/B,EAAG,EACX,OACD,CAAC,ICn2BD,IAAA8G,GAAO,SCNP,IAAIC,GAAgB,SAASC,EAAGC,EAAG,CACjC,OAAAF,GAAgB,OAAO,gBAClB,CAAE,UAAW,CAAC,CAAE,YAAa,OAAS,SAAUC,EAAGC,EAAG,CAAED,EAAE,UAAYC,CAAG,GAC1E,SAAUD,EAAGC,EAAG,CAAE,QAASC,KAAKD,EAAO,OAAO,UAAU,eAAe,KAAKA,EAAGC,CAAC,IAAGF,EAAEE,CAAC,EAAID,EAAEC,CAAC,EAAG,EAC7FH,GAAcC,EAAGC,CAAC,CAC3B,EAEO,SAASE,GAAUH,EAAGC,EAAG,CAC9B,GAAI,OAAOA,GAAM,YAAcA,IAAM,KACjC,MAAM,IAAI,UAAU,uBAAyB,OAAOA,CAAC,EAAI,+BAA+B,EAC5FF,GAAcC,EAAGC,CAAC,EAClB,SAASG,GAAK,CAAE,KAAK,YAAcJ,CAAG,CACtCA,EAAE,UAAYC,IAAM,KAAO,OAAO,OAAOA,CAAC,GAAKG,EAAG,UAAYH,EAAE,UAAW,IAAIG,EACjF,CAqFO,SAASC,GAAUC,EAASC,EAAYC,EAAGC,EAAW,CAC3D,SAASC,EAAMC,EAAO,CAAE,OAAOA,aAAiBH,EAAIG,EAAQ,IAAIH,EAAE,SAAUI,EAAS,CAAEA,EAAQD,CAAK,CAAG,CAAC,CAAG,CAC3G,OAAO,IAAKH,IAAMA,EAAI,UAAU,SAAUI,EAASC,EAAQ,CACvD,SAASC,EAAUH,EAAO,CAAE,GAAI,CAAEI,EAAKN,EAAU,KAAKE,CAAK,CAAC,CAAG,OAASK,EAAG,CAAEH,EAAOG,CAAC,CAAG,CAAE,CAC1F,SAASC,EAASN,EAAO,CAAE,GAAI,CAAEI,EAAKN,EAAU,MAASE,CAAK,CAAC,CAAG,OAASK,EAAG,CAAEH,EAAOG,CAAC,CAAG,CAAE,CAC7F,SAASD,EAAKG,EAAQ,CAAEA,EAAO,KAAON,EAAQM,EAAO,KAAK,EAAIR,EAAMQ,EAAO,KAAK,EAAE,KAAKJ,EAAWG,CAAQ,CAAG,CAC7GF,GAAMN,EAAYA,EAAU,MAAMH,EAASC,GAAc,CAAC,CAAC,GAAG,KAAK,CAAC,CACxE,CAAC,CACH,CAEO,SAASY,GAAYb,EAASc,EAAM,CACzC,IAAIC,EAAI,CAAE,MAAO,EAAG,KAAM,UAAW,CAAE,GAAIC,EAAE,CAAC,EAAI,EAAG,MAAMA,EAAE,CAAC,EAAG,OAAOA,EAAE,CAAC,CAAG,EAAG,KAAM,CAAC,EAAG,IAAK,CAAC,CAAE,EAAGC,EAAGC,EAAGF,EAAGG,EAAI,OAAO,QAAQ,OAAO,UAAa,WAAa,SAAW,QAAQ,SAAS,EAC/L,OAAOA,EAAE,KAAOC,EAAK,CAAC,EAAGD,EAAE,MAAWC,EAAK,CAAC,EAAGD,EAAE,OAAYC,EAAK,CAAC,EAAG,OAAO,QAAW,aAAeD,EAAE,OAAO,QAAQ,EAAI,UAAW,CAAE,OAAO,IAAM,GAAIA,EAC1J,SAASC,EAAKC,EAAG,CAAE,OAAO,SAAUC,EAAG,CAAE,OAAOb,EAAK,CAACY,EAAGC,CAAC,CAAC,CAAG,CAAG,CACjE,SAASb,EAAKc,EAAI,CACd,GAAIN,EAAG,MAAM,IAAI,UAAU,iCAAiC,EAC5D,KAAOE,IAAMA,EAAI,EAAGI,EAAG,CAAC,IAAMR,EAAI,IAAKA,GAAG,GAAI,CAC1C,GAAIE,EAAI,EAAGC,IAAMF,EAAIO,EAAG,CAAC,EAAI,EAAIL,EAAE,OAAYK,EAAG,CAAC,EAAIL,EAAE,SAAcF,EAAIE,EAAE,SAAcF,EAAE,KAAKE,CAAC,EAAG,GAAKA,EAAE,OAAS,EAAEF,EAAIA,EAAE,KAAKE,EAAGK,EAAG,CAAC,CAAC,GAAG,KAAM,OAAOP,EAE3J,OADIE,EAAI,EAAGF,IAAGO,EAAK,CAACA,EAAG,CAAC,EAAI,EAAGP,EAAE,KAAK,GAC9BO,EAAG,CAAC,EAAG,CACX,IAAK,GAAG,IAAK,GAAGP,EAAIO,EAAI,MACxB,IAAK,GAAG,OAAAR,EAAE,QAAgB,CAAE,MAAOQ,EAAG,CAAC,EAAG,KAAM,EAAM,EACtD,IAAK,GAAGR,EAAE,QAASG,EAAIK,EAAG,CAAC,EAAGA,EAAK,CAAC,CAAC,EAAG,SACxC,IAAK,GAAGA,EAAKR,EAAE,IAAI,IAAI,EAAGA,EAAE,KAAK,IAAI,EAAG,SACxC,QACI,GAAMC,EAAID,EAAE,KAAM,EAAAC,EAAIA,EAAE,OAAS,GAAKA,EAAEA,EAAE,OAAS,CAAC,KAAOO,EAAG,CAAC,IAAM,GAAKA,EAAG,CAAC,IAAM,GAAI,CAAER,EAAI,EAAG,QAAU,CAC3G,GAAIQ,EAAG,CAAC,IAAM,IAAM,CAACP,GAAMO,EAAG,CAAC,EAAIP,EAAE,CAAC,GAAKO,EAAG,CAAC,EAAIP,EAAE,CAAC,GAAK,CAAED,EAAE,MAAQQ,EAAG,CAAC,EAAG,KAAO,CACrF,GAAIA,EAAG,CAAC,IAAM,GAAKR,EAAE,MAAQC,EAAE,CAAC,EAAG,CAAED,EAAE,MAAQC,EAAE,CAAC,EAAGA,EAAIO,EAAI,KAAO,CACpE,GAAIP,GAAKD,EAAE,MAAQC,EAAE,CAAC,EAAG,CAAED,EAAE,MAAQC,EAAE,CAAC,EAAGD,EAAE,IAAI,KAAKQ,CAAE,EAAG,KAAO,CAC9DP,EAAE,CAAC,GAAGD,EAAE,IAAI,IAAI,EACpBA,EAAE,KAAK,IAAI,EAAG,QACtB,CACAQ,EAAKT,EAAK,KAAKd,EAASe,CAAC,CAC7B,OAASL,EAAG,CAAEa,EAAK,CAAC,EAAGb,CAAC,EAAGQ,EAAI,CAAG,QAAE,CAAUD,EAAID,EAAI,CAAG,CACzD,GAAIO,EAAG,CAAC,EAAI,EAAG,MAAMA,EAAG,CAAC,EAAG,MAAO,CAAE,MAAOA,EAAG,CAAC,EAAIA,EAAG,CAAC,EAAI,OAAQ,KAAM,EAAK,CACnF,CACF,CAkBO,SAASC,GAASC,EAAG,CAC1B,IAAIC,EAAI,OAAO,QAAW,YAAc,OAAO,SAAUC,EAAID,GAAKD,EAAEC,CAAC,EAAGE,EAAI,EAC5E,GAAID,EAAG,OAAOA,EAAE,KAAKF,CAAC,EACtB,GAAIA,GAAK,OAAOA,EAAE,QAAW,SAAU,MAAO,CAC1C,KAAM,UAAY,CACd,OAAIA,GAAKG,GAAKH,EAAE,SAAQA,EAAI,QACrB,CAAE,MAAOA,GAAKA,EAAEG,GAAG,EAAG,KAAM,CAACH,CAAE,CAC1C,CACJ,EACA,MAAM,IAAI,UAAUC,EAAI,0BAA4B,iCAAiC,CACvF,CAEO,SAASG,EAAOJ,EAAGK,EAAG,CAC3B,IAAIH,EAAI,OAAO,QAAW,YAAcF,EAAE,OAAO,QAAQ,EACzD,GAAI,CAACE,EAAG,OAAOF,EACf,IAAIG,EAAID,EAAE,KAAKF,CAAC,EAAGM,EAAGC,EAAK,CAAC,EAAGC,EAC/B,GAAI,CACA,MAAQH,IAAM,QAAUA,KAAM,IAAM,EAAEC,EAAIH,EAAE,KAAK,GAAG,MAAMI,EAAG,KAAKD,EAAE,KAAK,CAC7E,OACOG,EAAO,CAAED,EAAI,CAAE,MAAOC,CAAM,CAAG,QACtC,CACI,GAAI,CACIH,GAAK,CAACA,EAAE,OAASJ,EAAIC,EAAE,SAAYD,EAAE,KAAKC,CAAC,CACnD,QACA,CAAU,GAAIK,EAAG,MAAMA,EAAE,KAAO,CACpC,CACA,OAAOD,CACT,CAkBO,SAASG,EAAcC,EAAIC,EAAMC,EAAM,CAC5C,GAAIA,GAAQ,UAAU,SAAW,EAAG,QAASC,EAAI,EAAGC,EAAIH,EAAK,OAAQI,EAAIF,EAAIC,EAAGD,KACxEE,GAAM,EAAEF,KAAKF,MACRI,IAAIA,EAAK,MAAM,UAAU,MAAM,KAAKJ,EAAM,EAAGE,CAAC,GACnDE,EAAGF,CAAC,EAAIF,EAAKE,CAAC,GAGtB,OAAOH,EAAG,OAAOK,GAAM,MAAM,UAAU,MAAM,KAAKJ,CAAI,CAAC,CACzD,CAEO,SAASK,GAAQC,EAAG,CACzB,OAAO,gBAAgBD,IAAW,KAAK,EAAIC,EAAG,MAAQ,IAAID,GAAQC,CAAC,CACrE,CAEO,SAASC,GAAiBC,EAASC,EAAYC,EAAW,CAC/D,GAAI,CAAC,OAAO,cAAe,MAAM,IAAI,UAAU,sCAAsC,EACrF,IAAIC,EAAID,EAAU,MAAMF,EAASC,GAAc,CAAC,CAAC,EAAGP,EAAGU,EAAI,CAAC,EAC5D,OAAOV,EAAI,OAAO,QAAQ,OAAO,eAAkB,WAAa,cAAgB,QAAQ,SAAS,EAAGW,EAAK,MAAM,EAAGA,EAAK,OAAO,EAAGA,EAAK,SAAUC,CAAW,EAAGZ,EAAE,OAAO,aAAa,EAAI,UAAY,CAAE,OAAO,IAAM,EAAGA,EACtN,SAASY,EAAYC,EAAG,CAAE,OAAO,SAAUT,EAAG,CAAE,OAAO,QAAQ,QAAQA,CAAC,EAAE,KAAKS,EAAGC,CAAM,CAAG,CAAG,CAC9F,SAASH,EAAKI,EAAGF,EAAG,CAAMJ,EAAEM,CAAC,IAAKf,EAAEe,CAAC,EAAI,SAAUX,EAAG,CAAE,OAAO,IAAI,QAAQ,SAAUY,EAAGC,GAAG,CAAEP,EAAE,KAAK,CAACK,EAAGX,EAAGY,EAAGC,EAAC,CAAC,EAAI,GAAKC,EAAOH,EAAGX,CAAC,CAAG,CAAC,CAAG,EAAOS,IAAGb,EAAEe,CAAC,EAAIF,EAAEb,EAAEe,CAAC,CAAC,GAAK,CACvK,SAASG,EAAOH,EAAGX,EAAG,CAAE,GAAI,CAAEe,EAAKV,EAAEM,CAAC,EAAEX,CAAC,CAAC,CAAG,OAASgB,EAAG,CAAEC,EAAOX,EAAE,CAAC,EAAE,CAAC,EAAGU,CAAC,CAAG,CAAE,CACjF,SAASD,EAAKG,EAAG,CAAEA,EAAE,iBAAiBnB,GAAU,QAAQ,QAAQmB,EAAE,MAAM,CAAC,EAAE,KAAKC,EAAST,CAAM,EAAIO,EAAOX,EAAE,CAAC,EAAE,CAAC,EAAGY,CAAC,CAAG,CACvH,SAASC,EAAQC,EAAO,CAAEN,EAAO,OAAQM,CAAK,CAAG,CACjD,SAASV,EAAOU,EAAO,CAAEN,EAAO,QAASM,CAAK,CAAG,CACjD,SAASH,EAAOR,EAAGT,EAAG,CAAMS,EAAET,CAAC,EAAGM,EAAE,MAAM,EAAGA,EAAE,QAAQQ,EAAOR,EAAE,CAAC,EAAE,CAAC,EAAGA,EAAE,CAAC,EAAE,CAAC,CAAC,CAAG,CACnF,CAQO,SAASe,GAAcC,EAAG,CAC/B,GAAI,CAAC,OAAO,cAAe,MAAM,IAAI,UAAU,sCAAsC,EACrF,IAAIC,EAAID,EAAE,OAAO,aAAa,EAAGE,EACjC,OAAOD,EAAIA,EAAE,KAAKD,CAAC,GAAKA,EAAI,OAAOG,IAAa,WAAaA,GAASH,CAAC,EAAIA,EAAE,OAAO,QAAQ,EAAE,EAAGE,EAAI,CAAC,EAAGE,EAAK,MAAM,EAAGA,EAAK,OAAO,EAAGA,EAAK,QAAQ,EAAGF,EAAE,OAAO,aAAa,EAAI,UAAY,CAAE,OAAO,IAAM,EAAGA,GAC9M,SAASE,EAAKC,EAAG,CAAEH,EAAEG,CAAC,EAAIL,EAAEK,CAAC,GAAK,SAAUC,EAAG,CAAE,OAAO,IAAI,QAAQ,SAAUC,EAASC,EAAQ,CAAEF,EAAIN,EAAEK,CAAC,EAAEC,CAAC,EAAGG,EAAOF,EAASC,EAAQF,EAAE,KAAMA,EAAE,KAAK,CAAG,CAAC,CAAG,CAAG,CAC/J,SAASG,EAAOF,EAASC,EAAQE,EAAGJ,EAAG,CAAE,QAAQ,QAAQA,CAAC,EAAE,KAAK,SAASA,EAAG,CAAEC,EAAQ,CAAE,MAAOD,EAAG,KAAMI,CAAE,CAAC,CAAG,EAAGF,CAAM,CAAG,CAC7H,CCxPM,SAAUG,EAAWC,EAAU,CACnC,OAAO,OAAOA,GAAU,UAC1B,CCGM,SAAUC,GAAoBC,EAAgC,CAClE,IAAMC,EAAS,SAACC,EAAa,CAC3B,MAAM,KAAKA,CAAQ,EACnBA,EAAS,MAAQ,IAAI,MAAK,EAAG,KAC/B,EAEMC,EAAWH,EAAWC,CAAM,EAClC,OAAAE,EAAS,UAAY,OAAO,OAAO,MAAM,SAAS,EAClDA,EAAS,UAAU,YAAcA,EAC1BA,CACT,CCDO,IAAMC,GAA+CC,GAC1D,SAACC,EAAM,CACL,OAAA,SAA4CC,EAA0B,CACpED,EAAO,IAAI,EACX,KAAK,QAAUC,EACRA,EAAO,OAAM;EACxBA,EAAO,IAAI,SAACC,EAAKC,EAAC,CAAK,OAAGA,EAAI,EAAC,KAAKD,EAAI,SAAQ,CAAzB,CAA6B,EAAE,KAAK;GAAM,EACzD,GACJ,KAAK,KAAO,sBACZ,KAAK,OAASD,CAChB,CARA,CAQC,ECvBC,SAAUG,GAAaC,EAA6BC,EAAO,CAC/D,GAAID,EAAK,CACP,IAAME,EAAQF,EAAI,QAAQC,CAAI,EAC9B,GAAKC,GAASF,EAAI,OAAOE,EAAO,CAAC,EAErC,CCOA,IAAAC,GAAA,UAAA,CAyBE,SAAAA,EAAoBC,EAA4B,CAA5B,KAAA,gBAAAA,EAdb,KAAA,OAAS,GAER,KAAA,WAAmD,KAMnD,KAAA,YAAqD,IAMV,CAQnD,OAAAD,EAAA,UAAA,YAAA,UAAA,aACME,EAEJ,GAAI,CAAC,KAAK,OAAQ,CAChB,KAAK,OAAS,GAGN,IAAAC,EAAe,KAAI,WAC3B,GAAIA,EAEF,GADA,KAAK,WAAa,KACd,MAAM,QAAQA,CAAU,MAC1B,QAAqBC,EAAAC,GAAAF,CAAU,EAAAG,EAAAF,EAAA,KAAA,EAAA,CAAAE,EAAA,KAAAA,EAAAF,EAAA,KAAA,EAAE,CAA5B,IAAMG,EAAMD,EAAA,MACfC,EAAO,OAAO,IAAI,yGAGpBJ,EAAW,OAAO,IAAI,EAIlB,IAAiBK,EAAqB,KAAI,gBAClD,GAAIC,EAAWD,CAAgB,EAC7B,GAAI,CACFA,EAAgB,QACTE,EAAG,CACVR,EAASQ,aAAaC,GAAsBD,EAAE,OAAS,CAACA,CAAC,EAIrD,IAAAE,EAAgB,KAAI,YAC5B,GAAIA,EAAa,CACf,KAAK,YAAc,SACnB,QAAwBC,EAAAR,GAAAO,CAAW,EAAAE,EAAAD,EAAA,KAAA,EAAA,CAAAC,EAAA,KAAAA,EAAAD,EAAA,KAAA,EAAE,CAAhC,IAAME,EAASD,EAAA,MAClB,GAAI,CACFE,GAAcD,CAAS,QAChBE,EAAK,CACZf,EAASA,GAAM,KAANA,EAAU,CAAA,EACfe,aAAeN,GACjBT,EAAMgB,EAAAA,EAAA,CAAA,EAAAC,EAAOjB,CAAM,CAAA,EAAAiB,EAAKF,EAAI,MAAM,CAAA,EAElCf,EAAO,KAAKe,CAAG,sGAMvB,GAAIf,EACF,MAAM,IAAIS,GAAoBT,CAAM,EAG1C,EAoBAF,EAAA,UAAA,IAAA,SAAIoB,EAAuB,OAGzB,GAAIA,GAAYA,IAAa,KAC3B,GAAI,KAAK,OAGPJ,GAAcI,CAAQ,MACjB,CACL,GAAIA,aAAoBpB,EAAc,CAGpC,GAAIoB,EAAS,QAAUA,EAAS,WAAW,IAAI,EAC7C,OAEFA,EAAS,WAAW,IAAI,GAEzB,KAAK,aAAcC,EAAA,KAAK,eAAW,MAAAA,IAAA,OAAAA,EAAI,CAAA,GAAI,KAAKD,CAAQ,EAG/D,EAOQpB,EAAA,UAAA,WAAR,SAAmBsB,EAAoB,CAC7B,IAAAnB,EAAe,KAAI,WAC3B,OAAOA,IAAemB,GAAW,MAAM,QAAQnB,CAAU,GAAKA,EAAW,SAASmB,CAAM,CAC1F,EASQtB,EAAA,UAAA,WAAR,SAAmBsB,EAAoB,CAC7B,IAAAnB,EAAe,KAAI,WAC3B,KAAK,WAAa,MAAM,QAAQA,CAAU,GAAKA,EAAW,KAAKmB,CAAM,EAAGnB,GAAcA,EAAa,CAACA,EAAYmB,CAAM,EAAIA,CAC5H,EAMQtB,EAAA,UAAA,cAAR,SAAsBsB,EAAoB,CAChC,IAAAnB,EAAe,KAAI,WACvBA,IAAemB,EACjB,KAAK,WAAa,KACT,MAAM,QAAQnB,CAAU,GACjCoB,GAAUpB,EAAYmB,CAAM,CAEhC,EAgBAtB,EAAA,UAAA,OAAA,SAAOoB,EAAsC,CACnC,IAAAR,EAAgB,KAAI,YAC5BA,GAAeW,GAAUX,EAAaQ,CAAQ,EAE1CA,aAAoBpB,GACtBoB,EAAS,cAAc,IAAI,CAE/B,EAlLcpB,EAAA,MAAS,UAAA,CACrB,IAAMwB,EAAQ,IAAIxB,EAClB,OAAAwB,EAAM,OAAS,GACRA,CACT,EAAE,EA+KJxB,GArLA,EAuLO,IAAMyB,GAAqBC,GAAa,MAEzC,SAAUC,GAAeC,EAAU,CACvC,OACEA,aAAiBF,IAChBE,GAAS,WAAYA,GAASC,EAAWD,EAAM,MAAM,GAAKC,EAAWD,EAAM,GAAG,GAAKC,EAAWD,EAAM,WAAW,CAEpH,CAEA,SAASE,GAAcC,EAAwC,CACzDF,EAAWE,CAAS,EACtBA,EAAS,EAETA,EAAU,YAAW,CAEzB,CChNO,IAAMC,GAAuB,CAClC,iBAAkB,KAClB,sBAAuB,KACvB,QAAS,OACT,sCAAuC,GACvC,yBAA0B,ICGrB,IAAMC,GAAmC,CAG9C,WAAA,SAAWC,EAAqBC,EAAgB,SAAEC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,EAAA,CAAA,EAAA,UAAAA,CAAA,EACxC,IAAAC,EAAaL,GAAe,SACpC,OAAIK,GAAQ,MAARA,EAAU,WACLA,EAAS,WAAU,MAAnBA,EAAQC,EAAA,CAAYL,EAASC,CAAO,EAAAK,EAAKJ,CAAI,CAAA,CAAA,EAE/C,WAAU,MAAA,OAAAG,EAAA,CAACL,EAASC,CAAO,EAAAK,EAAKJ,CAAI,CAAA,CAAA,CAC7C,EACA,aAAA,SAAaK,EAAM,CACT,IAAAH,EAAaL,GAAe,SACpC,QAAQK,GAAQ,KAAA,OAARA,EAAU,eAAgB,cAAcG,CAAa,CAC/D,EACA,SAAU,QCjBN,SAAUC,GAAqBC,EAAQ,CAC3CC,GAAgB,WAAW,UAAA,CACjB,IAAAC,EAAqBC,GAAM,iBACnC,GAAID,EAEFA,EAAiBF,CAAG,MAGpB,OAAMA,CAEV,CAAC,CACH,CCtBM,SAAUI,IAAI,CAAK,CCMlB,IAAMC,GAAyB,UAAA,CAAM,OAAAC,GAAmB,IAAK,OAAW,MAAS,CAA5C,EAAsE,EAO5G,SAAUC,GAAkBC,EAAU,CAC1C,OAAOF,GAAmB,IAAK,OAAWE,CAAK,CACjD,CAOM,SAAUC,GAAoBC,EAAQ,CAC1C,OAAOJ,GAAmB,IAAKI,EAAO,MAAS,CACjD,CAQM,SAAUJ,GAAmBK,EAAuBD,EAAYF,EAAU,CAC9E,MAAO,CACL,KAAIG,EACJ,MAAKD,EACL,MAAKF,EAET,CCrCA,IAAII,GAAuD,KASrD,SAAUC,GAAaC,EAAc,CACzC,GAAIC,GAAO,sCAAuC,CAChD,IAAMC,EAAS,CAACJ,GAKhB,GAJII,IACFJ,GAAU,CAAE,YAAa,GAAO,MAAO,IAAI,GAE7CE,EAAE,EACEE,EAAQ,CACJ,IAAAC,EAAyBL,GAAvBM,EAAWD,EAAA,YAAEE,EAAKF,EAAA,MAE1B,GADAL,GAAU,KACNM,EACF,MAAMC,QAMVL,EAAE,CAEN,CAMM,SAAUM,GAAaC,EAAQ,CAC/BN,GAAO,uCAAyCH,KAClDA,GAAQ,YAAc,GACtBA,GAAQ,MAAQS,EAEpB,CCrBA,IAAAC,GAAA,SAAAC,EAAA,CAAmCC,GAAAF,EAAAC,CAAA,EA6BjC,SAAAD,EAAYG,EAA6C,CAAzD,IAAAC,EACEH,EAAA,KAAA,IAAA,GAAO,KATC,OAAAG,EAAA,UAAqB,GAUzBD,GACFC,EAAK,YAAcD,EAGfE,GAAeF,CAAW,GAC5BA,EAAY,IAAIC,CAAI,GAGtBA,EAAK,YAAcE,IAEvB,CAzBO,OAAAN,EAAA,OAAP,SAAiBO,EAAwBC,EAA2BC,EAAqB,CACvF,OAAO,IAAIC,GAAeH,EAAMC,EAAOC,CAAQ,CACjD,EAgCAT,EAAA,UAAA,KAAA,SAAKW,EAAS,CACR,KAAK,UACPC,GAA0BC,GAAiBF,CAAK,EAAG,IAAI,EAEvD,KAAK,MAAMA,CAAM,CAErB,EASAX,EAAA,UAAA,MAAA,SAAMc,EAAS,CACT,KAAK,UACPF,GAA0BG,GAAkBD,CAAG,EAAG,IAAI,GAEtD,KAAK,UAAY,GACjB,KAAK,OAAOA,CAAG,EAEnB,EAQAd,EAAA,UAAA,SAAA,UAAA,CACM,KAAK,UACPY,GAA0BI,GAAuB,IAAI,GAErD,KAAK,UAAY,GACjB,KAAK,UAAS,EAElB,EAEAhB,EAAA,UAAA,YAAA,UAAA,CACO,KAAK,SACR,KAAK,UAAY,GACjBC,EAAA,UAAM,YAAW,KAAA,IAAA,EACjB,KAAK,YAAc,KAEvB,EAEUD,EAAA,UAAA,MAAV,SAAgBW,EAAQ,CACtB,KAAK,YAAY,KAAKA,CAAK,CAC7B,EAEUX,EAAA,UAAA,OAAV,SAAiBc,EAAQ,CACvB,GAAI,CACF,KAAK,YAAY,MAAMA,CAAG,UAE1B,KAAK,YAAW,EAEpB,EAEUd,EAAA,UAAA,UAAV,UAAA,CACE,GAAI,CACF,KAAK,YAAY,SAAQ,UAEzB,KAAK,YAAW,EAEpB,EACFA,CAAA,EApHmCiB,EAAY,EA2H/C,IAAMC,GAAQ,SAAS,UAAU,KAEjC,SAASC,GAAyCC,EAAQC,EAAY,CACpE,OAAOH,GAAM,KAAKE,EAAIC,CAAO,CAC/B,CAMA,IAAAC,GAAA,UAAA,CACE,SAAAA,EAAoBC,EAAqC,CAArC,KAAA,gBAAAA,CAAwC,CAE5D,OAAAD,EAAA,UAAA,KAAA,SAAKE,EAAQ,CACH,IAAAD,EAAoB,KAAI,gBAChC,GAAIA,EAAgB,KAClB,GAAI,CACFA,EAAgB,KAAKC,CAAK,QACnBC,EAAO,CACdC,GAAqBD,CAAK,EAGhC,EAEAH,EAAA,UAAA,MAAA,SAAMK,EAAQ,CACJ,IAAAJ,EAAoB,KAAI,gBAChC,GAAIA,EAAgB,MAClB,GAAI,CACFA,EAAgB,MAAMI,CAAG,QAClBF,EAAO,CACdC,GAAqBD,CAAK,OAG5BC,GAAqBC,CAAG,CAE5B,EAEAL,EAAA,UAAA,SAAA,UAAA,CACU,IAAAC,EAAoB,KAAI,gBAChC,GAAIA,EAAgB,SAClB,GAAI,CACFA,EAAgB,SAAQ,QACjBE,EAAO,CACdC,GAAqBD,CAAK,EAGhC,EACFH,CAAA,EArCA,EAuCAM,GAAA,SAAAC,EAAA,CAAuCC,GAAAF,EAAAC,CAAA,EACrC,SAAAD,EACEG,EACAN,EACAO,EAA8B,CAHhC,IAAAC,EAKEJ,EAAA,KAAA,IAAA,GAAO,KAEHN,EACJ,GAAIW,EAAWH,CAAc,GAAK,CAACA,EAGjCR,EAAkB,CAChB,KAAOQ,GAAc,KAAdA,EAAkB,OACzB,MAAON,GAAK,KAALA,EAAS,OAChB,SAAUO,GAAQ,KAARA,EAAY,YAEnB,CAEL,IAAIG,EACAF,GAAQG,GAAO,0BAIjBD,EAAU,OAAO,OAAOJ,CAAc,EACtCI,EAAQ,YAAc,UAAA,CAAM,OAAAF,EAAK,YAAW,CAAhB,EAC5BV,EAAkB,CAChB,KAAMQ,EAAe,MAAQZ,GAAKY,EAAe,KAAMI,CAAO,EAC9D,MAAOJ,EAAe,OAASZ,GAAKY,EAAe,MAAOI,CAAO,EACjE,SAAUJ,EAAe,UAAYZ,GAAKY,EAAe,SAAUI,CAAO,IAI5EZ,EAAkBQ,EAMtB,OAAAE,EAAK,YAAc,IAAIX,GAAiBC,CAAe,GACzD,CACF,OAAAK,CAAA,EAzCuCS,EAAU,EA2CjD,SAASC,GAAqBC,EAAU,CAClCC,GAAO,sCACTC,GAAaF,CAAK,EAIlBG,GAAqBH,CAAK,CAE9B,CAQA,SAASI,GAAoBC,EAAQ,CACnC,MAAMA,CACR,CAOA,SAASC,GAA0BC,EAA2CC,EAA2B,CAC/F,IAAAC,EAA0BR,GAAM,sBACxCQ,GAAyBC,GAAgB,WAAW,UAAA,CAAM,OAAAD,EAAsBF,EAAcC,CAAU,CAA9C,CAA+C,CAC3G,CAOO,IAAMG,GAA6D,CACxE,OAAQ,GACR,KAAMC,GACN,MAAOR,GACP,SAAUQ,IC5QL,IAAMC,GAA+B,UAAA,CAAM,OAAC,OAAO,QAAW,YAAc,OAAO,YAAe,cAAvD,EAAsE,ECoClH,SAAUC,GAAYC,EAAI,CAC9B,OAAOA,CACT,CCiCM,SAAUC,IAAI,SAACC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACnB,OAAOC,GAAcF,CAAG,CAC1B,CAGM,SAAUE,GAAoBF,EAA+B,CACjE,OAAIA,EAAI,SAAW,EACVG,GAGLH,EAAI,SAAW,EACVA,EAAI,CAAC,EAGP,SAAeI,EAAQ,CAC5B,OAAOJ,EAAI,OAAO,SAACK,EAAWC,EAAuB,CAAK,OAAAA,EAAGD,CAAI,CAAP,EAAUD,CAAY,CAClF,CACF,CC9EA,IAAAG,EAAA,UAAA,CAkBE,SAAAA,EAAYC,EAA6E,CACnFA,IACF,KAAK,WAAaA,EAEtB,CA4BA,OAAAD,EAAA,UAAA,KAAA,SAAQE,EAAyB,CAC/B,IAAMC,EAAa,IAAIH,EACvB,OAAAG,EAAW,OAAS,KACpBA,EAAW,SAAWD,EACfC,CACT,EA6IAH,EAAA,UAAA,UAAA,SACEI,EACAC,EACAC,EAA8B,CAHhC,IAAAC,EAAA,KAKQC,EAAaC,GAAaL,CAAc,EAAIA,EAAiB,IAAIM,GAAeN,EAAgBC,EAAOC,CAAQ,EAErH,OAAAK,GAAa,UAAA,CACL,IAAAC,EAAuBL,EAArBL,EAAQU,EAAA,SAAEC,EAAMD,EAAA,OACxBJ,EAAW,IACTN,EAGIA,EAAS,KAAKM,EAAYK,CAAM,EAChCA,EAIAN,EAAK,WAAWC,CAAU,EAG1BD,EAAK,cAAcC,CAAU,CAAC,CAEtC,CAAC,EAEMA,CACT,EAGUR,EAAA,UAAA,cAAV,SAAwBc,EAAmB,CACzC,GAAI,CACF,OAAO,KAAK,WAAWA,CAAI,QACpBC,EAAK,CAIZD,EAAK,MAAMC,CAAG,EAElB,EA6DAf,EAAA,UAAA,QAAA,SAAQgB,EAA0BC,EAAoC,CAAtE,IAAAV,EAAA,KACE,OAAAU,EAAcC,GAAeD,CAAW,EAEjC,IAAIA,EAAkB,SAACE,EAASC,EAAM,CAC3C,IAAMZ,EAAa,IAAIE,GAAkB,CACvC,KAAM,SAACW,EAAK,CACV,GAAI,CACFL,EAAKK,CAAK,QACHN,EAAK,CACZK,EAAOL,CAAG,EACVP,EAAW,YAAW,EAE1B,EACA,MAAOY,EACP,SAAUD,EACX,EACDZ,EAAK,UAAUC,CAAU,CAC3B,CAAC,CACH,EAGUR,EAAA,UAAA,WAAV,SAAqBQ,EAA2B,OAC9C,OAAOI,EAAA,KAAK,UAAM,MAAAA,IAAA,OAAA,OAAAA,EAAE,UAAUJ,CAAU,CAC1C,EAOAR,EAAA,UAACG,EAAiB,EAAlB,UAAA,CACE,OAAO,IACT,EA4FAH,EAAA,UAAA,KAAA,UAAA,SAAKsB,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACH,OAAOC,GAAcF,CAAU,EAAE,IAAI,CACvC,EA6BAtB,EAAA,UAAA,UAAA,SAAUiB,EAAoC,CAA9C,IAAAV,EAAA,KACE,OAAAU,EAAcC,GAAeD,CAAW,EAEjC,IAAIA,EAAY,SAACE,EAASC,EAAM,CACrC,IAAIC,EACJd,EAAK,UACH,SAACkB,EAAI,CAAK,OAACJ,EAAQI,CAAT,EACV,SAACV,EAAQ,CAAK,OAAAK,EAAOL,CAAG,CAAV,EACd,UAAA,CAAM,OAAAI,EAAQE,CAAK,CAAb,CAAc,CAExB,CAAC,CACH,EA1aOrB,EAAA,OAAkC,SAAIC,EAAwD,CACnG,OAAO,IAAID,EAAcC,CAAS,CACpC,EAyaFD,GA9cA,EAudA,SAAS0B,GAAeC,EAA+C,OACrE,OAAOC,EAAAD,GAAW,KAAXA,EAAeE,GAAO,WAAO,MAAAD,IAAA,OAAAA,EAAI,OAC1C,CAEA,SAASE,GAAcC,EAAU,CAC/B,OAAOA,GAASC,EAAWD,EAAM,IAAI,GAAKC,EAAWD,EAAM,KAAK,GAAKC,EAAWD,EAAM,QAAQ,CAChG,CAEA,SAASE,GAAgBF,EAAU,CACjC,OAAQA,GAASA,aAAiBG,IAAgBJ,GAAWC,CAAK,GAAKI,GAAeJ,CAAK,CAC7F,CCzeM,SAAUK,GAAQC,EAAW,CACjC,OAAOC,EAAWD,GAAM,KAAA,OAANA,EAAQ,IAAI,CAChC,CAMM,SAAUE,EACdC,EAAqF,CAErF,OAAO,SAACH,EAAqB,CAC3B,GAAID,GAAQC,CAAM,EAChB,OAAOA,EAAO,KAAK,SAA+BI,EAA2B,CAC3E,GAAI,CACF,OAAOD,EAAKC,EAAc,IAAI,QACvBC,EAAK,CACZ,KAAK,MAAMA,CAAG,EAElB,CAAC,EAEH,MAAM,IAAI,UAAU,wCAAwC,CAC9D,CACF,CCjBM,SAAUC,EACdC,EACAC,EACAC,EACAC,EACAC,EAAuB,CAEvB,OAAO,IAAIC,GAAmBL,EAAaC,EAAQC,EAAYC,EAASC,CAAU,CACpF,CAMA,IAAAC,GAAA,SAAAC,EAAA,CAA2CC,GAAAF,EAAAC,CAAA,EAiBzC,SAAAD,EACEL,EACAC,EACAC,EACAC,EACQC,EACAI,EAAiC,CAN3C,IAAAC,EAoBEH,EAAA,KAAA,KAAMN,CAAW,GAAC,KAfV,OAAAS,EAAA,WAAAL,EACAK,EAAA,kBAAAD,EAeRC,EAAK,MAAQR,EACT,SAAuCS,EAAQ,CAC7C,GAAI,CACFT,EAAOS,CAAK,QACLC,EAAK,CACZX,EAAY,MAAMW,CAAG,EAEzB,EACAL,EAAA,UAAM,MACVG,EAAK,OAASN,EACV,SAAuCQ,EAAQ,CAC7C,GAAI,CACFR,EAAQQ,CAAG,QACJA,EAAK,CAEZX,EAAY,MAAMW,CAAG,UAGrB,KAAK,YAAW,EAEpB,EACAL,EAAA,UAAM,OACVG,EAAK,UAAYP,EACb,UAAA,CACE,GAAI,CACFA,EAAU,QACHS,EAAK,CAEZX,EAAY,MAAMW,CAAG,UAGrB,KAAK,YAAW,EAEpB,EACAL,EAAA,UAAM,WACZ,CAEA,OAAAD,EAAA,UAAA,YAAA,UAAA,OACE,GAAI,CAAC,KAAK,mBAAqB,KAAK,kBAAiB,EAAI,CAC/C,IAAAO,EAAW,KAAI,OACvBN,EAAA,UAAM,YAAW,KAAA,IAAA,EAEjB,CAACM,KAAUC,EAAA,KAAK,cAAU,MAAAA,IAAA,QAAAA,EAAA,KAAf,IAAI,GAEnB,EACFR,CAAA,EAnF2CS,EAAU,ECd9C,IAAMC,GAAiD,CAG5D,SAAA,SAASC,EAAQ,CACf,IAAIC,EAAU,sBACVC,EAAkD,qBAC9CC,EAAaJ,GAAsB,SACvCI,IACFF,EAAUE,EAAS,sBACnBD,EAASC,EAAS,sBAEpB,IAAMC,EAASH,EAAQ,SAACI,EAAS,CAI/BH,EAAS,OACTF,EAASK,CAAS,CACpB,CAAC,EACD,OAAO,IAAIC,GAAa,UAAA,CAAM,OAAAJ,GAAM,KAAA,OAANA,EAASE,CAAM,CAAf,CAAgB,CAChD,EACA,sBAAqB,UAAA,SAACG,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACZ,IAAAL,EAAaJ,GAAsB,SAC3C,QAAQI,GAAQ,KAAA,OAARA,EAAU,wBAAyB,uBAAsB,MAAA,OAAAM,EAAA,CAAA,EAAAC,EAAIH,CAAI,CAAA,CAAA,CAC3E,EACA,qBAAoB,UAAA,SAACA,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACX,IAAAL,EAAaJ,GAAsB,SAC3C,QAAQI,GAAQ,KAAA,OAARA,EAAU,uBAAwB,sBAAqB,MAAA,OAAAM,EAAA,CAAA,EAAAC,EAAIH,CAAI,CAAA,CAAA,CACzE,EACA,SAAU,QCrBL,IAAMI,GAAuDC,GAClE,SAACC,EAAM,CACL,OAAA,UAAoC,CAClCA,EAAO,IAAI,EACX,KAAK,KAAO,0BACZ,KAAK,QAAU,qBACjB,CAJA,CAIC,ECXL,IAAAC,EAAA,SAAAC,EAAA,CAAgCC,GAAAF,EAAAC,CAAA,EAwB9B,SAAAD,GAAA,CAAA,IAAAG,EAEEF,EAAA,KAAA,IAAA,GAAO,KAzBT,OAAAE,EAAA,OAAS,GAEDA,EAAA,iBAAyC,KAGjDA,EAAA,UAA2B,CAAA,EAE3BA,EAAA,UAAY,GAEZA,EAAA,SAAW,GAEXA,EAAA,YAAmB,MAenB,CAGA,OAAAH,EAAA,UAAA,KAAA,SAAQI,EAAwB,CAC9B,IAAMC,EAAU,IAAIC,GAAiB,KAAM,IAAI,EAC/C,OAAAD,EAAQ,SAAWD,EACZC,CACT,EAGUL,EAAA,UAAA,eAAV,UAAA,CACE,GAAI,KAAK,OACP,MAAM,IAAIO,EAEd,EAEAP,EAAA,UAAA,KAAA,SAAKQ,EAAQ,CAAb,IAAAL,EAAA,KACEM,GAAa,UAAA,SAEX,GADAN,EAAK,eAAc,EACf,CAACA,EAAK,UAAW,CACdA,EAAK,mBACRA,EAAK,iBAAmB,MAAM,KAAKA,EAAK,SAAS,OAEnD,QAAuBO,EAAAC,GAAAR,EAAK,gBAAgB,EAAAS,EAAAF,EAAA,KAAA,EAAA,CAAAE,EAAA,KAAAA,EAAAF,EAAA,KAAA,EAAE,CAAzC,IAAMG,EAAQD,EAAA,MACjBC,EAAS,KAAKL,CAAK,qGAGzB,CAAC,CACH,EAEAR,EAAA,UAAA,MAAA,SAAMc,EAAQ,CAAd,IAAAX,EAAA,KACEM,GAAa,UAAA,CAEX,GADAN,EAAK,eAAc,EACf,CAACA,EAAK,UAAW,CACnBA,EAAK,SAAWA,EAAK,UAAY,GACjCA,EAAK,YAAcW,EAEnB,QADQC,EAAcZ,EAAI,UACnBY,EAAU,QACfA,EAAU,MAAK,EAAI,MAAMD,CAAG,EAGlC,CAAC,CACH,EAEAd,EAAA,UAAA,SAAA,UAAA,CAAA,IAAAG,EAAA,KACEM,GAAa,UAAA,CAEX,GADAN,EAAK,eAAc,EACf,CAACA,EAAK,UAAW,CACnBA,EAAK,UAAY,GAEjB,QADQY,EAAcZ,EAAI,UACnBY,EAAU,QACfA,EAAU,MAAK,EAAI,SAAQ,EAGjC,CAAC,CACH,EAEAf,EAAA,UAAA,YAAA,UAAA,CACE,KAAK,UAAY,KAAK,OAAS,GAC/B,KAAK,UAAY,KAAK,iBAAmB,IAC3C,EAEA,OAAA,eAAIA,EAAA,UAAA,WAAQ,KAAZ,UAAA,OACE,QAAOgB,EAAA,KAAK,aAAS,MAAAA,IAAA,OAAA,OAAAA,EAAE,QAAS,CAClC,kCAGUhB,EAAA,UAAA,cAAV,SAAwBiB,EAAyB,CAC/C,YAAK,eAAc,EACZhB,EAAA,UAAM,cAAa,KAAA,KAACgB,CAAU,CACvC,EAGUjB,EAAA,UAAA,WAAV,SAAqBiB,EAAyB,CAC5C,YAAK,eAAc,EACnB,KAAK,wBAAwBA,CAAU,EAChC,KAAK,gBAAgBA,CAAU,CACxC,EAGUjB,EAAA,UAAA,gBAAV,SAA0BiB,EAA2B,CAArD,IAAAd,EAAA,KACQa,EAAqC,KAAnCE,EAAQF,EAAA,SAAEG,EAASH,EAAA,UAAED,EAASC,EAAA,UACtC,OAAIE,GAAYC,EACPC,IAET,KAAK,iBAAmB,KACxBL,EAAU,KAAKE,CAAU,EAClB,IAAII,GAAa,UAAA,CACtBlB,EAAK,iBAAmB,KACxBmB,GAAUP,EAAWE,CAAU,CACjC,CAAC,EACH,EAGUjB,EAAA,UAAA,wBAAV,SAAkCiB,EAA2B,CACrD,IAAAD,EAAuC,KAArCE,EAAQF,EAAA,SAAEO,EAAWP,EAAA,YAAEG,EAASH,EAAA,UACpCE,EACFD,EAAW,MAAMM,CAAW,EACnBJ,GACTF,EAAW,SAAQ,CAEvB,EAQAjB,EAAA,UAAA,aAAA,UAAA,CACE,IAAMwB,EAAkB,IAAIC,EAC5B,OAAAD,EAAW,OAAS,KACbA,CACT,EAxHOxB,EAAA,OAAkC,SAAI0B,EAA0BC,EAAqB,CAC1F,OAAO,IAAIrB,GAAoBoB,EAAaC,CAAM,CACpD,EAuHF3B,GA7IgCyB,CAAU,EAkJ1C,IAAAG,GAAA,SAAAC,EAAA,CAAyCC,GAAAF,EAAAC,CAAA,EACvC,SAAAD,EAESG,EACPC,EAAsB,CAHxB,IAAAC,EAKEJ,EAAA,KAAA,IAAA,GAAO,KAHA,OAAAI,EAAA,YAAAF,EAIPE,EAAK,OAASD,GAChB,CAEA,OAAAJ,EAAA,UAAA,KAAA,SAAKM,EAAQ,UACXC,GAAAC,EAAA,KAAK,eAAW,MAAAA,IAAA,OAAA,OAAAA,EAAE,QAAI,MAAAD,IAAA,QAAAA,EAAA,KAAAC,EAAGF,CAAK,CAChC,EAEAN,EAAA,UAAA,MAAA,SAAMS,EAAQ,UACZF,GAAAC,EAAA,KAAK,eAAW,MAAAA,IAAA,OAAA,OAAAA,EAAE,SAAK,MAAAD,IAAA,QAAAA,EAAA,KAAAC,EAAGC,CAAG,CAC/B,EAEAT,EAAA,UAAA,SAAA,UAAA,UACEO,GAAAC,EAAA,KAAK,eAAW,MAAAA,IAAA,OAAA,OAAAA,EAAE,YAAQ,MAAAD,IAAA,QAAAA,EAAA,KAAAC,CAAA,CAC5B,EAGUR,EAAA,UAAA,WAAV,SAAqBU,EAAyB,SAC5C,OAAOH,GAAAC,EAAA,KAAK,UAAM,MAAAA,IAAA,OAAA,OAAAA,EAAE,UAAUE,CAAU,KAAC,MAAAH,IAAA,OAAAA,EAAII,EAC/C,EACFX,CAAA,EA1ByCY,CAAO,ECxJhD,IAAAC,GAAA,SAAAC,EAAA,CAAwCC,GAAAF,EAAAC,CAAA,EACtC,SAAAD,EAAoBG,EAAS,CAA7B,IAAAC,EACEH,EAAA,KAAA,IAAA,GAAO,KADW,OAAAG,EAAA,OAAAD,GAEpB,CAEA,cAAA,eAAIH,EAAA,UAAA,QAAK,KAAT,UAAA,CACE,OAAO,KAAK,SAAQ,CACtB,kCAGUA,EAAA,UAAA,WAAV,SAAqBK,EAAyB,CAC5C,IAAMC,EAAeL,EAAA,UAAM,WAAU,KAAA,KAACI,CAAU,EAChD,OAACC,EAAa,QAAUD,EAAW,KAAK,KAAK,MAAM,EAC5CC,CACT,EAEAN,EAAA,UAAA,SAAA,UAAA,CACQ,IAAAO,EAAoC,KAAlCC,EAAQD,EAAA,SAAEE,EAAWF,EAAA,YAAEJ,EAAMI,EAAA,OACrC,GAAIC,EACF,MAAMC,EAER,YAAK,eAAc,EACZN,CACT,EAEAH,EAAA,UAAA,KAAA,SAAKU,EAAQ,CACXT,EAAA,UAAM,KAAI,KAAA,KAAE,KAAK,OAASS,CAAM,CAClC,EACFV,CAAA,EA5BwCW,CAAO,ECJxC,IAAMC,GAA+C,CAC1D,IAAG,UAAA,CAGD,OAAQA,GAAsB,UAAY,MAAM,IAAG,CACrD,EACA,SAAU,QCwBZ,IAAAC,GAAA,SAAAC,EAAA,CAAsCC,GAAAF,EAAAC,CAAA,EAUpC,SAAAD,EACUG,EACAC,EACAC,EAA6D,CAF7DF,IAAA,SAAAA,EAAA,KACAC,IAAA,SAAAA,EAAA,KACAC,IAAA,SAAAA,EAAAC,IAHV,IAAAC,EAKEN,EAAA,KAAA,IAAA,GAAO,KAJC,OAAAM,EAAA,YAAAJ,EACAI,EAAA,YAAAH,EACAG,EAAA,mBAAAF,EAZFE,EAAA,QAA0B,CAAA,EAC1BA,EAAA,oBAAsB,GAc5BA,EAAK,oBAAsBH,IAAgB,IAC3CG,EAAK,YAAc,KAAK,IAAI,EAAGJ,CAAW,EAC1CI,EAAK,YAAc,KAAK,IAAI,EAAGH,CAAW,GAC5C,CAEA,OAAAJ,EAAA,UAAA,KAAA,SAAKQ,EAAQ,CACL,IAAAC,EAA+E,KAA7EC,EAASD,EAAA,UAAEE,EAAOF,EAAA,QAAEG,EAAmBH,EAAA,oBAAEJ,EAAkBI,EAAA,mBAAEL,EAAWK,EAAA,YAC3EC,IACHC,EAAQ,KAAKH,CAAK,EAClB,CAACI,GAAuBD,EAAQ,KAAKN,EAAmB,IAAG,EAAKD,CAAW,GAE7E,KAAK,YAAW,EAChBH,EAAA,UAAM,KAAI,KAAA,KAACO,CAAK,CAClB,EAGUR,EAAA,UAAA,WAAV,SAAqBa,EAAyB,CAC5C,KAAK,eAAc,EACnB,KAAK,YAAW,EAQhB,QANMC,EAAe,KAAK,gBAAgBD,CAAU,EAE9CJ,EAAmC,KAAjCG,EAAmBH,EAAA,oBAAEE,EAAOF,EAAA,QAG9BM,EAAOJ,EAAQ,MAAK,EACjBK,EAAI,EAAGA,EAAID,EAAK,QAAU,CAACF,EAAW,OAAQG,GAAKJ,EAAsB,EAAI,EACpFC,EAAW,KAAKE,EAAKC,CAAC,CAAM,EAG9B,YAAK,wBAAwBH,CAAU,EAEhCC,CACT,EAEQd,EAAA,UAAA,YAAR,UAAA,CACQ,IAAAS,EAAoE,KAAlEN,EAAWM,EAAA,YAAEJ,EAAkBI,EAAA,mBAAEE,EAAOF,EAAA,QAAEG,EAAmBH,EAAA,oBAK/DQ,GAAsBL,EAAsB,EAAI,GAAKT,EAK3D,GAJAA,EAAc,KAAYc,EAAqBN,EAAQ,QAAUA,EAAQ,OAAO,EAAGA,EAAQ,OAASM,CAAkB,EAIlH,CAACL,EAAqB,CAKxB,QAJMM,EAAMb,EAAmB,IAAG,EAC9Bc,EAAO,EAGFH,EAAI,EAAGA,EAAIL,EAAQ,QAAWA,EAAQK,CAAC,GAAgBE,EAAKF,GAAK,EACxEG,EAAOH,EAETG,GAAQR,EAAQ,OAAO,EAAGQ,EAAO,CAAC,EAEtC,EACFnB,CAAA,EAzEsCoB,CAAO,EClB7C,IAAAC,GAAA,SAAAC,EAAA,CAA+BC,GAAAF,EAAAC,CAAA,EAC7B,SAAAD,EAAYG,EAAsBC,EAAmD,QACnFH,EAAA,KAAA,IAAA,GAAO,IACT,CAWO,OAAAD,EAAA,UAAA,SAAP,SAAgBK,EAAWC,EAAiB,CAAjB,OAAAA,IAAA,SAAAA,EAAA,GAClB,IACT,EACFN,CAAA,EAjB+BO,EAAY,ECHpC,IAAMC,GAAqC,CAGhD,YAAA,SAAYC,EAAqBC,EAAgB,SAAEC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,EAAA,CAAA,EAAA,UAAAA,CAAA,EACzC,IAAAC,EAAaL,GAAgB,SACrC,OAAIK,GAAQ,MAARA,EAAU,YACLA,EAAS,YAAW,MAApBA,EAAQC,EAAA,CAAaL,EAASC,CAAO,EAAAK,EAAKJ,CAAI,CAAA,CAAA,EAEhD,YAAW,MAAA,OAAAG,EAAA,CAACL,EAASC,CAAO,EAAAK,EAAKJ,CAAI,CAAA,CAAA,CAC9C,EACA,cAAA,SAAcK,EAAM,CACV,IAAAH,EAAaL,GAAgB,SACrC,QAAQK,GAAQ,KAAA,OAARA,EAAU,gBAAiB,eAAeG,CAAa,CACjE,EACA,SAAU,QCrBZ,IAAAC,GAAA,SAAAC,EAAA,CAAoCC,GAAAF,EAAAC,CAAA,EAOlC,SAAAD,EAAsBG,EAAqCC,EAAmD,CAA9G,IAAAC,EACEJ,EAAA,KAAA,KAAME,EAAWC,CAAI,GAAC,KADF,OAAAC,EAAA,UAAAF,EAAqCE,EAAA,KAAAD,EAFjDC,EAAA,QAAmB,IAI7B,CAEO,OAAAL,EAAA,UAAA,SAAP,SAAgBM,EAAWC,EAAiB,OAC1C,GADyBA,IAAA,SAAAA,EAAA,GACrB,KAAK,OACP,OAAO,KAIT,KAAK,MAAQD,EAEb,IAAME,EAAK,KAAK,GACVL,EAAY,KAAK,UAuBvB,OAAIK,GAAM,OACR,KAAK,GAAK,KAAK,eAAeL,EAAWK,EAAID,CAAK,GAKpD,KAAK,QAAU,GAEf,KAAK,MAAQA,EAEb,KAAK,IAAKE,EAAA,KAAK,MAAE,MAAAA,IAAA,OAAAA,EAAI,KAAK,eAAeN,EAAW,KAAK,GAAII,CAAK,EAE3D,IACT,EAEUP,EAAA,UAAA,eAAV,SAAyBG,EAA2BO,EAAmBH,EAAiB,CAAjB,OAAAA,IAAA,SAAAA,EAAA,GAC9DI,GAAiB,YAAYR,EAAU,MAAM,KAAKA,EAAW,IAAI,EAAGI,CAAK,CAClF,EAEUP,EAAA,UAAA,eAAV,SAAyBY,EAA4BJ,EAAkBD,EAAwB,CAE7F,GAFqEA,IAAA,SAAAA,EAAA,GAEjEA,GAAS,MAAQ,KAAK,QAAUA,GAAS,KAAK,UAAY,GAC5D,OAAOC,EAILA,GAAM,MACRG,GAAiB,cAAcH,CAAE,CAIrC,EAMOR,EAAA,UAAA,QAAP,SAAeM,EAAUC,EAAa,CACpC,GAAI,KAAK,OACP,OAAO,IAAI,MAAM,8BAA8B,EAGjD,KAAK,QAAU,GACf,IAAMM,EAAQ,KAAK,SAASP,EAAOC,CAAK,EACxC,GAAIM,EACF,OAAOA,EACE,KAAK,UAAY,IAAS,KAAK,IAAM,OAc9C,KAAK,GAAK,KAAK,eAAe,KAAK,UAAW,KAAK,GAAI,IAAI,EAE/D,EAEUb,EAAA,UAAA,SAAV,SAAmBM,EAAUQ,EAAc,CACzC,IAAIC,EAAmB,GACnBC,EACJ,GAAI,CACF,KAAK,KAAKV,CAAK,QACRW,EAAG,CACVF,EAAU,GAIVC,EAAaC,GAAQ,IAAI,MAAM,oCAAoC,EAErE,GAAIF,EACF,YAAK,YAAW,EACTC,CAEX,EAEAhB,EAAA,UAAA,YAAA,UAAA,CACE,GAAI,CAAC,KAAK,OAAQ,CACV,IAAAS,EAAoB,KAAlBD,EAAEC,EAAA,GAAEN,EAASM,EAAA,UACbS,EAAYf,EAAS,QAE7B,KAAK,KAAO,KAAK,MAAQ,KAAK,UAAY,KAC1C,KAAK,QAAU,GAEfgB,GAAUD,EAAS,IAAI,EACnBV,GAAM,OACR,KAAK,GAAK,KAAK,eAAeL,EAAWK,EAAI,IAAI,GAGnD,KAAK,MAAQ,KACbP,EAAA,UAAM,YAAW,KAAA,IAAA,EAErB,EACFD,CAAA,EA9IoCoB,EAAM,ECgB1C,IAAAC,GAAA,UAAA,CAGE,SAAAA,EAAoBC,EAAoCC,EAAiC,CAAjCA,IAAA,SAAAA,EAAoBF,EAAU,KAAlE,KAAA,oBAAAC,EAClB,KAAK,IAAMC,CACb,CA6BO,OAAAF,EAAA,UAAA,SAAP,SAAmBG,EAAqDC,EAAmBC,EAAS,CAA5B,OAAAD,IAAA,SAAAA,EAAA,GAC/D,IAAI,KAAK,oBAAuB,KAAMD,CAAI,EAAE,SAASE,EAAOD,CAAK,CAC1E,EAnCcJ,EAAA,IAAoBM,GAAsB,IAoC1DN,GArCA,ECnBA,IAAAO,GAAA,SAAAC,EAAA,CAAoCC,GAAAF,EAAAC,CAAA,EAkBlC,SAAAD,EAAYG,EAAgCC,EAAiC,CAAjCA,IAAA,SAAAA,EAAoBC,GAAU,KAA1E,IAAAC,EACEL,EAAA,KAAA,KAAME,EAAiBC,CAAG,GAAC,KAlBtB,OAAAE,EAAA,QAAmC,CAAA,EAOnCA,EAAA,QAAmB,IAY1B,CAEO,OAAAN,EAAA,UAAA,MAAP,SAAaO,EAAwB,CAC3B,IAAAC,EAAY,KAAI,QAExB,GAAI,KAAK,QAAS,CAChBA,EAAQ,KAAKD,CAAM,EACnB,OAGF,IAAIE,EACJ,KAAK,QAAU,GAEf,EACE,IAAKA,EAAQF,EAAO,QAAQA,EAAO,MAAOA,EAAO,KAAK,EACpD,YAEMA,EAASC,EAAQ,MAAK,GAIhC,GAFA,KAAK,QAAU,GAEXC,EAAO,CACT,KAAQF,EAASC,EAAQ,MAAK,GAC5BD,EAAO,YAAW,EAEpB,MAAME,EAEV,EACFT,CAAA,EAhDoCK,EAAS,EC6CtC,IAAMK,GAAiB,IAAIC,GAAeC,EAAW,EAK/CC,GAAQH,GCjDrB,IAAAI,GAAA,SAAAC,EAAA,CAAoCC,GAAAF,EAAAC,CAAA,EAClC,SAAAD,EAAsBG,EAAqCC,EAAmD,CAA9G,IAAAC,EACEJ,EAAA,KAAA,KAAME,EAAWC,CAAI,GAAC,KADF,OAAAC,EAAA,UAAAF,EAAqCE,EAAA,KAAAD,GAE3D,CAEO,OAAAJ,EAAA,UAAA,SAAP,SAAgBM,EAAWC,EAAiB,CAC1C,OADyBA,IAAA,SAAAA,EAAA,GACrBA,EAAQ,EACHN,EAAA,UAAM,SAAQ,KAAA,KAACK,EAAOC,CAAK,GAEpC,KAAK,MAAQA,EACb,KAAK,MAAQD,EACb,KAAK,UAAU,MAAM,IAAI,EAClB,KACT,EAEON,EAAA,UAAA,QAAP,SAAeM,EAAUC,EAAa,CACpC,OAAOA,EAAQ,GAAK,KAAK,OAASN,EAAA,UAAM,QAAO,KAAA,KAACK,EAAOC,CAAK,EAAI,KAAK,SAASD,EAAOC,CAAK,CAC5F,EAEUP,EAAA,UAAA,eAAV,SAAyBG,EAA2BK,EAAkBD,EAAiB,CAKrF,OALoEA,IAAA,SAAAA,EAAA,GAK/DA,GAAS,MAAQA,EAAQ,GAAOA,GAAS,MAAQ,KAAK,MAAQ,EAC1DN,EAAA,UAAM,eAAc,KAAA,KAACE,EAAWK,EAAID,CAAK,GAIlDJ,EAAU,MAAM,IAAI,EAMb,EACT,EACFH,CAAA,EArCoCS,EAAW,ECJ/C,IAAAC,GAAA,SAAAC,EAAA,CAAoCC,GAAAF,EAAAC,CAAA,EAApC,SAAAD,GAAA,+CACA,CAAA,OAAAA,CAAA,EADoCG,EAAc,ECgE3C,IAAMC,GAAiB,IAAIC,GAAeC,EAAW,EC5D5D,IAAAC,GAAA,SAAAC,EAAA,CAA6CC,GAAAF,EAAAC,CAAA,EAC3C,SAAAD,EAAsBG,EAA8CC,EAAmD,CAAvH,IAAAC,EACEJ,EAAA,KAAA,KAAME,EAAWC,CAAI,GAAC,KADF,OAAAC,EAAA,UAAAF,EAA8CE,EAAA,KAAAD,GAEpE,CAEU,OAAAJ,EAAA,UAAA,eAAV,SAAyBG,EAAoCG,EAAkBC,EAAiB,CAE9F,OAF6EA,IAAA,SAAAA,EAAA,GAEzEA,IAAU,MAAQA,EAAQ,EACrBN,EAAA,UAAM,eAAc,KAAA,KAACE,EAAWG,EAAIC,CAAK,GAGlDJ,EAAU,QAAQ,KAAK,IAAI,EAIpBA,EAAU,aAAeA,EAAU,WAAaK,GAAuB,sBAAsB,UAAA,CAAM,OAAAL,EAAU,MAAM,MAAS,CAAzB,CAA0B,GACtI,EAEUH,EAAA,UAAA,eAAV,SAAyBG,EAAoCG,EAAkBC,EAAiB,OAI9F,GAJ6EA,IAAA,SAAAA,EAAA,GAIzEA,GAAS,KAAOA,EAAQ,EAAI,KAAK,MAAQ,EAC3C,OAAON,EAAA,UAAM,eAAc,KAAA,KAACE,EAAWG,EAAIC,CAAK,EAK1C,IAAAE,EAAYN,EAAS,QACzBG,GAAM,QAAQI,EAAAD,EAAQA,EAAQ,OAAS,CAAC,KAAC,MAAAC,IAAA,OAAA,OAAAA,EAAE,MAAOJ,IACpDE,GAAuB,qBAAqBF,CAAY,EACxDH,EAAU,WAAa,OAI3B,EACFH,CAAA,EApC6CW,EAAW,ECHxD,IAAAC,GAAA,SAAAC,EAAA,CAA6CC,GAAAF,EAAAC,CAAA,EAA7C,SAAAD,GAAA,+CAkCA,CAjCS,OAAAA,EAAA,UAAA,MAAP,SAAaG,EAAyB,CACpC,KAAK,QAAU,GAUf,IAAMC,EAAU,KAAK,WACrB,KAAK,WAAa,OAEV,IAAAC,EAAY,KAAI,QACpBC,EACJH,EAASA,GAAUE,EAAQ,MAAK,EAEhC,EACE,IAAKC,EAAQH,EAAO,QAAQA,EAAO,MAAOA,EAAO,KAAK,EACpD,aAEMA,EAASE,EAAQ,CAAC,IAAMF,EAAO,KAAOC,GAAWC,EAAQ,MAAK,GAIxE,GAFA,KAAK,QAAU,GAEXC,EAAO,CACT,MAAQH,EAASE,EAAQ,CAAC,IAAMF,EAAO,KAAOC,GAAWC,EAAQ,MAAK,GACpEF,EAAO,YAAW,EAEpB,MAAMG,EAEV,EACFN,CAAA,EAlC6CO,EAAc,ECgCpD,IAAMC,GAA0B,IAAIC,GAAwBC,EAAoB,EC8BhF,IAAMC,EAAQ,IAAIC,EAAkB,SAACC,EAAU,CAAK,OAAAA,EAAW,SAAQ,CAAnB,CAAqB,EC9D1E,SAAUC,GAAYC,EAAU,CACpC,OAAOA,GAASC,EAAWD,EAAM,QAAQ,CAC3C,CCDA,SAASE,GAAQC,EAAQ,CACvB,OAAOA,EAAIA,EAAI,OAAS,CAAC,CAC3B,CAEM,SAAUC,GAAkBC,EAAW,CAC3C,OAAOC,EAAWJ,GAAKG,CAAI,CAAC,EAAIA,EAAK,IAAG,EAAK,MAC/C,CAEM,SAAUE,GAAaF,EAAW,CACtC,OAAOG,GAAYN,GAAKG,CAAI,CAAC,EAAIA,EAAK,IAAG,EAAK,MAChD,CAEM,SAAUI,GAAUJ,EAAaK,EAAoB,CACzD,OAAO,OAAOR,GAAKG,CAAI,GAAM,SAAWA,EAAK,IAAG,EAAMK,CACxD,CClBO,IAAMC,GAAe,SAAIC,EAAM,CAAwB,OAAAA,GAAK,OAAOA,EAAE,QAAW,UAAY,OAAOA,GAAM,UAAlD,ECMxD,SAAUC,GAAUC,EAAU,CAClC,OAAOC,EAAWD,GAAK,KAAA,OAALA,EAAO,IAAI,CAC/B,CCHM,SAAUE,GAAoBC,EAAU,CAC5C,OAAOC,EAAWD,EAAME,EAAiB,CAAC,CAC5C,CCLM,SAAUC,GAAmBC,EAAQ,CACzC,OAAO,OAAO,eAAiBC,EAAWD,GAAG,KAAA,OAAHA,EAAM,OAAO,aAAa,CAAC,CACvE,CCAM,SAAUE,GAAiCC,EAAU,CAEzD,OAAO,IAAI,UACT,iBACEA,IAAU,MAAQ,OAAOA,GAAU,SAAW,oBAAsB,IAAIA,EAAK,KAAG,0HACwC,CAE9H,CCXM,SAAUC,IAAiB,CAC/B,OAAI,OAAO,QAAW,YAAc,CAAC,OAAO,SACnC,aAGF,OAAO,QAChB,CAEO,IAAMC,GAAWD,GAAiB,ECJnC,SAAUE,GAAWC,EAAU,CACnC,OAAOC,EAAWD,GAAK,KAAA,OAALA,EAAQE,EAAe,CAAC,CAC5C,CCHM,SAAiBC,GAAsCC,EAAqC,mGAC1FC,EAASD,EAAe,UAAS,2DAGX,MAAA,CAAA,EAAAE,GAAMD,EAAO,KAAI,CAAE,CAAA,gBAArCE,EAAkBC,EAAA,KAAA,EAAhBC,EAAKF,EAAA,MAAEG,EAAIH,EAAA,KACfG,iBAAA,CAAA,EAAA,CAAA,SACF,MAAA,CAAA,EAAAF,EAAA,KAAA,CAAA,qBAEIC,CAAM,CAAA,SAAZ,MAAA,CAAA,EAAAD,EAAA,KAAA,CAAA,SAAA,OAAAA,EAAA,KAAA,mCAGF,OAAAH,EAAO,YAAW,6BAIhB,SAAUM,GAAwBC,EAAQ,CAG9C,OAAOC,EAAWD,GAAG,KAAA,OAAHA,EAAK,SAAS,CAClC,CCPM,SAAUE,EAAaC,EAAyB,CACpD,GAAIA,aAAiBC,EACnB,OAAOD,EAET,GAAIA,GAAS,KAAM,CACjB,GAAIE,GAAoBF,CAAK,EAC3B,OAAOG,GAAsBH,CAAK,EAEpC,GAAII,GAAYJ,CAAK,EACnB,OAAOK,GAAcL,CAAK,EAE5B,GAAIM,GAAUN,CAAK,EACjB,OAAOO,GAAYP,CAAK,EAE1B,GAAIQ,GAAgBR,CAAK,EACvB,OAAOS,GAAkBT,CAAK,EAEhC,GAAIU,GAAWV,CAAK,EAClB,OAAOW,GAAaX,CAAK,EAE3B,GAAIY,GAAqBZ,CAAK,EAC5B,OAAOa,GAAuBb,CAAK,EAIvC,MAAMc,GAAiCd,CAAK,CAC9C,CAMM,SAAUG,GAAyBY,EAAQ,CAC/C,OAAO,IAAId,EAAW,SAACe,EAAyB,CAC9C,IAAMC,EAAMF,EAAIG,EAAiB,EAAC,EAClC,GAAIC,EAAWF,EAAI,SAAS,EAC1B,OAAOA,EAAI,UAAUD,CAAU,EAGjC,MAAM,IAAI,UAAU,gEAAgE,CACtF,CAAC,CACH,CASM,SAAUX,GAAiBe,EAAmB,CAClD,OAAO,IAAInB,EAAW,SAACe,EAAyB,CAU9C,QAASK,EAAI,EAAGA,EAAID,EAAM,QAAU,CAACJ,EAAW,OAAQK,IACtDL,EAAW,KAAKI,EAAMC,CAAC,CAAC,EAE1BL,EAAW,SAAQ,CACrB,CAAC,CACH,CAEM,SAAUT,GAAee,EAAuB,CACpD,OAAO,IAAIrB,EAAW,SAACe,EAAyB,CAC9CM,EACG,KACC,SAACC,EAAK,CACCP,EAAW,SACdA,EAAW,KAAKO,CAAK,EACrBP,EAAW,SAAQ,EAEvB,EACA,SAACQ,EAAQ,CAAK,OAAAR,EAAW,MAAMQ,CAAG,CAApB,CAAqB,EAEpC,KAAK,KAAMC,EAAoB,CACpC,CAAC,CACH,CAEM,SAAUd,GAAgBe,EAAqB,CACnD,OAAO,IAAIzB,EAAW,SAACe,EAAyB,aAC9C,QAAoBW,EAAAC,GAAAF,CAAQ,EAAAG,EAAAF,EAAA,KAAA,EAAA,CAAAE,EAAA,KAAAA,EAAAF,EAAA,KAAA,EAAE,CAAzB,IAAMJ,EAAKM,EAAA,MAEd,GADAb,EAAW,KAAKO,CAAK,EACjBP,EAAW,OACb,yGAGJA,EAAW,SAAQ,CACrB,CAAC,CACH,CAEM,SAAUP,GAAqBqB,EAA+B,CAClE,OAAO,IAAI7B,EAAW,SAACe,EAAyB,CAC9Ce,GAAQD,EAAed,CAAU,EAAE,MAAM,SAACQ,EAAG,CAAK,OAAAR,EAAW,MAAMQ,CAAG,CAApB,CAAqB,CACzE,CAAC,CACH,CAEM,SAAUX,GAA0BmB,EAAqC,CAC7E,OAAOvB,GAAkBwB,GAAmCD,CAAc,CAAC,CAC7E,CAEA,SAAeD,GAAWD,EAAiCd,EAAyB,uIACxDkB,EAAAC,GAAAL,CAAa,gFAIrC,GAJeP,EAAKa,EAAA,MACpBpB,EAAW,KAAKO,CAAK,EAGjBP,EAAW,OACb,MAAA,CAAA,CAAA,6RAGJ,OAAAA,EAAW,SAAQ,WChHf,SAAUqB,GACdC,EACAC,EACAC,EACAC,EACAC,EAAc,CADdD,IAAA,SAAAA,EAAA,GACAC,IAAA,SAAAA,EAAA,IAEA,IAAMC,EAAuBJ,EAAU,SAAS,UAAA,CAC9CC,EAAI,EACAE,EACFJ,EAAmB,IAAI,KAAK,SAAS,KAAMG,CAAK,CAAC,EAEjD,KAAK,YAAW,CAEpB,EAAGA,CAAK,EAIR,GAFAH,EAAmB,IAAIK,CAAoB,EAEvC,CAACD,EAKH,OAAOC,CAEX,CCeM,SAAUC,GAAaC,EAA0BC,EAAS,CAAT,OAAAA,IAAA,SAAAA,EAAA,GAC9CC,EAAQ,SAACC,EAAQC,EAAU,CAChCD,EAAO,UACLE,EACED,EACA,SAACE,EAAK,CAAK,OAAAC,GAAgBH,EAAYJ,EAAW,UAAA,CAAM,OAAAI,EAAW,KAAKE,CAAK,CAArB,EAAwBL,CAAK,CAA1E,EACX,UAAA,CAAM,OAAAM,GAAgBH,EAAYJ,EAAW,UAAA,CAAM,OAAAI,EAAW,SAAQ,CAAnB,EAAuBH,CAAK,CAAzE,EACN,SAACO,EAAG,CAAK,OAAAD,GAAgBH,EAAYJ,EAAW,UAAA,CAAM,OAAAI,EAAW,MAAMI,CAAG,CAApB,EAAuBP,CAAK,CAAzE,CAA0E,CACpF,CAEL,CAAC,CACH,CCPM,SAAUQ,GAAeC,EAA0BC,EAAiB,CAAjB,OAAAA,IAAA,SAAAA,EAAA,GAChDC,EAAQ,SAACC,EAAQC,EAAU,CAChCA,EAAW,IAAIJ,EAAU,SAAS,UAAA,CAAM,OAAAG,EAAO,UAAUC,CAAU,CAA3B,EAA8BH,CAAK,CAAC,CAC9E,CAAC,CACH,CC7DM,SAAUI,GAAsBC,EAA6BC,EAAwB,CACzF,OAAOC,EAAUF,CAAK,EAAE,KAAKG,GAAYF,CAAS,EAAGG,GAAUH,CAAS,CAAC,CAC3E,CCFM,SAAUI,GAAmBC,EAAuBC,EAAwB,CAChF,OAAOC,EAAUF,CAAK,EAAE,KAAKG,GAAYF,CAAS,EAAGG,GAAUH,CAAS,CAAC,CAC3E,CCJM,SAAUI,GAAiBC,EAAqBC,EAAwB,CAC5E,OAAO,IAAIC,EAAc,SAACC,EAAU,CAElC,IAAIC,EAAI,EAER,OAAOH,EAAU,SAAS,UAAA,CACpBG,IAAMJ,EAAM,OAGdG,EAAW,SAAQ,GAInBA,EAAW,KAAKH,EAAMI,GAAG,CAAC,EAIrBD,EAAW,QACd,KAAK,SAAQ,EAGnB,CAAC,CACH,CAAC,CACH,CCfM,SAAUE,GAAoBC,EAAoBC,EAAwB,CAC9E,OAAO,IAAIC,EAAc,SAACC,EAAU,CAClC,IAAIC,EAKJ,OAAAC,GAAgBF,EAAYF,EAAW,UAAA,CAErCG,EAAYJ,EAAcI,EAAe,EAAC,EAE1CC,GACEF,EACAF,EACA,UAAA,OACMK,EACAC,EACJ,GAAI,CAEDC,EAAkBJ,EAAS,KAAI,EAA7BE,EAAKE,EAAA,MAAED,EAAIC,EAAA,WACPC,EAAK,CAEZN,EAAW,MAAMM,CAAG,EACpB,OAGEF,EAKFJ,EAAW,SAAQ,EAGnBA,EAAW,KAAKG,CAAK,CAEzB,EACA,EACA,EAAI,CAER,CAAC,EAMM,UAAA,CAAM,OAAAI,EAAWN,GAAQ,KAAA,OAARA,EAAU,MAAM,GAAKA,EAAS,OAAM,CAA/C,CACf,CAAC,CACH,CCvDM,SAAUO,GAAyBC,EAAyBC,EAAwB,CACxF,GAAI,CAACD,EACH,MAAM,IAAI,MAAM,yBAAyB,EAE3C,OAAO,IAAIE,EAAc,SAACC,EAAU,CAClCC,GAAgBD,EAAYF,EAAW,UAAA,CACrC,IAAMI,EAAWL,EAAM,OAAO,aAAa,EAAC,EAC5CI,GACED,EACAF,EACA,UAAA,CACEI,EAAS,KAAI,EAAG,KAAK,SAACC,EAAM,CACtBA,EAAO,KAGTH,EAAW,SAAQ,EAEnBA,EAAW,KAAKG,EAAO,KAAK,CAEhC,CAAC,CACH,EACA,EACA,EAAI,CAER,CAAC,CACH,CAAC,CACH,CCzBM,SAAUC,GAA8BC,EAA8BC,EAAwB,CAClG,OAAOC,GAAsBC,GAAmCH,CAAK,EAAGC,CAAS,CACnF,CCoBM,SAAUG,GAAaC,EAA2BC,EAAwB,CAC9E,GAAID,GAAS,KAAM,CACjB,GAAIE,GAAoBF,CAAK,EAC3B,OAAOG,GAAmBH,EAAOC,CAAS,EAE5C,GAAIG,GAAYJ,CAAK,EACnB,OAAOK,GAAcL,EAAOC,CAAS,EAEvC,GAAIK,GAAUN,CAAK,EACjB,OAAOO,GAAgBP,EAAOC,CAAS,EAEzC,GAAIO,GAAgBR,CAAK,EACvB,OAAOS,GAAsBT,EAAOC,CAAS,EAE/C,GAAIS,GAAWV,CAAK,EAClB,OAAOW,GAAiBX,EAAOC,CAAS,EAE1C,GAAIW,GAAqBZ,CAAK,EAC5B,OAAOa,GAA2Bb,EAAOC,CAAS,EAGtD,MAAMa,GAAiCd,CAAK,CAC9C,CCoDM,SAAUe,GAAQC,EAA2BC,EAAyB,CAC1E,OAAOA,EAAYC,GAAUF,EAAOC,CAAS,EAAIE,EAAUH,CAAK,CAClE,CCxBM,SAAUI,GAAE,SAAIC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACpB,IAAMC,EAAYC,GAAaH,CAAI,EACnC,OAAOI,GAAKJ,EAAaE,CAAS,CACpC,CCsCM,SAAUG,GAAWC,EAA0BC,EAAyB,CAC5E,IAAMC,EAAeC,EAAWH,CAAmB,EAAIA,EAAsB,UAAA,CAAM,OAAAA,CAAA,EAC7EI,EAAO,SAACC,EAA6B,CAAK,OAAAA,EAAW,MAAMH,EAAY,CAAE,CAA/B,EAChD,OAAO,IAAII,EAAWL,EAAY,SAACI,EAAU,CAAK,OAAAJ,EAAU,SAASG,EAAa,EAAGC,CAAU,CAA7C,EAAiDD,CAAI,CACzG,CCpGO,IAAMG,GAA6BC,GAAiB,SAACC,EAAM,CAAK,OAAA,UAAuB,CAC5FA,EAAO,IAAI,EACX,KAAK,KAAO,aACZ,KAAK,QAAU,yBACjB,CAJuE,CAItE,ECrBK,SAAUC,GAAYC,EAAU,CACpC,OAAOA,aAAiB,MAAQ,CAAC,MAAMA,CAAY,CACrD,CCsCM,SAAUC,EAAUC,EAAyCC,EAAa,CAC9E,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAEhC,IAAIC,EAAQ,EAGZF,EAAO,UACLG,EAAyBF,EAAY,SAACG,EAAQ,CAG5CH,EAAW,KAAKJ,EAAQ,KAAKC,EAASM,EAAOF,GAAO,CAAC,CACvD,CAAC,CAAC,CAEN,CAAC,CACH,CC1DQ,IAAAG,GAAY,MAAK,QAEzB,SAASC,GAAkBC,EAA6BC,EAAW,CAC/D,OAAOH,GAAQG,CAAI,EAAID,EAAE,MAAA,OAAAE,EAAA,CAAA,EAAAC,EAAIF,CAAI,CAAA,CAAA,EAAID,EAAGC,CAAI,CAChD,CAMM,SAAUG,GAAuBJ,EAA2B,CAC9D,OAAOK,EAAI,SAAAJ,EAAI,CAAI,OAAAF,GAAYC,EAAIC,CAAI,CAApB,CAAqB,CAC5C,CCfQ,IAAAK,GAAY,MAAK,QACjBC,GAA0D,OAAM,eAArCC,GAA+B,OAAM,UAAlBC,GAAY,OAAM,KAQlE,SAAUC,GAAqDC,EAAuB,CAC1F,GAAIA,EAAK,SAAW,EAAG,CACrB,IAAMC,EAAQD,EAAK,CAAC,EACpB,GAAIL,GAAQM,CAAK,EACf,MAAO,CAAE,KAAMA,EAAO,KAAM,IAAI,EAElC,GAAIC,GAAOD,CAAK,EAAG,CACjB,IAAME,EAAOL,GAAQG,CAAK,EAC1B,MAAO,CACL,KAAME,EAAK,IAAI,SAACC,EAAG,CAAK,OAAAH,EAAMG,CAAG,CAAT,CAAU,EAClC,KAAID,IAKV,MAAO,CAAE,KAAMH,EAAa,KAAM,IAAI,CACxC,CAEA,SAASE,GAAOG,EAAQ,CACtB,OAAOA,GAAO,OAAOA,GAAQ,UAAYT,GAAeS,CAAG,IAAMR,EACnE,CC7BM,SAAUS,GAAaC,EAAgBC,EAAa,CACxD,OAAOD,EAAK,OAAO,SAACE,EAAQC,EAAKC,EAAC,CAAK,OAAEF,EAAOC,CAAG,EAAIF,EAAOG,CAAC,EAAIF,CAA5B,EAAqC,CAAA,CAAS,CACvF,CCsMM,SAAUG,GAAa,SAAoCC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EAC/D,IAAMC,EAAYC,GAAaH,CAAI,EAC7BI,EAAiBC,GAAkBL,CAAI,EAEvCM,EAA8BC,GAAqBP,CAAI,EAA/CQ,EAAWF,EAAA,KAAEG,EAAIH,EAAA,KAE/B,GAAIE,EAAY,SAAW,EAIzB,OAAOE,GAAK,CAAA,EAAIR,CAAgB,EAGlC,IAAMS,EAAS,IAAIC,EACjBC,GACEL,EACAN,EACAO,EAEI,SAACK,EAAM,CAAK,OAAAC,GAAaN,EAAMK,CAAM,CAAzB,EAEZE,EAAQ,CACb,EAGH,OAAOZ,EAAkBO,EAAO,KAAKM,GAAiBb,CAAc,CAAC,EAAsBO,CAC7F,CAEM,SAAUE,GACdL,EACAN,EACAgB,EAAiD,CAAjD,OAAAA,IAAA,SAAAA,EAAAF,IAEO,SAACG,EAA2B,CAGjCC,GACElB,EACA,UAAA,CAaE,QAZQmB,EAAWb,EAAW,OAExBM,EAAS,IAAI,MAAMO,CAAM,EAG3BC,EAASD,EAITE,EAAuBF,aAGlBG,EAAC,CACRJ,GACElB,EACA,UAAA,CACE,IAAMuB,EAASf,GAAKF,EAAYgB,CAAC,EAAGtB,CAAgB,EAChDwB,EAAgB,GACpBD,EAAO,UACLE,EACER,EACA,SAACS,EAAK,CAEJd,EAAOU,CAAC,EAAII,EACPF,IAEHA,EAAgB,GAChBH,KAEGA,GAGHJ,EAAW,KAAKD,EAAeJ,EAAO,MAAK,CAAE,CAAC,CAElD,EACA,UAAA,CACO,EAAEQ,GAGLH,EAAW,SAAQ,CAEvB,CAAC,CACF,CAEL,EACAA,CAAU,GAjCLK,EAAI,EAAGA,EAAIH,EAAQG,MAAnBA,CAAC,CAoCZ,EACAL,CAAU,CAEd,CACF,CAMA,SAASC,GAAclB,EAAsC2B,EAAqBC,EAA0B,CACtG5B,EACF6B,GAAgBD,EAAc5B,EAAW2B,CAAO,EAEhDA,EAAO,CAEX,CC3RM,SAAUG,GACdC,EACAC,EACAC,EACAC,EACAC,EACAC,EACAC,EACAC,EAAgC,CAGhC,IAAMC,EAAc,CAAA,EAEhBC,EAAS,EAETC,EAAQ,EAERC,EAAa,GAKXC,EAAgB,UAAA,CAIhBD,GAAc,CAACH,EAAO,QAAU,CAACC,GACnCR,EAAW,SAAQ,CAEvB,EAGMY,EAAY,SAACC,EAAQ,CAAK,OAACL,EAASN,EAAaY,EAAWD,CAAK,EAAIN,EAAO,KAAKM,CAAK,CAA5D,EAE1BC,EAAa,SAACD,EAAQ,CAI1BT,GAAUJ,EAAW,KAAKa,CAAY,EAItCL,IAKA,IAAIO,EAAgB,GAGpBC,EAAUf,EAAQY,EAAOJ,GAAO,CAAC,EAAE,UACjCQ,EACEjB,EACA,SAACkB,GAAU,CAGTf,GAAY,MAAZA,EAAee,EAAU,EAErBd,EAGFQ,EAAUM,EAAiB,EAG3BlB,EAAW,KAAKkB,EAAU,CAE9B,EACA,UAAA,CAGEH,EAAgB,EAClB,EAEA,OACA,UAAA,CAIE,GAAIA,EAKF,GAAI,CAIFP,IAKA,sBACE,IAAMW,EAAgBZ,EAAO,MAAK,EAI9BF,EACFe,GAAgBpB,EAAYK,EAAmB,UAAA,CAAM,OAAAS,EAAWK,CAAa,CAAxB,CAAyB,EAE9EL,EAAWK,CAAa,GARrBZ,EAAO,QAAUC,EAASN,QAYjCS,EAAa,QACNU,EAAK,CACZrB,EAAW,MAAMqB,CAAG,EAG1B,CAAC,CACF,CAEL,EAGA,OAAAtB,EAAO,UACLkB,EAAyBjB,EAAYY,EAAW,UAAA,CAE9CF,EAAa,GACbC,EAAa,CACf,CAAC,CAAC,EAKG,UAAA,CACLL,GAAmB,MAAnBA,EAAmB,CACrB,CACF,CClEM,SAAUgB,GACdC,EACAC,EACAC,EAA6B,CAE7B,OAFAA,IAAA,SAAAA,EAAA,KAEIC,EAAWF,CAAc,EAEpBF,GAAS,SAACK,EAAGC,EAAC,CAAK,OAAAC,EAAI,SAACC,EAAQC,EAAU,CAAK,OAAAP,EAAeG,EAAGG,EAAGF,EAAGG,CAAE,CAA1B,CAA2B,EAAEC,EAAUT,EAAQI,EAAGC,CAAC,CAAC,CAAC,CAAjF,EAAoFH,CAAU,GAC/G,OAAOD,GAAmB,WACnCC,EAAaD,GAGRS,EAAQ,SAACC,EAAQC,EAAU,CAAK,OAAAC,GAAeF,EAAQC,EAAYZ,EAASE,CAAU,CAAtD,CAAuD,EAChG,CChCM,SAAUY,GAAyCC,EAA6B,CAA7B,OAAAA,IAAA,SAAAA,EAAA,KAChDC,GAASC,GAAUF,CAAU,CACtC,CCNM,SAAUG,IAAS,CACvB,OAAOC,GAAS,CAAC,CACnB,CCmDM,SAAUC,IAAM,SAACC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACrB,OAAOC,GAAS,EAAGC,GAAKH,EAAMI,GAAaJ,CAAI,CAAC,CAAC,CACnD,CC9DM,SAAUK,EAAsCC,EAA0B,CAC9E,OAAO,IAAIC,EAA+B,SAACC,EAAU,CACnDC,EAAUH,EAAiB,CAAE,EAAE,UAAUE,CAAU,CACrD,CAAC,CACH,CChDA,IAAME,GAA0B,CAAC,cAAe,gBAAgB,EAC1DC,GAAqB,CAAC,mBAAoB,qBAAqB,EAC/DC,GAAgB,CAAC,KAAM,KAAK,EAkO5B,SAAUC,EACdC,EACAC,EACAC,EACAC,EAAsC,CAMtC,GAJIC,EAAWF,CAAO,IACpBC,EAAiBD,EACjBA,EAAU,QAERC,EACF,OAAOJ,EAAaC,EAAQC,EAAWC,CAA+B,EAAE,KAAKG,GAAiBF,CAAc,CAAC,EAUzG,IAAAG,EAAAC,EAEJC,GAAcR,CAAM,EAChBH,GAAmB,IAAI,SAACY,EAAU,CAAK,OAAA,SAACC,EAAY,CAAK,OAAAV,EAAOS,CAAU,EAAER,EAAWS,EAASR,CAA+B,CAAtE,CAAlB,CAAyF,EAElIS,GAAwBX,CAAM,EAC5BJ,GAAwB,IAAIgB,GAAwBZ,EAAQC,CAAS,CAAC,EACtEY,GAA0Bb,CAAM,EAChCF,GAAc,IAAIc,GAAwBZ,EAAQC,CAAS,CAAC,EAC5D,CAAA,EAAE,CAAA,EATDa,EAAGR,EAAA,CAAA,EAAES,EAAMT,EAAA,CAAA,EAgBlB,GAAI,CAACQ,GACCE,GAAYhB,CAAM,EACpB,OAAOiB,GAAS,SAACC,EAAc,CAAK,OAAAnB,EAAUmB,EAAWjB,EAAWC,CAA+B,CAA/D,CAAgE,EAClGiB,EAAUnB,CAAM,CAAC,EAOvB,GAAI,CAACc,EACH,MAAM,IAAI,UAAU,sBAAsB,EAG5C,OAAO,IAAIM,EAAc,SAACC,EAAU,CAIlC,IAAMX,EAAU,UAAA,SAACY,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EAAmB,OAAAF,EAAW,KAAK,EAAIC,EAAK,OAASA,EAAOA,EAAK,CAAC,CAAC,CAAhD,EAEpC,OAAAR,EAAIJ,CAAO,EAEJ,UAAA,CAAM,OAAAK,EAAQL,CAAO,CAAf,CACf,CAAC,CACH,CASA,SAASE,GAAwBZ,EAAaC,EAAiB,CAC7D,OAAO,SAACQ,EAAkB,CAAK,OAAA,SAACC,EAAY,CAAK,OAAAV,EAAOS,CAAU,EAAER,EAAWS,CAAO,CAArC,CAAlB,CACjC,CAOA,SAASC,GAAwBX,EAAW,CAC1C,OAAOI,EAAWJ,EAAO,WAAW,GAAKI,EAAWJ,EAAO,cAAc,CAC3E,CAOA,SAASa,GAA0Bb,EAAW,CAC5C,OAAOI,EAAWJ,EAAO,EAAE,GAAKI,EAAWJ,EAAO,GAAG,CACvD,CAOA,SAASQ,GAAcR,EAAW,CAChC,OAAOI,EAAWJ,EAAO,gBAAgB,GAAKI,EAAWJ,EAAO,mBAAmB,CACrF,CCnMM,SAAUwB,GACdC,EACAC,EACAC,EAAsC,CAEtC,OAAIA,EACKH,GAAoBC,EAAYC,CAAa,EAAE,KAAKE,GAAiBD,CAAc,CAAC,EAGtF,IAAIE,EAAoB,SAACC,EAAU,CACxC,IAAMC,EAAU,UAAA,SAACC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EAAc,OAAAH,EAAW,KAAKE,EAAE,SAAW,EAAIA,EAAE,CAAC,EAAIA,CAAC,CAAzC,EACzBE,EAAWT,EAAWM,CAAO,EACnC,OAAOI,EAAWT,CAAa,EAAI,UAAA,CAAM,OAAAA,EAAcK,EAASG,CAAQ,CAA/B,EAAmC,MAC9E,CAAC,CACH,CCtBM,SAAUE,GACdC,EACAC,EACAC,EAAyC,CAFzCF,IAAA,SAAAA,EAAA,GAEAE,IAAA,SAAAA,EAAAC,IAIA,IAAIC,EAAmB,GAEvB,OAAIH,GAAuB,OAIrBI,GAAYJ,CAAmB,EACjCC,EAAYD,EAIZG,EAAmBH,GAIhB,IAAIK,EAAW,SAACC,EAAU,CAI/B,IAAIC,EAAMC,GAAYT,CAAO,EAAI,CAACA,EAAUE,EAAW,IAAG,EAAKF,EAE3DQ,EAAM,IAERA,EAAM,GAIR,IAAIE,EAAI,EAGR,OAAOR,EAAU,SAAS,UAAA,CACnBK,EAAW,SAEdA,EAAW,KAAKG,GAAG,EAEf,GAAKN,EAGP,KAAK,SAAS,OAAWA,CAAgB,EAGzCG,EAAW,SAAQ,EAGzB,EAAGC,CAAG,CACR,CAAC,CACH,CChGM,SAAUG,GAAK,SAACC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACpB,IAAMC,EAAYC,GAAaH,CAAI,EAC7BI,EAAaC,GAAUL,EAAM,GAAQ,EACrCM,EAAUN,EAChB,OAAQM,EAAQ,OAGZA,EAAQ,SAAW,EAEnBC,EAAUD,EAAQ,CAAC,CAAC,EAEpBE,GAASJ,CAAU,EAAEK,GAAKH,EAASJ,CAAS,CAAC,EAL7CQ,CAMN,CCjEO,IAAMC,GAAQ,IAAIC,EAAkBC,EAAI,ECpCvC,IAAAC,GAAY,MAAK,QAMnB,SAAUC,GAAkBC,EAAiB,CACjD,OAAOA,EAAK,SAAW,GAAKF,GAAQE,EAAK,CAAC,CAAC,EAAIA,EAAK,CAAC,EAAKA,CAC5D,CCoDM,SAAUC,EAAUC,EAAiDC,EAAa,CACtF,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAEhC,IAAIC,EAAQ,EAIZF,EAAO,UAILG,EAAyBF,EAAY,SAACG,EAAK,CAAK,OAAAP,EAAU,KAAKC,EAASM,EAAOF,GAAO,GAAKD,EAAW,KAAKG,CAAK,CAAhE,CAAiE,CAAC,CAEtH,CAAC,CACH,CCxBM,SAAUC,IAAG,SAACC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EAClB,IAAMC,EAAiBC,GAAkBH,CAAI,EAEvCI,EAAUC,GAAeL,CAAI,EAEnC,OAAOI,EAAQ,OACX,IAAIE,EAAsB,SAACC,EAAU,CAGnC,IAAIC,EAAuBJ,EAAQ,IAAI,UAAA,CAAM,MAAA,CAAA,CAAA,CAAE,EAK3CK,EAAYL,EAAQ,IAAI,UAAA,CAAM,MAAA,EAAA,CAAK,EAGvCG,EAAW,IAAI,UAAA,CACbC,EAAUC,EAAY,IACxB,CAAC,EAKD,mBAASC,EAAW,CAClBC,EAAUP,EAAQM,CAAW,CAAC,EAAE,UAC9BE,EACEL,EACA,SAACM,EAAK,CAKJ,GAJAL,EAAQE,CAAW,EAAE,KAAKG,CAAK,EAI3BL,EAAQ,MAAM,SAACM,EAAM,CAAK,OAAAA,EAAO,MAAP,CAAa,EAAG,CAC5C,IAAMC,EAAcP,EAAQ,IAAI,SAACM,EAAM,CAAK,OAAAA,EAAO,MAAK,CAAZ,CAAe,EAE3DP,EAAW,KAAKL,EAAiBA,EAAc,MAAA,OAAAc,EAAA,CAAA,EAAAC,EAAIF,CAAM,CAAA,CAAA,EAAIA,CAAM,EAI/DP,EAAQ,KAAK,SAACM,EAAQI,EAAC,CAAK,MAAA,CAACJ,EAAO,QAAUL,EAAUS,CAAC,CAA7B,CAA8B,GAC5DX,EAAW,SAAQ,EAGzB,EACA,UAAA,CAGEE,EAAUC,CAAW,EAAI,GAIzB,CAACF,EAAQE,CAAW,EAAE,QAAUH,EAAW,SAAQ,CACrD,CAAC,CACF,GA9BIG,EAAc,EAAG,CAACH,EAAW,QAAUG,EAAcN,EAAQ,OAAQM,MAArEA,CAAW,EAmCpB,OAAO,UAAA,CACLF,EAAUC,EAAY,IACxB,CACF,CAAC,EACDU,CACN,CC9DM,SAAUC,GAASC,EAAoD,CAC3E,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAW,GACXC,EAAsB,KACtBC,EAA6C,KAC7CC,EAAa,GAEXC,EAAc,UAAA,CAGlB,GAFAF,GAAkB,MAAlBA,EAAoB,YAAW,EAC/BA,EAAqB,KACjBF,EAAU,CACZA,EAAW,GACX,IAAMK,EAAQJ,EACdA,EAAY,KACZF,EAAW,KAAKM,CAAK,EAEvBF,GAAcJ,EAAW,SAAQ,CACnC,EAEMO,EAAkB,UAAA,CACtBJ,EAAqB,KACrBC,GAAcJ,EAAW,SAAQ,CACnC,EAEAD,EAAO,UACLS,EACER,EACA,SAACM,EAAK,CACJL,EAAW,GACXC,EAAYI,EACPH,GACHM,EAAUZ,EAAiBS,CAAK,CAAC,EAAE,UAChCH,EAAqBK,EAAyBR,EAAYK,EAAaE,CAAe,CAAE,CAG/F,EACA,UAAA,CACEH,EAAa,IACZ,CAACH,GAAY,CAACE,GAAsBA,EAAmB,SAAWH,EAAW,SAAQ,CACxF,CAAC,CACF,CAEL,CAAC,CACH,CC3CM,SAAUU,GAAaC,EAAkBC,EAAyC,CAAzC,OAAAA,IAAA,SAAAA,EAAAC,IACtCC,GAAM,UAAA,CAAM,OAAAC,GAAMJ,EAAUC,CAAS,CAAzB,CAA0B,CAC/C,CCEM,SAAUI,GAAeC,EAAoBC,EAAsC,CAAtC,OAAAA,IAAA,SAAAA,EAAA,MAGjDA,EAAmBA,GAAgB,KAAhBA,EAAoBD,EAEhCE,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAiB,CAAA,EACjBC,EAAQ,EAEZH,EAAO,UACLI,EACEH,EACA,SAACI,EAAK,aACAC,EAAuB,KAKvBH,IAAUL,IAAsB,GAClCI,EAAQ,KAAK,CAAA,CAAE,MAIjB,QAAqBK,EAAAC,GAAAN,CAAO,EAAAO,EAAAF,EAAA,KAAA,EAAA,CAAAE,EAAA,KAAAA,EAAAF,EAAA,KAAA,EAAE,CAAzB,IAAMG,EAAMD,EAAA,MACfC,EAAO,KAAKL,CAAK,EAMbR,GAAca,EAAO,SACvBJ,EAASA,GAAM,KAANA,EAAU,CAAA,EACnBA,EAAO,KAAKI,CAAM,uGAItB,GAAIJ,MAIF,QAAqBK,EAAAH,GAAAF,CAAM,EAAAM,EAAAD,EAAA,KAAA,EAAA,CAAAC,EAAA,KAAAA,EAAAD,EAAA,KAAA,EAAE,CAAxB,IAAMD,EAAME,EAAA,MACfC,GAAUX,EAASQ,CAAM,EACzBT,EAAW,KAAKS,CAAM,sGAG5B,EACA,UAAA,aAGE,QAAqBI,EAAAN,GAAAN,CAAO,EAAAa,EAAAD,EAAA,KAAA,EAAA,CAAAC,EAAA,KAAAA,EAAAD,EAAA,KAAA,EAAE,CAAzB,IAAMJ,EAAMK,EAAA,MACfd,EAAW,KAAKS,CAAM,oGAExBT,EAAW,SAAQ,CACrB,EAEA,OACA,UAAA,CAEEC,EAAU,IACZ,CAAC,CACF,CAEL,CAAC,CACH,CCbM,SAAUc,GACdC,EAAgD,CAEhD,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAgC,KAChCC,EAAY,GACZC,EAEJF,EAAWF,EAAO,UAChBK,EAAyBJ,EAAY,OAAW,OAAW,SAACK,EAAG,CAC7DF,EAAgBG,EAAUT,EAASQ,EAAKT,GAAWC,CAAQ,EAAEE,CAAM,CAAC,CAAC,EACjEE,GACFA,EAAS,YAAW,EACpBA,EAAW,KACXE,EAAc,UAAUH,CAAU,GAIlCE,EAAY,EAEhB,CAAC,CAAC,EAGAA,IAMFD,EAAS,YAAW,EACpBA,EAAW,KACXE,EAAe,UAAUH,CAAU,EAEvC,CAAC,CACH,CC/HM,SAAUO,GACdC,EACAC,EACAC,EACAC,EACAC,EAAqC,CAErC,OAAO,SAACC,EAAuBC,EAA2B,CAIxD,IAAIC,EAAWL,EAIXM,EAAaP,EAEbQ,EAAQ,EAGZJ,EAAO,UACLK,EACEJ,EACA,SAACK,EAAK,CAEJ,IAAMC,EAAIH,IAEVD,EAAQD,EAEJP,EAAYQ,EAAOG,EAAOC,CAAC,GAIzBL,EAAW,GAAOI,GAGxBR,GAAcG,EAAW,KAAKE,CAAK,CACrC,EAGAJ,GACG,UAAA,CACCG,GAAYD,EAAW,KAAKE,CAAK,EACjCF,EAAW,SAAQ,CACrB,CAAE,CACL,CAEL,CACF,CCnCM,SAAUO,IAAa,SAAOC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EAClC,IAAMC,EAAiBC,GAAkBH,CAAI,EAC7C,OAAOE,EACHE,GAAKL,GAAa,MAAA,OAAAM,EAAA,CAAA,EAAAC,EAAKN,CAAoC,CAAA,CAAA,EAAGO,GAAiBL,CAAc,CAAC,EAC9FM,EAAQ,SAACC,EAAQC,EAAU,CACzBC,GAAiBN,EAAA,CAAEI,CAAM,EAAAH,EAAKM,GAAeZ,CAAI,CAAC,CAAA,CAAA,EAAGU,CAAU,CACjE,CAAC,CACP,CCUM,SAAUG,IAAiB,SAC/BC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EAEA,OAAOC,GAAa,MAAA,OAAAC,EAAA,CAAA,EAAAC,EAAIJ,CAAY,CAAA,CAAA,CACtC,CCkBM,SAAUK,GAAYC,EAAoD,CAC9E,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAW,GACXC,EAAsB,KAEtBC,EAA6C,KAE3CC,EAAO,UAAA,CAMX,GAFAD,GAAkB,MAAlBA,EAAoB,YAAW,EAC/BA,EAAqB,KACjBF,EAAU,CAEZA,EAAW,GACX,IAAMI,EAAQH,EACdA,EAAY,KACZF,EAAW,KAAKK,CAAK,EAEzB,EAEAN,EAAO,UACLO,EACEN,EACA,SAACK,EAAQ,CAIPF,GAAkB,MAAlBA,EAAoB,YAAW,EAC/BF,EAAW,GACXC,EAAYG,EAGZF,EAAqBG,EAAyBN,EAAYI,EAAMG,EAAI,EAEpEC,EAAUX,EAAiBQ,CAAK,CAAC,EAAE,UAAUF,CAAkB,CACjE,EACA,UAAA,CAGEC,EAAI,EACJJ,EAAW,SAAQ,CACrB,EAEA,OACA,UAAA,CAEEE,EAAYC,EAAqB,IACnC,CAAC,CACF,CAEL,CAAC,CACH,CCvDM,SAAUM,GAAgBC,EAAiBC,EAAyC,CAAzC,OAAAA,IAAA,SAAAA,EAAAC,IACxCC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAkC,KAClCC,EAAsB,KACtBC,EAA0B,KAExBC,EAAO,UAAA,CACX,GAAIH,EAAY,CAEdA,EAAW,YAAW,EACtBA,EAAa,KACb,IAAMI,EAAQH,EACdA,EAAY,KACZF,EAAW,KAAKK,CAAK,EAEzB,EACA,SAASC,GAAY,CAInB,IAAMC,EAAaJ,EAAYR,EACzBa,EAAMZ,EAAU,IAAG,EACzB,GAAIY,EAAMD,EAAY,CAEpBN,EAAa,KAAK,SAAS,OAAWM,EAAaC,CAAG,EACtDR,EAAW,IAAIC,CAAU,EACzB,OAGFG,EAAI,CACN,CAEAL,EAAO,UACLU,EACET,EACA,SAACK,EAAQ,CACPH,EAAYG,EACZF,EAAWP,EAAU,IAAG,EAGnBK,IACHA,EAAaL,EAAU,SAASU,EAAcX,CAAO,EACrDK,EAAW,IAAIC,CAAU,EAE7B,EACA,UAAA,CAGEG,EAAI,EACJJ,EAAW,SAAQ,CACrB,EAEA,OACA,UAAA,CAEEE,EAAYD,EAAa,IAC3B,CAAC,CACF,CAEL,CAAC,CACH,CCpFM,SAAUS,GAAqBC,EAAe,CAClD,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAW,GACfF,EAAO,UACLG,EACEF,EACA,SAACG,EAAK,CACJF,EAAW,GACXD,EAAW,KAAKG,CAAK,CACvB,EACA,UAAA,CACOF,GACHD,EAAW,KAAKH,CAAa,EAE/BG,EAAW,SAAQ,CACrB,CAAC,CACF,CAEL,CAAC,CACH,CCXM,SAAUI,GAAQC,EAAa,CACnC,OAAOA,GAAS,EAEZ,UAAA,CAAM,OAAAC,CAAA,EACNC,EAAQ,SAACC,EAAQC,EAAU,CACzB,IAAIC,EAAO,EACXF,EAAO,UACLG,EAAyBF,EAAY,SAACG,EAAK,CAIrC,EAAEF,GAAQL,IACZI,EAAW,KAAKG,CAAK,EAIjBP,GAASK,GACXD,EAAW,SAAQ,EAGzB,CAAC,CAAC,CAEN,CAAC,CACP,CC9BM,SAAUI,GAAc,CAC5B,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChCD,EAAO,UAAUE,EAAyBD,EAAYE,EAAI,CAAC,CAC7D,CAAC,CACH,CCCM,SAAUC,GAASC,EAAQ,CAC/B,OAAOC,EAAI,UAAA,CAAM,OAAAD,CAAA,CAAK,CACxB,CC4CM,SAAUE,GACdC,EACAC,EAAmC,CAEnC,OAAIA,EAEK,SAACC,EAAqB,CAC3B,OAAAC,GAAOF,EAAkB,KAAKG,GAAK,CAAC,EAAGC,EAAc,CAAE,EAAGH,EAAO,KAAKH,GAAUC,CAAqB,CAAC,CAAC,CAAvG,EAGGM,GAAS,SAACC,EAAOC,EAAK,CAAK,OAAAC,EAAUT,EAAsBO,EAAOC,CAAK,CAAC,EAAE,KAAKJ,GAAK,CAAC,EAAGM,GAAMH,CAAK,CAAC,CAAzE,CAA0E,CAC9G,CCzCM,SAAUI,GAASC,EAAoBC,EAAyC,CAAzCA,IAAA,SAAAA,EAAAC,IAC3C,IAAMC,EAAWC,GAAMJ,EAAKC,CAAS,EACrC,OAAOI,GAAU,UAAA,CAAM,OAAAF,CAAA,CAAQ,CACjC,CC0EM,SAAUG,EACdC,EACAC,EAA0D,CAA1D,OAAAA,IAAA,SAAAA,EAA+BC,IAK/BF,EAAaA,GAAU,KAAVA,EAAcG,GAEpBC,EAAQ,SAACC,EAAQC,EAAU,CAGhC,IAAIC,EAEAC,EAAQ,GAEZH,EAAO,UACLI,EAAyBH,EAAY,SAACI,EAAK,CAEzC,IAAMC,EAAaV,EAAYS,CAAK,GAKhCF,GAAS,CAACR,EAAYO,EAAaI,CAAU,KAM/CH,EAAQ,GACRD,EAAcI,EAGdL,EAAW,KAAKI,CAAK,EAEzB,CAAC,CAAC,CAEN,CAAC,CACH,CAEA,SAASP,GAAeS,EAAQC,EAAM,CACpC,OAAOD,IAAMC,CACf,CCjHM,SAAUC,GAA8CC,EAAQC,EAAuC,CAC3G,OAAOC,EAAqB,SAACC,EAAMC,EAAI,CAAK,OAAAH,EAAUA,EAAQE,EAAEH,CAAG,EAAGI,EAAEJ,CAAG,CAAC,EAAIG,EAAEH,CAAG,IAAMI,EAAEJ,CAAG,CAApD,CAAqD,CACnG,CC7BM,SAAUK,GAAgBC,EAA6C,CAA7C,OAAAA,IAAA,SAAAA,EAAAC,IACvBC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAW,GACfF,EAAO,UACLG,EACEF,EACA,SAACG,EAAK,CACJF,EAAW,GACXD,EAAW,KAAKG,CAAK,CACvB,EACA,UAAA,CAAM,OAACF,EAAWD,EAAW,SAAQ,EAAKA,EAAW,MAAMJ,EAAY,CAAE,CAAnE,CAAqE,CAC5E,CAEL,CAAC,CACH,CAEA,SAASC,IAAmB,CAC1B,OAAO,IAAIO,EACb,CCMM,SAAUC,IAAO,SAAIC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACzB,OAAO,SAACC,EAAqB,CAAK,OAAAC,GAAOD,EAAQE,EAAE,MAAA,OAAAC,EAAA,CAAA,EAAAC,EAAIN,CAAM,CAAA,CAAA,CAAA,CAA3B,CACpC,CCHM,SAAUO,EAAYC,EAAoB,CAC9C,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAGhC,GAAI,CACFD,EAAO,UAAUC,CAAU,UAE3BA,EAAW,IAAIH,CAAQ,EAE3B,CAAC,CACH,CCMM,SAAUI,GACdC,EACAC,EAAgB,CAEhB,IAAMC,EAAkB,UAAU,QAAU,EAC5C,OAAO,SAACC,EAAqB,CAC3B,OAAAA,EAAO,KACLH,EAAYI,EAAO,SAACC,EAAG,EAAC,CAAK,OAAAL,EAAUK,EAAG,EAAGF,CAAM,CAAtB,CAAuB,EAAIG,GACxDC,GAAK,CAAC,EACNL,EAAkBM,GAAeP,CAAa,EAAIQ,GAAa,UAAA,CAAM,OAAA,IAAIC,EAAJ,CAAgB,CAAC,CAHxF,CAKJ,CC/CM,SAAUC,GAAYC,EAAa,CACvC,OAAOA,GAAS,EACZ,UAAA,CAAM,OAAAC,CAAA,EACNC,EAAQ,SAACC,EAAQC,EAAU,CAKzB,IAAIC,EAAc,CAAA,EAClBF,EAAO,UACLG,EACEF,EACA,SAACG,EAAK,CAEJF,EAAO,KAAKE,CAAK,EAGjBP,EAAQK,EAAO,QAAUA,EAAO,MAAK,CACvC,EACA,UAAA,aAGE,QAAoBG,EAAAC,GAAAJ,CAAM,EAAAK,EAAAF,EAAA,KAAA,EAAA,CAAAE,EAAA,KAAAA,EAAAF,EAAA,KAAA,EAAE,CAAvB,IAAMD,EAAKG,EAAA,MACdN,EAAW,KAAKG,CAAK,oGAEvBH,EAAW,SAAQ,CACrB,EAEA,OACA,UAAA,CAEEC,EAAS,IACX,CAAC,CACF,CAEL,CAAC,CACP,CC1DM,SAAUM,IAAK,SAAIC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACvB,IAAMC,EAAYC,GAAaH,CAAI,EAC7BI,EAAaC,GAAUL,EAAM,GAAQ,EAC3C,OAAAA,EAAOM,GAAeN,CAAI,EAEnBO,EAAQ,SAACC,EAAQC,EAAU,CAChCC,GAASN,CAAU,EAAEO,GAAIC,EAAA,CAAEJ,CAAM,EAAAK,EAAMb,CAA6B,CAAA,EAAGE,CAAS,CAAC,EAAE,UAAUO,CAAU,CACzG,CAAC,CACH,CCcM,SAAUK,IAAS,SACvBC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EAEA,OAAOC,GAAK,MAAA,OAAAC,EAAA,CAAA,EAAAC,EAAIJ,CAAY,CAAA,CAAA,CAC9B,CCmEM,SAAUK,GAAUC,EAAqC,OACzDC,EAAQ,IACRC,EAEJ,OAAIF,GAAiB,OACf,OAAOA,GAAkB,UACxBG,EAA4BH,EAAa,MAAzCC,EAAKE,IAAA,OAAG,IAAQA,EAAED,EAAUF,EAAa,OAE5CC,EAAQD,GAILC,GAAS,EACZ,UAAA,CAAM,OAAAG,CAAA,EACNC,EAAQ,SAACC,EAAQC,EAAU,CACzB,IAAIC,EAAQ,EACRC,EAEEC,EAAc,UAAA,CAGlB,GAFAD,GAAS,MAATA,EAAW,YAAW,EACtBA,EAAY,KACRP,GAAS,KAAM,CACjB,IAAMS,EAAW,OAAOT,GAAU,SAAWU,GAAMV,CAAK,EAAIW,EAAUX,EAAMM,CAAK,CAAC,EAC5EM,EAAqBC,EAAyBR,EAAY,UAAA,CAC9DO,EAAmB,YAAW,EAC9BE,EAAiB,CACnB,CAAC,EACDL,EAAS,UAAUG,CAAkB,OAErCE,EAAiB,CAErB,EAEMA,EAAoB,UAAA,CACxB,IAAIC,EAAY,GAChBR,EAAYH,EAAO,UACjBS,EAAyBR,EAAY,OAAW,UAAA,CAC1C,EAAEC,EAAQP,EACRQ,EACFC,EAAW,EAEXO,EAAY,GAGdV,EAAW,SAAQ,CAEvB,CAAC,CAAC,EAGAU,GACFP,EAAW,CAEf,EAEAM,EAAiB,CACnB,CAAC,CACP,CCpFM,SAAUE,GAAcC,EAA6DC,EAAQ,CAMjG,OAAOC,EAAQC,GAAcH,EAAaC,EAAW,UAAU,QAAU,EAAG,EAAI,CAAC,CACnF,CC+CM,SAAUG,GAASC,EAA4B,CAA5BA,IAAA,SAAAA,EAAA,CAAA,GACf,IAAAC,EAAgHD,EAAO,UAAvHE,EAASD,IAAA,OAAG,UAAA,CAAM,OAAA,IAAIE,CAAJ,EAAgBF,EAAEG,EAA4EJ,EAAO,aAAnFK,EAAYD,IAAA,OAAG,GAAIA,EAAEE,EAAuDN,EAAO,gBAA9DO,EAAeD,IAAA,OAAG,GAAIA,EAAEE,EAA+BR,EAAO,oBAAtCS,EAAmBD,IAAA,OAAG,GAAIA,EAUnH,OAAO,SAACE,EAAa,CACnB,IAAIC,EACAC,EACAC,EACAC,EAAW,EACXC,EAAe,GACfC,EAAa,GAEXC,EAAc,UAAA,CAClBL,GAAe,MAAfA,EAAiB,YAAW,EAC5BA,EAAkB,MACpB,EAGMM,GAAQ,UAAA,CACZD,EAAW,EACXN,EAAaE,EAAU,OACvBE,EAAeC,EAAa,EAC9B,EACMG,EAAsB,UAAA,CAG1B,IAAMC,EAAOT,EACbO,GAAK,EACLE,GAAI,MAAJA,EAAM,YAAW,CACnB,EAEA,OAAOC,EAAc,SAACC,EAAQC,GAAU,CACtCT,IACI,CAACE,GAAc,CAACD,GAClBE,EAAW,EAOb,IAAMO,GAAQX,EAAUA,GAAO,KAAPA,EAAWX,EAAS,EAO5CqB,GAAW,IAAI,UAAA,CACbT,IAKIA,IAAa,GAAK,CAACE,GAAc,CAACD,IACpCH,EAAkBa,GAAYN,EAAqBV,CAAmB,EAE1E,CAAC,EAIDe,GAAK,UAAUD,EAAU,EAGvB,CAACZ,GAIDG,EAAW,IAOXH,EAAa,IAAIe,GAAe,CAC9B,KAAM,SAACC,GAAK,CAAK,OAAAH,GAAK,KAAKG,EAAK,CAAf,EACjB,MAAO,SAACC,GAAG,CACTZ,EAAa,GACbC,EAAW,EACXL,EAAkBa,GAAYP,GAAOb,EAAcuB,EAAG,EACtDJ,GAAK,MAAMI,EAAG,CAChB,EACA,SAAU,UAAA,CACRb,EAAe,GACfE,EAAW,EACXL,EAAkBa,GAAYP,GAAOX,CAAe,EACpDiB,GAAK,SAAQ,CACf,EACD,EACDK,EAAUP,CAAM,EAAE,UAAUX,CAAU,EAE1C,CAAC,EAAED,CAAa,CAClB,CACF,CAEA,SAASe,GACPP,EACAY,EAAoD,SACpDC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,EAAA,CAAA,EAAA,UAAAA,CAAA,EAEA,GAAIF,IAAO,GAAM,CACfZ,EAAK,EACL,OAGF,GAAIY,IAAO,GAIX,KAAMG,EAAe,IAAIP,GAAe,CACtC,KAAM,UAAA,CACJO,EAAa,YAAW,EACxBf,EAAK,CACP,EACD,EAED,OAAOW,EAAUC,EAAE,MAAA,OAAAI,EAAA,CAAA,EAAAC,EAAIJ,CAAI,CAAA,CAAA,CAAA,EAAG,UAAUE,CAAY,EACtD,CChHM,SAAUG,EACdC,EACAC,EACAC,EAAyB,WAErBC,EACAC,EAAW,GACf,OAAIJ,GAAsB,OAAOA,GAAuB,UACnDK,EAA8EL,EAAkB,WAAhGG,EAAUE,IAAA,OAAG,IAAQA,EAAEC,EAAuDN,EAAkB,WAAzEC,EAAUK,IAAA,OAAG,IAAQA,EAAEC,EAAgCP,EAAkB,SAAlDI,EAAQG,IAAA,OAAG,GAAKA,EAAEL,EAAcF,EAAkB,WAEnGG,EAAcH,GAAkB,KAAlBA,EAAsB,IAE/BQ,GAAS,CACd,UAAW,UAAA,CAAM,OAAA,IAAIC,GAAcN,EAAYF,EAAYC,CAAS,CAAnD,EACjB,aAAc,GACd,gBAAiB,GACjB,oBAAqBE,EACtB,CACH,CCxIM,SAAUM,GAAQC,EAAa,CACnC,OAAOC,EAAO,SAACC,EAAGC,EAAK,CAAK,OAAAH,GAASG,CAAT,CAAc,CAC5C,CCaM,SAAUC,GAAaC,EAA8B,CACzD,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAS,GAEPC,EAAiBC,EACrBH,EACA,UAAA,CACEE,GAAc,MAAdA,EAAgB,YAAW,EAC3BD,EAAS,EACX,EACAG,EAAI,EAGNC,EAAUR,CAAQ,EAAE,UAAUK,CAAc,EAE5CH,EAAO,UAAUI,EAAyBH,EAAY,SAACM,EAAK,CAAK,OAAAL,GAAUD,EAAW,KAAKM,CAAK,CAA/B,CAAgC,CAAC,CACpG,CAAC,CACH,CCVM,SAAUC,GAAS,SAAOC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EAC9B,IAAMC,EAAYC,GAAaH,CAAM,EACrC,OAAOI,EAAQ,SAACC,EAAQC,EAAU,EAI/BJ,EAAYK,GAAOP,EAAQK,EAAQH,CAAS,EAAIK,GAAOP,EAAQK,CAAM,GAAG,UAAUC,CAAU,CAC/F,CAAC,CACH,CCmBM,SAAUE,EACdC,EACAC,EAA6G,CAE7G,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAyD,KACzDC,EAAQ,EAERC,EAAa,GAIXC,EAAgB,UAAA,CAAM,OAAAD,GAAc,CAACF,GAAmBD,EAAW,SAAQ,CAArD,EAE5BD,EAAO,UACLM,EACEL,EACA,SAACM,EAAK,CAEJL,GAAe,MAAfA,EAAiB,YAAW,EAC5B,IAAIM,EAAa,EACXC,EAAaN,IAEnBO,EAAUb,EAAQU,EAAOE,CAAU,CAAC,EAAE,UACnCP,EAAkBI,EACjBL,EAIA,SAACU,EAAU,CAAK,OAAAV,EAAW,KAAKH,EAAiBA,EAAeS,EAAOI,EAAYF,EAAYD,GAAY,EAAIG,CAAU,CAAzG,EAChB,UAAA,CAIET,EAAkB,KAClBG,EAAa,CACf,CAAC,CACD,CAEN,EACA,UAAA,CACED,EAAa,GACbC,EAAa,CACf,CAAC,CACF,CAEL,CAAC,CACH,CCvFM,SAAUO,EAAaC,EAA8B,CACzD,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChCC,EAAUJ,CAAQ,EAAE,UAAUK,EAAyBF,EAAY,UAAA,CAAM,OAAAA,EAAW,SAAQ,CAAnB,EAAuBG,EAAI,CAAC,EACrG,CAACH,EAAW,QAAUD,EAAO,UAAUC,CAAU,CACnD,CAAC,CACH,CCIM,SAAUI,GAAaC,EAAiDC,EAAiB,CAAjB,OAAAA,IAAA,SAAAA,EAAA,IACrEC,EAAQ,SAACC,EAAQC,EAAU,CAChC,IAAIC,EAAQ,EACZF,EAAO,UACLG,EAAyBF,EAAY,SAACG,EAAK,CACzC,IAAMC,EAASR,EAAUO,EAAOF,GAAO,GACtCG,GAAUP,IAAcG,EAAW,KAAKG,CAAK,EAC9C,CAACC,GAAUJ,EAAW,SAAQ,CAChC,CAAC,CAAC,CAEN,CAAC,CACH,CCqGM,SAAUK,EACdC,EACAC,EACAC,EAA8B,CAK9B,IAAMC,EACJC,EAAWJ,CAAc,GAAKC,GAASC,EAElC,CAAE,KAAMF,EAA2E,MAAKC,EAAE,SAAQC,CAAA,EACnGF,EAEN,OAAOG,EACHE,EAAQ,SAACC,EAAQC,EAAU,QACzBC,EAAAL,EAAY,aAAS,MAAAK,IAAA,QAAAA,EAAA,KAArBL,CAAW,EACX,IAAIM,EAAU,GACdH,EAAO,UACLI,EACEH,EACA,SAACI,EAAK,QACJH,EAAAL,EAAY,QAAI,MAAAK,IAAA,QAAAA,EAAA,KAAhBL,EAAmBQ,CAAK,EACxBJ,EAAW,KAAKI,CAAK,CACvB,EACA,UAAA,OACEF,EAAU,IACVD,EAAAL,EAAY,YAAQ,MAAAK,IAAA,QAAAA,EAAA,KAApBL,CAAW,EACXI,EAAW,SAAQ,CACrB,EACA,SAACK,EAAG,OACFH,EAAU,IACVD,EAAAL,EAAY,SAAK,MAAAK,IAAA,QAAAA,EAAA,KAAjBL,EAAoBS,CAAG,EACvBL,EAAW,MAAMK,CAAG,CACtB,EACA,UAAA,SACMH,KACFD,EAAAL,EAAY,eAAW,MAAAK,IAAA,QAAAA,EAAA,KAAvBL,CAAW,IAEbU,EAAAV,EAAY,YAAQ,MAAAU,IAAA,QAAAA,EAAA,KAApBV,CAAW,CACb,CAAC,CACF,CAEL,CAAC,EAIDW,EACN,CCnIM,SAAUC,GAAYC,EAAsDC,EAAuB,CACvG,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAC1B,IAAAC,EAAuCJ,GAAM,KAANA,EAAU,CAAA,EAA/CK,EAAAD,EAAA,QAAAE,EAAOD,IAAA,OAAG,GAAIA,EAAEE,EAAAH,EAAA,SAAAI,EAAQD,IAAA,OAAG,GAAKA,EACpCE,EAAW,GACXC,EAAsB,KACtBC,EAAiC,KACjCC,EAAa,GAEXC,EAAgB,UAAA,CACpBF,GAAS,MAATA,EAAW,YAAW,EACtBA,EAAY,KACRH,IACFM,EAAI,EACJF,GAAcT,EAAW,SAAQ,EAErC,EAEMY,EAAoB,UAAA,CACxBJ,EAAY,KACZC,GAAcT,EAAW,SAAQ,CACnC,EAEMa,EAAgB,SAACC,GAAQ,CAC7B,OAACN,EAAYO,EAAUnB,EAAiBkB,EAAK,CAAC,EAAE,UAAUE,EAAyBhB,EAAYU,EAAeE,CAAiB,CAAC,CAAhI,EAEID,EAAO,UAAA,CACX,GAAIL,EAAU,CAIZA,EAAW,GACX,IAAMQ,GAAQP,EACdA,EAAY,KAEZP,EAAW,KAAKc,EAAK,EACrB,CAACL,GAAcI,EAAcC,EAAK,EAEtC,EAEAf,EAAO,UACLiB,EACEhB,EAMA,SAACc,GAAK,CACJR,EAAW,GACXC,EAAYO,GACZ,EAAEN,GAAa,CAACA,EAAU,UAAYL,EAAUQ,EAAI,EAAKE,EAAcC,EAAK,EAC9E,EACA,UAAA,CACEL,EAAa,GACb,EAAEJ,GAAYC,GAAYE,GAAa,CAACA,EAAU,SAAWR,EAAW,SAAQ,CAClF,CAAC,CACF,CAEL,CAAC,CACH,CCxFM,SAAUiB,GACdC,EACAC,EACAC,EAAuB,CADvBD,IAAA,SAAAA,EAAAE,IAGA,IAAMC,EAAYC,GAAML,EAAUC,CAAS,EAC3C,OAAOK,GAAS,UAAA,CAAM,OAAAF,CAAA,EAAWF,CAAM,CACzC,CCJM,SAAUK,IAAc,SAAOC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACnC,IAAMC,EAAUC,GAAkBH,CAAM,EAExC,OAAOI,EAAQ,SAACC,EAAQC,EAAU,CAehC,QAdMC,EAAMP,EAAO,OACbQ,EAAc,IAAI,MAAMD,CAAG,EAI7BE,EAAWT,EAAO,IAAI,UAAA,CAAM,MAAA,EAAA,CAAK,EAGjCU,EAAQ,cAMHC,EAAC,CACRC,EAAUZ,EAAOW,CAAC,CAAC,EAAE,UACnBE,EACEP,EACA,SAACQ,EAAK,CACJN,EAAYG,CAAC,EAAIG,EACb,CAACJ,GAAS,CAACD,EAASE,CAAC,IAEvBF,EAASE,CAAC,EAAI,IAKbD,EAAQD,EAAS,MAAMM,EAAQ,KAAON,EAAW,MAEtD,EAGAO,EAAI,CACL,GAnBIL,EAAI,EAAGA,EAAIJ,EAAKI,MAAhBA,CAAC,EAwBVN,EAAO,UACLQ,EAAyBP,EAAY,SAACQ,EAAK,CACzC,GAAIJ,EAAO,CAET,IAAMO,EAAMC,EAAA,CAAIJ,CAAK,EAAAK,EAAKX,CAAW,CAAA,EACrCF,EAAW,KAAKJ,EAAUA,EAAO,MAAA,OAAAgB,EAAA,CAAA,EAAAC,EAAIF,CAAM,CAAA,CAAA,EAAIA,CAAM,EAEzD,CAAC,CAAC,CAEN,CAAC,CACH,CCxFM,SAAUG,IAAG,SAAOC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACxB,OAAOC,EAAQ,SAACC,EAAQC,EAAU,CAChCL,GAAS,MAAA,OAAAM,EAAA,CAACF,CAA8B,EAAAG,EAAMN,CAAuC,CAAA,CAAA,EAAE,UAAUI,CAAU,CAC7G,CAAC,CACH,CCCM,SAAUG,IAAO,SAAkCC,EAAA,CAAA,EAAAC,EAAA,EAAAA,EAAA,UAAA,OAAAA,IAAAD,EAAAC,CAAA,EAAA,UAAAA,CAAA,EACvD,OAAOC,GAAG,MAAA,OAAAC,EAAA,CAAA,EAAAC,EAAIJ,CAAW,CAAA,CAAA,CAC3B,CCYO,SAASK,IAAmC,CACjD,IAAMC,EAAY,IAAIC,GAAwB,CAAC,EAC/C,OAAAC,EAAU,SAAU,mBAAoB,CAAE,KAAM,EAAK,CAAC,EACnD,UAAU,IAAMF,EAAU,KAAK,QAAQ,CAAC,EAGpCA,CACT,CCHO,SAASG,EACdC,EAAkBC,EAAmB,SAChC,CACL,OAAO,MAAM,KAAKA,EAAK,iBAAoBD,CAAQ,CAAC,CACtD,CAuBO,SAASE,EACdF,EAAkBC,EAAmB,SAClC,CACH,IAAME,EAAKC,GAAsBJ,EAAUC,CAAI,EAC/C,GAAI,OAAOE,GAAO,YAChB,MAAM,IAAI,eACR,8BAA8BH,CAAQ,iBACxC,EAGF,OAAOG,CACT,CAsBO,SAASC,GACdJ,EAAkBC,EAAmB,SACtB,CACf,OAAOA,EAAK,cAAiBD,CAAQ,GAAK,MAC5C,CAOO,SAASK,IAA4C,CAnH5D,IAAAC,EAAAC,EAAAC,EAAAC,EAoHE,OACEA,GAAAD,GAAAD,GAAAD,EAAA,SAAS,gBAAT,YAAAA,EAAwB,aAAxB,YAAAC,EAAoC,gBAApC,KAAAC,EACA,SAAS,gBADT,KAAAC,EAEA,MAEJ,CCvEA,IAAMC,GAAYC,EAChBC,EAAU,SAAS,KAAM,SAAS,EAClCA,EAAU,SAAS,KAAM,UAAU,CACrC,EACG,KACCC,GAAa,CAAC,EACdC,EAAU,MAAS,EACnBC,EAAI,IAAMC,GAAiB,GAAK,SAAS,IAAI,EAC7CC,EAAY,CAAC,CACf,EAaK,SAASC,GACdC,EACqB,CACrB,OAAOT,GACJ,KACCK,EAAIK,GAAUD,EAAG,SAASC,CAAM,CAAC,EACjCC,EAAqB,CACvB,CACJ,CC7BO,SAASC,GACdC,EAAiBC,EACI,CACrB,OAAOC,EAAM,IAAMC,EACjBC,EAAUJ,EAAI,YAAY,EAAE,KAAKK,EAAI,IAAM,EAAI,CAAC,EAChDD,EAAUJ,EAAI,YAAY,EAAE,KAAKK,EAAI,IAAM,EAAK,CAAC,CACnD,EACG,KACCJ,EAAUK,GAASC,GAAUC,GAAM,CAAC,CAACD,EAASN,CAAO,CAAC,EAAIQ,GAC1DC,EAAUV,EAAG,QAAQ,QAAQ,CAAC,CAChC,CACF,CACF,CCPA,SAASW,GAAYC,EAAiBC,EAA8B,CAGlE,GAAI,OAAOA,GAAU,UAAY,OAAOA,GAAU,SAChDD,EAAG,WAAaC,EAAM,SAAS,UAGtBA,aAAiB,KAC1BD,EAAG,YAAYC,CAAK,UAGX,MAAM,QAAQA,CAAK,EAC5B,QAAWC,KAAQD,EACjBF,GAAYC,EAAIE,CAAI,CAE1B,CAyBO,SAASC,EACdC,EAAaC,KAAmCC,EAC7C,CACH,IAAMN,EAAK,SAAS,cAAcI,CAAG,EAGrC,GAAIC,EACF,QAAWE,KAAQ,OAAO,KAAKF,CAAU,EACnC,OAAOA,EAAWE,CAAI,GAAM,cAI5B,OAAOF,EAAWE,CAAI,GAAM,UAC9BP,EAAG,aAAaO,EAAMF,EAAWE,CAAI,CAAC,EAEtCP,EAAG,aAAaO,EAAM,EAAE,GAI9B,QAAWN,KAASK,EAClBP,GAAYC,EAAIC,CAAK,EAGvB,OAAOD,CACT,CC9EO,SAASQ,GAAMC,EAAuB,CAC3C,GAAIA,EAAQ,IAAK,CACf,IAAMC,EAAS,GAAGD,EAAQ,KAAO,IAAO,IACxC,MAAO,KAAKA,EAAQ,MAAY,KAAM,QAAQC,CAAM,CAAC,GACvD,KACE,QAAOD,EAAM,SAAS,CAE1B,CCCO,SAASE,GAAYC,EAA+B,CACzD,IAAMC,EAASC,EAAE,SAAU,CAAE,IAAAF,CAAI,CAAC,EAClC,OAAOG,EAAM,KACX,SAAS,KAAK,YAAYF,CAAM,EACzBG,EACLC,EAAUJ,EAAQ,MAAM,EACxBI,EAAUJ,EAAQ,OAAO,EACtB,KACCK,EAAU,IACRC,GAAW,IAAM,IAAI,eAAe,mBAAmBP,CAAG,EAAE,CAAC,CAC9D,CACH,CACJ,EACG,KACCQ,EAAI,IAAG,EAAY,EACnBC,EAAS,IAAM,SAAS,KAAK,YAAYR,CAAM,CAAC,EAChDS,GAAK,CAAC,CACR,EACH,CACH,CCVA,IAAMC,GAAS,IAAIC,EAiBbC,GAAYC,EAAM,IACtB,OAAO,gBAAmB,YACtBC,GAAY,4CAA4C,EACxDC,EAAG,MAAS,CACjB,EACE,KACCC,EAAI,IAAM,IAAI,eAAeC,GAC3BA,EAAQ,QAAQC,GAASR,GAAO,KAAKQ,CAAK,CAAC,CAC5C,CAAC,EACFC,EAAUC,GAAYC,EAAMC,GAAOP,EAAGK,CAAQ,CAAC,EAAE,KAC/CG,EAAS,IAAMH,EAAS,WAAW,CAAC,CACtC,CAAC,EACDI,EAAY,CAAC,CACf,EAaK,SAASC,GACdC,EACa,CACb,MAAO,CACL,MAAQA,EAAG,YACX,OAAQA,EAAG,YACb,CACF,CAuBO,SAASC,GACdD,EACyB,CAMzB,IAAIE,EAASF,EACb,KAAOE,EAAO,cAAgB,GACxBA,EAAO,eACTA,EAASA,EAAO,cAMpB,OAAOhB,GAAU,KACfiB,EAAIT,GAAYA,EAAS,QAAQQ,CAAM,CAAC,EACxCT,EAAUC,GAAYV,GAAO,KAC3BoB,EAAOZ,GAASA,EAAM,SAAWU,CAAM,EACvCL,EAAS,IAAMH,EAAS,UAAUQ,CAAM,CAAC,CAC3C,CAAC,EACDZ,EAAI,IAAMS,GAAeC,CAAE,CAAC,EAC5BK,EAAUN,GAAeC,CAAE,CAAC,CAC9B,CACF,CC3HO,SAASM,GACdC,EACa,CACb,MAAO,CACL,MAAQA,EAAG,YACX,OAAQA,EAAG,YACb,CACF,CASO,SAASC,GACdD,EACyB,CACzB,IAAIE,EAASF,EAAG,cAChB,KAAOE,IAEHF,EAAG,aAAgBE,EAAO,aAC1BF,EAAG,cAAgBE,EAAO,eAE1BA,GAAUF,EAAKE,GAAQ,cAK3B,OAAOA,EAASF,EAAK,MACvB,CAYO,SAASG,GACdH,EACe,CACf,IAAMI,EAA4B,CAAC,EAG/BF,EAASF,EAAG,cAChB,KAAOE,IAEHF,EAAG,YAAeE,EAAO,aACzBF,EAAG,aAAeE,EAAO,eAEzBE,EAAW,KAAKF,CAAM,EAGxBA,GAAUF,EAAKE,GAAQ,cAKzB,OAAIE,EAAW,SAAW,GACxBA,EAAW,KAAK,SAAS,eAAe,EAGnCA,CACT,CC9CO,SAASC,GACdC,EACe,CACf,MAAO,CACL,EAAGA,EAAG,WACN,EAAGA,EAAG,SACR,CACF,CASO,SAASC,GACdD,EACe,CACf,IAAME,EAAOF,EAAG,sBAAsB,EACtC,MAAO,CACL,EAAGE,EAAK,EAAI,OAAO,QACnB,EAAGA,EAAK,EAAI,OAAO,OACrB,CACF,CAWO,SAASC,GACdH,EAC2B,CAC3B,OAAOI,EACLC,EAAU,OAAQ,MAAM,EACxBA,EAAU,OAAQ,QAAQ,CAC5B,EACG,KACCC,GAAU,EAAGC,EAAuB,EACpCC,EAAI,IAAMT,GAAiBC,CAAE,CAAC,EAC9BS,EAAUV,GAAiBC,CAAE,CAAC,CAChC,CACJ,CC3DO,SAASU,GACdC,EACe,CACf,MAAO,CACL,EAAGA,EAAG,WACN,EAAGA,EAAG,SACR,CACF,CAWO,SAASC,GACdD,EAC2B,CAC3B,OAAOE,EACLC,EAAUH,EAAI,QAAQ,EACtBG,EAAU,OAAQ,QAAQ,EAC1BA,EAAU,OAAQ,QAAQ,CAC5B,EACG,KACCC,GAAU,EAAGC,EAAuB,EACpCC,EAAI,IAAMP,GAAwBC,CAAE,CAAC,EACrCO,EAAUR,GAAwBC,CAAE,CAAC,CACvC,CACJ,CCzBA,IAAMQ,GAAS,IAAIC,EAUbC,GAAYC,EAAM,IAAMC,EAC5B,IAAI,qBAAqBC,GAAW,CAClC,QAAWC,KAASD,EAClBL,GAAO,KAAKM,CAAK,CACrB,EAAG,CACD,UAAW,CACb,CAAC,CACH,CAAC,EACE,KACCC,EAAUC,GAAYC,EAAMC,GAAON,EAAGI,CAAQ,CAAC,EAC5C,KACCG,EAAS,IAAMH,EAAS,WAAW,CAAC,CACtC,CACF,EACAI,EAAY,CAAC,CACf,EAaK,SAASC,GACdC,EACqB,CACrB,OAAOZ,GACJ,KACCa,EAAIP,GAAYA,EAAS,QAAQM,CAAE,CAAC,EACpCP,EAAUC,GAAYR,GACnB,KACCgB,EAAO,CAAC,CAAE,OAAAC,CAAO,IAAMA,IAAWH,CAAE,EACpCH,EAAS,IAAMH,EAAS,UAAUM,CAAE,CAAC,EACrCI,EAAI,CAAC,CAAE,eAAAC,CAAe,IAAMA,CAAc,CAC5C,CACF,CACF,CACJ,CAaO,SAASC,GACdN,EAAiBO,EAAY,GACR,CACrB,OAAOC,GAA0BR,CAAE,EAChC,KACCI,EAAI,CAAC,CAAE,EAAAK,CAAE,IAAM,CACb,IAAMC,EAAUC,GAAeX,CAAE,EAC3BY,EAAUC,GAAsBb,CAAE,EACxC,OAAOS,GACLG,EAAQ,OAASF,EAAQ,OAASH,CAEtC,CAAC,EACDO,EAAqB,CACvB,CACJ,CCjFA,IAAMC,GAA4C,CAChD,OAAQC,EAAW,yBAAyB,EAC5C,OAAQA,EAAW,yBAAyB,CAC9C,EAaO,SAASC,GAAUC,EAAuB,CAC/C,OAAOH,GAAQG,CAAI,EAAE,OACvB,CAaO,SAASC,GAAUD,EAAcE,EAAsB,CACxDL,GAAQG,CAAI,EAAE,UAAYE,GAC5BL,GAAQG,CAAI,EAAE,MAAM,CACxB,CAWO,SAASG,GAAYH,EAAmC,CAC7D,IAAMI,EAAKP,GAAQG,CAAI,EACvB,OAAOK,EAAUD,EAAI,QAAQ,EAC1B,KACCE,EAAI,IAAMF,EAAG,OAAO,EACpBG,EAAUH,EAAG,OAAO,CACtB,CACJ,CC9BA,SAASI,GACPC,EAAiBC,EACR,CACT,OAAQD,EAAG,YAAa,CAGtB,KAAK,iBAEH,OAAIA,EAAG,OAAS,QACP,SAAS,KAAKC,CAAI,EAElB,GAGX,KAAK,kBACL,KAAK,oBACH,MAAO,GAGT,QACE,OAAOD,EAAG,iBACd,CACF,CAWO,SAASE,IAAwC,CACtD,OAAOC,EACLC,EAAU,OAAQ,kBAAkB,EAAE,KAAKC,EAAI,IAAM,EAAI,CAAC,EAC1DD,EAAU,OAAQ,gBAAgB,EAAE,KAAKC,EAAI,IAAM,EAAK,CAAC,CAC3D,EACG,KACCC,EAAU,EAAK,CACjB,CACJ,CAOO,SAASC,IAAsC,CACpD,IAAMC,EAAYJ,EAAyB,OAAQ,SAAS,EACzD,KACCK,EAAOC,GAAM,EAAEA,EAAG,SAAWA,EAAG,QAAQ,EACxCL,EAAIK,IAAO,CACT,KAAMC,GAAU,QAAQ,EAAI,SAAW,SACvC,KAAMD,EAAG,IACT,OAAQ,CACNA,EAAG,eAAe,EAClBA,EAAG,gBAAgB,CACrB,CACF,EAAc,EACdD,EAAO,CAAC,CAAE,KAAAG,EAAM,KAAAX,CAAK,IAAM,CACzB,GAAIW,IAAS,SAAU,CACrB,IAAMC,EAASC,GAAiB,EAChC,GAAI,OAAOD,GAAW,YACpB,MAAO,CAACd,GAAwBc,EAAQZ,CAAI,CAChD,CACA,MAAO,EACT,CAAC,EACDc,GAAM,CACR,EAGF,OAAOb,GAAiB,EACrB,KACCc,EAAUH,GAAWA,EAAqBI,EAAZT,CAAiB,CACjD,CACJ,CC1GO,SAASU,IAAmB,CACjC,OAAO,IAAI,IAAI,SAAS,IAAI,CAC9B,CAgBO,SAASC,GACdC,EAA4BC,EAAW,GACjC,CACN,GAAIC,EAAQ,oBAAoB,GAAK,CAACD,EAAU,CAC9C,IAAME,EAAKC,EAAE,IAAK,CAAE,KAAMJ,EAAI,IAAK,CAAC,EACpC,SAAS,KAAK,YAAYG,CAAE,EAC5BA,EAAG,MAAM,EACTA,EAAG,OAAO,CAIZ,MACE,SAAS,KAAOH,EAAI,IAExB,CASO,SAASK,IAA8B,CAC5C,OAAO,IAAIC,CACb,CCxCO,SAASC,IAA0B,CACxC,OAAO,SAAS,KAAK,MAAM,CAAC,CAC9B,CAYO,SAASC,GAAgBC,EAAoB,CAClD,IAAMC,EAAKC,EAAE,IAAK,CAAE,KAAMF,CAAK,CAAC,EAChCC,EAAG,iBAAiB,QAASE,GAAMA,EAAG,gBAAgB,CAAC,EACvDF,EAAG,MAAM,CACX,CAWO,SAASG,GACdC,EACoB,CACpB,OAAOC,EACLC,EAA2B,OAAQ,YAAY,EAC/CF,CACF,EACG,KACCG,EAAIV,EAAe,EACnBW,EAAUX,GAAgB,CAAC,EAC3BY,EAAOV,GAAQA,EAAK,OAAS,CAAC,EAC9BW,EAAY,CAAC,CACf,CACJ,CASO,SAASC,GACdP,EACyB,CACzB,OAAOD,GAAkBC,CAAS,EAC/B,KACCG,EAAIK,GAAMC,GAAmB,QAAQD,CAAE,IAAI,CAAE,EAC7CH,EAAOT,GAAM,OAAOA,GAAO,WAAW,CACxC,CACJ,CCtDO,SAASc,GAAWC,EAAoC,CAC7D,IAAMC,EAAQ,WAAWD,CAAK,EAC9B,OAAOE,GAA0BC,GAC/BF,EAAM,YAAY,IAAME,EAAKF,EAAM,OAAO,CAAC,CAC5C,EACE,KACCG,EAAUH,EAAM,OAAO,CACzB,CACJ,CAOO,SAASI,IAAkC,CAChD,IAAMJ,EAAQ,WAAW,OAAO,EAChC,OAAOK,EACLC,EAAU,OAAQ,aAAa,EAAE,KAAKC,EAAI,IAAM,EAAI,CAAC,EACrDD,EAAU,OAAQ,YAAY,EAAE,KAAKC,EAAI,IAAM,EAAK,CAAC,CACvD,EACG,KACCJ,EAAUH,EAAM,OAAO,CACzB,CACJ,CAcO,SAASQ,GACdC,EAA6BC,EACd,CACf,OAAOD,EACJ,KACCE,EAAUC,GAAUA,EAASF,EAAQ,EAAIG,CAAK,CAChD,CACJ,CC/BO,SAASC,GACdC,EAAmBC,EACD,CAClB,OAAO,IAAIC,EAAiBC,GAAY,CACtC,IAAMC,EAAM,IAAI,eAChB,OAAAA,EAAI,KAAK,MAAO,GAAGJ,CAAG,EAAE,EACxBI,EAAI,aAAe,OAGnBA,EAAI,iBAAiB,OAAQ,IAAM,CAC7BA,EAAI,QAAU,KAAOA,EAAI,OAAS,KACpCD,EAAS,KAAKC,EAAI,QAAQ,EAC1BD,EAAS,SAAS,GAIlBA,EAAS,MAAM,IAAI,MAAMC,EAAI,UAAU,CAAC,CAE5C,CAAC,EAGDA,EAAI,iBAAiB,QAAS,IAAM,CAClCD,EAAS,MAAM,IAAI,MAAM,eAAe,CAAC,CAC3C,CAAC,EAGDC,EAAI,iBAAiB,QAAS,IAAM,CAClCD,EAAS,SAAS,CACpB,CAAC,EAGG,OAAOF,GAAA,YAAAA,EAAS,YAAc,cAChCG,EAAI,iBAAiB,WAAYC,GAAS,CA/FhD,IAAAC,EAgGQ,GAAID,EAAM,iBACRJ,EAAQ,UAAW,KAAMI,EAAM,OAASA,EAAM,MAAS,GAAG,MAIrD,CACL,IAAME,GAASD,EAAAF,EAAI,kBAAkB,gBAAgB,IAAtC,KAAAE,EAA2C,EAC1DL,EAAQ,UAAW,KAAMI,EAAM,OAAS,CAACE,EAAU,GAAG,CACxD,CACF,CAAC,EAGDN,EAAQ,UAAU,KAAK,CAAC,GAI1BG,EAAI,KAAK,EACF,IAAMA,EAAI,MAAM,CACzB,CAAC,CACH,CAcO,SAASI,GACdR,EAAmBC,EACJ,CACf,OAAOF,GAAQC,EAAKC,CAAO,EACxB,KACCQ,EAAUC,GAAOA,EAAI,KAAK,CAAC,EAC3BC,EAAIC,GAAQ,KAAK,MAAMA,CAAI,CAAM,EACjCC,EAAY,CAAC,CACf,CACJ,CAUO,SAASC,GACdd,EAAmBC,EACG,CACtB,IAAMc,EAAM,IAAI,UAChB,OAAOhB,GAAQC,EAAKC,CAAO,EACxB,KACCQ,EAAUC,GAAOA,EAAI,KAAK,CAAC,EAC3BC,EAAID,GAAOK,EAAI,gBAAgBL,EAAK,WAAW,CAAC,EAChDG,EAAY,CAAC,CACf,CACJ,CAUO,SAASG,GACdhB,EAAmBC,EACG,CACtB,IAAMc,EAAM,IAAI,UAChB,OAAOhB,GAAQC,EAAKC,CAAO,EACxB,KACCQ,EAAUC,GAAOA,EAAI,KAAK,CAAC,EAC3BC,EAAID,GAAOK,EAAI,gBAAgBL,EAAK,UAAU,CAAC,EAC/CG,EAAY,CAAC,CACf,CACJ,CC5HO,SAASI,IAAoC,CAClD,MAAO,CACL,EAAG,KAAK,IAAI,EAAG,OAAO,EACtB,EAAG,KAAK,IAAI,EAAG,OAAO,CACxB,CACF,CASO,SAASC,IAAkD,CAChE,OAAOC,EACLC,EAAU,OAAQ,SAAU,CAAE,QAAS,EAAK,CAAC,EAC7CA,EAAU,OAAQ,SAAU,CAAE,QAAS,EAAK,CAAC,CAC/C,EACG,KACCC,EAAIJ,EAAiB,EACrBK,EAAUL,GAAkB,CAAC,CAC/B,CACJ,CC3BO,SAASM,IAAgC,CAC9C,MAAO,CACL,MAAQ,WACR,OAAQ,WACV,CACF,CASO,SAASC,IAA8C,CAC5D,OAAOC,EAAU,OAAQ,SAAU,CAAE,QAAS,EAAK,CAAC,EACjD,KACCC,EAAIH,EAAe,EACnBI,EAAUJ,GAAgB,CAAC,CAC7B,CACJ,CCXO,SAASK,IAAsC,CACpD,OAAOC,EAAc,CACnBC,GAAoB,EACpBC,GAAkB,CACpB,CAAC,EACE,KACCC,EAAI,CAAC,CAACC,EAAQC,CAAI,KAAO,CAAE,OAAAD,EAAQ,KAAAC,CAAK,EAAE,EAC1CC,EAAY,CAAC,CACf,CACJ,CCVO,SAASC,GACdC,EAAiB,CAAE,UAAAC,EAAW,QAAAC,CAAQ,EAChB,CACtB,IAAMC,EAAQF,EACX,KACCG,GAAwB,MAAM,CAChC,EAGIC,EAAUC,EAAc,CAACH,EAAOD,CAAO,CAAC,EAC3C,KACCK,EAAI,IAAMC,GAAiBR,CAAE,CAAC,CAChC,EAGF,OAAOM,EAAc,CAACJ,EAASD,EAAWI,CAAO,CAAC,EAC/C,KACCE,EAAI,CAAC,CAAC,CAAE,OAAAE,CAAO,EAAG,CAAE,OAAAC,EAAQ,KAAAC,CAAK,EAAG,CAAE,EAAAC,EAAG,EAAAC,CAAE,CAAC,KAAO,CACjD,OAAQ,CACN,EAAGH,EAAO,EAAIE,EACd,EAAGF,EAAO,EAAIG,EAAIJ,CACpB,EACA,KAAAE,CACF,EAAE,CACJ,CACJ,CCzBA,SAASG,GAAQC,EAA+B,CAC9C,OAAOC,EAA8BD,EAAQ,UAAWE,GAAMA,EAAG,IAAI,CACvE,CAWA,SAASC,GAAQH,EAA4B,CAC3C,IAAMI,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAUE,GAAQN,EAAO,YAAYM,CAAI,CAAC,EAGzCF,CACT,CAgBO,SAASG,GACdC,EAAaR,EAAS,IAAI,OAAOQ,CAAG,EACxB,CACZ,IAAMC,EAAQV,GAAQC,CAAM,EACtBI,EAAQD,GAAQH,CAAM,EAGtBU,EAAU,IAAIL,EACpBK,EAAQ,UAAUN,CAAK,EAGvB,IAAMO,EAAQP,EAAM,KAAKQ,EAAe,EAAGC,GAAQ,EAAI,CAAC,EACxD,OAAOH,EACJ,KACCE,EAAe,EACfE,GAAUL,EAAM,KAAKM,EAAUJ,CAAK,CAAC,CAAC,EACtCK,GAAM,CACR,CACJ,CCJA,IAAMC,GAASC,EAAW,WAAW,EAC/BC,GAAiB,KAAK,MAAMF,GAAO,WAAY,EACrDE,GAAO,KAAO,GAAG,IAAI,IAAIA,GAAO,KAAMC,GAAY,CAAC,CAAC,GAW7C,SAASC,IAAwB,CACtC,OAAOF,EACT,CASO,SAASG,EAAQC,EAAqB,CAC3C,OAAOJ,GAAO,SAAS,SAASI,CAAI,CACtC,CAUO,SAASC,GACdC,EAAkBC,EACV,CACR,OAAO,OAAOA,GAAU,YACpBP,GAAO,aAAaM,CAAG,EAAE,QAAQ,IAAKC,EAAM,SAAS,CAAC,EACtDP,GAAO,aAAaM,CAAG,CAC7B,CChCO,SAASE,GACdC,EAASC,EAAmB,SACP,CACrB,OAAOC,EAAW,sBAAsBF,CAAI,IAAKC,CAAI,CACvD,CAYO,SAASE,GACdH,EAASC,EAAmB,SACL,CACvB,OAAOG,EAAY,sBAAsBJ,CAAI,IAAKC,CAAI,CACxD,CC7EO,SAASI,GACdC,EACsB,CACtB,IAAMC,EAASC,EAAW,6BAA8BF,CAAE,EAC1D,OAAOG,EAAUF,EAAQ,QAAS,CAAE,KAAM,EAAK,CAAC,EAC7C,KACCG,EAAI,IAAMF,EAAW,cAAeF,CAAE,CAAC,EACvCI,EAAIC,IAAY,CAAE,KAAM,UAAUA,EAAQ,SAAS,CAAE,EAAE,CACzD,CACJ,CASO,SAASC,GACdN,EACiC,CACjC,GAAI,CAACO,EAAQ,kBAAkB,GAAK,CAACP,EAAG,kBACtC,OAAOQ,EAGT,GAAI,CAACR,EAAG,OAAQ,CACd,IAAMK,EAAUH,EAAW,cAAeF,CAAE,EACxC,UAAUK,EAAQ,SAAS,IAAM,SAAS,YAAY,IACxDL,EAAG,OAAS,GAChB,CAGA,OAAOS,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAU,CAAC,CAAE,KAAAE,CAAK,IAAM,CAC5BZ,EAAG,OAAS,GAGZ,SAAiB,aAAcY,CAAI,CACrC,CAAC,EAGMb,GAAcC,CAAE,EACpB,KACCa,EAAIC,GAASJ,EAAM,KAAKI,CAAK,CAAC,EAC9BC,EAAS,IAAML,EAAM,SAAS,CAAC,EAC/BN,EAAIU,GAAUE,EAAA,CAAE,IAAKhB,GAAOc,EAAQ,CACtC,CACJ,CAAC,CACH,CC5BO,SAASG,GACdC,EAAiB,CAAE,QAAAC,CAAQ,EACN,CACrB,OAAOA,EACJ,KACCC,EAAIC,IAAW,CAAE,OAAQA,IAAWH,CAAG,EAAE,CAC3C,CACJ,CAYO,SAASI,GACdJ,EAAiBK,EACe,CAChC,IAAMC,EAAY,IAAIC,EACtB,OAAAD,EAAU,UAAU,CAAC,CAAE,OAAAE,CAAO,IAAM,CAClCR,EAAG,OAASQ,CACd,CAAC,EAGMT,GAAaC,EAAIK,CAAO,EAC5B,KACCI,EAAIC,GAASJ,EAAU,KAAKI,CAAK,CAAC,EAClCC,EAAS,IAAML,EAAU,SAAS,CAAC,EACnCJ,EAAIQ,GAAUE,EAAA,CAAE,IAAKZ,GAAOU,EAAQ,CACtC,CACJ,CCnEO,SAASG,GACdC,EAAaC,EACA,CACb,OAAIA,IAAU,SAEVC,EAAC,OAAI,MAAM,gCAAgC,GAAIF,EAAI,KAAK,WACtDE,EAAC,OAAI,MAAM,+BAA+B,CAC5C,EAIAA,EAAC,OAAI,MAAM,aAAa,GAAIF,EAAI,KAAK,WACnCE,EAAC,OAAI,MAAM,+BAA+B,CAC5C,CAGN,CAGO,SAASC,MACXC,EACU,CACb,OACEF,EAAC,OAAI,MAAM,cAAc,KAAK,WAC5BA,EAAC,OAAI,MAAM,iCACRE,CACH,CACF,CAEJ,CCvCO,SAASC,GACdC,EAAqBC,EACR,CAIb,GAHAA,EAASA,EAAS,GAAGA,CAAM,eAAeD,CAAE,GAAK,OAG7CC,EAAQ,CACV,IAAMC,EAASD,EAAS,IAAIA,CAAM,GAAK,OACvC,OACEE,EAAC,SAAM,MAAM,gBAAgB,SAAU,GACpCC,GAAcH,CAAM,EACrBE,EAAC,KAAE,KAAMD,EAAQ,MAAM,uBAAuB,SAAU,IACtDC,EAAC,QAAK,wBAAuBH,EAAI,CACnC,CACF,CAEJ,KACE,QACEG,EAAC,SAAM,MAAM,gBAAgB,SAAU,GACpCC,GAAcH,CAAM,EACrBE,EAAC,QAAK,MAAM,uBAAuB,SAAU,IAC3CA,EAAC,QAAK,wBAAuBH,EAAI,CACnC,CACF,CAGN,CC5BO,SAASK,GAAsBC,EAAyB,CAC7D,OACEC,EAAC,UACC,MAAM,uBACN,MAAOC,GAAY,gBAAgB,EACnC,wBAAuB,IAAIF,CAAE,UAC9B,CAEL,CCtBA,IAAAG,GAAuB,SA+BvB,SAASC,GACPC,EAAsBC,EACT,CACb,IAAMC,EAASD,EAAO,EAChBE,EAASF,EAAO,EAGhBG,EAAU,OAAO,KAAKJ,EAAS,KAAK,EACvC,OAAOK,GAAO,CAACL,EAAS,MAAMK,CAAG,CAAC,EAClC,OAAyB,CAACC,EAAMD,IAAQ,CACvC,GAAGC,EAAMC,EAAC,cAAK,GAAAC,SAAWH,CAAG,CAAE,EAAQ,GACzC,EAAG,CAAC,CAAC,EACJ,MAAM,EAAG,EAAE,EAGRI,EAASC,GAAc,EACvBC,EAAM,IAAI,IAAIX,EAAS,SAAUS,EAAO,IAAI,EAC9CG,EAAQ,kBAAkB,GAC5BD,EAAI,aAAa,IAAI,IAAK,OAAO,QAAQX,EAAS,KAAK,EACpD,OAAO,CAAC,CAAC,CAAEa,CAAK,IAAMA,CAAK,EAC3B,OAAO,CAACC,EAAW,CAACC,CAAK,IAAM,GAAGD,CAAS,IAAIC,CAAK,GAAG,KAAK,EAAG,EAAE,CACpE,EAGF,GAAM,CAAE,KAAAC,CAAK,EAAIN,GAAc,EAC/B,OACEH,EAAC,KAAE,KAAM,GAAGI,CAAG,GAAI,MAAM,yBAAyB,SAAU,IAC1DJ,EAAC,WACC,MAAM,uCACN,gBAAeP,EAAS,MAAM,QAAQ,CAAC,GAEtCE,EAAS,GAAKK,EAAC,OAAI,MAAM,iCAAiC,EAC1DL,EAAS,GAAKK,EAAC,UAAIP,EAAS,KAAM,EAClCE,GAAU,GAAKK,EAAC,UAAIP,EAAS,KAAM,EACnCG,EAAS,GAAKH,EAAS,KAAK,OAAS,GACpCA,EAAS,KAEVA,EAAS,MACRO,EAAC,OAAI,MAAM,WACRP,EAAS,KAAK,IAAIiB,GAAO,CACxB,IAAMC,EAAOF,EACTC,KAAOD,EACL,uBAAuBA,EAAKC,CAAG,CAAC,GAChC,cACF,GACJ,OACEV,EAAC,QAAK,MAAO,UAAUW,CAAI,IAAKD,CAAI,CAExC,CAAC,CACH,EAEDd,EAAS,GAAKC,EAAQ,OAAS,GAC9BG,EAAC,KAAE,MAAM,2BACNY,GAAY,4BAA4B,EAAE,KAAG,GAAGf,CACnD,CAEJ,CACF,CAEJ,CAaO,SAASgB,GACdC,EACa,CACb,IAAMC,EAAYD,EAAO,CAAC,EAAE,MACtBE,EAAO,CAAC,GAAGF,CAAM,EAEjBZ,EAASC,GAAc,EAGvBR,EAASqB,EAAK,UAAUC,GAErB,CADG,GAAG,IAAI,IAAIA,EAAI,SAAUf,EAAO,IAAI,CAAC,GACrC,SAAS,GAAG,CACvB,EACK,CAACgB,CAAO,EAAIF,EAAK,OAAOrB,EAAQ,CAAC,EAGnCwB,EAAQH,EAAK,UAAUC,GAAOA,EAAI,MAAQF,CAAS,EACnDI,IAAU,KACZA,EAAQH,EAAK,QAGf,IAAMI,EAAOJ,EAAK,MAAM,EAAGG,CAAK,EAC1BE,EAAOL,EAAK,MAAMG,CAAK,EAGvBG,EAAW,CACf9B,GAAqB0B,EAAS,EAAc,EAAE,CAACvB,GAAUwB,IAAU,EAAE,EACrE,GAAGC,EAAK,IAAIG,GAAW/B,GAAqB+B,EAAS,CAAW,CAAC,EACjE,GAAGF,EAAK,OAAS,CACfrB,EAAC,WAAQ,MAAM,0BACbA,EAAC,WAAQ,SAAU,IACjBA,EAAC,WACEqB,EAAK,OAAS,GAAKA,EAAK,SAAW,EAChCT,GAAY,wBAAwB,EACpCA,GAAY,2BAA4BS,EAAK,MAAM,CAEzD,CACF,EACC,GAAGA,EAAK,IAAIE,GAAW/B,GAAqB+B,EAAS,CAAW,CAAC,CACpE,CACF,EAAI,CAAC,CACP,EAGA,OACEvB,EAAC,MAAG,MAAM,0BACPsB,CACH,CAEJ,CC1IO,SAASE,GAAkBC,EAAiC,CACjE,OACEC,EAAC,MAAG,MAAM,oBACP,OAAO,QAAQD,CAAK,EAAE,IAAI,CAAC,CAACE,EAAKC,CAAK,IACrCF,EAAC,MAAG,MAAO,oCAAoCC,CAAG,IAC/C,OAAOC,GAAU,SAAWC,GAAMD,CAAK,EAAIA,CAC9C,CACD,CACH,CAEJ,CCAO,SAASE,GACdC,EACa,CACb,IAAMC,EAAU,kCAAkCD,CAAI,GACtD,OACEE,EAAC,OAAI,MAAOD,EAAS,OAAM,IACzBC,EAAC,UAAO,MAAM,gBAAgB,SAAU,GAAI,cAAY,OAAO,CACjE,CAEJ,CCpBO,SAASC,GAAYC,EAAiC,CAC3D,OACEC,EAAC,OAAI,MAAM,0BACTA,EAAC,OAAI,MAAM,qBACRD,CACH,CACF,CAEJ,CCcA,SAASE,GAAcC,EAA+B,CAzDtD,IAAAC,EA0DE,IAAMC,EAASC,GAAc,EAGvBC,EAAM,IAAI,IAAI,MAAMJ,EAAQ,OAAO,IAAKE,EAAO,IAAI,EACzD,OACEG,EAAC,MAAG,MAAM,oBACRA,EAAC,KAAE,KAAM,GAAGD,CAAG,GAAI,MAAM,oBACtBJ,EAAQ,QACRC,EAAAC,EAAO,UAAP,YAAAD,EAAgB,QAASD,EAAQ,QAAQ,OAAS,GACjDK,EAAC,QAAK,MAAM,qBACTL,EAAQ,QAAQ,CAAC,CACpB,CAEJ,CACF,CAEJ,CAcO,SAASM,GACdC,EAAqBC,EACR,CA1Ff,IAAAP,EA2FE,IAAMC,EAASC,GAAc,EAC7B,OAAAI,EAAWA,EAAS,OAAOP,GAAQ,CA5FrC,IAAAC,EA4FwC,SAACA,EAAAD,EAAQ,aAAR,MAAAC,EAAoB,QAAM,EAE/DI,EAAC,OAAI,MAAM,cACTA,EAAC,UACC,MAAM,sBACN,aAAYI,GAAY,gBAAgB,GAEvCD,EAAO,QACPP,EAAAC,EAAO,UAAP,YAAAD,EAAgB,QAASO,EAAO,QAAQ,OAAS,GAChDH,EAAC,QAAK,MAAM,qBACTG,EAAO,QAAQ,CAAC,CACnB,CAEJ,EACAH,EAAC,MAAG,MAAM,oBACPE,EAAS,IAAIR,EAAa,CAC7B,CACF,CAEJ,CCdA,IAAIW,GAAW,EAkBR,SAASC,GACdC,EACqB,CAMrB,IAAMC,EACJC,EAAc,CACZC,GAAkBH,CAAE,EACpBI,GAAkBJ,CAAE,CACtB,CAAC,EACE,KACCK,EAAI,CAAC,CAACC,EAAOC,CAAK,IAAMD,GAASC,CAAK,EACtCC,EAAqB,CACvB,EAMEC,EACJC,EAAM,IAAMC,GAAqBX,CAAE,CAAC,EAAE,KACpCY,GAASC,EAAyB,EAClCC,GAAa,CAAC,EAKdC,GAAkBd,CAAO,EACzBI,EAAI,IAAMW,GAAyBhB,CAAE,CAAC,CACxC,EAMF,OAAOC,EAAQ,KACbgB,GAAMC,GAAUA,CAAM,EACtBC,EAAU,IAAMjB,EAAc,CAACD,EAASQ,CAAO,CAAC,CAAC,EACjDJ,EAAI,CAAC,CAACa,EAAQE,CAAM,KAAO,CAAE,OAAAF,EAAQ,OAAAE,CAAO,EAAE,EAC9CC,GAAM,CACR,CACF,CAoBO,SAASC,GACdtB,EAAiBuB,EACe,CAChC,GAAM,CAAE,SAAAC,EAAU,UAAAC,CAAU,EAAIF,EAI1BG,EAAK,cAAc5B,IAAU,GAGnC,OAAOY,EAAM,IAAM,CACjB,IAAMiB,EAAQ,IAAIC,EAMZC,EAAQ,IAAIC,GAAgB,EAAK,EACvCH,EAAM,KAAKI,EAAe,EAAGC,GAAQ,EAAK,CAAC,EACxC,UAAUH,CAAK,EAUlB,IAAMI,EAAQJ,EAAM,KAClBK,GAAShB,GAAUiB,GAAM,CAAC,CAACjB,EAAS,IAAKkB,EAAc,CAAC,EACxD5B,EAAqB,EACrBW,EAAUD,GAAUA,EAASM,EAAWa,CAAK,EAC7CC,EAAIC,GAAQA,EAAK,GAAKb,CAAE,EACxBL,GAAM,CACR,EAIAnB,EAAc,CACZyB,EAAM,KAAKtB,EAAI,CAAC,CAAE,OAAAa,CAAO,IAAMA,CAAM,CAAC,EACtCe,EAAM,KACJd,EAAUoB,GAAQnC,GAAkBmC,EAAM,GAAG,CAAC,EAC9CC,EAAU,EAAK,CACjB,CACF,CAAC,EACE,KAAKnC,EAAIoC,GAAUA,EAAO,KAAKvB,GAAUA,CAAM,CAAC,CAAC,EACjD,UAAUW,CAAK,EAMlB,IAAMa,EAAUb,EAAM,KACpBc,EAAOzB,GAAUA,CAAM,EACvB0B,GAAeX,EAAOR,CAAS,EAC/BpB,EAAI,CAAC,CAACwC,EAAGN,EAAM,CAAE,KAAAO,CAAK,CAAC,IAAM,CAC3B,IAAMC,EAAO/C,EAAG,sBAAsB,EAChCgD,EAAID,EAAK,MAAQ,EAIvB,GAAIR,EAAK,OAAS,UAChB,MAAO,CAAE,EAAAS,EAAG,EAAG,EAAID,EAAK,MAAO,EAI1B,GAAIA,EAAK,GAAKD,EAAK,OAAS,EAAG,CACpC,GAAM,CAAE,OAAAG,CAAO,EAAIC,GAAeX,CAAI,EACtC,MAAO,CAAE,EAAAS,EAAG,EAAG,IAAMC,CAAO,CAC9B,KACE,OAAO,CAAE,EAAAD,EAAG,EAAG,GAAMD,EAAK,MAAO,CAErC,CAAC,CACH,EAIA,OAAA7C,EAAc,CAAC+B,EAAON,EAAOe,CAAO,CAAC,EAClC,UAAU,CAAC,CAACH,EAAM,CAAE,OAAAnB,CAAO,EAAG+B,CAAM,IAAM,CACzCZ,EAAK,MAAM,YAAY,sBAAuB,GAAGnB,EAAO,CAAC,IAAI,EAC7DmB,EAAK,MAAM,YAAY,sBAAuB,GAAGnB,EAAO,CAAC,IAAI,EAI7DmB,EAAK,MAAM,YAAY,iBAAkB,GAAGY,EAAO,CAAC,IAAI,EACxDZ,EAAK,MAAM,YAAY,iBAAkB,GAAGY,EAAO,CAAC,IAAI,EAIxDZ,EAAK,UAAU,OAAO,mBAAuBY,EAAO,EAAK,CAAC,EAC1DZ,EAAK,UAAU,OAAO,sBAAuBY,EAAO,GAAK,CAAC,CAC5D,CAAC,EAIHtB,EAAM,KACJc,EAAOzB,GAAUA,CAAM,EACvB0B,GAAeX,EAAO,CAACY,EAAGN,IAASA,CAAI,EACvCI,EAAOJ,GAAQA,EAAK,OAAS,SAAS,CACxC,EACG,UAAUA,GAAQ,CACjB,IAAMO,EAAOI,GAAeE,EAAW,aAAcb,CAAI,CAAC,EAI1DA,EAAK,MAAM,YAAY,qBAAsB,GAAGO,EAAK,KAAK,IAAI,EAC9DP,EAAK,MAAM,YAAY,oBAAsB,KAAQ,CACvD,CAAC,EAMHV,EAAM,KACJrB,EAAqB,EACrB6C,GAAUC,EAAuB,EACjCV,GAAeX,CAAK,CACtB,EACG,UAAU,CAAC,CAACf,EAAQqB,CAAI,IAAM,CAC7BA,EAAK,UAAU,OAAO,sBAAuBrB,CAAM,CACrD,CAAC,EAGHhB,EAAc,CACZ2B,EAAM,KAAKc,EAAOzB,GAAUA,CAAM,CAAC,EACnCe,CACF,CAAC,EACE,UAAU,CAAC,CAACY,EAAGN,CAAI,IAAM,CACpBA,EAAK,OAAS,UAChBvC,EAAG,aAAa,gBAAiB0B,CAAE,EACnC1B,EAAG,aAAa,gBAAiB,QAAQ,GAEzCA,EAAG,aAAa,mBAAoB0B,CAAE,CAE1C,CAAC,EAGHG,EAAM,KAAKc,EAAOzB,GAAU,CAACA,CAAM,CAAC,EACjC,UAAU,IAAM,CACflB,EAAG,gBAAgB,eAAe,EAClCA,EAAG,gBAAgB,kBAAkB,EACrCA,EAAG,gBAAgB,eAAe,CACpC,CAAC,EAGID,GAAcC,CAAE,EACpB,KACCsC,EAAIiB,GAAS5B,EAAM,KAAK4B,CAAK,CAAC,EAC9BC,EAAS,IAAM7B,EAAM,SAAS,CAAC,EAC/BtB,EAAIkD,GAAUE,EAAA,CAAE,IAAKzD,GAAOuD,EAAQ,CACtC,CACJ,CAAC,CACH,CAeO,SAASG,GACd1D,EAAiB,CAAE,UAAAyB,CAAU,EAC7BkC,EAAY,SAAS,KACW,CAChC,OAAOrC,GAActB,EAAI,CACvB,SAAU,IAAI4D,EAAwBC,GAAY,CAChD,IAAMC,EAAQ9D,EAAG,MACXuC,EAAOwB,GAAqBD,CAAK,EACvC,OAAAD,EAAS,KAAKtB,CAAI,EAClBvC,EAAG,gBAAgB,OAAO,EAE1B2D,EAAU,OAAOpB,CAAI,EACd,IAAM,CACXA,EAAK,OAAO,EACZvC,EAAG,aAAa,QAAS8D,CAAK,CAChC,CACF,CAAC,EACD,UAAArC,CACF,CAAC,CACH,CCjRO,SAASuC,GACdC,EAAiBC,EACO,CACxB,IAAMC,EAAUC,EAAM,IAAMC,EAAc,CACxCC,GAAmBL,CAAE,EACrBM,GAA0BL,CAAS,CACrC,CAAC,CAAC,EACC,KACCM,EAAI,CAAC,CAAC,CAAE,EAAAC,EAAG,EAAAC,CAAE,EAAGC,CAAM,IAAqB,CACzC,GAAM,CAAE,MAAAC,EAAO,OAAAC,CAAO,EAAIC,GAAeb,CAAE,EAC3C,MAAQ,CACN,EAAGQ,EAAIE,EAAO,EAAIC,EAAS,EAC3B,EAAGF,EAAIC,EAAO,EAAIE,EAAS,CAC7B,CACF,CAAC,CACH,EAGF,OAAOE,GAAkBd,CAAE,EACxB,KACCe,EAAUC,GAAUd,EACjB,KACCK,EAAIU,IAAW,CAAE,OAAAD,EAAQ,OAAAC,CAAO,EAAE,EAClCC,GAAK,CAAC,CAACF,GAAU,GAAQ,CAC3B,CACF,CACF,CACJ,CAWO,SAASG,GACdnB,EAAiBC,EAAwB,CAAE,QAAAmB,CAAQ,EAChB,CACnC,GAAM,CAACC,EAASC,CAAK,EAAI,MAAM,KAAKtB,EAAG,QAAQ,EAG/C,OAAOG,EAAM,IAAM,CACjB,IAAMoB,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGC,GAAQ,EAAI,CAAC,EACxD,OAAAJ,EAAM,UAAU,CAGd,KAAK,CAAE,OAAAN,CAAO,EAAG,CACfjB,EAAG,MAAM,YAAY,iBAAkB,GAAGiB,EAAO,CAAC,IAAI,EACtDjB,EAAG,MAAM,YAAY,iBAAkB,GAAGiB,EAAO,CAAC,IAAI,CACxD,EAGA,UAAW,CACTjB,EAAG,MAAM,eAAe,gBAAgB,EACxCA,EAAG,MAAM,eAAe,gBAAgB,CAC1C,CACF,CAAC,EAGD4B,GAAuB5B,CAAE,EACtB,KACC6B,EAAUJ,CAAK,CACjB,EACG,UAAUK,GAAW,CACpB9B,EAAG,gBAAgB,kBAAmB8B,CAAO,CAC/C,CAAC,EAGLC,EACER,EAAM,KAAKS,EAAO,CAAC,CAAE,OAAAhB,CAAO,IAAMA,CAAM,CAAC,EACzCO,EAAM,KAAKU,GAAa,GAAG,EAAGD,EAAO,CAAC,CAAE,OAAAhB,CAAO,IAAM,CAACA,CAAM,CAAC,CAC/D,EACG,UAAU,CAGT,KAAK,CAAE,OAAAA,CAAO,EAAG,CACXA,EACFhB,EAAG,QAAQqB,CAAO,EAElBA,EAAQ,OAAO,CACnB,EAGA,UAAW,CACTrB,EAAG,QAAQqB,CAAO,CACpB,CACF,CAAC,EAGHE,EACG,KACCW,GAAU,GAAIC,EAAuB,CACvC,EACG,UAAU,CAAC,CAAE,OAAAnB,CAAO,IAAM,CACzBK,EAAQ,UAAU,OAAO,qBAAsBL,CAAM,CACvD,CAAC,EAGLO,EACG,KACCa,GAAa,IAAKD,EAAuB,EACzCH,EAAO,IAAM,CAAC,CAAChC,EAAG,YAAY,EAC9BO,EAAI,IAAMP,EAAG,aAAc,sBAAsB,CAAC,EAClDO,EAAI,CAAC,CAAE,EAAAC,CAAE,IAAMA,CAAC,CAClB,EACG,UAAU,CAGT,KAAK6B,EAAQ,CACPA,EACFrC,EAAG,MAAM,YAAY,iBAAkB,GAAG,CAACqC,CAAM,IAAI,EAErDrC,EAAG,MAAM,eAAe,gBAAgB,CAC5C,EAGA,UAAW,CACTA,EAAG,MAAM,eAAe,gBAAgB,CAC1C,CACF,CAAC,EAGLsC,EAAsBhB,EAAO,OAAO,EACjC,KACCO,EAAUJ,CAAK,EACfO,EAAOO,GAAM,EAAEA,EAAG,SAAWA,EAAG,QAAQ,CAC1C,EACG,UAAUA,GAAM,CACfA,EAAG,gBAAgB,EACnBA,EAAG,eAAe,CACpB,CAAC,EAGLD,EAAsBhB,EAAO,WAAW,EACrC,KACCO,EAAUJ,CAAK,EACfe,GAAejB,CAAK,CACtB,EACG,UAAU,CAAC,CAACgB,EAAI,CAAE,OAAAvB,CAAO,CAAC,IAAM,CA3OzC,IAAAyB,EA8OU,GAAIF,EAAG,SAAW,GAAKA,EAAG,SAAWA,EAAG,QACtCA,EAAG,eAAe,UAGTvB,EAAQ,CACjBuB,EAAG,eAAe,EAGlB,IAAMG,EAAS1C,EAAG,cAAe,QAAQ,gBAAgB,EACrD0C,aAAkB,YACpBA,EAAO,MAAM,GAEbD,EAAAE,GAAiB,IAAjB,MAAAF,EAAoB,MACxB,CACF,CAAC,EAGLrB,EACG,KACCS,EAAUJ,CAAK,EACfO,EAAOY,GAAUA,IAAWvB,CAAO,EACnCwB,GAAM,GAAG,CACX,EACG,UAAU,IAAM7C,EAAG,MAAM,CAAC,EAGxBD,GAAgBC,EAAIC,CAAS,EACjC,KACC6C,EAAIC,GAASxB,EAAM,KAAKwB,CAAK,CAAC,EAC9BC,EAAS,IAAMzB,EAAM,SAAS,CAAC,EAC/BhB,EAAIwC,GAAUE,EAAA,CAAE,IAAKjD,GAAO+C,EAAQ,CACtC,CACJ,CAAC,CACH,CCxMA,SAASG,GAAUC,EAAuC,CACxD,OAAOA,EAAU,UAAY,OACzBC,EAAY,eAAgBD,CAAS,EACrC,CAACA,CAAS,CAChB,CASA,SAASE,GAAYF,EAAgC,CACnD,IAAMG,EAAkB,CAAC,EACzB,QAAWC,KAAML,GAAUC,CAAS,EAAG,CACrC,IAAMK,EAAgB,CAAC,EAGjBC,EAAK,SAAS,mBAAmBF,EAAI,WAAW,SAAS,EAC/D,QAASG,EAAOD,EAAG,SAAS,EAAGC,EAAMA,EAAOD,EAAG,SAAS,EACtDD,EAAM,KAAKE,CAAY,EAGzB,QAASC,KAAQH,EAAO,CACtB,IAAII,EAGJ,KAAQA,EAAQ,gBAAgB,KAAKD,EAAK,WAAY,GAAI,CACxD,GAAM,CAAC,CAAEE,EAAIC,CAAK,EAAIF,EACtB,GAAI,OAAOE,GAAU,YAAa,CAChC,IAAMC,EAASJ,EAAK,UAAUC,EAAM,KAAK,EACzCD,EAAOI,EAAO,UAAUF,EAAG,MAAM,EACjCP,EAAQ,KAAKS,CAAM,CAGrB,KAAO,CACLJ,EAAK,YAAcE,EACnBP,EAAQ,KAAKK,CAAI,EACjB,KACF,CACF,CACF,CACF,CACA,OAAOL,CACT,CAQA,SAASU,GAAKC,EAAqBC,EAA2B,CAC5DA,EAAO,OAAO,GAAG,MAAM,KAAKD,EAAO,UAAU,CAAC,CAChD,CAoBO,SAASE,GACdZ,EAAiBJ,EAAwB,CAAE,QAAAiB,EAAS,OAAAC,CAAO,EACxB,CAGnC,IAAMC,EAASnB,EAAU,QAAQ,MAAM,EACjCoB,EAASD,GAAA,YAAAA,EAAQ,GAGjBE,EAAc,IAAI,IACxB,QAAWT,KAAUV,GAAYF,CAAS,EAAG,CAC3C,GAAM,CAAC,CAAEU,CAAE,EAAIE,EAAO,YAAa,MAAM,WAAW,EAChDU,GAAmB,yBAAyBZ,CAAE,IAAKN,CAAE,IACvDiB,EAAY,IAAIX,EAAIa,GAAiBb,EAAIU,CAAM,CAAC,EAChDR,EAAO,YAAYS,EAAY,IAAIX,CAAE,CAAE,EAE3C,CAGA,OAAIW,EAAY,OAAS,EAChBG,EAGFC,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGC,GAAQ,EAAI,CAAC,EAGlDC,EAAsC,CAAC,EAC7C,OAAW,CAACrB,EAAIsB,CAAU,IAAKX,EAC7BU,EAAM,KAAK,CACTE,EAAW,cAAeD,CAAU,EACpCC,EAAW,yBAAyBvB,CAAE,IAAKN,CAAE,CAC/C,CAAC,EAGH,OAAAc,EAAO,KAAKgB,EAAUN,CAAK,CAAC,EACzB,UAAUO,GAAU,CACnB/B,EAAG,OAAS,CAAC+B,EAGb/B,EAAG,UAAU,OAAO,qBAAsB+B,CAAM,EAGhD,OAAW,CAACC,EAAOC,CAAK,IAAKN,EACtBI,EAGHtB,GAAKuB,EAAOC,CAAK,EAFjBxB,GAAKwB,EAAOD,CAAK,CAGvB,CAAC,EAGIE,EAAM,GAAG,CAAC,GAAGjB,CAAW,EAC5B,IAAI,CAAC,CAAC,CAAEW,CAAU,IACjBO,GAAgBP,EAAYhC,EAAW,CAAE,QAAAiB,CAAQ,CAAC,CACnD,CACH,EACG,KACCuB,EAAS,IAAMd,EAAM,SAAS,CAAC,EAC/Be,GAAM,CACR,CACJ,CAAC,CACH,CC7JA,SAASC,GAASC,EAA0C,CAC1D,GAAIA,EAAG,mBAAoB,CACzB,IAAMC,EAAUD,EAAG,mBACnB,GAAIC,EAAQ,UAAY,KACtB,OAAOA,EAGJ,GAAIA,EAAQ,UAAY,KAAO,CAACA,EAAQ,SAAS,OACpD,OAAOF,GAASE,CAAO,CAC3B,CAIF,CAcO,SAASC,GACdF,EAAiBG,EACkB,CACnC,OAAOC,EAAM,IAAM,CACjB,IAAMC,EAAON,GAASC,CAAE,EACxB,OAAO,OAAOK,GAAS,YACnBC,GAAoBD,EAAML,EAAIG,CAAO,EACrCI,CACN,CAAC,CACH,CCjEA,IAAAC,GAAwB,SA4ExB,IAAIC,GAAW,EAaf,SAASC,GAAkBC,EAA0C,CACnE,GAAIA,EAAG,mBAAoB,CACzB,IAAMC,EAAUD,EAAG,mBACnB,GAAIC,EAAQ,UAAY,KACtB,OAAOA,EAGJ,GAAIA,EAAQ,UAAY,KAAO,CAACA,EAAQ,SAAS,OACpD,OAAOF,GAAkBE,CAAO,CACpC,CAIF,CAgBO,SAASC,GACdF,EACsB,CACtB,OAAOG,GAAiBH,CAAE,EACvB,KACCI,EAAI,CAAC,CAAE,MAAAC,CAAM,KAEJ,CACL,WAFcC,GAAsBN,CAAE,EAElB,MAAQK,CAC9B,EACD,EACDE,GAAwB,YAAY,CACtC,CACJ,CAoBO,SAASC,GACdR,EAAiBS,EACiB,CAClC,GAAM,CAAE,QAASC,CAAM,EAAI,WAAW,SAAS,EAGzCC,EAAWC,EAAM,IAAM,CAC3B,IAAMC,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,GAAS,CAAC,CAAC,EACpCH,EAAM,UAAU,CAAC,CAAE,WAAAI,CAAW,IAAM,CAC9BA,GAAcP,EAChBV,EAAG,aAAa,WAAY,GAAG,EAE/BA,EAAG,gBAAgB,UAAU,CACjC,CAAC,EAGD,IAAMkB,EAAoD,CAAC,EAC3D,GAAI,GAAAC,QAAY,YAAY,IACtBnB,EAAG,QAAQ,OAAO,GACpBoB,EAAQ,mBAAmB,GAAK,CAACpB,EAAG,QAAQ,UAAU,GACrD,CACD,IAAMqB,EAASrB,EAAG,QAAQ,KAAK,EAC/BqB,EAAO,GAAK,UAAUvB,IAAU,GAGhC,IAAMwB,EAASC,GAAsBF,EAAO,EAAE,EAC9CA,EAAO,aAAaC,EAAQtB,CAAE,EAC1BoB,EAAQ,kBAAkB,GAC5BF,EAAS,KAAKM,GAAoBF,EAAQ,CAAE,SAAU,CAAC,CAAC,CAC5D,CAIF,IAAMG,EAAYzB,EAAG,QAAQ,YAAY,EACzC,GAAIyB,aAAqB,YAAa,CACpC,IAAMC,EAAO3B,GAAkB0B,CAAS,EAGxC,GAAI,OAAOC,GAAS,cAClBD,EAAU,UAAU,SAAS,UAAU,GACvCL,EAAQ,uBAAuB,GAC9B,CACD,IAAMO,EAAeC,GAAoBF,EAAM1B,EAAIS,CAAO,EAC1DS,EAAS,KACPf,GAAiBsB,CAAS,EACvB,KACCI,EAAUd,CAAK,EACfX,EAAI,CAAC,CAAE,MAAAC,EAAO,OAAAyB,CAAO,IAAMzB,GAASyB,CAAM,EAC1CC,EAAqB,EACrBC,EAAUC,GAAUA,EAASN,EAAeO,CAAK,CACnD,CACJ,CACF,CACF,CAOA,OADcC,EAAY,oBAAqBnC,CAAE,EACvC,QACRA,EAAG,UAAU,IAAI,kBAAkB,EAG9BE,GAAeF,CAAE,EACrB,KACCoC,EAAIC,GAASxB,EAAM,KAAKwB,CAAK,CAAC,EAC9BC,EAAS,IAAMzB,EAAM,SAAS,CAAC,EAC/BT,EAAIiC,GAAUE,EAAA,CAAE,IAAKvC,GAAOqC,EAAQ,EACpCG,GAAU,GAAGtB,CAAQ,CACvB,CACJ,CAAC,EAGD,OAAIE,EAAQ,cAAc,EACjBqB,GAAuBzC,CAAE,EAC7B,KACC0C,EAAOC,GAAWA,CAAO,EACzBC,GAAK,CAAC,EACNZ,EAAU,IAAMrB,CAAQ,CAC1B,EAGGA,CACT,CCnLO,SAASkC,GACdC,EAAwB,CAAE,QAAAC,EAAS,OAAAC,CAAO,EACrB,CACrB,IAAIC,EAAO,GACX,OAAOC,EAGLH,EACG,KACCI,EAAIC,GAAUA,EAAO,QAAQ,qBAAqB,CAAE,EACpDC,EAAOC,GAAWR,IAAOQ,CAAO,EAChCH,EAAI,KAAO,CACT,OAAQ,OAAQ,OAAQ,EAC1B,EAAa,CACf,EAGFH,EACG,KACCK,EAAOE,GAAUA,GAAU,CAACN,CAAI,EAChCO,EAAI,IAAMP,EAAOH,EAAG,IAAI,EACxBK,EAAII,IAAW,CACb,OAAQA,EAAS,OAAS,OAC5B,EAAa,CACf,CACJ,CACF,CAaO,SAASE,GACdX,EAAwBY,EACQ,CAChC,OAAOC,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAU,CAAC,CAAE,OAAAE,EAAQ,OAAAC,CAAO,IAAM,CACtCjB,EAAG,gBAAgB,OAAQgB,IAAW,MAAM,EACxCC,GACFjB,EAAG,eAAe,CACtB,CAAC,EAGMD,GAAaC,EAAIY,CAAO,EAC5B,KACCF,EAAIQ,GAASJ,EAAM,KAAKI,CAAK,CAAC,EAC9BC,EAAS,IAAML,EAAM,SAAS,CAAC,EAC/BT,EAAIa,GAAUE,EAAA,CAAE,IAAKpB,GAAOkB,EAAQ,CACtC,CACJ,CAAC,CACH,CCzIA,IAAAG,GAAA,iiMCqDA,IAAIC,GAKAC,GAAW,EAWf,SAASC,IAAiC,CACxC,OAAO,OAAO,SAAY,aAAe,mBAAmB,QACxDC,GAAY,kDAAkD,EAC9DC,EAAG,MAAS,CAClB,CAaO,SAASC,GACdC,EACgC,CAChC,OAAAA,EAAG,UAAU,OAAO,SAAS,EAC7BN,QAAaE,GAAa,EACvB,KACCK,EAAI,IAAM,QAAQ,WAAW,CAC3B,YAAa,GACb,SAAAC,GACA,SAAU,CACR,cAAe,OACf,gBAAiB,OACjB,aAAc,MAChB,CACF,CAAC,CAAC,EACFC,EAAI,IAAG,EAAY,EACnBC,EAAY,CAAC,CACf,GAGFV,GAAS,UAAU,IAAYW,GAAA,sBAC7BL,EAAG,UAAU,IAAI,SAAS,EAC1B,IAAMM,EAAK,aAAaX,IAAU,GAG5BY,EAAOC,EAAE,MAAO,CAAE,MAAO,SAAU,CAAC,EACpCC,EAAOT,EAAG,YAGV,CAAE,IAAAU,EAAK,GAAAC,CAAG,EAAI,MAAM,QAAQ,OAAOL,EAAIG,CAAI,EAG3CG,EAASL,EAAK,aAAa,CAAE,KAAM,QAAS,CAAC,EACnDK,EAAO,UAAYF,EAGnBV,EAAG,YAAYO,CAAI,EACnBI,GAAA,MAAAA,EAAKC,EACP,EAAC,EAGMlB,GACJ,KACCS,EAAI,KAAO,CAAE,IAAKH,CAAG,EAAE,CACzB,CACJ,CCtFA,IAAMa,GAAWC,EAAE,OAAO,EAgBnB,SAASC,GACdC,EACkC,CAClC,OAAAA,EAAG,YAAYH,EAAQ,EACvBA,GAAS,YAAYI,GAAYD,CAAE,CAAC,EAG7BE,EAAG,CAAE,IAAKF,CAAG,CAAC,CACvB,CC4BO,SAASG,GACdC,EACyB,CACzB,IAAMC,EAAUD,EAAO,KAAKE,GAASA,EAAM,OAAO,GAAKF,EAAO,CAAC,EAC/D,OAAOG,EAAM,GAAGH,EAAO,IAAIE,GAASE,EAAUF,EAAO,QAAQ,EAC1D,KACCG,EAAI,IAAMC,EAA6B,cAAcJ,EAAM,EAAE,IAAI,CAAC,CACpE,CACF,CAAC,EACE,KACCK,EAAUD,EAA6B,cAAcL,EAAQ,EAAE,IAAI,CAAC,EACpEI,EAAIG,IAAW,CAAE,OAAAA,CAAO,EAAE,CAC5B,CACJ,CAUO,SAASC,GACdC,EAAiB,CAAE,UAAAC,EAAW,QAAAC,CAAQ,EACF,CACpC,IAAMC,EAAYP,EAAW,iBAAkBI,CAAE,EAC3CV,EAASc,EAA8B,iBAAkBJ,CAAE,EAG3DK,EAAOC,GAAoB,MAAM,EACvCN,EAAG,OAAOK,CAAI,EAGd,IAAME,EAAOD,GAAoB,MAAM,EACvC,OAAAN,EAAG,OAAOO,CAAI,EAGPC,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGC,GAAQ,EAAI,CAAC,EACxDC,EAAc,CAACL,EAAOM,GAAiBf,CAAE,EAAGgB,GAAuBhB,CAAE,CAAC,CAAC,EACpE,KACCiB,EAAUN,CAAK,EACfO,GAAU,EAAGC,EAAuB,CACtC,EACG,UAAU,CAGT,KAAK,CAAC,CAAE,OAAArB,CAAO,EAAGsB,CAAI,EAAG,CACvB,IAAMC,EAASC,GAAiBxB,CAAM,EAChC,CAAE,MAAAyB,CAAM,EAAIC,GAAe1B,CAAM,EAGvCE,EAAG,MAAM,YAAY,mBAAoB,GAAGqB,EAAO,CAAC,IAAI,EACxDrB,EAAG,MAAM,YAAY,uBAAwB,GAAGuB,CAAK,IAAI,EAGzD,IAAME,EAAUC,GAAwBvB,CAAS,GAE/CkB,EAAO,EAAYI,EAAQ,GAC3BJ,EAAO,EAAIE,EAAQE,EAAQ,EAAIL,EAAK,QAEpCjB,EAAU,SAAS,CACjB,KAAM,KAAK,IAAI,EAAGkB,EAAO,EAAI,EAAE,EAC/B,SAAU,QACZ,CAAC,CACL,EAGA,UAAW,CACTrB,EAAG,MAAM,eAAe,kBAAkB,EAC1CA,EAAG,MAAM,eAAe,sBAAsB,CAChD,CACF,CAAC,EAGLc,EAAc,CACZa,GAA0BxB,CAAS,EACnCY,GAAiBZ,CAAS,CAC5B,CAAC,EACE,KACCc,EAAUN,CAAK,CACjB,EACG,UAAU,CAAC,CAACU,EAAQD,CAAI,IAAM,CAC7B,IAAMK,EAAUG,GAAsBzB,CAAS,EAC/CE,EAAK,OAASgB,EAAO,EAAI,GACzBd,EAAK,OAASc,EAAO,EAAII,EAAQ,MAAQL,EAAK,MAAQ,EACxD,CAAC,EAGL3B,EACEC,EAAUW,EAAM,OAAO,EAAE,KAAKV,EAAI,IAAM,EAAE,CAAC,EAC3CD,EAAUa,EAAM,OAAO,EAAE,KAAKZ,EAAI,IAAM,CAAE,CAAC,CAC7C,EACG,KACCsB,EAAUN,CAAK,CACjB,EACG,UAAUkB,GAAa,CACtB,GAAM,CAAE,MAAAN,CAAM,EAAIC,GAAerB,CAAS,EAC1CA,EAAU,SAAS,CACjB,KAAMoB,EAAQM,EACd,SAAU,QACZ,CAAC,CACH,CAAC,EAGL3B,EACG,KACCe,EAAUN,CAAK,EACfmB,EAAOtC,GAASF,EAAO,SAASE,CAAyB,CAAC,CAC5D,EACG,UAAUA,GAASA,EAAM,MAAM,CAAC,EAGrCW,EAAU,UAAU,IAAI,uBAAuB,EAC/C,QAAWX,KAASF,EAAQ,CAC1B,IAAMyC,EAAQnC,EAA6B,cAAcJ,EAAM,EAAE,IAAI,EACrEuC,EAAM,gBAAgBC,EAAE,IAAK,CAC3B,KAAM,IAAID,EAAM,OAAO,GACvB,SAAU,EACZ,EAAG,GAAG,MAAM,KAAKA,EAAM,UAAU,CAAC,CAAC,EAGnCrC,EAAsBqC,EAAM,kBAAoB,OAAO,EACpD,KACCd,EAAUN,CAAK,EACfmB,EAAOG,GAAM,EAAEA,EAAG,SAAWA,EAAG,QAAQ,EACxCC,EAAID,GAAM,CACRA,EAAG,eAAe,EAClBA,EAAG,gBAAgB,CACrB,CAAC,CACH,EAEG,UAAU,IAAM,CACf,QAAQ,aAAa,CAAC,EAAG,GAAI,IAAIF,EAAM,OAAO,EAAE,EAChDA,EAAM,MAAM,CACd,CAAC,CACP,CAGA,OAAII,EAAQ,mBAAmB,GAC7B1B,EAAM,KACJ2B,GAAK,CAAC,EACNC,GAAepC,CAAS,CAC1B,EACG,UAAU,CAAC,CAAC,CAAE,OAAAH,CAAO,EAAG,CAAE,OAAAuB,CAAO,CAAC,IAAM,CACvC,IAAMiB,EAAMxC,EAAO,UAAU,KAAK,EAClC,GAAIA,EAAO,aAAa,mBAAmB,EACzCA,EAAO,gBAAgB,mBAAmB,MAGrC,CACL,IAAMyC,EAAIvC,EAAG,UAAYqB,EAAO,EAGhC,QAAWmB,KAAOpC,EAAY,aAAa,EACzC,QAAWZ,KAASY,EAClB,iBAAkBoC,CACpB,EAAG,CACD,IAAMT,EAAQnC,EAAW,cAAcJ,EAAM,EAAE,IAAI,EACnD,GACEuC,IAAUjC,GACViC,EAAM,UAAU,KAAK,IAAMO,EAC3B,CACAP,EAAM,aAAa,oBAAqB,EAAE,EAC1CvC,EAAM,MAAM,EACZ,KACF,CACF,CAGF,OAAO,SAAS,CACd,IAAKQ,EAAG,UAAYuC,CACtB,CAAC,EAGD,IAAME,EAAO,SAAmB,QAAQ,GAAK,CAAC,EAC9C,SAAS,SAAU,CAAC,GAAG,IAAI,IAAI,CAACH,EAAK,GAAGG,CAAI,CAAC,CAAC,CAAC,CACjD,CACF,CAAC,EAGLhC,EAAM,KAAKQ,EAAUN,CAAK,CAAC,EACxB,UAAU,IAAM,CACf,QAAW+B,KAAStC,EAA8B,eAAgBJ,CAAE,EAClE0C,EAAM,MAAM,CAChB,CAAC,EAGIrD,GAAiBC,CAAM,EAC3B,KACC4C,EAAIS,GAASlC,EAAM,KAAKkC,CAAK,CAAC,EAC9BC,EAAS,IAAMnC,EAAM,SAAS,CAAC,EAC/Bd,EAAIgD,GAAUE,EAAA,CAAE,IAAK7C,GAAO2C,EAAQ,CACtC,CACJ,CAAC,EACE,KACCG,GAAYC,EAAc,CAC5B,CACJ,CCpMO,SAASC,GACdC,EAAiB,CAAE,UAAAC,EAAW,QAAAC,EAAS,OAAAC,CAAO,EACd,CAChC,OAAOC,EAGL,GAAGC,EAAY,4BAA6BL,CAAE,EAC3C,IAAIM,GAASC,GAAqBD,EAAO,CAAE,QAAAJ,EAAS,OAAAC,CAAO,CAAC,CAAC,EAGhE,GAAGE,EAAY,2BAA4BL,CAAE,EAC1C,IAAIM,GAASE,GAAeF,EAAO,CAAE,QAAAJ,EAAS,OAAAC,CAAO,CAAC,CAAC,EAG1D,GAAGE,EAAY,cAAeL,CAAE,EAC7B,IAAIM,GAASG,GAAaH,CAAK,CAAC,EAGnC,GAAGD,EAAY,qBAAsBL,CAAE,EACpC,IAAIM,GAASI,GAAeJ,CAAK,CAAC,EAGrC,GAAGD,EAAY,UAAWL,CAAE,EACzB,IAAIM,GAASK,GAAaL,EAAO,CAAE,QAAAJ,EAAS,OAAAC,CAAO,CAAC,CAAC,EAGxD,GAAGE,EAAY,cAAeL,CAAE,EAC7B,IAAIM,GAASM,GAAiBN,EAAO,CAAE,UAAAL,EAAW,QAAAC,CAAQ,CAAC,CAAC,EAG/D,GAAGG,EAAY,UAAWL,CAAE,EACzB,OAAO,IAAMa,EAAQ,kBAAkB,CAAC,EACxC,IAAIP,GAASQ,GAAoBR,EAAO,CAAE,UAAAL,CAAU,CAAC,CAAC,CAC3D,CACF,CCtDO,SAASc,GACdC,EAAkB,CAAE,OAAAC,CAAO,EACP,CACpB,OAAOA,EACJ,KACCC,EAAUC,GAAWC,EACnBC,EAAG,EAAI,EACPA,EAAG,EAAK,EAAE,KAAKC,GAAM,GAAI,CAAC,CAC5B,EACG,KACCC,EAAIC,IAAW,CAAE,QAAAL,EAAS,OAAAK,CAAO,EAAE,CACrC,CACF,CACF,CACJ,CAaO,SAASC,GACdC,EAAiBC,EACc,CAC/B,IAAMC,EAAQC,EAAW,cAAeH,CAAE,EAC1C,OAAOI,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAU,CAAC,CAAE,QAAAZ,EAAS,OAAAK,CAAO,IAAM,CACvCE,EAAG,UAAU,OAAO,oBAAqBF,CAAM,EAC/CI,EAAM,YAAcT,CACtB,CAAC,EAGMJ,GAAYW,EAAIC,CAAO,EAC3B,KACCM,EAAIC,GAASH,EAAM,KAAKG,CAAK,CAAC,EAC9BC,EAAS,IAAMJ,EAAM,SAAS,CAAC,EAC/BR,EAAIW,GAAUE,EAAA,CAAE,IAAKV,GAAOQ,EAAQ,CACtC,CACJ,CAAC,CACH,CCnDA,IAAIG,GAAW,EAiBR,SAASC,GACdC,EAAiBC,EACI,CACrB,SAAS,KAAK,OAAOD,CAAE,EAGvB,GAAM,CAAE,MAAAE,CAAM,EAAIC,GAAeH,CAAE,EACnCA,EAAG,MAAM,YAAY,qBAAsB,GAAGE,CAAK,IAAI,EACvDF,EAAG,OAAO,EAGV,IAAMI,EAAYC,GAAoBJ,CAAI,EACpCK,EACJ,OAAOF,GAAc,YACjBG,GAA0BH,CAAS,EACnCI,EAAG,CAAE,EAAG,EAAG,EAAG,CAAE,CAAC,EAGjBC,EAAUC,EACdC,GAAkBV,CAAI,EACtBW,GAAkBX,CAAI,CACxB,EACG,KACCY,EAAqB,CACvB,EAGF,OAAOC,EAAc,CAACL,EAASH,CAAO,CAAC,EACpC,KACCS,EAAI,CAAC,CAACC,EAAQC,CAAM,IAAM,CACxB,GAAI,CAAE,EAAAC,EAAG,EAAAC,CAAE,EAAIC,GAAiBnB,CAAI,EAC9BoB,EAAOlB,GAAeF,CAAI,EAU1BqB,EAAQrB,EAAK,QAAQ,OAAO,EAClC,OAAIqB,GAASrB,EAAK,gBAChBiB,GAAKI,EAAM,WAAarB,EAAK,cAAc,WAC3CkB,GAAKG,EAAM,UAAarB,EAAK,cAAc,WAEtC,CACL,OAAAe,EACA,OAAQ,CACN,EAAGE,EAAID,EAAO,EAAII,EAAK,MAAS,EAAInB,EAAQ,EAC5C,EAAGiB,EAAIF,EAAO,EAAII,EAAK,OAAS,CAClC,CACF,CACF,CAAC,CACH,CACJ,CASO,SAASE,GACdvB,EACgC,CAChC,IAAMwB,EAAQxB,EAAG,MACjB,GAAI,CAACwB,EAAM,OACT,OAAOC,EAGT,IAAMC,EAAK,aAAa5B,IAAU,GAC5B6B,EAAUC,GAAcF,EAAI,QAAQ,EACpCG,EAAUC,EAAW,cAAeH,CAAO,EACjD,OAAAE,EAAQ,UAAYL,EAGbO,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAU,CAGd,KAAK,CAAE,OAAAE,CAAO,EAAG,CACfP,EAAQ,MAAM,YAAY,iBAAkB,GAAGO,EAAO,CAAC,IAAI,EAC3DP,EAAQ,MAAM,YAAY,iBAAkB,GAAGO,EAAO,CAAC,IAAI,CAC7D,EAGA,UAAW,CACTP,EAAQ,MAAM,eAAe,gBAAgB,EAC7CA,EAAQ,MAAM,eAAe,gBAAgB,CAC/C,CACF,CAAC,EAGDjB,EACEsB,EAAM,KAAKG,EAAO,CAAC,CAAE,OAAAnB,CAAO,IAAMA,CAAM,CAAC,EACzCgB,EAAM,KAAKI,GAAa,GAAG,EAAGD,EAAO,CAAC,CAAE,OAAAnB,CAAO,IAAM,CAACA,CAAM,CAAC,CAC/D,EACG,UAAU,CAGT,KAAK,CAAE,OAAAA,CAAO,EAAG,CACXA,GACFhB,EAAG,sBAAsB,WAAY2B,CAAO,EAC5C3B,EAAG,aAAa,mBAAoB0B,CAAE,EACtC1B,EAAG,gBAAgB,OAAO,IAE1B2B,EAAQ,OAAO,EACf3B,EAAG,gBAAgB,kBAAkB,EACrCA,EAAG,aAAa,QAASwB,CAAK,EAElC,EAGA,UAAW,CACTG,EAAQ,OAAO,EACf3B,EAAG,gBAAgB,kBAAkB,EACrCA,EAAG,aAAa,QAASwB,CAAK,CAChC,CACF,CAAC,EAGHQ,EACG,KACCK,GAAU,GAAIC,EAAuB,CACvC,EACG,UAAU,CAAC,CAAE,OAAAtB,CAAO,IAAM,CACzBW,EAAQ,UAAU,OAAO,qBAAsBX,CAAM,CACvD,CAAC,EAMLgB,EACG,KACCO,GAAa,IAAKD,EAAuB,EACzCH,EAAO,IAAM,CAAC,CAACnC,EAAG,YAAY,EAC9Be,EAAI,IAAMf,EAAG,aAAc,sBAAsB,CAAC,EAClDe,EAAI,CAAC,CAAE,EAAAG,CAAE,IAAMA,CAAC,CAClB,EACC,UAAU,CAGT,KAAKsB,EAAQ,CACPA,EACFb,EAAQ,MAAM,YAAY,iBAAkB,GAAG,CAACa,CAAM,IAAI,EAE1Db,EAAQ,MAAM,eAAe,gBAAgB,CACjD,EAGA,UAAW,CACTA,EAAQ,MAAM,eAAe,gBAAgB,CAC/C,CACF,CAAC,EAGI5B,GAAa4B,EAAS3B,CAAE,EAC5B,KACCyC,EAAIC,GAASV,EAAM,KAAKU,CAAK,CAAC,EAC9BC,EAAS,IAAMX,EAAM,SAAS,CAAC,EAC/BjB,EAAI2B,GAAUE,EAAA,CAAE,IAAK5C,GAAO0C,EAAQ,CACtC,CACJ,CAAC,EACE,KACCG,GAAYC,EAAc,CAC5B,CACJ,CC7JA,SAASC,GAAS,CAAE,UAAAC,CAAU,EAAsC,CAClE,GAAI,CAACC,EAAQ,iBAAiB,EAC5B,OAAOC,EAAG,EAAK,EAGjB,IAAMC,EAAaH,EAChB,KACCI,EAAI,CAAC,CAAE,OAAQ,CAAE,EAAAC,CAAE,CAAE,IAAMA,CAAC,EAC5BC,GAAY,EAAG,CAAC,EAChBF,EAAI,CAAC,CAACG,EAAGC,CAAC,IAAM,CAACD,EAAIC,EAAGA,CAAC,CAAU,EACnCC,GAAwB,CAAC,CAC3B,EAGIC,EAAUC,EAAc,CAACX,EAAWG,CAAU,CAAC,EAClD,KACCS,EAAO,CAAC,CAAC,CAAE,OAAAC,CAAO,EAAG,CAAC,CAAER,CAAC,CAAC,IAAM,KAAK,IAAIA,EAAIQ,EAAO,CAAC,EAAI,GAAG,EAC5DT,EAAI,CAAC,CAAC,CAAE,CAACU,CAAS,CAAC,IAAMA,CAAS,EAClCC,EAAqB,CACvB,EAGIC,EAAUC,GAAY,QAAQ,EACpC,OAAON,EAAc,CAACX,EAAWgB,CAAO,CAAC,EACtC,KACCZ,EAAI,CAAC,CAAC,CAAE,OAAAS,CAAO,EAAGK,CAAM,IAAML,EAAO,EAAI,KAAO,CAACK,CAAM,EACvDH,EAAqB,EACrBI,EAAUC,GAAUA,EAASV,EAAUR,EAAG,EAAK,CAAC,EAChDmB,EAAU,EAAK,CACjB,CACJ,CAcO,SAASC,GACdC,EAAiBC,EACG,CACpB,OAAOC,EAAM,IAAMd,EAAc,CAC/Be,GAAiBH,CAAE,EACnBxB,GAASyB,CAAO,CAClB,CAAC,CAAC,EACC,KACCpB,EAAI,CAAC,CAAC,CAAE,OAAAuB,CAAO,EAAGC,CAAM,KAAO,CAC7B,OAAAD,EACA,OAAAC,CACF,EAAE,EACFb,EAAqB,CAACR,EAAGC,IACvBD,EAAE,SAAWC,EAAE,QACfD,EAAE,SAAWC,EAAE,MAChB,EACDqB,EAAY,CAAC,CACf,CACJ,CAaO,SAASC,GACdP,EAAiB,CAAE,QAAAQ,EAAS,MAAAC,CAAM,EACO,CACzC,OAAOP,EAAM,IAAM,CACjB,IAAMQ,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGC,GAAQ,EAAI,CAAC,EACxDJ,EACG,KACCxB,GAAwB,QAAQ,EAChC6B,GAAkBP,CAAO,CAC3B,EACG,UAAU,CAAC,CAAC,CAAE,OAAAX,CAAO,EAAG,CAAE,OAAAQ,CAAO,CAAC,IAAM,CACvCL,EAAG,UAAU,OAAO,oBAAqBH,GAAU,CAACQ,CAAM,EAC1DL,EAAG,OAASK,CACd,CAAC,EAGL,IAAMW,EAAWC,GAAKC,EAAY,UAAWlB,CAAE,CAAC,EAC7C,KACCX,EAAO,IAAMX,EAAQ,kBAAkB,CAAC,EACxCyC,GAASC,GAASC,GAAaD,CAAK,CAAC,CACvC,EAGF,OAAAX,EAAM,UAAUC,CAAK,EAGdF,EACJ,KACCc,EAAUV,CAAK,EACf/B,EAAI0C,GAAUC,EAAA,CAAE,IAAKxB,GAAOuB,EAAQ,EACpCE,GAAUT,EAAS,KAAKM,EAAUV,CAAK,CAAC,CAAC,CAC3C,CACJ,CAAC,CACH,CCjIO,SAASc,GACdC,EAAiB,CAAE,UAAAC,EAAW,QAAAC,CAAQ,EACb,CACzB,OAAOC,GAAgBH,EAAI,CAAE,UAAAC,EAAW,QAAAC,CAAQ,CAAC,EAC9C,KACCE,EAAI,CAAC,CAAE,OAAQ,CAAE,EAAAC,CAAE,CAAE,IAAM,CACzB,GAAM,CAAE,OAAAC,CAAO,EAAIC,GAAeP,CAAE,EACpC,MAAO,CACL,OAAQK,GAAKC,CACf,CACF,CAAC,EACDE,GAAwB,QAAQ,CAClC,CACJ,CAaO,SAASC,GACdT,EAAiBU,EACmB,CACpC,OAAOC,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EAClBD,EAAM,UAAU,CAGd,KAAK,CAAE,OAAAE,CAAO,EAAG,CACfd,EAAG,UAAU,OAAO,2BAA4Bc,CAAM,CACxD,EAGA,UAAW,CACTd,EAAG,UAAU,OAAO,0BAA0B,CAChD,CACF,CAAC,EAGD,IAAMe,EAAUC,GAAmB,gBAAgB,EACnD,OAAI,OAAOD,GAAY,YACdE,EAGFlB,GAAiBgB,EAASL,CAAO,EACrC,KACCQ,EAAIC,GAASP,EAAM,KAAKO,CAAK,CAAC,EAC9BC,EAAS,IAAMR,EAAM,SAAS,CAAC,EAC/BR,EAAIe,GAAUE,EAAA,CAAE,IAAKrB,GAAOmB,EAAQ,CACtC,CACJ,CAAC,CACH,CChEO,SAASG,GACdC,EAAiB,CAAE,UAAAC,EAAW,QAAAC,CAAQ,EACpB,CAGlB,IAAMC,EAAUD,EACb,KACCE,EAAI,CAAC,CAAE,OAAAC,CAAO,IAAMA,CAAM,EAC1BC,EAAqB,CACvB,EAGIC,EAAUJ,EACb,KACCK,EAAU,IAAMC,GAAiBT,CAAE,EAChC,KACCI,EAAI,CAAC,CAAE,OAAAC,CAAO,KAAO,CACnB,IAAQL,EAAG,UACX,OAAQA,EAAG,UAAYK,CACzB,EAAE,EACFK,GAAwB,QAAQ,CAClC,CACF,CACF,EAGF,OAAOC,EAAc,CAACR,EAASI,EAASN,CAAS,CAAC,EAC/C,KACCG,EAAI,CAAC,CAACQ,EAAQ,CAAE,IAAAC,EAAK,OAAAC,CAAO,EAAG,CAAE,OAAQ,CAAE,EAAAC,CAAE,EAAG,KAAM,CAAE,OAAAV,CAAO,CAAE,CAAC,KAChEA,EAAS,KAAK,IAAI,EAAGA,EACjB,KAAK,IAAI,EAAGQ,EAASE,EAAIH,CAAM,EAC/B,KAAK,IAAI,EAAGP,EAASU,EAAID,CAAM,CACnC,EACO,CACL,OAAQD,EAAMD,EACd,OAAAP,EACA,OAAQQ,EAAMD,GAAUG,CAC1B,EACD,EACDT,EAAqB,CAACU,EAAGC,IACvBD,EAAE,SAAWC,EAAE,QACfD,EAAE,SAAWC,EAAE,QACfD,EAAE,SAAWC,EAAE,MAChB,CACH,CACJ,CCxCO,SAASC,GACdC,EACqB,CACrB,IAAMC,EAAU,SAAkB,WAAW,GAAK,CAChD,MAAOD,EAAO,UAAUE,GAAS,WAC/BA,EAAM,aAAa,qBAAqB,CAC1C,EAAE,OAAO,CACX,EAGMC,EAAQ,KAAK,IAAI,EAAG,KAAK,IAAIF,EAAQ,MAAOD,EAAO,OAAS,CAAC,CAAC,EACpE,OAAOI,EAAG,GAAGJ,CAAM,EAChB,KACCK,GAASH,GAASI,EAAUJ,EAAO,QAAQ,EAAE,KAAKK,EAAI,IAAML,CAAK,CAAC,CAAC,EACnEM,EAAUR,EAAOG,CAAK,CAAC,EACvBI,EAAIL,IAAU,CACZ,MAAOF,EAAO,QAAQE,CAAK,EAC3B,MAAO,CACL,MAASA,EAAM,aAAa,qBAAqB,EACjD,OAASA,EAAM,aAAa,sBAAsB,EAClD,QAASA,EAAM,aAAa,uBAAuB,EACnD,OAASA,EAAM,aAAa,sBAAsB,CACpD,CACF,EAAa,EACbO,EAAY,CAAC,CACf,CACJ,CASO,SAASC,GACdC,EACgC,CAChC,IAAMX,EAASY,EAA8B,QAASD,CAAE,EAClDE,EAAOC,EAAE,OAAQ,CAAE,KAAM,aAAc,CAAC,EAC9C,SAAS,KAAK,YAAYD,CAAI,EAG9B,IAAME,EAASD,EAAE,OAAQ,CAAE,KAAM,cAAe,CAAC,EACjD,SAAS,KAAK,YAAYC,CAAM,EAGhC,IAAMC,EAASC,GAAW,+BAA+B,EACzD,OAAOC,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAUE,GAAW,CAIzB,GAHA,SAAS,KAAK,aAAa,0BAA2B,EAAE,EAGpDA,EAAQ,MAAM,QAAU,yBAA0B,CACpD,IAAMC,EAAQ,WAAW,+BAA+B,EAClDpB,EAAQ,SAAS,cAAcoB,EAAM,QACvC,wDACA,sDACJ,EAGAD,EAAQ,MAAM,OAAUnB,EAAM,aAAa,sBAAsB,EACjEmB,EAAQ,MAAM,QAAUnB,EAAM,aAAa,uBAAuB,EAClEmB,EAAQ,MAAM,OAAUnB,EAAM,aAAa,sBAAsB,CACnE,CAGA,OAAW,CAACqB,EAAKC,CAAK,IAAK,OAAO,QAAQH,EAAQ,KAAK,EACrD,SAAS,KAAK,aAAa,iBAAiBE,CAAG,GAAIC,CAAK,EAG1D,QAASrB,EAAQ,EAAGA,EAAQH,EAAO,OAAQG,IAAS,CAClD,IAAMsB,EAAQzB,EAAOG,CAAK,EAAE,mBACxBsB,aAAiB,cACnBA,EAAM,OAASJ,EAAQ,QAAUlB,EACrC,CAGA,SAAS,YAAakB,CAAO,CAC/B,CAAC,EAGDf,EAAyBK,EAAI,SAAS,EAAE,KACtCe,EAAOC,GAAMA,EAAG,MAAQ,OAAO,EAC/BC,GAAeT,EAAO,CAACU,EAAGR,IAAYA,CAAO,CAC/C,EACG,UAAU,CAAC,CAAE,MAAAlB,CAAM,IAAM,CACxBA,GAASA,EAAQ,GAAKH,EAAO,OAC7BA,EAAOG,CAAK,EAAE,MAAM,EACpBH,EAAOG,CAAK,EAAE,MAAM,CACtB,CAAC,EAGHgB,EACG,KACCZ,EAAI,IAAM,CACR,IAAMuB,EAASC,GAAoB,QAAQ,EACrCC,EAAS,OAAO,iBAAiBF,CAAM,EAG7C,OAAAf,EAAO,QAAUiB,EAAM,YAGhBA,EAAM,gBAAgB,MAAM,MAAM,EACtC,IAAIR,IAAU,CAACA,GAAO,SAAS,EAAE,EAAE,SAAS,EAAG,GAAG,CAAC,EACnD,KAAK,EAAE,CACZ,CAAC,CACH,EACG,UAAUS,GAASpB,EAAK,QAAU,IAAIoB,CAAK,EAAE,EAGlDd,EAAM,KAAKe,GAAUC,EAAc,CAAC,EACjC,UAAU,IAAM,CACf,SAAS,KAAK,gBAAgB,yBAAyB,CACzD,CAAC,EAGIpC,GAAaC,CAAM,EACvB,KACCoC,EAAUpB,EAAO,KAAKqB,GAAK,CAAC,CAAC,CAAC,EAC9BC,GAAO,EACPC,EAAIC,GAASrB,EAAM,KAAKqB,CAAK,CAAC,EAC9BC,EAAS,IAAMtB,EAAM,SAAS,CAAC,EAC/BZ,EAAIiC,GAAUE,EAAA,CAAE,IAAK/B,GAAO6B,EAAQ,CACtC,CACJ,CAAC,CACH,CChJO,SAASG,GACdC,EAAiB,CAAE,UAAAC,CAAU,EACI,CAGjC,OAAOC,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAU,CAAC,CAAE,MAAAE,CAAM,IAAM,CAC7BL,EAAG,MAAM,YAAY,sBAAuB,GAAGK,CAAK,EAAE,CACxD,CAAC,EAGMJ,EACJ,KACCK,EAAID,GAASF,EAAM,KAAK,CAAE,MAAAE,CAAM,CAAC,CAAC,EAClCE,EAAS,IAAMJ,EAAM,SAAS,CAAC,EAC/BK,EAAIH,IAAU,CAAE,IAAKL,EAAI,MAAAK,CAAM,EAAE,CACnC,CACJ,CAAC,CACH,CChEA,IAAAI,GAAwB,SAiCxB,SAASC,GAAQC,EAAyB,CACxCA,EAAG,aAAa,kBAAmB,EAAE,EACrC,IAAMC,EAAOD,EAAG,QAAQ,aAAa,EAC/BE,EAAOD,EACTA,EAAK,aAAa,WAAW,EAC7BD,EAAG,UACP,OAAAA,EAAG,gBAAgB,iBAAiB,EAC7BE,EAAK,QAAQ,CACtB,CAWO,SAASC,GACd,CAAE,OAAAC,CAAO,EACH,CACF,GAAAC,QAAY,YAAY,GAC1B,IAAIC,EAA8BC,GAAc,CAC9C,IAAI,GAAAF,QAAY,iDAAkD,CAChE,KAAML,GACJA,EAAG,aAAa,qBAAqB,GACrCD,GAAQS,EACNR,EAAG,aAAa,uBAAuB,CACzC,CAAC,CAEL,CAAC,EACE,GAAG,UAAWS,GAAMF,EAAW,KAAKE,CAAE,CAAC,CAC5C,CAAC,EACE,KACCC,EAAID,GAAM,CACQA,EAAG,QACX,MAAM,CAChB,CAAC,EACDE,EAAI,IAAMC,GAAY,kBAAkB,CAAC,CAC3C,EACG,UAAUR,CAAM,CAEzB,CCrCA,SAASS,GAAQC,EAAUC,EAAW,CACpC,OAAAD,EAAI,SAAWC,EAAK,SACpBD,EAAI,SAAWC,EAAK,SACbD,CACT,CA2BA,SAASE,GAAQC,EAAoBF,EAAoB,CACvD,IAAMG,EAAmB,IAAI,IAC7B,QAAWC,KAAMC,EAAY,MAAOH,CAAQ,EAAG,CAC7C,IAAMH,EAAMO,EAAW,MAAOF,CAAE,EAG1BG,EAAQ,CAACT,GAAQ,IAAI,IAAIC,EAAI,WAAY,EAAGC,CAAI,CAAC,EACvDG,EAAQ,IAAI,GAAGI,EAAM,CAAC,CAAC,GAAIA,CAAK,EAGhC,QAAWC,KAAQH,EAAY,kBAAmBD,CAAE,EAAG,CACrD,IAAMK,EAAOD,EAAK,aAAa,MAAM,EACjCC,GAAQ,MACVF,EAAM,KAAKT,GAAQ,IAAI,IAAIW,CAAI,EAAGT,CAAI,CAAC,CAC3C,CACF,CAGA,OAAOG,CACT,CAgBO,SAASO,GAAaV,EAAyC,CACpE,OAAOW,GAAW,IAAI,IAAI,cAAeX,CAAI,CAAC,EAC3C,KACCY,EAAIV,GAAYD,GAAQC,EAAU,IAAI,IAAIF,CAAI,CAAC,CAAC,EAChDa,GAAW,IAAMC,EAAG,IAAI,GAAK,CAAC,CAChC,CACJ,CClDA,SAASC,GACPC,EAAgBC,EACC,CACjB,GAAI,EAAED,EAAG,kBAAkB,SACzB,OAAOE,EAIT,IAAMC,EAAKH,EAAG,OAAO,QAAQ,GAAG,EAChC,GAAIG,IAAO,KACT,OAAOD,EAMT,GAAIC,EAAG,QAAUH,EAAG,SAAWA,EAAG,QAChC,OAAOE,EAQT,IAAME,EAAM,IAAI,IAAID,EAAG,IAAI,EAO3B,OANAC,EAAI,OAASA,EAAI,KAAO,GAMnBH,EAAQ,IAAI,GAAGG,CAAG,EAAE,GASzBJ,EAAG,eAAe,EACXK,EAAG,IAAI,IAAIF,EAAG,IAAI,CAAC,GATjBD,CAUX,CASA,SAASI,GAAKC,EAA8C,CAC1D,IAAMC,EAAO,IAAI,IACjB,QAAWL,KAAMM,EAAY,aAAcF,EAAS,IAAI,EACtDC,EAAK,IAAIL,EAAG,UAAWA,CAAE,EAG3B,OAAOK,CACT,CAYA,SAASE,GAAQH,EAA0C,CACzD,QAAWJ,KAAMM,EAAY,gBAAiBF,CAAQ,EACpD,QAAWI,IAAO,CAAC,OAAQ,KAAK,EAAG,CACjC,IAAMC,EAAQT,EAAG,aAAaQ,CAAG,EACjC,GAAIC,GAAS,CAAC,qBAAqB,KAAKA,CAAK,EAAG,CAE9CT,EAAGQ,CAAG,EAAIR,EAAGQ,CAAG,EAChB,KACF,CACF,CAGF,OAAON,EAAGE,CAAQ,CACpB,CASA,SAASM,GAAOC,EAAsC,CACpD,QAAWC,IAAY,CACrB,+BACA,gCACA,mCACA,+BACA,2BACA,2BACA,GAAGC,EAAQ,wBAAwB,EAC/B,CAAC,0BAA0B,EAC3B,CAAC,CACP,EAAG,CACD,IAAMC,EAASC,GAAmBH,CAAQ,EACpCI,EAASD,GAAmBH,EAAUD,CAAI,EAE9C,OAAOG,GAAW,aAClB,OAAOE,GAAW,aAElBF,EAAO,YAAYE,CAAM,CAE7B,CAGA,IAAMX,EAAOF,GAAK,QAAQ,EAC1B,OAAW,CAACc,EAAMjB,CAAE,IAAKG,GAAKQ,CAAI,EAC5BN,EAAK,IAAIY,CAAI,EACfZ,EAAK,OAAOY,CAAI,EAEhB,SAAS,KAAK,YAAYjB,CAAE,EAGhC,QAAWA,KAAMK,EAAK,OAAO,EAAG,CAC9B,IAAMa,EAAOlB,EAAG,aAAa,MAAM,EAI/BkB,IAAS,eAAiBA,IAAS,gBACrClB,EAAG,OAAO,CACd,CAIA,IAAMmB,EAAYC,GAAoB,WAAW,EACjD,OAAOC,GAAOf,EAAY,SAAUa,CAAS,CAAC,EAC3C,KACCG,EAAUtB,GAAM,CACd,IAAMuB,EAASZ,EAAK,cAAc,QAAQ,EAC1C,GAAIX,EAAG,IAAK,CACV,QAAWkB,KAAQlB,EAAG,kBAAkB,EACtCuB,EAAO,aAAaL,EAAMlB,EAAG,aAAakB,CAAI,CAAE,EAClD,OAAAlB,EAAG,YAAYuB,CAAM,EAGd,IAAIC,EAAWC,GAAY,CAChCF,EAAO,OAAS,IAAME,EAAS,SAAS,CAC1C,CAAC,CAGH,KACE,QAAAF,EAAO,YAAcvB,EAAG,YACxBA,EAAG,YAAYuB,CAAM,EACdxB,CAEX,CAAC,EACD2B,EAAe,EACfC,GAAQ,QAAQ,CAClB,CACJ,CAgBO,SAASC,GACd,CAAE,UAAAC,EAAW,UAAAC,EAAW,UAAAC,CAAU,EACZ,CACtB,IAAMC,EAASC,GAAc,EAC7B,GAAI,SAAS,WAAa,QACxB,OAAOlC,EAIT,IAAMmC,EAAWC,GAAaH,EAAO,IAAI,EAUzC9B,EAAG,QAAQ,EACR,UAAUK,EAAO,EAUpB,IAAM6B,EACJC,EAAsB,SAAS,KAAM,OAAO,EACzC,KACCC,GAAkBJ,CAAQ,EAC1BZ,EAAU,CAAC,CAACzB,EAAIC,CAAO,IAAMF,GAAOC,EAAIC,CAAO,CAAC,EAChDyC,GAAM,CACR,EAIEC,EACJH,EAAyB,OAAQ,UAAU,EACxC,KACCI,EAAIC,EAAW,EACfH,GAAM,CACR,EAMJH,EAAS,KAAKO,GAAeb,CAAS,CAAC,EACpC,UAAU,CAAC,CAAC7B,EAAK,CAAE,OAAA2C,CAAO,CAAC,IAAM,CAChC,QAAQ,aAAaA,EAAQ,EAAE,EAC/B,QAAQ,UAAU,KAAM,GAAI3C,CAAG,CACjC,CAAC,EAMH4C,EAAMT,EAAUI,CAAQ,EACrB,UAAUX,CAAS,EActB,IAAMiB,EACJjB,EAAU,KACRkB,GAAwB,UAAU,EAClCzB,EAAUrB,GAAO+C,GAAY/C,EAAK,CAAE,UAAA8B,CAAU,CAAC,EAC5C,KACCkB,GAAW,KACTC,GAAYjD,EAAK,EAAI,EACdF,EACR,CACH,CACF,EAIAuB,EAAUf,EAAO,EACjBe,EAAUZ,EAAM,EAChB6B,GAAM,CACR,EAUF,OAAAM,EACEC,EAAU,KAAKH,GAAed,EAAW,CAACsB,EAAGlD,IAAQA,CAAG,CAAC,EASzD6C,EAAU,KACRxB,EAAU,IAAMO,CAAS,EACzBkB,GAAwB,UAAU,EAClCzB,EAAU,IAAMO,CAAS,EACzBkB,GAAwB,MAAM,CAChC,EAQAlB,EAAU,KACRuB,EAAqB,CAACC,EAAGC,IACvBD,EAAE,WAAaC,EAAE,UACjBD,EAAE,OAAaC,EAAE,IAClB,EACDhC,EAAU,IAAMc,CAAQ,EACxBmB,EAAI,IAAM,QAAQ,KAAK,CAAC,CAC1B,CACF,EACG,UAAUtD,GAAO,CA1YtB,IAAAuD,EAAAC,EAgZU,QAAQ,QAAU,MAAQ,CAACxD,EAAI,KACjC,OAAO,SAAS,GAAGwD,GAAAD,EAAA,QAAQ,QAAR,YAAAA,EAAe,IAAf,KAAAC,EAAoB,CAAC,GAExC,QAAQ,kBAAoB,OAC5BC,GAAgBzD,EAAI,IAAI,EACxB,QAAQ,kBAAoB,SAEhC,CAAC,EAMH4B,EAAU,UAAU,IAAM,CACxB,QAAQ,kBAAoB,QAC9B,CAAC,EAMDQ,EAAU,OAAQ,cAAc,EAC7B,UAAU,IAAM,CACf,QAAQ,kBAAoB,MAC9B,CAAC,EAMHP,EAAU,KACRiB,GAAwB,QAAQ,EAChCY,GAAa,GAAG,CAClB,EACG,UAAU,CAAC,CAAE,OAAAf,CAAO,IAAM,CACzB,QAAQ,aAAaA,EAAQ,EAAE,CACjC,CAAC,EAGIE,CACT,CClaA,IAAAc,GAAuB,SAqChB,SAASC,GACdC,EAC0B,CAE1B,IAAMC,EAAQD,EAAO,UAAU,MAAM,GAAG,EAAE,IAAIE,GAC/BA,EAAK,QAAQ,sBAAuB,EAAE,EACvC,SAAW,EAAI,SAAMA,CAClC,EACE,KAAK,GAAG,EAELC,EAAY,IAAI,OAAOF,EAAO,KAAK,EACnCG,EAAY,CAACC,EAAYC,EAAcJ,IACpC,GAAGI,CAAI,2BAA2BJ,CAAI,UAI/C,OAAQK,GAAkB,CACxBA,EAAQA,EACL,QAAQ,gBAAiB,GAAG,EAC5B,KAAK,EAGR,IAAMC,EAAQ,IAAI,OAAO,MAAMR,EAAO,SAAS,MAC7CO,EACG,QAAQ,uBAAwB,MAAM,EACtC,QAAQJ,EAAW,GAAG,CAC3B,IAAK,KAAK,EAGV,OAAOM,MAAS,GAAAC,SAAWD,CAAK,EAC7B,QAAQD,EAAOJ,CAAS,EACxB,QAAQ,8BAA+B,IAAI,CAChD,CACF,CCEO,SAASO,GACdC,EAC+B,CAC/B,OAAOA,EAAQ,OAAS,CAC1B,CASO,SAASC,GACdD,EACgC,CAChC,OAAOA,EAAQ,OAAS,CAC1B,CC1CO,SAASE,GACdC,EAAaC,EACW,CACxB,IAAMC,EAAUC,GAA2BH,CAAG,EAC9C,OAAAI,EACEC,EAAG,SAAS,WAAa,OAAO,EAChCC,GAAY,QAAQ,CACtB,EACG,KACCC,GAAMC,GAAUA,CAAM,EACtBC,EAAU,IAAMR,CAAM,CACxB,EACG,UAAU,CAAC,CAAE,OAAAS,EAAQ,KAAAC,CAAK,IAAMT,EAAQ,KAAK,CAC5C,OACA,KAAM,CACJ,OAAAQ,EACA,KAAAC,EACA,QAAS,CACP,QAASC,EAAQ,gBAAgB,CACnC,CACF,CACF,CAAC,CAAC,EAGCV,CACT,CCjEO,SAASW,GACdC,EACiB,CA/BnB,IAAAC,EAgCE,GAAM,CAAC,uBAAAC,EACL,uBAAAC,EACA,gBAAAC,EACA,eAAAC,CAAc,EAAIL,EACdM,GAAeL,EAAAM,GAAaF,CAAc,IAA3B,YAAAJ,EAA8B,SACnD,GAAIK,IAAiB,OACnB,OAEF,IAAME,EAAsBC,GAAYL,EAAgB,SAAUE,CAAY,EAC9E,GAAIE,IAAwB,OAC1B,OAEF,IAAME,EAAsBC,GAAqBT,EAAuB,KAAK,CAAC,EAC9E,GAAI,CAACA,EAAuB,IAAIQ,CAAmB,EAIjD,OAGF,IAAME,EAAsBL,GAAaC,EAAqBE,CAAmB,EACjF,GAAI,CAACE,GAAuB,CAACV,EAAuB,IAAIU,EAAoB,IAAI,EAC9E,OAGF,IAAMC,EAASN,GAAaC,EAAqBL,CAAsB,EACvE,GAAKU,EAGL,OAAAA,EAAO,KAAOT,EAAgB,KAC9BS,EAAO,OAAST,EAAgB,OACzBS,CACT,CAWA,SAASN,GAAaO,EAAiBC,EAAoC,CACzE,GAAI,CACF,OAAO,IAAI,IAAID,EAAKC,CAAI,CAC1B,OAAQC,EAAA,CACN,MACF,CACF,CAYO,SAASP,GAAYQ,EAAWC,EAAoC,CACzE,GAAID,EAAE,WAAWC,CAAM,EACrB,OAAOD,EAAE,MAAMC,EAAO,MAAM,CAGhC,CASA,SAASC,GAAgBC,EAAYC,EAAoB,CACvD,IAAMC,EAAM,KAAK,IAAIF,EAAG,OAAQC,EAAG,MAAM,EACrCR,EACJ,IAAKA,EAAS,EAAGA,EAASS,GACpBF,EAAGP,CAAM,IAAMQ,EAAGR,CAAM,EADC,EAAEA,EAC/B,CAIF,OAAOA,CACT,CAQO,SAASF,GAAqBY,EAAgC,CACnE,IAAIV,EACJ,QAAWI,KAAKM,EACVV,IAAW,OACbA,EAASI,EAETJ,EAASA,EAAO,MAAM,EAAGM,GAAgBN,EAAQI,CAAC,CAAC,EAGvD,OAAOJ,GAAA,KAAAA,EAAU,EACnB,CC9DO,SAASW,GACd,CAAE,UAAAC,CAAU,EACN,CACN,IAAMC,EAASC,GAAc,EACvBC,EAAYC,GAChB,IAAI,IAAI,mBAAoBH,EAAO,IAAI,CACzC,EACG,KACCI,GAAW,IAAMC,CAAK,CACxB,EAGIC,EAAWJ,EACd,KACCK,EAAIC,GAAY,CACd,GAAM,CAAC,CAAEC,CAAO,EAAIT,EAAO,KAAK,MAAM,aAAa,EACnD,OAAOQ,EAAS,KAAK,CAAC,CAAE,QAAAE,EAAS,QAAAC,CAAQ,IACvCD,IAAYD,GAAWE,EAAQ,SAASF,CAAO,CAChD,GAAKD,EAAS,CAAC,CAClB,CAAC,CACH,EAGFN,EACG,KACCK,EAAIC,GAAY,IAAI,IAAIA,EAAS,IAAIE,GAAW,CAC9C,GAAG,IAAI,IAAI,MAAMA,EAAQ,OAAO,IAAKV,EAAO,IAAI,CAAC,GACjDU,CACF,CAAC,CAAC,CAAC,EACHE,EAAUC,GAAQC,EAAsB,SAAS,KAAM,OAAO,EAC3D,KACCC,EAAOC,GAAM,CAACA,EAAG,SAAW,CAACA,EAAG,OAAO,EACvCC,GAAeX,CAAQ,EACvBM,EAAU,CAAC,CAACI,EAAIP,CAAO,IAAM,CAC3B,GAAIO,EAAG,kBAAkB,QAAS,CAChC,IAAME,EAAKF,EAAG,OAAO,QAAQ,GAAG,EAChC,GAAIE,GAAM,CAACA,EAAG,QAAUL,EAAK,IAAIK,EAAG,IAAI,EAAG,CACzC,IAAMC,EAAMD,EAAG,KAWf,MAAI,CAACF,EAAG,OAAO,QAAQ,aAAa,GAClBH,EAAK,IAAIM,CAAG,IACZV,EACPJ,GAEXW,EAAG,eAAe,EACXI,EAAG,IAAI,IAAID,CAAG,CAAC,EACxB,CACF,CACA,OAAOd,CACT,CAAC,EACDO,EAAUS,GACDC,GAAaD,CAAsB,EAAE,KAC1Cd,EACEgB,GAAQ,CAtIxB,IAAAC,EAuIkB,OAAAA,EAAAC,GAAgC,CAC9B,uBAAwBF,EACxB,uBAAAF,EACA,gBAAiBK,GAAY,EAC7B,eAAgB1B,EAAO,IACzB,CAAC,IALD,KAAAwB,EAKMH,EACV,CACF,CACD,CACH,CACF,CACF,EACG,UAAUF,GAAOQ,GAAYR,EAAK,EAAI,CAAC,EAG5CS,EAAc,CAAC1B,EAAWI,CAAQ,CAAC,EAChC,UAAU,CAAC,CAACE,EAAUC,CAAO,IAAM,CACpBoB,EAAW,mBAAmB,EACtC,YAAYC,GAAsBtB,EAAUC,CAAO,CAAC,CAC5D,CAAC,EAGHV,EAAU,KAAKa,EAAU,IAAMN,CAAQ,CAAC,EACrC,UAAUG,GAAW,CA9J1B,IAAAe,EAiKM,IAAIO,EAAW,SAAS,aAAc,cAAc,EACpD,GAAIA,IAAa,KAAM,CACrBA,EAAW,GAGX,IAAIC,IAAUR,EAAAxB,EAAO,UAAP,YAAAwB,EAAgB,UAAW,SACpC,MAAM,QAAQQ,CAAO,IACxBA,EAAU,CAACA,CAAO,GAGpBC,EAAM,QAAWC,KAAUF,EACzB,QAAWtB,KAAWD,EAAQ,QAAQ,OAAOA,EAAQ,OAAO,EAC1D,GAAI,IAAI,OAAOyB,EAAQ,GAAG,EAAE,KAAKxB,CAAO,EAAG,CACzCqB,EAAW,GACX,MAAME,CACR,CAGJ,SAAS,aAAcF,EAAU,cAAc,CACjD,CAGA,GAAIA,EACF,QAAWI,KAAWC,GAAqB,UAAU,EACnDD,EAAQ,OAAS,EACvB,CAAC,CACL,CCvFO,SAASE,GACdC,EAAsB,CAAE,QAAAC,CAAQ,EACP,CAGzB,GAAM,CAAE,aAAAC,CAAa,EAAIC,GAAY,EACjCD,EAAa,IAAI,GAAG,IACtBE,GAAU,SAAU,EAAI,EAGxBJ,EAAG,MAAQE,EAAa,IAAI,GAAG,EAC/BF,EAAG,MAAM,EAGTK,GAAY,QAAQ,EACjB,KACCC,GAAMC,GAAU,CAACA,CAAM,CACzB,EACG,UAAU,IAAM,CACf,IAAMC,EAAML,GAAY,EACxBK,EAAI,aAAa,OAAO,GAAG,EAC3B,QAAQ,aAAa,CAAC,EAAG,GAAI,GAAGA,CAAG,EAAE,CACvC,CAAC,GAIP,IAAMC,EAASC,GAAkBV,CAAE,EAC7BW,EAASC,EACbX,EAAQ,KAAKK,GAAMO,EAAoB,CAAC,EACxCC,EAAUd,EAAI,OAAO,EACrBS,CACF,EACG,KACCM,EAAI,IAAMf,EAAG,KAAK,EAClBgB,EAAqB,CACvB,EAGF,OAAOC,EAAc,CAACN,EAAQF,CAAM,CAAC,EAClC,KACCM,EAAI,CAAC,CAACG,EAAOC,CAAK,KAAO,CAAE,MAAAD,EAAO,MAAAC,CAAM,EAAE,EAC1CC,EAAY,CAAC,CACf,CACJ,CAUO,SAASC,GACdrB,EAAsB,CAAE,QAAAC,CAAQ,EACsB,CACtD,IAAMqB,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGC,GAAQ,EAAI,CAAC,EAGxDT,EAAc,CACZhB,EAAQ,KAAKK,GAAMO,EAAoB,CAAC,EACxCS,CACF,EAAG,CAACK,EAAGC,IAAUA,CAAK,EACnB,KACCC,GAAwB,OAAO,CACjC,EACG,UAAU,CAAC,CAAE,MAAAX,CAAM,IAAMjB,EAAQ,KAAK,CACrC,OACA,KAAMiB,CACR,CAAC,CAAC,EAGNI,EACG,KACCO,GAAwB,OAAO,CACjC,EACG,UAAU,CAAC,CAAE,MAAAV,CAAM,IAAM,CACpBA,GACFf,GAAU,SAAUe,CAAK,CAC7B,CAAC,EAGLL,EAAUd,EAAG,KAAO,OAAO,EACxB,KACC8B,EAAUN,CAAK,CACjB,EACG,UAAU,IAAMxB,EAAG,MAAM,CAAC,EAM/B,IAAM+B,EAAQC,EAAW,uBAAuB,EAChD,OAAAlB,EAAUiB,EAAO,OAAO,EACrB,UAAU,IAAM/B,EAAG,MAAM,CAAC,EAGtBD,GAAiBC,EAAI,CAAE,QAAAC,CAAQ,CAAC,EACpC,KACCgC,EAAIC,GAASZ,EAAM,KAAKY,CAAK,CAAC,EAC9BC,EAAS,IAAMb,EAAM,SAAS,CAAC,EAC/BP,EAAImB,GAAUE,EAAA,CAAE,IAAKpC,GAAOkC,EAAQ,EACpCd,EAAY,CAAC,CACf,CACJ,CCnHO,SAASiB,GACdC,EAAiB,CAAE,QAAAC,EAAS,OAAAC,CAAO,EACE,CACrC,IAAMC,EAAQ,IAAIC,EACZC,EAAYC,GAAqBN,EAAG,aAAc,EACrD,KACCO,EAAO,OAAO,CAChB,EAGIC,EAAYR,EAAG,cAGfS,EAAOC,EAAW,wBAAyBV,CAAE,EAC7CW,EAAOD,EAAW,uBAAwBV,CAAE,EAGlDY,GAAY,QAAQ,EACjB,UAAUC,GAAUF,EAAK,aACxB,OAAQE,EAAS,OAAS,cAC5B,CAAC,EAGHV,EACG,KACCW,GAAeZ,CAAM,EACrBa,GAAUd,EAAQ,KAAKe,GAAMC,EAAoB,CAAC,CAAC,CACrD,EACG,UAAU,CAAC,CAAC,CAAE,MAAAC,CAAM,EAAG,CAAE,MAAAC,CAAM,CAAC,IAAM,CACrC,OAAQD,EAAM,OAAQ,CAGpB,IAAK,GACHT,EAAK,YAAcU,EAAM,OACrBC,GAAY,oBAAoB,EAChCA,GAAY,2BAA2B,EAC3C,MAGF,IAAK,GACHX,EAAK,YAAcW,GAAY,mBAAmB,EAClD,MAGF,QACE,IAAMC,EAAQC,GAAMJ,EAAM,MAAM,EAChCT,EAAK,YAAcW,GAAY,sBAAuBC,CAAK,CAC/D,CACF,CAAC,EAGL,IAAME,EAAUpB,EACb,KACCqB,EAAI,IAAMb,EAAK,UAAY,EAAE,EAC7Bc,EAAU,CAAC,CAAE,MAAAP,CAAM,IAAMQ,EACvBC,EAAG,GAAGT,EAAM,MAAM,EAAG,EAAE,CAAC,EACxBS,EAAG,GAAGT,EAAM,MAAM,EAAE,CAAC,EAClB,KACCU,GAAY,CAAC,EACbC,GAAQxB,CAAS,EACjBoB,EAAU,CAAC,CAACK,CAAK,IAAMA,CAAK,CAC9B,CACJ,CAAC,EACDC,EAAIC,EAAsB,EAC1BC,GAAM,CACR,EAGF,OAAAV,EAAQ,UAAUW,GAAQvB,EAAK,YAAYuB,CAAI,CAAC,EAChDX,EACG,KACCY,GAASD,GAAQ,CACf,IAAME,EAAUC,GAAmB,UAAWH,CAAI,EAClD,OAAI,OAAOE,GAAY,YACdE,EAGFC,EAAUH,EAAS,QAAQ,EAC/B,KACCI,EAAUrC,CAAK,EACf4B,EAAI,IAAMK,CAAO,CACnB,CACJ,CAAC,CACH,EACG,UAAUA,GAAW,CAElBA,EAAQ,OAAS,IACjBA,EAAQ,WAAa5B,EAAU,WAE/BA,EAAU,SAAS,CAAE,IAAK4B,EAAQ,SAAU,CAAC,CACjD,CAAC,EAGWnC,EACb,KACCM,EAAOkC,EAAqB,EAC5BV,EAAI,CAAC,CAAE,KAAAW,CAAK,IAAMA,CAAI,CACxB,EAIC,KACClB,EAAImB,GAASxC,EAAM,KAAKwC,CAAK,CAAC,EAC9BC,EAAS,IAAMzC,EAAM,SAAS,CAAC,EAC/B4B,EAAIY,GAAUE,EAAA,CAAE,IAAK7C,GAAO2C,EAAQ,CACtC,CACJ,CCpHO,SAASG,GACdC,EAAkB,CAAE,OAAAC,CAAO,EACF,CACzB,OAAOA,EACJ,KACCC,EAAI,CAAC,CAAE,MAAAC,CAAM,IAAM,CACjB,IAAMC,EAAMC,GAAY,EACxB,OAAAD,EAAI,KAAO,GAGXD,EAAQA,EACL,QAAQ,OAAQ,GAAG,EACnB,QAAQ,KAAM,KAAK,EACnB,QAAQ,KAAM,KAAK,EAGtBC,EAAI,OAAS,KAAKD,CAAK,GAChB,CAAE,IAAAC,CAAI,CACf,CAAC,CACH,CACJ,CAUO,SAASE,GACdC,EAAuBC,EACa,CACpC,IAAMC,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGC,GAAQ,EAAI,CAAC,EACxD,OAAAJ,EAAM,UAAU,CAAC,CAAE,IAAAL,CAAI,IAAM,CAC3BG,EAAG,aAAa,sBAAuBA,EAAG,IAAI,EAC9CA,EAAG,KAAO,GAAGH,CAAG,EAClB,CAAC,EAGDU,EAAUP,EAAI,OAAO,EAClB,KACCQ,EAAUJ,CAAK,CACjB,EACG,UAAUK,GAAMA,EAAG,eAAe,CAAC,EAGjCjB,GAAiBQ,EAAIC,CAAO,EAChC,KACCS,EAAIC,GAAST,EAAM,KAAKS,CAAK,CAAC,EAC9BC,EAAS,IAAMV,EAAM,SAAS,CAAC,EAC/BP,EAAIgB,GAAUE,EAAA,CAAE,IAAKb,GAAOW,EAAQ,CACtC,CACJ,CCpDO,SAASG,GACdC,EAAiB,CAAE,QAAAC,EAAS,UAAAC,CAAU,EACA,CACtC,IAAMC,EAAQ,IAAIC,EAGZC,EAASC,GAAoB,cAAc,EAC3CC,EAASC,EACbC,EAAUJ,EAAO,SAAS,EAC1BI,EAAUJ,EAAO,OAAO,CAC1B,EACG,KACCK,GAAUC,EAAc,EACxBC,EAAI,IAAMP,EAAM,KAAK,EACrBQ,EAAqB,CACvB,EAGF,OAAAV,EACG,KACCW,GAAkBP,CAAM,EACxBK,EAAI,CAAC,CAAC,CAAE,QAAAG,CAAQ,EAAGC,CAAK,IAAM,CAC5B,IAAMC,EAAQD,EAAM,MAAM,UAAU,EACpC,GAAID,GAAA,MAAAA,EAAS,QAAUE,EAAMA,EAAM,OAAS,CAAC,EAAG,CAC9C,IAAMC,EAAOH,EAAQA,EAAQ,OAAS,CAAC,EACnCG,EAAK,WAAWD,EAAMA,EAAM,OAAS,CAAC,CAAC,IACzCA,EAAMA,EAAM,OAAS,CAAC,EAAIC,EAC9B,MACED,EAAM,OAAS,EAEjB,OAAOA,CACT,CAAC,CACH,EACG,UAAUA,GAASjB,EAAG,UAAYiB,EAChC,KAAK,EAAE,EACP,QAAQ,MAAO,QAAQ,CAC1B,EAGJf,EACG,KACCiB,EAAO,CAAC,CAAE,KAAAC,CAAK,IAAMA,IAAS,QAAQ,CACxC,EACG,UAAUC,GAAO,CAChB,OAAQA,EAAI,KAAM,CAGhB,IAAK,aAEDrB,EAAG,UAAU,QACbK,EAAM,iBAAmBA,EAAM,MAAM,SAErCA,EAAM,MAAQL,EAAG,WACnB,KACJ,CACF,CAAC,EAGWC,EACb,KACCkB,EAAOG,EAAqB,EAC5BV,EAAI,CAAC,CAAE,KAAAW,CAAK,IAAMA,CAAI,CACxB,EAIC,KACCC,EAAIC,GAAStB,EAAM,KAAKsB,CAAK,CAAC,EAC9BC,EAAS,IAAMvB,EAAM,SAAS,CAAC,EAC/BS,EAAI,KAAO,CAAE,IAAKZ,CAAG,EAAE,CACzB,CACJ,CCjDO,SAAS2B,GACdC,EAAiB,CAAE,OAAAC,EAAQ,UAAAC,CAAU,EACN,CAC/B,IAAMC,EAASC,GAAc,EAC7B,GAAI,CACF,IAAMC,EAAUC,GAAkBH,EAAO,OAAQF,CAAM,EAGjDM,EAASC,GAAoB,eAAgBR,CAAE,EAC/CS,EAASD,GAAoB,gBAAiBR,CAAE,EAGtDU,EAAwBV,EAAI,OAAO,EAChC,KACCW,EAAO,CAAC,CAAE,OAAAC,CAAO,IACfA,aAAkB,SAAW,CAAC,CAACA,EAAO,QAAQ,GAAG,CAClD,CACH,EACG,UAAU,IAAMC,GAAU,SAAU,EAAK,CAAC,EAG/CX,EACG,KACCS,EAAO,CAAC,CAAE,KAAAG,CAAK,IAAMA,IAAS,QAAQ,CACxC,EACG,UAAUC,GAAO,CAChB,IAAMC,EAASC,GAAiB,EAChC,OAAQF,EAAI,KAAM,CAGhB,IAAK,QACH,GAAIC,IAAWT,EAAO,CACpB,IAAMW,EAAU,IAAI,IACpB,QAAWC,KAAUC,EACnB,sBAAuBX,CACzB,EAAG,CACD,IAAMY,EAAUF,EAAO,kBACvBD,EAAQ,IAAIC,EAAQ,WAClBE,EAAQ,aAAa,eAAe,CACtC,CAAC,CACH,CAGA,GAAIH,EAAQ,KAAM,CAChB,GAAM,CAAC,CAACI,CAAI,CAAC,EAAI,CAAC,GAAGJ,CAAO,EAAE,KAAK,CAAC,CAAC,CAAEK,CAAC,EAAG,CAAC,CAAEC,CAAC,IAAMA,EAAID,CAAC,EAC1DD,EAAK,MAAM,CACb,CAGAP,EAAI,MAAM,CACZ,CACA,MAGF,IAAK,SACL,IAAK,MACHF,GAAU,SAAU,EAAK,EACzBN,EAAM,KAAK,EACX,MAGF,IAAK,UACL,IAAK,YACH,GAAI,OAAOS,GAAW,YACpBT,EAAM,MAAM,MACP,CACL,IAAMkB,EAAM,CAAClB,EAAO,GAAGa,EACrB,wDACAX,CACF,CAAC,EACKiB,EAAI,KAAK,IAAI,GACjB,KAAK,IAAI,EAAGD,EAAI,QAAQT,CAAM,CAAC,EAAIS,EAAI,QACrCV,EAAI,OAAS,UAAY,GAAK,IAE9BU,EAAI,MAAM,EACdA,EAAIC,CAAC,EAAE,MAAM,CACf,CAGAX,EAAI,MAAM,EACV,MAGF,QACMR,IAAUU,GAAiB,GAC7BV,EAAM,MAAM,CAClB,CACF,CAAC,EAGLL,EACG,KACCS,EAAO,CAAC,CAAE,KAAAG,CAAK,IAAMA,IAAS,QAAQ,CACxC,EACG,UAAUC,GAAO,CAChB,OAAQA,EAAI,KAAM,CAGhB,IAAK,IACL,IAAK,IACL,IAAK,IACHR,EAAM,MAAM,EACZA,EAAM,OAAO,EAGbQ,EAAI,MAAM,EACV,KACJ,CACF,CAAC,EAGL,IAAMY,EAASC,GAAiBrB,EAAO,CAAE,QAAAF,CAAQ,CAAC,EAClD,OAAOwB,EACLF,EACAG,GAAkBrB,EAAQ,CAAE,QAAAJ,EAAS,OAAAsB,CAAO,CAAC,CAC/C,EACG,KACCI,GAGE,GAAGC,GAAqB,eAAgBhC,CAAE,EACvC,IAAIiC,GAASC,GAAiBD,EAAO,CAAE,OAAAN,CAAO,CAAC,CAAC,EAGnD,GAAGK,GAAqB,iBAAkBhC,CAAE,EACzC,IAAIiC,GAASE,GAAmBF,EAAO,CAAE,QAAA5B,EAAS,UAAAH,CAAU,CAAC,CAAC,CACnE,CACF,CAGJ,OAASkC,EAAK,CACZ,OAAApC,EAAG,OAAS,GACLqC,EACT,CACF,CCnKO,SAASC,GACdC,EAAiB,CAAE,OAAAC,EAAQ,UAAAC,CAAU,EACG,CACxC,OAAOC,EAAc,CACnBF,EACAC,EACG,KACCE,EAAUC,GAAY,CAAC,EACvBC,EAAOC,GAAO,CAAC,CAACA,EAAI,aAAa,IAAI,GAAG,CAAC,CAC3C,CACJ,CAAC,EACE,KACCC,EAAI,CAAC,CAACC,EAAOF,CAAG,IAAMG,GAAuBD,EAAM,MAAM,EACvDF,EAAI,aAAa,IAAI,GAAG,CAC1B,CAAC,EACDC,EAAIG,GAAM,CA1FhB,IAAAC,EA2FQ,IAAMC,EAAQ,IAAI,IAGZC,EAAK,SAAS,mBAAmBd,EAAI,WAAW,SAAS,EAC/D,QAASe,EAAOD,EAAG,SAAS,EAAGC,EAAMA,EAAOD,EAAG,SAAS,EACtD,IAAIF,EAAAG,EAAK,gBAAL,MAAAH,EAAoB,aAAc,CACpC,IAAMI,EAAWD,EAAK,YAChBE,EAAWN,EAAGK,CAAQ,EACxBC,EAAS,OAASD,EAAS,QAC7BH,EAAM,IAAIE,EAAmBE,CAAQ,CACzC,CAIF,OAAW,CAACF,EAAMG,CAAI,IAAKL,EAAO,CAChC,GAAM,CAAE,WAAAM,CAAW,EAAIC,EAAE,OAAQ,KAAMF,CAAI,EAC3CH,EAAK,YAAY,GAAG,MAAM,KAAKI,CAAU,CAAC,CAC5C,CAGA,MAAO,CAAE,IAAKnB,EAAI,MAAAa,CAAM,CAC1B,CAAC,CACH,CACJ,CCPO,SAASQ,GACdC,EAAiB,CAAE,UAAAC,EAAW,MAAAC,CAAM,EACf,CACrB,IAAMC,EAASH,EAAG,QAAqB,UAAU,EAC3CI,EACJD,EAAO,UACPA,EAAO,cAAe,UAGxB,OAAOE,EAAc,CAACH,EAAOD,CAAS,CAAC,EACpC,KACCK,EAAI,CAAC,CAAC,CAAE,OAAAC,EAAQ,OAAAC,CAAO,EAAG,CAAE,OAAQ,CAAE,EAAAC,CAAE,CAAE,CAAC,KACzCD,EAASA,EACL,KAAK,IAAIJ,EAAQ,KAAK,IAAI,EAAGK,EAAIF,CAAM,CAAC,EACxCH,EACG,CACL,OAAAI,EACA,OAAQC,GAAKF,EAASH,CACxB,EACD,EACDM,EAAqB,CAACC,EAAGC,IACvBD,EAAE,SAAWC,EAAE,QACfD,EAAE,SAAWC,EAAE,MAChB,CACH,CACJ,CAuBO,SAASC,GACdb,EAAiBc,EACe,CADf,IAAAC,EAAAD,EAAE,SAAAE,CA5JrB,EA4JmBD,EAAcE,EAAAC,GAAdH,EAAc,CAAZ,YAEnB,IAAMI,EAAQC,EAAW,0BAA2BpB,CAAE,EAChD,CAAE,EAAAS,CAAE,EAAIY,GAAiBF,CAAK,EACpC,OAAOG,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGC,GAAQ,EAAI,CAAC,EAClDC,EAAQL,EACX,KACCM,GAAU,EAAGC,EAAuB,CACtC,EAGF,OAAAF,EAAM,KAAKG,GAAef,CAAO,CAAC,EAC/B,UAAU,CAGT,KAAK,CAAC,CAAE,OAAAR,CAAO,EAAG,CAAE,OAAQD,CAAO,CAAC,EAAG,CACrCY,EAAM,MAAM,OAAS,GAAGX,EAAS,EAAIC,CAAC,KACtCT,EAAG,MAAM,IAAY,GAAGO,CAAM,IAChC,EAGA,UAAW,CACTY,EAAM,MAAM,OAAS,GACrBnB,EAAG,MAAM,IAAY,EACvB,CACF,CAAC,EAGH4B,EAAM,KAAKI,GAAM,CAAC,EACf,UAAU,IAAM,CACf,QAAWC,KAAQC,EAAY,8BAA+BlC,CAAE,EAAG,CACjE,GAAI,CAACiC,EAAK,aACR,SACF,IAAME,EAAYF,EAAK,QAAqB,yBAAyB,EACrE,GAAI,OAAOE,GAAc,YAAa,CACpC,IAAM5B,EAAS0B,EAAK,UAAYE,EAAU,UACpC,CAAE,OAAA3B,CAAO,EAAI4B,GAAeD,CAAS,EAC3CA,EAAU,SAAS,CACjB,IAAK5B,EAASC,EAAS,CACzB,CAAC,CACH,CACF,CACF,CAAC,EAGH6B,GAAKH,EAA8B,kBAAmBlC,CAAE,CAAC,EACtD,KACCsC,GAASC,GAASC,EAAUD,EAAO,OAAO,EACvC,KACCE,GAAUC,EAAc,EACxBpC,EAAI,IAAMiC,CAAK,EACfI,EAAUlB,CAAK,CACjB,CACF,CACF,EACG,UAAUc,GAAS,CAClB,IAAMK,EAAQxB,EAA6B,QAAQmB,EAAM,OAAO,IAAI,EACxDnB,EAAW,qBAAqBmB,EAAM,EAAE,IAAI,EACpD,aAAa,gBAAiB,GAAGK,EAAM,OAAO,EAAE,CACtD,CAAC,EAGE7C,GAAaC,EAAIiB,CAAO,EAC5B,KACC4B,EAAIC,GAASvB,EAAM,KAAKuB,CAAK,CAAC,EAC9BC,EAAS,IAAMxB,EAAM,SAAS,CAAC,EAC/BjB,EAAIwC,GAAUE,EAAA,CAAE,IAAKhD,GAAO8C,EAAQ,CACtC,CACJ,CAAC,CACH,CCxKO,SAASG,GACdC,EAAcC,EACW,CACzB,GAAI,OAAOA,GAAS,YAAa,CAC/B,IAAMC,EAAM,gCAAgCF,CAAI,IAAIC,CAAI,GACxD,OAAOE,GAGLC,GAAqB,GAAGF,CAAG,kBAAkB,EAC1C,KACCG,GAAW,IAAMC,CAAK,EACtBC,EAAIC,IAAY,CACd,QAASA,EAAQ,QACnB,EAAE,EACFC,GAAe,CAAC,CAAC,CACnB,EAGFL,GAAkBF,CAAG,EAClB,KACCG,GAAW,IAAMC,CAAK,EACtBC,EAAIG,IAAS,CACX,MAAOA,EAAK,iBACZ,MAAOA,EAAK,WACd,EAAE,EACFD,GAAe,CAAC,CAAC,CACnB,CACJ,EACG,KACCF,EAAI,CAAC,CAACC,EAASE,CAAI,IAAOC,IAAA,GAAKH,GAAYE,EAAO,CACpD,CAGJ,KAAO,CACL,IAAMR,EAAM,gCAAgCF,CAAI,GAChD,OAAOI,GAAkBF,CAAG,EACzB,KACCK,EAAIG,IAAS,CACX,aAAcA,EAAK,YACrB,EAAE,EACFD,GAAe,CAAC,CAAC,CACnB,CACJ,CACF,CC3CO,SAASG,GACdC,EAAcC,EACW,CACzB,IAAMC,EAAM,WAAWF,CAAI,oBAAoB,mBAAmBC,CAAO,CAAC,GAC1E,OAAOE,GAGLC,GAAqB,GAAGF,CAAG,4BAA4B,EACpD,KACCG,GAAW,IAAMC,CAAK,EACtBC,EAAI,CAAC,CAAE,SAAAC,CAAS,KAAO,CACrB,QAASA,CACX,EAAE,EACFC,GAAe,CAAC,CAAC,CACnB,EAGFL,GAA2BF,CAAG,EAC3B,KACCG,GAAW,IAAMC,CAAK,EACtBC,EAAI,CAAC,CAAE,WAAAG,EAAY,YAAAC,CAAY,KAAO,CACpC,MAAOD,EACP,MAAOC,CACT,EAAE,EACFF,GAAe,CAAC,CAAC,CACnB,CACJ,EACG,KACCF,EAAI,CAAC,CAACK,EAASC,CAAI,IAAOC,IAAA,GAAKF,GAAYC,EAAO,CACpD,CACJ,CCtBO,SAASE,GACdC,EACyB,CAGzB,IAAIC,EAAQD,EAAI,MAAM,qCAAqC,EAC3D,GAAIC,EAAO,CACT,GAAM,CAAC,CAAEC,EAAMC,CAAI,EAAIF,EACvB,OAAOG,GAA2BF,EAAMC,CAAI,CAC9C,CAIA,GADAF,EAAQD,EAAI,MAAM,oCAAoC,EAClDC,EAAO,CACT,GAAM,CAAC,CAAEI,EAAMC,CAAI,EAAIL,EACvB,OAAOM,GAA2BF,EAAMC,CAAI,CAC9C,CAGA,OAAOE,CACT,CCpBA,IAAIC,GAgBG,SAASC,GACdC,EACoB,CACpB,OAAOF,QAAWG,EAAM,IAAM,CAC5B,IAAMC,EAAS,SAAsB,WAAY,cAAc,EAC/D,GAAIA,EACF,OAAOC,EAAGD,CAAM,EAKhB,GADYE,GAAqB,SAAS,EAClC,OAAQ,CACd,IAAMC,EAAU,SAA0B,WAAW,EACrD,GAAI,EAAEA,GAAWA,EAAQ,QACvB,OAAOC,CACX,CAGA,OAAOC,GAAiBP,EAAG,IAAI,EAC5B,KACCQ,EAAIC,GAAS,SAAS,WAAYA,EAAO,cAAc,CAAC,CAC1D,CAEN,CAAC,EACE,KACCC,GAAW,IAAMJ,CAAK,EACtBK,EAAOF,GAAS,OAAO,KAAKA,CAAK,EAAE,OAAS,CAAC,EAC7CG,EAAIH,IAAU,CAAE,MAAAA,CAAM,EAAE,EACxBI,EAAY,CAAC,CACf,EACJ,CASO,SAASC,GACdd,EAC+B,CAC/B,IAAMe,EAAQC,EAAW,uBAAwBhB,CAAE,EACnD,OAAOC,EAAM,IAAM,CACjB,IAAMgB,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAU,CAAC,CAAE,MAAAR,CAAM,IAAM,CAC7BM,EAAM,YAAYI,GAAkBV,CAAK,CAAC,EAC1CM,EAAM,UAAU,IAAI,+BAA+B,CACrD,CAAC,EAGMhB,GAAYC,CAAE,EAClB,KACCQ,EAAIY,GAASH,EAAM,KAAKG,CAAK,CAAC,EAC9BC,EAAS,IAAMJ,EAAM,SAAS,CAAC,EAC/BL,EAAIQ,GAAUE,EAAA,CAAE,IAAKtB,GAAOoB,EAAQ,CACtC,CACJ,CAAC,CACH,CCtDO,SAASG,GACdC,EAAiB,CAAE,UAAAC,EAAW,QAAAC,CAAQ,EACpB,CAClB,OAAOC,GAAiB,SAAS,IAAI,EAClC,KACCC,EAAU,IAAMC,GAAgBL,EAAI,CAAE,QAAAE,EAAS,UAAAD,CAAU,CAAC,CAAC,EAC3DK,EAAI,CAAC,CAAE,OAAQ,CAAE,EAAAC,CAAE,CAAE,KACZ,CACL,OAAQA,GAAK,EACf,EACD,EACDC,GAAwB,QAAQ,CAClC,CACJ,CAaO,SAASC,GACdT,EAAiBU,EACY,CAC7B,OAAOC,EAAM,IAAM,CACjB,IAAMC,EAAQ,IAAIC,EAClB,OAAAD,EAAM,UAAU,CAGd,KAAK,CAAE,OAAAE,CAAO,EAAG,CACfd,EAAG,OAASc,CACd,EAGA,UAAW,CACTd,EAAG,OAAS,EACd,CACF,CAAC,GAICe,EAAQ,wBAAwB,EAC5BC,EAAG,CAAE,OAAQ,EAAM,CAAC,EACpBjB,GAAUC,EAAIU,CAAO,GAExB,KACCO,EAAIC,GAASN,EAAM,KAAKM,CAAK,CAAC,EAC9BC,EAAS,IAAMP,EAAM,SAAS,CAAC,EAC/BN,EAAIY,GAAUE,EAAA,CAAE,IAAKpB,GAAOkB,EAAQ,CACtC,CACJ,CAAC,CACH,CCfO,SAASG,GACdC,EAAiB,CAAE,UAAAC,EAAW,QAAAC,CAAQ,EACT,CAC7B,IAAMC,EAAQ,IAAI,IAGZC,EAAUC,EAA+B,gBAAiBL,CAAE,EAClE,QAAWM,KAAUF,EAAS,CAC5B,IAAMG,EAAK,mBAAmBD,EAAO,KAAK,UAAU,CAAC,CAAC,EAChDE,EAASC,GAAmB,QAAQF,CAAE,IAAI,EAC5C,OAAOC,GAAW,aACpBL,EAAM,IAAIG,EAAQE,CAAM,CAC5B,CAGA,IAAME,EAAUR,EACb,KACCS,GAAwB,QAAQ,EAChCC,EAAI,CAAC,CAAE,OAAAC,CAAO,IAAM,CAClB,IAAMC,EAAOC,GAAoB,MAAM,EACjCC,EAAOC,EAAW,wBAAyBH,CAAI,EACrD,OAAOD,EAAS,IACdG,EAAK,UACLF,EAAK,UAET,CAAC,EACDI,GAAM,CACR,EAqFF,OAlFmBC,GAAiB,SAAS,IAAI,EAC9C,KACCR,GAAwB,QAAQ,EAGhCS,EAAUC,GAAQC,EAAM,IAAM,CAC5B,IAAIC,EAA4B,CAAC,EACjC,OAAOC,EAAG,CAAC,GAAGrB,CAAK,EAAE,OAAO,CAACsB,EAAO,CAACnB,EAAQE,CAAM,IAAM,CACvD,KAAOe,EAAK,QACGpB,EAAM,IAAIoB,EAAKA,EAAK,OAAS,CAAC,CAAC,EACnC,SAAWf,EAAO,SACzBe,EAAK,IAAI,EAOb,IAAIG,EAASlB,EAAO,UACpB,KAAO,CAACkB,GAAUlB,EAAO,eACvBA,EAASA,EAAO,cAChBkB,EAASlB,EAAO,UAIlB,IAAImB,EAASnB,EAAO,aACpB,KAAOmB,EAAQA,EAASA,EAAO,aAC7BD,GAAUC,EAAO,UAGnB,OAAOF,EAAM,IACX,CAAC,GAAGF,EAAO,CAAC,GAAGA,EAAMjB,CAAM,CAAC,EAAE,QAAQ,EACtCoB,CACF,CACF,EAAG,IAAI,GAAkC,CAAC,CAC5C,CAAC,EACE,KAGCd,EAAIa,GAAS,IAAI,IAAI,CAAC,GAAGA,CAAK,EAAE,KAAK,CAAC,CAAC,CAAEG,CAAC,EAAG,CAAC,CAAEC,CAAC,IAAMD,EAAIC,CAAC,CAAC,CAAC,EAC9DC,GAAkBpB,CAAO,EAGzBU,EAAU,CAAC,CAACK,EAAOM,CAAM,IAAM9B,EAC5B,KACC+B,GAAK,CAAC,CAACC,EAAMC,CAAI,EAAG,CAAE,OAAQ,CAAE,EAAAC,CAAE,EAAG,KAAAC,CAAK,IAAM,CAC9C,IAAMC,EAAOF,EAAIC,EAAK,QAAU,KAAK,MAAMf,EAAK,MAAM,EAGtD,KAAOa,EAAK,QAAQ,CAClB,GAAM,CAAC,CAAER,CAAM,EAAIQ,EAAK,CAAC,EACzB,GAAIR,EAASK,EAASI,GAAKE,EACzBJ,EAAO,CAAC,GAAGA,EAAMC,EAAK,MAAM,CAAE,MAE9B,MAEJ,CAGA,KAAOD,EAAK,QAAQ,CAClB,GAAM,CAAC,CAAEP,CAAM,EAAIO,EAAKA,EAAK,OAAS,CAAC,EACvC,GAAIP,EAASK,GAAUI,GAAK,CAACE,EAC3BH,EAAO,CAACD,EAAK,IAAI,EAAI,GAAGC,CAAI,MAE5B,MAEJ,CAGA,MAAO,CAACD,EAAMC,CAAI,CACpB,EAAG,CAAC,CAAC,EAAG,CAAC,GAAGT,CAAK,CAAC,CAAC,EACnBa,EAAqB,CAACV,EAAGC,IACvBD,EAAE,CAAC,IAAMC,EAAE,CAAC,GACZD,EAAE,CAAC,IAAMC,EAAE,CAAC,CACb,CACH,CACF,CACF,CACF,CACF,EAIC,KACCjB,EAAI,CAAC,CAACqB,EAAMC,CAAI,KAAO,CACrB,KAAMD,EAAK,IAAI,CAAC,CAACV,CAAI,IAAMA,CAAI,EAC/B,KAAMW,EAAK,IAAI,CAAC,CAACX,CAAI,IAAMA,CAAI,CACjC,EAAE,EAGFgB,EAAU,CAAE,KAAM,CAAC,EAAG,KAAM,CAAC,CAAE,CAAC,EAChCC,GAAY,EAAG,CAAC,EAChB5B,EAAI,CAAC,CAACgB,EAAGC,CAAC,IAGJD,EAAE,KAAK,OAASC,EAAE,KAAK,OAClB,CACL,KAAMA,EAAE,KAAK,MAAM,KAAK,IAAI,EAAGD,EAAE,KAAK,OAAS,CAAC,EAAGC,EAAE,KAAK,MAAM,EAChE,KAAM,CAAC,CACT,EAIO,CACL,KAAMA,EAAE,KAAK,MAAM,EAAE,EACrB,KAAMA,EAAE,KAAK,MAAM,EAAGA,EAAE,KAAK,OAASD,EAAE,KAAK,MAAM,CACrD,CAEH,CACH,CACJ,CAYO,SAASa,GACdzC,EAAiB,CAAE,UAAAC,EAAW,QAAAC,EAAS,MAAAwC,EAAO,QAAAC,CAAQ,EACd,CACxC,OAAOrB,EAAM,IAAM,CACjB,IAAMsB,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGC,GAAQ,EAAI,CAAC,EAoBxD,GAnBAJ,EAAM,UAAU,CAAC,CAAE,KAAAX,EAAM,KAAAC,CAAK,IAAM,CAGlC,OAAW,CAAC5B,CAAM,IAAK4B,EACrB5B,EAAO,UAAU,OAAO,sBAAsB,EAC9CA,EAAO,UAAU,OAAO,sBAAsB,EAIhD,OAAW,CAACmB,EAAO,CAACnB,CAAM,CAAC,IAAK2B,EAAK,QAAQ,EAC3C3B,EAAO,UAAU,IAAI,sBAAsB,EAC3CA,EAAO,UAAU,OACf,uBACAmB,IAAUQ,EAAK,OAAS,CAC1B,CAEJ,CAAC,EAGGgB,EAAQ,YAAY,EAAG,CAGzB,IAAMC,EAAUC,EACdlD,EAAU,KAAKmD,GAAa,CAAC,EAAGxC,EAAI,IAAG,EAAY,CAAC,EACpDX,EAAU,KAAKmD,GAAa,GAAG,EAAGxC,EAAI,IAAM,QAAiB,CAAC,CAChE,EAGAgC,EACG,KACCS,EAAO,CAAC,CAAE,KAAApB,CAAK,IAAMA,EAAK,OAAS,CAAC,EACpCH,GAAkBY,EAAM,KAAKY,GAAUC,EAAc,CAAC,CAAC,EACvDC,GAAeN,CAAO,CACxB,EACG,UAAU,CAAC,CAAC,CAAC,CAAE,KAAAjB,CAAK,CAAC,EAAGwB,CAAQ,IAAM,CACrC,GAAM,CAACnD,CAAM,EAAI2B,EAAKA,EAAK,OAAS,CAAC,EACrC,GAAI3B,EAAO,aAAc,CAGvB,IAAMoD,EAAYC,GAAoBrD,CAAM,EAC5C,GAAI,OAAOoD,GAAc,YAAa,CACpC,IAAMhC,EAASpB,EAAO,UAAYoD,EAAU,UACtC,CAAE,OAAA7C,CAAO,EAAI+C,GAAeF,CAAS,EAC3CA,EAAU,SAAS,CACjB,IAAKhC,EAASb,EAAS,EACvB,SAAA4C,CACF,CAAC,CACH,CACF,CACF,CAAC,CACP,CAGA,OAAIR,EAAQ,qBAAqB,GAC/BhD,EACG,KACC4D,EAAUf,CAAK,EACfnC,GAAwB,QAAQ,EAChCyC,GAAa,GAAG,EAChBU,GAAK,CAAC,EACND,EAAUlB,EAAQ,KAAKmB,GAAK,CAAC,CAAC,CAAC,EAC/BC,GAAO,CAAE,MAAO,GAAI,CAAC,EACrBP,GAAeZ,CAAK,CACtB,EACG,UAAU,CAAC,CAAC,CAAE,CAAE,KAAAX,CAAK,CAAC,IAAM,CAC3B,IAAM+B,EAAMC,GAAY,EAGlB3D,EAAS2B,EAAKA,EAAK,OAAS,CAAC,EACnC,GAAI3B,GAAUA,EAAO,OAAQ,CAC3B,GAAM,CAAC4D,CAAM,EAAI5D,EACX,CAAE,KAAA6D,CAAK,EAAI,IAAI,IAAID,EAAO,IAAI,EAChCF,EAAI,OAASG,IACfH,EAAI,KAAOG,EACX,QAAQ,aAAa,CAAC,EAAG,GAAI,GAAGH,CAAG,EAAE,EAIzC,MACEA,EAAI,KAAO,GACX,QAAQ,aAAa,CAAC,EAAG,GAAI,GAAGA,CAAG,EAAE,CAEzC,CAAC,EAGAjE,GAAqBC,EAAI,CAAE,UAAAC,EAAW,QAAAC,CAAQ,CAAC,EACnD,KACCkE,EAAIC,GAASzB,EAAM,KAAKyB,CAAK,CAAC,EAC9BC,EAAS,IAAM1B,EAAM,SAAS,CAAC,EAC/BhC,EAAIyD,GAAUE,EAAA,CAAE,IAAKvE,GAAOqE,EAAQ,CACtC,CACJ,CAAC,CACH,CC9RO,SAASG,GACdC,EAAkB,CAAE,UAAAC,EAAW,MAAAC,EAAO,QAAAC,CAAQ,EACvB,CAGvB,IAAMC,EAAaH,EAChB,KACCI,EAAI,CAAC,CAAE,OAAQ,CAAE,EAAAC,CAAE,CAAE,IAAMA,CAAC,EAC5BC,GAAY,EAAG,CAAC,EAChBF,EAAI,CAAC,CAAC,EAAGG,CAAC,IAAM,EAAIA,GAAKA,EAAI,CAAC,EAC9BC,EAAqB,CACvB,EAGIC,EAAUR,EACb,KACCG,EAAI,CAAC,CAAE,OAAAM,CAAO,IAAMA,CAAM,CAC5B,EAGF,OAAOC,EAAc,CAACF,EAASN,CAAU,CAAC,EACvC,KACCC,EAAI,CAAC,CAACM,EAAQE,CAAS,IAAM,EAAEF,GAAUE,EAAU,EACnDJ,EAAqB,EACrBK,EAAUX,EAAQ,KAAKY,GAAK,CAAC,CAAC,CAAC,EAC/BC,GAAQ,EAAI,EACZC,GAAO,CAAE,MAAO,GAAI,CAAC,EACrBZ,EAAIa,IAAW,CAAE,OAAAA,CAAO,EAAE,CAC5B,CACJ,CAYO,SAASC,GACdC,EAAiB,CAAE,UAAAnB,EAAW,QAAAoB,EAAS,MAAAnB,EAAO,QAAAC,CAAQ,EACpB,CAClC,IAAMmB,EAAQ,IAAIC,EACZC,EAAQF,EAAM,KAAKG,EAAe,EAAGT,GAAQ,EAAI,CAAC,EACxD,OAAAM,EAAM,UAAU,CAGd,KAAK,CAAE,OAAAJ,CAAO,EAAG,CACfE,EAAG,OAASF,EACRA,GACFE,EAAG,aAAa,WAAY,IAAI,EAChCA,EAAG,KAAK,GAERA,EAAG,gBAAgB,UAAU,CAEjC,EAGA,UAAW,CACTA,EAAG,MAAM,IAAM,GACfA,EAAG,OAAS,GACZA,EAAG,gBAAgB,UAAU,CAC/B,CACF,CAAC,EAGDC,EACG,KACCP,EAAUU,CAAK,EACfE,GAAwB,QAAQ,CAClC,EACG,UAAU,CAAC,CAAE,OAAAC,CAAO,IAAM,CACzBP,EAAG,MAAM,IAAM,GAAGO,EAAS,EAAE,IAC/B,CAAC,EAGLC,EAAUR,EAAI,OAAO,EAClB,UAAUS,GAAM,CACfA,EAAG,eAAe,EAClB,OAAO,SAAS,CAAE,IAAK,CAAE,CAAC,CAC5B,CAAC,EAGI9B,GAAeqB,EAAI,CAAE,UAAAnB,EAAW,MAAAC,EAAO,QAAAC,CAAQ,CAAC,EACpD,KACC2B,EAAIC,GAAST,EAAM,KAAKS,CAAK,CAAC,EAC9BC,EAAS,IAAMV,EAAM,SAAS,CAAC,EAC/BjB,EAAI0B,GAAUE,EAAA,CAAE,IAAKb,GAAOW,EAAQ,CACtC,CACJ,CClHO,SAASG,GACd,CAAE,UAAAC,EAAW,UAAAC,CAAU,EACjB,CACND,EACG,KACCE,EAAU,IAAMC,EAAY,cAAc,CAAC,EAC3CC,GAASC,GAAMC,GAAuBD,CAAE,EACrC,KACCE,EAAUP,EAAU,KAAKQ,GAAK,CAAC,CAAC,CAAC,EACjCC,EAAOC,GAAWA,CAAO,EACzBC,EAAI,IAAMN,CAAE,EACZO,GAAK,CAAC,CACR,CACF,EACAH,EAAOJ,GAAMA,EAAG,YAAcA,EAAG,WAAW,EAC5CD,GAASC,GAAM,CACb,IAAMQ,EAAOR,EAAG,UACVS,EAAOT,EAAG,QAAQ,GAAG,GAAKA,EAIhC,OAHAS,EAAK,MAAQD,EAGRE,EAAQ,kBAAkB,EAIxBC,GAAoBF,EAAM,CAAE,UAAAb,CAAU,CAAC,EAC3C,KACCM,EAAUP,EAAU,KAAKQ,GAAK,CAAC,CAAC,CAAC,EACjCS,EAAS,IAAMH,EAAK,gBAAgB,OAAO,CAAC,CAC9C,EAPOI,CAQX,CAAC,CACH,EACG,UAAU,EAGXH,EAAQ,kBAAkB,GAC5Bf,EACG,KACCE,EAAU,IAAMC,EAAY,YAAY,CAAC,EACzCC,GAASC,GAAMW,GAAoBX,EAAI,CAAE,UAAAJ,CAAU,CAAC,CAAC,CACvD,EACG,UAAU,CACnB,CCpDO,SAASkB,GACd,CAAE,UAAAC,EAAW,QAAAC,CAAQ,EACf,CACND,EACG,KACCE,EAAU,IAAMC,EACd,2BACF,CAAC,EACDC,EAAIC,GAAM,CACRA,EAAG,cAAgB,GACnBA,EAAG,QAAU,EACf,CAAC,EACDC,GAASD,GAAME,EAAUF,EAAI,QAAQ,EAClC,KACCG,GAAU,IAAMH,EAAG,UAAU,SAAS,0BAA0B,CAAC,EACjEI,EAAI,IAAMJ,CAAE,CACd,CACF,EACAK,GAAeT,CAAO,CACxB,EACG,UAAU,CAAC,CAACI,EAAIM,CAAM,IAAM,CAC3BN,EAAG,UAAU,OAAO,0BAA0B,EAC1CM,IACFN,EAAG,QAAU,GACjB,CAAC,CACP,CC9BA,SAASO,IAAyB,CAChC,MAAO,qBAAqB,KAAK,UAAU,SAAS,CACtD,CAiBO,SAASC,GACd,CAAE,UAAAC,CAAU,EACN,CACNA,EACG,KACCC,EAAU,IAAMC,EAAY,qBAAqB,CAAC,EAClDC,EAAIC,GAAMA,EAAG,gBAAgB,mBAAmB,CAAC,EACjDC,EAAOP,EAAa,EACpBQ,GAASF,GAAMG,EAAUH,EAAI,YAAY,EACtC,KACCI,EAAI,IAAMJ,CAAE,CACd,CACF,CACF,EACG,UAAUA,GAAM,CACf,IAAMK,EAAML,EAAG,UAGXK,IAAQ,EACVL,EAAG,UAAY,EAGNK,EAAML,EAAG,eAAiBA,EAAG,eACtCA,EAAG,UAAYK,EAAM,EAEzB,CAAC,CACP,CCpCO,SAASC,GACd,CAAE,UAAAC,EAAW,QAAAC,CAAQ,EACf,CACNC,EAAc,CAACC,GAAY,QAAQ,EAAGF,CAAO,CAAC,EAC3C,KACCG,EAAI,CAAC,CAACC,EAAQC,CAAM,IAAMD,GAAU,CAACC,CAAM,EAC3CC,EAAUF,GAAUG,EAAGH,CAAM,EAC1B,KACCI,GAAMJ,EAAS,IAAM,GAAG,CAC1B,CACF,EACAK,GAAeV,CAAS,CAC1B,EACG,UAAU,CAAC,CAACK,EAAQ,CAAE,OAAQ,CAAE,EAAAM,CAAE,CAAC,CAAC,IAAM,CACzC,GAAIN,EACF,SAAS,KAAK,aAAa,qBAAsB,EAAE,EACnD,SAAS,KAAK,MAAM,IAAM,IAAIM,CAAC,SAC1B,CACL,IAAMC,EAAQ,GAAK,SAAS,SAAS,KAAK,MAAM,IAAK,EAAE,EACvD,SAAS,KAAK,gBAAgB,oBAAoB,EAClD,SAAS,KAAK,MAAM,IAAM,GACtBA,GACF,OAAO,SAAS,EAAGA,CAAK,CAC5B,CACF,CAAC,CACP,CC7DK,OAAO,UACV,OAAO,QAAU,SAAUC,EAAa,CACtC,IAAMC,EAA2B,CAAC,EAClC,QAAWC,KAAO,OAAO,KAAKF,CAAG,EAE/BC,EAAK,KAAK,CAACC,EAAKF,EAAIE,CAAG,CAAC,CAAC,EAG3B,OAAOD,CACT,GAGG,OAAO,SACV,OAAO,OAAS,SAAUD,EAAa,CACrC,IAAMC,EAAiB,CAAC,EACxB,QAAWC,KAAO,OAAO,KAAKF,CAAG,EAE/BC,EAAK,KAAKD,EAAIE,CAAG,CAAC,EAGpB,OAAOD,CACT,GAKE,OAAO,SAAY,cAGhB,QAAQ,UAAU,WACrB,QAAQ,UAAU,SAAW,SAC3BE,EAA8BC,EACxB,CACF,OAAOD,GAAM,UACf,KAAK,WAAaA,EAAE,KACpB,KAAK,UAAYA,EAAE,MAEnB,KAAK,WAAaA,EAClB,KAAK,UAAYC,EAErB,GAGG,QAAQ,UAAU,cACrB,QAAQ,UAAU,YAAc,YAC3BC,EACG,CACN,IAAMC,EAAS,KAAK,WACpB,GAAIA,EAAQ,CACND,EAAM,SAAW,GACnBC,EAAO,YAAY,IAAI,EAGzB,QAASC,EAAIF,EAAM,OAAS,EAAGE,GAAK,EAAGA,IAAK,CAC1C,IAAIC,EAAOH,EAAME,CAAC,EACd,OAAOC,GAAS,SAClBA,EAAO,SAAS,eAAeA,CAAI,EAC5BA,EAAK,YACZA,EAAK,WAAW,YAAYA,CAAI,EAG7BD,EAGHD,EAAO,aAAa,KAAK,gBAAkBE,CAAI,EAF/CF,EAAO,aAAaE,EAAM,IAAI,CAGlC,CACF,CACF,I3MMJ,SAASC,IAA4C,CACnD,OAAI,SAAS,WAAa,QACjBC,GACL,GAAG,IAAI,IAAI,yBAA0BC,GAAO,IAAI,CAAC,EACnD,EACG,KAECC,EAAI,IAAM,OAAO,EACjBC,EAAY,CAAC,CACf,EAEKC,GACL,IAAI,IAAI,2BAA4BH,GAAO,IAAI,CACjD,CAEJ,CAOA,SAAS,gBAAgB,UAAU,OAAO,OAAO,EACjD,SAAS,gBAAgB,UAAU,IAAI,IAAI,EAG3C,IAAMI,GAAYC,GAAc,EAC1BC,GAAYC,GAAc,EAC1BC,GAAYC,GAAoBH,EAAS,EACzCI,GAAYC,GAAc,EAG1BC,GAAYC,GAAc,EAC1BC,GAAYC,GAAW,oBAAoB,EAC3CC,GAAYD,GAAW,qBAAqB,EAC5CE,GAAYC,GAAW,EAGvBlB,GAASmB,GAAc,EACvBC,GAAS,SAAS,MAAM,UAAU,QAAQ,EAC5CtB,GAAiB,EACjBuB,GAGEC,GAAS,IAAIC,EACnBC,GAAiB,CAAE,OAAAF,EAAO,CAAC,EAG3B,IAAMG,GAAY,IAAIF,EAGlBG,EAAQ,oBAAoB,GAC9BC,GAAuB,CAAE,UAAArB,GAAW,UAAAM,GAAW,UAAAa,EAAU,CAAC,EACvD,UAAUrB,EAAS,EAzJxB,IAAAwB,KA4JIA,GAAA5B,GAAO,UAAP,YAAA4B,GAAgB,YAAa,QAC/BC,GAAqB,CAAE,UAAAzB,EAAU,CAAC,EAGpC0B,EAAMxB,GAAWE,EAAO,EACrB,KACCuB,GAAM,GAAG,CACX,EACG,UAAU,IAAM,CACfC,GAAU,SAAU,EAAK,EACzBA,GAAU,SAAU,EAAK,CAC3B,CAAC,EAGLtB,GACG,KACCuB,EAAO,CAAC,CAAE,KAAAC,CAAK,IAAMA,IAAS,QAAQ,CACxC,EACG,UAAUC,GAAO,CAChB,OAAQA,EAAI,KAAM,CAGhB,IAAK,IACL,IAAK,IACH,IAAMC,EAAOC,GAAoC,gBAAgB,EAC7D,OAAOD,GAAS,aAClBE,GAAYF,CAAI,EAClB,MAGF,IAAK,IACL,IAAK,IACH,IAAMG,EAAOF,GAAoC,gBAAgB,EAC7D,OAAOE,GAAS,aAClBD,GAAYC,CAAI,EAClB,MAGF,IAAK,QACH,IAAMC,EAASC,GAAiB,EAC5BD,aAAkB,kBACpBA,EAAO,MAAM,CACnB,CACF,CAAC,EAGLE,GAAc,CAAE,UAAA9B,GAAW,UAAAR,EAAU,CAAC,EACtCuC,GAAmB,CAAE,UAAAvC,GAAW,QAAAU,EAAQ,CAAC,EACzC8B,GAAe,CAAE,UAAAxC,EAAU,CAAC,EAC5ByC,GAAgB,CAAE,UAAAjC,GAAW,QAAAE,EAAQ,CAAC,EAGtC,IAAMgC,GAAUC,GAAYC,GAAoB,QAAQ,EAAG,CAAE,UAAApC,EAAU,CAAC,EAClEqC,GAAQ7C,GACX,KACCH,EAAI,IAAM+C,GAAoB,MAAM,CAAC,EACrCE,EAAUC,GAAMC,GAAUD,EAAI,CAAE,UAAAvC,GAAW,QAAAkC,EAAQ,CAAC,CAAC,EACrD5C,EAAY,CAAC,CACf,EAGImD,GAAWvB,EAGf,GAAGwB,GAAqB,SAAS,EAC9B,IAAIH,GAAMI,GAAaJ,EAAI,CAAE,QAAA3C,EAAQ,CAAC,CAAC,EAG1C,GAAG8C,GAAqB,QAAQ,EAC7B,IAAIH,GAAMK,GAAYL,EAAI,CAAE,OAAA7B,EAAO,CAAC,CAAC,EAGxC,GAAGgC,GAAqB,SAAS,EAC9B,IAAIH,GAAMM,GAAaN,CAAE,CAAC,EAG7B,GAAGG,GAAqB,UAAU,EAC/B,IAAIH,GAAMO,GAAcP,EAAI,CAAE,UAAA1B,EAAU,CAAC,CAAC,EAG7C,GAAG6B,GAAqB,QAAQ,EAC7B,IAAIH,GAAMQ,GAAYR,EAAI,CAAE,OAAA/B,GAAQ,UAAAV,EAAU,CAAC,CAAC,EAGnD,GAAG4C,GAAqB,QAAQ,EAC7B,IAAIH,GAAMS,GAAYT,CAAE,CAAC,CAC9B,EAGMU,GAAWC,EAAM,IAAMhC,EAG3B,GAAGwB,GAAqB,UAAU,EAC/B,IAAIH,GAAMY,GAAcZ,CAAE,CAAC,EAG9B,GAAGG,GAAqB,SAAS,EAC9B,IAAIH,GAAMa,GAAab,EAAI,CAAE,UAAAvC,GAAW,QAAAJ,GAAS,OAAAS,EAAO,CAAC,CAAC,EAG7D,GAAGqC,GAAqB,SAAS,EAC9B,IAAIH,GAAMzB,EAAQ,kBAAkB,EACjCuC,GAAoBd,EAAI,CAAE,OAAA/B,GAAQ,UAAAd,EAAU,CAAC,EAC7C4D,CACJ,EAGF,GAAGZ,GAAqB,QAAQ,EAC7B,IAAIH,GAAMgB,GAAYhB,EAAI,CAAE,UAAAvC,GAAW,QAAAkC,GAAS,MAAAG,EAAM,CAAC,CAAC,EAG3D,GAAGK,GAAqB,cAAc,EACnC,IAAIH,GAAMiB,GAAiBjB,EAAI,CAAE,UAAAvC,GAAW,QAAAkC,EAAQ,CAAC,CAAC,EAGzD,GAAGQ,GAAqB,SAAS,EAC9B,IAAIH,GAAMA,EAAG,aAAa,cAAc,IAAM,aAC3CkB,GAAGrD,GAAS,IAAMsD,GAAanB,EAAI,CAAE,UAAAvC,GAAW,QAAAkC,GAAS,MAAAG,EAAM,CAAC,CAAC,EACjEoB,GAAGvD,GAAS,IAAMwD,GAAanB,EAAI,CAAE,UAAAvC,GAAW,QAAAkC,GAAS,MAAAG,EAAM,CAAC,CAAC,CACrE,EAGF,GAAGK,GAAqB,MAAM,EAC3B,IAAIH,GAAMoB,GAAUpB,EAAI,CAAE,UAAAvC,GAAW,QAAAkC,EAAQ,CAAC,CAAC,EAGlD,GAAGQ,GAAqB,KAAK,EAC1B,IAAIH,GAAMqB,GAAqBrB,EAAI,CAClC,UAAAvC,GAAW,QAAAkC,GAAS,MAAAG,GAAO,QAAAzC,EAC7B,CAAC,CAAC,EAGJ,GAAG8C,GAAqB,KAAK,EAC1B,IAAIH,GAAMsB,GAAetB,EAAI,CAAE,UAAAvC,GAAW,QAAAkC,GAAS,MAAAG,GAAO,QAAAzC,EAAQ,CAAC,CAAC,CACzE,CAAC,EAGKkE,GAAatE,GAChB,KACC8C,EAAU,IAAMW,EAAQ,EACxBc,GAAUtB,EAAQ,EAClBnD,EAAY,CAAC,CACf,EAGFwE,GAAW,UAAU,EAMrB,OAAO,UAAatE,GACpB,OAAO,UAAaE,GACpB,OAAO,QAAaE,GACpB,OAAO,UAAaE,GACpB,OAAO,UAAaE,GACpB,OAAO,QAAaE,GACpB,OAAO,QAAaE,GACpB,OAAO,OAAaC,GACpB,OAAO,OAAaK,GACpB,OAAO,UAAaG,GACpB,OAAO,WAAaiD",
+  "names": ["require_focus_visible", "__commonJSMin", "exports", "module", "global", "factory", "applyFocusVisiblePolyfill", "scope", "hadKeyboardEvent", "hadFocusVisibleRecently", "hadFocusVisibleRecentlyTimeout", "inputTypesAllowlist", "isValidFocusTarget", "el", "focusTriggersKeyboardModality", "type", "tagName", "addFocusVisibleClass", "removeFocusVisibleClass", "onKeyDown", "e", "onPointerDown", "onFocus", "onBlur", "onVisibilityChange", "addInitialPointerMoveListeners", "onInitialPointerMove", "removeInitialPointerMoveListeners", "event", "error", "require_escape_html", "__commonJSMin", "exports", "module", "matchHtmlRegExp", "escapeHtml", "string", "str", "match", "escape", "html", "index", "lastIndex", "require_clipboard", "__commonJSMin", "exports", "module", "root", "factory", "__webpack_modules__", "__unused_webpack_module", "__webpack_exports__", "__webpack_require__", "clipboard", "tiny_emitter", "tiny_emitter_default", "listen", "listen_default", "src_select", "select_default", "command", "type", "err", "ClipboardActionCut", "target", "selectedText", "actions_cut", "createFakeElement", "value", "isRTL", "fakeElement", "yPosition", "fakeCopyAction", "options", "ClipboardActionCopy", "actions_copy", "_typeof", "obj", "ClipboardActionDefault", "_options$action", "action", "container", "text", "actions_default", "clipboard_typeof", "_classCallCheck", "instance", "Constructor", "_defineProperties", "props", "i", "descriptor", "_createClass", "protoProps", "staticProps", "_inherits", "subClass", "superClass", "_setPrototypeOf", "o", "p", "_createSuper", "Derived", "hasNativeReflectConstruct", "_isNativeReflectConstruct", "Super", "_getPrototypeOf", "result", "NewTarget", "_possibleConstructorReturn", "self", "call", "_assertThisInitialized", "e", "getAttributeValue", "suffix", "element", "attribute", "Clipboard", "_Emitter", "_super", "trigger", "_this", "_this2", "selector", "actions", "support", "DOCUMENT_NODE_TYPE", "proto", "closest", "__unused_webpack_exports", "_delegate", "callback", "useCapture", "listenerFn", "listener", "delegate", "elements", "is", "listenNode", "listenNodeList", "listenSelector", "node", "nodeList", "select", "isReadOnly", "selection", "range", "E", "name", "ctx", "data", "evtArr", "len", "evts", "liveEvents", "__webpack_module_cache__", "moduleId", "getter", "definition", "key", "prop", "import_focus_visible", "extendStatics", "d", "b", "p", "__extends", "__", "__awaiter", "thisArg", "_arguments", "P", "generator", "adopt", "value", "resolve", "reject", "fulfilled", "step", "e", "rejected", "result", "__generator", "body", "_", "t", "f", "y", "g", "verb", "n", "v", "op", "__values", "o", "s", "m", "i", "__read", "n", "r", "ar", "e", "error", "__spreadArray", "to", "from", "pack", "i", "l", "ar", "__await", "v", "__asyncGenerator", "thisArg", "_arguments", "generator", "g", "q", "verb", "awaitReturn", "f", "reject", "n", "a", "b", "resume", "step", "e", "settle", "r", "fulfill", "value", "__asyncValues", "o", "m", "i", "__values", "verb", "n", "v", "resolve", "reject", "settle", "d", "isFunction", "value", "createErrorClass", "createImpl", "_super", "instance", "ctorFunc", "UnsubscriptionError", "createErrorClass", "_super", "errors", "err", "i", "arrRemove", "arr", "item", "index", "Subscription", "initialTeardown", "errors", "_parentage", "_parentage_1", "__values", "_parentage_1_1", "parent_1", "initialFinalizer", "isFunction", "e", "UnsubscriptionError", "_finalizers", "_finalizers_1", "_finalizers_1_1", "finalizer", "execFinalizer", "err", "__spreadArray", "__read", "teardown", "_a", "parent", "arrRemove", "empty", "EMPTY_SUBSCRIPTION", "Subscription", "isSubscription", "value", "isFunction", "execFinalizer", "finalizer", "config", "timeoutProvider", "handler", "timeout", "args", "_i", "delegate", "__spreadArray", "__read", "handle", "reportUnhandledError", "err", "timeoutProvider", "onUnhandledError", "config", "noop", "COMPLETE_NOTIFICATION", "createNotification", "errorNotification", "error", "nextNotification", "value", "kind", "context", "errorContext", "cb", "config", "isRoot", "_a", "errorThrown", "error", "captureError", "err", "Subscriber", "_super", "__extends", "destination", "_this", "isSubscription", "EMPTY_OBSERVER", "next", "error", "complete", "SafeSubscriber", "value", "handleStoppedNotification", "nextNotification", "err", "errorNotification", "COMPLETE_NOTIFICATION", "Subscription", "_bind", "bind", "fn", "thisArg", "ConsumerObserver", "partialObserver", "value", "error", "handleUnhandledError", "err", "SafeSubscriber", "_super", "__extends", "observerOrNext", "complete", "_this", "isFunction", "context_1", "config", "Subscriber", "handleUnhandledError", "error", "config", "captureError", "reportUnhandledError", "defaultErrorHandler", "err", "handleStoppedNotification", "notification", "subscriber", "onStoppedNotification", "timeoutProvider", "EMPTY_OBSERVER", "noop", "observable", "identity", "x", "pipe", "fns", "_i", "pipeFromArray", "identity", "input", "prev", "fn", "Observable", "subscribe", "operator", "observable", "observerOrNext", "error", "complete", "_this", "subscriber", "isSubscriber", "SafeSubscriber", "errorContext", "_a", "source", "sink", "err", "next", "promiseCtor", "getPromiseCtor", "resolve", "reject", "value", "operations", "_i", "pipeFromArray", "x", "getPromiseCtor", "promiseCtor", "_a", "config", "isObserver", "value", "isFunction", "isSubscriber", "Subscriber", "isSubscription", "hasLift", "source", "isFunction", "operate", "init", "liftedSource", "err", "createOperatorSubscriber", "destination", "onNext", "onComplete", "onError", "onFinalize", "OperatorSubscriber", "_super", "__extends", "shouldUnsubscribe", "_this", "value", "err", "closed_1", "_a", "Subscriber", "animationFrameProvider", "callback", "request", "cancel", "delegate", "handle", "timestamp", "Subscription", "args", "_i", "__spreadArray", "__read", "ObjectUnsubscribedError", "createErrorClass", "_super", "Subject", "_super", "__extends", "_this", "operator", "subject", "AnonymousSubject", "ObjectUnsubscribedError", "value", "errorContext", "_b", "__values", "_c", "observer", "err", "observers", "_a", "subscriber", "hasError", "isStopped", "EMPTY_SUBSCRIPTION", "Subscription", "arrRemove", "thrownError", "observable", "Observable", "destination", "source", "AnonymousSubject", "_super", "__extends", "destination", "source", "_this", "value", "_b", "_a", "err", "subscriber", "EMPTY_SUBSCRIPTION", "Subject", "BehaviorSubject", "_super", "__extends", "_value", "_this", "subscriber", "subscription", "_a", "hasError", "thrownError", "value", "Subject", "dateTimestampProvider", "ReplaySubject", "_super", "__extends", "_bufferSize", "_windowTime", "_timestampProvider", "dateTimestampProvider", "_this", "value", "_a", "isStopped", "_buffer", "_infiniteTimeWindow", "subscriber", "subscription", "copy", "i", "adjustedBufferSize", "now", "last", "Subject", "Action", "_super", "__extends", "scheduler", "work", "state", "delay", "Subscription", "intervalProvider", "handler", "timeout", "args", "_i", "delegate", "__spreadArray", "__read", "handle", "AsyncAction", "_super", "__extends", "scheduler", "work", "_this", "state", "delay", "id", "_a", "_id", "intervalProvider", "_scheduler", "error", "_delay", "errored", "errorValue", "e", "actions", "arrRemove", "Action", "Scheduler", "schedulerActionCtor", "now", "work", "delay", "state", "dateTimestampProvider", "AsyncScheduler", "_super", "__extends", "SchedulerAction", "now", "Scheduler", "_this", "action", "actions", "error", "asyncScheduler", "AsyncScheduler", "AsyncAction", "async", "QueueAction", "_super", "__extends", "scheduler", "work", "_this", "state", "delay", "id", "AsyncAction", "QueueScheduler", "_super", "__extends", "AsyncScheduler", "queueScheduler", "QueueScheduler", "QueueAction", "AnimationFrameAction", "_super", "__extends", "scheduler", "work", "_this", "id", "delay", "animationFrameProvider", "actions", "_a", "AsyncAction", "AnimationFrameScheduler", "_super", "__extends", "action", "flushId", "actions", "error", "AsyncScheduler", "animationFrameScheduler", "AnimationFrameScheduler", "AnimationFrameAction", "EMPTY", "Observable", "subscriber", "isScheduler", "value", "isFunction", "last", "arr", "popResultSelector", "args", "isFunction", "popScheduler", "isScheduler", "popNumber", "defaultValue", "isArrayLike", "x", "isPromise", "value", "isFunction", "isInteropObservable", "input", "isFunction", "observable", "isAsyncIterable", "obj", "isFunction", "createInvalidObservableTypeError", "input", "getSymbolIterator", "iterator", "isIterable", "input", "isFunction", "iterator", "readableStreamLikeToAsyncGenerator", "readableStream", "reader", "__await", "_a", "_b", "value", "done", "isReadableStreamLike", "obj", "isFunction", "innerFrom", "input", "Observable", "isInteropObservable", "fromInteropObservable", "isArrayLike", "fromArrayLike", "isPromise", "fromPromise", "isAsyncIterable", "fromAsyncIterable", "isIterable", "fromIterable", "isReadableStreamLike", "fromReadableStreamLike", "createInvalidObservableTypeError", "obj", "subscriber", "obs", "observable", "isFunction", "array", "i", "promise", "value", "err", "reportUnhandledError", "iterable", "iterable_1", "__values", "iterable_1_1", "asyncIterable", "process", "readableStream", "readableStreamLikeToAsyncGenerator", "asyncIterable_1", "__asyncValues", "asyncIterable_1_1", "executeSchedule", "parentSubscription", "scheduler", "work", "delay", "repeat", "scheduleSubscription", "observeOn", "scheduler", "delay", "operate", "source", "subscriber", "createOperatorSubscriber", "value", "executeSchedule", "err", "subscribeOn", "scheduler", "delay", "operate", "source", "subscriber", "scheduleObservable", "input", "scheduler", "innerFrom", "subscribeOn", "observeOn", "schedulePromise", "input", "scheduler", "innerFrom", "subscribeOn", "observeOn", "scheduleArray", "input", "scheduler", "Observable", "subscriber", "i", "scheduleIterable", "input", "scheduler", "Observable", "subscriber", "iterator", "executeSchedule", "value", "done", "_a", "err", "isFunction", "scheduleAsyncIterable", "input", "scheduler", "Observable", "subscriber", "executeSchedule", "iterator", "result", "scheduleReadableStreamLike", "input", "scheduler", "scheduleAsyncIterable", "readableStreamLikeToAsyncGenerator", "scheduled", "input", "scheduler", "isInteropObservable", "scheduleObservable", "isArrayLike", "scheduleArray", "isPromise", "schedulePromise", "isAsyncIterable", "scheduleAsyncIterable", "isIterable", "scheduleIterable", "isReadableStreamLike", "scheduleReadableStreamLike", "createInvalidObservableTypeError", "from", "input", "scheduler", "scheduled", "innerFrom", "of", "args", "_i", "scheduler", "popScheduler", "from", "throwError", "errorOrErrorFactory", "scheduler", "errorFactory", "isFunction", "init", "subscriber", "Observable", "EmptyError", "createErrorClass", "_super", "isValidDate", "value", "map", "project", "thisArg", "operate", "source", "subscriber", "index", "createOperatorSubscriber", "value", "isArray", "callOrApply", "fn", "args", "__spreadArray", "__read", "mapOneOrManyArgs", "map", "isArray", "getPrototypeOf", "objectProto", "getKeys", "argsArgArrayOrObject", "args", "first_1", "isPOJO", "keys", "key", "obj", "createObject", "keys", "values", "result", "key", "i", "combineLatest", "args", "_i", "scheduler", "popScheduler", "resultSelector", "popResultSelector", "_a", "argsArgArrayOrObject", "observables", "keys", "from", "result", "Observable", "combineLatestInit", "values", "createObject", "identity", "mapOneOrManyArgs", "valueTransform", "subscriber", "maybeSchedule", "length", "active", "remainingFirstValues", "i", "source", "hasFirstValue", "createOperatorSubscriber", "value", "execute", "subscription", "executeSchedule", "mergeInternals", "source", "subscriber", "project", "concurrent", "onBeforeNext", "expand", "innerSubScheduler", "additionalFinalizer", "buffer", "active", "index", "isComplete", "checkComplete", "outerNext", "value", "doInnerSub", "innerComplete", "innerFrom", "createOperatorSubscriber", "innerValue", "bufferedValue", "executeSchedule", "err", "mergeMap", "project", "resultSelector", "concurrent", "isFunction", "a", "i", "map", "b", "ii", "innerFrom", "operate", "source", "subscriber", "mergeInternals", "mergeAll", "concurrent", "mergeMap", "identity", "concatAll", "mergeAll", "concat", "args", "_i", "concatAll", "from", "popScheduler", "defer", "observableFactory", "Observable", "subscriber", "innerFrom", "nodeEventEmitterMethods", "eventTargetMethods", "jqueryMethods", "fromEvent", "target", "eventName", "options", "resultSelector", "isFunction", "mapOneOrManyArgs", "_a", "__read", "isEventTarget", "methodName", "handler", "isNodeStyleEventEmitter", "toCommonHandlerRegistry", "isJQueryStyleEventEmitter", "add", "remove", "isArrayLike", "mergeMap", "subTarget", "innerFrom", "Observable", "subscriber", "args", "_i", "fromEventPattern", "addHandler", "removeHandler", "resultSelector", "mapOneOrManyArgs", "Observable", "subscriber", "handler", "e", "_i", "retValue", "isFunction", "timer", "dueTime", "intervalOrScheduler", "scheduler", "async", "intervalDuration", "isScheduler", "Observable", "subscriber", "due", "isValidDate", "n", "merge", "args", "_i", "scheduler", "popScheduler", "concurrent", "popNumber", "sources", "innerFrom", "mergeAll", "from", "EMPTY", "NEVER", "Observable", "noop", "isArray", "argsOrArgArray", "args", "filter", "predicate", "thisArg", "operate", "source", "subscriber", "index", "createOperatorSubscriber", "value", "zip", "args", "_i", "resultSelector", "popResultSelector", "sources", "argsOrArgArray", "Observable", "subscriber", "buffers", "completed", "sourceIndex", "innerFrom", "createOperatorSubscriber", "value", "buffer", "result", "__spreadArray", "__read", "i", "EMPTY", "audit", "durationSelector", "operate", "source", "subscriber", "hasValue", "lastValue", "durationSubscriber", "isComplete", "endDuration", "value", "cleanupDuration", "createOperatorSubscriber", "innerFrom", "auditTime", "duration", "scheduler", "asyncScheduler", "audit", "timer", "bufferCount", "bufferSize", "startBufferEvery", "operate", "source", "subscriber", "buffers", "count", "createOperatorSubscriber", "value", "toEmit", "buffers_1", "__values", "buffers_1_1", "buffer", "toEmit_1", "toEmit_1_1", "arrRemove", "buffers_2", "buffers_2_1", "catchError", "selector", "operate", "source", "subscriber", "innerSub", "syncUnsub", "handledResult", "createOperatorSubscriber", "err", "innerFrom", "scanInternals", "accumulator", "seed", "hasSeed", "emitOnNext", "emitBeforeComplete", "source", "subscriber", "hasState", "state", "index", "createOperatorSubscriber", "value", "i", "combineLatest", "args", "_i", "resultSelector", "popResultSelector", "pipe", "__spreadArray", "__read", "mapOneOrManyArgs", "operate", "source", "subscriber", "combineLatestInit", "argsOrArgArray", "combineLatestWith", "otherSources", "_i", "combineLatest", "__spreadArray", "__read", "debounce", "durationSelector", "operate", "source", "subscriber", "hasValue", "lastValue", "durationSubscriber", "emit", "value", "createOperatorSubscriber", "noop", "innerFrom", "debounceTime", "dueTime", "scheduler", "asyncScheduler", "operate", "source", "subscriber", "activeTask", "lastValue", "lastTime", "emit", "value", "emitWhenIdle", "targetTime", "now", "createOperatorSubscriber", "defaultIfEmpty", "defaultValue", "operate", "source", "subscriber", "hasValue", "createOperatorSubscriber", "value", "take", "count", "EMPTY", "operate", "source", "subscriber", "seen", "createOperatorSubscriber", "value", "ignoreElements", "operate", "source", "subscriber", "createOperatorSubscriber", "noop", "mapTo", "value", "map", "delayWhen", "delayDurationSelector", "subscriptionDelay", "source", "concat", "take", "ignoreElements", "mergeMap", "value", "index", "innerFrom", "mapTo", "delay", "due", "scheduler", "asyncScheduler", "duration", "timer", "delayWhen", "distinctUntilChanged", "comparator", "keySelector", "identity", "defaultCompare", "operate", "source", "subscriber", "previousKey", "first", "createOperatorSubscriber", "value", "currentKey", "a", "b", "distinctUntilKeyChanged", "key", "compare", "distinctUntilChanged", "x", "y", "throwIfEmpty", "errorFactory", "defaultErrorFactory", "operate", "source", "subscriber", "hasValue", "createOperatorSubscriber", "value", "EmptyError", "endWith", "values", "_i", "source", "concat", "of", "__spreadArray", "__read", "finalize", "callback", "operate", "source", "subscriber", "first", "predicate", "defaultValue", "hasDefaultValue", "source", "filter", "v", "identity", "take", "defaultIfEmpty", "throwIfEmpty", "EmptyError", "takeLast", "count", "EMPTY", "operate", "source", "subscriber", "buffer", "createOperatorSubscriber", "value", "buffer_1", "__values", "buffer_1_1", "merge", "args", "_i", "scheduler", "popScheduler", "concurrent", "popNumber", "argsOrArgArray", "operate", "source", "subscriber", "mergeAll", "from", "__spreadArray", "__read", "mergeWith", "otherSources", "_i", "merge", "__spreadArray", "__read", "repeat", "countOrConfig", "count", "delay", "_a", "EMPTY", "operate", "source", "subscriber", "soFar", "sourceSub", "resubscribe", "notifier", "timer", "innerFrom", "notifierSubscriber_1", "createOperatorSubscriber", "subscribeToSource", "syncUnsub", "scan", "accumulator", "seed", "operate", "scanInternals", "share", "options", "_a", "connector", "Subject", "_b", "resetOnError", "_c", "resetOnComplete", "_d", "resetOnRefCountZero", "wrapperSource", "connection", "resetConnection", "subject", "refCount", "hasCompleted", "hasErrored", "cancelReset", "reset", "resetAndUnsubscribe", "conn", "operate", "source", "subscriber", "dest", "handleReset", "SafeSubscriber", "value", "err", "innerFrom", "on", "args", "_i", "onSubscriber", "__spreadArray", "__read", "shareReplay", "configOrBufferSize", "windowTime", "scheduler", "bufferSize", "refCount", "_a", "_b", "_c", "share", "ReplaySubject", "skip", "count", "filter", "_", "index", "skipUntil", "notifier", "operate", "source", "subscriber", "taking", "skipSubscriber", "createOperatorSubscriber", "noop", "innerFrom", "value", "startWith", "values", "_i", "scheduler", "popScheduler", "operate", "source", "subscriber", "concat", "switchMap", "project", "resultSelector", "operate", "source", "subscriber", "innerSubscriber", "index", "isComplete", "checkComplete", "createOperatorSubscriber", "value", "innerIndex", "outerIndex", "innerFrom", "innerValue", "takeUntil", "notifier", "operate", "source", "subscriber", "innerFrom", "createOperatorSubscriber", "noop", "takeWhile", "predicate", "inclusive", "operate", "source", "subscriber", "index", "createOperatorSubscriber", "value", "result", "tap", "observerOrNext", "error", "complete", "tapObserver", "isFunction", "operate", "source", "subscriber", "_a", "isUnsub", "createOperatorSubscriber", "value", "err", "_b", "identity", "throttle", "durationSelector", "config", "operate", "source", "subscriber", "_a", "_b", "leading", "_c", "trailing", "hasValue", "sendValue", "throttled", "isComplete", "endThrottling", "send", "cleanupThrottling", "startThrottle", "value", "innerFrom", "createOperatorSubscriber", "throttleTime", "duration", "scheduler", "config", "asyncScheduler", "duration$", "timer", "throttle", "withLatestFrom", "inputs", "_i", "project", "popResultSelector", "operate", "source", "subscriber", "len", "otherValues", "hasValue", "ready", "i", "innerFrom", "createOperatorSubscriber", "value", "identity", "noop", "values", "__spreadArray", "__read", "zip", "sources", "_i", "operate", "source", "subscriber", "__spreadArray", "__read", "zipWith", "otherInputs", "_i", "zip", "__spreadArray", "__read", "watchDocument", "document$", "ReplaySubject", "fromEvent", "getElements", "selector", "node", "getElement", "el", "getOptionalElement", "getActiveElement", "_a", "_b", "_c", "_d", "observer$", "merge", "fromEvent", "debounceTime", "startWith", "map", "getActiveElement", "shareReplay", "watchElementFocus", "el", "active", "distinctUntilChanged", "watchElementHover", "el", "timeout", "defer", "merge", "fromEvent", "map", "debounce", "active", "timer", "identity", "startWith", "appendChild", "el", "child", "node", "h", "tag", "attributes", "children", "attr", "round", "value", "digits", "watchScript", "src", "script", "h", "defer", "merge", "fromEvent", "switchMap", "throwError", "map", "finalize", "take", "entry$", "Subject", "observer$", "defer", "watchScript", "of", "map", "entries", "entry", "switchMap", "observer", "merge", "NEVER", "finalize", "shareReplay", "getElementSize", "el", "watchElementSize", "target", "tap", "filter", "startWith", "getElementContentSize", "el", "getElementContainer", "parent", "getElementContainers", "containers", "getElementOffset", "el", "getElementOffsetAbsolute", "rect", "watchElementOffset", "merge", "fromEvent", "auditTime", "animationFrameScheduler", "map", "startWith", "getElementContentOffset", "el", "watchElementContentOffset", "merge", "fromEvent", "auditTime", "animationFrameScheduler", "map", "startWith", "entry$", "Subject", "observer$", "defer", "of", "entries", "entry", "switchMap", "observer", "merge", "NEVER", "finalize", "shareReplay", "watchElementVisibility", "el", "tap", "filter", "target", "map", "isIntersecting", "watchElementBoundary", "threshold", "watchElementContentOffset", "y", "visible", "getElementSize", "content", "getElementContentSize", "distinctUntilChanged", "toggles", "getElement", "getToggle", "name", "setToggle", "value", "watchToggle", "el", "fromEvent", "map", "startWith", "isSusceptibleToKeyboard", "el", "type", "watchComposition", "merge", "fromEvent", "map", "startWith", "watchKeyboard", "keyboard$", "filter", "ev", "getToggle", "mode", "active", "getActiveElement", "share", "switchMap", "EMPTY", "getLocation", "setLocation", "url", "navigate", "feature", "el", "h", "watchLocation", "Subject", "getLocationHash", "setLocationHash", "hash", "el", "h", "ev", "watchLocationHash", "location$", "merge", "fromEvent", "map", "startWith", "filter", "shareReplay", "watchLocationTarget", "id", "getOptionalElement", "watchMedia", "query", "media", "fromEventPattern", "next", "startWith", "watchPrint", "merge", "fromEvent", "map", "at", "query$", "factory", "switchMap", "active", "EMPTY", "request", "url", "options", "Observable", "observer", "req", "event", "_a", "length", "requestJSON", "switchMap", "res", "map", "body", "shareReplay", "requestHTML", "dom", "requestXML", "getViewportOffset", "watchViewportOffset", "merge", "fromEvent", "map", "startWith", "getViewportSize", "watchViewportSize", "fromEvent", "map", "startWith", "watchViewport", "combineLatest", "watchViewportOffset", "watchViewportSize", "map", "offset", "size", "shareReplay", "watchViewportAt", "el", "viewport$", "header$", "size$", "distinctUntilKeyChanged", "offset$", "combineLatest", "map", "getElementOffset", "height", "offset", "size", "x", "y", "recv", "worker", "fromEvent", "ev", "send", "send$", "Subject", "data", "watchWorker", "url", "recv$", "worker$", "done$", "ignoreElements", "endWith", "mergeWith", "takeUntil", "share", "script", "getElement", "config", "getLocation", "configuration", "feature", "flag", "translation", "key", "value", "getComponentElement", "type", "node", "getElement", "getComponentElements", "getElements", "watchAnnounce", "el", "button", "getElement", "fromEvent", "map", "content", "mountAnnounce", "feature", "EMPTY", "defer", "push$", "Subject", "hash", "tap", "state", "finalize", "__spreadValues", "watchConsent", "el", "target$", "map", "target", "mountConsent", "options", "internal$", "Subject", "hidden", "tap", "state", "finalize", "__spreadValues", "renderTooltip", "id", "style", "h", "renderInlineTooltip2", "children", "renderAnnotation", "id", "prefix", "anchor", "h", "renderTooltip", "renderClipboardButton", "id", "h", "translation", "import_escape_html", "renderSearchDocument", "document", "flag", "parent", "teaser", "missing", "key", "list", "h", "escapeHTML", "config", "configuration", "url", "feature", "match", "highlight", "value", "tags", "tag", "type", "translation", "renderSearchResultItem", "result", "threshold", "docs", "doc", "article", "index", "best", "more", "children", "section", "renderSourceFacts", "facts", "h", "key", "value", "round", "renderTabbedControl", "type", "classes", "h", "renderTable", "table", "h", "renderVersion", "version", "_a", "config", "configuration", "url", "h", "renderVersionSelector", "versions", "active", "translation", "sequence", "watchTooltip2", "el", "active$", "combineLatest", "watchElementFocus", "watchElementHover", "map", "focus", "hover", "distinctUntilChanged", "offset$", "defer", "getElementContainers", "mergeMap", "watchElementContentOffset", "throttleTime", "combineLatestWith", "getElementOffsetAbsolute", "first", "active", "switchMap", "offset", "share", "mountTooltip2", "dependencies", "content$", "viewport$", "id", "push$", "Subject", "show$", "BehaviorSubject", "ignoreElements", "endWith", "node$", "debounce", "timer", "queueScheduler", "EMPTY", "tap", "node", "startWith", "states", "origin$", "filter", "withLatestFrom", "_", "size", "host", "x", "height", "getElementSize", "origin", "getElement", "observeOn", "animationFrameScheduler", "state", "finalize", "__spreadValues", "mountInlineTooltip2", "container", "Observable", "observer", "title", "renderInlineTooltip2", "watchAnnotation", "el", "container", "offset$", "defer", "combineLatest", "watchElementOffset", "watchElementContentOffset", "map", "x", "y", "scroll", "width", "height", "getElementSize", "watchElementFocus", "switchMap", "active", "offset", "take", "mountAnnotation", "target$", "tooltip", "index", "push$", "Subject", "done$", "ignoreElements", "endWith", "watchElementVisibility", "takeUntil", "visible", "merge", "filter", "debounceTime", "auditTime", "animationFrameScheduler", "throttleTime", "origin", "fromEvent", "ev", "withLatestFrom", "_a", "parent", "getActiveElement", "target", "delay", "tap", "state", "finalize", "__spreadValues", "findHosts", "container", "getElements", "findMarkers", "markers", "el", "nodes", "it", "node", "text", "match", "id", "force", "marker", "swap", "source", "target", "mountAnnotationList", "target$", "print$", "parent", "prefix", "annotations", "getOptionalElement", "renderAnnotation", "EMPTY", "defer", "push$", "Subject", "done$", "ignoreElements", "endWith", "pairs", "annotation", "getElement", "takeUntil", "active", "inner", "child", "merge", "mountAnnotation", "finalize", "share", "findList", "el", "sibling", "mountAnnotationBlock", "options", "defer", "list", "mountAnnotationList", "EMPTY", "import_clipboard", "sequence", "findCandidateList", "el", "sibling", "watchCodeBlock", "watchElementSize", "map", "width", "getElementContentSize", "distinctUntilKeyChanged", "mountCodeBlock", "options", "hover", "factory$", "defer", "push$", "Subject", "done$", "takeLast", "scrollable", "content$", "ClipboardJS", "feature", "parent", "button", "renderClipboardButton", "mountInlineTooltip2", "container", "list", "annotations$", "mountAnnotationList", "takeUntil", "height", "distinctUntilChanged", "switchMap", "active", "EMPTY", "getElements", "tap", "state", "finalize", "__spreadValues", "mergeWith", "watchElementVisibility", "filter", "visible", "take", "watchDetails", "el", "target$", "print$", "open", "merge", "map", "target", "filter", "details", "active", "tap", "mountDetails", "options", "defer", "push$", "Subject", "action", "reveal", "state", "finalize", "__spreadValues", "mermaid_default", "mermaid$", "sequence", "fetchScripts", "watchScript", "of", "mountMermaid", "el", "tap", "mermaid_default", "map", "shareReplay", "__async", "id", "host", "h", "text", "svg", "fn", "shadow", "sentinel", "h", "mountDataTable", "el", "renderTable", "of", "watchContentTabs", "inputs", "initial", "input", "merge", "fromEvent", "map", "getElement", "startWith", "active", "mountContentTabs", "el", "viewport$", "target$", "container", "getElements", "prev", "renderTabbedControl", "next", "defer", "push$", "Subject", "done$", "ignoreElements", "endWith", "combineLatest", "watchElementSize", "watchElementVisibility", "takeUntil", "auditTime", "animationFrameScheduler", "size", "offset", "getElementOffset", "width", "getElementSize", "content", "getElementContentOffset", "watchElementContentOffset", "getElementContentSize", "direction", "filter", "label", "h", "ev", "tap", "feature", "skip", "withLatestFrom", "tab", "y", "set", "tabs", "media", "state", "finalize", "__spreadValues", "subscribeOn", "asyncScheduler", "mountContent", "el", "viewport$", "target$", "print$", "merge", "getElements", "child", "mountAnnotationBlock", "mountCodeBlock", "mountMermaid", "mountDataTable", "mountDetails", "mountContentTabs", "feature", "mountInlineTooltip2", "watchDialog", "_el", "alert$", "switchMap", "message", "merge", "of", "delay", "map", "active", "mountDialog", "el", "options", "inner", "getElement", "defer", "push$", "Subject", "tap", "state", "finalize", "__spreadValues", "sequence", "watchTooltip", "el", "host", "width", "getElementSize", "container", "getElementContainer", "scroll$", "watchElementContentOffset", "of", "active$", "merge", "watchElementFocus", "watchElementHover", "distinctUntilChanged", "combineLatest", "map", "active", "scroll", "x", "y", "getElementOffset", "size", "table", "mountTooltip", "title", "EMPTY", "id", "tooltip", "renderTooltip", "typeset", "getElement", "defer", "push$", "Subject", "offset", "filter", "debounceTime", "auditTime", "animationFrameScheduler", "throttleTime", "origin", "tap", "state", "finalize", "__spreadValues", "subscribeOn", "asyncScheduler", "isHidden", "viewport$", "feature", "of", "direction$", "map", "y", "bufferCount", "a", "b", "distinctUntilKeyChanged", "hidden$", "combineLatest", "filter", "offset", "direction", "distinctUntilChanged", "search$", "watchToggle", "search", "switchMap", "active", "startWith", "watchHeader", "el", "options", "defer", "watchElementSize", "height", "hidden", "shareReplay", "mountHeader", "header$", "main$", "push$", "Subject", "done$", "ignoreElements", "endWith", "combineLatestWith", "tooltips", "from", "getElements", "mergeMap", "child", "mountTooltip", "takeUntil", "state", "__spreadValues", "mergeWith", "watchHeaderTitle", "el", "viewport$", "header$", "watchViewportAt", "map", "y", "height", "getElementSize", "distinctUntilKeyChanged", "mountHeaderTitle", "options", "defer", "push$", "Subject", "active", "heading", "getOptionalElement", "EMPTY", "tap", "state", "finalize", "__spreadValues", "watchMain", "el", "viewport$", "header$", "adjust$", "map", "height", "distinctUntilChanged", "border$", "switchMap", "watchElementSize", "distinctUntilKeyChanged", "combineLatest", "header", "top", "bottom", "y", "a", "b", "watchPalette", "inputs", "current", "input", "index", "of", "mergeMap", "fromEvent", "map", "startWith", "shareReplay", "mountPalette", "el", "getElements", "meta", "h", "scheme", "media$", "watchMedia", "defer", "push$", "Subject", "palette", "media", "key", "value", "label", "filter", "ev", "withLatestFrom", "_", "header", "getComponentElement", "style", "color", "observeOn", "asyncScheduler", "takeUntil", "skip", "repeat", "tap", "state", "finalize", "__spreadValues", "mountProgress", "el", "progress$", "defer", "push$", "Subject", "value", "tap", "finalize", "map", "import_clipboard", "extract", "el", "copy", "text", "setupClipboardJS", "alert$", "ClipboardJS", "Observable", "subscriber", "getElement", "ev", "tap", "map", "translation", "resolve", "url", "base", "extract", "document", "sitemap", "el", "getElements", "getElement", "links", "link", "href", "fetchSitemap", "requestXML", "map", "catchError", "of", "handle", "ev", "sitemap", "EMPTY", "el", "url", "of", "head", "document", "tags", "getElements", "resolve", "key", "value", "inject", "next", "selector", "feature", "source", "getOptionalElement", "target", "html", "name", "container", "getComponentElement", "concat", "switchMap", "script", "Observable", "observer", "ignoreElements", "endWith", "setupInstantNavigation", "location$", "viewport$", "progress$", "config", "configuration", "sitemap$", "fetchSitemap", "instant$", "fromEvent", "combineLatestWith", "share", "history$", "map", "getLocation", "withLatestFrom", "offset", "merge", "document$", "distinctUntilKeyChanged", "requestHTML", "catchError", "setLocation", "_", "distinctUntilChanged", "a", "b", "tap", "_a", "_b", "setLocationHash", "debounceTime", "import_escape_html", "setupSearchHighlighter", "config", "regex", "term", "separator", "highlight", "_", "data", "query", "match", "value", "escapeHTML", "isSearchReadyMessage", "message", "isSearchResultMessage", "setupSearchWorker", "url", "index$", "worker$", "watchWorker", "merge", "of", "watchToggle", "first", "active", "switchMap", "config", "docs", "feature", "selectedVersionCorrespondingURL", "params", "_a", "selectedVersionSitemap", "selectedVersionBaseURL", "currentLocation", "currentBaseURL", "current_path", "safeURLParse", "currentRelativePath", "stripPrefix", "sitemapCommonPrefix", "shortestCommonPrefix", "potentialSitemapURL", "result", "url", "base", "e", "s", "prefix", "commonPrefixLen", "s1", "s2", "max", "strs", "setupVersionSelector", "document$", "config", "configuration", "versions$", "requestJSON", "catchError", "EMPTY", "current$", "map", "versions", "current", "version", "aliases", "switchMap", "urls", "fromEvent", "filter", "ev", "withLatestFrom", "el", "url", "of", "selectedVersionBaseURL", "fetchSitemap", "sitemap", "_a", "selectedVersionCorrespondingURL", "getLocation", "setLocation", "combineLatest", "getElement", "renderVersionSelector", "outdated", "ignored", "main", "ignore", "warning", "getComponentElements", "watchSearchQuery", "el", "worker$", "searchParams", "getLocation", "setToggle", "watchToggle", "first", "active", "url", "focus$", "watchElementFocus", "value$", "merge", "isSearchReadyMessage", "fromEvent", "map", "distinctUntilChanged", "combineLatest", "value", "focus", "shareReplay", "mountSearchQuery", "push$", "Subject", "done$", "ignoreElements", "endWith", "_", "query", "distinctUntilKeyChanged", "takeUntil", "label", "getElement", "tap", "state", "finalize", "__spreadValues", "mountSearchResult", "el", "worker$", "query$", "push$", "Subject", "boundary$", "watchElementBoundary", "filter", "container", "meta", "getElement", "list", "watchToggle", "active", "withLatestFrom", "skipUntil", "first", "isSearchReadyMessage", "items", "value", "translation", "count", "round", "render$", "tap", "switchMap", "merge", "of", "bufferCount", "zipWith", "chunk", "map", "renderSearchResultItem", "share", "item", "mergeMap", "details", "getOptionalElement", "EMPTY", "fromEvent", "takeUntil", "isSearchResultMessage", "data", "state", "finalize", "__spreadValues", "watchSearchShare", "_el", "query$", "map", "value", "url", "getLocation", "mountSearchShare", "el", "options", "push$", "Subject", "done$", "ignoreElements", "endWith", "fromEvent", "takeUntil", "ev", "tap", "state", "finalize", "__spreadValues", "mountSearchSuggest", "el", "worker$", "keyboard$", "push$", "Subject", "query", "getComponentElement", "query$", "merge", "fromEvent", "observeOn", "asyncScheduler", "map", "distinctUntilChanged", "combineLatestWith", "suggest", "value", "words", "last", "filter", "mode", "key", "isSearchResultMessage", "data", "tap", "state", "finalize", "mountSearch", "el", "index$", "keyboard$", "config", "configuration", "worker$", "setupSearchWorker", "query", "getComponentElement", "result", "fromEvent", "filter", "target", "setToggle", "mode", "key", "active", "getActiveElement", "anchors", "anchor", "getElements", "article", "best", "a", "b", "els", "i", "query$", "mountSearchQuery", "merge", "mountSearchResult", "mergeWith", "getComponentElements", "child", "mountSearchShare", "mountSearchSuggest", "err", "NEVER", "mountSearchHiglight", "el", "index$", "location$", "combineLatest", "startWith", "getLocation", "filter", "url", "map", "index", "setupSearchHighlighter", "fn", "_a", "nodes", "it", "node", "original", "replaced", "text", "childNodes", "h", "watchSidebar", "el", "viewport$", "main$", "parent", "adjust", "combineLatest", "map", "offset", "height", "y", "distinctUntilChanged", "a", "b", "mountSidebar", "_a", "_b", "header$", "options", "__objRest", "inner", "getElement", "getElementOffset", "defer", "push$", "Subject", "done$", "ignoreElements", "endWith", "next$", "auditTime", "animationFrameScheduler", "withLatestFrom", "first", "item", "getElements", "container", "getElementSize", "from", "mergeMap", "label", "fromEvent", "observeOn", "asyncScheduler", "takeUntil", "input", "tap", "state", "finalize", "__spreadValues", "fetchSourceFactsFromGitHub", "user", "repo", "url", "zip", "requestJSON", "catchError", "EMPTY", "map", "release", "defaultIfEmpty", "info", "__spreadValues", "fetchSourceFactsFromGitLab", "base", "project", "url", "zip", "requestJSON", "catchError", "EMPTY", "map", "tag_name", "defaultIfEmpty", "star_count", "forks_count", "release", "info", "__spreadValues", "fetchSourceFacts", "url", "match", "user", "repo", "fetchSourceFactsFromGitHub", "base", "slug", "fetchSourceFactsFromGitLab", "EMPTY", "fetch$", "watchSource", "el", "defer", "cached", "of", "getComponentElements", "consent", "EMPTY", "fetchSourceFacts", "tap", "facts", "catchError", "filter", "map", "shareReplay", "mountSource", "inner", "getElement", "push$", "Subject", "renderSourceFacts", "state", "finalize", "__spreadValues", "watchTabs", "el", "viewport$", "header$", "watchElementSize", "switchMap", "watchViewportAt", "map", "y", "distinctUntilKeyChanged", "mountTabs", "options", "defer", "push$", "Subject", "hidden", "feature", "of", "tap", "state", "finalize", "__spreadValues", "watchTableOfContents", "el", "viewport$", "header$", "table", "anchors", "getElements", "anchor", "id", "target", "getOptionalElement", "adjust$", "distinctUntilKeyChanged", "map", "height", "main", "getComponentElement", "grid", "getElement", "share", "watchElementSize", "switchMap", "body", "defer", "path", "of", "index", "offset", "parent", "a", "b", "combineLatestWith", "adjust", "scan", "prev", "next", "y", "size", "last", "distinctUntilChanged", "startWith", "bufferCount", "mountTableOfContents", "main$", "target$", "push$", "Subject", "done$", "ignoreElements", "endWith", "feature", "smooth$", "merge", "debounceTime", "filter", "observeOn", "asyncScheduler", "withLatestFrom", "behavior", "container", "getElementContainer", "getElementSize", "takeUntil", "skip", "repeat", "url", "getLocation", "active", "hash", "tap", "state", "finalize", "__spreadValues", "watchBackToTop", "_el", "viewport$", "main$", "target$", "direction$", "map", "y", "bufferCount", "b", "distinctUntilChanged", "active$", "active", "combineLatest", "direction", "takeUntil", "skip", "endWith", "repeat", "hidden", "mountBackToTop", "el", "header$", "push$", "Subject", "done$", "ignoreElements", "distinctUntilKeyChanged", "height", "fromEvent", "ev", "tap", "state", "finalize", "__spreadValues", "patchEllipsis", "document$", "viewport$", "switchMap", "getElements", "mergeMap", "el", "watchElementVisibility", "takeUntil", "skip", "filter", "visible", "map", "take", "text", "host", "feature", "mountInlineTooltip2", "finalize", "EMPTY", "patchIndeterminate", "document$", "tablet$", "switchMap", "getElements", "tap", "el", "mergeMap", "fromEvent", "takeWhile", "map", "withLatestFrom", "tablet", "isAppleDevice", "patchScrollfix", "document$", "switchMap", "getElements", "tap", "el", "filter", "mergeMap", "fromEvent", "map", "top", "patchScrolllock", "viewport$", "tablet$", "combineLatest", "watchToggle", "map", "active", "tablet", "switchMap", "of", "delay", "withLatestFrom", "y", "value", "obj", "data", "key", "x", "y", "nodes", "parent", "i", "node", "fetchSearchIndex", "watchScript", "config", "map", "shareReplay", "requestJSON", "document$", "watchDocument", "location$", "watchLocation", "target$", "watchLocationTarget", "keyboard$", "watchKeyboard", "viewport$", "watchViewport", "tablet$", "watchMedia", "screen$", "print$", "watchPrint", "configuration", "index$", "NEVER", "alert$", "Subject", "setupClipboardJS", "progress$", "feature", "setupInstantNavigation", "_a", "setupVersionSelector", "merge", "delay", "setToggle", "filter", "mode", "key", "prev", "getOptionalElement", "setLocation", "next", "active", "getActiveElement", "patchEllipsis", "patchIndeterminate", "patchScrollfix", "patchScrolllock", "header$", "watchHeader", "getComponentElement", "main$", "switchMap", "el", "watchMain", "control$", "getComponentElements", "mountConsent", "mountDialog", "mountPalette", "mountProgress", "mountSearch", "mountSource", "content$", "defer", "mountAnnounce", "mountContent", "mountSearchHiglight", "EMPTY", "mountHeader", "mountHeaderTitle", "at", "mountSidebar", "mountTabs", "mountTableOfContents", "mountBackToTop", "component$", "mergeWith"]
 }
diff --git a/main/assets/stylesheets/main.6f8fc17f.min.css b/main/assets/stylesheets/main.6f8fc17f.min.css
new file mode 100644
index 000000000..a0d06b0eb
--- /dev/null
+++ b/main/assets/stylesheets/main.6f8fc17f.min.css
@@ -0,0 +1 @@
+@charset "UTF-8";html{-webkit-text-size-adjust:none;-moz-text-size-adjust:none;text-size-adjust:none;box-sizing:border-box}*,:after,:before{box-sizing:inherit}@media (prefers-reduced-motion){*,:after,:before{transition:none!important}}body{margin:0}a,button,input,label{-webkit-tap-highlight-color:transparent}a{color:inherit;text-decoration:none}hr{border:0;box-sizing:initial;display:block;height:.05rem;overflow:visible;padding:0}small{font-size:80%}sub,sup{line-height:1em}img{border-style:none}table{border-collapse:initial;border-spacing:0}td,th{font-weight:400;vertical-align:top}button{background:#0000;border:0;font-family:inherit;font-size:inherit;margin:0;padding:0}input{border:0;outline:none}:root{--md-primary-fg-color:#4051b5;--md-primary-fg-color--light:#5d6cc0;--md-primary-fg-color--dark:#303fa1;--md-primary-bg-color:#fff;--md-primary-bg-color--light:#ffffffb3;--md-accent-fg-color:#526cfe;--md-accent-fg-color--transparent:#526cfe1a;--md-accent-bg-color:#fff;--md-accent-bg-color--light:#ffffffb3}[data-md-color-scheme=default]{color-scheme:light}[data-md-color-scheme=default] img[src$="#gh-dark-mode-only"],[data-md-color-scheme=default] img[src$="#only-dark"]{display:none}:root,[data-md-color-scheme=default]{--md-hue:225deg;--md-default-fg-color:#000000de;--md-default-fg-color--light:#0000008a;--md-default-fg-color--lighter:#00000052;--md-default-fg-color--lightest:#00000012;--md-default-bg-color:#fff;--md-default-bg-color--light:#ffffffb3;--md-default-bg-color--lighter:#ffffff4d;--md-default-bg-color--lightest:#ffffff1f;--md-code-fg-color:#36464e;--md-code-bg-color:#f5f5f5;--md-code-hl-color:#4287ff;--md-code-hl-color--light:#4287ff1a;--md-code-hl-number-color:#d52a2a;--md-code-hl-special-color:#db1457;--md-code-hl-function-color:#a846b9;--md-code-hl-constant-color:#6e59d9;--md-code-hl-keyword-color:#3f6ec6;--md-code-hl-string-color:#1c7d4d;--md-code-hl-name-color:var(--md-code-fg-color);--md-code-hl-operator-color:var(--md-default-fg-color--light);--md-code-hl-punctuation-color:var(--md-default-fg-color--light);--md-code-hl-comment-color:var(--md-default-fg-color--light);--md-code-hl-generic-color:var(--md-default-fg-color--light);--md-code-hl-variable-color:var(--md-default-fg-color--light);--md-typeset-color:var(--md-default-fg-color);--md-typeset-a-color:var(--md-primary-fg-color);--md-typeset-del-color:#f5503d26;--md-typeset-ins-color:#0bd57026;--md-typeset-kbd-color:#fafafa;--md-typeset-kbd-accent-color:#fff;--md-typeset-kbd-border-color:#b8b8b8;--md-typeset-mark-color:#ffff0080;--md-typeset-table-color:#0000001f;--md-typeset-table-color--light:rgba(0,0,0,.035);--md-admonition-fg-color:var(--md-default-fg-color);--md-admonition-bg-color:var(--md-default-bg-color);--md-warning-fg-color:#000000de;--md-warning-bg-color:#ff9;--md-footer-fg-color:#fff;--md-footer-fg-color--light:#ffffffb3;--md-footer-fg-color--lighter:#ffffff73;--md-footer-bg-color:#000000de;--md-footer-bg-color--dark:#00000052;--md-shadow-z1:0 0.2rem 0.5rem #0000000d,0 0 0.05rem #0000001a;--md-shadow-z2:0 0.2rem 0.5rem #0000001a,0 0 0.05rem #00000040;--md-shadow-z3:0 0.2rem 0.5rem #0003,0 0 0.05rem #00000059}.md-icon svg{fill:currentcolor;display:block;height:1.2rem;width:1.2rem}body{-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale;--md-text-font-family:var(--md-text-font,_),-apple-system,BlinkMacSystemFont,Helvetica,Arial,sans-serif;--md-code-font-family:var(--md-code-font,_),SFMono-Regular,Consolas,Menlo,monospace}aside,body,input{font-feature-settings:"kern","liga";color:var(--md-typeset-color);font-family:var(--md-text-font-family)}code,kbd,pre{font-feature-settings:"kern";font-family:var(--md-code-font-family)}:root{--md-typeset-table-sort-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="m18 21-4-4h3V7h-3l4-4 4 4h-3v10h3M2 19v-2h10v2M2 13v-2h7v2M2 7V5h4v2z"/></svg>');--md-typeset-table-sort-icon--asc:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M19 17h3l-4 4-4-4h3V3h2M2 17h10v2H2M6 5v2H2V5m0 6h7v2H2z"/></svg>');--md-typeset-table-sort-icon--desc:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M19 7h3l-4-4-4 4h3v14h2M2 17h10v2H2M6 5v2H2V5m0 6h7v2H2z"/></svg>')}.md-typeset{-webkit-print-color-adjust:exact;color-adjust:exact;font-size:.8rem;line-height:1.6}@media print{.md-typeset{font-size:.68rem}}.md-typeset blockquote,.md-typeset dl,.md-typeset figure,.md-typeset ol,.md-typeset pre,.md-typeset ul{margin-bottom:1em;margin-top:1em}.md-typeset h1{color:var(--md-default-fg-color--light);font-size:2em;line-height:1.3;margin:0 0 1.25em}.md-typeset h1,.md-typeset h2{font-weight:300;letter-spacing:-.01em}.md-typeset h2{font-size:1.5625em;line-height:1.4;margin:1.6em 0 .64em}.md-typeset h3{font-size:1.25em;font-weight:400;letter-spacing:-.01em;line-height:1.5;margin:1.6em 0 .8em}.md-typeset h2+h3{margin-top:.8em}.md-typeset h4{font-weight:700;letter-spacing:-.01em;margin:1em 0}.md-typeset h5,.md-typeset h6{color:var(--md-default-fg-color--light);font-size:.8em;font-weight:700;letter-spacing:-.01em;margin:1.25em 0}.md-typeset h5{text-transform:uppercase}.md-typeset h5 code{text-transform:none}.md-typeset hr{border-bottom:.05rem solid var(--md-default-fg-color--lightest);display:flow-root;margin:1.5em 0}.md-typeset a{color:var(--md-typeset-a-color);word-break:break-word}.md-typeset a,.md-typeset a:before{transition:color 125ms}.md-typeset a:focus,.md-typeset a:hover{color:var(--md-accent-fg-color)}.md-typeset a:focus code,.md-typeset a:hover code{background-color:var(--md-accent-fg-color--transparent)}.md-typeset a code{color:currentcolor;transition:background-color 125ms}.md-typeset a.focus-visible{outline-color:var(--md-accent-fg-color);outline-offset:.2rem}.md-typeset code,.md-typeset kbd,.md-typeset pre{color:var(--md-code-fg-color);direction:ltr;font-variant-ligatures:none}@media print{.md-typeset code,.md-typeset kbd,.md-typeset pre{white-space:pre-wrap}}.md-typeset code{background-color:var(--md-code-bg-color);border-radius:.1rem;-webkit-box-decoration-break:clone;box-decoration-break:clone;font-size:.85em;padding:0 .2941176471em;word-break:break-word}.md-typeset code:not(.focus-visible){-webkit-tap-highlight-color:transparent;outline:none}.md-typeset pre{display:flow-root;line-height:1.4;position:relative}.md-typeset pre>code{-webkit-box-decoration-break:slice;box-decoration-break:slice;box-shadow:none;display:block;margin:0;outline-color:var(--md-accent-fg-color);overflow:auto;padding:.7720588235em 1.1764705882em;scrollbar-color:var(--md-default-fg-color--lighter) #0000;scrollbar-width:thin;touch-action:auto;word-break:normal}.md-typeset pre>code:hover{scrollbar-color:var(--md-accent-fg-color) #0000}.md-typeset pre>code::-webkit-scrollbar{height:.2rem;width:.2rem}.md-typeset pre>code::-webkit-scrollbar-thumb{background-color:var(--md-default-fg-color--lighter)}.md-typeset pre>code::-webkit-scrollbar-thumb:hover{background-color:var(--md-accent-fg-color)}.md-typeset kbd{background-color:var(--md-typeset-kbd-color);border-radius:.1rem;box-shadow:0 .1rem 0 .05rem var(--md-typeset-kbd-border-color),0 .1rem 0 var(--md-typeset-kbd-border-color),0 -.1rem .2rem var(--md-typeset-kbd-accent-color) inset;color:var(--md-default-fg-color);display:inline-block;font-size:.75em;padding:0 .6666666667em;vertical-align:text-top;word-break:break-word}.md-typeset mark{background-color:var(--md-typeset-mark-color);-webkit-box-decoration-break:clone;box-decoration-break:clone;color:inherit;word-break:break-word}.md-typeset abbr{border-bottom:.05rem dotted var(--md-default-fg-color--light);cursor:help;text-decoration:none}.md-typeset small{opacity:.75}[dir=ltr] .md-typeset sub,[dir=ltr] .md-typeset sup{margin-left:.078125em}[dir=rtl] .md-typeset sub,[dir=rtl] .md-typeset sup{margin-right:.078125em}[dir=ltr] .md-typeset blockquote{padding-left:.6rem}[dir=rtl] .md-typeset blockquote{padding-right:.6rem}[dir=ltr] .md-typeset blockquote{border-left:.2rem solid var(--md-default-fg-color--lighter)}[dir=rtl] .md-typeset blockquote{border-right:.2rem solid var(--md-default-fg-color--lighter)}.md-typeset blockquote{color:var(--md-default-fg-color--light);margin-left:0;margin-right:0}.md-typeset ul{list-style-type:disc}.md-typeset ul[type]{list-style-type:revert-layer}[dir=ltr] .md-typeset ol,[dir=ltr] .md-typeset ul{margin-left:.625em}[dir=rtl] .md-typeset ol,[dir=rtl] .md-typeset ul{margin-right:.625em}.md-typeset ol,.md-typeset ul{padding:0}.md-typeset ol:not([hidden]),.md-typeset ul:not([hidden]){display:flow-root}.md-typeset ol ol,.md-typeset ul ol{list-style-type:lower-alpha}.md-typeset ol ol ol,.md-typeset ul ol ol{list-style-type:lower-roman}.md-typeset ol ol ol ol,.md-typeset ul ol ol ol{list-style-type:upper-alpha}.md-typeset ol ol ol ol ol,.md-typeset ul ol ol ol ol{list-style-type:upper-roman}.md-typeset ol[type],.md-typeset ul[type]{list-style-type:revert-layer}[dir=ltr] .md-typeset ol li,[dir=ltr] .md-typeset ul li{margin-left:1.25em}[dir=rtl] .md-typeset ol li,[dir=rtl] .md-typeset ul li{margin-right:1.25em}.md-typeset ol li,.md-typeset ul li{margin-bottom:.5em}.md-typeset ol li blockquote,.md-typeset ol li p,.md-typeset ul li blockquote,.md-typeset ul li p{margin:.5em 0}.md-typeset ol li:last-child,.md-typeset ul li:last-child{margin-bottom:0}[dir=ltr] .md-typeset ol li ol,[dir=ltr] .md-typeset ol li ul,[dir=ltr] .md-typeset ul li ol,[dir=ltr] .md-typeset ul li ul{margin-left:.625em}[dir=rtl] .md-typeset ol li ol,[dir=rtl] .md-typeset ol li ul,[dir=rtl] .md-typeset ul li ol,[dir=rtl] .md-typeset ul li ul{margin-right:.625em}.md-typeset ol li ol,.md-typeset ol li ul,.md-typeset ul li ol,.md-typeset ul li ul{margin-bottom:.5em;margin-top:.5em}[dir=ltr] .md-typeset dd{margin-left:1.875em}[dir=rtl] .md-typeset dd{margin-right:1.875em}.md-typeset dd{margin-bottom:1.5em;margin-top:1em}.md-typeset img,.md-typeset svg,.md-typeset video{height:auto;max-width:100%}.md-typeset img[align=left]{margin:1em 1em 1em 0}.md-typeset img[align=right]{margin:1em 0 1em 1em}.md-typeset img[align]:only-child{margin-top:0}.md-typeset figure{display:flow-root;margin:1em auto;max-width:100%;text-align:center;width:-moz-fit-content;width:fit-content}.md-typeset figure img{display:block;margin:0 auto}.md-typeset figcaption{font-style:italic;margin:1em auto;max-width:24rem}.md-typeset iframe{max-width:100%}.md-typeset table:not([class]){background-color:var(--md-default-bg-color);border:.05rem solid var(--md-typeset-table-color);border-radius:.1rem;display:inline-block;font-size:.64rem;max-width:100%;overflow:auto;touch-action:auto}@media print{.md-typeset table:not([class]){display:table}}.md-typeset table:not([class])+*{margin-top:1.5em}.md-typeset table:not([class]) td>:first-child,.md-typeset table:not([class]) th>:first-child{margin-top:0}.md-typeset table:not([class]) td>:last-child,.md-typeset table:not([class]) th>:last-child{margin-bottom:0}.md-typeset table:not([class]) td:not([align]),.md-typeset table:not([class]) th:not([align]){text-align:left}[dir=rtl] .md-typeset table:not([class]) td:not([align]),[dir=rtl] .md-typeset table:not([class]) th:not([align]){text-align:right}.md-typeset table:not([class]) th{font-weight:700;min-width:5rem;padding:.9375em 1.25em;vertical-align:top}.md-typeset table:not([class]) td{border-top:.05rem solid var(--md-typeset-table-color);padding:.9375em 1.25em;vertical-align:top}.md-typeset table:not([class]) tbody tr{transition:background-color 125ms}.md-typeset table:not([class]) tbody tr:hover{background-color:var(--md-typeset-table-color--light);box-shadow:0 .05rem 0 var(--md-default-bg-color) inset}.md-typeset table:not([class]) a{word-break:normal}.md-typeset table th[role=columnheader]{cursor:pointer}[dir=ltr] .md-typeset table th[role=columnheader]:after{margin-left:.5em}[dir=rtl] .md-typeset table th[role=columnheader]:after{margin-right:.5em}.md-typeset table th[role=columnheader]:after{content:"";display:inline-block;height:1.2em;-webkit-mask-image:var(--md-typeset-table-sort-icon);mask-image:var(--md-typeset-table-sort-icon);-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;transition:background-color 125ms;vertical-align:text-bottom;width:1.2em}.md-typeset table th[role=columnheader]:hover:after{background-color:var(--md-default-fg-color--lighter)}.md-typeset table th[role=columnheader][aria-sort=ascending]:after{background-color:var(--md-default-fg-color--light);-webkit-mask-image:var(--md-typeset-table-sort-icon--asc);mask-image:var(--md-typeset-table-sort-icon--asc)}.md-typeset table th[role=columnheader][aria-sort=descending]:after{background-color:var(--md-default-fg-color--light);-webkit-mask-image:var(--md-typeset-table-sort-icon--desc);mask-image:var(--md-typeset-table-sort-icon--desc)}.md-typeset__scrollwrap{margin:1em -.8rem;overflow-x:auto;touch-action:auto}.md-typeset__table{display:inline-block;margin-bottom:.5em;padding:0 .8rem}@media print{.md-typeset__table{display:block}}html .md-typeset__table table{display:table;margin:0;overflow:hidden;width:100%}@media screen and (max-width:44.984375em){.md-content__inner>pre{margin:1em -.8rem}.md-content__inner>pre code{border-radius:0}}.md-typeset .md-author{border-radius:100%;display:block;flex-shrink:0;height:1.6rem;overflow:hidden;position:relative;transition:color 125ms,transform 125ms;width:1.6rem}.md-typeset .md-author img{display:block}.md-typeset .md-author--more{background:var(--md-default-fg-color--lightest);color:var(--md-default-fg-color--lighter);font-size:.6rem;font-weight:700;line-height:1.6rem;text-align:center}.md-typeset .md-author--long{height:2.4rem;width:2.4rem}.md-typeset a.md-author{transform:scale(1)}.md-typeset a.md-author img{border-radius:100%;filter:grayscale(100%) opacity(75%);transition:filter 125ms}.md-typeset a.md-author:focus,.md-typeset a.md-author:hover{transform:scale(1.1);z-index:1}.md-typeset a.md-author:focus img,.md-typeset a.md-author:hover img{filter:grayscale(0)}.md-banner{background-color:var(--md-footer-bg-color);color:var(--md-footer-fg-color);overflow:auto}@media print{.md-banner{display:none}}.md-banner--warning{background-color:var(--md-warning-bg-color);color:var(--md-warning-fg-color)}.md-banner__inner{font-size:.7rem;margin:.6rem auto;padding:0 .8rem}[dir=ltr] .md-banner__button{float:right}[dir=rtl] .md-banner__button{float:left}.md-banner__button{color:inherit;cursor:pointer;transition:opacity .25s}.no-js .md-banner__button{display:none}.md-banner__button:hover{opacity:.7}html{font-size:125%;height:100%;overflow-x:hidden}@media screen and (min-width:100em){html{font-size:137.5%}}@media screen and (min-width:125em){html{font-size:150%}}body{background-color:var(--md-default-bg-color);display:flex;flex-direction:column;font-size:.5rem;min-height:100%;position:relative;width:100%}@media print{body{display:block}}@media screen and (max-width:59.984375em){body[data-md-scrolllock]{position:fixed}}.md-grid{margin-left:auto;margin-right:auto;max-width:61rem}.md-container{display:flex;flex-direction:column;flex-grow:1}@media print{.md-container{display:block}}.md-main{flex-grow:1}.md-main__inner{display:flex;height:100%;margin-top:1.5rem}.md-ellipsis{overflow:hidden;text-overflow:ellipsis}.md-toggle{display:none}.md-option{height:0;opacity:0;position:absolute;width:0}.md-option:checked+label:not([hidden]){display:block}.md-option.focus-visible+label{outline-color:var(--md-accent-fg-color);outline-style:auto}.md-skip{background-color:var(--md-default-fg-color);border-radius:.1rem;color:var(--md-default-bg-color);font-size:.64rem;margin:.5rem;opacity:0;outline-color:var(--md-accent-fg-color);padding:.3rem .5rem;position:fixed;transform:translateY(.4rem);z-index:-1}.md-skip:focus{opacity:1;transform:translateY(0);transition:transform .25s cubic-bezier(.4,0,.2,1),opacity 175ms 75ms;z-index:10}@page{margin:25mm}:root{--md-clipboard-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M19 21H8V7h11m0-2H8a2 2 0 0 0-2 2v14a2 2 0 0 0 2 2h11a2 2 0 0 0 2-2V7a2 2 0 0 0-2-2m-3-4H4a2 2 0 0 0-2 2v14h2V3h12z"/></svg>')}.md-clipboard{border-radius:.1rem;color:var(--md-default-fg-color--lightest);cursor:pointer;height:1.5em;outline-color:var(--md-accent-fg-color);outline-offset:.1rem;position:absolute;right:.5em;top:.5em;transition:color .25s;width:1.5em;z-index:1}@media print{.md-clipboard{display:none}}.md-clipboard:not(.focus-visible){-webkit-tap-highlight-color:transparent;outline:none}:hover>.md-clipboard{color:var(--md-default-fg-color--light)}.md-clipboard:focus,.md-clipboard:hover{color:var(--md-accent-fg-color)}.md-clipboard:after{background-color:currentcolor;content:"";display:block;height:1.125em;margin:0 auto;-webkit-mask-image:var(--md-clipboard-icon);mask-image:var(--md-clipboard-icon);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;width:1.125em}.md-clipboard--inline{cursor:pointer}.md-clipboard--inline code{transition:color .25s,background-color .25s}.md-clipboard--inline:focus code,.md-clipboard--inline:hover code{background-color:var(--md-accent-fg-color--transparent);color:var(--md-accent-fg-color)}.md-typeset .md-code__content{display:grid}@keyframes consent{0%{opacity:0;transform:translateY(100%)}to{opacity:1;transform:translateY(0)}}@keyframes overlay{0%{opacity:0}to{opacity:1}}.md-consent__overlay{animation:overlay .25s both;-webkit-backdrop-filter:blur(.1rem);backdrop-filter:blur(.1rem);background-color:#0000008a;height:100%;opacity:1;position:fixed;top:0;width:100%;z-index:5}.md-consent__inner{animation:consent .5s cubic-bezier(.1,.7,.1,1) both;background-color:var(--md-default-bg-color);border:0;border-radius:.1rem;bottom:0;box-shadow:0 0 .2rem #0000001a,0 .2rem .4rem #0003;max-height:100%;overflow:auto;padding:0;position:fixed;width:100%;z-index:5}.md-consent__form{padding:.8rem}.md-consent__settings{display:none;margin:1em 0}input:checked+.md-consent__settings{display:block}.md-consent__controls{margin-bottom:.8rem}.md-typeset .md-consent__controls .md-button{display:inline}@media screen and (max-width:44.984375em){.md-typeset .md-consent__controls .md-button{display:block;margin-top:.4rem;text-align:center;width:100%}}.md-consent label{cursor:pointer}.md-content{flex-grow:1;min-width:0}.md-content__inner{margin:0 .8rem 1.2rem;padding-top:.6rem}@media screen and (min-width:76.25em){[dir=ltr] .md-sidebar--primary:not([hidden])~.md-content>.md-content__inner{margin-left:1.2rem}[dir=ltr] .md-sidebar--secondary:not([hidden])~.md-content>.md-content__inner,[dir=rtl] .md-sidebar--primary:not([hidden])~.md-content>.md-content__inner{margin-right:1.2rem}[dir=rtl] .md-sidebar--secondary:not([hidden])~.md-content>.md-content__inner{margin-left:1.2rem}}.md-content__inner:before{content:"";display:block;height:.4rem}.md-content__inner>:last-child{margin-bottom:0}[dir=ltr] .md-content__button{float:right}[dir=rtl] .md-content__button{float:left}[dir=ltr] .md-content__button{margin-left:.4rem}[dir=rtl] .md-content__button{margin-right:.4rem}.md-content__button{margin:.4rem 0;padding:0}@media print{.md-content__button{display:none}}.md-typeset .md-content__button{color:var(--md-default-fg-color--lighter)}.md-content__button svg{display:inline;vertical-align:top}[dir=rtl] .md-content__button svg{transform:scaleX(-1)}[dir=ltr] .md-dialog{right:.8rem}[dir=rtl] .md-dialog{left:.8rem}.md-dialog{background-color:var(--md-default-fg-color);border-radius:.1rem;bottom:.8rem;box-shadow:var(--md-shadow-z3);min-width:11.1rem;opacity:0;padding:.4rem .6rem;pointer-events:none;position:fixed;transform:translateY(100%);transition:transform 0ms .4s,opacity .4s;z-index:4}@media print{.md-dialog{display:none}}.md-dialog--active{opacity:1;pointer-events:auto;transform:translateY(0);transition:transform .4s cubic-bezier(.075,.85,.175,1),opacity .4s}.md-dialog__inner{color:var(--md-default-bg-color);font-size:.7rem}.md-feedback{margin:2em 0 1em;text-align:center}.md-feedback fieldset{border:none;margin:0;padding:0}.md-feedback__title{font-weight:700;margin:1em auto}.md-feedback__inner{position:relative}.md-feedback__list{display:flex;flex-wrap:wrap;place-content:baseline center;position:relative}.md-feedback__list:hover .md-icon:not(:disabled){color:var(--md-default-fg-color--lighter)}:disabled .md-feedback__list{min-height:1.8rem}.md-feedback__icon{color:var(--md-default-fg-color--light);cursor:pointer;flex-shrink:0;margin:0 .1rem;transition:color 125ms}.md-feedback__icon:not(:disabled).md-icon:hover{color:var(--md-accent-fg-color)}.md-feedback__icon:disabled{color:var(--md-default-fg-color--lightest);pointer-events:none}.md-feedback__note{opacity:0;position:relative;transform:translateY(.4rem);transition:transform .4s cubic-bezier(.1,.7,.1,1),opacity .15s}.md-feedback__note>*{margin:0 auto;max-width:16rem}:disabled .md-feedback__note{opacity:1;transform:translateY(0)}@media print{.md-feedback{display:none}}.md-footer{background-color:var(--md-footer-bg-color);color:var(--md-footer-fg-color)}@media print{.md-footer{display:none}}.md-footer__inner{justify-content:space-between;overflow:auto;padding:.2rem}.md-footer__inner:not([hidden]){display:flex}.md-footer__link{align-items:end;display:flex;flex-grow:0.01;margin-bottom:.4rem;margin-top:1rem;max-width:100%;outline-color:var(--md-accent-fg-color);overflow:hidden;transition:opacity .25s}.md-footer__link:focus,.md-footer__link:hover{opacity:.7}[dir=rtl] .md-footer__link svg{transform:scaleX(-1)}@media screen and (max-width:44.984375em){.md-footer__link--prev{flex-shrink:0}.md-footer__link--prev .md-footer__title{display:none}}[dir=ltr] .md-footer__link--next{margin-left:auto}[dir=rtl] .md-footer__link--next{margin-right:auto}.md-footer__link--next{text-align:right}[dir=rtl] .md-footer__link--next{text-align:left}.md-footer__title{flex-grow:1;font-size:.9rem;margin-bottom:.7rem;max-width:calc(100% - 2.4rem);padding:0 1rem;white-space:nowrap}.md-footer__button{margin:.2rem;padding:.4rem}.md-footer__direction{font-size:.64rem;opacity:.7}.md-footer-meta{background-color:var(--md-footer-bg-color--dark)}.md-footer-meta__inner{display:flex;flex-wrap:wrap;justify-content:space-between;padding:.2rem}html .md-footer-meta.md-typeset a{color:var(--md-footer-fg-color--light)}html .md-footer-meta.md-typeset a:focus,html .md-footer-meta.md-typeset a:hover{color:var(--md-footer-fg-color)}.md-copyright{color:var(--md-footer-fg-color--lighter);font-size:.64rem;margin:auto .6rem;padding:.4rem 0;width:100%}@media screen and (min-width:45em){.md-copyright{width:auto}}.md-copyright__highlight{color:var(--md-footer-fg-color--light)}.md-social{display:inline-flex;gap:.2rem;margin:0 .4rem;padding:.2rem 0 .6rem}@media screen and (min-width:45em){.md-social{padding:.6rem 0}}.md-social__link{display:inline-block;height:1.6rem;text-align:center;width:1.6rem}.md-social__link:before{line-height:1.9}.md-social__link svg{fill:currentcolor;max-height:.8rem;vertical-align:-25%}.md-typeset .md-button{border:.1rem solid;border-radius:.1rem;color:var(--md-primary-fg-color);cursor:pointer;display:inline-block;font-weight:700;padding:.625em 2em;transition:color 125ms,background-color 125ms,border-color 125ms}.md-typeset .md-button--primary{background-color:var(--md-primary-fg-color);border-color:var(--md-primary-fg-color);color:var(--md-primary-bg-color)}.md-typeset .md-button:focus,.md-typeset .md-button:hover{background-color:var(--md-accent-fg-color);border-color:var(--md-accent-fg-color);color:var(--md-accent-bg-color)}[dir=ltr] .md-typeset .md-input{border-top-left-radius:.1rem}[dir=ltr] .md-typeset .md-input,[dir=rtl] .md-typeset .md-input{border-top-right-radius:.1rem}[dir=rtl] .md-typeset .md-input{border-top-left-radius:.1rem}.md-typeset .md-input{border-bottom:.1rem solid var(--md-default-fg-color--lighter);box-shadow:var(--md-shadow-z1);font-size:.8rem;height:1.8rem;padding:0 .6rem;transition:border .25s,box-shadow .25s}.md-typeset .md-input:focus,.md-typeset .md-input:hover{border-bottom-color:var(--md-accent-fg-color);box-shadow:var(--md-shadow-z2)}.md-typeset .md-input--stretch{width:100%}.md-header{background-color:var(--md-primary-fg-color);box-shadow:0 0 .2rem #0000,0 .2rem .4rem #0000;color:var(--md-primary-bg-color);display:block;left:0;position:sticky;right:0;top:0;z-index:4}@media print{.md-header{display:none}}.md-header[hidden]{transform:translateY(-100%);transition:transform .25s cubic-bezier(.8,0,.6,1),box-shadow .25s}.md-header--shadow{box-shadow:0 0 .2rem #0000001a,0 .2rem .4rem #0003;transition:transform .25s cubic-bezier(.1,.7,.1,1),box-shadow .25s}.md-header__inner{align-items:center;display:flex;padding:0 .2rem}.md-header__button{color:currentcolor;cursor:pointer;margin:.2rem;outline-color:var(--md-accent-fg-color);padding:.4rem;position:relative;transition:opacity .25s;vertical-align:middle;z-index:1}.md-header__button:hover{opacity:.7}.md-header__button:not([hidden]){display:inline-block}.md-header__button:not(.focus-visible){-webkit-tap-highlight-color:transparent;outline:none}.md-header__button.md-logo{margin:.2rem;padding:.4rem}@media screen and (max-width:76.234375em){.md-header__button.md-logo{display:none}}.md-header__button.md-logo img,.md-header__button.md-logo svg{fill:currentcolor;display:block;height:1.2rem;width:auto}@media screen and (min-width:60em){.md-header__button[for=__search]{display:none}}.no-js .md-header__button[for=__search]{display:none}[dir=rtl] .md-header__button[for=__search] svg{transform:scaleX(-1)}@media screen and (min-width:76.25em){.md-header__button[for=__drawer]{display:none}}.md-header__topic{display:flex;max-width:100%;position:absolute;transition:transform .4s cubic-bezier(.1,.7,.1,1),opacity .15s;white-space:nowrap}.md-header__topic+.md-header__topic{opacity:0;pointer-events:none;transform:translateX(1.25rem);transition:transform .4s cubic-bezier(1,.7,.1,.1),opacity .15s;z-index:-1}[dir=rtl] .md-header__topic+.md-header__topic{transform:translateX(-1.25rem)}.md-header__topic:first-child{font-weight:700}[dir=ltr] .md-header__title{margin-left:1rem;margin-right:.4rem}[dir=rtl] .md-header__title{margin-left:.4rem;margin-right:1rem}.md-header__title{flex-grow:1;font-size:.9rem;height:2.4rem;line-height:2.4rem}.md-header__title--active .md-header__topic{opacity:0;pointer-events:none;transform:translateX(-1.25rem);transition:transform .4s cubic-bezier(1,.7,.1,.1),opacity .15s;z-index:-1}[dir=rtl] .md-header__title--active .md-header__topic{transform:translateX(1.25rem)}.md-header__title--active .md-header__topic+.md-header__topic{opacity:1;pointer-events:auto;transform:translateX(0);transition:transform .4s cubic-bezier(.1,.7,.1,1),opacity .15s;z-index:0}.md-header__title>.md-header__ellipsis{height:100%;position:relative;width:100%}.md-header__option{display:flex;flex-shrink:0;max-width:100%;transition:max-width 0ms .25s,opacity .25s .25s;white-space:nowrap}[data-md-toggle=search]:checked~.md-header .md-header__option{max-width:0;opacity:0;transition:max-width 0ms,opacity 0ms}.md-header__option>input{bottom:0}.md-header__source{display:none}@media screen and (min-width:60em){[dir=ltr] .md-header__source{margin-left:1rem}[dir=rtl] .md-header__source{margin-right:1rem}.md-header__source{display:block;max-width:11.7rem;width:11.7rem}}@media screen and (min-width:76.25em){[dir=ltr] .md-header__source{margin-left:1.4rem}[dir=rtl] .md-header__source{margin-right:1.4rem}}.md-meta{color:var(--md-default-fg-color--light);font-size:.7rem;line-height:1.3}.md-meta__list{display:inline-flex;flex-wrap:wrap;list-style:none;margin:0;padding:0}.md-meta__item:not(:last-child):after{content:"·";margin-left:.2rem;margin-right:.2rem}.md-meta__link{color:var(--md-typeset-a-color)}.md-meta__link:focus,.md-meta__link:hover{color:var(--md-accent-fg-color)}.md-draft{background-color:#ff1744;border-radius:.125em;color:#fff;display:inline-block;font-weight:700;padding-left:.5714285714em;padding-right:.5714285714em}:root{--md-nav-icon--prev:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>');--md-nav-icon--next:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M8.59 16.58 13.17 12 8.59 7.41 10 6l6 6-6 6z"/></svg>');--md-toc-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M3 9h14V7H3zm0 4h14v-2H3zm0 4h14v-2H3zm16 0h2v-2h-2zm0-10v2h2V7zm0 6h2v-2h-2z"/></svg>')}.md-nav{font-size:.7rem;line-height:1.3}.md-nav__title{color:var(--md-default-fg-color--light);display:block;font-weight:700;overflow:hidden;padding:0 .6rem;text-overflow:ellipsis}.md-nav__title .md-nav__button{display:none}.md-nav__title .md-nav__button img{height:100%;width:auto}.md-nav__title .md-nav__button.md-logo img,.md-nav__title .md-nav__button.md-logo svg{fill:currentcolor;display:block;height:2.4rem;max-width:100%;object-fit:contain;width:auto}.md-nav__list{list-style:none;margin:0;padding:0}.md-nav__link{align-items:flex-start;display:flex;gap:.4rem;margin-top:.625em;scroll-snap-align:start;transition:color 125ms}.md-nav__link--passed{color:var(--md-default-fg-color--light)}.md-nav__item .md-nav__link--active,.md-nav__item .md-nav__link--active code{color:var(--md-typeset-a-color)}.md-nav__link .md-ellipsis{position:relative}[dir=ltr] .md-nav__link .md-icon:last-child{margin-left:auto}[dir=rtl] .md-nav__link .md-icon:last-child{margin-right:auto}.md-nav__link svg{fill:currentcolor;flex-shrink:0;height:1.3em;position:relative}.md-nav__link[for]:focus,.md-nav__link[for]:hover,.md-nav__link[href]:focus,.md-nav__link[href]:hover{color:var(--md-accent-fg-color);cursor:pointer}.md-nav__link.focus-visible{outline-color:var(--md-accent-fg-color);outline-offset:.2rem}.md-nav--primary .md-nav__link[for=__toc]{display:none}.md-nav--primary .md-nav__link[for=__toc] .md-icon:after{background-color:currentcolor;display:block;height:100%;-webkit-mask-image:var(--md-toc-icon);mask-image:var(--md-toc-icon);width:100%}.md-nav--primary .md-nav__link[for=__toc]~.md-nav{display:none}.md-nav__container>.md-nav__link{margin-top:0}.md-nav__container>.md-nav__link:first-child{flex-grow:1;min-width:0}.md-nav__icon{flex-shrink:0}.md-nav__source{display:none}@media screen and (max-width:76.234375em){.md-nav--primary,.md-nav--primary .md-nav{background-color:var(--md-default-bg-color);display:flex;flex-direction:column;height:100%;left:0;position:absolute;right:0;top:0;z-index:1}.md-nav--primary .md-nav__item,.md-nav--primary .md-nav__title{font-size:.8rem;line-height:1.5}.md-nav--primary .md-nav__title{background-color:var(--md-default-fg-color--lightest);color:var(--md-default-fg-color--light);cursor:pointer;height:5.6rem;line-height:2.4rem;padding:3rem .8rem .2rem;position:relative;white-space:nowrap}[dir=ltr] .md-nav--primary .md-nav__title .md-nav__icon{left:.4rem}[dir=rtl] .md-nav--primary .md-nav__title .md-nav__icon{right:.4rem}.md-nav--primary .md-nav__title .md-nav__icon{display:block;height:1.2rem;margin:.2rem;position:absolute;top:.4rem;width:1.2rem}.md-nav--primary .md-nav__title .md-nav__icon:after{background-color:currentcolor;content:"";display:block;height:100%;-webkit-mask-image:var(--md-nav-icon--prev);mask-image:var(--md-nav-icon--prev);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;width:100%}.md-nav--primary .md-nav__title~.md-nav__list{background-color:var(--md-default-bg-color);box-shadow:0 .05rem 0 var(--md-default-fg-color--lightest) inset;overflow-y:auto;scroll-snap-type:y mandatory;touch-action:pan-y}.md-nav--primary .md-nav__title~.md-nav__list>:first-child{border-top:0}.md-nav--primary .md-nav__title[for=__drawer]{background-color:var(--md-primary-fg-color);color:var(--md-primary-bg-color);font-weight:700}.md-nav--primary .md-nav__title .md-logo{display:block;left:.2rem;margin:.2rem;padding:.4rem;position:absolute;right:.2rem;top:.2rem}.md-nav--primary .md-nav__list{flex:1}.md-nav--primary .md-nav__item{border-top:.05rem solid var(--md-default-fg-color--lightest)}.md-nav--primary .md-nav__item--active>.md-nav__link{color:var(--md-typeset-a-color)}.md-nav--primary .md-nav__item--active>.md-nav__link:focus,.md-nav--primary .md-nav__item--active>.md-nav__link:hover{color:var(--md-accent-fg-color)}.md-nav--primary .md-nav__link{margin-top:0;padding:.6rem .8rem}.md-nav--primary .md-nav__link svg{margin-top:.1em}.md-nav--primary .md-nav__link>.md-nav__link{padding:0}[dir=ltr] .md-nav--primary .md-nav__link .md-nav__icon{margin-right:-.2rem}[dir=rtl] .md-nav--primary .md-nav__link .md-nav__icon{margin-left:-.2rem}.md-nav--primary .md-nav__link .md-nav__icon{font-size:1.2rem;height:1.2rem;width:1.2rem}.md-nav--primary .md-nav__link .md-nav__icon:after{background-color:currentcolor;content:"";display:block;height:100%;-webkit-mask-image:var(--md-nav-icon--next);mask-image:var(--md-nav-icon--next);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;width:100%}[dir=rtl] .md-nav--primary .md-nav__icon:after{transform:scale(-1)}.md-nav--primary .md-nav--secondary .md-nav{background-color:initial;position:static}[dir=ltr] .md-nav--primary .md-nav--secondary .md-nav .md-nav__link{padding-left:1.4rem}[dir=rtl] .md-nav--primary .md-nav--secondary .md-nav .md-nav__link{padding-right:1.4rem}[dir=ltr] .md-nav--primary .md-nav--secondary .md-nav .md-nav .md-nav__link{padding-left:2rem}[dir=rtl] .md-nav--primary .md-nav--secondary .md-nav .md-nav .md-nav__link{padding-right:2rem}[dir=ltr] .md-nav--primary .md-nav--secondary .md-nav .md-nav .md-nav .md-nav__link{padding-left:2.6rem}[dir=rtl] .md-nav--primary .md-nav--secondary .md-nav .md-nav .md-nav .md-nav__link{padding-right:2.6rem}[dir=ltr] .md-nav--primary .md-nav--secondary .md-nav .md-nav .md-nav .md-nav .md-nav__link{padding-left:3.2rem}[dir=rtl] .md-nav--primary .md-nav--secondary .md-nav .md-nav .md-nav .md-nav .md-nav__link{padding-right:3.2rem}.md-nav--secondary{background-color:initial}.md-nav__toggle~.md-nav{display:flex;opacity:0;transform:translateX(100%);transition:transform .25s cubic-bezier(.8,0,.6,1),opacity 125ms 50ms}[dir=rtl] .md-nav__toggle~.md-nav{transform:translateX(-100%)}.md-nav__toggle:checked~.md-nav{opacity:1;transform:translateX(0);transition:transform .25s cubic-bezier(.4,0,.2,1),opacity 125ms 125ms}.md-nav__toggle:checked~.md-nav>.md-nav__list{-webkit-backface-visibility:hidden;backface-visibility:hidden}}@media screen and (max-width:59.984375em){.md-nav--primary .md-nav__link[for=__toc]{display:flex}.md-nav--primary .md-nav__link[for=__toc] .md-icon:after{content:""}.md-nav--primary .md-nav__link[for=__toc]+.md-nav__link{display:none}.md-nav--primary .md-nav__link[for=__toc]~.md-nav{display:flex}.md-nav__source{background-color:var(--md-primary-fg-color--dark);color:var(--md-primary-bg-color);display:block;padding:0 .2rem}}@media screen and (min-width:60em) and (max-width:76.234375em){.md-nav--integrated .md-nav__link[for=__toc]{display:flex}.md-nav--integrated .md-nav__link[for=__toc] .md-icon:after{content:""}.md-nav--integrated .md-nav__link[for=__toc]+.md-nav__link{display:none}.md-nav--integrated .md-nav__link[for=__toc]~.md-nav{display:flex}}@media screen and (min-width:60em){.md-nav{margin-bottom:-.4rem}.md-nav--secondary .md-nav__title{background:var(--md-default-bg-color);box-shadow:0 0 .4rem .4rem var(--md-default-bg-color);position:sticky;top:0;z-index:1}.md-nav--secondary .md-nav__title[for=__toc]{scroll-snap-align:start}.md-nav--secondary .md-nav__title .md-nav__icon{display:none}[dir=ltr] .md-nav--secondary .md-nav__list{padding-left:.6rem}[dir=rtl] .md-nav--secondary .md-nav__list{padding-right:.6rem}.md-nav--secondary .md-nav__list{padding-bottom:.4rem}[dir=ltr] .md-nav--secondary .md-nav__item>.md-nav__link{margin-right:.4rem}[dir=rtl] .md-nav--secondary .md-nav__item>.md-nav__link{margin-left:.4rem}}@media screen and (min-width:76.25em){.md-nav{margin-bottom:-.4rem;transition:max-height .25s cubic-bezier(.86,0,.07,1)}.md-nav--primary .md-nav__title{background:var(--md-default-bg-color);box-shadow:0 0 .4rem .4rem var(--md-default-bg-color);position:sticky;top:0;z-index:1}.md-nav--primary .md-nav__title[for=__drawer]{scroll-snap-align:start}.md-nav--primary .md-nav__title .md-nav__icon{display:none}[dir=ltr] .md-nav--primary .md-nav__list{padding-left:.6rem}[dir=rtl] .md-nav--primary .md-nav__list{padding-right:.6rem}.md-nav--primary .md-nav__list{padding-bottom:.4rem}[dir=ltr] .md-nav--primary .md-nav__item>.md-nav__link{margin-right:.4rem}[dir=rtl] .md-nav--primary .md-nav__item>.md-nav__link{margin-left:.4rem}.md-nav__toggle~.md-nav{display:grid;grid-template-rows:0fr;opacity:0;transition:grid-template-rows .25s cubic-bezier(.86,0,.07,1),opacity .25s,visibility 0ms .25s;visibility:collapse}.md-nav__toggle~.md-nav>.md-nav__list{overflow:hidden}.md-nav__toggle.md-toggle--indeterminate~.md-nav,.md-nav__toggle:checked~.md-nav{grid-template-rows:1fr;opacity:1;transition:grid-template-rows .25s cubic-bezier(.86,0,.07,1),opacity .15s .1s,visibility 0ms;visibility:visible}.md-nav__toggle.md-toggle--indeterminate~.md-nav{transition:none}.md-nav__item--nested>.md-nav>.md-nav__title{display:none}.md-nav__item--section{display:block;margin:1.25em 0}.md-nav__item--section:last-child{margin-bottom:0}.md-nav__item--section>.md-nav__link{font-weight:700}.md-nav__item--section>.md-nav__link[for]{color:var(--md-default-fg-color--light)}.md-nav__item--section>.md-nav__link:not(.md-nav__container){pointer-events:none}.md-nav__item--section>.md-nav__link .md-icon,.md-nav__item--section>.md-nav__link>[for]{display:none}[dir=ltr] .md-nav__item--section>.md-nav{margin-left:-.6rem}[dir=rtl] .md-nav__item--section>.md-nav{margin-right:-.6rem}.md-nav__item--section>.md-nav{display:block;opacity:1;visibility:visible}.md-nav__item--section>.md-nav>.md-nav__list>.md-nav__item{padding:0}.md-nav__icon{border-radius:100%;height:.9rem;transition:background-color .25s;width:.9rem}.md-nav__icon:hover{background-color:var(--md-accent-fg-color--transparent)}.md-nav__icon:after{background-color:currentcolor;border-radius:100%;content:"";display:inline-block;height:100%;-webkit-mask-image:var(--md-nav-icon--next);mask-image:var(--md-nav-icon--next);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;transition:transform .25s;vertical-align:-.1rem;width:100%}[dir=rtl] .md-nav__icon:after{transform:rotate(180deg)}.md-nav__item--nested .md-nav__toggle:checked~.md-nav__link .md-nav__icon:after,.md-nav__item--nested .md-toggle--indeterminate~.md-nav__link .md-nav__icon:after{transform:rotate(90deg)}.md-nav--lifted>.md-nav__list>.md-nav__item,.md-nav--lifted>.md-nav__title{display:none}.md-nav--lifted>.md-nav__list>.md-nav__item--active{display:block}.md-nav--lifted>.md-nav__list>.md-nav__item--active>.md-nav__link{background:var(--md-default-bg-color);box-shadow:0 0 .4rem .4rem var(--md-default-bg-color);margin-top:0;position:sticky;top:0;z-index:1}.md-nav--lifted>.md-nav__list>.md-nav__item--active>.md-nav__link:not(.md-nav__container){pointer-events:none}.md-nav--lifted>.md-nav__list>.md-nav__item--active.md-nav__item--section{margin:0}[dir=ltr] .md-nav--lifted>.md-nav__list>.md-nav__item>.md-nav:not(.md-nav--secondary){margin-left:-.6rem}[dir=rtl] .md-nav--lifted>.md-nav__list>.md-nav__item>.md-nav:not(.md-nav--secondary){margin-right:-.6rem}.md-nav--lifted>.md-nav__list>.md-nav__item>[for]{color:var(--md-default-fg-color--light)}.md-nav--lifted .md-nav[data-md-level="1"]{grid-template-rows:1fr;opacity:1;visibility:visible}[dir=ltr] .md-nav--integrated>.md-nav__list>.md-nav__item--active .md-nav--secondary{border-left:.05rem solid var(--md-primary-fg-color)}[dir=rtl] .md-nav--integrated>.md-nav__list>.md-nav__item--active .md-nav--secondary{border-right:.05rem solid var(--md-primary-fg-color)}.md-nav--integrated>.md-nav__list>.md-nav__item--active .md-nav--secondary{display:block;margin-bottom:1.25em;opacity:1;visibility:visible}.md-nav--integrated>.md-nav__list>.md-nav__item--active .md-nav--secondary>.md-nav__list{overflow:visible;padding-bottom:0}.md-nav--integrated>.md-nav__list>.md-nav__item--active .md-nav--secondary>.md-nav__title{display:none}}.md-pagination{font-size:.8rem;font-weight:700;gap:.4rem}.md-pagination,.md-pagination>*{align-items:center;display:flex;justify-content:center}.md-pagination>*{border-radius:.2rem;height:1.8rem;min-width:1.8rem;text-align:center}.md-pagination__current{background-color:var(--md-default-fg-color--lightest);color:var(--md-default-fg-color--light)}.md-pagination__link{transition:color 125ms,background-color 125ms}.md-pagination__link:focus,.md-pagination__link:hover{background-color:var(--md-accent-fg-color--transparent);color:var(--md-accent-fg-color)}.md-pagination__link:focus svg,.md-pagination__link:hover svg{color:var(--md-accent-fg-color)}.md-pagination__link.focus-visible{outline-color:var(--md-accent-fg-color);outline-offset:.2rem}.md-pagination__link svg{fill:currentcolor;color:var(--md-default-fg-color--lighter);display:block;max-height:100%;width:1.2rem}.md-post__back{border-bottom:.05rem solid var(--md-default-fg-color--lightest);margin-bottom:1.2rem;padding-bottom:1.2rem}@media screen and (max-width:76.234375em){.md-post__back{display:none}}[dir=rtl] .md-post__back svg{transform:scaleX(-1)}.md-post__authors{display:flex;flex-direction:column;gap:.6rem;margin:0 .6rem 1.2rem}.md-post .md-post__meta a{transition:color 125ms}.md-post .md-post__meta a:focus,.md-post .md-post__meta a:hover{color:var(--md-accent-fg-color)}.md-post__title{color:var(--md-default-fg-color--light);font-weight:700}.md-post--excerpt{margin-bottom:3.2rem}.md-post--excerpt .md-post__header{align-items:center;display:flex;gap:.6rem;min-height:1.6rem}.md-post--excerpt .md-post__authors{align-items:center;display:inline-flex;flex-direction:row;gap:.2rem;margin:0;min-height:2.4rem}[dir=ltr] .md-post--excerpt .md-post__meta .md-meta__list{margin-right:.4rem}[dir=rtl] .md-post--excerpt .md-post__meta .md-meta__list{margin-left:.4rem}.md-post--excerpt .md-post__content>:first-child{--md-scroll-margin:6rem;margin-top:0}.md-post>.md-nav--secondary{margin:1em 0}.md-profile{align-items:center;display:flex;font-size:.7rem;gap:.6rem;line-height:1.4;width:100%}.md-profile__description{flex-grow:1}.md-content--post{display:flex}@media screen and (max-width:76.234375em){.md-content--post{flex-flow:column-reverse}}.md-content--post>.md-content__inner{min-width:0}@media screen and (min-width:76.25em){[dir=ltr] .md-content--post>.md-content__inner{margin-left:1.2rem}[dir=rtl] .md-content--post>.md-content__inner{margin-right:1.2rem}}@media screen and (max-width:76.234375em){.md-sidebar.md-sidebar--post{padding:0;position:static;width:100%}.md-sidebar.md-sidebar--post .md-sidebar__scrollwrap{overflow:visible}.md-sidebar.md-sidebar--post .md-sidebar__inner{padding:0}.md-sidebar.md-sidebar--post .md-post__meta{margin-left:.6rem;margin-right:.6rem}.md-sidebar.md-sidebar--post .md-nav__item{border:none;display:inline}.md-sidebar.md-sidebar--post .md-nav__list{display:inline-flex;flex-wrap:wrap;gap:.6rem;padding-bottom:.6rem;padding-top:.6rem}.md-sidebar.md-sidebar--post .md-nav__link{padding:0}.md-sidebar.md-sidebar--post .md-nav{height:auto;margin-bottom:0;position:static}}:root{--md-progress-value:0;--md-progress-delay:400ms}.md-progress{background:var(--md-primary-bg-color);height:.075rem;opacity:min(clamp(0,var(--md-progress-value),1),clamp(0,100 - var(--md-progress-value),1));position:fixed;top:0;transform:scaleX(calc(var(--md-progress-value)*1%));transform-origin:left;transition:transform .5s cubic-bezier(.19,1,.22,1),opacity .25s var(--md-progress-delay);width:100%;z-index:4}:root{--md-search-result-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M14 2H6a2 2 0 0 0-2 2v16a2 2 0 0 0 2 2h7c-.41-.25-.8-.56-1.14-.9-.33-.33-.61-.7-.86-1.1H6V4h7v5h5v1.18c.71.16 1.39.43 2 .82V8zm6.31 16.9c1.33-2.11.69-4.9-1.4-6.22-2.11-1.33-4.91-.68-6.22 1.4-1.34 2.11-.69 4.89 1.4 6.22 1.46.93 3.32.93 4.79.02L22 23.39 23.39 22zm-3.81.1a2.5 2.5 0 0 1-2.5-2.5 2.5 2.5 0 0 1 2.5-2.5 2.5 2.5 0 0 1 2.5 2.5 2.5 2.5 0 0 1-2.5 2.5"/></svg>')}.md-search{position:relative}@media screen and (min-width:60em){.md-search{padding:.2rem 0}}.no-js .md-search{display:none}.md-search__overlay{opacity:0;z-index:1}@media screen and (max-width:59.984375em){[dir=ltr] .md-search__overlay{left:-2.2rem}[dir=rtl] .md-search__overlay{right:-2.2rem}.md-search__overlay{background-color:var(--md-default-bg-color);border-radius:1rem;height:2rem;overflow:hidden;pointer-events:none;position:absolute;top:-1rem;transform-origin:center;transition:transform .3s .1s,opacity .2s .2s;width:2rem}[data-md-toggle=search]:checked~.md-header .md-search__overlay{opacity:1;transition:transform .4s,opacity .1s}}@media screen and (min-width:60em){[dir=ltr] .md-search__overlay{left:0}[dir=rtl] .md-search__overlay{right:0}.md-search__overlay{background-color:#0000008a;cursor:pointer;height:0;position:fixed;top:0;transition:width 0ms .25s,height 0ms .25s,opacity .25s;width:0}[data-md-toggle=search]:checked~.md-header .md-search__overlay{height:200vh;opacity:1;transition:width 0ms,height 0ms,opacity .25s;width:100%}}@media screen and (max-width:29.984375em){[data-md-toggle=search]:checked~.md-header .md-search__overlay{transform:scale(45)}}@media screen and (min-width:30em) and (max-width:44.984375em){[data-md-toggle=search]:checked~.md-header .md-search__overlay{transform:scale(60)}}@media screen and (min-width:45em) and (max-width:59.984375em){[data-md-toggle=search]:checked~.md-header .md-search__overlay{transform:scale(75)}}.md-search__inner{-webkit-backface-visibility:hidden;backface-visibility:hidden}@media screen and (max-width:59.984375em){[dir=ltr] .md-search__inner{left:0}[dir=rtl] .md-search__inner{right:0}.md-search__inner{height:0;opacity:0;overflow:hidden;position:fixed;top:0;transform:translateX(5%);transition:width 0ms .3s,height 0ms .3s,transform .15s cubic-bezier(.4,0,.2,1) .15s,opacity .15s .15s;width:0;z-index:2}[dir=rtl] .md-search__inner{transform:translateX(-5%)}[data-md-toggle=search]:checked~.md-header .md-search__inner{height:100%;opacity:1;transform:translateX(0);transition:width 0ms 0ms,height 0ms 0ms,transform .15s cubic-bezier(.1,.7,.1,1) .15s,opacity .15s .15s;width:100%}}@media screen and (min-width:60em){[dir=ltr] .md-search__inner{float:right}[dir=rtl] .md-search__inner{float:left}.md-search__inner{padding:.1rem 0;position:relative;transition:width .25s cubic-bezier(.1,.7,.1,1);width:11.7rem}}@media screen and (min-width:60em) and (max-width:76.234375em){[data-md-toggle=search]:checked~.md-header .md-search__inner{width:23.4rem}}@media screen and (min-width:76.25em){[data-md-toggle=search]:checked~.md-header .md-search__inner{width:34.4rem}}.md-search__form{background-color:var(--md-default-bg-color);box-shadow:0 0 .6rem #0000;height:2.4rem;position:relative;transition:color .25s,background-color .25s;z-index:2}@media screen and (min-width:60em){.md-search__form{background-color:#00000042;border-radius:.1rem;height:1.8rem}.md-search__form:hover{background-color:#ffffff1f}}[data-md-toggle=search]:checked~.md-header .md-search__form{background-color:var(--md-default-bg-color);border-radius:.1rem .1rem 0 0;box-shadow:0 0 .6rem #00000012;color:var(--md-default-fg-color)}[dir=ltr] .md-search__input{padding-left:3.6rem;padding-right:2.2rem}[dir=rtl] .md-search__input{padding-left:2.2rem;padding-right:3.6rem}.md-search__input{background:#0000;font-size:.9rem;height:100%;position:relative;text-overflow:ellipsis;width:100%;z-index:2}.md-search__input::placeholder{transition:color .25s}.md-search__input::placeholder,.md-search__input~.md-search__icon{color:var(--md-default-fg-color--light)}.md-search__input::-ms-clear{display:none}@media screen and (max-width:59.984375em){.md-search__input{font-size:.9rem;height:2.4rem;width:100%}}@media screen and (min-width:60em){[dir=ltr] .md-search__input{padding-left:2.2rem}[dir=rtl] .md-search__input{padding-right:2.2rem}.md-search__input{color:inherit;font-size:.8rem}.md-search__input::placeholder{color:var(--md-primary-bg-color--light)}.md-search__input+.md-search__icon{color:var(--md-primary-bg-color)}[data-md-toggle=search]:checked~.md-header .md-search__input{text-overflow:clip}[data-md-toggle=search]:checked~.md-header .md-search__input+.md-search__icon{color:var(--md-default-fg-color--light)}[data-md-toggle=search]:checked~.md-header .md-search__input::placeholder{color:#0000}}.md-search__icon{cursor:pointer;display:inline-block;height:1.2rem;transition:color .25s,opacity .25s;width:1.2rem}.md-search__icon:hover{opacity:.7}[dir=ltr] .md-search__icon[for=__search]{left:.5rem}[dir=rtl] .md-search__icon[for=__search]{right:.5rem}.md-search__icon[for=__search]{position:absolute;top:.3rem;z-index:2}[dir=rtl] .md-search__icon[for=__search] svg{transform:scaleX(-1)}@media screen and (max-width:59.984375em){[dir=ltr] .md-search__icon[for=__search]{left:.8rem}[dir=rtl] .md-search__icon[for=__search]{right:.8rem}.md-search__icon[for=__search]{top:.6rem}.md-search__icon[for=__search] svg:first-child{display:none}}@media screen and (min-width:60em){.md-search__icon[for=__search]{pointer-events:none}.md-search__icon[for=__search] svg:last-child{display:none}}[dir=ltr] .md-search__options{right:.5rem}[dir=rtl] .md-search__options{left:.5rem}.md-search__options{pointer-events:none;position:absolute;top:.3rem;z-index:2}@media screen and (max-width:59.984375em){[dir=ltr] .md-search__options{right:.8rem}[dir=rtl] .md-search__options{left:.8rem}.md-search__options{top:.6rem}}[dir=ltr] .md-search__options>.md-icon{margin-left:.2rem}[dir=rtl] .md-search__options>.md-icon{margin-right:.2rem}.md-search__options>.md-icon{color:var(--md-default-fg-color--light);opacity:0;transform:scale(.75);transition:transform .15s cubic-bezier(.1,.7,.1,1),opacity .15s}.md-search__options>.md-icon:not(.focus-visible){-webkit-tap-highlight-color:transparent;outline:none}[data-md-toggle=search]:checked~.md-header .md-search__input:valid~.md-search__options>.md-icon{opacity:1;pointer-events:auto;transform:scale(1)}[data-md-toggle=search]:checked~.md-header .md-search__input:valid~.md-search__options>.md-icon:hover{opacity:.7}[dir=ltr] .md-search__suggest{padding-left:3.6rem;padding-right:2.2rem}[dir=rtl] .md-search__suggest{padding-left:2.2rem;padding-right:3.6rem}.md-search__suggest{align-items:center;color:var(--md-default-fg-color--lighter);display:flex;font-size:.9rem;height:100%;opacity:0;position:absolute;top:0;transition:opacity 50ms;white-space:nowrap;width:100%}@media screen and (min-width:60em){[dir=ltr] .md-search__suggest{padding-left:2.2rem}[dir=rtl] .md-search__suggest{padding-right:2.2rem}.md-search__suggest{font-size:.8rem}}[data-md-toggle=search]:checked~.md-header .md-search__suggest{opacity:1;transition:opacity .3s .1s}[dir=ltr] .md-search__output{border-bottom-left-radius:.1rem}[dir=ltr] .md-search__output,[dir=rtl] .md-search__output{border-bottom-right-radius:.1rem}[dir=rtl] .md-search__output{border-bottom-left-radius:.1rem}.md-search__output{overflow:hidden;position:absolute;width:100%;z-index:1}@media screen and (max-width:59.984375em){.md-search__output{bottom:0;top:2.4rem}}@media screen and (min-width:60em){.md-search__output{opacity:0;top:1.9rem;transition:opacity .4s}[data-md-toggle=search]:checked~.md-header .md-search__output{box-shadow:var(--md-shadow-z3);opacity:1}}.md-search__scrollwrap{-webkit-backface-visibility:hidden;backface-visibility:hidden;background-color:var(--md-default-bg-color);height:100%;overflow-y:auto;touch-action:pan-y}@media (-webkit-max-device-pixel-ratio:1),(max-resolution:1dppx){.md-search__scrollwrap{transform:translateZ(0)}}@media screen and (min-width:60em) and (max-width:76.234375em){.md-search__scrollwrap{width:23.4rem}}@media screen and (min-width:76.25em){.md-search__scrollwrap{width:34.4rem}}@media screen and (min-width:60em){.md-search__scrollwrap{max-height:0;scrollbar-color:var(--md-default-fg-color--lighter) #0000;scrollbar-width:thin}[data-md-toggle=search]:checked~.md-header .md-search__scrollwrap{max-height:75vh}.md-search__scrollwrap:hover{scrollbar-color:var(--md-accent-fg-color) #0000}.md-search__scrollwrap::-webkit-scrollbar{height:.2rem;width:.2rem}.md-search__scrollwrap::-webkit-scrollbar-thumb{background-color:var(--md-default-fg-color--lighter)}.md-search__scrollwrap::-webkit-scrollbar-thumb:hover{background-color:var(--md-accent-fg-color)}}.md-search-result{color:var(--md-default-fg-color);word-break:break-word}.md-search-result__meta{background-color:var(--md-default-fg-color--lightest);color:var(--md-default-fg-color--light);font-size:.64rem;line-height:1.8rem;padding:0 .8rem;scroll-snap-align:start}@media screen and (min-width:60em){[dir=ltr] .md-search-result__meta{padding-left:2.2rem}[dir=rtl] .md-search-result__meta{padding-right:2.2rem}}.md-search-result__list{list-style:none;margin:0;padding:0;-webkit-user-select:none;user-select:none}.md-search-result__item{box-shadow:0 -.05rem var(--md-default-fg-color--lightest)}.md-search-result__item:first-child{box-shadow:none}.md-search-result__link{display:block;outline:none;scroll-snap-align:start;transition:background-color .25s}.md-search-result__link:focus,.md-search-result__link:hover{background-color:var(--md-accent-fg-color--transparent)}.md-search-result__link:last-child p:last-child{margin-bottom:.6rem}.md-search-result__more>summary{cursor:pointer;display:block;outline:none;position:sticky;scroll-snap-align:start;top:0;z-index:1}.md-search-result__more>summary::marker{display:none}.md-search-result__more>summary::-webkit-details-marker{display:none}.md-search-result__more>summary>div{color:var(--md-typeset-a-color);font-size:.64rem;padding:.75em .8rem;transition:color .25s,background-color .25s}@media screen and (min-width:60em){[dir=ltr] .md-search-result__more>summary>div{padding-left:2.2rem}[dir=rtl] .md-search-result__more>summary>div{padding-right:2.2rem}}.md-search-result__more>summary:focus>div,.md-search-result__more>summary:hover>div{background-color:var(--md-accent-fg-color--transparent);color:var(--md-accent-fg-color)}.md-search-result__more[open]>summary{background-color:var(--md-default-bg-color)}.md-search-result__article{overflow:hidden;padding:0 .8rem;position:relative}@media screen and (min-width:60em){[dir=ltr] .md-search-result__article{padding-left:2.2rem}[dir=rtl] .md-search-result__article{padding-right:2.2rem}}[dir=ltr] .md-search-result__icon{left:0}[dir=rtl] .md-search-result__icon{right:0}.md-search-result__icon{color:var(--md-default-fg-color--light);height:1.2rem;margin:.5rem;position:absolute;width:1.2rem}@media screen and (max-width:59.984375em){.md-search-result__icon{display:none}}.md-search-result__icon:after{background-color:currentcolor;content:"";display:inline-block;height:100%;-webkit-mask-image:var(--md-search-result-icon);mask-image:var(--md-search-result-icon);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;width:100%}[dir=rtl] .md-search-result__icon:after{transform:scaleX(-1)}.md-search-result .md-typeset{color:var(--md-default-fg-color--light);font-size:.64rem;line-height:1.6}.md-search-result .md-typeset h1{color:var(--md-default-fg-color);font-size:.8rem;font-weight:400;line-height:1.4;margin:.55rem 0}.md-search-result .md-typeset h1 mark{text-decoration:none}.md-search-result .md-typeset h2{color:var(--md-default-fg-color);font-size:.64rem;font-weight:700;line-height:1.6;margin:.5em 0}.md-search-result .md-typeset h2 mark{text-decoration:none}.md-search-result__terms{color:var(--md-default-fg-color);display:block;font-size:.64rem;font-style:italic;margin:.5em 0}.md-search-result mark{background-color:initial;color:var(--md-accent-fg-color);text-decoration:underline}.md-select{position:relative;z-index:1}.md-select__inner{background-color:var(--md-default-bg-color);border-radius:.1rem;box-shadow:var(--md-shadow-z2);color:var(--md-default-fg-color);left:50%;margin-top:.2rem;max-height:0;opacity:0;position:absolute;top:calc(100% - .2rem);transform:translate3d(-50%,.3rem,0);transition:transform .25s 375ms,opacity .25s .25s,max-height 0ms .5s}.md-select:focus-within .md-select__inner,.md-select:hover .md-select__inner{max-height:10rem;opacity:1;transform:translate3d(-50%,0,0);transition:transform .25s cubic-bezier(.1,.7,.1,1),opacity .25s,max-height 0ms}.md-select__inner:after{border-bottom:.2rem solid #0000;border-bottom-color:var(--md-default-bg-color);border-left:.2rem solid #0000;border-right:.2rem solid #0000;border-top:0;content:"";height:0;left:50%;margin-left:-.2rem;margin-top:-.2rem;position:absolute;top:0;width:0}.md-select__list{border-radius:.1rem;font-size:.8rem;list-style-type:none;margin:0;max-height:inherit;overflow:auto;padding:0}.md-select__item{line-height:1.8rem}[dir=ltr] .md-select__link{padding-left:.6rem;padding-right:1.2rem}[dir=rtl] .md-select__link{padding-left:1.2rem;padding-right:.6rem}.md-select__link{cursor:pointer;display:block;outline:none;scroll-snap-align:start;transition:background-color .25s,color .25s;width:100%}.md-select__link:focus,.md-select__link:hover{color:var(--md-accent-fg-color)}.md-select__link:focus{background-color:var(--md-default-fg-color--lightest)}.md-sidebar{align-self:flex-start;flex-shrink:0;padding:1.2rem 0;position:sticky;top:2.4rem;width:12.1rem}@media print{.md-sidebar{display:none}}@media screen and (max-width:76.234375em){[dir=ltr] .md-sidebar--primary{left:-12.1rem}[dir=rtl] .md-sidebar--primary{right:-12.1rem}.md-sidebar--primary{background-color:var(--md-default-bg-color);display:block;height:100%;position:fixed;top:0;transform:translateX(0);transition:transform .25s cubic-bezier(.4,0,.2,1),box-shadow .25s;width:12.1rem;z-index:5}[data-md-toggle=drawer]:checked~.md-container .md-sidebar--primary{box-shadow:var(--md-shadow-z3);transform:translateX(12.1rem)}[dir=rtl] [data-md-toggle=drawer]:checked~.md-container .md-sidebar--primary{transform:translateX(-12.1rem)}.md-sidebar--primary .md-sidebar__scrollwrap{bottom:0;left:0;margin:0;overflow:hidden;position:absolute;right:0;scroll-snap-type:none;top:0}}@media screen and (min-width:76.25em){.md-sidebar{height:0}.no-js .md-sidebar{height:auto}.md-header--lifted~.md-container .md-sidebar{top:4.8rem}}.md-sidebar--secondary{display:none;order:2}@media screen and (min-width:60em){.md-sidebar--secondary{height:0}.no-js .md-sidebar--secondary{height:auto}.md-sidebar--secondary:not([hidden]){display:block}.md-sidebar--secondary .md-sidebar__scrollwrap{touch-action:pan-y}}.md-sidebar__scrollwrap{scrollbar-gutter:stable;-webkit-backface-visibility:hidden;backface-visibility:hidden;margin:0 .2rem;overflow-y:auto;scrollbar-color:var(--md-default-fg-color--lighter) #0000;scrollbar-width:thin}.md-sidebar__scrollwrap::-webkit-scrollbar{height:.2rem;width:.2rem}.md-sidebar__scrollwrap:focus-within,.md-sidebar__scrollwrap:hover{scrollbar-color:var(--md-accent-fg-color) #0000}.md-sidebar__scrollwrap:focus-within::-webkit-scrollbar-thumb,.md-sidebar__scrollwrap:hover::-webkit-scrollbar-thumb{background-color:var(--md-default-fg-color--lighter)}.md-sidebar__scrollwrap:focus-within::-webkit-scrollbar-thumb:hover,.md-sidebar__scrollwrap:hover::-webkit-scrollbar-thumb:hover{background-color:var(--md-accent-fg-color)}@supports selector(::-webkit-scrollbar){.md-sidebar__scrollwrap{scrollbar-gutter:auto}[dir=ltr] .md-sidebar__inner{padding-right:calc(100% - 11.5rem)}[dir=rtl] .md-sidebar__inner{padding-left:calc(100% - 11.5rem)}}@media screen and (max-width:76.234375em){.md-overlay{background-color:#0000008a;height:0;opacity:0;position:fixed;top:0;transition:width 0ms .25s,height 0ms .25s,opacity .25s;width:0;z-index:5}[data-md-toggle=drawer]:checked~.md-overlay{height:100%;opacity:1;transition:width 0ms,height 0ms,opacity .25s;width:100%}}@keyframes facts{0%{height:0}to{height:.65rem}}@keyframes fact{0%{opacity:0;transform:translateY(100%)}50%{opacity:0}to{opacity:1;transform:translateY(0)}}:root{--md-source-forks-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><path d="M5 5.372v.878c0 .414.336.75.75.75h4.5a.75.75 0 0 0 .75-.75v-.878a2.25 2.25 0 1 1 1.5 0v.878a2.25 2.25 0 0 1-2.25 2.25h-1.5v2.128a2.251 2.251 0 1 1-1.5 0V8.5h-1.5A2.25 2.25 0 0 1 3.5 6.25v-.878a2.25 2.25 0 1 1 1.5 0M5 3.25a.75.75 0 1 0-1.5 0 .75.75 0 0 0 1.5 0m6.75.75a.75.75 0 1 0 0-1.5.75.75 0 0 0 0 1.5m-3 8.75a.75.75 0 1 0-1.5 0 .75.75 0 0 0 1.5 0"/></svg>');--md-source-repositories-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><path d="M2 2.5A2.5 2.5 0 0 1 4.5 0h8.75a.75.75 0 0 1 .75.75v12.5a.75.75 0 0 1-.75.75h-2.5a.75.75 0 0 1 0-1.5h1.75v-2h-8a1 1 0 0 0-.714 1.7.75.75 0 1 1-1.072 1.05A2.5 2.5 0 0 1 2 11.5Zm10.5-1h-8a1 1 0 0 0-1 1v6.708A2.5 2.5 0 0 1 4.5 9h8ZM5 12.25a.25.25 0 0 1 .25-.25h3.5a.25.25 0 0 1 .25.25v3.25a.25.25 0 0 1-.4.2l-1.45-1.087a.25.25 0 0 0-.3 0L5.4 15.7a.25.25 0 0 1-.4-.2Z"/></svg>');--md-source-stars-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><path d="M8 .25a.75.75 0 0 1 .673.418l1.882 3.815 4.21.612a.75.75 0 0 1 .416 1.279l-3.046 2.97.719 4.192a.751.751 0 0 1-1.088.791L8 12.347l-3.766 1.98a.75.75 0 0 1-1.088-.79l.72-4.194L.818 6.374a.75.75 0 0 1 .416-1.28l4.21-.611L7.327.668A.75.75 0 0 1 8 .25m0 2.445L6.615 5.5a.75.75 0 0 1-.564.41l-3.097.45 2.24 2.184a.75.75 0 0 1 .216.664l-.528 3.084 2.769-1.456a.75.75 0 0 1 .698 0l2.77 1.456-.53-3.084a.75.75 0 0 1 .216-.664l2.24-2.183-3.096-.45a.75.75 0 0 1-.564-.41z"/></svg>');--md-source-version-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><path d="M1 7.775V2.75C1 1.784 1.784 1 2.75 1h5.025c.464 0 .91.184 1.238.513l6.25 6.25a1.75 1.75 0 0 1 0 2.474l-5.026 5.026a1.75 1.75 0 0 1-2.474 0l-6.25-6.25A1.75 1.75 0 0 1 1 7.775m1.5 0c0 .066.026.13.073.177l6.25 6.25a.25.25 0 0 0 .354 0l5.025-5.025a.25.25 0 0 0 0-.354l-6.25-6.25a.25.25 0 0 0-.177-.073H2.75a.25.25 0 0 0-.25.25ZM6 5a1 1 0 1 1 0 2 1 1 0 0 1 0-2"/></svg>')}.md-source{-webkit-backface-visibility:hidden;backface-visibility:hidden;display:block;font-size:.65rem;line-height:1.2;outline-color:var(--md-accent-fg-color);transition:opacity .25s;white-space:nowrap}.md-source:hover{opacity:.7}.md-source__icon{display:inline-block;height:2.4rem;vertical-align:middle;width:2rem}[dir=ltr] .md-source__icon svg{margin-left:.6rem}[dir=rtl] .md-source__icon svg{margin-right:.6rem}.md-source__icon svg{margin-top:.6rem}[dir=ltr] .md-source__icon+.md-source__repository{padding-left:2rem}[dir=rtl] .md-source__icon+.md-source__repository{padding-right:2rem}[dir=ltr] .md-source__icon+.md-source__repository{margin-left:-2rem}[dir=rtl] .md-source__icon+.md-source__repository{margin-right:-2rem}[dir=ltr] .md-source__repository{margin-left:.6rem}[dir=rtl] .md-source__repository{margin-right:.6rem}.md-source__repository{display:inline-block;max-width:calc(100% - 1.2rem);overflow:hidden;text-overflow:ellipsis;vertical-align:middle}.md-source__facts{display:flex;font-size:.55rem;gap:.4rem;list-style-type:none;margin:.1rem 0 0;opacity:.75;overflow:hidden;padding:0;width:100%}.md-source__repository--active .md-source__facts{animation:facts .25s ease-in}.md-source__fact{overflow:hidden;text-overflow:ellipsis}.md-source__repository--active .md-source__fact{animation:fact .4s ease-out}[dir=ltr] .md-source__fact:before{margin-right:.1rem}[dir=rtl] .md-source__fact:before{margin-left:.1rem}.md-source__fact:before{background-color:currentcolor;content:"";display:inline-block;height:.6rem;-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;vertical-align:text-top;width:.6rem}.md-source__fact:nth-child(1n+2){flex-shrink:0}.md-source__fact--version:before{-webkit-mask-image:var(--md-source-version-icon);mask-image:var(--md-source-version-icon)}.md-source__fact--stars:before{-webkit-mask-image:var(--md-source-stars-icon);mask-image:var(--md-source-stars-icon)}.md-source__fact--forks:before{-webkit-mask-image:var(--md-source-forks-icon);mask-image:var(--md-source-forks-icon)}.md-source__fact--repositories:before{-webkit-mask-image:var(--md-source-repositories-icon);mask-image:var(--md-source-repositories-icon)}.md-source-file{margin:1em 0}[dir=ltr] .md-source-file__fact{margin-right:.6rem}[dir=rtl] .md-source-file__fact{margin-left:.6rem}.md-source-file__fact{align-items:center;color:var(--md-default-fg-color--light);display:inline-flex;font-size:.68rem;gap:.3rem}.md-source-file__fact .md-icon{flex-shrink:0;margin-bottom:.05rem}[dir=ltr] .md-source-file__fact .md-author{float:left}[dir=rtl] .md-source-file__fact .md-author{float:right}.md-source-file__fact .md-author{margin-right:.2rem}.md-source-file__fact svg{width:.9rem}:root{--md-status:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M11 9h2V7h-2m1 13c-4.41 0-8-3.59-8-8s3.59-8 8-8 8 3.59 8 8-3.59 8-8 8m0-18A10 10 0 0 0 2 12a10 10 0 0 0 10 10 10 10 0 0 0 10-10A10 10 0 0 0 12 2m-1 15h2v-6h-2z"/></svg>');--md-status--new:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="m23 12-2.44-2.78.34-3.68-3.61-.82-1.89-3.18L12 3 8.6 1.54 6.71 4.72l-3.61.81.34 3.68L1 12l2.44 2.78-.34 3.69 3.61.82 1.89 3.18L12 21l3.4 1.46 1.89-3.18 3.61-.82-.34-3.68zm-10 5h-2v-2h2zm0-4h-2V7h2z"/></svg>');--md-status--deprecated:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9 3v1H4v2h1v13a2 2 0 0 0 2 2h10a2 2 0 0 0 2-2V6h1V4h-5V3zm0 5h2v9H9zm4 0h2v9h-2z"/></svg>');--md-status--encrypted:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 1 3 5v6c0 5.55 3.84 10.74 9 12 5.16-1.26 9-6.45 9-12V5zm0 6c1.4 0 2.8 1.1 2.8 2.5V11c.6 0 1.2.6 1.2 1.3v3.5c0 .6-.6 1.2-1.3 1.2H9.2c-.6 0-1.2-.6-1.2-1.3v-3.5c0-.6.6-1.2 1.2-1.2V9.5C9.2 8.1 10.6 7 12 7m0 1.2c-.8 0-1.5.5-1.5 1.3V11h3V9.5c0-.8-.7-1.3-1.5-1.3"/></svg>')}.md-status:after{background-color:var(--md-default-fg-color--light);content:"";display:inline-block;height:1.125em;-webkit-mask-image:var(--md-status);mask-image:var(--md-status);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;vertical-align:text-bottom;width:1.125em}.md-status:hover:after{background-color:currentcolor}.md-status--new:after{-webkit-mask-image:var(--md-status--new);mask-image:var(--md-status--new)}.md-status--deprecated:after{-webkit-mask-image:var(--md-status--deprecated);mask-image:var(--md-status--deprecated)}.md-status--encrypted:after{-webkit-mask-image:var(--md-status--encrypted);mask-image:var(--md-status--encrypted)}.md-tabs{background-color:var(--md-primary-fg-color);color:var(--md-primary-bg-color);display:block;line-height:1.3;overflow:auto;width:100%;z-index:3}@media print{.md-tabs{display:none}}@media screen and (max-width:76.234375em){.md-tabs{display:none}}.md-tabs[hidden]{pointer-events:none}[dir=ltr] .md-tabs__list{margin-left:.2rem}[dir=rtl] .md-tabs__list{margin-right:.2rem}.md-tabs__list{contain:content;display:flex;list-style:none;margin:0;overflow:auto;padding:0;scrollbar-width:none;white-space:nowrap}.md-tabs__list::-webkit-scrollbar{display:none}.md-tabs__item{height:2.4rem;padding-left:.6rem;padding-right:.6rem}.md-tabs__item--active .md-tabs__link{color:inherit;opacity:1}.md-tabs__link{-webkit-backface-visibility:hidden;backface-visibility:hidden;display:flex;font-size:.7rem;margin-top:.8rem;opacity:.7;outline-color:var(--md-accent-fg-color);outline-offset:.2rem;transition:transform .4s cubic-bezier(.1,.7,.1,1),opacity .25s}.md-tabs__link:focus,.md-tabs__link:hover{color:inherit;opacity:1}[dir=ltr] .md-tabs__link svg{margin-right:.4rem}[dir=rtl] .md-tabs__link svg{margin-left:.4rem}.md-tabs__link svg{fill:currentcolor;height:1.3em}.md-tabs__item:nth-child(2) .md-tabs__link{transition-delay:20ms}.md-tabs__item:nth-child(3) .md-tabs__link{transition-delay:40ms}.md-tabs__item:nth-child(4) .md-tabs__link{transition-delay:60ms}.md-tabs__item:nth-child(5) .md-tabs__link{transition-delay:80ms}.md-tabs__item:nth-child(6) .md-tabs__link{transition-delay:.1s}.md-tabs__item:nth-child(7) .md-tabs__link{transition-delay:.12s}.md-tabs__item:nth-child(8) .md-tabs__link{transition-delay:.14s}.md-tabs__item:nth-child(9) .md-tabs__link{transition-delay:.16s}.md-tabs__item:nth-child(10) .md-tabs__link{transition-delay:.18s}.md-tabs__item:nth-child(11) .md-tabs__link{transition-delay:.2s}.md-tabs__item:nth-child(12) .md-tabs__link{transition-delay:.22s}.md-tabs__item:nth-child(13) .md-tabs__link{transition-delay:.24s}.md-tabs__item:nth-child(14) .md-tabs__link{transition-delay:.26s}.md-tabs__item:nth-child(15) .md-tabs__link{transition-delay:.28s}.md-tabs__item:nth-child(16) .md-tabs__link{transition-delay:.3s}.md-tabs[hidden] .md-tabs__link{opacity:0;transform:translateY(50%);transition:transform 0ms .1s,opacity .1s}:root{--md-tag-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="m5.41 21 .71-4h-4l.35-2h4l1.06-6h-4l.35-2h4l.71-4h2l-.71 4h6l.71-4h2l-.71 4h4l-.35 2h-4l-1.06 6h4l-.35 2h-4l-.71 4h-2l.71-4h-6l-.71 4zM9.53 9l-1.06 6h6l1.06-6z"/></svg>')}.md-typeset .md-tags:not([hidden]){display:inline-flex;flex-wrap:wrap;gap:.5em;margin-bottom:.75em;margin-top:-.125em}.md-typeset .md-tag{align-items:center;background:var(--md-default-fg-color--lightest);border-radius:2.4rem;display:inline-flex;font-size:.64rem;font-size:min(.8em,.64rem);font-weight:700;gap:.5em;letter-spacing:normal;line-height:1.6;padding:.3125em .78125em}.md-typeset .md-tag[href]{-webkit-tap-highlight-color:transparent;color:inherit;outline:none;transition:color 125ms,background-color 125ms}.md-typeset .md-tag[href]:focus,.md-typeset .md-tag[href]:hover{background-color:var(--md-accent-fg-color);color:var(--md-accent-bg-color)}[id]>.md-typeset .md-tag{vertical-align:text-top}.md-typeset .md-tag-icon:before{background-color:var(--md-default-fg-color--lighter);content:"";display:inline-block;height:1.2em;-webkit-mask-image:var(--md-tag-icon);mask-image:var(--md-tag-icon);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;transition:background-color 125ms;vertical-align:text-bottom;width:1.2em}.md-typeset .md-tag-icon[href]:focus:before,.md-typeset .md-tag-icon[href]:hover:before{background-color:var(--md-accent-bg-color)}@keyframes pulse{0%{transform:scale(.95)}75%{transform:scale(1)}to{transform:scale(.95)}}:root{--md-annotation-bg-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 2A10 10 0 0 0 2 12a10 10 0 0 0 10 10 10 10 0 0 0 10-10A10 10 0 0 0 12 2"/></svg>');--md-annotation-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M17 13h-4v4h-2v-4H7v-2h4V7h2v4h4m-5-9A10 10 0 0 0 2 12a10 10 0 0 0 10 10 10 10 0 0 0 10-10A10 10 0 0 0 12 2"/></svg>')}.md-tooltip{-webkit-backface-visibility:hidden;backface-visibility:hidden;background-color:var(--md-default-bg-color);border-radius:.1rem;box-shadow:var(--md-shadow-z2);color:var(--md-default-fg-color);font-family:var(--md-text-font-family);left:clamp(var(--md-tooltip-0,0rem) + .8rem,var(--md-tooltip-x),100vw + var(--md-tooltip-0,0rem) + .8rem - var(--md-tooltip-width) - 2 * .8rem);max-width:calc(100vw - 1.6rem);opacity:0;position:absolute;top:var(--md-tooltip-y);transform:translateY(-.4rem);transition:transform 0ms .25s,opacity .25s,z-index .25s;width:var(--md-tooltip-width);z-index:0}.md-tooltip--active{opacity:1;transform:translateY(0);transition:transform .25s cubic-bezier(.1,.7,.1,1),opacity .25s,z-index 0ms;z-index:2}.md-tooltip--inline{font-weight:700;-webkit-user-select:none;user-select:none;width:auto}.md-tooltip--inline:not(.md-tooltip--active){transform:translateY(.2rem) scale(.9)}.md-tooltip--inline .md-tooltip__inner{font-size:.5rem;padding:.2rem .4rem}[hidden]+.md-tooltip--inline{display:none}.focus-visible>.md-tooltip,.md-tooltip:target{outline:var(--md-accent-fg-color) auto}.md-tooltip__inner{font-size:.64rem;padding:.8rem}.md-tooltip__inner.md-typeset>:first-child{margin-top:0}.md-tooltip__inner.md-typeset>:last-child{margin-bottom:0}.md-annotation{font-style:normal;font-weight:400;outline:none;text-align:initial;vertical-align:text-bottom;white-space:normal}[dir=rtl] .md-annotation{direction:rtl}code .md-annotation{font-family:var(--md-code-font-family);font-size:inherit}.md-annotation:not([hidden]){display:inline-block;line-height:1.25}.md-annotation__index{border-radius:.01px;cursor:pointer;display:inline-block;margin-left:.4ch;margin-right:.4ch;outline:none;overflow:hidden;position:relative;-webkit-user-select:none;user-select:none;vertical-align:text-top;z-index:0}.md-annotation .md-annotation__index{transition:z-index .25s}@media screen{.md-annotation__index{width:2.2ch}[data-md-visible]>.md-annotation__index{animation:pulse 2s infinite}.md-annotation__index:before{background:var(--md-default-bg-color);-webkit-mask-image:var(--md-annotation-bg-icon);mask-image:var(--md-annotation-bg-icon)}.md-annotation__index:after,.md-annotation__index:before{content:"";height:2.2ch;-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;position:absolute;top:-.1ch;width:2.2ch;z-index:-1}.md-annotation__index:after{background-color:var(--md-default-fg-color--lighter);-webkit-mask-image:var(--md-annotation-icon);mask-image:var(--md-annotation-icon);transform:scale(1.0001);transition:background-color .25s,transform .25s}.md-tooltip--active+.md-annotation__index:after{transform:rotate(45deg)}.md-tooltip--active+.md-annotation__index:after,:hover>.md-annotation__index:after{background-color:var(--md-accent-fg-color)}}.md-tooltip--active+.md-annotation__index{animation-play-state:paused;transition-duration:0ms;z-index:2}.md-annotation__index [data-md-annotation-id]{display:inline-block}@media print{.md-annotation__index [data-md-annotation-id]{background:var(--md-default-fg-color--lighter);border-radius:2ch;color:var(--md-default-bg-color);font-weight:700;padding:0 .6ch;white-space:nowrap}.md-annotation__index [data-md-annotation-id]:after{content:attr(data-md-annotation-id)}}.md-typeset .md-annotation-list{counter-reset:xxx;list-style:none}.md-typeset .md-annotation-list li{position:relative}[dir=ltr] .md-typeset .md-annotation-list li:before{left:-2.125em}[dir=rtl] .md-typeset .md-annotation-list li:before{right:-2.125em}.md-typeset .md-annotation-list li:before{background:var(--md-default-fg-color--lighter);border-radius:2ch;color:var(--md-default-bg-color);content:counter(xxx);counter-increment:xxx;font-size:.8875em;font-weight:700;height:2ch;line-height:1.25;min-width:2ch;padding:0 .6ch;position:absolute;text-align:center;top:.25em}:root{--md-tooltip-width:20rem;--md-tooltip-tail:0.3rem}.md-tooltip2{-webkit-backface-visibility:hidden;backface-visibility:hidden;color:var(--md-default-fg-color);font-family:var(--md-text-font-family);opacity:0;pointer-events:none;position:absolute;top:calc(var(--md-tooltip-host-y) + var(--md-tooltip-y));transform:translateY(-.4rem);transform-origin:calc(var(--md-tooltip-host-x) + var(--md-tooltip-x)) 0;transition:transform 0ms .25s,opacity .25s,z-index .25s;width:100%;z-index:0}.md-tooltip2:before{border-left:var(--md-tooltip-tail) solid #0000;border-right:var(--md-tooltip-tail) solid #0000;content:"";display:block;left:clamp(1.5 * .8rem,var(--md-tooltip-host-x) + var(--md-tooltip-x) - var(--md-tooltip-tail),100vw - 2 * var(--md-tooltip-tail) - 1.5 * .8rem);position:absolute;z-index:1}.md-tooltip2--top:before{border-top:var(--md-tooltip-tail) solid var(--md-default-bg-color);bottom:calc(var(--md-tooltip-tail)*-1 + .025rem);filter:drop-shadow(0 1px 0 hsla(0,0%,0%,.05))}.md-tooltip2--bottom:before{border-bottom:var(--md-tooltip-tail) solid var(--md-default-bg-color);filter:drop-shadow(0 -1px 0 hsla(0,0%,0%,.05));top:calc(var(--md-tooltip-tail)*-1 + .025rem)}.md-tooltip2--active{opacity:1;transform:translateY(0);transition:transform .4s cubic-bezier(0,1,.5,1),opacity .25s,z-index 0ms;z-index:2}.md-tooltip2__inner{scrollbar-gutter:stable;background-color:var(--md-default-bg-color);border-radius:.1rem;box-shadow:var(--md-shadow-z2);left:clamp(.8rem,var(--md-tooltip-host-x) - .8rem,100vw - var(--md-tooltip-width) - .8rem);max-height:40vh;max-width:calc(100vw - 1.6rem);position:relative;scrollbar-width:thin}.md-tooltip2__inner::-webkit-scrollbar{height:.2rem;width:.2rem}.md-tooltip2__inner::-webkit-scrollbar-thumb{background-color:var(--md-default-fg-color--lighter)}.md-tooltip2__inner::-webkit-scrollbar-thumb:hover{background-color:var(--md-accent-fg-color)}[role=tooltip]>.md-tooltip2__inner{font-size:.5rem;font-weight:700;left:clamp(.8rem,var(--md-tooltip-host-x) + var(--md-tooltip-x) - var(--md-tooltip-width)/2,100vw - var(--md-tooltip-width) - .8rem);max-width:min(100vw - 2 * .8rem,400px);padding:.2rem .4rem;-webkit-user-select:none;user-select:none;width:-moz-fit-content;width:fit-content}.md-tooltip2__inner.md-typeset>:first-child{margin-top:0}.md-tooltip2__inner.md-typeset>:last-child{margin-bottom:0}[dir=ltr] .md-top{margin-left:50%}[dir=rtl] .md-top{margin-right:50%}.md-top{background-color:var(--md-default-bg-color);border-radius:1.6rem;box-shadow:var(--md-shadow-z2);color:var(--md-default-fg-color--light);cursor:pointer;display:block;font-size:.7rem;outline:none;padding:.4rem .8rem;position:fixed;top:3.2rem;transform:translate(-50%);transition:color 125ms,background-color 125ms,transform 125ms cubic-bezier(.4,0,.2,1),opacity 125ms;z-index:2}@media print{.md-top{display:none}}[dir=rtl] .md-top{transform:translate(50%)}.md-top[hidden]{opacity:0;pointer-events:none;transform:translate(-50%,.2rem);transition-duration:0ms}[dir=rtl] .md-top[hidden]{transform:translate(50%,.2rem)}.md-top:focus,.md-top:hover{background-color:var(--md-accent-fg-color);color:var(--md-accent-bg-color)}.md-top svg{display:inline-block;vertical-align:-.5em}@keyframes hoverfix{0%{pointer-events:none}}:root{--md-version-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 320 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M137.4 374.6c12.5 12.5 32.8 12.5 45.3 0l128-128c9.2-9.2 11.9-22.9 6.9-34.9S301 191.9 288 191.9L32 192c-12.9 0-24.6 7.8-29.6 19.8s-2.2 25.7 6.9 34.9l128 128z"/></svg>')}.md-version{flex-shrink:0;font-size:.8rem;height:2.4rem}[dir=ltr] .md-version__current{margin-left:1.4rem;margin-right:.4rem}[dir=rtl] .md-version__current{margin-left:.4rem;margin-right:1.4rem}.md-version__current{color:inherit;cursor:pointer;outline:none;position:relative;top:.05rem}[dir=ltr] .md-version__current:after{margin-left:.4rem}[dir=rtl] .md-version__current:after{margin-right:.4rem}.md-version__current:after{background-color:currentcolor;content:"";display:inline-block;height:.6rem;-webkit-mask-image:var(--md-version-icon);mask-image:var(--md-version-icon);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;width:.4rem}.md-version__alias{margin-left:.3rem;opacity:.7}.md-version__list{background-color:var(--md-default-bg-color);border-radius:.1rem;box-shadow:var(--md-shadow-z2);color:var(--md-default-fg-color);list-style-type:none;margin:.2rem .8rem;max-height:0;opacity:0;overflow:auto;padding:0;position:absolute;scroll-snap-type:y mandatory;top:.15rem;transition:max-height 0ms .5s,opacity .25s .25s;z-index:3}.md-version:focus-within .md-version__list,.md-version:hover .md-version__list{max-height:10rem;opacity:1;transition:max-height 0ms,opacity .25s}@media (hover:none),(pointer:coarse){.md-version:hover .md-version__list{animation:hoverfix .25s forwards}.md-version:focus-within .md-version__list{animation:none}}.md-version__item{line-height:1.8rem}[dir=ltr] .md-version__link{padding-left:.6rem;padding-right:1.2rem}[dir=rtl] .md-version__link{padding-left:1.2rem;padding-right:.6rem}.md-version__link{cursor:pointer;display:block;outline:none;scroll-snap-align:start;transition:color .25s,background-color .25s;white-space:nowrap;width:100%}.md-version__link:focus,.md-version__link:hover{color:var(--md-accent-fg-color)}.md-version__link:focus{background-color:var(--md-default-fg-color--lightest)}:root{--md-admonition-icon--note:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 2C6.47 2 2 6.47 2 12s4.47 10 10 10 10-4.47 10-10S17.53 2 12 2m3.1 5.07c.14 0 .28.05.4.16l1.27 1.27c.23.22.23.57 0 .78l-1 1-2.05-2.05 1-1c.1-.11.24-.16.38-.16m-1.97 1.74 2.06 2.06-6.06 6.06H7.07v-2.06z"/></svg>');--md-admonition-icon--abstract:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M17 9H7V7h10m0 6H7v-2h10m-3 6H7v-2h7M12 3a1 1 0 0 1 1 1 1 1 0 0 1-1 1 1 1 0 0 1-1-1 1 1 0 0 1 1-1m7 0h-4.18C14.4 1.84 13.3 1 12 1s-2.4.84-2.82 2H5a2 2 0 0 0-2 2v14a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2V5a2 2 0 0 0-2-2"/></svg>');--md-admonition-icon--info:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M13 9h-2V7h2m0 10h-2v-6h2m-1-9A10 10 0 0 0 2 12a10 10 0 0 0 10 10 10 10 0 0 0 10-10A10 10 0 0 0 12 2"/></svg>');--md-admonition-icon--tip:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M17.66 11.2c-.23-.3-.51-.56-.77-.82-.67-.6-1.43-1.03-2.07-1.66C13.33 7.26 13 4.85 13.95 3c-.95.23-1.78.75-2.49 1.32-2.59 2.08-3.61 5.75-2.39 8.9.04.1.08.2.08.33 0 .22-.15.42-.35.5-.23.1-.47.04-.66-.12a.6.6 0 0 1-.14-.17c-1.13-1.43-1.31-3.48-.55-5.12C5.78 10 4.87 12.3 5 14.47c.06.5.12 1 .29 1.5.14.6.41 1.2.71 1.73 1.08 1.73 2.95 2.97 4.96 3.22 2.14.27 4.43-.12 6.07-1.6 1.83-1.66 2.47-4.32 1.53-6.6l-.13-.26c-.21-.46-.77-1.26-.77-1.26m-3.16 6.3c-.28.24-.74.5-1.1.6-1.12.4-2.24-.16-2.9-.82 1.19-.28 1.9-1.16 2.11-2.05.17-.8-.15-1.46-.28-2.23-.12-.74-.1-1.37.17-2.06.19.38.39.76.63 1.06.77 1 1.98 1.44 2.24 2.8.04.14.06.28.06.43.03.82-.33 1.72-.93 2.27"/></svg>');--md-admonition-icon--success:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M21 7 9 19l-5.5-5.5 1.41-1.41L9 16.17 19.59 5.59z"/></svg>');--md-admonition-icon--question:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="m15.07 11.25-.9.92C13.45 12.89 13 13.5 13 15h-2v-.5c0-1.11.45-2.11 1.17-2.83l1.24-1.26c.37-.36.59-.86.59-1.41a2 2 0 0 0-2-2 2 2 0 0 0-2 2H8a4 4 0 0 1 4-4 4 4 0 0 1 4 4 3.2 3.2 0 0 1-.93 2.25M13 19h-2v-2h2M12 2A10 10 0 0 0 2 12a10 10 0 0 0 10 10 10 10 0 0 0 10-10c0-5.53-4.5-10-10-10"/></svg>');--md-admonition-icon--warning:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M13 14h-2V9h2m0 9h-2v-2h2M1 21h22L12 2z"/></svg>');--md-admonition-icon--failure:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M19 6.41 17.59 5 12 10.59 6.41 5 5 6.41 10.59 12 5 17.59 6.41 19 12 13.41 17.59 19 19 17.59 13.41 12z"/></svg>');--md-admonition-icon--danger:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="m11.5 20 4.86-9.73H13V4l-5 9.73h3.5zM12 2c2.75 0 5.1 1 7.05 2.95S22 9.25 22 12s-1 5.1-2.95 7.05S14.75 22 12 22s-5.1-1-7.05-2.95S2 14.75 2 12s1-5.1 2.95-7.05S9.25 2 12 2"/></svg>');--md-admonition-icon--bug:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M11 13h2v1h-2zm10-8v6c0 5.5-3.8 10.7-9 12-5.2-1.3-9-6.5-9-12V5l9-4zm-4 5h-2.2c-.2-.6-.6-1.1-1.1-1.5l1.2-1.2-.7-.7L12.8 8H12c-.2 0-.5 0-.7.1L9.9 6.6l-.8.8 1.2 1.2c-.5.3-.9.8-1.1 1.4H7v1h2v1H7v1h2v1H7v1h2.2c.4 1.2 1.5 2 2.8 2s2.4-.8 2.8-2H17v-1h-2v-1h2v-1h-2v-1h2zm-6 2h2v-1h-2z"/></svg>');--md-admonition-icon--example:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M7 2v2h1v14a4 4 0 0 0 4 4 4 4 0 0 0 4-4V4h1V2zm4 14c-.6 0-1-.4-1-1s.4-1 1-1 1 .4 1 1-.4 1-1 1m2-4c-.6 0-1-.4-1-1s.4-1 1-1 1 .4 1 1-.4 1-1 1m1-5h-4V4h4z"/></svg>');--md-admonition-icon--quote:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M14 17h3l2-4V7h-6v6h3M6 17h3l2-4V7H5v6h3z"/></svg>')}.md-typeset .admonition,.md-typeset details{background-color:var(--md-admonition-bg-color);border:.075rem solid #448aff;border-radius:.2rem;box-shadow:var(--md-shadow-z1);color:var(--md-admonition-fg-color);display:flow-root;font-size:.64rem;margin:1.5625em 0;padding:0 .6rem;page-break-inside:avoid;transition:box-shadow 125ms}@media print{.md-typeset .admonition,.md-typeset details{box-shadow:none}}.md-typeset .admonition:focus-within,.md-typeset details:focus-within{box-shadow:0 0 0 .2rem #448aff1a}.md-typeset .admonition>*,.md-typeset details>*{box-sizing:border-box}.md-typeset .admonition .admonition,.md-typeset .admonition details,.md-typeset details .admonition,.md-typeset details details{margin-bottom:1em;margin-top:1em}.md-typeset .admonition .md-typeset__scrollwrap,.md-typeset details .md-typeset__scrollwrap{margin:1em -.6rem}.md-typeset .admonition .md-typeset__table,.md-typeset details .md-typeset__table{padding:0 .6rem}.md-typeset .admonition>.tabbed-set:only-child,.md-typeset details>.tabbed-set:only-child{margin-top:0}html .md-typeset .admonition>:last-child,html .md-typeset details>:last-child{margin-bottom:.6rem}[dir=ltr] .md-typeset .admonition-title,[dir=ltr] .md-typeset summary{padding-left:2rem;padding-right:.6rem}[dir=rtl] .md-typeset .admonition-title,[dir=rtl] .md-typeset summary{padding-left:.6rem;padding-right:2rem}[dir=ltr] .md-typeset .admonition-title,[dir=ltr] .md-typeset summary{border-left-width:.2rem}[dir=rtl] .md-typeset .admonition-title,[dir=rtl] .md-typeset summary{border-right-width:.2rem}[dir=ltr] .md-typeset .admonition-title,[dir=ltr] .md-typeset summary{border-top-left-radius:.1rem}[dir=ltr] .md-typeset .admonition-title,[dir=ltr] .md-typeset summary,[dir=rtl] .md-typeset .admonition-title,[dir=rtl] .md-typeset summary{border-top-right-radius:.1rem}[dir=rtl] .md-typeset .admonition-title,[dir=rtl] .md-typeset summary{border-top-left-radius:.1rem}.md-typeset .admonition-title,.md-typeset summary{background-color:#448aff1a;border:none;font-weight:700;margin:0 -.6rem;padding-bottom:.4rem;padding-top:.4rem;position:relative}html .md-typeset .admonition-title:last-child,html .md-typeset summary:last-child{margin-bottom:0}[dir=ltr] .md-typeset .admonition-title:before,[dir=ltr] .md-typeset summary:before{left:.6rem}[dir=rtl] .md-typeset .admonition-title:before,[dir=rtl] .md-typeset summary:before{right:.6rem}.md-typeset .admonition-title:before,.md-typeset summary:before{background-color:#448aff;content:"";height:1rem;-webkit-mask-image:var(--md-admonition-icon--note);mask-image:var(--md-admonition-icon--note);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;position:absolute;top:.625em;width:1rem}.md-typeset .admonition-title code,.md-typeset summary code{box-shadow:0 0 0 .05rem var(--md-default-fg-color--lightest)}.md-typeset .admonition.note,.md-typeset details.note{border-color:#448aff}.md-typeset .admonition.note:focus-within,.md-typeset details.note:focus-within{box-shadow:0 0 0 .2rem #448aff1a}.md-typeset .note>.admonition-title,.md-typeset .note>summary{background-color:#448aff1a}.md-typeset .note>.admonition-title:before,.md-typeset .note>summary:before{background-color:#448aff;-webkit-mask-image:var(--md-admonition-icon--note);mask-image:var(--md-admonition-icon--note)}.md-typeset .note>.admonition-title:after,.md-typeset .note>summary:after{color:#448aff}.md-typeset .admonition.abstract,.md-typeset details.abstract{border-color:#00b0ff}.md-typeset .admonition.abstract:focus-within,.md-typeset details.abstract:focus-within{box-shadow:0 0 0 .2rem #00b0ff1a}.md-typeset .abstract>.admonition-title,.md-typeset .abstract>summary{background-color:#00b0ff1a}.md-typeset .abstract>.admonition-title:before,.md-typeset .abstract>summary:before{background-color:#00b0ff;-webkit-mask-image:var(--md-admonition-icon--abstract);mask-image:var(--md-admonition-icon--abstract)}.md-typeset .abstract>.admonition-title:after,.md-typeset .abstract>summary:after{color:#00b0ff}.md-typeset .admonition.info,.md-typeset details.info{border-color:#00b8d4}.md-typeset .admonition.info:focus-within,.md-typeset details.info:focus-within{box-shadow:0 0 0 .2rem #00b8d41a}.md-typeset .info>.admonition-title,.md-typeset .info>summary{background-color:#00b8d41a}.md-typeset .info>.admonition-title:before,.md-typeset .info>summary:before{background-color:#00b8d4;-webkit-mask-image:var(--md-admonition-icon--info);mask-image:var(--md-admonition-icon--info)}.md-typeset .info>.admonition-title:after,.md-typeset .info>summary:after{color:#00b8d4}.md-typeset .admonition.tip,.md-typeset details.tip{border-color:#00bfa5}.md-typeset .admonition.tip:focus-within,.md-typeset details.tip:focus-within{box-shadow:0 0 0 .2rem #00bfa51a}.md-typeset .tip>.admonition-title,.md-typeset .tip>summary{background-color:#00bfa51a}.md-typeset .tip>.admonition-title:before,.md-typeset .tip>summary:before{background-color:#00bfa5;-webkit-mask-image:var(--md-admonition-icon--tip);mask-image:var(--md-admonition-icon--tip)}.md-typeset .tip>.admonition-title:after,.md-typeset .tip>summary:after{color:#00bfa5}.md-typeset .admonition.success,.md-typeset details.success{border-color:#00c853}.md-typeset .admonition.success:focus-within,.md-typeset details.success:focus-within{box-shadow:0 0 0 .2rem #00c8531a}.md-typeset .success>.admonition-title,.md-typeset .success>summary{background-color:#00c8531a}.md-typeset .success>.admonition-title:before,.md-typeset .success>summary:before{background-color:#00c853;-webkit-mask-image:var(--md-admonition-icon--success);mask-image:var(--md-admonition-icon--success)}.md-typeset .success>.admonition-title:after,.md-typeset .success>summary:after{color:#00c853}.md-typeset .admonition.question,.md-typeset details.question{border-color:#64dd17}.md-typeset .admonition.question:focus-within,.md-typeset details.question:focus-within{box-shadow:0 0 0 .2rem #64dd171a}.md-typeset .question>.admonition-title,.md-typeset .question>summary{background-color:#64dd171a}.md-typeset .question>.admonition-title:before,.md-typeset .question>summary:before{background-color:#64dd17;-webkit-mask-image:var(--md-admonition-icon--question);mask-image:var(--md-admonition-icon--question)}.md-typeset .question>.admonition-title:after,.md-typeset .question>summary:after{color:#64dd17}.md-typeset .admonition.warning,.md-typeset details.warning{border-color:#ff9100}.md-typeset .admonition.warning:focus-within,.md-typeset details.warning:focus-within{box-shadow:0 0 0 .2rem #ff91001a}.md-typeset .warning>.admonition-title,.md-typeset .warning>summary{background-color:#ff91001a}.md-typeset .warning>.admonition-title:before,.md-typeset .warning>summary:before{background-color:#ff9100;-webkit-mask-image:var(--md-admonition-icon--warning);mask-image:var(--md-admonition-icon--warning)}.md-typeset .warning>.admonition-title:after,.md-typeset .warning>summary:after{color:#ff9100}.md-typeset .admonition.failure,.md-typeset details.failure{border-color:#ff5252}.md-typeset .admonition.failure:focus-within,.md-typeset details.failure:focus-within{box-shadow:0 0 0 .2rem #ff52521a}.md-typeset .failure>.admonition-title,.md-typeset .failure>summary{background-color:#ff52521a}.md-typeset .failure>.admonition-title:before,.md-typeset .failure>summary:before{background-color:#ff5252;-webkit-mask-image:var(--md-admonition-icon--failure);mask-image:var(--md-admonition-icon--failure)}.md-typeset .failure>.admonition-title:after,.md-typeset .failure>summary:after{color:#ff5252}.md-typeset .admonition.danger,.md-typeset details.danger{border-color:#ff1744}.md-typeset .admonition.danger:focus-within,.md-typeset details.danger:focus-within{box-shadow:0 0 0 .2rem #ff17441a}.md-typeset .danger>.admonition-title,.md-typeset .danger>summary{background-color:#ff17441a}.md-typeset .danger>.admonition-title:before,.md-typeset .danger>summary:before{background-color:#ff1744;-webkit-mask-image:var(--md-admonition-icon--danger);mask-image:var(--md-admonition-icon--danger)}.md-typeset .danger>.admonition-title:after,.md-typeset .danger>summary:after{color:#ff1744}.md-typeset .admonition.bug,.md-typeset details.bug{border-color:#f50057}.md-typeset .admonition.bug:focus-within,.md-typeset details.bug:focus-within{box-shadow:0 0 0 .2rem #f500571a}.md-typeset .bug>.admonition-title,.md-typeset .bug>summary{background-color:#f500571a}.md-typeset .bug>.admonition-title:before,.md-typeset .bug>summary:before{background-color:#f50057;-webkit-mask-image:var(--md-admonition-icon--bug);mask-image:var(--md-admonition-icon--bug)}.md-typeset .bug>.admonition-title:after,.md-typeset .bug>summary:after{color:#f50057}.md-typeset .admonition.example,.md-typeset details.example{border-color:#7c4dff}.md-typeset .admonition.example:focus-within,.md-typeset details.example:focus-within{box-shadow:0 0 0 .2rem #7c4dff1a}.md-typeset .example>.admonition-title,.md-typeset .example>summary{background-color:#7c4dff1a}.md-typeset .example>.admonition-title:before,.md-typeset .example>summary:before{background-color:#7c4dff;-webkit-mask-image:var(--md-admonition-icon--example);mask-image:var(--md-admonition-icon--example)}.md-typeset .example>.admonition-title:after,.md-typeset .example>summary:after{color:#7c4dff}.md-typeset .admonition.quote,.md-typeset details.quote{border-color:#9e9e9e}.md-typeset .admonition.quote:focus-within,.md-typeset details.quote:focus-within{box-shadow:0 0 0 .2rem #9e9e9e1a}.md-typeset .quote>.admonition-title,.md-typeset .quote>summary{background-color:#9e9e9e1a}.md-typeset .quote>.admonition-title:before,.md-typeset .quote>summary:before{background-color:#9e9e9e;-webkit-mask-image:var(--md-admonition-icon--quote);mask-image:var(--md-admonition-icon--quote)}.md-typeset .quote>.admonition-title:after,.md-typeset .quote>summary:after{color:#9e9e9e}:root{--md-footnotes-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M19 7v4H5.83l3.58-3.59L8 6l-6 6 6 6 1.41-1.42L5.83 13H21V7z"/></svg>')}.md-typeset .footnote{color:var(--md-default-fg-color--light);font-size:.64rem}[dir=ltr] .md-typeset .footnote>ol{margin-left:0}[dir=rtl] .md-typeset .footnote>ol{margin-right:0}.md-typeset .footnote>ol>li{transition:color 125ms}.md-typeset .footnote>ol>li:target{color:var(--md-default-fg-color)}.md-typeset .footnote>ol>li:focus-within .footnote-backref{opacity:1;transform:translateX(0);transition:none}.md-typeset .footnote>ol>li:hover .footnote-backref,.md-typeset .footnote>ol>li:target .footnote-backref{opacity:1;transform:translateX(0)}.md-typeset .footnote>ol>li>:first-child{margin-top:0}.md-typeset .footnote-ref{font-size:.75em;font-weight:700}html .md-typeset .footnote-ref{outline-offset:.1rem}.md-typeset [id^="fnref:"]:target>.footnote-ref{outline:auto}.md-typeset .footnote-backref{color:var(--md-typeset-a-color);display:inline-block;font-size:0;opacity:0;transform:translateX(.25rem);transition:color .25s,transform .25s .25s,opacity 125ms .25s;vertical-align:text-bottom}@media print{.md-typeset .footnote-backref{color:var(--md-typeset-a-color);opacity:1;transform:translateX(0)}}[dir=rtl] .md-typeset .footnote-backref{transform:translateX(-.25rem)}.md-typeset .footnote-backref:hover{color:var(--md-accent-fg-color)}.md-typeset .footnote-backref:before{background-color:currentcolor;content:"";display:inline-block;height:.8rem;-webkit-mask-image:var(--md-footnotes-icon);mask-image:var(--md-footnotes-icon);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;width:.8rem}[dir=rtl] .md-typeset .footnote-backref:before svg{transform:scaleX(-1)}[dir=ltr] .md-typeset .headerlink{margin-left:.5rem}[dir=rtl] .md-typeset .headerlink{margin-right:.5rem}.md-typeset .headerlink{color:var(--md-default-fg-color--lighter);display:inline-block;opacity:0;transition:color .25s,opacity 125ms}@media print{.md-typeset .headerlink{display:none}}.md-typeset .headerlink:focus,.md-typeset :hover>.headerlink,.md-typeset :target>.headerlink{opacity:1;transition:color .25s,opacity 125ms}.md-typeset .headerlink:focus,.md-typeset .headerlink:hover,.md-typeset :target>.headerlink{color:var(--md-accent-fg-color)}.md-typeset :target{--md-scroll-margin:3.6rem;--md-scroll-offset:0rem;scroll-margin-top:calc(var(--md-scroll-margin) - var(--md-scroll-offset))}@media screen and (min-width:76.25em){.md-header--lifted~.md-container .md-typeset :target{--md-scroll-margin:6rem}}.md-typeset h1:target,.md-typeset h2:target,.md-typeset h3:target{--md-scroll-offset:0.2rem}.md-typeset h4:target{--md-scroll-offset:0.15rem}.md-typeset div.arithmatex{overflow:auto}@media screen and (max-width:44.984375em){.md-typeset div.arithmatex{margin:0 -.8rem}.md-typeset div.arithmatex>*{width:min-content}}.md-typeset div.arithmatex>*{margin-left:auto!important;margin-right:auto!important;padding:0 .8rem;touch-action:auto}.md-typeset div.arithmatex>* mjx-container{margin:0!important}.md-typeset div.arithmatex mjx-assistive-mml{height:0}.md-typeset del.critic{background-color:var(--md-typeset-del-color)}.md-typeset del.critic,.md-typeset ins.critic{-webkit-box-decoration-break:clone;box-decoration-break:clone}.md-typeset ins.critic{background-color:var(--md-typeset-ins-color)}.md-typeset .critic.comment{-webkit-box-decoration-break:clone;box-decoration-break:clone;color:var(--md-code-hl-comment-color)}.md-typeset .critic.comment:before{content:"/* "}.md-typeset .critic.comment:after{content:" */"}.md-typeset .critic.block{box-shadow:none;display:block;margin:1em 0;overflow:auto;padding-left:.8rem;padding-right:.8rem}.md-typeset .critic.block>:first-child{margin-top:.5em}.md-typeset .critic.block>:last-child{margin-bottom:.5em}:root{--md-details-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M8.59 16.58 13.17 12 8.59 7.41 10 6l6 6-6 6z"/></svg>')}.md-typeset details{display:flow-root;overflow:visible;padding-top:0}.md-typeset details[open]>summary:after{transform:rotate(90deg)}.md-typeset details:not([open]){box-shadow:none;padding-bottom:0}.md-typeset details:not([open])>summary{border-radius:.1rem}[dir=ltr] .md-typeset summary{padding-right:1.8rem}[dir=rtl] .md-typeset summary{padding-left:1.8rem}[dir=ltr] .md-typeset summary{border-top-left-radius:.1rem}[dir=ltr] .md-typeset summary,[dir=rtl] .md-typeset summary{border-top-right-radius:.1rem}[dir=rtl] .md-typeset summary{border-top-left-radius:.1rem}.md-typeset summary{cursor:pointer;display:block;min-height:1rem;overflow:hidden}.md-typeset summary.focus-visible{outline-color:var(--md-accent-fg-color);outline-offset:.2rem}.md-typeset summary:not(.focus-visible){-webkit-tap-highlight-color:transparent;outline:none}[dir=ltr] .md-typeset summary:after{right:.4rem}[dir=rtl] .md-typeset summary:after{left:.4rem}.md-typeset summary:after{background-color:currentcolor;content:"";height:1rem;-webkit-mask-image:var(--md-details-icon);mask-image:var(--md-details-icon);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;position:absolute;top:.625em;transform:rotate(0deg);transition:transform .25s;width:1rem}[dir=rtl] .md-typeset summary:after{transform:rotate(180deg)}.md-typeset summary::marker{display:none}.md-typeset summary::-webkit-details-marker{display:none}.md-typeset .emojione,.md-typeset .gemoji,.md-typeset .twemoji{--md-icon-size:1.125em;display:inline-flex;height:var(--md-icon-size);vertical-align:text-top}.md-typeset .emojione svg,.md-typeset .gemoji svg,.md-typeset .twemoji svg{fill:currentcolor;max-height:100%;width:var(--md-icon-size)}.md-typeset .lg,.md-typeset .xl,.md-typeset .xxl,.md-typeset .xxxl{vertical-align:text-bottom}.md-typeset .middle{vertical-align:middle}.md-typeset .lg{--md-icon-size:1.5em}.md-typeset .xl{--md-icon-size:2.25em}.md-typeset .xxl{--md-icon-size:3em}.md-typeset .xxxl{--md-icon-size:4em}.highlight .o,.highlight .ow{color:var(--md-code-hl-operator-color)}.highlight .p{color:var(--md-code-hl-punctuation-color)}.highlight .cpf,.highlight .l,.highlight .s,.highlight .s1,.highlight .s2,.highlight .sb,.highlight .sc,.highlight .si,.highlight .ss{color:var(--md-code-hl-string-color)}.highlight .cp,.highlight .se,.highlight .sh,.highlight .sr,.highlight .sx{color:var(--md-code-hl-special-color)}.highlight .il,.highlight .m,.highlight .mb,.highlight .mf,.highlight .mh,.highlight .mi,.highlight .mo{color:var(--md-code-hl-number-color)}.highlight .k,.highlight .kd,.highlight .kn,.highlight .kp,.highlight .kr,.highlight .kt{color:var(--md-code-hl-keyword-color)}.highlight .kc,.highlight .n{color:var(--md-code-hl-name-color)}.highlight .bp,.highlight .nb,.highlight .no{color:var(--md-code-hl-constant-color)}.highlight .nc,.highlight .ne,.highlight .nf,.highlight .nn{color:var(--md-code-hl-function-color)}.highlight .nd,.highlight .ni,.highlight .nl,.highlight .nt{color:var(--md-code-hl-keyword-color)}.highlight .c,.highlight .c1,.highlight .ch,.highlight .cm,.highlight .cs,.highlight .sd{color:var(--md-code-hl-comment-color)}.highlight .na,.highlight .nv,.highlight .vc,.highlight .vg,.highlight .vi{color:var(--md-code-hl-variable-color)}.highlight .ge,.highlight .gh,.highlight .go,.highlight .gp,.highlight .gr,.highlight .gs,.highlight .gt,.highlight .gu{color:var(--md-code-hl-generic-color)}.highlight .gd,.highlight .gi{border-radius:.1rem;margin:0 -.125em;padding:0 .125em}.highlight .gd{background-color:var(--md-typeset-del-color)}.highlight .gi{background-color:var(--md-typeset-ins-color)}.highlight .hll{background-color:var(--md-code-hl-color--light);box-shadow:2px 0 0 0 var(--md-code-hl-color) inset;display:block;margin:0 -1.1764705882em;padding:0 1.1764705882em}.highlight span.filename{background-color:var(--md-code-bg-color);border-bottom:.05rem solid var(--md-default-fg-color--lightest);border-top-left-radius:.1rem;border-top-right-radius:.1rem;display:flow-root;font-size:.85em;font-weight:700;margin-top:1em;padding:.6617647059em 1.1764705882em;position:relative}.highlight span.filename+pre{margin-top:0}.highlight span.filename+pre>code{border-top-left-radius:0;border-top-right-radius:0}.highlight [data-linenos]:before{background-color:var(--md-code-bg-color);box-shadow:-.05rem 0 var(--md-default-fg-color--lightest) inset;color:var(--md-default-fg-color--light);content:attr(data-linenos);float:left;left:-1.1764705882em;margin-left:-1.1764705882em;margin-right:1.1764705882em;padding-left:1.1764705882em;position:sticky;-webkit-user-select:none;user-select:none;z-index:3}.highlight code a[id]{position:absolute;visibility:hidden}.highlight code[data-md-copying]{display:initial}.highlight code[data-md-copying] .hll{display:contents}.highlight code[data-md-copying] .md-annotation{display:none}.highlighttable{display:flow-root}.highlighttable tbody,.highlighttable td{display:block;padding:0}.highlighttable tr{display:flex}.highlighttable pre{margin:0}.highlighttable th.filename{flex-grow:1;padding:0;text-align:left}.highlighttable th.filename span.filename{margin-top:0}.highlighttable .linenos{background-color:var(--md-code-bg-color);border-bottom-left-radius:.1rem;border-top-left-radius:.1rem;font-size:.85em;padding:.7720588235em 0 .7720588235em 1.1764705882em;-webkit-user-select:none;user-select:none}.highlighttable .linenodiv{box-shadow:-.05rem 0 var(--md-default-fg-color--lightest) inset;padding-right:.5882352941em}.highlighttable .linenodiv pre{color:var(--md-default-fg-color--light);text-align:right}.highlighttable .code{flex:1;min-width:0}.linenodiv a{color:inherit}.md-typeset .highlighttable{direction:ltr;margin:1em 0}.md-typeset .highlighttable>tbody>tr>.code>div>pre>code{border-bottom-left-radius:0;border-top-left-radius:0}.md-typeset .highlight+.result{border:.05rem solid var(--md-code-bg-color);border-bottom-left-radius:.1rem;border-bottom-right-radius:.1rem;border-top-width:.1rem;margin-top:-1.125em;overflow:visible;padding:0 1em}.md-typeset .highlight+.result:after{clear:both;content:"";display:block}@media screen and (max-width:44.984375em){.md-content__inner>.highlight{margin:1em -.8rem}.md-content__inner>.highlight>.filename,.md-content__inner>.highlight>.highlighttable>tbody>tr>.code>div>pre>code,.md-content__inner>.highlight>.highlighttable>tbody>tr>.filename span.filename,.md-content__inner>.highlight>.highlighttable>tbody>tr>.linenos,.md-content__inner>.highlight>pre>code{border-radius:0}.md-content__inner>.highlight+.result{border-left-width:0;border-radius:0;border-right-width:0;margin-left:-.8rem;margin-right:-.8rem}}.md-typeset .keys kbd:after,.md-typeset .keys kbd:before{-moz-osx-font-smoothing:initial;-webkit-font-smoothing:initial;color:inherit;margin:0;position:relative}.md-typeset .keys span{color:var(--md-default-fg-color--light);padding:0 .2em}.md-typeset .keys .key-alt:before,.md-typeset .keys .key-left-alt:before,.md-typeset .keys .key-right-alt:before{content:"⎇";padding-right:.4em}.md-typeset .keys .key-command:before,.md-typeset .keys .key-left-command:before,.md-typeset .keys .key-right-command:before{content:"⌘";padding-right:.4em}.md-typeset .keys .key-control:before,.md-typeset .keys .key-left-control:before,.md-typeset .keys .key-right-control:before{content:"⌃";padding-right:.4em}.md-typeset .keys .key-left-meta:before,.md-typeset .keys .key-meta:before,.md-typeset .keys .key-right-meta:before{content:"◆";padding-right:.4em}.md-typeset .keys .key-left-option:before,.md-typeset .keys .key-option:before,.md-typeset .keys .key-right-option:before{content:"⌥";padding-right:.4em}.md-typeset .keys .key-left-shift:before,.md-typeset .keys .key-right-shift:before,.md-typeset .keys .key-shift:before{content:"⇧";padding-right:.4em}.md-typeset .keys .key-left-super:before,.md-typeset .keys .key-right-super:before,.md-typeset .keys .key-super:before{content:"❖";padding-right:.4em}.md-typeset .keys .key-left-windows:before,.md-typeset .keys .key-right-windows:before,.md-typeset .keys .key-windows:before{content:"⊞";padding-right:.4em}.md-typeset .keys .key-arrow-down:before{content:"↓";padding-right:.4em}.md-typeset .keys .key-arrow-left:before{content:"←";padding-right:.4em}.md-typeset .keys .key-arrow-right:before{content:"→";padding-right:.4em}.md-typeset .keys .key-arrow-up:before{content:"↑";padding-right:.4em}.md-typeset .keys .key-backspace:before{content:"⌫";padding-right:.4em}.md-typeset .keys .key-backtab:before{content:"⇤";padding-right:.4em}.md-typeset .keys .key-caps-lock:before{content:"⇪";padding-right:.4em}.md-typeset .keys .key-clear:before{content:"⌧";padding-right:.4em}.md-typeset .keys .key-context-menu:before{content:"☰";padding-right:.4em}.md-typeset .keys .key-delete:before{content:"⌦";padding-right:.4em}.md-typeset .keys .key-eject:before{content:"⏏";padding-right:.4em}.md-typeset .keys .key-end:before{content:"⤓";padding-right:.4em}.md-typeset .keys .key-escape:before{content:"⎋";padding-right:.4em}.md-typeset .keys .key-home:before{content:"⤒";padding-right:.4em}.md-typeset .keys .key-insert:before{content:"⎀";padding-right:.4em}.md-typeset .keys .key-page-down:before{content:"⇟";padding-right:.4em}.md-typeset .keys .key-page-up:before{content:"⇞";padding-right:.4em}.md-typeset .keys .key-print-screen:before{content:"⎙";padding-right:.4em}.md-typeset .keys .key-tab:after{content:"⇥";padding-left:.4em}.md-typeset .keys .key-num-enter:after{content:"⌤";padding-left:.4em}.md-typeset .keys .key-enter:after{content:"⏎";padding-left:.4em}:root{--md-tabbed-icon--prev:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M15.41 16.58 10.83 12l4.58-4.59L14 6l-6 6 6 6z"/></svg>');--md-tabbed-icon--next:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M8.59 16.58 13.17 12 8.59 7.41 10 6l6 6-6 6z"/></svg>')}.md-typeset .tabbed-set{border-radius:.1rem;display:flex;flex-flow:column wrap;margin:1em 0;position:relative}.md-typeset .tabbed-set>input{height:0;opacity:0;position:absolute;width:0}.md-typeset .tabbed-set>input:target{--md-scroll-offset:0.625em}.md-typeset .tabbed-set>input.focus-visible~.tabbed-labels:before{background-color:var(--md-accent-fg-color)}.md-typeset .tabbed-labels{-ms-overflow-style:none;box-shadow:0 -.05rem var(--md-default-fg-color--lightest) inset;display:flex;max-width:100%;overflow:auto;scrollbar-width:none}@media print{.md-typeset .tabbed-labels{display:contents}}@media screen{.js .md-typeset .tabbed-labels{position:relative}.js .md-typeset .tabbed-labels:before{background:var(--md-default-fg-color);bottom:0;content:"";display:block;height:2px;left:0;position:absolute;transform:translateX(var(--md-indicator-x));transition:width 225ms,background-color .25s,transform .25s;transition-timing-function:cubic-bezier(.4,0,.2,1);width:var(--md-indicator-width)}}.md-typeset .tabbed-labels::-webkit-scrollbar{display:none}.md-typeset .tabbed-labels>label{border-bottom:.1rem solid #0000;border-radius:.1rem .1rem 0 0;color:var(--md-default-fg-color--light);cursor:pointer;flex-shrink:0;font-size:.64rem;font-weight:700;padding:.78125em 1.25em .625em;scroll-margin-inline-start:1rem;transition:background-color .25s,color .25s;white-space:nowrap;width:auto}@media print{.md-typeset .tabbed-labels>label:first-child{order:1}.md-typeset .tabbed-labels>label:nth-child(2){order:2}.md-typeset .tabbed-labels>label:nth-child(3){order:3}.md-typeset .tabbed-labels>label:nth-child(4){order:4}.md-typeset .tabbed-labels>label:nth-child(5){order:5}.md-typeset .tabbed-labels>label:nth-child(6){order:6}.md-typeset .tabbed-labels>label:nth-child(7){order:7}.md-typeset .tabbed-labels>label:nth-child(8){order:8}.md-typeset .tabbed-labels>label:nth-child(9){order:9}.md-typeset .tabbed-labels>label:nth-child(10){order:10}.md-typeset .tabbed-labels>label:nth-child(11){order:11}.md-typeset .tabbed-labels>label:nth-child(12){order:12}.md-typeset .tabbed-labels>label:nth-child(13){order:13}.md-typeset .tabbed-labels>label:nth-child(14){order:14}.md-typeset .tabbed-labels>label:nth-child(15){order:15}.md-typeset .tabbed-labels>label:nth-child(16){order:16}.md-typeset .tabbed-labels>label:nth-child(17){order:17}.md-typeset .tabbed-labels>label:nth-child(18){order:18}.md-typeset .tabbed-labels>label:nth-child(19){order:19}.md-typeset .tabbed-labels>label:nth-child(20){order:20}}.md-typeset .tabbed-labels>label:hover{color:var(--md-default-fg-color)}.md-typeset .tabbed-labels>label>[href]:first-child{color:inherit}.md-typeset .tabbed-labels--linked>label{padding:0}.md-typeset .tabbed-labels--linked>label>a{display:block;padding:.78125em 1.25em .625em}.md-typeset .tabbed-content{width:100%}@media print{.md-typeset .tabbed-content{display:contents}}.md-typeset .tabbed-block{display:none}@media print{.md-typeset .tabbed-block{display:block}.md-typeset .tabbed-block:first-child{order:1}.md-typeset .tabbed-block:nth-child(2){order:2}.md-typeset .tabbed-block:nth-child(3){order:3}.md-typeset .tabbed-block:nth-child(4){order:4}.md-typeset .tabbed-block:nth-child(5){order:5}.md-typeset .tabbed-block:nth-child(6){order:6}.md-typeset .tabbed-block:nth-child(7){order:7}.md-typeset .tabbed-block:nth-child(8){order:8}.md-typeset .tabbed-block:nth-child(9){order:9}.md-typeset .tabbed-block:nth-child(10){order:10}.md-typeset .tabbed-block:nth-child(11){order:11}.md-typeset .tabbed-block:nth-child(12){order:12}.md-typeset .tabbed-block:nth-child(13){order:13}.md-typeset .tabbed-block:nth-child(14){order:14}.md-typeset .tabbed-block:nth-child(15){order:15}.md-typeset .tabbed-block:nth-child(16){order:16}.md-typeset .tabbed-block:nth-child(17){order:17}.md-typeset .tabbed-block:nth-child(18){order:18}.md-typeset .tabbed-block:nth-child(19){order:19}.md-typeset .tabbed-block:nth-child(20){order:20}}.md-typeset .tabbed-block>.highlight:first-child>pre,.md-typeset .tabbed-block>pre:first-child{margin:0}.md-typeset .tabbed-block>.highlight:first-child>pre>code,.md-typeset .tabbed-block>pre:first-child>code{border-top-left-radius:0;border-top-right-radius:0}.md-typeset .tabbed-block>.highlight:first-child>.filename{border-top-left-radius:0;border-top-right-radius:0;margin:0}.md-typeset .tabbed-block>.highlight:first-child>.highlighttable{margin:0}.md-typeset .tabbed-block>.highlight:first-child>.highlighttable>tbody>tr>.filename span.filename,.md-typeset .tabbed-block>.highlight:first-child>.highlighttable>tbody>tr>.linenos{border-top-left-radius:0;border-top-right-radius:0;margin:0}.md-typeset .tabbed-block>.highlight:first-child>.highlighttable>tbody>tr>.code>div>pre>code{border-top-left-radius:0;border-top-right-radius:0}.md-typeset .tabbed-block>.highlight:first-child+.result{margin-top:-.125em}.md-typeset .tabbed-block>.tabbed-set{margin:0}.md-typeset .tabbed-button{align-self:center;border-radius:100%;color:var(--md-default-fg-color--light);cursor:pointer;display:block;height:.9rem;margin-top:.1rem;pointer-events:auto;transition:background-color .25s;width:.9rem}.md-typeset .tabbed-button:hover{background-color:var(--md-accent-fg-color--transparent);color:var(--md-accent-fg-color)}.md-typeset .tabbed-button:after{background-color:currentcolor;content:"";display:block;height:100%;-webkit-mask-image:var(--md-tabbed-icon--prev);mask-image:var(--md-tabbed-icon--prev);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;transition:background-color .25s,transform .25s;width:100%}.md-typeset .tabbed-control{background:linear-gradient(to right,var(--md-default-bg-color) 60%,#0000);display:flex;height:1.9rem;justify-content:start;pointer-events:none;position:absolute;transition:opacity 125ms;width:1.2rem}[dir=rtl] .md-typeset .tabbed-control{transform:rotate(180deg)}.md-typeset .tabbed-control[hidden]{opacity:0}.md-typeset .tabbed-control--next{background:linear-gradient(to left,var(--md-default-bg-color) 60%,#0000);justify-content:end;right:0}.md-typeset .tabbed-control--next .tabbed-button:after{-webkit-mask-image:var(--md-tabbed-icon--next);mask-image:var(--md-tabbed-icon--next)}@media screen and (max-width:44.984375em){[dir=ltr] .md-content__inner>.tabbed-set .tabbed-labels{padding-left:.8rem}[dir=rtl] .md-content__inner>.tabbed-set .tabbed-labels{padding-right:.8rem}.md-content__inner>.tabbed-set .tabbed-labels{margin:0 -.8rem;max-width:100vw;scroll-padding-inline-start:.8rem}[dir=ltr] .md-content__inner>.tabbed-set .tabbed-labels:after{padding-right:.8rem}[dir=rtl] .md-content__inner>.tabbed-set .tabbed-labels:after{padding-left:.8rem}.md-content__inner>.tabbed-set .tabbed-labels:after{content:""}[dir=ltr] .md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--prev{padding-left:.8rem}[dir=rtl] .md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--prev{padding-right:.8rem}[dir=ltr] .md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--prev{margin-left:-.8rem}[dir=rtl] .md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--prev{margin-right:-.8rem}.md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--prev{width:2rem}[dir=ltr] .md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--next{padding-right:.8rem}[dir=rtl] .md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--next{padding-left:.8rem}[dir=ltr] .md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--next{margin-right:-.8rem}[dir=rtl] .md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--next{margin-left:-.8rem}.md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--next{width:2rem}}@media screen{.md-typeset .tabbed-set>input:first-child:checked~.tabbed-labels>:first-child,.md-typeset .tabbed-set>input:nth-child(10):checked~.tabbed-labels>:nth-child(10),.md-typeset .tabbed-set>input:nth-child(11):checked~.tabbed-labels>:nth-child(11),.md-typeset .tabbed-set>input:nth-child(12):checked~.tabbed-labels>:nth-child(12),.md-typeset .tabbed-set>input:nth-child(13):checked~.tabbed-labels>:nth-child(13),.md-typeset .tabbed-set>input:nth-child(14):checked~.tabbed-labels>:nth-child(14),.md-typeset .tabbed-set>input:nth-child(15):checked~.tabbed-labels>:nth-child(15),.md-typeset .tabbed-set>input:nth-child(16):checked~.tabbed-labels>:nth-child(16),.md-typeset .tabbed-set>input:nth-child(17):checked~.tabbed-labels>:nth-child(17),.md-typeset .tabbed-set>input:nth-child(18):checked~.tabbed-labels>:nth-child(18),.md-typeset .tabbed-set>input:nth-child(19):checked~.tabbed-labels>:nth-child(19),.md-typeset .tabbed-set>input:nth-child(2):checked~.tabbed-labels>:nth-child(2),.md-typeset .tabbed-set>input:nth-child(20):checked~.tabbed-labels>:nth-child(20),.md-typeset .tabbed-set>input:nth-child(3):checked~.tabbed-labels>:nth-child(3),.md-typeset .tabbed-set>input:nth-child(4):checked~.tabbed-labels>:nth-child(4),.md-typeset .tabbed-set>input:nth-child(5):checked~.tabbed-labels>:nth-child(5),.md-typeset .tabbed-set>input:nth-child(6):checked~.tabbed-labels>:nth-child(6),.md-typeset .tabbed-set>input:nth-child(7):checked~.tabbed-labels>:nth-child(7),.md-typeset .tabbed-set>input:nth-child(8):checked~.tabbed-labels>:nth-child(8),.md-typeset .tabbed-set>input:nth-child(9):checked~.tabbed-labels>:nth-child(9){color:var(--md-default-fg-color)}.md-typeset .no-js .tabbed-set>input:first-child:checked~.tabbed-labels>:first-child,.md-typeset .no-js .tabbed-set>input:nth-child(10):checked~.tabbed-labels>:nth-child(10),.md-typeset .no-js .tabbed-set>input:nth-child(11):checked~.tabbed-labels>:nth-child(11),.md-typeset .no-js .tabbed-set>input:nth-child(12):checked~.tabbed-labels>:nth-child(12),.md-typeset .no-js .tabbed-set>input:nth-child(13):checked~.tabbed-labels>:nth-child(13),.md-typeset .no-js .tabbed-set>input:nth-child(14):checked~.tabbed-labels>:nth-child(14),.md-typeset .no-js .tabbed-set>input:nth-child(15):checked~.tabbed-labels>:nth-child(15),.md-typeset .no-js .tabbed-set>input:nth-child(16):checked~.tabbed-labels>:nth-child(16),.md-typeset .no-js .tabbed-set>input:nth-child(17):checked~.tabbed-labels>:nth-child(17),.md-typeset .no-js .tabbed-set>input:nth-child(18):checked~.tabbed-labels>:nth-child(18),.md-typeset .no-js .tabbed-set>input:nth-child(19):checked~.tabbed-labels>:nth-child(19),.md-typeset .no-js .tabbed-set>input:nth-child(2):checked~.tabbed-labels>:nth-child(2),.md-typeset .no-js .tabbed-set>input:nth-child(20):checked~.tabbed-labels>:nth-child(20),.md-typeset .no-js .tabbed-set>input:nth-child(3):checked~.tabbed-labels>:nth-child(3),.md-typeset .no-js .tabbed-set>input:nth-child(4):checked~.tabbed-labels>:nth-child(4),.md-typeset .no-js .tabbed-set>input:nth-child(5):checked~.tabbed-labels>:nth-child(5),.md-typeset .no-js .tabbed-set>input:nth-child(6):checked~.tabbed-labels>:nth-child(6),.md-typeset .no-js .tabbed-set>input:nth-child(7):checked~.tabbed-labels>:nth-child(7),.md-typeset .no-js .tabbed-set>input:nth-child(8):checked~.tabbed-labels>:nth-child(8),.md-typeset .no-js .tabbed-set>input:nth-child(9):checked~.tabbed-labels>:nth-child(9),.no-js .md-typeset .tabbed-set>input:first-child:checked~.tabbed-labels>:first-child,.no-js .md-typeset .tabbed-set>input:nth-child(10):checked~.tabbed-labels>:nth-child(10),.no-js .md-typeset .tabbed-set>input:nth-child(11):checked~.tabbed-labels>:nth-child(11),.no-js .md-typeset .tabbed-set>input:nth-child(12):checked~.tabbed-labels>:nth-child(12),.no-js .md-typeset .tabbed-set>input:nth-child(13):checked~.tabbed-labels>:nth-child(13),.no-js .md-typeset .tabbed-set>input:nth-child(14):checked~.tabbed-labels>:nth-child(14),.no-js .md-typeset .tabbed-set>input:nth-child(15):checked~.tabbed-labels>:nth-child(15),.no-js .md-typeset .tabbed-set>input:nth-child(16):checked~.tabbed-labels>:nth-child(16),.no-js .md-typeset .tabbed-set>input:nth-child(17):checked~.tabbed-labels>:nth-child(17),.no-js .md-typeset .tabbed-set>input:nth-child(18):checked~.tabbed-labels>:nth-child(18),.no-js .md-typeset .tabbed-set>input:nth-child(19):checked~.tabbed-labels>:nth-child(19),.no-js .md-typeset .tabbed-set>input:nth-child(2):checked~.tabbed-labels>:nth-child(2),.no-js .md-typeset .tabbed-set>input:nth-child(20):checked~.tabbed-labels>:nth-child(20),.no-js .md-typeset .tabbed-set>input:nth-child(3):checked~.tabbed-labels>:nth-child(3),.no-js .md-typeset .tabbed-set>input:nth-child(4):checked~.tabbed-labels>:nth-child(4),.no-js .md-typeset .tabbed-set>input:nth-child(5):checked~.tabbed-labels>:nth-child(5),.no-js .md-typeset .tabbed-set>input:nth-child(6):checked~.tabbed-labels>:nth-child(6),.no-js .md-typeset .tabbed-set>input:nth-child(7):checked~.tabbed-labels>:nth-child(7),.no-js .md-typeset .tabbed-set>input:nth-child(8):checked~.tabbed-labels>:nth-child(8),.no-js .md-typeset .tabbed-set>input:nth-child(9):checked~.tabbed-labels>:nth-child(9){border-color:var(--md-default-fg-color)}}.md-typeset .tabbed-set>input:first-child.focus-visible~.tabbed-labels>:first-child,.md-typeset .tabbed-set>input:nth-child(10).focus-visible~.tabbed-labels>:nth-child(10),.md-typeset .tabbed-set>input:nth-child(11).focus-visible~.tabbed-labels>:nth-child(11),.md-typeset .tabbed-set>input:nth-child(12).focus-visible~.tabbed-labels>:nth-child(12),.md-typeset .tabbed-set>input:nth-child(13).focus-visible~.tabbed-labels>:nth-child(13),.md-typeset .tabbed-set>input:nth-child(14).focus-visible~.tabbed-labels>:nth-child(14),.md-typeset .tabbed-set>input:nth-child(15).focus-visible~.tabbed-labels>:nth-child(15),.md-typeset .tabbed-set>input:nth-child(16).focus-visible~.tabbed-labels>:nth-child(16),.md-typeset .tabbed-set>input:nth-child(17).focus-visible~.tabbed-labels>:nth-child(17),.md-typeset .tabbed-set>input:nth-child(18).focus-visible~.tabbed-labels>:nth-child(18),.md-typeset .tabbed-set>input:nth-child(19).focus-visible~.tabbed-labels>:nth-child(19),.md-typeset .tabbed-set>input:nth-child(2).focus-visible~.tabbed-labels>:nth-child(2),.md-typeset .tabbed-set>input:nth-child(20).focus-visible~.tabbed-labels>:nth-child(20),.md-typeset .tabbed-set>input:nth-child(3).focus-visible~.tabbed-labels>:nth-child(3),.md-typeset .tabbed-set>input:nth-child(4).focus-visible~.tabbed-labels>:nth-child(4),.md-typeset .tabbed-set>input:nth-child(5).focus-visible~.tabbed-labels>:nth-child(5),.md-typeset .tabbed-set>input:nth-child(6).focus-visible~.tabbed-labels>:nth-child(6),.md-typeset .tabbed-set>input:nth-child(7).focus-visible~.tabbed-labels>:nth-child(7),.md-typeset .tabbed-set>input:nth-child(8).focus-visible~.tabbed-labels>:nth-child(8),.md-typeset .tabbed-set>input:nth-child(9).focus-visible~.tabbed-labels>:nth-child(9){color:var(--md-accent-fg-color)}.md-typeset .tabbed-set>input:first-child:checked~.tabbed-content>:first-child,.md-typeset .tabbed-set>input:nth-child(10):checked~.tabbed-content>:nth-child(10),.md-typeset .tabbed-set>input:nth-child(11):checked~.tabbed-content>:nth-child(11),.md-typeset .tabbed-set>input:nth-child(12):checked~.tabbed-content>:nth-child(12),.md-typeset .tabbed-set>input:nth-child(13):checked~.tabbed-content>:nth-child(13),.md-typeset .tabbed-set>input:nth-child(14):checked~.tabbed-content>:nth-child(14),.md-typeset .tabbed-set>input:nth-child(15):checked~.tabbed-content>:nth-child(15),.md-typeset .tabbed-set>input:nth-child(16):checked~.tabbed-content>:nth-child(16),.md-typeset .tabbed-set>input:nth-child(17):checked~.tabbed-content>:nth-child(17),.md-typeset .tabbed-set>input:nth-child(18):checked~.tabbed-content>:nth-child(18),.md-typeset .tabbed-set>input:nth-child(19):checked~.tabbed-content>:nth-child(19),.md-typeset .tabbed-set>input:nth-child(2):checked~.tabbed-content>:nth-child(2),.md-typeset .tabbed-set>input:nth-child(20):checked~.tabbed-content>:nth-child(20),.md-typeset .tabbed-set>input:nth-child(3):checked~.tabbed-content>:nth-child(3),.md-typeset .tabbed-set>input:nth-child(4):checked~.tabbed-content>:nth-child(4),.md-typeset .tabbed-set>input:nth-child(5):checked~.tabbed-content>:nth-child(5),.md-typeset .tabbed-set>input:nth-child(6):checked~.tabbed-content>:nth-child(6),.md-typeset .tabbed-set>input:nth-child(7):checked~.tabbed-content>:nth-child(7),.md-typeset .tabbed-set>input:nth-child(8):checked~.tabbed-content>:nth-child(8),.md-typeset .tabbed-set>input:nth-child(9):checked~.tabbed-content>:nth-child(9){display:block}:root{--md-tasklist-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M1 12C1 5.925 5.925 1 12 1s11 4.925 11 11-4.925 11-11 11S1 18.075 1 12m16.28-2.72a.75.75 0 0 0-.018-1.042.75.75 0 0 0-1.042-.018l-5.97 5.97-2.47-2.47a.75.75 0 0 0-1.042.018.75.75 0 0 0-.018 1.042l3 3a.75.75 0 0 0 1.06 0Z"/></svg>');--md-tasklist-icon--checked:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M1 12C1 5.925 5.925 1 12 1s11 4.925 11 11-4.925 11-11 11S1 18.075 1 12m16.28-2.72a.75.75 0 0 0-.018-1.042.75.75 0 0 0-1.042-.018l-5.97 5.97-2.47-2.47a.75.75 0 0 0-1.042.018.75.75 0 0 0-.018 1.042l3 3a.75.75 0 0 0 1.06 0Z"/></svg>')}.md-typeset .task-list-item{list-style-type:none;position:relative}[dir=ltr] .md-typeset .task-list-item [type=checkbox]{left:-2em}[dir=rtl] .md-typeset .task-list-item [type=checkbox]{right:-2em}.md-typeset .task-list-item [type=checkbox]{position:absolute;top:.45em}.md-typeset .task-list-control [type=checkbox]{opacity:0;z-index:-1}[dir=ltr] .md-typeset .task-list-indicator:before{left:-1.5em}[dir=rtl] .md-typeset .task-list-indicator:before{right:-1.5em}.md-typeset .task-list-indicator:before{background-color:var(--md-default-fg-color--lightest);content:"";height:1.25em;-webkit-mask-image:var(--md-tasklist-icon);mask-image:var(--md-tasklist-icon);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;position:absolute;top:.15em;width:1.25em}.md-typeset [type=checkbox]:checked+.task-list-indicator:before{background-color:#00e676;-webkit-mask-image:var(--md-tasklist-icon--checked);mask-image:var(--md-tasklist-icon--checked)}@media print{.giscus,[id=__comments]{display:none}}:root>*{--md-mermaid-font-family:var(--md-text-font-family),sans-serif;--md-mermaid-edge-color:var(--md-code-fg-color);--md-mermaid-node-bg-color:var(--md-accent-fg-color--transparent);--md-mermaid-node-fg-color:var(--md-accent-fg-color);--md-mermaid-label-bg-color:var(--md-default-bg-color);--md-mermaid-label-fg-color:var(--md-code-fg-color);--md-mermaid-sequence-actor-bg-color:var(--md-mermaid-label-bg-color);--md-mermaid-sequence-actor-fg-color:var(--md-mermaid-label-fg-color);--md-mermaid-sequence-actor-border-color:var(--md-mermaid-node-fg-color);--md-mermaid-sequence-actor-line-color:var(--md-default-fg-color--lighter);--md-mermaid-sequence-actorman-bg-color:var(--md-mermaid-label-bg-color);--md-mermaid-sequence-actorman-line-color:var(--md-mermaid-node-fg-color);--md-mermaid-sequence-box-bg-color:var(--md-mermaid-node-bg-color);--md-mermaid-sequence-box-fg-color:var(--md-mermaid-edge-color);--md-mermaid-sequence-label-bg-color:var(--md-mermaid-node-bg-color);--md-mermaid-sequence-label-fg-color:var(--md-mermaid-node-fg-color);--md-mermaid-sequence-loop-bg-color:var(--md-mermaid-node-bg-color);--md-mermaid-sequence-loop-fg-color:var(--md-mermaid-edge-color);--md-mermaid-sequence-loop-border-color:var(--md-mermaid-node-fg-color);--md-mermaid-sequence-message-fg-color:var(--md-mermaid-edge-color);--md-mermaid-sequence-message-line-color:var(--md-mermaid-edge-color);--md-mermaid-sequence-note-bg-color:var(--md-mermaid-label-bg-color);--md-mermaid-sequence-note-fg-color:var(--md-mermaid-edge-color);--md-mermaid-sequence-note-border-color:var(--md-mermaid-label-fg-color);--md-mermaid-sequence-number-bg-color:var(--md-mermaid-node-fg-color);--md-mermaid-sequence-number-fg-color:var(--md-accent-bg-color)}.mermaid{line-height:normal;margin:1em 0}.md-typeset .grid{grid-gap:.4rem;display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,16rem),1fr));margin:1em 0}.md-typeset .grid.cards>ol,.md-typeset .grid.cards>ul{display:contents}.md-typeset .grid.cards>ol>li,.md-typeset .grid.cards>ul>li,.md-typeset .grid>.card{border:.05rem solid var(--md-default-fg-color--lightest);border-radius:.1rem;display:block;margin:0;padding:.8rem;transition:border .25s,box-shadow .25s}.md-typeset .grid.cards>ol>li:focus-within,.md-typeset .grid.cards>ol>li:hover,.md-typeset .grid.cards>ul>li:focus-within,.md-typeset .grid.cards>ul>li:hover,.md-typeset .grid>.card:focus-within,.md-typeset .grid>.card:hover{border-color:#0000;box-shadow:var(--md-shadow-z2)}.md-typeset .grid.cards>ol>li>hr,.md-typeset .grid.cards>ul>li>hr,.md-typeset .grid>.card>hr{margin-bottom:1em;margin-top:1em}.md-typeset .grid.cards>ol>li>:first-child,.md-typeset .grid.cards>ul>li>:first-child,.md-typeset .grid>.card>:first-child{margin-top:0}.md-typeset .grid.cards>ol>li>:last-child,.md-typeset .grid.cards>ul>li>:last-child,.md-typeset .grid>.card>:last-child{margin-bottom:0}.md-typeset .grid>*,.md-typeset .grid>.admonition,.md-typeset .grid>.highlight>*,.md-typeset .grid>.highlighttable,.md-typeset .grid>.md-typeset details,.md-typeset .grid>details,.md-typeset .grid>pre{margin-bottom:0;margin-top:0}.md-typeset .grid>.highlight>pre:only-child,.md-typeset .grid>.highlight>pre>code,.md-typeset .grid>.highlighttable,.md-typeset .grid>.highlighttable>tbody,.md-typeset .grid>.highlighttable>tbody>tr,.md-typeset .grid>.highlighttable>tbody>tr>.code,.md-typeset .grid>.highlighttable>tbody>tr>.code>.highlight,.md-typeset .grid>.highlighttable>tbody>tr>.code>.highlight>pre,.md-typeset .grid>.highlighttable>tbody>tr>.code>.highlight>pre>code{height:100%}.md-typeset .grid>.tabbed-set{margin-bottom:0;margin-top:0}@media screen and (min-width:45em){[dir=ltr] .md-typeset .inline{float:left}[dir=rtl] .md-typeset .inline{float:right}[dir=ltr] .md-typeset .inline{margin-right:.8rem}[dir=rtl] .md-typeset .inline{margin-left:.8rem}.md-typeset .inline{margin-bottom:.8rem;margin-top:0;width:11.7rem}[dir=ltr] .md-typeset .inline.end{float:right}[dir=rtl] .md-typeset .inline.end{float:left}[dir=ltr] .md-typeset .inline.end{margin-left:.8rem;margin-right:0}[dir=rtl] .md-typeset .inline.end{margin-left:0;margin-right:.8rem}}
\ No newline at end of file
diff --git a/main/assets/stylesheets/main.6f8fc17f.min.css.map b/main/assets/stylesheets/main.6f8fc17f.min.css.map
new file mode 100644
index 000000000..8ba5ce39e
--- /dev/null
+++ b/main/assets/stylesheets/main.6f8fc17f.min.css.map
@@ -0,0 +1 @@
+{"version":3,"sources":["src/templates/assets/stylesheets/main/components/_meta.scss","../../../../src/templates/assets/stylesheets/main.scss","src/templates/assets/stylesheets/main/_resets.scss","src/templates/assets/stylesheets/main/_colors.scss","src/templates/assets/stylesheets/main/_icons.scss","src/templates/assets/stylesheets/main/_typeset.scss","src/templates/assets/stylesheets/utilities/_break.scss","src/templates/assets/stylesheets/main/components/_author.scss","src/templates/assets/stylesheets/main/components/_banner.scss","src/templates/assets/stylesheets/main/components/_base.scss","src/templates/assets/stylesheets/main/components/_clipboard.scss","src/templates/assets/stylesheets/main/components/_code.scss","src/templates/assets/stylesheets/main/components/_consent.scss","src/templates/assets/stylesheets/main/components/_content.scss","src/templates/assets/stylesheets/main/components/_dialog.scss","src/templates/assets/stylesheets/main/components/_feedback.scss","src/templates/assets/stylesheets/main/components/_footer.scss","src/templates/assets/stylesheets/main/components/_form.scss","src/templates/assets/stylesheets/main/components/_header.scss","node_modules/material-design-color/material-color.scss","src/templates/assets/stylesheets/main/components/_nav.scss","src/templates/assets/stylesheets/main/components/_pagination.scss","src/templates/assets/stylesheets/main/components/_post.scss","src/templates/assets/stylesheets/main/components/_progress.scss","src/templates/assets/stylesheets/main/components/_search.scss","src/templates/assets/stylesheets/main/components/_select.scss","src/templates/assets/stylesheets/main/components/_sidebar.scss","src/templates/assets/stylesheets/main/components/_source.scss","src/templates/assets/stylesheets/main/components/_status.scss","src/templates/assets/stylesheets/main/components/_tabs.scss","src/templates/assets/stylesheets/main/components/_tag.scss","src/templates/assets/stylesheets/main/components/_tooltip.scss","src/templates/assets/stylesheets/main/components/_tooltip2.scss","src/templates/assets/stylesheets/main/components/_top.scss","src/templates/assets/stylesheets/main/components/_version.scss","src/templates/assets/stylesheets/main/extensions/markdown/_admonition.scss","src/templates/assets/stylesheets/main/extensions/markdown/_footnotes.scss","src/templates/assets/stylesheets/main/extensions/markdown/_toc.scss","src/templates/assets/stylesheets/main/extensions/pymdownx/_arithmatex.scss","src/templates/assets/stylesheets/main/extensions/pymdownx/_critic.scss","src/templates/assets/stylesheets/main/extensions/pymdownx/_details.scss","src/templates/assets/stylesheets/main/extensions/pymdownx/_emoji.scss","src/templates/assets/stylesheets/main/extensions/pymdownx/_highlight.scss","src/templates/assets/stylesheets/main/extensions/pymdownx/_keys.scss","src/templates/assets/stylesheets/main/extensions/pymdownx/_tabbed.scss","src/templates/assets/stylesheets/main/extensions/pymdownx/_tasklist.scss","src/templates/assets/stylesheets/main/integrations/_giscus.scss","src/templates/assets/stylesheets/main/integrations/_mermaid.scss","src/templates/assets/stylesheets/main/modifiers/_grid.scss","src/templates/assets/stylesheets/main/modifiers/_inline.scss"],"names":[],"mappings":"AA0CE,gBC4yCF,CC1zCA,KAEE,6BAAA,CAAA,0BAAA,CAAA,qBAAA,CADA,qBDzBF,CC8BA,iBAGE,kBD3BF,CC8BE,gCANF,iBAOI,yBDzBF,CACF,CC6BA,KACE,QD1BF,CC8BA,qBAIE,uCD3BF,CC+BA,EACE,aAAA,CACA,oBD5BF,CCgCA,GAME,QAAA,CALA,kBAAA,CACA,aAAA,CACA,aAAA,CAEA,gBAAA,CADA,SD3BF,CCiCA,MACE,aD9BF,CCkCA,QAEE,eD/BF,CCmCA,IACE,iBDhCF,CCoCA,MAEE,uBAAA,CADA,gBDhCF,CCqCA,MAEE,eAAA,CACA,kBDlCF,CCsCA,OAKE,gBAAA,CACA,QAAA,CAHA,mBAAA,CACA,iBAAA,CAFA,QAAA,CADA,SD9BF,CCuCA,MACE,QAAA,CACA,YDpCF,CErDA,MAIE,6BAAA,CACA,oCAAA,CACA,mCAAA,CACA,0BAAA,CACA,sCAAA,CAGA,4BAAA,CACA,2CAAA,CACA,yBAAA,CACA,qCFmDF,CE7CA,+BAIE,kBF6CF,CE1CE,oHAEE,YF4CJ,CEnCA,qCAIE,eAAA,CAGA,+BAAA,CACA,sCAAA,CACA,wCAAA,CACA,yCAAA,CACA,0BAAA,CACA,sCAAA,CACA,wCAAA,CACA,yCAAA,CAGA,0BAAA,CACA,0BAAA,CAGA,0BAAA,CACA,mCAAA,CAGA,iCAAA,CACA,kCAAA,CACA,mCAAA,CACA,mCAAA,CACA,kCAAA,CACA,iCAAA,CACA,+CAAA,CACA,6DAAA,CACA,gEAAA,CACA,4DAAA,CACA,4DAAA,CACA,6DAAA,CAGA,6CAAA,CAGA,+CAAA,CAGA,gCAAA,CACA,gCAAA,CAGA,8BAAA,CACA,kCAAA,CACA,qCAAA,CAGA,iCAAA,CAGA,kCAAA,CACA,gDAAA,CAGA,mDAAA,CACA,mDAAA,CAGA,+BAAA,CACA,0BAAA,CAGA,yBAAA,CACA,qCAAA,CACA,uCAAA,CACA,8BAAA,CACA,oCAAA,CAGA,8DAAA,CAKA,8DAAA,CAKA,0DFKF,CG9HE,aAIE,iBAAA,CAHA,aAAA,CAEA,aAAA,CADA,YHmIJ,CIxIA,KACE,kCAAA,CACA,iCAAA,CAGA,uGAAA,CAKA,mFJyIF,CInIA,iBAIE,mCAAA,CACA,6BAAA,CAFA,sCJwIF,CIlIA,aAIE,4BAAA,CADA,sCJsIF,CI7HA,MACE,wNAAA,CACA,gNAAA,CACA,iNJgIF,CIzHA,YAGE,gCAAA,CAAA,kBAAA,CAFA,eAAA,CACA,eJ6HF,CIxHE,aAPF,YAQI,gBJ2HF,CACF,CIxHE,uGAME,iBAAA,CAAA,cJ0HJ,CItHE,eAKE,uCAAA,CAHA,aAAA,CAEA,eAAA,CAHA,iBJ6HJ,CIpHE,8BAPE,eAAA,CAGA,qBJ+HJ,CI3HE,eAEE,kBAAA,CAEA,eAAA,CAHA,oBJ0HJ,CIlHE,eAEE,gBAAA,CACA,eAAA,CAEA,qBAAA,CADA,eAAA,CAHA,mBJwHJ,CIhHE,kBACE,eJkHJ,CI9GE,eAEE,eAAA,CACA,qBAAA,CAFA,YJkHJ,CI5GE,8BAKE,uCAAA,CAFA,cAAA,CACA,eAAA,CAEA,qBAAA,CAJA,eJkHJ,CI1GE,eACE,wBJ4GJ,CIzGI,oBACE,mBJ2GN,CItGE,eAGE,+DAAA,CAFA,iBAAA,CACA,cJyGJ,CIpGE,cACE,+BAAA,CACA,qBJsGJ,CInGI,mCAEE,sBJoGN,CIhGI,wCACE,+BJkGN,CI/FM,kDACE,uDJiGR,CI5FI,mBACE,kBAAA,CACA,iCJ8FN,CI1FI,4BACE,uCAAA,CACA,oBJ4FN,CIvFE,iDAIE,6BAAA,CACA,aAAA,CAFA,2BJ2FJ,CItFI,aARF,iDASI,oBJ2FJ,CACF,CIvFE,iBAIE,wCAAA,CACA,mBAAA,CACA,kCAAA,CAAA,0BAAA,CAJA,eAAA,CADA,uBAAA,CAEA,qBJ4FJ,CItFI,qCAEE,uCAAA,CADA,YJyFN,CInFE,gBAEE,iBAAA,CACA,eAAA,CAFA,iBJuFJ,CIlFI,qBAWE,kCAAA,CAAA,0BAAA,CADA,eAAA,CATA,aAAA,CAEA,QAAA,CAMA,uCAAA,CALA,aAAA,CAFA,oCAAA,CAKA,yDAAA,CACA,oBAAA,CAFA,iBAAA,CADA,iBJ0FN,CIjFM,2BACE,+CJmFR,CI/EM,wCAEE,YAAA,CADA,WJkFR,CI7EM,8CACE,oDJ+ER,CI5EQ,oDACE,0CJ8EV,CIvEE,gBAOE,4CAAA,CACA,mBAAA,CACA,mKACE,CANF,gCAAA,CAHA,oBAAA,CAEA,eAAA,CADA,uBAAA,CAIA,uBAAA,CADA,qBJ6EJ,CIlEE,iBAGE,6CAAA,CACA,kCAAA,CAAA,0BAAA,CAHA,aAAA,CACA,qBJsEJ,CIhEE,iBAGE,6DAAA,CADA,WAAA,CADA,oBJoEJ,CI9DE,kBACE,WJgEJ,CI5DE,oDAEE,qBJ8DJ,CIhEE,oDAEE,sBJ8DJ,CI1DE,iCACE,kBJ+DJ,CIhEE,iCACE,mBJ+DJ,CIhEE,iCAIE,2DJ4DJ,CIhEE,iCAIE,4DJ4DJ,CIhEE,uBAGE,uCAAA,CADA,aAAA,CAAA,cJ8DJ,CIxDE,eACE,oBJ0DJ,CItDI,qBACE,4BJwDN,CInDE,kDAGE,kBJqDJ,CIxDE,kDAGE,mBJqDJ,CIxDE,8BAEE,SJsDJ,CIlDI,0DACE,iBJqDN,CIjDI,oCACE,2BJoDN,CIjDM,0CACE,2BJoDR,CIjDQ,gDACE,2BJoDV,CIjDU,sDACE,2BJoDZ,CI5CI,0CACE,4BJ+CN,CI3CI,wDACE,kBJ+CN,CIhDI,wDACE,mBJ+CN,CIhDI,oCAEE,kBJ8CN,CI3CM,kGAEE,aJ+CR,CI3CM,0DACE,eJ8CR,CI1CM,4HAEE,kBJ6CR,CI/CM,4HAEE,mBJ6CR,CI/CM,oFACE,kBAAA,CAAA,eJ8CR,CIvCE,yBAEE,mBJyCJ,CI3CE,yBAEE,oBJyCJ,CI3CE,eACE,mBAAA,CAAA,cJ0CJ,CIrCE,kDAIE,WAAA,CADA,cJwCJ,CIhCI,4BAEE,oBJkCN,CI9BI,6BAEE,oBJgCN,CI5BI,kCACE,YJ8BN,CIzBE,mBACE,iBAAA,CAGA,eAAA,CADA,cAAA,CAEA,iBAAA,CAHA,sBAAA,CAAA,iBJ8BJ,CIxBI,uBACE,aAAA,CACA,aJ0BN,CIrBE,uBAGE,iBAAA,CADA,eAAA,CADA,eJyBJ,CInBE,mBACE,cJqBJ,CIjBE,+BAME,2CAAA,CACA,iDAAA,CACA,mBAAA,CAPA,oBAAA,CAGA,gBAAA,CAFA,cAAA,CACA,aAAA,CAEA,iBJsBJ,CIhBI,aAXF,+BAYI,aJmBJ,CACF,CIdI,iCACE,gBJgBN,CITM,8FACE,YJWR,CIPM,4FACE,eJSR,CIJI,8FACE,eJMN,CIHM,kHACE,gBJKR,CIAI,kCAGE,eAAA,CAFA,cAAA,CACA,sBAAA,CAEA,kBJEN,CIEI,kCAGE,qDAAA,CAFA,sBAAA,CACA,kBJCN,CIII,wCACE,iCJFN,CIKM,8CACE,qDAAA,CACA,sDJHR,CIQI,iCACE,iBJNN,CIWE,wCACE,cJTJ,CIYI,wDAIE,gBJJN,CIAI,wDAIE,iBJJN,CIAI,8CAME,UAAA,CALA,oBAAA,CAEA,YAAA,CAIA,oDAAA,CAAA,4CAAA,CACA,6BAAA,CAAA,qBAAA,CACA,yBAAA,CAAA,iBAAA,CACA,iCAAA,CALA,0BAAA,CAHA,WJFN,CIcI,oDACE,oDJZN,CIgBI,mEACE,kDAAA,CACA,yDAAA,CAAA,iDJdN,CIkBI,oEACE,kDAAA,CACA,0DAAA,CAAA,kDJhBN,CIqBE,wBACE,iBAAA,CACA,eAAA,CACA,iBJnBJ,CIuBE,mBACE,oBAAA,CAEA,kBAAA,CADA,eJpBJ,CIwBI,aANF,mBAOI,aJrBJ,CACF,CIwBI,8BACE,aAAA,CAEA,QAAA,CACA,eAAA,CAFA,UJpBN,CKrWI,0CDwYF,uBACE,iBJ/BF,CIkCE,4BACE,eJhCJ,CACF,CMpiBE,uBAOE,kBAAA,CALA,aAAA,CACA,aAAA,CAEA,aAAA,CACA,eAAA,CALA,iBAAA,CAOA,sCACE,CALF,YN0iBJ,CMjiBI,2BACE,aNmiBN,CM/hBI,6BAME,+CAAA,CAFA,yCAAA,CAHA,eAAA,CACA,eAAA,CACA,kBAAA,CAEA,iBNkiBN,CM7hBI,6BAEE,aAAA,CADA,YNgiBN,CM1hBE,wBACE,kBN4hBJ,CMzhBI,4BAIE,kBAAA,CAHA,mCAAA,CAIA,uBNyhBN,CMrhBI,4DAEE,oBAAA,CADA,SNwhBN,CMphBM,oEACE,mBNshBR,CO/kBA,WAGE,0CAAA,CADA,+BAAA,CADA,aPolBF,CO/kBE,aANF,WAOI,YPklBF,CACF,CO/kBE,oBAEE,2CAAA,CADA,gCPklBJ,CO7kBE,kBAGE,eAAA,CADA,iBAAA,CADA,ePilBJ,CO3kBE,6BACE,WPglBJ,COjlBE,6BACE,UPglBJ,COjlBE,mBAEE,aAAA,CACA,cAAA,CACA,uBP6kBJ,CO1kBI,0BACE,YP4kBN,COxkBI,yBACE,UP0kBN,CQ/mBA,KASE,cAAA,CARA,WAAA,CACA,iBRmnBF,CK/cI,oCGtKJ,KAaI,gBR4mBF,CACF,CKpdI,oCGtKJ,KAkBI,cR4mBF,CACF,CQvmBA,KASE,2CAAA,CAPA,YAAA,CACA,qBAAA,CAKA,eAAA,CAHA,eAAA,CAJA,iBAAA,CAGA,UR6mBF,CQrmBE,aAZF,KAaI,aRwmBF,CACF,CKrdI,0CGhJF,yBAII,cRqmBJ,CACF,CQ5lBA,SAEE,gBAAA,CAAA,iBAAA,CADA,eRgmBF,CQ3lBA,cACE,YAAA,CAEA,qBAAA,CADA,WR+lBF,CQ3lBE,aANF,cAOI,aR8lBF,CACF,CQ1lBA,SACE,WR6lBF,CQ1lBE,gBACE,YAAA,CACA,WAAA,CACA,iBR4lBJ,CQvlBA,aACE,eAAA,CACA,sBR0lBF,CQjlBA,WACE,YRolBF,CQ/kBA,WAGE,QAAA,CACA,SAAA,CAHA,iBAAA,CACA,ORolBF,CQ/kBE,uCACE,aRilBJ,CQ7kBE,+BAEE,uCAAA,CADA,kBRglBJ,CQ1kBA,SASE,2CAAA,CACA,mBAAA,CAFA,gCAAA,CADA,gBAAA,CADA,YAAA,CAMA,SAAA,CADA,uCAAA,CANA,mBAAA,CAJA,cAAA,CAYA,2BAAA,CATA,URolBF,CQxkBE,eAEE,SAAA,CAIA,uBAAA,CAHA,oEACE,CAHF,UR6kBJ,CQ/jBA,MACE,WRkkBF,CS3tBA,MACE,6PT6tBF,CSvtBA,cASE,mBAAA,CAFA,0CAAA,CACA,cAAA,CAFA,YAAA,CAIA,uCAAA,CACA,oBAAA,CAVA,iBAAA,CAEA,UAAA,CADA,QAAA,CAUA,qBAAA,CAPA,WAAA,CADA,STkuBF,CSvtBE,aAfF,cAgBI,YT0tBF,CACF,CSvtBE,kCAEE,uCAAA,CADA,YT0tBJ,CSrtBE,qBACE,uCTutBJ,CSntBE,wCACE,+BTqtBJ,CShtBE,oBAME,6BAAA,CADA,UAAA,CAJA,aAAA,CAEA,cAAA,CACA,aAAA,CAGA,2CAAA,CAAA,mCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CARA,aT0tBJ,CS9sBE,sBACE,cTgtBJ,CS7sBI,2BACE,2CT+sBN,CSzsBI,kEAEE,uDAAA,CADA,+BT4sBN,CU9wBE,8BACE,YVixBJ,CWtxBA,mBACE,GACE,SAAA,CACA,0BXyxBF,CWtxBA,GACE,SAAA,CACA,uBXwxBF,CACF,CWpxBA,mBACE,GACE,SXsxBF,CWnxBA,GACE,SXqxBF,CACF,CW1wBE,qBASE,2BAAA,CAFA,mCAAA,CAAA,2BAAA,CADA,0BAAA,CADA,WAAA,CAGA,SAAA,CAPA,cAAA,CACA,KAAA,CAEA,UAAA,CADA,SXkxBJ,CWxwBE,mBAcE,mDAAA,CANA,2CAAA,CACA,QAAA,CACA,mBAAA,CARA,QAAA,CASA,kDACE,CAPF,eAAA,CAEA,aAAA,CADA,SAAA,CALA,cAAA,CAGA,UAAA,CADA,SXmxBJ,CWpwBE,kBACE,aXswBJ,CWlwBE,sBACE,YAAA,CACA,YXowBJ,CWjwBI,oCACE,aXmwBN,CW9vBE,sBACE,mBXgwBJ,CW7vBI,6CACE,cX+vBN,CKzpBI,0CMvGA,6CAKI,aAAA,CAEA,gBAAA,CACA,iBAAA,CAFA,UXiwBN,CACF,CW1vBE,kBACE,cX4vBJ,CY71BA,YACE,WAAA,CAIA,WZ61BF,CY11BE,mBAEE,qBAAA,CADA,iBZ61BJ,CKhsBI,sCOtJE,4EACE,kBZy1BN,CYr1BI,0JACE,mBZu1BN,CYx1BI,8EACE,kBZu1BN,CACF,CYl1BI,0BAGE,UAAA,CAFA,aAAA,CACA,YZq1BN,CYh1BI,+BACE,eZk1BN,CY50BE,8BACE,WZi1BJ,CYl1BE,8BACE,UZi1BJ,CYl1BE,8BAIE,iBZ80BJ,CYl1BE,8BAIE,kBZ80BJ,CYl1BE,oBAGE,cAAA,CADA,SZg1BJ,CY30BI,aAPF,oBAQI,YZ80BJ,CACF,CY30BI,gCACE,yCZ60BN,CYz0BI,wBACE,cAAA,CACA,kBZ20BN,CYx0BM,kCACE,oBZ00BR,Ca34BA,qBAEE,Wby5BF,Ca35BA,qBAEE,Uby5BF,Ca35BA,WAQE,2CAAA,CACA,mBAAA,CANA,YAAA,CAOA,8BAAA,CALA,iBAAA,CAMA,SAAA,CALA,mBAAA,CACA,mBAAA,CANA,cAAA,CAcA,0BAAA,CAHA,wCACE,CATF,Sbu5BF,Caz4BE,aAlBF,WAmBI,Yb44BF,CACF,Caz4BE,mBAEE,SAAA,CADA,mBAAA,CAKA,uBAAA,CAHA,kEb44BJ,Car4BE,kBAEE,gCAAA,CADA,ebw4BJ,Cc16BA,aACE,gBAAA,CACA,iBd66BF,Cc16BE,sBAGE,WAAA,CADA,QAAA,CADA,Sd86BJ,Ccx6BE,oBAEE,eAAA,CADA,ed26BJ,Cct6BE,oBACE,iBdw6BJ,Ccp6BE,mBAEE,YAAA,CACA,cAAA,CACA,6BAAA,CAHA,iBdy6BJ,Ccn6BI,iDACE,yCdq6BN,Ccj6BI,6BACE,iBdm6BN,Cc95BE,mBAGE,uCAAA,CACA,cAAA,CAHA,aAAA,CACA,cAAA,CAGA,sBdg6BJ,Cc75BI,gDACE,+Bd+5BN,Cc35BI,4BACE,0CAAA,CACA,mBd65BN,Ccx5BE,mBAEE,SAAA,CADA,iBAAA,CAKA,2BAAA,CAHA,8Dd25BJ,Ccr5BI,qBAEE,aAAA,CADA,edw5BN,Ccn5BI,6BACE,SAAA,CACA,uBdq5BN,Cch5BE,aAnFF,aAoFI,Ydm5BF,CACF,Cex+BA,WAEE,0CAAA,CADA,+Bf4+BF,Cex+BE,aALF,WAMI,Yf2+BF,CACF,Cex+BE,kBACE,6BAAA,CAEA,aAAA,CADA,af2+BJ,Cev+BI,gCACE,Yfy+BN,Cep+BE,iBAOE,eAAA,CANA,YAAA,CAKA,cAAA,CAGA,mBAAA,CAAA,eAAA,CADA,cAAA,CAGA,uCAAA,CADA,eAAA,CAEA,uBfk+BJ,Ce/9BI,8CACE,Ufi+BN,Ce79BI,+BACE,oBf+9BN,CKj1BI,0CUvIE,uBACE,af29BN,Cex9BM,yCACE,Yf09BR,CACF,Cer9BI,iCACE,gBfw9BN,Cez9BI,iCACE,iBfw9BN,Cez9BI,uBAEE,gBfu9BN,Cep9BM,iCACE,efs9BR,Ceh9BE,kBACE,WAAA,CAIA,eAAA,CADA,mBAAA,CAFA,6BAAA,CACA,cAAA,CAGA,kBfk9BJ,Ce98BE,mBAEE,YAAA,CADA,afi9BJ,Ce58BE,sBACE,gBAAA,CACA,Uf88BJ,Cez8BA,gBACE,gDf48BF,Cez8BE,uBACE,YAAA,CACA,cAAA,CACA,6BAAA,CACA,af28BJ,Cev8BE,kCACE,sCfy8BJ,Cet8BI,gFACE,+Bfw8BN,Ceh8BA,cAKE,wCAAA,CADA,gBAAA,CADA,iBAAA,CADA,eAAA,CADA,Ufu8BF,CK35BI,mCU7CJ,cASI,Ufm8BF,CACF,Ce/7BE,yBACE,sCfi8BJ,Ce17BA,WACE,mBAAA,CACA,SAAA,CAEA,cAAA,CADA,qBf87BF,CK16BI,mCUvBJ,WAQI,ef67BF,CACF,Ce17BE,iBACE,oBAAA,CAEA,aAAA,CACA,iBAAA,CAFA,Yf87BJ,Cez7BI,wBACE,ef27BN,Cev7BI,qBAGE,iBAAA,CAFA,gBAAA,CACA,mBf07BN,CgBhmCE,uBAME,kBAAA,CACA,mBAAA,CAHA,gCAAA,CACA,cAAA,CAJA,oBAAA,CAEA,eAAA,CADA,kBAAA,CAMA,gEhBmmCJ,CgB7lCI,gCAEE,2CAAA,CACA,uCAAA,CAFA,gChBimCN,CgB3lCI,0DAEE,0CAAA,CACA,sCAAA,CAFA,+BhB+lCN,CgBxlCE,gCAKE,4BhB6lCJ,CgBlmCE,gEAME,6BhB4lCJ,CgBlmCE,gCAME,4BhB4lCJ,CgBlmCE,sBAIE,6DAAA,CAGA,8BAAA,CAJA,eAAA,CAFA,aAAA,CACA,eAAA,CAMA,sChB0lCJ,CgBrlCI,wDACE,6CAAA,CACA,8BhBulCN,CgBnlCI,+BACE,UhBqlCN,CiBxoCA,WAOE,2CAAA,CAGA,8CACE,CALF,gCAAA,CADA,aAAA,CAHA,MAAA,CADA,eAAA,CACA,OAAA,CACA,KAAA,CACA,SjB+oCF,CiBpoCE,aAfF,WAgBI,YjBuoCF,CACF,CiBpoCE,mBAIE,2BAAA,CAHA,iEjBuoCJ,CiBhoCE,mBACE,kDACE,CAEF,kEjBgoCJ,CiB1nCE,kBAEE,kBAAA,CADA,YAAA,CAEA,ejB4nCJ,CiBxnCE,mBAKE,kBAAA,CAEA,cAAA,CAHA,YAAA,CAIA,uCAAA,CALA,aAAA,CAFA,iBAAA,CAQA,uBAAA,CAHA,qBAAA,CAJA,SjBioCJ,CiBvnCI,yBACE,UjBynCN,CiBrnCI,iCACE,oBjBunCN,CiBnnCI,uCAEE,uCAAA,CADA,YjBsnCN,CiBjnCI,2BAEE,YAAA,CADA,ajBonCN,CKtgCI,0CY/GA,2BAMI,YjBmnCN,CACF,CiBhnCM,8DAIE,iBAAA,CAHA,aAAA,CAEA,aAAA,CADA,UjBonCR,CKpiCI,mCYzEA,iCAII,YjB6mCN,CACF,CiB1mCM,wCACE,YjB4mCR,CiBxmCM,+CACE,oBjB0mCR,CK/iCI,sCYtDA,iCAII,YjBqmCN,CACF,CiBhmCE,kBAEE,YAAA,CACA,cAAA,CAFA,iBAAA,CAIA,8DACE,CAFF,kBjBmmCJ,CiB7lCI,oCAGE,SAAA,CADA,mBAAA,CAKA,6BAAA,CAHA,8DACE,CAJF,UjBmmCN,CiB1lCM,8CACE,8BjB4lCR,CiBvlCI,8BACE,ejBylCN,CiBplCE,4BAGE,gBAAA,CAAA,kBjBwlCJ,CiB3lCE,4BAGE,iBAAA,CAAA,iBjBwlCJ,CiB3lCE,kBACE,WAAA,CAGA,eAAA,CAFA,aAAA,CAGA,kBjBslCJ,CiBnlCI,4CAGE,SAAA,CADA,mBAAA,CAKA,8BAAA,CAHA,8DACE,CAJF,UjBylCN,CiBhlCM,sDACE,6BjBklCR,CiB9kCM,8DAGE,SAAA,CADA,mBAAA,CAKA,uBAAA,CAHA,8DACE,CAJF,SjBolCR,CiBzkCI,uCAGE,WAAA,CAFA,iBAAA,CACA,UjB4kCN,CiBtkCE,mBACE,YAAA,CACA,aAAA,CACA,cAAA,CAEA,+CACE,CAFF,kBjBykCJ,CiBnkCI,8DACE,WAAA,CACA,SAAA,CACA,oCjBqkCN,CiB5jCI,yBACE,QjB8jCN,CiBzjCE,mBACE,YjB2jCJ,CKvnCI,mCY2DF,6BAQI,gBjB2jCJ,CiBnkCA,6BAQI,iBjB2jCJ,CiBnkCA,mBAKI,aAAA,CAEA,iBAAA,CADA,ajB6jCJ,CACF,CK/nCI,sCY2DF,6BAaI,kBjB2jCJ,CiBxkCA,6BAaI,mBjB2jCJ,CACF,CD1yCA,SAGE,uCAAA,CAFA,eAAA,CACA,eC8yCF,CD1yCE,eACE,mBAAA,CACA,cAAA,CAGA,eAAA,CADA,QAAA,CADA,SC8yCJ,CDxyCE,sCAEE,WAAA,CADA,iBAAA,CAAA,kBC2yCJ,CDtyCE,eACE,+BCwyCJ,CDryCI,0CACE,+BCuyCN,CDjyCA,UAKE,wBmBaa,CnBZb,oBAAA,CAFA,UAAA,CAHA,oBAAA,CAEA,eAAA,CADA,0BAAA,CAAA,2BCwyCF,CmB10CA,MACE,uMAAA,CACA,sLAAA,CACA,iNnB60CF,CmBv0CA,QACE,eAAA,CACA,enB00CF,CmBv0CE,eAKE,uCAAA,CAJA,aAAA,CAGA,eAAA,CADA,eAAA,CADA,eAAA,CAIA,sBnBy0CJ,CmBt0CI,+BACE,YnBw0CN,CmBr0CM,mCAEE,WAAA,CADA,UnBw0CR,CmBh0CQ,sFAME,iBAAA,CALA,aAAA,CAGA,aAAA,CADA,cAAA,CAEA,kBAAA,CAHA,UnBs0CV,CmB3zCE,cAGE,eAAA,CADA,QAAA,CADA,SnB+zCJ,CmBzzCE,cAGE,sBAAA,CAFA,YAAA,CACA,SAAA,CAEA,iBAAA,CACA,uBAAA,CACA,sBnB2zCJ,CmBxzCI,sBACE,uCnB0zCN,CmBnzCM,6EAEE,+BnBqzCR,CmBhzCI,2BAIE,iBnB+yCN,CmB3yCI,4CACE,gBnB6yCN,CmB9yCI,4CACE,iBnB6yCN,CmBzyCI,kBAME,iBAAA,CAFA,aAAA,CACA,YAAA,CAFA,iBnB4yCN,CmBryCI,sGACE,+BAAA,CACA,cnBuyCN,CmBnyCI,4BACE,uCAAA,CACA,oBnBqyCN,CmBjyCI,0CACE,YnBmyCN,CmBhyCM,yDAIE,6BAAA,CAHA,aAAA,CAEA,WAAA,CAEA,qCAAA,CAAA,6BAAA,CAHA,UnBqyCR,CmB9xCM,kDACE,YnBgyCR,CmB1xCE,iCACE,YnB4xCJ,CmBzxCI,6CACE,WAAA,CAGA,WnByxCN,CmBpxCE,cACE,anBsxCJ,CmBlxCE,gBACE,YnBoxCJ,CKrvCI,0CcxBA,0CASE,2CAAA,CAHA,YAAA,CACA,qBAAA,CACA,WAAA,CALA,MAAA,CADA,iBAAA,CACA,OAAA,CACA,KAAA,CACA,SnBmxCJ,CmBxwCI,+DACE,eAAA,CACA,enB0wCN,CmBtwCI,gCAQE,qDAAA,CAHA,uCAAA,CAEA,cAAA,CALA,aAAA,CAEA,kBAAA,CADA,wBAAA,CAFA,iBAAA,CAKA,kBnB0wCN,CmBrwCM,wDAEE,UnB4wCR,CmB9wCM,wDAEE,WnB4wCR,CmB9wCM,8CAIE,aAAA,CAEA,aAAA,CACA,YAAA,CANA,iBAAA,CAEA,SAAA,CAEA,YnBywCR,CmBpwCQ,oDAKE,6BAAA,CADA,UAAA,CAHA,aAAA,CAEA,WAAA,CAGA,2CAAA,CAAA,mCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CAPA,UnB6wCV,CmBjwCM,8CAIE,2CAAA,CACA,gEACE,CALF,eAAA,CAEA,4BAAA,CADA,kBnBswCR,CmB/vCQ,2DACE,YnBiwCV,CmB5vCM,8CAGE,2CAAA,CADA,gCAAA,CADA,enBgwCR,CmB1vCM,yCAIE,aAAA,CAFA,UAAA,CAIA,YAAA,CADA,aAAA,CAJA,iBAAA,CACA,WAAA,CACA,SnB+vCR,CmBvvCI,+BACE,MnByvCN,CmBrvCI,+BACE,4DnBuvCN,CmBpvCM,qDACE,+BnBsvCR,CmBnvCQ,sHACE,+BnBqvCV,CmB/uCI,+BAEE,YAAA,CADA,mBnBkvCN,CmB9uCM,mCACE,enBgvCR,CmB5uCM,6CACE,SnB8uCR,CmB1uCM,uDAGE,mBnB6uCR,CmBhvCM,uDAGE,kBnB6uCR,CmBhvCM,6CAIE,gBAAA,CAFA,aAAA,CADA,YnB+uCR,CmBzuCQ,mDAKE,6BAAA,CADA,UAAA,CAHA,aAAA,CAEA,WAAA,CAGA,2CAAA,CAAA,mCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CAPA,UnBkvCV,CmBluCM,+CACE,mBnBouCR,CmB5tCM,4CAEE,wBAAA,CADA,enB+tCR,CmB3tCQ,oEACE,mBnB6tCV,CmB9tCQ,oEACE,oBnB6tCV,CmBztCQ,4EACE,iBnB2tCV,CmB5tCQ,4EACE,kBnB2tCV,CmBvtCQ,oFACE,mBnBytCV,CmB1tCQ,oFACE,oBnBytCV,CmBrtCQ,4FACE,mBnButCV,CmBxtCQ,4FACE,oBnButCV,CmBhtCE,mBACE,wBnBktCJ,CmB9sCE,wBACE,YAAA,CACA,SAAA,CAIA,0BAAA,CAHA,oEnBitCJ,CmB3sCI,kCACE,2BnB6sCN,CmBxsCE,gCACE,SAAA,CAIA,uBAAA,CAHA,qEnB2sCJ,CmBrsCI,8CAEE,kCAAA,CAAA,0BnBssCN,CACF,CKx4CI,0Cc0MA,0CACE,YnBisCJ,CmB9rCI,yDACE,UnBgsCN,CmB5rCI,wDACE,YnB8rCN,CmB1rCI,kDACE,YnB4rCN,CmBvrCE,gBAIE,iDAAA,CADA,gCAAA,CAFA,aAAA,CACA,enB2rCJ,CACF,CKr8CM,+DcmRF,6CACE,YnBqrCJ,CmBlrCI,4DACE,UnBorCN,CmBhrCI,2DACE,YnBkrCN,CmB9qCI,qDACE,YnBgrCN,CACF,CK77CI,mCc7JJ,QAgbI,oBnB8qCF,CmBxqCI,kCAME,qCAAA,CACA,qDAAA,CANA,eAAA,CACA,KAAA,CAGA,SnB0qCN,CmBrqCM,6CACE,uBnBuqCR,CmBnqCM,gDACE,YnBqqCR,CmBhqCI,2CACE,kBnBmqCN,CmBpqCI,2CACE,mBnBmqCN,CmBpqCI,iCAEE,oBnBkqCN,CmB3pCI,yDACE,kBnB6pCN,CmB9pCI,yDACE,iBnB6pCN,CACF,CKt9CI,sCc7JJ,QA4dI,oBAAA,CACA,oDnB2pCF,CmBrpCI,gCAME,qCAAA,CACA,qDAAA,CANA,eAAA,CACA,KAAA,CAGA,SnBupCN,CmBlpCM,8CACE,uBnBopCR,CmBhpCM,8CACE,YnBkpCR,CmB7oCI,yCACE,kBnBgpCN,CmBjpCI,yCACE,mBnBgpCN,CmBjpCI,+BAEE,oBnB+oCN,CmBxoCI,uDACE,kBnB0oCN,CmB3oCI,uDACE,iBnB0oCN,CmBroCE,wBACE,YAAA,CACA,sBAAA,CAEA,SAAA,CACA,6FACE,CAHF,mBnByoCJ,CmBjoCI,sCACE,enBmoCN,CmB9nCE,iFACE,sBAAA,CAEA,SAAA,CACA,4FACE,CAHF,kBnBkoCJ,CmBznCE,iDACE,enB2nCJ,CmBvnCE,6CACE,YnBynCJ,CmBrnCE,uBACE,aAAA,CACA,enBunCJ,CmBpnCI,kCACE,enBsnCN,CmBlnCI,qCACE,enBonCN,CmBjnCM,0CACE,uCnBmnCR,CmB/mCM,6DACE,mBnBinCR,CmB7mCM,yFAEE,YnB+mCR,CmB1mCI,yCAEE,kBnB8mCN,CmBhnCI,yCAEE,mBnB8mCN,CmBhnCI,+BACE,aAAA,CAGA,SAAA,CADA,kBnB6mCN,CmBzmCM,2DACE,SnB2mCR,CmBrmCE,cAGE,kBAAA,CADA,YAAA,CAEA,gCAAA,CAHA,WnB0mCJ,CmBpmCI,oBACE,uDnBsmCN,CmBlmCI,oBAME,6BAAA,CACA,kBAAA,CAFA,UAAA,CAJA,oBAAA,CAEA,WAAA,CAKA,2CAAA,CAAA,mCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CACA,yBAAA,CARA,qBAAA,CAFA,UnB8mCN,CmBjmCM,8BACE,wBnBmmCR,CmB/lCM,kKAEE,uBnBgmCR,CmBllCI,2EACE,YnBulCN,CmBplCM,oDACE,anBslCR,CmBnlCQ,kEAKE,qCAAA,CACA,qDAAA,CAFA,YAAA,CAHA,eAAA,CACA,KAAA,CACA,SnBwlCV,CmBllCU,0FACE,mBnBolCZ,CmB/kCQ,0EACE,QnBilCV,CmB5kCM,sFACE,kBnB8kCR,CmB/kCM,sFACE,mBnB8kCR,CmB1kCM,kDACE,uCnB4kCR,CmBtkCI,2CACE,sBAAA,CAEA,SAAA,CADA,kBnBykCN,CmBhkCI,qFAIE,mDnBmkCN,CmBvkCI,qFAIE,oDnBmkCN,CmBvkCI,2EACE,aAAA,CACA,oBAAA,CAGA,SAAA,CAFA,kBnBokCN,CmB/jCM,yFAEE,gBAAA,CADA,gBnBkkCR,CmB7jCM,0FACE,YnB+jCR,CACF,CoBtxDA,eAKE,eAAA,CACA,eAAA,CAJA,SpB6xDF,CoBtxDE,gCANA,kBAAA,CAFA,YAAA,CAGA,sBpBoyDF,CoB/xDE,iBAOE,mBAAA,CAFA,aAAA,CADA,gBAAA,CAEA,iBpByxDJ,CoBpxDE,wBAEE,qDAAA,CADA,uCpBuxDJ,CoBlxDE,qBACE,6CpBoxDJ,CoB/wDI,sDAEE,uDAAA,CADA,+BpBkxDN,CoB9wDM,8DACE,+BpBgxDR,CoB3wDI,mCACE,uCAAA,CACA,oBpB6wDN,CoBzwDI,yBAKE,iBAAA,CADA,yCAAA,CAHA,aAAA,CAEA,eAAA,CADA,YpB8wDN,CqB9zDE,eAGE,+DAAA,CADA,oBAAA,CADA,qBrBm0DJ,CK9oDI,0CgBtLF,eAOI,YrBi0DJ,CACF,CqB3zDM,6BACE,oBrB6zDR,CqBvzDE,kBACE,YAAA,CACA,qBAAA,CACA,SAAA,CACA,qBrByzDJ,CqBlzDI,0BACE,sBrBozDN,CqBjzDM,gEACE,+BrBmzDR,CqB7yDE,gBAEE,uCAAA,CADA,erBgzDJ,CqB3yDE,kBACE,oBrB6yDJ,CqB1yDI,mCAGE,kBAAA,CAFA,YAAA,CACA,SAAA,CAEA,iBrB4yDN,CqBxyDI,oCAIE,kBAAA,CAHA,mBAAA,CACA,kBAAA,CACA,SAAA,CAGA,QAAA,CADA,iBrB2yDN,CqBtyDI,0DACE,kBrBwyDN,CqBzyDI,0DACE,iBrBwyDN,CqBpyDI,iDACE,uBAAA,CAEA,YrBqyDN,CqBhyDE,4BACE,YrBkyDJ,CqB3xDA,YAGE,kBAAA,CAFA,YAAA,CAIA,eAAA,CAHA,SAAA,CAIA,eAAA,CAFA,UrBgyDF,CqB3xDE,yBACE,WrB6xDJ,CqBtxDA,kBACE,YrByxDF,CKjtDI,0CgBzEJ,kBAKI,wBrByxDF,CACF,CqBtxDE,qCACE,WrBwxDJ,CK5uDI,sCgB7CF,+CAKI,kBrBwxDJ,CqB7xDA,+CAKI,mBrBwxDJ,CACF,CK9tDI,0CgBrDJ,6BAMI,SAAA,CAFA,eAAA,CACA,UrBqxDF,CqBlxDE,qDACE,gBrBoxDJ,CqBjxDE,gDACE,SrBmxDJ,CqBhxDE,4CACE,iBAAA,CAAA,kBrBkxDJ,CqB/wDE,2CAEE,WAAA,CADA,crBkxDJ,CqB9wDE,2CACE,mBAAA,CACA,cAAA,CACA,SAAA,CACA,oBAAA,CAAA,iBrBgxDJ,CqB7wDE,2CACE,SrB+wDJ,CqB5wDE,qCAEE,WAAA,CACA,eAAA,CAFA,erBgxDJ,CACF,CsB17DA,MACE,qBAAA,CACA,yBtB67DF,CsBv7DA,aAME,qCAAA,CADA,cAAA,CAEA,0FACE,CAPF,cAAA,CACA,KAAA,CAaA,mDAAA,CACA,qBAAA,CAJA,wFACE,CATF,UAAA,CADA,StBi8DF,CuB58DA,MACE,mfvB+8DF,CuBz8DA,WACE,iBvB48DF,CK9yDI,mCkB/JJ,WAKI,evB48DF,CACF,CuBz8DE,kBACE,YvB28DJ,CuBv8DE,oBAEE,SAAA,CADA,SvB08DJ,CKvyDI,0CkBpKF,8BAOI,YvBk9DJ,CuBz9DA,8BAOI,avBk9DJ,CuBz9DA,oBAaI,2CAAA,CACA,kBAAA,CAJA,WAAA,CACA,eAAA,CACA,mBAAA,CANA,iBAAA,CAEA,SAAA,CAUA,uBAAA,CAHA,4CACE,CAPF,UvBg9DJ,CuBp8DI,+DACE,SAAA,CACA,oCvBs8DN,CACF,CK70DI,mCkBjJF,8BAgCI,MvBy8DJ,CuBz+DA,8BAgCI,OvBy8DJ,CuBz+DA,oBAqCI,0BAAA,CADA,cAAA,CADA,QAAA,CAJA,cAAA,CAEA,KAAA,CAKA,sDACE,CALF,OvBu8DJ,CuB77DI,+DAME,YAAA,CACA,SAAA,CACA,4CACE,CARF,UvBk8DN,CACF,CK50DI,0CkBxGA,+DAII,mBvBo7DN,CACF,CK13DM,+DkB/DF,+DASI,mBvBo7DN,CACF,CK/3DM,+DkB/DF,+DAcI,mBvBo7DN,CACF,CuB/6DE,kBAEE,kCAAA,CAAA,0BvBg7DJ,CK91DI,0CkBpFF,4BAOI,MvBw7DJ,CuB/7DA,4BAOI,OvBw7DJ,CuB/7DA,kBAWI,QAAA,CAEA,SAAA,CADA,eAAA,CANA,cAAA,CAEA,KAAA,CAWA,wBAAA,CALA,qGACE,CALF,OAAA,CADA,SvBs7DJ,CuBz6DI,4BACE,yBvB26DN,CuBv6DI,6DAEE,WAAA,CACA,SAAA,CAMA,uBAAA,CALA,sGACE,CAJF,UvB66DN,CACF,CKz4DI,mCkBjEF,4BA2CI,WvBu6DJ,CuBl9DA,4BA2CI,UvBu6DJ,CuBl9DA,kBA6CI,eAAA,CAHA,iBAAA,CAIA,8CAAA,CAFA,avBs6DJ,CACF,CKx6DM,+DkBOF,6DAII,avBi6DN,CACF,CKv5DI,sCkBfA,6DASI,avBi6DN,CACF,CuB55DE,iBAIE,2CAAA,CACA,0BAAA,CAFA,aAAA,CAFA,iBAAA,CAKA,2CACE,CALF,SvBk6DJ,CKp6DI,mCkBAF,iBAaI,0BAAA,CACA,mBAAA,CAFA,avB85DJ,CuBz5DI,uBACE,0BvB25DN,CACF,CuBv5DI,4DAEE,2CAAA,CACA,6BAAA,CACA,8BAAA,CAHA,gCvB45DN,CuBp5DE,4BAKE,mBAAA,CAAA,oBvBy5DJ,CuB95DE,4BAKE,mBAAA,CAAA,oBvBy5DJ,CuB95DE,kBAQE,gBAAA,CAFA,eAAA,CAFA,WAAA,CAHA,iBAAA,CAMA,sBAAA,CAJA,UAAA,CADA,SvB45DJ,CuBn5DI,+BACE,qBvBq5DN,CuBj5DI,kEAEE,uCvBk5DN,CuB94DI,6BACE,YvBg5DN,CKp7DI,0CkBaF,kBA8BI,eAAA,CADA,aAAA,CADA,UvBi5DJ,CACF,CK98DI,mCkBgCF,4BAmCI,mBvBi5DJ,CuBp7DA,4BAmCI,oBvBi5DJ,CuBp7DA,kBAqCI,aAAA,CADA,evBg5DJ,CuB54DI,+BACE,uCvB84DN,CuB14DI,mCACE,gCvB44DN,CuBx4DI,6DACE,kBvB04DN,CuBv4DM,8EACE,uCvBy4DR,CuBr4DM,0EACE,WvBu4DR,CACF,CuBj4DE,iBAIE,cAAA,CAHA,oBAAA,CAEA,aAAA,CAEA,kCACE,CAJF,YvBs4DJ,CuB93DI,uBACE,UvBg4DN,CuB53DI,yCAEE,UvBg4DN,CuBl4DI,yCAEE,WvBg4DN,CuBl4DI,+BACE,iBAAA,CAEA,SAAA,CACA,SvB83DN,CuB33DM,6CACE,oBvB63DR,CKp+DI,0CkB+FA,yCAaI,UvB63DN,CuB14DE,yCAaI,WvB63DN,CuB14DE,+BAcI,SvB43DN,CuBz3DM,+CACE,YvB23DR,CACF,CKhgEI,mCkBkHA,+BAwBI,mBvB03DN,CuBv3DM,8CACE,YvBy3DR,CACF,CuBn3DE,8BAEE,WvBw3DJ,CuB13DE,8BAEE,UvBw3DJ,CuB13DE,oBAKE,mBAAA,CAJA,iBAAA,CAEA,SAAA,CACA,SvBs3DJ,CK5/DI,0CkBkIF,8BASI,WvBs3DJ,CuB/3DA,8BASI,UvBs3DJ,CuB/3DA,oBAUI,SvBq3DJ,CACF,CuBl3DI,uCACE,iBvBw3DN,CuBz3DI,uCACE,kBvBw3DN,CuBz3DI,6BAEE,uCAAA,CACA,SAAA,CAIA,oBAAA,CAHA,+DvBq3DN,CuB/2DM,iDAEE,uCAAA,CADA,YvBk3DR,CuB72DM,gGAGE,SAAA,CADA,mBAAA,CAEA,kBvB82DR,CuB32DQ,sGACE,UvB62DV,CuBt2DE,8BAOE,mBAAA,CAAA,oBvB62DJ,CuBp3DE,8BAOE,mBAAA,CAAA,oBvB62DJ,CuBp3DE,oBAIE,kBAAA,CAKA,yCAAA,CANA,YAAA,CAKA,eAAA,CAFA,WAAA,CAKA,SAAA,CAVA,iBAAA,CACA,KAAA,CAUA,uBAAA,CAFA,kBAAA,CALA,UvB+2DJ,CKtjEI,mCkBkMF,8BAgBI,mBvBy2DJ,CuBz3DA,8BAgBI,oBvBy2DJ,CuBz3DA,oBAiBI,evBw2DJ,CACF,CuBr2DI,+DACE,SAAA,CACA,0BvBu2DN,CuBl2DE,6BAKE,+BvBq2DJ,CuB12DE,0DAME,gCvBo2DJ,CuB12DE,6BAME,+BvBo2DJ,CuB12DE,mBAIE,eAAA,CAHA,iBAAA,CAEA,UAAA,CADA,SvBw2DJ,CKrjEI,0CkB2MF,mBAWI,QAAA,CADA,UvBq2DJ,CACF,CK9kEI,mCkB8NF,mBAiBI,SAAA,CADA,UAAA,CAEA,sBvBo2DJ,CuBj2DI,8DACE,8BAAA,CACA,SvBm2DN,CACF,CuB91DE,uBASE,kCAAA,CAAA,0BAAA,CAFA,2CAAA,CANA,WAAA,CACA,eAAA,CAIA,kBvB+1DJ,CuBz1DI,iEAZF,uBAaI,uBvB41DJ,CACF,CK3nEM,+DkBiRJ,uBAkBI,avB41DJ,CACF,CK1mEI,sCkB2PF,uBAuBI,avB41DJ,CACF,CK/mEI,mCkB2PF,uBA4BI,YAAA,CACA,yDAAA,CACA,oBvB41DJ,CuBz1DI,kEACE,evB21DN,CuBv1DI,6BACE,+CvBy1DN,CuBr1DI,0CAEE,YAAA,CADA,WvBw1DN,CuBn1DI,gDACE,oDvBq1DN,CuBl1DM,sDACE,0CvBo1DR,CACF,CuB70DA,kBACE,gCAAA,CACA,qBvBg1DF,CuB70DE,wBAME,qDAAA,CAFA,uCAAA,CAFA,gBAAA,CACA,kBAAA,CAFA,eAAA,CAIA,uBvBg1DJ,CKnpEI,mCkB8TF,kCAUI,mBvB+0DJ,CuBz1DA,kCAUI,oBvB+0DJ,CACF,CuB30DE,wBAGE,eAAA,CADA,QAAA,CADA,SAAA,CAIA,wBAAA,CAAA,gBvB40DJ,CuBx0DE,wBACE,yDvB00DJ,CuBv0DI,oCACE,evBy0DN,CuBp0DE,wBACE,aAAA,CAEA,YAAA,CADA,uBAAA,CAEA,gCvBs0DJ,CuBn0DI,4DACE,uDvBq0DN,CuBj0DI,gDACE,mBvBm0DN,CuB9zDE,gCAKE,cAAA,CADA,aAAA,CAGA,YAAA,CANA,eAAA,CAKA,uBAAA,CAJA,KAAA,CACA,SvBo0DJ,CuB7zDI,wCACE,YvB+zDN,CuB1zDI,wDACE,YvB4zDN,CuBxzDI,oCAGE,+BAAA,CADA,gBAAA,CADA,mBAAA,CAGA,2CvB0zDN,CKrsEI,mCkBuYA,8CAUI,mBvBwzDN,CuBl0DE,8CAUI,oBvBwzDN,CACF,CuBpzDI,oFAEE,uDAAA,CADA,+BvBuzDN,CuBjzDE,sCACE,2CvBmzDJ,CuB9yDE,2BAGE,eAAA,CADA,eAAA,CADA,iBvBkzDJ,CKttEI,mCkBmaF,qCAOI,mBvBgzDJ,CuBvzDA,qCAOI,oBvBgzDJ,CACF,CuB5yDE,kCAEE,MvBkzDJ,CuBpzDE,kCAEE,OvBkzDJ,CuBpzDE,wBAME,uCAAA,CAFA,aAAA,CACA,YAAA,CAJA,iBAAA,CAEA,YvBizDJ,CKhtEI,0CkB4ZF,wBAUI,YvB8yDJ,CACF,CuB3yDI,8BAKE,6BAAA,CADA,UAAA,CAHA,oBAAA,CAEA,WAAA,CAGA,+CAAA,CAAA,uCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CAPA,UvBozDN,CuB1yDM,wCACE,oBvB4yDR,CuBtyDE,8BAGE,uCAAA,CAFA,gBAAA,CACA,evByyDJ,CuBryDI,iCAKE,gCAAA,CAHA,eAAA,CACA,eAAA,CACA,eAAA,CAHA,evB2yDN,CuBpyDM,sCACE,oBvBsyDR,CuBjyDI,iCAKE,gCAAA,CAHA,gBAAA,CACA,eAAA,CACA,eAAA,CAHA,avBuyDN,CuBhyDM,sCACE,oBvBkyDR,CuB5xDE,yBAKE,gCAAA,CAJA,aAAA,CAEA,gBAAA,CACA,iBAAA,CAFA,avBiyDJ,CuB1xDE,uBAGE,wBAAA,CAFA,+BAAA,CACA,yBvB6xDJ,CwBj8EA,WACE,iBAAA,CACA,SxBo8EF,CwBj8EE,kBAOE,2CAAA,CACA,mBAAA,CACA,8BAAA,CAHA,gCAAA,CAHA,QAAA,CAEA,gBAAA,CADA,YAAA,CAMA,SAAA,CATA,iBAAA,CACA,sBAAA,CAaA,mCAAA,CAJA,oExBo8EJ,CwB77EI,6EACE,gBAAA,CACA,SAAA,CAKA,+BAAA,CAJA,8ExBg8EN,CwBx7EI,wBAWE,+BAAA,CAAA,8CAAA,CAFA,6BAAA,CAAA,8BAAA,CACA,YAAA,CAFA,UAAA,CAHA,QAAA,CAFA,QAAA,CAIA,kBAAA,CADA,iBAAA,CALA,iBAAA,CACA,KAAA,CAEA,OxBi8EN,CwBr7EE,iBAOE,mBAAA,CAFA,eAAA,CACA,oBAAA,CAHA,QAAA,CAFA,kBAAA,CAGA,aAAA,CAFA,SxB47EJ,CwBn7EE,iBACE,kBxBq7EJ,CwBj7EE,2BAGE,kBAAA,CAAA,oBxBu7EJ,CwB17EE,2BAGE,mBAAA,CAAA,mBxBu7EJ,CwB17EE,iBAIE,cAAA,CAHA,aAAA,CAKA,YAAA,CADA,uBAAA,CAEA,2CACE,CANF,UxBw7EJ,CwB96EI,8CACE,+BxBg7EN,CwB56EI,uBACE,qDxB86EN,CyBlgFA,YAIE,qBAAA,CADA,aAAA,CAGA,gBAAA,CALA,eAAA,CACA,UAAA,CAGA,azBsgFF,CyBlgFE,aATF,YAUI,YzBqgFF,CACF,CKv1EI,0CoB3KF,+BAKI,azB0gFJ,CyB/gFA,+BAKI,czB0gFJ,CyB/gFA,qBAWI,2CAAA,CAHA,aAAA,CAEA,WAAA,CANA,cAAA,CAEA,KAAA,CASA,uBAAA,CAHA,iEACE,CAJF,aAAA,CAFA,SzBwgFJ,CyB7/EI,mEACE,8BAAA,CACA,6BzB+/EN,CyB5/EM,6EACE,8BzB8/ER,CyBz/EI,6CAEE,QAAA,CAAA,MAAA,CACA,QAAA,CACA,eAAA,CAHA,iBAAA,CACA,OAAA,CAGA,qBAAA,CAHA,KzB8/EN,CACF,CKt4EI,sCoBtKJ,YAuDI,QzBy/EF,CyBt/EE,mBACE,WzBw/EJ,CyBp/EE,6CACE,UzBs/EJ,CACF,CyBl/EE,uBACE,YAAA,CACA,OzBo/EJ,CKr5EI,mCoBjGF,uBAMI,QzBo/EJ,CyBj/EI,8BACE,WzBm/EN,CyB/+EI,qCACE,azBi/EN,CyB7+EI,+CACE,kBzB++EN,CACF,CyB1+EE,wBAIE,uBAAA,CAOA,kCAAA,CAAA,0BAAA,CAVA,cAAA,CACA,eAAA,CACA,yDAAA,CAMA,oBzBy+EJ,CyBp+EI,2CAEE,YAAA,CADA,WzBu+EN,CyBl+EI,mEACE,+CzBo+EN,CyBj+EM,qHACE,oDzBm+ER,CyBh+EQ,iIACE,0CzBk+EV,CyBn9EE,wCAGE,wBACE,qBzBm9EJ,CyB/8EE,6BACE,kCzBi9EJ,CyBl9EE,6BACE,iCzBi9EJ,CACF,CK76EI,0CoB5BF,YAME,0BAAA,CADA,QAAA,CAEA,SAAA,CANA,cAAA,CACA,KAAA,CAMA,sDACE,CALF,OAAA,CADA,SzBk9EF,CyBv8EE,4CAEE,WAAA,CACA,SAAA,CACA,4CACE,CAJF,UzB48EJ,CACF,C0BznFA,iBACE,GACE,Q1B2nFF,C0BxnFA,GACE,a1B0nFF,CACF,C0BtnFA,gBACE,GACE,SAAA,CACA,0B1BwnFF,C0BrnFA,IACE,S1BunFF,C0BpnFA,GACE,SAAA,CACA,uB1BsnFF,CACF,C0B9mFA,MACE,2eAAA,CACA,+fAAA,CACA,0lBAAA,CACA,kf1BgnFF,C0B1mFA,WAOE,kCAAA,CAAA,0BAAA,CANA,aAAA,CACA,gBAAA,CACA,eAAA,CAEA,uCAAA,CAGA,uBAAA,CAJA,kB1BgnFF,C0BzmFE,iBACE,U1B2mFJ,C0BvmFE,iBACE,oBAAA,CAEA,aAAA,CACA,qBAAA,CAFA,U1B2mFJ,C0BtmFI,+BACE,iB1BymFN,C0B1mFI,+BACE,kB1BymFN,C0B1mFI,qBAEE,gB1BwmFN,C0BpmFI,kDACE,iB1BumFN,C0BxmFI,kDACE,kB1BumFN,C0BxmFI,kDAEE,iB1BsmFN,C0BxmFI,kDAEE,kB1BsmFN,C0BjmFE,iCAGE,iB1BsmFJ,C0BzmFE,iCAGE,kB1BsmFJ,C0BzmFE,uBACE,oBAAA,CACA,6BAAA,CAEA,eAAA,CACA,sBAAA,CACA,qB1BmmFJ,C0B/lFE,kBACE,YAAA,CAMA,gBAAA,CALA,SAAA,CAMA,oBAAA,CAHA,gBAAA,CAIA,WAAA,CAHA,eAAA,CAFA,SAAA,CADA,U1BumFJ,C0B9lFI,iDACE,4B1BgmFN,C0B3lFE,iBACE,eAAA,CACA,sB1B6lFJ,C0B1lFI,gDACE,2B1B4lFN,C0BxlFI,kCAIE,kB1BgmFN,C0BpmFI,kCAIE,iB1BgmFN,C0BpmFI,wBAOE,6BAAA,CADA,UAAA,CALA,oBAAA,CAEA,YAAA,CAMA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CALA,uBAAA,CAHA,W1BkmFN,C0BtlFI,iCACE,a1BwlFN,C0BplFI,iCACE,gDAAA,CAAA,wC1BslFN,C0BllFI,+BACE,8CAAA,CAAA,sC1BolFN,C0BhlFI,+BACE,8CAAA,CAAA,sC1BklFN,C0B9kFI,sCACE,qDAAA,CAAA,6C1BglFN,C0B1kFA,gBACE,Y1B6kFF,C0B1kFE,gCAIE,kB1B8kFJ,C0BllFE,gCAIE,iB1B8kFJ,C0BllFE,sBAGE,kBAAA,CAGA,uCAAA,CALA,mBAAA,CAIA,gBAAA,CAHA,S1BglFJ,C0BzkFI,+BACE,aAAA,CACA,oB1B2kFN,C0BvkFI,2CACE,U1B0kFN,C0B3kFI,2CACE,W1B0kFN,C0B3kFI,iCAEE,kB1BykFN,C0BrkFI,0BACE,W1BukFN,C2B9vFA,MACE,iSAAA,CACA,4UAAA,CACA,+NAAA,CACA,gZ3BiwFF,C2BxvFE,iBAME,kDAAA,CADA,UAAA,CAJA,oBAAA,CAEA,cAAA,CAIA,mCAAA,CAAA,2BAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CANA,0BAAA,CAFA,a3BmwFJ,C2BvvFE,uBACE,6B3ByvFJ,C2BrvFE,sBACE,wCAAA,CAAA,gC3BuvFJ,C2BnvFE,6BACE,+CAAA,CAAA,uC3BqvFJ,C2BjvFE,4BACE,8CAAA,CAAA,sC3BmvFJ,C4B9xFA,SASE,2CAAA,CADA,gCAAA,CAJA,aAAA,CAGA,eAAA,CADA,aAAA,CADA,UAAA,CAFA,S5BqyFF,C4B5xFE,aAZF,SAaI,Y5B+xFF,CACF,CKpnFI,0CuBzLJ,SAkBI,Y5B+xFF,CACF,C4B5xFE,iBACE,mB5B8xFJ,C4B1xFE,yBAIE,iB5BiyFJ,C4BryFE,yBAIE,kB5BiyFJ,C4BryFE,eAQE,eAAA,CAPA,YAAA,CAMA,eAAA,CAJA,QAAA,CAEA,aAAA,CAHA,SAAA,CAWA,oBAAA,CAPA,kB5B+xFJ,C4BrxFI,kCACE,Y5BuxFN,C4BlxFE,eACE,aAAA,CACA,kBAAA,CAAA,mB5BoxFJ,C4BjxFI,sCACE,aAAA,CACA,S5BmxFN,C4B7wFE,eAOE,kCAAA,CAAA,0BAAA,CANA,YAAA,CAEA,eAAA,CADA,gBAAA,CAMA,UAAA,CAJA,uCAAA,CACA,oBAAA,CAIA,8D5B8wFJ,C4BzwFI,0CACE,aAAA,CACA,S5B2wFN,C4BvwFI,6BAEE,kB5B0wFN,C4B5wFI,6BAEE,iB5B0wFN,C4B5wFI,mBAGE,iBAAA,CAFA,Y5B2wFN,C4BpwFM,2CACE,qB5BswFR,C4BvwFM,2CACE,qB5BywFR,C4B1wFM,2CACE,qB5B4wFR,C4B7wFM,2CACE,qB5B+wFR,C4BhxFM,2CACE,oB5BkxFR,C4BnxFM,2CACE,qB5BqxFR,C4BtxFM,2CACE,qB5BwxFR,C4BzxFM,2CACE,qB5B2xFR,C4B5xFM,4CACE,qB5B8xFR,C4B/xFM,4CACE,oB5BiyFR,C4BlyFM,4CACE,qB5BoyFR,C4BryFM,4CACE,qB5BuyFR,C4BxyFM,4CACE,qB5B0yFR,C4B3yFM,4CACE,qB5B6yFR,C4B9yFM,4CACE,oB5BgzFR,C4B1yFI,gCACE,SAAA,CAIA,yBAAA,CAHA,wC5B6yFN,C6Bh5FA,MACE,mS7Bm5FF,C6B14FE,mCACE,mBAAA,CACA,cAAA,CACA,QAAA,CAEA,mBAAA,CADA,kB7B84FJ,C6Bz4FE,oBAGE,kBAAA,CAOA,+CAAA,CACA,oBAAA,CAVA,mBAAA,CAIA,gBAAA,CACA,0BAAA,CACA,eAAA,CALA,QAAA,CAOA,qBAAA,CADA,eAAA,CAJA,wB7Bk5FJ,C6Bx4FI,0BAGE,uCAAA,CAFA,aAAA,CACA,YAAA,CAEA,6C7B04FN,C6Br4FM,gEAEE,0CAAA,CADA,+B7Bw4FR,C6Bl4FI,yBACE,uB7Bo4FN,C6B53FI,gCAME,oDAAA,CADA,UAAA,CAJA,oBAAA,CAEA,YAAA,CAIA,qCAAA,CAAA,6BAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CACA,iCAAA,CAPA,0BAAA,CAFA,W7Bu4FN,C6B13FI,wFACE,0C7B43FN,C8Bt8FA,iBACE,GACE,oB9By8FF,C8Bt8FA,IACE,kB9Bw8FF,C8Br8FA,GACE,oB9Bu8FF,CACF,C8B/7FA,MACE,yNAAA,CACA,sP9Bk8FF,C8B37FA,YA6BE,kCAAA,CAAA,0BAAA,CAVA,2CAAA,CACA,mBAAA,CACA,8BAAA,CAHA,gCAAA,CADA,sCAAA,CAdA,+IACE,CAYF,8BAAA,CAMA,SAAA,CArBA,iBAAA,CACA,uBAAA,CAyBA,4BAAA,CAJA,uDACE,CATF,6BAAA,CADA,S9B+7FF,C8B76FE,oBAEE,SAAA,CAKA,uBAAA,CAJA,2EACE,CAHF,S9Bk7FJ,C8Bx6FE,oBAEE,eAAA,CACA,wBAAA,CAAA,gBAAA,CAFA,U9B46FJ,C8Bv6FI,6CACE,qC9By6FN,C8Br6FI,uCAEE,eAAA,CADA,mB9Bw6FN,C8Bl6FI,6BACE,Y9Bo6FN,C8B/5FE,8CACE,sC9Bi6FJ,C8B75FE,mBAEE,gBAAA,CADA,a9Bg6FJ,C8B55FI,2CACE,Y9B85FN,C8B15FI,0CACE,e9B45FN,C8Bp5FA,eACE,iBAAA,CACA,eAAA,CAIA,YAAA,CAHA,kBAAA,CAEA,0BAAA,CADA,kB9By5FF,C8Bp5FE,yBACE,a9Bs5FJ,C8Bl5FE,oBACE,sCAAA,CACA,iB9Bo5FJ,C8Bh5FE,6BACE,oBAAA,CAGA,gB9Bg5FJ,C8B54FE,sBAYE,mBAAA,CANA,cAAA,CAHA,oBAAA,CACA,gBAAA,CAAA,iBAAA,CAIA,YAAA,CAGA,eAAA,CAVA,iBAAA,CAMA,wBAAA,CAAA,gBAAA,CAFA,uBAAA,CAHA,S9Bs5FJ,C8Bx4FI,qCACE,uB9B04FN,C8Bt4FI,cArBF,sBAsBI,W9By4FJ,C8Bt4FI,wCACE,2B9Bw4FN,C8Bp4FI,6BAOE,qCAAA,CACA,+CAAA,CAAA,uC9By4FN,C8B/3FI,yDAZE,UAAA,CADA,YAAA,CAKA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CAVA,iBAAA,CACA,SAAA,CAEA,WAAA,CADA,U9B65FN,C8B94FI,4BAOE,oDAAA,CACA,4CAAA,CAAA,oCAAA,CAQA,uBAAA,CAJA,+C9Bk4FN,C8B33FM,gDACE,uB9B63FR,C8Bz3FM,mFACE,0C9B23FR,CACF,C8Bt3FI,0CAGE,2BAAA,CADA,uBAAA,CADA,S9B03FN,C8Bp3FI,8CACE,oB9Bs3FN,C8Bn3FM,aAJF,8CASI,8CAAA,CACA,iBAAA,CAHA,gCAAA,CADA,eAAA,CADA,cAAA,CAGA,kB9Bw3FN,C8Bn3FM,oDACE,mC9Bq3FR,CACF,C8Bz2FE,gCAEE,iBAAA,CADA,e9B62FJ,C8Bz2FI,mCACE,iB9B22FN,C8Bx2FM,oDAEE,a9Bu3FR,C8Bz3FM,oDAEE,c9Bu3FR,C8Bz3FM,0CAcE,8CAAA,CACA,iBAAA,CALA,gCAAA,CAEA,oBAAA,CACA,qBAAA,CANA,iBAAA,CACA,eAAA,CAHA,UAAA,CAIA,gBAAA,CALA,aAAA,CAEA,cAAA,CALA,iBAAA,CAUA,iBAAA,CARA,S9Bs3FR,C+BtoGA,MACE,wBAAA,CACA,wB/ByoGF,C+BnoGA,aA+BE,kCAAA,CAAA,0BAAA,CAjBA,gCAAA,CADA,sCAAA,CAGA,SAAA,CADA,mBAAA,CAdA,iBAAA,CAGA,wDACE,CAgBF,4BAAA,CAGA,uEACE,CARF,uDACE,CANF,UAAA,CADA,S/BuoGF,C+BhnGE,oBAuBE,8CAAA,CAAA,+CAAA,CADA,UAAA,CADA,aAAA,CAfA,gJACE,CANF,iBAAA,CAmBA,S/BomGJ,C+B7lGE,yBAGE,kEAAA,CAFA,gDAAA,CACA,6C/BgmGJ,C+B3lGE,4BAGE,qEAAA,CADA,8CAAA,CADA,6C/B+lGJ,C+BzlGE,qBAEE,SAAA,CAKA,uBAAA,CAJA,wEACE,CAHF,S/B8lGJ,C+BplGE,oBAqBE,uBAAA,CAEA,2CAAA,CACA,mBAAA,CACA,8BAAA,CAnBA,0FACE,CAaF,eAAA,CADA,8BAAA,CAlBA,iBAAA,CAqBA,oB/BykGJ,C+BnkGI,uCAEE,YAAA,CADA,W/BskGN,C+BjkGI,6CACE,oD/BmkGN,C+BhkGM,mDACE,0C/BkkGR,C+B1jGI,mCAwBE,eAAA,CACA,eAAA,CAxBA,oIACE,CAgBF,sCACE,CAIF,mBAAA,CAKA,wBAAA,CAAA,gBAAA,CAbA,sBAAA,CAAA,iB/BojGN,C+BniGI,4CACE,Y/BqiGN,C+BjiGI,2CACE,e/BmiGN,CgCttGA,kBAME,ehCkuGF,CgCxuGA,kBAME,gBhCkuGF,CgCxuGA,QAUE,2CAAA,CACA,oBAAA,CAEA,8BAAA,CALA,uCAAA,CACA,cAAA,CALA,aAAA,CAGA,eAAA,CAKA,YAAA,CAPA,mBAAA,CAJA,cAAA,CACA,UAAA,CAiBA,yBAAA,CALA,mGACE,CAZF,ShCquGF,CgCltGE,aAtBF,QAuBI,YhCqtGF,CACF,CgCltGE,kBACE,wBhCotGJ,CgChtGE,gBAEE,SAAA,CADA,mBAAA,CAGA,+BAAA,CADA,uBhCmtGJ,CgC/sGI,0BACE,8BhCitGN,CgC5sGE,4BAEE,0CAAA,CADA,+BhC+sGJ,CgC1sGE,YACE,oBAAA,CACA,oBhC4sGJ,CiCjwGA,oBACE,GACE,mBjCowGF,CACF,CiC5vGA,MACE,wfjC8vGF,CiCxvGA,YACE,aAAA,CAEA,eAAA,CADA,ajC4vGF,CiCxvGE,+BAOE,kBAAA,CAAA,kBjCyvGJ,CiChwGE,+BAOE,iBAAA,CAAA,mBjCyvGJ,CiChwGE,qBAQE,aAAA,CACA,cAAA,CACA,YAAA,CATA,iBAAA,CAKA,UjC0vGJ,CiCnvGI,qCAIE,iBjC2vGN,CiC/vGI,qCAIE,kBjC2vGN,CiC/vGI,2BAME,6BAAA,CADA,UAAA,CAJA,oBAAA,CAEA,YAAA,CAIA,yCAAA,CAAA,iCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CARA,WjC6vGN,CiChvGE,mBACE,iBAAA,CACA,UjCkvGJ,CiC9uGE,kBAWE,2CAAA,CACA,mBAAA,CACA,8BAAA,CALA,gCAAA,CACA,oBAAA,CAHA,kBAAA,CAFA,YAAA,CAUA,SAAA,CAPA,aAAA,CAFA,SAAA,CAJA,iBAAA,CASA,4BAAA,CARA,UAAA,CAaA,+CACE,CAbF,SjC4vGJ,CiC3uGI,+EACE,gBAAA,CACA,SAAA,CACA,sCjC6uGN,CiCvuGI,qCAEE,oCACE,gCjCwuGN,CiCpuGI,2CACE,cjCsuGN,CACF,CiCjuGE,kBACE,kBjCmuGJ,CiC/tGE,4BAGE,kBAAA,CAAA,oBjCsuGJ,CiCzuGE,4BAGE,mBAAA,CAAA,mBjCsuGJ,CiCzuGE,kBAKE,cAAA,CAJA,aAAA,CAMA,YAAA,CADA,uBAAA,CAEA,2CACE,CALF,kBAAA,CAFA,UjCuuGJ,CiC5tGI,gDACE,+BjC8tGN,CiC1tGI,wBACE,qDjC4tGN,CkCl0GA,MAEI,6VAAA,CAAA,uWAAA,CAAA,qPAAA,CAAA,2xBAAA,CAAA,qMAAA,CAAA,+aAAA,CAAA,2LAAA,CAAA,yPAAA,CAAA,2TAAA,CAAA,oaAAA,CAAA,2SAAA,CAAA,2LlC21GJ,CkC/0GE,4CAME,8CAAA,CACA,4BAAA,CACA,mBAAA,CACA,8BAAA,CAJA,mCAAA,CAJA,iBAAA,CAGA,gBAAA,CADA,iBAAA,CADA,eAAA,CASA,uBAAA,CADA,2BlCm1GJ,CkC/0GI,aAdF,4CAeI,elCk1GJ,CACF,CkC/0GI,sEACE,gClCi1GN,CkC50GI,gDACE,qBlC80GN,CkC10GI,gIAEE,iBAAA,CADA,clC60GN,CkCx0GI,4FACE,iBlC00GN,CkCt0GI,kFACE,elCw0GN,CkCp0GI,0FACE,YlCs0GN,CkCl0GI,8EACE,mBlCo0GN,CkC/zGE,sEAGE,iBAAA,CAAA,mBlCy0GJ,CkC50GE,sEAGE,kBAAA,CAAA,kBlCy0GJ,CkC50GE,sEASE,uBlCm0GJ,CkC50GE,sEASE,wBlCm0GJ,CkC50GE,sEAUE,4BlCk0GJ,CkC50GE,4IAWE,6BlCi0GJ,CkC50GE,sEAWE,4BlCi0GJ,CkC50GE,kDAOE,0BAAA,CACA,WAAA,CAFA,eAAA,CADA,eAAA,CAHA,oBAAA,CAAA,iBAAA,CADA,iBlC20GJ,CkC9zGI,kFACE,elCg0GN,CkC5zGI,oFAEE,UlCu0GN,CkCz0GI,oFAEE,WlCu0GN,CkCz0GI,gEAOE,wBhBiIU,CgBlIV,UAAA,CADA,WAAA,CAGA,kDAAA,CAAA,0CAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CAVA,iBAAA,CAEA,UAAA,CACA,UlCq0GN,CkC1zGI,4DACE,4DlC4zGN,CkC9yGE,sDACE,oBlCizGJ,CkC9yGI,gFACE,gClCgzGN,CkC3yGE,8DACE,0BlC8yGJ,CkC3yGI,4EACE,wBAlBG,CAmBH,kDAAA,CAAA,0ClC6yGN,CkCzyGI,0EACE,alC2yGN,CkCh0GE,8DACE,oBlCm0GJ,CkCh0GI,wFACE,gClCk0GN,CkC7zGE,sEACE,0BlCg0GJ,CkC7zGI,oFACE,wBAlBG,CAmBH,sDAAA,CAAA,8ClC+zGN,CkC3zGI,kFACE,alC6zGN,CkCl1GE,sDACE,oBlCq1GJ,CkCl1GI,gFACE,gClCo1GN,CkC/0GE,8DACE,0BlCk1GJ,CkC/0GI,4EACE,wBAlBG,CAmBH,kDAAA,CAAA,0ClCi1GN,CkC70GI,0EACE,alC+0GN,CkCp2GE,oDACE,oBlCu2GJ,CkCp2GI,8EACE,gClCs2GN,CkCj2GE,4DACE,0BlCo2GJ,CkCj2GI,0EACE,wBAlBG,CAmBH,iDAAA,CAAA,yClCm2GN,CkC/1GI,wEACE,alCi2GN,CkCt3GE,4DACE,oBlCy3GJ,CkCt3GI,sFACE,gClCw3GN,CkCn3GE,oEACE,0BlCs3GJ,CkCn3GI,kFACE,wBAlBG,CAmBH,qDAAA,CAAA,6ClCq3GN,CkCj3GI,gFACE,alCm3GN,CkCx4GE,8DACE,oBlC24GJ,CkCx4GI,wFACE,gClC04GN,CkCr4GE,sEACE,0BlCw4GJ,CkCr4GI,oFACE,wBAlBG,CAmBH,sDAAA,CAAA,8ClCu4GN,CkCn4GI,kFACE,alCq4GN,CkC15GE,4DACE,oBlC65GJ,CkC15GI,sFACE,gClC45GN,CkCv5GE,oEACE,0BlC05GJ,CkCv5GI,kFACE,wBAlBG,CAmBH,qDAAA,CAAA,6ClCy5GN,CkCr5GI,gFACE,alCu5GN,CkC56GE,4DACE,oBlC+6GJ,CkC56GI,sFACE,gClC86GN,CkCz6GE,oEACE,0BlC46GJ,CkCz6GI,kFACE,wBAlBG,CAmBH,qDAAA,CAAA,6ClC26GN,CkCv6GI,gFACE,alCy6GN,CkC97GE,0DACE,oBlCi8GJ,CkC97GI,oFACE,gClCg8GN,CkC37GE,kEACE,0BlC87GJ,CkC37GI,gFACE,wBAlBG,CAmBH,oDAAA,CAAA,4ClC67GN,CkCz7GI,8EACE,alC27GN,CkCh9GE,oDACE,oBlCm9GJ,CkCh9GI,8EACE,gClCk9GN,CkC78GE,4DACE,0BlCg9GJ,CkC78GI,0EACE,wBAlBG,CAmBH,iDAAA,CAAA,yClC+8GN,CkC38GI,wEACE,alC68GN,CkCl+GE,4DACE,oBlCq+GJ,CkCl+GI,sFACE,gClCo+GN,CkC/9GE,oEACE,0BlCk+GJ,CkC/9GI,kFACE,wBAlBG,CAmBH,qDAAA,CAAA,6ClCi+GN,CkC79GI,gFACE,alC+9GN,CkCp/GE,wDACE,oBlCu/GJ,CkCp/GI,kFACE,gClCs/GN,CkCj/GE,gEACE,0BlCo/GJ,CkCj/GI,8EACE,wBAlBG,CAmBH,mDAAA,CAAA,2ClCm/GN,CkC/+GI,4EACE,alCi/GN,CmCrpHA,MACE,qMnCwpHF,CmC/oHE,sBAEE,uCAAA,CADA,gBnCmpHJ,CmC/oHI,mCACE,anCipHN,CmClpHI,mCACE,cnCipHN,CmC7oHM,4BACE,sBnC+oHR,CmC5oHQ,mCACE,gCnC8oHV,CmC1oHQ,2DACE,SAAA,CAEA,uBAAA,CADA,enC6oHV,CmCxoHQ,yGACE,SAAA,CACA,uBnC0oHV,CmCtoHQ,yCACE,YnCwoHV,CmCjoHE,0BACE,eAAA,CACA,enCmoHJ,CmChoHI,+BACE,oBnCkoHN,CmC7nHE,gDACE,YnC+nHJ,CmC3nHE,8BAIE,+BAAA,CAHA,oBAAA,CAEA,WAAA,CAGA,SAAA,CAKA,4BAAA,CAJA,4DACE,CAHF,0BnC+nHJ,CmCtnHI,aAdF,8BAeI,+BAAA,CACA,SAAA,CACA,uBnCynHJ,CACF,CmCtnHI,wCACE,6BnCwnHN,CmCpnHI,oCACE,+BnCsnHN,CmClnHI,qCAKE,6BAAA,CADA,UAAA,CAHA,oBAAA,CAEA,YAAA,CAGA,2CAAA,CAAA,mCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CAPA,WnC2nHN,CmC9mHQ,mDACE,oBnCgnHV,CoC9tHE,kCAEE,iBpCouHJ,CoCtuHE,kCAEE,kBpCouHJ,CoCtuHE,wBAGE,yCAAA,CAFA,oBAAA,CAGA,SAAA,CACA,mCpCiuHJ,CoC5tHI,aAVF,wBAWI,YpC+tHJ,CACF,CoC3tHE,6FAEE,SAAA,CACA,mCpC6tHJ,CoCvtHE,4FAEE,+BpCytHJ,CoCrtHE,oBACE,yBAAA,CACA,uBAAA,CAGA,yEpCqtHJ,CKtlHI,sC+BrHE,qDACE,uBpC8sHN,CACF,CoCzsHE,kEACE,yBpC2sHJ,CoCvsHE,sBACE,0BpCysHJ,CqCpwHE,2BACE,arCuwHJ,CKllHI,0CgCtLF,2BAKI,erCuwHJ,CqCpwHI,6BACE,iBrCswHN,CACF,CqClwHI,6BAEE,0BAAA,CAAA,2BAAA,CADA,eAAA,CAEA,iBrCowHN,CqCjwHM,2CACE,kBrCmwHR,CqC7vHI,6CACE,QrC+vHN,CsC3xHE,uBACE,4CtC+xHJ,CsC1xHE,8CAJE,kCAAA,CAAA,0BtCkyHJ,CsC9xHE,uBACE,4CtC6xHJ,CsCxxHE,4BAEE,kCAAA,CAAA,0BAAA,CADA,qCtC2xHJ,CsCvxHI,mCACE,atCyxHN,CsCrxHI,kCACE,atCuxHN,CsClxHE,0BAKE,eAAA,CAJA,aAAA,CAEA,YAAA,CACA,aAAA,CAFA,kBAAA,CAAA,mBtCuxHJ,CsCjxHI,uCACE,etCmxHN,CsC/wHI,sCACE,kBtCixHN,CuC9zHA,MACE,oLvCi0HF,CuCxzHE,oBAGE,iBAAA,CAEA,gBAAA,CADA,avC0zHJ,CuCtzHI,wCACE,uBvCwzHN,CuCpzHI,gCAEE,eAAA,CADA,gBvCuzHN,CuChzHM,wCACE,mBvCkzHR,CuC5yHE,8BAKE,oBvCgzHJ,CuCrzHE,8BAKE,mBvCgzHJ,CuCrzHE,8BAUE,4BvC2yHJ,CuCrzHE,4DAWE,6BvC0yHJ,CuCrzHE,8BAWE,4BvC0yHJ,CuCrzHE,oBASE,cAAA,CANA,aAAA,CACA,eAAA,CAIA,evC6yHJ,CuCvyHI,kCACE,uCAAA,CACA,oBvCyyHN,CuCryHI,wCAEE,uCAAA,CADA,YvCwyHN,CuCnyHI,oCAEE,WvCgzHN,CuClzHI,oCAEE,UvCgzHN,CuClzHI,0BAOE,6BAAA,CADA,UAAA,CADA,WAAA,CAGA,yCAAA,CAAA,iCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CAVA,iBAAA,CAEA,UAAA,CAUA,sBAAA,CADA,yBAAA,CARA,UvC8yHN,CuClyHM,oCACE,wBvCoyHR,CuC/xHI,4BACE,YvCiyHN,CuC5xHI,4CACE,YvC8xHN,CwCx3HE,+DACE,sBAAA,CAEA,mBAAA,CACA,0BAAA,CACA,uBxC03HJ,CwCv3HI,2EAGE,iBAAA,CADA,eAAA,CADA,yBxC23HN,CwCp3HE,mEACE,0BxCs3HJ,CwCl3HE,oBACE,qBxCo3HJ,CwCh3HE,gBACE,oBxCk3HJ,CwC92HE,gBACE,qBxCg3HJ,CwC52HE,iBACE,kBxC82HJ,CwC12HE,kBACE,kBxC42HJ,CyCr5HE,6BACE,sCzCw5HJ,CyCr5HE,cACE,yCzCu5HJ,CyC34HE,sIACE,oCzC64HJ,CyCr4HE,2EACE,qCzCu4HJ,CyC73HE,wGACE,oCzC+3HJ,CyCt3HE,yFACE,qCzCw3HJ,CyCn3HE,6BACE,kCzCq3HJ,CyC/2HE,6CACE,sCzCi3HJ,CyC12HE,4DACE,sCzC42HJ,CyCr2HE,4DACE,qCzCu2HJ,CyC91HE,yFACE,qCzCg2HJ,CyCx1HE,2EACE,sCzC01HJ,CyC/0HE,wHACE,qCzCi1HJ,CyC50HE,8BAGE,mBAAA,CADA,gBAAA,CADA,gBzCg1HJ,CyC30HE,eACE,4CzC60HJ,CyC10HE,eACE,4CzC40HJ,CyCx0HE,gBAIE,+CAAA,CACA,kDAAA,CAJA,aAAA,CAEA,wBAAA,CADA,wBzC60HJ,CyCt0HE,yBAOE,wCAAA,CACA,+DAAA,CACA,4BAAA,CACA,6BAAA,CARA,iBAAA,CAGA,eAAA,CACA,eAAA,CAFA,cAAA,CADA,oCAAA,CAFA,iBzCi1HJ,CyCr0HI,6BACE,YzCu0HN,CyCp0HM,kCACE,wBAAA,CACA,yBzCs0HR,CyCh0HE,iCAaE,wCAAA,CACA,+DAAA,CAJA,uCAAA,CACA,0BAAA,CALA,UAAA,CAJA,oBAAA,CAOA,2BAAA,CADA,2BAAA,CADA,2BAAA,CANA,eAAA,CAWA,wBAAA,CAAA,gBAAA,CAPA,SzCy0HJ,CyCvzHE,sBACE,iBAAA,CACA,iBzCyzHJ,CyCpzHE,iCAKE,ezCkzHJ,CyC/yHI,sCACE,gBzCizHN,CyC7yHI,gDACE,YzC+yHN,CyCryHA,gBACE,iBzCwyHF,CyCpyHE,yCACE,aAAA,CACA,SzCsyHJ,CyCjyHE,mBACE,YzCmyHJ,CyC9xHE,oBACE,QzCgyHJ,CyC5xHE,4BACE,WAAA,CACA,SAAA,CACA,ezC8xHJ,CyC3xHI,0CACE,YzC6xHN,CyCvxHE,yBAKE,wCAAA,CAEA,+BAAA,CADA,4BAAA,CAHA,eAAA,CADA,oDAAA,CAEA,wBAAA,CAAA,gBzC4xHJ,CyCrxHE,2BAEE,+DAAA,CADA,2BzCwxHJ,CyCpxHI,+BACE,uCAAA,CACA,gBzCsxHN,CyCjxHE,sBACE,MAAA,CACA,WzCmxHJ,CyC9wHA,aACE,azCixHF,CyCvwHE,4BAEE,aAAA,CADA,YzC2wHJ,CyCvwHI,wDAEE,2BAAA,CADA,wBzC0wHN,CyCpwHE,+BAKE,2CAAA,CAEA,+BAAA,CADA,gCAAA,CADA,sBAAA,CAHA,mBAAA,CACA,gBAAA,CAFA,azC4wHJ,CyCnwHI,qCAEE,UAAA,CACA,UAAA,CAFA,azCuwHN,CK94HI,0CoCsJF,8BACE,iBzC4vHF,CyClvHE,wSAGE,ezCwvHJ,CyCpvHE,sCAEE,mBAAA,CACA,eAAA,CADA,oBAAA,CADA,kBAAA,CAAA,mBzCwvHJ,CACF,C0CrlII,yDAIE,+BAAA,CACA,8BAAA,CAFA,aAAA,CADA,QAAA,CADA,iB1C2lIN,C0CnlII,uBAEE,uCAAA,CADA,c1CslIN,C0CjiIM,iHAEE,WAlDkB,CAiDlB,kB1C4iIR,C0C7iIM,6HAEE,WAlDkB,CAiDlB,kB1CwjIR,C0CzjIM,6HAEE,WAlDkB,CAiDlB,kB1CokIR,C0CrkIM,oHAEE,WAlDkB,CAiDlB,kB1CglIR,C0CjlIM,0HAEE,WAlDkB,CAiDlB,kB1C4lIR,C0C7lIM,uHAEE,WAlDkB,CAiDlB,kB1CwmIR,C0CzmIM,uHAEE,WAlDkB,CAiDlB,kB1ConIR,C0CrnIM,6HAEE,WAlDkB,CAiDlB,kB1CgoIR,C0CjoIM,yCAEE,WAlDkB,CAiDlB,kB1CooIR,C0CroIM,yCAEE,WAlDkB,CAiDlB,kB1CwoIR,C0CzoIM,0CAEE,WAlDkB,CAiDlB,kB1C4oIR,C0C7oIM,uCAEE,WAlDkB,CAiDlB,kB1CgpIR,C0CjpIM,wCAEE,WAlDkB,CAiDlB,kB1CopIR,C0CrpIM,sCAEE,WAlDkB,CAiDlB,kB1CwpIR,C0CzpIM,wCAEE,WAlDkB,CAiDlB,kB1C4pIR,C0C7pIM,oCAEE,WAlDkB,CAiDlB,kB1CgqIR,C0CjqIM,2CAEE,WAlDkB,CAiDlB,kB1CoqIR,C0CrqIM,qCAEE,WAlDkB,CAiDlB,kB1CwqIR,C0CzqIM,oCAEE,WAlDkB,CAiDlB,kB1C4qIR,C0C7qIM,kCAEE,WAlDkB,CAiDlB,kB1CgrIR,C0CjrIM,qCAEE,WAlDkB,CAiDlB,kB1CorIR,C0CrrIM,mCAEE,WAlDkB,CAiDlB,kB1CwrIR,C0CzrIM,qCAEE,WAlDkB,CAiDlB,kB1C4rIR,C0C7rIM,wCAEE,WAlDkB,CAiDlB,kB1CgsIR,C0CjsIM,sCAEE,WAlDkB,CAiDlB,kB1CosIR,C0CrsIM,2CAEE,WAlDkB,CAiDlB,kB1CwsIR,C0C7rIM,iCAEE,WAPkB,CAMlB,iB1CgsIR,C0CjsIM,uCAEE,WAPkB,CAMlB,iB1CosIR,C0CrsIM,mCAEE,WAPkB,CAMlB,iB1CwsIR,C2C1xIA,MACE,2LAAA,CACA,yL3C6xIF,C2CpxIE,wBAKE,mBAAA,CAHA,YAAA,CACA,qBAAA,CACA,YAAA,CAHA,iB3C2xIJ,C2CjxII,8BAGE,QAAA,CACA,SAAA,CAHA,iBAAA,CACA,O3CqxIN,C2ChxIM,qCACE,0B3CkxIR,C2CrvIM,kEACE,0C3CuvIR,C2CjvIE,2BAME,uBAAA,CADA,+DAAA,CAJA,YAAA,CACA,cAAA,CACA,aAAA,CACA,oB3CqvIJ,C2ChvII,aATF,2BAUI,gB3CmvIJ,CACF,C2ChvII,cAGE,+BACE,iB3CgvIN,C2C7uIM,sCAQE,qCAAA,CANA,QAAA,CAKA,UAAA,CAHA,aAAA,CAEA,UAAA,CAHA,MAAA,CAFA,iBAAA,CAaA,2CAAA,CALA,2DACE,CAGF,kDAAA,CARA,+B3CqvIR,CACF,C2CvuII,8CACE,Y3CyuIN,C2CruII,iCAUE,+BAAA,CACA,6BAAA,CALA,uCAAA,CAEA,cAAA,CAPA,aAAA,CAGA,gBAAA,CACA,eAAA,CAFA,8BAAA,CAMA,+BAAA,CAGA,2CACE,CANF,kBAAA,CALA,U3CivIN,C2CluIM,aAII,6CACE,O3CiuIV,C2CluIQ,8CACE,O3CouIV,C2CruIQ,8CACE,O3CuuIV,C2CxuIQ,8CACE,O3C0uIV,C2C3uIQ,8CACE,O3C6uIV,C2C9uIQ,8CACE,O3CgvIV,C2CjvIQ,8CACE,O3CmvIV,C2CpvIQ,8CACE,O3CsvIV,C2CvvIQ,8CACE,O3CyvIV,C2C1vIQ,+CACE,Q3C4vIV,C2C7vIQ,+CACE,Q3C+vIV,C2ChwIQ,+CACE,Q3CkwIV,C2CnwIQ,+CACE,Q3CqwIV,C2CtwIQ,+CACE,Q3CwwIV,C2CzwIQ,+CACE,Q3C2wIV,C2C5wIQ,+CACE,Q3C8wIV,C2C/wIQ,+CACE,Q3CixIV,C2ClxIQ,+CACE,Q3CoxIV,C2CrxIQ,+CACE,Q3CuxIV,C2CxxIQ,+CACE,Q3C0xIV,CACF,C2CrxIM,uCACE,gC3CuxIR,C2CnxIM,oDACE,a3CqxIR,C2ChxII,yCACE,S3CkxIN,C2C9wIM,2CACE,aAAA,CACA,8B3CgxIR,C2C1wIE,4BACE,U3C4wIJ,C2CzwII,aAJF,4BAKI,gB3C4wIJ,CACF,C2CxwIE,0BACE,Y3C0wIJ,C2CvwII,aAJF,0BAKI,a3C0wIJ,C2CtwIM,sCACE,O3CwwIR,C2CzwIM,uCACE,O3C2wIR,C2C5wIM,uCACE,O3C8wIR,C2C/wIM,uCACE,O3CixIR,C2ClxIM,uCACE,O3CoxIR,C2CrxIM,uCACE,O3CuxIR,C2CxxIM,uCACE,O3C0xIR,C2C3xIM,uCACE,O3C6xIR,C2C9xIM,uCACE,O3CgyIR,C2CjyIM,wCACE,Q3CmyIR,C2CpyIM,wCACE,Q3CsyIR,C2CvyIM,wCACE,Q3CyyIR,C2C1yIM,wCACE,Q3C4yIR,C2C7yIM,wCACE,Q3C+yIR,C2ChzIM,wCACE,Q3CkzIR,C2CnzIM,wCACE,Q3CqzIR,C2CtzIM,wCACE,Q3CwzIR,C2CzzIM,wCACE,Q3C2zIR,C2C5zIM,wCACE,Q3C8zIR,C2C/zIM,wCACE,Q3Ci0IR,CACF,C2C3zII,+FAEE,Q3C6zIN,C2C1zIM,yGACE,wBAAA,CACA,yB3C6zIR,C2CpzIM,2DAEE,wBAAA,CACA,yBAAA,CAFA,Q3CwzIR,C2CjzIM,iEACE,Q3CmzIR,C2ChzIQ,qLAGE,wBAAA,CACA,yBAAA,CAFA,Q3CozIV,C2C9yIQ,6FACE,wBAAA,CACA,yB3CgzIV,C2C3yIM,yDACE,kB3C6yIR,C2CxyII,sCACE,Q3C0yIN,C2CryIE,2BAEE,iBAAA,CAOA,kBAAA,CAHA,uCAAA,CAEA,cAAA,CAPA,aAAA,CAGA,YAAA,CACA,gBAAA,CAEA,mBAAA,CAGA,gCAAA,CAPA,W3C8yIJ,C2CpyII,iCAEE,uDAAA,CADA,+B3CuyIN,C2ClyII,iCAKE,6BAAA,CADA,UAAA,CAHA,aAAA,CAEA,WAAA,CAGA,8CAAA,CAAA,sCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CACA,+CACE,CATF,U3C4yIN,C2C7xIE,4BAOE,yEACE,CANF,YAAA,CAGA,aAAA,CAFA,qBAAA,CAGA,mBAAA,CALA,iBAAA,CAYA,wBAAA,CATA,Y3CmyIJ,C2CvxII,sCACE,wB3CyxIN,C2CrxII,oCACE,S3CuxIN,C2CnxII,kCAGE,wEACE,CAFF,mBAAA,CADA,O3CuxIN,C2C7wIM,uDACE,8CAAA,CAAA,sC3C+wIR,CKt5II,0CsCqJF,wDAEE,kB3CuwIF,C2CzwIA,wDAEE,mB3CuwIF,C2CzwIA,8CAGE,eAAA,CAFA,eAAA,CAGA,iC3CqwIF,C2CjwIE,8DACE,mB3CowIJ,C2CrwIE,8DACE,kB3CowIJ,C2CrwIE,oDAEE,U3CmwIJ,C2C/vIE,8EAEE,kB3CkwIJ,C2CpwIE,8EAEE,mB3CkwIJ,C2CpwIE,8EAGE,kB3CiwIJ,C2CpwIE,8EAGE,mB3CiwIJ,C2CpwIE,oEACE,U3CmwIJ,C2C7vIE,8EAEE,mB3CgwIJ,C2ClwIE,8EAEE,kB3CgwIJ,C2ClwIE,8EAGE,mB3C+vIJ,C2ClwIE,8EAGE,kB3C+vIJ,C2ClwIE,oEACE,U3CiwIJ,CACF,C2CnvIE,cAHF,olDAII,gC3CsvIF,C2CnvIE,g8GACE,uC3CqvIJ,CACF,C2ChvIA,4sDACE,+B3CmvIF,C2C/uIA,wmDACE,a3CkvIF,C4CtnJA,MACE,qWAAA,CACA,8W5CynJF,C4ChnJE,4BAEE,oBAAA,CADA,iB5ConJJ,C4C/mJI,sDAEE,S5CknJN,C4CpnJI,sDAEE,U5CknJN,C4CpnJI,4CACE,iBAAA,CAEA,S5CinJN,C4C5mJE,+CAEE,SAAA,CADA,U5C+mJJ,C4C1mJE,kDAEE,W5CqnJJ,C4CvnJE,kDAEE,Y5CqnJJ,C4CvnJE,wCAOE,qDAAA,CADA,UAAA,CADA,aAAA,CAGA,0CAAA,CAAA,kCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CAVA,iBAAA,CAEA,SAAA,CACA,Y5CmnJJ,C4CxmJE,gEACE,wB1B2Wa,C0B1Wb,mDAAA,CAAA,2C5C0mJJ,C6C1pJA,aAQE,wBACE,Y7CypJF,CACF,C8CnqJA,QACE,8DAAA,CAGA,+CAAA,CACA,iEAAA,CACA,oDAAA,CACA,sDAAA,CACA,mDAAA,CAGA,qEAAA,CACA,qEAAA,CACA,wEAAA,CACA,0EAAA,CACA,wEAAA,CACA,yEAAA,CACA,kEAAA,CACA,+DAAA,CACA,oEAAA,CACA,oEAAA,CACA,mEAAA,CACA,gEAAA,CACA,uEAAA,CACA,mEAAA,CACA,qEAAA,CACA,oEAAA,CACA,gEAAA,CACA,wEAAA,CACA,qEAAA,CACA,+D9CiqJF,C8C3pJA,SAEE,kBAAA,CADA,Y9C+pJF,C+CjsJE,kBAUE,cAAA,CATA,YAAA,CACA,kEACE,CAQF,Y/C6rJJ,C+CzrJI,sDACE,gB/C2rJN,C+CrrJI,oFAKE,wDAAA,CACA,mBAAA,CAJA,aAAA,CAEA,QAAA,CADA,aAAA,CAIA,sC/CurJN,C+ClrJM,iOACE,kBAAA,CACA,8B/CqrJR,C+CjrJM,6FACE,iBAAA,CAAA,c/CorJR,C+ChrJM,2HACE,Y/CmrJR,C+C/qJM,wHACE,e/CkrJR,C+CnqJI,yMAGE,eAAA,CAAA,Y/C2qJN,C+C7pJI,ybAOE,W/CmqJN,C+C/pJI,8BACE,eAAA,CAAA,Y/CiqJN,CK7lJI,mC2ChKA,8BACE,UhDqwJJ,CgDtwJE,8BACE,WhDqwJJ,CgDtwJE,8BAGE,kBhDmwJJ,CgDtwJE,8BAGE,iBhDmwJJ,CgDtwJE,oBAKE,mBAAA,CADA,YAAA,CAFA,ahDowJJ,CgD9vJI,kCACE,WhDiwJN,CgDlwJI,kCACE,UhDiwJN,CgDlwJI,kCAEE,iBAAA,CAAA,chDgwJN,CgDlwJI,kCAEE,aAAA,CAAA,kBhDgwJN,CACF","file":"main.css"}
\ No newline at end of file
diff --git a/main/assets/stylesheets/main.8c3ca2c6.min.css b/main/assets/stylesheets/main.8c3ca2c6.min.css
deleted file mode 100644
index 57a79c121..000000000
--- a/main/assets/stylesheets/main.8c3ca2c6.min.css
+++ /dev/null
@@ -1 +0,0 @@
-@charset "UTF-8";html{-webkit-text-size-adjust:none;-moz-text-size-adjust:none;text-size-adjust:none;box-sizing:border-box}*,:after,:before{box-sizing:inherit}@media (prefers-reduced-motion){*,:after,:before{transition:none!important}}body{margin:0}a,button,input,label{-webkit-tap-highlight-color:transparent}a{color:inherit;text-decoration:none}hr{border:0;box-sizing:initial;display:block;height:.05rem;overflow:visible;padding:0}small{font-size:80%}sub,sup{line-height:1em}img{border-style:none}table{border-collapse:initial;border-spacing:0}td,th{font-weight:400;vertical-align:top}button{background:#0000;border:0;font-family:inherit;font-size:inherit;margin:0;padding:0}input{border:0;outline:none}:root{--md-primary-fg-color:#4051b5;--md-primary-fg-color--light:#5d6cc0;--md-primary-fg-color--dark:#303fa1;--md-primary-bg-color:#fff;--md-primary-bg-color--light:#ffffffb3;--md-accent-fg-color:#526cfe;--md-accent-fg-color--transparent:#526cfe1a;--md-accent-bg-color:#fff;--md-accent-bg-color--light:#ffffffb3}[data-md-color-scheme=default]{color-scheme:light}[data-md-color-scheme=default] img[src$="#gh-dark-mode-only"],[data-md-color-scheme=default] img[src$="#only-dark"]{display:none}:root,[data-md-color-scheme=default]{--md-hue:225deg;--md-default-fg-color:#000000de;--md-default-fg-color--light:#0000008a;--md-default-fg-color--lighter:#00000052;--md-default-fg-color--lightest:#00000012;--md-default-bg-color:#fff;--md-default-bg-color--light:#ffffffb3;--md-default-bg-color--lighter:#ffffff4d;--md-default-bg-color--lightest:#ffffff1f;--md-code-fg-color:#36464e;--md-code-bg-color:#f5f5f5;--md-code-hl-color:#4287ff;--md-code-hl-color--light:#4287ff1a;--md-code-hl-number-color:#d52a2a;--md-code-hl-special-color:#db1457;--md-code-hl-function-color:#a846b9;--md-code-hl-constant-color:#6e59d9;--md-code-hl-keyword-color:#3f6ec6;--md-code-hl-string-color:#1c7d4d;--md-code-hl-name-color:var(--md-code-fg-color);--md-code-hl-operator-color:var(--md-default-fg-color--light);--md-code-hl-punctuation-color:var(--md-default-fg-color--light);--md-code-hl-comment-color:var(--md-default-fg-color--light);--md-code-hl-generic-color:var(--md-default-fg-color--light);--md-code-hl-variable-color:var(--md-default-fg-color--light);--md-typeset-color:var(--md-default-fg-color);--md-typeset-a-color:var(--md-primary-fg-color);--md-typeset-del-color:#f5503d26;--md-typeset-ins-color:#0bd57026;--md-typeset-kbd-color:#fafafa;--md-typeset-kbd-accent-color:#fff;--md-typeset-kbd-border-color:#b8b8b8;--md-typeset-mark-color:#ffff0080;--md-typeset-table-color:#0000001f;--md-typeset-table-color--light:rgba(0,0,0,.035);--md-admonition-fg-color:var(--md-default-fg-color);--md-admonition-bg-color:var(--md-default-bg-color);--md-warning-fg-color:#000000de;--md-warning-bg-color:#ff9;--md-footer-fg-color:#fff;--md-footer-fg-color--light:#ffffffb3;--md-footer-fg-color--lighter:#ffffff73;--md-footer-bg-color:#000000de;--md-footer-bg-color--dark:#00000052;--md-shadow-z1:0 0.2rem 0.5rem #0000000d,0 0 0.05rem #0000001a;--md-shadow-z2:0 0.2rem 0.5rem #0000001a,0 0 0.05rem #00000040;--md-shadow-z3:0 0.2rem 0.5rem #0003,0 0 0.05rem #00000059}.md-icon svg{fill:currentcolor;display:block;height:1.2rem;width:1.2rem}body{-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale;--md-text-font-family:var(--md-text-font,_),-apple-system,BlinkMacSystemFont,Helvetica,Arial,sans-serif;--md-code-font-family:var(--md-code-font,_),SFMono-Regular,Consolas,Menlo,monospace}aside,body,input{font-feature-settings:"kern","liga";color:var(--md-typeset-color);font-family:var(--md-text-font-family)}code,kbd,pre{font-feature-settings:"kern";font-family:var(--md-code-font-family)}:root{--md-typeset-table-sort-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="m18 21-4-4h3V7h-3l4-4 4 4h-3v10h3M2 19v-2h10v2M2 13v-2h7v2M2 7V5h4v2z"/></svg>');--md-typeset-table-sort-icon--asc:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M19 17h3l-4 4-4-4h3V3h2M2 17h10v2H2M6 5v2H2V5m0 6h7v2H2z"/></svg>');--md-typeset-table-sort-icon--desc:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M19 7h3l-4-4-4 4h3v14h2M2 17h10v2H2M6 5v2H2V5m0 6h7v2H2z"/></svg>')}.md-typeset{-webkit-print-color-adjust:exact;color-adjust:exact;font-size:.8rem;line-height:1.6}@media print{.md-typeset{font-size:.68rem}}.md-typeset blockquote,.md-typeset dl,.md-typeset figure,.md-typeset ol,.md-typeset pre,.md-typeset ul{margin-bottom:1em;margin-top:1em}.md-typeset h1{color:var(--md-default-fg-color--light);font-size:2em;line-height:1.3;margin:0 0 1.25em}.md-typeset h1,.md-typeset h2{font-weight:300;letter-spacing:-.01em}.md-typeset h2{font-size:1.5625em;line-height:1.4;margin:1.6em 0 .64em}.md-typeset h3{font-size:1.25em;font-weight:400;letter-spacing:-.01em;line-height:1.5;margin:1.6em 0 .8em}.md-typeset h2+h3{margin-top:.8em}.md-typeset h4{font-weight:700;letter-spacing:-.01em;margin:1em 0}.md-typeset h5,.md-typeset h6{color:var(--md-default-fg-color--light);font-size:.8em;font-weight:700;letter-spacing:-.01em;margin:1.25em 0}.md-typeset h5{text-transform:uppercase}.md-typeset hr{border-bottom:.05rem solid var(--md-default-fg-color--lightest);display:flow-root;margin:1.5em 0}.md-typeset a{color:var(--md-typeset-a-color);word-break:break-word}.md-typeset a,.md-typeset a:before{transition:color 125ms}.md-typeset a:focus,.md-typeset a:hover{color:var(--md-accent-fg-color)}.md-typeset a:focus code,.md-typeset a:hover code{background-color:var(--md-accent-fg-color--transparent)}.md-typeset a code{color:currentcolor;transition:background-color 125ms}.md-typeset a.focus-visible{outline-color:var(--md-accent-fg-color);outline-offset:.2rem}.md-typeset code,.md-typeset kbd,.md-typeset pre{color:var(--md-code-fg-color);direction:ltr;font-variant-ligatures:none}@media print{.md-typeset code,.md-typeset kbd,.md-typeset pre{white-space:pre-wrap}}.md-typeset code{background-color:var(--md-code-bg-color);border-radius:.1rem;-webkit-box-decoration-break:clone;box-decoration-break:clone;font-size:.85em;padding:0 .2941176471em;word-break:break-word}.md-typeset code:not(.focus-visible){-webkit-tap-highlight-color:transparent;outline:none}.md-typeset pre{display:flow-root;line-height:1.4;position:relative}.md-typeset pre>code{-webkit-box-decoration-break:slice;box-decoration-break:slice;box-shadow:none;display:block;margin:0;outline-color:var(--md-accent-fg-color);overflow:auto;padding:.7720588235em 1.1764705882em;scrollbar-color:var(--md-default-fg-color--lighter) #0000;scrollbar-width:thin;touch-action:auto;word-break:normal}.md-typeset pre>code:hover{scrollbar-color:var(--md-accent-fg-color) #0000}.md-typeset pre>code::-webkit-scrollbar{height:.2rem;width:.2rem}.md-typeset pre>code::-webkit-scrollbar-thumb{background-color:var(--md-default-fg-color--lighter)}.md-typeset pre>code::-webkit-scrollbar-thumb:hover{background-color:var(--md-accent-fg-color)}.md-typeset kbd{background-color:var(--md-typeset-kbd-color);border-radius:.1rem;box-shadow:0 .1rem 0 .05rem var(--md-typeset-kbd-border-color),0 .1rem 0 var(--md-typeset-kbd-border-color),0 -.1rem .2rem var(--md-typeset-kbd-accent-color) inset;color:var(--md-default-fg-color);display:inline-block;font-size:.75em;padding:0 .6666666667em;vertical-align:text-top;word-break:break-word}.md-typeset mark{background-color:var(--md-typeset-mark-color);-webkit-box-decoration-break:clone;box-decoration-break:clone;color:inherit;word-break:break-word}.md-typeset abbr{border-bottom:.05rem dotted var(--md-default-fg-color--light);cursor:help;text-decoration:none}.md-typeset small{opacity:.75}[dir=ltr] .md-typeset sub,[dir=ltr] .md-typeset sup{margin-left:.078125em}[dir=rtl] .md-typeset sub,[dir=rtl] .md-typeset sup{margin-right:.078125em}[dir=ltr] .md-typeset blockquote{padding-left:.6rem}[dir=rtl] .md-typeset blockquote{padding-right:.6rem}[dir=ltr] .md-typeset blockquote{border-left:.2rem solid var(--md-default-fg-color--lighter)}[dir=rtl] .md-typeset blockquote{border-right:.2rem solid var(--md-default-fg-color--lighter)}.md-typeset blockquote{color:var(--md-default-fg-color--light);margin-left:0;margin-right:0}.md-typeset ul{list-style-type:disc}.md-typeset ul[type]{list-style-type:revert-layer}[dir=ltr] .md-typeset ol,[dir=ltr] .md-typeset ul{margin-left:.625em}[dir=rtl] .md-typeset ol,[dir=rtl] .md-typeset ul{margin-right:.625em}.md-typeset ol,.md-typeset ul{padding:0}.md-typeset ol:not([hidden]),.md-typeset ul:not([hidden]){display:flow-root}.md-typeset ol ol,.md-typeset ul ol{list-style-type:lower-alpha}.md-typeset ol ol ol,.md-typeset ul ol ol{list-style-type:lower-roman}.md-typeset ol ol ol ol,.md-typeset ul ol ol ol{list-style-type:upper-alpha}.md-typeset ol ol ol ol ol,.md-typeset ul ol ol ol ol{list-style-type:upper-roman}.md-typeset ol[type],.md-typeset ul[type]{list-style-type:revert-layer}[dir=ltr] .md-typeset ol li,[dir=ltr] .md-typeset ul li{margin-left:1.25em}[dir=rtl] .md-typeset ol li,[dir=rtl] .md-typeset ul li{margin-right:1.25em}.md-typeset ol li,.md-typeset ul li{margin-bottom:.5em}.md-typeset ol li blockquote,.md-typeset ol li p,.md-typeset ul li blockquote,.md-typeset ul li p{margin:.5em 0}.md-typeset ol li:last-child,.md-typeset ul li:last-child{margin-bottom:0}[dir=ltr] .md-typeset ol li ol,[dir=ltr] .md-typeset ol li ul,[dir=ltr] .md-typeset ul li ol,[dir=ltr] .md-typeset ul li ul{margin-left:.625em}[dir=rtl] .md-typeset ol li ol,[dir=rtl] .md-typeset ol li ul,[dir=rtl] .md-typeset ul li ol,[dir=rtl] .md-typeset ul li ul{margin-right:.625em}.md-typeset ol li ol,.md-typeset ol li ul,.md-typeset ul li ol,.md-typeset ul li ul{margin-bottom:.5em;margin-top:.5em}[dir=ltr] .md-typeset dd{margin-left:1.875em}[dir=rtl] .md-typeset dd{margin-right:1.875em}.md-typeset dd{margin-bottom:1.5em;margin-top:1em}.md-typeset img,.md-typeset svg,.md-typeset video{height:auto;max-width:100%}.md-typeset img[align=left]{margin:1em 1em 1em 0}.md-typeset img[align=right]{margin:1em 0 1em 1em}.md-typeset img[align]:only-child{margin-top:0}.md-typeset figure{display:flow-root;margin:1em auto;max-width:100%;text-align:center;width:-moz-fit-content;width:fit-content}.md-typeset figure img{display:block;margin:0 auto}.md-typeset figcaption{font-style:italic;margin:1em auto;max-width:24rem}.md-typeset iframe{max-width:100%}.md-typeset table:not([class]){background-color:var(--md-default-bg-color);border:.05rem solid var(--md-typeset-table-color);border-radius:.1rem;display:inline-block;font-size:.64rem;max-width:100%;overflow:auto;touch-action:auto}@media print{.md-typeset table:not([class]){display:table}}.md-typeset table:not([class])+*{margin-top:1.5em}.md-typeset table:not([class]) td>:first-child,.md-typeset table:not([class]) th>:first-child{margin-top:0}.md-typeset table:not([class]) td>:last-child,.md-typeset table:not([class]) th>:last-child{margin-bottom:0}.md-typeset table:not([class]) td:not([align]),.md-typeset table:not([class]) th:not([align]){text-align:left}[dir=rtl] .md-typeset table:not([class]) td:not([align]),[dir=rtl] .md-typeset table:not([class]) th:not([align]){text-align:right}.md-typeset table:not([class]) th{font-weight:700;min-width:5rem;padding:.9375em 1.25em;vertical-align:top}.md-typeset table:not([class]) td{border-top:.05rem solid var(--md-typeset-table-color);padding:.9375em 1.25em;vertical-align:top}.md-typeset table:not([class]) tbody tr{transition:background-color 125ms}.md-typeset table:not([class]) tbody tr:hover{background-color:var(--md-typeset-table-color--light);box-shadow:0 .05rem 0 var(--md-default-bg-color) inset}.md-typeset table:not([class]) a{word-break:normal}.md-typeset table th[role=columnheader]{cursor:pointer}[dir=ltr] .md-typeset table th[role=columnheader]:after{margin-left:.5em}[dir=rtl] .md-typeset table th[role=columnheader]:after{margin-right:.5em}.md-typeset table th[role=columnheader]:after{content:"";display:inline-block;height:1.2em;-webkit-mask-image:var(--md-typeset-table-sort-icon);mask-image:var(--md-typeset-table-sort-icon);-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;transition:background-color 125ms;vertical-align:text-bottom;width:1.2em}.md-typeset table th[role=columnheader]:hover:after{background-color:var(--md-default-fg-color--lighter)}.md-typeset table th[role=columnheader][aria-sort=ascending]:after{background-color:var(--md-default-fg-color--light);-webkit-mask-image:var(--md-typeset-table-sort-icon--asc);mask-image:var(--md-typeset-table-sort-icon--asc)}.md-typeset table th[role=columnheader][aria-sort=descending]:after{background-color:var(--md-default-fg-color--light);-webkit-mask-image:var(--md-typeset-table-sort-icon--desc);mask-image:var(--md-typeset-table-sort-icon--desc)}.md-typeset__scrollwrap{margin:1em -.8rem;overflow-x:auto;touch-action:auto}.md-typeset__table{display:inline-block;margin-bottom:.5em;padding:0 .8rem}@media print{.md-typeset__table{display:block}}html .md-typeset__table table{display:table;margin:0;overflow:hidden;width:100%}@media screen and (max-width:44.984375em){.md-content__inner>pre{margin:1em -.8rem}.md-content__inner>pre code{border-radius:0}}.md-typeset .md-author{border-radius:100%;display:block;flex-shrink:0;height:1.6rem;overflow:hidden;position:relative;transition:color 125ms,transform 125ms;width:1.6rem}.md-typeset .md-author img{display:block}.md-typeset .md-author--more{background:var(--md-default-fg-color--lightest);color:var(--md-default-fg-color--lighter);font-size:.6rem;font-weight:700;line-height:1.6rem;text-align:center}.md-typeset .md-author--long{height:2.4rem;width:2.4rem}.md-typeset a.md-author{transform:scale(1)}.md-typeset a.md-author img{border-radius:100%;filter:grayscale(100%) opacity(75%);transition:filter 125ms}.md-typeset a.md-author:focus,.md-typeset a.md-author:hover{transform:scale(1.1);z-index:1}.md-typeset a.md-author:focus img,.md-typeset a.md-author:hover img{filter:grayscale(0)}.md-banner{background-color:var(--md-footer-bg-color);color:var(--md-footer-fg-color);overflow:auto}@media print{.md-banner{display:none}}.md-banner--warning{background-color:var(--md-warning-bg-color);color:var(--md-warning-fg-color)}.md-banner__inner{font-size:.7rem;margin:.6rem auto;padding:0 .8rem}[dir=ltr] .md-banner__button{float:right}[dir=rtl] .md-banner__button{float:left}.md-banner__button{color:inherit;cursor:pointer;transition:opacity .25s}.no-js .md-banner__button{display:none}.md-banner__button:hover{opacity:.7}html{font-size:125%;height:100%;overflow-x:hidden}@media screen and (min-width:100em){html{font-size:137.5%}}@media screen and (min-width:125em){html{font-size:150%}}body{background-color:var(--md-default-bg-color);display:flex;flex-direction:column;font-size:.5rem;min-height:100%;position:relative;width:100%}@media print{body{display:block}}@media screen and (max-width:59.984375em){body[data-md-scrolllock]{position:fixed}}.md-grid{margin-left:auto;margin-right:auto;max-width:61rem}.md-container{display:flex;flex-direction:column;flex-grow:1}@media print{.md-container{display:block}}.md-main{flex-grow:1}.md-main__inner{display:flex;height:100%;margin-top:1.5rem}.md-ellipsis{overflow:hidden;text-overflow:ellipsis}.md-toggle{display:none}.md-option{height:0;opacity:0;position:absolute;width:0}.md-option:checked+label:not([hidden]){display:block}.md-option.focus-visible+label{outline-color:var(--md-accent-fg-color);outline-style:auto}.md-skip{background-color:var(--md-default-fg-color);border-radius:.1rem;color:var(--md-default-bg-color);font-size:.64rem;margin:.5rem;opacity:0;outline-color:var(--md-accent-fg-color);padding:.3rem .5rem;position:fixed;transform:translateY(.4rem);z-index:-1}.md-skip:focus{opacity:1;transform:translateY(0);transition:transform .25s cubic-bezier(.4,0,.2,1),opacity 175ms 75ms;z-index:10}@page{margin:25mm}:root{--md-clipboard-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M19 21H8V7h11m0-2H8a2 2 0 0 0-2 2v14a2 2 0 0 0 2 2h11a2 2 0 0 0 2-2V7a2 2 0 0 0-2-2m-3-4H4a2 2 0 0 0-2 2v14h2V3h12z"/></svg>')}.md-clipboard{border-radius:.1rem;color:var(--md-default-fg-color--lightest);cursor:pointer;height:1.5em;outline-color:var(--md-accent-fg-color);outline-offset:.1rem;position:absolute;right:.5em;top:.5em;transition:color .25s;width:1.5em;z-index:1}@media print{.md-clipboard{display:none}}.md-clipboard:not(.focus-visible){-webkit-tap-highlight-color:transparent;outline:none}:hover>.md-clipboard{color:var(--md-default-fg-color--light)}.md-clipboard:focus,.md-clipboard:hover{color:var(--md-accent-fg-color)}.md-clipboard:after{background-color:currentcolor;content:"";display:block;height:1.125em;margin:0 auto;-webkit-mask-image:var(--md-clipboard-icon);mask-image:var(--md-clipboard-icon);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;width:1.125em}.md-clipboard--inline{cursor:pointer}.md-clipboard--inline code{transition:color .25s,background-color .25s}.md-clipboard--inline:focus code,.md-clipboard--inline:hover code{background-color:var(--md-accent-fg-color--transparent);color:var(--md-accent-fg-color)}.md-typeset .md-code__content{display:grid}@keyframes consent{0%{opacity:0;transform:translateY(100%)}to{opacity:1;transform:translateY(0)}}@keyframes overlay{0%{opacity:0}to{opacity:1}}.md-consent__overlay{animation:overlay .25s both;-webkit-backdrop-filter:blur(.1rem);backdrop-filter:blur(.1rem);background-color:#0000008a;height:100%;opacity:1;position:fixed;top:0;width:100%;z-index:5}.md-consent__inner{animation:consent .5s cubic-bezier(.1,.7,.1,1) both;background-color:var(--md-default-bg-color);border:0;border-radius:.1rem;bottom:0;box-shadow:0 0 .2rem #0000001a,0 .2rem .4rem #0003;max-height:100%;overflow:auto;padding:0;position:fixed;width:100%;z-index:5}.md-consent__form{padding:.8rem}.md-consent__settings{display:none;margin:1em 0}input:checked+.md-consent__settings{display:block}.md-consent__controls{margin-bottom:.8rem}.md-typeset .md-consent__controls .md-button{display:inline}@media screen and (max-width:44.984375em){.md-typeset .md-consent__controls .md-button{display:block;margin-top:.4rem;text-align:center;width:100%}}.md-consent label{cursor:pointer}.md-content{flex-grow:1;min-width:0}.md-content__inner{margin:0 .8rem 1.2rem;padding-top:.6rem}@media screen and (min-width:76.25em){[dir=ltr] .md-sidebar--primary:not([hidden])~.md-content>.md-content__inner{margin-left:1.2rem}[dir=ltr] .md-sidebar--secondary:not([hidden])~.md-content>.md-content__inner,[dir=rtl] .md-sidebar--primary:not([hidden])~.md-content>.md-content__inner{margin-right:1.2rem}[dir=rtl] .md-sidebar--secondary:not([hidden])~.md-content>.md-content__inner{margin-left:1.2rem}}.md-content__inner:before{content:"";display:block;height:.4rem}.md-content__inner>:last-child{margin-bottom:0}[dir=ltr] .md-content__button{float:right}[dir=rtl] .md-content__button{float:left}[dir=ltr] .md-content__button{margin-left:.4rem}[dir=rtl] .md-content__button{margin-right:.4rem}.md-content__button{margin:.4rem 0;padding:0}@media print{.md-content__button{display:none}}.md-typeset .md-content__button{color:var(--md-default-fg-color--lighter)}.md-content__button svg{display:inline;vertical-align:top}[dir=rtl] .md-content__button svg{transform:scaleX(-1)}[dir=ltr] .md-dialog{right:.8rem}[dir=rtl] .md-dialog{left:.8rem}.md-dialog{background-color:var(--md-default-fg-color);border-radius:.1rem;bottom:.8rem;box-shadow:var(--md-shadow-z3);min-width:11.1rem;opacity:0;padding:.4rem .6rem;pointer-events:none;position:fixed;transform:translateY(100%);transition:transform 0ms .4s,opacity .4s;z-index:4}@media print{.md-dialog{display:none}}.md-dialog--active{opacity:1;pointer-events:auto;transform:translateY(0);transition:transform .4s cubic-bezier(.075,.85,.175,1),opacity .4s}.md-dialog__inner{color:var(--md-default-bg-color);font-size:.7rem}.md-feedback{margin:2em 0 1em;text-align:center}.md-feedback fieldset{border:none;margin:0;padding:0}.md-feedback__title{font-weight:700;margin:1em auto}.md-feedback__inner{position:relative}.md-feedback__list{display:flex;flex-wrap:wrap;place-content:baseline center;position:relative}.md-feedback__list:hover .md-icon:not(:disabled){color:var(--md-default-fg-color--lighter)}:disabled .md-feedback__list{min-height:1.8rem}.md-feedback__icon{color:var(--md-default-fg-color--light);cursor:pointer;flex-shrink:0;margin:0 .1rem;transition:color 125ms}.md-feedback__icon:not(:disabled).md-icon:hover{color:var(--md-accent-fg-color)}.md-feedback__icon:disabled{color:var(--md-default-fg-color--lightest);pointer-events:none}.md-feedback__note{opacity:0;position:relative;transform:translateY(.4rem);transition:transform .4s cubic-bezier(.1,.7,.1,1),opacity .15s}.md-feedback__note>*{margin:0 auto;max-width:16rem}:disabled .md-feedback__note{opacity:1;transform:translateY(0)}.md-footer{background-color:var(--md-footer-bg-color);color:var(--md-footer-fg-color)}@media print{.md-footer{display:none}}.md-footer__inner{justify-content:space-between;overflow:auto;padding:.2rem}.md-footer__inner:not([hidden]){display:flex}.md-footer__link{align-items:end;display:flex;flex-grow:0.01;margin-bottom:.4rem;margin-top:1rem;max-width:100%;outline-color:var(--md-accent-fg-color);overflow:hidden;transition:opacity .25s}.md-footer__link:focus,.md-footer__link:hover{opacity:.7}[dir=rtl] .md-footer__link svg{transform:scaleX(-1)}@media screen and (max-width:44.984375em){.md-footer__link--prev{flex-shrink:0}.md-footer__link--prev .md-footer__title{display:none}}[dir=ltr] .md-footer__link--next{margin-left:auto}[dir=rtl] .md-footer__link--next{margin-right:auto}.md-footer__link--next{text-align:right}[dir=rtl] .md-footer__link--next{text-align:left}.md-footer__title{flex-grow:1;font-size:.9rem;margin-bottom:.7rem;max-width:calc(100% - 2.4rem);padding:0 1rem;white-space:nowrap}.md-footer__button{margin:.2rem;padding:.4rem}.md-footer__direction{font-size:.64rem;opacity:.7}.md-footer-meta{background-color:var(--md-footer-bg-color--dark)}.md-footer-meta__inner{display:flex;flex-wrap:wrap;justify-content:space-between;padding:.2rem}html .md-footer-meta.md-typeset a{color:var(--md-footer-fg-color--light)}html .md-footer-meta.md-typeset a:focus,html .md-footer-meta.md-typeset a:hover{color:var(--md-footer-fg-color)}.md-copyright{color:var(--md-footer-fg-color--lighter);font-size:.64rem;margin:auto .6rem;padding:.4rem 0;width:100%}@media screen and (min-width:45em){.md-copyright{width:auto}}.md-copyright__highlight{color:var(--md-footer-fg-color--light)}.md-social{display:inline-flex;gap:.2rem;margin:0 .4rem;padding:.2rem 0 .6rem}@media screen and (min-width:45em){.md-social{padding:.6rem 0}}.md-social__link{display:inline-block;height:1.6rem;text-align:center;width:1.6rem}.md-social__link:before{line-height:1.9}.md-social__link svg{fill:currentcolor;max-height:.8rem;vertical-align:-25%}.md-typeset .md-button{border:.1rem solid;border-radius:.1rem;color:var(--md-primary-fg-color);cursor:pointer;display:inline-block;font-weight:700;padding:.625em 2em;transition:color 125ms,background-color 125ms,border-color 125ms}.md-typeset .md-button--primary{background-color:var(--md-primary-fg-color);border-color:var(--md-primary-fg-color);color:var(--md-primary-bg-color)}.md-typeset .md-button:focus,.md-typeset .md-button:hover{background-color:var(--md-accent-fg-color);border-color:var(--md-accent-fg-color);color:var(--md-accent-bg-color)}[dir=ltr] .md-typeset .md-input{border-top-left-radius:.1rem}[dir=ltr] .md-typeset .md-input,[dir=rtl] .md-typeset .md-input{border-top-right-radius:.1rem}[dir=rtl] .md-typeset .md-input{border-top-left-radius:.1rem}.md-typeset .md-input{border-bottom:.1rem solid var(--md-default-fg-color--lighter);box-shadow:var(--md-shadow-z1);font-size:.8rem;height:1.8rem;padding:0 .6rem;transition:border .25s,box-shadow .25s}.md-typeset .md-input:focus,.md-typeset .md-input:hover{border-bottom-color:var(--md-accent-fg-color);box-shadow:var(--md-shadow-z2)}.md-typeset .md-input--stretch{width:100%}.md-header{background-color:var(--md-primary-fg-color);box-shadow:0 0 .2rem #0000,0 .2rem .4rem #0000;color:var(--md-primary-bg-color);display:block;left:0;position:sticky;right:0;top:0;z-index:4}@media print{.md-header{display:none}}.md-header[hidden]{transform:translateY(-100%);transition:transform .25s cubic-bezier(.8,0,.6,1),box-shadow .25s}.md-header--shadow{box-shadow:0 0 .2rem #0000001a,0 .2rem .4rem #0003;transition:transform .25s cubic-bezier(.1,.7,.1,1),box-shadow .25s}.md-header__inner{align-items:center;display:flex;padding:0 .2rem}.md-header__button{color:currentcolor;cursor:pointer;margin:.2rem;outline-color:var(--md-accent-fg-color);padding:.4rem;position:relative;transition:opacity .25s;vertical-align:middle;z-index:1}.md-header__button:hover{opacity:.7}.md-header__button:not([hidden]){display:inline-block}.md-header__button:not(.focus-visible){-webkit-tap-highlight-color:transparent;outline:none}.md-header__button.md-logo{margin:.2rem;padding:.4rem}@media screen and (max-width:76.234375em){.md-header__button.md-logo{display:none}}.md-header__button.md-logo img,.md-header__button.md-logo svg{fill:currentcolor;display:block;height:1.2rem;width:auto}@media screen and (min-width:60em){.md-header__button[for=__search]{display:none}}.no-js .md-header__button[for=__search]{display:none}[dir=rtl] .md-header__button[for=__search] svg{transform:scaleX(-1)}@media screen and (min-width:76.25em){.md-header__button[for=__drawer]{display:none}}.md-header__topic{display:flex;max-width:100%;position:absolute;transition:transform .4s cubic-bezier(.1,.7,.1,1),opacity .15s;white-space:nowrap}.md-header__topic+.md-header__topic{opacity:0;pointer-events:none;transform:translateX(1.25rem);transition:transform .4s cubic-bezier(1,.7,.1,.1),opacity .15s;z-index:-1}[dir=rtl] .md-header__topic+.md-header__topic{transform:translateX(-1.25rem)}.md-header__topic:first-child{font-weight:700}[dir=ltr] .md-header__title{margin-left:1rem;margin-right:.4rem}[dir=rtl] .md-header__title{margin-left:.4rem;margin-right:1rem}.md-header__title{flex-grow:1;font-size:.9rem;height:2.4rem;line-height:2.4rem}.md-header__title--active .md-header__topic{opacity:0;pointer-events:none;transform:translateX(-1.25rem);transition:transform .4s cubic-bezier(1,.7,.1,.1),opacity .15s;z-index:-1}[dir=rtl] .md-header__title--active .md-header__topic{transform:translateX(1.25rem)}.md-header__title--active .md-header__topic+.md-header__topic{opacity:1;pointer-events:auto;transform:translateX(0);transition:transform .4s cubic-bezier(.1,.7,.1,1),opacity .15s;z-index:0}.md-header__title>.md-header__ellipsis{height:100%;position:relative;width:100%}.md-header__option{display:flex;flex-shrink:0;max-width:100%;transition:max-width 0ms .25s,opacity .25s .25s;white-space:nowrap}[data-md-toggle=search]:checked~.md-header .md-header__option{max-width:0;opacity:0;transition:max-width 0ms,opacity 0ms}.md-header__option>input{bottom:0}.md-header__source{display:none}@media screen and (min-width:60em){[dir=ltr] .md-header__source{margin-left:1rem}[dir=rtl] .md-header__source{margin-right:1rem}.md-header__source{display:block;max-width:11.7rem;width:11.7rem}}@media screen and (min-width:76.25em){[dir=ltr] .md-header__source{margin-left:1.4rem}[dir=rtl] .md-header__source{margin-right:1.4rem}}.md-meta{color:var(--md-default-fg-color--light);font-size:.7rem;line-height:1.3}.md-meta__list{display:inline-flex;flex-wrap:wrap;list-style:none;margin:0;padding:0}.md-meta__item:not(:last-child):after{content:"·";margin-left:.2rem;margin-right:.2rem}.md-meta__link{color:var(--md-typeset-a-color)}.md-meta__link:focus,.md-meta__link:hover{color:var(--md-accent-fg-color)}.md-draft{background-color:#ff1744;border-radius:.125em;color:#fff;display:inline-block;font-weight:700;padding-left:.5714285714em;padding-right:.5714285714em}:root{--md-nav-icon--prev:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>');--md-nav-icon--next:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M8.59 16.58 13.17 12 8.59 7.41 10 6l6 6-6 6z"/></svg>');--md-toc-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M3 9h14V7H3zm0 4h14v-2H3zm0 4h14v-2H3zm16 0h2v-2h-2zm0-10v2h2V7zm0 6h2v-2h-2z"/></svg>')}.md-nav{font-size:.7rem;line-height:1.3}.md-nav__title{color:var(--md-default-fg-color--light);display:block;font-weight:700;overflow:hidden;padding:0 .6rem;text-overflow:ellipsis}.md-nav__title .md-nav__button{display:none}.md-nav__title .md-nav__button img{height:100%;width:auto}.md-nav__title .md-nav__button.md-logo img,.md-nav__title .md-nav__button.md-logo svg{fill:currentcolor;display:block;height:2.4rem;max-width:100%;object-fit:contain;width:auto}.md-nav__list{list-style:none;margin:0;padding:0}.md-nav__link{align-items:flex-start;display:flex;gap:.4rem;margin-top:.625em;scroll-snap-align:start;transition:color 125ms}.md-nav__link--passed{color:var(--md-default-fg-color--light)}.md-nav__item .md-nav__link--active,.md-nav__item .md-nav__link--active code{color:var(--md-typeset-a-color)}.md-nav__link .md-ellipsis{position:relative}[dir=ltr] .md-nav__link .md-icon:last-child{margin-left:auto}[dir=rtl] .md-nav__link .md-icon:last-child{margin-right:auto}.md-nav__link svg{fill:currentcolor;flex-shrink:0;height:1.3em;position:relative}.md-nav__link[for]:focus,.md-nav__link[for]:hover,.md-nav__link[href]:focus,.md-nav__link[href]:hover{color:var(--md-accent-fg-color);cursor:pointer}.md-nav__link.focus-visible{outline-color:var(--md-accent-fg-color);outline-offset:.2rem}.md-nav--primary .md-nav__link[for=__toc]{display:none}.md-nav--primary .md-nav__link[for=__toc] .md-icon:after{background-color:currentcolor;display:block;height:100%;-webkit-mask-image:var(--md-toc-icon);mask-image:var(--md-toc-icon);width:100%}.md-nav--primary .md-nav__link[for=__toc]~.md-nav{display:none}.md-nav__container>.md-nav__link{margin-top:0}.md-nav__container>.md-nav__link:first-child{flex-grow:1;min-width:0}.md-nav__icon{flex-shrink:0}.md-nav__source{display:none}@media screen and (max-width:76.234375em){.md-nav--primary,.md-nav--primary .md-nav{background-color:var(--md-default-bg-color);display:flex;flex-direction:column;height:100%;left:0;position:absolute;right:0;top:0;z-index:1}.md-nav--primary .md-nav__item,.md-nav--primary .md-nav__title{font-size:.8rem;line-height:1.5}.md-nav--primary .md-nav__title{background-color:var(--md-default-fg-color--lightest);color:var(--md-default-fg-color--light);cursor:pointer;height:5.6rem;line-height:2.4rem;padding:3rem .8rem .2rem;position:relative;white-space:nowrap}[dir=ltr] .md-nav--primary .md-nav__title .md-nav__icon{left:.4rem}[dir=rtl] .md-nav--primary .md-nav__title .md-nav__icon{right:.4rem}.md-nav--primary .md-nav__title .md-nav__icon{display:block;height:1.2rem;margin:.2rem;position:absolute;top:.4rem;width:1.2rem}.md-nav--primary .md-nav__title .md-nav__icon:after{background-color:currentcolor;content:"";display:block;height:100%;-webkit-mask-image:var(--md-nav-icon--prev);mask-image:var(--md-nav-icon--prev);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;width:100%}.md-nav--primary .md-nav__title~.md-nav__list{background-color:var(--md-default-bg-color);box-shadow:0 .05rem 0 var(--md-default-fg-color--lightest) inset;overflow-y:auto;scroll-snap-type:y mandatory;touch-action:pan-y}.md-nav--primary .md-nav__title~.md-nav__list>:first-child{border-top:0}.md-nav--primary .md-nav__title[for=__drawer]{background-color:var(--md-primary-fg-color);color:var(--md-primary-bg-color);font-weight:700}.md-nav--primary .md-nav__title .md-logo{display:block;left:.2rem;margin:.2rem;padding:.4rem;position:absolute;right:.2rem;top:.2rem}.md-nav--primary .md-nav__list{flex:1}.md-nav--primary .md-nav__item{border-top:.05rem solid var(--md-default-fg-color--lightest)}.md-nav--primary .md-nav__item--active>.md-nav__link{color:var(--md-typeset-a-color)}.md-nav--primary .md-nav__item--active>.md-nav__link:focus,.md-nav--primary .md-nav__item--active>.md-nav__link:hover{color:var(--md-accent-fg-color)}.md-nav--primary .md-nav__link{margin-top:0;padding:.6rem .8rem}.md-nav--primary .md-nav__link svg{margin-top:.1em}.md-nav--primary .md-nav__link>.md-nav__link{padding:0}[dir=ltr] .md-nav--primary .md-nav__link .md-nav__icon{margin-right:-.2rem}[dir=rtl] .md-nav--primary .md-nav__link .md-nav__icon{margin-left:-.2rem}.md-nav--primary .md-nav__link .md-nav__icon{font-size:1.2rem;height:1.2rem;width:1.2rem}.md-nav--primary .md-nav__link .md-nav__icon:after{background-color:currentcolor;content:"";display:block;height:100%;-webkit-mask-image:var(--md-nav-icon--next);mask-image:var(--md-nav-icon--next);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;width:100%}[dir=rtl] .md-nav--primary .md-nav__icon:after{transform:scale(-1)}.md-nav--primary .md-nav--secondary .md-nav{background-color:initial;position:static}[dir=ltr] .md-nav--primary .md-nav--secondary .md-nav .md-nav__link{padding-left:1.4rem}[dir=rtl] .md-nav--primary .md-nav--secondary .md-nav .md-nav__link{padding-right:1.4rem}[dir=ltr] .md-nav--primary .md-nav--secondary .md-nav .md-nav .md-nav__link{padding-left:2rem}[dir=rtl] .md-nav--primary .md-nav--secondary .md-nav .md-nav .md-nav__link{padding-right:2rem}[dir=ltr] .md-nav--primary .md-nav--secondary .md-nav .md-nav .md-nav .md-nav__link{padding-left:2.6rem}[dir=rtl] .md-nav--primary .md-nav--secondary .md-nav .md-nav .md-nav .md-nav__link{padding-right:2.6rem}[dir=ltr] .md-nav--primary .md-nav--secondary .md-nav .md-nav .md-nav .md-nav .md-nav__link{padding-left:3.2rem}[dir=rtl] .md-nav--primary .md-nav--secondary .md-nav .md-nav .md-nav .md-nav .md-nav__link{padding-right:3.2rem}.md-nav--secondary{background-color:initial}.md-nav__toggle~.md-nav{display:flex;opacity:0;transform:translateX(100%);transition:transform .25s cubic-bezier(.8,0,.6,1),opacity 125ms 50ms}[dir=rtl] .md-nav__toggle~.md-nav{transform:translateX(-100%)}.md-nav__toggle:checked~.md-nav{opacity:1;transform:translateX(0);transition:transform .25s cubic-bezier(.4,0,.2,1),opacity 125ms 125ms}.md-nav__toggle:checked~.md-nav>.md-nav__list{-webkit-backface-visibility:hidden;backface-visibility:hidden}}@media screen and (max-width:59.984375em){.md-nav--primary .md-nav__link[for=__toc]{display:flex}.md-nav--primary .md-nav__link[for=__toc] .md-icon:after{content:""}.md-nav--primary .md-nav__link[for=__toc]+.md-nav__link{display:none}.md-nav--primary .md-nav__link[for=__toc]~.md-nav{display:flex}.md-nav__source{background-color:var(--md-primary-fg-color--dark);color:var(--md-primary-bg-color);display:block;padding:0 .2rem}}@media screen and (min-width:60em) and (max-width:76.234375em){.md-nav--integrated .md-nav__link[for=__toc]{display:flex}.md-nav--integrated .md-nav__link[for=__toc] .md-icon:after{content:""}.md-nav--integrated .md-nav__link[for=__toc]+.md-nav__link{display:none}.md-nav--integrated .md-nav__link[for=__toc]~.md-nav{display:flex}}@media screen and (min-width:60em){.md-nav{margin-bottom:-.4rem}.md-nav--secondary .md-nav__title{background:var(--md-default-bg-color);box-shadow:0 0 .4rem .4rem var(--md-default-bg-color);position:sticky;top:0;z-index:1}.md-nav--secondary .md-nav__title[for=__toc]{scroll-snap-align:start}.md-nav--secondary .md-nav__title .md-nav__icon{display:none}[dir=ltr] .md-nav--secondary .md-nav__list{padding-left:.6rem}[dir=rtl] .md-nav--secondary .md-nav__list{padding-right:.6rem}.md-nav--secondary .md-nav__list{padding-bottom:.4rem}[dir=ltr] .md-nav--secondary .md-nav__item>.md-nav__link{margin-right:.4rem}[dir=rtl] .md-nav--secondary .md-nav__item>.md-nav__link{margin-left:.4rem}}@media screen and (min-width:76.25em){.md-nav{margin-bottom:-.4rem;transition:max-height .25s cubic-bezier(.86,0,.07,1)}.md-nav--primary .md-nav__title{background:var(--md-default-bg-color);box-shadow:0 0 .4rem .4rem var(--md-default-bg-color);position:sticky;top:0;z-index:1}.md-nav--primary .md-nav__title[for=__drawer]{scroll-snap-align:start}.md-nav--primary .md-nav__title .md-nav__icon{display:none}[dir=ltr] .md-nav--primary .md-nav__list{padding-left:.6rem}[dir=rtl] .md-nav--primary .md-nav__list{padding-right:.6rem}.md-nav--primary .md-nav__list{padding-bottom:.4rem}[dir=ltr] .md-nav--primary .md-nav__item>.md-nav__link{margin-right:.4rem}[dir=rtl] .md-nav--primary .md-nav__item>.md-nav__link{margin-left:.4rem}.md-nav__toggle~.md-nav{display:grid;grid-template-rows:0fr;opacity:0;transition:grid-template-rows .25s cubic-bezier(.86,0,.07,1),opacity .25s,visibility 0ms .25s;visibility:collapse}.md-nav__toggle~.md-nav>.md-nav__list{overflow:hidden}.md-nav__toggle.md-toggle--indeterminate~.md-nav,.md-nav__toggle:checked~.md-nav{grid-template-rows:1fr;opacity:1;transition:grid-template-rows .25s cubic-bezier(.86,0,.07,1),opacity .15s .1s,visibility 0ms;visibility:visible}.md-nav__toggle.md-toggle--indeterminate~.md-nav{transition:none}.md-nav__item--nested>.md-nav>.md-nav__title{display:none}.md-nav__item--section{display:block;margin:1.25em 0}.md-nav__item--section:last-child{margin-bottom:0}.md-nav__item--section>.md-nav__link{font-weight:700}.md-nav__item--section>.md-nav__link[for]{color:var(--md-default-fg-color--light)}.md-nav__item--section>.md-nav__link:not(.md-nav__container){pointer-events:none}.md-nav__item--section>.md-nav__link .md-icon,.md-nav__item--section>.md-nav__link>[for]{display:none}[dir=ltr] .md-nav__item--section>.md-nav{margin-left:-.6rem}[dir=rtl] .md-nav__item--section>.md-nav{margin-right:-.6rem}.md-nav__item--section>.md-nav{display:block;opacity:1;visibility:visible}.md-nav__item--section>.md-nav>.md-nav__list>.md-nav__item{padding:0}.md-nav__icon{border-radius:100%;height:.9rem;transition:background-color .25s;width:.9rem}.md-nav__icon:hover{background-color:var(--md-accent-fg-color--transparent)}.md-nav__icon:after{background-color:currentcolor;border-radius:100%;content:"";display:inline-block;height:100%;-webkit-mask-image:var(--md-nav-icon--next);mask-image:var(--md-nav-icon--next);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;transition:transform .25s;vertical-align:-.1rem;width:100%}[dir=rtl] .md-nav__icon:after{transform:rotate(180deg)}.md-nav__item--nested .md-nav__toggle:checked~.md-nav__link .md-nav__icon:after,.md-nav__item--nested .md-toggle--indeterminate~.md-nav__link .md-nav__icon:after{transform:rotate(90deg)}.md-nav--lifted>.md-nav__list>.md-nav__item,.md-nav--lifted>.md-nav__title{display:none}.md-nav--lifted>.md-nav__list>.md-nav__item--active{display:block}.md-nav--lifted>.md-nav__list>.md-nav__item--active>.md-nav__link{background:var(--md-default-bg-color);box-shadow:0 0 .4rem .4rem var(--md-default-bg-color);margin-top:0;position:sticky;top:0;z-index:1}.md-nav--lifted>.md-nav__list>.md-nav__item--active>.md-nav__link:not(.md-nav__container){pointer-events:none}.md-nav--lifted>.md-nav__list>.md-nav__item--active.md-nav__item--section{margin:0}[dir=ltr] .md-nav--lifted>.md-nav__list>.md-nav__item>.md-nav:not(.md-nav--secondary){margin-left:-.6rem}[dir=rtl] .md-nav--lifted>.md-nav__list>.md-nav__item>.md-nav:not(.md-nav--secondary){margin-right:-.6rem}.md-nav--lifted>.md-nav__list>.md-nav__item>[for]{color:var(--md-default-fg-color--light)}.md-nav--lifted .md-nav[data-md-level="1"]{grid-template-rows:1fr;opacity:1;visibility:visible}[dir=ltr] .md-nav--integrated>.md-nav__list>.md-nav__item--active .md-nav--secondary{border-left:.05rem solid var(--md-primary-fg-color)}[dir=rtl] .md-nav--integrated>.md-nav__list>.md-nav__item--active .md-nav--secondary{border-right:.05rem solid var(--md-primary-fg-color)}.md-nav--integrated>.md-nav__list>.md-nav__item--active .md-nav--secondary{display:block;margin-bottom:1.25em;opacity:1;visibility:visible}.md-nav--integrated>.md-nav__list>.md-nav__item--active .md-nav--secondary>.md-nav__list{overflow:visible;padding-bottom:0}.md-nav--integrated>.md-nav__list>.md-nav__item--active .md-nav--secondary>.md-nav__title{display:none}}.md-pagination{font-size:.8rem;font-weight:700;gap:.4rem}.md-pagination,.md-pagination>*{align-items:center;display:flex;justify-content:center}.md-pagination>*{border-radius:.2rem;height:1.8rem;min-width:1.8rem;text-align:center}.md-pagination__current{background-color:var(--md-default-fg-color--lightest);color:var(--md-default-fg-color--light)}.md-pagination__link{transition:color 125ms,background-color 125ms}.md-pagination__link:focus,.md-pagination__link:hover{background-color:var(--md-accent-fg-color--transparent);color:var(--md-accent-fg-color)}.md-pagination__link:focus svg,.md-pagination__link:hover svg{color:var(--md-accent-fg-color)}.md-pagination__link.focus-visible{outline-color:var(--md-accent-fg-color);outline-offset:.2rem}.md-pagination__link svg{fill:currentcolor;color:var(--md-default-fg-color--lighter);display:block;max-height:100%;width:1.2rem}.md-post__back{border-bottom:.05rem solid var(--md-default-fg-color--lightest);margin-bottom:1.2rem;padding-bottom:1.2rem}@media screen and (max-width:76.234375em){.md-post__back{display:none}}[dir=rtl] .md-post__back svg{transform:scaleX(-1)}.md-post__authors{display:flex;flex-direction:column;gap:.6rem;margin:0 .6rem 1.2rem}.md-post .md-post__meta a{transition:color 125ms}.md-post .md-post__meta a:focus,.md-post .md-post__meta a:hover{color:var(--md-accent-fg-color)}.md-post__title{color:var(--md-default-fg-color--light);font-weight:700}.md-post--excerpt{margin-bottom:3.2rem}.md-post--excerpt .md-post__header{align-items:center;display:flex;gap:.6rem;min-height:1.6rem}.md-post--excerpt .md-post__authors{align-items:center;display:inline-flex;flex-direction:row;gap:.2rem;margin:0;min-height:2.4rem}[dir=ltr] .md-post--excerpt .md-post__meta .md-meta__list{margin-right:.4rem}[dir=rtl] .md-post--excerpt .md-post__meta .md-meta__list{margin-left:.4rem}.md-post--excerpt .md-post__content>:first-child{--md-scroll-margin:6rem;margin-top:0}.md-post>.md-nav--secondary{margin:1em 0}.md-profile{align-items:center;display:flex;font-size:.7rem;gap:.6rem;line-height:1.4;width:100%}.md-profile__description{flex-grow:1}.md-content--post{display:flex}@media screen and (max-width:76.234375em){.md-content--post{flex-flow:column-reverse}}.md-content--post>.md-content__inner{min-width:0}@media screen and (min-width:76.25em){[dir=ltr] .md-content--post>.md-content__inner{margin-left:1.2rem}[dir=rtl] .md-content--post>.md-content__inner{margin-right:1.2rem}}@media screen and (max-width:76.234375em){.md-sidebar.md-sidebar--post{padding:0;position:static;width:100%}.md-sidebar.md-sidebar--post .md-sidebar__scrollwrap{overflow:visible}.md-sidebar.md-sidebar--post .md-sidebar__inner{padding:0}.md-sidebar.md-sidebar--post .md-post__meta{margin-left:.6rem;margin-right:.6rem}.md-sidebar.md-sidebar--post .md-nav__item{border:none;display:inline}.md-sidebar.md-sidebar--post .md-nav__list{display:inline-flex;flex-wrap:wrap;gap:.6rem;padding-bottom:.6rem;padding-top:.6rem}.md-sidebar.md-sidebar--post .md-nav__link{padding:0}.md-sidebar.md-sidebar--post .md-nav{height:auto;margin-bottom:0;position:static}}:root{--md-progress-value:0;--md-progress-delay:400ms}.md-progress{background:var(--md-primary-bg-color);height:.075rem;opacity:min(clamp(0,var(--md-progress-value),1),clamp(0,100 - var(--md-progress-value),1));position:fixed;top:0;transform:scaleX(calc(var(--md-progress-value)*1%));transform-origin:left;transition:transform .5s cubic-bezier(.19,1,.22,1),opacity .25s var(--md-progress-delay);width:100%;z-index:4}:root{--md-search-result-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M14 2H6a2 2 0 0 0-2 2v16a2 2 0 0 0 2 2h7c-.41-.25-.8-.56-1.14-.9-.33-.33-.61-.7-.86-1.1H6V4h7v5h5v1.18c.71.16 1.39.43 2 .82V8zm6.31 16.9c1.33-2.11.69-4.9-1.4-6.22-2.11-1.33-4.91-.68-6.22 1.4-1.34 2.11-.69 4.89 1.4 6.22 1.46.93 3.32.93 4.79.02L22 23.39 23.39 22zm-3.81.1a2.5 2.5 0 0 1-2.5-2.5 2.5 2.5 0 0 1 2.5-2.5 2.5 2.5 0 0 1 2.5 2.5 2.5 2.5 0 0 1-2.5 2.5"/></svg>')}.md-search{position:relative}@media screen and (min-width:60em){.md-search{padding:.2rem 0}}.no-js .md-search{display:none}.md-search__overlay{opacity:0;z-index:1}@media screen and (max-width:59.984375em){[dir=ltr] .md-search__overlay{left:-2.2rem}[dir=rtl] .md-search__overlay{right:-2.2rem}.md-search__overlay{background-color:var(--md-default-bg-color);border-radius:1rem;height:2rem;overflow:hidden;pointer-events:none;position:absolute;top:-1rem;transform-origin:center;transition:transform .3s .1s,opacity .2s .2s;width:2rem}[data-md-toggle=search]:checked~.md-header .md-search__overlay{opacity:1;transition:transform .4s,opacity .1s}}@media screen and (min-width:60em){[dir=ltr] .md-search__overlay{left:0}[dir=rtl] .md-search__overlay{right:0}.md-search__overlay{background-color:#0000008a;cursor:pointer;height:0;position:fixed;top:0;transition:width 0ms .25s,height 0ms .25s,opacity .25s;width:0}[data-md-toggle=search]:checked~.md-header .md-search__overlay{height:200vh;opacity:1;transition:width 0ms,height 0ms,opacity .25s;width:100%}}@media screen and (max-width:29.984375em){[data-md-toggle=search]:checked~.md-header .md-search__overlay{transform:scale(45)}}@media screen and (min-width:30em) and (max-width:44.984375em){[data-md-toggle=search]:checked~.md-header .md-search__overlay{transform:scale(60)}}@media screen and (min-width:45em) and (max-width:59.984375em){[data-md-toggle=search]:checked~.md-header .md-search__overlay{transform:scale(75)}}.md-search__inner{-webkit-backface-visibility:hidden;backface-visibility:hidden}@media screen and (max-width:59.984375em){[dir=ltr] .md-search__inner{left:0}[dir=rtl] .md-search__inner{right:0}.md-search__inner{height:0;opacity:0;overflow:hidden;position:fixed;top:0;transform:translateX(5%);transition:width 0ms .3s,height 0ms .3s,transform .15s cubic-bezier(.4,0,.2,1) .15s,opacity .15s .15s;width:0;z-index:2}[dir=rtl] .md-search__inner{transform:translateX(-5%)}[data-md-toggle=search]:checked~.md-header .md-search__inner{height:100%;opacity:1;transform:translateX(0);transition:width 0ms 0ms,height 0ms 0ms,transform .15s cubic-bezier(.1,.7,.1,1) .15s,opacity .15s .15s;width:100%}}@media screen and (min-width:60em){[dir=ltr] .md-search__inner{float:right}[dir=rtl] .md-search__inner{float:left}.md-search__inner{padding:.1rem 0;position:relative;transition:width .25s cubic-bezier(.1,.7,.1,1);width:11.7rem}}@media screen and (min-width:60em) and (max-width:76.234375em){[data-md-toggle=search]:checked~.md-header .md-search__inner{width:23.4rem}}@media screen and (min-width:76.25em){[data-md-toggle=search]:checked~.md-header .md-search__inner{width:34.4rem}}.md-search__form{background-color:var(--md-default-bg-color);box-shadow:0 0 .6rem #0000;height:2.4rem;position:relative;transition:color .25s,background-color .25s;z-index:2}@media screen and (min-width:60em){.md-search__form{background-color:#00000042;border-radius:.1rem;height:1.8rem}.md-search__form:hover{background-color:#ffffff1f}}[data-md-toggle=search]:checked~.md-header .md-search__form{background-color:var(--md-default-bg-color);border-radius:.1rem .1rem 0 0;box-shadow:0 0 .6rem #00000012;color:var(--md-default-fg-color)}[dir=ltr] .md-search__input{padding-left:3.6rem;padding-right:2.2rem}[dir=rtl] .md-search__input{padding-left:2.2rem;padding-right:3.6rem}.md-search__input{background:#0000;font-size:.9rem;height:100%;position:relative;text-overflow:ellipsis;width:100%;z-index:2}.md-search__input::placeholder{transition:color .25s}.md-search__input::placeholder,.md-search__input~.md-search__icon{color:var(--md-default-fg-color--light)}.md-search__input::-ms-clear{display:none}@media screen and (max-width:59.984375em){.md-search__input{font-size:.9rem;height:2.4rem;width:100%}}@media screen and (min-width:60em){[dir=ltr] .md-search__input{padding-left:2.2rem}[dir=rtl] .md-search__input{padding-right:2.2rem}.md-search__input{color:inherit;font-size:.8rem}.md-search__input::placeholder{color:var(--md-primary-bg-color--light)}.md-search__input+.md-search__icon{color:var(--md-primary-bg-color)}[data-md-toggle=search]:checked~.md-header .md-search__input{text-overflow:clip}[data-md-toggle=search]:checked~.md-header .md-search__input+.md-search__icon{color:var(--md-default-fg-color--light)}[data-md-toggle=search]:checked~.md-header .md-search__input::placeholder{color:#0000}}.md-search__icon{cursor:pointer;display:inline-block;height:1.2rem;transition:color .25s,opacity .25s;width:1.2rem}.md-search__icon:hover{opacity:.7}[dir=ltr] .md-search__icon[for=__search]{left:.5rem}[dir=rtl] .md-search__icon[for=__search]{right:.5rem}.md-search__icon[for=__search]{position:absolute;top:.3rem;z-index:2}[dir=rtl] .md-search__icon[for=__search] svg{transform:scaleX(-1)}@media screen and (max-width:59.984375em){[dir=ltr] .md-search__icon[for=__search]{left:.8rem}[dir=rtl] .md-search__icon[for=__search]{right:.8rem}.md-search__icon[for=__search]{top:.6rem}.md-search__icon[for=__search] svg:first-child{display:none}}@media screen and (min-width:60em){.md-search__icon[for=__search]{pointer-events:none}.md-search__icon[for=__search] svg:last-child{display:none}}[dir=ltr] .md-search__options{right:.5rem}[dir=rtl] .md-search__options{left:.5rem}.md-search__options{pointer-events:none;position:absolute;top:.3rem;z-index:2}@media screen and (max-width:59.984375em){[dir=ltr] .md-search__options{right:.8rem}[dir=rtl] .md-search__options{left:.8rem}.md-search__options{top:.6rem}}[dir=ltr] .md-search__options>.md-icon{margin-left:.2rem}[dir=rtl] .md-search__options>.md-icon{margin-right:.2rem}.md-search__options>.md-icon{color:var(--md-default-fg-color--light);opacity:0;transform:scale(.75);transition:transform .15s cubic-bezier(.1,.7,.1,1),opacity .15s}.md-search__options>.md-icon:not(.focus-visible){-webkit-tap-highlight-color:transparent;outline:none}[data-md-toggle=search]:checked~.md-header .md-search__input:valid~.md-search__options>.md-icon{opacity:1;pointer-events:auto;transform:scale(1)}[data-md-toggle=search]:checked~.md-header .md-search__input:valid~.md-search__options>.md-icon:hover{opacity:.7}[dir=ltr] .md-search__suggest{padding-left:3.6rem;padding-right:2.2rem}[dir=rtl] .md-search__suggest{padding-left:2.2rem;padding-right:3.6rem}.md-search__suggest{align-items:center;color:var(--md-default-fg-color--lighter);display:flex;font-size:.9rem;height:100%;opacity:0;position:absolute;top:0;transition:opacity 50ms;white-space:nowrap;width:100%}@media screen and (min-width:60em){[dir=ltr] .md-search__suggest{padding-left:2.2rem}[dir=rtl] .md-search__suggest{padding-right:2.2rem}.md-search__suggest{font-size:.8rem}}[data-md-toggle=search]:checked~.md-header .md-search__suggest{opacity:1;transition:opacity .3s .1s}[dir=ltr] .md-search__output{border-bottom-left-radius:.1rem}[dir=ltr] .md-search__output,[dir=rtl] .md-search__output{border-bottom-right-radius:.1rem}[dir=rtl] .md-search__output{border-bottom-left-radius:.1rem}.md-search__output{overflow:hidden;position:absolute;width:100%;z-index:1}@media screen and (max-width:59.984375em){.md-search__output{bottom:0;top:2.4rem}}@media screen and (min-width:60em){.md-search__output{opacity:0;top:1.9rem;transition:opacity .4s}[data-md-toggle=search]:checked~.md-header .md-search__output{box-shadow:var(--md-shadow-z3);opacity:1}}.md-search__scrollwrap{-webkit-backface-visibility:hidden;backface-visibility:hidden;background-color:var(--md-default-bg-color);height:100%;overflow-y:auto;touch-action:pan-y}@media (-webkit-max-device-pixel-ratio:1),(max-resolution:1dppx){.md-search__scrollwrap{transform:translateZ(0)}}@media screen and (min-width:60em) and (max-width:76.234375em){.md-search__scrollwrap{width:23.4rem}}@media screen and (min-width:76.25em){.md-search__scrollwrap{width:34.4rem}}@media screen and (min-width:60em){.md-search__scrollwrap{max-height:0;scrollbar-color:var(--md-default-fg-color--lighter) #0000;scrollbar-width:thin}[data-md-toggle=search]:checked~.md-header .md-search__scrollwrap{max-height:75vh}.md-search__scrollwrap:hover{scrollbar-color:var(--md-accent-fg-color) #0000}.md-search__scrollwrap::-webkit-scrollbar{height:.2rem;width:.2rem}.md-search__scrollwrap::-webkit-scrollbar-thumb{background-color:var(--md-default-fg-color--lighter)}.md-search__scrollwrap::-webkit-scrollbar-thumb:hover{background-color:var(--md-accent-fg-color)}}.md-search-result{color:var(--md-default-fg-color);word-break:break-word}.md-search-result__meta{background-color:var(--md-default-fg-color--lightest);color:var(--md-default-fg-color--light);font-size:.64rem;line-height:1.8rem;padding:0 .8rem;scroll-snap-align:start}@media screen and (min-width:60em){[dir=ltr] .md-search-result__meta{padding-left:2.2rem}[dir=rtl] .md-search-result__meta{padding-right:2.2rem}}.md-search-result__list{list-style:none;margin:0;padding:0;-webkit-user-select:none;user-select:none}.md-search-result__item{box-shadow:0 -.05rem var(--md-default-fg-color--lightest)}.md-search-result__item:first-child{box-shadow:none}.md-search-result__link{display:block;outline:none;scroll-snap-align:start;transition:background-color .25s}.md-search-result__link:focus,.md-search-result__link:hover{background-color:var(--md-accent-fg-color--transparent)}.md-search-result__link:last-child p:last-child{margin-bottom:.6rem}.md-search-result__more>summary{cursor:pointer;display:block;outline:none;position:sticky;scroll-snap-align:start;top:0;z-index:1}.md-search-result__more>summary::marker{display:none}.md-search-result__more>summary::-webkit-details-marker{display:none}.md-search-result__more>summary>div{color:var(--md-typeset-a-color);font-size:.64rem;padding:.75em .8rem;transition:color .25s,background-color .25s}@media screen and (min-width:60em){[dir=ltr] .md-search-result__more>summary>div{padding-left:2.2rem}[dir=rtl] .md-search-result__more>summary>div{padding-right:2.2rem}}.md-search-result__more>summary:focus>div,.md-search-result__more>summary:hover>div{background-color:var(--md-accent-fg-color--transparent);color:var(--md-accent-fg-color)}.md-search-result__more[open]>summary{background-color:var(--md-default-bg-color)}.md-search-result__article{overflow:hidden;padding:0 .8rem;position:relative}@media screen and (min-width:60em){[dir=ltr] .md-search-result__article{padding-left:2.2rem}[dir=rtl] .md-search-result__article{padding-right:2.2rem}}[dir=ltr] .md-search-result__icon{left:0}[dir=rtl] .md-search-result__icon{right:0}.md-search-result__icon{color:var(--md-default-fg-color--light);height:1.2rem;margin:.5rem;position:absolute;width:1.2rem}@media screen and (max-width:59.984375em){.md-search-result__icon{display:none}}.md-search-result__icon:after{background-color:currentcolor;content:"";display:inline-block;height:100%;-webkit-mask-image:var(--md-search-result-icon);mask-image:var(--md-search-result-icon);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;width:100%}[dir=rtl] .md-search-result__icon:after{transform:scaleX(-1)}.md-search-result .md-typeset{color:var(--md-default-fg-color--light);font-size:.64rem;line-height:1.6}.md-search-result .md-typeset h1{color:var(--md-default-fg-color);font-size:.8rem;font-weight:400;line-height:1.4;margin:.55rem 0}.md-search-result .md-typeset h1 mark{text-decoration:none}.md-search-result .md-typeset h2{color:var(--md-default-fg-color);font-size:.64rem;font-weight:700;line-height:1.6;margin:.5em 0}.md-search-result .md-typeset h2 mark{text-decoration:none}.md-search-result__terms{color:var(--md-default-fg-color);display:block;font-size:.64rem;font-style:italic;margin:.5em 0}.md-search-result mark{background-color:initial;color:var(--md-accent-fg-color);text-decoration:underline}.md-select{position:relative;z-index:1}.md-select__inner{background-color:var(--md-default-bg-color);border-radius:.1rem;box-shadow:var(--md-shadow-z2);color:var(--md-default-fg-color);left:50%;margin-top:.2rem;max-height:0;opacity:0;position:absolute;top:calc(100% - .2rem);transform:translate3d(-50%,.3rem,0);transition:transform .25s 375ms,opacity .25s .25s,max-height 0ms .5s}.md-select:focus-within .md-select__inner,.md-select:hover .md-select__inner{max-height:10rem;opacity:1;transform:translate3d(-50%,0,0);transition:transform .25s cubic-bezier(.1,.7,.1,1),opacity .25s,max-height 0ms}.md-select__inner:after{border-bottom:.2rem solid #0000;border-bottom-color:var(--md-default-bg-color);border-left:.2rem solid #0000;border-right:.2rem solid #0000;border-top:0;content:"";height:0;left:50%;margin-left:-.2rem;margin-top:-.2rem;position:absolute;top:0;width:0}.md-select__list{border-radius:.1rem;font-size:.8rem;list-style-type:none;margin:0;max-height:inherit;overflow:auto;padding:0}.md-select__item{line-height:1.8rem}[dir=ltr] .md-select__link{padding-left:.6rem;padding-right:1.2rem}[dir=rtl] .md-select__link{padding-left:1.2rem;padding-right:.6rem}.md-select__link{cursor:pointer;display:block;outline:none;scroll-snap-align:start;transition:background-color .25s,color .25s;width:100%}.md-select__link:focus,.md-select__link:hover{color:var(--md-accent-fg-color)}.md-select__link:focus{background-color:var(--md-default-fg-color--lightest)}.md-sidebar{align-self:flex-start;flex-shrink:0;padding:1.2rem 0;position:sticky;top:2.4rem;width:12.1rem}@media print{.md-sidebar{display:none}}@media screen and (max-width:76.234375em){[dir=ltr] .md-sidebar--primary{left:-12.1rem}[dir=rtl] .md-sidebar--primary{right:-12.1rem}.md-sidebar--primary{background-color:var(--md-default-bg-color);display:block;height:100%;position:fixed;top:0;transform:translateX(0);transition:transform .25s cubic-bezier(.4,0,.2,1),box-shadow .25s;width:12.1rem;z-index:5}[data-md-toggle=drawer]:checked~.md-container .md-sidebar--primary{box-shadow:var(--md-shadow-z3);transform:translateX(12.1rem)}[dir=rtl] [data-md-toggle=drawer]:checked~.md-container .md-sidebar--primary{transform:translateX(-12.1rem)}.md-sidebar--primary .md-sidebar__scrollwrap{bottom:0;left:0;margin:0;overflow:hidden;position:absolute;right:0;scroll-snap-type:none;top:0}}@media screen and (min-width:76.25em){.md-sidebar{height:0}.no-js .md-sidebar{height:auto}.md-header--lifted~.md-container .md-sidebar{top:4.8rem}}.md-sidebar--secondary{display:none;order:2}@media screen and (min-width:60em){.md-sidebar--secondary{height:0}.no-js .md-sidebar--secondary{height:auto}.md-sidebar--secondary:not([hidden]){display:block}.md-sidebar--secondary .md-sidebar__scrollwrap{touch-action:pan-y}}.md-sidebar__scrollwrap{scrollbar-gutter:stable;-webkit-backface-visibility:hidden;backface-visibility:hidden;margin:0 .2rem;overflow-y:auto;scrollbar-color:var(--md-default-fg-color--lighter) #0000;scrollbar-width:thin}.md-sidebar__scrollwrap::-webkit-scrollbar{height:.2rem;width:.2rem}.md-sidebar__scrollwrap:focus-within,.md-sidebar__scrollwrap:hover{scrollbar-color:var(--md-accent-fg-color) #0000}.md-sidebar__scrollwrap:focus-within::-webkit-scrollbar-thumb,.md-sidebar__scrollwrap:hover::-webkit-scrollbar-thumb{background-color:var(--md-default-fg-color--lighter)}.md-sidebar__scrollwrap:focus-within::-webkit-scrollbar-thumb:hover,.md-sidebar__scrollwrap:hover::-webkit-scrollbar-thumb:hover{background-color:var(--md-accent-fg-color)}@supports selector(::-webkit-scrollbar){.md-sidebar__scrollwrap{scrollbar-gutter:auto}[dir=ltr] .md-sidebar__inner{padding-right:calc(100% - 11.5rem)}[dir=rtl] .md-sidebar__inner{padding-left:calc(100% - 11.5rem)}}@media screen and (max-width:76.234375em){.md-overlay{background-color:#0000008a;height:0;opacity:0;position:fixed;top:0;transition:width 0ms .25s,height 0ms .25s,opacity .25s;width:0;z-index:5}[data-md-toggle=drawer]:checked~.md-overlay{height:100%;opacity:1;transition:width 0ms,height 0ms,opacity .25s;width:100%}}@keyframes facts{0%{height:0}to{height:.65rem}}@keyframes fact{0%{opacity:0;transform:translateY(100%)}50%{opacity:0}to{opacity:1;transform:translateY(0)}}:root{--md-source-forks-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><path d="M5 5.372v.878c0 .414.336.75.75.75h4.5a.75.75 0 0 0 .75-.75v-.878a2.25 2.25 0 1 1 1.5 0v.878a2.25 2.25 0 0 1-2.25 2.25h-1.5v2.128a2.251 2.251 0 1 1-1.5 0V8.5h-1.5A2.25 2.25 0 0 1 3.5 6.25v-.878a2.25 2.25 0 1 1 1.5 0M5 3.25a.75.75 0 1 0-1.5 0 .75.75 0 0 0 1.5 0m6.75.75a.75.75 0 1 0 0-1.5.75.75 0 0 0 0 1.5m-3 8.75a.75.75 0 1 0-1.5 0 .75.75 0 0 0 1.5 0"/></svg>');--md-source-repositories-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><path d="M2 2.5A2.5 2.5 0 0 1 4.5 0h8.75a.75.75 0 0 1 .75.75v12.5a.75.75 0 0 1-.75.75h-2.5a.75.75 0 0 1 0-1.5h1.75v-2h-8a1 1 0 0 0-.714 1.7.75.75 0 1 1-1.072 1.05A2.5 2.5 0 0 1 2 11.5Zm10.5-1h-8a1 1 0 0 0-1 1v6.708A2.5 2.5 0 0 1 4.5 9h8ZM5 12.25a.25.25 0 0 1 .25-.25h3.5a.25.25 0 0 1 .25.25v3.25a.25.25 0 0 1-.4.2l-1.45-1.087a.25.25 0 0 0-.3 0L5.4 15.7a.25.25 0 0 1-.4-.2Z"/></svg>');--md-source-stars-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><path d="M8 .25a.75.75 0 0 1 .673.418l1.882 3.815 4.21.612a.75.75 0 0 1 .416 1.279l-3.046 2.97.719 4.192a.751.751 0 0 1-1.088.791L8 12.347l-3.766 1.98a.75.75 0 0 1-1.088-.79l.72-4.194L.818 6.374a.75.75 0 0 1 .416-1.28l4.21-.611L7.327.668A.75.75 0 0 1 8 .25m0 2.445L6.615 5.5a.75.75 0 0 1-.564.41l-3.097.45 2.24 2.184a.75.75 0 0 1 .216.664l-.528 3.084 2.769-1.456a.75.75 0 0 1 .698 0l2.77 1.456-.53-3.084a.75.75 0 0 1 .216-.664l2.24-2.183-3.096-.45a.75.75 0 0 1-.564-.41z"/></svg>');--md-source-version-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><path d="M1 7.775V2.75C1 1.784 1.784 1 2.75 1h5.025c.464 0 .91.184 1.238.513l6.25 6.25a1.75 1.75 0 0 1 0 2.474l-5.026 5.026a1.75 1.75 0 0 1-2.474 0l-6.25-6.25A1.75 1.75 0 0 1 1 7.775m1.5 0c0 .066.026.13.073.177l6.25 6.25a.25.25 0 0 0 .354 0l5.025-5.025a.25.25 0 0 0 0-.354l-6.25-6.25a.25.25 0 0 0-.177-.073H2.75a.25.25 0 0 0-.25.25ZM6 5a1 1 0 1 1 0 2 1 1 0 0 1 0-2"/></svg>')}.md-source{-webkit-backface-visibility:hidden;backface-visibility:hidden;display:block;font-size:.65rem;line-height:1.2;outline-color:var(--md-accent-fg-color);transition:opacity .25s;white-space:nowrap}.md-source:hover{opacity:.7}.md-source__icon{display:inline-block;height:2.4rem;vertical-align:middle;width:2rem}[dir=ltr] .md-source__icon svg{margin-left:.6rem}[dir=rtl] .md-source__icon svg{margin-right:.6rem}.md-source__icon svg{margin-top:.6rem}[dir=ltr] .md-source__icon+.md-source__repository{padding-left:2rem}[dir=rtl] .md-source__icon+.md-source__repository{padding-right:2rem}[dir=ltr] .md-source__icon+.md-source__repository{margin-left:-2rem}[dir=rtl] .md-source__icon+.md-source__repository{margin-right:-2rem}[dir=ltr] .md-source__repository{margin-left:.6rem}[dir=rtl] .md-source__repository{margin-right:.6rem}.md-source__repository{display:inline-block;max-width:calc(100% - 1.2rem);overflow:hidden;text-overflow:ellipsis;vertical-align:middle}.md-source__facts{display:flex;font-size:.55rem;gap:.4rem;list-style-type:none;margin:.1rem 0 0;opacity:.75;overflow:hidden;padding:0;width:100%}.md-source__repository--active .md-source__facts{animation:facts .25s ease-in}.md-source__fact{overflow:hidden;text-overflow:ellipsis}.md-source__repository--active .md-source__fact{animation:fact .4s ease-out}[dir=ltr] .md-source__fact:before{margin-right:.1rem}[dir=rtl] .md-source__fact:before{margin-left:.1rem}.md-source__fact:before{background-color:currentcolor;content:"";display:inline-block;height:.6rem;-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;vertical-align:text-top;width:.6rem}.md-source__fact:nth-child(1n+2){flex-shrink:0}.md-source__fact--version:before{-webkit-mask-image:var(--md-source-version-icon);mask-image:var(--md-source-version-icon)}.md-source__fact--stars:before{-webkit-mask-image:var(--md-source-stars-icon);mask-image:var(--md-source-stars-icon)}.md-source__fact--forks:before{-webkit-mask-image:var(--md-source-forks-icon);mask-image:var(--md-source-forks-icon)}.md-source__fact--repositories:before{-webkit-mask-image:var(--md-source-repositories-icon);mask-image:var(--md-source-repositories-icon)}.md-source-file{margin:1em 0}[dir=ltr] .md-source-file__fact{margin-right:.6rem}[dir=rtl] .md-source-file__fact{margin-left:.6rem}.md-source-file__fact{align-items:center;color:var(--md-default-fg-color--light);display:inline-flex;font-size:.68rem;gap:.3rem}.md-source-file__fact .md-icon{flex-shrink:0;margin-bottom:.05rem}[dir=ltr] .md-source-file__fact .md-author{float:left}[dir=rtl] .md-source-file__fact .md-author{float:right}.md-source-file__fact .md-author{margin-right:.2rem}.md-source-file__fact svg{width:.9rem}:root{--md-status:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M11 9h2V7h-2m1 13c-4.41 0-8-3.59-8-8s3.59-8 8-8 8 3.59 8 8-3.59 8-8 8m0-18A10 10 0 0 0 2 12a10 10 0 0 0 10 10 10 10 0 0 0 10-10A10 10 0 0 0 12 2m-1 15h2v-6h-2z"/></svg>');--md-status--new:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="m23 12-2.44-2.78.34-3.68-3.61-.82-1.89-3.18L12 3 8.6 1.54 6.71 4.72l-3.61.81.34 3.68L1 12l2.44 2.78-.34 3.69 3.61.82 1.89 3.18L12 21l3.4 1.46 1.89-3.18 3.61-.82-.34-3.68zm-10 5h-2v-2h2zm0-4h-2V7h2z"/></svg>');--md-status--deprecated:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9 3v1H4v2h1v13a2 2 0 0 0 2 2h10a2 2 0 0 0 2-2V6h1V4h-5V3zm0 5h2v9H9zm4 0h2v9h-2z"/></svg>');--md-status--encrypted:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 1 3 5v6c0 5.55 3.84 10.74 9 12 5.16-1.26 9-6.45 9-12V5zm0 6c1.4 0 2.8 1.1 2.8 2.5V11c.6 0 1.2.6 1.2 1.3v3.5c0 .6-.6 1.2-1.3 1.2H9.2c-.6 0-1.2-.6-1.2-1.3v-3.5c0-.6.6-1.2 1.2-1.2V9.5C9.2 8.1 10.6 7 12 7m0 1.2c-.8 0-1.5.5-1.5 1.3V11h3V9.5c0-.8-.7-1.3-1.5-1.3"/></svg>')}.md-status:after{background-color:var(--md-default-fg-color--light);content:"";display:inline-block;height:1.125em;-webkit-mask-image:var(--md-status);mask-image:var(--md-status);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;vertical-align:text-bottom;width:1.125em}.md-status:hover:after{background-color:currentcolor}.md-status--new:after{-webkit-mask-image:var(--md-status--new);mask-image:var(--md-status--new)}.md-status--deprecated:after{-webkit-mask-image:var(--md-status--deprecated);mask-image:var(--md-status--deprecated)}.md-status--encrypted:after{-webkit-mask-image:var(--md-status--encrypted);mask-image:var(--md-status--encrypted)}.md-tabs{background-color:var(--md-primary-fg-color);color:var(--md-primary-bg-color);display:block;line-height:1.3;overflow:auto;width:100%;z-index:3}@media print{.md-tabs{display:none}}@media screen and (max-width:76.234375em){.md-tabs{display:none}}.md-tabs[hidden]{pointer-events:none}[dir=ltr] .md-tabs__list{margin-left:.2rem}[dir=rtl] .md-tabs__list{margin-right:.2rem}.md-tabs__list{contain:content;display:flex;list-style:none;margin:0;overflow:auto;padding:0;scrollbar-width:none;white-space:nowrap}.md-tabs__list::-webkit-scrollbar{display:none}.md-tabs__item{height:2.4rem;padding-left:.6rem;padding-right:.6rem}.md-tabs__item--active .md-tabs__link{color:inherit;opacity:1}.md-tabs__link{-webkit-backface-visibility:hidden;backface-visibility:hidden;display:flex;font-size:.7rem;margin-top:.8rem;opacity:.7;outline-color:var(--md-accent-fg-color);outline-offset:.2rem;transition:transform .4s cubic-bezier(.1,.7,.1,1),opacity .25s}.md-tabs__link:focus,.md-tabs__link:hover{color:inherit;opacity:1}[dir=ltr] .md-tabs__link svg{margin-right:.4rem}[dir=rtl] .md-tabs__link svg{margin-left:.4rem}.md-tabs__link svg{fill:currentcolor;height:1.3em}.md-tabs__item:nth-child(2) .md-tabs__link{transition-delay:20ms}.md-tabs__item:nth-child(3) .md-tabs__link{transition-delay:40ms}.md-tabs__item:nth-child(4) .md-tabs__link{transition-delay:60ms}.md-tabs__item:nth-child(5) .md-tabs__link{transition-delay:80ms}.md-tabs__item:nth-child(6) .md-tabs__link{transition-delay:.1s}.md-tabs__item:nth-child(7) .md-tabs__link{transition-delay:.12s}.md-tabs__item:nth-child(8) .md-tabs__link{transition-delay:.14s}.md-tabs__item:nth-child(9) .md-tabs__link{transition-delay:.16s}.md-tabs__item:nth-child(10) .md-tabs__link{transition-delay:.18s}.md-tabs__item:nth-child(11) .md-tabs__link{transition-delay:.2s}.md-tabs__item:nth-child(12) .md-tabs__link{transition-delay:.22s}.md-tabs__item:nth-child(13) .md-tabs__link{transition-delay:.24s}.md-tabs__item:nth-child(14) .md-tabs__link{transition-delay:.26s}.md-tabs__item:nth-child(15) .md-tabs__link{transition-delay:.28s}.md-tabs__item:nth-child(16) .md-tabs__link{transition-delay:.3s}.md-tabs[hidden] .md-tabs__link{opacity:0;transform:translateY(50%);transition:transform 0ms .1s,opacity .1s}:root{--md-tag-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="m5.41 21 .71-4h-4l.35-2h4l1.06-6h-4l.35-2h4l.71-4h2l-.71 4h6l.71-4h2l-.71 4h4l-.35 2h-4l-1.06 6h4l-.35 2h-4l-.71 4h-2l.71-4h-6l-.71 4zM9.53 9l-1.06 6h6l1.06-6z"/></svg>')}.md-typeset .md-tags:not([hidden]){display:inline-flex;flex-wrap:wrap;gap:.5em;margin-bottom:.75em;margin-top:-.125em}.md-typeset .md-tag{align-items:center;background:var(--md-default-fg-color--lightest);border-radius:2.4rem;display:inline-flex;font-size:.64rem;font-size:min(.8em,.64rem);font-weight:700;gap:.5em;letter-spacing:normal;line-height:1.6;padding:.3125em .78125em}.md-typeset .md-tag[href]{-webkit-tap-highlight-color:transparent;color:inherit;outline:none;transition:color 125ms,background-color 125ms}.md-typeset .md-tag[href]:focus,.md-typeset .md-tag[href]:hover{background-color:var(--md-accent-fg-color);color:var(--md-accent-bg-color)}[id]>.md-typeset .md-tag{vertical-align:text-top}.md-typeset .md-tag-icon:before{background-color:var(--md-default-fg-color--lighter);content:"";display:inline-block;height:1.2em;-webkit-mask-image:var(--md-tag-icon);mask-image:var(--md-tag-icon);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;transition:background-color 125ms;vertical-align:text-bottom;width:1.2em}.md-typeset .md-tag-icon[href]:focus:before,.md-typeset .md-tag-icon[href]:hover:before{background-color:var(--md-accent-bg-color)}@keyframes pulse{0%{transform:scale(.95)}75%{transform:scale(1)}to{transform:scale(.95)}}:root{--md-annotation-bg-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 2A10 10 0 0 0 2 12a10 10 0 0 0 10 10 10 10 0 0 0 10-10A10 10 0 0 0 12 2"/></svg>');--md-annotation-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M17 13h-4v4h-2v-4H7v-2h4V7h2v4h4m-5-9A10 10 0 0 0 2 12a10 10 0 0 0 10 10 10 10 0 0 0 10-10A10 10 0 0 0 12 2"/></svg>')}.md-tooltip{-webkit-backface-visibility:hidden;backface-visibility:hidden;background-color:var(--md-default-bg-color);border-radius:.1rem;box-shadow:var(--md-shadow-z2);color:var(--md-default-fg-color);font-family:var(--md-text-font-family);left:clamp(var(--md-tooltip-0,0rem) + .8rem,var(--md-tooltip-x),100vw + var(--md-tooltip-0,0rem) + .8rem - var(--md-tooltip-width) - 2 * .8rem);max-width:calc(100vw - 1.6rem);opacity:0;position:absolute;top:var(--md-tooltip-y);transform:translateY(-.4rem);transition:transform 0ms .25s,opacity .25s,z-index .25s;width:var(--md-tooltip-width);z-index:0}.md-tooltip--active{opacity:1;transform:translateY(0);transition:transform .25s cubic-bezier(.1,.7,.1,1),opacity .25s,z-index 0ms;z-index:2}.md-tooltip--inline{font-weight:700;-webkit-user-select:none;user-select:none;width:auto}.md-tooltip--inline:not(.md-tooltip--active){transform:translateY(.2rem) scale(.9)}.md-tooltip--inline .md-tooltip__inner{font-size:.5rem;padding:.2rem .4rem}[hidden]+.md-tooltip--inline{display:none}.focus-visible>.md-tooltip,.md-tooltip:target{outline:var(--md-accent-fg-color) auto}.md-tooltip__inner{font-size:.64rem;padding:.8rem}.md-tooltip__inner.md-typeset>:first-child{margin-top:0}.md-tooltip__inner.md-typeset>:last-child{margin-bottom:0}.md-annotation{font-style:normal;font-weight:400;outline:none;text-align:initial;vertical-align:text-bottom;white-space:normal}[dir=rtl] .md-annotation{direction:rtl}code .md-annotation{font-family:var(--md-code-font-family);font-size:inherit}.md-annotation:not([hidden]){display:inline-block;line-height:1.25}.md-annotation__index{border-radius:.01px;cursor:pointer;display:inline-block;margin-left:.4ch;margin-right:.4ch;outline:none;overflow:hidden;position:relative;-webkit-user-select:none;user-select:none;vertical-align:text-top;z-index:0}.md-annotation .md-annotation__index{transition:z-index .25s}@media screen{.md-annotation__index{width:2.2ch}[data-md-visible]>.md-annotation__index{animation:pulse 2s infinite}.md-annotation__index:before{background:var(--md-default-bg-color);-webkit-mask-image:var(--md-annotation-bg-icon);mask-image:var(--md-annotation-bg-icon)}.md-annotation__index:after,.md-annotation__index:before{content:"";height:2.2ch;-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;position:absolute;top:-.1ch;width:2.2ch;z-index:-1}.md-annotation__index:after{background-color:var(--md-default-fg-color--lighter);-webkit-mask-image:var(--md-annotation-icon);mask-image:var(--md-annotation-icon);transform:scale(1.0001);transition:background-color .25s,transform .25s}.md-tooltip--active+.md-annotation__index:after{transform:rotate(45deg)}.md-tooltip--active+.md-annotation__index:after,:hover>.md-annotation__index:after{background-color:var(--md-accent-fg-color)}}.md-tooltip--active+.md-annotation__index{animation-play-state:paused;transition-duration:0ms;z-index:2}.md-annotation__index [data-md-annotation-id]{display:inline-block}@media print{.md-annotation__index [data-md-annotation-id]{background:var(--md-default-fg-color--lighter);border-radius:2ch;color:var(--md-default-bg-color);font-weight:700;padding:0 .6ch;white-space:nowrap}.md-annotation__index [data-md-annotation-id]:after{content:attr(data-md-annotation-id)}}.md-typeset .md-annotation-list{counter-reset:xxx;list-style:none}.md-typeset .md-annotation-list li{position:relative}[dir=ltr] .md-typeset .md-annotation-list li:before{left:-2.125em}[dir=rtl] .md-typeset .md-annotation-list li:before{right:-2.125em}.md-typeset .md-annotation-list li:before{background:var(--md-default-fg-color--lighter);border-radius:2ch;color:var(--md-default-bg-color);content:counter(xxx);counter-increment:xxx;font-size:.8875em;font-weight:700;height:2ch;line-height:1.25;min-width:2ch;padding:0 .6ch;position:absolute;text-align:center;top:.25em}:root{--md-tooltip-width:20rem;--md-tooltip-tail:0.3rem}.md-tooltip2{-webkit-backface-visibility:hidden;backface-visibility:hidden;color:var(--md-default-fg-color);font-family:var(--md-text-font-family);opacity:0;pointer-events:none;position:absolute;top:calc(var(--md-tooltip-host-y) + var(--md-tooltip-y));transform:translateY(-.4rem);transform-origin:calc(var(--md-tooltip-host-x) + var(--md-tooltip-x)) 0;transition:transform 0ms .25s,opacity .25s,z-index .25s;width:100%;z-index:0}.md-tooltip2:before{border-left:var(--md-tooltip-tail) solid #0000;border-right:var(--md-tooltip-tail) solid #0000;content:"";display:block;left:clamp(1.5 * .8rem,var(--md-tooltip-host-x) + var(--md-tooltip-x) - var(--md-tooltip-tail),100vw - 2 * var(--md-tooltip-tail) - 1.5 * .8rem);position:absolute;z-index:1}.md-tooltip2--top:before{border-top:var(--md-tooltip-tail) solid var(--md-default-bg-color);bottom:calc(var(--md-tooltip-tail)*-1 + .025rem);filter:drop-shadow(0 1px 0 hsla(0,0%,0%,.05))}.md-tooltip2--bottom:before{border-bottom:var(--md-tooltip-tail) solid var(--md-default-bg-color);filter:drop-shadow(0 -1px 0 hsla(0,0%,0%,.05));top:calc(var(--md-tooltip-tail)*-1 + .025rem)}.md-tooltip2--active{opacity:1;transform:translateY(0);transition:transform .4s cubic-bezier(0,1,.5,1),opacity .25s,z-index 0ms;z-index:2}.md-tooltip2__inner{scrollbar-gutter:stable;background-color:var(--md-default-bg-color);border-radius:.1rem;box-shadow:var(--md-shadow-z2);left:clamp(.8rem,var(--md-tooltip-host-x) - .8rem,100vw - var(--md-tooltip-width) - .8rem);max-height:40vh;max-width:calc(100vw - 1.6rem);position:relative;scrollbar-width:thin}.md-tooltip2__inner::-webkit-scrollbar{height:.2rem;width:.2rem}.md-tooltip2__inner::-webkit-scrollbar-thumb{background-color:var(--md-default-fg-color--lighter)}.md-tooltip2__inner::-webkit-scrollbar-thumb:hover{background-color:var(--md-accent-fg-color)}[role=tooltip]>.md-tooltip2__inner{font-size:.5rem;font-weight:700;left:clamp(.8rem,var(--md-tooltip-host-x) + var(--md-tooltip-x) - var(--md-tooltip-width)/2,100vw - var(--md-tooltip-width) - .8rem);max-width:min(100vw - 2 * .8rem,400px);padding:.2rem .4rem;-webkit-user-select:none;user-select:none;width:-moz-fit-content;width:fit-content}.md-tooltip2__inner.md-typeset>:first-child{margin-top:0}.md-tooltip2__inner.md-typeset>:last-child{margin-bottom:0}[dir=ltr] .md-top{margin-left:50%}[dir=rtl] .md-top{margin-right:50%}.md-top{background-color:var(--md-default-bg-color);border-radius:1.6rem;box-shadow:var(--md-shadow-z2);color:var(--md-default-fg-color--light);cursor:pointer;display:block;font-size:.7rem;outline:none;padding:.4rem .8rem;position:fixed;top:3.2rem;transform:translate(-50%);transition:color 125ms,background-color 125ms,transform 125ms cubic-bezier(.4,0,.2,1),opacity 125ms;z-index:2}@media print{.md-top{display:none}}[dir=rtl] .md-top{transform:translate(50%)}.md-top[hidden]{opacity:0;pointer-events:none;transform:translate(-50%,.2rem);transition-duration:0ms}[dir=rtl] .md-top[hidden]{transform:translate(50%,.2rem)}.md-top:focus,.md-top:hover{background-color:var(--md-accent-fg-color);color:var(--md-accent-bg-color)}.md-top svg{display:inline-block;vertical-align:-.5em}@keyframes hoverfix{0%{pointer-events:none}}:root{--md-version-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 320 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M137.4 374.6c12.5 12.5 32.8 12.5 45.3 0l128-128c9.2-9.2 11.9-22.9 6.9-34.9S301 191.9 288 191.9L32 192c-12.9 0-24.6 7.8-29.6 19.8s-2.2 25.7 6.9 34.9l128 128z"/></svg>')}.md-version{flex-shrink:0;font-size:.8rem;height:2.4rem}[dir=ltr] .md-version__current{margin-left:1.4rem;margin-right:.4rem}[dir=rtl] .md-version__current{margin-left:.4rem;margin-right:1.4rem}.md-version__current{color:inherit;cursor:pointer;outline:none;position:relative;top:.05rem}[dir=ltr] .md-version__current:after{margin-left:.4rem}[dir=rtl] .md-version__current:after{margin-right:.4rem}.md-version__current:after{background-color:currentcolor;content:"";display:inline-block;height:.6rem;-webkit-mask-image:var(--md-version-icon);mask-image:var(--md-version-icon);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;width:.4rem}.md-version__alias{margin-left:.3rem;opacity:.7}.md-version__list{background-color:var(--md-default-bg-color);border-radius:.1rem;box-shadow:var(--md-shadow-z2);color:var(--md-default-fg-color);list-style-type:none;margin:.2rem .8rem;max-height:0;opacity:0;overflow:auto;padding:0;position:absolute;scroll-snap-type:y mandatory;top:.15rem;transition:max-height 0ms .5s,opacity .25s .25s;z-index:3}.md-version:focus-within .md-version__list,.md-version:hover .md-version__list{max-height:10rem;opacity:1;transition:max-height 0ms,opacity .25s}@media (hover:none),(pointer:coarse){.md-version:hover .md-version__list{animation:hoverfix .25s forwards}.md-version:focus-within .md-version__list{animation:none}}.md-version__item{line-height:1.8rem}[dir=ltr] .md-version__link{padding-left:.6rem;padding-right:1.2rem}[dir=rtl] .md-version__link{padding-left:1.2rem;padding-right:.6rem}.md-version__link{cursor:pointer;display:block;outline:none;scroll-snap-align:start;transition:color .25s,background-color .25s;white-space:nowrap;width:100%}.md-version__link:focus,.md-version__link:hover{color:var(--md-accent-fg-color)}.md-version__link:focus{background-color:var(--md-default-fg-color--lightest)}:root{--md-admonition-icon--note:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 2C6.47 2 2 6.47 2 12s4.47 10 10 10 10-4.47 10-10S17.53 2 12 2m3.1 5.07c.14 0 .28.05.4.16l1.27 1.27c.23.22.23.57 0 .78l-1 1-2.05-2.05 1-1c.1-.11.24-.16.38-.16m-1.97 1.74 2.06 2.06-6.06 6.06H7.07v-2.06z"/></svg>');--md-admonition-icon--abstract:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M17 9H7V7h10m0 6H7v-2h10m-3 6H7v-2h7M12 3a1 1 0 0 1 1 1 1 1 0 0 1-1 1 1 1 0 0 1-1-1 1 1 0 0 1 1-1m7 0h-4.18C14.4 1.84 13.3 1 12 1s-2.4.84-2.82 2H5a2 2 0 0 0-2 2v14a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2V5a2 2 0 0 0-2-2"/></svg>');--md-admonition-icon--info:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M13 9h-2V7h2m0 10h-2v-6h2m-1-9A10 10 0 0 0 2 12a10 10 0 0 0 10 10 10 10 0 0 0 10-10A10 10 0 0 0 12 2"/></svg>');--md-admonition-icon--tip:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M17.66 11.2c-.23-.3-.51-.56-.77-.82-.67-.6-1.43-1.03-2.07-1.66C13.33 7.26 13 4.85 13.95 3c-.95.23-1.78.75-2.49 1.32-2.59 2.08-3.61 5.75-2.39 8.9.04.1.08.2.08.33 0 .22-.15.42-.35.5-.23.1-.47.04-.66-.12a.6.6 0 0 1-.14-.17c-1.13-1.43-1.31-3.48-.55-5.12C5.78 10 4.87 12.3 5 14.47c.06.5.12 1 .29 1.5.14.6.41 1.2.71 1.73 1.08 1.73 2.95 2.97 4.96 3.22 2.14.27 4.43-.12 6.07-1.6 1.83-1.66 2.47-4.32 1.53-6.6l-.13-.26c-.21-.46-.77-1.26-.77-1.26m-3.16 6.3c-.28.24-.74.5-1.1.6-1.12.4-2.24-.16-2.9-.82 1.19-.28 1.9-1.16 2.11-2.05.17-.8-.15-1.46-.28-2.23-.12-.74-.1-1.37.17-2.06.19.38.39.76.63 1.06.77 1 1.98 1.44 2.24 2.8.04.14.06.28.06.43.03.82-.33 1.72-.93 2.27"/></svg>');--md-admonition-icon--success:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M21 7 9 19l-5.5-5.5 1.41-1.41L9 16.17 19.59 5.59z"/></svg>');--md-admonition-icon--question:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="m15.07 11.25-.9.92C13.45 12.89 13 13.5 13 15h-2v-.5c0-1.11.45-2.11 1.17-2.83l1.24-1.26c.37-.36.59-.86.59-1.41a2 2 0 0 0-2-2 2 2 0 0 0-2 2H8a4 4 0 0 1 4-4 4 4 0 0 1 4 4 3.2 3.2 0 0 1-.93 2.25M13 19h-2v-2h2M12 2A10 10 0 0 0 2 12a10 10 0 0 0 10 10 10 10 0 0 0 10-10c0-5.53-4.5-10-10-10"/></svg>');--md-admonition-icon--warning:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M13 14h-2V9h2m0 9h-2v-2h2M1 21h22L12 2z"/></svg>');--md-admonition-icon--failure:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M19 6.41 17.59 5 12 10.59 6.41 5 5 6.41 10.59 12 5 17.59 6.41 19 12 13.41 17.59 19 19 17.59 13.41 12z"/></svg>');--md-admonition-icon--danger:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="m11.5 20 4.86-9.73H13V4l-5 9.73h3.5zM12 2c2.75 0 5.1 1 7.05 2.95S22 9.25 22 12s-1 5.1-2.95 7.05S14.75 22 12 22s-5.1-1-7.05-2.95S2 14.75 2 12s1-5.1 2.95-7.05S9.25 2 12 2"/></svg>');--md-admonition-icon--bug:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M11 13h2v1h-2zm10-8v6c0 5.5-3.8 10.7-9 12-5.2-1.3-9-6.5-9-12V5l9-4zm-4 5h-2.2c-.2-.6-.6-1.1-1.1-1.5l1.2-1.2-.7-.7L12.8 8H12c-.2 0-.5 0-.7.1L9.9 6.6l-.8.8 1.2 1.2c-.5.3-.9.8-1.1 1.4H7v1h2v1H7v1h2v1H7v1h2.2c.4 1.2 1.5 2 2.8 2s2.4-.8 2.8-2H17v-1h-2v-1h2v-1h-2v-1h2zm-6 2h2v-1h-2z"/></svg>');--md-admonition-icon--example:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M7 2v2h1v14a4 4 0 0 0 4 4 4 4 0 0 0 4-4V4h1V2zm4 14c-.6 0-1-.4-1-1s.4-1 1-1 1 .4 1 1-.4 1-1 1m2-4c-.6 0-1-.4-1-1s.4-1 1-1 1 .4 1 1-.4 1-1 1m1-5h-4V4h4z"/></svg>');--md-admonition-icon--quote:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M14 17h3l2-4V7h-6v6h3M6 17h3l2-4V7H5v6h3z"/></svg>')}.md-typeset .admonition,.md-typeset details{background-color:var(--md-admonition-bg-color);border:.075rem solid #448aff;border-radius:.2rem;box-shadow:var(--md-shadow-z1);color:var(--md-admonition-fg-color);display:flow-root;font-size:.64rem;margin:1.5625em 0;padding:0 .6rem;page-break-inside:avoid;transition:box-shadow 125ms}@media print{.md-typeset .admonition,.md-typeset details{box-shadow:none}}.md-typeset .admonition:focus-within,.md-typeset details:focus-within{box-shadow:0 0 0 .2rem #448aff1a}.md-typeset .admonition>*,.md-typeset details>*{box-sizing:border-box}.md-typeset .admonition .admonition,.md-typeset .admonition details,.md-typeset details .admonition,.md-typeset details details{margin-bottom:1em;margin-top:1em}.md-typeset .admonition .md-typeset__scrollwrap,.md-typeset details .md-typeset__scrollwrap{margin:1em -.6rem}.md-typeset .admonition .md-typeset__table,.md-typeset details .md-typeset__table{padding:0 .6rem}.md-typeset .admonition>.tabbed-set:only-child,.md-typeset details>.tabbed-set:only-child{margin-top:0}html .md-typeset .admonition>:last-child,html .md-typeset details>:last-child{margin-bottom:.6rem}[dir=ltr] .md-typeset .admonition-title,[dir=ltr] .md-typeset summary{padding-left:2rem;padding-right:.6rem}[dir=rtl] .md-typeset .admonition-title,[dir=rtl] .md-typeset summary{padding-left:.6rem;padding-right:2rem}[dir=ltr] .md-typeset .admonition-title,[dir=ltr] .md-typeset summary{border-left-width:.2rem}[dir=rtl] .md-typeset .admonition-title,[dir=rtl] .md-typeset summary{border-right-width:.2rem}[dir=ltr] .md-typeset .admonition-title,[dir=ltr] .md-typeset summary{border-top-left-radius:.1rem}[dir=ltr] .md-typeset .admonition-title,[dir=ltr] .md-typeset summary,[dir=rtl] .md-typeset .admonition-title,[dir=rtl] .md-typeset summary{border-top-right-radius:.1rem}[dir=rtl] .md-typeset .admonition-title,[dir=rtl] .md-typeset summary{border-top-left-radius:.1rem}.md-typeset .admonition-title,.md-typeset summary{background-color:#448aff1a;border:none;font-weight:700;margin:0 -.6rem;padding-bottom:.4rem;padding-top:.4rem;position:relative}html .md-typeset .admonition-title:last-child,html .md-typeset summary:last-child{margin-bottom:0}[dir=ltr] .md-typeset .admonition-title:before,[dir=ltr] .md-typeset summary:before{left:.6rem}[dir=rtl] .md-typeset .admonition-title:before,[dir=rtl] .md-typeset summary:before{right:.6rem}.md-typeset .admonition-title:before,.md-typeset summary:before{background-color:#448aff;content:"";height:1rem;-webkit-mask-image:var(--md-admonition-icon--note);mask-image:var(--md-admonition-icon--note);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;position:absolute;top:.625em;width:1rem}.md-typeset .admonition-title code,.md-typeset summary code{box-shadow:0 0 0 .05rem var(--md-default-fg-color--lightest)}.md-typeset .admonition.note,.md-typeset details.note{border-color:#448aff}.md-typeset .admonition.note:focus-within,.md-typeset details.note:focus-within{box-shadow:0 0 0 .2rem #448aff1a}.md-typeset .note>.admonition-title,.md-typeset .note>summary{background-color:#448aff1a}.md-typeset .note>.admonition-title:before,.md-typeset .note>summary:before{background-color:#448aff;-webkit-mask-image:var(--md-admonition-icon--note);mask-image:var(--md-admonition-icon--note)}.md-typeset .note>.admonition-title:after,.md-typeset .note>summary:after{color:#448aff}.md-typeset .admonition.abstract,.md-typeset details.abstract{border-color:#00b0ff}.md-typeset .admonition.abstract:focus-within,.md-typeset details.abstract:focus-within{box-shadow:0 0 0 .2rem #00b0ff1a}.md-typeset .abstract>.admonition-title,.md-typeset .abstract>summary{background-color:#00b0ff1a}.md-typeset .abstract>.admonition-title:before,.md-typeset .abstract>summary:before{background-color:#00b0ff;-webkit-mask-image:var(--md-admonition-icon--abstract);mask-image:var(--md-admonition-icon--abstract)}.md-typeset .abstract>.admonition-title:after,.md-typeset .abstract>summary:after{color:#00b0ff}.md-typeset .admonition.info,.md-typeset details.info{border-color:#00b8d4}.md-typeset .admonition.info:focus-within,.md-typeset details.info:focus-within{box-shadow:0 0 0 .2rem #00b8d41a}.md-typeset .info>.admonition-title,.md-typeset .info>summary{background-color:#00b8d41a}.md-typeset .info>.admonition-title:before,.md-typeset .info>summary:before{background-color:#00b8d4;-webkit-mask-image:var(--md-admonition-icon--info);mask-image:var(--md-admonition-icon--info)}.md-typeset .info>.admonition-title:after,.md-typeset .info>summary:after{color:#00b8d4}.md-typeset .admonition.tip,.md-typeset details.tip{border-color:#00bfa5}.md-typeset .admonition.tip:focus-within,.md-typeset details.tip:focus-within{box-shadow:0 0 0 .2rem #00bfa51a}.md-typeset .tip>.admonition-title,.md-typeset .tip>summary{background-color:#00bfa51a}.md-typeset .tip>.admonition-title:before,.md-typeset .tip>summary:before{background-color:#00bfa5;-webkit-mask-image:var(--md-admonition-icon--tip);mask-image:var(--md-admonition-icon--tip)}.md-typeset .tip>.admonition-title:after,.md-typeset .tip>summary:after{color:#00bfa5}.md-typeset .admonition.success,.md-typeset details.success{border-color:#00c853}.md-typeset .admonition.success:focus-within,.md-typeset details.success:focus-within{box-shadow:0 0 0 .2rem #00c8531a}.md-typeset .success>.admonition-title,.md-typeset .success>summary{background-color:#00c8531a}.md-typeset .success>.admonition-title:before,.md-typeset .success>summary:before{background-color:#00c853;-webkit-mask-image:var(--md-admonition-icon--success);mask-image:var(--md-admonition-icon--success)}.md-typeset .success>.admonition-title:after,.md-typeset .success>summary:after{color:#00c853}.md-typeset .admonition.question,.md-typeset details.question{border-color:#64dd17}.md-typeset .admonition.question:focus-within,.md-typeset details.question:focus-within{box-shadow:0 0 0 .2rem #64dd171a}.md-typeset .question>.admonition-title,.md-typeset .question>summary{background-color:#64dd171a}.md-typeset .question>.admonition-title:before,.md-typeset .question>summary:before{background-color:#64dd17;-webkit-mask-image:var(--md-admonition-icon--question);mask-image:var(--md-admonition-icon--question)}.md-typeset .question>.admonition-title:after,.md-typeset .question>summary:after{color:#64dd17}.md-typeset .admonition.warning,.md-typeset details.warning{border-color:#ff9100}.md-typeset .admonition.warning:focus-within,.md-typeset details.warning:focus-within{box-shadow:0 0 0 .2rem #ff91001a}.md-typeset .warning>.admonition-title,.md-typeset .warning>summary{background-color:#ff91001a}.md-typeset .warning>.admonition-title:before,.md-typeset .warning>summary:before{background-color:#ff9100;-webkit-mask-image:var(--md-admonition-icon--warning);mask-image:var(--md-admonition-icon--warning)}.md-typeset .warning>.admonition-title:after,.md-typeset .warning>summary:after{color:#ff9100}.md-typeset .admonition.failure,.md-typeset details.failure{border-color:#ff5252}.md-typeset .admonition.failure:focus-within,.md-typeset details.failure:focus-within{box-shadow:0 0 0 .2rem #ff52521a}.md-typeset .failure>.admonition-title,.md-typeset .failure>summary{background-color:#ff52521a}.md-typeset .failure>.admonition-title:before,.md-typeset .failure>summary:before{background-color:#ff5252;-webkit-mask-image:var(--md-admonition-icon--failure);mask-image:var(--md-admonition-icon--failure)}.md-typeset .failure>.admonition-title:after,.md-typeset .failure>summary:after{color:#ff5252}.md-typeset .admonition.danger,.md-typeset details.danger{border-color:#ff1744}.md-typeset .admonition.danger:focus-within,.md-typeset details.danger:focus-within{box-shadow:0 0 0 .2rem #ff17441a}.md-typeset .danger>.admonition-title,.md-typeset .danger>summary{background-color:#ff17441a}.md-typeset .danger>.admonition-title:before,.md-typeset .danger>summary:before{background-color:#ff1744;-webkit-mask-image:var(--md-admonition-icon--danger);mask-image:var(--md-admonition-icon--danger)}.md-typeset .danger>.admonition-title:after,.md-typeset .danger>summary:after{color:#ff1744}.md-typeset .admonition.bug,.md-typeset details.bug{border-color:#f50057}.md-typeset .admonition.bug:focus-within,.md-typeset details.bug:focus-within{box-shadow:0 0 0 .2rem #f500571a}.md-typeset .bug>.admonition-title,.md-typeset .bug>summary{background-color:#f500571a}.md-typeset .bug>.admonition-title:before,.md-typeset .bug>summary:before{background-color:#f50057;-webkit-mask-image:var(--md-admonition-icon--bug);mask-image:var(--md-admonition-icon--bug)}.md-typeset .bug>.admonition-title:after,.md-typeset .bug>summary:after{color:#f50057}.md-typeset .admonition.example,.md-typeset details.example{border-color:#7c4dff}.md-typeset .admonition.example:focus-within,.md-typeset details.example:focus-within{box-shadow:0 0 0 .2rem #7c4dff1a}.md-typeset .example>.admonition-title,.md-typeset .example>summary{background-color:#7c4dff1a}.md-typeset .example>.admonition-title:before,.md-typeset .example>summary:before{background-color:#7c4dff;-webkit-mask-image:var(--md-admonition-icon--example);mask-image:var(--md-admonition-icon--example)}.md-typeset .example>.admonition-title:after,.md-typeset .example>summary:after{color:#7c4dff}.md-typeset .admonition.quote,.md-typeset details.quote{border-color:#9e9e9e}.md-typeset .admonition.quote:focus-within,.md-typeset details.quote:focus-within{box-shadow:0 0 0 .2rem #9e9e9e1a}.md-typeset .quote>.admonition-title,.md-typeset .quote>summary{background-color:#9e9e9e1a}.md-typeset .quote>.admonition-title:before,.md-typeset .quote>summary:before{background-color:#9e9e9e;-webkit-mask-image:var(--md-admonition-icon--quote);mask-image:var(--md-admonition-icon--quote)}.md-typeset .quote>.admonition-title:after,.md-typeset .quote>summary:after{color:#9e9e9e}:root{--md-footnotes-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M19 7v4H5.83l3.58-3.59L8 6l-6 6 6 6 1.41-1.42L5.83 13H21V7z"/></svg>')}.md-typeset .footnote{color:var(--md-default-fg-color--light);font-size:.64rem}[dir=ltr] .md-typeset .footnote>ol{margin-left:0}[dir=rtl] .md-typeset .footnote>ol{margin-right:0}.md-typeset .footnote>ol>li{transition:color 125ms}.md-typeset .footnote>ol>li:target{color:var(--md-default-fg-color)}.md-typeset .footnote>ol>li:focus-within .footnote-backref{opacity:1;transform:translateX(0);transition:none}.md-typeset .footnote>ol>li:hover .footnote-backref,.md-typeset .footnote>ol>li:target .footnote-backref{opacity:1;transform:translateX(0)}.md-typeset .footnote>ol>li>:first-child{margin-top:0}.md-typeset .footnote-ref{font-size:.75em;font-weight:700}html .md-typeset .footnote-ref{outline-offset:.1rem}.md-typeset [id^="fnref:"]:target>.footnote-ref{outline:auto}.md-typeset .footnote-backref{color:var(--md-typeset-a-color);display:inline-block;font-size:0;opacity:0;transform:translateX(.25rem);transition:color .25s,transform .25s .25s,opacity 125ms .25s;vertical-align:text-bottom}@media print{.md-typeset .footnote-backref{color:var(--md-typeset-a-color);opacity:1;transform:translateX(0)}}[dir=rtl] .md-typeset .footnote-backref{transform:translateX(-.25rem)}.md-typeset .footnote-backref:hover{color:var(--md-accent-fg-color)}.md-typeset .footnote-backref:before{background-color:currentcolor;content:"";display:inline-block;height:.8rem;-webkit-mask-image:var(--md-footnotes-icon);mask-image:var(--md-footnotes-icon);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;width:.8rem}[dir=rtl] .md-typeset .footnote-backref:before svg{transform:scaleX(-1)}[dir=ltr] .md-typeset .headerlink{margin-left:.5rem}[dir=rtl] .md-typeset .headerlink{margin-right:.5rem}.md-typeset .headerlink{color:var(--md-default-fg-color--lighter);display:inline-block;opacity:0;transition:color .25s,opacity 125ms}@media print{.md-typeset .headerlink{display:none}}.md-typeset .headerlink:focus,.md-typeset :hover>.headerlink,.md-typeset :target>.headerlink{opacity:1;transition:color .25s,opacity 125ms}.md-typeset .headerlink:focus,.md-typeset .headerlink:hover,.md-typeset :target>.headerlink{color:var(--md-accent-fg-color)}.md-typeset :target{--md-scroll-margin:3.6rem;--md-scroll-offset:0rem;scroll-margin-top:calc(var(--md-scroll-margin) - var(--md-scroll-offset))}@media screen and (min-width:76.25em){.md-header--lifted~.md-container .md-typeset :target{--md-scroll-margin:6rem}}.md-typeset h1:target,.md-typeset h2:target,.md-typeset h3:target{--md-scroll-offset:0.2rem}.md-typeset h4:target{--md-scroll-offset:0.15rem}.md-typeset div.arithmatex{overflow:auto}@media screen and (max-width:44.984375em){.md-typeset div.arithmatex{margin:0 -.8rem}.md-typeset div.arithmatex>*{width:min-content}}.md-typeset div.arithmatex>*{margin-left:auto!important;margin-right:auto!important;padding:0 .8rem;touch-action:auto}.md-typeset div.arithmatex>* mjx-container{margin:0!important}.md-typeset div.arithmatex mjx-assistive-mml{height:0}.md-typeset del.critic{background-color:var(--md-typeset-del-color)}.md-typeset del.critic,.md-typeset ins.critic{-webkit-box-decoration-break:clone;box-decoration-break:clone}.md-typeset ins.critic{background-color:var(--md-typeset-ins-color)}.md-typeset .critic.comment{-webkit-box-decoration-break:clone;box-decoration-break:clone;color:var(--md-code-hl-comment-color)}.md-typeset .critic.comment:before{content:"/* "}.md-typeset .critic.comment:after{content:" */"}.md-typeset .critic.block{box-shadow:none;display:block;margin:1em 0;overflow:auto;padding-left:.8rem;padding-right:.8rem}.md-typeset .critic.block>:first-child{margin-top:.5em}.md-typeset .critic.block>:last-child{margin-bottom:.5em}:root{--md-details-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M8.59 16.58 13.17 12 8.59 7.41 10 6l6 6-6 6z"/></svg>')}.md-typeset details{display:flow-root;overflow:visible;padding-top:0}.md-typeset details[open]>summary:after{transform:rotate(90deg)}.md-typeset details:not([open]){box-shadow:none;padding-bottom:0}.md-typeset details:not([open])>summary{border-radius:.1rem}[dir=ltr] .md-typeset summary{padding-right:1.8rem}[dir=rtl] .md-typeset summary{padding-left:1.8rem}[dir=ltr] .md-typeset summary{border-top-left-radius:.1rem}[dir=ltr] .md-typeset summary,[dir=rtl] .md-typeset summary{border-top-right-radius:.1rem}[dir=rtl] .md-typeset summary{border-top-left-radius:.1rem}.md-typeset summary{cursor:pointer;display:block;min-height:1rem;overflow:hidden}.md-typeset summary.focus-visible{outline-color:var(--md-accent-fg-color);outline-offset:.2rem}.md-typeset summary:not(.focus-visible){-webkit-tap-highlight-color:transparent;outline:none}[dir=ltr] .md-typeset summary:after{right:.4rem}[dir=rtl] .md-typeset summary:after{left:.4rem}.md-typeset summary:after{background-color:currentcolor;content:"";height:1rem;-webkit-mask-image:var(--md-details-icon);mask-image:var(--md-details-icon);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;position:absolute;top:.625em;transform:rotate(0deg);transition:transform .25s;width:1rem}[dir=rtl] .md-typeset summary:after{transform:rotate(180deg)}.md-typeset summary::marker{display:none}.md-typeset summary::-webkit-details-marker{display:none}.md-typeset .emojione,.md-typeset .gemoji,.md-typeset .twemoji{--md-icon-size:1.125em;display:inline-flex;height:var(--md-icon-size);vertical-align:text-top}.md-typeset .emojione svg,.md-typeset .gemoji svg,.md-typeset .twemoji svg{fill:currentcolor;max-height:100%;width:var(--md-icon-size)}.md-typeset .lg,.md-typeset .xl,.md-typeset .xxl,.md-typeset .xxxl{vertical-align:text-bottom}.md-typeset .middle{vertical-align:middle}.md-typeset .lg{--md-icon-size:1.5em}.md-typeset .xl{--md-icon-size:2.25em}.md-typeset .xxl{--md-icon-size:3em}.md-typeset .xxxl{--md-icon-size:4em}.highlight .o,.highlight .ow{color:var(--md-code-hl-operator-color)}.highlight .p{color:var(--md-code-hl-punctuation-color)}.highlight .cpf,.highlight .l,.highlight .s,.highlight .s1,.highlight .s2,.highlight .sb,.highlight .sc,.highlight .si,.highlight .ss{color:var(--md-code-hl-string-color)}.highlight .cp,.highlight .se,.highlight .sh,.highlight .sr,.highlight .sx{color:var(--md-code-hl-special-color)}.highlight .il,.highlight .m,.highlight .mb,.highlight .mf,.highlight .mh,.highlight .mi,.highlight .mo{color:var(--md-code-hl-number-color)}.highlight .k,.highlight .kd,.highlight .kn,.highlight .kp,.highlight .kr,.highlight .kt{color:var(--md-code-hl-keyword-color)}.highlight .kc,.highlight .n{color:var(--md-code-hl-name-color)}.highlight .bp,.highlight .nb,.highlight .no{color:var(--md-code-hl-constant-color)}.highlight .nc,.highlight .ne,.highlight .nf,.highlight .nn{color:var(--md-code-hl-function-color)}.highlight .nd,.highlight .ni,.highlight .nl,.highlight .nt{color:var(--md-code-hl-keyword-color)}.highlight .c,.highlight .c1,.highlight .ch,.highlight .cm,.highlight .cs,.highlight .sd{color:var(--md-code-hl-comment-color)}.highlight .na,.highlight .nv,.highlight .vc,.highlight .vg,.highlight .vi{color:var(--md-code-hl-variable-color)}.highlight .ge,.highlight .gh,.highlight .go,.highlight .gp,.highlight .gr,.highlight .gs,.highlight .gt,.highlight .gu{color:var(--md-code-hl-generic-color)}.highlight .gd,.highlight .gi{border-radius:.1rem;margin:0 -.125em;padding:0 .125em}.highlight .gd{background-color:var(--md-typeset-del-color)}.highlight .gi{background-color:var(--md-typeset-ins-color)}.highlight .hll{background-color:var(--md-code-hl-color--light);box-shadow:2px 0 0 0 var(--md-code-hl-color) inset;display:block;margin:0 -1.1764705882em;padding:0 1.1764705882em}.highlight span.filename{background-color:var(--md-code-bg-color);border-bottom:.05rem solid var(--md-default-fg-color--lightest);border-top-left-radius:.1rem;border-top-right-radius:.1rem;display:flow-root;font-size:.85em;font-weight:700;margin-top:1em;padding:.6617647059em 1.1764705882em;position:relative}.highlight span.filename+pre{margin-top:0}.highlight span.filename+pre>code{border-top-left-radius:0;border-top-right-radius:0}.highlight [data-linenos]:before{background-color:var(--md-code-bg-color);box-shadow:-.05rem 0 var(--md-default-fg-color--lightest) inset;color:var(--md-default-fg-color--light);content:attr(data-linenos);float:left;left:-1.1764705882em;margin-left:-1.1764705882em;margin-right:1.1764705882em;padding-left:1.1764705882em;position:sticky;-webkit-user-select:none;user-select:none;z-index:3}.highlight code a[id]{position:absolute;visibility:hidden}.highlight code[data-md-copying]{display:initial}.highlight code[data-md-copying] .hll{display:contents}.highlight code[data-md-copying] .md-annotation{display:none}.highlighttable{display:flow-root}.highlighttable tbody,.highlighttable td{display:block;padding:0}.highlighttable tr{display:flex}.highlighttable pre{margin:0}.highlighttable th.filename{flex-grow:1;padding:0;text-align:left}.highlighttable th.filename span.filename{margin-top:0}.highlighttable .linenos{background-color:var(--md-code-bg-color);border-bottom-left-radius:.1rem;border-top-left-radius:.1rem;font-size:.85em;padding:.7720588235em 0 .7720588235em 1.1764705882em;-webkit-user-select:none;user-select:none}.highlighttable .linenodiv{box-shadow:-.05rem 0 var(--md-default-fg-color--lightest) inset;padding-right:.5882352941em}.highlighttable .linenodiv pre{color:var(--md-default-fg-color--light);text-align:right}.highlighttable .code{flex:1;min-width:0}.linenodiv a{color:inherit}.md-typeset .highlighttable{direction:ltr;margin:1em 0}.md-typeset .highlighttable>tbody>tr>.code>div>pre>code{border-bottom-left-radius:0;border-top-left-radius:0}.md-typeset .highlight+.result{border:.05rem solid var(--md-code-bg-color);border-bottom-left-radius:.1rem;border-bottom-right-radius:.1rem;border-top-width:.1rem;margin-top:-1.125em;overflow:visible;padding:0 1em}.md-typeset .highlight+.result:after{clear:both;content:"";display:block}@media screen and (max-width:44.984375em){.md-content__inner>.highlight{margin:1em -.8rem}.md-content__inner>.highlight>.filename,.md-content__inner>.highlight>.highlighttable>tbody>tr>.code>div>pre>code,.md-content__inner>.highlight>.highlighttable>tbody>tr>.filename span.filename,.md-content__inner>.highlight>.highlighttable>tbody>tr>.linenos,.md-content__inner>.highlight>pre>code{border-radius:0}.md-content__inner>.highlight+.result{border-left-width:0;border-radius:0;border-right-width:0;margin-left:-.8rem;margin-right:-.8rem}}.md-typeset .keys kbd:after,.md-typeset .keys kbd:before{-moz-osx-font-smoothing:initial;-webkit-font-smoothing:initial;color:inherit;margin:0;position:relative}.md-typeset .keys span{color:var(--md-default-fg-color--light);padding:0 .2em}.md-typeset .keys .key-alt:before,.md-typeset .keys .key-left-alt:before,.md-typeset .keys .key-right-alt:before{content:"⎇";padding-right:.4em}.md-typeset .keys .key-command:before,.md-typeset .keys .key-left-command:before,.md-typeset .keys .key-right-command:before{content:"⌘";padding-right:.4em}.md-typeset .keys .key-control:before,.md-typeset .keys .key-left-control:before,.md-typeset .keys .key-right-control:before{content:"⌃";padding-right:.4em}.md-typeset .keys .key-left-meta:before,.md-typeset .keys .key-meta:before,.md-typeset .keys .key-right-meta:before{content:"◆";padding-right:.4em}.md-typeset .keys .key-left-option:before,.md-typeset .keys .key-option:before,.md-typeset .keys .key-right-option:before{content:"⌥";padding-right:.4em}.md-typeset .keys .key-left-shift:before,.md-typeset .keys .key-right-shift:before,.md-typeset .keys .key-shift:before{content:"⇧";padding-right:.4em}.md-typeset .keys .key-left-super:before,.md-typeset .keys .key-right-super:before,.md-typeset .keys .key-super:before{content:"❖";padding-right:.4em}.md-typeset .keys .key-left-windows:before,.md-typeset .keys .key-right-windows:before,.md-typeset .keys .key-windows:before{content:"⊞";padding-right:.4em}.md-typeset .keys .key-arrow-down:before{content:"↓";padding-right:.4em}.md-typeset .keys .key-arrow-left:before{content:"←";padding-right:.4em}.md-typeset .keys .key-arrow-right:before{content:"→";padding-right:.4em}.md-typeset .keys .key-arrow-up:before{content:"↑";padding-right:.4em}.md-typeset .keys .key-backspace:before{content:"⌫";padding-right:.4em}.md-typeset .keys .key-backtab:before{content:"⇤";padding-right:.4em}.md-typeset .keys .key-caps-lock:before{content:"⇪";padding-right:.4em}.md-typeset .keys .key-clear:before{content:"⌧";padding-right:.4em}.md-typeset .keys .key-context-menu:before{content:"☰";padding-right:.4em}.md-typeset .keys .key-delete:before{content:"⌦";padding-right:.4em}.md-typeset .keys .key-eject:before{content:"⏏";padding-right:.4em}.md-typeset .keys .key-end:before{content:"⤓";padding-right:.4em}.md-typeset .keys .key-escape:before{content:"⎋";padding-right:.4em}.md-typeset .keys .key-home:before{content:"⤒";padding-right:.4em}.md-typeset .keys .key-insert:before{content:"⎀";padding-right:.4em}.md-typeset .keys .key-page-down:before{content:"⇟";padding-right:.4em}.md-typeset .keys .key-page-up:before{content:"⇞";padding-right:.4em}.md-typeset .keys .key-print-screen:before{content:"⎙";padding-right:.4em}.md-typeset .keys .key-tab:after{content:"⇥";padding-left:.4em}.md-typeset .keys .key-num-enter:after{content:"⌤";padding-left:.4em}.md-typeset .keys .key-enter:after{content:"⏎";padding-left:.4em}:root{--md-tabbed-icon--prev:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M15.41 16.58 10.83 12l4.58-4.59L14 6l-6 6 6 6z"/></svg>');--md-tabbed-icon--next:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M8.59 16.58 13.17 12 8.59 7.41 10 6l6 6-6 6z"/></svg>')}.md-typeset .tabbed-set{border-radius:.1rem;display:flex;flex-flow:column wrap;margin:1em 0;position:relative}.md-typeset .tabbed-set>input{height:0;opacity:0;position:absolute;width:0}.md-typeset .tabbed-set>input:target{--md-scroll-offset:0.625em}.md-typeset .tabbed-set>input.focus-visible~.tabbed-labels:before{background-color:var(--md-accent-fg-color)}.md-typeset .tabbed-labels{-ms-overflow-style:none;box-shadow:0 -.05rem var(--md-default-fg-color--lightest) inset;display:flex;max-width:100%;overflow:auto;scrollbar-width:none}@media print{.md-typeset .tabbed-labels{display:contents}}@media screen{.js .md-typeset .tabbed-labels{position:relative}.js .md-typeset .tabbed-labels:before{background:var(--md-default-fg-color);bottom:0;content:"";display:block;height:2px;left:0;position:absolute;transform:translateX(var(--md-indicator-x));transition:width 225ms,background-color .25s,transform .25s;transition-timing-function:cubic-bezier(.4,0,.2,1);width:var(--md-indicator-width)}}.md-typeset .tabbed-labels::-webkit-scrollbar{display:none}.md-typeset .tabbed-labels>label{border-bottom:.1rem solid #0000;border-radius:.1rem .1rem 0 0;color:var(--md-default-fg-color--light);cursor:pointer;flex-shrink:0;font-size:.64rem;font-weight:700;padding:.78125em 1.25em .625em;scroll-margin-inline-start:1rem;transition:background-color .25s,color .25s;white-space:nowrap;width:auto}@media print{.md-typeset .tabbed-labels>label:first-child{order:1}.md-typeset .tabbed-labels>label:nth-child(2){order:2}.md-typeset .tabbed-labels>label:nth-child(3){order:3}.md-typeset .tabbed-labels>label:nth-child(4){order:4}.md-typeset .tabbed-labels>label:nth-child(5){order:5}.md-typeset .tabbed-labels>label:nth-child(6){order:6}.md-typeset .tabbed-labels>label:nth-child(7){order:7}.md-typeset .tabbed-labels>label:nth-child(8){order:8}.md-typeset .tabbed-labels>label:nth-child(9){order:9}.md-typeset .tabbed-labels>label:nth-child(10){order:10}.md-typeset .tabbed-labels>label:nth-child(11){order:11}.md-typeset .tabbed-labels>label:nth-child(12){order:12}.md-typeset .tabbed-labels>label:nth-child(13){order:13}.md-typeset .tabbed-labels>label:nth-child(14){order:14}.md-typeset .tabbed-labels>label:nth-child(15){order:15}.md-typeset .tabbed-labels>label:nth-child(16){order:16}.md-typeset .tabbed-labels>label:nth-child(17){order:17}.md-typeset .tabbed-labels>label:nth-child(18){order:18}.md-typeset .tabbed-labels>label:nth-child(19){order:19}.md-typeset .tabbed-labels>label:nth-child(20){order:20}}.md-typeset .tabbed-labels>label:hover{color:var(--md-default-fg-color)}.md-typeset .tabbed-labels>label>[href]:first-child{color:inherit}.md-typeset .tabbed-labels--linked>label{padding:0}.md-typeset .tabbed-labels--linked>label>a{display:block;padding:.78125em 1.25em .625em}.md-typeset .tabbed-content{width:100%}@media print{.md-typeset .tabbed-content{display:contents}}.md-typeset .tabbed-block{display:none}@media print{.md-typeset .tabbed-block{display:block}.md-typeset .tabbed-block:first-child{order:1}.md-typeset .tabbed-block:nth-child(2){order:2}.md-typeset .tabbed-block:nth-child(3){order:3}.md-typeset .tabbed-block:nth-child(4){order:4}.md-typeset .tabbed-block:nth-child(5){order:5}.md-typeset .tabbed-block:nth-child(6){order:6}.md-typeset .tabbed-block:nth-child(7){order:7}.md-typeset .tabbed-block:nth-child(8){order:8}.md-typeset .tabbed-block:nth-child(9){order:9}.md-typeset .tabbed-block:nth-child(10){order:10}.md-typeset .tabbed-block:nth-child(11){order:11}.md-typeset .tabbed-block:nth-child(12){order:12}.md-typeset .tabbed-block:nth-child(13){order:13}.md-typeset .tabbed-block:nth-child(14){order:14}.md-typeset .tabbed-block:nth-child(15){order:15}.md-typeset .tabbed-block:nth-child(16){order:16}.md-typeset .tabbed-block:nth-child(17){order:17}.md-typeset .tabbed-block:nth-child(18){order:18}.md-typeset .tabbed-block:nth-child(19){order:19}.md-typeset .tabbed-block:nth-child(20){order:20}}.md-typeset .tabbed-block>.highlight:first-child>pre,.md-typeset .tabbed-block>pre:first-child{margin:0}.md-typeset .tabbed-block>.highlight:first-child>pre>code,.md-typeset .tabbed-block>pre:first-child>code{border-top-left-radius:0;border-top-right-radius:0}.md-typeset .tabbed-block>.highlight:first-child>.filename{border-top-left-radius:0;border-top-right-radius:0;margin:0}.md-typeset .tabbed-block>.highlight:first-child>.highlighttable{margin:0}.md-typeset .tabbed-block>.highlight:first-child>.highlighttable>tbody>tr>.filename span.filename,.md-typeset .tabbed-block>.highlight:first-child>.highlighttable>tbody>tr>.linenos{border-top-left-radius:0;border-top-right-radius:0;margin:0}.md-typeset .tabbed-block>.highlight:first-child>.highlighttable>tbody>tr>.code>div>pre>code{border-top-left-radius:0;border-top-right-radius:0}.md-typeset .tabbed-block>.highlight:first-child+.result{margin-top:-.125em}.md-typeset .tabbed-block>.tabbed-set{margin:0}.md-typeset .tabbed-button{align-self:center;border-radius:100%;color:var(--md-default-fg-color--light);cursor:pointer;display:block;height:.9rem;margin-top:.1rem;pointer-events:auto;transition:background-color .25s;width:.9rem}.md-typeset .tabbed-button:hover{background-color:var(--md-accent-fg-color--transparent);color:var(--md-accent-fg-color)}.md-typeset .tabbed-button:after{background-color:currentcolor;content:"";display:block;height:100%;-webkit-mask-image:var(--md-tabbed-icon--prev);mask-image:var(--md-tabbed-icon--prev);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;transition:background-color .25s,transform .25s;width:100%}.md-typeset .tabbed-control{background:linear-gradient(to right,var(--md-default-bg-color) 60%,#0000);display:flex;height:1.9rem;justify-content:start;pointer-events:none;position:absolute;transition:opacity 125ms;width:1.2rem}[dir=rtl] .md-typeset .tabbed-control{transform:rotate(180deg)}.md-typeset .tabbed-control[hidden]{opacity:0}.md-typeset .tabbed-control--next{background:linear-gradient(to left,var(--md-default-bg-color) 60%,#0000);justify-content:end;right:0}.md-typeset .tabbed-control--next .tabbed-button:after{-webkit-mask-image:var(--md-tabbed-icon--next);mask-image:var(--md-tabbed-icon--next)}@media screen and (max-width:44.984375em){[dir=ltr] .md-content__inner>.tabbed-set .tabbed-labels{padding-left:.8rem}[dir=rtl] .md-content__inner>.tabbed-set .tabbed-labels{padding-right:.8rem}.md-content__inner>.tabbed-set .tabbed-labels{margin:0 -.8rem;max-width:100vw;scroll-padding-inline-start:.8rem}[dir=ltr] .md-content__inner>.tabbed-set .tabbed-labels:after{padding-right:.8rem}[dir=rtl] .md-content__inner>.tabbed-set .tabbed-labels:after{padding-left:.8rem}.md-content__inner>.tabbed-set .tabbed-labels:after{content:""}[dir=ltr] .md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--prev{padding-left:.8rem}[dir=rtl] .md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--prev{padding-right:.8rem}[dir=ltr] .md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--prev{margin-left:-.8rem}[dir=rtl] .md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--prev{margin-right:-.8rem}.md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--prev{width:2rem}[dir=ltr] .md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--next{padding-right:.8rem}[dir=rtl] .md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--next{padding-left:.8rem}[dir=ltr] .md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--next{margin-right:-.8rem}[dir=rtl] .md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--next{margin-left:-.8rem}.md-content__inner>.tabbed-set .tabbed-labels~.tabbed-control--next{width:2rem}}@media screen{.md-typeset .tabbed-set>input:first-child:checked~.tabbed-labels>:first-child,.md-typeset .tabbed-set>input:nth-child(10):checked~.tabbed-labels>:nth-child(10),.md-typeset .tabbed-set>input:nth-child(11):checked~.tabbed-labels>:nth-child(11),.md-typeset .tabbed-set>input:nth-child(12):checked~.tabbed-labels>:nth-child(12),.md-typeset .tabbed-set>input:nth-child(13):checked~.tabbed-labels>:nth-child(13),.md-typeset .tabbed-set>input:nth-child(14):checked~.tabbed-labels>:nth-child(14),.md-typeset .tabbed-set>input:nth-child(15):checked~.tabbed-labels>:nth-child(15),.md-typeset .tabbed-set>input:nth-child(16):checked~.tabbed-labels>:nth-child(16),.md-typeset .tabbed-set>input:nth-child(17):checked~.tabbed-labels>:nth-child(17),.md-typeset .tabbed-set>input:nth-child(18):checked~.tabbed-labels>:nth-child(18),.md-typeset .tabbed-set>input:nth-child(19):checked~.tabbed-labels>:nth-child(19),.md-typeset .tabbed-set>input:nth-child(2):checked~.tabbed-labels>:nth-child(2),.md-typeset .tabbed-set>input:nth-child(20):checked~.tabbed-labels>:nth-child(20),.md-typeset .tabbed-set>input:nth-child(3):checked~.tabbed-labels>:nth-child(3),.md-typeset .tabbed-set>input:nth-child(4):checked~.tabbed-labels>:nth-child(4),.md-typeset .tabbed-set>input:nth-child(5):checked~.tabbed-labels>:nth-child(5),.md-typeset .tabbed-set>input:nth-child(6):checked~.tabbed-labels>:nth-child(6),.md-typeset .tabbed-set>input:nth-child(7):checked~.tabbed-labels>:nth-child(7),.md-typeset .tabbed-set>input:nth-child(8):checked~.tabbed-labels>:nth-child(8),.md-typeset .tabbed-set>input:nth-child(9):checked~.tabbed-labels>:nth-child(9){color:var(--md-default-fg-color)}.md-typeset .no-js .tabbed-set>input:first-child:checked~.tabbed-labels>:first-child,.md-typeset .no-js .tabbed-set>input:nth-child(10):checked~.tabbed-labels>:nth-child(10),.md-typeset .no-js .tabbed-set>input:nth-child(11):checked~.tabbed-labels>:nth-child(11),.md-typeset .no-js .tabbed-set>input:nth-child(12):checked~.tabbed-labels>:nth-child(12),.md-typeset .no-js .tabbed-set>input:nth-child(13):checked~.tabbed-labels>:nth-child(13),.md-typeset .no-js .tabbed-set>input:nth-child(14):checked~.tabbed-labels>:nth-child(14),.md-typeset .no-js .tabbed-set>input:nth-child(15):checked~.tabbed-labels>:nth-child(15),.md-typeset .no-js .tabbed-set>input:nth-child(16):checked~.tabbed-labels>:nth-child(16),.md-typeset .no-js .tabbed-set>input:nth-child(17):checked~.tabbed-labels>:nth-child(17),.md-typeset .no-js .tabbed-set>input:nth-child(18):checked~.tabbed-labels>:nth-child(18),.md-typeset .no-js .tabbed-set>input:nth-child(19):checked~.tabbed-labels>:nth-child(19),.md-typeset .no-js .tabbed-set>input:nth-child(2):checked~.tabbed-labels>:nth-child(2),.md-typeset .no-js .tabbed-set>input:nth-child(20):checked~.tabbed-labels>:nth-child(20),.md-typeset .no-js .tabbed-set>input:nth-child(3):checked~.tabbed-labels>:nth-child(3),.md-typeset .no-js .tabbed-set>input:nth-child(4):checked~.tabbed-labels>:nth-child(4),.md-typeset .no-js .tabbed-set>input:nth-child(5):checked~.tabbed-labels>:nth-child(5),.md-typeset .no-js .tabbed-set>input:nth-child(6):checked~.tabbed-labels>:nth-child(6),.md-typeset .no-js .tabbed-set>input:nth-child(7):checked~.tabbed-labels>:nth-child(7),.md-typeset .no-js .tabbed-set>input:nth-child(8):checked~.tabbed-labels>:nth-child(8),.md-typeset .no-js .tabbed-set>input:nth-child(9):checked~.tabbed-labels>:nth-child(9),.no-js .md-typeset .tabbed-set>input:first-child:checked~.tabbed-labels>:first-child,.no-js .md-typeset .tabbed-set>input:nth-child(10):checked~.tabbed-labels>:nth-child(10),.no-js .md-typeset .tabbed-set>input:nth-child(11):checked~.tabbed-labels>:nth-child(11),.no-js .md-typeset .tabbed-set>input:nth-child(12):checked~.tabbed-labels>:nth-child(12),.no-js .md-typeset .tabbed-set>input:nth-child(13):checked~.tabbed-labels>:nth-child(13),.no-js .md-typeset .tabbed-set>input:nth-child(14):checked~.tabbed-labels>:nth-child(14),.no-js .md-typeset .tabbed-set>input:nth-child(15):checked~.tabbed-labels>:nth-child(15),.no-js .md-typeset .tabbed-set>input:nth-child(16):checked~.tabbed-labels>:nth-child(16),.no-js .md-typeset .tabbed-set>input:nth-child(17):checked~.tabbed-labels>:nth-child(17),.no-js .md-typeset .tabbed-set>input:nth-child(18):checked~.tabbed-labels>:nth-child(18),.no-js .md-typeset .tabbed-set>input:nth-child(19):checked~.tabbed-labels>:nth-child(19),.no-js .md-typeset .tabbed-set>input:nth-child(2):checked~.tabbed-labels>:nth-child(2),.no-js .md-typeset .tabbed-set>input:nth-child(20):checked~.tabbed-labels>:nth-child(20),.no-js .md-typeset .tabbed-set>input:nth-child(3):checked~.tabbed-labels>:nth-child(3),.no-js .md-typeset .tabbed-set>input:nth-child(4):checked~.tabbed-labels>:nth-child(4),.no-js .md-typeset .tabbed-set>input:nth-child(5):checked~.tabbed-labels>:nth-child(5),.no-js .md-typeset .tabbed-set>input:nth-child(6):checked~.tabbed-labels>:nth-child(6),.no-js .md-typeset .tabbed-set>input:nth-child(7):checked~.tabbed-labels>:nth-child(7),.no-js .md-typeset .tabbed-set>input:nth-child(8):checked~.tabbed-labels>:nth-child(8),.no-js .md-typeset .tabbed-set>input:nth-child(9):checked~.tabbed-labels>:nth-child(9){border-color:var(--md-default-fg-color)}}.md-typeset .tabbed-set>input:first-child.focus-visible~.tabbed-labels>:first-child,.md-typeset .tabbed-set>input:nth-child(10).focus-visible~.tabbed-labels>:nth-child(10),.md-typeset .tabbed-set>input:nth-child(11).focus-visible~.tabbed-labels>:nth-child(11),.md-typeset .tabbed-set>input:nth-child(12).focus-visible~.tabbed-labels>:nth-child(12),.md-typeset .tabbed-set>input:nth-child(13).focus-visible~.tabbed-labels>:nth-child(13),.md-typeset .tabbed-set>input:nth-child(14).focus-visible~.tabbed-labels>:nth-child(14),.md-typeset .tabbed-set>input:nth-child(15).focus-visible~.tabbed-labels>:nth-child(15),.md-typeset .tabbed-set>input:nth-child(16).focus-visible~.tabbed-labels>:nth-child(16),.md-typeset .tabbed-set>input:nth-child(17).focus-visible~.tabbed-labels>:nth-child(17),.md-typeset .tabbed-set>input:nth-child(18).focus-visible~.tabbed-labels>:nth-child(18),.md-typeset .tabbed-set>input:nth-child(19).focus-visible~.tabbed-labels>:nth-child(19),.md-typeset .tabbed-set>input:nth-child(2).focus-visible~.tabbed-labels>:nth-child(2),.md-typeset .tabbed-set>input:nth-child(20).focus-visible~.tabbed-labels>:nth-child(20),.md-typeset .tabbed-set>input:nth-child(3).focus-visible~.tabbed-labels>:nth-child(3),.md-typeset .tabbed-set>input:nth-child(4).focus-visible~.tabbed-labels>:nth-child(4),.md-typeset .tabbed-set>input:nth-child(5).focus-visible~.tabbed-labels>:nth-child(5),.md-typeset .tabbed-set>input:nth-child(6).focus-visible~.tabbed-labels>:nth-child(6),.md-typeset .tabbed-set>input:nth-child(7).focus-visible~.tabbed-labels>:nth-child(7),.md-typeset .tabbed-set>input:nth-child(8).focus-visible~.tabbed-labels>:nth-child(8),.md-typeset .tabbed-set>input:nth-child(9).focus-visible~.tabbed-labels>:nth-child(9){color:var(--md-accent-fg-color)}.md-typeset .tabbed-set>input:first-child:checked~.tabbed-content>:first-child,.md-typeset .tabbed-set>input:nth-child(10):checked~.tabbed-content>:nth-child(10),.md-typeset .tabbed-set>input:nth-child(11):checked~.tabbed-content>:nth-child(11),.md-typeset .tabbed-set>input:nth-child(12):checked~.tabbed-content>:nth-child(12),.md-typeset .tabbed-set>input:nth-child(13):checked~.tabbed-content>:nth-child(13),.md-typeset .tabbed-set>input:nth-child(14):checked~.tabbed-content>:nth-child(14),.md-typeset .tabbed-set>input:nth-child(15):checked~.tabbed-content>:nth-child(15),.md-typeset .tabbed-set>input:nth-child(16):checked~.tabbed-content>:nth-child(16),.md-typeset .tabbed-set>input:nth-child(17):checked~.tabbed-content>:nth-child(17),.md-typeset .tabbed-set>input:nth-child(18):checked~.tabbed-content>:nth-child(18),.md-typeset .tabbed-set>input:nth-child(19):checked~.tabbed-content>:nth-child(19),.md-typeset .tabbed-set>input:nth-child(2):checked~.tabbed-content>:nth-child(2),.md-typeset .tabbed-set>input:nth-child(20):checked~.tabbed-content>:nth-child(20),.md-typeset .tabbed-set>input:nth-child(3):checked~.tabbed-content>:nth-child(3),.md-typeset .tabbed-set>input:nth-child(4):checked~.tabbed-content>:nth-child(4),.md-typeset .tabbed-set>input:nth-child(5):checked~.tabbed-content>:nth-child(5),.md-typeset .tabbed-set>input:nth-child(6):checked~.tabbed-content>:nth-child(6),.md-typeset .tabbed-set>input:nth-child(7):checked~.tabbed-content>:nth-child(7),.md-typeset .tabbed-set>input:nth-child(8):checked~.tabbed-content>:nth-child(8),.md-typeset .tabbed-set>input:nth-child(9):checked~.tabbed-content>:nth-child(9){display:block}:root{--md-tasklist-icon:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M1 12C1 5.925 5.925 1 12 1s11 4.925 11 11-4.925 11-11 11S1 18.075 1 12m16.28-2.72a.75.75 0 0 0-.018-1.042.75.75 0 0 0-1.042-.018l-5.97 5.97-2.47-2.47a.75.75 0 0 0-1.042.018.75.75 0 0 0-.018 1.042l3 3a.75.75 0 0 0 1.06 0Z"/></svg>');--md-tasklist-icon--checked:url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M1 12C1 5.925 5.925 1 12 1s11 4.925 11 11-4.925 11-11 11S1 18.075 1 12m16.28-2.72a.75.75 0 0 0-.018-1.042.75.75 0 0 0-1.042-.018l-5.97 5.97-2.47-2.47a.75.75 0 0 0-1.042.018.75.75 0 0 0-.018 1.042l3 3a.75.75 0 0 0 1.06 0Z"/></svg>')}.md-typeset .task-list-item{list-style-type:none;position:relative}[dir=ltr] .md-typeset .task-list-item [type=checkbox]{left:-2em}[dir=rtl] .md-typeset .task-list-item [type=checkbox]{right:-2em}.md-typeset .task-list-item [type=checkbox]{position:absolute;top:.45em}.md-typeset .task-list-control [type=checkbox]{opacity:0;z-index:-1}[dir=ltr] .md-typeset .task-list-indicator:before{left:-1.5em}[dir=rtl] .md-typeset .task-list-indicator:before{right:-1.5em}.md-typeset .task-list-indicator:before{background-color:var(--md-default-fg-color--lightest);content:"";height:1.25em;-webkit-mask-image:var(--md-tasklist-icon);mask-image:var(--md-tasklist-icon);-webkit-mask-position:center;mask-position:center;-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:contain;mask-size:contain;position:absolute;top:.15em;width:1.25em}.md-typeset [type=checkbox]:checked+.task-list-indicator:before{background-color:#00e676;-webkit-mask-image:var(--md-tasklist-icon--checked);mask-image:var(--md-tasklist-icon--checked)}:root>*{--md-mermaid-font-family:var(--md-text-font-family),sans-serif;--md-mermaid-edge-color:var(--md-code-fg-color);--md-mermaid-node-bg-color:var(--md-accent-fg-color--transparent);--md-mermaid-node-fg-color:var(--md-accent-fg-color);--md-mermaid-label-bg-color:var(--md-default-bg-color);--md-mermaid-label-fg-color:var(--md-code-fg-color);--md-mermaid-sequence-actor-bg-color:var(--md-mermaid-label-bg-color);--md-mermaid-sequence-actor-fg-color:var(--md-mermaid-label-fg-color);--md-mermaid-sequence-actor-border-color:var(--md-mermaid-node-fg-color);--md-mermaid-sequence-actor-line-color:var(--md-default-fg-color--lighter);--md-mermaid-sequence-actorman-bg-color:var(--md-mermaid-label-bg-color);--md-mermaid-sequence-actorman-line-color:var(--md-mermaid-node-fg-color);--md-mermaid-sequence-box-bg-color:var(--md-mermaid-node-bg-color);--md-mermaid-sequence-box-fg-color:var(--md-mermaid-edge-color);--md-mermaid-sequence-label-bg-color:var(--md-mermaid-node-bg-color);--md-mermaid-sequence-label-fg-color:var(--md-mermaid-node-fg-color);--md-mermaid-sequence-loop-bg-color:var(--md-mermaid-node-bg-color);--md-mermaid-sequence-loop-fg-color:var(--md-mermaid-edge-color);--md-mermaid-sequence-loop-border-color:var(--md-mermaid-node-fg-color);--md-mermaid-sequence-message-fg-color:var(--md-mermaid-edge-color);--md-mermaid-sequence-message-line-color:var(--md-mermaid-edge-color);--md-mermaid-sequence-note-bg-color:var(--md-mermaid-label-bg-color);--md-mermaid-sequence-note-fg-color:var(--md-mermaid-edge-color);--md-mermaid-sequence-note-border-color:var(--md-mermaid-label-fg-color);--md-mermaid-sequence-number-bg-color:var(--md-mermaid-node-fg-color);--md-mermaid-sequence-number-fg-color:var(--md-accent-bg-color)}.mermaid{line-height:normal;margin:1em 0}.md-typeset .grid{grid-gap:.4rem;display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,16rem),1fr));margin:1em 0}.md-typeset .grid.cards>ol,.md-typeset .grid.cards>ul{display:contents}.md-typeset .grid.cards>ol>li,.md-typeset .grid.cards>ul>li,.md-typeset .grid>.card{border:.05rem solid var(--md-default-fg-color--lightest);border-radius:.1rem;display:block;margin:0;padding:.8rem;transition:border .25s,box-shadow .25s}.md-typeset .grid.cards>ol>li:focus-within,.md-typeset .grid.cards>ol>li:hover,.md-typeset .grid.cards>ul>li:focus-within,.md-typeset .grid.cards>ul>li:hover,.md-typeset .grid>.card:focus-within,.md-typeset .grid>.card:hover{border-color:#0000;box-shadow:var(--md-shadow-z2)}.md-typeset .grid.cards>ol>li>hr,.md-typeset .grid.cards>ul>li>hr,.md-typeset .grid>.card>hr{margin-bottom:1em;margin-top:1em}.md-typeset .grid.cards>ol>li>:first-child,.md-typeset .grid.cards>ul>li>:first-child,.md-typeset .grid>.card>:first-child{margin-top:0}.md-typeset .grid.cards>ol>li>:last-child,.md-typeset .grid.cards>ul>li>:last-child,.md-typeset .grid>.card>:last-child{margin-bottom:0}.md-typeset .grid>*,.md-typeset .grid>.admonition,.md-typeset .grid>.highlight>*,.md-typeset .grid>.highlighttable,.md-typeset .grid>.md-typeset details,.md-typeset .grid>details,.md-typeset .grid>pre{margin-bottom:0;margin-top:0}.md-typeset .grid>.highlight>pre:only-child,.md-typeset .grid>.highlight>pre>code,.md-typeset .grid>.highlighttable,.md-typeset .grid>.highlighttable>tbody,.md-typeset .grid>.highlighttable>tbody>tr,.md-typeset .grid>.highlighttable>tbody>tr>.code,.md-typeset .grid>.highlighttable>tbody>tr>.code>.highlight,.md-typeset .grid>.highlighttable>tbody>tr>.code>.highlight>pre,.md-typeset .grid>.highlighttable>tbody>tr>.code>.highlight>pre>code{height:100%}.md-typeset .grid>.tabbed-set{margin-bottom:0;margin-top:0}@media screen and (min-width:45em){[dir=ltr] .md-typeset .inline{float:left}[dir=rtl] .md-typeset .inline{float:right}[dir=ltr] .md-typeset .inline{margin-right:.8rem}[dir=rtl] .md-typeset .inline{margin-left:.8rem}.md-typeset .inline{margin-bottom:.8rem;margin-top:0;width:11.7rem}[dir=ltr] .md-typeset .inline.end{float:right}[dir=rtl] .md-typeset .inline.end{float:left}[dir=ltr] .md-typeset .inline.end{margin-left:.8rem;margin-right:0}[dir=rtl] .md-typeset .inline.end{margin-left:0;margin-right:.8rem}}
\ No newline at end of file
diff --git a/main/assets/stylesheets/main.8c3ca2c6.min.css.map b/main/assets/stylesheets/main.8c3ca2c6.min.css.map
deleted file mode 100644
index bc43a98c6..000000000
--- a/main/assets/stylesheets/main.8c3ca2c6.min.css.map
+++ /dev/null
@@ -1 +0,0 @@
-{"version":3,"sources":["src/templates/assets/stylesheets/main/components/_meta.scss","../../../../src/templates/assets/stylesheets/main.scss","src/templates/assets/stylesheets/main/_resets.scss","src/templates/assets/stylesheets/main/_colors.scss","src/templates/assets/stylesheets/main/_icons.scss","src/templates/assets/stylesheets/main/_typeset.scss","src/templates/assets/stylesheets/utilities/_break.scss","src/templates/assets/stylesheets/main/components/_author.scss","src/templates/assets/stylesheets/main/components/_banner.scss","src/templates/assets/stylesheets/main/components/_base.scss","src/templates/assets/stylesheets/main/components/_clipboard.scss","src/templates/assets/stylesheets/main/components/_code.scss","src/templates/assets/stylesheets/main/components/_consent.scss","src/templates/assets/stylesheets/main/components/_content.scss","src/templates/assets/stylesheets/main/components/_dialog.scss","src/templates/assets/stylesheets/main/components/_feedback.scss","src/templates/assets/stylesheets/main/components/_footer.scss","src/templates/assets/stylesheets/main/components/_form.scss","src/templates/assets/stylesheets/main/components/_header.scss","node_modules/material-design-color/material-color.scss","src/templates/assets/stylesheets/main/components/_nav.scss","src/templates/assets/stylesheets/main/components/_pagination.scss","src/templates/assets/stylesheets/main/components/_post.scss","src/templates/assets/stylesheets/main/components/_progress.scss","src/templates/assets/stylesheets/main/components/_search.scss","src/templates/assets/stylesheets/main/components/_select.scss","src/templates/assets/stylesheets/main/components/_sidebar.scss","src/templates/assets/stylesheets/main/components/_source.scss","src/templates/assets/stylesheets/main/components/_status.scss","src/templates/assets/stylesheets/main/components/_tabs.scss","src/templates/assets/stylesheets/main/components/_tag.scss","src/templates/assets/stylesheets/main/components/_tooltip.scss","src/templates/assets/stylesheets/main/components/_tooltip2.scss","src/templates/assets/stylesheets/main/components/_top.scss","src/templates/assets/stylesheets/main/components/_version.scss","src/templates/assets/stylesheets/main/extensions/markdown/_admonition.scss","src/templates/assets/stylesheets/main/extensions/markdown/_footnotes.scss","src/templates/assets/stylesheets/main/extensions/markdown/_toc.scss","src/templates/assets/stylesheets/main/extensions/pymdownx/_arithmatex.scss","src/templates/assets/stylesheets/main/extensions/pymdownx/_critic.scss","src/templates/assets/stylesheets/main/extensions/pymdownx/_details.scss","src/templates/assets/stylesheets/main/extensions/pymdownx/_emoji.scss","src/templates/assets/stylesheets/main/extensions/pymdownx/_highlight.scss","src/templates/assets/stylesheets/main/extensions/pymdownx/_keys.scss","src/templates/assets/stylesheets/main/extensions/pymdownx/_tabbed.scss","src/templates/assets/stylesheets/main/extensions/pymdownx/_tasklist.scss","src/templates/assets/stylesheets/main/integrations/_mermaid.scss","src/templates/assets/stylesheets/main/modifiers/_grid.scss","src/templates/assets/stylesheets/main/modifiers/_inline.scss"],"names":[],"mappings":"AA0CE,gBCoyCF,CClzCA,KAEE,6BAAA,CAAA,0BAAA,CAAA,qBAAA,CADA,qBDzBF,CC8BA,iBAGE,kBD3BF,CC8BE,gCANF,iBAOI,yBDzBF,CACF,CC6BA,KACE,QD1BF,CC8BA,qBAIE,uCD3BF,CC+BA,EACE,aAAA,CACA,oBD5BF,CCgCA,GAME,QAAA,CALA,kBAAA,CACA,aAAA,CACA,aAAA,CAEA,gBAAA,CADA,SD3BF,CCiCA,MACE,aD9BF,CCkCA,QAEE,eD/BF,CCmCA,IACE,iBDhCF,CCoCA,MAEE,uBAAA,CADA,gBDhCF,CCqCA,MAEE,eAAA,CACA,kBDlCF,CCsCA,OAKE,gBAAA,CACA,QAAA,CAHA,mBAAA,CACA,iBAAA,CAFA,QAAA,CADA,SD9BF,CCuCA,MACE,QAAA,CACA,YDpCF,CErDA,MAIE,6BAAA,CACA,oCAAA,CACA,mCAAA,CACA,0BAAA,CACA,sCAAA,CAGA,4BAAA,CACA,2CAAA,CACA,yBAAA,CACA,qCFmDF,CE7CA,+BAIE,kBF6CF,CE1CE,oHAEE,YF4CJ,CEnCA,qCAIE,eAAA,CAGA,+BAAA,CACA,sCAAA,CACA,wCAAA,CACA,yCAAA,CACA,0BAAA,CACA,sCAAA,CACA,wCAAA,CACA,yCAAA,CAGA,0BAAA,CACA,0BAAA,CAGA,0BAAA,CACA,mCAAA,CAGA,iCAAA,CACA,kCAAA,CACA,mCAAA,CACA,mCAAA,CACA,kCAAA,CACA,iCAAA,CACA,+CAAA,CACA,6DAAA,CACA,gEAAA,CACA,4DAAA,CACA,4DAAA,CACA,6DAAA,CAGA,6CAAA,CAGA,+CAAA,CAGA,gCAAA,CACA,gCAAA,CAGA,8BAAA,CACA,kCAAA,CACA,qCAAA,CAGA,iCAAA,CAGA,kCAAA,CACA,gDAAA,CAGA,mDAAA,CACA,mDAAA,CAGA,+BAAA,CACA,0BAAA,CAGA,yBAAA,CACA,qCAAA,CACA,uCAAA,CACA,8BAAA,CACA,oCAAA,CAGA,8DAAA,CAKA,8DAAA,CAKA,0DFKF,CG9HE,aAIE,iBAAA,CAHA,aAAA,CAEA,aAAA,CADA,YHmIJ,CIxIA,KACE,kCAAA,CACA,iCAAA,CAGA,uGAAA,CAKA,mFJyIF,CInIA,iBAIE,mCAAA,CACA,6BAAA,CAFA,sCJwIF,CIlIA,aAIE,4BAAA,CADA,sCJsIF,CI7HA,MACE,wNAAA,CACA,gNAAA,CACA,iNJgIF,CIzHA,YAGE,gCAAA,CAAA,kBAAA,CAFA,eAAA,CACA,eJ6HF,CIxHE,aAPF,YAQI,gBJ2HF,CACF,CIxHE,uGAME,iBAAA,CAAA,cJ0HJ,CItHE,eAKE,uCAAA,CAHA,aAAA,CAEA,eAAA,CAHA,iBJ6HJ,CIpHE,8BAPE,eAAA,CAGA,qBJ+HJ,CI3HE,eAEE,kBAAA,CAEA,eAAA,CAHA,oBJ0HJ,CIlHE,eAEE,gBAAA,CACA,eAAA,CAEA,qBAAA,CADA,eAAA,CAHA,mBJwHJ,CIhHE,kBACE,eJkHJ,CI9GE,eAEE,eAAA,CACA,qBAAA,CAFA,YJkHJ,CI5GE,8BAKE,uCAAA,CAFA,cAAA,CACA,eAAA,CAEA,qBAAA,CAJA,eJkHJ,CI1GE,eACE,wBJ4GJ,CIxGE,eAGE,+DAAA,CAFA,iBAAA,CACA,cJ2GJ,CItGE,cACE,+BAAA,CACA,qBJwGJ,CIrGI,mCAEE,sBJsGN,CIlGI,wCACE,+BJoGN,CIjGM,kDACE,uDJmGR,CI9FI,mBACE,kBAAA,CACA,iCJgGN,CI5FI,4BACE,uCAAA,CACA,oBJ8FN,CIzFE,iDAIE,6BAAA,CACA,aAAA,CAFA,2BJ6FJ,CIxFI,aARF,iDASI,oBJ6FJ,CACF,CIzFE,iBAIE,wCAAA,CACA,mBAAA,CACA,kCAAA,CAAA,0BAAA,CAJA,eAAA,CADA,uBAAA,CAEA,qBJ8FJ,CIxFI,qCAEE,uCAAA,CADA,YJ2FN,CIrFE,gBAEE,iBAAA,CACA,eAAA,CAFA,iBJyFJ,CIpFI,qBAWE,kCAAA,CAAA,0BAAA,CADA,eAAA,CATA,aAAA,CAEA,QAAA,CAMA,uCAAA,CALA,aAAA,CAFA,oCAAA,CAKA,yDAAA,CACA,oBAAA,CAFA,iBAAA,CADA,iBJ4FN,CInFM,2BACE,+CJqFR,CIjFM,wCAEE,YAAA,CADA,WJoFR,CI/EM,8CACE,oDJiFR,CI9EQ,oDACE,0CJgFV,CIzEE,gBAOE,4CAAA,CACA,mBAAA,CACA,mKACE,CANF,gCAAA,CAHA,oBAAA,CAEA,eAAA,CADA,uBAAA,CAIA,uBAAA,CADA,qBJ+EJ,CIpEE,iBAGE,6CAAA,CACA,kCAAA,CAAA,0BAAA,CAHA,aAAA,CACA,qBJwEJ,CIlEE,iBAGE,6DAAA,CADA,WAAA,CADA,oBJsEJ,CIhEE,kBACE,WJkEJ,CI9DE,oDAEE,qBJgEJ,CIlEE,oDAEE,sBJgEJ,CI5DE,iCACE,kBJiEJ,CIlEE,iCACE,mBJiEJ,CIlEE,iCAIE,2DJ8DJ,CIlEE,iCAIE,4DJ8DJ,CIlEE,uBAGE,uCAAA,CADA,aAAA,CAAA,cJgEJ,CI1DE,eACE,oBJ4DJ,CIxDI,qBACE,4BJ0DN,CIrDE,kDAGE,kBJuDJ,CI1DE,kDAGE,mBJuDJ,CI1DE,8BAEE,SJwDJ,CIpDI,0DACE,iBJuDN,CInDI,oCACE,2BJsDN,CInDM,0CACE,2BJsDR,CInDQ,gDACE,2BJsDV,CInDU,sDACE,2BJsDZ,CI9CI,0CACE,4BJiDN,CI7CI,wDACE,kBJiDN,CIlDI,wDACE,mBJiDN,CIlDI,oCAEE,kBJgDN,CI7CM,kGAEE,aJiDR,CI7CM,0DACE,eJgDR,CI5CM,4HAEE,kBJ+CR,CIjDM,4HAEE,mBJ+CR,CIjDM,oFACE,kBAAA,CAAA,eJgDR,CIzCE,yBAEE,mBJ2CJ,CI7CE,yBAEE,oBJ2CJ,CI7CE,eACE,mBAAA,CAAA,cJ4CJ,CIvCE,kDAIE,WAAA,CADA,cJ0CJ,CIlCI,4BAEE,oBJoCN,CIhCI,6BAEE,oBJkCN,CI9BI,kCACE,YJgCN,CI3BE,mBACE,iBAAA,CAGA,eAAA,CADA,cAAA,CAEA,iBAAA,CAHA,sBAAA,CAAA,iBJgCJ,CI1BI,uBACE,aAAA,CACA,aJ4BN,CIvBE,uBAGE,iBAAA,CADA,eAAA,CADA,eJ2BJ,CIrBE,mBACE,cJuBJ,CInBE,+BAME,2CAAA,CACA,iDAAA,CACA,mBAAA,CAPA,oBAAA,CAGA,gBAAA,CAFA,cAAA,CACA,aAAA,CAEA,iBJwBJ,CIlBI,aAXF,+BAYI,aJqBJ,CACF,CIhBI,iCACE,gBJkBN,CIXM,8FACE,YJaR,CITM,4FACE,eJWR,CINI,8FACE,eJQN,CILM,kHACE,gBJOR,CIFI,kCAGE,eAAA,CAFA,cAAA,CACA,sBAAA,CAEA,kBJIN,CIAI,kCAGE,qDAAA,CAFA,sBAAA,CACA,kBJGN,CIEI,wCACE,iCJAN,CIGM,8CACE,qDAAA,CACA,sDJDR,CIMI,iCACE,iBJJN,CISE,wCACE,cJPJ,CIUI,wDAIE,gBJFN,CIFI,wDAIE,iBJFN,CIFI,8CAME,UAAA,CALA,oBAAA,CAEA,YAAA,CAIA,oDAAA,CAAA,4CAAA,CACA,6BAAA,CAAA,qBAAA,CACA,yBAAA,CAAA,iBAAA,CACA,iCAAA,CALA,0BAAA,CAHA,WJAN,CIYI,oDACE,oDJVN,CIcI,mEACE,kDAAA,CACA,yDAAA,CAAA,iDJZN,CIgBI,oEACE,kDAAA,CACA,0DAAA,CAAA,kDJdN,CImBE,wBACE,iBAAA,CACA,eAAA,CACA,iBJjBJ,CIqBE,mBACE,oBAAA,CAEA,kBAAA,CADA,eJlBJ,CIsBI,aANF,mBAOI,aJnBJ,CACF,CIsBI,8BACE,aAAA,CAEA,QAAA,CACA,eAAA,CAFA,UJlBN,CKlWI,0CDmYF,uBACE,iBJ7BF,CIgCE,4BACE,eJ9BJ,CACF,CMjiBE,uBAOE,kBAAA,CALA,aAAA,CACA,aAAA,CAEA,aAAA,CACA,eAAA,CALA,iBAAA,CAOA,sCACE,CALF,YNuiBJ,CM9hBI,2BACE,aNgiBN,CM5hBI,6BAME,+CAAA,CAFA,yCAAA,CAHA,eAAA,CACA,eAAA,CACA,kBAAA,CAEA,iBN+hBN,CM1hBI,6BAEE,aAAA,CADA,YN6hBN,CMvhBE,wBACE,kBNyhBJ,CMthBI,4BAIE,kBAAA,CAHA,mCAAA,CAIA,uBNshBN,CMlhBI,4DAEE,oBAAA,CADA,SNqhBN,CMjhBM,oEACE,mBNmhBR,CO5kBA,WAGE,0CAAA,CADA,+BAAA,CADA,aPilBF,CO5kBE,aANF,WAOI,YP+kBF,CACF,CO5kBE,oBAEE,2CAAA,CADA,gCP+kBJ,CO1kBE,kBAGE,eAAA,CADA,iBAAA,CADA,eP8kBJ,COxkBE,6BACE,WP6kBJ,CO9kBE,6BACE,UP6kBJ,CO9kBE,mBAEE,aAAA,CACA,cAAA,CACA,uBP0kBJ,COvkBI,0BACE,YPykBN,COrkBI,yBACE,UPukBN,CQ5mBA,KASE,cAAA,CARA,WAAA,CACA,iBRgnBF,CK5cI,oCGtKJ,KAaI,gBRymBF,CACF,CKjdI,oCGtKJ,KAkBI,cRymBF,CACF,CQpmBA,KASE,2CAAA,CAPA,YAAA,CACA,qBAAA,CAKA,eAAA,CAHA,eAAA,CAJA,iBAAA,CAGA,UR0mBF,CQlmBE,aAZF,KAaI,aRqmBF,CACF,CKldI,0CGhJF,yBAII,cRkmBJ,CACF,CQzlBA,SAEE,gBAAA,CAAA,iBAAA,CADA,eR6lBF,CQxlBA,cACE,YAAA,CAEA,qBAAA,CADA,WR4lBF,CQxlBE,aANF,cAOI,aR2lBF,CACF,CQvlBA,SACE,WR0lBF,CQvlBE,gBACE,YAAA,CACA,WAAA,CACA,iBRylBJ,CQplBA,aACE,eAAA,CACA,sBRulBF,CQ9kBA,WACE,YRilBF,CQ5kBA,WAGE,QAAA,CACA,SAAA,CAHA,iBAAA,CACA,ORilBF,CQ5kBE,uCACE,aR8kBJ,CQ1kBE,+BAEE,uCAAA,CADA,kBR6kBJ,CQvkBA,SASE,2CAAA,CACA,mBAAA,CAFA,gCAAA,CADA,gBAAA,CADA,YAAA,CAMA,SAAA,CADA,uCAAA,CANA,mBAAA,CAJA,cAAA,CAYA,2BAAA,CATA,URilBF,CQrkBE,eAEE,SAAA,CAIA,uBAAA,CAHA,oEACE,CAHF,UR0kBJ,CQ5jBA,MACE,WR+jBF,CSxtBA,MACE,6PT0tBF,CSptBA,cASE,mBAAA,CAFA,0CAAA,CACA,cAAA,CAFA,YAAA,CAIA,uCAAA,CACA,oBAAA,CAVA,iBAAA,CAEA,UAAA,CADA,QAAA,CAUA,qBAAA,CAPA,WAAA,CADA,ST+tBF,CSptBE,aAfF,cAgBI,YTutBF,CACF,CSptBE,kCAEE,uCAAA,CADA,YTutBJ,CSltBE,qBACE,uCTotBJ,CShtBE,wCACE,+BTktBJ,CS7sBE,oBAME,6BAAA,CADA,UAAA,CAJA,aAAA,CAEA,cAAA,CACA,aAAA,CAGA,2CAAA,CAAA,mCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CARA,aTutBJ,CS3sBE,sBACE,cT6sBJ,CS1sBI,2BACE,2CT4sBN,CStsBI,kEAEE,uDAAA,CADA,+BTysBN,CU3wBE,8BACE,YV8wBJ,CWnxBA,mBACE,GACE,SAAA,CACA,0BXsxBF,CWnxBA,GACE,SAAA,CACA,uBXqxBF,CACF,CWjxBA,mBACE,GACE,SXmxBF,CWhxBA,GACE,SXkxBF,CACF,CWvwBE,qBASE,2BAAA,CAFA,mCAAA,CAAA,2BAAA,CADA,0BAAA,CADA,WAAA,CAGA,SAAA,CAPA,cAAA,CACA,KAAA,CAEA,UAAA,CADA,SX+wBJ,CWrwBE,mBAcE,mDAAA,CANA,2CAAA,CACA,QAAA,CACA,mBAAA,CARA,QAAA,CASA,kDACE,CAPF,eAAA,CAEA,aAAA,CADA,SAAA,CALA,cAAA,CAGA,UAAA,CADA,SXgxBJ,CWjwBE,kBACE,aXmwBJ,CW/vBE,sBACE,YAAA,CACA,YXiwBJ,CW9vBI,oCACE,aXgwBN,CW3vBE,sBACE,mBX6vBJ,CW1vBI,6CACE,cX4vBN,CKtpBI,0CMvGA,6CAKI,aAAA,CAEA,gBAAA,CACA,iBAAA,CAFA,UX8vBN,CACF,CWvvBE,kBACE,cXyvBJ,CY11BA,YACE,WAAA,CAIA,WZ01BF,CYv1BE,mBAEE,qBAAA,CADA,iBZ01BJ,CK7rBI,sCOtJE,4EACE,kBZs1BN,CYl1BI,0JACE,mBZo1BN,CYr1BI,8EACE,kBZo1BN,CACF,CY/0BI,0BAGE,UAAA,CAFA,aAAA,CACA,YZk1BN,CY70BI,+BACE,eZ+0BN,CYz0BE,8BACE,WZ80BJ,CY/0BE,8BACE,UZ80BJ,CY/0BE,8BAIE,iBZ20BJ,CY/0BE,8BAIE,kBZ20BJ,CY/0BE,oBAGE,cAAA,CADA,SZ60BJ,CYx0BI,aAPF,oBAQI,YZ20BJ,CACF,CYx0BI,gCACE,yCZ00BN,CYt0BI,wBACE,cAAA,CACA,kBZw0BN,CYr0BM,kCACE,oBZu0BR,Cax4BA,qBAEE,Wbs5BF,Cax5BA,qBAEE,Ubs5BF,Cax5BA,WAQE,2CAAA,CACA,mBAAA,CANA,YAAA,CAOA,8BAAA,CALA,iBAAA,CAMA,SAAA,CALA,mBAAA,CACA,mBAAA,CANA,cAAA,CAcA,0BAAA,CAHA,wCACE,CATF,Sbo5BF,Cat4BE,aAlBF,WAmBI,Yby4BF,CACF,Cat4BE,mBAEE,SAAA,CADA,mBAAA,CAKA,uBAAA,CAHA,kEby4BJ,Cal4BE,kBAEE,gCAAA,CADA,ebq4BJ,Ccv6BA,aACE,gBAAA,CACA,iBd06BF,Ccv6BE,sBAGE,WAAA,CADA,QAAA,CADA,Sd26BJ,Ccr6BE,oBAEE,eAAA,CADA,edw6BJ,Ccn6BE,oBACE,iBdq6BJ,Ccj6BE,mBAEE,YAAA,CACA,cAAA,CACA,6BAAA,CAHA,iBds6BJ,Cch6BI,iDACE,yCdk6BN,Cc95BI,6BACE,iBdg6BN,Cc35BE,mBAGE,uCAAA,CACA,cAAA,CAHA,aAAA,CACA,cAAA,CAGA,sBd65BJ,Cc15BI,gDACE,+Bd45BN,Ccx5BI,4BACE,0CAAA,CACA,mBd05BN,Ccr5BE,mBAEE,SAAA,CADA,iBAAA,CAKA,2BAAA,CAHA,8Ddw5BJ,Ccl5BI,qBAEE,aAAA,CADA,edq5BN,Cch5BI,6BACE,SAAA,CACA,uBdk5BN,Ceh+BA,WAEE,0CAAA,CADA,+Bfo+BF,Ceh+BE,aALF,WAMI,Yfm+BF,CACF,Ceh+BE,kBACE,6BAAA,CAEA,aAAA,CADA,afm+BJ,Ce/9BI,gCACE,Yfi+BN,Ce59BE,iBAOE,eAAA,CANA,YAAA,CAKA,cAAA,CAGA,mBAAA,CAAA,eAAA,CADA,cAAA,CAGA,uCAAA,CADA,eAAA,CAEA,uBf09BJ,Cev9BI,8CACE,Ufy9BN,Cer9BI,+BACE,oBfu9BN,CKz0BI,0CUvIE,uBACE,afm9BN,Ceh9BM,yCACE,Yfk9BR,CACF,Ce78BI,iCACE,gBfg9BN,Cej9BI,iCACE,iBfg9BN,Cej9BI,uBAEE,gBf+8BN,Ce58BM,iCACE,ef88BR,Cex8BE,kBACE,WAAA,CAIA,eAAA,CADA,mBAAA,CAFA,6BAAA,CACA,cAAA,CAGA,kBf08BJ,Cet8BE,mBAEE,YAAA,CADA,afy8BJ,Cep8BE,sBACE,gBAAA,CACA,Ufs8BJ,Cej8BA,gBACE,gDfo8BF,Cej8BE,uBACE,YAAA,CACA,cAAA,CACA,6BAAA,CACA,afm8BJ,Ce/7BE,kCACE,sCfi8BJ,Ce97BI,gFACE,+Bfg8BN,Cex7BA,cAKE,wCAAA,CADA,gBAAA,CADA,iBAAA,CADA,eAAA,CADA,Uf+7BF,CKn5BI,mCU7CJ,cASI,Uf27BF,CACF,Cev7BE,yBACE,sCfy7BJ,Cel7BA,WACE,mBAAA,CACA,SAAA,CAEA,cAAA,CADA,qBfs7BF,CKl6BI,mCUvBJ,WAQI,efq7BF,CACF,Cel7BE,iBACE,oBAAA,CAEA,aAAA,CACA,iBAAA,CAFA,Yfs7BJ,Cej7BI,wBACE,efm7BN,Ce/6BI,qBAGE,iBAAA,CAFA,gBAAA,CACA,mBfk7BN,CgBxlCE,uBAME,kBAAA,CACA,mBAAA,CAHA,gCAAA,CACA,cAAA,CAJA,oBAAA,CAEA,eAAA,CADA,kBAAA,CAMA,gEhB2lCJ,CgBrlCI,gCAEE,2CAAA,CACA,uCAAA,CAFA,gChBylCN,CgBnlCI,0DAEE,0CAAA,CACA,sCAAA,CAFA,+BhBulCN,CgBhlCE,gCAKE,4BhBqlCJ,CgB1lCE,gEAME,6BhBolCJ,CgB1lCE,gCAME,4BhBolCJ,CgB1lCE,sBAIE,6DAAA,CAGA,8BAAA,CAJA,eAAA,CAFA,aAAA,CACA,eAAA,CAMA,sChBklCJ,CgB7kCI,wDACE,6CAAA,CACA,8BhB+kCN,CgB3kCI,+BACE,UhB6kCN,CiBhoCA,WAOE,2CAAA,CAGA,8CACE,CALF,gCAAA,CADA,aAAA,CAHA,MAAA,CADA,eAAA,CACA,OAAA,CACA,KAAA,CACA,SjBuoCF,CiB5nCE,aAfF,WAgBI,YjB+nCF,CACF,CiB5nCE,mBAIE,2BAAA,CAHA,iEjB+nCJ,CiBxnCE,mBACE,kDACE,CAEF,kEjBwnCJ,CiBlnCE,kBAEE,kBAAA,CADA,YAAA,CAEA,ejBonCJ,CiBhnCE,mBAKE,kBAAA,CAEA,cAAA,CAHA,YAAA,CAIA,uCAAA,CALA,aAAA,CAFA,iBAAA,CAQA,uBAAA,CAHA,qBAAA,CAJA,SjBynCJ,CiB/mCI,yBACE,UjBinCN,CiB7mCI,iCACE,oBjB+mCN,CiB3mCI,uCAEE,uCAAA,CADA,YjB8mCN,CiBzmCI,2BAEE,YAAA,CADA,ajB4mCN,CK9/BI,0CY/GA,2BAMI,YjB2mCN,CACF,CiBxmCM,8DAIE,iBAAA,CAHA,aAAA,CAEA,aAAA,CADA,UjB4mCR,CK5hCI,mCYzEA,iCAII,YjBqmCN,CACF,CiBlmCM,wCACE,YjBomCR,CiBhmCM,+CACE,oBjBkmCR,CKviCI,sCYtDA,iCAII,YjB6lCN,CACF,CiBxlCE,kBAEE,YAAA,CACA,cAAA,CAFA,iBAAA,CAIA,8DACE,CAFF,kBjB2lCJ,CiBrlCI,oCAGE,SAAA,CADA,mBAAA,CAKA,6BAAA,CAHA,8DACE,CAJF,UjB2lCN,CiBllCM,8CACE,8BjBolCR,CiB/kCI,8BACE,ejBilCN,CiB5kCE,4BAGE,gBAAA,CAAA,kBjBglCJ,CiBnlCE,4BAGE,iBAAA,CAAA,iBjBglCJ,CiBnlCE,kBACE,WAAA,CAGA,eAAA,CAFA,aAAA,CAGA,kBjB8kCJ,CiB3kCI,4CAGE,SAAA,CADA,mBAAA,CAKA,8BAAA,CAHA,8DACE,CAJF,UjBilCN,CiBxkCM,sDACE,6BjB0kCR,CiBtkCM,8DAGE,SAAA,CADA,mBAAA,CAKA,uBAAA,CAHA,8DACE,CAJF,SjB4kCR,CiBjkCI,uCAGE,WAAA,CAFA,iBAAA,CACA,UjBokCN,CiB9jCE,mBACE,YAAA,CACA,aAAA,CACA,cAAA,CAEA,+CACE,CAFF,kBjBikCJ,CiB3jCI,8DACE,WAAA,CACA,SAAA,CACA,oCjB6jCN,CiBpjCI,yBACE,QjBsjCN,CiBjjCE,mBACE,YjBmjCJ,CK/mCI,mCY2DF,6BAQI,gBjBmjCJ,CiB3jCA,6BAQI,iBjBmjCJ,CiB3jCA,mBAKI,aAAA,CAEA,iBAAA,CADA,ajBqjCJ,CACF,CKvnCI,sCY2DF,6BAaI,kBjBmjCJ,CiBhkCA,6BAaI,mBjBmjCJ,CACF,CDlyCA,SAGE,uCAAA,CAFA,eAAA,CACA,eCsyCF,CDlyCE,eACE,mBAAA,CACA,cAAA,CAGA,eAAA,CADA,QAAA,CADA,SCsyCJ,CDhyCE,sCAEE,WAAA,CADA,iBAAA,CAAA,kBCmyCJ,CD9xCE,eACE,+BCgyCJ,CD7xCI,0CACE,+BC+xCN,CDzxCA,UAKE,wBmBaa,CnBZb,oBAAA,CAFA,UAAA,CAHA,oBAAA,CAEA,eAAA,CADA,0BAAA,CAAA,2BCgyCF,CmBl0CA,MACE,uMAAA,CACA,sLAAA,CACA,iNnBq0CF,CmB/zCA,QACE,eAAA,CACA,enBk0CF,CmB/zCE,eAKE,uCAAA,CAJA,aAAA,CAGA,eAAA,CADA,eAAA,CADA,eAAA,CAIA,sBnBi0CJ,CmB9zCI,+BACE,YnBg0CN,CmB7zCM,mCAEE,WAAA,CADA,UnBg0CR,CmBxzCQ,sFAME,iBAAA,CALA,aAAA,CAGA,aAAA,CADA,cAAA,CAEA,kBAAA,CAHA,UnB8zCV,CmBnzCE,cAGE,eAAA,CADA,QAAA,CADA,SnBuzCJ,CmBjzCE,cAGE,sBAAA,CAFA,YAAA,CACA,SAAA,CAEA,iBAAA,CACA,uBAAA,CACA,sBnBmzCJ,CmBhzCI,sBACE,uCnBkzCN,CmB3yCM,6EAEE,+BnB6yCR,CmBxyCI,2BAIE,iBnBuyCN,CmBnyCI,4CACE,gBnBqyCN,CmBtyCI,4CACE,iBnBqyCN,CmBjyCI,kBAME,iBAAA,CAFA,aAAA,CACA,YAAA,CAFA,iBnBoyCN,CmB7xCI,sGACE,+BAAA,CACA,cnB+xCN,CmB3xCI,4BACE,uCAAA,CACA,oBnB6xCN,CmBzxCI,0CACE,YnB2xCN,CmBxxCM,yDAIE,6BAAA,CAHA,aAAA,CAEA,WAAA,CAEA,qCAAA,CAAA,6BAAA,CAHA,UnB6xCR,CmBtxCM,kDACE,YnBwxCR,CmBlxCE,iCACE,YnBoxCJ,CmBjxCI,6CACE,WAAA,CAGA,WnBixCN,CmB5wCE,cACE,anB8wCJ,CmB1wCE,gBACE,YnB4wCJ,CK7uCI,0CcxBA,0CASE,2CAAA,CAHA,YAAA,CACA,qBAAA,CACA,WAAA,CALA,MAAA,CADA,iBAAA,CACA,OAAA,CACA,KAAA,CACA,SnB2wCJ,CmBhwCI,+DACE,eAAA,CACA,enBkwCN,CmB9vCI,gCAQE,qDAAA,CAHA,uCAAA,CAEA,cAAA,CALA,aAAA,CAEA,kBAAA,CADA,wBAAA,CAFA,iBAAA,CAKA,kBnBkwCN,CmB7vCM,wDAEE,UnBowCR,CmBtwCM,wDAEE,WnBowCR,CmBtwCM,8CAIE,aAAA,CAEA,aAAA,CACA,YAAA,CANA,iBAAA,CAEA,SAAA,CAEA,YnBiwCR,CmB5vCQ,oDAKE,6BAAA,CADA,UAAA,CAHA,aAAA,CAEA,WAAA,CAGA,2CAAA,CAAA,mCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CAPA,UnBqwCV,CmBzvCM,8CAIE,2CAAA,CACA,gEACE,CALF,eAAA,CAEA,4BAAA,CADA,kBnB8vCR,CmBvvCQ,2DACE,YnByvCV,CmBpvCM,8CAGE,2CAAA,CADA,gCAAA,CADA,enBwvCR,CmBlvCM,yCAIE,aAAA,CAFA,UAAA,CAIA,YAAA,CADA,aAAA,CAJA,iBAAA,CACA,WAAA,CACA,SnBuvCR,CmB/uCI,+BACE,MnBivCN,CmB7uCI,+BACE,4DnB+uCN,CmB5uCM,qDACE,+BnB8uCR,CmB3uCQ,sHACE,+BnB6uCV,CmBvuCI,+BAEE,YAAA,CADA,mBnB0uCN,CmBtuCM,mCACE,enBwuCR,CmBpuCM,6CACE,SnBsuCR,CmBluCM,uDAGE,mBnBquCR,CmBxuCM,uDAGE,kBnBquCR,CmBxuCM,6CAIE,gBAAA,CAFA,aAAA,CADA,YnBuuCR,CmBjuCQ,mDAKE,6BAAA,CADA,UAAA,CAHA,aAAA,CAEA,WAAA,CAGA,2CAAA,CAAA,mCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CAPA,UnB0uCV,CmB1tCM,+CACE,mBnB4tCR,CmBptCM,4CAEE,wBAAA,CADA,enButCR,CmBntCQ,oEACE,mBnBqtCV,CmBttCQ,oEACE,oBnBqtCV,CmBjtCQ,4EACE,iBnBmtCV,CmBptCQ,4EACE,kBnBmtCV,CmB/sCQ,oFACE,mBnBitCV,CmBltCQ,oFACE,oBnBitCV,CmB7sCQ,4FACE,mBnB+sCV,CmBhtCQ,4FACE,oBnB+sCV,CmBxsCE,mBACE,wBnB0sCJ,CmBtsCE,wBACE,YAAA,CACA,SAAA,CAIA,0BAAA,CAHA,oEnBysCJ,CmBnsCI,kCACE,2BnBqsCN,CmBhsCE,gCACE,SAAA,CAIA,uBAAA,CAHA,qEnBmsCJ,CmB7rCI,8CAEE,kCAAA,CAAA,0BnB8rCN,CACF,CKh4CI,0Cc0MA,0CACE,YnByrCJ,CmBtrCI,yDACE,UnBwrCN,CmBprCI,wDACE,YnBsrCN,CmBlrCI,kDACE,YnBorCN,CmB/qCE,gBAIE,iDAAA,CADA,gCAAA,CAFA,aAAA,CACA,enBmrCJ,CACF,CK77CM,+DcmRF,6CACE,YnB6qCJ,CmB1qCI,4DACE,UnB4qCN,CmBxqCI,2DACE,YnB0qCN,CmBtqCI,qDACE,YnBwqCN,CACF,CKr7CI,mCc7JJ,QAgbI,oBnBsqCF,CmBhqCI,kCAME,qCAAA,CACA,qDAAA,CANA,eAAA,CACA,KAAA,CAGA,SnBkqCN,CmB7pCM,6CACE,uBnB+pCR,CmB3pCM,gDACE,YnB6pCR,CmBxpCI,2CACE,kBnB2pCN,CmB5pCI,2CACE,mBnB2pCN,CmB5pCI,iCAEE,oBnB0pCN,CmBnpCI,yDACE,kBnBqpCN,CmBtpCI,yDACE,iBnBqpCN,CACF,CK98CI,sCc7JJ,QA4dI,oBAAA,CACA,oDnBmpCF,CmB7oCI,gCAME,qCAAA,CACA,qDAAA,CANA,eAAA,CACA,KAAA,CAGA,SnB+oCN,CmB1oCM,8CACE,uBnB4oCR,CmBxoCM,8CACE,YnB0oCR,CmBroCI,yCACE,kBnBwoCN,CmBzoCI,yCACE,mBnBwoCN,CmBzoCI,+BAEE,oBnBuoCN,CmBhoCI,uDACE,kBnBkoCN,CmBnoCI,uDACE,iBnBkoCN,CmB7nCE,wBACE,YAAA,CACA,sBAAA,CAEA,SAAA,CACA,6FACE,CAHF,mBnBioCJ,CmBznCI,sCACE,enB2nCN,CmBtnCE,iFACE,sBAAA,CAEA,SAAA,CACA,4FACE,CAHF,kBnB0nCJ,CmBjnCE,iDACE,enBmnCJ,CmB/mCE,6CACE,YnBinCJ,CmB7mCE,uBACE,aAAA,CACA,enB+mCJ,CmB5mCI,kCACE,enB8mCN,CmB1mCI,qCACE,enB4mCN,CmBzmCM,0CACE,uCnB2mCR,CmBvmCM,6DACE,mBnBymCR,CmBrmCM,yFAEE,YnBumCR,CmBlmCI,yCAEE,kBnBsmCN,CmBxmCI,yCAEE,mBnBsmCN,CmBxmCI,+BACE,aAAA,CAGA,SAAA,CADA,kBnBqmCN,CmBjmCM,2DACE,SnBmmCR,CmB7lCE,cAGE,kBAAA,CADA,YAAA,CAEA,gCAAA,CAHA,WnBkmCJ,CmB5lCI,oBACE,uDnB8lCN,CmB1lCI,oBAME,6BAAA,CACA,kBAAA,CAFA,UAAA,CAJA,oBAAA,CAEA,WAAA,CAKA,2CAAA,CAAA,mCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CACA,yBAAA,CARA,qBAAA,CAFA,UnBsmCN,CmBzlCM,8BACE,wBnB2lCR,CmBvlCM,kKAEE,uBnBwlCR,CmB1kCI,2EACE,YnB+kCN,CmB5kCM,oDACE,anB8kCR,CmB3kCQ,kEAKE,qCAAA,CACA,qDAAA,CAFA,YAAA,CAHA,eAAA,CACA,KAAA,CACA,SnBglCV,CmB1kCU,0FACE,mBnB4kCZ,CmBvkCQ,0EACE,QnBykCV,CmBpkCM,sFACE,kBnBskCR,CmBvkCM,sFACE,mBnBskCR,CmBlkCM,kDACE,uCnBokCR,CmB9jCI,2CACE,sBAAA,CAEA,SAAA,CADA,kBnBikCN,CmBxjCI,qFAIE,mDnB2jCN,CmB/jCI,qFAIE,oDnB2jCN,CmB/jCI,2EACE,aAAA,CACA,oBAAA,CAGA,SAAA,CAFA,kBnB4jCN,CmBvjCM,yFAEE,gBAAA,CADA,gBnB0jCR,CmBrjCM,0FACE,YnBujCR,CACF,CoB9wDA,eAKE,eAAA,CACA,eAAA,CAJA,SpBqxDF,CoB9wDE,gCANA,kBAAA,CAFA,YAAA,CAGA,sBpB4xDF,CoBvxDE,iBAOE,mBAAA,CAFA,aAAA,CADA,gBAAA,CAEA,iBpBixDJ,CoB5wDE,wBAEE,qDAAA,CADA,uCpB+wDJ,CoB1wDE,qBACE,6CpB4wDJ,CoBvwDI,sDAEE,uDAAA,CADA,+BpB0wDN,CoBtwDM,8DACE,+BpBwwDR,CoBnwDI,mCACE,uCAAA,CACA,oBpBqwDN,CoBjwDI,yBAKE,iBAAA,CADA,yCAAA,CAHA,aAAA,CAEA,eAAA,CADA,YpBswDN,CqBtzDE,eAGE,+DAAA,CADA,oBAAA,CADA,qBrB2zDJ,CKtoDI,0CgBtLF,eAOI,YrByzDJ,CACF,CqBnzDM,6BACE,oBrBqzDR,CqB/yDE,kBACE,YAAA,CACA,qBAAA,CACA,SAAA,CACA,qBrBizDJ,CqB1yDI,0BACE,sBrB4yDN,CqBzyDM,gEACE,+BrB2yDR,CqBryDE,gBAEE,uCAAA,CADA,erBwyDJ,CqBnyDE,kBACE,oBrBqyDJ,CqBlyDI,mCAGE,kBAAA,CAFA,YAAA,CACA,SAAA,CAEA,iBrBoyDN,CqBhyDI,oCAIE,kBAAA,CAHA,mBAAA,CACA,kBAAA,CACA,SAAA,CAGA,QAAA,CADA,iBrBmyDN,CqB9xDI,0DACE,kBrBgyDN,CqBjyDI,0DACE,iBrBgyDN,CqB5xDI,iDACE,uBAAA,CAEA,YrB6xDN,CqBxxDE,4BACE,YrB0xDJ,CqBnxDA,YAGE,kBAAA,CAFA,YAAA,CAIA,eAAA,CAHA,SAAA,CAIA,eAAA,CAFA,UrBwxDF,CqBnxDE,yBACE,WrBqxDJ,CqB9wDA,kBACE,YrBixDF,CKzsDI,0CgBzEJ,kBAKI,wBrBixDF,CACF,CqB9wDE,qCACE,WrBgxDJ,CKpuDI,sCgB7CF,+CAKI,kBrBgxDJ,CqBrxDA,+CAKI,mBrBgxDJ,CACF,CKttDI,0CgBrDJ,6BAMI,SAAA,CAFA,eAAA,CACA,UrB6wDF,CqB1wDE,qDACE,gBrB4wDJ,CqBzwDE,gDACE,SrB2wDJ,CqBxwDE,4CACE,iBAAA,CAAA,kBrB0wDJ,CqBvwDE,2CAEE,WAAA,CADA,crB0wDJ,CqBtwDE,2CACE,mBAAA,CACA,cAAA,CACA,SAAA,CACA,oBAAA,CAAA,iBrBwwDJ,CqBrwDE,2CACE,SrBuwDJ,CqBpwDE,qCAEE,WAAA,CACA,eAAA,CAFA,erBwwDJ,CACF,CsBl7DA,MACE,qBAAA,CACA,yBtBq7DF,CsB/6DA,aAME,qCAAA,CADA,cAAA,CAEA,0FACE,CAPF,cAAA,CACA,KAAA,CAaA,mDAAA,CACA,qBAAA,CAJA,wFACE,CATF,UAAA,CADA,StBy7DF,CuBp8DA,MACE,mfvBu8DF,CuBj8DA,WACE,iBvBo8DF,CKtyDI,mCkB/JJ,WAKI,evBo8DF,CACF,CuBj8DE,kBACE,YvBm8DJ,CuB/7DE,oBAEE,SAAA,CADA,SvBk8DJ,CK/xDI,0CkBpKF,8BAOI,YvB08DJ,CuBj9DA,8BAOI,avB08DJ,CuBj9DA,oBAaI,2CAAA,CACA,kBAAA,CAJA,WAAA,CACA,eAAA,CACA,mBAAA,CANA,iBAAA,CAEA,SAAA,CAUA,uBAAA,CAHA,4CACE,CAPF,UvBw8DJ,CuB57DI,+DACE,SAAA,CACA,oCvB87DN,CACF,CKr0DI,mCkBjJF,8BAgCI,MvBi8DJ,CuBj+DA,8BAgCI,OvBi8DJ,CuBj+DA,oBAqCI,0BAAA,CADA,cAAA,CADA,QAAA,CAJA,cAAA,CAEA,KAAA,CAKA,sDACE,CALF,OvB+7DJ,CuBr7DI,+DAME,YAAA,CACA,SAAA,CACA,4CACE,CARF,UvB07DN,CACF,CKp0DI,0CkBxGA,+DAII,mBvB46DN,CACF,CKl3DM,+DkB/DF,+DASI,mBvB46DN,CACF,CKv3DM,+DkB/DF,+DAcI,mBvB46DN,CACF,CuBv6DE,kBAEE,kCAAA,CAAA,0BvBw6DJ,CKt1DI,0CkBpFF,4BAOI,MvBg7DJ,CuBv7DA,4BAOI,OvBg7DJ,CuBv7DA,kBAWI,QAAA,CAEA,SAAA,CADA,eAAA,CANA,cAAA,CAEA,KAAA,CAWA,wBAAA,CALA,qGACE,CALF,OAAA,CADA,SvB86DJ,CuBj6DI,4BACE,yBvBm6DN,CuB/5DI,6DAEE,WAAA,CACA,SAAA,CAMA,uBAAA,CALA,sGACE,CAJF,UvBq6DN,CACF,CKj4DI,mCkBjEF,4BA2CI,WvB+5DJ,CuB18DA,4BA2CI,UvB+5DJ,CuB18DA,kBA6CI,eAAA,CAHA,iBAAA,CAIA,8CAAA,CAFA,avB85DJ,CACF,CKh6DM,+DkBOF,6DAII,avBy5DN,CACF,CK/4DI,sCkBfA,6DASI,avBy5DN,CACF,CuBp5DE,iBAIE,2CAAA,CACA,0BAAA,CAFA,aAAA,CAFA,iBAAA,CAKA,2CACE,CALF,SvB05DJ,CK55DI,mCkBAF,iBAaI,0BAAA,CACA,mBAAA,CAFA,avBs5DJ,CuBj5DI,uBACE,0BvBm5DN,CACF,CuB/4DI,4DAEE,2CAAA,CACA,6BAAA,CACA,8BAAA,CAHA,gCvBo5DN,CuB54DE,4BAKE,mBAAA,CAAA,oBvBi5DJ,CuBt5DE,4BAKE,mBAAA,CAAA,oBvBi5DJ,CuBt5DE,kBAQE,gBAAA,CAFA,eAAA,CAFA,WAAA,CAHA,iBAAA,CAMA,sBAAA,CAJA,UAAA,CADA,SvBo5DJ,CuB34DI,+BACE,qBvB64DN,CuBz4DI,kEAEE,uCvB04DN,CuBt4DI,6BACE,YvBw4DN,CK56DI,0CkBaF,kBA8BI,eAAA,CADA,aAAA,CADA,UvBy4DJ,CACF,CKt8DI,mCkBgCF,4BAmCI,mBvBy4DJ,CuB56DA,4BAmCI,oBvBy4DJ,CuB56DA,kBAqCI,aAAA,CADA,evBw4DJ,CuBp4DI,+BACE,uCvBs4DN,CuBl4DI,mCACE,gCvBo4DN,CuBh4DI,6DACE,kBvBk4DN,CuB/3DM,8EACE,uCvBi4DR,CuB73DM,0EACE,WvB+3DR,CACF,CuBz3DE,iBAIE,cAAA,CAHA,oBAAA,CAEA,aAAA,CAEA,kCACE,CAJF,YvB83DJ,CuBt3DI,uBACE,UvBw3DN,CuBp3DI,yCAEE,UvBw3DN,CuB13DI,yCAEE,WvBw3DN,CuB13DI,+BACE,iBAAA,CAEA,SAAA,CACA,SvBs3DN,CuBn3DM,6CACE,oBvBq3DR,CK59DI,0CkB+FA,yCAaI,UvBq3DN,CuBl4DE,yCAaI,WvBq3DN,CuBl4DE,+BAcI,SvBo3DN,CuBj3DM,+CACE,YvBm3DR,CACF,CKx/DI,mCkBkHA,+BAwBI,mBvBk3DN,CuB/2DM,8CACE,YvBi3DR,CACF,CuB32DE,8BAEE,WvBg3DJ,CuBl3DE,8BAEE,UvBg3DJ,CuBl3DE,oBAKE,mBAAA,CAJA,iBAAA,CAEA,SAAA,CACA,SvB82DJ,CKp/DI,0CkBkIF,8BASI,WvB82DJ,CuBv3DA,8BASI,UvB82DJ,CuBv3DA,oBAUI,SvB62DJ,CACF,CuB12DI,uCACE,iBvBg3DN,CuBj3DI,uCACE,kBvBg3DN,CuBj3DI,6BAEE,uCAAA,CACA,SAAA,CAIA,oBAAA,CAHA,+DvB62DN,CuBv2DM,iDAEE,uCAAA,CADA,YvB02DR,CuBr2DM,gGAGE,SAAA,CADA,mBAAA,CAEA,kBvBs2DR,CuBn2DQ,sGACE,UvBq2DV,CuB91DE,8BAOE,mBAAA,CAAA,oBvBq2DJ,CuB52DE,8BAOE,mBAAA,CAAA,oBvBq2DJ,CuB52DE,oBAIE,kBAAA,CAKA,yCAAA,CANA,YAAA,CAKA,eAAA,CAFA,WAAA,CAKA,SAAA,CAVA,iBAAA,CACA,KAAA,CAUA,uBAAA,CAFA,kBAAA,CALA,UvBu2DJ,CK9iEI,mCkBkMF,8BAgBI,mBvBi2DJ,CuBj3DA,8BAgBI,oBvBi2DJ,CuBj3DA,oBAiBI,evBg2DJ,CACF,CuB71DI,+DACE,SAAA,CACA,0BvB+1DN,CuB11DE,6BAKE,+BvB61DJ,CuBl2DE,0DAME,gCvB41DJ,CuBl2DE,6BAME,+BvB41DJ,CuBl2DE,mBAIE,eAAA,CAHA,iBAAA,CAEA,UAAA,CADA,SvBg2DJ,CK7iEI,0CkB2MF,mBAWI,QAAA,CADA,UvB61DJ,CACF,CKtkEI,mCkB8NF,mBAiBI,SAAA,CADA,UAAA,CAEA,sBvB41DJ,CuBz1DI,8DACE,8BAAA,CACA,SvB21DN,CACF,CuBt1DE,uBASE,kCAAA,CAAA,0BAAA,CAFA,2CAAA,CANA,WAAA,CACA,eAAA,CAIA,kBvBu1DJ,CuBj1DI,iEAZF,uBAaI,uBvBo1DJ,CACF,CKnnEM,+DkBiRJ,uBAkBI,avBo1DJ,CACF,CKlmEI,sCkB2PF,uBAuBI,avBo1DJ,CACF,CKvmEI,mCkB2PF,uBA4BI,YAAA,CACA,yDAAA,CACA,oBvBo1DJ,CuBj1DI,kEACE,evBm1DN,CuB/0DI,6BACE,+CvBi1DN,CuB70DI,0CAEE,YAAA,CADA,WvBg1DN,CuB30DI,gDACE,oDvB60DN,CuB10DM,sDACE,0CvB40DR,CACF,CuBr0DA,kBACE,gCAAA,CACA,qBvBw0DF,CuBr0DE,wBAME,qDAAA,CAFA,uCAAA,CAFA,gBAAA,CACA,kBAAA,CAFA,eAAA,CAIA,uBvBw0DJ,CK3oEI,mCkB8TF,kCAUI,mBvBu0DJ,CuBj1DA,kCAUI,oBvBu0DJ,CACF,CuBn0DE,wBAGE,eAAA,CADA,QAAA,CADA,SAAA,CAIA,wBAAA,CAAA,gBvBo0DJ,CuBh0DE,wBACE,yDvBk0DJ,CuB/zDI,oCACE,evBi0DN,CuB5zDE,wBACE,aAAA,CAEA,YAAA,CADA,uBAAA,CAEA,gCvB8zDJ,CuB3zDI,4DACE,uDvB6zDN,CuBzzDI,gDACE,mBvB2zDN,CuBtzDE,gCAKE,cAAA,CADA,aAAA,CAGA,YAAA,CANA,eAAA,CAKA,uBAAA,CAJA,KAAA,CACA,SvB4zDJ,CuBrzDI,wCACE,YvBuzDN,CuBlzDI,wDACE,YvBozDN,CuBhzDI,oCAGE,+BAAA,CADA,gBAAA,CADA,mBAAA,CAGA,2CvBkzDN,CK7rEI,mCkBuYA,8CAUI,mBvBgzDN,CuB1zDE,8CAUI,oBvBgzDN,CACF,CuB5yDI,oFAEE,uDAAA,CADA,+BvB+yDN,CuBzyDE,sCACE,2CvB2yDJ,CuBtyDE,2BAGE,eAAA,CADA,eAAA,CADA,iBvB0yDJ,CK9sEI,mCkBmaF,qCAOI,mBvBwyDJ,CuB/yDA,qCAOI,oBvBwyDJ,CACF,CuBpyDE,kCAEE,MvB0yDJ,CuB5yDE,kCAEE,OvB0yDJ,CuB5yDE,wBAME,uCAAA,CAFA,aAAA,CACA,YAAA,CAJA,iBAAA,CAEA,YvByyDJ,CKxsEI,0CkB4ZF,wBAUI,YvBsyDJ,CACF,CuBnyDI,8BAKE,6BAAA,CADA,UAAA,CAHA,oBAAA,CAEA,WAAA,CAGA,+CAAA,CAAA,uCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CAPA,UvB4yDN,CuBlyDM,wCACE,oBvBoyDR,CuB9xDE,8BAGE,uCAAA,CAFA,gBAAA,CACA,evBiyDJ,CuB7xDI,iCAKE,gCAAA,CAHA,eAAA,CACA,eAAA,CACA,eAAA,CAHA,evBmyDN,CuB5xDM,sCACE,oBvB8xDR,CuBzxDI,iCAKE,gCAAA,CAHA,gBAAA,CACA,eAAA,CACA,eAAA,CAHA,avB+xDN,CuBxxDM,sCACE,oBvB0xDR,CuBpxDE,yBAKE,gCAAA,CAJA,aAAA,CAEA,gBAAA,CACA,iBAAA,CAFA,avByxDJ,CuBlxDE,uBAGE,wBAAA,CAFA,+BAAA,CACA,yBvBqxDJ,CwBz7EA,WACE,iBAAA,CACA,SxB47EF,CwBz7EE,kBAOE,2CAAA,CACA,mBAAA,CACA,8BAAA,CAHA,gCAAA,CAHA,QAAA,CAEA,gBAAA,CADA,YAAA,CAMA,SAAA,CATA,iBAAA,CACA,sBAAA,CAaA,mCAAA,CAJA,oExB47EJ,CwBr7EI,6EACE,gBAAA,CACA,SAAA,CAKA,+BAAA,CAJA,8ExBw7EN,CwBh7EI,wBAWE,+BAAA,CAAA,8CAAA,CAFA,6BAAA,CAAA,8BAAA,CACA,YAAA,CAFA,UAAA,CAHA,QAAA,CAFA,QAAA,CAIA,kBAAA,CADA,iBAAA,CALA,iBAAA,CACA,KAAA,CAEA,OxBy7EN,CwB76EE,iBAOE,mBAAA,CAFA,eAAA,CACA,oBAAA,CAHA,QAAA,CAFA,kBAAA,CAGA,aAAA,CAFA,SxBo7EJ,CwB36EE,iBACE,kBxB66EJ,CwBz6EE,2BAGE,kBAAA,CAAA,oBxB+6EJ,CwBl7EE,2BAGE,mBAAA,CAAA,mBxB+6EJ,CwBl7EE,iBAIE,cAAA,CAHA,aAAA,CAKA,YAAA,CADA,uBAAA,CAEA,2CACE,CANF,UxBg7EJ,CwBt6EI,8CACE,+BxBw6EN,CwBp6EI,uBACE,qDxBs6EN,CyB1/EA,YAIE,qBAAA,CADA,aAAA,CAGA,gBAAA,CALA,eAAA,CACA,UAAA,CAGA,azB8/EF,CyB1/EE,aATF,YAUI,YzB6/EF,CACF,CK/0EI,0CoB3KF,+BAKI,azBkgFJ,CyBvgFA,+BAKI,czBkgFJ,CyBvgFA,qBAWI,2CAAA,CAHA,aAAA,CAEA,WAAA,CANA,cAAA,CAEA,KAAA,CASA,uBAAA,CAHA,iEACE,CAJF,aAAA,CAFA,SzBggFJ,CyBr/EI,mEACE,8BAAA,CACA,6BzBu/EN,CyBp/EM,6EACE,8BzBs/ER,CyBj/EI,6CAEE,QAAA,CAAA,MAAA,CACA,QAAA,CACA,eAAA,CAHA,iBAAA,CACA,OAAA,CAGA,qBAAA,CAHA,KzBs/EN,CACF,CK93EI,sCoBtKJ,YAuDI,QzBi/EF,CyB9+EE,mBACE,WzBg/EJ,CyB5+EE,6CACE,UzB8+EJ,CACF,CyB1+EE,uBACE,YAAA,CACA,OzB4+EJ,CK74EI,mCoBjGF,uBAMI,QzB4+EJ,CyBz+EI,8BACE,WzB2+EN,CyBv+EI,qCACE,azBy+EN,CyBr+EI,+CACE,kBzBu+EN,CACF,CyBl+EE,wBAIE,uBAAA,CAOA,kCAAA,CAAA,0BAAA,CAVA,cAAA,CACA,eAAA,CACA,yDAAA,CAMA,oBzBi+EJ,CyB59EI,2CAEE,YAAA,CADA,WzB+9EN,CyB19EI,mEACE,+CzB49EN,CyBz9EM,qHACE,oDzB29ER,CyBx9EQ,iIACE,0CzB09EV,CyB38EE,wCAGE,wBACE,qBzB28EJ,CyBv8EE,6BACE,kCzBy8EJ,CyB18EE,6BACE,iCzBy8EJ,CACF,CKr6EI,0CoB5BF,YAME,0BAAA,CADA,QAAA,CAEA,SAAA,CANA,cAAA,CACA,KAAA,CAMA,sDACE,CALF,OAAA,CADA,SzB08EF,CyB/7EE,4CAEE,WAAA,CACA,SAAA,CACA,4CACE,CAJF,UzBo8EJ,CACF,C0BjnFA,iBACE,GACE,Q1BmnFF,C0BhnFA,GACE,a1BknFF,CACF,C0B9mFA,gBACE,GACE,SAAA,CACA,0B1BgnFF,C0B7mFA,IACE,S1B+mFF,C0B5mFA,GACE,SAAA,CACA,uB1B8mFF,CACF,C0BtmFA,MACE,2eAAA,CACA,+fAAA,CACA,0lBAAA,CACA,kf1BwmFF,C0BlmFA,WAOE,kCAAA,CAAA,0BAAA,CANA,aAAA,CACA,gBAAA,CACA,eAAA,CAEA,uCAAA,CAGA,uBAAA,CAJA,kB1BwmFF,C0BjmFE,iBACE,U1BmmFJ,C0B/lFE,iBACE,oBAAA,CAEA,aAAA,CACA,qBAAA,CAFA,U1BmmFJ,C0B9lFI,+BACE,iB1BimFN,C0BlmFI,+BACE,kB1BimFN,C0BlmFI,qBAEE,gB1BgmFN,C0B5lFI,kDACE,iB1B+lFN,C0BhmFI,kDACE,kB1B+lFN,C0BhmFI,kDAEE,iB1B8lFN,C0BhmFI,kDAEE,kB1B8lFN,C0BzlFE,iCAGE,iB1B8lFJ,C0BjmFE,iCAGE,kB1B8lFJ,C0BjmFE,uBACE,oBAAA,CACA,6BAAA,CAEA,eAAA,CACA,sBAAA,CACA,qB1B2lFJ,C0BvlFE,kBACE,YAAA,CAMA,gBAAA,CALA,SAAA,CAMA,oBAAA,CAHA,gBAAA,CAIA,WAAA,CAHA,eAAA,CAFA,SAAA,CADA,U1B+lFJ,C0BtlFI,iDACE,4B1BwlFN,C0BnlFE,iBACE,eAAA,CACA,sB1BqlFJ,C0BllFI,gDACE,2B1BolFN,C0BhlFI,kCAIE,kB1BwlFN,C0B5lFI,kCAIE,iB1BwlFN,C0B5lFI,wBAOE,6BAAA,CADA,UAAA,CALA,oBAAA,CAEA,YAAA,CAMA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CALA,uBAAA,CAHA,W1B0lFN,C0B9kFI,iCACE,a1BglFN,C0B5kFI,iCACE,gDAAA,CAAA,wC1B8kFN,C0B1kFI,+BACE,8CAAA,CAAA,sC1B4kFN,C0BxkFI,+BACE,8CAAA,CAAA,sC1B0kFN,C0BtkFI,sCACE,qDAAA,CAAA,6C1BwkFN,C0BlkFA,gBACE,Y1BqkFF,C0BlkFE,gCAIE,kB1BskFJ,C0B1kFE,gCAIE,iB1BskFJ,C0B1kFE,sBAGE,kBAAA,CAGA,uCAAA,CALA,mBAAA,CAIA,gBAAA,CAHA,S1BwkFJ,C0BjkFI,+BACE,aAAA,CACA,oB1BmkFN,C0B/jFI,2CACE,U1BkkFN,C0BnkFI,2CACE,W1BkkFN,C0BnkFI,iCAEE,kB1BikFN,C0B7jFI,0BACE,W1B+jFN,C2BtvFA,MACE,iSAAA,CACA,4UAAA,CACA,+NAAA,CACA,gZ3ByvFF,C2BhvFE,iBAME,kDAAA,CADA,UAAA,CAJA,oBAAA,CAEA,cAAA,CAIA,mCAAA,CAAA,2BAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CANA,0BAAA,CAFA,a3B2vFJ,C2B/uFE,uBACE,6B3BivFJ,C2B7uFE,sBACE,wCAAA,CAAA,gC3B+uFJ,C2B3uFE,6BACE,+CAAA,CAAA,uC3B6uFJ,C2BzuFE,4BACE,8CAAA,CAAA,sC3B2uFJ,C4BtxFA,SASE,2CAAA,CADA,gCAAA,CAJA,aAAA,CAGA,eAAA,CADA,aAAA,CADA,UAAA,CAFA,S5B6xFF,C4BpxFE,aAZF,SAaI,Y5BuxFF,CACF,CK5mFI,0CuBzLJ,SAkBI,Y5BuxFF,CACF,C4BpxFE,iBACE,mB5BsxFJ,C4BlxFE,yBAIE,iB5ByxFJ,C4B7xFE,yBAIE,kB5ByxFJ,C4B7xFE,eAQE,eAAA,CAPA,YAAA,CAMA,eAAA,CAJA,QAAA,CAEA,aAAA,CAHA,SAAA,CAWA,oBAAA,CAPA,kB5BuxFJ,C4B7wFI,kCACE,Y5B+wFN,C4B1wFE,eACE,aAAA,CACA,kBAAA,CAAA,mB5B4wFJ,C4BzwFI,sCACE,aAAA,CACA,S5B2wFN,C4BrwFE,eAOE,kCAAA,CAAA,0BAAA,CANA,YAAA,CAEA,eAAA,CADA,gBAAA,CAMA,UAAA,CAJA,uCAAA,CACA,oBAAA,CAIA,8D5BswFJ,C4BjwFI,0CACE,aAAA,CACA,S5BmwFN,C4B/vFI,6BAEE,kB5BkwFN,C4BpwFI,6BAEE,iB5BkwFN,C4BpwFI,mBAGE,iBAAA,CAFA,Y5BmwFN,C4B5vFM,2CACE,qB5B8vFR,C4B/vFM,2CACE,qB5BiwFR,C4BlwFM,2CACE,qB5BowFR,C4BrwFM,2CACE,qB5BuwFR,C4BxwFM,2CACE,oB5B0wFR,C4B3wFM,2CACE,qB5B6wFR,C4B9wFM,2CACE,qB5BgxFR,C4BjxFM,2CACE,qB5BmxFR,C4BpxFM,4CACE,qB5BsxFR,C4BvxFM,4CACE,oB5ByxFR,C4B1xFM,4CACE,qB5B4xFR,C4B7xFM,4CACE,qB5B+xFR,C4BhyFM,4CACE,qB5BkyFR,C4BnyFM,4CACE,qB5BqyFR,C4BtyFM,4CACE,oB5BwyFR,C4BlyFI,gCACE,SAAA,CAIA,yBAAA,CAHA,wC5BqyFN,C6Bx4FA,MACE,mS7B24FF,C6Bl4FE,mCACE,mBAAA,CACA,cAAA,CACA,QAAA,CAEA,mBAAA,CADA,kB7Bs4FJ,C6Bj4FE,oBAGE,kBAAA,CAOA,+CAAA,CACA,oBAAA,CAVA,mBAAA,CAIA,gBAAA,CACA,0BAAA,CACA,eAAA,CALA,QAAA,CAOA,qBAAA,CADA,eAAA,CAJA,wB7B04FJ,C6Bh4FI,0BAGE,uCAAA,CAFA,aAAA,CACA,YAAA,CAEA,6C7Bk4FN,C6B73FM,gEAEE,0CAAA,CADA,+B7Bg4FR,C6B13FI,yBACE,uB7B43FN,C6Bp3FI,gCAME,oDAAA,CADA,UAAA,CAJA,oBAAA,CAEA,YAAA,CAIA,qCAAA,CAAA,6BAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CACA,iCAAA,CAPA,0BAAA,CAFA,W7B+3FN,C6Bl3FI,wFACE,0C7Bo3FN,C8B97FA,iBACE,GACE,oB9Bi8FF,C8B97FA,IACE,kB9Bg8FF,C8B77FA,GACE,oB9B+7FF,CACF,C8Bv7FA,MACE,yNAAA,CACA,sP9B07FF,C8Bn7FA,YA6BE,kCAAA,CAAA,0BAAA,CAVA,2CAAA,CACA,mBAAA,CACA,8BAAA,CAHA,gCAAA,CADA,sCAAA,CAdA,+IACE,CAYF,8BAAA,CAMA,SAAA,CArBA,iBAAA,CACA,uBAAA,CAyBA,4BAAA,CAJA,uDACE,CATF,6BAAA,CADA,S9Bu7FF,C8Br6FE,oBAEE,SAAA,CAKA,uBAAA,CAJA,2EACE,CAHF,S9B06FJ,C8Bh6FE,oBAEE,eAAA,CACA,wBAAA,CAAA,gBAAA,CAFA,U9Bo6FJ,C8B/5FI,6CACE,qC9Bi6FN,C8B75FI,uCAEE,eAAA,CADA,mB9Bg6FN,C8B15FI,6BACE,Y9B45FN,C8Bv5FE,8CACE,sC9By5FJ,C8Br5FE,mBAEE,gBAAA,CADA,a9Bw5FJ,C8Bp5FI,2CACE,Y9Bs5FN,C8Bl5FI,0CACE,e9Bo5FN,C8B54FA,eACE,iBAAA,CACA,eAAA,CAIA,YAAA,CAHA,kBAAA,CAEA,0BAAA,CADA,kB9Bi5FF,C8B54FE,yBACE,a9B84FJ,C8B14FE,oBACE,sCAAA,CACA,iB9B44FJ,C8Bx4FE,6BACE,oBAAA,CAGA,gB9Bw4FJ,C8Bp4FE,sBAYE,mBAAA,CANA,cAAA,CAHA,oBAAA,CACA,gBAAA,CAAA,iBAAA,CAIA,YAAA,CAGA,eAAA,CAVA,iBAAA,CAMA,wBAAA,CAAA,gBAAA,CAFA,uBAAA,CAHA,S9B84FJ,C8Bh4FI,qCACE,uB9Bk4FN,C8B93FI,cArBF,sBAsBI,W9Bi4FJ,C8B93FI,wCACE,2B9Bg4FN,C8B53FI,6BAOE,qCAAA,CACA,+CAAA,CAAA,uC9Bi4FN,C8Bv3FI,yDAZE,UAAA,CADA,YAAA,CAKA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CAVA,iBAAA,CACA,SAAA,CAEA,WAAA,CADA,U9Bq5FN,C8Bt4FI,4BAOE,oDAAA,CACA,4CAAA,CAAA,oCAAA,CAQA,uBAAA,CAJA,+C9B03FN,C8Bn3FM,gDACE,uB9Bq3FR,C8Bj3FM,mFACE,0C9Bm3FR,CACF,C8B92FI,0CAGE,2BAAA,CADA,uBAAA,CADA,S9Bk3FN,C8B52FI,8CACE,oB9B82FN,C8B32FM,aAJF,8CASI,8CAAA,CACA,iBAAA,CAHA,gCAAA,CADA,eAAA,CADA,cAAA,CAGA,kB9Bg3FN,C8B32FM,oDACE,mC9B62FR,CACF,C8Bj2FE,gCAEE,iBAAA,CADA,e9Bq2FJ,C8Bj2FI,mCACE,iB9Bm2FN,C8Bh2FM,oDAEE,a9B+2FR,C8Bj3FM,oDAEE,c9B+2FR,C8Bj3FM,0CAcE,8CAAA,CACA,iBAAA,CALA,gCAAA,CAEA,oBAAA,CACA,qBAAA,CANA,iBAAA,CACA,eAAA,CAHA,UAAA,CAIA,gBAAA,CALA,aAAA,CAEA,cAAA,CALA,iBAAA,CAUA,iBAAA,CARA,S9B82FR,C+B9nGA,MACE,wBAAA,CACA,wB/BioGF,C+B3nGA,aA+BE,kCAAA,CAAA,0BAAA,CAjBA,gCAAA,CADA,sCAAA,CAGA,SAAA,CADA,mBAAA,CAdA,iBAAA,CAGA,wDACE,CAgBF,4BAAA,CAGA,uEACE,CARF,uDACE,CANF,UAAA,CADA,S/B+nGF,C+BxmGE,oBAuBE,8CAAA,CAAA,+CAAA,CADA,UAAA,CADA,aAAA,CAfA,gJACE,CANF,iBAAA,CAmBA,S/B4lGJ,C+BrlGE,yBAGE,kEAAA,CAFA,gDAAA,CACA,6C/BwlGJ,C+BnlGE,4BAGE,qEAAA,CADA,8CAAA,CADA,6C/BulGJ,C+BjlGE,qBAEE,SAAA,CAKA,uBAAA,CAJA,wEACE,CAHF,S/BslGJ,C+B5kGE,oBAqBE,uBAAA,CAEA,2CAAA,CACA,mBAAA,CACA,8BAAA,CAnBA,0FACE,CAaF,eAAA,CADA,8BAAA,CAlBA,iBAAA,CAqBA,oB/BikGJ,C+B3jGI,uCAEE,YAAA,CADA,W/B8jGN,C+BzjGI,6CACE,oD/B2jGN,C+BxjGM,mDACE,0C/B0jGR,C+BljGI,mCAwBE,eAAA,CACA,eAAA,CAxBA,oIACE,CAgBF,sCACE,CAIF,mBAAA,CAKA,wBAAA,CAAA,gBAAA,CAbA,sBAAA,CAAA,iB/B4iGN,C+B3hGI,4CACE,Y/B6hGN,C+BzhGI,2CACE,e/B2hGN,CgC9sGA,kBAME,ehC0tGF,CgChuGA,kBAME,gBhC0tGF,CgChuGA,QAUE,2CAAA,CACA,oBAAA,CAEA,8BAAA,CALA,uCAAA,CACA,cAAA,CALA,aAAA,CAGA,eAAA,CAKA,YAAA,CAPA,mBAAA,CAJA,cAAA,CACA,UAAA,CAiBA,yBAAA,CALA,mGACE,CAZF,ShC6tGF,CgC1sGE,aAtBF,QAuBI,YhC6sGF,CACF,CgC1sGE,kBACE,wBhC4sGJ,CgCxsGE,gBAEE,SAAA,CADA,mBAAA,CAGA,+BAAA,CADA,uBhC2sGJ,CgCvsGI,0BACE,8BhCysGN,CgCpsGE,4BAEE,0CAAA,CADA,+BhCusGJ,CgClsGE,YACE,oBAAA,CACA,oBhCosGJ,CiCzvGA,oBACE,GACE,mBjC4vGF,CACF,CiCpvGA,MACE,wfjCsvGF,CiChvGA,YACE,aAAA,CAEA,eAAA,CADA,ajCovGF,CiChvGE,+BAOE,kBAAA,CAAA,kBjCivGJ,CiCxvGE,+BAOE,iBAAA,CAAA,mBjCivGJ,CiCxvGE,qBAQE,aAAA,CACA,cAAA,CACA,YAAA,CATA,iBAAA,CAKA,UjCkvGJ,CiC3uGI,qCAIE,iBjCmvGN,CiCvvGI,qCAIE,kBjCmvGN,CiCvvGI,2BAME,6BAAA,CADA,UAAA,CAJA,oBAAA,CAEA,YAAA,CAIA,yCAAA,CAAA,iCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CARA,WjCqvGN,CiCxuGE,mBACE,iBAAA,CACA,UjC0uGJ,CiCtuGE,kBAWE,2CAAA,CACA,mBAAA,CACA,8BAAA,CALA,gCAAA,CACA,oBAAA,CAHA,kBAAA,CAFA,YAAA,CAUA,SAAA,CAPA,aAAA,CAFA,SAAA,CAJA,iBAAA,CASA,4BAAA,CARA,UAAA,CAaA,+CACE,CAbF,SjCovGJ,CiCnuGI,+EACE,gBAAA,CACA,SAAA,CACA,sCjCquGN,CiC/tGI,qCAEE,oCACE,gCjCguGN,CiC5tGI,2CACE,cjC8tGN,CACF,CiCztGE,kBACE,kBjC2tGJ,CiCvtGE,4BAGE,kBAAA,CAAA,oBjC8tGJ,CiCjuGE,4BAGE,mBAAA,CAAA,mBjC8tGJ,CiCjuGE,kBAKE,cAAA,CAJA,aAAA,CAMA,YAAA,CADA,uBAAA,CAEA,2CACE,CALF,kBAAA,CAFA,UjC+tGJ,CiCptGI,gDACE,+BjCstGN,CiCltGI,wBACE,qDjCotGN,CkC1zGA,MAEI,6VAAA,CAAA,uWAAA,CAAA,qPAAA,CAAA,2xBAAA,CAAA,qMAAA,CAAA,+aAAA,CAAA,2LAAA,CAAA,yPAAA,CAAA,2TAAA,CAAA,oaAAA,CAAA,2SAAA,CAAA,2LlCm1GJ,CkCv0GE,4CAME,8CAAA,CACA,4BAAA,CACA,mBAAA,CACA,8BAAA,CAJA,mCAAA,CAJA,iBAAA,CAGA,gBAAA,CADA,iBAAA,CADA,eAAA,CASA,uBAAA,CADA,2BlC20GJ,CkCv0GI,aAdF,4CAeI,elC00GJ,CACF,CkCv0GI,sEACE,gClCy0GN,CkCp0GI,gDACE,qBlCs0GN,CkCl0GI,gIAEE,iBAAA,CADA,clCq0GN,CkCh0GI,4FACE,iBlCk0GN,CkC9zGI,kFACE,elCg0GN,CkC5zGI,0FACE,YlC8zGN,CkC1zGI,8EACE,mBlC4zGN,CkCvzGE,sEAGE,iBAAA,CAAA,mBlCi0GJ,CkCp0GE,sEAGE,kBAAA,CAAA,kBlCi0GJ,CkCp0GE,sEASE,uBlC2zGJ,CkCp0GE,sEASE,wBlC2zGJ,CkCp0GE,sEAUE,4BlC0zGJ,CkCp0GE,4IAWE,6BlCyzGJ,CkCp0GE,sEAWE,4BlCyzGJ,CkCp0GE,kDAOE,0BAAA,CACA,WAAA,CAFA,eAAA,CADA,eAAA,CAHA,oBAAA,CAAA,iBAAA,CADA,iBlCm0GJ,CkCtzGI,kFACE,elCwzGN,CkCpzGI,oFAEE,UlC+zGN,CkCj0GI,oFAEE,WlC+zGN,CkCj0GI,gEAOE,wBhBiIU,CgBlIV,UAAA,CADA,WAAA,CAGA,kDAAA,CAAA,0CAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CAVA,iBAAA,CAEA,UAAA,CACA,UlC6zGN,CkClzGI,4DACE,4DlCozGN,CkCtyGE,sDACE,oBlCyyGJ,CkCtyGI,gFACE,gClCwyGN,CkCnyGE,8DACE,0BlCsyGJ,CkCnyGI,4EACE,wBAlBG,CAmBH,kDAAA,CAAA,0ClCqyGN,CkCjyGI,0EACE,alCmyGN,CkCxzGE,8DACE,oBlC2zGJ,CkCxzGI,wFACE,gClC0zGN,CkCrzGE,sEACE,0BlCwzGJ,CkCrzGI,oFACE,wBAlBG,CAmBH,sDAAA,CAAA,8ClCuzGN,CkCnzGI,kFACE,alCqzGN,CkC10GE,sDACE,oBlC60GJ,CkC10GI,gFACE,gClC40GN,CkCv0GE,8DACE,0BlC00GJ,CkCv0GI,4EACE,wBAlBG,CAmBH,kDAAA,CAAA,0ClCy0GN,CkCr0GI,0EACE,alCu0GN,CkC51GE,oDACE,oBlC+1GJ,CkC51GI,8EACE,gClC81GN,CkCz1GE,4DACE,0BlC41GJ,CkCz1GI,0EACE,wBAlBG,CAmBH,iDAAA,CAAA,yClC21GN,CkCv1GI,wEACE,alCy1GN,CkC92GE,4DACE,oBlCi3GJ,CkC92GI,sFACE,gClCg3GN,CkC32GE,oEACE,0BlC82GJ,CkC32GI,kFACE,wBAlBG,CAmBH,qDAAA,CAAA,6ClC62GN,CkCz2GI,gFACE,alC22GN,CkCh4GE,8DACE,oBlCm4GJ,CkCh4GI,wFACE,gClCk4GN,CkC73GE,sEACE,0BlCg4GJ,CkC73GI,oFACE,wBAlBG,CAmBH,sDAAA,CAAA,8ClC+3GN,CkC33GI,kFACE,alC63GN,CkCl5GE,4DACE,oBlCq5GJ,CkCl5GI,sFACE,gClCo5GN,CkC/4GE,oEACE,0BlCk5GJ,CkC/4GI,kFACE,wBAlBG,CAmBH,qDAAA,CAAA,6ClCi5GN,CkC74GI,gFACE,alC+4GN,CkCp6GE,4DACE,oBlCu6GJ,CkCp6GI,sFACE,gClCs6GN,CkCj6GE,oEACE,0BlCo6GJ,CkCj6GI,kFACE,wBAlBG,CAmBH,qDAAA,CAAA,6ClCm6GN,CkC/5GI,gFACE,alCi6GN,CkCt7GE,0DACE,oBlCy7GJ,CkCt7GI,oFACE,gClCw7GN,CkCn7GE,kEACE,0BlCs7GJ,CkCn7GI,gFACE,wBAlBG,CAmBH,oDAAA,CAAA,4ClCq7GN,CkCj7GI,8EACE,alCm7GN,CkCx8GE,oDACE,oBlC28GJ,CkCx8GI,8EACE,gClC08GN,CkCr8GE,4DACE,0BlCw8GJ,CkCr8GI,0EACE,wBAlBG,CAmBH,iDAAA,CAAA,yClCu8GN,CkCn8GI,wEACE,alCq8GN,CkC19GE,4DACE,oBlC69GJ,CkC19GI,sFACE,gClC49GN,CkCv9GE,oEACE,0BlC09GJ,CkCv9GI,kFACE,wBAlBG,CAmBH,qDAAA,CAAA,6ClCy9GN,CkCr9GI,gFACE,alCu9GN,CkC5+GE,wDACE,oBlC++GJ,CkC5+GI,kFACE,gClC8+GN,CkCz+GE,gEACE,0BlC4+GJ,CkCz+GI,8EACE,wBAlBG,CAmBH,mDAAA,CAAA,2ClC2+GN,CkCv+GI,4EACE,alCy+GN,CmC7oHA,MACE,qMnCgpHF,CmCvoHE,sBAEE,uCAAA,CADA,gBnC2oHJ,CmCvoHI,mCACE,anCyoHN,CmC1oHI,mCACE,cnCyoHN,CmCroHM,4BACE,sBnCuoHR,CmCpoHQ,mCACE,gCnCsoHV,CmCloHQ,2DACE,SAAA,CAEA,uBAAA,CADA,enCqoHV,CmChoHQ,yGACE,SAAA,CACA,uBnCkoHV,CmC9nHQ,yCACE,YnCgoHV,CmCznHE,0BACE,eAAA,CACA,enC2nHJ,CmCxnHI,+BACE,oBnC0nHN,CmCrnHE,gDACE,YnCunHJ,CmCnnHE,8BAIE,+BAAA,CAHA,oBAAA,CAEA,WAAA,CAGA,SAAA,CAKA,4BAAA,CAJA,4DACE,CAHF,0BnCunHJ,CmC9mHI,aAdF,8BAeI,+BAAA,CACA,SAAA,CACA,uBnCinHJ,CACF,CmC9mHI,wCACE,6BnCgnHN,CmC5mHI,oCACE,+BnC8mHN,CmC1mHI,qCAKE,6BAAA,CADA,UAAA,CAHA,oBAAA,CAEA,YAAA,CAGA,2CAAA,CAAA,mCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CAPA,WnCmnHN,CmCtmHQ,mDACE,oBnCwmHV,CoCttHE,kCAEE,iBpC4tHJ,CoC9tHE,kCAEE,kBpC4tHJ,CoC9tHE,wBAGE,yCAAA,CAFA,oBAAA,CAGA,SAAA,CACA,mCpCytHJ,CoCptHI,aAVF,wBAWI,YpCutHJ,CACF,CoCntHE,6FAEE,SAAA,CACA,mCpCqtHJ,CoC/sHE,4FAEE,+BpCitHJ,CoC7sHE,oBACE,yBAAA,CACA,uBAAA,CAGA,yEpC6sHJ,CK9kHI,sC+BrHE,qDACE,uBpCssHN,CACF,CoCjsHE,kEACE,yBpCmsHJ,CoC/rHE,sBACE,0BpCisHJ,CqC5vHE,2BACE,arC+vHJ,CK1kHI,0CgCtLF,2BAKI,erC+vHJ,CqC5vHI,6BACE,iBrC8vHN,CACF,CqC1vHI,6BAEE,0BAAA,CAAA,2BAAA,CADA,eAAA,CAEA,iBrC4vHN,CqCzvHM,2CACE,kBrC2vHR,CqCrvHI,6CACE,QrCuvHN,CsCnxHE,uBACE,4CtCuxHJ,CsClxHE,8CAJE,kCAAA,CAAA,0BtC0xHJ,CsCtxHE,uBACE,4CtCqxHJ,CsChxHE,4BAEE,kCAAA,CAAA,0BAAA,CADA,qCtCmxHJ,CsC/wHI,mCACE,atCixHN,CsC7wHI,kCACE,atC+wHN,CsC1wHE,0BAKE,eAAA,CAJA,aAAA,CAEA,YAAA,CACA,aAAA,CAFA,kBAAA,CAAA,mBtC+wHJ,CsCzwHI,uCACE,etC2wHN,CsCvwHI,sCACE,kBtCywHN,CuCtzHA,MACE,oLvCyzHF,CuChzHE,oBAGE,iBAAA,CAEA,gBAAA,CADA,avCkzHJ,CuC9yHI,wCACE,uBvCgzHN,CuC5yHI,gCAEE,eAAA,CADA,gBvC+yHN,CuCxyHM,wCACE,mBvC0yHR,CuCpyHE,8BAKE,oBvCwyHJ,CuC7yHE,8BAKE,mBvCwyHJ,CuC7yHE,8BAUE,4BvCmyHJ,CuC7yHE,4DAWE,6BvCkyHJ,CuC7yHE,8BAWE,4BvCkyHJ,CuC7yHE,oBASE,cAAA,CANA,aAAA,CACA,eAAA,CAIA,evCqyHJ,CuC/xHI,kCACE,uCAAA,CACA,oBvCiyHN,CuC7xHI,wCAEE,uCAAA,CADA,YvCgyHN,CuC3xHI,oCAEE,WvCwyHN,CuC1yHI,oCAEE,UvCwyHN,CuC1yHI,0BAOE,6BAAA,CADA,UAAA,CADA,WAAA,CAGA,yCAAA,CAAA,iCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CAVA,iBAAA,CAEA,UAAA,CAUA,sBAAA,CADA,yBAAA,CARA,UvCsyHN,CuC1xHM,oCACE,wBvC4xHR,CuCvxHI,4BACE,YvCyxHN,CuCpxHI,4CACE,YvCsxHN,CwCh3HE,+DACE,sBAAA,CAEA,mBAAA,CACA,0BAAA,CACA,uBxCk3HJ,CwC/2HI,2EAGE,iBAAA,CADA,eAAA,CADA,yBxCm3HN,CwC52HE,mEACE,0BxC82HJ,CwC12HE,oBACE,qBxC42HJ,CwCx2HE,gBACE,oBxC02HJ,CwCt2HE,gBACE,qBxCw2HJ,CwCp2HE,iBACE,kBxCs2HJ,CwCl2HE,kBACE,kBxCo2HJ,CyC74HE,6BACE,sCzCg5HJ,CyC74HE,cACE,yCzC+4HJ,CyCn4HE,sIACE,oCzCq4HJ,CyC73HE,2EACE,qCzC+3HJ,CyCr3HE,wGACE,oCzCu3HJ,CyC92HE,yFACE,qCzCg3HJ,CyC32HE,6BACE,kCzC62HJ,CyCv2HE,6CACE,sCzCy2HJ,CyCl2HE,4DACE,sCzCo2HJ,CyC71HE,4DACE,qCzC+1HJ,CyCt1HE,yFACE,qCzCw1HJ,CyCh1HE,2EACE,sCzCk1HJ,CyCv0HE,wHACE,qCzCy0HJ,CyCp0HE,8BAGE,mBAAA,CADA,gBAAA,CADA,gBzCw0HJ,CyCn0HE,eACE,4CzCq0HJ,CyCl0HE,eACE,4CzCo0HJ,CyCh0HE,gBAIE,+CAAA,CACA,kDAAA,CAJA,aAAA,CAEA,wBAAA,CADA,wBzCq0HJ,CyC9zHE,yBAOE,wCAAA,CACA,+DAAA,CACA,4BAAA,CACA,6BAAA,CARA,iBAAA,CAGA,eAAA,CACA,eAAA,CAFA,cAAA,CADA,oCAAA,CAFA,iBzCy0HJ,CyC7zHI,6BACE,YzC+zHN,CyC5zHM,kCACE,wBAAA,CACA,yBzC8zHR,CyCxzHE,iCAaE,wCAAA,CACA,+DAAA,CAJA,uCAAA,CACA,0BAAA,CALA,UAAA,CAJA,oBAAA,CAOA,2BAAA,CADA,2BAAA,CADA,2BAAA,CANA,eAAA,CAWA,wBAAA,CAAA,gBAAA,CAPA,SzCi0HJ,CyC/yHE,sBACE,iBAAA,CACA,iBzCizHJ,CyC5yHE,iCAKE,ezC0yHJ,CyCvyHI,sCACE,gBzCyyHN,CyCryHI,gDACE,YzCuyHN,CyC7xHA,gBACE,iBzCgyHF,CyC5xHE,yCACE,aAAA,CACA,SzC8xHJ,CyCzxHE,mBACE,YzC2xHJ,CyCtxHE,oBACE,QzCwxHJ,CyCpxHE,4BACE,WAAA,CACA,SAAA,CACA,ezCsxHJ,CyCnxHI,0CACE,YzCqxHN,CyC/wHE,yBAKE,wCAAA,CAEA,+BAAA,CADA,4BAAA,CAHA,eAAA,CADA,oDAAA,CAEA,wBAAA,CAAA,gBzCoxHJ,CyC7wHE,2BAEE,+DAAA,CADA,2BzCgxHJ,CyC5wHI,+BACE,uCAAA,CACA,gBzC8wHN,CyCzwHE,sBACE,MAAA,CACA,WzC2wHJ,CyCtwHA,aACE,azCywHF,CyC/vHE,4BAEE,aAAA,CADA,YzCmwHJ,CyC/vHI,wDAEE,2BAAA,CADA,wBzCkwHN,CyC5vHE,+BAKE,2CAAA,CAEA,+BAAA,CADA,gCAAA,CADA,sBAAA,CAHA,mBAAA,CACA,gBAAA,CAFA,azCowHJ,CyC3vHI,qCAEE,UAAA,CACA,UAAA,CAFA,azC+vHN,CKt4HI,0CoCsJF,8BACE,iBzCovHF,CyC1uHE,wSAGE,ezCgvHJ,CyC5uHE,sCAEE,mBAAA,CACA,eAAA,CADA,oBAAA,CADA,kBAAA,CAAA,mBzCgvHJ,CACF,C0C7kII,yDAIE,+BAAA,CACA,8BAAA,CAFA,aAAA,CADA,QAAA,CADA,iB1CmlIN,C0C3kII,uBAEE,uCAAA,CADA,c1C8kIN,C0CzhIM,iHAEE,WAlDkB,CAiDlB,kB1CoiIR,C0CriIM,6HAEE,WAlDkB,CAiDlB,kB1CgjIR,C0CjjIM,6HAEE,WAlDkB,CAiDlB,kB1C4jIR,C0C7jIM,oHAEE,WAlDkB,CAiDlB,kB1CwkIR,C0CzkIM,0HAEE,WAlDkB,CAiDlB,kB1ColIR,C0CrlIM,uHAEE,WAlDkB,CAiDlB,kB1CgmIR,C0CjmIM,uHAEE,WAlDkB,CAiDlB,kB1C4mIR,C0C7mIM,6HAEE,WAlDkB,CAiDlB,kB1CwnIR,C0CznIM,yCAEE,WAlDkB,CAiDlB,kB1C4nIR,C0C7nIM,yCAEE,WAlDkB,CAiDlB,kB1CgoIR,C0CjoIM,0CAEE,WAlDkB,CAiDlB,kB1CooIR,C0CroIM,uCAEE,WAlDkB,CAiDlB,kB1CwoIR,C0CzoIM,wCAEE,WAlDkB,CAiDlB,kB1C4oIR,C0C7oIM,sCAEE,WAlDkB,CAiDlB,kB1CgpIR,C0CjpIM,wCAEE,WAlDkB,CAiDlB,kB1CopIR,C0CrpIM,oCAEE,WAlDkB,CAiDlB,kB1CwpIR,C0CzpIM,2CAEE,WAlDkB,CAiDlB,kB1C4pIR,C0C7pIM,qCAEE,WAlDkB,CAiDlB,kB1CgqIR,C0CjqIM,oCAEE,WAlDkB,CAiDlB,kB1CoqIR,C0CrqIM,kCAEE,WAlDkB,CAiDlB,kB1CwqIR,C0CzqIM,qCAEE,WAlDkB,CAiDlB,kB1C4qIR,C0C7qIM,mCAEE,WAlDkB,CAiDlB,kB1CgrIR,C0CjrIM,qCAEE,WAlDkB,CAiDlB,kB1CorIR,C0CrrIM,wCAEE,WAlDkB,CAiDlB,kB1CwrIR,C0CzrIM,sCAEE,WAlDkB,CAiDlB,kB1C4rIR,C0C7rIM,2CAEE,WAlDkB,CAiDlB,kB1CgsIR,C0CrrIM,iCAEE,WAPkB,CAMlB,iB1CwrIR,C0CzrIM,uCAEE,WAPkB,CAMlB,iB1C4rIR,C0C7rIM,mCAEE,WAPkB,CAMlB,iB1CgsIR,C2ClxIA,MACE,2LAAA,CACA,yL3CqxIF,C2C5wIE,wBAKE,mBAAA,CAHA,YAAA,CACA,qBAAA,CACA,YAAA,CAHA,iB3CmxIJ,C2CzwII,8BAGE,QAAA,CACA,SAAA,CAHA,iBAAA,CACA,O3C6wIN,C2CxwIM,qCACE,0B3C0wIR,C2C7uIM,kEACE,0C3C+uIR,C2CzuIE,2BAME,uBAAA,CADA,+DAAA,CAJA,YAAA,CACA,cAAA,CACA,aAAA,CACA,oB3C6uIJ,C2CxuII,aATF,2BAUI,gB3C2uIJ,CACF,C2CxuII,cAGE,+BACE,iB3CwuIN,C2CruIM,sCAQE,qCAAA,CANA,QAAA,CAKA,UAAA,CAHA,aAAA,CAEA,UAAA,CAHA,MAAA,CAFA,iBAAA,CAaA,2CAAA,CALA,2DACE,CAGF,kDAAA,CARA,+B3C6uIR,CACF,C2C/tII,8CACE,Y3CiuIN,C2C7tII,iCAUE,+BAAA,CACA,6BAAA,CALA,uCAAA,CAEA,cAAA,CAPA,aAAA,CAGA,gBAAA,CACA,eAAA,CAFA,8BAAA,CAMA,+BAAA,CAGA,2CACE,CANF,kBAAA,CALA,U3CyuIN,C2C1tIM,aAII,6CACE,O3CytIV,C2C1tIQ,8CACE,O3C4tIV,C2C7tIQ,8CACE,O3C+tIV,C2ChuIQ,8CACE,O3CkuIV,C2CnuIQ,8CACE,O3CquIV,C2CtuIQ,8CACE,O3CwuIV,C2CzuIQ,8CACE,O3C2uIV,C2C5uIQ,8CACE,O3C8uIV,C2C/uIQ,8CACE,O3CivIV,C2ClvIQ,+CACE,Q3CovIV,C2CrvIQ,+CACE,Q3CuvIV,C2CxvIQ,+CACE,Q3C0vIV,C2C3vIQ,+CACE,Q3C6vIV,C2C9vIQ,+CACE,Q3CgwIV,C2CjwIQ,+CACE,Q3CmwIV,C2CpwIQ,+CACE,Q3CswIV,C2CvwIQ,+CACE,Q3CywIV,C2C1wIQ,+CACE,Q3C4wIV,C2C7wIQ,+CACE,Q3C+wIV,C2ChxIQ,+CACE,Q3CkxIV,CACF,C2C7wIM,uCACE,gC3C+wIR,C2C3wIM,oDACE,a3C6wIR,C2CxwII,yCACE,S3C0wIN,C2CtwIM,2CACE,aAAA,CACA,8B3CwwIR,C2ClwIE,4BACE,U3CowIJ,C2CjwII,aAJF,4BAKI,gB3CowIJ,CACF,C2ChwIE,0BACE,Y3CkwIJ,C2C/vII,aAJF,0BAKI,a3CkwIJ,C2C9vIM,sCACE,O3CgwIR,C2CjwIM,uCACE,O3CmwIR,C2CpwIM,uCACE,O3CswIR,C2CvwIM,uCACE,O3CywIR,C2C1wIM,uCACE,O3C4wIR,C2C7wIM,uCACE,O3C+wIR,C2ChxIM,uCACE,O3CkxIR,C2CnxIM,uCACE,O3CqxIR,C2CtxIM,uCACE,O3CwxIR,C2CzxIM,wCACE,Q3C2xIR,C2C5xIM,wCACE,Q3C8xIR,C2C/xIM,wCACE,Q3CiyIR,C2ClyIM,wCACE,Q3CoyIR,C2CryIM,wCACE,Q3CuyIR,C2CxyIM,wCACE,Q3C0yIR,C2C3yIM,wCACE,Q3C6yIR,C2C9yIM,wCACE,Q3CgzIR,C2CjzIM,wCACE,Q3CmzIR,C2CpzIM,wCACE,Q3CszIR,C2CvzIM,wCACE,Q3CyzIR,CACF,C2CnzII,+FAEE,Q3CqzIN,C2ClzIM,yGACE,wBAAA,CACA,yB3CqzIR,C2C5yIM,2DAEE,wBAAA,CACA,yBAAA,CAFA,Q3CgzIR,C2CzyIM,iEACE,Q3C2yIR,C2CxyIQ,qLAGE,wBAAA,CACA,yBAAA,CAFA,Q3C4yIV,C2CtyIQ,6FACE,wBAAA,CACA,yB3CwyIV,C2CnyIM,yDACE,kB3CqyIR,C2ChyII,sCACE,Q3CkyIN,C2C7xIE,2BAEE,iBAAA,CAOA,kBAAA,CAHA,uCAAA,CAEA,cAAA,CAPA,aAAA,CAGA,YAAA,CACA,gBAAA,CAEA,mBAAA,CAGA,gCAAA,CAPA,W3CsyIJ,C2C5xII,iCAEE,uDAAA,CADA,+B3C+xIN,C2C1xII,iCAKE,6BAAA,CADA,UAAA,CAHA,aAAA,CAEA,WAAA,CAGA,8CAAA,CAAA,sCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CACA,+CACE,CATF,U3CoyIN,C2CrxIE,4BAOE,yEACE,CANF,YAAA,CAGA,aAAA,CAFA,qBAAA,CAGA,mBAAA,CALA,iBAAA,CAYA,wBAAA,CATA,Y3C2xIJ,C2C/wII,sCACE,wB3CixIN,C2C7wII,oCACE,S3C+wIN,C2C3wII,kCAGE,wEACE,CAFF,mBAAA,CADA,O3C+wIN,C2CrwIM,uDACE,8CAAA,CAAA,sC3CuwIR,CK94II,0CsCqJF,wDAEE,kB3C+vIF,C2CjwIA,wDAEE,mB3C+vIF,C2CjwIA,8CAGE,eAAA,CAFA,eAAA,CAGA,iC3C6vIF,C2CzvIE,8DACE,mB3C4vIJ,C2C7vIE,8DACE,kB3C4vIJ,C2C7vIE,oDAEE,U3C2vIJ,C2CvvIE,8EAEE,kB3C0vIJ,C2C5vIE,8EAEE,mB3C0vIJ,C2C5vIE,8EAGE,kB3CyvIJ,C2C5vIE,8EAGE,mB3CyvIJ,C2C5vIE,oEACE,U3C2vIJ,C2CrvIE,8EAEE,mB3CwvIJ,C2C1vIE,8EAEE,kB3CwvIJ,C2C1vIE,8EAGE,mB3CuvIJ,C2C1vIE,8EAGE,kB3CuvIJ,C2C1vIE,oEACE,U3CyvIJ,CACF,C2C3uIE,cAHF,olDAII,gC3C8uIF,C2C3uIE,g8GACE,uC3C6uIJ,CACF,C2CxuIA,4sDACE,+B3C2uIF,C2CvuIA,wmDACE,a3C0uIF,C4C9mJA,MACE,qWAAA,CACA,8W5CinJF,C4CxmJE,4BAEE,oBAAA,CADA,iB5C4mJJ,C4CvmJI,sDAEE,S5C0mJN,C4C5mJI,sDAEE,U5C0mJN,C4C5mJI,4CACE,iBAAA,CAEA,S5CymJN,C4CpmJE,+CAEE,SAAA,CADA,U5CumJJ,C4ClmJE,kDAEE,W5C6mJJ,C4C/mJE,kDAEE,Y5C6mJJ,C4C/mJE,wCAOE,qDAAA,CADA,UAAA,CADA,aAAA,CAGA,0CAAA,CAAA,kCAAA,CAEA,4BAAA,CAAA,oBAAA,CADA,6BAAA,CAAA,qBAAA,CAEA,yBAAA,CAAA,iBAAA,CAVA,iBAAA,CAEA,SAAA,CACA,Y5C2mJJ,C4ChmJE,gEACE,wB1B2Wa,C0B1Wb,mDAAA,CAAA,2C5CkmJJ,C6ClpJA,QACE,8DAAA,CAGA,+CAAA,CACA,iEAAA,CACA,oDAAA,CACA,sDAAA,CACA,mDAAA,CAGA,qEAAA,CACA,qEAAA,CACA,wEAAA,CACA,0EAAA,CACA,wEAAA,CACA,yEAAA,CACA,kEAAA,CACA,+DAAA,CACA,oEAAA,CACA,oEAAA,CACA,mEAAA,CACA,gEAAA,CACA,uEAAA,CACA,mEAAA,CACA,qEAAA,CACA,oEAAA,CACA,gEAAA,CACA,wEAAA,CACA,qEAAA,CACA,+D7CipJF,C6C3oJA,SAEE,kBAAA,CADA,Y7C+oJF,C8CjrJE,kBAUE,cAAA,CATA,YAAA,CACA,kEACE,CAQF,Y9C6qJJ,C8CzqJI,sDACE,gB9C2qJN,C8CrqJI,oFAKE,wDAAA,CACA,mBAAA,CAJA,aAAA,CAEA,QAAA,CADA,aAAA,CAIA,sC9CuqJN,C8ClqJM,iOACE,kBAAA,CACA,8B9CqqJR,C8CjqJM,6FACE,iBAAA,CAAA,c9CoqJR,C8ChqJM,2HACE,Y9CmqJR,C8C/pJM,wHACE,e9CkqJR,C8CnpJI,yMAGE,eAAA,CAAA,Y9C2pJN,C8C7oJI,ybAOE,W9CmpJN,C8C/oJI,8BACE,eAAA,CAAA,Y9CipJN,CK7kJI,mC0ChKA,8BACE,U/CqvJJ,C+CtvJE,8BACE,W/CqvJJ,C+CtvJE,8BAGE,kB/CmvJJ,C+CtvJE,8BAGE,iB/CmvJJ,C+CtvJE,oBAKE,mBAAA,CADA,YAAA,CAFA,a/CovJJ,C+C9uJI,kCACE,W/CivJN,C+ClvJI,kCACE,U/CivJN,C+ClvJI,kCAEE,iBAAA,CAAA,c/CgvJN,C+ClvJI,kCAEE,aAAA,CAAA,kB/CgvJN,CACF","file":"main.css"}
\ No newline at end of file
diff --git a/main/concepts/0003-protocols/index.html b/main/concepts/0003-protocols/index.html
index 3637575d0..66276e6da 100644
--- a/main/concepts/0003-protocols/index.html
+++ b/main/concepts/0003-protocols/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3635,6 +3635,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3803,6 +3824,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3845,6 +3887,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3860,6 +3923,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5676,7 +5781,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../../aip2/0593-json-ld-cred-attach/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials">
+          <a href="../../aip2/0593-json-ld-cred-attach/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0593 JSON-LD Credential Attachment format for requesting and issuing credentials">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -5686,7 +5791,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+                0593 JSON-LD Credential Attachment format for requesting and issuing credentials
               </div>
             </div>
           </a>
@@ -5736,7 +5841,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0003-protocols/roles-participants-etc/index.html b/main/concepts/0003-protocols/roles-participants-etc/index.html
index 544aedb41..732019dce 100644
--- a/main/concepts/0003-protocols/roles-participants-etc/index.html
+++ b/main/concepts/0003-protocols/roles-participants-etc/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4519,7 +4624,7 @@ <h4 id="controllers">Controllers<a class="headerlink" href="#controllers" title=
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0003-protocols/tictactoe/index.html b/main/concepts/0003-protocols/tictactoe/index.html
index f187becf7..9416082bb 100644
--- a/main/concepts/0003-protocols/tictactoe/index.html
+++ b/main/concepts/0003-protocols/tictactoe/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4841,7 +4946,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0004-agents/index.html b/main/concepts/0004-agents/index.html
index f1a6a91d8..59f00f4ec 100644
--- a/main/concepts/0004-agents/index.html
+++ b/main/concepts/0004-agents/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3401,6 +3401,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3569,6 +3590,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3611,6 +3653,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3626,6 +3689,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5064,7 +5169,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0005-didcomm/index.html b/main/concepts/0005-didcomm/index.html
index f1d5d957e..a2c873c72 100644
--- a/main/concepts/0005-didcomm/index.html
+++ b/main/concepts/0005-didcomm/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3425,6 +3425,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3593,6 +3614,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3635,6 +3677,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3650,6 +3713,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4867,7 +4972,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0006-ssi-notation/index.html b/main/concepts/0006-ssi-notation/index.html
index 931515d9b..db924070d 100644
--- a/main/concepts/0006-ssi-notation/index.html
+++ b/main/concepts/0006-ssi-notation/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3575,6 +3575,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3743,6 +3764,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3785,6 +3827,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3800,6 +3863,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5327,7 +5432,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0008-message-id-and-threading/index.html b/main/concepts/0008-message-id-and-threading/index.html
index c71c37ad4..d627b0d9e 100644
--- a/main/concepts/0008-message-id-and-threading/index.html
+++ b/main/concepts/0008-message-id-and-threading/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3461,6 +3461,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3629,6 +3650,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3671,6 +3713,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3686,6 +3749,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4970,7 +5075,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0011-decorators/index.html b/main/concepts/0011-decorators/index.html
index caa0838d6..214e8c8ce 100644
--- a/main/concepts/0011-decorators/index.html
+++ b/main/concepts/0011-decorators/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3443,6 +3443,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3611,6 +3632,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3653,6 +3695,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3668,6 +3731,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4977,7 +5082,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0013-overlays/index.html b/main/concepts/0013-overlays/index.html
index 1181bbee3..3b8bdea77 100644
--- a/main/concepts/0013-overlays/index.html
+++ b/main/concepts/0013-overlays/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4506,7 +4611,7 @@ <h1 id="aries-rfc-0013-overlays">Aries RFC 0013: Overlays<a class="headerlink" h
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0017-attachments/index.html b/main/concepts/0017-attachments/index.html
index fbc281c57..54192b32b 100644
--- a/main/concepts/0017-attachments/index.html
+++ b/main/concepts/0017-attachments/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3503,6 +3503,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3671,6 +3692,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3713,6 +3755,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3728,6 +3791,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5278,7 +5383,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0020-message-types/index.html b/main/concepts/0020-message-types/index.html
index b5f556b1d..9c07d6e4e 100644
--- a/main/concepts/0020-message-types/index.html
+++ b/main/concepts/0020-message-types/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3494,6 +3494,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3662,6 +3683,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3704,6 +3746,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3719,6 +3782,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4927,7 +5032,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0021-didcomm-message-anatomy/index.html b/main/concepts/0021-didcomm-message-anatomy/index.html
index 1ef9ff3df..d4b323b10 100644
--- a/main/concepts/0021-didcomm-message-anatomy/index.html
+++ b/main/concepts/0021-didcomm-message-anatomy/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3461,6 +3461,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3629,6 +3650,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3671,6 +3713,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3686,6 +3749,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4822,7 +4927,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0029-message-trust-contexts/index.html b/main/concepts/0029-message-trust-contexts/index.html
index f3e913c49..d97c5fb51 100644
--- a/main/concepts/0029-message-trust-contexts/index.html
+++ b/main/concepts/0029-message-trust-contexts/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4871,7 +4976,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0046-mediators-and-relays/index.html b/main/concepts/0046-mediators-and-relays/index.html
index 8bd3dfd29..604d3de1f 100644
--- a/main/concepts/0046-mediators-and-relays/index.html
+++ b/main/concepts/0046-mediators-and-relays/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3425,6 +3425,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3593,6 +3614,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3635,6 +3677,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3650,6 +3713,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4878,7 +4983,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0047-json-ld-compatibility/index.html b/main/concepts/0047-json-ld-compatibility/index.html
index 7590eb947..ed04adc07 100644
--- a/main/concepts/0047-json-ld-compatibility/index.html
+++ b/main/concepts/0047-json-ld-compatibility/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3452,6 +3452,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3620,6 +3641,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3662,6 +3704,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3677,6 +3740,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4957,7 +5062,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0049-repudiation/index.html b/main/concepts/0049-repudiation/index.html
index 9e8b99738..f1d5bfb55 100644
--- a/main/concepts/0049-repudiation/index.html
+++ b/main/concepts/0049-repudiation/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3410,6 +3410,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3578,6 +3599,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3620,6 +3662,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3635,6 +3698,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4758,7 +4863,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0050-wallets/index.html b/main/concepts/0050-wallets/index.html
index bede20692..a45e4fe51 100644
--- a/main/concepts/0050-wallets/index.html
+++ b/main/concepts/0050-wallets/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3560,6 +3560,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3728,6 +3749,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3770,6 +3812,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3785,6 +3848,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5327,7 +5432,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0051-dkms/agent-authz-policy-ledger-interactions/index.html b/main/concepts/0051-dkms/agent-authz-policy-ledger-interactions/index.html
index 4b3556363..2bf2e0450 100644
--- a/main/concepts/0051-dkms/agent-authz-policy-ledger-interactions/index.html
+++ b/main/concepts/0051-dkms/agent-authz-policy-ledger-interactions/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4661,7 +4766,7 @@ <h2 id="code-organisation">Code organisation.<a class="headerlink" href="#code-o
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0051-dkms/dkms-v4/index.html b/main/concepts/0051-dkms/dkms-v4/index.html
index f56f6870e..e70267b04 100644
--- a/main/concepts/0051-dkms/dkms-v4/index.html
+++ b/main/concepts/0051-dkms/dkms-v4/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5213,7 +5318,7 @@ <h1 id="12-future-standardization">12. Future Standardization<a class="headerlin
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0051-dkms/index.html b/main/concepts/0051-dkms/index.html
index 7157cf4b9..149d5e7e9 100644
--- a/main/concepts/0051-dkms/index.html
+++ b/main/concepts/0051-dkms/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4755,7 +4860,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0051-dkms/shamir_secret/index.html b/main/concepts/0051-dkms/shamir_secret/index.html
index c87f6244b..cfc1b0cc7 100644
--- a/main/concepts/0051-dkms/shamir_secret/index.html
+++ b/main/concepts/0051-dkms/shamir_secret/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4486,7 +4591,7 @@ <h2 id="indy-sdk">Indy-sdk<a class="headerlink" href="#indy-sdk" title="Permanen
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0051-dkms/trustee_protocols/index.html b/main/concepts/0051-dkms/trustee_protocols/index.html
index 9a7cb5052..fae8966f1 100644
--- a/main/concepts/0051-dkms/trustee_protocols/index.html
+++ b/main/concepts/0051-dkms/trustee_protocols/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4703,7 +4808,7 @@ <h2 id="recovery-share-data-structure">Recovery Share Data Structure<a class="he
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0074-didcomm-best-practices/index.html b/main/concepts/0074-didcomm-best-practices/index.html
index 80405c318..4e0e2f75b 100644
--- a/main/concepts/0074-didcomm-best-practices/index.html
+++ b/main/concepts/0074-didcomm-best-practices/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3497,6 +3497,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3665,6 +3686,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3707,6 +3749,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3722,6 +3785,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5188,7 +5293,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0094-cross-domain-messaging/index.html b/main/concepts/0094-cross-domain-messaging/index.html
index 98698262a..e3d7019b1 100644
--- a/main/concepts/0094-cross-domain-messaging/index.html
+++ b/main/concepts/0094-cross-domain-messaging/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3530,6 +3530,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3698,6 +3719,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3740,6 +3782,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3755,6 +3818,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5121,7 +5226,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0103-indirect-identity-control/controllership-details/index.html b/main/concepts/0103-indirect-identity-control/controllership-details/index.html
index 8fe617fb8..560b6e7fe 100644
--- a/main/concepts/0103-indirect-identity-control/controllership-details/index.html
+++ b/main/concepts/0103-indirect-identity-control/controllership-details/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4449,7 +4554,7 @@ <h1 id="controllership-details">Controllership Details<a class="headerlink" href
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0103-indirect-identity-control/delegation-details/index.html b/main/concepts/0103-indirect-identity-control/delegation-details/index.html
index e6a3cca17..539b7dd13 100644
--- a/main/concepts/0103-indirect-identity-control/delegation-details/index.html
+++ b/main/concepts/0103-indirect-identity-control/delegation-details/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4591,7 +4696,7 @@ <h2 id="prior-art-and-references">Prior Art and References<a class="headerlink"
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0103-indirect-identity-control/guardianship-details/index.html b/main/concepts/0103-indirect-identity-control/guardianship-details/index.html
index 5f82a9d70..47f367063 100644
--- a/main/concepts/0103-indirect-identity-control/guardianship-details/index.html
+++ b/main/concepts/0103-indirect-identity-control/guardianship-details/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4542,7 +4647,7 @@ <h2 id="diffuse-trust">Diffuse Trust<a class="headerlink" href="#diffuse-trust"
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0103-indirect-identity-control/guardianship-sample/schema/index.html b/main/concepts/0103-indirect-identity-control/guardianship-sample/schema/index.html
index fa196c3ae..5b3a3868c 100644
--- a/main/concepts/0103-indirect-identity-control/guardianship-sample/schema/index.html
+++ b/main/concepts/0103-indirect-identity-control/guardianship-sample/schema/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4467,7 +4572,7 @@ <h3 id="how-to-use">How to Use<a class="headerlink" href="#how-to-use" title="Pe
     <script id="__config" type="application/json">{"base": "../../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/index.html b/main/concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/index.html
index 091563687..d5fcfcece 100644
--- a/main/concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/index.html
+++ b/main/concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4667,7 +4772,7 @@ <h3 id="best-practices">Best Practices<a class="headerlink" href="#best-practice
     <script id="__config" type="application/json">{"base": "../../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0103-indirect-identity-control/index.html b/main/concepts/0103-indirect-identity-control/index.html
index b23c34f33..3ec390c99 100644
--- a/main/concepts/0103-indirect-identity-control/index.html
+++ b/main/concepts/0103-indirect-identity-control/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3461,6 +3461,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3629,6 +3650,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3671,6 +3713,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3686,6 +3749,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5016,7 +5121,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0104-chained-credentials/contrast-zcap-ld/index.html b/main/concepts/0104-chained-credentials/contrast-zcap-ld/index.html
index 2e604e55a..9405944b3 100644
--- a/main/concepts/0104-chained-credentials/contrast-zcap-ld/index.html
+++ b/main/concepts/0104-chained-credentials/contrast-zcap-ld/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4480,7 +4585,7 @@ <h3 id="why-not-zcap-ld">Why not ZCAP-LD?<a class="headerlink" href="#why-not-zc
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0104-chained-credentials/index.html b/main/concepts/0104-chained-credentials/index.html
index 02a506756..bf09c92e4 100644
--- a/main/concepts/0104-chained-credentials/index.html
+++ b/main/concepts/0104-chained-credentials/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3530,6 +3530,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3698,6 +3719,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3740,6 +3782,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3755,6 +3818,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5169,7 +5274,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0167-data-consent-lifecycle/index.html b/main/concepts/0167-data-consent-lifecycle/index.html
index 90c536174..7b7da0884 100644
--- a/main/concepts/0167-data-consent-lifecycle/index.html
+++ b/main/concepts/0167-data-consent-lifecycle/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3617,6 +3617,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3785,6 +3806,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3827,6 +3869,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3842,6 +3905,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5830,7 +5935,7 @@ <h3 id="comments">Comments<a class="headerlink" href="#comments" title="Permanen
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0207-credential-fraud-threat-model/index.html b/main/concepts/0207-credential-fraud-threat-model/index.html
index 23d13dd52..26dc97a00 100644
--- a/main/concepts/0207-credential-fraud-threat-model/index.html
+++ b/main/concepts/0207-credential-fraud-threat-model/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4978,7 +5083,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0217-linkable-message-paths/index.html b/main/concepts/0217-linkable-message-paths/index.html
index ac6789d63..7b1c239f7 100644
--- a/main/concepts/0217-linkable-message-paths/index.html
+++ b/main/concepts/0217-linkable-message-paths/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4832,7 +4937,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0231-biometric-service-provider/index.html b/main/concepts/0231-biometric-service-provider/index.html
index 787fed88f..817f97e9f 100644
--- a/main/concepts/0231-biometric-service-provider/index.html
+++ b/main/concepts/0231-biometric-service-provider/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3512,6 +3512,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3680,6 +3701,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3722,6 +3764,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3737,6 +3800,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5095,7 +5200,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0250-rich-schemas/index.html b/main/concepts/0250-rich-schemas/index.html
index d9452a06d..0e5b84ed0 100644
--- a/main/concepts/0250-rich-schemas/index.html
+++ b/main/concepts/0250-rich-schemas/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5320,7 +5425,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0257-private-credential-issuance/index.html b/main/concepts/0257-private-credential-issuance/index.html
index c48e4ce3b..8de5c2fa9 100644
--- a/main/concepts/0257-private-credential-issuance/index.html
+++ b/main/concepts/0257-private-credential-issuance/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4774,7 +4879,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0268-unified-didcomm-agent-deeplinking/index.html b/main/concepts/0268-unified-didcomm-agent-deeplinking/index.html
index c4ef434fd..184ea4ef0 100644
--- a/main/concepts/0268-unified-didcomm-agent-deeplinking/index.html
+++ b/main/concepts/0268-unified-didcomm-agent-deeplinking/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3479,6 +3479,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3647,6 +3668,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3689,6 +3731,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3704,6 +3767,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4848,7 +4953,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0270-interop-test-suite/index.html b/main/concepts/0270-interop-test-suite/index.html
index efd54e9ec..23ff5224f 100644
--- a/main/concepts/0270-interop-test-suite/index.html
+++ b/main/concepts/0270-interop-test-suite/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3503,6 +3503,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3671,6 +3692,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3713,6 +3755,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3728,6 +3791,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5056,7 +5161,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0289-toip-stack/index.html b/main/concepts/0289-toip-stack/index.html
index ce68ce40b..c890f6bbb 100644
--- a/main/concepts/0289-toip-stack/index.html
+++ b/main/concepts/0289-toip-stack/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5469,7 +5574,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0302-aries-interop-profile/index.html b/main/concepts/0302-aries-interop-profile/index.html
index bfde8f7e3..947c3e77e 100644
--- a/main/concepts/0302-aries-interop-profile/index.html
+++ b/main/concepts/0302-aries-interop-profile/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3503,6 +3503,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3671,6 +3692,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3713,6 +3755,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3728,6 +3791,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5059,7 +5164,7 @@ <h4 id="base-requirements">Base Requirements<a class="headerlink" href="#base-re
 <tr>
 <td>Concept</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00../../concepts/0519-goal-codes">0519-goal-codes</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 <tr>
 <td>Feature</td>
@@ -5074,7 +5179,7 @@ <h4 id="base-requirements">Base Requirements<a class="headerlink" href="#base-re
 <tr>
 <td>Feature</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/bf3d796cc33ce78ed7cde7f5422b10719a68be21../../features/0023-did-exchange">0023-did-exchange</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 <tr>
 <td>Feature</td>
@@ -5089,27 +5194,27 @@ <h4 id="base-requirements">Base Requirements<a class="headerlink" href="#base-re
 <tr>
 <td>Feature</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00../../features/0044-didcomm-file-and-mime-types">0044-didcomm-file-and-mime-types</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 <tr>
 <td>Feature</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00../../features/0048-trust-ping">0048-trust-ping</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 <tr>
 <td>Feature</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/4e78319e5f79df2003ddf37f8f497d0fae20cc63../../features/0183-revocation-notification">0183-revocation-notification</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 <tr>
 <td>Feature</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/4e78319e5f79df2003ddf37f8f497d0fae20cc63../../features/0360-use-did-key">0360-use-did-key</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 <tr>
 <td>Feature</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00../../features/0434-outofband">0434-outofband</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 <tr>
 <td>Feature</td>
@@ -5124,7 +5229,7 @@ <h4 id="base-requirements">Base Requirements<a class="headerlink" href="#base-re
 <tr>
 <td>Feature</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2../../features/0557-discover-features-v2">0557-discover-features-v2</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 </tbody>
 </table>
@@ -5141,12 +5246,12 @@ <h4 id="mediate-mediator-coordination">MEDIATE: Mediator Coordination<a class="h
 <tr>
 <td>Feature</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00../../features/0211-route-coordination">0211-route-coordination</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 <tr>
 <td>Feature</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2../../features/0092-transport-return-route">0092-transport-return-route</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 </tbody>
 </table>
@@ -5163,12 +5268,12 @@ <h4 id="indycred-indy-based-credentials">INDYCRED: Indy Based Credentials<a clas
 <tr>
 <td>Feature</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00../../features/0592-indy-attachments">0592-indy-attachments</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /> Evolved from AIP V1.0</td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /> Evolved from AIP V1.0</td>
 </tr>
 <tr>
 <td>Concept</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/4e78319e5f79df2003ddf37f8f497d0fae20cc63../../concepts/0441-present-proof-best-practices">0441-present-proof-best-practices</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 </tbody>
 </table>
@@ -5185,12 +5290,12 @@ <h4 id="ldcred-json-ld-based-credentials">LDCRED: JSON-LD Based Credentials<a cl
 <tr>
 <td>Feature</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00../../features/0593-json-ld-cred-attach">0593-json-ld-cred-attach</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 <tr>
 <td>Feature</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00../../features/0510-dif-pres-exch-attach">0510-dif-pres-exch-attach</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 </tbody>
 </table>
@@ -5207,17 +5312,17 @@ <h4 id="bbscred-bbs-based-credentials">BBSCRED: BBS+ Based Credentials<a class="
 <tr>
 <td>Feature</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00../../features/0593-json-ld-cred-attach">0593-json-ld-cred-attach</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 <tr>
 <td>Feature</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/blob/7a44f650d3cebf5b3047c1680618978393a497d5../../features/0646-bbs-credentials/README.md">0646-bbs-credentials</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 <tr>
 <td>Feature</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00../../features/0510-dif-pres-exch-attach">0510-dif-pres-exch-attach</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 </tbody>
 </table>
@@ -5234,7 +5339,7 @@ <h4 id="chat-chat-related-features">CHAT: Chat related ../../features<a class="h
 <tr>
 <td>Feature</td>
 <td><a href="https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00../../features/0095-basic-message">0095-basic-message</a></td>
-<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.0.3/assets/svg/1f195.svg" title=":new:" /></td>
+<td><img alt="🆕" class="twemoji" src="https://cdn.jsdelivr.net/gh/jdecked/twemoji@15.1.0/assets/svg/1f195.svg" title=":new:" /></td>
 </tr>
 </tbody>
 </table>
@@ -5462,7 +5567,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0345-community-coordinated-update/index.html b/main/concepts/0345-community-coordinated-update/index.html
index 91810c8a6..14b70cb53 100644
--- a/main/concepts/0345-community-coordinated-update/index.html
+++ b/main/concepts/0345-community-coordinated-update/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3479,6 +3479,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3647,6 +3668,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3689,6 +3731,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3704,6 +3767,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4851,7 +4956,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0346-didcomm-between-two-mobile-agents/index.html b/main/concepts/0346-didcomm-between-two-mobile-agents/index.html
index 8ff349d29..8c0c750ad 100644
--- a/main/concepts/0346-didcomm-between-two-mobile-agents/index.html
+++ b/main/concepts/0346-didcomm-between-two-mobile-agents/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3428,6 +3428,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3596,6 +3617,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3638,6 +3680,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3653,6 +3716,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4772,7 +4877,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0420-rich-schemas-common/index.html b/main/concepts/0420-rich-schemas-common/index.html
index 48607ac6a..9594fb5a1 100644
--- a/main/concepts/0420-rich-schemas-common/index.html
+++ b/main/concepts/0420-rich-schemas-common/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5129,7 +5234,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0430-machine-readable-governance-frameworks/gov-fw-covid-19/index.html b/main/concepts/0430-machine-readable-governance-frameworks/gov-fw-covid-19/index.html
index f87c3cc49..4b103cb6f 100644
--- a/main/concepts/0430-machine-readable-governance-frameworks/gov-fw-covid-19/index.html
+++ b/main/concepts/0430-machine-readable-governance-frameworks/gov-fw-covid-19/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -184,7 +184,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -402,7 +402,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -746,7 +746,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -767,7 +767,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -788,7 +788,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -809,7 +809,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -830,7 +830,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -851,7 +851,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -872,7 +872,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -893,7 +893,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -914,7 +914,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -935,7 +935,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -956,7 +956,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -977,7 +977,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -998,7 +998,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1019,7 +1019,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1040,7 +1040,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1061,7 +1061,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1082,7 +1082,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1103,7 +1103,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1124,7 +1124,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1145,7 +1145,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1166,7 +1166,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1208,7 +1208,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1229,7 +1229,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1271,7 +1271,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1292,7 +1292,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1313,7 +1313,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1355,7 +1355,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1376,7 +1376,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1397,7 +1397,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3302,6 +3302,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0559-pppu/" class="md-nav__link">
         
@@ -3470,6 +3491,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0757-push-notification/" class="md-nav__link">
         
@@ -3512,6 +3554,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../0799-long-term-support/" class="md-nav__link">
         
@@ -3527,6 +3590,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4525,7 +4630,7 @@ <h1>Gov fw covid 19</h1>
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0430-machine-readable-governance-frameworks/index.html b/main/concepts/0430-machine-readable-governance-frameworks/index.html
index affd0c434..3770f37c0 100644
--- a/main/concepts/0430-machine-readable-governance-frameworks/index.html
+++ b/main/concepts/0430-machine-readable-governance-frameworks/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3452,6 +3452,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3620,6 +3641,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3662,6 +3704,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3677,6 +3740,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5002,7 +5107,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0440-kms-architectures/index.html b/main/concepts/0440-kms-architectures/index.html
index bcfa7eb23..873922525 100644
--- a/main/concepts/0440-kms-architectures/index.html
+++ b/main/concepts/0440-kms-architectures/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3605,6 +3605,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3773,6 +3794,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3815,6 +3857,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3830,6 +3893,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5418,7 +5523,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0441-present-proof-best-practices/index.html b/main/concepts/0441-present-proof-best-practices/index.html
index 966e63176..0a67744bc 100644
--- a/main/concepts/0441-present-proof-best-practices/index.html
+++ b/main/concepts/0441-present-proof-best-practices/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3443,6 +3443,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3611,6 +3632,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3653,6 +3695,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3668,6 +3731,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4836,7 +4941,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0478-coprotocols/index.html b/main/concepts/0478-coprotocols/index.html
index f9678135d..67f9b3a27 100644
--- a/main/concepts/0478-coprotocols/index.html
+++ b/main/concepts/0478-coprotocols/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4917,7 +5022,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0519-goal-codes/index.html b/main/concepts/0519-goal-codes/index.html
index 83e6cd492..72fd087c7 100644
--- a/main/concepts/0519-goal-codes/index.html
+++ b/main/concepts/0519-goal-codes/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3488,6 +3488,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3656,6 +3677,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3698,6 +3740,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3713,6 +3776,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4933,7 +5038,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0530-goal-human-readable-verified-identifer/index.html b/main/concepts/0530-goal-human-readable-verified-identifer/index.html
index 51a4f32cc..6d00f53f3 100644
--- a/main/concepts/0530-goal-human-readable-verified-identifer/index.html
+++ b/main/concepts/0530-goal-human-readable-verified-identifer/index.html
@@ -12,11 +12,11 @@
         <link rel="prev" href="../../features/0511-dif-cred-manifest-attach/">
       
       
-        <link rel="next" href="../0559-pppu/">
+        <link rel="next" href="../0535-email-access-governance-framework/">
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3443,6 +3443,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3611,6 +3632,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3653,6 +3695,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3668,6 +3731,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4718,13 +4823,13 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
         
         
           
-          <a href="../0559-pppu/" class="md-footer__link md-footer__link--next" aria-label="Next: 0559 Privacy-Preserving Proof of Uniqueness">
+          <a href="../0535-email-access-governance-framework/" class="md-footer__link md-footer__link--next" aria-label="Next: 0535 Email Access Governance Framework">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                0559 Privacy-Preserving Proof of Uniqueness
+                0535 Email Access Governance Framework
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4761,7 +4866,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0535-email-access-governance-framework/data.json b/main/concepts/0535-email-access-governance-framework/data.json
new file mode 100644
index 000000000..fbccd0166
--- /dev/null
+++ b/main/concepts/0535-email-access-governance-framework/data.json
@@ -0,0 +1,12 @@
+{
+    "@context": ["https://github.com/hyperledger/aries-rfcs/blob/master/0430-machine-readable-governance-frameworks/context.jsonld"],
+    "name": "Email Access"
+    "version": "0.1",
+    "description": "Proof of email access, useful for proving a common identifier and/or validating an email address without performing a live loop-back test."
+    "last_updated": "2020-09-16",
+    "docs_uri": "http://github.com/hyperledger/aries-rfcs/blob/master/",
+    "data_uri": "<uri to machine readable portion of this example>",
+    "schemas": ["schemaidhere"],
+    "roles": ["issuer"], 
+    "rules": [ {"when": {"id": "did:example:abc123"}, "thus": "issuer"} ]
+}   
\ No newline at end of file
diff --git a/main/concepts/0535-email-access-governance-framework/index.html b/main/concepts/0535-email-access-governance-framework/index.html
new file mode 100644
index 000000000..9c7e61bbe
--- /dev/null
+++ b/main/concepts/0535-email-access-governance-framework/index.html
@@ -0,0 +1,5003 @@
+
+<!doctype html>
+<html lang="en" class="no-js">
+  <head>
+    
+      <meta charset="utf-8">
+      <meta name="viewport" content="width=device-width,initial-scale=1">
+      
+      
+      
+      
+        <link rel="prev" href="../0530-goal-human-readable-verified-identifer/">
+      
+      
+        <link rel="next" href="../0559-pppu/">
+      
+      
+      <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
+    
+    
+      
+        <title>0535 Email Access Governance Framework - Hyperledger Aries Interoperability Profiles / RFCs</title>
+      
+    
+    
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
+      
+        
+        <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
+      
+      
+
+
+    
+    
+      
+    
+    
+      
+        
+        
+        <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
+        <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto:300,300i,400,400i,700,700i%7CRoboto+Mono:400,400i,700,700i&display=fallback">
+        <style>:root{--md-text-font:"Roboto";--md-code-font:"Roboto Mono"}</style>
+      
+    
+    
+    <script>__md_scope=new URL("../..",location),__md_hash=e=>[...e].reduce(((e,_)=>(e<<5)-e+_.charCodeAt(0)),0),__md_get=(e,_=localStorage,t=__md_scope)=>JSON.parse(_.getItem(t.pathname+"."+e)),__md_set=(e,_,t=localStorage,a=__md_scope)=>{try{t.setItem(a.pathname+"."+e,JSON.stringify(_))}catch(e){}}</script>
+    
+      
+
+    
+    
+    
+  </head>
+  
+  
+    
+    
+      
+    
+    
+    
+    
+    <body dir="ltr" data-md-color-scheme="default" data-md-color-primary="green" data-md-color-accent="indigo">
+  
+    
+    <input class="md-toggle" data-md-toggle="drawer" type="checkbox" id="__drawer" autocomplete="off">
+    <input class="md-toggle" data-md-toggle="search" type="checkbox" id="__search" autocomplete="off">
+    <label class="md-overlay" for="__drawer"></label>
+    <div data-md-component="skip">
+      
+        
+        <a href="#0535-email-access-governance-framework" class="md-skip">
+          Skip to content
+        </a>
+      
+    </div>
+    <div data-md-component="announce">
+      
+    </div>
+    
+    
+      
+
+  
+
+<header class="md-header md-header--shadow md-header--lifted" data-md-component="header">
+  <nav class="md-header__inner md-grid" aria-label="Header">
+    <a href="../.." title="Hyperledger Aries Interoperability Profiles / RFCs" class="md-header__button md-logo" aria-label="Hyperledger Aries Interoperability Profiles / RFCs" data-md-component="logo">
+      
+  <img src="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/Hyperledger_Aries_Logo_White.png" alt="logo">
+
+    </a>
+    <label class="md-header__button md-icon" for="__drawer">
+      
+      <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M3 6h18v2H3zm0 5h18v2H3zm0 5h18v2H3z"/></svg>
+    </label>
+    <div class="md-header__title" data-md-component="header-title">
+      <div class="md-header__ellipsis">
+        <div class="md-header__topic">
+          <span class="md-ellipsis">
+            Hyperledger Aries Interoperability Profiles / RFCs
+          </span>
+        </div>
+        <div class="md-header__topic" data-md-component="header-topic">
+          <span class="md-ellipsis">
+            
+              0535 Email Access Governance Framework
+            
+          </span>
+        </div>
+      </div>
+    </div>
+    
+      
+        <form class="md-header__option" data-md-component="palette">
+  
+    
+    
+    
+    <input class="md-option" data-md-color-media="" data-md-color-scheme="default" data-md-color-primary="green" data-md-color-accent="indigo"  aria-hidden="true"  type="radio" name="__palette" id="__palette_0">
+    
+  
+    
+    
+    
+    <input class="md-option" data-md-color-media="(prefers-color-scheme: light)" data-md-color-scheme="default" data-md-color-primary="indigo" data-md-color-accent="indigo"  aria-label="Switch to dark mode"  type="radio" name="__palette" id="__palette_1">
+    
+      <label class="md-header__button md-icon" title="Switch to dark mode" for="__palette_2" hidden>
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 8a4 4 0 0 0-4 4 4 4 0 0 0 4 4 4 4 0 0 0 4-4 4 4 0 0 0-4-4m0 10a6 6 0 0 1-6-6 6 6 0 0 1 6-6 6 6 0 0 1 6 6 6 6 0 0 1-6 6m8-9.31V4h-4.69L12 .69 8.69 4H4v4.69L.69 12 4 15.31V20h4.69L12 23.31 15.31 20H20v-4.69L23.31 12z"/></svg>
+      </label>
+    
+  
+    
+    
+    
+    <input class="md-option" data-md-color-media="(prefers-color-scheme: dark)" data-md-color-scheme="slate" data-md-color-primary="indigo" data-md-color-accent="indigo"  aria-label="Switch to light mode"  type="radio" name="__palette" id="__palette_2">
+    
+      <label class="md-header__button md-icon" title="Switch to light mode" for="__palette_0" hidden>
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 18c-.89 0-1.74-.2-2.5-.55C11.56 16.5 13 14.42 13 12s-1.44-4.5-3.5-5.45C10.26 6.2 11.11 6 12 6a6 6 0 0 1 6 6 6 6 0 0 1-6 6m8-9.31V4h-4.69L12 .69 8.69 4H4v4.69L.69 12 4 15.31V20h4.69L12 23.31 15.31 20H20v-4.69L23.31 12z"/></svg>
+      </label>
+    
+  
+</form>
+      
+    
+    
+      <script>var palette=__md_get("__palette");if(palette&&palette.color){if("(prefers-color-scheme)"===palette.color.media){var media=matchMedia("(prefers-color-scheme: light)"),input=document.querySelector(media.matches?"[data-md-color-media='(prefers-color-scheme: light)']":"[data-md-color-media='(prefers-color-scheme: dark)']");palette.color.media=input.getAttribute("data-md-color-media"),palette.color.scheme=input.getAttribute("data-md-color-scheme"),palette.color.primary=input.getAttribute("data-md-color-primary"),palette.color.accent=input.getAttribute("data-md-color-accent")}for(var[key,value]of Object.entries(palette.color))document.body.setAttribute("data-md-color-"+key,value)}</script>
+    
+    
+    
+      <label class="md-header__button md-icon" for="__search">
+        
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+      </label>
+      <div class="md-search" data-md-component="search" role="dialog">
+  <label class="md-search__overlay" for="__search"></label>
+  <div class="md-search__inner" role="search">
+    <form class="md-search__form" name="search">
+      <input type="text" class="md-search__input" name="query" aria-label="Search" placeholder="Search" autocapitalize="off" autocorrect="off" autocomplete="off" spellcheck="false" data-md-component="search-query" required>
+      <label class="md-search__icon md-icon" for="__search">
+        
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+        
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
+      </label>
+      <nav class="md-search__options" aria-label="Search">
+        
+        <button type="reset" class="md-search__icon md-icon" title="Clear" aria-label="Clear" tabindex="-1">
+          
+          <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M19 6.41 17.59 5 12 10.59 6.41 5 5 6.41 10.59 12 5 17.59 6.41 19 12 13.41 17.59 19 19 17.59 13.41 12z"/></svg>
+        </button>
+      </nav>
+      
+    </form>
+    <div class="md-search__output">
+      <div class="md-search__scrollwrap" tabindex="0" data-md-scrollfix>
+        <div class="md-search-result" data-md-component="search-result">
+          <div class="md-search-result__meta">
+            Initializing search
+          </div>
+          <ol class="md-search-result__list" role="presentation"></ol>
+        </div>
+      </div>
+    </div>
+  </div>
+</div>
+    
+    
+      <div class="md-header__source">
+        <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
+  <div class="md-source__icon md-icon">
+    
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+  </div>
+  <div class="md-source__repository">
+    hyperledger/aries-rfcs
+  </div>
+</a>
+      </div>
+    
+  </nav>
+  
+    
+      
+<nav class="md-tabs" aria-label="Tabs" data-md-component="tabs">
+  <div class="md-grid">
+    <ul class="md-tabs__list">
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../.." class="md-tabs__link">
+          
+  
+  Welcome
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../MAINTAINERS/" class="md-tabs__link">
+          
+  
+  Governance
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../aip2/0003-protocols/" class="md-tabs__link">
+          
+  
+  AIP 2.0
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../0003-protocols/" class="md-tabs__link">
+          
+  
+  ADOPTED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../0004-agents/" class="md-tabs__link">
+          
+  
+  ACCEPTED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../features/0032-message-timing/" class="md-tabs__link">
+          
+  
+  DEMONSTRATED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+    
+  
+  
+    
+    
+      <li class="md-tabs__item md-tabs__item--active">
+        <a href="../../features/0028-introduce/" class="md-tabs__link">
+          
+  
+  PROPOSED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../features/0024-didcomm-over-xmpp/" class="md-tabs__link">
+          
+  
+  STALLED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../0013-overlays/" class="md-tabs__link">
+          
+  
+  RETIRED
+
+        </a>
+      </li>
+    
+  
+
+      
+    </ul>
+  </div>
+</nav>
+    
+  
+</header>
+    
+    <div class="md-container" data-md-component="container">
+      
+      
+        
+      
+      <main class="md-main" data-md-component="main">
+        <div class="md-main__inner md-grid">
+          
+            
+              
+              <div class="md-sidebar md-sidebar--primary" data-md-component="sidebar" data-md-type="navigation" >
+                <div class="md-sidebar__scrollwrap">
+                  <div class="md-sidebar__inner">
+                    
+
+
+  
+
+
+<nav class="md-nav md-nav--primary md-nav--lifted" aria-label="Navigation" data-md-level="0">
+  <label class="md-nav__title" for="__drawer">
+    <a href="../.." title="Hyperledger Aries Interoperability Profiles / RFCs" class="md-nav__button md-logo" aria-label="Hyperledger Aries Interoperability Profiles / RFCs" data-md-component="logo">
+      
+  <img src="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/Hyperledger_Aries_Logo_White.png" alt="logo">
+
+    </a>
+    Hyperledger Aries Interoperability Profiles / RFCs
+  </label>
+  
+    <div class="md-nav__source">
+      <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
+  <div class="md-source__icon md-icon">
+    
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+  </div>
+  <div class="md-source__repository">
+    hyperledger/aries-rfcs
+  </div>
+</a>
+    </div>
+  
+  <ul class="md-nav__list" data-md-scrollfix>
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_1" >
+        
+          
+          <label class="md-nav__link" for="__nav_1" id="__nav_1_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    Welcome
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_1_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_1">
+            <span class="md-nav__icon md-icon"></span>
+            Welcome
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../.." class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Welcome
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../RFCindex/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    All RFCs by Status
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0000-template/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    RFC Template
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0000-template-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Protocol RFC Template
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_2" >
+        
+          
+          <label class="md-nav__link" for="__nav_2" id="__nav_2_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    Governance
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_2_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_2">
+            <span class="md-nav__icon md-icon"></span>
+            Governance
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../MAINTAINERS/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Maintainers
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../contributing/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Contributing
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../github-issues/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Submitting Issues
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../LICENSE/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    License
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../SECURITY/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Security
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_3" >
+        
+          
+          <label class="md-nav__link" for="__nav_3" id="__nav_3_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    AIP 2.0
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_3_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_3">
+            <span class="md-nav__icon md-icon"></span>
+            AIP 2.0
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0003-protocols/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0003 Protocols
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0004-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0004 Agents
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0005-didcomm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0005 DID Communication
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0008-message-id-and-threading/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0008 Message ID and Threading
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0011-decorators/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0011 Decorators
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0015-acks/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0015 ACKs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0017-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0017 Attachments
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0019-encryption-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0019 Encryption Envelope
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0020-message-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0020 Message Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0023-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0023 DID Exchange Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0025-didcomm-transports/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0025 DIDComm Transports
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0035-report-problem/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0035 Report Problem Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0044-didcomm-file-and-mime-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0044 DIDComm File and MIME Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0046-mediators-and-relays/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0046 Mediators and Relays
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0047-json-ld-compatibility/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0047 JSON-LD Compatibility
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0048-trust-ping/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0048 Trust Ping Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0050-wallets/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0050 Wallets
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0092-transport-return-route/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0092 Transports Return Route
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0094-cross-domain-messaging/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0094 Cross-Domain Messaging
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0095-basic-message/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0095 Basic Message Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0183-revocation-notification/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0183 Revocation Notification 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0211-route-coordination/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0211 Mediator Coordination Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0360-use-did-key/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0360 did:key Usage
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0434-outofband/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0434 Out-of-Band Protocol 1.1
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0441-present-proof-best-practices/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0441 Prover and Verifier Best Practices for Proof Presentation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0453-issue-credential-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0453 Issue Credential Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0454-present-proof-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0454 Present Proof Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0510-dif-pres-exch-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0519-goal-codes/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0519 Goal Codes
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0557-discover-features-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0557 Discover Features Protocol v2.x
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0592-indy-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0593-json-ld-cred-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_4" >
+        
+          
+          <label class="md-nav__link" for="__nav_4" id="__nav_4_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    ADOPTED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_4_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_4">
+            <span class="md-nav__icon md-icon"></span>
+            ADOPTED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0003-protocols/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0003 Protocols
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0005-didcomm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0005 DID Communication
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0008-message-id-and-threading/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0008 Message ID and Threading
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0011-decorators/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0011 Decorators
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0015-acks/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0015 ACKs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0017-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0017 Attachments
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0019-encryption-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0019 Encryption Envelope
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0020-message-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0020 Message Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0021-didcomm-message-anatomy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0021 DIDComm Message Anatomy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0023-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0023 DID Exchange v1
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0025-didcomm-transports/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0025 DIDComm Transports
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0031-discover-features/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0031 Discover Features Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0035-report-problem/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0035 Report Problem Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0036-issue-credential/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0036 Issue Credential Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0037-present-proof/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0037 Present Proof Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0048-trust-ping/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0048 Trust Ping Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0092-transport-return-route/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0092 Transports Return Route
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0094-cross-domain-messaging/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0094 Cross-Domain Messaging
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0095-basic-message/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0095 Basic Message Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0160-connection-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0160 Connection Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0211-route-coordination/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0211 Mediator Coordination Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0302-aries-interop-profile/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0302 Aries Interop Profile
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0360-use-did-key/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0360 did:key Usage
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0434-outofband/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0434 Out-of-Band Protocol 1.1
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0441-present-proof-best-practices/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0441 Prover and Verifier Best Practices for Proof Presentation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0453-issue-credential-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0453 Issue Credential Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0454-present-proof-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0454 Present Proof Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0496-transition-to-oob-and-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0496 Transition to the Out of Band Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0510-dif-pres-exch-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0557-discover-features-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0557 Discover Features Protocol v2.x
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0592-indy-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0593-json-ld-cred-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_5" >
+        
+          
+          <label class="md-nav__link" for="__nav_5" id="__nav_5_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    ACCEPTED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_5_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_5">
+            <span class="md-nav__icon md-icon"></span>
+            ACCEPTED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0004-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0004 Agents
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0006-ssi-notation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0006 SSI Notation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0044-didcomm-file-and-mime-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0044 DIDComm File and MIME Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0046-mediators-and-relays/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0046 Mediators and Relays
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0047-json-ld-compatibility/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0047 JSON-LD Compatibility
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0049-repudiation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0049 Repudiation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0050-wallets/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0050 Wallets
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0183-revocation-notification/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0183 Revocation Notification 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0519-goal-codes/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0519 Goal Codes
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0587-encryption-envelope-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0587 Encryption Envelope v2
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0646-bbs-credentials/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0646 W3C Credential Exchange using BBS+ Signatures
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0685-pickup-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0685 Pickup Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0721-revocation-notification-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0721 Revocation Notification 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0793-unqualfied-dids-transition/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0793 Unqualified DID Transition
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0794-did-rotate/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0794 DID Rotate 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_6" >
+        
+          
+          <label class="md-nav__link" for="__nav_6" id="__nav_6_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    DEMONSTRATED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_6_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_6">
+            <span class="md-nav__icon md-icon"></span>
+            DEMONSTRATED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0032-message-timing/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0032 Message Timing
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0042-lox/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0042 LOX -- A more secure pluggable framework for protecting wallet keys
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0043-l10n/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0043 l10n (Locali[s|z]ation)
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0113-question-answer/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0113 Question Answer Protocol 0.9
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0509-action-menu/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0509 Action Menu Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0748-n-wise-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0748 N-wise DID Exchange Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0755-oca-for-aries/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0755 Overlays Capture Architecture (OCA) For Aries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0756-oca-for-aries-style-guide/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0756 OCA for Aries Style Guide
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0780-data-urls-images/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0780 Use Data URLs for Images and More in Credential Attributes
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0804-didcomm-rpc/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0804 DIDComm Remote Procedure Call (DRPC)
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0809-w3c-data-integrity-credential-attachment/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0809 W3C Verifiable Credential Data Integrity Attachment format for requesting and issuing credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+    
+  
+  
+  
+    
+    
+    
+      
+        
+        
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--active md-nav__item--section md-nav__item--nested">
+      
+        
+        
+        <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_7" checked>
+        
+          
+          <label class="md-nav__link" for="__nav_7" id="__nav_7_label" tabindex="">
+            
+  
+  <span class="md-ellipsis">
+    PROPOSED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_7_label" aria-expanded="true">
+          <label class="md-nav__title" for="__nav_7">
+            <span class="md-nav__icon md-icon"></span>
+            PROPOSED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0028-introduce/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0028 Introduce Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0034-message-tracing/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0034 Message Tracing
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0056-service-decorator/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0056 Service Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0066-non-repudiable-cryptographic-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0066 Non-Repudiable Signature for Cryptographic Envelope
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0067-didcomm-diddoc-conventions/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0067 DIDComm DID document conventions
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0074-didcomm-best-practices/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0074 DIDComm Best Practices
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0103-indirect-identity-control/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0103 Indirect Identity Control
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0104-chained-credentials/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0104 Chained Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0124-did-resolution-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0124 DID Resolution Protocol 0.9
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0167-data-consent-lifecycle/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0167 Data Consent Lifecycle
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0212-pickup/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0212 Pickup Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0213-transfer-policy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0213 Transfer Policy Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0214-help-me-discover/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0214 "Help Me Discover" Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0231-biometric-service-provider/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0231 Biometric Service Provider
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0268-unified-didcomm-agent-deeplinking/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0268 Unified DIDCOMM Deeplinking
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0270-interop-test-suite/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0270 Interop Test Suite
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0345-community-coordinated-update/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0345 Community Coordinated Update
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0346-didcomm-between-two-mobile-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0346 DIDComm Between Two Mobile Agents Using Cloud Agent Mediator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0347-proof-negotiation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0347 Proof Negotiation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0430-machine-readable-governance-frameworks/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0430 Machine-Readable Governance Frameworks
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0440-kms-architectures/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0440 KMS Architectures
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0511-dif-cred-manifest-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0511 Credential-Manifest Attachment format for requesting and presenting credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0530-goal-human-readable-verified-identifer/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0530 Goal - Human Readable Verifiable Identifier
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+    
+  
+  
+  
+    <li class="md-nav__item md-nav__item--active">
+      
+      <input class="md-nav__toggle md-toggle" type="checkbox" id="__toc">
+      
+      
+        
+      
+      
+        <label class="md-nav__link md-nav__link--active" for="__toc">
+          
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+          <span class="md-nav__icon md-icon"></span>
+        </label>
+      
+      <a href="./" class="md-nav__link md-nav__link--active">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+      
+        
+
+<nav class="md-nav md-nav--secondary" aria-label="Table of contents">
+  
+  
+  
+    
+  
+  
+    <label class="md-nav__title" for="__toc">
+      <span class="md-nav__icon md-icon"></span>
+      Table of contents
+    </label>
+    <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
+      
+        <li class="md-nav__item">
+  <a href="#summary" class="md-nav__link">
+    <span class="md-ellipsis">
+      Summary
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#purpose" class="md-nav__link">
+    <span class="md-ellipsis">
+      Purpose
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#details" class="md-nav__link">
+    <span class="md-ellipsis">
+      Details
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Details">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#goal-codes" class="md-nav__link">
+    <span class="md-ellipsis">
+      Goal Codes
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#protocols" class="md-nav__link">
+    <span class="md-ellipsis">
+      Protocols
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#roles" class="md-nav__link">
+    <span class="md-ellipsis">
+      Roles
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#schemas" class="md-nav__link">
+    <span class="md-ellipsis">
+      Schemas
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#issuers" class="md-nav__link">
+    <span class="md-ellipsis">
+      Issuers
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#issue-requirements" class="md-nav__link">
+    <span class="md-ellipsis">
+      Issue Requirements
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#revocation" class="md-nav__link">
+    <span class="md-ellipsis">
+      Revocation
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#allowable-verification-purposes" class="md-nav__link">
+    <span class="md-ellipsis">
+      Allowable Verification Purposes
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#machine-readable-document" class="md-nav__link">
+    <span class="md-ellipsis">
+      Machine Readable Document
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#notes" class="md-nav__link">
+    <span class="md-ellipsis">
+      Notes
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#unresolved-questions" class="md-nav__link">
+    <span class="md-ellipsis">
+      Unresolved questions
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#uses" class="md-nav__link">
+    <span class="md-ellipsis">
+      Uses
+    </span>
+  </a>
+  
+</li>
+      
+    </ul>
+  
+</nav>
+      
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0559-pppu/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0559 Privacy-Preserving Proof of Uniqueness
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0566-issuer-hosted-custodidal-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0566 Issuer-Hosted Custodial Agents
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0641-linking-binary-objects-to-credentials/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0641 Linking binary objects to credentials using hash based references
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0693-credential-representation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0693 Cross-Platform Credential Representation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0699-push-notifications-apns/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0699 Push Notifications apns Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0700-oob-through-redirect/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0700 Out-of-Band through redirect
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0728-device-binding-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0728 Device Binding Attachments
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0734-push-notifications-fcm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0734 Push Notifications fcm Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0757-push-notification/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0757 Push Notification
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0771-anoncreds-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0771 AnonCreds Attachment Formats for Requesting and Presenting Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0799-long-term-support/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0799 Aries Long Term Support Releases
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_8" >
+        
+          
+          <label class="md-nav__link" for="__nav_8" id="__nav_8_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    STALLED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_8_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_8">
+            <span class="md-nav__icon md-icon"></span>
+            STALLED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0024-didcomm-over-xmpp/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0024 DIDComm over XMPP
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0029-message-trust-contexts/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0029 Message Trust Contexts
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0030-sync-connection/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0030 Sync Connection Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0075-payment-decorators/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0075 Payment Decorators
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0114-predefined-identities/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0114 Predefined Identities
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0116-evidence-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0116 Evidence Exchange Protocol 0.9
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0193-coin-flip/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0193 Coin Flip Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0207-credential-fraud-threat-model/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0207 Credential Fraud Threat Model
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0217-linkable-message-paths/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0217 Linkable Message Paths
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0249-rich-schema-contexts/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0249 Aries Rich Schema Contexts
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0250-rich-schemas/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0250 Rich Schema Objects
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0257-private-credential-issuance/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0257 Private Credential Issuance
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0281-rich-schemas/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0281 Aries Rich Schemas
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0289-toip-stack/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0289 The Trust Over IP Stack
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0309-didauthz/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0309 DIDAuthZ
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0327-crypto-service/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0327 Crypto service Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0334-jwe-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0334 JWE envelope 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0335-http-over-didcomm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0335 HTTP Over DIDComm
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0351-purpose-decorator/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0351 Purpose Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0418-rich-schema-encoding/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0418 Aries Rich Schema Encoding Objects
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0420-rich-schemas-common/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0420 Rich Schema Objects Common
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0428-prepare-issue-rich-credential/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0428 Prerequisites to Issue Rich Credential
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0429-prepare-req-rich-pres/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0429 Prerequisites to Request Rich Presentation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0445-rich-schema-mapping/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0445 Aries Rich Schema Mapping
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0446-rich-schema-cred-def/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0446 Aries Rich Schema Credential Definition
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0478-coprotocols/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0478 Coprotocols
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0482-coprotocol-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0482 Coprotocol Protocol 0.5
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_9" >
+        
+          
+          <label class="md-nav__link" for="__nav_9" id="__nav_9_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    RETIRED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_9_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_9">
+            <span class="md-nav__icon md-icon"></span>
+            RETIRED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0013-overlays/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0013 Overlays
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0051-dkms/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0051 Decentralized Key Management
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0234-signature-decorator/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0234 Signature Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0303-v01-credential-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0303 V0.1 Credential Exchange (Deprecated)
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0317-please-ack/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0317 Please ACK Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0348-transition-msg-type-to-https/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0348 Transition Message Type to HTTPs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0627-static-peer-dids/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0627 Static Peer DIDs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+  </ul>
+</nav>
+                  </div>
+                </div>
+              </div>
+            
+            
+              
+              <div class="md-sidebar md-sidebar--secondary" data-md-component="sidebar" data-md-type="toc" >
+                <div class="md-sidebar__scrollwrap">
+                  <div class="md-sidebar__inner">
+                    
+
+<nav class="md-nav md-nav--secondary" aria-label="Table of contents">
+  
+  
+  
+    
+  
+  
+    <label class="md-nav__title" for="__toc">
+      <span class="md-nav__icon md-icon"></span>
+      Table of contents
+    </label>
+    <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
+      
+        <li class="md-nav__item">
+  <a href="#summary" class="md-nav__link">
+    <span class="md-ellipsis">
+      Summary
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#purpose" class="md-nav__link">
+    <span class="md-ellipsis">
+      Purpose
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#details" class="md-nav__link">
+    <span class="md-ellipsis">
+      Details
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Details">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#goal-codes" class="md-nav__link">
+    <span class="md-ellipsis">
+      Goal Codes
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#protocols" class="md-nav__link">
+    <span class="md-ellipsis">
+      Protocols
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#roles" class="md-nav__link">
+    <span class="md-ellipsis">
+      Roles
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#schemas" class="md-nav__link">
+    <span class="md-ellipsis">
+      Schemas
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#issuers" class="md-nav__link">
+    <span class="md-ellipsis">
+      Issuers
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#issue-requirements" class="md-nav__link">
+    <span class="md-ellipsis">
+      Issue Requirements
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#revocation" class="md-nav__link">
+    <span class="md-ellipsis">
+      Revocation
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#allowable-verification-purposes" class="md-nav__link">
+    <span class="md-ellipsis">
+      Allowable Verification Purposes
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#machine-readable-document" class="md-nav__link">
+    <span class="md-ellipsis">
+      Machine Readable Document
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#notes" class="md-nav__link">
+    <span class="md-ellipsis">
+      Notes
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#unresolved-questions" class="md-nav__link">
+    <span class="md-ellipsis">
+      Unresolved questions
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#uses" class="md-nav__link">
+    <span class="md-ellipsis">
+      Uses
+    </span>
+  </a>
+  
+</li>
+      
+    </ul>
+  
+</nav>
+                  </div>
+                </div>
+              </div>
+            
+          
+          
+            <div class="md-content" data-md-component="content">
+              <article class="md-content__inner md-typeset">
+                
+                  
+
+  
+  
+
+
+<h1 id="0535-email-access-governance-framework">0535: Email Access Governance Framework<a class="headerlink" href="#0535-email-access-governance-framework" title="Permanent link">&para;</a></h1>
+<ul>
+<li>Authors: <a href="mailto:telegramsam@gmail.com">Sam Curren</a></li>
+<li>Status: <a href="../../#proposed">PROPOSED</a></li>
+<li>Since: 2020-09-16</li>
+<li>Status Note: Proposed, but in need of specifics to put into action.</li>
+<li>Start Date: 2020-07-14</li>
+<li>Tags: feature, protocol</li>
+</ul>
+<h2 id="summary">Summary<a class="headerlink" href="#summary" title="Permanent link">&para;</a></h2>
+<blockquote>
+<p>Note: This RFC was created in advance of the <a href="https://identity.foundation/credential-trust-establishment/">Credential Trust Establishment</a> spec work at the DIF. The ../../concepts are good, but the governance mechanism should be updated to use this newer spec before action is taken.</p>
+</blockquote>
+<p>This Governance Framework is community managed.</p>
+<p>When making connections from one person to another over DIDComm, it is useful to be able to gain proof of something to verify that the connection is with the right person and has not been subject to a MITM attack. We expect this Governance Framework to be one of many used for the purpose of helping to verify identity attributes in the creation of trusted channels.</p>
+<p>This is an early attempt at the creation and use of of a practical governance framework. As Governance Framework technology improves, we expect this particular framework to be replaced.</p>
+<h2 id="purpose">Purpose<a class="headerlink" href="#purpose" title="Permanent link">&para;</a></h2>
+<p>To facilitate the verification of email access between two parties over DIDComm and related technologies.</p>
+<h2 id="details">Details<a class="headerlink" href="#details" title="Permanent link">&para;</a></h2>
+<h3 id="goal-codes">Goal Codes<a class="headerlink" href="#goal-codes" title="Permanent link">&para;</a></h3>
+<p>This Governance framework satisfies the following goal code(s):</p>
+<p><code>aries.receive.verifiable.identifier</code></p>
+<h3 id="protocols">Protocols<a class="headerlink" href="#protocols" title="Permanent link">&para;</a></h3>
+<p><code>https://didcomm.org/present-proof/2.0/</code></p>
+<h3 id="roles">Roles<a class="headerlink" href="#roles" title="Permanent link">&para;</a></h3>
+<p><strong>issuer</strong>: Responsible for issuing credentials according to the requirements of this governance framework.</p>
+<h3 id="schemas">Schemas<a class="headerlink" href="#schemas" title="Permanent link">&para;</a></h3>
+<p><em>TODO: schemas listed here</em></p>
+<h3 id="issuers">Issuers<a class="headerlink" href="#issuers" title="Permanent link">&para;</a></h3>
+<p>BCGov (DID?)</p>
+<h3 id="issue-requirements">Issue Requirements<a class="headerlink" href="#issue-requirements" title="Permanent link">&para;</a></h3>
+<p>Issuers must validate email ownership by sending an email to the email address in question. The email MUST contain a link for the user to click, or a code to be entered in a verification step. After verifying that the clicked link or entered code matches, the credential may be issued.</p>
+<p>Issued credentials should indicate an expiration date no longer than 6 months from the date of verification.</p>
+<h3 id="revocation">Revocation<a class="headerlink" href="#revocation" title="Permanent link">&para;</a></h3>
+<p>This framework does not currently use revocation, relying upon the expiration date to prevent widespread issues.</p>
+<h3 id="allowable-verification-purposes">Allowable Verification Purposes<a class="headerlink" href="#allowable-verification-purposes" title="Permanent link">&para;</a></h3>
+<p>Email addresses revealed in this manner may be used for the following purposes:</p>
+<ul>
+<li>Displaying to recipient.</li>
+<li>Checking against address book.</li>
+</ul>
+<p>Use outside these purposes, including the following examples, violates the allowed uses as specified by this governance framework.</p>
+<ul>
+<li>Sending email to the address without explicit additional approval of the user.</li>
+<li>Sharing email address with any other party.</li>
+</ul>
+<h3 id="machine-readable-document">Machine Readable Document<a class="headerlink" href="#machine-readable-document" title="Permanent link">&para;</a></h3>
+<p>Located <a href="data.json">here</a>.</p>
+<h2 id="notes">Notes<a class="headerlink" href="#notes" title="Permanent link">&para;</a></h2>
+<ul>
+<li>The machine readable document is as simple as possible by design. As related technology improves, the document will be updated to reflect these changes.</li>
+<li>Code for the indy email verification service: <a href="https://github.com/bcgov/indy-email-verification">https://github.com/bcgov/indy-email-verification</a> that could be used as a basis for an issuer.</li>
+</ul>
+<h2 id="unresolved-questions">Unresolved questions<a class="headerlink" href="#unresolved-questions" title="Permanent link">&para;</a></h2>
+<ul>
+<li>Which networks?</li>
+<li>Need Schemas and Issuers</li>
+</ul>
+<h2 id="uses">Uses<a class="headerlink" href="#uses" title="Permanent link">&para;</a></h2>
+<p>The following libraries or applications use this Governance Framework.</p>
+<table>
+<thead>
+<tr>
+<th>Name / Link</th>
+<th>Implementation Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td></td>
+<td></td>
+</tr>
+</tbody>
+</table>
+
+
+
+
+
+
+
+
+
+
+
+
+                
+              </article>
+            </div>
+          
+          
+<script>var target=document.getElementById(location.hash.slice(1));target&&target.name&&(target.checked=target.name.startsWith("__tabbed_"))</script>
+        </div>
+        
+          <button type="button" class="md-top md-icon" data-md-component="top" hidden>
+  
+  <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M13 20h-2V8l-5.5 5.5-1.42-1.42L12 4.16l7.92 7.92-1.42 1.42L13 8z"/></svg>
+  Back to top
+</button>
+        
+      </main>
+      
+        <footer class="md-footer">
+  
+    
+      
+      <nav class="md-footer__inner md-grid" aria-label="Footer" >
+        
+          
+          <a href="../0530-goal-human-readable-verified-identifer/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0530 Goal - Human Readable Verifiable Identifier">
+            <div class="md-footer__button md-icon">
+              
+              <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
+            </div>
+            <div class="md-footer__title">
+              <span class="md-footer__direction">
+                Previous
+              </span>
+              <div class="md-ellipsis">
+                0530 Goal - Human Readable Verifiable Identifier
+              </div>
+            </div>
+          </a>
+        
+        
+          
+          <a href="../0559-pppu/" class="md-footer__link md-footer__link--next" aria-label="Next: 0559 Privacy-Preserving Proof of Uniqueness">
+            <div class="md-footer__title">
+              <span class="md-footer__direction">
+                Next
+              </span>
+              <div class="md-ellipsis">
+                0559 Privacy-Preserving Proof of Uniqueness
+              </div>
+            </div>
+            <div class="md-footer__button md-icon">
+              
+              <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M4 11v2h12l-5.5 5.5 1.42 1.42L19.84 12l-7.92-7.92L10.5 5.5 16 11z"/></svg>
+            </div>
+          </a>
+        
+      </nav>
+    
+  
+  <div class="md-footer-meta md-typeset">
+    <div class="md-footer-meta__inner md-grid">
+      <div class="md-copyright">
+  
+  
+    Made with
+    <a href="https://squidfunk.github.io/mkdocs-material/" target="_blank" rel="noopener">
+      Material for MkDocs
+    </a>
+  
+</div>
+      
+    </div>
+  </div>
+</footer>
+      
+    </div>
+    <div class="md-dialog" data-md-component="dialog">
+      <div class="md-dialog__inner md-typeset"></div>
+    </div>
+    
+    
+    <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
+    
+    
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
+      
+    
+  </body>
+</html>
\ No newline at end of file
diff --git a/main/concepts/0559-pppu/index.html b/main/concepts/0559-pppu/index.html
index 452d89365..778658692 100644
--- a/main/concepts/0559-pppu/index.html
+++ b/main/concepts/0559-pppu/index.html
@@ -9,14 +9,14 @@
       
       
       
-        <link rel="prev" href="../0530-goal-human-readable-verified-identifer/">
+        <link rel="prev" href="../0535-email-access-governance-framework/">
       
       
         <link rel="next" href="../0566-issuer-hosted-custodidal-agents/">
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3314,6 +3314,27 @@
                 
   
   
+  
+  
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
     
   
   
@@ -3611,6 +3632,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3653,6 +3695,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3668,6 +3731,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4822,7 +4927,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../0530-goal-human-readable-verified-identifer/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0530 Goal - Human Readable Verifiable Identifier">
+          <a href="../0535-email-access-governance-framework/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0535 Email Access Governance Framework">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4832,7 +4937,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                0530 Goal - Human Readable Verifiable Identifier
+                0535 Email Access Governance Framework
               </div>
             </div>
           </a>
@@ -4882,7 +4987,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0566-issuer-hosted-custodidal-agents/index.html b/main/concepts/0566-issuer-hosted-custodidal-agents/index.html
index 4f3540d5e..4873d2c3f 100644
--- a/main/concepts/0566-issuer-hosted-custodidal-agents/index.html
+++ b/main/concepts/0566-issuer-hosted-custodidal-agents/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3316,6 +3316,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3707,6 +3728,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3749,6 +3791,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3764,6 +3827,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4985,7 +5090,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0700-oob-through-redirect/index.html b/main/concepts/0700-oob-through-redirect/index.html
index 521cd686d..c388f6944 100644
--- a/main/concepts/0700-oob-through-redirect/index.html
+++ b/main/concepts/0700-oob-through-redirect/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3316,6 +3316,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3620,6 +3641,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3662,6 +3704,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3677,6 +3740,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4879,7 +4984,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0757-push-notification/index.html b/main/concepts/0757-push-notification/index.html
index eac0f671a..5eaef35e3 100644
--- a/main/concepts/0757-push-notification/index.html
+++ b/main/concepts/0757-push-notification/index.html
@@ -9,14 +9,14 @@
       
       
       
-        <link rel="prev" href="../../features/0734-push-notifications-fcm/">
+        <link rel="prev" href="../../features/0745-push-notifications-expo/">
       
       
         <link rel="next" href="../../features/0771-anoncreds-attachments/">
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3316,6 +3316,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3482,6 +3503,27 @@
                 
   
   
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
     
   
   
@@ -3626,6 +3668,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0799-long-term-support/" class="md-nav__link">
         
@@ -3641,6 +3704,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4651,7 +4756,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../../features/0734-push-notifications-fcm/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0734 Push Notifications fcm Protocol 1.0">
+          <a href="../../features/0745-push-notifications-expo/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0745 Push Notifications Expo Protocol 1.0">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4661,7 +4766,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                0734 Push Notifications fcm Protocol 1.0
+                0745 Push Notifications Expo Protocol 1.0
               </div>
             </div>
           </a>
@@ -4711,7 +4816,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0781-trust-input-protocol/Test b/main/concepts/0781-trust-input-protocol/Test
new file mode 100644
index 000000000..9c558e357
--- /dev/null
+++ b/main/concepts/0781-trust-input-protocol/Test
@@ -0,0 +1 @@
+.
diff --git a/main/concepts/0781-trust-input-protocol/index.html b/main/concepts/0781-trust-input-protocol/index.html
new file mode 100644
index 000000000..faab48fb2
--- /dev/null
+++ b/main/concepts/0781-trust-input-protocol/index.html
@@ -0,0 +1,4966 @@
+
+<!doctype html>
+<html lang="en" class="no-js">
+  <head>
+    
+      <meta charset="utf-8">
+      <meta name="viewport" content="width=device-width,initial-scale=1">
+      
+      
+      
+      
+        <link rel="prev" href="../../features/0771-anoncreds-attachments/">
+      
+      
+        <link rel="next" href="../0799-long-term-support/">
+      
+      
+      <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
+    
+    
+      
+        <title>0781 Trust Input Protocol - Hyperledger Aries Interoperability Profiles / RFCs</title>
+      
+    
+    
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
+      
+        
+        <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
+      
+      
+
+
+    
+    
+      
+    
+    
+      
+        
+        
+        <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
+        <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto:300,300i,400,400i,700,700i%7CRoboto+Mono:400,400i,700,700i&display=fallback">
+        <style>:root{--md-text-font:"Roboto";--md-code-font:"Roboto Mono"}</style>
+      
+    
+    
+    <script>__md_scope=new URL("../..",location),__md_hash=e=>[...e].reduce(((e,_)=>(e<<5)-e+_.charCodeAt(0)),0),__md_get=(e,_=localStorage,t=__md_scope)=>JSON.parse(_.getItem(t.pathname+"."+e)),__md_set=(e,_,t=localStorage,a=__md_scope)=>{try{t.setItem(a.pathname+"."+e,JSON.stringify(_))}catch(e){}}</script>
+    
+      
+
+    
+    
+    
+  </head>
+  
+  
+    
+    
+      
+    
+    
+    
+    
+    <body dir="ltr" data-md-color-scheme="default" data-md-color-primary="green" data-md-color-accent="indigo">
+  
+    
+    <input class="md-toggle" data-md-toggle="drawer" type="checkbox" id="__drawer" autocomplete="off">
+    <input class="md-toggle" data-md-toggle="search" type="checkbox" id="__search" autocomplete="off">
+    <label class="md-overlay" for="__drawer"></label>
+    <div data-md-component="skip">
+      
+        
+        <a href="#rfc-0781-trust-input-protocol" class="md-skip">
+          Skip to content
+        </a>
+      
+    </div>
+    <div data-md-component="announce">
+      
+    </div>
+    
+    
+      
+
+  
+
+<header class="md-header md-header--shadow md-header--lifted" data-md-component="header">
+  <nav class="md-header__inner md-grid" aria-label="Header">
+    <a href="../.." title="Hyperledger Aries Interoperability Profiles / RFCs" class="md-header__button md-logo" aria-label="Hyperledger Aries Interoperability Profiles / RFCs" data-md-component="logo">
+      
+  <img src="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/Hyperledger_Aries_Logo_White.png" alt="logo">
+
+    </a>
+    <label class="md-header__button md-icon" for="__drawer">
+      
+      <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M3 6h18v2H3zm0 5h18v2H3zm0 5h18v2H3z"/></svg>
+    </label>
+    <div class="md-header__title" data-md-component="header-title">
+      <div class="md-header__ellipsis">
+        <div class="md-header__topic">
+          <span class="md-ellipsis">
+            Hyperledger Aries Interoperability Profiles / RFCs
+          </span>
+        </div>
+        <div class="md-header__topic" data-md-component="header-topic">
+          <span class="md-ellipsis">
+            
+              0781 Trust Input Protocol
+            
+          </span>
+        </div>
+      </div>
+    </div>
+    
+      
+        <form class="md-header__option" data-md-component="palette">
+  
+    
+    
+    
+    <input class="md-option" data-md-color-media="" data-md-color-scheme="default" data-md-color-primary="green" data-md-color-accent="indigo"  aria-hidden="true"  type="radio" name="__palette" id="__palette_0">
+    
+  
+    
+    
+    
+    <input class="md-option" data-md-color-media="(prefers-color-scheme: light)" data-md-color-scheme="default" data-md-color-primary="indigo" data-md-color-accent="indigo"  aria-label="Switch to dark mode"  type="radio" name="__palette" id="__palette_1">
+    
+      <label class="md-header__button md-icon" title="Switch to dark mode" for="__palette_2" hidden>
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 8a4 4 0 0 0-4 4 4 4 0 0 0 4 4 4 4 0 0 0 4-4 4 4 0 0 0-4-4m0 10a6 6 0 0 1-6-6 6 6 0 0 1 6-6 6 6 0 0 1 6 6 6 6 0 0 1-6 6m8-9.31V4h-4.69L12 .69 8.69 4H4v4.69L.69 12 4 15.31V20h4.69L12 23.31 15.31 20H20v-4.69L23.31 12z"/></svg>
+      </label>
+    
+  
+    
+    
+    
+    <input class="md-option" data-md-color-media="(prefers-color-scheme: dark)" data-md-color-scheme="slate" data-md-color-primary="indigo" data-md-color-accent="indigo"  aria-label="Switch to light mode"  type="radio" name="__palette" id="__palette_2">
+    
+      <label class="md-header__button md-icon" title="Switch to light mode" for="__palette_0" hidden>
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 18c-.89 0-1.74-.2-2.5-.55C11.56 16.5 13 14.42 13 12s-1.44-4.5-3.5-5.45C10.26 6.2 11.11 6 12 6a6 6 0 0 1 6 6 6 6 0 0 1-6 6m8-9.31V4h-4.69L12 .69 8.69 4H4v4.69L.69 12 4 15.31V20h4.69L12 23.31 15.31 20H20v-4.69L23.31 12z"/></svg>
+      </label>
+    
+  
+</form>
+      
+    
+    
+      <script>var palette=__md_get("__palette");if(palette&&palette.color){if("(prefers-color-scheme)"===palette.color.media){var media=matchMedia("(prefers-color-scheme: light)"),input=document.querySelector(media.matches?"[data-md-color-media='(prefers-color-scheme: light)']":"[data-md-color-media='(prefers-color-scheme: dark)']");palette.color.media=input.getAttribute("data-md-color-media"),palette.color.scheme=input.getAttribute("data-md-color-scheme"),palette.color.primary=input.getAttribute("data-md-color-primary"),palette.color.accent=input.getAttribute("data-md-color-accent")}for(var[key,value]of Object.entries(palette.color))document.body.setAttribute("data-md-color-"+key,value)}</script>
+    
+    
+    
+      <label class="md-header__button md-icon" for="__search">
+        
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+      </label>
+      <div class="md-search" data-md-component="search" role="dialog">
+  <label class="md-search__overlay" for="__search"></label>
+  <div class="md-search__inner" role="search">
+    <form class="md-search__form" name="search">
+      <input type="text" class="md-search__input" name="query" aria-label="Search" placeholder="Search" autocapitalize="off" autocorrect="off" autocomplete="off" spellcheck="false" data-md-component="search-query" required>
+      <label class="md-search__icon md-icon" for="__search">
+        
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+        
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
+      </label>
+      <nav class="md-search__options" aria-label="Search">
+        
+        <button type="reset" class="md-search__icon md-icon" title="Clear" aria-label="Clear" tabindex="-1">
+          
+          <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M19 6.41 17.59 5 12 10.59 6.41 5 5 6.41 10.59 12 5 17.59 6.41 19 12 13.41 17.59 19 19 17.59 13.41 12z"/></svg>
+        </button>
+      </nav>
+      
+    </form>
+    <div class="md-search__output">
+      <div class="md-search__scrollwrap" tabindex="0" data-md-scrollfix>
+        <div class="md-search-result" data-md-component="search-result">
+          <div class="md-search-result__meta">
+            Initializing search
+          </div>
+          <ol class="md-search-result__list" role="presentation"></ol>
+        </div>
+      </div>
+    </div>
+  </div>
+</div>
+    
+    
+      <div class="md-header__source">
+        <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
+  <div class="md-source__icon md-icon">
+    
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+  </div>
+  <div class="md-source__repository">
+    hyperledger/aries-rfcs
+  </div>
+</a>
+      </div>
+    
+  </nav>
+  
+    
+      
+<nav class="md-tabs" aria-label="Tabs" data-md-component="tabs">
+  <div class="md-grid">
+    <ul class="md-tabs__list">
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../.." class="md-tabs__link">
+          
+  
+  Welcome
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../MAINTAINERS/" class="md-tabs__link">
+          
+  
+  Governance
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../aip2/0003-protocols/" class="md-tabs__link">
+          
+  
+  AIP 2.0
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../0003-protocols/" class="md-tabs__link">
+          
+  
+  ADOPTED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../0004-agents/" class="md-tabs__link">
+          
+  
+  ACCEPTED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../features/0032-message-timing/" class="md-tabs__link">
+          
+  
+  DEMONSTRATED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+    
+  
+  
+    
+    
+      <li class="md-tabs__item md-tabs__item--active">
+        <a href="../../features/0028-introduce/" class="md-tabs__link">
+          
+  
+  PROPOSED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../features/0024-didcomm-over-xmpp/" class="md-tabs__link">
+          
+  
+  STALLED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../0013-overlays/" class="md-tabs__link">
+          
+  
+  RETIRED
+
+        </a>
+      </li>
+    
+  
+
+      
+    </ul>
+  </div>
+</nav>
+    
+  
+</header>
+    
+    <div class="md-container" data-md-component="container">
+      
+      
+        
+      
+      <main class="md-main" data-md-component="main">
+        <div class="md-main__inner md-grid">
+          
+            
+              
+              <div class="md-sidebar md-sidebar--primary" data-md-component="sidebar" data-md-type="navigation" >
+                <div class="md-sidebar__scrollwrap">
+                  <div class="md-sidebar__inner">
+                    
+
+
+  
+
+
+<nav class="md-nav md-nav--primary md-nav--lifted" aria-label="Navigation" data-md-level="0">
+  <label class="md-nav__title" for="__drawer">
+    <a href="../.." title="Hyperledger Aries Interoperability Profiles / RFCs" class="md-nav__button md-logo" aria-label="Hyperledger Aries Interoperability Profiles / RFCs" data-md-component="logo">
+      
+  <img src="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/Hyperledger_Aries_Logo_White.png" alt="logo">
+
+    </a>
+    Hyperledger Aries Interoperability Profiles / RFCs
+  </label>
+  
+    <div class="md-nav__source">
+      <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
+  <div class="md-source__icon md-icon">
+    
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+  </div>
+  <div class="md-source__repository">
+    hyperledger/aries-rfcs
+  </div>
+</a>
+    </div>
+  
+  <ul class="md-nav__list" data-md-scrollfix>
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_1" >
+        
+          
+          <label class="md-nav__link" for="__nav_1" id="__nav_1_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    Welcome
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_1_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_1">
+            <span class="md-nav__icon md-icon"></span>
+            Welcome
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../.." class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Welcome
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../RFCindex/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    All RFCs by Status
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0000-template/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    RFC Template
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0000-template-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Protocol RFC Template
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_2" >
+        
+          
+          <label class="md-nav__link" for="__nav_2" id="__nav_2_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    Governance
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_2_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_2">
+            <span class="md-nav__icon md-icon"></span>
+            Governance
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../MAINTAINERS/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Maintainers
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../contributing/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Contributing
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../github-issues/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Submitting Issues
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../LICENSE/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    License
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../SECURITY/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Security
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_3" >
+        
+          
+          <label class="md-nav__link" for="__nav_3" id="__nav_3_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    AIP 2.0
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_3_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_3">
+            <span class="md-nav__icon md-icon"></span>
+            AIP 2.0
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0003-protocols/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0003 Protocols
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0004-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0004 Agents
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0005-didcomm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0005 DID Communication
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0008-message-id-and-threading/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0008 Message ID and Threading
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0011-decorators/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0011 Decorators
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0015-acks/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0015 ACKs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0017-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0017 Attachments
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0019-encryption-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0019 Encryption Envelope
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0020-message-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0020 Message Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0023-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0023 DID Exchange Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0025-didcomm-transports/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0025 DIDComm Transports
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0035-report-problem/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0035 Report Problem Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0044-didcomm-file-and-mime-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0044 DIDComm File and MIME Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0046-mediators-and-relays/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0046 Mediators and Relays
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0047-json-ld-compatibility/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0047 JSON-LD Compatibility
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0048-trust-ping/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0048 Trust Ping Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0050-wallets/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0050 Wallets
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0092-transport-return-route/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0092 Transports Return Route
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0094-cross-domain-messaging/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0094 Cross-Domain Messaging
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0095-basic-message/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0095 Basic Message Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0183-revocation-notification/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0183 Revocation Notification 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0211-route-coordination/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0211 Mediator Coordination Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0360-use-did-key/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0360 did:key Usage
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0434-outofband/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0434 Out-of-Band Protocol 1.1
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0441-present-proof-best-practices/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0441 Prover and Verifier Best Practices for Proof Presentation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0453-issue-credential-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0453 Issue Credential Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0454-present-proof-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0454 Present Proof Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0510-dif-pres-exch-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0519-goal-codes/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0519 Goal Codes
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0557-discover-features-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0557 Discover Features Protocol v2.x
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0592-indy-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0593-json-ld-cred-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_4" >
+        
+          
+          <label class="md-nav__link" for="__nav_4" id="__nav_4_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    ADOPTED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_4_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_4">
+            <span class="md-nav__icon md-icon"></span>
+            ADOPTED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0003-protocols/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0003 Protocols
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0005-didcomm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0005 DID Communication
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0008-message-id-and-threading/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0008 Message ID and Threading
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0011-decorators/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0011 Decorators
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0015-acks/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0015 ACKs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0017-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0017 Attachments
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0019-encryption-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0019 Encryption Envelope
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0020-message-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0020 Message Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0021-didcomm-message-anatomy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0021 DIDComm Message Anatomy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0023-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0023 DID Exchange v1
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0025-didcomm-transports/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0025 DIDComm Transports
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0031-discover-features/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0031 Discover Features Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0035-report-problem/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0035 Report Problem Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0036-issue-credential/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0036 Issue Credential Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0037-present-proof/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0037 Present Proof Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0048-trust-ping/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0048 Trust Ping Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0092-transport-return-route/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0092 Transports Return Route
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0094-cross-domain-messaging/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0094 Cross-Domain Messaging
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0095-basic-message/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0095 Basic Message Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0160-connection-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0160 Connection Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0211-route-coordination/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0211 Mediator Coordination Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0302-aries-interop-profile/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0302 Aries Interop Profile
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0360-use-did-key/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0360 did:key Usage
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0434-outofband/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0434 Out-of-Band Protocol 1.1
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0441-present-proof-best-practices/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0441 Prover and Verifier Best Practices for Proof Presentation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0453-issue-credential-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0453 Issue Credential Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0454-present-proof-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0454 Present Proof Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0496-transition-to-oob-and-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0496 Transition to the Out of Band Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0510-dif-pres-exch-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0557-discover-features-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0557 Discover Features Protocol v2.x
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0592-indy-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0593-json-ld-cred-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_5" >
+        
+          
+          <label class="md-nav__link" for="__nav_5" id="__nav_5_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    ACCEPTED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_5_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_5">
+            <span class="md-nav__icon md-icon"></span>
+            ACCEPTED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0004-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0004 Agents
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0006-ssi-notation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0006 SSI Notation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0044-didcomm-file-and-mime-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0044 DIDComm File and MIME Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0046-mediators-and-relays/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0046 Mediators and Relays
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0047-json-ld-compatibility/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0047 JSON-LD Compatibility
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0049-repudiation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0049 Repudiation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0050-wallets/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0050 Wallets
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0183-revocation-notification/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0183 Revocation Notification 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0519-goal-codes/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0519 Goal Codes
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0587-encryption-envelope-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0587 Encryption Envelope v2
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0646-bbs-credentials/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0646 W3C Credential Exchange using BBS+ Signatures
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0685-pickup-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0685 Pickup Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0721-revocation-notification-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0721 Revocation Notification 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0793-unqualfied-dids-transition/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0793 Unqualified DID Transition
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0794-did-rotate/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0794 DID Rotate 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_6" >
+        
+          
+          <label class="md-nav__link" for="__nav_6" id="__nav_6_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    DEMONSTRATED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_6_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_6">
+            <span class="md-nav__icon md-icon"></span>
+            DEMONSTRATED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0032-message-timing/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0032 Message Timing
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0042-lox/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0042 LOX -- A more secure pluggable framework for protecting wallet keys
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0043-l10n/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0043 l10n (Locali[s|z]ation)
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0113-question-answer/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0113 Question Answer Protocol 0.9
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0509-action-menu/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0509 Action Menu Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0748-n-wise-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0748 N-wise DID Exchange Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0755-oca-for-aries/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0755 Overlays Capture Architecture (OCA) For Aries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0756-oca-for-aries-style-guide/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0756 OCA for Aries Style Guide
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0780-data-urls-images/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0780 Use Data URLs for Images and More in Credential Attributes
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0804-didcomm-rpc/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0804 DIDComm Remote Procedure Call (DRPC)
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0809-w3c-data-integrity-credential-attachment/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0809 W3C Verifiable Credential Data Integrity Attachment format for requesting and issuing credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+    
+  
+  
+  
+    
+    
+    
+      
+        
+        
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--active md-nav__item--section md-nav__item--nested">
+      
+        
+        
+        <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_7" checked>
+        
+          
+          <label class="md-nav__link" for="__nav_7" id="__nav_7_label" tabindex="">
+            
+  
+  <span class="md-ellipsis">
+    PROPOSED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_7_label" aria-expanded="true">
+          <label class="md-nav__title" for="__nav_7">
+            <span class="md-nav__icon md-icon"></span>
+            PROPOSED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0028-introduce/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0028 Introduce Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0034-message-tracing/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0034 Message Tracing
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0056-service-decorator/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0056 Service Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0066-non-repudiable-cryptographic-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0066 Non-Repudiable Signature for Cryptographic Envelope
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0067-didcomm-diddoc-conventions/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0067 DIDComm DID document conventions
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0074-didcomm-best-practices/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0074 DIDComm Best Practices
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0103-indirect-identity-control/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0103 Indirect Identity Control
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0104-chained-credentials/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0104 Chained Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0124-did-resolution-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0124 DID Resolution Protocol 0.9
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0167-data-consent-lifecycle/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0167 Data Consent Lifecycle
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0212-pickup/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0212 Pickup Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0213-transfer-policy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0213 Transfer Policy Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0214-help-me-discover/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0214 "Help Me Discover" Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0231-biometric-service-provider/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0231 Biometric Service Provider
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0268-unified-didcomm-agent-deeplinking/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0268 Unified DIDCOMM Deeplinking
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0270-interop-test-suite/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0270 Interop Test Suite
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0345-community-coordinated-update/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0345 Community Coordinated Update
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0346-didcomm-between-two-mobile-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0346 DIDComm Between Two Mobile Agents Using Cloud Agent Mediator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0347-proof-negotiation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0347 Proof Negotiation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0430-machine-readable-governance-frameworks/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0430 Machine-Readable Governance Frameworks
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0440-kms-architectures/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0440 KMS Architectures
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0511-dif-cred-manifest-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0511 Credential-Manifest Attachment format for requesting and presenting credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0530-goal-human-readable-verified-identifer/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0530 Goal - Human Readable Verifiable Identifier
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0559-pppu/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0559 Privacy-Preserving Proof of Uniqueness
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0566-issuer-hosted-custodidal-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0566 Issuer-Hosted Custodial Agents
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0641-linking-binary-objects-to-credentials/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0641 Linking binary objects to credentials using hash based references
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0693-credential-representation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0693 Cross-Platform Credential Representation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0699-push-notifications-apns/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0699 Push Notifications apns Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0700-oob-through-redirect/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0700 Out-of-Band through redirect
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0728-device-binding-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0728 Device Binding Attachments
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0734-push-notifications-fcm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0734 Push Notifications fcm Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0757-push-notification/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0757 Push Notification
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0771-anoncreds-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0771 AnonCreds Attachment Formats for Requesting and Presenting Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+    
+  
+  
+  
+    <li class="md-nav__item md-nav__item--active">
+      
+      <input class="md-nav__toggle md-toggle" type="checkbox" id="__toc">
+      
+      
+        
+      
+      
+        <label class="md-nav__link md-nav__link--active" for="__toc">
+          
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+          <span class="md-nav__icon md-icon"></span>
+        </label>
+      
+      <a href="./" class="md-nav__link md-nav__link--active">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+      
+        
+
+<nav class="md-nav md-nav--secondary" aria-label="Table of contents">
+  
+  
+  
+    
+  
+  
+    <label class="md-nav__title" for="__toc">
+      <span class="md-nav__icon md-icon"></span>
+      Table of contents
+    </label>
+    <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
+      
+        <li class="md-nav__item">
+  <a href="#response-message-type" class="md-nav__link">
+    <span class="md-ellipsis">
+      response Message Type
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#trust-registry-considerations" class="md-nav__link">
+    <span class="md-ellipsis">
+      Trust Registry Considerations
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Trust Registry Considerations">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#connection-establishment" class="md-nav__link">
+    <span class="md-ellipsis">
+      Connection Establishment
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#identifier" class="md-nav__link">
+    <span class="md-ellipsis">
+      Identifier
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#governance" class="md-nav__link">
+    <span class="md-ellipsis">
+      Governance
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#localization" class="md-nav__link">
+    <span class="md-ellipsis">
+      Localization
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#open-topics" class="md-nav__link">
+    <span class="md-ellipsis">
+      Open Topics
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#acknowledgements" class="md-nav__link">
+    <span class="md-ellipsis">
+      Acknowledgements
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#implementations" class="md-nav__link">
+    <span class="md-ellipsis">
+      Implementations
+    </span>
+  </a>
+  
+</li>
+      
+    </ul>
+  
+</nav>
+      
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0799-long-term-support/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0799 Aries Long Term Support Releases
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_8" >
+        
+          
+          <label class="md-nav__link" for="__nav_8" id="__nav_8_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    STALLED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_8_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_8">
+            <span class="md-nav__icon md-icon"></span>
+            STALLED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0024-didcomm-over-xmpp/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0024 DIDComm over XMPP
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0029-message-trust-contexts/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0029 Message Trust Contexts
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0030-sync-connection/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0030 Sync Connection Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0075-payment-decorators/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0075 Payment Decorators
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0114-predefined-identities/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0114 Predefined Identities
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0116-evidence-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0116 Evidence Exchange Protocol 0.9
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0193-coin-flip/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0193 Coin Flip Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0207-credential-fraud-threat-model/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0207 Credential Fraud Threat Model
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0217-linkable-message-paths/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0217 Linkable Message Paths
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0249-rich-schema-contexts/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0249 Aries Rich Schema Contexts
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0250-rich-schemas/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0250 Rich Schema Objects
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0257-private-credential-issuance/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0257 Private Credential Issuance
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0281-rich-schemas/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0281 Aries Rich Schemas
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0289-toip-stack/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0289 The Trust Over IP Stack
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0309-didauthz/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0309 DIDAuthZ
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0327-crypto-service/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0327 Crypto service Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0334-jwe-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0334 JWE envelope 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0335-http-over-didcomm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0335 HTTP Over DIDComm
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0351-purpose-decorator/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0351 Purpose Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0418-rich-schema-encoding/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0418 Aries Rich Schema Encoding Objects
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0420-rich-schemas-common/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0420 Rich Schema Objects Common
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0428-prepare-issue-rich-credential/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0428 Prerequisites to Issue Rich Credential
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0429-prepare-req-rich-pres/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0429 Prerequisites to Request Rich Presentation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0445-rich-schema-mapping/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0445 Aries Rich Schema Mapping
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0446-rich-schema-cred-def/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0446 Aries Rich Schema Credential Definition
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0478-coprotocols/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0478 Coprotocols
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0482-coprotocol-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0482 Coprotocol Protocol 0.5
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_9" >
+        
+          
+          <label class="md-nav__link" for="__nav_9" id="__nav_9_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    RETIRED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_9_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_9">
+            <span class="md-nav__icon md-icon"></span>
+            RETIRED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0013-overlays/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0013 Overlays
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0051-dkms/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0051 Decentralized Key Management
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0234-signature-decorator/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0234 Signature Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0303-v01-credential-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0303 V0.1 Credential Exchange (Deprecated)
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0317-please-ack/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0317 Please ACK Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0348-transition-msg-type-to-https/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0348 Transition Message Type to HTTPs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0627-static-peer-dids/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0627 Static Peer DIDs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+  </ul>
+</nav>
+                  </div>
+                </div>
+              </div>
+            
+            
+              
+              <div class="md-sidebar md-sidebar--secondary" data-md-component="sidebar" data-md-type="toc" >
+                <div class="md-sidebar__scrollwrap">
+                  <div class="md-sidebar__inner">
+                    
+
+<nav class="md-nav md-nav--secondary" aria-label="Table of contents">
+  
+  
+  
+    
+  
+  
+    <label class="md-nav__title" for="__toc">
+      <span class="md-nav__icon md-icon"></span>
+      Table of contents
+    </label>
+    <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
+      
+        <li class="md-nav__item">
+  <a href="#response-message-type" class="md-nav__link">
+    <span class="md-ellipsis">
+      response Message Type
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#trust-registry-considerations" class="md-nav__link">
+    <span class="md-ellipsis">
+      Trust Registry Considerations
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Trust Registry Considerations">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#connection-establishment" class="md-nav__link">
+    <span class="md-ellipsis">
+      Connection Establishment
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#identifier" class="md-nav__link">
+    <span class="md-ellipsis">
+      Identifier
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#governance" class="md-nav__link">
+    <span class="md-ellipsis">
+      Governance
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#localization" class="md-nav__link">
+    <span class="md-ellipsis">
+      Localization
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#open-topics" class="md-nav__link">
+    <span class="md-ellipsis">
+      Open Topics
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#acknowledgements" class="md-nav__link">
+    <span class="md-ellipsis">
+      Acknowledgements
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#implementations" class="md-nav__link">
+    <span class="md-ellipsis">
+      Implementations
+    </span>
+  </a>
+  
+</li>
+      
+    </ul>
+  
+</nav>
+                  </div>
+                </div>
+              </div>
+            
+          
+          
+            <div class="md-content" data-md-component="content">
+              <article class="md-content__inner md-typeset">
+                
+                  
+
+  
+  
+
+
+<h1 id="rfc-0781-trust-input-protocol">RFC 0781: Trust Input Protocol<a class="headerlink" href="#rfc-0781-trust-input-protocol" title="Permanent link">&para;</a></h1>
+<ul>
+<li>Authors: Mathieu Glaude, Subhasis Ojha</li>
+<li>Status: PROPOSED</li>
+<li>Since: 2023-11-23</li>
+<li>Status Note: New RFC being proposed</li>
+<li>Supersedes: None</li>
+<li>Start Date: 2023-11-23</li>
+</ul>
+<p>## Summary</p>
+<p>The Trust Input Protocol is a conceptual framework designed to assist with the making of trust decisions within digital interactions. It emphasizes the importance of both technical (cryptographic) trust and human trust. The protocol introduces the concept of "Trust Inputs," which are sources of information that assist entities in making trust decisions. For the purpose of this RFC, trust inputs may only come from Trust Registries that support DIDComm-based messaging, based on <a href="https://github.com/hyperledger/aries-rfcs/blob/main../../features/0160-connection-protocol/README.md">RFC 0160: Connection Protocol</a>. The first use case that this framework looks to support is allowing verifiers of a digital credential proof presentation to query the authoritativeness of digital credential issuers against trust registries.</p>
+<p>## Motivation</p>
+<p>The primary motivation for creating a Trust Input Protocol is to address the challenges of establishing trust in digital interactions. As digital transactions become more prevalent, there's a growing need to ensure that parties can trust each other, especially in contexts where real or perceived risks are involved. Traditional cryptographic methods provide technical trust, ensuring that data hasn't been altered or falsified. However, they don't address the human aspect of trust, such as verifying the authenticity of a claim or ensuring that a claim has been issued by a recognized authority. The Trust Input Protocol aims to bridge this gap by providing a framework where parties can seek trust inputs from various sources to make informed trust decisions. Although we focus on trust registries in the short-term, we imagine this protocol being capable of allowing trust decision making entities to seek inputs from sources outside of trust registries. For this reason, we will use the broader term <code>trust-input</code>.</p>
+<p><img alt="Making a trust decision" src="https://github.com/Northern-Block/trustinputprotocol/blob/main/trust-inputs-flow.png" /></p>
+<p>This above diagram was taken from a June 29, 2023 presentation given to the Trust over IP Foundation (<a href="https://docs.google.com/presentation/d/1UMacqKZOEXiisNMz38_47FmJBUj69XePcTg9WbUCJtw/edit?usp=sharing">Slides</a>, <a href="https://zoom.us/rec/share/Hx-3oOZBL_vIPgf-2I6zP7QuBdQNKki4yULa2U71-VMvIrXUrS21HBAobYKBoUV5.gDEK5BKn5yJUq7nN">Recording</a>).</p>
+<p>Trust registries are authoritative sources of information that we can use as inputs to make trust decisions. In the digital credentialing world, we can imagine sometimes needing to check an authoritative source to know if a credential was issued by an authority. And the reason for a protocol? We want to make sure we avoid building proprietary solutions and rather work with the community to develop standards and protocols that can be used by any implementer.</p>
+<p>Inspiration for this protocol was taken from <a href="https://github.com/hyperledger/aries-rfcs/blob/main../../features/0113-question-answer/README.md">RFC 0113: Question Answer Protocol</a>. We have gone beyond this protocol by adding structure to it, since we need a standard method for requesting for authorization related to credential issuance contexts.</p>
+<p>## Tutorial</p>
+<p>This RFC introduces a protocol for interacting with trust registries. The identifier for the message family used by this protocol is <code>trust-input</code>, and the fully qualified URI for its definition is: </p>
+<p><em><a href="https://didcomm.org/trust-input/1.0">https://didcomm.org/trust-input/1.0</a></em></p>
+<p>## Roles</p>
+<p>There are two roles in the <code>trust-input</code> protocol: <code>requestor</code> and <code>trust-registry</code>. The <code>requestor</code> asks the <code>trust-registry</code> if credential metadata of a verifiable credential shared by a holder was issued by an authorized issuer, and the <code>trust-registry</code> responds with an answer. Any type of entity can be a requestor and inquire about the authority of an issuing entity. All the requests sent by the requestor are sent in a single message type, and the same is true for the response from the <code>trust-registry</code>.</p>
+<p>## States</p>
+<p>This is a classic two-step request~response interaction, so it uses the predefined state machines for any <code>requestor</code> and <code>trust-registry</code>:</p>
+<p><img src= "https://github.com/Northern-Block/trustinputprotocol/blob/main/trust-input-states.png" width="408.16" height="300"></p>
+<p>## Messages</p>
+<p>### query Message Type</p>
+<p>A trust-input-protocol/query message looks like this:</p>
+<div class="highlight"><pre><span></span><code>{
+&quot;@type&quot;: &quot;https://didcomm.org/trust-input/1.0/query&quot;,
+    &quot;@id&quot;: &quot;yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU&quot;,
+    &quot;query&quot;: {
+            &quot;trust-task&quot;:&quot;issuance&quot;,
+            &quot;include-governance&quot;:&quot;yes&quot;,
+            &quot;credentialmetadata&quot;:[
+                {
+                &quot;credential-id&quot;: &quot;http://university.example/credentials/1872&quot;,
+            &quot;credential-format&quot;: &quot;1&quot;,
+                &quot;issuer-did&quot;: &quot;did:example:123456abcdef&quot;
+                }
+            ]
+        },
+    &quot;comment&quot;: &quot;Please tell me if this issuer is authoritative to issue this credential type...&quot;
+}
+</code></pre></div>
+<p>The query message says, “ Please tell me if the issuer: ‘did:example:123456abcdef’ is authorized to issue the credential: ‘<a href="http://university.example/credentials/1872">http://university.example/credentials/1872</a>’. And please give me information about the governance framework that governs the trust registry operation.” Please refer to the Localisation section below for further details.</p>
+<p>The <code>requestor</code> can send an array of issuers and credentials in their request to the trust registry. If they’re seeking multiple trust inputs from a single trust registry, they can get them in a single request.</p>
+<p>The values for <code>credential-format</code> are:</p>
+<div class="highlight"><pre><span></span><code>1 = AnonCreds
+2 = JSON-LD
+3 = JWT
+</code></pre></div>
+<p>Additional formats can be supported and added to this above list.</p>
+<p>The credential field within the requestor’s <code>query</code> may include a * wildcard. An example use of this could be “I’m interested in knowing all the credentials that this specific issuer is authorized to offer”. This may be useful for discovery purposes.</p>
+<h3 id="response-message-type">response Message Type<a class="headerlink" href="#response-message-type" title="Permanent link">&para;</a></h3>
+<p>A trust-input/response message looks like this:</p>
+<div class="highlight"><pre><span></span><code>{ 
+&quot;@type&quot;: &quot;https://didcomm.org/trust-input/1.0/response&quot;,
+&quot;~thread&quot;: {
+        &quot;thid&quot;: &quot;yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU&quot; 
+    },
+    &quot;governance&quot;:&quot;http://university.example/governanceframework&quot;,
+    &quot;response&quot;:[    
+{
+            &quot;credential-id&quot;: &quot;http://university.example/credentials/1872&quot;,
+            &quot;status&quot;: &quot;2&quot;,
+            &quot;status_date&quot;:&quot;yyyy&#39;-&#39;MM&#39;-&#39;dd&#39;T&#39;HH&#39;:&#39;mm&#39;:&#39;ss&#39;.&#39;fff&#39;Z&#39;&quot;
+            }
+    ]
+}
+</code></pre></div>
+<p>The <code>response</code> field is a JSON array of response support descriptor objects that matches the query. Each descriptor has a <code>credential-id</code> that contains a credential (fully qualified verifiable credential id), plus the current authoritative <code>status</code> of the credential issuer to issue said credential.</p>
+<p>The response returns the current status of the credential issuer(s) against their authority to issue credentials at the time of <code>query</code>.</p>
+<p>The values for <code>status</code> are:</p>
+<div class="highlight"><pre><span></span><code>1 = Not found
+2 = Valid
+3 = Expired (not renewed after the previous valid registration period) [when was it expired]
+4 = Terminated (voluntary termination by the registered party) [when was it terminated]
+5 = Revoked [when was it revoked]
+</code></pre></div>
+<p>For status values 3, 4, 5; the trust registry will return a date value of when that status became that value.</p>
+<p>A <code>query</code> which contains a *wildcard would return all the credentials offered by the issuer’s DID.
+The date format returned in the response is a web UTC format. The date represents  the status changes of status values and the <code>requestor</code> can use that info to make their trust decision.</p>
+<h2 id="trust-registry-considerations">Trust Registry Considerations<a class="headerlink" href="#trust-registry-considerations" title="Permanent link">&para;</a></h2>
+<h3 id="connection-establishment">Connection Establishment<a class="headerlink" href="#connection-establishment" title="Permanent link">&para;</a></h3>
+<p>The connection between the <code>requestor</code> and the <code>trust-registry</code> is established via an out-of-band message sent to the <code>requestor</code>. Other connection methods such as <a href="https://github.com/hyperledger/aries-rfcs/blob/main../../features/0160-connection-protocol/README.md">RFC 0160</a> can also be used.</p>
+<h3 id="identifier">Identifier<a class="headerlink" href="#identifier" title="Permanent link">&para;</a></h3>
+<p><code>trust-registry</code> must have a resolvable Verifiable Identifier (VID).</p>
+<h3 id="governance">Governance<a class="headerlink" href="#governance" title="Permanent link">&para;</a></h3>
+<p>The trust registries that an entity using this protocol will interact with should ensure their trust registries are aligned with the <a href="https://github.com/trustoverip/tswg-trust-registry-tf/blob/main/v2/requirements.md#governing-authorities">Trust over IP’s Trust Registry Governance Framework</a>.</p>
+<p>A governance document must be published to be able to respond to a request that asks for governance.</p>
+<h2 id="localization">Localization<a class="headerlink" href="#localization" title="Permanent link">&para;</a></h2>
+<p>Because the <code>requestor</code> is being returned a status number to represent the status, the implementers can use this to localise it in the language of their choice and make it friendly to their application or user experience.</p>
+<p>The <code>query</code> message contains a <code>comment</code> field that is localizable. This field is optional and may not be often used, but when it is, it is to provide a human-friendly justification for the query. An agent that consults its master before answering a query could present the content of this field as an explanation of the request.</p>
+<p>All message types in this family thus have the following implicit decorator:</p>
+<div class="highlight"><pre><span></span><code>{
+
+&quot;~l10n&quot;: {
+    &quot;locales&quot;: { &quot;en&quot;: [&quot;comment&quot;] },
+    &quot;catalogs&quot;: [&quot;https://github.com/hyperledger/aries-rfcs../../features/trust-input/requestor/catalog.json&quot;]
+
+        }
+}
+</code></pre></div>
+<p>For more information, see the <a href="https://github.com/hyperledger/aries-rfcs/blob/main../../features/0043-l10n/README.md">localization RFC</a>.</p>
+<h2 id="open-topics">Open Topics<a class="headerlink" href="#open-topics" title="Permanent link">&para;</a></h2>
+<ul>
+<li>How to implement using <a href="https://github.com/hyperledger/aries-rfcs/blob/main../../features/0434-outofband/README.md">RFC 0434: Out-of-Band Protocol 1.1</a>? We plan to leave this out of scope until a further version.</li>
+<li>Governance on how the credential id is entered into a trust registry will be required. And this is dependent on the credential format. So there will likely be a required field in the trust registry for credential format, which would then dictate how the credential id is entered. The format for the credential metadata in the trust registry must align with the format received by the <code>requestor</code>.</li>
+</ul>
+<h2 id="acknowledgements">Acknowledgements<a class="headerlink" href="#acknowledgements" title="Permanent link">&para;</a></h2>
+<p>Although many people helped with the thinking behind this protocol, the authors would like to specifically thank these following people for their support and contributions:</p>
+<ul>
+<li>
+<p>British Columbia Government - Kyle Robinson and Nancy Norris</p>
+</li>
+<li>
+<p>CIRA - Jacques Latour and Jesse Carter</p>
+</li>
+<li>
+<p>Continuum Loop - Darrell O’Donnell</p>
+</li>
+<li>
+<p>IDLab - Cosanna Preston-Idedia and Hadrien Seymour-Provencher</p>
+</li>
+<li>
+<p>Trust over IP’s Trust Registry Task Force</p>
+</li>
+</ul>
+<h2 id="implementations">Implementations<a class="headerlink" href="#implementations" title="Permanent link">&para;</a></h2>
+<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the "Name" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p>
+<table>
+<thead>
+<tr>
+<th>Name/Link</th>
+<th>Implementation Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td><a href="http://nborbit.io">nborbit.io</a></td>
+<td>Commercial trust task orchestration application built by <a href="https://northernblock.io/">Northern Block</a> using Aries Cloud Agent Python (ACA-Py).</td>
+</tr>
+</tbody>
+</table>
+
+
+
+
+
+
+
+
+
+
+
+
+                
+              </article>
+            </div>
+          
+          
+<script>var target=document.getElementById(location.hash.slice(1));target&&target.name&&(target.checked=target.name.startsWith("__tabbed_"))</script>
+        </div>
+        
+          <button type="button" class="md-top md-icon" data-md-component="top" hidden>
+  
+  <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M13 20h-2V8l-5.5 5.5-1.42-1.42L12 4.16l7.92 7.92-1.42 1.42L13 8z"/></svg>
+  Back to top
+</button>
+        
+      </main>
+      
+        <footer class="md-footer">
+  
+    
+      
+      <nav class="md-footer__inner md-grid" aria-label="Footer" >
+        
+          
+          <a href="../../features/0771-anoncreds-attachments/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0771 AnonCreds Attachment Formats for Requesting and Presenting Credentials">
+            <div class="md-footer__button md-icon">
+              
+              <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
+            </div>
+            <div class="md-footer__title">
+              <span class="md-footer__direction">
+                Previous
+              </span>
+              <div class="md-ellipsis">
+                0771 AnonCreds Attachment Formats for Requesting and Presenting Credentials
+              </div>
+            </div>
+          </a>
+        
+        
+          
+          <a href="../0799-long-term-support/" class="md-footer__link md-footer__link--next" aria-label="Next: 0799 Aries Long Term Support Releases">
+            <div class="md-footer__title">
+              <span class="md-footer__direction">
+                Next
+              </span>
+              <div class="md-ellipsis">
+                0799 Aries Long Term Support Releases
+              </div>
+            </div>
+            <div class="md-footer__button md-icon">
+              
+              <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M4 11v2h12l-5.5 5.5 1.42 1.42L19.84 12l-7.92-7.92L10.5 5.5 16 11z"/></svg>
+            </div>
+          </a>
+        
+      </nav>
+    
+  
+  <div class="md-footer-meta md-typeset">
+    <div class="md-footer-meta__inner md-grid">
+      <div class="md-copyright">
+  
+  
+    Made with
+    <a href="https://squidfunk.github.io/mkdocs-material/" target="_blank" rel="noopener">
+      Material for MkDocs
+    </a>
+  
+</div>
+      
+    </div>
+  </div>
+</footer>
+      
+    </div>
+    <div class="md-dialog" data-md-component="dialog">
+      <div class="md-dialog__inner md-typeset"></div>
+    </div>
+    
+    
+    <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
+    
+    
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
+      
+    
+  </body>
+</html>
\ No newline at end of file
diff --git a/main/concepts/0781-trust-input-protocol/trust-input-states.png b/main/concepts/0781-trust-input-protocol/trust-input-states.png
new file mode 100644
index 000000000..df70b57e4
Binary files /dev/null and b/main/concepts/0781-trust-input-protocol/trust-input-states.png differ
diff --git a/main/concepts/0781-trust-input-protocol/trust-inputs-flow.png b/main/concepts/0781-trust-input-protocol/trust-inputs-flow.png
new file mode 100644
index 000000000..17eb7c4b3
Binary files /dev/null and b/main/concepts/0781-trust-input-protocol/trust-inputs-flow.png differ
diff --git a/main/concepts/0799-long-term-support/index.html b/main/concepts/0799-long-term-support/index.html
index 75a4fca7b..0f1fb4ba0 100644
--- a/main/concepts/0799-long-term-support/index.html
+++ b/main/concepts/0799-long-term-support/index.html
@@ -9,14 +9,14 @@
       
       
       
-        <link rel="prev" href="../../features/0771-anoncreds-attachments/">
+        <link rel="prev" href="../0781-trust-input-protocol/">
       
       
-        <link rel="next" href="../../features/0024-didcomm-over-xmpp/">
+        <link rel="next" href="../0812-compression-dictionary/">
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3316,6 +3316,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0559-pppu/" class="md-nav__link">
         
@@ -3484,6 +3505,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../0757-push-notification/" class="md-nav__link">
         
@@ -3524,6 +3566,27 @@
                 
   
   
+  
+  
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
     
   
   
@@ -3635,6 +3698,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4625,7 +4730,7 @@ <h2 id="references">References<a class="headerlink" href="#references" title="Pe
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../../features/0771-anoncreds-attachments/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0771 AnonCreds Attachment Formats for Requesting and Presenting Credentials">
+          <a href="../0781-trust-input-protocol/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0781 Trust Input Protocol">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4635,20 +4740,20 @@ <h2 id="references">References<a class="headerlink" href="#references" title="Pe
                 Previous
               </span>
               <div class="md-ellipsis">
-                0771 AnonCreds Attachment Formats for Requesting and Presenting Credentials
+                0781 Trust Input Protocol
               </div>
             </div>
           </a>
         
         
           
-          <a href="../../features/0024-didcomm-over-xmpp/" class="md-footer__link md-footer__link--next" aria-label="Next: 0024 DIDComm over XMPP">
+          <a href="../0812-compression-dictionary/" class="md-footer__link md-footer__link--next" aria-label="Next: 0812 Compressing DIDComm messages using dictionaries">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                0024 DIDComm over XMPP
+                0812 Compressing DIDComm messages using dictionaries
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4685,7 +4790,7 @@ <h2 id="references">References<a class="headerlink" href="#references" title="Pe
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/concepts/0812-compression-dictionary/YlU3M52.png b/main/concepts/0812-compression-dictionary/YlU3M52.png
new file mode 100644
index 000000000..9bbc91b0c
Binary files /dev/null and b/main/concepts/0812-compression-dictionary/YlU3M52.png differ
diff --git a/main/concepts/0812-compression-dictionary/b9y8VTC.png b/main/concepts/0812-compression-dictionary/b9y8VTC.png
new file mode 100644
index 000000000..db516c447
Binary files /dev/null and b/main/concepts/0812-compression-dictionary/b9y8VTC.png differ
diff --git a/main/concepts/0812-compression-dictionary/index.html b/main/concepts/0812-compression-dictionary/index.html
new file mode 100644
index 000000000..738d536e0
--- /dev/null
+++ b/main/concepts/0812-compression-dictionary/index.html
@@ -0,0 +1,5127 @@
+
+<!doctype html>
+<html lang="en" class="no-js">
+  <head>
+    
+      <meta charset="utf-8">
+      <meta name="viewport" content="width=device-width,initial-scale=1">
+      
+      
+      
+      
+        <link rel="prev" href="../0799-long-term-support/">
+      
+      
+        <link rel="next" href="../../features/0829-VDR-Proxy/">
+      
+      
+      <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
+    
+    
+      
+        <title>0812 Compressing DIDComm messages using dictionaries - Hyperledger Aries Interoperability Profiles / RFCs</title>
+      
+    
+    
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
+      
+        
+        <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
+      
+      
+
+
+    
+    
+      
+    
+    
+      
+        
+        
+        <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
+        <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto:300,300i,400,400i,700,700i%7CRoboto+Mono:400,400i,700,700i&display=fallback">
+        <style>:root{--md-text-font:"Roboto";--md-code-font:"Roboto Mono"}</style>
+      
+    
+    
+    <script>__md_scope=new URL("../..",location),__md_hash=e=>[...e].reduce(((e,_)=>(e<<5)-e+_.charCodeAt(0)),0),__md_get=(e,_=localStorage,t=__md_scope)=>JSON.parse(_.getItem(t.pathname+"."+e)),__md_set=(e,_,t=localStorage,a=__md_scope)=>{try{t.setItem(a.pathname+"."+e,JSON.stringify(_))}catch(e){}}</script>
+    
+      
+
+    
+    
+    
+  </head>
+  
+  
+    
+    
+      
+    
+    
+    
+    
+    <body dir="ltr" data-md-color-scheme="default" data-md-color-primary="green" data-md-color-accent="indigo">
+  
+    
+    <input class="md-toggle" data-md-toggle="drawer" type="checkbox" id="__drawer" autocomplete="off">
+    <input class="md-toggle" data-md-toggle="search" type="checkbox" id="__search" autocomplete="off">
+    <label class="md-overlay" for="__drawer"></label>
+    <div data-md-component="skip">
+      
+        
+        <a href="#0812-compressing-didcomm-messages-using-dictionaries" class="md-skip">
+          Skip to content
+        </a>
+      
+    </div>
+    <div data-md-component="announce">
+      
+    </div>
+    
+    
+      
+
+  
+
+<header class="md-header md-header--shadow md-header--lifted" data-md-component="header">
+  <nav class="md-header__inner md-grid" aria-label="Header">
+    <a href="../.." title="Hyperledger Aries Interoperability Profiles / RFCs" class="md-header__button md-logo" aria-label="Hyperledger Aries Interoperability Profiles / RFCs" data-md-component="logo">
+      
+  <img src="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/Hyperledger_Aries_Logo_White.png" alt="logo">
+
+    </a>
+    <label class="md-header__button md-icon" for="__drawer">
+      
+      <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M3 6h18v2H3zm0 5h18v2H3zm0 5h18v2H3z"/></svg>
+    </label>
+    <div class="md-header__title" data-md-component="header-title">
+      <div class="md-header__ellipsis">
+        <div class="md-header__topic">
+          <span class="md-ellipsis">
+            Hyperledger Aries Interoperability Profiles / RFCs
+          </span>
+        </div>
+        <div class="md-header__topic" data-md-component="header-topic">
+          <span class="md-ellipsis">
+            
+              0812 Compressing DIDComm messages using dictionaries
+            
+          </span>
+        </div>
+      </div>
+    </div>
+    
+      
+        <form class="md-header__option" data-md-component="palette">
+  
+    
+    
+    
+    <input class="md-option" data-md-color-media="" data-md-color-scheme="default" data-md-color-primary="green" data-md-color-accent="indigo"  aria-hidden="true"  type="radio" name="__palette" id="__palette_0">
+    
+  
+    
+    
+    
+    <input class="md-option" data-md-color-media="(prefers-color-scheme: light)" data-md-color-scheme="default" data-md-color-primary="indigo" data-md-color-accent="indigo"  aria-label="Switch to dark mode"  type="radio" name="__palette" id="__palette_1">
+    
+      <label class="md-header__button md-icon" title="Switch to dark mode" for="__palette_2" hidden>
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 8a4 4 0 0 0-4 4 4 4 0 0 0 4 4 4 4 0 0 0 4-4 4 4 0 0 0-4-4m0 10a6 6 0 0 1-6-6 6 6 0 0 1 6-6 6 6 0 0 1 6 6 6 6 0 0 1-6 6m8-9.31V4h-4.69L12 .69 8.69 4H4v4.69L.69 12 4 15.31V20h4.69L12 23.31 15.31 20H20v-4.69L23.31 12z"/></svg>
+      </label>
+    
+  
+    
+    
+    
+    <input class="md-option" data-md-color-media="(prefers-color-scheme: dark)" data-md-color-scheme="slate" data-md-color-primary="indigo" data-md-color-accent="indigo"  aria-label="Switch to light mode"  type="radio" name="__palette" id="__palette_2">
+    
+      <label class="md-header__button md-icon" title="Switch to light mode" for="__palette_0" hidden>
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 18c-.89 0-1.74-.2-2.5-.55C11.56 16.5 13 14.42 13 12s-1.44-4.5-3.5-5.45C10.26 6.2 11.11 6 12 6a6 6 0 0 1 6 6 6 6 0 0 1-6 6m8-9.31V4h-4.69L12 .69 8.69 4H4v4.69L.69 12 4 15.31V20h4.69L12 23.31 15.31 20H20v-4.69L23.31 12z"/></svg>
+      </label>
+    
+  
+</form>
+      
+    
+    
+      <script>var palette=__md_get("__palette");if(palette&&palette.color){if("(prefers-color-scheme)"===palette.color.media){var media=matchMedia("(prefers-color-scheme: light)"),input=document.querySelector(media.matches?"[data-md-color-media='(prefers-color-scheme: light)']":"[data-md-color-media='(prefers-color-scheme: dark)']");palette.color.media=input.getAttribute("data-md-color-media"),palette.color.scheme=input.getAttribute("data-md-color-scheme"),palette.color.primary=input.getAttribute("data-md-color-primary"),palette.color.accent=input.getAttribute("data-md-color-accent")}for(var[key,value]of Object.entries(palette.color))document.body.setAttribute("data-md-color-"+key,value)}</script>
+    
+    
+    
+      <label class="md-header__button md-icon" for="__search">
+        
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+      </label>
+      <div class="md-search" data-md-component="search" role="dialog">
+  <label class="md-search__overlay" for="__search"></label>
+  <div class="md-search__inner" role="search">
+    <form class="md-search__form" name="search">
+      <input type="text" class="md-search__input" name="query" aria-label="Search" placeholder="Search" autocapitalize="off" autocorrect="off" autocomplete="off" spellcheck="false" data-md-component="search-query" required>
+      <label class="md-search__icon md-icon" for="__search">
+        
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+        
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
+      </label>
+      <nav class="md-search__options" aria-label="Search">
+        
+        <button type="reset" class="md-search__icon md-icon" title="Clear" aria-label="Clear" tabindex="-1">
+          
+          <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M19 6.41 17.59 5 12 10.59 6.41 5 5 6.41 10.59 12 5 17.59 6.41 19 12 13.41 17.59 19 19 17.59 13.41 12z"/></svg>
+        </button>
+      </nav>
+      
+    </form>
+    <div class="md-search__output">
+      <div class="md-search__scrollwrap" tabindex="0" data-md-scrollfix>
+        <div class="md-search-result" data-md-component="search-result">
+          <div class="md-search-result__meta">
+            Initializing search
+          </div>
+          <ol class="md-search-result__list" role="presentation"></ol>
+        </div>
+      </div>
+    </div>
+  </div>
+</div>
+    
+    
+      <div class="md-header__source">
+        <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
+  <div class="md-source__icon md-icon">
+    
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+  </div>
+  <div class="md-source__repository">
+    hyperledger/aries-rfcs
+  </div>
+</a>
+      </div>
+    
+  </nav>
+  
+    
+      
+<nav class="md-tabs" aria-label="Tabs" data-md-component="tabs">
+  <div class="md-grid">
+    <ul class="md-tabs__list">
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../.." class="md-tabs__link">
+          
+  
+  Welcome
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../MAINTAINERS/" class="md-tabs__link">
+          
+  
+  Governance
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../aip2/0003-protocols/" class="md-tabs__link">
+          
+  
+  AIP 2.0
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../0003-protocols/" class="md-tabs__link">
+          
+  
+  ADOPTED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../0004-agents/" class="md-tabs__link">
+          
+  
+  ACCEPTED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../features/0032-message-timing/" class="md-tabs__link">
+          
+  
+  DEMONSTRATED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+    
+  
+  
+    
+    
+      <li class="md-tabs__item md-tabs__item--active">
+        <a href="../../features/0028-introduce/" class="md-tabs__link">
+          
+  
+  PROPOSED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../features/0024-didcomm-over-xmpp/" class="md-tabs__link">
+          
+  
+  STALLED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../0013-overlays/" class="md-tabs__link">
+          
+  
+  RETIRED
+
+        </a>
+      </li>
+    
+  
+
+      
+    </ul>
+  </div>
+</nav>
+    
+  
+</header>
+    
+    <div class="md-container" data-md-component="container">
+      
+      
+        
+      
+      <main class="md-main" data-md-component="main">
+        <div class="md-main__inner md-grid">
+          
+            
+              
+              <div class="md-sidebar md-sidebar--primary" data-md-component="sidebar" data-md-type="navigation" >
+                <div class="md-sidebar__scrollwrap">
+                  <div class="md-sidebar__inner">
+                    
+
+
+  
+
+
+<nav class="md-nav md-nav--primary md-nav--lifted" aria-label="Navigation" data-md-level="0">
+  <label class="md-nav__title" for="__drawer">
+    <a href="../.." title="Hyperledger Aries Interoperability Profiles / RFCs" class="md-nav__button md-logo" aria-label="Hyperledger Aries Interoperability Profiles / RFCs" data-md-component="logo">
+      
+  <img src="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/Hyperledger_Aries_Logo_White.png" alt="logo">
+
+    </a>
+    Hyperledger Aries Interoperability Profiles / RFCs
+  </label>
+  
+    <div class="md-nav__source">
+      <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
+  <div class="md-source__icon md-icon">
+    
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+  </div>
+  <div class="md-source__repository">
+    hyperledger/aries-rfcs
+  </div>
+</a>
+    </div>
+  
+  <ul class="md-nav__list" data-md-scrollfix>
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_1" >
+        
+          
+          <label class="md-nav__link" for="__nav_1" id="__nav_1_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    Welcome
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_1_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_1">
+            <span class="md-nav__icon md-icon"></span>
+            Welcome
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../.." class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Welcome
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../RFCindex/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    All RFCs by Status
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0000-template/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    RFC Template
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0000-template-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Protocol RFC Template
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_2" >
+        
+          
+          <label class="md-nav__link" for="__nav_2" id="__nav_2_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    Governance
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_2_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_2">
+            <span class="md-nav__icon md-icon"></span>
+            Governance
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../MAINTAINERS/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Maintainers
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../contributing/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Contributing
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../github-issues/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Submitting Issues
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../LICENSE/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    License
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../SECURITY/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Security
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_3" >
+        
+          
+          <label class="md-nav__link" for="__nav_3" id="__nav_3_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    AIP 2.0
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_3_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_3">
+            <span class="md-nav__icon md-icon"></span>
+            AIP 2.0
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0003-protocols/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0003 Protocols
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0004-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0004 Agents
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0005-didcomm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0005 DID Communication
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0008-message-id-and-threading/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0008 Message ID and Threading
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0011-decorators/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0011 Decorators
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0015-acks/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0015 ACKs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0017-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0017 Attachments
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0019-encryption-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0019 Encryption Envelope
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0020-message-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0020 Message Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0023-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0023 DID Exchange Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0025-didcomm-transports/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0025 DIDComm Transports
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0035-report-problem/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0035 Report Problem Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0044-didcomm-file-and-mime-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0044 DIDComm File and MIME Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0046-mediators-and-relays/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0046 Mediators and Relays
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0047-json-ld-compatibility/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0047 JSON-LD Compatibility
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0048-trust-ping/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0048 Trust Ping Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0050-wallets/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0050 Wallets
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0092-transport-return-route/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0092 Transports Return Route
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0094-cross-domain-messaging/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0094 Cross-Domain Messaging
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0095-basic-message/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0095 Basic Message Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0183-revocation-notification/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0183 Revocation Notification 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0211-route-coordination/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0211 Mediator Coordination Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0360-use-did-key/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0360 did:key Usage
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0434-outofband/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0434 Out-of-Band Protocol 1.1
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0441-present-proof-best-practices/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0441 Prover and Verifier Best Practices for Proof Presentation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0453-issue-credential-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0453 Issue Credential Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0454-present-proof-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0454 Present Proof Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0510-dif-pres-exch-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0519-goal-codes/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0519 Goal Codes
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0557-discover-features-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0557 Discover Features Protocol v2.x
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0592-indy-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0593-json-ld-cred-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_4" >
+        
+          
+          <label class="md-nav__link" for="__nav_4" id="__nav_4_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    ADOPTED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_4_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_4">
+            <span class="md-nav__icon md-icon"></span>
+            ADOPTED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0003-protocols/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0003 Protocols
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0005-didcomm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0005 DID Communication
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0008-message-id-and-threading/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0008 Message ID and Threading
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0011-decorators/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0011 Decorators
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0015-acks/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0015 ACKs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0017-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0017 Attachments
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0019-encryption-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0019 Encryption Envelope
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0020-message-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0020 Message Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0021-didcomm-message-anatomy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0021 DIDComm Message Anatomy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0023-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0023 DID Exchange v1
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0025-didcomm-transports/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0025 DIDComm Transports
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0031-discover-features/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0031 Discover Features Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0035-report-problem/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0035 Report Problem Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0036-issue-credential/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0036 Issue Credential Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0037-present-proof/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0037 Present Proof Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0048-trust-ping/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0048 Trust Ping Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0092-transport-return-route/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0092 Transports Return Route
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0094-cross-domain-messaging/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0094 Cross-Domain Messaging
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0095-basic-message/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0095 Basic Message Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0160-connection-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0160 Connection Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0211-route-coordination/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0211 Mediator Coordination Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0302-aries-interop-profile/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0302 Aries Interop Profile
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0360-use-did-key/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0360 did:key Usage
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0434-outofband/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0434 Out-of-Band Protocol 1.1
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0441-present-proof-best-practices/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0441 Prover and Verifier Best Practices for Proof Presentation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0453-issue-credential-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0453 Issue Credential Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0454-present-proof-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0454 Present Proof Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0496-transition-to-oob-and-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0496 Transition to the Out of Band Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0510-dif-pres-exch-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0557-discover-features-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0557 Discover Features Protocol v2.x
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0592-indy-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0593-json-ld-cred-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_5" >
+        
+          
+          <label class="md-nav__link" for="__nav_5" id="__nav_5_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    ACCEPTED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_5_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_5">
+            <span class="md-nav__icon md-icon"></span>
+            ACCEPTED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0004-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0004 Agents
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0006-ssi-notation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0006 SSI Notation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0044-didcomm-file-and-mime-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0044 DIDComm File and MIME Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0046-mediators-and-relays/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0046 Mediators and Relays
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0047-json-ld-compatibility/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0047 JSON-LD Compatibility
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0049-repudiation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0049 Repudiation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0050-wallets/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0050 Wallets
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0183-revocation-notification/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0183 Revocation Notification 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0519-goal-codes/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0519 Goal Codes
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0587-encryption-envelope-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0587 Encryption Envelope v2
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0646-bbs-credentials/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0646 W3C Credential Exchange using BBS+ Signatures
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0685-pickup-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0685 Pickup Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0721-revocation-notification-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0721 Revocation Notification 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0793-unqualfied-dids-transition/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0793 Unqualified DID Transition
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0794-did-rotate/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0794 DID Rotate 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_6" >
+        
+          
+          <label class="md-nav__link" for="__nav_6" id="__nav_6_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    DEMONSTRATED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_6_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_6">
+            <span class="md-nav__icon md-icon"></span>
+            DEMONSTRATED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0032-message-timing/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0032 Message Timing
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0042-lox/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0042 LOX -- A more secure pluggable framework for protecting wallet keys
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0043-l10n/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0043 l10n (Locali[s|z]ation)
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0113-question-answer/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0113 Question Answer Protocol 0.9
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0509-action-menu/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0509 Action Menu Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0748-n-wise-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0748 N-wise DID Exchange Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0755-oca-for-aries/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0755 Overlays Capture Architecture (OCA) For Aries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0756-oca-for-aries-style-guide/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0756 OCA for Aries Style Guide
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0780-data-urls-images/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0780 Use Data URLs for Images and More in Credential Attributes
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0804-didcomm-rpc/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0804 DIDComm Remote Procedure Call (DRPC)
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0809-w3c-data-integrity-credential-attachment/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0809 W3C Verifiable Credential Data Integrity Attachment format for requesting and issuing credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+    
+  
+  
+  
+    
+    
+    
+      
+        
+        
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--active md-nav__item--section md-nav__item--nested">
+      
+        
+        
+        <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_7" checked>
+        
+          
+          <label class="md-nav__link" for="__nav_7" id="__nav_7_label" tabindex="">
+            
+  
+  <span class="md-ellipsis">
+    PROPOSED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_7_label" aria-expanded="true">
+          <label class="md-nav__title" for="__nav_7">
+            <span class="md-nav__icon md-icon"></span>
+            PROPOSED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0028-introduce/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0028 Introduce Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0034-message-tracing/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0034 Message Tracing
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0056-service-decorator/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0056 Service Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0066-non-repudiable-cryptographic-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0066 Non-Repudiable Signature for Cryptographic Envelope
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0067-didcomm-diddoc-conventions/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0067 DIDComm DID document conventions
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0074-didcomm-best-practices/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0074 DIDComm Best Practices
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0103-indirect-identity-control/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0103 Indirect Identity Control
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0104-chained-credentials/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0104 Chained Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0124-did-resolution-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0124 DID Resolution Protocol 0.9
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0167-data-consent-lifecycle/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0167 Data Consent Lifecycle
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0212-pickup/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0212 Pickup Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0213-transfer-policy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0213 Transfer Policy Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0214-help-me-discover/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0214 "Help Me Discover" Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0231-biometric-service-provider/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0231 Biometric Service Provider
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0268-unified-didcomm-agent-deeplinking/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0268 Unified DIDCOMM Deeplinking
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0270-interop-test-suite/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0270 Interop Test Suite
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0345-community-coordinated-update/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0345 Community Coordinated Update
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0346-didcomm-between-two-mobile-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0346 DIDComm Between Two Mobile Agents Using Cloud Agent Mediator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0347-proof-negotiation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0347 Proof Negotiation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0430-machine-readable-governance-frameworks/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0430 Machine-Readable Governance Frameworks
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0440-kms-architectures/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0440 KMS Architectures
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0511-dif-cred-manifest-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0511 Credential-Manifest Attachment format for requesting and presenting credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0530-goal-human-readable-verified-identifer/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0530 Goal - Human Readable Verifiable Identifier
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0559-pppu/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0559 Privacy-Preserving Proof of Uniqueness
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0566-issuer-hosted-custodidal-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0566 Issuer-Hosted Custodial Agents
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0641-linking-binary-objects-to-credentials/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0641 Linking binary objects to credentials using hash based references
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0693-credential-representation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0693 Cross-Platform Credential Representation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0699-push-notifications-apns/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0699 Push Notifications apns Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0700-oob-through-redirect/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0700 Out-of-Band through redirect
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0728-device-binding-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0728 Device Binding Attachments
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0734-push-notifications-fcm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0734 Push Notifications fcm Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0757-push-notification/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0757 Push Notification
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0771-anoncreds-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0771 AnonCreds Attachment Formats for Requesting and Presenting Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0799-long-term-support/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0799 Aries Long Term Support Releases
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+    
+  
+  
+  
+    <li class="md-nav__item md-nav__item--active">
+      
+      <input class="md-nav__toggle md-toggle" type="checkbox" id="__toc">
+      
+      
+        
+      
+      
+        <label class="md-nav__link md-nav__link--active" for="__toc">
+          
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+          <span class="md-nav__icon md-icon"></span>
+        </label>
+      
+      <a href="./" class="md-nav__link md-nav__link--active">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+      
+        
+
+<nav class="md-nav md-nav--secondary" aria-label="Table of contents">
+  
+  
+  
+    
+  
+  
+    <label class="md-nav__title" for="__toc">
+      <span class="md-nav__icon md-icon"></span>
+      Table of contents
+    </label>
+    <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
+      
+        <li class="md-nav__item">
+  <a href="#summary" class="md-nav__link">
+    <span class="md-ellipsis">
+      Summary
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#motivation" class="md-nav__link">
+    <span class="md-ellipsis">
+      Motivation
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#tutorial" class="md-nav__link">
+    <span class="md-ellipsis">
+      Tutorial
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Tutorial">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#training" class="md-nav__link">
+    <span class="md-ellipsis">
+      Training
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#the-compressed-out-of-band-message" class="md-nav__link">
+    <span class="md-ellipsis">
+      The Compressed Out of Band Message
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#redirect-on-failure" class="md-nav__link">
+    <span class="md-ellipsis">
+      Redirect on failure
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#dictionary-storage" class="md-nav__link">
+    <span class="md-ellipsis">
+      Dictionary Storage
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#drawbacks" class="md-nav__link">
+    <span class="md-ellipsis">
+      Drawbacks
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#rationale-and-alternatives" class="md-nav__link">
+    <span class="md-ellipsis">
+      Rationale and alternatives
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Rationale and alternatives">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#qr-code-quality" class="md-nav__link">
+    <span class="md-ellipsis">
+      QR Code Quality
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#reducing-need-for-redirect-support" class="md-nav__link">
+    <span class="md-ellipsis">
+      Reducing need for redirect support
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#binary-based-format" class="md-nav__link">
+    <span class="md-ellipsis">
+      Binary based format
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#standard-compression-without-dictionaries" class="md-nav__link">
+    <span class="md-ellipsis">
+      Standard Compression without dictionaries
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#didcomm-compression" class="md-nav__link">
+    <span class="md-ellipsis">
+      DIDComm Compression
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#process-of-creating-new-dictionaries" class="md-nav__link">
+    <span class="md-ellipsis">
+      Process of creating new dictionaries
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#distribution-of-dictionaries" class="md-nav__link">
+    <span class="md-ellipsis">
+      Distribution of dictionaries
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#prior-art" class="md-nav__link">
+    <span class="md-ellipsis">
+      Prior art
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#unresolved-questions" class="md-nav__link">
+    <span class="md-ellipsis">
+      Unresolved questions
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#implementations" class="md-nav__link">
+    <span class="md-ellipsis">
+      Implementations
+    </span>
+  </a>
+  
+</li>
+      
+    </ul>
+  
+</nav>
+      
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_8" >
+        
+          
+          <label class="md-nav__link" for="__nav_8" id="__nav_8_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    STALLED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_8_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_8">
+            <span class="md-nav__icon md-icon"></span>
+            STALLED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0024-didcomm-over-xmpp/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0024 DIDComm over XMPP
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0029-message-trust-contexts/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0029 Message Trust Contexts
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0030-sync-connection/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0030 Sync Connection Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0075-payment-decorators/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0075 Payment Decorators
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0114-predefined-identities/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0114 Predefined Identities
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0116-evidence-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0116 Evidence Exchange Protocol 0.9
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0193-coin-flip/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0193 Coin Flip Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0207-credential-fraud-threat-model/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0207 Credential Fraud Threat Model
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0217-linkable-message-paths/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0217 Linkable Message Paths
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0249-rich-schema-contexts/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0249 Aries Rich Schema Contexts
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0250-rich-schemas/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0250 Rich Schema Objects
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0257-private-credential-issuance/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0257 Private Credential Issuance
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0281-rich-schemas/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0281 Aries Rich Schemas
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0289-toip-stack/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0289 The Trust Over IP Stack
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0309-didauthz/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0309 DIDAuthZ
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0327-crypto-service/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0327 Crypto service Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0334-jwe-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0334 JWE envelope 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0335-http-over-didcomm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0335 HTTP Over DIDComm
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0351-purpose-decorator/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0351 Purpose Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0418-rich-schema-encoding/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0418 Aries Rich Schema Encoding Objects
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0420-rich-schemas-common/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0420 Rich Schema Objects Common
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0428-prepare-issue-rich-credential/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0428 Prerequisites to Issue Rich Credential
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0429-prepare-req-rich-pres/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0429 Prerequisites to Request Rich Presentation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0445-rich-schema-mapping/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0445 Aries Rich Schema Mapping
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0446-rich-schema-cred-def/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0446 Aries Rich Schema Credential Definition
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0478-coprotocols/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0478 Coprotocols
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0482-coprotocol-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0482 Coprotocol Protocol 0.5
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_9" >
+        
+          
+          <label class="md-nav__link" for="__nav_9" id="__nav_9_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    RETIRED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_9_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_9">
+            <span class="md-nav__icon md-icon"></span>
+            RETIRED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0013-overlays/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0013 Overlays
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0051-dkms/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0051 Decentralized Key Management
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0234-signature-decorator/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0234 Signature Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0303-v01-credential-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0303 V0.1 Credential Exchange (Deprecated)
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0317-please-ack/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0317 Please ACK Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0348-transition-msg-type-to-https/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0348 Transition Message Type to HTTPs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../features/0627-static-peer-dids/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0627 Static Peer DIDs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+  </ul>
+</nav>
+                  </div>
+                </div>
+              </div>
+            
+            
+              
+              <div class="md-sidebar md-sidebar--secondary" data-md-component="sidebar" data-md-type="toc" >
+                <div class="md-sidebar__scrollwrap">
+                  <div class="md-sidebar__inner">
+                    
+
+<nav class="md-nav md-nav--secondary" aria-label="Table of contents">
+  
+  
+  
+    
+  
+  
+    <label class="md-nav__title" for="__toc">
+      <span class="md-nav__icon md-icon"></span>
+      Table of contents
+    </label>
+    <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
+      
+        <li class="md-nav__item">
+  <a href="#summary" class="md-nav__link">
+    <span class="md-ellipsis">
+      Summary
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#motivation" class="md-nav__link">
+    <span class="md-ellipsis">
+      Motivation
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#tutorial" class="md-nav__link">
+    <span class="md-ellipsis">
+      Tutorial
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Tutorial">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#training" class="md-nav__link">
+    <span class="md-ellipsis">
+      Training
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#the-compressed-out-of-band-message" class="md-nav__link">
+    <span class="md-ellipsis">
+      The Compressed Out of Band Message
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#redirect-on-failure" class="md-nav__link">
+    <span class="md-ellipsis">
+      Redirect on failure
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#dictionary-storage" class="md-nav__link">
+    <span class="md-ellipsis">
+      Dictionary Storage
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#drawbacks" class="md-nav__link">
+    <span class="md-ellipsis">
+      Drawbacks
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#rationale-and-alternatives" class="md-nav__link">
+    <span class="md-ellipsis">
+      Rationale and alternatives
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Rationale and alternatives">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#qr-code-quality" class="md-nav__link">
+    <span class="md-ellipsis">
+      QR Code Quality
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#reducing-need-for-redirect-support" class="md-nav__link">
+    <span class="md-ellipsis">
+      Reducing need for redirect support
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#binary-based-format" class="md-nav__link">
+    <span class="md-ellipsis">
+      Binary based format
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#standard-compression-without-dictionaries" class="md-nav__link">
+    <span class="md-ellipsis">
+      Standard Compression without dictionaries
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#didcomm-compression" class="md-nav__link">
+    <span class="md-ellipsis">
+      DIDComm Compression
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#process-of-creating-new-dictionaries" class="md-nav__link">
+    <span class="md-ellipsis">
+      Process of creating new dictionaries
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#distribution-of-dictionaries" class="md-nav__link">
+    <span class="md-ellipsis">
+      Distribution of dictionaries
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#prior-art" class="md-nav__link">
+    <span class="md-ellipsis">
+      Prior art
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#unresolved-questions" class="md-nav__link">
+    <span class="md-ellipsis">
+      Unresolved questions
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#implementations" class="md-nav__link">
+    <span class="md-ellipsis">
+      Implementations
+    </span>
+  </a>
+  
+</li>
+      
+    </ul>
+  
+</nav>
+                  </div>
+                </div>
+              </div>
+            
+          
+          
+            <div class="md-content" data-md-component="content">
+              <article class="md-content__inner md-typeset">
+                
+                  
+
+  
+  
+
+
+<h1 id="0812-compressing-didcomm-messages-using-dictionaries">0812: Compressing DIDComm messages using dictionaries<a class="headerlink" href="#0812-compressing-didcomm-messages-using-dictionaries" title="Permanent link">&para;</a></h1>
+<ul>
+<li>Authors: <a href="mailto:kim@indicio.tech">Kim Ebert</a></li>
+<li>Status: <a href="../../#proposed">PROPOSED</a></li>
+<li>Since: 2022-</li>
+<li>Status Note: Compression theory  </li>
+<li>Supersedes: </li>
+<li>Start Date: 2022-03-10</li>
+<li>Tags: <a href="../../tags/#concept">concept</a></li>
+</ul>
+<h2 id="summary">Summary<a class="headerlink" href="#summary" title="Permanent link">&para;</a></h2>
+<p>Using Dictionary Compression, higher compression rates can be achieved for small messages with known entries.</p>
+<h2 id="motivation">Motivation<a class="headerlink" href="#motivation" title="Permanent link">&para;</a></h2>
+<p>DIDComm messages contain well know values and are often short in size. Using dictionary based compression may reduce the overall size of messages that may be transmitted or stored.</p>
+<h2 id="tutorial">Tutorial<a class="headerlink" href="#tutorial" title="Permanent link">&para;</a></h2>
+<h3 id="training">Training<a class="headerlink" href="#training" title="Permanent link">&para;</a></h3>
+<p>The first step is to determine the type of data that needs to be provided for training, and generating a number of requests that meets that criteria.</p>
+<p>An example of creating such an invite using Aca-py and curl</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a>curl -X POST &quot;http://127.0.0.1:8150/out-of-band/create-invitation&quot; -H &quot;accept: application/json&quot; -H &quot;Content-Type: application/json&quot; -d &quot;{ \&quot;alias\&quot;: \&quot;\&quot;, \&quot;attachments\&quot;: [ ], \&quot;handshake_protocols\&quot;: [ \&quot;did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0\&quot; ], \&quot;metadata\&quot;: {}, \&quot;my_label\&quot;: \&quot;\&quot;, \&quot;use_public_did\&quot;: false}&quot;
+</code></pre></div>
+<p>Result:</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a>{&quot;invitation_url&quot;: &quot;https://localhost:443?oob=eyJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9vdXQtb2YtYmFuZC8xLjAvaW52aXRhdGlvbiIsICJAaWQiOiAiYTYwZDhlYTAtZDg1Zi00NDJkLTk0NTktZTk2NWEyYjg3Nzg1IiwgInNlcnZpY2VzIjogW3siaWQiOiAiI2lubGluZSIsICJ0eXBlIjogImRpZC1jb21tdW5pY2F0aW9uIiwgInJlY2lwaWVudEtleXMiOiBbImRpZDprZXk6ejZNa296SGNjNzI0ajlGOFJBR214bTFOY3hpVlhtOE10c0NMQ0paWktacWRwd0Z3Il0sICJyb3V0aW5nS2V5cyI6IFsiZGlkOmtleTp6Nk1rcTNycDg1cm1qTjRwdnN5WUpWTlZoVXZBNUJwTWFlNkd5MlBUUzVZaHdVelIiLCAiZGlkOmtleTp6Nk1rbnZwTmEzQXdWOHl6SHJaM0s3WXVDdU1adXBiSEt0ZDJwVDN4U3NzODRqenEiXSwgInNlcnZpY2VFbmRwb2ludCI6ICJodHRwczovL21lZGlhdG9yNC50ZXN0LmluZGljaW90ZWNoLmlvOjQ0MyJ9XSwgImhhbmRzaGFrZV9wcm90b2NvbHMiOiBbImRpZDpzb3Y6QnpDYnNOWWhNcmpIaXFaRFRVQVNIZztzcGVjL2RpZGV4Y2hhbmdlLzEuMCJdLCAibGFiZWwiOiAiTGFiIn0=&quot;, &quot;invitation&quot;: {&quot;@type&quot;: &quot;did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/out-of-band/1.0/invitation&quot;, &quot;@id&quot;: &quot;a60d8ea0-d85f-442d-9459-e965a2b87785&quot;, &quot;services&quot;: [{&quot;id&quot;: &quot;#inline&quot;, &quot;type&quot;: &quot;did-communication&quot;, &quot;recipientKeys&quot;: [&quot;did:key:z6MkozHcc724j9F8RAGmxm1NcxiVXm8MtsCLCJZZKZqdpwFw&quot;], &quot;routingKeys&quot;: [&quot;did:key:z6Mkq3rp85rmjN4pvsyYJVNVhUvA5BpMae6Gy2PTS5YhwUzR&quot;, &quot;did:key:z6MknvpNa3AwV8yzHrZ3K7YuCuMZupbHKtd2pT3xSss84jzq&quot;], &quot;serviceEndpoint&quot;: &quot;https://localhost:443&quot;}], &quot;handshake_protocols&quot;: [&quot;did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0&quot;], &quot;label&quot;: &quot;Lab&quot;}, &quot;state&quot;: &quot;initial&quot;, &quot;trace&quot;: false, &quot;invi_msg_id&quot;: &quot;a60d8ea0-d85f-442d-9459-e965a2b87785&quot;}
+</code></pre></div>
+<p>We then extract the data required for the invitation.</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-2-1" name="__codelineno-2-1" href="#__codelineno-2-1"></a>{&quot;@type&quot;: &quot;did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/out-of-band/1.0/invitation&quot;, &quot;@id&quot;: &quot;2dbf6f36-8dc0-4b35-9558-dab26e3ae3c3&quot;, &quot;services&quot;: [{&quot;id&quot;: &quot;#inline&quot;, &quot;type&quot;: &quot;did-communication&quot;, &quot;recipientKeys&quot;: [&quot;did:key:z6MkqfRyf4ycr6HFpo4XyhQp8gBwdBW51Z2yXnxg11AuFZT6&quot;], &quot;routingKeys&quot;: [&quot;did:key:z6Mkq3rp85rmjN4pvsyYJVNVhUvA5BpMae6Gy2PTS5YhwUzR&quot;, &quot;did:key:z6MknvpNa3AwV8yzHrZ3K7YuCuMZupbHKtd2pT3xSss84jzq&quot;], &quot;serviceEndpoint&quot;: &quot;https://localhost:443&quot;}], &quot;handshake_protocols&quot;: [&quot;did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0&quot;], &quot;label&quot;: &quot;Lab&quot;}
+</code></pre></div>
+<p>Finally, we strip out the keys that are specific to the local agent, leaving content that can easily be compressed.</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-3-1" name="__codelineno-3-1" href="#__codelineno-3-1"></a>{&quot;@type&quot;: &quot;did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/out-of-band/1.0/invitation&quot;, &quot;@id:&quot;: &quot;&quot;, &quot;services&quot;: [{&quot;id&quot;: &quot;#inline&quot;, &quot;type&quot;: &quot;did-communication&quot;, &quot;recipientKeys&quot;: [&quot;did:key:&quot;], &quot;routingKeys&quot;: [&quot;did:key:&quot;, &quot;did:key:&quot;], &quot;serviceEndpoint&quot;: &quot;https://:443&quot;}], &quot;handshake_protocols&quot;: [&quot;did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0&quot;], &quot;label&quot;: &quot;Lab&quot;}
+</code></pre></div>
+<p>We do this a hundred or so times, and include other configuration options of interest. ( Research into what should be included here could provide some value )</p>
+<p>We then create the dictionary.</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-4-1" name="__codelineno-4-1" href="#__codelineno-4-1"></a>zstd --train ./data/* -o dict
+</code></pre></div>
+<p>This dictionary can now be used to compress the data before it is base64 encoded into the url.</p>
+<h3 id="the-compressed-out-of-band-message">The Compressed Out of Band Message<a class="headerlink" href="#the-compressed-out-of-band-message" title="Permanent link">&para;</a></h3>
+<p>Using a unique url parameter for compressed out of band messages, the client can determine the alternative behavior to follow.</p>
+<p>The coob message includes the following binary data. The first 4 bytes indicate the dictary to be used, perhaps as an unsiged long. Or alternatively we could use a d= parameter for the storage of the dictionary id.</p>
+<p>Dictionary IDs would be used to indicate which dictionary the client should use. Occassionally, ARIES may release a new dictionary. This new dictionary should not be used for limited time to allow all clients to get the latest dictionaries. These dictionaries could be auto-retrieved by the clients when connection to the internet is available.</p>
+<p>The rest of the coob data is the a compressed zstd binary output. After the binary data is combined together, the data is base64url encoded.</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-5-1" name="__codelineno-5-1" href="#__codelineno-5-1"></a>https://localhost:443?c=sztd&amp;d=1&amp;oob=KLUv_Wc3PnoBMAG1BgBijCwjEIfWAzs-1Bd8YPpweoDAqvElxVlFB2t_B0mLRHdVVVVVwQ1ZRjAL7yxb-TIysjm8Ed-yTeWLF1qo8MlxiEaMtHI3fSrdFbppodFuTwhO6WsiVbU3ECY-bHpEdFBAg8QUpAG-8RKYVKWACeQ87VWx2H7qLWqW-QNtLAt11M6HIEmkxwYucGqk1akI2O1ABcPSONJHGQaQDJnr8mtWyfL4Ho4t6nhZ-XGX-8dUCIn_JQ8CCgCVXyJ1RAnO_AEwww7QY1FQCCwIETfkSRDzzwJ-R-kV6uOdbQ==
+</code></pre></div>
+<p>The URL is reduced from 794 bytes to 370 bytes.(46.6 % of original size) There difference in the QR codes can be seen below.</p>
+<p><img alt="" src="b9y8VTC.png" />
+<img alt="" src="YlU3M52.png" /></p>
+<h3 id="redirect-on-failure">Redirect on failure<a class="headerlink" href="#redirect-on-failure" title="Permanent link">&para;</a></h3>
+<p>If the client cannot decode the coob message, or does not have the appropriate dictionary, the client can visit the url and will be redirected to the decompressed url.</p>
+<h2 id="dictionary-storage">Dictionary Storage<a class="headerlink" href="#dictionary-storage" title="Permanent link">&para;</a></h2>
+<p>Dictionaries could be stored along side the RFCs, or an alternative method for transfering dictionaries between clients could be derived.</p>
+<h2 id="drawbacks">Drawbacks<a class="headerlink" href="#drawbacks" title="Permanent link">&para;</a></h2>
+<p>Dictionaries may need to be regularly rebuilt to adjust to new protocols. Some dictionaries may not provide any compression benefits depending upon the message.</p>
+<h2 id="rationale-and-alternatives">Rationale and alternatives<a class="headerlink" href="#rationale-and-alternatives" title="Permanent link">&para;</a></h2>
+<h3 id="qr-code-quality">QR Code Quality<a class="headerlink" href="#qr-code-quality" title="Permanent link">&para;</a></h3>
+<p>By reducing the size of QR codes for offline or cases where URL redirects are not available, the QR code becomes more manageable.</p>
+<h3 id="reducing-need-for-redirect-support">Reducing need for redirect support<a class="headerlink" href="#reducing-need-for-redirect-support" title="Permanent link">&para;</a></h3>
+<p>URL Shorterning services may introduce privacy concerns</p>
+<h3 id="binary-based-format">Binary based format<a class="headerlink" href="#binary-based-format" title="Permanent link">&para;</a></h3>
+<p>Instead of using compression, a binary file format would reduce overall message size.</p>
+<h3 id="standard-compression-without-dictionaries">Standard Compression without dictionaries<a class="headerlink" href="#standard-compression-without-dictionaries" title="Permanent link">&para;</a></h3>
+<h4 id="gzip">gzip<a class="headerlink" href="#gzip" title="Permanent link">&para;</a></h4>
+<p>Using</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-6-1" name="__codelineno-6-1" href="#__codelineno-6-1"></a>gzip -9
+</code></pre></div>
+<p>We can reduce the size of the Out of Band invitation.</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-7-1" name="__codelineno-7-1" href="#__codelineno-7-1"></a>https://localhost:443?c=gzip&amp;oob=H4sICODx-mUCA3RtcC50eHQAhZFdb5swFIbv9ysqdjtCykdC2E3TbC1qCpqaDy1M02Ts03CSYDvYkEDV_z6cTVsvJu3a5338nPO-WDe6lWBFVxZDFinRRLfdLFfppkiqXYzH7NNyNV3E249KAnVErW3xbOeEM-d6MHSQN6iJRsGtD1fWDTIDIqMhC4EMbRYGz7bvu8ye-MHEhskoIG4ejsdhYMYVVA1SUH3m24v1K_se-QE5mOc3XjYVZVlzpH--qoCiROB6Du0FcNHfQxt1o2QvupjSsevvJnfh0_S-PJfXKT3j-msZJlrNHmcPWTbPjkye7k7Wd4PrF0O-_Sfs6FUyDKpyl_qyUe3mYZ2ui1UzDW5lQmB037pflotgU5xW3ZNRe5vljUyJNz2tw7aLq8ybjzf1rE6yWubxXDNXLr3zQqnQ33XHi8jvm3zmTArk2uxfaC1V5DglMCRaVP5Ag9ID5AwpCg20GKCIfN-zXg2h6LtRBdnDD1kJLag4_F3pf_X2M3CmPWELpt6L0YHkcDAejyS3Xt_9BC2pH8MxAgAA
+</code></pre></div>
+<p>Using gzip, we can reduce the size of the Out of Band invitation from 775 bytes to 590 bytes. (76.13 % of original size)</p>
+<h4 id="zstd-without-a-dictionary">ZSTD without a dictionary<a class="headerlink" href="#zstd-without-a-dictionary" title="Permanent link">&para;</a></h4>
+<p>Using</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-8-1" name="__codelineno-8-1" href="#__codelineno-8-1"></a>zstd -9
+</code></pre></div>
+<p>We can reduce the size of the Out of Band invitation.</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-9-1" name="__codelineno-9-1" href="#__codelineno-9-1"></a>https://localhost:443?c=zstd&amp;oob=KLUv_WQxAW0MAPbYVCjgzMwDaJPAFkV01uPxaHNM71pq1L8QfLwg044FcGs2cBMMwwwjDC8ESQBJAE4AEMhKUkIT1LRQg_q0DQe1XxAXAvHi33T_dz9qMAYie6kGTWBoeziqnjVBxqJELJWDrPOWprs2DKY1SWhQfVhX9m1cVNEzuAsiRQsSBone1-QeLv-p2AD34RQiDjMBopHSo1YrxJvLEVagb0Cf7Oufv3pX_3ochyvk9zn3AyIFxKKK2ut_nWtqPh5TkyjlgDgEoWSa8pkqWbJ7YmnZyy5P4mEekynrrBCcF09kolj-rkNo8WwYilJpkEAFh9MrG1CRz7JdsMsCBtRflpiG66iZu6mTub89HBE9CZ5sO9kkywIAFVGjDBzXKMczl2714_YtB1e8cZclfEM3bS_dKuIkZYWfsVXf-Ovb-4ytfTNkhzd961wUVTrvve37ONuLEBE7oUZOHRQgMMKgpQeLQytzAcvFxYE1CCvGeoAVfTFYf7zoaWmohyZtK6wtoqCuRTa3JQrbbxSl8RATCDPtnYPf
+</code></pre></div>
+<p>Using zstd without a dictionary, we can reduce the Out of Band invitation from 775 bytes to 582 bytes. (75.10 % of original size)</p>
+<h3 id="didcomm-compression">DIDComm Compression<a class="headerlink" href="#didcomm-compression" title="Permanent link">&para;</a></h3>
+<p>It would be possible to use compression in DIDComm communications. Each message would be compressed individually, as DIDComm doesn't guarentee the order of messages being delievered.</p>
+<p>Things to consider</p>
+<ul>
+<li>Compress may not want to be used until Discover ../../features is shared</li>
+<li>It may be possible to sharing custom dictionaries as a separate protocol</li>
+</ul>
+<h3 id="process-of-creating-new-dictionaries">Process of creating new dictionaries<a class="headerlink" href="#process-of-creating-new-dictionaries" title="Permanent link">&para;</a></h3>
+<p>To be defined</p>
+<h3 id="distribution-of-dictionaries">Distribution of dictionaries<a class="headerlink" href="#distribution-of-dictionaries" title="Permanent link">&para;</a></h3>
+<p>If dictionaries are used, they should be included in DIDComm libraries
+The dictionaries may be a dependency of a DIDComm library</p>
+<h2 id="prior-art">Prior art<a class="headerlink" href="#prior-art" title="Permanent link">&para;</a></h2>
+<p>[zstd] (<a href="http://facebook.github.io/zstd/">http://facebook.github.io/zstd/</a>)
+<a href="https://github.com/facebook/zstd/blob/dev/programs/zstd.1.md">zstd manual</a>
+<a href="https://datatracker.ietf.org/doc/html/rfc7932">brotli</a>
+<a href="https://en.wikipedia.org/wiki/Zlib">zlib</a>
+<a href="https://datatracker.ietf.org/doc/html/rfc1951">DEFLATE</a></p>
+<h2 id="unresolved-questions">Unresolved questions<a class="headerlink" href="#unresolved-questions" title="Permanent link">&para;</a></h2>
+<ul>
+<li>Where are dictionaries stored</li>
+<li>How do we specify compression will be used for DIDComm messages</li>
+<li>What to do when a client doesn't support compression.</li>
+</ul>
+<h2 id="implementations">Implementations<a class="headerlink" href="#implementations" title="Permanent link">&para;</a></h2>
+<p><em>Implementation Notes</em> <a href="../../#accepted">may need to include a link to test results</a>.</p>
+<table>
+<thead>
+<tr>
+<th>Name / Link</th>
+<th>Implementation Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td></td>
+<td></td>
+</tr>
+</tbody>
+</table>
+
+
+
+
+
+
+
+
+
+
+
+
+                
+              </article>
+            </div>
+          
+          
+<script>var target=document.getElementById(location.hash.slice(1));target&&target.name&&(target.checked=target.name.startsWith("__tabbed_"))</script>
+        </div>
+        
+          <button type="button" class="md-top md-icon" data-md-component="top" hidden>
+  
+  <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M13 20h-2V8l-5.5 5.5-1.42-1.42L12 4.16l7.92 7.92-1.42 1.42L13 8z"/></svg>
+  Back to top
+</button>
+        
+      </main>
+      
+        <footer class="md-footer">
+  
+    
+      
+      <nav class="md-footer__inner md-grid" aria-label="Footer" >
+        
+          
+          <a href="../0799-long-term-support/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0799 Aries Long Term Support Releases">
+            <div class="md-footer__button md-icon">
+              
+              <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
+            </div>
+            <div class="md-footer__title">
+              <span class="md-footer__direction">
+                Previous
+              </span>
+              <div class="md-ellipsis">
+                0799 Aries Long Term Support Releases
+              </div>
+            </div>
+          </a>
+        
+        
+          
+          <a href="../../features/0829-VDR-Proxy/" class="md-footer__link md-footer__link--next" aria-label="Next: 0829 VDR Proxy">
+            <div class="md-footer__title">
+              <span class="md-footer__direction">
+                Next
+              </span>
+              <div class="md-ellipsis">
+                0829 VDR Proxy
+              </div>
+            </div>
+            <div class="md-footer__button md-icon">
+              
+              <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M4 11v2h12l-5.5 5.5 1.42 1.42L19.84 12l-7.92-7.92L10.5 5.5 16 11z"/></svg>
+            </div>
+          </a>
+        
+      </nav>
+    
+  
+  <div class="md-footer-meta md-typeset">
+    <div class="md-footer-meta__inner md-grid">
+      <div class="md-copyright">
+  
+  
+    Made with
+    <a href="https://squidfunk.github.io/mkdocs-material/" target="_blank" rel="noopener">
+      Material for MkDocs
+    </a>
+  
+</div>
+      
+    </div>
+  </div>
+</footer>
+      
+    </div>
+    <div class="md-dialog" data-md-component="dialog">
+      <div class="md-dialog__inner md-typeset"></div>
+    </div>
+    
+    
+    <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
+    
+    
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
+      
+    
+  </body>
+</html>
\ No newline at end of file
diff --git a/main/contributing/index.html b/main/contributing/index.html
index 6d04d905d..b9a1da6a8 100644
--- a/main/contributing/index.html
+++ b/main/contributing/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -896,7 +896,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -917,7 +917,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -938,7 +938,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -959,7 +959,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -980,7 +980,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -1001,7 +1001,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -1022,7 +1022,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -1043,7 +1043,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -1064,7 +1064,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -1085,7 +1085,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1106,7 +1106,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1127,7 +1127,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1148,7 +1148,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1169,7 +1169,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1190,7 +1190,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1211,7 +1211,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1232,7 +1232,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1253,7 +1253,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1274,7 +1274,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1295,7 +1295,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1316,7 +1316,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1358,7 +1358,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1379,7 +1379,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1421,7 +1421,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1442,7 +1442,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1463,7 +1463,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1505,7 +1505,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1526,7 +1526,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1547,7 +1547,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3452,6 +3452,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3620,6 +3641,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3662,6 +3704,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3677,6 +3740,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4859,7 +4964,7 @@ <h4 id="how-to-sign-off-previous-commits">How to Sign Off Previous Commits<a cla
     <script id="__config" type="application/json">{"base": "..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0015-acks/index.html b/main/features/0015-acks/index.html
index ceb027b4c..f09f8be46 100644
--- a/main/features/0015-acks/index.html
+++ b/main/features/0015-acks/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3512,6 +3512,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3680,6 +3701,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3722,6 +3764,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3737,6 +3800,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5014,7 +5119,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0019-encryption-envelope/index.html b/main/features/0019-encryption-envelope/index.html
index f81890eda..18e904daf 100644
--- a/main/features/0019-encryption-envelope/index.html
+++ b/main/features/0019-encryption-envelope/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3365,6 +3365,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3533,6 +3554,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3575,6 +3617,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3590,6 +3653,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4913,7 +5018,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0019-encryption-envelope/schema/index.html b/main/features/0019-encryption-envelope/schema/index.html
index c59c4caf0..4e200fbec 100644
--- a/main/features/0019-encryption-envelope/schema/index.html
+++ b/main/features/0019-encryption-envelope/schema/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4509,7 +4614,7 @@ <h1 id="schema">Schema<a class="headerlink" href="#schema" title="Permanent link
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0023-did-exchange/index.html b/main/features/0023-did-exchange/index.html
index 8d125540a..6c3fafa8a 100644
--- a/main/features/0023-did-exchange/index.html
+++ b/main/features/0023-did-exchange/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3593,6 +3593,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3761,6 +3782,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3803,6 +3845,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3818,6 +3881,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5378,7 +5483,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0024-didcomm-over-xmpp/index.html b/main/features/0024-didcomm-over-xmpp/index.html
index 5cbe72f04..c9d81ecb5 100644
--- a/main/features/0024-didcomm-over-xmpp/index.html
+++ b/main/features/0024-didcomm-over-xmpp/index.html
@@ -9,14 +9,14 @@
       
       
       
-        <link rel="prev" href="../../concepts/0799-long-term-support/">
+        <link rel="prev" href="../0829-VDR-Proxy/">
       
       
         <link rel="next" href="../../concepts/0029-message-trust-contexts/">
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4932,7 +5037,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
       <nav class="md-footer__inner md-grid" aria-label="Footer" >
         
           
-          <a href="../../concepts/0799-long-term-support/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0799 Aries Long Term Support Releases">
+          <a href="../0829-VDR-Proxy/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0829 VDR Proxy">
             <div class="md-footer__button md-icon">
               
               <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
@@ -4942,7 +5047,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
                 Previous
               </span>
               <div class="md-ellipsis">
-                0799 Aries Long Term Support Releases
+                0829 VDR Proxy
               </div>
             </div>
           </a>
@@ -4992,7 +5097,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0025-didcomm-transports/index.html b/main/features/0025-didcomm-transports/index.html
index 1deb86352..4967e13cc 100644
--- a/main/features/0025-didcomm-transports/index.html
+++ b/main/features/0025-didcomm-transports/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3497,6 +3497,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3665,6 +3686,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3707,6 +3749,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3722,6 +3785,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4904,7 +5009,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0028-introduce/index.html b/main/features/0028-introduce/index.html
index aa2a2f0b5..6990d0b72 100644
--- a/main/features/0028-introduce/index.html
+++ b/main/features/0028-introduce/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3539,6 +3539,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3707,6 +3728,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3749,6 +3791,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3764,6 +3827,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5242,7 +5347,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0030-sync-connection/abandon-connection-protocol/index.html b/main/features/0030-sync-connection/abandon-connection-protocol/index.html
index 1e771c948..ad03865c5 100644
--- a/main/features/0030-sync-connection/abandon-connection-protocol/index.html
+++ b/main/features/0030-sync-connection/abandon-connection-protocol/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4559,7 +4664,7 @@ <h5 id="announce"><code>announce</code><a class="headerlink" href="#announce" ti
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0030-sync-connection/index.html b/main/features/0030-sync-connection/index.html
index 19246ff79..9c19be0f8 100644
--- a/main/features/0030-sync-connection/index.html
+++ b/main/features/0030-sync-connection/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5060,7 +5165,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0030-sync-connection/test_cases/index.html b/main/features/0030-sync-connection/test_cases/index.html
index b6b28bda0..b0eca2716 100644
--- a/main/features/0030-sync-connection/test_cases/index.html
+++ b/main/features/0030-sync-connection/test_cases/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4515,7 +4620,7 @@ <h3 id="scenarios-each-starts-over-at-the-initial-conditions">Scenarios (each st
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0031-discover-features/index.html b/main/features/0031-discover-features/index.html
index 91090bbcc..0de1ef15c 100644
--- a/main/features/0031-discover-features/index.html
+++ b/main/features/0031-discover-features/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3476,6 +3476,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3644,6 +3665,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3686,6 +3728,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3701,6 +3764,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4972,7 +5077,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0032-message-timing/index.html b/main/features/0032-message-timing/index.html
index 3ef6ecfa4..c1db73fa6 100644
--- a/main/features/0032-message-timing/index.html
+++ b/main/features/0032-message-timing/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3425,6 +3425,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3593,6 +3614,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3635,6 +3677,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3650,6 +3713,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4770,7 +4875,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0034-message-tracing/index.html b/main/features/0034-message-tracing/index.html
index be0a9c933..62d6c4169 100644
--- a/main/features/0034-message-tracing/index.html
+++ b/main/features/0034-message-tracing/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3503,6 +3503,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3671,6 +3692,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3713,6 +3755,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3728,6 +3791,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5050,7 +5155,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0035-report-problem/index.html b/main/features/0035-report-problem/index.html
index 885174096..d091ec4ba 100644
--- a/main/features/0035-report-problem/index.html
+++ b/main/features/0035-report-problem/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3584,6 +3584,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3752,6 +3773,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3794,6 +3836,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3809,6 +3872,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5310,7 +5415,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0036-issue-credential/index.html b/main/features/0036-issue-credential/index.html
index f5f896ffb..98c4f08aa 100644
--- a/main/features/0036-issue-credential/index.html
+++ b/main/features/0036-issue-credential/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3554,6 +3554,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3722,6 +3743,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3764,6 +3806,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3779,6 +3842,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5204,7 +5309,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0037-present-proof/index.html b/main/features/0037-present-proof/index.html
index 7c86d296a..8c54b36b4 100644
--- a/main/features/0037-present-proof/index.html
+++ b/main/features/0037-present-proof/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3506,6 +3506,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3674,6 +3695,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3716,6 +3758,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3731,6 +3794,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5088,7 +5193,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0042-lox/index.html b/main/features/0042-lox/index.html
index 7d9a3ee71..f28e6d810 100644
--- a/main/features/0042-lox/index.html
+++ b/main/features/0042-lox/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3461,6 +3461,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3629,6 +3650,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3671,6 +3713,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3686,6 +3749,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4858,7 +4963,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0042-lox/reference_code/index.html b/main/features/0042-lox/reference_code/index.html
index 1720829d7..d5844de7d 100644
--- a/main/features/0042-lox/reference_code/index.html
+++ b/main/features/0042-lox/reference_code/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4692,7 +4797,7 @@ <h2 id="future-work">FUTURE WORK<a class="headerlink" href="#future-work" title=
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0043-l10n/index.html b/main/features/0043-l10n/index.html
index 376ed1a74..78e282de1 100644
--- a/main/features/0043-l10n/index.html
+++ b/main/features/0043-l10n/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3374,6 +3374,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3542,6 +3563,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3584,6 +3626,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3599,6 +3662,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4840,7 +4945,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0043-l10n/localization-section/index.html b/main/features/0043-l10n/localization-section/index.html
index 53b1b604a..447fd9d19 100644
--- a/main/features/0043-l10n/localization-section/index.html
+++ b/main/features/0043-l10n/localization-section/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -184,7 +184,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -402,7 +402,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -746,7 +746,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -767,7 +767,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -788,7 +788,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -809,7 +809,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -830,7 +830,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -851,7 +851,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -872,7 +872,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -893,7 +893,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -914,7 +914,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -935,7 +935,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -956,7 +956,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -977,7 +977,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -998,7 +998,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1019,7 +1019,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1040,7 +1040,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1061,7 +1061,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1082,7 +1082,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1103,7 +1103,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1124,7 +1124,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1145,7 +1145,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1166,7 +1166,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1208,7 +1208,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1229,7 +1229,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1271,7 +1271,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1292,7 +1292,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1313,7 +1313,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1355,7 +1355,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1376,7 +1376,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1397,7 +1397,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3302,6 +3302,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3470,6 +3491,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3512,6 +3554,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3527,6 +3590,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4443,7 +4548,7 @@ <h5 id="localization">Localization<a class="headerlink" href="#localization" tit
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0043-l10n/message-catalog-section/index.html b/main/features/0043-l10n/message-catalog-section/index.html
index 5f9c22d32..e845dc364 100644
--- a/main/features/0043-l10n/message-catalog-section/index.html
+++ b/main/features/0043-l10n/message-catalog-section/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -184,7 +184,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -402,7 +402,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -746,7 +746,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -767,7 +767,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -788,7 +788,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -809,7 +809,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -830,7 +830,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -851,7 +851,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -872,7 +872,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -893,7 +893,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -914,7 +914,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -935,7 +935,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -956,7 +956,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -977,7 +977,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -998,7 +998,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1019,7 +1019,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1040,7 +1040,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1061,7 +1061,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1082,7 +1082,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1103,7 +1103,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1124,7 +1124,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1145,7 +1145,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1166,7 +1166,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1208,7 +1208,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1229,7 +1229,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1271,7 +1271,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1292,7 +1292,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1313,7 +1313,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1355,7 +1355,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1376,7 +1376,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1397,7 +1397,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3302,6 +3302,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3470,6 +3491,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3512,6 +3554,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3527,6 +3590,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4444,7 +4549,7 @@ <h5 id="message-catalog">Message Catalog<a class="headerlink" href="#message-cat
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0044-didcomm-file-and-mime-types/index.html b/main/features/0044-didcomm-file-and-mime-types/index.html
index ccd76b694..d9819ca16 100644
--- a/main/features/0044-didcomm-file-and-mime-types/index.html
+++ b/main/features/0044-didcomm-file-and-mime-types/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3488,6 +3488,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3656,6 +3677,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3698,6 +3740,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3713,6 +3776,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5021,7 +5126,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0048-trust-ping/index.html b/main/features/0048-trust-ping/index.html
index 858ce2527..f7e32f98e 100644
--- a/main/features/0048-trust-ping/index.html
+++ b/main/features/0048-trust-ping/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3425,6 +3425,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3593,6 +3614,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3635,6 +3677,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3650,6 +3713,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4814,7 +4919,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0056-service-decorator/index.html b/main/features/0056-service-decorator/index.html
index d2b531a64..05911efcc 100644
--- a/main/features/0056-service-decorator/index.html
+++ b/main/features/0056-service-decorator/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3437,6 +3437,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3605,6 +3626,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3647,6 +3689,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3662,6 +3725,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4757,7 +4862,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0066-non-repudiable-cryptographic-envelope/index.html b/main/features/0066-non-repudiable-cryptographic-envelope/index.html
index e2ae96093..4ec4a0d14 100644
--- a/main/features/0066-non-repudiable-cryptographic-envelope/index.html
+++ b/main/features/0066-non-repudiable-cryptographic-envelope/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3512,6 +3512,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3680,6 +3701,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3722,6 +3764,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3737,6 +3800,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5043,7 +5148,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0067-didcomm-diddoc-conventions/index.html b/main/features/0067-didcomm-diddoc-conventions/index.html
index 4c680d9c0..0d5968dd7 100644
--- a/main/features/0067-didcomm-diddoc-conventions/index.html
+++ b/main/features/0067-didcomm-diddoc-conventions/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3470,6 +3470,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3638,6 +3659,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3680,6 +3722,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3695,6 +3758,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4953,7 +5058,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0075-payment-decorators/index.html b/main/features/0075-payment-decorators/index.html
index 725589cec..46efadedc 100644
--- a/main/features/0075-payment-decorators/index.html
+++ b/main/features/0075-payment-decorators/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5082,7 +5187,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0092-transport-return-route/index.html b/main/features/0092-transport-return-route/index.html
index 8de331b40..702062135 100644
--- a/main/features/0092-transport-return-route/index.html
+++ b/main/features/0092-transport-return-route/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3428,6 +3428,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3596,6 +3617,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3638,6 +3680,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3653,6 +3716,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4746,7 +4851,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0095-basic-message/index.html b/main/features/0095-basic-message/index.html
index b74573c98..959068584 100644
--- a/main/features/0095-basic-message/index.html
+++ b/main/features/0095-basic-message/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3437,6 +3437,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3605,6 +3626,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3647,6 +3689,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3662,6 +3725,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4795,7 +4900,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0113-question-answer/index.html b/main/features/0113-question-answer/index.html
index c812c8e1d..73eaa302c 100644
--- a/main/features/0113-question-answer/index.html
+++ b/main/features/0113-question-answer/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3326,6 +3326,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3494,6 +3515,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3536,6 +3578,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3551,6 +3614,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4592,7 +4697,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0114-predefined-identities/index.html b/main/features/0114-predefined-identities/index.html
index cf54bb13d..6201a4ffd 100644
--- a/main/features/0114-predefined-identities/index.html
+++ b/main/features/0114-predefined-identities/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4972,7 +5077,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0116-evidence-exchange/digital_notary_usecase/index.html b/main/features/0116-evidence-exchange/digital_notary_usecase/index.html
index 87f134369..d96818faa 100644
--- a/main/features/0116-evidence-exchange/digital_notary_usecase/index.html
+++ b/main/features/0116-evidence-exchange/digital_notary_usecase/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4697,7 +4802,7 @@ <h2 id="commentary">Commentary<a class="headerlink" href="#commentary" title="Pe
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0116-evidence-exchange/eep_glossary/index.html b/main/features/0116-evidence-exchange/eep_glossary/index.html
index 312651aa2..88f6f4b46 100644
--- a/main/features/0116-evidence-exchange/eep_glossary/index.html
+++ b/main/features/0116-evidence-exchange/eep_glossary/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4516,7 +4621,7 @@ <h1 id="evidence-exchange-protocol-glossary">Evidence Exchange Protocol Glossary
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0116-evidence-exchange/index.html b/main/features/0116-evidence-exchange/index.html
index 020ee7e0b..85383a64f 100644
--- a/main/features/0116-evidence-exchange/index.html
+++ b/main/features/0116-evidence-exchange/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5688,7 +5793,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0124-did-resolution-protocol/index.html b/main/features/0124-did-resolution-protocol/index.html
index c5f92fff3..12d9fd43b 100644
--- a/main/features/0124-did-resolution-protocol/index.html
+++ b/main/features/0124-did-resolution-protocol/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3512,6 +3512,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3680,6 +3701,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3722,6 +3764,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3737,6 +3800,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5198,7 +5303,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0160-connection-protocol/index.html b/main/features/0160-connection-protocol/index.html
index 9affac0c8..2e4afa710 100644
--- a/main/features/0160-connection-protocol/index.html
+++ b/main/features/0160-connection-protocol/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3506,6 +3506,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3674,6 +3695,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3716,6 +3758,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3731,6 +3794,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5226,7 +5331,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0183-revocation-notification/index.html b/main/features/0183-revocation-notification/index.html
index f2eb6d40c..7641923ca 100644
--- a/main/features/0183-revocation-notification/index.html
+++ b/main/features/0183-revocation-notification/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3470,6 +3470,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3638,6 +3659,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3680,6 +3722,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3695,6 +3758,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4845,7 +4950,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0193-coin-flip/index.html b/main/features/0193-coin-flip/index.html
index a0a39b0ef..cd097c3ce 100644
--- a/main/features/0193-coin-flip/index.html
+++ b/main/features/0193-coin-flip/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4982,7 +5087,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0211-route-coordination/index.html b/main/features/0211-route-coordination/index.html
index 4b8e519b0..6c456713c 100644
--- a/main/features/0211-route-coordination/index.html
+++ b/main/features/0211-route-coordination/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3539,6 +3539,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3707,6 +3728,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3749,6 +3791,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3764,6 +3827,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5060,7 +5165,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0212-pickup/index.html b/main/features/0212-pickup/index.html
index ecd1db809..826ef0fd3 100644
--- a/main/features/0212-pickup/index.html
+++ b/main/features/0212-pickup/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3512,6 +3512,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3680,6 +3701,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3722,6 +3764,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3737,6 +3800,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4983,7 +5088,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0213-transfer-policy/index.html b/main/features/0213-transfer-policy/index.html
index 936d49293..1462b9b3f 100644
--- a/main/features/0213-transfer-policy/index.html
+++ b/main/features/0213-transfer-policy/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3467,6 +3467,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3635,6 +3656,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3677,6 +3719,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3692,6 +3755,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4837,7 +4942,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0214-help-me-discover/index.html b/main/features/0214-help-me-discover/index.html
index bbbc613f6..65bd77a51 100644
--- a/main/features/0214-help-me-discover/index.html
+++ b/main/features/0214-help-me-discover/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3503,6 +3503,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3671,6 +3692,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3713,6 +3755,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3728,6 +3791,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5026,7 +5131,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0234-signature-decorator/ed25519sha256_single/index.html b/main/features/0234-signature-decorator/ed25519sha256_single/index.html
index a9b519e27..91424eb8f 100644
--- a/main/features/0234-signature-decorator/ed25519sha256_single/index.html
+++ b/main/features/0234-signature-decorator/ed25519sha256_single/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4509,7 +4614,7 @@ <h3 id="verification">Verification<a class="headerlink" href="#verification" tit
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0234-signature-decorator/index.html b/main/features/0234-signature-decorator/index.html
index fa7b3e551..406e2ac3f 100644
--- a/main/features/0234-signature-decorator/index.html
+++ b/main/features/0234-signature-decorator/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4926,7 +5031,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0249-rich-schema-contexts/index.html b/main/features/0249-rich-schema-contexts/index.html
index 695fe820a..cc1c45754 100644
--- a/main/features/0249-rich-schema-contexts/index.html
+++ b/main/features/0249-rich-schema-contexts/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4871,7 +4976,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0281-rich-schemas/index.html b/main/features/0281-rich-schemas/index.html
index 6c396647c..0f6fb6cf5 100644
--- a/main/features/0281-rich-schemas/index.html
+++ b/main/features/0281-rich-schemas/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5152,7 +5257,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0303-v01-credential-exchange/index.html b/main/features/0303-v01-credential-exchange/index.html
index 8f7a9c500..fcb2f1f77 100644
--- a/main/features/0303-v01-credential-exchange/index.html
+++ b/main/features/0303-v01-credential-exchange/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4904,7 +5009,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0309-didauthz/index.html b/main/features/0309-didauthz/index.html
index 7773ccb28..0e0ccb1e6 100644
--- a/main/features/0309-didauthz/index.html
+++ b/main/features/0309-didauthz/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5187,7 +5292,7 @@ <h2 id="references">References<a class="headerlink" href="#references" title="Pe
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0317-please-ack/index.html b/main/features/0317-please-ack/index.html
index 1f30ef3bd..cf3bf9d3e 100644
--- a/main/features/0317-please-ack/index.html
+++ b/main/features/0317-please-ack/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4912,7 +5017,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0327-crypto-service/index.html b/main/features/0327-crypto-service/index.html
index 35fc5d9a5..3825b78b3 100644
--- a/main/features/0327-crypto-service/index.html
+++ b/main/features/0327-crypto-service/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5079,7 +5184,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0334-jwe-envelope/anoncrypt-examples/index.html b/main/features/0334-jwe-envelope/anoncrypt-examples/index.html
index 0be9ce9ea..919424b85 100644
--- a/main/features/0334-jwe-envelope/anoncrypt-examples/index.html
+++ b/main/features/0334-jwe-envelope/anoncrypt-examples/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5541,7 +5646,7 @@ <h4 id="224-x25519-key">2.2.4 X25519 key<a class="headerlink" href="#224-x25519-
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0334-jwe-envelope/authcrypt-examples/index.html b/main/features/0334-jwe-envelope/authcrypt-examples/index.html
index 4da76d0e4..660451a47 100644
--- a/main/features/0334-jwe-envelope/authcrypt-examples/index.html
+++ b/main/features/0334-jwe-envelope/authcrypt-examples/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5709,7 +5814,7 @@ <h4 id="224-x25519-key">2.2.4 X25519 key<a class="headerlink" href="#224-x25519-
     <script id="__config" type="application/json">{"base": "../../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0334-jwe-envelope/index.html b/main/features/0334-jwe-envelope/index.html
index d53cc388c..7a224f254 100644
--- a/main/features/0334-jwe-envelope/index.html
+++ b/main/features/0334-jwe-envelope/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5282,7 +5387,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0335-http-over-didcomm/index.html b/main/features/0335-http-over-didcomm/index.html
index b420b2f43..28456c915 100644
--- a/main/features/0335-http-over-didcomm/index.html
+++ b/main/features/0335-http-over-didcomm/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4891,7 +4996,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0347-proof-negotiation/index.html b/main/features/0347-proof-negotiation/index.html
index d099de714..f7dbc1e8e 100644
--- a/main/features/0347-proof-negotiation/index.html
+++ b/main/features/0347-proof-negotiation/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3470,6 +3470,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3638,6 +3659,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3680,6 +3722,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3695,6 +3758,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5049,7 +5154,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0348-transition-msg-type-to-https/index.html b/main/features/0348-transition-msg-type-to-https/index.html
index fc6ca1007..70d4d5d35 100644
--- a/main/features/0348-transition-msg-type-to-https/index.html
+++ b/main/features/0348-transition-msg-type-to-https/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4838,7 +4943,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0351-purpose-decorator/index.html b/main/features/0351-purpose-decorator/index.html
index 0ab0d6c89..f1b2eee5a 100644
--- a/main/features/0351-purpose-decorator/index.html
+++ b/main/features/0351-purpose-decorator/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4873,7 +4978,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0360-use-did-key/index.html b/main/features/0360-use-did-key/index.html
index 5292fb8d5..3a0562a4d 100644
--- a/main/features/0360-use-did-key/index.html
+++ b/main/features/0360-use-did-key/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3437,6 +3437,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3605,6 +3626,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3647,6 +3689,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3662,6 +3725,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4795,7 +4900,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0418-rich-schema-encoding/index.html b/main/features/0418-rich-schema-encoding/index.html
index cbd13c239..e9a8a1e87 100644
--- a/main/features/0418-rich-schema-encoding/index.html
+++ b/main/features/0418-rich-schema-encoding/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5073,7 +5178,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0428-prepare-issue-rich-credential/index.html b/main/features/0428-prepare-issue-rich-credential/index.html
index a0da6c40a..2914d7dd6 100644
--- a/main/features/0428-prepare-issue-rich-credential/index.html
+++ b/main/features/0428-prepare-issue-rich-credential/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4758,7 +4863,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0429-prepare-req-rich-pres/index.html b/main/features/0429-prepare-req-rich-pres/index.html
index 46fcc8c50..cdbda1ef1 100644
--- a/main/features/0429-prepare-req-rich-pres/index.html
+++ b/main/features/0429-prepare-req-rich-pres/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4736,7 +4841,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0434-outofband/index.html b/main/features/0434-outofband/index.html
index 15b2e8fea..c786db4e1 100644
--- a/main/features/0434-outofband/index.html
+++ b/main/features/0434-outofband/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3626,6 +3626,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3794,6 +3815,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3836,6 +3878,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3851,6 +3914,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5541,7 +5646,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0445-rich-schema-mapping/index.html b/main/features/0445-rich-schema-mapping/index.html
index db3f79ef0..f0b9e5657 100644
--- a/main/features/0445-rich-schema-mapping/index.html
+++ b/main/features/0445-rich-schema-mapping/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5018,7 +5123,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0446-rich-schema-cred-def/index.html b/main/features/0446-rich-schema-cred-def/index.html
index ae63b1f89..412d30873 100644
--- a/main/features/0446-rich-schema-cred-def/index.html
+++ b/main/features/0446-rich-schema-cred-def/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4951,7 +5056,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0453-issue-credential-v2/index.html b/main/features/0453-issue-credential-v2/index.html
index c74b87289..d8892d828 100644
--- a/main/features/0453-issue-credential-v2/index.html
+++ b/main/features/0453-issue-credential-v2/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3536,6 +3536,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3704,6 +3725,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3746,6 +3788,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3761,6 +3824,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5355,7 +5460,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0454-present-proof-v2/index.html b/main/features/0454-present-proof-v2/index.html
index 0360492f6..4156caa9a 100644
--- a/main/features/0454-present-proof-v2/index.html
+++ b/main/features/0454-present-proof-v2/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3581,6 +3581,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3749,6 +3770,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3791,6 +3833,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3806,6 +3869,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5313,7 +5418,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0482-coprotocol-protocol/index.html b/main/features/0482-coprotocol-protocol/index.html
index 9cfa5e553..3ef805ae8 100644
--- a/main/features/0482-coprotocol-protocol/index.html
+++ b/main/features/0482-coprotocol-protocol/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3313,6 +3313,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3481,6 +3502,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3523,6 +3565,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3538,6 +3601,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5064,7 +5169,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0496-transition-to-oob-and-did-exchange/index.html b/main/features/0496-transition-to-oob-and-did-exchange/index.html
index efb98d682..4e8debe98 100644
--- a/main/features/0496-transition-to-oob-and-did-exchange/index.html
+++ b/main/features/0496-transition-to-oob-and-did-exchange/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3461,6 +3461,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3629,6 +3650,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3671,6 +3713,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3686,6 +3749,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4963,7 +5068,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0509-action-menu/index.html b/main/features/0509-action-menu/index.html
index 880e37965..b993c041b 100644
--- a/main/features/0509-action-menu/index.html
+++ b/main/features/0509-action-menu/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3479,6 +3479,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3647,6 +3668,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3689,6 +3731,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3704,6 +3767,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4997,7 +5102,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0510-dif-pres-exch-attach/index.html b/main/features/0510-dif-pres-exch-attach/index.html
index 76511764e..d90714474 100644
--- a/main/features/0510-dif-pres-exch-attach/index.html
+++ b/main/features/0510-dif-pres-exch-attach/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3488,6 +3488,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3656,6 +3677,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3698,6 +3740,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3713,6 +3776,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5420,7 +5525,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0511-dif-cred-manifest-attach/index.html b/main/features/0511-dif-cred-manifest-attach/index.html
index 08dfb091c..94fb8eea3 100644
--- a/main/features/0511-dif-cred-manifest-attach/index.html
+++ b/main/features/0511-dif-cred-manifest-attach/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3479,6 +3479,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3647,6 +3668,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3689,6 +3731,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3704,6 +3767,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4984,7 +5089,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0557-discover-features-v2/index.html b/main/features/0557-discover-features-v2/index.html
index 6771de710..1469db95e 100644
--- a/main/features/0557-discover-features-v2/index.html
+++ b/main/features/0557-discover-features-v2/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3434,6 +3434,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3602,6 +3623,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3644,6 +3686,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3659,6 +3722,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4800,7 +4905,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0587-encryption-envelope-v2/index.html b/main/features/0587-encryption-envelope-v2/index.html
index 0fb81b8d8..fb4f8b1c1 100644
--- a/main/features/0587-encryption-envelope-v2/index.html
+++ b/main/features/0587-encryption-envelope-v2/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3515,6 +3515,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3683,6 +3704,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3725,6 +3767,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3740,6 +3803,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5011,7 +5116,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0592-indy-attachments/index.html b/main/features/0592-indy-attachments/index.html
index aa0fe4623..725191627 100644
--- a/main/features/0592-indy-attachments/index.html
+++ b/main/features/0592-indy-attachments/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3470,6 +3470,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3638,6 +3659,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3680,6 +3722,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3695,6 +3758,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5086,7 +5191,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0593-json-ld-cred-attach/index.html b/main/features/0593-json-ld-cred-attach/index.html
index afbb6d692..c4639949e 100644
--- a/main/features/0593-json-ld-cred-attach/index.html
+++ b/main/features/0593-json-ld-cred-attach/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3470,6 +3470,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3638,6 +3659,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3680,6 +3722,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3695,6 +3758,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4995,7 +5100,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0627-static-peer-dids/index.html b/main/features/0627-static-peer-dids/index.html
index 12d087907..e29de9acf 100644
--- a/main/features/0627-static-peer-dids/index.html
+++ b/main/features/0627-static-peer-dids/index.html
@@ -14,7 +14,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -22,7 +22,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -191,7 +191,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -411,7 +411,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -755,7 +755,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -776,7 +776,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -797,7 +797,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -818,7 +818,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -839,7 +839,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -860,7 +860,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -881,7 +881,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -902,7 +902,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -923,7 +923,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -944,7 +944,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -965,7 +965,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -986,7 +986,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1007,7 +1007,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1028,7 +1028,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1049,7 +1049,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1070,7 +1070,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1091,7 +1091,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1112,7 +1112,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1133,7 +1133,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1154,7 +1154,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1175,7 +1175,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1217,7 +1217,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1238,7 +1238,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1280,7 +1280,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1301,7 +1301,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1322,7 +1322,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1364,7 +1364,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1385,7 +1385,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1406,7 +1406,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3311,6 +3311,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3479,6 +3500,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3521,6 +3563,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3536,6 +3599,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4698,7 +4803,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0641-linking-binary-objects-to-credentials/index.html b/main/features/0641-linking-binary-objects-to-credentials/index.html
index b79eee2d6..52ef383e9 100644
--- a/main/features/0641-linking-binary-objects-to-credentials/index.html
+++ b/main/features/0641-linking-binary-objects-to-credentials/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3316,6 +3316,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3671,6 +3692,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3713,6 +3755,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3728,6 +3791,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5022,7 +5127,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0646-bbs-credentials/index.html b/main/features/0646-bbs-credentials/index.html
index 6d5effbb6..c5081fc84 100644
--- a/main/features/0646-bbs-credentials/index.html
+++ b/main/features/0646-bbs-credentials/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3494,6 +3494,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3662,6 +3683,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3704,6 +3746,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3719,6 +3782,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5033,7 +5138,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0685-pickup-v2/index.html b/main/features/0685-pickup-v2/index.html
index 75f9f6086..83f481e30 100644
--- a/main/features/0685-pickup-v2/index.html
+++ b/main/features/0685-pickup-v2/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3536,6 +3536,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3704,6 +3725,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3746,6 +3788,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3761,6 +3824,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5070,7 +5175,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0693-credential-representation/index.html b/main/features/0693-credential-representation/index.html
index 68cb61803..879ea1ae4 100644
--- a/main/features/0693-credential-representation/index.html
+++ b/main/features/0693-credential-representation/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3316,6 +3316,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3575,6 +3596,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3617,6 +3659,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3632,6 +3695,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4683,7 +4788,7 @@ <h2 id="future-work">Future work<a class="headerlink" href="#future-work" title=
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0699-push-notifications-apns/index.html b/main/features/0699-push-notifications-apns/index.html
index d37dc409c..efe348cca 100644
--- a/main/features/0699-push-notifications-apns/index.html
+++ b/main/features/0699-push-notifications-apns/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3316,6 +3316,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3647,6 +3668,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3689,6 +3731,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3704,6 +3767,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4895,7 +5000,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0721-revocation-notification-v2/index.html b/main/features/0721-revocation-notification-v2/index.html
index f8901cb79..bb079e5ee 100644
--- a/main/features/0721-revocation-notification-v2/index.html
+++ b/main/features/0721-revocation-notification-v2/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3470,6 +3470,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3638,6 +3659,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3680,6 +3722,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3695,6 +3758,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4897,7 +5002,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0728-device-binding-attachments/index.html b/main/features/0728-device-binding-attachments/index.html
index 364c1575f..c5bc623ba 100644
--- a/main/features/0728-device-binding-attachments/index.html
+++ b/main/features/0728-device-binding-attachments/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3316,6 +3316,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3638,6 +3659,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3680,6 +3722,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3695,6 +3758,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4999,7 +5104,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0734-push-notifications-fcm/index.html b/main/features/0734-push-notifications-fcm/index.html
index ead3c8c60..f93cdcb5d 100644
--- a/main/features/0734-push-notifications-fcm/index.html
+++ b/main/features/0734-push-notifications-fcm/index.html
@@ -12,11 +12,11 @@
         <link rel="prev" href="../0728-device-binding-attachments/">
       
       
-        <link rel="next" href="../../concepts/0757-push-notification/">
+        <link rel="next" href="../0745-push-notifications-expo/">
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3316,6 +3316,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3647,6 +3668,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3689,6 +3731,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3704,6 +3767,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4854,13 +4959,13 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
         
         
           
-          <a href="../../concepts/0757-push-notification/" class="md-footer__link md-footer__link--next" aria-label="Next: 0757 Push Notification">
+          <a href="../0745-push-notifications-expo/" class="md-footer__link md-footer__link--next" aria-label="Next: 0745 Push Notifications Expo Protocol 1.0">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                0757 Push Notification
+                0745 Push Notifications Expo Protocol 1.0
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -4897,7 +5002,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0745-push-notifications-expo/index.html b/main/features/0745-push-notifications-expo/index.html
new file mode 100644
index 000000000..f3d3f9035
--- /dev/null
+++ b/main/features/0745-push-notifications-expo/index.html
@@ -0,0 +1,4999 @@
+
+<!doctype html>
+<html lang="en" class="no-js">
+  <head>
+    
+      <meta charset="utf-8">
+      <meta name="viewport" content="width=device-width,initial-scale=1">
+      
+      
+      
+      
+        <link rel="prev" href="../0734-push-notifications-fcm/">
+      
+      
+        <link rel="next" href="../../concepts/0757-push-notification/">
+      
+      
+      <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
+    
+    
+      
+        <title>0745 Push Notifications Expo Protocol 1.0 - Hyperledger Aries Interoperability Profiles / RFCs</title>
+      
+    
+    
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
+      
+        
+        <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
+      
+      
+
+
+    
+    
+      
+    
+    
+      
+        
+        
+        <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
+        <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto:300,300i,400,400i,700,700i%7CRoboto+Mono:400,400i,700,700i&display=fallback">
+        <style>:root{--md-text-font:"Roboto";--md-code-font:"Roboto Mono"}</style>
+      
+    
+    
+    <script>__md_scope=new URL("../..",location),__md_hash=e=>[...e].reduce(((e,_)=>(e<<5)-e+_.charCodeAt(0)),0),__md_get=(e,_=localStorage,t=__md_scope)=>JSON.parse(_.getItem(t.pathname+"."+e)),__md_set=(e,_,t=localStorage,a=__md_scope)=>{try{t.setItem(a.pathname+"."+e,JSON.stringify(_))}catch(e){}}</script>
+    
+      
+
+    
+    
+    
+  </head>
+  
+  
+    
+    
+      
+    
+    
+    
+    
+    <body dir="ltr" data-md-color-scheme="default" data-md-color-primary="green" data-md-color-accent="indigo">
+  
+    
+    <input class="md-toggle" data-md-toggle="drawer" type="checkbox" id="__drawer" autocomplete="off">
+    <input class="md-toggle" data-md-toggle="search" type="checkbox" id="__search" autocomplete="off">
+    <label class="md-overlay" for="__drawer"></label>
+    <div data-md-component="skip">
+      
+        
+        <a href="#aries-rfc-0745-push-notifications-expo-protocol-10" class="md-skip">
+          Skip to content
+        </a>
+      
+    </div>
+    <div data-md-component="announce">
+      
+    </div>
+    
+    
+      
+
+  
+
+<header class="md-header md-header--shadow md-header--lifted" data-md-component="header">
+  <nav class="md-header__inner md-grid" aria-label="Header">
+    <a href="../.." title="Hyperledger Aries Interoperability Profiles / RFCs" class="md-header__button md-logo" aria-label="Hyperledger Aries Interoperability Profiles / RFCs" data-md-component="logo">
+      
+  <img src="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/Hyperledger_Aries_Logo_White.png" alt="logo">
+
+    </a>
+    <label class="md-header__button md-icon" for="__drawer">
+      
+      <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M3 6h18v2H3zm0 5h18v2H3zm0 5h18v2H3z"/></svg>
+    </label>
+    <div class="md-header__title" data-md-component="header-title">
+      <div class="md-header__ellipsis">
+        <div class="md-header__topic">
+          <span class="md-ellipsis">
+            Hyperledger Aries Interoperability Profiles / RFCs
+          </span>
+        </div>
+        <div class="md-header__topic" data-md-component="header-topic">
+          <span class="md-ellipsis">
+            
+              0745 Push Notifications Expo Protocol 1.0
+            
+          </span>
+        </div>
+      </div>
+    </div>
+    
+      
+        <form class="md-header__option" data-md-component="palette">
+  
+    
+    
+    
+    <input class="md-option" data-md-color-media="" data-md-color-scheme="default" data-md-color-primary="green" data-md-color-accent="indigo"  aria-hidden="true"  type="radio" name="__palette" id="__palette_0">
+    
+  
+    
+    
+    
+    <input class="md-option" data-md-color-media="(prefers-color-scheme: light)" data-md-color-scheme="default" data-md-color-primary="indigo" data-md-color-accent="indigo"  aria-label="Switch to dark mode"  type="radio" name="__palette" id="__palette_1">
+    
+      <label class="md-header__button md-icon" title="Switch to dark mode" for="__palette_2" hidden>
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 8a4 4 0 0 0-4 4 4 4 0 0 0 4 4 4 4 0 0 0 4-4 4 4 0 0 0-4-4m0 10a6 6 0 0 1-6-6 6 6 0 0 1 6-6 6 6 0 0 1 6 6 6 6 0 0 1-6 6m8-9.31V4h-4.69L12 .69 8.69 4H4v4.69L.69 12 4 15.31V20h4.69L12 23.31 15.31 20H20v-4.69L23.31 12z"/></svg>
+      </label>
+    
+  
+    
+    
+    
+    <input class="md-option" data-md-color-media="(prefers-color-scheme: dark)" data-md-color-scheme="slate" data-md-color-primary="indigo" data-md-color-accent="indigo"  aria-label="Switch to light mode"  type="radio" name="__palette" id="__palette_2">
+    
+      <label class="md-header__button md-icon" title="Switch to light mode" for="__palette_0" hidden>
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 18c-.89 0-1.74-.2-2.5-.55C11.56 16.5 13 14.42 13 12s-1.44-4.5-3.5-5.45C10.26 6.2 11.11 6 12 6a6 6 0 0 1 6 6 6 6 0 0 1-6 6m8-9.31V4h-4.69L12 .69 8.69 4H4v4.69L.69 12 4 15.31V20h4.69L12 23.31 15.31 20H20v-4.69L23.31 12z"/></svg>
+      </label>
+    
+  
+</form>
+      
+    
+    
+      <script>var palette=__md_get("__palette");if(palette&&palette.color){if("(prefers-color-scheme)"===palette.color.media){var media=matchMedia("(prefers-color-scheme: light)"),input=document.querySelector(media.matches?"[data-md-color-media='(prefers-color-scheme: light)']":"[data-md-color-media='(prefers-color-scheme: dark)']");palette.color.media=input.getAttribute("data-md-color-media"),palette.color.scheme=input.getAttribute("data-md-color-scheme"),palette.color.primary=input.getAttribute("data-md-color-primary"),palette.color.accent=input.getAttribute("data-md-color-accent")}for(var[key,value]of Object.entries(palette.color))document.body.setAttribute("data-md-color-"+key,value)}</script>
+    
+    
+    
+      <label class="md-header__button md-icon" for="__search">
+        
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+      </label>
+      <div class="md-search" data-md-component="search" role="dialog">
+  <label class="md-search__overlay" for="__search"></label>
+  <div class="md-search__inner" role="search">
+    <form class="md-search__form" name="search">
+      <input type="text" class="md-search__input" name="query" aria-label="Search" placeholder="Search" autocapitalize="off" autocorrect="off" autocomplete="off" spellcheck="false" data-md-component="search-query" required>
+      <label class="md-search__icon md-icon" for="__search">
+        
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+        
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
+      </label>
+      <nav class="md-search__options" aria-label="Search">
+        
+        <button type="reset" class="md-search__icon md-icon" title="Clear" aria-label="Clear" tabindex="-1">
+          
+          <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M19 6.41 17.59 5 12 10.59 6.41 5 5 6.41 10.59 12 5 17.59 6.41 19 12 13.41 17.59 19 19 17.59 13.41 12z"/></svg>
+        </button>
+      </nav>
+      
+    </form>
+    <div class="md-search__output">
+      <div class="md-search__scrollwrap" tabindex="0" data-md-scrollfix>
+        <div class="md-search-result" data-md-component="search-result">
+          <div class="md-search-result__meta">
+            Initializing search
+          </div>
+          <ol class="md-search-result__list" role="presentation"></ol>
+        </div>
+      </div>
+    </div>
+  </div>
+</div>
+    
+    
+      <div class="md-header__source">
+        <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
+  <div class="md-source__icon md-icon">
+    
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+  </div>
+  <div class="md-source__repository">
+    hyperledger/aries-rfcs
+  </div>
+</a>
+      </div>
+    
+  </nav>
+  
+    
+      
+<nav class="md-tabs" aria-label="Tabs" data-md-component="tabs">
+  <div class="md-grid">
+    <ul class="md-tabs__list">
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../.." class="md-tabs__link">
+          
+  
+  Welcome
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../MAINTAINERS/" class="md-tabs__link">
+          
+  
+  Governance
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../aip2/0003-protocols/" class="md-tabs__link">
+          
+  
+  AIP 2.0
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../concepts/0003-protocols/" class="md-tabs__link">
+          
+  
+  ADOPTED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../concepts/0004-agents/" class="md-tabs__link">
+          
+  
+  ACCEPTED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../0032-message-timing/" class="md-tabs__link">
+          
+  
+  DEMONSTRATED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+    
+  
+  
+    
+    
+      <li class="md-tabs__item md-tabs__item--active">
+        <a href="../0028-introduce/" class="md-tabs__link">
+          
+  
+  PROPOSED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../0024-didcomm-over-xmpp/" class="md-tabs__link">
+          
+  
+  STALLED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../concepts/0013-overlays/" class="md-tabs__link">
+          
+  
+  RETIRED
+
+        </a>
+      </li>
+    
+  
+
+      
+    </ul>
+  </div>
+</nav>
+    
+  
+</header>
+    
+    <div class="md-container" data-md-component="container">
+      
+      
+        
+      
+      <main class="md-main" data-md-component="main">
+        <div class="md-main__inner md-grid">
+          
+            
+              
+              <div class="md-sidebar md-sidebar--primary" data-md-component="sidebar" data-md-type="navigation" >
+                <div class="md-sidebar__scrollwrap">
+                  <div class="md-sidebar__inner">
+                    
+
+
+  
+
+
+<nav class="md-nav md-nav--primary md-nav--lifted" aria-label="Navigation" data-md-level="0">
+  <label class="md-nav__title" for="__drawer">
+    <a href="../.." title="Hyperledger Aries Interoperability Profiles / RFCs" class="md-nav__button md-logo" aria-label="Hyperledger Aries Interoperability Profiles / RFCs" data-md-component="logo">
+      
+  <img src="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/Hyperledger_Aries_Logo_White.png" alt="logo">
+
+    </a>
+    Hyperledger Aries Interoperability Profiles / RFCs
+  </label>
+  
+    <div class="md-nav__source">
+      <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
+  <div class="md-source__icon md-icon">
+    
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+  </div>
+  <div class="md-source__repository">
+    hyperledger/aries-rfcs
+  </div>
+</a>
+    </div>
+  
+  <ul class="md-nav__list" data-md-scrollfix>
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_1" >
+        
+          
+          <label class="md-nav__link" for="__nav_1" id="__nav_1_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    Welcome
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_1_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_1">
+            <span class="md-nav__icon md-icon"></span>
+            Welcome
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../.." class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Welcome
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../RFCindex/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    All RFCs by Status
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0000-template/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    RFC Template
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0000-template-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Protocol RFC Template
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_2" >
+        
+          
+          <label class="md-nav__link" for="__nav_2" id="__nav_2_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    Governance
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_2_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_2">
+            <span class="md-nav__icon md-icon"></span>
+            Governance
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../MAINTAINERS/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Maintainers
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../contributing/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Contributing
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../github-issues/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Submitting Issues
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../LICENSE/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    License
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../SECURITY/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Security
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_3" >
+        
+          
+          <label class="md-nav__link" for="__nav_3" id="__nav_3_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    AIP 2.0
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_3_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_3">
+            <span class="md-nav__icon md-icon"></span>
+            AIP 2.0
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0003-protocols/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0003 Protocols
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0004-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0004 Agents
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0005-didcomm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0005 DID Communication
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0008-message-id-and-threading/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0008 Message ID and Threading
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0011-decorators/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0011 Decorators
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0015-acks/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0015 ACKs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0017-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0017 Attachments
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0019-encryption-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0019 Encryption Envelope
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0020-message-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0020 Message Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0023-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0023 DID Exchange Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0025-didcomm-transports/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0025 DIDComm Transports
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0035-report-problem/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0035 Report Problem Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0044-didcomm-file-and-mime-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0044 DIDComm File and MIME Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0046-mediators-and-relays/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0046 Mediators and Relays
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0047-json-ld-compatibility/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0047 JSON-LD Compatibility
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0048-trust-ping/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0048 Trust Ping Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0050-wallets/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0050 Wallets
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0092-transport-return-route/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0092 Transports Return Route
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0094-cross-domain-messaging/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0094 Cross-Domain Messaging
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0095-basic-message/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0095 Basic Message Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0183-revocation-notification/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0183 Revocation Notification 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0211-route-coordination/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0211 Mediator Coordination Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0360-use-did-key/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0360 did:key Usage
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0434-outofband/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0434 Out-of-Band Protocol 1.1
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0441-present-proof-best-practices/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0441 Prover and Verifier Best Practices for Proof Presentation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0453-issue-credential-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0453 Issue Credential Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0454-present-proof-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0454 Present Proof Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0510-dif-pres-exch-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0519-goal-codes/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0519 Goal Codes
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0557-discover-features-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0557 Discover Features Protocol v2.x
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0592-indy-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0593-json-ld-cred-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_4" >
+        
+          
+          <label class="md-nav__link" for="__nav_4" id="__nav_4_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    ADOPTED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_4_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_4">
+            <span class="md-nav__icon md-icon"></span>
+            ADOPTED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0003-protocols/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0003 Protocols
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0005-didcomm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0005 DID Communication
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0008-message-id-and-threading/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0008 Message ID and Threading
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0011-decorators/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0011 Decorators
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0015-acks/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0015 ACKs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0017-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0017 Attachments
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0019-encryption-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0019 Encryption Envelope
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0020-message-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0020 Message Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0021-didcomm-message-anatomy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0021 DIDComm Message Anatomy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0023-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0023 DID Exchange v1
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0025-didcomm-transports/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0025 DIDComm Transports
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0031-discover-features/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0031 Discover Features Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0035-report-problem/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0035 Report Problem Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0036-issue-credential/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0036 Issue Credential Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0037-present-proof/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0037 Present Proof Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0048-trust-ping/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0048 Trust Ping Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0092-transport-return-route/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0092 Transports Return Route
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0094-cross-domain-messaging/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0094 Cross-Domain Messaging
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0095-basic-message/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0095 Basic Message Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0160-connection-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0160 Connection Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0211-route-coordination/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0211 Mediator Coordination Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0302-aries-interop-profile/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0302 Aries Interop Profile
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0360-use-did-key/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0360 did:key Usage
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0434-outofband/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0434 Out-of-Band Protocol 1.1
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0441-present-proof-best-practices/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0441 Prover and Verifier Best Practices for Proof Presentation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0453-issue-credential-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0453 Issue Credential Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0454-present-proof-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0454 Present Proof Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0496-transition-to-oob-and-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0496 Transition to the Out of Band Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0510-dif-pres-exch-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0557-discover-features-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0557 Discover Features Protocol v2.x
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0592-indy-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0593-json-ld-cred-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_5" >
+        
+          
+          <label class="md-nav__link" for="__nav_5" id="__nav_5_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    ACCEPTED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_5_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_5">
+            <span class="md-nav__icon md-icon"></span>
+            ACCEPTED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0004-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0004 Agents
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0006-ssi-notation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0006 SSI Notation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0044-didcomm-file-and-mime-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0044 DIDComm File and MIME Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0046-mediators-and-relays/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0046 Mediators and Relays
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0047-json-ld-compatibility/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0047 JSON-LD Compatibility
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0049-repudiation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0049 Repudiation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0050-wallets/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0050 Wallets
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0183-revocation-notification/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0183 Revocation Notification 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0519-goal-codes/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0519 Goal Codes
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0587-encryption-envelope-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0587 Encryption Envelope v2
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0646-bbs-credentials/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0646 W3C Credential Exchange using BBS+ Signatures
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0685-pickup-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0685 Pickup Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0721-revocation-notification-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0721 Revocation Notification 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0793-unqualfied-dids-transition/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0793 Unqualified DID Transition
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0794-did-rotate/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0794 DID Rotate 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_6" >
+        
+          
+          <label class="md-nav__link" for="__nav_6" id="__nav_6_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    DEMONSTRATED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_6_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_6">
+            <span class="md-nav__icon md-icon"></span>
+            DEMONSTRATED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0032-message-timing/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0032 Message Timing
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0042-lox/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0042 LOX -- A more secure pluggable framework for protecting wallet keys
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0043-l10n/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0043 l10n (Locali[s|z]ation)
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0113-question-answer/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0113 Question Answer Protocol 0.9
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0509-action-menu/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0509 Action Menu Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0748-n-wise-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0748 N-wise DID Exchange Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0755-oca-for-aries/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0755 Overlays Capture Architecture (OCA) For Aries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0756-oca-for-aries-style-guide/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0756 OCA for Aries Style Guide
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0780-data-urls-images/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0780 Use Data URLs for Images and More in Credential Attributes
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0804-didcomm-rpc/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0804 DIDComm Remote Procedure Call (DRPC)
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0809-w3c-data-integrity-credential-attachment/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0809 W3C Verifiable Credential Data Integrity Attachment format for requesting and issuing credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+    
+  
+  
+  
+    
+    
+    
+      
+        
+        
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--active md-nav__item--section md-nav__item--nested">
+      
+        
+        
+        <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_7" checked>
+        
+          
+          <label class="md-nav__link" for="__nav_7" id="__nav_7_label" tabindex="">
+            
+  
+  <span class="md-ellipsis">
+    PROPOSED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_7_label" aria-expanded="true">
+          <label class="md-nav__title" for="__nav_7">
+            <span class="md-nav__icon md-icon"></span>
+            PROPOSED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0028-introduce/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0028 Introduce Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0034-message-tracing/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0034 Message Tracing
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0056-service-decorator/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0056 Service Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0066-non-repudiable-cryptographic-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0066 Non-Repudiable Signature for Cryptographic Envelope
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0067-didcomm-diddoc-conventions/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0067 DIDComm DID document conventions
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0074-didcomm-best-practices/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0074 DIDComm Best Practices
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0103-indirect-identity-control/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0103 Indirect Identity Control
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0104-chained-credentials/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0104 Chained Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0124-did-resolution-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0124 DID Resolution Protocol 0.9
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0167-data-consent-lifecycle/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0167 Data Consent Lifecycle
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0212-pickup/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0212 Pickup Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0213-transfer-policy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0213 Transfer Policy Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0214-help-me-discover/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0214 "Help Me Discover" Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0231-biometric-service-provider/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0231 Biometric Service Provider
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0268-unified-didcomm-agent-deeplinking/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0268 Unified DIDCOMM Deeplinking
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0270-interop-test-suite/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0270 Interop Test Suite
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0345-community-coordinated-update/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0345 Community Coordinated Update
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0346-didcomm-between-two-mobile-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0346 DIDComm Between Two Mobile Agents Using Cloud Agent Mediator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0347-proof-negotiation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0347 Proof Negotiation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0430-machine-readable-governance-frameworks/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0430 Machine-Readable Governance Frameworks
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0440-kms-architectures/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0440 KMS Architectures
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0511-dif-cred-manifest-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0511 Credential-Manifest Attachment format for requesting and presenting credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0530-goal-human-readable-verified-identifer/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0530 Goal - Human Readable Verifiable Identifier
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0559-pppu/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0559 Privacy-Preserving Proof of Uniqueness
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0566-issuer-hosted-custodidal-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0566 Issuer-Hosted Custodial Agents
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0641-linking-binary-objects-to-credentials/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0641 Linking binary objects to credentials using hash based references
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0693-credential-representation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0693 Cross-Platform Credential Representation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0699-push-notifications-apns/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0699 Push Notifications apns Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0700-oob-through-redirect/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0700 Out-of-Band through redirect
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0728-device-binding-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0728 Device Binding Attachments
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0734-push-notifications-fcm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0734 Push Notifications fcm Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+    
+  
+  
+  
+    <li class="md-nav__item md-nav__item--active">
+      
+      <input class="md-nav__toggle md-toggle" type="checkbox" id="__toc">
+      
+      
+        
+      
+      
+        <label class="md-nav__link md-nav__link--active" for="__toc">
+          
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+          <span class="md-nav__icon md-icon"></span>
+        </label>
+      
+      <a href="./" class="md-nav__link md-nav__link--active">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+      
+        
+
+<nav class="md-nav md-nav--secondary" aria-label="Table of contents">
+  
+  
+  
+    
+  
+  
+    <label class="md-nav__title" for="__toc">
+      <span class="md-nav__icon md-icon"></span>
+      Table of contents
+    </label>
+    <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
+      
+        <li class="md-nav__item">
+  <a href="#summary" class="md-nav__link">
+    <span class="md-ellipsis">
+      Summary
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#motivation" class="md-nav__link">
+    <span class="md-ellipsis">
+      Motivation
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#tutorial" class="md-nav__link">
+    <span class="md-ellipsis">
+      Tutorial
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Tutorial">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#name-and-version" class="md-nav__link">
+    <span class="md-ellipsis">
+      Name and Version
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#key-concepts" class="md-nav__link">
+    <span class="md-ellipsis">
+      Key Concepts
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#roles" class="md-nav__link">
+    <span class="md-ellipsis">
+      Roles
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#services" class="md-nav__link">
+    <span class="md-ellipsis">
+      Services
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#messages" class="md-nav__link">
+    <span class="md-ellipsis">
+      Messages
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#sending-push-notifications" class="md-nav__link">
+    <span class="md-ellipsis">
+      Sending Push Notifications
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#drawbacks" class="md-nav__link">
+    <span class="md-ellipsis">
+      Drawbacks
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#prior-art" class="md-nav__link">
+    <span class="md-ellipsis">
+      Prior art
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#unresolved-questions" class="md-nav__link">
+    <span class="md-ellipsis">
+      Unresolved questions
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#implementations" class="md-nav__link">
+    <span class="md-ellipsis">
+      Implementations
+    </span>
+  </a>
+  
+</li>
+      
+    </ul>
+  
+</nav>
+      
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0757-push-notification/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0757 Push Notification
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0771-anoncreds-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0771 AnonCreds Attachment Formats for Requesting and Presenting Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0799 Aries Long Term Support Releases
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_8" >
+        
+          
+          <label class="md-nav__link" for="__nav_8" id="__nav_8_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    STALLED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_8_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_8">
+            <span class="md-nav__icon md-icon"></span>
+            STALLED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0024-didcomm-over-xmpp/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0024 DIDComm over XMPP
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0029-message-trust-contexts/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0029 Message Trust Contexts
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0030-sync-connection/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0030 Sync Connection Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0075-payment-decorators/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0075 Payment Decorators
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0114-predefined-identities/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0114 Predefined Identities
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0116-evidence-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0116 Evidence Exchange Protocol 0.9
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0193-coin-flip/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0193 Coin Flip Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0207-credential-fraud-threat-model/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0207 Credential Fraud Threat Model
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0217-linkable-message-paths/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0217 Linkable Message Paths
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0249-rich-schema-contexts/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0249 Aries Rich Schema Contexts
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0250-rich-schemas/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0250 Rich Schema Objects
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0257-private-credential-issuance/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0257 Private Credential Issuance
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0281-rich-schemas/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0281 Aries Rich Schemas
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0289-toip-stack/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0289 The Trust Over IP Stack
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0309-didauthz/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0309 DIDAuthZ
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0327-crypto-service/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0327 Crypto service Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0334-jwe-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0334 JWE envelope 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0335-http-over-didcomm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0335 HTTP Over DIDComm
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0351-purpose-decorator/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0351 Purpose Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0418-rich-schema-encoding/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0418 Aries Rich Schema Encoding Objects
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0420-rich-schemas-common/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0420 Rich Schema Objects Common
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0428-prepare-issue-rich-credential/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0428 Prerequisites to Issue Rich Credential
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0429-prepare-req-rich-pres/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0429 Prerequisites to Request Rich Presentation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0445-rich-schema-mapping/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0445 Aries Rich Schema Mapping
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0446-rich-schema-cred-def/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0446 Aries Rich Schema Credential Definition
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0478-coprotocols/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0478 Coprotocols
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0482-coprotocol-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0482 Coprotocol Protocol 0.5
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_9" >
+        
+          
+          <label class="md-nav__link" for="__nav_9" id="__nav_9_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    RETIRED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_9_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_9">
+            <span class="md-nav__icon md-icon"></span>
+            RETIRED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0013-overlays/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0013 Overlays
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0051-dkms/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0051 Decentralized Key Management
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0234-signature-decorator/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0234 Signature Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0303-v01-credential-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0303 V0.1 Credential Exchange (Deprecated)
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0317-please-ack/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0317 Please ACK Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0348-transition-msg-type-to-https/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0348 Transition Message Type to HTTPs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0627-static-peer-dids/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0627 Static Peer DIDs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+  </ul>
+</nav>
+                  </div>
+                </div>
+              </div>
+            
+            
+              
+              <div class="md-sidebar md-sidebar--secondary" data-md-component="sidebar" data-md-type="toc" >
+                <div class="md-sidebar__scrollwrap">
+                  <div class="md-sidebar__inner">
+                    
+
+<nav class="md-nav md-nav--secondary" aria-label="Table of contents">
+  
+  
+  
+    
+  
+  
+    <label class="md-nav__title" for="__toc">
+      <span class="md-nav__icon md-icon"></span>
+      Table of contents
+    </label>
+    <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
+      
+        <li class="md-nav__item">
+  <a href="#summary" class="md-nav__link">
+    <span class="md-ellipsis">
+      Summary
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#motivation" class="md-nav__link">
+    <span class="md-ellipsis">
+      Motivation
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#tutorial" class="md-nav__link">
+    <span class="md-ellipsis">
+      Tutorial
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Tutorial">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#name-and-version" class="md-nav__link">
+    <span class="md-ellipsis">
+      Name and Version
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#key-concepts" class="md-nav__link">
+    <span class="md-ellipsis">
+      Key Concepts
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#roles" class="md-nav__link">
+    <span class="md-ellipsis">
+      Roles
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#services" class="md-nav__link">
+    <span class="md-ellipsis">
+      Services
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#messages" class="md-nav__link">
+    <span class="md-ellipsis">
+      Messages
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#sending-push-notifications" class="md-nav__link">
+    <span class="md-ellipsis">
+      Sending Push Notifications
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#drawbacks" class="md-nav__link">
+    <span class="md-ellipsis">
+      Drawbacks
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#prior-art" class="md-nav__link">
+    <span class="md-ellipsis">
+      Prior art
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#unresolved-questions" class="md-nav__link">
+    <span class="md-ellipsis">
+      Unresolved questions
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#implementations" class="md-nav__link">
+    <span class="md-ellipsis">
+      Implementations
+    </span>
+  </a>
+  
+</li>
+      
+    </ul>
+  
+</nav>
+                  </div>
+                </div>
+              </div>
+            
+          
+          
+            <div class="md-content" data-md-component="content">
+              <article class="md-content__inner md-typeset">
+                
+                  
+
+  
+  
+
+
+<h1 id="aries-rfc-0745-push-notifications-expo-protocol-10">Aries RFC 0745: Push Notifications Expo Protocol 1.0<a class="headerlink" href="#aries-rfc-0745-push-notifications-expo-protocol-10" title="Permanent link">&para;</a></h1>
+<ul>
+<li>Authors: <a href="mailto:timo@animo.id">Timo Glastra</a> (Animo Solutions) &amp; <a href="mailto:berend@animo.id">Berend Sliedrecht</a> (Animo Solutions)</li>
+<li>Status: <a href="../../#proposed">PROPOSED</a></li>
+<li>Since: 2022-07-26</li>
+<li>Status Note: Initial version</li>
+<li>Start Date: 2022-07-15</li>
+<li>Tags: <a href="../../tags/#feature">feature</a>, <a href="../../tags/#protocol">protocol</a></li>
+</ul>
+<blockquote>
+<p>Note: This protocol is currently written to support sending push notifications through <a href="https://docs.expo.dev/push-notifications/overview/">Expo's push notification service</a>. For sending push notification directly using APNS or FCM see the respective RFCs; <a href="../0734-push-notifications-fcm/">0734: Push Notifications fcm</a> and <a href="../0699-push-notifications-apns/">0699: Push Notifications apns</a>.</p>
+</blockquote>
+<h2 id="summary">Summary<a class="headerlink" href="#summary" title="Permanent link">&para;</a></h2>
+<p><a href="https://expo.dev">Expo</a> provides tools and services on top of <a href="https://reactnative.dev/">React Native</a>. This RFC defines a protocol to coordinate expo push notification configuration between two agents, allowing the <strong>notification-sender</strong> to send push notifications through Expo's push notification service to the <strong>notification-receiver</strong>.</p>
+<h2 id="motivation">Motivation<a class="headerlink" href="#motivation" title="Permanent link">&para;</a></h2>
+<p>When mobile edge agents are offline and messages are received at the mediator, it is desired that the mediator can inform the mobile agent of pending messages. A protocol to set the push notification device info at another agent allows the mediator to send updates to the mobile agent.</p>
+<h2 id="tutorial">Tutorial<a class="headerlink" href="#tutorial" title="Permanent link">&para;</a></h2>
+<h3 id="name-and-version">Name and Version<a class="headerlink" href="#name-and-version" title="Permanent link">&para;</a></h3>
+<p>URI: <code>https://didcomm.org/push-notifications-expo/1.0</code></p>
+<p>Protocol Identifier: <code>push-notifications-expo</code></p>
+<p>Version: <code>1.0</code></p>
+<h3 id="key-concepts">Key Concepts<a class="headerlink" href="#key-concepts" title="Permanent link">&para;</a></h3>
+<p>When an agent would like to receive push notifications of pending messages, e.g. when a forward message is received at the mediator, the <strong>notification-receiver</strong> can register for push notifications at the <strong>notification-sender</strong> using the <code>set-device-info</code> message.</p>
+<p>This protocol only defines how an agent would get the token which is necessary for push notifications.</p>
+<p>Each platform is has its own protocol so that we can easily use <a href="https://github.com/hyperledger/aries-rfcs/blob/main../../features/0031-discover-features/README.md">0031: Discover Features 1.0</a> and <a href="https://github.com/hyperledger/aries-rfcs/blob/main../../features/0557-discover-features-v2/README.md">0557: Discover Features 2.X</a> to see which specific services are supported by the other agent.</p>
+<h3 id="roles">Roles<a class="headerlink" href="#roles" title="Permanent link">&para;</a></h3>
+<p><strong>notification-sender</strong></p>
+<p><strong>notification-receiver</strong></p>
+<p>The <strong>notification-sender</strong> is an agent who will send the <strong>notification-receiver</strong> notifications. The <strong>notification-receiver</strong> can get and set their push notification configuration at the <strong>notification-sender</strong>.</p>
+<h3 id="services">Services<a class="headerlink" href="#services" title="Permanent link">&para;</a></h3>
+<p>This RFC focusses on configuring the data necessary for pushing notifications to iOS and Android, via <a href="https://docs.expo.dev/push-notifications/sending-notifications/">Expo's Push API</a></p>
+<h3 id="messages">Messages<a class="headerlink" href="#messages" title="Permanent link">&para;</a></h3>
+<p>When a notification-receiver wants to receive push notifications from the notification-sender, the notification-receiver has to send the following message:</p>
+<h4 id="set-device-info">Set Device Info<a class="headerlink" href="#set-device-info" title="Permanent link">&para;</a></h4>
+<p>Message to set the device info using the <a href="https://docs.expo.dev/versions/latest/sdk/notifications/#getexpopushtokenasyncoptions-expotokenoptions-expopushtoken">Expo Push Token</a> for push notifications.</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a><span class="p">{</span>
+<a id="__codelineno-0-2" name="__codelineno-0-2" href="#__codelineno-0-2"></a><span class="w">  </span><span class="nt">&quot;@type&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;https://didcomm.org/push-notifications-expo/1.0/set-device-info&quot;</span><span class="p">,</span>
+<a id="__codelineno-0-3" name="__codelineno-0-3" href="#__codelineno-0-3"></a><span class="w">  </span><span class="nt">&quot;@id&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;&lt;UUID&gt;&quot;</span><span class="p">,</span>
+<a id="__codelineno-0-4" name="__codelineno-0-4" href="#__codelineno-0-4"></a><span class="w">  </span><span class="nt">&quot;device_token&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;&lt;DEVICE_TOKEN&gt;&quot;</span>
+<a id="__codelineno-0-5" name="__codelineno-0-5" href="#__codelineno-0-5"></a><span class="p">}</span>
+</code></pre></div>
+<p>Description of the fields:</p>
+<ul>
+<li><code>device_token</code> -- The token that is required by the notification provider. Usually has the format of <code>ExponentPushToken[xxxxxxxxxxxxxxxxxxxxxx]</code> (string, null)</li>
+</ul>
+<p>It is important to note that the set device info message can be used to set, update and remove the device info. To set, and update, these values the normal messages as stated above can be used. To remove yourself from receiving push notifications, you can send the same message where the <code>device_token</code> value is <code>null</code>.</p>
+<h4 id="get-device-info">Get Device Info<a class="headerlink" href="#get-device-info" title="Permanent link">&para;</a></h4>
+<p>When a notification-receiver wants to get their push-notification configuration, they can send the following message:</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a><span class="p">{</span>
+<a id="__codelineno-1-2" name="__codelineno-1-2" href="#__codelineno-1-2"></a><span class="w">  </span><span class="nt">&quot;@type&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;https://didcomm.org/push-notifications-expo/1.0/get-device-info&quot;</span><span class="p">,</span>
+<a id="__codelineno-1-3" name="__codelineno-1-3" href="#__codelineno-1-3"></a><span class="w">  </span><span class="nt">&quot;@id&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;&lt;UUID&gt;&quot;</span>
+<a id="__codelineno-1-4" name="__codelineno-1-4" href="#__codelineno-1-4"></a><span class="p">}</span>
+</code></pre></div>
+<h4 id="device-info">Device Info<a class="headerlink" href="#device-info" title="Permanent link">&para;</a></h4>
+<p>Response to the get device info:</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-2-1" name="__codelineno-2-1" href="#__codelineno-2-1"></a><span class="p">{</span>
+<a id="__codelineno-2-2" name="__codelineno-2-2" href="#__codelineno-2-2"></a><span class="w">  </span><span class="nt">&quot;@type&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;https://didcomm.org/push-notifications-expo/1.0/device-info&quot;</span><span class="p">,</span>
+<a id="__codelineno-2-3" name="__codelineno-2-3" href="#__codelineno-2-3"></a><span class="w">  </span><span class="nt">&quot;device_token&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;&lt;DEVICE_TOKEN&gt;&quot;</span><span class="p">,</span>
+<a id="__codelineno-2-4" name="__codelineno-2-4" href="#__codelineno-2-4"></a><span class="w">  </span><span class="nt">&quot;~thread&quot;</span><span class="p">:</span><span class="w"> </span><span class="p">{</span>
+<a id="__codelineno-2-5" name="__codelineno-2-5" href="#__codelineno-2-5"></a><span class="w">    </span><span class="nt">&quot;thid&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;&lt;GET_DEVICE_INFO_UUID&gt;&quot;</span>
+<a id="__codelineno-2-6" name="__codelineno-2-6" href="#__codelineno-2-6"></a><span class="w">  </span><span class="p">}</span>
+<a id="__codelineno-2-7" name="__codelineno-2-7" href="#__codelineno-2-7"></a><span class="p">}</span>
+</code></pre></div>
+<p>This message can be used by the notification-receiver to receive their device info, e.g. <code>device_token</code>. If the notification-sender does not have this field for that connection, a <code>problem-report</code> MAY be used as a response with <code>not-registered-for-push-notifications</code>.</p>
+<h4 id="adopted-messages">Adopted messages<a class="headerlink" href="#adopted-messages" title="Permanent link">&para;</a></h4>
+<p>In addition, the <a href="https://github.com/hyperledger/aries-rfcs/blob/08653f21a489bf4717b54e4d7fd2d0bdfe6b4d1a../../features/0015-acks/README.md"><code>ack</code></a> message is adopted into the protocol for confirmation by the notification-sender. The ack message MUST be sent in response to any of the set-device-info messages.</p>
+<h3 id="sending-push-notifications">Sending Push Notifications<a class="headerlink" href="#sending-push-notifications" title="Permanent link">&para;</a></h3>
+<p>When an agent wants to send a push notification to another agent, the payload of the push notifications MUST include the <code>@type</code> property, and COULD include the <code>message_tag</code> property, to indicate the message is sent by the notification-sender. Guidelines on notification messages are not defined.</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-3-1" name="__codelineno-3-1" href="#__codelineno-3-1"></a><span class="p">{</span>
+<a id="__codelineno-3-2" name="__codelineno-3-2" href="#__codelineno-3-2"></a><span class="w">  </span><span class="nt">&quot;@type&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;https://didcomm.org/push-notifications-expo&quot;</span><span class="p">,</span>
+<a id="__codelineno-3-3" name="__codelineno-3-3" href="#__codelineno-3-3"></a><span class="w">  </span><span class="nt">&quot;message_tag&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;&lt;MESSAGE_TAG&gt;&quot;</span><span class="p">,</span>
+<a id="__codelineno-3-4" name="__codelineno-3-4" href="#__codelineno-3-4"></a><span class="w">  </span><span class="nt">&quot;message_id&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;&lt;MESSAGE_ID&gt;&quot;</span><span class="p">,</span>
+<a id="__codelineno-3-5" name="__codelineno-3-5" href="#__codelineno-3-5"></a><span class="w">  </span><span class="err">...</span>
+<a id="__codelineno-3-6" name="__codelineno-3-6" href="#__codelineno-3-6"></a><span class="p">}</span>
+</code></pre></div>
+<p>Description of the fields:</p>
+<ul>
+<li><code>@type</code> -- Indicator of what kind of notification it is. (This could help the notification-receiver with parsing if a notification comes from another agent, for example)</li>
+<li><code>message_tag</code> -- Optional field to connect the push notification to a DIDcomm message. As defined in <a href="https://github.com/hyperledger/aries-rfcs/tree/main../../features/0334-jwe-envelope">0334: jwe-envelope</a> or <a href="https://github.com/hyperledger/aries-rfcs/tree/main../../features/0019-encryption-envelope">0019: encryption-envelope</a>.</li>
+<li><code>message_id</code> -- Optional field to pickup the message from the mediator that the notification was linked to. As defined in <a href="https://github.com/hyperledger/aries-rfcs/blob/main../../features/0685-pickup-v2/README.md">0685: Pickup Protocol 2.0</a>.</li>
+</ul>
+<h2 id="drawbacks">Drawbacks<a class="headerlink" href="#drawbacks" title="Permanent link">&para;</a></h2>
+<p>Each service requires a considerable amount of domain knowledge. The RFC can be extended with new services over time.</p>
+<p>The <code>@type</code> property in the push notification payload currently doesn't indicate which agent the push notification came from. In e.g. the instance of using multiple mediators, this means the notification-receiver does not know which mediator to retrieve the message from.</p>
+<h2 id="prior-art">Prior art<a class="headerlink" href="#prior-art" title="Permanent link">&para;</a></h2>
+<ul>
+<li>This RFC is based on the implementation of the <a href="https://github.com/hyperledger/aries-framework-dotnet/blob/9bc6346a21da263083bbac8dd8227cc941c95ea9/src/Hyperledger.Aries.Routing/AddDeviceInfoMessage.cs"><code>AddDeviceInfoMessage</code></a> in Aries Framework .NET</li>
+</ul>
+<h2 id="unresolved-questions">Unresolved questions<a class="headerlink" href="#unresolved-questions" title="Permanent link">&para;</a></h2>
+<p>None</p>
+<h2 id="implementations">Implementations<a class="headerlink" href="#implementations" title="Permanent link">&para;</a></h2>
+<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the "Name" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p>
+<table>
+<thead>
+<tr>
+<th>Name / Link</th>
+<th>Implementation Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td></td>
+<td></td>
+</tr>
+</tbody>
+</table>
+
+
+
+
+
+
+
+
+
+
+
+
+                
+              </article>
+            </div>
+          
+          
+<script>var target=document.getElementById(location.hash.slice(1));target&&target.name&&(target.checked=target.name.startsWith("__tabbed_"))</script>
+        </div>
+        
+          <button type="button" class="md-top md-icon" data-md-component="top" hidden>
+  
+  <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M13 20h-2V8l-5.5 5.5-1.42-1.42L12 4.16l7.92 7.92-1.42 1.42L13 8z"/></svg>
+  Back to top
+</button>
+        
+      </main>
+      
+        <footer class="md-footer">
+  
+    
+      
+      <nav class="md-footer__inner md-grid" aria-label="Footer" >
+        
+          
+          <a href="../0734-push-notifications-fcm/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0734 Push Notifications fcm Protocol 1.0">
+            <div class="md-footer__button md-icon">
+              
+              <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
+            </div>
+            <div class="md-footer__title">
+              <span class="md-footer__direction">
+                Previous
+              </span>
+              <div class="md-ellipsis">
+                0734 Push Notifications fcm Protocol 1.0
+              </div>
+            </div>
+          </a>
+        
+        
+          
+          <a href="../../concepts/0757-push-notification/" class="md-footer__link md-footer__link--next" aria-label="Next: 0757 Push Notification">
+            <div class="md-footer__title">
+              <span class="md-footer__direction">
+                Next
+              </span>
+              <div class="md-ellipsis">
+                0757 Push Notification
+              </div>
+            </div>
+            <div class="md-footer__button md-icon">
+              
+              <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M4 11v2h12l-5.5 5.5 1.42 1.42L19.84 12l-7.92-7.92L10.5 5.5 16 11z"/></svg>
+            </div>
+          </a>
+        
+      </nav>
+    
+  
+  <div class="md-footer-meta md-typeset">
+    <div class="md-footer-meta__inner md-grid">
+      <div class="md-copyright">
+  
+  
+    Made with
+    <a href="https://squidfunk.github.io/mkdocs-material/" target="_blank" rel="noopener">
+      Material for MkDocs
+    </a>
+  
+</div>
+      
+    </div>
+  </div>
+</footer>
+      
+    </div>
+    <div class="md-dialog" data-md-component="dialog">
+      <div class="md-dialog__inner md-typeset"></div>
+    </div>
+    
+    
+    <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
+    
+    
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
+      
+    
+  </body>
+</html>
\ No newline at end of file
diff --git a/main/features/0748-n-wise-did-exchange/index.html b/main/features/0748-n-wise-did-exchange/index.html
index 5443b7fa8..fbfaab8b9 100644
--- a/main/features/0748-n-wise-did-exchange/index.html
+++ b/main/features/0748-n-wise-did-exchange/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3584,6 +3584,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3752,6 +3773,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3794,6 +3836,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3809,6 +3872,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5326,7 +5431,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0755-oca-for-aries/index.html b/main/features/0755-oca-for-aries/index.html
index b61647cea..9f97bd5bd 100644
--- a/main/features/0755-oca-for-aries/index.html
+++ b/main/features/0755-oca-for-aries/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3470,6 +3470,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3638,6 +3659,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3680,6 +3722,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3695,6 +3758,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5390,7 +5495,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image 4_1.png b/main/features/0756-oca-for-aries-style-guide/images/image 4_1.png
new file mode 100644
index 000000000..f97f9cc00
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image 4_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image10_1.png b/main/features/0756-oca-for-aries-style-guide/images/image10_1.png
new file mode 100644
index 000000000..a884b90d5
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image10_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image11.png b/main/features/0756-oca-for-aries-style-guide/images/image11.png
index ddcbbae39..ec2bac930 100644
Binary files a/main/features/0756-oca-for-aries-style-guide/images/image11.png and b/main/features/0756-oca-for-aries-style-guide/images/image11.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image11_1.png b/main/features/0756-oca-for-aries-style-guide/images/image11_1.png
new file mode 100644
index 000000000..2b889ca53
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image11_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image12_1.png b/main/features/0756-oca-for-aries-style-guide/images/image12_1.png
new file mode 100644
index 000000000..e24f10c7d
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image12_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image13_1.png b/main/features/0756-oca-for-aries-style-guide/images/image13_1.png
new file mode 100644
index 000000000..283645835
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image13_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image14_1.png b/main/features/0756-oca-for-aries-style-guide/images/image14_1.png
new file mode 100644
index 000000000..e20283d6f
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image14_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image15_1.png b/main/features/0756-oca-for-aries-style-guide/images/image15_1.png
new file mode 100644
index 000000000..2c46d826f
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image15_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image16_1.png b/main/features/0756-oca-for-aries-style-guide/images/image16_1.png
new file mode 100644
index 000000000..84e82ab12
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image16_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image17_1.png b/main/features/0756-oca-for-aries-style-guide/images/image17_1.png
new file mode 100644
index 000000000..b8ecf203a
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image17_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image18_1.png b/main/features/0756-oca-for-aries-style-guide/images/image18_1.png
new file mode 100644
index 000000000..32ddc2647
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image18_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image19_1.png b/main/features/0756-oca-for-aries-style-guide/images/image19_1.png
new file mode 100644
index 000000000..ff29055fc
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image19_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image1_1.png b/main/features/0756-oca-for-aries-style-guide/images/image1_1.png
new file mode 100644
index 000000000..1e13458ff
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image1_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image20_1.png b/main/features/0756-oca-for-aries-style-guide/images/image20_1.png
new file mode 100644
index 000000000..85707b047
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image20_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image2_1.png b/main/features/0756-oca-for-aries-style-guide/images/image2_1.png
new file mode 100644
index 000000000..9e876d6c1
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image2_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image3_1.png b/main/features/0756-oca-for-aries-style-guide/images/image3_1.png
new file mode 100644
index 000000000..31aedc182
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image3_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image5_1.png b/main/features/0756-oca-for-aries-style-guide/images/image5_1.png
new file mode 100644
index 000000000..2ceb3962d
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image5_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image6_1.png b/main/features/0756-oca-for-aries-style-guide/images/image6_1.png
new file mode 100644
index 000000000..11de4a743
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image6_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image7_1.png b/main/features/0756-oca-for-aries-style-guide/images/image7_1.png
new file mode 100644
index 000000000..fafdfd821
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image7_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image8_1.png b/main/features/0756-oca-for-aries-style-guide/images/image8_1.png
new file mode 100644
index 000000000..8e3db3d40
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image8_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/images/image9_1.png b/main/features/0756-oca-for-aries-style-guide/images/image9_1.png
new file mode 100644
index 000000000..3edbec93d
Binary files /dev/null and b/main/features/0756-oca-for-aries-style-guide/images/image9_1.png differ
diff --git a/main/features/0756-oca-for-aries-style-guide/index.html b/main/features/0756-oca-for-aries-style-guide/index.html
index 38448a423..bab329d05 100644
--- a/main/features/0756-oca-for-aries-style-guide/index.html
+++ b/main/features/0756-oca-for-aries-style-guide/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3551,6 +3551,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3719,6 +3740,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3761,6 +3803,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3776,6 +3839,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4838,7 +4943,7 @@ <h1 id="0756-oca-for-aries-style-guide">0756: OCA for Aries Style Guide<a class=
 <li>Status Note: Implemented in the <a href="https://github.com/openwallet-foundation/bifold-wallet">Bifold Wallet</a></li>
 <li>Supersedes: N/A</li>
 <li>Start Date: 2022-11-15</li>
-<li>Version: 1.0</li>
+<li>Versions: 1.0 and 1.1</li>
 <li>Tags: <a href="../../tags/#feature">feature</a></li>
 </ul>
 <h2 id="summary">Summary<a class="headerlink" href="#summary" title="Permanent link">&para;</a></h2>
@@ -4851,6 +4956,7 @@ <h2 id="summary">Summary<a class="headerlink" href="#summary" title="Permanent l
 also for Aries holder and verifier software makers about how to use the OCA data
 provided from issuers for a given credential type. It is up to the software
 makers to use OCA data provided by the issuers as outlined in this guide.</p>
+<p>There are 2 versions of the OCA that can be used. Version 1.1 does not remove version 1.0, but rather propose a different view for credential layout. It is to the wallet maintainer to chose which one would be used in their application.</p>
 <p>For more information about the use of OCA in Aries, please see <a href="../0755-oca-for-aries/">RFC0755 OCA for
 Aries</a></p>
 <h2 id="motivation">Motivation<a class="headerlink" href="#motivation" title="Permanent link">&para;</a></h2>
@@ -4950,6 +5056,7 @@ <h2 id="oca-for-aries-style-guide">OCA for Aries Style Guide<a class="headerlink
 <h3 id="credential-layouts">Credential Layouts<a class="headerlink" href="#credential-layouts" title="Permanent link">&para;</a></h3>
 <p>This style guide defines three layouts for credentials, the credential list layout, the stacked list layout, and the single credential layout. Holders and verifiers SHOULD display credentials using only these layouts in the context of a screen containing either a list of credentials or a single credential, respectively. Holders and verifiers MAY display other relevant information on the page along with one of the layouts.</p>
 <p>The stacked list is the same as the credential layout, with the credentials that are stacked cutoff between elements 6 and 7. Examples of the stacked layout can be seen in the <a href="#heading=h.27voxgccn7kf">Stacking</a> section of this document. In the Stacked layout, one of the credentials in the stack may be displayed using the full credential list layout.</p>
+<p><strong>Version 1.0</strong></p>
 <table>
   <tr>
    <td>
@@ -4969,6 +5076,26 @@ <h3 id="credential-layouts">Credential Layouts<a class="headerlink" href="#crede
   </tr>
 </table>
 
+<p><strong>Version 1.1</strong></p>
+<table>
+  <tr>
+   <td>
+<img src="./images/image1_1.png" width="" alt="alt_text" title="image_tooltip">
+
+   </td>
+   <td>
+<img src="./images/image2_1.png" width="" alt="alt_text" title="image_tooltip">
+
+   </td>
+  </tr>
+  <tr>
+   <td><strong>Credential List Layout</strong>
+   </td>
+   <td><strong>Single Credential Layout</strong>
+   </td>
+  </tr>
+</table>
+
 <p><strong><em>Figure: Credential Layouts</em></strong></p>
 <p>The numbered items in the layouts are as follows. In the list, the OCA data element(s) is provided first, and, where the needed data element(s) is not available through an OCA Bundle, a calculation for a fallback is defined. It is good practice to have code that populates a per credential data structure with data from the credential’s OCA Bundle if available, and if not, populated by the fallbacks. That way, the credentials are displayed in the same way with or without an OCA Bundle per credential. Unless noted, all of the data elements come from the “branding” overlay. Items 10 and 11 are not included in the layouts but are included to document the fallbacks for those values.</p>
 <ol>
@@ -5017,9 +5144,20 @@ <h3 id="credential-layouts">Credential Layouts<a class="headerlink" href="#crede
 </ul>
 </li>
 </ol>
+<p><strong>added with version 1.1</strong></p>
+<ol>
+<li><code>Contact detail button</code><ul>
+<li>Fallback: Empty</li>
+</ul>
+</li>
+</ol>
+<p><strong>Version 1.0</strong></p>
 <p><img alt="alt_text" src="images/image3.png" title="image_tooltip" /></p>
+<p><strong>Version 1.1</strong>
+<img alt="alt_text" src="images/image3_1.png" title="image_tooltip" /></p>
 <p><strong><em>Figure: Template layers</em></strong></p>
 <p>The font color is either black or white, as determined by calculating contrast levels (following <a href="https://www.w3.org/WAI/WCAG2AA-Conformance">Web Content Accessibility Guidelines</a>) against the background colors from either the OCA Bundle or the generated defaults.</p>
+<p><strong>Version 1.0</strong></p>
 <table>
   <tr>
    <td>
@@ -5033,9 +5171,25 @@ <h3 id="credential-layouts">Credential Layouts<a class="headerlink" href="#crede
   </tr>
 </table>
 
+<p><strong>Version 1.1</strong></p>
+<table>
+  <tr>
+   <td>
+<img src="./images/image 4_1.png" width="" alt="alt_text" title="image_tooltip">
+
+   </td>
+   <td>
+<img src="./images/image5_1.png" width="" alt="alt_text" title="image_tooltip">
+
+   </td>
+  </tr>
+</table>
+
 <p><strong><em>Figure: example of a credential with no override specifications</em></strong></p>
 <h3 id="logo-image-specifications">Logo Image Specifications<a class="headerlink" href="#logo-image-specifications" title="Permanent link">&para;</a></h3>
-<p>The image in the top left corner is a space for the issuer logo. This space should not be used for anything other than the issuer logo. The logo image may be masked to fit within a rounded square with varying corner radii. Thus, the logo must be a square image (aspect ratio 1:1), as noted in the table below. The background is default white, therefore logo files with a transparent background will overlay a white background.</p>
+<p>This space should not be used for anything other than the issuer logo. The logo image may be masked to fit within a rounded square with varying corner radii. Thus, the logo must be a square image (aspect ratio 1:1), as noted in the table below. The background is default white, therefore logo files with a transparent background will overlay a white background.</p>
+<p>For version 1.0, the issuer logo is located at the top left of the credential.</p>
+<p>With version 1.1, the issuer logo is located on the bottom of the credential, left of the issuer's name.</p>
 <p>The following are the specifications for the credential logo for issuers. </p>
 <p>Images should be as small as possible to balance quality and download speed. To ensure image quality on all devices, it is recommended to use vector based file types such as SVG. </p>
 <table>
@@ -5068,9 +5222,13 @@ <h3 id="logo-image-specifications">Logo Image Specifications<a class="headerlink
 <h3 id="background-image-slice-specifications">Background Image Slice Specifications<a class="headerlink" href="#background-image-slice-specifications" title="Permanent link">&para;</a></h3>
 <p>For issuers to better represent their brand, issuers may specify an image slice that will be used as outlined in the samples below. Note the use of the image in a long, narrow space and the dynamic height. The image slice will be top aligned, scaled (preserving aspect ratio) and cropped as needed to fill the space.</p>
 <p>Credential height is dependent on the content and can be unpredictable. Different languages (English, French, etc.) will add more length to names, OS level settings such as font changes or text enlargement will unpredictably change the height of the credential. The recommended image size below is suggested to accommodate for most situations. Note that since the image is top aligned, the top area of the image is certain to be displayed, while the bottom section of the image may not always be visible. </p>
+<p><strong>Version 1.0</strong></p>
 <p><img alt="alt_text" src="images/image6.jpg" title="image_tooltip" /></p>
+<p><strong>Version 1.1</strong></p>
+<p><img alt="alt_text" src="images/image6_1.png" title="image_tooltip" /></p>
 <p><strong><em>Figure: Examples of the image slice behavior</em></strong></p>
 <p>Types of images best used in this area are abstract images or graphical art. Do not use images that are difficult to interpret when cropped.</p>
+<p><strong>Version 1.0</strong></p>
 <table>
   <tr>
    <td>
@@ -5094,6 +5252,30 @@ <h3 id="background-image-slice-specifications">Background Image Slice Specificat
   </tr>
 </table>
 
+<p><strong>Version 1.1</strong></p>
+<table>
+  <tr>
+   <td>
+<img src="./images/image7_1.png" width="" alt="alt_text" title="image_tooltip">
+
+   </td>
+   <td>
+<img src="./images/image8_1.png" width="" alt="alt_text" title="image_tooltip">
+
+   </td>
+  </tr>
+  <tr>
+   <td><strong>Do</strong>
+<p>
+Use an abstract image that can work even when cropped unexpectedly. 
+   </td>
+   <td><strong>Don’t</strong>
+<p>
+Use images that are hard to interpret when cropped. Avoid words
+   </td>
+  </tr>
+</table>
+
 <p><strong><em>Figure: Background image slice Do’s and Don’ts</em></strong></p>
 <table>
   <tr>
@@ -5124,6 +5306,7 @@ <h3 id="background-image-slice-specifications">Background Image Slice Specificat
 
 <h3 id="background-image-specifications">Background Image Specifications<a class="headerlink" href="#background-image-specifications" title="Permanent link">&para;</a></h3>
 <p>The background image is to give issuers more opportunities to represent their brand and is used in some credential display screens. Avoid text in the background image.</p>
+<p><strong>Version 1.0</strong></p>
 <table>
   <tr>
    <td>
@@ -5147,6 +5330,30 @@ <h3 id="background-image-specifications">Background Image Specifications<a class
   </tr>
 </table>
 
+<p><strong>Version 1.1</strong></p>
+<table>
+  <tr>
+   <td>
+<img src="./images/image9_1.png" width="" alt="alt_text" title="image_tooltip">
+
+   </td>
+   <td>
+<img src="./images/image10_1.png" width="" alt="alt_text" title="image_tooltip">
+
+   </td>
+  </tr>
+  <tr>
+   <td><strong>Do</strong>
+<p>
+Use an image that represents your brand.
+   </td>
+   <td><strong>Don’t</strong>
+<p>
+Use this image as a marketing platform. Avoid the use of text.
+   </td>
+  </tr>
+</table>
+
 <p><strong><em>Figure: Background image Do’s and Don’ts</em></strong></p>
 <table>
   <tr>
@@ -5182,20 +5389,30 @@ <h3 id="credential-status">Credential Status<a class="headerlink" href="#credent
 <li>A credential is revoked, if the credential is revocable and is known to have been revoked.</li>
 <li>A credential is expiring soon or expired, based on <em>expiry_date_attribute</em>, if set.</li>
 </ul>
+<p><strong>Version 1.0</strong></p>
 <p><img alt="alt_text" src="images/image11.png" title="image_tooltip" /></p>
+<p><strong>Version 1.1</strong></p>
+<p><img alt="alt_text" src="images/image11_1.png" title="image_tooltip" /></p>
 <p><strong><em>Figure: An example demonstrating how the revocation date, expiry date or issued date may be represented.</em></strong></p>
 <p>The interpretation of the issued date, expiry date and revocation status may be dependent on the holder software, such as a wallet. For example, the specific icons used may vary by wallet, or the full status data may be printed over the credential.</p>
 <h3 id="credential-name-and-issuer-name-guidelines">Credential name and Issuer name guidelines<a class="headerlink" href="#credential-name-and-issuer-name-guidelines" title="Permanent link">&para;</a></h3>
 <p>Issuers should be mindful of the length of text on the credential as lengthy text will dynamically change the height of the credential. Expansive credentials risk reducing the number of fully visible credentials in a list.</p>
+<p><strong>Version 1.0</strong>    </p>
 <p><img alt="alt_text" src="images/image12.png" title="image_tooltip" /></p>
+<p><strong>Version 1.1</strong>   </p>
+<p><img alt="alt_text" src="images/image12_1.png" title="image_tooltip" /></p>
 <p><strong><em>Figure: An example demonstrating how lengthy credentials can limit the number of visible credentials.</em></strong></p>
 <p>Be mindful of other factors that may increase the length of text and hence, the height of the credential such as translated languages or the font size configured at the OS level.</p>
+<p><strong>Version 1.0</strong></p>
 <p><img alt="alt_text" src="images/image13.png" title="image_tooltip" /></p>
+<p><strong>Version 1.1</strong></p>
+<p><img alt="alt_text" src="images/image13_1.png" title="image_tooltip" /></p>
 <p><strong><em>Figure: Examples showing the treatment of lengthy names</em></strong></p>
 <h3 id="primary-and-secondary-attribute-guidelines">Primary and Secondary Attribute Guidelines<a class="headerlink" href="#primary-and-secondary-attribute-guidelines" title="Permanent link">&para;</a></h3>
 <p>If issuers expect people to hold multiples of their credentials of the same type, they may want to specify a primary and secondary attribute to display on the card face. </p>
 <p>Note that wallet builders or holders may limit the visibility of the primary and secondary attributes on the card face to mitigate privacy concerns. Issuers can expect that these attributes may be fully visible, redacted, or hidden.</p>
 <p>To limit personal information from being displayed on a card face, only specify what is absolutely necessary for wallet holders to differentiate between credentials of the same type. Do not display private information such as medical related attributes.</p>
+<p><strong>Version 1.0</strong></p>
 <table>
   <tr>
    <td>
@@ -5219,6 +5436,30 @@ <h3 id="primary-and-secondary-attribute-guidelines">Primary and Secondary Attrib
   </tr>
 </table>
 
+<p><strong>Version 1.1</strong></p>
+<table>
+  <tr>
+   <td>
+<img src="./images/image14_1.png" width="" alt="alt_text" title="image_tooltip">
+
+   </td>
+   <td>
+<img src="./images/image15_1.png" width="" alt="alt_text" title="image_tooltip">
+
+   </td>
+  </tr>
+  <tr>
+   <td><strong>Do</strong>
+<p>
+Use attributes that help users identify their credentials. Always consider if a primary and secondary attribute is absolutely necessary.
+   </td>
+   <td><strong>Don’t</strong>
+<p>
+Display attributes that contain private information.
+   </td>
+  </tr>
+</table>
+
 <p><strong><em>Figure: Primary/secondary attribute Do’s and Don’ts</em></strong></p>
 <h3 id="non-production-watermark">Non-production watermark<a class="headerlink" href="#non-production-watermark" title="Permanent link">&para;</a></h3>
 <p>To identify non-production credentials, issuers can add a watermark to their credentials. The watermark is a simple line of text that can be customized depending on the issuer needs. The line of text will also appear as a prefix to the credential name. The line of text should be succinct to ensure legibility. This watermark is not intended to be used for any other purpose than to mark non-production credentials. Ensure proper localization to the watermark is present in all languages.</p>
@@ -5231,6 +5472,7 @@ <h3 id="non-production-watermark">Non-production watermark<a class="headerlink"
 <li>DEVELOPMENT</li>
 <li>DO NOT USE </li>
 </ul>
+<p><strong>Version 1.0</strong></p>
 <table>
   <tr>
    <td>
@@ -5255,15 +5497,50 @@ <h3 id="non-production-watermark">Non-production watermark<a class="headerlink"
   </tr>
 </table>
 
+<p><strong>Version 1.1</strong></p>
+<table>
+  <tr>
+   <td>
+
+<img src="./images/image16_1.png" width="" alt="alt_text" title="image_tooltip">
+
+   </td>
+   <td>
+<img src="./images/image17_1.png" width="" alt="alt_text" title="image_tooltip">
+
+   </td>
+  </tr>
+  <tr>
+   <td><strong>Do</strong>
+<p>
+Use succinct words to describe the type of issued credential. This ensures legibility and does not increase the size of the credential unnecessarily.
+   </td>
+   <td><strong>Don’t</strong>
+<p>
+Use long works or words that do not describe non-production credentials.
+   </td>
+  </tr>
+</table>
+
 <h3 id="credential-resizing">Credential resizing<a class="headerlink" href="#credential-resizing" title="Permanent link">&para;</a></h3>
 <p>Credential size depends on the content of the credential and the size of the device. Text areas are resized according to the width. </p>
+<p><strong>Version 1.0</strong></p>
 <p><img alt="alt_text" src="images/image18.png" title="image_tooltip" /></p>
+<p><strong>Version 1.1</strong></p>
+<p><img alt="alt_text" src="images/image18_1.png" title="image_tooltip" /></p>
 <p><strong><em>Figure: Treatment of the credential template on different devices</em></strong></p>
+<p><strong>Version 1.0</strong></p>
 <p><img alt="alt_text" src="images/image19.png" title="image_tooltip" /></p>
+<p><strong>Version 1.1</strong></p>
+<p><img alt="alt_text" src="images/image19_1.png" title="image_tooltip" /></p>
 <p><strong><em>Figure: An example of credential on different devices</em></strong></p>
 <h3 id="stacking">Stacking<a class="headerlink" href="#stacking" title="Permanent link">&para;</a></h3>
-<p>Credentials may be stacked to overlap each other to increase the number of visible credentials in the viewport. The header remains unchanged. The issuer name, logo and credential name will always be visible but the primary and secondary attributes and the image slice will be obscured. </p>
+<p>Credentials may be stacked to overlap each other to increase the number of visible credentials in the viewport. The header remains unchanged. The issuer name, logo and credential name will always be visible, but the primary and secondary attributes and the image slice will be obscured. </p>
+<p>In version 1.1, the credential name will always be visible. The issuer name, logo, attributes and the image slice will be obscured. </p>
+<p><strong>Version 1.0</strong></p>
 <p><img alt="alt_text" src="images/image20.png" title="image_tooltip" /></p>
+<p><strong>Version 1.1</strong></p>
+<p><img alt="alt_text" src="images/image20_1.png" title="image_tooltip" /></p>
 <p><strong><em>Figure: An example of stacked credentials with default and enlarged text.</em></strong></p>
 <h3 id="accessibility">Accessibility<a class="headerlink" href="#accessibility" title="Permanent link">&para;</a></h3>
 <p>The alt-tags for the logo and background images come from the multilingual OCA Meta Overlay for the issuer name and credential type name. </p>
@@ -5417,7 +5694,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0771-anoncreds-attachments/index.html b/main/features/0771-anoncreds-attachments/index.html
index a1b9f3610..e02cc0de9 100644
--- a/main/features/0771-anoncreds-attachments/index.html
+++ b/main/features/0771-anoncreds-attachments/index.html
@@ -12,11 +12,11 @@
         <link rel="prev" href="../../concepts/0757-push-notification/">
       
       
-        <link rel="next" href="../../concepts/0799-long-term-support/">
+        <link rel="next" href="../../concepts/0781-trust-input-protocol/">
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3316,6 +3316,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3484,6 +3505,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3662,6 +3704,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3677,6 +3740,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4978,13 +5083,13 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
         
         
           
-          <a href="../../concepts/0799-long-term-support/" class="md-footer__link md-footer__link--next" aria-label="Next: 0799 Aries Long Term Support Releases">
+          <a href="../../concepts/0781-trust-input-protocol/" class="md-footer__link md-footer__link--next" aria-label="Next: 0781 Trust Input Protocol">
             <div class="md-footer__title">
               <span class="md-footer__direction">
                 Next
               </span>
               <div class="md-ellipsis">
-                0799 Aries Long Term Support Releases
+                0781 Trust Input Protocol
               </div>
             </div>
             <div class="md-footer__button md-icon">
@@ -5021,7 +5126,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0780-data-urls-images/index.html b/main/features/0780-data-urls-images/index.html
index 0212fe1a5..9611d7eda 100644
--- a/main/features/0780-data-urls-images/index.html
+++ b/main/features/0780-data-urls-images/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3461,6 +3461,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3629,6 +3650,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3671,6 +3713,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3686,6 +3749,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4894,7 +4999,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0793-unqualfied-dids-transition/index.html b/main/features/0793-unqualfied-dids-transition/index.html
index 7b2d3c9fd..4be1722ff 100644
--- a/main/features/0793-unqualfied-dids-transition/index.html
+++ b/main/features/0793-unqualfied-dids-transition/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3437,6 +3437,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3605,6 +3626,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3647,6 +3689,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3662,6 +3725,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4828,7 +4933,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0794-did-rotate/index.html b/main/features/0794-did-rotate/index.html
index ce5a5a836..a3ad50dd6 100644
--- a/main/features/0794-did-rotate/index.html
+++ b/main/features/0794-did-rotate/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3443,6 +3443,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3611,6 +3632,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3653,6 +3695,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3668,6 +3731,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4815,7 +4920,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0804-didcomm-rpc/index.html b/main/features/0804-didcomm-rpc/index.html
index fd972597b..1accdb5f6 100644
--- a/main/features/0804-didcomm-rpc/index.html
+++ b/main/features/0804-didcomm-rpc/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3536,6 +3536,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3704,6 +3725,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3746,6 +3788,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3761,6 +3824,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5300,7 +5405,7 @@ <h2 id="implementations">Implementations<a class="headerlink" href="#implementat
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0809-w3c-data-integrity-credential-attachment/index.html b/main/features/0809-w3c-data-integrity-credential-attachment/index.html
index d79a3a2c3..1ffd1bbb4 100644
--- a/main/features/0809-w3c-data-integrity-credential-attachment/index.html
+++ b/main/features/0809-w3c-data-integrity-credential-attachment/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -757,7 +757,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -778,7 +778,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -799,7 +799,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -820,7 +820,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -841,7 +841,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -862,7 +862,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -883,7 +883,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -904,7 +904,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -925,7 +925,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -946,7 +946,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -967,7 +967,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -988,7 +988,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1009,7 +1009,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1030,7 +1030,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1051,7 +1051,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1072,7 +1072,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1093,7 +1093,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1114,7 +1114,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1135,7 +1135,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1156,7 +1156,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1177,7 +1177,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1219,7 +1219,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1240,7 +1240,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1282,7 +1282,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1303,7 +1303,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1324,7 +1324,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1366,7 +1366,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1387,7 +1387,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1408,7 +1408,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3470,6 +3470,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3638,6 +3659,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3680,6 +3722,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3695,6 +3758,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -5021,7 +5126,7 @@ <h2 id="unresolved-questions">Unresolved questions<a class="headerlink" href="#u
     <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/features/0829-VDR-Proxy/index.html b/main/features/0829-VDR-Proxy/index.html
new file mode 100644
index 000000000..e16493557
--- /dev/null
+++ b/main/features/0829-VDR-Proxy/index.html
@@ -0,0 +1,5243 @@
+
+<!doctype html>
+<html lang="en" class="no-js">
+  <head>
+    
+      <meta charset="utf-8">
+      <meta name="viewport" content="width=device-width,initial-scale=1">
+      
+      
+      
+      
+        <link rel="prev" href="../../concepts/0812-compression-dictionary/">
+      
+      
+        <link rel="next" href="../0024-didcomm-over-xmpp/">
+      
+      
+      <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
+    
+    
+      
+        <title>0829 VDR Proxy - Hyperledger Aries Interoperability Profiles / RFCs</title>
+      
+    
+    
+      <link rel="stylesheet" href="../../assets/stylesheets/main.6f8fc17f.min.css">
+      
+        
+        <link rel="stylesheet" href="../../assets/stylesheets/palette.06af60db.min.css">
+      
+      
+
+
+    
+    
+      
+    
+    
+      
+        
+        
+        <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
+        <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto:300,300i,400,400i,700,700i%7CRoboto+Mono:400,400i,700,700i&display=fallback">
+        <style>:root{--md-text-font:"Roboto";--md-code-font:"Roboto Mono"}</style>
+      
+    
+    
+    <script>__md_scope=new URL("../..",location),__md_hash=e=>[...e].reduce(((e,_)=>(e<<5)-e+_.charCodeAt(0)),0),__md_get=(e,_=localStorage,t=__md_scope)=>JSON.parse(_.getItem(t.pathname+"."+e)),__md_set=(e,_,t=localStorage,a=__md_scope)=>{try{t.setItem(a.pathname+"."+e,JSON.stringify(_))}catch(e){}}</script>
+    
+      
+
+    
+    
+    
+  </head>
+  
+  
+    
+    
+      
+    
+    
+    
+    
+    <body dir="ltr" data-md-color-scheme="default" data-md-color-primary="green" data-md-color-accent="indigo">
+  
+    
+    <input class="md-toggle" data-md-toggle="drawer" type="checkbox" id="__drawer" autocomplete="off">
+    <input class="md-toggle" data-md-toggle="search" type="checkbox" id="__search" autocomplete="off">
+    <label class="md-overlay" for="__drawer"></label>
+    <div data-md-component="skip">
+      
+        
+        <a href="#0829-vdr-proxy" class="md-skip">
+          Skip to content
+        </a>
+      
+    </div>
+    <div data-md-component="announce">
+      
+    </div>
+    
+    
+      
+
+  
+
+<header class="md-header md-header--shadow md-header--lifted" data-md-component="header">
+  <nav class="md-header__inner md-grid" aria-label="Header">
+    <a href="../.." title="Hyperledger Aries Interoperability Profiles / RFCs" class="md-header__button md-logo" aria-label="Hyperledger Aries Interoperability Profiles / RFCs" data-md-component="logo">
+      
+  <img src="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/Hyperledger_Aries_Logo_White.png" alt="logo">
+
+    </a>
+    <label class="md-header__button md-icon" for="__drawer">
+      
+      <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M3 6h18v2H3zm0 5h18v2H3zm0 5h18v2H3z"/></svg>
+    </label>
+    <div class="md-header__title" data-md-component="header-title">
+      <div class="md-header__ellipsis">
+        <div class="md-header__topic">
+          <span class="md-ellipsis">
+            Hyperledger Aries Interoperability Profiles / RFCs
+          </span>
+        </div>
+        <div class="md-header__topic" data-md-component="header-topic">
+          <span class="md-ellipsis">
+            
+              0829 VDR Proxy
+            
+          </span>
+        </div>
+      </div>
+    </div>
+    
+      
+        <form class="md-header__option" data-md-component="palette">
+  
+    
+    
+    
+    <input class="md-option" data-md-color-media="" data-md-color-scheme="default" data-md-color-primary="green" data-md-color-accent="indigo"  aria-hidden="true"  type="radio" name="__palette" id="__palette_0">
+    
+  
+    
+    
+    
+    <input class="md-option" data-md-color-media="(prefers-color-scheme: light)" data-md-color-scheme="default" data-md-color-primary="indigo" data-md-color-accent="indigo"  aria-label="Switch to dark mode"  type="radio" name="__palette" id="__palette_1">
+    
+      <label class="md-header__button md-icon" title="Switch to dark mode" for="__palette_2" hidden>
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 8a4 4 0 0 0-4 4 4 4 0 0 0 4 4 4 4 0 0 0 4-4 4 4 0 0 0-4-4m0 10a6 6 0 0 1-6-6 6 6 0 0 1 6-6 6 6 0 0 1 6 6 6 6 0 0 1-6 6m8-9.31V4h-4.69L12 .69 8.69 4H4v4.69L.69 12 4 15.31V20h4.69L12 23.31 15.31 20H20v-4.69L23.31 12z"/></svg>
+      </label>
+    
+  
+    
+    
+    
+    <input class="md-option" data-md-color-media="(prefers-color-scheme: dark)" data-md-color-scheme="slate" data-md-color-primary="indigo" data-md-color-accent="indigo"  aria-label="Switch to light mode"  type="radio" name="__palette" id="__palette_2">
+    
+      <label class="md-header__button md-icon" title="Switch to light mode" for="__palette_0" hidden>
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 18c-.89 0-1.74-.2-2.5-.55C11.56 16.5 13 14.42 13 12s-1.44-4.5-3.5-5.45C10.26 6.2 11.11 6 12 6a6 6 0 0 1 6 6 6 6 0 0 1-6 6m8-9.31V4h-4.69L12 .69 8.69 4H4v4.69L.69 12 4 15.31V20h4.69L12 23.31 15.31 20H20v-4.69L23.31 12z"/></svg>
+      </label>
+    
+  
+</form>
+      
+    
+    
+      <script>var palette=__md_get("__palette");if(palette&&palette.color){if("(prefers-color-scheme)"===palette.color.media){var media=matchMedia("(prefers-color-scheme: light)"),input=document.querySelector(media.matches?"[data-md-color-media='(prefers-color-scheme: light)']":"[data-md-color-media='(prefers-color-scheme: dark)']");palette.color.media=input.getAttribute("data-md-color-media"),palette.color.scheme=input.getAttribute("data-md-color-scheme"),palette.color.primary=input.getAttribute("data-md-color-primary"),palette.color.accent=input.getAttribute("data-md-color-accent")}for(var[key,value]of Object.entries(palette.color))document.body.setAttribute("data-md-color-"+key,value)}</script>
+    
+    
+    
+      <label class="md-header__button md-icon" for="__search">
+        
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+      </label>
+      <div class="md-search" data-md-component="search" role="dialog">
+  <label class="md-search__overlay" for="__search"></label>
+  <div class="md-search__inner" role="search">
+    <form class="md-search__form" name="search">
+      <input type="text" class="md-search__input" name="query" aria-label="Search" placeholder="Search" autocapitalize="off" autocorrect="off" autocomplete="off" spellcheck="false" data-md-component="search-query" required>
+      <label class="md-search__icon md-icon" for="__search">
+        
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+        
+        <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
+      </label>
+      <nav class="md-search__options" aria-label="Search">
+        
+        <button type="reset" class="md-search__icon md-icon" title="Clear" aria-label="Clear" tabindex="-1">
+          
+          <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M19 6.41 17.59 5 12 10.59 6.41 5 5 6.41 10.59 12 5 17.59 6.41 19 12 13.41 17.59 19 19 17.59 13.41 12z"/></svg>
+        </button>
+      </nav>
+      
+    </form>
+    <div class="md-search__output">
+      <div class="md-search__scrollwrap" tabindex="0" data-md-scrollfix>
+        <div class="md-search-result" data-md-component="search-result">
+          <div class="md-search-result__meta">
+            Initializing search
+          </div>
+          <ol class="md-search-result__list" role="presentation"></ol>
+        </div>
+      </div>
+    </div>
+  </div>
+</div>
+    
+    
+      <div class="md-header__source">
+        <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
+  <div class="md-source__icon md-icon">
+    
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+  </div>
+  <div class="md-source__repository">
+    hyperledger/aries-rfcs
+  </div>
+</a>
+      </div>
+    
+  </nav>
+  
+    
+      
+<nav class="md-tabs" aria-label="Tabs" data-md-component="tabs">
+  <div class="md-grid">
+    <ul class="md-tabs__list">
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../.." class="md-tabs__link">
+          
+  
+  Welcome
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../MAINTAINERS/" class="md-tabs__link">
+          
+  
+  Governance
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../aip2/0003-protocols/" class="md-tabs__link">
+          
+  
+  AIP 2.0
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../concepts/0003-protocols/" class="md-tabs__link">
+          
+  
+  ADOPTED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../concepts/0004-agents/" class="md-tabs__link">
+          
+  
+  ACCEPTED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../0032-message-timing/" class="md-tabs__link">
+          
+  
+  DEMONSTRATED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+    
+  
+  
+    
+    
+      <li class="md-tabs__item md-tabs__item--active">
+        <a href="../0028-introduce/" class="md-tabs__link">
+          
+  
+  PROPOSED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../0024-didcomm-over-xmpp/" class="md-tabs__link">
+          
+  
+  STALLED
+
+        </a>
+      </li>
+    
+  
+
+      
+        
+  
+  
+  
+    
+    
+      <li class="md-tabs__item">
+        <a href="../../concepts/0013-overlays/" class="md-tabs__link">
+          
+  
+  RETIRED
+
+        </a>
+      </li>
+    
+  
+
+      
+    </ul>
+  </div>
+</nav>
+    
+  
+</header>
+    
+    <div class="md-container" data-md-component="container">
+      
+      
+        
+      
+      <main class="md-main" data-md-component="main">
+        <div class="md-main__inner md-grid">
+          
+            
+              
+              <div class="md-sidebar md-sidebar--primary" data-md-component="sidebar" data-md-type="navigation" >
+                <div class="md-sidebar__scrollwrap">
+                  <div class="md-sidebar__inner">
+                    
+
+
+  
+
+
+<nav class="md-nav md-nav--primary md-nav--lifted" aria-label="Navigation" data-md-level="0">
+  <label class="md-nav__title" for="__drawer">
+    <a href="../.." title="Hyperledger Aries Interoperability Profiles / RFCs" class="md-nav__button md-logo" aria-label="Hyperledger Aries Interoperability Profiles / RFCs" data-md-component="logo">
+      
+  <img src="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/Hyperledger_Aries_Logo_White.png" alt="logo">
+
+    </a>
+    Hyperledger Aries Interoperability Profiles / RFCs
+  </label>
+  
+    <div class="md-nav__source">
+      <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
+  <div class="md-source__icon md-icon">
+    
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+  </div>
+  <div class="md-source__repository">
+    hyperledger/aries-rfcs
+  </div>
+</a>
+    </div>
+  
+  <ul class="md-nav__list" data-md-scrollfix>
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_1" >
+        
+          
+          <label class="md-nav__link" for="__nav_1" id="__nav_1_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    Welcome
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_1_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_1">
+            <span class="md-nav__icon md-icon"></span>
+            Welcome
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../.." class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Welcome
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../RFCindex/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    All RFCs by Status
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0000-template/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    RFC Template
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../0000-template-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Protocol RFC Template
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_2" >
+        
+          
+          <label class="md-nav__link" for="__nav_2" id="__nav_2_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    Governance
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_2_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_2">
+            <span class="md-nav__icon md-icon"></span>
+            Governance
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../MAINTAINERS/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Maintainers
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../contributing/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Contributing
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../github-issues/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Submitting Issues
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../LICENSE/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    License
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../SECURITY/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    Security
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_3" >
+        
+          
+          <label class="md-nav__link" for="__nav_3" id="__nav_3_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    AIP 2.0
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_3_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_3">
+            <span class="md-nav__icon md-icon"></span>
+            AIP 2.0
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0003-protocols/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0003 Protocols
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0004-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0004 Agents
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0005-didcomm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0005 DID Communication
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0008-message-id-and-threading/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0008 Message ID and Threading
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0011-decorators/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0011 Decorators
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0015-acks/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0015 ACKs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0017-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0017 Attachments
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0019-encryption-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0019 Encryption Envelope
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0020-message-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0020 Message Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0023-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0023 DID Exchange Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0025-didcomm-transports/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0025 DIDComm Transports
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0035-report-problem/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0035 Report Problem Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0044-didcomm-file-and-mime-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0044 DIDComm File and MIME Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0046-mediators-and-relays/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0046 Mediators and Relays
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0047-json-ld-compatibility/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0047 JSON-LD Compatibility
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0048-trust-ping/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0048 Trust Ping Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0050-wallets/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0050 Wallets
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0092-transport-return-route/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0092 Transports Return Route
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0094-cross-domain-messaging/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0094 Cross-Domain Messaging
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0095-basic-message/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0095 Basic Message Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0183-revocation-notification/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0183 Revocation Notification 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0211-route-coordination/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0211 Mediator Coordination Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0360-use-did-key/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0360 did:key Usage
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0434-outofband/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0434 Out-of-Band Protocol 1.1
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0441-present-proof-best-practices/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0441 Prover and Verifier Best Practices for Proof Presentation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0453-issue-credential-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0453 Issue Credential Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0454-present-proof-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0454 Present Proof Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0510-dif-pres-exch-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0519-goal-codes/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0519 Goal Codes
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0557-discover-features-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0557 Discover Features Protocol v2.x
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0592-indy-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../aip2/0593-json-ld-cred-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_4" >
+        
+          
+          <label class="md-nav__link" for="__nav_4" id="__nav_4_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    ADOPTED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_4_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_4">
+            <span class="md-nav__icon md-icon"></span>
+            ADOPTED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0003-protocols/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0003 Protocols
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0005-didcomm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0005 DID Communication
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0008-message-id-and-threading/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0008 Message ID and Threading
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0011-decorators/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0011 Decorators
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0015-acks/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0015 ACKs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0017-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0017 Attachments
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0019-encryption-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0019 Encryption Envelope
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0020-message-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0020 Message Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0021-didcomm-message-anatomy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0021 DIDComm Message Anatomy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0023-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0023 DID Exchange v1
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0025-didcomm-transports/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0025 DIDComm Transports
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0031-discover-features/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0031 Discover Features Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0035-report-problem/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0035 Report Problem Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0036-issue-credential/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0036 Issue Credential Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0037-present-proof/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0037 Present Proof Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0048-trust-ping/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0048 Trust Ping Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0092-transport-return-route/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0092 Transports Return Route
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0094-cross-domain-messaging/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0094 Cross-Domain Messaging
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0095-basic-message/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0095 Basic Message Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0160-connection-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0160 Connection Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0211-route-coordination/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0211 Mediator Coordination Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0302-aries-interop-profile/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0302 Aries Interop Profile
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0360-use-did-key/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0360 did:key Usage
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0434-outofband/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0434 Out-of-Band Protocol 1.1
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0441-present-proof-best-practices/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0441 Prover and Verifier Best Practices for Proof Presentation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0453-issue-credential-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0453 Issue Credential Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0454-present-proof-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0454 Present Proof Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0496-transition-to-oob-and-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0496 Transition to the Out of Band Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0510-dif-pres-exch-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0557-discover-features-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0557 Discover Features Protocol v2.x
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0592-indy-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0593-json-ld-cred-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_5" >
+        
+          
+          <label class="md-nav__link" for="__nav_5" id="__nav_5_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    ACCEPTED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_5_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_5">
+            <span class="md-nav__icon md-icon"></span>
+            ACCEPTED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0004-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0004 Agents
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0006-ssi-notation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0006 SSI Notation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0044-didcomm-file-and-mime-types/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0044 DIDComm File and MIME Types
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0046-mediators-and-relays/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0046 Mediators and Relays
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0047-json-ld-compatibility/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0047 JSON-LD Compatibility
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0049-repudiation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0049 Repudiation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0050-wallets/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0050 Wallets
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0183-revocation-notification/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0183 Revocation Notification 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0519-goal-codes/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0519 Goal Codes
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0587-encryption-envelope-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0587 Encryption Envelope v2
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0646-bbs-credentials/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0646 W3C Credential Exchange using BBS+ Signatures
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0685-pickup-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0685 Pickup Protocol 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0721-revocation-notification-v2/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0721 Revocation Notification 2.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0793-unqualfied-dids-transition/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0793 Unqualified DID Transition
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0794-did-rotate/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0794 DID Rotate 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_6" >
+        
+          
+          <label class="md-nav__link" for="__nav_6" id="__nav_6_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    DEMONSTRATED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_6_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_6">
+            <span class="md-nav__icon md-icon"></span>
+            DEMONSTRATED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0032-message-timing/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0032 Message Timing
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0042-lox/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0042 LOX -- A more secure pluggable framework for protecting wallet keys
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0043-l10n/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0043 l10n (Locali[s|z]ation)
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0113-question-answer/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0113 Question Answer Protocol 0.9
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0509-action-menu/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0509 Action Menu Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0748-n-wise-did-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0748 N-wise DID Exchange Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0755-oca-for-aries/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0755 Overlays Capture Architecture (OCA) For Aries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0756-oca-for-aries-style-guide/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0756 OCA for Aries Style Guide
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0780-data-urls-images/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0780 Use Data URLs for Images and More in Credential Attributes
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0804-didcomm-rpc/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0804 DIDComm Remote Procedure Call (DRPC)
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0809-w3c-data-integrity-credential-attachment/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0809 W3C Verifiable Credential Data Integrity Attachment format for requesting and issuing credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+    
+  
+  
+  
+    
+    
+    
+      
+        
+        
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--active md-nav__item--section md-nav__item--nested">
+      
+        
+        
+        <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_7" checked>
+        
+          
+          <label class="md-nav__link" for="__nav_7" id="__nav_7_label" tabindex="">
+            
+  
+  <span class="md-ellipsis">
+    PROPOSED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_7_label" aria-expanded="true">
+          <label class="md-nav__title" for="__nav_7">
+            <span class="md-nav__icon md-icon"></span>
+            PROPOSED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0028-introduce/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0028 Introduce Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0034-message-tracing/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0034 Message Tracing
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0056-service-decorator/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0056 Service Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0066-non-repudiable-cryptographic-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0066 Non-Repudiable Signature for Cryptographic Envelope
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0067-didcomm-diddoc-conventions/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0067 DIDComm DID document conventions
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0074-didcomm-best-practices/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0074 DIDComm Best Practices
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0103-indirect-identity-control/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0103 Indirect Identity Control
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0104-chained-credentials/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0104 Chained Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0124-did-resolution-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0124 DID Resolution Protocol 0.9
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0167-data-consent-lifecycle/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0167 Data Consent Lifecycle
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0212-pickup/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0212 Pickup Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0213-transfer-policy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0213 Transfer Policy Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0214-help-me-discover/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0214 "Help Me Discover" Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0231-biometric-service-provider/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0231 Biometric Service Provider
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0268-unified-didcomm-agent-deeplinking/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0268 Unified DIDCOMM Deeplinking
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0270-interop-test-suite/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0270 Interop Test Suite
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0345-community-coordinated-update/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0345 Community Coordinated Update
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0346-didcomm-between-two-mobile-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0346 DIDComm Between Two Mobile Agents Using Cloud Agent Mediator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0347-proof-negotiation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0347 Proof Negotiation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0430-machine-readable-governance-frameworks/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0430 Machine-Readable Governance Frameworks
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0440-kms-architectures/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0440 KMS Architectures
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0511-dif-cred-manifest-attach/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0511 Credential-Manifest Attachment format for requesting and presenting credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0530-goal-human-readable-verified-identifer/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0530 Goal - Human Readable Verifiable Identifier
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0559-pppu/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0559 Privacy-Preserving Proof of Uniqueness
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0566-issuer-hosted-custodidal-agents/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0566 Issuer-Hosted Custodial Agents
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0641-linking-binary-objects-to-credentials/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0641 Linking binary objects to credentials using hash based references
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0693-credential-representation/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0693 Cross-Platform Credential Representation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0699-push-notifications-apns/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0699 Push Notifications apns Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0700-oob-through-redirect/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0700 Out-of-Band through redirect
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0728-device-binding-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0728 Device Binding Attachments
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0734-push-notifications-fcm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0734 Push Notifications fcm Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0757-push-notification/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0757 Push Notification
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0771-anoncreds-attachments/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0771 AnonCreds Attachment Formats for Requesting and Presenting Credentials
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0799-long-term-support/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0799 Aries Long Term Support Releases
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+    
+  
+  
+  
+    <li class="md-nav__item md-nav__item--active">
+      
+      <input class="md-nav__toggle md-toggle" type="checkbox" id="__toc">
+      
+      
+        
+      
+      
+        <label class="md-nav__link md-nav__link--active" for="__toc">
+          
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+          <span class="md-nav__icon md-icon"></span>
+        </label>
+      
+      <a href="./" class="md-nav__link md-nav__link--active">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+      
+        
+
+<nav class="md-nav md-nav--secondary" aria-label="Table of contents">
+  
+  
+  
+    
+  
+  
+    <label class="md-nav__title" for="__toc">
+      <span class="md-nav__icon md-icon"></span>
+      Table of contents
+    </label>
+    <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
+      
+        <li class="md-nav__item">
+  <a href="#summary" class="md-nav__link">
+    <span class="md-ellipsis">
+      Summary
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#motivation" class="md-nav__link">
+    <span class="md-ellipsis">
+      Motivation
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Motivation">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#firewall-issues-for-agents-accessing-indy-networks" class="md-nav__link">
+    <span class="md-ellipsis">
+      Firewall Issues for Agents Accessing Indy Networks
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#fetching-revocation-data" class="md-nav__link">
+    <span class="md-ellipsis">
+      Fetching Revocation Data
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#tutorial" class="md-nav__link">
+    <span class="md-ellipsis">
+      Tutorial
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Tutorial">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#name-and-version" class="md-nav__link">
+    <span class="md-ellipsis">
+      Name and Version
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#key-concepts" class="md-nav__link">
+    <span class="md-ellipsis">
+      Key Concepts
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#role" class="md-nav__link">
+    <span class="md-ellipsis">
+      Role
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#states" class="md-nav__link">
+    <span class="md-ellipsis">
+      States
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#messages" class="md-nav__link">
+    <span class="md-ellipsis">
+      Messages
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#constraints" class="md-nav__link">
+    <span class="md-ellipsis">
+      Constraints
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#reference" class="md-nav__link">
+    <span class="md-ellipsis">
+      Reference
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#drawbacks" class="md-nav__link">
+    <span class="md-ellipsis">
+      Drawbacks
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#rationale-and-alternatives" class="md-nav__link">
+    <span class="md-ellipsis">
+      Rationale and alternatives
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#prior-art" class="md-nav__link">
+    <span class="md-ellipsis">
+      Prior art
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#unresolved-questions" class="md-nav__link">
+    <span class="md-ellipsis">
+      Unresolved questions
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#implementations" class="md-nav__link">
+    <span class="md-ellipsis">
+      Implementations
+    </span>
+  </a>
+  
+</li>
+      
+    </ul>
+  
+</nav>
+      
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_8" >
+        
+          
+          <label class="md-nav__link" for="__nav_8" id="__nav_8_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    STALLED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_8_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_8">
+            <span class="md-nav__icon md-icon"></span>
+            STALLED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0024-didcomm-over-xmpp/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0024 DIDComm over XMPP
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0029-message-trust-contexts/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0029 Message Trust Contexts
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0030-sync-connection/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0030 Sync Connection Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0075-payment-decorators/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0075 Payment Decorators
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0114-predefined-identities/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0114 Predefined Identities
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0116-evidence-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0116 Evidence Exchange Protocol 0.9
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0193-coin-flip/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0193 Coin Flip Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0207-credential-fraud-threat-model/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0207 Credential Fraud Threat Model
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0217-linkable-message-paths/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0217 Linkable Message Paths
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0249-rich-schema-contexts/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0249 Aries Rich Schema Contexts
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0250-rich-schemas/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0250 Rich Schema Objects
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0257-private-credential-issuance/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0257 Private Credential Issuance
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0281-rich-schemas/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0281 Aries Rich Schemas
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0289-toip-stack/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0289 The Trust Over IP Stack
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0309-didauthz/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0309 DIDAuthZ
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0327-crypto-service/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0327 Crypto service Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0334-jwe-envelope/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0334 JWE envelope 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0335-http-over-didcomm/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0335 HTTP Over DIDComm
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0351-purpose-decorator/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0351 Purpose Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0418-rich-schema-encoding/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0418 Aries Rich Schema Encoding Objects
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0420-rich-schemas-common/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0420 Rich Schema Objects Common
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0428-prepare-issue-rich-credential/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0428 Prerequisites to Issue Rich Credential
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0429-prepare-req-rich-pres/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0429 Prerequisites to Request Rich Presentation
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0445-rich-schema-mapping/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0445 Aries Rich Schema Mapping
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0446-rich-schema-cred-def/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0446 Aries Rich Schema Credential Definition
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0478-coprotocols/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0478 Coprotocols
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0482-coprotocol-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0482 Coprotocol Protocol 0.5
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+      
+      
+  
+  
+  
+  
+    
+    
+    
+      
+      
+    
+    
+    <li class="md-nav__item md-nav__item--nested">
+      
+        
+        
+          
+        
+        <input class="md-nav__toggle md-toggle md-toggle--indeterminate" type="checkbox" id="__nav_9" >
+        
+          
+          <label class="md-nav__link" for="__nav_9" id="__nav_9_label" tabindex="0">
+            
+  
+  <span class="md-ellipsis">
+    RETIRED
+  </span>
+  
+
+            <span class="md-nav__icon md-icon"></span>
+          </label>
+        
+        <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_9_label" aria-expanded="false">
+          <label class="md-nav__title" for="__nav_9">
+            <span class="md-nav__icon md-icon"></span>
+            RETIRED
+          </label>
+          <ul class="md-nav__list" data-md-scrollfix>
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0013-overlays/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0013 Overlays
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../../concepts/0051-dkms/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0051 Decentralized Key Management
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0234-signature-decorator/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0234 Signature Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0303-v01-credential-exchange/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0303 V0.1 Credential Exchange (Deprecated)
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0317-please-ack/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0317 Please ACK Decorator
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0348-transition-msg-type-to-https/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0348 Transition Message Type to HTTPs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../0627-static-peer-dids/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0627 Static Peer DIDs
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+          </ul>
+        </nav>
+      
+    </li>
+  
+
+    
+  </ul>
+</nav>
+                  </div>
+                </div>
+              </div>
+            
+            
+              
+              <div class="md-sidebar md-sidebar--secondary" data-md-component="sidebar" data-md-type="toc" >
+                <div class="md-sidebar__scrollwrap">
+                  <div class="md-sidebar__inner">
+                    
+
+<nav class="md-nav md-nav--secondary" aria-label="Table of contents">
+  
+  
+  
+    
+  
+  
+    <label class="md-nav__title" for="__toc">
+      <span class="md-nav__icon md-icon"></span>
+      Table of contents
+    </label>
+    <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
+      
+        <li class="md-nav__item">
+  <a href="#summary" class="md-nav__link">
+    <span class="md-ellipsis">
+      Summary
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#motivation" class="md-nav__link">
+    <span class="md-ellipsis">
+      Motivation
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Motivation">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#firewall-issues-for-agents-accessing-indy-networks" class="md-nav__link">
+    <span class="md-ellipsis">
+      Firewall Issues for Agents Accessing Indy Networks
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#fetching-revocation-data" class="md-nav__link">
+    <span class="md-ellipsis">
+      Fetching Revocation Data
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#tutorial" class="md-nav__link">
+    <span class="md-ellipsis">
+      Tutorial
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Tutorial">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#name-and-version" class="md-nav__link">
+    <span class="md-ellipsis">
+      Name and Version
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#key-concepts" class="md-nav__link">
+    <span class="md-ellipsis">
+      Key Concepts
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#role" class="md-nav__link">
+    <span class="md-ellipsis">
+      Role
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#states" class="md-nav__link">
+    <span class="md-ellipsis">
+      States
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#messages" class="md-nav__link">
+    <span class="md-ellipsis">
+      Messages
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#constraints" class="md-nav__link">
+    <span class="md-ellipsis">
+      Constraints
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#reference" class="md-nav__link">
+    <span class="md-ellipsis">
+      Reference
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#drawbacks" class="md-nav__link">
+    <span class="md-ellipsis">
+      Drawbacks
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#rationale-and-alternatives" class="md-nav__link">
+    <span class="md-ellipsis">
+      Rationale and alternatives
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#prior-art" class="md-nav__link">
+    <span class="md-ellipsis">
+      Prior art
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#unresolved-questions" class="md-nav__link">
+    <span class="md-ellipsis">
+      Unresolved questions
+    </span>
+  </a>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#implementations" class="md-nav__link">
+    <span class="md-ellipsis">
+      Implementations
+    </span>
+  </a>
+  
+</li>
+      
+    </ul>
+  
+</nav>
+                  </div>
+                </div>
+              </div>
+            
+          
+          
+            <div class="md-content" data-md-component="content">
+              <article class="md-content__inner md-typeset">
+                
+                  
+
+  
+  
+
+
+<h1 id="0829-vdr-proxy">0829: VDR Proxy<a class="headerlink" href="#0829-vdr-proxy" title="Permanent link">&para;</a></h1>
+<ul>
+<li>Authors: <a href="mailto:swcurran@cloudcompass.ca">Stephen Curran</a> (BC Gov)</li>
+<li>Status: <a href="../../#proposed">PROPOSED</a></li>
+<li>Since: 2024-05-09</li>
+<li>Status Note: Proposed</li>
+<li>Supersedes: N/A</li>
+<li>Start Date: 2024-05-09</li>
+<li>Tags: <a href="../../tags/#feature">feature</a>, <a href="../../tags/#protocol">protocol</a></li>
+</ul>
+<h2 id="summary">Summary<a class="headerlink" href="#summary" title="Permanent link">&para;</a></h2>
+<p>A VDR (<a href="https://www.w3.org/TR/did-core/#dfn-verifiable-data-registry">verifiable data registry</a>) is a place where DIDs and objects related to
+DIDs (such as <a href="https://www.hyperledger.org/projects/anoncreds">Hyperledger AnonCreds</a> objects) are stored such that they can be
+resolved. The VDR Proxy protocol defined by this RFC is a DIDComm protocol that
+can be used by a DIDComm agent to request another agent resolve VDR URIs
+(<a href="https://en.wikipedia.org/wiki/Uniform_Resource_Identifier">Uniform Resource Identifier</a>s) and return the resolved objects to the
+requesting agent. The protocol is a simple client/server protocol, supporting
+the ability to request and receive back multiple resolutions in a single exchange.</p>
+<h2 id="motivation">Motivation<a class="headerlink" href="#motivation" title="Permanent link">&para;</a></h2>
+<p>There are several use cases that are driving the initial need for this protocol.</p>
+<h3 id="firewall-issues-for-agents-accessing-indy-networks">Firewall Issues for Agents Accessing Indy Networks<a class="headerlink" href="#firewall-issues-for-agents-accessing-indy-networks" title="Permanent link">&para;</a></h3>
+<p>Directly accessing an Indy network requires an Aries agent to use <a href="https://zeromq.org/">ZMQ</a> which in
+turn uses an atypical set of IP ports (in the 9700 range). Since an Aries agent
+makes an outbound request to interact with the ledger, that is normally not a
+problem. However, some enterprises, and even some <a href="https://en.wikipedia.org/wiki/Internet_service_provider">ISPs</a>, prevent the use of
+"non-standard" ports, blocking them with at an outbound firewall. Such
+organizations only permit the outbound use of the HTTP/HTTPS ports of 80 and
+443. When an Aries user, such as someone with a mobile wallet, is on a network
+that limits outbound port access they cannot access the Indy networks to
+retrieve ledger objects needed to process the credentials and presentations they
+are receiving/generating. When direct access to the ledger is blocked, an agent
+can detect the problem and fallback to use a configured VDR Proxy service using
+this protocol. The initial use is for a mobile agent to use its DIDComm mediator
+as a proxy, but the protocol is not restricted to that case.</p>
+<h3 id="fetching-revocation-data">Fetching Revocation Data<a class="headerlink" href="#fetching-revocation-data" title="Permanent link">&para;</a></h3>
+<p>Another use case for this protocol is when a holder needs verification data when
+preparing a verifiable presentation. Some VDRs, such as the <a href="https://w3c-ccg.github.io/did-method-web/">did:web DID Method</a>
+can be setup with the issuer hosting such data, especially the
+revocation-related data. When the holder is required to collect revocation
+data for preparing a verifiable presentation, as is the case with <a href="https://www.hyperledger.org/projects/anoncreds">Hyperledger
+AnonCreds</a>, we don't want the holder directly contacting the issuer to get the
+necessary data. That enables either tracking or the perception of tracking by
+the issuer, which is undesirable. By using the VDR Proxy protocol, the holder
+can have another party, such as the verifier, the holder's mediator, or another
+agent altogether, resolve the revocation data and provide it to the holder.</p>
+<h2 id="tutorial">Tutorial<a class="headerlink" href="#tutorial" title="Permanent link">&para;</a></h2>
+<h3 id="name-and-version">Name and Version<a class="headerlink" href="#name-and-version" title="Permanent link">&para;</a></h3>
+<p>This is the VDR Proxy protocol. It is uniquely identified by the URI:</p>
+<div class="highlight"><pre><span></span><code>&quot;https://didcomm.org/vdrproxy/1.0&quot;
+</code></pre></div>
+<h3 id="key-concepts">Key Concepts<a class="headerlink" href="#key-concepts" title="Permanent link">&para;</a></h3>
+<blockquote>
+<p>This RFC assumes that the reader is familiar with <a href="../../concepts/0005-didcomm/">DID communication</a>.</p>
+</blockquote>
+<p>The protocol consists of a DIDComm <code>request</code> message from a client carrying an
+array of URIs to be resolved by the proxy server, and a second message that
+carries the result of resolving those URIs back to the client. The intention is
+that the URIs refer to resolvable objects held in a <a href="https://www.w3.org/TR/did-core/#dfn-verifiable-data-registry">VDR</a>.</p>
+<p>The server may or may not be able to resolve the requested URI(s). For example,
+the server will be configured to resolve certain DID and AnonCreds methods
+(types of VDRs) and will only resolve URIs for those methods/VDRs.</p>
+<p>On receipt of a request, the server <strong>SHOULD</strong> attempt to resolve each URI
+passed, returning for each an array entry containing either the resolved content, encoded as a
+<a href="https://datatracker.ietf.org/doc/html/rfc2397">data URI</a>, or an error status. A server <strong>MAY</strong> be configured to not to
+resolve some requested URIs, either because they can't or don't want to for some
+business reason. In such cases, the server <strong>SHOULD</strong> respond with an error
+code per unprocessed URI.  If the <code>request</code> itself is incorrectly structured,
+the server <strong>SHOULD</strong> send a [Problem Report] to the client.</p>
+<h3 id="role">Role<a class="headerlink" href="#role" title="Permanent link">&para;</a></h3>
+<p>There are two roles in the protocol <code>client</code> and <code>server</code>:</p>
+<ul>
+<li>The <code>client</code> initiates the protocol, sending a request message to the <code>server</code>.</li>
+<li>The <code>server</code> carries out the request however they see fit. The <code>server</code>
+  <strong>SHOULD</strong> resolve the URIs. The <code>server</code> might be unable or unwilling to
+  resolve some or all of the URIs.</li>
+<li>The <code>server</code> returns the resolution objects in a message to the <code>client</code>.</li>
+</ul>
+<h3 id="states">States<a class="headerlink" href="#states" title="Permanent link">&para;</a></h3>
+<h4 id="client-states">Client States<a class="headerlink" href="#client-states" title="Permanent link">&para;</a></h4>
+<p>The <code>client</code> agent goes through the following states:</p>
+<ul>
+<li>request-sent</li>
+<li>completed</li>
+</ul>
+<p>The state transition table for the <code>client</code> is:</p>
+<table>
+<thead>
+<tr>
+<th>State / Events</th>
+<th>Send Request</th>
+<th>Receive Response</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td><em>Start</em></td>
+<td>Transition to <br><strong>request-sent</strong></td>
+<td></td>
+</tr>
+<tr>
+<td>request-sent</td>
+<td></td>
+<td>Transition to <br><strong>complete</strong></td>
+</tr>
+<tr>
+<td>completed</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>problem-report received</td>
+<td></td>
+<td>Transition to <br><strong>abandoned</strong></td>
+</tr>
+<tr>
+<td>abandoned</td>
+<td></td>
+<td></td>
+</tr>
+</tbody>
+</table>
+<h4 id="server-states">Server States<a class="headerlink" href="#server-states" title="Permanent link">&para;</a></h4>
+<p>The <code>server</code> agent goes through the following states:</p>
+<ul>
+<li>request-received</li>
+<li>completed</li>
+</ul>
+<p>The state transition table for the <code>server</code> is:</p>
+<table>
+<thead>
+<tr>
+<th>State / Events</th>
+<th>Receive Request</th>
+<th>Send Response or Problem Report</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td><em>Start</em></td>
+<td>Transition to <br><strong>request-received</strong></td>
+<td></td>
+</tr>
+<tr>
+<td>request-received</td>
+<td></td>
+<td>Transition to <br><strong>complete</strong></td>
+</tr>
+<tr>
+<td>completed</td>
+<td></td>
+<td></td>
+</tr>
+</tbody>
+</table>
+<h3 id="messages">Messages<a class="headerlink" href="#messages" title="Permanent link">&para;</a></h3>
+<p>The following are the messages in the VDR Proxy protocol. The <code>response</code> message
+handles all completed responses, so the <code>ack</code> (<a href="../0015-acks/">RFC 0015 ACKs</a>) message is
+<strong>NOT</strong> adopted by this protocol. The <a href="../0035-report-problem/">RFC 0035 Report Problem</a> is adopted by
+this protocol in the event that a <code>request</code> is not recognizable as a VDR Proxy
+message and as such, a response message cannot be created. See the
+details below in the <a href="#problem-report-message">Problem Report Message</a> section.</p>
+<h4 id="request-message">Request Message<a class="headerlink" href="#request-message" title="Permanent link">&para;</a></h4>
+<p>The <code>request</code> message is sent by the <code>client</code> to initiate the protocol. The
+message contains the array of URIs for the <code>server</code> to resolve and send the
+resolved objects back to the <code>client</code>. It is assumed the <code>client</code> knows what
+types of URIs the <code>server</code> is prepared to resolve. The <code>server</code> returns an error
+status for any URIs it does not know how to resolve. </p>
+<p>The <code>request</code> message uses the following format:</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a>  {
+<a id="__codelineno-0-2" name="__codelineno-0-2" href="#__codelineno-0-2"></a>    &quot;@type&quot;: &quot;https://didcomm.org/vdrproxy/1.0/request&quot;,
+<a id="__codelineno-0-3" name="__codelineno-0-3" href="#__codelineno-0-3"></a>    &quot;@id&quot;: &quot;2a0ec6db-471d-42ed-84ee-f9544db9da4b&quot;,
+<a id="__codelineno-0-4" name="__codelineno-0-4" href="#__codelineno-0-4"></a>    &quot;request&quot; : [
+<a id="__codelineno-0-5" name="__codelineno-0-5" href="#__codelineno-0-5"></a>      {
+<a id="__codelineno-0-6" name="__codelineno-0-6" href="#__codelineno-0-6"></a>        &quot;id&quot;: &quot;&lt;id&gt;&quot;,
+<a id="__codelineno-0-7" name="__codelineno-0-7" href="#__codelineno-0-7"></a>        &quot;uri&quot; : &quot;&lt;uri&gt;&quot;
+<a id="__codelineno-0-8" name="__codelineno-0-8" href="#__codelineno-0-8"></a>      }
+<a id="__codelineno-0-9" name="__codelineno-0-9" href="#__codelineno-0-9"></a>    ]
+<a id="__codelineno-0-10" name="__codelineno-0-10" href="#__codelineno-0-10"></a>  }
+</code></pre></div>
+<p>The items in the message are as follows:</p>
+<ul>
+<li><code>@type</code> -- required, must be as above</li>
+<li><code>@id</code> -- required, must be as defined in [RFC 0005 DIDComm]</li>
+<li><code>request</code> -- <strong>required</strong>, an item containing an array of URIs to be resolved.</li>
+<li><code>request</code> <strong>MUST</strong> be an array of requests.</li>
+<li>Each request item <strong>MUST</strong> have an <code>id</code>, that is unique with the <code>request</code> item, typically the index of the array ("1", "2", "3", etc.).</li>
+<li>Each request items <strong>MUST</strong> have a URI to be resolved.</li>
+</ul>
+<p>On receipt, the server verifies the format of the request, and iterates through the <code>request</code> array,
+resolving (or not) each URI and preparing the response message.</p>
+<h4 id="response-message">Response Message<a class="headerlink" href="#response-message" title="Permanent link">&para;</a></h4>
+<p>A <code>response</code> message is sent by the <code>server</code> to following the
+processing of the request to convey the output of the processing to the
+<code>client</code>.</p>
+<p>If the <code>request</code> content is unrecognizable, the <code>server</code> SHOULD send a <a href="../0035-report-problem/">RFC 0035
+Report Problem</a> message to the <code>client</code>.</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a>  {
+<a id="__codelineno-1-2" name="__codelineno-1-2" href="#__codelineno-1-2"></a>    &quot;@type&quot;: &quot;https://didcomm.org/vdrproxy/1.0/response&quot;,
+<a id="__codelineno-1-3" name="__codelineno-1-3" href="#__codelineno-1-3"></a>    &quot;@id&quot;: &quot;63d6f6cf-b723-4eaf-874b-ae13f3e3e5c5&quot;,
+<a id="__codelineno-1-4" name="__codelineno-1-4" href="#__codelineno-1-4"></a>    &quot;response&quot;: [
+<a id="__codelineno-1-5" name="__codelineno-1-5" href="#__codelineno-1-5"></a>      {
+<a id="__codelineno-1-6" name="__codelineno-1-6" href="#__codelineno-1-6"></a>        &quot;id&quot;: &quot;&lt;id&gt;&quot;,
+<a id="__codelineno-1-7" name="__codelineno-1-7" href="#__codelineno-1-7"></a>        &quot;status&quot; : &quot;&lt;status code&gt;&quot;,
+<a id="__codelineno-1-8" name="__codelineno-1-8" href="#__codelineno-1-8"></a>        &quot;result&quot; : &quot;&lt;data uri&gt;&quot;
+<a id="__codelineno-1-9" name="__codelineno-1-9" href="#__codelineno-1-9"></a>      }
+<a id="__codelineno-1-10" name="__codelineno-1-10" href="#__codelineno-1-10"></a>    ]
+<a id="__codelineno-1-11" name="__codelineno-1-11" href="#__codelineno-1-11"></a>  }
+</code></pre></div>
+<p>The items in the message are as follows:</p>
+<ul>
+<li><code>@type</code> -- required, must be as above</li>
+<li><code>@id</code> -- required, must be as defined in [RFC 0005 DIDComm]</li>
+<li><code>response</code> -- <strong>required</strong>, an item containing an array of resolution results.</li>
+<li><code>response</code> <strong>MUST</strong> be an array of resolution results the same length and with the same <code>id</code>s as the request.</li>
+<li><code>id</code> -- the <code>id</code> from the <code>request</code> message from the corresponding <code>request</code> item.</li>
+<li><code>status</code> -- either a <code>501</code> (meaning "Service Unavailable") if the server refuses to <code>resolve</code> the URI, or the status code resulting from attempting to resolve the URI.</li>
+<li><code>result</code> -- optional, included only if the resolution was attempted, and the resolution returned a result. If included, the value <strong>MUST</strong> be the result of the resolution in <a href="https://datatracker.ietf.org/doc/html/rfc2397">data URI</a> format. For example, if the result of the resolution is a JSON object, the data URL would likely look like this: <code>data:application/json;base64,&lt;base64 encoded JSON data&gt;</code>.</li>
+</ul>
+<p>As with all DIDComm messages that are not the first in a protocol instance, a
+<code>~thread</code> decorator <strong>MUST</strong> be included in the <code>response</code> message.</p>
+<p>Caching of resolved objects may be done by both the client and the server as they see fit to improve the
+performance of using (or not needing to use) a VDR Proxy. Caching strategies depend by the proxied VDR and
+are out of scope of this protocol.</p>
+<h4 id="problem-report-message">Problem Report Message<a class="headerlink" href="#problem-report-message" title="Permanent link">&para;</a></h4>
+<p>A <a href="../0035-report-problem/">RFC 0035 Report Problem</a> message <strong>SHOULD</strong> be sent by the <code>server</code> instead
+of a <code>response</code> message only if the <code>request</code> is not an array of URIs.
+All resolution errors <strong>MUST</strong> be provided to the <code>client</code> by the <code>server</code> via the
+<code>response</code> message, not a <code>problem-report</code>. The <code>client</code> <strong>MUST NOT</strong>
+respond to a <code>response</code> message, even if the <code>response</code> message is not a valid
+response.  This is because once the <code>server</code> sends the <code>response</code>, the
+protocol is in the <code>completed</code> state (from the <code>server</code>'s perspective) and so
+is subject to deletion. As such, a follow up <code>problem-report</code> message would have
+an invalid <code>thid</code> (thread ID) and (at best) be thrown away by the <code>server</code>.</p>
+<h3 id="constraints">Constraints<a class="headerlink" href="#constraints" title="Permanent link">&para;</a></h3>
+<p>The primary constraint with this protocol is that the two parties using the
+protocol must understand what types of VDRs the server is willing to proxy.</p>
+<h2 id="reference">Reference<a class="headerlink" href="#reference" title="Permanent link">&para;</a></h2>
+<p>None.</p>
+<h2 id="drawbacks">Drawbacks<a class="headerlink" href="#drawbacks" title="Permanent link">&para;</a></h2>
+<p>None defined.</p>
+<h2 id="rationale-and-alternatives">Rationale and alternatives<a class="headerlink" href="#rationale-and-alternatives" title="Permanent link">&para;</a></h2>
+<p>None defined.</p>
+<h2 id="prior-art">Prior art<a class="headerlink" href="#prior-art" title="Permanent link">&para;</a></h2>
+<p>This protocol borrows much from the [RFC 0809 DIDComm Remote Producer Call], including
+the request/response handling, arrays of requests, and the Problem Report handling.</p>
+<h2 id="unresolved-questions">Unresolved questions<a class="headerlink" href="#unresolved-questions" title="Permanent link">&para;</a></h2>
+<p>What status should be returned from the server if it refuses to resolve a URI?
+The chosen status is listed. It would be helpful if the client could differentiate
+between a status returned directly from the server or one proxied from the VDR.</p>
+<h2 id="implementations">Implementations<a class="headerlink" href="#implementations" title="Permanent link">&para;</a></h2>
+<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the "Name" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p>
+<p><em>Implementation Notes</em> <a href="./">may need to include a link to test results</a>.</p>
+<table>
+<thead>
+<tr>
+<th>Name / Link</th>
+<th>Implementation Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td></td>
+<td></td>
+</tr>
+</tbody>
+</table>
+
+
+
+
+
+
+
+
+
+
+
+
+                
+              </article>
+            </div>
+          
+          
+<script>var target=document.getElementById(location.hash.slice(1));target&&target.name&&(target.checked=target.name.startsWith("__tabbed_"))</script>
+        </div>
+        
+          <button type="button" class="md-top md-icon" data-md-component="top" hidden>
+  
+  <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M13 20h-2V8l-5.5 5.5-1.42-1.42L12 4.16l7.92 7.92-1.42 1.42L13 8z"/></svg>
+  Back to top
+</button>
+        
+      </main>
+      
+        <footer class="md-footer">
+  
+    
+      
+      <nav class="md-footer__inner md-grid" aria-label="Footer" >
+        
+          
+          <a href="../../concepts/0812-compression-dictionary/" class="md-footer__link md-footer__link--prev" aria-label="Previous: 0812 Compressing DIDComm messages using dictionaries">
+            <div class="md-footer__button md-icon">
+              
+              <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg>
+            </div>
+            <div class="md-footer__title">
+              <span class="md-footer__direction">
+                Previous
+              </span>
+              <div class="md-ellipsis">
+                0812 Compressing DIDComm messages using dictionaries
+              </div>
+            </div>
+          </a>
+        
+        
+          
+          <a href="../0024-didcomm-over-xmpp/" class="md-footer__link md-footer__link--next" aria-label="Next: 0024 DIDComm over XMPP">
+            <div class="md-footer__title">
+              <span class="md-footer__direction">
+                Next
+              </span>
+              <div class="md-ellipsis">
+                0024 DIDComm over XMPP
+              </div>
+            </div>
+            <div class="md-footer__button md-icon">
+              
+              <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M4 11v2h12l-5.5 5.5 1.42 1.42L19.84 12l-7.92-7.92L10.5 5.5 16 11z"/></svg>
+            </div>
+          </a>
+        
+      </nav>
+    
+  
+  <div class="md-footer-meta md-typeset">
+    <div class="md-footer-meta__inner md-grid">
+      <div class="md-copyright">
+  
+  
+    Made with
+    <a href="https://squidfunk.github.io/mkdocs-material/" target="_blank" rel="noopener">
+      Material for MkDocs
+    </a>
+  
+</div>
+      
+    </div>
+  </div>
+</footer>
+      
+    </div>
+    <div class="md-dialog" data-md-component="dialog">
+      <div class="md-dialog__inner md-typeset"></div>
+    </div>
+    
+    
+    <script id="__config" type="application/json">{"base": "../..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
+    
+    
+      <script src="../../assets/javascripts/bundle.88dd0f4e.min.js"></script>
+      
+    
+  </body>
+</html>
\ No newline at end of file
diff --git a/main/github-issues/index.html b/main/github-issues/index.html
index f042198c2..3cfdad5f6 100644
--- a/main/github-issues/index.html
+++ b/main/github-issues/index.html
@@ -16,7 +16,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -24,7 +24,7 @@
       
     
     
-      <link rel="stylesheet" href="../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../assets/stylesheets/palette.06af60db.min.css">
@@ -193,7 +193,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -413,7 +413,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -809,7 +809,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -830,7 +830,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -851,7 +851,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -872,7 +872,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -893,7 +893,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -914,7 +914,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -935,7 +935,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -956,7 +956,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -977,7 +977,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -998,7 +998,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1019,7 +1019,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1040,7 +1040,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1061,7 +1061,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1082,7 +1082,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1103,7 +1103,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1124,7 +1124,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1145,7 +1145,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1166,7 +1166,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1187,7 +1187,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1208,7 +1208,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1229,7 +1229,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1271,7 +1271,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1292,7 +1292,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1334,7 +1334,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1355,7 +1355,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1376,7 +1376,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1418,7 +1418,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1439,7 +1439,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1460,7 +1460,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3365,6 +3365,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3533,6 +3554,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3575,6 +3617,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3590,6 +3653,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4568,7 +4673,7 @@ <h2 id="github-issues">Github Issues<a class="headerlink" href="#github-issues"
     <script id="__config" type="application/json">{"base": "..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/index.html b/main/index.html
index d0f41cc26..410353df9 100644
--- a/main/index.html
+++ b/main/index.html
@@ -14,7 +14,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -22,7 +22,7 @@
       
     
     
-      <link rel="stylesheet" href="assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="assets/stylesheets/palette.06af60db.min.css">
@@ -191,7 +191,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -411,7 +411,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -831,7 +831,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -852,7 +852,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -873,7 +873,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -894,7 +894,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -915,7 +915,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -936,7 +936,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -957,7 +957,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -978,7 +978,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -999,7 +999,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -1020,7 +1020,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -1041,7 +1041,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -1062,7 +1062,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1083,7 +1083,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1104,7 +1104,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1125,7 +1125,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1146,7 +1146,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1167,7 +1167,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1188,7 +1188,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1209,7 +1209,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1230,7 +1230,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1251,7 +1251,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1293,7 +1293,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1314,7 +1314,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1356,7 +1356,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1377,7 +1377,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1398,7 +1398,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1440,7 +1440,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1461,7 +1461,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1482,7 +1482,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3387,6 +3387,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="concepts/0559-pppu/" class="md-nav__link">
         
@@ -3555,6 +3576,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3597,6 +3639,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3612,6 +3675,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4642,7 +4747,7 @@ <h4 id="acknowledgement">Acknowledgement<a class="headerlink" href="#acknowledge
     <script id="__config" type="application/json">{"base": ".", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>
diff --git a/main/search/search_index.json b/main/search/search_index.json
index 8d5a2592b..feb65f87f 100644
--- a/main/search/search_index.json
+++ b/main/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Welcome","text":"<p>This repo holds Request for Comment (RFCs) for the Aries project. They describe important topics (not minor details) that we want to standardize across the Aries ecosystem.</p> <p>If you are here to learn about Aries, we recommend you use the the RFC Index for a current listing of all RFCs and their statuses.</p> <p>There are 2 types of Aries RFCs:</p> <ul> <li>RFCs that describe individual features (in the <code>./features</code> folder)</li> <li>RFCs that explain concepts underpinning many features (in the <code>./concepts</code> folder)</li> </ul> <p>RFCs are for developers building on Aries. They don't provide guidance on how Aries components implement features internally; individual Aries repos have design docs for that. Each Aries RFC includes an \"implementations\" section and all RFCs with a status greater than <code>Proposed</code> should have at least one listed implementation.</p>"},{"location":"#rfc-lifecycle","title":"RFC Lifecycle","text":"<p>RFCs go through a standard lifecycle.</p> <p></p>"},{"location":"#proposed","title":"PROPOSED","text":"<p>To propose an RFC, use these instructions to raise a PR against the repo. Proposed RFCs are considered a \"work in progress\", even after they are merged. In other words, they haven't been endorsed by the community yet, but they seem like reasonable ideas worth exploring.</p>"},{"location":"#demonstrated","title":"DEMONSTRATED","text":"<p>Demonstrated RFCs have one or more implementations available, listed in the \"Implementations\" section of the RFC document. As with the PROPOSED status, demonstrated RFCs haven't been endorsed by the community, but the ideas put forth have been more thoroughly explored through the implementation(s). The demonstrated status is an optional step in the lifecycle. For protocol-related RFCs, work on protocol tests SHOULD begin in the test suite repo by the time this status is assigned.</p>"},{"location":"#accepted","title":"ACCEPTED","text":"<p>To get an RFC accepted, build consensus for your RFC on chat and in community meetings. If your RFC is a feature that's protocol- or decorator-related, it MUST have reasonable tests in the test suite repo, it MUST list the test suite in the protocol RFC's Implementations section, at least one other implementation must have passed the relevant portions of the test suite, and all implementations listed in this section of the RFC MUST hyperlink to their test results. An accepted RFC is incubating on a standards track; the community has decided to polish it and is exploring or pursuing implementation.</p>"},{"location":"#adopted","title":"ADOPTED","text":"<p>To get an RFC adopted, socialize and implement. An RFC gets this status once it has significant momentum--when implementations accumulate, or when the mental model it advocates has begun to permeate our discourse. In other words, adoption is acknowledgment of a de facto standard.</p> <p>To refine an RFC, propose changes to it through additional PRs. Typically these changes are driven by experience that accumulates during or after adoption. Minor refinements that just improve clarity can happen inline with lightweight review. Status is still ADOPTED.</p>"},{"location":"#stalled","title":"STALLED","text":"<p>An RFC is stalled when a proposed RFC makes no progress towards implementation such that it is extremely unlikely it will ever move forward. The stalled state differs from retired in that it is an RFC that has never been implemented or superseded. Like the retired state, it is (likely) an end state and the RFC will not proceed further. Such an RFC remains in the repository on the off chance it will ring a chord with others, be returned to the proposed state, and continue to evolve.</p>"},{"location":"#retired","title":"RETIRED","text":"<p>An RFC is retired when it is withdrawn from community consideration by its authors, when implementation seems permanently stalled, or when significant refinements require a superseding document. If a retired RFC has been superseded, its <code>Superseded By</code> field should contain a link to the newer spec, and the newer spec's <code>Supersedes</code> field should contain a link to the older spec. Permalinks are not broken.</p>"},{"location":"#changing-an-rfc-status","title":"Changing an RFC Status","text":"<p>See notes about this in Contributing.</p>"},{"location":"#about","title":"About","text":""},{"location":"#license","title":"License","text":"<p>This repository is licensed under an Apache 2 License. It is protected by a Developer Certificate of Origin on every commit. This means that any contributions you make must be licensed in an Apache-2-compatible way, and must be free from patent encumbrances or additional terms and conditions. By raising a PR, you certify that this is the case for your contribution.</p> <p>For more instructions about contributing, see Contributing.</p>"},{"location":"#acknowledgement","title":"Acknowledgement","text":"<p>The structure and a lot of the initial language of this repository was borrowed from Indy HIPEs, which borrowed it from Rust RFC. Their good work has made the setup of this repository much quicker and better than it otherwise would have been. If you are not familiar with the Rust community, you should check them out.</p>"},{"location":"0000-template-protocol/","title":"Aries RFC 0000: Your Protocol 0.9","text":"<ul> <li>Authors: your name -- email is optional</li> <li>Status: PROPOSED</li> <li>Since: 2019-12-26 (date you submit your PR)</li> <li>Status Note: (explanation of current status)  </li> <li>Supersedes: (link to anything this RFC supersedes)</li> <li>Start Date: 2018-12-26 (date you started working on this idea)</li> <li>Tags: feature, protocol</li> <li>URI: https://didcomm.org/your_protocol_name/%VER</li> </ul>"},{"location":"0000-template-protocol/#summary","title":"Summary","text":"<p>One paragraph explanation of the feature.</p> <p>If the RFC you are proposing is NOT a protocol, please use this template as a starting point.</p> <p>When completing this template and before submitting as a PR, please remove the template text in sections (other than Implementations). The implementations section should remain as is.</p>"},{"location":"0000-template-protocol/#motivation","title":"Motivation","text":"<p>Why are we doing this? What use cases does it support? What is the expected outcome?</p>"},{"location":"0000-template-protocol/#tutorial","title":"Tutorial","text":""},{"location":"0000-template-protocol/#name-and-version","title":"Name and Version","text":"<p>Name and Version</p> <p>Specify the official name of the protocol and its version, e.g., \"My Protocol 0.9\".</p> <p>Protocol names are often either lower_snake_case or kebob-case. The non-version components of the protocol named are matched exactly.</p> <p>URI: <code>https://didcomm.org/lets_do_lunch/&lt;version&gt;/&lt;messageType&gt;</code></p> <p>Message types and protocols are identified with special URIs that match certain conventions. See Message Type and Protocol Identifier URIs for more details.</p> <p>The version of a protocol is declared carefully. See Semver Rules for Protocols for details.</p>"},{"location":"0000-template-protocol/#key-concepts","title":"Key Concepts","text":"<p>This is short--a paragraph or two. It defines terms and describes the flow of the interaction at a very high level. Key preconditions should be noted (e.g., \"You can't issue a credential until you have completed the connection protocol first\"), as well as ways the protocol can start and end, and what can go wrong. The section might also talk about timing constraints and other assumptions. After reading this section, a developer should know what problem your protocol solves, and should have a rough idea of how the protocol works in its simpler variants.</p>"},{"location":"0000-template-protocol/#roles","title":"Roles","text":"<p>See this note for definitions of the terms \"role\", \"participant\", and \"party\".</p> <p>Provides a formal name to each role in the protocol, says who and how many can play each role, and describes constraints associated with those roles (e.g., \"You can only issue a credential if you have a DID on the public ledger\"). The issue of qualification for roles can also be explored (e.g., \"The holder of the credential must be known to the issuer\").</p> <p>The formal names for each role are important because they are used when agents discover one another's capabilities; an agent doesn't just claim that it supports a protocol; it makes a claim about which roles in the protocol it supports. An agent that supports credential issuance and an agent that supports credential holding may have very different features, but they both use the credential-issuance protocol. By convention, role names use lower-kebab-case and are compared case-sensitively.</p>"},{"location":"0000-template-protocol/#states","title":"States","text":"<p>This section lists the possible states that exist for each role. It also enumerates the events (often but not always messages) that can occur, including errors, and what should happen to state as a result. A formal representation of this information is provided in a state machine matrix. It lists events as columns, and states as rows; a cell answers the question, \"If I am in state X (=row), and event Y (=column) occurs, what happens to my state?\" The Tic Tac Toe example is typical.</p> <p>Choreography Diagrams from BPMN are good artifacts here, as are PUML sequence diagrams and UML-style state machine diagrams. The matrix form is nice because it forces an exhaustive analysis of every possible event. The diagram styles are often simpler to create and consume, and the PUML and BPMN forms have the virtue that they can support line-by-line diffs when checked in with source code. However, they don't offer an easy way to see if all possible flows have been considered; what they may NOT describe isn't obvious. This--and the freedom from fancy tools--is why the matrix form is used in many early RFCs. We leave it up to the community to settle on whether it wants to strongly recommend specific diagram types.</p> <p>The formal names for each state are important, as they are used in <code>ack</code>s and <code>problem-report</code>s). For example, a <code>problem-report</code> message declares which state the sender arrived at because of the problem. This helps other participants to react to errors with confidence. Formal state names are also used in the agent test suite, in log messages, and so forth.</p> <p>By convention, state names use lower-kebab-case. They are compared case-sensitively.</p> <p>State management in protocols is a deep topic. For more information, please see State Details and State Machines.</p>"},{"location":"0000-template-protocol/#messages","title":"Messages","text":"<p>This section describes each message in the protocol. It should also note the names and versions of messages from other message families that are adopted by the protocol (e.g., an <code>ack</code> or a <code>problem-report</code>). Typically this section is written as a narrative, showing each message type in the context of an end-to-end sample interaction. All possible fields may not appear; an exhaustive catalog is saved for the \"Reference\" section.</p> <p>Sample messages that are presented in the narrative should also be checked in next to the markdown of the RFC, in DIDComm Plaintext format.</p> <p>The message element of a message type URI are typically lower_camel_case or lower-kebab-case, matching the style of the protocol. JSON items in messages are lower_camel_case and inconsistency in the application of a style within a message is frowned upon by the community.</p>"},{"location":"0000-template-protocol/#adopted-messages","title":"Adopted Messages","text":"<p>Many protocols should use general-purpose messages such as <code>ack</code> and <code>problem-report</code>) at certain points in an interaction. This reuse is strongly encouraged because it helps us avoid defining redundant message types--and the code to handle them--over and over again (see DRY principle).</p> <p>However, using messages with generic values of <code>@type</code> (e.g., <code>\"@type\": \"https://didcomm.org/notification/1.0/ack\"</code>) introduces a challenge for agents as they route messages to their internal routines for handling. We expect internal handlers to be organized around protocols, since a protocol is a discrete unit of business value as well as a unit of testing in our agent test suite. Early work on agents has gravitated towards pluggable, routable protocols as a unit of code encapsulation and dependency as well. Thus the natural routing question inside an agent, when it sees a message, is \"Which protocol handler should I route this message to, based on its @type?\" A generic <code>ack</code> can't be routed this way.</p> <p>Therefore, we allow a protocol to adopt messages into its namespace. This works very much like python's <code>from module import symbol</code> syntax. It changes the <code>@type</code> attribute of the adopted message. Suppose a <code>rendezvous</code> protocol is identified by the URI <code>https://didcomm.org/rendezvous/2.0</code>, and its definition announces that it has adopted generic 1.x <code>ack</code> messages. When such <code>ack</code> messages are sent, the <code>@type</code> should now use the alias defined inside the namespace of the <code>rendezvous</code> protocol:</p> <p></p> <p>Adoption should be declared in an \"Adopted\" subsection of \"Messages\". When adoption is specified, it should include a minimum adopted version of the adopted message type: \"This protocol adopts <code>ack</code> with version &gt;= 1.4\". All versions of the adopted message that share the same major number should be compatible, given the semver rules that apply to protocols.</p>"},{"location":"0000-template-protocol/#constraints","title":"Constraints","text":"<p>Many protocols have constraints that help parties build trust. For example, in buying a house, the protocol includes such things as commission paid to realtors to guarantee their incentives, title insurance, earnest money, and a phase of the process where a home inspection takes place. If you are documenting a protocol that has attributes like these, explain them here. If not, the section can be omitted.</p>"},{"location":"0000-template-protocol/#reference","title":"Reference","text":"<p>All of the sections of reference are optional. If none are needed, the \"Reference\" section can be deleted.</p>"},{"location":"0000-template-protocol/#messages-details","title":"Messages Details","text":"<p>Unless the \"Messages\" section under \"Tutorial\" covered everything that needs to be known about all message fields, this is where the data type, validation rules, and semantics of each field in each message type are details. Enumerating possible values, or providing ABNF or regexes is encouraged. Following conventions such as those for date- and time-related fields can save a lot of time here.</p> <p>Each message type should be associated with one or more roles in the  protocol. That is, it should be clear which roles can send and receive which message types.</p> <p>If the \"Tutorial\" section covers everything about the messages, this section should be deleted.</p>"},{"location":"0000-template-protocol/#examples","title":"Examples","text":"<p>This section is optional. It can be used to show alternate flows through the protocol.</p>"},{"location":"0000-template-protocol/#collateral","title":"Collateral","text":"<p>This section is optional. It could be used to reference files, code, relevant standards, oracles, test suites, or other artifacts that would be useful to an implementer. In general, collateral should be checked in with the RFC.</p>"},{"location":"0000-template-protocol/#localization","title":"Localization","text":"<p>If communication in the protocol involves humans, then localization of message content may be relevant. Default settings for localization of all messages in the protocol can be specified in an <code>l10n.json</code> file described here and checked in with the RFC. See \"Decorators at Message Type Scope\" in the Localization RFC.</p>"},{"location":"0000-template-protocol/#codes-catalog","title":"Codes Catalog","text":"<p>If the protocol has a formally defined catalog of codes (e.g., for errors or for statuses), define them in this section. See \"Message Codes and Catalogs\" in the Localization RFC.</p>"},{"location":"0000-template-protocol/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"0000-template-protocol/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"0000-template-protocol/#prior-art","title":"Prior art","text":"<p>Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:</p> <ul> <li>Does this feature exist in other SSI ecosystems and what experience have their community had?</li> <li>For other teams: What lessons can we learn from other attempts?</li> <li>Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.</li> </ul> <p>This section is intended to encourage you as an author to think about the lessons from other implementers, provide readers of your proposal with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if they are an adaptation from other communities.</p> <p>Note that while precedent set by other communities is some motivation, it does not on its own motivate an enhancement proposal here. Please also take into consideration that Aries sometimes intentionally diverges from common identity features.</p>"},{"location":"0000-template-protocol/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"0000-template-protocol/#implementations","title":"Implementations","text":"<p>NOTE: This section should remain in the RFC as is on first release. Remove this note and leave the rest of the text as is. Template text in all other sections should be removed before submitting your Pull Request.</p> <p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"0000-template/","title":"Title (Ex. 0000: RFC Topic)","text":"<ul> <li>Authors: your name -- email is optional</li> <li>Status: PROPOSED</li> <li>Since: 2019-12-26 (date you submit your PR)</li> <li>Status Note: (explanation of current status)  </li> <li>Supersedes: (link to anything this RFC supersedes)</li> <li>Start Date: 2018-12-26 (date you started working on this idea)</li> <li>Tags: concept</li> </ul>"},{"location":"0000-template/#summary","title":"Summary","text":"<p>One paragraph explanation of the feature.</p> <p>NOTE: If you are creating a protocol RFC, please use this template instead.</p>"},{"location":"0000-template/#motivation","title":"Motivation","text":"<p>Why are we doing this? What use cases does it support? What is the expected outcome?</p>"},{"location":"0000-template/#tutorial","title":"Tutorial","text":"<p>Explain the proposal as if it were already implemented and you were teaching it to another Aries contributor or Aries consumer. That generally means:</p> <ul> <li>Introducing new named concepts.</li> <li>Explaining the feature largely in terms of examples.</li> <li>Explaining how Aries contributors and/or consumers should think about the feature, and how it should impact the way they use the ecosystem.</li> <li>If applicable, provide sample error messages, deprecation warnings, or migration guidance.</li> </ul> <p>Some enhancement proposals may be more aimed at contributors (e.g. for consensus internals); others may be more aimed at consumers.</p>"},{"location":"0000-template/#reference","title":"Reference","text":"<p>Provide guidance for implementers, procedures to inform testing, interface definitions, formal function prototypes, error codes, diagrams, and other technical details that might be looked up. Strive to guarantee that:</p> <ul> <li>Interactions with other features are clear.</li> <li>Implementation trajectory is well defined.</li> <li>Corner cases are dissected by example.</li> </ul>"},{"location":"0000-template/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"0000-template/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"0000-template/#prior-art","title":"Prior art","text":"<p>Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:</p> <ul> <li>Does this feature exist in other SSI ecosystems and what experience have their community had?</li> <li>For other teams: What lessons can we learn from other attempts?</li> <li>Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.</li> </ul> <p>This section is intended to encourage you as an author to think about the lessons from other implementers, provide readers of your proposal with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if they are an adaptation from other communities.</p> <p>Note that while precedent set by other communities is some motivation, it does not on its own motivate an enhancement proposal here. Please also take into consideration that Aries sometimes intentionally diverges from common identity features.</p>"},{"location":"0000-template/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"0000-template/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"LICENSE/","title":"License","text":"<pre><code>                             Apache License\n                       Version 2.0, January 2004\n                    http://www.apache.org/licenses/\n</code></pre> <p>TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION</p> <ol> <li> <p>Definitions.</p> <p>\"License\" shall mean the terms and conditions for use, reproduction,   and distribution as defined by Sections 1 through 9 of this document.</p> <p>\"Licensor\" shall mean the copyright owner or entity authorized by   the copyright owner that is granting the License.</p> <p>\"Legal Entity\" shall mean the union of the acting entity and all   other entities that control, are controlled by, or are under common   control with that entity. For the purposes of this definition,   \"control\" means (i) the power, direct or indirect, to cause the   direction or management of such entity, whether by contract or   otherwise, or (ii) ownership of fifty percent (50%) or more of the   outstanding shares, or (iii) beneficial ownership of such entity.</p> <p>\"You\" (or \"Your\") shall mean an individual or Legal Entity   exercising permissions granted by this License.</p> <p>\"Source\" form shall mean the preferred form for making modifications,   including but not limited to software source code, documentation   source, and configuration files.</p> <p>\"Object\" form shall mean any form resulting from mechanical   transformation or translation of a Source form, including but   not limited to compiled object code, generated documentation,   and conversions to other media types.</p> <p>\"Work\" shall mean the work of authorship, whether in Source or   Object form, made available under the License, as indicated by a   copyright notice that is included in or attached to the work   (an example is provided in the Appendix below).</p> <p>\"Derivative Works\" shall mean any work, whether in Source or Object   form, that is based on (or derived from) the Work and for which the   editorial revisions, annotations, elaborations, or other modifications   represent, as a whole, an original work of authorship. For the purposes   of this License, Derivative Works shall not include works that remain   separable from, or merely link (or bind by name) to the interfaces of,   the Work and Derivative Works thereof.</p> <p>\"Contribution\" shall mean any work of authorship, including   the original version of the Work and any modifications or additions   to that Work or Derivative Works thereof, that is intentionally   submitted to Licensor for inclusion in the Work by the copyright owner   or by an individual or Legal Entity authorized to submit on behalf of   the copyright owner. For the purposes of this definition, \"submitted\"   means any form of electronic, verbal, or written communication sent   to the Licensor or its representatives, including but not limited to   communication on electronic mailing lists, source code control systems,   and issue tracking systems that are managed by, or on behalf of, the   Licensor for the purpose of discussing and improving the Work, but   excluding communication that is conspicuously marked or otherwise   designated in writing by the copyright owner as \"Not a Contribution.\"</p> <p>\"Contributor\" shall mean Licensor and any individual or Legal Entity   on behalf of whom a Contribution has been received by Licensor and   subsequently incorporated within the Work.</p> </li> <li> <p>Grant of Copyright License. Subject to the terms and conditions of       this License, each Contributor hereby grants to You a perpetual,       worldwide, non-exclusive, no-charge, royalty-free, irrevocable       copyright license to reproduce, prepare Derivative Works of,       publicly display, publicly perform, sublicense, and distribute the       Work and such Derivative Works in Source or Object form.</p> </li> <li> <p>Grant of Patent License. Subject to the terms and conditions of       this License, each Contributor hereby grants to You a perpetual,       worldwide, non-exclusive, no-charge, royalty-free, irrevocable       (except as stated in this section) patent license to make, have made,       use, offer to sell, sell, import, and otherwise transfer the Work,       where such license applies only to those patent claims licensable       by such Contributor that are necessarily infringed by their       Contribution(s) alone or by combination of their Contribution(s)       with the Work to which such Contribution(s) was submitted. If You       institute patent litigation against any entity (including a       cross-claim or counterclaim in a lawsuit) alleging that the Work       or a Contribution incorporated within the Work constitutes direct       or contributory patent infringement, then any patent licenses       granted to You under this License for that Work shall terminate       as of the date such litigation is filed.</p> </li> <li> <p>Redistribution. You may reproduce and distribute copies of the       Work or Derivative Works thereof in any medium, with or without       modifications, and in Source or Object form, provided that You       meet the following conditions:</p> <p>(a) You must give any other recipients of the Work or       Derivative Works a copy of this License; and</p> <p>(b) You must cause any modified files to carry prominent notices       stating that You changed the files; and</p> <p>\u00a9 You must retain, in the Source form of any Derivative Works       that You distribute, all copyright, patent, trademark, and       attribution notices from the Source form of the Work,       excluding those notices that do not pertain to any part of       the Derivative Works; and</p> <p>(d) If the Work includes a \"NOTICE\" text file as part of its       distribution, then any Derivative Works that You distribute must       include a readable copy of the attribution notices contained       within such NOTICE file, excluding those notices that do not       pertain to any part of the Derivative Works, in at least one       of the following places: within a NOTICE text file distributed       as part of the Derivative Works; within the Source form or       documentation, if provided along with the Derivative Works; or,       within a display generated by the Derivative Works, if and       wherever such third-party notices normally appear. The contents       of the NOTICE file are for informational purposes only and       do not modify the License. You may add Your own attribution       notices within Derivative Works that You distribute, alongside       or as an addendum to the NOTICE text from the Work, provided       that such additional attribution notices cannot be construed       as modifying the License.</p> <p>You may add Your own copyright statement to Your modifications and   may provide additional or different license terms and conditions   for use, reproduction, or distribution of Your modifications, or   for any such Derivative Works as a whole, provided Your use,   reproduction, and distribution of the Work otherwise complies with   the conditions stated in this License.</p> </li> <li> <p>Submission of Contributions. Unless You explicitly state otherwise,       any Contribution intentionally submitted for inclusion in the Work       by You to the Licensor shall be under the terms and conditions of       this License, without any additional terms or conditions.       Notwithstanding the above, nothing herein shall supersede or modify       the terms of any separate license agreement you may have executed       with Licensor regarding such Contributions.</p> </li> <li> <p>Trademarks. This License does not grant permission to use the trade       names, trademarks, service marks, or product names of the Licensor,       except as required for reasonable and customary use in describing the       origin of the Work and reproducing the content of the NOTICE file.</p> </li> <li> <p>Disclaimer of Warranty. Unless required by applicable law or       agreed to in writing, Licensor provides the Work (and each       Contributor provides its Contributions) on an \"AS IS\" BASIS,       WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or       implied, including, without limitation, any warranties or conditions       of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A       PARTICULAR PURPOSE. You are solely responsible for determining the       appropriateness of using or redistributing the Work and assume any       risks associated with Your exercise of permissions under this License.</p> </li> <li> <p>Limitation of Liability. In no event and under no legal theory,       whether in tort (including negligence), contract, or otherwise,       unless required by applicable law (such as deliberate and grossly       negligent acts) or agreed to in writing, shall any Contributor be       liable to You for damages, including any direct, indirect, special,       incidental, or consequential damages of any character arising as a       result of this License or out of the use or inability to use the       Work (including but not limited to damages for loss of goodwill,       work stoppage, computer failure or malfunction, or any and all       other commercial damages or losses), even if such Contributor       has been advised of the possibility of such damages.</p> </li> <li> <p>Accepting Warranty or Additional Liability. While redistributing       the Work or Derivative Works thereof, You may choose to offer,       and charge a fee for, acceptance of support, warranty, indemnity,       or other liability obligations and/or rights consistent with this       License. However, in accepting such obligations, You may act only       on Your own behalf and on Your sole responsibility, not on behalf       of any other Contributor, and only if You agree to indemnify,       defend, and hold each Contributor harmless for any liability       incurred by, or claims asserted against, such Contributor by reason       of your accepting any such warranty or additional liability.</p> </li> </ol> <p>END OF TERMS AND CONDITIONS</p> <p>APPENDIX: How to apply the Apache License to your work.</p> <pre><code>  To apply the Apache License to your work, attach the following\n  boilerplate notice, with the fields enclosed by brackets \"[]\"\n  replaced with your own identifying information. (Don't include\n  the brackets!)  The text should be enclosed in the appropriate\n  comment syntax for the file format. We also recommend that a\n  file or class name and description of purpose be included on the\n  same \"printed page\" as the copyright notice for easier\n  identification within third-party archives.\n</code></pre> <p>Copyright [yyyy] [name of copyright owner]</p> <p>Licensed under the Apache License, Version 2.0 (the \"License\");    you may not use this file except in compliance with the License.    You may obtain a copy of the License at</p> <pre><code>   http://www.apache.org/licenses/LICENSE-2.0\n</code></pre> <p>Unless required by applicable law or agreed to in writing, software    distributed under the License is distributed on an \"AS IS\" BASIS,    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.    See the License for the specific language governing permissions and    limitations under the License.</p>"},{"location":"MAINTAINERS/","title":"Maintainers","text":""},{"location":"MAINTAINERS/#active-maintainers","title":"Active Maintainers","text":"Name Github LFID Daniel Hardman dhh1128 George Aristy llorllale Nathan George nage Stephen Curran swcurran Drummond Reed talltree Sam Curren TelegramSam"},{"location":"MAINTAINERS/#emeritus-maintainers","title":"Emeritus Maintainers","text":"Name Github LFID"},{"location":"MAINTAINERS/#becoming-a-maintainer","title":"Becoming a Maintainer","text":"<p>The Aries community welcomes contributions. Contributors may progress to become a maintainer. To become a maintainer the following steps occur, roughly in order.</p> <ul> <li>5 significant changes have been authored by the proposed maintainer and   accepted.</li> <li>The proposed maintainer has the sponsorship of at least one other maintainer.</li> <li>This sponsoring maintainer will create a PR modifying the list of     maintainers.</li> <li>The proposed maintainer accepts the nomination and expresses a willingness     to be a long-term (more than 6 month) committer.</li> <li>This would be a comment in the above PR.</li> <li>This PR will be communicated in all appropriate communication channels. It     should be mentioned in any maintainer/community call. It should also be     posted to the appropriate mailing list or chat channels if they exist.</li> <li>Approval by at least 3 current maintainers within two weeks of the proposal or   an absolute majority of current maintainers.</li> <li>These votes will be recorded in the PR modifying the list of maintainers.</li> <li>No veto by another maintainer within two weeks of proposal are recorded.</li> <li>All vetoes must be accompanied by a public explanation as a comment in the     PR for adding this maintainer</li> <li>The explanation of the veto must be reasonable.</li> <li>A veto can be retracted, in that case the approval/veto timeframe is reset.</li> <li>It is bad form to veto, retract, and veto again.</li> <li>The proposed maintainer becomes a maintainer</li> <li>Either two weeks have passed since the third approval,</li> <li>Or an absolute majority of maintainers approve.</li> <li>In either case, no maintainer presents a veto.</li> </ul>"},{"location":"MAINTAINERS/#removing-maintainers","title":"Removing Maintainers","text":"<p>Being a maintainer is not a status symbol or a title to be maintained indefinitely. It will occasionally be necessary and appropriate to move a maintainer to emeritus status. This can occur in the following situations:</p> <ul> <li>Resignation of a maintainer.</li> <li>Violation of the Code of Conduct warranting removal.</li> <li>Inactivity.</li> <li>A general measure of inactivity will be no commits or code review comments     for one reporting quarter, although this will not be strictly enforced if     the maintainer expresses a reasonable intent to continue contributing.</li> <li>Reasonable exceptions to inactivity will be granted for known long term     leave such as parental leave and medical leave.</li> <li>Other unspecified circumstances.</li> </ul> <p>Like adding a maintainer the record and governance process for moving a maintainer to emeritus status is recorded in the github PR making that change.</p> <p>Returning to active status from emeritus status uses the same steps as adding a new maintainer. Note that the emeritus maintainer already has the 5 required significant changes as there is no contribution time horizon for those.</p>"},{"location":"RFCindex/","title":"Aries RFCs by Status","text":""},{"location":"RFCindex/#adopted","title":"ADOPTED","text":"<ul> <li>0003: Protocols (2019-04-01, 10 impls \u2014 <code>concept</code>)</li> <li>0005: DID Communication (2019-11-21, 10 impls \u2014 <code>concept</code>)</li> <li>0008: Message ID and Threading (2018-10-01, 5 impls \u2014 <code>concept</code>)</li> <li>0011: Decorators (2019-01-31, 10 impls \u2014 <code>concept</code> <code>decorator</code>)</li> <li>0015: ACKs (2024-05-01, 4 impls \u2014 <code>feature</code>)</li> <li>0017: Attachments (2024-05-01, 2 impls \u2014 <code>concept</code>)</li> <li>0019: Encryption Envelope (2019-05-04, 7 impls \u2014 <code>feature</code>)</li> <li>0020: Message Types (2019-05-24, 8 impls \u2014 <code>concept</code>)</li> <li>0021: DIDComm Message Anatomy (2019-05-25 \u2014 <code>concept</code> <code>decorator</code>)</li> <li>0023: DID Exchange v1 (2021-04-15, 1 impl \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0025: DIDComm Transports (2019-12-05 \u2014 <code>feature</code>)</li> <li>0031: Discover Features Protocol 1.0 (2019-05-01, 2 impls \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0035: Report Problem Protocol 1.0 (2024-05-01, 3 impls \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0036: Issue Credential Protocol 1.0 (2019-05-28, 1 impl \u2014 <code>feature</code> <code>decorator</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> <li>0037: Present Proof Protocol 1.0 (2019-05-28, 1 impl \u2014 <code>feature</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> <li>0048: Trust Ping Protocol 1.0 (2019-02-01, 6 impls \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0092: Transports Return Route (2024-05-01, 2 impls \u2014 <code>feature</code>)</li> <li>0094: Cross-Domain Messaging (2024-05-01 \u2014 <code>concept</code>)</li> <li>0095: Basic Message Protocol 1.0 (2019-08-06, 6 impls \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0160: Connection Protocol (2019-08-06, 6 impls \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0211: Mediator Coordination Protocol (2024-05-01, 2 impls \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0302: Aries Interop Profile (2021-01-06 \u2014 <code>concept</code>)</li> <li>0360: did:key Usage (2024-05-01 \u2014 <code>feature</code>)</li> <li>0434: Out-of-Band Protocol 1.1 (2020-03-01 \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0441: Prover and Verifier Best Practices for Proof Presentation (2024-05-01 \u2014 <code>concept</code> <code>credentials</code>)</li> <li>0453: Issue Credential Protocol 2.0 (2021-04-15 \u2014 <code>feature</code> <code>decorator</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> <li>0454: Present Proof Protocol 2.0 (2021-04-15 \u2014 <code>feature</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> <li>0496: Transition to the Out of Band Protocol (2021-11-24 \u2014 <code>feature</code> <code>community-update</code> <code>test-anomaly</code>)</li> <li>0510: Presentation-Exchange Attachment format for requesting and presenting proofs (2020-07-21 \u2014 <code>feature</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> <li>0557: Discover Features Protocol v2.x (2024-05-01 \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0592: Indy Attachment Formats for Requesting and Presenting Credentials (2021-04-15 \u2014 <code>feature</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> <li>0593: JSON-LD Credential Attachment format for requesting and issuing credentials (2021-04-15 \u2014 <code>feature</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> </ul>"},{"location":"RFCindex/#accepted","title":"ACCEPTED","text":"<ul> <li>0004: Agents (2019-01-15, 11 impls \u2014 <code>concept</code>)</li> <li>0006: SSI Notation (2018-09-01, 1 impl \u2014 <code>concept</code>)</li> <li>0044: DIDComm File and MIME Types (2021-04-15 \u2014 <code>feature</code>)</li> <li>0046: Mediators and Relays (2019-02-01, 3 impls \u2014 <code>concept</code>)</li> <li>0047: JSON-LD Compatibility (2019-02-20 \u2014 <code>concept</code> <code>decorator</code>)</li> <li>0049: Repudiation (2019-03-01 \u2014 <code>concept</code>)</li> <li>0050: Wallets (2018-07-01, 1 impl \u2014 <code>concept</code>)</li> <li>0183: Revocation Notification 1.0 (2024-05-01 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0519: Goal Codes (2021-04-15 \u2014 <code>concept</code>)</li> <li>0587: Encryption Envelope v2 (2021-04-15 \u2014 <code>feature</code>)</li> <li>0646: W3C Credential Exchange using BBS+ Signatures (2021-04-28 \u2014 <code>feature</code>)</li> <li>0685: Pickup Protocol 2.0 (2024-05-01 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0721: Revocation Notification 2.0 (2024-05-01 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0793: Unqualified DID Transition (2023-07-11, 12 impls \u2014 <code>feature</code> <code>community-update</code>)</li> <li>0794: DID Rotate 1.0 (2024-03-02 \u2014 <code>feature</code> <code>protocol</code>)</li> </ul>"},{"location":"RFCindex/#demonstrated","title":"DEMONSTRATED","text":"<ul> <li>0032: Message Timing (2019-05-01, 1 impl \u2014 <code>feature</code>)</li> <li>0042: LOX -- A more secure pluggable framework for protecting wallet keys (2019-05-30, 1 impl \u2014 <code>feature</code>)</li> <li>0043: l10n (Locali[s|z]ation) (2019-04-01, 4 impls \u2014 <code>feature</code> <code>decorator</code>)</li> <li>0113: Question Answer Protocol 0.9 (2019-07-05, 2 impls \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0509: Action Menu Protocol (2020-07-02 , 1 impl \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0748: N-wise DID Exchange Protocol 1.0 (2022-08-03, 1 impl \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0755: Overlays Capture Architecture (OCA) For Aries (2024-03-02 \u2014 <code>feature</code>)</li> <li>0756: OCA for Aries Style Guide (2023-01-05 \u2014 <code>feature</code>)</li> <li>0780: Use Data URLs for Images and More in Credential Attributes (2024-03-02 \u2014 <code>feature</code>)</li> <li>0804: DIDComm Remote Procedure Call (DRPC) (2024-03-02 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0809: W3C Verifiable Credential Data Integrity Attachment format for requesting and issuing credentials (2024-01-10 \u2014 <code>feature</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> </ul>"},{"location":"RFCindex/#proposed","title":"PROPOSED","text":"<ul> <li>0028: Introduce Protocol 1.0 (2019-04-15 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0034: Message Tracing (2018-10-24 \u2014 <code>feature</code> <code>decorator</code>)</li> <li>0056: Service Decorator (2019-06-03 \u2014 <code>feature</code> <code>decorator</code>)</li> <li>0066: Non-Repudiable Signature for Cryptographic Envelope (2019-04-15 \u2014 <code>feature</code>)</li> <li>0067: DIDComm DID document conventions (2019-06-10 \u2014 <code>feature</code>)</li> <li>0074: DIDComm Best Practices (2019-06-10 \u2014 <code>concept</code>)</li> <li>0103: Indirect Identity Control (2019-06-04 \u2014 <code>concept</code> <code>credentials</code>)</li> <li>0104: Chained Credentials (2019-09-09 \u2014 <code>concept</code> <code>credentials</code>)</li> <li>0124: DID Resolution Protocol 0.9 (2019-07-13 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0167: Data Consent Lifecycle (2019-08-07 (updated 2019-03-16) \u2014 <code>concept</code>)</li> <li>0212: Pickup Protocol (2019-09-03 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0213: Transfer Policy Protocol (2019-09-03 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0214: \"Help Me Discover\" Protocol (2019-09-10 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0231: Biometric Service Provider (2019-09-24 \u2014 <code>concept</code>)</li> <li>0268: Unified DIDCOMM Deeplinking (2019-10-23 \u2014 <code>concept</code>)</li> <li>0270: Interop Test Suite (2019-10-25 \u2014 <code>concept</code>)</li> <li>0345: Community Coordinated Update (2019-12-26 (date you submit your PR) \u2014 <code>concept</code>)</li> <li>0346: DIDComm Between Two Mobile Agents Using Cloud Agent Mediator (2019-06-23 \u2014 <code>concept</code>)</li> <li>0347: Proof Negotiation (2019-12-13 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0430: Machine-Readable Governance Frameworks (2020-02-24 \u2014 <code>concept</code>)</li> <li>0440: KMS Architectures  (2020-03-06 \u2014 <code>concept</code>)</li> <li>0511: Credential-Manifest Attachment format for requesting and presenting credentials (2020-07-22 \u2014 <code>feature</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> <li>0559: Privacy-Preserving Proof of Uniqueness (2020-10-21 \u2014 <code>concept</code>)</li> <li>0566: Issuer-Hosted Custodial Agents (2020-11-16 \u2014 <code>concept</code>)</li> <li>0641: Linking binary objects to credentials using hash based references (2021-04-22 \u2014 <code>feature</code> <code>credentials</code>)</li> <li>0693: Cross-Platform Credential Representation (2021-07-06 \u2014 <code>feature</code>)</li> <li>0699: Push Notifications apns Protocol 1.0 (2021-10-07 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0700: Out-of-Band through redirect (2021-10-08 \u2014 <code>concept</code> <code>decorator</code>)</li> <li>0728: Device Binding Attachments (2022-04-07 \u2014 <code>feature</code>)</li> <li>0734: Push Notifications fcm Protocol 1.0 (2022-05-12 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0757: Push Notification (2022-11-02  \u2014 <code>concept</code>)</li> <li>0771: AnonCreds Attachment Formats for Requesting and Presenting Credentials (2023-02-24 \u2014 <code>feature</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> <li>0799: Aries Long Term Support Releases (2023-11-07  \u2014 <code>concept</code>)</li> </ul>"},{"location":"RFCindex/#stalled","title":"STALLED","text":"<ul> <li>0024: DIDComm over XMPP (2024-04-03 \u2014 <code>feature</code>)</li> <li>0029: Message Trust Contexts (2024-04-03, 3 impls \u2014 <code>concept</code>)</li> <li>0030: Sync Connection Protocol 1.0 (2024-04-03 \u2014 <code>feature</code> <code>decorator</code> <code>protocol</code>)</li> <li>0075: Payment Decorators (2024-04-03 \u2014 <code>feature</code> <code>decorator</code>)</li> <li>0114: Predefined Identities (2024-04-03 \u2014 <code>feature</code>)</li> <li>0116: Evidence Exchange Protocol 0.9 (2024-04-03 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0193: Coin Flip Protocol 1.0  (2024-04-03 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0207: Credential Fraud Threat Model (2024-04-03 \u2014 <code>concept</code> <code>credentials</code>)</li> <li>0217: Linkable Message Paths (2024-04-03 \u2014 <code>concept</code>)</li> <li>0249: Aries Rich Schema Contexts (2024-04-03 \u2014 <code>feature</code> <code>rich-schemas</code>)</li> <li>0250: Rich Schema Objects (2024-04-03 \u2014 <code>concept</code> <code>rich-schemas</code>)</li> <li>0257: Private Credential Issuance (2024-04-03 \u2014 <code>concept</code> <code>protocol</code>)</li> <li>0281: Aries Rich Schemas (2024-04-03 \u2014 <code>feature</code> <code>rich-schemas</code>)</li> <li>0289: The Trust Over IP Stack (2024-04-03 \u2014 <code>concept</code> <code>stack</code> <code>trust layer</code> <code>governance framework</code>)</li> <li>0309: DIDAuthZ (2024-04-03 \u2014 <code>feature</code> <code>credentials</code>)</li> <li>0327: Crypto service Protocol 1.0 (2024-04-03 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0334: JWE envelope 1.0 (2024-04-03 \u2014 <code>feature</code>)</li> <li>0335: HTTP Over DIDComm (2024-04-03 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0351: Purpose Decorator (2024-04-03 \u2014 <code>feature</code> <code>decorator</code>)</li> <li>0418: Aries Rich Schema Encoding Objects (2024-04-03 \u2014 <code>feature</code> <code>rich-schemas</code>)</li> <li>0420: Rich Schema Objects Common (2024-04-03 \u2014 <code>concept</code> <code>rich-schemas</code>)</li> <li>0428: Prerequisites to Issue Rich Credential (2024-04-03 \u2014 <code>feature</code> <code>rich-schemas</code>)</li> <li>0429: Prerequisites to Request Rich Presentation (2024-04-03 \u2014 <code>feature</code> <code>rich-schemas</code>)</li> <li>0445: Aries Rich Schema Mapping (2024-04-03 \u2014 <code>feature</code> <code>rich-schemas</code>)</li> <li>0446: Aries Rich Schema Credential Definition (2024-04-03 \u2014 <code>feature</code> <code>rich-schemas</code>)</li> <li>0478: Coprotocols (2024-04-03 \u2014 <code>concept</code> <code>protocol</code>)</li> <li>0482: Coprotocol Protocol 0.5 (2024-04-03 \u2014 <code>feature</code> <code>protocol</code>)</li> </ul>"},{"location":"RFCindex/#retired","title":"RETIRED","text":"<ul> <li>0013: Overlays (2023-01-15 \u2014 <code>concept</code>)</li> <li>0051: Decentralized Key Management (2024-04-03, 2 impls \u2014 <code>concept</code>)</li> <li>0234: Signature Decorator (2020-10-14, 3 impls \u2014 <code>feature</code> <code>decorator</code>)</li> <li>0303: V0.1 Credential Exchange (Deprecated) (2019-11-12, 4 impls \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0317: Please ACK Decorator (2019-12-26 \u2014 <code>feature</code> <code>decorator</code>)</li> <li>0348: Transition Message Type to HTTPs (2020-08-26, 14 impls \u2014 <code>feature</code> <code>community-update</code>)</li> <li>0627: Static Peer DIDs (2021-04-07 \u2014 <code>feature</code>)</li> </ul> <p>(This file is machine-generated; see code/generate_index.py.)</p>"},{"location":"SECURITY/","title":"Hyperledger Security Policy","text":""},{"location":"SECURITY/#reporting-a-security-bug","title":"Reporting a Security Bug","text":"<p>If you think you have discovered a security issue in any of the Hyperledger projects, we'd love to hear from you. We will take all security bugs seriously and if confirmed upon investigation we will patch it within a reasonable amount of time and release a public security bulletin discussing the impact and credit the discoverer.</p> <p>There are two ways to report a security bug. The easiest is to email a description of the flaw and any related information (e.g. reproduction steps, version) to security at hyperledger dot org.</p> <p>The other way is to file a confidential security bug in our JIRA bug tracking system. Be sure to set the \u201cSecurity Level\u201d to \u201cSecurity issue\u201d.</p> <p>The process by which the Hyperledger Security Team handles security bugs is documented further in our Defect Response page on our wiki.</p>"},{"location":"contributing/","title":"Contributing","text":""},{"location":"contributing/#contributing","title":"Contributing","text":""},{"location":"contributing/#do-you-need-an-rfc","title":"Do you need an RFC?","text":"<p>Use an RFC to advocate substantial changes to the Aries ecosystem, where those changes need to be understood by developers who use Aries. Minor changes are not RFC-worthy, and changes that are internal in nature, invisible to those consuming Aries, should be documented elsewhere.</p>"},{"location":"contributing/#preparation","title":"Preparation","text":"<p>Before writing an RFC, consider exploring the idea on the aries chat channel, on community calls (see the Hyperledger Community Calendar), or on aries@lists.hyperledger.org. Encouraging feedback from maintainers is a good sign that you're on the right track.</p>"},{"location":"contributing/#how-to-propose-an-rfc","title":"How to propose an RFC","text":"<ul> <li>Fork the RFC repo.</li> <li>Pick a descriptive folder name for your RFC. Don't pick a number yet.     See Best Practices: RFC Naming     for guidance.</li> <li>Decide which parent folder is appropriate for your RFC.     If it is about a specific protocol or decorator or feature, its parent     should be <code>/features</code>; if it is about a concept that will be used in many     different features, its parent should be <code>/concepts</code>.</li> <li>Create the folder and copy either <code>0000-template.md</code> or <code>0000-template-protocol.md</code> (if your RFC is for a protocol) to <code>&lt;parent&gt;/&lt;your folder name&gt;/README.md</code>.</li> <li>Fill in the RFC. Use MUST and SHOULD per standard conventions. Put care into the details: RFCs that do not present     convincing motivation, demonstrate an understanding of the impact of the     design, or are disingenuous about the drawbacks or alternatives tend to be     poorly received. You can add supporting artifacts, such as diagrams and sample     data, in the RFC's folder. Make sure you follow community-endorsed best     practices.</li> <li>Consider how the RFC should be tagged.</li> <li>Assign a number to your RFC. Get the number by loading this web page (or,     if you want to do it the hard way, by inspecting open and closed PRs against     this repo to figure out what the next PR number will be). Rename your folder from     <code>&lt;your folder name&gt;</code> to <code>&lt;your 4-digit number&gt;-&lt;your folder name&gt;</code>. At the     top of your README.md, modify the title so it is in the form: <code>&lt;your 4-digit     number&gt;: Friendly Version of Your Title</code>.</li> <li>Commit and push your changes.</li> <li>Submit a pull request.</li> </ul> <p>Make sure that all of your commits satisfy the DCO requirements of the repo and conform to the license restrictions noted below.</p> <p>The RFC Maintainers will check to see if the process has been followed, and request any process changes before merging the PR.</p> <p>When the PR is merged, your RFC is now formally in the PROPOSED state.</p>"},{"location":"contributing/#changing-an-rfc-status","title":"Changing an RFC Status","text":"<p>The lifecycle of an RFC is driven by the author or current champion of the RFC. To move an RFC along in the lifecycle, submit a PR with the following characteristics:</p> <ul> <li>The PR should ONLY change the RFC status. Note that this requires refreshing the index (<code>python code/generate_index.py &amp;&amp; pytest code</code>).</li> <li>The title of the PR should include a deadline date for merging the PR and the referenced RFC.</li> <li>Example: <code>Status to Accepted, deadline 2019.08.15, RFC 0095-basic-message</code></li> <li>The PR comment should document why the status is being changed.</li> <li>The deadline date should be 2 weeks after announcing the proposed status change on an Aries WG call. The PR should also be announced on the #aries  channel.</li> <li>Barring negative feedback from the community, the repo's maintainers should merge the PR after the deadline.</li> <li>The deadline should be moved by two weeks after addressing each substantive change to the RFC made during the status change review period.</li> </ul>"},{"location":"contributing/#how-to-get-an-rfc-demonstrated","title":"How to get an RFC demonstrated","text":"<p>If your RFC is a feature, it's common (though not strictly required) for it to go to a DEMONSTRATED state next. Write some code that embodies the concepts in the RFC. Publish the code. Then submit a PR that adds your early implementation to the Implementations section, and that changes the status to DEMONSTRATED. These PRs should be accepted immediately, as long as all unit tests pass.</p>"},{"location":"contributing/#how-to-get-an-rfc-accepted","title":"How to get an RFC accepted","text":"<p>After your RFC is merged and officially acquires the PROPOSED status, the RFC will receive feedback from the larger community, and the author should be prepared to revise it. Updates may be made via pull request, and those changes will be merged as long as the process is followed.</p> <p>When you believe that the RFC is mature enough (feedback is somewhat resolved, consensus is emerging, and implementation against it makes sense), submit a PR that changes the status to ACCEPTED. The status change PR will remain open until the maintainers agree on the status change.</p> <p>NOTE: contributors who used the Indy HIPE process prior to May 2019 should see the acceptance process substantially simplified under this approach. The bar for acceptance is not perfect consensus and all issues resolved; it's just general agreement that a doc is \"close enough\" that it makes sense to put it on a standards track where it can be improved as implementation teaches us what to tweak.</p>"},{"location":"contributing/#how-to-get-an-rfc-adopted","title":"How to get an RFC adopted","text":"<p>An accepted RFC is a standards-track document. It becomes an acknowledged standard when there is evidence that the community is deriving meaningful value from it. So:</p> <ul> <li>Implement the ideas, and find out who else is implementing.</li> <li>Socialize the ideas. Use them in other RFCs and documentation.</li> <li>Update the agent test suite to reflect the ideas.</li> </ul> <p>When you believe an RFC is a de facto standard, raise a PR that changes the status to ADOPTED.  If the community is friendly to the idea, the doc will enter a two-week \"Final Comment Period\" (FCP), after which there will be a vote on disposition.</p>"},{"location":"contributing/#intellectual-property","title":"Intellectual Property","text":"<p>This repository is licensed under an Apache 2 License. It is protected by a Developer Certificate of Origin on every commit. This means that any contributions you make must be licensed in an Apache-2-compatible way, and must be free from patent encumbrances or additional terms and conditions. By raising a PR, you certify that this is the case for your contribution.</p>"},{"location":"contributing/#signing-off-commits-dco","title":"Signing off commits (DCO)","text":"<p>If you are here because you forgot to sign off your commits, fear not. Check out how to sign off previous commits</p> <p>We use developer certificate of origin (DCO) in all Hyperledger repositories, so to get your pull requests accepted, you must certify your commits by signing off on each commit.</p>"},{"location":"contributing/#signing-off-your-current-commit","title":"Signing off your current commit","text":"<ul> <li><code>$ git commit -s -m \"your commit message\"</code></li> <li>To see if your commits have been signed off, run <code>$ git log</code>. Any commits including a line with <code>Signed-off-by: Example Author &lt;author.email@example.com&gt;</code> are signed off.</li> <li>If you need to re-sign the most current commit, use <code>$ git commit --amend --no-edit -s</code>.</li> </ul> <p>The <code>-s</code> flag signs off the commit message with your name and email.</p>"},{"location":"contributing/#how-to-sign-off-previous-commits","title":"How to Sign Off Previous Commits","text":"<ol> <li>Use <code>$ git log</code> to see which commits need to be signed off. Any commits missing a line with <code>Signed-off-by: Example Author &lt;author.email@example.com&gt;</code> need to be re-signed.</li> <li>Go into interactive rebase mode using <code>$ git rebase -i HEAD~X</code> where X is the number of commits up to the most current commit you would like to see.</li> <li>You will see a list of the commits in a text file. On the line after each commit you need to sign off, add <code>exec git commit --amend --no-edit -s</code> with the lowercase <code>-s</code> adding a text signature in the commit body. Example that signs both commits:</li> </ol> <pre><code>pick 12345 commit message\nexec git commit --amend --no-edit -s\npick 67890 commit message\nexec git commit --amend --no-edit -s\n</code></pre> <ol> <li> <p>If you need to re-sign a bunch of previous commits at once, find the earliest commit missing the sign off line using <code>$ git log</code> and use that the HASH of the commit before it in this command:    <pre><code> $ git rebase --exec 'git commit --amend --no-edit -n -s' -i HASH.\n</code></pre>    This will sign off every commit from most recent to right before the HASH.</p> </li> <li> <p>You will probably need to do a force push (<code>$ git push -f</code>) if you had previously pushed unsigned commits to remote.</p> </li> </ol>"},{"location":"github-issues/","title":"Submitting Issues","text":""},{"location":"github-issues/#github-issues","title":"Github Issues","text":"<p>RFCs that are not on the brink of changing status are discussed through Github Issues. We generally use Issues to discuss changes that are controversial, and PRs to propose changes that are vetted. This keeps the PR backlog small.</p> <p>Any community member can open an issue; specify the RFC number in the issue title so the relationship is clear. For example, to open an issue on RFC 0025, an appropriate title for the issue might be:</p> <pre><code>RFC 0025: Need better diagram in Reference section\n</code></pre> <p>When the community feels that it's reasonable to suggest a formal status change for an RFC, best efforts are made to resolve all open issues against it. Then a PR is raised against the RFC's main README.md, where the status field in the header is updated. Discussion about the status change typically takes place in the comment stream for the PR, with issues being reserved for non-status-change topics.</p>"},{"location":"tags/","title":"Tags on RFCs","text":"<p>We categorize RFCs with tags to enrich searches. The meaning of tags is given below.</p>"},{"location":"tags/#protocol","title":"<code>protocol</code>","text":"<p>Defines one or more protocols that explain how messages are passed to accomplish a stateful interaction.</p>"},{"location":"tags/#decorator","title":"<code>decorator</code>","text":"<p>Defines one or more decorators that act as mixins to DIDComm messages. Decorators can be added to many different message types without explicitly declaring them in message schemas.</p>"},{"location":"tags/#feature","title":"<code>feature</code>","text":"<p>Defines a specific, concrete feature that agents might support.</p>"},{"location":"tags/#concept","title":"<code>concept</code>","text":"<p>Defines a general aspect of the Aries mental model, or a pattern that manifests in many different features.</p>"},{"location":"tags/#community-update","title":"<code>community-update</code>","text":"<p>An RFC that tracks a community-coordinated update, as described in RFC 0345. Such updates enable independently deployed, interoperable agents to remain interoperable throughout the transition.</p>"},{"location":"tags/#credentials","title":"<code>credentials</code>","text":"<p>Relates to verifiable credentials.</p>"},{"location":"tags/#rich-schemas","title":"<code>rich-schemas</code>","text":"<p>Relates to next-generation schemas, such as those used by https://schema.org, as used in verifiable credentials.</p>"},{"location":"tags/#test-anomaly","title":"<code>test-anomaly</code>","text":"<p>Violates some aspect of our policy on writing tests for protocols before allowing their status to progress beyond DEMONSTRATED. RFCs should only carry this tag temporarily, to grandfather something where test improvements are happening in the background. When this tag is applied to an RFC, unit tests run by our CI/CD pipeline will emit a warning rather than an error about missing tests, IFF each implementation that lacks tests formats its notes about test results like this:</p> <pre><code>name of impl | [MISSING test results](/tags.md#test-anomaly)\n</code></pre>"},{"location":"aip2/0003-protocols/","title":"Aries RFC 0003: Protocols","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-04-01</li> <li>Status Note: standards track and beginning to influence many mental models, but not yet ADOPTED.</li> <li>Supersedes: Indy PR #69</li> <li>Start Date: 2018-12-28</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0003-protocols/#summary","title":"Summary","text":"<p>Defines peer-to-peer application-level protocols in the context of interactions among agent-like things, and shows how they should be designed and documented.</p> <p></p>"},{"location":"aip2/0003-protocols/#table-of-contents","title":"Table of Contents","text":"<ul> <li>Aries RFC 0003: Protocols</li> <li>Summary</li> <li>Motivation</li> <li>Tutorial<ul> <li>What is a Protocol?</li> <li>Relationship to APIs</li> <li>Decentralized</li> <li>Types of Protocols</li> <li>Agent Design</li> <li>Composable</li> <li>Message Types</li> <li>Handling Unrecognized Items in Messages</li> <li>Ingredients</li> <li>How to Define a Protocol</li> <li>Security Considerations</li> <li>Replay Attacks</li> </ul> </li> <li>Reference<ul> <li>Message Type and Protocol Identifier URIs</li> <li>MTURI</li> <li>PIURI</li> <li>Semver Rules for Protocols</li> <li>Semver Examples<ul> <li>Initiator</li> <li>Recipient Rules</li> </ul> </li> <li>State Details and State Machines</li> <li>State Machines</li> <li>Processing Points</li> <li>Roles, Participants, Parties, and Controllers</li> <li>Roles</li> <li>Participants</li> <li>Parties</li> <li>Controllers</li> <li>Instructions for Protocol RFCs</li> </ul> </li> <li>Drawbacks</li> <li>Rationale and alternatives</li> <li>Prior art<ul> <li>BPMN</li> <li>WSDL</li> <li>Swagger / OpenAPI</li> <li>Other</li> </ul> </li> <li>Unresolved questions</li> <li>Implementations</li> </ul>"},{"location":"aip2/0003-protocols/#motivation","title":"Motivation","text":"<p>APIs in the style of Swagger are familiar to nearly all developers, and it's a common assumption that we should use them to solve the problems at hand in the decentralized identity space. However, to truly decentralize, we must think about interactions at a higher level of generalization. Protocols can model all APIs, but not the other way around. This matters. We need to explain why.</p> <p>We also need to show how a protocol is defined, so the analog to defining a Swagger API is demystified.</p>"},{"location":"aip2/0003-protocols/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0003-protocols/#what-is-a-protocol","title":"What is a Protocol?","text":"<p>A protocol is a recipe for a stateful interaction. Protocols are all around us, and are so ordinary that we take them for granted. Each of the following interactions is stateful, and has conventions that constitute a sort of \"recipe\":</p> <ul> <li>Ordering food at a restaurant</li> <li>Buying a house</li> <li>Playing a game of chess, checkers, tic-tac-toe, etc.</li> <li>Bidding on an item in an online auction.</li> <li>Going through security at the airport when we fly</li> <li>Applying for a loan</li> </ul> <p>In the context of decentralized identity, protocols manifest at many different levels of the stack: at the lowest levels of networking, in cryptographic algorithms like Diffie Hellman, in the management of DIDs, in the conventions of DIDComm, and in higher-level interactions that solve problems for people with only minimal interest in the technology they're using. However, this RFC focuses on the last of these layers, where use cases and personas are transformed into ../../features with obvious social value like:</p> <ul> <li>Connecting with one another</li> <li>Requesting and issuing credentials</li> <li>Proving things using credentials</li> <li>Discovering things</li> <li>Delegating</li> <li>Buying and Selling</li> <li>Negotiating</li> <li>Enacting and enforcing contracts</li> <li>Putting things in escrow (and taking them out again)</li> <li>Scheduling</li> <li>Auditing</li> <li>Reporting errors</li> <li>Cooperative debugging</li> </ul> <p>When \"protocol\" is used in an Aries context without any qualifying adjective, it is referencing a recipe for a high-level interaction like these. Lower-level protocols are usually described more specifically and possibly with other verbiage: \"cryptographic algorithms\", \"DID management procedures\", \"DIDComm conventions\", \"transports\", and so forth. This helps us focus \"protocol\" on the place where application developers that consume Aries do most of the work that creates value.</p>"},{"location":"aip2/0003-protocols/#relationship-to-apis","title":"Relationship to APIs","text":"<p>The familiar world of web APIs is a world of protocols, but it comes with constraints antithetical to decentralized identity:</p> <ul> <li>It assumes all interactions are between a client and a server--either two parties, or N parties mediated by a central server. Thus, the server is a natural locus for surveillance and hacking.</li> <li>It assumes security is asymmetric--not using DIDs, but driven by certs on a server and by a session for the client.</li> <li>It assumes the transport is HTTP. This is problematic for pure mobile-to-mobile, or for use cases where the transport is complex or asymmetric.</li> <li>Because the server can never initiate an interaction, it requires at least one party to be continuously online.</li> </ul> <p>Protocols impose none of these constraints. Web APIs can easily be modeled as protocols where the transport is HTTP and the payload is a message, and the Aries community actively does this. We are not opposed to APIs. We just want to describe and standardize the higher level abstraction so we don't have a web solution and a BlueTooth solution that are diverged for no good reason.</p>"},{"location":"aip2/0003-protocols/#decentralized","title":"Decentralized","text":"<p>As used in the agent/DIDComm world, protocols are decentralized. This means there is not an overseer for the protocol, guaranteeing information flow, enforcing behaviors, and ensuring a coherent view. It is a subtle but important divergence from API-centric approaches, where a server holds state against which all other parties (clients) operate. Instead, all parties are peers, and they interact by mutual consent and with a (hopefully) shared understanding of the rules and goals. Protocols are like a dance\u2014not one that's choreographed or directed, but one where the parties make dynamic decisions and react to them.</p> <p></p>"},{"location":"aip2/0003-protocols/#types-of-protocols","title":"Types of Protocols","text":"<p>The simplest protocol style is notification. This style involves two parties, but it is one-way: the <code>notifier</code> emits a message, and the protocol ends when the <code>notified</code> receives it. The basic message protocol uses this style.</p> <p></p> <p>Slightly more complex is the request-response protocol style. This style involve two parties, with the <code>requester</code> making the first move, and the <code>responder</code> completing the interaction. The Discover Features Protocol uses this style. Note that with protocols as Aries models them (and unlike an HTTP request), the request-response messages are asynchronous.</p> <p></p> <p>However, more complex protocols exist. The Introduce Protocol involves three parties, not two. The issue credential protocol includes up to six message types (including <code>ack</code> and <code>problem_report</code>), two of which (<code>proposal</code> and <code>offer</code>) can be used to interactively negotiate details of the elements of the subsequent messages in the protocol.</p> <p>See this subsection for definitions of the terms \"role\", \"participant\", and \"party\".</p>"},{"location":"aip2/0003-protocols/#agent-design","title":"Agent Design","text":"<p>Protocols are the key unit of interoperable extensibility in agents and agent-like things. To add a new interoperable feature to an agent, give it the ability to handle a new protocol.</p> <p>When agents receive messages, they map the messages to a protocol handler and possibly to an interaction state that was previously persisted. This is the analog to routes, route handlers, and sessions in web APIs, and could actually be implemented as such if the transport for the protocol is HTTP. The protocol handler is code that knows the rules of a particular protocol; the interaction state tracks progress through an interaction. For more information, see the agents explainer\u2014RFC 0004 and the DIDComm explainer\u2014RFC 0005.</p>"},{"location":"aip2/0003-protocols/#composable","title":"Composable","text":"<p>Protocols are composable--meaning that you can build complex ones from simple ones. The protocol for asking someone to repeat their last sentence can be part of the protocol for ordering food at a restaurant. It's common to ask a potential driver's license holder to prove their street address before issuing the license. In protocol terms, this is nicely modeled as the present proof being invoked in the middle of an issue credential protocol.</p> <p>When we run one protocol inside another, we call the inner protocol a subprotocol, and the outer protocol a superprotocol. A given protocol may be a subprotocol in some contexts, and a standalone protocol in others. In some contexts, a protocol may be a subprotocol from one perspective, and a superprotocol from another (as when protocols are nested at least 3 deep).</p> <p></p> <p>Commonly, protocols wait for subprotocols to complete, and then they continue. A good example of this is mentioned above\u2014starting an issue credential flow, but requiring the potential issuer and/or the potential holder to prove something to one another before completing the process.</p> <p>In other cases, a protocol B is not \"contained\" inside protocol A. Rather, A triggers B, then continues in parallel, without waiting for B to complete. This coprotocol relationship is analogous to relationship between coroutines in computer science. In the Introduce Protocol, the final step is to begin a connection protocol between the two introducees-- but the introduction coprotocol completes when the connect coprotocol starts, not when it completes.</p> <p></p>"},{"location":"aip2/0003-protocols/#message-types","title":"Message Types","text":"<p>A protocol includes a number of message types that enable the execution of an instance of a protocol. Collectively, the message types of a protocol become the skeleton of its interface. Most of the message types are defined with the protocol, but several key message types, notably acks and problem reports are defined in separate RFCs and <code>adopted</code> into a protocol. This ensures that the structure of such messages is standardized, but used in the context of the protocol adopting the message types.</p>"},{"location":"aip2/0003-protocols/#handling-unrecognized-items-in-messages","title":"Handling Unrecognized Items in Messages","text":"<p>In the semver section of this document there is discussion of the handling of mismatches in minor versions supported and received. Notably, a recipient that supports a given minor version of a protocol less than that of a received protocol message should ignore any unrecognized fields in the message. Such handling of unrecognized data items applies more generally than just minor version mismatches. A recipient of a message from a supported major version of a protocol should ignore any unrecognized items in a received message, even if the supported and minor versions are the same. When items from the message are ignored, the recipient may want to send a warning <code>problem-report</code> message with code <code>fields-ignored</code>.</p>"},{"location":"aip2/0003-protocols/#ingredients","title":"Ingredients","text":"<p>A protocol has the following ingredients:</p> <ul> <li>Name and semver-compatible   version</li> <li>URI that uniquely identifies it</li> <li>Messages (primary message family)</li> <li>Adopted messages</li> <li>Roles</li> <li>State and sequencing rules</li> <li>Events that can change state -- notably, messages, but also errors, timeouts, and other things</li> <li>Constraints that provide trust and incentives</li> </ul>"},{"location":"aip2/0003-protocols/#how-to-define-a-protocol","title":"How to Define a Protocol","text":"<p>To define a protocol, write an RFC. Specific instructions for protocol RFCs, and a discussion about the theory behind detailed protocol ../../concepts, are given in the instructions for protocol RFCs and in the protocol RFC template.</p> <p>The tictactoe protocol is attached to this RFC as an example.</p> <p></p>"},{"location":"aip2/0003-protocols/#security-considerations","title":"Security Considerations","text":""},{"location":"aip2/0003-protocols/#replay-attacks","title":"Replay Attacks","text":"<p>It should be noted that when defining a protocol that has domain specific requirements around preventing replay attacks, an <code>@id</code> property SHOULD be required. Given an <code>@id</code> field is most commonly set to be a UUID, it should provide randomness comparable to that of a nonce in preventing replay attacks. However, this means that care will be needed in processing of the <code>@id</code> field to make sure its value has not been used before. In some cases, nonces require being unpredictable as well. In this case, greater review should be taken as to how the <code>@id</code> field should be used in the domain specific protocol. In the event where the <code>@id</code> field is not adequate for preventing replay attacks, it's recommended that an additional <code>nonce</code> field be required by the domain specific protocol specification.</p>"},{"location":"aip2/0003-protocols/#reference","title":"Reference","text":""},{"location":"aip2/0003-protocols/#message-type-and-protocol-identifier-uris","title":"Message Type and Protocol Identifier URIs","text":"<p>Message types and protocols are identified with URIs that match certain conventions.</p>"},{"location":"aip2/0003-protocols/#mturi","title":"MTURI","text":"<p>A message type URI (MTURI) identifies message types unambiguously. Standardizing its format is important because it is parsed by agents that will map messages to handlers--basically, code will look at this string and say, \"Do I have something that can handle this message type inside protocol X version Y?\"</p> <p>When this analysis happens, strings should be compared for byte-wise equality in all segments except version. This means that case, unicode normalization, and punctuation differences all matter. It is thus best practice to avoid protocol and message names that differ only in subtle, easy-to-mistake ways.</p> <p>Comparison of the version segment of an MTURI or PIURI should follow semver rules and is discussed in the semver section of this document.</p> <p>The URI MUST be composed as follows:</p> <p></p> <pre><code>message-type-uri  = doc-uri delim protocol-name\n    \"/\" protocol-version \"/\" message-type-name\ndelim             = \"?\" / \"/\" / \"&amp;\" / \":\" / \";\" / \"=\"\nprotocol-name     = identifier\nprotocol-version  = semver\nmessage-type-name = identifier\nidentifier        = alpha *(*(alphanum / \"_\" / \"-\" / \".\") alphanum)\n</code></pre> <p>It can be loosely matched and parsed with the following regex:</p> <pre><code>    (.*?)([a-z0-9._-]+)/(\\d[^/]*)/([a-z0-9._-]+)$\n</code></pre> <p>A match will have captures groups of (1) = <code>doc-uri</code>, (2) = <code>protocol-name</code>, (3) = <code>protocol-version</code>, and (4) = <code>message-type-name</code>.</p> <p>The goals of this URI are, in descending priority:</p> <ul> <li> <p>Code can use the URI to route messages to protocol handlers using semver rules.</p> </li> <li> <p>The definition of a protocol should be tied to the URI such that it is semantically stable. This means that once version 1.0 of a protocol is defined, its definition should not change in ways that would break implementations.</p> </li> <li> <p>Developers can discover information about novel protocols, using the URI to browse or search the web.</p> </li> </ul> <p>The <code>doc-uri</code> portion is any URI that exposes documentation about protocols. A developer should be able to browse to that URI and use human intelligence to look up the named and versioned protocol. Optionally and preferably, the full URI may produce a page of documentation about the specific message type, with no human mediation involved.</p>"},{"location":"aip2/0003-protocols/#piuri","title":"PIURI","text":"<p>A shorter URI that follows the same conventions but lacks the <code>message-type-name</code> portion is called a protocol identifier URI (PIURI).</p> <p></p> <pre><code>protocol-identifier-uri  = doc-uri delim protocol-name\n    \"/\" semver\n</code></pre> <p>Its loose matcher regex is:</p> <pre><code>    (.*?)([a-z0-9._-]+)/(\\d[^/]*)/?$\n</code></pre> <p>The following are examples of valid MTURIs and PIURIs:</p> <ul> <li><code>http://example.com/protocols?which=lets_do_lunch/1.0/</code> (PIURI with fully automated lookup of protocol docs)</li> <li><code>http://example.com/message_types?which=lets_do_lunch/1.0/proposal</code> (MTURI)</li> <li><code>https://github.com/hyperledger/aries-rfcs/tree/18c4f82:trust_ping/1.0/ping</code>    (MTURI). Note that this URI returns a 404 error if followed directly--but    per rules described above, the developer should browse to the doc root    (https://github.com/hyperledger/aries-rfcs/tree/18c4f82) and look for documentation on the <code>trust_ping/1.0</code> protocol.</li> <li><code>https://didcomm.org/trust_ping/1.0/ping</code> (MTURI) This    uses an https reference that could serve    information about protocols.</li> </ul>"},{"location":"aip2/0003-protocols/#semver-rules-for-protocols","title":"Semver Rules for Protocols","text":"<p>Semver rules apply to protocols, with the version of a protocol is expressed in the <code>semver</code> portion of its identifying URI. The \"ingredients\" of a protocol combine to form a public API in the semver sense. Core Aries protocols specify only major and minor elements in a version; the patch component is not used. Non-core protocols may choose to use the patch element.</p> <p>The major and minor versions of protocols match semver semantics:</p> <ul> <li>Clarification updates that do not change the \"public API\" of the protocol can be made with community support without changing the minor version of the protocol.</li> <li>An individual message type can add new optional fields, or deprecate existing fields, with only a change to its protocol's minor version. Similarly, a protocol can add new or deprecate message types with only a change to the minor version.</li> <li>Changes that remove fields or message types, that make formerly optional things required, or that alter the state machine in incompatible ways, must result in an increase of the major version of the protocol/primary message family.</li> </ul> <p>Within a given major version of a protocol, an agent should:</p> <ul> <li>Respond to a minimum supported minor version, defaulting to \"0\".</li> <li>An agent SHOULD keep minimum supported minor version at \"0\" unless it is unsecure or extremely complicated to do so.</li> <li>Respond with or initiate a protocol instance the current fully supported minor version.</li> </ul> <p>This leads to the following received message handling rules:</p> <ul> <li>Message types received with minor versions below the minimum MAY be ignored, or preferably, MAY be answered only with a <code>problem-report</code> message with code <code>version-not-supported</code>.</li> <li>Message types received with a minor version at or higher than the minimum supported and less than the current minor version are processed as follows:</li> <li>The processing MAY be with the same minor version of the received message.<ul> <li>To support this, an implementation must implement each minor version from minimum to current within the major version.</li> </ul> </li> <li>The processing MAY be with the current minor version (higher than received).<ul> <li>This approach is used when maintaining each minor version from minimum to current within the major version is impractical.</li> <li>Recipients of the response message SHOULD detect from the response PIURI that a higher minor version was used in the response, and to compensate if needed and as necessary.</li> <li>Prior wording of this protocol included the following suggestion that is now considered deprecated. See note below about deprecating the \"warning\" problem reports.</li> <li>In addition to responding with the protocol message (if necessary), the agent MAY also want to send a warning <code>problem-report</code> message with code <code>version-with-degraded-../../features</code>.</li> </ul> </li> <li>Message types received with a minor version higher than the current minor version MUST be processed with any unrecognized fields ignored.</li> <li>The response MUST use the current minor version.</li> <li>Recipients of the response message SHOULD detect from the response PIURI that a lower minor version was used in the response, and to compensate if needed and as necessary.</li> <li>Prior wording of this protocol included the following that is now considered deprecated. See note below about deprecating the \"warning\" problem reports.<ul> <li>In addition to responding with the protocol message, an agent MAY send a warning <code>problem-report</code> message with code <code>fields-ignored-due-to-version-mismatch</code></li> </ul> </li> </ul> <p>Note: The deprecation of the \"warning\" <code>problem-reports</code> in cases of minor version mismatches is because the recipient of the response can detect the mismatch by looking at the PIURI, making the \"warning\" unnecessary, and because the <code>problem-report</code> message may be received after (and definitely at a different time than) the response message, and so the warning is of very little value to the recipient. Recipients should still be aware that minor version mismatch warning <code>problem-report</code> messages may be received and handle them appropriately, likely by quietly ignoring them.</p> <p>As documented in the semver documentation, these requirements are not applied when major version 0 is used. In that case, minor version increments are considered breaking.</p> <p>Agents may support multiple major versions and select which major version to use when initiating an instance of the protocol.</p> <p>An agent should reject messages from protocols or unsupported protocol major versions with a <code>problem-report</code> message with code <code>version-not-supported</code>. Agents that receive such a <code>problem-report</code> message may use the discover ../../features protocol to resolve the mismatch.</p>"},{"location":"aip2/0003-protocols/#semver-examples","title":"Semver Examples","text":""},{"location":"aip2/0003-protocols/#initiator","title":"Initiator","text":"<p>Unless Alice's agent (the initiator of a protocol) knows from prior history that it should do something different, it should begin a protocol using the highest version number that it supports. For example, if A.1 supports versions 2.0 through 2.2 of protocol X, it should use 2.2 as the version in the message type of its first message.</p>"},{"location":"aip2/0003-protocols/#recipient-rules","title":"Recipient Rules","text":"<p>Agents for Bob (the recipient) should reject messages from protocols with major versions different from those they support. For major version 0, they should also reject protocols with minor versions they don't support, since semver stipulates that ../../features are not stable before 1.0. For example, if B.1 supports only versions 2.0 and 2.1 of protocol X, it should reject any messages from version 3 or version 1 or 0. In most cases, rejecting a message means sending a <code>problem-report</code> that the message is unsupported. The <code>code</code> field in such messages should be <code>version-not-supported</code>. Agents that receive such a <code>problem-report</code> can then use the Discover Features Protocol to resolve version problems.</p> <p>Recipient agents should accept messages that differ from their own supported version of a protocol only in the patch, prerelease, and/or build fields, whether these differences make the message earlier or later than the version the recipient prefers. These messages will be robustly compatible.</p> <p>For major version &gt;= 1, recipients should also accept messages that differ only in that the message's minor version is earlier than their own preference. In such a case, the recipient should degrade gracefully to use the earlier version of the protocol. If the earlier version lacks important ../../features, the recipient may optionally choose to send, in addition to a response, a <code>problem-report</code> with code <code>version-with-degraded-../../features</code>.</p> <p>If a recipient supports protocol X version 1.0, it should tentatively accept messages with later minor versions (e.g., 1.2). Message types that differ in only in minor version are guaranteed to be compatible for the feature set of the earlier version. That is, a 1.0-capable agent can support 1.0 ../../features using a 1.2 message, though of course it will lose any ../../features that 1.2 added. Thus, accepting such a message could have two possible outcomes:</p> <ol> <li> <p>The message at version 1.2 might look and behave exactly like it did at version 1.0, in which case the message will process without any trouble.</p> </li> <li> <p>The message might contain some fields that are unrecognized and need to be ignored.</p> </li> </ol> <p>In case 2, it is best practice for the recipient to send a <code>problem-report</code> that is a warning, not an error, announcing that some fields could not be processed (code = <code>fields-ignored-due-to-version-mismatch</code>). Such a message is in addition to any response that the protocol demands of the recipient.</p> <p>If the recipient of a protocol's initial message generates a response, the response should use the latest major.minor protocol version that both parties support and know about. Generally, all messages after the first use only major.minor</p> <p></p>"},{"location":"aip2/0003-protocols/#state-details-and-state-machines","title":"State Details and State Machines","text":"<p>While some protocols have only one sequence of states to manage, in most different roles perceive the interaction differently. The sequence of states for each role needs to be described with care in the RFC.</p>"},{"location":"aip2/0003-protocols/#state-machines","title":"State Machines","text":"<p>By convention, protocol state and sequence rules are described using the concept of state machines, and we encourage developers who implement protocols to build them that way.</p> <p>Among other benefits, this helps with error handling: when one agent sends a <code>problem-report</code> message to another, the message can make it crystal clear which state it has fallen back to as a result of the error.</p> <p>Many developers will have encountered a formal of definition of state machines as they wrote parsers or worked on other highly demanding tasks, and may worry that state machines are heavy and intimidating. But as they are used in Aries protocols, state machines are straightforward and elegant. They cleanly encapsulate logic that would otherwise be a bunch of conditionals scattered throughout agent code. The tictactoe example protocol example includes a complete state machine in less than 50 lines of python code, with tests.</p> <p>For an extended discussion of how state machines can be used, including in nested protocols, and with hooks that let custom processing happen at each point in a flow, see https://github.com/dhh1128/distributed-state-machine.</p>"},{"location":"aip2/0003-protocols/#processing-points","title":"Processing Points","text":"<p>A protocol definition describes key points in the flow where business logic can attach. Some of these processing points are obvious, because the protocol makes calls for decisions to be made. Others are implicit. Some examples include:</p> <ul> <li>The beginning and end.</li> <li>The launch of a subprotocol.</li> <li>The completion of a subprotocol, or the subprotocol changing state.</li> <li>Sending a message. (For each send, the sender could choose to go silent and abandon the interaction instead, though many protocols would ask for notification to be emitted as best practice.)</li> <li>(Receiving a message_. (Requires validation, then integration with policy and processes internal to the agent and its sovereign domain, to move the interaction forward.)</li> </ul>"},{"location":"aip2/0003-protocols/#roles-participants-parties-and-controllers","title":"Roles, Participants, Parties, and Controllers","text":""},{"location":"aip2/0003-protocols/#roles","title":"Roles","text":"<p>The roles in a protocol are the perspectives (responsibilities, privileges) that parties take in an interaction.</p> <p>This perspective is manifested in three general ways:</p> <ul> <li>by the expectations that a party takes on in a protocol (ex. a role may be expected to do something to start a protocol).</li> <li>by the messages that a party can and does use in the course of the protocol (some messages may be reserved for a single role, while other may used by some if not all roles).</li> <li>by the state and the transition rules</li> </ul> <p>Like parties, roles are normally known at the start of the protocol but this is not a requirement.</p> <p>In an auction protocol, there are only two roles\u2014auctioneer and bidder\u2014even though there may be many parties involved.</p>"},{"location":"aip2/0003-protocols/#participants","title":"Participants","text":"<p>The participants in a protocol are the agents that send and/or receive plaintext application-level messages that embody the protocol's interaction. Alice, Bob, and Carol may each have a cloud agent, a laptop, and a phone; if they engage in an introduction protocol using phones, then the agents on their phones are the participants. If the phones talk directly over Bluetooth, this is particularly clear--but even if the phones leverage push notifications and HTTP such that cloud agents help with routing, only the phone agents are participants, because only they maintain state for the interaction underway. (The cloud agents would be facilitators, and the laptops would be bystanders). When a protocol is complete, the participant agents know about the outcome; they may need to synchronize or replicate their state before other agents of the parties are aware.</p>"},{"location":"aip2/0003-protocols/#parties","title":"Parties","text":"<p>The parties to a protocol are the entities directly responsible for achieving the protocol's goals. When a protocol is high-level, parties are typically people or organizations; as protocols become lower-level, parties may be specific agents tasked with detail work through delegation.</p> <p>Imagine a situation where Alice wants a vacation. She engages with a travel agent named Bob. Together, they begin an \"arrange a vacation\" protocol. Alice is responsible for expressing her parameters and proving her willingness to pay; Bob is responsible for running a bunch of subprotocols to work out the details. Alice and Bob--not software agents they use--are parties to this high-level protocol, since they share responsibility for its goals.</p> <p>As soon as Alice has provided enough direction and hangs up the phone, Bob begins a sub-protocol with a hotel to book a room for Alice. This sub-protocol has related but different goals--it is about booking a particular hotel room, not about the vacation as a whole. We can see the difference when we consider that Bob could abandon the booking and choose a different hotel entirely, without affecting the overarching \"arrange a vacation\" protocol.</p> <p>With the change in goal, the parties have now changed, too. Bob and a hotel concierge are the ones responsible for making the \"book a hotel room\" protocol progress. Alice is an approver and indirect stakeholder, but she is not doing the work. (In RACI terms, Alice is an \"accountable\" or \"approving\" entity, but only Bob and the concierge are \"responsible\" parties.)</p> <p>Now, as part of the hotel reservation, Bob tells the concierge that the guest would like access to a waverunner to play in the ocean on day 2. The concierge engages in a sub-sub-protocol to reserve the waverunner. The goal of this sub-sub-protocol is to reserve the equipment, not to book a hotel or arrange a vacation. The parties to this sub-sub-protocol are the concierge and the person or automated system that manages waverunners.</p> <p>Often, parties are known at the start of a protocol; however, that is not a requirement. Some protocols might commence with some parties not yet known or assigned.</p> <p>For many protocols, there are only two parties, and they are in a pairwise relationship. Other protocols are more complex. Introductions involves three; an auction may involve many.</p> <p>Normally, the parties that are involved in a protocol also participate in the interaction but this is not always the case. Consider a gossip protocol, two parties may be talking about a third party. In this case, the third party would not even know that the protocol was happening and would definitely not participate.</p>"},{"location":"aip2/0003-protocols/#controllers","title":"Controllers","text":"<p>The controllers in a protocol are entities that make decisions. They may or may not be direct parties.</p> <p>Imagine a remote chess game between Bob and Carol, conducted with software agents. The chess protocol isn't technically about how to select a wise chess move; it's about communicating the moves so parties achieve the shared goal of running a game to completion. Yet choices about moves are clearly made as the protocol unfolds. These choices are made by controllers--Bob and Carol--while the agents responsible for the work of moving the game forward wait with the protocol suspended.</p> <p>In this case, Bob and Carol could be analyzed as parties to the protocol, as well as controllers. But in other cases, the ../../concepts are distinct. For example, in a protocol to issue credentials, the issuing institution might use an AI and/or business automation as a controller.</p>"},{"location":"aip2/0003-protocols/#instructions-for-protocol-rfcs","title":"Instructions for Protocol RFCs","text":"<p>A protocol RFC conforms to general RFC patterns, but includes some specific substructure.</p> <p></p> <p>Please see the special protocol RFC template for details.</p>"},{"location":"aip2/0003-protocols/#drawbacks","title":"Drawbacks","text":"<p>This RFC creates some formalism around defining protocols. It doesn't go nearly as far as SOAP or CORBA/COM did, but it is slightly more demanding of a protocol author than the familiar world of RESTful Swagger/OpenAPI.</p> <p>The extra complexity is justified by the greater demands that agent-to-agent communications place on the protocol definition. See notes in Prior Art section for details.</p>"},{"location":"aip2/0003-protocols/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Some of the simplest DIDComm protocols could be specified in a Swagger/OpenAPI style. This would give some nice tooling. However, not all fit into that mold. It may be desirable to create conversion tools that allow Swagger interop.</p>"},{"location":"aip2/0003-protocols/#prior-art","title":"Prior art","text":""},{"location":"aip2/0003-protocols/#bpmn","title":"BPMN","text":"<p>BPMN (Business Process Model and Notation) is a graphical language for modeling flows of all types (plus things less like our protocols as well). BPMN is a mature standard sponsored by OMG(Object Management Group). It has a nice tool ecosystem (such as this). It also has an XML file format, so the visual diagrams have a two-way transformation to and from formal written language. And it has a code generation mode, where BPMN can be used to drive executable behavior if diagrams are sufficiently detailed and sufficiently standard. (Since BPMN supports various extensions and is often used at various levels of formality, execution is not its most common application.)</p> <p>BPMN began with a focus on centralized processes (those driven by a business entity), with diagrams organized around the goal of the point-of-view entity and what they experience in the interaction. This is somewhat different from a DIDComm protocol where any given entity may experience the goal and the scope of interaction differently; the state machine for a home inspector in the \"buy a home\" protocol is quite different, and somewhat separable, from the state machine of the buyer, and that of the title insurance company.</p> <p>BPMN 2.0 introduced the notion of a choreography, which is much closer to the concept of an A2A protocol, and which has quite an elegant and intuitive visual representation. However, even a BPMN choreography doesn't have a way to discuss interactions with decorators, adoption of generic messages, and other A2A-specific concerns. Thus, we may lean on BPMN for some diagramming tasks, but it is not a substitute for the RFC definition procedure described here.</p>"},{"location":"aip2/0003-protocols/#wsdl","title":"WSDL","text":"<p>WSDL (Web Services Description Language) is a web-centric evolution of earlier, RPC-style interface definition languages like IDL in all its varieties and CORBA. These technologies describe a called interface, but they don't describe the caller, and they lack a formalism for capturing state changes, especiall by the caller. They are also out of favor in the programmer community at present, as being too heavy, too fragile, or poorly supported by current tools.</p>"},{"location":"aip2/0003-protocols/#swagger-openapi","title":"Swagger / OpenAPI","text":"<p>Swagger / OpenAPI overlaps with some of the concerns of protocol definition in agent-to-agent  interactions. We like the tools and the convenience of the paradigm  offered by OpenAPI, but where these two do not overlap, we have impedance.</p> <p>Agent-to-agent protocols must support more than 2 roles, or  two roles that are peers, whereas RESTful web services assume just client  and server--and only the server has a documented API.</p> <p>Agent-to-agent protocols are fundamentally asynchronous,  whereas RESTful web services mostly assume synchronous request~response.</p> <p>Agent-to-agent protocols have complex considerations for diffuse trust,  whereas RESTful web services centralize trust in the web server.</p> <p>Agent-to-agent protocols need to support transports beyond HTTP, whereas  RESTful web services do not.</p> <p>Agent-to-agent protocols are nestable, while  RESTful web services don't provide any special support for that construct.</p>"},{"location":"aip2/0003-protocols/#other","title":"Other","text":"<ul> <li>Pdef (Protocol Definition Language): An alternative to Swagger.</li> <li>JSON RPC: Defines how invocation of  remote methods can be accomplished by passing JSON messages. However, the  RPC paradigm assumes request/response pairs, and does not provide a way  to describe state and roles carefully.</li> <li>IPC Protocol Definition Language (IPDL):  This is much closer to agent protocols in terms of its scope of concerns  than OpenAPI. However, it is C++ only, and intended for use within browser  plugins.</li> </ul>"},{"location":"aip2/0003-protocols/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Should we write a Swagger translator?</li> <li>If not swagger, what formal definition format should we use in the future?</li> </ul>"},{"location":"aip2/0003-protocols/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python several protocols, circa Feb 2019 Aries Framework - .NET several protocols, circa Feb 2019 Streetcred.id several protocols, circa Feb 2019 Aries Cloud Agent - Python numerous protocols plus extension mechanism for pluggable protocols Aries Static Agent - Python 2 or 3 protocols Aries Framework - Go DID Exchange Connect.Me mature but proprietary protocols; community protocols in process Verity mature but proprietary protocols; community protocols in process Aries Protocol Test Suite 2 or 3 core protocols; active work to implement all that are ACCEPTED, since this tests conformance of other agents Pico Labs implemented protocols: connections, trust_ping, basicmessage, routing"},{"location":"aip2/0003-protocols/roles-participants-etc/","title":"Roles participants etc","text":""},{"location":"aip2/0003-protocols/roles-participants-etc/#roles-participants-parties-and-controllers","title":"Roles, Participants, Parties, and Controllers","text":""},{"location":"aip2/0003-protocols/roles-participants-etc/#roles","title":"Roles","text":"<p>The roles in a protocol are the perspectives (responsibilities, privileges) that parties take i an interaction.</p> <p>This perspective is manifested in three general ways:</p> <ul> <li>by the expectations that a party takes on in a protocol (ex. a role may be expected to do something to start a protocol).</li> <li>by the messages that a party can and does use in the course of the protocol (some messages may be reserved for a single role, while other may used by some if not all roles).</li> <li>by the state and the transition rules</li> </ul> <p>Like parties, roles are normally known at the start of the protocol but this is not a requirement.</p> <p>In an auction protocol, there are only two roles\u2014auctioneer and bidder\u2014even though there may be many parties involved.</p>"},{"location":"aip2/0003-protocols/roles-participants-etc/#participants","title":"Participants","text":"<p>The participants in a protocol are the agents that send and/or receive plaintext application-level messages that embody the protocol's interaction. Alice, Bob, and Carol may each have a cloud agent, a laptop, and a phone; if they engage in an introduction protocol using phones, then the agents on their phones are the participants. If the phones talk directly over Bluetooth, this is particularly clear--but even if the phones leverage push notifications and HTTP such that cloud agents help with routing, only the phone agents are participants, because only they maintain state for the interaction underway. (The cloud agents would be facilitators, and the laptops would be bystanders). When a protocol is complete, the participant agents know about the outcome; they may need to synchronize or replicate their state before other agents of the parties are aware.</p>"},{"location":"aip2/0003-protocols/roles-participants-etc/#parties","title":"Parties","text":"<p>The parties to a protocol are the entities directly responsible for achieving the protocol's goals. When a protocol is high-level, parties are typically people or organizations; as protocols become lower-level, parties may be specific agents tasked with detail work through delegation.</p> <p>Imagine a situation where Alice wants a vacation. She engages with a travel agent named Bob. Together, they begin an \"arrange a vacation\" protocol. Alice is responsible for expressing her parameters and proving her willingness to pay; Bob is responsible for running a bunch of subprotocols to work out the details. Alice and Bob--not software agents they use--are parties to this high-level protocol, since they share responsibility for its goals.</p> <p>As soon as Alice has provided enough direction and hangs up the phone, Bob begins a sub-protocol with a hotel to book a room for Alice. This sub-protocol has related but different goals--it is about booking a particular hotel room, not about the vacation as a whole. We can see the difference when we consider that Bob could abandon the booking and choose a different hotel entirely, without affecting the overarching \"arrange a vacation\" protocol.</p> <p>With the change in goal, the parties have now changed, too. Bob and a hotel concierge are the ones responsible for making the \"book a hotel room\" protocol progress. Alice is an approver and indirect stakeholder, but she is not doing the work. (In RACI terms, Alice is an \"accountable\" or \"approving\" entity, but only Bob and the concierge are \"responsible\" parties.)</p> <p>Now, as part of the hotel reservation, Bob tells the concierge that the guest would like access to a waverunner to play in the ocean on day 2. The concierge engages in a sub-sub-protocol to reserve the waverunner. The goal of this sub-sub-protocol is to reserve the equipment, not to book a hotel or arrange a vacation. The parties to this sub-sub-protocol are the concierge and the person or automated system that manages waverunners.</p> <p>Often, parties are known at the start of a protocol; however, that is not a requirement. Some protocols might commence with some parties not yet known or assigned.</p> <p>For many protocols, there are only two parties, and they are in a pairwise relationship. Other protocols are more complex. Introductions involves three; an auction may involve many.</p> <p>Normally, the parties that are involved in a protocol also participate in the interaction but this is not always the case. Consider a gossip protocol, two parties may be talking about a third party. In this case, the third party would not even know that the protocol was happening and would definitely not participate.</p>"},{"location":"aip2/0003-protocols/roles-participants-etc/#controllers","title":"Controllers","text":"<p>The controllers in a protocol are entities that make decisions. They may or may not be direct parties.</p> <p>Imagine a remote chess game between Bob and Carol, conducted with software agents. The chess protocol isn't technically about how to select a wise chess move; it's about communicating the moves so parties achieve the shared goal of running a game to completion. Yet choices about moves are clearly made as the protocol unfolds. These choices are made by controllers--Bob and Carol--while the agents responsible for the work of moving the game forward wait with the protocol suspended.</p> <p>In this case, Bob and Carol could be analyzed as parties to the protocol, as well as controllers. But in other cases, the concepts are distinct. For example, in a protocol to issue credentials, the issuing institution might use an AI and/or business automation as a controller.</p>"},{"location":"aip2/0003-protocols/tictactoe/","title":"Tic Tac Toe Protocol 1.0","text":""},{"location":"aip2/0003-protocols/tictactoe/#summary","title":"Summary","text":"<p>Describes a simple protocol, already familiar to most developers, as a way to demonstrate how all protocols should be documented.</p>"},{"location":"aip2/0003-protocols/tictactoe/#motivation","title":"Motivation","text":"<p>Playing tic-tac-toe is a good way to test whether agents are working properly, since it requires two parties to take turns and to communicate reliably about state. However, it is also pretty simple, and it has a low bar for trust (it's not dangerous to play tic-tac-toe with a malicious stranger). Thus, we expect agent tic-tac-toe to be a good way to test basic plumbing and to identify functional gaps. The game also provides a way of testing interactions with the human owners of agents, or of hooking up an agent AI.</p>"},{"location":"aip2/0003-protocols/tictactoe/#tutorial","title":"Tutorial","text":"<p>Tic-tac-toe is a simple game where players take turns placing Xs and Os in a 3x3 grid, attempting to capture 3 cells of the grid in a straight line.</p>"},{"location":"aip2/0003-protocols/tictactoe/#name-and-version","title":"Name and Version","text":"<p>This defines the <code>tictactoe</code> protocol, version 1.x, as identified by the following PIURI:</p> <pre><code>did:sov:SLfEi9esrjzybysFxQZbfq;spec/tictactoe/1.0\n</code></pre>"},{"location":"aip2/0003-protocols/tictactoe/#key-concepts","title":"Key Concepts","text":"<p>A tic-tac-toe game is an interaction where 2 parties take turns to make up to 9 moves. It starts when either party proposes the game, and ends when one of the parties wins, or when all all cells in the grid are occupied but nobody has won (a draw).</p> <p>Note: Optionally, a Tic-Tac-Toe game can be preceded by a Coin Flip Protocol to decide who goes first. This is not a high-value enhancement, but we add it for illustration purposes. If used, the <code>choice-id</code> field in the initial <code>propose</code> message of the Coin Flip should have the value <code>did:sov:SLfEi9esrjzybysFxQZbfq;spec/tictactoe/1.0/who-goes-first</code>, and the <code>caller-wins</code> and <code>flipper-wins</code> fields should contain the DIDs of the two players.</p> <p>Illegal moves and moving out of turn are errors that trigger a complaint from the other player. However, they do not scuttle the interaction. A game can also be abandoned in an unfinished state by either player, for any reason. Games can last any amount of time.</p> <pre><code>About the Key Concepts section: Here we describe the flow at a very\nhigh level. We identify preconditions, ways the protocol can start\nand end, and what can go wrong. We also talk about timing\nconstraints and other assumptions.\n</code></pre>"},{"location":"aip2/0003-protocols/tictactoe/#roles","title":"Roles","text":"<p>There are two parties in a tic-tac-toe game, but only one role, <code>player</code>. One player places 'X' for the duration of a game; the other places 'O'. There are no special requirements about who can be a player. The parties do not need to be trusted or even known to one another, either at the outset or as the game proceeds. No prior setup is required, other than an ability to communicate.</p> <pre><code>About the Roles section: Here we name the roles in the protocol,\nsay who and how many can play each role, and describe constraints.\nWe also explore qualifications for roles.\n</code></pre>"},{"location":"aip2/0003-protocols/tictactoe/#states","title":"States","text":"<p>The states of each <code>player</code> in the protocol evolve according to the following state machine:</p> <p></p> <p>When a player is in the <code>my-move</code> state, possible valid events include <code>send move</code> (the normal case), <code>send outcome</code> (if the player decides to abandon the game), and <code>receive outcome</code> (if the other player decides to abandon). A <code>receive move</code> event could conceivably occur, too-- but it would be an error on the part of the other player, and would trigger a <code>problem-report</code> message as described above, leaving the state unchanged.</p> <p>In the <code>their-move</code> state, <code>send move</code> is an impossible event for a properly behaving player. All 3 of the other events could occur, causing a state transition.</p> <p>In the <code>wrap-up</code> state, the game is over, but communication with the outcome message has not yet occurred. The logical flow is <code>send outcome</code>, whereupon the player transitions to the <code>done</code> state.</p> <pre><code>About the States section: Here we explain which states exist for each\nrole. We also enumerate the events that can occur, including messages,\nerrors, or events triggered by surrounding context, and what should\nhappen to state as a result. In this protocol, we only have one role,\nand thus only one state machine matrix. But in many protocols, each\nrole may have a different state machine.\n</code></pre>"},{"location":"aip2/0003-protocols/tictactoe/#messages","title":"Messages","text":"<p>All messages in this protocol are part of the \"tictactoe 1.0\" message family uniquely identified by this DID reference: <code>did:sov:SLfEi9esrjzybysFxQZbfq;spec/tictactoe/1.0</code></p> NOTE 1: All the messages defined in a protocol should follow  DIDComm best practices as far as how they name fields and define their data types and semantics.  NOTE 2 about the \"DID Reference\" URI that appears here: DIDs can be resolved     to a DID doc that contains an endpoint, to which everything after a     semicolon can be appended. Thus, if this DID is publicly registered     and its DID doc gives an endpoint of http://example.com, this URI     would mean that anyone can find a formal definition of the protocol at     http://example.com/spec/tictactoe/1.0. It is also possible to use a     traditional URI here, such as http://example.com/spec/tictactoe/1.0.     If that sort of URI is used, it is best practice for it to reference     immutable content, as with a link to specific commit on github:       https://github.com/hyperledger/aries-rfcs/blob/ab7a04f/concepts/0003-protocols/tictactoe/README.md#messages"},{"location":"aip2/0003-protocols/tictactoe/#move-message","title":"<code>move</code> message","text":"<p>The protocol begins when one party sends a <code>move</code> message to the other. It looks like this:</p> <p></p> <p><code>@id</code> is required here, as it establishes a message thread that will govern the rest of the game.</p> <p><code>me</code> tells which mark (X or O) the sender is placing. It is required.</p> <p><code>moves</code> is optional in the first message of the interaction. If missing or empty, the sender of the first message is inviting the recipient to make the first move. If it contains a move, the sender is moving first.</p> <p>Moves are strings like \"X:B2\" that match the regular expression <code>(?i)[XO]:[A-C][1-3]</code>. They identify a mark to be placed (\"X\" or \"O\") and a position in the 3x3 grid. The grid's columns and rows are numbered like familiar spreadsheets, with columns A, B, and C, and rows 1, 2, and 3.</p> <p><code>comment</code> is optional and probably not used much, but could be a way for players to razz one another or chat as they play. It follows the conventions of localized messages.</p> <p>Other decorators could be placed on tic-tac-toe messages, such as those to enable message timing to force players to make a move within a certain period of time.</p>"},{"location":"aip2/0003-protocols/tictactoe/#subsequent-moves","title":"Subsequent Moves","text":"<p>Once the initial <code>move</code> message has been sent, game play continues by each player taking turns sending responses, which are also <code>move</code> messages. With each new message the <code>move</code> array inside the message grows by one, ensuring that the players agree on the current accumulated state of the game. The <code>me</code> field is still required and must accurately reflect the role of the message sender; it thus alternates values between <code>X</code> and <code>O</code>.</p> <p>Subsequent messages in the game use the message threading mechanism where the <code>@id</code> of the first <code>move</code> becomes the <code>~thread.thid</code> for the duration of the game.</p> <p>An evolving sequence of <code>move</code> messages might thus look like this, suppressing all fields except what's required:</p>"},{"location":"aip2/0003-protocols/tictactoe/#messagemove-2","title":"Message/Move 2","text":"<p>This is the first message in the thread that's sent by the <code>player</code> placing \"O\"; hence it has <code>myindex</code> = 0.</p>"},{"location":"aip2/0003-protocols/tictactoe/#messagemove-3","title":"Message/Move 3","text":"<p>This is the second message in the thread by the player placing \"X\"; hence it has <code>myindex</code> = 1.</p>"},{"location":"aip2/0003-protocols/tictactoe/#messagemove-4","title":"Message/Move 4","text":"<p>...and so forth.</p> <p>Note that the order of the items in the <code>moves</code> array is NOT significant. The state of the game at any given point of time is fully captured by the moves, regardless of the order in which they were made.</p> <p>If a player makes an illegal move or another error occurs, the other player can complain using a problem-report message, with <code>explain.@l10n.code</code> set to one of the values defined in the Message Catalog section (see below).</p>"},{"location":"aip2/0003-protocols/tictactoe/#outcome-message","title":"<code>outcome</code> message","text":"<p>Game play ends when one player sends a <code>move</code> message that manages to mark 3 cells in a row. Thereupon, it is best practice, but not strictly required, for the other player to send an acknowledgement in the form of an <code>outcome</code> message.</p> <p></p> <p>The <code>moves</code> and <code>me</code> fields from a <code>move</code> message can also, optionally, be included to further document state. The <code>winner</code> field is required. Its value may be \"X\", \"O\", or--in the case of a draw--\"none\".</p> <p>This <code>outcome</code> message can also be used to document an abandoned game, in which case <code>winner</code> is <code>null</code>, and <code>comment</code> can be used to explain why (e.g., timeout, loss of interest).</p> <pre><code>About the Messages section: Here we explain the message types, but\nalso which roles send which messages, what sequencing rules apply,\nand how errors may occur during the flow. The message begins with\nan announcement of the identifier and version of the message\nfamily, and also enumerates error codes to be used with problem\nreports. This protocol is simple enough that we document the\ndatatypes and validation rules for fields inline in the narrative;\nin more complex protocols, we'd move that text into the Reference\n&gt; Messages section instead.\n</code></pre>"},{"location":"aip2/0003-protocols/tictactoe/#constraints","title":"Constraints","text":"<p>Players do not have to trust one another. Messages do not have to be authcrypted, although anoncrypted messages still have to have a path back to the sender to be useful.</p> <pre><code>About the Constraints section: Many protocols have rules\nor mechanisms that help parties build trust. For example, in buying\na house, the protocol includes such things as commission paid to\nrealtors to guarantee their incentives, title insurance, earnest\nmoney, and a phase of the process where a home inspection takes\nplace. If you are documenting a protocol that has attributes like\nthese, explain them here.\n</code></pre>"},{"location":"aip2/0003-protocols/tictactoe/#reference","title":"Reference","text":"<pre><code>About the Reference section: If the Tutorial &gt; Messages section\nsuppresses details, we would add a Messages section here to\nexhaustively describe each field. We could also include an\nExamples section to show variations on the main flow.\n</code></pre>"},{"location":"aip2/0003-protocols/tictactoe/#collateral","title":"Collateral","text":"<p>A reference implementation of the logic of a game is provided with this RFC as python 3.x code. See game.py. There is also a simple hand-coded AI that can play the game when plugged into an agent (see ai.py), and a set of unit tests that prove correctness (see test_tictactoe.py).</p> <p>A full implementation of the state machine is provided as well; see state_machine.py and test_state_machine.py.</p> <p>The game can be played interactively by running <code>python game.py</code>.</p>"},{"location":"aip2/0003-protocols/tictactoe/#localization","title":"Localization","text":"<p>The only localizable field in this message family is <code>comment</code> on both <code>move</code> and <code>outcome</code> messages. It contains ad hoc text supplied by the sender, instead of a value selected from an enumeration and identified by <code>code</code> for use with message catalogs. This means the only approach to localize <code>move</code> or <code>outcome</code> messages is to submit <code>comment</code> fields to an automated translation service. Because the locale of <code>tictactoe</code> messages is not predefined, each message must be decorated with <code>~l10n.locale</code> to make automated translation possible.</p> <p>There is one other way that localization is relevant to this protocol: in error messages. Errors are communicated through the general problem-report message type rather than through a special message type that's part of the <code>tictactoe</code> family. However, we define a catalog of tictactoe-specific error codes below to make this protocol's specific error strings localizable. </p> <p>Thus, all instances of this message family carry localization metadata in the form of an implicit <code>~l10n</code> decorator that looks like this:</p> <p></p> <p>This JSON fragment is checked in next to the narrative content of this RFC as ~l10n.json, for easy machine parsing.</p> <p>Individual messages can use the <code>~l10n</code> decorator to supplement or override these settings.</p> <p>For more information about localization concepts, see the RFC about localized messages.</p>"},{"location":"aip2/0003-protocols/tictactoe/#message-catalog","title":"Message Catalog","text":"<p>To facilitate localization of error messages, all instances of this message family assume the following catalog in their <code>~l10n</code> data:</p> <p></p> <p>When referencing this catalog, please be sure you have the correct version. The official, immutable URL to this version of the catalog file is:</p> <pre><code>https://github.com/hyperledger/indy-hipe/blob/fc7a6028/text/tictactoe-protocol/catalog.json\n</code></pre> <p>This JSON fragment is checked in next to the narrative content of this RFC as catalog.json, for easy machine parsing. The catalog currently contains localized alternatives only for English. Other language contributions would be welcome.</p> <p>For more information, see the Message Catalog section of the localization HIPE.</p>"},{"location":"aip2/0003-protocols/tictactoe/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Verity Commercially licensed enterprise agent, SaaS or on-prem. Pico Labs Open source TicTacToe for Pico Agents"},{"location":"aip2/0004-agents/","title":"Aries RFC 0004: Agents","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2019-01-15</li> <li>Status Note: On a standards track and beginning to influence many mental models, but not yet ADOPTED. </li> <li>Supersedes: Indy HIPE 0002</li> <li>Start Date: 2017-11-01 (approx, backdated)</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0004-agents/#summary","title":"Summary","text":"<p>Provide a high-level introduction to the ../../concepts of agents in the self-sovereign identity ecosystem.</p>"},{"location":"aip2/0004-agents/#tutorial","title":"Tutorial","text":"<p>Managing an identity is complex. We need tools to help us.</p> <p>In the physical world, we often delegate complexity to trusted proxies that can help. We hire an accountant to do our taxes, a real estate agent to help us buy a house, and a talent agent to help us pitch an album to a recording studio.</p> <p>On the digital landscape, humans and organizations (and sometimes, things) cannot directly consume and emit bytes, store and manage data, or perform the crypto that self-sovereign identity demands. They need delegates--agents--to help. Agents are a vital dimension across which we exercise sovereignty over identity.</p> <p></p>"},{"location":"aip2/0004-agents/#essential-characteristics","title":"Essential Characteristics","text":"<p>When we use the term \"agent\" in the SSI community, we more properly mean \"an agent of self-sovereign identity.\" This means something more specific than just a \"user agent\" or a \"software agent.\" Such an agent has three defining characteristics:</p> <ol> <li>It acts as a fiduciary on behalf of a single identity owner (or, for agents of things like IoT devices, pets, and similar things, a single controller).</li> <li>It holds cryptographic keys that uniquely embody its delegated authorization.</li> <li>It interacts using interoperable DIDComm protocols.</li> </ol> <p>These characteristics don't tie an agent to any particular blockchain. It is possible to implement agents without any use of blockchain at all (e.g., with peer DIDs), and some efforts to do so are quite active.</p>"},{"location":"aip2/0004-agents/#canonical-examples","title":"Canonical Examples","text":"<p>Three types of agents are especially common:</p> <ol> <li>A mobile app that Alice uses to manage credentials and to connect to others is an agent for Alice.</li> <li>A cloud-based service that Alice uses to expose a stable endpoint where other agents can talk to her is an agent for Alice.</li> <li>A server run by Faber College, allowing it to issue credentials to its students, is an agent for Faber.</li> </ol> <p>Depending on your perspective, you might describe these agents in various ways. #1 can correctly be called a \"mobile\" or \"edge\" or \"rich\" agent. #2 can be called a \"cloud\" or \"routing\" agent. #3 can be called an \"on-prem\" or \"edge\" or \"advanced\" agent. See Categorizing Agents for a discussion about why multiple labels are correct.</p> <p>Agents can be other things as well. They can big or small, complex or simple. They can interact and be packaged in various ways.  They can be written in a host of programming languages. Some are more canonical than others. But all the ones we intend to interact with in the self-sovereign identity problem domain share the three essential characteristics described above.</p>"},{"location":"aip2/0004-agents/#how-agents-talk","title":"How Agents Talk","text":"<p>DID communication (DIDComm), and the protocols built atop it are each rich subjects unto themselves. Here, we will stay very high-level.</p> <p>Agents can use many different communication transports: HTTP(S) 1.x and 2.0, WebSockets, IRC, Bluetooth, AMQP, NFC, Signal, email, push notifications to mobile devices, ZMQ, and more. However, all A2A is message-based, and is secured by modern, best-practice public key cryptography. How messages flow over a transport may vary--but their security and privacy toolset, their links to the DIDs and DID Docs of identity owners, and the ways their messages are packaged and handled are standard.</p> <p>Agents connect to one another through a standard connection protocol, discover one another's endpoints and keys through standard DID Docs, discover one another's ../../features in a standard way, and maintain relationships in a standard way. All of these points of standardization are what makes them interoperable.</p> <p>Because agents speak so many different ways, and because many of them won't have a permanent, accessible point of presence on the network, they can't all be thought of as web servers with a Swagger-compatible API for request-response. The analog to an API construct in agent-land is protocols. These are patterns for stateful interactions. They specify things like, \"If you want to negotiate a sale with an agent, send it a message of type X. It will respond with a message of type Y or type Z, or with an error message of type W. Repeat until the negotiation finishes.\" Some interesting A2A protocols include the one where two parties connect to one another to build a relationship, the one where agents discover which protocols they each support, the one where credentials are issued, and the one where proof is requested and sent. Hundreds of other protocols are being defined.</p>"},{"location":"aip2/0004-agents/#how-to-get-an-agent","title":"How to Get an Agent","text":"<p>As the ecosystem for self-sovereign identity matures, the average person or organization will get an agent by downloading it from the app store, installing it with their OS package manager, or subscribing to it as a service. However, the availability of quality pre-packaged agents is still limited today.</p> <p>Agent providers are emerging in the marketplace, though. Some are governments, NGOs, or educational institutions that offer agents for free; others are for-profit ventures. If you'd like suggestions about ready-to-use agent offerings, please describe your use case in <code>#aries</code> on chat.hyperledger.org.</p> <p>There is also intense activity in the SSI community around building custom agents and the tools and processes that enable them. A significant amount of early work occurred in the Indy Agent Community with some of those efforts materializing in the indy-agent repo on github.com and other code bases. The indy-agent repo is now deprecated but is still valuable in demonstrating the basics of agents. With the introduction of Hyperledger Aries, agent efforts are migrating from the Indy Agent community.</p> <p>Hyperledger Aries provides a number of code bases ranging from agent frameworks to tools to aid in development to ready-to-use agents.</p>"},{"location":"aip2/0004-agents/#how-to-write-an-agent","title":"How to Write an Agent","text":"<p>This is one of the most common questions that Aries newcomers ask. It's a challenging one to answer, because it's so open-ended. It's sort of like someone asking, \"Can you give me a recipe for dinner?\" The obvious follow-up question would be, \"What type of dinner did you have in mind?\"</p> <p>Here are some thought questions to clarify intent:</p> <ul> <li>Do you need an agent for people or institutions (or an IoT thing)?</li> <li>Will the agent run on a mobile device, in a cloud, on a server,   or elsewhere?</li> <li>Will the agent be on and connected to the internet constantly, or   will it run only from time to time?</li> <li>Which protocols should your agent implement? (In other words, what   sort of work do you want to delegate to it?)</li> <li>Will your agent talk, listen, or both? What channels/transports   will it use?</li> <li>What interesting requirements does your agent have with respect to   security, privacy, scale, and performance?</li> </ul>"},{"location":"aip2/0004-agents/#general-patterns","title":"General Patterns","text":"<p>We said it's hard to provide a recipe for an agent without specifics. However, the majority of agents do have two things in common: they listen to and process A2A messages, and they use a wallet to manage keys, credentials, and other sensitive material. Unless you have uses cases that involve IoT, cron jobs, or web hooks, your agent is likely to fit this mold.</p> <p>The heart of such an agent is probably a messaging handling loop, with pluggable protocols to give it new capabilities, and pluggable transports to let it talk in different ways. The pseudocode for its main function might look like this:</p>"},{"location":"aip2/0004-agents/#pseudocode-for-main","title":"Pseudocode for main()","text":"<pre><code>1  While not done:\n2      Get next message.\n3      Verify it (decrypt, identify sender, check signature...).\n3      Look at the type of the plaintext message.\n4      Find a plugged in protocol handler that matches that type.\n5      Give plaintext message and security metadata to handler.\n</code></pre> <p>Line 2 can be done via standard HTTP dispatch, or by checking an email inbox, or in many other ways. Line 3 can be quite sophisticated--the sender will not be Alice, but rather one of the agents that she has authorized. Verification may involve consulting cached information and/or a blockchain where a DID and DID Doc are stored, among other things.</p> <p>The pseudocode for each protocol handler it loads might look like:</p>"},{"location":"aip2/0004-agents/#pseudocode-for-protocol-handler","title":"Pseudocode for protocol handler","text":"<pre><code>1  Check authorization against metadata. Reject if needed.\n2  Read message header. Is it part of an ongoing interaction?\n3  If yes, load persisted state.\n4  Process the message and update interaction state.\n5  If a response is appropriate:\n6      Prepare response content.\n7      Ask my outbound comm module to package and send it.\n</code></pre> <p>Line 4 is the workhorse. For example, if the interaction is about issuing credentials and this agent is doing the issuance, this would be where it looks up the material for the credential in internal databases, formats it appropriately, and records the fact that the credential has now been built. Line 6 might be where that credential is attached to an outgoing message for transmission to the recipient.</p> <p>The pseudocode for the outbound communication module might be:</p>"},{"location":"aip2/0004-agents/#pseudocode-for-outbound","title":"Pseudocode for outbound","text":"<pre><code>1  Iterate through all pluggable transports to find best one to use\n     with the intended recipient.\n2  Figure out how to route the message over the selected transport.\n3  Serialize the message content and encrypt it appropriately.\n4  Send the message.\n</code></pre> <p>Line 2 can be complex. It involves looking up one or more endpoints in the DID Doc of the recipient, and finding an intersection between transports they use, and transports the sender can speak. Line 3 requires the keys of the sender, which would normally be held in a wallet.</p> <p>If you are building this sort of code using Aries technology, you will certainly want to use Aries Agent SDK. This gives you a ready-made, highly secure wallet that can be adapted to many requirements. It also provides easy functions to serialize and encrypt. Many of the operations you need to do are demonstrated in the SDK's /doc/how-tos folder, or in its Getting Started Guide.</p>"},{"location":"aip2/0004-agents/#how-to-learn-more","title":"How to Learn More","text":"<ul> <li>Hang out and ask questions on <code>#aries</code> on chat.hyperledger.org.</li> <li>Use the mailing list: aries@lists.hyperledger.org</li> <li>Follow the Aries Cloud Agent - Python Getting Started Guide (for developers)</li> <li>Study the Aries Protocol Test Suite |</li> <li>Study the sample mobile agent at github.com/sovrin-foundation/connector-app.</li> <li>Browse other RFCs.</li> <li>Attend the Aries working group on Wednesdays. (See HL community calendar for details; note that the default timezone is GMT.)</li> <li>Review this slide deck   about integrating agents with familiar web development paradigms.</li> </ul>"},{"location":"aip2/0004-agents/#reference","title":"Reference","text":""},{"location":"aip2/0004-agents/#categorizing-agents","title":"Categorizing Agents","text":"<p>Agents can be categorized in various ways, and these categories lead to terms you're likely to encounter in RFCs and other documentation. Understanding the categories will help the definitions make sense.</p>"},{"location":"aip2/0004-agents/#by-trust","title":"By Trust","text":"<p>A trustable agent runs in an environment that's under the direct control of its owner; the owner can trust it without incurring much risk. A semi-trustable agent runs in an environment where others besides the owner may have access, so giving it crucial secrets is less advisable. (An untrustable delegate should never be an agent, by definition, so we don't use that term.)</p> <p>Note that these distinctions highlight what is advisable, not how much trust the owner actually extends.</p>"},{"location":"aip2/0004-agents/#by-location","title":"By Location","text":"<p>Two related but deprecated terms are edge agent and cloud agent. You will probably hear these terms in the community or read them in docs. The problem with them is that they suggest location, but were formally defined to imply levels of trust. When they were chosen, location and levels of trust were seen as going together--you trust your edge more, and your cloud less. We've since realized that a trustable agent could exist in the cloud, if it is directly controlled by the owner, and a semi-trustable agent could be on-prem, if the owner's control is indirect. Thus we are trying to correct usage and make \"edge\" and \"cloud\" about location instead.</p>"},{"location":"aip2/0004-agents/#by-platform","title":"By Platform","text":"<ul> <li>Mobile -- likely trustable</li> <li>Workstation -- likely trustable</li> <li>Server -- could be trustable or semi-trustable</li> <li>Embedded -- trustable or semi-trustable</li> <li>Browser (web assembly or javascript) -- likely semi-trustable</li> <li>Blockchain (embodied in smart contract -- trustable?)</li> <li>Mesh (IoT\u2026)</li> <li>Paper?</li> </ul>"},{"location":"aip2/0004-agents/#by-complexity","title":"By Complexity","text":"<p>We can arrange agents on a continuum, from simple to complex. The simplest agents are static--they are preconfigured for a single relationship. Thin agents are somewhat fancier. Thick agents are fancier still, and rich agents exhibit the most sophistication and flexibility:</p> <p></p> <p>A nice visualization of several dimensions of agent category has been built by Michael Herman:</p> <p></p>"},{"location":"aip2/0004-agents/#the-agent-ness-continuum","title":"The Agent-ness Continuum","text":"<p>The tutorial above gives three essential characteristics of agents, and lists some canonical examples. This may make it feel like agent-ness is pretty binary. However, we've learned that reality is more fuzzy.</p> <p>Having a tight definition of an agent may not matter in all cases. However, it is important when we are trying to understand interoperability goals. We want agents to be able to interact with one another. Does that mean they must interact with every piece of software that is even marginally agent-like? Probably not.</p> <p>Some attributes that are not technically necessary in agents include:</p> <ul> <li>Has a wallet (common, but not universal)</li> <li>Establishes new connections (some may use only a small set of preconfigured connections)</li> <li>Exchanges credentials and proofs (some may not use these protocols)</li> <li>Both listens and talks (some may only listen or only talk)</li> </ul> <p>Agents that lack these characteristics can still be fully interoperable.</p> <p>Some interesting examples of less prototypical agents or agent-like things include:</p>"},{"location":"aip2/0004-agents/#dif-hubs","title":"DIF Hubs","text":"<p>A DIF Identity Hub is construct that resembles agents in some ways, but that focuses on the data-sharing aspects of identity. Currently DIF Hubs do not use the protocols known to the Aries community, and vice versa. However, there are efforts to bridge that gap.</p>"},{"location":"aip2/0004-agents/#identity-wallets","title":"Identity Wallets","text":"<p>\"Identity wallet\" is a term that's carefully defined in our ecosystem, and in strict, technical usage it maps to a concept much closer to \"database\" than \"agent\". This is because it is an inert storage container, not an active interacter. However, in casual usage, it may mean the software that uses a wallet to do identity work--in which case it is definitely an agent.</p>"},{"location":"aip2/0004-agents/#crypto-wallets","title":"Crypto Wallets","text":"<p>Cryptocurrency wallets are quite agent-like in that they hold keys and represent a user. However, they diverge from the agent definition in that they talk proprietary protocols to blockchains, rather than A2A to other agents.</p>"},{"location":"aip2/0004-agents/#uport","title":"uPort","text":"<p>The uPort app is an edge agent. Here, too, there are efforts to bridge a protocol gap.</p>"},{"location":"aip2/0004-agents/#learning-machine","title":"Learning Machine","text":"<p>The credential issuance technology offered by Learning Machine, and the app used to share those credentials, are agents of institutions and individuals, respectively. Again, there is a protocol gap to bridge.</p>"},{"location":"aip2/0004-agents/#cron-jobs","title":"Cron Jobs","text":"<p>A cron job that runs once a night at Faber, scanning a database and revoking credentials that have changes status during the day, is an agent for Faber. This is true even though it doesn't listen for incoming messages (it only talks revocation protocol to the ledger). In order to talk that protocol, it must hold keys delegated by Faber, and it is surely Faber's fiduciary.</p>"},{"location":"aip2/0004-agents/#operating-systems","title":"Operating Systems","text":"<p>The operating system on a laptop could be described as agent-like, in that it works for a single owner and may have a keystore. However, it doesn't talk A2A to other agents--at least not yet. (OSes that service multiple users fit the definition less.)</p>"},{"location":"aip2/0004-agents/#devices","title":"Devices","text":"<p>A device can be thought of as an agent (e.g., Alice's phone as an edge agent). However, strictly speaking, one device might run multiple agents, so this is only casually correct.</p>"},{"location":"aip2/0004-agents/#sovrin-mainnet","title":"Sovrin MainNet","text":"<p>The Sovrin MainNet can be thought of as an agent for the Sovrin community (but NOT the Sovrin Foundation, which codifies the rules but leaves operation of the network to its stewards). Certainly, the blockchain holds keys, uses A2A protocols, and acts in a fiduciary capacity toward the community to further its interests. The only challenge with this perspective is that the Sovrin community has a very fuzzy identity.</p>"},{"location":"aip2/0004-agents/#validators","title":"Validators","text":"<p>Validator nodes on a particular blockchain are agents of the stewards that operate them.</p>"},{"location":"aip2/0004-agents/#digital-assistants","title":"Digital Assistants","text":"<p>Digital assistants like Alexa and Google Home are somewhat agent-like. However, the Alexa in the home of the Jones family is probably not an agent for either the Jones family or Amazon. It accepts delegated work from anybody who talks to it (instead of a single controlling identity), and all current implementations are totally antithetical to the ethos of privacy and security required by self-sovereign identity. Although it interfaces with Amazon to download data and ../../features, it isn't Amazon's fiduciary, either. It doesn't hold keys that allow it to represent its owner. The protocols it uses are not interactions with other agents, but with non-agent entities. Perhaps agents and digtal assistants will converge in the future.</p>"},{"location":"aip2/0004-agents/#doorbell","title":"Doorbell","text":"<p>An doorbell that emits a simple signal each time it is pressed is not an agent. It doesn't represent a fiduciary or hold keys. (However, a fancy IoT doorbell that reports to Alice's mobile agent using an A2A protocol would be an agent.)</p>"},{"location":"aip2/0004-agents/#microservices","title":"Microservices","text":"<p>A microservice run by AcmeCorp to integrate with its vendors is not an agent for Acme's vendors. Depending on whether it holds keys and uses A2A protocols, it may or may not be an agent for Acme.</p>"},{"location":"aip2/0004-agents/#human-delegates","title":"Human Delegates","text":"<p>A human delegate who proves empowerment through keys might be thought of as an agent.</p>"},{"location":"aip2/0004-agents/#paper","title":"Paper","text":"<p>The keys for an agent can be stored on paper. This storage basically constitutes a wallet. It isn't an agent. However, it can be thought of as playing the role of an agent in some cases when designing backup and recovery solutions.</p>"},{"location":"aip2/0004-agents/#prior-art","title":"Prior art","text":"<ul> <li>Alan Kay, the recipient of a Turing Award and the coiner of the term \"Object-Oriented Programming\", has emphasized the value of message-passing architectures in numerous places. What he called \"objects\" are conceptually similar to what we are calling \"agents.\" Not surprisingly, the agent ecosystem echoes some aspects of the design of SmallTalk, Objective-C, Erlang Actors, Akka Actors, and similar approaches.</li> <li>The design of the web includes the concept of browsers and similar tech, and refers to them as \"user agents\" in various RFCs. These are not true SSI agents, but they provide an example of ubiquitous helper tech that is the forerunner of the agents described here.</li> </ul>"},{"location":"aip2/0004-agents/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community Aries Framework - .NET .NET framework for building agents of all types Streetcred.id Commercial mobile and web app built using Aries Framework for .NET Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Aries Framework - Go For building agents, hubs and other DIDComm ../../features in GoLang. Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem. Aries Protocol Test Suite Pico Labs Pico Agents protocols: connections, trust_ping, basicmessage, routing Rust Agent Rust implementation of a framework for building agents of all types"},{"location":"aip2/0005-didcomm/","title":"Aries RFC 0005: DID Communication","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-11-21</li> <li>Status Note: Mature as concept, with multiple implementations.</li> <li>Supersedes: Indy PR #98</li> <li>Start Date: 2018-01-05 (approx, backdated)</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0005-didcomm/#summary","title":"Summary","text":"<p>Explain the basics of DID communication (DIDComm) at a high level, and link to other RFCs to promote deeper exploration.</p> <p>NOTE: The version of DIDComm collectively defined in Aries RFCs is known by the label \"DIDComm V1.\" A newer version of DIDComm (\"DIDComm V2\") is now being incubated at DIF. Many ../../concepts are the same between the two versions, but there are some differences in the details. For information about detecting V1 versus V2, see Detecting DIDComm Versions.</p>"},{"location":"aip2/0005-didcomm/#motivation","title":"Motivation","text":"<p>The DID communication between agents and agent-like things is a rich subject with a lot of tribal knowledge. Newcomers to the decentralized identity ecosystem tend to bring mental models that are subtly divergent from its paradigm. When they encounter dissonance, DIDComm becomes mysterious. We need a standard high-level reference.</p>"},{"location":"aip2/0005-didcomm/#tutorial","title":"Tutorial","text":"<p>This discussion assumes that you have a reasonable grasp on topics like self-sovereign identity, DIDs and DID docs, and agents. If you find yourself lost, please review that material for background and starting assumptions.</p> <p>Agent-like things have to interact with one another to get work done. How they talk in general is DIDComm, the subject of this RFC. The specific interactions enabled by DIDComm--connecting and maintaining relationships, issuing credentials, providing proof, etc.--are called protocols; they are described elsewhere.</p>"},{"location":"aip2/0005-didcomm/#rough-overview","title":"Rough Overview","text":"<p>A typical DIDComm interaction works like this:</p>  Imagine Alice wants to negotiate with Bob to sell something online, and that DIDComm, not direct human communication, is involved. This means Alice's agent and Bob's agent are going to exchange a series of messages.  Alice may just press a button and be unaware of details, but underneath, her agent begins by preparing a plaintext JSON message about the proposed sale. (The particulars are irrelevant here, but would be described in the spec for a \"sell something\" protocol.) It then looks up Bob's DID Doc to access two key pieces of information:  * An endpoint (web, email, etc) where messages can be delivered to Bob. * The public key that Bob's agent is using in the Alice:Bob relationship.  Now Alice's agent uses Bob's public key to encrypt the plaintext so that only Bob's agent can read it, adding authentication with its own private key. The agent arranges delivery to Bob. This \"arranging\" can involve various hops and intermediaries. It can be complex.  Bob's agent eventually receives and decrypts the message, authenticating its origin as Alice using her public key. It prepares its response and routes it back using a reciprocal process (plaintext -&gt; lookup endpoint and public key for Alice -&gt; encrypt with authentication -&gt; arrange delivery).  <p>That's it.</p> <p>Well, mostly. The description is pretty good, if you squint, but it does not fit all DIDComm interactions:</p> <ul> <li>DIDComm doesn't always involve turn-taking and request-response.</li> <li>DIDComm interactions can involve more than 2 parties, and the parties are not always individuals.</li> <li>DIDComm may include formats other than JSON.</li> </ul> <p>Before we provide more details, let's explore what drives the design of DIDComm.</p>"},{"location":"aip2/0005-didcomm/#goals-and-ramifications","title":"Goals and Ramifications","text":"<p>The DIDComm design attempts to be:</p> <ol> <li>Secure</li> <li>Private</li> <li>Interoperable</li> <li>Transport-agnostic</li> <li>Extensible</li> </ol> <p>As a list of buzz words, this may elicit nods rather than surprise. However, several items have deep ramifications.</p> <p>Taken together, Secure and Private require that the protocol be decentralized and maximally opaque to the surveillance economy.</p> <p>Interoperable means that DIDComm should work across programming languages, blockchains, vendors, OS/platforms, networks, legal jurisdictions, geos, cryptographies, and hardware--as well as across time. That's quite a list. It means that DIDComm intends something more than just compatibility within Aries; it aims to be a future-proof lingua franca of all self-sovereign interactions.</p> <p>Transport-agnostic means that it should be possible to use DIDComm over HTTP(S) 1.x and 2.0, WebSockets, IRC, Bluetooth, AMQP, NFC, Signal, email, push notifications to mobile devices, Ham radio, multicast, snail mail, carrier pigeon, and more.</p> <p>All software design involves tradeoffs. These goals, prioritized as shown, lead down an interesting path.</p>"},{"location":"aip2/0005-didcomm/#message-based-asynchronous-and-simplex","title":"Message-Based, Asynchronous, and Simplex","text":"<p>The dominant paradigm in mobile and web development today is duplex request-response. You call an API with certain inputs, and you get back a response with certain outputs over the same channel, shortly thereafter. This is the world of OpenAPI (Swagger), and it has many virtues.</p> <p>Unfortunately, many agents are not good analogs to web servers. They may be mobile devices that turn off at unpredictable intervals and that lack a stable connection to the network. They may need to work peer-to-peer, when the internet is not available. They may need to interact in time frames of hours or days, not with 30-second timeouts. They may not listen over the same channel that they use to talk.</p> <p>Because of this, the fundamental paradigm for DIDComm is message-based, asynchronous, and simplex. Agent X sends a message over channel A. Sometime later, it may receive a response from Agent Y over channel B. This is much closer to an email paradigm than a web paradigm.</p> <p>On top of this foundation, it is possible to build elegant, synchronous request-response interactions. All of us have interacted with a friend who's emailing or texting us in near-realtime. However, interoperability begins with a least-common-denominator assumption that's simpler.</p>"},{"location":"aip2/0005-didcomm/#message-level-security-reciprocal-authentication","title":"Message-Level Security, Reciprocal Authentication","text":"<p>The security and privacy goals, and the asynchronous+simplex design decision, break familiar web assumptions in another way. Servers are commonly run by institutions, and we authenticate them with certificates. People and things are usually authenticated to servers by some sort of login process quite different from certificates, and this authentication is cached in a session object that expires. Furthermore, web security is provided at the transport level (TLS); it is not an independent attribute of the messages themselves.</p> <p>In a partially disconnected world where a comm channel is not assumed to support duplex request-response, and where the security can't be ignored as a transport problem, traditional TLS, login, and expiring sessions are impractical. Furthermore, centralized servers and certificate authorities perpetuate a power and UX imbalance between servers and clients that doesn't fit with the peer-oriented DIDComm.</p> <p>DIDComm uses public key cryptography, not certificates from some parties and passwords from others. Its security guarantees are independent of the transport over which it flows. It is sessionless (though sessions can easily be built atop it). When authentication is required, all parties do it the same way.</p>"},{"location":"aip2/0005-didcomm/#reference","title":"Reference","text":"<p>The following RFCs profide additional information: * 0021: DIDComm Message Anatomy * 0020: Message Types * 0011: Decorators * 0008: Message ID and Threading * 0019: Encryption Envelope * 0025: Agent Transports</p>"},{"location":"aip2/0005-didcomm/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community Aries Framework - .NET .NET framework for building agents of all types Streetcred.id Commercial mobile and web app built using Aries Framework - .NET Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Aries Framework - Go For building agents, hubs and other DIDComm ../../features in GoLang. Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem. Aries Protocol Test Suite Pico Labs Pico Agents protocols: connections, trust_ping, basicmessage, routing"},{"location":"aip2/0008-message-id-and-threading/","title":"Aries RFC 0008: Message ID and Threading","text":"<ul> <li>Authors: Daniel Bluhm, Sam Curren, Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2018-10-01</li> <li>Status Note: Implemented broadly in Indy, but not yet elsewhere.</li> <li>Start Date: 2018-08-03</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0008-message-id-and-threading/#summary","title":"Summary","text":"<p>Definition of the message @id field and the ~thread decorator.</p>"},{"location":"aip2/0008-message-id-and-threading/#motivation","title":"Motivation","text":"<p>Referring to messages is useful in many interactions. A standard method of adding a message ID promotes good patterns in message families. When multiple messages are coordinated in a message flow, the threading pattern helps avoid having to re-roll the same spec for each message family that needs it.</p>"},{"location":"aip2/0008-message-id-and-threading/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0008-message-id-and-threading/#message-ids","title":"Message IDs","text":"<p>Message IDs are specified with the @id attribute, which comes from JSON-LD. The sender of the message is responsible for creating the message ID, and any message can be identified by the combination of the sender and the message ID. Message IDs should be considered to be opaque identifiers by any recipients.</p>"},{"location":"aip2/0008-message-id-and-threading/#message-id-requirements","title":"Message ID Requirements","text":"<ul> <li>A short stream of characters matching regex <code>[-_./a-ZA-Z0-9]{8,64}</code> (Note the   special semantics of a dotted suffix on IDs,   as described in the message tracing HIPE proposal)</li> <li>Should be compared case-sensitive (no case folding)</li> <li>Sufficiently unique</li> <li>UUID recommended</li> </ul>"},{"location":"aip2/0008-message-id-and-threading/#example","title":"Example","text":"<pre><code>{\n    \"@type\": \"did:example:12345...;spec/example_family/1.0/example_type\",\n    \"@id\": \"98fd8d72-80f6-4419-abc2-c65ea39d0f38\",\n    \"example_attribute\": \"stuff\"\n}\n</code></pre> <p>The following was pulled from this document written by Daniel Hardman and stored in the Sovrin Foundation's <code>protocol</code> repository.</p>"},{"location":"aip2/0008-message-id-and-threading/#threaded-messages","title":"Threaded Messages","text":"<p>Message threading will be implemented as a decorator to messages, for example:</p> <pre><code>{\n    \"@type\": \"did:example:12345...;spec/example_family/1.0/example_type\",\n    \"@id\": \"98fd8d72-80f6-4419-abc2-c65ea39d0f38\",\n    \"~thread\": {\n        \"thid\": \"98fd8d72-80f6-4419-abc2-c65ea39d0f38\",\n        \"pthid\": \"1e513ad4-48c9-444e-9e7e-5b8b45c5e325\",\n        \"sender_order\": 3,\n        \"received_orders\": {\"did:sov:abcxyz\":1},\n        \"goal_code\": \"aries.vc.issue\"\n    },\n    \"example_attribute\": \"example_value\"\n}\n</code></pre> <p>The <code>~thread</code> decorator is generally required on any type of response, since this is what connects it with the original request.</p> <p>While not recommended, the initial message of a new protocol instance MAY have an empty (<code>{}</code>) <code>~thread</code> item. Aries agents receiving a message with an empty <code>~thread</code> item MUST gracefully handle such a message.</p>"},{"location":"aip2/0008-message-id-and-threading/#thread-object","title":"Thread object","text":"<p>A thread object has the following fields discussed below:</p> <ul> <li><code>thid</code>: The ID of the message that serves as the thread start.</li> <li><code>pthid</code>: An optional parent <code>thid</code>. Used when branching or nesting a new interaction off of an existing one.</li> <li><code>sender_order</code>: A number that tells where this message fits in the sequence of all messages that the current sender has contributed to this thread.</li> <li><code>received_orders</code>: Reports the highest <code>sender_order</code> value that the sender has seen   from other sender(s) on the thread. (This value is often missing if it   is the first message in an interaction, but should be used otherwise,   as it provides an implicit ACK.)</li> <li><code>goal_code</code>: Optional. See RFC 0519: Goal Codes.</li> </ul>"},{"location":"aip2/0008-message-id-and-threading/#thread-id-thid","title":"Thread ID (<code>thid</code>)","text":"<p>Because multiple interactions can happen simultaneously, it's important to differentiate between them. This is done with a Thread ID or <code>thid</code>.</p> <p>If the Thread object is defined and a <code>thid</code> is given, the Thread ID is the value given there. But if the Thread object is not defined in a message, the Thread ID is  implicitly defined as the Message ID (<code>@id</code>) of the given message and that message is the first message of a new thread.</p>"},{"location":"aip2/0008-message-id-and-threading/#sender-order-sender_order","title":"Sender Order (<code>sender_order</code>)","text":"<p>It is desirable to know how messages within a thread should be ordered. However, it is very difficult to know with confidence the absolute ordering of events scattered across a distributed system. Alice and Bob may each send a message before receiving the other's response, but be unsure whether their message was composed before the other's. Timestamping cannot resolve an impasse. Therefore, there is no unified absolute ordering of all messages within a thread--but there is an ordering of all messages emitted by a each participant.</p> <p>In a given thread, the first message from each party has a <code>sender_order</code> value of 0, the second message sent from each party has a <code>sender_order</code> value of 1, and so forth. Note that both Alice and Bob use 0 and 1, without regard to whether the other party may be known to have used them. This gives a strong ordering with respect to each party's messages, and it means that any message can be uniquely identified in an interaction by its <code>thid</code>, the sender DID and/or key, and the <code>sender_order</code>.</p>"},{"location":"aip2/0008-message-id-and-threading/#received-orders-received_orders","title":"Received Orders (<code>received_orders</code>)","text":"<p>In an interaction, it may be useful for the recipient of a message to know if their last message was received. A <code>received_orders</code> value addresses this need, and could be included as a best practice to help detect missing messages.</p> <p>In the example above, if Alice is the sender, and Bob is identified by <code>did:sov:abcxyz</code>, then Alice is saying, \"Here's my message with index 3 (<code>sender_order</code>=3), and I'm sending it in response to your message 1 (<code>received_orders: {&lt;bob's DID&gt;: 1}</code>. Apparently Alice has been more chatty than Bob in this exchange.</p> <p>The <code>received_orders</code> field is plural to acknowledge the possibility of multiple parties. In pairwise interactions, this may seem odd. However, n-wise interactions are possible (e.g., in a doctor ~ hospital ~ patient n-wise relationship). Even in pairwise, multiple agents on either side may introduce other actors. This may happen even if an interaction is designed to be 2-party (e.g., an intermediate party emits an error unexpectedly).</p> <p>In an interaction with more parties, the <code>received_orders</code> object has a key/value pair for each <code>actor</code>/<code>sender_order</code>, where <code>actor</code> is a DID or a key for an agent:</p> <pre><code>\"received_orders\": {\"did:sov:abcxyz\":1, \"did:sov:defghi\":14}\n</code></pre> <p>Here, the <code>received_orders</code> fragment makes a claim about the last <code>sender_order</code> that the sender observed from <code>did:sov:abcxyz</code> and <code>did:sov:defghi</code>. The sender of this fragment is presumably some other DID, implying that 3 parties are participating. Any parties unnamed in <code>received_orders</code> have an undefined value for <code>received_orders</code>. This is NOT the same as saying that they have made no observable contribution to the thread. To make that claim, use the special value <code>-1</code>, as in:</p> <pre><code>\"received_orders\": {\"did:sov:abcxyz\":1, \"did:sov:defghi\":14, \"did:sov:jklmno\":-1}\n</code></pre>"},{"location":"aip2/0008-message-id-and-threading/#example_1","title":"Example","text":"<p>As an example, Alice is an issuer and she offers a credential to Bob.</p> <ul> <li>Alice sends a CRED_OFFER as the start of a new thread, <code>@id</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0.</li> <li>Bob responds with a CRED_REQUEST, <code>@id</code>=&lt;uuid2&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0, <code>received_orders:{alice:0}</code>.</li> <li>Alice sends a CRED, <code>@id</code>=&lt;uuid3&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=1, <code>received_orders:{bob:0}</code>.</li> <li>Bob responds with an ACK, <code>@id</code>=&lt;uuid4&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=1, <code>received_orders:{alice:1}</code>.</li> </ul>"},{"location":"aip2/0008-message-id-and-threading/#nested-interactions-parent-thread-id-or-pthid","title":"Nested interactions (Parent Thread ID or <code>pthid</code>)","text":"<p>Sometimes there are interactions that need to occur with the same party, while an existing interaction is in-flight.</p> <p>When an interaction is nested within another, the initiator of a new interaction can include a Parent Thread ID (<code>pthid</code>). This signals to the other party that this is a thread that is branching off of an existing interaction.</p>"},{"location":"aip2/0008-message-id-and-threading/#nested-example","title":"Nested Example","text":"<p>As before, Alice is an issuer and she offers a credential to Bob. This time, she wants a bit more information before she is comfortable providing a credential.</p> <ul> <li>Alice sends a CRED_OFFER as the start of a new thread, <code>@id</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0.</li> <li>Bob responds with a CRED_REQUEST, <code>@id</code>=&lt;uuid2&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0, <code>received_orders:{alice:0}</code>.</li> <li>Alice sends a PROOF_REQUEST, <code>@id</code>=&lt;uuid3&gt;, <code>pthid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0. Note the subthread, the parent thread ID, and the reset <code>sender_order</code> value.</li> <li>Bob sends a PROOF, <code>@id</code>=&lt;uuid4&gt;, <code>thid</code>=&lt;uuid3&gt;,<code>sender_order</code>=0, <code>received_orders:{alice:0}</code>.</li> <li>Alice sends a CRED, <code>@id</code>=&lt;uuid5&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=1, <code>received_orders:{bob:0}</code>.</li> <li>Bob responds with an ACK, <code>@id</code>=&lt;uuid6&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=1, <code>received_orders:{alice:1}</code>.</li> </ul> <p>All of the steps are the same, except the two bolded steps that are part of a nested interaction.</p>"},{"location":"aip2/0008-message-id-and-threading/#implicit-threads","title":"Implicit Threads","text":"<p>Threads reference a Message ID as the origin of the thread. This allows any message to be the start of a thread, even if not originally intended. Any message without an explicit <code>~thread</code> attribute can be considered to have the following <code>~thread</code> attribute implicitly present.</p> <pre><code>\"~thread\": {\n    \"thid\": &lt;same as @id of the outer message&gt;,\n    \"sender_order\": 0\n}\n</code></pre>"},{"location":"aip2/0008-message-id-and-threading/#implicit-replies","title":"Implicit Replies","text":"<p>A message that contains a <code>~thread</code> block with a <code>thid</code> different from the outer message <code>@id</code>, but no <code>sender_order</code> is considered an implicit reply. Implicit replies have a <code>sender_order</code> of <code>0</code> and an <code>received_orders:{other:0}</code>. Implicit replies should only be used when a further message thread is not anticipated. When further messages in the thread are expected, a full regular <code>~thread</code> block should be used.</p> <p>Example Message with am Implicit Reply:</p> <p><pre><code>{\n    \"@id\": \"&lt;@id of outer message&gt;\",\n    \"~thread\": {\n        \"thid\": \"&lt;different than @id of outer message&gt;\"\n    }\n}\n</code></pre> Effective Message with defaults in place: <pre><code>{\n    \"@id\": \"&lt;@id of outer message&gt;\",\n    \"~thread\": {\n        \"thid\": \"&lt;different than @id of outer message&gt;\"\n        \"sender_order\": 0,\n        \"received_orders\": { \"DID of sender\":0 }\n    }\n}\n</code></pre></p>"},{"location":"aip2/0008-message-id-and-threading/#reference","title":"Reference","text":"<ul> <li>Message Packaging document from Sovrin Foundation Protocol Repo</li> <li>Very brief summary of discussion from Agent Summit on Decorators</li> </ul>"},{"location":"aip2/0008-message-id-and-threading/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"aip2/0008-message-id-and-threading/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Implement threading for each message type that needs it.</li> </ul>"},{"location":"aip2/0008-message-id-and-threading/#prior-art","title":"Prior art","text":"<p>If you're aware of relevant prior-art, please add it here.</p>"},{"location":"aip2/0008-message-id-and-threading/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Using a wrapping method for threading has been discussed but most seemed in favor of the annotated method. Any remaining arguments to be made in favor of the wrapping method?</li> </ul>"},{"location":"aip2/0008-message-id-and-threading/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem. Aries Protocol Test Suite"},{"location":"aip2/0011-decorators/","title":"Aries RFC 0011: Decorators","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-01-31</li> <li>Status Note: broadly used in Indy, but not yet harmonized with DIF work on hubs.</li> <li>Start Date: 2018-12-14</li> <li>Tags: concept, decorator</li> </ul>"},{"location":"aip2/0011-decorators/#summary","title":"Summary","text":"<p>Explain how decorators work in DID communication.</p>"},{"location":"aip2/0011-decorators/#motivation","title":"Motivation","text":"<p>Certain semantic patterns manifest over and over again in communication. For example, all communication needs the pattern of testing the type of message received. The pattern of identifying a message and referencing it later is likely to be useful in a high percentage of all protocols that are ever written. A pattern that associates messages with debugging/tracing/timing metadata is equally relevant. And so forth.</p> <p>We need a way to convey metadata that embodies these patterns, without complicating schemas, bloating core definitions, managing complicated inheritance hierarchies, or confusing one another. It needs to be elegant, powerful, and adaptable.</p>"},{"location":"aip2/0011-decorators/#tutorial","title":"Tutorial","text":"<p>A decorator is an optional chunk of JSON that conveys metadata. Decorators are not declared in a core schema but rather supplementary to it. Decorators add semantic content broadly relevant to messaging in general, and not so much tied to the problem domain of a specific type of interaction.</p> <p>You can think of decorators as a sort of mixin for agent-to-agent messaging. This is not a perfect analogy, but it is a good one. Decorators in DIDComm also have some overlap (but not a direct congruence) with annotations in Java, attributes in C#, and both decorators and annotations in python.</p>"},{"location":"aip2/0011-decorators/#simple-example","title":"Simple Example","text":"<p>Imagine we are designing a protocol and associated messages to arrange meetings between two people. We might come up with a <code>meeting_proposal</code> message that looks like this:</p> <pre><code>{\n  \"@id\": \"e2987006-a18a-4544-9596-5ad0d9390c8b\",\n  \"@type\": \"did:sov:8700e296a1458aad0d93;spec/meetings/1.0/proposal\",\n  \"proposed_time\": \"2019-12-23 17:00\",\n  \"proposed_place\": \"at the cathedral, Barf\u00fcsserplatz, Basel\",\n  \"comment\": \"Let's walk through the Christmas market.\"\n}\n</code></pre> <p>Now we tackle the <code>meeting_proposal_response</code> messages. Maybe we start with something exceedingly simple, like:</p> <pre><code>{\n  \"@id\": \"d9390ce2-8ba1-4544-9596-9870065ad08a\",\n  \"@type\": \"did:sov:8700e296a1458aad0d93;spec/meetings/1.0/response\",\n  \"agree\": true,\n  \"comment\": \"See you there!\"\n}\n</code></pre> <p>But we quickly realize that the asynchronous nature of messaging will expose a gap in our message design: if Alice receives two meeting proposals from Bob at the same time, there is nothing to bind a response back to the specific proposal it addresses.</p> <p>We could extend the schema of our response so it contains an <code>thread</code> that references the <code>@id</code> of the original proposal. This would work. However, it does not satsify the DRY principle of software design, because when we tackle the protocol for negotiating a purchase between buyer and seller next week, we will need the same solution all over again. The result would be a proliferation of schemas that all address the same basic need for associating request and response. Worse, they might do it in different ways, cluttering the mental model for everyone and making the underlying patterns less obvious.</p> <p>What we want instead is a way to inject into any message the idea of a thread, such that we can easily associate responses with requests, errors with the messages that triggered them, and child interactions that branch off of the main one. This is the subject of the message threading RFC, and the solution is the <code>~thread</code> decorator, which can be added to any response:</p> <p><pre><code>{\n  \"@id\": \"d9390ce2-8ba1-4544-9596-9870065ad08a\",\n  \"@type\": \"did:sov:8700e296a1458aad0d93;spec/meetings/1.0/response\",\n  \"~thread\": {\"thid\": \"e2987006-a18a-4544-9596-5ad0d9390c8b\"},\n  \"agree\": true,\n  \"comment\": \"See you there!\"\n}\n</code></pre> This chunk of JSON is defined independent of any particular message schema, but is understood to be available in all DIDComm schemas.</p>"},{"location":"aip2/0011-decorators/#basic-conventions","title":"Basic Conventions","text":"<p>Decorators are defined in RFCs that document a general pattern such as message threading RFC or message localization. The documentation for a decorator explains its semantics and offers examples.</p> <p>Decorators are recognized by name. The name must begin with the <code>~</code> character (which is reserved in DIDComm messages for decorator use), and be a short, single-line string suitable for use as a JSON attribute name.</p> <p>Decorators may be simple key:value pairs <code>\"~foo\": \"bar\"</code>. Or they may associate a key with a more complex structure:</p> <pre><code>\"~thread\": {\n  \"thid\": \"e2987006-a18a-4544-9596-5ad0d9390c8b\",\n  \"pthid\": \"0c8be298-45a1-48a4-5996-d0d95a397006\",\n  \"sender_order\": 0\n}\n</code></pre> <p>Decorators should be thought of as supplementary to the problem-domain-specific fields of a message, in that they describe general communication issues relevant to a broad array of message types. Entities that handle messages should treat all unrecognized fields as valid but meaningless, and decorators are no exception. Thus, software that doesn't recognize a decorator should ignore it.</p> <p>However, this does not mean that decorators are necessarily optional. Some messages may intend something tied so tightly to a decorator's semantics that the decorator effectively becomes required. An example of this is the relationship between a general error reporting mechanism and the <code>~thread</code> decorator: it's not very helpful to report errors without the context that a thread provides.</p> <p>Because decorators are general by design and intent, we don't expect namespacing to be a major concern. The community agrees on decorators that everybody will recognize, and they acquire global scope upon acceptance. Their globalness is part of their utility. Effectively, decorator names are like reserved words in a shared public language of messages.</p> <p>Namespacing is also supported, as we may discover legitimate uses. When namespaces are desired, dotted name notation is used, as in <code>~mynamespace.mydecoratorname</code>. We may elaborate this topic more in the future.</p> <p>Decorators are orthogonal to JSON-LD constructs in DIDComm messages.</p>"},{"location":"aip2/0011-decorators/#versioning","title":"Versioning","text":"<p>We hope that community-defined decorators are very stable. However, new fields (a non-breaking change) might need to be added to complex decorators; occasionally, more significant changes might be necessary as well. Therefore, decorators do support semver-style versioning, but in a form that allows details to be ignored unless or until they become important. The rules are:</p> <ol> <li>As with all other aspects of DIDComm messages, unrecognized fields in decorators must be ignored.</li> <li>Version information can be appended to the name of a decorator, as in <code>~mydecorator/1</code>. Only a major version (never minor or patch) is used, since:<ul> <li>Minor version variations should not break decorator handling code.</li> <li>The dot character <code>.</code> is reserved for namespacing within field names.</li> <li>The extra complexity is not worth the small amount of value it might add.</li> </ul> </li> <li>A decorator without a version is considered to be synonymous with version 1.0, and the version-less form is preferred. This allows version numbers to be added only in the uncommon cases where they are necessary.</li> </ol>"},{"location":"aip2/0011-decorators/#decorator-scope","title":"Decorator Scope","text":"<p>A decorator may be understood to decorate (add semantics) at several different scopes. The discussion thus far has focused on message decorators, and this is by far the most important scope to understand. But there are more possibilities.</p> <p>Suppose we wanted to decorate an individual field. This can be done with a field decorator, which is a sibling field to the field it decorates. The name of decorated field is combined with a decorator suffix, as follows:</p> <p><pre><code>{\n  \"note\": \"Let's have a picnic.\",\n  \"note~l10n\": { ... }\n}\n</code></pre> In this example, taken from the localization pattern, <code>note~l10n</code> decorates <code>note</code>.</p> <p>Besides a single message or a single field, consider the following scopes as decorator targets:</p> <ul> <li>Message Family: An decorator can be declared in documentation for the   message family, explaining semantics that apply to all message instances in the   family unless overridden at a narrower scope. This is not the same as declaring the   decorator's structure to be part of the schema of a message family; this is saying   that the field values in a concrete instance of a decorator applies to all instances   of a message family. The localization pattern contemplates this usage as a way to   declare default localization semantics.</li> <li>Message Type:   A decorator can be declared in the documentation on a specific message   type. If this happens, semantics of the decorator on the message type should be   understood as overriding or enriching the semantics of that same decorator on the   parent message family, since the scope is becoming more specific.</li> <li>Message Thread or thread tree: A participant in a   thread could send a message containing nothing but the <code>~thread</code> with one or   more additional decorators inside it. This should be viewed as a statement of semantics that   apply to subsequent communications from the sender, on that thread, until further   notice or until overridden at the scope of an individual message instance. (While   powerful, applying a decorator to this scope may be a burden on receivers because   it requires them to be stateful. Therefore this usage, though theoretically possible,   may be undesirable. If community members want to explore this, they are encouraged   to discuss broadly, first.)</li> <li>Connection. It is conceivable that Alice could bundle up a set of decorators   and send them to Bob as a way of saying \"Hey, Bob: unless/until subsequent interactions   give you more specific semantics, here's a set of semantics (settings for our connection)   that you should assume for all interactions.\" (This may or may not be useful. It introduces ambiguity--should settings declared   at this scope override those at the scope of a message family or message type? It   also adds a burden of remembering to another party; some of what informs the interaction   isn't present in the bits that flow later on. Thus, this style of decorator is also   left as a possibility for future exploration and is not actively supported at present.)</li> </ul>"},{"location":"aip2/0011-decorators/#reference","title":"Reference","text":"<p>This section of this RFC will be kept up-to-date with a list of globally accepted decorators, and links to the RFCs that define them.</p> <ul> <li><code>~thread</code>: provide request/reply and threading semantics</li> <li><code>~timing</code>: timestamps, expiration, elapsed time</li> <li><code>~trace</code>: collaborative debugging and monitoring</li> <li><code>~l10n</code>: localization support</li> </ul>"},{"location":"aip2/0011-decorators/#drawbacks","title":"Drawbacks","text":"<p>By having fields that are meaningful yet not declared in core schemas, we run the risk that parsing and validation routines will fail to enforce details that are significant but invisible. We also accept the possibility that interop may look good on paper, but fail due to different understandings of important metadata.</p> <p>We believe this risk will take care of itself, for the most part, as real-life usage accumulates and decorators become a familiar and central part of the thinking for developers who work with agent-to-agent communication.</p>"},{"location":"aip2/0011-decorators/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>There is ongoing work in the <code>#indy-semantics</code> channel on Rocket.Chat to explore the concept of overlays. These are layers of additional meaning that accumulate above a schema base. Decorators as described here are quite similar in intent. There are some subtle differences, though. The most interesting is that decorators as described here may be applied to things that are not schema-like (e.g., to a message family as a whole, or to a connection, not just to an individual message).</p> <p>We may be able to resolve these two worldviews, such that decorators are viewed as overlays and inherit some overlay goodness as a result. However, it is unlikely that decorators will change significantly in form or substance as a result. We thus believe the current mental model is already RFC-worthy, and represents a reasonable foundation for immediate use.</p>"},{"location":"aip2/0011-decorators/#prior-art","title":"Prior art","text":"<p>See references to similar ../../features in programming languages like Java, C#, and Python, mentiond above.</p> <p>See also this series of blog posts about semantic gaps and the need to manage intent in a declarative style: [ Lacunas Everywhere, Bridging the Lacuna Humana, Introducing Marks, Mountains,  Molehills, and Markedness ]</p>"},{"location":"aip2/0011-decorators/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Are we doing enough about namespacing and collision avoidance with JSON-LD?</li> <li>What should we do, if anything, about versioning decorators?</li> <li>What should we do, if anything, about applying decorators to stateful scopes   like a connection or a thread?</li> </ul>"},{"location":"aip2/0011-decorators/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries RFCs: RFC 0008, RFC 0017, RFC 0015, RFC 0023, RFC 0043, RFC 0056, RFC 0075 many implemented RFCs depend on decorators... Indy Cloud Agent - Python message threading Aries Framework - .NET message threading Streetcred.id message threading Aries Cloud Agent - Python message threading, attachments Aries Static Agent - Python message threading Aries Framework - Go message threading Connect.Me message threading Verity message threading Aries Protocol Test Suite message threading"},{"location":"aip2/0015-acks/","title":"Aries RFC 0015: ACKs","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Broadly implemented, adopted into many protocols and part of AIP 1 and 2.</li> <li>Start Date: 2018-12-26</li> <li>Tags: feature</li> </ul>"},{"location":"aip2/0015-acks/#summary","title":"Summary","text":"<p>Explains how one party can send acknowledgment messages (ACKs) to confirm receipt and clarify the status of complex processes.</p>"},{"location":"aip2/0015-acks/#change-log","title":"Change log","text":"<ul> <li> <p>Mar 22, 2022: Clarification that an Ack <code>Fail</code> must not be used, and that a Report Problem must be used in its place. Remove Ack <code>Fail</code> from the RFC.</p> </li> <li> <p>Mar 25, 2020: In the ~thread decorator section of the sample in the Explicit ACKs section, 'myindex' was changed to 'sender_order' and 'lrecs' to 'received_orders'. This is in accordance with the field names as defined in RFC 0008.</p> </li> </ul>"},{"location":"aip2/0015-acks/#motivation","title":"Motivation","text":"<p>An acknowledgment or ACK is one of the most common procedures in protocols of all types. We need a flexible, powerful, and easy way to send such messages in agent-to-agent interactions.</p>"},{"location":"aip2/0015-acks/#tutorial","title":"Tutorial","text":"<p>Confirming a shared understanding matters whenever independent parties interact. We buy something on Amazon; moments later, our email client chimes to tell us of a new message with subject \"Thank you for your recent order.\" We verbally accept a new job, but don't rest easy until we've also emailed the signed offer letter back to our new boss. We change a password on an online account, and get a text at our recovery phone number so both parties know the change truly originated with the account's owner.</p> <p>When formal acknowledgments are missing, we get nervous. And rightfully so; most of us have a story of a package that was lost in the mail, or a web form that didn't submit the way we expected.</p> <p>Agents interact in very complex ways. They may use multiple transport mechanisms, across varied protocols, through long stretches of time. While we usually expect messages to arrive as sent, and to be processed as expected, a vital tool in the agent communication repertoire is the receipt of acknowledgments to confirm a shared understanding.</p>"},{"location":"aip2/0015-acks/#implicit-acks","title":"Implicit ACKs","text":"<p>Message threading includes a lightweight, automatic sort of ACK in the form of the <code>~thread.received_orders</code> field. This allows Alice to report that she has received Bob's recent message that had <code>~thread.sender_order</code> = N. We expect threading to be best practice in many use cases, and we expect interactions to often happen reliably enough and quickly enough that implicit ACKs provide high value. If you are considering ACKs but are not familiar with that mechanism, make sure you understand it, first. This RFC offers a supplement, not a replacement.</p>"},{"location":"aip2/0015-acks/#explicit-acks","title":"Explicit ACKs","text":"<p>Despite the goodness of implicit ACKs, there are many circumstances where a reply will not happen immediately. Explicit ACKs can be vital here.</p> <p>Explicit ACKS may also be vital at the end of an interaction, when work is finished: a credential has been issued, a proof has been received, a payment has been made. In such a flow, an implicit ACK meets the needs of the party who received the final message, but the other party may want explicit closure. Otherwise they can't know with confidence about the final outcome of the flow.</p> <p>Rather than inventing a new \"interaction has been completed successfully\" message for each protocol, an all-purpose <code>ack</code> message type is recommended. It looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/notification/1.0/ack\",\n  \"@id\": \"06d474e0-20d3-4cbf-bea6-6ba7e1891240\",\n  \"status\": \"OK\",\n  \"~thread\": {\n    \"thid\": \"b271c889-a306-4737-81e6-6b2f2f8062ae\",\n    \"sender_order\": 4,\n    \"received_orders\": {\"did:sov:abcxyz\": 3}\n  }\n}\n</code></pre> <p>It may also be appropriate to send an ack at other key points in an interaction (e.g., when a key rotation notice is received).</p>"},{"location":"aip2/0015-acks/#adopting-acks","title":"Adopting acks","text":"<p>As discussed in 0003: Protocols, a protocol can adopt the ack message into its own namespace. This allows the type of an ack to change from:     <code>https://didcomm.org/notification/1.0/ack</code> to something like:     <code>https://didcomm.org/otherProtocol/2.0/ack</code>. Thus, message routing logic can see the ack as part of the other protocol, and send it to the relevant handler--but still have all the standardization of generic acks.</p>"},{"location":"aip2/0015-acks/#ack-status","title":"ack status","text":"<p>The <code>status</code> field in an ack tells whether the ack is final or not with respect to the message being acknowledged. It has 2 predefined values: <code>OK</code> (which means an outcome has occurred, and it was positive); and <code>PENDING</code>, which acknowledges that no outcome is yet known.</p> <p>There is not an ack <code>status</code> of <code>FAIL</code>. In the case of a protocol failure a Report Problem message must be used to inform the other party(ies). For more details, see the next section.</p> <p>In addition, more advanced ack usage is possible. See the details in the Reference section.</p>"},{"location":"aip2/0015-acks/#relationship-to-problem-report","title":"Relationship to <code>problem-report</code>","text":"<p>Negative outcomes do not necessarily mean that something bad happened; perhaps Alice comes to hope that Bob rejects her offer to buy his house because she's found something better--and Bob does that, without any error occurring. This is not a FAIL in a problem sense; it's a FAIL in the sense that the offer to buy did not lead to the outcome Alice intended when she sent it.</p> <p>This raises the question of errors. Any time an unexpected problem arises, best practice is to report it to the sender of the message that triggered the problem. This is the subject of the problem reporting mechanism.</p> <p>A <code>problem_report</code> is inherently a sort of ACK. In fact, the <code>ack</code> message type and the <code>problem_report</code> message type are both members of the same <code>notification</code> message family. Both help a sender learn about status. Therefore, a requirement for an <code>ack</code> is that a status of <code>FAIL</code> be satisfied by a <code>problem_report</code> message.</p> <p>However, there is some subtlety in the use of the two types of messages. Some <code>ack</code>s may be sent before a final outcome, so a final <code>problem_report</code> may not be enough. As well, an ack request may be sent after a previous <code>ack</code> or <code>problem_report</code> was lost in transit. Because of these caveats, developers whose code creates or consumes acks should be thoughtful about where the two message types overlap, and where they do not. Carelessness here is likely to cause subtle, hard-to-duplicate surprises from time to time.</p>"},{"location":"aip2/0015-acks/#custom-acks","title":"Custom ACKs","text":"<p>This mechanism cannot address all possible ACK use cases. Some ACKs may require custom data to be sent, and some acknowledgment schemes may be more sophisticated or fine-grained that the simple settings offered here. In such cases, developers should write their own ACK message type(s) and maybe their own decorators. However, reusing the field names and conventions in this RFC may still be desirable, if there is significant overlap in the ../../concepts.</p>"},{"location":"aip2/0015-acks/#requesting-acks","title":"Requesting ACKs","text":"<p>A decorator, <code>~please_ack</code>, allows one agent to request an ad hoc ACK from another agent. This is described in the 0317-please-ack RFC.</p>"},{"location":"aip2/0015-acks/#reference","title":"Reference","text":""},{"location":"aip2/0015-acks/#ack-message","title":"<code>ack</code> message","text":""},{"location":"aip2/0015-acks/#status","title":"<code>status</code>","text":"<p>Required, values <code>OK</code> or <code>PENDING</code>. As discussed above, this tells whether the ack is final or not with respect to the message being acknowledged.</p>"},{"location":"aip2/0015-acks/#threadthid","title":"<code>~thread.thid</code>","text":"<p>Required. This links the <code>ack</code> back to the message that requested it.</p> <p>All other fields in an <code>ack</code> are present or absent per requirements of ordinary messages.</p>"},{"location":"aip2/0015-acks/#drawbacks-and-alternatives","title":"Drawbacks and Alternatives","text":"<p>None identified.</p>"},{"location":"aip2/0015-acks/#prior-art","title":"Prior art","text":"<p>See notes above about the implicit ACK mechanism in <code>~thread.received_orders</code>.</p>"},{"location":"aip2/0015-acks/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Muliplexed acks. How do you supply an ACK to all of Alice's agents instead of just to the one who involved in the current protocol?</li> </ul>"},{"location":"aip2/0015-acks/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes RFC 0036: Issue Credential Protocol ACKs are adopted by this protocol. RFC 0037: Present Proof Protocol ACKs are adopted by this protocol. RFC 0193: Coin Flip Protocol ACKs are adopted as a subprotocol. Aries Cloud Agent - Python Contributed by the Government of British Columbia."},{"location":"aip2/0017-attachments/","title":"Aries RFC 0017: Attachments","text":"<ul> <li>Authors: Daniel Hardman, Sam Curren, Andrew Whitehead</li> <li>Status: ACCEPTED</li> <li>Since: 2019-01-31</li> <li>Status Note: Used in a number of other RFCs.</li> <li>Start Date: 2018-12-24</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0017-attachments/#summary","title":"Summary","text":"<p>Explains the three canonical ways to attach data to an agent message.</p>"},{"location":"aip2/0017-attachments/#motivation","title":"Motivation","text":"<p>DIDComm messages use a structured format with a defined schema and a small inventory of scalar data types (string, number, date, etc). However, it will be quite common for messages to supplement formalized exchange with arbitrary data--images, documents, or types of media not yet invented.</p> <p>We need a way to \"attach\" such content to DIDComm messages. This method must be flexible, powerful, and usable without requiring new schema updates for every dynamic variation.</p>"},{"location":"aip2/0017-attachments/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0017-attachments/#messages-versus-data","title":"Messages versus Data","text":"<p>Before explaining how to associate data with a message, it is worth pondering exactly how these two categories of information differ. It is common for newcomers to DIDComm to argue that messages are just data, and vice versa. After all, any data can be transmitted over DIDComm; doesn't that turn it into a message? And any message can be saved; doesn't that make it data?</p> <p>While it is true that messages and data are highly related, some semantic differences matter:</p> <ul> <li> <p>Messages are primarily about communication. Their meaning is tied to a communication context. Messages are a mechanism whereby state evolves in a protocol. Protocols are versioned according to the structure and semantics of messages. Messages are usually small, consisting of a modest number of fields with a structure that's focused on furthering the goals of their protocol.</p> </li> <li> <p>Data has meaning at rest, in many different DIDComm protocols, or in important contexts beyond DIDComm. Data may be very large and very complex. It may come in formats that are quite independent from DIDComm, versioned independently from the protocols that share it. Data may be produced, consumed or handled as part of a protocol, but the actual content of the data is usually not where processing at the protocol level focuses. In agent codebases, it would be common for data handling to be implemented in different classes or libraries from the handlers for messages.</p> </li> </ul> <p>Some examples:</p> <ul> <li> <p>A protocol to negotiate the release of medical records might cause X-Rays, genomes, and many other artifacts to be transmitted. These artifacts are data, whereas the information packets that arrange the transmission and provide a carrying mechanism for the artifacts are messages.</p> </li> <li> <p>A DIDComm message can be used to report an error. Descriptive parameters that change how the error is processed are probably part of the message, whereas a log file that provides supporting information should be thought of as data rather than the message.</p> </li> <li> <p>The protocol for issuing credentials consists of messages that flow through certain steps. One of the steps eventually delivers a credential. The credential is data; it has meaning even when the protocol is complete, and the protocol version may evolve independent of the data format of the credential itself. The fact that the credential is transmitted through a message does not change the credential's primary status as data.</p> </li> <li> <p>A protocol to schedule a venue for an event might produce a confirmation message when it finishes. This message might include a map of the venue, instructions about how to unlock the gate, pictures of certain resources, and so forth. This collateral is data, whereas the messages that signal progression through the steps of scheduling are not.</p> </li> <li> <p>The DID Exchange Protocol exchanges messages to establish a connection between two parties. Part of what's exchanged is a DID Doc. The DID Doc is more like data than it is like an ordinary message, since it has meaning at rest and outside the protocol.</p> </li> </ul> <p>The line between these two ../../concepts may not be perfectly crisp in all cases, and that is okay. It is clear enough, most of the time, to provide context for the central question of this RFC, which is:</p> <p>How do we send data along with messages?</p>"},{"location":"aip2/0017-attachments/#3-ways","title":"3 Ways","text":"<p>Data can be \"attached\" to DIDComm messages in 3 ways:</p> <ol> <li>Inlining</li> <li>Embedding</li> <li>Appending</li> </ol>"},{"location":"aip2/0017-attachments/#inlining","title":"Inlining","text":"<p>In inlining, data is directly assigned as the value paired with a JSON key in a DIDComm message. For example, a message about arranging a rendezvous may inline data about a location: </p> <p>This inlined data is in Google Maps pinning format. It has a meaning at rest, outside the message that conveys it, and the versioning of its structure may evolve independently of the versioning of the rendezvous protocol.</p> <p>Only JSON data can be inlined, since any other data format would break JSON format rules.</p>"},{"location":"aip2/0017-attachments/#embedding","title":"Embedding","text":"<p>In embedding, a JSON data structure called an attachment descriptor is assigned as the value paired with a JSON key in a DIDComm message. (Or, an array of attachment descriptors could be assigned.) By convention, the key name for such attachment fields ends with <code>~attach</code>, making it a field-level decorator that can share common handling logic in agent code. The attachment descriptor structure describes the MIME type and other properties of the data, in much the same way that MIME headers and body describe and contain an attachment in an email message. Given an imaginary protocol that photographers could use to share their favorite photo with friends, the embedded data might manifest like this:</p> <p></p> <p>Embedding is a less direct mechanism than inlining, because the data is no longer readable by a human inspecting the message; it is base64url-encoded instead. A benefit of this approach is that the data can be any MIME type instead of just JSON, and that the data comes with useful metadata that can facilitate saving it as a separate file.</p>"},{"location":"aip2/0017-attachments/#appending","title":"Appending","text":"<p>Appending is accomplished using the <code>~attach</code> decorator, which can be added to any message to include arbitrary data. The decorator is an array of attachment descriptor structures (the same structure used for embedding). For example, a message that conveys evidence found at a crime scene might include the following decorator:</p> <p></p>"},{"location":"aip2/0017-attachments/#choosing-the-right-approach","title":"Choosing the right approach","text":"<p>These methods for attaching sit along a continuum that is somewhat like the continuum between strong, statically typed languages versus dynamic, duck-typed languages in programming. The more strongly typed the attachments are, the more strongly bound the attachments are to the protocol that conveys them. Each choice has advantages and disadvantages.</p> <p></p> <p>Inlined data is strongly typed; the schema for its associated message must specify the name of the data field, plus what type of data it contains. Its format is always some kind of JSON--often JSON-LD with a <code>@type</code> and/or <code>@context</code> field to provide greater clarity and some independence of versioning. Simple and small data is the best fit for inlining. As mentioned earlier, the Connection Protocol inlines a DID Doc in its <code>connection_request</code> and <code>connection_response</code> messages.</p> <p>Embedded data is still associated with a known field in the message schema, but it can have a broader set of possible formats. A credential exchange protocol might embed a credential in the final message that does credential issuance.</p> <p>Appended attachments are the most flexible but also the hardest to run through semantically sophisticated processing. They do not require any specific declaration in the schema of a message, although they can be referenced in fields defined by the schema via their nickname (see below). A protocol that needs to pass an arbitrary collection of artifacts without strong knowledge of their semantics might find this helpful, as in the example mentioned above, where scheduling a venue causes various human-usable payloads to be delivered.</p>"},{"location":"aip2/0017-attachments/#ids-for-attachments","title":"IDs for attachments","text":"<p>The <code>@id</code> field within an attachment descriptor is used to refer unambiguously to an appended (or less ideally, embedded) attachment, and works like an HTML anchor. It is resolved relative to the root <code>@id</code> of the message and only has to be unique within a message. For example, imagine a fictional message type that's used to apply for an art scholarship, that requires photos of art demonstrating techniques A, B, and C. We could have 3 different attachment descriptors--but what if the same work of art demonstrates both technique A and technique B? We don't want to attach the same photo twice...</p> <p>What we can do is stipulate that the datatype of <code>A_pic</code>, <code>B_pic</code>, and <code>C_pic</code> is an attachment reference, and that the references will point to appended attachments. A fragment of the result might look like this:</p> <p></p> <p>Another example of nickname use appeared in the first example of appended attachments above, where the <code>notes</code> field refered to the <code>@id</code>s of the various attachments.</p> <p>This indirection offers several benefits:</p> <ul> <li>The same attachment may be referenced at more than one place in the schema, without duplicating the content.</li> <li>The message may now include any number of attachments besides the 3 that are required, and mingle them freely with the others. (In our example, perhaps the student wants to add side and overhead shots of each work of art, not just front views).</li> <li>Attachments may now have formal semantics, instead of requiring human intelligence to handle. (How many times have we written emails with multiple attachments, and added verbiage like, \"My photo of the door is attached as image1.jpeg; my photo of the damaged trunk is attached as image2.jpeg\"?)</li> </ul> <p>We could use this same technique with embedded attachments (that is, assign a nickname to an embedded attachment, and refer to that nickname in another field where attached data could be embedded), but this is not considered best practice. The reason is that it requires a field in the schema to have two possible data types--one a string that's a nickname reference, and one an attachment descriptor. Generally, we like fields to have a single datatype in a schema.</p>"},{"location":"aip2/0017-attachments/#content-formats","title":"Content Formats","text":"<p>There are multiple ways to include content in an attachment. Only one method should be used per attachment.</p>"},{"location":"aip2/0017-attachments/#base64url","title":"base64url","text":"<p>This content encoding is an obvious choice for any content different than JSON. You can embed content of any type using this method. Examples are plentiful throughout the document. Note that this encoding is always base64url encoding, not plain base64, and that padding is not required. Code that reads this encoding SHOULD tolerate the presence or absence of padding and base64 versus base64url encodings equally well, but code that writes this encoding SHOULD omit the padding to guarantee alignment with encoding rules in the JOSE (JW*) family of specs.</p>"},{"location":"aip2/0017-attachments/#json","title":"json","text":"<p>If you are embedding an attachment that is JSON, you can embed it directly in JSON format to make access easier, by replacing <code>data.base64</code> with <code>data.json</code>, where the value assigned to <code>data.json</code> is the attached content:</p> <p></p> <p>This is an overly trivial example of GeoJSON, but hopefully it illustrates the technique. In cases where there is no mime type to declare, it may be helpful to use JSON-LD's <code>@type</code> construct to clarify the specific flavor of JSON in the embedded attachment.</p>"},{"location":"aip2/0017-attachments/#links","title":"links","text":"<p>All examples discussed so far include an attachment by value--that is, the attachment's bytes are directly inlined in the message in some way. This is a useful mode of data delivery, but it is not the only mode.</p> <p>Another way that attachment data can be incorporated is by reference. For example, you can link to the content on a web server by replacing <code>data.base64</code> or <code>data.json</code> with <code>data.links</code> in an attachment descriptor:</p> <p></p> <p>When you provide such a link, you are creating a logical association between the message and an attachment that can be fetched separately. This makes it possible to send brief descriptors of attachments and to make the downloading of the heavy content optional (or parallelizable) for the recipient.</p> <p>The <code>links</code> field is plural (an array) to allow multiple locations to be offered for the same content. This allows an agent to fetch attachments using whichever mechanism(s) are best suited to its individual needs and capabilities.</p>"},{"location":"aip2/0017-attachments/#supported-uri-types","title":"Supported URI Types","text":"<p>The set of supported URI types in an attachment link is limited to:</p> <ul> <li>HTTP</li> <li>HTTPS</li> </ul> <p>Additional URI types may be added via updates to this RFC.</p> <p>If an attachment link with an unsupported URI is received, the agent SHOULD respond with a Problem Report indicated the problem.</p> <p>An ecosystem (coordinating set of agents working in a specific business area) may agree to support other URI types within that ecosystem. As such, implementing a mechanism to easily add support for other attachment link URI types might be useful, but is not required.</p>"},{"location":"aip2/0017-attachments/#signing-attachments","title":"Signing Attachments","text":"<p>In some cases it may be desirable to sign an attachment in addition to or instead of signing the message as a whole. Consider a home-buying protocol; the home inspection needs to be signed even when it is removed from a messaging flow. Attachments may also be signed by a party separate from the sender of the message, or using a different signing key when the sender is performing key rotation.</p> <p>Embedded and appended attachments support signatures by the addition of a <code>data.jws</code> field containing a signature in JWS (RFC 7515) format with Detached Content. The payload of the JWS is the raw bytes of the attachment, appropriately base64url-encoded per JWS rules. If these raw bytes are incorporated by value in the DIDComm message, they are already base64url-encoded in <code>data.base64</code> and are thus directly substitutable for the suppressed <code>data.jws.payload</code> field; if they are externally referenced, then the bytes must be fetched via the URI in <code>data.links</code> and base64url-encoded before the JWS can be fully reconstituted. Signatures over inlined JSON attachments are not currently defined as this depends upon a canonical serialization for the data.</p> <p>Sample JWS-signed attachment:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/xhomebuy/1.0/home_insp\",\n  \"inspection_date\": \"2020-03-25\",\n  \"inspection_address\": \"123 Villa de Las Fuentes, Toledo, Spain\",\n  \"comment\": \"Here's that report you asked for.\",\n  \"report~attach\": {\n    \"mime-type\": \"application/pdf\",\n    \"filename\": \"Garcia-inspection-March-25.pdf\",\n    \"data\": {\n      \"base64\": \"eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ... (bytes omitted to shorten)\",\n      \"jws\": {\n        // payload: ...,  &lt;-- omitted: refer to base64 content when validating\n        \"header\": {\n          \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n        },\n        \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n        \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n      }\n    }\n  }\n}\n</code></pre> <p>Here, the JWS structure inlines a public key value in did:key format within the unprotected header's <code>kid</code> field. It may also use a DID URL to reference a key within a resolvable DIDDoc. Supported DID URLs should specify a timestamp and/or version for the containing document.</p> <p>The JWS protected header consists of at least the following parameter indicating an Edwards curve digital signature:</p> <pre><code>{\n  \"alg\": \"EdDSA\"\n}\n</code></pre> <p>Additional protected and unprotected header parameters may be included in the JWS and must be ignored by implementations if not specifically supported. Any registered header parameters defined by the JWS RFC must be used according to the specification if present.</p> <p>Multiple signatures may be included using the JWS General Serialization syntax. When a single signature is present, the Flattened Serialization syntax should be preferred. Because each JWS contains an unprotected header with the signing key information, the JWS Compact Serialization cannot be supported.</p>"},{"location":"aip2/0017-attachments/#size-considerations","title":"Size Considerations","text":"<p>DIDComm messages should be small, as a general rule. Just as it's a bad idea to send email messages with multi-GB attachments, it would be bad to send DIDComm messages with huge amounts of data inside them. Remember, a message is about advancing a protocol; usually that can be done without gigabytes or even megabytes of JSON fields. Remember as well that DIDComm messages may be sent over channels having size constraints tied to the transport--an HTTP POST or Bluetooth or NFC or AMQP payload of more than a few MB may be problematic.</p> <p>Size pressures in messaging are likely to come from attached data. A good rule of thumb might be to not make DIDComm messages bigger than email or MMS messages--whenever more data needs to be attached, use the inclusion-by-reference technique to allow the data to be fetched separately.</p>"},{"location":"aip2/0017-attachments/#security-implications","title":"Security Implications","text":"<p>Attachments are a notorious vector for malware and mischief with email. For this reason, agents that support attachments MUST perform input validation on attachments, and MUST NOT invoke risky actions on attachments until such validation has been performed. The status of input validation with respect to attachment data MUST be reflected in the Message Trust Context associated with the data's message.</p>"},{"location":"aip2/0017-attachments/#privacy-implications","title":"Privacy Implications","text":"<p>When attachments are inlined, they enjoy the same security and transmission guarantees as all agent communication. However, given the right context, a large inlined attachment may be recognizable by its size, even if it is carefully encrypted.</p> <p>If attachment content is fetched from an external source, then new complications arise. The security guarantees may change. Data streamed from a CDN may be observable in flight. URIs may be correlating. Content may not be immutable or tamper-resistant.</p> <p>However, these issues are not necessarily a problem. If a DIDComm message wants to attach a 4 GB ISO file of a linux distribution, it may be perfectly fine to do so in the clear. Downloading it is unlikely to introduce strong correlation, encryption is unnecessary, and the torrent itself prevents malicious modification.</p> <p>Code that handles attachments will need to use wise policy to decide whether attachments are presented in a form that meets its needs.</p>"},{"location":"aip2/0017-attachments/#reference","title":"Reference","text":""},{"location":"aip2/0017-attachments/#attachment-descriptor-structure","title":"Attachment Descriptor structure","text":"<ul> <li> <p><code>@id</code>: A JSON-LD construct that uniquely identifies attached content within the scope of a given message. Recommended on appended attachment descriptors. Possible but generally unused on embedded attachment descriptors. Never required if no references to the attachment exist; if omitted, then there is no way to refer to the attachment later in the thread, in error messages, and so forth. Because <code>@id</code> is used to compose URIs, it is recommended that this name be brief and avoid spaces and other characters that require URI escaping.</p> </li> <li> <p><code>description</code>: An optional human-readable description of the content.</p> </li> <li> <p><code>filename</code>: A hint about the name that might be used if this attachment is persisted as a file. It is not required, and need not be unique. If this field is present and <code>mime-type</code> is not, the extension on the filename may be used to infer a MIME type.</p> </li> <li> <p><code>mime-type</code>: Describes the MIME type of the attached content. Optional but recommended.</p> </li> <li> <p><code>lastmod_time</code>: A hint about when the content in this attachment was last modified.</p> </li> <li> <p><code>byte_count</code>: Optional, and mostly relevant when content is included by reference instead of by value. Lets the receiver guess how expensive it will be, in time, bandwidth, and storage, to fully fetch the attachment.</p> </li> <li> <p><code>data</code>: A JSON object that gives access to the actual content of the attachment. Contains the following subfields:</p> </li> <li> <p><code>jws</code>: A JSON Web Signature over the content of the attachment. Optional.</p> </li> <li> <p><code>sha256</code>: The hash of the content. Optional. Used as an integrity check if   content is inlined. if content is only referenced, then including this field   makes the content tamper-evident. This may be redundant, if the content is   stored in an inherently immutable container like content-addressable storage.   This may also be undesirable, if dynamic content at a specified link is   beneficial. Including a hash without including a way to fetch the content via   link is a form of proof of existence.</p> </li> <li> <p><code>links</code>: A list of zero or more locations at which the content may be fetched.   Optional.</p> </li> <li> <p><code>base64</code>: Base64url-encoded data, when representing arbitrary content inline instead   of via <code>links</code>. Optional.</p> </li> <li> <p><code>json</code>: Directly embedded JSON data, when representing content inline instead of   via <code>links</code>, and when the content is natively conveyable as JSON. Optional.</p> </li> </ul>"},{"location":"aip2/0017-attachments/#drawbacks","title":"Drawbacks","text":"<p>By providing 3 different choices, we impose additional complexity on agents that will receive messages. They have to handle attachments in 3 different modes.</p>"},{"location":"aip2/0017-attachments/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Originally, we only proposed the most flexible method of attaching--appending. However, feedback from the community suggested that stronger binding to schema was desirable. Inlining was independently invented, and is suggested by JSON-LD anyway. Embedding without appending eliminates some valuable ../../features such as unnamed and undeclared ad-hoc attachments. So we ended up wanting to support all 3 modes.</p>"},{"location":"aip2/0017-attachments/#prior-art","title":"Prior art","text":"<p>Multipart MIME (see RFCs 822, 1341, and 2045) defines a mechanism somewhat like this. Since we are using JSON instead of email messages as the core model, we can't use these mechanisms directly. However, they are an inspiration for what we are showing here.</p>"},{"location":"aip2/0017-attachments/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>N/A</li> </ul>"},{"location":"aip2/0017-attachments/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python in credential exchange Streetcred.id Commercial mobile and web app built using Aries Framework - .NET"},{"location":"aip2/0019-encryption-envelope/","title":"Aries RFC 0019: Encryption Envelope","text":"<ul> <li>Authors: Kyle Den Hartog, Stephen Curran, Sam Curren, Mike Lodder</li> <li>Status: ADOPTED</li> <li>Since: 2019-05-04</li> <li>Status Note:  </li> <li>Supersedes: INDY 0028 Wire Level Format</li> <li>Start Date: 2018-07-10 (approximate, backdated)</li> <li>Tags: feature</li> </ul>"},{"location":"aip2/0019-encryption-envelope/#summary","title":"Summary","text":"<p>There are two layers of messages that combine to enable interoperable self-sovereign agent-to-agent communication. At the highest level are DIDComm Plaintext Messages - messages sent between identities to accomplish some shared goal (e.g., establishing a connection, issuing a verifiable credential, sharing a chat). DIDComm Plaintext Messages are delivered via the second, lower layer of messaging - DIDComm Encrypted Envelopes. A DIDComm Encrypted Envelope is a wrapper (envelope) around a plaintext message to permit secure sending and routing. A plaintext message going from its sender to its receiver passes through many agents, and an encryption envelope is used for each hop of the journey.</p> <p>This RFC describes the DIDComm Encrypted Envelope format and the <code>pack()</code> and <code>unpack()</code> functions that implement this format.</p>"},{"location":"aip2/0019-encryption-envelope/#motivation","title":"Motivation","text":"<p>Encryption envelopes use a standard format built on JSON Web Encryption - RFC 7516. This format is not captive to Aries; it requires no special Aries worldview or Aries dependencies to implement. Rather, it is a general-purpose solution to the question of how to encrypt, decrypt, and route messages as they pass over any transport(s). By documenting the format here, we hope to provide a point of interoperability for developers of agents inside and outside the Aries ecosystem.</p> <p>We also document how Aries implements its support for the DIDComm Encrypted Envelope format through the <code>pack()</code> and <code>unpack()</code> functions. For developers of Aries, this is a sort of design doc; for those who want to implement the format in other tech stacks, it may be a useful reference.</p>"},{"location":"aip2/0019-encryption-envelope/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0019-encryption-envelope/#assumptions","title":"Assumptions","text":"<p>We assume that each sending agent knows:</p> <ul> <li>Its intended recipient(s).</li> <li>What encryption (if any) is appropriate.</li> <li>If encryption will be used, a public key of the receiving agent.</li> <li>The physical endpoint to use for the receiver, and the appropriate transport protocol (https, zmq, etc.).</li> </ul> <p>The assumptions can be made because either the message is being sent to an agent within the sending agent's domain and so the sender knows the internal configuration of agents, or the message is being sent outside the sending agent's domain and interoperability requirements are in force to define the sending agent's behaviour.</p>"},{"location":"aip2/0019-encryption-envelope/#example-scenario","title":"Example Scenario","text":"<p>The example of Alice and Bob's sovereign domains is used for illustrative purposes in defining this RFC.</p> <p></p> <p>In the diagram above:</p> <ul> <li>Alice has</li> <li>1 Edge agent - \"1\"</li> <li>1 Routing agent - \"2\"</li> <li>1 Domain Endpoint - \"8\"</li> <li>Bob has</li> <li>3 Edge Agents - \"4\", \"5\" and \"6\"<ul> <li>\"6\" is an Edge agent in the cloud, \"4\" and \"5\" are physical devices.</li> </ul> </li> <li>1 Routing agent - \"3\"</li> <li>1 Domain Endpoint - \"9\"</li> </ul> <p>For the purposes of this discussion we are defining the Encryption Envelope agent message flow to be:</p> <p>1 \u2192 2 \u2192 8 \u2192 9 \u2192 3 \u2192 4</p> <p>However, that flow is just one of several that could match this configuration. What we know for sure is that:</p> <ul> <li>1 is the Sender agent in this case and so must send the first or original message.</li> <li>9 is the Domain Endpoint of Bob's domain and so must receive the message as an Encrypted Envelope.</li> <li>4 is the Receiver in this case and so must receive (and should be able to read) the first or original message.</li> </ul>"},{"location":"aip2/0019-encryption-envelope/#encrypted-envelopes","title":"Encrypted Envelopes","text":"<p>An encrypted envelope is used to transport any plaintext message from one agent directly to another. In our example message flow above, there are five encrypted envelopes sent, one for each hop in the flow. The process to send an encrypted envelope consists of the following steps:</p> <ul> <li>Call the standard function <code>pack()</code> to wrap the plaintext message</li> <li>Send the encrypted envelope using the transport protocol defined by the receiving endpoint</li> <li>Receive the encrypted envelope</li> <li>Call the standard function <code>unpack()</code> to retrieve the plaintext message (and possibly its provenance) from the encrypted envelope</li> </ul> <p>This is repeated with each hop, but the encrypted envelopes are nested, such that the plaintext is never visible until it reaches its final recipient.</p>"},{"location":"aip2/0019-encryption-envelope/#implementation","title":"Implementation","text":"<p>We will describe the pack and unpack algorithms, and their output, in terms of Aries' initial implementation, which may evolve over time. Other implementations could be built, but they would need to emit and consume similar inputs and outputs.</p> <p>The data structures emitted and consumed by these algorithms are described in a formal schema.</p>"},{"location":"aip2/0019-encryption-envelope/#authcrypt-mode-vs-anoncrypt-mode","title":"Authcrypt mode vs. Anoncrypt mode","text":"<p>When packing and unpacking are done in a way that the sender is anonymous, we say that we are in anoncrypt mode. When the sender is revealed, we are in authcrypt mode. Authcrypt mode reveals the sender to the recipient only; it is not the same as a non-repudiable signature. See the RFC about non-repudiable signatures, and this discussion about the theory of non-repudiation.</p>"},{"location":"aip2/0019-encryption-envelope/#pack-message","title":"Pack Message","text":""},{"location":"aip2/0019-encryption-envelope/#pack_message-interface","title":"pack_message() interface","text":"<p>packed_message = pack_message(wallet_handle, message, receiver_verkeys, sender_verkey)</p>"},{"location":"aip2/0019-encryption-envelope/#pack_message-params","title":"pack_message() Params:","text":"<ul> <li>wallet_handle: handle to the wallet that contains the sender's secrets.</li> <li>message: the message (plaintext, or nested encrypted envelope) as a string. If it's JSON object it should be in string format first</li> <li>receiver_verkeys: a list of recipient verkeys as string containing a JSON array</li> <li>sender_verkey: the sender's verkey as a string. This verkey is used to look up the sender's private key so the wallet can put supply it as input to the encryption algorithm. When an empty string (\"\") is passed in this parameter, anoncrypt mode is used</li> </ul>"},{"location":"aip2/0019-encryption-envelope/#pack_message-return-value-authcrypt-mode","title":"pack_message() return value (Authcrypt mode)","text":"<p>This is an example of an outputted message encrypting for two verkeys using Authcrypt.</p> <pre><code>{\n    \"protected\": \"eyJlbmMiOiJ4Y2hhY2hhMjBwb2x5MTMwNV9pZXRmIiwidHlwIjoiSldNLzEuMCIsImFsZyI6IkF1dGhjcnlwdCIsInJlY2lwaWVudHMiOlt7ImVuY3J5cHRlZF9rZXkiOiJMNVhEaEgxNVBtX3ZIeFNlcmFZOGVPVEc2UmZjRTJOUTNFVGVWQy03RWlEWnl6cFJKZDhGVzBhNnFlNEpmdUF6IiwiaGVhZGVyIjp7ImtpZCI6IkdKMVN6b1d6YXZRWWZOTDlYa2FKZHJRZWpmenRONFhxZHNpVjRjdDNMWEtMIiwiaXYiOiJhOEltaW5zdFhIaTU0X0otSmU1SVdsT2NOZ1N3RDlUQiIsInNlbmRlciI6ImZ0aW13aWlZUkc3clJRYlhnSjEzQzVhVEVRSXJzV0RJX2JzeERxaVdiVGxWU0tQbXc2NDE4dnozSG1NbGVsTThBdVNpS2xhTENtUkRJNHNERlNnWkljQVZYbzEzNFY4bzhsRm9WMUJkREk3ZmRLT1p6ckticUNpeEtKaz0ifX0seyJlbmNyeXB0ZWRfa2V5IjoiZUFNaUQ2R0RtT3R6UkVoSS1UVjA1X1JoaXBweThqd09BdTVELTJJZFZPSmdJOC1ON1FOU3VsWXlDb1dpRTE2WSIsImhlYWRlciI6eyJraWQiOiJIS1RBaVlNOGNFMmtLQzlLYU5NWkxZajRHUzh1V0NZTUJ4UDJpMVk5Mnp1bSIsIml2IjoiRDR0TnRIZDJyczY1RUdfQTRHQi1vMC05QmdMeERNZkgiLCJzZW5kZXIiOiJzSjdwaXU0VUR1TF9vMnBYYi1KX0pBcHhzYUZyeGlUbWdwWmpsdFdqWUZUVWlyNGI4TVdtRGR0enAwT25UZUhMSzltRnJoSDRHVkExd1Z0bm9rVUtvZ0NkTldIc2NhclFzY1FDUlBaREtyVzZib2Z0d0g4X0VZR1RMMFE9In19XX0=\",\n    \"iv\": \"ZqOrBZiA-RdFMhy2\",\n    \"ciphertext\": \"K7KxkeYGtQpbi-gNuLObS8w724mIDP7IyGV_aN5AscnGumFd-SvBhW2WRIcOyHQmYa-wJX0MSGOJgc8FYw5UOQgtPAIMbSwVgq-8rF2hIniZMgdQBKxT_jGZS06kSHDy9UEYcDOswtoLgLp8YPU7HmScKHSpwYY3vPZQzgSS_n7Oa3o_jYiRKZF0Gemamue0e2iJ9xQIOPodsxLXxkPrvvdEIM0fJFrpbeuiKpMk\",\n    \"tag\": \"kAuPl8mwb0FFVyip1omEhQ==\"\n}\n</code></pre> <p>The base64URL encoded <code>protected</code> decodes to this: <pre><code>{\n    \"enc\": \"xchacha20poly1305_ietf\",\n    \"typ\": \"JWM/1.0\",\n    \"alg\": \"Authcrypt\",\n    \"recipients\": [\n        {\n            \"encrypted_key\": \"L5XDhH15Pm_vHxSeraY8eOTG6RfcE2NQ3ETeVC-7EiDZyzpRJd8FW0a6qe4JfuAz\",\n            \"header\": {\n                \"kid\": \"GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL\",\n                \"iv\": \"a8IminstXHi54_J-Je5IWlOcNgSwD9TB\",\n                \"sender\": \"ftimwiiYRG7rRQbXgJ13C5aTEQIrsWDI_bsxDqiWbTlVSKPmw6418vz3HmMlelM8AuSiKlaLCmRDI4sDFSgZIcAVXo134V8o8lFoV1BdDI7fdKOZzrKbqCixKJk=\"\n            }\n        },\n        {\n            \"encrypted_key\": \"eAMiD6GDmOtzREhI-TV05_Rhippy8jwOAu5D-2IdVOJgI8-N7QNSulYyCoWiE16Y\",\n            \"header\": {\n                \"kid\": \"HKTAiYM8cE2kKC9KaNMZLYj4GS8uWCYMBxP2i1Y92zum\",\n                \"iv\": \"D4tNtHd2rs65EG_A4GB-o0-9BgLxDMfH\",\n                \"sender\": \"sJ7piu4UDuL_o2pXb-J_JApxsaFrxiTmgpZjltWjYFTUir4b8MWmDdtzp0OnTeHLK9mFrhH4GVA1wVtnokUKogCdNWHscarQscQCRPZDKrW6boftwH8_EYGTL0Q=\"\n            }\n        }\n    ]\n}\n</code></pre></p>"},{"location":"aip2/0019-encryption-envelope/#pack-output-format-authcrypt-mode","title":"pack output format (Authcrypt mode)","text":"<pre><code>    {\n        \"protected\": \"b64URLencoded({\n            \"enc\": \"xchachapoly1305_ietf\",\n            \"typ\": \"JWM/1.0\",\n            \"alg\": \"Authcrypt\",\n            \"recipients\": [\n                {\n                    \"encrypted_key\": base64URLencode(libsodium.crypto_box(my_key, their_vk, cek, cek_iv))\n                    \"header\": {\n                          \"kid\": \"base58encode(recipient_verkey)\",\n                           \"sender\" : base64URLencode(libsodium.crypto_box_seal(their_vk, base58encode(sender_vk)),\n                            \"iv\" : base64URLencode(cek_iv)\n                }\n            },\n            ],\n        })\",\n        \"iv\": &lt;b64URLencode(iv)&gt;,\n        \"ciphertext\": b64URLencode(encrypt_detached({'@type'...}, protected_value_encoded, iv, cek),\n        \"tag\": &lt;b64URLencode(tag)&gt;\n    }\n</code></pre>"},{"location":"aip2/0019-encryption-envelope/#authcrypt-pack-algorithm","title":"Authcrypt pack algorithm","text":"<ol> <li>generate a content encryption key (symmetrical encryption key)</li> <li>encrypt the CEK for each recipient's public key using Authcrypt (steps below)<ol> <li>set <code>encrypted_key</code> value to base64URLencode(libsodium.crypto_box(my_key, their_vk, cek, cek_iv))<ul> <li>Note it this step we're encrypting the cek, so it can be decrypted by the recipient</li> </ul> </li> <li>set <code>sender</code> value to base64URLencode(libsodium.crypto_box_seal(their_vk, sender_vk_string))<ul> <li>Note in this step we're encrypting the sender_verkey to protect sender anonymity</li> </ul> </li> <li>base64URLencode(cek_iv) and set to <code>iv</code> value in the header<ul> <li>Note the cek_iv in the header is used for the <code>encrypted_key</code> where as <code>iv</code> is for ciphertext</li> </ul> </li> </ol> </li> <li>base64URLencode the <code>protected</code> value</li> <li>encrypt the <code>message</code> using libsodium.crypto_aead_chacha20poly1305_ietf_encrypt_detached(message, protected_value_encoded, iv, cek) this is the ciphertext.</li> <li>base64URLencode the iv, ciphertext, and tag then serialize the format into the output format listed above.</li> </ol> <p>For a reference implementation, see https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/commands/crypto.rs</p>"},{"location":"aip2/0019-encryption-envelope/#pack_message-return-value-anoncrypt-mode","title":"pack_message() return value (Anoncrypt mode)","text":"<p>This is an example of an outputted message encrypted for two verkeys using Anoncrypt.</p> <pre><code>{\n    \"protected\": \"eyJlbmMiOiJ4Y2hhY2hhMjBwb2x5MTMwNV9pZXRmIiwidHlwIjoiSldNLzEuMCIsImFsZyI6IkFub25jcnlwdCIsInJlY2lwaWVudHMiOlt7ImVuY3J5cHRlZF9rZXkiOiJYQ044VjU3UTF0Z2F1TFcxemdqMVdRWlEwV0RWMFF3eUVaRk5Od0Y2RG1pSTQ5Q0s1czU4ZHNWMGRfTlpLLVNNTnFlMGlGWGdYRnZIcG9jOGt1VmlTTV9LNWxycGJNU3RqN0NSUHNrdmJTOD0iLCJoZWFkZXIiOnsia2lkIjoiR0oxU3pvV3phdlFZZk5MOVhrYUpkclFlamZ6dE40WHFkc2lWNGN0M0xYS0wifX0seyJlbmNyeXB0ZWRfa2V5IjoiaG5PZUwwWTl4T3ZjeTVvRmd0ZDFSVm05ZDczLTB1R1dOSkN0RzRsS3N3dlljV3pTbkRsaGJidmppSFVDWDVtTU5ZdWxpbGdDTUZRdmt2clJEbkpJM0U2WmpPMXFSWnVDUXY0eVQtdzZvaUE9IiwiaGVhZGVyIjp7ImtpZCI6IjJHWG11Q04ySkN4U3FNUlZmdEJITHhWSktTTDViWHl6TThEc1B6R3FRb05qIn19XX0=\",\n    \"iv\": \"M1GneQLepxfDbios\",\n    \"ciphertext\": \"iOLSKIxqn_kCZ7Xo7iKQ9rjM4DYqWIM16_vUeb1XDsmFTKjmvjR0u2mWFA48ovX5yVtUd9YKx86rDVDLs1xgz91Q4VLt9dHMOfzqv5DwmAFbbc9Q5wHhFwBvutUx5-lDZJFzoMQHlSAGFSBrvuApDXXt8fs96IJv3PsL145Qt27WLu05nxhkzUZz8lXfERHwAC8FYAjfvN8Fy2UwXTVdHqAOyI5fdKqfvykGs6fV\",\n    \"tag\": \"gL-lfmD-MnNj9Pr6TfzgLA==\"\n}\n</code></pre> <p>The protected data decodes to this:</p> <pre><code>{\n    \"enc\": \"xchacha20poly1305_ietf\",\n    \"typ\": \"JWM/1.0\",\n    \"alg\": \"Anoncrypt\",\n    \"recipients\": [\n        {\n            \"encrypted_key\": \"XCN8V57Q1tgauLW1zgj1WQZQ0WDV0QwyEZFNNwF6DmiI49CK5s58dsV0d_NZK-SMNqe0iFXgXFvHpoc8kuViSM_K5lrpbMStj7CRPskvbS8=\",\n            \"header\": {\n                \"kid\": \"GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL\"\n            }\n        },\n        {\n            \"encrypted_key\": \"hnOeL0Y9xOvcy5oFgtd1RVm9d73-0uGWNJCtG4lKswvYcWzSnDlhbbvjiHUCX5mMNYulilgCMFQvkvrRDnJI3E6ZjO1qRZuCQv4yT-w6oiA=\",\n            \"header\": {\n                \"kid\": \"2GXmuCN2JCxSqMRVftBHLxVJKSL5bXyzM8DsPzGqQoNj\"\n            }\n        }\n    ]\n}\n</code></pre>"},{"location":"aip2/0019-encryption-envelope/#pack-output-format-anoncrypt-mode","title":"pack output format (Anoncrypt mode)","text":"<pre><code>    {\n         \"protected\": \"b64URLencoded({\n            \"enc\": \"xchachapoly1305_ietf\",\n            \"typ\": \"JWM/1.0\",\n            \"alg\": \"Anoncrypt\",\n            \"recipients\": [\n                {\n                    \"encrypted_key\": base64URLencode(libsodium.crypto_box_seal(their_vk, cek)),\n                    \"header\": {\n                        \"kid\": base58encode(recipient_verkey),\n                    }\n                },\n            ],\n         })\",\n         \"iv\": b64URLencode(iv),\n         \"ciphertext\": b64URLencode(encrypt_detached({'@type'...}, protected_value_encoded, iv, cek),\n         \"tag\": b64URLencode(tag)\n    }\n</code></pre>"},{"location":"aip2/0019-encryption-envelope/#anoncrypt-pack-algorithm","title":"Anoncrypt pack algorithm","text":"<ol> <li>generate a content encryption key (symmetrical encryption key)</li> <li>encrypt the CEK for each recipient's public key using Anoncrypt (steps below)<ol> <li>set <code>encrypted_key</code> value to base64URLencode(libsodium.crypto_box_seal(their_vk, cek))<ul> <li>Note it this step we're encrypting the cek, so it can be decrypted by the recipient</li> </ul> </li> </ol> </li> <li>base64URLencode the <code>protected</code> value</li> <li>encrypt the message using libsodium.crypto_aead_chacha20poly1305_ietf_encrypt_detached(message, protected_value_encoded, iv, cek) this is the ciphertext.</li> <li>base64URLencode the iv, ciphertext, and tag then serialize the format into the output format listed above.</li> </ol> <p>For a reference implementation, see https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/commands/crypto.rs</p>"},{"location":"aip2/0019-encryption-envelope/#unpack-message","title":"Unpack Message","text":""},{"location":"aip2/0019-encryption-envelope/#unpack_message-interface","title":"unpack_message() interface","text":"<p>unpacked_message = unpack_message(wallet_handle, jwe)</p>"},{"location":"aip2/0019-encryption-envelope/#unpack_message-params","title":"unpack_message() Params","text":"<ul> <li>wallet_handle: wallet handle that contains the sender_verkey</li> <li>jwe: a message which was returned from a pack_message() and follows the scheme format described below</li> </ul>"},{"location":"aip2/0019-encryption-envelope/#unpack-algorithm","title":"Unpack Algorithm","text":"<ol> <li>seralize data, so it can be used<ul> <li>For example, in rust-lang this has to be seralized as a struct.</li> </ul> </li> <li>Lookup the <code>kid</code> for each recipient in the wallet to see if the wallet possesses a private key associated with the public key listed</li> <li>Check if a <code>sender</code> field is used.<ul> <li>If a sender is included use auth_decrypt to decrypt the <code>encrypted_key</code> by doing the following:<ol> <li>decrypt sender verkey using libsodium.crypto_box_seal_open(my_private_key, base64URLdecode(sender))</li> <li>decrypt cek using libsodium.crypto_box_open(my_private_key, sender_verkey, encrypted_key, cek_iv)</li> <li>decrypt ciphertext using libsodium.crypto_aead_chacha20poly1305_ietf_open_detached(base64URLdecode(ciphertext_bytes), base64URLdecode(protected_data_as_bytes), base64URLdecode(nonce), cek)</li> <li>return <code>message</code>, <code>recipient_verkey</code> and <code>sender_verkey</code> following the authcrypt format listed below</li> </ol> </li> <li>If a sender is NOT included use anon_decrypt to decrypt the <code>encrypted_key</code> by doing the following:<ol> <li>decrypt <code>encrypted_key</code> using libsodium.crypto_box_seal_open(my_private_key, encrypted_key)</li> <li>decrypt ciphertext using libsodium.crypto_aead_chacha20poly1305_ietf_open_detached(base64URLdecode(ciphertext_bytes), base64URLdecode(protected_data_as_bytes), base64URLdecode(nonce), cek)</li> <li>return <code>message</code> and <code>recipient_verkey</code> following the anoncrypt format listed below</li> </ol> </li> </ul> </li> </ol> <p>NOTE: In the unpack algorithm, the base64url decode implementation used MUST correctly decode padded and unpadded base64URL encoded data.</p> <p>For a reference unpack implementation, see https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/commands/crypto.rs</p>"},{"location":"aip2/0019-encryption-envelope/#unpack_message-return-values-authcrypt-mode","title":"unpack_message() return values (authcrypt mode)","text":"<pre><code>{\n    \"message\": \"{ \\\"@id\\\": \\\"123456780\\\",\\\"@type\\\":\\\"https://didcomm.org/basicmessage/1.0/message\\\",\\\"sent_time\\\": \\\"2019-01-15 18:42:01Z\\\",\\\"content\\\": \\\"Your hovercraft is full of eels.\\\"}\",\n    \"recipient_verkey\": \"HKTAiYM8cE2kKC9KaNMZLYj4GS8uWCYMBxP2i1Y92zum\",\n    \"sender_verkey\": \"DWwLsbKCRAbYtfYnQNmzfKV7ofVhMBi6T4o3d2SCxVuX\"\n}\n</code></pre>"},{"location":"aip2/0019-encryption-envelope/#unpack_message-return-values-anoncrypt-mode","title":"unpack_message() return values (anoncrypt mode)","text":"<pre><code>{\n    \"message\": \"{ \\\"@id\\\": \\\"123456780\\\",\\\"@type\\\":\\\"https://didcomm.org/basicmessage/1.0/message\\\",\\\"sent_time\\\": \\\"2019-01-15 18:42:01Z\\\",\\\"content\\\": \\\"Your hovercraft is full of eels.\\\"}\",\n    \"recipient_verkey\": \"2GXmuCN2JCxSqMRVftBHLxVJKSL5bXyzM8DsPzGqQoNj\"\n}\n</code></pre>"},{"location":"aip2/0019-encryption-envelope/#additional-notes","title":"Additional Notes","text":"<ul> <li> <p>All <code>kid</code> values used currently are base58 encoded ed25519 keys. If other keys types are used, say secp256k1, base58 encoding should also be used here for interoperability.</p> </li> <li> <p>All algorithm APIs which use libsodium are from sodiumoxide rust wrapping of the original C implementation.</p> </li> </ul>"},{"location":"aip2/0019-encryption-envelope/#drawbacks","title":"Drawbacks","text":"<p>The current implementation of the <code>pack()</code> message is currently Hyperledger Aries specific. It is based on common crypto libraries (NaCl), but the wrappers are not commonly used outside of Aries. There's currently work being done to fine alignment on a cross-ecosystem interoperable protocol, but this hasn't been achieved yet. This work will hopefully bridge this gap.</p>"},{"location":"aip2/0019-encryption-envelope/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>As the JWE standard currently stands, it does not follow this format. We're actively working with the lead writer of the JWE spec to find alignment and are hopeful the changes needed can be added.</p> <p>We've also looked at using the Message Layer Security (MLS) specification. This specification shows promise for adoption later on with more maturity. Additionally because they aren't hiding metadata related to the sender (Sender Anonymity), we would need to see some changes made to the specification before we could adopt this spec.</p>"},{"location":"aip2/0019-encryption-envelope/#prior-art","title":"Prior art","text":"<p>The JWE family of encryption methods.</p>"},{"location":"aip2/0019-encryption-envelope/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>How transport protocols (https, zmq, etc.) will be be used to send Encrypted Envelopes?<ul> <li>These will need to be defined using separate RFCs. For example, HTTP might POST a message and place it in the body of the HTTP POST.</li> </ul> </li> <li>How will the encrypted envelopes work with routing tables to pass a message through a domain, potentially over various transport protocols?<ul> <li>There's not much certainty whether routing tables or some other mechanism will be used. This needs to be defined in another RFC.</li> </ul> </li> <li>If the encryption envelope protocol fails, how is that failure passed back to those involved in the transmission?<ul> <li>This should be handled using the Report Problem Protocol which is currently demonstrated RFC #35 by Stephen Curran.</li> </ul> </li> </ul>"},{"location":"aip2/0019-encryption-envelope/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community Aries Framework - .NET .NET framework for building agents of all types Streetcred.id Commercial mobile and web app built using Aries Framework - .NET Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Aries Framework - Go For building agents, hubs and other DIDComm ../../features in GoLang. Aries Protocol Test Suite"},{"location":"aip2/0019-encryption-envelope/schema/","title":"Schema","text":"<p>This spec is according JSON Schema v0.7 <pre><code>{\n    \"id\": \"https://github.com/hyperledger/indy-agent/wiremessage.json\",\n    \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n    \"title\": \"Json Web Message format\",\n    \"type\": \"object\",\n    \"required\": [\"ciphertext\", \"iv\", \"protected\", \"tag\"],\n    \"properties\": {\n        \"protected\": {\n            \"type\": \"object\",\n            \"description\": \"Additional authenticated message data base64URL encoded, so it can be verified by the recipient using the tag\",\n            \"required\": [\"enc\", \"typ\", \"alg\", \"recipients\"],\n            \"properties\": {\n                \"enc\": {\n                    \"type\": \"string\",\n                    \"enum\": [\"xchacha20poly1305_ietf\"],\n                    \"description\": \"The authenticated encryption algorithm used to encrypt the ciphertext\"\n                },\n                \"typ\": { \n                    \"type\": \"string\",\n                    \"description\": \"The message type. Ex: JWM/1.0\"\n                },\n                \"alg\": {\n                    \"type\": \"string\",\n                    \"enum\": [ \"authcrypt\", \"anoncrypt\"]\n                },\n                \"recipients\": {\n                    \"type\": \"array\",\n                    \"description\": \"A list of the recipients who the message is encrypted for\",\n                    \"items\": {\n                        \"type\": \"object\",\n                        \"required\": [\"encrypted_key\", \"header\"],\n                        \"properties\": {\n                            \"encrypted_key\": {\n                                \"type\": \"string\",\n                                \"description\": \"The key used for encrypting the ciphertext. This is also referred to as a cek\"\n                            },\n                            \"header\": {\n                                \"type\": \"object\",\n                                \"required\": [\"kid\"],\n                                \"description\": \"The recipient to whom this message will be sent\",\n                                \"properties\": {\n                                    \"kid\": {\n                                        \"type\": \"string\",\n                                        \"description\": \"base58 encoded verkey of the recipient.\"\n                                    }\n                                }\n                            }\n                        }\n                    }\n                 },     \n            },\n        },\n        \"iv\": {\n            \"type\": \"string\",\n            \"description\": \"base64 URL encoded nonce used to encrypt ciphertext\"\n        },\n        \"ciphertext\": {\n            \"type\": \"string\",\n            \"description\": \"base64 URL encoded authenticated encrypted message\"\n        },\n        \"tag\": {\n            \"type\": \"string\",\n            \"description\": \"Integrity checksum/tag base64URL encoded to check ciphertext, protected, and iv\"\n        }\n    }\n}\n</code></pre></p>"},{"location":"aip2/0020-message-types/","title":"Aries RFC 0020: Message Types","text":"<ul> <li>Authors: Daniel Bluhm, Sam Curren</li> <li>Status: ADOPTED</li> <li>Since: 2019-05-24</li> <li>Status Note:  </li> <li>Supersedes: HIPE 0021 Message Types</li> <li>Start Date: 2018-07-06</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0020-message-types/#summary","title":"Summary","text":"<p>Define structure of message type strings used in agent to agent communication, describe their resolution to documentation URIs, and offer guidelines for protocol specifications.</p>"},{"location":"aip2/0020-message-types/#motivation","title":"Motivation","text":"<p>A clear convention to follow for agent developers is necessary for interoperability and continued progress as a community.</p>"},{"location":"aip2/0020-message-types/#tutorial","title":"Tutorial","text":"<p>A \"Message Type\" is a required attribute of all communications sent between parties. The message type instructs the receiving agent how to interpret the content and what content to expect as part of a given message.</p> <p>Types are specified within a message using the <code>@type</code> attribute:</p> <pre><code>{\n    \"@type\": \"&lt;message type string&gt;\",\n    // other attributes\n}\n</code></pre> <p>Message types are URIs that may resolve to developer documentation for the message type, as described in Protocol URIs. We recommend that message type URIs be HTTP URLs.</p>"},{"location":"aip2/0020-message-types/#aries-core-message-namespace","title":"Aries Core Message Namespace","text":"<p><code>https://didcomm.org/</code> is used to namespace protocols defined by the community as \"core protocols\" or protocols that agents should minimally support.</p> <p>The <code>didcomm.org</code> DNS entry is currently controlled by the Decentralized Identity Foundation (DIF) based on their role in standardizing the DIDComm Messaging specification.</p>"},{"location":"aip2/0020-message-types/#protocols","title":"Protocols","text":"<p>Protocols provide a logical grouping for message types. These protocols, along with each type belonging to that protocol, are to be defined in future RFCs or through means appropriate to subprojects.</p>"},{"location":"aip2/0020-message-types/#protocol-versioning","title":"Protocol Versioning","text":"<p>Version numbering should essentially follow Semantic Versioning 2.0.0, excluding patch version number. To summarize, a change in the major protocol version number indicates a breaking change while the minor protocol version number indicates non-breaking additions.</p>"},{"location":"aip2/0020-message-types/#message-type-design-guidelines","title":"Message Type Design Guidelines","text":"<p>These guidelines are guidelines on purpose. There will be situations where a good design will have to choose between conflicting points, or ignore all of them. The goal should always be clear and good design.</p>"},{"location":"aip2/0020-message-types/#respect-reserved-attribute-names","title":"Respect Reserved Attribute Names","text":"<p>Reserved attributes are prefixed with an <code>@</code> sign, such as <code>@type</code>. Don't use this prefix for an attribute, even if use of that specific attribute is undefined.</p>"},{"location":"aip2/0020-message-types/#avoid-ambiguous-attribute-names","title":"Avoid ambiguous attribute names","text":"<p>Data, id, and package, are often terrible names. Adjust the name to enhance meaning. For example, use  <code>message_id</code> instead of <code>id</code>.</p>"},{"location":"aip2/0020-message-types/#avoid-names-with-special-characters","title":"Avoid names with special characters","text":"<p>Technically, attribute names can be any valid json key (except prefixed with @, as mentioned above). Practically, you should avoid using special characters, including those that need to be escaped. Underscores and dashes [_,-] are totally acceptable, but you should avoid quotation marks, punctuation, and other symbols.</p>"},{"location":"aip2/0020-message-types/#use-attributes-consistently-within-a-protocol","title":"Use attributes consistently within a protocol","text":"<p>Be consistent with attribute names between the different types within a protocol. Only use the same attribute name for the same data. If the attribute values are similar, but not exactly the same, adjust the name to indicate the difference.</p>"},{"location":"aip2/0020-message-types/#nest-attributes-only-when-useful","title":"Nest Attributes only when useful","text":"<p>Attributes do not need to be nested under a top level attribute, but can be to organize related attributes. Nesting all message attributes under one top level attribute is usually not a good idea.</p>"},{"location":"aip2/0020-message-types/#design-examples","title":"Design Examples","text":""},{"location":"aip2/0020-message-types/#example-1","title":"Example 1","text":"<pre><code>{\n    \"@type\": \"did:example:00000;spec/pizzaplace/1.0/pizzaorder\",\n    \"content\": {\n        \"id\": 15,\n        \"name\": \"combo\",\n        \"prepaid?\": true,\n        \"ingredients\": [\"pepperoni\", \"bell peppers\", \"anchovies\"]\n    }\n}\n</code></pre> <p>Suggestions: Ambiguous names, unnecessary nesting, symbols in names.</p>"},{"location":"aip2/0020-message-types/#example-1-fixed","title":"Example 1 Fixed","text":"<pre><code>{\n    \"@type\": \"did:example:00000;spec/pizzaplace/1.0/pizzaorder\",\n    \"table_id\": 15,\n    \"pizza_name\": \"combo\",\n    \"prepaid\": true,\n    \"ingredients\": [\"pepperoni\", \"bell peppers\", \"anchovies\"]\n}\n</code></pre>"},{"location":"aip2/0020-message-types/#reference","title":"Reference","text":"<ul> <li>Daniel Hardman's Agent Summit Notes</li> <li>Stephen Curran's presentation summarizing the Agent Summit</li> <li>Semantic Versioning</li> <li>DIDComm Message Anatomy</li> </ul>"},{"location":"aip2/0020-message-types/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community Aries Framework - .NET .NET framework for building agents of all types Streetcred.id Commercial mobile and web app built using Aries Framework - .NET Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Aries Framework - Go For building agents, hubs and other DIDComm ../../features in GoLang. Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem."},{"location":"aip2/0023-did-exchange/","title":"Aries RFC 0023: DID Exchange Protocol 1.0","text":"<ul> <li>Authors: Ryan West, Daniel Bluhm, Matthew Hailstone, Stephen Curran, Sam Curren, Stephen Curran, George Aristy</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Replaces RFC 0160 - Connection Protocol and is a part of AIP 2.0.</li> <li>Supersedes: RFC 0160 - Connection Protocol</li> <li>Start Date: 2018-06-29</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"aip2/0023-did-exchange/#summary","title":"Summary","text":"<p>This RFC describes the protocol to exchange DIDs between agents when establishing a DID based relationship.</p>"},{"location":"aip2/0023-did-exchange/#motivation","title":"Motivation","text":"<p>Aries agent developers want to create agents that are able to establish relationships with each other and exchange secure information using keys and endpoints in DID Documents. For this to happen there must be a clear protocol to exchange DIDs.</p>"},{"location":"aip2/0023-did-exchange/#tutorial","title":"Tutorial","text":"<p>We will explain how DIDs are exchanged, with the roles, states, and messages required.</p>"},{"location":"aip2/0023-did-exchange/#roles","title":"Roles","text":"<p>The DID Exchange Protocol uses two roles: requester and responder.</p> <p>The requester is the party that initiates this protocol after receiving an <code>invitation</code> message (using RFC 0434 Out of Band) or by using an implied invitation from a public DID. For example, a verifier might get the DID of the issuer of a credential they are verifying, and use information in the DIDDoc for that DID as the basis for initiating an instance of this protocol.</p> <p>Since the requester receiving an explicit invitation may not have an Aries agent, it is desirable, but not strictly, required that sender of the invitation (who has the responder role in this protocol) have the ability to help the requester with the process and/or costs associated with acquiring an agent capable of participating in the ecosystem. For example, the sender of an invitation may often be sponsoring institutions.</p> <p>The responder, who is the sender of an explicit invitation or the publisher of a DID with an implicit invitation, must have an agent capable of interacting with other agents via DIDComm.</p> <p>In cases where both parties already possess SSI capabilities, deciding who plays the role of requester and responder  might be a casual matter of whose phone is handier.</p>"},{"location":"aip2/0023-did-exchange/#states","title":"States","text":""},{"location":"aip2/0023-did-exchange/#requester","title":"Requester","text":"<p>The requester goes through the following states per the State Machine Tables below</p> <ul> <li>start</li> <li>invitation-received</li> <li>request-sent</li> <li>response-received</li> <li>abandoned</li> <li>completed</li> </ul>"},{"location":"aip2/0023-did-exchange/#responder","title":"Responder","text":"<p>The responder goes through the following states per the State Machine Tables below</p> <ul> <li>start</li> <li>invitation-sent</li> <li>request-received</li> <li>response-sent</li> <li>abandoned</li> <li>completed</li> </ul>"},{"location":"aip2/0023-did-exchange/#state-machine-tables","title":"State Machine Tables","text":"<p>The following are the requester and responder state machines.</p> <p>The <code>invitation-sent</code> and <code>invitation-received</code> are technically outside this protocol, but are useful to show in the state machine as the invitation is the trigger to start the protocol and is referenced from the protocol as the parent thread (<code>pthid</code>).  This is discussed in more detail below.</p> <p>The <code>abandoned</code> and <code>completed</code> states are terminal states and there is no expectation that the protocol can be continued (or even referenced) after reaching those states.</p> <p></p>"},{"location":"aip2/0023-did-exchange/#errors","title":"Errors","text":"<p>After receiving an explicit invitation, the requester may send a <code>problem-report</code> to the responder using the information in the invitation to either restart the invitation process (returning to the <code>start</code> state) or to abandon the protocol. The <code>problem-report</code> may be an adopted  <code>Out of Band</code> protocol message or an adopted <code>DID Exchange</code> protocol message, depending on where in the processing of the invitation the error was detected.</p> <p>During the <code>request</code> / <code>response</code> part of the protocol, there are two protocol-specific error messages possible: one for an active rejection and one for an unknown error. These errors are sent using a problem_report message type specific to the DID Exchange Protocol. These errors do not transition the protocol to the <code>abandoned</code> state. The following list details <code>problem-code</code>s that may be sent in these cases:</p> <p>request_not_accepted - The error indicates that the <code>request</code> message has been rejected for a reason listed in the <code>error_report</code>. Typical reasons include not accepting the method of the provided DID, unknown endpoint protocols, etc. The <code>request</code> can be resent after the appropriate corrections have been made.</p> <p>request_processing_error - This error is sent when the responder was processing the request with the intent to accept the request, but some processing error occurred. This error indicates that the <code>request</code> should be resent as-is.</p> <p>response_not_accepted - The error indicates that the <code>response</code> has been rejected for a reason listed in the <code>error_report</code>. Typical reasons include not accepting the method of the provided DID, unknown endpoint protocols, invalid signature, etc. The <code>response</code> can be resent after the appropriate corrections have been made.</p> <p>response_processing_error - This error is sent when the requester was processing the <code>response</code> with the intent to accept the response, but some processing error occurred. This error indicates that the <code>response</code> should be resent as-is.</p> <p>If other errors occur, the corresponding party may send a <code>problem-report</code> to inform the other party they are abandoning the protocol.</p> <p>No errors are sent in timeout situations. If the requester or responder wishes to retract the messages they sent, they record so locally and return a <code>request_not_accepted</code> or <code>response_not_accepted</code> error when the other party sends a <code>request</code> or <code>response</code>.</p>"},{"location":"aip2/0023-did-exchange/#error-message-example","title":"Error Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/didexchange/1.0/problem_report\",\n  \"@id\": \"5678876542345\",\n  \"~thread\": { \"thid\": \"&lt;@id of message related to problem&gt;\" },\n  \"~l10n\": { \"locale\": \"en\"},\n  \"problem-code\": \"request_not_accepted\", // matches codes listed above\n  \"explain\": \"Unsupported DID method for provided DID.\"\n}\n</code></pre>"},{"location":"aip2/0023-did-exchange/#error-message-attributes","title":"Error Message Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is a problem_report within the didexchange protocol.</li> <li>The <code>~thread</code> attribute provides a context for the problem, referring to the message which contains the problem.</li> <li>Use of <code>~l10n</code> is encouraged, with at least locale defined for the message.</li> <li>The <code>problem-code</code> attribute contains one of a fixed set of codes defined in the list above.</li> <li>The <code>explain</code> attribute contains a human readable message which indicates the problem.</li> </ul>"},{"location":"aip2/0023-did-exchange/#flow-overview","title":"Flow Overview","text":"<ul> <li>The responder gives provisional information to the requester using an explicit <code>invitation</code> message from the <code>out-of-band</code> protocol or an implicit invitation in a DID the responder publishes.</li> <li>In the <code>out-of-band</code> protocol, the responder is called the sender, and the requester is called the receiver.</li> <li>The requester uses the provisional information to send a DID and DID Doc to the responder in a <code>request</code> message.</li> <li>The responder uses sent DID Doc information to send a DID and DID Doc to the requester in a <code>response</code> message.</li> <li>The requester sends the responder a <code>complete</code> message that confirms the <code>response</code> message was received.</li> </ul>"},{"location":"aip2/0023-did-exchange/#implicit-and-explicit-invitations","title":"Implicit and Explicit Invitations","text":"<p>The DID Exchange Protocol is preceded by  - either knowledge of a resolvable DID (an implicit invitation)  - or by a <code>out-of-band/%VER/invitation</code> message from the Out Of Band Protocols RFC. </p> <p>The information needed to construct the <code>request</code> message to start the protocol is used - either from the resolved DID Document  - or the <code>service</code> element of the <code>handshake_protocols</code> attribute of the <code>invitation</code>.</p>"},{"location":"aip2/0023-did-exchange/#1-exchange-request","title":"1. Exchange Request","text":"<p>The <code>request</code> message is used to communicate the DID document of the requester to the responder using the provisional service information present in the (implicit or explicit) invitation.</p> <p>The requester may provision a new DID according to the DID method spec. For a Peer DID, this involves creating a matching peer DID and key. The newly provisioned DID and DID Doc is presented in the <code>request</code> message as follows:</p>"},{"location":"aip2/0023-did-exchange/#request-message-example","title":"Request Message Example","text":"<pre><code>{\n  \"@id\": \"5678876542345\",\n  \"@type\": \"https://didcomm.org/didexchange/1.0/request\",\n  \"~thread\": { \n      \"thid\": \"5678876542345\",\n      \"pthid\": \"&lt;id of invitation&gt;\"\n  },\n  \"label\": \"Bob\",\n  \"goal_code\": \"aries.rel.build\",\n  \"goal\": \"To create a relationship\",\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n      \"@id\": \"d2ab6f2b-5646-4de3-8c02-762f553ab804\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n         \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n         \"jws\": {\n            \"header\": {\n               \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n            },\n            \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n            \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n            }\n      }\n   }\n}\n</code></pre>"},{"location":"aip2/0023-did-exchange/#request-message-attributes","title":"Request Message Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is an exchange request.</li> <li>The <code>~thread</code> decorator MUST be included:</li> <li>It MUST include the ID of the parent thread (<code>pthid</code>) such that the <code>request</code> can be correlated to the corresponding (implicit or explicit) <code>invitation</code>. More on correlation below.</li> <li>It MAY include the <code>thid</code> property. This works according to the <code>thid</code> property in the thread decorator, meaning that if <code>thid</code> is not defined it is implicitly defined as the <code>@id</code> on the same <code>request</code> message.</li> <li>The <code>label</code> attribute provides a suggested label for the DID being exchanged. This allows the user to tell multiple exchange requests apart. This is not a trusted attribute. (See note on <code>label</code> below)</li> <li>The <code>goal_code</code> (optional) is a self-attested code the receiver may want to display to the user or use in automatically deciding what to do with the request message. The goal code might be used particularly when the request is sent to a resolvable DID without reference to a specfic invitation.</li> <li>The goal (optional) is a self-attested string that the receiver may want to display to the user about the context-specific goal of the request message.</li> <li>The <code>did</code> attribute MUST be included. It indicates the DID being exchanged.</li> <li>The <code>did_doc~attach</code> (optional), contains the DIDDoc associated with the <code>did</code>, if required.</li> <li>If the <code>did</code> is resolvable (either an inline <code>peer:did</code> or a publicly resolvable DID), the <code>did_doc~attach</code> attribute should not be included.</li> <li>If the DID is a <code>did:peer</code> DID, the DIDDoc must be as outlined in RFC 0627 Static Peer DIDs.</li> </ul> <p>The <code>label</code> property was intended to be declared as an optional property, but was added to the RFC as a required property. If an agent wishes to not use a label in the request, an empty string (<code>\"\"</code>) or the set value <code>Unspecified</code> may be used to indicate a non-value. This approach ensures existing AIP 2.0 implementations do not break.</p>"},{"location":"aip2/0023-did-exchange/#correlating-requests-to-invitations","title":"Correlating requests to invitations","text":"<p>An invitation is presented in one of two forms:</p> <ul> <li>An explicit out-of-band invitation with its own <code>@id</code>.</li> <li>An implicit invitation contained in a DID document's <code>service</code> attribute that conforms to the DIDComm conventions.</li> </ul> <p>When a <code>request</code> responds to an explicit invitation, its <code>~thread.pthid</code> MUST be equal to the <code>@id</code> property of the invitation as described in the out-of-band RFC.</p> <p>When a <code>request</code> responds to an implicit invitation, its <code>~thread.pthid</code> MUST contain a DID URL that resolves to the specific <code>service</code> on a DID document that contains the invitation.</p>"},{"location":"aip2/0023-did-exchange/#example-referencing-an-explicit-invitation","title":"Example Referencing an Explicit Invitation","text":"<pre><code>{\n  \"@id\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n  \"@type\": \"https://didcomm.org/didexchange/1.0/request\",\n  \"~thread\": { \n      \"thid\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n      \"pthid\": \"032fbd19-f6fd-48c5-9197-ba9a47040470\" \n  },\n  \"label\": \"Bob\",\n  \"goal_code\": \"aries.rel.build\",\n  \"goal\": \"To create a relationship\",\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n      \"@id\": \"d2ab6f2b-5646-4de3-8c02-762f553ab804\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n         \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n         \"jws\": {\n            \"header\": {\n               \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n            },\n            \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n            \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n            }\n      }\n   }\n}\n</code></pre>"},{"location":"aip2/0023-did-exchange/#example-referencing-an-implicit-invitation","title":"Example Referencing an Implicit Invitation","text":"<pre><code>{\n  \"@id\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n  \"@type\": \"https://didcomm.org/didexchange/1.0/request\",\n  \"~thread\": { \n      \"thid\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n      \"pthid\": \"did:example:21tDAKCERh95uGgKbJNHYp#didcomm\" \n  },\n  \"label\": \"Bob\",\n  \"goal_code\": \"aries.rel.build\",\n  \"goal\": \"To create a relationship\",\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n      \"@id\": \"d2ab6f2b-5646-4de3-8c02-762f553ab804\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n         \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n         \"jws\": {\n            \"header\": {\n               \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n            },\n            \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n            \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n            }\n      }\n   }\n}\n</code></pre>"},{"location":"aip2/0023-did-exchange/#request-transmission","title":"Request Transmission","text":"<p>The <code>request</code> message is encoded according to the standards of the Encryption Envelope, using the <code>recipientKeys</code> present in the invitation.</p> <p>If the <code>routingKeys</code> attribute was present and non-empty in the invitation, each key must be used to wrap the message in a forward request, then encoded in an Encryption Envelope. This processing is in order of the keys in the list, with the last key in the list being the one for which the <code>serviceEndpoint</code> possesses the private key.</p> <p>The message is then transmitted to the <code>serviceEndpoint</code>.</p> <p>The requester is in the <code>request-sent</code> state. When received, the responder is in the <code>request-received</code> state.</p>"},{"location":"aip2/0023-did-exchange/#request-processing","title":"Request processing","text":"<p>After receiving the exchange request, the responder evaluates the provided DID and DID Doc according to the DID Method Spec.</p> <p>The responder should check the information presented with the keys used in the wire-level message transmission to ensure they match.</p> <p>The responder MAY look up the corresponding invitation identified in the request's <code>~thread.pthid</code> to determine whether it should accept this exchange request.</p> <p>If the responder wishes to continue the exchange, they will persist the received information in their wallet. They will then either update the provisional service information to rotate the key, or provision a new DID entirely. The choice here will depend on the nature of the DID used in the invitation.</p> <p>The responder will then craft an exchange response using the newly updated or provisioned information.</p>"},{"location":"aip2/0023-did-exchange/#request-errors","title":"Request Errors","text":"<p>See Error Section above for message format details.</p>"},{"location":"aip2/0023-did-exchange/#request-rejected","title":"Request Rejected","text":"<p>Possible reasons:</p> <ul> <li>Unsupported DID method for provided DID</li> <li>Expired Invitation</li> <li>DID Doc Invalid</li> <li>Unsupported key type</li> <li>Unsupported endpoint protocol</li> <li>Missing reference to invitation</li> </ul>"},{"location":"aip2/0023-did-exchange/#request-processing-error","title":"Request Processing Error","text":"<ul> <li>unknown processing error</li> </ul>"},{"location":"aip2/0023-did-exchange/#2-exchange-response","title":"2. Exchange Response","text":"<p>The exchange response message is used to complete the exchange. This message is required in the flow, as it updates the provisional information presented in the invitation.</p>"},{"location":"aip2/0023-did-exchange/#response-message-example","title":"Response Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/didexchange/1.0/response\",\n  \"@id\": \"12345678900987654321\",\n  \"~thread\": {\n    \"thid\": \"&lt;The Thread ID is the Message ID (@id) of the first message in the thread&gt;\"\n  },\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n      \"@id\": \"d2ab6f2b-5646-4de3-8c02-762f553ab804\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n         \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n         \"jws\": {\n            \"header\": {\n               \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n            },\n            \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n            \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n            }\n      }\n   }\n}\n</code></pre> <p>The invitation's <code>recipientKeys</code> should be dedicated to envelopes authenticated encryption throughout the exchange. These keys are usually defined in the <code>KeyAgreement</code> DID verification relationship.</p>"},{"location":"aip2/0023-did-exchange/#response-message-attributes","title":"Response Message Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is an exchange request.</li> <li>The <code>~thread</code> decorator MUST be included. It contains a <code>thid</code> reference to the <code>@id</code> of the request message.</li> <li>The <code>did</code> attribute MUST be included. It denotes the DID in use by the responder. Note that this MAY NOT be the same DID used in the invitation.</li> <li>The <code>did_doc~attach</code> optional, contains the DID Doc associated with the <code>did</code>, if required.</li> <li>If the <code>did</code> is resolvable (either an inline <code>peer:did</code> or a publicly resolvable DID), the <code>did_doc~attach</code> attribute should not be included.</li> <li>If the DID is a <code>did:peer</code> identifier, the DIDDoc must be as outlined in RFC 0627 Static Peer DIDs.</li> </ul> <p>In addition to a new DID, the associated DID Doc might contain a new endpoint. This new DID and endpoint are to be used going forward in the relationship.</p>"},{"location":"aip2/0023-did-exchange/#response-transmission","title":"Response Transmission","text":"<p>The message should be packaged in the encrypted envelope format, using the keys from the request, and the new keys presented in the internal did doc.</p> <p>When the message is sent, the responder are now in the <code>response-sent</code> state. On receipt, the requester is in the <code>response-received</code> state.</p>"},{"location":"aip2/0023-did-exchange/#response-processing","title":"Response Processing","text":"<p>When the requester receives the <code>response</code> message, they will decrypt the authenticated envelope which confirms the source's authenticity. After decryption validation, they will update their wallet with the new information, and use that information in sending the <code>complete</code> message.</p>"},{"location":"aip2/0023-did-exchange/#response-errors","title":"Response Errors","text":"<p>See Error Section above for message format details.</p>"},{"location":"aip2/0023-did-exchange/#response-rejected","title":"Response Rejected","text":"<p>Possible reasons:</p> <ul> <li>unsupported DID method for provided DID</li> <li>Expired Request</li> <li>DID Doc Invalid</li> <li>Unsupported key type</li> <li>Unsupported endpoint protocol</li> <li>Invalid Signature</li> </ul>"},{"location":"aip2/0023-did-exchange/#response-processing-error","title":"Response Processing Error","text":"<ul> <li>unknown processing error</li> </ul>"},{"location":"aip2/0023-did-exchange/#3-exchange-complete","title":"3. Exchange Complete","text":"<p>The exchange <code>complete</code> message is used to confirm the exchange to the responder. This message is required in the flow, as it marks the exchange complete. The responder may then invoke any protocols desired based on the context expressed via the <code>pthid</code> in the DID Exchange protocol.</p>"},{"location":"aip2/0023-did-exchange/#complete-message-example","title":"Complete Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/didexchange/1.0/complete\",\n  \"@id\": \"12345678900987654321\",\n  \"~thread\": {\n    \"thid\": \"&lt;The Thread ID is the Message ID (@id) of the first message in the thread&gt;\",\n    \"pthid\": \"&lt;pthid used in request message&gt;\"\n  }\n}\n</code></pre> <p>The <code>pthid</code> is required in this message, and must be identical to the <code>pthid</code> used in the <code>request</code> message.</p> <p>After a <code>complete</code> message is sent, the requester is in the <code>completed</code> terminal state. Receipt of the message puts the responder into the <code>completed</code> state.</p>"},{"location":"aip2/0023-did-exchange/#complete-errors","title":"Complete Errors","text":"<p>See Error Section above for message format details.</p>"},{"location":"aip2/0023-did-exchange/#complete-rejected","title":"Complete Rejected","text":"<p>This is unlikely to occur with other than an unknown processing error (covered below), so no possible reasons are listed. As experience is gained with the protocol, possible reasons may be added.</p>"},{"location":"aip2/0023-did-exchange/#complete-processing-error","title":"Complete Processing Error","text":"<ul> <li>unknown processing error</li> </ul>"},{"location":"aip2/0023-did-exchange/#next-steps","title":"Next Steps","text":"<p>The exchange between the requester and the responder has been completed. This relationship has no trust associated with it. The next step should be to increase the trust to a sufficient level for the purpose of the relationship, such as through an exchange of proofs.</p>"},{"location":"aip2/0023-did-exchange/#peer-did-maintenance","title":"Peer DID Maintenance","text":"<p>When Peer DIDs are used in an exchange, it is likely that both the requester and responder will want to perform some relationship maintenance such as key rotations. Future RFC updates will add these maintenance ../../features.</p>"},{"location":"aip2/0023-did-exchange/#reference","title":"Reference","text":"<ul> <li>https://docs.google.com/document/d/1mRLPOK4VmU9YYdxHJSxgqBp19gNh3fT7Qk4Q069VPY8/edit#heading=h.7sxkr7hbou5i</li> <li>Agent to Agent Communication Video</li> <li>Agent to Agent Communication Presentation</li> <li>Problem_report message adopted into message family, following form defined by the Problem Report HIPE</li> <li>RFC0519 Goal Codes</li> </ul>"},{"location":"aip2/0023-did-exchange/#drawbacks","title":"Drawbacks","text":"<p>N/A at this time</p>"},{"location":"aip2/0023-did-exchange/#prior-art","title":"Prior art","text":"<ul> <li>This process is similar to other key exchange protocols.</li> </ul>"},{"location":"aip2/0023-did-exchange/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>N/A at this time</li> </ul>"},{"location":"aip2/0023-did-exchange/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Trinsic.id Commercial mobile and web app built using Aries Framework - .NET MISSING test results"},{"location":"aip2/0025-didcomm-transports/","title":"Aries RFC 0025: DIDComm Transports","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: ADOPTED</li> <li>Since: 2019-12-05</li> <li>Status Note:  </li> <li>Supersedes: INDY PR 94</li> <li>Start Date: 2019-02-26</li> <li>Tags: feature</li> </ul>"},{"location":"aip2/0025-didcomm-transports/#summary","title":"Summary","text":"<p>This RFC Details how different transports are to be used for Agent Messaging.</p>"},{"location":"aip2/0025-didcomm-transports/#motivation","title":"Motivation","text":"<p>Agent Messaging is designed to be transport independent, including message encryption and agent message format. Each transport does have unique ../../features, and we need to standardize how the transport ../../features are (or are not) applied.</p>"},{"location":"aip2/0025-didcomm-transports/#reference","title":"Reference","text":"<p>Standardized transport methods are detailed here.</p>"},{"location":"aip2/0025-didcomm-transports/#https","title":"HTTP(S)","text":"<p>HTTP(S) is the first, and most used transport for DID Communication that has received heavy attention. </p> <p>While it is recognized that all DIDComm messages are secured through strong encryption, making HTTPS somewhat redundant, it will likely cause issues with mobile clients because venders (Apple and Google) are limiting application access to the HTTP protocol. For example, on iOS 9 or above where [ATS])(https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity) is in effect, any URLs using HTTP must have an exception hard coded in the application prior to uploading to the iTunes Store. This makes DIDComm unreliable as the agent initiating the the request provides an endpoint for communication that the mobile client must use. If the agent provides a URL using the HTTP protocol it will likely be unusable due to low level operating system limitations.</p> <p>As a best practice, when HTTP is used in situations where a mobile client (iOS or Android) may be involved it is highly recommended to use the HTTPS protocol, specifically TLS 1.2 or above. </p> <p>Other important notes on the subject of using HTTP(S) include:</p> <ul> <li>Messages are transported via HTTP POST.</li> <li>The MIME Type for the POST request is <code>application/didcomm-envelope-enc</code>; see RFC 0044: DIDComm File and MIME Types for more details.</li> <li>A received message should be responded to with a 202 Accepted status code. This indicates that the request was received, but not necessarily processed. Accepting a 200 OK status code is allowed.</li> <li>POST requests are considered transmit only by default. No agent messages will be returned in the response. This behavior may be modified with additional signaling.</li> <li>Using HTTPS with TLS 1.2 or greater with a forward secret cipher will provide Perfect Forward Secrecy (PFS) on the transmission leg.</li> </ul>"},{"location":"aip2/0025-didcomm-transports/#known-implementations","title":"Known Implementations","text":"<p>Aries Cloud Agent - Python Aries Framework - .NET</p>"},{"location":"aip2/0025-didcomm-transports/#websocket","title":"Websocket","text":"<p>Websockets are an efficient way to transmit multiple messages without the overhead of individual requests.</p> <ul> <li>Each message is transmitted individually in an Encryption Envelope.</li> <li>The trust of each message comes from the Encryption Envelope, not the socket connection itself.</li> <li>Websockets are considered transmit only by default. Messages will only flow from the agent that opened the socket. This behavior may be modified with additional signaling.</li> <li>Using Secure Websockets (wss://) with TLS 1.2 or greater with a forward secret cipher will provide Perfect Forward Secrecy (PFS) on the transmission leg.</li> </ul>"},{"location":"aip2/0025-didcomm-transports/#known-implementations_1","title":"Known Implementations","text":"<p>Aries Cloud Agent - Python Aries Framework - .NET</p>"},{"location":"aip2/0025-didcomm-transports/#xmpp","title":"XMPP","text":"<p>XMPP is an effective transport for incoming DID-Communication messages directly to mobile agents, like smartphones.</p> <ul> <li>Incoming DID-Communication messages will arrive, even if the mobile agent is behind a firewall and network-address-translation (NAT).</li> <li>Incoming DID-Communication messages continue to arrive, even when the IP address of the mobile agent changes (switching between, 3G, 4G, Wifi, roaming, ...).</li> <li>Independent of cloud agents and routing agents, as messages arrive directly at the mobile agent.</li> <li>Well suited for direct consumer-to-consumer SSI transactions, from one mobile agent directly to another mobile agent without any DID-Communication intermediaries.</li> <li>Simple encapsulation of DIDcom messages, getting trust from the DIDcom Encryption Envelope.</li> <li>Specified in Aries RFC 0024: DIDCom-over-XMPP</li> </ul>"},{"location":"aip2/0025-didcomm-transports/#known-implementations_2","title":"Known Implementations","text":"<p>XMPP is implemented in the Openfire Server open source project. Integration with DID Communication agents is work-in-progress.</p>"},{"location":"aip2/0025-didcomm-transports/#other-transports","title":"Other Transports","text":"<p>Other transports may be used for Agent messaging. As they are developed, this RFC should be updated with appropriate standards for the transport method. A PR should be raised against this doc to facilitate discussion of the proposed additions and/or updates. New transports should highlight the common elements of the transport (such as an HTTP response code for the HTTP transport) and how they should be applied.</p>"},{"location":"aip2/0025-didcomm-transports/#message-routing","title":"Message Routing","text":"<p>The transports described here are used between two agents. In the case of message routing, a message will travel across multiple agent connections. Each intermediate agent (see Mediators and Relays) may use a different transport. These transport details are not made known to the sender, who only knows the keys of Mediators and the first endpoint of the route.</p>"},{"location":"aip2/0025-didcomm-transports/#message-context","title":"Message Context","text":"<p>The transport used from a previous agent can be recorded in the message trust context. This is particularly true of controlled network environments, where the transport may have additional security considerations not applicable on the public internet. The transport recorded in the message context only records the last transport used, and not any previous routing steps as described in the Message Routing section of this document.</p>"},{"location":"aip2/0025-didcomm-transports/#transport-testing","title":"Transport Testing","text":"<p>Transports which operate on IP based networks can be tested by an Agent Test Suite through a transport adapter. Some transports may be more difficult to test in a general sense, and may need specialized testing frameworks. An agent with a transport not yet supported by any testing suites may have non-transport testing performed by use of a routing agent.</p>"},{"location":"aip2/0025-didcomm-transports/#drawbacks","title":"Drawbacks","text":"<p>Setting transport standards may prevent some uses of each transport method.</p>"},{"location":"aip2/0025-didcomm-transports/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Without standards for each transport, the assumptions of each agent may not align and prevent communication before each message can be unpacked and evaluated.</li> </ul>"},{"location":"aip2/0025-didcomm-transports/#prior-art","title":"Prior art","text":"<p>Several agent implementations already exist that follow similar conventions.</p>"},{"location":"aip2/0025-didcomm-transports/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"aip2/0025-didcomm-transports/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0035-report-problem/","title":"Aries RFC 0035: Report Problem Protocol 1.0","text":"<ul> <li>Authors: Stephen Curran, Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2021-03-15</li> <li>Status Note: Implemented in multiple codebases.</li> <li>Supersedes: Indy HIPE PR #65</li> <li>Start Date: 2018-11-26</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"aip2/0035-report-problem/#summary","title":"Summary","text":"<p>Describes how to report errors and warnings in a powerful, interoperable way. All implementations of SSI agent or hub technology SHOULD implement this RFC.</p>"},{"location":"aip2/0035-report-problem/#motivation","title":"Motivation","text":"<p>Effective reporting of errors and warnings is difficult in any system, and particularly so in decentralized systems such as remotely collaborating agents. We need to surface problems, and their supporting context, to people who want to know about them (and perhaps separately, to people who can actually fix them). This is especially challenging when a problem is detected well after and well away from its cause, and when multiple parties may need to cooperate on a solution.</p> <p>Interoperability is perhaps more crucial with problem reporting than with any other aspect of DIDComm, since an agent written by one developer MUST be able to understand an error reported by an entirely different team. Notice how different this is from normal enterprise software development, where developers only need to worry about understanding their own errors.</p> <p>The goal of this RFC is to provide agents with tools and techniques possible to address these challenges. It makes two key contributions:</p> <ul> <li>A protocol that helps an Agent report problems with appropriate   context. We expect this to be a subprotocol of nearly every interesting application-level   protocol; messages from it may even be adopted into other protocols.</li> <li>An inventory of problem categories and best practices for handling them.</li> </ul>"},{"location":"aip2/0035-report-problem/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0035-report-problem/#error-vs-warning-vs-problem","title":"\"Error\" vs. \"Warning\" vs. \"Problem\"","text":"<p>The distinction between \"error\" and \"warning\" is often thought of as one of severity -- errors are really bad, and warnings are only somewhat bad. This is reinforced by the way logging platforms assign numeric constants to ERROR vs. WARN log events, and by the way compilers let warnings be suppressed but refuse to ignore errors.</p> <p>However, any cybersecurity professional will tell you that warnings sometimes signal deep and scary problems that should not be ignored, and most veteran programmers can tell war stories that reinforce this wisdom. A deeper analysis of warnings reveals that what truly differentiates them from errors is not their lesser severity, but rather their greater ambiguity. Warnings are problems that require human judgment to evaluate, whereas errors are unambiguously bad.</p> <p>The mechanism for reporting problems in DIDComm cannot make a simplistic assumption that all agents are configured to run with a particular verbosity or debug level. Each agent must let other agents decide for themselves, based on policy or user preference, what do do about various issues. For this reason, we use the generic term \"problem\" instead of the more specific and semantically opinionated term \"error\" (or \"warning\") to describe the general situation we're addressing. \"Problem\" includes any deviation from the so-called \"happy path\" of an interaction. This could include situations where the severity is unknown and must be evaluated by a human, as well as surprising events (e.g., a decision by a human to alter the basis for in-flight messaging by moving from one device to another).</p>"},{"location":"aip2/0035-report-problem/#specific-challenges","title":"Specific Challenges","text":"<p>All of the following challenges need to be addressed.</p> <ol> <li>Report problems to external parties interacting with us.   For example, AliceCorp has to be able to tell Bob that it can\u2019t issue the   credential he requested because his payment didn\u2019t go through.</li> <li>Report problems to other entities inside our own domain. For example,   AliceCorp\u2019s agent #1 has to be able to report to AliceCorp agent #2 that   it is out of disk space.</li> <li>Report in a way that provides human beings with useful context and guidance   to troubleshoot.   Most developers know of cases where error reporting was technically correct but   completely useless. Bad communication about problems is one of the most common   causes of UX debacles. Humans using agents will speak different languages, have   differing degrees of technical competence, and have different software and hardware   resources. They may lack context about what their agents are doing, such as when   a DIDComm interaction occurs as a result of scheduled or policy-driven actions.   This makes context and guidance crucial.</li> <li>Map a problem backward in time, space, and circumstances, so when it is   studied, its original context is available. This is particularly difficult   in DIDComm, which is transport-agnostic and inherently asynchronous, and   which takes place on an inconsistently connected digital landscape.</li> <li>Support localization using techniques in the l10n RFC.</li> <li>Provide consistent, locale-independent problem codes, not just localized text,   so problems can be researched in knowledge bases, on Stack Overflow, and in   other internet forums, regardless of the natural language in which a message   displays. This also helps meaning remain stable as wording is tweaked.</li> <li>Provide a registry of well known problem codes that are carefully defined and   localized, to maximize shared understanding. Maintaining an exhaustive list   of all possible things that can go wrong with all possible agents in all possible   interactions is completely unrealistic. However, it may be possible to maintain   a curated subset. While we can't enumerate everything that can go wrong in a   financial transaction, a code for \"insufficient funds\" might have near-universal   usefulness. Compare the posix error inventory in errorno.h.</li> <li>Facilitate automated problem handling by agents, not just manual handling by humans.   Perfect automation may be impossible, but high levels of automation should be   doable.</li> <li>Clarify how the problem affects an in-progress interaction. Does a failure to   process payment reset the interaction to the very beginning of the protocol, or   just back to the previous step, where payment was requested? This requires problems   to be matched in a formal way to the state machine of a protocol underway.</li> </ol>"},{"location":"aip2/0035-report-problem/#the-report-problem-protocol","title":"The <code>report-problem</code> protocol","text":"<p>Reporting problems uses a simple one-step notification protocol. Its official PIURI is:</p> <pre><code>https://didcomm.org/report-problem/1.0\n</code></pre> <p>The protocol includes the standard <code>notifier</code> and <code>notified</code> roles. It defines a single message type <code>problem-report</code>, introduced here. It also adopts the <code>ack</code> message from the <code>ACK 1.0</code> protocol, to accommodate the possibility that the <code>~please_ack</code> decorator may be used on the  notification.</p> <p>A <code>problem-report</code> communicates about a problem when an agent-to-agent message is possible and a recipient for the problem report is known. This covers, for example, cases where a Sender's message gets to an intended Recipient, but the Recipient is unable to process the message for some reason and wants to notify the Sender. It may also be relevant in cases where the recipient of the <code>problem-report</code> is not a message Sender. Of course, a reporting technique that depends on message delivery doesn't apply when the error reporter can't identify or communicate with the proper recipient.</p>"},{"location":"aip2/0035-report-problem/#the-problem-report-message-type","title":"The <code>problem-report</code> message type","text":"<p>Only <code>description.code</code> is required, but a maximally verbose <code>problem-report</code> could contain all of the following:</p> <pre><code>{\n  \"@type\"            : \"https://didcomm.org/report-problem/1.0/problem-report\",\n  \"@id\"              : \"an identifier that can be used to discuss this error message\",\n  \"~thread\"          : \"info about the threading context in which the error occurred (if any)\",\n  \"description\"      : { \"en\": \"localized message\", \"code\": \"symbolic-name-for-error\" },\n  \"problem_items\"    : [ {\"&lt;item descrip&gt;\": \"value\"} ],\n  \"who_retries\"      : \"enum: you | me | both | none\",\n  \"fix_hint\"         : { \"en\": \"localized error-instance-specific hint of how to fix issue\"},\n  \"impact\"           : \"enum: message | thread | connection\",\n  \"where\"            : \"enum: you | me | other - enum: cloud | edge | wire | agency | ..\",\n  \"noticed_time\"     : \"&lt;time&gt;\",\n  \"tracking_uri\"     : \"\",\n  \"escalation_uri\"   : \"\"\n}\n</code></pre>"},{"location":"aip2/0035-report-problem/#field-reference","title":"Field Reference","text":"<p>Some fields will be relevant and useful in many use cases, but not always. Including empty or null fields is discouraged; best practice is to include as many fields as you can fill with useful data, and to omit the others.</p> <p>@id: An identifier for this message, as described in the message threading RFC. This decorator is STRONGLY recommended, because enables a dialog about the problem itself in a branched thread (e.g., suggest a retry, report a resolution, ask for more information).</p> <p>~thread: A thread decorator that places the <code>problem-report</code> into a thread context. If the problem was triggered in the processing of a message, then the triggering message is the head of a new thread of which the problem report is the second member (<code>~thread.sender_order</code> = 0). In such cases, the <code>~thread.pthid</code> (parent thread id) here would be the <code>@id</code> of the triggering message. If the problem-report is unrelated to a message, the thread decorator is mostly redundant, as <code>~thread.thid</code> must equal <code>@id</code>.</p> <p>description: Contains human-readable, localized alternative string(s) that explain the problem. It is highly recommended that the message follow use the guidance in the l10n RFC, allowing the error to be searched on the web and documented formally.</p> <p>description.code: Required. Contains the code that indicates the problem being communicated. Codes are described in protocol RFCs and other relevant places. New Codes SHOULD follow the Problem Code naming convention detailed in the DIDComm v2 spec.</p> <p>problem_items: A list of one or more key/value pairs that are parameters about the problem. Some examples might be:</p> <ul> <li>a list of arguments that didn\u2019t pass input validation</li> <li>the name of a file or URL that could not be fetched</li> <li>the name of a crypto algorithm that the receiving agent didn\u2019t support</li> </ul> <p>All items should have in common the fact that they exemplify the problem described by the code (e.g., each is an invalid param, or each is an unresponsive URL, or each is an unrecognized crypto algorithm, etc).</p> <p>Each item in the list must be a tagged pair (a JSON {key:value}, where the key names the parameter or item, and the value is the actual problem text/number/value. For example, to report that two different endpoints listed in party B\u2019s DID Doc failed to respond when they were contacted, the code might contain \"endpoint-not-responding\", and the problem_items property might contain:</p> <pre><code>[\n  {\"endpoint1\": \"http://agency.com/main/endpoint\"},\n  {\"endpoint2\": \"http://failover.agency.com/main/endpoint\"}\n]\n</code></pre> <p>who_retries: value is the string \"you\", the string \"me\", the string \"both\", or the string \"none\". This property tells whether a problem is considered permanent and who the sender of the problem report believes should have the responsibility to resolve it by retrying. Rules about how many times to retry, and who does the retry, and under what circumstances, are not enforceable and not expressed in the message text. This property is thus not a strong commitment to retry--only a recommendation of who should retry, with the assumption that retries will often occur if they make sense.</p> <p>[TODO: figure out how to identify parties &gt; 2 in n-wise interaction]</p> <p>fix_hint: Contains human-readable, localized suggestions about how to fix this instance of the problem. If present, this should be viewed as overriding general hints found in a message catalog.</p> <p>impact: A string describing the breadth of impact of the problem. An enumerated type:</p> <ul> <li>\"message\" (this is a problem with a single message only; the rest of the interaction may still be fine),</li> <li>\"thread\" (this is a problem that endangers or invalidates the entire thread),</li> <li>\"connection\" (this is a problem that endangers or invalidates the entire connection).</li> </ul> <p>where: A string that describes where the error happened, from the perspective of the reporter, and that uses the \"you\" or \"me\" or \"other\" prefix, followed by a suffix like \"cloud\", \"edge\", \"wire\", \"agency\", etc.</p> <p>noticed_time: Standard time entry (ISO-8601 UTC with at least day precision and up to millisecond precision) of when the problem was detected.</p> <p>[TODO: should we refer to timestamps in a standard way (\"date\"? \"time\"? \"timestamp\"? \"when\"?)]</p> <p>tracking_uri: Provides a URI that allows the recipient to track the status of the error. For example, if the error is related to a service that is down, the URI could be used to monitor the status of the service, so its return to operational status could be automatically discovered.</p> <p>escalation_uri: Provides a URI where additional help on the issue can be received. For example, this might be a \"mailto\" and email address for the Help Desk associated with a currently down service.</p>"},{"location":"aip2/0035-report-problem/#sample","title":"Sample","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/notification/1.0/problem-report\",\n  \"@id\": \"7c9de639-c51c-4d60-ab95-103fa613c805\",\n  \"~thread\": {\n    \"pthid\": \"1e513ad4-48c9-444e-9e7e-5b8b45c5e325\",\n    \"sender_order\": 1\n  },\n  \"~l10n\"            : {\"catalog\": \"https://didcomm.org/error-codes\"},\n  \"description\"      : \"Unable to find a route to the specified recipient.\",\n  \"description~l10n\" : {\"code\": \"cant-find-route\" },\n  \"problem_items\"    : [\n      { \"recipient\": \"did:sov:C805sNYhMrjHiqZDTUASHg\" }\n  ],\n  \"who_retries\"      : \"you\",\n  \"impact\"           : \"message\",\n  \"noticed_time\"     : \"2019-05-27 18:23:06Z\"\n}\n</code></pre>"},{"location":"aip2/0035-report-problem/#categorized-examples-of-errors-and-current-best-practice-handling","title":"Categorized Examples of Errors and (current) Best Practice Handling","text":"<p>The following is a categorization of a number of examples of errors and (current) Best Practice handling for those types of errors. The new <code>problem-report</code> message type is used for some of these categories, but not all.</p>"},{"location":"aip2/0035-report-problem/#unknown-error","title":"Unknown Error","text":"<p>Errors of a known error code will be processed according to the understanding of what the code means. Support of a protocol includes support and proper processing of the error codes detailed within that protocol.</p> <p>Any unknown error code that starts with <code>w.</code> in the DIDComm v2 style may be considered a warning, and the flow of the active protocol SHOULD continue. All other unknown error codes SHOULD be considered to be an end to the active protocol.</p>"},{"location":"aip2/0035-report-problem/#error-while-processing-a-received-message","title":"Error While Processing a Received Message","text":"<p>An Agent Message sent by a Sender and received by its intended Recipient cannot be processed.</p>"},{"location":"aip2/0035-report-problem/#examples","title":"Examples:","text":"<ul> <li>An error occurs in the processing of the message (e.g. missing required parameters, bad data in parameters, etc.)</li> <li>The recipient has no message handler for the message type</li> <li>A message request is rejected because of a policy</li> <li>\"Access denied\" scenarios</li> </ul>"},{"location":"aip2/0035-report-problem/#recommended-handling","title":"Recommended Handling","text":"<p>The Recipient should send the Sender a <code>problem-report</code> Agent Message detailing the issue.</p> <p>The last example deserves an additional comment about whether there should be a response sent at all. Particularly in cases where trust in the message sender is low (e.g. when establishing the connection), an Agent may not want to send any response to a rejected message as even a negative response could reveal correlatable information. That said, if a response is provided, the <code>problem-report</code> message type should be used.</p>"},{"location":"aip2/0035-report-problem/#error-while-routing-a-message","title":"Error While Routing A Message","text":"<p>An Agent in the routing flow of getting a message from a Sender to the Agent Message Recipient cannot route the message.</p>"},{"location":"aip2/0035-report-problem/#examples_1","title":"Examples:","text":"<ul> <li>Unknown \"To\" destination for the message</li> <li>Insufficient resources (disk space, network access)</li> <li>Unable to decrypt the message</li> </ul>"},{"location":"aip2/0035-report-problem/#recommended-handling_1","title":"Recommended Handling","text":"<p>If the Sender is known to the Agent having the problem, send a <code>problem-report</code> Agent Message detailing at least that a blocking issue occurred, and if relevant (such as in the first example), some details about the issue. If the message is valid, and the problem is related to a lack of resources (e.g. the second issue), also send a <code>problem-report</code> message to an escalation point within the domain.</p> <p>Alternatively, the capabilities described in 0034: Message Tracing could be used to inform others of the fact that an issue occurred.</p>"},{"location":"aip2/0035-report-problem/#messages-triggered-about-a-transaction","title":"Messages Triggered about a Transaction","text":""},{"location":"aip2/0035-report-problem/#examples_2","title":"Examples:","text":"<ul> <li>\"You\u2019re asking for more information than we agreed to\" or \"You\u2019re giving me more than I expected.\"</li> <li>Couldn\u2019t pay (insufficient funds, payment mechanism is offline\u2026)</li> <li>You violated the terms of service we agreed to, because I see that my info has been leaked.</li> <li>Your credential has been revoked (asynchronous)</li> <li>A is unwilling to consent to the terms and conditions that B proposes.</li> </ul>"},{"location":"aip2/0035-report-problem/#recommended-handling_2","title":"Recommended Handling","text":"<p>These types of error scenarios represent a gray error in handling between using the generic <code>problem-report</code> message format, or a message type that is part of the current transaction's message family. For example, the \"Your credential has been revoked\" might well be included as a part of the (TBD) standard Credentials Exchange message family. The \"more information\" example might be a generic error across a number of message families and so should trigger a <code>problem-report</code>) or, might be specific to the ongoing thread (e.g. Credential Exchange) and so be better handled by a defined message within that thread and that message family.</p> <p>The current advice on which to use in a given scenario is to consider how the recipient will handle the message. If the handler will need to process the response in a specific way for the transaction, then a message family-specific message type should be used. If the error is cross-cutting such that a common handler can be used across transaction contexts, then a generic <code>problem-report</code> should be used.</p> <p>\"Current advice\" implies that as we gain more experience with Agent To Agent messaging, the recommendations could get more precise.</p>"},{"location":"aip2/0035-report-problem/#messaging-channel-settings","title":"Messaging Channel Settings","text":""},{"location":"aip2/0035-report-problem/#examples_3","title":"Examples","text":"<ul> <li>\"Please resend so a different one of my agents can read this.\", or, \"Agent X no longer in service. Use Agent Y instead.\"</li> <li>A received a message from B that it cannot understand (message garbled, can\u2019t be decrypted, is of an unrecognized type, uses crypto from a library that A doesn\u2019t have, etc)</li> <li>A wants to report to B that it believes A has been hacked, or that it is under attack</li> <li>A wants to report to B that it believes B has been hacked, or that it is under attack</li> <li>Version incompatibilities of various kinds (transport version incompatibilities [http 1.1 vs. 2.0]; agent message type version incompatibilities)</li> </ul>"},{"location":"aip2/0035-report-problem/#recommended-handling_3","title":"Recommended Handling","text":"<p>These types of messages might or might not be triggered during the receipt and processing of a message, but either way, they are unrelated to the message and are really about the communication channel between the entities. In such cases, the recommended approach is to use a (TBD) standard message family to notify and rectify the issue (e.g. change the attributes of a connection). The definition of that message family is outside the scope of this RFC.</p>"},{"location":"aip2/0035-report-problem/#timeouts","title":"Timeouts","text":"<p>A special generic class of errors that deserves mention is the timeout, where a Sender sends out a message and does not receive back a response in a given time. In a distributed environment such as Agent to Agent messaging, these are particularly likely - and particularly difficult to handle gracefully. The potential reasons for timeouts are numerous:</p> <ul> <li>loss of connectivity</li> <li>resource errors with one of the Agents between the Sender and Receiver</li> <li>not yet detected key rotations (cached DIDDocs and encryption keys)</li> <li>errors occurring in an Agent unaware of the Sender (so cannot notify the sender of the issue)</li> <li>Recipient offline for an extended period</li> <li>disinterest on the part of the Recipient (received, but no response sent back)</li> </ul>"},{"location":"aip2/0035-report-problem/#recommended-handling_4","title":"Recommended Handling","text":"<p>Appropriate timeout handling is extremely contextual, with two key parameters driving the handling - the length of the waiting period before triggering the timeout and the response to a triggered timeout.</p> <p>The time to wait for a response should be dynamic by at least type of message, and ideally learned through experience. Messages requiring human interaction should have an inherently longer timeout period than a message expected to be handled automatically. Beyond that, it would be good for Agents to track response times by message type (and perhaps other parameters) and adjust timeouts to match observed patterns.</p> <p>When a timeout is received there are three possible responses, handled automatically or based on feedback from the user:</p> <ul> <li>Wait longer</li> <li>Retry</li> <li>Give up</li> </ul> <p>An automated \"wait longer\" response might be used when first interacting with a particular message type or identity, as the response cadence is learned.</p> <p>If the decision is to retry, it would be good to have support in areas covered by other RFCs. First, it would be helpful (and perhaps necessary) for the threading decorator to support the concept of retries, so that a Recipient would know when a message is a retry of an already sent message.  Next, on \"forward\" message types, Agents might want to know that a message was a retry such that they can consider refreshing DIDDoc/encryption key cache before sending the message along. It could also be helpful for a retry to interact with the Tracing facility so that more information could be gathered about why messages are not getting to their destination.</p> <p>Excessive retrying can exacerbate an existing system issue. If the reason for the timeout is because there is a \"too many messages to be processed\" situation, then sending retries simply makes the problem worse. As such, a reasonable backoff strategy should be used (e.g. exponentially increasing times between retries). As well, a strategy used at Uber is to flag and handle retries differently from regular messages. The analogy with Uber is not pure - that is a single-vendor system - but the notion of flagging retries such that retry messages can be handled differently is a good approach.</p>"},{"location":"aip2/0035-report-problem/#caveat-problem-report-loops","title":"Caveat: Problem Report Loops","text":"<p>Implementers should consider and mitigate the risk of an endless loop of error messages. For example:</p> <ul> <li>Alice sends a message to Bob that Bob doesn't recognize. Bob sends a <code>Problem Report</code> message to Alice.</li> <li>Alice doesn't understand the message from Bob and sends a <code>Problem Report</code> to Bob.</li> <li>Bob doesn't understand the message from Alice and sends a <code>Problem Report</code> to Alice. And so on...</li> </ul>"},{"location":"aip2/0035-report-problem/#recommended-handling_5","title":"Recommended Handling","text":"<p>How agents mitigate the risk of this problem is implementation specific, balancing loop-tracking overhead versus the likelihood of occurrence. For example, an agent implementation might have a counter on a connection object that is incremented when certain types of <code>Problem Report</code> messages are sent on that connection, and reset when any other message is sent. The agent could stop sending those types of <code>Problem Report</code> messages after the counter reaches a given value.</p>"},{"location":"aip2/0035-report-problem/#reference","title":"Reference","text":"<p>TBD</p>"},{"location":"aip2/0035-report-problem/#drawbacks","title":"Drawbacks","text":"<p>In many cases, a specific <code>problem-report</code> message is necessary, so formalizing the format of the message is also preferred over leaving it to individual implementations. There is no drawback to specifying that format now.</p> <p>As experience is gained with handling distributed errors, the recommendations provided in this RFC will have to evolve.</p>"},{"location":"aip2/0035-report-problem/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>The error type specification mechanism builds on the same approach used by the message type specifications. It's possible that additional capabilities could be gained by making runtime use of the error type specification - e.g. for the broader internationalization of the error messages.</p> <p>The main alternative to a formally defined error type format is leaving it to individual implementations to handle error notifications, which will not lead to an effective solution.</p>"},{"location":"aip2/0035-report-problem/#prior-art","title":"Prior art","text":"<p>A brief search was done for error handling in messaging systems with few useful results found. Perhaps the best was the Uber article referenced in the \"Timeout\" section above.</p>"},{"location":"aip2/0035-report-problem/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Can the Tracing facility provide a trusted way to better handle distributed errors in a production environment?</li> <li>Denial of service via problems that spam the wrong person with   a problem report.</li> </ul>"},{"location":"aip2/0035-report-problem/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes RFC 0036: Issue Credential Protocol The <code>problem-report</code> message is adopted by this protocol. MISSING test results RFC 0037: Present Proof Protocol The <code>problem-report</code> message is adopted by this protocol. MISSING test results Trinsic.id Commercial mobile and web app built using Aries Framework - .NET MISSING test results"},{"location":"aip2/0044-didcomm-file-and-mime-types/","title":"Aries RFC 0044: DIDComm File and MIME Types","text":"<ul> <li>Authors: Daniel Hardman, Kyle Den Hartog</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Revised as part of AIP 2.0 to ease the upcoming transition from DIDComm v1 to DIDComm v2.</li> <li>Start Date: 2018-11-13</li> <li>Tags: feature</li> </ul>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#summary","title":"Summary","text":"<p>Defines the media (MIME) types and file types that hold DIDComm messages in encrypted, signed, and plaintext forms. Covers DIDComm V1, plus a little of V2 to clarify how DIDComm versions are detected.</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#motivation","title":"Motivation","text":"<p>Most work on DIDComm so far has assumed HTTP as a transport. However, we know that DID communication is transport-agnostic. We should be able to say the same thing no matter which channel we use.</p> <p>An incredibly important channel or transport for messages is digital files. Files can be attached to messages in email or chat, can be carried around on a thumb drive, can be backed up, can be distributed via CDN, can be replicated on distributed file systems like IPFS, can be inserted in an object store or in content-addressable storage, can be viewed and modified in editors, and support a million other uses.</p> <p>We need to define how files and attachments can contain DIDComm messages, and what the semantics of processing such files will be.</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0044-didcomm-file-and-mime-types/#media-types","title":"Media Types","text":"<p>Media types are based on the conventions of RFC6838. Similar to RFC7515, the <code>application/</code> prefix MAY be omitted and the recipient MUST treat media types not containing <code>/</code> as having the <code>application/</code> prefix present.</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#didcomm-v1-encrypted-envelope-dee","title":"DIDComm v1 Encrypted Envelope (*.dee)","text":"<p>The raw bytes of an encrypted envelope may be persisted to a file without any modifications whatsoever. In such a case, the data will be encrypted and packaged such that only specific receiver(s) can process it. However, the file will contain a JOSE-style header that can be used by magic bytes algorithms to detect its type reliably.</p> <p>The file extension associated with this filetype is <code>dee</code>, giving a globbing pattern  of <code>*.dee</code>; this should be be read as \"STAR DOT D E E\" or as \"D E E\" files.</p> <p>The name of this file format is \"DIDComm V1 Encrypted Envelope.\" We expect people to say, \"I am looking at a DIDComm V1 Encrypted Envelope\", or \"This file is in DIDComm V1 Encrypted Envelope format\", or \"Does my editor have a DIDComm V1 Encrypted Envelope plugin?\"</p> <p>Although the format of encrypted envelopes is derived from JSON and the JWT/JWE family of specs, no useful processing of these files will take place by viewing them as JSON, and viewing them as generic JWEs will greatly constrain which semantics are applied. Therefore, the recommended MIME type for *.dee files is <code>application/didcomm-envelope-enc</code>, with <code>application/jwe</code> as a fallback, and <code>application/json</code> as an even less desirable fallback. (In this, we are making a choice similar to the one that views <code>*.docx</code> files primarily as <code>application/msword</code> instead of <code>application/xml</code>.) If format evolution takes place, the version could become a parameter as described in RFC 1341: <code>application/didcomm-envelope-enc;v=2</code>.</p> <p>A recipient using the media type value MUST treat it as if <code>\u201capplication/\u201d</code> were prepended to any <code>\"typ\"</code> or <code>\"cty\"</code> value not containing a \u2018/\u2019 in compliance  with the JWE /JWS  family of specs.</p> <p>The default action for DIDComm V1 Encrypted Envelopes (what happens when a user double-clicks one) should be <code>Handle</code> (that is, process the message as if it had just arrived by some other transport), if the software handling the message is an agent. In other types of software, the default action might be to view the file. Other useful actions might include <code>Send</code>, <code>Attach</code> (to email, chat, etc), <code>Open with agent</code>, and <code>Decrypt to *.dp</code>.</p> <p>NOTE: The analog to this content type in DIDComm v2 is called a \"DIDComm Encrypted Message.\" Its format is slightly different. For more info, see Detecting DIDComm Versions below.</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#didcomm-v1-signed-envelopes-dse","title":"DIDComm V1 Signed Envelopes (*.dse)","text":"<p>When DIDComm messages are signed, the signing uses a JWS signing envelope. Often signing is unnecessary, since authenticated encryption proves the sender of the message to the recipient(s), but sometimes when non-repudiation is required, this envelope is used. It is also required when the recipient of a message is unknown, but tamper-evidence is still required, as in the case of a public invitation.</p> <p>By convention, DIDComm Signed Envelopes contain plaintext; if encryption is used in combination with signing, the DSE goes inside the DEE.</p> <p>The file extension associated with this filetype is <code>dse</code>, giving a globbing pattern  of <code>*.dse</code>; this should be be read as \"STAR DOT D S E\" or as \"D S E\" files.</p> <p>The name of this file format is \"DIDComm V1 Signed Envelope.\" We expect people to say, \"I am looking at a DIDComm V1 Signed Envelope\", or \"This file is in DIDComm V1 Signed Envelope format\", or \"Does my editor have a DIDComm V1 Signed Envelope plugin?\"</p> <p>As with *.dee files, the best way to hande *.dse files is to map them to a custom MIME type. The recommendation is <code>application/didcomm-sig-env</code>, with <code>application/jws</code> as a fallback, and <code>application/json</code> as an even less desirable fallback.</p> <p>A recipient using the media type value MUST treat it as if <code>\u201capplication/\u201d</code> were prepended to any <code>\"typ\"</code> or <code>\"cty\"</code> value not containing a \u2018/\u2019 in compliance  with the JWE /JWS family of specs.</p> <p>The default action for DIDComm V1 Signed Envelopes (what happens when a user double-clicks one) should be <code>Validate</code> (that is, process the signature to see if it is valid.</p> <p>NOTE: The analog to this content type in DIDComm v2 is called a \"DIDComm Signed Message.\" Its format is slightly different. For more info, see Detecting DIDComm Versions below.</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#didcomm-v1-messages-dm","title":"DIDComm V1 Messages (*.dm)","text":"<p>The plaintext representation of a DIDComm message--something like a credential offer, a proof request, a connection invitation, or anything else worthy of a DIDComm protocol--is JSON. As such, it should be editable by anything that expects JSON.</p> <p>However, all such files have some additional conventions, over and above the simple requirements of JSON. For example, key decorators have special meaning ( <code>@id</code>, <code>~thread</code>, <code>@trace</code> , etc). Nonces may be especially significant. The format of particular values such as DID and DID+key references is important. Therefore, we refer to these messages generically as JSON, but we also define a file format for tools that are aware of the additional semantics.</p> <p>The file extension associated with this filetype is <code>*.dm</code>, and should be read as \"STAR DOT D M\" or \"D M\" files. If a format evolution takes place, a subsequent version could be noted by appending a digit, as in <code>*.dm2</code> for second-generation <code>dm</code> files.</p> <p>The name of this file format is \"DIDComm V1 Message.\" We expect people to say, \"I am looking at a DIDComm V1 Message\", or \"This file is in DIDComm V1 Message format\", or \"Does my editor have a DIDComm V1 Message plugin?\" For extra clarity, it is acceptable to add the adjective \"plaintext\", as in \"DIDComm V1 Plaintext Message.\"</p> <p>The most specific MIME type of *.dm files is <code>application/json;flavor=didcomm-msg</code>--or, if more generic handling is appropriate, just  <code>application/json</code>.</p> <p>A recipient using the media type value MUST treat it as if <code>\u201capplication/\u201d</code> were prepended to any <code>\"typ\"</code> or <code>\"cty\"</code> value not containing a \u2018/\u2019 in compliance  with the JWE /JWS family of specs.</p> <p>The default action for DIDComm V1 Messages should be to <code>View</code> or <code>Validate</code> them. Other interesting actions might be <code>Encrypt to *.dee</code>, <code>Sign to *.dse</code>, and <code>Find definition of protocol</code>.</p> <p>NOTE: The analog to this content type in DIDComm v2 is called a \"DIDComm Plaintext Message.\" Its format is slightly different. For more info, see Detecting DIDComm Versions below.</p> <p>As a general rule, DIDComm messages that are being sent in production use cases of DID communication should be stored in encrypted form (<code>*.dee</code>) at rest. There are cases where this might not be preferred, e.g., providing documentation of the format of message or during a debugging scenario using message tracing. However, these are exceptional cases. Storing meaningful <code>*.dm</code> files decrypted is not a security best practice, since it replaces all the privacy and security guarantees provided by the DID communication mechanism with only the ACLs and other security barriers that are offered by the container.</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#native-object-representation","title":"Native Object representation","text":"<p>This is not a file format, but rather an in-memory form of a DIDComm Message using whatever object hierarchy is natural for a programming language to map to and from JSON. For example, in python, the natural Native Object format is a dict that contains properties indexed by strings. This is the representation that python's <code>json</code> library expects when converting to JSON, and the format it produces when converting from JSON. In Java, Native Object format might be a bean. In C++, it might be a <code>std::map&lt;std::string, variant&gt;</code>...</p> <p>There can be more than one Native Object representation for a given programming language.</p> <p>Native Object forms are never rendered directly to files; rather, they are serialized to DIDComm Plaintext Format and then persisted (likely after also encrypting to DIDComm V1 Encrypted Envelope).</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#negotiating-compatibility","title":"Negotiating Compatibility","text":"<p>When parties want to communicate via DIDComm, a number of mechanisms must align. These include:</p> <ol> <li>The type of service endpoint used by each party</li> <li>The key types used for encryption and/or signing</li> <li>The format of the encryption and/or signing envelopes</li> <li>The encoding of plaintext messages</li> <li>The protocol used to forward and route</li> <li>The protocol embodied in the plaintext messages</li> </ol> <p>Although DIDComm allows flexibility in each of these choices, it is not expected that a given DIDComm implementation will support many permutations. Rather, we expect a few sets of choices that commonly go together. We call a set of choices that work well together a profile. Profiles are identified by a string that matches the conventions of IANA media types, but they express choices about plaintext, encryption, signing, and routing in a single value. The following profile identifiers are defined in this version of the RFC:</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#defined-profiles","title":"Defined Profiles","text":"<ul> <li><code>didcomm/aip1</code>: The encryption envelope, signing mechanism, plaintext conventions, and routing algorithms embodied in Aries AIP 1.0, circa 2020.</li> <li><code>didcomm/aip2;env=rfc19</code>: The signing mechanism, plaintext conventions, and routing algorithms embodied in Aries AIP 2.0, circa 2021 -- with the old-style encryption envelope from Aries RFC 0019. This legal variant of AIP 2.0 minimizes differences with codebases that shipped AIP 1.0 support.</li> <li><code>didcomm/aip2;env=rfc587</code>: The signing mechanism, plaintext conventions, and routing algorithms embodied in Aries AIP 2.0, circa 2021 -- with the new-style encryption envelope from Aries RFC 0587. This legal variant of AIP 2.0 lays the foundation for DIDComm v2 support by anticipating the eventual envelope change.</li> <li><code>didcomm/v2</code>: The encryption envelope, signing mechanism, plaintext conventions, and routing algorithms embodied in the DIDComm messaging spec.</li> </ul> <p>Profiles are named in the <code>accept</code> section of a DIDComm service endpoint and in an out-of-band message. When Alice declares that she accepts <code>didcomm/aip2;env=rfc19</code>, she is making a declaration about more than her own endpoint. She is saying that all publicly visible steps in an inbound route to her will use the <code>didcomm/aip2;env=rfc19</code> profile, such that a sender only has to use <code>didcomm/aip2;env=rfc19</code> choices to get the message from Alice's outermost mediator to Alice's edge. It is up to Alice to select and configure mediators and internal routing in such a way that this is true for the sender.</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#detecting-didcomm-versions","title":"Detecting DIDComm Versions","text":"<p>Because media types differ from DIDComm V1 to V2, and because media types are easy to communicate in headers and message fields, they are a convenient way to detect which version of DIDComm applies in a given context:</p> Nature of Content V1 V2 encrypted <code>application/didcomm-envelope-enc</code>DIDComm V1 Encrypted Envelope*.dee <code>application/didcomm-encrypted+json</code>DIDComm Encrypted Message*.dcem signed <code>application/didcomm-sig-env</code>DIDComm V1 Signed Envelope*.dse <code>application/didcomm-signed+json</code>DIDComm Signed Message*.dcsm plaintext <code>application/json;flavor=didcomm-msg</code>DIDComm V1 Message*.dm <code>application/didcomm-plain+json</code>DIDComm Plaintext Message*.dcpm <p>It is also recommended that agents implementing Discover Features Protocol v2 respond to queries about supported DIDComm versions using the <code>didcomm-version</code> feature name. This allows queries about what an agent is willing to support, whereas the media type mechanism describes what is in active use. The values that should be returned from such a query are URIs that tell where DIDComm versions are developed:</p> Version URI V1 https://github.com/hyperledger/aries-rfcs V2 https://github.com/decentralized-identity/didcomm-messaging"},{"location":"aip2/0044-didcomm-file-and-mime-types/#what-it-means-to-implement-this-rfc","title":"What it means to \"implement\" this RFC","text":"<p>For the purposes of Aries Interop Profiles, an agent \"implements\" this RFC when:</p> <ul> <li>If it encounters references to DIDComm V1 media types (e.g., in HTTP headers, in attachments, or in the fields of DIDComm messages where a media type is expected), it imputes the meaning documented here.</li> <li>If it characterizes DIDComm V1 content in its own outbound communication or UI, it does so with the media type strings, friendly names, and file extensions documented here.</li> </ul>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#reference","title":"Reference","text":"<p>The file extensions and MIME types described here are also accompanied by suggested graphics. Vector forms of these graphics are available.</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0046-mediators-and-relays/","title":"Aries RFC 0046: Mediators and Relays","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2019-02-01</li> <li>Status Note: Socialized and broadly understood in other conceptual RFCs about routing.</li> <li>Start Date: 2018-12-01</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0046-mediators-and-relays/#summary","title":"Summary","text":"<p>The mental model for agent-to-agent messaging (A2A) messaging includes two important communication primitives that have a meaning unique to our ecosystem: mediator and relay.</p> <p>A mediator is a participant in agent-to-agent message delivery that must be modeled by the sender. It has its own keys and will deliver messages only after decrypting an outer envelope to reveal a <code>forward</code> request. Many types of mediators may exist, but two important ones should be widely understood, as they commonly manifest in DID Docs:</p> <ol> <li>A service that hosts many cloud agents at a single endpoint to provide herd privacy (an \"agency\") is a mediator.</li> <li>A cloud-based agent that routes between/among the edges of a sovereign domain is a mediator.</li> </ol> <p>A relay is an entity that passes along agent-to-agent messages, but that can be ignored when the sender considers encryption choices. It does not decrypt anything. Relays can be used to change the transport for a message (e.g., accept an HTTP POST, then turn around and emit an email; accept a Bluetooth transmission, then turn around and emit something in a message queue). Mix networks like TOR are an important type of relay.</p> <p>Read on to explore how agent-to-agent communication can model complex topologies and flows using these two primitives.</p>"},{"location":"aip2/0046-mediators-and-relays/#motivation","title":"Motivation","text":"<p>When we describe agent-to-agent communication, it is convenient to think of an interaction only in terms of Alice and Bob and their agents. We say things like: \"Alice's agent sends a message to Bob's agent\" -- or perhaps \"Alice's edge agent sends a message to Bob's cloud agent, which forwards it to Bob's edge agent\".</p> <p>Such statements adopt a useful level of abstraction--one that's highly recommended for most discussions. However, they make a number of simplifications. By modeling the roles of mediators and relays in routing, we can support routes that use multiple transports, routes that are not fully known (or knowable) to the sender, routes that pass through mix networks, and other advanced and powerful ../../concepts.</p>"},{"location":"aip2/0046-mediators-and-relays/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0046-mediators-and-relays/#key-concepts","title":"Key Concepts","text":"<p>Let's define mediators and relays by exploring how they manifest in a series of communication scenarios between Alice and Bob.</p>"},{"location":"aip2/0046-mediators-and-relays/#scenario-1-base","title":"Scenario 1 (base)","text":"<p>Alice and Bob are both employees of a large corporation. They work in the same office, but have never met. The office has a rule that all messages between employees must be encrypted. They use paper messages and physical delivery as the transport. Alice writes a note, encrypts it so only Bob can read it, puts it in an envelope addressed to Bob, and drops the envelope on a desk that she has been told belongs to Bob. This desk is in fact Bob's, and he later picks up the message, decrypts it, and reads it.</p> <p></p> <p>In this scenario, there is no mediator, and no relay.</p>"},{"location":"aip2/0046-mediators-and-relays/#scenario-2-a-gatekeeper","title":"Scenario 2: a gatekeeper","text":"<p>Imagine that Bob hires an executive assistant, Carl, to filter his mail. Bob won't open any mail unless Carl looks at it and decides that it's worthy of Bob's attention.</p> <p>Alice has to change her behavior. She continues to package a message for Bob, but now she must account for Carl as well. She take the envelope for Bob, and places it inside a new envelope addressed to Carl. Inside the outer envelope, and next to the envelope destined for Bob, Alice writes Carl an encrypted note: \"This inner envelope is for Bob. Please forward.\"</p> <p></p> <p>Here, Carl is acting as a mediator. He is mostly just passing messages along. But because he is processing a message himself, and because Carl is interposed between Alice and Bob, he affects the behavior of the sender. He is a known entity in the route.</p>"},{"location":"aip2/0046-mediators-and-relays/#scenario-3-transparent-indirection","title":"Scenario 3: transparent indirection","text":"<p>All is the same as the base scenario (Carl has been fired), except that Bob is working from home when Alice's message lands on his desk. Bob has previously arranged with his friend Darla, who lives near him, to pick up any mail that's on his desk and drop it off at his house at the end of the work day. Darla sees Alice's note and takes it home to Bob.</p> <p></p> <p>In this scenario, Darla is acting as a relay. Note that Bob arranges for Darla to do this without notifying Alice, and that Alice does not need to adjust her behavior in any way for the relay to work.</p>"},{"location":"aip2/0046-mediators-and-relays/#scenario-4-more-indirection","title":"Scenario 4: more indirection","text":"<p>Like scenario 3, Darla brings Bob his mail at home. However, Bob isn't at home when his mail arrives. He's had to rush out on an errand, but he's left instructions with his son, Emil, to open any work mail, take a photo of the letter, and text him the photo. Emil intends to do this, but the camera on his phone misfires, so he convinces his sister, Francis, to take the picture on her phone and email it to him. Then he texts the photo to Bob, as arranged.</p> <p></p> <p>Here, Emil and Francis are also acting as relays. Note that nobody knows about the full route. Alice thinks she's delivering directly to Bob. So does Darla. Bob knows about Darla and Emil, but not about Francis.</p> <p>Note, too, how the transport is changing from physical mail to email to text.</p> <p>To the party immediately upstream (closer to the sender), a relay is indistinguishable from the next party downstream (closer to the recipient). A party anywhere in the chain can insert one or more relays upstream from themselves, as long as those relays are not upstream of another named party (sender or mediator).</p>"},{"location":"aip2/0046-mediators-and-relays/#more-scenarios","title":"More Scenarios","text":"<p>Mediators and relays can be combined in any order and any amount in variations on our fictional scenario. Bob could employ Carl as a mediator, and Carl could work from home and arrange delivery via George, then have his daughter Hannah run messages back to Bob's desk at work. Carl could hire his own mediator. Darla could arrange or Ivan to substitute for her when she goes on vacation. And so forth.</p>"},{"location":"aip2/0046-mediators-and-relays/#more-traditional-usage","title":"More Traditional Usage","text":"<p>The scenarios used above are somewhat artificial. Our most familiar agent-to-agent scenarios involve edge agents running on mobile devices and accessible through bluetooth or push notification, and cloud agents that use electronic protocols as their transport. Let's see how relays and mediators apply there.</p>"},{"location":"aip2/0046-mediators-and-relays/#scenario-5-traditional-base","title":"Scenario 5 (traditional base)","text":"<p>Alice's cloud agent wants to talk to Bob's cloud agent. Bob's cloud agent is listening at http://bob.com/agent. Alice encrypts a message for Bob and posts it to that URL.</p> <p></p> <p>In this scenario, we are using a direct transport with neither a mediator nor a relay.</p> <p>If you are familiar with common routing patterns and you are steeped in HTTP, you are likely objecting at this point, pointing out ways that this description diverges from best practice, including what's prescribed in other RFC. You may be eager to explain why this is a privacy problem, for example.</p> <p>You are not wrong, exactly. But please suspend those concerns and hang with me. This is about what's theoretically possible in the mental model. Besides, I would note that virtually the same diagram could be used for a Bluetooth agent conversation:</p> <p></p>"},{"location":"aip2/0046-mediators-and-relays/#scenario-6-herd-hosting","title":"Scenario 6: herd hosting","text":"<p>Let's tweak Scenario 5 slightly by saying that Bob's agent is one of thousands that are hosted at the same URL. Maybe the URL is now http://agents-r-us.com/inbox. Now if Alice wants to talk to Bob's cloud agent, she has to cope with a mediator. She wraps the encrypted message for Bob's cloud agent inside a <code>forward</code> message that's addressed to and encrypted for the agent of agents-r-us that functions as a gatekeeper.</p> <p></p> <p>This scenario is one that highlights an external mediator--so-called because the mediator lives outside the sovereign domain of the final recipient.</p>"},{"location":"aip2/0046-mediators-and-relays/#scenario-7-intra-domain-dispatch","title":"Scenario 7: intra-domain dispatch","text":"<p>Now let's subtract agents-r-us. We're back to Bob's cloud agent listening directly at http://bob.com/agent. However, let's say that Alice has a different goal--now she wants to talk to the edge agent running on Bob's mobile device. This agent doesn't have a permanent IP address, so Bob uses his own cloud agent as a mediator. He tells Alice that his mobile device agent can only be reached via his cloud agent.</p> <p></p> <p>Once again, this causes Alice to modify her behavior. Again, she wraps her encrypted message. The inner message is enclosed in an outer envelope, and the outer envelope is passed to the mediator.</p> <p>This scenario highlights an internal mediator. Internal and external mediators introduce similar ../../features and similar constraints; the relevant difference is that internal mediators live within the sovereign domain of the recipient, and may thus be worthy of greater trust.</p>"},{"location":"aip2/0046-mediators-and-relays/#scenario-8-double-mediation","title":"Scenario 8: double mediation","text":"<p>Now let's combine. Bob's cloud agent is hosted at agents-r-us, AND Alice wants to reach Bob's mobile:</p> <p></p> <p>This is a common pattern with HTTP-based cloud agents plus mobile edge agents, which is the most common deployment pattern we expect for many users of self-sovereign identity. Note that the properties of the agency and the routing agent are not particularly special--they are just an external and an internal mediator, respectively.</p>"},{"location":"aip2/0046-mediators-and-relays/#related-concepts","title":"Related Concepts","text":""},{"location":"aip2/0046-mediators-and-relays/#routes-are-one-way-not-duplex","title":"Routes are One-Way (not duplex)","text":"<p>In all of this discussion, note that we are analyzing only a flow from Alice to Bob. How Bob gets a message back to Alice is a completely separate question. Just because Carl, Darla, Emil, Francis, and Agents-R-Us may be involved in how messages flow from Alice to Bob, does not mean they are involved in flow the opposite direction.</p> <p>Note how this breaks the simple assumptions of pure request-response technologies like HTTP, that assume the channel in (request) is also the channel out (response). Duplex request-response can be modeled with A2A, but doing so requires support that may not always be available, plus cooperative behavior governed by the <code>~thread</code> decorator.</p>"},{"location":"aip2/0046-mediators-and-relays/#conventions-on-direction","title":"Conventions on Direction","text":"<p>For any given one-way route, the direction of flow is always from sender to receiver. We could use many different metaphors to talk about the \"closer to sender\" and \"closer to receiver\" directions -- upstream and downstream, left and right, before and after, in and out. We've chosen to standardize on two:</p> <ul> <li> <p>The SSI Notation uses directional arrows. A message from Alice to Bob is notated as either <code>A --&gt; B</code> or <code>B &lt;-- A</code> -- whether the arrow faces left or right, it always points to Bob.</p> </li> <li> <p>In text, we use the words source-ward and dest-ward to clarify whether we are moving toward the sender, or toward the receiver, respectively. \"Dest-ward\" always corresponds to where the arrow is pointing and to later points in time; \"source-ward\" is the opposite direction. All messages, whether requests, responses, or otherwise, always flow dest-ward.</p> </li> </ul>"},{"location":"aip2/0046-mediators-and-relays/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem. DIDComm mediator Open source cloud-based mediator with Firebase support."},{"location":"aip2/0047-json-ld-compatibility/","title":"Aries RFC 0047: JSON-LD Compatibility","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2019-02-20</li> <li>Status Note: Has guided Indy design choices for several months. Not yet ratified by greater Aries community. </li> <li>Supersedes: Indy HIPE 0035</li> <li>Start Date: 2019-01-23</li> <li>Tags: concept, decorator</li> </ul>"},{"location":"aip2/0047-json-ld-compatibility/#summary","title":"Summary","text":"<p>Explains the goals of DID Communication with respect to JSON-LD, and how Aries proposes to accomplish them.</p>"},{"location":"aip2/0047-json-ld-compatibility/#motivation","title":"Motivation","text":"<p>JSON-LD is a familiar body of conventions that enriches the expressive power of plain JSON. It is natural for people who arrive in the DID Communication (DIDComm) ecosystem to wonder whether we are using JSON-LD--and if so, how. We need a coherent answer that clarifies our intentions and that keeps us true to those intentions as the ecosystem evolves.</p>"},{"location":"aip2/0047-json-ld-compatibility/#tutorial","title":"Tutorial","text":"<p>The JSON-LD spec is a recommendation work product of the W3C RDF Working Group Since it was formally recommended as version 1.0 in 2014, the JSON for Linking Data Community Group has taken up not-yet-standards-track work on a 1.1 update.</p> <p>JSON-LD has significant gravitas in identity circles. It gives to JSON some capabilities that are sorely needed to model the semantic web, including linking, namespacing, datatyping, signing, and a strong story for schema (partly through the use of JSON-LD on schema.org).</p> <p>However, JSON-LD also comes with some conceptual and technical baggage. It can be hard for developers to master its subtleties; it requires very flexible parsing behavior after built-in JSON support is used to deserialize; it references a family of related specs that have their own learning curve; the formality of its test suite and libraries may get in the way of a developer who just wants to read and write JSON and \"get stuff done.\"</p> <p>In addition, the problem domain of DIDComm is somewhat different from the places where JSON-LD has the most traction. The sweet spot for DIDComm is small, relatively simple JSON documents where code behavior is strongly bound to the needs of a specific interaction. DIDComm needs to work with extremely simple agents on embedded platforms. Such agents may experience full JSON-LD support as an undue burden when they don't even have a familiar desktop OS. They don't need arbitrary semantic complexity.</p> <p>If we wanted to use email technology to send a verifiable credential, we would model the credential as an attachment, not enrich the schema of raw email message bodies. DIDComm invites a similar approach.</p>"},{"location":"aip2/0047-json-ld-compatibility/#goal","title":"Goal","text":"<p>The DIDComm messaging effort that began in the Indy community wants to benefit from the accessibility of ordinary JSON, but leave an easy path for more sophisticated JSON-LD-driven patterns when the need arises. We therefore set for ourselves this goal:</p> <p>Be compatible with JSON-LD, such that advanced use cases can take advantage   of it where it makes sense, but impose no dependencies on the mental model or   the tooling of JSON-LD for the casual developer.</p>"},{"location":"aip2/0047-json-ld-compatibility/#what-the-casual-developer-needs-to-know","title":"What the Casual Developer Needs to Know","text":"<ul> <li> <p>The <code>@</code> character in DIDComm messages is reserved for JSON-LD-isms. Any usage of JSON keys that begin with this character is required to be JSON-LD-compatible, and any time you see it, you are seeing JSON-LD at work.</p> </li> <li> <p><code>@type</code> and <code>@id</code> are required at the root of every message. The meaning of these fields in DIDComm matches JSON-LD's expectations, but you don't need to learn JSON-LD to use them.</p> </li> <li> <p>JSON-LD's more advanced mechanisms are an option--not invoked ad hoc on a message-by-message basis, but specified in the formal description of a message family. You will know how much JSON-LD is relevant to a protocol when you implement it. In general, the community will want to discuss usage of new JSON-LD constructs before embracing them in protocols with broad interoperability intentions, because of the goal articulated above.</p> </li> <li> <p>The decorator concept in DIDComm is orthogonal to JSON-LD, and is far more likely to be relevant to your early learning. See the Decorator RFC.</p> </li> </ul> <p>That's it.</p>"},{"location":"aip2/0047-json-ld-compatibility/#details","title":"Details","text":"<p>Compatibility with JSON-LD was evaluated against version 1.1 of the JSON-LD spec, current in early 2019. If material changes in the spec are forthcoming, a new analysis may be worthwhile. Our current understanding follows.</p>"},{"location":"aip2/0047-json-ld-compatibility/#type","title":"<code>@type</code>","text":"<p>The type of a DIDComm message, and its associated route or handler in dispatching code, is given by the JSON-LD <code>@type</code> property at the root of a message. JSON-LD requires this value to be an IRI. DIDComm DID references are fully compliant. Instances of <code>@type</code> on any node other than a message root have JSON-LD meaning, but no predefined relevance in DIDComm.</p>"},{"location":"aip2/0047-json-ld-compatibility/#id","title":"<code>@id</code>","text":"<p>The identifier for a DIDComm message is given by the JSON-LD <code>@id</code> property at the root of a message. JSON-LD requires this value to be an IRI. DIDComm message IDs are relative IRIs, and can be converted to absolute form as described in RFC 0217: Linkable Message Paths. Instances of <code>@id</code> on any node other than a message root have JSON-LD meaning, but no predefined relevance in DIDComm.</p>"},{"location":"aip2/0047-json-ld-compatibility/#context","title":"<code>@context</code>","text":"<p>This is JSON-LD\u2019s namespacing mechanism. It is active in DIDComm messages, but can be ignored for simple processing, in the same way namespaces in XML are often ignored for simple tasks.</p> <p>Every DIDComm message has an associated <code>@context</code>, but we have chosen to follow the procedure described in section 6 of the JSON-LD spec, which focuses on how ordinary JSON can be intepreted as JSON-LD by communicating <code>@context</code> out of band.</p> <p>DIDComm messages communicate the context out of band by specifying it in the protocol definition (e.g., RFC) for the associated message type; thus, the value of <code>@type</code> indirectly gives the relevant <code>@context</code>. In advanced use cases, <code>@context</code> may appear in a DIDComm message, supplementing this behavior.</p>"},{"location":"aip2/0047-json-ld-compatibility/#ordering","title":"Ordering","text":"<p>JSON-LD specifies that the order of items in arrays is NOT significant, and notes (correctly) that this is the opposite of the standard assumption for plain JSON. This makes sense when viewed through the lens of JSON-LD\u2019s role as a transformation of RDF.</p> <p>Since we want to violate as few assumptions as possible for a developer with general knowledge of JSON, DIDComm messages reverse this default, making arrays an ordered construct, as if all DIDComm message <code>@context</code>s contained something like:</p> <p><pre><code>\"each field\": { \"@container\": \"@list\"}\n</code></pre> To contravene the default, use a JSON-LD construction like this in <code>@context</code>:</p> <pre><code>\"myfield\": { \"@container\": \"@set\"}\n</code></pre>"},{"location":"aip2/0047-json-ld-compatibility/#decorators","title":"Decorators","text":"<p>Decorators are JSON fragments that can be included in any DIDComm message. They enter the formally defined JSON-LD namespace via a JSON-LD fragment that is automatically imputed to every DIDComm message:</p> <pre><code>\"@context\": {\n  \"@vocab\": \"https://github.com/hyperledger/aries-rfcs/\"\n}\n</code></pre> <p>All decorators use the reserved prefix char <code>~</code> (tilde). For more on decorators, see the Decorator RFC.</p>"},{"location":"aip2/0047-json-ld-compatibility/#signing","title":"Signing","text":"<p>JSON-LD is associated but not strictly bound to a signing mechanism, LD-Signatures. It\u2019s a good mechanism, but it comes with some baggage: you must canonicalize, which means you must resolve every \u201cterm\u201d (key name) to its fully qualified form by expanding contexts before signing. This raises the bar for JSON-LD sophistication and library dependencies.</p> <p>The DIDComm community is not opposed to using LD Signatures for problems that need them, but has decided not to adopt the mechanism across the board. There is another signing mechanism that is far simpler, and adequate for many scenarios. We\u2019ll use whichever scheme is best suited to circumstances.</p>"},{"location":"aip2/0047-json-ld-compatibility/#type-coercion","title":"Type Coercion","text":"<p>DIDComm messages generally do not need this feature of JSON-LD, because there are well understood conventions around date-time datatypes, and individual RFCs that define each message type can further clarify such subtleties. However, it is available on a message-type-definition basis (not ad hoc).</p>"},{"location":"aip2/0047-json-ld-compatibility/#node-references","title":"Node References","text":"<p>JSON-LD lets one field reference another. See example 93 (note  that the ref could have just been \u201c#me\u201d instead of the fully qualified IRI).  We may need this construct at some point in DIDComm, but it is not in active  use yet.</p>"},{"location":"aip2/0047-json-ld-compatibility/#internationalization-and-localization","title":"Internationalization and Localization","text":"<p>JSON-LD describes a mechanism for this. It has approximately the same ../../features as the one described in Aries RFC 0043, with a few exceptions:</p> <ul> <li>The JSON-LD mechanism only applies to strings; it is explicitly disallowed for describing dates, numbers, or any strings that coerce to dates or numbers.</li> <li>The JSON-LD mechanism is language-centric rather than locale-centric. For example, it doesn't specify sort order, time-of-day, or currency semantics.</li> <li>There is no notion of a code that maps to strings--just a notion of strings that all have the same meaning. This means it doesn\u2019t help us solve the problem of locale-independent error codes.</li> <li>The notion of mappings of values for different locales is separable into an external catalog, but only if a value is referenced or included implicitly in a doc. In other words, a processor has to see the full message catalog when evaluating the doc.</li> <li>It\u2019s a bit awkward to retrofit onto an existing schema, because it requires a redefinition of the field that contains localized values, from being a single string to being a dictionary with language mappings. In other words, the schema before and after a developer adds localization support is not just different by new, optional fields; it is a breaking change. This contrasts with the indy PR approach, where the language mapping can be added after the fact, and gets associated by convention.</li> <li>It doesn\u2019t support localization of keys--only values. There are corner cases where key localization is desirable.</li> </ul> <p>Because of these misalignments, the DIDComm ecosystem plans to use its own solution to this problem.</p>"},{"location":"aip2/0047-json-ld-compatibility/#additional-json-ld-constructs","title":"Additional JSON-LD Constructs","text":"<p>The following JSON-LD keywords may be useful in DIDComm at some point in the future: <code>@base</code>, <code>@index</code>, <code>@container</code> (cf <code>@list</code> and <code>@set</code>), <code>@nest</code>, <code>@value</code>, <code>@graph</code>, <code>@prefix</code>, <code>@reverse</code>, <code>@version</code>.</p>"},{"location":"aip2/0047-json-ld-compatibility/#drawbacks","title":"Drawbacks","text":"<p>By attempting compatibility but only lightweight usage of JSON-LD, we are neither all-in on JSON-LD, nor all-out. This could cause confusion. We are making the bet that most developers won't need to know or care about the details; they'll simply learn that <code>@type</code> and <code>@id</code> are special, required fields on messages. Designers of protocols will need to know a bit more.</p>"},{"location":"aip2/0047-json-ld-compatibility/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>We could go all-in on JSON-LD. This would require adoption of sophisticated parsing that is impractical on embedded platforms, but it would add a lot of semantic sophistication.</li> <li>We could avoid JSON-LD entirely. This would force us to reinvent the wheel in some cases, and it would be frustrating to our friends in other SSI communities that are more JSON-LD-centric.</li> </ul>"},{"location":"aip2/0047-json-ld-compatibility/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the reversal of JSON-LD's default of unordered arrays valid?</li> <li>Is there a good way to discover that new DIDComm proposals should consider JSON-LD solutions, and make sure such questions get evaluated thoughtfully?</li> </ul>"},{"location":"aip2/0047-json-ld-compatibility/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0048-trust-ping/","title":"Aries RFC 0048: Trust Ping Protocol 1.0","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-02-01</li> <li>Status Note: Numerous implementations. </li> <li>Supersedes: Indy HIPE 0032</li> <li>Start Date: 2018-12-11</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"aip2/0048-trust-ping/#summary","title":"Summary","text":"<p>Describe a standard way for agents to test connectivity, responsiveness, and security of a pairwise channel.</p>"},{"location":"aip2/0048-trust-ping/#motivation","title":"Motivation","text":"<p>Agents are distributed. They are not guaranteed to be connected or running all the time. They support a variety of transports, speak a variety of protocols, and run software from many different vendors.</p> <p>This can make it very difficult to prove that two agents have a functional pairwise channel. Troubleshooting connectivity, responsivenes, and security is vital.</p>"},{"location":"aip2/0048-trust-ping/#tutorial","title":"Tutorial","text":"<p>This protocol is analogous to the familiar <code>ping</code> command in networking--but because it operates over agent-to-agent channels, it is transport agnostic and asynchronous, and it can produce insights into privacy and security that a regular ping cannot.</p>"},{"location":"aip2/0048-trust-ping/#roles","title":"Roles","text":"<p>There are two parties in a trust ping: the <code>sender</code> and the <code>receiver</code>. The sender initiates the trust ping. The receiver responds. If the receiver wants to do a ping of their own, they can, but this is a new interaction in which they become the sender.</p>"},{"location":"aip2/0048-trust-ping/#messages","title":"Messages","text":"<p>The trust ping interaction begins when <code>sender</code> creates a <code>ping</code> message like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/trust_ping/1.0/ping\",\n  \"@id\": \"518be002-de8e-456e-b3d5-8fe472477a86\",\n  \"~timing\": {\n    \"out_time\": \"2018-12-15 04:29:23Z\",\n    \"expires_time\": \"2018-12-15 05:29:23Z\",\n    \"delay_milli\": 0\n  },\n  \"comment\": \"Hi. Are you listening?\",\n  \"response_requested\": true\n}\n</code></pre> <p>Only <code>@type</code> and <code>@id</code> are required; <code>~timing.out_time</code>, <code>~timing.expires_time</code>,  and <code>~timing.delay_milli</code> are optional message timing decorators, and <code>comment</code> follows the conventions of localizable message fields. If present, it may be used to display a human-friendly description of the ping to a user that gives approval to respond. (Whether an agent responds to a trust ping is a decision for each agent owner to make, per policy and/or interaction with their agent.)</p> <p>The <code>response_requested</code> field deserves special mention. The normal expectation of a trust ping is that it elicits a response. However, it may be desirable to do a unilateral trust ping at times--communicate information without any expecation of a reaction. In this case, <code>\"response_requested\": false</code> may be used. This might be useful, for example, to defeat correlation between request and response (to generate noise). Or agents A and B might agree that periodically A will ping B without a response, as a way of evidencing that A is up and functional. If <code>response_requested</code> is false, then the receiver MUST NOT respond.</p> <p>When the message arrives at the receiver, assuming that <code>response_requested</code> is not <code>false</code>, the receiver should reply as quickly as possible with a <code>ping_response</code> message that looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/trust_ping/1.0/ping_response\",\n  \"@id\": \"e002518b-456e-b3d5-de8e-7a86fe472847\",\n  \"~thread\": { \"thid\": \"518be002-de8e-456e-b3d5-8fe472477a86\" },\n  \"~timing\": { \"in_time\": \"2018-12-15 04:29:28Z\", \"out_time\": \"2018-12-15 04:31:00Z\"},\n  \"comment\": \"Hi yourself. I'm here.\"\n}\n</code></pre> <p>Here, <code>@type</code> and <code>~thread</code> are required, and the rest is optional.</p>"},{"location":"aip2/0048-trust-ping/#trust","title":"Trust","text":"<p>This is the \"trust ping protocol\", not just the \"ping protocol.\" The \"trust\" in its name comes from several ../../features that the interaction gains by virtue of its use of standard agent-to-agent conventions:</p> <ol> <li> <p>Messages should be associated with a message trust context that allows sender and receiver to evaluate how much trust can be placed in the channel. For example, both sender and receiver can check whether messages are encrypted with suitable algorithms and keys.</p> </li> <li> <p>Messages may be targeted at any known agent in the other party's sovereign domain, using cross-domain routing conventions, and may be encrypted and packaged to expose exactly and only the information desired, at each hop along the way. This allows two parties to evaluate the completeness of a channel and the alignment of all agents that maintain it.</p> </li> <li> <p>This interaction may be traced using the general message tracing mechanism.</p> </li> </ol>"},{"location":"aip2/0048-trust-ping/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull  request to add your implementation. If the implementation is open source,  include a link to the repo or to the implementation within the repo. Please be  consistent in the \"Name\" field so that a mechanical processing of the RFCs can  generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community; MISSING test results Aries Framework - .NET .NET framework for building agents of all types; MISSING test results Streetcred.id Commercial mobile and web app built using Aries Framework - .NET; MISSING test results Aries Cloud Agent - Python Contributed by the government of British Columbia.; MISSING test results Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases.; MISSING test results Aries Protocol Test Suite MISSING test results"},{"location":"aip2/0050-wallets/","title":"Aries RFC 0050: Wallets","text":"<ul> <li>Authors: Daniel Hardman, Darko Kulic, Vyacheslav Gudkov, Mike Lodder</li> <li>Status: ACCEPTED</li> <li>Since: 2018-07-01</li> <li>Status Note: Fully implemented in Indy SDK, but not yet socialized well in the broader Aries community. Needs some updates to promote better key management; see related RFC about lox. </li> <li>Supersedes: Indy HIPE 0013</li> <li>Start Date: 2018-05-22</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0050-wallets/#summary","title":"Summary","text":"<p>Specify the external interfaces of identity wallets in the Indy ecosystem, as well as some background ../../concepts, theory, tradeoffs, and internal implementation guidelines.</p> <p></p>"},{"location":"aip2/0050-wallets/#motivation","title":"Motivation","text":"<p>Wallets are a familiar component metaphor that SSI has adopted from the world of cryptocurrencies. The translation isn't perfect, though; crypto wallets have only a subset of the ../../features that an identity wallet needs. This causes problems, as coders may approach wallets in Indy with assumptions that are more narrow than our actual design target.</p> <p>Since wallets are a major vector for hacking and cybersecurity issues, casual or fuzzy wallet requirements are a recipe for frustration or disaster. Divergent and substandard implementations could undermine security more broadly. This argues for as much design guidance and implementation help as possible.</p> <p>Wallets are also a unit of identity portability--if an identity owner doesn't like how her software is working, she should be able to exercise her self- sovereignty by taking the contents of her wallet to a new service. This implies that wallets need certain types of interoperability in the ecosystem, if they are to avoid vendor lock-in.</p> <p>All of these reasons--to clarify design scope, to provide uniform high security, and to guarantee interop--suggest that we need a formal RFC to document wallet architecture.</p>"},{"location":"aip2/0050-wallets/#tutorial","title":"Tutorial","text":"<p>(For a slide deck that gives a simplified overview of all the content in this RFC, please see http://bit.ly/2JUcIiT. The deck also includes a link to a recorded presentation, if you prefer something verbal and interactive.)</p>"},{"location":"aip2/0050-wallets/#what-is-an-identity-wallet","title":"What Is an Identity Wallet?","text":"<p>Informally, an identity wallet (preferably not just \"wallet\") is a digital container for data that's needed to control a self-sovereign identity. We borrow this metaphor from physical wallets:</p> <p></p> <p>Notice that we do not carry around in a physical wallet every document, key, card, photo, piece of currency, or credential that we possess. A wallet is a mechanism of convenient control, not an exhaustive repository. A wallet is portable. A wallet is worth safeguarding. Good wallets are organized so we can find things easily. A wallet has a physical location.</p> <p>What does suggest about identity wallets?</p>"},{"location":"aip2/0050-wallets/#types-of-sovereign-data","title":"Types of Sovereign Data","text":"<p>Before we give a definitive answer to that question, let's take a detour for a moment to consider digital data. Actors in a self-sovereign identity ecosystem may own or control many different types of data:</p> <ul> <li>encryption and signing keys</li> <li>payment keys</li> <li>link secrets</li> <li>PII about themselves or others</li> <li>credentials</li> <li>personal documents (e.g., last year's tax filing, journal, love letters)</li> <li>digital breadcrumbs (e.g., purchase history)</li> <li>photos and videos</li> <li>receipts</li> <li>health records</li> </ul> <p>...and much more. Different subsets of data may be worthy of different protection efforts:</p> <p></p> <p>The data can also show huge variety in its size and in its richness:</p> <p></p> <p>Because of the sensitivity difference, the size and richness difference, joint ownership, and different needs for access in different circumstances, we may store digital data in many different locations, with different backup regimes, different levels of security, and different cost profiles.</p>"},{"location":"aip2/0050-wallets/#whats-out-of-scope","title":"What's Out of Scope","text":""},{"location":"aip2/0050-wallets/#not-a-vault","title":"Not a Vault","text":"<p>This variety suggests that an identity wallet as a loose grab-bag of all our digital \"stuff\" will give us a poor design. We won't be able to make good tradeoffs that satisfy everybody; some will want rigorous, optimized search; others will want to minimize storage footprint; others will be concerned about maximizing security.</p> <p>We reserve the term vault to refer to the complex collection of all an identity owner's data:</p> <p></p> <p>Note that a vault can contain an identity wallet. A vault is an important construct, and we may want to formalize its interface. But that is not the subject of this spec.</p>"},{"location":"aip2/0050-wallets/#not-a-cryptocurrency-wallet","title":"Not A Cryptocurrency Wallet","text":"<p>The cryptocurrency community has popularized the term \"wallet\"--and because identity wallets share with crypto wallets both high-tech crypto and a need to store secrets, it is tempting to equate these two ../../concepts. However, an identity wallet can hold more than just cryptocurrency keys, just as a physical wallet can hold more than paper currency. Also, identity wallets may need to manage hundreds of millions of relationships (in the case of large organizations), whereas most crypto wallets manage a small number of keys:</p> <p></p>"},{"location":"aip2/0050-wallets/#not-a-gui","title":"Not a GUI","text":"<p>As used in this spec, an identity wallet is not a visible application, but rather a data store. Although user interfaces (superb ones!) can and should be layered on top of wallets, from indy's perspective the wallet itself consists of a container and its data; its friendly face is a separate construct. We may casually refer to an application as a \"wallet\", but what we really mean is that the application provides an interface to the underlying wallet.</p> <p>This is important because if a user changes which app manages his identity, he should be able to retain the wallet data itself. We are aiming for a better portability story than browsers offer (where if you change browsers, you may be able to export+import your bookmarks, but you have to rebuild all sessions and logins from scratch).</p>"},{"location":"aip2/0050-wallets/#personas","title":"Personas","text":"<p>Wallets have many stakeholders. However, three categories of wallet users are especially impactful on design decisions, so we define a persona for each.</p>"},{"location":"aip2/0050-wallets/#alice-individual-identity-owner","title":"Alice (individual identity owner)","text":"<p>Alice owns several devices, and she has an agent in the cloud. She has a thousand relationships--some with institutions, some with other people. She has a couple hundred credentials. She owns three different types of cryptocurrency. She doesn\u2019t issue or revoke credentials--she just uses them. She receives proofs from other entities (people and orgs). Her main tool for exercising a self-sovereign identity is an app on a mobile device.</p>"},{"location":"aip2/0050-wallets/#faber-intitutional-identity-owner","title":"Faber (intitutional identity owner)","text":"<p>Faber College has an on-prem data center as well as many resources and processes in public and private clouds. It has relationships with a million students, alumni, staff, former staff, applicants, business partners, suppliers, and so forth. Faber issues credentials and must manage their revocation. Faber may use crypto tokens to sell and buy credentials and proofs.</p>"},{"location":"aip2/0050-wallets/#the-org-book-trust-hub","title":"The Org Book (trust hub)","text":"<p>The Org Book holds credentials (business licenses, articles of incorporation, health permits, etc) issued by various government agencies, about millions of other business entities. It needs to index and search credentials quickly. Its data is public. It serves as a reference for many relying parties--thus its trust hub role.</p>"},{"location":"aip2/0050-wallets/#use-cases","title":"Use Cases","text":"<p>The specific uses cases for an identity wallet are too numerous to fully list, but we can summarize them as follows:</p> <p>As an identity owner (any of the personas above), I want to manage identity and its relationships in a way that guarantees security and privacy:</p> <ul> <li>Create an identity</li> <li>Setup protective policies</li> <li>Govern agents</li> <li>Connect and interact with others</li> <li>Recover and revoke</li> <li>Take an identity somewhere else</li> </ul>"},{"location":"aip2/0050-wallets/#managing-secrets","title":"Managing Secrets","text":"<p>Certain sensitive things require special handling. We would never expect to casually lay an ebola zaire sample on the counter in our bio lab; rather, it must never leave a special controlled isolation chamber.</p> <p></p> <p>Cybersecurity in wallets can be greatly enhanced if we take a similar tack with high-value secrets. We prefer to generate such secrets in their final resting place, possibly using a seed if we need determinism. We only use such secrets in their safe place, instead of passing them out to untrusted parties.</p> <p>TPMs, HSMs, and so forth follow these rules. Indy\u2019s current wallet interface does, too. You can\u2019t get private keys out.</p>"},{"location":"aip2/0050-wallets/#composition","title":"Composition","text":"<p>The foregoing discussions about cybersecurity, the desirability of design guidance and careful implementation, and wallet data that includes but is not limited to secrets motivates the following logical organization of identity wallets in Indy:</p> <p></p> <p>The world outside a wallet interfaces with the wallet through a public interface provided by indy-sdk, and implemented only once. This is the block labeled <code>encryption, query (wallet core)</code> in the diagram. The implementation in this layer guarantees proper encryption and secret-handling. It also provides some query ../../features. Records (items) to be stored in a wallet are referenced by a public handle if they are secrets. This public handle might be a public key in a key pair, for example. Records that are not secrets can be returned directly across the API boundary.</p> <p>Underneath, this common wallet code in libindy is supplemented with pluggable storage-- a technology that provides persistence and query ../../features. This pluggable storage could be a file system, an object store, an RDBMS, a NoSQL DB, a Graph DB, a key~value store, or almost anything similar. The pluggable storage is registered with the wallet layer by providing a series of C-callable functions (callbacks). The storage layer doesn't have to worry about encryption at all; by the time data reaches it, it is encrypted robustly, and the layer above the storage takes care of translating queries to and from encrypted form for external consumers of the wallet.</p>"},{"location":"aip2/0050-wallets/#tags-and-queries","title":"Tags and Queries","text":"<p>Searchability in wallets is facilitated with a tagging mechanism. Each item in a wallet can be associated with zero or more tags, where a tag is a <code>key=value</code> pair. Items can be searched based on the tags associated with them, and tag values can be strings or numbers. With a good inventory of tags in a wallet, searching can be robust and efficient--but there is no support for joins, subqueries, and other RDBMS-like constructs, as this would constrain the type of storage plugin that could be written.</p> <p>An example of the tags on a wallet item that is a credential might be:</p> <pre><code>  item-name = \"My Driver's License\"\n  date-issued = \"2018-05-23\"\n  issuer-did = \"ABC\"\n  schema = \"DEF\"\n</code></pre> <p>Tag names and tag values are both case-sensitive.</p> <p>Because tag values are normally encrypted, most tag values can only be tested using the <code>$eq</code>, <code>$neq</code> or <code>$in</code> operators (see Wallet Query Language, next). However, it is possible to force a tag to be stored in the wallet as plain text by naming it with a special prefix, <code>~</code> (tilde). This enables operators like <code>$gt</code>, <code>$lt</code>, and <code>$like</code>. Such tags lose their security guarantees but provide for richer queries; it is up to applications and their users to decide whether the tradeoff is appropriate.</p>"},{"location":"aip2/0050-wallets/#wallet-query-language","title":"Wallet Query Language","text":"<p>Wallets can be searched and filtered using a simple, JSON-based query language. We call this Wallet Query Language (WQL). WQL is designed to require no fancy parsing by storage plugins, and to be easy enough for developers to learn in just a few minutes. It is inspired by MongoDB's query syntax, and can be mapped to SQL, GraphQL, and other query languages supported by storage backends, with minimal effort.</p> <p>Formal definition of WQL language is the following:</p> <pre><code>query = {subquery}\nsubquery = {subquery, ..., subquery} // means subquery AND ... AND subquery\nsubquery = $or: [{subquery},..., {subquery}] // means subquery OR ... OR subquery\nsubquery = $not: {subquery} // means NOT (subquery)\nsubquery = \"tagName\": tagValue // means tagName == tagValue\nsubquery = \"tagName\": {$neq: tagValue} // means tagName != tagValue\nsubquery = \"tagName\": {$gt: tagValue} // means tagName &gt; tagValue\nsubquery = \"tagName\": {$gte: tagValue} // means tagName &gt;= tagValue\nsubquery = \"tagName\": {$lt: tagValue} // means tagName &lt; tagValue\nsubquery = \"tagName\": {$lte: tagValue} // means tagName &lt;= tagValue\nsubquery = \"tagName\": {$like: tagValue} // means tagName LIKE tagValue\nsubquery = \"tagName\": {$in: [tagValue, ..., tagValue]} // means tagName IN (tagValue, ..., tagValue)\n</code></pre>"},{"location":"aip2/0050-wallets/#sample-wql-query-1","title":"Sample WQL Query 1","text":"<p>Get all credentials where subject like \u2018Acme%\u2019 and issue_date &gt; last week. (Note here that the name of the issue date tag begins with a tilde, telling the wallet to store its value unencrypted, which makes the <code>$gt</code> operator possible.)</p> <pre><code>{\n  \"~subject\": {\"$like\": \"Acme%\"},\n  \"~issue_date\": {\"$gt\": 2018-06-01}\n}\n</code></pre>"},{"location":"aip2/0050-wallets/#sample-wql-query-2","title":"Sample WQL Query 2","text":"<p>Get all credentials about me where schema in (a, b, c) and issuer in (d, e, f).</p> <pre><code>{\n  \"schema_id\": {\"$in\": [\"a\", \"b\", \"c\"]},\n  \"issuer_id\": {\"$in\": [\"d\", \"e\", \"f\"]},\n  \"holder_role\": \"self\"\n}\n</code></pre>"},{"location":"aip2/0050-wallets/#encryption","title":"Encryption","text":"<p>Wallets need very robust encryption. However, they must also be searchable, and the encryption must be equally strong regardless of which storage technology is used. We want to be able to hide data patterns in the encrypted data, such that an attacker cannot see common prefixes on keys, or common fragments of data in encrypted values. And we want to rotate the key that protects a wallet without having to re-encrypt all its content. This suggests that a trivial encryption scheme, where we pick a symmetric key and encrypt everything with it, is not adequate.</p> <p>Instead, wallet encryption takes the following approach:</p> <ul> <li>For attributes of items that are searchable  (<code>type</code>, <code>id</code>, <code>tag_name</code>,   <code>tag_value</code>):</li> <li>The same input produces the same output.</li> <li>Every attribute \"column\" has its own key. That is, there's an encryption key for     all <code>type</code> attributes, a different encryption key for all <code>id</code> attributes,     and so forth.</li> <li>Initialization vector is HMAC-256 value of the field being encrypted.</li> <li> <p>Two more keys are needed for HMAC--one for <code>type</code> and <code>id</code> and one for     <code>tag_name</code> and <code>tag_value</code>.</p> </li> <li> <p>For item values:</p> </li> <li>A new value key is generated for each item value.</li> <li>Value key is encrypted using key for that field. (Value key also has a \"column\"     key that contributes to its encryption.)</li> <li> <p>Initialization vector is generated every time for both encryptions.</p> </li> <li> <p>For wallet keys:</p> </li> <li>Encrypted with master key with random initialization vector.</li> </ul> <p>The 7 \"column\" keys are concatenated and encrypted with a wallet master key,  then saved into the metadata of the wallet. This allows the master key to be rotated  without re-encrypting all the items in the wallet.</p> <p>Today, all encryption is done using ChaCha20-Poly1305, with HMAC-SHA256. This is a solid, secure encryption algorithm, well tested and widely supported. However, we anticipate the desire to use different cipher suites, so in the future we will make the cipher suite pluggable.</p> <p>The way the individual fields are encrypted is shown in the following diagram. Here, data is shown as if stored in a relational database with tables. Wallet storage may or may not use tables, but regardless of how the storage distributes and divides the data, the logical relationships and the encryption shown in the diagram apply.</p> <p></p>"},{"location":"aip2/0050-wallets/#pluggable-storage","title":"Pluggable Storage","text":"<p>Although Indy infrastructure will provide only one wallet implementation it will allow to plug different storages for covering of different use cases. Default storage shipped with libindy will be sqlite based and well suited for agents running on edge devices. The API endpoint <code>register_wallet_storage</code> will allow Indy Developers to register a custom storage implementation as a set of handlers.</p> <p>A storage implementation does not need any special security ../../features. It stores data that was already encrypted by libindy (or data that needs no encryption/protection, in the case of unencrypted tag values). It searches data in whatever form it is persisted, without any translation. It returns data as persisted, and lets the common wallet infrastructure in libindy decrypt it before return it to the user.</p>"},{"location":"aip2/0050-wallets/#secure-enclaves","title":"Secure Enclaves","text":"<p>Secure Enclaves are purposely designed to manage, generate, and securely store cryptographic material. Enclaves can be either specially designed hardware (e.g. HSM, TPM) or trusted execution environments (TEE) that isolate code and data from operating systems (e.g. Intel SGX, AMD SVE, ARM Trustzone). Enclaves can replace common cryptographic operations that wallets perform (e.g. encryption, signing). Some secrets cannot be stored in wallets like the key that encrypts the wallet itself or keys that are backed up. These cannot be stored in enclaves as keys stored in enclaves cannot be extracted. Enclaves can still protect these secrets via a mechanism called wrapping.</p>"},{"location":"aip2/0050-wallets/#enclave-wrapping","title":"Enclave Wrapping","text":"<p>Suppose I have a secret, X, that needs maximum protection. However, I can\u2019t store X in my secure enclave because I need to use it for operations that the enclave can\u2019t do for me; I need direct access. So how to I extend enclave protections to encompass my secret?</p> <p>I ask the secure enclave to generate a key, Y, that will be used to protect X. Y is called a wrapping key. I give X to the secure enclave and ask that it be encrypted with wrapping key Y. The enclave returns X\u2019 (ciphertext of X, now called a wrapped secret), which I can leave on disk with confidence; it cannot be decrypted to X without involving the secure enclave. Later, when I want to decrypt, I give wrapped secret X\u2019 to the secure enclave and ask it to give me back X by decrypting with wrapping key Y.</p> <p></p> <p>You could ask whether this really increases security. If you can get into the enclave, you can wrap or unwrap at will.</p> <p>The answer is that an unwrapped secret is protected by only one thing--whatever ACLs exist on the filesystem or storage where it resides. A wrapped secret is protected by two things--the ACLs and the enclave. OS access may breach either one, but pulling a hard drive out of a device will not breach the enclave.</p>"},{"location":"aip2/0050-wallets/#paper-wallets","title":"Paper Wallets","text":"<p>It is possible to persist wallet data to physical paper (or, for that matter, to etched metal or other physical media) instead of a digital container. Such data has attractive storage properties (e.g., may survive natural disasters, power outages, and other challenges that would destroy digital data). Of course, by leaving the digital realm, the data loses its accessibility over standard APIs.</p> <p>We anticipate that paper wallets will play a role in backup and recovery, and possibly in enabling SSI usage by populations that lack easy access to smartphones or the internet. Our wallet design should be friendly to such usage, but physical persistence of data is beyond the scope of Indy's plugin storage model and thus not explored further in this RFC.</p>"},{"location":"aip2/0050-wallets/#backup-and-recovery","title":"Backup and Recovery","text":"<p>Wallets need a backup and recovery feature, and also a way to export data and import it. Indy's wallet API includes an export function and an import function that may be helpful in such use cases. Today, the export is unfiltered--all data is exported. The import is also all-or-nothing and must be to an empty wallet; it is not possible to import selectively or to update existing records during import.</p> <p>A future version of import and export may add filtering, overwrite, and progress callbacks. It may also allow supporting or auxiliary data (other than what the wallet directly persists) to be associated with the export/import payload.</p> <p>For technical details on how export and import work, please see the internal design docs.</p>"},{"location":"aip2/0050-wallets/#reference","title":"Reference","text":"<ul> <li>Wallet Design</li> </ul>"},{"location":"aip2/0050-wallets/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>We could implement wallets purely as built already in the cryptocurrency world. This would give us great security (except for crypto wallets that are cloud based), and perhaps moderately good usability.</p> <p>However, it would also mean we could not store credentials in wallets. Indy would then need an alternate mechanism to scan some sort of container when trying to satisfy a proof request. And it would mean that a person's identity would not be portable via a single container; rather, if you wanted to take your identity to a new place, you'd have to copy all crypto keys in your crypto wallet, plus copy all your credentials using some other mechanism. It would also fragment the places where you could maintain an audit trail of your SSI activities.</p>"},{"location":"aip2/0050-wallets/#prior-art","title":"Prior art","text":"<p>See comment about crypto wallets, above.</p>"},{"location":"aip2/0050-wallets/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What is the relationship between a threading model in pluggable storage and   the threading model of wallets? Is it always legal to be reading and writing   wallets from multiple threads at the same time?</li> </ul>"},{"location":"aip2/0050-wallets/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy SDK Most agents that implement wallets get their wallet support from Indy SDK. These are not listed separately."},{"location":"aip2/0092-transport-return-route/","title":"Aries RFC 0092: Transports Return Route","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: ACCEPTED</li> <li>Since: 2019-12-06</li> <li>Status Note:  </li> <li>Supersedes: INDY HIPE PR 116</li> <li>Start Date: 2019-03-04</li> <li>Tags: feature</li> </ul>"},{"location":"aip2/0092-transport-return-route/#summary","title":"Summary","text":"<p>Agents can indicate that an inbound message transmission may also be used as a return route for messages. This allows for transports of increased efficiency as well as agents without an inbound route.</p>"},{"location":"aip2/0092-transport-return-route/#motivation","title":"Motivation","text":"<p>Inbound HTTP and Websockets are used only for receiving messages by default. Return messages are sent using their own outbound connections. Including a decorator allows the receiving agent to know that using the inbound connection as a return route is acceptable. This allows two way communication with agents that may not have an inbound route available. Agents without an inbound route include mobile agents, and agents that use a client (and not a server) for communication.</p> <p>This decorator is intended to facilitate message communication between a client based agent (an agent that can only operate as a client, not a server) and the server based agents they communicate directly with. Use on messages that will be forwarded is not allowed.</p>"},{"location":"aip2/0092-transport-return-route/#tutorial","title":"Tutorial","text":"<p>When you send a message through a connection, you can use the <code>~transport</code> decorator on the message and specify <code>return_route</code>. The value of <code>return_route</code> is discussed in the Reference section of this document.</p> <pre><code>{\n    \"~transport\": {\n        \"return_route\": \"all\"\n    }\n}\n</code></pre>"},{"location":"aip2/0092-transport-return-route/#reference","title":"Reference","text":"<ul> <li> <p><code>return_route</code> has the following acceptable values:</p> </li> <li> <p><code>none</code>: Default. No messages should be returned over this connection.</p> </li> <li><code>all</code>: Send all messages for this cryptographic key over the connection.</li> <li><code>thread</code>: Send all messages matching the cryptographic key and thread specified in the <code>return_route_thread</code> attribute.</li> </ul> <p>The <code>~transport</code> decorator should be processed after unpacking and prior to routing the message to a message handler.</p> <p>For HTTP transports, the presence of this message decorator indicates that the receiving agent MAY hold onto the connection and use it to return messages as designated. HTTP transports will only be able to receive at most one message at a time. Websocket transports are capable of receiving multiple messages.</p> <p>Compliance with this indicator is optional for agents generally, but required for agents wishing to connect with client based agents.</p>"},{"location":"aip2/0092-transport-return-route/#drawbacks","title":"Drawbacks","text":"<ul> <li>Application varies between transports, adding complexity to agent development.</li> </ul>"},{"location":"aip2/0092-transport-return-route/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Using a transport level decorator makes this behavior transport agnostic.</li> </ul>"},{"location":"aip2/0092-transport-return-route/#prior-art","title":"Prior art","text":"<p>The Decorators RFC describes scope of decorators. Transport isn't one of the scopes listed.</p>"},{"location":"aip2/0092-transport-return-route/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Protocol Test Suite Used in Tests"},{"location":"aip2/0094-cross-domain-messaging/","title":"Aries RFC 0094: Cross-Domain Messaging","text":"<ul> <li>Authors: Stephen Curran</li> <li>Status: ACCEPTED</li> <li>Since: 2018-10-29</li> <li>Status Note: Socialized and broadly understood in other conceptual RFCs about routing. </li> <li>Supersedes: 0022-Cross-Domain-Messaging</li> <li>Start Date: 2018-08-13</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0094-cross-domain-messaging/#summary","title":"Summary","text":"<p>There are two layers of messages that combine to enable interoperable self-sovereign identity DIDcomm (formerly called Agent-to-Agent) communication. At the highest level are Agent Messages - messages sent between Identities to accomplish some shared goal. For example, establishing a connection between identities, issuing a Verifiable Credential from an Issuer to a Holder or even the simple delivery of a text Instant Message from one person to another. Agent Messages are delivered via the second, lower layer of messaging - encryption envelopes. An encryption envelope is a wrapper (envelope) around an Agent Message to enable the secure delivery of a message from one Agent directly to another Agent. An Agent Message going from its Sender to its Receiver may be passed through a number of Agents, and an encryption envelope is used for each hop of the journey.</p> <p>This RFC addresses Cross Domain messaging to enable interoperability. This is one of a series of related RFCs that address interoperability, including DIDDoc Conventions, Agent Messages and Encryption Envelope. Those RFCs should be considered together in understanding DIDcomm messaging.</p> <p>In order to send a message from one Identity to another, the sending Identity must know something about the Receiver's domain - the Receiver's configuration of Agents. This RFC outlines how a domain MUST present itself to enable the Sender to know enough to be able to send a message to an Agent in the domain.  In support of that, a DIDcomm protocol (currently consisting of just one Message Type) is introduced to route messages through a network of Agents in both the Sender and Receiver's domain. This RFC provides the specification of the \"Forward\" Agent Message Type - an envelope that indicates the destination of a message without revealing anything about the message.</p> <p>The goal of this RFC is to define the rules that domains MUST follow to enable the delivery of Agent messages from a Sending Agent to a Receiver Agent in a secure and privacy-preserving manner.</p>"},{"location":"aip2/0094-cross-domain-messaging/#motivation","title":"Motivation","text":"<p>The purpose of this RFC and its related RFCs is to define a layered messaging protocol such that we can ignore the delivery of messages as we discuss the much richer Agent Messaging types and interactions. That is, we can assume that there is no need to include in an Agent message anything about how to route the message to the Receiver - it just magically happens. Alice (via her App Agent) sends a message to Bob, and (because of implementations based on this series of RFCs) we can ignore how the actual message got to Bob's App Agent.</p> <p>Put another way - these RFCs are about envelopes. They define a way to put a message - any message - into an envelope, put it into an outbound mailbox and have it magically appear in the Receiver's inbound mailbox in a secure and privacy-preserving manner. Once we have that, we can focus on letters and not how letters are sent.</p> <p>Most importantly for Agent to Agent interoperability, this RFC clearly defines the assumptions necessary to deliver a message from one domain to another - e.g. what exactly does Alice have to know about Bob's domain to send Bob a message?</p>"},{"location":"aip2/0094-cross-domain-messaging/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0094-cross-domain-messaging/#core-messaging-goals","title":"Core Messaging Goals","text":"<p>These are vital design goals for this RFC:</p> <ol> <li>Sender Encapsulation: We SHOULD minimize what the Receiver has to know about the domain (routing tree or agent infrastructure) of the Sender in order for them to communicate.</li> <li>Receiver Encapsulation: We SHOULD minimize what the Sender has to know about the domain (routing tree or agent infrastructure) of the Receiver in order for them to communicate.</li> <li>Independent Keys: Private signing keys SHOULD NOT be shared between agents; each agent SHOULD be separately identifiable for accounting and authorization/revocation purposes.</li> <li>Need To Know Information Sharing: Information made available to intermediary agents between the Sender and Receiver SHOULD be minimized to what is needed to perform the agent's role in the process.</li> </ol>"},{"location":"aip2/0094-cross-domain-messaging/#assumptions","title":"Assumptions","text":"<p>The following are assumptions upon which this RFC is predicated.</p>"},{"location":"aip2/0094-cross-domain-messaging/#terminology","title":"Terminology","text":"<p>The following terms are used in this RFC with the following meanings:</p> <ul> <li>Domain - a set of Agents collaborating on behalf of an Identity</li> <li>It's assumed that the Agents of a Domain were developed by a single vendor and so MAY have implementation-specific mechanisms for tracking extra information about one another.</li> <li>An example of two Domains is provided in the image below.</li> <li>Edge Agents - the Agents involved in sending (creating) and receiving (processing) an Agent Message</li> <li>Sender - the Agent sending an original Agent Message</li> <li>Receiver - the Agent intended to receive an Agent Message from the Sender</li> <li>Note: A message MAY pass through many Agents between the Sender and Receiver</li> <li>Domain Endpoint - a physical endpoint for messages into domains that MUST be assumed to be shared across many Identities</li> <li>Shared by many identities (e.g. https://endpoint.agentsRus.com)</li> <li>Agency - the handler for messages sent to the Domain Endpoint.</li> <li>Mediators - agents explicitly known to the sender as part of routing messages to a Receiver.</li> <li>DID - reference to the literal Decentralized ID text</li> <li>e.g. did:sov:1234abcd</li> <li>DID#keyname - reference to the DID appended with \"#\" and a specific key from the DIDDoc</li> <li>e.g. did:sov:1234abcd#1 references key \"1\" of the \"did:sov:1234abcd\" DIDDoc.</li> <li>Note: The #keyname is NOT the actual Public Key - it's a reference to an entry in the DIDDoc that contains the Public Key.</li> </ul>"},{"location":"aip2/0094-cross-domain-messaging/#diddoc","title":"DIDDoc","text":"<p>The term \"DIDDoc\" is used in this RFC as it is defined in the DID Specification:</p> <ul> <li>a collection of public keys and endpoints,</li> <li>controlled by an identity,</li> <li>associated with a DID, and</li> <li>used for a relationship.</li> </ul> <p>A DID can be resolved to get its corresponding DIDDoc by any Agent that needs access to the DIDDoc. This is true whether talking about a DID on a Public Ledger, or a pairwise DID (using the did:peer method) persisted only to the parties of the relationship. In the case of pairwise DIDs, it's the (implementation specific) domain's responsibility to ensure such resolution is available to all Agents requiring it within the domain.</p>"},{"location":"aip2/0094-cross-domain-messaging/#messages-are-private","title":"Messages are Private","text":"<p>Agent Messages sent from a Sender to a Receiver SHOULD be private. That is, the Sender SHOULD encrypt the message with a public key for the Receiver. Any agent in between the Sender and Receiver will know only to whom the message is intended (by DID and possibly keyname within the DID), not anything about the message.</p>"},{"location":"aip2/0094-cross-domain-messaging/#the-sender-knows-the-receiver","title":"The Sender Knows The Receiver","text":"<p>This RFC assumes that the Sender knows the Receiver's DID and, within the DIDDoc for that DID, the keyname to use for the Receiver's Agent. How the Sender knows the DID and keyname to send the message is not defined within this RFC - that is a higher level concern.</p> <p>The Receiver's DID MAY be a public or pairwise DID, and MAY be on a Public Ledger or only shared between the parties of the relationship.</p>"},{"location":"aip2/0094-cross-domain-messaging/#example-domain-and-diddoc","title":"Example: Domain and DIDDoc","text":"<p>The following is an example of an arbitrary pair of domains that will be helpful in defining the requirements in this RFC.</p> <p></p> <p>In the diagram above:</p> <ul> <li>Alice has</li> <li>1 Edge Agent - \"1\"</li> <li>1 Routing Agent - \"2\"</li> <li>1 Domain Endpoint - \"8\"</li> <li>Bob has</li> <li>3 Edge Agents - \"4\", \"5\" and \"6\"<ul> <li>\"6\" is an Edge Agent in the cloud, \"4\" and \"5\" are physical devices.</li> </ul> </li> <li>1 Routing Agent - \"3\"</li> <li>1 Domain Endpoint - \"9\"</li> </ul>"},{"location":"aip2/0094-cross-domain-messaging/#bobs-did-for-his-relationship-with-alice","title":"Bob's DID for his Relationship with Alice","text":"<p>Bob\u2019s domain has 3 devices he uses for processing messages - two phones (4 and 5) and a cloud-based agent (6). However, in Bob's relationship with Alice, he ONLY uses one phone (4) and the cloud-based agent (6). Thus the key for device 5 is left out of the DIDDoc (see below).</p> <p>Note that the keyname for the Routing Agent (3) is called \"routing\". This is an example of the kind of convention needed to allow the Sender's agents to know the keys for Agents with a designated role in the receiving domain - as defined in the <code>DIDDoc Conventions</code> RFC.</p> <pre><code>{\n  \"@context\": \"https://w3id.org/did/v1\",\n  \"id\": \"did:sov:1234abcd\",\n  \"publicKey\": [\n    {\"id\": \"routing\", \"type\": \"RsaVerificationKey2018\",  \"owner\": \"did:sov:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC X\u2026\"},\n    {\"id\": \"4\", \"type\": \"RsaVerificationKey2018\",  \"owner\": \"did:sov:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC 9\u2026\"},\n    {\"id\": \"6\", \"type\": \"RsaVerificationKey2018\",  \"owner\": \"did:sov:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC A\u2026\"}\n  ],\n  \"authentication\": [\n    {\"type\": \"RsaSignatureAuthentication2018\", \"publicKey\": \"did:sov:1234abcd#4\"}\n  ],\n  \"service\": [\n    {\n      \"id\": \"did:example:123456789abcdefghi;did-communication\",\n      \"type\": \"did-communication\",\n      \"priority\" : 0,\n      \"recipientKeys\" : [ \"did:example:1234abcd#4\" ],\n      \"routingKeys\" : [ \"did:example:1234abcd#3\" ],\n      \"serviceEndpoint\" : \"did:example:xd45fr567794lrzti67;did-communication\"\n    }\n  ]\n}\n</code></pre> <p>For the purposes of this discussion we are defining the message flow to be:</p> <p>1 \u2192 2 \u2192 8 \u2192 9 \u2192 3 \u2192 4</p> <p>However, that flow is arbitrary and only one hop is actually required:</p> <ul> <li>1 is the Sender in this case and so must send the first message.</li> <li>4 is the Receiver in this case and so must receive the message.</li> </ul>"},{"location":"aip2/0094-cross-domain-messaging/#encryption-envelopes","title":"Encryption Envelopes","text":"<p>An encryption envelope is used to transport any Agent Message from one Agent directly to another. In our example message flow above, there are five encryption envelopes sent, one for each hop in the flow. The separate Encryption Envelope RFC covers those details.</p>"},{"location":"aip2/0094-cross-domain-messaging/#agent-message-format","title":"Agent Message Format","text":"<p>An Agent Message defines the format of messages processed by Agents. Details about the general form of Agent Messages can be found in the Agent Messages RFC.</p> <p>This RFC specifies (below) the \"Forward\" message type, a part of the \"Routing\" family of Agent Messages.</p>"},{"location":"aip2/0094-cross-domain-messaging/#did-diddoc-and-routing","title":"DID, DIDDoc and Routing","text":"<p>A DID owned by the Receiver is resolvable by the Sender as a DIDDoc using either a Public Ledger or using pairwise DIDs based on the <code>did:peer</code> method. The related DIDcomm DIDDoc Conventions RFC defines the required contents of a DIDDoc created by the receiving entity. Notably, the DIDDoc given to the Sender by the Receiver specifies the required routing of the message through an optional set of mediators.</p>"},{"location":"aip2/0094-cross-domain-messaging/#cross-domain-interoperability","title":"Cross Domain Interoperability","text":"<p>A key goal for interoperability is that we want other domains to know just enough about the configuration of a domain to which they are delivering a message, but no more. The following walks through those minimum requirements.</p>"},{"location":"aip2/0094-cross-domain-messaging/#required-the-did-and-diddoc","title":"Required: The DID and DIDDoc","text":"<p>As noted above, the Sender of an Agent to Agent Message has the DID of the Receiver, and knows the key(s) from the DIDDoc to use for the Receiver's Agent(s).</p> <p>Example: Alice wants to send a message from her phone (1) to Bob's phone (4). She has Bob's B:did@A:B, the DID/DIDDoc Bob created and gave to Alice to use for their relationship. Alice created A:did@A:B and gave that to Bob, but we don't need to use that in this example. The content of the DIDDoc for B:did@A:B is presented above.</p>"},{"location":"aip2/0094-cross-domain-messaging/#required-end-to-end-encryption-of-the-agent-message","title":"Required: End-to-End encryption of the Agent Message","text":"<p>The Agent Message from the Sender SHOULD be hidden from all Agents other than the Receiver. Thus, it SHOULD be encrypted with the public key of the Receiver. Based on our assumptions, the Sender can get the public key of the Receiver agent because they know the DID#keyname string, can resolve the DID to the DIDDoc and find the public key associated with DID#keyname in the DIDDoc. In our example above, that is the key associated with \"did:sov:1234abcd#4\".</p> <p>Most Sender-to-Receiver messages will be sent between parties that have shared pairwise DIDs (using the <code>did:peer</code> method). When that is true, the Sender will (usually) AuthCrypt the message. If that is not the case, or for some other reason the Sender does not want to AuthCrypt the message, AnonCrypt will be used. In either case, the Indy-SDK <code>pack()</code> function handles the encryption.</p> <p>If there are mediators specified in the DID service endpoint for the Receiver agent, the Sender must wrap the message for the Receiver in a 'Forward' message for each mediator. It is assumed that the Receiver can determine the from <code>did</code> based on the <code>to</code> DID (or the sender's verkey) using their pairwise relationship.</p> <pre><code>{\n  \"@type\" : \"https://didcomm.org/routing/1.0/forward\",\n  \"@id\": \"54ad1a63-29bd-4a59-abed-1c5b1026e6fd\",\n  \"to\"   : \"did:sov:1234abcd#4\",\n  \"msg\"  : { json object from &lt;pack(AgentMessage,valueOf(did:sov:1234abcd#4), privKey(A.did@A:B#1))&gt; }\n}\n</code></pre> <p>Notes</p> <ul> <li>the <code>@type</code> value is in the precise URI format for the \"forward\" message type</li> <li>Indy-SDK's \"pack\" function is used to AuthCrypt the message using the Receiver's public key and the Sender's private key.</li> <li>If the Sender wishes to remain anonymous or knows the Receiver does not know the Sender's public key, AnonCrypt is used.</li> <li>More details about the Indy-SDK <code>pack()</code> function can be found in the Encryption Envelope RFC.</li> <li>The Indy-SDK's \"unpack()\" function MUST return the public key of the private key used to sign the message. See the note below for the background on this.</li> <li>Additional <code>forward</code> messages are created to wrap each forward for each mediator.</li> </ul> <p>The bullet above about the unpack() function returning the signer's public key deserves some additional attention. The Receiver of the message knows from the \"to\" field the DID to which the message was sent. From that, the Receiver is expected to be able to determine the DID of the Sender, and from that, access the Sender's DIDDoc. However, knowing the DIDDoc is not enough to know from whom the message was sent - which key was used to send the message, and hence, which Agent controls the Sending private key. This information MUST be made known to the Receiver (from unpack()) when AuthCrypt is used so that the Receiver knows which key was used to the send the message and can, for example, use that key in responding to the arriving Message.</p> <p>The Sender can now send the Forward Agent Message on its way via the first of the encryption envelope. In our example, the Sender sends the Agent Message to 2 (in the Sender's domain), who in turn sends it to 8. That of course, is arbitrary - the Sender's Domain could have any configuration of Agents for outbound messages. The Agent Message above is passed unchanged, with each Agent able to see the <code>@type</code>, <code>to</code> and <code>msg</code> fields as described above. This continues until the outer <code>forward</code> message gets to the Receiver's first mediator or the Receiver's agent (if there are no mediators). Each agent decrypts the received encrypted envelope and either forwards it (if a mediator) or processes it (if the Receiver Agent). Per the Encryption Envelope RFC, between Agents the Agent Message is pack()'d and unpack()'d as appropriate or required.</p> <p>The diagram below shows an example use of the <code>forward</code> messages to encrypt the message all the way to the Receiver with two mediators in between - a shared domain endpoint (aka https://agents-r-us.com) and a routing agent owned by the receiving entity.</p> <p></p>"},{"location":"aip2/0094-cross-domain-messaging/#required-cross-domain-encryption","title":"Required: Cross Domain Encryption","text":"<p>While within a domain the Agents MAY choose to use encryption or not when sending messages from Agent to Agent, encryption MUST be used when sending a message into the Receiver's domain. The endpoint agent unpack()'s the encryption envelope and processes the message - usually a <code>forward</code>. Note that within a domain, the agents may use arbitrary relays for messages, unknown to the sender. How the agents within the domain knows where to send the message is implementation specific - likely some sort of dynamic DID-to-Agent routing table. If the path to the receiving agent includes mediators, the message must go through those mediators in order (for example, through 3 in our example) as the message being forwarded has been encrypted for the mediators.</p>"},{"location":"aip2/0094-cross-domain-messaging/#required-mediators-process-forward-messages","title":"Required: Mediators Process Forward Messages","text":"<p>When a mediator (eventually) receives the message, it determines it is the target of the (current) outer forward Agent Message and so decrypts the message's <code>msg</code> value to reveal the inner \"Forward\" message.  Mediators use their (implementation specific) knowledge to map from the <code>to</code> field to deliver the message to the physical endpoint of the next agent to process the message on it's way to the Receiver.</p>"},{"location":"aip2/0094-cross-domain-messaging/#required-the-receiver-app-agent-decryptsprocesses-the-agent-message","title":"Required: The Receiver App Agent Decrypts/Processes the Agent Message","text":"<p>When the Receiver Agent receives the message, it determines it is the target of the forward message, decrypts the payload and processes the message.</p>"},{"location":"aip2/0094-cross-domain-messaging/#exposed-data","title":"Exposed Data","text":"<p>The following summarizes the information needed by the Sender's agents:</p> <ul> <li>The DID to use for the relationship, and its related DIDDoc</li> <li>A public key entry for the Receiver agent</li> <li>From the DIDDoc, a service entry for each Receiver agent that includes:</li> <li>a public DID or physical endpoint and public key for the endpoint agent.</li> <li>An optional order list of public keys (<code>RoutingKeys</code>) of mediators used by the Receiver in delivering the message.</li> </ul> <p>The DIDDoc will have a public key entry for each additional Agent message Receiver and each mediator.</p> <p>In many cases, the entry for the endpoint agent should be a public DID, as it will likely be operated by an agency (for example, https://agents-r-us.com) rather than by the Receiver entity (for example, a person). By making that a public DID in that case, the agency can rotate its public key(s) for receiving messages in a single operation, rather than having to notify each identity owner and in turn having them update the public key in every pairwise DID that uses that endpoint.</p>"},{"location":"aip2/0094-cross-domain-messaging/#data-not-exposed","title":"Data Not Exposed","text":"<p>Given the sequence specified above, the following data is NOT exposed to the Sender's agents:</p> <ul> <li>The relays within the Receiver's domain</li> <li>Receiver agents the identity chooses not to include in a given DIDDoc</li> <li>The physical endpoints of agents within the Receiver's domain (other than the Domain Endpoint)</li> <li>The physical endpoints and, as required, associated public keys, are shared as needed by the agents within the Receiver's domain.</li> </ul>"},{"location":"aip2/0094-cross-domain-messaging/#message-types","title":"Message Types","text":"<p>The following Message Types are defined in this RFC.</p>"},{"location":"aip2/0094-cross-domain-messaging/#corerouting10forward","title":"Core:Routing:1.0:Forward","text":"<p>The core message type \"forward\", version 1.0 of the \"routing\" family is defined in this RFC. An example of the message is the following:</p> <pre><code>{\n  \"@type\" : \"https://didcomm.org/routing/1.0/forward\",\n  \"@id\": \"54ad1a63-29bd-4a59-abed-1c5b1026e6fd\",\n  \"to\"   : \"did:sov:1234abcd#4\",\n  \"msg\"  : { json object from &lt;pack(AgentMessage,valueOf(did:sov:1234abcd#4), privKey(A.did@A:B#1))&gt; }\n}\n</code></pre> <p>The <code>to</code> field is required and takes one of two forms:</p> <ul> <li>A DID without a key reference (e.g. <code>did:sov:1234abcd</code>)</li> <li>A DID with a key reference (e.g. <code>did:sov:1234abcd#4</code>)</li> </ul> <p>The first form is used when sending forward messages across one or more agents that do not need to know the details of a domain. The Receiver of the message is the designated <code>Routing Agent</code> in the Receiver Domain, as it controls the key used to decrypt messages sent to the domain, but not to a specific Agent.</p> <p>The second form is used when the precise key (and hence, the Agent controlling that key) is used to encrypt the Agent Message placed in the <code>msg</code> field.</p> <p>The <code>msg</code> field calls the Indy-SDK <code>pack()</code> function to encrypt the Agent Message to be forwarded. The Sender calls the <code>pack()</code> with the suitable arguments to AnonCrypt or AuthCrypt the message. The <code>pack()</code> and <code>unpack()</code> functions are described in more detail in the Encryption Envelope RFC.</p>"},{"location":"aip2/0094-cross-domain-messaging/#reference","title":"Reference","text":"<p>See the other RFCs referenced in this document:</p> <ul> <li>DIDcomm</li> <li>Encryption Envelope</li> <li>Agent Messages</li> <li>DIDDoc Conventions</li> </ul>"},{"location":"aip2/0094-cross-domain-messaging/#drawbacks","title":"Drawbacks","text":"<p>N/A</p>"},{"location":"aip2/0094-cross-domain-messaging/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>A number of discussions were held about this RFC. In those discussions, the rationale for the RFC evolved into the text, and the alternatives were eliminated. See prior versions of the superseded HIPE (in status section, above) for details.</p> <p>A suggestion was made that the following optional parameters could be defined in the \"routing/1.0/forward\" message type:</p> <ul> <li>forward-after: specify that the message should not be forwarded until the system clock shows a particular time, or until a particular interval has elapsed. This could be useful to defeat timing correlations. Particular agents might not support it.</li> <li>mix-config: artificially introduce extra hops to obscure path (use a mix network like TOR)</li> </ul> <p>The optional parameters have been left off for now, but could be added in this RFC or to a later version of the message type.</p>"},{"location":"aip2/0094-cross-domain-messaging/#prior-art","title":"Prior art","text":"<p>N/A</p>"},{"location":"aip2/0094-cross-domain-messaging/#unresolved-questions","title":"Unresolved questions","text":"<p>N/A</p>"},{"location":"aip2/0094-cross-domain-messaging/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0095-basic-message/","title":"Aries RFC 0095: Basic Message Protocol 1.0","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: ADOPTED</li> <li>Since: 2019-08-06</li> <li>Status Note:  </li> <li>Supersedes: Indy 0033</li> <li>Start Date: 2019-01-16</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"aip2/0095-basic-message/#summary","title":"Summary","text":"<p>The BasicMessage protocol describes a stateless, easy to support user message protocol. It has a single message type used to communicate.</p>"},{"location":"aip2/0095-basic-message/#motivation","title":"Motivation","text":"<p>It is a useful feature to be able to communicate human written messages. BasicMessage is the most basic form of this written message communication, explicitly excluding advanced ../../features to make implementation easier.</p>"},{"location":"aip2/0095-basic-message/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0095-basic-message/#roles","title":"Roles","text":"<p>There are two roles in this protocol: sender and receiver. It is anticipated that both roles are supported by agents that provide an interface for humans, but it is possible for an agent to only act as a sender (do not process received messages) or a receiver (will never send messages).</p>"},{"location":"aip2/0095-basic-message/#states","title":"States","text":"<p>There are not really states in this protocol, as sending a message leaves both parties in the same state they were before.</p>"},{"location":"aip2/0095-basic-message/#out-of-scope","title":"Out of Scope","text":"<p>There are many useful ../../features of user messaging systems that we will not be adding to this protocol. We anticipate the development of more advanced and full-featured message protocols to fill these needs. Features that are considered out of scope for this protocol include:</p> <ul> <li>read receipts</li> <li>emojii responses</li> <li>typing indicators</li> <li>message replies (threading)</li> <li>multi-party (group) messages</li> <li>attachments</li> </ul>"},{"location":"aip2/0095-basic-message/#reference","title":"Reference","text":"<p>Protocol: https://didcomm.org/basicmessage/1.0/</p> <p>message</p> <ul> <li>sent_time - timestamp in ISO 8601 UTC</li> <li>content - content of the user intended message as a string.</li> <li>The <code>~l10n</code> block SHOULD be used, but only the <code>locale</code> presented.</li> </ul> <p>Example:</p> <pre><code>{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/basicmessage/1.0/message\",\n    \"~l10n\": { \"locale\": \"en\" },\n    \"sent_time\": \"2019-01-15 18:42:01Z\",\n    \"content\": \"Your hovercraft is full of eels.\"\n}\n</code></pre>"},{"location":"aip2/0095-basic-message/#drawbacks","title":"Drawbacks","text":"<ul> <li>Creating this basicmessage may inhibit the creation of more advanced user messaging protocols.</li> <li>After more advanced user messaging protocols are created, the need to support this protocol may be annoying.</li> </ul>"},{"location":"aip2/0095-basic-message/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Basic user messaging creates an easy useful feature in the early days of agent messaging.</li> <li>Even in the presence of better protocols, it can still be useful for basic devices or service messaging.</li> </ul>"},{"location":"aip2/0095-basic-message/#prior-art","title":"Prior art","text":"<p>BasicMessage has parallels to SMS, which led to the later creation of MMS and even the still-under-development RCS.</p>"},{"location":"aip2/0095-basic-message/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Receive receipts (NOT read receipts) may be implicitly supported by an ack decorator with pre-processing support.</li> </ul>"},{"location":"aip2/0095-basic-message/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community; MISSING test results Aries Framework - .NET .NET framework for building agents of all types; MISSING test results Streetcred.id Commercial mobile and web app built using Aries Framework - .NET; MISSING test results Aries Cloud Agent - Python Contributed by the government of British Columbia.; MISSING test results Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases.; MISSING test results Aries Protocol Test Suite ; MISSING test results"},{"location":"aip2/0183-revocation-notification/","title":"Aries RFC 0183: Revocation Notification 1.0","text":"<ul> <li>Authors: [Keith Smith]</li> <li>Status: PROPOSED</li> <li>Since: 2019-08-12</li> <li>Status Note: Initial proposal after discussion on rocketchat</li> <li>Supersedes:</li> <li>Start Date: 2018-08-12</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"aip2/0183-revocation-notification/#summary","title":"Summary","text":"<p>This RFC defines the message format which an issuer uses to notify a holder that a previously issued credential has been revoked.</p>"},{"location":"aip2/0183-revocation-notification/#motivation","title":"Motivation","text":"<p>We need a standard protocol for an issuer to notify a holder that a previously issued credential has been revoked.</p> <p>For example, suppose a passport agency revokes Alice's passport. The passport agency (an issuer) may want to notify Alice (a holder) that her passport has been revoked so that she knows that she will be unable to use her passport to travel.</p>"},{"location":"aip2/0183-revocation-notification/#tutorial","title":"Tutorial","text":"<p>The Revocation Notification protocol is a very simple protocol consisting of a single message:</p> <ul> <li>Revoke - issuer to holder</li> </ul> <p>This simple protocol allows an issuer to choose to notify a holder that a previously issued credential has been revoked.</p> <p>It is the issuer's prerogative whether or not to notify the holder that a credential has been revoked.  It is not a security risk if the issuer does not notify the holder that the credential has been revoked, nor if the message is lost.  The holder will still be unable to use a revoked credential without this notification.</p>"},{"location":"aip2/0183-revocation-notification/#roles","title":"Roles","text":"<p>There are two parties involved in a Revocation Notification: <code>issuer</code> and <code>holder</code>. The <code>issuer</code> sends the <code>revoke</code> message to the <code>holder</code>.</p>"},{"location":"aip2/0183-revocation-notification/#messages","title":"Messages","text":"<p>The <code>revoke</code> message sent by the <code>issuer</code> to the <code>holder</code> is as follows:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/revocation_notification/1.0/revoke\",\n  \"@id\": \"&lt;uuid-revocation-notification&gt;\",\n  \"~please_ack\": [\"RECEIPT\",\"OUTCOME\"],\n  \"thread_id\": \"&lt;thread_id&gt;\",\n  \"comment\": \"Some comment\"\n}\n</code></pre> <p>Description of fields:</p> <ul> <li> <p><code>~please_ack</code> (optional) -- as described by the Please ACK Decorator RFC.  If <code>OUTCOME</code> is specified, the <code>holder</code> should send an ack when the holder's agent has successfully notified the holder of the revocation.</p> </li> <li> <p><code>thread_id</code> (required) -- the thread ID of the issue-credential-v2 protocol which was used to issue one or more credentials that have been revoked by the issuer.  If multiple credentials were issued, each credential has a different credential format but contains the same claims as described here; therefore, this message notifies the holder that all of these credentials have been revoked.</p> </li> <li> <p><code>comment</code> (optional) -- a field that provides some human readable information about the revocation notification.  This is typically the reason for the revocation as deemed appropriate by the issuer.</p> </li> </ul>"},{"location":"aip2/0183-revocation-notification/#reference","title":"Reference","text":"<ul> <li>See the issue-credential-v2 protocol.</li> <li>See the thread ID description.</li> <li>See the Please ACK Decorator RFC.</li> </ul>"},{"location":"aip2/0183-revocation-notification/#drawbacks","title":"Drawbacks","text":"<p>If we later added support for more general event subscription and notification message flows, this would be redundant.</p>"},{"location":"aip2/0183-revocation-notification/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?  It is simple.</li> <li>What other designs have been considered and what is the rationale for not choosing them?  A more general event subscription and notification mechanism was considered but chose to keep this simple for the same reasons that the basic message was kept simple.</li> <li>What is the impact of not doing this?  There is no standard way of sending a revocation notification which is a common scenario.</li> </ul>"},{"location":"aip2/0183-revocation-notification/#prior-art","title":"Prior art","text":""},{"location":"aip2/0183-revocation-notification/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"aip2/0183-revocation-notification/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0211-route-coordination/","title":"0211: Mediator Coordination Protocol","text":"<ul> <li>Authors: Sam Curren, Daniel Bluhm, Adam Burdett</li> <li>Status: ACCEPTED</li> <li>Since: 2021-03-15</li> <li>Status Note: Discussed and implemented and part of AIP 2.0.</li> <li>Start Date: 2019-09-03</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"aip2/0211-route-coordination/#summary","title":"Summary","text":"<p>A protocol to coordinate mediation configuration between a mediating agent and the recipient.</p>"},{"location":"aip2/0211-route-coordination/#application-scope","title":"Application Scope","text":"<p>This protocol is needed when using an edge agent and a mediator agent from different vendors. Edge agents and mediator agents from the same vendor may use whatever protocol they wish without sacrificing interoperability.</p>"},{"location":"aip2/0211-route-coordination/#motivation","title":"Motivation","text":"<p>Use of the forward message in the Routing Protocol requires an exchange of information. The Recipient must know which endpoint and routing key(s) to share, and the Mediator needs to know which keys should be routed via this relationship.</p>"},{"location":"aip2/0211-route-coordination/#protocol","title":"Protocol","text":"<p>Name: coordinate-mediation</p> <p>Version: 1.0</p> <p>Base URI: <code>https://didcomm.org/coordinate-mediation/1.0/</code></p>"},{"location":"aip2/0211-route-coordination/#roles","title":"Roles","text":"<p>mediator - The agent that will be receiving <code>forward</code> messages on behalf of the recipient. recipient - The agent for whom the <code>forward</code> message payload is intended.</p>"},{"location":"aip2/0211-route-coordination/#flow","title":"Flow","text":"<p>A recipient may discover an agent capable of routing using the Feature Discovery Protocol. If protocol is supported with the mediator role, a recipient may send a <code>mediate-request</code> to initiate a routing relationship.</p> <p>First, the recipient sends a <code>mediate-request</code> message to the mediator. If the mediator is willing to route messages, it will respond with a <code>mediate-grant</code> message. The recipient will share the routing information in the grant message with other contacts.</p> <p>When a new key is used by the recipient, it must be registered with the mediator to enable route identification. This is done with a <code>keylist-update</code> message.</p> <p>The <code>keylist-update</code> and <code>keylist-query</code> methods are used over time to identify and remove keys that are no longer in use by the recipient.</p>"},{"location":"aip2/0211-route-coordination/#reference","title":"Reference","text":"<p>Note on terms: Early versions of this protocol included the concept of terms for mediation.  This concept has been removed from this version due to a need for further discussion on representing terms in DIDComm in general and lack of use of these terms in current implementations.</p>"},{"location":"aip2/0211-route-coordination/#mediation-request","title":"Mediation Request","text":"<p>This message serves as a request from the recipient to the mediator, asking for the permission (and routing information) to publish the endpoint as a mediator.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/mediate-request\",\n}\n</code></pre>"},{"location":"aip2/0211-route-coordination/#mediation-deny","title":"Mediation Deny","text":"<p>This message serves as notification of the mediator denying the recipient's request for mediation.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/mediate-deny\",\n}\n</code></pre>"},{"location":"aip2/0211-route-coordination/#mediation-grant","title":"Mediation Grant","text":"<p>A route grant message is a signal from the mediator to the recipient that permission is given to distribute the included information as an inbound route.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/mediate-grant\",\n    \"endpoint\": \"http://mediators-r-us.com\",\n    \"routing_keys\": [\"did:key:z6Mkfriq1MqLBoPWecGoDLjguo1sB9brj6wT3qZ5BxkKpuP6\"]\n}\n</code></pre> <p><code>endpoint</code>: The endpoint reported to mediation client connections.</p> <p><code>routing_keys</code>: List of keys in intended routing order. Key used as recipient of forward messages.</p>"},{"location":"aip2/0211-route-coordination/#keylist-update","title":"Keylist Update","text":"<p>Used to notify the mediator of keys in use by the recipient.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/keylist-update\",\n    \"updates\":[\n        {\n            \"recipient_key\": \"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\",\n            \"action\": \"add\"\n        }\n    ]\n}\n</code></pre> <p><code>recipient_key</code>: Key subject of the update.</p> <p><code>action</code>: One of <code>add</code> or <code>remove</code>.</p>"},{"location":"aip2/0211-route-coordination/#keylist-update-response","title":"Keylist Update Response","text":"<p>Confirmation of requested keylist updates.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/keylist-update-response\",\n    \"updated\": [\n        {\n            \"recipient_key\": \"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\",\n            \"action\": \"\" // \"add\" or \"remove\"\n            \"result\": \"\" // [client_error | server_error | no_change | success]\n        }\n    ]\n}\n</code></pre> <p><code>recipient_key</code>: Key subject of the update.</p> <p><code>action</code>: One of <code>add</code> or <code>remove</code>.</p> <p><code>result</code>: One of <code>client_error</code>, <code>server_error</code>, <code>no_change</code>, <code>success</code>; describes the resulting state of the keylist update.</p>"},{"location":"aip2/0211-route-coordination/#key-list-query","title":"Key List Query","text":"<p>Query mediator for a list of keys registered for this connection.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/keylist-query\",\n    \"paginate\": {\n        \"limit\": 30,\n        \"offset\": 0\n    }\n}\n</code></pre> <p><code>paginate</code> is optional.</p>"},{"location":"aip2/0211-route-coordination/#key-list","title":"Key List","text":"<p>Response to key list query, containing retrieved keys.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/keylist\",\n    \"keys\": [\n        {\n            \"recipient_key\": \"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"\n        }\n    ],\n    \"pagination\": {\n        \"count\": 30,\n        \"offset\": 30,\n        \"remaining\": 100\n    }\n}\n</code></pre> <p><code>pagination</code> is optional.</p>"},{"location":"aip2/0211-route-coordination/#encoding-of-keys","title":"Encoding of keys","text":"<p>All keys are encoded using the <code>did:key</code> method as per RFC0360.</p>"},{"location":"aip2/0211-route-coordination/#prior-art","title":"Prior art","text":"<p>There was an Indy HIPE that never made it past the PR process that described a similar approach. That HIPE led to a partial implementation of this inside the Aries Cloud Agent Python</p>"},{"location":"aip2/0211-route-coordination/#future-considerations","title":"Future Considerations","text":"<ul> <li>Should we allow listing keys by date? You could query keys in use by date?</li> <li>We are missing a way to check a single key (or a few keys) without doing a full list.</li> <li>Mediation grant supports only one endpoint. What can be done to support multiple endpoint options i.e. http, ws, etc.</li> <li>Requiring proof of key ownership (with a signature) would prevent an edge case where a malicious party registers a key for another party at the same mediator, and before the other party.</li> <li>How do we express terms and conditions for mediation?</li> </ul>"},{"location":"aip2/0211-route-coordination/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>None</li> </ul>"},{"location":"aip2/0211-route-coordination/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python Added in ACA-Py 0.6.0 MISSING test results**** DIDComm mediator Open source cloud-based mediator."},{"location":"aip2/0360-use-did-key/","title":"Aries RFC 0360: did:key Usage","text":"<ul> <li>Authors: Tobias Looker, Stephen Curran</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Referenced in a number of Aries RFCs and formalized as part of AIP 2.0 did:key method is a W3C CCG work item</li> <li>Start Date: 2019-12-17</li> <li>Tags: feature</li> </ul>"},{"location":"aip2/0360-use-did-key/#summary","title":"Summary","text":"<p>A number of RFCs that have been defined reference what amounts to a \"naked\" public key, such that the sender relies on the receiver knowing what type the key is and how it can be used. The application of this RFC will result in the replacement of \"naked\" verkeys (public keys) in some DIDComm/Aries protocols with the did:key ledgerless DID method, a format that concisely conveys useful information about the use of the key, including the public key type. While <code>did:key</code> is less a DID method than a transformation from a public key and type to an opinionated DIDDoc, it provides a versioning mechanism for supporting new/different cryptographic formats and its use makes clear how a public key is intended to be used. The method also enables support for using standard DID resolution mechanisms that may simplify the use of the key. The use of a DID to represent a public key is seen as odd by some in the community. Should a representation be found that is has better properties than a plain public key but is constrained to being \"just a key\", then we will consider changing from the <code>did:key</code> representation.</p> <p>To Do: Update link DID Key Method link (above) from Digital Bazaar to W3C repositories when they are created and populated.</p> <p>While it is well known in the Aries community that <code>did:key</code> is fundamentally different from the did:peer method that is the basis of Aries protocols, it must be re-emphasized here. This RFC does NOT imply any changes to the use of <code>did:peer</code> in Aries, nor does it change the content of a <code>did:peer</code> DIDDoc. This RFC only changes references to plain public keys in the JSON of some RFCs to use <code>did:key</code> in place of a plain text string.</p> <p>Should this RFC be ACCEPTED, a community coordinated update will be used to apply updates to the agent code bases and impacted RFCs.</p>"},{"location":"aip2/0360-use-did-key/#motivation","title":"Motivation","text":"<p>When one Aries agent inserts a public key into the JSON of an Aries message (for example, the <code>~service</code> decorator), it assumes that the recipient agent will use the key in the intended way. At the time this RFC is being written, this is easy because only one key type is in use by all agents. However, in order to enable the use of different cryptography algorithms, the public references must be extended to at least include the key type. The preferred and concise way to do that is the use of the multicodec mechanism, which provides a registry of encodings for known key types that are prefixed to the public key in a standard and concise way. did:key extends that mechanism by providing a templated way to transform the combination of public key and key type into a DID-standard DIDDoc.</p> <p>At the cost of adding/building a did:key resolver we get a DID standard way to access the key and key type, including specific information on how the key can be used. The resolver may be trivial or complex. In a trivial version, the key type is assumed, and the key can be easily extracted from the string. In a more complete implementation, the key type can be checked, and standard DID URL handling can be used to extract parts of the DIDDoc for specific purposes. For example, in the ed25519 <code>did:key</code> DIDDoc, the existence of the <code>keyAgreement</code> entry implies that the key can be used in a Diffie-Hellman exchange, without the developer guessing, or using the key incorrectly.</p> <p>Note that simply knowing the key type is not necessarily sufficient to be able to use the key. The cryptography supporting the processing data using the key must also be available in the agent. However, the multicodec and did:key capabilities will simplify adding support for new key types in the future.</p>"},{"location":"aip2/0360-use-did-key/#tutorial","title":"Tutorial","text":"<p>An example of the use of the replacement of a verkey with <code>did:key</code> can be found in the ~service decorator RFC. Notably in the example at the beginning of the tutorial section, the verkeys in the <code>recipientKeys</code> and <code>routingKeys</code> items would be changed from native keys to use <code>did:key</code> as follows:</p> <pre><code>{\n    \"@type\": \"somemessagetype\",\n    \"~service\": {\n        \"recipientKeys\": [\"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"],\n        \"routingKeys\": [\"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"]\n        \"serviceEndpoint\": \"https://example.com/endpoint\"\n    }\n}\n</code></pre> <p>Thus, <code>8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K</code> becomes <code>did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th</code> using the following transformations:</p> <ul> <li>Start with the original (presumably) base58 ed25519 public key</li> <li>Since we have only a naked public key, we must assume the format</li> <li>Base58 decode the public key to get the hex version</li> <li>Multicodec: Prefix with the unsigned varint of the algorithm type. In this case, that means prefixing the string with <code>unsigned_varint(0xed)</code> (which is <code>0xed 0x01</code>) for the key type of ed25519,</li> <li>the <code>0xed</code> is per the multicodec table (search for  <code>ed25519</code>).</li> <li>Note that unsigned varint handling varies by key type prefix, so don't just assume the same handling (e.g. <code>code+0x01</code>) for other key type prefixes. For a broader discussion of this see this issue comment in the <code>did:key</code> repo.</li> <li>Multibase: Base58 encode the result and prefix that with \"z\" to indicate base58 encoding</li> <li>DID: Prefix that with the DID Method prefix <code>did:key:</code></li> </ul> <p>The transformation above is only for illustration within this RFC. The <code>did:key</code> specification is the definitive source for the appropriate transformations.</p> <p>The <code>did:key</code> method uses the strings that are the DID, public key and key type to construct (\"resolve\") a DIDDoc based on a template defined by the <code>did:key</code> specification. Further, the <code>did:key</code> resolver generates, in the case of an ed25519 public signing key, a key that can be used as part of a Diffie-Hellman exchange appropriate for encryption in the <code>keyAgreement</code> section of the DIDDoc. Presumably, as the <code>did:key</code> method supports other key types, similar DIDDoc templates will become part of the specification. Key types that don't support a signing/key exchange transformation would not have a <code>keyAgreement</code> entry in the resolved DIDDoc.</p> <p>The following currently implemented RFCs would be affected by acceptance of this RFC. In these RFCs, the JSON items that currently contain naked public keys (mostly the items <code>recipientKeys</code> and <code>routingKeys</code>) would be changed to use <code>did:key</code> references where applicable. Note that in these items public DIDs could also be used if applicable for a given use case.</p> <ul> <li>0023-did-exchange - Invitation Message</li> <li>0028-introduce</li> <li>0056-service-decorator</li> <li>0160-connection-protocol</li> <li>0434-out-of-band-protocols</li> <li>0211-mediator-coordination-protocol</li> </ul> <p>Service entries in <code>did:peer</code> DIDDocs (such as in RFCs 0094-cross-domain-messaging and 0067-didcomm-diddoc-conventions) should NOT use a <code>did:key</code> public key representation. Instead, service entries in the DIDDoc should reference keys defined internally in the DIDDoc where appropriate.</p> <p>To Do: Discuss the use of <code>did:key</code> (or not) in the context of encryption envelopes. This will be part of the ongoing discussion about JWEs and the upcoming discussions about JWMs\u2014a soon-to-be-proposed specification. That conversation will likely go on in the DIF DIDComm Working Group.</p>"},{"location":"aip2/0360-use-did-key/#reference","title":"Reference","text":"<p>See the <code>did:key</code> specification. Note that the specification is still evolving.</p>"},{"location":"aip2/0360-use-did-key/#drawbacks","title":"Drawbacks","text":"<p>The <code>did:key</code> standard is not finalized.</p> <p>The DIDDoc \"resolved\" from a <code>did:key</code> probably has more entries in it than are needed for DIDComm. That said, the entries in the DIDDoc make it clear to a developer how they can use the public key.</p>"},{"location":"aip2/0360-use-did-key/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>We should not stick with the status quo and assume that all agents will always know the type of keys being used and how to use them.</p> <p>We should at minimum move to a scheme like multicodecs such that the key is self documenting and supports the versioning of cryptographic algorithms. However, even if we do that, we still have to document for developers how they should (and not should not) use the public key.</p> <p>Another logical alternative is to use a JWK. However, that representation only adds the type of the key (same as multicodecs) at the cost of being significantly more verbose.</p>"},{"location":"aip2/0360-use-did-key/#prior-art","title":"Prior art","text":"<p>To do - there are other instances of this pattern being used. Insert those here.</p>"},{"location":"aip2/0360-use-did-key/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>How to transition to the use of <code>did:key</code>.</li> <li>What will the initial accepted version of <code>did:key</code> look like?  It's probably close to its final form, with an expected resolution of the open question of what  a DIDDoc looks like if the key type is not ed25519.</li> </ul>"},{"location":"aip2/0360-use-did-key/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes</p> Name / Link Implementation Notes"},{"location":"aip2/0434-outofband/","title":"Aries RFC 0434: Out-of-Band Protocol 1.1","text":"<ul> <li>Authors: Ryan West, Daniel Bluhm, Matthew Hailstone, Stephen Curran, Sam Curren, George Aristy</li> <li>Status: ADOPTED</li> <li>Since: 2020-03-01</li> <li>Status Note: This RFC extracts the <code>invitation</code> messages from the DID Exchange protocol (and perhaps Connection), and replaces the combined <code>present_proof/1.0/request</code> combined with the <code>~service</code> decorator to define an ephemeral (connection-less) challenge.</li> <li>Supersedes: Invitation Message in 0160-Connections and Invitation Message in 0023-DID-Exchange.</li> <li>Start Date: 2020-03-01</li> <li>Tags: feature, protocol, test-anomaly</li> <li>URI: <code>https://didcomm.org/out-of-band/%VER</code></li> </ul>"},{"location":"aip2/0434-outofband/#summary","title":"Summary","text":"<p>The Out-of-band protocol is used when you wish to engage with another agent and you don't have a DIDComm connection to use for the interaction.</p>"},{"location":"aip2/0434-outofband/#motivation","title":"Motivation","text":"<p>The use of the <code>invitation</code> in the Connection and DID Exchange protocols has been relatively successful, but has some shortcomings, as follows.</p>"},{"location":"aip2/0434-outofband/#connection-reuse","title":"Connection Reuse","text":"<p>A common pattern we have seen in the early days of Aries agents is a user with a browser getting to a point where a connection is needed between the website's (enterprise) agent and the user's mobile agent. A QR invitation is displayed, scanned and a protocol is executed to establish a connection. Life is good!</p> <p>However, with the current invitation processes, when the same user returns to the same page, the same process is executed (QR code, scan, etc.) and a new connection is created between the two agents. There is no way for the user's agent to say \"Hey, I've already got a connection with you. Let's use that one!\"</p> <p>We need the ability to reuse a connection.</p>"},{"location":"aip2/0434-outofband/#connection-establishment-versioning","title":"Connection Establishment Versioning","text":"<p>In the existing Connections and DID Exchange <code>invitation</code> handling, the inviter dictates what connection establishment protocol all invitee's will use. A more sustainable approach is for the inviter to offer the invitee a list of supported protocols and allow the invitee to use one that it supports.</p>"},{"location":"aip2/0434-outofband/#handling-of-all-out-of-band-messages","title":"Handling of all Out-of-Band Messages","text":"<p>We currently have two sets of out-of-band messages that cannot be delivered via DIDComm because there is no channel. We'd like to align those messages into a single \"out-of-band\" protocol so that their handling can be harmonized inside an agent, and a common QR code handling mechanism can be used.</p>"},{"location":"aip2/0434-outofband/#urls-and-qr-code-handling","title":"URLs and QR Code Handling","text":"<p>We'd like to have the specification of QR handling harmonized into a single RFC (this one).</p>"},{"location":"aip2/0434-outofband/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0434-outofband/#key-concepts","title":"Key Concepts","text":"<p>The Out-of-band protocol is used when an agent doesn't know if it has a connection with another agent. This could be because you are trying to establish a new connection with that agent, you have connections but don't know who the other party is, or if you want to have a connection-less interaction. Since there is no DIDComm connection to use for the messages of this protocol, the messages are plaintext and sent out-of-band, such as via a QR code, in an email message or any other available channel. Since the delivery of out-of-band messages will often be via QR codes, this RFC also covers the use of QR codes.</p> <p>Two well known use cases for using an out-of-band protocol are:</p> <ul> <li>A user on a web browser wants to execute a protocol (for example, to issue a verifiable credential) between the website operator's agent and a user's agent. To enable the execution of the protocol, the two agents must first have a connection. An out-of-band message is used to trigger the creation of a new, or the reuse an existing, connection.</li> <li>A website operator wants to request something from a user on their site where there is no (known) connection with the user's agent, and there is no need to create a connection.</li> </ul> <p>In both cases, there is only a single out-of-band protocol message sent. The message responding to the out-of-band message is a DIDComm message from an appropriate protocol.</p> <p>Note that the website-to-agent model is not the only such interaction enabled by the out-of-band protocol, and a QR code is not the only delivery mechanism for out-of-band messages. However, they are useful as examples of the purpose of the protocol.</p>"},{"location":"aip2/0434-outofband/#roles","title":"Roles","text":"<p>The out-of-band protocol has two roles: sender and receiver.</p>"},{"location":"aip2/0434-outofband/#sender","title":"sender","text":"<p>The agent that generates the out-of-band message and makes it available to the other party.</p>"},{"location":"aip2/0434-outofband/#receiver","title":"receiver","text":"<p>The agent that receives the out-of-band message and decides how to respond. There is no out-of-band protocol message with which the receiver will respond. Rather, if they respond, they will use a message from another protocol that the sender understands.</p>"},{"location":"aip2/0434-outofband/#states","title":"States","text":"<p>The state machines for the sender and receiver are a bit odd for the out-of-band protocol because it consists of a single message that kicks off a co-protocol and ends when evidence of the co-protocol's launch is received, in the form of some response. In the following state machine diagrams we generically describe the response message from the receiver as being a DIDComm message.</p> <p>The sender state machine is as follows:</p> <p></p> <p>Note the \"optional\" reference under the second event in the <code>await-response</code> state. That is to indicate that an out-of-band message might be a single use message with a transition to done, or reusable message (received by many receivers) with a transition back to <code>await-response</code>.</p> <p>The receiver state machine is as follows:</p> <p></p> <p>Worth noting is the first event of the <code>done</code> state, where the receiver may receive the message multiple times. This represents, for example, an agent returning to the same website and being greeted with instances of the same QR code each time.</p>"},{"location":"aip2/0434-outofband/#messages","title":"Messages","text":"<p>The out-of-band protocol a single message that is sent by the sender.</p>"},{"location":"aip2/0434-outofband/#invitation-httpsdidcommorgout-of-bandverinvitation","title":"Invitation: <code>https://didcomm.org/out-of-band/%VER/invitation</code>","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/invitation\",\n  \"@id\": \"&lt;id used for context as pthid&gt;\",\n  \"label\": \"Faber College\",\n  \"goal_code\": \"issue-vc\",\n  \"goal\": \"To issue a Faber College Graduate credential\",\n  \"accept\": [\n    \"didcomm/aip2;env=rfc587\",\n    \"didcomm/aip2;env=rfc19\"\n  ],\n  \"handshake_protocols\": [\n    \"https://didcomm.org/didexchange/1.0\",\n    \"https://didcomm.org/connections/1.0\"\n  ],\n  \"requests~attach\": [\n    {\n      \"@id\": \"request-0\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"json\": \"&lt;json of protocol message&gt;\"\n      }\n    }\n  ],\n  \"services\": [\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]\n}\n</code></pre> <p>The items in the message are:</p> <ul> <li><code>@type</code> - the DIDComm message type</li> <li><code>@id</code> - the unique ID of the message. The ID should be used as the parent thread ID (<code>pthid</code>) for the response message, rather than the more common thread ID (<code>thid</code>) of the response message. This enables multiple uses of a single out-of-band message.</li> <li><code>label</code> - [optional] a self-attested string that the receiver may want to display to the user, likely about who sent the out-of-band message.</li> <li><code>goal_code</code> - [optional] a self-attested code the receiver may want to display to the user or use in automatically deciding what to do with the out-of-band message.</li> <li><code>goal</code> - [optional] a self-attested string that the receiver may want to display to the user about the context-specific goal of the out-of-band message.</li> <li><code>accept</code> - [optional] an array of media (aka mime) types in the order of preference of the sender that the receiver can use in responding to the message. If <code>accept</code> is not specified, the receiver uses its preferred choice to respond to the message. RFC 0044 provides a general discussion of media types.</li> <li><code>handshake_protocols</code> - [optional] an array of protocols in the order of preference of the sender that the receiver can use in responding to the message in order to create or reuse a connection with the sender. These are not arbitrary protocols but rather protocols that result in the establishment of a connection. One or both of <code>handshake_protocols</code> and <code>requests~attach</code> MUST be included in the message.</li> <li><code>requests~attach</code> - [optional] an attachment decorator containing an array of request messages in order of preference that the receiver can using in responding to the message. One or both of <code>handshake_protocols</code> and <code>requests~attach</code> MUST be included in the message.</li> <li>While the JSON form of the attachment is used in the example above, the sender could choose to use the base64 form.</li> <li><code>services</code> - an array of union types that the receiver uses when responding to the message. Each item is either a DIDComm <code>service</code> object (as per RFC0067) or a DID (as per Decentralized Identifiers v1.0). Additional details below.</li> </ul> <p>If only the <code>handshake_protocols</code> item is included, the initial interaction will complete with the establishment (or reuse) of the connection. Either side may then use that connection for any purpose. A common use case (but not required) would be for the sender to initiate another protocol after the connection is established to accomplish some shared goal.</p> <p>If only the <code>requests~attach</code> item is included, no new connection is expected to be created, although one could be used if the receiver knows such a connection already exists. The receiver responds to one of the messages in the <code>requests~attach</code> array. The <code>requests~attach</code> item might include the first message of a protocol from the sender, or might be a please-play-the-role message requesting the receiver initiate a protocol. If the protocol requires a further response from the sender to the receiver, the receiver must include a <code>~service</code> decorator for the sender to use in responding.</p> <p>If both the <code>handshake_protocols</code> and <code>requests~attach</code> items are included in the message, the receiver should first establish a connection and then respond (using that connection) to one of the messages in the <code>requests~attach</code> message. If a connection already exists between the parties, the receiver may respond immediately to the <code>request-attach</code> message using the established connection.</p>"},{"location":"aip2/0434-outofband/#reuse-messages","title":"Reuse Messages","text":"<p>While the receiver is expected to respond with an initiating message from a <code>handshake_protocols</code> or <code>requests~attach</code> item using an offered service, the receiver may be able to respond by reusing an existing connection. Specifically, if a connection they have was created from an out-of-band <code>invitation</code> from the same <code>services</code> DID of a new <code>invitation</code> message, the connection MAY be reused. The receiver may choose to not reuse the existing connection for privacy purposes and repeat a handshake protocol to receive a redundant connection. </p> <p>If a message has a service block instead of a DID in the <code>services</code> list, you may enable reuse by encoding the key and endpoint of the service block in a Peer DID numalgo 2 and using that DID instead of a service block.</p> <p>If the receiver desires to reuse the existing connection and a <code>requests~attach</code> item is included in the message, the receiver SHOULD respond to one of the attached messages using the existing connection.</p> <p>If the receiver desires to reuse the existing connection and no <code>requests~attach</code> item is included in the message, the receiver SHOULD attempt to do so with the <code>reuse</code> and <code>reuse-accepted</code> messages. This will notify the inviter that the existing connection should be used, along with the context that can be used for follow-on interactions.</p> <p>While the <code>invitation</code> message is passed unencrypted and out-of-band, both the <code>handshake-reuse</code> and <code>handshake-reuse-accepted</code> messages MUST be encrypted and transmitted as normal DIDComm messages.</p>"},{"location":"aip2/0434-outofband/#reuse-httpsdidcommorgout-of-bandverhandshake-reuse","title":"Reuse: <code>https://didcomm.org/out-of-band/%VER/handshake-reuse</code>","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/handshake-reuse\",\n  \"@id\": \"&lt;id&gt;\",\n  \"~thread\": {\n    \"thid\": \"&lt;same as @id&gt;\",\n    \"pthid\": \"&lt;The @id of the Out-of-Band invitation&gt;\"\n  }\n}\n</code></pre> <p>The items in the message are:</p> <ul> <li><code>@type</code> - the DIDComm message type</li> <li><code>@id</code> - the unique ID of the message. </li> <li><code>pthid</code> - the @id of the invitation message. This provides the context link for the inviter to prompt additional protocol interactions.</li> </ul> <p>Sending or receiving this message does not change the state of the existing connection.</p> <p>When the inviter receives the <code>handshake-reuse</code> message, they MUST respond with a <code>handshake-reuse-accepted</code> message to notify that invitee that the request to reuse the existing connection is successful.</p>"},{"location":"aip2/0434-outofband/#reuse-accepted-httpsdidcommorgout-of-bandverhandshake-reuse-accepted","title":"Reuse Accepted:  <code>https://didcomm.org/out-of-band/%VER/handshake-reuse-accepted</code>","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/handshake-reuse-accepted\",\n  \"@id\": \"&lt;id&gt;\",\n  \"~thread\": {\n    \"thid\": \"&lt;The Message @id of the reuse message&gt;\",\n    \"pthid\": \"&lt;The @id of the Out-of-Band invitation&gt;\"\n  }\n}\n</code></pre> <p>The items in the message are:</p> <ul> <li><code>@type</code> - the DIDComm message type</li> <li><code>@id</code> - the unique ID of the message. </li> <li><code>pthid</code> - the @id of the invitation message. This and the <code>thid</code> provides context for the invitee to know the reuse attempt succeeded.</li> </ul> <p>If this message is not received by the invitee, they should use the regular process. This message is a mechanism by which the invitee can detect a situation where the inviter no longer has a record of the connection and is unable to decrypt and process the <code>handshake-reuse</code> message.</p> <p>After sending this message, the inviter may continue any desired protocol interactions based on the context matched by the <code>pthid</code> present in the <code>handshake-reuse</code> message.</p>"},{"location":"aip2/0434-outofband/#responses","title":"Responses","text":"<p>The following table summarizes the different forms of the out-of-band <code>invitation</code> message depending on the presence (or not) of the <code>handshake_protocols</code> item, the <code>requests~attach</code> item and whether or not a connection between the agents already exists.</p> <code>handshake_protocols</code> Present? <code>requests~attach</code> Present? Existing connection? Receiver action(s) No No No Impossible Yes No No Uses the first supported protocol from <code>handshake_protocols</code> to make a new connection using the first supported <code>services</code> entry. No Yes No Send a response to the first supported request message using the first supported <code>services</code> entry. Include a <code>~service</code> decorator if the sender is expected to respond. No No Yes Impossible Yes Yes No Use the first supported protocol from <code>handshake_protocols</code> to make a new connection using the first supported <code>services</code> entry, and then send a response message to the first supported attachment message using the new connection. Yes No Yes Send a <code>handshake-reuse</code> message. No Yes Yes Send a response message to the first supported request message using the existing connection. Yes Yes Yes Send a response message to the first supported request message using the existing connection. <p>Both the <code>goal_code</code> and <code>goal</code> fields SHOULD be used with the localization service decorator. The two fields are to enable both human and machine handling of the out-of-band message. <code>goal_code</code> is to specify a generic, protocol level outcome for sending the out-of-band message (e.g. issue verifiable credential, request proof, etc.) that is suitable for machine handling and possibly human display, while <code>goal</code> provides context specific guidance, targeting mainly a person controlling the receiver's agent. The list of <code>goal_code</code> values is provided in the Message Catalog section of this RFC.</p>"},{"location":"aip2/0434-outofband/#the-services-item","title":"The <code>services</code> Item","text":"<p>As mentioned in the description above, the <code>services</code> item array is intended to be analogous to the <code>service</code> block of a DIDDoc. When not reusing an existing connection, the receiver scans the array and selects (according to the rules described below) a service entry to use for the response to the out-of-band message.</p> <p>There are two forms of entries in the <code>services</code> item array:</p> <ul> <li>a DID that is resolved to retrieve it's DIDDoc service block, and</li> <li>an inline service block.</li> </ul> <p>The following is an example of a two entry array, one of each form:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/invitation\",\n  \"@id\": \"&lt;id used for context as pthid&gt;\",\n  \"label\": \"Faber College\",\n  \"handshake_protocols\": [\"https://didcomm.org/didexchange/1.0\"],\n  \"services\": [\n    {\n      \"id\": \"#inline\",\n      \"type\": \"did-communication\",\n      \"recipientKeys\": [\"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"],\n      \"routingKeys\": [],\n      \"serviceEndpoint\": \"https://example.com:5000\"\n    },\n    \"did:sov:LjgpST2rjsoxYegQDRm7EL\"\n  ]\n}\n</code></pre> <p>The processing rules for the <code>services</code> block are:</p> <ul> <li>Use only entries where the <code>type</code> is equal to <code>did-communication</code>.</li> <li>Entries without a <code>type</code> are assumed to be <code>did-communication</code>.</li> <li>The sender MUST put the array into their order of preference, and, as such, the receiver SHOULD prefer the entries in order.</li> </ul> <p>The attributes in the inline form parallel the attributes of a DID Document for increased meaning. The <code>recipientKeys</code> and <code>routingKeys</code> within the inline block decorator MUST be <code>did:key</code> references.</p> <p>As defined in the DIDComm Cross Domain Messaging RFC, if <code>routingKeys</code> is present and non-empty, additional forwarding wrapping are necessary in the response message.</p> <p>When considering routing and options for out-of-band messages, keep in mind that the more detail in the message, the longer the URL will be and (if used) the more dense (and harder to scan) the QR code will be.</p>"},{"location":"aip2/0434-outofband/#service-endpoint","title":"Service Endpoint","text":"<p>The service endpoint used to transmit the response is either present in the out-of-band message or available in the DID Document of a presented DID. If the endpoint is itself a DID, the <code>serviceEndpoint</code> in the DIDDoc of the resolved DID MUST be a URI, and the <code>recipientKeys</code> MUST contain a single key. That key is appended to the end of the list of <code>routingKeys</code> for processing. For more information about message forwarding and routing, see RFC 0094 Cross Domain Messaging.</p>"},{"location":"aip2/0434-outofband/#adoption-messages","title":"Adoption Messages","text":"<p>The <code>problem_report</code> message MAY be adopted by the out-of-band protocol if the agent wants to respond with problem reports to invalid messages, such as attempting to reuse a single-use invitation.</p>"},{"location":"aip2/0434-outofband/#constraints","title":"Constraints","text":"<p>An existing connection can only be reused based on a DID in the <code>services</code> list in an out-of-band message.</p>"},{"location":"aip2/0434-outofband/#reference","title":"Reference","text":""},{"location":"aip2/0434-outofband/#messages-reference","title":"Messages Reference","text":"<p>The full description of the message in this protocol can be found in the Tutorial section of this RFC.</p>"},{"location":"aip2/0434-outofband/#localization","title":"Localization","text":"<p>The <code>goal_code</code> and <code>goal</code> fields SHOULD have localization applied. See the purpose of those fields in the message type definitions section and the message catalog section (immediately below).</p>"},{"location":"aip2/0434-outofband/#message-catalog","title":"Message Catalog","text":""},{"location":"aip2/0434-outofband/#goal_code","title":"<code>goal_code</code>","text":"<p>The following values are defined for the <code>goal_code</code> field:</p> Code (cd) English (en) issue-vc To issue a credential request-proof To request a proof create-account To create an account with a service p2p-messaging To establish a peer-to-peer messaging relationship"},{"location":"aip2/0434-outofband/#goal","title":"<code>goal</code>","text":"<p>The <code>goal</code> localization values are use case specific and localization is left to the agent implementor to enable using the techniques defined in the ~l10n RFC.</p>"},{"location":"aip2/0434-outofband/#roles-reference","title":"Roles Reference","text":"<p>The roles are defined in the Tutorial section of this RFC.</p>"},{"location":"aip2/0434-outofband/#states-reference","title":"States Reference","text":""},{"location":"aip2/0434-outofband/#initial","title":"initial","text":"<p>No out-of-band messages have been sent.</p>"},{"location":"aip2/0434-outofband/#await-response","title":"await-response","text":"<p>The sender has shared an out-of-band message with the intended receiver(s), and the sender has not yet received all of the responses. For a single-use out-of-band message, there will be only one response; for a multi-use out-of-band message, there is no defined limit on the number of responses.</p>"},{"location":"aip2/0434-outofband/#prepare-response","title":"prepare-response","text":"<p>The receiver has received the out-of-band message and is preparing a response. The response will not be an out-of-band protocol message, but a message from another protocol chosen based on the contents of the out-of-band message.</p>"},{"location":"aip2/0434-outofband/#done","title":"done","text":"<p>The out-of-band protocol has been completed. Note that if the out-of-band message was intended to be available to many receivers (a multiple use message), the sender returns to the await-response state rather than going to the done state.</p>"},{"location":"aip2/0434-outofband/#errors","title":"Errors","text":"<p>There is an optional courtesy error message stemming from an out-of-band message that the sender could provide if they have sufficient recipient information. If the out-of-band message is a single use message and the sender receives multiple responses and each receiver's response includes a way for the sender to respond with a DIDComm message, all but the first MAY be answered with a <code>problem_report</code>.</p>"},{"location":"aip2/0434-outofband/#error-message-example","title":"Error Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/problem_report\",\n  \"@id\": \"5678876542345\",\n  \"~thread\": { \"pthid\": \"&lt;@id of the OutofBand message&gt;\" },\n  \"description\": {\n    \"en\": \"The invitation has expired.\",\n    \"code\": \"expired-invitation\"\n  },\n  \"impact\": \"thread\"\n}\n</code></pre> <p>See the problem-report protocol for details on the items in the example.</p>"},{"location":"aip2/0434-outofband/#flow-overview","title":"Flow Overview","text":"<p>In an out-of-band message the sender gives information to the receiver about the kind of DIDComm protocol response messages it can handle and how to deliver the response. The receiver uses that information to determine what DIDComm protocol/message to use in responding to the sender, and (from the service item or an existing connection) how to deliver the response to the sender.</p> <p>The handling of the response is specified by the protocol used.</p> <p>To Do: Make sure that the following remains in the DID Exchange/Connections RFCs</p> <p>Any Published DID that expresses support for DIDComm by defining a  <code>service</code> that follows the DIDComm conventions serves as an implicit invitation. If an invitee wishes to connect to any Published DID, they need not wait for an out-of-band invitation message. Rather, they can designate their own label and initiate the appropriate protocol (e.g. 0160-Connections or 0023-DID-Exchange) for establishing a connection.</p>"},{"location":"aip2/0434-outofband/#standard-out-of-band-message-encoding","title":"Standard Out-of-Band Message Encoding","text":"<p>Using a standard out-of-band message encoding allows for easier interoperability between multiple projects and software platforms. Using a URL for that standard encoding provides a built in fallback flow for users who are unable to automatically process the message. Those new users will load the URL in a browser as a default behavior, and may be presented with instructions on how to install software capable of processing the message. Already onboarded users will be able to process the message without loading in a browser via mobile app URL capture, or via capability detection after being loaded in a browser.</p> <p>The standard out-of-band message format is a URL with a Base64Url encoded json object as a query parameter.</p> <p>Please note the difference between Base64Url and Base64 encoding.</p> <p>The URL format is as follows, with some elements described below:</p> <pre><code>https://&lt;domain&gt;/&lt;path&gt;?oob=&lt;outofbandMessage&gt;\n</code></pre> <p><code>&lt;domain&gt;</code> and <code>&lt;path&gt;</code> should be kept as short as possible, and the full URL SHOULD return human readable instructions when loaded in a browser. This is intended to aid new users. The <code>oob</code> query parameter is required and is reserved to contain the out-of-band message string. Additional path elements or query parameters are allowed, and can be leveraged to provide coupons or other promise of payment for new users.</p> <p>To do: We need to rationalize this approach <code>https://</code> approach with the use of a special protocol (e.g. <code>didcomm://</code>) that will enable handling of the URL on mobile devices to automatically invoke an installed app on both Android and iOS. A user must be able to process the out-of-band message on the device of the agent (e.g. when the mobile device can't scan the QR code because it is on a web page on device).</p> <p>The <code>&lt;outofbandMessage&gt;</code> is an agent plaintext message (not a DIDComm message) that has been Base64Url encoded such that the resulting string can be safely used in a URL.</p> <pre><code>outofband_message = base64UrlEncode(&lt;outofbandMessage&gt;)\n</code></pre> <p>During Base64Url encoding, whitespace from the JSON string SHOULD be eliminated to keep the resulting out-of-band message string as short as possible.</p>"},{"location":"aip2/0434-outofband/#example-out-of-band-message-encoding","title":"Example Out-of-Band Message Encoding","text":"<p>Invitation:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/1.0/invitation\",\n  \"@id\": \"69212a3a-d068-4f9d-a2dd-4741bca89af3\",\n  \"label\": \"Faber College\",\n  \"goal_code\": \"issue-vc\",\n  \"goal\": \"To issue a Faber College Graduate credential\",\n  \"handshake_protocols\": [\"https://didcomm.org/didexchange/1.0\", \"https://didcomm.org/connections/1.0\"],\n  \"services\": [\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]\n}\n</code></pre> <p>Whitespace removed:</p> <pre><code>{\"@type\":\"https://didcomm.org/out-of-band/1.0/invitation\",\"@id\":\"69212a3a-d068-4f9d-a2dd-4741bca89af3\",\"label\":\"Faber College\",\"goal_code\":\"issue-vc\",\"goal\":\"To issue a Faber College Graduate credential\",\"handshake_protocols\":[\"https://didcomm.org/didexchange/1.0\",\"https://didcomm.org/connections/1.0\"],\"services\":[\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]}\n</code></pre> <p>Base64Url encoded:</p> <pre><code>eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0=\n</code></pre> <p>Example URL with Base64Url encoded message:</p> <pre><code>http://example.com/ssi?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0=\n</code></pre> <p>Out-of-band message URLs can be transferred via any method that can send text, including an email, SMS, posting on a website, or QR Code.</p> <p>Example URL encoded as a QR Code:</p> <p></p> <p>Example Email Message:</p> <pre><code>To: alice@alum.faber.edu\nFrom: studentrecords@faber.edu\nSubject: Your request to connect and receive your graduate verifiable credential\n\nDear Alice,\n\nTo receive your Faber College graduation certificate, click here to [connect](http://example.com/ssi?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0=) with us, or paste the following into your browser:\n\nhttp://example.com/ssi?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0=\n\nIf you don't have an identity agent for holding credentials, you will be given instructions on how you can get one.\n\nThanks,\n\nFaber College\nKnowledge is Good\n</code></pre>"},{"location":"aip2/0434-outofband/#url-shortening","title":"URL Shortening","text":"<p>It seems inevitable that the length of some out-of-band message will be too long to produce a useable QR code. Techniques to avoid unusable QR codes have been presented above, including using attachment links for requests, minimizing the routing of the response and eliminating unnecessary whitespace in the JSON. However, at some point a sender may need generate a very long URL. In that case, a DIDComm specific URL shortener redirection should be implemented by the sender as follows:</p> <ul> <li>The sender generates a unique URL for each shortened out-of-band message.</li> <li>The unique URL often includes a unique id component as part of the path or in a query parameter.</li> <li>The following URLs are valid examples:</li> <li><code>https://example.com/ssi?id=5f0e3ffb-3f92-4648-9868-0d6f8889e6f3</code></li> <li><code>https://example.com/8E6nEcJ26TTE</code></li> <li><code>https://example.com/sky/event/8DcnUW2h8m4jcfPdQ2uMN7/work-laptop-bag/s/u</code></li> <li>On receipt of this form of message, the agent MUST perform an HTTP GET to retrieve the associated out-of-band message. The agent SHOULD include an <code>Accept</code> header requesting the <code>application/json</code> MIME type.</li> <li>The sender MAY include a <code>Content-Type</code> header specifying <code>application/json; charset=utf-8</code>, and in the case where the agent included an <code>Accept</code> header for the <code>application/json</code> MIME type, the sender MUST include the header. If so, the sender MUST return the invitation in JSON format in the response body with a <code>status_code</code> of <code>200</code>.</li> <li>The sender MAY respond with a <code>status_code</code> of <code>301</code> or <code>302</code> and include a <code>Location</code> header specifying the long out-of-band message URL.</li> <li>This redirect option operates like many commercial URL shorteners. </li> <li>The sender MUST invalidate the URL after message retrieval or after an expiration time to prevent unintended parties from retrieving a copy of the message.</li> <li>A sender MUST NOT use a commercial URL shortener unless it supports invalidating the URL.</li> </ul> <p>A usable QR code will always be able to be generated from the shortened form of the URL.</p>"},{"location":"aip2/0434-outofband/#url-shortening-caveats","title":"URL Shortening Caveats","text":"<p>Some HTTP libraries don't support stopping redirects from occuring on reception of a <code>301</code> or <code>302</code>, in this instance the redirect is automatically followed and will result in a response that MAY have a status of <code>200</code> and MAY contain a URL that can be processed as a normal <code>Out-of-Band</code> message.</p> <p>If the agent performs a HTTP GET with the <code>Accept</code> header requesting <code>application/json</code> MIME type the response can either contain the message in <code>json</code> or result in a redirect, processing of the response should attempt to determine which response type is received and process the message accordingly.</p>"},{"location":"aip2/0434-outofband/#out-of-band-message-publishing","title":"Out-of-Band Message Publishing","text":"<p>The sender will publish or transmit the out-of-band message URL in a manner available to the intended receiver. After publishing, the sender is in the await-response state, will the receiver is in the prepare-response state.</p>"},{"location":"aip2/0434-outofband/#out-of-band-message-processing","title":"Out-of-Band Message Processing","text":"<p>If the receiver receives an <code>out-of-band</code> message in the form of a QR code, the receiver should attempt to decode the QR code to an out-of-band message URL for processing.</p> <p>When the receiver receives the out-of-band message URL, there are two possible user flows, depending on whether the individual has an Aries agent. If the individual is new to Aries, they will likely load the URL in a browser. The resulting page SHOULD contain instructions on how to get started by installing an Aries agent. That install flow will transfer the out-of-band message to the newly installed software.</p> <p>A user that already has those steps accomplished will have the URL received by software directly. That software will attempt to base64URL decode the string and can read the out-of-band message directly out of the <code>oob</code> query parameter, without loading the URL. If this process fails then the software should attempt the steps to process a shortened URL. </p> <p>NOTE: In receiving the out-of-band message, the base64url decode implementation used MUST correctly decode padded and unpadded base64URL encoded data.</p> <p>If the receiver wants to respond to the out-of-band message, they will use the information in the message to prepare the request, including:</p> <ul> <li>the <code>handshake_protocols</code> or <code>requests~attach</code> to determine the acceptable response messages, and</li> <li>the <code>services</code> block to determine how to get the response to the sender.</li> </ul>"},{"location":"aip2/0434-outofband/#correlating-responses-to-out-of-band-messages","title":"Correlating responses to Out-of-Band messages","text":"<p>The response to an out-of-band message MUST set its <code>~thread.pthid</code> equal to the <code>@id</code> property of the out-of-band message.</p> <p>Example referencing an explicit invitation:</p> <pre><code>{\n  \"@id\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n  \"@type\": \"https://didcomm.org/didexchange/1.0/request\",\n  \"~thread\": { \"pthid\": \"032fbd19-f6fd-48c5-9197-ba9a47040470\" },\n  \"label\": \"Bob\",\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n    \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n    \"jws\": {\n      \"header\": {\n        \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n      },\n      \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n      \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n    }\n  }\n}\n</code></pre>"},{"location":"aip2/0434-outofband/#response-transmission","title":"Response Transmission","text":"<p>The response message from the receiver is encoded according to the standards of the DIDComm encryption envelope, using the <code>service</code> block present in (or resolved from) the out-of-band invitation.</p>"},{"location":"aip2/0434-outofband/#reusing-connections","title":"Reusing Connections","text":"<p>If an out-of-band invitation has a DID in the <code>services</code> block, and the receiver determines it has previously established a connection with that DID, the receiver MAY send its response on the established connection. See Reuse Messages for details.</p>"},{"location":"aip2/0434-outofband/#receiver-error-handling","title":"Receiver Error Handling","text":"<p>If the receiver is unable to process the out-of-band message, the receiver may respond with a Problem Report identifying the problem using a DIDComm message. As with any response, the ~thread decorator of the <code>pthid</code> MUST be the <code>@id</code> of the out-of-band message. The problem report MUST be in the protocol of an expected response. An example of an error that might come up is that the receiver is not able to handle any of the proposed protocols in the out-of-band message. The receiver MAY include in the problem report a <code>~service</code> decorator that allows the sender to respond to the out-of-band message with a DIDComm message.</p>"},{"location":"aip2/0434-outofband/#response-processing","title":"Response processing","text":"<p>The sender MAY look up the corresponding out-of-band message identified in the response's <code>~thread.pthid</code> to determine whether it should accept the response. Information about the related out-of-band message protocol may be required to provide the sender with context about processing the response and what to do after the protocol completes.</p>"},{"location":"aip2/0434-outofband/#sender-error-handling","title":"Sender Error Handling","text":"<p>If the sender receives a Problem Report message from the receiver, the sender has several options for responding. The sender will receive the message as part of an offered protocol in the out-of-band message.</p> <p>If the receiver did not include a <code>~service</code> decorator in the response, the sender can only respond if it is still in session with the receiver. For example, if the sender is a website that displayed a QR code for the receiver to scan, the sender could create a new, presumably adjusted, out-of-band message, encode it and present it to the user in the same way as before.</p> <p>If the receiver included a <code>~service</code> decorator in the response, the sender can provide a new message to the receiver, even a new version of the original out-of-band message, and send it to the receiver. The new message MUST include a <code>~thread</code> decorator with the <code>thid</code> set to the <code>@id</code> from the problem report message.</p>"},{"location":"aip2/0434-outofband/#drawbacks","title":"Drawbacks","text":"<ul> <li>Publicly displayed out-of-band messages (say, a slide at the end of a presentation) all use the same DID. This is not a problem for institutions, and only provides a minor increase in correlation over sharing an endpoint, key, and routing information in a way that is observable by multiple parties.</li> </ul>"},{"location":"aip2/0434-outofband/#prior-art","title":"Prior art","text":"<ul> <li>The out-of-band message/response process is similar to other key exchange protocols.</li> <li>The Connections and DID Exchange protocols have (or had) their own <code>invitation</code> method.</li> <li>The <code>~service</code> decorator in combination with a request/response-type protocol message (such as present-proof/request) has previously used in place of the out-of-band <code>request</code> message.</li> </ul>"},{"location":"aip2/0434-outofband/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>None</li> </ul>"},{"location":"aip2/0434-outofband/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0441-present-proof-best-practices/","title":"0441: Prover and Verifier Best Practices for Proof Presentation","text":"<ul> <li>Authors: Stephen Klump</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Interoperability guidance when using Indy AnonCreds Present Proof. An element of the Indy AnonCreds subtarget for AIP v2.0.</li> <li>Start Date: 2020-10-31</li> <li>Tags: concept, credentials</li> </ul>"},{"location":"aip2/0441-present-proof-best-practices/#summary","title":"Summary","text":"<p>This work prescribes best practices for provers in credential selection (toward proof presentation), for verifiers in proof acceptance, and for both regarding non-revocation interval semantics in fulfilment of the Present Proof protocol RFC0037. Of particular instance is behaviour against presentation requests and presentations in their various non-revocation interval profiles.</p>"},{"location":"aip2/0441-present-proof-best-practices/#motivation","title":"Motivation","text":"<p>Agents should behave consistently in automatically selecting credentials and proving presentations.</p>"},{"location":"aip2/0441-present-proof-best-practices/#tutorial","title":"Tutorial","text":"<p>The subsections below introduce constructs and outline best practices for provers and verifiers.</p>"},{"location":"aip2/0441-present-proof-best-practices/#presentation-requests-and-non-revocation-intervals","title":"Presentation Requests and Non-Revocation Intervals","text":"<p>This section prescribes norms and best practices in formulating and interpreting non-revocation intervals on proof requests.</p>"},{"location":"aip2/0441-present-proof-best-practices/#semantics-of-non-revocation-interval-presence-and-absence","title":"Semantics of Non-Revocation Interval Presence and Absence","text":"<p>The presence of a non-revocation interval applicable to a requested item (see below) in a presentation request signifies that the verifier requires proof of non-revocation status of the credential providing that item.</p> <p>The absence of any non-revocation interval applicable to a requested item signifies that the verifier has no interest in its credential's non-revocation status.</p> <p>A revocable or non-revocable credential may satisfy a presentation request with or without a non-revocation interval. The presence of a non-revocation interval conveys that if the prover presents a revocable credential, the presentation must include proof of non-revocation. Its presence does not convey any restriction on the revocability of the credential to present: in many cases the verifier cannot know whether a prover's credential is revocable or not.</p>"},{"location":"aip2/0441-present-proof-best-practices/#non-revocation-interval-applicability-to-requested-items","title":"Non-Revocation Interval Applicability to Requested Items","text":"<p>A requested item in a presentation request is an attribute or a predicate, proof of which the verifier requests presentation. A non-revocation interval within a presentation request is specifically applicable, generally applicable, or inapplicable to a requested item.</p> <p>Within a presentation request, a top-level non-revocation interval is generally  applicable to all requested items. A non-revocation interval defined particularly for  a requested item is specifically applicable to that requested attribute or predicate but inapplicable to all others.</p> <p>A non-revocation interval specifically applicable to a requested item overrides any generally applicable non-revocation interval: no requested item may have both.</p> <p>For example, in the following (indy) proof request</p> <pre><code>{\n    \"name\": \"proof-request\",\n    \"version\": \"1.0\",\n    \"nonce\": \"1234567890\",\n    \"requested_attributes\": {\n        \"legalname\": {\n            \"name\": \"legalName\",\n            \"restrictions\": [\n                {\n                    \"issuer_did\": \"WgWxqztrNooG92RXvxSTWv\"\n                }\n            ]\n        },\n        \"regdate\": {\n            \"name\": \"regDate\",\n            \"restrictions\": [\n                {\n                    \"issuer_did\": \"WgWxqztrNooG92RXvxSTWv\"\n                }\n            ],\n            \"non_revoked\": {\n                \"from\": 1600001000,\n                \"to\": 1600001000\n            }\n        }\n    },\n    \"requested_predicates\": {\n    },\n    \"non_revoked\": {\n        \"from\": 1600000000,\n        \"to\": 1600000000\n    }\n}\n</code></pre> <p>the non-revocation interval on 1600000000 is generally applicable to the referent <code>\"legalname\"</code> while the non-revocation interval on 1600001000 specifically applicable to referent <code>\"regdate\"</code>.</p>"},{"location":"aip2/0441-present-proof-best-practices/#semantics-of-non-revocation-interval-endpoints","title":"Semantics of Non-Revocation Interval Endpoints","text":"<p>A non-revocation interval contains <code>\"from\"</code> and <code>\"to\"</code> (integer) EPOCH times. For historical reasons, any timestamp within this interval is technically acceptable in a non-revocation subproof. However, these semantics allow for ambiguity in cases where revocation occurs within the interval, and in cases where the ledger supports reinstatement. These best practices require the <code>\"from\"</code> value, should the prover specify it, to equal the <code>\"to\"</code> value: this approach fosters deterministic outcomes.</p> <p>A missing <code>\"from\"</code> specification defaults to the same value as the interval's <code>\"to\"</code> value. In other words, the non-revocation intervals</p> <pre><code>{\n    \"to\": 1234567890\n}\n</code></pre> <p>and</p> <pre><code>{\n    \"from\": 1234567890,\n    \"to\": 1234567890\n}\n</code></pre> <p>are semantically equivalent.</p>"},{"location":"aip2/0441-present-proof-best-practices/#verifier-non-revocation-interval-formulation","title":"Verifier Non-Revocation Interval Formulation","text":"<p>The verifier MUST specify, as current INDY-HIPE 11 notes, the same integer EPOCH time for both ends of the interval, or else omit the <code>\"from\"</code> key and value. In effect, where the presentation request specifies a non-revocation interval, the verifier MUST request a non-revocation instant.</p>"},{"location":"aip2/0441-present-proof-best-practices/#prover-non-revocation-interval-processing","title":"Prover Non-Revocation Interval Processing","text":"<p>In querying the nodes for revocation status, given a revocation interval on a single instant (i.e., on <code>\"from\"</code> and <code>\"to\"</code> the same, or <code>\"from\"</code> absent), the prover MUST query the ledger for all germane revocation updates from registry creation through that instant (i.e., from zero through <code>\"to\"</code> value): if the credential has been revoked prior to the instant, the revocation necessarily will appear in the aggregate delta.</p>"},{"location":"aip2/0441-present-proof-best-practices/#provers-presentation-proposals-and-presentation-requests","title":"Provers, Presentation Proposals, and Presentation Requests","text":"<p>In fulfilment of the RFC0037 Present Proof protocol, provers may initiate with a presentation proposal or verifiers may initiate with a presentation request. In the former case, the prover has both a presentation proposal and a presentation request; in the latter case, the prover has only a presentation request.</p>"},{"location":"aip2/0441-present-proof-best-practices/#credential-selection-best-practices","title":"Credential Selection Best Practices","text":"<p>This section specifies a prover's best practices in matching a credential to a requested item. The specification pertains to automated credential selection: obviously, a human user may select any credential in response to a presentation request; it is up to the verifier to verify the resulting presentation as satisfactory or not.</p> <p>Note that where a prover selects a revocable credential for inclusion in response to a requested item with a non-revocation interval in the presentation request, the prover MUST create a corresponding sub-proof of non-revocation at a timestamp within that non-revocation interval (insofar as possible; see below).</p>"},{"location":"aip2/0441-present-proof-best-practices/#with-presentation-proposal","title":"With Presentation Proposal","text":"<p>If prover initiated the protocol with a presentation proposal specifying a value (or predicate threshold) for an attribute, and the presentation request does not require a different value for it, then the prover MUST select a credential matching the presentation proposal, in addition to following the best practices below regarding the presentation request.</p>"},{"location":"aip2/0441-present-proof-best-practices/#preference-for-irrevocable-credentials","title":"Preference for Irrevocable Credentials","text":"<p>In keeping with the specification above, presentation of an irrevocable credential ipso facto constitutes proof of non-revocation. Provers MUST always prefer irrevocable credentials to revocable credentials, when the wallet has both satisfying a requested item, whether the requested item has an applicable non-revocation interval or not. Note that if a non-revocation interval is applicable to a credential's requested item in the presentation request, selecting an irrevocable credential for presentation may lead to a missing timestamp at the verifier (see below).</p> <p>If only revocable credentials are available to satisfy a requested item with no applicable non-revocation interval, the prover MUST present such for proof. As per above, the absence of a non-revocation interval signifies that the verifier has no interest in its revocation status.</p>"},{"location":"aip2/0441-present-proof-best-practices/#verifiers-presentations-and-timestamps","title":"Verifiers, Presentations, and Timestamps","text":"<p>This section prescribes verifier best practices concerning a received presentation by its timestamps against the corresponding presentation request's non-revocation intervals.</p>"},{"location":"aip2/0441-present-proof-best-practices/#timestamp-for-irrevocable-credential","title":"Timestamp for Irrevocable Credential","text":"<p>A presentation's inclusion of a timestamp pertaining to an irrevocable credential evinces tampering: the verifier MUST reject such a presentation.</p>"},{"location":"aip2/0441-present-proof-best-practices/#missing-timestamp","title":"Missing Timestamp","text":"<p>A presentation with no timestamp for a revocable credential purporting to satisfy a requested item in the corresponding presentation request, where the requested item has an applicable non-revocation interval, evinces tampering: the verifier MUST reject such a presentation.</p> <p>It is licit for a presentation to have no timestamp for an irrevocable credential: the applicable non-revocation interval is superfluous in the presentation request.</p>"},{"location":"aip2/0441-present-proof-best-practices/#timestamp-outside-non-revocation-interval","title":"Timestamp Outside Non-Revocation Interval","text":"<p>A presentation may include a timestamp outside of a the non-revocation interval applicable to the requested item that a presented credential purports to satisfy. If the latest timestamp from the ledger for a presented credential's revocation registry predates the non-revocation interval, but the timestamp is not in the future (relative to the instant of presentation proof, with a reasonable allowance for clock skew), the verifier MUST log and continue the proof verification process.</p> <p>Any timestamp in the future (relative to the instant of presentation proof, with a reasonable allowance for clock skew) evinces tampering: the verifier MUST reject a presentation with a future timestamp. Similarly, any timestamp predating the creation of its corresponding credential's revocation registry on the ledger evinces tampering: the verifier MUST reject a presentation with such a timestamp.</p>"},{"location":"aip2/0441-present-proof-best-practices/#dates-and-predicates","title":"Dates and Predicates","text":"<p>This section prescribes issuer and verifier best practices concerning representing dates for use in predicate proofs (eg proving Alice is over 21 without revealing her birth date).</p>"},{"location":"aip2/0441-present-proof-best-practices/#dates-in-credentials","title":"Dates in Credentials","text":"<p>In order for dates to be used in a predicate proof they MUST be expressed as an Int32. While unix timestamps could work for this, it has several drawbacks including: can't represent dates outside of the years 1901-2038, isn't human readable, and is overly precise in that birth time down to the second is generally not needed for an age check. To address these issues, date attributes SHOULD be represented as integers in the form YYYYMMDD (eg 19991231). This addresses the issues with unix timestamps (or any seconds-since-epoch system) while still allowing date values to be compared with &lt; &gt; operators. Note that this system won't work for any general date math (eg adding or subtracting days), but it will work for predicate proofs which just require comparisons. In order to make it clear that this format is being used, the attribute name SHOULD have the suffix <code>_dateint</code>. Since most datetime libraries don't include this format, here are some examples of helper functions written in typescript.</p>"},{"location":"aip2/0441-present-proof-best-practices/#dates-in-presentations","title":"Dates in Presentations","text":"<p>When constructing a proof request, the verifier SHOULD express the minimum/maximum date as an integer in the form YYYYMMDD. For example if today is Jan 1, 2021 then the verifier would request that <code>bithdate_dateint</code> is before or equal to Jan 1 2000 so <code>&lt;= 20000101</code>. The holder MUST construct a predicate proof with a YYYYMMDD represented birth date less than that value to satisfy the proof request.</p>"},{"location":"aip2/0441-present-proof-best-practices/#reference","title":"Reference","text":"<ul> <li>RFC 0037: Present Proof protocol</li> <li>INDY-HIPE 11: Indy revocation.</li> </ul>"},{"location":"aip2/0441-present-proof-best-practices/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"aip2/0453-issue-credential-v2/","title":"Aries RFC 0453: Issue Credential Protocol 2.0","text":"<ul> <li>Authors: Nikita Khateev, Stephen Klump, Stephen Curran</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note:  See RFC 0454 for the presentation part of using credentials.</li> <li>Supersedes: RFC 0036 Issue Credential v1.x</li> <li>Start Date: 2020-03-23</li> <li>Tags: feature, decorator, protocol, credentials, test-anomaly</li> </ul>"},{"location":"aip2/0453-issue-credential-v2/#version-change-log","title":"Version Change Log","text":"<ul> <li>20240311 Removed references to payments in the protocol to clarify to those new to the protocol that they have not been implemented by anyone.</li> <li>20240313 Version 2.0 is the current version</li> </ul> <p>For a period of time, versions 2.1 and 2.2 where defined in this RFC. Those definitions were added prior to any implementations, and to date, there are no known implementations available or planned. An attempt at implementing version 2.1 was not merged into the main branch of Aries Cloud Agent Python, deemed overly complicated and not worth the effort for what amounts to an edge case (issuing multiple credentials of the same type in a single protocol instance). Further, there is a version 3.0 of this protocol that has been specified and implemented that does not include these capabilities. Thus, a decision was made that versions 2.1 and 2.2 be removed as being not accepted by the community and overly complicated to both implement and migrate from. Those interested in seeing how those capabilities were specified can look at this protocol before they were removed.</p>"},{"location":"aip2/0453-issue-credential-v2/#20propose-credential-and-identifiers","title":"2.0/propose-credential and identifiers","text":"<p>Version 2.0 of the protocol is introduced because of a breaking changes in the propose-credential message, replacing the (indy-specific) filtration criteria with a generalized filter attachment to align with the rest of the messages in the protocol. The previous version is 1.1/propose-credential. Version 2.0 also uses &lt;angle brackets&gt; explicitly to mark all values that may vary between instances, such as identifiers and comments.</p> <p>The \"formats\" field is added to all the messages to enable the linking the specific attachment IDs with the the format (credential format and version) of the attachment.</p> <p>The details that are part of each message type about the different attachment formats serves as a registry of the known formats and versions.</p>"},{"location":"aip2/0453-issue-credential-v2/#summary","title":"Summary","text":"<p>Formalizes messages used to issue a credential--whether the credential is JWT-oriented, JSON-LD-oriented, or ZKP-oriented. The general flow is similar, and this protocol intends to handle all of them. If you are using a credential type that doesn't fit this protocol, please raise a Github issue.</p>"},{"location":"aip2/0453-issue-credential-v2/#motivation","title":"Motivation","text":"<p>We need a standard protocol for issuing credentials. This is the basis of interoperability between Issuers and Holders.</p>"},{"location":"aip2/0453-issue-credential-v2/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0453-issue-credential-v2/#name-and-version","title":"Name and Version","text":"<p><code>issue-credential</code>, version 2.0</p>"},{"location":"aip2/0453-issue-credential-v2/#roles","title":"Roles","text":"<p>There are two roles in this protocol: Issuer and Holder. Technically, the latter role is only potential until the protocol completes; that is, the second party becomes a Holder of a credential by completing the protocol. However, we will use the term Holder throughout, to keep things simple.</p> <p>Note: When a holder of credentials turns around and uses those credentials to prove something, they become a Prover. In the sister RFC to this one, 0454: Present Proof Protocol 2.0, the Holder is therefore renamed to Prover. Sometimes in casual conversation, the Holder role here might be called \"Prover\" as well, but more formally, \"Holder\" is the right term at this phase of the credential lifecycle.</p>"},{"location":"aip2/0453-issue-credential-v2/#goals","title":"Goals","text":"<p>When the goals of each role are not available because of context, goal codes may be specifically included in protocol messages. This is particularly helpful to differentiate between credentials passed between the same parties for several different reasons. A goal code included should be considered to apply to the entire thread and is not necessary to be repeated on each message. Changing the goal code may be done by including the new code in a message. All goal codes are optional, and without default.</p>"},{"location":"aip2/0453-issue-credential-v2/#states","title":"States","text":"<p>The choreography diagram below details how state evolves in this protocol, in a \"happy path.\" The states include</p>"},{"location":"aip2/0453-issue-credential-v2/#issuer-states","title":"Issuer States","text":"<ul> <li>proposal-received</li> <li>offer-sent</li> <li>request-received</li> <li>credential-issued</li> <li>done</li> </ul>"},{"location":"aip2/0453-issue-credential-v2/#holder-states","title":"Holder States","text":"<ul> <li>proposal-sent</li> <li>offer-received</li> <li>request-sent</li> <li>credential-received</li> <li>done</li> </ul> <p>Errors might occur in various places. For example, an Issuer might offer a credential for a price that the Holder is unwilling to pay. All errors are modeled with a <code>problem-report</code> message. Easy-to-anticipate errors reset the flow as shown in the diagrams, and use the code <code>issuance-abandoned</code>; more exotic errors (e.g., server crashed at Issuer headquarters in the middle of a workflow) may have different codes but still cause the flow to be abandoned in the same way. That is, in this version of the protocol, all errors cause the state of both parties (the sender and the receiver of the <code>problem-report</code>) to revert to <code>null</code> (meaning it is no longer engaged in the protocol at all). Future versions of the protocol may allow more granular choices (e.g., requesting and receiving a (re-)send of the <code>issue-credential</code> message if the Holder times out while waiting in the <code>request-sent</code> state).</p> <p>The state table outlines the protocol states and transitions.</p>"},{"location":"aip2/0453-issue-credential-v2/#messages","title":"Messages","text":"<p>The Issue Credential protocol consists of these messages:</p> <ul> <li><code>propose-credential</code> - potential Holder to Issuer (optional). Tells what the Holder hopes to receive.</li> <li><code>offer-credential</code> - Issuer to potential Holder (optional for some credential implementations; required for Hyperledger Indy). Tells what the Issuer intends to issue, and possibly, the price the Issuer expects to be paid.</li> <li><code>request-credential</code> - potential Holder to Issuer. If neither of the previous message types is used, this is the message that begins the protocol.</li> <li><code>issue-credential</code> - Issuer to new Holder. Attachment payload contains the actual credential.</li> </ul> <p>In addition, the <code>ack</code> and <code>problem-report</code> messages are adopted into the protocol for confirmation and error handling.</p>"},{"location":"aip2/0453-issue-credential-v2/#message-attachments","title":"Message Attachments","text":"<p>This protocol is about the messages that must be exchanged to issue verifiable credentials, NOT about the specifics of particular verifiable credential schemes. DIDComm attachments are deliberately used in messages to isolate the protocol flow/semantics from the credential artifacts themselves as separate constructs. Attachments allow credential formats and this protocol to evolve through versioning milestones independently instead of in lockstep. Links are provided in the message descriptions below, to describe how the protocol adapts to specific verifiable credential implementations.</p> <p>The attachment items in the messages are arrays. The arrays are provided to support the issuing of different credential formats (e.g. ZKP, JSON-LD JWT, or other) containing the same data (claims). The arrays are not to be used for issuing credentials with different claims. The <code>formats</code> field of each message associates each attachment with the format (and version) of the attachment.</p> <p>A registry of attachment formats is provided in this RFC within the message type sections. A sub-section should be added for each attachment format type (and optionally, each version). Updates to the attachment type formats does NOT impact the versioning of the Issue Credential protocol. Formats are flexibly defined. For example, the first definitions are for <code>hlindy/cred-abstract@v2.0</code> et al., assuming that all Hyperledger Indy implementations and ledgers will use a common format. However, if a specific instance of Indy uses a different format, another format value can be documented as a new registry entry.</p> <p>Any of the 0017-attachments RFC embedded inline attachments can be used. In the examples below, <code>base64</code> is used in most cases, but implementations MUST expect any of the formats.</p>"},{"location":"aip2/0453-issue-credential-v2/#choreography-diagram","title":"Choreography Diagram","text":"<p>Note: This diagram was made in draw.io. To make changes:</p> <ul> <li>upload the drawing HTML from this folder to the draw.io site (Import From...GitHub),</li> <li>make changes,</li> <li>export the picture and HTML to your local copy of this repo, and</li> <li>submit a pull request.</li> </ul> <p>The protocol has 3 alternative beginnings:</p> <ol> <li>The Issuer can begin with an offer.</li> <li>The Holder can begin with a proposal.</li> <li>the Holder can begin with a request.</li> </ol> <p>The offer and proposal messages are part of an optional negotiation phase and may trigger back-and-forth counters. A request is not subject to negotiation; it can only be accepted or rejected.</p> <p></p>"},{"location":"aip2/0453-issue-credential-v2/#propose-credential","title":"Propose Credential","text":"<p>An optional message sent by the potential Holder to the Issuer to initiate the protocol or in response to an <code>offer-credential</code> message when the Holder wants some adjustments made to the credential data offered by Issuer.</p>  Note: In Hyperledger Indy, where the `request-credential` message can **only** be sent in response to an `offer-credential` message, the `propose-credential` message is the only way for a potential Holder to initiate the workflow.  <p>Message format:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/propose-credential\",\n    \"@id\": \"&lt;uuid of propose-message&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\"\n        }\n    ],\n    \"filters~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Proposal, so the proposal can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>credential_preview</code> -- an optional JSON-LD object that represents the credential data that Prover wants to receive. It matches the schema of Credential Preview.</li> <li><code>formats</code> -- contains an entry for each <code>filters~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable credential format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>filters~attach</code> -- an array of attachments that further define the credential being proposed. This might be used to clarify which formats or format versions are wanted.</li> </ul>"},{"location":"aip2/0453-issue-credential-v2/#propose-attachment-registry","title":"Propose Attachment Registry","text":"Credential Format Format Value Link to Attachment Format Comment DIF Credential Manifest <code>dif/credential-manifest@v1.0</code> <code>propose-credential</code> attachment format Linked Data Proof VC Detail <code>aries/ld-proof-vc-detail@v1.0</code> <code>ld-proof-vc-detail</code> attachment format Hyperledger Indy Credential Filter <code>hlindy/cred-filter@v2.0</code> <code>cred filter</code> format Hyperledger AnonCreds Credential Filter <code>anoncreds/credential-filter@v1.0</code> <code>Credential Filter</code> format"},{"location":"aip2/0453-issue-credential-v2/#offer-credential","title":"Offer Credential","text":"<p>A message sent by the Issuer to the potential Holder, describing the credential they intend to offer and possibly the price they expect to be paid. In Hyperledger Indy, this message is required, because it forces the Issuer to make a cryptographic commitment to the set of fields in the final credential and thus prevents Issuers from inserting spurious data. In credential implementations where this message is optional, an Issuer can use the message to negotiate the issuing following receipt of a <code>request-credential</code> message.</p> <p>Message Format:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/offer-credential\",\n    \"@id\": \"&lt;uuid of offer message&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"replacement_id\": \"&lt;issuer unique id&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"offers~attach\": [\n        {\n            \"@id\": \"&lt;attach@id value&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>replacement_id</code> -- an optional field to help coordinate credential replacement. When this is present and matches the <code>replacement_id</code> of a previously issued credential, it may be used to inform the recipient that the offered credential is considered to be a replacement to the previous credential. This value is unique to the issuer. It must not be used in a credential presentation.</li> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Offer, so the offer can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>credential_preview</code> -- a JSON-LD object that represents the credential data that Issuer is willing to issue. It matches the schema of Credential Preview;</li> <li><code>formats</code> -- contains an entry for each <code>offers~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable credential format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>offers~attach</code> -- an array of attachments that further define the credential being offered. This might be used to clarify which formats or format versions will be issued.</li> </ul> <p>It is possible for an Issuer to add a <code>~timing.expires_time</code> decorator to this message to convey the idea that the offer will expire at a particular point in the future. Such behavior is not a special part of this protocol, and support for it is not a requirement of conforming implementations; the <code>~timing</code> decorator is simply a general possibility for any DIDComm message. We mention it here just to note that the protocol can be enriched in composable ways.</p>"},{"location":"aip2/0453-issue-credential-v2/#offer-attachment-registry","title":"Offer Attachment Registry","text":"Credential Format Format Value Link to Attachment Format Comment DIF Credential Manifest <code>dif/credential-manifest@v1.0</code> <code>offer-credential</code> attachment format Hyperledger Indy Credential Abstract <code>hlindy/cred-abstract@v2.0</code> <code>cred abstract</code> format Linked Data Proof VC Detail <code>aries/ld-proof-vc-detail@v1.0</code> <code>ld-proof-vc-detail</code> attachment format Hyperledger AnonCreds Credential Offer <code>anoncreds/credential-offer@v1.0</code> <code>Credential Offer</code> format W3C VC - Data Integrity Proof Credential Offer <code>didcomm/w3c-di-vc-offer@v0.1</code> <code>Credential Offer</code> format"},{"location":"aip2/0453-issue-credential-v2/#request-credential","title":"Request Credential","text":"<p>This is a message sent by the potential Holder to the Issuer, to request the issuance of a credential. Where circumstances do not require a preceding Offer Credential message (e.g., there is no cost to issuance that the Issuer needs to explain in advance, and there is no need for cryptographic negotiation), this message initiates the protocol. When using the Hyperledger Indy AnonCreds verifiable credential format, this message can only be sent in response to an <code>offer-credential</code> message.</p> <p>Message Format:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/request-credential\",\n    \"@id\": \"&lt;uuid of request message&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"requests~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        },\n    ]\n}\n</code></pre> <p>Description of Fields:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Request, so it can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>formats</code> -- contains an entry for each <code>requests~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable credential format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>requests~attach</code> -- an array of attachments defining the requested formats for the credential.</li> </ul>"},{"location":"aip2/0453-issue-credential-v2/#request-attachment-registry","title":"Request Attachment Registry","text":"Credential Format Format Value Link to Attachment Format Comment DIF Credential Manifest <code>dif/credential-manifest@v1.0</code> <code>request-credential</code> attachment format Hyperledger Indy Credential Request <code>hlindy/cred-req@v2.0</code> <code>cred request</code> format Linked Data Proof VC Detail <code>aries/ld-proof-vc-detail@v1.0</code> <code>ld-proof-vc-detail</code> attachment format Hyperledger AnonCreds Credential Request <code>anoncreds/credential-request@v1.0</code> <code>Credential Request</code> format W3C VC - Data Integrity Proof Credential Request <code>didcomm/w3c-di-vc-request@v0.1</code> <code>Credential Request</code> format"},{"location":"aip2/0453-issue-credential-v2/#issue-credential","title":"Issue Credential","text":"<p>This message contains a verifiable credential being issued as an attached payload. It is sent in response to a valid Request Credential message.</p> <p>Message Format:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/issue-credential\",\n    \"@id\": \"&lt;uuid of issue message&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"replacement_id\": \"&lt;issuer unique id&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"credentials~attach\": [\n        {\n            \"@id\": \"&lt;attachment-id&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>replacement_id</code> -- an optional field that provides an identifier used to manage credential replacement. When this value is present and matches the <code>replacement_id</code> of a previously issued credential, this credential may be considered as a replacement for that credential. This value is unique to the issuer. It must not be used in a credential presentation.</li> <li><code>comment</code> -- an optional field that provides human readable information about the issued credential, so it can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>formats</code> -- contains an entry for each <code>credentials~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable credential format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>credentials~attach</code> -- an array of attachments containing the issued credentials.</li> </ul> <p>If the issuer wants an acknowledgement that he issued credential was accepted, this message must be decorated with the <code>~please-ack</code> decorator using the <code>OUTCOME</code> acknowledgement request. Outcome in the context of this protocol means the acceptance of the credential in whole, i.e. the credential is verified and the contents of the credential are acknowledged. Note that this is different from the default behavior as described in 0317: Please ACK Decorator. It is then best practice for the new Holder to respond with an explicit <code>ack</code> message as described in the please ack decorator RFC.</p>"},{"location":"aip2/0453-issue-credential-v2/#credentials-attachment-registry","title":"Credentials Attachment Registry","text":"Credential Format Format Value Link to Attachment Format Comment Linked Data Proof VC <code>aries/ld-proof-vc@v1.0</code> <code>ld-proof-vc</code> attachment format Hyperledger Indy Credential <code>hlindy/cred@v2.0</code> credential format Hyperledger AnonCreds Credential <code>anoncreds/credential@v1.0</code> <code>Credential</code> format W3C VC - Data Integrity Proof Credential <code>didcomm/w3c-di-vc@v0.1</code> <code>Credential</code> format"},{"location":"aip2/0453-issue-credential-v2/#adopted-problem-report","title":"Adopted Problem Report","text":"<p>The problem-report message is adopted by this protocol. <code>problem-report</code> messages can be used by either party to indicate an error in the protocol.</p>"},{"location":"aip2/0453-issue-credential-v2/#preview-credential","title":"Preview Credential","text":"<p>This is not a message but an inner object for other messages in this protocol. It is used construct a preview of the data for the credential that is to be issued. Its schema follows:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/credential-preview\",\n    \"attributes\": [\n        {\n            \"name\": \"&lt;attribute name&gt;\",\n            \"mime-type\": \"&lt;type&gt;\",\n            \"value\": \"&lt;value&gt;\"\n        },\n        // more attributes\n    ]\n}\n</code></pre> <p>The main element is <code>attributes</code>. It is an array of (object) attribute specifications; the subsections below outline their semantics.</p>"},{"location":"aip2/0453-issue-credential-v2/#attribute-name","title":"Attribute Name","text":"<p>The mandatory <code>\"name\"</code> key maps to the attribute name as a string.</p>"},{"location":"aip2/0453-issue-credential-v2/#mime-type-and-value","title":"MIME Type and Value","text":"<p>The optional <code>mime-type</code> advises the issuer how to render a binary attribute, to judge its content for applicability before issuing a credential containing it. Its value parses case-insensitively in keeping with MIME type semantics of RFC 2045. If <code>mime-type</code> is missing, its value is null.</p> <p>The mandatory <code>value</code> holds the attribute value:</p> <ul> <li>if <code>mime-type</code> is missing (null), then <code>value</code> is a string. In other words, implementations interpret it the same as any other key+value pair in JSON</li> <li>if <code>mime-type</code> is not null, then <code>value</code> is always a base64url-encoded string that represents a binary BLOB, and <code>mime-type</code> tells how to interpret the BLOB after base64url-decoding.</li> </ul>"},{"location":"aip2/0453-issue-credential-v2/#threading","title":"Threading","text":"<p>Threading can be used to initiate a sub-protocol during an issue credential protocol instance. For example, during credential issuance, the Issuer may initiate a child message thread to execute the <code>Present Proof</code> sub-protocol to have the potential Holder (now acting as a Prover) prove attributes about themselves before issuing the credential. Depending on circumstances, this might be a best practice for preventing credential fraud at issuance time.</p> <p>If threading were added to all of the above messages, a <code>~thread</code> decorator would be present, and later messages in the flow would reference the <code>@id</code> of earlier messages to stitch the flow into a single coherent sequence. Details about threading can be found in the 0008: Message ID and Threading RFC.</p>"},{"location":"aip2/0453-issue-credential-v2/#limitations","title":"Limitations","text":"<p>Smart contracts may be missed in ecosystem, so operation \"issue credential after payment received\" is not atomic. It\u2019s possible case that malicious issuer will charge first and then will not issue credential in fact. But this situation should be easily detected and appropriate penalty should be applied in such type of networks.</p>"},{"location":"aip2/0453-issue-credential-v2/#negotiation-and-preview","title":"Negotiation and Preview","text":"<p>Negotiation prior to issuing the credential can be done using the <code>offer-credential</code> and <code>propose-credential</code> messages. A common negotiation use case would be about the data to go into the credential. For that, the <code>credential_preview</code> element is used.</p>"},{"location":"aip2/0453-issue-credential-v2/#drawbacks","title":"Drawbacks","text":"<p>None documented</p>"},{"location":"aip2/0453-issue-credential-v2/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Attention should be paid by the Aries community to other credential issuance protocols being proposed/used in other communities to ensure this RFC could support those protocols.</li> <li>Digital Bazaar has proposed the Credential Handler API (CHAPI) protocol that is being considered by the W3C Credentials Community Group.</li> </ul>"},{"location":"aip2/0453-issue-credential-v2/#prior-art","title":"Prior art","text":"<p>See RFC 0036 Issue Credential, v1.x.</p>"},{"location":"aip2/0453-issue-credential-v2/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>We might need to propose a new MIME type for credential (the same way as .docx is not processed as generic xml). See this issue against the W3C/vc-data-model.</li> </ul>"},{"location":"aip2/0453-issue-credential-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0454-present-proof-v2/","title":"Aries RFC 0454: Present Proof Protocol 2.0","text":"<ul> <li>Authors: Nikita Khateev, Stephen Curran</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note:  See RFC 0453 for the corresponding issue credential protocol.</li> <li>Supersedes: RFC 0037</li> <li>Start Date: 2020-05-27</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"aip2/0454-present-proof-v2/#version-change-log","title":"Version Change Log","text":"<ul> <li>Version 2.0 is the current version</li> </ul> <p>For a period of time, versions 2.1 and 2.2 where defined in this RFC. Those definitions were added prior to any implementations, and to date, there are no known implementations available or planned. An attempt at implementing version 2.1 of the associated \"issue multiple credentials\" was not merged into the main branch of Aries Cloud Agent Python, deemed overly complicated and not worth the effort for what amounts to an edge case (presenting multiple presentations of the same type in a single protocol instance). Further, there is a version 3.0 of this protocol that has been specified and implemented that does not include these capabilities. Thus, a decision was made that versions 2.1 and 2.2 be removed as being not accepted by the community and overly complicated to both implement and migrate from. Those interested in seeing how those capabilities were specified can look at this protocol before they were removed.</p>"},{"location":"aip2/0454-present-proof-v2/#20-alignment-with-rfc-0453-issue-credential","title":"2.0 - Alignment with RFC 0453 Issue Credential","text":"<ul> <li>The \"formats\" field is added to all the messages to link the specific attachment IDs with the verifiable presentation format and version of the attachment.</li> <li>The details that are part of each message type about the different attachment formats serves as a registry of the known formats and versions.</li> <li>Version 2.0 uses &lt;angle brackets&gt; explicitly to mark all values that may vary between instances, such as identifiers and comments.</li> </ul>"},{"location":"aip2/0454-present-proof-v2/#summary","title":"Summary","text":"<p>A protocol supporting a general purpose verifiable presentation exchange regardless of the specifics of the underlying verifiable presentation request and verifiable presentation format.</p>"},{"location":"aip2/0454-present-proof-v2/#motivation","title":"Motivation","text":"<p>We need a standard protocol for a verifier to request a presentation from a prover, and for the prover to respond by presenting a proof to the verifier. When doing that exchange, we want to provide a mechanism for the participants to negotiate the underlying format and content of the proof.</p>"},{"location":"aip2/0454-present-proof-v2/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0454-present-proof-v2/#name-and-version","title":"Name and Version","text":"<p><code>present-proof</code>, version 2.0</p>"},{"location":"aip2/0454-present-proof-v2/#key-concepts","title":"Key Concepts","text":"<p>This protocol is about the messages to support the presentation of verifiable claims, not about the specifics of particular verifiable presentation formats. DIDComm attachments are deliberately used in messages to make the protocol agnostic to specific verifiable presentation format payloads. Links are provided in the message data element descriptions to details of specific verifiable presentation implementation data structures.</p> <p>Diagrams in this protocol were made in draw.io. To make changes:</p> <ul> <li>upload the drawing HTML from this folder to the draw.io site (Import From...GitHub),</li> <li>make changes,</li> <li>export the picture and HTML to your local copy of this repo, and</li> <li>submit a pull request.</li> </ul>"},{"location":"aip2/0454-present-proof-v2/#roles","title":"Roles","text":"<p>The roles are <code>verifier</code> and <code>prover</code>.  The <code>verifier</code> requests the presentation of a proof and verifies the presentation, while the <code>prover</code> prepares the proof and presents it to the verifier. Optionally, although unlikely from a business sense, the <code>prover</code> may initiate an instance of the protocol using the <code>propose-presentation</code> message.</p>"},{"location":"aip2/0454-present-proof-v2/#goals","title":"Goals","text":"<p>When the goals of each role are not available because of context, goal codes may be specifically included in protocol messages. This is particularly helpful to differentiate between credentials passed between the same parties for several different reasons. A goal code included should be considered to apply to the entire thread and is not necessary to be repeated on each message. Changing the goal code may be done by including the new code in a message. All goal codes are optional, and without default.</p>"},{"location":"aip2/0454-present-proof-v2/#states","title":"States","text":"<p>The following states are defined and included in the state transition table below.</p>"},{"location":"aip2/0454-present-proof-v2/#states-for-verifier","title":"States for Verifier","text":"<ul> <li>request-sent</li> <li>proposal-received</li> <li>presentation-received</li> <li>abandoned</li> <li>done</li> </ul>"},{"location":"aip2/0454-present-proof-v2/#states-for-prover","title":"States for Prover","text":"<ul> <li>request-received</li> <li>proposal-sent</li> <li>presentation-sent</li> <li>abandoned</li> <li>done</li> </ul> <p>For the most part, these states map onto the transitions shown in both the state transition table above, and in the choreography diagram (below) in obvious ways. However, a few subtleties are worth highlighting:</p> <ul> <li> <p>The final states for both the prover and verifier are <code>done</code> or <code>abandoned</code>, and once reached, no further updates to the protocol instance are expected.</p> </li> <li> <p>The <code>ack-presentation</code> is sent or not based on the value of <code>will_confirm</code> in the <code>request-presentation</code>. A verifier may send an <code>ack-presentation</code> message in response to the prover including the <code>~please_ack</code> decorator in the <code>presentation</code> message. Whether an <code>ack-presentation</code> is expected or not determines whether the states <code>presentation-sent</code> and <code>presentation-received</code> are used at all in a protocol instance.</p> </li> <li> <p>The <code>ack-presentation</code> message should reflect the business validation of the proof (does the proof satisfy the business need?) not just the cryptographic verification. Ideally, those are as tightly aligned as possible.</p> </li> <li> <p>When a Prover makes a (counter-)proposal, it transitions to the <code>proposal-sent</code> state. This state is only present by implication in the choreography diagram; it essentially equates to the null or begin state in that the Prover does nothing until a presentation request arrives, triggering the leftmost transition for the Prover.</p> </li> <li> <p>Errors might occur in various places. For example, a Prover might decide not to respond to a <code>presentation-request</code> or a verifier may time out waiting for the Prover to supply a <code>presentation</code>. Errors should trigger a <code>problem-report</code>. In this version of the protocol, all errors cause the state of both parties (the sender and the receiver of the <code>problem-report</code>) to transition to the terminal <code>abandoned</code> state (meaning it is no longer engaged in the protocol at all).</p> </li> </ul>"},{"location":"aip2/0454-present-proof-v2/#choreography-diagram","title":"Choreography Diagram","text":""},{"location":"aip2/0454-present-proof-v2/#messages","title":"Messages","text":"<p>The present proof protocol consists of these messages:</p> <ul> <li><code>propose-presentation</code> - Prover to Verifier (optional) - propose a presentation or send a counter-proposal in response to a <code>request-presentation</code> message</li> <li><code>request-presentation</code> - Verifier to Prover - request a presentation</li> <li><code>presentation</code> - Prover to Verifier - provide a presentation in response to a request</li> </ul> <p>In addition, the <code>ack</code> and <code>problem-report</code> messages are adopted into the protocol for confirmation and error handling.</p> <p>The messages that include <code>~attach</code> attachments may use any form of the embedded attachment. In the examples below, the forms of the attachment are arbitrary.</p> <p>The <code>~attach</code> array is to be used to enable a single presentation to be requested/delivered in different verifiable presentation formats. The ability to have multiple attachments must not be used to request/deliver multiple different presentations in a single instance of the protocol.</p>"},{"location":"aip2/0454-present-proof-v2/#propose-presentation","title":"Propose Presentation","text":"<p>An optional message sent by the prover to the verifier to initiate a proof presentation process, or in response to a <code>request-presentation</code> message when the prover wants to propose using a different presentation format or request. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/propose-presentation\",\n    \"@id\": \"&lt;uuid-propose-presentation&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"some comment\",\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"proposals~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"json\": \"&lt;json&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>comment</code> -- a field that provides some human readable information about the proposed presentation.</li> <li><code>formats</code> -- contains an entry for each <code>filter~attach</code> array entry, including an optional value of the attachment <code>@id</code> (if attachments are present) and the verifiable presentation format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>proposals~attach</code> -- an optional array of attachments that further define the presentation request being proposed. This might be used to clarify which formats or format versions are wanted.</li> </ul> <p>If the <code>proposals~attach</code> is not provided, the <code>attach_id</code> item in the <code>formats</code> array should not be provided. That form of the <code>propose-presentation</code> message is to indicate the presentation formats supported by the prover, independent of the verifiable presentation request content.</p>"},{"location":"aip2/0454-present-proof-v2/#negotiation-and-preview","title":"Negotiation and Preview","text":"<p>Negotiation prior to the delivery of the presentation can be done using the <code>propose-presentation</code> and <code>request-presentation</code> messages. The common negotiation use cases would be about the claims to go into the presentation and the format of the verifiable presentation.</p>"},{"location":"aip2/0454-present-proof-v2/#propose-attachment-registry","title":"Propose Attachment Registry","text":"Presentation Format Format Value Link to Attachment Format Comment Hyperledger Indy Proof Req <code>hlindy/proof-req@v2.0</code> proof request format Used to propose as well as request proofs. DIF Presentation Exchange <code>dif/presentation-exchange/definitions@v1.0</code> <code>propose-presentation</code> attachment format Hyperledger AnonCreds Proof Request <code>anoncreds/proof-request@v1.0</code> <code>Proof Request</code> format Used to propose as well as request proofs."},{"location":"aip2/0454-present-proof-v2/#request-presentation","title":"Request Presentation","text":"<p>From a verifier to a prover, the <code>request-presentation</code> message describes values that need to be revealed and predicates that need to be fulfilled. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/request-presentation\",\n    \"@id\": \"&lt;uuid-request&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"some comment\",\n    \"will_confirm\": true,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"request_presentations~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;base64 data&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>comment</code> -- a field that provides some human readable information about this request for a presentation.</li> <li><code>will_confirm</code> -- an optional field that defaults to <code>false</code> to indicate that the verifier will or will not send a post-presentation confirmation <code>ack</code> message</li> <li><code>formats</code> -- contains an entry for each <code>request_presentations~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable presentation request format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format Attachment registry immediately below.</li> <li><code>request_presentations~attach</code> -- an array of attachments containing the acceptable verifiable presentation requests.</li> </ul>"},{"location":"aip2/0454-present-proof-v2/#presentation-request-attachment-registry","title":"Presentation Request Attachment Registry","text":"Presentation Format Format Value Link to Attachment Format Comment Hyperledger Indy Proof Req <code>hlindy/proof-req@v2.0</code> proof request format Used to propose as well as request proofs. DIF Presentation Exchange <code>dif/presentation-exchange/definitions@v1.0</code> <code>propose-presentation</code> attachment format Hyperledger AnonCreds Proof Request <code>anoncreds/proof-request@v1.0</code> <code>Proof Request</code> format Used to propose as well as request proofs."},{"location":"aip2/0454-present-proof-v2/#presentation","title":"Presentation","text":"<p>This message is a response to a Presentation Request message and contains signed presentations. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/presentation\",\n    \"@id\": \"&lt;uuid-presentation&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"some comment\",\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"presentations~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"sha256\": \"f8dca1d901d18c802e6a8ce1956d4b0d17f03d9dc5e4e1f618b6a022153ef373\",\n                \"links\": [\"https://ibb.co/TtgKkZY\"]\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>comment</code> -- a field that provides some human readable information about this presentation.</li> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>formats</code> -- contains an entry for each <code>presentations~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable presentation format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format Attachment registry immediately below.</li> <li><code>presentations~attach</code> -- an array of attachments containing the presentation in the requested format(s).</li> </ul> <p>If the prover wants an acknowledgement that the presentation was accepted, this message may be decorated with the <code>~please-ack</code> decorator using the <code>OUTCOME</code> acknowledgement request. This is not necessary if the verifier has indicated it will send an <code>ack-presentation</code> using the <code>will_confirm</code> property. Outcome in the context of this protocol is the definition of \"successful\" as described in Ack Presentation. Note that this is different from the default behavior as described in 0317: Please ACK Decorator. It is then best practice for the new Verifier to respond with an explicit <code>ack</code> message as described in the please ack decorator RFC.</p>"},{"location":"aip2/0454-present-proof-v2/#presentations-attachment-registry","title":"Presentations Attachment Registry","text":"Presentation Format Format Value Link to Attachment Format Comment Hyperledger Indy Proof <code>hlindy/proof@v2.0</code> proof format DIF Presentation Exchange <code>dif/presentation-exchange/submission@v1.0</code> <code>propose-presentation</code> attachment format Hyperledger AnonCreds Proof <code>anoncreds/proof@v1.0</code> <code>Proof</code> format"},{"location":"aip2/0454-present-proof-v2/#ack-presentation","title":"Ack Presentation","text":"<p>A message from the verifier to the prover that the <code>Present Proof</code> protocol was completed successfully and is now in the <code>done</code> state. The message is an adopted <code>ack</code> from the RFC 0015 acks protocol. The definition of \"successful\" in this protocol means the acceptance of the presentation in whole, i.e. the proof is verified and the contents of the proof are acknowledged.</p>"},{"location":"aip2/0454-present-proof-v2/#problem-report","title":"Problem Report","text":"<p>A message from the verifier to the prover that follows the <code>presentation</code> message to indicate that the <code>Present Proof</code> protocol was completed unsuccessfully and is now in the <code>abandoned</code> state. The message is an adopted <code>problem-report</code> from the RFC 0015 report-problem protocol. The definition of \"unsuccessful\" from a business sense is up to the verifier. The elements of the <code>problem-report</code> message can provide information to the prover about why the protocol instance was unsuccessful.</p> <p>Either party may send a <code>problem-report</code> message earlier in the flow to terminate the protocol before its normal conclusion.</p>"},{"location":"aip2/0454-present-proof-v2/#reference","title":"Reference","text":"<p>Details are covered in the Tutorial section.</p>"},{"location":"aip2/0454-present-proof-v2/#drawbacks","title":"Drawbacks","text":"<p>The Indy format of the proposal attachment as proposed above does not allow nesting of logic along the lines of \"A and either B or C if D, otherwise A and B\", nor cross-credential options such as proposing a legal name issued by either (for example) a specific financial institution or government entity.</p> <p>The verifiable presentation standardization work being conducted in parallel to this in DIF and the W3C Credentials Community Group (CCG) should be included in at least the <code>Registry</code> tables of this document, and ideally used to eliminate the need for presentation format-specific options.</p>"},{"location":"aip2/0454-present-proof-v2/#rationale-and-alternatives","title":"Rationale and alternatives","text":""},{"location":"aip2/0454-present-proof-v2/#prior-art","title":"Prior art","text":"<p>The previous major version of this protocol is RFC 0037 Present Proof protocol and implementations.</p>"},{"location":"aip2/0454-present-proof-v2/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>There might need to be a way to associate a payment with the present proof protocol.</li> </ul>"},{"location":"aip2/0454-present-proof-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0510-dif-pres-exch-attach/","title":"Aries RFC 0510: Presentation-Exchange Attachment format for requesting and presenting proofs","text":"<ul> <li>Authors: George Aristy (SecureKey Technologies)</li> <li>Status: ADOPTED</li> <li>Since: 2020-07-21</li> <li>Status Note:  </li> <li>Supersedes: </li> <li>Start Date: 2020-07-21</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"aip2/0510-dif-pres-exch-attach/#summary","title":"Summary","text":"<p>This RFC registers three attachment formats for use in the present-proof V2 protocol based on the Decentralized Identity Foundation's (DIF) Presentation Exchange specification (P-E). Two of these formats define containers for a presentation-exchange request object and another options object carrying additional parameters, while the third format is just a vessel for the final <code>presentation_submission</code> verifiable presentation transferred from the Prover to the Verifier.</p> <p>Presentation Exchange defines a data format capable of articulating a rich set of proof requirements from Verifiers, and also provides a means of describing the formats in which Provers must submit those proofs.</p> <p>A Verifier's defines their requirements in a <code>presentation_definition</code> containing <code>input_descriptors</code> that describe the credential(s) the proof(s) must be derived from as well as a rich set of operators that place <code>constraints</code> on those proofs (eg. \"must be issued from issuer X\" or \"<code>age</code> over X\", etc.).</p> <p>The Verifiable Presentation format of Presentation Submissions is used as opposed to OIDC tokens or CHAPI objects. For an alternative on how to tunnel OIDC messages over DIDComm, see HTTP-Over-DIDComm. CHAPI is an alternative transport to DIDComm.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#motivation","title":"Motivation","text":"<p>The Presentation Exchange specification (P-E) possesses a rich language for expressing a Verifier's criterion.</p> <p>P-E lends itself well to several transport mediums due to its limited scope as a data format, and is easily transported over DIDComm.</p> <p>It is furthermore desirable to make use of specifications developed in an open standards body.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#tutorial","title":"Tutorial","text":"<p>Complete examples of messages are provided in the reference section.</p> <p>The Verifier sends a <code>request-presentation</code> to the Prover containing a <code>presentation_definition</code>, along with a <code>domain</code> and <code>challenge</code> the Prover must sign over in the proof.</p> <p>The Prover can optionally respond to the Verifier's <code>request-presentation</code> with a <code>propose-presentation</code> message containing \"Input Descriptors\" that describe the proofs they can provide. The contents of the attachment is just the <code>input_descriptors</code> attribute of the <code>presentation_definition</code> object.</p> <p>The Prover responds with a <code>presentation</code> message containing a <code>presentation_submission</code>.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#reference","title":"Reference","text":""},{"location":"aip2/0510-dif-pres-exch-attach/#propose-presentation-attachment-format","title":"<code>propose-presentation</code> attachment format","text":"<p>Format identifier: <code>dif/presentation-exchange/definitions@v1.0</code></p>"},{"location":"aip2/0510-dif-pres-exch-attach/#examples-propose-presentation","title":"Examples: propose-presentation","text":"Complete message example <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/propose-presentation\",\n    \"@id\": \"fce30ed1-96f8-44c9-95cf-b274288009dc\",\n    \"comment\": \"some comment\",\n    \"formats\" : [{\n        \"attach_id\" : \"143c458d-1b1c-40c7-ab85-4d16808ddf0a\",\n        \"format\" : \"dif/presentation-exchange/definitions@v1.0\"\n    }],\n    \"proposal~attach\": [{\n        \"@id\": \"143c458d-1b1c-40c7-ab85-4d16808ddf0a\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"json\": {\n                \"input_descriptors\": [{\n                    \"id\": \"citizenship_input\",\n                    \"name\": \"US Passport\",\n                    \"group\": [\"A\"],\n                    \"schema\": [{\n                        \"uri\": \"hub://did:foo:123/Collections/schema.us.gov/passport.json\"\n                    }],\n                    \"constraints\": {\n                        \"fields\": [{\n                            \"path\": [\"$.credentialSubject.birth_date\", \"$.vc.credentialSubject.birth_date\", \"$.birth_date\"],\n                            \"filter\": {\n                                \"type\": \"date\",\n                                \"minimum\": \"1999-5-16\"\n                            }\n                        }]\n                    }\n                }]\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"aip2/0510-dif-pres-exch-attach/#request-presentation-attachment-format","title":"<code>request-presentation</code> attachment format","text":"<p>Format identifier: <code>dif/presentation-exchange/definitions@v1.0</code></p> <p>Since the format identifier defined above is the same as the one used in the <code>propose-presentation</code> message, it's recommended to consider both the message <code>@type</code> and the <code>format</code> to accuarately understand the contents of the attachment.</p> <p>The contents of the attachment is a JSON object containing the Verifier's presentation definition and an options object with proof options:</p> <pre><code>{\n    \"options\": {\n        \"challenge\": \"...\",\n        \"domain\": \"...\",\n    },\n    \"presentation_definition\": {\n        // presentation definition object\n    }\n}\n</code></pre>"},{"location":"aip2/0510-dif-pres-exch-attach/#the-options-object","title":"The options object","text":"<p>options is a container of additional parameters required for the Prover to fulfill the Verifier's request.</p> <p>Available options are:</p> Name Status Description <code>challenge</code> RECOMMENDED (for LD proofs) Random seed provided by the Verifier for LD Proofs. <code>domain</code> RECOMMENDED (for LD proofs) The operational domain of the requested LD proof."},{"location":"aip2/0510-dif-pres-exch-attach/#examples-request-presentation","title":"Examples: request-presentation","text":"Complete message example requesting a verifiable presentation with proof type Ed25519Signature2018 <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/request-presentation\",\n    \"@id\": \"0ac534c8-98ed-4fe3-8a41-3600775e1e92\",\n    \"comment\": \"some comment\",\n    \"formats\" : [{\n        \"attach_id\" : \"ed7d9b1f-9eed-4bde-b81c-3aa7485cf947\",\n        \"format\" : \"dif/presentation-exchange/definitions@v1.0\"\n    }],\n    \"request_presentations~attach\": [{\n        \"@id\": \"ed7d9b1f-9eed-4bde-b81c-3aa7485cf947\",\n        \"mime-type\": \"application/json\",\n        \"data\":  {\n            \"json\": {\n                \"options\": {\n                    \"challenge\": \"23516943-1d79-4ebd-8981-623f036365ef\",\n                    \"domain\": \"us.gov/DriversLicense\"\n                },\n                \"presentation_definition\": {\n                    \"input_descriptors\": [{\n                        \"id\": \"citizenship_input\",\n                        \"name\": \"US Passport\",\n                        \"group\": [\"A\"],\n                        \"schema\": [{\n                            \"uri\": \"hub://did:foo:123/Collections/schema.us.gov/passport.json\"\n                        }],\n                        \"constraints\": {\n                            \"fields\": [{\n                                \"path\": [\"$.credentialSubject.birth_date\", \"$.birth_date\"],\n                                \"filter\": {\n                                    \"type\": \"date\",\n                                    \"minimum\": \"1999-5-16\"\n                                }\n                            }]\n                        }\n                    }],\n                    \"format\": {\n                        \"ldp_vp\": {\n                            \"proof_type\": [\"Ed25519Signature2018\"]\n                        }\n                    }\n                }\n            }\n        }\n    }]\n}\n</code></pre> The same example but requesting the verifiable presentation with proof type BbsBlsSignatureProof2020 instead <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/request-presentation\",\n    \"@id\": \"0ac534c8-98ed-4fe3-8a41-3600775e1e92\",\n    \"comment\": \"some comment\",\n    \"formats\" : [{\n        \"attach_id\" : \"ed7d9b1f-9eed-4bde-b81c-3aa7485cf947\",\n        \"format\" : \"dif/presentation-exchange/definitions@v1.0\"\n    }],\n    \"request_presentations~attach\": [{\n        \"@id\": \"ed7d9b1f-9eed-4bde-b81c-3aa7485cf947\",\n        \"mime-type\": \"application/json\",\n        \"data\":  {\n            \"json\": {\n                \"options\": {\n                    \"challenge\": \"23516943-1d79-4ebd-8981-623f036365ef\",\n                    \"domain\": \"us.gov/DriversLicense\"\n                },\n                \"presentation_definition\": {\n                    \"input_descriptors\": [{\n                        \"id\": \"citizenship_input\",\n                        \"name\": \"US Passport\",\n                        \"group\": [\"A\"],\n                        \"schema\": [{\n                            \"uri\": \"hub://did:foo:123/Collections/schema.us.gov/passport.json\"\n                        }],\n                        \"constraints\": {\n                            \"fields\": [{\n                                \"path\": [\"$.credentialSubject.birth_date\", \"$.vc.credentialSubject.birth_date\", \"$.birth_date\"],\n                                \"filter\": {\n                                    \"type\": \"date\",\n                                    \"minimum\": \"1999-5-16\"\n                                }\n                            }],\n                            \"limit_disclosure\": \"required\"\n                        }\n                    }],\n                    \"format\": {\n                        \"ldp_vc\": {\n                            \"proof_type\": [\"BbsBlsSignatureProof2020\"]\n                        }\n                    }\n                }\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"aip2/0510-dif-pres-exch-attach/#presentation-attachment-format","title":"<code>presentation</code> attachment format","text":"<p>Format identifier: <code>dif/presentation-exchange/submission@v1.0</code></p> <p>The contents of the attachment is a Presentation Submission in a standard Verifiable Presentation format containing the proofs requested.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#examples-presentation","title":"Examples: presentation","text":"Complete message example <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/presentation\",\n    \"@id\": \"f1ca8245-ab2d-4d9c-8d7d-94bf310314ef\",\n    \"comment\": \"some comment\",\n    \"formats\" : [{\n        \"attach_id\" : \"2a3f1c4c-623c-44e6-b159-179048c51260\",\n        \"format\" : \"dif/presentation-exchange/submission@v1.0\"\n    }],\n    \"presentations~attach\": [{\n        \"@id\": \"2a3f1c4c-623c-44e6-b159-179048c51260\",\n        \"mime-type\": \"application/ld+json\",\n        \"data\": {\n            \"json\": {\n                \"@context\": [\n                    \"https://www.w3.org/2018/credentials/v1\",\n                    \"https://identity.foundation/presentation-exchange/submission/v1\"\n                ],\n                \"type\": [\n                    \"VerifiablePresentation\",\n                    \"PresentationSubmission\"\n                ],\n                \"presentation_submission\": {\n                    \"descriptor_map\": [{\n                        \"id\": \"citizenship_input\",\n                        \"path\": \"$.verifiableCredential.[0]\"\n                    }]\n                },\n                \"verifiableCredential\": [{\n                    \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n                    \"id\": \"https://eu.com/claims/DriversLicense\",\n                    \"type\": [\"EUDriversLicense\"],\n                    \"issuer\": \"did:foo:123\",\n                    \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n                    \"credentialSubject\": {\n                        \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n                        \"license\": {\n                            \"number\": \"34DGE352\",\n                            \"dob\": \"07/13/80\"\n                        }\n                    },\n                    \"proof\": {\n                        \"type\": \"RsaSignature2018\",\n                        \"created\": \"2017-06-18T21:19:10Z\",\n                        \"proofPurpose\": \"assertionMethod\",\n                        \"verificationMethod\": \"https://example.edu/issuers/keys/1\",\n                        \"jws\": \"...\"\n                    }\n                }],\n                \"proof\": {\n                    \"type\": \"RsaSignature2018\",\n                    \"created\": \"2018-09-14T21:19:10Z\",\n                    \"proofPurpose\": \"authentication\",\n                    \"verificationMethod\": \"did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1\",\n                    \"challenge\": \"1f44d55f-f161-4938-a659-f8026467f126\",\n                    \"domain\": \"4jt78h47fh47\",\n                    \"jws\": \"...\"\n                }\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"aip2/0510-dif-pres-exch-attach/#supported-features-of-presentation-exchange","title":"Supported Features of Presentation-Exchange","text":"<p>Level of support for Presentation-Exchange ../../features:</p> Feature Notes <code>presentation_definition.input_descriptors.id</code> <code>presentation_definition.input_descriptors.name</code> <code>presentation_definition.input_descriptors.purpose</code> <code>presentation_definition.input_descriptors.schema.uri</code> URI for the credential's schema. <code>presentation_definition.input_descriptors.constraints.fields.path</code> Array of JSONPath string expressions as defined in section 8. REQUIRED as per the spec. <code>presentation_definition.input_descriptors.constraints.fields.filter</code> JSONSchema descriptor. <code>presentation_definition.input_descriptors.constraints.limit_disclosure</code> <code>preferred</code> or <code>required</code> as defined in the spec and as supported by the Holder and Verifier proof mechanisms.Note that the Holder MUST have credentials with cryptographic proof suites that are capable of selective disclosure in order to respond to a request with <code>limit_disclosure: \"required\"</code>.See RFC0593 for appropriate crypto suites. <code>presentation_definition.input_descriptors.constraints.is_holder</code> <code>preferred</code> or <code>required</code> as defined in the spec.Note that this feature allows the Holder to present credentials with a different subject identifier than the DID used to establish the DIDComm connection with the Verifier. <code>presentation_definition.format</code> For JSONLD-based credentials: <code>ldp_vc</code> and <code>ldp_vp</code>. <code>presentation_definition.format.proof_type</code> For JSONLD-based credentials: <code>Ed25519Signature2018</code>, <code>BbsBlsSignature2020</code>, and <code>JsonWebSignature2020</code>. When specifying <code>ldp_vc</code>, <code>BbsBlsSignatureProof2020</code> may also be used."},{"location":"aip2/0510-dif-pres-exch-attach/#proof-formats","title":"Proof Formats","text":""},{"location":"aip2/0510-dif-pres-exch-attach/#constraints","title":"Constraints","text":"<p>Verifiable Presentations MUST be produced and consumed using the JSON-LD syntax.</p> <p>The proof types defined below MUST be registered in the Linked Data Cryptographic Suite Registry.</p> <p>The value of any <code>credentialSubject.id</code> in a credential MUST be a Dentralized Identifier (DID) conforming to the DID Syntax if present. This allows the Holder to authenticate as the credential's subject if required by the Verifier (see the <code>is_holder</code> property above). The Holder authenticates as the credential's subject by attaching an LD Proof on the enclosing Verifiable Presentation.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#proof-formats-on-credentials","title":"Proof Formats on Credentials","text":"<p>Aries agents implementing this RFC MUST support the formats outlined in RFC0593 for proofs on Verifiable Credentials.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#proof-formats-on-presentations","title":"Proof Formats on Presentations","text":"<p>Aries agents implementing this RFC MUST support the formats outlined below for proofs on Verifiable Presentations.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#ed25519signature2018","title":"Ed25519Signature2018","text":"<p>Specification.</p> <p>Request Parameters:</p> <ul> <li><code>presentation_definition.format</code>: <code>ldp_vp</code></li> <li><code>presentation_definition.format.proof_type</code>: <code>Ed25519Signature2018</code></li> <li><code>options.challenge</code>: (Optional) a random string value generated by the Verifier</li> <li><code>options.domain</code>: (Optional) a string value specified set by the Verifier</li> </ul> <p>Result:</p> <p>A Verifiable Presentation of type Presentation Submission containing the credentials requested under the <code>verifiableCredential</code> property and a <code>proof</code> property of type <code>Ed25519Signature2018</code>.</p> Example <pre><code>{\n    \"@context\": [\n        \"https://www.w3.org/2018/credentials/v1\",\n        \"https://identity.foundation/presentation-exchange/submission/v1\"\n    ],\n    \"type\": [\n        \"VerifiablePresentation\",\n        \"PresentationSubmission\"\n    ],\n    \"presentation_submission\": {\n        \"descriptor_map\": [{\n           \"id\": \"citizenship_input\",\n           \"path\": \"$.verifiableCredential.[0]\"\n        }]\n    },\n    \"verifiableCredential\": [{\n        \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n        \"id\": \"https://eu.com/claims/DriversLicense\",\n        \"type\": [\n            \"EUDriversLicense\"\n        ],\n        \"issuer\": \"did:foo:123\",\n        \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n        \"credentialSubject\": {\n            \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n            \"license\": {\n            \"number\": \"34DGE352\",\n            \"dob\": \"07/13/80\"\n          }\n        },\n        \"proof\": {\n            \"type\": \"RsaSignature2018\",\n            \"created\": \"2017-06-18T21:19:10Z\",\n            \"proofPurpose\": \"assertionMethod\",\n            \"verificationMethod\": \"https://example.edu/issuers/keys/1\",\n            \"jws\": \"...\"\n        }\n    }],\n    \"proof\": {\n      \"type\": \"Ed25519Signature2018\",\n      \"proofPurpose\": \"authentication\",\n      \"created\": \"2017-09-23T20:21:34Z\",\n      \"verificationMethod\": \"did:example:123456#key1\",\n      \"challenge\": \"2bbgh3dgjg2302d-d2b3gi423d42\",\n      \"domain\": \"example.org\",\n      \"jws\": \"eyJ0eXAiOiJK...gFWFOEjXk\"\n  }\n}\n</code></pre>"},{"location":"aip2/0510-dif-pres-exch-attach/#bbsblssignature2020","title":"BbsBlsSignature2020","text":"<p>Specification.</p> <p>Associated RFC: RFC0646.</p> <p>Request Parameters: * <code>presentation_definition.format</code>: <code>ldp_vp</code> * <code>presentation_definition.format.proof_type</code>: <code>BbsBlsSignature2020</code> * <code>options.challenge</code>: (Optional) a random string value generated by the Verifier * <code>options.domain</code>: (Optional) a string value specified set by the Verifier</p> <p>Result:</p> <p>A Verifiable Presentation of type Presentation Submission containing the credentials requested under the <code>verifiableCredential</code> property and a <code>proof</code> property of type <code>BbsBlsSignature2020</code>.</p> Example <pre><code>{\n    \"@context\": [\n        \"https://www.w3.org/2018/credentials/v1\",\n        \"https://w3id.org/security/v2\",\n        \"https://w3id.org/security/bbs/v1\",\n        \"https://identity.foundation/presentation-exchange/submission/v1\"\n    ],\n    \"type\": [\n        \"VerifiablePresentation\",\n        \"PresentationSubmission\"\n    ],\n    \"presentation_submission\": {\n        \"descriptor_map\": [{\n            \"id\": \"citizenship_input\",\n            \"path\": \"$.verifiableCredential.[0]\"\n        }]\n    },\n    \"verifiableCredential\": [{\n        \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n        \"id\": \"https://eu.com/claims/DriversLicense\",\n        \"type\": [\"EUDriversLicense\"],\n        \"issuer\": \"did:foo:123\",\n        \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n        \"credentialSubject\": {\n            \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n            \"license\": {\n                \"number\": \"34DGE352\",\n                \"dob\": \"07/13/80\"\n            }\n       },\n       \"proof\": {\n           \"type\": \"BbsBlsSignatureProof2020\",\n           \"created\": \"2020-04-25\",\n           \"verificationMethod\": \"did:example:489398593#test\",\n           \"proofPurpose\": \"assertionMethod\",\n           \"signature\": \"F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg==\"\n       }\n    }],\n    \"proof\": {\n        \"type\": \"BbsBlsSignature2020\",\n        \"created\": \"2020-04-25\",\n        \"verificationMethod\": \"did:example:489398593#test\",\n        \"proofPurpose\": \"authentication\",\n        \"proofValue\": \"F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg==\",\n        \"requiredRevealStatements\": [ 4, 5 ]\n    }\n}\n</code></pre> <p>Note: The above example is for illustrative purposes. In particular, note that whether a Verifier requests a <code>proof_type</code> of <code>BbsBlsSignature2020</code> has no bearing on whether the Holder is required to present credentials with proofs of type <code>BbsBlsSignatureProof2020</code>. The choice of proof types on the credentials is constrained by a) the available types registered in RFC0593 and b) additional constraints placed on them due to other aspects of the proof requested by the Verifier, such as requiring limited disclosure with the <code>limit_disclosure</code> property. In such a case, a proof type of <code>Ed25519Signature2018</code> in the credentials is not appropriate whereas <code>BbsBlsSignatureProof2020</code> is capable of selective disclosure.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#jsonwebsignature2020","title":"JsonWebSignature2020","text":"<p>Specification.</p> <p>Request Parameters:</p> <ul> <li><code>presentation_definition.format</code>: <code>ldp_vp</code></li> <li><code>presentation_definition.format.proof_type</code>: <code>JsonWebSignature2020</code></li> <li><code>options.challenge</code>: (Optional) a random string value generated by the Verifier</li> <li><code>options.domain</code>: (Optional) a string value specified set by the Verifier</li> </ul> <p>Result:</p> <p>A Verifiable Presentation of type Presentation Submission containing the credentials requested under the <code>verifiableCredential</code> property and a <code>proof</code> property of type <code>JsonWebSignature2020</code>.</p> Example <pre><code>{\n    \"@context\": [\n        \"https://www.w3.org/2018/credentials/v1\",\n        \"https://identity.foundation/presentation-exchange/submission/v1\"\n    ],\n    \"type\": [\n        \"VerifiablePresentation\",\n        \"PresentationSubmission\"\n    ],\n    \"presentation_submission\": {\n        \"descriptor_map\": [{\n           \"id\": \"citizenship_input\",\n           \"path\": \"$.verifiableCredential.[0]\"\n        }]\n    },\n    \"verifiableCredential\": [{\n        \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n        \"id\": \"https://eu.com/claims/DriversLicense\",\n        \"type\": [\n            \"EUDriversLicense\"\n        ],\n        \"issuer\": \"did:foo:123\",\n        \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n        \"credentialSubject\": {\n            \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n            \"license\": {\n            \"number\": \"34DGE352\",\n            \"dob\": \"07/13/80\"\n          }\n        },\n        \"proof\": {\n            \"type\": \"RsaSignature2018\",\n            \"created\": \"2017-06-18T21:19:10Z\",\n            \"proofPurpose\": \"assertionMethod\",\n            \"verificationMethod\": \"https://example.edu/issuers/keys/1\",\n            \"jws\": \"...\"\n        }\n    }],\n    \"proof\": {\n      \"type\": \"JsonWebSignature2020\",\n      \"proofPurpose\": \"authentication\",\n      \"created\": \"2017-09-23T20:21:34Z\",\n      \"verificationMethod\": \"did:example:123456#key1\",\n      \"challenge\": \"2bbgh3dgjg2302d-d2b3gi423d42\",\n      \"domain\": \"example.org\",\n      \"jws\": \"eyJ0eXAiOiJK...gFWFOEjXk\"\n  }\n}\n</code></pre> <p>Available JOSE key types are:</p> kty crv signature EC P-256 ES256 EC P-384 ES384"},{"location":"aip2/0510-dif-pres-exch-attach/#drawbacks","title":"Drawbacks","text":"<p>N/A</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>The <code>hlindy-zkp-v1.0</code> format is an alternative restricted to the Hyperledger Indy network.</li> </ul>"},{"location":"aip2/0510-dif-pres-exch-attach/#prior-art","title":"Prior art","text":"<ul> <li>OAuth 2.0 Rich Authorization Requests:   Provides a coarse object structure that implementers must extend to support their needs. Presentation Exchange   provides a rich set of operators out of the box.</li> </ul>"},{"location":"aip2/0510-dif-pres-exch-attach/#unresolved-questions","title":"Unresolved questions","text":"<p>TODO it is assumed the Verifier will initiate the protocol if they can transmit their presentation definition via an out-of-band channel  (eg. it is published on their website) with a <code>request-presentation</code> message, possibly delivered via an Out-of-Band invitation  (see RFC0434). For now, the Prover sends <code>propose-presentation</code> as a response to <code>request-presentation</code>.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0519-goal-codes/","title":"0519: Goal Codes","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Used in several protocols that are part of AIP 2.0, such as the Out-of-Band protocol.</li> <li>Start Date: 2020-01-01</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0519-goal-codes/#summary","title":"Summary","text":"<p>Explain how different parties in an SSI ecosystem can communicate about their intentions in a way that is understandable by humans and by automated software.</p>"},{"location":"aip2/0519-goal-codes/#motivation","title":"Motivation","text":"<p>Agents exist to achieve the intents of their owners. Those intents largely unfold through protocols. Sometimes intelligent action in these protocols depends on a party declaring their intent. We need a standard way to do that.</p>"},{"location":"aip2/0519-goal-codes/#tutorial","title":"Tutorial","text":"<p>Our early learnings in SSI focused on VC-based proving with a very loose, casual approach to context. We did demos where Alice connects with a potential employer, Acme Corp -- and we assumed that each of the interacting parties had a shared understanding of one another's needs and purposes.</p> <p>But in a mature SSI ecosystem, where unknown agents can contact one another for arbitrary reasons, this context is not always easy to deduce. Acme Corp's agent may support many different protocols, and Alice may interact with Acme in the capacity of customer or potential employee or vendor. Although we have feature discovery to learn what's possible, and we have machine-readable governance frameworks to tell us what rules might apply in a given context, we haven't had a way to establish the context in the first place. When Alice contacts Acme, a context is needed before a governance framework is selectable, and before we know which ../../features are desirable.</p> <p>The key ingredient in context is intent. If Alice says to Acme, \"I'd like to connect,\", Acme wants to be able to trigger different behavior depending on whether Alice's intent is to be a customer, apply for a job, or audit Acme's taxes. This is the purpose of a goal code.</p>"},{"location":"aip2/0519-goal-codes/#the-goal-code-datatype","title":"The goal code datatype","text":"<p>To express intent, this RFC formally introduces the goal code datatype. When a field in a DIDComm message contains a goal code, its semantics and format match the description given here. (Goal codes are often declared via the <code>~thread</code> decorator, but may also appear in ordinary message fields. See the Scope section below. Convention is to name this field \"goal_code\" where possible; however, this is only a convention, and individual protocols may adapt to it however they wish.)</p> <p>TODO: should we make a decorator out of this, so protocols don't have to declare it, and so any message can have a goal code? Or should we just let protocols declare a field in whatever message makes sense?</p> <p>Protocols use fields of this type as a way to express the intent of the message sender, thus coloring the larger context. In a sense, goal codes are to DIDComm what the <code>subject:</code> field is to email -- except that goal codes have formalized meanings to make them recognizable to automation.</p> <p>Goal codes use a standard format. They are lower-cased, kebab-punctuated strings. ASCII and English are recommended, as they are intended to be read by the software developer community, not by human beings; however, full UTF-8 is allowed. They support hierarchical dotted notation, where more general categories are to the left of a dot, and more specific categories are to the right. Some example goal codes might be:</p> <ul> <li><code>aries.sell.consumer.fitness</code></li> <li><code>meetupcorp.personal.date</code></li> <li><code>dif.employment.check-references</code></li> <li><code>cci.healthcare.arrange</code></li> </ul> <p>Goals are inherently self-attested. Thus, goal codes don't represent objective fact that a recipient can rely upon in a strong sense; subsequent interactions can always yield surprises. Even so, goal codes let agents triage interactions and find misalignments early; there's no point in engaging if their goals are incompatible. This has significant benefits for spam prevention, among other things.</p>"},{"location":"aip2/0519-goal-codes/#verbs","title":"Verbs","text":"<p>Notice the verbs in the examples: <code>sell</code>, <code>date</code>, <code>hire</code>, and <code>arrange</code>. Goals typically involve action; a complete goal code should have one or more verbs in it somewhere. Turning verbs into nouns (e.g., <code>employment.references</code> instead of <code>employment.check-references</code>) is considered bad form. (Some namespaces may put the verbs at the end; some may put them in the middle. That's a purely stylistic choice.)</p>"},{"location":"aip2/0519-goal-codes/#directionality","title":"Directionality","text":"<p>Notice, too, that the verbs may imply directionality. A goal with the <code>sell</code> verb implies that the person announcing the goal is a would-be seller, not a buyer. We could imagine a more general verb like <code>engage-in-commerce</code> that would allow either behavior. However, that would often be a mistake. The value of goal codes is that they let agents align around intent; announcing that you want to engage in general commerce without clarifying whether you intend to sell or buy may be too vague to help the other party make decisions. </p> <p>It is conceivable that this would lead to parallel branchs of a goal ontology that differ only in the direction of their verb. Thus, we could imagine <code>sell.A</code> and <code>sell.B</code> being shadowed by <code>buy.A</code> and <code>buy.B</code>. This might be necessary if a family of protocols allow either party to initiate an interaction and declare the goal, and if both parties view the goals as perfect mirror images. However, practical considerations may make this kind of parallelism unlikely. A random party contacting an individual to sell something may need to be quite clear about the type of selling they intend, to make it past a spam filter. In contrast, a random individual arriving at the digital storefront of a mega retailer may be quite vague about the type of buying they intend. Thus, the <code>buy.*</code> side of the namespace may need much less detail than the <code>sell.*</code> side.</p>"},{"location":"aip2/0519-goal-codes/#goals-for-others","title":"Goals for others","text":"<p>Related to directionality, it may occasionally be desirable to propose goals to others, rather than adovcating your own: \"Let &lt;parties = us = Alice, Bob, and Carol&gt; &lt;goal = hold an auction&gt; -- I nominate Carol to be the &lt;role = auctioneer&gt; and get us started.\" The difference between a normal message and an unusual one like this is not visible in the goal code; it should be exposed in additional fields that associate the goal with a particular identifier+role pair. Essentially, you are proposing a goal to another party, and these extra fields clarify who should receive the proposal, and what role/perspective they might take with respect to the goal.</p> <p>Making proposals like this may be a feature in some protocols. Where it is, the protocols determine the message field names for the goal code, the role, and the DID associated with the role and goal.</p>"},{"location":"aip2/0519-goal-codes/#matching","title":"Matching","text":"<p>The goal code <code>cci.healthcare</code> is considered a more general form of the code <code>cci.healthcare.procedure</code>, which is more general than <code>cci.healthcare.procedure.schedule</code>. Because these codes are hierarchical, wildcards and fuzzy matching are possible for either a sender or a recipient of a message. Filename-style globbing semantics are used.</p> <p>A sender agent can specify that their owner's goal is just <code>meetupcorp.personal</code> without clarifying more; this is like specifying that a file is located under a folder named \"meetupcorp/personal\" without specifying where; any file \"under\" that folder -- or the folder itself -- would match the pattern. A recipient agent can have a policy that says, \"Reject any attempts to connect if the goal code of the other party is <code>aries.sell.*</code>. Notice how this differs from <code>aries.sell*</code>; the first looks for things \"inside\" <code>aries.sell</code>; the latter looks for things \"inside\" <code>aries</code> that have names beginning with <code>sell</code>.</p>"},{"location":"aip2/0519-goal-codes/#scope","title":"Scope","text":"<p>When is a declared goal known to color interactions, and when is it undefined? </p> <p>We previously noted that goal codes are a bit like the <code>subject:</code> header on an email; they contextualize everything that follows in that thread. We don't generally want to declare a goal outside of a thread context, because that would prevent an agent from engaging in two goals at the same time.</p> <p>Given these two observations, we can say that a goal applies as soon as it is declared, and it continues to apply to all messages in the same thread. It is also inherited by implication through a thread's <code>pthid</code> field; that is, a parent thread's goal colors the child thread unless/until overridden.</p>"},{"location":"aip2/0519-goal-codes/#namespacing","title":"Namespacing","text":"<p>To avoid collision and ambiguity in code values, we need to support namespacing in our goal codes. Since goals are only a coarse-grained alignment mechanism, however, we don't need perfect decentralized precision. Confusion isn't much more than an annoyance; the worst that could happen is that two agents discover one or two steps into a protocol that they're not as aligned as they supposed. They need to be prepared to tolerate that outcome in any case.</p> <p>Thus, we follow the same general approach that's used in java's packaging system, where organizations and communities use a self-declared prefix for their ecosystem as the leftmost segment or segments of a family of identifiers (goal codes) they manage. Unlike java, though, these need not be tied to DNS in any way. We recommend a single segment namespace that is a unique string, and that is an alias for a URI identifying the origin ecosystem. (In other words, you don't need to start with \"com.yourcorp.yourproduct\" -- \"yourcorp\" is probably fine.)</p> <p>The <code>aries</code> namespace alias is reserved for goal codes defined in Aries RFCs. The URI aliased by this name is TBD. See the Reference section for more details.</p>"},{"location":"aip2/0519-goal-codes/#versioning","title":"Versioning","text":"<p>Semver-style semantics don't map to goals in an simple way; it is not obvious what constitutes a \"major\" versus a \"minor\" difference in a goal, or a difference that's not worth tracking at all. The content of a goal \u2014 the only thing that might vary across versions \u2014 is simply its free-form description, and that varies according to human judgment. Many different versions of a protocol are likely to share the goal to make a payment or to introduce two strangers. A goal is likely to be far more stable than the details of how it is accomplished.</p> <p>Because of these considerations, goal codes do not impose an explicit versioning mechanism. However, one is reserved for use, in the unusual cases where it may be helpful. It is to append <code>-v</code> plus a numeric suffix: <code>my-goal-code-v1</code>, <code>my-goal-code-v2</code>, etc. Goal codes that vary only by this suffix should be understood as ordered-by-numeric-suffix evolutions of one another, and goal codes that do not intend to express versioning should not use this convention for something else. A variant of the goal code without any version suffix is equivalent to a variant with the <code>-v1</code> suffix. This allows human intuition about the relatedness of different codes, and it allows useful wildcard matching across versions. It also treats all version-like changes to a goal as breaking (semver \"major\") changes, which is probably a safe default.</p> <p>Families of goal codes are free to use this convention if they need it, or to invent a non-conflicting one of their own. However, we repeat our observation that versioning in goal codes is often inappropriate and unnecessary.</p>"},{"location":"aip2/0519-goal-codes/#declaring-goal-codes","title":"Declaring goal codes","text":""},{"location":"aip2/0519-goal-codes/#standalone-rfcs-or-similar-sources","title":"Standalone RFCs or Similar Sources","text":"<p>Any URI-referencable document can declare famlies or ontologies of goal codes. In the context of Aries, we encourage standalone RFCs for this purpose if the goals seem likely to be relevant in many contexts. Other communities may of course document goal codes in their own specs -- either dedicated to goal codes, or as part of larger topics. The following block is a sample of how we recommend that such goal codes be declared. Note that each code is individually hyperlink-able, and each is associated with a brief human-friendly description in one or more languages. This description may be used in menuing mechanisms such as the one described in Action Menu Protocol.</p>"},{"location":"aip2/0519-goal-codes/#goal-codes","title":"goal codes","text":""},{"location":"aip2/0519-goal-codes/#ariessell","title":"<code>aries.sell</code>","text":"<p>en: Sell something. Assumes two parties (buyer/seller). es: Vender algo. Asume que dos partes participan (comprador/vendedor).</p>"},{"location":"aip2/0519-goal-codes/#ariessellgoodsconsumer","title":"<code>aries.sell.goods.consumer</code>","text":"<p>en: Sell tangible goods of interest to general consumers.</p>"},{"location":"aip2/0519-goal-codes/#ariessellservicesconsumer","title":"<code>aries.sell.services.consumer</code>","text":"<p>en: Sell services of interest to general consumers.</p>"},{"location":"aip2/0519-goal-codes/#ariessellservicesenterprise","title":"<code>aries.sell.services.enterprise</code>","text":"<p>en: Sell services of interest to enterprises.</p>"},{"location":"aip2/0519-goal-codes/#in-didcomm-based-protocol-specs","title":"In DIDComm-based Protocol Specs","text":"<p>Occasionally, goal codes may have meaning only within the context of a specific protocol. In such cases, it may be appropriate to declare the goal codes directly in a protocol spec. This can be done using a section of the RFC as described above.</p> <p>More commonly, however, a protocol will accomplish one or more goals (e.g., when the protocol is fulfilling a co-protocol interface), or will require a participant to identify a goal at one or more points in a protocol flow. In such cases, the goal codes are probably declared external to the protocol. If they can be enumerated, they should still be referenced (hyperlinked to their respective definitions) in the protocol RFC.</p>"},{"location":"aip2/0519-goal-codes/#in-governance-frameworks","title":"In Governance Frameworks","text":"<p>Goal codes can also be (re-)declared in a machine-readable governance framework. </p>"},{"location":"aip2/0519-goal-codes/#reference","title":"Reference","text":""},{"location":"aip2/0519-goal-codes/#known-namespace-aliases","title":"Known Namespace Aliases","text":"<p>No central registry of namespace aliases is maintained; you need not register with an authority to create a new one. Just pick an alias with good enough uniqueness, and socialize it within your community. For convenience of collision avoidance, however, we maintain a table of aliases that are typically used in global contexts, and welcome PRs from anyone who wants to update it.</p> alias used by URI aries Hyperledger Aries Community TBD"},{"location":"aip2/0519-goal-codes/#well-known-goal-codes","title":"Well-known goal codes","text":"<p>The following goal codes are defined here because they already have demonstrated utility, based on early SSI work in Aries and elsewhere.</p>"},{"location":"aip2/0519-goal-codes/#ariesvc","title":"<code>aries.vc</code>","text":"<p>Participate in some form of VC-based interaction. </p>"},{"location":"aip2/0519-goal-codes/#ariesvcissue","title":"<code>aries.vc.issue</code>","text":"<p>Issue a verifiable credential. </p>"},{"location":"aip2/0519-goal-codes/#ariesvcverify","title":"<code>aries.vc.verify</code>","text":"<p>Verify or validate VC-based assertions.</p>"},{"location":"aip2/0519-goal-codes/#ariesvcrevoke","title":"<code>aries.vc.revoke</code>","text":"<p>Revoke a VC.</p>"},{"location":"aip2/0519-goal-codes/#ariesrel","title":"<code>aries.rel</code>","text":"<p>Create, maintain, or end something that humans would consider a relationship. This may be accomplished by establishing, updating or deleting a DIDComm messaging connection that provides a secure communication channel for the relationship. The DIDComm connection itself is not the relationship, but would be used to carry out interactions between the parties to facilitate the relationship.</p>"},{"location":"aip2/0519-goal-codes/#ariesrelbuild","title":"<code>aries.rel.build</code>","text":"<p>Create a relationship. Carries the meaning implied today by a LinkedIn invitation to connect or a Facebook \"Friend\" request. Could be as limited as creating a DIDComm Connection.</p>"},{"location":"aip2/0519-goal-codes/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"aip2/0557-discover-features-v2/","title":"Aries RFC 0557: Discover Features Protocol v2.x","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Update to version 2.0 proposed in conjunction with DIDComm v2 efforts at DIF, where it became clear that we need to discover more than just protocol support of other agents. Included in AIP v2.0.</li> <li>Supersedes: version 1.0 of this protocol in RFC 0031, which was widely referenced in the Aries eocsystem in 2018 and 2019.</li> <li>Start Date: 2018-12-17</li> <li>URI: https://didcomm.org/discover-features/%VER</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"aip2/0557-discover-features-v2/#summary","title":"Summary","text":"<p>Describes how one agent can query another to discover which ../../features it supports, and to what extent.</p>"},{"location":"aip2/0557-discover-features-v2/#motivation","title":"Motivation","text":"<p>Though some agents will support just one feature and will be statically configured to interact with just one other party, many exciting uses of agents are more dynamic and unpredictable. When Alice and Bob meet, they won't know in advance which ../../features are supported by one another's agents. They need a way to find out.</p>"},{"location":"aip2/0557-discover-features-v2/#tutorial","title":"Tutorial","text":"<p>This is version 2.0 of the Discover Features protocol, and its fully qualified PIURI for the Discover Features protocol is:</p> <pre><code>https://didcomm.org/discover-features/2.0\n</code></pre> <p>This version is conceptually similar to version 1.0 of this protocol. It differs in its ability to ask about multiple feature types, and to ask multiple questions and receive multiple answers in a single round trip.</p>"},{"location":"aip2/0557-discover-features-v2/#roles","title":"Roles","text":"<p>There are two roles in the <code>discover-features</code> protocol: <code>requester</code> and <code>responder</code>. Normally, the requester asks the responder about the ../../features it supports, and the responder answers. Each role uses a single message type.</p> <p>It is also possible to proactively disclose ../../features; in this case a requester receives a response without asking for it. This may eliminate some chattiness in certain use cases (e.g., where two-way connectivity is limited).</p>"},{"location":"aip2/0557-discover-features-v2/#states","title":"States","text":"<p>The state progression is very simple. In the normal case, it is simple request-response; in a proactive disclosure, it's a simple one-way notification.</p>"},{"location":"aip2/0557-discover-features-v2/#requester","title":"Requester","text":""},{"location":"aip2/0557-discover-features-v2/#responder","title":"Responder","text":""},{"location":"aip2/0557-discover-features-v2/#messages","title":"Messages","text":""},{"location":"aip2/0557-discover-features-v2/#queries-message-type","title":"<code>queries</code> Message Type","text":"<p>A <code>discover-features/queries</code> message looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/2.0/queries\",\n  \"@id\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\",\n  \"queries\": [\n    { \"feature-type\": \"protocol\", \"match\": \"https://didcomm.org/tictactoe/1.*\" },\n    { \"feature-type\": \"goal-code\", \"match\": \"aries.*\" }\n  ]\n}\n</code></pre> <p>Queries messages contain one or more query objects in the <code>queries</code> array. Each query essentially says, \"Please tell me what ../../features of type X you support, where the feature identifiers match this (potentially wildcarded) string.\" This particular example asks an agent if it supports any 1.x versions of the tictactoe protocol, and if it supports any goal codes that begin with \"aries.\".</p> <p>Implementations of this protocol must recognize the following values for <code>feature-type</code>: <code>protocol</code>, <code>goal-code</code>, <code>gov-fw</code>, <code>didcomm-version</code>, and <code>decorator</code>/<code>header</code>. (The concept known as <code>decorator</code> in DIDComm v1 approximately maps to the concept known as <code>header</code> in DIDComm v2. The two values should be considered synonyms and must both be recognized.) Additional values of <code>feature-type</code> may be standardized by raising a PR against this RFC that defines the new type and increments the minor protocol version number; non-standardized values are also valid, but there is no guarantee that their semantics will be recognized.</p> <p>Identifiers for feature types vary. For protocols, identifiers are PIURIs. For goal codes, identifiers are goal code values. For governance frameworks, identifiers are URIs where the framework is published (typically the <code>data_uri</code> field if machine-readable. For DIDComm versions, identifiers are the URIs where DIDComm versions are developed (<code>https://github.com/hyperledger/aries-rfcs</code> for V1 and <code>https://github.com/decentralized-identity/didcomm-messaging</code> for V2; see \"Detecting DIDComm Versions\" in RFC 0044 for more details).</p> <p>The <code>match</code> field of a query descriptor may use the * wildcard. By itself, a <code>match</code> with just the wildcard says, \"I'm interested in anything you want to share with me.\" But usually, this wildcard will be to match a prefix that's a little more specific, as in the example that matches any 1.x version.</p> <p>Any agent may send another agent this message type at any time. Implementers of agents that intend to support dynamic relationships and rich ../../features are strongly encouraged to implement support for this message, as it is likely to be among the first messages exchanged with a stranger.</p>"},{"location":"aip2/0557-discover-features-v2/#disclosures-message-type","title":"<code>disclosures</code> Message Type","text":"<p>A <code>discover-features/disclosures</code> message looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/2.0/disclosures\",\n  \"~thread\": { \"thid\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\" },\n  \"disclosures\": [\n    {\n      \"feature-type\": \"protocol\",\n      \"id\": \"https://didcomm.org/tictactoe/1.0\",\n      \"roles\": [\"player\"]\n    },\n    {\n      \"feature-type\": \"goal-code\",\n      \"id\": \"aries.sell.goods.consumer\"\n    }\n  ]\n}\n</code></pre> <p>The <code>disclosures</code> field is a JSON array of zero or more disclosure objects that describe a feature. Each descriptor has a <code>feature-type</code> field that contains data corresponding to <code>feature-type</code> in a query object, and an <code>id</code> field that unambiguously identifies a single item of that feature type. When the item is a protocol, the disclosure object may also contain a <code>roles</code> array that enumerates the roles the responding agent can play in the associated protocol. Future feature types may add additional optional fields, though no other fields are being standardized with this version of the RFC.</p> <p>Disclosures messages say, \"Here are some ../../features I support (that matched your queries).\"</p>"},{"location":"aip2/0557-discover-features-v2/#sparse-disclosures","title":"Sparse Disclosures","text":"<p>Disclosures do not have to contain exhaustive detail. For example, the following response omits the optional <code>roles</code> field but may be just as useful as one that includes it:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/2.0/disclosures\",\n  \"~thread\": { \"thid\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\" },\n  \"disclosures\": [\n    {\"feature-type\": \"protocol\", \"id\": \"https://didcomm.org/tictactoe/1.0\"}\n  ]\n}\n</code></pre> <p>Less detail probably suffices because agents do not need to know everything about one another's implementations in order to start an interaction--usually the flow will organically reveal what's needed. For example, the <code>outcome</code> message in the <code>tictactoe</code> protocol isn't needed until the end, and is optional anyway. Alice can start a tictactoe game with Bob and will eventually see whether he has the right idea about <code>outcome</code> messages.</p> <p>The missing <code>roles</code> in this disclosure does not say, \"I support no roles in this protocol.\" It says, \"I support the protocol but I'm providing no detail about specific roles.\" Similar logic applies to any other omitted fields.</p> <p>An empty <code>disclosures</code> array does not say, \"I support no ../../features that match your query.\" It says, \"I'm not disclosing to you that I support any ../../features (that match your query).\" An agent might not tell another that it supports a feature for various reasons, including: the trust that it imputes to the other party based on cumulative interactions so far, whether it's in the middle of upgrading a plugin, whether it's currently under high load, and so forth. And responses to a <code>discover-features</code> query are not guaranteed to be true forever; agents can be upgraded or downgraded, although they probably won't churn in their feature profiles from moment to moment.</p>"},{"location":"aip2/0557-discover-features-v2/#privacy-considerations","title":"Privacy Considerations","text":"<p>Because the wildcards in a <code>queries</code> message can be very inclusive, the <code>discover-features</code> protocol could be used to mine information suitable for agent fingerprinting, in much the same way that browser fingerprinting works. This is antithetical to the ethos of our ecosystem, and represents bad behavior. Agents should use <code>discover-features</code> to answer legitimate questions, and not to build detailed profiles of one another. However, fingerprinting may be attempted anyway.</p> <p>For agents that want to maintain privacy, several best practices are recommended:</p>"},{"location":"aip2/0557-discover-features-v2/#follow-selective-disclosure","title":"Follow selective disclosure.","text":"<p>Only reveal supported ../../features based on trust in the relationship. Even if you support a protocol, you may not wish to use it in every relationship. Don't tell others about ../../features you do not plan to use with them.</p> <p>Patterns are easier to see in larger data samples. However, a pattern of ultra-minimal data is also a problem, so use good judgment about how forthcoming to be.</p>"},{"location":"aip2/0557-discover-features-v2/#vary-the-format-of-responses","title":"Vary the format of responses.","text":"<p>Sometimes, you might prettify your agent plaintext message one way, sometimes another.</p>"},{"location":"aip2/0557-discover-features-v2/#vary-the-order-of-items-in-the-disclosures-array","title":"Vary the order of items in the <code>disclosures</code> array.","text":"<p>If more than one key matches a query, do not always return them in alphabetical order or version order. If you do return them in order, do not always return them in ascending order.</p>"},{"location":"aip2/0557-discover-features-v2/#consider-adding-some-spurious-details","title":"Consider adding some spurious details.","text":"<p>If a query could match multiple ../../features, then occasionally you might add some made-up ../../features as matches. If a wildcard allows multiple versions of a protocol, then sometimes you might use some made-up versions. And sometimes not. (Doing this too aggressively might reveal your agent implementation, so use sparingly.)</p>"},{"location":"aip2/0557-discover-features-v2/#vary-how-you-query-too","title":"Vary how you query, too.","text":"<p>How you ask questions may also be fingerprintable.</p>"},{"location":"aip2/0557-discover-features-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0592-indy-attachments/","title":"Aries RFC 0592: Indy Attachment Formats for Requesting and Presenting Credentials","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Formalizes the Indy AnonCreds attachments for issuing credentials and presenting proofs. A part of the Indy AnonCreds subtarget of AIP v2.0.</li> <li>Supersedes: less formally documented Indy attachment formats documented in Aries RFC 0036, Aries RFC 0037, etc.</li> <li>Start Date: 2017-01-01</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"aip2/0592-indy-attachments/#summary","title":"Summary","text":"<p>This RFC registers attachment formats used with Hyperledger Indy-style ZKP-oriented credentials in Issue Credential Protocol 2.0 and Present Proof Protocol 2.0. These formats are generally considered v2 formats, as they align with the \"anoncreds2\" work in Hyperledger Ursa and are a second generation implementation. They began to be used in production in 2018 and are in active deployment in 2021.</p>"},{"location":"aip2/0592-indy-attachments/#motivation","title":"Motivation","text":"<p>Allows Indy-style credentials to be used with credential-related protocols that take pluggable formats as payloads.</p>"},{"location":"aip2/0592-indy-attachments/#reference","title":"Reference","text":""},{"location":"aip2/0592-indy-attachments/#cred-filter-format","title":"cred filter format","text":"<p>The potential holder uses this format to propose criteria for a potential credential for the issuer to offer.</p> <p>The identifier for this format is <code>hlindy/cred-filter@v2.0</code>. It is a base64-encoded version of the data structure specifying zero or more criteria from the following (non-base64-encoded) structure:</p> <pre><code>{\n    \"schema_issuer_did\": \"&lt;schema_issuer_did&gt;\",\n    \"schema_name\": \"&lt;schema_name&gt;\",\n    \"schema_version\": \"&lt;schema_version&gt;\",\n    \"schema_id\": \"&lt;schema_identifier&gt;\",\n    \"issuer_did\": \"&lt;issuer_did&gt;\",\n    \"cred_def_id\": \"&lt;credential_definition_identifier&gt;\"\n}\n</code></pre> <p>The potential holder may not know, and need not specify, all of these criteria. For example, the holder might only know the schema name and the (credential) issuer DID. Recall that the potential holder may specify target attribute values and MIME types in the credential preview.</p> <p>For example, the JSON (non-base64-encoded) structure might look like this:</p> <pre><code>{\n    \"schema_issuer_did\": \"did:sov:4RW6QK2HZhHxa2tg7t1jqt\",\n    \"schema_name\": \"bcgov-mines-act-permit.bcgov-mines-permitting\",\n    \"issuer_did\": \"did:sov:4RW6QK2HZhHxa2tg7t1jqt\"\n}\n</code></pre> <p>A complete <code>propose-credential</code> message from the Issue Credential protocol 2.0 embeds this format at <code>/filters~attach/data/base64</code>:</p> <pre><code>{\n    \"@id\": \"&lt;uuid of propose message&gt;\",\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/propose-credential\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\" : [{\n        \"attach_id\": \"&lt;attach@id value&gt;\",\n        \"format\": \"hlindy/cred-filter@v2.0\"\n    }],\n    \"filters~attach\": [{\n        \"@id\": \"&lt;attach@id value&gt;\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"base64\": \"ewogICAgInNjaGVtYV9pc3N1ZXJfZGlkIjogImRpZDpzb3Y... (clipped)... LMkhaaEh4YTJ0Zzd0MWpxdCIKfQ==\"\n        }\n    }]\n}\n</code></pre>"},{"location":"aip2/0592-indy-attachments/#cred-abstract-format","title":"cred abstract format","text":"<p>This format is used to clarify the structure and semantics (but not the concrete data values) of a potential credential, in offers sent from issuer to potential holder.</p> <p>The identifier for this format is <code>hlindy/cred-abstract@v2.0</code>. It is a base64-encoded version of the data returned from <code>indy_issuer_create_credential_offer()</code>.</p> <p>The JSON (non-base64-encoded) structure might look like this:</p> <pre><code>{\n    \"schema_id\": \"4RW6QK2HZhHxa2tg7t1jqt:2:bcgov-mines-act-permit.bcgov-mines-permitting:0.2.0\",\n    \"cred_def_id\": \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    \"nonce\": \"57a62300-fbe2-4f08-ace0-6c329c5210e1\",\n    \"key_correctness_proof\" : &lt;key_correctness_proof&gt;\n}\n</code></pre> <p>A complete <code>offer-credential</code> message from the Issue Credential protocol 2.0 embeds this format at <code>/offers~attach/data/base64</code>:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/offer-credential\",\n    \"@id\": \"&lt;uuid of offer message&gt;\",\n    \"replacement_id\": \"&lt;issuer unique id&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\": \"hlindy/cred-abstract@v2.0\"\n        }\n    ],\n    \"offers~attach\": [\n        {\n            \"@id\": \"&lt;attach@id value&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"ewogICAgInNjaGVtYV9pZCI6ICI0Ulc2UUsySFpoS... (clipped)... jb3JyZWN0bmVzc19wcm9vZj4KfQ==\"\n            }\n        }\n    ]\n}\n</code></pre> <p>The same structure can be embedded at <code>/offers~attach/data/base64</code> in an <code>offer-credential</code> message. </p>"},{"location":"aip2/0592-indy-attachments/#cred-request-format","title":"cred request format","text":"<p>This format is used to formally request a credential. It differs from the credential abstract above in that it contains a cryptographic commitment to a link secret; an issuer can therefore use it to bind a concrete instance of an issued credential to the appropriate holder. (In contrast, the credential abstract describes the schema and cred def, but not enough information to actually issue to a specific holder.)</p> <p>The identifier for this format is <code>hlindy/cred-req@v2.0</code>. It is a base64-encoded version of the data returned from indy_prover_create_credential_req().</p> <p>The JSON (non-base64-encoded) structure might look like this:</p> <pre><code>{\n    \"prover_did\" : \"did:sov:abcxyz123\",\n    \"cred_def_id\" : \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    // Fields below can depend on Cred Def type\n    \"blinded_ms\" : &lt;blinded_master_secret&gt;,\n    \"blinded_ms_correctness_proof\" : &lt;blinded_ms_correctness_proof&gt;,\n    \"nonce\": \"fbe22300-57a6-4f08-ace0-9c5210e16c32\"\n}\n</code></pre> <p>A complete <code>request-credential</code> message from the Issue Credential protocol 2.0 embeds this format at <code>/requests~attach/data/base64</code>:</p> <pre><code>{\n    \"@id\": \"cf3a9301-6d4a-430f-ae02-b4a79ddc9706\",\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/request-credential\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\": [{\n        \"attach_id\": \"7cd11894-838a-45c0-a9ec-13e2d9d125a1\",\n        \"format\": \"hlindy/cred-req@v2.0\"\n    }],\n    \"requests~attach\": [{\n        \"@id\": \"7cd11894-838a-45c0-a9ec-13e2d9d125a1\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"base64\": \"ewogICAgInByb3Zlcl9kaWQiIDogImRpZDpzb3Y6YWJjeHl.. (clipped)... DAtNTdhNi00ZjA4LWFjZTAtOWM1MjEwZTE2YzMyIgp9\"\n        }\n    }]\n}\n</code></pre>"},{"location":"aip2/0592-indy-attachments/#credential-format","title":"credential format","text":"<p>A concrete, issued Indy credential may be transmitted over many protocols, but is specifically expected as the final message in Issuance Protocol 2.0. The identifier for its format is <code>hlindy/cred@v2.0</code>.</p> <p>This is a credential that's designed to be held but not shared directly. It is stored in the holder's wallet and used to derive a novel ZKP or W3C-compatible verifiable presentation just in time for each sharing of credential material.</p> <p>The encoded values of the credential MUST follow the encoding algorithm as described in Encoding Claims.</p> <p>This is the format emitted by libindy's indy_issuer_create_credential() function. It is JSON-based and might look like this:</p> <pre><code>{\n    \"schema_id\": \"4RW6QK2HZhHxa2tg7t1jqt:2:bcgov-mines-act-permit.bcgov-mines-permitting:0.2.0\",\n    \"cred_def_id\": \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    \"rev_reg_id\", \"EyN78DDGHyok8qw6W96UBY:4:EyN78DDGHyok8qw6W96UBY:3:CL:56389:CardossierOrgPerson:CL_ACCUM:1-1000\",\n    \"values\": {\n        \"attr1\" : {\"raw\": \"value1\", \"encoded\": \"value1_as_int\" },\n        \"attr2\" : {\"raw\": \"value2\", \"encoded\": \"value2_as_int\" }\n    },\n    // Fields below can depend on Cred Def type\n    \"signature\": &lt;signature&gt;,\n    \"signature_correctness_proof\": &lt;signature_correctness_proof&gt;\n    \"rev_reg\": &lt;revocation registry state&gt;\n    \"witness\": &lt;witness&gt;\n}\n</code></pre> <p>An exhaustive description of the format is out of scope here; it is more completely documented in white papers, source code, and other Indy materials.</p>"},{"location":"aip2/0592-indy-attachments/#proof-request-format","title":"proof request format","text":"<p>This format is used to formally request a verifiable presenation (proof) derived from an Indy-style ZKP-oriented credential. It can also be used by a holder to propose a presentation.</p> <p>The identifier for this format is <code>hlindy/proof-req@v2.0</code>. It is a base64-encoded version of the data returned from indy_prover_search_credentials_for_proof_req().</p> <p>Here is a sample proof request that embodies the following: \"Using a government-issued ID, disclose the credential holder\u2019s name and height, hide the credential holder\u2019s sex, get them to self-attest their phone number, and prove that their age is at least 18\":</p> <pre><code>{\n    \"nonce\": \u201c2934823091873049823740198370q23984710239847\u201d, \n    \"name\":\"proof_req_1\",\n    \"version\":\"0.1\",\n    \"requested_attributes\":{\n        \"attr1_referent\": {\"name\":\"sex\"},\n        \"attr2_referent\": {\"name\":\"phone\"},\n        \"attr3_referent\": {\"names\": [\"name\", \"height\"], \"restrictions\": &lt;restrictions specifying government-issued ID&gt;}\n    },\n    \"requested_predicates\":{\n        \"predicate1_referent\":{\"name\":\"age\",\"p_type\":\"&gt;=\",\"p_value\":18}\n    }\n}\n</code></pre>"},{"location":"aip2/0592-indy-attachments/#proof-format","title":"proof format","text":"<p>This is the format of an Indy-style ZKP. It plays the same role as a W3C-style verifiable presentation (VP) and can be mapped to one.</p> <p>The raw values encoded in the presentation SHOULD be verified against the encoded values using the encoding algorithm as described below in Encoding Claims.</p> <p>The identifier for this format is <code>hlindy/proof@v2.0</code>. It is a version of the (JSON-based) data emitted by libindy's indy_prover_create_proof()) function. A proof that responds to the previous proof request sample looks like this:</p> <pre><code>{\n  \"proof\":{\n    \"proofs\":[\n      {\n        \"primary_proof\":{\n          \"eq_proof\":{\n            \"revealed_attrs\":{\n              \"height\":\"175\",\n              \"name\":\"1139481716457488690172217916278103335\"\n            },\n            \"a_prime\":\"5817705...096889\",\n            \"e\":\"1270938...756380\",\n            \"v\":\"1138...39984052\",\n            \"m\":{\n              \"master_secret\":\"375275...0939395\",\n              \"sex\":\"3511483...897083518\",\n              \"age\":\"13430...63372249\"\n            },\n            \"m2\":\"1444497...2278453\"\n          },\n          \"ge_proofs\":[\n            {\n              \"u\":{\n                \"1\":\"152500...3999140\",\n                \"2\":\"147748...2005753\",\n                \"0\":\"8806...77968\",\n                \"3\":\"10403...8538260\"\n              },\n              \"r\":{\n                \"2\":\"15706...781609\",\n                \"3\":\"343...4378642\",\n                \"0\":\"59003...702140\",\n                \"DELTA\":\"9607...28201020\",\n                \"1\":\"180097...96766\"\n              },\n              \"mj\":\"134300...249\",\n              \"alpha\":\"827896...52261\",\n              \"t\":{\n                \"2\":\"7132...47794\",\n                \"3\":\"38051...27372\",\n                \"DELTA\":\"68025...508719\",\n                \"1\":\"32924...41082\",\n                \"0\":\"74906...07857\"\n              },\n              \"predicate\":{\n                \"attr_name\":\"age\",\n                \"p_type\":\"GE\",\n                \"value\":18\n              }\n            }\n          ]\n        },\n        \"non_revoc_proof\":null\n      }\n    ],\n    \"aggregated_proof\":{\n      \"c_hash\":\"108743...92564\",\n      \"c_list\":[ 6 arrays of 257 numbers between 0 and 255]\n    }\n  },\n  \"requested_proof\":{\n    \"revealed_attrs\":{\n      \"attr1_referent\":{\n        \"sub_proof_index\":0,\n        \"raw\":\"Alex\",\n        \"encoded\":\"1139481716457488690172217916278103335\"\n      }\n    },\n    \"revealed_attr_groups\":{\n      \"attr4_referent\":{\n        \"sub_proof_index\":0,\n        \"values\":{\n          \"name\":{\n            \"raw\":\"Alex\",\n            \"encoded\":\"1139481716457488690172217916278103335\"\n          },\n          \"height\":{\n            \"raw\":\"175\",\n            \"encoded\":\"175\"\n          }\n        }\n      }\n    },\n    \"self_attested_attrs\":{\n      \"attr3_referent\":\"8-800-300\"\n    },\n    \"unrevealed_attrs\":{\n      \"attr2_referent\":{\n        \"sub_proof_index\":0\n      }\n    },\n    \"predicates\":{\n      \"predicate1_referent\":{\n        \"sub_proof_index\":0\n      }\n    }\n  },\n  \"identifiers\":[\n    {\n      \"schema_id\":\"NcYxiDXkpYi6ov5FcYDi1e:2:gvt:1.0\",\n      \"cred_def_id\":\"NcYxi...cYDi1e:2:gvt:1.0:TAG_1\",\n      \"rev_reg_id\":null,\n      \"timestamp\":null\n    }\n  ]\n}\n</code></pre>"},{"location":"aip2/0592-indy-attachments/#unrevealed-attributes","title":"Unrevealed Attributes","text":"<p>AnonCreds supports a holder responding to a proof request with some of the requested claims included in an <code>unrevealed_attrs</code> array, as seen in the example above, with <code>attr2_referent</code>. Assuming the rest of the proof is valid, AnonCreds will indicate that a proof with unrevealed attributes has been successfully verified. It is the responsibility of the verifier to determine if the purpose of the verification has been met if some of the attributes are not revealed.</p> <p>There are at least a few valid use cases for this approach:</p> <ul> <li>A verifier may ask for, but not require, that a prover provide all of the   requested attributes.</li> <li>A verifier may ask for claims from several credentials, expecting holders to   only have some of the credentials. The holders respond with claims from the   credentials they have, and leave the other attributes unrevealed.</li> <li>For example, a verifier may ask for a national identity card and an resident     card, knowing that most holders will have one or the other.</li> </ul>"},{"location":"aip2/0592-indy-attachments/#encoding-claims","title":"Encoding Claims","text":"<p>Claims in AnonCreds-based verifiable credentials are put into the credential in two forms, <code>raw</code> and <code>encoded</code>. <code>raw</code> is the actual data value, and <code>encoded</code> is the (possibly derived) integer value that is used in presentations. At this time, AnonCreds does not take an opinion on the method used for encoding the raw value.</p> <p>AnonCreds issuers and verifiers must agree on the encoding method so that the verifier can check that the <code>raw</code> value returned in a presentation corresponds to the proven <code>encoded</code> value. The following is the encoding algorithm that MUST be used by Issuers when creating credentials and SHOULD be verified by Verifiers receiving presentations:</p> <ul> <li>keep any 32-bit integer as is</li> <li>convert any string integer (e.g. <code>\"1234\"</code>) to be a 32-bit integer (e.g. <code>1234</code>)</li> <li>for data of any other type:</li> <li>convert to string (use string \"None\" for null)</li> <li>encode via utf-8 to bytes</li> <li>apply SHA-256 to digest the bytes</li> <li>convert the resulting digest bytes, big-endian, to integer</li> <li>stringify the integer as a decimal.</li> </ul> <p>An example implementation in Python can be found here.</p> <p>A gist of test value pairs can be found here.</p>"},{"location":"aip2/0592-indy-attachments/#notes-on-encoding-claims","title":"Notes on Encoding Claims","text":"<ul> <li>In converting any string integer to an integer, leading 0s in the string are (by definition) not part of the integer. The leading 0's remain in the (untouched) <code>raw</code> value.</li> <li>The use of AnonCreds predicates, such as proving \"older than 21\" based on a date of birth claim without sharing the date of birth, is based on an expression involving the <code>encoded</code> value. Thus, only <code>raw</code> integers or string integers can be used in AnonCreds predicates.</li> </ul>"},{"location":"aip2/0592-indy-attachments/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0593-json-ld-cred-attach/","title":"Aries RFC 0593: JSON-LD Credential Attachment format for requesting and issuing credentials","text":"<ul> <li>Authors: Timo Glastra (Animo Solutions), George Aristy (SecureKey Technologies)</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Included as part of the JSON-LD verifiable credentials subtarget of AIP v2.0.</li> <li>Supersedes:</li> <li>Start Date: 2021-02-17</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"aip2/0593-json-ld-cred-attach/#summary","title":"Summary","text":"<p>This RFC registers an attachment format for use in the issue-credential V2 protocol based on JSON-LD credentials with Linked Data Proofs from the VC Data Model.</p> <p>It defines a minimal set of parameters needed to create a common understanding of the verifiable credential to issue. It is based on version 1.0 of the Verifiable Credentials Data Model which is a W3C recommendation since 19 November 2019.</p>"},{"location":"aip2/0593-json-ld-cred-attach/#motivation","title":"Motivation","text":"<p>The Issue Credential protocol needs an attachment format to be able to exchange JSON-LD credentials with Linked Data Proofs. It is desirable to make use of specifications developed in an open standards body, such as the Credential Manifest for which the attachment format is described in RFC 0511: Credential-Manifest Attachment format. However, the Credential Manifest is not finished and ready yet, and therefore there is a need to bridge the gap between standards.</p>"},{"location":"aip2/0593-json-ld-cred-attach/#tutorial","title":"Tutorial","text":"<p>Complete examples of messages are provided in the reference section.</p>"},{"location":"aip2/0593-json-ld-cred-attach/#reference","title":"Reference","text":""},{"location":"aip2/0593-json-ld-cred-attach/#ld-proof-vc-detail-attachment-format","title":"<code>ld-proof-vc-detail</code> attachment format","text":"<p>Format identifier: <code>aries/ld-proof-vc-detail@v1.0</code></p> <p>This format is used to formally propose, offer, or request a credential. The <code>credential</code> property should contain the credential as it is going to be issued, without the <code>proof</code> and <code>credentialStatus</code> properties. Options for these properties are specified in the <code>options</code> object.</p> <p>The JSON structure might look like this:</p> <pre><code>{\n  \"credential\": {\n    \"@context\": [\n      \"https://www.w3.org/2018/credentials/v1\",\n      \"https://www.w3.org/2018/credentials/examples/v1\"\n    ],\n    \"id\": \"urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5\",\n    \"type\": [\"VerifiableCredential\", \"UniversityDegreeCredential\"],\n    \"issuer\": \"did:key:z6MkodKV3mnjQQMB9jhMZtKD9Sm75ajiYq51JDLuRSPZTXrr\",\n    \"issuanceDate\": \"2020-01-01T19:23:24Z\",\n    \"expirationDate\": \"2021-01-01T19:23:24Z\",\n    \"credentialSubject\": {\n      \"id\": \"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\",\n      \"degree\": {\n        \"type\": \"BachelorDegree\",\n        \"name\": \"Bachelor of Science and Arts\"\n      }\n    }\n  },\n  \"options\": {\n    \"proofPurpose\": \"assertionMethod\",\n    \"created\": \"2020-04-02T18:48:36Z\",\n    \"domain\": \"example.com\",\n    \"challenge\": \"9450a9c1-4db5-4ab9-bc0c-b7a9b2edac38\",\n    \"credentialStatus\": {\n      \"type\": \"CredentialStatusList2017\"\n    },\n    \"proofType\": \"Ed25519Signature2018\"\n  }\n}\n</code></pre> <p>A complete <code>request credential</code> message form the Issue Credential protocol 2.0 might look like this:</p> <pre><code>{\n  \"@id\": \"7293daf0-ed47-4295-8cc4-5beb513e500f\",\n  \"@type\": \"https://didcomm.org/issue-credential/%VER/request-credential\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"13a3f100-38ce-4e96-96b4-ea8f30250df9\",\n      \"format\": \"aries/ld-proof-vc-detail@v1.0\"\n    }\n  ],\n  \"requests~attach\": [\n    {\n      \"@id\": \"13a3f100-38ce-4e96-96b4-ea8f30250df9\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"ewogICJjcmVkZW50aWFsIjogewogICAgIkBjb250...(clipped)...IkVkMjU1MTlTaWduYXR1cmUyMDE4IgogIH0KfQ==\"\n      }\n    }\n  ]\n}\n</code></pre> <ul> <li> <p><code>credential</code> - Required. Detail of the JSON-LD Credential that will be issued. Properties MUST align with the Verifiable Credentials Data Model. This also means all properties required by the data model MUST be present. The properties listed below are formally supported, but additional properties MAY be included if it conforms with the data model.</p> </li> <li> <p><code>@context</code></p> </li> <li><code>id</code></li> <li><code>type</code></li> <li><code>issuer</code></li> <li><code>issuanceDate</code></li> <li><code>expirationDate</code></li> <li> <p><code>credentialSubject</code></p> </li> <li> <p><code>options</code> - Required. Options for specifying how the linked data proof is created.</p> </li> <li> <p><code>proofType</code> - Required string. The proof type used for the proof. Should match suites registered in the Linked Data Cryptographic Suite Registry.</p> </li> <li><code>proofPurpose</code> - Optional string, default <code>assertionMethod</code>. The proof purpose used for the proof. Should match proof purposes registered in the Linked Data Proofs Specification.</li> <li><code>created</code> - Optional string, default current system time. The date and time of the proof (with a maximum accuracy in seconds).</li> <li><code>challenge</code> - Optional string. A challenge to include in the proof. SHOULD be provided by the requesting party of the credential (=holder).</li> <li><code>domain</code> - Optional string. The intended domain of validity for the proof.</li> <li><code>credentialStatus</code> - Optional object. The credential status mechanism to use for the credential. Omitting the property indicates the issued credential will not include a credential status.<ul> <li><code>type</code> - Required string. Credential status method type to use for the credential. Should match status method registered in the Verifiable Credential Extension Registry</li> </ul> </li> </ul> <p>The format is closely related to the Verifiable Credentials HTTP API, but diverts on some places. The main differences are:</p> <ul> <li>The types in the VC HTTP API are more restrictive (.e.g. <code>@context</code> must be array of strings). This format allows all fields to use the full syntax as described by the verifiable credentials data model.</li> <li>Instead of specifying the exact <code>verificationMethod</code>, the <code>proofType</code> that will be used for the credential can be specified.</li> </ul>"},{"location":"aip2/0593-json-ld-cred-attach/#ld-proof-vc-attachment-format","title":"<code>ld-proof-vc</code> attachment format","text":"<p>Format identifier: <code>aries/ld-proof-vc@v1.0</code></p> <p>This format is used to transmit a verifiable credential with linked data proof. The contents of the attachment is a standard JSON-LD Verifiable Credential object with linked data proof as defined by the Verifiable Credentials Data Model and the Linked Data Proofs specification.</p> <p>The JSON structure might look like this:</p> <pre><code>{\n  \"@context\": [\n    \"https://www.w3.org/2018/credentials/v1\",\n    \"https://www.w3.org/2018/credentials/examples/v1\"\n  ],\n  \"id\": \"http://example.gov/credentials/3732\",\n  \"type\": [\"VerifiableCredential\", \"UniversityDegreeCredential\"],\n  \"issuer\": {\n    \"id\": \"did:web:vc.transmute.world\"\n  },\n  \"issuanceDate\": \"2020-03-10T04:24:12.164Z\",\n  \"credentialSubject\": {\n    \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n    \"degree\": {\n      \"type\": \"BachelorDegree\",\n      \"name\": \"Bachelor of Science and Arts\"\n    }\n  },\n  \"proof\": {\n    \"type\": \"JsonWebSignature2020\",\n    \"created\": \"2020-03-21T17:51:48Z\",\n    \"verificationMethod\": \"did:web:vc.transmute.world#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A\",\n    \"proofPurpose\": \"assertionMethod\",\n    \"jws\": \"eyJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdLCJhbGciOiJFZERTQSJ9..OPxskX37SK0FhmYygDk-S4csY_gNhCUgSOAaXFXDTZx86CmI5nU9xkqtLWg-f4cqkigKDdMVdtIqWAvaYx2JBA\"\n  }\n}\n</code></pre> <p>A complete <code>issue-credential</code> message from the Issue Credential protocol 2.0 might look like this:</p> <pre><code>{\n  \"@id\": \"284d3996-ba85-45d9-964b-9fd5805517b6\",\n  \"@type\": \"https://didcomm.org/issue-credential/%VER/issue-credential\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"5b38af88-d36f-4f77-bb7a-2f04ab806eb8\",\n      \"format\": \"aries/ld-proof-vc@v1.0\"\n    }\n  ],\n  \"credentials~attach\": [\n    {\n      \"@id\": \"5b38af88-d36f-4f77-bb7a-2f04ab806eb8\",\n      \"mime-type\": \"application/ld+json\",\n      \"data\": {\n        \"base64\": \"ewogICAgICAgICAgIkBjb250ZXogWwogICAgICAg...(clipped)...RNVmR0SXFXZhWXgySkJBIgAgfQogICAgICAgIH0=\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"aip2/0593-json-ld-cred-attach/#supported-proof-types","title":"Supported Proof Types","text":"<p>Following are the Linked Data proof types on Verifiable Credentials that MUST be supported for compliance with this RFC. All suites listed in the following table MUST be registered in the Linked Data Cryptographic Suite Registry:</p> Suite Spec Enables Selective disclosure? Enables Zero-knowledge proofs? Optional Ed25519Signature2018 Link No No No BbsBlsSignature2020** Link Yes No No JsonWebSignature2020*** Link No No Yes <p>** Note: see RFC0646 for details on how BBS+ signatures are to be produced and consumed by Aries agents.</p> <p>*** Note: P-256 and P-384 curves are supported.</p>"},{"location":"aip2/0593-json-ld-cred-attach/#drawbacks","title":"Drawbacks","text":"<p>N/A</p>"},{"location":"aip2/0593-json-ld-cred-attach/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>The <code>hlindy-zkp-v1.0</code> format is an alternative restricted to the Hyperledger Indy network. The <code>dif/credential-manifest@v1.0</code> allows to issue JSON-LD credentials but is not ready yet for usage.</li> </ul>"},{"location":"aip2/0593-json-ld-cred-attach/#prior-art","title":"Prior art","text":"<p>N/A</p>"},{"location":"aip2/0593-json-ld-cred-attach/#unresolved-questions","title":"Unresolved questions","text":"<p>N/A</p>"},{"location":"aip2/0593-json-ld-cred-attach/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0003-protocols/","title":"Aries RFC 0003: Protocols","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-04-01</li> <li>Status Note: standards track and beginning to influence many mental models, but not yet ADOPTED.</li> <li>Supersedes: Indy PR #69</li> <li>Start Date: 2018-12-28</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0003-protocols/#summary","title":"Summary","text":"<p>Defines peer-to-peer application-level protocols in the context of interactions among agent-like things, and shows how they should be designed and documented.</p> <p></p>"},{"location":"concepts/0003-protocols/#table-of-contents","title":"Table of Contents","text":"<ul> <li>Aries RFC 0003: Protocols</li> <li>Summary</li> <li>Motivation</li> <li>Tutorial<ul> <li>What is a Protocol?</li> <li>Relationship to APIs</li> <li>Decentralized</li> <li>Types of Protocols</li> <li>Agent Design</li> <li>Composable</li> <li>Message Types</li> <li>Handling Unrecognized Items in Messages</li> <li>Ingredients</li> <li>How to Define a Protocol</li> <li>Security Considerations</li> <li>Replay Attacks</li> </ul> </li> <li>Reference<ul> <li>Message Type and Protocol Identifier URIs</li> <li>MTURI</li> <li>PIURI</li> <li>Semver Rules for Protocols</li> <li>Semver Examples<ul> <li>Initiator</li> <li>Recipient Rules</li> </ul> </li> <li>State Details and State Machines</li> <li>State Machines</li> <li>Processing Points</li> <li>Roles, Participants, Parties, and Controllers</li> <li>Roles</li> <li>Participants</li> <li>Parties</li> <li>Controllers</li> <li>Instructions for Protocol RFCs</li> </ul> </li> <li>Drawbacks</li> <li>Rationale and alternatives</li> <li>Prior art<ul> <li>BPMN</li> <li>WSDL</li> <li>Swagger / OpenAPI</li> <li>Other</li> </ul> </li> <li>Unresolved questions</li> <li>Implementations</li> </ul>"},{"location":"concepts/0003-protocols/#motivation","title":"Motivation","text":"<p>APIs in the style of Swagger are familiar to nearly all developers, and it's a common assumption that we should use them to solve the problems at hand in the decentralized identity space. However, to truly decentralize, we must think about interactions at a higher level of generalization. Protocols can model all APIs, but not the other way around. This matters. We need to explain why.</p> <p>We also need to show how a protocol is defined, so the analog to defining a Swagger API is demystified.</p>"},{"location":"concepts/0003-protocols/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0003-protocols/#what-is-a-protocol","title":"What is a Protocol?","text":"<p>A protocol is a recipe for a stateful interaction. Protocols are all around us, and are so ordinary that we take them for granted. Each of the following interactions is stateful, and has conventions that constitute a sort of \"recipe\":</p> <ul> <li>Ordering food at a restaurant</li> <li>Buying a house</li> <li>Playing a game of chess, checkers, tic-tac-toe, etc.</li> <li>Bidding on an item in an online auction.</li> <li>Going through security at the airport when we fly</li> <li>Applying for a loan</li> </ul> <p>In the context of decentralized identity, protocols manifest at many different levels of the stack: at the lowest levels of networking, in cryptographic algorithms like Diffie Hellman, in the management of DIDs, in the conventions of DIDComm, and in higher-level interactions that solve problems for people with only minimal interest in the technology they're using. However, this RFC focuses on the last of these layers, where use cases and personas are transformed into ../../features with obvious social value like:</p> <ul> <li>Connecting with one another</li> <li>Requesting and issuing credentials</li> <li>Proving things using credentials</li> <li>Discovering things</li> <li>Delegating</li> <li>Buying and Selling</li> <li>Negotiating</li> <li>Enacting and enforcing contracts</li> <li>Putting things in escrow (and taking them out again)</li> <li>Scheduling</li> <li>Auditing</li> <li>Reporting errors</li> <li>Cooperative debugging</li> </ul> <p>When \"protocol\" is used in an Aries context without any qualifying adjective, it is referencing a recipe for a high-level interaction like these. Lower-level protocols are usually described more specifically and possibly with other verbiage: \"cryptographic algorithms\", \"DID management procedures\", \"DIDComm conventions\", \"transports\", and so forth. This helps us focus \"protocol\" on the place where application developers that consume Aries do most of the work that creates value.</p>"},{"location":"concepts/0003-protocols/#relationship-to-apis","title":"Relationship to APIs","text":"<p>The familiar world of web APIs is a world of protocols, but it comes with constraints antithetical to decentralized identity:</p> <ul> <li>It assumes all interactions are between a client and a server--either two parties, or N parties mediated by a central server. Thus, the server is a natural locus for surveillance and hacking.</li> <li>It assumes security is asymmetric--not using DIDs, but driven by certs on a server and by a session for the client.</li> <li>It assumes the transport is HTTP. This is problematic for pure mobile-to-mobile, or for use cases where the transport is complex or asymmetric.</li> <li>Because the server can never initiate an interaction, it requires at least one party to be continuously online.</li> </ul> <p>Protocols impose none of these constraints. Web APIs can easily be modeled as protocols where the transport is HTTP and the payload is a message, and the Aries community actively does this. We are not opposed to APIs. We just want to describe and standardize the higher level abstraction so we don't have a web solution and a BlueTooth solution that are diverged for no good reason.</p>"},{"location":"concepts/0003-protocols/#decentralized","title":"Decentralized","text":"<p>As used in the agent/DIDComm world, protocols are decentralized. This means there is not an overseer for the protocol, guaranteeing information flow, enforcing behaviors, and ensuring a coherent view. It is a subtle but important divergence from API-centric approaches, where a server holds state against which all other parties (clients) operate. Instead, all parties are peers, and they interact by mutual consent and with a (hopefully) shared understanding of the rules and goals. Protocols are like a dance\u2014not one that's choreographed or directed, but one where the parties make dynamic decisions and react to them.</p> <p></p>"},{"location":"concepts/0003-protocols/#types-of-protocols","title":"Types of Protocols","text":"<p>The simplest protocol style is notification. This style involves two parties, but it is one-way: the <code>notifier</code> emits a message, and the protocol ends when the <code>notified</code> receives it. The basic message protocol uses this style.</p> <p></p> <p>Slightly more complex is the request-response protocol style. This style involve two parties, with the <code>requester</code> making the first move, and the <code>responder</code> completing the interaction. The Discover Features Protocol uses this style. Note that with protocols as Aries models them (and unlike an HTTP request), the request-response messages are asynchronous.</p> <p></p> <p>However, more complex protocols exist. The Introduce Protocol involves three parties, not two. The issue credential protocol includes up to six message types (including <code>ack</code> and <code>problem_report</code>), two of which (<code>proposal</code> and <code>offer</code>) can be used to interactively negotiate details of the elements of the subsequent messages in the protocol.</p> <p>See this subsection for definitions of the terms \"role\", \"participant\", and \"party\".</p>"},{"location":"concepts/0003-protocols/#agent-design","title":"Agent Design","text":"<p>Protocols are the key unit of interoperable extensibility in agents and agent-like things. To add a new interoperable feature to an agent, give it the ability to handle a new protocol.</p> <p>When agents receive messages, they map the messages to a protocol handler and possibly to an interaction state that was previously persisted. This is the analog to routes, route handlers, and sessions in web APIs, and could actually be implemented as such if the transport for the protocol is HTTP. The protocol handler is code that knows the rules of a particular protocol; the interaction state tracks progress through an interaction. For more information, see the agents explainer\u2014RFC 0004 and the DIDComm explainer\u2014RFC 0005.</p>"},{"location":"concepts/0003-protocols/#composable","title":"Composable","text":"<p>Protocols are composable--meaning that you can build complex ones from simple ones. The protocol for asking someone to repeat their last sentence can be part of the protocol for ordering food at a restaurant. It's common to ask a potential driver's license holder to prove their street address before issuing the license. In protocol terms, this is nicely modeled as the present proof being invoked in the middle of an issue credential protocol.</p> <p>When we run one protocol inside another, we call the inner protocol a subprotocol, and the outer protocol a superprotocol. A given protocol may be a subprotocol in some contexts, and a standalone protocol in others. In some contexts, a protocol may be a subprotocol from one perspective, and a superprotocol from another (as when protocols are nested at least 3 deep).</p> <p></p> <p>Commonly, protocols wait for subprotocols to complete, and then they continue. A good example of this is mentioned above\u2014starting an issue credential flow, but requiring the potential issuer and/or the potential holder to prove something to one another before completing the process.</p> <p>In other cases, a protocol B is not \"contained\" inside protocol A. Rather, A triggers B, then continues in parallel, without waiting for B to complete. This coprotocol relationship is analogous to relationship between coroutines in computer science. In the Introduce Protocol, the final step is to begin a connection protocol between the two introducees-- but the introduction coprotocol completes when the connect coprotocol starts, not when it completes.</p> <p></p>"},{"location":"concepts/0003-protocols/#message-types","title":"Message Types","text":"<p>A protocol includes a number of message types that enable the execution of an instance of a protocol. Collectively, the message types of a protocol become the skeleton of its interface. Most of the message types are defined with the protocol, but several key message types, notably acks and problem reports are defined in separate RFCs and <code>adopted</code> into a protocol. This ensures that the structure of such messages is standardized, but used in the context of the protocol adopting the message types.</p>"},{"location":"concepts/0003-protocols/#handling-unrecognized-items-in-messages","title":"Handling Unrecognized Items in Messages","text":"<p>In the semver section of this document there is discussion of the handling of mismatches in minor versions supported and received. Notably, a recipient that supports a given minor version of a protocol less than that of a received protocol message should ignore any unrecognized fields in the message. Such handling of unrecognized data items applies more generally than just minor version mismatches. A recipient of a message from a supported major version of a protocol should ignore any unrecognized items in a received message, even if the supported and minor versions are the same. When items from the message are ignored, the recipient may want to send a warning <code>problem-report</code> message with code <code>fields-ignored</code>.</p>"},{"location":"concepts/0003-protocols/#ingredients","title":"Ingredients","text":"<p>A protocol has the following ingredients:</p> <ul> <li>Name and semver-compatible   version</li> <li>URI that uniquely identifies it</li> <li>Messages (primary message family)</li> <li>Adopted messages</li> <li>Roles</li> <li>State and sequencing rules</li> <li>Events that can change state -- notably, messages, but also errors, timeouts, and other things</li> <li>Constraints that provide trust and incentives</li> </ul>"},{"location":"concepts/0003-protocols/#how-to-define-a-protocol","title":"How to Define a Protocol","text":"<p>To define a protocol, write an RFC. Specific instructions for protocol RFCs, and a discussion about the theory behind detailed protocol ../../concepts, are given in the instructions for protocol RFCs and in the protocol RFC template.</p> <p>The tictactoe protocol is attached to this RFC as an example.</p> <p></p>"},{"location":"concepts/0003-protocols/#security-considerations","title":"Security Considerations","text":""},{"location":"concepts/0003-protocols/#replay-attacks","title":"Replay Attacks","text":"<p>It should be noted that when defining a protocol that has domain specific requirements around preventing replay attacks, an <code>@id</code> property SHOULD be required. Given an <code>@id</code> field is most commonly set to be a UUID, it should provide randomness comparable to that of a nonce in preventing replay attacks. However, this means that care will be needed in processing of the <code>@id</code> field to make sure its value has not been used before. In some cases, nonces require being unpredictable as well. In this case, greater review should be taken as to how the <code>@id</code> field should be used in the domain specific protocol. In the event where the <code>@id</code> field is not adequate for preventing replay attacks, it's recommended that an additional <code>nonce</code> field be required by the domain specific protocol specification.</p>"},{"location":"concepts/0003-protocols/#reference","title":"Reference","text":""},{"location":"concepts/0003-protocols/#message-type-and-protocol-identifier-uris","title":"Message Type and Protocol Identifier URIs","text":"<p>Message types and protocols are identified with URIs that match certain conventions.</p>"},{"location":"concepts/0003-protocols/#mturi","title":"MTURI","text":"<p>A message type URI (MTURI) identifies message types unambiguously. Standardizing its format is important because it is parsed by agents that will map messages to handlers--basically, code will look at this string and say, \"Do I have something that can handle this message type inside protocol X version Y?\"</p> <p>When this analysis happens, strings should be compared for byte-wise equality in all segments except version. This means that case, unicode normalization, and punctuation differences all matter. It is thus best practice to avoid protocol and message names that differ only in subtle, easy-to-mistake ways.</p> <p>Comparison of the version segment of an MTURI or PIURI should follow semver rules and is discussed in the semver section of this document.</p> <p>The URI MUST be composed as follows:</p> <p></p> <pre><code>message-type-uri  = doc-uri delim protocol-name\n    \"/\" protocol-version \"/\" message-type-name\ndelim             = \"?\" / \"/\" / \"&amp;\" / \":\" / \";\" / \"=\"\nprotocol-name     = identifier\nprotocol-version  = semver\nmessage-type-name = identifier\nidentifier        = alpha *(*(alphanum / \"_\" / \"-\" / \".\") alphanum)\n</code></pre> <p>It can be loosely matched and parsed with the following regex:</p> <pre><code>    (.*?)([a-z0-9._-]+)/(\\d[^/]*)/([a-z0-9._-]+)$\n</code></pre> <p>A match will have captures groups of (1) = <code>doc-uri</code>, (2) = <code>protocol-name</code>, (3) = <code>protocol-version</code>, and (4) = <code>message-type-name</code>.</p> <p>The goals of this URI are, in descending priority:</p> <ul> <li> <p>Code can use the URI to route messages to protocol handlers using semver rules.</p> </li> <li> <p>The definition of a protocol should be tied to the URI such that it is semantically stable. This means that once version 1.0 of a protocol is defined, its definition should not change in ways that would break implementations.</p> </li> <li> <p>Developers can discover information about novel protocols, using the URI to browse or search the web.</p> </li> </ul> <p>The <code>doc-uri</code> portion is any URI that exposes documentation about protocols. A developer should be able to browse to that URI and use human intelligence to look up the named and versioned protocol. Optionally and preferably, the full URI may produce a page of documentation about the specific message type, with no human mediation involved.</p>"},{"location":"concepts/0003-protocols/#piuri","title":"PIURI","text":"<p>A shorter URI that follows the same conventions but lacks the <code>message-type-name</code> portion is called a protocol identifier URI (PIURI).</p> <p></p> <pre><code>protocol-identifier-uri  = doc-uri delim protocol-name\n    \"/\" semver\n</code></pre> <p>Its loose matcher regex is:</p> <pre><code>    (.*?)([a-z0-9._-]+)/(\\d[^/]*)/?$\n</code></pre> <p>The following are examples of valid MTURIs and PIURIs:</p> <ul> <li><code>http://example.com/protocols?which=lets_do_lunch/1.0/</code> (PIURI with fully automated lookup of protocol docs)</li> <li><code>http://example.com/message_types?which=lets_do_lunch/1.0/proposal</code> (MTURI)</li> <li><code>https://github.com/hyperledger/aries-rfcs/tree/18c4f82:trust_ping/1.0/ping</code>    (MTURI). Note that this URI returns a 404 error if followed directly--but    per rules described above, the developer should browse to the doc root    (https://github.com/hyperledger/aries-rfcs/tree/18c4f82) and look for documentation on the <code>trust_ping/1.0</code> protocol.</li> <li><code>https://didcomm.org/trust_ping/1.0/ping</code> (MTURI) This    uses an https reference that could serve    information about protocols.</li> </ul>"},{"location":"concepts/0003-protocols/#semver-rules-for-protocols","title":"Semver Rules for Protocols","text":"<p>Semver rules apply to protocols, with the version of a protocol is expressed in the <code>semver</code> portion of its identifying URI. The \"ingredients\" of a protocol combine to form a public API in the semver sense. Core Aries protocols specify only major and minor elements in a version; the patch component is not used. Non-core protocols may choose to use the patch element.</p> <p>The major and minor versions of protocols match semver semantics:</p> <ul> <li>Clarification updates that do not change the \"public API\" of the protocol can be made with community support without changing the minor version of the protocol.</li> <li>An individual message type can add new optional fields, or deprecate existing fields, with only a change to its protocol's minor version. Similarly, a protocol can add new or deprecate message types with only a change to the minor version.</li> <li>Changes that remove fields or message types, that make formerly optional things required, or that alter the state machine in incompatible ways, must result in an increase of the major version of the protocol/primary message family.</li> </ul> <p>Within a given major version of a protocol, an agent should:</p> <ul> <li>Respond to a minimum supported minor version, defaulting to \"0\".</li> <li>An agent SHOULD keep minimum supported minor version at \"0\" unless it is unsecure or extremely complicated to do so.</li> <li>Respond with or initiate a protocol instance the current fully supported minor version.</li> </ul> <p>This leads to the following received message handling rules:</p> <ul> <li>Message types received with minor versions below the minimum MAY be ignored, or preferably, MAY be answered only with a <code>problem-report</code> message with code <code>version-not-supported</code>.</li> <li>Message types received with a minor version at or higher than the minimum supported and less than the current minor version are processed as follows:</li> <li>The processing MAY be with the same minor version of the received message.<ul> <li>To support this, an implementation must implement each minor version from minimum to current within the major version.</li> </ul> </li> <li>The processing MAY be with the current minor version (higher than received).<ul> <li>This approach is used when maintaining each minor version from minimum to current within the major version is impractical.</li> <li>Recipients of the response message SHOULD detect from the response PIURI that a higher minor version was used in the response, and to compensate if needed and as necessary.</li> <li>Prior wording of this protocol included the following suggestion that is now considered deprecated. See note below about deprecating the \"warning\" problem reports.</li> <li>In addition to responding with the protocol message (if necessary), the agent MAY also want to send a warning <code>problem-report</code> message with code <code>version-with-degraded-../../features</code>.</li> </ul> </li> <li>Message types received with a minor version higher than the current minor version MUST be processed with any unrecognized fields ignored.</li> <li>The response MUST use the current minor version.</li> <li>Recipients of the response message SHOULD detect from the response PIURI that a lower minor version was used in the response, and to compensate if needed and as necessary.</li> <li>Prior wording of this protocol included the following that is now considered deprecated. See note below about deprecating the \"warning\" problem reports.<ul> <li>In addition to responding with the protocol message, an agent MAY send a warning <code>problem-report</code> message with code <code>fields-ignored-due-to-version-mismatch</code></li> </ul> </li> </ul> <p>Note: The deprecation of the \"warning\" <code>problem-reports</code> in cases of minor version mismatches is because the recipient of the response can detect the mismatch by looking at the PIURI, making the \"warning\" unnecessary, and because the <code>problem-report</code> message may be received after (and definitely at a different time than) the response message, and so the warning is of very little value to the recipient. Recipients should still be aware that minor version mismatch warning <code>problem-report</code> messages may be received and handle them appropriately, likely by quietly ignoring them.</p> <p>As documented in the semver documentation, these requirements are not applied when major version 0 is used. In that case, minor version increments are considered breaking.</p> <p>Agents may support multiple major versions and select which major version to use when initiating an instance of the protocol.</p> <p>An agent should reject messages from protocols or unsupported protocol major versions with a <code>problem-report</code> message with code <code>version-not-supported</code>. Agents that receive such a <code>problem-report</code> message may use the discover ../../features protocol to resolve the mismatch.</p>"},{"location":"concepts/0003-protocols/#semver-examples","title":"Semver Examples","text":""},{"location":"concepts/0003-protocols/#initiator","title":"Initiator","text":"<p>Unless Alice's agent (the initiator of a protocol) knows from prior history that it should do something different, it should begin a protocol using the highest version number that it supports. For example, if A.1 supports versions 2.0 through 2.2 of protocol X, it should use 2.2 as the version in the message type of its first message.</p>"},{"location":"concepts/0003-protocols/#recipient-rules","title":"Recipient Rules","text":"<p>Agents for Bob (the recipient) should reject messages from protocols with major versions different from those they support. For major version 0, they should also reject protocols with minor versions they don't support, since semver stipulates that ../../features are not stable before 1.0. For example, if B.1 supports only versions 2.0 and 2.1 of protocol X, it should reject any messages from version 3 or version 1 or 0. In most cases, rejecting a message means sending a <code>problem-report</code> that the message is unsupported. The <code>code</code> field in such messages should be <code>version-not-supported</code>. Agents that receive such a <code>problem-report</code> can then use the Discover Features Protocol to resolve version problems.</p> <p>Recipient agents should accept messages that differ from their own supported version of a protocol only in the patch, prerelease, and/or build fields, whether these differences make the message earlier or later than the version the recipient prefers. These messages will be robustly compatible.</p> <p>For major version &gt;= 1, recipients should also accept messages that differ only in that the message's minor version is earlier than their own preference. In such a case, the recipient should degrade gracefully to use the earlier version of the protocol. If the earlier version lacks important ../../features, the recipient may optionally choose to send, in addition to a response, a <code>problem-report</code> with code <code>version-with-degraded-../../features</code>.</p> <p>If a recipient supports protocol X version 1.0, it should tentatively accept messages with later minor versions (e.g., 1.2). Message types that differ in only in minor version are guaranteed to be compatible for the feature set of the earlier version. That is, a 1.0-capable agent can support 1.0 ../../features using a 1.2 message, though of course it will lose any ../../features that 1.2 added. Thus, accepting such a message could have two possible outcomes:</p> <ol> <li> <p>The message at version 1.2 might look and behave exactly like it did at version 1.0, in which case the message will process without any trouble.</p> </li> <li> <p>The message might contain some fields that are unrecognized and need to be ignored.</p> </li> </ol> <p>In case 2, it is best practice for the recipient to send a <code>problem-report</code> that is a warning, not an error, announcing that some fields could not be processed (code = <code>fields-ignored-due-to-version-mismatch</code>). Such a message is in addition to any response that the protocol demands of the recipient.</p> <p>If the recipient of a protocol's initial message generates a response, the response should use the latest major.minor protocol version that both parties support and know about. Generally, all messages after the first use only major.minor</p> <p></p>"},{"location":"concepts/0003-protocols/#state-details-and-state-machines","title":"State Details and State Machines","text":"<p>While some protocols have only one sequence of states to manage, in most different roles perceive the interaction differently. The sequence of states for each role needs to be described with care in the RFC.</p>"},{"location":"concepts/0003-protocols/#state-machines","title":"State Machines","text":"<p>By convention, protocol state and sequence rules are described using the concept of state machines, and we encourage developers who implement protocols to build them that way.</p> <p>Among other benefits, this helps with error handling: when one agent sends a <code>problem-report</code> message to another, the message can make it crystal clear which state it has fallen back to as a result of the error.</p> <p>Many developers will have encountered a formal of definition of state machines as they wrote parsers or worked on other highly demanding tasks, and may worry that state machines are heavy and intimidating. But as they are used in Aries protocols, state machines are straightforward and elegant. They cleanly encapsulate logic that would otherwise be a bunch of conditionals scattered throughout agent code. The tictactoe example protocol example includes a complete state machine in less than 50 lines of python code, with tests.</p> <p>For an extended discussion of how state machines can be used, including in nested protocols, and with hooks that let custom processing happen at each point in a flow, see https://github.com/dhh1128/distributed-state-machine.</p>"},{"location":"concepts/0003-protocols/#processing-points","title":"Processing Points","text":"<p>A protocol definition describes key points in the flow where business logic can attach. Some of these processing points are obvious, because the protocol makes calls for decisions to be made. Others are implicit. Some examples include:</p> <ul> <li>The beginning and end.</li> <li>The launch of a subprotocol.</li> <li>The completion of a subprotocol, or the subprotocol changing state.</li> <li>Sending a message. (For each send, the sender could choose to go silent and abandon the interaction instead, though many protocols would ask for notification to be emitted as best practice.)</li> <li>(Receiving a message_. (Requires validation, then integration with policy and processes internal to the agent and its sovereign domain, to move the interaction forward.)</li> </ul>"},{"location":"concepts/0003-protocols/#roles-participants-parties-and-controllers","title":"Roles, Participants, Parties, and Controllers","text":""},{"location":"concepts/0003-protocols/#roles","title":"Roles","text":"<p>The roles in a protocol are the perspectives (responsibilities, privileges) that parties take in an interaction.</p> <p>This perspective is manifested in three general ways:</p> <ul> <li>by the expectations that a party takes on in a protocol (ex. a role may be expected to do something to start a protocol).</li> <li>by the messages that a party can and does use in the course of the protocol (some messages may be reserved for a single role, while other may used by some if not all roles).</li> <li>by the state and the transition rules</li> </ul> <p>Like parties, roles are normally known at the start of the protocol but this is not a requirement.</p> <p>In an auction protocol, there are only two roles\u2014auctioneer and bidder\u2014even though there may be many parties involved.</p>"},{"location":"concepts/0003-protocols/#participants","title":"Participants","text":"<p>The participants in a protocol are the agents that send and/or receive plaintext application-level messages that embody the protocol's interaction. Alice, Bob, and Carol may each have a cloud agent, a laptop, and a phone; if they engage in an introduction protocol using phones, then the agents on their phones are the participants. If the phones talk directly over Bluetooth, this is particularly clear--but even if the phones leverage push notifications and HTTP such that cloud agents help with routing, only the phone agents are participants, because only they maintain state for the interaction underway. (The cloud agents would be facilitators, and the laptops would be bystanders). When a protocol is complete, the participant agents know about the outcome; they may need to synchronize or replicate their state before other agents of the parties are aware.</p>"},{"location":"concepts/0003-protocols/#parties","title":"Parties","text":"<p>The parties to a protocol are the entities directly responsible for achieving the protocol's goals. When a protocol is high-level, parties are typically people or organizations; as protocols become lower-level, parties may be specific agents tasked with detail work through delegation.</p> <p>Imagine a situation where Alice wants a vacation. She engages with a travel agent named Bob. Together, they begin an \"arrange a vacation\" protocol. Alice is responsible for expressing her parameters and proving her willingness to pay; Bob is responsible for running a bunch of subprotocols to work out the details. Alice and Bob--not software agents they use--are parties to this high-level protocol, since they share responsibility for its goals.</p> <p>As soon as Alice has provided enough direction and hangs up the phone, Bob begins a sub-protocol with a hotel to book a room for Alice. This sub-protocol has related but different goals--it is about booking a particular hotel room, not about the vacation as a whole. We can see the difference when we consider that Bob could abandon the booking and choose a different hotel entirely, without affecting the overarching \"arrange a vacation\" protocol.</p> <p>With the change in goal, the parties have now changed, too. Bob and a hotel concierge are the ones responsible for making the \"book a hotel room\" protocol progress. Alice is an approver and indirect stakeholder, but she is not doing the work. (In RACI terms, Alice is an \"accountable\" or \"approving\" entity, but only Bob and the concierge are \"responsible\" parties.)</p> <p>Now, as part of the hotel reservation, Bob tells the concierge that the guest would like access to a waverunner to play in the ocean on day 2. The concierge engages in a sub-sub-protocol to reserve the waverunner. The goal of this sub-sub-protocol is to reserve the equipment, not to book a hotel or arrange a vacation. The parties to this sub-sub-protocol are the concierge and the person or automated system that manages waverunners.</p> <p>Often, parties are known at the start of a protocol; however, that is not a requirement. Some protocols might commence with some parties not yet known or assigned.</p> <p>For many protocols, there are only two parties, and they are in a pairwise relationship. Other protocols are more complex. Introductions involves three; an auction may involve many.</p> <p>Normally, the parties that are involved in a protocol also participate in the interaction but this is not always the case. Consider a gossip protocol, two parties may be talking about a third party. In this case, the third party would not even know that the protocol was happening and would definitely not participate.</p>"},{"location":"concepts/0003-protocols/#controllers","title":"Controllers","text":"<p>The controllers in a protocol are entities that make decisions. They may or may not be direct parties.</p> <p>Imagine a remote chess game between Bob and Carol, conducted with software agents. The chess protocol isn't technically about how to select a wise chess move; it's about communicating the moves so parties achieve the shared goal of running a game to completion. Yet choices about moves are clearly made as the protocol unfolds. These choices are made by controllers--Bob and Carol--while the agents responsible for the work of moving the game forward wait with the protocol suspended.</p> <p>In this case, Bob and Carol could be analyzed as parties to the protocol, as well as controllers. But in other cases, the ../../concepts are distinct. For example, in a protocol to issue credentials, the issuing institution might use an AI and/or business automation as a controller.</p>"},{"location":"concepts/0003-protocols/#instructions-for-protocol-rfcs","title":"Instructions for Protocol RFCs","text":"<p>A protocol RFC conforms to general RFC patterns, but includes some specific substructure.</p> <p></p> <p>Please see the special protocol RFC template for details.</p>"},{"location":"concepts/0003-protocols/#drawbacks","title":"Drawbacks","text":"<p>This RFC creates some formalism around defining protocols. It doesn't go nearly as far as SOAP or CORBA/COM did, but it is slightly more demanding of a protocol author than the familiar world of RESTful Swagger/OpenAPI.</p> <p>The extra complexity is justified by the greater demands that agent-to-agent communications place on the protocol definition. See notes in Prior Art section for details.</p>"},{"location":"concepts/0003-protocols/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Some of the simplest DIDComm protocols could be specified in a Swagger/OpenAPI style. This would give some nice tooling. However, not all fit into that mold. It may be desirable to create conversion tools that allow Swagger interop.</p>"},{"location":"concepts/0003-protocols/#prior-art","title":"Prior art","text":""},{"location":"concepts/0003-protocols/#bpmn","title":"BPMN","text":"<p>BPMN (Business Process Model and Notation) is a graphical language for modeling flows of all types (plus things less like our protocols as well). BPMN is a mature standard sponsored by OMG(Object Management Group). It has a nice tool ecosystem (such as this). It also has an XML file format, so the visual diagrams have a two-way transformation to and from formal written language. And it has a code generation mode, where BPMN can be used to drive executable behavior if diagrams are sufficiently detailed and sufficiently standard. (Since BPMN supports various extensions and is often used at various levels of formality, execution is not its most common application.)</p> <p>BPMN began with a focus on centralized processes (those driven by a business entity), with diagrams organized around the goal of the point-of-view entity and what they experience in the interaction. This is somewhat different from a DIDComm protocol where any given entity may experience the goal and the scope of interaction differently; the state machine for a home inspector in the \"buy a home\" protocol is quite different, and somewhat separable, from the state machine of the buyer, and that of the title insurance company.</p> <p>BPMN 2.0 introduced the notion of a choreography, which is much closer to the concept of an A2A protocol, and which has quite an elegant and intuitive visual representation. However, even a BPMN choreography doesn't have a way to discuss interactions with decorators, adoption of generic messages, and other A2A-specific concerns. Thus, we may lean on BPMN for some diagramming tasks, but it is not a substitute for the RFC definition procedure described here.</p>"},{"location":"concepts/0003-protocols/#wsdl","title":"WSDL","text":"<p>WSDL (Web Services Description Language) is a web-centric evolution of earlier, RPC-style interface definition languages like IDL in all its varieties and CORBA. These technologies describe a called interface, but they don't describe the caller, and they lack a formalism for capturing state changes, especiall by the caller. They are also out of favor in the programmer community at present, as being too heavy, too fragile, or poorly supported by current tools.</p>"},{"location":"concepts/0003-protocols/#swagger-openapi","title":"Swagger / OpenAPI","text":"<p>Swagger / OpenAPI overlaps with some of the concerns of protocol definition in agent-to-agent  interactions. We like the tools and the convenience of the paradigm  offered by OpenAPI, but where these two do not overlap, we have impedance.</p> <p>Agent-to-agent protocols must support more than 2 roles, or  two roles that are peers, whereas RESTful web services assume just client  and server--and only the server has a documented API.</p> <p>Agent-to-agent protocols are fundamentally asynchronous,  whereas RESTful web services mostly assume synchronous request~response.</p> <p>Agent-to-agent protocols have complex considerations for diffuse trust,  whereas RESTful web services centralize trust in the web server.</p> <p>Agent-to-agent protocols need to support transports beyond HTTP, whereas  RESTful web services do not.</p> <p>Agent-to-agent protocols are nestable, while  RESTful web services don't provide any special support for that construct.</p>"},{"location":"concepts/0003-protocols/#other","title":"Other","text":"<ul> <li>Pdef (Protocol Definition Language): An alternative to Swagger.</li> <li>JSON RPC: Defines how invocation of  remote methods can be accomplished by passing JSON messages. However, the  RPC paradigm assumes request/response pairs, and does not provide a way  to describe state and roles carefully.</li> <li>IPC Protocol Definition Language (IPDL):  This is much closer to agent protocols in terms of its scope of concerns  than OpenAPI. However, it is C++ only, and intended for use within browser  plugins.</li> </ul>"},{"location":"concepts/0003-protocols/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Should we write a Swagger translator?</li> <li>If not swagger, what formal definition format should we use in the future?</li> </ul>"},{"location":"concepts/0003-protocols/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python several protocols, circa Feb 2019 Aries Framework - .NET several protocols, circa Feb 2019 Streetcred.id several protocols, circa Feb 2019 Aries Cloud Agent - Python numerous protocols plus extension mechanism for pluggable protocols Aries Static Agent - Python 2 or 3 protocols Aries Framework - Go DID Exchange Connect.Me mature but proprietary protocols; community protocols in process Verity mature but proprietary protocols; community protocols in process Aries Protocol Test Suite 2 or 3 core protocols; active work to implement all that are ACCEPTED, since this tests conformance of other agents Pico Labs implemented protocols: connections, trust_ping, basicmessage, routing"},{"location":"concepts/0003-protocols/roles-participants-etc/","title":"Roles participants etc","text":""},{"location":"concepts/0003-protocols/roles-participants-etc/#roles-participants-parties-and-controllers","title":"Roles, Participants, Parties, and Controllers","text":""},{"location":"concepts/0003-protocols/roles-participants-etc/#roles","title":"Roles","text":"<p>The roles in a protocol are the perspectives (responsibilities, privileges) that parties take i an interaction.</p> <p>This perspective is manifested in three general ways:</p> <ul> <li>by the expectations that a party takes on in a protocol (ex. a role may be expected to do something to start a protocol).</li> <li>by the messages that a party can and does use in the course of the protocol (some messages may be reserved for a single role, while other may used by some if not all roles).</li> <li>by the state and the transition rules</li> </ul> <p>Like parties, roles are normally known at the start of the protocol but this is not a requirement.</p> <p>In an auction protocol, there are only two roles\u2014auctioneer and bidder\u2014even though there may be many parties involved.</p>"},{"location":"concepts/0003-protocols/roles-participants-etc/#participants","title":"Participants","text":"<p>The participants in a protocol are the agents that send and/or receive plaintext application-level messages that embody the protocol's interaction. Alice, Bob, and Carol may each have a cloud agent, a laptop, and a phone; if they engage in an introduction protocol using phones, then the agents on their phones are the participants. If the phones talk directly over Bluetooth, this is particularly clear--but even if the phones leverage push notifications and HTTP such that cloud agents help with routing, only the phone agents are participants, because only they maintain state for the interaction underway. (The cloud agents would be facilitators, and the laptops would be bystanders). When a protocol is complete, the participant agents know about the outcome; they may need to synchronize or replicate their state before other agents of the parties are aware.</p>"},{"location":"concepts/0003-protocols/roles-participants-etc/#parties","title":"Parties","text":"<p>The parties to a protocol are the entities directly responsible for achieving the protocol's goals. When a protocol is high-level, parties are typically people or organizations; as protocols become lower-level, parties may be specific agents tasked with detail work through delegation.</p> <p>Imagine a situation where Alice wants a vacation. She engages with a travel agent named Bob. Together, they begin an \"arrange a vacation\" protocol. Alice is responsible for expressing her parameters and proving her willingness to pay; Bob is responsible for running a bunch of subprotocols to work out the details. Alice and Bob--not software agents they use--are parties to this high-level protocol, since they share responsibility for its goals.</p> <p>As soon as Alice has provided enough direction and hangs up the phone, Bob begins a sub-protocol with a hotel to book a room for Alice. This sub-protocol has related but different goals--it is about booking a particular hotel room, not about the vacation as a whole. We can see the difference when we consider that Bob could abandon the booking and choose a different hotel entirely, without affecting the overarching \"arrange a vacation\" protocol.</p> <p>With the change in goal, the parties have now changed, too. Bob and a hotel concierge are the ones responsible for making the \"book a hotel room\" protocol progress. Alice is an approver and indirect stakeholder, but she is not doing the work. (In RACI terms, Alice is an \"accountable\" or \"approving\" entity, but only Bob and the concierge are \"responsible\" parties.)</p> <p>Now, as part of the hotel reservation, Bob tells the concierge that the guest would like access to a waverunner to play in the ocean on day 2. The concierge engages in a sub-sub-protocol to reserve the waverunner. The goal of this sub-sub-protocol is to reserve the equipment, not to book a hotel or arrange a vacation. The parties to this sub-sub-protocol are the concierge and the person or automated system that manages waverunners.</p> <p>Often, parties are known at the start of a protocol; however, that is not a requirement. Some protocols might commence with some parties not yet known or assigned.</p> <p>For many protocols, there are only two parties, and they are in a pairwise relationship. Other protocols are more complex. Introductions involves three; an auction may involve many.</p> <p>Normally, the parties that are involved in a protocol also participate in the interaction but this is not always the case. Consider a gossip protocol, two parties may be talking about a third party. In this case, the third party would not even know that the protocol was happening and would definitely not participate.</p>"},{"location":"concepts/0003-protocols/roles-participants-etc/#controllers","title":"Controllers","text":"<p>The controllers in a protocol are entities that make decisions. They may or may not be direct parties.</p> <p>Imagine a remote chess game between Bob and Carol, conducted with software agents. The chess protocol isn't technically about how to select a wise chess move; it's about communicating the moves so parties achieve the shared goal of running a game to completion. Yet choices about moves are clearly made as the protocol unfolds. These choices are made by controllers--Bob and Carol--while the agents responsible for the work of moving the game forward wait with the protocol suspended.</p> <p>In this case, Bob and Carol could be analyzed as parties to the protocol, as well as controllers. But in other cases, the concepts are distinct. For example, in a protocol to issue credentials, the issuing institution might use an AI and/or business automation as a controller.</p>"},{"location":"concepts/0003-protocols/tictactoe/","title":"Tic Tac Toe Protocol 1.0","text":""},{"location":"concepts/0003-protocols/tictactoe/#summary","title":"Summary","text":"<p>Describes a simple protocol, already familiar to most developers, as a way to demonstrate how all protocols should be documented.</p>"},{"location":"concepts/0003-protocols/tictactoe/#motivation","title":"Motivation","text":"<p>Playing tic-tac-toe is a good way to test whether agents are working properly, since it requires two parties to take turns and to communicate reliably about state. However, it is also pretty simple, and it has a low bar for trust (it's not dangerous to play tic-tac-toe with a malicious stranger). Thus, we expect agent tic-tac-toe to be a good way to test basic plumbing and to identify functional gaps. The game also provides a way of testing interactions with the human owners of agents, or of hooking up an agent AI.</p>"},{"location":"concepts/0003-protocols/tictactoe/#tutorial","title":"Tutorial","text":"<p>Tic-tac-toe is a simple game where players take turns placing Xs and Os in a 3x3 grid, attempting to capture 3 cells of the grid in a straight line.</p>"},{"location":"concepts/0003-protocols/tictactoe/#name-and-version","title":"Name and Version","text":"<p>This defines the <code>tictactoe</code> protocol, version 1.x, as identified by the following PIURI:</p> <pre><code>did:sov:SLfEi9esrjzybysFxQZbfq;spec/tictactoe/1.0\n</code></pre>"},{"location":"concepts/0003-protocols/tictactoe/#key-concepts","title":"Key Concepts","text":"<p>A tic-tac-toe game is an interaction where 2 parties take turns to make up to 9 moves. It starts when either party proposes the game, and ends when one of the parties wins, or when all all cells in the grid are occupied but nobody has won (a draw).</p> <p>Note: Optionally, a Tic-Tac-Toe game can be preceded by a Coin Flip Protocol to decide who goes first. This is not a high-value enhancement, but we add it for illustration purposes. If used, the <code>choice-id</code> field in the initial <code>propose</code> message of the Coin Flip should have the value <code>did:sov:SLfEi9esrjzybysFxQZbfq;spec/tictactoe/1.0/who-goes-first</code>, and the <code>caller-wins</code> and <code>flipper-wins</code> fields should contain the DIDs of the two players.</p> <p>Illegal moves and moving out of turn are errors that trigger a complaint from the other player. However, they do not scuttle the interaction. A game can also be abandoned in an unfinished state by either player, for any reason. Games can last any amount of time.</p> <pre><code>About the Key Concepts section: Here we describe the flow at a very\nhigh level. We identify preconditions, ways the protocol can start\nand end, and what can go wrong. We also talk about timing\nconstraints and other assumptions.\n</code></pre>"},{"location":"concepts/0003-protocols/tictactoe/#roles","title":"Roles","text":"<p>There are two parties in a tic-tac-toe game, but only one role, <code>player</code>. One player places 'X' for the duration of a game; the other places 'O'. There are no special requirements about who can be a player. The parties do not need to be trusted or even known to one another, either at the outset or as the game proceeds. No prior setup is required, other than an ability to communicate.</p> <pre><code>About the Roles section: Here we name the roles in the protocol,\nsay who and how many can play each role, and describe constraints.\nWe also explore qualifications for roles.\n</code></pre>"},{"location":"concepts/0003-protocols/tictactoe/#states","title":"States","text":"<p>The states of each <code>player</code> in the protocol evolve according to the following state machine:</p> <p></p> <p>When a player is in the <code>my-move</code> state, possible valid events include <code>send move</code> (the normal case), <code>send outcome</code> (if the player decides to abandon the game), and <code>receive outcome</code> (if the other player decides to abandon). A <code>receive move</code> event could conceivably occur, too-- but it would be an error on the part of the other player, and would trigger a <code>problem-report</code> message as described above, leaving the state unchanged.</p> <p>In the <code>their-move</code> state, <code>send move</code> is an impossible event for a properly behaving player. All 3 of the other events could occur, causing a state transition.</p> <p>In the <code>wrap-up</code> state, the game is over, but communication with the outcome message has not yet occurred. The logical flow is <code>send outcome</code>, whereupon the player transitions to the <code>done</code> state.</p> <pre><code>About the States section: Here we explain which states exist for each\nrole. We also enumerate the events that can occur, including messages,\nerrors, or events triggered by surrounding context, and what should\nhappen to state as a result. In this protocol, we only have one role,\nand thus only one state machine matrix. But in many protocols, each\nrole may have a different state machine.\n</code></pre>"},{"location":"concepts/0003-protocols/tictactoe/#messages","title":"Messages","text":"<p>All messages in this protocol are part of the \"tictactoe 1.0\" message family uniquely identified by this DID reference: <code>did:sov:SLfEi9esrjzybysFxQZbfq;spec/tictactoe/1.0</code></p> NOTE 1: All the messages defined in a protocol should follow  DIDComm best practices as far as how they name fields and define their data types and semantics.  NOTE 2 about the \"DID Reference\" URI that appears here: DIDs can be resolved     to a DID doc that contains an endpoint, to which everything after a     semicolon can be appended. Thus, if this DID is publicly registered     and its DID doc gives an endpoint of http://example.com, this URI     would mean that anyone can find a formal definition of the protocol at     http://example.com/spec/tictactoe/1.0. It is also possible to use a     traditional URI here, such as http://example.com/spec/tictactoe/1.0.     If that sort of URI is used, it is best practice for it to reference     immutable content, as with a link to specific commit on github:       https://github.com/hyperledger/aries-rfcs/blob/ab7a04f/concepts/0003-protocols/tictactoe/README.md#messages"},{"location":"concepts/0003-protocols/tictactoe/#move-message","title":"<code>move</code> message","text":"<p>The protocol begins when one party sends a <code>move</code> message to the other. It looks like this:</p> <p></p> <p><code>@id</code> is required here, as it establishes a message thread that will govern the rest of the game.</p> <p><code>me</code> tells which mark (X or O) the sender is placing. It is required.</p> <p><code>moves</code> is optional in the first message of the interaction. If missing or empty, the sender of the first message is inviting the recipient to make the first move. If it contains a move, the sender is moving first.</p> <p>Moves are strings like \"X:B2\" that match the regular expression <code>(?i)[XO]:[A-C][1-3]</code>. They identify a mark to be placed (\"X\" or \"O\") and a position in the 3x3 grid. The grid's columns and rows are numbered like familiar spreadsheets, with columns A, B, and C, and rows 1, 2, and 3.</p> <p><code>comment</code> is optional and probably not used much, but could be a way for players to razz one another or chat as they play. It follows the conventions of localized messages.</p> <p>Other decorators could be placed on tic-tac-toe messages, such as those to enable message timing to force players to make a move within a certain period of time.</p>"},{"location":"concepts/0003-protocols/tictactoe/#subsequent-moves","title":"Subsequent Moves","text":"<p>Once the initial <code>move</code> message has been sent, game play continues by each player taking turns sending responses, which are also <code>move</code> messages. With each new message the <code>move</code> array inside the message grows by one, ensuring that the players agree on the current accumulated state of the game. The <code>me</code> field is still required and must accurately reflect the role of the message sender; it thus alternates values between <code>X</code> and <code>O</code>.</p> <p>Subsequent messages in the game use the message threading mechanism where the <code>@id</code> of the first <code>move</code> becomes the <code>~thread.thid</code> for the duration of the game.</p> <p>An evolving sequence of <code>move</code> messages might thus look like this, suppressing all fields except what's required:</p>"},{"location":"concepts/0003-protocols/tictactoe/#messagemove-2","title":"Message/Move 2","text":"<p>This is the first message in the thread that's sent by the <code>player</code> placing \"O\"; hence it has <code>myindex</code> = 0.</p>"},{"location":"concepts/0003-protocols/tictactoe/#messagemove-3","title":"Message/Move 3","text":"<p>This is the second message in the thread by the player placing \"X\"; hence it has <code>myindex</code> = 1.</p>"},{"location":"concepts/0003-protocols/tictactoe/#messagemove-4","title":"Message/Move 4","text":"<p>...and so forth.</p> <p>Note that the order of the items in the <code>moves</code> array is NOT significant. The state of the game at any given point of time is fully captured by the moves, regardless of the order in which they were made.</p> <p>If a player makes an illegal move or another error occurs, the other player can complain using a problem-report message, with <code>explain.@l10n.code</code> set to one of the values defined in the Message Catalog section (see below).</p>"},{"location":"concepts/0003-protocols/tictactoe/#outcome-message","title":"<code>outcome</code> message","text":"<p>Game play ends when one player sends a <code>move</code> message that manages to mark 3 cells in a row. Thereupon, it is best practice, but not strictly required, for the other player to send an acknowledgement in the form of an <code>outcome</code> message.</p> <p></p> <p>The <code>moves</code> and <code>me</code> fields from a <code>move</code> message can also, optionally, be included to further document state. The <code>winner</code> field is required. Its value may be \"X\", \"O\", or--in the case of a draw--\"none\".</p> <p>This <code>outcome</code> message can also be used to document an abandoned game, in which case <code>winner</code> is <code>null</code>, and <code>comment</code> can be used to explain why (e.g., timeout, loss of interest).</p> <pre><code>About the Messages section: Here we explain the message types, but\nalso which roles send which messages, what sequencing rules apply,\nand how errors may occur during the flow. The message begins with\nan announcement of the identifier and version of the message\nfamily, and also enumerates error codes to be used with problem\nreports. This protocol is simple enough that we document the\ndatatypes and validation rules for fields inline in the narrative;\nin more complex protocols, we'd move that text into the Reference\n&gt; Messages section instead.\n</code></pre>"},{"location":"concepts/0003-protocols/tictactoe/#constraints","title":"Constraints","text":"<p>Players do not have to trust one another. Messages do not have to be authcrypted, although anoncrypted messages still have to have a path back to the sender to be useful.</p> <pre><code>About the Constraints section: Many protocols have rules\nor mechanisms that help parties build trust. For example, in buying\na house, the protocol includes such things as commission paid to\nrealtors to guarantee their incentives, title insurance, earnest\nmoney, and a phase of the process where a home inspection takes\nplace. If you are documenting a protocol that has attributes like\nthese, explain them here.\n</code></pre>"},{"location":"concepts/0003-protocols/tictactoe/#reference","title":"Reference","text":"<pre><code>About the Reference section: If the Tutorial &gt; Messages section\nsuppresses details, we would add a Messages section here to\nexhaustively describe each field. We could also include an\nExamples section to show variations on the main flow.\n</code></pre>"},{"location":"concepts/0003-protocols/tictactoe/#collateral","title":"Collateral","text":"<p>A reference implementation of the logic of a game is provided with this RFC as python 3.x code. See game.py. There is also a simple hand-coded AI that can play the game when plugged into an agent (see ai.py), and a set of unit tests that prove correctness (see test_tictactoe.py).</p> <p>A full implementation of the state machine is provided as well; see state_machine.py and test_state_machine.py.</p> <p>The game can be played interactively by running <code>python game.py</code>.</p>"},{"location":"concepts/0003-protocols/tictactoe/#localization","title":"Localization","text":"<p>The only localizable field in this message family is <code>comment</code> on both <code>move</code> and <code>outcome</code> messages. It contains ad hoc text supplied by the sender, instead of a value selected from an enumeration and identified by <code>code</code> for use with message catalogs. This means the only approach to localize <code>move</code> or <code>outcome</code> messages is to submit <code>comment</code> fields to an automated translation service. Because the locale of <code>tictactoe</code> messages is not predefined, each message must be decorated with <code>~l10n.locale</code> to make automated translation possible.</p> <p>There is one other way that localization is relevant to this protocol: in error messages. Errors are communicated through the general problem-report message type rather than through a special message type that's part of the <code>tictactoe</code> family. However, we define a catalog of tictactoe-specific error codes below to make this protocol's specific error strings localizable. </p> <p>Thus, all instances of this message family carry localization metadata in the form of an implicit <code>~l10n</code> decorator that looks like this:</p> <p></p> <p>This JSON fragment is checked in next to the narrative content of this RFC as ~l10n.json, for easy machine parsing.</p> <p>Individual messages can use the <code>~l10n</code> decorator to supplement or override these settings.</p> <p>For more information about localization concepts, see the RFC about localized messages.</p>"},{"location":"concepts/0003-protocols/tictactoe/#message-catalog","title":"Message Catalog","text":"<p>To facilitate localization of error messages, all instances of this message family assume the following catalog in their <code>~l10n</code> data:</p> <p></p> <p>When referencing this catalog, please be sure you have the correct version. The official, immutable URL to this version of the catalog file is:</p> <pre><code>https://github.com/hyperledger/indy-hipe/blob/fc7a6028/text/tictactoe-protocol/catalog.json\n</code></pre> <p>This JSON fragment is checked in next to the narrative content of this RFC as catalog.json, for easy machine parsing. The catalog currently contains localized alternatives only for English. Other language contributions would be welcome.</p> <p>For more information, see the Message Catalog section of the localization HIPE.</p>"},{"location":"concepts/0003-protocols/tictactoe/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Verity Commercially licensed enterprise agent, SaaS or on-prem. Pico Labs Open source TicTacToe for Pico Agents"},{"location":"concepts/0004-agents/","title":"Aries RFC 0004: Agents","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2019-01-15</li> <li>Status Note: On a standards track and beginning to influence many mental models, but not yet ADOPTED. </li> <li>Supersedes: Indy HIPE 0002</li> <li>Start Date: 2017-11-01 (approx, backdated)</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0004-agents/#summary","title":"Summary","text":"<p>Provide a high-level introduction to the ../../concepts of agents in the self-sovereign identity ecosystem.</p>"},{"location":"concepts/0004-agents/#tutorial","title":"Tutorial","text":"<p>Managing an identity is complex. We need tools to help us.</p> <p>In the physical world, we often delegate complexity to trusted proxies that can help. We hire an accountant to do our taxes, a real estate agent to help us buy a house, and a talent agent to help us pitch an album to a recording studio.</p> <p>On the digital landscape, humans and organizations (and sometimes, things) cannot directly consume and emit bytes, store and manage data, or perform the crypto that self-sovereign identity demands. They need delegates--agents--to help. Agents are a vital dimension across which we exercise sovereignty over identity.</p> <p></p>"},{"location":"concepts/0004-agents/#essential-characteristics","title":"Essential Characteristics","text":"<p>When we use the term \"agent\" in the SSI community, we more properly mean \"an agent of self-sovereign identity.\" This means something more specific than just a \"user agent\" or a \"software agent.\" Such an agent has three defining characteristics:</p> <ol> <li>It acts as a fiduciary on behalf of a single identity owner (or, for agents of things like IoT devices, pets, and similar things, a single controller).</li> <li>It holds cryptographic keys that uniquely embody its delegated authorization.</li> <li>It interacts using interoperable DIDComm protocols.</li> </ol> <p>These characteristics don't tie an agent to any particular blockchain. It is possible to implement agents without any use of blockchain at all (e.g., with peer DIDs), and some efforts to do so are quite active.</p>"},{"location":"concepts/0004-agents/#canonical-examples","title":"Canonical Examples","text":"<p>Three types of agents are especially common:</p> <ol> <li>A mobile app that Alice uses to manage credentials and to connect to others is an agent for Alice.</li> <li>A cloud-based service that Alice uses to expose a stable endpoint where other agents can talk to her is an agent for Alice.</li> <li>A server run by Faber College, allowing it to issue credentials to its students, is an agent for Faber.</li> </ol> <p>Depending on your perspective, you might describe these agents in various ways. #1 can correctly be called a \"mobile\" or \"edge\" or \"rich\" agent. #2 can be called a \"cloud\" or \"routing\" agent. #3 can be called an \"on-prem\" or \"edge\" or \"advanced\" agent. See Categorizing Agents for a discussion about why multiple labels are correct.</p> <p>Agents can be other things as well. They can big or small, complex or simple. They can interact and be packaged in various ways.  They can be written in a host of programming languages. Some are more canonical than others. But all the ones we intend to interact with in the self-sovereign identity problem domain share the three essential characteristics described above.</p>"},{"location":"concepts/0004-agents/#how-agents-talk","title":"How Agents Talk","text":"<p>DID communication (DIDComm), and the protocols built atop it are each rich subjects unto themselves. Here, we will stay very high-level.</p> <p>Agents can use many different communication transports: HTTP(S) 1.x and 2.0, WebSockets, IRC, Bluetooth, AMQP, NFC, Signal, email, push notifications to mobile devices, ZMQ, and more. However, all A2A is message-based, and is secured by modern, best-practice public key cryptography. How messages flow over a transport may vary--but their security and privacy toolset, their links to the DIDs and DID Docs of identity owners, and the ways their messages are packaged and handled are standard.</p> <p>Agents connect to one another through a standard connection protocol, discover one another's endpoints and keys through standard DID Docs, discover one another's ../../features in a standard way, and maintain relationships in a standard way. All of these points of standardization are what makes them interoperable.</p> <p>Because agents speak so many different ways, and because many of them won't have a permanent, accessible point of presence on the network, they can't all be thought of as web servers with a Swagger-compatible API for request-response. The analog to an API construct in agent-land is protocols. These are patterns for stateful interactions. They specify things like, \"If you want to negotiate a sale with an agent, send it a message of type X. It will respond with a message of type Y or type Z, or with an error message of type W. Repeat until the negotiation finishes.\" Some interesting A2A protocols include the one where two parties connect to one another to build a relationship, the one where agents discover which protocols they each support, the one where credentials are issued, and the one where proof is requested and sent. Hundreds of other protocols are being defined.</p>"},{"location":"concepts/0004-agents/#how-to-get-an-agent","title":"How to Get an Agent","text":"<p>As the ecosystem for self-sovereign identity matures, the average person or organization will get an agent by downloading it from the app store, installing it with their OS package manager, or subscribing to it as a service. However, the availability of quality pre-packaged agents is still limited today.</p> <p>Agent providers are emerging in the marketplace, though. Some are governments, NGOs, or educational institutions that offer agents for free; others are for-profit ventures. If you'd like suggestions about ready-to-use agent offerings, please describe your use case in <code>#aries</code> on chat.hyperledger.org.</p> <p>There is also intense activity in the SSI community around building custom agents and the tools and processes that enable them. A significant amount of early work occurred in the Indy Agent Community with some of those efforts materializing in the indy-agent repo on github.com and other code bases. The indy-agent repo is now deprecated but is still valuable in demonstrating the basics of agents. With the introduction of Hyperledger Aries, agent efforts are migrating from the Indy Agent community.</p> <p>Hyperledger Aries provides a number of code bases ranging from agent frameworks to tools to aid in development to ready-to-use agents.</p>"},{"location":"concepts/0004-agents/#how-to-write-an-agent","title":"How to Write an Agent","text":"<p>This is one of the most common questions that Aries newcomers ask. It's a challenging one to answer, because it's so open-ended. It's sort of like someone asking, \"Can you give me a recipe for dinner?\" The obvious follow-up question would be, \"What type of dinner did you have in mind?\"</p> <p>Here are some thought questions to clarify intent:</p> <ul> <li>Do you need an agent for people or institutions (or an IoT thing)?</li> <li>Will the agent run on a mobile device, in a cloud, on a server,   or elsewhere?</li> <li>Will the agent be on and connected to the internet constantly, or   will it run only from time to time?</li> <li>Which protocols should your agent implement? (In other words, what   sort of work do you want to delegate to it?)</li> <li>Will your agent talk, listen, or both? What channels/transports   will it use?</li> <li>What interesting requirements does your agent have with respect to   security, privacy, scale, and performance?</li> </ul>"},{"location":"concepts/0004-agents/#general-patterns","title":"General Patterns","text":"<p>We said it's hard to provide a recipe for an agent without specifics. However, the majority of agents do have two things in common: they listen to and process A2A messages, and they use a wallet to manage keys, credentials, and other sensitive material. Unless you have uses cases that involve IoT, cron jobs, or web hooks, your agent is likely to fit this mold.</p> <p>The heart of such an agent is probably a messaging handling loop, with pluggable protocols to give it new capabilities, and pluggable transports to let it talk in different ways. The pseudocode for its main function might look like this:</p>"},{"location":"concepts/0004-agents/#pseudocode-for-main","title":"Pseudocode for main()","text":"<pre><code>1  While not done:\n2      Get next message.\n3      Verify it (decrypt, identify sender, check signature...).\n3      Look at the type of the plaintext message.\n4      Find a plugged in protocol handler that matches that type.\n5      Give plaintext message and security metadata to handler.\n</code></pre> <p>Line 2 can be done via standard HTTP dispatch, or by checking an email inbox, or in many other ways. Line 3 can be quite sophisticated--the sender will not be Alice, but rather one of the agents that she has authorized. Verification may involve consulting cached information and/or a blockchain where a DID and DID Doc are stored, among other things.</p> <p>The pseudocode for each protocol handler it loads might look like:</p>"},{"location":"concepts/0004-agents/#pseudocode-for-protocol-handler","title":"Pseudocode for protocol handler","text":"<pre><code>1  Check authorization against metadata. Reject if needed.\n2  Read message header. Is it part of an ongoing interaction?\n3  If yes, load persisted state.\n4  Process the message and update interaction state.\n5  If a response is appropriate:\n6      Prepare response content.\n7      Ask my outbound comm module to package and send it.\n</code></pre> <p>Line 4 is the workhorse. For example, if the interaction is about issuing credentials and this agent is doing the issuance, this would be where it looks up the material for the credential in internal databases, formats it appropriately, and records the fact that the credential has now been built. Line 6 might be where that credential is attached to an outgoing message for transmission to the recipient.</p> <p>The pseudocode for the outbound communication module might be:</p>"},{"location":"concepts/0004-agents/#pseudocode-for-outbound","title":"Pseudocode for outbound","text":"<pre><code>1  Iterate through all pluggable transports to find best one to use\n     with the intended recipient.\n2  Figure out how to route the message over the selected transport.\n3  Serialize the message content and encrypt it appropriately.\n4  Send the message.\n</code></pre> <p>Line 2 can be complex. It involves looking up one or more endpoints in the DID Doc of the recipient, and finding an intersection between transports they use, and transports the sender can speak. Line 3 requires the keys of the sender, which would normally be held in a wallet.</p> <p>If you are building this sort of code using Aries technology, you will certainly want to use Aries Agent SDK. This gives you a ready-made, highly secure wallet that can be adapted to many requirements. It also provides easy functions to serialize and encrypt. Many of the operations you need to do are demonstrated in the SDK's /doc/how-tos folder, or in its Getting Started Guide.</p>"},{"location":"concepts/0004-agents/#how-to-learn-more","title":"How to Learn More","text":"<ul> <li>Hang out and ask questions on <code>#aries</code> on chat.hyperledger.org.</li> <li>Use the mailing list: aries@lists.hyperledger.org</li> <li>Follow the Aries Cloud Agent - Python Getting Started Guide (for developers)</li> <li>Study the Aries Protocol Test Suite |</li> <li>Study the sample mobile agent at github.com/sovrin-foundation/connector-app.</li> <li>Browse other RFCs.</li> <li>Attend the Aries working group on Wednesdays. (See HL community calendar for details; note that the default timezone is GMT.)</li> <li>Review this slide deck   about integrating agents with familiar web development paradigms.</li> </ul>"},{"location":"concepts/0004-agents/#reference","title":"Reference","text":""},{"location":"concepts/0004-agents/#categorizing-agents","title":"Categorizing Agents","text":"<p>Agents can be categorized in various ways, and these categories lead to terms you're likely to encounter in RFCs and other documentation. Understanding the categories will help the definitions make sense.</p>"},{"location":"concepts/0004-agents/#by-trust","title":"By Trust","text":"<p>A trustable agent runs in an environment that's under the direct control of its owner; the owner can trust it without incurring much risk. A semi-trustable agent runs in an environment where others besides the owner may have access, so giving it crucial secrets is less advisable. (An untrustable delegate should never be an agent, by definition, so we don't use that term.)</p> <p>Note that these distinctions highlight what is advisable, not how much trust the owner actually extends.</p>"},{"location":"concepts/0004-agents/#by-location","title":"By Location","text":"<p>Two related but deprecated terms are edge agent and cloud agent. You will probably hear these terms in the community or read them in docs. The problem with them is that they suggest location, but were formally defined to imply levels of trust. When they were chosen, location and levels of trust were seen as going together--you trust your edge more, and your cloud less. We've since realized that a trustable agent could exist in the cloud, if it is directly controlled by the owner, and a semi-trustable agent could be on-prem, if the owner's control is indirect. Thus we are trying to correct usage and make \"edge\" and \"cloud\" about location instead.</p>"},{"location":"concepts/0004-agents/#by-platform","title":"By Platform","text":"<ul> <li>Mobile -- likely trustable</li> <li>Workstation -- likely trustable</li> <li>Server -- could be trustable or semi-trustable</li> <li>Embedded -- trustable or semi-trustable</li> <li>Browser (web assembly or javascript) -- likely semi-trustable</li> <li>Blockchain (embodied in smart contract -- trustable?)</li> <li>Mesh (IoT\u2026)</li> <li>Paper?</li> </ul>"},{"location":"concepts/0004-agents/#by-complexity","title":"By Complexity","text":"<p>We can arrange agents on a continuum, from simple to complex. The simplest agents are static--they are preconfigured for a single relationship. Thin agents are somewhat fancier. Thick agents are fancier still, and rich agents exhibit the most sophistication and flexibility:</p> <p></p> <p>A nice visualization of several dimensions of agent category has been built by Michael Herman:</p> <p></p>"},{"location":"concepts/0004-agents/#the-agent-ness-continuum","title":"The Agent-ness Continuum","text":"<p>The tutorial above gives three essential characteristics of agents, and lists some canonical examples. This may make it feel like agent-ness is pretty binary. However, we've learned that reality is more fuzzy.</p> <p>Having a tight definition of an agent may not matter in all cases. However, it is important when we are trying to understand interoperability goals. We want agents to be able to interact with one another. Does that mean they must interact with every piece of software that is even marginally agent-like? Probably not.</p> <p>Some attributes that are not technically necessary in agents include:</p> <ul> <li>Has a wallet (common, but not universal)</li> <li>Establishes new connections (some may use only a small set of preconfigured connections)</li> <li>Exchanges credentials and proofs (some may not use these protocols)</li> <li>Both listens and talks (some may only listen or only talk)</li> </ul> <p>Agents that lack these characteristics can still be fully interoperable.</p> <p>Some interesting examples of less prototypical agents or agent-like things include:</p>"},{"location":"concepts/0004-agents/#dif-hubs","title":"DIF Hubs","text":"<p>A DIF Identity Hub is construct that resembles agents in some ways, but that focuses on the data-sharing aspects of identity. Currently DIF Hubs do not use the protocols known to the Aries community, and vice versa. However, there are efforts to bridge that gap.</p>"},{"location":"concepts/0004-agents/#identity-wallets","title":"Identity Wallets","text":"<p>\"Identity wallet\" is a term that's carefully defined in our ecosystem, and in strict, technical usage it maps to a concept much closer to \"database\" than \"agent\". This is because it is an inert storage container, not an active interacter. However, in casual usage, it may mean the software that uses a wallet to do identity work--in which case it is definitely an agent.</p>"},{"location":"concepts/0004-agents/#crypto-wallets","title":"Crypto Wallets","text":"<p>Cryptocurrency wallets are quite agent-like in that they hold keys and represent a user. However, they diverge from the agent definition in that they talk proprietary protocols to blockchains, rather than A2A to other agents.</p>"},{"location":"concepts/0004-agents/#uport","title":"uPort","text":"<p>The uPort app is an edge agent. Here, too, there are efforts to bridge a protocol gap.</p>"},{"location":"concepts/0004-agents/#learning-machine","title":"Learning Machine","text":"<p>The credential issuance technology offered by Learning Machine, and the app used to share those credentials, are agents of institutions and individuals, respectively. Again, there is a protocol gap to bridge.</p>"},{"location":"concepts/0004-agents/#cron-jobs","title":"Cron Jobs","text":"<p>A cron job that runs once a night at Faber, scanning a database and revoking credentials that have changes status during the day, is an agent for Faber. This is true even though it doesn't listen for incoming messages (it only talks revocation protocol to the ledger). In order to talk that protocol, it must hold keys delegated by Faber, and it is surely Faber's fiduciary.</p>"},{"location":"concepts/0004-agents/#operating-systems","title":"Operating Systems","text":"<p>The operating system on a laptop could be described as agent-like, in that it works for a single owner and may have a keystore. However, it doesn't talk A2A to other agents--at least not yet. (OSes that service multiple users fit the definition less.)</p>"},{"location":"concepts/0004-agents/#devices","title":"Devices","text":"<p>A device can be thought of as an agent (e.g., Alice's phone as an edge agent). However, strictly speaking, one device might run multiple agents, so this is only casually correct.</p>"},{"location":"concepts/0004-agents/#sovrin-mainnet","title":"Sovrin MainNet","text":"<p>The Sovrin MainNet can be thought of as an agent for the Sovrin community (but NOT the Sovrin Foundation, which codifies the rules but leaves operation of the network to its stewards). Certainly, the blockchain holds keys, uses A2A protocols, and acts in a fiduciary capacity toward the community to further its interests. The only challenge with this perspective is that the Sovrin community has a very fuzzy identity.</p>"},{"location":"concepts/0004-agents/#validators","title":"Validators","text":"<p>Validator nodes on a particular blockchain are agents of the stewards that operate them.</p>"},{"location":"concepts/0004-agents/#digital-assistants","title":"Digital Assistants","text":"<p>Digital assistants like Alexa and Google Home are somewhat agent-like. However, the Alexa in the home of the Jones family is probably not an agent for either the Jones family or Amazon. It accepts delegated work from anybody who talks to it (instead of a single controlling identity), and all current implementations are totally antithetical to the ethos of privacy and security required by self-sovereign identity. Although it interfaces with Amazon to download data and ../../features, it isn't Amazon's fiduciary, either. It doesn't hold keys that allow it to represent its owner. The protocols it uses are not interactions with other agents, but with non-agent entities. Perhaps agents and digtal assistants will converge in the future.</p>"},{"location":"concepts/0004-agents/#doorbell","title":"Doorbell","text":"<p>An doorbell that emits a simple signal each time it is pressed is not an agent. It doesn't represent a fiduciary or hold keys. (However, a fancy IoT doorbell that reports to Alice's mobile agent using an A2A protocol would be an agent.)</p>"},{"location":"concepts/0004-agents/#microservices","title":"Microservices","text":"<p>A microservice run by AcmeCorp to integrate with its vendors is not an agent for Acme's vendors. Depending on whether it holds keys and uses A2A protocols, it may or may not be an agent for Acme.</p>"},{"location":"concepts/0004-agents/#human-delegates","title":"Human Delegates","text":"<p>A human delegate who proves empowerment through keys might be thought of as an agent.</p>"},{"location":"concepts/0004-agents/#paper","title":"Paper","text":"<p>The keys for an agent can be stored on paper. This storage basically constitutes a wallet. It isn't an agent. However, it can be thought of as playing the role of an agent in some cases when designing backup and recovery solutions.</p>"},{"location":"concepts/0004-agents/#prior-art","title":"Prior art","text":"<ul> <li>Alan Kay, the recipient of a Turing Award and the coiner of the term \"Object-Oriented Programming\", has emphasized the value of message-passing architectures in numerous places. What he called \"objects\" are conceptually similar to what we are calling \"agents.\" Not surprisingly, the agent ecosystem echoes some aspects of the design of SmallTalk, Objective-C, Erlang Actors, Akka Actors, and similar approaches.</li> <li>The design of the web includes the concept of browsers and similar tech, and refers to them as \"user agents\" in various RFCs. These are not true SSI agents, but they provide an example of ubiquitous helper tech that is the forerunner of the agents described here.</li> </ul>"},{"location":"concepts/0004-agents/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community Aries Framework - .NET .NET framework for building agents of all types Streetcred.id Commercial mobile and web app built using Aries Framework for .NET Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Aries Framework - Go For building agents, hubs and other DIDComm ../../features in GoLang. Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem. Aries Protocol Test Suite Pico Labs Pico Agents protocols: connections, trust_ping, basicmessage, routing Rust Agent Rust implementation of a framework for building agents of all types"},{"location":"concepts/0005-didcomm/","title":"Aries RFC 0005: DID Communication","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-11-21</li> <li>Status Note: Mature as concept, with multiple implementations.</li> <li>Supersedes: Indy PR #98</li> <li>Start Date: 2018-01-05 (approx, backdated)</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0005-didcomm/#summary","title":"Summary","text":"<p>Explain the basics of DID communication (DIDComm) at a high level, and link to other RFCs to promote deeper exploration.</p> <p>NOTE: The version of DIDComm collectively defined in Aries RFCs is known by the label \"DIDComm V1.\" A newer version of DIDComm (\"DIDComm V2\") is now being incubated at DIF. Many ../../concepts are the same between the two versions, but there are some differences in the details. For information about detecting V1 versus V2, see Detecting DIDComm Versions.</p>"},{"location":"concepts/0005-didcomm/#motivation","title":"Motivation","text":"<p>The DID communication between agents and agent-like things is a rich subject with a lot of tribal knowledge. Newcomers to the decentralized identity ecosystem tend to bring mental models that are subtly divergent from its paradigm. When they encounter dissonance, DIDComm becomes mysterious. We need a standard high-level reference.</p>"},{"location":"concepts/0005-didcomm/#tutorial","title":"Tutorial","text":"<p>This discussion assumes that you have a reasonable grasp on topics like self-sovereign identity, DIDs and DID docs, and agents. If you find yourself lost, please review that material for background and starting assumptions.</p> <p>Agent-like things have to interact with one another to get work done. How they talk in general is DIDComm, the subject of this RFC. The specific interactions enabled by DIDComm--connecting and maintaining relationships, issuing credentials, providing proof, etc.--are called protocols; they are described elsewhere.</p>"},{"location":"concepts/0005-didcomm/#rough-overview","title":"Rough Overview","text":"<p>A typical DIDComm interaction works like this:</p>  Imagine Alice wants to negotiate with Bob to sell something online, and that DIDComm, not direct human communication, is involved. This means Alice's agent and Bob's agent are going to exchange a series of messages.  Alice may just press a button and be unaware of details, but underneath, her agent begins by preparing a plaintext JSON message about the proposed sale. (The particulars are irrelevant here, but would be described in the spec for a \"sell something\" protocol.) It then looks up Bob's DID Doc to access two key pieces of information:  * An endpoint (web, email, etc) where messages can be delivered to Bob. * The public key that Bob's agent is using in the Alice:Bob relationship.  Now Alice's agent uses Bob's public key to encrypt the plaintext so that only Bob's agent can read it, adding authentication with its own private key. The agent arranges delivery to Bob. This \"arranging\" can involve various hops and intermediaries. It can be complex.  Bob's agent eventually receives and decrypts the message, authenticating its origin as Alice using her public key. It prepares its response and routes it back using a reciprocal process (plaintext -&gt; lookup endpoint and public key for Alice -&gt; encrypt with authentication -&gt; arrange delivery).  <p>That's it.</p> <p>Well, mostly. The description is pretty good, if you squint, but it does not fit all DIDComm interactions:</p> <ul> <li>DIDComm doesn't always involve turn-taking and request-response.</li> <li>DIDComm interactions can involve more than 2 parties, and the parties are not always individuals.</li> <li>DIDComm may include formats other than JSON.</li> </ul> <p>Before we provide more details, let's explore what drives the design of DIDComm.</p>"},{"location":"concepts/0005-didcomm/#goals-and-ramifications","title":"Goals and Ramifications","text":"<p>The DIDComm design attempts to be:</p> <ol> <li>Secure</li> <li>Private</li> <li>Interoperable</li> <li>Transport-agnostic</li> <li>Extensible</li> </ol> <p>As a list of buzz words, this may elicit nods rather than surprise. However, several items have deep ramifications.</p> <p>Taken together, Secure and Private require that the protocol be decentralized and maximally opaque to the surveillance economy.</p> <p>Interoperable means that DIDComm should work across programming languages, blockchains, vendors, OS/platforms, networks, legal jurisdictions, geos, cryptographies, and hardware--as well as across time. That's quite a list. It means that DIDComm intends something more than just compatibility within Aries; it aims to be a future-proof lingua franca of all self-sovereign interactions.</p> <p>Transport-agnostic means that it should be possible to use DIDComm over HTTP(S) 1.x and 2.0, WebSockets, IRC, Bluetooth, AMQP, NFC, Signal, email, push notifications to mobile devices, Ham radio, multicast, snail mail, carrier pigeon, and more.</p> <p>All software design involves tradeoffs. These goals, prioritized as shown, lead down an interesting path.</p>"},{"location":"concepts/0005-didcomm/#message-based-asynchronous-and-simplex","title":"Message-Based, Asynchronous, and Simplex","text":"<p>The dominant paradigm in mobile and web development today is duplex request-response. You call an API with certain inputs, and you get back a response with certain outputs over the same channel, shortly thereafter. This is the world of OpenAPI (Swagger), and it has many virtues.</p> <p>Unfortunately, many agents are not good analogs to web servers. They may be mobile devices that turn off at unpredictable intervals and that lack a stable connection to the network. They may need to work peer-to-peer, when the internet is not available. They may need to interact in time frames of hours or days, not with 30-second timeouts. They may not listen over the same channel that they use to talk.</p> <p>Because of this, the fundamental paradigm for DIDComm is message-based, asynchronous, and simplex. Agent X sends a message over channel A. Sometime later, it may receive a response from Agent Y over channel B. This is much closer to an email paradigm than a web paradigm.</p> <p>On top of this foundation, it is possible to build elegant, synchronous request-response interactions. All of us have interacted with a friend who's emailing or texting us in near-realtime. However, interoperability begins with a least-common-denominator assumption that's simpler.</p>"},{"location":"concepts/0005-didcomm/#message-level-security-reciprocal-authentication","title":"Message-Level Security, Reciprocal Authentication","text":"<p>The security and privacy goals, and the asynchronous+simplex design decision, break familiar web assumptions in another way. Servers are commonly run by institutions, and we authenticate them with certificates. People and things are usually authenticated to servers by some sort of login process quite different from certificates, and this authentication is cached in a session object that expires. Furthermore, web security is provided at the transport level (TLS); it is not an independent attribute of the messages themselves.</p> <p>In a partially disconnected world where a comm channel is not assumed to support duplex request-response, and where the security can't be ignored as a transport problem, traditional TLS, login, and expiring sessions are impractical. Furthermore, centralized servers and certificate authorities perpetuate a power and UX imbalance between servers and clients that doesn't fit with the peer-oriented DIDComm.</p> <p>DIDComm uses public key cryptography, not certificates from some parties and passwords from others. Its security guarantees are independent of the transport over which it flows. It is sessionless (though sessions can easily be built atop it). When authentication is required, all parties do it the same way.</p>"},{"location":"concepts/0005-didcomm/#reference","title":"Reference","text":"<p>The following RFCs profide additional information: * 0021: DIDComm Message Anatomy * 0020: Message Types * 0011: Decorators * 0008: Message ID and Threading * 0019: Encryption Envelope * 0025: Agent Transports</p>"},{"location":"concepts/0005-didcomm/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community Aries Framework - .NET .NET framework for building agents of all types Streetcred.id Commercial mobile and web app built using Aries Framework - .NET Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Aries Framework - Go For building agents, hubs and other DIDComm ../../features in GoLang. Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem. Aries Protocol Test Suite Pico Labs Pico Agents protocols: connections, trust_ping, basicmessage, routing"},{"location":"concepts/0006-ssi-notation/","title":"Aries RFC 0006: SSI Notation","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2018-09-01</li> <li>Status Note: broadly accepted but not heavily used; may need greater usage before it's ready for ADOPTED status.</li> <li>Start Date: 2018-05-03</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0006-ssi-notation/#summary","title":"Summary","text":"<p>This RFC describes a simple, standard notation for various ../../concepts related to decentralized and self-sovereign identity (SSI).</p> <p>The notation could be used in design docs, other RFCs, source code comments, chat channels, scripts, debug logs, and miscellaneous technical materials throughout the Aries ecosystem. We hope it is also used in the larger SSI community.</p> <p>This RFC is complementary to official terms like the ones curated in the TOIP Concepts and Terminology Working group, the Sovrin Glossary, and so forth.</p>"},{"location":"concepts/0006-ssi-notation/#motivation","title":"Motivation","text":"<p>All technical materials in our ecosystem hinge on fundamental ../../concepts of self-sovereign identity such as controllers, keys, DIDs, and agents. We need a standard, documented notation to refer to such things, so we can use it consistently, and so we can link to the notation's spec for definitive usage.</p>"},{"location":"concepts/0006-ssi-notation/#tutorial","title":"Tutorial","text":"<p>The following explanation is meant to be read sequentially and should provide a friendly overview for most who encounter the RFC. See the Reference section for quick lookup.</p>"},{"location":"concepts/0006-ssi-notation/#requirements","title":"Requirements","text":"<p>This notation aims to be:</p> <ul> <li>Precise</li> <li>Consistent</li> <li>Terse</li> <li>Easy to learn, understand, guess, and remember</li> <li>Representable in 7-bit ASCII plain text</li> </ul> <p>The final requirement deserves special comment. Cryptologists are a major stakeholder in SSI theory. They already have many notational conventions, some more standardized than others. Generally, their notation derives from advanced math and uses specialized symbols and fonts. These experts also tend to intersect strongly with academic circles, where LaTeX and similar rendering technologies are common.</p> <p>Despite the intersection between SSI, cryptology, and academia, SSI has to serve a broader audience. Its practicioners are not just mathematicians; they may include support and IT staff, lawyers specializing in intellectual property, business people, auditors, regulators, and individuals sometimes called \"end users.\" In particular, SSI ecosystems are built and maintained by coders. Coders regularly write docs in markdown and html. They interact with one another on chat. They write emails and source code where comments might need to be embedded. They create UML diagrams. They type in shells. They paste code into slide decks and word processors. All of these behaviors militate against a notation that requires complex markup.</p> <p>Instead, we want something simple, clean, and universally supported. Hence the 7-bit ASCII requirement. A future version of this RFC, or an addendum to it, might explain how to map this 7-bit ASCII notation to various schemes that use mathematical symbols and are familiar to experts from other fields.</p>"},{"location":"concepts/0006-ssi-notation/#solution","title":"Solution","text":""},{"location":"concepts/0006-ssi-notation/#controllers-and-subjects","title":"Controllers and Subjects","text":"<p>An identified thing (the referent of an identifier) is called an identity subject. Identity subjects can include:</p> <ul> <li>passive things (pets, digital documents, symphonies, rivers, asteroids, strains of bacteria...)</li> <li>active things (people, institutions, IoT devices)</li> </ul> <p>The latter category may also act as an identity controller -- something that projects its intent with respect to identity onto the digital landscape.</p> <p>When an identity controller controls its own identity, we say that it has self sovereignty -- and we call it a self. (The term identity owner was originally used for an identity controller managing itself, but this hid some of the nuance and introduced legal ../../concepts of ownership that are problematic, so we'll avoid it here.)</p> <p>In our notation, selves (or identity controllers) are denoted with a single upper-case ASCII alpha, often corresponding to a first initial of their human-friendly name. For example, Alice might be represented as <code>A</code>. By preference, the first half of the alphabet is used (because \"x\", \"y\", and \"z\" tend to have other ad-hoc meanings). When reading aloud, the spoken form of a symbol like this is the name of the letter. The relevant ABNF fragment is:</p> <p>```ABNF   ucase-alpha    = %x41-5A            ; A-Z   lcase-alpha    = %x61-7A            ; a-z   digit          = %x30-39            ; 0-9</p> <p>self = ucase-alpha   ```</p> <p>Identity subjects that are not self-controlled are referenced in our notation using a single lower-case ASCII alpha. For example, a movie might be <code>m</code>. For clarity in scenarios where multiple subjects are referenced, it is best to choose letters that differ in something other than case.</p> <pre><code>  controlled = lcase-alpha\n\n  subject = self / controlled\n</code></pre> <p>The set of devices, keys, endpoints, data, and other resources controlled by or for a given subject is called the subject's identity domain (or just domain for short). When the controller is a self, the domain is self-sovereign; otherwise, the domain is controlled. Either way, the domain of an identity subject is like its private universe, so the name or symbol of a subject is often used to denote its domain as well; context eliminates ambiguity. You will see examples of this below.</p>"},{"location":"concepts/0006-ssi-notation/#association","title":"Association","text":"<p>Elements associated with a domain are named in a way that makes their association clear, using a <code>name@context</code> pattern familiar from email addresses: <code>1@A</code> (\u201cone at A\u201d) is agent 1 in A\u2019s sovereign domain. (Note how we use an erstwhile identity owner symbol, <code>A</code>, to reference a domain here, but there is no ambiguity.) This fully qualified form of a subject reference is useful for clarification but is often not necessary.</p> <p>In addition to domains, this same associating notation may be used where a relationship is the context, because sometimes the association is to the relationship rather than to a participant. See the DID example in the next section.</p>"},{"location":"concepts/0006-ssi-notation/#agents","title":"Agents","text":"<p>Agents are not subjects. They neither control or own a domain; rather, they live and act within it. They take instructions from the domain's controller. Agents (and hubs, and other things like them) are the first example of elements associated with an identity subject. Despite this, agent-ish things are the primary focus of interactions within SSI ecosystems.</p> <p>Additionally, agents are distinct from devices, even though we often (and inaccurately) used them interchangeably. We may say things like \"Alice's iPhone sends a message\" when we more precisely mean \"the agent on Alice's iPhone sends a message.\" In reality, there may be zero, one, or more than one agents running on a particular device.</p> <p>Agents are numbered and are represented by up to three digits and then with an association. In most discussions, one digit is plenty, but three digits are allowed so agents can be conveniently grouped by prefix (e.g., all edge agents in Alice's domain might begin with <code>1</code>, and all cloud might begin with <code>2</code>).</p> <pre><code>agent = 1*3digit \"@\" subject\n</code></pre>"},{"location":"concepts/0006-ssi-notation/#devices","title":"Devices","text":"<p>Devices are another element inside a subject's domain. They are represented with two or more lower-case ASCII alphanumerics or underscore characters, where the first char cannot be a digit. They end with an association: <code>bobs_car@B</code>, <code>drone4@F</code>, <code>alices_iphone9@A</code>.</p> <pre><code>name-start-char = lcase-alpha / \"_\"            ; a-z or underscore\nname-other-char = digit / lcase-alpha / \"_\"    ; 0-9 or a-z or underscore\ndevice = name-start-char 1*name-other-char \"@\" subject\n</code></pre>"},{"location":"concepts/0006-ssi-notation/#cross-domain-relationships","title":"Cross-Domain Relationships","text":""},{"location":"concepts/0006-ssi-notation/#short-form-more-common","title":"Short Form (more common)","text":"<p>Alice\u2019s pairwise relationship with Bob is represented with colon notation: <code>A:B</code>. This is read aloud as \u201cA to B\u201d (preferred because it\u2019s short; alternatives such as \u201cthe A B relationship\u201d or \u201cA colon B\u201d or \u201cA with respect to B\u201d are also valid). When written in the other order, it represents the same relationship as seen from Bob\u2019s point of view. Note that passive subjects may also participate in relationships: <code>A:bobs_car</code>. (Contrast Intra-Domain Relationships below.)</p> <p>N-wise relationships (e.g., doctor, hospital, patient) are written with the perspective-governing subject's identifier, a single colon, then by all other identifiers for members of the relationship, in alphabetical order, separated by <code>+</code>: <code>A:B+C</code>, <code>B:A+C</code>. This is read aloud as in \"A to B plus C.\"</p> <pre><code>next-subject = \"+\" subject\nshort-relationship = subject \":\" subject *next-subject\n</code></pre>"},{"location":"concepts/0006-ssi-notation/#long-form","title":"Long Form","text":"<p>Short form is convenient and brief, but it is inconsistent because each party to the relationship describes it differently. Sometimes this may be undesirable, so a long and consistent form is also supported. The long form of both pairwise and N-way relationships lists all participants to the right of the colon, in alphabetical order. Thus the long forms of the Alice to Bob relationship might be <code>A:A+B</code> (for Alice's view of this relationship) and <code>B:A+B</code> (for Bob's view). For a doctor, hospital, patient relationship, we might have <code>D:D+H+P</code>, <code>H:D+H+P</code>, and <code>P:D+H+P</code>. Note how the enumeration of parties to the right of the colon is consistent.</p> <p>Long form and short form are allowed to vary freely; any tools that parses this notation should treat them as synonyms and stylistic choices only.</p> <p>The ABNF for long form is identical to short form, except that we are guaranteed that after the colon, we will see at least two parties and one <code>+</code> character:</p> <pre><code>long-relationship = subject \":\" subject 1*next-subject\n</code></pre>"},{"location":"concepts/0006-ssi-notation/#generalized-relationships","title":"Generalized Relationships","text":""},{"location":"concepts/0006-ssi-notation/#contexts","title":"Contexts","text":"<p>Some models for SSI emphasize the concept of personas or contexts. These are essentially \"masks\" that an identity controller enables, exposing a limited subset of the subject's identity to an audience that shares that context. For example, Alice might assume one persona in her employment relationships, another for government interactions, another for friends, and another when she's a customer.</p> <p>Contexts or personas can be modeled as a relationship with a generalized audience: <code>A:Work</code>, <code>A:Friends</code>.</p> <pre><code>general-audience = ucase-alpha 1*name-other-char\ngeneral-relationship = subject \":\" general-audience\nrelationship = short-relationship / long-relationship / general-relationship\n</code></pre>"},{"location":"concepts/0006-ssi-notation/#any","title":"Any","text":"<p>The concept of public DIDs suggests that someone may think about a relationship as unbounded, or as not varying no matter who the other subject is. For example, a company may create a public DID and advertise it to the world, intending for this connection point to begin relationships with customers, partners, and vendors alike. While best practice suggests that such relationships be used with care, and that they primarily serve to bootstrap pairwise relationships, the notation still needs to represent the possibility.</p> <p>The token <code>Any</code> is reserved for these semantics. If Acme Corp is represented as <code>A</code>, then Acme's public persona could be denoted with <code>A:Any</code>. When <code>Any</code> is used, it is never the subject whose perspective is captured; it is always a faceless \"other\". This means that <code>Any</code> appears only on the right side of a colon in a relationship, and it probably doesn't make sense to combine it with other participants since it would subsume them all.</p>"},{"location":"concepts/0006-ssi-notation/#self","title":"Self","text":"<p>It is sometimes useful to model a relationship with onesself. This is done with the reserved token <code>Self</code>.</p>"},{"location":"concepts/0006-ssi-notation/#intra-domain-relationships","title":"Intra-Domain Relationships","text":"<p>Within a domain, relationships among agents or devices is sometimes interesting. Such relationships use the <code>~</code> (tilde) character. Thus, the intra-domain relationship between Alice's agent 1 and agent 2 is written <code>1~2</code> and read as \"one tilde two\".</p>"},{"location":"concepts/0006-ssi-notation/#constituents","title":"Constituents","text":"<p>Items that belong to a domain rather than having independent identity of their own (for example, data, money, keys) use dot notation for containment or ownership: <code>A.ls</code>, (A\u2019s link secret), <code>A.policy</code>, etc.</p> <p>Names for constituents use the same rules as names for agents and devices.</p> <p>Alice\u2019s DID for her relationship with Bob is an inert constituent datum, but it is properly associated with the relationship rather than just Alice. It is thus represented with <code>A.did@A:B</code>. (The token <code>did</code> is reserved for DIDs). This is read as \u201cA\u2019s DID at A to B\u201d. Bob\u2019s complementary DID would be <code>B.did@B:A</code>.</p> <pre><code>inert = name-start-char 1*name-other-char\nnested = \".\" inert\nowned-inert = subject 1*nested\n\nassociated-to = identity-owner / relationship\nassociated = subject 0*nested \"@\" associated-to\n</code></pre> <p>If <code>A</code> has a cloud agent <code>2</code>, then the public key (verification key or verkey) and private, secret key (signing key or sigkey) used by <code>2</code> in <code>A:B</code> would be: <code>2.pk@A:B</code> and <code>2.sk@A:B</code>. This is read as \u201c2 dot P K at A to B\u201d and \u201c2 dot S K at A to B\u201d. Here, <code>2</code> is known to belong to <code>A</code> because it takes <code>A</code>\u2019s perspective on <code>A:B</code>--it would be equivalent but unnecessary to write <code>A.2.pk@A:B</code>.</p>"},{"location":"concepts/0006-ssi-notation/#did-docs-and-did-references","title":"DID Docs and DID References","text":"<p>The mention of keys belonging to agents naturally raises the question of DID docs and the things they contain. How do they relate to our notation?</p> <p>DIDs are designed to be URIs, and items that carry an <code>id</code> property within a DID Doc can be referenced with standard URI fragment notation. This allows someone, for example, to refer to the first public key used by one of the agents owned by Alice with a notation like: <code>did:sov:VUrvFeWW2cPv9hkNZ2ms2a;#key1</code>.</p> <p>This notation is important and useful, but it is somewhat orthogonal to the concerns of this RFC. In the context of SSI notation, we are not DID-centric; we are subject centric, and subject are identified by a single capital alpha instead of by their DID. This helps with brevity. It lets us ignore the specific DID value and instead focus on the higher level semantics; compare:</p> <code>{A.did@A:B}/B --&gt; B</code> <p>...to:</p> <code>did:sov:PXqKt8sVsDu9T7BpeNqBfe</code> sends its DID for <code>did:sov:6tb15mkMRagD7YA3SBZg3p</code> to <code>did:sov:6tb15mkMRagD7YA3SBZg3p</code>, using the agent possessing <code>did:sov:PXqKt8sVsDu9T7BpeNqBfe;#key1</code> to encrypt with the corresponding signing key. <p>We expect DID reference notation (the verbose text above) to be relevant for concrete communication between computers, and SSI notation (the terse equivalent shown first) to be more convenient for symbolic, higher level discussions between human beings. Occasionally, we may get very specific and map SSI notation into DID notation (e.g., <code>A.1.vk = did:sov:PXqKt8sVsDu9T7BpeNqBfe;#key1</code>).</p>"},{"location":"concepts/0006-ssi-notation/#counting-and-iteration","title":"Counting and Iteration","text":"<p>Sometimes, a concept or value evolves over time. For example, a given discussion might need to describe a DID Doc or an endpoint or a key across multiple state changes. In mathematical notation, this would typically be modeled with subscripts. In our notation, we use square brackets, and we number beginning from zero. <code>A.pk[0]@A:B</code> would be the first pubkey used by A in the <code>A:B</code> relationship; <code>A.pk[1]@A:B</code> would be the second pubkey, and so on. Likewise, a sequence of messages could be represented with <code>msg[0]</code>, <code>msg[1]</code>, and <code>msg[2]</code>.</p>"},{"location":"concepts/0006-ssi-notation/#messages","title":"Messages","text":"<p>Messages are represented as quoted string literals, or with the reserved token <code>msg</code>, or with kebab-case names that explain their semantics, as in <code>cred-offer</code>:</p> <pre><code>string-literal = %x22 c-literal %x22\nkebab-char = lcase-alpha / digit\nkebab-suffix = \"-\" 1*hint-char\nkebab-msg = 1*kebab-char *kebab-suffix\nmessage = \"msg\" / string-literal / kebab-msg\n</code></pre>"},{"location":"concepts/0006-ssi-notation/#payments","title":"Payments","text":"<p>Economic activity is part of rich SSI ecosystems, and requires notation. A payment address is denoted with the <code>pay</code> reserved token; <code>A.pay[4]</code> would be A's fifth payment address. The public key and secret key for a payment address use the <code>ppk</code> and <code>psk</code> reserved token, respectively. Thus, one way to reference the payment keys for that payment address would be <code>A.pay[4].ppk</code> and <code>A.pay[4].psk</code>. (Keys are normally held by agents, not by people--and every agent has its own keys. Thus, another notation for the public key pertaining to this address might be <code>A.1.pay[4].ppk</code>. This is an area of clumsiness that needs further study.)</p>"},{"location":"concepts/0006-ssi-notation/#encryption","title":"Encryption","text":"<p>Encryption deserves special consideration in the SSI world. It often figures prominently in discussions about security and privacy, and our notation needs to be able to represent it carefully.</p> <p>The following crypto operations are recognized by the notation, without making a strong claim about how the operations are implemented. (For example, inline Diffie Helman and an ephemeral symmetric key might be used for the *_crypt algorithms. What is interesting to the notation isn't the low-level details, but the general semantics achieved.)</p> <ul> <li> <p><code>anon_crypt(msg, recipient_pubkey)</code> -- Encrypt only for recipient, achieving confidentiality. Sender is anonymous. Parties may have had no prior contact, though sender must discover recipient's pubkey. The message is tamper evident.</p> </li> <li> <p><code>auth_crypt(msg, recipient_pubkey, sender_privkey)</code> -- Encrypt only for recipient, achieving confidentiality. Recipient learns sender\u2019s pubkey but can\u2019t prove to anybody else who the sender is (making the message repudiable). Parties may have had no prior contact, though sender must discover recipient's pubkey. The message is tamper evident.</p> </li> <li> <p><code>sign(msg, signer_privkeys)</code> -- Associate a signature with a message, making the message non-repudiable. This also makes the message tamper-evident. A signature does not automatically encrypt and therefore is not a way to achieve confidentiality. Note that complex signature schemes (multisig, M of N, ring) use this operation as well.</p> </li> <li> <p><code>verify(msg, signature, signer_pubkeys)</code> -- Verify a signature over a message with select keys. Note that complex verification schemes (multiverify, M of N, ring) use this operation as well.</p> </li> <li> <p><code>sym_crypt(msg, sym_key)</code> -- Symmetrically encrypt for anyone who has the symmetric key, achieving a limited form of confidentiality. Key must be shared in advance with both parties. Likely tamper evident. If multiple parties know the symmetric key, the sender is not knowable to the recipient.</p> </li> </ul> <p>The notation for these crypto primitives uses curly braces around the message, with suffixes to clarify semantics. Generally, it identifies a recipient as an identity owner or thing, without clarifying the key that's used--the pairwise key for their DID is assumed.</p> <pre><code>asymmetric   = \"/\"                                   ; suffix\nsymmetric    = \"*\"                                   ; suffix\nsign         = \"#\"                                   ; suffix\nmultiplex    = \"%\"                                   ; suffix\nverify       = \"?\"                                   ; suffix\n\nanon-crypt   = \"{\" message \"}\" asymmetric subject          ; e.g., {\"hi\"}/B\n\n                ; sender is first subject in relationship, receiver is second\nauth-crypt   = \"{\" message \"}\" asymmetric short-relationship ; e.g., {\"hi\"}/A:B\n\nsym-crypt    = \"{\" message \"}\" symmetric subject           ; e.g., {\"hi\"}*B\n\nverify       = \"{\" message \"}\" verify subject              ; e.g., {\"hi\"}?B\n</code></pre> <p>The relative order of suffixes reflects whether encryption or signing takes place first: <code>{\"hello\"}*B#</code> says that symmetric encryption happens first, and then a signature is computed over the cypertext; <code>{\"hello\"#}*B</code> says that plaintext is signed, and then both the plaintext and the signature are encrypted. (The <code>{\"hello\"}#*B</code> variant is nonsensical because it splits the encryption notation in half).</p> <p>All suffixes can be further decorated with a parenthesized algorithm name, if precision is required: <code>{\"hello\"}*(aes256)B</code> or <code>{\"hello\"}/(rsa1024)A:B</code> or <code>{\"hello\"#(ecdsa)}/B</code>.</p> <p>With signing, usually the signer and sender are assumed to be identical, and the notation omits any clarification about the signer. However, this can be added after <code>#</code> to be explicit. Thus, <code>{msg#B}/C</code> would be a message with plaintext signed by B, anon-encrypted for C. Similarly, <code>{msg#(ring-rabin)BGJM}/A:C</code> would be a message with plaintext signed according to a Rabin ring signature algorithm, by B, G, J, and M, and then auth-encrypted by A for C.</p> <p>Signing verification would be over the corresponding message and which entities perform the action. <code>{msg#A}?B</code> would be a message with plaintext signed by A verified by B. <code>{msg#(threshold-sig)ABC}?DE</code> would be a plaintext message signed according to a threshold signature algorithm by A, B, C and then verified by D and E.</p> <p>Multiplexed asymmetric encryption is noted above, but has not yet been described. This is a technique whereby a message body is encrypted with an ephemeral symmetric key, and then the ephemeral key is encrypted asymmetrically for multiple potential recipients (each of which has a unique but tiny payload [the key] to decrypt, which in turn unlocks the main payload). The notation for this looks like <code>{msg}%BCDE</code> for multiplexed anon_crypt (sender is anonymous), and like <code>{msg}%A:BCDE</code> for multiplexed auth_crypt (sender is authenticated by their private key).</p>"},{"location":"concepts/0006-ssi-notation/#other-punctuation","title":"Other punctuation","text":"<p>Message sending is represented with arrows: <code>-&gt;</code> is most common, though <code>&lt;-</code> is also reasonable in some cases. Message content and notes about sending can be embedded in the hyphens of sending arrow, as in this example, where the notation says an unknown party uses http to transmit \"hello\", anon-enrcypted for Alice:</p> <p><code>&lt;unknown&gt; -- http: {\"hello\"}/A --&gt; 1</code></p> <p>Parentheses have traditional meaning (casual usage in written language, plus grouping and precedence).</p> <p>Angle braces <code>&lt;</code> and <code>&gt;</code> are for placeholders; any reasonable explanatory text may appear inside the angle braces, so to represent Alice's relationship with a not-yet-known subject, the notation might show something like <code>A:&lt;TBD&gt;</code>.</p>"},{"location":"concepts/0006-ssi-notation/#reference","title":"Reference","text":""},{"location":"concepts/0006-ssi-notation/#examples","title":"Examples","text":"<ul> <li><code>A</code>: a self (sovereign identity subject) like Alice or Acme Corp.</li> <li><code>alices_pixel@A</code> or <code>bobs_alexa@B</code>: an object in a given domain</li> <li><code>7@A</code>: an agent, arbitrarily assigned number 7</li> <li><code>A:B</code> or <code>A:A+B</code>: The Alice to Bob relationship, as seen from Alice's perspective (short form, then long form). Bob's view of this relationship would be <code>B:A</code> or <code>B:A+B</code>.</li> <li><code>B:ACD</code> or <code>B:A+B+C+D</code>: The 4-way relationship between A, B, C, and D, as seen from B's perspective (short form, then long form)</li> <li><code>A:Dating</code>: Alice's dating persona</li> <li><code>A.pay[3].ppk</code>: The public payment key for the fourth payment address belonging to A.</li> <li><code>F.did@F:Any</code>: Faber's public DID.</li> <li><code>C.ls</code>: Carol's link secret.</li> <li><code>D.padr</code>: Doug's policy address.</li> <li><code>F.state@F:A</code>: F's state for the F:A relationship.</li> <li><code>A.uri@A:B</code>: Alice's URI (endpoint of DID doc) in the Alice to Bob relationship.</li> <li><code>F.uri@F:Any</code>: The endpoint where the DID doc for Faber's public DID is hosted.</li> <li><code>escrow-offer</code>: A message that represents step 1a in a standard negotiation about escrow. (The escrow concept is unknown to the notation, and we don't know the format of its messages, but we know they are used in a standard way because of the <code>-offer</code> kebab suffix).</li> <li><code>{msg}/A</code>: A message anon-encrypted for A.</li> <li><code>{\"hello\"}/A:B</code>: A message auth-encrypted for B by A.</li> <li><code>{bail-req#(p2sh)DF}/(rsa)B</code>: A message that represents step 1b or step 2 in a standard negotiaion about bail. This message was signed as plaintext using the p2sh multisig algorithm by D and F, and was then anon-encrypted for B using an RSA algorithm.</li> <li><code>{advice-receipt}*A</code>: A message that that represents step 4 in a standard negotiaion about advice. The message was symmetrically encrypted and sent to A.</li> <li><code>{msg[4]}%C:1+2</code>: A message (5<sup>th</sup> in sequence) that was multiplex-encrypted by C for agents 1 and 2.</li> </ul>"},{"location":"concepts/0006-ssi-notation/#reserved-tokens","title":"Reserved Tokens","text":"<ul> <li><code>Any</code>: The name for the public side of a relationship between a specific subject and the public.</li> <li><code>Self</code>: The name for one's one identity in a self relationship.</li> <li><code>did</code>: The DID belonging to an subject in a given relationship, as in <code>A.did@A:B</code></li> <li><code>ipk</code> and <code>isk</code>: Issuer public (verification) key and issuer secret key.</li> <li><code>key</code>: A symmetric key.</li> <li><code>ls</code>: The link secret belonging to an subject, as in <code>A.ls</code>.</li> <li><code>state</code>: The state belonging to an subject in a given relationship, as in <code>A.state@A:B</code></li> <li><code>msg</code>: A generic message.</li> <li><code>-offer</code>: kebab suffix for messages that express willingness to give    something.</li> <li><code>padr</code>: a policy address, as in <code>F.padr</code>.</li> <li><code>pay</code>: A payment address belonging to an identity owner, as in <code>C.pay</code>.</li> <li><code>ppk</code> and <code>psk</code>: Payment address public (verification) and secret key (control    cryptocurrency).</li> <li><code>pk</code>: The public verification key (verkey) portion of an asymmetric keypair. The more specific form, <code>vk</code>, is only recommended if elliptic curve crypto is specifically intended.</li> <li><code>-receipt</code>: kebab suffix for messages that formally acknowledge receipt after receiving a delivered item.</li> <li><code>-req</code>: kebab suffix for messages that formally request something.</li> <li><code>rpk</code> and <code>rsk</code>: Revocation public (verification) and secret key.</li> <li><code>sk</code>: The private key (privkey, sigkey) portion of an asymmetric keypair.</li> <li><code>uri</code>: An endpoint for a relationship, as in <code>B.uri@A:B</code></li> <li><code>vk</code>: The public verification key (verkey) portion of an asymmetric keypair. The more generic form, <code>pk</code>, is recommended instead, unless elliptic curve crypto is specifically intended.</li> <li><code>wallet</code>: An identity wallet belonging to an subject.</li> </ul>"},{"location":"concepts/0006-ssi-notation/#abnf","title":"ABNF","text":"<pre><code>ucase-alpha    = %x41-5A                        ; A-Z\nlcase-alpha    = %x61-7A                        ; a-z\ndigit          = %x30-39                        ; 0-9\nname-start-char = lcase-alpha / \"_\"             ; a-z or underscore\nname-other-char = digit / lcase-alpha / \"_\"     ; 0-9 or a-z or underscore\n\nidentity-owner = ucase-alpha\nthing = lcase-alpha\nsubject = identity-owner / thing\n\nagent = 1*3digit \"@\" subject\ndevice = name-start-char 1*name-other-char \"@\" subject\n\nnext-subject = \"+\" subject\nshort-relationship = subject \":\" subject *next-subject\nlong-relationship = subject \":\" subject 1*next-subject\ngeneral-audience = ucase-alpha 1*name-other-char\ngeneral-relationship = subject \":\" general-audience\nrelationship = short-relationship / long-relationship / general-relationship\n\ninert = name-start-char 1*name-other-char\nnested = \".\" inert\nowned-inert = subject 1*nested\n\nassociated-to = identity-owner / relationship\nassociated = subject 0*nested \"@\" associated-to\n\nstring-literal = %x22 c-literal %x22\nkebab-char = lcase-alpha / digit\nkebab-suffix = \"-\" 1*hint-char\nkebab-msg = 1*kebab-char *kebab-suffix\nmessage = \"msg\" / string-literal / kebab-msg\n\nasymmetric   = \"/\"                                   ; suffix\nsymmetric    = \"*\"                                   ; suffix\nsign         = \"#\"                                   ; suffix\nmultiplex    = \"%\"                                   ; suffix\n\nanon-crypt   = \"{\" message \"}\" asymmetric subject          ; e.g., {\"hi\"}/B\n\n                ; sender is first subject in relationship, receiver is second\nauth-crypt   = \"{\" message asymmetric short-relationship ; e.g., {\"hi\"}/A:B\n\nsym-crypt    = \"{\" message \"}\" symmetric subject           ; e.g., {\"hi\"}*B\n</code></pre>"},{"location":"concepts/0006-ssi-notation/#drawbacks","title":"Drawbacks","text":"<ul> <li>Creates one more formalism to learn. SSI is already a dense topic with a steep learning curve.</li> <li>Creates something that needs to be version-controlled.</li> </ul>"},{"location":"concepts/0006-ssi-notation/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Could use informal verbiage instead. However, it would be inconsistent and poorly documented.</li> </ul>"},{"location":"concepts/0006-ssi-notation/#prior-art","title":"Prior art","text":"<ul> <li> <p>LaTeX provides powerful and beautiful rendering of complex formal ../../concepts, and uses escape sequences that are pure ASCII. There is a JVM-based parser/renderer for Latex; perhaps similar things exist for other programming languages as well.</p> <p>However, LaTeX has drawbacks. It focuses on rendering, not on the semantics behind what's rendered. In this respect, it is a bit like HTML 1.0 before CSS--you can bold or underline, but you're usually encoding what something looks like, not what it means. (LaTeX does support logical styles and sections, but this introduces far more complexity than we need.)</p> <p>The LaTeX snippet <code>e^{-x_y}</code> should render like this:</p> <p></p> <p>This is great--but it doesn't say anything about what <code>e</code>, <code>x</code>, and <code>y</code> mean. Thus a LaTeX solution would still have to define conventions for meaning in a separate spec. These conventions would have to find representations that are not obvious (LaTeX recommends no particular rendering for encryption functions, keys, ownership, association). And such a spec would have to be careful not to ascribe meaning to a rendering that conflicts with assumptions of knowledgeable LaTeX users (e.g., using <code>\\sqrt</code> for something other than its mathematical square root function in the vocabulary would raise eyebrows).</p> <p>Highly formatted LaTeX is also quite verbose.</p> <p>A very simple form of LaTeX could be used (e.g., just superscripts and subscripts)-- but this would have to solve some of the problems mentioned below, in the DKMS section.</p> </li> <li> <p>ASCIIMath has many of the same benefits and drawbacks as LaTeX. It is less ubiquitous.</p> </li> <li> <p>The key management notation introduced in \"DKMS (Decentralized Key Management System) V3\" overlaps significantly with the concerns of this notation (render this diagram for an example). However, it does not encompass all the concerns explored here, so it would have to be expanded before it could be complete.</p> </li> </ul> <p>Also, experiments with superscripts and subscripts in this format led to semantic   dead ends or undesirable nesting when patterns were applied consistently. For   example, one thought had us representing Alice's verkey, signing key, and DID for her   Bob relationship with A<sub>B</sub><sup>VK</sup>, A<sub>B</sub><sup>SK</sup>.   and A<sub>B</sub><sup>DID</sup>. This was fine until we asked how to represent   the verkey for Alice's agent in the Alice to Bob relationship; is that   A<sub>B</sub><sup>DID<sup>VK</sup></sup>? And what about Alice's link secret, that   isn't relationship-specific? And how would we handle N-way relationships?</p>"},{"location":"concepts/0006-ssi-notation/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Do we need to support non-ASCII characters in the notation? (I suggest no--for coders   wishing to share simple algebra-like notes in comments or on chat, ASCII is a reasonable   least-common denominator usable with any keyboard or natural language. Adding more complicates   too many things.)</li> <li>Do we need special notation for credentials, proofs, and the like? If so, how does   this relate to ZKLang?</li> <li>Do we need notation for security contexts of messages?</li> </ul>"},{"location":"concepts/0006-ssi-notation/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Peer DID Method Spec uses notation in diagrams"},{"location":"concepts/0008-message-id-and-threading/","title":"Aries RFC 0008: Message ID and Threading","text":"<ul> <li>Authors: Daniel Bluhm, Sam Curren, Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2018-10-01</li> <li>Status Note: Implemented broadly in Indy, but not yet elsewhere.</li> <li>Start Date: 2018-08-03</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0008-message-id-and-threading/#summary","title":"Summary","text":"<p>Definition of the message @id field and the ~thread decorator.</p>"},{"location":"concepts/0008-message-id-and-threading/#motivation","title":"Motivation","text":"<p>Referring to messages is useful in many interactions. A standard method of adding a message ID promotes good patterns in message families. When multiple messages are coordinated in a message flow, the threading pattern helps avoid having to re-roll the same spec for each message family that needs it.</p>"},{"location":"concepts/0008-message-id-and-threading/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0008-message-id-and-threading/#message-ids","title":"Message IDs","text":"<p>Message IDs are specified with the @id attribute, which comes from JSON-LD. The sender of the message is responsible for creating the message ID, and any message can be identified by the combination of the sender and the message ID. Message IDs should be considered to be opaque identifiers by any recipients.</p>"},{"location":"concepts/0008-message-id-and-threading/#message-id-requirements","title":"Message ID Requirements","text":"<ul> <li>A short stream of characters matching regex <code>[-_./a-ZA-Z0-9]{8,64}</code> (Note the   special semantics of a dotted suffix on IDs,   as described in the message tracing HIPE proposal)</li> <li>Should be compared case-sensitive (no case folding)</li> <li>Sufficiently unique</li> <li>UUID recommended</li> </ul>"},{"location":"concepts/0008-message-id-and-threading/#example","title":"Example","text":"<pre><code>{\n    \"@type\": \"did:example:12345...;spec/example_family/1.0/example_type\",\n    \"@id\": \"98fd8d72-80f6-4419-abc2-c65ea39d0f38\",\n    \"example_attribute\": \"stuff\"\n}\n</code></pre> <p>The following was pulled from this document written by Daniel Hardman and stored in the Sovrin Foundation's <code>protocol</code> repository.</p>"},{"location":"concepts/0008-message-id-and-threading/#threaded-messages","title":"Threaded Messages","text":"<p>Message threading will be implemented as a decorator to messages, for example:</p> <pre><code>{\n    \"@type\": \"did:example:12345...;spec/example_family/1.0/example_type\",\n    \"@id\": \"98fd8d72-80f6-4419-abc2-c65ea39d0f38\",\n    \"~thread\": {\n        \"thid\": \"98fd8d72-80f6-4419-abc2-c65ea39d0f38\",\n        \"pthid\": \"1e513ad4-48c9-444e-9e7e-5b8b45c5e325\",\n        \"sender_order\": 3,\n        \"received_orders\": {\"did:sov:abcxyz\":1},\n        \"goal_code\": \"aries.vc.issue\"\n    },\n    \"example_attribute\": \"example_value\"\n}\n</code></pre> <p>The <code>~thread</code> decorator is generally required on any type of response, since this is what connects it with the original request.</p> <p>While not recommended, the initial message of a new protocol instance MAY have an empty (<code>{}</code>) <code>~thread</code> item. Aries agents receiving a message with an empty <code>~thread</code> item MUST gracefully handle such a message.</p>"},{"location":"concepts/0008-message-id-and-threading/#thread-object","title":"Thread object","text":"<p>A thread object has the following fields discussed below:</p> <ul> <li><code>thid</code>: The ID of the message that serves as the thread start.</li> <li><code>pthid</code>: An optional parent <code>thid</code>. Used when branching or nesting a new interaction off of an existing one.</li> <li><code>sender_order</code>: A number that tells where this message fits in the sequence of all messages that the current sender has contributed to this thread.</li> <li><code>received_orders</code>: Reports the highest <code>sender_order</code> value that the sender has seen   from other sender(s) on the thread. (This value is often missing if it   is the first message in an interaction, but should be used otherwise,   as it provides an implicit ACK.)</li> <li><code>goal_code</code>: Optional. See RFC 0519: Goal Codes.</li> </ul>"},{"location":"concepts/0008-message-id-and-threading/#thread-id-thid","title":"Thread ID (<code>thid</code>)","text":"<p>Because multiple interactions can happen simultaneously, it's important to differentiate between them. This is done with a Thread ID or <code>thid</code>.</p> <p>If the Thread object is defined and a <code>thid</code> is given, the Thread ID is the value given there. But if the Thread object is not defined in a message, the Thread ID is  implicitly defined as the Message ID (<code>@id</code>) of the given message and that message is the first message of a new thread.</p>"},{"location":"concepts/0008-message-id-and-threading/#sender-order-sender_order","title":"Sender Order (<code>sender_order</code>)","text":"<p>It is desirable to know how messages within a thread should be ordered. However, it is very difficult to know with confidence the absolute ordering of events scattered across a distributed system. Alice and Bob may each send a message before receiving the other's response, but be unsure whether their message was composed before the other's. Timestamping cannot resolve an impasse. Therefore, there is no unified absolute ordering of all messages within a thread--but there is an ordering of all messages emitted by a each participant.</p> <p>In a given thread, the first message from each party has a <code>sender_order</code> value of 0, the second message sent from each party has a <code>sender_order</code> value of 1, and so forth. Note that both Alice and Bob use 0 and 1, without regard to whether the other party may be known to have used them. This gives a strong ordering with respect to each party's messages, and it means that any message can be uniquely identified in an interaction by its <code>thid</code>, the sender DID and/or key, and the <code>sender_order</code>.</p>"},{"location":"concepts/0008-message-id-and-threading/#received-orders-received_orders","title":"Received Orders (<code>received_orders</code>)","text":"<p>In an interaction, it may be useful for the recipient of a message to know if their last message was received. A <code>received_orders</code> value addresses this need, and could be included as a best practice to help detect missing messages.</p> <p>In the example above, if Alice is the sender, and Bob is identified by <code>did:sov:abcxyz</code>, then Alice is saying, \"Here's my message with index 3 (<code>sender_order</code>=3), and I'm sending it in response to your message 1 (<code>received_orders: {&lt;bob's DID&gt;: 1}</code>. Apparently Alice has been more chatty than Bob in this exchange.</p> <p>The <code>received_orders</code> field is plural to acknowledge the possibility of multiple parties. In pairwise interactions, this may seem odd. However, n-wise interactions are possible (e.g., in a doctor ~ hospital ~ patient n-wise relationship). Even in pairwise, multiple agents on either side may introduce other actors. This may happen even if an interaction is designed to be 2-party (e.g., an intermediate party emits an error unexpectedly).</p> <p>In an interaction with more parties, the <code>received_orders</code> object has a key/value pair for each <code>actor</code>/<code>sender_order</code>, where <code>actor</code> is a DID or a key for an agent:</p> <pre><code>\"received_orders\": {\"did:sov:abcxyz\":1, \"did:sov:defghi\":14}\n</code></pre> <p>Here, the <code>received_orders</code> fragment makes a claim about the last <code>sender_order</code> that the sender observed from <code>did:sov:abcxyz</code> and <code>did:sov:defghi</code>. The sender of this fragment is presumably some other DID, implying that 3 parties are participating. Any parties unnamed in <code>received_orders</code> have an undefined value for <code>received_orders</code>. This is NOT the same as saying that they have made no observable contribution to the thread. To make that claim, use the special value <code>-1</code>, as in:</p> <pre><code>\"received_orders\": {\"did:sov:abcxyz\":1, \"did:sov:defghi\":14, \"did:sov:jklmno\":-1}\n</code></pre>"},{"location":"concepts/0008-message-id-and-threading/#example_1","title":"Example","text":"<p>As an example, Alice is an issuer and she offers a credential to Bob.</p> <ul> <li>Alice sends a CRED_OFFER as the start of a new thread, <code>@id</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0.</li> <li>Bob responds with a CRED_REQUEST, <code>@id</code>=&lt;uuid2&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0, <code>received_orders:{alice:0}</code>.</li> <li>Alice sends a CRED, <code>@id</code>=&lt;uuid3&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=1, <code>received_orders:{bob:0}</code>.</li> <li>Bob responds with an ACK, <code>@id</code>=&lt;uuid4&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=1, <code>received_orders:{alice:1}</code>.</li> </ul>"},{"location":"concepts/0008-message-id-and-threading/#nested-interactions-parent-thread-id-or-pthid","title":"Nested interactions (Parent Thread ID or <code>pthid</code>)","text":"<p>Sometimes there are interactions that need to occur with the same party, while an existing interaction is in-flight.</p> <p>When an interaction is nested within another, the initiator of a new interaction can include a Parent Thread ID (<code>pthid</code>). This signals to the other party that this is a thread that is branching off of an existing interaction.</p>"},{"location":"concepts/0008-message-id-and-threading/#nested-example","title":"Nested Example","text":"<p>As before, Alice is an issuer and she offers a credential to Bob. This time, she wants a bit more information before she is comfortable providing a credential.</p> <ul> <li>Alice sends a CRED_OFFER as the start of a new thread, <code>@id</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0.</li> <li>Bob responds with a CRED_REQUEST, <code>@id</code>=&lt;uuid2&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0, <code>received_orders:{alice:0}</code>.</li> <li>Alice sends a PROOF_REQUEST, <code>@id</code>=&lt;uuid3&gt;, <code>pthid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0. Note the subthread, the parent thread ID, and the reset <code>sender_order</code> value.</li> <li>Bob sends a PROOF, <code>@id</code>=&lt;uuid4&gt;, <code>thid</code>=&lt;uuid3&gt;,<code>sender_order</code>=0, <code>received_orders:{alice:0}</code>.</li> <li>Alice sends a CRED, <code>@id</code>=&lt;uuid5&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=1, <code>received_orders:{bob:0}</code>.</li> <li>Bob responds with an ACK, <code>@id</code>=&lt;uuid6&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=1, <code>received_orders:{alice:1}</code>.</li> </ul> <p>All of the steps are the same, except the two bolded steps that are part of a nested interaction.</p>"},{"location":"concepts/0008-message-id-and-threading/#implicit-threads","title":"Implicit Threads","text":"<p>Threads reference a Message ID as the origin of the thread. This allows any message to be the start of a thread, even if not originally intended. Any message without an explicit <code>~thread</code> attribute can be considered to have the following <code>~thread</code> attribute implicitly present.</p> <pre><code>\"~thread\": {\n    \"thid\": &lt;same as @id of the outer message&gt;,\n    \"sender_order\": 0\n}\n</code></pre>"},{"location":"concepts/0008-message-id-and-threading/#implicit-replies","title":"Implicit Replies","text":"<p>A message that contains a <code>~thread</code> block with a <code>thid</code> different from the outer message <code>@id</code>, but no <code>sender_order</code> is considered an implicit reply. Implicit replies have a <code>sender_order</code> of <code>0</code> and an <code>received_orders:{other:0}</code>. Implicit replies should only be used when a further message thread is not anticipated. When further messages in the thread are expected, a full regular <code>~thread</code> block should be used.</p> <p>Example Message with am Implicit Reply:</p> <p><pre><code>{\n    \"@id\": \"&lt;@id of outer message&gt;\",\n    \"~thread\": {\n        \"thid\": \"&lt;different than @id of outer message&gt;\"\n    }\n}\n</code></pre> Effective Message with defaults in place: <pre><code>{\n    \"@id\": \"&lt;@id of outer message&gt;\",\n    \"~thread\": {\n        \"thid\": \"&lt;different than @id of outer message&gt;\"\n        \"sender_order\": 0,\n        \"received_orders\": { \"DID of sender\":0 }\n    }\n}\n</code></pre></p>"},{"location":"concepts/0008-message-id-and-threading/#reference","title":"Reference","text":"<ul> <li>Message Packaging document from Sovrin Foundation Protocol Repo</li> <li>Very brief summary of discussion from Agent Summit on Decorators</li> </ul>"},{"location":"concepts/0008-message-id-and-threading/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"concepts/0008-message-id-and-threading/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Implement threading for each message type that needs it.</li> </ul>"},{"location":"concepts/0008-message-id-and-threading/#prior-art","title":"Prior art","text":"<p>If you're aware of relevant prior-art, please add it here.</p>"},{"location":"concepts/0008-message-id-and-threading/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Using a wrapping method for threading has been discussed but most seemed in favor of the annotated method. Any remaining arguments to be made in favor of the wrapping method?</li> </ul>"},{"location":"concepts/0008-message-id-and-threading/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem. Aries Protocol Test Suite"},{"location":"concepts/0011-decorators/","title":"Aries RFC 0011: Decorators","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-01-31</li> <li>Status Note: broadly used in Indy, but not yet harmonized with DIF work on hubs.</li> <li>Start Date: 2018-12-14</li> <li>Tags: concept, decorator</li> </ul>"},{"location":"concepts/0011-decorators/#summary","title":"Summary","text":"<p>Explain how decorators work in DID communication.</p>"},{"location":"concepts/0011-decorators/#motivation","title":"Motivation","text":"<p>Certain semantic patterns manifest over and over again in communication. For example, all communication needs the pattern of testing the type of message received. The pattern of identifying a message and referencing it later is likely to be useful in a high percentage of all protocols that are ever written. A pattern that associates messages with debugging/tracing/timing metadata is equally relevant. And so forth.</p> <p>We need a way to convey metadata that embodies these patterns, without complicating schemas, bloating core definitions, managing complicated inheritance hierarchies, or confusing one another. It needs to be elegant, powerful, and adaptable.</p>"},{"location":"concepts/0011-decorators/#tutorial","title":"Tutorial","text":"<p>A decorator is an optional chunk of JSON that conveys metadata. Decorators are not declared in a core schema but rather supplementary to it. Decorators add semantic content broadly relevant to messaging in general, and not so much tied to the problem domain of a specific type of interaction.</p> <p>You can think of decorators as a sort of mixin for agent-to-agent messaging. This is not a perfect analogy, but it is a good one. Decorators in DIDComm also have some overlap (but not a direct congruence) with annotations in Java, attributes in C#, and both decorators and annotations in python.</p>"},{"location":"concepts/0011-decorators/#simple-example","title":"Simple Example","text":"<p>Imagine we are designing a protocol and associated messages to arrange meetings between two people. We might come up with a <code>meeting_proposal</code> message that looks like this:</p> <pre><code>{\n  \"@id\": \"e2987006-a18a-4544-9596-5ad0d9390c8b\",\n  \"@type\": \"did:sov:8700e296a1458aad0d93;spec/meetings/1.0/proposal\",\n  \"proposed_time\": \"2019-12-23 17:00\",\n  \"proposed_place\": \"at the cathedral, Barf\u00fcsserplatz, Basel\",\n  \"comment\": \"Let's walk through the Christmas market.\"\n}\n</code></pre> <p>Now we tackle the <code>meeting_proposal_response</code> messages. Maybe we start with something exceedingly simple, like:</p> <pre><code>{\n  \"@id\": \"d9390ce2-8ba1-4544-9596-9870065ad08a\",\n  \"@type\": \"did:sov:8700e296a1458aad0d93;spec/meetings/1.0/response\",\n  \"agree\": true,\n  \"comment\": \"See you there!\"\n}\n</code></pre> <p>But we quickly realize that the asynchronous nature of messaging will expose a gap in our message design: if Alice receives two meeting proposals from Bob at the same time, there is nothing to bind a response back to the specific proposal it addresses.</p> <p>We could extend the schema of our response so it contains an <code>thread</code> that references the <code>@id</code> of the original proposal. This would work. However, it does not satsify the DRY principle of software design, because when we tackle the protocol for negotiating a purchase between buyer and seller next week, we will need the same solution all over again. The result would be a proliferation of schemas that all address the same basic need for associating request and response. Worse, they might do it in different ways, cluttering the mental model for everyone and making the underlying patterns less obvious.</p> <p>What we want instead is a way to inject into any message the idea of a thread, such that we can easily associate responses with requests, errors with the messages that triggered them, and child interactions that branch off of the main one. This is the subject of the message threading RFC, and the solution is the <code>~thread</code> decorator, which can be added to any response:</p> <p><pre><code>{\n  \"@id\": \"d9390ce2-8ba1-4544-9596-9870065ad08a\",\n  \"@type\": \"did:sov:8700e296a1458aad0d93;spec/meetings/1.0/response\",\n  \"~thread\": {\"thid\": \"e2987006-a18a-4544-9596-5ad0d9390c8b\"},\n  \"agree\": true,\n  \"comment\": \"See you there!\"\n}\n</code></pre> This chunk of JSON is defined independent of any particular message schema, but is understood to be available in all DIDComm schemas.</p>"},{"location":"concepts/0011-decorators/#basic-conventions","title":"Basic Conventions","text":"<p>Decorators are defined in RFCs that document a general pattern such as message threading RFC or message localization. The documentation for a decorator explains its semantics and offers examples.</p> <p>Decorators are recognized by name. The name must begin with the <code>~</code> character (which is reserved in DIDComm messages for decorator use), and be a short, single-line string suitable for use as a JSON attribute name.</p> <p>Decorators may be simple key:value pairs <code>\"~foo\": \"bar\"</code>. Or they may associate a key with a more complex structure:</p> <pre><code>\"~thread\": {\n  \"thid\": \"e2987006-a18a-4544-9596-5ad0d9390c8b\",\n  \"pthid\": \"0c8be298-45a1-48a4-5996-d0d95a397006\",\n  \"sender_order\": 0\n}\n</code></pre> <p>Decorators should be thought of as supplementary to the problem-domain-specific fields of a message, in that they describe general communication issues relevant to a broad array of message types. Entities that handle messages should treat all unrecognized fields as valid but meaningless, and decorators are no exception. Thus, software that doesn't recognize a decorator should ignore it.</p> <p>However, this does not mean that decorators are necessarily optional. Some messages may intend something tied so tightly to a decorator's semantics that the decorator effectively becomes required. An example of this is the relationship between a general error reporting mechanism and the <code>~thread</code> decorator: it's not very helpful to report errors without the context that a thread provides.</p> <p>Because decorators are general by design and intent, we don't expect namespacing to be a major concern. The community agrees on decorators that everybody will recognize, and they acquire global scope upon acceptance. Their globalness is part of their utility. Effectively, decorator names are like reserved words in a shared public language of messages.</p> <p>Namespacing is also supported, as we may discover legitimate uses. When namespaces are desired, dotted name notation is used, as in <code>~mynamespace.mydecoratorname</code>. We may elaborate this topic more in the future.</p> <p>Decorators are orthogonal to JSON-LD constructs in DIDComm messages.</p>"},{"location":"concepts/0011-decorators/#versioning","title":"Versioning","text":"<p>We hope that community-defined decorators are very stable. However, new fields (a non-breaking change) might need to be added to complex decorators; occasionally, more significant changes might be necessary as well. Therefore, decorators do support semver-style versioning, but in a form that allows details to be ignored unless or until they become important. The rules are:</p> <ol> <li>As with all other aspects of DIDComm messages, unrecognized fields in decorators must be ignored.</li> <li>Version information can be appended to the name of a decorator, as in <code>~mydecorator/1</code>. Only a major version (never minor or patch) is used, since:<ul> <li>Minor version variations should not break decorator handling code.</li> <li>The dot character <code>.</code> is reserved for namespacing within field names.</li> <li>The extra complexity is not worth the small amount of value it might add.</li> </ul> </li> <li>A decorator without a version is considered to be synonymous with version 1.0, and the version-less form is preferred. This allows version numbers to be added only in the uncommon cases where they are necessary.</li> </ol>"},{"location":"concepts/0011-decorators/#decorator-scope","title":"Decorator Scope","text":"<p>A decorator may be understood to decorate (add semantics) at several different scopes. The discussion thus far has focused on message decorators, and this is by far the most important scope to understand. But there are more possibilities.</p> <p>Suppose we wanted to decorate an individual field. This can be done with a field decorator, which is a sibling field to the field it decorates. The name of decorated field is combined with a decorator suffix, as follows:</p> <p><pre><code>{\n  \"note\": \"Let's have a picnic.\",\n  \"note~l10n\": { ... }\n}\n</code></pre> In this example, taken from the localization pattern, <code>note~l10n</code> decorates <code>note</code>.</p> <p>Besides a single message or a single field, consider the following scopes as decorator targets:</p> <ul> <li>Message Family: An decorator can be declared in documentation for the   message family, explaining semantics that apply to all message instances in the   family unless overridden at a narrower scope. This is not the same as declaring the   decorator's structure to be part of the schema of a message family; this is saying   that the field values in a concrete instance of a decorator applies to all instances   of a message family. The localization pattern contemplates this usage as a way to   declare default localization semantics.</li> <li>Message Type:   A decorator can be declared in the documentation on a specific message   type. If this happens, semantics of the decorator on the message type should be   understood as overriding or enriching the semantics of that same decorator on the   parent message family, since the scope is becoming more specific.</li> <li>Message Thread or thread tree: A participant in a   thread could send a message containing nothing but the <code>~thread</code> with one or   more additional decorators inside it. This should be viewed as a statement of semantics that   apply to subsequent communications from the sender, on that thread, until further   notice or until overridden at the scope of an individual message instance. (While   powerful, applying a decorator to this scope may be a burden on receivers because   it requires them to be stateful. Therefore this usage, though theoretically possible,   may be undesirable. If community members want to explore this, they are encouraged   to discuss broadly, first.)</li> <li>Connection. It is conceivable that Alice could bundle up a set of decorators   and send them to Bob as a way of saying \"Hey, Bob: unless/until subsequent interactions   give you more specific semantics, here's a set of semantics (settings for our connection)   that you should assume for all interactions.\" (This may or may not be useful. It introduces ambiguity--should settings declared   at this scope override those at the scope of a message family or message type? It   also adds a burden of remembering to another party; some of what informs the interaction   isn't present in the bits that flow later on. Thus, this style of decorator is also   left as a possibility for future exploration and is not actively supported at present.)</li> </ul>"},{"location":"concepts/0011-decorators/#reference","title":"Reference","text":"<p>This section of this RFC will be kept up-to-date with a list of globally accepted decorators, and links to the RFCs that define them.</p> <ul> <li><code>~thread</code>: provide request/reply and threading semantics</li> <li><code>~timing</code>: timestamps, expiration, elapsed time</li> <li><code>~trace</code>: collaborative debugging and monitoring</li> <li><code>~l10n</code>: localization support</li> </ul>"},{"location":"concepts/0011-decorators/#drawbacks","title":"Drawbacks","text":"<p>By having fields that are meaningful yet not declared in core schemas, we run the risk that parsing and validation routines will fail to enforce details that are significant but invisible. We also accept the possibility that interop may look good on paper, but fail due to different understandings of important metadata.</p> <p>We believe this risk will take care of itself, for the most part, as real-life usage accumulates and decorators become a familiar and central part of the thinking for developers who work with agent-to-agent communication.</p>"},{"location":"concepts/0011-decorators/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>There is ongoing work in the <code>#indy-semantics</code> channel on Rocket.Chat to explore the concept of overlays. These are layers of additional meaning that accumulate above a schema base. Decorators as described here are quite similar in intent. There are some subtle differences, though. The most interesting is that decorators as described here may be applied to things that are not schema-like (e.g., to a message family as a whole, or to a connection, not just to an individual message).</p> <p>We may be able to resolve these two worldviews, such that decorators are viewed as overlays and inherit some overlay goodness as a result. However, it is unlikely that decorators will change significantly in form or substance as a result. We thus believe the current mental model is already RFC-worthy, and represents a reasonable foundation for immediate use.</p>"},{"location":"concepts/0011-decorators/#prior-art","title":"Prior art","text":"<p>See references to similar ../../features in programming languages like Java, C#, and Python, mentiond above.</p> <p>See also this series of blog posts about semantic gaps and the need to manage intent in a declarative style: [ Lacunas Everywhere, Bridging the Lacuna Humana, Introducing Marks, Mountains,  Molehills, and Markedness ]</p>"},{"location":"concepts/0011-decorators/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Are we doing enough about namespacing and collision avoidance with JSON-LD?</li> <li>What should we do, if anything, about versioning decorators?</li> <li>What should we do, if anything, about applying decorators to stateful scopes   like a connection or a thread?</li> </ul>"},{"location":"concepts/0011-decorators/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries RFCs: RFC 0008, RFC 0017, RFC 0015, RFC 0023, RFC 0043, RFC 0056, RFC 0075 many implemented RFCs depend on decorators... Indy Cloud Agent - Python message threading Aries Framework - .NET message threading Streetcred.id message threading Aries Cloud Agent - Python message threading, attachments Aries Static Agent - Python message threading Aries Framework - Go message threading Connect.Me message threading Verity message threading Aries Protocol Test Suite message threading"},{"location":"concepts/0013-overlays/","title":"Aries RFC 0013: Overlays","text":"<ul> <li>Authors: Paul Knowles, The Human Colossus Foundation</li> <li>Status: RETIRED</li> <li>Since: 2023-01-15</li> <li>Status Note: Although this RFP is in the retired status, the use of overlays and the Overlays Capture Architecture (OCA) is active in Aries. This RFP is an early of the OCA specification, and its content is replaced by the Overlays Capture Architecture Specification. The use of OCA in Aries is described in RFC 0755: OCA for Aries.</li> <li>Start Date: 2018-10-01</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0017-attachments/","title":"Aries RFC 0017: Attachments","text":"<ul> <li>Authors: Daniel Hardman, Sam Curren, Andrew Whitehead</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Used in a number of other RFCs.</li> <li>Start Date: 2018-12-24</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0017-attachments/#summary","title":"Summary","text":"<p>Explains the three canonical ways to attach data to an agent message.</p>"},{"location":"concepts/0017-attachments/#motivation","title":"Motivation","text":"<p>DIDComm messages use a structured format with a defined schema and a small inventory of scalar data types (string, number, date, etc). However, it will be quite common for messages to supplement formalized exchange with arbitrary data--images, documents, or types of media not yet invented.</p> <p>We need a way to \"attach\" such content to DIDComm messages. This method must be flexible, powerful, and usable without requiring new schema updates for every dynamic variation.</p>"},{"location":"concepts/0017-attachments/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0017-attachments/#messages-versus-data","title":"Messages versus Data","text":"<p>Before explaining how to associate data with a message, it is worth pondering exactly how these two categories of information differ. It is common for newcomers to DIDComm to argue that messages are just data, and vice versa. After all, any data can be transmitted over DIDComm; doesn't that turn it into a message? And any message can be saved; doesn't that make it data?</p> <p>While it is true that messages and data are highly related, some semantic differences matter:</p> <ul> <li> <p>Messages are primarily about communication. Their meaning is tied to a communication context. Messages are a mechanism whereby state evolves in a protocol. Protocols are versioned according to the structure and semantics of messages. Messages are usually small, consisting of a modest number of fields with a structure that's focused on furthering the goals of their protocol.</p> </li> <li> <p>Data has meaning at rest, in many different DIDComm protocols, or in important contexts beyond DIDComm. Data may be very large and very complex. It may come in formats that are quite independent from DIDComm, versioned independently from the protocols that share it. Data may be produced, consumed or handled as part of a protocol, but the actual content of the data is usually not where processing at the protocol level focuses. In agent codebases, it would be common for data handling to be implemented in different classes or libraries from the handlers for messages.</p> </li> </ul> <p>Some examples:</p> <ul> <li> <p>A protocol to negotiate the release of medical records might cause X-Rays, genomes, and many other artifacts to be transmitted. These artifacts are data, whereas the information packets that arrange the transmission and provide a carrying mechanism for the artifacts are messages.</p> </li> <li> <p>A DIDComm message can be used to report an error. Descriptive parameters that change how the error is processed are probably part of the message, whereas a log file that provides supporting information should be thought of as data rather than the message.</p> </li> <li> <p>The protocol for issuing credentials consists of messages that flow through certain steps. One of the steps eventually delivers a credential. The credential is data; it has meaning even when the protocol is complete, and the protocol version may evolve independent of the data format of the credential itself. The fact that the credential is transmitted through a message does not change the credential's primary status as data.</p> </li> <li> <p>A protocol to schedule a venue for an event might produce a confirmation message when it finishes. This message might include a map of the venue, instructions about how to unlock the gate, pictures of certain resources, and so forth. This collateral is data, whereas the messages that signal progression through the steps of scheduling are not.</p> </li> <li> <p>The DID Exchange Protocol exchanges messages to establish a connection between two parties. Part of what's exchanged is a DID Doc. The DID Doc is more like data than it is like an ordinary message, since it has meaning at rest and outside the protocol.</p> </li> </ul> <p>The line between these two ../../concepts may not be perfectly crisp in all cases, and that is okay. It is clear enough, most of the time, to provide context for the central question of this RFC, which is:</p> <p>How do we send data along with messages?</p>"},{"location":"concepts/0017-attachments/#3-ways","title":"3 Ways","text":"<p>Data can be \"attached\" to DIDComm messages in 3 ways:</p> <ol> <li>Inlining</li> <li>Embedding</li> <li>Appending</li> </ol>"},{"location":"concepts/0017-attachments/#inlining","title":"Inlining","text":"<p>In inlining, data is directly assigned as the value paired with a JSON key in a DIDComm message. For example, a message about arranging a rendezvous may inline data about a location: </p> <p>This inlined data is in Google Maps pinning format. It has a meaning at rest, outside the message that conveys it, and the versioning of its structure may evolve independently of the versioning of the rendezvous protocol.</p> <p>Only JSON data can be inlined, since any other data format would break JSON format rules.</p>"},{"location":"concepts/0017-attachments/#embedding","title":"Embedding","text":"<p>In embedding, a JSON data structure called an attachment descriptor is assigned as the value paired with a JSON key in a DIDComm message. (Or, an array of attachment descriptors could be assigned.) By convention, the key name for such attachment fields ends with <code>~attach</code>, making it a field-level decorator that can share common handling logic in agent code. The attachment descriptor structure describes the MIME type and other properties of the data, in much the same way that MIME headers and body describe and contain an attachment in an email message. Given an imaginary protocol that photographers could use to share their favorite photo with friends, the embedded data might manifest like this:</p> <p></p> <p>Embedding is a less direct mechanism than inlining, because the data is no longer readable by a human inspecting the message; it is base64url-encoded instead. A benefit of this approach is that the data can be any MIME type instead of just JSON, and that the data comes with useful metadata that can facilitate saving it as a separate file.</p>"},{"location":"concepts/0017-attachments/#appending","title":"Appending","text":"<p>Appending is accomplished using the <code>~attach</code> decorator, which can be added to any message to include arbitrary data. The decorator is an array of attachment descriptor structures (the same structure used for embedding). For example, a message that conveys evidence found at a crime scene might include the following decorator:</p> <p></p>"},{"location":"concepts/0017-attachments/#choosing-the-right-approach","title":"Choosing the right approach","text":"<p>These methods for attaching sit along a continuum that is somewhat like the continuum between strong, statically typed languages versus dynamic, duck-typed languages in programming. The more strongly typed the attachments are, the more strongly bound the attachments are to the protocol that conveys them. Each choice has advantages and disadvantages.</p> <p></p> <p>Inlined data is strongly typed; the schema for its associated message must specify the name of the data field, plus what type of data it contains. Its format is always some kind of JSON--often JSON-LD with a <code>@type</code> and/or <code>@context</code> field to provide greater clarity and some independence of versioning. Simple and small data is the best fit for inlining. As mentioned earlier, the Connection Protocol inlines a DID Doc in its <code>connection_request</code> and <code>connection_response</code> messages.</p> <p>Embedded data is still associated with a known field in the message schema, but it can have a broader set of possible formats. A credential exchange protocol might embed a credential in the final message that does credential issuance.</p> <p>Appended attachments are the most flexible but also the hardest to run through semantically sophisticated processing. They do not require any specific declaration in the schema of a message, although they can be referenced in fields defined by the schema via their nickname (see below). A protocol that needs to pass an arbitrary collection of artifacts without strong knowledge of their semantics might find this helpful, as in the example mentioned above, where scheduling a venue causes various human-usable payloads to be delivered.</p>"},{"location":"concepts/0017-attachments/#ids-for-attachments","title":"IDs for attachments","text":"<p>The <code>@id</code> field within an attachment descriptor is used to refer unambiguously to an appended (or less ideally, embedded) attachment, and works like an HTML anchor. It is resolved relative to the root <code>@id</code> of the message and only has to be unique within a message. For example, imagine a fictional message type that's used to apply for an art scholarship, that requires photos of art demonstrating techniques A, B, and C. We could have 3 different attachment descriptors--but what if the same work of art demonstrates both technique A and technique B? We don't want to attach the same photo twice...</p> <p>What we can do is stipulate that the datatype of <code>A_pic</code>, <code>B_pic</code>, and <code>C_pic</code> is an attachment reference, and that the references will point to appended attachments. A fragment of the result might look like this:</p> <p></p> <p>Another example of nickname use appeared in the first example of appended attachments above, where the <code>notes</code> field refered to the <code>@id</code>s of the various attachments.</p> <p>This indirection offers several benefits:</p> <ul> <li>The same attachment may be referenced at more than one place in the schema, without duplicating the content.</li> <li>The message may now include any number of attachments besides the 3 that are required, and mingle them freely with the others. (In our example, perhaps the student wants to add side and overhead shots of each work of art, not just front views).</li> <li>Attachments may now have formal semantics, instead of requiring human intelligence to handle. (How many times have we written emails with multiple attachments, and added verbiage like, \"My photo of the door is attached as image1.jpeg; my photo of the damaged trunk is attached as image2.jpeg\"?)</li> </ul> <p>We could use this same technique with embedded attachments (that is, assign a nickname to an embedded attachment, and refer to that nickname in another field where attached data could be embedded), but this is not considered best practice. The reason is that it requires a field in the schema to have two possible data types--one a string that's a nickname reference, and one an attachment descriptor. Generally, we like fields to have a single datatype in a schema.</p>"},{"location":"concepts/0017-attachments/#content-formats","title":"Content Formats","text":"<p>There are multiple ways to include content in an attachment. Only one method should be used per attachment.</p>"},{"location":"concepts/0017-attachments/#base64url","title":"base64url","text":"<p>This content encoding is an obvious choice for any content different than JSON. You can embed content of any type using this method. Examples are plentiful throughout the document. Note that this encoding is always base64url encoding, not plain base64, and that padding is not required. Code that reads this encoding SHOULD tolerate the presence or absence of padding and base64 versus base64url encodings equally well, but code that writes this encoding SHOULD omit the padding to guarantee alignment with encoding rules in the JOSE (JW*) family of specs.</p>"},{"location":"concepts/0017-attachments/#json","title":"json","text":"<p>If you are embedding an attachment that is JSON, you can embed it directly in JSON format to make access easier, by replacing <code>data.base64</code> with <code>data.json</code>, where the value assigned to <code>data.json</code> is the attached content:</p> <p></p> <p>This is an overly trivial example of GeoJSON, but hopefully it illustrates the technique. In cases where there is no mime type to declare, it may be helpful to use JSON-LD's <code>@type</code> construct to clarify the specific flavor of JSON in the embedded attachment.</p>"},{"location":"concepts/0017-attachments/#links","title":"links","text":"<p>All examples discussed so far include an attachment by value--that is, the attachment's bytes are directly inlined in the message in some way. This is a useful mode of data delivery, but it is not the only mode.</p> <p>Another way that attachment data can be incorporated is by reference. For example, you can link to the content on a web server by replacing <code>data.base64</code> or <code>data.json</code> with <code>data.links</code> in an attachment descriptor:</p> <p></p> <p>When you provide such a link, you are creating a logical association between the message and an attachment that can be fetched separately. This makes it possible to send brief descriptors of attachments and to make the downloading of the heavy content optional (or parallelizable) for the recipient.</p> <p>The <code>links</code> field is plural (an array) to allow multiple locations to be offered for the same content. This allows an agent to fetch attachments using whichever mechanism(s) are best suited to its individual needs and capabilities.</p>"},{"location":"concepts/0017-attachments/#supported-uri-types","title":"Supported URI Types","text":"<p>The set of supported URI types in an attachment link is limited to:</p> <ul> <li>HTTP</li> <li>HTTPS</li> </ul> <p>Additional URI types may be added via updates to this RFC.</p> <p>If an attachment link with an unsupported URI is received, the agent SHOULD respond with a Problem Report indicated the problem.</p> <p>An ecosystem (coordinating set of agents working in a specific business area) may agree to support other URI types within that ecosystem. As such, implementing a mechanism to easily add support for other attachment link URI types might be useful, but is not required.</p>"},{"location":"concepts/0017-attachments/#signing-attachments","title":"Signing Attachments","text":"<p>In some cases it may be desirable to sign an attachment in addition to or instead of signing the message as a whole. Consider a home-buying protocol; the home inspection needs to be signed even when it is removed from a messaging flow. Attachments may also be signed by a party separate from the sender of the message, or using a different signing key when the sender is performing key rotation.</p> <p>Embedded and appended attachments support signatures by the addition of a <code>data.jws</code> field containing a signature in JWS (RFC 7515) format with Detached Content. The payload of the JWS is the raw bytes of the attachment, appropriately base64url-encoded per JWS rules. If these raw bytes are incorporated by value in the DIDComm message, they are already base64url-encoded in <code>data.base64</code> and are thus directly substitutable for the suppressed <code>data.jws.payload</code> field; if they are externally referenced, then the bytes must be fetched via the URI in <code>data.links</code> and base64url-encoded before the JWS can be fully reconstituted. Signatures over inlined JSON attachments are not currently defined as this depends upon a canonical serialization for the data.</p> <p>Sample JWS-signed attachment:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/xhomebuy/1.0/home_insp\",\n  \"inspection_date\": \"2020-03-25\",\n  \"inspection_address\": \"123 Villa de Las Fuentes, Toledo, Spain\",\n  \"comment\": \"Here's that report you asked for.\",\n  \"report~attach\": {\n    \"mime-type\": \"application/pdf\",\n    \"filename\": \"Garcia-inspection-March-25.pdf\",\n    \"data\": {\n      \"base64\": \"eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ... (bytes omitted to shorten)\",\n      \"jws\": {\n        // payload: ...,  &lt;-- omitted: refer to base64 content when validating\n        \"header\": {\n          \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n        },\n        \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n        \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n      }\n    }\n  }\n}\n</code></pre> <p>Here, the JWS structure inlines a public key value in did:key format within the unprotected header's <code>kid</code> field. It may also use a DID URL to reference a key within a resolvable DIDDoc. Supported DID URLs should specify a timestamp and/or version for the containing document.</p> <p>The JWS protected header consists of at least the following parameter indicating an Edwards curve digital signature:</p> <pre><code>{\n  \"alg\": \"EdDSA\"\n}\n</code></pre> <p>Additional protected and unprotected header parameters may be included in the JWS and must be ignored by implementations if not specifically supported. Any registered header parameters defined by the JWS RFC must be used according to the specification if present.</p> <p>Multiple signatures may be included using the JWS General Serialization syntax. When a single signature is present, the Flattened Serialization syntax should be preferred. Because each JWS contains an unprotected header with the signing key information, the JWS Compact Serialization cannot be supported.</p>"},{"location":"concepts/0017-attachments/#size-considerations","title":"Size Considerations","text":"<p>DIDComm messages should be small, as a general rule. Just as it's a bad idea to send email messages with multi-GB attachments, it would be bad to send DIDComm messages with huge amounts of data inside them. Remember, a message is about advancing a protocol; usually that can be done without gigabytes or even megabytes of JSON fields. Remember as well that DIDComm messages may be sent over channels having size constraints tied to the transport--an HTTP POST or Bluetooth or NFC or AMQP payload of more than a few MB may be problematic.</p> <p>Size pressures in messaging are likely to come from attached data. A good rule of thumb might be to not make DIDComm messages bigger than email or MMS messages--whenever more data needs to be attached, use the inclusion-by-reference technique to allow the data to be fetched separately.</p>"},{"location":"concepts/0017-attachments/#security-implications","title":"Security Implications","text":"<p>Attachments are a notorious vector for malware and mischief with email. For this reason, agents that support attachments MUST perform input validation on attachments, and MUST NOT invoke risky actions on attachments until such validation has been performed. The status of input validation with respect to attachment data MUST be reflected in the Message Trust Context associated with the data's message.</p>"},{"location":"concepts/0017-attachments/#privacy-implications","title":"Privacy Implications","text":"<p>When attachments are inlined, they enjoy the same security and transmission guarantees as all agent communication. However, given the right context, a large inlined attachment may be recognizable by its size, even if it is carefully encrypted.</p> <p>If attachment content is fetched from an external source, then new complications arise. The security guarantees may change. Data streamed from a CDN may be observable in flight. URIs may be correlating. Content may not be immutable or tamper-resistant.</p> <p>However, these issues are not necessarily a problem. If a DIDComm message wants to attach a 4 GB ISO file of a linux distribution, it may be perfectly fine to do so in the clear. Downloading it is unlikely to introduce strong correlation, encryption is unnecessary, and the torrent itself prevents malicious modification.</p> <p>Code that handles attachments will need to use wise policy to decide whether attachments are presented in a form that meets its needs.</p>"},{"location":"concepts/0017-attachments/#reference","title":"Reference","text":""},{"location":"concepts/0017-attachments/#attachment-descriptor-structure","title":"Attachment Descriptor structure","text":"<ul> <li> <p><code>@id</code>: A JSON-LD construct that uniquely identifies attached content within the scope of a given message. Recommended on appended attachment descriptors. Possible but generally unused on embedded attachment descriptors. Never required if no references to the attachment exist; if omitted, then there is no way to refer to the attachment later in the thread, in error messages, and so forth. Because <code>@id</code> is used to compose URIs, it is recommended that this name be brief and avoid spaces and other characters that require URI escaping.</p> </li> <li> <p><code>description</code>: An optional human-readable description of the content.</p> </li> <li> <p><code>filename</code>: A hint about the name that might be used if this attachment is persisted as a file. It is not required, and need not be unique. If this field is present and <code>mime-type</code> is not, the extension on the filename may be used to infer a MIME type.</p> </li> <li> <p><code>mime-type</code>: Describes the MIME type of the attached content. Optional but recommended.</p> </li> <li> <p><code>lastmod_time</code>: A hint about when the content in this attachment was last modified.</p> </li> <li> <p><code>byte_count</code>: Optional, and mostly relevant when content is included by reference instead of by value. Lets the receiver guess how expensive it will be, in time, bandwidth, and storage, to fully fetch the attachment.</p> </li> <li> <p><code>data</code>: A JSON object that gives access to the actual content of the attachment. Contains the following subfields:</p> </li> <li> <p><code>jws</code>: A JSON Web Signature over the content of the attachment. Optional.</p> </li> <li> <p><code>sha256</code>: The hash of the content. Optional. Used as an integrity check if   content is inlined. if content is only referenced, then including this field   makes the content tamper-evident. This may be redundant, if the content is   stored in an inherently immutable container like content-addressable storage.   This may also be undesirable, if dynamic content at a specified link is   beneficial. Including a hash without including a way to fetch the content via   link is a form of proof of existence.</p> </li> <li> <p><code>links</code>: A list of zero or more locations at which the content may be fetched.   Optional.</p> </li> <li> <p><code>base64</code>: Base64url-encoded data, when representing arbitrary content inline instead   of via <code>links</code>. Optional.</p> </li> <li> <p><code>json</code>: Directly embedded JSON data, when representing content inline instead of   via <code>links</code>, and when the content is natively conveyable as JSON. Optional.</p> </li> </ul>"},{"location":"concepts/0017-attachments/#drawbacks","title":"Drawbacks","text":"<p>By providing 3 different choices, we impose additional complexity on agents that will receive messages. They have to handle attachments in 3 different modes.</p>"},{"location":"concepts/0017-attachments/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Originally, we only proposed the most flexible method of attaching--appending. However, feedback from the community suggested that stronger binding to schema was desirable. Inlining was independently invented, and is suggested by JSON-LD anyway. Embedding without appending eliminates some valuable ../../features such as unnamed and undeclared ad-hoc attachments. So we ended up wanting to support all 3 modes.</p>"},{"location":"concepts/0017-attachments/#prior-art","title":"Prior art","text":"<p>Multipart MIME (see RFCs 822, 1341, and 2045) defines a mechanism somewhat like this. Since we are using JSON instead of email messages as the core model, we can't use these mechanisms directly. However, they are an inspiration for what we are showing here.</p>"},{"location":"concepts/0017-attachments/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>N/A</li> </ul>"},{"location":"concepts/0017-attachments/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python in credential exchange Streetcred.id Commercial mobile and web app built using Aries Framework - .NET"},{"location":"concepts/0020-message-types/","title":"Aries RFC 0020: Message Types","text":"<ul> <li>Authors: Daniel Bluhm, Sam Curren</li> <li>Status: ADOPTED</li> <li>Since: 2019-05-24</li> <li>Status Note:  </li> <li>Supersedes: HIPE 0021 Message Types</li> <li>Start Date: 2018-07-06</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0020-message-types/#summary","title":"Summary","text":"<p>Define structure of message type strings used in agent to agent communication, describe their resolution to documentation URIs, and offer guidelines for protocol specifications.</p>"},{"location":"concepts/0020-message-types/#motivation","title":"Motivation","text":"<p>A clear convention to follow for agent developers is necessary for interoperability and continued progress as a community.</p>"},{"location":"concepts/0020-message-types/#tutorial","title":"Tutorial","text":"<p>A \"Message Type\" is a required attribute of all communications sent between parties. The message type instructs the receiving agent how to interpret the content and what content to expect as part of a given message.</p> <p>Types are specified within a message using the <code>@type</code> attribute:</p> <pre><code>{\n    \"@type\": \"&lt;message type string&gt;\",\n    // other attributes\n}\n</code></pre> <p>Message types are URIs that may resolve to developer documentation for the message type, as described in Protocol URIs. We recommend that message type URIs be HTTP URLs.</p>"},{"location":"concepts/0020-message-types/#aries-core-message-namespace","title":"Aries Core Message Namespace","text":"<p><code>https://didcomm.org/</code> is used to namespace protocols defined by the community as \"core protocols\" or protocols that agents should minimally support.</p> <p>The <code>didcomm.org</code> DNS entry is currently controlled by the Decentralized Identity Foundation (DIF) based on their role in standardizing the DIDComm Messaging specification.</p>"},{"location":"concepts/0020-message-types/#protocols","title":"Protocols","text":"<p>Protocols provide a logical grouping for message types. These protocols, along with each type belonging to that protocol, are to be defined in future RFCs or through means appropriate to subprojects.</p>"},{"location":"concepts/0020-message-types/#protocol-versioning","title":"Protocol Versioning","text":"<p>Version numbering should essentially follow Semantic Versioning 2.0.0, excluding patch version number. To summarize, a change in the major protocol version number indicates a breaking change while the minor protocol version number indicates non-breaking additions.</p>"},{"location":"concepts/0020-message-types/#message-type-design-guidelines","title":"Message Type Design Guidelines","text":"<p>These guidelines are guidelines on purpose. There will be situations where a good design will have to choose between conflicting points, or ignore all of them. The goal should always be clear and good design.</p>"},{"location":"concepts/0020-message-types/#respect-reserved-attribute-names","title":"Respect Reserved Attribute Names","text":"<p>Reserved attributes are prefixed with an <code>@</code> sign, such as <code>@type</code>. Don't use this prefix for an attribute, even if use of that specific attribute is undefined.</p>"},{"location":"concepts/0020-message-types/#avoid-ambiguous-attribute-names","title":"Avoid ambiguous attribute names","text":"<p>Data, id, and package, are often terrible names. Adjust the name to enhance meaning. For example, use  <code>message_id</code> instead of <code>id</code>.</p>"},{"location":"concepts/0020-message-types/#avoid-names-with-special-characters","title":"Avoid names with special characters","text":"<p>Technically, attribute names can be any valid json key (except prefixed with @, as mentioned above). Practically, you should avoid using special characters, including those that need to be escaped. Underscores and dashes [_,-] are totally acceptable, but you should avoid quotation marks, punctuation, and other symbols.</p>"},{"location":"concepts/0020-message-types/#use-attributes-consistently-within-a-protocol","title":"Use attributes consistently within a protocol","text":"<p>Be consistent with attribute names between the different types within a protocol. Only use the same attribute name for the same data. If the attribute values are similar, but not exactly the same, adjust the name to indicate the difference.</p>"},{"location":"concepts/0020-message-types/#nest-attributes-only-when-useful","title":"Nest Attributes only when useful","text":"<p>Attributes do not need to be nested under a top level attribute, but can be to organize related attributes. Nesting all message attributes under one top level attribute is usually not a good idea.</p>"},{"location":"concepts/0020-message-types/#design-examples","title":"Design Examples","text":""},{"location":"concepts/0020-message-types/#example-1","title":"Example 1","text":"<pre><code>{\n    \"@type\": \"did:example:00000;spec/pizzaplace/1.0/pizzaorder\",\n    \"content\": {\n        \"id\": 15,\n        \"name\": \"combo\",\n        \"prepaid?\": true,\n        \"ingredients\": [\"pepperoni\", \"bell peppers\", \"anchovies\"]\n    }\n}\n</code></pre> <p>Suggestions: Ambiguous names, unnecessary nesting, symbols in names.</p>"},{"location":"concepts/0020-message-types/#example-1-fixed","title":"Example 1 Fixed","text":"<pre><code>{\n    \"@type\": \"did:example:00000;spec/pizzaplace/1.0/pizzaorder\",\n    \"table_id\": 15,\n    \"pizza_name\": \"combo\",\n    \"prepaid\": true,\n    \"ingredients\": [\"pepperoni\", \"bell peppers\", \"anchovies\"]\n}\n</code></pre>"},{"location":"concepts/0020-message-types/#reference","title":"Reference","text":"<ul> <li>Daniel Hardman's Agent Summit Notes</li> <li>Stephen Curran's presentation summarizing the Agent Summit</li> <li>Semantic Versioning</li> <li>DIDComm Message Anatomy</li> </ul>"},{"location":"concepts/0020-message-types/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community Aries Framework - .NET .NET framework for building agents of all types Streetcred.id Commercial mobile and web app built using Aries Framework - .NET Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Aries Framework - Go For building agents, hubs and other DIDComm ../../features in GoLang. Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem."},{"location":"concepts/0021-didcomm-message-anatomy/","title":"Aries RFC 0021: DIDComm Message Anatomy","text":"<ul> <li>Authors: Tobias Looker, Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-05-25</li> <li>Start Date: 2019-05-25</li> <li>Tags: concept, decorator</li> </ul>"},{"location":"concepts/0021-didcomm-message-anatomy/#summary","title":"Summary","text":"<p>Explain the basics of DID communication messages at a high level, and link to other RFCs to promote deeper exploration.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#motivation","title":"Motivation","text":"<p>Promote a deeper understanding of the DIDComm message anatomy through a overarching view of the two distinct levels of messages in a single place.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#tutorial","title":"Tutorial","text":"<p>DIDComm messages are comprised of the following two main layers, which are not dissimilar to how postal messages occur in the real world.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#envelope-level","title":"Envelope Level","text":"<p>As the name suggests, <code>envelope</code> borrows from the analogy of how physical messages are handled in the postal system, this message format level acts as the digital envelope for DIDComm messages.</p> <p>There are two main variations of the envelope level format which are defined to cater for the different audiences and use cases DIDComm messages serve.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#1-encrypted","title":"1. Encrypted","text":"<p>This format is for when the audience of the message is a DID or DID's known to the sender, in this case the message can be prepared and encrypted with the key information present in the audiences DID docs.</p> <p>Within this encrypted format, there are multiple sub-formats which give rise to different properties.</p> <ol> <li>Anonymous Encrypted format This format is when a message is encrypted to a recipient in an anonymous fashion, and it does not include any sender information.</li> <li>Authenticated Encrypted format This format is when a message is encrypted to a recipient and sender information is included through the use of authenticated encryption. With this format only the true recipient(s) can both decrypt the message and authenticate its content is truly from the sender.</li> <li>Signed Encrypted format This format is when a message is encrypted to the recipient and sender information is included along with a non-repudiable signature. In this case the recipient(s) is still the only party that can decrypt the message. However, because the underlying message includes non-repudiability, authentication of the decrypted message content can be done by any party who knows the sender.</li> </ol>"},{"location":"concepts/0021-didcomm-message-anatomy/#2-signed-unencrypted","title":"2. Signed Unencrypted","text":"<p>This format is for when the audience of the message is unknown (for example some form of public challenge). This format is signed, so that when a member of the audience receives the message they can authenticate the message with its non-repudiable signature.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#serialization-format","title":"Serialization Format","text":"<p>All of the envelope level formats are achieved through JOSE based structures. The encrypted formats uses a JWE structure, whereas the signed unencrypted format uses a JWS structure.</p> <p>Details on the encrypted forms are found here</p> <p>Details on the signed un-encrypted are TBC</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#content-level","title":"Content Level","text":"<p>This level to continue the postal metaphor is the content inside the envelope and contains the message.</p> <p>At this level, several conventions are defined around how messages are structured, which facilitates in message identification and processing.</p> <p>The most important ../../concepts to introduce about these conventions are the following.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#message-type","title":"Message Type","text":"<p>Every message contains a message type which allows the context of the message to be established and therefore process the content, see here for more information. It is also important to note that in DIDComm, the message identification does not just identify the message, the message type also identifies the associated protocol. These protocols are essentially a group of related messages that are together required to achieve some form of multi-step flow see here for more information.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#message-id","title":"Message Id","text":"<p>Every message contains a message id which is uniquely generated by the sender, this allows unique identification of the message. See here for more information.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#decorators","title":"Decorators","text":"<p>DIDComm messages at a content level allow for the support of re-usable conventions that are present across multiple messages in order to handle the same functionality in a consistent manner.</p> <p>A relevant analogy for decorators, is that they are like HTTP headers in a HTTP request. The same HTTP header is often reused as a convention across multiple requests to achieve cross cutting functionality.</p> <p>See here for more details.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#serialization-format_1","title":"Serialization Format","text":"<p>At present all content level messages are represented as JSON. Further more these messages are also JSON-LD sympathetic however they do not have full and direct support for JSON-LD.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#reference","title":"Reference","text":"<p>All references are defined inline where required.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#rationale-and-alternatives","title":"Rationale and alternatives","text":""},{"location":"concepts/0021-didcomm-message-anatomy/#prior-art","title":"Prior art","text":""},{"location":"concepts/0021-didcomm-message-anatomy/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"concepts/0021-didcomm-message-anatomy/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0029-message-trust-contexts/","title":"Aries RFC 0029: Message Trust Contexts","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: Not practically applied.</li> <li>Supersedes: Indy HIPE PR #120</li> <li>Start Date: 2018-02-10 (approx, backdated)</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0029-message-trust-contexts/#summary","title":"Summary","text":"<p>Introduces the concept of Message Trust Contexts and describes how they are populated and used.</p>"},{"location":"concepts/0029-message-trust-contexts/#motivation","title":"Motivation","text":"<p>An important aim of DID Communication is to let parties achieve high trust. Such trust is vital in cases where money changes hands and identity is at stake. However, sometimes lower trust is fine; playing tic-tac-toe ought to be safe through agents, even with a malicious stranger.</p> <p>We may intuitively understand the differences in these situations, but intuition isn't the best guide when designing a secure ecosystem. Trust is a complex, multidimensional phenomenon. We need a formal way to analyze it, and to test its suitability in particular circumstances.</p>"},{"location":"concepts/0029-message-trust-contexts/#tutorial","title":"Tutorial","text":"<p>When Alice sends a message to Bob, how much should Bob trust it?</p> <p>This is not a binary question, with possible answers of \"completely\" or \"not at all\". Rather, it is a nuanced question that should consider many factors. Some clarifying questions might include:</p> <ul> <li> <p>How much does Bob know about Alice? And what evidence is behind that knowledge?</p> </li> <li> <p>Was the confidentiality and integrity of the message protected while it was in transit? If so:</p> <ul> <li>How strong is the encryption algorithm?</li> <li>How good are the protections on the keys?</li> <li>Is perfect forward secrecy being used?</li> </ul> </li> <li> <p>Does Bob have any kind of prior relationship to Alice, such that history increases (or decreases) trust?</p> </li> <li> <p>Is the message repudiable, or is Alice speaking \"on the record\"?</p> </li> <li> <p>Could Alice use a malformed message to attack Bob (e.g., with buffer overflows, numeric range errors, unexpected fields, and so forth)?</p> </li> </ul>"},{"location":"concepts/0029-message-trust-contexts/#message-trust-contexts","title":"Message Trust Contexts","text":"<p>The DID Communication ecosystem formalizes the idea of a Message Trust Context (MTC) to expose such questions, make their answers explicit, and encourage thoughtful choices based on the answers.</p> <p>An MTC is an object that holds trust context for a message. This context follows a message throughout its processing journey inside the agent that receives it, and it should be analyzed and updated for decision-making purposes throughout.</p> <p>Protocols should be designed with standard MTCs in mind. Thus, it is desirable that all implementations share common names for certain ../../concepts, so we can discuss them conveniently in design docs, error messages, logs, and so forth. The standard dimensions of trust tracked in an MTC break down into two groups:</p>"},{"location":"concepts/0029-message-trust-contexts/#crypto-related","title":"Crypto-related","text":"<ul> <li>Confidentiality: Could the plaintext content of the message I just received over this channel have been observed by another party?</li> <li>Integrity: Could the message have been tampered with since it was sent?</li> <li>Authenticated Origin: Can I know the identity of the original sender with confidence? And if so, on what basis--were multiple factors of auth required to use the keys that encrypted the message? Were biometrics at play?</li> <li>Nonrepudiation: Can I prove the identity of the sender to a third party? Note that this guarantee may or may not be a desirable quality.</li> <li>PFS: Is perfect forward secrecy active?</li> <li>Uniqueness: Can I know that this message is not being sent as part of a replay attack?</li> <li>Limited Scope: Does the sender identify me in a way that is only meaningful inside a narrow context (e.g., pairwise or nwise relationship), to preserve my privacy? Or did they use a published DID that would correlate me?</li> </ul>"},{"location":"concepts/0029-message-trust-contexts/#input-validations","title":"Input validations","text":"<ul> <li>Size OK: Do I know that the message will not overflow internal buffers or persistent storage?</li> <li>Deserialize OK: Does the plaintext message deserialize into native object representation?</li> <li>Keys OK: As a native object, do the keys (property names) and structure match what was expected? In some approaches to deserialization, it may be combined with the previous question--but in languages that produce a loose dictionary from JSON, it is distinct.</li> <li>Values OK: As a native object, do the values for properties match the datatypes, sizes, and constraints that were expected?</li> </ul> <p>In code, these types of trust are written using whatever naming convention matches the implementer's programming language, so <code>authenticated_origin</code> and <code>authenticatedOrigin</code> are synonyms of each other and of <code>Authenticated Origin</code>.</p>"},{"location":"concepts/0029-message-trust-contexts/#notation","title":"Notation","text":"<p>In protocol designs, the requirements of a message trust context should be declared when message types are defined. For example, the <code>credential_offer</code> message in the <code>credential_issuance</code> protocol should not be accepted unless it has <code>Integrity</code> and <code>Authenticated Origin</code> in its MTC (because otherwise a MITM could interfere). The definition of the message type should say this. Its RFC does this by notating:</p> <pre><code>mtc: +integrity +authenticated_origin\n</code></pre> <p>When a loan is digitally signed, we probably need:</p> <pre><code>mtc: +integrity +authenticated_origin +nonrepudiation\n</code></pre> <p>The labels for these trust types are long, but they can be shortened if they remain unambiguous. Notice, too, that all of the official MTC fields have unique intial letters. We can therefore abbreviate unambiguously:</p> <pre><code>mtc: +i +a +n\n</code></pre> <p>Any type of trust that does not appear in MTC notation is assumed to be <code>undefined</code> (meaning no claim is made about it either way, perhaps because it hasn't been evaluated or because it doesn't matter). However, sometimes we need to make a lack of trust explicit. We might claim in a protocol definition that a particular type of trust is definitely not required. Or we might want to show that we evaluated a particular trust at runtime, and had a negative outcome. In such cases, we can do this:</p> <pre><code>mtc: +i +a -n\n</code></pre> <p>Here, we are explicitly denying that <code>nonrepudiation</code> is part of the trust context.</p> <p>For further terseness in our notation, spaces can be omitted:</p> <pre><code>mtc: +i+a-n\n</code></pre> <p>Finally, an mtc that makes no explicit positive or negative claims (undefined) is written as:</p> <pre><code>mtc: ?\n</code></pre> <p>This MTC notation is a supplement to SSI Notation and should be treated as equally normative. Such notation might be useful in log files and error messages, among other things. See Using a Message Trust Context at Runtime below.</p>"},{"location":"concepts/0029-message-trust-contexts/#custom-trust","title":"Custom Trust","text":"<p>Specific agents may make trust distinctions that are helpful in their own problem domains. For example, some agents may evaluate trust on the physical location or IP address of a sender, or on the time of day that a message arrives. Others may use DIDComm for internal processes that have unique trust requirements over and above those that matter in interoperable scenarios, such as whether a message emanates from a machine running endpoint compliance software, or whether it has passed through intrusion detection or data loss prevention filters.</p> <p>Agent implementations are encouraged to add their own trust dimensions to their own implementations of a Message Trust Context, as long as they do not redefine the standard labels. In cases where custom trust types introduce ambiguity with trust labels, MTC notation requires enough letters to disambiguate labels. So if a complex custom MTC has fields named <code>intrusion_detect_ok</code>, <code>ipaddr_ok</code> (which both start like the standard <code>integrity</code>), and <code>endpoint_compliance</code> (which has no ambiguity with a standard token) it might be notated as:</p> <pre><code>mtc: +c+a+inte+intr+ip-n-p-e\n</code></pre> <p>Here, <code>inte</code> matches the standard label <code>integrity</code>, whereas <code>intr</code> and <code>ip</code> are known to be custom because they don't match a standard label; <code>e</code> is custom but only a single letter because it is unambiguous.</p>"},{"location":"concepts/0029-message-trust-contexts/#populating-a-message-trust-context-at-runtime","title":"Populating a Message Trust Context at Runtime","text":"<p>A Message Trust Context comes into being when it arrives on the wire at the receiving agent and begins its processing flow.</p> <p>The first step may be an input validation to confirm that the message doesn't exceed a max size. If so, the empty MTC is updated with <code>+s</code>.</p> <p>Another early step is decryption. This should allow population of the <code>confidentiality</code> and <code>authenticated_origin</code> dimensions, at least.</p> <p>Subsequent layers of code that do additional analysis should update the MTC as appropriate. For example, if a signature is not analyzed and validated until after the decryption step, the signature's presence or absence should cause <code>nonrepudiation</code> and maybe <code>integrity</code> to be updated. Similarly, once the plaintext of a message is known to be a valid enough to deserialize into an object, the MTC acquires <code>+deserialize_ok</code>. Later, when the fields of the message's native object representation have been analyzed to make sure they conform to a particular structure, it should be updated again with <code>+key_ok</code>. And so forth.</p>"},{"location":"concepts/0029-message-trust-contexts/#using-a-message-trust-context-at-runtime","title":"Using a Message Trust Context at Runtime","text":"<p>As message processing happens, the MTC isn't just updated. It should constantly be queried, and decisions should be made on the basis of what the MTC says. These decisions can vary according to the preferences of agent developers and the policies of agent owners. Some agents may choose not to accept any messages that are <code>-a</code>, for example, while others may be content to talk with anonymous senders. The recommendations of protocol designers should never be ignored, however; it is probably wrong to accept a <code>-n</code> message that signs a loan, even if agent policy is lax about other things. Formally declared MTCs in a protocol design may be linked to security proofs...</p> <p>Part of the intention with the terse MTC notation is that conversations about agent trust should be easy and interoperable. When agents send one another <code>problem-report</code> messages, they can turn MTCs into human-friendly text, but also use this notation: \"Unable to accept a payment from message that lacks Integrity guarantees (-i).\" This notation can help diagnose trust problems in logs. It may also be helpful with message tracing, feature discovery, and agent testing.</p>"},{"location":"concepts/0029-message-trust-contexts/#attachments","title":"Attachments","text":"<p>MTCs apply to the entirety of the associated message's attributes. However, embedded and appended message attachments present the unique situation of nested content with the potential for a trust context that differs from the parent message.</p> <p>The attachment descriptor, used for both embedded and appended attachments, shares the same MTC as the parent message. Unpacked attachment data have their own Trust Contexts populated as appropriate depending on how the data was retrieved, whether the attachment is signed, whether an integrity checksum was provided and verified, etc.</p> <p>Attachments delivered by the parent message, i.e. as base64url-encoded data, inherit relevant trust contexts from the parent, such as <code>confidentiality</code> and <code>authenticated_origin</code>, when the message was delivered as an authenticated encrypted message.</p> <p>Attachments retrieved from a remote resource populate their trust context as relevant to the retrieval mechanism.</p>"},{"location":"concepts/0029-message-trust-contexts/#reference","title":"Reference","text":"<p>A complete reference implementation of MTCs in python is attached to this RFC (see mtc.py). It could easily be extended with custom trust dimensions, and it would be simple to port to other programming languages. Note that the implementation includes unit tests written in pytest style, and has only been tested on python 3.x.</p>"},{"location":"concepts/0029-message-trust-contexts/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes MTC reference impl Reference impl in python, checked in with RFC. Includes unit tests. Aries Protocol Test Suite Aries Static Agent - Python Largely inspired by reference implementation; MTC populated and made available to handlers."},{"location":"concepts/0046-mediators-and-relays/","title":"Aries RFC 0046: Mediators and Relays","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2019-02-01</li> <li>Status Note: Socialized and broadly understood in other conceptual RFCs about routing.</li> <li>Start Date: 2018-12-01</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0046-mediators-and-relays/#summary","title":"Summary","text":"<p>The mental model for agent-to-agent messaging (A2A) messaging includes two important communication primitives that have a meaning unique to our ecosystem: mediator and relay.</p> <p>A mediator is a participant in agent-to-agent message delivery that must be modeled by the sender. It has its own keys and will deliver messages only after decrypting an outer envelope to reveal a <code>forward</code> request. Many types of mediators may exist, but two important ones should be widely understood, as they commonly manifest in DID Docs:</p> <ol> <li>A service that hosts many cloud agents at a single endpoint to provide herd privacy (an \"agency\") is a mediator.</li> <li>A cloud-based agent that routes between/among the edges of a sovereign domain is a mediator.</li> </ol> <p>A relay is an entity that passes along agent-to-agent messages, but that can be ignored when the sender considers encryption choices. It does not decrypt anything. Relays can be used to change the transport for a message (e.g., accept an HTTP POST, then turn around and emit an email; accept a Bluetooth transmission, then turn around and emit something in a message queue). Mix networks like TOR are an important type of relay.</p> <p>Read on to explore how agent-to-agent communication can model complex topologies and flows using these two primitives.</p>"},{"location":"concepts/0046-mediators-and-relays/#motivation","title":"Motivation","text":"<p>When we describe agent-to-agent communication, it is convenient to think of an interaction only in terms of Alice and Bob and their agents. We say things like: \"Alice's agent sends a message to Bob's agent\" -- or perhaps \"Alice's edge agent sends a message to Bob's cloud agent, which forwards it to Bob's edge agent\".</p> <p>Such statements adopt a useful level of abstraction--one that's highly recommended for most discussions. However, they make a number of simplifications. By modeling the roles of mediators and relays in routing, we can support routes that use multiple transports, routes that are not fully known (or knowable) to the sender, routes that pass through mix networks, and other advanced and powerful ../../concepts.</p>"},{"location":"concepts/0046-mediators-and-relays/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0046-mediators-and-relays/#key-concepts","title":"Key Concepts","text":"<p>Let's define mediators and relays by exploring how they manifest in a series of communication scenarios between Alice and Bob.</p>"},{"location":"concepts/0046-mediators-and-relays/#scenario-1-base","title":"Scenario 1 (base)","text":"<p>Alice and Bob are both employees of a large corporation. They work in the same office, but have never met. The office has a rule that all messages between employees must be encrypted. They use paper messages and physical delivery as the transport. Alice writes a note, encrypts it so only Bob can read it, puts it in an envelope addressed to Bob, and drops the envelope on a desk that she has been told belongs to Bob. This desk is in fact Bob's, and he later picks up the message, decrypts it, and reads it.</p> <p></p> <p>In this scenario, there is no mediator, and no relay.</p>"},{"location":"concepts/0046-mediators-and-relays/#scenario-2-a-gatekeeper","title":"Scenario 2: a gatekeeper","text":"<p>Imagine that Bob hires an executive assistant, Carl, to filter his mail. Bob won't open any mail unless Carl looks at it and decides that it's worthy of Bob's attention.</p> <p>Alice has to change her behavior. She continues to package a message for Bob, but now she must account for Carl as well. She take the envelope for Bob, and places it inside a new envelope addressed to Carl. Inside the outer envelope, and next to the envelope destined for Bob, Alice writes Carl an encrypted note: \"This inner envelope is for Bob. Please forward.\"</p> <p></p> <p>Here, Carl is acting as a mediator. He is mostly just passing messages along. But because he is processing a message himself, and because Carl is interposed between Alice and Bob, he affects the behavior of the sender. He is a known entity in the route.</p>"},{"location":"concepts/0046-mediators-and-relays/#scenario-3-transparent-indirection","title":"Scenario 3: transparent indirection","text":"<p>All is the same as the base scenario (Carl has been fired), except that Bob is working from home when Alice's message lands on his desk. Bob has previously arranged with his friend Darla, who lives near him, to pick up any mail that's on his desk and drop it off at his house at the end of the work day. Darla sees Alice's note and takes it home to Bob.</p> <p></p> <p>In this scenario, Darla is acting as a relay. Note that Bob arranges for Darla to do this without notifying Alice, and that Alice does not need to adjust her behavior in any way for the relay to work.</p>"},{"location":"concepts/0046-mediators-and-relays/#scenario-4-more-indirection","title":"Scenario 4: more indirection","text":"<p>Like scenario 3, Darla brings Bob his mail at home. However, Bob isn't at home when his mail arrives. He's had to rush out on an errand, but he's left instructions with his son, Emil, to open any work mail, take a photo of the letter, and text him the photo. Emil intends to do this, but the camera on his phone misfires, so he convinces his sister, Francis, to take the picture on her phone and email it to him. Then he texts the photo to Bob, as arranged.</p> <p></p> <p>Here, Emil and Francis are also acting as relays. Note that nobody knows about the full route. Alice thinks she's delivering directly to Bob. So does Darla. Bob knows about Darla and Emil, but not about Francis.</p> <p>Note, too, how the transport is changing from physical mail to email to text.</p> <p>To the party immediately upstream (closer to the sender), a relay is indistinguishable from the next party downstream (closer to the recipient). A party anywhere in the chain can insert one or more relays upstream from themselves, as long as those relays are not upstream of another named party (sender or mediator).</p>"},{"location":"concepts/0046-mediators-and-relays/#more-scenarios","title":"More Scenarios","text":"<p>Mediators and relays can be combined in any order and any amount in variations on our fictional scenario. Bob could employ Carl as a mediator, and Carl could work from home and arrange delivery via George, then have his daughter Hannah run messages back to Bob's desk at work. Carl could hire his own mediator. Darla could arrange or Ivan to substitute for her when she goes on vacation. And so forth.</p>"},{"location":"concepts/0046-mediators-and-relays/#more-traditional-usage","title":"More Traditional Usage","text":"<p>The scenarios used above are somewhat artificial. Our most familiar agent-to-agent scenarios involve edge agents running on mobile devices and accessible through bluetooth or push notification, and cloud agents that use electronic protocols as their transport. Let's see how relays and mediators apply there.</p>"},{"location":"concepts/0046-mediators-and-relays/#scenario-5-traditional-base","title":"Scenario 5 (traditional base)","text":"<p>Alice's cloud agent wants to talk to Bob's cloud agent. Bob's cloud agent is listening at http://bob.com/agent. Alice encrypts a message for Bob and posts it to that URL.</p> <p></p> <p>In this scenario, we are using a direct transport with neither a mediator nor a relay.</p> <p>If you are familiar with common routing patterns and you are steeped in HTTP, you are likely objecting at this point, pointing out ways that this description diverges from best practice, including what's prescribed in other RFC. You may be eager to explain why this is a privacy problem, for example.</p> <p>You are not wrong, exactly. But please suspend those concerns and hang with me. This is about what's theoretically possible in the mental model. Besides, I would note that virtually the same diagram could be used for a Bluetooth agent conversation:</p> <p></p>"},{"location":"concepts/0046-mediators-and-relays/#scenario-6-herd-hosting","title":"Scenario 6: herd hosting","text":"<p>Let's tweak Scenario 5 slightly by saying that Bob's agent is one of thousands that are hosted at the same URL. Maybe the URL is now http://agents-r-us.com/inbox. Now if Alice wants to talk to Bob's cloud agent, she has to cope with a mediator. She wraps the encrypted message for Bob's cloud agent inside a <code>forward</code> message that's addressed to and encrypted for the agent of agents-r-us that functions as a gatekeeper.</p> <p></p> <p>This scenario is one that highlights an external mediator--so-called because the mediator lives outside the sovereign domain of the final recipient.</p>"},{"location":"concepts/0046-mediators-and-relays/#scenario-7-intra-domain-dispatch","title":"Scenario 7: intra-domain dispatch","text":"<p>Now let's subtract agents-r-us. We're back to Bob's cloud agent listening directly at http://bob.com/agent. However, let's say that Alice has a different goal--now she wants to talk to the edge agent running on Bob's mobile device. This agent doesn't have a permanent IP address, so Bob uses his own cloud agent as a mediator. He tells Alice that his mobile device agent can only be reached via his cloud agent.</p> <p></p> <p>Once again, this causes Alice to modify her behavior. Again, she wraps her encrypted message. The inner message is enclosed in an outer envelope, and the outer envelope is passed to the mediator.</p> <p>This scenario highlights an internal mediator. Internal and external mediators introduce similar ../../features and similar constraints; the relevant difference is that internal mediators live within the sovereign domain of the recipient, and may thus be worthy of greater trust.</p>"},{"location":"concepts/0046-mediators-and-relays/#scenario-8-double-mediation","title":"Scenario 8: double mediation","text":"<p>Now let's combine. Bob's cloud agent is hosted at agents-r-us, AND Alice wants to reach Bob's mobile:</p> <p></p> <p>This is a common pattern with HTTP-based cloud agents plus mobile edge agents, which is the most common deployment pattern we expect for many users of self-sovereign identity. Note that the properties of the agency and the routing agent are not particularly special--they are just an external and an internal mediator, respectively.</p>"},{"location":"concepts/0046-mediators-and-relays/#related-concepts","title":"Related Concepts","text":""},{"location":"concepts/0046-mediators-and-relays/#routes-are-one-way-not-duplex","title":"Routes are One-Way (not duplex)","text":"<p>In all of this discussion, note that we are analyzing only a flow from Alice to Bob. How Bob gets a message back to Alice is a completely separate question. Just because Carl, Darla, Emil, Francis, and Agents-R-Us may be involved in how messages flow from Alice to Bob, does not mean they are involved in flow the opposite direction.</p> <p>Note how this breaks the simple assumptions of pure request-response technologies like HTTP, that assume the channel in (request) is also the channel out (response). Duplex request-response can be modeled with A2A, but doing so requires support that may not always be available, plus cooperative behavior governed by the <code>~thread</code> decorator.</p>"},{"location":"concepts/0046-mediators-and-relays/#conventions-on-direction","title":"Conventions on Direction","text":"<p>For any given one-way route, the direction of flow is always from sender to receiver. We could use many different metaphors to talk about the \"closer to sender\" and \"closer to receiver\" directions -- upstream and downstream, left and right, before and after, in and out. We've chosen to standardize on two:</p> <ul> <li> <p>The SSI Notation uses directional arrows. A message from Alice to Bob is notated as either <code>A --&gt; B</code> or <code>B &lt;-- A</code> -- whether the arrow faces left or right, it always points to Bob.</p> </li> <li> <p>In text, we use the words source-ward and dest-ward to clarify whether we are moving toward the sender, or toward the receiver, respectively. \"Dest-ward\" always corresponds to where the arrow is pointing and to later points in time; \"source-ward\" is the opposite direction. All messages, whether requests, responses, or otherwise, always flow dest-ward.</p> </li> </ul>"},{"location":"concepts/0046-mediators-and-relays/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem. DIDComm mediator Open source cloud-based mediator with Firebase support."},{"location":"concepts/0047-json-ld-compatibility/","title":"Aries RFC 0047: JSON-LD Compatibility","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2019-02-20</li> <li>Status Note: Has guided Indy design choices for several months. Not yet ratified by greater Aries community. </li> <li>Supersedes: Indy HIPE 0035</li> <li>Start Date: 2019-01-23</li> <li>Tags: concept, decorator</li> </ul>"},{"location":"concepts/0047-json-ld-compatibility/#summary","title":"Summary","text":"<p>Explains the goals of DID Communication with respect to JSON-LD, and how Aries proposes to accomplish them.</p>"},{"location":"concepts/0047-json-ld-compatibility/#motivation","title":"Motivation","text":"<p>JSON-LD is a familiar body of conventions that enriches the expressive power of plain JSON. It is natural for people who arrive in the DID Communication (DIDComm) ecosystem to wonder whether we are using JSON-LD--and if so, how. We need a coherent answer that clarifies our intentions and that keeps us true to those intentions as the ecosystem evolves.</p>"},{"location":"concepts/0047-json-ld-compatibility/#tutorial","title":"Tutorial","text":"<p>The JSON-LD spec is a recommendation work product of the W3C RDF Working Group Since it was formally recommended as version 1.0 in 2014, the JSON for Linking Data Community Group has taken up not-yet-standards-track work on a 1.1 update.</p> <p>JSON-LD has significant gravitas in identity circles. It gives to JSON some capabilities that are sorely needed to model the semantic web, including linking, namespacing, datatyping, signing, and a strong story for schema (partly through the use of JSON-LD on schema.org).</p> <p>However, JSON-LD also comes with some conceptual and technical baggage. It can be hard for developers to master its subtleties; it requires very flexible parsing behavior after built-in JSON support is used to deserialize; it references a family of related specs that have their own learning curve; the formality of its test suite and libraries may get in the way of a developer who just wants to read and write JSON and \"get stuff done.\"</p> <p>In addition, the problem domain of DIDComm is somewhat different from the places where JSON-LD has the most traction. The sweet spot for DIDComm is small, relatively simple JSON documents where code behavior is strongly bound to the needs of a specific interaction. DIDComm needs to work with extremely simple agents on embedded platforms. Such agents may experience full JSON-LD support as an undue burden when they don't even have a familiar desktop OS. They don't need arbitrary semantic complexity.</p> <p>If we wanted to use email technology to send a verifiable credential, we would model the credential as an attachment, not enrich the schema of raw email message bodies. DIDComm invites a similar approach.</p>"},{"location":"concepts/0047-json-ld-compatibility/#goal","title":"Goal","text":"<p>The DIDComm messaging effort that began in the Indy community wants to benefit from the accessibility of ordinary JSON, but leave an easy path for more sophisticated JSON-LD-driven patterns when the need arises. We therefore set for ourselves this goal:</p> <p>Be compatible with JSON-LD, such that advanced use cases can take advantage   of it where it makes sense, but impose no dependencies on the mental model or   the tooling of JSON-LD for the casual developer.</p>"},{"location":"concepts/0047-json-ld-compatibility/#what-the-casual-developer-needs-to-know","title":"What the Casual Developer Needs to Know","text":"<ul> <li> <p>The <code>@</code> character in DIDComm messages is reserved for JSON-LD-isms. Any usage of JSON keys that begin with this character is required to be JSON-LD-compatible, and any time you see it, you are seeing JSON-LD at work.</p> </li> <li> <p><code>@type</code> and <code>@id</code> are required at the root of every message. The meaning of these fields in DIDComm matches JSON-LD's expectations, but you don't need to learn JSON-LD to use them.</p> </li> <li> <p>JSON-LD's more advanced mechanisms are an option--not invoked ad hoc on a message-by-message basis, but specified in the formal description of a message family. You will know how much JSON-LD is relevant to a protocol when you implement it. In general, the community will want to discuss usage of new JSON-LD constructs before embracing them in protocols with broad interoperability intentions, because of the goal articulated above.</p> </li> <li> <p>The decorator concept in DIDComm is orthogonal to JSON-LD, and is far more likely to be relevant to your early learning. See the Decorator RFC.</p> </li> </ul> <p>That's it.</p>"},{"location":"concepts/0047-json-ld-compatibility/#details","title":"Details","text":"<p>Compatibility with JSON-LD was evaluated against version 1.1 of the JSON-LD spec, current in early 2019. If material changes in the spec are forthcoming, a new analysis may be worthwhile. Our current understanding follows.</p>"},{"location":"concepts/0047-json-ld-compatibility/#type","title":"<code>@type</code>","text":"<p>The type of a DIDComm message, and its associated route or handler in dispatching code, is given by the JSON-LD <code>@type</code> property at the root of a message. JSON-LD requires this value to be an IRI. DIDComm DID references are fully compliant. Instances of <code>@type</code> on any node other than a message root have JSON-LD meaning, but no predefined relevance in DIDComm.</p>"},{"location":"concepts/0047-json-ld-compatibility/#id","title":"<code>@id</code>","text":"<p>The identifier for a DIDComm message is given by the JSON-LD <code>@id</code> property at the root of a message. JSON-LD requires this value to be an IRI. DIDComm message IDs are relative IRIs, and can be converted to absolute form as described in RFC 0217: Linkable Message Paths. Instances of <code>@id</code> on any node other than a message root have JSON-LD meaning, but no predefined relevance in DIDComm.</p>"},{"location":"concepts/0047-json-ld-compatibility/#context","title":"<code>@context</code>","text":"<p>This is JSON-LD\u2019s namespacing mechanism. It is active in DIDComm messages, but can be ignored for simple processing, in the same way namespaces in XML are often ignored for simple tasks.</p> <p>Every DIDComm message has an associated <code>@context</code>, but we have chosen to follow the procedure described in section 6 of the JSON-LD spec, which focuses on how ordinary JSON can be intepreted as JSON-LD by communicating <code>@context</code> out of band.</p> <p>DIDComm messages communicate the context out of band by specifying it in the protocol definition (e.g., RFC) for the associated message type; thus, the value of <code>@type</code> indirectly gives the relevant <code>@context</code>. In advanced use cases, <code>@context</code> may appear in a DIDComm message, supplementing this behavior.</p>"},{"location":"concepts/0047-json-ld-compatibility/#ordering","title":"Ordering","text":"<p>JSON-LD specifies that the order of items in arrays is NOT significant, and notes (correctly) that this is the opposite of the standard assumption for plain JSON. This makes sense when viewed through the lens of JSON-LD\u2019s role as a transformation of RDF.</p> <p>Since we want to violate as few assumptions as possible for a developer with general knowledge of JSON, DIDComm messages reverse this default, making arrays an ordered construct, as if all DIDComm message <code>@context</code>s contained something like:</p> <p><pre><code>\"each field\": { \"@container\": \"@list\"}\n</code></pre> To contravene the default, use a JSON-LD construction like this in <code>@context</code>:</p> <pre><code>\"myfield\": { \"@container\": \"@set\"}\n</code></pre>"},{"location":"concepts/0047-json-ld-compatibility/#decorators","title":"Decorators","text":"<p>Decorators are JSON fragments that can be included in any DIDComm message. They enter the formally defined JSON-LD namespace via a JSON-LD fragment that is automatically imputed to every DIDComm message:</p> <pre><code>\"@context\": {\n  \"@vocab\": \"https://github.com/hyperledger/aries-rfcs/\"\n}\n</code></pre> <p>All decorators use the reserved prefix char <code>~</code> (tilde). For more on decorators, see the Decorator RFC.</p>"},{"location":"concepts/0047-json-ld-compatibility/#signing","title":"Signing","text":"<p>JSON-LD is associated but not strictly bound to a signing mechanism, LD-Signatures. It\u2019s a good mechanism, but it comes with some baggage: you must canonicalize, which means you must resolve every \u201cterm\u201d (key name) to its fully qualified form by expanding contexts before signing. This raises the bar for JSON-LD sophistication and library dependencies.</p> <p>The DIDComm community is not opposed to using LD Signatures for problems that need them, but has decided not to adopt the mechanism across the board. There is another signing mechanism that is far simpler, and adequate for many scenarios. We\u2019ll use whichever scheme is best suited to circumstances.</p>"},{"location":"concepts/0047-json-ld-compatibility/#type-coercion","title":"Type Coercion","text":"<p>DIDComm messages generally do not need this feature of JSON-LD, because there are well understood conventions around date-time datatypes, and individual RFCs that define each message type can further clarify such subtleties. However, it is available on a message-type-definition basis (not ad hoc).</p>"},{"location":"concepts/0047-json-ld-compatibility/#node-references","title":"Node References","text":"<p>JSON-LD lets one field reference another. See example 93 (note  that the ref could have just been \u201c#me\u201d instead of the fully qualified IRI).  We may need this construct at some point in DIDComm, but it is not in active  use yet.</p>"},{"location":"concepts/0047-json-ld-compatibility/#internationalization-and-localization","title":"Internationalization and Localization","text":"<p>JSON-LD describes a mechanism for this. It has approximately the same ../../features as the one described in Aries RFC 0043, with a few exceptions:</p> <ul> <li>The JSON-LD mechanism only applies to strings; it is explicitly disallowed for describing dates, numbers, or any strings that coerce to dates or numbers.</li> <li>The JSON-LD mechanism is language-centric rather than locale-centric. For example, it doesn't specify sort order, time-of-day, or currency semantics.</li> <li>There is no notion of a code that maps to strings--just a notion of strings that all have the same meaning. This means it doesn\u2019t help us solve the problem of locale-independent error codes.</li> <li>The notion of mappings of values for different locales is separable into an external catalog, but only if a value is referenced or included implicitly in a doc. In other words, a processor has to see the full message catalog when evaluating the doc.</li> <li>It\u2019s a bit awkward to retrofit onto an existing schema, because it requires a redefinition of the field that contains localized values, from being a single string to being a dictionary with language mappings. In other words, the schema before and after a developer adds localization support is not just different by new, optional fields; it is a breaking change. This contrasts with the indy PR approach, where the language mapping can be added after the fact, and gets associated by convention.</li> <li>It doesn\u2019t support localization of keys--only values. There are corner cases where key localization is desirable.</li> </ul> <p>Because of these misalignments, the DIDComm ecosystem plans to use its own solution to this problem.</p>"},{"location":"concepts/0047-json-ld-compatibility/#additional-json-ld-constructs","title":"Additional JSON-LD Constructs","text":"<p>The following JSON-LD keywords may be useful in DIDComm at some point in the future: <code>@base</code>, <code>@index</code>, <code>@container</code> (cf <code>@list</code> and <code>@set</code>), <code>@nest</code>, <code>@value</code>, <code>@graph</code>, <code>@prefix</code>, <code>@reverse</code>, <code>@version</code>.</p>"},{"location":"concepts/0047-json-ld-compatibility/#drawbacks","title":"Drawbacks","text":"<p>By attempting compatibility but only lightweight usage of JSON-LD, we are neither all-in on JSON-LD, nor all-out. This could cause confusion. We are making the bet that most developers won't need to know or care about the details; they'll simply learn that <code>@type</code> and <code>@id</code> are special, required fields on messages. Designers of protocols will need to know a bit more.</p>"},{"location":"concepts/0047-json-ld-compatibility/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>We could go all-in on JSON-LD. This would require adoption of sophisticated parsing that is impractical on embedded platforms, but it would add a lot of semantic sophistication.</li> <li>We could avoid JSON-LD entirely. This would force us to reinvent the wheel in some cases, and it would be frustrating to our friends in other SSI communities that are more JSON-LD-centric.</li> </ul>"},{"location":"concepts/0047-json-ld-compatibility/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the reversal of JSON-LD's default of unordered arrays valid?</li> <li>Is there a good way to discover that new DIDComm proposals should consider JSON-LD solutions, and make sure such questions get evaluated thoughtfully?</li> </ul>"},{"location":"concepts/0047-json-ld-compatibility/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0049-repudiation/","title":"Aries RFC 0049: Repudiation","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2019-03-01</li> <li>Status Note: Well understood and baked into various protocol designs and DIDComm processes--but not yet ratified by the larger Aries community. </li> <li>Supersedes: Indy HIPE 0037</li> <li>Start Date: 2018-03-01 (backdated)</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0049-repudiation/#summary","title":"Summary","text":"<p>Explain DID Communication's perspective on repudiation, and how this influences the DIDComm approach to digital signatures.</p>"},{"location":"concepts/0049-repudiation/#motivation","title":"Motivation","text":"<p>A very common mistake among newcomers to cryptography is to assume that digital signatures are the best way to prove the origin of data. While it is true that digital signatures can be used in this way, over-signing creates a digital exhaust that can lead to serious long-term privacy problems. We do use digital signatures, but we want to be very deliberate about when and why--and by default, we want to use a more limited technique called authenticated encryption. This doc explains the distinction and its implications.</p>"},{"location":"concepts/0049-repudiation/#tutorial","title":"Tutorial","text":"<p>If Carol receives a message that purports to come from Alice, she may naturally ask:</p> <p>Do I know that this really came from Alice?</p> <p>This is a fair question, and an important one. There are two ways to answer it:</p> <ul> <li>Alice can send in a way that's repudiable</li> <li>Alice can send in a way that's non-repudiable</li> </ul> <p>Both of these approaches can answer Carol's question, but they differ   in who can trust the answer. If Carol knows Alice is the sender,  but can't prove it to anybody else, then we say the  message is publicly repudiable; if Carol can prove the origin  to others, then we say the message is non-repudiable.</p> <p>The repudiable variant is accomplished with a technique called authenticated encryption.</p> <p>The non-repudiable variant is accomplished with digital signatures.</p>"},{"location":"concepts/0049-repudiation/#how-authenticated-encryption-works","title":"How Authenticated Encryption Works","text":"<p>Repudiable sending may sound mysterious, but it's actually quite simple.  Alice and Carol can negotiate a shared secret and trust one another not to  leak it. Thereafter, if Alice sends Carol a message that uses the shared  secret (e.g., it's encrypted by a negotiated symmetric  encryption key), then Carol knows the sender must be Alice. However,  she can't prove it to anyone, because Alice's immediate counter-response  could be, \"Carol could have encrypted this herself. She knows the key, too.\"  Notice that this only works in a pairwise channel.</p>"},{"location":"concepts/0049-repudiation/#signatures","title":"Signatures","text":"<p>Non-repudiable messages are typically accomplished with digital  signatures. With signatures, everyone can examine a signature to verify  its provenance.</p> <p>Fancy signature schemes such as ring signatures may represent intermediate  positions, where the fact that a signature was provided by a member of  a group is known--but not which specific member did the signing.</p>"},{"location":"concepts/0049-repudiation/#why-and-when-to-use-each-strategy","title":"Why and When To Use Each Strategy","text":"<p>A common mistake is to assume that digital signatures should be used everywhere because they give the most guarantees. This is a misunderstanding of who needs which guarantees under which conditions.</p> <p>If Alice tells a secret to Carol, who should decide whether the secret is reshared--Alice, or Carol?</p> <p></p> <p>In an SSI paradigm, the proper, desirable default is that a sender of secrets should retain the ability to decide if their secrets are shareable, not give that guarantee away.</p> <p>If Alice sends a repudiable message, she gets a guarantee that Carol can't reshare it in a way that damages Alice. On the other hand, if she sends a message that's digitally signed, she has no control over where Carol shares the secret and proves its provenance. Hopefully Carol has Alice's best interests at heart, and has good judgment and solid cybersecurity...</p> <p>There are certainly cases where non-repudiation is appropriate. If  Alice is entering into a borrower:lender relationship with Carol,  Carol needs to prove to third parties that Alice, and only Alice,  incurred the legal obligation.</p> <p>DIDComm supports both modes of communication. However, properly modeled  interactions tend to favor repudiable messages; non-repudiation must be  a deliberate choice. For this reason, we assume repudiable until  an explicit signature is required (in which case the <code>sign()</code> crypto  primitive is invoked). This matches the physical world, where most  communication is casual and does not carry the weight of legal  accountability--and should not.</p>"},{"location":"concepts/0049-repudiation/#unknown-recipients","title":"Unknown Recipients","text":"<p>Imagine that Alice wants to broadcast a message. She doesn't know who will receive it, so she can't use authenticated encryption. Yet she wants anyone who receives it to know that it truly comes from her.</p> <p>In this situation, digital signatures are required. Note, however, that Alice is trading some privacy for her ability to publicly prove message origin.</p>"},{"location":"concepts/0049-repudiation/#reference","title":"Reference","text":"<p>Authenticated encryption is not something we invented. It is well described in the documentation for libsodium. It is implemented there, and also in the pure javascript port, TweetNacl.</p>"},{"location":"concepts/0049-repudiation/#drawbacks","title":"Drawbacks","text":"<p>The main reason not to emphasize authenticated encryption over digital signatures is that we seem to encounter a steady impedance from people who are signature-oriented. It is hard and time-consuming to reset expectations. However, we have concluded that the gains in privacy are worth the effort.</p>"},{"location":"concepts/0049-repudiation/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0050-wallets/","title":"Aries RFC 0050: Wallets","text":"<ul> <li>Authors: Daniel Hardman, Darko Kulic, Vyacheslav Gudkov, Mike Lodder</li> <li>Status: ACCEPTED</li> <li>Since: 2018-07-01</li> <li>Status Note: Fully implemented in Indy SDK, but not yet socialized well in the broader Aries community. Needs some updates to promote better key management; see related RFC about lox. </li> <li>Supersedes: Indy HIPE 0013</li> <li>Start Date: 2018-05-22</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0050-wallets/#summary","title":"Summary","text":"<p>Specify the external interfaces of identity wallets in the Indy ecosystem, as well as some background ../../concepts, theory, tradeoffs, and internal implementation guidelines.</p> <p></p>"},{"location":"concepts/0050-wallets/#motivation","title":"Motivation","text":"<p>Wallets are a familiar component metaphor that SSI has adopted from the world of cryptocurrencies. The translation isn't perfect, though; crypto wallets have only a subset of the ../../features that an identity wallet needs. This causes problems, as coders may approach wallets in Indy with assumptions that are more narrow than our actual design target.</p> <p>Since wallets are a major vector for hacking and cybersecurity issues, casual or fuzzy wallet requirements are a recipe for frustration or disaster. Divergent and substandard implementations could undermine security more broadly. This argues for as much design guidance and implementation help as possible.</p> <p>Wallets are also a unit of identity portability--if an identity owner doesn't like how her software is working, she should be able to exercise her self- sovereignty by taking the contents of her wallet to a new service. This implies that wallets need certain types of interoperability in the ecosystem, if they are to avoid vendor lock-in.</p> <p>All of these reasons--to clarify design scope, to provide uniform high security, and to guarantee interop--suggest that we need a formal RFC to document wallet architecture.</p>"},{"location":"concepts/0050-wallets/#tutorial","title":"Tutorial","text":"<p>(For a slide deck that gives a simplified overview of all the content in this RFC, please see http://bit.ly/2JUcIiT. The deck also includes a link to a recorded presentation, if you prefer something verbal and interactive.)</p>"},{"location":"concepts/0050-wallets/#what-is-an-identity-wallet","title":"What Is an Identity Wallet?","text":"<p>Informally, an identity wallet (preferably not just \"wallet\") is a digital container for data that's needed to control a self-sovereign identity. We borrow this metaphor from physical wallets:</p> <p></p> <p>Notice that we do not carry around in a physical wallet every document, key, card, photo, piece of currency, or credential that we possess. A wallet is a mechanism of convenient control, not an exhaustive repository. A wallet is portable. A wallet is worth safeguarding. Good wallets are organized so we can find things easily. A wallet has a physical location.</p> <p>What does suggest about identity wallets?</p>"},{"location":"concepts/0050-wallets/#types-of-sovereign-data","title":"Types of Sovereign Data","text":"<p>Before we give a definitive answer to that question, let's take a detour for a moment to consider digital data. Actors in a self-sovereign identity ecosystem may own or control many different types of data:</p> <ul> <li>encryption and signing keys</li> <li>payment keys</li> <li>link secrets</li> <li>PII about themselves or others</li> <li>credentials</li> <li>personal documents (e.g., last year's tax filing, journal, love letters)</li> <li>digital breadcrumbs (e.g., purchase history)</li> <li>photos and videos</li> <li>receipts</li> <li>health records</li> </ul> <p>...and much more. Different subsets of data may be worthy of different protection efforts:</p> <p></p> <p>The data can also show huge variety in its size and in its richness:</p> <p></p> <p>Because of the sensitivity difference, the size and richness difference, joint ownership, and different needs for access in different circumstances, we may store digital data in many different locations, with different backup regimes, different levels of security, and different cost profiles.</p>"},{"location":"concepts/0050-wallets/#whats-out-of-scope","title":"What's Out of Scope","text":""},{"location":"concepts/0050-wallets/#not-a-vault","title":"Not a Vault","text":"<p>This variety suggests that an identity wallet as a loose grab-bag of all our digital \"stuff\" will give us a poor design. We won't be able to make good tradeoffs that satisfy everybody; some will want rigorous, optimized search; others will want to minimize storage footprint; others will be concerned about maximizing security.</p> <p>We reserve the term vault to refer to the complex collection of all an identity owner's data:</p> <p></p> <p>Note that a vault can contain an identity wallet. A vault is an important construct, and we may want to formalize its interface. But that is not the subject of this spec.</p>"},{"location":"concepts/0050-wallets/#not-a-cryptocurrency-wallet","title":"Not A Cryptocurrency Wallet","text":"<p>The cryptocurrency community has popularized the term \"wallet\"--and because identity wallets share with crypto wallets both high-tech crypto and a need to store secrets, it is tempting to equate these two ../../concepts. However, an identity wallet can hold more than just cryptocurrency keys, just as a physical wallet can hold more than paper currency. Also, identity wallets may need to manage hundreds of millions of relationships (in the case of large organizations), whereas most crypto wallets manage a small number of keys:</p> <p></p>"},{"location":"concepts/0050-wallets/#not-a-gui","title":"Not a GUI","text":"<p>As used in this spec, an identity wallet is not a visible application, but rather a data store. Although user interfaces (superb ones!) can and should be layered on top of wallets, from indy's perspective the wallet itself consists of a container and its data; its friendly face is a separate construct. We may casually refer to an application as a \"wallet\", but what we really mean is that the application provides an interface to the underlying wallet.</p> <p>This is important because if a user changes which app manages his identity, he should be able to retain the wallet data itself. We are aiming for a better portability story than browsers offer (where if you change browsers, you may be able to export+import your bookmarks, but you have to rebuild all sessions and logins from scratch).</p>"},{"location":"concepts/0050-wallets/#personas","title":"Personas","text":"<p>Wallets have many stakeholders. However, three categories of wallet users are especially impactful on design decisions, so we define a persona for each.</p>"},{"location":"concepts/0050-wallets/#alice-individual-identity-owner","title":"Alice (individual identity owner)","text":"<p>Alice owns several devices, and she has an agent in the cloud. She has a thousand relationships--some with institutions, some with other people. She has a couple hundred credentials. She owns three different types of cryptocurrency. She doesn\u2019t issue or revoke credentials--she just uses them. She receives proofs from other entities (people and orgs). Her main tool for exercising a self-sovereign identity is an app on a mobile device.</p>"},{"location":"concepts/0050-wallets/#faber-intitutional-identity-owner","title":"Faber (intitutional identity owner)","text":"<p>Faber College has an on-prem data center as well as many resources and processes in public and private clouds. It has relationships with a million students, alumni, staff, former staff, applicants, business partners, suppliers, and so forth. Faber issues credentials and must manage their revocation. Faber may use crypto tokens to sell and buy credentials and proofs.</p>"},{"location":"concepts/0050-wallets/#the-org-book-trust-hub","title":"The Org Book (trust hub)","text":"<p>The Org Book holds credentials (business licenses, articles of incorporation, health permits, etc) issued by various government agencies, about millions of other business entities. It needs to index and search credentials quickly. Its data is public. It serves as a reference for many relying parties--thus its trust hub role.</p>"},{"location":"concepts/0050-wallets/#use-cases","title":"Use Cases","text":"<p>The specific uses cases for an identity wallet are too numerous to fully list, but we can summarize them as follows:</p> <p>As an identity owner (any of the personas above), I want to manage identity and its relationships in a way that guarantees security and privacy:</p> <ul> <li>Create an identity</li> <li>Setup protective policies</li> <li>Govern agents</li> <li>Connect and interact with others</li> <li>Recover and revoke</li> <li>Take an identity somewhere else</li> </ul>"},{"location":"concepts/0050-wallets/#managing-secrets","title":"Managing Secrets","text":"<p>Certain sensitive things require special handling. We would never expect to casually lay an ebola zaire sample on the counter in our bio lab; rather, it must never leave a special controlled isolation chamber.</p> <p></p> <p>Cybersecurity in wallets can be greatly enhanced if we take a similar tack with high-value secrets. We prefer to generate such secrets in their final resting place, possibly using a seed if we need determinism. We only use such secrets in their safe place, instead of passing them out to untrusted parties.</p> <p>TPMs, HSMs, and so forth follow these rules. Indy\u2019s current wallet interface does, too. You can\u2019t get private keys out.</p>"},{"location":"concepts/0050-wallets/#composition","title":"Composition","text":"<p>The foregoing discussions about cybersecurity, the desirability of design guidance and careful implementation, and wallet data that includes but is not limited to secrets motivates the following logical organization of identity wallets in Indy:</p> <p></p> <p>The world outside a wallet interfaces with the wallet through a public interface provided by indy-sdk, and implemented only once. This is the block labeled <code>encryption, query (wallet core)</code> in the diagram. The implementation in this layer guarantees proper encryption and secret-handling. It also provides some query ../../features. Records (items) to be stored in a wallet are referenced by a public handle if they are secrets. This public handle might be a public key in a key pair, for example. Records that are not secrets can be returned directly across the API boundary.</p> <p>Underneath, this common wallet code in libindy is supplemented with pluggable storage-- a technology that provides persistence and query ../../features. This pluggable storage could be a file system, an object store, an RDBMS, a NoSQL DB, a Graph DB, a key~value store, or almost anything similar. The pluggable storage is registered with the wallet layer by providing a series of C-callable functions (callbacks). The storage layer doesn't have to worry about encryption at all; by the time data reaches it, it is encrypted robustly, and the layer above the storage takes care of translating queries to and from encrypted form for external consumers of the wallet.</p>"},{"location":"concepts/0050-wallets/#tags-and-queries","title":"Tags and Queries","text":"<p>Searchability in wallets is facilitated with a tagging mechanism. Each item in a wallet can be associated with zero or more tags, where a tag is a <code>key=value</code> pair. Items can be searched based on the tags associated with them, and tag values can be strings or numbers. With a good inventory of tags in a wallet, searching can be robust and efficient--but there is no support for joins, subqueries, and other RDBMS-like constructs, as this would constrain the type of storage plugin that could be written.</p> <p>An example of the tags on a wallet item that is a credential might be:</p> <pre><code>  item-name = \"My Driver's License\"\n  date-issued = \"2018-05-23\"\n  issuer-did = \"ABC\"\n  schema = \"DEF\"\n</code></pre> <p>Tag names and tag values are both case-sensitive.</p> <p>Because tag values are normally encrypted, most tag values can only be tested using the <code>$eq</code>, <code>$neq</code> or <code>$in</code> operators (see Wallet Query Language, next). However, it is possible to force a tag to be stored in the wallet as plain text by naming it with a special prefix, <code>~</code> (tilde). This enables operators like <code>$gt</code>, <code>$lt</code>, and <code>$like</code>. Such tags lose their security guarantees but provide for richer queries; it is up to applications and their users to decide whether the tradeoff is appropriate.</p>"},{"location":"concepts/0050-wallets/#wallet-query-language","title":"Wallet Query Language","text":"<p>Wallets can be searched and filtered using a simple, JSON-based query language. We call this Wallet Query Language (WQL). WQL is designed to require no fancy parsing by storage plugins, and to be easy enough for developers to learn in just a few minutes. It is inspired by MongoDB's query syntax, and can be mapped to SQL, GraphQL, and other query languages supported by storage backends, with minimal effort.</p> <p>Formal definition of WQL language is the following:</p> <pre><code>query = {subquery}\nsubquery = {subquery, ..., subquery} // means subquery AND ... AND subquery\nsubquery = $or: [{subquery},..., {subquery}] // means subquery OR ... OR subquery\nsubquery = $not: {subquery} // means NOT (subquery)\nsubquery = \"tagName\": tagValue // means tagName == tagValue\nsubquery = \"tagName\": {$neq: tagValue} // means tagName != tagValue\nsubquery = \"tagName\": {$gt: tagValue} // means tagName &gt; tagValue\nsubquery = \"tagName\": {$gte: tagValue} // means tagName &gt;= tagValue\nsubquery = \"tagName\": {$lt: tagValue} // means tagName &lt; tagValue\nsubquery = \"tagName\": {$lte: tagValue} // means tagName &lt;= tagValue\nsubquery = \"tagName\": {$like: tagValue} // means tagName LIKE tagValue\nsubquery = \"tagName\": {$in: [tagValue, ..., tagValue]} // means tagName IN (tagValue, ..., tagValue)\n</code></pre>"},{"location":"concepts/0050-wallets/#sample-wql-query-1","title":"Sample WQL Query 1","text":"<p>Get all credentials where subject like \u2018Acme%\u2019 and issue_date &gt; last week. (Note here that the name of the issue date tag begins with a tilde, telling the wallet to store its value unencrypted, which makes the <code>$gt</code> operator possible.)</p> <pre><code>{\n  \"~subject\": {\"$like\": \"Acme%\"},\n  \"~issue_date\": {\"$gt\": 2018-06-01}\n}\n</code></pre>"},{"location":"concepts/0050-wallets/#sample-wql-query-2","title":"Sample WQL Query 2","text":"<p>Get all credentials about me where schema in (a, b, c) and issuer in (d, e, f).</p> <pre><code>{\n  \"schema_id\": {\"$in\": [\"a\", \"b\", \"c\"]},\n  \"issuer_id\": {\"$in\": [\"d\", \"e\", \"f\"]},\n  \"holder_role\": \"self\"\n}\n</code></pre>"},{"location":"concepts/0050-wallets/#encryption","title":"Encryption","text":"<p>Wallets need very robust encryption. However, they must also be searchable, and the encryption must be equally strong regardless of which storage technology is used. We want to be able to hide data patterns in the encrypted data, such that an attacker cannot see common prefixes on keys, or common fragments of data in encrypted values. And we want to rotate the key that protects a wallet without having to re-encrypt all its content. This suggests that a trivial encryption scheme, where we pick a symmetric key and encrypt everything with it, is not adequate.</p> <p>Instead, wallet encryption takes the following approach:</p> <ul> <li>For attributes of items that are searchable  (<code>type</code>, <code>id</code>, <code>tag_name</code>,   <code>tag_value</code>):</li> <li>The same input produces the same output.</li> <li>Every attribute \"column\" has its own key. That is, there's an encryption key for     all <code>type</code> attributes, a different encryption key for all <code>id</code> attributes,     and so forth.</li> <li>Initialization vector is HMAC-256 value of the field being encrypted.</li> <li> <p>Two more keys are needed for HMAC--one for <code>type</code> and <code>id</code> and one for     <code>tag_name</code> and <code>tag_value</code>.</p> </li> <li> <p>For item values:</p> </li> <li>A new value key is generated for each item value.</li> <li>Value key is encrypted using key for that field. (Value key also has a \"column\"     key that contributes to its encryption.)</li> <li> <p>Initialization vector is generated every time for both encryptions.</p> </li> <li> <p>For wallet keys:</p> </li> <li>Encrypted with master key with random initialization vector.</li> </ul> <p>The 7 \"column\" keys are concatenated and encrypted with a wallet master key,  then saved into the metadata of the wallet. This allows the master key to be rotated  without re-encrypting all the items in the wallet.</p> <p>Today, all encryption is done using ChaCha20-Poly1305, with HMAC-SHA256. This is a solid, secure encryption algorithm, well tested and widely supported. However, we anticipate the desire to use different cipher suites, so in the future we will make the cipher suite pluggable.</p> <p>The way the individual fields are encrypted is shown in the following diagram. Here, data is shown as if stored in a relational database with tables. Wallet storage may or may not use tables, but regardless of how the storage distributes and divides the data, the logical relationships and the encryption shown in the diagram apply.</p> <p></p>"},{"location":"concepts/0050-wallets/#pluggable-storage","title":"Pluggable Storage","text":"<p>Although Indy infrastructure will provide only one wallet implementation it will allow to plug different storages for covering of different use cases. Default storage shipped with libindy will be sqlite based and well suited for agents running on edge devices. The API endpoint <code>register_wallet_storage</code> will allow Indy Developers to register a custom storage implementation as a set of handlers.</p> <p>A storage implementation does not need any special security ../../features. It stores data that was already encrypted by libindy (or data that needs no encryption/protection, in the case of unencrypted tag values). It searches data in whatever form it is persisted, without any translation. It returns data as persisted, and lets the common wallet infrastructure in libindy decrypt it before return it to the user.</p>"},{"location":"concepts/0050-wallets/#secure-enclaves","title":"Secure Enclaves","text":"<p>Secure Enclaves are purposely designed to manage, generate, and securely store cryptographic material. Enclaves can be either specially designed hardware (e.g. HSM, TPM) or trusted execution environments (TEE) that isolate code and data from operating systems (e.g. Intel SGX, AMD SVE, ARM Trustzone). Enclaves can replace common cryptographic operations that wallets perform (e.g. encryption, signing). Some secrets cannot be stored in wallets like the key that encrypts the wallet itself or keys that are backed up. These cannot be stored in enclaves as keys stored in enclaves cannot be extracted. Enclaves can still protect these secrets via a mechanism called wrapping.</p>"},{"location":"concepts/0050-wallets/#enclave-wrapping","title":"Enclave Wrapping","text":"<p>Suppose I have a secret, X, that needs maximum protection. However, I can\u2019t store X in my secure enclave because I need to use it for operations that the enclave can\u2019t do for me; I need direct access. So how to I extend enclave protections to encompass my secret?</p> <p>I ask the secure enclave to generate a key, Y, that will be used to protect X. Y is called a wrapping key. I give X to the secure enclave and ask that it be encrypted with wrapping key Y. The enclave returns X\u2019 (ciphertext of X, now called a wrapped secret), which I can leave on disk with confidence; it cannot be decrypted to X without involving the secure enclave. Later, when I want to decrypt, I give wrapped secret X\u2019 to the secure enclave and ask it to give me back X by decrypting with wrapping key Y.</p> <p></p> <p>You could ask whether this really increases security. If you can get into the enclave, you can wrap or unwrap at will.</p> <p>The answer is that an unwrapped secret is protected by only one thing--whatever ACLs exist on the filesystem or storage where it resides. A wrapped secret is protected by two things--the ACLs and the enclave. OS access may breach either one, but pulling a hard drive out of a device will not breach the enclave.</p>"},{"location":"concepts/0050-wallets/#paper-wallets","title":"Paper Wallets","text":"<p>It is possible to persist wallet data to physical paper (or, for that matter, to etched metal or other physical media) instead of a digital container. Such data has attractive storage properties (e.g., may survive natural disasters, power outages, and other challenges that would destroy digital data). Of course, by leaving the digital realm, the data loses its accessibility over standard APIs.</p> <p>We anticipate that paper wallets will play a role in backup and recovery, and possibly in enabling SSI usage by populations that lack easy access to smartphones or the internet. Our wallet design should be friendly to such usage, but physical persistence of data is beyond the scope of Indy's plugin storage model and thus not explored further in this RFC.</p>"},{"location":"concepts/0050-wallets/#backup-and-recovery","title":"Backup and Recovery","text":"<p>Wallets need a backup and recovery feature, and also a way to export data and import it. Indy's wallet API includes an export function and an import function that may be helpful in such use cases. Today, the export is unfiltered--all data is exported. The import is also all-or-nothing and must be to an empty wallet; it is not possible to import selectively or to update existing records during import.</p> <p>A future version of import and export may add filtering, overwrite, and progress callbacks. It may also allow supporting or auxiliary data (other than what the wallet directly persists) to be associated with the export/import payload.</p> <p>For technical details on how export and import work, please see the internal design docs.</p>"},{"location":"concepts/0050-wallets/#reference","title":"Reference","text":"<ul> <li>Wallet Design</li> </ul>"},{"location":"concepts/0050-wallets/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>We could implement wallets purely as built already in the cryptocurrency world. This would give us great security (except for crypto wallets that are cloud based), and perhaps moderately good usability.</p> <p>However, it would also mean we could not store credentials in wallets. Indy would then need an alternate mechanism to scan some sort of container when trying to satisfy a proof request. And it would mean that a person's identity would not be portable via a single container; rather, if you wanted to take your identity to a new place, you'd have to copy all crypto keys in your crypto wallet, plus copy all your credentials using some other mechanism. It would also fragment the places where you could maintain an audit trail of your SSI activities.</p>"},{"location":"concepts/0050-wallets/#prior-art","title":"Prior art","text":"<p>See comment about crypto wallets, above.</p>"},{"location":"concepts/0050-wallets/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What is the relationship between a threading model in pluggable storage and   the threading model of wallets? Is it always legal to be reading and writing   wallets from multiple threads at the same time?</li> </ul>"},{"location":"concepts/0050-wallets/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy SDK Most agents that implement wallets get their wallet support from Indy SDK. These are not listed separately."},{"location":"concepts/0051-dkms/","title":"Aries RFC 0051: Decentralized Key Management","text":"<ul> <li>Authors: Drummond Reed et al.</li> <li>Status: RETIRED</li> <li>Since: 2024-04-03</li> <li>Status Note: Covered elsewhere and not specific to Aries.</li> <li>Start Date: 2018-09-01 (approx, backdated)</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0051-dkms/#summary","title":"Summary","text":"<p>Describes a general approach to key management in a decentralized, self-sovereign world. We expect Aries to embody the principles described here; this doc is likely to color numerous protocols  and ecosystem ../../features.</p>"},{"location":"concepts/0051-dkms/#motivation","title":"Motivation","text":"<p>A decentralized key management system (DKMS) is an approach to cryptographic key management where there is no central authority. DKMS leverages the security, immutability, availability, and resiliency properties of distributed ledgers to provide highly scalable key distribution, verification, and recovery.</p> <p>Key management is vital to exercising sovereignty in a digital ecosystem, and decentralization is a vital principle as well. Therefore, we need a coherent and comprehensive statement of philosophy and architecture on this vital nexus of topics.</p>"},{"location":"concepts/0051-dkms/#tutorial","title":"Tutorial","text":"<p>The bulk of the content for this RFC is located in the official architecture documentation -- dkms-v4.md; readers are encouraged to go there to learn more. Here we present only the highest-level background context, for those who may be unaware of some basics.</p>"},{"location":"concepts/0051-dkms/#background-concepts","title":"Background Concepts","text":""},{"location":"concepts/0051-dkms/#key-types","title":"Key Types","text":"<p>DKMS uses the following key types: 1. Master keys: Keys that are not cryptographically protected. They are distributed manually or initially installed and protected by procedural controls and physical or electronic isolation. 2. Key encrypting keys: Symmetric or public keys used for key transport or storage of other keys. 3. Data keys: Used to provide cryptographic operations on user data (e.g., encryption, authentication).</p> <p>The keys at one level are used to protect items at a lower level. Consequently, special measures are used to protect master keys, including severely limiting access and use, hardware protection, and providing access to the key only under shared control.</p>"},{"location":"concepts/0051-dkms/#key-loss","title":"Key Loss","text":"<p>Key loss means the owner no longer controls the key and it can assume there is no further risk of compromise. For example devices unable to function due to water, electricity, breaking, fire, hardware failure, acts of God, etc.</p>"},{"location":"concepts/0051-dkms/#compromise","title":"Compromise","text":"<p>Key compromise means that private keys and/or master keys have become or can become known either passively or actively.</p>"},{"location":"concepts/0051-dkms/#recovery","title":"Recovery","text":"<p>In decentralized identity management, recovery is important since identity owners have no \u201chigher authority\u201d to turn to for recovery. 1. Offline recovery uses physical media or removable digital media to store recovery keys. 2. Social recovery employs entities trusted by the identity owner called \"trustees\" who store recovery data on an identity owners behalf\u2014typically in the trustees own agent(s).</p> <p>These methods are not exclusive and should be combined with key rotation and revocation for proper security.</p>"},{"location":"concepts/0051-dkms/#reference","title":"Reference","text":"<ol> <li>Design and architecture</li> <li>Public Registry for Agent Authorization Policy. An identity owner creates a policy on the ledger that defines its agents and their authorizations.    Agents while acting on the behalf of the identity owner need to prove that they are authorised. More details</li> <li>Shamir Secret</li> <li>Trustee Protocols</li> </ol>"},{"location":"concepts/0051-dkms/#drawbacks-rationale-and-alternatives-prior-art-unresolved-questions","title":"Drawbacks, Rationale and alternatives, Prior art, Unresolved Questions","text":"<p>The material that's normally in these sections of a RFC appears in the official architecture documentation -- dkms-v4.md.</p>"},{"location":"concepts/0051-dkms/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy SDK partial: backup Connect.Me partial: backup, sync to cloud"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/","title":"Agent Authz policy (changes for ledger)","text":"<p>Objective: Prove agents are authorized to provide proof of claims and authorize and de-authorize other agents</p>"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#assumptions","title":"Assumptions","text":"<ol> <li>The ledger maintains a global accumulator that holds commitments sent by the agents.</li> <li>The global accumulator is maintained by the each node so every node knows the accumulator private key</li> <li>Agent auth policy txns are stored at the identity ledger.</li> <li>Each auth policy is uniquely identified by a policy address <code>I</code>.</li> <li>One agent can belong to several authz policies, thus several different <code>I</code>'s.</li> <li>An agent can have several authorizations. Following are the list of authorizations:</li> <li>PROVE</li> <li>PROVE_GRANT</li> <li>PROVE_REVOKE</li> <li>ADMIN</li> </ol>"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#transactions","title":"Transactions","text":""},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#agent_authz","title":"AGENT_AUTHZ","text":"<p>An authz policy is created/updated by an <code>AGENT_AUTHZ</code> transaction. A transaction creating a new authz policy: <pre><code>{\n    identifier: &lt;transaction sender's verification key&gt;\n    signature: &lt;signature created by the sender's public key&gt;,\n    req_id: &lt;a nonce&gt;,\n    operation: {\n        type: AGENT_AUTHZ,\n        address: &lt;policy address, I&gt;,\n        verkey: &lt;optional, verification key of the agent&gt;,\n        authorization: &lt;optional, a bitset&gt;,\n        commitment: &lt;optional&gt;\n    }\n} \n</code></pre> address: The policy address, this is a unique identifier of an authz policy. Is a large number (size/range TBD). If the ledger has never seen the provided policy address, it considers the transaction a creation of a new authz policy else it is considered an update of an existing policy identifier by the address. verkey: An ed25519 verkey of the agent to which the <code>authorization</code> corresponds. This is optional when a new policy is being created as <code>identifier</code> is sufficient. This verkey should be kept different from any DID verkey to avoid correlation.  authorization: A bitset indicating which authorizations are being given to the agent, it is ignored when creating a new policy (the ledger does not know <code>I</code>). The various bits indicate different authorizations:</p> <pre><code>0 None (revoked)\n1 ADMIN (all)\n2 PROVE\n3 PROVE_GRANT\n4 PROVE_REVOKE\n5 \"Reserved for future\"\n6 \"Reserved for future\"\n7  ... \n   ... \n</code></pre> <p>While creating a new policy, this field's value is ignored and the creator agent has all authorizations. For any subsequent policy transactions, the ledger checks if the sender (author to be precise, since anyone can send a transaction once a signature has been done) of transaction has the authorization to make the transaction, eg. The author of txn has <code>PROVE_GRANT</code> if it is giving a <code>PROVE</code> authorization to another agent. Future Work: When we support <code>m-of-n</code> authorization, <code>verkey</code> would be a map stating the policy and the verkeys</p> <p>commitment: This is a number (size/range TBD) given by the agent when it is being given a <code>PROVE</code> authorization. Thus this field is only needed when a policy is being created or an agent is being given the <code>PROVE</code> authorization. The ledger upon receiving this commitment checks if the commitment is prime and if it is then it updates the global accumulator with this commitment. Efficient primality testing algorithms like BPSW or ECPP can be used but the exact algorithm is yet to be decided.  If the commitment is not prime (in case of creation or update of policy address) then the transaction is rejected. The ledger rejects the transaction if it has already seen the commitment as part of another transaction.  In case of creation of new policy or an agent being given <code>PROVE</code> authorization, the ledger responds with the accumulator value after the update with this commitment.</p>"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#get_agent_authz","title":"GET_AGENT_AUTHZ","text":"<p>This query is sent by any client to check what the authz policy of any address <code>I</code> is <pre><code>{\n    ...,\n    operation: {\n        type: GET_AGENT_AUTHZ,\n        address: &lt;policy address, I&gt;,\n    }\n} \n</code></pre></p> <p>The ledger replies with all the agents, their associated authorizations and the commitments of the address <code>I</code>.</p>"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#get_agent_authz_accum","title":"GET_AGENT_AUTHZ_ACCUM","text":"<p>This query is sent by anyone to get the value of the accumulator.  <pre><code>{\n    ...,\n    operation: {\n        type: GET_AGENT_AUTHZ_ACCUM,\n    accum_id: &lt;id of either the provisioned agents accumulator or the revoked agent accumulator&gt;\n    }\n} \n</code></pre> The ledger returns the global accumulator with the id. Both accumulators are add only; the client checks that commitment is present in one accumulator AND not present in other accumulator.</p>"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#data-structures","title":"Data structures","text":""},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#ledger","title":"Ledger","text":"<p>Each authz transaction goes in the identity ledger.</p>"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#state-trie","title":"State trie.","text":"<p>The state stores: 1. Accumulator: The accumulator is stored in the trie at name <code>&lt;special byte denoting an authz prove accumulator&gt;</code> with value as the value of accumulator.  2. Policies: The state stores one name for each policy, the name is <code>&lt;special byte denoting an authz policy&gt;:&lt;policy address&gt;</code>, the value at this name is a hash. The hash is determined deterministically serializing (RLP encoding from ethereum, we already use this) this data structure: </p> <pre><code>[\n  [&lt;agent verkey1&gt;, &lt;authorization bitset&gt;, [commitment&gt;]],\n  [&lt;agent verkey2&gt;, &lt;authorization bitset&gt;, [commitment&gt;]],\n  [&lt;agent verkey3&gt;, &lt;authorization bitset&gt;, [commitment&gt;]],\n]\n</code></pre> <p>The hash of above can then be used to lookup (it is not, more on this later) the exact authorization policy in a separate name-value store. This is done to keep the database backing the state (trie) smaller.</p>"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#caches","title":"Caches","text":"<p>There is an agent_authz cache used for optimisations are: The cache is a name-value store (leveldb) and offers a constant lookup time for lookup by name. 1. Policy values: The authorization of each agent per policy. The values for the keys are rlp encoding of the list of at most 2 items, <code>authorization bitset</code> with each bit respresenting a different auth, <code>commitment</code> is optional and relevant only when agent has the <code>PROVE</code> authorization.</p> <p><pre><code>{\n  &lt;policy address 1&gt;&lt;delimiter&gt;&lt;agent verkey 1&gt;: &lt;authorization bitset&gt;:&lt;commitment&gt;,\n  &lt;policy address 1&gt;&lt;delimiter&gt;&lt;agent verkey 2&gt;: &lt;authorization bitset&gt;:&lt;commitment&gt;,\n  &lt;policy address 1&gt;&lt;delimiter&gt;&lt;agent verkey 3&gt;: &lt;authorization bitset&gt;:&lt;commitment&gt;,\n  &lt;policy address 2&gt;&lt;delimiter&gt;&lt;agent verkey 1&gt;: &lt;authorization bitset&gt;:&lt;commitment&gt;,\n  &lt;policy address 2&gt;&lt;delimiter&gt;&lt;agent verkey 2&gt;: &lt;authorization bitset&gt;:&lt;commitment&gt;,\n  ....\n}\n</code></pre> These names are used by the nodes during processing any transaction.</p> <ol> <li>Accumulator value: Value of each accumulator is stored corresponding to the special byte indicating the global accumulator. <pre><code>{\n  &lt;special_byte&gt;: &lt;accumulator value&gt;,\n}\n</code></pre></li> </ol> <p>During processing of any write transaction, the node updates the ledger, state and caches after the txn is successful but for querying (client as well as its own like validation, etc) it only uses caches since caches are more efficient than state trie. The state trie is only used for state proofs.  </p> <ol> <li>TODO: Maintaining a set of commitments: Each node maintains a set of see commitments and does not allow duplicate commitments. Its kept in key value store with constant lookup time for commitment lookup.</li> </ol>"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#code-organisation","title":"Code organisation.","text":"<p>These changes would be implemented as a separate plugin. The plugin will not introduce new ledger or state but will introduce the cache described above. The plugin will introduce a new request handler which will subclass the <code>DomainRequestHandler</code>. The plugin's new request handler will introduce 1 <code>write_type</code> and 2 <code>query_types</code> and methods to handle those.</p>"},{"location":"concepts/0051-dkms/dkms-v4/","title":"DKMS (Decentralized Key Management System) Design and Architecture V4","text":"<p>2019-03-29</p> <p>Authors: Drummond Reed, Jason Law, Daniel Hardman, Mike Lodder</p> <p>Contributors: Christopher Allen, Devin Fisher, Nathan George, Lovesh Harchandani, Dmitry Khovratovich, Corin Kochenower, Brent Zundel, Nathan George</p> <p>Advisors: Stephen Wilson</p> <p>STATUS: This design and architecture for a decentralized key management system (DKMS) has been developed by Evernym Inc. under a contract with the U.S. Department of Homeland Security Science &amp; Technology Directorate. This fourth draft is being released on 29 Mar 2019 to begin an open public review and comment process in preparation for DKMS to be submitted to a standards development organization such as OASIS for formal standardization.</p> <p>Acknowledgements: </p> <ul> <li> <p>Work on DKMS Design and Architecture has been funded in part by a Small Business Innovation Research (SBIR) grant from the U.S. Department of Homeland Security Science and Technology Directorate. The content of this specification does not necessarily reflect the position or the policy of the U.S. Government and no official endorsement should be inferred.</p> </li> <li> <p>The Internet Security Research Lab at Brigham Young University gathered feedback on decentralized key management and recovery from user surveys and UX usability studies. They also provided feedback on earlier drafts of this document. Contributions were made by Kent Seamons (faculty), Daniel Zappala (faculty), Ken Reese, Brad Spendlove, Trevor Smith, and Luke Dickinson.</p> </li> </ul> <p>Table of Contents</p> <ol> <li>Introduction</li> <li>Design Goals and Requirements</li> <li>High Level Architecture</li> <li>Ledger Architecture</li> <li>Key Management Architecture</li> <li>Recovery Methods</li> <li>Recovery From Key Loss</li> <li>Recovery From Key Compromise</li> <li>DKMS Protocol</li> <li>Protocol Flows</li> <li>Open Issues and Future Work</li> <li>Future Standardization</li> </ol>"},{"location":"concepts/0051-dkms/dkms-v4/#1-introduction","title":"1. Introduction","text":""},{"location":"concepts/0051-dkms/dkms-v4/#11-overview","title":"1.1. Overview","text":"<p>DKMS (Decentralized Key Management System) is a new approach to cryptographic key management intended for use with blockchain and distributed ledger technologies (DLTs) where there are no centralized authorities. DKMS inverts a core assumption of conventional PKI (public key infrastructure) architecture, namely that public key certificates will be issued by centralized or federated certificate authorities (CAs). With DKMS, the initial \"root of trust\" for all participants is any distributed ledger or decentralized protocol that supports a new form of root identity record called a DID (decentralized identifier).</p> <p>A DID is a globally unique identifier that is generated cryptographically and self-registered with the identity owner\u2019s choice of a DID-compatible distributed ledger or decentralized protocol so no central registration authority is required. Each DID points to a DID document\u2014a JSON or JSON-LD object containing the associated public verification key(s) and addresses of services such as off-ledger agent(s) supporting secure peer-to-peer interactions with the identity owner. For more on DIDs, see the DID Primer. For more on peer-to-peer interactions, see the DID Communication explainer.</p> <p>Since no third party is involved in the initial registration of a DID and DID document, it begins as \"trustless\". From this starting point, trust between DID-identified peers can be built up through the exchange of verifiable credentials\u2014credentials about identity attributes that include cryptographic proof of authenticity of authorship. These proofs can be verified by reference to the issuer\u2019s DID and DID document. For more about verifiable credentials, see the  Verifiable Credentials Primer. </p> <p>This decentralized web of trust model leverages the security, immutability, availability, and resiliency properties of distributed ledgers to provide highly scalable key distribution, verification, and recovery. This inversion of conventional public key infrastructure (PKI) into decentralized PKI (DPKI) removes centralized gatekeepers, making the benefits of PKI accessible to everyone. However this lack of centralized authorities for DKMS shifts the majority of responsibility for key management directly to participating identity owners. This demands the decentralized equivalent of the centralized cryptographic key management systems (CKMS) that are the current best practice in most enterprises. The purpose of this document is to specify a design and architecture that fulfills this market need.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#12-market-need","title":"1.2. Market Need","text":"<p>X.509 public key certificates, as used in the TLS/SSL protocol for HTTPS secure Web browsing, have become the most widely adopted PKI in the world. However this system requires that all certificates be obtained from a relatively small list of trusted authorities\u2014and that any changes to these certificates also be approved by someone in this chain of trust.</p> <p>This creates political and structural barriers to establishing and updating authoritative data. This friction is great enough that only a small fraction of Internet users are currently in position to use public/private key cryptography for their own identity, security, privacy, and trust management. This inability for people and organizations to interact privately as independent, verifiable peers on their own terms has many consequences:</p> <ol> <li> <p>It forces individuals and smaller organizations to rely on large federated identity providers and certificate authorities who are in a position to dictate security, privacy and business policies.</p> </li> <li> <p>It restricts the number of ways in which peers can discover each other and build new trust relationships\u2014which in turn limits the health and resiliency of the digital economy.</p> </li> <li> <p>It discourages the use of modern cryptography for increased security and privacy, weakening our cybersecurity infrastructure.</p> </li> </ol> <p>Decentralized technologies such as distributed ledgers and edge protocols can remove these barriers and make it much easier to share and verify public keys. This enables each entity to manage its own authoritative key material without requiring approval from other parties. Furthermore, those changes can be seen immediately by the entity\u2019s peers without requiring them to change their software or \"certificate store\".</p> <p>Maturing DLTs and protocols will bring DPKI into the mainstream\u2014a combination of DIDs for decentralized identification and DKMS for decentralized key management. DPKI will provide a simple, secure, way to generate strong public/private key pairs, register them for easy discovery and verification, and rotate and retire them as needed to maintain strong security and privacy.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#13-benefits","title":"1.3. Benefits","text":"<p>DKMS architecture and DPKI provides the following major benefits:</p> <ol> <li> <p>No single point of failure. With DKMS, there is no central CA or other registration authority whose failure can jeopardize large swaths of users.</p> </li> <li> <p>Interoperability. DKMS will enable any two identity owners and their applications to perform key exchange and create encrypted P2P connections without reliance on proprietary software, service providers, or federations.</p> </li> <li> <p>Portability. DKMS will enable identity owners to avoid being locked into any specific implementation of a DKMS-compatible wallet, agent, or agency. Identity owners should\u2014with the appropriate security safeguards\u2014be able to use the DKMS protocol itself to move the contents of their wallet (though not necessarily the actual cryptographic keys) between compliant DKMS implementations.</p> </li> <li> <p>Resilient trust infrastructure. DKMS incorporates all the advantages of distributed ledger technology for decentralized access to cryptographically verifiable data. It then adds on top of it a distributed web of trust where any peer can exchange keys, form connections, and issue/accept verifiable credentials from any other peer.</p> </li> <li> <p>Key recovery. Rather than app-specific or domain-specific key recovery solutions, DKMS can build robust key recovery directly into the infrastructure, including agent-automated encrypted backup, DKMS key escrow services, and social recovery of keys, for example by backing up or sharding keys across trusted DKMS connections and agents.</p> </li> </ol>"},{"location":"concepts/0051-dkms/dkms-v4/#2-design-goals-and-requirements","title":"2. Design Goals and Requirements","text":""},{"location":"concepts/0051-dkms/dkms-v4/#21-conventional-ckms-requirements-nist-800-130-analysis","title":"2.1. Conventional CKMS Requirements: NIST 800-130 Analysis","text":"<p>As a general rule, DKMS requirements are a derivation of CKMS requirements, adjusted for the lack of centralized authorities or systems for key management operations. Evernym\u2019s DKMS team and subcontractors performed an extensive analysis of the applicability of conventional CKMS requirements to DKMS using  NIST Special Publication 800-130: A Framework for Designing Cryptographic Key Management Systems. For a summary of the results, see:</p> <ul> <li> <p>Evernym HSHQDC-17-C-00018 - DKMS Requirements Spreadsheet Based On NIST 800-130</p> </li> <li> <p>Evernym HSHQDC-17-C-00018 - DKMS Requirements Text Based on NIST 800-130</p> </li> <li> <p>Evernym HSHQDC-17-C-00018 - DKMS Requirements Report - 30 June 2017</p> </li> </ul> <p>The most relevant special requirements are highlighted in the following sections.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#22-decentralization","title":"2.2. Decentralization","text":"<p>The DKMS design MUST NOT assume any reliance on a centralized authority for the system as a whole. The DKMS design MUST assume all participants are independent actors identified with DIDs conformant with the Decentralized Identifiers (DID) specification but otherwise acting in their own decentralized security and privacy domains. The DKMS design MUST support options for decentralized key recovery.</p> <p>What distinguishes DKMS from conventional CKMS is the fact that the entire design assumes decentralization: outside of the \"meta-policies\" established by the DKMS specification itself, there is no central authority to dictate policies that apply to all users. So global DKMS infrastructure must achieve interoperability organically based on a shared set of specifications, just like the Internet.</p> <p>Note that the need to maintain decentralization is most acute when it comes to key recovery: the advantages of decentralization are nullified if key recovery mechanisms reintroduce centralization.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#23-privacy-and-pseudonymity","title":"2.3. Privacy and Pseudonymity","text":"<p>The DKMS design MUST NOT introduce new means of correlating participants by virtue of using the DKMS standards. The DKMS design SHOULD increase privacy and security by enabling the use of pseudonyms, selective disclosure, and encrypted private channels of communication.</p> <p>Conventional PKI and CKMS rarely have anti-correlation as a primary requirement. DKMS should ensure that participants will have more, not less, control over their privacy as well as their security. This facet of DKMS requires an vigilant application of all the principles of Privacy by Design.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#24-usability","title":"2.4. Usability","text":"<p>DIDs and DKMS components intended to be used by individual identity owners MUST be safely usable without any special training or knowledge of cryptography or key management.</p> <p>In many ways this follows from decentralization: in a DKMS, there is no central authority to teach everyone how to use it or require specific user training. It must be automated and intuitive to a very high degree, similar to the usability achieved by modern encrypted OTT messaging products like Whatsapp, iMessage, and Signal.</p> <p>According to the BYU Internet Security Research Lab, this level of usability is a necessary property of any successfully deployed system. \"We spent the 1990s building and deploying security that wasn\u2019t really needed, and now that it\u2019s actually desirable, we\u2019re finding that nobody can use it\" [Guttman and Grigg, IEEE Security and Privacy, 2005]. The DKMS needs to be able to support a broad spectrum of applications, with both manual and automatic key management, in order to satisfy the numerous security and usability requirements of those applications.</p> <p>Again, this requirement is particularly acute when it comes to key recovery. Because there is no central authority to fall back on, the key recovery options must not only be anticipated and implemented in advance, but they must be easy enough for a non-technical user to employ while still preventing exploitation by an attacker.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#25-automation","title":"2.5. Automation","text":"<p>To maximize usability, the DKMS design SHOULD automate as many key management functions as possible while still meeting security and privacy requirements.</p> <p>This design principle follows directly from the usability requirement, and also from the inherent complexity of maintaining the security, privacy, and integrity of cryptographic primitives combined with the general lack of knowledge of most Internet users about any of these subjects.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#26-key-derivation","title":"2.6. Key Derivation","text":"<p>In DKMS design it is NOT RECOMMENDED to copy private keys directly between wallets, even over encrypted connections. It is RECOMMENDED to use derived keys whenever possible to enable agent-specific and device-specific revocation.</p> <p>This design principle is based on security best practices, and also the growing industry experience with the BIP32 standard for management of the large numbers of private keys required by Bitcoin and other cryptocurrencies. However DKMS architecture can also accomplish this goal in other ways, such as using key signing keys (\"key endorsement\").</p>"},{"location":"concepts/0051-dkms/dkms-v4/#27-delegation-and-guardianship","title":"2.7. Delegation and Guardianship","text":"<p>The DKMS design MUST enable key management to be delegated by one identity owner to another, including the DID concept of delegation.</p> <p>Although DKMS infrastructure enables \"self-sovereign identity\"\u2014digital identifiers and identity wallets that are completely under the control of an identity owner and cannot be taken away by a third-party\u2014not all individuals have the ability to be self-sovereign. They may be operating at a physical, economic, or network disadvantage that requires another identity owner (individual or org) to act as an agent on their behalf. </p> <p>Other identity owners may simply prefer to have others manage their keys for purposes of convenience, efficiency, or safety. In either case, this means DKMS architecture needs to incorporate the concept of delegation as defined in the Decentralized Identifiers (DID) specification and in the Sovrin Glossary.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#28-portability","title":"2.8. Portability","text":"<p>The DKMS design MUST enable an identity owner\u2019s DKMS-compliant key management capabilities to be portable across multiple DKMS-compliant devices, applications, and service providers.</p> <p>While the NIST 800-130 specifications have an entire section on interoperability, those requirements are focused primarily on interoperability of CKMS components with each other and with external CKMS systems. They do not encompass the need for a decentralized identity owner to be able to port their key management capabilities from one CKMS device, application, or service provider to another.</p> <p>This is the DID and DKMS equivalent of telephone number portability, and it is critical not only for the general acceptance of DKMS infrastructure, but to support the ability of DID owners to act with full autonomy and independence. As with telephone number portability, it also helps ensure a robust and competitive marketplace for DKMS-compliant products and services. (NOTE:  Note that \"portability\" here refers to the ability of a DID owner to use the same DID across multiple devices, software applications, service providers, etc. It does not mean that a particular DID that uses a particular DID method is portable across different distributed ledgers. DID methods are ledger-specific.)</p>"},{"location":"concepts/0051-dkms/dkms-v4/#29-extensibility","title":"2.9. Extensibility","text":"<p>The DKMS design SHOULD be capable of being extended to support new cryptographic algorithms, keys, data structures, and modules, as well as new distributed ledger technologies and other security and privacy innovations.</p> <p>Section 7 of NIST 800-130 includes several requirements for conventional CKMS to be able to transition to newer and stronger cryptographic algorithms, but it does not go as far as is required for DKMS infrastructure, which must be capable of adapting to evolving Internet security and privacy infrastructure as well as rapid advances in distributed ledger technologies.</p> <p>It is worth noting that the DKMS specifications will not themselves include a trust framework (also called a governance framework; rather, one or more trust frameworks can be layered over them to formalize certain types of extensions. This provides a flexible and adaptable method of extending DKMS to meet the needs of specific communities.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#210-simplicity","title":"2.10. Simplicity","text":"<p>Given the inherent complexity of key management, the DKMS design SHOULD aim to be as simple and interoperable as possible by pushing complexity to the edges and to extensions.</p> <p>Simplicity and elegance of design are common traits of most successful decentralized systems, starting with the packet-based design of the Internet itself. The less complex a system is, the easier it is to debug, evaluate, and adapt to future changes. Especially in light of the highly comprehensive scope of NIST 800-130, this requirement highlights a core difference with conventional CKMS design: the DKMS specification should NOT try to do everything, e.g., enumerate every possible type of key or role of user or application, but let those be defined locally in a way that is interoperable with the rest of the system.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#211-open-system-and-open-standard","title":"2.11. Open System and Open Standard","text":"<p>The DKMS design MUST be an open system based on open, royalty-free standards.</p> <p>While many CKMS systems are deployed using proprietary technology, the baseline DKMS infrastructure must, like the Internet itself, be an open, royalty-free system. It may, of course, have many proprietary extensions and solutions built on top of it.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#3-high-level-architecture","title":"3. High-Level Architecture","text":"<p>At a high level, DKMS architecture consists of three logical layers:</p> <ol> <li> <p>The DID layer is the foundational layer consisting of DIDs registered and resolved via distributed ledgers and/or decentralized protocols.</p> </li> <li> <p>The cloud layer consists of server-side agents and wallets that provide a means of communicating and mediating between the DID layer and the edge layer. This layer enables encrypted peer-to-peer communications for exchange and verification of DIDs, public keys, and verifiable credentials.</p> </li> <li> <p>The edge layer consists of the local devices, agents, and wallets used directly by identity owners to generate and store most private keys and perform most key management operations.</p> </li> </ol> <p>Figure 1 is an overview of this three-layer architecture:</p> <p></p> <p>Figure 1: The high-level three-layer DKMS architecture</p> <p>Figure 2 is a more detailed picture of the relationship between the different types of agents and wallets in DKMS architecture.</p> <p></p> <p>Figure 2: Diagram of the types of agents and connections in DKMS architecture.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#31-the-did-decentralized-identifier-layer","title":"3.1. The DID (Decentralized Identifier) Layer","text":"<p>The foundation for DKMS is laid by the DID specification. DIDs can work with any decentralized source of truth such as a distributed ledger or edge protocol for which a DID method\u2014a way of creating, reading, updating, and revoking a DID\u2014has been specified. As globally unique identifiers, DIDs are patterned after URNs (Uniform Resource Names): colon-delimited strings consisting of a scheme name followed by a DID method name followed by a method-specific identifier. Here is an example DID that uses the Sovrin DID method:</p> <p>did:sov:21tDAKCERh95uGgKbJNHYp</p> <p>Each DID method specification defines:</p> <ol> <li> <p>The specific source of truth against which the DID method operates;</p> </li> <li> <p>The format of the method-specific identifier;</p> </li> <li> <p>The CRUD operations (create, read, update, delete) for DIDs and DID documents on that ledger.</p> </li> </ol> <p>DID resolver code can then be written to perform these CRUD operations on the target system with respect to any DID conforming to that DID method specification. Note that some distributed ledger technologies (DLTs) and distributed networks are better suited to DIDs than others. The DID specification itself is neutral with regard to DLTs; it is anticipated that those DLTs that are best suited for the purpose of DIDs will see the highest adoption rates.there will be Darwinian selection of the DLTs that are best fit for the purpose of DIDs.</p> <p>From a digital identity perspective, the primary problem that DIDs and DID documents solve is the need for a universally available, decentralized root of trust that any application or system can rely upon to discover and verify credentials about the DID subject. Such a solution enables us to move \"beyond federation\" into a world where any peer can enter into trusted interactions with any other peer, just as the Internet enabled any two peers to connect and communicate.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#32-the-cloud-layer-cloud-agents-and-cloud-wallets","title":"3.2. The Cloud Layer: Cloud Agents and Cloud Wallets","text":"<p>While the DID specification covers the bottom layer of a decentralized public key infrastructure, the DKMS spec will concentrate on the two layers above it. The first of these, the cloud layer, is the server-side infrastructure that mediates between the ultimate peers\u2014the edge devices used directly by identity owners\u2014and the DID layer.</p> <p>While not strictly necessary from a pure logical point-of-view, in practice this server-side DKMS layer plays a similar role in DID infrastructure as email servers play in SMTP email infrastructure or Web servers play in Web infrastructure. Like email or Web servers, cloud agents and cloud wallets are designed to be available 24 x 7 to send and receive communications on behalf of their identity owners. They are also designed to perform communications, encryption, key management, data management, and data storage and backup processes that are not typically feasible for edge devices given their typical computational power, bandwidth, storage capacity, reliability and/or availability.</p> <p>Cloud agents and wallets will typically be hosted by a service provider called an agency. Agencies could be operated by any type of service provider\u2014ISPs, telcos, search engines, social networks, banks, utility companies, governments, etc. A third party agency is not a requirement of DKMS architecture\u2014any identity owner can also host their own cloud agents.</p> <p>From an architectural standpoint, it is critical that the cloud layer be designed so that it does not \"recentralize\" any aspect of DKMS. In other words, even if an identity owner chooses to use a specific DKMS service provider for a specific set of cloud agent functions, the identity owner should be able to substitute another DKMS service provider at a later date and retain complete portability of her DKMS keys, data and metadata.</p> <p>Another feature of the cloud layer is that cloud agents can use DIDs and DID documents to automatically negotiate mutually authenticated secure connections with each other using DID Communication, a protocol being designed for this purpose.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#33-the-edge-layer-edge-agents-and-edge-wallets","title":"3.3. The Edge Layer: Edge Agents and Edge Wallets","text":"<p>The edge layer is vital to DKMS because it is where identity owners interact directly with computing devices, operating systems, and applications. This layer consists of DKMS edge agents and edge wallets that are under the direct control of identity owners. When designed and implemented correctly, edge devices, agents, and wallets can also be the safest place to store private keys and other cryptographic material. They are the least accessible for network intrusion, and even a successful attack on any single client device would yield the private data for only a single user or at most a small family of users.</p> <p>Therefore, the edge layer is where most DKMS private keys and link secrets are generated and where most key operations and storage are performed. To meet the security and privacy requirements, DKMS architecture makes the following two assumptions:</p> <ol> <li> <p>A DKMS agent is always installed in an environment that includes a secure element or Trusted Platform Module (for simplicity, this document will use the term \"secure element\" or \u201cSE\u201d for this module).</p> </li> <li> <p>Private keys used by the agent never leave the secure element. </p> </li> </ol> <p>By default edge agents are always paired with a corresponding cloud agent due to the many DKMS operations that a cloud agent enables, including communications via the DKMS protocol to other edge and cloud agents. However this is not strictly necessary. As shown in Figure 1, edge agents could also communicate directly, peer-to-peer, via a protocol such as Bluetooth, NFC, or another mesh network protocol. Edge agents may also establish secure connections with cloud agents or with others using DID Communication.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#34-verifiable-credentials","title":"3.4. Verifiable Credentials","text":"<p>By themselves, DIDs are \"trustless\", i.e., they carry no more inherent trust than an IP address. The primary difference is that they provide a mechanism for resolving the DID to a DID document containing the necessary cryptographic keys and endpoints to bootstrap secure communications with the associated agent.</p> <p>To achieve a higher level of trust, DKMS agents may exchange digitally signed credentials called verifiable credentials. Verifiable credentials are being standardized by the W3C Working Group of the same name. The purpose is summarized in the charter:</p> <p>It is currently difficult to express banking account information, education qualifications, healthcare data, and other sorts of machine-readable personal information that has been verified by a 3<sup>rd</sup> party on the Web. These sorts of data are often referred to as verifiable credentials. The mission of the Verifiable Credentials Working Group is to make expressing, exchanging, and verifying credentials easier and more secure on the Web.</p> <p>The following diagram from the W3C Verifiable Claims Working Group illustrates the primary roles in the verifiable credential ecosystem and the close relationship between DIDs and verifiable credentials.</p> <p></p> <p>Figure 3: The W3C Verifiable Credentials ecosystem</p> <p>Note that what is being verified in a verifiable credential is the signature of the credential issuer. The strength of the actual credential depends on the degree of trust the verifier has in the issuer. For example, if a bank issues a credential saying that the subject of the credential has a certain credit card number, a merchant can rely on the credential if the merchant has a high degree of trust in the bank.</p> <p>The Verifiable Claims Working Group is standardizing both the format of credentials and of digital signatures on the credentials. Different digital signature formats require different cryptographic key material. For example, credentials that use a zero-knowledge signature format such as Camenisch-Lysyanskaya (CL) signatures require a \"master secret\" or \u201clink secret\u201d that enables the prover (the identity owner) to make proofs about the credential without revealing the underlying data or signatures in the credential (or the prover's DID with respect to the credential issuer). This allows for \"credential presentations\" that are unlinkable to each other. Link secrets are another type of cryptographic key material that must be stored in DKMS wallets.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#4-ledger-architecture","title":"4. Ledger Architecture","text":"<p>A fundamental feature of DIDs and DKMS is that they will work with any modern blockchain, distributed ledger, distributed database, or distributed file system capable of supporting a DID method (which has a relatively simple set of requirements\u2014see the DID specification). For simplicity, this document will refer to all of these systems as \"ledgers\".</p> <p>There are a variety of ledger designs and governance models as illustrated in Figure 4. </p> <p></p> <p>Figure 4: Blockchain and distributed ledger governance models</p> <p>Public ledgers are available for anyone to access, while private ledgers have restricted access. Permissionless ledgers allow anyone to run a validator node of the ledger (a node that participates in the consensus protocol), and thus require proof-of-work, proof-of-stake, or other protections against Sybil attacks. Permissioned ledgers restrict who can run a validator node, and thus can typically operate at a higher transaction rate.</p> <p>For decentralized identity management, a core requirement of DIDs and DKMS is that they can interoperate with any of these ledgers. However for privacy and scalability reasons, certain types of ledgers play specific roles in DKMS architecture.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#41-public-ledgers","title":"4.1. Public Ledgers","text":"<p>Public ledgers, whether permissionless or permissioned, are crucial to DKMS infrastructure because they provide an open global root of trust. To the extent that a particular public ledger has earned the public\u2019s trust that it is strong enough to withstand attacks, tampering, or censorship, it is in a position to serve as a strong, universally-available root of trust for DIDs and the DID documents necessary for decentralized key management.</p> <p>Such a publicly available root of trust is particularly important for:</p> <ol> <li> <p>Public DIDs (also called \"anywise DIDs\") that need to be recognized as trust anchors by a large number of verifiers.</p> </li> <li> <p>Schema and credential definitions needed for broad semantic interoperability of verifiable credentials.</p> </li> <li> <p>Revocation registries needed for revocation of verifiable credentials that use proofs.</p> </li> <li> <p>Policy registries needed for authorization and revocation of DKMS agents (see section 9.2).</p> </li> <li> <p>Anchoring transactions posted for verification or coordination purposes by smart contracts or other ledgers, including microledgers (below).</p> </li> </ol>"},{"location":"concepts/0051-dkms/dkms-v4/#42-private-ledgers","title":"4.2. Private Ledgers","text":"<p>Although public ledgers may also be used for private DIDs\u2014DIDs that are intended for use only by a restricted audience\u2014this requires that their DID documents be carefully provisioned and managed to avoid any information that can be used for attack or correlation. This threat is lessened if private DIDs are registered and managed on a private ledger that has restricted access. However the larger the ledger, the more it will require the same precautions as a public ledger.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#43-microledgers","title":"4.3. Microledgers","text":"<p>From a privacy perspective\u2014and particularly for compliance with privacy regulations such as the EU General Data Protection Regulation (GDPR)\u2014the ideal identifier is a pairwise pseudonymous DID. This DID (and its corresponding DID document) is only known to the two parties in a relationship.</p> <p>Because pairwise pseudonymous DID documents contain the public keys and service endpoints necessary for the respective DKMS agents to connect and send encrypted, signed messages to each other, there is no need for pairwise pseudonymous DIDs to be registered on a public ledger or even a conventional private ledger. Rather they can use microledgers. </p> <p>A microledger is essentially identical to a conventional private ledger except it has only as many nodes as it has parties to the relationship. The same cryptographic steps are used:</p> <ol> <li> <p>Transactions are digitally signed by authorized private key(s).</p> </li> <li> <p>Transactions are cryptographically ordered and tamper evident.</p> </li> <li> <p>Transactions are replicated efficiently across agents using simple consensus protocols. These protocol, and the microledgers that provide their persistent state, constitute a root of trust for the relationship.</p> </li> </ol> <p>Microledgers are effectively permissionless because anyone can operate one in cooperation with anyone else\u2014only the parties to the microledger relationship need to agree. If there is a danger of the parties to the microledger getting \"out of sync\" (e.g., if an attacker has compromised one party's agents such that the party's state is deadlocked, or one party's agents have all been lost so that the party is unable to receive a change-of-state from the other), the party\u2019s agents can register a dead drop point. This is a pre-established endpoint and keys both parties can use to re-sync their microledgers and restore their connection.</p> <p>Microledgers play a special role in DKMS architecture because they are used to maintain pairwise pseudonymous connections between DKMS agents. The use of microledgers also helps enormously with the problems of scale\u2014they can significantly reduce the load on public ledgers by moving management of pairwise pseudonymous DIDs and DID documents directly to DKMS agents.</p> <p>The protocols associated with microledgers include:</p> <ul> <li>A protocol to formally connect two parties and exchange DID Documents.</li> <li>A protocol to update and synchronize DID Documents.</li> <li>A protocol to query DID Documents.</li> </ul> <p>Today, the only known example of this approach is the <code>did:peer</code> method. It is possible that alternative implementations will emerge.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#5-key-management-architecture","title":"5. Key Management Architecture","text":"<p>DKMS adheres to the principle of key separation where keys for different purposes should be cryptographically separated. This avoids use of the same key for multiple purposes. Keys are classified based on usage and the nature of information being protected. Any change to a key requires that the relevant DID method ensure that the change comes from the identity owner or her authorized delegate. All requests by unauthorized entities must be ignored or flagged by the DKMS agent. If anyone else can change any key material, the security of the system is compromised. </p> <p>DKMS architecture addresses what keys are needed, how they are used, where they should be stored and protected, how long they should live, and how they are revoked and/or recovered when lost or compromised.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#51-key-types-and-key-descriptions","title":"5.1. Key Types and Key Descriptions","text":"<p>NIST 800-130 framework requirement 6.1 requires a CKMS to specify and define each key type used. The following key layering and policies can be applied.</p> <ol> <li> <p>Master keys:             </p> <ol> <li> <p>Keys at the highest level, in that they themselves are not cryptographically protected. They are distributed manually or initially installed and protected by procedural controls and physical or electronic isolation.</p> </li> <li> <p>MAY be used for deriving other keys;</p> </li> <li> <p>MUST NOT ever be stored in cleartext.</p> </li> <li> <p>SHOULD never be stored in a single encrypted form, but only:</p> <ol> <li> <p>Saved in secure offline storage;</p> </li> <li> <p>Secured by high secure encrypted vaults, such as a secure element, TPM, or TEE.</p> </li> <li> <p>Distributed using a technique such as Shamir secret sharing;</p> </li> <li> <p>Derived from secure multiparty computation.</p> </li> <li> <p>Saved somewhere that requires secure interactions to access (which could mean slower retrieval times).</p> </li> </ol> </li> <li> <p>SHOULD be used only for creating signatures as proof of delegation for other keys.</p> </li> <li> <p>MUST be forgotten immediately after use\u2013securely erased from memory, disk, and every location that accessed the key in plain text. </p> </li> </ol> </li> <li> <p>Key encrypting keys              </p> <ol> <li> <p>Symmetric or public keys used for key transport or storage of other keys.</p> </li> <li> <p>MAY themselves be secured under other keys.</p> </li> <li> <p>If they are not ephemeral, they SHOULD be stored in secure access-controlled devices, used in those devices and never exposed.</p> </li> </ol> </li> <li> <p>Data keys    </p> <ol> <li> <p>Used to provide cryptographic operations on user data (e.g., encryption, authentication). These are generally short-term symmetric keys; however, asymmetric signature private keys may also be considered data keys, and these are usually longer-term keys.</p> </li> <li> <p>SHOULD be dedicated to specific roles, such as authentication, securing communications, protecting storage, proving authorized delegation, constructing credentials, or generating proofs.</p> </li> </ol> </li> </ol> <p>The keys at one layer are used to protect items at a lower level. This constraint is intended to make attacks more difficult, and to limit exposure resulting from compromise of a specific key. For example, compromise of a key-encrypting-key (of which a master key is a special case) affects all keys protected thereunder. Consequently, special measures are used to protect master keys, including severely limiting access and use, hardware protection, and providing access to the key only under shared control.   </p> <p>In addition to key layering hierarchy, keys may be classified based on temporal considerations: </p> <ol> <li> <p>Long-term keys. These include master keys, often key-encrypting keys, and keys used to facilitate key agreement.   </p> </li> <li> <p>Short-term keys. These include keys established by key transport or key agreement, often used as data keys or session keys for a single communications session.</p> </li> </ol> <p>In general, communications applications involve short-term keys, while data storage applications require longer-term keys. Long-term keys typically protect short-term keys. </p> <p>The following policies apply to key descriptions:</p> <ol> <li> <p>Any DKMS-compliant key SHOULD use a DID-compliant key description.</p> </li> <li> <p>This key description MUST be published at least in the governing DID method specification.</p> </li> <li> <p>This key description SHOULD be aggregated in the Key Description Registry maintained by the W3C Credentials Community Group.</p> </li> </ol> <p>DKMS key management must encompass the keys needed by different DID methods as well as different verifiable credentials exchange protocols and signature formats. The following list includes the initial key types required by the Sovrin DID Method Spec and the Sovrin protocol for verifiable credentials exchange:</p> <ol> <li> <p>Link secret: (one per entity) A high-entropy 256-bit integer included in every credential in blinded form. Used for proving credentials were issued to the same logical identity. A logical identity only has one link secret. The first DKMS agent provisioned by an identity owner creates this value and stores it in an encrypted wallet or in a secure element if available. Agents that receive credentials and present proofs must know this value. It can be transferred over secure channels between agents as necessary. If the link secret is changed, credentials issued with the new link secret value cannot be correlated with credentials using the old link secret value.</p> </li> <li> <p>DID keys: (one per relationship per agent) Ed25519 keys used for non-repudiation signing and verification for DIDs. Each agent manages their own set of DID keys.</p> </li> <li> <p>Agent policy keys: (one per agent) Ed25519 key pairs used with the agent policy registry. See section 9.2. The public key is stored with the agent policy registry. Transactions made to the policy registry are signed by the private key. The keys are used in zero-knowledge during proof presentation to show the agent is authorized by the identity owner to present the proof. Unauthorized agents MUST NOT be trusted by verifiers.</p> </li> <li> <p>Agent recovery keys: (a fraction per trustee) Ed25519 keys. A public key is stored by the agent and used for encrypting backups. The private key is saved to an offline medium or split into shares and given to trustees. To encrypt a backup, an ephemeral X25519 key pair is created where the ephemeral private key is used to perform a Diffie-Hellman agreement with the public recovery key to create a wallet encryption key. The private ephemeral key is forgotten and the ephemeral public key is stored with the encrypted wallet backup. To decrypt a backup, the private recovery key performs a Diffie-Hellman agreement with the ephemeral public key to create the same wallet encryption key.</p> </li> <li> <p>Wallet encryption keys: (one per wallet segment) 256 bit symmetric keys for encrypting wallets and backups. The key is generated by an agent then wrapped using secure enclaves (preferred) or derived from user inputs like strong passwords (see section 5.2). It MUST NOT be stored directly in secure enclaves when portability is a requirement.</p> </li> <li> <p>Wallet permission keys: (one per permission) Symmetric keys or Ed25519 keypairs that allow fine-grained permissions over various data stored in the wallet i.e. wallet read-only access, credential group write access, or write all access.</p> </li> </ol>"},{"location":"concepts/0051-dkms/dkms-v4/#52-key-generation","title":"5.2. Key Generation","text":"<p>NIST 800-130 framework requirement 6.19 requires that a CKMS design shall specify the key-generation methods to be used in the CKMS for each type of key. The following policies can be applied.</p> <ol> <li> <p>For any key represented in a DID document, the generation method MUST be included in the key description specification.</p> </li> <li> <p>Any parameters necessary to understand the generated key MUST be included in the key description.</p> </li> <li> <p>The key description SHOULD NOT include any metadata that enables correlation across key pairs.</p> </li> <li> <p>DKMS key types SHOULD use derivation functions that simplify and standardize key recovery. </p> </li> </ol> <p>A secure method for key creation is to use a seed value combined with a derivation algorithm. Key derivation functions (KDF), pseudo random number generators (PRNG), and Bitcoin\u2019s BIP32 standard for hierarchical deterministic (HD) keys are all examples of key creation using a seed value with a derivation function or mapping.</p> <p>Hardware based key generation (like HSMs or TPMS) is usually more secure as they are typically designed to include more factors like white noise and temperature which are harder to corrupt.</p> <p>If KDFs or PRNGs are used, a passphrase, biometric input, or social data from multiple users combined with random salt SHOULD be used as the input to create the seed. Alternately a QR code or words from a list such as the PGP word list can be used. In either case, the input MUST NOT be stored anywhere connected to the Internet.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#53-multi-device-management","title":"5.3. Multi-Device Management","text":"<p>Each device hosts an edge agent and edge wallet. All keys except for the link secret are unique per device. This allows for fine-grained (e.g., per relationship) control of authorized devices, as well as remote revocation. As part of the process for provisioning an edge agent, owners must choose what capabilities to grant. Capabilities must be flexible so owners can add or remove them depending on their needs.</p> <p>Wallet permissions SHOULD be controlled using keys that grant fixed permissions. One example of such a system is Cryptree.</p> <p>It is recommended that private keys never be reused across agents. If a secret is shared across agents, then there must be a way to remotely revoke the agent using a distributed ledger such that the secret is rendered useless on that agent. The DKMS architecture uses ledgers and diffused trust to enable fine grained control over individual keys and entire devices. An agent policy registry located on a ledger allows an owner to define agent authorizations and control over those authorizations. (See 9.2 Policy Registries). Agents must notify each other when a new agent is added to an authorized pool or removed in order to warn identity owners of unauthorized or malicious agents with a cloud agent acting as the synchronization hub.</p> <p>Techniques like distributed hash tables or gossip protocols SHOULD be employed to keep device data synchronized.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#54-key-portability-and-migration","title":"5.4. Key Portability and Migration","text":"<p>As mentioned in section 2.8, portability of DKMS wallets and keys is an important requirement\u2014if agencies or other service providers could \"lock-in\" identity owners, DIDs and DKMS would no longer be decentralized. Thus the DKMS protocol MUST support identity owners migrating their edge agents and cloud agents to the agency of their choice (including self-hosting). Agency-to-agency migration is not fully defined in this version of DKMS architecture, but it will be specified in a future version. See section 11.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#6-recovery-methods","title":"6. Recovery Methods","text":"<p>In key management, key recovery specifies how keys are reconstituted in case of loss or compromise. In decentralized identity management, recovery is even more important since identity owners have no \"higher authority\" to turn to for recovery.</p> <p>In this version of DKMS architecture, two recovery methods are recommended:</p> <ol> <li> <p>Offline recovery uses physical media or removable digital media to store recovery keys.</p> </li> <li> <p>Social recovery employs \"trustees\" who store encrypted recovery data on an identity owners behalf\u2014typically in the trustees own agent(s).</p> </li> </ol> <p>These methods are not exclusive, i.e., both can be employed for additional safety.</p> <p>Both methods operate against encrypted backups of the identity owner\u2019s digital identity wallet. Backups are encrypted by the edge agent with a backup recovery key. See section 5.1. While such backups may be stored in many locations, for simplicity this version of DKMS architecture assumes that cloud agents will provide an automated backup service for their respective edge agents.</p> <p>Future versions of this specification MAY specify additional recovery methods, include remote biometric recovery and recovery cooperatives.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#61-offline-recovery","title":"6.1. Offline Recovery","text":"<p>Offline recovery is the conventional form of backup. It can be performed using many different methods. In DKMS architecture, the standard strategy is to store an encrypted backup of the identity owner\u2019s wallet at the owner\u2019s cloud agent, and then store a private backup recovery key offline. The private backup recovery key can be printed to a paper wallet as one or more QR codes or text strings. It can also be saved to a file on a detachable media device such as a removable disk, hardware wallet or USB key. </p> <p>The primary downside to offline recovery is that the identity owner must not only safely store the offline copy, but remember the location and be able to able to access the offline copy when it is needed to recover.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#62-social-recovery","title":"6.2. Social Recovery","text":"<p>Social recovery has two advantages over offline recovery:</p> <ol> <li> <p>The identity owner does not have to create an offline backup\u2014the social recovery setup process can be accomplished entirely online.</p> </li> <li> <p>The identity owner does not have to safely store and remember the location of the offline backup.</p> </li> </ol> <p>However it is not a panacea:</p> <ol> <li> <p>The identity owner still needs to remember her trustees.</p> </li> <li> <p>Social recovery opens the opportunity, however remote, for an identity owner\u2019s trustees to collude to take over the identity owner\u2019s digital identity wallet.</p> </li> </ol> <p>A trustee is any person, institution, or service that agrees to assist an identity owner during recovery by (1) securely storing recovery material (called a \"share\") until a recovery is needed, and (2) positively identifying the identity owner and the authenticity of a recovery request before authorizing release of their shares.</p> <p>This second step is critical. Trustees MUST strongly authenticate an identity owner during recovery so as to detect if an attacker is trying exploit them to steal a key or secret. Software should aid in ensuring the authentication is strong, for example, confirming the trustee actually conversed with Alice, as opposed to getting an email from her.</p> <p>For social recovery, agents SHOULD split keys into shares and distribute them to trustees instead of sending each trustee a full copy. When recovery is needed, trustees can be contacted and the key will be recovered once enough shares have been received. An efficient and secure threshold secret sharing scheme, like Shamir's Secret Sharing, SHOULD be used to generate the shares and recombine them. The number of trustees to use is the decision of the identity owner, however it is RECOMMENDED to use at least three with a threshold of at least two. </p> <p>The shares may be encrypted by a key derived from a KDF or PRNG whose input is something only the identity owner knows, has, or is or any combination of these.</p> <p></p> <p>Figure 5: Key sharing using Shamir Secret Sharing</p> <p>As the adoption interest in decentralized identity grows, social recovery has become a major focus of additional research and development in the industry. For example, at the Rebooting the Web of Trust #8 conference held in Barcelona 1-3 March 2019, six papers on the topic were submitted (note that several of these also have extensive bibliographies):</p> <ol> <li> <p>A New Approach to Social Key Recovery by Christopher Allen and Mark Friedenbach</p> </li> <li> <p>Security Considerations of Shamir's Secret Sharing by Peg</p> </li> <li> <p>Implementing of Threshold Schemes by Daan Sprenkels</p> </li> <li> <p>Social Key Recovery Design and Implementation by Hank Chiu, Hankuan Yu, Justin Lin &amp; Jon Tsai</p> </li> <li> <p>SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes by The TREZOR Team</p> </li> </ol> <p>In addition, two new papers on the topic were started at the conference and are still in development at the time of publication:</p> <ol> <li> <p>Shamir Secret Sharing Best Practices by Christopher Allen et al.</p> </li> <li> <p>Evaluating Social Schemes for Recovering Control of an Identifier by Sean Gilligan, Peg, Adin Schmahmann, and Andrew Hughes</p> </li> </ol>"},{"location":"concepts/0051-dkms/dkms-v4/#7-recovery-from-key-loss","title":"7. Recovery From Key Loss","text":"<p>Key loss as defined in this document means the owner can assume there is no further risk of compromise. Such scenarios include devices unable to function due to water, electricity, breaking, fire, hardware failure, acts of God, etc.  </p>"},{"location":"concepts/0051-dkms/dkms-v4/#71-agent-policy-key-loss","title":"7.1. Agent Policy Key Loss","text":"<p>Loss of an agent policy key means the agent no longer has proof authorization and cannot make updates to the agent policy registry on the ledger. Identity owners SHOULD have backup agent policy keys that can revoke the current active agent policy key from the agent policy registry and issue a new agent policy key to the replacement agent.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#72-did-key-loss","title":"7.2. DID Key Loss","text":"<p>Loss of a DID key means the agent can no longer authenticate over the channel and cannot rotate the key. This key MUST be recoverable from the encrypted backup.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#73-link-secret-loss","title":"7.3. Link Secret Loss","text":"<p>Loss of the link secret means the owner can no longer generate proofs for the verifiable credentials in her possession or be issued credentials under the same identity. The link secret MUST be recoverable from the encrypted backup.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#74-credential-loss","title":"7.4. Credential Loss","text":"<p>Loss of credentials requires the owner to contact his credential issuers, reauthenticate, and request the issuers revoke existing credentials, if recovery from a backup is not possible. Credentials SHOULD be recoverable from the encrypted backup. </p>"},{"location":"concepts/0051-dkms/dkms-v4/#75-relationship-state-recovery","title":"7.5. Relationship State Recovery","text":"<p>Recovery of relationship state due to any of the above key-loss scenarios is enabled via the dead drop mechanism.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#8-recovery-from-key-compromise","title":"8. Recovery From Key Compromise","text":"<p>Key compromise means that private keys and/or master keys have become or can become known either passively or actively. </p> <ol> <li> <p>\"Passively\" means the identity owner is not aware of the compromise. An attacker may be eavesdropping or have remote communications with the agent but has not provided direct evidence of intrusion or malicious activity, such as impersonating the identity owner or committing fraud.</p> </li> <li> <p>\"Actively\" means the identity owner knows her keys have been exposed. For example, the owner is locked out of her own devices and/or DKMS agents and wallets, or becomes aware of abuse or fraud.</p> </li> </ol> <p>To protect from either, there are techniques available: rotation, revocation, and quick recovery. Rotation helps to limit a passive compromise, while revocation and quick recovery help to limit an active one.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#81-key-rotation","title":"8.1. Key Rotation","text":"<p>Keys SHOULD be changed periodically to limit tampering. When keys are rotated, the previous keys are revoked and new ones are added. It is RECOMMENDED for keys to expire for the following reasons:</p> <ul> <li> <p>Technology advances. Encryption (and encryption breaking) technologies are constantly advancing.  Expiring keys helps enforce migrating to better technologies.</p> </li> <li> <p>Mitigation of compromises. Keys that change often prevent attackers from using them even if they are able to steal them. Expiring keys spreads this immunity.</p> </li> <li> <p>Changing needs. Key owners may only use certain secrets while performing a specific task. The task may end after a certain date and all secrets tied to that task should also be terminated. Expiring keys helps enforce this this policy.</p> </li> </ul>"},{"location":"concepts/0051-dkms/dkms-v4/#82-key-revocation","title":"8.2. Key Revocation","text":"<p>DKMS keys MUST be revocable. Verifiers MUST be able to determine the revocation status of a DKMS key. It is not good enough to simply forget a key because that does not protect against key compromise. Control over who can update a revocation list MUST be enforced so attackers cannot maliciously revoke user keys. (Note that a key revoked by an attacker reveals that the attacker knows a secret.)</p>"},{"location":"concepts/0051-dkms/dkms-v4/#83-agent-policy-key-compromise","title":"8.3. Agent Policy Key Compromise","text":"<p>Compromise of an agent\u2019s policy key means an attacker can use the agent to impersonate the owner for proof presentation and make changes to the agent policy registry. Owners must be able to revoke any of their devices to prevent impersonation. For example, if the owner knows her device has been stolen, she will want to revoke all device permissions so even if the thief manages to break into the agent the DKMS data value is limited. Identity owners SHOULD have backup agent policy keys that are authorized to revoke the compromised key from the agent policy registry and issue a new agent policy key to the replacement agent.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#84-did-key-compromise","title":"8.4. DID Key Compromise","text":"<p>Compromise of a DID key means an attacker can use the channel to impersonate the owner as well as potentially lock the owner out from further use if the attacker rotates the key before the owner realizes what has happened. This attack surface is minimized if keys are rotated on a regular basis. An identity owner MUST also be able to trigger a rotation manually upon discovery of a compromise. Owners SHOULD implement a diffuse trust model among multiple agents where a single compromised agent is not able to revoke a key because more than one agent is required to approve the action. </p>"},{"location":"concepts/0051-dkms/dkms-v4/#85-link-secret-compromise","title":"8.5. Link Secret Compromise","text":"<p>Compromise of the owner link secret means an attacker may impersonate the owner when receiving verifiable credentials or use existing credentials for proof presentation. Note that unless the attacker is also able to use an agent that has \"PROVE\" authorization, the verifier will be able to detect an unauthorized agent. At this point the owner SHOULD revoke her credentials and request for them to be reissued with a new link secret.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#86-credential-compromise","title":"8.6. Credential Compromise","text":"<p>Compromise of a verifiable credential means an attacker has learned the attributes of the credential. Unless the attacker also manages to compromise the link secret and an authorized agent, he is not able to assert the credential, so the only loss is control of the underlying data.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#87-relationship-state-recovery","title":"8.7. Relationship State Recovery","text":"<p>Recovery of relationship state due to any of the above key-compromise scenarios is enabled via the dead drop mechanism.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#9-dkms-protocol","title":"9. DKMS Protocol","text":""},{"location":"concepts/0051-dkms/dkms-v4/#91-microledger-transactions","title":"9.1. Microledger Transactions","text":"<p>DKMS architecture uses microledgers to represent the state of the authorized keys in a relationship. Just as with conventional ledgers, the structure is such that the parties to a relationship can verify it at any moment in time, as can a third party for auditing purposes. Microledgers are used between two parties where each party signs transactions using their DID keys. This allow changes to DID keys to be propagated in a secure manner where each transaction is signed with an existing key authorized in earlier transactions. </p>"},{"location":"concepts/0051-dkms/dkms-v4/#92-policy-registries","title":"9.2. Policy Registries","text":"<p>Each Identity Owner creates an authorization policy on the ledger. The policy allows an agent to have some combination of authorizations. This is a public record, but no information needs to be shared with any other party. Its purpose is to allow for management of device authorization in a flexible way, by allowing for agents to prove in zero knowledge that they are authorized by the identity owner.</p> <ul> <li>The authorization policy has a unique address on the ledger.</li> <li>Each of the identity owner's agents has a secret value.</li> <li>The agent makes a blinded commitment to the secret value.</li> <li>The agent then makes another blinded commitment to both the first commitment and the policy address.</li> <li>The first commitment is stored in the PROVE section of the authorization policy.</li> <li>The second commitment is stored by the ledger in a global registry (shared by all identity owners, or at least a large number of them, for herd privacy).</li> </ul> <p>When an agent is granted PROVE authorization, by adding a commitment to the agent's secret value to PROVE section of the authorization policy, the ledger adds the second commitment to the global prover registry. When an agent loses its PROVE authorization, the ledger removes the associated commitment from the prover registry. The ledger can enforce sophisticated owner defined rules like requiring multiple signatures to authorize updates to the Policy.</p> <p>An agent can now prove in zero knowledge that it is authorized because the ledger maintains a global registry for all agents with PROVE authorization for all identity owners. An agent can prove that its secret value and the policy address in which that value is given PROVE authorization are part of the global policy registry without revealing the secret value, or the policy address. By using a zero knowledge proof, the global policy registry does not enable correlation of any specific identity owner.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#93-authenticated-encryption","title":"9.3. Authenticated Encryption","text":"<p>The use of DIDs and microledgers allows communication between agents to use authenticated encryption. Agents use their DID verification keys for authenticating each other whenever a communication channel is established. Microledgers allow DID keys to have rooted mutual authentication for any two parties with a DID. In the sequence diagrams in section 10, all agent-to-agent communications that uses authenticated encryption is indicated by bold blue arrows.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#94-recovery-connection","title":"9.4. Recovery connection","text":"<p>Each Identity Owner begins a recovery operation by requesting their respective recovery information from trustees. After a trustee has confirmed the request originated with the identity owner and not a malicious party, a recovery connection is formed. This special type of connection is meant only for recovery purposes. Recovery connections are decommissioned when the minimum number of recovery shares have been received and the original encrypted wallet data has been restored. Identity owners can then resume normal connections because their keys have been recovered. Trustees SHOULD only send recovery shares to identity owners over a recovery connection.  </p>"},{"location":"concepts/0051-dkms/dkms-v4/#95-dead-drops","title":"9.5. Dead Drops","text":"<p>In scenarios where two parties to a connection move agencies (and thus service endpoints) at the same time, or one party's agents have been compromised such that it can no longer send or receive relationship state changes, there is a need for recovery not just of keys and agents, but of the state of the relationship. These scenarios may include malicious compromise of agents by an attacker such that neither the party nor the attacker controls enough agents to meet the thresholds set in the DID Document or the Authorization Policy, or complete loss of all agents due to some catastrophic event.</p> <p>In some cases, relationship state may be recoverable via encrypted backup of the agent wallets. In the event that this is not possible, the parties can make use of a dead drop to recover their relationship state.</p> <p>A dead drop is established and maintained as part of a pairwise relationship. The dead drop consists of a service endpoint and the public keys needed to verify the package that may be retrieved from that endpoint. The keys needed for the dead drop are derived from a combination of a Master key and the pairwise DID of the relationship that is being recovered.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#10-protocol-flows","title":"10. Protocol Flows","text":"<p>This section contains the UML sequence diagrams for all standard DKMS key management operations that use the DKMS protocol. Diagrams are listed in logical order of usage but may be reviewed in any order. Cross-references to reusable protocol sequences are represented as notes in blue. Other comments are in yellow.</p> <p>Table 1 is a glossary of the DKMS key names and types used in these diagrams.</p> Key Name Description A<sub>p</sub><sup>x-sv</sup> Agent Policy Secret Value for agent x A<sub>p</sub><sup>x-svc</sup> Agent Policy Secret Value Commitment for agent x A<sub>p</sub><sup>x-ac</sup> Agent Policy Address Commitment for agent x A<sub>A</sub><sup>x-ID</sup> Alice's Agent to Agent Identifier for agent x A<sub>A</sub><sup>x-vk</sup> Alice's Agent to Agent Public Verification Key for agent x A<sub>A</sub><sup>x-sk</sup> Alice's Agent to Agent Private Signing Key for agent x A<sub>B</sub><sup>DID</sup> Alice\u2019s DID for connection with Bob A<sub>B</sub><sup>x</sup> Alice\u2019s key pair for connection with Bob for agent x A<sub>B</sub><sup>x-vk</sup> Alice\u2019s Public Verification Key for connection with Bob for agent x A<sub>B</sub><sup>x-sk</sup> Alice\u2019s Private Signing Key for connection with Bob for agent x A<sub>W</sub><sup>x-k</sup> Wallet Encryption Key for agent x A<sub>LS</sub> Alice's Link Secret <p>Table 1: DKMS key names used in this section</p>"},{"location":"concepts/0051-dkms/dkms-v4/#101-edge-agent-start","title":"10.1. Edge Agent Start","text":"<p>An identity owner\u2019s experience with DKMS begins with her first installation of a DKMS edge agent. This startup routine is reused by many other protocol sequences because it is needed each time an identity owner installs a new DKMS edge agent.</p> <p></p> <p>The first step after successful installation is to prompt the identity owner whether he/she already has a DKMS identity wallet or is instantiating one for the first time. If the owner already has a wallet, the owner is prompted to determine if the new edge agent installation is for the purpose of adding a new edge agent, or recovering from a lost or compromised edge agent. Each of these options references another protocol pattern.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#102-provision-new-agent","title":"10.2. Provision New Agent","text":"<p>Any time a new agent is provisioned\u2014regardless of whether it is an edge agent or a cloud agent\u2014the same sequence of steps are necessary to set up the associated wallet and secure communications with the new agent.</p> <p></p> <p>As noted in section 3.3, DKMS architecture recommends that a DKMS agent be installed in an environment that includes a secure element. So the first step is for the edge agent to set up the credential the identity owner will use to unlock the secure element. On modern smartphones this will typically be a biometric, but it could be a PIN, passcode, or other factor, or a combination of factors.</p> <p>The edge agent then requests the secure element to create the key pairs necessary to establish the initial agent policies and to secure agent-to-agent communications. The edge agent also generates a ID to uniquely identify the agent across the identity owner\u2019s set of DKMS agents.</p> <p>Finally the edge agent requests the secure element to create a wallet encryption key and then uses it to encrypt the edge wallet.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#103-first-edge-agent","title":"10.3. First Edge Agent","text":"<p>The first time a new identity owner installs an edge agent, it must also set up the DKMS components that enable the identity owner to manage multiple separate DIDs and verifiable credentials as if they were from one logically unified digital identity. It must also lay the groundwork for the identity owner to install additional DKMS agents on other devices, each of which will maintain its own DKMS identity wallet while still enabling the identity owner to act as if they were all part of one logically unified identity wallet.</p> <p></p> <p>Link secrets are defined in section 5.1 and policy registries in section 9.2. The edge agent first needs to generate and store the link secret in the edge wallet. It then needs to generate the policy registry address and store it in the edge wallet. Now it is ready to update the agent policy registry.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#104-update-agent-policy-registry","title":"10.4. Update Agent Policy Registry","text":"<p>As explained in section 9.2, an agent policy registry is the master control point that an identity owner uses to authorize and revoke DKMS agent proof authorization (edge or cloud).</p> <p></p> <p>Each time the identity owner takes an action to add, revoke, or change the permissions for an agent, the policy registry is updated. For example, at the end of the protocol sequence in section 10.3, the action is to write the first policy registry entries that authorize the first edge agent.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#105-add-cloud-agent","title":"10.5. Add Cloud Agent","text":"<p>The final step in first-time setup of an edge agent is creation of the corresponding cloud agent. As explained in section 3.3, the default in DKMS architecture is to always pair an edge agent with a corresponding cloud agent due to the many different key management functions this combination can automate.</p> <p></p> <p></p> <p>The process of registering a cloud agent begins with the edge agent contacting the agency agent. For purposes of this document, we will assume that the edge agent has a relationship with one or more agencies, and has a trusted method (such as a pre-installed DID) for establishing a secure connection using authenticated encryption.</p> <p>The target agency first returns a request for the consent required from the identity owner to register the cloud agent together with a request for the authorizations to be granted to the cloud agent. By default, cloud agents have no authorizations other than those granted by the identity owner. This enables identity owners to control what tasks a cloud agent may or may not perform on the identity owner\u2019s behalf.</p> <p>Once the identity owner has returned consent and the selected authorizations, the agency agent provisions the new cloud agent and registers the cloud agent\u2019s service endpoint using the agency\u2019s routing extension. Note that this service endpoint is used only in agent-to-agent communications that are internal to the identity owner\u2019s own agent domain. Outward-facing service endpoints are assigned as part of adding connections with their own DIDs.</p> <p>Once these tasks are performed, the results are returned to the edge agent and stored security in the edge wallet.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#106-add-new-edge-agent","title":"10.6. Add New Edge Agent","text":"<p>Each time an identity owner installs a new edge agent after their first edge agent, the process must initialize the new agent and grant it the necessary authorizations to begin acting on the identity owner\u2019s behalf.</p> <p></p> <p>Provisioning of the new edge agent (Edge Agent 2) starts by the identity owner installing the edge agent software (section 10.2) and then receiving instructions about how to provision the new edge agent from an existing edge agent (Edge Agent 1). Note that Edge Agent 1 must the authorization to add a new edge agent (not all edge agents have such authorization). The identity owner must also select the authorizations the edge agent will have (DKMS agent developers will compete to make such policy choices easy and intuitive for identity owners).</p> <p>There are multiple options for how the Edge Agent 2 may receive authorization from Edge Agent 1. One common method is for Edge Agent 1 to display a QR code or other machine-readable code scanned by Edge Agent 2. Another way is for Edge Agent 1 to provide a passcode or passphrase that the identity owner types into Edge Agent 2. Another method is sending an SMS or email with a helper URL. In all methods the ultimate result is that Edge Agent 2 must be able to connect via authenticated encryption with Edge Agent 1 in order to verify the connection and pass the new agent-to-agent encryption keys that will be used for secure communications between the two agents.</p> <p>Once this is confirmed by both agents, Edge Agent 1 will then use the Update Agent Policy Registry sequence (section 10.4) to add authorizations to the policy registry for Edge Agent 2.</p> <p>Once that is confirmed, provisioning of Edge Agent 2 is completed when Edge Agent 1 send the link secret and any verifiable credentials that the identity owner has authorized Edge Agent 2 to handle to Edge Agent 2, which securely stores them in Edge Agent 2\u2019s wallet.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#107-add-connection-to-public-did","title":"10.7. Add Connection to Public DID","text":"<p>The primary purpose of DIDs and DKMS is to enable trusted digital connections. One of the most common use cases is when an identity owner needs to create a connection to an entity that has a public DID, for example any website that wants to support trusted decentralized identity connections with its users (for registration, authentication, verifiable credentials exchange, secure communications, etc.)</p> <p></p> <p></p> <p>Note that this sequence is entirely about agent-to-agent communications between DKMS agents to create a shared microledger and populate it with the pairwise pseudonymous DIDs that Alice and Org assign to each other together with the public keys and service endpoints they need to enable their agents to use authenticated encryption.</p> <p>First Alice\u2019s edge agent creates the key pair and DID that it will assign to Org and uses those to initialize a new microledger. It then sends a request for Alice\u2019s cloud agent to add its own key pair that Alice authorizes to act on that DID. These are returned to Alice\u2019s edge agent who adds them to the microledger.</p> <p>Next Alice\u2019s edge agent creates and sends a connection invitation to Alice\u2019s cloud agent. Alice\u2019s cloud agent resolves Org\u2019s DID to its DID document to discover the endpoint for Org\u2019s cloud agent (this resolution step is not shown in the diagram above). It then forwards the invitation to Org\u2019s cloud agent who in turn forwards it to the system operating as Org\u2019s edge agent.</p> <p>Org\u2019s edge agent performs the mirror image of the same steps Alice\u2019s edge agent took to create its own DID and key pair for Alice, adding those to the microledger, and authorizing its cloud agent to act on its behalf in this new relationship. </p> <p>When that is complete, Org\u2019s edge agent returns its microledger updates via authenticated encryption to its cloud agent which forwards them to Alice\u2019s cloud agent and finally to Alice\u2019s edge agent. This completes the connection and Alice is notified of success.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#108-add-connection-to-private-did-provisioned","title":"10.8. Add Connection to Private DID (Provisioned)","text":"<p>The other common use case for trusted connections is private peer-to-peer connections between two parties that do not initially connect via one or the other\u2019s public DIDs. These connections can be initiated any way that one party can share a unique invitation address, i.e., via a URL sent via text, email, or posted on a blog, website, LinkedIn profile, etc.</p> <p></p> <p></p> <p>The flow in this sequence diagram is very similar to the flow in section 10.8 where Alice is connecting to a public organization. The only difference is that rather than beginning with Alice\u2019s edge agent knowing a public DID for the Org, Alice\u2019s edge agent knows Bob\u2019s invitation address. This is a service, typically provided by an agency, that enables Bob\u2019s cloud agent to accept connection invitations (typically with appropriate spam protections and other forms of connection invitation filtering).</p> <p>The end result is the same as in section 10.8: Alice and Bob have established a shared microledger with the pairwise pseudonymous DIDs and the public keys and endpoints they need to maintain their relationship. Note that with DIDs and DKMS, this is the first connection that Alice and Bob can maintain for life (and beyond) that is not dependent on any centralized service provider or registry. And this connection is available for Alice and Bob to use with any application they wish to authorize.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#109-add-connection-to-private-did-unprovisioned","title":"10.9. Add Connection to Private DID (Unprovisioned)","text":"<p>This sequence is identical to section 10.8 except that Bob does not yet have a DKMS agent or wallet. So it addresses what is necessary for Alice to invite Bob to both start using a DKMS agent and to form a connection with Alice at the same time.</p> <p></p> <p></p> <p>The only difference between this sequence diagram and section 10.8 is the invitation delivery process. In 10.8, Bob already has a cloud agent, so the invitation can be delivered to an invitation address established at the hosting agency. In this sequence, Bob does not yet have cloud agent, so the invitation must be: a) anchored at a helper URL (typically provided by an agency), and b) delivered to Bob via some out-of-band means (typically an SMS, email, or other medium that can communicate a helper URL).</p> <p>When Bob receives the invitation, Bob clicks on the URL to go to the helper page and receive instructions about the invitation and how he can download a DKMS edge agent. He follows the instructions, installs the edge agent, which in turn provisions Bob\u2019s cloud agent. When provisioning is complete, Bob\u2019s edge agent retrieves Alice\u2019s connection invitation from the helper URL. Since Bob is now fully provisioned, the rest of the sequence proceeds identically to section 10.8.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#1010-rotate-did-keys","title":"10.10. Rotate DID Keys","text":"<p>As described in section 8.1, key rotation is a core security feature of DKMS. This diagram illustrates athe protocol for key rotation.</p> <p></p> <p></p> <p>Key rotation may be triggered by expiration of a key or by an another event such as agent recovery. The process begins with the identity owner\u2019s edge agent generating its own new keys. If keys also need to be rotated in the cloud agent, the edge agent sends a key change request.</p> <p>The identity owner\u2019s agent policy may require that key rotation requires authorization from two or more edge agents. If so, the first edge agent generates a one time passcode or QR code that the identity owner can use to authorize the key rotation at the second edge agent. Once the passcode is verified, the second edge agent signs the key rotation request and sends it to the first edge agent.</p> <p>Once the necessary authorizations have been received, the first edge agent writes the changes to the microledger for that DID. It then sends the updates to the microledger to the cloud agent for the other party to the DID relationship (Bob), who forwards it to Bob\u2019s edge agent. Bob\u2019s edge agent verifies the updates and adds the changes to its copy of the microledger.</p> <p>Bob\u2019s edge agent then needs to broadcast the changes to Bob\u2019s cloud agent and any other edge agent that Bob has authorized to interact with Alice. Once this is done, Alice and Bob are \"in sync\" with the rotated keys, and their connection is at full strength.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#1011-delete-connection","title":"10.11. Delete Connection","text":"<p>In decentralized identity, identity owners are always in control of their relationships. This means either party to a connection can terminate the relationship by deleting it. This diagram illustrates Alice deleting the connection she had with Bob.</p> <p></p> <p>All that is required to delete a connection is for the edge agent to add a DISABLE event to the microledger she established with Bob. As always, this change is propagated to Alice\u2019s cloud agent and any other edge agents authorized to interact with the DID she assigned to Bob.</p> <p>Note that, just like in the real world, it is optional for Alice to notify Bob of this change in the state of their relationship. If she chooses to do so, her edge agent will propagate the DISABLE event to Bob\u2019s copy of the microledger. If, when, and how Bob is notified by his edge agent(s) depends on Bob\u2019s notification policies.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#1012-revoke-edge-agent","title":"10.12. Revoke Edge Agent","text":"<p>Key revocation is also a required feature of DKMS architecture as discussed in section 8.2. Revocation of keys for a specific DID is accomplished either through rotation of those keys (section 10.10) or deletion of the connection (section 10.11). However in certain cases, an identity owner may need to revoke an entire edge agent, effectively disabling all keys managed by that agent. This is appropriate if a device is lost, stolen, or suspected of compromise.</p> <p></p> <p>Revoking an edge agent is done from another edge agent that is authorized to revoke agents. If a single edge agent is authorized, the process is straightforward. The revoking edge agent sends a signed request to the policy registry address (section 9.2) on the ledger holding the policy registry. The ledger performs the update. The revoking edge agent then \"removes\" the keys for the revoked edge agent by disabling them.</p> <p>As a best practice, this event also should trigger key rotation by the edge agent.</p> <p>Note that an identity owner may have a stronger revocation policy, such as requiring two edge agents to authorize revocation of another edge agent. This sequence is very similar to requiring two edge agents to authorize a key rotation as described in section 10.10. However it could also cause Alice to be locked out of her edge agents if an attacker can gain control of enough devices. In this case Alice could use one of her recovery options (sections 10.16 and 10.17).</p>"},{"location":"concepts/0051-dkms/dkms-v4/#1013-recovery-setup","title":"10.13. Recovery Setup","text":"<p>As discussed in section 6, recovery is a paramount feature of DKMS\u2014in decentralized key management, there is no \"forgot password\" button (and if there were, it would be a major security vulnerability). So it is particularly important that it be easy and natural for an identity owner to select and configure recovery options.</p> <p></p> <p>The process begins with Alice\u2019s edge agent prompting Alice to select among the two recovery options described in section 6: offline recovery and social recovery. Her edge agent then creates a key pair for backup encryption, encrypts a backup of her edge wallet, and stores it with her cloud agent.</p> <p>If Alice chooses social recovery, the next step is for Alice to add trustees as described in section 10.14. Once the trustee has accepted Alice\u2019s invitation, Alice\u2019s edge agent creates and shares a recovery data share for each trustee. This is a shard of a file containing a copy of her backup encryption key, her link secret, and the special recovery endpoint that was set up by her cloud agent when the recovery invitation was created (see section 10.14).</p> <p>Alice\u2019s edge agent sends this recovery data share to her cloud agent who forwards it to the cloud agent for each of her trustees. Each cloud agent securely stores the share so its identity owner is ready in helping Alice to recover should the need arise. (See sections 10.17 and 10.18 for the actual social recovery process.)</p> <p>If Alice chooses offline recovery, her edge agent first creates a \"paper wallet\", which typically consists of a QR code or string of text that encodes the same data as in a recovery data share. Her edge agent then displays that paper wallet data to Alice for printing and storing in a safe place. Note that one of the primary usability challenges with offline recovery methods is Alice:</p> <ol> <li> <p>Following through with storage of the paper wallet.</p> </li> <li> <p>Properly securing storage of the paper wallet over long periods of time.</p> </li> <li> <p>Remembering the location of the paper wallet over long periods of time.</p> </li> </ol> <p>To some extent these can be addressed if the edge agent periodically reminds the identity owner to verify that his/her paper wallet is securely stored in a known location.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#1014-add-trustee","title":"10.14. Add Trustee","text":"<p>The secret to implementing social recovery in DKMS is using DKMS agents to automate the process of securely storing, sharing, and recovering encrypted backups of DKMS wallets with several of the identity owner\u2019s connections. In DKMS architecture, these connections are currently called trustees. (Note: this is a placeholder term pending further usability research on the best name for this new role.)</p> <p></p> <p>Trustees are selected by the identity owner based on the owner\u2019s trust. For each trustee, the edge agent requests the cloud agent to create a trustee invitation. The cloud agent generates and registers with the agency a unique URL that will be used only for this purpose. The edge agent then creates a recovery data share (defined in 10.13) and shards it as defined by the identity owner\u2019s recovery policy.</p> <p>At this point there are two options for delivering the trustee invitation depending on whether the identity owner already has a connection with the trustee or not. If a connection exists, the edge agent sends the invitation to the cloud agent who forwards it to the trustee\u2019s cloud agent who forwards it to an edge agent who notifies the trustee of the invitation.</p> <p>If a connection does not exist, the recovery invitation is delivered out of band in a process very similar to adding a connection to a private DID (sections 10.8 and 10.9).</p> <p>Once the trustee accepts the invitation, the response is returned to identity owner\u2019s edge agent to complete the recovery setup process (section 10.13).</p>"},{"location":"concepts/0051-dkms/dkms-v4/#1015-update-recovery-setup","title":"10.15. Update Recovery Setup","text":"<p>With DKMS infrastructure, key recovery is a lifelong process. A DKMS wallet filled with keys, DIDs, and verifiable credentials is an asset constantly increasing in value. Thus it is critical that identity owners be able to update their recovery methods as their circumstances, devices, and connections change.</p> <p></p> <p>For social recovery, an identity owner may wish to add new trustees or delete existing ones. Whenever this happens, the owner\u2019s edge agent must recalculate new recovery data shares to shard among the new set of trustees. This is a two step process: the new share must first be sent to all trustees in the new set and an acknowledgement must be received from all of them. Once that it done, the edge agent can send a commitment message to all trustees in the new set to complete the process.</p> <p>Updating offline recovery data is simply a matter of repeating the process of creating and printing out a paper wallet. An edge agent can automatically inform its identity owner of the need to do this when circumstances require it as well as automatically remind its owner to keep such offline information safe and accessible.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#1016-offline-recovery","title":"10.16. Offline Recovery","text":"<p>One advantage of the offline recovery process is that it can be performed very quickly by the identity owner because it has no dependencies on outside parties.</p> <p></p> <p>The identity owner simply initiates recovery on a newly installed edge agent. The edge agent prompts to scan the paper wallet (or input the text). From this data, it extracts the special recovery endpoint registered in the recovery setup process (section 10.13) and the backup decryption key. It then requests the encrypted backup from the recovery endpoint (which routes to the identity owner\u2019s cloud agent), decrypts it, restores the edge wallet, and replaces the agent keys with new keys. The final steps are to update the agent policy registry and, as a best practice, rotate all DID keys.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#1017-social-recovery","title":"10.17. Social Recovery","text":"<p>Social recovery, while more complex than offline recovery, is also more automated, flexible, and resilient. The secret to making it easy and intuitive for identity owners is using DKMS agents to automate every aspect of the process except for the most social step: verification of the actual identity of the identity owner by trustees.</p> <p></p> <p></p> <p>Social recovery, like offline recovery, begins with the installation of a fresh edge agent. The identity owner selects the social recovery option and is prompted for the contact data her edge agent and cloud agent will need to send special new connection requests to her trustees. These special connection requests are then issued as described in section 10.8.</p> <p>These special connection requests are able to leverage the same secure DKMS infrastructure as the original connections while at the same time carrying the metadata needed for the trustee\u2019s edge agent to recognize it is a recovery request. At that point, the single most important step in social recovery happens: the trustee verifying that it is really Alice making the recovery request, and not an impersonator using social engineering.</p> <p>Once the trustee is satisfied with the verification, the edge agent prompts the trustee to perform the next most important step: select the existing connection with Alice so that the trustee edge agent knows which connection is trying to recover. Only the trustee\u2014a human being\u2014can be trusted to make this association.</p> <p>At this point, the edge agent can correlate the old connection to Alice with the new connection to Alice, so it knows which recovery data share to select (see section 10.13). It can then decrypt the recovery data share with the identity owner\u2019s private key, extracts the recovery endpoint, and re-encrypt the recovery data share with the public key of Alice\u2019s new edge agent.</p> <p>Now the trustee\u2019s edge agent is ready to return the recovery data share to Alice\u2019s new cloud agent via the recovery endpoint. The cloud agent forwards it to Alice\u2019s new edge agent. Once Alice\u2019s new edge agent has the required set of recovery data shares, it decrypts and assembles them. It then uses that recovery data to complete the same final steps as offline recovery described in section 10.16.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#11-open-issues-and-future-work","title":"11. Open Issues and Future Work","text":"<ol> <li> <p>DID specification. The DKMS specification has major dependencies on the DID specification which is still in progress at the W3C Credentials Community Group. Although we are not concerned that the resulting specification will not support DKMS requirements, we cannot be specific about certain details of how DKMS will interact with DIDs until that specification is finalized. However the strong market interest in DIDs led the Credentials Community Group to author an extensive DID Use Cases document and submit a Decentralized Identifier Working Group charter to the W3C for consideration as a full Working Group. </p> </li> <li> <p>DID methods. The number of DID methods has grown substantially as shown by the unofficial DID Method Registry maintained by the W3C Credentials Community Group. Because different DID methods may support different levels of assurance about DKMS keys, more work may be required to assess about the role of different ledgers as a decentralized source of truth and the requirements of each ledger for the hosting of DIDs and DID documents.</p> </li> <li> <p>Verifiable credentials interoperability. The W3C Verifiable Claims Working Group is currently preparing its 1.0 Candidate Recommendation. As verifiable credentials mature, we need to say more about how different DKMS wallets and agents from different vendors can support interoperable verifiable credentials, including those with zero-knowledge credentials and proofs. Again, this may need to extend to an adjacent protocol.</p> </li> <li> <p>DKMS wallet and agent portability. As mentioned in section 5.4, this aspect of the DKMS protocol is not fully specified and needs to be addressed in a subsequent version. This area of work is particularly active in the Hyperledger Indy Agent development community. A recent \"connectathon\" hosted by the Sovrin Foundation had 32 developers testing agent-to-agent protocol interoperability among 9 different code bases.</p> </li> <li> <p>Secure elements, TPMs, and TEEs. Since DKMS is highly dependent on secure elements, more work is needed to specify how a device can communicate or verify its own security capabilities or its ability to attest to authentication factors for the identity owner.</p> </li> <li> <p>Biometrics. While they can play a special role in the DKMS architecture because of their ability to intrinsically identify a unique individual, this same quality means a privacy breach of biometric attributes could be disastrous because they may be unrecoverable. So determining the role of biometrics and biometric service providers is a major area of future work.</p> </li> <li> <p>Spam and DDOS attacks. There are several areas where this must be considered, particularly in relation to connection requests (section 10.7).</p> </li> <li> <p>DID phishing. DKMS can only enable security, it cannot by itself prevent a malicious actor or agency sending malicious invitations to form malicious connections that appear to be legitimate connection invitations (section 10.9).</p> </li> <li> <p>Usability testing. Although early research on the usability of DKMS wallets and agents was carried out by BYU Internet Security Research Lab, much more work remains to be done to develop the highly repeatable \"user ceremonies\" necessary for DKMS to succeed in the mass market.</p> </li> </ol>"},{"location":"concepts/0051-dkms/dkms-v4/#12-future-standardization","title":"12. Future Standardization","text":"<p>It is the recommendation of the authors that the work described in this document be carried forward to full Internet standardization. We believe OASIS is a strong candidate for this work due to its hosting of the Key Management Interoperability Protocol (KMIP) at the KMIP Technical Committee since 2010. Please contact the authors if you are interested in contributing to organizing an open standard effort for DKMS.</p>"},{"location":"concepts/0051-dkms/shamir_secret/","title":"Shamir secret API (indy-crypto and indy-sdk)","text":"<p>Objective: <code>indy-crypto</code> exposes the low level API for generating and reconstructing secrets. <code>indy-sdk</code> uses the underlying <code>indy-crypto</code> and exposes an API to shard a JSON message, store the shards and reconstitute the secret.</p>"},{"location":"concepts/0051-dkms/shamir_secret/#indy-crypto","title":"Indy-crypto","text":"<ol> <li><code>shard_secret(secret: bytes, m: u8, n: u8, sign_shares: Option&lt;bool&gt;) -&gt; Result&lt;Vec&lt;Share&gt;, IndyCryptoError&gt;</code>. Splits the bytes of the secret <code>secret</code> in <code>n</code> different shares and <code>m-of-n</code> shares are required to reconstitute the secret. <code>sign_shares</code> if provided, all shards are signed.  </li> <li><code>recover_secret(shards: Vec&lt;Share&gt;, verify_signatures: Option&lt;bool&gt;) -&gt; Result&lt;Vec&lt;u8&gt;, IndyCryptoError&gt;</code>. Recover the secret from the given <code>shards</code>. <code>verify_signatures</code> if given verifies the signatures.</li> </ol>"},{"location":"concepts/0051-dkms/shamir_secret/#indy-sdk","title":"Indy-sdk","text":"<ol> <li><code>shard_JSON(msg: String, m: u8, n: u8, sign_shares: Option&lt;bool&gt;) -&gt; Result&lt;Vec&lt;String&gt;, IndyError&gt;</code> Takes the message as a JSON string and serialises it to bytes and passes it to <code>shard_secret</code> of <code>indy-crypto</code>. The serialisation has to be deterministic, i.e the same JSON should always serialise to same bytes everytime. The resulting <code>Share</code> given by <code>indy-crypto</code> is converted to JSON before returning. </li> <li><code>shard_JSON_with_wallet_data(wallet_handle: i32, msg: String, wallet_keys:Vec&lt;&amp;str&gt;, m: u8, n: u8, sign_shares: Option&lt;bool&gt;) -&gt; Result&lt;Vec&lt;String&gt;, IndyError&gt;</code> Takes the message as a JSON string, updates the JSON with key-values from wallet given by handle <code>wallet_handle</code>, keys present in the vector <code>wallet_keys</code> and passes the resulting JSON to <code>shard_JSON</code>. </li> <li><code>recover_secret(shards: Vec&lt;String&gt;, verify_signatures: Option&lt;bool&gt;) -&gt; Result&lt;String, IndyError&gt;</code> Takes a collection of shards each encoded as JSON, deserialises them into <code>Share</code>s and passes them to <code>recover_secret</code> from <code>indy-crypto</code>. It converts the resulting secret back to JSON before returning it.</li> <li><code>shard_JSON_and_store_shards(wallet_handle: i32, msg: String, m: u8, n: u8, sign_shares: Option&lt;bool&gt;) -&gt; Result&lt;String, IndyError&gt;</code> Shards the given JSON using <code>shard_JSON</code> and store shards as a JSON array (each shard is an object in itself) in the wallet given by <code>wallet_handle</code>. Returns the wallet key used to store the shards.</li> </ol>"},{"location":"concepts/0051-dkms/trustee_protocols/","title":"Trustee Setup Protocol","text":"<p>Objective: Provide the messages and data formats so an identity owner can choose, update, remove trustees and their delegated capabilities.</p>"},{"location":"concepts/0051-dkms/trustee_protocols/#assumptions","title":"Assumptions","text":"<ol> <li>An identity owner selects a connection to become a trustee</li> <li>Trustees can be granted various capabilities by identity owners<ol> <li>Safeguarding a recovery share. This will be the most common</li> <li>Revoke an authorized agent on behalf of an identity owner</li> <li>Provision a new agent on behalf of an identity owner</li> <li>Be an administrator for managing identity owner agents</li> </ol> </li> <li>Trustees agree to any new specified capabilities before any action is taken</li> <li>Trustees will safeguard recovery shares. Their app will encrypt the share and not expose it to anyone else</li> <li>Trustees authenticate out-of-band an identity owner when a recovery event occurs</li> <li>The Trustees' app should only send a recovery share to an identity owner after they have been authenticated</li> <li>All messages will use a standard DIDComm Envelope.</li> </ol>"},{"location":"concepts/0051-dkms/trustee_protocols/#messages-and-structures","title":"Messages and Structures","text":"<p>Messages are formatted as JSON. All binary encodings use base64url. All messages include the following fields:</p> <ol> <li>version \\&lt;string&gt;: The semantic version of the message data format.</li> <li>type \\&lt;string&gt;: The message type.</li> </ol>"},{"location":"concepts/0051-dkms/trustee_protocols/#capabilty_offer","title":"CAPABILTY_OFFER","text":"<p>Informs a connection that the identity owner wishes to make them a trustee. The message includes information about what capabilities the identity owner has chosen to grant a trustee and how long the offer is valid. This message adds the following fields</p> <p>expires \\&lt;string&gt;: 64-bit unsigned big-endian integer. The number of seconds elapsed between January 1, 1970 UTC and the time the offer will expire if no request message is received. This value is purely informative.\\ capabilities \\&lt;list[string]&gt;: A list of capabilities that the trustee will be granted. They can include</p> <ol> <li>RECOVERY_SHARE: The trustee will be given a recovery share</li> <li>REVOKE_AUTHZ: The trustee can revoke agents</li> <li>PROVISION_AUTHZ: The trustee can provision new agents</li> <li>ADMIN_AUTHZ: The trustee is an administrator of agents</li> </ol> <pre><code>{\n  \"version\": \"0.1\",\n  \"type\": \"CAPABILITY_OFFER\",\n  \"capabilities\": [\"RECOVERY_SHARE\", \"REVOKE_AUTHZ\", \"PROVISION_AUTHZ\"]\n  \"expires\": 1517428815\n}\n</code></pre>"},{"location":"concepts/0051-dkms/trustee_protocols/#capabilty_request","title":"CAPABILTY_REQUEST","text":"<p>Sent to an identity owner in response to a TRUSTEE_OFFER message. The message includes includes information for which capabilities the trustee has agreed. This message adds the following fields</p> <p>for_id \\&lt;string&gt;: The nonce sent in the TRUSTEE_OFFER message.\\ capabilities \\&lt;object[string,string]&gt;: A name value object that contains the trustee's response for each privilege.\\ authorizationKeys \\&lt;list[string]&gt;: The public keys that the trustee will use to verify her actions with the authz policy registry on behalf of the identity owner.</p> <pre><code>{\n  \"version\": \"0.1\",\n  \"type\": \"CAPABILITY_REQUEST\",\n  \"authorizationKeys\": [\"Rtna123KPuQWEcxzbNMjkb\"]\n  \"capabilities\": [\"RECOVERY_SHARE\", \"REVOKE_AUTHZ\"]\n}\n</code></pre>"},{"location":"concepts/0051-dkms/trustee_protocols/#capability_response","title":"CAPABILITY_RESPONSE","text":"<p>Sends the identity owner policy address and/or recovery data and metadata to a recovery trustee. A trustee should send a confirmation message that this message was received.</p> <p>address \\&lt;string&gt;: The identity owner's policy address. Only required if the trustee has a key in the authz policy registry.\\ share \\&lt;object&gt;: The actual recovery share data in the format given in the next section. Only required if the trustee has the RECOVERY_SHARE privilege.</p> <pre><code>{\n  \"version\": \"0.1\",\n  \"type\": \"CAPABILITY_RESPONSE\",\n  \"address\": \"b3AFkei98bf3R2s\"\n  \"share\": {\n    ...\n  }\n}\n</code></pre>"},{"location":"concepts/0051-dkms/trustee_protocols/#trust_ping","title":"TRUST_PING","text":"<p>Authenticates a party to the identity owner for out of band communication.</p> <p>challenge \\&lt;object&gt;: A message that a party should respond to so the identity owner can be authenticated. Contains a question field for the other party to answer and a list of valid_responses.</p> <pre><code>{\n  \"version\": \"0.1\",\n  \"type\": \"TRUST_PING\",\n  \"challenge\": {\n    ...\n  }\n}\n</code></pre> <p>challenge will look like the example below but allows for future changes as needed.\\ question \\&lt;string&gt;: The question for the other party to answer.\\ valid_responses \\&lt;list[string]&gt;: A list of valid responses that the party can give in return.</p> <pre><code>{\n    \"question\": \"Are you on a call with CULedger?\",\n    \"valid_responses\": [\"Yes\", \"No\"]\n}\n</code></pre>"},{"location":"concepts/0051-dkms/trustee_protocols/#trust_pong","title":"TRUST_PONG","text":"<p>The response message for the TRUST_PING message.</p> <pre><code>  \"version\": \"0.1\",\n  \"type\": \"TRUST_PONG\",\n  \"answer\": {\n    \"answerValue\": \"Yes\"\n  }\n</code></pre>"},{"location":"concepts/0051-dkms/trustee_protocols/#key_heartbeat_request","title":"KEY_HEARTBEAT_REQUEST","text":"<p>Future_Work: Verifies a trustee/agent has and is using the public keys that were given to the identity owner. These keys</p> <p>authorizationKeys \\&lt;list[string]&gt;: Public keys the identity owner knows that belong to the trustee/agent.</p> <pre><code>{\n  \"version\": \"0.1\",\n  \"type\": \"KEY_HEARTBEAT_REQUEST\",\n  \"authorizationKeys\": [\"Rtna123KPuQWEcxzbNMjkb\"]\n}\n</code></pre>"},{"location":"concepts/0051-dkms/trustee_protocols/#key_heartbeat_response","title":"KEY_HEARTBEAT_RESPONSE","text":"<p>Future_Work: The updated keys sent back from the trustee/agent </p>"},{"location":"concepts/0051-dkms/trustee_protocols/#recovery_share_response","title":"RECOVERY_SHARE_RESPONSE","text":"<p>Future_Work: After an identity owner receives a challenge from a trustee, an application prompts her to complete the challenge. This message contains her response.</p> <p>for_id \\&lt;string&gt;: The nonce sent in the RECOVERY_SHARE_CHALLENGE message.\\ response \\&lt;object&gt;: The response from the identity owner.</p> <pre><code>{\n  \"version\": \"0.1\",\n  \"type\": \"RECOVERY_SHARE_RESPONSE\",\n  \"response\": {\n    ...\n  }\n}\n</code></pre> <p>response will look like the example below but allows for future changes as needed.</p> <pre><code>{\n  \"pin\": \"3qA5h7\"\n}\n</code></pre>"},{"location":"concepts/0051-dkms/trustee_protocols/#recovery-share-data-structure","title":"Recovery Share Data Structure","text":"<p>Recovery shares are formatted in JSON with the following fields:</p> <ol> <li>version \\&lt;string&gt;: The semantic version of the recovery share data format.</li> <li>source_did: The identity owner DID that sent this share to the trustee</li> <li>tag \\&lt;string&gt;: A value used to verify that all the shares are for the same secret. The identity owner compares this to every share to make sure they are the same.</li> <li>shareValue \\&lt;string&gt;: The share binary value.</li> <li>hint \\&lt;object&gt;: Hint data that contains the following fields:<ol> <li>trustees \\&lt;list[string]&gt;: A list of all the recovery trustee names associated with this share. These names are only significant to the identity owner. Helps to aid in recovery by providing some metadata for the identity owner and the application.</li> <li>threshold \\&lt;integer&gt;: The minimum number of shares needed to recover the key. Helps to aid in recovery by providing some metadata for the identity owner and the application.</li> </ol> </li> </ol> <pre><code>{\n  \"version\": \"0.1\",\n  \"source_did\": \"did:sov:asbdfa32135\"\n  \"tag\": \"ze4152Bsxo90\",\n  \"shareValue\": \"abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ123456789\"\n  \"hint\": {\n    \"theshold\": 3,\n    \"trustees\": [\"Mike L\", \"Lovesh\", \"Corin\", \"Devin\", \"Drummond\"]\n  }\n}\n</code></pre>"},{"location":"concepts/0074-didcomm-best-practices/","title":"Aries RFC 0074: DIDComm Best Practices","text":"<ul> <li>Authors: Devin Fisher, Daniel Hardman</li> <li>Status: PROPOSED</li> <li>Since: 2019-06-10</li> <li>Status Note: This captures some tribal knowledge from the Indy community. However, it is by no means uniformly accepted inside that group, and it has never been shared in a larger context. Therefore, the RFC is currently fodder for discussion.</li> <li>Start Date: 2019-01-15</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0074-didcomm-best-practices/#summary","title":"Summary","text":"<p>Identifies some conventions that are generally accepted as best practice by developers of DIDComm software. Explains their rationale. This document is a recommendation, not normative.</p>"},{"location":"concepts/0074-didcomm-best-practices/#motivation","title":"Motivation","text":"<p>By design, DIDComm architecture is extremely flexible. Besides adapting well to many platforms, programming languages, and idioms, this let us leave matters of implementation style in the hands of developers. We don't want framework police trying to enforce rigid paradigms.</p> <p>However, some best practices are worth documenting. There is tribal knowledge in the community that represents battle scars. Collaboration is fostered if learning curves don't have to proliferate. Therefore, we offer the following guidelines.</p>"},{"location":"concepts/0074-didcomm-best-practices/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0074-didcomm-best-practices/#normative-language","title":"Normative language","text":"<p>RFCs about protocols and DIDComm behaviors follow commonly understood conventions about normative language, including words like \"MUST\", \"SHOULD\", and \"MAY\". These conventions are documented in IETF's RFC 2119. Existing documents that were written before we clarified our intention to follow these conventions are grandfathered but should be updated to conform.</p>"},{"location":"concepts/0074-didcomm-best-practices/#names","title":"Names","text":"<p>Names show up in lots of places in our work. We name RFCs, ../../concepts defined in those RFCs, protocols, message types, keys in JSON, and much more.</p> <p>The two most important best practices with names are:</p> <ul> <li>Pick descriptive and accurate names. Thoughtfully chosen names can save enormous amounts of commenting and documentation.</li> <li>Be consistent. Particularly within an RFC and especially within the JSON for a set of related messages.</li> <li>For example, don't mix snake_case and other conventions within a single family of DIDComm messages.</li> </ul> <p>These are so common-sense that we won't argue them. But a few other points are worthy of comment.</p>"},{"location":"concepts/0074-didcomm-best-practices/#snake_case-and-variants","title":"snake_case and variants","text":"<p>Nearly all code uses multi-word tokens as names. Different programming ecosystems have different conventions for managing them: <code>camelCase</code>, <code>TitleCase</code>, <code>snake_case</code>, <code>kabob-case</code>, <code>SHOUT_CASE</code>, etc. We want to avoid a religious debate about these conventions, and we want to leave developers the freedom to choose their own styles. However, we also want to avoid random variation that makes it hard to predict the correct form. Therefore, we try to stay idiomatic in the language we're using, and many of our tokens are defined to compare case-insensitive with punctuation omitted, so the differences melt away. This is the case with protocol names and message type names, for example; it means that you should interpret \"TicTacToe\" and \"tic-tac-toe\" and \"ticTacToe\" as being the same protocol. If you are writing a java function for it, by all means use \"ticTacToe\"; if you are writing CSS, by all means use \"tic-tac-toe\".</p> <p>The community tries to use <code>snake_case</code> in JSON key names, even though camelCase is slightly more common. This is not a hard-and-fast rule; in particular, a few constructs from DID Docs leak into DIDComm, and these use the camelCase style that those specs expect. However, it was felt that snake_case was mildly preferable because it didn't raise the questions about acronyms that camelCase does (is it \"zeroOutRAMAlgorithm\", \"zeroOutRamAlgorithm\", or \"zeroOutRAMalgorithm\"?).</p> <p>The main rule to follow with respect to case is: Use the same convention as the rest of the code around you, and in JSON that's intended to be interoperable, use snake_case unless you have a good reason not to. Definitely use the same case conventions as the other keys in the same JSON schema.</p>"},{"location":"concepts/0074-didcomm-best-practices/#pluralization","title":"Pluralization","text":"<p>The names of JSON items that represent arrays should be pluralized whenever possible, while singleton items should not.</p>"},{"location":"concepts/0074-didcomm-best-practices/#terminology-and-notation","title":"Terminology and Notation","text":"<p>Use terms correctly and consistently.</p> <p>The Sovrin Glossary V2 is considered a definitive source of terms. We will probably move it over to Aries at some point as an officially sponsored artifact of this group. RFC 0006: SSI Notation is also a definitive reference.</p> <p>RFCs in general should make every effort to define new terms only when needed, to be clear about the ../../concepts they are labeling, and use prior work consistently. If you find a misalignment in the terminology or notation used by RFCs, please open a github issue.</p>"},{"location":"concepts/0074-didcomm-best-practices/#terseness-and-abbreviations","title":"Terseness and abbreviations","text":"<p>We like obvious abbreviations like \"ipaddr\" and \"inet\" and \"doc\" and \"conn\". We also formally define abbreviations or acronyms for terms and then use the short forms as appropriate.</p> <p>However, we don't value terseness so much that we are willing to give up clarity. Abbreviating \"wallet\" as \"wal\" or \"agent\" as \"ag\" is quirky and discouraged.</p>"},{"location":"concepts/0074-didcomm-best-practices/#rfc-naming","title":"RFC naming","text":"<p>RFCs that define a protocol should be named in the form <code>&lt;do something&gt;-protocol</code>, where <code>&lt;do-something&gt;</code> is a verb phrase like <code>issue-credential</code>, or possibly a noun phrase like <code>did-exchange</code>--something that makes the theme of the protocol obvious. The intent is to be clear; a protocol name like \"connection\" is too vague because you can do lots of things with connections.</p> <p>Protocol RFCs need to be versioned thoughtfully. However, we do not put version numbers in a protocl RFC's folder name. Rather, the RFC folder contains all versions of the protocol, with the latest version documented in README.md, and earlier versions documented in subdocs named according to version, as in <code>version-0.9.md</code> or similar. The main README.md should contain a section of links to previous versions. This allows the most natural permalink for a protocol to be a link to the current version, but it also allows us to link to previous versions explicitly if we need to.</p> <p>RFCs that define a decorator should be named in the form <code>&lt;decorator name&gt;-decorator</code>, as in <code>timing-decorator</code> or <code>trace-decorator</code>.</p>"},{"location":"concepts/0074-didcomm-best-practices/#json","title":"JSON","text":"<p>Json is a very flexible data format. This can be nice, but it can also lead to data modeled in ways that cause a lot of bother for some programming languages. Therefore, we recommend the following choices.</p>"},{"location":"concepts/0074-didcomm-best-practices/#no-variable-type-arrays","title":"No Variable Type Arrays","text":"<p>Every element in an array should be the same data type. This is helpful for statically and strongly typed programming languages that want arrays of something more specific than a base Object class. A violating example:</p> <p><pre><code>[\n   {\n    \"id\":\"324234\",\n    \"data\":\"1/3/2232\"\n   },\n   {\n    \"x_pos\":3251,\n    \"y_pos\":11,\n    \"z_pos\":55\n   }\n]\n</code></pre> Notice that the first object and the second object in the array have no structure in common.</p> <p>Although the benefit of this convention is especially obvious for some programming languages,  it is helpful in all languages to keep parsing logic predictable and reducing branching  cod epaths.</p>"},{"location":"concepts/0074-didcomm-best-practices/#dont-treat-objects-as-associative-arrays","title":"Don't Treat Objects as Associative Arrays","text":"<p>Many loosely typed programming languages conflate the concept of an associative array (dict, map) with the concept of object. In python, for example, an object is just a <code>dict</code> with some syntactic sugar, and python's JSON serialization handles the two interchangeably when serializing.</p> <p>This makes it tempting to do the same thing in JSON. An unhappy example:</p> <pre><code>{\n    \"usage\": {\n        \"194.52.101.254\": 34,\n        \"73.183.146.222\": 55,\n        \"149.233.52.170\": 349\n    }\n}\n</code></pre> <p>Notice that the keys of the <code>usage</code> object are unbounded; as the set of IP addresses grows, the set of keys in <code>usage</code> grows as well. JSON is an \"object notation\", and <code>{...}</code> is a JSON object -- NOT a JSON associative array--but this type of modeling ignores that. If we model data this way, we'll end up with an \"object\" that could have dozens, hundreds, thousands, or millions of keys with identical semantics but different names. That's not how objects are supposed to work.</p> <p>Note as well that the keys here, such as \"192.52.101.254\", are not appropriate identifiers in most programming languages. This means that unless deserialization code maps the keys to keys in an associative array (dict, map), it will not be able to handle the data at all. Also, this way to model the data assumes that we know how lookups will be done (in this case, ipaddr\u2192number); it doesn't leave any flexibility for other access patterns.</p> <p>A better way to model this type of data is as a JSON array, where each item in the array is a tuple of known field types with known field names. This is only slightly more verbose. It allows deserialization to map to one or more lookup data structures per preference, and is handled equally well in strongly, statically typed programming languages and in loosely typed languages:</p> <pre><code>{\n    \"usage\": [\n        { \"ip\": \"194.52.101.254\", \"num\": 34 },\n        { \"ip\": \"73.183.146.222\", \"num\": 55 },\n        { \"ip\": \"149.233.52.170\", \"num\": 349 }\n    ]\n}\n</code></pre>"},{"location":"concepts/0074-didcomm-best-practices/#numeric-field-properties","title":"Numeric Field Properties","text":"<p>Json numeric fields are very flexible. As wikipedia notes in its discussion about JSON numeric primitives:</p> <pre><code>Number: a signed decimal number that may contain a fractional part and may use exponential\nE notation, but cannot include non-numbers such as NaN. The format makes no distinction\nbetween integer and floating-point. JavaScript uses a double-precision floating-point format\nfor all its numeric values, but other languages implementing JSON may encode numbers\ndifferently.\n</code></pre> <p>Knowing that something is a number may be enough in javascript, but in many other programming languages, more clarity is helpful or even required. If the intent is for the number to be a non-negative or positive-only integer, say so when your field is defined in a protocol. If you know the valid range, give it. Specify whether the field is nullable.</p> <p>Per the first guideline above about names, name your numeric fields in a way that makes it clear they are numbers: \"references\" is a bad name in this respect (could be a hyperlink, an array, a string, etc), whereas \"reference_count\" or \"num_of_refs\" is much better.</p>"},{"location":"concepts/0074-didcomm-best-practices/#date-time-conventions","title":"Date Time Conventions","text":"<p>Representing date- and time-related data in JSON is a source of huge variation, since the datatype for the data isn't obvious even before it's serialized. A quick survey of source code across industries and geos shows that dates, times, and timestamps are handled with great inconsistency outside JSON as well. Some common storage types include:</p> <ul> <li>32-bit (signed or unsigned) seconds since epoch (Jan 1, 1970 and Jan 1, 1980 are both used)</li> <li>64-bit 100-nanosecond intervals since Jan 1, 1601</li> <li>Floating-point days and fractions of days since Dec 30, 1899</li> <li>Whole integer days since Jan 1, 1900</li> <li>Floating point scientific time (billions of years since big bang)</li> <li>clock ticks since OS booted</li> <li>milliseconds since OS booted</li> </ul> <p>Of course, many of these datatypes have special rules about their relationship to timezones, which further complicates matters. And timezone handling is notoriously inconsistent, all on its own.</p> <p>Some common names for the fields that store these times include:</p> <ul> <li>&lt;something&gt;Time</li> <li>&lt;something&gt;Date</li> <li>&lt;something&gt;Timestamp</li> <li>&lt;something&gt;Millis or * &lt;something&gt;Ms or &lt;something&gt;Secs</li> </ul> <p>The intent of this RFC is NOT to eliminate all diversity. There are good reasons why these different datatypes exist. However, we would like DIDComm messages to use broadly understood naming conventions that clearly communicate date- and time-related semantics, so that where there is diversity, it's because of different use cases, not just chaos.</p> <p>By convention, DIDComm field suffixes communicate datatype and semantics for date- and time-related ideas, as described below. As we've stressed before, conventions are recommendations only. However:</p> <ol> <li> <p>It is strongly preferred that developers not ignore these perfectly usable conventions unless they have a good reason (e.g., a need to measure the age of the universe in seconds in scientific notation, or a need for ancient dates in a genealogy or archeology use case).</p> </li> <li> <p>Developers should never contradict the conventions. That is, if a developer sees a date- or time-related field that appears to match what's documented here, the assumption of alignment ought to be safe. Divergence should use new conventions, not redefine these.</p> </li> </ol> <p>Field names like \"expires\" or \"lastmod\" are deprecated, because they don't say enough about what to expect from the values. (Is \"expires\" a boolean? Or is it a date/time? If the latter, what is its granularity and format?)</p>"},{"location":"concepts/0074-didcomm-best-practices/#_date","title":"<code>_date</code>","text":"<p>Used for fields that have only date precision, no time component. For example, <code>birth_date</code> or <code>expiration_date</code>. Such fields should be represented as strings in ISO 8601 format (yyyy-mm-dd). They should contain a timezone indicator if and only if it's meaningful (see Timezone Offset Notation).</p>"},{"location":"concepts/0074-didcomm-best-practices/#_time","title":"<code>_time</code>","text":"<p>Used for fields that identify a moment with both date and time precision. For example, <code>arrival_time</code> might communicate when a train reaches the station. The datatype of such fields is a string in ISO 8601 format (yyyy-mm-ddTHH:MM:SS.xxx...) using the Gregorian calendar, and the timezone defaults to UTC. However: * Precision can vary from minute to microsecond or greater. * It is strongly recommended to use the \"Z\" suffix to make UTC   explicit: \"2018-05-27 18:22Z\" * The capital 'T' that separates date from time in ISO 8601 can freely vary with a space. (Many datetime formatters support this variation, for greater readability.) * If local time is needed, Timezone Offset Notation is used.</p>"},{"location":"concepts/0074-didcomm-best-practices/#_sched","title":"<code>_sched</code>","text":"<p>Holds a string that expresses appointment-style schedules such as \"the first Thursday of each month, at 7 pm\". The format of these strings is recommended to follow ISO 8601's Repeating Intervals notation where possible. Otherwise, the format of such strings may vary; the suffix doesn't stipulate a single format, but just the semantic commonality of scheduling.</p>"},{"location":"concepts/0074-didcomm-best-practices/#_clock","title":"<code>_clock</code>","text":"<p>Describes wall time without reference to a date, as in <code>13:57</code>. Uses ISO 8601 formatted strings and a 24-hour cycle, not AM/PM.</p>"},{"location":"concepts/0074-didcomm-best-practices/#_t","title":"<code>_t</code>","text":"<p>Used just like <code>_time</code>, but for unsigned integer seconds since Jan 1, 1970 (with no opinion about whether it's a 32-bit or 64-bit value). Thus, a field that captures a last modified timestamp for a file, as number of seconds since Jan 1, 1970 would be <code>lastmod_t</code>. This suffix was chosen for resonance with Posix's <code>time_t</code> datatype, which has similar semantics.</p>"},{"location":"concepts/0074-didcomm-best-practices/#_tt","title":"<code>_tt</code>","text":"<p>Used just like <code>_time</code> and <code>_t</code>, but for 100-nanosecond intervals since Jan 1, 1601. This matches the semantics of the Windows FILETIME datatype.</p>"},{"location":"concepts/0074-didcomm-best-practices/#_sec-or-subunits-of-seconds-_milli-_micro-_nano","title":"<code>_sec</code> or subunits of seconds (<code>_milli</code>, <code>_micro</code>, <code>_nano</code>)","text":"<p>Used for fields that tell how long something took. For example, a field describing how long a system waited before retry might be named <code>retry_milli</code>. Normally, this field would be represented as an unsigned positive integer.</p>"},{"location":"concepts/0074-didcomm-best-practices/#_dur","title":"<code>_dur</code>","text":"<p>Tells duration (elapsed time) in friendly, calendar based units as a string, using the conventions of ISO 8601's Duration concept. <code>Y</code> = year, <code>M</code> = month, <code>W</code> = week, <code>D</code> = day, <code>H</code> = hour, <code>M</code> = minute, <code>S</code> = second: \"P3Y2M5D11H\" = 3 years, 2 months, 5 days, 11 hours. 'M' can be preceded by 'T' to resolve ambiguity between months and minutes: \"PT1M3S\" = 1 minute, 3 seconds, whereas \"P1M3S\" = 1 month, 3 seconds.</p>"},{"location":"concepts/0074-didcomm-best-practices/#_when","title":"<code>_when</code>","text":"<p>For vague or imprecise dates and date ranges. Fragments of ISO 8601 are preferred, as in \"1939-12\" for \"December 1939\". The token \"to\" is reserved for inclusive ranges, and the token \"circa\" is reserved to make fuzziness explicit, with \"CE\" and \"BCE\" also reserved. Thus, Cleopatra's <code>birth_when</code> might be \"circa 30 BCE\", and the timing of the Industrial Revolution might have a <code>happened_when</code> of \"circa 1760 to 1840\".</p>"},{"location":"concepts/0074-didcomm-best-practices/#timezone-offset-notation","title":"Timezone Offset Notation","text":"<p>Most timestamping can and should be done in UTC, and should use the \"Z\" suffix to make the Zero/Zulu/UTC timezone explicit.</p> <p>However, sometimes the local time and the UTC time for an event are both of interest. This is common with news events that are tied to a geo, as with the time that an earthquake is felt at its epicenter. When this is the case, rather than use two fields, it is recommended to use timezone offset notation (the \"+0800\" in \"2018-05-27T18:22+08:00\"). Except for the \"Z\" suffix of UTC, timezone name notation is deprecated, because timezones can change their definitions according to the whim of local lawmakers, and because resolving the names requires expensive dictionary lookup. Note that this convention is exactly how ISO 8601 handles the timezone issue.</p>"},{"location":"concepts/0074-didcomm-best-practices/#blobs","title":"Blobs","text":"<p>In general, blobs are encoded as base64url strings in DIDComm.</p>"},{"location":"concepts/0074-didcomm-best-practices/#unicode","title":"Unicode","text":"<p>UTF-8 is our standard way to represent unicode strings in JSON and all other contexts. For casual definition, this is sufficient detail.</p> <p>For advanced use cases, it may be necessary to understand subtleties like Unicode normalization forms and canonical equivalence. We generally assume that we can compare strings for equality and sort order using a simple binary algorithm. This is approximately but (in some corner cases) not exactly the same as assuming that text is in NFC normalization form with no case folding expectations and no extraneous surrogate pairs. Where more precision is required, the definition of DIDComm message fields should provide it.</p>"},{"location":"concepts/0074-didcomm-best-practices/#hyperlinks","title":"Hyperlinks","text":"<p>This repo is designed to be browsed as HTML. Browsing can be done directly through github, but we may publish the content using Github Pages and/or ReadTheDocs. As a result, some hyperlink hygiene is observed to make the content as useful as possible:</p> <ul> <li>Hyperlinks (both internal to the repo and external to it) must not be broken.</li> <li>Fragments like <code>#heading-title</code> must correctly reference a real markdown heading.</li> <li>Hyperlinks to an RFC should point to the RFC's README.md rather than to a folder with (possibly) many documents.</li> <li>Hyperlinks from one RFC to another should be in relative form (<code>../../features/my-rfc/README.md</code>), not in absolute form (<code>../../features/my-rfc/README.md</code>) or external form (<code>https://github.com/hyperledger/aries-rfcs/blob/main../../features/my-rfc/README.md</code>). This lets us move or embed the content, and it prevents branch names from cluttering the hyperlink.</li> </ul> <p>These rules are enforced by a unit test that runs <code>code/check_links.py</code>. To run it, go to the root of the repo and run <code>pytest code</code> -- or simply invoke the <code>check_links</code> script directly. Normally, <code>check_links</code> does not test external hyperlinks on the web, because it is too time-consuming; if you want that check, add <code>--full</code> as a command-line argument.</p>"},{"location":"concepts/0074-didcomm-best-practices/#security-considerations","title":"Security Considerations","text":""},{"location":"concepts/0074-didcomm-best-practices/#replay-attacks","title":"Replay attacks","text":"<p>It should be noted that when defining a protocol that has domain specific requirements around preventing replay attacks an <code>@id</code> property SHOULD be required. Given the <code>@id</code> field is most commonly set to be a UUID, it usually provides sufficient randomness that a nonce would in preventing replay attacks. This means that sufficient care will be needed in processing of the <code>@id</code> field however, to make sure the <code>@id</code> field hasn't been used before. In some cases, nonces require being unpredictable as well. In this case, greater review should be taken as to how the <code>@id</code> field should be used in the domain specific protocol. Additionally, in the event where the <code>@id</code> field is not adequate, it's recommended that an additional <code>nonce</code> field be required by the domain specific protocol specification.</p>"},{"location":"concepts/0074-didcomm-best-practices/#reference","title":"Reference","text":"<ul> <li>Discussion of date and time datatypes on Wikipedia</li> <li>ISO 8601</li> <li>Unicode TR 15 on Normalization Forms</li> <li>DIDComm's stance on JSON-LD Compatibility</li> <li>DIDComm localization</li> </ul>"},{"location":"concepts/0074-didcomm-best-practices/#drawbacks","title":"Drawbacks","text":"<p>The main concern with this type of RFC is that it will produce more heat than light -- that is, that developers will debate minutiae instead of getting stuff done. We hope that the conventions here feel reasonable and lightweight enough to avoid that.</p>"},{"location":"concepts/0074-didcomm-best-practices/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>If we weren't using JSON, but rather something like ProtoBuf or MsgPack, datatype handling would probably   require less conventions, but we would still have a similar need.</li> <li>JSON-LD allows some forms of datatype coercion,   but not enough to satisfy all our requirements. It is also considered overly heavy in terms of   parsing and validation dependencies. See DIDComm's stance on JSON-LD Compatibility</li> </ul>"},{"location":"concepts/0074-didcomm-best-practices/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What other conventions do we need?</li> </ul>"},{"location":"concepts/0074-didcomm-best-practices/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0094-cross-domain-messaging/","title":"Aries RFC 0094: Cross-Domain Messaging","text":"<ul> <li>Authors: Stephen Curran</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Socialized and broadly understood in other conceptual RFCs about routing. </li> <li>Supersedes: 0022-Cross-Domain-Messaging</li> <li>Start Date: 2018-08-13</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0094-cross-domain-messaging/#summary","title":"Summary","text":"<p>There are two layers of messages that combine to enable interoperable self-sovereign identity DIDcomm (formerly called Agent-to-Agent) communication. At the highest level are Agent Messages - messages sent between Identities to accomplish some shared goal. For example, establishing a connection between identities, issuing a Verifiable Credential from an Issuer to a Holder or even the simple delivery of a text Instant Message from one person to another. Agent Messages are delivered via the second, lower layer of messaging - encryption envelopes. An encryption envelope is a wrapper (envelope) around an Agent Message to enable the secure delivery of a message from one Agent directly to another Agent. An Agent Message going from its Sender to its Receiver may be passed through a number of Agents, and an encryption envelope is used for each hop of the journey.</p> <p>This RFC addresses Cross Domain messaging to enable interoperability. This is one of a series of related RFCs that address interoperability, including DIDDoc Conventions, Agent Messages and Encryption Envelope. Those RFCs should be considered together in understanding DIDcomm messaging.</p> <p>In order to send a message from one Identity to another, the sending Identity must know something about the Receiver's domain - the Receiver's configuration of Agents. This RFC outlines how a domain MUST present itself to enable the Sender to know enough to be able to send a message to an Agent in the domain.  In support of that, a DIDcomm protocol (currently consisting of just one Message Type) is introduced to route messages through a network of Agents in both the Sender and Receiver's domain. This RFC provides the specification of the \"Forward\" Agent Message Type - an envelope that indicates the destination of a message without revealing anything about the message.</p> <p>The goal of this RFC is to define the rules that domains MUST follow to enable the delivery of Agent messages from a Sending Agent to a Receiver Agent in a secure and privacy-preserving manner.</p>"},{"location":"concepts/0094-cross-domain-messaging/#motivation","title":"Motivation","text":"<p>The purpose of this RFC and its related RFCs is to define a layered messaging protocol such that we can ignore the delivery of messages as we discuss the much richer Agent Messaging types and interactions. That is, we can assume that there is no need to include in an Agent message anything about how to route the message to the Receiver - it just magically happens. Alice (via her App Agent) sends a message to Bob, and (because of implementations based on this series of RFCs) we can ignore how the actual message got to Bob's App Agent.</p> <p>Put another way - these RFCs are about envelopes. They define a way to put a message - any message - into an envelope, put it into an outbound mailbox and have it magically appear in the Receiver's inbound mailbox in a secure and privacy-preserving manner. Once we have that, we can focus on letters and not how letters are sent.</p> <p>Most importantly for Agent to Agent interoperability, this RFC clearly defines the assumptions necessary to deliver a message from one domain to another - e.g. what exactly does Alice have to know about Bob's domain to send Bob a message?</p>"},{"location":"concepts/0094-cross-domain-messaging/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0094-cross-domain-messaging/#core-messaging-goals","title":"Core Messaging Goals","text":"<p>These are vital design goals for this RFC:</p> <ol> <li>Sender Encapsulation: We SHOULD minimize what the Receiver has to know about the domain (routing tree or agent infrastructure) of the Sender in order for them to communicate.</li> <li>Receiver Encapsulation: We SHOULD minimize what the Sender has to know about the domain (routing tree or agent infrastructure) of the Receiver in order for them to communicate.</li> <li>Independent Keys: Private signing keys SHOULD NOT be shared between agents; each agent SHOULD be separately identifiable for accounting and authorization/revocation purposes.</li> <li>Need To Know Information Sharing: Information made available to intermediary agents between the Sender and Receiver SHOULD be minimized to what is needed to perform the agent's role in the process.</li> </ol>"},{"location":"concepts/0094-cross-domain-messaging/#assumptions","title":"Assumptions","text":"<p>The following are assumptions upon which this RFC is predicated.</p>"},{"location":"concepts/0094-cross-domain-messaging/#terminology","title":"Terminology","text":"<p>The following terms are used in this RFC with the following meanings:</p> <ul> <li>Domain - a set of Agents collaborating on behalf of an Identity</li> <li>It's assumed that the Agents of a Domain were developed by a single vendor and so MAY have implementation-specific mechanisms for tracking extra information about one another.</li> <li>An example of two Domains is provided in the image below.</li> <li>Edge Agents - the Agents involved in sending (creating) and receiving (processing) an Agent Message</li> <li>Sender - the Agent sending an original Agent Message</li> <li>Receiver - the Agent intended to receive an Agent Message from the Sender</li> <li>Note: A message MAY pass through many Agents between the Sender and Receiver</li> <li>Domain Endpoint - a physical endpoint for messages into domains that MUST be assumed to be shared across many Identities</li> <li>Shared by many identities (e.g. https://endpoint.agentsRus.com)</li> <li>Agency - the handler for messages sent to the Domain Endpoint.</li> <li>Mediators - agents explicitly known to the sender as part of routing messages to a Receiver.</li> <li>DID - reference to the literal Decentralized ID text</li> <li>e.g. did:sov:1234abcd</li> <li>DID#keyname - reference to the DID appended with \"#\" and a specific key from the DIDDoc</li> <li>e.g. did:sov:1234abcd#1 references key \"1\" of the \"did:sov:1234abcd\" DIDDoc.</li> <li>Note: The #keyname is NOT the actual Public Key - it's a reference to an entry in the DIDDoc that contains the Public Key.</li> </ul>"},{"location":"concepts/0094-cross-domain-messaging/#diddoc","title":"DIDDoc","text":"<p>The term \"DIDDoc\" is used in this RFC as it is defined in the DID Specification:</p> <ul> <li>a collection of public keys and endpoints,</li> <li>controlled by an identity,</li> <li>associated with a DID, and</li> <li>used for a relationship.</li> </ul> <p>A DID can be resolved to get its corresponding DIDDoc by any Agent that needs access to the DIDDoc. This is true whether talking about a DID on a Public Ledger, or a pairwise DID (using the did:peer method) persisted only to the parties of the relationship. In the case of pairwise DIDs, it's the (implementation specific) domain's responsibility to ensure such resolution is available to all Agents requiring it within the domain.</p>"},{"location":"concepts/0094-cross-domain-messaging/#messages-are-private","title":"Messages are Private","text":"<p>Agent Messages sent from a Sender to a Receiver SHOULD be private. That is, the Sender SHOULD encrypt the message with a public key for the Receiver. Any agent in between the Sender and Receiver will know only to whom the message is intended (by DID and possibly keyname within the DID), not anything about the message.</p>"},{"location":"concepts/0094-cross-domain-messaging/#the-sender-knows-the-receiver","title":"The Sender Knows The Receiver","text":"<p>This RFC assumes that the Sender knows the Receiver's DID and, within the DIDDoc for that DID, the keyname to use for the Receiver's Agent. How the Sender knows the DID and keyname to send the message is not defined within this RFC - that is a higher level concern.</p> <p>The Receiver's DID MAY be a public or pairwise DID, and MAY be on a Public Ledger or only shared between the parties of the relationship.</p>"},{"location":"concepts/0094-cross-domain-messaging/#example-domain-and-diddoc","title":"Example: Domain and DIDDoc","text":"<p>The following is an example of an arbitrary pair of domains that will be helpful in defining the requirements in this RFC.</p> <p></p> <p>In the diagram above:</p> <ul> <li>Alice has</li> <li>1 Edge Agent - \"1\"</li> <li>1 Routing Agent - \"2\"</li> <li>1 Domain Endpoint - \"8\"</li> <li>Bob has</li> <li>3 Edge Agents - \"4\", \"5\" and \"6\"<ul> <li>\"6\" is an Edge Agent in the cloud, \"4\" and \"5\" are physical devices.</li> </ul> </li> <li>1 Routing Agent - \"3\"</li> <li>1 Domain Endpoint - \"9\"</li> </ul>"},{"location":"concepts/0094-cross-domain-messaging/#bobs-did-for-his-relationship-with-alice","title":"Bob's DID for his Relationship with Alice","text":"<p>Bob\u2019s domain has 3 devices he uses for processing messages - two phones (4 and 5) and a cloud-based agent (6). However, in Bob's relationship with Alice, he ONLY uses one phone (4) and the cloud-based agent (6). Thus the key for device 5 is left out of the DIDDoc (see below).</p> <p>Note that the keyname for the Routing Agent (3) is called \"routing\". This is an example of the kind of convention needed to allow the Sender's agents to know the keys for Agents with a designated role in the receiving domain - as defined in the <code>DIDDoc Conventions</code> RFC.</p> <pre><code>{\n  \"@context\": \"https://w3id.org/did/v1\",\n  \"id\": \"did:sov:1234abcd\",\n  \"publicKey\": [\n    {\"id\": \"routing\", \"type\": \"RsaVerificationKey2018\",  \"owner\": \"did:sov:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC X\u2026\"},\n    {\"id\": \"4\", \"type\": \"RsaVerificationKey2018\",  \"owner\": \"did:sov:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC 9\u2026\"},\n    {\"id\": \"6\", \"type\": \"RsaVerificationKey2018\",  \"owner\": \"did:sov:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC A\u2026\"}\n  ],\n  \"authentication\": [\n    {\"type\": \"RsaSignatureAuthentication2018\", \"publicKey\": \"did:sov:1234abcd#4\"}\n  ],\n  \"service\": [\n    {\n      \"id\": \"did:example:123456789abcdefghi;did-communication\",\n      \"type\": \"did-communication\",\n      \"priority\" : 0,\n      \"recipientKeys\" : [ \"did:example:1234abcd#4\" ],\n      \"routingKeys\" : [ \"did:example:1234abcd#3\" ],\n      \"serviceEndpoint\" : \"did:example:xd45fr567794lrzti67;did-communication\"\n    }\n  ]\n}\n</code></pre> <p>For the purposes of this discussion we are defining the message flow to be:</p> <p>1 \u2192 2 \u2192 8 \u2192 9 \u2192 3 \u2192 4</p> <p>However, that flow is arbitrary and only one hop is actually required:</p> <ul> <li>1 is the Sender in this case and so must send the first message.</li> <li>4 is the Receiver in this case and so must receive the message.</li> </ul>"},{"location":"concepts/0094-cross-domain-messaging/#encryption-envelopes","title":"Encryption Envelopes","text":"<p>An encryption envelope is used to transport any Agent Message from one Agent directly to another. In our example message flow above, there are five encryption envelopes sent, one for each hop in the flow. The separate Encryption Envelope RFC covers those details.</p>"},{"location":"concepts/0094-cross-domain-messaging/#agent-message-format","title":"Agent Message Format","text":"<p>An Agent Message defines the format of messages processed by Agents. Details about the general form of Agent Messages can be found in the Agent Messages RFC.</p> <p>This RFC specifies (below) the \"Forward\" message type, a part of the \"Routing\" family of Agent Messages.</p>"},{"location":"concepts/0094-cross-domain-messaging/#did-diddoc-and-routing","title":"DID, DIDDoc and Routing","text":"<p>A DID owned by the Receiver is resolvable by the Sender as a DIDDoc using either a Public Ledger or using pairwise DIDs based on the <code>did:peer</code> method. The related DIDcomm DIDDoc Conventions RFC defines the required contents of a DIDDoc created by the receiving entity. Notably, the DIDDoc given to the Sender by the Receiver specifies the required routing of the message through an optional set of mediators.</p>"},{"location":"concepts/0094-cross-domain-messaging/#cross-domain-interoperability","title":"Cross Domain Interoperability","text":"<p>A key goal for interoperability is that we want other domains to know just enough about the configuration of a domain to which they are delivering a message, but no more. The following walks through those minimum requirements.</p>"},{"location":"concepts/0094-cross-domain-messaging/#required-the-did-and-diddoc","title":"Required: The DID and DIDDoc","text":"<p>As noted above, the Sender of an Agent to Agent Message has the DID of the Receiver, and knows the key(s) from the DIDDoc to use for the Receiver's Agent(s).</p> <p>Example: Alice wants to send a message from her phone (1) to Bob's phone (4). She has Bob's B:did@A:B, the DID/DIDDoc Bob created and gave to Alice to use for their relationship. Alice created A:did@A:B and gave that to Bob, but we don't need to use that in this example. The content of the DIDDoc for B:did@A:B is presented above.</p>"},{"location":"concepts/0094-cross-domain-messaging/#required-end-to-end-encryption-of-the-agent-message","title":"Required: End-to-End encryption of the Agent Message","text":"<p>The Agent Message from the Sender SHOULD be hidden from all Agents other than the Receiver. Thus, it SHOULD be encrypted with the public key of the Receiver. Based on our assumptions, the Sender can get the public key of the Receiver agent because they know the DID#keyname string, can resolve the DID to the DIDDoc and find the public key associated with DID#keyname in the DIDDoc. In our example above, that is the key associated with \"did:sov:1234abcd#4\".</p> <p>Most Sender-to-Receiver messages will be sent between parties that have shared pairwise DIDs (using the <code>did:peer</code> method). When that is true, the Sender will (usually) AuthCrypt the message. If that is not the case, or for some other reason the Sender does not want to AuthCrypt the message, AnonCrypt will be used. In either case, the Indy-SDK <code>pack()</code> function handles the encryption.</p> <p>If there are mediators specified in the DID service endpoint for the Receiver agent, the Sender must wrap the message for the Receiver in a 'Forward' message for each mediator. It is assumed that the Receiver can determine the from <code>did</code> based on the <code>to</code> DID (or the sender's verkey) using their pairwise relationship.</p> <pre><code>{\n  \"@type\" : \"https://didcomm.org/routing/1.0/forward\",\n  \"@id\": \"54ad1a63-29bd-4a59-abed-1c5b1026e6fd\",\n  \"to\"   : \"did:sov:1234abcd#4\",\n  \"msg\"  : { json object from &lt;pack(AgentMessage,valueOf(did:sov:1234abcd#4), privKey(A.did@A:B#1))&gt; }\n}\n</code></pre> <p>Notes</p> <ul> <li>the <code>@type</code> value is in the precise URI format for the \"forward\" message type</li> <li>Indy-SDK's \"pack\" function is used to AuthCrypt the message using the Receiver's public key and the Sender's private key.</li> <li>If the Sender wishes to remain anonymous or knows the Receiver does not know the Sender's public key, AnonCrypt is used.</li> <li>More details about the Indy-SDK <code>pack()</code> function can be found in the Encryption Envelope RFC.</li> <li>The Indy-SDK's \"unpack()\" function MUST return the public key of the private key used to sign the message. See the note below for the background on this.</li> <li>Additional <code>forward</code> messages are created to wrap each forward for each mediator.</li> </ul> <p>The bullet above about the unpack() function returning the signer's public key deserves some additional attention. The Receiver of the message knows from the \"to\" field the DID to which the message was sent. From that, the Receiver is expected to be able to determine the DID of the Sender, and from that, access the Sender's DIDDoc. However, knowing the DIDDoc is not enough to know from whom the message was sent - which key was used to send the message, and hence, which Agent controls the Sending private key. This information MUST be made known to the Receiver (from unpack()) when AuthCrypt is used so that the Receiver knows which key was used to the send the message and can, for example, use that key in responding to the arriving Message.</p> <p>The Sender can now send the Forward Agent Message on its way via the first of the encryption envelope. In our example, the Sender sends the Agent Message to 2 (in the Sender's domain), who in turn sends it to 8. That of course, is arbitrary - the Sender's Domain could have any configuration of Agents for outbound messages. The Agent Message above is passed unchanged, with each Agent able to see the <code>@type</code>, <code>to</code> and <code>msg</code> fields as described above. This continues until the outer <code>forward</code> message gets to the Receiver's first mediator or the Receiver's agent (if there are no mediators). Each agent decrypts the received encrypted envelope and either forwards it (if a mediator) or processes it (if the Receiver Agent). Per the Encryption Envelope RFC, between Agents the Agent Message is pack()'d and unpack()'d as appropriate or required.</p> <p>The diagram below shows an example use of the <code>forward</code> messages to encrypt the message all the way to the Receiver with two mediators in between - a shared domain endpoint (aka https://agents-r-us.com) and a routing agent owned by the receiving entity.</p> <p></p>"},{"location":"concepts/0094-cross-domain-messaging/#required-cross-domain-encryption","title":"Required: Cross Domain Encryption","text":"<p>While within a domain the Agents MAY choose to use encryption or not when sending messages from Agent to Agent, encryption MUST be used when sending a message into the Receiver's domain. The endpoint agent unpack()'s the encryption envelope and processes the message - usually a <code>forward</code>. Note that within a domain, the agents may use arbitrary relays for messages, unknown to the sender. How the agents within the domain knows where to send the message is implementation specific - likely some sort of dynamic DID-to-Agent routing table. If the path to the receiving agent includes mediators, the message must go through those mediators in order (for example, through 3 in our example) as the message being forwarded has been encrypted for the mediators.</p>"},{"location":"concepts/0094-cross-domain-messaging/#required-mediators-process-forward-messages","title":"Required: Mediators Process Forward Messages","text":"<p>When a mediator (eventually) receives the message, it determines it is the target of the (current) outer forward Agent Message and so decrypts the message's <code>msg</code> value to reveal the inner \"Forward\" message.  Mediators use their (implementation specific) knowledge to map from the <code>to</code> field to deliver the message to the physical endpoint of the next agent to process the message on it's way to the Receiver.</p>"},{"location":"concepts/0094-cross-domain-messaging/#required-the-receiver-app-agent-decryptsprocesses-the-agent-message","title":"Required: The Receiver App Agent Decrypts/Processes the Agent Message","text":"<p>When the Receiver Agent receives the message, it determines it is the target of the forward message, decrypts the payload and processes the message.</p>"},{"location":"concepts/0094-cross-domain-messaging/#exposed-data","title":"Exposed Data","text":"<p>The following summarizes the information needed by the Sender's agents:</p> <ul> <li>The DID to use for the relationship, and its related DIDDoc</li> <li>A public key entry for the Receiver agent</li> <li>From the DIDDoc, a service entry for each Receiver agent that includes:</li> <li>a public DID or physical endpoint and public key for the endpoint agent.</li> <li>An optional order list of public keys (<code>RoutingKeys</code>) of mediators used by the Receiver in delivering the message.</li> </ul> <p>The DIDDoc will have a public key entry for each additional Agent message Receiver and each mediator.</p> <p>In many cases, the entry for the endpoint agent should be a public DID, as it will likely be operated by an agency (for example, https://agents-r-us.com) rather than by the Receiver entity (for example, a person). By making that a public DID in that case, the agency can rotate its public key(s) for receiving messages in a single operation, rather than having to notify each identity owner and in turn having them update the public key in every pairwise DID that uses that endpoint.</p>"},{"location":"concepts/0094-cross-domain-messaging/#data-not-exposed","title":"Data Not Exposed","text":"<p>Given the sequence specified above, the following data is NOT exposed to the Sender's agents:</p> <ul> <li>The relays within the Receiver's domain</li> <li>Receiver agents the identity chooses not to include in a given DIDDoc</li> <li>The physical endpoints of agents within the Receiver's domain (other than the Domain Endpoint)</li> <li>The physical endpoints and, as required, associated public keys, are shared as needed by the agents within the Receiver's domain.</li> </ul>"},{"location":"concepts/0094-cross-domain-messaging/#message-types","title":"Message Types","text":"<p>The following Message Types are defined in this RFC.</p>"},{"location":"concepts/0094-cross-domain-messaging/#corerouting10forward","title":"Core:Routing:1.0:Forward","text":"<p>The core message type \"forward\", version 1.0 of the \"routing\" family is defined in this RFC. An example of the message is the following:</p> <pre><code>{\n  \"@type\" : \"https://didcomm.org/routing/1.0/forward\",\n  \"@id\": \"54ad1a63-29bd-4a59-abed-1c5b1026e6fd\",\n  \"to\"   : \"did:sov:1234abcd#4\",\n  \"msg\"  : { json object from &lt;pack(AgentMessage,valueOf(did:sov:1234abcd#4), privKey(A.did@A:B#1))&gt; }\n}\n</code></pre> <p>The <code>to</code> field is required and takes one of two forms:</p> <ul> <li>A DID without a key reference (e.g. <code>did:sov:1234abcd</code>)</li> <li>A DID with a key reference (e.g. <code>did:sov:1234abcd#4</code>)</li> </ul> <p>The first form is used when sending forward messages across one or more agents that do not need to know the details of a domain. The Receiver of the message is the designated <code>Routing Agent</code> in the Receiver Domain, as it controls the key used to decrypt messages sent to the domain, but not to a specific Agent.</p> <p>The second form is used when the precise key (and hence, the Agent controlling that key) is used to encrypt the Agent Message placed in the <code>msg</code> field.</p> <p>The <code>msg</code> field calls the Indy-SDK <code>pack()</code> function to encrypt the Agent Message to be forwarded. The Sender calls the <code>pack()</code> with the suitable arguments to AnonCrypt or AuthCrypt the message. The <code>pack()</code> and <code>unpack()</code> functions are described in more detail in the Encryption Envelope RFC.</p>"},{"location":"concepts/0094-cross-domain-messaging/#reference","title":"Reference","text":"<p>See the other RFCs referenced in this document:</p> <ul> <li>DIDcomm</li> <li>Encryption Envelope</li> <li>Agent Messages</li> <li>DIDDoc Conventions</li> </ul>"},{"location":"concepts/0094-cross-domain-messaging/#drawbacks","title":"Drawbacks","text":"<p>N/A</p>"},{"location":"concepts/0094-cross-domain-messaging/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>A number of discussions were held about this RFC. In those discussions, the rationale for the RFC evolved into the text, and the alternatives were eliminated. See prior versions of the superseded HIPE (in status section, above) for details.</p> <p>A suggestion was made that the following optional parameters could be defined in the \"routing/1.0/forward\" message type:</p> <ul> <li>forward-after: specify that the message should not be forwarded until the system clock shows a particular time, or until a particular interval has elapsed. This could be useful to defeat timing correlations. Particular agents might not support it.</li> <li>mix-config: artificially introduce extra hops to obscure path (use a mix network like TOR)</li> </ul> <p>The optional parameters have been left off for now, but could be added in this RFC or to a later version of the message type.</p>"},{"location":"concepts/0094-cross-domain-messaging/#prior-art","title":"Prior art","text":"<p>N/A</p>"},{"location":"concepts/0094-cross-domain-messaging/#unresolved-questions","title":"Unresolved questions","text":"<p>N/A</p>"},{"location":"concepts/0094-cross-domain-messaging/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0103-indirect-identity-control/","title":"Aries RFC 0103: Indirect Identity Control","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: PROPOSED</li> <li>Since: 2019-06-04</li> <li>Status Note: Currently under study for implementation in various pilots and POCs. See, for example, the Sovrin Foundation's Guardianship Task Force.</li> <li>Start Date: 2019-05-10</li> <li>Tags: concept, credentials</li> </ul>"},{"location":"concepts/0103-indirect-identity-control/#summary","title":"Summary","text":"<p>Compares and contrasts three forms of indirect identity control that have much in common and that should be explored together: delegation, guardianship, and controllership. Recommends mechanisms that allow identity technology to model each with flexibility, precision, and safety. These recommendations can be applied to many decentralized identity and credentialing ecosystems--not just to the ones best known in Hyperledger circles. </p>"},{"location":"concepts/0103-indirect-identity-control/#motivation","title":"Motivation","text":"<p>In most situations, we expect identity owners to directly control their own identities. This is the ideal that gives \"self-sovereign identity\" its name. However, control is not so simple in many situations:</p> <ul> <li> <p>A corporation is governed by a Board of Directors, executives, and employees with multiple levels of delegated authority. The control relationships are dynamic and complex. (delegation)</p> </li> <li> <p>Parents typically manage the identities of their young children. Adult children may need to exercise the identity of a parent with dementia, or of a parent who recently passed away. (guardianship)</p> </li> <li> <p>A self-driving car may be capable of many independent actions, but behind such a smart device must be a human entity that takes legal responsibility. (controllership)</p> </li> </ul> <p>We need to understand how such situations color the interactions we have in an identity ecosystem.</p>"},{"location":"concepts/0103-indirect-identity-control/#tutorial","title":"Tutorial","text":"<p>Although the Sovrin Foundation advocates a specific approach to verifiable credentials, its glossary offers a useful analysis of indirect identity control that applies to any approach. Appendix C of the Sovrin Glossary V2 defines three forms of indirect identity control relationship--delegation, guardianship, controllership--matching the three bulleted examples above. Reviewing that document is highly recommended. It is the product of careful collaboration by experts in many fields, includes useful examples, and is clear and thorough.</p> <p>Here, we will simply reproduce two diagrams as a summary:</p> <p></p> <p></p> <p>Note: The type of delegation described in Appendix C, and the type we focus on in this doc, is one that crosses identity boundaries. There is another type that happens within an identity, as Alice delegates work to her various agents. For the time being, ignore this intra-identity delegation; it is explored more carefully near the end of the Delegation Details doc.</p>"},{"location":"concepts/0103-indirect-identity-control/#commonalities","title":"Commonalities","text":"<p>All of these forms of identity control share the issue of indirectness. All of them introduce risks beyond the ones that dominate in direct identity management. All of them complicate information flows and behavior. And they are inter-related; guardians and controllers often need to delegate, delegates may become controllers, and so forth.</p> <p>The solutions for each ought to have much in common, too--and that is the case. These forms of indirect identity control use similarly structured credentials in similar ways, in the context of similarly structured trust frameworks. Understanding and implementing support for one of them should give developers and organizations a massive headstart in implementing the others.</p> <p>Before we provide details about solutions, let's explore what's common and unique about each of the three forms of indirect identity control. </p>"},{"location":"concepts/0103-indirect-identity-control/#compare-and-contrast","title":"Compare and Contrast","text":""},{"location":"concepts/0103-indirect-identity-control/#delegation","title":"Delegation","text":"<p>Delegation can be either transparent or opaque, depending on whether it's obvious to an external party that a delegate is involved. A lawyer that files a court motion in their own name, but on behalf of a client, is a transparent delegate. A nurse who transcribes a doctor's oral instructions may be performing record-keeping as an opaque delegate, if the nurse is unnamed in the record.</p> <p>Transparent delegation is safer and provides a better audit trail than opaque delegation. It is closer to the ethos of self-sovereign identity. However, opaque delegation is a fact of life; sometimes a CEO wants her personal assistant to send a note or meeting invitation in a way that impersonates rather than explicitly representing her.</p> <p>Delegation needs constraints. These can take many forms, such as:</p>"},{"location":"concepts/0103-indirect-identity-control/#constraints","title":"Constraints","text":"<ul> <li>Time (for what period(s) delegate has that status)</li> <li>Place (in what physical or virtual locations delegate is approved)</li> <li>Function (legal vs. medical vs. educational)</li> <li>Circumstances (for particular event(s))</li> <li>Biometrics (for delegator involvement)</li> <li>Relationships (who delegate can interact with)</li> <li>Attributes (data/credentials -- what delegate can know or prove about delegator)</li> <li>Agents (what software/devices delegate can use)</li> <li>Cooperation (act as delegate with joint approval of other delegates)</li> <li>Oversight (audit trail, reporting)</li> </ul> <p>Delegation needs to be revokable.</p> <p>Delegates should not mix identity data for themselves with data that may belong to the delegator.</p> <p>The rules of how delegation work need to be spelled out in a trust framework.</p> <p>Sometimes, the indirect authority of a delegate should be recursively extensible (allow sub-delegation). Other times, this may be inappropriate.</p> <p>Use cases and other specifics of delegation are explored in greater depth in the Delegation Details doc.</p>"},{"location":"concepts/0103-indirect-identity-control/#guardianship","title":"Guardianship","text":"<p>Guardianship has all the bolded properties of delegation: transparent or opaque styles, constraints, revocation, the need to not mix identity data, the need for a trust framework, and the potential for recursive extensibility. It also adds some unique considerations.</p> <p>Since guardianship does not always derive from dependent consent (that is, the dependent is often unable to exercise sovereignty), the dependent in a guardianship relationship is particularly vulnerable to abuse from within.</p> <p></p> <p>Because of this risk, guardianship is the most likely of the three forms of indirect control to require an audit trail and to involve legal formalities. Its trust frameworks are typically the most nuanced and complex.</p> <p>Guardianship is also the form of indirect identity control with the most complications related to privacy.</p> <p>Guardianship must have a rationale -- a justification that explains why the guardian has that status. Not all rationales are equally strong; a child lacking an obvious parent may receive a temporary guardian, but this guardian's status could change if a parent is found. Having a formal rationale allows conflicting guardianship claims to be adjudicated.</p> <p></p> <p>Either the guardian role or specific guardianship duties may be delegated. An example of the former is when a parent leaves on a long, dangerous trip, and appoints a grandparent to be guardian in their absence. An example of the latter is when a parent asks a grandparent to drive a child to the school to sign up for the soccer team. When the guardian role is delegated, the result is a new guardian. When only guardianship duties are delegated, this is simple delegation and ceases to be guardianship.</p> <p>Use cases and other specifics of guardianship are explored in greater depth in the Guardianship Details doc.</p>"},{"location":"concepts/0103-indirect-identity-control/#controllership","title":"Controllership","text":"<p>Controllership shares nearly all bolded ../../features with delegation. It is usually transparent because things are usually known not to be identity owners in their interactions, and things are assumed not to control themselves.</p> <p>Like guardianship, controllership has a rationale. Usually, it is rooted in property ownership, but occasionally it might derive from court appointment. Also like guardianship, either the role or specific duties of controllership may be delegated. When controllership involves animals instead of machines, it may have risks of abuse and complex protections and trust frameworks.</p> <p>Unlike guardianship, controlled things usually require minimal privacy. However, things that constantly identify their controller(s) in a correlatable fashion may undermine the privacy of controllers in ways that are unexpected.</p> <p>Use cases and other specifics of controllership are explored in greater depth in the Controllership Details doc.</p>"},{"location":"concepts/0103-indirect-identity-control/#solution","title":"Solution","text":"<p>We recommend that all three forms of indirect identity control be modeled with some common ingredients:</p> <ul> <li> <p>A proxy trust framework that specifies the rules and conventions in force for a particular class of indirect identity control use cases.</p> </li> <li> <p>A proxy credential that binds a controlled entity to its proxy and clarifies the nature and limits of the control for that specific relationship.</p> </li> <li> <p>A proxy challenge that evaluates the proxy credential in a particular context, proving or disproving the legitimacy of indirect control and creating opportunities for auditing and enforcement.</p> </li> </ul> <p>Here, \"proxy\" is used as a generic cover term for all three forms of indirect identity control. Each ingredient has a variant for each form (e.g., delegate credential, guardian credential, controller credential), and they have minor differences. However, they work so similarly that they'll be described generically, with differences noted where necessary.</p>"},{"location":"concepts/0103-indirect-identity-control/#proxy-trust-framework","title":"Proxy Trust Framework","text":"<p>A proxy trust framework is a published, versioned document (or collection of documents) that's accessible by URI. Writing one doesn't have to be a massive undertaking; see the sample guardianship trust framework for a simple example).</p> <p>It should answer at least the following questions:</p> <ol> <li> <p>What is the trust framework's formal name, version, and URI? (The name cannot include a <code>/</code> character due to how it's paired with version in credential <code>type</code> fields. The version must follow semver rules.)</p> </li> <li> <p>In what geos and legal jurisdictions is it valid?</p> </li> <li> <p>On what rationales are proxies appointed? (For guardianship, these might include values like <code>kinship</code> and <code>court_order</code>. Each rationale needs to be formally defined, named, and published at a URI, because proxy credentials will reference them. This question is mostly irrelevant to delegation, where the rationale is always an action of the delegator.)</p> </li> <li> <p>What are the required and recommended behaviors of a proxy (holder), issuer, and verifier? How will this be enforced?</p> </li> <li> <p>What permissions vis-a-vis the proxied identity govern proxy actions? (For a delegate, these might include values like <code>sign</code>, <code>pay</code>, or <code>arrange_travel</code>. For a guardian, these might include values like <code>financial</code>, <code>medical</code>, <code>do_not_resuscitate</code>, <code>foreign_travel</code>, or <code>new_relationships</code>. Like rationales, permissions need to be formally defined and referencable by URI.)</p> </li> <li> <p>What are possible constraints on a proxy? (Constraints are bound to particular proxies, whereas a permission model is bound to the identity that the proxy is controlling; this distinction will make more sense in an example. Some constraints might include <code>geo_radius</code>, <code>jurisdiction</code>, <code>biometric_consent_freshness</code>, and so forth. These values also need to be formally defined and referencable by URI.)</p> </li> <li> <p>What auditing mechanisms are required, recommended, or allowed?</p> </li> <li> <p>What appeal mechanisms are required or supported?</p> </li> <li> <p>What proxy challenge procedures are best practice?</p> </li> <li> <p>What freshness rules are used for revocation testing and offline mode?</p> </li> </ol>"},{"location":"concepts/0103-indirect-identity-control/#proxy-credential","title":"Proxy Credential","text":"<p>A proxy credential conforms to the Verifiable Credential Data Model 1.0. It can use any style of proof or data format (JSON-LD, JWT, Sovrin ZKP, etc). It is recognizable as a proxy credential by the following characteristics:</p> <ol> <li> <p>Its <code>@context</code> field, besides including the \"https://www.w3.org/2018/credentials/v1\" required of all VCs, also includes a reference to this spec: \"https://github.com/hyperledger/aries-rfcs../../concepts/0103-indirect-identity-control\".</p> </li> <li> <p>Its <code>type</code> field contains, in addition to \"VerifiableCredential\", a string in the format:</p> <p></p> <p>...where <code>form</code> is one of the letters D (for Delegation), G (for Guardianship), or C (for controllership), <code>trust framework</code> is the name that a Proxy Trust Framework formally declares for itself, <code>tfver</code> is its version, and <code>variant</code> is a specific schema named in the trust framework. A regex that matches this pattern is: <code>Proxy\\.([DGC])/([^/]+)/(\\d+[^/]*)/(.+)</code>, and an example of a matching string is: <code>Proxy.G/UNICEF Vulnerable Populations Trust Framework/1.0/ChildGuardian</code>.</p> </li> <li> <p>The metadata fields for the credential include <code>trustFrameworkURI</code> (the value of which is a URI linking to the relevant trust framework), <code>auditURI</code> (the value of which is a URI linking to a third-party auditing service, and which may be constrained or empty as specified in the trust framework), and <code>appealURI</code> (the value of which is a URI linking to an arbitration or adjudication authority for the credential, and which may be constrained or empty as specified in the trust framework).</p> </li> <li> <p>The <code>credentialSubject</code> section of the credential describes a subject called <code>holder</code> and a subject called <code>proxied</code>. The holder is the delegate, guardian, or controller; the proxied is the delegator, dependent, or controlled thing.</p> </li> <li> <p><code>credentialSubject.holder.type</code> must be a URI pointing to a schema for <code>credentialSubject.holder</code> as defined in the trust framework. The schema must include the following fields:</p> <ul> <li> <p><code>role</code>: A string naming the role that the holder plays in the permissioning scheme of the dependent. These roles must be formally defined in the trust framework. For example, a guardian credential might identify the holder (guardian) as playing the <code>next_of_kin</code> role, and this <code>next_of_kin</code> role might be granted a subset of all permissions that are possible for the dependent's identity. A controllership credential for a drone might identify the holder (controller) as playing the <code>pilot</code> role, which has different permissions from the <code>maintenance_crew</code> role.</p> </li> <li> <p><code>rationaleURI</code>: Required for guardian credentials, optional for the other types. This links to a formal definition in the trust framework of a justification for holding identity control status. For guardians, the rationaleURI might point to a definition of the <code>blood_relative</code> or <code>tribal_member</code> rationale, for example. For controllers, the rationaleURI might point to a definition of <code>legal_appointment</code> or <code>property_owner</code>.</p> </li> </ul> <p>The schema may also include zero or more <code>credentialSubject.holder.constraint.*</code> fields. These fields would be used to limit the time, place, or circumstances in which the proxy may operate.</p> </li> <li> <p><code>credentialSubject.proxied.type</code> must be a URI pointing to a schema for <code>credentialSubject.proxied</code> as defined in the trust framework. The schema must include a <code>permissions</code> field. This field contains an array of SGL rules, each of which is a JSON object in the form:</p> <pre><code>{\"grant\": privileges, \"when\": condition}\n</code></pre> <p>A complete example for a guardianship use case is provided in the SGL tutorial.</p> </li> <li> <p>The credential MAY or MUST contain additional fields under <code>credentialSubject.holder</code> that describe the holder (e.g., the holder's name, DID, biometric, etc.). If the credential is based on ZKP/link secret technologies, then these may be unnecessary, because the holder can bind their proxy credential to other credentials that prove who they are. If not, then the credential MUST contain such fields.</p> </li> <li> <p>The credential MUST contain additional fields under <code>credentialSubject.proxied</code> that describe the proxied identity (e.g., a dependent's name or biometric; a pet's RFID tag; a drone's serial number).</p> </li> </ol>"},{"location":"concepts/0103-indirect-identity-control/#proxy-challenge","title":"Proxy Challenge","text":"<p>A proxy challenge is an interaction in which the proxy must justify the control they are exerting over the proxied identity. The heart of the challenge is a request for a verifiable presentation based on a proxy credential, followed by an evaluation of the evidence. This evaluation includes traditional credential verification, but also a comparison of a proxy's role (<code>credentialSubject.holder.role</code>) to permissions (<code>credentialSubject.proxied.permissions</code>), and a comparison of circumstances to constraints (<code>credentialSubject.holder.constraints.*</code>). It may also involve the creation of an audit trail, depending on the value of the <code>auditURI</code> field.</p> <p>During the verifiable presentation, the holder MUST disclose all of the following fields:</p> <ul> <li><code>@context</code></li> <li><code>type</code></li> <li><code>issuanceDate</code> (if present in schema)</li> <li><code>expirationDate</code> (if present in schema)</li> <li><code>credentialStatus</code> (if present in schema)</li> <li><code>issuer</code></li> <li><code>trustFramework</code></li> <li><code>auditURI</code></li> <li><code>appealURI</code></li> <li><code>credentialSubject.holder.type</code></li> <li><code>credentialSubject.holder.role</code></li> <li><code>credentialSubject.holder.rationaleURI</code></li> <li><code>credentialSubject.holder.constraints.*</code></li> <li><code>credentialSubject.proxied.type</code></li> <li><code>credentialSubject.proxied.permissions</code></li> </ul> <p>In addition, the holder MUST prove that the proxy is the intended holder of the credential, to whatever standard is required by the trust framework. This can be done by disclosing additional fields under <code>credentialSubject.holder</code>, or by proving things about the holder in zero knowledge, if the credential supports ZKPs. In the latter case, proofs about the holder could also come from other credentials in the holder's possession, linked to the proxy credential through the link secret.</p> <p>The holder MUST also prove that the proxied identity is correct, to whatever standard is required by the trust framework. This can be done by disclosing additional fields under <code>credentialSubject.proxied</code>, or by proving things about the subject in zero knowledge.</p> <p>[TODO: discuss moments when proxy challenges may be vital; see https://docs.google.com/presentation/d/1aq45aUHTOK_WhFEICboXQrp7dalpLm9-MGg77Nsn50s/edit#slide=id.g59fffee7a0_0_39 ]</p> <p>[TODO: discuss offline mode, freshness, and revocation]</p>"},{"location":"concepts/0103-indirect-identity-control/#reference","title":"Reference","text":"<p>A complete sample of a guardianship trust framework and credential schema are attached for reference. Please also see the details about each form of indirect identity control:</p> <ul> <li>Delegation Details</li> <li>Guardianship Details</li> <li>Controllership Details</li> </ul>"},{"location":"concepts/0103-indirect-identity-control/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0103-indirect-identity-control/controllership-details/","title":"Controllership Details","text":"<ul> <li>How controlled things can undermine privacy</li> <li>controllership and delegation</li> <li>Ethical considerations and the duty continuum</li> <li>Informal controllership by owner</li> <li>How controllership becomes transparent</li> <li>sample trust framework (DignifID?)</li> </ul>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/","title":"Delegation Details","text":"<p>Three basic approaches to delegation are possible:</p> <ol> <li>Delegate by expressing intent in a DID Doc.</li> <li>Delegate with verifiable credentials.</li> <li>Delegate by sharing a wallet.</li> </ol> <p>The alternative of delegating via the <code>authorization</code> section of a DID Doc (option #1) is unnecessarily fragile, cumbersome, redundant, and expensive to implement. The theory of delegation with DIDs and credentials has been explored thoughtfully in many places (see Prior Art and References). The emergent consensus is:</p> <ul> <li> <p>Formal delegation is best accomplished with a credential (option 2). This creates an audit trail, makes it possible to declare and enforce limits on what the delegate can do, takes advantage of standard verification and revocation features, and makes recursive delegation possible but not automatic.</p> </li> <li> <p>Informal (undeclared, invisible) delegation could be accomplished by granting access to a shared wallet (option 3). However, this introduces risks of abuse that make it unsuitable for use cases requiring high standards of security, accountability, and privacy.</p> </li> </ul>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#use-cases","title":"Use Cases","text":"<p>The following use cases are good tests of whether we're implementing delegation properly.</p>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#1-thrift-bank-employees","title":"1. Thrift Bank Employees","text":"<p>Thrift Bank wishes to issue employee credentials to its employees, giving them delegated authority to perform certain actions on behalf of the bank (e.g., open their till, unlock the front door, etc). Thrist has a DID, but wishes to grant credential-issuing authority to its Human Resources Department (which has a separate DID). In turn, the HR department wishes to further delegate this authority to the Personnel Division. Inside of the Personnel division, three employees, Cathy, Stan, and Janet will ultimately be responsible for issuing the employee credentials.</p> <ul> <li>Cathy, Stan, and Janet should not have the ability to further delegate the authority.</li> <li>The employee credentials should include the proof of delegated authority.</li> <li>Revocation of the authority to issue the employee credential should be possible at any point along the chain of delegation</li> <li>Proving non-revocation of delegated authority should be possible by Cathy, Stan, and Janet without the need for the Bank, HR, or Personnel to be involved.</li> <li>Revoking the authority to issue the credential should not invalidate the issued employee credentials.</li> </ul>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#2-u-rent-a-car","title":"2. U-Rent-a-Car","text":"<p>U-Rent-a-Car is a multinational company that owns a large fleet of vehicles. Its national headquarters issues a credential, C1, to its regional office in Quebec, authorizing U-Rent-a-Car Quebec to delegate driving privileges to customers, for cars owned by the parent company. Alice rents a car from U-Rent-a-Car Quebec. U-Rent-a-Car Quebec issues a driving privileges credential, C2, to Alice. C2 gives Alice the privilege to drive the car from Monday through Friday of a particular week. Alice climbs in the car and uses her C2 credential to prove to the car (which acts as verifier) that she is an authorized driver. She gets pulled over for speeding on Wednesday and uses C2 to prove to the police that she is the authorized driver of the car. On Thursday night Alice goes to a fancy restaurant. She uses valet parking. She issues credential C3 to the valet, allowing him to drive the car within 100 meters of the restaurant, for the next 2 hours while she is at the restaurant. The valet uses this credential to drive the car to the parking garage. While Alice eats, law enforcement goes to U-Rent-a-Car Quebec with a search warrant for the car. The law enforcement agency has discovered that the previous driver of the car was a criminal. It asks U-Rent-a-Car Quebec to revoke C2, because they don\u2019t want the car to be driven any more, in case evidence is accidentally destroyed. At the end of dinner, Alice goes to the valet and asks for her car to be returned. The valet goes to the car and attempts to open the door using C3. The car tests the validity of the delegation chain of C3, and discovers that C2 has been revoked, making C3 invalid. The car refuses to open the door. Alice has to take Uber to get home. Law enforcement officials take possession of the car.</p>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#3-acme-departments","title":"3. Acme Departments","text":"<p>Acme wants its HR department to issue Acme Employment Credentials, its Accounting department to issue Purchase Orders and Letters of Credit, its Marketing department to officially sign press releases, and so forth. All of these departments should be provably associated with Acme and acting under Acme\u2019s name in an official capacity.</p>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#4-members-of-an-llc","title":"4. Members of an LLC","text":"<p>Like #3, but simpler. 3 or 4 people each need signing authority for the LLC, so LLC delegates that authority.</p>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#approaches-to-recursive-delegation","title":"Approaches to recursive delegation","text":"<p>TODO 1. Root authority delegates directly at every level. 2. Follow the chain 3. Embed the chain</p>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#revocation","title":"Revocation","text":"<p>[TODO]</p>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#infra-identity-delegation","title":"Infra-identity Delegation","text":"<p>TODO</p>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#prior-art-and-references","title":"Prior Art and References","text":"<p>All of the following sources have contributed valuable thinking about delegation:</p> <ul> <li>\"Traversing the Web of Trust: A Protocol for Trusting the Issuer of a Verifiable Credential\", by Stephen Curran, Feb 2018.</li> <li>\"Delegation of Authority for Organizations + Services w/DID\u2019s + VerfCreds (IIW session, April 2018)</li> <li>\"Digital Identity: A Chain of Claims\", by Tim Bouma, May 2018. (See also several other posts by Tim about his work on the Pan-Canadian Trust Framework.)</li> <li>Appendix C of the W3C Verifiable Credentials Spec</li> <li>Object Capabilities for Linked Data</li> <li>Section 5.3 of the DID Spec</li> <li>\"Delegation Concepts in Sovrin\"</li> <li>\"Human Agency Has a Standard\", by Adrian Gropper</li> </ul>"},{"location":"concepts/0103-indirect-identity-control/guardianship-details/","title":"Guardianship Details","text":"<p>For a complete walkthrough or demo of how guardianship works, see this demo script.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-details/#use-cases","title":"Use Cases","text":"<p>See https://docs.google.com/presentation/d/1qUYQa7U1jczEFun3a7sB3lKHIprlwd7brfOU9hEJ34U/edit?usp=sharing</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-details/#who-appoints-a-guardian-rationales","title":"Who appoints a guardian (rationales)","text":"<p>See https://docs.google.com/presentation/d/1aq45aUHTOK_WhFEICboXQrp7dalpLm9-MGg77Nsn50s/edit#slide=id.g59fffee7a0_0_0</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-details/#transparent-vs-opaque","title":"Transparent vs. Opaque","text":"<p>See https://docs.google.com/presentation/d/1aq45aUHTOK_WhFEICboXQrp7dalpLm9-MGg77Nsn50s/edit#slide=id.g59fffee7a0_0_46</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-details/#modes-of-guardianship","title":"Modes of Guardianship","text":"<p>Holding-Based, Impersonation, Doc-based</p> <p>See https://docs.google.com/presentation/d/1aq45aUHTOK_WhFEICboXQrp7dalpLm9-MGg77Nsn50s/edit#slide=id.g59fffee7a0_0_265</p> <p>See also https://docs.google.com/presentation/d/1aq45aUHTOK_WhFEICboXQrp7dalpLm9-MGg77Nsn50s/edit#slide=id.g59fffee7a0_0_280, https://docs.google.com/presentation/d/1aq45aUHTOK_WhFEICboXQrp7dalpLm9-MGg77Nsn50s/edit#slide=id.g59fffee7a0_0_295, https://docs.google.com/presentation/d/1aq45aUHTOK_WhFEICboXQrp7dalpLm9-MGg77Nsn50s/edit#slide=id.g59fffee7a0_0_307</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-details/#guardians-and-wallets","title":"Guardians and Wallets","text":"<p>Need to work on \"wallets\" term See https://docs.google.com/presentation/d/1aq45aUHTOK_WhFEICboXQrp7dalpLm9-MGg77Nsn50s/edit#slide=id.g59fffee7a0_0_365</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-details/#guardians-and-delegation","title":"Guardians and Delegation","text":"<p>TODO</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-details/#privacy-considerations","title":"Privacy Considerations","text":""},{"location":"concepts/0103-indirect-identity-control/guardianship-details/#diffuse-trust","title":"Diffuse Trust","text":""},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/schema/","title":"Sample Guardianship Schema","text":"<p>This document presents a sample schema for a guardian credential appropriate to the IRC-as-guardian-of-Mya-in-a-refugee-camp use case. It is accompanied by a sample trust framework.</p> <p>The raw schema is here:</p> <p></p> <p>For general background on guardianship and its associated credentials, see this slide presentation.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/schema/#how-to-use","title":"How to Use","text":"<p>The schema documented here could be passed as the <code>attrs</code> arg to the <code>indy_issuer_create_schema()</code> method in libindy. The \"1.0\" in this document's name refers to the fact that we are using Indy 1.0-style schemas; we aren't trying to use the rich schema constructs that will be available to us when the \"schema 2.0\" effort is mature.</p> <p>The actual JSON you would need to pass to the <code>indy_issuer_create_schema()</code> method is given in the attached schema.json file. In code, if you place that file's content in a string variable and pass the variable as the <code>attrs</code> arg, the schema will be registered on the ledger. You might use values like \"Red Cross Vulnerable Populations Guardianship Cred\" and \"1.0\" as the <code>name</code> and <code>version</code> args to that same function. You can see an example of how to make the call by looking at the \"Save Schema and Credential Definition\" How-To in Indy SDK.</p> <p>See the accompanying trust framework for an explanation of individual fields.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/","title":"Sample Guardianship Trust Framework","text":"<p>This document describes a sample trust framework for guardianship appropriate to the IRC-as-guardian-of-Mya-in-a-refugee-camp use case. It is accompanied by a sample schema for a guardian credential.</p> <p>For general background on guardianship and its associated credentials, see this slide presentation.</p> <p>The trust framework shown here is a reasonable starting point, and it demonstrates the breadth of issues well. However, it probably would need significantly more depth to provide enough guidance for developers writing production software, and to be legally robust in many different jurisdictions.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#name-version-author","title":"Name, Version, Author","text":"<p>This is the \"Sovrin ID4All Vulnerable Populations Guardianship Trust Framework\", version \"1.0\". The trust framework is abbreviated in credential names and elsewhere as \"SIVPGTF\". It is maintained by the Sovrin ID4All Working Group. Credentials using the schema described here are known as gcreds.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#scope","title":"Scope","text":"<p>The trust framework applies to situations where NGOs like the International Red Cross/Red Crescent, UNICEF, or Doctors Without Borders are servicing large populations of vulnerable refugees, both children and adults, in formal camps. It assumes that the camps have at least modest, intermittent access to telecommunications, and that that they operate with at least tacit approval from relevant legal authorities. It may not provide enough guidance or protections in situations involving active combat, or in legal jurisdictions where rule of law is very tenuous.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#rationales-for-guardianship","title":"Rationales for Guardianship","text":"<p>In this framework, guardianship is based on one or more of the following formally defined rationales:</p> <ul> <li><code>dependent-appointment</code>: The dependent was capable of appointing a guardian, and chose to appoint the named guardian(s) to that role. This is considered the strongest rationale for guardianship.</li> <li><code>kinship</code>: The dependent is known to be vulnerable because of age or disability. The guardian is related to the dependent and thus has a natural claim to guardianship status. This trust framework formally recognizes the following kinship relationships, in order from strongest to weakest: <code>biological-parent</code>, <code>step-parent</code>, <code>sibling</code>, <code>grandparent</code>, <code>aunt-or-uncle</code>, <code>first-cousin</code>, <code>indirect-relative</code>, <code>tribe-adult</code>. Kinships weaker than <code>first-cousin</code> are considered invalid as the rationale for guardianship by themselves.</li> <li><code>adjudicated</code>: A legal authority, or a council consisting of 5 grandmothers, chose the guardian.</li> <li><code>self</code>: No suitable guardian could be found on another basis, but the dependent needed a guardian, so the guardian assumed the status until a better alternative could be found.</li> </ul>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#identifying-a-guardian","title":"Identifying a guardian","text":"<p>This framework assumes that credentials will use ZKP technology. Thus, no holder attributes are embedded in a gcred except for the holder's blinded link secret. During a guardian challenge, the holder should include appropriate identifying evidence based on ZKP credential linking.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#identifying-a-dependent","title":"Identifying a dependent","text":"<p>This framework defines the following formal ways to identify a dependent in a gcred:</p> <ul> <li><code>credentialSubject.first_name</code></li> <li><code>credentialSubject.last_name</code></li> <li><code>credentialSubject.birth_date</code></li> <li><code>credentialSubject.gender</code></li> <li><code>credentialSubject.native_language</code></li> <li><code>credentialSubject.identifying_marks</code></li> <li><code>credentialSubject.photo</code></li> <li><code>credentialSubject.iris</code></li> <li><code>credentialSubject.fingerprint</code></li> </ul> <p>These fields should appear in all gcreds. First name should be the name that the dependent acknowledges and answers to, not necessarily the legal first name. Last name may be empty if it is unknown. Birth date may be approximate. Photo is required and must be a color photo of at least 800x800 pixel resolution, taken at the time the guardian credential is issued, showing the dependent only, in good light. At least one of iris and fingerprint are strongly recommended, but neither is required.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#permissions","title":"Permissions","text":"<p>Guardians may be assigned some or all of the following formally defined permissions in this trust framework:</p> <ul> <li><code>routine-medical-care</code>: Consent to normal medical treatment, including vaccinations, HIV tests, prescriptions, hospitalization, dental procedures, surgeries, and so forth.</li> <li><code>do-not-resuscitate</code>: Consent to discontinue life support.</li> <li><code>school</code>: Enroll or unenroll dependent in school programs. Customize courses of instruction.</li> <li><code>necessaries</code>: Receive food, hygiene items, clothing, and other materials allocated to the dependent.</li> <li><code>gender-identity</code>: Specify the gender by which the dependent shall be known.</li> <li><code>religious-observance</code>: Require the dependent to observe religious practices, or consent for the dependent not to do so.</li> <li><code>light-travel</code>: Take the dependent outside the camp, returning before dark.</li> <li><code>extended-travel</code>: Take the dependent outside the camp for extended periods.</li> <li><code>unenroll</code>: Permanently remove the dependent from the camp's care.</li> <li><code>contracts</code>: Enter into financial or other legally binding arrangements on behalf of the dependent.</li> <li><code>marriage-family-planning</code>: Give consent for the dependent to marry, or require them to do so. Direct the use   contraceptives.</li> <li><code>delegate</code>: Give permission to a non-guardian to exercise some of the guardian's privileges, possibly with restrictions.</li> <li><code>successor</code>: Designate a replacement to assume guardian duties.</li> <li><code>authorize</code>: Configure the permissions of self or other guardians.</li> </ul>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#constraints","title":"Constraints","text":"<p>A guardian's ability to control the dependent may be constrained in the following formal ways by guardian credentials that use this trust framework:</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#boundary","title":"Boundary","text":"<p>Guardian can only operate within named boundaries, such as the boundaries of a country, province, city, military command, river, etc. Boundaries are specified as a localized, comma-separated list of strings, where each locale section begins with a <code>|</code> (pipe) character followed by an ISO639 language code followed by a <code>:</code> (colon) character, followed by data. All localized values must describe the same constraints; if one locale's description is more permissive than another's, the most restrictive interpretation must be used. An example might be:</p> <pre><code>\"constraints.boundaries\": \"|en: West side of Euphrates river, within Baghdad city limits\n    |es: lado oeste del r\u00edo Eufrates, dentro del centro de Bagdad\n    |fr: c\u00f4t\u00e9 ouest de l'Euphrate, dans les limites de la ville de Bagdad\n    |ar: \u0627\u0644\u062c\u0627\u0646\u0628 \u0627\u0644\u063a\u0631\u0628\u064a \u0645\u0646 \u0646\u0647\u0631 \u0627\u0644\u0641\u0631\u0627\u062a \u060c \u062f\u0627\u062e\u0644 \u062d\u062f\u0648\u062f \u0645\u062f\u064a\u0646\u0629 \u0628\u063a\u062f\u0627\u062f\"\n</code></pre>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#point-of-origin-and-radius","title":"Point of Origin and Radius","text":"<p>The <code>constraints.point_of_origin</code> and <code>radius</code> fields are an additional or alternative way to specify a geographical constraint. They must be used together. Point of origin is a string that may use latitude/longitude notation (e.g., \"@40.4043328,-111.7761829,15z\"), or a landmark. Landmarks must be localized as described previously. Radius is an integer measured in kilometers.</p> <pre><code>\"constraints.point_of_origin\": \"|en: Red Crescent Sunrise Camp\"\n\"constraints.radius_km\": 10\n</code></pre>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#jurisdictions","title":"Jurisdictions","text":"<p>This is a comma-separated list of legal jurisdictions where the guardianship applies. It is also localized:</p> <pre><code>\"constraints.jurisdictions\": \"|en: EU, India, Bangladesh\"\n</code></pre>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#trigger-and-circumstances","title":"Trigger and Circumstances","text":"<p>These are human-friendly description of circumstances that must apply in order to make the guardian's status active. It may be used in conjunction with a trigger (see next). It is vital that the wording of these fields be carefully chosen to minimize ambiguity; carelessness could invite abuse. Note that each of these fields could be used separately. A trigger by itself would unconditionally confer guardianship status; circumstances without a trigger would require re-evaluation with every guardianship challenge and might be used as long as an adult is unconscious or diagnosed with dementia, or while traveling with a child, for example.</p> <pre><code>\"constraints.trigger\": \"|en: Death of parent\"\n\"constraints.circumstances\": \"|en: While a parent or adult sibling is unavailable, and no\n    new guardian has been adjudicated.\n    |ar: \u0641\u064a \u062d\u064a\u0646 \u0623\u0646 \u0623\u062d\u062f \u0627\u0644\u0648\u0627\u0644\u062f\u064a\u0646 \u0623\u0648 \u0627\u0644\u0623\u0634\u0642\u0627\u0621 \u0627\u0644\u0628\u0627\u0644\u063a\u064a\u0646 \u063a\u064a\u0631 \u0645\u062a\u0648\u0641\u0631 \u060c \u0648\u0644\u064a\u0633\n         \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u0627\u0644\u0648\u0635\u064a \u0627\u0644\u062c\u062f\u064a\u062f \u062a\u0645 \u0627\u0644\u0641\u0635\u0644 \u0641\u064a\u0647.\"\n</code></pre>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#timing","title":"Timing","text":"<p>These allow calendar restrictions. Both start time and end time are expressed as ISO8601 timestamps in UTC timezone, but can be limited to day- instead of hour-and-minute-precision (in which case timezone is irrelevant). Start time is inclusive, whereas end time is exclusive (as soon as the date and time equals or exceeds end time, the guardianship becomes invalid). Either value can be used by itself, in addition to being used in combination.</p> <pre><code>\"constraints.startTime\": \"2019-07-01T18:00\"\n\"constraints.endTime\": \"2019-08-01\"\n</code></pre>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#auditing","title":"Auditing","text":"<p>It is strongly recommended that an audit trail be produced any time a guardian performs any action on behalf of the dependent, except for <code>school</code> and <code>necessaries</code>. Reports of auditable events are accomplished by generating a JSON document in the following format:</p> <pre><code>{\n    \"@type\": \"SIVPGTF audit/1.0\",\n    \"event_time\": \"2019-07-25T18:03:26\",\n    \"event_place\": \"@40.4043328,-111.7761829,15z\",\n    \"challenger\": \"amy.smith@redcross.org\",\n    \"witness\": \"fred.jones@redcross.org\",\n    \"guardian\": \"Farooq Abdul Sami\",\n    \"rationale\": \"natural parent\",\n    \"dependent\": \"Isabel Sami, DOB 2009-05-21\",\n    \"event\": \"enroll in class, receive books\",\n    \"justifying_permissions\": \"school, necessaries\"\n    \"evidence\": // base64-encoded photo of Farooq and Isabel\n}\n</code></pre>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#appeal","title":"Appeal","text":"<p>NGO staff (who receive delegated authority from the NGO that acts as guardian), and a council of 5 grandmothers maintain a balance of powers. Decisions of either group may be appealed to the other. Conformant NGOs must identify a resource that can adjudicate an escalated appeal, and this resource must be independent in all respects--legal, financial, human, and otherwise--from the NGO. This resource must have contact information in the form of a phone number, web site, or email address, and the contact info must be provided in the guardian credential in the <code>appeal_uri</code> field.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#freshness-and-offline-operation","title":"Freshness and Offline Operation","text":"<p>[TODO]</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#revocation","title":"Revocation","text":"<p>[TODO]</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#best-practices","title":"Best Practices","text":"<ul> <li>Perform a guardian challenge whenever a guardian attempts an action requiring permissions other than <code>school</code> and <code>necessaries</code>.</li> <li>Require the disclosure of dependent photo and the comparison of the photo to the dependent, who must be physically present, for all operations using the <code>routine-medical-care</code>, <code>do-not-resuscitate</code>, <code>gender-identity</code>, and <code>light-travel</code> permissions.</li> <li>Require a biometric match (fingerprint or iris strongly preferred, or else photo plus two related adult witnesses) for the <code>extended travel</code>, <code>unenroll</code>, <code>contracts</code>, and <code>marriage-family-planning</code> permissions to be exercised where possible.</li> </ul>"},{"location":"concepts/0104-chained-credentials/","title":"Aries RFC 0104: Chained Credentials","text":"<ul> <li>Authors: Daniel Hardman, Lovesh Harchandani</li> <li>Status: PROPOSED</li> <li>Since: 2019-09-09</li> <li>Status Note: Updated 2019-11-04 after discussion at IIW at on Aries community calls, and again 2020-01-07. Various aspects of this are implemented, or in the process of being implemented, in Hyperledger Ursa and Hyperledger Indy. This doc will be updated based on learnings.</li> <li>Start Date: 2019-08-01</li> <li>Tags: concept, credentials</li> </ul>"},{"location":"concepts/0104-chained-credentials/#note-editable-images","title":"Note: editable images","text":"<p>See here for original images used in this RFC.</p>"},{"location":"concepts/0104-chained-credentials/#note-terminology-update","title":"Note: terminology update","text":"<p>\"Chained credentials\" were previously called \"delegatable credentials.\" The new term is broader and more accurate. Delegation remains a use case for the mechanism, but is no longer its exclusive focus.</p>"},{"location":"concepts/0104-chained-credentials/#summary","title":"Summary","text":"<p>Describes a set of conventions, collectively called chained credentials, that allows data in a verifiable credential (VC) to be traced back to its origin while retaining its verifiable quality. This chaining alters trust dynamics. It means that issuers late in a chain can skip complex issuer setup, and do not need the same strong, globally recognizable reputation that's important for true roots of trust. It increases the usefulness of offline verification. It enables powerful delegation of privileges, which unlocks many new verifiable credential use cases.</p> <p>Chained credentials do not require any modification to the standard data model for verifiable credentials; rather, they leverage the data model in a simple, predictable way. Chaining conventions work (with some feature variations) for any W3C-conformant verifiable credential type, not just the ones developed inside Hyperledger.</p>"},{"location":"concepts/0104-chained-credentials/#note-object-capabilities","title":"Note: object capabilities","text":"<p>When chained credentials are used to delegate, the result is an object capabilities (OCAP) solution similar to ZCAP-LD in scope, ../../features, and intent. However, such chained capabilities accomplish their goals a bit differently. See here for an explanation of the divergence and redundancy.</p>"},{"location":"concepts/0104-chained-credentials/#note-sister-rfc","title":"Note: sister RFC","text":"<p>This RFC is complements Aries RFC 0103: Indirect Identity Control. That doc describes how delegation (and related control mechanisms like delegation and controllership) can be represented in credentials and governed; this one describes an underlying infrastructure to enable such a model. The ZKP implementation of this RFC comes from Hyperledger Ursa and depends on cryptography described by Camenisch et al. in 2017.</p>"},{"location":"concepts/0104-chained-credentials/#motivation","title":"Motivation","text":"<p>There is a tension between the decentralization that we want in a VC ecosystem, and the way that trust tends to centralize because knowledge and reputation are unevenly distributed. We want anyone to be able to attest to anything they like--but we know that verifiers care very much about the reputation of the parties that make those attestations.</p> <p>We can say that verifiers will choose which issuers they trust. However, this places a heavy burden on them--verifiers can't afford to vett every potential issuer of credentials they might encounter. The result will be a tendency to accept credentials only from a short list of issuers, which leads back to centralization.</p> <p>This tendency also creates problems with delegation. If all delegation has to be validated through a few authorities, a lot of the flexibility and power of delegation is frustrated.</p> <p>We'd like a VC landscape where a tiny startup can issue an employment credential with holder attributes taken as seriously as one from a massive global conglomerate--and with no special setup by verifiers to trust them equally. And we'd like parents to be able to delegate childcare decisions to a babysitter on the spur of the moment--and have the babysitter be able to prove it when she calls an ambulance.</p>"},{"location":"concepts/0104-chained-credentials/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0104-chained-credentials/#data-provenance","title":"Data provenance","text":"<p>Our confidence in data depends on the data's origin and chain of custody--its provenance.</p> <p>Journalists and academics cite sources. The highest quality sources explain how primary data was derived, and what inferences are reasonable to draw from it. Better sources, and better links to those sources, create better trust.</p> <p>With credentials, the direct reporter of data is the issuer--but the issuer is not always the data's source. When Acme's HR department issues an employment credential that includes Bob the employee's name, the source of Bob's name is probably government-issued ID, not Acme's subjective opinion. Acme is reporting data that originated elsewhere.</p> <p></p> <p>Acme should cite its sources. Even when citations are unstructured and unsigned, they may still be helpful to humans. But we may be able to do better. If the provenance of an employee's name is verifiable in the same way as other credential data, then Acme's reputation with respect to that assertion becomes almost unimportant; the data's ability to foster trust is derived from the reputation of its true source, plus the algorithm that verifies that source.</p> <p>This matters.</p> <p>One of the challenges with traditional trust on the web is the all-or-nothing model of trust for certificate authorities. A website in an obscure corner of the globe uses an odd CA; browser manufacturers must debate whether that CA deserves to be on the list of globally trusted attesters. If yes, then any cert the CA issues will be silently believed; if no, then none will. UX pressure has often decided the debate in favor of trust by default; the result has been very long lists of trusted CAs, and a corresponding parade of junk certificates and abuse.</p> <p>Provenanced data helps verifiable credentials avoid the same conundrum. The set of original sources for a person's legal name is far smaller than the set of secondary entities that might issue credentials containing that data, so verifiers need only a short list of trusted sources for that data, no matter how many issuers they see. When they evaluate an employment credential, they will be able to see that the employee's name comes from a passport issued by the government, while the hire date is directly attested by the company. This lets the verifier nuance trust in granular and useful ways. </p>"},{"location":"concepts/0104-chained-credentials/#delegation-as-provenance-of-authority","title":"Delegation as provenance of authority","text":"<p>Delegation can be modeled as a data provenance issue, where the data in question is an authorization. Suppose Alice, the CEO of Thrift Bank, has the authority to do many tasks, and that one of them is to negotiate contracts. As the company grows, she decides that the company needs a role called \"Corporate Counsel\", and she hires Carl for the job. She wants to give Carl a credential that says he has the authority to negotiate contracts. The provenance of Carl's authority is Alice's own authority.</p> <p></p> <p>Notice how parallel this diagram is to the previous one.</p>"},{"location":"concepts/0104-chained-credentials/#chaining","title":"Chaining","text":"<p>Both of the examples given above imagine a single indirection between a data source and the issuer who references it. But of course many use cases will be far more complex. Perhaps the government attests Bob's name; this becomes the basis for Bob's employer's attestation, which in turn becomes the basis for an attestation by the contractor that processes payroll for Bob's employer. Or perhaps authorization from Alice to corporate counsel gets further delegated. In either case, the result will be a data provenance chain:</p> <p></p> <p>This is the basis for the chained credential mechanism that gives this RFC its name. Chained credentials contain information about the provenance of some or all of the data they embody; this allows a verifier to trace the data backward, possibly through several links, to its origin, and to evaluate trust on that basis.</p>"},{"location":"concepts/0104-chained-credentials/#use-cases","title":"Use cases","text":"<p>Many use cases exist for conveying provenance for the data inside verifiable credentials:</p> <ul> <li>A person wants to use an airplane ticket to gain access to a boarding area in an airport. The airplaine ticket contains data directly attested by the carrier, as well as data attested by the passport that the passenger used during check in, plus data attested by the credit card company that the passenger used to buy the ticket, plus maybe data attested by personnel at a security checkpoint. Verification of this data should impute different trust to different fields on the ticket depending on the provenance of the data. </li> <li>An oversight body wants to certify election results, based on results reported (as VCs) by each precint. Precints in turn want to certify results based on data emitted (as VCs) by polling stations. The oversight body wants to show that its certification is dependent on data that it received and believed to be genuine, not on direct observation in every polling location.</li> <li>Company A wants to delegate to B (a vendor of HR services) the management of A's employees, including the issuance of employee-of-A credentials that are in turn used to act on behalf of A.</li> <li>A scientific organization that operates exploratory drones wants to delegate pilot privileges to some staff members, and maintenance privileges to other staff members.</li> <li>A parent wants to delegate medical care decisions to a babysitter for a few hours.</li> </ul>"},{"location":"concepts/0104-chained-credentials/#acid-test","title":"Acid Test","text":"<p>Although these situations sound different, their underlying characteristics are surprisingly similar--and so are those of other use cases we've identified. We therefore chose a single situation as being prototypical. If we address it well, our solution will embody all the characteristics we want. The situation is this:</p> <p></p>"},{"location":"concepts/0104-chained-credentials/#chain-of-provenance-for-authority-delegation","title":"Chain of Provenance for Authority (Delegation)","text":"<p>The national headquarters of Ur Wheelz (a car rental company) issues a verifiable credential, C1, to its regional office in Houston, authorizing Ur Wheelz Houston to rent, maintain, sell, drive, and delegate driving privileges to customers, for certain cars owned by the national company. </p> <p>Alice rents a car from Ur Wheelz Houston. Ur Wheelz Houston issues a driving privileges credential, C2, to Alice. C2 gives Alice the privilege to drive the car on a particular week, within the state of Texas, and to further delegate that privilege. Alice uses her C2 credential to prove to the car (which is a fancy future car that acts as verifier) that she is an authorized driver; this is what unlocks the door.</p> <p>Alice gets pulled over for speeding on Wednesday and uses C2 to prove to the police that she is the authorized driver of the car.</p> <p>On Thursday night Alice goes to a fancy restaurant. She uses valet parking. She issues credential C3 to the valet, allowing him to drive the car within 100 meters of the restaurant, for the next 2 hours while she is at the restaurant. Alice chooses to constrain C3 so the valet cannot further delegate. The valet uses C3 to unlock and drive the car to the parking garage.</p>"},{"location":"concepts/0104-chained-credentials/#revocation","title":"Revocation","text":"<p>While Alice eats, law enforcement officers go to Ur Wheelz Houston with a search warrant for the car. They have discovered that the previous driver of the car was a criminal. They ask Ur Wheelz to revoke C2, because they don\u2019t want the car to be driven any more, in case evidence is accidentally destroyed.</p> <p>At the end of dinner, Alice goes to the valet and asks for her car to be returned. The valet goes to the car and attempts to open the door using C3. The car tests the validity of the delegation chain of C3, and discovers that C2 has been revoked, making C3 invalid. The car refuses to open the door. Alice has to take Uber to get home. Law enforcement takes possession of the car.</p>"},{"location":"concepts/0104-chained-credentials/#how-chained-credentials-address-this-use-case","title":"How chained credentials address this use case","text":"<p>A chained credential is a verifiable credential that contains provenanced data, linking it back to its source. In this case, the provenanced data is about authority, and each credential in the chain functions like a capability token, granting its holder privileges that derive from an upstream issuer's own authority.</p>"},{"location":"concepts/0104-chained-credentials/#note-delegate-credentials","title":"Note: delegate credentials","text":"<p>We call this subtype of chained credential a delegate credential. We'll try to describe the provenance chain in generic terms as much as possible, but the delegation problem domain will occasionally color our verbiage... All delegate credentials are chained; not all chained credentials are delegate credentials.</p> <p>The first entity in the provenance chain for authority (Ur Wheels National, in our acid use case) is called the root attester, and is probably an institution configured for traditional credential issuance (e.g., with a public DID to which reputation attaches; in Indy, this entity also publishes a credential definition). All downstream entities in the provenance chain can participate without special setup. They need not have public DIDs or credential definitions. This is because the strength of the assertion does not depend on their reputation; rather, it depends on the robustness of the algorithm that walks the provenance chain back to its root. Only the root attester needs public reputation.</p>"},{"location":"concepts/0104-chained-credentials/#note-contrast-with-acls","title":"Note: contrast with ACLs","text":"<p>When chained credentials are used to convey authority (the delegate credential subtype), they are quite different from ACLs. ACLs map an identity to a list of permissions. Delegate credentials entitle their holder to whatever permissions the credential enumerates. Holding may or may not be transferrable. If it is not transferrable, then fraud prevention must be considered. If the credential isn't bound to a holder, then it's a bearer token and is an even more canonical OCAP.</p>"},{"location":"concepts/0104-chained-credentials/#special-sauce","title":"Special Sauce","text":"<p>A chained credential delivers these ../../features by obeying some special conventions over and above the core requirements of an ordinary VC:</p> <ol> <li> <p>It contains a special field named <code>schema</code> that is a base64url-encoded representation of its own schema. This makes the credential self-contained in the sense that it doesn't depend on a schema or credential definition defined by an external authority (though it could optionally embody one). This field is always disclosed in presentations.</p> </li> <li> <p>It contains a special field named <code>provenanceProofs</code>. The field is an array, where each member of the array is a tuple (also a JSON array). The first member of each tuple is a list of field names; the second member of each tuple is an embedded W3C verifiable presentation that proves the provenance of the values in those fields. In the case of delegate credentials, <code>provenanceProofs</code> is proving the provenance of a field named <code>authorization</code>.</p> <p>Using credentials C1, C2, and C3 from our example use case, the <code>authorization</code> tuple in <code>provenanceProofs</code> of C1 includes a presentation that proves, on the basis of a car title that's a traditional, non-provenanced VC, that Ur Wheelz National had the authority to delegate a certain set of privileges X to Ur Wheelz Houston. The <code>authorization</code> tuple in <code>provenanceProofs</code> of C2 proves that Ur Wheelz Houston had authority to delegate Y (a subset of the authority in X) to Alice, and also that Ur Wheelz Houston derived its authority from Ur Wheelz National, who had the authority to delegate X to Ur Wheelz Houston. Similarly, the <code>authorization</code> tuple in C3's <code>provenanceProofs</code> is an extension of the <code>authorization</code> tuple in C2's <code>provenanceProofs</code>\u2014now proving that Alice had the authority to delegate Z to the valet, plus all the other delegations in the upstream credentials.</p> <p></p> <p>When a presentation is created from a chained credential, <code>provenanceProofs</code> is either disclosed (for non-ZKP proofs), or is used as evidence to prove the same thing (for ZKPs).</p> </li> <li> <p>It is associated (through a name in its <code>type</code> field array and through a URI in its <code>trustFrameworkURI</code> field) with a trust framework that describes provenancing rules. For general chained credentials, this is optional; for delegate credentails, it is required. The trust framework may partially describe the semantics of some schema variants for a family of chained credentials, as well as how provenance is attenuated or categorized. For example, a trust framework jointly published by Ur Wheelz and other car rental companies might describe delegate credential schemas for car owners, car rental offices, drivers, insurers, maintenance staff, and guest users of cars. It might specify that the permissions delegatable in these credentials include <code>drive</code>, <code>maintain</code>, <code>rent</code>, <code>sell</code>, <code>retire</code>, <code>delegate-further</code>, and so forth. The trust framework would do more than enumerate these values; it would define exactly what they mean, how they interact with one another, and what permissions are expected to be in force in various circumstances.</p> </li> <li> <p>The reputation of non-root holders in a provenance chain become irrelevant as far as credential trust is concerned--trust is based on an unbroken chain back to a root public attester, not on published, permanent characteristics of secondary issuers. Only the root attester needs to have a public DID. Other issuer keys and DIDs can be private and pairwise.</p> </li> <li> <p>If it is a delegate credential, it also meets all the requirements to be a proxy credential as described in Aries RFC 0103: Indirect Identity Control. Specifically:</p> <ul> <li> <p>It uses <code>credentialSubject.holder.*</code> fields to bind it to a particular holder, if applicable.</p> </li> <li> <p>It uses <code>credentialSubject.proxied.*</code> fields to describe the upstream delegator to whatever extent is required.</p> </li> <li> <p>It uses <code>credentialSubject.holder.role</code> and <code>credentialSubject.proxied.permissions</code> to grant permissions to the holder. See Delegating Permissions for more details.</p> </li> <li> <p>It may use <code>credentialSubject.holder.constraints.*</code> to impose restrictions on how/when/under what circumstances the delegation is appropriate.</p> </li> </ul> </li> </ol>"},{"location":"concepts/0104-chained-credentials/#whats-not-different","title":"What's not different","text":"<p>Proof of non-revocation uses the same mechanism as the underlying credentialing system. For ZKPs, this means that merkle tree or accumulator state is checked against the ledger or against any other source of truth that the root attester in the chain specifies; no conferring with upstream issuers is required. See ZKP Revocation in the reference section. For non-ZKP credentials, this probably means consulting revocation lists or similar.</p> <p>Offline mode works exactly the same way as it works for ordinary credentials, and with exactly the same latency and caching properties.</p> <p>Chained credentials may contain ordinary credential attributes that describe the holder or other subjects, including ZKP-style blinded link secrets. This allows chained credentials to be combined with other VCs in composite presentations.</p>"},{"location":"concepts/0104-chained-credentials/#sample-credentials","title":"Sample credentials","text":"<p>Here is JSON that might embody credentials C1, C2, and C3 from our use case. Note that these examples suppress a few details that seem uninteresting, and they also introduce some new ../../concepts that are described more fully in the Reference section.</p>"},{"location":"concepts/0104-chained-credentials/#c1-delegates-management-of-car-to-ur-wheelz-houston","title":"C1 (delegates management of car to Ur Wheelz Houston)","text":"<pre><code>{\n    \"@context\": [\"https://w3.org/2018/credentials/v1\", \"https://github.com/hyperledger/aries-rfcs/tree/main../../concepts/0104-delegatable-credentials\"],\n    \"type\": [\"VerifiableCredential\", \"Proxy.D/CarRentalTF/1.0/subsidiary\"],\n    \"schema\": \"WwogICJAY29udGV4dCIsIC8vSlN... (clipped for brevity) ...ob2x\",\n    \"provenanceProofs\": [\n        [[\"authorization\"], {\n            // proof that Ur Wheelz National owns the car\n            }]\n    ],\n    // Optional. Might be used to identify the car in question.\n    \"credentialSubject.car.VIN\": \"1HGES26721L024785\",\n    \"credentialSubject.proxied.permissions\": {\n        \"grant\": [\"rent\", \"maintain\", \"sell\", \"drive\", \"delegate\"], \n        \"when\": { \"role\": \"regional_office\" } \n    }\n    // Optional. Binds the credential to a business name.\n    \"credentialSubject.holder.name\": \"Ur Wheelz Houston\",\n    // Optional. Binds the credential to the public DID of Houston office.\n    \"credentialSubject.holder.id\": \"did:example:12345\",\n    \"credentialSubject.holder.role\": \"regional_office\",\n}\n</code></pre>"},{"location":"concepts/0104-chained-credentials/#c2-delegates-permission-to-alice-to-drive-subdelegate","title":"C2 (delegates permission to Alice to drive, subdelegate)","text":"<pre><code>{\n    // @context, type, schema are similar to previous\n    \"provenanceProofs\": {\n        [[\"authorization\"], {\n            // proof that Ur Wheelz Houston could delegate\n            }]\n    },\n    // Optional. Might be used to identify the car in question.\n    \"credentialSubject.car.VIN\": \"1HGES26721L024785\",\n    \"credentialSubject.proxied.permissions\": {\n        \"grant\": [\"drive\", \"delegate\"], \n        \"when\": { \"role\": \"renter\" } \n    }\n    // Optional. Binds the credential to a business name.\n    \"credentialSubject.holder.name\": \"Alice Jones\",\n    // Optional. Binds the credential to the public DID of Houston office.\n    \"credentialSubject.holder.id\": \"did:example:12345\",\n    \"credentialSubject.holder.role\": \"renter\",\n    // Limit dates when delegation is active\n    \"credentialSubject.holder.constraints.startTime\": \"2020-05-20T14:00Z\",\n    \"credentialSubject.holder.constraints.endTime\": \"2020-05-27T14:00Z\",\n    // Provide a boundary within which delegation is active\n    \"credentialSubject.holder.constraints.boundary\": \"USA:TX\"\n}\n</code></pre>"},{"location":"concepts/0104-chained-credentials/#c3-delegates-permission-to-valet-to-drive","title":"C3 (delegates permission to valet to drive)","text":"<pre><code>{\n    // @context, type, schema are similar to previous\n    \"delegationProof\": {\n        [[\"authorization\"], {\n            // proof that Alice could delegate\n            }]\n    },\n    // Optional. Might be used to identify the car in question.\n    \"credentialSubject.car.VIN\": \"1HGES26721L024785\",\n    \"credentialSubject.proxied.permissions\": {\n        \"grant\": [\"drive\"], \n        \"when\": { \"role\": \"valet\" } \n    }\n    // Optional. Binds the credential to a business name.\n    \"credentialSubject.holder.name\": \"Alice Jones\",\n    // Optional. Binds the credential to the public DID of Houston office.\n    \"credentialSubject.holder.id\": \"did:example:12345\",\n    \"credentialSubject.holder.role\": \"valet\",\n    \"credentialSubject.holder.constraints.startTime\": \"2020-05-25T04:00Z\",\n    \"credentialSubject.holder.constraints.endTime\": \"2020-05-25T06:00Z\",\n    // Give a place where delegation is active.\n    \"credentialSubject.holder.constraints.pointOfOrigin\": \"@29.7690295,-95.5293445,12z\",\n    \"credentialSubject.holder.constraints.radiusKm\": 0.1,\n}\n</code></pre>"},{"location":"concepts/0104-chained-credentials/#reference","title":"Reference","text":""},{"location":"concepts/0104-chained-credentials/#delegating-permissions","title":"Delegating Permissions","text":"<p>In theory, we could just enumerate permissions in delegate credentials in a special VC field named <code>permissions</code>. To delegate the <code>drive</code> and <code>delegate</code> privileges to Alice, this would mean we'd need a credential field like this:</p> <pre><code>{\n    // ... rest of credential fields ...\n\n    \"permissions\": [\"drive\", \"delegate\"]\n}\n</code></pre> <p>Such a technique is adequate for many delegation use cases, and is more or less how ZCAP-LD works. However, it has two important limitations:</p> <ul> <li>It doesn't support aggregate delegation\u2014delegating to a group of holders who must act together to acquire the permission. Example: there is no obvious way for a company to delegate signing permissions to 3 members of its board as a collective unit\u2014only to single board members as individuals.</li> <li>It doesn't convey context in ways that lets humans adjudicate the intent of the delegator. This is a requirement for guardianship, and possibly for some other specialized delegation use cases.</li> </ul> <p>To address these additional requirements, delegate credentials split the granting of permissions into two fields instead of one:</p> <ol> <li>The permission model that provides context for the credential is expressed in a special field named <code>credentialSubject.proxied.permissions</code>. This field contains an SGL rule that embodies the semantics of the delegation.</li> <li>The holder (delegate) is given a named role in that overall permission scheme in a special field named <code>credentialSubject.holder.role</code>. This role has to reference something from <code>...permissions</code>. </li> </ol> <p>In our Ur Wheelz / Alice use case, the extra expressive power of these two fields is not especially interesting. The credential that Alice carries might look like this:</p> <pre><code>{\n    // ... rest of credential fields ...\n\n    \"credentialSubject.proxied.permissions\": { \n        \"grant\": [\"drive\"], \n        \"when\": { \"role\": \"renter\" } \n    }\n    \"credentialSubject.holder.role\": [\"renter\"]\n}\n</code></pre> <p>Since <code>credentialSubject.holder.role</code> says that Alice has the <code>renter</code> role, the grant of <code>drive</code> applies to her. We expect permissions to always apply directly to the holder in simple cases like this.</p> <p>But in the case of a corporation that wants to delegate signing privileges to 3 board members, the benefit of the two-field approach is clearer. Each board member gets a delegate credential that looks like this:</p> <pre><code>{\n    // ... rest of credential fields ...\n\n    \"credentialSubject.proxied.permissions\": { \n        \"grant\": [\"sign\"], \n        \"when\": { \"role\": \"board\", \"n\": 3 } \n    }\n    \"credentialSubject.holder.role\": [\"board\"]\n}\n</code></pre> <p>Now a verifier can say to one credential-holding board member, \"I see that you have part of the signing privilege. Can you find me two other board members who agree with this action?\"</p>"},{"location":"concepts/0104-chained-credentials/#privacy-considerations","title":"Privacy Considerations","text":"<p>Non-ZKP-based chained credentials reveal the public identity of the immediate downstream holder to each issuer (delegator) -- and they reveal the public identiy of all upstream members of the chain to the holder.</p> <p>ZKP-based chained credentials offer more granular choices. See ZKP Variants and their privacy implications below.</p>"},{"location":"concepts/0104-chained-credentials/#embedded-schema","title":"Embedded schema","text":"<p>Often, the schema of a chained credential might be decided (or created) by the issuer. In some cases, the schema might be decided by the delegatee or specified fully or partially in a trust framework. </p> <p>It is the responsibility of each issuer to ensure that the special <code>schema</code> attribute is present and that the credential matches it.</p>"},{"location":"concepts/0104-chained-credentials/#zkp-revocation","title":"ZKP Revocation","text":"<p>When a chained credential is issued, a unique credential id is assigned to it by its issuer and then the revocation registry is updated to track which credential id was issued by which issuer. During proof presentation, the prover proves in zero knowledge that its credential is not revoked. When a credential is to be revoked, the issuer of the credential sends a signed message to the revocation registry asking it to mark the credential id as revoked. Note that this allows only the issuer of the credential to revoke the credential and does not allow, for example, the delegator to revoke any credential that was issued by its delegatee. However, this can be achieved by the verifier mandating that each credential in the chain of credentials is non-revoked. When a PCF decides to revoke the PTR credential, every subsequent credential should be considered revoked.</p> <p>In practice, there are more attributes associated with the credential id in the revocation registry than just the public key. The registry also tracks the timestamps of issuance and revocation of the credential id and the prover is able to prove in zero knowledge about those data points as well. The way we imagine revocation being implemented is having a merkle tree with each leaf corresponding to a credential id, so for a binary tree of height 8, there are 2^8 = 256 leaves and leaf number 1 will correspond to credential id 1, leaf number 2 will correspond to credential id 2, and so on. The data at the leaf consists of the public key of the issuer, the issuance timestamp and the revocation timestamp. We imagine the use of Bulletproofs merkle tree gadget to do such proofs like we plan to do for the upcoming version of anonymous credentials.</p>"},{"location":"concepts/0104-chained-credentials/#zkp-variants-and-their-privacy-implications","title":"ZKP Variants and their privacy implications","text":"<p>There are two general categories of chained anonymous credentials, distinguished by the tradeoff they make between privacy and efficiency. Choosing between them should depend on whether privacy between intermediate issuers is required.</p> <p>The more efficient category provides no privacy among the issuers but only verifiers. Suppose the holder, say Alice, requests a chained credential from the root attestor, say Acme Corp., which it further attests to a downstream issuer Bob which further delegates to another downstream issuer Carol. Here Carol knows the identity (a public key) of Bob and both Carol and Bob know the identity of Alice but when Carol or Bob uses its credential to create a proof and send it to the verifier, the verifier only learns about the identity of the root attester.</p> <p>Less efficient but more private schemes (isolating attestors more completely) also exist.</p> <p>The first academic paper in the following list describes a scheme which does not allow for privacy between attestors, but that is more efficient; the second and third papers make the opposite tradeoff.</p> <ol> <li>Practical UC-Secure Delegatable Credentials with Attributes and Their Application to Blockchain.</li> <li>Delegatable Attribute-based Anonymous Credentials from Dynamically Malleable Signatures</li> <li>Delegatable Anonymous Credentials from Mercurial Signatures </li> </ol> <p>In the first scheme, each issuer passes on its received credentials to the issuer it is delegating to. In the above Acme Corp., Alice, Bob and Carol example, if when Alice delegates to Bob, it gives Bob a new credential but also a copy of the credential it received from Acme Corp. And when Bob delegates to Carol, he gives a new credential to Carol but also the copies of credential it got from Alice and the one Alice had got from Acme Corp. The verifier while getting a proof from, say Carol, does not learn the about the Alice, Bob or Carol but learns that there were 2 issuers between Acme Corp and the proof presenter. It also learns the number of attributes in each credential in the chain of credentials.</p> <p>In the second and third scheme, during delegation, the delegator gives only one credential to the delegatee derived from its credential but the delegatee randomizes its identity each time. The second scheme's efficiency is comparable to the first scheme's but it has a trusted authority which can deanonymize any issuer given a proof created from that issuer's credential. This might be fine in cases where the PCF can be safely made the trusted authority and is not assumed to colluding with the verifiers to deanonymize the users.</p> <p>In the third scheme, another limitation exists that non-root issuers cannot add any more attributes to the credential than the root issuer did.</p>"},{"location":"concepts/0104-chained-credentials/#drawbacks","title":"Drawbacks","text":"<p>If the trust framework is not properly defined, malicious parties might be able to get credentials from delegators leading to priviledge escalation. </p>"},{"location":"concepts/0104-chained-credentials/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>An expensive alternative of delegatable credentials is the holder to get credential directly from the root issuer. The expensiveness of this is not just computational but operational too.</p>"},{"location":"concepts/0104-chained-credentials/#prior-art","title":"Prior art","text":"<p>Delegatable anonymous credentials have been explored since the last decade and the first efficient (somewhat) came in 2009 by Belenkiy et al. in \"Randomizable proofs and delegatable anonymous credentials\". Although this was a significant efficiency improvement over previous works, it was still impractical. Chase et al. gave a conceptually novel construction of delegatable anonymous credentials in 2013 in \"Complex unary transformations and delegatable anonymous credentials\" but the resulting construction was essentially as inefficient as that of Belenkiy et al. </p>"},{"location":"concepts/0104-chained-credentials/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0104-chained-credentials/contrast-zcap-ld/","title":"Contrast zcap ld","text":""},{"location":"concepts/0104-chained-credentials/contrast-zcap-ld/#why-not-zcap-ld","title":"Why not ZCAP-LD?","text":"<p>The object capability model is great, and ZCAP-LD is an interesting solution that exposes that goodness to the VC ecosystem. However, we had the following concerns when we first encountered its spec (originally entitled \"OCAP-LD\"):</p> <ul> <li> <p>It invents a new document format type, with associated new parsing and validation logic. We wondered whether a VC itself, instead of a new type of doc, could convey an object capability. Using a VC to convey delegation, instead of a new doc type, would minimize new code and possibly give a natural adaptation path for all VC ecosystems. (In fairness to ZCAP-LD, the reuse is fairly substantial with ZCAP-LD if your VC impl is JSON-LD centric. So this concern mainly resonates for people coming from a JWT- or ZKP-centric world.)</p> </li> <li> <p>ZCAP-LD's mechanism for validating the non-revocation status of each credential in the delegation chain seemed to follow the same revocation checking pattern as traditional non-ZKP credentials. This results in a workflow where everyone upstream in a delegated credential chain finds out each time a credential is used, which is a privacy concern.</p> </li> <li> <p>We had concerns about fragility. When issuers are massive institutions that are online 24x7x365, this may not be deeply problematic, but we wanted a solution that could be used by issuers that are regularly offline.</p> </li> <li> <p>It wasn't obvious to us how to use ZCAP-LD when ZKPs are a desirable feature.</p> </li> <li> <p>We needed to integrate delegation with the concepts of guardianship and controllership (e.g., so a guardian could delegate and a delegate could be a guardian). This required some commonality among the 3 modes of proxy identity control that was not modeled in ZCAP-LD.</p> </li> <li> <p>We wanted to use delegation features to faciliate issuance by private individuals, while short-circuiting the relatively demanding setup that normal VC issuance requires.  </p> </li> </ul> <p>For these reasons, we spent some time working out a somewhat similar mechanism. We hope we can reconcile the two at some point. For now, though, this doc just describes our alternative path.</p>"},{"location":"concepts/0167-data-consent-lifecycle/","title":"Aries RFC 0167: Data Consent Lifecycle","text":"<ul> <li>Authors: Jan Lindquist, Dativa; Paul Knowles, Dativa; Mark Lizar, OpenConsent; Harshvardhan J. Pandit, ADAPT Centre, Trinity College Dublin</li> <li>Status: PROPOSED</li> <li>Since: 2019-08-07 (updated 2019-03-16)</li> <li>Status Note: This RFC is under development. The reference implementation was recently added.</li> <li>Supersedes: Indy HIPE PR #55: Consent Receipt</li> <li>Start Date: 2018-11-08</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0167-data-consent-lifecycle/#table-of-contents","title":"Table of Contents","text":"<ul> <li>Summary</li> <li>Motivation</li> <li>Overview</li> <li>Concepts</li> <li>Use Cases</li> <li>Implementation Guidelines<ul> <li>Collect Personal Data</li> <li>Personal Data Processing Schema</li> <li>Example: schemas</li> <li>Blockchain Prerequisites</li> <li>Data Consent Receipt Certificate</li> <li>Initial agreement of privacy agreement</li> <li>Proof Request</li> <li>Performing Proof Request</li> <li>Certification Revocation</li> </ul> </li> <li>Implementation Reference</li> <li>Reference</li> <li>Annex A: PDP Schema mapping to Kantara Consent Receipt</li> <li>Prior art<ul> <li>ETL process</li> <li>Personal Data Terms and Conditions</li> </ul> </li> <li>Unresolved questions</li> <li>Plan</li> <li>ToDo</li> <li>Comments</li> </ul>"},{"location":"concepts/0167-data-consent-lifecycle/#summary","title":"Summary","text":"<p>This  RFC illustrates a reference implementation for generating a consent proof for use with DLT (Distributed Ledger Technology).  Presenting a person controlled consent proof data control architecture and supply chain permissions, that is linked to the single consent proof.</p> <p>The objective of this RFC is to move this  reference implementation, once comments are processed, to a working implementation RFC, demonstrating a proof of consent for DLT.</p> <p>This RFC  breaks down key components to generate an explicit consent directive with the use of a personal data processing notice (PDP-N) specification which is provided with this RFC as a template for smart privacy.  Appendix - PDP - Notice Spec (DLC Extension for CR v2)</p> <p>This reference RFC utilises a unified legal data control vocabulary for notification and consent records and receipts  (see Appendix A), maintained by the W3C Data Privacy Vocabulary Control Community Group (DPV), where the unified data control vocabulary is actively being maintained.</p> <p>This RFC modularizes data capture to make the mappings interchangeable with overlays  (OCA -Ref), to facilitate scale of data control sets across contexts, domains and jurisdictions.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#motivation","title":"Motivation","text":"<p>A key challenge with privacy and personal data sharing and self-initiated consent is to establish trust. There is no trust in the personal data based economy. GDPR Article 25, Data Protection by Design and by Default, lists recommendations on how private data is processed. Here we list the technology changes required to implement that GDPR article. Note the RFC focuses on formalizing the processing agreement associated with the consent, rather than on informal consent dialogue.</p> <p>Hyperledger Aries provides the perfect framework for managing personal data, especially personal identifiable information (PII), when necessary data is restricted to protect the identity of the individual or data subject. Currently, the privacy policy that is agreed to when signing up for a new service dictates how personal data is processed and for which purpose. There is no clear technology to hold a company accountable for the privacy policy. By using blockchain and the data consent receipt, accountability of a privacy policy can be reached. The data consent is not limited to a single data controller (or institution) and data subject (or individual), but to a series of institutions that process the data from the original data subject. The beauty of the proposal in this RFC is that accountability is extended to ALL parties using the data subject's personal data. When the data subject withdraws consent, the data consent receipt agreement is withdrawn, too.</p> <p>GDPR lacks specifics regarding how technology should be or can be used to enforce obligations. This RFC provides a viable alternative with the mechanisms to bring accountability and at the same time protecting personal data.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#overview","title":"Overview","text":"<p>Three key components need to be in place:</p> <ol> <li> <p>Schema bases/overlays</p> </li> <li> <p>Consent Lifecycle</p> </li> <li> <p>Wallet</p> </li> </ol> <p>Schema bases/overlays describes a standard approach to data capture that separates raw schema building blocks from additional semantic layers such as data entry business logic and constraints, knowledge about data sensitivity, and so forth (refer to [RFC 0013: Overlays for details). The data consent lifecycle covers the data consent receipt certificate, proof request and revocation. The wallet is where all data is stored which requires a high level of security and control by individual or institution. This RFC will cover the consent lifecycle.</p> <p>The Concepts section below explains the RFC in GDPR terms. There is an attempt to align with the vocabulary in the W3C Data Privacy Vocabulary specification.</p> <p>The consent lifecycle will be based on self sovereign identity (SSI) to  ensure that the individual (data subject) has full control of their personal information. To help illustrate how SSI is applied several use cases along a reference implementation will help show the relation between the data subject, data controller and data processor.</p> <p></p>"},{"location":"concepts/0167-data-consent-lifecycle/#concepts","title":"Concepts","text":"<p>These are some ../../concepts that are important to understand when reviewing this RFC.</p> <p>Secondary Data Controller: The terms \"data subject\" and \"data controller\" (see GDPR Article 4, items 1 and 7) should be well understood. The data controller is responsible for the data that is shared beyond their control. A data controller which does not itself collect data but receives it from another controller is termed a 'secondary' data controller. Even though the secondary data controller is independent in its processing of personal data, GDPR requires the primary or original data controller to be responsible for sharing data under the given consent. The 3<sup>rd</sup> party becomes a secondary controller under the responsibility of the original data controller. Important to note that if a 3<sup>rd</sup> party does not share the collected data back to the original data controller, then the 3<sup>rd</sup> party is considered an independent data controller (add reference to CIEU).</p> <p>Opt-in / Opt-out: These terms describe a request to use personal data beyond the limits of legitimate reasons for conducting a service. If for example the data is shared with a 3<sup>rd</sup> party a consent or opt-in is required. At any point the data subject may withdraw the consent through an opt-out.</p> <p>Expiration: The consent may have time limitations that may require being renewed and does not automatically renew. The data subject may have a yearly subscription or for purposes of a trial there needs to be a mechanism to ensure the consent is limited to the duration of the service.</p> <p>Storage limitation: PII data should not be stored indefinitely and need to have a clear storage limitation. Storage limitation as defined by GDPR is limiting how long PII data is kept to fulfill the legitimate reasons of a service.</p> <p>Processing TTL: Indy currently supports proof only limited to a specific point in time. For companies that collect data over time to check for proof every minute is not a viable solution. The processing TTL gives allowances for data ingestion to be done for an extended period without requiring performing new proof request. Examples will be given that explain the usage of the term.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#use-cases","title":"Use Cases","text":"<p>These are the use cases to help understand the implementation guide. A reference implementation will help in the development.</p> <ol> <li> <p>Alice (data subject) gives data consent by accepting a privacy agreement.</p> </li> <li> <p>Acme (3<sup>rd</sup> party data controller) requests proof that data consent     was given</p> </li> <li> <p>Alice terminates privacy agreement, thus withdrawing her data consent.</p> </li> </ol> <p>Note: additional use cases may be developed based on contributions to this RFC.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#implementation-guidelines","title":"Implementation Guidelines","text":""},{"location":"concepts/0167-data-consent-lifecycle/#collect-personal-data","title":"Collect Personal Data","text":"<p>These are the steps covered with collect personal data:</p> <ul> <li>list personal Identifiable data points</li> <li>list quasi-identifiable data points</li> </ul> <p>The [Blinding Identity Taxonomy] provides a compressive list of data points that are considered sensitive and shall be handled with higher level of security.</p> <p>Section will expand terms of the explanation of personal identifiable and quasi-identifiable terms.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#personal-data-processing-schema","title":"Personal Data Processing Schema","text":"<p>The personal data processing (PDP) schema captures attributes used to defines the conditions of collecting data and conditions how data may be shared or used.</p> <p>These are the PDP schema attributes:</p> Category Attribute Brief description Comment Data subset DID of associated schema or overlay Data object identifier All data objects Industry Scope [1] A predefined description of the industry scope of the issuer. All data objects Storage (raw) Expiration Date The definitive date on which data revocation throughout the chain of engaged private data lockers of all Data Controllers and sub-Data Controllers will automatically occur. In other words when the PDP expires. Access-Window Limitation (Restricted-Time) How long data is kept in the system before being removed. Different from expiration date attribute limitation indicates how long personal data may be used beyond the PDP expires. Request to be forgotten supersedes the limitation. Access-Window PII pseudonymization Data stored with pseudonymization. Conditions of access to are given under purpose attribute of \"Access\" category. Encryption Method of psuedonymization Specify algorithm used for performing anonymisation that is acceptable. Encryption Geographic restriction The data storage has geo location restrictions (country). Demarcation No share The data shall not be shared outside of the Data Controller responsibility. When set no 3<sup>rd</sup> party or Secondary Data Controller are allowed. Demarcation Access (1-n) Purpose The purpose for processing data shall be specified (refer to GDPR Article 4, clause 2, for details on processing details). Applies to both a Data Controller and Secondary Data Controller. Access-Window policyUrl Reference to privacy policy URL that describes policy in human readable form. Access-Window Requires 3PP PDP [2] A PDP is required between Data Controller and Secondary Data Controller in the form of code of conduct agreement. Access-Window Single Use The data is shared only for the purpose of completing the interaction at hand. \"Expiration-Date\" is set to the date of interaction completion. Access-Window PII anonymisation Data stored with no PII association. Encryption [3] Method of anonymisation Specify algorithm used for performing anonymisation that is acceptable. Encryption Multi-attribute anonymisation Quasi-identifiable data may be combined create a finger print of the data subject. When set a method of multi-attribute anonymisation is applied on the data Encryption Method of multi-attribute anonymisation Specifify algorithm used for performing anonymisation that is acceptable (K-anonymity). Encryption Ongoing Use The data is shared for repeated use by the recipient, with no end date or end conditions. However, the data subject may alter the terms of use in the future, and if the alteration in terms is unacceptable to the data controller, the data controller acknowledges that it will thereby incur a duty to delete. In other words, the controller uses the data at the ongoing sufferance of its owner. Access-Window Collection Frequency (Refresh) How frequently the data can be accessed. The collection may be limited to once a day or 1 hour. Purpose of attribute is protect data subject to create a profile of behavior. Access-Window Validity TTL If collection is continuous the validity TTL specifies when to perform new verification. Verification is to check customer withdrew consent. Note this is method for revocation. Access-Window No correlation No correlation is allowed for subset. This means no external data shall be combined for example public data record of the data subject. Correlation Inform correlation Correlation is shared with data subject and what data was combined related to them. Correlation Open correlation Correlation is open and does not need to be informed to data subject. Correlation"},{"location":"concepts/0167-data-consent-lifecycle/#notes","title":"Notes","text":""},{"location":"concepts/0167-data-consent-lifecycle/#1","title":"1","text":"<p>As the PDP schema may be the only compulsory linked schema specified in every schema metadata block, we have an opportunity to store the \"Framework Description\" - a description of the business framework of the issuer.</p> <p>Predefined values could be imported from the GICS \"Description\" entries, or, where missing, NECS \"Description\" entries, courtesy of filtration through the Global Industry Classification Standard (GICS) or New Economy Classification Standard (NECS) ontologies.</p> <p>The predefined values could be determined by the next highest level code to the stored GICS \"Sub-industry\" code (or NECS \"SubSector\" code) held in the associated metadata attribute of the primary schema base to add flexibility of choice for the Issuer.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#2","title":"2","text":"<p>If a PDP is required between the Data Controller (Issuer) and sub-Data Controller, we should have a field(s) to store the Public DID (or Private Data Locker ID) of the sub-Data Controller(s). This will be vital to ensure auto-revocation from all associated private data lockers on the date of expiry.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#3","title":"3","text":"<p>As the \"PII Attribute\" schema object is already in place for Issuer's to flag sensitive data according to the Blinding Identity Taxonomy (BIT), we already have a mechanism in place for PII. Once flagged, we can obviously encrypt sensitive data. Some considerations post PII flagging: (i.) In the Issuer's Private Data Locker : The default position should be to encrypt all sensitive elements. However, the issuer should be able to specify if any of the flagged sensitive elements should remain unencrypted in their private locker. (ii.) In a Public Data Store : all sensitive elements should always be encrypted</p>"},{"location":"concepts/0167-data-consent-lifecycle/#example-schemas","title":"Example: Schemas","text":"<p>When defining a schema there will be a consent schema associated with it.</p> <pre><code>SCHEMA = {\n      did: \"did:sov:3214abcd\",\n    name: 'Demographics',\n    description: \"Created by Faber\",\n    version: '1.0',\n    # MANDATORY KEYS\n    attr_names: {\n      brthd: Date,\n      ageic: Integer\n    },\n    consent: did:schema:27312381238123  # reference to consent schema\n    # Attributes flagged according to the Blinding Identity Taxonomy\n    # by the issuer of the schema\n    # OPTIONAL KEYS\n    frmsrc: \"DEM\"\n}\n</code></pre> <p>The original schema will have a consent schema reference.</p> <pre><code>CONSENT_SCHEMA = {\n    did: \"did:schema:27312381238123\",\n    name: 'Consent schema for consumer behaviour data',\n    description: \"Created by Faber\",\n    version: '1.0',\n    # MANDATORY KEYS\n    attr_names: {\n      expiration: Date,\n      limitation: Date,\n      dictatedBy: String,\n      validityTTL: Integer\n    }\n}\n</code></pre> <p>The consent schema will have specific attributes for managing data.</p> Attribute Purpose Type expiration How long consent valid for Date limitation How long is data kept Date dictatedBy Who sets expiration and limitation String validityTTL Duration proof is valid for purposes of data processing Integer <p>The issuer may optionally define an overlay that sets the consent schema values without input from the data subject.</p> <pre><code>CONSENT_RECEIPT_OVERLAY = {\n  did: \"did:sov:5678abcd\",\n  type: \"spec/overlay/1.0/consent_entry\",\n  name: \"Consent receipt entry overlay for clinical trial\",\n  default_values: [\n    :expiration =&gt; 3 years,\n    :limitation =&gt; 2 years,\n    :dictatedBy = &lt;reference to issuer&gt; # ??? Should the DID of the issuer's DID be used?\n    :validityTTL =&gt; 1 month\n    ]\n}\n</code></pre> <p>If some attributes are identified as sensitive based on the Blinding Identity Taxonomy when a sensitivity overlay is created.</p> <pre><code>SENSITIVE_OVERLAY = {\n    did: \"did:sov:12idksjabcd\",\n  type: \"spec/overlay/1.0/bit\",\n  name: \"Sensitive data for private entity\",\n  attributes: [\n      :ageic\n  ]\n}\n</code></pre> <p>To finalise a consent a proof schema has to be created which lists which schemas and overlays applied and values. The proof is kept off ledger in the wallet.</p> <pre><code>PROOF_SCHEMA = {\n    did: \"did:schema:12341dasd\",\n    name: 'Credential Proof schema',\n    description: \"Created by Rosche\",\n    version: '1.0',\n    # MANDATORY KEYS\n    attr_names: {\n      createdAt: DateTime,           # How long consent valid for.\n      proof_key: \"&lt;crypto asset&gt;\",   # How long data is kept.\n      # Include all the schema did that were agreed upon\n      proof_of: [ \"did:sov:3214abcd\", \"did:sov:1234abcd\"]\n    }\n}\n</code></pre>"},{"location":"concepts/0167-data-consent-lifecycle/#blockchain-prerequisites","title":"Blockchain Prerequisites","text":"<p>These are the considerations when setting up the ledger:</p> <ul> <li>Ledger setup</li> <li>Wallet setup</li> <li>Types of entities</li> <li>Agents (working on behalf of entity)</li> <li>Communication between entities</li> <li>Onboarding</li> <li>Onboarding of data subject</li> </ul>"},{"location":"concepts/0167-data-consent-lifecycle/#data-consent-receipt-certificate","title":"Data Consent Receipt Certificate","text":"<p>These are the steps covered with data consent receipt certificate:</p> <ul> <li>initial agreement of privacy agreement</li> <li>update agreement with changed terms of use</li> <li>update agreement with new opt-in</li> <li>terminate agreement</li> <li>apply option to forget</li> </ul>"},{"location":"concepts/0167-data-consent-lifecycle/#initial-agreement-of-privacy-agreement","title":"Initial agreement of privacy agreement","text":"<p>The following flow diagram for setting up privacy agreement.</p> <p></p>"},{"location":"concepts/0167-data-consent-lifecycle/#proof-request","title":"Proof Request","text":"<p>These are the steps covered with proof request:</p> <ul> <li>performing proof request</li> <li>performing proof request without personal data</li> <li>auditing of proof request by Data Authority</li> </ul> <p>The proof request serves multiple purposes. The main one being the conditions of access are auditable. If a data controller encounters a situation they need to show the consent and conditions of accessing data are meet the proof request provides the evidence. The data subject also has more control of the proof request and in situations the revocation of certificate is not performed this becomes an extra safe guard. An important aspect with proof request is that it can be done without requiring to share any personal data.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#performing-proof-request","title":"Performing Proof Request","text":"<p>The following flow diagram for setting up privacy agreement.</p> <p></p>"},{"location":"concepts/0167-data-consent-lifecycle/#certification-revocation","title":"Certification Revocation","text":"<p>These are the steps covered with certification revocation:</p> <ul> <li> <p>data subject initiated revocation</p> </li> <li> <p>data controller initiated revocation</p> </li> <li> <p>data authority initiated revocation (if owns schema base)</p> </li> </ul>"},{"location":"concepts/0167-data-consent-lifecycle/#implementation-reference","title":"Implementation Reference","text":"<p>A python jupyter notebook is available as reference implementation  to help with implementation. The base for this example is  getting-started jupyter notebook. In order to run the example take the following steps.</p> <ol> <li> <p>Clone indy-sdk \\</p> <pre><code> git clone https://github.com/hyperledger/indy-sdk.git\n</code></pre> <ol> <li>Copy over following files to doc/getting-started \\</li> <li>consent-flow.ipynb</li> <li>docker-compose.yml *</li> </ol> <p>Note * - Reason for changing the docker-compose.yml is to be able to    view consent-flow.ipynb.</p> </li> <li> <p>Ready to start docker-compose \\</p> <p>docker-compose up 4. Open html link and run consent-flow.ipynb</p> </li> </ol>"},{"location":"concepts/0167-data-consent-lifecycle/#reference","title":"Reference","text":"<p>Provide guidance for implementers, procedures to inform testing, interface definitions, formal function prototypes, error codes, diagrams, and other technical details that might be looked up. Strive to guarantee that:</p> <ul> <li> <p>Interactions with other ../../features are clear.</p> </li> <li> <p>Implementation trajectory is well defined.</p> </li> <li> <p>Corner cases are dissected by example.</p> </li> <li> <p>General Data Protection Regulation\\     REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE     COUNCIL of 27 April 2016</p> </li> <li> <p>Data Privacy Vocabulary v0.1\\     Draft Community Group Report 26 July 2019\\     [https://www.w3.org/ns/dpv]</p> </li> <li> <p>Hyperledger Aries is infrastructure for blockchain-rooted,     peer-to-peer interactions\\     [https://github.com/hyperledger/aries-rfcs]</p> </li> <li> <p>Overlays\\     [../0013-overlays/README.md]</p> </li> <li> <p>Blinding Identity Taxonomy\\     Created by Andrew Hughes, last modified on Jun 19, 2019\\     [https://kantarainitiative.org/confluence/display/infosharing/Blinding+Identity+Taxonomy]</p> </li> <li> <p>W3C Verifiable Credential     https://www.w3.org/TR/vc-data-model/</p> </li> </ul>"},{"location":"concepts/0167-data-consent-lifecycle/#annex-a-pdp-schema-mapping-to-kantara-consent-receipt","title":"Annex A: PDP Schema mapping to Kantara Consent Receipt","text":"<p>Kantara has defined a Consent Receipt with a list of mandatory and optional attributes. This annex maps the attributes to the PDP. Many of the attributes are supported through the ledger and is not directly included in the PDP.</p> <p>Note: The draft used for this annex was file \"Consent receipt annex for 29184.docx\".</p> Kantara attribute Hyperledger Indy mapping Version Schema registration Jurisdiction Agent registration Consent Timestamp PDP signed certificate Collection Method - Consent Receipt ID PDP signed certificate Public Key Ledger Language Overlays PII Principal ID Schema/Agent registration PII Controller Agent registration On Behalf Agent registration (1) PII Controller Contract Agent registration (2) PII Controller Address Agent registration PII Controller Email Agent registration PII Controller Phone Agent registration PII Controller URL [OPTIONAL] - Privacy Policy PDP services PDP purposes PDP Purpose Category - Consent Type PDP PII Categories - Primary Purpose PDP Termination Ledger Third Party Name PDP Sensitive PII Schema base <p>Notes</p> <p>(1) Agent may be of type Cloud Agent which works on behalf of an Issuer     (Data Controller). When the institution when they register in     blockchain should make it clear who are they registering on behalf.</p> <p>(2) Controller Contact may change over time and is not a good reference     to be used when accepting a consent. If required suggest include as     part of Agent registration (or requirement)</p>"},{"location":"concepts/0167-data-consent-lifecycle/#prior-art","title":"Prior art","text":""},{"location":"concepts/0167-data-consent-lifecycle/#etl-process","title":"ETL process","text":"<p>Current data processing of PII date is not based on blockchain. Data is processed through ETL routines (ex. AWS API Gateway and Lambda) with a data warehouse (ex. AWS Redshift). The enforcement of GDPR is based on adding configuration routines to enforce storage limitations. Most data warehouses do not implement pseudonymization and may instead opt to have a very short storage limitation of a couple of months. The current practice is to collect as much data as possible which goes against data minimisation.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#personal-data-terms-and-conditions","title":"Personal Data Terms and Conditions","text":"<p>The Customer Commons iniative (customercommons.org) has developed a [terms and conditions] for personal data usage. The implementation of these terms and conditions will be tied to the schema and overlay definitions. The overlay will specify the conditions of sharing. For more broader conditions the schema will have new attributes for actual consent for data sharing. The work by Hypeledger Aries and Customer Commons complement each other.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"concepts/0167-data-consent-lifecycle/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0167-data-consent-lifecycle/#plan","title":"Plan","text":"<ul> <li>Upload consent demo to Indy-sdk</li> </ul>"},{"location":"concepts/0167-data-consent-lifecycle/#todo","title":"ToDo","text":"<ul> <li>Update schema examples</li> </ul>"},{"location":"concepts/0167-data-consent-lifecycle/#comments","title":"Comments","text":"Question From Date Answer Where is consent recorded? Harsh 2019-07-31 There are several types of consent listed below. Where the actual consent is recorded needs Specialised Consent (legal)Generic Consent (legal)General Data Processing Consent"},{"location":"concepts/0207-credential-fraud-threat-model/","title":"0207: Credential Fraud Threat Model","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created. Socialized on an informal credential fraud study group (https://groups.google.com/d/forum/credential-fraud-study) circa 2019.  </li> <li>Start Date: 2019-05-23</li> <li>Tags: concept, credentials</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#summary","title":"Summary","text":"<p>Provides a model for analyzing and preventing fraud with verifiable credentials.</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#motivation","title":"Motivation","text":"<p>Cybersecurity experts often view technology through the lens of a threat model that helps implementers methodically discover and remediate vulnerabilities.</p> <p>Verifiable credentials are a new technology that has enormous potential to shape the digital landscape. However, when used carelessly, they could bring to digital, remote interactions many of the same abuse possibilities that criminals have exploited for generations in face-to-face interactions.</p> <p>We need a base threat model for the specific subdiscipline of verifiable credentials, so implementations and deployments have a clear view of how vulnerabilities might arise, and how they can be eliminated. More specific threat models can build atop this general foundation.</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0207-credential-fraud-threat-model/#scope","title":"Scope","text":"<p>Verifiable credentials are a way to establish trust. They provide value for login, authorization, reputation, and data sharing, and they enable an entire ecosystem of loosely cooperating parties that use different software, follow different business processes, and require different levels of assurance.</p> <p>This looseness and variety presents a challenge. Exhaustively detailing every conceivable abuse in such an ecosystem would be nearly as daunting as trying to model all risk on the internet.</p> <p>This threat model therefore takes a narrower view. We assume the digital landscape (e.g., the internet) as context, with all its vulnerabilities and mitigating best practices. We focus on just the ways that the risks and mitigations for verifiable credential fraud are unique.</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#definition","title":"Definition","text":"<p>Fraud: intentional deception to secure unfair or unlawful gain, or to hurt a victim. Contrast hoax, which is deception for annoyance or entertainment. (paraphrase from Wikipedia)</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#relation-to-familiar-methods","title":"Relation to familiar methods","text":"<p>There are many methods for constructing threat models, including STRIDE, PASTA, LINDDUN, CVSS, and so forth. These are excellent tools. We use insights from them to construct what's offered here, and we borrow some terminology. We recommend them to any issuer, holder, or verifier that wants to deepen their expertise. They are an excellent complement to this RFC.</p> <p>However, this RFC is an actual model, not a method. Also, early exploration of the threat space suggests that with verifiable credentials, patterns of remediation grow more obvious if we categorize vulnerabilities in a specialized way. Therefore, what follows is more than just the mechanical expansion of the STRIDE algorithm or the PASTA process.</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#data-flow-diagram","title":"Data Flow Diagram","text":"<p>Data flows in a verifiable credential ecosystem in approximately the following way:</p> <p></p> <p>Some verifiable credential models include an additional flow (arrow) directly from issuers to verifiers, if they call for revocation to be tested by consulting a revocation list maintained by the issuer.</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#key-questions","title":"Key Questions","text":"<p>Fraud could be categorized in many ways--for example, by how much damage it causes, how easy it is to detect, or how common it is. However, we get predictive power and true insight when we focus on characteristics that lead to different risk profiles and different remediations. For verifiable credentials, this suggests a focus on the following 4 questions:</p> <ol> <li>Who is the perpetrator?</li> <li>Who is directly deceived?</li> <li>When is the deception committed?</li> <li>Where (on which fact) is the deception focused? </li> </ol> <p>We can think of these questions as orthogonal dimensions, where each question is like an axis that has many possible positions or answers. We will enumerate as many answers to these questions as we can, and assign each answer a formal name. Then we can use a terse, almost mathematical notation in the form <code>(w + x + y + z)</code> (where <code>w</code> is an answer to question 1, <code>x</code> is an answer to question 2, and so forth) to identify a fraud potential in 4-dimensional space. For example, a fraud where the holder fools the issuer at time of issuance about subject data might be given by the locus: <code>(liar-holder + fool-issuer + issuance-time + bad-subject-claims)</code>.</p> <p></p> <p>What follows is an exploration of each question and a beginning set of associated answers. We provide at least one example of a situation that embodies each answer, notated with \u21e8. Our catalog is unlikely to be exhaustive; criminal creativity  will find new expressions as we eliminate potential in the obvious places. However, these answers are complete enough to provide significant insight into the risks and remediations in the ecosystem.</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#1-who-is-the-perpetrator","title":"1. Who is the perpetrator?","text":"<ul> <li>1.1 liar-issuer \u21e8 Issuer lies about a fact (e.g., birthdate). \u21e8 Issuer charges to issue a college diploma, but turns out not to be accredited. \u21e8 Issuer signs credential with the wrong key, making it useless.</li> <li>1.2 liar-holder \u21e8 Holder lets a friend use the credential. \u21e8 Holder attests to something that\u2019s not true, that gets incorporated into cred (e.g., claims they haven\u2019t had any seizures lately, as driver\u2019s license is issued--but has actually had them).</li> <li>1.3 liar-subject \u21e8 A subject that is not the holder convinces Issuer of attributes that weren\u2019t actually true. liar-verifier \u21e8 Verifier replays a presentation to impersonate holder.</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#third-parties","title":"third parties","text":"<ul> <li>1.4 fake-issuer \u21e8 charges \u00a350 for a diploma from Oxford, but isn\u2019t actually Oxford.</li> <li>1.5 fake-holder \u21e8 Mallory pretends to be Alice and gets Alice's driver\u2019s license issued to Mallory instead.</li> <li>1.6 fake-verifier \u21e8 Gets holder to prove something to the wrong person.</li> <li>1.7 hacker \u21e8 Hacker alters issuer\u2019s internal DB upon which creds are based. \u21e8 Hacker checks revocation lists on Alice\u2019s credentials to create a fake trail of her proving activities.</li> <li>1.8 malicious-node \u21e8 Malicious node of blockchain reports invalid state of blockchain or revocation upon which validation depends.</li> <li>1.9 malicious-resolver \u21e8 Ledger client or similar claims DID state that is wrong.</li> <li>1.10 malicious-server \u21e8 Serves incorrect revocation list or similar data.</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#combinations","title":"combinations","text":"<ul> <li>1.11 colluding-issuer-holder \u21e8 Deceive verifier by holder presenting and issuer claiming non-revoked cred--but really cred was revoked and the rest of the world knows it.</li> <li>1.12 colluding-issuer-verifier \u21e8 Coordinate to correlate holder without holder knowing. \u21e8 Embed info in the credential that the holder doesn\u2019t realize.</li> <li>1.13 colluding-holder-verifier \u21e8 Deceive issuer about a proving interaction that didn\u2019t actually happen.</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#2-who-is-directly-deceived","title":"2. Who is directly deceived?","text":"<ul> <li>2.1 fool-verifier \u21e8 Present data that doesn\u2019t satisfy a presentation request but convince verifier to accept anyway. \u21e8 Convince verifier to leak data that was proved to them, contrary to terms of use that applied when holder gave data to them.</li> <li>2.2 fool-issuer \u21e8 Convince issuer to reissue without revoking old credential, allowing double spend. \u21e8 Get issuer to issue with faulty data.</li> <li>2.3 fool-holder \u21e8 Verifier gets holder to reveal attributes that are more correlating than they realize, or to reveal without consent. \u21e8 Anonymous person extorts holder claiming to have proof that holder did something embarrassing.</li> <li>2.4 fool-subject \u21e8 Put subject attributes in a credential they didn\u2019t consent to.</li> <li>2.5 fool-auditor \u21e8 Build fake evidence that something was proved when it wasn\u2019t. \u21e8 Remove evidence that something was proved. \u21e8 Build fake evidence that something was NOT proved, when it was. \u21e8 Fake evidence (or evidence that\u2019s circumstantial and true, but irrelevant) presented to law enforcement to harass a holder.</li> <li>2.6 fool-twin \u21e8 A person named \u201cJohn Smith\u201d is extorted with a true credential about \u201cJohn Smith\u201d (a different one) doing something nefarious -- threat to reveal.</li> </ul> <p>Combinations of the above?</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#3-when-is-the-deception-committed","title":"3. When is the deception committed?","text":"<ul> <li>3.1 connection-time \u21e8 insert MITM when two identities first connect--but possibly don\u2019t take advantage of the redirection until a strategic time in the future.</li> <li>3.2 proving-time \u21e8 Get verifier to believe the wrong thing from the presentation.</li> <li>3.3 post-proving-time \u21e8 Lull verifier into continuing to believe something that\u2019s no longer true, but that was true when it was proved long ago.</li> <li>3.4 revocation-time \u21e8 MITM pretends to record revocation but doesn\u2019t actually do so.</li> <li>3.5 revocation-check-time \u21e8 MITM serves up bogus revocation data.</li> <li>3.6 cache-refresh-time \u21e8 Malware on Verifier system changes local record of how long it\u2019s been since testing credential, delaying a needed check.</li> <li>3.7 cache-check-time</li> <li>3.8 before-issuance-time \u21e8 Convince the issuer of something untrue that will alter what they attest about the subject.</li> <li>3.9 issuance-time \u21e8 Issue to the wrong person. \u21e8 Issue twice when intention was one cred per person.</li> <li>3.10 post-issuance-time \u21e8 Convince issuer to revoke for no good reason.</li> <li>3.11 multi-time \u21e8 Fraud must happen at two or more different times to accomplish its objective.</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#4-where-on-which-fact-is-the-deception-focused","title":"4. Where (on which fact) is the deception focused?","text":""},{"location":"concepts/0207-credential-fraud-threat-model/#identity","title":"identity","text":"<ul> <li>4.1 bad-holder-identity \u21e8 Impersonate holder by proving with a device that the holder doesn\u2019t control.</li> <li>4.2 bad-subject-identity \u21e8 Put the wrong father in a birth certificate.</li> <li>4.3 bad-issuer-identity \u21e8 Sign credential with a key belonging to the IRS\u2019s HR department instead of the IRS\u2019s main government agency key.</li> <li>4.4 bad-verifier-identity \u21e8 Get prover to prove something to a MITM pretending to be the legitimate verifier.</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#claims","title":"claims","text":"<ul> <li>4.5 bad-subject-claims</li> <li>4.6 inadequate-claims \u21e8 Get verifier to assume something beyond what the evidence actually supports.</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#context","title":"context","text":"<ul> <li>4.7 bad-timestamp \u21e8 Fraud hinges on claiming a different time for an event than the time it actually occurred.</li> <li>4.8 bad-ledger-read \u21e8 Malicious ledger client returns incorrect data from a query of the ledger. </li> <li>4.9 bad-ledger-write \u21e8 Malicious ledger client alters data before writing it to the ledger.</li> <li>4.10 bad-revoc-read \u21e8 False revocation status is reported when a revocation list or revocation registry is read.</li> <li>4.11 bad-revoc-write \u21e8 Revocation status is not updated when a request to update is submitted.</li> <li>4.12 bad-payment \u21e8 A payment amount, timestamp, or responsibile party is falsified.</li> <li>4.13 bad-did-resolve \u21e8 Invalid or stale results are returned when a DID is resolved.</li> <li>4.14 bad-tamper-check \u21e8 Data is tampered with, but the tampering is not detected.</li> <li>4.15 missing-evidence \u21e8 Issuer subverts audit by removing evidence that they discriminated when a loan was issued.</li> <li>4.16 bad-evidence \u21e8 Issuer subverts audit by creating falsified evidence that they behaved properly when a loan was issued.</li> <li>4.17 bad-compliance \u21e8 Verifier asserts to government or to holder that they\u2019ve complied with GDPR, but this is not actually true.</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#reference","title":"Reference","text":"<p>Provide guidance for implementers, procedures to inform testing, interface definitions, formal function prototypes, error codes, diagrams, and other technical details that might be looked up. Strive to guarantee that:</p> <ul> <li>Interactions with other ../../features are clear.</li> <li>Implementation trajectory is well defined.</li> <li>Corner cases are dissected by example.</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#prior-art","title":"Prior art","text":"<p>Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:</p> <ul> <li>Does this feature exist in other SSI ecosystems and what experience have their community had?</li> <li>For other teams: What lessons can we learn from other attempts?</li> <li>Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.</li> </ul> <p>This section is intended to encourage you as an author to think about the lessons from other implementers, provide readers of your proposal with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if they are an adaptation from other communities.</p> <p>Note that while precedent set by other communities is some motivation, it does not on its own motivate an enhancement proposal here. Please also take into consideration that Aries sometimes intentionally diverges from common identity ../../features.</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0217-linkable-message-paths/","title":"Aries RFC 0217: Linkable Message Paths","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Start Date: 2019-08-26</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0217-linkable-message-paths/#summary","title":"Summary","text":"<p>Describes how to hyperlink to specific elements of specific DIDComm messages.</p>"},{"location":"concepts/0217-linkable-message-paths/#motivation","title":"Motivation","text":"<p>It must be possible to refer to specific pieces of data in specific DIDComm messages. This allows a message later in a protocol to refer to data in a message that preceded it, which is useful for stitching together subprotocols, debugging, error handling, logging, and various other scenarios.</p>"},{"location":"concepts/0217-linkable-message-paths/#tutorial","title":"Tutorial","text":"<p>There are numerous approaches to the general problem of referencing/querying a piece of data in a JSON document. We have chosen JSPath as our solution to that part of the problem; see Prior Art for a summary of that option and a comparison to alternatives.</p> <p>What we need, over and above JSPath, is a URI-oriented way to refer to an individual message, so the rest of the referencing mechanism has a JSON document to start from.</p>"},{"location":"concepts/0217-linkable-message-paths/#didcomm-message-uris","title":"DIDComm Message URIs","text":"<p>A DIDComm message URI (DMURI) is a string that references a sent/received message, using standard URI syntax as specified in RFC 3986. It takes one of the following forms:</p> <ol> <li><code>didcomm://&lt;thid&gt;/&lt;msgid&gt;</code></li> <li><code>didcomm://./&lt;msgid&gt;</code> or <code>didcomm://../&lt;msgid&gt;</code></li> <li><code>didcomm:///&lt;msgid&gt;</code> (note 3 slashes)</li> <li><code>didcomm://&lt;sender&gt;@&lt;thid&gt;/&lt;senderorder&gt;</code></li> </ol> <p>Here, <code>&lt;msgid&gt;</code> is replaced with the value of the <code>@id</code> property of a plaintext DIDComm message; <code>&lt;thid&gt;</code> is replaced with the <code>~thread.thid</code> property, <code>&lt;sender&gt;</code> is replaced with a DID, and <code>&lt;senderorder&gt;</code> is replaced with a zero-based index (the Nth message emitted in the thread by that sender). </p> <p>Form 1 is called absolute form, and is the prefered form of DMURI to use when talking about messages outside the context of an active thread (e.g., in log files)</p> <p>Form 2 is called relative form, and is a convenient way for one message to refer to another within an ongoing interaction. It is relatively explicit and terse. It uses 1 or 2 dots to reference the current or parent thread, and then provides the message id with that thread as context. Referencing more distant parent threads is done with absolute form.</p> <p>Form 3 is called simple form. It omits the thread id entirely. It is maximally short and usually clear enough. However, it is slightly less preferred than forms 1 and 2 because it is possible that some senders might not practice good message ID hygeine that guarantees global message ID uniqueness. When that happens, a message ID could get reused, making this form ambiguous. The most recent message that is known to match the message id must be assumed.</p> <p>Form 4 is called ordered form. It is useful for referencing a message that was never received, making the message's internal <code>@id</code> property unavailable. It might be used to request a resend of a lost message that is uncovered by the gap detection mechanism in DIDComm's message threading.</p> <p>Only parties who have sent or received messages can dereference DMURIs. However, the URIs should be transmittable through any number of third parties who do not understand them, without any loss of utility.</p>"},{"location":"concepts/0217-linkable-message-paths/#combining-a-dmuri-with-a-jspath","title":"Combining a DMURI with a JSPath","text":"<p>A JSPath is concatenated to a DMURI by using an intervening slash delimiter:</p> <p><code>didcomm:///e56085f9-4fe5-40a4-bf15-6438751b3ae8/.~timing.expires_time</code></p> <p>If a JSPath uses characters from RFC 3986's reserved characters list in a context where they have special meaning, they must be percent-encoded.</p>"},{"location":"concepts/0217-linkable-message-paths/#reference","title":"Reference","text":"<p>Provide guidance for implementers, procedures to inform testing, interface definitions, formal function prototypes, error codes, diagrams, and other technical details that might be looked up. Strive to guarantee that:</p> <ul> <li>Interactions with other ../../features are clear.</li> <li>Implementation trajectory is well defined.</li> <li>Corner cases are dissected by example.</li> </ul>"},{"location":"concepts/0217-linkable-message-paths/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"concepts/0217-linkable-message-paths/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"concepts/0217-linkable-message-paths/#prior-art","title":"Prior art","text":"<ul> <li>JSPath: the one we're using. Simple and relatively current, with clean syntax.</li> <li>JSONPath: superseded by JSONQuery</li> <li>JSONQuery: also looks a bit old</li> <li>JSONSelect: old. More like CSS selectors</li> <li>JSONiq: powerful and current, but focuses more on querying; may be overkill for just referencing a subobject</li> </ul>"},{"location":"concepts/0217-linkable-message-paths/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"concepts/0217-linkable-message-paths/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0231-biometric-service-provider/","title":"Aries RFC 0231: Biometric Service Provider","text":"<ul> <li>Authors: John Callahan, Daniel Hardman, Asem Othman</li> <li>Status: PROPOSED</li> <li>Since: 2019-09-24</li> <li>Status Note: Proposed for now based on authors joint work</li> <li>Start Date: 2019-06-01</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0231-biometric-service-provider/#summary","title":"Summary","text":"<p>Biometric services for Identity Verification, Authentication, Recovery and other use cases referred to in Aries RFCs including DKMS.</p>"},{"location":"concepts/0231-biometric-service-provider/#motivation","title":"Motivation","text":"<p>Biometrics play a special role in many identity use cases because of their ability to intrinsically identify a unique individual, but their use depends on a variety of factors including liveness, matching accuracy, ease of acquisition, security and privacy. Use of biometrics is already well established in most countries for domestic and international travel, banking and law enforcement.  In banking, know-your-customer (KYC) and anti-money laundering (AML) laws require some form of biometric(s) when establishing accounts.</p> <p>In this specification, we characterize the functions and schema that biometric service providers (BSPs) must implement to ensure a uniform interface to clients: wallets and agents.  For example, current Automated Biometric Information Systems (ABIS) and other standards (IEEE 2410, FIDO) provide a subset of services but often require proprietary adaptors due to the fragmented history of the biometric market: different modalities (face, fingerprint, iris, etc.) require different functions, schema, and registration information.  More recently, standards have begun to specify functions and schema across biometric modalities.  This specification will adopt these approaches and treat biometric data within an encrypted envelope across modalities.</p>"},{"location":"concepts/0231-biometric-service-provider/#tutorial","title":"Tutorial","text":"<p>One goal of the Biometric Service Provider (BSP) specification is to allow for self-sovereign biometric credentials in a holder's wallet or cloud agent trusted by issuers and verifiers:</p> <p></p> <p>An issuer may collect biometric information from a holder in order to issue credentials (biometric or not). Likewise, a verifier may require biometric matching against the holder's credentials for authentication.  In either case, issuers, holders and verifiers may need to rely on 3<sup>rd</sup> party services to perform biometric matching functions for comparison to authoritative databases.</p>"},{"location":"concepts/0231-biometric-service-provider/#basics","title":"Basics","text":"<p>In general, biometrics are collected during registration from a person and stored for later comparisons.  The registration data is called the Initial Biometric Vector (IBV).  During subsequent sessions, a biometric reading is taken called the Candidate Biometric Vector (CBV) and \"matched\" to the IBV:</p> <p></p> <p>Both the IBV and CBV must be securely stored on a mobile device or server often with the help of hardware-based encryption mechanisms such as a Trusted Execution Environment (TEE) or Hardware Security Module (HSM).  The CBV is typically ephemeral and discarded (using secure erasure) following the match operation.</p> <p>If the IBV and/or CBV are used on a server, any exchange must use strong encryption between client and server if transmitted over public or private networks in case of interception.  Failure to properly protect the collection, transmission, storage and processing of biometric data is a serious offense in most countries and violations are subject to severe fines and/or imprisonment.</p>"},{"location":"concepts/0231-biometric-service-provider/#example-aadhaar","title":"Example: Aadhaar","text":"<p>The Aadhaar system is an operational biometric that provides identity proofing and identity verification services for over 1 billion people in India.  Aadhaar is comprised of many elements with authentication as the most common use case:</p> <p></p> <p>Authentication Service Agents (ASAs) are licensed by the Government of India to pass the verification request via secure channels to the Unique Identification Authority of India (UIDAI) data centre where IBVs are retrieved and matched to incoming CBVs from Authentication User Agencies (AUA) that broker user authentication sessions from point-of-sale (PoS) terminals:</p>"},{"location":"concepts/0231-biometric-service-provider/#use-cases","title":"Use Cases","text":"<p>A Biometric Service Provider (BSP) supports the following use cases. In each case, we distinguish whether the use case requires one-to-one (1:1) matching or one-to-many (1:N) matching:</p> <ol> <li> <p>Device Unlocking - primarily introduced to solve the inconvenience of typing a password into a small mobile device, face and single-digit fingerprint was introduced to mobile devices to protect access to the device resources.  This is a 1:1 match operation.</p> </li> <li> <p>Authentication - the dominant use case for biometrics.  Users must prove they sufficiently match the IBV created during registration in order to access local and remote resources including doors, cars, servers, etc. This is a 1:1 match operation.</p> </li> <li> <p>Identification - an unknown person presents for purposes of determining their identity against a database of registered persons. This is a 1:N match operation because the database(s) must be searched for all IBVs of matching identities.</p> </li> <li> <p>Identity Verification - a person claims a specific identity with associated metadata (e.g., name, address, etc.) and provides a CBV for match against that person's registered biometric data to confirm the claim.  This is a 1:1 match operation.</p> </li> <li> <p>Identity Proofing - a person claims a specific identity with associated metadata (e.g., name, address, etc.) and provides a CBV for match against all persons in database(s) in order to determine the efficacy of their claims and any counter-claims.  This is a 1:N match operation because the database(s) must be searched for all IBVs of matching identities.</p> </li> <li> <p>Deduplication - given a CBV, match against IBVs of all registered identities to determine if already present or not in the database(s). This is a 1:N matching operation.</p> </li> <li> <p>Fraud prevention - A match operation could return confidence score(s) (0..1) rather than a simply boolean.  Confidence score(s) express the probability that the candidate is not an imposter and could be used in risk analysis engines.  This may be a use case for BSP clients.</p> </li> <li> <p>Recovery - Using biometric shards, a process using one's biometrics to recover lost private keys associated with a credential is possible using secret sharing.  This may be a use case for BSP clients.</p> </li> </ol> <p>The previous diagram describing the IBV and CBV collection and matching during registration and presentation did not specify where the IBV is persisted nor where the match operation is performed.  In general, we can divide the use cases into 4 categories depending on where the IBV is persisted and where the match must occur:</p> <p></p> <p>Mobile-Mobile: The IBV is stored on the mobile device and the match with the CBV occurs on the mobile device</p> <p>Mobile-Server: The IBV is stored on the mobile device, but the match occurs on a server</p> <p>Server-Mobile: The IBV is stored on a server, but the match occurs on a mobile device</p> <p>Server-Server: The IBV is stored on a server and the match occurs on a server</p>"},{"location":"concepts/0231-biometric-service-provider/#use-case-1-identity-proofing","title":"Use case 1: Identity Proofing","text":""},{"location":"concepts/0231-biometric-service-provider/#use-case-2-recovery","title":"Use case 2: Recovery","text":""},{"location":"concepts/0231-biometric-service-provider/#reference","title":"Reference","text":"<p>The NIST 800-63-3 publications are guidelines that establish levels of assurance (LOA) for identity proofing (Volume A), authentication (Volume B), and federation (Volume C).  The Biometric Service Provider (BSP) specification deals primarily with identity proofing and authentication.</p> <p>A common misconception is that a biometric is like a password, but cannot be replaced upon loss or compromise.  A biometric is private but not secret, whereas a password is secret and private.  Used correctly, biometrics require presentation attack detection (PAD), also called liveness, to ensure that the sensor is presented with a live face, fingerprints, etc. of a subject rather than a spoof, i.e., a photo, fake fingertips, etc.  Indeed, NIST 800-63-3B requires presence of a person in front of a witness for Identity Assurance Level 3 (IAL3) in identity proofing use cases.NIST characterizes the identity proofing process as follows:</p> <p></p> <p>Remote use of biometrics is increasing as well to streamline on-boarding and recovery processes without having to present to an official.  NIST 800-63-3A introduced remote identity proofing for IAL2 in 2017 with some form of PAD strongly recommended (by reference to NIST 800-63-3B).  Typically, additional measures are combined with biometrics including knowledge-based authentication (KBA), risk scoring and document-based verification to reduce fraud.  </p>"},{"location":"concepts/0231-biometric-service-provider/#protection","title":"Protection","text":"<p>Biometric data is highly sensitive and must be protected wherever and whenever it is collected, transmitted, stored and processed.  In general, some simple rules of thumb include:</p> <ul> <li>Protect biometric data at collection (sensor safeguards)</li> <li>Protect biometric data at rest (special hardware, TPM/TEE, database encryption)</li> <li>Protect biometric data in transit (encrypted communications)</li> <li>Protect biometric data during match (volatile memory protections)</li> <li>Never log biometric data!</li> <li>The Candidate Biometric Vector (CBV) is ephemeral</li> </ul>"},{"location":"concepts/0231-biometric-service-provider/#issues","title":"Issues","text":"<ul> <li>Should define biometric verifiable credential schema(s)</li> <li>Biometric modality agnostic</li> <li>Accommodate Biometric shards</li> <li>Integrate with Ursa crypto</li> <li>Integrate with service endpoint model</li> <li>Allows Issuers, Verifiers, and Holder wallets &amp; agents to invoke services like:</li> <li>Registration </li> <li>Matching</li> <li>Deduplication</li> <li>Verification</li> <li>Provides new services</li> <li>Fuzzy matching</li> <li>Shard management (for DKMS) including Horcrux-based storage options</li> <li>Holder-specific biometric matching \u201cmachine\u201d (using ZK-STARKs)</li> <li>Compatible with trust relationships</li> <li>Supports DID connections/Trust relationships (Holder \u27f7 BSP \u27f7 Verifier)</li> </ul>"},{"location":"concepts/0231-biometric-service-provider/#drawbacks","title":"Drawbacks","text":"<p>Biometrics are explicitly required in many global regulations including NIST (USA), Aadhaar (India), INE (Mexico), and RENIEC (Peru) but also standardized by international organizations for travel (IATA) and finance (FATF).</p>"},{"location":"concepts/0231-biometric-service-provider/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>By addressing biometrics, we seek to provide explicit guidance to developers who will undoubtedly encounter them in many identity credentialing and authentication processes.</p>"},{"location":"concepts/0231-biometric-service-provider/#prior-art","title":"Prior art","text":"<p>Several biometric standards exist that provide frameworks for biometric services including the FIDO family of standards and IEEE 2410.  Within each biometric modality, standards exist to encode representations of biometric information.  For example, fingerprints can be captured as raw images in JPEG or PNG format but also represented as vectors of minutiae encoded in the WSQ format.</p>"},{"location":"concepts/0231-biometric-service-provider/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What is the threat model?</li> <li>Alignment with other RFCs</li> <li>Distributed Key Management RFC (Open Issues and Future Work section)</li> <li>Credential Fraud RFC (Threat model, Patterns &amp; Anti-Patterns)</li> <li>Relation to</li> <li>IEEE 2410 (BOPS)</li> <li>FIDO and new FIDO IDWG (Identity Verification)</li> </ul>"},{"location":"concepts/0231-biometric-service-provider/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0250-rich-schemas/","title":"RFC 0250: Rich Schema Objects","text":"<ul> <li>Author: Ken Ebert, Brent Zundel</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No recent progress and no implementations have been created.</li> <li>Supersedes: this HIPE</li> <li>Start Date: 2019-03-19</li> <li>Tags: concept, rich-schemas</li> </ul>"},{"location":"concepts/0250-rich-schemas/#summary","title":"Summary","text":"<p>A high-level description of the components of an anonymous credential ecosystem that supports rich schemas, W3C Verifiable Credentials and Presentations, and correspondingly rich presentation requests. Rich schemas are hierarchically composable graph-based representations of complex data. For these rich schemas to be incorporated into the aries anonymous credential ecosystem, we also introduce such objects as mappings, encodings, presentation definitions and their associated contexts.</p> <p>Though the goal of this RFC is to describe how rich schemas may be used with anonymous credentials, it will be noted that many of the objects described here may be used to allow any credential system to make use of rich schemas.</p> <p>This RFC provides a brief description of each rich schema object. Future RFCs will provide greater detail for each individual object and will be linked to from this document. The further RFCs will contain examples for each object.</p>"},{"location":"concepts/0250-rich-schemas/#motivation","title":"Motivation","text":""},{"location":"concepts/0250-rich-schemas/#standards-compliance","title":"Standards Compliance","text":"<p>The W3C Verifiable Claims Working Group (VCWG) will soon be releasing a verifiable credential data model. This proposal introduces aries anonymous credentials and presentations which are in compliance with that standard.</p>"},{"location":"concepts/0250-rich-schemas/#interoperability","title":"Interoperability","text":"<p>Compliance with the VCWG data model introduces the possibility of interoperability with other credentials that also comply with the standard. The verifiable credential data model specification is limited to defining the data structure of verifiable credentials and presentations. This includes defining extension points, such as \"proof\" or \"credentialStatus.\"</p> <p>The extensions themselves are outside the scope of the current specification, so interoperability beyond the data model layer will require shared understanding of the extensions used. Work on interoperability of the extensions will be an important aspect of maturing the data model specification and associated protocols.</p> <p>Additionally, the new rich schemas are compatible with or the same as existing schemas defined by industry standards bodies and communities of interest. This means that the rich schemas should be interoperable with those found on schema.org, for example. Schemas can also be readily defined for those organizations that have standards for data representation, but who do not have an existing formal schema representation.</p>"},{"location":"concepts/0250-rich-schemas/#shared-semantic-meaning","title":"Shared Semantic Meaning","text":"<p>The rich schemas and associated constructs are linked data objects that have an explicitly shared context. This allows for all entities in the ecosystem to operate with a shared vocabulary.</p> <p>Because rich schemas are composable, the potential data types that may be used for field values are themselves specified in schemas that are linked to in the property definitions. The shared semantic meaning gives greater assurance that the meaning of the claims in a presentation is in harmony with the semantics the issuer intended to attest when they signed the credential.</p>"},{"location":"concepts/0250-rich-schemas/#improved-predicate-proofs","title":"Improved Predicate Proofs","text":"<p>Introducing standard encoding methods for most data types will enable predicate proof support for floating point numbers, dates and times, and other assorted measurements. We also introduce a mapping object that ties intended encoding methods to each schema property that may be signed so that an issuer will have the ability to canonically specify how the data they wish to sign maps to the signature they provide.</p>"},{"location":"concepts/0250-rich-schemas/#use-of-json-ld","title":"Use of JSON-LD","text":"<p>Rich schema objects primarily wish to benefit from the accessibility of ordinary JSON, but require more sophisticated JSON-LD-driven patterns when the need arises.</p> <p>Each rich schema object will specify the extent to which it supports JSON-LD functionality, and the extent to which JSON-LD processing may be required.</p>"},{"location":"concepts/0250-rich-schemas/#what-the-casual-developer-needs-to-know","title":"What the Casual Developer Needs to Know","text":"<ul> <li> <p>The <code>@</code> character in rich schema objects is reserved for JSON-LD-isms. Any usage of JSON keys that begin with this character is required to be JSON-LD-compatible, and any time you see it, you are seeing JSON-LD at work.</p> </li> <li> <p><code>@context</code> and <code>@type</code> are required at the root of every object. The meaning of these fields in rich schema objects matches JSON-LD's expectations, but you don't need to learn JSON-LD to use them.</p> </li> <li> <p>JSON-LD's more advanced mechanisms are an option--not invoked ad hoc for every type of rich schema object, but specified in the formal description of each rich schema object. Most rich schema objects use no more JSON-LD than <code>@context</code>, <code>@type</code>, and <code>@id</code>.</p> </li> </ul>"},{"location":"concepts/0250-rich-schemas/#details","title":"Details","text":"<p>Compatibility with JSON-LD was evaluated against version 1.1 of the JSON-LD spec, current in early 2019. If material changes in the spec are forthcoming, a new analysis may be worthwhile. Our current understanding follows.</p>"},{"location":"concepts/0250-rich-schemas/#type","title":"<code>@type</code>","text":"<p>The type of an rich schema object, or of an embedded object within a rich schema object, is given by the JSON-LD <code>@type</code> property. JSON-LD requires this value to be an IRI.</p>"},{"location":"concepts/0250-rich-schemas/#id","title":"<code>@id</code>","text":"<p>The identifier for a rich schema object is given by the JSON-LD <code>@id</code> property. JSON-LD requires this value to be an IRI.</p>"},{"location":"concepts/0250-rich-schemas/#context","title":"<code>@context</code>","text":"<p>This is JSON-LD\u2019s namespacing mechanism. It is active in rich schema objects, but can usually be ignored for simple processing, in the same way namespaces in XML are often ignored for simple tasks.</p> <p>Every rich schema object has an associated <code>@context</code>, but for many of them we have chosen to follow the procedure described in section 6 of the JSON-LD spec, which focuses on how ordinary JSON can be interpreted as JSON-LD.</p> <p>Contexts are JSON objects. They are the standard mechanism for defining shared semantic meaning among rich schema objects. Contexts allow schemas, mappings, presentations, etc. to use a common vocabulary when referring to common attributes, i.e. they provide an explicit shared semantic meaning.</p>"},{"location":"concepts/0250-rich-schemas/#ordering","title":"Ordering","text":"<p>JSON-LD specifies that the order of items in arrays is NOT significant, and notes that this is the opposite of the standard assumption for plain JSON. This makes sense when viewed through the lens of JSON-LD\u2019s role as a transformation of RDF, and is a concept supported by rich schema objects.</p>"},{"location":"concepts/0250-rich-schemas/#tutorial","title":"Tutorial","text":"<p>The object ecosystem for anonymous credentials that make use of rich schemas has a lot of familiar items: credentials, credential definitions, schemas, and presentations. Each of these objects has been changed, some slightly, some more significantly, in order to take advantage of the benefits of contextually rich linked schemas and W3C verifiable credentials. More information on each of these objects can be found below.</p> <p>In addition to the familiar objects, we introduce some new objects: contexts, mappings, encodings, and presentation definitions. These serve to bridge between our current powerful signatures and the rich schemas, as well as to take advantage of some of the new capabilities that are introduced.</p> <p> Relationship graph of rich schema objects </p>"},{"location":"concepts/0250-rich-schemas/#verifiable-credentials","title":"Verifiable Credentials","text":"<p>The Verifiable Claims Working Group of the W3C is working to publish a Verifiable Credentials data model specification. Put simply, the goal of the new data format for anonymous credentials is to comply with the W3C specification.</p> <p>The data model introduces some standard properties and a shared vocabulary so that different producers of credentials can better inter-operate.</p>"},{"location":"concepts/0250-rich-schemas/#rich-schemas","title":"Rich Schemas","text":"<p>The proposed rich schemas are JSON-LD objects. This allows credentials issued according to them to have a clear semantic meaning, so that the verifier can know what the issuer intended. They also support explicitly typed properties and semantic inheritance. A schema may include other schemas as property types, or extend another schema with additional properties. For example a schema for \"employee\" may inherit from the schema for \"person.\"</p> <p>Rich schemas are an object that may be used by any verifiable credential system.</p>"},{"location":"concepts/0250-rich-schemas/#mappings","title":"Mappings","text":"<p>Rich schemas are complex, hierarchical, and possibly nested objects. The Camenisch-Lysyanskaya signature scheme used in anonymous credentials requires the attributes to be represented by an array of 256-bit integers. Converting data specified by a rich schema into a flat array of integers requires a mapping object.</p> <p>Mappings serve as a bridge between rich schemas and the flat array of signed integers. A mapping specifies the order in which attributes are transformed and signed. It consists of a set of graph paths and the encoding used for the attribute values specified by those graph paths. Each claim in a mapping has a reference to an encoding, and those encodings are defined in encoding objects.</p> <p>Mappings are written to a data registry so they can be shared by multiple credential definitions. They need to be discoverable. When a mapping has been created or selected by an issuer, it is made part of the credential definition.</p> <p>The mappings serve as a vital part of the verification process. The verifier, upon receipt of a presentation must not only check that the array of integers signed by the issuer is valid, but that the attribute values were transformed and ordered according to the mapping referenced in the credential definition.</p> <p>Note: The anonymous credential signature scheme introduced here is Camenisch-Lysyanskaya signatures. It is the use of this signature scheme in combination with rich schema objects that necessitates a mapping object. If another signature scheme is used which does not have the same requirements, a mapping object may not be necessary or a different mapping object may need to be defined.</p>"},{"location":"concepts/0250-rich-schemas/#encodings","title":"Encodings","text":"<p>All attribute values to be signed in an anonymous credential must be transformed into 256-bit integers in order to support the current Camenisch-Lysyanskaya signature scheme.</p> <p>The introduction of rich schemas and their associated range of possible attribute value data types require correspondingly rich encoding algorithms. The purpose of the encoding object is to specify the algorithm used to perform transformations for each attribute value data type. The encoding algorithms will also allow for extending the cryptographic schemes and various sizes of encodings (256-bit, 384-bit, etc.). The encoding algorithms will allow for broad use of predicate proofs, and avoid hashed values where they are not needed, as hashed values do not support predicate proofs.</p> <p>Encodings, at their heart, describe an algorithm for converting data from one format to another, in a deterministic way. They can therefore be used in myriad ways, not only for the values of attributes within anonymous credentials.</p> <p>Encoding objects are written to a data registry. Encoding objects also allow for a means of extending the standard set of encodings.</p>"},{"location":"concepts/0250-rich-schemas/#credential-definitions","title":"Credential Definitions","text":"<p>Credential definitions provide a method for issuers to specify a schema and mapping object, and provide public key data for anonymous credentials they issue. This ties the schema and public key data values to the issuer. The verifier uses the credential definition to check the validity of each signed credential attribute presented to the verifier.</p>"},{"location":"concepts/0250-rich-schemas/#presentation-definitions","title":"Presentation Definitions","text":"<p>A presentation definition is the means whereby a verifier asks for data from a holder. It contains a set of named desired proof attributes with corresponding restrictions that limit the potential sources for the attribute data according to the desired source schema, issuer DID, credential definition, etc. A presentation definition also contains a similar set of requested predicate proofs, with named attributes and restrictions.</p> <p>It may be helpful to think of a presentation definition as the mirror image of a mapping object. Where a mapping object specifies the graph paths of the attributes to be signed, a presentation definition specifies the graph query that may be fulfilled by such graph paths. The presentation definition does not need to concern itself with specifying a particular mapping that contains the desired graph paths, any mapping that contains those graph paths may be acceptable. The fact that multiple graph paths might satisfy the query adds some complexity to the presentation definition. The query may also restrict the acceptable set of issuers and credential definitions and specify the desired predicates.</p> <p>A presentation definition is expressed using JSON-LD and may be stored in a data registry. This supports re-use, interoperability, and a much richer set of communication options. Multiple verifiers can use the same presentation definitions. A community may specify acceptable presentation definitions for its verifiers, and this acceptable set may be adopted by other communities. Credential offers may include the presentation definition the issuer would like fulfilled by the holder before issuing them a credential. Presentation requests may also be more simply negotiated by pointing to alternative acceptable presentation definitions. Writing a presentation definition to a data registry also allows it to be publicly reviewed for privacy and security considerations and gain or lose reputation.</p> <p>Presentation definitions specify the set of information that a verifier wants from a holder. This is useful regardless of the underlying credential scheme.</p>"},{"location":"concepts/0250-rich-schemas/#presentations","title":"Presentations","text":"<p>The presentation object that makes use of rich schemas is defined by the W3C Verifiable Credentials Data Model, and is known in the specification as a verifiable presentation. The verifiable presentation is defined as a way to present multiple credentials to a verifier in a single package.</p> <p>As with most rich schema objects, verifiable presentations will be useful for credential systems beyond anonymous credentials.</p> <p>The claims that make up a presentation are specified by the presentation definition. For anonymous credentials, the credentials from which these claims originate are used to create new derived credentials that only contain the specified claims and the cryptographic material necessary for proofs. </p> <p>The type of claims in derived credentials is also specified by the presentation definition. These types include revealed and predicate proof claims, for those credential systems which support them. </p> <p>The presentation contains the cryptographic material needed to support a proof that source credentials are all held by the same entity. For anonymous credentials, this is accomplished by proving knowledge of a link secret.</p> <p>A presentation refers to the presentation definition it fulfills. For anonymous credentials, is also refers to the credential definitions on the data registry associated with the source credentials. A presentation is not stored on a data registry.</p> <p>The following image illustrates the relationship between anonymous credentials and presentations:</p> <p></p>"},{"location":"concepts/0250-rich-schemas/#presentation-description","title":"Presentation Description","text":"<p>There may be a number of ways a presentation definition can be used by a holder to produce a presentation, based on the graph queries and other restrictions in the presentation definition. A presentation description describes the source credentials and the process that was used to derive a presentation from them.</p>"},{"location":"concepts/0250-rich-schemas/#reference","title":"Reference","text":"<p>This document draws on a number of other documents, most notably the W3C verifiable credentials and presentation data model.</p> <p>The signature types used for anonymous credentials are the same as those currently used in Indy's anonymous credential and Fabric's idemix systems. Here is the paper that defines Camenisch-Lysyanskaya signatures. They are the source for Indy's AnonCreds protocol.</p>"},{"location":"concepts/0250-rich-schemas/#drawbacks","title":"Drawbacks","text":"<ul> <li> <p>Rich schemas are complex.</p> </li> <li> <p>The formats rely largely on JSON-LD serialization and may be dependent on full or limited JSON-LD processing.</p> </li> </ul>"},{"location":"concepts/0250-rich-schemas/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>This design has the following benefits:   - It complies with the upcoming Verifiable Credentials standard.   - It allows for interoperability with existing schemas, such as those   found on schema.org.   - It adds security guarantees by providing means for validation of   attribute encodings.   - It allows for a broad range of value types to be used in predicate   proofs.   - It introduces presentation definitions that allow for proof   negotiation, rich presentation specification, and an assurance   that the presentation requested complies with security and privacy   concerns.   - It supports discoverability of schemas, mappings, encodings,   presentation definitions, etc.</p>"},{"location":"concepts/0250-rich-schemas/#unresolved-questions","title":"Unresolved questions","text":"<p>This technology is intended for implementation at the SDK API level. It does not address UI tools for the creation or editing of these objects.</p> <p>Variable length attribute lists are only partially addressed using mappings. Variable lists of attributes may be specified by a rich schema, but the maximum number of attributes that may be signed as part of the list must be determined at the time of mapping creation.</p>"},{"location":"concepts/0250-rich-schemas/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0257-private-credential-issuance/","title":"Aries RFC 0257: Private Credential Issuance","text":"<ul> <li>Authors: Daniel Hardman and Lovesh Harchandani</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No recent progress and no implementations have been created.</li> <li>Start Date: 2019-08-26</li> <li>Tags: concept, protocol</li> </ul>"},{"location":"concepts/0257-private-credential-issuance/#summary","title":"Summary","text":"<p>This document describes an approach to let private individuals issue credentials without needing to have a public DID or credential definition on the ledger but more importantly without disclosing their identity to the credential receiver or the verifier. The idea is for the private individual to anchor its identity in a public entity (DID) like an organization. The public entity issues a credential to the private individual which acts as a permission for the private individual to issue credentials on behalf of the public entity. To say it another way, the public entity is delegating the issuance capability to the private individual. The receiver of the delegated credential (from the private individual) does not learn the identity of the private individual but only learn that the public entity has allowed this private individual to issue credentials on its behalf. When such a credential is used for a proof, the verifier's knowledge of the issuer is same as the credential receiver, it only knows identity of the public entity. The contrasts the current anonymous credential scheme used by Aries where the credential receiver and proof verifier know the identity of the credential issuer. Additionally, using the same cryptographic techniques, the private individual can delegate issuance rights further, if allowed by the public entity. </p>"},{"location":"concepts/0257-private-credential-issuance/#motivation","title":"Motivation","text":"<p>As they\u2019ve been implemented so far, verifiable credentials in general, and Indy-style credentials in particular, are not well suited to helping private individuals issue. Here are some use cases we don\u2019t address:</p>"},{"location":"concepts/0257-private-credential-issuance/#recommendations","title":"Recommendations","text":"<p>Alice wants to give Bob a credential saying that he did good work for her as a plumber.</p>"},{"location":"concepts/0257-private-credential-issuance/#testimony","title":"Testimony","text":"<p>Alice isn\u2019t necessarily recommending Bob, but she\u2019s willing to say that he was physically present at her house at 9 am on July 31.</p>"},{"location":"concepts/0257-private-credential-issuance/#payment-receipts","title":"Payment receipts","text":"<p>Bob, a private person selling a car, wants to issue a receipt to Alice, confirming that she paid him the price he was asking.</p>"},{"location":"concepts/0257-private-credential-issuance/#agreements","title":"Agreements","text":"<p>Alice wants to issue a receipt to Carol, acknowledging that she is taking custody of a valuable painting and accepting responsibility for its safety. Essentially, this is Alice formalizing her half of a contract between peers. Carol wants to issue a receipt to Alice, formalizing her agreement to the contract as well. Note that consent receipts, whether they be for data sharing or medical procedures, fall into this category, but the category is broader than consent.</p>"},{"location":"concepts/0257-private-credential-issuance/#delegation","title":"Delegation","text":"<p>Alice wants to let Darla, a babysitter, have the right to seek medical care for her children in Alice\u2019s absence.</p> <p>The reasons why these use cases aren\u2019t well handled are:</p>"},{"location":"concepts/0257-private-credential-issuance/#issuers-are-publicly-disclosed","title":"Issuers are publicly disclosed.","text":"<p>Alice would have to create a wholly public persona and DID for her issuer role--and all issuance she did with that DID would be correlatable. This endangers privacy. (Non-Indy credentials have exactly this same problem; there is nothing about ZKPs that makes this problem arise. But proponents of other credential ecosystems don't consider this risk a concern, so they may not think their credentialing solution has a problem.)</p>"},{"location":"concepts/0257-private-credential-issuance/#issuance-requires-tooling-setup-and-ongoing-maintenance","title":"Issuance requires tooling, setup, and ongoing maintenance.","text":"<p>An issuer needs to register a credential definition and a revocation registry on the ledger, and needs to maintain revocation status. This is an expensive hassle for private individuals. (Setup for credential issuance in non-ZKP ecosystems is also a problem, particularly for revocation. However, it may be more demanding for Indy due to the need for a credential definition and due to the more sophisticated revocation model.)</p>"},{"location":"concepts/0257-private-credential-issuance/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0257-private-credential-issuance/#delegatable-credentials-as-a-tool","title":"Delegatable credentials as a tool","text":"<p>Delegatable Credentials are a useful tool that we can use to solve this problem. They function like special Object Capabilities (OCAP) tokens, and may offer the beginnings of a solution. They definitely address the delegation use cases, at least. Their properties include:</p> <ul> <li> <p>A root issuer that is willing to go through setup and maintenance hassle creates a normal Indy credential and issues it to a normal Indy holder.</p> </li> <li> <p>This root holder can generate a new credential, based on the first one, that extends all or part of the trust from the root credential into a new delegate credential held by a delegate holder. The process of delegating subsets of trust through new delegate credentials can be repeated as often as needed.</p> </li> <li> <p>Each delegate credential embeds a pre-generated proof that the delegate holder derives their authority from the root holder through an unbroken chain of delegation. This proof can use ZKP techniques that are non-correlating and non-identifying of everyone in the chain other than the root issuer. For example, it might prove that the proximate holder was an over-21 resident of a particular city, as supported by evidence from their driver\u2019s license--and that the proximate holder received delegated authority from a root holder that was was the proximate holder\u2019s employer. Embedding proofs of delegation in this way eliminates the need to interact with anyone in the delegation chain. The only thing that these embedded, pre-generated proofs cannot contain is proof of non-revocation. That must be tested by interacting with the blockchain.</p> </li> <li> <p>Only the root issuer has to go through a setup process.</p> </li> <li> <p>Only the root issuer, not any holders in a delegation chain, must be publicly disclosed.</p> </li> <li> <p>All holders can revoke anything that they delegated, by using a revocation mechanism (possibly but not necessarily on a ledger) provided by the root issuer. This registry is unusual compared to that of ordinary credentials, in that others besides the creator of the registry (delegate holders) can write to it directly.</p> </li> </ul>"},{"location":"concepts/0257-private-credential-issuance/#applying-delegatable-credentials-to-other-use-cases","title":"Applying Delegatable Credentials to Other Use Cases","text":"<p>Here is how we might apply delegatable credentials to the private-individuals-can-issue problem.</p> <p>A new kind of issuer is needed, called a private credential facilitator (PCF). The job of a PCF is to eliminate some of the setup and maintenance hassle for private individual issuers by acting as a root issuer in a delegatable credential chain.</p> <p>On demand, a PCF is willing to issue a personal trust root (PTR) credential to any individual who asks. A PTR is a delegatable credential that points to a delegation trust framework where particular delegation patterns and credential schemas are defined. The PTR grants all privileges in that trust framework to its holder. It may also contain fields that describe the holder in certain ways (e.g., the holder is named Alice, the holder has a particular birth date or passport number or credit card number, the holder has a blinded link secret with a certain value, etc), based on things that the individual holder has proved to the PCF. The PCF is not making any strong claim about holder attributes when it issues these PTR credentials; it's just adding a few attributes that can be easily re-proved by Alice in the future, and that can be used to reliably link the holder to more traditional credentials with higher bars for trust. In some ways the PCF acts like a notary by endorsing or passing along credential attributes that originated elsewhere.</p> <p>For example, Alice might approach a PCF and ask for a PTR that she can use as a homeowner who wishes to delegate certain privileges in her smart home to AirBnB guests. The PCF would (probably for a fee) ask Alice to prove her name, address, and home ownership with either verifiable or non-digital credentials, agree with Alice on a trust framework that's useful for AirBnB scenarios, and create a PTR for Alice that gives Alice all privileges for her home under that trust framework.</p> <p>With this PTR in hand, Alice can now begin to delegate or subdivide permissions in whatever way she chooses, without a public DID and without going through any issuer setup herself. She issues (delegates) credentials to each guest, allowing them to adjust the thermostat and unlock the front doors, but not to schedule maintenance on the furnace. Each delegated credential she issues traces its trust back to the PTR and from there, to the PCF.</p> <p>Alice can revoke any credential she has delegated in this way, without coordinating either upstream or downstream. The PCF she contracted with gave her access to do this by either configuring their own revocation registry on the ledger so it was writable by Alice's DID as well as their own, or by providing a database or other source of truth where revocation info could be stored and edited by any of its customers.</p> <p>This use of delegatable credentials is obvious, and helpful. But what's cooler and less obvious is that Alice can also use the PTR and delegatable credential mechanism to address non-delegation use cases. For example, she can issue a degenerate delegated credential to Bob the plumber, granting him zero privileges but attesting to Alice's 5-star rating for the job he did. Bob can use this credential to build his reputation, and can prove that each recommendation is unique because each such recommendation credential is bound to a different link secret, which in turn traces back to a unique human due to the PCF's vetting of Alice when Alice enrolled in the service. If Alice agrees to include information about herself in the recommendation credential, Bob can even display credential-based recommendations (and proofs derived therefrom) on his website, showing that recommendation A came from a woman named Alice who lived in postal code X, whereas recommendation B came from a man named Bob who lived in postal code Y.</p> <p>Lets consider another case where an employee issues a delegated credential on the basis of a credential issued to by the employer. Lets say the PCF is an employer. The PCF issues a PTR credential to each of its employee using which the employee can issue recommendation credentials to different 3<sup>rd</sup> party service providers associated with the employer. The recommender (employee) while issuing a recommendation credential proves that he has a valid non-revoked PTR credential from the PCF. The credential contains the id of the employee, the rating, other data and is signed by the employee's private key. The 3<sup>rd</sup> party service provider can discover the employee's public key from the employer's hosted database. Now the service provider can use this credential to create proofs which do not reveal the identity of the employee but only the employer. If the verifier wanted more protection, he could demand that the service provider verifiably encrypt the employee ID from the PTR credential for the employer such that if the employer wishes (in case of any dispute), deanonymize the employee by decrypting the encrypted employee ID.</p> <p>Alice can issue testimony credentials in the same way she issues recommendation credentials. And she can issue payment receipts the same way.</p>"},{"location":"concepts/0257-private-credential-issuance/#more-about-reputation-management","title":"More about Reputation Management","text":"<p>Reputation requires a tradeoff with privacy; we haven't figured out anonymous reputation yet. If Alice's recommendation of Bob as a plumber (or her testimony that Bob was at her house yesterday) is going to carry any weight, people who see it need to know that the credential used as evidence truly came from a woman named Alice--not from Bob himself. And they need to know that Alice couldn't distort reputation by submitting dozens of recommendations or eyewitness accounts herself.</p> <p>Therefore, issuance of by private individuals should start by carefully answering this question:</p> <p>What characteristic(s) of the issuer will make this credential useful?</p> <p>The characteristics might include:</p> <ul> <li>A combination of the issuer\u2019s attributes that allows verifiers to tell two different issuers apart. Let\u2019s call these data items distinguishing factors.</li> <li>Any attributes of the issuer that may give her credential gravitas / relevance to future verifiers: location, proof of issuer reputation, possibly demographics. Let\u2019s call these data items weighting factors.</li> </ul> <p>Weighting factors are probably irrelevant to payment receipts and agreements; proofs in these use cases are about binary matching, not degree.</p> <p>All of our use cases for individual issuance care about distinguishing factors. Sometimes the distinguishing factors might be fuzzy (enough to tell that Alice-1 recommending Bob as a plumber is different from Alice-2, but not enough to strongly identify); other times they have to be exact. They do need distinguishing factors, though. Where these factors could maybe be fuzzy in recommendations or  do matter, though. In many cases, the distinguishing factors need to be strongly identifying, whereas for recommendations or testimony, fuzzier distinguishing factors might  probably don\u2019t care about weighting factors.</p> <p>Distinguishing factors and weighting factors should be embedded in each delegated credential, to the degree that they will be needed in downstream use to facilitate reputation. In some cases, we may want to use verifiable encryption to embed some of them. This would allow Alice to give an eyewitness testimony credential to Bob, to still remain anonymous from Bob, but to prove to Bob at the time of private issuance that Alice's strong personal identifiers are present, and could be revealed by Alice's PCF (or a designated 3<sup>rd</sup> party) if Bob comes up with a compelling reason.</p>"},{"location":"concepts/0257-private-credential-issuance/#reference","title":"Reference","text":""},{"location":"concepts/0257-private-credential-issuance/#todo","title":"TODO","text":""},{"location":"concepts/0257-private-credential-issuance/#drawbacks","title":"Drawbacks","text":""},{"location":"concepts/0257-private-credential-issuance/#todo_1","title":"TODO","text":""},{"location":"concepts/0257-private-credential-issuance/#rationale-and-alternatives","title":"Rationale and alternatives","text":""},{"location":"concepts/0257-private-credential-issuance/#todo_2","title":"TODO","text":""},{"location":"concepts/0257-private-credential-issuance/#prior-art","title":"Prior art","text":""},{"location":"concepts/0257-private-credential-issuance/#todo_3","title":"TODO","text":""},{"location":"concepts/0257-private-credential-issuance/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"concepts/0257-private-credential-issuance/#todo_4","title":"TODO","text":""},{"location":"concepts/0257-private-credential-issuance/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/","title":"Aries RFC 0268: Unified DIDCOMM Deeplinking","text":"<ul> <li>Authors: Dev Bharel, Alexi Falquier</li> <li>Status: PROPOSED</li> <li>Since: 2019-10-23</li> <li>Status Note: Proposed</li> <li>Start Date: 2018-10-04</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#summary","title":"Summary","text":"<p>A set of specifications for mobile agents to standardize around to provide better interoperable support for DIDCOMM compliant messages. Standards around the way agents intepret these encoded messages allow increased user choice when picking agents. </p> <p>This RFC lists a series of standards which must be followed by an Aires compatible agent for it to be considered interoperable with other agents. </p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#motivation","title":"Motivation","text":"<p>As more and more mobile agents come to market, the user base for these wallets will become increasingly fragmented. As one of the core tennats of SSI is interoperability we want to ensure that messages passed to users from these wallets are in formats that any wallet can digest. We want to ensure that the onboarding experience for new users is as seemless and unified as possible. </p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#tutorial","title":"Tutorial","text":"<p>Alice wants to invite Bob to connect with her. Alice sends Bob a invitation link generated by her Mobile Agent (a wallet provided by ACME Corp). </p> <p>The invitation url takes the form of: \"www.acmecorp.com/invite?d_m=XXXXX\" where the text following the query parameter \"d_m\" is the base64url-encoded invitation. </p> <p>Bob recieves this link and opens it on his phone. Since he doesn't have an Aires wallet, he gets directed to the webpage, \"acmecorp.com/invite\" where there's a list of wallets for each platform that he can choose and pick from. On the page is also the ACME Corp offical wallet. </p> <p>Bob decides to download the ACME Corp wallet and clicks on the link again. Because the ACME Corp wallet registered 'www.acmecorp.com' as it's deeplink, Bob gets prompted to open it in the ACME Corp app. </p> <p>Alice sends a similar invite to Charlie. Charlie uses a wallet distributed by Open Corp. Open Corp does not have the \"acmecorp.com\" URI registered as their deeplink, because they do not own that domain. </p> <p>When Charlie lands on that page, along with the offer for wallets is a QR Code with the encoded invitation and a button that states \"Open in App\". This button launches the didcomm:// custom protocol, which is registered by ALL Aires compatible wallets (in the same way e-mail apps all register mailto: ).</p> <p>Pressing the button prompts Charlie's phone to open the app that can handle didcomm://, which happens to be the wallet app by Open Corp. </p> <p>In both instances, Alice does not need to worry about what wallet the counter party is using and can send didcomm messages with the assurance that the counter party will have a onboarding experience waiting for them even if they don't have a wallet already. </p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#reference","title":"Reference","text":""},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#uri-registration","title":"URI Registration","text":"<p>Each mobile agent should register their own URI to open in app. These URI's should point to a landing invitation page.</p> <p>An example of such a URI page/invitation: \"www.spaceman.id/invite?d_m=\" In this case, if the recepient of this URL has an app that's registered Spaceman.id as it's domain (likely a wallet published by spaceman.id) then it will open the invation in app. If the recepient does not have the app installed, they'll have a page open on their mobile browser with suggestions for DIDCOMM compliant wallets. </p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#invitation-page","title":"Invitation Page","text":"<p>The Invitation page users land on must have a list of DIDCOMM compliant agents for each platform (iOS, Android). A list of these can be found here:</p> <p>The Invitation page must also show the encoded message as a scannable QR code and have a button (\"Open in App\") to manually launch the didcomm:// protcol.  The QR code helps interactions between web and mobile agent wallets. </p> <p>The button to manually launch the didcomm:// protocol allows other Aires wallets on their phone to launch to handle the message, even if they haven't registered that specific URI. Alternatively you can use a library to automatically launch the didcomm:// prefix when the webpage is opened.</p> <p>The Invitation page should also run a URL shortner service. This would help passing messages between services easily without needing to pass massive strings around. This also prevents polluting closed source properitary services with links. </p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#deeplink-prefix","title":"Deeplink Prefix","text":"<p>There must exist a common prefix for mobile agents to register for DIDCOMM messages. This vastly improves interoperability between agents and messages, as they can be opened by any wallet. As the messages are all off the DIDCOMM family, we think the prefix that is best suited is didcomm:// </p> <p>All Mobile Agents should register didcomm:// as affilated with their app to both iOS and Android. This will enable users to be prompted to use their wallet when they  recieve a DIDCOMM message.</p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#message-requirements","title":"Message Requirements","text":"<p>Proposed is a change to the query parameter usually used for the passing of the message from 'c_i' which stands for connection invite to the more inclusive 'd_m' which stands for DIDCOMM message. </p> <p>Furthermore, messages must also be base64 encoded serialized jsons, stripped of any excess space and as small as possible. </p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#drawbacks","title":"Drawbacks","text":"<p>This puts extra work on wallet developers to ensure a good experience. </p> <p>On iOS only one app can be registered to handle <code>didcomm://</code> at a time; the first one to be installed will prevent others from using this custom scheme.</p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>This allows each wallet to define their own invite page (or use an existing page provided by the community) while providing a common protocol scheme (didcomm://) for all applications. </p> <p>If we don't do this, there's a chance that wallet applications become unable to communicate with each other effecively during the onboarding process, leading to fragmentation, much like in the IM world. </p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#prior-art","title":"Prior Art","text":""},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#unresolved-questions","title":"Unresolved Questions","text":""},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes.</p> Name / Link Implementation Notes"},{"location":"concepts/0270-interop-test-suite/","title":"0270: Interop Test Suite","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: PROPOSED</li> <li>Since: 2019-10-25</li> <li>Status Note: Codifies some thinking about scope and mental model that are already socialized. Provides some new thinking as well.</li> <li>Supersedes: Partially, and in some ways, Indy HIPE 0015 and Indy HIPE 0016. Also, represents answers to questions that the community first posed in this HackMD doc and first attempted to answer in the indy-agent repo.</li> <li>Start Date: 2018-10-25</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0270-interop-test-suite/#summary","title":"Summary","text":"<p>Describes the goals, scope, and interoperability contract of the Aries Interop Test Suite. Does NOT serve as a design doc for the test suite code, or as a developer guide explaining how the test suite can be run; see the test suite codebase for that.</p>"},{"location":"concepts/0270-interop-test-suite/#motivation","title":"Motivation","text":"<p>The Aries Interop Test Suite makes SSI interoperability publicly and objectively measurable. It is a major deliverable of the Aries project as a whole--not a minor detail that only test zealots care about. It's important that the entire SSI community understand what it offers, how it works, what its results mean, and how it should be used.</p>"},{"location":"concepts/0270-interop-test-suite/#tutorial","title":"Tutorial","text":"<p>Interoperability is a buzzword in the SSI/decentralized identity space. We all want it.</p> <p>Without careful effort, though, interoperability is subjective and slippery. If products A and B implement the same spec, or if they demo cooperation in a single workflow, does that mean they can be used together? How much? For how long? Across which release boundaries? With what feature caveats?</p> <p>We need a methodology that gives crisp answers to questions like these--and it needs to be more efficient than continuously exercising every feature of every product against ../../features of every other product.</p> <p>However, it's important to temper our ambitions. Standards, community specs, and reference implementations exist, and many of them come with tests or test suites of their own. Products can test themselves with these tools, and with custom tests written by their dev staffs, and make rough guesses about interoperability. The insight we're after is a bit different.</p>"},{"location":"concepts/0270-interop-test-suite/#goals","title":"Goals","text":"<p>What we need is a tool that achieves these goals:</p> <ol> <li> <p>Evaluate practical interoperability of agents.</p> <p>Other software that offers SSI ../../features should also be testable. Here, such components are conflated with agents for simplicity, but it's understood that the suite targets protocol participants no matter what their technical classification.</p> </li> </ol> <p>Focus on remote interactions that deliver business value: high-level protocols built atop DIDComm, such as credential issuance, proving, and introducing, where each participant uses different software. DID methods, ledgers, crypto libraries, credential implementations, and DIDComm infrastructure should have separate tests that are out of scope here. None of these generate deep insight into whether packaged software is interoperable enough to justify purchase decisions; that's the gap we need to plug.</p> <ol> <li> <p>Describe results in a formal, granular, reproducible way that supports comparison between agents A and B, and between A at two different points of time or in two different configurations.</p> <p>This implies a structured report, as well as support for versioning of the suite, the agents under test, and the results.</p> </li> <li> <p>Track the collective community state of the art, so measurements are comprehensive and up-to-date, and so new ideas automatically encounter pressure to be vetted for interoperability.</p> <p>The test suite isn't a compliance tool, and it should be unopinionated about what's important and what's not. However, it should embody a broad list of testable ../../features--certainly, ones that are standard, and often, ones that are still maturing.</p> </li> </ol>"},{"location":"concepts/0270-interop-test-suite/#dos-and-donts","title":"Dos and Don'ts","text":"<p>Based on the preceding context, the following rules guide our understanding of the test suite scope:</p> <ul> <li>DO organize testing around protocols, as this is the major way that interoperability questions manifest. \"Can agent X issue credentials in a way that agent Y accepts?\" is a question about whether X and Y support a common protocol.</li> <li>DO test many protocols.</li> <li>DO allow easy extension for new protocols, both as contributions inside the codebase and as external code added after the test suite is installed.</li> <li>DO evaluate unhappy paths (timeouts, brownouts, graceful handling of version incompatibilities, reporting, troubleshooting...), since practical interoperability is often a function of robustness in suboptimal circumstances. </li> <li>DO test all relevant versions of each protocol. (The test suite does not need to maintain an unreasonably comprehensive inventory of all protocols; old protocols could be retired if they become difficult to support. An agent wishing to certify against an old protocol could download an old version of the test suite to certify. However, we generally want the test suite to support both breadth--many protocols--and depth--multiple protocol versions if they are all in active use.)</li> <li>DO test roles in a protocol separately, and DO test only one agent at a time. The question isn't \"Does agent X support the issuance protocol?\" but rather \"Does agent X support role Y in the issuance protocol?\" All roles in a protocol other than the one role for the one tested agent should be played by the test suite. </li> <li>DO test required and optional decorators to the extent that they are relevant to interoperability.</li> <li>DO distinguish between required and optional ../../features of a protocol in results.</li> <li>DO provide value for agents that talk over transports besides HTTP: BlueTooth, SMTP, AMQP, and so forth -- but DON'T get bogged down in all the permutations of transport and routing.</li> <li>DO describe results in a formally defined data structure that can be prettified in various ways.</li> <li>DO allow the test suite to be an automated step in a CI/CD pipeline.</li> <li>DO evaluate message correctness, but touch more lightly on data correctness. See this discussion about the distinction between messages and data, and note how the Issue Credential and Present Proof protocols push credential and presentation format to a concern about the format of attached data, so the data can evolve at a different rate from the protocol.</li> </ul> <ul> <li>DON'T attempt to replace proper unit, functional, or integration tests for agents.</li> <li>DON'T attempt to replace pen-testing or security analyses.</li> <li>DON'T attempt to replace formal methods (proofs of correctness/eventual consistency/security guarantees)</li> <li>DON'T test governance, policy, regulatory compliance, or similar high-level concerns outside fundamental interoperability. </li> <li>DON'T require manual interaction.</li> <li>DON'T artificially link one protocol's results to another's.</li> <li>DON'T attempt to release the test suite in sync with other Aries artifacts. Rather, use an independent release cadence that many uncoordinated agent projects can leverage per their own convenience.</li> <li>DON'T impose unreasonable processes, tools, architecture constraints, or dependencies on builders of agents or test suite contributors. For example, if the test suite required the agent under test to be instrumented, and the instrumentation library weren't available on certain platforms, that would violate this rule. It should be possible for just about any agent to be put under test, long after its initial design, just by implementing the backchannel.</li> <li>DON'T require that the test suite be runnable by an independent third party; trust results as reported by an agent's own developers. The suite might be relevant in a certification process, but is not intended to embody a certification process in and of itself.</li> <li>DON'T worry about test suite performance much. We want tests to run in minutes, so we shouldn't do anything ridiculously time-consuming--but simplicity of the suite is more important than its efficiency.</li> </ul>"},{"location":"concepts/0270-interop-test-suite/#general-approach","title":"General Approach","text":"<p>We've chosen to pursue these goals by maintaining a modular interop test suite as a deliverable of the Aries project. The test suite is an agent in its own right, albeit an agent with deliberate misbehaviors, a security model unsuitable for production deployment, an independent release schedule, and a desire to use every possible version of every protocol.</p> <p>Currently the suite lives in the <code>aries-protocol-test-suite</code> repo, but the location and codebase could change without invalidating this RFC; the location is an implementation detail.</p>"},{"location":"concepts/0270-interop-test-suite/#contract-between-suite-and-agent-under-test","title":"Contract Between Suite and Agent Under Test","text":"<p>The contract between the test suite and the agents it tests is:</p>"},{"location":"concepts/0270-interop-test-suite/#suite-will","title":"Suite will...","text":"<ol> <li> <p>Be packaged for local installation.</p> <p>Packaging could take various convenient forms. Those testing an agent install the suite in an environment that they control, where their agent is already running, and then configure the suite to talk to their agent.</p> </li> <li> <p>Evaluate the agent under test by engaging in protocol interactions over a frontchannel, and control the interactions over a backchannel.</p> <p>Note: Initially, this doc stipulated that both channels should use DIDComm over HTTP. This has triggered some dissonance. If an agent doesn't want to talk HTTP, should it have to, just to be tested? If an agent wants to be controlled over a RESTful interface, shouldn't it be allowed to do that? Answers to the preceding two questions have been proposed (use a generic adapter to transform the protocol, but don't make the test suite talk on a different frontchannel; unless all agents expose the same RESTful interface, the only thing we can count on is that agents will have DIDComm support, and the only methdology we have for uniform specification is to describe a DIDComm-based protocol, so yes, backchannel should be DIDComm). These two incompatible opinions are both alive and well in the community, and we are not yet converging on a consensus. Therefore, the actual implementation of the frontchannel and backchannel remains a bit muddy right now. Perhaps matters will clarify as we think longer and/or as we gain experience with implementation.</p> <p>Over the frontchannel, the test suite and the agent under test look like ordinary agents in the ecosystem; any messages sent over this channel could occur in the wild, with no clue that either party is in testing mode.</p> <p>The backchannel is the place where testing mode manifests. It lets the agent's initial state be set and reset with precision, guarantees its choices at forks in a workflow, eliminates any need for manual interaction, and captures notifications from the agent about errors. Depending on the agent under test, this backchannel may be very simple, or more complex. For more details, see Backchannel below.</p> <p>Agents that interact over other transports on either channel can use transport adapters provided by the test suite, or write their own. HTTP is the least common denominator transport into which any other transports are reinterpreted. Adapting is the job of the agent developer, not the test suite--but the suite will try to make this as easy as possible.</p> <p></p> </li> <li> <p>Not probe for agent ../../features. Instead, it will just run whatever subset of its test inventory is declared relevant by the agent under test.</p> <p>This lets simple agents do simple integrations with the test suite, and avoid lots of needless error handling on both sides.</p> </li> <li> <p>Use a set of predefined identities and a set of starting conditions that all agents under test must be able to recognize on demand; these are referenced on the backchannel in control messages. See Predefined Inventory below.</p> </li> <li> <p>Run tests in arbitrary orders and combinations, but only run one test at a time.</p> <p>Some agents may support lots of concurrency, but the test suite should not assume that all agents do.</p> </li> <li> <p>Produce an interop profile for the agent under test, with respect to the tested ../../features, for every successful run of the test suite.</p> <p>A \"successful\" run is one where the test suite runs to completion and believes it has valid data; it has nothing to do with how many tests are passed by the agent under test. The test suite will not emit profiles for unsuccessful runs.</p> <p>Interop profiles emitted by the test suite are the artifacts that should be hyperlinked in the Implementation Notes section of protocol RFCs. They could also be published (possibly in a prettified form) in release notes, distributed as a product or documentation artifact, or returned as an attachment with the <code>disclose</code> message of the Discover Features protocol.</p> </li> <li> <p>Have a very modest footprint in RAM and on disk, so running it in Docker containers, VMs, and CI/CD pipelines is practical.</p> </li> <li> <p>Run on modern desktop and server operating systems, but not necessarily on embedded or mobile platforms. However, since it interacts with the agent under test over a remote messaging technology, it should be able to test agents running on any platform that's capable of interacting over HTTP or over a transport that can be adapted to HTTP.</p> </li> <li> <p>Enforce reasonable timeouts unless configured not to do so (see note about user interaction below).</p> </li> </ol>"},{"location":"concepts/0270-interop-test-suite/#agent-under-test-will","title":"Agent under test will...","text":"<ol> <li> <p>Provide a consistent name for itself, and a semver-compatible version, so test results can be compared across test suite runs.</p> </li> <li> <p>Use the test suite configuration mechanism to make a claim about the tests that it believes are relevant, based on the ../../features and roles it implements.</p> </li> <li> <p>Implement a distinction between test mode and non-test mode, such that:</p> <ul> <li> <p>Test mode causes the agent to expose and use a backchannel--but the backchannel does not introduce a risk of abuse in production mode.</p> </li> <li> <p>Test mode either causes the agent to need no interaction with a user (preferred), or is combined with test suite config that turns off timeouts (not ideal but may be useful for debugging and mobile agents). This is necessary so the test suite can be automated, or so unpredictable timing on user interaction doesn't cause spurious results.</p> </li> </ul> <p>The mechanism for implementing this mode distinction could be extremely primitive (conditional compilation, cmdline switches, config file, different binaries). It simply has to preserve ordinary control in the agent under test when it's in production, while ceding some control to the test suite as the suite runs.</p> </li> <li> <p>Faithfully create the start conditions implied by named states from the Predefined Inventory, when requested on the backchannel.</p> </li> <li> <p>Accurately report errors on the backchannel.</p> </li> </ol>"},{"location":"concepts/0270-interop-test-suite/#reference","title":"Reference","text":""},{"location":"concepts/0270-interop-test-suite/#releasing-and-versioning","title":"Releasing and Versioning","text":"<p>Defining a release and versioning scheme is important, because the test suite's version is embedded in every interop profile it generates, and people who read test suite output need to reason about whether the results from two different test suites are comparable. By picking the right conventions, we can also avoid a lot of complexity and maintenance overhead.</p> <p>The test suite releases implicitly with every merged commit, and is versioned in a semver-compatible way as follows:</p> <ul> <li> <p>The <code>major</code> version of the test suite version corresponds to the provisions of the contract defined in this RFC. Any breaking changes in this RFC will require an increment of the major number.</p> </li> <li> <p>The <code>minor</code> version of the test suite is a count of how many protocol+version combinations the community knows about. This number is derived from a list of known PIURIs that's autogenerated from metadata about protocols in the <code>aries-rfcs</code> repo. Publishing or versioning a protocol in the community thus automatically causes the test suite's minor version to increment.</p> </li> <li> <p>The <code>patch</code> version of the test suite is the 7-character short form of the git commit hash for the source code from which it is built.</p> </li> </ul> <p>The major version should change rarely, after significant community debate. The minor version should update on a weekly or monthly sort of timeframe as protocols accumulate and evolve in the community--without near-zero release effort by contributors to the test suite. The patch version is updated automatically with every commit. This is a very light process, but it still allows the test suite on Monday and the test suite on Friday to report versions like <code>1.39.5e22189</code> and <code>1.40.c5d8aaf</code>, to know which version of the test suite is later, to know that both versions implement the same contract, and to know that the later version is backwards-compatible with the earlier one.</p>"},{"location":"concepts/0270-interop-test-suite/#test-naming-and-grouping","title":"Test Naming and Grouping","text":"<p>Tests in the test suite are named in a comma-separated form that groups them by protocol, version, role, and behavior, in that order. For example, a test of the <code>holder</code> role in version <code>1.0</code> of the the <code>issue-credential</code> protocol, that checks to see if the holder sends a proper <code>ack</code> at the end, might be named:</p> <pre><code>issue-credential,1.0,holder,sends-final-ack\n</code></pre> <p>Because of punctuation, this format cannot be reflected in function names in code, and it also will probably not be reflected in file names in the test suite codebase. However, it provides useful grouping behavior when sorted, and it is convenient for parsing. It lets agents under test declare patterns of relevant tests with wildcards. An agent that supports the credential issuance but not holding, and that only supports the 1.1 version of the <code>issue-credential</code> protocol, can tell the test suite what's relevant with:</p> <pre><code>issue-credential,1.1,issuer,*\n</code></pre>"},{"location":"concepts/0270-interop-test-suite/#interop-profile","title":"Interop Profile","text":"<p>The results of a test suite run are represented in a JSON object that looks like this:</p> <pre><code>{\n    \"@type\": \"Aries Test Suite Interop Profile v1\"\n    \"suite_version\": \"1.39.5e22189\",\n    \"under_test_name\": \"Aries Static Agent Python\",\n    \"under_test_version\": \"0.9.3\",\n    \"test_time\": \"2019-11-23T18:59:06\", // when test suite launched\n    \"results\": [\n        {\"name\": \"issue-credential,1.0,holder,ignores-spurious-response\", \"pass\": false },\n        {\"name\": \"issue-credential,1.0,holder,sends-final-ack\", \"pass\": true },\n    ]\n}\n</code></pre>"},{"location":"concepts/0270-interop-test-suite/#backchannel","title":"Backchannel","text":"<p>While the concept of a backchannel has been accepted by the community, there is not alignment with the definition of the backchannel provided here. Rather than maintaining this section as related work in the community evolves the concept, we're adding this note to say \"this section will likely change.\" Once backchannel implementations stabilize with a core definition, we'll refine this section as appropriate.</p> <p>The backchannel between test suite and agent under test is managed as a standard DIDComm protocol. The identifier for the message family is X. The messages include:</p> <ul> <li><code>reset-state</code>: Sent from suite to agent. Throws away all current state and gives keys and relationships that must exist in the KMS, by referencing named items from the Predefined Inventory.</li> <li><code>start</code>: Sent from suite to agent. Triggers the agent under test to make the first move in a protocol. Identifies the role the agent should take, and possibly the message type the agent should emit to start, if more than one start message is possible. Also identifies the roles and endpoints for any other participants.</li> <li><code>control-next</code>: Sent from suite to agent. Tells the agent under test what to do the next time it is their turn to make a decision in the protocol. For example, if the protocol under test is tic-tac-toe, this might tell the agent under test what move to make. Does this in a generic way by attaching an approximation of the plaintext message the test suite wants the agent under test to emit. The agent can examine this JSON and act accordingly.</li> <li><code>problem-report</code>: Sent from agent to suite to report errors in the testing procedure itself. Any such message invalidates and abandons the current test.</li> <li><code>report-state-change</code>: Sent from agent to suite to report that it is now in a new state in the protocol.</li> </ul>"},{"location":"concepts/0270-interop-test-suite/#predefined-inventory","title":"Predefined Inventory","text":"<p>TODO: link to the predefined identity for the test suite created by Daniel B, plus the RFC about other predefined DIDs. Any and all of these should be names as possible existing states in the KMS. Other initial states:</p> <ul> <li>totally empty KMS</li> <li>corrupt KMS</li> <li>100 random DIDs from various DID methods, with ratios per method configurable</li> </ul>"},{"location":"concepts/0270-interop-test-suite/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"concepts/0270-interop-test-suite/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0289-toip-stack/","title":"0289: The Trust Over IP Stack","text":"<ul> <li>Authors: Matthew Davie, Dan Gisolfi, Daniel Hardman, John Jordan, Darrell O'Donnell, Drummond Reed, Oskar van Deventer</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No recent progress and no implementations have been created.</li> <li>Start Date: 2019-01-01</li> <li>Tags: concept, stack, trust layer, governance framework</li> </ul>"},{"location":"concepts/0289-toip-stack/#summary","title":"Summary","text":"<p>This Aries concept RFC introduces a complete architecture for Internet-scale digital trust that integrates cryptographic trust at the machine layer with human trust at the business, legal, and social layers.</p>"},{"location":"concepts/0289-toip-stack/#motivations","title":"Motivations","text":"<p>The importance of interoperability for the widespread adoption of an information network architecture has been proven by the dramatic rise to dominance of the Internet [1]. A key driver of the Internet's rise to dominance was the open source implementation of the TCP/IP stack in Version 4.2 of Berkeley Software Distrbution (BSD) of UNIX [2]. This widely-adopted open source implementation of the TCP/IP stack offered the capability for any two peer devices to form a connection and exchange data packets regardless of their local network. In addition, secure protocol suites such as the Secure Sockets Layer (SSL), and its modern version, Transport Layer Security (TLS), have been protecting Internet transactions since 1995.</p> <p>Without a doubt, implementations of the TCP/IP stack, followed by SSL/TLS, have driven a tremendous amount of innovation over the last 30 years. However, although protocols such as TLS offer world-class security, the architecture over which they have been built leaves a significant and widely-recognized gap: a means for any peer to establish trust over these digital connections. For example, while TLS does allow a user to trust she is accessing the right website, it does not offer, at least in an usable way, a way for the user to log in, or prove her identity, to the website. This gap has often been referred to as \"the Internet's missing identity layer\" [3].</p> <p>The purpose of this Aries Concept RFC is to fill this gap by defining a standard information network architecture that developers can implement to establish trusted relationships over digital communicatons networks.</p>"},{"location":"concepts/0289-toip-stack/#architectural-layering-of-the-trust-over-ip-stack","title":"Architectural Layering of the Trust over IP Stack","text":"<p>Since the ultimate purpose of an \"identity layer\" is not actually to identify entities, but to facilitate the trust they need to interact, co-author John Jordan coined the term Trust over IP (ToIP) for this stack. Figure 1 is a diagram of its four layers:</p> <p></p> <p>Figure 1: The ToIP stack</p> <p>Note that it is actually a \"dual stack\": two parallel stacks encompassing both technology and governance. This reflects the fact that digital trust cannot be achieved by technology alone, but only by humans and technology working together.</p> <p>Important: The ToIP stack does not define specific governance frameworks. Rather it is a metamodel for how to design and implement digital governance frameworks that can be universally referenced, understood, and consumed in order to facilitate transitive trust online. This approach to defining governance makes it easier for  humans\u2014and the software agents that represent us at Layer Two\u2014to make trust decisions both within and across trust boundaries.</p> <p>The ToIP Governance Stack plays a special role in ToIP architecture. See the descriptions of the specialized governance frameworks at each layer and also the special section on Scaling Digital Trust.</p>"},{"location":"concepts/0289-toip-stack/#layer-one-public-utilities-for-decentralized-identifiers-dids","title":"Layer One: Public Utilities for Decentralized Identifiers (DIDs)","text":"<p>The ToIP stack is fundamentally made possible by new advancements in cryptography and distributed systems, including blockchains and distributed ledgers. Their high availability and cryptographic verifiability enable strong roots of trust that are decentralized so they will not serve as single points of failure.</p>"},{"location":"concepts/0289-toip-stack/#dids","title":"DIDs","text":"<p>Adapting these decentralized systems to be the base layer of the ToIP stack required a new type of globally unique identifier called a Decentralized Identifier (DID). Starting with a research grant from the U.S. Department of Homeland Security Science &amp; Technology division, the DID specification [4] and the DID Primer [5] were contributed to the W3C Credentials Community Group in June 2017. In September 2019 the W3C launched the DID Working Group to complete the job of turning DIDs into a full W3C standard [6].</p> <p>DIDs are defined by an RFC 3986-compliant URI scheme designed to provide four core properties:</p> <ol> <li>Permanence. A DID effectively functions as a Uniform Resource Name (URN) [7], i.e., once assigned to an entity (called the DID subject), a DID is a persistent identifier for that entity that should never be reassigned to another entity.</li> <li>Resolvability. A DID resolves to a DID document\u2014a data structure (encoded in JSON or other syntaxes) describing the public key(s) and service endpoint(s) necessary to engage in trusted interactions with the DID subject.</li> <li>Cryptographic verifiability. The cryptographic material in a DID document that enables a DID subject to prove cryptographic control of a DID.</li> <li>Decentralization. Because a DID is cryptographically generated and verified, it does not require a centralized registration authority such as those needed for phone numbers, IP addresses, or domain names today.</li> </ol> <p>Figure 2 shows the resemblance between DID syntax and URN syntax (RFC 8141).</p> <p></p> <p>Figure 2: How DID syntax resembles URN syntax</p>"},{"location":"concepts/0289-toip-stack/#did-methods","title":"DID Methods","text":"<p>Like the URN specification, the DID specification also defines a generic URI scheme which is in turn used for defining other specific URI schemes. With DIDs, these are called DID methods. Each DID method is defined by its own DID method specification that must include:</p> <ol> <li>The target system (technically called a verifiable data registry) against which the DID method operates. In the ToIP stack this is called a utility. Note that a utility is not required to be implemented as a blockchain or distributed ledger. DID methods can be designed to work with any type of distributed database, file system, or other system that can anchor a cryptographic root of trust.</li> <li>The DID method name.</li> <li>The syntax of the DID method-specific string.</li> <li>The CRUD (Create, Read, Update, Delete) operations for DIDs and DID documents that conform to the specification.</li> </ol> <p>DIDs have already proved to be a popular solution to decentralized PKI (public key infrastructure) [8]. Over 40 DID methods have already been registered in the informal DID Method Registry [9] hosted by the W3C Credentials Community Group (which the W3C DID Working Group is planning to incorporate into a formal registry as one of its deliverables). The CCG DID Method Registry currently include methods for:</p> <ul> <li>Permissionless blockchains such as Bitcoin (three methods), Ethereum (six methods), Veres One, IOTA, RChain, Ontology, etc.</li> <li>Permissioned ledgers such as the Sovrin ledger.</li> <li>Distributed file systems such as IPFS.</li> <li>Ledgerless P2P networks such as git, JLINC, and peer DIDs.</li> </ul>"},{"location":"concepts/0289-toip-stack/#utility-governance-frameworks","title":"Utility Governance Frameworks","text":"<p>A Layer One public utility may choose any governance model suited to the the constraints of its business model, legal model, and technical architecture. This is true whether the public utility is operated as a blockchain, distributed ledger, or decentralized file store, or whether it is permissioned, permissionless, or any hybrid. (Note that even permissionless blockchain networks still have rules\u2014formal or informal\u2014governing who can update the code.)</p> <p>All ToIP architecture requires is that the governance model conform to the requirements of the ToIP Governance Stack to support both interoperability and transitive trust. This includes transparent identification of the governance authority, the governance framework, and participant nodes or operators; transparent discovery of nodes and/or service endpoints; and transparent security, privacy, data protection, and other operational policies. See the Governance section below.</p> <p>Utility governance frameworks that conform to the ToIP Governance Stack model will support standard roles for all types of utility governance authorities. For example, the role currently supported by public-permissioned utilities such as those based on Hyperledger Indy include:</p> <ul> <li>Transaction Authors: initiate transactions</li> <li>Transaction Endorsers: permission transactions for Transaction Authors</li> <li>Stewards: operate a node of the ledger</li> </ul>"},{"location":"concepts/0289-toip-stack/#layer-one-support-for-higher-layers","title":"Layer One Support for Higher Layers","text":"<p>DIDs and DID documents are not the only cryptographic data structures needed to support the higher layers. Others include:</p> <ul> <li>Schemas define the claims (attributes) that can be included in verifiable credentials (Layer Three).</li> <li>Credential definitions specify the claims and related metadata needed by an issuer of verifiable credentials (Layer Three).</li> <li>Revocation Registries are cryptographic accumulators that enable credential issuers to revoke credentials while still protecting the privacy of the credential holder (Layer Three).</li> <li>Agent Authorization Policies are also cryptographic accumulators that enable credential holders to activate and deactivate agents operating on their behalf at Layer Two. (For more information, see section 5.1 of DKMS Design and Architecture.)</li> </ul> <p>In summary, the interoperability of Layer One is currently defined by the W3C DID specification and by Aries RFCs for the other cryptographic data structures listed above. Any DID registry that supports all of these data structures can work with any agent, wallet, and secure data store that operates at Layer Two.</p>"},{"location":"concepts/0289-toip-stack/#layer-two-the-didcomm-protocol","title":"Layer Two: The DIDComm Protocol","text":"<p>The second layer of the Trust over IP stack is defined by the DIDComm secure messaging standards [10]. This family of specifications, which are now being defined in the DIDComm Working Group at the Decentralized Identity Foundation, establish a cryptographic means by which any two software agents (peers) can securely communicate either directly edge-to-edge or via intermediate cloud agents as shown in Figure 3).</p> <p></p> <p>Figure 3: At Layer Two, agents communicate peer-to-peer using DIDComm standards</p>"},{"location":"concepts/0289-toip-stack/#peer-dids-and-did-to-did-connections","title":"Peer DIDs and DID-to-DID Connections","text":"<p>A fundamental feature of DIDComm is that by default all DID-to-DID connections are established and secured using pairwise pseudonymous peer DIDs as defined in the Peer DID Method Specification [11]. These DIDs are based on key pairs generated and stored by the local cryptographic key management system (KMS, aka \"wallet\") maintained by each agent. Agents then use the DID Exchange protocol to exchange peer DIDs and DID documents in order to establish and maintain secure private connections between each other\u2014including key rotation or revocation as needed during the lifetime of a trusted relationship.</p> <p>Because all of the components of peer DIDs and DID-to-DID connections are created, stored, and managed at Layer Two, there is no need for them to be registered in a Layer One public utility. In fact there are good privacy and security reasons not to\u2014these components can stay entirely private to the peers. As a general rule, the only ToIP actors who should need public DIDs at Layer One are:</p> <ol> <li>Credential issuers as explained in Layer Three below.</li> <li>Governance authorities at any layer as explained in the section on Scaling Digital Trust.</li> </ol> <p>This also means that, once formed, DID-to-DID connections can be used for any type of secure communications between the peers. Furthermore, these connections are capable of lasting literally forever. There are no intermediary service providers of any kind involved. The only reason a DID-to-DID connection needs to broken is if one or both of the peers no longer wants it.</p>"},{"location":"concepts/0289-toip-stack/#agents-and-wallets","title":"Agents and Wallets","text":"<p>At Layer Two, every agent is paired with a digital wallet\u2014or more accurately a KMS (key management system). This KMS can be anything from a very simple static file on an embedded device to a highly sophisticated enterprise-grade key server. Regardless of the complexity, the job of the KMS is to safeguard sensitive data: key pairs, zero-knowledge proof blinded secrets, verifiable credentials, and any other cryptographic material needed to establish and maintain technical trust.</p> <p>This job includes the difficult challenge of recovery after a device is lost or stolen or a KMS is hacked or corrupted. This is the province of decentralized key management. For more details, see the Decentralized Key Management System (DKMS) Design and Architecture document [12], and Dr. Sam Smith's paper on KERI (Key Event Receipt Infrastructure) [13].</p>"},{"location":"concepts/0289-toip-stack/#secure-data-stores","title":"Secure Data Stores","text":"<p>Agents may also be paired with a secure data store\u2014a database with three special properties:</p> <ol> <li>It is controlled exclusively by the DID controller (person, organization, or thing) and not by any intermediary or third party.</li> <li>All the data is encrypted with private keys in the subject\u2019s KMS.</li> <li>If a DID controller has more than one secure data store, the set of stores can be automatically synchronized according to the owner\u2019s preferences.</li> </ol> <p>Work on standardizing secure data stores has been proceeding in several projects in addition to Hyperledger Aries\u2014primarily at the Decentralized Identity Foundation (DIF) and the W3C Credentials Community Group. This has culminated in the formation of the Secure Data Store (SDS) Working Group at DIF.</p>"},{"location":"concepts/0289-toip-stack/#guardianship-and-guardian-agentswallets","title":"Guardianship and Guardian Agents/Wallets","text":"<p>The ToIP stack cannot become a universal layer for digital trust if it ignores the one-third of the world's population that do not have smartphones or Internet access\u2014or the physical, mental, or economic capacity to use ToIP-enabled infrastructure. This underscores the need for the ToIP layer to robustly support the concept of digital guardianship\u2014the combination of a hosted cloud agent/wallet service and an individual or organization willing to take legal responsibility for managing that cloud agent/wallet on behalf of the person under guardianship, called the dependent.</p> <p>For more about all aspects of digital guardianship, see the Sovrin Foundation white paper On Guardianship in Self-Sovereign Identity [14].</p>"},{"location":"concepts/0289-toip-stack/#provider-governance-frameworks","title":"Provider Governance Frameworks","text":"<p>At Layer Two, governance is needed primarily to establish  interoperability testing and certification requirements, including security, privacy, data protection, for the following roles:</p> <ul> <li>Hardware Developers who provider ToIP-compliant hardware, e.g., secure enclaves, trusted execution environments, HSMs.</li> <li>Software Developers who provider ToIP-compliant agents, wallets, secure data stores, etc.</li> <li>Agencies who host ToIP-compliant cloud agents for individuals, organizations, and guardians.</li> </ul>"},{"location":"concepts/0289-toip-stack/#layer-two-support-for-higher-layers","title":"Layer Two Support for Higher Layers","text":"<p>The purpose of Layer Two is to enable peers to form secure DID-to-DID connections so they can:</p> <ol> <li>Issue, exchange, and verify credentials over these connections using the data exchange protocols at Layer Three.</li> <li>Access the Layer One cryptographic data structures needed to issue and verify Layer Three credentials regardless of the public utility used by the issuer.</li> <li>Migrate and port ToIP data between agents, wallets, and  secure data stores without restriction. This data portability is critical to the broad adoption and interoperability of ToIP.</li> </ol>"},{"location":"concepts/0289-toip-stack/#layer-three-data-exchange-protocols","title":"Layer Three: Data Exchange Protocols","text":"<p>Layer One and Layer Two together enable the establishment of cryptographic trust (also called technical trust) between peers. By contrast, the purpose of Layers Three and Four is to establish human trust between peers\u2014trust between real-world individuals and organizations and the things with which they interact (devices, sensors, appliances, vehicles, buildings, etc.)</p> <p>Part of the power of the DIDComm protocol at Layer Two is that it lays the foundation for secure, private agent-to-agent connections that can now \"speak\" any number of data exchange protocols. From the standpoint of the ToIP stack, the most important of these are protocols that support the exchange of verifiable credentials.</p>"},{"location":"concepts/0289-toip-stack/#the-verifiable-credentials-data-model","title":"The Verifiable Credentials Data Model","text":"<p>After several years of incubation led by Manu Sporny, David Longley, and other members of the W3C Credentials Community Group, the W3C Verifiable Claims Working Group (VCWG) was formed in 2017 and produced the Verifiable Credentials Data Model 1.0 which became a W3C Recommendation in September 2019 [15].</p> <p>Figure 4 is a diagram of the three core roles in verifiable credential exchange\u2014often called the \"trust triangle\". For more information see the Verifiable Credentials Primer [16].</p> <p></p> <p>Figure 4: The three primary roles in the W3C Verifiable Credentials Data Model</p> <p>The core goal of the Verifiable Credentials standard is to enable us to finally have the digital equivalent of the physical credentials we store in our physical wallets to provide proof of our identity and attributes every day. This is why the presentation of a verifiable credential to a verified is call a proof\u2014it is both a cryptographic proof and a proof of some set of attributes or relationships a verifier needs to make a trust decision.</p>"},{"location":"concepts/0289-toip-stack/#credential-proof-types","title":"Credential Proof Types","text":"<p>The Verifiable Credentials Data Model 1.0 supports several different cryptographic proof types:</p> <ol> <li>JSON Web Tokens (JWTs) secured using JSON Web Signatures.</li> <li>Linked Data Signatures using JSON-LD.</li> <li>Zero Knowledge Proofs (ZKPs) using Camenisch-Lysyanskaya Signatures.</li> </ol> <p>All three proof types address specific needs in the market:</p> <ul> <li>JWTs are widely used in the JOSE stack and federated identity infrastructure.</li> <li>Linked Data Signatures are used in wide-area data integration and other Semantic Web applications.</li> <li>ZKP-based credentials enable credential holders to selectively disclose claims to verifiers without unintentional correlation\u2014a significant advancement in Privacy by Design architecture that simplifies compliance with the EU General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), and similar data protection regulations.</li> </ul> <p>To support all three of these credential proof types in the ToIP stack means:</p> <ul> <li>Layer One must support the data structures necessary to issue and verify each proof type.</li> <li>Layer Two agents, wallets, and secure data stores must support storage and export of the cryptographic materials needed for each proof type.</li> <li>Layer Three must support credential exchange protocols for each proof type.</li> </ul>"},{"location":"concepts/0289-toip-stack/#credential-exchange-protocols","title":"Credential Exchange Protocols","text":"<p>At Layer Three, the exchange of verifiable credentials is performed by agents using data exchange protocols layered over the DIDComm protocol. These data exchange protocol specifications are being published as part of the DIDComm suite [10]. Credential exchange protocols are unique to each credential proof type because the request and response formats are different. The goal of the ToIP technology stack is to standardize all supported credential exchange protocols so that any ToIP-compatible agent, wallet, and secure data store can work with any other agent, wallet, and secure data store.</p> <p>With fully interoperable verifiable credentials, any issuer may issue any set of claims to any holder who can then prove them to any verifier. Every verifier can decide which issuers and which claims it will trust. This is a fully decentralized system that uses the same trust triangle as the physical credentials we carry in our physical wallets today. This simple, universal trust model can be adapted to any set of requirements from any trust community. Even better, in most cases it does not require new  policies or business relationships. Instead the same policies that apply to existing physical credentials can just be applied to a new, more flexible and useful digital format.</p>"},{"location":"concepts/0289-toip-stack/#credential-governance-frameworks","title":"Credential Governance Frameworks","text":"<p>Since Layer Three is where the ToIP stack crosses over from technical trust to human trust, this is the layer where governance frameworks become a critical component for interoperability and scalability of digital trust ecosystems. Credential governance frameworks can be used to specify:</p> <ul> <li>Credential schema definitions.</li> <li>The rules governing who can serve as the authoritative issuers for those credentials.</li> <li>The policies those issuers must follow to issue and revoke those credentials.</li> <li>Applicable business models, liability frameworks, and insurance models.</li> </ul> <p>Standard roles that credential governance frameworks can define under the ToIP Governance Stack model include:</p> <ul> <li>Authoritative Issuers are issuers authorized by the governance authority to issue specific types of credentials at specific levels of assurance</li> <li>Credential Registries are alternative holders of credentials to support other uses, such as public searchable directory services.</li> <li>Insurers provide insurance to issuers operating under the terms of the governance framework.</li> </ul>"},{"location":"concepts/0289-toip-stack/#layer-three-support-for-higher-layers","title":"Layer Three Support for Higher Layers","text":"<p>Layer Three enables human trust\u2014in the form of verifiable assertions about entities, attributes and relationships\u2014to be layered over the cryptographic trust provided by Layers One and Two. Layer Four is the application ecosystems that request and consume these verifiable credentials in order to support the specific trust models and policies of their own digital trust ecosystem.</p>"},{"location":"concepts/0289-toip-stack/#layer-four-application-ecosystems","title":"Layer Four: Application Ecosystems","text":"<p>Layer Four is the layer where humans interact with applications in order to engage in trusted interactions that serve a specific business, legal, or social purpose. Just as applications call the TCP/IP stack to communicate over the Internet, applications call the ToIP stack to register DIDs, form connections, obtain and exchange verifiable credentials, and engage in trusted data exchange using the protocols in Layers One, Two, and Three.</p> <p>The ToIP stack no more  limits the applications that can be built on it than the TCP/IP stack  limits the applications that can be built on the Internet. The ToIP stack simply defines the \"tools and rules\"\u2014technology and governance\u2014for those applications to interoperate within digital trust ecosystems that provide the security, privacy, and data protection that their members expect. The ToIP stack also enables the consistent user experience of trust decisions across applications and ecosystems that is critical to achieving widespread trust online\u2014just as a consistent user experience of the controls for driving a car (steering wheel, gas pedal, brakes, turn signals) are critical to the safety of drivers throughout the world.</p>"},{"location":"concepts/0289-toip-stack/#ecosystem-governance-frameworks","title":"Ecosystem Governance Frameworks","text":"<p>Layer Four is where humans will directly experience the ToIP Governance Stack\u2014specifically the trust marks and policy promises of ecosystem governance frameworks. These specify the purpose, principes, and policies that apply to all  governance authorities and governance frameworks operating within that ecosystem\u2014at all four levels of the ToIP stack.</p> <p>The ToIP Governance Stack will define standard roles that can be included in an ecosystem governance framework (EGF) including:</p> <ul> <li>Member Directories the provide both human- and machine-searchable listings of the public DIDs and other searchable attributes of participants in the EGF.</li> <li>Auditors who can audit participants in a EGF for compliance with the EGF policies.</li> <li>Accreditors who can accredit auditors when a EGF needs to scale nationally or globally.</li> </ul> <p>To fully understand the scope and power of ecosystem governance frameworks, let us dive deeper into the special role of the ToIP Governance Stack.</p>"},{"location":"concepts/0289-toip-stack/#scaling-digital-trust","title":"Scaling Digital Trust","text":"<p>The top half of Figure 5 below shows the basic trust triangle architecture used by verifiable credentials. The bottom half shows a second trust triangle\u2014the governance trust triangle\u2014that can solve a number of problems related to the real-world adoption and scalability of verifiable credentials and the ToIP stack.</p> <p></p> <p>Figure 5: The special role of governance frameworks</p>"},{"location":"concepts/0289-toip-stack/#governance-authorities","title":"Governance Authorities","text":"<p>The governance trust triangle in Figure 5 represents the same governance model that exists for many of the most successful physical credentials we use every day: passports, driving licenses, credit cards, health insurance cards, etc.</p> <p>These credentials are \"backed\" by rules and policies that in many cases have taken decades to evolve. These rules and policies have been developed, published, and enforced by many different types of existing governance authorities\u2014private companies, industry consortia, financial networks, and of course governments.</p> <p>The same model can be applied to verifiable credentials simply by having these same governance authorities\u2014or new ones formed explicitly for ToIP governance\u2014publish digital governance frameworks. Any group of issuers who want to standardize, strengthen, and scale the credentials they offer can join together under the auspices of a sponsoring authority to craft a governance framework. No matter the form of the organization\u2014government, consortia, association, cooperative\u2014the purpose is the same: define the business, legal, and technical rules under which the members agree to operate in order to achieve trust.</p> <p>This of course is exactly how Mastercard and Visa\u2014two of the world\u2019s largest trust networks\u2014have scaled. Any bank or merchant can verify in seconds that another bank or merchant is a member of the network and thus bound by its rules.</p> <p>With the ToIP stack, this governance architecture can be applied to any set of roles and/or credentials, for any trust community, of any size, in any jurisdiction.</p> <p>As an historical note, some facets of the ToIP governance stack are inspired by the Sovrin Governance Framework (SGF) [17] developed starting in 2017 by the Sovrin Foundation, the governance authority for the Sovrin public ledger for self-sovereign identity (SSI).</p>"},{"location":"concepts/0289-toip-stack/#defining-a-governance-framework","title":"Defining a Governance Framework","text":"<p>In addition to the overall metamodel, the ToIP governance stack will provide an architectural model for individual governance frameworks at any level. This enables the components of the governance framework to be expressed in a standard, modular format so they can be easily indexed and referenced both internally and externally from other governance frameworks.</p> <p>Figure 6 shows this basic architectural model:</p> <p></p> <p>Figure 6: Anatomy of a governance framework</p>"},{"location":"concepts/0289-toip-stack/#discovery-and-verification-of-authoritative-issuers","title":"Discovery and Verification of Authoritative Issuers","text":"<p>Verifiers often need to verify that a credential was issued by an authoritative issuer. The ToIP stack will give governance authorities multiple mechanisms for designating their set of authoritative issuers (these options are non-exclusive\u2014they can each be used independently or in any combination):</p> <ol> <li>DID Documents. The governance authority can publish the list of their DIDs in a DID document on one or more public utilities of its choice.</li> <li>Member Directories. A governance authority can publish a \"whitelist\" of DIDs via a whitelisting service available at a standard service endpoint published in the governance authority\u2019s own DID document.</li> <li>Credential registries. If search and discovery of authoritative issuers is desired, a governance authority can publish verifiable credentials containing both the DID and additional attributes for each authoritative issuer in a credential registry.  Note that in this case the credential registry serves as a separate, cryptographically-verifiable holder of the credential\u2014a holder that is not the subject of the credential, but which can independently prove the validity of the credential.</li> <li>Verifiable credentials. As shown in Figure 5, the governance authority (or its designated auditors) can issue verifiable credentials to the authoritative issuers, which they in turn can provide directly to verifiers or indirectly via credential holders.</li> </ol>"},{"location":"concepts/0289-toip-stack/#discovery-and-verification-of-authoritative-verifiers","title":"Discovery and Verification of Authoritative Verifiers","text":"<p>Holders often need to verify that a credential was requested by an authoritative verifier, e.g. as part of a \u2018machine readable governance framework\u2019. The ToIP stack will give governance authorities multiple mechanisms for designating their set of authoritative verifiers (these options are non-exclusive\u2014they can be used independently or in any combination):</p> <ol> <li>DID Documents. The governance authority can publish the list of their DIDs in a DID document on one or more verifiable data registries of its choice.</li> <li>Member Directories. A governance authority can publish a \"whitelist\" of DIDs via a whitelisting service available at a standard service endpoint published in the governance authority\u2019s own DID document.</li> <li>Credential registries. If search and discovery of authoritative verifiers is desired, a governance authority can publish verifiable credentials containing both the DID and additional attributes for each authoritative verifiers in a credential registry.  Note that in this case the credential registry serves as a separate, cryptographically-verifiable holder of the credential\u2014a holder that is not the subject of the credential, but which can independently prove the validity of the credential.</li> <li>Verifiable credentials. Similar to Figure 5, the governance authority (or its designated auditors) can issue verifiable credentials to the authoritative issuers in the governance framework. Those issuers can in turn provide proofs directly to holders or verifiers.</li> </ol>"},{"location":"concepts/0289-toip-stack/#countermeasures-against-coercion","title":"Countermeasures against coercion","text":"<p>The concept of \"self-sovereign\" identity presumes that parties are free to enter a transaction, to share personal and confidential information, and to walk away when requests by the other party are deemed unreasonable or even unlawful. In practice, this is often not the case: \"What do you give an 800-pound gorilla?\", answer: \"Anything that it asks for\". Examples of such 800-pound gorillas are some big-tech websites, immigration offices and uniformed individuals alleging to represent law-enforcement [20][21]. Also the typical client-server nature of web transactions reinforces this power imbalance, where the human party behind its client agent feels coerced in surrendering personal data as otherwise they are denied access to a product, service or location. Point in case are the infamous cookie walls, where a visitor of a website get the choice between \"accept all cookies or go into the maze-without-exit\".</p> <p>Governance frameworks may be certified to implement one or more potential countermeasures against different types of coercion. In case of a machine readable governance framework, some of such countermeasures may be automatically enforced, safeguarding its user from being coerced into action against their own interest. Different governance frameworks may choose different balances between full self-sovereignty and tight control, depending of the interests that are at play as well as applicable legislation.</p> <p>The following are examples of potential countermeasures against coercion. The governance framework can stimulate or enforce that some verifiable credentials are only presented when the holder agent determines that some requirements are satisfied. When a requirement is not fulfilled, the user is warned about the violation and the holder agent may refuse presentation of the requested verifiable credential. 1. Require authoritative verifier. Verifiers would need to be authorized within the applicable governance framework, see also section \u201cDiscovery and Verification of Authoritative Verifiers\u201d. 2. Require evidence collection. Requests for presentation of verifiable credentials may hold up as evidence in court, if the electronic signature on the requests is linked to the verifier in a non-repudiable way. 3. Require enabling anonymous complaints. The above evidence collection may be compromised if the holder can be uniquely identified from the collected evidence. So a governance framework may require the blinding of holder information, as well as instance-identifiable information about the evidence itself. 4. Require remote/proxy verification. Verification has only value to a holder, if it results in a positive decision by the verifier. Hence a holder should preferably only surrender personal data if such warrants a positive decision. It would save travel, if the requested decision is access to a physical facility. It would in any case prevent unnecessary disclosure of personal data. Some verifiers may consider their decision criteria confidential. Hence, different governance frameworks may choose different balances between holder privacy and verifier confidentiality. 5. Require complying holder agent. Some rogue holder agents may surrender personal data against the policies of the governance framework associated with that data. Issuers of such data may require verification of compliance of the holder\u2019s agent before issuing. 6. Require what-you-know authentication. Holders may be forced to surrender biometric authentication by rogue verifiers as well as some state jurisdictions. This is the reason that many bank apps require \u201cwhat-you-know\u201d authentication, next to biometric \u201cwhat-you-are\u201d or device-based \u201cwhat-you-have\u201d authentication. This may be needed even for when then the user views its own personal data in the app without electronic presentation, as some 800-pound gorillas require watching over the shoulder.</p>"},{"location":"concepts/0289-toip-stack/#interoperability-with-other-governance-frameworks","title":"Interoperability with Other Governance Frameworks","text":"<p>The ToIP governance stack is designed to be compatible with\u2014and an implementation vehicle for\u2014national governance frameworks such as the Pan-Canadian Trust Framework (PCTF) [18] being developed through a public/private sector collaboration with the Digital Identity and Authentication Council of Canada (DIACC). It should also interoperate with regional and local governance frameworks of all kinds. For example, the Province of British Columbia (BC) has implemented a ToIP-compatible verifiable credential registry service called OrgBook BC. OrgBook is a holder service for legally registered entities in BC that was built using Indy Catalyst and Hyperledger Aries Cloud Agent - Python. Other provinces such as Ontario and Alberta as well as the Canadian federal government have begun to experiment with these services for business credentials, giving rise to new kind of network where trust is at the edge. For more information see the VON (Verifiable Organization Network) [19].</p>"},{"location":"concepts/0289-toip-stack/#building-a-world-of-interoperable-digital-trust-ecosystems","title":"Building a World of Interoperable Digital Trust Ecosystems","text":"<p>The Internet is a network of networks, where the interconnections between each network are facilitated through the TCP/IP stack. The ToIP-enable Internet is a digital trust ecosystem of digital trust ecosystems, where the interconnections between each digital trust ecosystem are facilitated through the ToIP stack. The boundaries of each digital trust ecosystem are determined by the governance framework(s) under which its members are operating.</p> <p>This allows the ToIP-enabled Internet to reflect the same diversity and richness the Internet has today, but with a new ability to form and maintain trust relationships of any kind\u2014personal, business, social, academic, political\u2014at any distance. These trust relationships can cross trust boundaries as easily as IP packets can cross network boundaries today.</p>"},{"location":"concepts/0289-toip-stack/#conclusion-a-trust-layer-for-the-internet","title":"Conclusion: A Trust Layer for the Internet","text":"<p>The purpose of the ToIP stack is to define a strong, decentralized, privacy-respecting trust layer for the Internet. It leverages blockchain technology and other new developments in cryptography, decentralized systems, cloud computing, mobile computing, and digital governance to solve longstanding problems in establishing and maintaining digital trust.</p> <p>This RFC will be updated to track the evolution of the ToIP stack as it is further developed, both through Hyperledger Aries and via other projects at the Linux Foundation. We welcome comments and contributions.</p>"},{"location":"concepts/0289-toip-stack/#references","title":"References","text":"<ol> <li>Petros Kavassalis, Richard Jay Solomon, Pierre-Jean Benghozi, The Internet: a Paradigmatic Rupture in Cumulative Telecom Evolution, Industrial and Corporate Change, 1996; accessed September 5 2019.</li> <li>FreeBSD, What, a real UNIX\u00ae?, accessed September 5, 2019.</li> <li>Kim Cameron, The Laws of Identity, May 2005; accessed November 2, 2019.</li> <li>Drummond Reed, Manu Sporny, Markus Sabadello, David Longley, Christopher Allen, Ryan Grant, Decentralized Identifiers (DIDs) v1.0, December 2019; accessed January 24, 2020.</li> <li>W3C Credentials Community Group, DID Primer, January 2019; accessed July 6, 2019.</li> <li>W3C DID Working Group, Home Page, September 2019; accessed November 2, 2019.</li> <li>Uniform Resource Names (URNs), RFC 8141, April 2017; accessed November 2, 2019.</li> <li>Greg Slepak, Christopher Allen, et al, Decentralized Public Key Infrastructure, December 2015, accessed January 24, 2020.</li> <li>W3C Credentials Community Group, DID Method Registry, June 2019; accessed July 6, 2019.</li> <li>Daniel Hardman, DID Communication, January 2019; accessed July 6, 2019.</li> <li>Daniel Hardman et al, Peer DID Method 1.0 Specification, July 2019; accessed July 6, 2019.</li> <li>Drummond Reed, Jason Law, Daniel Hardman, Mike Lodder, DKMS Design and Architecture V4, March 2019; accessed November 2, 2019.</li> <li>Samuel M. Smith, Key Event Receipt Infrastructure (KERI) , July 2019, accessed February 4, 2020.</li> <li>Sovrin Governance Framework Working Group, On Guardianship in Self-Sovereign Identity, December 2019, accessed April 10, 2020.</li> <li>Manu Sporny, Grant Noble, Dave Longley, Daniel C. Burnett, Brent Zundel, Verifiable Credentials Data Model 1.0, September 2019; accessed November 2, 2019.</li> <li>Manu Sporny, Verifiable Credentials Primer, February 2019; accessed July 6, 2019.</li> <li>Sovrin Foundation, Sovrin Governance Framework V2, March 2019; accessed December 21, 2019.</li> <li>DIACC, Pan-Canadian Trust Framework, May 2019; accessed July 6, 2019.</li> <li>Governments of British Columbia, Ontario, and Canada, Verifiable Organizations Network (VON),June 2019; accessed July 6, 2019.</li> <li>Oskar van Deventer et al, TNO, Netherlands, Self-Sovereign Identity - The Good, The Bad And The Ugly, May 2019.</li> <li>Oskar van Deventer (TNO), Alexander Blom (Bloqzone), Line Kofoed (Bloqzone) Verify the Verifier - anti-coersion by design, October 2020.</li> </ol>"},{"location":"concepts/0289-toip-stack/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0302-aries-interop-profile/","title":"0302: Aries Interop Profile","text":"<ul> <li>Authors: Stephen Curran, John Jordan Province of British Columbia</li> <li>Status: ADOPTED</li> <li>Since: 2021-01-06</li> <li>Status Note: This RFC defines an Aries Interop Profile process and Aries Interop Profile versions</li> <li>Supersedes:</li> <li>Start Date: 2019-11-06</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0302-aries-interop-profile/#summary","title":"Summary","text":"<p>This RFC defines the process for the community of Aries agent builders to:</p> <ul> <li>enumerate a versioned set of Aries concept and feature RFCs which are collectively referred to as 'Aries Interop Profile Vx.y'</li> <li>track Aries Interop Profile versions.</li> </ul> <p>\"Agent builders\" are organizations or teams that are developing open source code upon which agents can be built (e.g. aries-framework-dotnet), or deployable agents (e.g. Aries Mobile Agent Xamarin), or commercially available agents.</p> <p>An Aries Interop Profile (AIP) version provides a clearly defined set of versions of RFCs for Aries agent builders to target their agent implementation when they wish it to be interoperable with other agents supporting the same Aries Interop Profile version. The Aries Interop Profile versioning process is intended to provide clarity and predictability for Aries agent builders and others in the broader Aries community. The process is not concerned with proposing new, or evolving existing, RFCs, nor with the development of Aries code bases.</p> <p>At all times, the Reference section of this RFC defines one or more current Aries Interop Profile versions -- a number and set of links to specific commits of concept and ../../features RFCs, along with a list of all previous Aries Interop Profile versions. Several current Aries Interop Profile versions can coexist during periods when multiple major Aries Interop Profile versions are in active use (e.g. 1.x and 2.x). Each entry in the previous versions list includes a link to the commit of this RFC associated with that Aries Interop Profile version. The Reference section MAY include one <code>&lt;major&gt;.next</code> version for each existing current major Aries Interop Profile versions. Such \"next\" versions are proposals for what is to be included in the next minor AIP version.</p> <p>Once a suitably populated Aries test suite is available, each Aries Interop Profile version will include a link to the relevant subset of test cases. The test cases will include only those targeting the specific versions of the ../../concepts and ../../features RFCs in that version of Aries Interop Profile. A process for maintaining the link between the Aries Interop Profile version and the test cases will be defined in this RFC once the Aries test suite is further evolved.</p> <p>This RFC includes a section maintained by Aries agent builders listing their Aries agents or agent deployments (whether open or closed source). This list SHOULD include the following information for each listed agent:</p> <ul> <li>The name, version and link to the agent (code or deployment)</li> <li>The type of the agent (see below)</li> <li>The name and link to the builder(s)</li> <li>The version of Aries Interop Profile supported</li> <li>A link to the test suite results or a summary of caveats/details about the agent's AIP support</li> <li>Notes about the agent</li> </ul> <p>An Aries agent builder SHOULD include an entry in the table per major version supported. Until there is a sufficiently rich test suite that produces linkable results, builders SHOULD link to and maintain a page that summarizes any exceptions and extensions to the agent's AIP support.</p> <p>The type of the agent MUST be selected from an enumerated list above the table of builder agents.</p>"},{"location":"concepts/0302-aries-interop-profile/#motivation","title":"Motivation","text":"<p>The establishment of Aries Interop Profile versions defined by the Aries agent builder community allows the independent creation of interoperable Aries agents by different Aries agent builders. Whether building open or closed source implementations, an agent that aligns with the set of RFC versions listed as part of an Aries Interop Profile version should be interoperable with any other agent built to align with that same version.</p>"},{"location":"concepts/0302-aries-interop-profile/#tutorial","title":"Tutorial","text":"<p>This RFC MUST contain the current Aries Interop Profile versions as defined by a version number and a set of links to concept and feature RFCs which have been agreed to by a community of Aries agent builders. \"Agreement\" is defined as when the community agrees to merge a Pull Request (PR) to this RFC that affects an Aries Interop Profile version number and/or any of the links to concept and feature RFCs. PRs that do not impact the Aries Interop Profile version number or links can (in general) be merged with less community scrutiny.</p> <p>Each link to a concept or feature RFCs MUST be to a specific commit of that RFC. RFCs in the list MAY be flagged as deprecated. Linked RFCs that reference external specs or standards MUST refer to as specific a version of the external resource as possible.</p> <p>Aries Interop Profile versions SHOULD have a link (or links) to a version (specific commit) of a test suite (or test cases) which SHOULD be used to verify compliance with the corresponding version of Aries Interop Profile. Aries agent builders MAY self-report their test results as part of their entries in the list of agents.</p> <p>Aries Interop Profile versions MUST evolve at a pace determined by the Aries agent builder community. This pace SHOULD be at a regular time interval so as to facilitate the independent but interoperable release of Aries Agents. Aries agent builders are encouraged to propose either updates to the list of RFCs supported by Aries Interop Profile through GitHub Issues or via a Pull Request. Such updates MAY trigger a change in the Aries Interop Profile version number.</p> <p>All previous versions of Aries Interop Profile MUST be listed in the Previous Versions section of the RFP and must include a link to the latest commit of this RFC at the time that version was active.</p> <p>A script in the <code>/code</code> folder of this repo can be run to list RFCs within an AIP version that have changed since the AIP version was set. For script usage information run the following from the root of the repo:</p> <p><code>python code/aipUpdates.py --help</code></p>"},{"location":"concepts/0302-aries-interop-profile/#sub-targets","title":"Sub-targets","text":"<p>AIP 2.0 is organized into a set of base requirements, and additional optional targets. These requirements are listed below. When indicating levels of support for AIP 2.0, subtargets are indicated in this format: <code>AIP 2.0/INDYCREDS/MEDIATE</code> with the subtargets listed in any order.</p> <p>Any RFCs within a single AIP Version and it's subtargets MUST refer to the exact same version of the RFC.</p>"},{"location":"concepts/0302-aries-interop-profile/#discover-features-usage","title":"Discover Features Usage","text":"<p>AIP Targets can be disclosed in the discover_../../features protocol, using the <code>feature-type</code> of <code>aip</code>. The feature's <code>id</code> is <code>AIP&lt;major&gt;.&lt;minor&gt;</code> for base compatibility, and <code>AIP&lt;major&gt;.&lt;minor&gt;/&lt;subtarget&gt;</code> for subtargets, each subtarget being included individually.</p> <p>Example:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/2.0/disclosures\",\n  \"disclosures\": [\n    {\n      \"feature-type\": \"aip\",\n      \"id\": \"AIP2.0\",\n    },\n    {\n      \"feature-type\": \"aip\",\n      \"id\": \"AIP2.0/INDYCRED\"\n    }\n  ]\n}\n</code></pre>"},{"location":"concepts/0302-aries-interop-profile/#reference","title":"Reference","text":"<p>The Aries Interop Profile version number and links to other RFCs in this section SHOULD only be updated with the agreement of the Aries agent builder community. There MAY be multiple active major Aries Interop Profile versions. A list of previous versions of Aries Interop Profile are listed after the current version(s).</p>"},{"location":"concepts/0302-aries-interop-profile/#aries-interop-profile-version-10","title":"Aries Interop Profile Version: 1.0","text":"<p>The initial version of Aries Interop Profile, based on the existing implementations such as aries-cloudagent-python, aries-framework-dotnet, Open Source Mobile Agent and Streetcred.id's IOS agent. Agents adhering to AIP 1.0 should be able to establish connections, exchange credentials and complete a connection-less proof-request/proof transaction.</p> RFC Type RFC/Link to RFC Version Concept 0003-protocols Concept 0004-agents Concept 0005-didcomm Concept 0008-message-id-and-threading Concept 0011-decorators Concept 0017-attachments Concept 0020-message-types Concept 0046-mediators-and-relays Concept 0047-json-LD-compatibility Concept 0050-wallets Concept 0094-cross-domain messaging Feature 0015-acks Feature 0019-encryption-envelope Feature 0160-connection-protocol Feature 0025-didcomm-transports Feature 0035-report-problem Feature 0036-issue-credential Feature 0037-present-proof Feature 0056-service-decorator"},{"location":"concepts/0302-aries-interop-profile/#changelog-aip-10","title":"Changelog - AIP 1.0","text":"<p>The original commit used in the definition of AIP 1.0 was: 64e5e55</p> <p>The following clarifications have been made to RFCs that make up AIP 1.0:</p> <ul> <li>RFC 0160 Connection: <code>signers</code> was updated to <code>signer</code> in the Signature decorator example, following the RFC.</li> </ul>"},{"location":"concepts/0302-aries-interop-profile/#aip-v10-test-suite","title":"AIP v1.0 Test Suite","text":"<p>To Do: Link(s) to version(s) of the test suite/test cases applicable to this Aries Interop Profile version.</p>"},{"location":"concepts/0302-aries-interop-profile/#aries-interop-profile-version-20","title":"Aries Interop Profile Version: 2.0","text":"<p>The following are the goals used in selecting RFC versions for inclusion in AIP 2.0, and the RFCs added as a result of each goal:</p> <ul> <li> <p>From AIP 1.0: Aries Agents must be able to establish connections, exchange credentials and complete a connection-less proof-request/proof transaction.</p> </li> <li> <p>Aries agents must be able to reuse connections.</p> </li> <li> <p>RFCs 0434, 0023, 0519, 0360</p> </li> <li> <p>Enable access to actionable information in Mobile Agents to enable improvements in the user experience (vs. AIP 1.0-based mobile agents).</p> </li> <li> <p>RFCs 0183, 0095, 0557</p> </li> <li> <p>Improve support for credential revocation use cases, independent of the revocation mechanism being used.</p> </li> <li> <p>RFCs 0183</p> </li> <li> <p>Improve the low-level messaging cryptography and enable a transition to DIDComm 2.0 to improve the security of the communication paths between agents.</p> </li> <li> <p>RFCs 0044, 0360, 0334</p> </li> <li> <p>Use protocols and standards that support multiple ledger types and verifiable credential formats.</p> </li> <li> <p>RFCs 0434, 0023, 0453, 0454</p> </li> <li> <p>Where appropriate, enable standard mediator coordination capabilities for mobile agents and multi-tenant agencies.</p> </li> <li>RFC 0211</li> </ul>"},{"location":"concepts/0302-aries-interop-profile/#aip-20-changelog-by-pull-requests","title":"AIP 2.0 Changelog by Pull Requests","text":"<p>Since approval of the AIP 2.0 profile, the following RFCs have been clarified by updating the commit in the link to the RFC:</p> <ul> <li>2022-03: RFC 0004 Agents, RFC 0005 DIDComm, RFC 0046 Mediators and Relays, RFC 0211 Route Coordination</li> <li>Note: In this update, a number of RFCs were changed solely for the purpose     of changing a link in the RFC to reference the \"main\" branch.</li> <li> <p>Pull request: #724</p> </li> <li> <p>2022-06: RFC 0023 DID Exchange, RFC 0025 DIDComm Transports, RFC 0434 Out of Band</p> </li> <li> <p>Pull request: #739</p> </li> <li> <p>2024-02: Clarifications and removals of RFCs that have been determined to be impractical for AIP 2.0.</p> </li> <li>See the AIP 2.0 RFC Removed section for details about the removed RFCs</li> <li>See the updated implementer's note on encryption envelopes in AIP 2.0 that highlights the removal of RFC 0587-encryption-envelope-v2.</li> <li> <p>Pull request: #814</p> </li> <li> <p>2024-03: Clarifications and removals of RFCs that have been determined to be impractical for AIP 2.0.</p> </li> <li>See the AIP 2.0 RFC Removed section for details about the removed RFCs</li> <li>Pull request: #820</li> </ul>"},{"location":"concepts/0302-aries-interop-profile/#aip-20-changelog-by-clarifications","title":"AIP 2.0 Changelog by Clarifications","text":"<p>The original commit used in the definition of AIP 2.0 was: <code>b3a3942ef052039e73cd23d847f42947f8287da2</code></p> <p>The following clarifications have been made to RFCs that make up AIP 2.0. This list excludes commits changed solely because of status changes:</p> <ul> <li>RFC 0003 Protocols: A correction to the tic-tac-toe example protocol was made; clarifications and additional guidance about the handling of minor differences in protocols by implementations.</li> <li>RFC 0017 Attachments: A clarification was made around the use of base64url encoding/decoding.</li> <li>RFC 0441 Present Proof Best Practices: A convention for representing dates to enable simple \"older than\" predicates was added.</li> <li>RFC 0592 Indy Attachment Format: The encoding algorithm used for credential attributes was added from RFC 0036.</li> <li>RFC 0008 Message ID and Threading: Clarification on having an empty <code>~thread</code> on a first message.</li> <li>RFC 0519 Goal Codes: Added some commonly used Goal Codes.</li> <li>RFC 0015 Acks: Clarification that an \"Ack\" value should not be \"Fail\" and Acks relationship with RFC 0035 Problem Report.</li> <li>RFC 0023 DID Exchange: Status update to Adopted, added to example the use of a DID Rotate attachment to include a signature on the the DID.</li> <li>RFC 0035 Report Problem: Clarification that a <code>description.code</code> is required, clarification on conventions for warnings.</li> <li>RFC 0044 DIDComm File and MIME Types: Clarifications on fallbacks for the mime types and why, and on using JWEs.</li> <li>RFC 0211 Route Coordination: Clarification to add a missing comma to an example.</li> <li>RFC 0434 Out of Band: Clarification that did:peer:2 can be used for reuse.</li> <li>RFC 0453 Issue Credential: Clarification about the protocol version (2.0) and that payments are not part of AIP 2.0.</li> <li>RFC 0454 Present Proof: Clarification about the protocol version (2.0) and that payments are not part of AIP 2.0.</li> <li>RFC 0592 Indy Attachments: Clarification on handling \"unrevealed attributes\" and on encoding integer strings as numbers (e.g. encoding both <code>\"1\"</code> vs. <code>1</code> as integers)</li> <li>RFC 0510 DIF Presentation Exchange Attachment: Correction of reference into the DIF spec that there is an \"s\" on \"definitions\" in <code>dif/presentation-exchange/definitions@v1.0</code></li> </ul>"},{"location":"concepts/0302-aries-interop-profile/#base-requirements","title":"Base Requirements","text":"RFC Type RFC/Link to RFC Version Note Concept 0003-protocols AIP V1.0, Reformatted Concept 0004-agents AIP V1.0, Unchanged Concept 0005-didcomm AIP V1.0, Minimally Updated Concept 0008-message-id-and-threading AIP V1.0, Updated Concept 0011-decorators AIP V1.0, Updated Concept 0017-attachments AIP V1.0, Updated Concept 0020-message-types AIP V1.0, UpdatedMandates message prefix <code>https://didcomm.org</code> for Aries Protocol messages. Concept 0046-mediators-and-relays AIP V1.0, Minimally Updated Concept 0047-json-LD-compatibility AIP V1.0, Minimally Updated Concept 0050-wallets AIP V1.0, Unchanged Concept 0094-cross-domain messaging AIP V1.0, Updated Concept 0519-goal-codes Feature 0015-acks AIP V1.0, Updated Feature 0019-encryption-envelope AIP V1.0, UpdatedSee envelope note below Feature 0023-did-exchange Feature 0025-didcomm-transports AIP V1.0, Minimally Updated Feature 0035-report-problem AIP V1.0, Updated Feature 0044-didcomm-file-and-mime-types Feature 0048-trust-ping Feature 0183-revocation-notification Feature 0360-use-did-key Feature 0434-outofband Feature 0453-issue-credential-v2 Update to V2 Protocol Feature 0454-present-proof-v2 Update to V2 Protocol Feature 0557-discover-features-v2"},{"location":"concepts/0302-aries-interop-profile/#mediate-mediator-coordination","title":"MEDIATE: Mediator Coordination","text":"RFC Type RFC/Link to RFC Version Note Feature 0211-route-coordination Feature 0092-transport-return-route"},{"location":"concepts/0302-aries-interop-profile/#indycred-indy-based-credentials","title":"INDYCRED: Indy Based Credentials","text":"RFC Type RFC/Link to RFC Version Note Feature 0592-indy-attachments  Evolved from AIP V1.0 Concept 0441-present-proof-best-practices"},{"location":"concepts/0302-aries-interop-profile/#ldcred-json-ld-based-credentials","title":"LDCRED: JSON-LD Based Credentials","text":"RFC Type RFC/Link to RFC Version Note Feature 0593-json-ld-cred-attach Feature 0510-dif-pres-exch-attach"},{"location":"concepts/0302-aries-interop-profile/#bbscred-bbs-based-credentials","title":"BBSCRED: BBS+ Based Credentials","text":"RFC Type RFC/Link to RFC Version Note Feature 0593-json-ld-cred-attach Feature 0646-bbs-credentials Feature 0510-dif-pres-exch-attach"},{"location":"concepts/0302-aries-interop-profile/#chat-chat-related-features","title":"CHAT: Chat related ../../features","text":"RFC Type RFC/Link to RFC Version Note Feature 0095-basic-message"},{"location":"concepts/0302-aries-interop-profile/#aip-20-rfcs-removed","title":"AIP 2.0 RFCs Removed","text":"<p>[!WARNING] After discussion amongst the Aries implementers, the following RFCs initially in AIP 2.0 have been removed as both never implemented (as far as we know) and/or impractical to implement. Since the RFCs have never been implemented, their removal does not have a practical impact on implementations. Commentary below the table listing the removed RFCs provides the reasoning for the removal of each RFC.</p> RFC Type RFC/Link to RFC Version Note Feature 0317-please-ack Removed from AIP 2.0 Feature 0587-encryption-envelope-v2 Removed from AIP 2.0 Feature 0627-static-peer-dids The use of static peer DIDs in Aries has evolved and all AIP 2.0 implementations should be using DID Peer types 4 (preferred), 1 or 2. <ul> <li>0317-please-ack: While the idea of a generic ACK request to be sent either immediately <code>on receipt</code>, or <code>after processing</code> seemed like a good idea, attempts to implement the feature proved ill-advised.</li> <li>The feature was never implemented, and there have been (as far as we know) no requests for its implementation. A good idea in theory, but not needed in practice.</li> <li>The <code>on receipt</code> use of <code>please-ack</code> might be feasible as a generic feature, but does not appear to be useful except in protocol specific ways, such as in implementing a texting protocol to get \"read receipts\". However, even in that case, it is not useful for the existing 0095-basic-messaging protocol, because the protocol will be complete (and likely deleted) before the <code>ack</code> can be sent back to the sender. When an <code>on receipt</code> ACK is needed, it is much preferred to add it in a protocol specific way vs. in a generic way.</li> <li>The <code>after processing</code> use of <code>please-ack</code> turned out to be impossible because its introduction changes every protocol state machine in protocol specific ways. We have determined that it is not possible to \"generically\" (without changing each protocol) to add such a feature and so we have decided that if there is a use case of <code>please-ack</code>-style functionality in a given protocol, it should be added/included in that protocol. Further, no one has requested that the feature be used in any implementation.</li> <li>See the RFC 0317 Please Ack for more details on it's change of status to <code>RETIRED</code> and links to unmerged PRs that attempted to design and implement the functionality.</li> <li>0587-encryption-envelope-v2</li> <li>While this RFC will be crucial when the transition to DIDComm v2 is started, it is not of use until then, and hence not applicable to AIP 2.0.</li> <li>0627-static-peer-dids: The inclusion of static peer DIDs was a transitory approach as the DID Peer specification evolved. The use of static peer DIDs is not in use in Aries, the DID Peer specification has stabilized, and the existing implementations are settled on the use of <code>did:peer</code> <code>4</code> (preferred), <code>2</code> and in some cases <code>1</code>. The removal of static peer DIDs from AIP 2.0 is to indicate where the community is currently and to lead newcomers to the community to follow the existing practices in the use of DID Peer.</li> </ul>"},{"location":"concepts/0302-aries-interop-profile/#aip-v20-test-suite","title":"AIP v2.0 Test Suite","text":"<p>The Aries Agent Test Harness has a set of tests tagged to exercise AIP 1.0 and AIP 2.0, including the extended targets.</p>"},{"location":"concepts/0302-aries-interop-profile/#implementers-note-about-didcomm-envelopes-and-the-accept-element","title":"Implementers Note about DIDComm Envelopes and the <code>ACCEPT</code> element","text":"<p>[!WARNING] The following paragraph is struck out as no longer relevant, since the 0587-encryption-envelope-v2 RFC has been removed from AIP 2.0. The upcoming (to be defined) AIP 3.0 will include the transition from DIDComm v1 to the next DIDComm generation, and at that time, the 0587-encryption-envelope-v2 will again be relevant.</p> <p>AIP 2.0 contains two RFCs that reference envelopes 0019-encryption-envelope and 0587-encryption-envelope-v2 (links above). The important feature that Aries implementers should understand to differentiate which envelope format can or is being used by an agent is the <code>accept</code> element of the DIDComm service endpoint and the out-of-band <code>invitation</code> message. If the <code>accept</code> element is not present, the agent can only use the RFC 0019-encryption-envelope present. If it is present, the values indicate the envelope format(s) the agent does support. See the RFCs for additional details.</p>"},{"location":"concepts/0302-aries-interop-profile/#previous-versions","title":"Previous Versions","text":"<ul> <li>None</li> </ul> <p>Will be the version number as a link to the latest commit of this RFC while the version was current.</p>"},{"location":"concepts/0302-aries-interop-profile/#aries-agent-builders-and-agents","title":"Aries Agent Builders and Agents","text":"<p>A list of agents that claim compatibility with versions of Aries Interop Profile. A entry can be included per agent and per major Aries Interop Profile version.</p> <p>The agent type MUST be one of the following:</p> <ul> <li>Mobile - A mobile agent; does not require mediator routing capabilities, credential issuing capabilities.</li> <li>I/V - A cloud-based Issuer/Verifier agent; does not require credential holding support.</li> <li>Mediator - A mediator/relay agent; does not require verifiable credential exchange protocol capabilities.</li> <li>Holder - A cloud-based holder/prover agent; does not require credential issuing capabilities.</li> <li>Framework - A general purpose agent code base for an agent that is the basis for deployments of agents; typically supports all AIP protocols.</li> </ul> Name / Version / Link Agent Type Builder / Link Aries Interop Profile Version Test Results Notes"},{"location":"concepts/0302-aries-interop-profile/#drawbacks","title":"Drawbacks","text":"<p>It may be difficult to agree on the exact list of RFCs to support in a given version.</p>"},{"location":"concepts/0302-aries-interop-profile/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Continuing with the current informal discussions of what agents/frameworks should support and when is an ineffective way of enabling independent building of interoperable agents.</p>"},{"location":"concepts/0302-aries-interop-profile/#prior-art","title":"Prior art","text":"<p>This is a typical approach to creating an early protocol certification program.</p>"},{"location":"concepts/0302-aries-interop-profile/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>The community agreement process for setting Aries Interop Profile versions needs to be tried and adjusted as appropriate.</li> <li>The tracking of who is part of the Aries agent builders community needs to be defined so we know who should have the strongest say in the setting of Aries Interop Profile versions.</li> <li>Should the Implementations table in all RFCs (below) be used for the agent builders table (above)?  Or, should we eliminate the per RFC \u201cimplementations table (below and in all RFCs) and just use this RFC to track implementations?</li> </ul>"},{"location":"concepts/0302-aries-interop-profile/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0345-community-coordinated-update/","title":"0345: Community Coordinated Update","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: PROPOSED</li> <li>Since: 2019-12-26 (date you submit your PR)</li> <li>Status Note: Initial Draft</li> <li>Start Date: 2019-12-06</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0345-community-coordinated-update/#summary","title":"Summary","text":"<p>This RFC describes the recommended process for coordinating a community update. This is not a mandate; this process should be adapted as useful to the circumstances of the update being performed.</p>"},{"location":"concepts/0345-community-coordinated-update/#motivation","title":"Motivation","text":"<p>Occasionally, an update will be needed that requires a coordinated change to be made across the community. These should be rare, but are inevitable. The steps in this process help avoid a coordinated software deployment, where multiple teams must fit a tight timeline of software deployment to avoid compatibility problems. Tightly coordinated software deployments are difficult and problematic, and should be avoided whenever possible.</p>"},{"location":"concepts/0345-community-coordinated-update/#tutorial","title":"Tutorial","text":"<p>This process descries how to move from OLD to NEW. OLD and NEW represent the required change, where OLD represents the item being replaced, and NEW represents the item OLD will be replaced with. Often, these will be strings. </p> <p>In brief, we first accept OLD and NEW while still defaulting to OLD, Then we default to NEW (while still accepting OLD), and then we remove support for OLD. These steps are coordinated with the community with a gracious timeline to allow for development cycles and deployment ease.</p>"},{"location":"concepts/0345-community-coordinated-update/#prerequisite-community-agreement-on-change","title":"Prerequisite: Community agreement on change.","text":"<p>Before these steps are taken, the community MUST agree on the change to be made. </p>"},{"location":"concepts/0345-community-coordinated-update/#step-1-accept-old-and-new","title":"Step 1: Accept OLD and NEW","text":"<p>The first step of the process is to accept both OLD and NEW from other agents. Typically, this is done by detecting and converting one string to the other in as few places in the software as possible. This allows the software to use a common value internally, and constrains the change logic to where the values are received.</p> <p>OLD should still be sent on outbound communication to other agents.</p> <p>During step 1, it is acceptable (but optional) to begin sending NEW when receiving NEW from the other agent. OLD should still be sent by default when the other Agent's support is unknown.</p> <p>This step is formalized by writing and RFC detailing which changes are expected in this update. This step is scheduled in the community by including the update RFC in a new version of the Interop Profile and setting a community target. The schedule should allow a generous time for development, generally between 1 and 3 months.</p> <p>Step 1 Coordination: This is the most critical coordination step. The community should have completed step 1 before moving to step 2.</p>"},{"location":"concepts/0345-community-coordinated-update/#step-2-default-to-new","title":"Step 2: Default to NEW","text":"<p>The second step changes the outbound value in use from OLD to NEW. Communication will not break with agents who have completed Step 1. </p> <p>OLD must still be accepted during step 2. OLD becomes deprecated.</p> <p>During step 2, it is acceptable (but optional) to keep sending OLD when receiving OLD from the other agent. NEW should still be sent by default when the other Agent's support is unknown.</p> <p>This step is formalized by writing an RFC detailing which changes are expected in this update. This step is scheduled by including the update RFC in a new version of the Interop Profile and setting a community target date. The schedule should allow a generous time for development, generally between 1 and 3 months.</p> <p>Step 2 Coordination: The community should complete step 2 before moving to step 3 to assure that OLD is no longer being sent prior to removing support.</p>"},{"location":"concepts/0345-community-coordinated-update/#step-3-remove-support-for-old","title":"Step 3: Remove support for OLD.","text":"<p>Software will be updated to remove support for OLD. Continued use is expected to result in a failure or error as appropriate</p> <p>This step is formalized by writing an RFC detailing which changes are expected in this update. Upon acceptance of the RFC, OLD is considered invalid. At this point, nobody should be sending the OLD.</p> <p>Step 3 Coordination: The deadline for step 3 is less important than the previous steps, and may be scheduled at the convenience of each development team.</p>"},{"location":"concepts/0345-community-coordinated-update/#reference","title":"Reference","text":"<p>This process should only be used for changes that are not detectable via the Discover Features protocol, either because the Discover Features Protocol cannot yet be run or the Discover Features Protocol does not reveal the change.</p>"},{"location":"concepts/0345-community-coordinated-update/#changes-not-applicable-to-this-process","title":"Changes NOT applicable to this process","text":"<p>Any changes that can be handled by increasing the version of a protocol should do so. The new version can be scheduled via Interop Profile directly without this process.</p> <p>Example proper applications of this process include switching the base common Message Type URI, and DID Doc Service Types.</p>"},{"location":"concepts/0345-community-coordinated-update/#pace","title":"Pace","text":"<p>The pace for Steps 1 and 2 should be appropriate for the change in question, but should allow generous time to allow for developer scheduling, testing, and production deployment schedules. App store approval process sometimes take a bit of time. A generous time allowance eases the burden of implementing the change.</p>"},{"location":"concepts/0345-community-coordinated-update/#drawbacks","title":"Drawbacks","text":"<p>This approach invites the drawbacks of sanity, unpanicked deployments, and steady forward community progress.</p>"},{"location":"concepts/0345-community-coordinated-update/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>The only other general approach is a tightly coordinated rollout, which should be avoided.</li> </ul>"},{"location":"concepts/0345-community-coordinated-update/#prior-art","title":"Prior art","text":"<p>This process was discussed in Issue 318 and in person at the 2019 December Aries Connectathon.</p>"},{"location":"concepts/0345-community-coordinated-update/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Should template RFCs be included for the steps outlined?</li> </ul>"},{"location":"concepts/0345-community-coordinated-update/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/","title":"0346: DIDComm Between Two Mobile Agents Using Cloud Agent Mediator","text":"<ul> <li>Author: Sukalpo Mitra</li> <li>Start Date: 2019-06-23</li> <li>Tags: concept</li> <li>Status: PROPOSED</li> <li>Status Date: 2019-06-23</li> <li>Status Note: ???</li> </ul>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#summary","title":"Summary","text":"<p>Explains how one mobile edge agent can send messages to another mobile edge agent through cloud agents. The sender edge agent also determines the route of the message. The recipient, on the other hand, can consume messages at its own pace and time.</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#motivation","title":"Motivation","text":"<p>The DIDCOMM between two mobile edge agents should be easy and intuitive for a beginner to visualize and to implement.</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#scenario","title":"Scenario","text":"<p>Alice sends a connection request message to Bob and Bob sends back an acceptance response. For simplicity's sake, we will only consider the cloud agents in play while sending and receiving a message for Alice.</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#cloud-agent-registration-process","title":"Cloud Agent Registration Process","text":"<p>A registration process is necessary for an edge agent to discover cloud agents that it can use to send a message through them. Cloud agents in the simplest form are routers hosted as a web application that solves the problem of availability by providing a persistent IP address. The Web server has a wallet of it's own storing its private key as a provisioning record, along with any information needed to forward messages to other agents. Alice wants to accept a connection invitation from Bob. But before doing so Alice needs to register herself with one or more cloud agents. The more cloud agents she registers with the more cloud agents she can use in transporting her message to Bob. To register herself with a cloud agent she visits the website of a cloud agent and simply scans a QR code.</p> <p>The cloud agent registration invite looks like below</p> <pre><code>{\u200b\n    \"@type\": \"https://didcomm.org/didexchange/1.0/cloudagentregistrationinvitation\",\u200b\n    \"@id\": \"12345678900987654321\",\u200b\n    \"label\": \"CloudAgentA\",\u200b\n    \"recipientKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"],\u200b\n    \"serviceEndpoint\": \"https://cloudagenta.com/endpoint\",\n    \"responseEndpoint\": \"https://cloudagenta.com/response\", \n    \"consumer\": \"b1004443feff4f3cba25c45ef35b492c\",\n    \"consumerEndpoint\" : \"https://cloudagenta.com/consume\"\u200b\n}\u200b\n</code></pre> <p>The registration data is base64url-encoded and is added to alink as part of the c_a_r query param. The recipient key is the public key of \"Cloud Agent A\". The service endpoint is where the edge agent should send the message to. Response endpoint is where a response that is being sent to Alice should be sent to. For example, if Bob wants to send a message to Alice, then Bob should send the message to the response endpoint. Consumer endpoint is where Alice's edge agent should consume the messages that are sent to her. The \"Consumer\" is an identifier to identify Alice's edge agent by the cloud agent \"A\". This identifier is different with each cloud agent and hence provides low correlation risk. Each time an invitation QR code is generated, a new consumer id is generated. No acknowledgment is required to be sent to the cloud agent or vice versa as the consumer-generated is never repeated.</p> <p>All the endpoint data and the public key of the cloud agents are then stored as non secret records in Alice's wallet with a tag \"cloud-agent\"</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#how-connection-request-from-alice-flows-to-bob","title":"How connection request from Alice flows to Bob","text":"<p>When Alice scans Bob's QR code invitation. It starts preparing the connection request message. It first queries the wallet record service for records tagged with \"cloud-agent\" and puts them in a list. The edge agent now randomly chooses one from the list (say Cloud Agent \"A\") and creates a new list without the cloud agent that is already chosen. Alice's edge agent creates the connection request message json and adds the service endpoint as the chosen cloud agent's response endpoint together with its consumer id. </p> <pre><code>\"serviceEndpoint\": \"https://cloudagenta.com/response/b1004443feff4f3cba25c45ef35b492c\"\n</code></pre> <p>It then packs this message by Bob's recipient key and then creates another json message structure like the below by ising the forward message type</p> <pre><code>{\u200b\n    \"@type\": \"https://didcomm.org/routing/1.0/forward\",\u200b\n    \"@id\": \"12345678900987654321\",\u200b\n    \"msg\": \"&lt;Encrypted message for Bob here&gt;\",\n    \"to\": \"&lt;Service endpoint of Bob&gt;\"\u200b\n}\u200b\n</code></pre> <p>It then packs it with the public key of cloud agent \"A\".</p> <p>Now it randomly chooses cloud agent from the new list and keeps on repeating the process of writing the message forwarding request.</p> <p>For example, say the next random cloud agent that it chooses is Cloud Agent \"C\". So now it creates another message forward json structure as below</p> <p><pre><code>{\u200b\n    \"@type\": \"https://didcomm.org/routing/1.0/forward\",\u200b\n    \"@id\": \"12345678900987654321\",\u200b\n    \"msg\": \"&lt;Encrypted message for Cloud Agent A&gt;\",\n    \"to\": \"&lt;Service endpoint of Cloud Agent A&gt;\"\u200b\n}\u200b\n</code></pre> And then packs with Cloud Agent \"C\"'s public key.</p> <p>This process happens till it has exhausted all the list of the cloud agent in the list and then sends the message to the service endpoint of the last cloud agent (say Cloud Agent \"B\") chosen.  For example, the message could have randomly been packed for this path, B-&gt;C-&gt;A where A is one of Bob's cloud agents that stores the message on the distributed log.</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#message-forwarding-process-by-cloud-agents","title":"Message Forwarding process by cloud agents","text":"<p>When the message is reached to cloud agent \"B\", the message is first unpacked by cliud agent \"B\"'s private key. It then finds out the message type is of \"forward\". It then processes the message by taking the value of the \"message\" attribute in the decrypted json and sending it to the forwardTo URI.</p> <p>Thus Cloud Agent \"B\" unpacks the message and forward the message to Cloud Agent \"C\" who then again unpacks and forwards it to Cloud Agent \"A\". Cloud Agent \"A\" ultimately unpacks and forwards it to Bob's edge agent (For simplicity sake we are not describing how the message reaches Bob through Bob's registered cloud agents)</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#bob-returns-a-response-back","title":"Bob returns a response back","text":"<p>Bob when recives the connection request message from Alice. It then creates a connection accept response and sends the response back to Alice at the service endpoint of Alice which is </p> <pre><code>\"serviceEndpoint\": \"https://cloudagenta.com/response/b1004443feff4f3cba25c45ef35b492c\"\n</code></pre> <p>For simplicity sake, we are not describing how the message ends up at the above endpoint from Bob after multiple routing through Bob's cloud agents. When the message actually ends up at the service endpoint mentioned by Alice, which is the response endpoint of cloud agent \"A\", the cloud agent simply stores it in a distributed log(NEEDS A LINK TO KAFKA INBOX RFC) using the consumer id as a key</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#alice-consumes-connection-accepted-response-from-bob","title":"Alice consumes connection accepted response from Bob","text":"<p>Alice's edge agent periodically checks the consumer endpoint of all the cloud agents it has registered with. For each cloud agent, Alice passes the unique consumer id that was used in registration so that cloud agent can return the correct messages. When it does the same for cloud agent \"A\", it simply consumes the message from the distributed log.</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#drawbacks-and-alternatives","title":"Drawbacks and Alternatives","text":"<p>In other suggested message formatting protocol Alice would provide a list of routing keys and the endpoint of the first hop in the chain of cloud agents. That gives allice confidence that bob is forced to use the path she has provided. The proposed routing in this RFC lacks that confidence. In contrast, routing with a list of routing keys requires a lot of overhead set up before establishing a connection. This proposed routing simplifies that overhead and provides more flexibility.</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#related-art","title":"Related art","text":"<p>[related-art] #prior-art Aries-rfc Aries RFC 0046: Mediators and Relays</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#prior-art","title":"Prior art","text":""},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#unresolved-questions","title":"Unresolved questions","text":"<p>Does separation of a \"service endpoint\" and \"Consumer endpoint\" provide a point of correlation that can be avoided by handling all messages through a single service endpoint?</p> <p>Can a cloud agent have their own army of servers that just basically looks into a registry of servers and randomly chooses an entry and exit node and a bunch of hops and just passes the message along. The exit node will then pass the message to the next cloud agent?  </p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0420-rich-schemas-common/","title":"0420: Rich Schema Objects Common","text":"<ul> <li>Author: Alexander Shcherbakov, Brent Zundel, Ken Ebert </li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No recent progress and no implementations have been created.</li> <li>Start Date: 2020-02-05</li> <li>Tags: concept, rich-schemas</li> </ul>"},{"location":"concepts/0420-rich-schemas-common/#summary","title":"Summary","text":"<p>A low-level description of the components of an anonymous credential ecosystem that supports rich schemas, W3C Verifiable Credentials and Presentations, and correspondingly rich presentation requests. </p> <p>Please see 0250: Rich Schema Objects  for high-level description.</p> <p>This RFC provides more low-level description of Rich Schema objects defining how they are identified and referenced. It also defines a general template and common part for all Rich Schema objects. </p>"},{"location":"concepts/0420-rich-schemas-common/#motivation","title":"Motivation","text":"<p>Please see 0250: Rich Schema Objects for use cases and high-level description of why Rich Schemas are needed.</p> <p>This RFC serves as a low-level design of common parts between all Rich Schema objects, and can help developers to  properly implement Rich Schema transactions on the Ledger and the corresponding client API. </p>"},{"location":"concepts/0420-rich-schemas-common/#tutorial-general-principles","title":"Tutorial: General Principles","text":"<p>By Rich Schema objects we mean all objects related to Rich Schema concept (Context, Rich Schema, Encoding, Mapping, Credential Definition, Presentation Definition)</p> <p>Let's discuss a number of items common for all Rich Schema objects</p>"},{"location":"concepts/0420-rich-schemas-common/#components-and-repositories","title":"Components and Repositories","text":"<p>The complete architecture for every Rich Schema object involves three separate components: - <code>aries-vdri</code>: This is the location of the <code>aries-verifiable-data-registy-interface</code>. Changes to this code will enable users of any data registry with an <code>aries-vdri</code>-compatible data manager to handle Rich Schema objects. - Specific Verifiable Data Registry implementation (for example, <code>indy-vdr</code>). It needs to comply with the interface described by the <code>aries-verifiable-data-registry-interface</code> and is built to plug in to the aries ecosystem. It contains the code to communicate with a specific data registry (ledger).</p> <ul> <li>Specific Data Registry (Ledger) implementation (for example, <code>indy-node</code>). Changes to this code will enable a Rich Schema object to be written to and retrieved from a data registry.</li> </ul>"},{"location":"concepts/0420-rich-schemas-common/#immutability-of-rich-schema-objects","title":"Immutability of Rich Schema Objects","text":"<p>The following Rich Schema objects are immutable: - Context - Rich Schema - Encoding - Mapping</p> <p>The following Rich Schema objects can be mutable: - Credential Definition - Presentation Definition</p> <p>Credential Definition and Presentation Definition should be immutable in most of the cases, but some applications may consider them as mutable objects.</p> <p>Credential Definition can be considered as a mutable object since the Issuer may rotate keys present there. However, rotation of Issuer's keys should be done carefully as it will invalidate all credentials issued for this key.</p> <p>Presentation Definition can be considered as a mutable object since restrictions to Issuers, Schemas and  Credential Definitions to be used in proof may evolve.  For example, Issuer's key for a given Credential Definition may be compromised, so  Presentation Definition can be updated to exclude this Credential Definition from the list of recommended ones. </p> <p>Please note, that some ledgers (Indy Ledger for example) have configurable auth rules which allow to have restrictions on mutability of particular objects, so that it can be up to applications and network administrators to decide if Credential Definition and Presentation Definition  are mutable. </p>"},{"location":"concepts/0420-rich-schemas-common/#identification-of-rich-schema-objects","title":"Identification of Rich Schema Objects","text":"<ul> <li>Every Rich Schema object is identified by a unique ID</li> <li>DID can be used as the ID.<ul> <li>The id-string of the DID is the base58 representation of the SHA2-256 hash of the canonical form  of the <code>content</code> field (see How Rich Schema objects are stored in the Data Registry.  The canonicalization scheme we recommend is the IETF draft   JSON Canonicalization Scheme (JCS). </li> </ul> </li> <li>There is additional metadata (aliases) that can identify Rich Schema objects on the ledger  in a more user-friendly way.</li> <li>rs_name </li> <li>rs_version</li> <li>rs_type </li> <li>Issuer's or Endorser's DID is not part of metadata, which means that Rich Schema objects of a given type must be unique among all Issuers and Endorsers.      </li> </ul> <p>The suggested Identification scheme allows to have a unique Identifier for any Rich Schema object.  DID's method name (for example <code>did:sov</code>) allows to identify Rich Schema objects with equal content within different  data registries (ledgers).   </p>"},{"location":"concepts/0420-rich-schemas-common/#referencing-rich-schema-objects","title":"Referencing Rich Schema Objects","text":"<ul> <li>Any Rich Schema object is referenced by other Rich Schema objects by its ID (DID).</li> <li>A Rich Schema object may reference a Rich Schema object from another ledger (as defined by DID's method name).</li> </ul>"},{"location":"concepts/0420-rich-schemas-common/#relationship","title":"Relationship","text":"<ul> <li>A credential definition refers to a single mapping object</li> <li>A mapping object refers to a single schema object</li> <li>If there is no existent single schema to be referenced by a mapping object, a new schema must be created potentially referencing or extending existing ones.</li> <li>Each attribute in a schema may be included in the mapping one or more times (it is possible to encode a single attribute  in multiple ways). A mapping may map only a subset of the attributes of a schema.</li> <li>A presentation definition refers to 1 or more schema, mapping or credential definition objects.</li> </ul> <p>A presentation definition may use only a subset of the attributes of a schema.  </p> <p></p>"},{"location":"concepts/0420-rich-schemas-common/#usage-of-json-ld","title":"Usage of JSON-LD","text":"<p>The following Rich Schema objects must be in JSON-LD format: - Schema - Mapping  - Presentation Definition</p> <p>Context object can also be in JSON-LD format.</p> <p>If a Rich Schema object is a JSON-LD object, the <code>content</code>'s <code>@id</code> field must be equal to the <code>id</code>.</p> <p>More details about JSON-LD usage may be found in the RFCs for specific rich schema objects.</p>"},{"location":"concepts/0420-rich-schemas-common/#how-rich-schema-objects-are-stored-in-the-data-registry","title":"How Rich Schema objects are stored in the Data Registry","text":"<p>Any write request for Rich Schema object has the same fields: <pre><code>'id': &lt;Rich Schema object's ID&gt;                # DID string \n'content': &lt;Rich Schema object as JSON&gt;        # JSON-serialized string\n'rs_name': &lt;rich schema object name&gt;           # string\n'rs_version': &lt;rich schema object version&gt;     # string\n'rs_type': &lt;rich schema object type&gt;           # string enum (currently one of `ctx`, `sch`, `map`, `enc`, `cdf`, `pdf`)\n'ver': &lt;format version&gt;                        # string                              \n</code></pre> - <code>id</code> is a unique ID (for example a DID with a id-string being base58 representation of the SHA2-256 hash of the <code>content</code> field) - The <code>content</code> field here contains a Rich Schema object in JSON-LD format (see 0250: Rich Schema Objects). It's passed and stored as-is. The <code>content</code> field must be serialized in the canonical form. The canonicalization scheme we recommend is the IETF draft   JSON Canonicalization Scheme (JCS). - <code>metadata</code> contains additional fields which can be used for human-readable identification   - <code>ver</code> defines the version of the format. It defines what fields and metadata are there, how <code>id</code> is generated, what hash function is used there, etc.  - Author's and Endorser's DIDs are also passed as a common metadata fields for any Request. </p> <p>If a Rich Schema object is a JSON-LD object, the <code>content</code>'s <code>@id</code> field must be equal to the <code>id</code>.</p>"},{"location":"concepts/0420-rich-schemas-common/#querying-rich-schema-objects-from-the-data-registry","title":"Querying Rich Schema objects from the Data Registry","text":"<ul> <li>Any Rich Schema object can be obtained from a Data Registry (Ledger) by its ID (DID).</li> <li>It should be possible to get Rich Schema objects by metadata as well: <code>(rs_name, rs_version, rs_type)</code>.</li> <li>Currently it's supposed that every Rich Schema object is queried individually, so it's up to clients and applications to get, query and cache all dependent Rich Schema objects.</li> <li>We may support resolving a Rich Schema object by a DID as a DID DOC object once aries-vdr interface for DID resolving is defined and DID DOC specification is finalized.</li> </ul> <p>The following information is returned from the Ledger in a reply for any get request of a Rich Schema object: <pre><code>'id': &lt;Rich Schema object's ID&gt;              # DID string \n'content': &lt;Rich Schema object as JSON&gt;      # JSON-serialized string\n'rs_name': &lt;rich schema object name&gt;         # string\n'rs_version': &lt;rich schema object version&gt;   # string\n'rs_type': &lt;rich schema object type&gt;         # string enum (currently one of `ctx`, `sch`, `map`, `enc`, `cdf`, `pdf`)\n'ver': &lt;format version&gt;                      # string\n'from': &lt;author DID&gt;,                        # DID string\n'endorser': &lt;endorser DID&gt;,                  # DID string\n</code></pre></p> <p>Common fields specific to a Ledger are also returned. </p>"},{"location":"concepts/0420-rich-schemas-common/#aries-data-registry-interface","title":"Aries Data Registry Interface","text":"<p>We can have a unified API to write and read Rich Schema objects from a Data Registry. Just two methods are sufficient to handle all Rich Schema types: - <code>write_rich_schema_object</code> - <code>read_rich_schema_object_request</code></p>"},{"location":"concepts/0420-rich-schemas-common/#write_rich_schema_object","title":"write_rich_schema_object","text":"<p><pre><code>Writes a Rich Schema object to the ledger.\n\n#Params\nsubmitter: information about submitter\ndata: {\n    id: Rich Schema object's unique ID for example a DID with an id-string being\n        base58 representation of the SHA2-256 hash of the `content` field),\n    content: Rich Schema object as a JSON or JSON-LD string,\n    rs_name: Rich Schema object name,\n    rs_version: Rich Schema object version,\n    rs_type: Rich schema object type's enum string (currently one of `ctx`, `sch`, `map`, `enc`, `cdf`, `pdf`),\n    ver: the version of the generic object template\n},\nregistry: identifier for the registry\n\n#Returns\nregistry_response: result as json,\nerror: {\n    code: aries common error code,\n    description:  aries common error description\n}\n</code></pre> The combination of <code>rs_type</code>, <code>rs_name</code>, and <code>rs_version</code> must be unique among all rich schema objects on the ledger.</p>"},{"location":"concepts/0420-rich-schemas-common/#read_rich_schema_object_by_id","title":"read_rich_schema_object_by_id","text":"<pre><code>Reads a Rich Schema object from the ledger by its unique ID.\n\n#Params\nsubmitter (optional): information about submitter\ndata: {\n    id: Rich Schema object's ID (as a DID for example),\n    ver: the version of the generic object template\n},\nregistry: identifier for the registry\n\n#Returns\nregistry_response: result as json,\nerror: {\n    code: aries common error code,\n    description:  aries common error description\n}\n</code></pre>"},{"location":"concepts/0420-rich-schemas-common/#read_rich_schema_object_by_metadata","title":"read_rich_schema_object_by_metadata","text":"<pre><code>Reads a Rich Schema object from the ledger by its unique combination of (name, version, type)\n\n#Params\nsubmitter (optional): information about submitter\ndata: {\n    rs_name: Rich Schema object name,\n    rs_version: Rich Schema object version,\n    rs_type: Rich schema object type's enum string (currently one of `ctx`, `sch`, `map`, `enc`, `cdf`, `pdf`),\n    ver: the version of the generic object template\n},\nregistry: identifier for the registry\n\n#Returns\nregistry_response: result as json,\nerror: {\n    code: aries common error code,\n    description:  aries common error description\n}\n</code></pre>"},{"location":"concepts/0420-rich-schemas-common/#reference","title":"Reference","text":"<ul> <li>0250: Rich Schema Objects</li> <li>0249: Aries Rich Schema Contexts </li> <li>0281: Aries Rich Schemas</li> </ul>"},{"location":"concepts/0420-rich-schemas-common/#drawbacks","title":"Drawbacks","text":"<p>Rich schema objects introduce more complexity.</p>"},{"location":"concepts/0420-rich-schemas-common/#rationale-and-alternatives","title":"Rationale and alternatives","text":""},{"location":"concepts/0420-rich-schemas-common/#rich-schema-object-id","title":"Rich Schema object ID","text":"<p>The following options on how a Rich Schema object can be identified exist: - DID unique for each Rich Schema - DID URL with the origin (issuer's) DID as a base - DID URL with a unique (not issuer-related) DID as a base - UUID or other unique ID</p> <p>UUID doesn't provide global resolvability. We can not say what ledger the Rich Schema object belongs to  by looking at the UUID.</p> <p>DID and DID URL give persistence, global resolvability and decentralization. We can resolve the DID and understand what ledger the Rich Schema object belongs to. Also we can see that the object with the same id-string on different ledger is the same object (if id-string is calculated against a canonicalized hash of the content).  </p> <p>However, Rich Schema's DIDs don't have cryptographic verifiability property of common DIDs, so this is a DID not associated with keys in general case. This DID belongs neither to person nor organization nor thing.</p> <p>Using Issuer's DID (origin DID) as a base for DID URL may be too Indy-specific as other ledgers may not have an Issuer DID. Also it links a Rich Schema object to the Issuer belonging to a particular ledger. </p> <p>So, we are proposing to use a unique DID for each Rich Schema object as it gives more natural way to identify  an entity in the distributed ledger world.  </p>"},{"location":"concepts/0420-rich-schemas-common/#rich-schema-object-as-did-doc","title":"Rich Schema object as DID DOC","text":"<p>If Rich Schema objects are identified by a unique DID, then a natural question is whether each Rich Schema object  needs to be presented as a DID DOC and resolved by a DID in a generic way.</p> <p>We are not requiring to define Rich Schema objects as DID DOCs for now. We may re-consider this in future once DID DOC format is finalized.</p>"},{"location":"concepts/0420-rich-schemas-common/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the proposed interface generic enough to support other data registries?</li> <li>We are not defining Rich Schema objects as DID DOCs for now. We may re-consider this in future  once aries-vdr interface for DID resolving is defined and DID DOC specification is finalized.</li> <li>Whether we should extend DID to be a standard for Rich Schema object IDs.</li> <li>Whether the proposed way to make a Canonicalization form of a content to be used for DID's id-string generation is good enough. </li> </ul>"},{"location":"concepts/0420-rich-schemas-common/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0430-machine-readable-governance-frameworks/","title":"Aries RFC 0430: Machine-Readable Governance Frameworks","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: PROPOSED</li> <li>Since: 2020-02-24</li> <li>Status Note: early proposal only  </li> <li>Start Date: 2020-02-24</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#summary","title":"Summary","text":"<p>Explains how governance frameworks are embodied in formal data structures, so it's possible to react to them with software, not just with human intelligence.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#motivation","title":"Motivation","text":"<p>We need to be able to write software that reacts to arbitrary governance frameworks in standard ways. This will allow various desirable ../../features.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#tutorial","title":"Tutorial","text":"<p>A governance framework (also called a trust framework in some contexts) is a set of rules that establish trust about process (and indirectly, about outcomes) in a given context. For example, the rules that bind buyers, merchants, vendors, and a global credit card company like Mastercard or Visa constitute a governance framework in a financial services context \u2014 and they have a corresponding trust mark to make the governance framework's relevance explicit. The rules by which certificate authorities are vetted and accepted by browser manufacturers, and by which CAs issue derivative certificates, constitute a governance framework in a web context. Trust frameworks are like guy wires: they balance opposing forces to produce careful alignment and optimal behavior.</p> <p></p> <p>Decentralized identity doesn't eliminate all forms of centralized authority, but its opt-in collaboration, openness, and peer orientation makes the need for trust rules particularly compelling. Somehow, a community needs to agree on answers to questions like these:</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#sample-questions-answered-in-a-trust-framework","title":"Sample Questions Answered in a Trust Framework","text":"<ul> <li>Which institutions should be trusted to attest key facts such as an individual's citizenship, graduation from college, HIV status, membership in an ethnic group, credit worthiness, etc?</li> <li>How do rules about consent, privacy, and repudiation influence the flow of data?</li> <li>Who can hold which parties accountable, and how, and when?</li> <li>What levels of assurance are required for certain privileges?</li> <li>How auditable must various activities be?</li> <li>How do incentives and reputation work?</li> <li>What terms of service are standard, odd-but-reasonable, or prohibited?</li> </ul> <p>Many industry groups are exploring these questions, and are building careful documentation of the answers they produce. It is not the purpose of this RFC to duplicate or guide such work. Rather, it's our goal to answer a secondary question:</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#the-question-tackled-by-this-rfc","title":"The Question Tackled By This RFC","text":"<p>How can answers to these questions be represented so they are consumable as artifacts of software policy? </p> <p>When we have good answers to this question, we can address feature requests like the following:</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#desirable-features","title":"Desirable Features","text":"<ul> <li>All the software used at a refugee camp \u2014 whether built by the United Nations, by an NGO like Doctors Without Borders, by startups providing identity wallets to individuals, or by military personnel \u2014 has a shared understanding about standards of proof, consent, enforcement, appeal, and privacy.</li> <li>Rules in an ecosystem can be versioned and updated formally, and parties who interact can know unambiguously whether their expectations align. If there is a misalignment, it is easy to identify the particulars.</li> <li>A user of an SSI-centric mobile app can be prompted about whether they'd like to accept as proof credentials issued under the rules of governance framework X (e.g., the governance framework for accredited institutions of higher education in Germany) \u2014 allowing them to accept or reject entire categories of proof without having to track the DIDs and business practices of every individual issuer they might encounter.</li> </ul>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#sample-data-structure","title":"Sample Data Structure","text":"<p>Trust frameworks generally begin as human-friendly content. They have to be created, reviewed, and agreed upon by experts from various disciplines: legal, business, humanitarian, government, trade groups, advocacy groups, etc. Developers can help by surfacing how rules are (or are not) susceptible to modeling in formal data structures. This can lead to an iterative process, where data structures and human conversations create refinement pressure on each other until the framework is ready for release.</p> <p>[TODO: The following blurb of JSON is one way to embody what we're after. I can imagine other approaches but haven't thought them through in detail. I'm less interested in the details of the JSON, for now, than in the ../../concepts we're trying to communicate and automate. So have a conversation about whether this format works for us, or should be tweaked/replaced.]</p> <p>Each problem domain will probably have unique requirements. Therefore, we start with a general governance framework recipe, but plan for extension. We use JSON-LD for this purpose. Here we present a simple example for the problem domain of university credentials in Germany. It manifests just the components of a governance framework that are common across all contexts; additional JSON-LD <code>@context</code> values can be added to introduce more structure as needed. (See Field Details for explanatory comments.)</p> <pre><code>{\n    \"@context\": [\n        // The first context must be this RFC's context. It defines core properties.\n        \"https://github.com/hyperledger/aries-rfcs/blob/main../../concepts/0430-machine-readable-governance-frameworks/context.jsonld\", \n        // Additional contexts can be added to extend.\n        \"https://kmk.org/uni-accred-trust-fw\"\n    ],\n    \"name\": \"Universit\u00e4tsakkreditierung\"\n    \"version\": \"1.0\",\n    \"logo\": \"http://kmk.org/uni-accred-trust-fw/logo.png\",\n    \"description\": \"Governs accredited colleges and universities in Germany.\",\n    \"docs_uri\": \"http://https://kmk.org/uni-accred-trust-fw/v1\",\n    \"data_uri\": \"http://https://kmk.org/uni-accred-trust-fw/v1/tf.json\",\n    \"topics\": [\"education\"],\n    \"jurisdictions\": [\"de\", \"eu\"],\n    \"geos\": [\"Deutschland\"],\n    \"roles\": [\"accreditor\", \"school\", \"graduate\", \"safe-verifier\"],\n    \"privileges\": [\n        {\"name\": \"accredit\", \"uri\": \"http://kmk.org/tf/accredit\"},\n        {\"name\": \"issue-edu\", \"uri\": \"http://kmk.org/tf/issue-edu\"},\n        {\"name\": \"hold-edu\", \"uri\": \"http://kmk.org/tf/hold-edu\"},\n        {\"name\": \"request-proof\", \"uri\", \"http://kmk.org/tf/request-proof\"\n    ],\n    \"duties\": [\n        {\"name\": \"safe-accredit\", \"uri\": \"http://kmk.org/tf/responsible-accredit\"},\n        {\"name\": \"GDPR-dat-control\", \"uri\": \"http://europa.eu/gdpr/trust-fw/gdpr-data-controller\"}\n        {\"name\": \"GDPR-edu-verif\", \"uri\": \"http://kmk.org/tf/gdpr-verif\"}\n        {\"name\": \"accept-kmk-tos\", \"uri\": \"http://kmk.org/tf/tos\"}\n    ],\n    \"define\": [\n        {\"name\": \"KMK\": \"id\": \"did:example:abc123\"},\n        {\"name\": \"KMK\": \"id\": \"did:anotherexample:def456\"},\n    ], \n    \"rules\": [\n        {\"grant\": [\"accredit\"], \"when\": {\"name\": \"KMK\"},\n            \"duties\": [\"safe-accredit\"]},\n        {\"grant\": [\"issue-edu\"], \"when\": {\n                // Proof request (see RFC 0037) specifying that\n                // institution is accredited by KMK.\n            },\n            // Any party who fulfills these criteria is considered\n            // to have the \"school\" role.\n            \"thus\": [\"school\"],\n            // And is considered to have the \"GDPR-dat-control\" duty.\n            \"duties\": [\"GDPR-dat-control\", \"accept-kmk-tos\"]\n        },\n        {\"grant\": \"hold-edu\", \"when\": {\n                // Proof request specifying that holder is a human.\n                // The presence of this item in the GF means that\n                // conforming issuers are supposed to verify\n                // humanness before issuing. Issuers can impose\n                // additional criteria; this is just the base\n                // requirement.\n            },\n            // Any party who fulfills these criteria is considered\n            // to qualify for the \"graduate\" role.\n            \"thus\": \"graduate\",\n            \"duties\": [\"accept-kmk-tos\"]\n        },\n        // In this governance framework, anyone can request proof based\n        // on credentials, as long as they demonstrate that they possess\n        // an \"approved verifier\" credential.\n        {\n            \"grant\": \"request-proof\", \"when\": {\n                // Proof request specifying that the party must possess\n                // a credential that makes them an approved verifier.\n                // The presence of this item in the GF means that\n                // provers should, at a minimum, verify the verifiers\n                // in this way before sharing proof. Provers can impose\n                // additional criteria of their own; this is just the\n                // base requirement.\n            }, \"thus\": \"safe-verifier\",\n            \"duties\": [\"GDPR-edu-verif\", \"accept-kmk-tos\"]\n        },\n        // Is there an authority that audits interactions?\n        \"audit\": {\n            // Where should reports be submitted via http POST?\n            \"uri\": \"http://kmk.org/audit\",\n            // How likely is it that a given interaction needs to\n            // be audited? Each party in the interaction picks a\n            // random number between 0 and 1, inclusive; if the number\n            // is &lt;= this number, then that party submits a report about it.\n            \"probability\": \"0.01\"\n        },\n        // Is there an authority to whom requests for redress can\n        // be made, if one party feels like another violates\n        // the governance framework? \n        \"redress\": {\n            \"uri\": \"http://kmk.org/redress\"\n        }\n    }    \n}\n</code></pre>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#using-the-sample","title":"Using the Sample","text":"<p>Let's look at how the above structure can be used to influence behavior of verifiable credential management software, and the parties that use it.</p> <p>We begin by noticing that KMK (KultusMinisterKonferenz), the accrediting body for universities in Germany, has a privileged role in this governance framework. It is given the right to operate as \"KMK\" as long as it proves control of one of the two DIDs named in the <code>define</code> array. </p> <p>We posit an issuer, Faber College, that wants to issue credentials compliant with this governance framework. This means that Faber College wants the <code>issue-edu</code> privilege defined at http://kmk.org/tf/issue-edu (see the second item in the <code>privileges</code> array). It wants to create credentials that contain the following field: <code>\"trust_framework\": \"http://https://kmk.org/uni-accred-trust-fw/v1/tf.json\"</code> (see the <code>data_uri</code> field). It wants to have a credential from KMK proving its accreditation (see second item in the <code>rules</code> array).</p> <p>Faber is required by this governance framework to accept the terms of service published at http://kmk.org/tf/tos, because it can't get the <code>issue-edu</code> privilege without incurring that duty (see the <code>accept-kmk-tos</code> duty in the second item in the <code>rules</code> array). KMK by implication incurs the obligation to enforce these terms of service when it issues a credential attesting Faber's accreditation and compliance with the governance framework.</p> <p>Assuming that Faber proceeds and satisfies KMK, Faber is now considered a <code>school</code> as far as this governance framework is concerned.</p> <p>Now, let us suppose that Alice, a student at Faber, wants to get a diploma as a verifiable credential. In addition to whatever else Faber does before it gives Alice a diploma, Faber is obligated by the governance framework to challenge Alice to prove she's a human being (see <code>when</code> in the third item of the <code>rules</code> array). Hopefully this is easy, and was done long before graduation. :-) It is also obligated to introduce Alice to the terms of service for KMK, since Alice will be acquiring the <code>graduate</code> role and this rule has the <code>accept-kmk-tos</code> duty. How Faber does this is something that might be clarified in the terms of service that Faber already accepted; we'll narrate one possible approach.</p> <p>Alice is holding a mobile app that manages credentials for her. She clicks an invitation to receive a credential in some way. What she sees next on her screen might look something like this:</p> <p></p> <p>Her app knew to display this message because the issuer, Faber College, communicated its reliance on this governance framework (by referencing its <code>data_uri</code>) as part of an early step in the issuance process (e.g., in the invitation or in the <code>offer-credential</code> message). Notice how metadata from the governance framework \u2014 its title, version, topics, and descriptions \u2014 show up in the prompt. Notice as well that governance frameworks have reputations. This helps users determine whether the rules are legitimate and worth using. The \"More Info\" tab would link to the governance framework's <code>docs_uri</code> page.</p> <p>Alice doesn't have to re-accept the governance framework if she's already using it (e.g., if she already activated it in her mobile app because it's relevant to other credentials she holds). As a person works regularly within a particular credential domain, decisions like these will become cached and seamless. However, we're showing the step here, for completeness.</p> <p>Suppose that Alice accepts the proposed rules. The governance framework requires that she also accept the KMK terms of service. These might require her to report any errors in her credential promptly, and clarify that she has the right to appeal under certain conditions (see the <code>redress</code> section of the governance framework data structure). They might also discuss the KMK governance framework's requirement for random auditing (see the <code>audit</code> section).</p> <p>A natural way to introduce Alice to these topics might be to combine them with a normal \"Accept terms of service\" screen for Faber itself. Many issuers are likely to ask holders to agree to how they want to manage revocation, privacy, and GDPR compliance; including information about terms that Faber inherited from the governance framework would be an easy addition.</p> <p>Suppose, therefore, that Alice is next shown a \"Terms of Service\" screen like the following.</p> <p></p> <p>Note the hyperlink back to the governance framework; if Alice already accepted the governance framework in another context, this helps her know what governance framework is in effect for a given credential.</p> <p>After Alice accepts the terms, she now proceeds with the issuance workflow. For the most part, she can forget about the governance framework attached to her credential \u2014 but the software doesn't. Some of the screens it might show her, because of information that it reads in the governance framework, include things like:</p> <p></p> <p>Or, alternatively:</p> <p></p> <p>In either case, proof of the issuer's qualifications was requested automatically, using canned criteria (see the second item in the governance framework's <code>rules</code> array).</p> <p>A similar kind of check can be performed on verifiers:</p> <p></p> <p>Or, alternatively:</p> <p></p> <p>Trust framework knowledge can also be woven into other parts of a UI, as for example:</p> <p></p> <p>And:</p> <p></p> <p>And:</p> <p></p> <p>The point here is not the specifics in the UI we're positing. Different UX designers may make different choices. Rather, it's that by publishing a carefully versioned, machine-readable governance framework, such UIs become possible. The user's experience becomes less about individual circumstances, and more about general patterns that have known reputations, dependable safeguards, and so forth.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#versioning","title":"Versioning","text":"<p>Trust framework data structures follow semver rules:</p> <ul> <li> <p>A major change is one that breaks the trust status of another party as a result of the change. Examples include:</p> <ul> <li>Altering the internal structure of the JSON in a breaking way, such that software can no longer process the structure. (Software is required to ignore fields in this structure that it doesn't understand, so simply adding things won't do this.)</li> <li>Disallowing a formerly defined field.</li> <li>Making a field required that used to be optional.</li> <li>Removing a defined role or privilege, such that relationships built under an old version of the framework are no longer explainable in an updated version.</li> <li>Changing how privileges are granted, in such a way that a party who had privileges before would lose them across the update.</li> <li>Substantive changes to terms of service.</li> </ul> </li> <li> <p>A minor change adds precision or options to an existing governance framework, without invalidating trust built with proximate, preceding versions. For example:</p> <ul> <li>Adding new roles or privileges.</li> <li>Changing URIs or minor details of auditing, redress, or terms of service.</li> <li>Changing privilege grants such that existing parties with existing privileges get new privileges as well.</li> </ul> </li> <li> <p>Patch versions of governance frameworks are supported but generally not displayed. They should be safe to accept automatically. They include things like:</p> <ul> <li>Adding new topics (hash tags).</li> <li>Tweaking descriptions.</li> </ul> </li> </ul>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#localization","title":"Localization","text":"<p>Trust frameworks can offer localized alternatives of text using the same mechanism described in RFC 0043: l10n; treat the governance framework JSON as a DIDComm message and use decorators as it describes.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#reference","title":"Reference","text":"<p>We've tried to make the sample JSON above self-describing. All fields are optional except the governance framework's <code>name</code>, <code>version</code>, <code>data_uri</code>, and at least one <code>define</code> or <code>rules</code> item to confer some trust.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#field-details","title":"Field Details","text":""},{"location":"concepts/0430-machine-readable-governance-frameworks/#name","title":"<code>name</code>","text":"<p>A short descriptive string that explains the governance framework's purpose and focus. Extends http://schema.org/name.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#version","title":"<code>version</code>","text":"<p>A semver-formatted value. Typically only major and minor segments are used, but patch should also be supported if present. Extends http://schema.org/version with the major/minor semantics discussed under Versioning above.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#logo","title":"<code>logo</code>","text":"<p>A URI that references something visually identifying for this framework, suitable for display to a user. Extends http://schema.org/logo.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#description","title":"<code>description</code>","text":"<p>Longer explanatory comment about the purpose and scope of the framework. Extends http://schema.org/description.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#docs_uri","title":"<code>docs_uri</code>","text":"<p>Where is this governance framework officially published in human-readable form? A human should be able to browse here to learn more. Extends http://schema.org/url.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#data_uri","title":"<code>data_uri</code>","text":"<p>Where is this governance framework officially published as a machine-readable data structure? A computer should be able to GET this JSON (MIME type = application/json) at the specified URI.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#topics","title":"<code>topics</code>","text":"<p>In which problem domains is this governance framework relevant? Think of these like hash tags; they constitute a loose, overlapping topic cloud rather than a normative taxonomy; the purpose is to facilitate search.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#geos","title":"<code>geos</code>","text":"<p>In which geographies is this governance framework relevant? May be redundant with jurisdictions in many cases.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#jurisdictions","title":"<code>jurisdictions</code>","text":"<p>In which legal jurisdictions is this governance framework relevant? Values here should use ISO 639-2 or 3 language code, possibly narrowed to a standard province and even county/city using <code>&gt;</code> as the narrowing character, plus standard abbreviations where useful: <code>us&gt;tx&gt;houston</code> for \"Houston, Texas, USA\" or <code>ca&gt;qc</code> for the province of Quebec in Canada.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#roles","title":"<code>roles</code>","text":"<p>Names all the roles that are significant to understanding interactions in this governance framework. These map to X in rules like \"X can do Y if Z.\"</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#privileges","title":"<code>privileges</code>","text":"<p>Names all the privileges that are significant to understanding interactions in this governance framework. These map to Y in rules like \"X can do Y if Z.\" Each privilege is defined for humans at the specified URI, so a person can understand what it entails.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#duties","title":"<code>duties</code>","text":"<p>Name all the duties that are significant to understanding interactions in this governance framework. Each duty is defined for humans at the specified URI, so a person can understand what it entails.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#define","title":"<code>define</code>","text":"<p>Uses an array of <code>{\"name\":x, \"id\": did value}</code> objects to define key participants in the ecosystem.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#rules","title":"<code>rules</code>","text":"<p>Uses SGL syntax to describe role-based rules of behavior like \"X can do Y if Z,\" where Z is a criterion following \"when\". </p> <p>Another sample governance framework (including the human documentation that would accompany the data structure) is presented as part of the discussion of guardianship in RFC 0103.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#drawbacks","title":"Drawbacks","text":""},{"location":"concepts/0430-machine-readable-governance-frameworks/#timing","title":"Timing?","text":"<p>It may be early in the evolution of the ecosystem to attempt to standardize governance framework structure. (On the other hand, if we don't standardize now, we may be running the risk of unwise divergence.)</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#overkill","title":"Overkill?","text":"<p>Joe Andrieu has pointed out on W3C CCG mailing list discussions that some important use cases for delegation involve returning to the issuer of a directed capability to receive the intended privilege. This contrasts with the way verifiable credentials are commonly used (across trust domain boundaries).</p> <p>Joe notes that governance frameworks are unnecessary (and perhaps counterproductive) for the simpler, within-boundary case; if the issuer of a directed capability is also the arbiter of trust in the end, credentials may be overkill. To the extent that Joe's insight applies, it may suggest that formalizing governance framework data structures is also overkill in some use cases.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>We could leave governance frameworks as entirely human-consumable artifacts. This would cause developers to interpret each set of such artifacts into code in a unique way. Bespoke adaptation might result in more polished UX and impose less learning curve on users, but it would also create larger integration burdens and greater difficulty in assessing trust.</li> </ul>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#prior-art","title":"Prior art","text":"<p>Some of the work on consent receipts, both in the Kantara Initiative and here in RFC 0167, overlaps to a small degree. However, this effort and that one are mainly complementary rather than conflicting.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>How do we enumerate canonical proof requests, and map them to circumstances appropriately?</li> <li>How do we test whether those circumstances apply? </li> </ul>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0430-machine-readable-governance-frameworks/gov-fw-covid-19/","title":"Gov fw covid 19","text":"<pre><code>{\n    \"@context\": [\n        \"https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks\", \n        \"https://fightthevirus.org/covid19-fw\"\n    ],\n    \"name\": \"COVID-19 Creds\"\n    \"1.0\",\n    \"description\": \"Which health-related credentials can be trusted for which levels of assurance, given which assumptions.\",\n    \"docs_uri\": \"http://fightthevirus.org/covid19-fw/v1\",\n    \"data_uri\": \"http://fightthevirus.org/covid19-fw/v1/tf.json\",\n    \"topics\": [\"health\", \"public safety\"],\n    \"jurisdictions\": [\"us\", \"uk\", \"eu\"],\n    \"roles\": [\"healthcare-provider\", \"healthcare-worker\", \"patient\"],\n    \"privileges\": [\n        {\"name\": \"travel\", \"uri\": \"http://ftv.org/tf/travel\"},\n        {\"name\": \"receive-healthcare\", \"uri\": \"http://ftv.org/tf/be-patient\"},\n        {\"name\": \"tlc-fragile\", \"uri\": \"http://ftv.org/tf/tlc\"},\n        {\"name\": \"visit-hot-zone\", \"uri\": \"http://ftv.org/tf/visit\"}\n    ],\n    // Name all the duties that are significant to understanding\n    // interactions in this governance framework. Each duty is defined for humans\n    // at the specified URI, so a person can understand what it\n    // entails.\n    \"duties\": [\n        {\"name\": \"safe-accredit\", \"uri\": \"http://kmk.org/tf/responsible-accredit\"},\n        {\"name\": \"GDPR-dat-control\", \"uri\": \"http://europa.eu/gdpr/trust-fw/gdpr-data-controller\"}\n        {\"name\": \"GDPR-edu-verif\", \"uri\": \"http://kmk.org/tf/gdpr-verif\"}\n        {\"name\": \"accept-kmk-tos\", \"uri\": \"http://kmk.org/tf/tos\"}\n    ],\n    // Use DIDs to define key participants in the ecosystem. KMK is\n    // the accreditation authority for higher education in Germany.\n    // Here we show it using two different DIDs.\n    \"define\": [\n        {\"name\": \"KMK\": \"id\": \"did:example:abc123\"},\n        {\"name\": \"KMK\": \"id\": \"did:anotherexample:def456\"},\n    ], \n    // Describe role-based rules of behavior like \"X can do Y if Z,\"\n    // where Z is a criterion following \"when\".\n    \"rules\": [\n        {\"grant\": [\"accredit\"], \"when\": {\"name\": \"KMK\"},\n            \"duties\": [\"safe-accredit\"]},\n        {\"grant\": [\"issue-edu\"], \"when\": {\n                // Proof request (see RFC 0037) specifying that\n                // institution is accredited by KMK.\n            },\n            // Any party who fulfills these criteria is considered\n            // to have the \"school\" role.\n            \"thus\": [\"school\"],\n            // And is considered to have the \"GDPR-dat-control\" duty.\n            \"duties\": [\"GDPR-dat-control\", \"accept-kmk-tos\"]\n        },\n        {\"grant\": \"hold-edu\", \"when\": {\n                // Proof request specifying that holder is a human.\n                // The presence of this item in the TF means that\n                // conforming issuers are supposed to verify\n                // humanness before issuing. Issuers can impose\n                // additional criteria; this is just the base\n                // requirement.\n            },\n            // Any party who fulfills these criteria is considered\n            // to qualify for the \"graduate\" role.\n            \"thus\": \"graduate\",\n            \"duties\": [\"accept-kmk-tos\"]\n        },\n        // In this governance framework, anyone can request proof based\n        // on credentials. No criteria are tested to map an entity\n        // to the \"anyone\" role.\n        {\n            \"grant\": \"request-proof\", \"thus\": \"anyone\",\n            \"duties\": [\"GDPR-edu-verif\", \"accept-kmk-tos\"]\n        },\n    ],\n    // Is there an authority that audits interactions?\n    \"audit\": {\n        // Where should reports be submitted via http POST?\n        \"uri\": \"http://kmk.org/audit\",\n        // How likely is it that a given interaction needs to\n        // be audited? Each party in the interaction picks a\n        // random number between 0 and 1, inclusive; if the number\n        // is &lt;= this number, then that party submits a report about it.\n        \"probability\": \"0.01\"\n    },\n    // Is there an authority to whom requests for redress can\n    // be made, if one party feels like another violates\n    // the governance framework? \n    \"redress\": {\n        \"uri\": \"http://kmk.org/redress\"\n    }\n}   \n</code></pre>"},{"location":"concepts/0440-kms-architectures/","title":"0440: KMS Architectures","text":"<ul> <li>Authors: Michael Lodder</li> <li>Status: PROPOSED</li> <li>Since: 2020-03-06</li> <li>Status Note: Proposed</li> <li>Supersedes: Wallets, uses ../../concepts from LOX</li> <li>Start Date: 2019-12-02</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0440-kms-architectures/#summary","title":"Summary","text":"<p>A Key Management Service (KMS) is designed to handle protecting sensitive agent information like keys, credentials, protocol state, and other data.  User authentication, access control policies, and cryptography are used in various combinations to mitigate various threat models and minimize risk. However, how to do this in practice is not intuitive and done incorrectly results in flawed or weak designs.  This RFC proposes best practices for designing a KMS that offers reasonable tradeoffs in flexibility for implementers with strong data security and privacy guarantees.</p>"},{"location":"concepts/0440-kms-architectures/#motivation","title":"Motivation","text":"<p>A KMS needs to be flexible to support various needs that arise when implementing agents. Mobile device needs are very different from an enterprise server environment, but ultimately the secrets still need to be protected in all environments. Some KMSs have already been implemented but fail to consider all the various threat models that exist within their designs. Some overlook good authentication schemes. Some misuse cryptography making the implementation insecure. A good KMS should provide the ability to configure alternative algorithms that are validated against specific standards like the Federal Information Processing Standards (FIPS). This RFC is meant to reduce the chances that an insecure implementation could be deployed while raising awareness of principles used in more secure designs.</p>"},{"location":"concepts/0440-kms-architectures/#tutorial","title":"Tutorial","text":"<p>A KMS can be broken into three main components with each component having potential subcategories. These components are designed to handle specific use cases and should be plug-and-play. The components are listed below and described in detail in the following sections:</p> <ol> <li>Enclave - <ul> <li>Safeguards cryptographic keys</li> <li>Key Generation<ul> <li>Encryption</li> <li>Digital Signatures</li> <li>Key exchange</li> <li>Proof generation and verification </li> </ul> </li> </ul> </li> <li>Persistence - <ul> <li>Stores non-key data<ul> <li>Verifiable credentials</li> <li>Protocol states</li> <li>DID documents</li> <li>Other metadata</li> </ul> </li> </ul> </li> <li>LOX - <ul> <li>Handle user authentication</li> <li>Access control enforcement</li> <li>Session/context establishment and management to the previous layers as described here.</li> </ul> </li> </ol>"},{"location":"concepts/0440-kms-architectures/#architecture","title":"Architecture","text":"<p>LOX sits between clients and the other subsystems. LOX asks the Enclave to do specific cryptographic operations and may pass the results to clients or Persistence or LOX may consume the results itself. The persistence layer does not directly interact with the enclave layer nor does the enclave layer interact directly with the persistence layer.</p> <p></p>"},{"location":"concepts/0440-kms-architectures/#lox","title":"LOX","text":"<p>LOX is the first layer KMS consumers will encounter and where the bulk of KMS work for implementers happens. LOX is divided into the following subcomponents that are not mutually exclusive:</p> <ol> <li>Authentication - Credentials for accessing the KMS and how to communicate with the KMS. Username/Passwords, PINS, Cryptographic keys, Verifiable credentials, Key fobs, key cards, and OpenID Connect are common methods for this layer. Any sensitive data handled by in this layer should be cleared from memory and minimize its footprint. </li> <li>Access control - Policies that indicate who can access the data and how data are handled. </li> <li>Audit - Logging about who does what and when and how verbose are the details </li> </ol> <p>Connecting to a KMS is usually done using functional system or library API calls, physical means like USB, or networks like Bluetooth, SSH, or HTTPS. These connections should be secured using encryption techniques like TLS or SSH or Signal other methods to prevent eavesdropping on  authentication credentials from end users. This is often the most vulnerable part of the system because its easy to  design something with weak security like passwords with only 6 characters and sent in plaintext.  It is preferred to use keys and multi-factor authentication techniques for connecting to LOX. Since password based sign ins are the most common, the following is a list of good methods for handling password based sign ins.</p>"},{"location":"concepts/0440-kms-architectures/#use-hashing-specially-designed-for-passwords","title":"Use hashing specially designed for passwords","text":"<p>Password based hashes are designed to be slow so the outputs are not so easily subjected to a brute-force dictionary attack. Simply hashing the password with cryptographic algorithms like Sha2/Sha3/Blake2 is not good enough. Below is a list of approved algorithms</p> <ol> <li>PBKDF2</li> <li>Bcrypt</li> <li>Scrypt</li> <li>Argon2</li> </ol> <p>The settings for using each of these should be enough to make even the strongest hardware take about 1-2 seconds to complete. The recommended settings in each section, also apply to mobile devices.</p> <p>PBKDF2</p> <p>Many applications use PBKDF2 which is NIST approved. However, PBKDF2 can use any SHA-family hash algorithm. Thus, it can be made weak if paired with SHA1 for example. When using PBKDF2, choose SHA2-512, which is significantly slower in current GPUs. The PBKDF2 parameters are</p> <ul> <li><code>N</code> - iterations count (the number of hashes to perform, \u2265100K recommended)</li> <li><code>password</code> - the input password</li> <li><code>salt</code> - securely-generated random bytes (128 bits recommended)</li> <li><code>hash</code> - The hash algorithm to use (SHA2-512 recommended)</li> </ul> <p>Bcrypt</p> <p>Bcrypt is a functional variant of the Blowfish cipher designed specially for password hashing. Unfortunately, the password sizes are limited to the first 72 bytes, any extra bytes are ignored. The recommended number of rounds  to use is \u226514. Bcrypt can support up to 31 rounds. Bcrypt is less resistant to ASIC and GPU attacks because it uses constant memory making it easier to build hardware-accelerated password crackers. When properly configured, Bcrypt is considered secure and is widely used in practice.</p> <ul> <li><code>N</code> - number of rounds (\u226514 recommended)</li> <li><code>password</code> - the input password</li> <li><code>salt</code> - securely-generated random bytes (128 bits recommended)</li> </ul> <p>Scrypt</p> <p>Scrypt is designed to make it costly to perform large-scale custom hardware attacks by requiring large amounts of memory. It is memory-intensive on purpose to prevent GPU, ASIC and FPGA attacks.  Scrypt offers multiple parameters:</p> <ul> <li><code>N</code> - iterations count (affects memory and CPU usage), e.g. 16384 or 2048</li> <li><code>r</code> - block size (affects memory and CPU usage), e.g. 8</li> <li><code>p</code> - parallelism factor (threads to run in parallel - affects the memory, CPU usage), usually 1</li> <li><code>password</code> - the input password</li> <li><code>salt</code> - securely-generated random bytes (128 bits recommended)</li> <li><code>derived-key-length</code> - how many bytes to generate as output, e.g. 32 bytes (256 bits)</li> </ul> <p>The memory in Scrypt is accessed in strongly dependent order at each step, so the memory access speed is the algorithm's bottleneck. The memory required is calculated as <code>128 * N * r * p</code> bytes. Example: 128*16384*8*1 = 16MB</p> <p>Choosing parameters depends on how much waiting is desired and what level of security (cracking resistance) should be achieved.</p> <p>MyEtherWallet uses N=8192, r=8, p=1. This is not considered strong enough for crypto wallets. Parameters of N=16384,r=8,p=1 (RAM = 2MB) typically take around 0.5 seconds, used for interactive sign ins. This doesn't hammer server side performance too much where many users can login at the same time. N=1048576,r=8,p=1 (RAM = 1GB) takes around 2-3 seconds. Scrypt is considered highly secure when properly configured.</p> <p>Argon2</p> <p>Argon2 is optimized for the x86 architecture and exploits the cache and memory layouts of modern Intel and AMD processors. It was the password hash competition winner and is recommended over PBKDF2, Bcrypt and Scrypt. Not recommended for ARM ABI's as performance tends to be much slower. This performance hit seem be desirable but what tends to happen is the parameters are configured lower for ARM environments to be reasonable but then can be cracked at 2-3 times faster when the hash is brute-forced on x86. Argon2 comes in three flavors: Argon2d, Argon2i and Argon2id and uses the  following parameters</p> <ul> <li>Argon2d - provides strong GPU resistance, but has potential side-channel attacks. Best if used on end-user machines where side channel attacks are less likely to happen.</li> <li>Argon2i - provides less GPU resistance, but has no side-channel attacks. Best if used for server-side sign ins.</li> <li> <p>Argon2id - combines both. Runs Argon2i first then Argon2d second, thus providing both side-channel attack protection and brute-force cost savings.</p> </li> <li> <p><code>password</code> - the input password</p> </li> <li><code>salt</code> - securely-generated random bytes (128 bits recommended)</li> <li><code>N</code> - number of iterations to perform</li> <li><code>m</code> - amount of memory to use in kilobytes</li> <li><code>p</code> - degree of parallelism (number of threads)</li> <li><code>derived-key-length</code> - how many bytes to generate as output, e.g. 32 bytes (256 bits)</li> </ul> <p>Parameters p=2,m=65536,n=128 typically take around 0.5 seconds, used for interactive sign ins. Moderate parameters are p=3,m=262144,n=192 typically take around 2-3 seconds, and sensitive parameters are p=4,m=1048576,n=256. Always time it in your environments.</p>"},{"location":"concepts/0440-kms-architectures/#session-establishment","title":"Session establishment","text":"<p>Upon authentication to LOX, LOX should establish connections to the enclave component and persistence component which should appear opaque to the client. LOX may need to authenticate to the enclave component or persistence component depending on where client access credentials are stored by implementors. Its preferable to store these in keychains or keystores if possible where the access is determined by the operating system and can include stronger mechanisms like TouchID or FaceID and hardware tokens in addition to passwords or pins. As described in LOX, the credentials for accessing the enclave and persistence layer can then be retrieved or generated if the client is new and stored in a secure manner. </p>"},{"location":"concepts/0440-kms-architectures/#using-os-keychain","title":"Using OS Keychain","text":""},{"location":"concepts/0440-kms-architectures/#using-password-based-key-derivation","title":"Using Password based key derivation","text":""},{"location":"concepts/0440-kms-architectures/#session-management","title":"Session management","text":"<p>Active connections to these other layers may possibly be pooled for efficiency reasons but care must be taken to avoid accidental permission grants. For example, Alice must not be able to use Bob's connection and Bob for Alice. However, the same database connection credentials might be used transparently for Alice and Bob, in which  case the database connection can be reused. This should be an exception as credential sharing is strongly discouraged. Auditing in the database might not be able to determine whether Alice or Bob performed a specific query.  Connections to enclaves and persistence usually requires session or context objects to be handled.  These must not be returned to clients, but rather maintained by LOX. When a client connection is closed, these must be securely deleted and/or closed.</p> <p></p>"},{"location":"concepts/0440-kms-architectures/#enclave","title":"Enclave","text":"<p>The enclave handles as many operations related to cryptography and key management as possible to ensure keys are adequately protected. Keys can potentially be stolen by means of side channel attacks from memory, disk, operational timing, voltage, heat, extraction, and others. Each enclave has been designed to consider certain threat models and mitigate these risks. For example, a Thales HSM is very different than a Yubico HSM or an Intel SGX Enclave. The correct mental model is to think about the formal guarantees that are needed and pick and choose/design the enclave layer to suite those needs. Build the system that meets the definition(s) of security then prove it meets the requirements. An enclave functions as a specialized cryptography component. The enclave provides APIs for passing in data to be operated on and executes its various cryptographic operations internally and only returns results to callers. The following is a list of operations that enclaves can support. The list will vary depending on the vendor.</p> <ol> <li>Generate asymmetric key</li> <li>Generate symmetric key</li> <li>Generate random</li> <li>Put key</li> <li>Delete key</li> <li>Wrap key</li> <li>Unwrap key</li> <li>Export wrapped key</li> <li>Import wrapped key</li> <li>List keys</li> <li>Update key metadata/capability</li> <li>Get key info/metadata</li> <li>Derive key agreement</li> <li>Sign</li> <li>Verify</li> <li>Encrypt</li> <li>Decrypt</li> <li>Get enclave info - metadata about the enclave like device info, version, manufacturer</li> <li>Query enclave capability</li> <li>Audit - e.g. enable/disable auditing</li> <li>Log - e.g. read audit logs</li> <li>Attestation - e.g. generate proofs about the enclave</li> </ol> <p>Most hardware implementations do not allow key material to be passed through the API, even in encrypted form, so a system of external references is required that allows keys to be referenced in a way that supports:</p> <ol> <li>Consistency - The same ID refers to the same key every time.</li> <li>Naming schemes - such as RSA_PSS_2048_8192_SHA256</li> </ol> <p>Some enclaves do support key material to be passed through the API. If allowed, these are called Key blocks. Key blocks are how a key is formatted when passed into or out of the enclave. See here.</p> <p>In keeping with the drive for enclaves to be simple and hard to mess up, the proposal is to make key IDs in the enclave storage be simple UTF-8 string names, and leave the underlying provider implementation to deal with the complexities of translation, key rollover, duplication and so on. Each of these operations uses different parameters and the enclave should specify what it allows and what it does not. If code needs to discover the capabilities on the fly, it is much more efficient to query the enclave if it supports it rather than return a list of capabilities that are search externally.</p> <p>Enclaves also store metadata with each key. This metadata consists of</p> <ol> <li>Attributes - e.g. key id, label, tag</li> <li>Access Constraints - e.g. require passcode or biometric auth to use</li> <li>Access Controls - e.g. can decrypt, can verify, can sign, exportable when wrapped</li> </ol>"},{"location":"concepts/0440-kms-architectures/#attributes","title":"Attributes","text":"<p>Attributes describe a key and do not enforce any particular permission about it. Such attributes typically include</p> <ol> <li>Identifier - e.g. f12f149d-e8d9-427c-85c7-f116f87f2e70 or 5a71028a74f1ad9f3f39 or 9s5m7EEJq1zZyc or 158</li> <li>Alias - e.g. fcb9ec81-d613-4c0f-a023-470155f38f92 or 1BC6HUi1soNML. Useful to sharing key but using a different id. Audits would show which one was used.</li> <li>Label or Description - e.g. Alice to Bob's DID key</li> <li>Class - e.g. public, private, symmetric</li> <li>Tag - e.g. sign, verify, did</li> <li>Type - e.g. aes, rsa, ecdsa, ed25519</li> <li>Size in bits - e.g. 256, 2048</li> <li>Creator - i.e. the original creator/owner</li> <li>Creation date</li> <li>Last modification date</li> <li>Always sensitive - i.e. was created with sensitive flag and never removed this control</li> <li>Never exported - i.e. never left the enclave</li> <li>Derived from - e.g. use PBKDF2 on this value to generate the key, or reference another key as a seed derived using HKDF</li> </ol> <p>Most of these attributes cannot change like Size in bits and are read-only. Aliases, Labels, and Tags are the only Attributes that can change. Enclaves allow 1 to many aliases and tags but only one label. The enclave should specify how many tags and aliases may be used. A common number is 5 for both.</p>"},{"location":"concepts/0440-kms-architectures/#access-constraints","title":"Access Constraints","text":"<p>Constraints restrict key access to be done under certain conditions like who is accessing the key like the owner(s) or group(s), password or biometric authentication, when host is unlocked like in mobile devices, always accessible. Constraints must be honored by the enclave to consumers to have confidence and trust. Possible constraints are:</p> <ol> <li>Owner(s) - e.g. who is allowed to access and use the key.</li> <li>User presence - e.g. require additional authentication like passcode or biometric auth (TouchID/FaceID). Authentication is on a per key basis vs just owner. Must be owner and meet additional authentication requirements.</li> <li>Biometric - e.g. require biometric authentication</li> <li>Passcode - e.g. require passcode authentication</li> <li>Fresh Interval - e.g. allowed time between additional authentications, 10 minutes is acceptable for extra sensitive keys</li> </ol> <p>Each of these can be mixed in combinations of AND and OR conjunctions. For example, key ABC might have the following constraints</p> <p>OR ( AND (Owner, User presence, Passcode), AND(Owner, User presence, Biometric) ) This requires the owner to enter an additional passcode OR biometric authentication to access the key.</p>"},{"location":"concepts/0440-kms-architectures/#access-controls","title":"Access Controls","text":"<p>Enclaves use access controls to restrict what operations keys are allowed to perform and who is allowed to use them. Controls are set during key generation and may or may not be permitted to change depending on the vendor or settings. Controls are stored with the key and enforced by the enclave. Possible access controls are:</p> <ol> <li>Can Key Agreement - e.g. Diffie-Hellman</li> <li>Can Derive - e.g. serve as seed to other keys</li> <li>Can Decrypt - e.g. can decrypt data for private keys and symmetric keys</li> <li>Can Encrypt - e.g. can encrypt data for public keys and symmetric keys</li> <li>Can Wrap - e.g. can be used to wrap another key to be exported</li> <li>Can Unwrap - e.g. can be used to unwrap a key that was exported</li> <li>Can Sign - e.g. can create digital signatures for private keys and MACs for symmetric keys</li> <li>Can Verify - e.g. can verify digital signatures for public keys and MACs for symmetric keys</li> <li>Can Attest - e.g. can be used to prove information about the enclave</li> <li>Is Exportable - e.g. can be exported from the enclave.</li> <li>Is Sensitive - e.g. can only be exported in an encrypted format.</li> <li>Is Synchronizable - e.g. can only be exported directly to another enclave</li> <li>Is Modifiable - e.g. can any controls be changed</li> <li>Is Visible - e.g. is the key available to clients outside the enclave or used internally.</li> <li>Valid Until Date - e.g. can use until this date, afterwards the key cannot be used</li> </ol> <p>To mitigate certain attacks like key material leaking in derive and encrypt functions, keys should be as limited as possible to one task (see here and here). For example, allowing concatenation of a base key to another key should be discouraged as it has the potential to perform key extraction attacks (see Clulow. Clulow shows that a key with decrypt and wrap capabilities can export a key then be used to decrypt it. This applies to both symmetric keys with decrypt and wrap and its variant where the wrapping key is a public key and the decryption key is the corresponding private key). The correct mental model to follow for enclave implementors is to model an intruder than can call any API command in any order he likes using any values that he knows. Sensitive and unexportable keys should never be directly readable and should not be changeable into nonsensitive and exportable. If a key can wrap, it should not be allowed to decrypt. Some of these controls should be considered sticky\u2013\u2013cannot be changed to mitigate these attacks like sensitive. This is useful when combined with conflicting controls like wrap and decrypt.</p> <p>Exporting key requirements</p> <p>The most secure model is to not allow keys to leave an enclave. However, in practice, this is not always reasonable. Backups, replications must be made, keys must be shared between two enclaves for data to be shared by two parties. When a key is lifted from the enclave, its attributes, constraints and controls must correctly bind with it. When a key lands in another enclave, the enclave must honor the attributes, constraints and controls with which it came. The wrapping format should be used to correctly bind key attributes, constraints and controls to the key. This prevents attacks where the key is wrapped and unwrapped twice with conflicting metadata as described by Delaune et. al, Cachin et.al, Cortier and Steel and Bortolozzo.</p>"},{"location":"concepts/0440-kms-architectures/#templates","title":"Templates","text":"<p>Some enclaves support creating templates such that keys can be generated and wrapped following secure guidelines in a reproducible way. Define separate templates for key generation and key wrapping.</p>"},{"location":"concepts/0440-kms-architectures/#final-enclave-notes","title":"Final enclave notes","text":"<p>Hardware enclaves typically have limited storage space like a few megabytes. A hardware enclave could be used to protect a software enclave that has a much higher storage capacity. A KMS is not limited to just one enclave. Cloud access security brokers (cloud enclaves) like Hashicorp Vault, Amazon\u2019s Cloud HSM, Iron Core Labs, Azure Key Vault, and Box Keysafe require trusting a SaaS vendor will store them in a place that is not vulnerable to data breaches. Even then, there is no assurance that the vendor, or one of their partners, won\u2019t access the secret material. This doesn't belittle their value, it's just another point to consider when using SaaS enclaves. Keys should be shared as little as possible if at all. Keys should be as short lived as possible and have a single purpose. This limits the need to replicate keys to other agents, either for dual functionality or recovery purposes, as well as damage in the event of a compromise.</p>"},{"location":"concepts/0440-kms-architectures/#persistence","title":"Persistence","text":"<p>This layer is meant to store other data in a KMS like credentials and protocol state. This layer could be optional for static agents where they store very little if anything. Credentials that access the persistence layer should stored in the enclave layer or with LOX in keychains. For example, if the persistence layer is a postgres database, the username/password or keypair to authenticate to the database could be stored in the enclave rather than a config file. Upon a successful authentication to LOX, these credentials are retrieved to connect to postgres and put into a connection pool. This is more secure than storing credentials in config files, environment variables or prompting them from user input.</p> <p>The most common storage mechanism is a SQL database. Designers should consider their system requirements in terms of performance, environments, user access control, system administrator access, then read Kamara\u2019s blog on how to develop encrypted databases (see 1, 2, 3, 4). For example, mobile environments vs enterprise environments. Mobile environments probably won\u2019t have a network adversary when using secure storage or an Honest-but-curious adversary where as enterprise environments will. Should the query engine be able to decrypt data prior to filtering or should it run on encrypted data and the querier performs decryption? Neither of these is considered wrong per se, but each comes with a set of trade offs. In the case of query engine decryption, there is no need to write a separate query mechanism and databases can execute as they normally do with a slight decrease in performance from decryption and encryption. However, the data reader must trust the query engine to not leak data or encryption keys. If the querier performs data encryption/decryption, no trust is given to the query engine but additional work must be performed before handing data to the engine and this searchable encryption is still vulnerable to access pattern leakage. What is practical engineering vs design vs theory? Theory is about what can and can\u2019t be done and why. Design is about using efficient primitives and protocols. Engineering is about effective and secure implementation.</p> <p>Implementers should consider the following threats and adversary sections.</p> <p>Threats * Memory access patterns leakage - Attackers can infer contents and/or importance of data based on how it is accessed and frequency of access. Attacker learns the set of matching records. * Volume leakage - Attacker learns the number of records/responses. * Search pattern leakage - Attackers can infer the contents and/or importance of data based on search patterns\u2013attacker can easily judge whether any two queries are generated from the same keywords or not. * Rank leakage - Attacker can infer or learn which data was queried * Side channel leakage - Attackers can access or learn the value of the secret material used to protect data confidentiality and integrity through side channels like memory inspection, RAM scraping attacks with swap access, and timing attacks [8]. * Microarchitectural attacks - Attacker is able to learn secrets through covert channels that target processors (Spectre/Meltdown)</p> <p>Adversary * Network adversary - observes traffic on the network. In addition to snooping and lurking, they can also perform fingerprinting attacks to learn who are the endpoints and correlate them to identical entities. * Snapshot adversary - breaks into server, snapshots system memory or storage. Sees copy of encrypted data but does not see transcripts related to any queries. Trade off between functionality and security. * Persistent adversary - corrupts server for a period of time, sees all communication transcripts. * Honest but curious adversary - System Administrator that can watch accesses to the data</p> <p>Disk Encryption This feature can help with encryption-at-rest requirements but only protects the data if the disk is off. Once booted, then an attacker can read it as easily as a system administrator and thus provides very little protection. Data can and usually is stolen via other methods like software vulnerabilities or virus\u2019. Useful if the storage hardware is not virtualized like in the cloud and is mobile like a laptop, phone, USB drives. If storage is in the cloud or network, it's worth more to invest in host-based intrusion prevention, intrusion detection systems, cloud, and file encryption  (see Sastry, Yegulalp, and Why Full Disk Encryption Isn't Enough).</p> <p>Application vs Database Encryption Databases provide varying levels of built-in encryption methods. SQL Server and SQLCipher are examples of databases that provide Transparent Data Encryption\u2013the users don\u2019t even know the data is encrypted, it\u2019s transparent to their knowledge. This works similar to Disk Encryption in that it mostly protects the database data at rest, but as soon as the user is connected, the data can be read in plaintext. A further abstraction is Postgres and SQL Server allowing database keys to be partially managed by the database to encrypt columns or cells and the user must supply either all or some of the keys and manage them separately. The last approach is for applications to manage all encryption. This has the advantage of being storage agnostic. Postgres permits the keys to be stored separately from the encrypted columns. When the data are queried, the key is passed to the query engine and the data are decrypted temporarily in memory to check the query.</p> <p>If the application is handling encryption, this means the query engine only operates on encrypted data vs allowing it decrypt and read the data directly. The tradeoff is a different query method/language will have to be used than provided by the persistence layer.</p> <p>Many databases are networked which requires another layer of protection like TLS or SSH.</p>"},{"location":"concepts/0440-kms-architectures/#data-storage","title":"Data storage","text":"<p>Metadata for data includes access controls and constraints. Controls dictate what can be done with the data, Constraints dictate who can access it. These could be managed by the underlying persistence application or it can be enforced by LOX before returning the data to the client. The constraints and controls indicate permissions to end clients and not necessarily to anything outside of the persistence layer. This is not like designing an enclave. Persistence is meant to be for more general purpose data that may or may not be sensitive. Metadata about the data includes attributes, constraints, and controls in a similar manner to the enclave.</p>"},{"location":"concepts/0440-kms-architectures/#access-constraints_1","title":"Access constraints","text":"<p>Constraints restrict data access to be done under certain conditions like who is accessing like the owner(s) or group(s). Constraints must be honored by the persistence layer or LOX to consumers to have confidence and trust. Possible constraints are:</p> <ol> <li>Identity or roles</li> <li>Context - i.e. what contexts can this data be used. For example, a credential may be restricted to be used only in a work environment if desired.</li> </ol>"},{"location":"concepts/0440-kms-architectures/#access-controls_1","title":"Access controls","text":"<ol> <li>Crypto Protection - e.g. which key id(s) and algorithm are used to protect this data. This allows data to re-encrypted, transformed via functional encryption in the future when keys are rotated or ciphers are deemed weak or insecure.</li> <li>Is Exportable - e.g. can the data leave the KMS</li> <li>Is Modifiable</li> <li>Can Delete</li> <li>Valid Until Date</li> </ol>"},{"location":"concepts/0440-kms-architectures/#reference","title":"Reference","text":"<p>Indy Wallet implements this in part and is one of the first attempts at this architecture. Indy Wallet doesn't use LOX yet, functions similar to an enclave in that it does not give direct access to private keys and uses key ids to execute operations. It supports a flexible persistence layer to be either SQLite or Postgres. The top layer encrypts data before it is queried or sent to the persistence layer and decrypted when returned. Aries Mayaguez is another implementation</p>"},{"location":"concepts/0440-kms-architectures/#drawbacks","title":"Drawbacks","text":"<p>There are additional complexities related to handling keys and other data as two distinct entities and it might be faster to combine them with a potential security tradeoff.</p>"},{"location":"concepts/0440-kms-architectures/#prior-art","title":"Prior art","text":"<p>PKCS#11 and  KMIP were developed for key management strictly for enclaves. These design patterns are not limited to just key management but any sensitive data.</p>"},{"location":"concepts/0440-kms-architectures/#unresolved-questions","title":"Unresolved questions","text":"<p>Is providing access constraints to the persistence layer necessary? Could this be removed? What are the consequences? Are there any missing constraints and controls for the enclave or persistence layer?</p>"},{"location":"concepts/0440-kms-architectures/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes</p> Name / Link Implementation Notes"},{"location":"concepts/0441-present-proof-best-practices/","title":"0441: Prover and Verifier Best Practices for Proof Presentation","text":"<ul> <li>Authors: Stephen Klump</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Interoperability guidance when using AnonCreds Present Proof. An element of the AnonCreds subtarget for AIP v2.0.</li> <li>Start Date: 2020-10-31</li> <li>Tags: concept, credentials</li> </ul>"},{"location":"concepts/0441-present-proof-best-practices/#summary","title":"Summary","text":"<p>This work prescribes best practices for provers in credential selection (toward proof presentation), for verifiers in proof acceptance, and for both regarding non-revocation interval semantics in fulfilment of the Present Proof protocol RFC0037. Of particular instance is behaviour against presentation requests and presentations in their various non-revocation interval profiles.</p>"},{"location":"concepts/0441-present-proof-best-practices/#motivation","title":"Motivation","text":"<p>Agents should behave consistently in automatically selecting credentials and proving presentations.</p>"},{"location":"concepts/0441-present-proof-best-practices/#tutorial","title":"Tutorial","text":"<p>The subsections below introduce constructs and outline best practices for provers and verifiers.</p>"},{"location":"concepts/0441-present-proof-best-practices/#presentation-requests-and-non-revocation-intervals","title":"Presentation Requests and Non-Revocation Intervals","text":"<p>This section prescribes norms and best practices in formulating and interpreting non-revocation intervals on proof requests.</p>"},{"location":"concepts/0441-present-proof-best-practices/#semantics-of-non-revocation-interval-presence-and-absence","title":"Semantics of Non-Revocation Interval Presence and Absence","text":"<p>The presence of a non-revocation interval applicable to a requested item (see below) in a presentation request signifies that the verifier requires proof of non-revocation status of the credential providing that item.</p> <p>The absence of any non-revocation interval applicable to a requested item signifies that the verifier has no interest in its credential's non-revocation status.</p> <p>A revocable or non-revocable credential may satisfy a presentation request with or without a non-revocation interval. The presence of a non-revocation interval conveys that if the prover presents a revocable credential, the presentation must include proof of non-revocation. Its presence does not convey any restriction on the revocability of the credential to present: in many cases the verifier cannot know whether a prover's credential is revocable or not.</p>"},{"location":"concepts/0441-present-proof-best-practices/#non-revocation-interval-applicability-to-requested-items","title":"Non-Revocation Interval Applicability to Requested Items","text":"<p>A requested item in a presentation request is an attribute or a predicate, proof of which the verifier requests presentation. A non-revocation interval within a presentation request is specifically applicable, generally applicable, or inapplicable to a requested item.</p> <p>Within a presentation request, a top-level non-revocation interval is generally  applicable to all requested items. A non-revocation interval defined particularly for  a requested item is specifically applicable to that requested attribute or predicate but inapplicable to all others.</p> <p>A non-revocation interval specifically applicable to a requested item overrides any generally applicable non-revocation interval: no requested item may have both.</p> <p>For example, in the following (indy) proof request</p> <pre><code>{\n    \"name\": \"proof-request\",\n    \"version\": \"1.0\",\n    \"nonce\": \"1234567890\",\n    \"requested_attributes\": {\n        \"legalname\": {\n            \"name\": \"legalName\",\n            \"restrictions\": [\n                {\n                    \"issuer_did\": \"WgWxqztrNooG92RXvxSTWv\"\n                }\n            ]\n        },\n        \"regdate\": {\n            \"name\": \"regDate\",\n            \"restrictions\": [\n                {\n                    \"issuer_did\": \"WgWxqztrNooG92RXvxSTWv\"\n                }\n            ],\n            \"non_revoked\": {\n                \"from\": 1600001000,\n                \"to\": 1600001000\n            }\n        }\n    },\n    \"requested_predicates\": {\n    },\n    \"non_revoked\": {\n        \"from\": 1600000000,\n        \"to\": 1600000000\n    }\n}\n</code></pre> <p>the non-revocation interval on 1600000000 is generally applicable to the referent <code>\"legalname\"</code> while the non-revocation interval on 1600001000 specifically applicable to referent <code>\"regdate\"</code>.</p>"},{"location":"concepts/0441-present-proof-best-practices/#semantics-of-non-revocation-interval-endpoints","title":"Semantics of Non-Revocation Interval Endpoints","text":"<p>A non-revocation interval contains <code>\"from\"</code> and <code>\"to\"</code> (integer) EPOCH times. For historical reasons, any timestamp within this interval is technically acceptable in a non-revocation subproof. However, these semantics allow for ambiguity in cases where revocation occurs within the interval, and in cases where the ledger supports reinstatement. These best practices require the <code>\"from\"</code> value, should the prover specify it, to equal the <code>\"to\"</code> value: this approach fosters deterministic outcomes.</p> <p>A missing <code>\"from\"</code> specification defaults to the same value as the interval's <code>\"to\"</code> value. In other words, the non-revocation intervals</p> <pre><code>{\n    \"to\": 1234567890\n}\n</code></pre> <p>and</p> <pre><code>{\n    \"from\": 1234567890,\n    \"to\": 1234567890\n}\n</code></pre> <p>are semantically equivalent.</p>"},{"location":"concepts/0441-present-proof-best-practices/#verifier-non-revocation-interval-formulation","title":"Verifier Non-Revocation Interval Formulation","text":"<p>The verifier MUST specify, as current INDY-HIPE 11 notes, the same integer EPOCH time for both ends of the interval, or else omit the <code>\"from\"</code> key and value. In effect, where the presentation request specifies a non-revocation interval, the verifier MUST request a non-revocation instant.</p>"},{"location":"concepts/0441-present-proof-best-practices/#prover-non-revocation-interval-processing","title":"Prover Non-Revocation Interval Processing","text":"<p>In querying the nodes for revocation status, given a revocation interval on a single instant (i.e., on <code>\"from\"</code> and <code>\"to\"</code> the same, or <code>\"from\"</code> absent), the prover MUST query the ledger for all germane revocation updates from registry creation through that instant (i.e., from zero through <code>\"to\"</code> value): if the credential has been revoked prior to the instant, the revocation necessarily will appear in the aggregate delta.</p>"},{"location":"concepts/0441-present-proof-best-practices/#provers-presentation-proposals-and-presentation-requests","title":"Provers, Presentation Proposals, and Presentation Requests","text":"<p>In fulfilment of the RFC0037 Present Proof protocol, provers may initiate with a presentation proposal or verifiers may initiate with a presentation request. In the former case, the prover has both a presentation proposal and a presentation request; in the latter case, the prover has only a presentation request.</p>"},{"location":"concepts/0441-present-proof-best-practices/#credential-selection-best-practices","title":"Credential Selection Best Practices","text":"<p>This section specifies a prover's best practices in matching a credential to a requested item. The specification pertains to automated credential selection: obviously, a human user may select any credential in response to a presentation request; it is up to the verifier to verify the resulting presentation as satisfactory or not.</p> <p>Note that where a prover selects a revocable credential for inclusion in response to a requested item with a non-revocation interval in the presentation request, the prover MUST create a corresponding sub-proof of non-revocation at a timestamp within that non-revocation interval (insofar as possible; see below).</p>"},{"location":"concepts/0441-present-proof-best-practices/#with-presentation-proposal","title":"With Presentation Proposal","text":"<p>If prover initiated the protocol with a presentation proposal specifying a value (or predicate threshold) for an attribute, and the presentation request does not require a different value for it, then the prover MUST select a credential matching the presentation proposal, in addition to following the best practices below regarding the presentation request.</p>"},{"location":"concepts/0441-present-proof-best-practices/#preference-for-irrevocable-credentials","title":"Preference for Irrevocable Credentials","text":"<p>In keeping with the specification above, presentation of an irrevocable credential ipso facto constitutes proof of non-revocation. Provers MUST always prefer irrevocable credentials to revocable credentials, when the wallet has both satisfying a requested item, whether the requested item has an applicable non-revocation interval or not. Note that if a non-revocation interval is applicable to a credential's requested item in the presentation request, selecting an irrevocable credential for presentation may lead to a missing timestamp at the verifier (see below).</p> <p>If only revocable credentials are available to satisfy a requested item with no applicable non-revocation interval, the prover MUST present such for proof. As per above, the absence of a non-revocation interval signifies that the verifier has no interest in its revocation status.</p>"},{"location":"concepts/0441-present-proof-best-practices/#verifiers-presentations-and-timestamps","title":"Verifiers, Presentations, and Timestamps","text":"<p>This section prescribes verifier best practices concerning a received presentation by its timestamps against the corresponding presentation request's non-revocation intervals.</p>"},{"location":"concepts/0441-present-proof-best-practices/#timestamp-for-irrevocable-credential","title":"Timestamp for Irrevocable Credential","text":"<p>A presentation's inclusion of a timestamp pertaining to an irrevocable credential evinces tampering: the verifier MUST reject such a presentation.</p>"},{"location":"concepts/0441-present-proof-best-practices/#missing-timestamp","title":"Missing Timestamp","text":"<p>A presentation with no timestamp for a revocable credential purporting to satisfy a requested item in the corresponding presentation request, where the requested item has an applicable non-revocation interval, evinces tampering: the verifier MUST reject such a presentation.</p> <p>It is licit for a presentation to have no timestamp for an irrevocable credential: the applicable non-revocation interval is superfluous in the presentation request.</p>"},{"location":"concepts/0441-present-proof-best-practices/#timestamp-outside-non-revocation-interval","title":"Timestamp Outside Non-Revocation Interval","text":"<p>A presentation may include a timestamp outside of a the non-revocation interval applicable to the requested item that a presented credential purports to satisfy. If the latest timestamp from the ledger for a presented credential's revocation registry predates the non-revocation interval, but the timestamp is not in the future (relative to the instant of presentation proof, with a reasonable allowance for clock skew), the verifier MUST log and continue the proof verification process.</p> <p>Any timestamp in the future (relative to the instant of presentation proof, with a reasonable allowance for clock skew) evinces tampering: the verifier MUST reject a presentation with a future timestamp. Similarly, any timestamp predating the creation of its corresponding credential's revocation registry on the ledger evinces tampering: the verifier MUST reject a presentation with such a timestamp.</p>"},{"location":"concepts/0441-present-proof-best-practices/#dates-and-predicates","title":"Dates and Predicates","text":"<p>This section prescribes issuer and verifier best practices concerning representing dates for use in predicate proofs (eg proving Alice is over 21 without revealing her birth date).</p>"},{"location":"concepts/0441-present-proof-best-practices/#dates-in-credentials","title":"Dates in Credentials","text":"<p>In order for dates to be used in a predicate proof they MUST be expressed as an Int32. While unix timestamps could work for this, it has several drawbacks including: can't represent dates outside of the years 1901-2038, isn't human readable, and is overly precise in that birth time down to the second is generally not needed for an age check. To address these issues, date attributes SHOULD be represented as integers in the form YYYYMMDD (eg 19991231). This addresses the issues with unix timestamps (or any seconds-since-epoch system) while still allowing date values to be compared with &lt; &gt; operators. Note that this system won't work for any general date math (eg adding or subtracting days), but it will work for predicate proofs which just require comparisons. In order to make it clear that this format is being used, the attribute name SHOULD have the suffix <code>_dateint</code>. Since most datetime libraries don't include this format, here are some examples of helper functions written in typescript.</p>"},{"location":"concepts/0441-present-proof-best-practices/#dates-in-presentations","title":"Dates in Presentations","text":"<p>When constructing a proof request, the verifier SHOULD express the minimum/maximum date as an integer in the form YYYYMMDD. For example if today is Jan 1, 2021 then the verifier would request that <code>bithdate_dateint</code> is before or equal to Jan 1 2000 so <code>&lt;= 20000101</code>. The holder MUST construct a predicate proof with a YYYYMMDD represented birth date less than that value to satisfy the proof request.</p>"},{"location":"concepts/0441-present-proof-best-practices/#reference","title":"Reference","text":"<ul> <li>RFC 0037: Present Proof protocol</li> <li>INDY-HIPE 11: Indy revocation.</li> </ul>"},{"location":"concepts/0441-present-proof-best-practices/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0478-coprotocols/","title":"Aries RFC 0478: Coprotocols","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No recent progress and no implementations have been created.</li> <li>Start Date: 2020-02-03</li> <li>Tags: concept, protocol</li> </ul>"},{"location":"concepts/0478-coprotocols/#summary","title":"Summary","text":"<p>Explains how one protocol can invoke and interact with others, giving inputs and receiving outputs and errors.</p>"},{"location":"concepts/0478-coprotocols/#motivation","title":"Motivation","text":"<p>It's common for complex business workflows to be composed from smaller, configurable units of logic. It's also common for multiple processes to unfold in interrelated ways, such that a complex goal is choreagraphed from semi-independent tasks. Enabling flexible constructions like this is one of the major goals of protocols built atop DIDComm. We need a standard methodology for doing so.</p>"},{"location":"concepts/0478-coprotocols/#tutorial","title":"Tutorial","text":"<p>A protocol is any recipe for a stateful interaction. DIDComm itself is a protocol, as are many primitives atop which it is built, such as HTTP, Diffie-Hellman key exchange, and so forth. However, when we talk about protocols in decentralized identity, without any qualifiers, we usually mean application-level interactions like credential issuance, feature discovery, third-party introductions, and so forth. These protocols are message-based interactions that use DIDComm.</p> <p>We want these protocols to be composable. In the middle of issuing credentials, we may want to challenge the potential holder for proof -- and in the middle of challenging for proof, maybe we want to negotiate payment. We could build proving into issuing, and payment into proving, but this runs counter to the DRY principle and to general best practice in encapsulation. A good developer writing a script to issue credentials would probably isolate payment and proving logic in separate functions or libraries, and would strive for loose coupling so each could evolve independently.</p> <p>Agents that run protocols have goals like those of the script developer. How we achieve them is the subject of this RFC.</p>"},{"location":"concepts/0478-coprotocols/#subroutines","title":"Subroutines","text":"<p>In the world of computer science, a subroutine is a vital abstraction for complex flows. It breaks logic into small, reusable chunks that are easy for a human to understand and document, and it formalizes their interfaces. Code calls a subroutine by referencing it via name or address, providing specified arguments as input. The subroutine computes on this input, eventually producing an output; the details don't interest the caller. While the subroutine is busy, the caller typically waits. Callers can often avoid recompilation when details inside subroutines change. Subroutines can come from pluggable libraries. These can be written by different programmers in different programming languages, as long as a calling convention is shared.</p> <p>Thinking of protocols as analogs to subroutines suggests some interesting questions:  </p> <ul> <li>How do we invoke one protocol from another?</li> <li>How does a protocol emit an output?</li> <li>What is the calling convention?</li> <li>How do errors propagate (or exceptions get thrown and handled)?</li> <li>How can we make protocols work like higher-order functions (functions that take other functions as parameters)?</li> </ul>"},{"location":"concepts/0478-coprotocols/#coroutines","title":"Coroutines","text":"<p>Before we answer these questions, let's think about a generalization of subroutines that's slightly less familiar to some programmers: coroutines. Coroutines achieve the same encapsulation and reusability as subroutines, but as a category they are more flexible and powerful. Coroutines may be, but aren't required to be, call-stack \"children\" of their callers; they may have complex lifecycles that begin or end outside the caller's lifespan. Coroutines may receive inputs at multiple points, not just at launch. They may yield outputs at multiple points, too. Subroutines are just the simplest variant of coroutines.</p> <p>The flexiblity of coroutines gives options to programmers, and it explains why most programming languages evolve to offer them as first-class constructs when they encounter demanding requirements for asynchronicity, performance, or scale. For example, early versions of python lacked the concept of coroutines; if you wrote a loop over <code>range(1, 1000000)</code>, python allocated and filled a container holding 1 million numbers, and then iterated over the container. When generators (a type of coroutine) were added to the language, the underlying logic changed. Now <code>range(1, 1000000)</code> is a coroutine invocation that trades execution state back and forth with its sibling caller routine. The first time it is invoked, it receives and stores its input values, then produces one output (the lower bound of the range). Each subsequent time through the loop it is invoked again; it increments its internal state and yields a new output back to the caller. No allocations occur, and an early break from the loop wastes nothing.</p> <p>If we want to choose one conceptual parallel for how protocols relate to one another, we should think of them as coroutines, not subroutines; doing so constrains us less. Although payment as a subroutine inside credential issuance sounds plausible at first glance, it turns out to be clumsy under deeper analysis. A payment protocol yields more than one output -- typically a preauthorization at an intermediate stage, then a final outcome when it completes. At the preauthorization stage, it should accept graceful cancellation (a second input, after launch). And high-speed, bulk issuance of credentials is likely to benefit from payment and issuance being partly parallelized instead of purely sequential.</p> <p></p> <p>Similarly, a handshake protocol like DID Exchange or Connection is best framed as a coprotocol of Introduce; this makes it easy for Introduce to complete as soon as the handshake begins, instead of waiting for the handshake to finish as if it were a subroutine.</p> <p>By thinking of cross-protocol interactions like coroutine interactions, we get the best of both worlds: where the interaction is just subroutine-like, the model lets us simplify; where we need more flexibility and power, the model still fits.</p> <p>Protocols don't have to support the types of coprotocol interactions we're describing here; protocols developed by Aries developers have already proven their value even without it. But to unlock their full potential, adding coprotocol support to new and existing protocol definitions may be worthwhile. This requires only a modest update to a protocol RFC, and creates little extra work for implementers.</p>"},{"location":"concepts/0478-coprotocols/#the-simple-approach-that-falls-apart","title":"The simple approach that falls apart","text":"<p>When the DIDComm community first began thinking about one protocol invoking another, we imagined that the interface to the called coprotocol would simply be its first message. For example, if verfiable credential issuer Acme Corp wanted to demand payment for a credential during an issuance protocol with Bob, Acme would send to Bob a <code>request_payment</code> message that constituted the first message in a <code>make_payment</code> protocol. This would create an instance of the payment protocol running alongside issuance; issuance could then wait until it completed before proceeding. And Bob wouldn't need to lift a finger to make it work, if he already supported the payment protocol.</p> <p>Unfortunately, this approach looks less attractive after study: </p> <ul> <li> <p>It creates a tight coupling between issuance and payment. The logic inside issuance must know exactly what data format, semantics, and versioning rules apply to the payment protocol, in order to generate its first message. If the payment protocol changes, the issuance protocol breaks. There is no flexibility in issuance to negotiate an optimal payment protocol from among several alternatives that both parties support. The implementation of issuance is too opinionated about how to approach a logically independent task.</p> </li> <li> <p>It doesn't give Bob any context. We don't want to inconvenience Bob to support payment in conjunction with issuance, but we DO want Bob to know that the payment protocol instance he participates in is related to the credential issuance protocol that's also underway. This is more than just connecting the two with DIDComm's message threading; if one protocol is abandoned or completes or fails, something probably needs to happen in the other.</p> </li> <li> <p>It doesn't let Bob be the first mover. What if Bob should be requesting payment instead of Acme? (The Protocol Role Request Protocol partly addresses this need, but lacks a formal way to give Bob data as input.)  </p> </li> <li> <p>It doesn't explain how the payment protocol emits output that its caller can consume. Individual agents could code proprietary answers to this question, but interoperability would be lost.</p> </li> <li> <p>It doesn't offer a signalling mechanism that would let the two protocols proceed in parallel, syncing up only when necessary.</p> </li> <li> <p>It doesn't explain how errors propagate, or how to decide what they mean for the calling protocol.</p> </li> </ul>"},{"location":"concepts/0478-coprotocols/#general-interface-needs","title":"General Interface Needs","text":"<p>What we want, instead, is a formal declaration of something a bit like a coprotocol's \"function signature.\" It needs to describe the inputs that launch the protocol, and the outputs and/or errors emitted as it finishes. It should hide implementation details and remain stable across irrelevant internal changes. </p> <p>We need to bind compatible coprotocols to one another using the metadata in these declarations. And since coprotocol discovery may have to satisfy a remote party, not just a local one, our binding needs to work well dynamically, and late, and with optional, possibly overlapping plugins providing implementations. This suggests that our declarations must be rich and flexible about binding criteria \u2014 it must be possible to match on something more than just a coprotocol name and/or arg count+type.</p> <p>An interesting divergence from the function signature parallel is that we may have to describe inputs and outputs (and errors) at multiple interaction points, not just the coprotocol's initial invocation. </p> <p>Another subtlety is that protocol interfaces need to be partitioned by role; the experience of a payer and a payee with respect to a payment protocol may be quite different. The interface offered by a coprotocol must vary by which role the invoked coprotocol instance embodies.</p> <p>Given all these considerations, we choose to describe coprotocol interfaces using a set of function-like signatures, not just one. We use a function-like notation to make them as terse and intuitive as possible for developers.</p>"},{"location":"concepts/0478-coprotocols/#example","title":"Example","text":"<p>Suppose we are writing a credential issuance protocol, and we want to use coprotocols to add support for situations where the issuer expects payment partway through the overall flow. We'd like it to be possible for our payment step to use Venmo/Zelle, or cryptocurrency, or traditional credit cards, or anything else that issuers and holders agree upon. So we want to encapsulate the payment problem as a pluggable, discoverable, negotiable coprotocol.</p> <p>We do a little research and discover that many DIDComm-based payment protocols exist. Three of them advertise support for the same coprotocol interface:</p> <pre><code>goal: aries.buy.make-payment\npayee:\n  get:\n      - invoke(amount: float, currency: str, bill_of_sale: str) @ null\n      - proceed(continue: bool) @ requested:, waiting-for-commit\n  give:\n      - preauth(code: str) @ waiting-for-commit\n      - return(confirmation_code: str) @ finalizing\n</code></pre> <p>In plain English, the declared coprotocol semantics are:</p> <p>This is a coprotocol interface for protocols that facilitate the <code>aries.buy.make-payment</code> goal code. The <code>payee</code> role in this coprotocol gets input at two interaction points, \"invoke\" and \"proceed\". Invoke happens when state is null (at launch); \"proceed\" happens when state is \"requested\" or \"waiting-for-commit.\" At invoke, the caller of the co-protocol provides 3 inputs: an amount, a currency, and a bill of sale. At proceed, the caller decides whether to continue. Implementations of this coprotocol interface also give output at two interaction points, \"preauth\" and \"return.\" At preauth, the output is a string that's a preauth code; at return, the output is a confirmation code.</p>"},{"location":"concepts/0478-coprotocols/#simplified-description-only","title":"Simplified description only","text":"<p>It's important to understand that this interface is NOT the same as the protocol's direct interface (the message family and state machine that a protocol impl must provide to implement the protocol as documented). It is, instead, a simplified encapuslation -- just like a function signature is a simplified encapsulation of a coroutine. A function impl can rename its args for internal use. It can have steps that the caller doesn't know about. The same is true for protocols: their role names, state names, message types and versions, and field names in messages don't need to be exposed directly in a coprotocol interface; they just need a mapping that the protocol understands internally. The specific payment protocol implementation might look like this (don't worry about details; the point is just that some might exist):</p> <p></p> <p>When we describe this as a coprotocol, we omit most of its details, and we change some verbiage. The existence of the <code>payee</code>, <code>gateway</code> and <code>blockchain</code> roles is suppressed (though we now have an implicit new role -- the caller of the coprotocol that gives what the protocol gets, and gets what the protocol gives). Smart contracts disappear. The concept of <code>handle to pending txn</code> is mapped to the coprotocol's <code>preauth</code> construct, and <code>txn hash</code> is mapped to the coprotocol's <code>confirmation_code</code>. As a coprotocol, the payee can interact according to a far simpler understanding, where the caller asks the payee to engage in a payment protocol, expose some simple hooks, and notify on completion:</p> <p></p>"},{"location":"concepts/0478-coprotocols/#calling-convention","title":"Calling Convention","text":"<p>More details are needed to understand exactly how the caller and the coprotocol communicate. There are two sources of such details:</p> <ol> <li>Proprietary methods</li> <li>Standard Aries-style DIDComm protocol</li> </ol> <p>Proprietary methods allow aggressive optimization. They may be appropriate when it's known that the caller and the coprotocol will share the same process space on a single device, and the code for both will come from a single codebase. In such cases, there is no need to use DIDComm to communicate.</p> <p>Answer 2 may be more chatty, but is better when the coprotocol might be invoked remotely (e.g., Acme's server A is in the middle of issuance and wants to invoke payment to run on server B), or where the codebases for each party to the interaction need some independence.</p> <p>The expectation is that co-protocols share a compatible trust domain; that is, coprotocol interactions occur within the scope of one identity rather than across identity boundaries. Thus, interoperability is not a strong requirement. Nonetheless, approaching this question as a standard protocol problem leads to a clean, loosely couple architecture with little incremental cost in an agent. Therefore, a protocol for coprotocol coordination has been developed. This is the subject of sister document Aries RFC 0482: Coprotocol Protocol.</p>"},{"location":"concepts/0478-coprotocols/#reference","title":"Reference","text":"<p>More about optional fields and syntax in a coprotocol declaration.</p> <p>How to add a coprotocol decl to a protocol.</p>"},{"location":"concepts/0478-coprotocols/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"concepts/0478-coprotocols/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"concepts/0478-coprotocols/#prior-art","title":"Prior art","text":"<p>Coroutines \u2014 the computer science scaffolding against which coprotocols are modeled \u2014 are extensively discussed in the literature of various compiler developer communities. The discussion about adding support for this feature in Rust is particularly good background reading: https://users.rust-lang.org/t/coroutines-and-rust/9058</p>"},{"location":"concepts/0478-coprotocols/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"concepts/0478-coprotocols/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0519-goal-codes/","title":"0519: Goal Codes","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Used in several protocols that are part of AIP 2.0, such as the Out-of-Band protocol.</li> <li>Start Date: 2020-01-01</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0519-goal-codes/#summary","title":"Summary","text":"<p>Explain how different parties in an SSI ecosystem can communicate about their intentions in a way that is understandable by humans and by automated software.</p>"},{"location":"concepts/0519-goal-codes/#motivation","title":"Motivation","text":"<p>Agents exist to achieve the intents of their owners. Those intents largely unfold through protocols. Sometimes intelligent action in these protocols depends on a party declaring their intent. We need a standard way to do that.</p>"},{"location":"concepts/0519-goal-codes/#tutorial","title":"Tutorial","text":"<p>Our early learnings in SSI focused on VC-based proving with a very loose, casual approach to context. We did demos where Alice connects with a potential employer, Acme Corp -- and we assumed that each of the interacting parties had a shared understanding of one another's needs and purposes.</p> <p>But in a mature SSI ecosystem, where unknown agents can contact one another for arbitrary reasons, this context is not always easy to deduce. Acme Corp's agent may support many different protocols, and Alice may interact with Acme in the capacity of customer or potential employee or vendor. Although we have feature discovery to learn what's possible, and we have machine-readable governance frameworks to tell us what rules might apply in a given context, we haven't had a way to establish the context in the first place. When Alice contacts Acme, a context is needed before a governance framework is selectable, and before we know which ../../features are desirable.</p> <p>The key ingredient in context is intent. If Alice says to Acme, \"I'd like to connect,\", Acme wants to be able to trigger different behavior depending on whether Alice's intent is to be a customer, apply for a job, or audit Acme's taxes. This is the purpose of a goal code.</p>"},{"location":"concepts/0519-goal-codes/#the-goal-code-datatype","title":"The goal code datatype","text":"<p>To express intent, this RFC formally introduces the goal code datatype. When a field in a DIDComm message contains a goal code, its semantics and format match the description given here. (Goal codes are often declared via the <code>~thread</code> decorator, but may also appear in ordinary message fields. See the Scope section below. Convention is to name this field \"goal_code\" where possible; however, this is only a convention, and individual protocols may adapt to it however they wish.)</p> <p>TODO: should we make a decorator out of this, so protocols don't have to declare it, and so any message can have a goal code? Or should we just let protocols declare a field in whatever message makes sense?</p> <p>Protocols use fields of this type as a way to express the intent of the message sender, thus coloring the larger context. In a sense, goal codes are to DIDComm what the <code>subject:</code> field is to email -- except that goal codes have formalized meanings to make them recognizable to automation.</p> <p>Goal codes use a standard format. They are lower-cased, kebab-punctuated strings. ASCII and English are recommended, as they are intended to be read by the software developer community, not by human beings; however, full UTF-8 is allowed. They support hierarchical dotted notation, where more general categories are to the left of a dot, and more specific categories are to the right. Some example goal codes might be:</p> <ul> <li><code>aries.sell.consumer.fitness</code></li> <li><code>meetupcorp.personal.date</code></li> <li><code>dif.employment.check-references</code></li> <li><code>cci.healthcare.arrange</code></li> </ul> <p>Goals are inherently self-attested. Thus, goal codes don't represent objective fact that a recipient can rely upon in a strong sense; subsequent interactions can always yield surprises. Even so, goal codes let agents triage interactions and find misalignments early; there's no point in engaging if their goals are incompatible. This has significant benefits for spam prevention, among other things.</p>"},{"location":"concepts/0519-goal-codes/#verbs","title":"Verbs","text":"<p>Notice the verbs in the examples: <code>sell</code>, <code>date</code>, <code>hire</code>, and <code>arrange</code>. Goals typically involve action; a complete goal code should have one or more verbs in it somewhere. Turning verbs into nouns (e.g., <code>employment.references</code> instead of <code>employment.check-references</code>) is considered bad form. (Some namespaces may put the verbs at the end; some may put them in the middle. That's a purely stylistic choice.)</p>"},{"location":"concepts/0519-goal-codes/#directionality","title":"Directionality","text":"<p>Notice, too, that the verbs may imply directionality. A goal with the <code>sell</code> verb implies that the person announcing the goal is a would-be seller, not a buyer. We could imagine a more general verb like <code>engage-in-commerce</code> that would allow either behavior. However, that would often be a mistake. The value of goal codes is that they let agents align around intent; announcing that you want to engage in general commerce without clarifying whether you intend to sell or buy may be too vague to help the other party make decisions. </p> <p>It is conceivable that this would lead to parallel branchs of a goal ontology that differ only in the direction of their verb. Thus, we could imagine <code>sell.A</code> and <code>sell.B</code> being shadowed by <code>buy.A</code> and <code>buy.B</code>. This might be necessary if a family of protocols allow either party to initiate an interaction and declare the goal, and if both parties view the goals as perfect mirror images. However, practical considerations may make this kind of parallelism unlikely. A random party contacting an individual to sell something may need to be quite clear about the type of selling they intend, to make it past a spam filter. In contrast, a random individual arriving at the digital storefront of a mega retailer may be quite vague about the type of buying they intend. Thus, the <code>buy.*</code> side of the namespace may need much less detail than the <code>sell.*</code> side.</p>"},{"location":"concepts/0519-goal-codes/#goals-for-others","title":"Goals for others","text":"<p>Related to directionality, it may occasionally be desirable to propose goals to others, rather than adovcating your own: \"Let &lt;parties = us = Alice, Bob, and Carol&gt; &lt;goal = hold an auction&gt; -- I nominate Carol to be the &lt;role = auctioneer&gt; and get us started.\" The difference between a normal message and an unusual one like this is not visible in the goal code; it should be exposed in additional fields that associate the goal with a particular identifier+role pair. Essentially, you are proposing a goal to another party, and these extra fields clarify who should receive the proposal, and what role/perspective they might take with respect to the goal.</p> <p>Making proposals like this may be a feature in some protocols. Where it is, the protocols determine the message field names for the goal code, the role, and the DID associated with the role and goal.</p>"},{"location":"concepts/0519-goal-codes/#matching","title":"Matching","text":"<p>The goal code <code>cci.healthcare</code> is considered a more general form of the code <code>cci.healthcare.procedure</code>, which is more general than <code>cci.healthcare.procedure.schedule</code>. Because these codes are hierarchical, wildcards and fuzzy matching are possible for either a sender or a recipient of a message. Filename-style globbing semantics are used.</p> <p>A sender agent can specify that their owner's goal is just <code>meetupcorp.personal</code> without clarifying more; this is like specifying that a file is located under a folder named \"meetupcorp/personal\" without specifying where; any file \"under\" that folder -- or the folder itself -- would match the pattern. A recipient agent can have a policy that says, \"Reject any attempts to connect if the goal code of the other party is <code>aries.sell.*</code>. Notice how this differs from <code>aries.sell*</code>; the first looks for things \"inside\" <code>aries.sell</code>; the latter looks for things \"inside\" <code>aries</code> that have names beginning with <code>sell</code>.</p>"},{"location":"concepts/0519-goal-codes/#scope","title":"Scope","text":"<p>When is a declared goal known to color interactions, and when is it undefined? </p> <p>We previously noted that goal codes are a bit like the <code>subject:</code> header on an email; they contextualize everything that follows in that thread. We don't generally want to declare a goal outside of a thread context, because that would prevent an agent from engaging in two goals at the same time.</p> <p>Given these two observations, we can say that a goal applies as soon as it is declared, and it continues to apply to all messages in the same thread. It is also inherited by implication through a thread's <code>pthid</code> field; that is, a parent thread's goal colors the child thread unless/until overridden.</p>"},{"location":"concepts/0519-goal-codes/#namespacing","title":"Namespacing","text":"<p>To avoid collision and ambiguity in code values, we need to support namespacing in our goal codes. Since goals are only a coarse-grained alignment mechanism, however, we don't need perfect decentralized precision. Confusion isn't much more than an annoyance; the worst that could happen is that two agents discover one or two steps into a protocol that they're not as aligned as they supposed. They need to be prepared to tolerate that outcome in any case.</p> <p>Thus, we follow the same general approach that's used in java's packaging system, where organizations and communities use a self-declared prefix for their ecosystem as the leftmost segment or segments of a family of identifiers (goal codes) they manage. Unlike java, though, these need not be tied to DNS in any way. We recommend a single segment namespace that is a unique string, and that is an alias for a URI identifying the origin ecosystem. (In other words, you don't need to start with \"com.yourcorp.yourproduct\" -- \"yourcorp\" is probably fine.)</p> <p>The <code>aries</code> namespace alias is reserved for goal codes defined in Aries RFCs. The URI aliased by this name is TBD. See the Reference section for more details.</p>"},{"location":"concepts/0519-goal-codes/#versioning","title":"Versioning","text":"<p>Semver-style semantics don't map to goals in an simple way; it is not obvious what constitutes a \"major\" versus a \"minor\" difference in a goal, or a difference that's not worth tracking at all. The content of a goal \u2014 the only thing that might vary across versions \u2014 is simply its free-form description, and that varies according to human judgment. Many different versions of a protocol are likely to share the goal to make a payment or to introduce two strangers. A goal is likely to be far more stable than the details of how it is accomplished.</p> <p>Because of these considerations, goal codes do not impose an explicit versioning mechanism. However, one is reserved for use, in the unusual cases where it may be helpful. It is to append <code>-v</code> plus a numeric suffix: <code>my-goal-code-v1</code>, <code>my-goal-code-v2</code>, etc. Goal codes that vary only by this suffix should be understood as ordered-by-numeric-suffix evolutions of one another, and goal codes that do not intend to express versioning should not use this convention for something else. A variant of the goal code without any version suffix is equivalent to a variant with the <code>-v1</code> suffix. This allows human intuition about the relatedness of different codes, and it allows useful wildcard matching across versions. It also treats all version-like changes to a goal as breaking (semver \"major\") changes, which is probably a safe default.</p> <p>Families of goal codes are free to use this convention if they need it, or to invent a non-conflicting one of their own. However, we repeat our observation that versioning in goal codes is often inappropriate and unnecessary.</p>"},{"location":"concepts/0519-goal-codes/#declaring-goal-codes","title":"Declaring goal codes","text":""},{"location":"concepts/0519-goal-codes/#standalone-rfcs-or-similar-sources","title":"Standalone RFCs or Similar Sources","text":"<p>Any URI-referencable document can declare famlies or ontologies of goal codes. In the context of Aries, we encourage standalone RFCs for this purpose if the goals seem likely to be relevant in many contexts. Other communities may of course document goal codes in their own specs -- either dedicated to goal codes, or as part of larger topics. The following block is a sample of how we recommend that such goal codes be declared. Note that each code is individually hyperlink-able, and each is associated with a brief human-friendly description in one or more languages. This description may be used in menuing mechanisms such as the one described in Action Menu Protocol.</p>"},{"location":"concepts/0519-goal-codes/#goal-codes","title":"goal codes","text":""},{"location":"concepts/0519-goal-codes/#ariessell","title":"<code>aries.sell</code>","text":"<p>en: Sell something. Assumes two parties (buyer/seller). es: Vender algo. Asume que dos partes participan (comprador/vendedor).</p>"},{"location":"concepts/0519-goal-codes/#ariessellgoodsconsumer","title":"<code>aries.sell.goods.consumer</code>","text":"<p>en: Sell tangible goods of interest to general consumers.</p>"},{"location":"concepts/0519-goal-codes/#ariessellservicesconsumer","title":"<code>aries.sell.services.consumer</code>","text":"<p>en: Sell services of interest to general consumers.</p>"},{"location":"concepts/0519-goal-codes/#ariessellservicesenterprise","title":"<code>aries.sell.services.enterprise</code>","text":"<p>en: Sell services of interest to enterprises.</p>"},{"location":"concepts/0519-goal-codes/#in-didcomm-based-protocol-specs","title":"In DIDComm-based Protocol Specs","text":"<p>Occasionally, goal codes may have meaning only within the context of a specific protocol. In such cases, it may be appropriate to declare the goal codes directly in a protocol spec. This can be done using a section of the RFC as described above.</p> <p>More commonly, however, a protocol will accomplish one or more goals (e.g., when the protocol is fulfilling a co-protocol interface), or will require a participant to identify a goal at one or more points in a protocol flow. In such cases, the goal codes are probably declared external to the protocol. If they can be enumerated, they should still be referenced (hyperlinked to their respective definitions) in the protocol RFC.</p>"},{"location":"concepts/0519-goal-codes/#in-governance-frameworks","title":"In Governance Frameworks","text":"<p>Goal codes can also be (re-)declared in a machine-readable governance framework. </p>"},{"location":"concepts/0519-goal-codes/#reference","title":"Reference","text":""},{"location":"concepts/0519-goal-codes/#known-namespace-aliases","title":"Known Namespace Aliases","text":"<p>No central registry of namespace aliases is maintained; you need not register with an authority to create a new one. Just pick an alias with good enough uniqueness, and socialize it within your community. For convenience of collision avoidance, however, we maintain a table of aliases that are typically used in global contexts, and welcome PRs from anyone who wants to update it.</p> alias used by URI aries Hyperledger Aries Community TBD"},{"location":"concepts/0519-goal-codes/#well-known-goal-codes","title":"Well-known goal codes","text":"<p>The following goal codes are defined here because they already have demonstrated utility, based on early SSI work in Aries and elsewhere.</p>"},{"location":"concepts/0519-goal-codes/#ariesvc","title":"<code>aries.vc</code>","text":"<p>Participate in some form of VC-based interaction. </p>"},{"location":"concepts/0519-goal-codes/#ariesvcissue","title":"<code>aries.vc.issue</code>","text":"<p>Issue a verifiable credential. </p>"},{"location":"concepts/0519-goal-codes/#ariesvcverify","title":"<code>aries.vc.verify</code>","text":"<p>Verify or validate VC-based assertions.</p>"},{"location":"concepts/0519-goal-codes/#ariesvcrevoke","title":"<code>aries.vc.revoke</code>","text":"<p>Revoke a VC.</p>"},{"location":"concepts/0519-goal-codes/#ariesrel","title":"<code>aries.rel</code>","text":"<p>Create, maintain, or end something that humans would consider a relationship. This may be accomplished by establishing, updating or deleting a DIDComm messaging connection that provides a secure communication channel for the relationship. The DIDComm connection itself is not the relationship, but would be used to carry out interactions between the parties to facilitate the relationship.</p>"},{"location":"concepts/0519-goal-codes/#ariesrelbuild","title":"<code>aries.rel.build</code>","text":"<p>Create a relationship. Carries the meaning implied today by a LinkedIn invitation to connect or a Facebook \"Friend\" request. Could be as limited as creating a DIDComm Connection.</p>"},{"location":"concepts/0519-goal-codes/#ariesvcverifieronce","title":"<code>aries.vc.verifier.once</code>","text":"<p>Create a DIDComm connection for the sole purpose of doing the one-time execution of a Present Proof protocol. Once the protocol execution is complete, both sides SHOULD delete the connection, as it will not be used again by either side.</p> <p>The purpose of the goal code flow is to accomplish the equivalent of a \"connection-less\" present proof by having the agents establish a DIDComm connection, execute the present proof protocol, and delete the connection. The need for this goal code is when an actual connection-less present proof cannot be used because the out-of-band (OOB) message (including the presentation request) is too large for the transport being used--most often a QR code (although it may be useful for Bluetooth scenarios as well)--and a URL shortner option is not available. By using a one-time connection, the OOB message is small enough to fit into easily into a QR code, the present proof protocol can be executed using the established connection, and at the end of the interaction, no connection remains for either side to use or manage.</p>"},{"location":"concepts/0519-goal-codes/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0530-goal-human-readable-verified-identifer/","title":"Aries RFC 0530: Goal - Human Readable Verifiable Identifier","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: PROPOSED</li> <li>Since: 2020-08-26</li> <li>Status Note: Early Proposal</li> <li>Start Date: 2020-08-26</li> <li>Tags: goalcode</li> </ul>"},{"location":"concepts/0530-goal-human-readable-verified-identifer/#summary","title":"Summary","text":"<p>DIDs are not human friendly. DIDComm provides a secure connection between two DIDs. This goal code seeks to provide a verifiable, human readable identifier from one party to another.</p>"},{"location":"concepts/0530-goal-human-readable-verified-identifer/#motivation","title":"Motivation","text":"<p>Presenting a Human Readable Verifiable Identifier over a DIDComm connection aids the user in positive connection identification. It also plays a role in Man-in-the-Middle (MitM) attack prevention.</p>"},{"location":"concepts/0530-goal-human-readable-verified-identifer/#reference","title":"Reference","text":""},{"location":"concepts/0530-goal-human-readable-verified-identifer/#goal-code","title":"Goal Code","text":"<p><code>aries.receive.verifiable.identifier</code></p>"},{"location":"concepts/0530-goal-human-readable-verified-identifer/#explanation","title":"Explanation","text":"<p>The party presenting this goal code has a goal of receiving a human readable verifiable identifier from the party it presents it to.</p>"},{"location":"concepts/0530-goal-human-readable-verified-identifer/#key-concepts","title":"Key Concepts","text":"<p>Human Readable implies that the identifier is meaningful to a human. This might be an identifier already used to communicate, such as an email address, phone number, website domain name, or social media account name.</p> <p>A Verifiable identifier requires that some level of assurance is provided that control has been proven over the identifier. </p> <p>Governance Frameworks that serve this goal code must provide details about which identifiers are acceptable, and how they are to be verified.  </p>"},{"location":"concepts/0530-goal-human-readable-verified-identifer/#governance-frameworks","title":"Governance Frameworks","text":"<p>The following Governance Frameworks are related to this goal code.</p> <ul> <li>Domain Control </li> <li>Email Ownership</li> </ul>"},{"location":"concepts/0530-goal-human-readable-verified-identifer/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"concepts/0530-goal-human-readable-verified-identifer/#implementations","title":"Implementations","text":"<p>NOTE: This section should remain in the RFC as is on first release. Remove this note and leave the rest of the text as is. Template text in all other sections should be removed before submitting your Pull Request.</p> <p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0559-pppu/","title":"Aries RFC 0559: Privacy-Preserving Proof of Uniqueness","text":"<ul> <li>Authors: Daniel Hardman, Drummond Reed, Lovesh Harchandani, Jason Law, Brent Zundel</li> <li>Status: PROPOSED</li> <li>Since: 2020-10-21</li> <li>Status Note: documents ideas mentioned at RWOT 9 (Sep 2019) and in informal conversations before and since. This is a defensive publication by the Aries community, to prevent such ideas from being encumbered by patents.  </li> <li>Start Date: 2019-02-13 (first formal writeup of the ../../concepts)</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0559-pppu/#summary","title":"Summary","text":"<p>Documents two techniques that, while preserving holder privacy, can guarantee a single use of a verifiable credential by any given unique holder -- the so-called \"one person one vote\" outcome that's often desirable in VC use cases.</p>"},{"location":"concepts/0559-pppu/#motivation","title":"Motivation","text":"<p>Many actions need to be constrained such that a given actor (usually, a human being) can only perform the action once. In government and stockholder elections, we want each voter to cast a single vote. At national borders, we want a visa to allow entrance only a single time before a visitor leaves. In refugee camps, homeless shelters, and halfway houses, we want each guest to access food or medication a single time per distribution event.</p> <p>Solving this problem without privacy is relatively straightforward. We require credentials that disclose a person\u2019s identity, and we track the identities to make sure each is authorized once. This pattern can be used with physical credentials, or with their digital equivalent.</p> <p>The problem is that each actor\u2019s behavior is tracked with this method, because it requires the recording of identity. Instead of just enforcing one-person-one-vote, we create a history of every instance when person X voted, which voting station they attended, what time they cast their vote, and so forth. We create similar records about personal travel or personal medication usage. Such information can be abused to surveil, to harass, to intrude, or to spam.</p> <p>What we need is a way to prove that an action is associated with a unique actor, and thus enforce the one-actor-one-action constraint, without disclosing that actor\u2019s identity in a way that erodes privacy. Although we began with examples of privacy for humans, we also want a solution for groups or institutions wishing to remain anonymous, or for devices, software entities, or other internet-of-things actors that have a similar need.</p>"},{"location":"concepts/0559-pppu/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0559-pppu/#solution-1","title":"Solution 1","text":"<p>This solution allows uniqueness to be imposed on provers during an arbitrary context chosen by the verifier, with no unusual setup at issuance time. For example, a verifier could decide to constrain a particular credential holder to proving something only once per hour, or once during a given contest or election. The price of this flexibility is that the credential holder must have a digital credential that already has important uniqueness guarantees (e.g., a driver's license, a passport, etc).</p> <p>In contrast, solution 2 imposes uniqueness at issuance time, but requires no  other credential with special guarantees.</p>"},{"location":"concepts/0559-pppu/#components","title":"Components","text":"<p>The following components are required to solve this problem:</p>"},{"location":"concepts/0559-pppu/#a","title":"A","text":"<p>one issuance to identified holder \u2014 A trustworthy process that issues verifiable credentials exactly once to an identified holder. (This is not new. Governments have such processes today to prevent issuing two driver\u2019s licenses or two passports to the same person.)</p>"},{"location":"concepts/0559-pppu/#b","title":"B","text":"<p>one issuance to anonymous holder \u2014 A method of issuing a credential only once to an anonymous holder. (This is not new. Scanning a biometric from an anonymous party, and then checking it against a list of known patterns with no additional metadata, is one way to do this. There are other, more cryptographic methods, as discussed below.)</p>"},{"location":"concepts/0559-pppu/#c","title":"C","text":"<p>strong binding \u2014 A mechanism for strongly associating credentials with a specific credential holder, such that they are not usable by anyone other than the proper holder. (This is not new. Embedding a biometric such as a fingerprint or a photo in a credential is a simple example of such a mechanism.)</p>"},{"location":"concepts/0559-pppu/#d","title":"D","text":"<p>linking mechanism \u2014 A mechanism for proving that it is valid to combine information from multiple credentials because they describe the same credential holder, without revealing the common link between those credentials. (An easy and familiar way to prove combinability is to embed a common characteristic in each credential. For example, two credentials that are both about a person with the same social security number can be assumed to describe the same person. What is required here goes one step further--we need a way to prove that two credentials contain the same data, or were built from the same data, without revealing that data at all. This is also not new. Cryptographic commitments provide one possible answer.)</p>"},{"location":"concepts/0559-pppu/#e","title":"E","text":"<p>proving without revealing \u2014 A method for proving the correctness of information derived from a credential, without sharing the credential information itself. (This is not new. In cryptographic circles, one such technique is known as a zero-knowledge proof. It allows Alice to hold a credential that contains her birthdate, but to prove she is over 65 years old instead of revealing the birthdate itself.)</p>"},{"location":"concepts/0559-pppu/#walkthru","title":"Walkthru","text":"<p>We will describe how this solution uses components A-E to help a fictional voter, Alice, in an interaction with a fictional government, G. Alice wishes to remain anonymous but still cast her vote in an election; G wishes to guarantee one-citizen-one-vote, but to retain no additional information that would endanger Alice\u2019s privacy. Extrapolating from a voting scenario to other situations that require uniqueness is left as an exercise for the reader.</p> <p>The solution works like this:</p> <ol> <li> <p>Alice receives a voter credential, C1, from G. C1 strongly identifies Alice, perhaps containing her name, address, birthdate, and so forth. It is possession of this credential that proves a right to vote. G issues only one such credential to each actor. (component A)</p> </li> <li> <p>C1 is bound to Alice so it can\u2019t be used by anyone else. (component C)</p> </li> <li> <p>C1 also contains data provided by Alice, and derived from a secret that only Alice knows, such that Alice can link C1 to other credentials with similarly derived data because she knows the secret. (component D)</p> <p></p> <p>Steps 1-3: Alice receives a voter credential from G.</p> </li> <li> <p>Alice arrives to vote and asserts her privilege to a different government agency, G\u2019, that administers the election.</p> </li> <li> <p>G\u2019 chooses a random identifier, X, for the anonymous person (Alice) that wants to vote.</p> </li> <li> <p>G\u2019 asks this anonymous voter (Alice) to provide data suitable for embedding in a new credential, such that the new credential and her old credential can be proved combinable. (component D).</p> </li> <li> <p>G\u2019 verifies that it has not issued a credential to this anonymous person previously. (component B)</p> </li> <li> <p>G\u2019 issues a new credential, C2, to the anonymous voter. C2 contains the random identifier X, plus the data that Alice provided in step 6. (This means the party playing the role of Verifier temporarily becomes a JIT Issuer.)</p> <p></p> <p>Steps 4-8: Anonymous (Alice) receives a unique credential from G\u2019.</p> </li> <li> <p>G\u2019 asks the anonymous voter to prove, without revealing any identifying information from C1 (component E) the following assertions:</p> <ul> <li>They possess a C1 and C2 that are combinable (component D)</li> <li>The C2 possessed by this anonymous voter contains the randomly-generated value X that was just chosen and embedded in the C2 issued by G\u2019. At this point X is revealed.</li> </ul> <p></p> <p>Step 9: Alice proves C1 and C2 are combinable and C2 contains X.</p> </li> </ol> <p>This solves the problem because:</p> <ul> <li>Each actor can only receive one C1 from G.</li> <li>Each actor can only receive one C2 from G\u2019.</li> <li>C1 cannot be shared or transferred.</li> <li>It is valid to combine information from C1 and C2 (they belong to the same actor), because of the first assertion in step 9.</li> <li>C2 is the same C2 that was just generated for the person asking to vote (it could not have been substituted), because it contains X as demonstrated by the second assertion in step 9.</li> <li>No identifying information in C1 is revealed.</li> </ul> <p>Both credentials are required. If a person only has C1, then there is no way to enforce single usage while remaining anonymous. If a person only has C2, then there is no reason to believe the unique person who shows up to vote actually deserves the voting privilege. It is the combination that proves uniqueness of the person in the voting event, plus privilege to cast a vote. Zero-knowledge proving is also required, or else the strongly identifying information in C1 may leak.</p> <p>As mentioned earlier, this same mechanism can be applied to scenarios besides voting, and can be used by actors other than individual human beings. G (the issuer of C1) and G\u2019 (the verifier of C1 and issuer of C2) do not need to be related entities, as long as G1 trusts G. What is common to all applications of the technique is that uniqueness is proved in a context chosen by the verifier, privilege is based on previously issued and strongly identifying credentials, and yet the anonymity of the credential holder is preserved.</p>"},{"location":"concepts/0559-pppu/#building-in-aries","title":"Building in Aries","text":"<p>Ingredients to build this solution are available in Aries or other Hyperledger projects (Ursa, Indy) today:</p> <ul> <li> <p>The behavior of component A could be enforced by a machine-readable governance framework.</p> </li> <li> <p>Component B can be built using an approach described here; a more general description was published much earlier, in a seminal \"Clone Wars\" paper by Camenisch et al.</p> </li> <li> <p>Component C can be accomplished using Indy's link secret construct, which uses Pedersen commitments to embed in a credential a blinded version of a secret known only to the holder. As mentioned earlier, biometric bindings are also an option. Depending on requirements for level of assurance, a simple binding by DID control may also work.</p> </li> <li> <p>Component D is a mainstream feature in Indy's anoncreds library today; it combines credentials by demonstrating mathematically that they each contain a differently blinded derivation of the same link secret. A more general form of this is available in Ursa; it demonstrates that any two fields are equal in two credentials without revealing the field values. [[TODO: need link]].</p> </li> <li> <p>Component E is available in Indy's anoncreds as well as in recent work done on BBS+ signatures by Mattr [[TODO: need link]].</p> </li> </ul>"},{"location":"concepts/0559-pppu/#solution-2","title":"Solution 2","text":"<p>This is another solution that accomplishes approximately the same goal as solution 1. It is particularly helpful in voting. It has much in common with the earlier approach, but differs in that uniqueness must be planned for at time of issuance (instead of being imposed just in time at verification). The issuer signs a serial number to each unique holder, and the holder then makes a Pedersen Commitment to their unique serial number while the voting is open. The holder cannot vote twice or change their vote. The voter\u2019s privacy is preserved.</p>"},{"location":"concepts/0559-pppu/#walkthru_1","title":"Walkthru","text":"<p>Suppose a poll is being conducted with p number of options as m1, m2, m3,... mp and each poll has a unique id I. Acme Corp is conducting the poll and Alice is considered an eligible voter by Acme Corp because Alice has a credential C from Acme Corp.</p>"},{"location":"concepts/0559-pppu/#goals","title":"Goals","text":"<ul> <li> <p>Ballot privacy: Alice should be able to participate in the poll without Acme corp finding out which poll option was chosen by Alice.</p> </li> <li> <p>One vote per voter: Alice should not be able to vote more than once.</p> </li> <li> <p>Immutable Ballot: Alice should be bound to her ballot, i.e. she should not be able to change her vote.</p> </li> <li> <p>Valid choice: Alice should not be able to vote for any option than the valid ones, i.e. other than m1, m2, m3,... mp.</p> </li> <li> <p>Verifiability: Alice should be able to check that her vote is being counted.</p> </li> <li> <p>No preview: Before the poll terminates, no one should be able to decide the outcome or even the favored option. This avoids bias.</p> </li> </ul> <p>Additional condition: In some cases the poll conduction entity, Acme Corp, in this case, may be accused of creating Sybil identities vote to influence the poll. This can be mitigated if an additional constraint is enforced where only those are eligible to vote who can prove that their credential C was issued before the poll started (or at least some time t before the poll started), i.e. Alice should be able to prove to anyone that her credential C was issued to anyone.</p>"},{"location":"concepts/0559-pppu/#setup","title":"Setup","text":"<p>Acme corp has hosted an application AS that maintains a merkle tree and the application follows some rules to update the tree. This application should be auditable meaning that anyone should be able to check whether the application is updating the tree as per the rules and the incoming data. Thus this application could be hosted on a blockchain, or within a trusted execution environment like SGX. Also the application server maintains a dynamic set where set membership check is efficient. The merkle tree is readable by all poll participants.</p> <p>There are 2 different functions defined F1 and F2 both of which take 2 inputs and return one output and they are not invertible, even knowing one input and output should not reveal other input. The output of both on same input must be different. Thus these can be modeled as different hash functions like SHA2 and SHA3 or SHA2 with domain separation. But we want these functions to R1CS friendly so we choose a hash function like MiMC with domain separation.</p>"},{"location":"concepts/0559-pppu/#basic-idea","title":"Basic idea","text":"<p>Alice generates a serial number and gets a blind signature from Acme Corp over the serial number. Then Alice creates her vote and sends the \"encrypted\" vote with the serial number and signature to the application server. Application server accepts the vote if the signature is valid and it has not seen that serial number before. It will then update the merkle tree with the \"encrypted\" vote and return a signed proof to Alice of the update. When the poll terminates, Alice will then submit the decryption key to the application server which can then decrypt the vote and do the tally.</p>"},{"location":"concepts/0559-pppu/#detailed-description","title":"Detailed description","text":"<ul> <li>Acme corp conducts a poll with p choices, m1, m2,..mp. The poll is given a unique identifier I.</li> <li>Alice wants to participate in the poll. She has a credential C from Acme with link secret l.</li> <li>Alice constructs serial number S using F1. S = F1(l, I).</li> <li>Alice blinds S and then obtains a blind signature (blind Schnorr works) from Amce Corp over it. Alice might have proved her ownership of credential C.</li> <li>Alice decides to vote for m2. She needs to commit to her vote as a Pedersen commitment. The randomness for the Pedersen commitment r is computed using F2.    r = F2(l, I). The committed vote now becomes gm2.hr. Let V = gm2.hr.</li> <li>Alice sends V and S and the signature over S from Acme to application server AS. Alice also sends a proof which proves the following:</li> <li>Alice owns a credential C from Acme Corp. This can be done with CL or BBS+ signature. Additionally, it can be proved that C was issued some time ago to achieve characteristic 5.</li> <li>Serial number S is constructed from the link secret l of C and poll identifier I using F1. This can be done with Bulletproofs by using proof of knowledge of preimage. We have proving knowledge of preimage implemented. The part about establishing equivalence with link secret l has to be done.</li> <li>V is correctly formed in this way gm2.hr. This is a standard Schnorr proof.</li> <li>V's randomness r is constructed from the link secret l of C and poll identifier I using F2. Again done with Bulletproofs above and circuit to prove knowledge of opening of Pedersen commitment. The 2<sup>nd</sup> part is to be implemented.</li> <li>V's message m2 is one of m1, m2,..mp. This can be done with set membership proof of committed value with Bulletproofs. We have it implemented already.</li> <li>If application server AS accepts a proof, it returns the signed merkle proof of the presence of V in the tree to Alice.</li> <li>Alice can anytime check that her V is present in the tree.</li> <li>Once poll completes, Alice can reveal opening of V to AS and then result of poll can be computed.</li> <li>Before the poll completes (and voter reveals their m and r, no one can know which option has been voted the most or least or not at all. </li> </ul>"},{"location":"concepts/0559-pppu/#rationale-and-alternatives","title":"Rationale and alternatives","text":""},{"location":"concepts/0559-pppu/#prior-art","title":"Prior art","text":""},{"location":"concepts/0559-pppu/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"concepts/0559-pppu/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/","title":"0566: Issuer-Hosted Custodial Agents","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: PROPOSED</li> <li>Since: 2020-11-16</li> <li>Status Note: Draft</li> <li>Start Date: 2020-10-27</li> <li>Tags: concept</li> </ul> <p>In the fully realized world of Self Soverign Identity, credential holders are equipped with capable agents to help them manage credentials and other SSI interactions. Before we arrive in that world, systems that facilitate the transition from the old model of centralized systems to the new decentralized models will be necessary and useful.</p> <p>One of the common points for a transition system is the issuance of credentials. Today's centralized systems contain information within an information silo. Issuing credentials requires the recipient to have an agent capable of receiving and managing the credential. Until the SSI transition is complete, some users will not have an agent of their own.</p> <p>Some users don't have the technology or the skills to use an agent, and there may be users who don't want to participate.</p> <p>In spite of the difficulties, there are huge advantages to transition to a decentralized system. Even when users don't understand the technology, they do care about the benefits it provides.</p> <p>This situation leaves the issuer with a choice: Maintain both a centralized system AND a decentralized SSI one, or enable their users to participate in the decentralized world.</p> <p>This paper addresses the second option: How to facilitate a transition to a decentralized world by providing issuer-hosted custodial agents.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#issuer-hosted-custodial-agents","title":"Issuer-Hosted Custodial Agents","text":"<p>A custodial agent is an agent hosted on behalf of someone else. This model is common in the cryptocurrency space. An Issuer-Hosted Custodial Agent is exactly what it sounds like: an agent hosted for the holder of a credential by the issuer of the credential.</p> <p>This custodial arrangement involves managing the credentials for the user, but also managing the keys for the user. Key management on behalf of another is often called guardianship.</p> <p>An alternative to hosting the agent directly is to pay for the hosting by a third party provider. This arrangement addresses some, but not all, of the issues in this paper.</p> <p>This custodial arrangement is only necessary for the users without their own agents. Users running their own agents (often a mobile app), will manage their own keys and their own credentials.</p> <p>For the users with their own agents, the decentralized world has taken full effect: they have their own data, and can participate fully in the SSI ecosystem.</p> <p>For the users with hosted custodial agents, they have only made a partial transition. The data is still hosted by the issuer. With appropriate limits, this storage model is no worse than a centralized system. Despite the data storage being the same, a hosted agent provides the ability to migrate to another agent if the user desires.</p> <p>Hosting agents for users might sound like a costly endeavor, but hosted agents contain an advantage. Most hosted agents will only be used by their owners for a small amount of time, most likely similar to their interaction with the centralized system it replaces. This means that the costs are substantially lower than hosting a full agent.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#hosted-agent-interaction","title":"Hosted Agent Interaction","text":"<p>Hosted agents have some particular challenges in providing effective user interaction. Detailed below are several options that can be used alone or in combination.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#browser-based","title":"Browser Based","text":"<p>Providing a browser based user interface for a user is a common solution when the user will have access to a computer. Authentication will likely use something familiar like a username and password.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#authorizing-actions","title":"Authorizing Actions","text":"<p>The user will often need a way to authorize actions that their agent will perform. A good option for this is via the use of a basic cell phone through SMS text messages or voice prompts. Less urgent actions can use an email sent to the user, prompting the user to login and authorize the actions.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#offline-paper-based","title":"Offline / Paper based","text":"<p>At times the user will have no available technology for their use. In this case, providing QR codes printed on paper with accompanying instructions will allow the user to facilitate verifier (and perhaps another issuer) access to their cloud agent. QR Codes, such as those detailed in the Out Of Band Protocol, can contain both information for connecting to agent AND an interaction to perform. Presenting the QR code for scanning can serve as a form of consent for the prescribed action within the QR code. Printed QR codes can be provided by the issuer at the time of custodial agent creation, or from within a web interface available to the user.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#kiosk-based","title":"Kiosk based","text":"<p>Kiosks can be useful to provide onsite interaction with a hosted agent. Kiosk authentication might take place via username and password, smartcard, or USB crypto key, with the possible inclusion of a biometric. Kiosks must be careful to fully remove any cached data when a session closes. Any biometric data used must be carefully managed between the kiosk and the hosted agent.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#smartphone-app","title":"Smartphone App","text":"<p>While it is common for a smartphone app to be an agent by itself, there are cases where a smartphone app can act as a remote for the hosted agent. In this iteraction, keys, credentials, and other wallet related data is held in the custodial agent. The mobile app acts as a remote viewer and a way for the user to authorize actions taken by the custodial agent.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#best-practices","title":"Best Practices","text":"<p>The following best practices should be followed to ensure proper operation and continued transition to a fully realized SSI architecture. Most of these practices depend upon and support one another.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#defend-the-ssi-architecture","title":"Defend the SSI architecture","text":"<p>When issuers host custodial agents, care must be taken to avoid shortcuts that would violate SSI architecture. Deviations will frequently lead to incompatibilities.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#didcomm-protocol-based-integration","title":"DIDComm Protocol based Integration","text":"<p>Communication between hosted agents and credential issuing agent must be based on published DIDComm protocols. Any communication which eliminates the use of a DID must be avoided. Whenever possible, these should be well adopted community protocols. If the case a new protocol is needed for a particular interaction, this must be fully documented and published, to allow other agents to become compatible by adopting the new protocol.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#allow-bring-your-own-agents","title":"Allow bring-your-own agents","text":"<p>The onboarding process must allow users to bring their own compatible agents. This will be possible as long as any communication is protocol based. No ../../features available to hosted agents should be blocked from user provided agents.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#limit-wallet-scope-to-data-originating-from-the-issuer","title":"Limit wallet scope to data originating from the issuer","text":"<p>Issuer hosted agents should have limits placed on them to prevent general use. This will prevent the agent from accepting additional credentials and data outside the scope of the issuer, therefore introducing responsibility for data that was never intended. This limtation must not limit the user in how they use the credentials issued, only in the acceptance of credentials and data from other issuers or parties. The use of policy and filters should be used to limit the types of credentials that can be held, which issuers should be allowed, and which protocols are enabled. None of these restrictions are necessary for bring-your-own agents provided by users.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#allow-migrate-from-hosted-to-bring-your-own","title":"Allow migrate from hosted to bring-your-own","text":"<p>Users must be allowed to transition from an issuer-hosted agent to an agent of their choosing. This can happen either via a backup in a standard format, or via re-issuing relevant credentials.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#transparent-to-the-verifier","title":"Transparent to the verifier","text":"<p>A verifier should not be able to tell the difference between a custodial hosted agent vs a bring-your-own agent.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#action-log","title":"Action Log","text":"<p>All actions taken by the wallet should be preserved in a log viewable to the user. This includes how actions were authorized, such as a named policy or confirmation via text message.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#encrypted-wallets","title":"Encrypted Wallets","text":"<p>Hosted wallet data should be encrypted at rest.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#independant-key-management","title":"Independant key management","text":"<p>Keys used for hosted agents should have key mangement isolated from the issuer keys. Access to the keys for hosted agents should be carefully limited to the minimum required personnel. All key access should be logged.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#hosted-agent-isolation","title":"Hosted Agent Isolation","text":"<p>Agents must be sufficiently isolated from each other to prevent a malicious user from accessing another user's agent or data or causing interruptions to the operation of another agent.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0700-oob-through-redirect/","title":"Aries RFC 0700: Out-of-Band through redirect","text":"<ul> <li>Authors: Sudesh Shetty</li> <li>Status: PROPOSED</li> <li>Since: 2021-10-08</li> <li>Status Note: implementation is being explored by SecureKey</li> <li>Start Date: 2019-10-08</li> <li>Tags: concept, decorator</li> </ul>"},{"location":"concepts/0700-oob-through-redirect/#summary","title":"Summary","text":"<p>Describes how one party can redirect to another party by passing out-of-band message as a query string and also recommends how to redirect back once protocol is over.  </p>"},{"location":"concepts/0700-oob-through-redirect/#motivation","title":"Motivation","text":"<p>In current day e-commerce applications, while performing checkout users are usually presented with various payment options, like direct payment options or through some payment gateways.  User then chooses an option, gets redirected to a payment application and then gets redirected back once transaction is over.  </p> <p>Similarly, sending an out-of-band invitation through redirect plays an important role in web based applications where an inviter who is aware of invitee application or a selection service should be able to send invitation through redirect. Once invitee accepts the invitation and protocol gets over, then invitee should also be able to redirect back to URL shared through DIDComm message during protocol execution.  The redirect can happen within the same device (ex: clicking a link) or between devices (ex: scanning a QR code).</p>"},{"location":"concepts/0700-oob-through-redirect/#scenario","title":"Scenario","text":"<p>Best example scenario would be how an issuer or a verifier applications trying to connect to holder applications for performing present proof or issuer credential protocol. A user who visits an issuer application can click on a link or scan a QR code to redirect to a holder application with an out-of-band message in query string (or redirect to a selection service showing available holder applications to choose from).  User's holder application decodes invitation from query string, performs issue credential protocol and redirects user back to URL it received through DIDComm message from issuer during execution of protocol.</p>"},{"location":"concepts/0700-oob-through-redirect/#tutorial","title":"Tutorial","text":"<p>There are 2 roles in this flow,</p> <ul> <li>requestor, the one who sends out-of-band invitation using query string to initiate a protocol.</li> <li>recipient, the one who receives out-of-band invitation and also the one who is asked to redirect back to requestor once protocol is over. </li> </ul>"},{"location":"concepts/0700-oob-through-redirect/#redirect-invitation-url","title":"Redirect Invitation URL","text":"<p>A redirect URL from inviter to connect can consist of following elements,</p> <ul> <li><code>domain and path</code>: domain and path are managed by inviter application and it can be a target application to which this out-of-band invitation is targeted. The target application can be a agent based application or a selection service which can present various application selection options to user.</li> <li><code>out-of-band message</code>: A query parameter <code>oob</code> containing out-of-band message of Base64URLEncoded json format. Refer Standard Out-of-Band Message Encoding to learn more.</li> <li><code>out-of-band message ID</code>: It seems inevitable that the length of some out-of-band message will be too long to produce a useable redirect URL or QR Code. A query parameter <code>oobid</code> containing out-of-band invitation URL which can be resolved to fetch actual invitation message. Refer Out-of-Band URL Shortening to learn more.</li> </ul>"},{"location":"concepts/0700-oob-through-redirect/#sample-1-redirect-invitation","title":"Sample 1: redirect invitation","text":"<p>Invitation:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/1.0/invitation\",\n  \"@id\": \"69212a3a-d068-4f9d-a2dd-4741bca89af3\",\n  \"label\": \"Faber College\",\n  \"goal_code\": \"issue-vc\",\n  \"goal\": \"To issue a Faber College Graduate credential\",\n  \"handshake_protocols\": [\"https://didcomm.org/didexchange/1.0\", \"https://didcomm.org/connections/1.0\"],\n  \"services\": [\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]\n}\n</code></pre> <p>Whitespace removed:</p> <pre><code>{\"@type\":\"https://didcomm.org/out-of-band/1.0/invitation\",\"@id\":\"69212a3a-d068-4f9d-a2dd-4741bca89af3\",\"label\":\"Faber College\",\"goal_code\":\"issue-vc\",\"goal\":\"To issue a Faber College Graduate credential\",\"handshake_protocols\":[\"https://didcomm.org/didexchange/1.0\",\"https://didcomm.org/connections/1.0\"],\"services\":[\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]}\n</code></pre> <p>Base 64 URL Encoded:</p> <pre><code>eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCAiZ29hbF9jb2RlIjoiaXNzdWUtdmMiLCJnb2FsIjoiVG8gaXNzdWUgYSBGYWJlciBDb2xsZWdlIEdyYWR1YXRlIGNyZWRlbnRpYWwiLCJoYW5kc2hha2VfcHJvdG9jb2xzIjpbImh0dHBzOi8vZGlkY29tbS5vcmcvZGlkZXhjaGFuZ2UvMS4wIiwiaHR0cHM6Ly9kaWRjb21tLm9yZy9jb25uZWN0aW9ucy8xLjAiXSwic2VydmljZSI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0\n</code></pre> <p>Example URL: targeting recipient 'recipient.example.com'</p> <pre><code>http://recipient.example.com/handle?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCAiZ29hbF9jb2RlIjoiaXNzdWUtdmMiLCJnb2FsIjoiVG8gaXNzdWUgYSBGYWJlciBDb2xsZWdlIEdyYWR1YXRlIGNyZWRlbnRpYWwiLCJoYW5kc2hha2VfcHJvdG9jb2xzIjpbImh0dHBzOi8vZGlkY29tbS5vcmcvZGlkZXhjaGFuZ2UvMS4wIiwiaHR0cHM6Ly9kaWRjb21tLm9yZy9jb25uZWN0aW9ucy8xLjAiXSwic2VydmljZSI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0\n</code></pre> <p>Out-of-band invitation redirect URLs can be transferred via text message, email, SMS, posting on a website, or QR Code.</p> <p>Example URL encoded as a QR Code:</p> <p></p>"},{"location":"concepts/0700-oob-through-redirect/#sample-2-redirect-invitation-url","title":"Sample 2: redirect invitation URL","text":"<p>Invitation URL from requestor which resolves to an out-of-band invitation:</p> <pre><code>https://requestor.example.com/ssi?id=5f0e3ffb-3f92-4648-9868-0d6f8889e6f3\n</code></pre> <p>Base 64 URL Encoded:</p> <pre><code>aHR0cHM6Ly9yZXF1ZXN0b3IuZXhhbXBsZS5jb20vc3NpP2lkPTVmMGUzZmZiLTNmOTItNDY0OC05ODY4LTBkNmY4ODg5ZTZmMw==\n</code></pre> <p>Example URL: targeting recipient 'recipient.example.com'</p> <pre><code>http://recipient.example.com/handle?oobid=aHR0cHM6Ly9yZXF1ZXN0b3IuZXhhbXBsZS5jb20vc3NpP2lkPTVmMGUzZmZiLTNmOTItNDY0OC05ODY4LTBkNmY4ODg5ZTZmMw==\n</code></pre> <p>Out-of-band invitation redirect URLs can be transferred via text message, email, SMS, posting on a website, or QR Code.</p> <p>Example URL encoded as a QR Code:</p> <p></p>"},{"location":"concepts/0700-oob-through-redirect/#web-redirect-decorator","title":"<code>~web-redirect</code> Decorator","text":"<p>In some scenarios, requestor would require recipient to redirect back after completion of protocol execution to proceed with further processing. For example, a verifier would request a holder application to redirect back  once present-proof protocol is over so that it can show credential verification results to user and navigate the user to further steps.</p> <p>The optional <code>~web-redirect</code> SHOULD be used in DIDComm message sent by requestor during protocol execution to send redirect information to recipient if required.</p> <p>This decorator may not be needed in many cases where requestor has control over the flow of application based on protocol status.  But this will be helpful in cases where an application has little or no control over user's navigation.  For example, in a web browser where user redirected from a verifier web application to his wallet application in a same window through some wallet selection wizard and some third party logins.  In this case once the protocol execution is over,  verifier can send a URL to wallet application requesting redirect.  This decorator is also useful switching from wallet mobile app to verifier mobile app in a mobile device.</p> <pre><code>\"~web-redirect\": {\n  \"status\": \"OK\",\n  \"url\": \"https://example.com/handle-success/51e63a5f-93e1-46ac-b269-66bb22591bfa\"\n}\n</code></pre> <p>where,</p> <ul> <li><code>status</code>: The value of this property MUST be one of the statuses defined here</li> <li><code>url</code>: URL to which recipient of this message is requested to redirect.</li> </ul> <p>Some of the DIDComm messages which can use <code>~web-redirect</code> details to send redirect request.</p> <ul> <li>protocol acknowledgment messages</li> <li>problem reports</li> <li>protocol messages which concludes the protocol, like Issue Credential message.</li> </ul>"},{"location":"concepts/0700-oob-through-redirect/#putting-all-together","title":"Putting all together","text":""},{"location":"concepts/0700-oob-through-redirect/#sending-invitation-to-recipient-through-redirect","title":"Sending Invitation to Recipient through redirect","text":"<ul> <li> <p>Step 1 - requestor prepares out-of-band redirect URL : requestor prepares URL using encoded JSON invitation or using a URL which resolves to an invitation.  Domain and target of URL can be a known recipient.</p> </li> <li> <p>Step 2: requestor presents redirect URL to user: redirect URL can be presented to user as a link, mobile deep link, QR Code, SMS, Email etc.  For example, user visits a verifier application and presented with link or QRCode to share his or her credentials.</p> </li> <li> <p>Step 3: user redirects to recipient: user clicks on link or scans QR code and then authenticates himself or herself in redirected application.  For example, user clicks on a link to share credentials in a verifier application, gets redirected to a holder application and logs in using his or her login credentials.</p> </li> <li> <p>Step 4: recipient accepts invitation, connects with requestor and executes protocol: recipient application decodes invitation, accepts it and executes DIDComm protocol. For example, holder application accepts invitation from a verifier, performs present proof and meanwhile shows credential interaction screen to user for consent.</p> </li> <li> <p>Step 5: requestor shares web redirect info to recipient for next step: requestor sends <code>~web-redirect</code> to recipient application through acknowledgement, problem report or any other DIDComm message which concludes protocol.  For example, verifier sending its success page URL as part of acknowledgement message to user after successful completion present proof protocol.</p> </li> <li> <p>Step 6: user redirected back to requestor: recipient application extracts redirect info from <code>~web-redirect</code> and redirects.  For example where user is presented with successful credential verification screen and asked to proceed with further steps.</p> </li> </ul>"},{"location":"concepts/0700-oob-through-redirect/#sending-invitation-to-selection-service-through-redirect","title":"Sending Invitation to Selection Service through redirect","text":"<p>This flow is similar to previous flow but target domain and path of invitation redirect URL will be selection service which presents user with various options to choose recipient application of choice. So in Step 3, user redirects to a selection service which guides user to select right recipient. For example a scenario where user is presented with various holder application providers to choose from while sharing/saving his or her verifiable credentials.</p>"},{"location":"concepts/0700-oob-through-redirect/#reference","title":"Reference","text":"<ul> <li>Wallet And Credential Interactions</li> </ul>"},{"location":"concepts/0700-oob-through-redirect/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>How different recipient applications registers with a selection service and establishing trust between requestor, recipient and selection service are out of scope of this RFC.</p>"},{"location":"concepts/0700-oob-through-redirect/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0757-push-notification/","title":"0757: Push Notification","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: PROPOSED</li> <li>Since: 2022-11-02 </li> <li>Status Note:  </li> <li>Start Date: 2022-11-02 </li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0757-push-notification/#summary","title":"Summary","text":"<p>This RFC Describes the general concept of push notification as it applies to Aries Agents. There are a variety of push notification systems and methods, each of which is described in it's own feature RFC.</p> <p>Note: These protocols operate only between a mobile app and it's mediator(s). There is no requirement to use these protocols when mobile apps and mediator services are provided as a bundle. These protocols exist to facilitate cooperation between open source mediators and mobile apps not necessarily developed between the same parties.</p>"},{"location":"concepts/0757-push-notification/#motivation","title":"Motivation","text":"<p>Mobile agents typically require the use of Mediators to receive DIDComm Messages. When messages arrive at a mediator, it is optimal to send a push notification to the mobile device to signal that a message is waiting. This provides a good user experience and allows mobile agents to be responsive without sacrificing battery life by routinly checking for new messages.</p>"},{"location":"concepts/0757-push-notification/#tutorial","title":"Tutorial","text":"<p>Though push notification is common mobile platforms, there are a variety of different systems with various requirements and mecanisms. Most of them follow a familiar pattern:</p>"},{"location":"concepts/0757-push-notification/#setup-phase","title":"Setup Phase","text":"<ol> <li>Notification Sender (mediator) registers with a push notification service. This typically involves some signup procedure.</li> <li>Notification Recipient (mobile app) registers with the push notification service. This typically involves some signup procedure. For some platforms, or for a mediator and mobile app by the same vendor, this will be accomplished in step 1.</li> <li>Notification Recipient (mobile app) adds code (with config values obtained in step 2) to connect to the push notification service.</li> <li>Notification Recipient (mobile app) communicates necessary information to the Notification Sender (mediator) for use in sending notifications.</li> </ol>"},{"location":"concepts/0757-push-notification/#notification-phase","title":"Notification Phase","text":"<ol> <li>A message arrives at the Notification Sender (mediator) destined for the Notification Recipient (mobile app).</li> <li>Notification Sender (mediator) calls an API associated with the push notification service with notification details, typically using the information obtained in step 4.</li> <li>Notification Recipient (mobile app) is notified (typically via a callback function) of the notification details.</li> <li>Notification Recipient (mobile app) then connects to the Notification Sender (mediator) and receives waiting messages.</li> </ol> <p>In spite of the flow similarities between the push notification platforms, the implementations, libraries used, and general code paths vary substantially.  Each push notification method is described in it's own protocol. This allows the protocol to fit the specific needs and terminology of the notification method it enables. Feature Discovery can be used between the Notification Sender and the Notification Recipient to discover push notification compatibility.</p>"},{"location":"concepts/0757-push-notification/#public-mediators","title":"Public Mediators","text":"<p>Some push notification methods require matching keys or secrets to be used in both sending and receiving notifications. This requirement makes these push notification methods unusable by public mediators.</p> <p>Public mediators SHOULD only implement push notification methods that do not require sharing secrets or keys with application implementations.</p>"},{"location":"concepts/0757-push-notification/#push-notification-protcols","title":"Push Notification Protcols","text":"<p>0699 - Push Notification APNS 1.0 (Apple Push Notification Service)</p>"},{"location":"concepts/0757-push-notification/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0799-long-term-support/","title":"0799: Aries Long Term Support Releases","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: PROPOSED</li> <li>Since: 2023-11-07 </li> <li>Start Date: 2023-11-07 </li> <li>Tags: concept</li> </ul> <p>Long Term Support Releases of Aries projects will assist those using the software to integrate within their development processes.</p>"},{"location":"concepts/0799-long-term-support/#motivation","title":"Motivation","text":"<p>Long Term Support releases allow stable use of projects without frequent code updates. Designating LTS releases frees projects to develop ../../features without worry of disrupting those seeking feature stable deployments. </p>"},{"location":"concepts/0799-long-term-support/#project-lts-releases","title":"Project LTS Releases","text":"<ul> <li>Details specific to each project will be found within the relevant repositories. </li> <li>Projects SHOULD create an LTS policy within the code repository for the project. </li> <li>Projects MAY alter any of these suggestions to match the needs of the project.</li> </ul>"},{"location":"concepts/0799-long-term-support/#lts-release-tagging","title":"LTS Release Tagging","text":"<ul> <li>No Specific version number scheme for LTS releases are set Aries-wide. Each project can use any version numbering they desire. Projects must have a way to indicate patch releases.</li> <li>The README.md file within each repository must indicate which version is an LTS release, with a link to the release or branch of the LTS</li> <li>Each LTS release MUST include detailed release notes detailing the changes from the last LTS release, including complex details or gotchas.</li> <li>It is recommended, when possible, to designate an LTS release when a project reaches compliance with an Interop Profile, including an AIP.</li> </ul>"},{"location":"concepts/0799-long-term-support/#lts-support-timeline","title":"LTS Support Timeline","text":"<ul> <li>Each LTS release MUST be supported for at least 9 months AFTER the next LTS release is designated.</li> <li>When the next LTS release is designated, the prior LTS release must clearly indicate the End of Support Date at least 9 months in future.</li> <li>A branch SHOULD be created to ease bugfixes and the maintenance of LTS patch releases.</li> <li>If a support term in excess of the minimum 9 months is chosen and and End of Support Date published, that period MUST be honored for that release.</li> <li>Projects may may designate an LTS release with any candance desired by the project.</li> <li>Frequent LTS relases may result in multiple LTS releases receiving support. Seeking community input for LTS release timing may decrease support efforts.</li> </ul>"},{"location":"concepts/0799-long-term-support/#lts-release-updates","title":"LTS Release Updates","text":"<ul> <li>Each LTS release MUST be updated for security updates via patch releases for the duration of its support lifetime.</li> <li>Each LTS release MAY include bugfixes that impact usability of the release.</li> <li>LTS patch releases MUST include detailed release notes.</li> <li>Updates MUST NOT include API updates, programatic interface changes, or major logic changes.</li> </ul>"},{"location":"concepts/0799-long-term-support/#references","title":"References","text":"<p>This policy is inspired by the Fabric LTS Policy https://hyperledger.github.io/fabric-rfcs/text/0005-lts-release-strategy.html</p>"},{"location":"features/0015-acks/","title":"Aries RFC 0015: ACKs","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Broadly implemented, adopted into many protocols and part of AIP 1 and 2.</li> <li>Start Date: 2018-12-26</li> <li>Tags: feature</li> </ul>"},{"location":"features/0015-acks/#summary","title":"Summary","text":"<p>Explains how one party can send acknowledgment messages (ACKs) to confirm receipt and clarify the status of complex processes.</p>"},{"location":"features/0015-acks/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> <li>20220322: Clarification that an Ack <code>Fail</code> must not be used, and that a Report Problem must be used in its place. Remove Ack <code>Fail</code> from the RFC.</li> <li>20200325: In the ~thread decorator section of the sample in the Explicit ACKs section, 'myindex' was changed to 'sender_order' and 'lrecs' to 'received_orders'. This is in accordance with the field names as defined in RFC 0008.</li> </ul>"},{"location":"features/0015-acks/#motivation","title":"Motivation","text":"<p>An acknowledgment or ACK is one of the most common procedures in protocols of all types. We need a flexible, powerful, and easy way to send such messages in agent-to-agent interactions.</p>"},{"location":"features/0015-acks/#tutorial","title":"Tutorial","text":"<p>Confirming a shared understanding matters whenever independent parties interact. We buy something on Amazon; moments later, our email client chimes to tell us of a new message with subject \"Thank you for your recent order.\" We verbally accept a new job, but don't rest easy until we've also emailed the signed offer letter back to our new boss. We change a password on an online account, and get a text at our recovery phone number so both parties know the change truly originated with the account's owner.</p> <p>When formal acknowledgments are missing, we get nervous. And rightfully so; most of us have a story of a package that was lost in the mail, or a web form that didn't submit the way we expected.</p> <p>Agents interact in very complex ways. They may use multiple transport mechanisms, across varied protocols, through long stretches of time. While we usually expect messages to arrive as sent, and to be processed as expected, a vital tool in the agent communication repertoire is the receipt of acknowledgments to confirm a shared understanding.</p>"},{"location":"features/0015-acks/#implicit-acks","title":"Implicit ACKs","text":"<p>Message threading includes a lightweight, automatic sort of ACK in the form of the <code>~thread.received_orders</code> field. This allows Alice to report that she has received Bob's recent message that had <code>~thread.sender_order</code> = N. We expect threading to be best practice in many use cases, and we expect interactions to often happen reliably enough and quickly enough that implicit ACKs provide high value. If you are considering ACKs but are not familiar with that mechanism, make sure you understand it, first. This RFC offers a supplement, not a replacement.</p>"},{"location":"features/0015-acks/#explicit-acks","title":"Explicit ACKs","text":"<p>Despite the goodness of implicit ACKs, there are many circumstances where a reply will not happen immediately. Explicit ACKs can be vital here.</p> <p>Explicit ACKS may also be vital at the end of an interaction, when work is finished: a credential has been issued, a proof has been received, a payment has been made. In such a flow, an implicit ACK meets the needs of the party who received the final message, but the other party may want explicit closure. Otherwise they can't know with confidence about the final outcome of the flow.</p> <p>Rather than inventing a new \"interaction has been completed successfully\" message for each protocol, an all-purpose <code>ack</code> message type is recommended. It looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/notification/1.0/ack\",\n  \"@id\": \"06d474e0-20d3-4cbf-bea6-6ba7e1891240\",\n  \"status\": \"OK\",\n  \"~thread\": {\n    \"thid\": \"b271c889-a306-4737-81e6-6b2f2f8062ae\",\n    \"sender_order\": 4,\n    \"received_orders\": {\"did:sov:abcxyz\": 3}\n  }\n}\n</code></pre> <p>It may also be appropriate to send an ack at other key points in an interaction (e.g., when a key rotation notice is received).</p>"},{"location":"features/0015-acks/#adopting-acks","title":"Adopting acks","text":"<p>As discussed in 0003: Protocols, a protocol can adopt the ack message into its own namespace. This allows the type of an ack to change from:     <code>https://didcomm.org/notification/1.0/ack</code> to something like:     <code>https://didcomm.org/otherProtocol/2.0/ack</code>. Thus, message routing logic can see the ack as part of the other protocol, and send it to the relevant handler--but still have all the standardization of generic acks.</p>"},{"location":"features/0015-acks/#ack-status","title":"ack status","text":"<p>The <code>status</code> field in an ack tells whether the ack is final or not with respect to the message being acknowledged. It has 2 predefined values: <code>OK</code> (which means an outcome has occurred, and it was positive); and <code>PENDING</code>, which acknowledges that no outcome is yet known.</p> <p>There is not an ack <code>status</code> of <code>FAIL</code>. In the case of a protocol failure a Report Problem message must be used to inform the other party(ies). For more details, see the next section.</p> <p>In addition, more advanced ack usage is possible. See the details in the Reference section.</p>"},{"location":"features/0015-acks/#relationship-to-problem-report","title":"Relationship to <code>problem-report</code>","text":"<p>Negative outcomes do not necessarily mean that something bad happened; perhaps Alice comes to hope that Bob rejects her offer to buy his house because she's found something better--and Bob does that, without any error occurring. This is not a FAIL in a problem sense; it's a FAIL in the sense that the offer to buy did not lead to the outcome Alice intended when she sent it.</p> <p>This raises the question of errors. Any time an unexpected problem arises, best practice is to report it to the sender of the message that triggered the problem. This is the subject of the problem reporting mechanism.</p> <p>A <code>problem_report</code> is inherently a sort of ACK. In fact, the <code>ack</code> message type and the <code>problem_report</code> message type are both members of the same <code>notification</code> message family. Both help a sender learn about status. Therefore, a requirement for an <code>ack</code> is that a status of <code>FAIL</code> be satisfied by a <code>problem_report</code> message.</p> <p>However, there is some subtlety in the use of the two types of messages. Some <code>ack</code>s may be sent before a final outcome, so a final <code>problem_report</code> may not be enough. As well, an ack request may be sent after a previous <code>ack</code> or <code>problem_report</code> was lost in transit. Because of these caveats, developers whose code creates or consumes acks should be thoughtful about where the two message types overlap, and where they do not. Carelessness here is likely to cause subtle, hard-to-duplicate surprises from time to time.</p>"},{"location":"features/0015-acks/#custom-acks","title":"Custom ACKs","text":"<p>This mechanism cannot address all possible ACK use cases. Some ACKs may require custom data to be sent, and some acknowledgment schemes may be more sophisticated or fine-grained that the simple settings offered here. In such cases, developers should write their own ACK message type(s) and maybe their own decorators. However, reusing the field names and conventions in this RFC may still be desirable, if there is significant overlap in the ../../concepts.</p>"},{"location":"features/0015-acks/#reference","title":"Reference","text":""},{"location":"features/0015-acks/#ack-message","title":"<code>ack</code> message","text":""},{"location":"features/0015-acks/#status","title":"<code>status</code>","text":"<p>Required, values <code>OK</code> or <code>PENDING</code>. As discussed above, this tells whether the ack is final or not with respect to the message being acknowledged.</p>"},{"location":"features/0015-acks/#threadthid","title":"<code>~thread.thid</code>","text":"<p>Required. This links the <code>ack</code> back to the message that requested it.</p> <p>All other fields in an <code>ack</code> are present or absent per requirements of ordinary messages.</p>"},{"location":"features/0015-acks/#drawbacks-and-alternatives","title":"Drawbacks and Alternatives","text":"<p>None identified.</p>"},{"location":"features/0015-acks/#prior-art","title":"Prior art","text":"<p>See notes above about the implicit ACK mechanism in <code>~thread.received_orders</code>.</p>"},{"location":"features/0015-acks/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Muliplexed acks. How do you supply an ACK to all of Alice's agents instead of just to the one who involved in the current protocol?</li> </ul>"},{"location":"features/0015-acks/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes RFC 0036: Issue Credential Protocol ACKs are adopted by this protocol. RFC 0037: Present Proof Protocol ACKs are adopted by this protocol. RFC 0193: Coin Flip Protocol ACKs are adopted as a subprotocol. Aries Cloud Agent - Python Contributed by the Government of British Columbia."},{"location":"features/0019-encryption-envelope/","title":"Aries RFC 0019: Encryption Envelope","text":"<ul> <li>Authors: Kyle Den Hartog, Stephen Curran, Sam Curren, Mike Lodder</li> <li>Status: ADOPTED</li> <li>Since: 2019-05-04</li> <li>Status Note:  </li> <li>Supersedes: INDY 0028 Wire Level Format</li> <li>Start Date: 2018-07-10 (approximate, backdated)</li> <li>Tags: feature</li> </ul>"},{"location":"features/0019-encryption-envelope/#summary","title":"Summary","text":"<p>There are two layers of messages that combine to enable interoperable self-sovereign agent-to-agent communication. At the highest level are DIDComm Plaintext Messages - messages sent between identities to accomplish some shared goal (e.g., establishing a connection, issuing a verifiable credential, sharing a chat). DIDComm Plaintext Messages are delivered via the second, lower layer of messaging - DIDComm Encrypted Envelopes. A DIDComm Encrypted Envelope is a wrapper (envelope) around a plaintext message to permit secure sending and routing. A plaintext message going from its sender to its receiver passes through many agents, and an encryption envelope is used for each hop of the journey.</p> <p>This RFC describes the DIDComm Encrypted Envelope format and the <code>pack()</code> and <code>unpack()</code> functions that implement this format.</p>"},{"location":"features/0019-encryption-envelope/#motivation","title":"Motivation","text":"<p>Encryption envelopes use a standard format built on JSON Web Encryption - RFC 7516. This format is not captive to Aries; it requires no special Aries worldview or Aries dependencies to implement. Rather, it is a general-purpose solution to the question of how to encrypt, decrypt, and route messages as they pass over any transport(s). By documenting the format here, we hope to provide a point of interoperability for developers of agents inside and outside the Aries ecosystem.</p> <p>We also document how Aries implements its support for the DIDComm Encrypted Envelope format through the <code>pack()</code> and <code>unpack()</code> functions. For developers of Aries, this is a sort of design doc; for those who want to implement the format in other tech stacks, it may be a useful reference.</p>"},{"location":"features/0019-encryption-envelope/#tutorial","title":"Tutorial","text":""},{"location":"features/0019-encryption-envelope/#assumptions","title":"Assumptions","text":"<p>We assume that each sending agent knows:</p> <ul> <li>Its intended recipient(s).</li> <li>What encryption (if any) is appropriate.</li> <li>If encryption will be used, a public key of the receiving agent.</li> <li>The physical endpoint to use for the receiver, and the appropriate transport protocol (https, zmq, etc.).</li> </ul> <p>The assumptions can be made because either the message is being sent to an agent within the sending agent's domain and so the sender knows the internal configuration of agents, or the message is being sent outside the sending agent's domain and interoperability requirements are in force to define the sending agent's behaviour.</p>"},{"location":"features/0019-encryption-envelope/#example-scenario","title":"Example Scenario","text":"<p>The example of Alice and Bob's sovereign domains is used for illustrative purposes in defining this RFC.</p> <p></p> <p>In the diagram above:</p> <ul> <li>Alice has</li> <li>1 Edge agent - \"1\"</li> <li>1 Routing agent - \"2\"</li> <li>1 Domain Endpoint - \"8\"</li> <li>Bob has</li> <li>3 Edge Agents - \"4\", \"5\" and \"6\"<ul> <li>\"6\" is an Edge agent in the cloud, \"4\" and \"5\" are physical devices.</li> </ul> </li> <li>1 Routing agent - \"3\"</li> <li>1 Domain Endpoint - \"9\"</li> </ul> <p>For the purposes of this discussion we are defining the Encryption Envelope agent message flow to be:</p> <p>1 \u2192 2 \u2192 8 \u2192 9 \u2192 3 \u2192 4</p> <p>However, that flow is just one of several that could match this configuration. What we know for sure is that:</p> <ul> <li>1 is the Sender agent in this case and so must send the first or original message.</li> <li>9 is the Domain Endpoint of Bob's domain and so must receive the message as an Encrypted Envelope.</li> <li>4 is the Receiver in this case and so must receive (and should be able to read) the first or original message.</li> </ul>"},{"location":"features/0019-encryption-envelope/#encrypted-envelopes","title":"Encrypted Envelopes","text":"<p>An encrypted envelope is used to transport any plaintext message from one agent directly to another. In our example message flow above, there are five encrypted envelopes sent, one for each hop in the flow. The process to send an encrypted envelope consists of the following steps:</p> <ul> <li>Call the standard function <code>pack()</code> to wrap the plaintext message</li> <li>Send the encrypted envelope using the transport protocol defined by the receiving endpoint</li> <li>Receive the encrypted envelope</li> <li>Call the standard function <code>unpack()</code> to retrieve the plaintext message (and possibly its provenance) from the encrypted envelope</li> </ul> <p>This is repeated with each hop, but the encrypted envelopes are nested, such that the plaintext is never visible until it reaches its final recipient.</p>"},{"location":"features/0019-encryption-envelope/#implementation","title":"Implementation","text":"<p>We will describe the pack and unpack algorithms, and their output, in terms of Aries' initial implementation, which may evolve over time. Other implementations could be built, but they would need to emit and consume similar inputs and outputs.</p> <p>The data structures emitted and consumed by these algorithms are described in a formal schema.</p>"},{"location":"features/0019-encryption-envelope/#authcrypt-mode-vs-anoncrypt-mode","title":"Authcrypt mode vs. Anoncrypt mode","text":"<p>When packing and unpacking are done in a way that the sender is anonymous, we say that we are in anoncrypt mode. When the sender is revealed, we are in authcrypt mode. Authcrypt mode reveals the sender to the recipient only; it is not the same as a non-repudiable signature. See the RFC about non-repudiable signatures, and this discussion about the theory of non-repudiation.</p>"},{"location":"features/0019-encryption-envelope/#pack-message","title":"Pack Message","text":""},{"location":"features/0019-encryption-envelope/#pack_message-interface","title":"pack_message() interface","text":"<p>packed_message = pack_message(wallet_handle, message, receiver_verkeys, sender_verkey)</p>"},{"location":"features/0019-encryption-envelope/#pack_message-params","title":"pack_message() Params:","text":"<ul> <li>wallet_handle: handle to the wallet that contains the sender's secrets.</li> <li>message: the message (plaintext, or nested encrypted envelope) as a string. If it's JSON object it should be in string format first</li> <li>receiver_verkeys: a list of recipient verkeys as string containing a JSON array</li> <li>sender_verkey: the sender's verkey as a string. This verkey is used to look up the sender's private key so the wallet can put supply it as input to the encryption algorithm. When an empty string (\"\") is passed in this parameter, anoncrypt mode is used</li> </ul>"},{"location":"features/0019-encryption-envelope/#pack_message-return-value-authcrypt-mode","title":"pack_message() return value (Authcrypt mode)","text":"<p>This is an example of an outputted message encrypting for two verkeys using Authcrypt.</p> <pre><code>{\n    \"protected\": \"eyJlbmMiOiJ4Y2hhY2hhMjBwb2x5MTMwNV9pZXRmIiwidHlwIjoiSldNLzEuMCIsImFsZyI6IkF1dGhjcnlwdCIsInJlY2lwaWVudHMiOlt7ImVuY3J5cHRlZF9rZXkiOiJMNVhEaEgxNVBtX3ZIeFNlcmFZOGVPVEc2UmZjRTJOUTNFVGVWQy03RWlEWnl6cFJKZDhGVzBhNnFlNEpmdUF6IiwiaGVhZGVyIjp7ImtpZCI6IkdKMVN6b1d6YXZRWWZOTDlYa2FKZHJRZWpmenRONFhxZHNpVjRjdDNMWEtMIiwiaXYiOiJhOEltaW5zdFhIaTU0X0otSmU1SVdsT2NOZ1N3RDlUQiIsInNlbmRlciI6ImZ0aW13aWlZUkc3clJRYlhnSjEzQzVhVEVRSXJzV0RJX2JzeERxaVdiVGxWU0tQbXc2NDE4dnozSG1NbGVsTThBdVNpS2xhTENtUkRJNHNERlNnWkljQVZYbzEzNFY4bzhsRm9WMUJkREk3ZmRLT1p6ckticUNpeEtKaz0ifX0seyJlbmNyeXB0ZWRfa2V5IjoiZUFNaUQ2R0RtT3R6UkVoSS1UVjA1X1JoaXBweThqd09BdTVELTJJZFZPSmdJOC1ON1FOU3VsWXlDb1dpRTE2WSIsImhlYWRlciI6eyJraWQiOiJIS1RBaVlNOGNFMmtLQzlLYU5NWkxZajRHUzh1V0NZTUJ4UDJpMVk5Mnp1bSIsIml2IjoiRDR0TnRIZDJyczY1RUdfQTRHQi1vMC05QmdMeERNZkgiLCJzZW5kZXIiOiJzSjdwaXU0VUR1TF9vMnBYYi1KX0pBcHhzYUZyeGlUbWdwWmpsdFdqWUZUVWlyNGI4TVdtRGR0enAwT25UZUhMSzltRnJoSDRHVkExd1Z0bm9rVUtvZ0NkTldIc2NhclFzY1FDUlBaREtyVzZib2Z0d0g4X0VZR1RMMFE9In19XX0=\",\n    \"iv\": \"ZqOrBZiA-RdFMhy2\",\n    \"ciphertext\": \"K7KxkeYGtQpbi-gNuLObS8w724mIDP7IyGV_aN5AscnGumFd-SvBhW2WRIcOyHQmYa-wJX0MSGOJgc8FYw5UOQgtPAIMbSwVgq-8rF2hIniZMgdQBKxT_jGZS06kSHDy9UEYcDOswtoLgLp8YPU7HmScKHSpwYY3vPZQzgSS_n7Oa3o_jYiRKZF0Gemamue0e2iJ9xQIOPodsxLXxkPrvvdEIM0fJFrpbeuiKpMk\",\n    \"tag\": \"kAuPl8mwb0FFVyip1omEhQ==\"\n}\n</code></pre> <p>The base64URL encoded <code>protected</code> decodes to this: <pre><code>{\n    \"enc\": \"xchacha20poly1305_ietf\",\n    \"typ\": \"JWM/1.0\",\n    \"alg\": \"Authcrypt\",\n    \"recipients\": [\n        {\n            \"encrypted_key\": \"L5XDhH15Pm_vHxSeraY8eOTG6RfcE2NQ3ETeVC-7EiDZyzpRJd8FW0a6qe4JfuAz\",\n            \"header\": {\n                \"kid\": \"GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL\",\n                \"iv\": \"a8IminstXHi54_J-Je5IWlOcNgSwD9TB\",\n                \"sender\": \"ftimwiiYRG7rRQbXgJ13C5aTEQIrsWDI_bsxDqiWbTlVSKPmw6418vz3HmMlelM8AuSiKlaLCmRDI4sDFSgZIcAVXo134V8o8lFoV1BdDI7fdKOZzrKbqCixKJk=\"\n            }\n        },\n        {\n            \"encrypted_key\": \"eAMiD6GDmOtzREhI-TV05_Rhippy8jwOAu5D-2IdVOJgI8-N7QNSulYyCoWiE16Y\",\n            \"header\": {\n                \"kid\": \"HKTAiYM8cE2kKC9KaNMZLYj4GS8uWCYMBxP2i1Y92zum\",\n                \"iv\": \"D4tNtHd2rs65EG_A4GB-o0-9BgLxDMfH\",\n                \"sender\": \"sJ7piu4UDuL_o2pXb-J_JApxsaFrxiTmgpZjltWjYFTUir4b8MWmDdtzp0OnTeHLK9mFrhH4GVA1wVtnokUKogCdNWHscarQscQCRPZDKrW6boftwH8_EYGTL0Q=\"\n            }\n        }\n    ]\n}\n</code></pre></p>"},{"location":"features/0019-encryption-envelope/#pack-output-format-authcrypt-mode","title":"pack output format (Authcrypt mode)","text":"<pre><code>    {\n        \"protected\": \"b64URLencoded({\n            \"enc\": \"xchachapoly1305_ietf\",\n            \"typ\": \"JWM/1.0\",\n            \"alg\": \"Authcrypt\",\n            \"recipients\": [\n                {\n                    \"encrypted_key\": base64URLencode(libsodium.crypto_box(my_key, their_vk, cek, cek_iv))\n                    \"header\": {\n                          \"kid\": \"base58encode(recipient_verkey)\",\n                           \"sender\" : base64URLencode(libsodium.crypto_box_seal(their_vk, base58encode(sender_vk)),\n                            \"iv\" : base64URLencode(cek_iv)\n                }\n            },\n            ],\n        })\",\n        \"iv\": &lt;b64URLencode(iv)&gt;,\n        \"ciphertext\": b64URLencode(encrypt_detached({'@type'...}, protected_value_encoded, iv, cek),\n        \"tag\": &lt;b64URLencode(tag)&gt;\n    }\n</code></pre>"},{"location":"features/0019-encryption-envelope/#authcrypt-pack-algorithm","title":"Authcrypt pack algorithm","text":"<ol> <li>generate a content encryption key (symmetrical encryption key)</li> <li>encrypt the CEK for each recipient's public key using Authcrypt (steps below)<ol> <li>set <code>encrypted_key</code> value to base64URLencode(libsodium.crypto_box(my_key, their_vk, cek, cek_iv))<ul> <li>Note it this step we're encrypting the cek, so it can be decrypted by the recipient</li> </ul> </li> <li>set <code>sender</code> value to base64URLencode(libsodium.crypto_box_seal(their_vk, sender_vk_string))<ul> <li>Note in this step we're encrypting the sender_verkey to protect sender anonymity</li> </ul> </li> <li>base64URLencode(cek_iv) and set to <code>iv</code> value in the header<ul> <li>Note the cek_iv in the header is used for the <code>encrypted_key</code> where as <code>iv</code> is for ciphertext</li> </ul> </li> </ol> </li> <li>base64URLencode the <code>protected</code> value</li> <li>encrypt the <code>message</code> using libsodium.crypto_aead_chacha20poly1305_ietf_encrypt_detached(message, protected_value_encoded, iv, cek) this is the ciphertext.</li> <li>base64URLencode the iv, ciphertext, and tag then serialize the format into the output format listed above.</li> </ol> <p>For a reference implementation, see https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/commands/crypto.rs</p>"},{"location":"features/0019-encryption-envelope/#pack_message-return-value-anoncrypt-mode","title":"pack_message() return value (Anoncrypt mode)","text":"<p>This is an example of an outputted message encrypted for two verkeys using Anoncrypt.</p> <pre><code>{\n    \"protected\": \"eyJlbmMiOiJ4Y2hhY2hhMjBwb2x5MTMwNV9pZXRmIiwidHlwIjoiSldNLzEuMCIsImFsZyI6IkFub25jcnlwdCIsInJlY2lwaWVudHMiOlt7ImVuY3J5cHRlZF9rZXkiOiJYQ044VjU3UTF0Z2F1TFcxemdqMVdRWlEwV0RWMFF3eUVaRk5Od0Y2RG1pSTQ5Q0s1czU4ZHNWMGRfTlpLLVNNTnFlMGlGWGdYRnZIcG9jOGt1VmlTTV9LNWxycGJNU3RqN0NSUHNrdmJTOD0iLCJoZWFkZXIiOnsia2lkIjoiR0oxU3pvV3phdlFZZk5MOVhrYUpkclFlamZ6dE40WHFkc2lWNGN0M0xYS0wifX0seyJlbmNyeXB0ZWRfa2V5IjoiaG5PZUwwWTl4T3ZjeTVvRmd0ZDFSVm05ZDczLTB1R1dOSkN0RzRsS3N3dlljV3pTbkRsaGJidmppSFVDWDVtTU5ZdWxpbGdDTUZRdmt2clJEbkpJM0U2WmpPMXFSWnVDUXY0eVQtdzZvaUE9IiwiaGVhZGVyIjp7ImtpZCI6IjJHWG11Q04ySkN4U3FNUlZmdEJITHhWSktTTDViWHl6TThEc1B6R3FRb05qIn19XX0=\",\n    \"iv\": \"M1GneQLepxfDbios\",\n    \"ciphertext\": \"iOLSKIxqn_kCZ7Xo7iKQ9rjM4DYqWIM16_vUeb1XDsmFTKjmvjR0u2mWFA48ovX5yVtUd9YKx86rDVDLs1xgz91Q4VLt9dHMOfzqv5DwmAFbbc9Q5wHhFwBvutUx5-lDZJFzoMQHlSAGFSBrvuApDXXt8fs96IJv3PsL145Qt27WLu05nxhkzUZz8lXfERHwAC8FYAjfvN8Fy2UwXTVdHqAOyI5fdKqfvykGs6fV\",\n    \"tag\": \"gL-lfmD-MnNj9Pr6TfzgLA==\"\n}\n</code></pre> <p>The protected data decodes to this:</p> <pre><code>{\n    \"enc\": \"xchacha20poly1305_ietf\",\n    \"typ\": \"JWM/1.0\",\n    \"alg\": \"Anoncrypt\",\n    \"recipients\": [\n        {\n            \"encrypted_key\": \"XCN8V57Q1tgauLW1zgj1WQZQ0WDV0QwyEZFNNwF6DmiI49CK5s58dsV0d_NZK-SMNqe0iFXgXFvHpoc8kuViSM_K5lrpbMStj7CRPskvbS8=\",\n            \"header\": {\n                \"kid\": \"GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL\"\n            }\n        },\n        {\n            \"encrypted_key\": \"hnOeL0Y9xOvcy5oFgtd1RVm9d73-0uGWNJCtG4lKswvYcWzSnDlhbbvjiHUCX5mMNYulilgCMFQvkvrRDnJI3E6ZjO1qRZuCQv4yT-w6oiA=\",\n            \"header\": {\n                \"kid\": \"2GXmuCN2JCxSqMRVftBHLxVJKSL5bXyzM8DsPzGqQoNj\"\n            }\n        }\n    ]\n}\n</code></pre>"},{"location":"features/0019-encryption-envelope/#pack-output-format-anoncrypt-mode","title":"pack output format (Anoncrypt mode)","text":"<pre><code>    {\n         \"protected\": \"b64URLencoded({\n            \"enc\": \"xchachapoly1305_ietf\",\n            \"typ\": \"JWM/1.0\",\n            \"alg\": \"Anoncrypt\",\n            \"recipients\": [\n                {\n                    \"encrypted_key\": base64URLencode(libsodium.crypto_box_seal(their_vk, cek)),\n                    \"header\": {\n                        \"kid\": base58encode(recipient_verkey),\n                    }\n                },\n            ],\n         })\",\n         \"iv\": b64URLencode(iv),\n         \"ciphertext\": b64URLencode(encrypt_detached({'@type'...}, protected_value_encoded, iv, cek),\n         \"tag\": b64URLencode(tag)\n    }\n</code></pre>"},{"location":"features/0019-encryption-envelope/#anoncrypt-pack-algorithm","title":"Anoncrypt pack algorithm","text":"<ol> <li>generate a content encryption key (symmetrical encryption key)</li> <li>encrypt the CEK for each recipient's public key using Anoncrypt (steps below)<ol> <li>set <code>encrypted_key</code> value to base64URLencode(libsodium.crypto_box_seal(their_vk, cek))<ul> <li>Note it this step we're encrypting the cek, so it can be decrypted by the recipient</li> </ul> </li> </ol> </li> <li>base64URLencode the <code>protected</code> value</li> <li>encrypt the message using libsodium.crypto_aead_chacha20poly1305_ietf_encrypt_detached(message, protected_value_encoded, iv, cek) this is the ciphertext.</li> <li>base64URLencode the iv, ciphertext, and tag then serialize the format into the output format listed above.</li> </ol> <p>For a reference implementation, see https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/commands/crypto.rs</p>"},{"location":"features/0019-encryption-envelope/#unpack-message","title":"Unpack Message","text":""},{"location":"features/0019-encryption-envelope/#unpack_message-interface","title":"unpack_message() interface","text":"<p>unpacked_message = unpack_message(wallet_handle, jwe)</p>"},{"location":"features/0019-encryption-envelope/#unpack_message-params","title":"unpack_message() Params","text":"<ul> <li>wallet_handle: wallet handle that contains the sender_verkey</li> <li>jwe: a message which was returned from a pack_message() and follows the scheme format described below</li> </ul>"},{"location":"features/0019-encryption-envelope/#unpack-algorithm","title":"Unpack Algorithm","text":"<ol> <li>seralize data, so it can be used<ul> <li>For example, in rust-lang this has to be seralized as a struct.</li> </ul> </li> <li>Lookup the <code>kid</code> for each recipient in the wallet to see if the wallet possesses a private key associated with the public key listed</li> <li>Check if a <code>sender</code> field is used.<ul> <li>If a sender is included use auth_decrypt to decrypt the <code>encrypted_key</code> by doing the following:<ol> <li>decrypt sender verkey using libsodium.crypto_box_seal_open(my_private_key, base64URLdecode(sender))</li> <li>decrypt cek using libsodium.crypto_box_open(my_private_key, sender_verkey, encrypted_key, cek_iv)</li> <li>decrypt ciphertext using libsodium.crypto_aead_chacha20poly1305_ietf_open_detached(base64URLdecode(ciphertext_bytes), base64URLdecode(protected_data_as_bytes), base64URLdecode(nonce), cek)</li> <li>return <code>message</code>, <code>recipient_verkey</code> and <code>sender_verkey</code> following the authcrypt format listed below</li> </ol> </li> <li>If a sender is NOT included use anon_decrypt to decrypt the <code>encrypted_key</code> by doing the following:<ol> <li>decrypt <code>encrypted_key</code> using libsodium.crypto_box_seal_open(my_private_key, encrypted_key)</li> <li>decrypt ciphertext using libsodium.crypto_aead_chacha20poly1305_ietf_open_detached(base64URLdecode(ciphertext_bytes), base64URLdecode(protected_data_as_bytes), base64URLdecode(nonce), cek)</li> <li>return <code>message</code> and <code>recipient_verkey</code> following the anoncrypt format listed below</li> </ol> </li> </ul> </li> </ol> <p>NOTE: In the unpack algorithm, the base64url decode implementation used MUST correctly decode padded and unpadded base64URL encoded data.</p> <p>For a reference unpack implementation, see https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/commands/crypto.rs</p>"},{"location":"features/0019-encryption-envelope/#unpack_message-return-values-authcrypt-mode","title":"unpack_message() return values (authcrypt mode)","text":"<pre><code>{\n    \"message\": \"{ \\\"@id\\\": \\\"123456780\\\",\\\"@type\\\":\\\"https://didcomm.org/basicmessage/1.0/message\\\",\\\"sent_time\\\": \\\"2019-01-15 18:42:01Z\\\",\\\"content\\\": \\\"Your hovercraft is full of eels.\\\"}\",\n    \"recipient_verkey\": \"HKTAiYM8cE2kKC9KaNMZLYj4GS8uWCYMBxP2i1Y92zum\",\n    \"sender_verkey\": \"DWwLsbKCRAbYtfYnQNmzfKV7ofVhMBi6T4o3d2SCxVuX\"\n}\n</code></pre>"},{"location":"features/0019-encryption-envelope/#unpack_message-return-values-anoncrypt-mode","title":"unpack_message() return values (anoncrypt mode)","text":"<pre><code>{\n    \"message\": \"{ \\\"@id\\\": \\\"123456780\\\",\\\"@type\\\":\\\"https://didcomm.org/basicmessage/1.0/message\\\",\\\"sent_time\\\": \\\"2019-01-15 18:42:01Z\\\",\\\"content\\\": \\\"Your hovercraft is full of eels.\\\"}\",\n    \"recipient_verkey\": \"2GXmuCN2JCxSqMRVftBHLxVJKSL5bXyzM8DsPzGqQoNj\"\n}\n</code></pre>"},{"location":"features/0019-encryption-envelope/#additional-notes","title":"Additional Notes","text":"<ul> <li> <p>All <code>kid</code> values used currently are base58 encoded ed25519 keys. If other keys types are used, say secp256k1, base58 encoding should also be used here for interoperability.</p> </li> <li> <p>All algorithm APIs which use libsodium are from sodiumoxide rust wrapping of the original C implementation.</p> </li> </ul>"},{"location":"features/0019-encryption-envelope/#drawbacks","title":"Drawbacks","text":"<p>The current implementation of the <code>pack()</code> message is currently Hyperledger Aries specific. It is based on common crypto libraries (NaCl), but the wrappers are not commonly used outside of Aries. There's currently work being done to fine alignment on a cross-ecosystem interoperable protocol, but this hasn't been achieved yet. This work will hopefully bridge this gap.</p>"},{"location":"features/0019-encryption-envelope/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>As the JWE standard currently stands, it does not follow this format. We're actively working with the lead writer of the JWE spec to find alignment and are hopeful the changes needed can be added.</p> <p>We've also looked at using the Message Layer Security (MLS) specification. This specification shows promise for adoption later on with more maturity. Additionally because they aren't hiding metadata related to the sender (Sender Anonymity), we would need to see some changes made to the specification before we could adopt this spec.</p>"},{"location":"features/0019-encryption-envelope/#prior-art","title":"Prior art","text":"<p>The JWE family of encryption methods.</p>"},{"location":"features/0019-encryption-envelope/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>How transport protocols (https, zmq, etc.) will be be used to send Encrypted Envelopes?<ul> <li>These will need to be defined using separate RFCs. For example, HTTP might POST a message and place it in the body of the HTTP POST.</li> </ul> </li> <li>How will the encrypted envelopes work with routing tables to pass a message through a domain, potentially over various transport protocols?<ul> <li>There's not much certainty whether routing tables or some other mechanism will be used. This needs to be defined in another RFC.</li> </ul> </li> <li>If the encryption envelope protocol fails, how is that failure passed back to those involved in the transmission?<ul> <li>This should be handled using the Report Problem Protocol which is currently demonstrated RFC #35 by Stephen Curran.</li> </ul> </li> </ul>"},{"location":"features/0019-encryption-envelope/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community Aries Framework - .NET .NET framework for building agents of all types Streetcred.id Commercial mobile and web app built using Aries Framework - .NET Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Aries Framework - Go For building agents, hubs and other DIDComm ../../features in GoLang. Aries Protocol Test Suite"},{"location":"features/0019-encryption-envelope/schema/","title":"Schema","text":"<p>This spec is according JSON Schema v0.7 <pre><code>{\n    \"id\": \"https://github.com/hyperledger/indy-agent/wiremessage.json\",\n    \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n    \"title\": \"Json Web Message format\",\n    \"type\": \"object\",\n    \"required\": [\"ciphertext\", \"iv\", \"protected\", \"tag\"],\n    \"properties\": {\n        \"protected\": {\n            \"type\": \"object\",\n            \"description\": \"Additional authenticated message data base64URL encoded, so it can be verified by the recipient using the tag\",\n            \"required\": [\"enc\", \"typ\", \"alg\", \"recipients\"],\n            \"properties\": {\n                \"enc\": {\n                    \"type\": \"string\",\n                    \"enum\": [\"xchacha20poly1305_ietf\"],\n                    \"description\": \"The authenticated encryption algorithm used to encrypt the ciphertext\"\n                },\n                \"typ\": { \n                    \"type\": \"string\",\n                    \"description\": \"The message type. Ex: JWM/1.0\"\n                },\n                \"alg\": {\n                    \"type\": \"string\",\n                    \"enum\": [ \"authcrypt\", \"anoncrypt\"]\n                },\n                \"recipients\": {\n                    \"type\": \"array\",\n                    \"description\": \"A list of the recipients who the message is encrypted for\",\n                    \"items\": {\n                        \"type\": \"object\",\n                        \"required\": [\"encrypted_key\", \"header\"],\n                        \"properties\": {\n                            \"encrypted_key\": {\n                                \"type\": \"string\",\n                                \"description\": \"The key used for encrypting the ciphertext. This is also referred to as a cek\"\n                            },\n                            \"header\": {\n                                \"type\": \"object\",\n                                \"required\": [\"kid\"],\n                                \"description\": \"The recipient to whom this message will be sent\",\n                                \"properties\": {\n                                    \"kid\": {\n                                        \"type\": \"string\",\n                                        \"description\": \"base58 encoded verkey of the recipient.\"\n                                    }\n                                }\n                            }\n                        }\n                    }\n                 },     \n            },\n        },\n        \"iv\": {\n            \"type\": \"string\",\n            \"description\": \"base64 URL encoded nonce used to encrypt ciphertext\"\n        },\n        \"ciphertext\": {\n            \"type\": \"string\",\n            \"description\": \"base64 URL encoded authenticated encrypted message\"\n        },\n        \"tag\": {\n            \"type\": \"string\",\n            \"description\": \"Integrity checksum/tag base64URL encoded to check ciphertext, protected, and iv\"\n        }\n    }\n}\n</code></pre></p>"},{"location":"features/0023-did-exchange/","title":"Aries RFC 0023: DID Exchange v1","text":"<ul> <li>Authors: Ryan West, Daniel Bluhm, Matthew Hailstone, Sam Curren, Stephen Curran, George Aristy</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Replaces RFC 0160 - Connection Protocol and is a part of AIP 2.0.</li> <li>Supersedes: RFC 0160 - Connection Protocol</li> <li>Start Date: 2018-06-29</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"features/0023-did-exchange/#summary","title":"Summary","text":"<p>This RFC describes the protocol to exchange DIDs between agents when establishing a DID based relationship.</p>"},{"location":"features/0023-did-exchange/#motivation","title":"Motivation","text":"<p>Aries agent developers want to create agents that are able to establish relationships with each other and exchange secure information using keys and endpoints in DID Documents. For this to happen there must be a clear protocol to exchange DIDs.</p>"},{"location":"features/0023-did-exchange/#version-change-log","title":"Version Change Log","text":""},{"location":"features/0023-did-exchange/#version-11-signed-rotations-without-did-documents","title":"Version 1.1 -  Signed Rotations without DID Documents","text":"<p>Added the optional <code>did_rotate~attach</code> attachment for provenance of rotation without an attached DID Document.</p>"},{"location":"features/0023-did-exchange/#tutorial","title":"Tutorial","text":"<p>We will explain how DIDs are exchanged, with the roles, states, and messages required.</p>"},{"location":"features/0023-did-exchange/#roles","title":"Roles","text":"<p>The DID Exchange Protocol uses two roles: requester and responder.</p> <p>The requester is the party that initiates this protocol after receiving an <code>invitation</code> message (using RFC 0434 Out of Band) or by using an implied invitation from a public DID. For example, a verifier might get the DID of the issuer of a credential they are verifying, and use information in the DIDDoc for that DID as the basis for initiating an instance of this protocol.</p> <p>Since the requester receiving an explicit invitation may not have an Aries agent, it is desirable, but not strictly, required that sender of the invitation (who has the responder role in this protocol) have the ability to help the requester with the process and/or costs associated with acquiring an agent capable of participating in the ecosystem. For example, the sender of an invitation may often be sponsoring institutions.</p> <p>The responder, who is the sender of an explicit invitation or the publisher of a DID with an implicit invitation, must have an agent capable of interacting with other agents via DIDComm.</p> <p>In cases where both parties already possess SSI capabilities, deciding who plays the role of requester and responder  might be a casual matter of whose phone is handier.</p>"},{"location":"features/0023-did-exchange/#states","title":"States","text":""},{"location":"features/0023-did-exchange/#requester","title":"Requester","text":"<p>The requester goes through the following states per the State Machine Tables below</p> <ul> <li>start</li> <li>invitation-received</li> <li>request-sent</li> <li>response-received</li> <li>abandoned</li> <li>completed</li> </ul>"},{"location":"features/0023-did-exchange/#responder","title":"Responder","text":"<p>The responder goes through the following states per the State Machine Tables below</p> <ul> <li>start</li> <li>invitation-sent</li> <li>request-received</li> <li>response-sent</li> <li>abandoned</li> <li>completed</li> </ul>"},{"location":"features/0023-did-exchange/#state-machine-tables","title":"State Machine Tables","text":"<p>The following are the requester and responder state machines.</p> <p>The <code>invitation-sent</code> and <code>invitation-received</code> are technically outside this protocol, but are useful to show in the state machine as the invitation is the trigger to start the protocol and is referenced from the protocol as the parent thread (<code>pthid</code>).  This is discussed in more detail below.</p> <p>The <code>abandoned</code> and <code>completed</code> states are terminal states and there is no expectation that the protocol can be continued (or even referenced) after reaching those states.</p> <p></p>"},{"location":"features/0023-did-exchange/#errors","title":"Errors","text":"<p>After receiving an explicit invitation, the requester may send a <code>problem-report</code> to the responder using the information in the invitation to either restart the invitation process (returning to the <code>start</code> state) or to abandon the protocol. The <code>problem-report</code> may be an adopted  <code>Out of Band</code> protocol message or an adopted <code>DID Exchange</code> protocol message, depending on where in the processing of the invitation the error was detected.</p> <p>During the <code>request</code> / <code>response</code> part of the protocol, there are two protocol-specific error messages possible: one for an active rejection and one for an unknown error. These errors are sent using a problem_report message type specific to the DID Exchange Protocol. These errors do not transition the protocol to the <code>abandoned</code> state. The following list details <code>problem-code</code>s that may be sent in these cases:</p> <p>request_not_accepted - The error indicates that the <code>request</code> message has been rejected for a reason listed in the <code>error_report</code>. Typical reasons include not accepting the method of the provided DID, unknown endpoint protocols, etc. The <code>request</code> can be resent after the appropriate corrections have been made.</p> <p>request_processing_error - This error is sent when the responder was processing the request with the intent to accept the request, but some processing error occurred. This error indicates that the <code>request</code> should be resent as-is.</p> <p>response_not_accepted - The error indicates that the <code>response</code> has been rejected for a reason listed in the <code>error_report</code>. Typical reasons include not accepting the method of the provided DID, unknown endpoint protocols, invalid signature, etc. The <code>response</code> can be resent after the appropriate corrections have been made.</p> <p>response_processing_error - This error is sent when the requester was processing the <code>response</code> with the intent to accept the response, but some processing error occurred. This error indicates that the <code>response</code> should be resent as-is.</p> <p>If other errors occur, the corresponding party may send a <code>problem-report</code> to inform the other party they are abandoning the protocol.</p> <p>No errors are sent in timeout situations. If the requester or responder wishes to retract the messages they sent, they record so locally and return a <code>request_not_accepted</code> or <code>response_not_accepted</code> error when the other party sends a <code>request</code> or <code>response</code>.</p>"},{"location":"features/0023-did-exchange/#error-message-example","title":"Error Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/didexchange/1.1/problem_report\",\n  \"@id\": \"5678876542345\",\n  \"~thread\": { \"thid\": \"&lt;@id of message related to problem&gt;\" },\n  \"~l10n\": { \"locale\": \"en\"},\n  \"problem-code\": \"request_not_accepted\", // matches codes listed above\n  \"explain\": \"Unsupported DID method for provided DID.\"\n}\n</code></pre>"},{"location":"features/0023-did-exchange/#error-message-attributes","title":"Error Message Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is a problem_report within the didexchange protocol.</li> <li>The <code>~thread</code> attribute provides a context for the problem, referring to the message which contains the problem.</li> <li>Use of <code>~l10n</code> is encouraged, with at least locale defined for the message.</li> <li>The <code>problem-code</code> attribute contains one of a fixed set of codes defined in the list above.</li> <li>The <code>explain</code> attribute contains a human readable message which indicates the problem.</li> </ul>"},{"location":"features/0023-did-exchange/#flow-overview","title":"Flow Overview","text":"<ul> <li>The responder gives provisional information to the requester using an explicit <code>invitation</code> message from the <code>out-of-band</code> protocol or an implicit invitation in a DID the responder publishes.</li> <li>In the <code>out-of-band</code> protocol, the responder is called the sender, and the requester is called the receiver.</li> <li>The requester uses the provisional information to send a DID and DID Doc to the responder in a <code>request</code> message.</li> <li>The responder uses sent DID Doc information to send a DID and DID Doc to the requester in a <code>response</code> message.</li> <li>The requester sends the responder a <code>complete</code> message that confirms the <code>response</code> message was received.</li> </ul>"},{"location":"features/0023-did-exchange/#implicit-and-explicit-invitations","title":"Implicit and Explicit Invitations","text":"<p>The DID Exchange Protocol is preceded by  - either knowledge of a resolvable DID (an implicit invitation)  - or by a <code>out-of-band/%VER/invitation</code> message from the Out Of Band Protocols RFC. </p> <p>The information needed to construct the <code>request</code> message to start the protocol is used - either from the resolved DID Document  - or the <code>service</code> element of the <code>handshake_protocols</code> attribute of the <code>invitation</code>.</p>"},{"location":"features/0023-did-exchange/#1-exchange-request","title":"1. Exchange Request","text":"<p>The <code>request</code> message is used to communicate the DID document of the requester to the responder using the provisional service information present in the (implicit or explicit) invitation.</p> <p>The requester may provision a new DID according to the DID method spec. For a Peer DID, this involves creating a matching peer DID and key. The newly provisioned DID and DID Doc is presented in the <code>request</code> message as follows:</p>"},{"location":"features/0023-did-exchange/#request-message-example","title":"Request Message Example","text":"<pre><code>{\n  \"@id\": \"5678876542345\",\n  \"@type\": \"https://didcomm.org/didexchange/1.1/request\",\n  \"~thread\": { \n      \"thid\": \"5678876542345\",\n      \"pthid\": \"&lt;id of invitation&gt;\"\n  },\n  \"label\": \"Bob\",\n  \"goal_code\": \"aries.rel.build\",\n  \"goal\": \"To create a relationship\",\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n      \"@id\": \"d2ab6f2b-5646-4de3-8c02-762f553ab804\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n         \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n         \"jws\": {\n            \"header\": {\n               \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n            },\n            \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n            \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n            }\n      }\n   }\n}\n</code></pre>"},{"location":"features/0023-did-exchange/#request-message-attributes","title":"Request Message Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is an exchange request.</li> <li>The <code>~thread</code> decorator MUST be included:</li> <li>It MUST include the ID of the parent thread (<code>pthid</code>) such that the <code>request</code> can be correlated to the corresponding (implicit or explicit) <code>invitation</code>. More on correlation below.</li> <li>It MAY include the <code>thid</code> property. This works according to the <code>thid</code> property in the thread decorator, meaning that if <code>thid</code> is not defined it is implicitly defined as the <code>@id</code> on the same <code>request</code> message.</li> <li>The <code>label</code> attribute provides a suggested label for the DID being exchanged. This allows the user to tell multiple exchange requests apart. This is not a trusted attribute. (See note on <code>label</code> below)</li> <li>The <code>goal_code</code> (optional) is a self-attested code the receiver may want to display to the user or use in automatically deciding what to do with the request message. The goal code might be used particularly when the request is sent to a resolvable DID without reference to a specfic invitation.</li> <li>The goal (optional) is a self-attested string that the receiver may want to display to the user about the context-specific goal of the request message.</li> <li>The <code>did</code> attribute MUST be included. It indicates the DID being exchanged.</li> <li>The <code>did_doc~attach</code> (optional), contains the DIDDoc associated with the <code>did</code>, if required.</li> <li>If the <code>did</code> is resolvable (either an inline <code>peer:did</code> or a publicly resolvable DID), the <code>did_doc~attach</code> attribute should not be included.</li> <li>If the DID is a <code>did:peer</code> DID, the DIDDoc must be as outlined in RFC 0627 Static Peer DIDs.</li> </ul> <p>The <code>label</code> property was intended to be declared as an optional property, but was added to the RFC as a required property. If an agent wishes to not use a label in the request, an empty string (<code>\"\"</code>) or the set value <code>Unspecified</code> may be used to indicate a non-value. This approach ensures existing AIP 2.0 implementations do not break.</p>"},{"location":"features/0023-did-exchange/#correlating-requests-to-invitations","title":"Correlating requests to invitations","text":"<p>An invitation is presented in one of two forms:</p> <ul> <li>An explicit out-of-band invitation with its own <code>@id</code>.</li> <li>An implicit invitation contained in a DID document's <code>service</code> attribute that conforms to the DIDComm conventions.</li> </ul> <p>When a <code>request</code> responds to an explicit invitation, its <code>~thread.pthid</code> MUST be equal to the <code>@id</code> property of the invitation as described in the out-of-band RFC.</p> <p>When a <code>request</code> responds to an implicit invitation, its <code>~thread.pthid</code> MUST contain a DID URL that resolves to the specific <code>service</code> on a DID document that contains the invitation.</p>"},{"location":"features/0023-did-exchange/#example-referencing-an-explicit-invitation","title":"Example Referencing an Explicit Invitation","text":"<pre><code>{\n  \"@id\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n  \"@type\": \"https://didcomm.org/didexchange/1.1/request\",\n  \"~thread\": { \n      \"thid\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n      \"pthid\": \"032fbd19-f6fd-48c5-9197-ba9a47040470\" \n  },\n  \"label\": \"Bob\",\n  \"goal_code\": \"aries.rel.build\",\n  \"goal\": \"To create a relationship\",\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n      \"@id\": \"d2ab6f2b-5646-4de3-8c02-762f553ab804\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n         \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n         \"jws\": {\n            \"header\": {\n               \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n            },\n            \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n            \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n            }\n      }\n   }\n}\n</code></pre>"},{"location":"features/0023-did-exchange/#example-referencing-an-implicit-invitation","title":"Example Referencing an Implicit Invitation","text":"<pre><code>{\n  \"@id\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n  \"@type\": \"https://didcomm.org/didexchange/1.1/request\",\n  \"~thread\": { \n      \"thid\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n      \"pthid\": \"did:example:21tDAKCERh95uGgKbJNHYp#didcomm\" \n  },\n  \"label\": \"Bob\",\n  \"goal_code\": \"aries.rel.build\",\n  \"goal\": \"To create a relationship\",\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n      \"@id\": \"d2ab6f2b-5646-4de3-8c02-762f553ab804\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n         \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n         \"jws\": {\n            \"header\": {\n               \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n            },\n            \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n            \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n            }\n      }\n   }\n}\n</code></pre>"},{"location":"features/0023-did-exchange/#request-transmission","title":"Request Transmission","text":"<p>The <code>request</code> message is encoded according to the standards of the Encryption Envelope, using the <code>recipientKeys</code> present in the invitation.</p> <p>If the <code>routingKeys</code> attribute was present and non-empty in the invitation, each key must be used to wrap the message in a forward request, then encoded in an Encryption Envelope. This processing is in order of the keys in the list, with the last key in the list being the one for which the <code>serviceEndpoint</code> possesses the private key.</p> <p>The message is then transmitted to the <code>serviceEndpoint</code>.</p> <p>The requester is in the <code>request-sent</code> state. When received, the responder is in the <code>request-received</code> state.</p>"},{"location":"features/0023-did-exchange/#request-processing","title":"Request processing","text":"<p>After receiving the exchange request, the responder evaluates the provided DID and DID Doc according to the DID Method Spec.</p> <p>The responder should check the information presented with the keys used in the wire-level message transmission to ensure they match.</p> <p>The responder MAY look up the corresponding invitation identified in the request's <code>~thread.pthid</code> to determine whether it should accept this exchange request.</p> <p>If the responder wishes to continue the exchange, they will persist the received information in their wallet. They will then either update the provisional service information to rotate the key, or provision a new DID entirely. The choice here will depend on the nature of the DID used in the invitation.</p> <p>The responder will then craft an exchange response using the newly updated or provisioned information.</p>"},{"location":"features/0023-did-exchange/#request-errors","title":"Request Errors","text":"<p>See Error Section above for message format details.</p>"},{"location":"features/0023-did-exchange/#request-rejected","title":"Request Rejected","text":"<p>Possible reasons:</p> <ul> <li>Unsupported DID method for provided DID</li> <li>Expired Invitation</li> <li>DID Doc Invalid</li> <li>Unsupported key type</li> <li>Unsupported endpoint protocol</li> <li>Missing reference to invitation</li> </ul>"},{"location":"features/0023-did-exchange/#request-processing-error","title":"Request Processing Error","text":"<ul> <li>unknown processing error</li> </ul>"},{"location":"features/0023-did-exchange/#2-exchange-response","title":"2. Exchange Response","text":"<p>The exchange response message is used to complete the exchange. This message is required in the flow, as it updates the provisional information presented in the invitation.</p>"},{"location":"features/0023-did-exchange/#response-message-example","title":"Response Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/didexchange/1.1/response\",\n  \"@id\": \"12345678900987654321\",\n  \"~thread\": {\n    \"thid\": \"&lt;The Thread ID is the Message ID (@id) of the first message in the thread&gt;\"\n  },\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n      \"@id\": \"d2ab6f2b-5646-4de3-8c02-762f553ab804\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n         \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n         \"jws\": {\n            \"header\": {\n               \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n            },\n            \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n            \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n            }\n      }\n   },\n   \"did_rotate~attach\": {\n      \"mime-type\": \"text/string\",\n      \"data\": {\n         \"base64\": \"Qi5kaWRAQjpB\",\n         \"jws\": {\n         \"header\": {\n            \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n         },\n         \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n         \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n         }\n      }\n   }\n}\n</code></pre> <p>The invitation's <code>recipientKeys</code> should be dedicated to envelopes authenticated encryption throughout the exchange. These keys are usually defined in the <code>KeyAgreement</code> DID verification relationship.</p>"},{"location":"features/0023-did-exchange/#response-message-attributes","title":"Response Message Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is an exchange request.</li> <li>The <code>~thread</code> decorator MUST be included. It contains a <code>thid</code> reference to the <code>@id</code> of the request message.</li> <li>The <code>did</code> attribute MUST be included. It denotes the DID in use by the responder. Note that this MAY NOT be the same DID used in the invitation.</li> <li>The <code>did_doc~attach</code> optional, contains the DID Doc associated with the <code>did</code>, if required.</li> <li>If the <code>did</code> is resolvable (either an inline <code>did:peer</code> or a publicly resolvable DID), the <code>did_doc~attach</code> attribute should not be included.</li> <li>If the DID is a <code>did:peer</code> identifier, the DIDDoc must be as outlined in RFC 0627 Static Peer DIDs.</li> <li>The <code>did_rotate~attach</code> attribute is optional, but SHOULD be included if the <code>did</code> attribute is resolvable and the <code>did_doc~attach</code> is not included. The value is the Base64url encoded DID, and signed with the key used in the invitation.</li> </ul> <p>In addition to a new DID, the associated DID Doc might contain a new endpoint. This new DID and endpoint are to be used going forward in the relationship.</p>"},{"location":"features/0023-did-exchange/#response-transmission","title":"Response Transmission","text":"<p>The message should be packaged in the encrypted envelope format, using the keys from the request, and the new keys presented in the internal did doc.</p> <p>When the message is sent, the responder are now in the <code>response-sent</code> state. On receipt, the requester is in the <code>response-received</code> state.</p>"},{"location":"features/0023-did-exchange/#response-processing","title":"Response Processing","text":"<p>When the requester receives the <code>response</code> message, they will decrypt the authenticated envelope which confirms the source's authenticity. After decryption validation, the signature on the <code>did_doc~attach</code> or <code>did_rotate~attach</code> MUST be validated, if present. The key used in the signature MUST match the key used in the invitation. After attachment signature validation, they will update their wallet with the new information, and use that information in sending the <code>complete</code> message.</p>"},{"location":"features/0023-did-exchange/#response-errors","title":"Response Errors","text":"<p>See Error Section above for message format details.</p>"},{"location":"features/0023-did-exchange/#response-rejected","title":"Response Rejected","text":"<p>Possible reasons:</p> <ul> <li>unsupported DID method for provided DID</li> <li>Expired Request</li> <li>DID Doc Invalid</li> <li>Unsupported key type</li> <li>Unsupported endpoint protocol</li> <li>Invalid Signature</li> </ul>"},{"location":"features/0023-did-exchange/#response-processing-error","title":"Response Processing Error","text":"<ul> <li>unknown processing error</li> </ul>"},{"location":"features/0023-did-exchange/#3-exchange-complete","title":"3. Exchange Complete","text":"<p>The exchange <code>complete</code> message is used to confirm the exchange to the responder. This message is required in the flow, as it marks the exchange complete. The responder may then invoke any protocols desired based on the context expressed via the <code>pthid</code> in the DID Exchange protocol.</p>"},{"location":"features/0023-did-exchange/#complete-message-example","title":"Complete Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/didexchange/1.1/complete\",\n  \"@id\": \"12345678900987654321\",\n  \"~thread\": {\n    \"thid\": \"&lt;The Thread ID is the Message ID (@id) of the first message in the thread&gt;\",\n    \"pthid\": \"&lt;pthid used in request message&gt;\"\n  }\n}\n</code></pre> <p>The <code>pthid</code> is required in this message, and must be identical to the <code>pthid</code> used in the <code>request</code> message.</p> <p>After a <code>complete</code> message is sent, the requester is in the <code>completed</code> terminal state. Receipt of the message puts the responder into the <code>completed</code> state.</p>"},{"location":"features/0023-did-exchange/#complete-errors","title":"Complete Errors","text":"<p>See Error Section above for message format details.</p>"},{"location":"features/0023-did-exchange/#complete-rejected","title":"Complete Rejected","text":"<p>This is unlikely to occur with other than an unknown processing error (covered below), so no possible reasons are listed. As experience is gained with the protocol, possible reasons may be added.</p>"},{"location":"features/0023-did-exchange/#complete-processing-error","title":"Complete Processing Error","text":"<ul> <li>unknown processing error</li> </ul>"},{"location":"features/0023-did-exchange/#next-steps","title":"Next Steps","text":"<p>The exchange between the requester and the responder has been completed. This relationship has no trust associated with it. The next step should be to increase the trust to a sufficient level for the purpose of the relationship, such as through an exchange of proofs.</p>"},{"location":"features/0023-did-exchange/#peer-did-maintenance","title":"Peer DID Maintenance","text":"<p>When Peer DIDs are used in an exchange, it is likely that both the requester and responder will want to perform some relationship maintenance such as key rotations. Future RFC updates will add these maintenance ../../features.</p>"},{"location":"features/0023-did-exchange/#reference","title":"Reference","text":"<ul> <li>https://docs.google.com/document/d/1mRLPOK4VmU9YYdxHJSxgqBp19gNh3fT7Qk4Q069VPY8/edit#heading=h.7sxkr7hbou5i</li> <li>Agent to Agent Communication Video</li> <li>Agent to Agent Communication Presentation</li> <li>Problem_report message adopted into message family, following form defined by the Problem Report HIPE</li> <li>RFC0519 Goal Codes</li> </ul>"},{"location":"features/0023-did-exchange/#drawbacks","title":"Drawbacks","text":"<p>N/A at this time</p>"},{"location":"features/0023-did-exchange/#prior-art","title":"Prior art","text":"<ul> <li>This process is similar to other key exchange protocols.</li> </ul>"},{"location":"features/0023-did-exchange/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>N/A at this time</li> </ul>"},{"location":"features/0023-did-exchange/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Trinsic.id Commercial mobile and web app built using Aries Framework - .NET MISSING test results"},{"location":"features/0024-didcomm-over-xmpp/","title":"Aries RFC 0024: DIDComm over XMPP","text":"<ul> <li>Authors: Oskar van Deventer, Galit Rahim, Alexander Blom</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes: Indy DIDComm-over-XMPP</li> <li>Start Date: 2019-04-23</li> <li>Tags: feature</li> </ul>"},{"location":"features/0024-didcomm-over-xmpp/#summary","title":"Summary","text":"<p>While DIDComm leaves its users free to choose any underlying communication protocol, for peer-to-peer DID relationships with one or both parties behind a firewall actually getting the messages to the other party is not straightforward.</p> <p>Fortunately this is a classical problem, encountered by all realtime communication protocols, and it is therefore natural to use one of these protocols to deal with the obstacles posed by firewalls. The DIDComm-over-XMPP feature provides an architecture to exchange DIDComm connection protocol messages over XMPP, using XMPP to solve any firewall issues.</p> <p>DIDComm-over-XMPP enables:</p> <ul> <li>Initiation, use, maintenance and termination of a trusted electronic relationship</li> <li>DIDComm agents being available for incoming DIDComm messages despite being behind a firewall</li> <li>Binding of that relationship to a human-to-human communication channel</li> </ul> <p>and all of this in spite of the presence of firewalls.</p> <p>Editor's note: A reference should be added to Propose HIPE: Transports  #94</p>"},{"location":"features/0024-didcomm-over-xmpp/#motivation","title":"Motivation","text":"<p>Currently, all examples of service endpoint in the W3C DID specification use HTTP. This assumes that the endpoint is running an HTTP server and firewalls have been opened to allow this traffic to pass through. This assumption typically fails for DIDComm agents behind LAN firewalls or using cellular networks. As a consequence, such DIDComm agents can be expected to be unavailable for incoming DIDComm messages, whereas several use cases require this. The following is an example of this.</p> <p>A consumer contacts a customer service agent of his health insurance company, and is subsequently asked for proof of identity before getting answers to his personal health related questions. DIDcom could be of use here, replacing privacy sensitive and time consuming questions in order to establish the consumers' identity with an exchange of verifiable credentials using DIDcom.  In that case, the agent would just send a DIDComm message to the caller to link the ongoing human-to-human communication session to a DIDComm agent-to-agent communication session. The DIDComm connection protocol would then enable the setting up and maintenance of a trusted electronic relationship, to be used to exchange verifiable credentials. Replace insurance company with any sizeable business to consumer company and one realizes that this use case is far from insignificant.</p> <p>Unfortunately, by itself, the parties DIDcom agents will be unable to bypass the firewalls involved and exchange DIDcom messages. Therefore XMPP is called to the rescue to serve as the transport protocol which is capable with firewalls. Once the firewalls issue is solved, DIDcom can be put to use in all of these cases.</p> <p>The XMPP protocol is a popular protocol for chat and messaging. It has a client-server structure that bypasses any firewall issues.</p>"},{"location":"features/0024-didcomm-over-xmpp/#tutorial","title":"Tutorial","text":"<p>The DIDComm-over-XMPP feature provides an architecture for the transport of DIDComm messages over an XMPP network, using XMPP to bypass any firewalls at the receiving side.</p>"},{"location":"features/0024-didcomm-over-xmpp/#didcomm","title":"DIDComm","text":"<p>The DIDComm wire message format is specified in HIPE 0028-wire-message-format. It can carry among others the DIDComm connection protocol, as specified in Hyperledger Indy Hipe 0031. The purpose of the latter protocol is to set up a trusted electronic relationship between two parties (natural person, legal person, ...). Technically, the trust relationship involves the following</p> <ul> <li>Univocal identification of the parties within the context of the relationship</li> <li>Secure exchange of keys to encrypt and verify messages between agents of the parties</li> <li>Secure exchange of service end points to be reachable at in the future</li> <li>Secure exchange of verifiable credentials and other messages that require secure exchange</li> </ul> <p>W3C specifies Data Model and Syntaxes for Decentralized Identifiers (DIDs). This specification introduces Decentralized Identifiers, DIDs, for identification. A DID can be resolved into a DID Document that contains the associated keys and service endpoints, see also W3C's A Primer for Decentralized Identifiers. W3C provides a DID Method Registry for a complete list of all known DID Method specifications. Many of the DID methods use an unambiguous source of truth to resolve a DID Document, e.g. a well governed public blockchain. An exception is the Peer DID method that relies on the peers, i.e. parties in the trusted electronic relationship to maintain the DID Document.</p>"},{"location":"features/0024-didcomm-over-xmpp/#xmpp","title":"XMPP","text":"<p>Extensible Messaging and Presence Protocol (XMPP) is a communication protocol for message-oriented middleware based on XML (Extensible Markup Language). It enables the near-real-time exchange of structured yet extensible data between any two or more network entities. Designed to be extensible, the protocol has been used also for publish-subscribe systems, signalling for VoIP, video, file transfer, gaming, the Internet of Things applications such as the smart grid, and social networking services.</p> <p>Unlike most instant messaging protocols, XMPP is defined in an open standard and uses an open systems approach of development and application, by which anyone may implement an XMPP service and interoperate with other organizations' implementations. Because XMPP is an open protocol, implementations can be developed using any software license and many server, client, and library implementations are distributed as free and open-source software. Numerous freeware and commercial software implementations also exist.</p> <p>XMPP uses 3 types of messages:</p> Message Type Description PRESENSE Inform listeners that agent is online MESSAGE Sending message to other agent IQ MESSAGE Asking for response from other agent <p></p>"},{"location":"features/0024-didcomm-over-xmpp/#didcomm-over-xmpp","title":"DIDComm over XMPP","text":""},{"location":"features/0024-didcomm-over-xmpp/#use-of-message-normative","title":"Use of MESSAGE (normative)","text":"<p>A DIDComm wire message shall be sent send as plaintext XMPP MESSAGE, without any additional identifiers.</p>"},{"location":"features/0024-didcomm-over-xmpp/#service-endpoint-normative","title":"Service endpoint (normative)","text":"<p>A DIDComm-over-XMPP service shall comply to the following.</p> <ol> <li>The id shall have a DID fragment \"#xmpp\".</li> <li>The type shall be \"XmppService\".</li> <li>The serviceEndpoint</li> <li>shall not have a resource part (i.e. \"/...resource...\")</li> <li>shall comply to the following ABNF.</li> </ol> <pre><code>xmpp-service-endpoint = \"xmpp:\" userpart \"@did.\" domainpart\n  userpart = 1\\*CHAR\n  domainpart = 1\\*CHAR 1\\*(\".\" 1\\*char)\n  CHAR = %x01-7F\n</code></pre> <p>The reason for not allowing a resources part is that DIDComm messages are addressed to the person/entity associated with the DID, and not to any particular device.</p> <p>A receiving XMPP client shall identify an incoming XMPP message as a DIDComm message, if the serviceEndpoint complies to the above. It shall pass any DIDComm message to its DIDComm agent.</p> <p>The following is an example of a complient DIDComm-over-XMPP service endpoint.</p> <pre><code>{\n  \"service\": [{\n    \"id\": \"did:example:123456789abcdefghi#xmpp\",\n    \"type\": \"XmppService\",\n    \"serviceEndpoint\": \"xmpp:bob@did.bar.com\"\n  }]\n}\n</code></pre>"},{"location":"features/0024-didcomm-over-xmpp/#userpart-generation-informative","title":"Userpart generation (informative)","text":"<p>There are multiple methods how the userpart of the DIDComm-over-XMPP serviceEndpoint may be generated.</p> <p>Editor's note: Should the description below be interpreted as informative, or should there be any signalling to indicate which userpart-generating method was used?</p> <p>Method 1: Same userpart as for human user</p> <p>In this method, the userpart is the same as used for human-to-human XMPP-based chat, and the resource part is removed. Here is an example.</p> <pre><code>Human-to-human XMPP address: xmpp:alice@foo.com/phone\n--&gt;\nDIDComm-over-XMPP serviceEndpoint: xmpp:alice@did.foo.com\n</code></pre> <p>The advantage of this method is its simplicity. An XMPP servicer needs to be configured only once to support this convention. No further registration actions are needed by any of the the users for its XMPP clients.</p> <p>The disadvantage of this method is that it creates a strong correlation point, which may conflict with privacy requirements.</p> <p>Editor's note: More advantages or disadvantages?</p> <p>A typical application of Method 1 is when there is an ongoing human-to-human (or human-to-bot) chat session that uses XMPP and the two parties what to set up a pairwise DID relationship. One can skip Step 0 \"Invitation to Connect\" (HIPE 0031) and immediately perform Step 1 \"Connection Request\".</p> <p>Method 2: Random userpart</p> <p>In this method, the userpart is randomly generated by either the XMPP client or the XMPP server, and it is rotated at a regular basis. Here is an example.</p> <pre><code>DIDComm-over-XMPP serviceEndpoint: xmpp:RllH91rcFdE@did.foo.com\n</code></pre> <p>The advantage of this method is low correlation and hence high privacy. If the DIDComm-over-XMPP serviceEndpoint is rotated after each set of XMPP exchange (\"session\"), then it cannot be correlated with subsequent XMPP exchanges.</p> <p>The disadvantage of this method is the high operational complexity of this method. It requires a client to keep a reserve of random XMPP addresses with the XMPP server. It significantly increases the routing tables of the XMPP server. It also places a burden on both DIDComm agents, because of the rapid rotation of DID Documents.</p> <p>Editor's note: More advantages or disadvantages?</p>"},{"location":"features/0024-didcomm-over-xmpp/#reference","title":"Reference","text":"<p>For use of XMPP, it is recommended to use Openfire Server open source project, including 2 plugins to enable server caching and message carbon copy. This will enable sending DIDcom to mulitple endpoints of the same person.</p> <p>Editor's note: Add references to the 2 plugins</p> <p>XMPP servers handle messages sent to a user@host (or \"bare\") XMPP address with no resource by delivering that message only to the resource with the highest priority for the target user. Some server implementations, however, have chosen to send these messages to all of the online resources for the target user. If the target user is online with multiple resources when the original message is sent, a conversation ensues on one of the user's devices; if the user subsequently switches devices, parts of the conversation may end up on the alternate device, causing the user to be confused, misled, or annoyed.</p> <p>To solve this is is recommended to use the plugin \"Message Carbons\". It will ensure that all of target user devices get both sides of all conversations in order to avoid user confusion. As a pleasant side-effect, information about the current state of a conversation is shared between all of a user's clients that implement this protocol.</p> <p>Editor's note: Add reference to \"Message Carbons\"</p>"},{"location":"features/0024-didcomm-over-xmpp/#drawbacks","title":"Drawbacks","text":"<p>Editor's note: Add drawbacks</p>"},{"location":"features/0024-didcomm-over-xmpp/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>All service endpoint examples from W3C's Data Model and Syntaxes for Decentralized Identifiers (DIDs) are HTTP. So if a consumer would want to be reachable for incoming DIDComm messages, then it should run an HTTP service on its consumer device and take actions to open firewalls (and handle network-address translations) towards its device. Such scenario is technically completely unrealistic, not to mention the security implications of such scenario.</p> <p>XMPP was specifically designed for incoming messages to consumer devices. XMPP's client-server structure overcomes any firewall issues.</p>"},{"location":"features/0024-didcomm-over-xmpp/#prior-art","title":"Prior art","text":"<p>Editor's note: Add prior art</p>"},{"location":"features/0024-didcomm-over-xmpp/#unresolved-questions","title":"Unresolved questions","text":"<p>Editor's note: Any unresolved questions?</p>"},{"location":"features/0024-didcomm-over-xmpp/#security-considerations","title":"Security considerations","text":"<p>Editor's note: Add security considerations</p>"},{"location":"features/0024-didcomm-over-xmpp/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0025-didcomm-transports/","title":"Aries RFC 0025: DIDComm Transports","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: ADOPTED</li> <li>Since: 2019-12-05</li> <li>Status Note:  </li> <li>Supersedes: INDY PR 94</li> <li>Start Date: 2019-02-26</li> <li>Tags: feature</li> </ul>"},{"location":"features/0025-didcomm-transports/#summary","title":"Summary","text":"<p>This RFC Details how different transports are to be used for Agent Messaging.</p>"},{"location":"features/0025-didcomm-transports/#motivation","title":"Motivation","text":"<p>Agent Messaging is designed to be transport independent, including message encryption and agent message format. Each transport does have unique ../../features, and we need to standardize how the transport ../../features are (or are not) applied.</p>"},{"location":"features/0025-didcomm-transports/#reference","title":"Reference","text":"<p>Standardized transport methods are detailed here.</p>"},{"location":"features/0025-didcomm-transports/#https","title":"HTTP(S)","text":"<p>HTTP(S) is the first, and most used transport for DID Communication that has received heavy attention. </p> <p>While it is recognized that all DIDComm messages are secured through strong encryption, making HTTPS somewhat redundant, it will likely cause issues with mobile clients because venders (Apple and Google) are limiting application access to the HTTP protocol. For example, on iOS 9 or above where [ATS])(https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity) is in effect, any URLs using HTTP must have an exception hard coded in the application prior to uploading to the iTunes Store. This makes DIDComm unreliable as the agent initiating the the request provides an endpoint for communication that the mobile client must use. If the agent provides a URL using the HTTP protocol it will likely be unusable due to low level operating system limitations.</p> <p>As a best practice, when HTTP is used in situations where a mobile client (iOS or Android) may be involved it is highly recommended to use the HTTPS protocol, specifically TLS 1.2 or above. </p> <p>Other important notes on the subject of using HTTP(S) include:</p> <ul> <li>Messages are transported via HTTP POST.</li> <li>The MIME Type for the POST request is <code>application/didcomm-envelope-enc</code>; see RFC 0044: DIDComm File and MIME Types for more details.</li> <li>A received message should be responded to with a 202 Accepted status code. This indicates that the request was received, but not necessarily processed. Accepting a 200 OK status code is allowed.</li> <li>POST requests are considered transmit only by default. No agent messages will be returned in the response. This behavior may be modified with additional signaling.</li> <li>Using HTTPS with TLS 1.2 or greater with a forward secret cipher will provide Perfect Forward Secrecy (PFS) on the transmission leg.</li> </ul>"},{"location":"features/0025-didcomm-transports/#known-implementations","title":"Known Implementations","text":"<p>Aries Cloud Agent - Python Aries Framework - .NET</p>"},{"location":"features/0025-didcomm-transports/#websocket","title":"Websocket","text":"<p>Websockets are an efficient way to transmit multiple messages without the overhead of individual requests.</p> <ul> <li>Each message is transmitted individually in an Encryption Envelope.</li> <li>The trust of each message comes from the Encryption Envelope, not the socket connection itself.</li> <li>Websockets are considered transmit only by default. Messages will only flow from the agent that opened the socket. This behavior may be modified with additional signaling.</li> <li>Using Secure Websockets (wss://) with TLS 1.2 or greater with a forward secret cipher will provide Perfect Forward Secrecy (PFS) on the transmission leg.</li> </ul>"},{"location":"features/0025-didcomm-transports/#known-implementations_1","title":"Known Implementations","text":"<p>Aries Cloud Agent - Python Aries Framework - .NET</p>"},{"location":"features/0025-didcomm-transports/#xmpp","title":"XMPP","text":"<p>XMPP is an effective transport for incoming DID-Communication messages directly to mobile agents, like smartphones.</p> <ul> <li>Incoming DID-Communication messages will arrive, even if the mobile agent is behind a firewall and network-address-translation (NAT).</li> <li>Incoming DID-Communication messages continue to arrive, even when the IP address of the mobile agent changes (switching between, 3G, 4G, Wifi, roaming, ...).</li> <li>Independent of cloud agents and routing agents, as messages arrive directly at the mobile agent.</li> <li>Well suited for direct consumer-to-consumer SSI transactions, from one mobile agent directly to another mobile agent without any DID-Communication intermediaries.</li> <li>Simple encapsulation of DIDcom messages, getting trust from the DIDcom Encryption Envelope.</li> <li>Specified in Aries RFC 0024: DIDCom-over-XMPP</li> </ul>"},{"location":"features/0025-didcomm-transports/#known-implementations_2","title":"Known Implementations","text":"<p>XMPP is implemented in the Openfire Server open source project. Integration with DID Communication agents is work-in-progress.</p>"},{"location":"features/0025-didcomm-transports/#other-transports","title":"Other Transports","text":"<p>Other transports may be used for Agent messaging. As they are developed, this RFC should be updated with appropriate standards for the transport method. A PR should be raised against this doc to facilitate discussion of the proposed additions and/or updates. New transports should highlight the common elements of the transport (such as an HTTP response code for the HTTP transport) and how they should be applied.</p>"},{"location":"features/0025-didcomm-transports/#message-routing","title":"Message Routing","text":"<p>The transports described here are used between two agents. In the case of message routing, a message will travel across multiple agent connections. Each intermediate agent (see Mediators and Relays) may use a different transport. These transport details are not made known to the sender, who only knows the keys of Mediators and the first endpoint of the route.</p>"},{"location":"features/0025-didcomm-transports/#message-context","title":"Message Context","text":"<p>The transport used from a previous agent can be recorded in the message trust context. This is particularly true of controlled network environments, where the transport may have additional security considerations not applicable on the public internet. The transport recorded in the message context only records the last transport used, and not any previous routing steps as described in the Message Routing section of this document.</p>"},{"location":"features/0025-didcomm-transports/#transport-testing","title":"Transport Testing","text":"<p>Transports which operate on IP based networks can be tested by an Agent Test Suite through a transport adapter. Some transports may be more difficult to test in a general sense, and may need specialized testing frameworks. An agent with a transport not yet supported by any testing suites may have non-transport testing performed by use of a routing agent.</p>"},{"location":"features/0025-didcomm-transports/#drawbacks","title":"Drawbacks","text":"<p>Setting transport standards may prevent some uses of each transport method.</p>"},{"location":"features/0025-didcomm-transports/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Without standards for each transport, the assumptions of each agent may not align and prevent communication before each message can be unpacked and evaluated.</li> </ul>"},{"location":"features/0025-didcomm-transports/#prior-art","title":"Prior art","text":"<p>Several agent implementations already exist that follow similar conventions.</p>"},{"location":"features/0025-didcomm-transports/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"features/0025-didcomm-transports/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0028-introduce/","title":"Aries RFC 0028: Introduce Protocol 1.0","text":"<ul> <li>Authors: Daniel Hardman, Sam Curren, Stephen Curran, Tobias Looker, George Aristy</li> <li>Status: PROPOSED</li> <li>Since: 2019-04-15</li> <li>Status Note: Referenced in some discussions about the peer DID method spec and n-wise DIDs, but not yet implemented.</li> <li>Start Date: 2019-03-27</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0028-introduce/#summary","title":"Summary","text":"<p>Describes how a go-between can introduce two parties that it already knows, but that do not know each other.</p>"},{"location":"features/0028-introduce/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> </ul>"},{"location":"features/0028-introduce/#motivation","title":"Motivation","text":"<p>Introductions are a fundamental activity in human relationships. They allow us to bootstrap contact information and trust. They are also a source of virality. We need a standard way to do introductions in an SSI ecosystem, and it needs to be flexible, secure, privacy-respecting, and well documented.</p>"},{"location":"features/0028-introduce/#tutorial","title":"Tutorial","text":""},{"location":"features/0028-introduce/#name-and-version","title":"Name and Version","text":"<p>This is the Introduce 1.0 protocol. It is uniquely identified by the URI:</p> <pre><code>\"https://didcomm.org/introduce/1.0\"\n</code></pre>"},{"location":"features/0028-introduce/#key-concepts","title":"Key Concepts","text":""},{"location":"features/0028-introduce/#basic-use-case","title":"Basic Use Case","text":"<p>Introductions target scenarios like this:</p> <p>Alice knows Bob and Carol, and can talk to each of them. She wants to introduce them in a way that allows a relationship to form.</p> <p></p> <p>This use case is worded carefully; it is far more adaptable than it may appear at first glance. The Advanced Use Cases section later in the doc explores many variations. But the early part of this document focuses on the simplest reading of the use case.</p>"},{"location":"features/0028-introduce/#goal","title":"Goal","text":"<p>When we introduce two friends, we may hope that a new friendship ensues. But technically, the introduction is complete when we provide the opportunity for a relationship--what the parties do with that opportunity is a separate question.</p> <p>Likewise, the goal of our formal introduction protocol should be crisply constrained. Alice wants to gather consent and contact information from Bob and Carol; then she wants to invite them to connect. What they do with her invitation after that is not under her control, and is outside the scope of the introduction.</p> <p>This suggests an important insight about the relationship between the introduce protocol and the Out-Of-Band protocols: they overlap. The invitation to form a relationship, which begins the Out-Of-Band protocols, is also the final step in an introduction.</p> <p>Said differently, the goal of the introduce protocol is to start the Out-Of-Band protocols.</p>"},{"location":"features/0028-introduce/#transferring-trust","title":"Transferring Trust","text":"<p>[TODO: talk about how humans do introductions instead of just introducing themselves to strangers because it raises trust. Example of Delta Airlines introducing you to Heathrow Airport; you trust that you're really talking to Heathrow based on Delta's asertion.]</p>"},{"location":"features/0028-introduce/#roles","title":"Roles","text":"<p>There are three [TODO:do we want to support introducing more than 2 at a time?] participants in the protocol, but only two roles.</p> <p>The introducer begins the process and must know the other two parties. Alice is the introducer in the diagram above. The other two participants are both introducees.</p>"},{"location":"features/0028-introduce/#states","title":"States","text":"<p>In a successful introduction, the introducer state progresses from <code>[start] -&gt; arranging -&gt; delivering -&gt; confirming (optional) -&gt; [done]</code>. Confirming is accomplished with an ACK to an introducee to let them know that their out-of-band message was forwarded.</p> <p>Meanwhile, each introducee progresses from <code>[start] -&gt; deciding -&gt; waiting -&gt; [done]</code>.</p> <p>Of course, errors and optional choices complicate the possibilities. The full state machine for each party are:</p> <p></p> <p>The subtleties are explored in the Advanced Use Cases section.</p>"},{"location":"features/0028-introduce/#messages","title":"Messages","text":""},{"location":"features/0028-introduce/#proposal","title":"<code>proposal</code>","text":"<p>This message informs an introducee that an introducer wants to perform an introduction, and requests approval to do so. It works the same way that proposals do in double-opt-in introductions in the non-agent world:</p> <p></p> <p>The DIDComm message looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/introduce/1.0/proposal\",\n  \"@id\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\",\n  \"to\": {\n    \"name\": \"Bob\"\n  }\n}\n</code></pre> <p>The <code>to</code> field contains an introducee descriptor that provides context about the introduction, helping the party receiving the proposal to evaluate whether they wish to accept it. Depending on how much context is available between introducer and introducee independent of the formal proposal message, this can be as simple as a name, or something fancier (see Advanced Use Cases below).</p>"},{"location":"features/0028-introduce/#response","title":"<code>response</code>","text":"<p>A standard example of the message that an introducee sends in response to an introduction proposal would be:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/introduce/1.0/response\",\n  \"@id\": \"283e15b5-a3f7-43e7-bac8-b75e4e7a0a25\",\n  \"~thread\": {\"thid\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\"},\n  \"approve\": true,\n  \"oob-message\": {\n    \"@type\": \"https://didcomm.org/out-of-band/1.0/invitation\",\n    \"@id\": \"12345678900987654321\",\n    \"label\": \"Robert\",\n    \"goal\": \"To issue a Faber College Graduate credential\",\n    \"goal_code\": \"issue-vc\",\n    \"handshake_protocols\": [\n      \"https://didcomm.org/didexchange/1.0\",\n      \"https://didcomm.org/connections/1.0\"\n    ],\n    \"service\": [\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]\n  }\n}\n</code></pre> <p>A simpler response, also valid, might look like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/introduce/1.0/response\",\n  \"@id\": \"283e15b5-a3f7-43e7-bac8-b75e4e7a0a25\",\n  \"~thread\": {\"thid\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\"},\n  \"approve\": true\n}\n</code></pre> <p>The difference between the two forms is whether the response contains a valid out-of-band message (see RFC 0434). Normally, it should--but sometimes, an introducee may not be able to (or may not want to) share a DIDComm endpoint to facilitate the introduction. In such cases, the stripped-down variant may be the right choice. See the Advanced Use Cases section for more details.</p> <p>At least one of the more complete variants must be received by an introducer to successfully complete the introduction, because the final step in the protocol is to begin one of the Out-Of-Band protocols by forwarding the message from one introducee to the other.</p>"},{"location":"features/0028-introduce/#note-on-the-ouf-of-band-messages","title":"Note on the ouf-of-band messages","text":"<p>These messages are not a member of the <code>introductions/1.0</code> protocol; they are not even adopted. They belong to the out-of-band protocols, and are no different from the message that two parties would generate when one invites the other with no intermediary, except that:</p> <ul> <li>It is delivered by the introducer, not by either of the introducees.</li> <li>It has a <code>~thread</code> decorator that identifies the introduction as its parent thread.</li> <li>If introducees already have DIDComm capabilities, it can be delivered over standard DIDComm channels. If one of the introducees does NOT have a DID-based channel with the introducer, then the message must be delivered to that introducee using the non-DIDComm channel. [TODO: is there a way for the introducer, rather than the other introducee, to \"sponsor\" the introducee that needs SSI onboarding?]</li> <li>If the message is delivered over a DIDComm channel, it is unusual in that it is from a party other than the one that owns the channel.</li> </ul>"},{"location":"features/0028-introduce/#request","title":"<code>request</code>","text":"<p>This message asks for an introduction to be made. This message also uses the <code>introducee descriptor</code> block, to tell the potential introducer which introducee is the object of the sender's interest:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/introduce/1.0/request\",\n  \"@id\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\",\n  \"please_introduce_to\": {\n    \"name\": \"Carol\",\n    \"description\": \"The woman who spoke after you at the PTA meeting last night.\",\n    \"expected\": true\n  },\n  \"nwise\": false,\n  \"~timing\": { \"expires_time\": \"2019-04-23 18:00Z\" }\n}\n</code></pre> <p>The recipient can choose whether or not to honor it in their own way, on their own schedule. However, a <code>problem_report</code> could be returned if the recipient chooses not to honor it.</p>"},{"location":"features/0028-introduce/#advanced-use-cases","title":"Advanced Use Cases","text":"<p>Any of the parties can be an organization or thing instead of a person.</p> <p></p> <p>Bob and Carol may actually know each other already, without Alice realizing it. The introduction may be rejected. It may create a new pairwise relationship between Bob and Carol that is entirely invisible to Alice. Or it may create an n-wise relationship in which Alice, Bob, and Carol know one another by the same identifiers.</p> <p>Some specific examples follow.</p>"},{"location":"features/0028-introduce/#one-introducee-cant-do-didcomm","title":"One introducee can't do DIDComm","text":"<p>The Out-Of-Band Protocols allow the invited party to be onboarded (acquire software and an agent) as part of the workflow.</p> <p></p> <p>Introductions support this use case, too. In such a case, the introducer sends a standard <code>proposal</code> to the introducee that DOES have DIDComm capabilities, but conveys the equivalent of a <code>proposal</code> over a non-DIDComm channel to the other introducee. The <code>response</code> from the DIDComm-capable introducee must include an out-of-band message with a deep link for onboarding, and this is sent to the introducee that needs onboarding.</p>"},{"location":"features/0028-introduce/#neither-introducee-can-do-didcomm","title":"Neither introducee can do DIDComm","text":"<p>In this case, the introducer first goes through onboarding via one of the Out-Of-Band protocols with one introducee. Once that introducee can do DIDComm, the previous workflow is used.</p>"},{"location":"features/0028-introduce/#introducer-doesnt-have-didcomm-capabilities","title":"Introducer doesn't have DIDComm capabilities","text":"<p>This might happen if AliceCorp wants to connect two of its customers. AliceCorp may not be able to talk to either of its customers over DIDComm channels, but it doesn't know whether they can talk to each other that way.</p> <p></p> <p>In this case, the introducer conveys the same information that a <code>proposal</code> would contain, using non-DIDComm channels. As long as one of the introducees sends back some kind of response that includes approval and an out-of-band message, the message can be delivered. The entire interaction is DIDComm-less.</p>"},{"location":"features/0028-introduce/#one-introducee-has-a-public-did-with-a-standing-invitation","title":"One introducee has a public DID with a standing invitation","text":"<p>This might happen if Alice wants to introduce Bob to CarolCorp, and CarolCorp has published a <code>connection-invitation</code> for general use.</p> <p></p> <p>As introducer, Alice simply has to forward CarolCorp's <code>connection-invitation</code> to Bob. No <code>proposal</code> message needs to be sent to CarolCorp; this is the <code>skip proposal</code> event shown in the introducer's state machine.</p>"},{"location":"features/0028-introduce/#introducee-requests-introduction","title":"Introducee requests introduction","text":"<p>Alice still acts as the introducer, but Bob now asks Alice to introduce him to a candidate introducee discovered a priori with the <code>help-me-discover</code> protocol:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/introduce/1.0/request\",\n  \"@id\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\",\n  \"please_introduce_to\": {\n      \"discovered\": \"didcomm:///5f2396b5-d84e-689e-78a1-2fa2248f03e4/.candidates%7B.id+%3D%3D%3D+%22Carol%22%7D\"\n  },\n  \"~timing\": { \"expires_time\": \"2019-04-23 18:00Z\" }\n}\n</code></pre> <p>This <code>request</code> message includes a <code>discovered</code> property with a linkable message path that uniquely identifies the candidate introducee.</p>"},{"location":"features/0028-introduce/#requesting-confirmation","title":"Requesting confirmation","text":"<p>[TODO: A field in the <code>response</code> where an introducee asks to be notified that the introduction has been made?]</p>"},{"location":"features/0028-introduce/#other-stuff","title":"Other stuff","text":"<ul> <li>Using acks to report status of introduction efforts.</li> <li>Timeouts.</li> <li>Introducing multiple parties at the same time?</li> </ul> <p>[TODO: What if Alice is introducing Bob, a public entity with no connection to her, to Carol, a private person? Can she just relay Bob's invitation that he published on his website? Are there security or privacy implications? What if she is introducing 2 public entities and has a connection to neither?]</p>"},{"location":"features/0028-introduce/#reference","title":"Reference","text":""},{"location":"features/0028-introduce/#proposal_1","title":"<code>proposal</code>","text":"<p>In the tutorial narrative, only a simple proposal was presented. A fancier version might be:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/introduce/1.0/proposal\",\n  \"@id\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\",\n  \"to\": {\n    \"name\": \"Kaiser Hospital\",\n    \"description\": \"Where I want to schedule your MRI. NOTE: NOT the one downtown!\",\n    \"description~l10n\": { \"locale\": \"en\", \"es\": \"Donde se toma el MRI; no en el centro\"},\n    \"where\": \"@34.0291739,-118.3589892,12z\",\n    \"img~attach\": {\n      \"description\": \"view from Marina Blvd\",\n      \"mime-type\": \"image/png\",\n      \"filename\": \"kaiser_culver_google.jpg\",\n      \"content\": {\n        \"link\": \"http://bit.ly/2FKkby3\",\n        \"byte_count\": 47738,\n        \"sha256\": \"cd5f24949f453385c89180207ddb1523640ac8565a214d1d37c4014910a4593e\"\n      }\n    },\n    \"proposed\": false\n  },\n  \"nwise\": true,\n  \"~timing\": { \"expires_time\": \"2019-04-23 18:00Z\" }\n}\n</code></pre> <p>This adds a number of fields to the introducee descriptor. Each is optional and may be appropriate in certain circumstances. Most should be self-explanatory, but the <code>proposed</code> field deserves special comment. This tells whether the described introducee has received a proposal of their own, or will be introduced without that step.</p> <p>This example also adds the <code>nwise</code> field to the proposal. When <code>nwise</code> is present and its value is <code>true</code>, the proposal is to establish an nwise relationship in which the introducer participates, as opposed to a pairwise relationship in which only the introducees participate.</p> <p>[TODO: do we care about having a response signed? Security? MITM?]</p>"},{"location":"features/0028-introduce/#errors","title":"Errors","text":"<p>[TODO: What can go wrong.]</p>"},{"location":"features/0028-introduce/#localization","title":"Localization","text":"<p>[TODO: the <code>description</code> field in an introducee descriptor. Error codes/catalog.]</p>"},{"location":"features/0028-introduce/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"features/0028-introduce/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"features/0028-introduce/#prior-art","title":"Prior art","text":"<p>Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:</p> <ul> <li>Does this feature exist in other SSI ecosystems and what experience have their community had?</li> <li>For other teams: What lessons can we learn from other attempts?</li> <li>Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.</li> </ul> <p>This section is intended to encourage you as an author to think about the lessons from other implementers, provide readers of your proposal with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if they are an adaptation from other communities.</p> <p>Note that while precedent set by other communities is some motivation, it does not on its own motivate an enhancement proposal here. Please also take into consideration that Indy sometimes intentionally diverges from common identity ../../features.</p>"},{"location":"features/0028-introduce/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"features/0028-introduce/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0030-sync-connection/","title":"Aries RFC 0030: Sync Connection Protocol 1.0","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes: Indy HIPE PR #104</li> <li>Start Date: 2018-10-01</li> <li>Tags: feature, decorator, protocol</li> </ul>"},{"location":"features/0030-sync-connection/#summary","title":"Summary","text":"<p>Define a set of non-centralized protocols (that is, ones that do not involve a common store of state like a blockchain), whereby parties using peer DIDs can synchronize the state of their shared relationship by direct communication with one another.</p>"},{"location":"features/0030-sync-connection/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> </ul>"},{"location":"features/0030-sync-connection/#motivation","title":"Motivation","text":"<p>For Alice and Bob to interact, they must establish and maintain state. This state includes all the information in a DID Document: endpoint, keys, and associated authorizations.</p> <p>The DID exchange protocol describes how these DID Docs are initially exchanged as a relationship is built. However, its mandate ends when a connection is established. This RFC focuses on how peers maintain their relationship thereafter, as DID docs evolve.</p>"},{"location":"features/0030-sync-connection/#tutorial","title":"Tutorial","text":"<p>Note 1: This RFC assumes you are thoroughly familiar with terminology and constructs from the peer DID method spec. Check there if you need background.</p> <p>Note 2: Most protocols between identity owners deal only with messages that cross a domain boundary--what Alice sends to Bob, or vice versa. What Alice does internally is generally none of Bob's business, since interoperability is a function of messages that are passed to external parties, not events that happen inside one's own domain. However, this protocol has some special requirements. Alice may have multiple agents, and Bob's behavior must account for the possibility that each of them has a different view of current relationship state. Alice has a responsibility to share and harmonize the view of state among her agents. Bob doesn't need to know exactly how she does it--but he does need to know that she's doing it, somehow--and he may need to cooperate with Alice to intelligently resolve divergences. For this reason, we describe the protocol as if it involved message passing within a domain in addition to message passing across domains. This is a simplification. The true, precise requirement for compliance is that implementers must pass messages across domains as described here, and they must appear to an outside observer as if they were passing messages within their domain as the protocol stipulates--but if they achieve the intra-domain results using some other mechanism besides DIDComm message passing, that is fine.</p>"},{"location":"features/0030-sync-connection/#name-and-version","title":"Name and Version","text":"<p>This RFC defines the <code>sync_connection</code> protocol, version 1.x, as identified by the following PIURI:</p> <pre><code>https://didcomm.org/sync_connection/1.0\n</code></pre> <p>Of course, subsequent evolutions of the protocol will replace <code>1.0</code> with an appropriate update per semver rules.</p> <p>A related, minor protocol is also defined in subdocs of this RFC:</p> <ul> <li>Abandon Connection Protocol</li> </ul>"},{"location":"features/0030-sync-connection/#roles","title":"Roles","text":"<p>The only role defined in this protocol is <code>peer</code>. However, see this note in the peer DID method spec for some subtleties.</p>"},{"location":"features/0030-sync-connection/#states","title":"States","text":"<p>This is a steady-state protocol, meaning that the state of participants does not change. Instead, all participants are continuously in a <code>syncing</code> state.</p>"},{"location":"features/0030-sync-connection/#messages","title":"Messages","text":""},{"location":"features/0030-sync-connection/#sync_state","title":"<code>sync_state</code>","text":"<p>This message announces that the sender wants to synchronize state with the recipient. This could happen because the sender suspects they are out of sync,  or because the sender wants to change the state by announcing new, never-before-seen  information. The recipient can be another agent within the same sovereign domain, or it can be an agent on the other side of the relationship. A sample looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/sync-connection/1.0/sync_state\",\n  \"@id\": \"e61586dd-f50e-4ed5-a389-716a49817207\",\n  \"for\": \"did:peer:11-479cbc07c3f991725836a3aa2a581ca2029198aa420b9d99bc0e131d9f3e2cbe\",\n  \"base_hash\": \"d48f058771956a305e12a3b062a3ac81bd8653d7b1a88dd07db8f663f37bf8e0\",\n  \"base_hash_time\": \"2019-07-23 18:05:06.123Z\",\n  \"deltas\": [\n    {\n      \"id\": \"040aaa5e-1a27-40d8-8d53-13a00b82d235\",\n      \"change\": \"ewogICJwdWJsaWNLZXkiOiBbCiAgICB...ozd1htcVBWcGZrY0pDd0R3biIKICAgIH0KICBdCn0=\",\n      \"by\": [ {\"key\": \"H3C2AVvL\", \"sig\": \"if8ooA+32YZc4SQBvIDDY9tgTa...i4VvND87PUqq5/0vsNFEGIIEDA==\"} ],\n      \"when\": \"2019-07-18T15:49:22.03Z\"\n    }\n  ]\n}\n</code></pre> <p>Note that the values in the <code>change</code> and <code>sig</code> fields have been shortened for readability.</p> <p>The properties in this message include:</p> <p>*<code>for</code>: Identifies which state is being synchronized. * <code>base_hash</code>: Identifies a shared state against which deltas should be   applied. See State Hashes for more details. * <code>base_hash_time</code>: An ISO 8601-formatted UTC timestamp,   identifying when the sender believes that the base hash became the   current state. This value need not be highly accurate, and different agents in   Alice and Bob's ecosystem may have different opinions about an appropriate   timestamp for the selected base hash. Like timestamps in email headers, it merely   provides a rough approximation of timeframe. * <code>deltas</code>: Gives a list of deltas that should be applied to the   DID doc, beginning at the specified state.</p> <p>When this message is received, the following processing happens:</p> <ul> <li>The <code>base_hash</code>  and <code>deltas</code> properties are checked for consistency. If any errors are detected, a <code>problem_report</code> message is returned, using message threading  to pinpoint the message that triggered the problem. No further processing occurs.</li> <li>If the recipient already has the same state, it sends an ACK.</li> <li>If the recipient knew about a subset of the delta, but not all of it, it applies what is left of the delta, and sends an ACK.</li> <li>If the recipient has a more evolved state, the recipient sends a reply that is a new <code>sync_state</code> message informing the sender of new information. As with the ACKs, this new message is known to be a reply to the original <code>sync_state</code> because its <code>~thread</code> decorator identifies the previous message's <code>@id</code> as its <code>thid</code>.</li> <li>If the recipient does not recognize the <code>base_hash</code>, it selects a hash from a point in time earlier than <code>base_hash_time</code> and sends back a new <code>sync_state</code> message with that earlier base.</li> <li>Because of the nature of the CRDT rules in the peer DID spec, truly problematic merge conflicts cannot occur. All objects in the DID doc that have an <code>id</code> property are immutable, and ordering of operations does not need to be highly consistent. Furthermore, an object in both deleted and undeleted state must be deemed to be deleted. However, if the recipient detects a trivial conflict, the delta with the <code>id</code> that sorts smaller/lower is selected.</li> </ul>"},{"location":"features/0030-sync-connection/#state-hashes","title":"State Hashes","text":"<p>To reliably describe the state of a DID doc at any given moment, we need a quick way to characterize its content. We could do this with a merkle tree, but the strong ordering of that structure is problematic--different participants may receive different deltas in different orders, and this is okay. What matters is whether they have applied the same set of deltas.</p> <p>To achieve this goal, the <code>id</code> properties of all received deltas are sorted and concatenated, and then the string undergoes a SHA256 hash. This produces a state hash.</p>"},{"location":"features/0030-sync-connection/#best-practices","title":"Best Practices","text":"<p>The following best practices will dramatically improve the robustness of state synchronization, both within and across domains. Software implementing this protocol is not required to do any of these things, but they are strongly recommended.</p>"},{"location":"features/0030-sync-connection/#the-state-decorator","title":"The <code>~state</code> decorator","text":"<p>Agents using peer DIDs should attach the <code>~state</code> decorator to messages to help each other discover when state synchronization is needed. This decorator has the following format:</p> <pre><code>\"~state\": [\n  {\"did\": \"&lt;my did&gt;\", \"state_hash\": \"&lt;my state hash&gt;\"},\n  {\"did\": \"&lt;your did&gt;\", \"state_hash\": \"&lt;your state hash&gt;\"}\n]\n</code></pre> <p>In n-wise relationships, there may be more than 2 entries in the list.</p> <p>The goal is to always describe the current known state hashes for each domain. It is also best practice for the recipient of the message to send a <code>sync_state</code> message back to the sender any time it detects a discrepancy.</p>"},{"location":"features/0030-sync-connection/#pending-commits","title":"Pending Commits","text":"<p>Agents should never commit to a change of state until they know that at least one other agent (on either side of the relationship) agrees to the change. This will significantly decrease the likelihood of merge conflicts. For example, an agent that wants to rotate a key should report the key rotation to someone, and receive an ACK, before it commits to use the new key. This guarantees that there will be gravitas and confirmation of the change, and is a reasonable requirement, since a change that nobody knows about is useless, anyway.</p>"},{"location":"features/0030-sync-connection/#routing-cloud-agent-rules","title":"Routing (Cloud) Agent Rules","text":"<p>It is best practice for routing agents (typically in the cloud) to enforce the following rules:</p> <ul> <li>Never deliver a message to an edge agent that shouldn't receive it, according to state  that the routing agent knows. Instead, reply with a <code>problem_report</code> about the state  being out of sync, followed by a <code>sync_state</code> message to initiate a reconciliation of  the differences.</li> <li>Never deliver a message from an agent that shouldn't be sending it, according to state that the routing agent knows. As with the previous rule, initiate a reconciliation first.</li> <li>Attempt to propagate state changes proactively.</li> </ul>"},{"location":"features/0030-sync-connection/#proactive-sync","title":"Proactive Sync","text":"<p>Any time that an agent has reason to suspect that it may be out of sync, it should attempt to reconcile. For example, if a mobile device has been turned off for an extended period of time, it should check with other agents to see if state has evolved, once it is able to communicate again.</p>"},{"location":"features/0030-sync-connection/#test-cases","title":"Test Cases","text":"<p>Because this protocol encapsulates a lot of potential complexity, and many corner cases, it is particularly important that implementations exercise the full range of scenarios in the Test Cases doc. Community members are encouraged to submit new test cases if they find situations that are not covered.</p>"},{"location":"features/0030-sync-connection/#reference","title":"Reference","text":""},{"location":"features/0030-sync-connection/#state-and-sequence-rules","title":"State and Sequence Rules","text":"<p>[TODO: create state machine matrices that show which messages can be sent in which states, causing which transitions]</p>"},{"location":"features/0030-sync-connection/#message-type-detail","title":"Message Type Detail","text":"<p>[TODO: explain every possible field of every possible message type]</p>"},{"location":"features/0030-sync-connection/#localized-message-catalog","title":"Localized Message Catalog","text":"<p>[TODO: define some localized strings that could be used with these messages, in errors or at other generally useful points?]</p>"},{"location":"features/0030-sync-connection/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0030-sync-connection/test_cases/","title":"Test Cases for Sync Connection Protocol","text":""},{"location":"features/0030-sync-connection/test_cases/#given","title":"Given","text":"<p>Let us assume that Alice and Bob each have 4 agents (A.1-A.4 and B.1-B.4, respectively), and that each of these agents possesses one key pair that's authorized to authenticate and do certain things in the DID Doc.</p> <p>A.1 and B.1 are routing (cloud) agents, where A.2-4 and B.2-4 run on edge devices that are imperfectly connected. A.1 and B.1 do not appear in the <code>authentication</code> section of their respective DID Docs, and thus cannot login on Alice and Bob's behalf.</p> <p>Let us further assume that Alice and Bob each have  two \"recovery keys\": A.5 and A.6; B.5 and B.6. These keys are not held by agents, but are printed on paper and held in a vault, or are sharded to friends. They are highly privileged but very difficult to use, since they would have to be digitized or unsharded and given to an agent before they would be useful.</p> <p>\"Admin\" operations like adding keys and granting privileges to them require either one of the privileged recovery keys, or 2 of the other agent keys to agree.</p> <p>Let us further assume that the initial state of Alice's domain, as described above, is known as A.state[0], and that Bob's state is B.state[0].</p> <p>These states may be represented by the following <code>authorization</code> section of each DID Doc:</p> <p>[TODO]</p>"},{"location":"features/0030-sync-connection/test_cases/#scenarios-each-starts-over-at-the-initial-conditions","title":"Scenarios (each starts over at the initial conditions)","text":"<ol> <li> <p>A.1 attempts to rotate its key by sending a <code>sync_state</code> message to A.2. Expected outcome: Should receive ACK, and A.2's state should be updated. Once A.1 receives the ACK, it should commit the pending change in its own  key. Until it receives the ACK, it should NOT commit the pending change.</p> </li> <li> <p>Like #1, except that message goes to B.1 and B.1's state is what should be updated.</p> </li> <li> <p>A.1 attempts to send a message to B.1, using the <code>~relstate</code> decorator, claiming states with <code>hash(A.state[0])</code> and <code>hash(B.state[0])</code>. Expected outcome: B.1 accepts the message.</p> </li> <li> <p>As #3, except that A.1 claims the current states are random hashes. Expected outcome: B.1 sends back a problem report, plus two <code>sync_state</code> messages (one with <code>who</code> = \"me\" and one with <code>who</code> = \"you\"). Each has an empty <code>deltas</code> array and <code>base_state</code> = the correct base state hash.</p> </li> <li> <p>A.1 attempts to rotate the key for A.2 by sending a <code>sync_state</code> message to any other agent. Expected outcome: change is rejected with a problem report that points out that A.1 is not authorized to rotate any key other than itself.</p> </li> </ol>"},{"location":"features/0030-sync-connection/abandon-connection-protocol/","title":"Abandon Connection Protocol 1.0","text":""},{"location":"features/0030-sync-connection/abandon-connection-protocol/#summary","title":"Summary","text":"<p>Describes how parties using peer DIDs can notify one another that they are abandoning the connection.</p>"},{"location":"features/0030-sync-connection/abandon-connection-protocol/#motivation","title":"Motivation","text":"<p>We need a way to tell another party that we are abandoning the connection. This is not strictly required, but it is good hygiene.</p>"},{"location":"features/0030-sync-connection/abandon-connection-protocol/#tutorial","title":"Tutorial","text":""},{"location":"features/0030-sync-connection/abandon-connection-protocol/#name-and-version","title":"Name and Version","text":"<p>This RFC defines the <code>abandon_connection</code> protocol, version 1.x, as identified by the following PIURI:</p> <pre><code>https://didcomm.org/abandon_connection/1.0\n</code></pre> <p>Of course, subsequent evolutions of the protocol will replace <code>1.0</code> with an appropriate update per semver rules.</p>"},{"location":"features/0030-sync-connection/abandon-connection-protocol/#roles","title":"Roles","text":"<p>This is a classic one-step notification, so it uses the predefined roles of <code>notifier</code> and <code>notified</code>.</p> <p></p>"},{"location":"features/0030-sync-connection/abandon-connection-protocol/#state-machines","title":"State Machines","text":"<p>No state changes during this protocol, although overarching state could change once it completes. Therefore no state machines are required.</p>"},{"location":"features/0030-sync-connection/abandon-connection-protocol/#messages","title":"Messages","text":""},{"location":"features/0030-sync-connection/abandon-connection-protocol/#announce","title":"<code>announce</code>","text":"<p>This message is used to announce that a party is abandoning the relationship. In a self-sovereign paradigm, abandoning a relationship can be done unilaterally, and does not require formal announcement. Indeed, sometimes a formal announcement is impossible, if one of the parties is offline. So while using this message is encouraged and best practice, it is not mandatory.</p> <p>An <code>announce</code> message from Alice to Bob looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/abandon_connection/1.0/announce\",\n  \"@id\": \"c17147d2-ada6-4d3c-a489-dc1e1bf778ab\"\n}\n</code></pre> <p>If Bob receives a message like this, he should assume that Alice no longer considers herself part of \"us\", and take appropriate action. This could include destroying data about Alice that he has accumulated over the course of their relationship, removing her peer DID and its public key(s) and endpoints from his wallet, and so forth. The nature of the relationship, the need for a historical audit trail, regulatory requirements, and many other factors may influence what's appropriate; the protocol simply requires that the message be understood to have permanent termination semantics.</p>"},{"location":"features/0031-discover-features/","title":"Aries RFC 0031: Discover Features Protocol 1.0","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED (may be RETIRED when v2.0 of the protocol has enough gravitas)</li> <li>Since: 2019-05-01</li> <li>Status Note: One of our earliest DIDComm protocols; reached FCP (standards track) status in Indy, and implemented in at least two codebases there. Converted to an Aries RFC Implemented in a handful of Aries codebases. With the advent of DIDComm v2 at DIF, it became clear that we wanted to discover ../../features beyond just protocol support, so this version of the protocol is now superseded by v2.0 in RFC 0557.</li> <li>Supersedes: Indy HIPE PR #73.</li> <li>Start Date: 2018-12-17</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"features/0031-discover-features/#summary","title":"Summary","text":"<p>Describes how agents can query one another to discover which ../../features it supports, and to what extent.</p>"},{"location":"features/0031-discover-features/#motivation","title":"Motivation","text":"<p>Though some agents will support just one protocol and will be statically configured to interact with just one other party, many exciting uses of agents are more dynamic and unpredictable. When Alice and Bob meet, they won't know in advance which ../../features are supported by one another's agents. They need a way to find out.</p>"},{"location":"features/0031-discover-features/#tutorial","title":"Tutorial","text":"<p>This RFC introduces a protocol for discussing the protocols an agent can handle. The identifier for the message family used by this protocol is <code>discover-features</code>, and the fully qualified URI for its definition is:</p> <pre><code>https://didcomm.org/discover-features/1.0\n</code></pre> <p>This protocol is now superseded by v2.0 in RFC 0557. Prefer the new version where practical.  </p>"},{"location":"features/0031-discover-features/#roles","title":"Roles","text":"<p>There are two roles in the <code>discover-features</code> protocol: <code>requester</code> and <code>responder</code>. The requester asks the responder about the protocols it supports, and the responder answers. Each role uses a single message type.</p>"},{"location":"features/0031-discover-features/#states","title":"States","text":"<p>This is a classic two-step request~response interaction, so it uses the predefined state machines for any <code>requester</code> and <code>responder</code>:</p> <p></p>"},{"location":"features/0031-discover-features/#messages","title":"Messages","text":""},{"location":"features/0031-discover-features/#query-message-type","title":"<code>query</code> Message Type","text":"<p>A <code>discover-features/query</code> message looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/1.0/query\",\n  \"@id\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\",\n  \"query\": \"https://didcomm.org/tictactoe/1.*\",\n  \"comment\": \"I'm wondering if we can play tic-tac-toe...\"\n}\n</code></pre> <p>Query messages say, \"Please tell me what your capabilities are with respect to the protocols that match this string.\" This particular example asks if another agent knows any 1.x versions of the tictactoe protocol.</p> <p>The <code>query</code> field may use the * wildcard. By itself, a query with just the wildcard says, \"I'm interested in anything you want to share with me.\" But usually, this wildcard will be to match a prefix that's a little more specific, as in the example that matches any 1.x version.</p> <p>Any agent may send another agent this message type at any time. Implementers of agents that intend to support dynamic relationships and rich ../../features are strongly encouraged to implement support for this message, as it is likely to be among the first messages exchanged with a stranger.</p>"},{"location":"features/0031-discover-features/#disclose-message-type","title":"<code>disclose</code> Message Type","text":"<p>A <code>discover-features/disclose</code> message looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/1.0/disclose\",\n  \"~thread\": { \"thid\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\" },\n  \"protocols\": [\n    {\n      \"pid\": \"https://didcomm.org/tictactoe/1.0\",\n      \"roles\": [\"player\"]\n    }\n  ]\n}\n</code></pre> <p>The <code>protocols</code> field is a JSON array of protocol support descriptor objects that match the query. Each descriptor has a <code>pid</code> that contains a protocol version (fully qualified message family identifier such as <code>https://didcomm.org/tictactoe/1.0</code>), plus a <code>roles</code> array that enumerates the roles the responding agent can play in the associated protocol.</p> <p>Response messages say, \"Here are some protocols I support that matched your query, and some things I can do with each one.\"</p>"},{"location":"features/0031-discover-features/#sparse-responses","title":"Sparse Responses","text":"<p>Responses do not have to contain exhaustive detail. For example, the following response is probably just as good:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/1.0/disclose\",\n  \"~thread\": { \"thid\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\" },\n  \"protocols\": [\n    {\"pid\": \"https://didcomm.org/tictactoe/1.0\"}\n  ]\n}\n</code></pre> <p>The reason why less detail probably suffices is that agents do not need to know everything about one another's implementations in order to start an interaction--usually the flow will organically reveal what's needed. For example, the <code>outcome</code> message in the <code>tictactoe</code> protocol isn't needed until the end, and is optional anyway. Alice can start a tictactoe game with Bob and will eventually see whether he has the right idea about <code>outcome</code> messages.</p> <p>The missing <code>roles</code> in this response does not say, \"I support no roles in this protocol.\" It says, \"I support the protocol but I'm providing no detail about specific roles.\"</p> <p>Even an empty <code>protocols</code> map does not say, \"I support no protocols that match your query.\" It says, \"I'm not telling you that I support any protocols that match your query.\" An agent might not tell another that it supports a protocol for various reasons, including: the trust that it imputes to the other party based on cumulative interactions so far, whether it's in the middle of upgrading a plugin, whether it's currently under high load, and so forth. And responses to a <code>discover-features</code> request are not guaranteed to be true forever; agents can be upgraded or downgraded, although they probably won't churn in their protocol support from moment to moment.</p>"},{"location":"features/0031-discover-features/#privacy-considerations","title":"Privacy Considerations","text":"<p>Because the regex in a <code>request</code> message can be very inclusive, the <code>discover-features</code> protocol could be used to mine information suitable for agent fingerprinting, in much the same way that browser fingerprinting works. This is antithetical to the ethos of our ecosystem, and represents bad behavior. Agents should use <code>discover-features</code> to answer legitimate questions, and not to build detailed profiles of one another. However, fingerprinting may be attempted anyway.</p> <p>For agents that want to maintain privacy, several best practices are recommended:</p>"},{"location":"features/0031-discover-features/#follow-selective-disclosure","title":"Follow selective disclosure.","text":"<p>Only reveal supported ../../features based on trust in the relationship. Even if you support a protocol, you may not wish to use it in every relationship. Don't tell others about protocols you do not plan to use with them.</p> <p>Patterns are easier to see in larger data samples. However, a pattern of ultra-minimal data is also a problem, so use good judgment about how forthcoming to be.</p>"},{"location":"features/0031-discover-features/#vary-the-format-of-responses","title":"Vary the format of responses.","text":"<p>Sometimes, you might prettify your agent plaintext message one way, sometimes another.</p>"},{"location":"features/0031-discover-features/#vary-the-order-of-items-in-the-protocols-array","title":"Vary the order of items in the <code>protocols</code> array.","text":"<p>If more than one key matches a query, do not always return them in alphabetical order or version order. If you do return them in order, do not always return them in ascending order.</p>"},{"location":"features/0031-discover-features/#consider-adding-some-spurious-details","title":"Consider adding some spurious details.","text":"<p>If a query could match multiple message families, then occasionally you might add some made-up message family names as matches. If a regex allows multiple versions of a protocol, then sometimes you might use some made-up versions. And sometimes not. (Doing this too aggressively might reveal your agent implementation, so use sparingly.)</p>"},{"location":"features/0031-discover-features/#vary-how-you-query-too","title":"Vary how you query, too.","text":"<p>How you ask questions may also be fingerprintable.</p>"},{"location":"features/0031-discover-features/#reference","title":"Reference","text":""},{"location":"features/0031-discover-features/#localization","title":"Localization","text":"<p>The <code>query</code> message contains a <code>comment</code> field that is localizable. This field is optional and may not be often used, but when it is, it is to provide a human-friendly justification for the query. An agent that consults its master before answering a query could present the content of this field as an explanation of the request.</p> <p>All message types in this family thus have the following implicit decorator:</p> <pre><code>{\n\n  \"~l10n\": {\n    \"locales\": { \"en\": [\"comment\"] },\n    \"catalogs\": [\"https://github.com/hyperledger/aries-rfcs/blob/a9ad499../../features/0031-discover-features/catalog.json\"]\n  }\n\n}\n</code></pre>"},{"location":"features/0031-discover-features/#message-catalog","title":"Message Catalog","text":"<p>As shown in the above <code>~l10n</code> decorator, all agents using this protocol have a simple message catalog in scope. This allows agents to send <code>problem-report</code>s to complain about something related to <code>discover-features</code> issues. The catalog looks like this (see catalog.json):</p> <pre><code>{\n  \"query-too-intrusive\": {\n    \"en\": \"Protocol query asked me to reveal too much information.\"\n  }\n}\n</code></pre> <p>For more information, see the localization RFC.</p>"},{"location":"features/0031-discover-features/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Do we want to support the discovery of ../../features that are not protocol-related?</li> </ul>"},{"location":"features/0031-discover-features/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Streetcred.id Commercial mobile and web app built using Aries Framework - .NET MISSING test results Aries Protocol Test Suite"},{"location":"features/0032-message-timing/","title":"Aries RFC 0032: Message Timing","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: DEMONSTRATED</li> <li>Since: 2019-05-01</li> <li>Status Note: Broadly socialized but not yet implemented. </li> <li>Supersedes: Indy RFC PR #68</li> <li>Start Date: 2018-12-11</li> <li>Tags: feature</li> </ul>"},{"location":"features/0032-message-timing/#summary","title":"Summary","text":"<p>Explain how timing of agent messages can be communicated and constrained.</p>"},{"location":"features/0032-message-timing/#motivation","title":"Motivation","text":"<p>Many timing considerations influence asynchronous messaging delivery. We need a standard way to talk about them.</p>"},{"location":"features/0032-message-timing/#tutorial","title":"Tutorial","text":"<p>This RFC introduces a decorator to communicate about timing of messages. It is compatible with, but independent from, conventions around date and time fields in messages.</p> <p>Timing attributes of messages can be described with the <code>~timing</code> decorator. It offers a number of optional subfields:</p> <pre><code>\"~timing\": {\n  \"in_time\":  \"2019-01-23 18:03:27.123Z\",\n  \"out_time\": \"2019-01-23 18:03:27.123Z\",\n  \"stale_time\": \"2019-01-24 18:25Z\",\n  \"expires_time\": \"2019-01-25 18:25Z\",\n  \"delay_milli\": 12345,\n  \"wait_until_time\": \"2019-01-24 00:00Z\"\n}\n</code></pre> <p>The meaning of these fields is:</p> <ul> <li><code>in_time</code>: The timestamp when the preceding message in this thread   (the one that elicited this message as a response) was received. Or, on   a dynamically composed <code>forward</code> message, the timestamp when an upstream   relay first received the message it's now asking to be forwarded.</li> <li><code>out_time</code>: The timestamp when the message was emitted. At least millisecond   precision is preferred, though second precision is acceptable.</li> <li><code>stale_time</code>: Ideally, the decorated message should be processed by the   the specified timestamp. After that, the message may become irrelevant   or less meaningful than intended. This is a hint only.</li> <li><code>expires_time</code>: The decorated message should be considered invalid or expired   if encountered after the specified timestamp. This is a much stronger claim   than the one for <code>stale_time</code>; it says that the receiver should cancel   attempts to process it once the deadline is past, because the sender won't   stand behind it any longer. While processing of the received message should   stop, the thread of the message should be retained as the sender may send an   updated/replacement message. In the case that the sender does not follow up,   the policy of the receiver agent related to abandoned threads would presumably   be used to eventually delete the thread.</li> <li><code>delay_milli</code>: Wait at least this many milliseconds before processing the   message. This may be useful to defeat temporal correlation. It is recommended   that agents supporting this field should not honor requests for delays longer   than 10 minutes (600,000 milliseconds).</li> <li><code>wait_until_time</code>: Wait until this time before processing the message.</li> </ul> <p>All information in these fields should be considered best-effort. That is, the sender makes a best effort to communicate accurately, and the receiver makes a best effort to use the information intelligently. In this respect, these values are like timestamps in email headers--they are generally useful, but not expected to be perfect. Receivers are not required to honor them exactly.</p> <p>An agent may ignore the <code>~timing</code> decorator entirely or implement the <code>~timing</code> decorator and silently ignore any of the fields it chooses not to support.</p>"},{"location":"features/0032-message-timing/#timing-in-routing","title":"Timing in Routing","text":"<p>Most usage of the <code>~timing</code> decorator is likely to focus on application-oriented messages processed at the edge. <code>in_time</code> and <code>out_time</code>, for example, are mainly useful so Bob can know how long Alice took to ponder her response to his love letter. In onion routing, where one edge agent prepares all layers of the <code>forward</code> wrapping, it makes no sense to apply them to <code>forward</code> messages. However, if a relay is composing new <code>forward</code> messages dynamically, these fields could be used to measure the delay imposed by that relay. All the other fields have meaning in routing.</p>"},{"location":"features/0032-message-timing/#timing-and-threads","title":"Timing and Threads","text":"<p>When a message is a reply, then <code>in_time</code> on an application-focused message is useful. However, <code>out_time</code> and all other fields are meaningful regardless of whether threading is active.</p>"},{"location":"features/0032-message-timing/#reference","title":"Reference","text":"<ul> <li>Discussion of date and time datatypes on Wikipedia</li> <li>ISO 8601</li> </ul>"},{"location":"features/0032-message-timing/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes RFC 0193: Coin Flip Protocol Uses <code>~timing.expires_time</code> to time out each step of the coin flip."},{"location":"features/0034-message-tracing/","title":"Aries RFC 0034: Message Tracing","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: PROPOSED</li> <li>Since: 2018-10-24</li> <li>Status Note: Not yet implemented broadly, but Evernym has been exploring it as a solution to some debugging needs.</li> <li>Start Date: 2018-10-24</li> <li>Tags: feature, decorator</li> </ul>"},{"location":"features/0034-message-tracing/#summary","title":"Summary","text":"<p>Define a mechanism to track what happens in a complex DIDComm interactions, to make troubleshooting and auditing easier.</p>"},{"location":"features/0034-message-tracing/#motivation","title":"Motivation","text":"<p>Anyone who has searched trash and spam folders for a missing email knows that when messages don't elicit the expected reaction, troubleshooting can be tricky. Aries-style agent-to-agent communication is likely to manifest many of the same challenges as email, in that it may be routed to multiple places, by multiple parties, with incomplete visibility into the meaning or state associated with individual messages. Aries's communication is even more opaque than ordinary email, in that it is transport agnostic and encrypted...</p> <p>In a future world where DIDComm technology is ubiquitous, people may send messages from one agent to another, and wonder why nothing happened, or why a particular error is reported. They will need answers.</p> <p>Also, developers and testers who are working with DIDComm-based protocols need a way to debug.</p>"},{"location":"features/0034-message-tracing/#tutorial","title":"Tutorial","text":""},{"location":"features/0034-message-tracing/#basics","title":"Basics","text":"<p>Many systems that deliver physical packages offer a \"cerified delivery\" or \"return receipt requested\" feature. To activate the feature, a sender affixes a special label to the package, announcing who should be notified, and how. Handlers of the package then cooperate to satisfy the request.</p> <p></p> <p>DIDComm thread tracing works on a similar principle. When tracing is desired, a sender adds to the normal message metadata a special decorator that the message handler can see. If the handler notices the decorator and chooses to honor the request, it emits a notification to provide tracing.</p> <p>The main complication is that DIDComm message routing uses nested layers of encryption. What is visible to one message handler may not be visible to another. Therefore, the decorator must be repeated in every layer of nesting where tracing is required. Although this makes tracing somewhat verbose, it also provides precision; troubleshooting can focus only on one problematic section of an overall route, and can degrade privacy selectively.</p>"},{"location":"features/0034-message-tracing/#decorator","title":"Decorator","text":"<p>Tracing is requested by decorating the JSON plaintext of an DIDComm message (which will  often be a forward message, but could also be the terminal message unpacked  and handled at its final destination) with the <code>~trace</code> attribute. Here is the simplest possible example:</p> <pre><code>{\n  \"@type\": \"did:sov:BzCBs...;spec/routing/1.0/forward\",\n  \"@id\": \"abc-def-...\",\n  \"msg\": \"U2Vl...\",\n  \"~trace\": {\n    \"target\": \"http://example.com/tracer\",\n    \"full_thread\": true\n  }\n}\n</code></pre> <p>The <code>\"target\"</code> can refer to a url (as above) or the term <code>\"log\"</code>, which is a request to append trace information to the standard log file.  (Information can then be manually collated from agents.)</p> <p>This example asks the handler of the message to perform an HTTP POST of a trace report about the message to the URI <code>http://example.com/tracer</code>.</p> <p>The service listening for trace reports--called the trace sink-- doesn't have to have any special characteristics, other than support for HTTP 1.1 or SMTP (for <code>mailto:</code> URIs) and the ability to receive small plaintext payloads rapidly. It may use TLS, but it is not required to. If TLS is used, the parties that submit reports should accept the certificate without strong checking, even if it is expired or invalid. The rationale for this choice is:</p> <ol> <li>It is the sender's trust in the tracing service, not the handler's trust, that matters.</li> <li>Tracing is inherently unsafe and non-privacy-preserving, in that it introduces    an eavesdropper and a channel with uncertain security guarantees. Trying to secure the    eavesdropper is a waste of effort.</li> <li>Introducing a strong dependency on PKI-based trust into a protocol that exists to improve    PKI feels wrong-headed.</li> <li>When tracing is needed, the last thing we should do is create another fragility to    troubleshoot.</li> </ol>"},{"location":"features/0034-message-tracing/#trace-reports","title":"Trace Reports","text":"<p>The body of the HTTP request (the trace report) is a JSON document that looks like this:</p> <pre><code>{\n  \"@type\": \"did:sov:BzCBs...;spec/1.0/trace_report\",\n  \"msg_id\": \"abc-def-...df\",\n  \"thread_id\": \"hij-klm-nop-...qr\",\n  \"handler\": \"did:sov:1234abcd#3\",\n  \"ellapsed_milli\": 27,\n  \"traced_type\": \"did:sov:BzCBs...;spec/routing/1.0/forward\",\n  \"str_time\": \"2018-03-27 18:23:45.123Z\",\n  \"timestamp\": \"1234567890.123456\",\n  \"outcome\": \"OK ...\"\n}\n</code></pre>"},{"location":"features/0034-message-tracing/#subtleties","title":"Subtleties","text":""},{"location":"features/0034-message-tracing/#message-ids","title":"Message IDs","text":"<p>If messages have a different <code>@id</code> attribute at each hop in a delivery chain, then a trace of the message at hop 1 and a trace of the message at hop 2 will not appear to have any connection when the reports are analyzed together.</p> <p></p> <p>To solve this problem, traced messages may use an ID convention that permits ordering. Assume that the inner application message has a base ID, X. Containing messages (e.g., <code>forward</code> messages) have IDs in the form X.1, X.2, X.3, and so forth -- where numbers represent the order in which the messages will be handled. Notice in the sample trace report above that the <code>for_id</code> of the trace report message is <code>98fd8d72-80f6-4419-abc2-c65ea39d0f38.1</code>. This implies that it is tracing the first hop of inner, application message with id <code>98fd8d72-80f6-4419-abc2-c65ea39d0f38</code>.</p>"},{"location":"features/0034-message-tracing/#delegation","title":"Delegation","text":"<p>Sometimes, a message is sent before it is fully wrapped for all hops in its route. This can happen, for example, if Alice's edge agent delegates to Alice's cloud agent the message preparation for later stages of routing.</p> <p>In such cases, tracing for the delegated portion of the route should default to inherit the tracing choice of the portion of the route already seen. To override this, the <code>~trace</code> decorator placed on the initial message from Alice's edge to Alice's cloud can include the optional <code>full-route</code> attribute, with its value set to <code>true</code> or <code>false</code>.</p> <p>This tells handlers that are wrapping subsequent portions of a routed message to either propagate or truncate the routing request in any new <code>forward</code> messages they compose.</p>"},{"location":"features/0034-message-tracing/#timing-and-sequencing","title":"Timing and Sequencing","text":"<p>Each trace report includes a UTC timestamp from the reporting handler. This timestamp should be computed at the instant a trace report is prepared--not when it is queued or delivered. Even so, it offers only a rough approximation of when something happened. Since system clocks from handlers may not be synchronized, there is no guarantee of precision or of agreement among timestamps.</p> <p>In addition, trace reports may be submitted asynchronously with respect to the message handling they document. Thus, a trace report could arrive out of sequence, even if the handling it describes occurred correctly. This makes it vital to order trace reports according to the ID sequencing convention described above.</p>"},{"location":"features/0034-message-tracing/#tracing-the-original-sender","title":"Tracing the original sender","text":"<p>The original sender may not run a message handling routine that triggers tracing. However, as a best practice, senders that enable tracing should send a trace report when they send, so the beginning of a routing sequence is documented. This report should reference X.0 in <code>for_id</code>, where X is the ID of the inner application message for the final recipient.</p>"},{"location":"features/0034-message-tracing/#handling-a-message-more-than-once","title":"Handling a message more than once","text":"<p>A particular handler may wish to document multiple phases of processing for a message. For example, it may choose to emit a trace report when the message is received, and again when the message is \"done.\" In such cases, the proper sequence of the two messages, both of which will have the same <code>for_id</code> attribute, is given by the relative sequence of the timestamps.</p> <p>Processing time for each handler--or for phases within a handler--is given by the <code>elapsed_milli</code> attribute.</p>"},{"location":"features/0034-message-tracing/#privacy","title":"Privacy","text":"<p>Tracing inherently compromises privacy. It is totally voluntary, and handlers should not honor trace requests if they have reason to believe they have been inserted for nefarious purposes. However, the fact that the trace reports can only be requested by the same entities that send the messages, and that they are encrypted in the same way as any other plaintext that a handler eventually sees, puts privacy controls in the hands of the ultimate sender and receiver.</p>"},{"location":"features/0034-message-tracing/#tracing-entire-threads","title":"Tracing entire threads","text":"<p>If a sender wishes to enable threading for an entire multi-step interaction between multiple parties, the <code>full_thread</code> attribute can be included on an inner application, with its value set to <code>true</code>. This signals to recipients that the sender wishes to have tracing turned on until the interaction is complete. Recipients may or may not honor such requests. If they don't, they may choose to send an error to the sender explaining why they are not honoring the request.</p>"},{"location":"features/0034-message-tracing/#reference","title":"Reference","text":""},{"location":"features/0034-message-tracing/#trace-decorator-trace","title":"Trace decorator (<code>~trace</code>)","text":"<p>Value is any URI. At least <code>http</code>, <code>https</code>, and <code>mailto</code> should be supported. If mail is sent, the message subject should be \"trace report for ?\", where ? is the value of the <code>for_id</code> attribute in the report, and the email body should contain the plaintext of the report, as utf8.</p>"},{"location":"features/0034-message-tracing/#trace-report-attributes","title":"Trace Report Attributes","text":"<ul> <li><code>@type</code>: Should always be <code>\"https://didcomm.org/tracing/1.0/trace_report\"</code>,    or some evolved version thereof. Required for version control and to support trace sinks    that process other HTTP payloads as well.</li> <li><code>msg_id</code>: The ID of the message that the handler is looking at when it composes the    trace report. Required.</li> <li><code>thread_id</code>: The ID of the protocol thread.  Required.</li> <li><code>handler</code>: A string that identifies the handler in a way that's useful for troubleshooting purposes.    For example, it might identify a particular agent by DID+keyref, or it might be a friendly    string like \"iPhone\" or \"AgentsRUs Cloud Agent, geocaching extension v1.3.7\". Optional but    encouraged.</li> <li><code>elapsed_milli</code>: How many milliseconds did the handler have this message before composing    the trace report? If the same handler emits more than one trace report, how long has it    been since the last trace was composed? Optional but encouraged.</li> <li><code>traced_type</code>: What was the message type of the traced message? Optional but encouraged.</li> <li><code>str_time</code>: What was the UTC timestamp of the system clock of the handler    when the handler composed the trace report? ISO 8601 format with millisecond precision.    Optional but encouraged.</li> <li><code>timestamp</code>: Value fo the <code>str_time</code> field in milliseconds (UNIX time format).</li> <li><code>outcome</code>: A string that describes the outcome of the message handling. The string MUST   begin with one of the following tokens: <code>\"OK\"</code> (meaning the handler completed its processing   successfully; <code>\"ERR\"</code> (the handler failed), or <code>\"PEND\"</code> (the handler is still working on the   message and does not know the final outcome). After this token, the string SHOULD contain   a parenthetical explanation suitable for use by humans that want to troubleshoot. For <code>forward</code>   messages that have an outcome of <code>OK</code>, the recommended explanation is something like   <code>\"(forwarded to did:sov:1234abcd#4)\"</code>.</li> </ul>"},{"location":"features/0034-message-tracing/#drawbacks","title":"Drawbacks","text":"<p>Tracing makes network communication quite noisy. It imposes a burden on message handlers. It may also incur performance penalties.</p>"},{"location":"features/0034-message-tracing/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Wireshark and similar network monitoring tools could give some visibility into agent-to-agent interactions. However, it would be hard to make sense of bytes on the wire, due to encryption and the way individual messages may be divorced from routing or thread context.</p> <p>Proprietary tracing could be added to the agents built by particular vendors. However, this would have limited utility if an interaction involved software not made by that vendor.</p>"},{"location":"features/0034-message-tracing/#prior-art","title":"Prior art","text":"<p>The message threading RFC and the error reporting RFC touch on similar subjects, but are distinct.</p>"},{"location":"features/0034-message-tracing/#unresolved-questions","title":"Unresolved questions","text":"<p>None.</p>"},{"location":"features/0034-message-tracing/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0035-report-problem/","title":"Aries RFC 0035: Report Problem Protocol 1.0","text":"<ul> <li>Authors: Stephen Curran, Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Implemented in multiple codebases.</li> <li>Supersedes: Indy HIPE PR #65</li> <li>Start Date: 2018-11-26</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"features/0035-report-problem/#summary","title":"Summary","text":"<p>Describes how to report errors and warnings in a powerful, interoperable way. All implementations of SSI agent or hub technology SHOULD implement this RFC.</p>"},{"location":"features/0035-report-problem/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> </ul>"},{"location":"features/0035-report-problem/#motivation","title":"Motivation","text":"<p>Effective reporting of errors and warnings is difficult in any system, and particularly so in decentralized systems such as remotely collaborating agents. We need to surface problems, and their supporting context, to people who want to know about them (and perhaps separately, to people who can actually fix them). This is especially challenging when a problem is detected well after and well away from its cause, and when multiple parties may need to cooperate on a solution.</p> <p>Interoperability is perhaps more crucial with problem reporting than with any other aspect of DIDComm, since an agent written by one developer MUST be able to understand an error reported by an entirely different team. Notice how different this is from normal enterprise software development, where developers only need to worry about understanding their own errors.</p> <p>The goal of this RFC is to provide agents with tools and techniques possible to address these challenges. It makes two key contributions:</p> <ul> <li>A protocol that helps an Agent report problems with appropriate   context. We expect this to be a subprotocol of nearly every interesting application-level   protocol; messages from it may even be adopted into other protocols.</li> <li>An inventory of problem categories and best practices for handling them.</li> </ul>"},{"location":"features/0035-report-problem/#tutorial","title":"Tutorial","text":""},{"location":"features/0035-report-problem/#error-vs-warning-vs-problem","title":"\"Error\" vs. \"Warning\" vs. \"Problem\"","text":"<p>The distinction between \"error\" and \"warning\" is often thought of as one of severity -- errors are really bad, and warnings are only somewhat bad. This is reinforced by the way logging platforms assign numeric constants to ERROR vs. WARN log events, and by the way compilers let warnings be suppressed but refuse to ignore errors.</p> <p>However, any cybersecurity professional will tell you that warnings sometimes signal deep and scary problems that should not be ignored, and most veteran programmers can tell war stories that reinforce this wisdom. A deeper analysis of warnings reveals that what truly differentiates them from errors is not their lesser severity, but rather their greater ambiguity. Warnings are problems that require human judgment to evaluate, whereas errors are unambiguously bad.</p> <p>The mechanism for reporting problems in DIDComm cannot make a simplistic assumption that all agents are configured to run with a particular verbosity or debug level. Each agent must let other agents decide for themselves, based on policy or user preference, what do do about various issues. For this reason, we use the generic term \"problem\" instead of the more specific and semantically opinionated term \"error\" (or \"warning\") to describe the general situation we're addressing. \"Problem\" includes any deviation from the so-called \"happy path\" of an interaction. This could include situations where the severity is unknown and must be evaluated by a human, as well as surprising events (e.g., a decision by a human to alter the basis for in-flight messaging by moving from one device to another).</p>"},{"location":"features/0035-report-problem/#specific-challenges","title":"Specific Challenges","text":"<p>All of the following challenges need to be addressed.</p> <ol> <li>Report problems to external parties interacting with us.   For example, AliceCorp has to be able to tell Bob that it can\u2019t issue the   credential he requested because his payment didn\u2019t go through.</li> <li>Report problems to other entities inside our own domain. For example,   AliceCorp\u2019s agent #1 has to be able to report to AliceCorp agent #2 that   it is out of disk space.</li> <li>Report in a way that provides human beings with useful context and guidance   to troubleshoot.   Most developers know of cases where error reporting was technically correct but   completely useless. Bad communication about problems is one of the most common   causes of UX debacles. Humans using agents will speak different languages, have   differing degrees of technical competence, and have different software and hardware   resources. They may lack context about what their agents are doing, such as when   a DIDComm interaction occurs as a result of scheduled or policy-driven actions.   This makes context and guidance crucial.</li> <li>Map a problem backward in time, space, and circumstances, so when it is   studied, its original context is available. This is particularly difficult   in DIDComm, which is transport-agnostic and inherently asynchronous, and   which takes place on an inconsistently connected digital landscape.</li> <li>Support localization using techniques in the l10n RFC.</li> <li>Provide consistent, locale-independent problem codes, not just localized text,   so problems can be researched in knowledge bases, on Stack Overflow, and in   other internet forums, regardless of the natural language in which a message   displays. This also helps meaning remain stable as wording is tweaked.</li> <li>Provide a registry of well known problem codes that are carefully defined and   localized, to maximize shared understanding. Maintaining an exhaustive list   of all possible things that can go wrong with all possible agents in all possible   interactions is completely unrealistic. However, it may be possible to maintain   a curated subset. While we can't enumerate everything that can go wrong in a   financial transaction, a code for \"insufficient funds\" might have near-universal   usefulness. Compare the posix error inventory in errorno.h.</li> <li>Facilitate automated problem handling by agents, not just manual handling by humans.   Perfect automation may be impossible, but high levels of automation should be   doable.</li> <li>Clarify how the problem affects an in-progress interaction. Does a failure to   process payment reset the interaction to the very beginning of the protocol, or   just back to the previous step, where payment was requested? This requires problems   to be matched in a formal way to the state machine of a protocol underway.</li> </ol>"},{"location":"features/0035-report-problem/#the-report-problem-protocol","title":"The <code>report-problem</code> protocol","text":"<p>Reporting problems uses a simple one-step notification protocol. Its official PIURI is:</p> <pre><code>https://didcomm.org/report-problem/1.0\n</code></pre> <p>The protocol includes the standard <code>notifier</code> and <code>notified</code> roles. It defines a single message type <code>problem-report</code>, introduced here.</p> <p>A <code>problem-report</code> communicates about a problem when an agent-to-agent message is possible and a recipient for the problem report is known. This covers, for example, cases where a Sender's message gets to an intended Recipient, but the Recipient is unable to process the message for some reason and wants to notify the Sender. It may also be relevant in cases where the recipient of the <code>problem-report</code> is not a message Sender. Of course, a reporting technique that depends on message delivery doesn't apply when the error reporter can't identify or communicate with the proper recipient.</p>"},{"location":"features/0035-report-problem/#the-problem-report-message-type","title":"The <code>problem-report</code> message type","text":"<p>Only <code>description.code</code> is required, but a maximally verbose <code>problem-report</code> could contain all of the following:</p> <pre><code>{\n  \"@type\"            : \"https://didcomm.org/report-problem/1.0/problem-report\",\n  \"@id\"              : \"an identifier that can be used to discuss this error message\",\n  \"~thread\"          : \"info about the threading context in which the error occurred (if any)\",\n  \"description\"      : { \"en\": \"localized message\", \"code\": \"symbolic-name-for-error\" },\n  \"problem_items\"    : [ {\"&lt;item descrip&gt;\": \"value\"} ],\n  \"who_retries\"      : \"enum: you | me | both | none\",\n  \"fix_hint\"         : { \"en\": \"localized error-instance-specific hint of how to fix issue\"},\n  \"impact\"           : \"enum: message | thread | connection\",\n  \"where\"            : \"enum: you | me | other - enum: cloud | edge | wire | agency | ..\",\n  \"noticed_time\"     : \"&lt;time&gt;\",\n  \"tracking_uri\"     : \"\",\n  \"escalation_uri\"   : \"\"\n}\n</code></pre>"},{"location":"features/0035-report-problem/#field-reference","title":"Field Reference","text":"<p>Some fields will be relevant and useful in many use cases, but not always. Including empty or null fields is discouraged; best practice is to include as many fields as you can fill with useful data, and to omit the others.</p> <p>@id: An identifier for this message, as described in the message threading RFC. This decorator is STRONGLY recommended, because enables a dialog about the problem itself in a branched thread (e.g., suggest a retry, report a resolution, ask for more information).</p> <p>~thread: A thread decorator that places the <code>problem-report</code> into a thread context. If the problem was triggered in the processing of a message, then the triggering message is the head of a new thread of which the problem report is the second member (<code>~thread.sender_order</code> = 0). In such cases, the <code>~thread.pthid</code> (parent thread id) here would be the <code>@id</code> of the triggering message. If the problem-report is unrelated to a message, the thread decorator is mostly redundant, as <code>~thread.thid</code> must equal <code>@id</code>.</p> <p>description: Contains human-readable, localized alternative string(s) that explain the problem. It is highly recommended that the message follow use the guidance in the l10n RFC, allowing the error to be searched on the web and documented formally.</p> <p>description.code: Required. Contains the code that indicates the problem being communicated. Codes are described in protocol RFCs and other relevant places. New Codes SHOULD follow the Problem Code naming convention detailed in the DIDComm v2 spec.</p> <p>problem_items: A list of one or more key/value pairs that are parameters about the problem. Some examples might be:</p> <ul> <li>a list of arguments that didn\u2019t pass input validation</li> <li>the name of a file or URL that could not be fetched</li> <li>the name of a crypto algorithm that the receiving agent didn\u2019t support</li> </ul> <p>All items should have in common the fact that they exemplify the problem described by the code (e.g., each is an invalid param, or each is an unresponsive URL, or each is an unrecognized crypto algorithm, etc).</p> <p>Each item in the list must be a tagged pair (a JSON {key:value}, where the key names the parameter or item, and the value is the actual problem text/number/value. For example, to report that two different endpoints listed in party B\u2019s DID Doc failed to respond when they were contacted, the code might contain \"endpoint-not-responding\", and the problem_items property might contain:</p> <pre><code>[\n  {\"endpoint1\": \"http://agency.com/main/endpoint\"},\n  {\"endpoint2\": \"http://failover.agency.com/main/endpoint\"}\n]\n</code></pre> <p>who_retries: value is the string \"you\", the string \"me\", the string \"both\", or the string \"none\". This property tells whether a problem is considered permanent and who the sender of the problem report believes should have the responsibility to resolve it by retrying. Rules about how many times to retry, and who does the retry, and under what circumstances, are not enforceable and not expressed in the message text. This property is thus not a strong commitment to retry--only a recommendation of who should retry, with the assumption that retries will often occur if they make sense.</p> <p>[TODO: figure out how to identify parties &gt; 2 in n-wise interaction]</p> <p>fix_hint: Contains human-readable, localized suggestions about how to fix this instance of the problem. If present, this should be viewed as overriding general hints found in a message catalog.</p> <p>impact: A string describing the breadth of impact of the problem. An enumerated type:</p> <ul> <li>\"message\" (this is a problem with a single message only; the rest of the interaction may still be fine),</li> <li>\"thread\" (this is a problem that endangers or invalidates the entire thread),</li> <li>\"connection\" (this is a problem that endangers or invalidates the entire connection).</li> </ul> <p>where: A string that describes where the error happened, from the perspective of the reporter, and that uses the \"you\" or \"me\" or \"other\" prefix, followed by a suffix like \"cloud\", \"edge\", \"wire\", \"agency\", etc.</p> <p>noticed_time: Standard time entry (ISO-8601 UTC with at least day precision and up to millisecond precision) of when the problem was detected.</p> <p>[TODO: should we refer to timestamps in a standard way (\"date\"? \"time\"? \"timestamp\"? \"when\"?)]</p> <p>tracking_uri: Provides a URI that allows the recipient to track the status of the error. For example, if the error is related to a service that is down, the URI could be used to monitor the status of the service, so its return to operational status could be automatically discovered.</p> <p>escalation_uri: Provides a URI where additional help on the issue can be received. For example, this might be a \"mailto\" and email address for the Help Desk associated with a currently down service.</p>"},{"location":"features/0035-report-problem/#sample","title":"Sample","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/notification/1.0/problem-report\",\n  \"@id\": \"7c9de639-c51c-4d60-ab95-103fa613c805\",\n  \"~thread\": {\n    \"pthid\": \"1e513ad4-48c9-444e-9e7e-5b8b45c5e325\",\n    \"sender_order\": 1\n  },\n  \"~l10n\"            : {\"catalog\": \"https://didcomm.org/error-codes\"},\n  \"description\"      : \"Unable to find a route to the specified recipient.\",\n  \"description~l10n\" : {\"code\": \"cant-find-route\" },\n  \"problem_items\"    : [\n      { \"recipient\": \"did:sov:C805sNYhMrjHiqZDTUASHg\" }\n  ],\n  \"who_retries\"      : \"you\",\n  \"impact\"           : \"message\",\n  \"noticed_time\"     : \"2019-05-27 18:23:06Z\"\n}\n</code></pre>"},{"location":"features/0035-report-problem/#categorized-examples-of-errors-and-current-best-practice-handling","title":"Categorized Examples of Errors and (current) Best Practice Handling","text":"<p>The following is a categorization of a number of examples of errors and (current) Best Practice handling for those types of errors. The new <code>problem-report</code> message type is used for some of these categories, but not all.</p>"},{"location":"features/0035-report-problem/#unknown-error","title":"Unknown Error","text":"<p>Errors of a known error code will be processed according to the understanding of what the code means. Support of a protocol includes support and proper processing of the error codes detailed within that protocol.</p> <p>Any unknown error code that starts with <code>w.</code> in the DIDComm v2 style may be considered a warning, and the flow of the active protocol SHOULD continue. All other unknown error codes SHOULD be considered to be an end to the active protocol.</p>"},{"location":"features/0035-report-problem/#error-while-processing-a-received-message","title":"Error While Processing a Received Message","text":"<p>An Agent Message sent by a Sender and received by its intended Recipient cannot be processed.</p>"},{"location":"features/0035-report-problem/#examples","title":"Examples:","text":"<ul> <li>An error occurs in the processing of the message (e.g. missing required parameters, bad data in parameters, etc.)</li> <li>The recipient has no message handler for the message type</li> <li>A message request is rejected because of a policy</li> <li>\"Access denied\" scenarios</li> </ul>"},{"location":"features/0035-report-problem/#recommended-handling","title":"Recommended Handling","text":"<p>The Recipient should send the Sender a <code>problem-report</code> Agent Message detailing the issue.</p> <p>The last example deserves an additional comment about whether there should be a response sent at all. Particularly in cases where trust in the message sender is low (e.g. when establishing the connection), an Agent may not want to send any response to a rejected message as even a negative response could reveal correlatable information. That said, if a response is provided, the <code>problem-report</code> message type should be used.</p>"},{"location":"features/0035-report-problem/#error-while-routing-a-message","title":"Error While Routing A Message","text":"<p>An Agent in the routing flow of getting a message from a Sender to the Agent Message Recipient cannot route the message.</p>"},{"location":"features/0035-report-problem/#examples_1","title":"Examples:","text":"<ul> <li>Unknown \"To\" destination for the message</li> <li>Insufficient resources (disk space, network access)</li> <li>Unable to decrypt the message</li> </ul>"},{"location":"features/0035-report-problem/#recommended-handling_1","title":"Recommended Handling","text":"<p>If the Sender is known to the Agent having the problem, send a <code>problem-report</code> Agent Message detailing at least that a blocking issue occurred, and if relevant (such as in the first example), some details about the issue. If the message is valid, and the problem is related to a lack of resources (e.g. the second issue), also send a <code>problem-report</code> message to an escalation point within the domain.</p> <p>Alternatively, the capabilities described in 0034: Message Tracing could be used to inform others of the fact that an issue occurred.</p>"},{"location":"features/0035-report-problem/#messages-triggered-about-a-transaction","title":"Messages Triggered about a Transaction","text":""},{"location":"features/0035-report-problem/#examples_2","title":"Examples:","text":"<ul> <li>\"You\u2019re asking for more information than we agreed to\" or \"You\u2019re giving me more than I expected.\"</li> <li>Couldn\u2019t pay (insufficient funds, payment mechanism is offline\u2026)</li> <li>You violated the terms of service we agreed to, because I see that my info has been leaked.</li> <li>Your credential has been revoked (asynchronous)</li> <li>A is unwilling to consent to the terms and conditions that B proposes.</li> </ul>"},{"location":"features/0035-report-problem/#recommended-handling_2","title":"Recommended Handling","text":"<p>These types of error scenarios represent a gray error in handling between using the generic <code>problem-report</code> message format, or a message type that is part of the current transaction's message family. For example, the \"Your credential has been revoked\" might well be included as a part of the (TBD) standard Credentials Exchange message family. The \"more information\" example might be a generic error across a number of message families and so should trigger a <code>problem-report</code>) or, might be specific to the ongoing thread (e.g. Credential Exchange) and so be better handled by a defined message within that thread and that message family.</p> <p>The current advice on which to use in a given scenario is to consider how the recipient will handle the message. If the handler will need to process the response in a specific way for the transaction, then a message family-specific message type should be used. If the error is cross-cutting such that a common handler can be used across transaction contexts, then a generic <code>problem-report</code> should be used.</p> <p>\"Current advice\" implies that as we gain more experience with Agent To Agent messaging, the recommendations could get more precise.</p>"},{"location":"features/0035-report-problem/#messaging-channel-settings","title":"Messaging Channel Settings","text":""},{"location":"features/0035-report-problem/#examples_3","title":"Examples","text":"<ul> <li>\"Please resend so a different one of my agents can read this.\", or, \"Agent X no longer in service. Use Agent Y instead.\"</li> <li>A received a message from B that it cannot understand (message garbled, can\u2019t be decrypted, is of an unrecognized type, uses crypto from a library that A doesn\u2019t have, etc)</li> <li>A wants to report to B that it believes A has been hacked, or that it is under attack</li> <li>A wants to report to B that it believes B has been hacked, or that it is under attack</li> <li>Version incompatibilities of various kinds (transport version incompatibilities [http 1.1 vs. 2.0]; agent message type version incompatibilities)</li> </ul>"},{"location":"features/0035-report-problem/#recommended-handling_3","title":"Recommended Handling","text":"<p>These types of messages might or might not be triggered during the receipt and processing of a message, but either way, they are unrelated to the message and are really about the communication channel between the entities. In such cases, the recommended approach is to use a (TBD) standard message family to notify and rectify the issue (e.g. change the attributes of a connection). The definition of that message family is outside the scope of this RFC.</p>"},{"location":"features/0035-report-problem/#timeouts","title":"Timeouts","text":"<p>A special generic class of errors that deserves mention is the timeout, where a Sender sends out a message and does not receive back a response in a given time. In a distributed environment such as Agent to Agent messaging, these are particularly likely - and particularly difficult to handle gracefully. The potential reasons for timeouts are numerous:</p> <ul> <li>loss of connectivity</li> <li>resource errors with one of the Agents between the Sender and Receiver</li> <li>not yet detected key rotations (cached DIDDocs and encryption keys)</li> <li>errors occurring in an Agent unaware of the Sender (so cannot notify the sender of the issue)</li> <li>Recipient offline for an extended period</li> <li>disinterest on the part of the Recipient (received, but no response sent back)</li> </ul>"},{"location":"features/0035-report-problem/#recommended-handling_4","title":"Recommended Handling","text":"<p>Appropriate timeout handling is extremely contextual, with two key parameters driving the handling - the length of the waiting period before triggering the timeout and the response to a triggered timeout.</p> <p>The time to wait for a response should be dynamic by at least type of message, and ideally learned through experience. Messages requiring human interaction should have an inherently longer timeout period than a message expected to be handled automatically. Beyond that, it would be good for Agents to track response times by message type (and perhaps other parameters) and adjust timeouts to match observed patterns.</p> <p>When a timeout is received there are three possible responses, handled automatically or based on feedback from the user:</p> <ul> <li>Wait longer</li> <li>Retry</li> <li>Give up</li> </ul> <p>An automated \"wait longer\" response might be used when first interacting with a particular message type or identity, as the response cadence is learned.</p> <p>If the decision is to retry, it would be good to have support in areas covered by other RFCs. First, it would be helpful (and perhaps necessary) for the threading decorator to support the concept of retries, so that a Recipient would know when a message is a retry of an already sent message.  Next, on \"forward\" message types, Agents might want to know that a message was a retry such that they can consider refreshing DIDDoc/encryption key cache before sending the message along. It could also be helpful for a retry to interact with the Tracing facility so that more information could be gathered about why messages are not getting to their destination.</p> <p>Excessive retrying can exacerbate an existing system issue. If the reason for the timeout is because there is a \"too many messages to be processed\" situation, then sending retries simply makes the problem worse. As such, a reasonable backoff strategy should be used (e.g. exponentially increasing times between retries). As well, a strategy used at Uber is to flag and handle retries differently from regular messages. The analogy with Uber is not pure - that is a single-vendor system - but the notion of flagging retries such that retry messages can be handled differently is a good approach.</p>"},{"location":"features/0035-report-problem/#caveat-problem-report-loops","title":"Caveat: Problem Report Loops","text":"<p>Implementers should consider and mitigate the risk of an endless loop of error messages. For example:</p> <ul> <li>Alice sends a message to Bob that Bob doesn't recognize. Bob sends a <code>Problem Report</code> message to Alice.</li> <li>Alice doesn't understand the message from Bob and sends a <code>Problem Report</code> to Bob.</li> <li>Bob doesn't understand the message from Alice and sends a <code>Problem Report</code> to Alice. And so on...</li> </ul>"},{"location":"features/0035-report-problem/#recommended-handling_5","title":"Recommended Handling","text":"<p>How agents mitigate the risk of this problem is implementation specific, balancing loop-tracking overhead versus the likelihood of occurrence. For example, an agent implementation might have a counter on a connection object that is incremented when certain types of <code>Problem Report</code> messages are sent on that connection, and reset when any other message is sent. The agent could stop sending those types of <code>Problem Report</code> messages after the counter reaches a given value.</p>"},{"location":"features/0035-report-problem/#reference","title":"Reference","text":"<p>TBD</p>"},{"location":"features/0035-report-problem/#drawbacks","title":"Drawbacks","text":"<p>In many cases, a specific <code>problem-report</code> message is necessary, so formalizing the format of the message is also preferred over leaving it to individual implementations. There is no drawback to specifying that format now.</p> <p>As experience is gained with handling distributed errors, the recommendations provided in this RFC will have to evolve.</p>"},{"location":"features/0035-report-problem/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>The error type specification mechanism builds on the same approach used by the message type specifications. It's possible that additional capabilities could be gained by making runtime use of the error type specification - e.g. for the broader internationalization of the error messages.</p> <p>The main alternative to a formally defined error type format is leaving it to individual implementations to handle error notifications, which will not lead to an effective solution.</p>"},{"location":"features/0035-report-problem/#prior-art","title":"Prior art","text":"<p>A brief search was done for error handling in messaging systems with few useful results found. Perhaps the best was the Uber article referenced in the \"Timeout\" section above.</p>"},{"location":"features/0035-report-problem/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Can the Tracing facility provide a trusted way to better handle distributed errors in a production environment?</li> <li>Denial of service via problems that spam the wrong person with   a problem report.</li> </ul>"},{"location":"features/0035-report-problem/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes RFC 0036: Issue Credential Protocol The <code>problem-report</code> message is adopted by this protocol. MISSING test results RFC 0037: Present Proof Protocol The <code>problem-report</code> message is adopted by this protocol. MISSING test results Trinsic.id Commercial mobile and web app built using Aries Framework - .NET MISSING test results"},{"location":"features/0036-issue-credential/","title":"Aries RFC 0036: Issue Credential Protocol 1.0","text":"<ul> <li>Authors: Nikita Khateev</li> <li>Status: ADOPTED (But should move to deprecated)</li> <li>Since: 2019-05-28</li> <li>Status Note:  See RFC 0037 for the presentation part of using credentials.</li> <li>Supersedes: Indy HIPE PR #89; also Credential Exchange 0.1 -- IIW 2019</li> <li>Start Date: 2019-01-30</li> <li>Tags: feature, decorator, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0036-issue-credential/#version-change-log","title":"Version Change Log","text":""},{"location":"features/0036-issue-credential/#11propose-credential","title":"1.1/propose-credential","text":"<p>In version 1.1 of the propose-credential message, the following optional fields were added: schema_name, schema_version, and issuer_did.</p> <p>The previous version is 1.0/propose-credential.</p>"},{"location":"features/0036-issue-credential/#summary","title":"Summary","text":"<p>Formalizes messages used to issue a credential--whether the credential is JWT-oriented, JSON-LD-oriented, or ZKP-oriented. The general flow is similar, and this protocol intends to handle all of them. If you are using a credential type that doesn't fit this protocol, please raise a Github issue.</p>"},{"location":"features/0036-issue-credential/#motivation","title":"Motivation","text":"<p>We need a standard protocol for issuing credentials. This is the basis of interoperability between Issuers and Holders.</p>"},{"location":"features/0036-issue-credential/#tutorial","title":"Tutorial","text":""},{"location":"features/0036-issue-credential/#roles","title":"Roles","text":"<p>There are two roles in this protocol: Issuer and Holder. Technically, the latter role is only potential until the protocol completes; that is, the second party becomes a Holder of a credential by completing the protocol. However, we will use the term Holder throughout, to keep things simple.</p> <p>Note: When a holder of credentials turns around and uses those credentials to prove something, they become a Prover. In the sister RFC to this one, 0037: Present Proof, the Holder is therefore renamed to Prover. Sometimes in casual conversation, the Holder role here might be called \"Prover\" as well, but more formally, \"Holder\" is the right term at this phase of the credential lifecycle.</p>"},{"location":"features/0036-issue-credential/#states","title":"States","text":"<p>The choreography diagrams shown below detail how state evolves in this protocol, in a \"happy path.\" The states include:</p>"},{"location":"features/0036-issue-credential/#states-for-issuer","title":"states for Issuer","text":"<ul> <li>proposal-received</li> <li>offer-sent</li> <li>request-received</li> <li>credential-issued</li> <li>done</li> </ul>"},{"location":"features/0036-issue-credential/#states-for-holder","title":"states for Holder","text":"<ul> <li>proposal-sent</li> <li>offer-received</li> <li>request-sent</li> <li>credential-received</li> <li>done</li> </ul> <p>Errors might occur in various places. For example, an Issuer might offer a credential for a price that the Holder is unwilling to pay. All errors are modeled with a <code>problem-report</code> message. Easy-to-anticipate errors reset the flow as shown in the diagrams, and use the code <code>issuance-abandoned</code>; more exotic errors (e.g., server crashed at Issuer headquarters in the middle of a workflow) may have different codes but still cause the flow to be abandoned in the same way. That is, in this version of the protocol, all errors cause the state of both parties (the sender and the receiver of the <code>problem-report</code>) to revert to <code>null</code> (meaning it is no longer engaged in the protocol at all). Future versions of the protocol may allow more granular choices (e.g., requesting and receiving a (re-)send of the <code>issue-credential</code> message if the Holder times out while waiting in the <code>request-sent</code> state).</p>"},{"location":"features/0036-issue-credential/#messages","title":"Messages","text":"<p>The Issue Credential protocol consists of these messages:</p> <ul> <li><code>propose-credential</code> - potential Holder to Issuer (optional). Tells what the Holder hopes to receive.</li> <li><code>offer-credential</code> - Issuer to potential Holder (optional for some credential implementations; required for Hyperledger Indy). Tells what the Issuer intends to issue, and possibly, the price the Issuer expects to be paid.</li> <li><code>request-credential</code> - potential Holder to Issuer. If neither of the previous message types is used, this is the message that begins the protocol.</li> <li><code>issue-credential</code> - Issuer to new Holder. Attachment payload contains the actual credential.</li> </ul> <p>In addition, the <code>ack</code> and <code>problem-report</code> messages are adopted into the protocol for confirmation and error handling.</p> <p>Note: This protocol is about the messages that must be exchanged to issue verifiable credentials, NOT about the specifics of particular verifiable credential schemes. DIDComm attachments are deliberately used in messages to isolate the protocol flow/semantics from the credential artifacts themselves as separate constructs. Attachments allow credential formats and this protocol to evolve through versioning milestones independently instead of in lockstep. Links are provided in the message descriptions below, to describe how the protocol adapts to specific verifiable credential implementations.</p>"},{"location":"features/0036-issue-credential/#choreography-diagram","title":"Choreography Diagram","text":"Note: This diagram was made in draw.io. To make changes:  - upload the drawing HTML from this folder to the [draw.io](https://draw.io) site (Import From...GitHub), - make changes, - export the picture and HTML to your local copy of this repo, and - submit a pull request.  <p>The protocol has 3 alternative beginnings:</p> <ol> <li>The Issuer can begin with an offer.</li> <li>The Holder can begin with a proposal.</li> <li>the Holder can begin with a request.</li> </ol> <p>The offer and proposal messages are part of an optional negotiation phase and may trigger back-and-forth counters. A request is not subject to negotiation; it can only be accepted or rejected.</p> <p></p>"},{"location":"features/0036-issue-credential/#propose-credential","title":"Propose Credential","text":"<p>An optional message sent by the potential Holder to the Issuer to initiate the protocol or in response to a <code>offer-credential</code> message when the Holder wants some adjustments made to the credential data offered by Issuer.</p> <p>Note: In Hyperledger Indy, where the <code>request-credential</code> message can only be sent in response to an <code>offer-credential</code> message, the <code>propose-credential</code> message is the only way for a potential Holder to initiate the workflow.</p> <p>Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/1.1/propose-credential\",\n    \"@id\": \"&lt;uuid-of-propose-message&gt;\",\n    \"comment\": \"some comment\",\n    \"credential_proposal\": &lt;json-ld object&gt;,\n    \"schema_issuer_did\": \"DID of the proposed schema issuer\",\n    \"schema_id\": \"Schema ID string\",\n    \"schema_name\": \"Schema name string\",\n    \"schema_version\": \"Schema version string\",\n    \"cred_def_id\": \"Credential Definition ID string\"\n    \"issuer_did\": \"DID of the proposed issuer\"\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Proposal, so the proposal can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>credential_proposal</code> -- an optional JSON-LD object that represents the credential data that Prover wants to receive. It matches the schema of Credential Preview.</li> <li><code>schema_issuer_did</code> -- optional filter to request credential based on a particular Schema issuer DID.</li> <li><code>schema_id</code> -- optional filter to request credential based on a particular Schema. This might be helpful when requesting a version 1 passport instead of a version 2 passport, for example.</li> <li><code>schema_name</code> -- optional filter to request credential based on a schema name. This is useful to allow a more user-friendly experience of requesting a credential by schema name.</li> <li><code>schema_version</code> -- optional filter to request credential based on a schema version. This is useful to allow a more user-friendly experience of requesting a credential by schema name and version.</li> <li><code>cred_def_id</code> -- optional filter to request credential based on a particular Credential Definition. This might be helpful when requesting a commercial driver's license instead of an ordinary driver's license, for example.</li> <li><code>issuer_did</code> -- optional filter to request a credential issued by the owner of a particular DID.</li> </ul>"},{"location":"features/0036-issue-credential/#offer-credential","title":"Offer Credential","text":"<p>A message sent by the Issuer to the potential Holder, describing the credential they intend to offer and possibly the price they expect to be paid. In Hyperledger Indy, this message is required, because it forces the Issuer to make a cryptographic commitment to the set of fields in the final credential and thus prevents Issuers from inserting spurious data. In credential implementations where this message is optional, an Issuer can use the message to negotiate the issuing following receipt of a <code>request-credential</code> message.</p> <p>Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/1.0/offer-credential\",\n    \"@id\": \"&lt;uuid-of-offer-message&gt;\",\n    \"comment\": \"some comment\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"offers~attach\": [\n        {\n            \"@id\": \"libindy-cred-offer-0\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Offer, so the offer can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>credential_preview</code> -- a JSON-LD object that represents the credential data that Issuer is willing to issue. It matches the schema of Credential Preview;</li> <li><code>offers~attach</code> -- an array of attachments that further define the credential being offered. This might be used to clarify which formats or format versions will be issued.</li> <li>For Indy, the attachment includes a nonce and key correctness proof to facilitate integrity checks. It is a base64url-encoded version of the data returned from <code>indy_issuer_create_credential_offer()</code>.</li> </ul> <p>The Issuer may add a <code>~payment-request</code> decorator to this message to convey the need for payment before issuance. See the payment section below for more details.</p> <p>It is possible for an Issuer to add a <code>~timing.expires_time</code> decorator to this message to convey the idea that the offer will expire at a particular point in the future. Such behavior is not a special part of this protocol, and support for it is not a requirement of conforming implementations; the <code>~timing</code> decorator is simply a general possibility for any DIDComm message. We mention it here just to note that the protocol can be enriched in composable ways.</p>"},{"location":"features/0036-issue-credential/#request-credential","title":"Request Credential","text":"<p>This is a message sent by the potential Holder to the Issuer, to request the issuance of a credential. Where circumstances do not require a preceding Offer Credential message (e.g., there is no cost to issuance that the Issuer needs to explain in advance, and there is no need for cryptographic negotiation), this message initiates the protocol. In Hyperledger Indy, this message can only be sent in response to an Offer Credential message.</p> <p>Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/1.0/request-credential\",\n    \"@id\": \"&lt;uuid-of-request-message&gt;\",\n    \"comment\": \"some comment\",\n    \"requests~attach\": [\n        {\n            \"@id\": \"attachment id\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        },\n    ]\n}\n</code></pre> <p>Description of Fields:</p> <ul> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Request, so it can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>requests~attach</code> -- an array of attachments defining the requested formats for the credential.</li> <li>For Indy, the attachment is a base64url-encoded version of the data returned from <code>indy_prover_create_credential_req()</code>.</li> </ul> <p>This message may have a <code>~payment-receipt</code> decorator to prove to the Issuer that the potential Holder has satisfied a payment requirement. See the payment section below.</p>"},{"location":"features/0036-issue-credential/#issue-credential","title":"Issue Credential","text":"<p>This message contains as attached payload the credentials being issued and is sent in response to a valid Request Credential message.</p> <p>Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/1.0/issue-credential\",\n    \"@id\": \"&lt;uuid-of-issue-message&gt;\",\n    \"comment\": \"some comment\",\n    \"credentials~attach\": [\n        {\n            \"@id\": \"libindy-cred-0\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>comment</code> -- an optional field that provides human readable information about the issued credential, so it can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>credentials~attach</code> -- an array of attachments containing the issued credentials.</li> <li>For Indy, the attachment contains data from libindy about credential to be issued, base64url-encoded, as returned from <code>libindy</code>. For more information see the Libindy API.</li> </ul> <p>If the issuer wants an acknowledgement that the issued credential was accepted, this message must be decorated with <code>~please-ack</code>, and it is then best practice for the new Holder to respond with an explicit <code>ack</code> message as described in 0317: Please ACK Decorator.</p>"},{"location":"features/0036-issue-credential/#encoding-claims-for-indy-based-verifiable-credentials","title":"Encoding Claims for Indy-based Verifiable Credentials","text":"<p>Claims in Hyperledger Indy-based verifiable credentials are put into the credential in two forms, <code>raw</code> and <code>encoded</code>. <code>raw</code> is the actual data value, and <code>encoded</code> is the (possibly derived) integer value that is used in presentations. At this time, Indy does not take an opinion on the method used for encoding the raw value. This will change with the Rich Schema work that is underway in the Indy/Aries community, where the encoding method will be part of the credential metadata available from the public ledger.</p> <p>Until the Rich Schema mechanism is deployed, Aries issuers and verifiers must agree on the encoding method so that the verifier can check that the <code>raw</code> value returned in a presentation corresponds to the proven <code>encoded</code> value. The following is the encoding algorithm that MUST be used by Issuers when creating credentials and SHOULD be verified by Verifiers receiving presentations:</p> <ul> <li>keep any 32-bit integer as is</li> <li>for data of any other type:</li> <li>convert to string (use string \"None\" for null)</li> <li>encode via utf-8 to bytes</li> <li>apply SHA-256 to digest the bytes</li> <li>convert the resulting digest bytes, big-endian, to integer</li> <li>stringify the integer as a decimal.</li> </ul> <p>An example implementation in Python can be found here.</p> <p>A gist of test value pairs can be found here.</p>"},{"location":"features/0036-issue-credential/#preview-credential","title":"Preview Credential","text":"<p>This is not a message but an inner object for other messages in this protocol. It is used construct a preview of the data for the credential that is to be issued. Its schema follows:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/1.0/credential-preview\",\n    \"attributes\": [\n        {\n            \"name\": \"&lt;attribute name&gt;\",\n            \"mime-type\": \"&lt;type&gt;\",\n            \"value\": \"&lt;value&gt;\"\n        },\n        // more attributes\n    ]\n}\n</code></pre> <p>The main element is <code>attributes</code>. It is an array of (object) attribute specifications; the subsections below outline their semantics.</p>"},{"location":"features/0036-issue-credential/#attribute-name","title":"Attribute Name","text":"<p>The mandatory <code>\"name\"</code> key maps to the attribute name as a string.</p>"},{"location":"features/0036-issue-credential/#mime-type-and-value","title":"MIME Type and Value","text":"<p>The optional <code>mime-type</code> advises the issuer how to render a binary attribute, to judge its content for applicability before issuing a credential containing it. Its value parses case-insensitively in keeping with MIME type semantics of RFC 2045. If <code>mime-type</code> is missing, its value is null.</p> <p>The mandatory <code>value</code> holds the attribute value:</p> <ul> <li>if <code>mime-type</code> is missing (null), then <code>value</code> is a string. In other words, implementations interpret it the same as any other key+value pair in JSON</li> <li>if <code>mime-type</code> is not null, then <code>value</code> is always a base64url-encoded string that represents a binary BLOB, and <code>mime-type</code> tells how to interpret the BLOB after base64url-decoding.</li> </ul>"},{"location":"features/0036-issue-credential/#threading","title":"Threading","text":"<p>Threading can be used to initiate a sub-protocol during an issue credential protocol instance. For example, during credential issuance, the Issuer may initiate a child message thread to execute the <code>Present Proof</code> sub-protocol to have the potential Holder (now acting as a Prover) prove attributes about themselves before issuing the credential. Depending on circumstances, this might be a best practice for preventing credential fraud at issuance time.</p> <p>If threading were added to all of the above messages, a <code>~thread</code> decorator would be present, and later messages in the flow would reference the <code>@id</code> of earlier messages to stitch the flow into a single coherent sequence. Details about threading can be found in the 0008: Message ID and Threading RFC.</p>"},{"location":"features/0036-issue-credential/#payments-during-credential-exchange","title":"Payments during credential exchange","text":"<p>Credentialing ecosystems may wish to associate credential issuance with payments by fiat currency or tokens. This is common with non-digital credentials today; we pay a fee when we apply for a passport or purchase a plane ticket. Instead or in addition, some circumstances may fit a mode where payment is made each time a credential is used, as when a Verifier pays a Prover for verifiable medical data to be used in research, or when a Prover pays a Verifier as part of a workflow that applies for admittance to a university. For maximum flexibility, we mention payment possibilities here as well as in the sister 0037: Present Proof RFC.</p>"},{"location":"features/0036-issue-credential/#payment-decorators","title":"Payment decorators","text":"<p>Wherever they happen and whoever they involve, payments are accomplished with optional payment decorators. See 0075: Payment Decorators.</p>"},{"location":"features/0036-issue-credential/#payment-flow","title":"Payment flow","text":"<p>A <code>~payment-request</code> may decorate a Credential Offer from Issuer to Holder. When they do, a corresponding <code>~payment-receipt</code> should be provided on the Credential Request returned to the Issuer.</p> <p>During credential presentation, the Verifier may pay the Holder as compensation for Holder for disclosing data. This would require a <code>~payment-request</code> in a Presentation Proposal message, and a corresponding <code>~payment-receipt</code> in the subsequent Presentation Request. If such a workflow begins with the Presentation Request, the Prover may sending back a Presentation (counter-)Proposal with appropriate decorator inside it.</p>"},{"location":"features/0036-issue-credential/#limitations","title":"Limitations","text":"<p>Smart contracts may be missed in ecosystem, so operation \"issue credential after payment received\" is not atomic. It\u2019s possible case that malicious issuer will charge first and then will not issue credential in fact. But this situation should be easily detected and appropriate penalty should be applied in such type of networks.</p>"},{"location":"features/0036-issue-credential/#negotiation-and-preview","title":"Negotiation and Preview","text":"<p>Negotiation prior to issuing the credential can be done using the <code>offer-credential</code> and <code>propose-credential</code> messages. A common negotiation use case would be about the data to go into the credential. For that, the <code>credential_preview</code> element is used.</p>"},{"location":"features/0036-issue-credential/#reference","title":"Reference","text":"<ul> <li>VCX -- this implementation might not be perfect and needs to be improved, you can gather some info on parameters' purpose from it</li> <li>A pre-RFC (labelled version 0.1) implementation of the protocol was implemented by a number of groups in the Hyperledger Indy community leading up to IIW28 in April 2019. The protocol defined and implemented can be reviewed here. It was the basis of the IIWBook demo from BC Gov and collaborators.</li> </ul>"},{"location":"features/0036-issue-credential/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"features/0036-issue-credential/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"features/0036-issue-credential/#prior-art","title":"Prior art","text":"<p>Similar (but simplified) credential exchanged was already implemented in von-anchor.</p>"},{"location":"features/0036-issue-credential/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>We might need to propose a new MIME type for credential (the same way as .docx is not processed as generic xml). The issue in W3C/vc-data-model: https://github.com/w3c/vc-data-model/issues/421</li> <li>It is a common practice when changing some attributes in credential to revoke the old credential and issue a new one. It might be useful to have an element in the <code>offer-credential</code> message to indicate a connection between a now revoked credential and the new credential being offered.</li> <li>We might need some explicit documentation for nested <code>@type</code> fields.</li> <li>There should be a way to ask for some payment with <code>offer-credential</code> and to send a payment (or payment receipt) in the request-credential.</li> </ul>"},{"location":"features/0036-issue-credential/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Streetcred.id Commercial mobile and web app built using Aries Framework - .NET MISSING test results"},{"location":"features/0037-present-proof/","title":"Aries RFC 0037: Present Proof Protocol 1.0","text":"<ul> <li>Authors: Nikita Khateev</li> <li>Status: ADOPTED (But should move to deprecated)</li> <li>Since: 2019-05-28</li> <li>Status Note:  This v1.x version of the protocol will be replaced by version v2 defined in RFC 454.</li> <li>Supersedes: Indy HIPE PR #89; also Credential Exchange 0.1 -- IIW 2019</li> <li>Start Date: 2019-01-30</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0037-present-proof/#summary","title":"Summary","text":"<p>Formalization and generalization of existing message formats used for presenting a proof according to existing RFCs about message formats.</p>"},{"location":"features/0037-present-proof/#motivation","title":"Motivation","text":"<p>We need to define a standard protocol for presenting a proof.</p>"},{"location":"features/0037-present-proof/#tutorial","title":"Tutorial","text":"<p>The present proof protocol consists of these messages:</p> <ul> <li>Propose Proof - Prover to Verifier (optional)</li> <li>Request Proof - Verifier to Prover</li> <li>Present Proof - Prover to Verifier</li> </ul> <p>In addition, the <code>ack</code> and <code>problem-report</code> messages are adopted into the protocol for confirmation and error handling.</p> <p>This protocol is about the messages to support the presentation of verifiable claims, not about the specifics of particular verifiable presentation mechanisms. This is challenging since at the time of writing this version of the protocol, there is only one supported verifiable presentation mechanism(Hyperledger Indy). DIDComm attachments are deliberately used in messages to try to make this protocol agnostic to the specific verifiable presentation mechanism payloads. Links are provided in the message data element descriptions to details of specific verifiable presentation implementation data structures.</p> <p>Diagrams in this protocol were made in draw.io. To make changes:</p> <ul> <li>upload the drawing HTML from this folder to the draw.io site (Import From...GitHub),</li> <li>make changes,</li> <li>export the picture and HTML to your local copy of this repo, and</li> <li>submit a pull request.</li> </ul>"},{"location":"features/0037-present-proof/#states","title":"States","text":""},{"location":"features/0037-present-proof/#states-for-verifier","title":"states for Verifier","text":"<ul> <li>request-sent</li> <li>proposal-received</li> <li>request-received</li> <li>presentation-received</li> <li>done</li> </ul>"},{"location":"features/0037-present-proof/#states-for-prover","title":"states for Prover","text":"<ul> <li>request-received</li> <li>proposal-sent</li> <li>presentation-sent</li> <li>reject-sent</li> <li>done</li> </ul> <p>For the most part, these states map onto the transitions shown in the choreography diagram in obvious ways. However, a few subtleties are worth highlighting:</p> <ul> <li>The final transitions for the Verifier (Send Presentation Reject, Send Presentation Ack, and Receive Presentation Reject) all result in a final <code>done</code> state, but this <code>done</code> may or may not be the Verifier's intended outcome. We may want to tweak this in a future version of the protocol.</li> <li>A similar situation exists with the final transitions for the Prover and its final transitions (Send Presentation Reject, Receive Presentation Ack, and Receive Presentation Reject).</li> <li>When a Prover makes a (counter-)proposal, it transitions to the <code>proposal-sent</code> state. This state is only present by implication in the choreography diagram; it essentially equates to the null or begin state in that the Prover does nothing until a presentation request arrives, triggering the leftmost transition for the Prover.</li> </ul> <p>Errors might occur in various places. For example, a Verifier might time out waiting for the Prover to supply a presentation. Errors trigger a <code>problem-report</code>. In this version of the protocol, all errors cause the state of both parties (the sender and the receiver of the <code>problem-report</code>) to revert to <code>null</code> (meaning it is no longer engaged in the protocol at all). Future versions of the protocol may allow more granular choices.</p>"},{"location":"features/0037-present-proof/#choreography-diagram","title":"Choreography Diagram:","text":""},{"location":"features/0037-present-proof/#propose-presentation","title":"Propose Presentation","text":"<p>An optional message sent by the Prover to the verifier to initiate a proof presentation process, or in response to a <code>request-presentation</code> message when the Prover wants to propose using a different presentation format. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/propose-presentation\",\n    \"@id\": \"&lt;uuid-propose-presentation&gt;\",\n    \"comment\": \"some comment\",\n    \"presentation_proposal\": &lt;json-ld object&gt;\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>comment</code> -- a field that provides some human readable information about the proposed presentation.</li> <li><code>presentation_proposal</code> -- a JSON-LD object that represents the presentation example that Prover wants to provide. It should follow the schema of Presentation Preview;</li> </ul>"},{"location":"features/0037-present-proof/#request-presentation","title":"Request Presentation","text":"<p>From a verifier to a prover, the <code>request-presentation</code> message describes values that need to be revealed and predicates that need to be fulfilled. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/request-presentation\",\n    \"@id\": \"&lt;uuid-request&gt;\",\n    \"comment\": \"some comment\",\n    \"request_presentations~attach\": [\n        {\n            \"@id\": \"libindy-request-presentation-0\",\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>comment</code> -- a field that provides some human readable information about this request for a presentation.</li> <li><code>request_presentations~attach</code> -- an array of attachments defining the acceptable formats for the presentation.</li> <li>For Indy, the attachment contains data from libindy about the presentation request, base64url-encoded, as returned from <code>libindy</code>. For more information see the Libindy API.</li> </ul>"},{"location":"features/0037-present-proof/#presentation","title":"Presentation","text":"<p>This message is a response to a Presentation Request message and contains signed presentations. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/presentation\",\n    \"@id\": \"&lt;uuid-presentation&gt;\",\n    \"comment\": \"some comment\",\n    \"presentations~attach\": [\n        {\n            \"@id\": \"libindy-presentation-0\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>comment</code> -- a field that provides some human readable information about this presentation.</li> <li><code>presentations~attach</code> -- an array of attachments containing the presentation in the requested format(s).</li> <li>For Indy, the attachment contains data from libindy that is the presentation, base64url-encoded, as returned from <code>libindy</code>. For more information see the Libindy API.</li> </ul>"},{"location":"features/0037-present-proof/#verifying-claims-of-indy-based-verifiable-credentials","title":"Verifying Claims of Indy-based Verifiable Credentials","text":"<p>Claims in Hyperledger Indy-based verifiable credentials are put into the credential in two forms, <code>raw</code> and <code>encoded</code>. <code>raw</code> is the actual data value, and <code>encoded</code> is the (possibly derived) integer value that is used in presentations. At this time, Indy does not take an opinion on the method used for encoding the raw value. This will change with the Rich Schema work that is underway in the Indy/Aries community, where the encoding method will be part of the credential metadata available from the public ledger.</p> <p>Until the Rich Schema mechanism is deployed, the Aries issuers and verifiers must agree on an encoding method so that the verifier can check that the <code>raw</code> value returned in a presentation corresponds to the proven <code>encoded</code> value. The following is the encoding algorithm that MUST be used by Issuers when creating credentials and SHOULD be verified by Verifiers receiving presentations:</p> <ul> <li>keep any 32-bit integer as is</li> <li>for data of any other type:</li> <li>convert to string (use string \"None\" for null)</li> <li>encode via utf-8 to bytes</li> <li>apply SHA-256 to digest the bytes</li> <li>convert the resulting digest bytes, big-endian, to integer</li> <li>stringify the integer as a decimal.</li> </ul> <p>An example implementation in Python can be found here.</p> <p>A gist of test value pairs can be found here.</p>"},{"location":"features/0037-present-proof/#presentation-preview","title":"Presentation Preview","text":"<p>This is not a message but an inner object for other messages in this protocol. It is used to construct a preview of the data for the presentation. Its schema follows:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/presentation-preview\",\n    \"attributes\": [\n        {\n            \"name\": \"&lt;attribute_name&gt;\",\n            \"cred_def_id\": \"&lt;cred_def_id&gt;\",\n            \"mime-type\": \"&lt;type&gt;\",\n            \"value\": \"&lt;value&gt;\",\n            \"referent\": \"&lt;referent&gt;\"\n        },\n        // more attributes\n    ],\n    \"predicates\": [\n        {\n            \"name\": \"&lt;attribute_name&gt;\",\n            \"cred_def_id\": \"&lt;cred_def_id&gt;\",\n            \"predicate\": \"&lt;predicate&gt;\",\n            \"threshold\": &lt;threshold&gt;\n        },\n        // more predicates\n    ]\n}\n</code></pre> <p>The preview identifies attributes and predicates to present.</p>"},{"location":"features/0037-present-proof/#attributes","title":"Attributes","text":"<p>The mandatory <code>\"attributes\"</code> key maps to a list (possibly empty to propose a presentation with no attributes) of specifications, one per attribute. Each such specification proposes its attribute's characteristics for creation within a presentation.</p>"},{"location":"features/0037-present-proof/#attribute-name","title":"Attribute Name","text":"<p>The mandatory <code>\"name\"</code> key maps to the name of the attribute.</p>"},{"location":"features/0037-present-proof/#credential-definition-identifier","title":"Credential Definition Identifier","text":"<p>The optional <code>\"cred_def_id\"</code> key maps to the credential definition identifier of the credential with the current attribute. Note that since it is the holder who creates the preview and the holder possesses the corresponding credential, the holder must know its credential definition identifier.</p> <p>If the key is absent, the preview specifies attribute's posture in the presentation as a self-attested attribute. A self-attested attribute does not come from a credential, and hence any attribute specification without the <code>\"cred_def_id\"</code> key cannot use a <code>\"referent\"</code> key as per Referent below.</p>"},{"location":"features/0037-present-proof/#mime-type-and-value","title":"MIME Type and Value","text":"<p>The optional <code>mime-type</code> advises the verifier how to render a binary attribute, to judge its content for applicability before accepting a presentation containing it. Its value parses case-insensitively in keeping with MIME type semantics of RFC 2045. If <code>mime-type</code> is missing, its value is null.</p> <p>The optional <code>value</code>, when present, holds the value of the attribute to reveal in presentation:</p> <ul> <li>if <code>mime-type</code> is missing (null), then <code>value</code> is a string. In other words, implementations interpret it the same as any other key+value pair in JSON</li> <li>if <code>mime-type</code> is not null, then <code>value</code> is always a base64url-encoded string that represents a binary BLOB, and <code>mime-type</code> tells how to interpret the BLOB after base64-decoding.</li> </ul> <p>An attribute specification must specify a <code>value</code>, a <code>cred_def_id</code>, or both:</p> <ul> <li>if <code>value</code> is present and <code>cred_def_id</code> is absent, the preview proposes a self-attested attribute;</li> <li>if <code>value</code> and <code>cred_def_id</code> are both present, the preview proposes a verifiable claim to reveal in the presentation;</li> <li>if <code>value</code> is absent and <code>cred_def_id</code> is present, the preview proposes a verifiable claim not to reveal in the presentation.</li> </ul>"},{"location":"features/0037-present-proof/#referent","title":"Referent","text":"<p>The optional <code>referent</code> can be useful in specifying multiple-credential presentations. Its value indicates which credential will supply the attribute in the presentation. Sharing a <code>referent</code> value between multiple attribute specifications indicates that the holder's same credential supplies the attribute.</p> <p>Any attribute specification using a <code>referent</code> must also have a <code>cred_def_id</code>; any attribute specifications sharing a common <code>referent</code> value must all have the same <code>cred_def_id</code> value (see Credential Definition Identifier above).</p> <p>For example, a holder with multiple account credentials could use a presentation preview such as</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/presentation-preview\",\n    \"attributes\": [\n        {\n            \"name\": \"account\",\n            \"cred_def_id\": \"BzCbsNYhMrjHiqZDTUASHg:3:CL:1234:tag\",\n            \"value\": \"12345678\",\n            \"referent\": \"0\"\n        },\n        {\n            \"name\": \"streetAddress\",\n            \"cred_def_id\": \"BzCbsNYhMrjHiqZDTUASHg:3:CL:1234:tag\",\n            \"value\": \"123 Main Street\",\n            \"referent\": \"0\"\n        },\n    ],\n    \"predicates\": [\n    ]\n}\n</code></pre> <p>to prompt a verifier to request proof of account number and street address from the same account, rather than potentially an account number and street address from distinct accounts.</p>"},{"location":"features/0037-present-proof/#predicates","title":"Predicates","text":"<p>The mandatory <code>\"predicates\"</code> key maps to a list (possibly empty to propose a presentation with no predicates) of predicate specifications, one per predicate. Each such specification proposes its predicate's characteristics for creation within a presentation.</p>"},{"location":"features/0037-present-proof/#attribute-name_1","title":"Attribute Name","text":"<p>The mandatory <code>\"name\"</code> key maps to the name of the attribute.</p>"},{"location":"features/0037-present-proof/#credential-definition-identifier_1","title":"Credential Definition Identifier","text":"<p>The mandatory <code>\"cred_def_id\"</code> key maps to the credential definition identifier of the credential with the current attribute. Note that since it is the holder who creates the preview and the holder possesses the corresponding credential, the holder must know its credential definition identifier.</p>"},{"location":"features/0037-present-proof/#predicate","title":"Predicate","text":"<p>The mandatory <code>\"predicate\"</code> key maps to the predicate operator: <code>\"&lt;\"</code>, <code>\"&lt;=\"</code>, <code>\"&gt;=\"</code>, <code>\"&gt;\"</code>.</p>"},{"location":"features/0037-present-proof/#threshold-value","title":"Threshold Value","text":"<p>The mandatory <code>\"threshold\"</code> key maps to the threshold value for the predicate.</p>"},{"location":"features/0037-present-proof/#negotiation-and-preview","title":"Negotiation and Preview","text":"<p>Negotiation prior to the presentation can be done using the <code>propose-presentation</code> and <code>request-presentation</code> messages. A common negotiation use case would be about the data to go into the presentation. For that, the <code>presentation-preview</code> element is used.</p>"},{"location":"features/0037-present-proof/#reference","title":"Reference","text":"<ul> <li>VCX -- this implementation might not be perfect and needs to be improved, you can gather some info on parameters purpose from it</li> <li>A pre-RFC (labeled version 0.1) implementation of the protocol was implemented by a number of groups in the Hyperledger Indy community leading up to IIW28 in April 2019. The protocol can be found here. It was the basis of the IIWBook demo from BC Gov and collaborators.</li> </ul>"},{"location":"features/0037-present-proof/#drawbacks","title":"Drawbacks","text":"<p>The presentation preview as proposed above does not allow nesting of predicate logic along the lines of \"A and either B or C if D, otherwise A and B\", nor cross-credential-definition predicates such as proposing a legal name from either a financial institution or selected government entity.</p> <p>The presentation preview may be indy-centric, as it assumes the inclusion of at most one credential per credential definition. In addition, it prescribes exactly four predicates and assumes mutual understanding of their semantics (e.g., could <code>\"&gt;=\"</code> imply a lexicographic order for non-integer values, and if so, where to specify character collation algorithm?).</p> <p>Finally, the inclusion of non-revocation timestamps may become desirable at the preview stage; the standard as proposed does not accommodate such.</p>"},{"location":"features/0037-present-proof/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"features/0037-present-proof/#prior-art","title":"Prior art","text":"<p>Similar (but simplified) credential exchange was already implemented in von-anchor.</p>"},{"location":"features/0037-present-proof/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>We might need some explicit documentation for nested <code>@type</code> fields.</li> <li>There might need to be a way to associate a payment with the present proof protocol.</li> </ul>"},{"location":"features/0037-present-proof/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Streetcred.id Commercial mobile and web app built using Aries Framework - .NET MISSING test results"},{"location":"features/0042-lox/","title":"Aries RFC 0042: LOX -- A more secure pluggable framework for protecting wallet keys","text":"<ul> <li>Authors: Michael Lodder</li> <li>Status: DEMONSTRATED</li> <li>Since: 2019-05-30</li> <li>Start Date: 2019-05-30</li> <li>Tags: feature</li> </ul>"},{"location":"features/0042-lox/#summary","title":"Summary","text":"<p>Wallets are protected by secrets that must live outside of the wallet. This document proposes the Lox framework for managing the wallet access key(s).</p>"},{"location":"features/0042-lox/#motivation","title":"Motivation","text":"<p>Wallets currently use a single key to access the wallet. The key is provided directly or derived from a password. However, this is prone to misuse as most developers have little experience in key management. Right now there are no recommendations for protecting a key provided by Aries forcing implementors to choose methods based on their company's or organization's policies or practices.</p> <p>Here Millenial Mike demonstrates this process.</p> <p></p> <p>Some implementors have no policy or practice in place at all to follow leaving them to make bad decisions about managing wallet key storage and protection. For example, when creating an API token for Amazon's AWS, Amazon generates a secret key on a user's behalf and is downloaded to a CSV file. Many programmers do not know how to best protect these downloaded credentials because they must be used in a program to make API calls. They don't which of the following is the best option. They typically:</p> <ul> <li>Put these credentials directly in the program like most do as constant variables but this is a terrible option because attackers can analyze the code and extract it.</li> <li>Use environment variables. If so, should it passed as at the command level or put in a global variable registry? Both are susceptible to sniffing memory, process information, or inspecting command history.</li> <li>Read a config file that contains the credentials but must rely on the security of the operating system to manage access control.</li> </ul> <p>The less commonly used or known solution involves keyrings, hardware security modules (HSM), trusted execution environments (TEE), and secure enclaves.</p>"},{"location":"features/0042-lox/#keyrings","title":"Keyrings","text":"<p>Keyrings come preinstalled with modern operating systems without requiring installing additional software, but other keyrings software packages can be installed that function in a similar way. Operating systems protect keyring contents in encrypted files with access controls based on the logged in user and process accessing them. The keyring can only be unlocked if the same user, process, and keyring credentials are used when the keyring is created. Keyring credentials can be any combination of passwords, pins, keys, cyber tokens, and biometrics. In principle, a system's keyring should be able to keep credentials away from <code>root</code> (as in, the attacker can use the credential as long as they have access, but they can't extract the credential for persistence and assuming no other attacks like Foreshadow). Mac OS X, Windows, Linux Gnome-Keyring and KWallet, Android, and iOS have built-in enclaves that are protected by the operating system.</p> <p>Some systems back keyrings with hardware to increase security. The following flow chart illustrates how a keyring functions.</p> <p></p>"},{"location":"features/0042-lox/#secure-enclaves","title":"Secure Enclaves","text":"<p>Secure enclaves are used to describe HSMs, TPMs, and TEEs. An explaination of how secure enclaves work is detailed here.</p>"},{"location":"features/0042-lox/#details","title":"Details","text":"<p>To avoid the overuse of repeating each of these to describe a highly secure environment, the term enclave will be used to indicate all of them synonymously. Enclaves are specially designed to safeguard secrets but can be complex to use with varying APIs and libraries and are accessed using multiple various combinations of credentials. However, these complexities cause many to avoid using them.</p> <p>Where to put the wallet access credentials that are directly used by applications or people is called the top-level credential problem. Lox aims to provide guidance and aid in adopting best practices and developing code to address the top level credential problem\u2013-the credential used to protect all others\u2013the keys to the kingdom\u2013or a secret that is used directly by Aries that if compromised would yield disastrous consequences and give access to the wallet.</p>"},{"location":"features/0042-lox/#tutorial","title":"Tutorial","text":"<p>Lox is a layer that is designed to be an API for storing secrets with pluggable backends that implement reasonable defaults but is flexible to support various others that may be used.</p> <p>The default enclave will be the operating system keychain. Lox will also allow for many different enclaves that are optimal for storing keys like YubiKey, Hashicorp Vault, Intel SGX, or other methods supported by Hyperledger Ursa. Other hardware security modules can be plugged into the system via USB or accessed via the cloud. Trusted Platform Modules (TPMs) now come standard with many laptops and higher end tablets. Communication to enclaves can be done using drivers or over Unix or TCP sockets, or the Windows Communication Framework.</p> <p>The goal of Lox is to remove the complexity of the various enclaves by choosing the best secure defaults and hiding details that are prone to be misused or misunderstood, making it easier to secure the wallet.</p> <p></p>"},{"location":"features/0042-lox/#reference","title":"Reference","text":"<p>Currently, there are two methods that are used to open a wallet: provide the wallet encryption key or use a password based key derivation function to derive the key. Neither of these methods is directly terrible but there are concerns. Where should the symmetric encryption key be stored? What settings should be chosen for Argon2id? Argon2id also does not scale horizontally because settings that are secure for a desktop can be very slow to execute on a mobile device in the order of tens of seconds to minutes. To make it usable, the settings must be dialed down for the mobile device, but this allows faster attacks from a hacker. Also, passwords are often weak in that they are short, easily guessed, and have low entropy.</p> <p>Lox, on the other hand, allows a wallet user to access a wallet providing the ID of the credential that will be used to open the wallet, then letting the secure enclave handle authenticating the owner and securing access control. The enclave will restrict access to the currently logged in user so even an administrator cannot read the enclave contents or even access the hardware or TEE.</p> <p>For example, a user creates a new wallet and instead of specifying a key, can specify an ID like <code>youthful_burnell</code>. The user is prompted to provide the enclave credentials like biometrics, pins, authenticator tokens, etc. If successful, Lox creates the wallet access key, stores it in the enclave, opens the wallet, and securely wipes the memory holding the key. The calling program can even store the ID value since this alone is not enough to access the enclave. The program must also be running as the same owner of the secret. This allows static agents to store the ID in a config file without having to store the key.</p> <p>Enclaves will usually remain unlocked until certain events occur like: when the system goes to sleep, after a set time interval passes, the user logs out. When the event occurs, the enclave reverts to its locked state which requires providing the credentials again. These settings can be modified if needed like only going to the locked state after system boot up.</p> <p>The benefits provided by Lox are these</p> <ol> <li>Avoid having Aries users reinvent the wheel when they manage secrets just like an enclave but in less secure ways.</li> <li>Securely create keys with sufficient entropy from trusted cryptographic sources.</li> <li>Safely use keys and wipe them from memory when finished to limit side-channel attacks.</li> <li>Support for pluggable enclave backends by providing a single API. This flexible architecture allows for the wallet key to be protected by a different enclave on each system its stored.</li> <li>Hide various enclave implementations and complexity to increase misuse-resistance.</li> </ol> <p>The first API iteration proposal includes the following functions</p> <pre><code>function lox_create_wallet(wallet_name: String, config: Map&lt;String, ...&gt;)\nfunction lox_open_wallet(wallet_name: String, config: Map&lt;String, ...&gt;)\n</code></pre> <p><code>wallet_name</code> can be any human readable string. This value will vary based on the enclaves requirements as some allow different characters than others. <code>config</code> can include anything needed to specify the enclave and access it like a service name, remote IP address, and other miscellaneous settings. If nothing is specified, the operating system's default enclave will be used.</p> <p>Lox will be used to access the wallet in addition to providing the raw key for those that do not want to use Lox and want to continue to manage their own keys in their own way. Essentially a raw key provided to the wallet is setting the enclave backend to be a null provider. The function for deriving the wallet key from a password should be deprecated for reasons described earlier and use Lox instead.</p>"},{"location":"features/0042-lox/#drawbacks","title":"Drawbacks","text":"<p>This adds another layer to wallet security. The APIs must be thought through to accommodate as many possible enclaves that could be used as possible. Hardware enclave vendor APIs are similar but are all different and have not unified behind a common standard yet. Trying to account for all of these will be difficult and may require changes to the API.</p>"},{"location":"features/0042-lox/#prior-art","title":"Prior art","text":"<p>A brief overview of enclaves and their services have been discussed in the Indy wallet HIPE.</p>"},{"location":"features/0042-lox/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What enclaves should be supported besides the default provided by the operating system?</li> </ul>"},{"location":"features/0042-lox/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Reference Code Example rust code that implements Lox using OS keychains"},{"location":"features/0042-lox/reference_code/","title":"Lox","text":"<p>A command line tool for accessing various keychains or secure enclaves.</p>"},{"location":"features/0042-lox/reference_code/#the-problem","title":"The problem","text":"<p>Applications use several credentials today to secure data locally and during transmitted. However, bad habits happen when safeguarding these credentials. For example, when creating an API token for Amazon's AWS, Amazon generates a secret key on a user's behalf and is downloaded to a CSV file. Programmers do not know how to best sure these downloaded credentials because they must be used in a program to make API calls. They don't which of the following is the best option. They can:</p> <ul> <li>Put these credentials directly in the program like most do as constant variables but this is a terrible option because attackers can analyze the code and extract it.</li> <li>Use environment variables. If so, should it passed as at the command level or put in a global variable registry? Both are susceptible to sniffing memory or process information.</li> <li>Read a config file that contains the credentials but must rely on the security of the operating system to manage access control.</li> <li>Use secure enclaves to store the credentials but this just shifts to another problem as secure enclaves rely on yet another set of credentials to ensure the application has the correct authorization. These come as hardware security modules (HSM) or trusted execution environments (TEE)</li> <li>Require interaction with a user or group to supply the credential for each use or cache it for a period of time. This is usually done with passwords, pins, cyber tokens, and biometrics.</li> </ul> <p>Where to put the credential that is directly used by applications or people is called the top level credential problem.</p> <p>There are services like LeakLooker that browse the internet looking for credentials that can be scrapped and unfortunately but often succeed. Some projects have documented how to test credentials to see if they have been revealed. See keyhacks.</p> <p>These document aims to provide guidance and aid in adopting best practices and developing code to address the top level credential problem\u2013-the credential used to protect all others\u2013the keys to the kingdom\u2013or a secret that is used directly by a program that if compromised would yield disastrous consequences.</p>"},{"location":"features/0042-lox/reference_code/#the-solution","title":"The solution","text":"<p>Lox is a layer that is designed to be a command line tool or API library for storing secrets. The default is to use the operating system keychain. The goal is to add to Lox to allow for  many different enclaves that are optimal for storing the keys to the kingdom like YubiKey, Intel SGX, or Arm Trustzone. In principle, a system's secure enclave should be able to keep some credentials away from <code>root</code> (as in, the attacker can use the credential as long as they have access, but they can't extract the credential for persistence), and assuming no other attacks like Foreshadow.</p> <p>Mac OS X, Linux, and Android have built-in keychains that are guarded by the operating system. iOS and Android come with hardware secure enclaves or trusted execution environments for managing the secrets stored in the keychain.</p> <p>This first iteration uses the OS keychain or an equivalent and uses the command line or is a C callable API. Future work could allow for communication over unix or tcp sockets with Lox running as a daemon process.</p> <p>Currently Mac OS X offers support for a CLI tool and libraries but they are complex to understand and can be prone to misuse due to misunderstandings. Lox removes the complexity by choosing secure defaults so developers can focus on their job. </p> <p>Lox is written in Rust and has no external dependencies to do its job except DBus on linux.</p> <p>The program can be compiled from any OS to run on any OS. Lox-CLI is the command line tool while Lox is the library.</p>"},{"location":"features/0042-lox/reference_code/#run-the-program","title":"Run the program","text":"<p>Basic Usage</p> <p>Requires dbus library on linux.</p> <p>On ubuntu, this is libdbus-1-3 when running. On redhat, this is dbus when running.</p> <p>Gnome-keyring or KWallet must also be installed on Linux.</p> <p>Lox can be run either using cargo run -- \\&lt;args&gt; or if it is already built from source using ./lox.</p> <p>Lox tries to determine if input is a file or text. If a file exists that matches the entered text, Lox will read the contents. Otherwise, it will prompt the user for either the id of the secret or to enter a secret.</p> <p>Lox stores secrets based on a service name and an ID. The service name is the name of the program or process that only is allowed to access the secret with ID. Secrets can be retrieved, stored, or deleted.</p> <p>When secrets are stored, care should be given to not pass the value over the command line as it could be stored in the command line history. For this reason, either put the value in a file or Lox will read it from STDIN. After Lox stores the secret, Lox will securely wipe it from memory.</p>"},{"location":"features/0042-lox/reference_code/#caveat","title":"Caveat","text":"<p>One remaining problem is how to solve the service name provided to Lox.  Ideally Lox could compute it instead of supplied from the calling endpoint which can lie about the name. We can imagine an attacker who wants access to the aws credentials in the keychain just needs to know the service name and the id of the secret to request it. Access is still blocked by the operating system if the attacker doesn't know the keychain credentials similar to a password vault. If Lox could compute the service name then this makes it harder for an attacker to retrieve targeted secrets. However, this is better than the secrets existing in plaintext in code, config files, or environment variables.</p>"},{"location":"features/0042-lox/reference_code/#examples","title":"Examples","text":"<p>Lox takes at least two arguments: service_name and ID. When storing a secret, an additional parameter is needed. If omitted (the preferred method) the value is read from STDIN.</p>"},{"location":"features/0042-lox/reference_code/#storing-a-secret","title":"Storing a secret","text":"<pre><code>lox set aws 1qwasdrtyuhjnjyt987yh\nprompt&gt; ...&lt;Return&gt;\nSuccess\n</code></pre>"},{"location":"features/0042-lox/reference_code/#retrieve-a-secret","title":"Retrieve a secret","text":"<pre><code>lox get aws 1qwasdrtyuhjnjyt987yh\n&lt;Secret Value&gt;\n</code></pre>"},{"location":"features/0042-lox/reference_code/#delete-a-secret","title":"Delete a secret","text":"<pre><code>lox delete aws 1qwasdrtyuhjnjyt987yh\n</code></pre>"},{"location":"features/0042-lox/reference_code/#list-all-secrets","title":"List all secrets","text":"<p>Lox can read all values stored in the keyring. List will just list the name of all the values in the keyring without retrieving their actual values. <pre><code>lox list\n</code></pre></p> <pre><code>{\"application\": \"lox\", \"id\": \"apikey\", \"service\": \"aws\", \"username\": \"mike\", \"xdg:schema\": \"org.freedesktop.Secret.Generic\"}\n{\"application\": \"lox\", \"id\": \"walletkey\", \"service\": \"indy\", \"username\": \"mike\", \"xdg:schema\": \"org.freedesktop.Secret.Generic\"}\n</code></pre>"},{"location":"features/0042-lox/reference_code/#peek-secrets","title":"Peek secrets","text":"<p>Lox can retrieve all or a subset of secrets in the keyring. Peek without any arguments will pull out all keyring names and their values. Because Lox encrypts values before storing them in the keyring if it can, those values will be returned as hex values instead of their associated plaintext. Peek filtering is different based on the operating system. </p> <p>For OSX, filtering is based on the kind that should be read. It can be generic or internet passwords. generic only requires the service and account labels. internet requires the server, account, protocol, authentication_type values. Filters are supplied as name value pairs separated by = and multiple pairs separated by a comma. <pre><code>lox peek service=aws,account=apikey\n</code></pre></p> <p>For Linux, filtering is based on a subset of name value pairs of the attributes that match. For example, if the attributes in the keyring were like this <pre><code>{\"application\": \"lox\", \"id\": \"apikey\", \"service\": \"aws\", \"username\": \"mike\", \"xdg:schema\": \"org.freedesktop.Secret.Generic\"}\n{\"application\": \"lox\", \"id\": \"walletkey\", \"service\": \"indy\", \"username\": \"mike\", \"xdg:schema\": \"org.freedesktop.Secret.Generic\"}\n</code></pre> To filter based on id, run <pre><code>lox peek id=apikey\n</code></pre> To filter based on username AND service, run  <pre><code>lox peek username=mike,service=aws\n</code></pre></p> <p>For Windows, filtering is based on the credentials targetname and globbing. For example, if list returned <pre><code>{\"targetname\": \"MicrosoftAccount:target=SSO_POP_Device\"}\n{\"targetname\": \"WindowsLive:target=virtualapp/didlogical\"}\n{\"targetname\": \"LegacyGeneric:target=IEUser:aws:apikey\"}\n</code></pre> then filtering searches everything after \":target=\". In this case, if the value to be peeked is IEUser:aws:apikey, the following will return just that result <pre><code>lox.exe peek IE*\nlox.exe peek IE*apikey\nlox.ece peek IEUser:aws:apikey\n</code></pre></p>"},{"location":"features/0042-lox/reference_code/#build-from-source","title":"Build from source","text":"<p>[build-from-source]: # build-from-source</p> <p>To make a distributable executable, run the following commands:</p> <ol> <li>On Linux install dbus library. On a debian based OS this is libdbus-1-dev. On a Redhat based OS this is dbus-devel.</li> <li>curl https://sh.rustup.rs -sSf | sh -s -- -y - installs the run compiler</li> <li>cd reference_code/</li> <li>cargo build --release - when this is finished the executable is target/release/lox.</li> <li>For *nix users cp target/release/lox /usr/local/lib and chmod +x /usr/local/lib/lox</li> <li>For Windows users copy target/release/lox.exe to a folder and add that folder to your %PATH variable.</li> </ol> <p>Liblox is the library that can be linked to programs to manage secrets. Use the library for the underlying operating system that meets your needs</p> <ol> <li>liblox.dll - Windows</li> <li>liblox.so - Linux</li> <li>liblox.dylib - Mac OS X</li> </ol>"},{"location":"features/0042-lox/reference_code/#future-work","title":"FUTURE WORK","text":"<p>Allow for other enclaves like Hashicorp vault, LastPass, 1Password. Allow for steganography methods like using images or Microsoft Office files for storing the secrets.</p>"},{"location":"features/0043-l10n/","title":"Aries RFC 0043: l10n (Locali[s|z]ation)","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: DEMONSTRATED</li> <li>Since: 2019-04-01</li> <li>Status Note: Broadly socialized within the Indy community, and used in some of the other RFCs. Not yet implemented to any significant degree.</li> <li>Start Date: 2018-11-30</li> <li>Tags: feature, decorator</li> </ul>"},{"location":"features/0043-l10n/#summary","title":"Summary","text":"<p>Defines how to send a DIDComm message in a way that facilitates interoperable localization, so humans communicating through agents can interact without natural language barriers.</p>"},{"location":"features/0043-l10n/#motivation","title":"Motivation","text":"<p>The primary use case for DIDComm is to support automated processing, as with messages that lead to credential issuance, proof exchange, and so forth. Automated processing may be the only way that certain agents can process messages, if they are devices or pieces of software run by organizations with no human intervention.</p> <p>However, humans are also a crucial component of the DIDComm ecosystem, and many interactions have them as either a primary or a secondary audience. In credential issuance, a human may need to accept terms and conditions from the issuer, even if their agent navigates the protocol. Some protocols, like a chat between friends, may be entirely human-centric. And in any protocol between agents, a human may have to interpret errors.</p> <p>When humans are involved, locale and potential translation into various natural languages becomes important. Normally, localization is the concern of individual software packages. However, in DIDComm, the participants may be using different software, and the localization may be a cross-cutting concern--Alice's software may need to send a localized message to Bob, who's running different software. It therefore becomes useful to explore a way to facilitate localization that allows interoperability without imposing undue burdens on any implementer or participant.</p> <p>NOTE: JSON-LD also describes a localization mechanism. We have chosen not to use it, for reasons enumerated in the RFC about JSON-LD compatibility.</p>"},{"location":"features/0043-l10n/#tutorial","title":"Tutorial","text":"<p>Here we introduce some flexible and easy-to-use conventions. Software that uses these conventions should be able to add localization value in several ways, depending on needs.</p>"},{"location":"features/0043-l10n/#introducing-l10n","title":"Introducing <code>~l10n</code>","text":"<p>The default assumption about locale with respect to all DIDComm messages is that they are locale-independent, because they are going to be processed entirely by automation. Dates should be in ISO 8601 format, typically in UTC. Numbers should use JSON formatting rules (or, if embedded in strings, the \"C\" locale). Booleans and null values use JSON keywords.</p> <p>Strings tend to be somewhat more interesting. An agent message may contain many strings. Some will be keys; others may be values. Usually, keys do not need to be localized, as they will be interpreted by software (though see  Advanced Use Case for an example that does). Among string values, some may be locale-sensitive, while others may not. For example, consider the following fictional message that proposes a meeting between Alice and Bob:</p> <p></p> <p>Here, the string value named <code>proposed_location</code> need not be changed, no matter what language Bob speaks. But <code>note</code> might be worth localizing, in case Bob speaks French instead of English.</p> <p>We can't assume all text is localizable. This would result in silly processing, such as trying to translate the <code>first_name</code> field in a driver's license:</p> <p></p> <p>The <code>~l10n</code> decorator  (so-named because \"localization\" has 10 letters between \"l\" and \"n\") may be added  to the <code>note</code> field to meet this need:</p> <p></p> <p>If you are not familiar with this notion of field decorators, please review the section about scope in the RFC on decorators.</p>"},{"location":"features/0043-l10n/#decorator-at-message-scope","title":"Decorator at Message Scope","text":"<p>The example above is minimal. It shows a French localized alternative for the string value of <code>note</code> in the <code>note~l10n.fr</code> field. Any number of these alternatives may be provided, for any set of locales. Deciding whether to use one depends on knowing the locale of the content that's already in <code>note</code>, so <code>note~l10n.locale</code> is also provided.</p> <p>But suppose we evolved our message type, and it ended up having 2 fields that were localization-worthy. Both would likely use the same locale in their values, but we don't really want to repeat that locale twice. The preferred way to handle this is to decorate the message with semantics that apply message-wide, and to decorate fields with semantics that apply just to field instances or to fields in the abstracts. Following this pattern puts our example message into a more canonical form:</p> <p></p>"},{"location":"features/0043-l10n/#decorator-at-message-type-scope","title":"Decorator at Message Type Scope","text":"<p>Now we are declaring, at message scope, that <code>note</code> and <code>fallback_plan</code> are localizable and that their locale is <code>en</code>.</p> <p>It is worth noting that this information is probably true of all instances of messages of this type--not just this particular message. This raises the possibility of declaring the localization data at an evey higher level of abstraction. We do this by moving the decorator from a message instance to a message type. Decorators on a message type are declared in a section of the associated RFC named Localization (or \"Localisation\", for folks that like a different locale's spelling rules :-). In our example, the relevant section of the RFC might look like this:</p> <p></p> <p>This snippet contains one unfamiliar construct, <code>catalogs</code>, which will be discussed below. Ignore that for a moment and focus on the rest of the content. As this snippet mentions, the JSON fragment for <code>~l10n</code> that's displayed in the running text of the RFC should also be checked in to github with the RFC's markdown as <code>&lt;message type name&gt;~l10n.json</code>, so automated tools can consume the content without parsing markdown.</p> <p>Notice that the markdown section is hyperlinked back to this RFC so developers unfamiliar with the mechanism will end up reading this RFC for more details.</p> <p>With this decorator on the message type, we can now send our original message, with no message or field decorators, and localization is still fully defined:</p> <p></p> <p>Despite the terse message, its locale is known to be English, and the <code>note</code> field is known to be localizable, with current content also in English.</p> <p>One benefit of defining a <code>~l10n</code> decorator for a message family is that developers can add localization support to their messages without changing field names or schema, and with only a minor semver revision to a message's version.</p> <p>We expect most message types to use localization ../../features in more or less this form. In fact, if localization settings have much in common across a message family, the <code>Localization</code> section of a RFC may be defined not just for a message type, but for a whole message family.</p>"},{"location":"features/0043-l10n/#message-codes-and-catalogs","title":"Message Codes and Catalogs","text":"<p>When the same text values are used over and over again (as opposed to the sort of unpredictable, human-provided text that we've seen in the <code>note</code> field thus far), it may be desirable to identify a piece of text by a code that describes its meaning, and to publish an inventory of these codes and their localized alternatives. By doing this, a message can avoid having to include a huge inventory of localized alternatives every time it is sent.</p> <p>We call this inventory of message codes and their localized alternatives a message catalog. Catalogs may be helpful to track a list of common errors (think of symbolic constants like <code>EBADF</code> and <code>EBUSY</code>, and the short explanatory strings associated with them, in Posix's &lt;errno.h&gt;). Catalogs let translation be done once, and reused globally. Also, the code for a message can be searched on the web, even when no localized alternative exists for a particular language. And the message text in a default language can undergo minor variation without invalidating translations or searches.</p> <p>If this usage is desired, a special subfield named <code>code</code> may be included inside the map of localized alternatives:</p> <p></p> <p>Note, however, that a code for a localized message is not useful unless we know what that code means. To do that, we need to know where the code is defined. In other words, codes need a namespace or context. Usually, this namespace or context comes from the message family where the code is used, and codes are defined in the same RFC where the message family is defined.</p> <p>Message families that support localized text with predictable values should thus include or reference an official catalog of codes for those messages. A catalog is a dictionary of <code>code</code> \u2192 localized alternatives mappings. For example:</p> <p></p> <p>To associate this catalog with a message type, the RFC defining the message type should contain a \"Message Catalog\" section that looks like this:</p> <p></p> <p>Note the verbiage about an official, immutable URL. This is important because localized alternatives for a message code could be an attack vector if the message catalog isn't handled correctly. If a hacker is able to change the content of a catalog, they may be able to change how a message is interpreted by a human that's using localization support. For example, they could suggest that the <code>en</code> localized alternative for code \"warn-suspicious-key-in-use` is \"Key has been properly verified and is trustworthy.\" By having a tamper-evident version of the catalog (e.g., in github or published on a blockchain), devlopers can write software that only deals with canonical text or dynamically translated text, never with something the hacker can manipulate.</p> <p>In addition, the following best practices are recommended to maximize catalog usefulness:</p> <ol> <li> <p>Especially when displaying localized error text, software should also display the underlying code. (This is desirable anyway, as it allows searching the web for hints and discussion about the code.)</p> </li> <li> <p>Software that regularly deals with localizable fields of key messages should download a catalog of localizable alternatives in advance, rather than fetching it just in time.</p> </li> </ol>"},{"location":"features/0043-l10n/#connecting-code-with-its-catalog","title":"Connecting <code>code</code> with its catalog","text":"<p>We've described a catalog's structure and definition, but we haven't yet explained how it's referenced. This is done through the <code>catalogs</code> field inside a <code>~l10n</code> decorator. There was an example above, in the example of a \"Localization\" section for a RFC. The field name, <code>catalogs</code>, is plural; its value is an array of URIs that reference specific catalog versions. Any catalogs listed in this URI are searched, in the order given, to find the definition and corresponding localized alternatives for a given <code>code</code>.</p> <p>A <code>catalogs</code> field can be placed in a <code>~l10n</code> decorator at various scopes. If it appears at the message or field level, the catalogs it lists are searched before the more general catalogs.</p>"},{"location":"features/0043-l10n/#advanced-use-case","title":"Advanced Use Case","text":"<p>This section is not normative in this version of the RFC. It is considered experimental for now.</p> <p>Let's consider a scenario that pushes the localization ../../features to their limit. Suppose we have a family of DIDComm messages that's designed to exchange genealogical records. The main message type, <code>record</code>, has a fairly simple schema: it just contains <code>record_type</code>, <code>record_date</code>, and <code>content</code>. But <code>content</code> is designed to hold arbitrary sub-records from various archives: probate paperwork from France, military discharge records from Japan, christening certificates from Germany.</p> <p>Imagine that the UX we want to build on top of these messages is similar to the one at Ancestry.com:</p> <p></p> <p>Notice that the names of fields in this UX are all given in English. But how likely is it that a christening certificate from Germany will have English field names like \"Birth Data\" and \"Marriage Date\" in its JSON?</p> <p>The <code>record</code> message behind data like this might be:</p> <p></p> <p>In order to translate this data, not just values but also keys need to have associated <code>~l10n</code> data. We do this with a <code>locales</code> array. This allows us to specify very complex locale settings--including multiple locales in the same message, and locales on keys. We may still have the <code>~l10n.locale</code> array and similar fields to establish defaults that are overridden in <code>~l10n.locales</code>:</p> <pre><code>\"~l10n\": {\n  \"locales\": {\n    \"de\": [\"content.key@*\", \"content.Geburtstag\", \"content.Heiratsdatum\"]\n  }\n}\n</code></pre> <p>This says that all fields under <code>content</code> have names that are German, and that the <code>content.Geburtstag</code> and <code>content.Heiratsdatum</code> field values (which are of type date) are also represented in a German locale rather than the default ISO 8601.</p> <p>Besides supporting key localization, having a <code>~l10n.locales</code> array on a message, message type, or message family scope is an elegant, concise way to cope with messages that have mixed field locales (fields in a variety of locales).</p>"},{"location":"features/0043-l10n/#drawbacks","title":"Drawbacks","text":"<p>The major problem with this feature is that it introduces complexity. However, it is complexity that most developers can ignore unless or until they care about localization. Once that becomes a concern, the complexity provides important ../../features--and it remains nicely encapsulated.</p>"},{"location":"features/0043-l10n/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>We could choose not to support this feature.</p> <p>We could also use JSON-LD's <code>@language</code> feature. However, this feature has a number of limitations, as documented in the RFC about JSON-LD compatibility.</p>"},{"location":"features/0043-l10n/#prior-art","title":"Prior art","text":"<p>Java's property bundle mechanism, Posix's gettext() function, and many other localization techniques are well known. They are not directly applicable, mostly because they don't address the need to communicate with software that may or may not be using the same underlying mapping/localization mechanism.</p>"},{"location":"features/0043-l10n/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is encoding for units (e.g., the metric system vs. the British Imperial system)   something that should be associated with locale?</li> </ul>"},{"location":"features/0043-l10n/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes RFC 0035: Report Problem Protocol Depends on this mechanism to localize the <code>description</code> field of an error. RFC 0036: Issue Credential Protocol Depends on this mechanism to localize the <code>comment</code> field of a <code>propose-credential</code>, <code>offer-credential</code>, <code>request-credential</code>, or <code>issue-credential</code> message. RFC 0037: Present Proof Protocol Depends on this mechanism to localize the <code>comment</code> field of a <code>propose-presentation</code>, <code>offer-presentation</code>, or <code>presentation</code> message. RFC 0193: Coin Flip Protocol Uses this mechanism to localize the <code>comment</code> field, when human iteraction around coin tosses is a a goal."},{"location":"features/0043-l10n/localization-section/","title":"Localization section","text":""},{"location":"features/0043-l10n/localization-section/#localization","title":"Localization","text":"<p>By default, all instances of this message type carry localization metadata in the form of an implicit <code>~l10n</code> decorator that looks like this:</p> <p></p> <p>This <code>~l10n</code> JSON fragment is checked in next to the narrative content of this RFC as l10n.json.</p> <p>Individual messages can use the <code>~l10n</code> decorator to supplement or override these settings.</p>"},{"location":"features/0043-l10n/message-catalog-section/","title":"Message catalog section","text":""},{"location":"features/0043-l10n/message-catalog-section/#message-catalog","title":"Message Catalog","text":"<p>By default, all instances of this message type assume the following catalog in their <code>@l10n</code> data:</p> <p></p> <p>When referencing this catalog, please be sure you have the correct version. The official, immutable URL to this version of the catalog file is:</p> <pre><code>https://github.com/x/y/blob/dc525a27d3b75/text/myfamily/catalog.json\n</code></pre> <p>For more information, see the Message Catalog section of the localization RFC. </p>"},{"location":"features/0044-didcomm-file-and-mime-types/","title":"Aries RFC 0044: DIDComm File and MIME Types","text":"<ul> <li>Authors: Daniel Hardman, Kyle Den Hartog</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Revised as part of AIP 2.0 to ease the upcoming transition from DIDComm v1 to DIDComm v2.</li> <li>Start Date: 2018-11-13</li> <li>Tags: feature</li> </ul>"},{"location":"features/0044-didcomm-file-and-mime-types/#summary","title":"Summary","text":"<p>Defines the media (MIME) types and file types that hold DIDComm messages in encrypted, signed, and plaintext forms. Covers DIDComm V1, plus a little of V2 to clarify how DIDComm versions are detected.</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#motivation","title":"Motivation","text":"<p>Most work on DIDComm so far has assumed HTTP as a transport. However, we know that DID communication is transport-agnostic. We should be able to say the same thing no matter which channel we use.</p> <p>An incredibly important channel or transport for messages is digital files. Files can be attached to messages in email or chat, can be carried around on a thumb drive, can be backed up, can be distributed via CDN, can be replicated on distributed file systems like IPFS, can be inserted in an object store or in content-addressable storage, can be viewed and modified in editors, and support a million other uses.</p> <p>We need to define how files and attachments can contain DIDComm messages, and what the semantics of processing such files will be.</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#tutorial","title":"Tutorial","text":""},{"location":"features/0044-didcomm-file-and-mime-types/#media-types","title":"Media Types","text":"<p>Media types are based on the conventions of RFC6838. Similar to RFC7515, the <code>application/</code> prefix MAY be omitted and the recipient MUST treat media types not containing <code>/</code> as having the <code>application/</code> prefix present.</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#didcomm-v1-encrypted-envelope-dee","title":"DIDComm v1 Encrypted Envelope (*.dee)","text":"<p>The raw bytes of an encrypted envelope may be persisted to a file without any modifications whatsoever. In such a case, the data will be encrypted and packaged such that only specific receiver(s) can process it. However, the file will contain a JOSE-style header that can be used by magic bytes algorithms to detect its type reliably.</p> <p>The file extension associated with this filetype is <code>dee</code>, giving a globbing pattern  of <code>*.dee</code>; this should be be read as \"STAR DOT D E E\" or as \"D E E\" files.</p> <p>The name of this file format is \"DIDComm V1 Encrypted Envelope.\" We expect people to say, \"I am looking at a DIDComm V1 Encrypted Envelope\", or \"This file is in DIDComm V1 Encrypted Envelope format\", or \"Does my editor have a DIDComm V1 Encrypted Envelope plugin?\"</p> <p>Although the format of encrypted envelopes is derived from JSON and the JWT/JWE family of specs, no useful processing of these files will take place by viewing them as JSON, and viewing them as generic JWEs will greatly constrain which semantics are applied. Therefore, the recommended MIME type for *.dee files is <code>application/didcomm-envelope-enc</code>, with <code>application/jwe</code> as a fallback, and <code>application/json</code> as an even less desirable fallback. (In this, we are making a choice similar to the one that views <code>*.docx</code> files primarily as <code>application/msword</code> instead of <code>application/xml</code>.) If format evolution takes place, the version could become a parameter as described in RFC 1341: <code>application/didcomm-envelope-enc;v=2</code>.</p> <p>A recipient using the media type value MUST treat it as if <code>\u201capplication/\u201d</code> were prepended to any <code>\"typ\"</code> or <code>\"cty\"</code> value not containing a \u2018/\u2019 in compliance  with the JWE /JWS  family of specs.</p> <p>The default action for DIDComm V1 Encrypted Envelopes (what happens when a user double-clicks one) should be <code>Handle</code> (that is, process the message as if it had just arrived by some other transport), if the software handling the message is an agent. In other types of software, the default action might be to view the file. Other useful actions might include <code>Send</code>, <code>Attach</code> (to email, chat, etc), <code>Open with agent</code>, and <code>Decrypt to *.dp</code>.</p> <p>NOTE: The analog to this content type in DIDComm v2 is called a \"DIDComm Encrypted Message.\" Its format is slightly different. For more info, see Detecting DIDComm Versions below.</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#didcomm-v1-signed-envelopes-dse","title":"DIDComm V1 Signed Envelopes (*.dse)","text":"<p>When DIDComm messages are signed, the signing uses a JWS signing envelope. Often signing is unnecessary, since authenticated encryption proves the sender of the message to the recipient(s), but sometimes when non-repudiation is required, this envelope is used. It is also required when the recipient of a message is unknown, but tamper-evidence is still required, as in the case of a public invitation.</p> <p>By convention, DIDComm Signed Envelopes contain plaintext; if encryption is used in combination with signing, the DSE goes inside the DEE.</p> <p>The file extension associated with this filetype is <code>dse</code>, giving a globbing pattern  of <code>*.dse</code>; this should be be read as \"STAR DOT D S E\" or as \"D S E\" files.</p> <p>The name of this file format is \"DIDComm V1 Signed Envelope.\" We expect people to say, \"I am looking at a DIDComm V1 Signed Envelope\", or \"This file is in DIDComm V1 Signed Envelope format\", or \"Does my editor have a DIDComm V1 Signed Envelope plugin?\"</p> <p>As with *.dee files, the best way to hande *.dse files is to map them to a custom MIME type. The recommendation is <code>application/didcomm-sig-env</code>, with <code>application/jws</code> as a fallback, and <code>application/json</code> as an even less desirable fallback.</p> <p>A recipient using the media type value MUST treat it as if <code>\u201capplication/\u201d</code> were prepended to any <code>\"typ\"</code> or <code>\"cty\"</code> value not containing a \u2018/\u2019 in compliance  with the JWE /JWS family of specs.</p> <p>The default action for DIDComm V1 Signed Envelopes (what happens when a user double-clicks one) should be <code>Validate</code> (that is, process the signature to see if it is valid.</p> <p>NOTE: The analog to this content type in DIDComm v2 is called a \"DIDComm Signed Message.\" Its format is slightly different. For more info, see Detecting DIDComm Versions below.</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#didcomm-v1-messages-dm","title":"DIDComm V1 Messages (*.dm)","text":"<p>The plaintext representation of a DIDComm message--something like a credential offer, a proof request, a connection invitation, or anything else worthy of a DIDComm protocol--is JSON. As such, it should be editable by anything that expects JSON.</p> <p>However, all such files have some additional conventions, over and above the simple requirements of JSON. For example, key decorators have special meaning ( <code>@id</code>, <code>~thread</code>, <code>@trace</code> , etc). Nonces may be especially significant. The format of particular values such as DID and DID+key references is important. Therefore, we refer to these messages generically as JSON, but we also define a file format for tools that are aware of the additional semantics.</p> <p>The file extension associated with this filetype is <code>*.dm</code>, and should be read as \"STAR DOT D M\" or \"D M\" files. If a format evolution takes place, a subsequent version could be noted by appending a digit, as in <code>*.dm2</code> for second-generation <code>dm</code> files.</p> <p>The name of this file format is \"DIDComm V1 Message.\" We expect people to say, \"I am looking at a DIDComm V1 Message\", or \"This file is in DIDComm V1 Message format\", or \"Does my editor have a DIDComm V1 Message plugin?\" For extra clarity, it is acceptable to add the adjective \"plaintext\", as in \"DIDComm V1 Plaintext Message.\"</p> <p>The most specific MIME type of *.dm files is <code>application/json;flavor=didcomm-msg</code>--or, if more generic handling is appropriate, just  <code>application/json</code>.</p> <p>A recipient using the media type value MUST treat it as if <code>\u201capplication/\u201d</code> were prepended to any <code>\"typ\"</code> or <code>\"cty\"</code> value not containing a \u2018/\u2019 in compliance  with the JWE /JWS family of specs.</p> <p>The default action for DIDComm V1 Messages should be to <code>View</code> or <code>Validate</code> them. Other interesting actions might be <code>Encrypt to *.dee</code>, <code>Sign to *.dse</code>, and <code>Find definition of protocol</code>.</p> <p>NOTE: The analog to this content type in DIDComm v2 is called a \"DIDComm Plaintext Message.\" Its format is slightly different. For more info, see Detecting DIDComm Versions below.</p> <p>As a general rule, DIDComm messages that are being sent in production use cases of DID communication should be stored in encrypted form (<code>*.dee</code>) at rest. There are cases where this might not be preferred, e.g., providing documentation of the format of message or during a debugging scenario using message tracing. However, these are exceptional cases. Storing meaningful <code>*.dm</code> files decrypted is not a security best practice, since it replaces all the privacy and security guarantees provided by the DID communication mechanism with only the ACLs and other security barriers that are offered by the container.</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#native-object-representation","title":"Native Object representation","text":"<p>This is not a file format, but rather an in-memory form of a DIDComm Message using whatever object hierarchy is natural for a programming language to map to and from JSON. For example, in python, the natural Native Object format is a dict that contains properties indexed by strings. This is the representation that python's <code>json</code> library expects when converting to JSON, and the format it produces when converting from JSON. In Java, Native Object format might be a bean. In C++, it might be a <code>std::map&lt;std::string, variant&gt;</code>...</p> <p>There can be more than one Native Object representation for a given programming language.</p> <p>Native Object forms are never rendered directly to files; rather, they are serialized to DIDComm Plaintext Format and then persisted (likely after also encrypting to DIDComm V1 Encrypted Envelope).</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#negotiating-compatibility","title":"Negotiating Compatibility","text":"<p>When parties want to communicate via DIDComm, a number of mechanisms must align. These include:</p> <ol> <li>The type of service endpoint used by each party</li> <li>The key types used for encryption and/or signing</li> <li>The format of the encryption and/or signing envelopes</li> <li>The encoding of plaintext messages</li> <li>The protocol used to forward and route</li> <li>The protocol embodied in the plaintext messages</li> </ol> <p>Although DIDComm allows flexibility in each of these choices, it is not expected that a given DIDComm implementation will support many permutations. Rather, we expect a few sets of choices that commonly go together. We call a set of choices that work well together a profile. Profiles are identified by a string that matches the conventions of IANA media types, but they express choices about plaintext, encryption, signing, and routing in a single value. The following profile identifiers are defined in this version of the RFC:</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#defined-profiles","title":"Defined Profiles","text":"<ul> <li><code>didcomm/aip1</code>: The encryption envelope, signing mechanism, plaintext conventions, and routing algorithms embodied in Aries AIP 1.0, circa 2020.</li> <li><code>didcomm/aip2;env=rfc19</code>: The signing mechanism, plaintext conventions, and routing algorithms embodied in Aries AIP 2.0, circa 2021 -- with the old-style encryption envelope from Aries RFC 0019. This legal variant of AIP 2.0 minimizes differences with codebases that shipped AIP 1.0 support.</li> <li><code>didcomm/aip2;env=rfc587</code>: The signing mechanism, plaintext conventions, and routing algorithms embodied in Aries AIP 2.0, circa 2021 -- with the new-style encryption envelope from Aries RFC 0587. This legal variant of AIP 2.0 lays the foundation for DIDComm v2 support by anticipating the eventual envelope change.</li> <li><code>didcomm/v2</code>: The encryption envelope, signing mechanism, plaintext conventions, and routing algorithms embodied in the DIDComm messaging spec.</li> </ul> <p>Profiles are named in the <code>accept</code> section of a DIDComm service endpoint and in an out-of-band message. When Alice declares that she accepts <code>didcomm/aip2;env=rfc19</code>, she is making a declaration about more than her own endpoint. She is saying that all publicly visible steps in an inbound route to her will use the <code>didcomm/aip2;env=rfc19</code> profile, such that a sender only has to use <code>didcomm/aip2;env=rfc19</code> choices to get the message from Alice's outermost mediator to Alice's edge. It is up to Alice to select and configure mediators and internal routing in such a way that this is true for the sender.</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#detecting-didcomm-versions","title":"Detecting DIDComm Versions","text":"<p>Because media types differ from DIDComm V1 to V2, and because media types are easy to communicate in headers and message fields, they are a convenient way to detect which version of DIDComm applies in a given context:</p> Nature of Content V1 V2 encrypted <code>application/didcomm-envelope-enc</code>DIDComm V1 Encrypted Envelope*.dee <code>application/didcomm-encrypted+json</code>DIDComm Encrypted Message*.dcem signed <code>application/didcomm-sig-env</code>DIDComm V1 Signed Envelope*.dse <code>application/didcomm-signed+json</code>DIDComm Signed Message*.dcsm plaintext <code>application/json;flavor=didcomm-msg</code>DIDComm V1 Message*.dm <code>application/didcomm-plain+json</code>DIDComm Plaintext Message*.dcpm <p>It is also recommended that agents implementing Discover Features Protocol v2 respond to queries about supported DIDComm versions using the <code>didcomm-version</code> feature name. This allows queries about what an agent is willing to support, whereas the media type mechanism describes what is in active use. The values that should be returned from such a query are URIs that tell where DIDComm versions are developed:</p> Version URI V1 https://github.com/hyperledger/aries-rfcs V2 https://github.com/decentralized-identity/didcomm-messaging"},{"location":"features/0044-didcomm-file-and-mime-types/#what-it-means-to-implement-this-rfc","title":"What it means to \"implement\" this RFC","text":"<p>For the purposes of Aries Interop Profiles, an agent \"implements\" this RFC when:</p> <ul> <li>If it encounters references to DIDComm V1 media types (e.g., in HTTP headers, in attachments, or in the fields of DIDComm messages where a media type is expected), it imputes the meaning documented here.</li> <li>If it characterizes DIDComm V1 content in its own outbound communication or UI, it does so with the media type strings, friendly names, and file extensions documented here.</li> </ul>"},{"location":"features/0044-didcomm-file-and-mime-types/#reference","title":"Reference","text":"<p>The file extensions and MIME types described here are also accompanied by suggested graphics. Vector forms of these graphics are available.</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0048-trust-ping/","title":"Aries RFC 0048: Trust Ping Protocol 1.0","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-02-01</li> <li>Status Note: Numerous implementations. </li> <li>Supersedes: Indy HIPE 0032</li> <li>Start Date: 2018-12-11</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"features/0048-trust-ping/#summary","title":"Summary","text":"<p>Describe a standard way for agents to test connectivity, responsiveness, and security of a pairwise channel.</p>"},{"location":"features/0048-trust-ping/#motivation","title":"Motivation","text":"<p>Agents are distributed. They are not guaranteed to be connected or running all the time. They support a variety of transports, speak a variety of protocols, and run software from many different vendors.</p> <p>This can make it very difficult to prove that two agents have a functional pairwise channel. Troubleshooting connectivity, responsivenes, and security is vital.</p>"},{"location":"features/0048-trust-ping/#tutorial","title":"Tutorial","text":"<p>This protocol is analogous to the familiar <code>ping</code> command in networking--but because it operates over agent-to-agent channels, it is transport agnostic and asynchronous, and it can produce insights into privacy and security that a regular ping cannot.</p>"},{"location":"features/0048-trust-ping/#roles","title":"Roles","text":"<p>There are two parties in a trust ping: the <code>sender</code> and the <code>receiver</code>. The sender initiates the trust ping. The receiver responds. If the receiver wants to do a ping of their own, they can, but this is a new interaction in which they become the sender.</p>"},{"location":"features/0048-trust-ping/#messages","title":"Messages","text":"<p>The trust ping interaction begins when <code>sender</code> creates a <code>ping</code> message like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/trust_ping/1.0/ping\",\n  \"@id\": \"518be002-de8e-456e-b3d5-8fe472477a86\",\n  \"~timing\": {\n    \"out_time\": \"2018-12-15 04:29:23Z\",\n    \"expires_time\": \"2018-12-15 05:29:23Z\",\n    \"delay_milli\": 0\n  },\n  \"comment\": \"Hi. Are you listening?\",\n  \"response_requested\": true\n}\n</code></pre> <p>Only <code>@type</code> and <code>@id</code> are required; <code>~timing.out_time</code>, <code>~timing.expires_time</code>,  and <code>~timing.delay_milli</code> are optional message timing decorators, and <code>comment</code> follows the conventions of localizable message fields. If present, it may be used to display a human-friendly description of the ping to a user that gives approval to respond. (Whether an agent responds to a trust ping is a decision for each agent owner to make, per policy and/or interaction with their agent.)</p> <p>The <code>response_requested</code> field deserves special mention. The normal expectation of a trust ping is that it elicits a response. However, it may be desirable to do a unilateral trust ping at times--communicate information without any expecation of a reaction. In this case, <code>\"response_requested\": false</code> may be used. This might be useful, for example, to defeat correlation between request and response (to generate noise). Or agents A and B might agree that periodically A will ping B without a response, as a way of evidencing that A is up and functional. If <code>response_requested</code> is false, then the receiver MUST NOT respond.</p> <p>When the message arrives at the receiver, assuming that <code>response_requested</code> is not <code>false</code>, the receiver should reply as quickly as possible with a <code>ping_response</code> message that looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/trust_ping/1.0/ping_response\",\n  \"@id\": \"e002518b-456e-b3d5-de8e-7a86fe472847\",\n  \"~thread\": { \"thid\": \"518be002-de8e-456e-b3d5-8fe472477a86\" },\n  \"~timing\": { \"in_time\": \"2018-12-15 04:29:28Z\", \"out_time\": \"2018-12-15 04:31:00Z\"},\n  \"comment\": \"Hi yourself. I'm here.\"\n}\n</code></pre> <p>Here, <code>@type</code> and <code>~thread</code> are required, and the rest is optional.</p>"},{"location":"features/0048-trust-ping/#trust","title":"Trust","text":"<p>This is the \"trust ping protocol\", not just the \"ping protocol.\" The \"trust\" in its name comes from several ../../features that the interaction gains by virtue of its use of standard agent-to-agent conventions:</p> <ol> <li> <p>Messages should be associated with a message trust context that allows sender and receiver to evaluate how much trust can be placed in the channel. For example, both sender and receiver can check whether messages are encrypted with suitable algorithms and keys.</p> </li> <li> <p>Messages may be targeted at any known agent in the other party's sovereign domain, using cross-domain routing conventions, and may be encrypted and packaged to expose exactly and only the information desired, at each hop along the way. This allows two parties to evaluate the completeness of a channel and the alignment of all agents that maintain it.</p> </li> <li> <p>This interaction may be traced using the general message tracing mechanism.</p> </li> </ol>"},{"location":"features/0048-trust-ping/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull  request to add your implementation. If the implementation is open source,  include a link to the repo or to the implementation within the repo. Please be  consistent in the \"Name\" field so that a mechanical processing of the RFCs can  generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community; MISSING test results Aries Framework - .NET .NET framework for building agents of all types; MISSING test results Streetcred.id Commercial mobile and web app built using Aries Framework - .NET; MISSING test results Aries Cloud Agent - Python Contributed by the government of British Columbia.; MISSING test results Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases.; MISSING test results Aries Protocol Test Suite MISSING test results"},{"location":"features/0056-service-decorator/","title":"Aries RFC 0056: Service Decorator","text":"<ul> <li>Authors: Sam Curren, Tobias Looker</li> <li>Status: PROPOSED</li> <li>Since: 2019-06-03</li> <li>Status Note: Needs refinement and validation, will be useful in any connectionless communication.</li> <li>Start Date: 2019-06-03</li> <li>Tags: feature, decorator</li> </ul>"},{"location":"features/0056-service-decorator/#summary","title":"Summary","text":"<p>The <code>~service</code> decorator describes a DID service endpoint inline to a message.</p>"},{"location":"features/0056-service-decorator/#motivation","title":"Motivation","text":"<p>This allows messages to self contain endpoint and routing information normally in a DID Document. This comes in handy when DIDs or DID Documents have not been exchanged.</p> <p>Examples include the Connect Protocol and Challenge Protocols.</p> <p>The <code>~service</code> decorator on a message contains the service definition that you might expect to find in a DID Document. These values function the same way.</p>"},{"location":"features/0056-service-decorator/#tutorial","title":"Tutorial","text":"<p>Usage looks like this, with the contents defined the Service Endpoint section of the DID Spec:</p> <pre><code>{\n    \"@type\": \"somemessagetype\",\n    \"~service\": {\n        \"recipientKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"],\n        \"routingKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"]\n        \"serviceEndpoint\": \"https://example.com/endpoint\"\n    }\n}\n</code></pre>"},{"location":"features/0056-service-decorator/#reference","title":"Reference","text":"<p>The contents of the <code>~service</code> decorator are defined by the Service Endpoint section of the DID Spec.</p> <p>The decorator should not be used when the message recipient already has a service endpoint.</p>"},{"location":"features/0056-service-decorator/#drawbacks","title":"Drawbacks","text":"<p>The current service block definition is not very compact, and could cause problems when attempting to transfer a message via QR code.</p>"},{"location":"features/0056-service-decorator/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Use of any other format would be yet a new format. Piggybacking upon the DID spec allows common logic to process the data in both places.</li> </ul>"},{"location":"features/0056-service-decorator/#prior-art","title":"Prior art","text":"<p>The Connect Protocol had previously included this same information as an attribute of the messages themselves.</p>"},{"location":"features/0056-service-decorator/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>We need a way to specify types and formats for inline keys</li> <li>Does allowing multiple service type definitions make sense?</li> <li>Should we allow for pointing to a remote service block instead of including it line?</li> <li>Should we allow for the decorator to be used within an existing connection? What should the behavior be? What security vulnerabilities does this present?</li> </ul>"},{"location":"features/0056-service-decorator/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0066-non-repudiable-cryptographic-envelope/","title":"Aries RFC 0066: Non-Repudiable Signature for Cryptographic Envelope","text":"<ul> <li>Authors: Kyle Den Hartog</li> <li>Status: PROPOSED</li> <li>Since: 2019-04-15</li> <li>Status Note: This is a second attempt to integrate non-repudiable digital signatures based on learnings and discussions over the past few months. This focuses only on the signing of entire messages. Signature Decorators will be handled seperately.</li> <li>Start Date: 2019-04-15</li> <li>Tags: feature</li> </ul>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#summary","title":"Summary","text":"<p>This HIPE is intended to highlight the ways that a non-repudiable signature could be added to a message field or message family through the use of JSON Web Signatures format.</p>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#motivation","title":"Motivation","text":"<p>Non-repudiable digital signatures serve as a beneficial method to provide proof of provenance of a message. There's many use cases where non-repudiable signatures are necessary and provide value. Some examples may be for a bank to keep on record when a mortgage is being signed. Some of the early use cases where this is going to be of value is going to be in the connection initiate protocol and the ephemeral challenge protocol. The expected outcome of this RFC is to define a method for using non-repudiable digital signatures in the cryptographic envelope layer of DID Communications.</p>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#tutorial","title":"Tutorial","text":""},{"location":"features/0066-non-repudiable-cryptographic-envelope/#json-web-signatures","title":"JSON Web Signatures","text":"<p>The JSON Web Signatures specification is written to define how to represent content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) based data structures.</p> <p>Our particular interest is in the use of non-repudiable digital signature using the ed25519 curve with edDSA signatures to sign invitation messages as well as sign full content layer messages.</p>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#when-should-non-repudiable-signatures-be-used","title":"When should non-repudiable signatures be used?","text":"<p>As highlighted in the repudiation RFC #0049, non-repudiable signatures are not always necessary and SHOULD NOT be used by default. The primary instances where a non-repudiable digital signature should be used is when a signer expects and considers it acceptable that a receiver can prove the sender sent the message.</p> <p>If Alice is entering into a borrower:lender relationship with Carol, Carol needs to prove to third parties that Alice, and only Alice, incurred the legal obligation.</p> <p>A good rule of thumb for a developer to decide when to use a non-repudiable signature is:</p> <p>\"Does the Receiver need to be able to prove who created the message to another person?\"</p> <p>In most cases, the answer to this is likely no. The few cases where it does make sense is when a message is establishing some burden of legal liability.</p>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#reference","title":"Reference","text":"<p>Provide guidance for implementers, procedures to inform testing, interface definitions, formal function prototypes, error codes, diagrams, and other technical details that might be looked up. Strive to guarantee that:</p> <ul> <li>Interactions with other ../../features are clear.</li> <li>Implementation trajectory is well defined.</li> <li> <p>Corner cases are dissected by example.</p> </li> <li> <p>Provide JWS structure format using predefined signature formats at the beginning (Curve25519 w/ edDSA)</p> </li> <li>Show examples of Format of JWS we'll support</li> </ul> <p>At a high level, the usage of a digital signature should occur before a message is encrypted. There's some cases where this may not make sense. This RFC will highlight a few different examples of how non-repudiable digital signatures could be used.</p>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#connect-protocol-example","title":"Connect protocol example","text":"<p>Starting with an initial <code>connections/1.0/invitation</code> message like this:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/connections/1.0/invitation\",\n    \"@id\": \"12345678900987654321\",\n    \"label\": \"Alice\",\n    \"recipientKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"],\n    \"serviceEndpoint\": \"https://example.com/endpoint\",\n    \"routingKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"]\n}\n</code></pre> <p>We would then bas64URL encode this message like this:</p> <pre><code>eyJAdHlwZSI6ImRpZDpzb3Y6QnpDYnNOWWhNcmpIaXFaRFRVQVNIZztzcGVjL2Nvbm5lY3Rpb25zLzEuMC9pbnZpdGF0aW9uIiwiQGlkIjoiMTIzNDU2Nzg5MDA5ODc2NTQzMjEiLCJsYWJlbCI6IkFsaWNlIiwicmVjaXBpZW50S2V5cyI6WyI4SEg1Z1lFZU5jM3o3UFlYbWQ1NGQ0eDZxQWZDTnJxUXFFQjNuUzdaZnU3SyJdLCJzZXJ2aWNlRW5kcG9pbnQiOiJodHRwczovL2V4YW1wbGUuY29tL2VuZHBvaW50Iiwicm91dGluZ0tleXMiOlsiOEhINWdZRWVOYzN6N1BZWG1kNTRkNHg2cUFmQ05ycVFxRUIzblM3WmZ1N0siXX0=\n</code></pre> <p>This base64URL encoded string would then become the payload in the JWS.</p> <p>Using the compact serialization format, our JOSE Header would look like this:</p> <pre><code>{\n    \"alg\":\"EdDSA\",\n    \"kid\":\"FYmoFw55GeQH7SRFa37dkx1d2dZ3zUF8ckg7wmL7ofN4\"\n}\n</code></pre> <p><code>alg</code>: specifies the signature algorithm used <code>kid</code>: specifies the key identifier. In the case of DIDComm, this will be a base58 encoded ed25519 key.</p> <p>To sign, we would combine the JOSE Header with the payload and separate it using a period. This would be the resulting data that would be signed:</p> <pre><code>ewogICAgImFsZyI6IkVkRFNBIiwKICAgICJraWQiOiJGWW1vRnc1NUdlUUg3U1JGYTM3ZGt4MWQyZFozelVGOGNrZzd3bUw3b2ZONCIKfQ==.eyJAdHlwZSI6ImRpZDpzb3Y6QnpDYnNOWWhNcmpIaXFaRFRVQVNIZztzcGVjL2Nvbm5lY3Rpb25zLzEuMC9pbnZpdGF0aW9uIiwiQGlkIjoiMTIzNDU2Nzg5MDA5ODc2NTQzMjEiLCJsYWJlbCI6IkFsaWNlIiwicmVjaXBpZW50S2V5cyI6WyI4SEg1Z1lFZU5jM3o3UFlYbWQ1NGQ0eDZxQWZDTnJxUXFFQjNuUzdaZnU3SyJdLCJzZXJ2aWNlRW5kcG9pbnQiOiJodHRwczovL2V4YW1wbGUuY29tL2VuZHBvaW50Iiwicm91dGluZ0tleXMiOlsiOEhINWdZRWVOYzN6N1BZWG1kNTRkNHg2cUFmQ05ycVFxRUIzblM3WmZ1N0siXX0=\n</code></pre> <p>and the resulting signature would be:</p> <pre><code>cwKY4Qhz0IFG9rGqNjcR-6K1NJqgyoGhso28ZGYkOPNI3C8rO6lmjwYstY0Fa2ew8jaFB-jWQN55kOTL5oHVDQ==\n</code></pre> <p>The final output would then produce this:</p> <pre><code>ewogICAgImFsZyI6IkVkRFNBIiwKICAgICJraWQiOiJGWW1vRnc1NUdlUUg3U1JGYTM3ZGt4MWQyZFozelVGOGNrZzd3bUw3b2ZONCIKfQ==.eyJAdHlwZSI6ImRpZDpzb3Y6QnpDYnNOWWhNcmpIaXFaRFRVQVNIZztzcGVjL2Nvbm5lY3Rpb25zLzEuMC9pbnZpdGF0aW9uIiwiQGlkIjoiMTIzNDU2Nzg5MDA5ODc2NTQzMjEiLCJsYWJlbCI6IkFsaWNlIiwicmVjaXBpZW50S2V5cyI6WyI4SEg1Z1lFZU5jM3o3UFlYbWQ1NGQ0eDZxQWZDTnJxUXFFQjNuUzdaZnU3SyJdLCJzZXJ2aWNlRW5kcG9pbnQiOiJodHRwczovL2V4YW1wbGUuY29tL2VuZHBvaW50Iiwicm91dGluZ0tleXMiOlsiOEhINWdZRWVOYzN6N1BZWG1kNTRkNHg2cUFmQ05ycVFxRUIzblM3WmZ1N0siXX0=.cwKY4Qhz0IFG9rGqNjcR-6K1NJqgyoGhso28ZGYkOPNI3C8rO6lmjwYstY0Fa2ew8jaFB-jWQN55kOTL5oHVDQ==\n</code></pre>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#basic-message-protocol-example","title":"Basic Message protocol example","text":""},{"location":"features/0066-non-repudiable-cryptographic-envelope/#sign-and-encrypt-process","title":"Sign and encrypt process","text":"<p>Next is an example that showcases what a basic message would look like. Since this message would utilize a connection to encrypt the message, we will produce a JWS first, and then encrypt the outputted compact JWS.</p> <p>We would first encode our JOSE Header which looks like this:</p> <pre><code>{\n    \"alg\": \"edDSA\",\n    \"kid\": \"7XVZJUuKtfYeN1W4Dq2Tw2ameG6gC1amxL7xZSsZxQCK\"\n}\n</code></pre> <p>and when base64url encoded it would be converted to this:</p> <pre><code>eyJhbGciOiAiZWREU0EiLCAia2lkIjogIjdYVlpKVXVLdGZZZU4xVzREcTJUdzJhbWVHNmdDMWFteEw3eFpTc1p4UUNLIn0=\n</code></pre> <p>Next we'll take our content layer message which as an example is the JSON provided:</p> <pre><code>{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/basicmessage/1.0/message\",\n    \"~l10n\": { \"locale\": \"en\" },\n    \"sent_time\": \"2019-01-15 18:42:01Z\",\n    \"content\": \"Your hovercraft is full of eels.\"\n}\n</code></pre> <p>and now we'll base64url encode this message which results in this output:</p> <pre><code>eyJjb250ZW50IjogIllvdXIgaG92ZXJjcmFmdCBpcyBmdWxsIG9mIGVlbHMuIiwgInNlbnRfdGltZSI6ICIyMDE5LTAxLTE1IDE4OjQyOjAxWiIsICJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9iYXNpY21lc3NhZ2UvMS4wL21lc3NhZ2UiLCAiQGlkIjogIjEyMzQ1Njc4MCIsICJ-bDEwbiI6IHsibG9jYWxlIjogImVuIn19\n</code></pre> <p>Next, they should be concatenated using a period (.) as a delimiter character which would produce this output:</p> <pre><code>eyJhbGciOiAiZWREU0EiLCAia2lkIjogIjdYVlpKVXVLdGZZZU4xVzREcTJUdzJhbWVHNmdDMWFteEw3eFpTc1p4UUNLIn0=.eyJjb250ZW50IjogIllvdXIgaG92ZXJjcmFmdCBpcyBmdWxsIG9mIGVlbHMuIiwgInNlbnRfdGltZSI6ICIyMDE5LTAxLTE1IDE4OjQyOjAxWiIsICJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9iYXNpY21lc3NhZ2UvMS4wL21lc3NhZ2UiLCAiQGlkIjogIjEyMzQ1Njc4MCIsICJ-bDEwbiI6IHsibG9jYWxlIjogImVuIn19\n</code></pre> <p>The signature for the signature data is:</p> <pre><code>FV7Yyz7i31EKoqS_cycQRr2pN59Q5Ojoxnr7uf6yZBqylnUZW2jCk_LesgWy5ZEux2K6dkrZh7q9pUs9dEsJBQ==\n</code></pre> <p>The signature should be concatenated to the signed data above resulting in this final string:</p> <pre><code>eyJhbGciOiAiZWREU0EiLCAia2lkIjogIjdYVlpKVXVLdGZZZU4xVzREcTJUdzJhbWVHNmdDMWFteEw3eFpTc1p4UUNLIn0=.eyJjb250ZW50IjogIllvdXIgaG92ZXJjcmFmdCBpcyBmdWxsIG9mIGVlbHMuIiwgInNlbnRfdGltZSI6ICIyMDE5LTAxLTE1IDE4OjQyOjAxWiIsICJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9iYXNpY21lc3NhZ2UvMS4wL21lc3NhZ2UiLCAiQGlkIjogIjEyMzQ1Njc4MCIsICJ-bDEwbiI6IHsibG9jYWxlIjogImVuIn19.FV7Yyz7i31EKoqS_cycQRr2pN59Q5Ojoxnr7uf6yZBqylnUZW2jCk_LesgWy5ZEux2K6dkrZh7q9pUs9dEsJBQ==\n</code></pre> <p>The last step is to encrypt this base64URL encoded string as the message in pack which will complete the cryptographic envelope.</p> <p>The output of this message then becomes:</p> <pre><code>{\"protected\":\"eyJlbmMiOiJ4Y2hhY2hhMjBwb2x5MTMwNV9pZXRmIiwidHlwIjoiSldNLzEuMCIsImFsZyI6IkF1dGhjcnlwdCIsInJlY2lwaWVudHMiOlt7ImVuY3J5cHRlZF9rZXkiOiJac2dYVWdNVGowUk9lbFBTT09lRGxtaE9sbngwMkVVYjZCbml4QjBESGtEZFRLaGc3ZlE1Tk1zcjU3bzA5WDZxIiwiaGVhZGVyIjp7ImtpZCI6IjRXenZOWjJjQUt6TXM4Nmo2S1c5WGZjMmhLdTNoaFd4V1RydkRNbWFSTEFiIiwiaXYiOiJsOWJHVnlyUnRseUNMX244UmNEakJVb1I3eU5sdEZqMCIsInNlbmRlciI6Imh4alZMRWpXcmY0RFplUGFsRGJnYzVfNmFMN2ltOGs1WElQWnBqTURlUzZaUS1jcEFUaGNzNVdiT25uaVFBM2Z0ZnlYWDJkVUc0dVZ3WHhOTHdMTXRqV3lxNkNKeDdUWEdBQW9ZY0RMMW1aaTJxd2xZMGlDQ2N0dHdNVT0ifX1dfQ==\",\"iv\":\"puCgKCfsOb5gRG81\",\"ciphertext\":\"EpHaC0ZMXQakM4n8Fxbedq_3UhiJHq6vd_I4NNz3N7aDbq7-0F6OXi--VaR7xoTqAyJjrOTYmy1SqivSkGmKaCcpFwC9Shdo_vcMFzIxu90_m3MG1xKNsvDmQBFnD0qgjPPXxmxTlmmYLSdA3JaHpEx1K9gYgGqv4X5bgWZqzFCoevyOlD5a2bDZBY5Mn__IT1pVzjbMbDeSgM2nOztWyF0baXwrqczBW-Msx-uP5HNlLdz02FPbMnRP6MYyw6q0wI0EqwzzwH81bZzHKrTVHT2-M_aIEQp9lKGLhnSW3-aIOpSzonGOriyDukfTpvsCUZEd_X1u0G3iZKxYCbIKaj_ARLbb6idlRngVGW9LYYaw7Xay83exp22gflvLmmN25Xzo1vLlaDaFr9h-J_QAvFebCHgWjl1kcodBRc2jhoMVSpEXJHoI5qMrlVvh45PLTEjxy7y5FHQ1L8klwWZN5EIwui3ExIOA8RwYDlp8-HLib_uqB7hNzVUYC0iPd1KTiNIcidYVdAoPpdtLDOh-KCmPB9RkjVUqSlwNYUAAnfY8OJXuBLHP2nWiYUDA6VDbvrv4npW88VMdsFDk_QzvDRvg7gkW8x8jNd8=\",\"tag\":\"B4UilbBNSUr3QcALtVxTEw==\"}\n</code></pre>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#decrypt-and-verify-process","title":"Decrypt and Verify process","text":"<p>To Decrypt and verify the JWS first unpack the message, which provides this result:</p> <pre><code>{\n    \"message\":\"eyJhbGciOiAiZWREU0EiLCAia2lkIjogIjdYVlpKVXVLdGZZZU4xVzREcTJUdzJhbWVHNmdDMWFteEw3eFpTc1p4UUNLIn0=.eyJjb250ZW50IjogIllvdXIgaG92ZXJjcmFmdCBpcyBmdWxsIG9mIGVlbHMuIiwgInNlbnRfdGltZSI6ICIyMDE5LTAxLTE1IDE4OjQyOjAxWiIsICJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9iYXNpY21lc3NhZ2UvMS4wL21lc3NhZ2UiLCAiQGlkIjogIjEyMzQ1Njc4MCIsICJ-bDEwbiI6IHsibG9jYWxlIjogImVuIn19.FV7Yyz7i31EKoqS_cycQRr2pN59Q5Ojoxnr7uf6yZBqylnUZW2jCk_LesgWy5ZEux2K6dkrZh7q9pUs9dEsJBQ==\",\n    \"recipient_verkey\":\"4WzvNZ2cAKzMs86j6KW9Xfc2hKu3hhWxWTrvDMmaRLAb\",\n    \"sender_verkey\":\"7XVZJUuKtfYeN1W4Dq2Tw2ameG6gC1amxL7xZSsZxQCK\"\n}\n</code></pre> <p>Parse the <code>message</code> field splitting on the second period <code>.</code> You should then have this as the payload:</p> <pre><code>eyJhbGciOiAiZWREU0EiLCAia2lkIjogIjdYVlpKVXVLdGZZZU4xVzREcTJUdzJhbWVHNmdDMWFteEw3eFpTc1p4UUNLIn0=.eyJjb250ZW50IjogIllvdXIgaG92ZXJjcmFmdCBpcyBmdWxsIG9mIGVlbHMuIiwgInNlbnRfdGltZSI6ICIyMDE5LTAxLTE1IDE4OjQyOjAxWiIsICJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9iYXNpY21lc3NhZ2UvMS4wL21lc3NhZ2UiLCAiQGlkIjogIjEyMzQ1Njc4MCIsICJ-bDEwbiI6IHsibG9jYWxlIjogImVuIn19\n</code></pre> <p>and the signature will be base64URL encoded and look like this:</p> <pre><code>FV7Yyz7i31EKoqS_cycQRr2pN59Q5Ojoxnr7uf6yZBqylnUZW2jCk_LesgWy5ZEux2K6dkrZh7q9pUs9dEsJBQ==\n</code></pre> <p>Now decode the signature and then convert the signature  and payload to bytes and use <code>crypto.crypto_verify()</code> API in IndySDK</p> <p>Your message has now been verified.</p> <p>To get the original message, you'll again parse the JWS this time taking the second section only which looks like this:</p> <pre><code>eyJjb250ZW50IjogIllvdXIgaG92ZXJjcmFmdCBpcyBmdWxsIG9mIGVlbHMuIiwgInNlbnRfdGltZSI6ICIyMDE5LTAxLTE1IDE4OjQyOjAxWiIsICJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9iYXNpY21lc3NhZ2UvMS4wL21lc3NhZ2UiLCAiQGlkIjogIjEyMzQ1Njc4MCIsICJ-bDEwbiI6IHsibG9jYWxlIjogImVuIn19\n</code></pre> <p>Now Base64URL decode that section and you'll get the original message:</p> <pre><code>{\n    \"content\": \"Your hovercraft is full of eels.\",\n    \"sent_time\": \"2019-01-15 18:42:01Z\",\n    \"@type\": \"https://didcomm.org/basicmessage/1.0/message\",\n    \"@id\": \"123456780\",\n    \"~l10n\": {\"locale\": \"en\"}\n}\n</code></pre>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#modifications-to-packunpack-api","title":"Modifications to pack()/unpack() API","text":"<ul> <li>Things to consider:<ul> <li>Combining this all into the pack/unpack API would require two additional APIs. One to handle signing, and one to indicate a message isn't encrypted.</li> <li>I like the idea of combining the API. However, I'm not a fan of the idea of incorporating a plaintext message into pack to support the connect protocol.</li> <li>My preference would be to create a seperate API specifically for the connect protocol given that it's an edge case.</li> <li>How would this affect the ephemeral challenge protocol as well as the \"spectrum of trust\" which was highlight by One of Daniel Hardman's previous posts?</li> </ul> </li> </ul>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#drawbacks","title":"Drawbacks","text":"<p>Through the choice of a JWS formatted structure we imply that an off the shelf library will support this structure. However, it's uncommon for libraries to support the edDSA signature algorithm even though it's a valid algorithm based on the IANA registry. This means that most implementations that support this will either need to add this signature algorithm to another JWS library or</p>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?<ul> <li>Given the support for ed25519 keys throughout the ecosystem, this seemed like the best fit for initial support. Over time, it may make sense to add additional support for other key types like Secp256k1 or RSA.</li> <li>The rational for supporting JWS is that it contains the bare minimum information to deterministically verify the payload (given JSON doesn't need to be ordered, but a signature must have the same byte order) and self contain the key and algorithm used.</li> <li>The compact serialization was chosen instead of the JSON serialization because it's assumed that senders will not be multi-signing messages at this time.</li> </ul> </li> <li>What other designs have been considered and what is the rationale for not choosing them?<ul> <li>CBOR supports a signature scheme called CBOR Web Signatures, but was not chosen because the DIDComm protocol is largely JSON based.</li> <li>JWTs were not chosen because they are a constrained form of JWS. This allows us to add JWT support if needed in the future, while not limiting ourselves early in the design process.</li> </ul> </li> <li>What is the impact of not doing this?<ul> <li>By not using JWTs we move away from a common dependency that many other SSI ecosystems support already for their credentials. However, many JWT libraries do not support ed25519 which is currently the only key type used.</li> </ul> </li> </ul>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#prior-art","title":"Prior art","text":"<p>The majority of prior art discussions are mentioned above in the rationale and alternatives section. Some prior art that was considered when selecting this system is how closely it aligns with OpenID Connect systems. This has the possibility to converge with Self Issued OpenID Connect systems when running over HTTP, but doesn't specifically constrain to an particular transport mechanism. This is a distinct advantage for backward compatibility.</p>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Was the usage of a JWT a better option for broader SSI adoption and backwards compatibility (e.g. Active directory and OpenID Connect)?</li> <li> </li> </ul>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#is-limiting-to-only-ed25519-key-types-an-unnecessary-restraint-given-the-broad-support-needed-for-didcomm","title":"Is limiting to only ed25519 key types an unnecessary restraint given the broad support needed for DIDComm?","text":""},{"location":"features/0066-non-repudiable-cryptographic-envelope/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0067-didcomm-diddoc-conventions/","title":"Aries RFC 0067: DIDComm DID document conventions","text":"<ul> <li>Authors: Tobias Looker, Stephen Curran</li> <li>Status: PROPOSED</li> <li>Since: 2019-06-10</li> <li>Status Note: This revises the former INDY HIPE</li> <li>Start Date: 2019-04-15</li> <li>Tags: feature</li> </ul>"},{"location":"features/0067-didcomm-diddoc-conventions/#summary","title":"Summary","text":"<p>Explain the DID document conventions required to enable DID communications.</p>"},{"location":"features/0067-didcomm-diddoc-conventions/#motivation","title":"Motivation","text":"<p>Standardization of these conventions is essential to promoting interoperability of DID communications.</p>"},{"location":"features/0067-didcomm-diddoc-conventions/#tutorial","title":"Tutorial","text":""},{"location":"features/0067-didcomm-diddoc-conventions/#did-documents","title":"DID documents","text":"<p>A DID document is the associated data model to a DID, it contains important associated cryptographic information and a declaration of capabilities the DID supports.</p> <p>Of particular interested to this RFC is the definition of service endpoints. The primary object of this RFC is to document the DID communication service type and describe the associated conventions.</p>"},{"location":"features/0067-didcomm-diddoc-conventions/#service-conventions","title":"Service Conventions","text":"<p>As referenced above within the DID specification lies a section called service endpoints, this section of the DID document is reserved for <code>any type of service the entity wishes to advertise, including decentralized identity management services for further discovery, authentication, authorization, or interaction</code>.</p> <p>When a DID document wishes to express support for DID communications, the following service definition is defined.</p> <pre><code>{\n  \"service\": [{\n    \"id\": \"did:example:123456789abcdefghi#did-communication\",\n    \"type\": \"did-communication\",\n    \"priority\" : 0,\n    \"recipientKeys\" : [ \"did:example:123456789abcdefghi#1\" ],\n    \"routingKeys\" : [ \"did:example:123456789abcdefghi#1\" ],\n    \"accept\": [\n      \"didcomm/aip2;env=rfc587\",\n      \"didcomm/aip2;env=rfc19\"\n    ],\n    \"serviceEndpoint\": \"https://agent.example.com/\"\n  }]\n}\n</code></pre> <ul> <li>id : Required by the Service Endpoints Spec.</li> <li>type : Required by the Service Endpoints Spec. It is mandatory that this field is set to <code>did-communication</code></li> <li>priority : This represents the priority of the service endpoint, used for distinction when multiple <code>did-communication</code> service endpoints are present in a single DID document. It is mandatory that this field is set to an unsigned integer with the default value of <code>0</code>.</li> <li>recipientKeys : This is an array of did key references used to denote the default recipients of an endpoint. (note-1)</li> <li>routingKeys: This is an array of did key references, ordered from most destward to most srcward, used to denote the individual routing hops in between the sender and recipients. See TBC for more information on how routing is intended to operate.</li> <li><code>accept</code> - [optional] an array of media types in the order of preference for sending a message to the endpoint.  If <code>accept</code> is not specified, the sender uses its preferred choice for sending a message to the endpoint.  RFC 0044 provides a general discussion of media types.</li> <li>serviceEndpoint : Required by the Service Endpoints Spec. This URL based endpoint is used to declare how the message should be sent. DID communication is transport agnostic, and therefore leverages existing application level transport protocols. However for each transport defined, which is identified by the URL scheme e.g <code>http</code>, a set of transport specific considerations are defined see transports for more details.</li> </ul> <p>Notes 1. The keys featured in this array must resolve to keys of the same type, for example a mix <code>Ed25519VerificationKey2018</code> or <code>RsaVerificationKey2018</code> in the same array is invalid.</p>"},{"location":"features/0067-didcomm-diddoc-conventions/#message-preparation-conventions","title":"Message Preparation Conventions","text":"<p>Below describes the process under which a DID communication message is prepared and sent to a DID based on the conventions declared in the associated DID document. The scenario in which the below is predicated has the following conditions.     - The sender possesses the DID document for the intended recipient(s) of a DID communication message.     - The sender has created a content level message that is now ready to be prepared for sending to the intended recipient(s).</p> <ol> <li>The sender resolves the relevant <code>did-communication</code> service of the intended recipient(s) DID document.</li> <li>The sender resolves the recipient keys present in the <code>recipientKeys</code> array of the service declaration.</li> <li>Using the resolved keys, the sender takes the content level message and packs it inside an encrypted envelope for the recipient keys. (note-2)</li> <li>The sender then inspects the <code>routingKeys</code> array, if it is found to be empty, then the process skips to step 5. Otherwise, the sender prepares a content level message of type <code>forward</code>. The resolved keys from the <code>recipientKeys</code> array is set as the contents of the <code>to</code> field in the forward message and the encrypted envelope from the previous step is set as the contents of the <code>msg</code> field in the forward message. Following this, for each element in the <code>routingKeys</code> array the following sub-process is repeated:<ol> <li>The sender resolves the current key in the routing array and takes the outputted encrypted envelope from the previous step and packs it inside a new encrypted envelope for the current key.</li> <li>The sender prepares a content level message of type <code>forward</code>. The current key in the routing array is set as the contents of the <code>to</code> field in the forward message and the encrypted envelope from the previous step is set as the contents of the <code>msg</code> field in the forward message.</li> </ol> </li> <li>Resolve the service endpoint:<ul> <li>If the endpoint is a valid DID URL, check that it resolves to another DID service definition. If the resolution is successful the process from step 2. is repeated using the message outputted from this process as the input message.</li> <li>If the service endpoint is not a DID URL, send the message using the transport protocol declared by the URL's scheme.</li> </ul> </li> </ol> <p>Notes 1. There are two main situations that an agent will be in prior to preparing a new message.</p> <ul> <li>The agent is responding to a message that has just been received and has the context of the sender key of the previous message. In this case, a targeted lookup of the <code>did-communication</code> service definition can be done to find the service definition that ../../features the sender key as a recipient key which would ensure that the response was delivered back to the sender.</li> <li>The agent is creating a new message to a connection and will use the default <code>did-communication</code> service definition for preparation of a message. In this case, the default <code>did-communication</code> service definition would be used by resolving the lowest priority service definition from the connections DID document.</li> </ul> <ol> <li>When preparing this envelope the sender has two main choices to make around properties to include in envelope <ul> <li>Whether to include sender information</li> <li>Whether to include a non-reputable signature</li> </ul> </li> </ol>"},{"location":"features/0067-didcomm-diddoc-conventions/#example-domain-and-did-document","title":"Example: Domain and DID document","text":"<p>The following is an example of an arbitrary pair of domains that will be helpful in providing context to conventions defined above.</p> <p></p> <p>In the diagram above:</p> <ul> <li>Alice has</li> <li>1 Edge Agent - \"1\"</li> <li>1 Cloud Agent - \"2\"</li> <li>1 Domain Endpoint - \"8\"</li> <li>Bob has</li> <li>2 Edge Agents - \"4\", \"5\"</li> <li>2 Cloud Agents - \"3\", \"6\"</li> <li>1 Domain Endpoint - \"9\"</li> </ul>"},{"location":"features/0067-didcomm-diddoc-conventions/#bobs-did-document-for-his-relationship-with-alice","title":"Bob's DID document for his Relationship with Alice","text":"<p>Bob\u2019s domain has 3 devices he uses for processing messages - two phones (4 and 5) and a cloud-based agent (6). As well, Bob has one agent that he uses as a mediator (3) that can hold messages for the two phones when they are offline. However, in Bob's relationship with Alice, he ONLY uses one phone (4) and the cloud-based agent (6). Thus the key for device 5 is left out of the DID document (see below). For further privacy preservation, Bob also elects to use a shared domain endpoint (agents-r-us), giving him an extra layer of isolation from correlation. This is represented by the <code>serviceEndpoint</code> in the service definition not directly resolving to an endpoint URI rather resolving to another <code>did-communication</code> service definition which is owned and controlled by the endpoint owner (agents-r-us).</p> <p>Bobs DID document given to Alice</p> <pre><code>{\n  \"@context\": \"https://w3id.org/did/v1\",\n  \"id\": \"did:example:1234abcd\",\n  \"publicKey\": [\n    {\"id\": \"3\", \"type\": \"RsaVerificationKey2018\",  \"controller\": \"did:example:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC X\u2026\"},\n    {\"id\": \"4\", \"type\": \"RsaVerificationKey2018\",  \"controller\": \"did:example:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC 9\u2026\"},\n    {\"id\": \"6\", \"type\": \"RsaVerificationKey2018\",  \"controller\": \"did:example:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC A\u2026\"}\n  ],\n  \"authentication\": [\n    {\"type\": \"RsaSignatureAuthentication2018\", \"publicKey\": \"did:example:1234abcd#4\"}\n  ],\n  \"service\": [\n    {\n      \"id\": \"did:example:123456789abcdefghi;did-communication\",\n      \"type\": \"did-communication\",\n      \"priority\" : 0,\n      \"recipientKeys\" : [ \"did:example:1234abcd#4\" ],\n      \"routingKeys\" : [ \"did:example:1234abcd#3\" ],\n      \"serviceEndpoint\" : \"did:example:xd45fr567794lrzti67;did-communication\"\n    }\n  ]\n}\n</code></pre> <p>Agents r Us DID document - resolvable by Alice</p> <pre><code>{\n  \"@context\": \"https://w3id.org/did/v1\",\n  \"id\": \"did:example:xd45fr567794lrzti67\",\n  \"publicKey\": [\n    {\"id\": \"1\", \"type\": \"RsaVerificationKey2018\",  \"controller\": \"did:example:xd45fr567794lrzti67\",\"publicKeyPem\": \"-----BEGIN PUBLIC X\u2026\"},\n  ],\n  \"authentication\": [\n    {\"type\": \"RsaSignatureAuthentication2018\", \"publicKey\": \"did:example:xd45fr567794lrzti67#1\"}\n  ],\n  \"service\": [\n    {\n      \"id\": \"did:example:xd45fr567794lrzti67;did-communication\",\n      \"type\": \"did-communication\",\n      \"priority\" : 0,\n      \"recipientKeys\" : [ \"did:example:xd45fr567794lrzti67#1\" ],\n      \"routingKeys\" : [ ],\n      \"serviceEndpoint\" : \"http://agents-r-us.com\"\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0067-didcomm-diddoc-conventions/#message-preparation-example","title":"Message Preparation Example","text":"<p>Alices agent goes to prepare a message <code>desired_msg</code> for Bob.</p> <ol> <li>Alices agent resolves the above DID document <code>did:example:1234abcd</code> for Bob and resolves the <code>did-communication</code> service definition.</li> <li>Alices agent then packs <code>desired_msg</code> in an encrypted envelope message to the resolved keys defined in the <code>recipientKeys</code> array.</li> <li>Because the <code>routingKeys</code> array is not empty, a content level message of type <code>forward</code> is prepared where the <code>to</code> field of the forward message is set to the resolved keys and the <code>msg</code> field of the forward message is set to the encrypted envelope from the previous step.</li> <li>The resulting forward message from the previous step is then packed inside another encrypted envelope for the first and only key in the <code>routingKeys</code> array.</li> <li>Inspection of the service endpoint, reveals it is a did url and leads to resolving another <code>did-communication</code> service definition, this time owned and controlled by <code>agents-r-us</code>.</li> <li>Because in the <code>agents-r-us</code> service definition there is a recipient key. A content level message of type <code>forward</code> is prepared where the <code>to</code> field of the forward message is set to the recipient key and the <code>msg</code> field of the forward message is set to the encrypted envelope from the previous step.</li> <li>This content message is then packed in a encrypted envelope for the recipient key in <code>agents-r-us</code> service definition.</li> <li>Finally as the endpoint listed in the serviceEndpoint field for the <code>agents-r-us</code> <code>did-communication</code> service definition is a valid endpoint URL, the message is transmitted in accordance with the URL's protocol.</li> </ol>"},{"location":"features/0067-didcomm-diddoc-conventions/#reference","title":"Reference","text":""},{"location":"features/0067-didcomm-diddoc-conventions/#rationale-and-alternatives","title":"Rationale and alternatives","text":""},{"location":"features/0067-didcomm-diddoc-conventions/#prior-art","title":"Prior art","text":"<ul> <li>DID Communication Message Anatomy</li> <li>DID Communication Encryption Envelope</li> </ul>"},{"location":"features/0067-didcomm-diddoc-conventions/#unresolved-questions","title":"Unresolved questions","text":"<p>The following remain unresolved:</p> <ul> <li>The convention for packing the message for the required routes is dependent on the array order of key references, which could be viewed as a weak/brittle convention.</li> </ul>"},{"location":"features/0067-didcomm-diddoc-conventions/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0075-payment-decorators/","title":"Aries RFC 0075: Payment Decorators","text":"<ul> <li>Authors: Sam Curren, Daniel Hardman, Tomislav Markovski</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes: Indy HIPE PR #129</li> <li>Start Date: 2019-04-22</li> <li>Tags: feature, decorator</li> </ul>"},{"location":"features/0075-payment-decorators/#summary","title":"Summary","text":"<p>Defines the <code>~payment_request</code>, <code>payment_internal_response</code>, and <code>~payment_receipt</code> decorators. These offer standard payment ../../features in all DIDComm interactions, and let DIDComm take advantage of the W3C's Payment Request API in an interoperable way.</p>"},{"location":"features/0075-payment-decorators/#motivation","title":"Motivation","text":"<p>Instead of inventing custom messages for payments in each protocol, arbitrary messages can express payment semantics with payment decorators. Individual protocol specs should clarify on which messages and under which conditions the decorators are used.</p>"},{"location":"features/0075-payment-decorators/#tutorial","title":"Tutorial","text":"<p>The W3C's Payment Request API governs interactions between three parties:</p> <ol> <li>payer</li> <li>payee</li> <li>payment method</li> </ol> <p>The payer is usually imagined to be a person operating a web browser, the payee is imagined to be an online store, and the payment method might be something like a credit card processing service. The payee emits a PaymentRequest JSON structure (step 1 below); this causes the payee to be prompted (step 2, \"Render\"). The payer decides whether to pay, and if so, which payment method and options she prefers (step 3, \"Configure\"). The payer's choices are embodied in a PaymentResponse JSON structure (step 4). This is then used to select the appropriate codepath and inputs to invoke the desired payment method (step 5).</p> <p></p> <p>Notice that this flow does not include anything coming back to the payer. In this API, the PaymentResponse structure embodies a response from the payer to the payer's own agent, expressing choices about which credit card to use and which shipping options are desired; it's not a response that crosses identity boundaries. That's reasonable because this is the Payment Request API, not a Payment Roundtrip API. It's only about requesting payments, not completing payments or reporting results. Also, each payment method will have unique APIs for fulfillment and receipts; the W3C Payment Request spec does not attempt to harmonize them, though some work in that direction is underway in the separate Payment Handler API spec.</p> <p>In DIDComm, the normal emphasis is on interactions between parties with different identities. This makes PaymentResponse and the communication that elicits it (steps 2-4) a bit unusual from a DIDComm perspective; normally DIDComm would use the word \"response\" for something that comes back from Bob, after Alice asks Bob a question. It also makes the scope of the W3C API feel incomplete, because we'd like to be able to model the entire flow, not just part of it.</p> <p>The DIDComm payment decorators map to the W3C API as follows:</p> <ul> <li>DIDComm's <code>payment_request</code> decorator is exactly equivalent to the JSON representation of PaymentRequest in the W3C API, including all internal fields and semantics, and the use of camelCase.</li> <li>DIDComm's <code>payment_internal_response</code> decorator is exactly equivalent to the JSON representation of PaymentResponse in the W3C API. However, we never expect it to appear on messages that cross a sovereign domain boundary. It is only relevant if Alice has two agents that want to confer about Alice's choices in responding to a <code>payment_request</code>, and is thus not relevant to interoperability. However, it is defined so internal conversations about Alice's choices may leverage a standard mechanism, if they like.</li> <li>DIDComm's <code>payment_receipt</code> decorator has no analog in the W3C spec, because it encapsulates proof from payer to payee, that payment has actually taken place.</li> <li>Neither DIDComm nor the W3C spec define messages for the interaction between payer and payment method handler. Rather, both allow this communication to be proprietary. At a future date, perhaps standardization will happen here.</li> </ul>"},{"location":"features/0075-payment-decorators/#reference","title":"Reference","text":""},{"location":"features/0075-payment-decorators/#payment_request","title":"<code>~payment_request</code>","text":"<p>Please see the PaymentRequest interface docs in the W3C spec for a full reference, or Section 2, Examples of Usage in the W3C spec for a narration that builds a PaymentRequest from first principles.</p> <p>The following is a sample <code>~payment_request</code> decorator with some interesting details to suggest what's possible:</p> <pre><code>{\n  \"~payment_request\": {\n    \"methodData\": [\n      {\n        \"supportedMethods\": \"basic-card\",\n        \"data\": {\n          \"supportedNetworks\": [\"visa\", \"mastercard\"],\n          \"payeeId\": \"12345\"\n        },\n      },\n      {\n        \"supportedMethods\": \"sovrin\",\n        \"data\": {\n          \"supportedNetworks\": [\"sov\", \"sov:test\", \"ibm-indy\"],\n          \"payeeId\": \"XXXX\"\n        },\n      }\n    ],\n    \"details\": {\n      \"id\": \"super-store-order-123-12312\",\n      \"displayItems\": [\n        {\n          \"label\": \"Sub-total\",\n          \"amount\": { \"currency\": \"USD\", \"value\": \"55.00\" },\n        },\n        {\n          \"label\": \"Sales Tax\",\n          \"amount\": { \"currency\": \"USD\", \"value\": \"5.00\" },\n          \"type\": \"tax\"\n        },\n      ],\n      \"total\": {\n        \"label\": \"Total due\",\n        // The total is USD$65.00 here because we need to\n        // add shipping (below). The selected shipping\n        // costs USD$5.00.\n        \"amount\": { \"currency\": \"USD\", \"value\": \"65.00\" }\n      },\n      \"shippingOptions\": [\n        {\n          \"id\": \"standard\",\n          \"label\": \"Ground Shipping (2 days)\",\n          \"amount\": { \"currency\": \"USD\", \"value\": \"5.00\" },\n          \"selected\": true,\n        },\n        {\n          \"id\": \"drone\",\n          \"label\": \"Drone Express (2 hours)\",\n          \"amount\": { \"currency\": \"USD\", \"value\": \"25.00\" }\n        }\n      ],\n      \"modifiers\": [\n        {\n          \"additionalDisplayItems\": [{\n            \"label\": \"Card processing fee\",\n            \"amount\": { \"currency\": \"USD\", \"value\": \"3.00\" },\n          }],\n          \"supportedMethods\": \"basic-card\",\n          \"total\": {\n            \"label\": \"Total due\",\n            \"amount\": { \"currency\": \"USD\", \"value\": \"68.00\" },\n          },\n          \"data\": {\n            \"supportedNetworks\": [\"visa\"],\n          },\n        },\n        {\n          \"supportedMethods\": \"sovrin\",\n          \"total\": {\n            \"label\": \"Total due\",\n            \"amount\": { \"currency\": \"SOV\", \"value\": \"2254\" },\n          },\n        },\n      ]\n    },\n    \"options\": {\n      \"requestPayerEmail\": false,\n      \"requestPayerName\": true,\n      \"requestPayerPhone\": false,\n      \"requestShipping\": true\n    }\n  }\n}\n</code></pre> <p>The <code>details.id</code> field contains an invoice number, shopping cart ID, or similar identifier that unambiguously identifies the goods and services for which payment is requested. The <code>payeeId</code> field would contain a payment address for cryptocurrency payment methods, or a merchant ID for credit cards. The <code>modifiers</code> section shows how the requested payment amount should be modified if the <code>basic-card</code> method is selected. That specific example is discussed in greater detail in the W3C spec. It also shows how the currency could be changed if a token-based method is selected instead of a fiat-based method. See the separate W3C spec on Payment Method IDs.</p> <p>Note that standard DIDComm localization can be used to provide localized alternatives to the <code>label</code> fields; this is a DIDComm-specific extension.</p> <p>This example shows <code>options</code> where the payee is requesting self-attested data from the payer. DIDComm offers the option of replacing this simple approach with a sophisticated presentation request based on verifiable credentials. The simple approach is fine where self-attested data is enough; the VC approach is useful when assurance of the data must be higher (e.g., a verified email address), or where fancy logic about what's required (Name plus either Email or Phone) is needed.</p> <p>The DIDComm <code>payment_request</code> decorator may be combined with the <code>~timing.expires_time</code> decorator to express the idea that the payment must be made within a certain time period or else the price or availability of merchandise is not guaranteed.</p>"},{"location":"features/0075-payment-decorators/#payment_internal_response","title":"<code>~payment_internal_response</code>","text":"<p>This decorator exactly matches PaymentResponse from the W3C API and will not be further described here. A useful example of a response is given in the related Basic Card Response doc.</p>"},{"location":"features/0075-payment-decorators/#payment_receipt","title":"<code>~payment_receipt</code>","text":"<p>This decorator on a message indicates that a payment has been made. It looks like this (note the snake_case since we are not matching a W3C spec):</p> <pre><code>{\n  \"~payment_receipt\": {\n      \"request_id\": \"super-store-order-123-12312\",\n      \"selected_method\": \"sovrin\",\n      \"selected_shippingOption\": \"standard\",\n      \"transaction_id\": \"abc123\",\n      \"proof\": \"directly verifiable proof of payment\",\n      \"payeeId\": \"XXXX\",\n      \"amount\": { \"currency\": \"SOV\", \"value\": \"2254\" }\n  }\n}\n</code></pre> <p>request_id: This contains the <code>details.id</code> of <code>~payment_request</code> that this payment receipt satisfies.</p> <p>selected_method: Which payment method was chosen to pay.</p> <p>selected_shippingOption: Which shipping option was chosen.</p> <p>transaction_id: A transaction identifier that can be checked by the payee to verify that funds were transferred, and that the transfer relates to this payment request instead of another. This might be a ledger's transaction ID, for example.</p> <p>proof: Optional. A base64url-encoded blob that contains directly verifiable proof that the transaction took place. This might be useful for payments enacted by a triple-signed receipt mechanism, for example. When this is present, <code>transaction_id</code> becomes optional. For ledgers that support state proofs, the state proof could be offered here.</p>"},{"location":"features/0075-payment-decorators/#example","title":"Example","text":"<p>Here is a rough description of how these decorators might be used in a protocol to issue credentials. We are not guaranteeing that the message details will remain up-to-date as that protocol evolves; this is only for purposes of general illustration.</p>"},{"location":"features/0075-payment-decorators/#credential-offer","title":"Credential Offer","text":"<p>This message is sent by the issuer; it indicates that payment is requested for the credential under discussion.</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue_credential/1.0/offer_credential\",\n    \"@id\": \"5bc1989d-f5c1-4eb1-89dd-21fd47093d96\",\n    \"cred_def_id\": \"KTwaKJkvyjKKf55uc6U8ZB:3:CL:59:tag1\",\n    \"~payment_request\": {\n        \"methodData\": [\n          {\n            \"supportedMethods\": \"ETH\",\n            \"data\": {\n              \"payeeId\": \"0xD15239C7e7dDd46575DaD9134a1bae81068AB2A4\"\n            },\n          }\n        ],\n        \"details\": {\n          \"id\": \"0a2bc4a6-1f45-4ff0-a046-703c71ab845d\",\n          \"displayItems\": [\n            {\n              \"label\": \"commercial driver's license\",\n              \"amount\": { \"currency\": \"ETH\", \"value\": \"0.0023\" },\n            }\n          ],\n          \"total\": {\n            \"label\": \"Total due\",\n            \"amount\": { \"currency\": \"ETH\", \"value\": \"0.0023\" }\n          }\n        }\n      },\n    \"credential_preview\": &lt;json-ld object&gt;,\n    ///...\n}\n</code></pre>"},{"location":"features/0075-payment-decorators/#example-credential-request","title":"Example Credential Request","text":"<p>This Credential Request is sent to the issuer, indicating that they have paid the requested amount.</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue_credential/1.0/request_credential\",\n    \"@id\": \"94af9be9-5248-4a65-ad14-3e7a6c3489b6\",\n    \"~thread\": { \"thid\": \"5bc1989d-f5c1-4eb1-89dd-21fd47093d96\" },\n    \"cred_def_id\": \"KTwaKJkvyjKKf55uc6U8ZB:3:CL:59:tag1\",\n    \"~payment_receipt\": {\n      \"request_id\": \"0a2bc4a6-1f45-4ff0-a046-703c71ab845d\",\n      \"selected_method\": \"ETH\",\n      \"transaction_id\": \"0x5674bfea99c480e110ea61c3e52783506e2c467f108b3068d642712aca4ea479\",\n      \"payeeId\": \"0xD15239C7e7dDd46575DaD9134a1bae81068AB2A4\",\n      \"amount\": { \"currency\": \"ETH\", \"value\": \"0.0023\" }\n    }\n\n    ///...\n}\n</code></pre>"},{"location":"features/0075-payment-decorators/#drawbacks","title":"Drawbacks","text":"<p>TBD</p>"},{"location":"features/0075-payment-decorators/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>We could allow each message family to indicate payment information independently. This would be very flexible, but tedious and very messy.</li> <li>We could not include payment information in messages, but that would limit useful applications.</li> </ul>"},{"location":"features/0075-payment-decorators/#prior-art","title":"Prior art","text":"<ul> <li>Indy HIPE PR #129 contains an earlier version of this thinking.</li> </ul>"},{"location":"features/0075-payment-decorators/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What about a receipt that covers multiple invoices?</li> <li>The W3C spec allows almost free variation in the fields used to communicate to specific payment methods. Do we want to standardize? Do we need to link to specific payment method definitions? Do we need to define our new payment methods (e.g., cryptocurrency-based) to be aligned with existing ones?</li> </ul>"},{"location":"features/0075-payment-decorators/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0092-transport-return-route/","title":"Aries RFC 0092: Transports Return Route","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note:  </li> <li>Supersedes: INDY HIPE PR 116</li> <li>Start Date: 2019-03-04</li> <li>Tags: feature</li> </ul>"},{"location":"features/0092-transport-return-route/#summary","title":"Summary","text":"<p>Agents can indicate that an inbound message transmission may also be used as a return route for messages. This allows for transports of increased efficiency as well as agents without an inbound route.</p>"},{"location":"features/0092-transport-return-route/#motivation","title":"Motivation","text":"<p>Inbound HTTP and Websockets are used only for receiving messages by default. Return messages are sent using their own outbound connections. Including a decorator allows the receiving agent to know that using the inbound connection as a return route is acceptable. This allows two way communication with agents that may not have an inbound route available. Agents without an inbound route include mobile agents, and agents that use a client (and not a server) for communication.</p> <p>This decorator is intended to facilitate message communication between a client based agent (an agent that can only operate as a client, not a server) and the server based agents they communicate directly with. Use on messages that will be forwarded is not allowed.</p>"},{"location":"features/0092-transport-return-route/#tutorial","title":"Tutorial","text":"<p>When you send a message through a connection, you can use the <code>~transport</code> decorator on the message and specify <code>return_route</code>. The value of <code>return_route</code> is discussed in the Reference section of this document.</p> <pre><code>{\n    \"~transport\": {\n        \"return_route\": \"all\"\n    }\n}\n</code></pre>"},{"location":"features/0092-transport-return-route/#reference","title":"Reference","text":"<ul> <li> <p><code>return_route</code> has the following acceptable values:</p> </li> <li> <p><code>none</code>: Default. No messages should be returned over this connection.</p> </li> <li><code>all</code>: Send all messages for this cryptographic key over the connection.</li> <li><code>thread</code>: Send all messages matching the cryptographic key and thread specified in the <code>return_route_thread</code> attribute.</li> </ul> <p>The <code>~transport</code> decorator should be processed after unpacking and prior to routing the message to a message handler.</p> <p>For HTTP transports, the presence of this message decorator indicates that the receiving agent MAY hold onto the connection and use it to return messages as designated. HTTP transports will only be able to receive at most one message at a time. Websocket transports are capable of receiving multiple messages.</p> <p>Compliance with this indicator is optional for agents generally, but required for agents wishing to connect with client based agents.</p>"},{"location":"features/0092-transport-return-route/#drawbacks","title":"Drawbacks","text":"<ul> <li>Application varies between transports, adding complexity to agent development.</li> </ul>"},{"location":"features/0092-transport-return-route/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Using a transport level decorator makes this behavior transport agnostic.</li> </ul>"},{"location":"features/0092-transport-return-route/#prior-art","title":"Prior art","text":"<p>The Decorators RFC describes scope of decorators. Transport isn't one of the scopes listed.</p>"},{"location":"features/0092-transport-return-route/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Protocol Test Suite Used in Tests"},{"location":"features/0095-basic-message/","title":"Aries RFC 0095: Basic Message Protocol 1.0","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: ADOPTED</li> <li>Since: 2019-08-06</li> <li>Status Note:  </li> <li>Supersedes: Indy 0033</li> <li>Start Date: 2019-01-16</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"features/0095-basic-message/#summary","title":"Summary","text":"<p>The BasicMessage protocol describes a stateless, easy to support user message protocol. It has a single message type used to communicate.</p>"},{"location":"features/0095-basic-message/#motivation","title":"Motivation","text":"<p>It is a useful feature to be able to communicate human written messages. BasicMessage is the most basic form of this written message communication, explicitly excluding advanced ../../features to make implementation easier.</p>"},{"location":"features/0095-basic-message/#tutorial","title":"Tutorial","text":""},{"location":"features/0095-basic-message/#roles","title":"Roles","text":"<p>There are two roles in this protocol: sender and receiver. It is anticipated that both roles are supported by agents that provide an interface for humans, but it is possible for an agent to only act as a sender (do not process received messages) or a receiver (will never send messages).</p>"},{"location":"features/0095-basic-message/#states","title":"States","text":"<p>There are not really states in this protocol, as sending a message leaves both parties in the same state they were before.</p>"},{"location":"features/0095-basic-message/#out-of-scope","title":"Out of Scope","text":"<p>There are many useful ../../features of user messaging systems that we will not be adding to this protocol. We anticipate the development of more advanced and full-featured message protocols to fill these needs. Features that are considered out of scope for this protocol include:</p> <ul> <li>read receipts</li> <li>emojii responses</li> <li>typing indicators</li> <li>message replies (threading)</li> <li>multi-party (group) messages</li> <li>attachments</li> </ul>"},{"location":"features/0095-basic-message/#reference","title":"Reference","text":"<p>Protocol: https://didcomm.org/basicmessage/1.0/</p> <p>message</p> <ul> <li>sent_time - timestamp in ISO 8601 UTC</li> <li>content - content of the user intended message as a string.</li> <li>The <code>~l10n</code> block SHOULD be used, but only the <code>locale</code> presented.</li> </ul> <p>Example:</p> <pre><code>{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/basicmessage/1.0/message\",\n    \"~l10n\": { \"locale\": \"en\" },\n    \"sent_time\": \"2019-01-15 18:42:01Z\",\n    \"content\": \"Your hovercraft is full of eels.\"\n}\n</code></pre>"},{"location":"features/0095-basic-message/#drawbacks","title":"Drawbacks","text":"<ul> <li>Creating this basicmessage may inhibit the creation of more advanced user messaging protocols.</li> <li>After more advanced user messaging protocols are created, the need to support this protocol may be annoying.</li> </ul>"},{"location":"features/0095-basic-message/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Basic user messaging creates an easy useful feature in the early days of agent messaging.</li> <li>Even in the presence of better protocols, it can still be useful for basic devices or service messaging.</li> </ul>"},{"location":"features/0095-basic-message/#prior-art","title":"Prior art","text":"<p>BasicMessage has parallels to SMS, which led to the later creation of MMS and even the still-under-development RCS.</p>"},{"location":"features/0095-basic-message/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Receive receipts (NOT read receipts) may be implicitly supported by an ack decorator with pre-processing support.</li> </ul>"},{"location":"features/0095-basic-message/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community; MISSING test results Aries Framework - .NET .NET framework for building agents of all types; MISSING test results Streetcred.id Commercial mobile and web app built using Aries Framework - .NET; MISSING test results Aries Cloud Agent - Python Contributed by the government of British Columbia.; MISSING test results Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases.; MISSING test results Aries Protocol Test Suite ; MISSING test results"},{"location":"features/0113-question-answer/","title":"Aries RFC 0113: Question Answer Protocol 0.9","text":"<ul> <li>Authors: Douglas Wightman</li> <li>Status: DEMONSTRATED</li> <li>Since: 2019-07-05</li> <li>Start Date: 2019-02-07</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0113-question-answer/#summary","title":"Summary","text":"<p>A simple protocol where a questioner asks a responder a question with at least one valid answer.  The responder then replies with an answer or ignores the question.</p> <pre><code>Note: While there is a need in the future for a robust negotiation protocol\nthis is not it. This is for simple question/answer exchanges.\n</code></pre>"},{"location":"features/0113-question-answer/#motivation","title":"Motivation","text":"<p>There are many instances where one party needs an answer to a specific question from another party. These can be related to consent, proof of identity, authentication, or choosing from a list of options. For example, when receiving a phone call a customer service representative can ask a question to the customer\u2019s phone to authenticate the caller, \u201cAre you on the phone with our representative?\u201d. The same could be done to authorize transactions, validate logins (2FA), accept terms and conditions, and any other simple, non-negotiable exchanges.</p>"},{"location":"features/0113-question-answer/#tutorial","title":"Tutorial","text":"<p>We'll describe this protocol in terms of a [Challenge/Response] https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication) scenario where a customer service representative for Faber Bank questions its customer Alice, who is speaking with them on the phone, to answer whether it is really her.</p>"},{"location":"features/0113-question-answer/#interaction","title":"Interaction","text":"<p>Using an already established pairwise connection and agent-to-agent communication Faber will send a question to Alice with one or more valid responses with an optional deadline and Alice can select one of the valid responses or ignore the question. If she selects one of the valid responses she will respond with her answer.</p>"},{"location":"features/0113-question-answer/#roles","title":"Roles","text":"<p>There are two parties in a typical question/answer interaction. The first party (Questioner) issues the question with its valid answers and the second party (Responder) responds with the selected answer. The parties must have already exchanged pairwise keys and created a connection. These pairwise can be used to encrypt and verify the response. When the answer has been sent questioner can know with a high level of certainty that it was sent by responder.</p> <p>In this tutorial Faber (the questioner) initiates the interaction and creates and sends the question to Alice. The question includes the valid responses, which can optionally be signed for non-repudiability.</p> <p>In this tutorial Alice (the responder) receives the packet and must respond to the question (or ignore it, which is not an answer) by encrypting either the positive or the negative response_code (signing both is invalid).</p>"},{"location":"features/0113-question-answer/#messages","title":"Messages","text":"<p>All messages in this protocol are part of the \"Question/Answer 1.0\" message family uniquely identified by this DID reference:</p> <pre><code>https://didcomm.org/questionanswer/1.0\n</code></pre> <p>The protocol begins when the questioner sends a <code>questionanswer</code> message to the responder:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/questionanswer/1.0/question\",\n  \"@id\": \"518be002-de8e-456e-b3d5-8fe472477a86\",\n  \"question_text\": \"Alice, are you on the phone with Bob from Faber Bank right now?\",\n  \"question_detail\": \"This is optional fine-print giving context to the question and its various answers.\",\n  \"nonce\": \"&lt;valid_nonce&gt;\",\n  \"signature_required\": true,\n  \"valid_responses\" : [\n    {\"text\": \"Yes, it's me\"},\n    {\"text\": \"No, that's not me!\"}],\n  \"~timing\": {\n    \"expires_time\": \"2018-12-13T17:29:06+0000\"\n  }\n}\n</code></pre> <p>The responder receives this message and chooses the answer. If the signature is required then she uses her private pairwise key to sign  her response.</p> <pre><code>Note: Alice should sign the following: the question, the chosen answer,\nand the nonce: HASH(&lt;question_text&gt;+&lt;answer_text&gt;+&lt;nonce&gt;), this keeps a\nrecord of each part of the transaction.\n</code></pre> <p>The response message is then sent using the ~sig message decorator:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/questionanswer/1.0/answer\",\n  \"~thread\": { \"thid\": \"518be002-de8e-456e-b3d5-8fe472477a86\", \"seqnum\": 0 },\n  \"response\": \"Yes, it's me\",\n  \"response~sig\": {\n    \"@type\": \"https://didcomm.org/signature/1.0/ed25519Sha512_single\"\n    \"signature\": \"&lt;digital signature function output&gt;\",\n    \"sig_data\": \"&lt;base64url(HASH(\"Alice, are you on the phone with Bob?\"+\"Yes, it's me\"+\"&lt;nonce&gt;\"))&gt;\",\n    \"signers\": [\"&lt;responder_key&gt;\"],\n    }\n  \"~timing\": {\n    \"out_time\": \"2018-12-13T17:29:34+0000\"\n  }\n}\n</code></pre> <p>The questioner then checks the signature against the sig_data.</p>"},{"location":"features/0113-question-answer/#optional-elements","title":"Optional Elements","text":"<p>The \"question_detail\" field is optional. It can be used to give \"fine print\"-like context around the question and all of its valid responses. While this could always be displayed, some UIs may choose to only make it available on-demand, in a \"More info...\" kind of way.</p> <p>~timing.expires_time is optional ~response~sig is optional when \"signature_required\" is false</p>"},{"location":"features/0113-question-answer/#business-cases-and-auditing","title":"Business cases and auditing","text":"<p>In the above scenario, Faber bank can audit the reply and prove that only Alice's pairwise key signed the response  (a cryptographic API like Indy-SDK can be used to guarantee the responder's signature). Conversely, Alice can also use her key to prove or dispute the validity of the signature. The cryptographic guarantees central to agent-to-agent communication and digital signatures create a trustworthy protocol for obtaining a committed answer from a pairwise connection. This  protocol can be used for approving wire transfers, accepting EULAs, or even selecting an item from a food menu. Of course,  as with a real world signature, Alice should be careful about what she signs.</p>"},{"location":"features/0113-question-answer/#invalid-replies","title":"Invalid replies","text":"<p>The responder may send an invalid, incomplete, or unsigned response. In this case the questioner must decide what to do. As with normal verbal communication, if the response is not understood the question can be asked again, maybe with increased emphasis. Or the questioner may determine the lack of a valid response is a response in and of itself. This depends on the parties involved and the question being asked. For example, in the exchange above, if the question times out or the answer is not \"Yes, it's me\" then Faber would probably choose to discontinue the phone call.</p>"},{"location":"features/0113-question-answer/#trust-and-constraints","title":"Trust and Constraints","text":"<p>Using already established pairwise relationships allows each side to trust each other. The responder can know who sent the message and the questioner knows that only the responder could have encrypted the response. This response gives a high level of trust to the exchange.</p>"},{"location":"features/0113-question-answer/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem."},{"location":"features/0114-predefined-identities/","title":"Aries RFC 0114: Predefined Identities","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Start Date: 2019-07-10</li> <li>Tags: feature</li> </ul>"},{"location":"features/0114-predefined-identities/#summary","title":"Summary","text":"<p>Documents some keys, DIDs, and DID Docs that may be useful for testing, simulation, and spec writing. The fake ones are the DIDComm / identity analogs to the reserved domain \"example.com\" that was allocated for testing purposes with DNS and other internet systems -- or to Microsoft's example Contoso database and website used to explore and document web development ../../concepts.</p>"},{"location":"features/0114-predefined-identities/#real-identities","title":"Real Identities","text":"<p>The following real--NOT fake--identities are worth publicly documenting.</p>"},{"location":"features/0114-predefined-identities/#aries-community","title":"Aries community","text":"<p>The collective Aries developer community is represented by:</p> <pre><code>did:sov:BzCbsNYhMrjHiqZDTUASHg -- verkey = 6zJ9dboyug451A8dtLgsjmjyguQcmq823y7vHP6vT2Eu\n</code></pre> <p>This DID is currently allocated, but not actually registered on Sovrin's mainnet. You will see this DID in a number of RFCs, as the basis of a PIURI that identifies a community-defined protocol. You DO NOT have to actually resolve this DID or relate to a Sovrin identity to use Aries or its RFCs; think of this more like the opaque URNs that are sometimes used in XML namespacing. At some point it may be registered, but nothing else in the preceding summary will change.</p> <p>The community controls a second DID that is useful for defining message families that are not canonical (e.g., in the sample tic-tac-toe protocol). It is:</p> <pre><code>did:sov:SLfEi9esrjzybysFxQZbfq -- verkey = Ep1puxjTDREwEyz91RYzn7arKL2iKQaDEB5kYDUUUwh5\n</code></pre> <p>This community may create DIDs for itself from other DID methods, too. If so, we will publish them here.</p>"},{"location":"features/0114-predefined-identities/#subgroups","title":"Subgroups","text":"<p>The Aries community may create subgroups with their own DIDs. If so, we may publish such information here.</p>"},{"location":"features/0114-predefined-identities/#allied-communities","title":"Allied communities","text":"<p>Other groups such as DIF, the W3C Crecentials Community Group, and so forth may wish to define identities and announce their associated DIDs here.</p>"},{"location":"features/0114-predefined-identities/#fake-identities","title":"Fake Identities","text":"<p>The identity material shown below is not registered anywhere. This is because sometimes our tests or demos are about registering or connecting, and because the identity material is intended to be somewhat independent of a specific blockchain instance. Instead, we define values and give them names, permalinks, and semantics in this RFC. This lets us have a shared understanding of how we expect them to behave in various contexts.</p> <p>WARNING: Below you will see some published secrets. By disclosing private keys and/or their seeds, we are compromising the keypairs. This fake identity material is thus NOT trustworthy for anything; the world knows the secrets, and now you do, too. <code>:-)</code> You can test or simulate workflows with these keys. You might use them in debugging and development. But you should never use them as the basis of real trust.</p>"},{"location":"features/0114-predefined-identities/#dids","title":"DIDs","text":""},{"location":"features/0114-predefined-identities/#alice-sov-1","title":"alice-sov-1","text":"<p>This DID, the <code>alice-sov-1</code> DID with value <code>did:sov:UrDaZsMUpa91DqU3vrGmoJ</code>, is associated with a very simplistic Indy/Sovrin identity. It has a single keypair (Key 1 below) that it uses for everything. In demos or tests, its genesis DID Doc looks like this:</p> <pre><code>{\n    \"@context\": \"https://w3id.org/did/v0.11\",\n    \"id\": \"did:sov:UrDaZsMUpa91DqU3vrGmoJ\",\n    \"service\": [{\n        \"type\": \"did-communication\",\n        \"serviceEndpoint\": \"https://localhost:23456\"\n    }],\n    \"publicKey\": [{\n        \"id\": \"#key-1\",\n        \"type\": \"Ed25519VerificationKey2018\",\n        \"publicKeyBase58\": \"GBMBzuhw7XgSdbNffh8HpoKWEdEN6hU2Q5WqL1KQTG5Z\"\n    }],\n    \"authentication\": [\"#key-1\"]\n}\n</code></pre>"},{"location":"features/0114-predefined-identities/#bob-many-1","title":"bob-many-1","text":"<p>This DID, the <code>bob-many-1</code> DID with value <code>did:sov:T9nQQ8CjAhk2oGAgAw1ToF</code>, is associated with a much more flexible, complex identity than <code>alice-sov-1</code>. It places every test keypair except Key 1 in the <code>authentication</code> section of its DID Doc. This means you should be able to talk to Bob using the types of crypto common in many communities, not just Indy/Sovrin. Its genesis DID doc looks like this:</p> <pre><code>{\n    \"@context\": \"https://w3id.org/did/v0.11\",\n    \"id\": \"did:sov:T9nQQ8CjAhk2oGAgAw1ToF\",\n    \"service\": [{\n        \"type\": \"did-communication\",\n        \"serviceEndpoint\": \"https://localhost:23457\"\n    }],\n    \"publicKey\": [{\n        \"id\": \"#key-2\",\n        \"type\": \"Ed25519VerificationKey2018\",\n        \"controller\": \"#id\",\n        \"publicKeyBase58\": \"FFhViHkJwqA15ruKmHQUoZYtc5ZkddozN3tSjETrUH9z\"\n      },\n      {\n        \"id\": \"#key-3\",\n        \"type\": \"Secp256k1VerificationKey2018\",\n        \"controller\": \"#id\",\n        \"publicKeyHex\": \"3056301006072a8648ce3d020106052b8104000a03420004a34521c8191d625ff811c82a24a60ff9f174c8b17a7550c11bba35dbf97f3f04392e6a9c6353fd07987e016122157bf56c487865036722e4a978bb6cd8843fa8\"\n      },\n      {\n        \"id\": \"#key-4\",\n        \"type\": \"RsaVerificationKey2018\",\n        \"controller\": \"#id\",\n        \"publicKeyPem\": \"-----BEGIN PUBLIC KEY-----\\r\\nMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlOJu6TyygqxfWT7eLtGDwajtN\\r\\nFOb9I5XRb6khyfD1Yt3YiCgQWMNW649887VGJiGr/L5i2osbl8C9+WJTeucF+S76\\r\\nxFxdU6jE0NQ+Z+zEdhUTooNRaY5nZiu5PgDB0ED/ZKBUSLKL7eibMxZtMlUDHjm4\\r\\ngwQco1KRMDSmXSMkDwIDAQAB\\r\\n-----END PUBLIC KEY-----\"\n      },\n      {\n        \"id\": \"#key-5\",\n        \"type\": \"RsaVerificationKey2018\",\n        \"controller\": \"#id\",\n        \"publicKeyPem\": \"-----BEGIN PUBLIC KEY-----\\r\\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAoZp7md4nkmmFvkoHhQMw\\r\\nN0lcpYeKfeinKir7zYWFLmpClZHawZKLkB52+nnY4w9ZlKhc4Yosrw/N0h1sZlVZ\\r\\nfOQBnzFUQCea6uK/4BKHPhiHpN73uOwu5TAY4BHS7fsXRLPgQFB6o6iy127o2Jfb\\r\\nUVpbNU/rJGxVI2K1BIzkfrXAJ0pkjkdP7OFE6yRLU4ZcATWSIPwGvlF6a0/QPC3B\\r\\nbTvp2+DYPDC4pKWxNF/qOwOnMWqxGq6ookn12N/GufA/Ugv3BTVoy7I7Q9SXty4u\\r\\nUat19OBJVIqBOMgXsyDz0x/C6lhBR2uQ1K06XRa8N4hbfcgkSs+yNBkLfBl7N80Q\\r\\n0Wkq2PHetzQU12dPnz64vvr6s0rpYIo20VtLzhYA8ZxseGc3s7zmY5QWYx3ek7Vu\\r\\nwPv9QQzcmtIQQsUbekPoLnKLt6wJhPIGEr4tPXy8bmbaThRMx4tjyEQYy6d+uD0h\\r\\nXTLSjZ1SccMRqLxoPtTWVNXKY1E84EcS/QkqlY4AthLFBL6r+lnm+DlNaG8LMwCm\\r\\ncz5NMag9ooM9IqgdDYhUpWYDSdOvDubtz1YZ4hjQhaofdC2AkPXRiQvMy/Nx9WjQ\\r\\nn4z387kz5PK5YbadoZYkwtFttmxJ/EQkkhGEDTXoSRTufv+qjXDsmhEsdaNkvcDP\\r\\n1uiCSY19UWe5LQhIMbR0u/0CAwEAAQ==\\r\\n-----END PUBLIC KEY-----\"\n      },\n    ],\n    \"authentication\": [\"#key-2\", \"#key-3\", \"#key-4\", \"#key-5\", \"#key-6\"]\n}\n</code></pre> <p>[TODO: define DIDs from other ecosystems that put the same set of keys in their DID docs -- maybe <code>bob-many-2</code> is a did:eth using these same keys, and <code>bob-many-3</code> is a did:btc using them...]</p>"},{"location":"features/0114-predefined-identities/#keys","title":"Keys","text":""},{"location":"features/0114-predefined-identities/#key-1-ed25519","title":"Key 1 (Ed25519)","text":"<p>This key is used by the <code>alice-sov-1</code> DID, but could also be used with other DIDs defined elsewhere.</p> <pre><code>signing key (private)\nGa3v3SyNsvv1QhSCrEAQfJiyxQYUdZzQARkCosSWrXbT\n\nhex seed (private; in a form usable by Indy CLI)\ne756c41c1b5c48d3be0f7b5c7aa576d2709f13b67c9078c7ded047fe87c8a79e\n\nverkey (public)\nGBMBzuhw7XgSdbNffh8HpoKWEdEN6hU2Q5WqL1KQTG5Z\n\nas a Sovrin DID\ndid:sov:UrDaZsMUpa91DqU3vrGmoJ\n</code></pre>"},{"location":"features/0114-predefined-identities/#key-2-ed25519","title":"Key 2 (Ed25519)","text":"<p>This key is used by the <code>bob-many-1</code> DID, but could also be used with other DIDs defined elsewhere.</p> <pre><code>signing key (private)\nFE2EYN25vcQmCU52MkiHuXHKqR46TwjFU4D4TGaYDRyd\n\nhex seed (private)\nd3598fea152e6a480faa676a76e545de7db9ac1093b9cee90b031d9625f3ce64\n\nverkey (public)\nFFhViHkJwqA15ruKmHQUoZYtc5ZkddozN3tSjETrUH9z\n\nas a Sovrin DID\ndid:sov:T9nQQ8CjAhk2oGAgAw1ToF\n</code></pre>"},{"location":"features/0114-predefined-identities/#key-3-secp256k1","title":"Key 3 (Secp256k1)","text":"<p>This key is used by the <code>bob-many-1</code> DID, but could also be used with other DIDs defined elsewhere.</p> <pre><code>-----BEGIN EC PRIVATE KEY-----\nMHQCAQEEIMFcUvDujXt0/C48vm1Wfj8ADlrGsHCHzp//2mUARw79oAcGBSuBBAAK\noUQDQgAEo0UhyBkdYl/4EcgqJKYP+fF0yLF6dVDBG7o12/l/PwQ5LmqcY1P9B5h+\nAWEiFXv1bEh4ZQNnIuSpeLts2IQ/qA==\n-----END EC PRIVATE KEY-----\n\n-----BEGIN PUBLIC KEY-----\nMFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAEo0UhyBkdYl/4EcgqJKYP+fF0yLF6dVDB\nG7o12/l/PwQ5LmqcY1P9B5h+AWEiFXv1bEh4ZQNnIuSpeLts2IQ/qA==\n-----END PUBLIC KEY-----\n\npublic key as hex\n3056301006072a8648ce3d020106052b8104000a03420004a34521c8191d625ff811c82a24a60ff9f174c8b17a7550c11bba35dbf97f3f04392e6a9c6353fd07987e016122157bf56c487865036722e4a978bb6cd8843fa8\n</code></pre>"},{"location":"features/0114-predefined-identities/#key-4-1024-bit-rsa","title":"Key 4 (1024-bit RSA)","text":"<p>This key is used by the <code>bob-many-1</code> DID, but could also be used with other DIDs defined elsewhere.</p> <pre><code>-----BEGIN RSA PRIVATE KEY-----\nMIICXQIBAAKBgQDlOJu6TyygqxfWT7eLtGDwajtNFOb9I5XRb6khyfD1Yt3YiCgQ\nWMNW649887VGJiGr/L5i2osbl8C9+WJTeucF+S76xFxdU6jE0NQ+Z+zEdhUTooNR\naY5nZiu5PgDB0ED/ZKBUSLKL7eibMxZtMlUDHjm4gwQco1KRMDSmXSMkDwIDAQAB\nAoGAfY9LpnuWK5Bs50UVep5c93SJdUi82u7yMx4iHFMc/Z2hfenfYEzu+57fI4fv\nxTQ//5DbzRR/XKb8ulNv6+CHyPF31xk7YOBfkGI8qjLoq06V+FyBfDSwL8KbLyeH\nm7KUZnLNQbk8yGLzB3iYKkRHlmUanQGaNMIJziWOkN+N9dECQQD0ONYRNZeuM8zd\n8XJTSdcIX4a3gy3GGCJxOzv16XHxD03GW6UNLmfPwenKu+cdrQeaqEixrCejXdAF\nz/7+BSMpAkEA8EaSOeP5Xr3ZrbiKzi6TGMwHMvC7HdJxaBJbVRfApFrE0/mPwmP5\nrN7QwjrMY+0+AbXcm8mRQyQ1+IGEembsdwJBAN6az8Rv7QnD/YBvi52POIlRSSIM\nV7SwWvSK4WSMnGb1ZBbhgdg57DXaspcwHsFV7hByQ5BvMtIduHcT14ECfcECQATe\naTgjFnqE/lQ22Rk0eGaYO80cc643BXVGafNfd9fcvwBMnk0iGX0XRsOozVt5Azil\npsLBYuApa66NcVHJpCECQQDTjI2AQhFc1yRnCU/YgDnSpJVm1nASoRUnU8Jfm3Oz\nuku7JUXcVpt08DFSceCEX9unCuMcT72rAQlLpdZir876\n-----END RSA PRIVATE KEY-----\n\n-----BEGIN PUBLIC KEY-----\nMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlOJu6TyygqxfWT7eLtGDwajtN\nFOb9I5XRb6khyfD1Yt3YiCgQWMNW649887VGJiGr/L5i2osbl8C9+WJTeucF+S76\nxFxdU6jE0NQ+Z+zEdhUTooNRaY5nZiu5PgDB0ED/ZKBUSLKL7eibMxZtMlUDHjm4\ngwQco1KRMDSmXSMkDwIDAQAB\n-----END PUBLIC KEY-----\n</code></pre>"},{"location":"features/0114-predefined-identities/#key-5-4096-bit-rsa","title":"Key 5 (4096-bit RSA)","text":"<p>This key is used by the <code>bob-many-1</code> DID, but could also be used with other DIDs defined elsewhere.</p> <pre><code>-----BEGIN RSA PRIVATE KEY-----\nMIIJKAIBAAKCAgEAoZp7md4nkmmFvkoHhQMwN0lcpYeKfeinKir7zYWFLmpClZHa\nwZKLkB52+nnY4w9ZlKhc4Yosrw/N0h1sZlVZfOQBnzFUQCea6uK/4BKHPhiHpN73\nuOwu5TAY4BHS7fsXRLPgQFB6o6iy127o2JfbUVpbNU/rJGxVI2K1BIzkfrXAJ0pk\njkdP7OFE6yRLU4ZcATWSIPwGvlF6a0/QPC3BbTvp2+DYPDC4pKWxNF/qOwOnMWqx\nGq6ookn12N/GufA/Ugv3BTVoy7I7Q9SXty4uUat19OBJVIqBOMgXsyDz0x/C6lhB\nR2uQ1K06XRa8N4hbfcgkSs+yNBkLfBl7N80Q0Wkq2PHetzQU12dPnz64vvr6s0rp\nYIo20VtLzhYA8ZxseGc3s7zmY5QWYx3ek7VuwPv9QQzcmtIQQsUbekPoLnKLt6wJ\nhPIGEr4tPXy8bmbaThRMx4tjyEQYy6d+uD0hXTLSjZ1SccMRqLxoPtTWVNXKY1E8\n4EcS/QkqlY4AthLFBL6r+lnm+DlNaG8LMwCmcz5NMag9ooM9IqgdDYhUpWYDSdOv\nDubtz1YZ4hjQhaofdC2AkPXRiQvMy/Nx9WjQn4z387kz5PK5YbadoZYkwtFttmxJ\n/EQkkhGEDTXoSRTufv+qjXDsmhEsdaNkvcDP1uiCSY19UWe5LQhIMbR0u/0CAwEA\nAQKCAgBWzqj+ajtPhqd1JEcNyDyqNhoyQLDAGa1SFWzVZZe46xOBTKv5t0KI1BSN\nT86VibVRCW97J8IA97hT2cJU5hv/3mqQnOro2114Nv1i3BER5hNXGP5ws04thryW\nAH0RoQNKwGUBpzl5mDEZUFZ7oncJKEQ+SwPAuQCy1V7vZs+G0RK7CFcjpmLkl81x\nkjl0UIQzkhdA6KCmsxXTdzggW2O/zaM9nXYKPxGwP+EEhVFJChlRjkI8Vv32z0vk\nh7A0ST16UTsL7Tix0rfLI/OrTn9LF5NxStmZNB1d5v30FwtiqXkGcQn/12QhGjxz\nrLbGDdU3p773AMJ1Ac8NhpKN0vXo7NOh9qKEq0KfLy+AD6CIDB9pjZIolajqFOmO\nRENAP9eY/dP7EJNTSU84GJn8csQ4imOIYqp0FkRhigshMbr7bToUos+/OlHYbMry\nr/I8VdMt4xazMK5PtGn9oBzfv/ovNyrQxv562rtx3G996HFF6+kCVC3mBtTHe0p2\nVKNJaXlQSkEyrYAOqhnMvIfIMuuG2+hIuv5LBBdCyv6YC4ER2RsaXHt4ZBfsbPfO\nTEP4YCJTuLc+Fyg1f01EsuboB0JmvzNyiK+lBp8FsxiqwpIExriBCPJgaxoWJMFh\nxrRzTXwBWkJaDhYVbc2bn8TtJE6uEC9m4B7IUQOrXXKyOTqUgQKCAQEAzJl16J3Y\nYjkeJORmvi2J1UbaaBJAeCB7jwXlarwAq8sdxEqdDoRB6cZhWX0VMH46oaUA+Ldx\nCoO2iMgOrs0p6dJOj1ybtIhiX9PJTzstd5WEltU/mov+DzlBiKg78dFi/B5HfE/F\nKIDx4gTcD//sahooMqbg78QfOO+JjLrvT7TljL/puOAM8LTytZqOaDIDwnblpSgZ\nJcCqochmz9b7f7NHbgVrBkXZTsgbH6Dw4H7T0WC4K4P4dJW8Js18r+xN3W8/ZhmY\nlxTDZy40LlUy7++Ha+v8vZ4cRJKq2sdTtt9Z/ZYDfpCDT5ZmGS/gDloGean9mivG\nlt/zgDswEUji9QKCAQEAyjPKsBitJ39S26H/hp5oZRad1MOXgXPpbu8ARmHooKP3\nQ0dtnreBLzIQxxIitp3GjzJFU9r/tqy/ylOhIGAt+340KoSye3gGpvxZImMAIIR9\ns03GE5AHJ4J5NIxQKX+g9o0fV44bVNrLzAnHaZh+Bi4xbLatBJABgN2TnjA8lx7x\nlrqb99VpKLZP7DGxK7o0Ji4qerMPeIVoJ9RaUkTYguJaXG22nPeKfDiI13xlm1RU\nptulJG3CkRYp48Udmqb1b+67KMOxKL1ISGhuzqitOY+Ua1sM5SEFyukEhMuK6/uM\nSCAVl9aNHU5vx95D/T7onPAnxNqDObWeZi2HWoif6QKCAQEAxC4BmOKBMO2Dsewv\nd/tCRnaBxXh6yLScxS7qI8XQ/ujryeOhZOH8MaQ+hAgj4TOoFIaav+FlSqewxsbN\nDV876S/2lBBAXILJkQkJ5ibgGeIMGHSxYAcLvJ0x8U8e62fSedyuvsveSFAbnpT6\nTX0fuz0Jfkf1NvHe3kEQqxgzj0HtOWBrQxHSVpuqfeeM1OvgHv7Sg+JG+qQa+LWn\nn3KMBI5q11vqm0EudRP6rgEr9pallAYhkdggy+knWC2AeU8j+kdJiyTP403Nb4om\nDqczCE2slBbbaRXKFRZtLQojgx32s+i7wQfgYNfdXhlBxYEc5FvTB5kh+lkSqsoV\n9PzmYQKCAQBrQHGAWnZt/uEqUpFBDID/LbHmCyEvrxXgm7EfpAtKOe6LpzWD/H3v\nVLUFgp8bEjEh/146jm0YriTE4vsSOzHothZhfyVUzGNq62s0DCMjHGO4WcZ41eqV\nkGVN9CcI/AObA1veiygAKFX1EjLN1e7yxEm/Cl5XjzLc8aq9O4TH+8fVVYIpQO+Y\ngqt98xWwxgGnRtGNZ7ELEmgeyEpoXNAjDIE1iZRVShAQt8QN2JPkgiSspNDBs96C\nKqlpgUKkp26EQrLPeo1buJrAnXQ49ct8PqZRE2iRmKSD7nlRHs2/Qhw0naAWe905\n8ELmVwTlLRshM1lE10rHr4gnVnr3EIURAoIBAFXLQXV9CuLoV9nosprVYbhSWLMj\nO9ChjgGfCmqi3gQecJxctwNlo3l8f5W2ZBrIqgWFsrxzHd2Ll4k2k/IcFa4jtz9+\nPrSGZz8TEkM5ERSwDd1QXNE/P7AV6EDs/W/V0T5G1RE82YGkf0PNM+drJ/r/I4HS\nN0DDlZb8YwjkP1tT8x3I+vx9bLWczbsMhrwIEUPQJZxMSdZ+DMM45TwAXyp9aLzU\npa9CdL1gAtSLA7AmcafGeUIA7N1evRYuUVWhhSRjPX55hGBoO0u9fxZIPRTf0dcK\nHHK05KthUPh7W5TXSPbni/GyuNg3H7kavT7ANHOwI77CfaKFgxLrZan+sAk=\n-----END RSA PRIVATE KEY-----\n\n-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAoZp7md4nkmmFvkoHhQMw\nN0lcpYeKfeinKir7zYWFLmpClZHawZKLkB52+nnY4w9ZlKhc4Yosrw/N0h1sZlVZ\nfOQBnzFUQCea6uK/4BKHPhiHpN73uOwu5TAY4BHS7fsXRLPgQFB6o6iy127o2Jfb\nUVpbNU/rJGxVI2K1BIzkfrXAJ0pkjkdP7OFE6yRLU4ZcATWSIPwGvlF6a0/QPC3B\nbTvp2+DYPDC4pKWxNF/qOwOnMWqxGq6ookn12N/GufA/Ugv3BTVoy7I7Q9SXty4u\nUat19OBJVIqBOMgXsyDz0x/C6lhBR2uQ1K06XRa8N4hbfcgkSs+yNBkLfBl7N80Q\n0Wkq2PHetzQU12dPnz64vvr6s0rpYIo20VtLzhYA8ZxseGc3s7zmY5QWYx3ek7Vu\nwPv9QQzcmtIQQsUbekPoLnKLt6wJhPIGEr4tPXy8bmbaThRMx4tjyEQYy6d+uD0h\nXTLSjZ1SccMRqLxoPtTWVNXKY1E84EcS/QkqlY4AthLFBL6r+lnm+DlNaG8LMwCm\ncz5NMag9ooM9IqgdDYhUpWYDSdOvDubtz1YZ4hjQhaofdC2AkPXRiQvMy/Nx9WjQ\nn4z387kz5PK5YbadoZYkwtFttmxJ/EQkkhGEDTXoSRTufv+qjXDsmhEsdaNkvcDP\n1uiCSY19UWe5LQhIMbR0u/0CAwEAAQ==\n-----END PUBLIC KEY-----\n</code></pre>"},{"location":"features/0114-predefined-identities/#key-6-ed25519","title":"Key 6 (Ed25519)","text":"<p>This key is used by the <code>bob-many-1</code> DID, but could also be used with other DIDs defined elsewhere.</p> <pre><code>signing key (private)\n9dTU6xawVQJprz7zYGCiTJCGjHdW5EcZduzRU4z69p64\n\nhex seed (private; in a form usable by Indy CLI)\n803454c9429467530b17e8e571df5442b6620ac06ab0172d943ab9e01f6d4e31\n\nverkey (public)\n4zZJaPg26FYcLZmqm99K2dz99agHd5rkhuYGCcKntAZ4\n\nas a Sovrin DID\ndid:sov:8KrDpiKkHsFyDm3ZM36Rwm\n</code></pre>"},{"location":"features/0114-predefined-identities/#tools-to-generate-your-own-identity-material","title":"Tools to generate your own identity material","text":"<ul> <li>Digital Bazaar's DID tool</li> <li>uPort tool</li> <li>Ed25519 and Indy-compatible DIDs in pure client-side javascript</li> <li>Hyperledger Indy CLI</li> </ul>"},{"location":"features/0114-predefined-identities/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0116-evidence-exchange/","title":"Aries RFC 0116: Evidence Exchange Protocol 0.9","text":"<ul> <li>Authors: Dan Gisolfi</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Start Date: 2019-07-05</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0116-evidence-exchange/#summary","title":"Summary","text":"<p>The goal of this protocol is to allow Holders to provider an inquiring Verifier with a secure and trusted mechanism for obtaining access to the foundational evidence that enabled the Issuer the assurances necessary to create the Verifiable Credential(s) that the Holder has presented to the Verifier. To this end, a P2P evidence exchange protocol is required that will allow parties using Pair-wise Peer DIDs to exchange evidence in support of the issuance of Verified Credentials without any dependencies on a  centralized storage facility.</p>"},{"location":"features/0116-evidence-exchange/#motivation","title":"Motivation","text":"<p>During the identity verification process, an entity may require access to the genesis documents used to establish digital credentials issued by a credential issuing entity or Credential Service Provider (CSP).  In support of the transition from existing business verification processes to emerging business processes that rely on digitally verified credentials using protocols such as 0036-issue-credential and 0037-present-proof, we need to establish a protocol that allow entities to make this transition while remaining compliant with business and regulatory requirements. Therefore, we need a mechanism for Verifiers to obtain access to vetted evidence (physical or digital information or documentation) without requiring a relationship or interaction with the Issuer.</p> <p>While this protocol should be supported by all persona, its relevance to decentralized identity ecosystems is highly dependent on the business policies of a market segment of Verifiers. For more details see the Persona section.</p> <p>While technology advancements around identity verification are improving, business policies (most often grounded in risk mitigation) will not change at the same rate of speed. For example, just because a financial institution in Singapore is willing to rely on the KYC due-diligence processing of another institution, we should not assume that the banks in another geolocation (i.e: Hong Kong) can embrace the same level of trust. For this reason, we must enable Verifiers with the option to obtain evidence that backs any assertions made by digital credential issuers.</p> <p>Based on a web-of-trust and cryptographic processing techniques, Verifiers of digital credentials can fulfill their identity proofing workflow requirements. However, business policies and regulatory compliance may require them to have evidence for oversight activities such as but not limited to government mandated Anti-Money Laundering (AML) Compliance audits.</p> <p>Verifiers or relying parties (RPs) of digital credentials need to make informed decisions about the risk of accepting a digital identity before trusting the digital credential and granting associated privileges. To mitigate such risk, the Verifier may need to understand the strength of the identity proofing process. According to a December 2015 - NIST Information Technology Laboratory Workshop Report, Measuring Strength of Identity Proofing, there are two (2) identity proofing methods that can be leveraged by a CSP:</p> Proofing Method Description In-Person Identity Proofing Holder is required to present themselves and their documentation directly to a trained representative of an identity proofing agency. Remote Identity Proofing Holder is not expected to present themselves or their documents at a physical location. Validation and verification of presented data (including digital documents) is performed programmatically against one or more corroborating authoritative sources of data. <p>If the In-Person Identity Proofing method is used, the strength can easily be determined by allowing the Verifier to gain access to any Original Documents used by the Issuer of a Derived Credential. In the situation where a Remote Identity Proofing method is used, confidence in the strength of the identity proofing process can be determined by allowing the Verifier to gain access to Digital Assertions used by the Issuer of a Derived Credential.</p>"},{"location":"features/0116-evidence-exchange/#problem-scope","title":"Problem Scope","text":"<p>This protocol is intended to address the following challenging questions:</p> <ol> <li> <p>What evidence (information or documentation) was used to establish the level of certitude necessary to allow an Issuer to issue a Verifiable Credential?</p> </li> <li> <p>For each Identity Proofing Inquiry (challenge) such as Address, Identity, Photo and Achievement, which forms of evidence was used by the Issuer of the Verifiable Credential?</p> </li> <li> <p>When the Issuer's Examinier relies on an Identity Proofing Service Provider (IPSP) as part of its Remote Identity Proofing process:</p> </li> <li> <p>Can the IPSP provide a Digital Assertion in association with the Identity Instrument they have vetted as part of their service to the Examiner?</p> </li> <li> <p>Can the Issuer provide a Digital Assertion in association with its certitude in the reliability of its due-diligence activity that is dependent on 3<sup>rd</sup> parties?</p> </li> <li> <p>When the Issuer relies on trained examiners for its In-Person Identity Proofing process, can the Issuer provide access to the digitally scanned documents either by-value or by-reference?</p> </li> </ol>"},{"location":"features/0116-evidence-exchange/#assurance-levels","title":"Assurance Levels","text":"<p>Organizations that implement Identity Proofing generally seek to balance cost, convenience, and security for both the Issuer and the Holder. Examples of these tradeoffs include:</p> <ul> <li>Adjusting the complexity of a Remote Identity Proofing process to improve user experience can reduce the quality of the verification process;</li> <li>Overly complex proofing processes can result in increased abandonment which is unacceptable to some service providers;</li> <li>Overly generalized processes based on expected population characteristics (e.g., national origin, country of residency) can lead to persons that are unable to complete proofing as they may not share such characteristics.</li> </ul> <p>To mitigate the risk associated with such tradeoffs, the NIST 800-63A Digital Identity Guidelines outline three (3) levels of identity proofing assurance. These levels describe the degree of due-diligence performed during an Identity Proofing Process. See Section 5.2 Identity Assurance Levels Table 5-1.</p> <p>Users of this protocol will need to understand the type of evidence that was collected and how it was confirmed so that they can adhere to any business processes that require IAL2 or IAL3  assurance levels supported by Strong or Superior forms of evidence.</p>"},{"location":"features/0116-evidence-exchange/#dematerialization-of-physical-documents","title":"Dematerialization of physical documents","text":"<p>Today, entities (businesses, organizations, government agencies) maintain existing processes for the gathering, examination and archiving of physical documents. These entities may retain a copy of a physical document, a scanned digital copy or both. Using manual or automated procedures, the information encapsulated within these documents is extracted and stored as personal data attestations about the document presenter within a system of record (SOR).</p> <p></p> <p>As decentralized identity technologies begin to be adopted, these entities can transform these attestations into Verifiable Credentials.</p>"},{"location":"features/0116-evidence-exchange/#understanding-kyc","title":"Understanding KYC","text":"<p>Know Your Customer (KYC) is a process by which entities (business, governments, organizations) obtain information about the identity and address of their customers. This process helps to ensure that the services that the entity provides are not misused. KYC procedures vary based on geolocation and industry. For example, the KYC documents required to open a bank account in India versus the USA may differ but the basic intent of demonstrating proof of identity and address are similar. Additionally, the KYC documents necessary to meet business processing requirements for enrollment in a university may differ from that of onboarding a new employee.</p> <p>Regardless of the type of KYC processing performed by an entity, there may be regulatory or business best practice requirements that mandate access to any Original Documents presented as evidence during the KYC process. As entities transition from paper/plastic based identity proofing practices to Verifiable Credentials there may exist (albeit only for a transitional period) the need to gain access to the Identity Evidence that an Issuer examined before issuing credentials.</p> <p>This process is time consuming and costly for the credential Issuer and often redundant and inconvenient for the Holder. Some industry attempts have been made to establish centrally controlled B2B sharing schemas to help reduce such impediments to the Issuer. These approaches are typically viewed as vital for the betterment of the Issuers and Verifiers and are not designed for or motivated by the data privacy concerns of the Holder. The purpose of this protocol is to place the Holder at the center of the P2P C2B exchange of Identity Evidence while allowing Verifiers to gain confidence in identity proofing assurance levels.</p>"},{"location":"features/0116-evidence-exchange/#evidence-vetting-workflow","title":"Evidence Vetting Workflow","text":"<p>The Verifiable Credentials Specification describes three key stakeholders in an ecosystem that manages digital credentials: Issuers, Holders and Verifiers. However, before an Issuer can attest to claims about a Holder, an Examiner must perform the required vetting, due diligence, regulatory compliance and other tasks needed to establish confidence in making a claim about an identity trait associated with a Holder. The actions of the Examiner may include physical validation of information (i.e.: comparison of real person to a photo) as well as reliance on third party services as part of its vetting process. Depending on the situational context of a credential request or the type of privileges to be granted, the complexity of the vetting process taken by an examiner to confirm the truth about a specific trait may vary.</p> <p></p> <p>An identity Holder may present to an Examiner Identity Evidence in the form of a physical document or other forms of Identity Instruments to resolve Identity Proofing Inquires. The presentment of these types of evidence may come in a variety of formats:</p> <ul> <li><code>Paper/Plastic</code>: Typically associated with a face to face interaction for the exchange of documents.</li> <li><code>Digital Copy</code>: Typically associated with an online exchange whereby the the Holder uploads a scanned image of the original source (Paper/Plastic) document.</li> <li><code>URL</code>: Holder can provide a link to a digital document version of the original source (Paper/Plastic) document on some 3<sup>rd</sup> Party file storage solution:</li> <li>Document Storage Provider (Dropbox, iCloud)</li> <li>Credential Issuing Agent (Retail Bank, Credit Union, Verification Service Provider)</li> </ul>"},{"location":"features/0116-evidence-exchange/#evidence-access-matrix","title":"Evidence Access Matrix","text":"<p>Note: Assumption herein is that original documents are never forfeited by an individual.</p> Original Source Format Issuer Archived Format Verifier Business Process Format Protocol Requirement Paper/Plastic Paper-Copy n/a n/a Paper/Plastic Digital Copy Digital Copy Access by Value Paper/Plastic Digital Copy URL Access by Reference Digital Copy Digital Copy Digital Copy Access by Value Digital Copy Digital Copy URL Access by Reference Digital Scan Digital Copy Digital Copy Digital Assertion URL Digital Copy Digital Copy Access by Value URL Digital Copy URL Access by Reference"},{"location":"features/0116-evidence-exchange/#why-a-peer-did-protocol","title":"Why a Peer DID Protocol?","text":"<p>In a decentralized identity ecosystem where peer relationships no longer depend on a centralized authority for the source of truth, why should a Verifier refer to some 3<sup>rd</sup> party or back to the issuing institution for capturing Identity Evidence?</p> <ul> <li>Centralized Shared-KYC Providers: While there seems to be a trend to build shared ledgers that manage the exchange of KYC documents and data, we can not ignore the user-centric privacy by design principle that is foundational to decentralized identity solutions. Pair-wise Peer DIDs offer an alternative approach that is independent of any central source of truth, and are intended to be cheap, fast, scalable, and secure. The advantages of Pair-wise Peer DIDs make them suitable for most private relationships between people, organizations, and things.</li> <li>Issuer Communications: B2B interactions between a Verifier of a credential and the Issuer of the credential injects unnecessary correlation and behavior privacy risks for the Holder.</li> </ul>"},{"location":"features/0116-evidence-exchange/#solution-concepts","title":"Solution Concepts","text":""},{"location":"features/0116-evidence-exchange/#protocol-assumptions","title":"Protocol Assumptions","text":"<ol> <li>Holder must present Identity Evidence access to Verifier such that Verifier can be assured that the Issuer vetted the evidence.</li> <li>Some business processes and/or regulatory compliance requirements may demand that a Verifier gains access to the Original Documents vetted by a credential Issuer.</li> <li>Some Issuers may accept digital access links to documents as input into vetting process. This is often associated with Issuers who will accept copies of the Original Documents.</li> <li>Some Issuer may accept Digital Assertions from IPSPs as evidence of their due-diligence process. Examples of such IPSPs are: Acuant, Au10tix, IWS, Onfido and 1Kosmos.</li> </ol>"},{"location":"features/0116-evidence-exchange/#protocol-objectives","title":"Protocol Objectives","text":"<p>In order for a Verifier to avoid or reduce evidence vetting expenses it must be able to:</p> <ul> <li>be convinced that a trusted entity has performed the necessary vetting;</li> <li>know, if required, that access to the original vetted evidence is possible.</li> </ul> <p>This implies that the protocol must address the following evidence concerns:</p> Interaction Type Challenge Protocol Approach Examiner-to-Holder How does Issuer provide Holder with proof that it has vetted Identity Evidence? Issuer signs hash of the evidence and presents signature to Holder. Holder-to-Verifier How does Holder present Verifier with evidence that the Issuer of a Credential vetted Identity Evidence? Holder presents verifier with digitally signed hash of evidence, public DID of Issuer and access to a copy of the digital evidence. Verifier-to-FileStorageProvider How does Verifier access the evidence in digital format (base64)? Issuer or Holder must provide secure access to a digital copy of the document. Verifier-to-Verifier How does Verifier validate that Issuer attests to the vetting of the Identity Evidence for personal data claims encapsulated in issued credentials? Verifier gains access to the digital evidence, fetches the public key associated with the Issuer's DID and validates Issuer's signature of document hash."},{"location":"features/0116-evidence-exchange/#protocol-outcome","title":"Protocol Outcome","text":"<p>This protocol is intended to be a compliment to the foundational (issuance, verification) protocols for credential lifecycle management in support of the Verifiable Credentials Specification. Overtime, it is assumed that the exchange of Identity Evidence will no longer be necessary as digital credentials become ubiquitous. In the meantime, the trust in and access to Identity Evidence can be achieved in private peer to peer relationships using the Peer DID Spec.</p>"},{"location":"features/0116-evidence-exchange/#persona","title":"Persona","text":"<p>This protocol addresses the business policy needs of a market segment of Verifiers. Agent Software used by the following persona is required to support this market segment.</p> Persona Applicability Examiner Entities that perform In-Person and/or Remote Identity Proofing processes and need to support potential requests for evidence in support of the issuance of Verifiable Credentials based on the results of such processes. Issuer Entities with the certitude to share with a Holder supporting evidence for the due-diligence performed in association with attestations backing an issued Verifiable Credential. Holder A recipient of a Verifiable Credential, that desires to proactively gather supporting evidence of such a credential incase a Verifier should inquire. Verifier Entities that require access to Original Documents or Digital Assertions because they can not (for business policy reasons) rely on the identity proofing due-diligence of others. These entities may refer to a Trust Score based on their own business heuristics associated with the type of evidence supplied: Original Documents, Digital Assertions."},{"location":"features/0116-evidence-exchange/#user-stories","title":"User Stories","text":"<p>An example of the applicability of this protocol to real world user scenarios is discussed in the context of a decentralized digital notary where the credential issuing institution is not the issuer of the original source document(s) or digital assertions.</p>"},{"location":"features/0116-evidence-exchange/#evidence-types","title":"Evidence Types","text":"<p>In the context of this protocol, Identity Evidence represents physical or digital information-based artifacts that support a belief to common Identity Proofing Inquires (challenges):</p> <ul> <li>Proof of Identity: Are you who you claim to be?</li> <li>Proof of Address: Do you reside at a valid and confirmed place of residence?</li> <li>Proof of Photo: Can you present either a physical or digital image that can be compared with corroborating authoritative sources of data?</li> <li>Proof of Achievement: Have you accomplished what you claim to have achieved?</li> <li>Proof of Privilege: Have you been granted certain rights or affiliations?</li> </ul> <p>The following, non-exhaustive, list of physical information-based artifacts (documents) are used as evidence when confronted with common identity related inquires. They are often accompanied with a recent photograph. Since this protocol is intended to be agnostic of business and regulatory processes, the types of acceptable documents will vary.</p> Proof Type Sample Documents Address Passport, Voter\u2019s Identity Card, Utility Bill (Gas, Electric, Telephone/Mobile), Bank Account Statement, Letter from any recognized public authority or public servant, Credit Card Statement, House Purchase deed, Lease agreement along with last 3 months rent receipt, Employer\u2019s certificate for residence proof Identity Passport, PAN Card, Voter\u2019s Identity Card, Driving License, Photo identity proof of Central or State government, Ration card with photograph, Letter from a recognized public authority or public servant, Bank Pass Book bearing photograph, Employee identity card of a listed company or public sector company, Identity card of University or board of education Photo Passport, Pistol Permit, Photo identity proof of Central or State government Achievement Diploma, Certificate Privilege Membership/Loyalty Card, Health Insurance Card <p>These forms of Identity Evidence are examples of trusted credentials that an Examiner relies on during their vetting process.</p> <p></p>"},{"location":"features/0116-evidence-exchange/#tutorial","title":"Tutorial","text":"<p>The evidence exchange protocol builds on the attachment decorator within DIDComm using the the Inlining Method for Digital Assertions and the Appending Method for Original Documents.</p> <p>The protocol is comprised of the following messages and associated actions:</p> Interaction Type Message Process Actions Holder to Issuer Request Evidence Holder reviews the list of credentials it has received from the Issuer and sends an <code>evidence_request</code> message to Issuer's agent. Issuer to Holder Evidence Response Issuer collects Identity Evidence associated with each requested credential ID and sends an <code>evidence_response</code> message to Holder's agent. Upon receipt, the Holder stores evidence data in Wallet. Verifier to Holder Evidence Access Request Verifier builds and sends an <code>evidence_access_request</code> message to Holder's agent. Holder to Verifier Evidence Access Response Holder builds and sends an <code>evidence_access_response</code> message to the Verifier's agent. Verifier fetches requested Identity Evidence and performs digital signature validation on each. Verifier stores evidence in system of record. <p></p>"},{"location":"features/0116-evidence-exchange/#request-evidence-message","title":"Request Evidence Message","text":"<p>This message should be used as an accompaniment to an issue credential message. Upon receipt and storage of a credential the Holder should compose an <code>evidence_request</code> for each credential received from the Issuer. The Holder may use this message to get an update for new and existing credentials from the Issuer.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/evidence_exchange/1.0/evidence_request\",\n  \"@id\": \"6a4986dd-f50e-4ed5-a389-718e61517207\",\n  \"for\": \"did:peer:1-F1220479cbc07c3f991725836a3aa2a581ca2029198aa420b9d99bc0e131d9f3e2cbe\",\n  \"as_of_time\": \"2019-07-23 18:05:06.123Z\",\n  \"credentials\": [\"cred-001\", \"cred-002\"],\n  \"request-type\": \"by-value\"\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>credentials</code>: A list of credential IDs associated with this pair-wise relationship with the Issuer.</li> <li><code>request-type</code>: Stipulates how the Holder's Agent will manage the document access. If <code>by-value</code>, then a copy of the document will be stored by the Holder. If <code>by-reference</code>, then the storage provider service used by the Issuer will be the source of the document and any access control mechanisms will also need to be conveyed.</li> </ul> <p></p>"},{"location":"features/0116-evidence-exchange/#evidence-response-message","title":"Evidence Response Message","text":"<p>This message is required for an Issuer Agent in response to an <code>evidence_request</code> message. The format of the <code>~attach</code> attribute will be determined by the value of the <code>request_type</code> attribute in the associated request message from the Holder. If the Issuer relied on one or more IPSPs during the Identity Proofing Process, then this message will also include an inline attachment using the <code>examiner_assertions</code> attribute.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/evidence_exchange/1.0/evidence_response\",\n  \"@id\": \"1517207d-f50e-4ed5-a389-6a4986d718e6\",\n  \"~thread\": { \"thid\": \"6a4986dd-f50e-4ed5-a389-718e61517207\" },\n  \"for\": \"did:peer:1-F1220479cbc07c3f991725836a3aa2a581ca2029198aa420b9d99bc0e131d9f3e2cbe\",\n  \"as_of_time\": \"2019-07-23 18:05:06.123Z\",\n  \"credentials\": [\n    { \"@id\": \"cred-001\",\n      \"evidence\": [\n        {\"evidence_type\": \"Address\", \"evidence_ref\": [\"#kycdoc1\", \"#kycdoc4\"]},\n        {\"evidence_type\": \"Identity\", \"evidence_ref\": [\"#kycdoc2\"]},\n        {\"evidence_type\": \"Photo\", \"evidence_ref\": null}\n      ]\n    },\n    { \"@id\": \"cred-002\",\n      \"evidence\": [\n        {\"evidence_type\": \"Address\", \"evidence_ref\": [\"#kycdoc1\",\"#kycdoc3\"]},\n        {\"evidence_type\": \"Identity\", \"evidence_ref\": [\"#kycdoc3\"]},\n        {\"evidence_type\": \"Photo\", \"evidence_ref\": [\"#kycdoc1\"]}\n      ]\n    }\n  ],\n  \"examiner_assertions\": [ ... ],\n  \"~attach\": [ ... ]\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>credentials</code>: A list of credential IDs each containing an array of evidence.</li> <li><code>@id</code>: Corresponds to each ID associated with the list of credential IDs supplied by the Holder in the <code>evidence_request</code> message.</li> <li><code>evidence</code>: An array of evidence attachments associated with each type of evidence the Issuer has established for a specific credential.<ul> <li><code>evidence_type</code>: Stipulates the type of KYC Document proofing (Address, Identity or Photo) that the Issuer performed for a set of attachments.</li> <li><code>evidence_ref</code>: An array of attachment reference IDs pertaining to the list of evidence used by the Issuer to establish confidence about the Holder.</li> </ul> </li> <li><code>examiner_assertions</code>: An array of inline attachments for Digital Assertions.</li> <li><code>~attach</code>: An array of appended attachments for Original Documents either by-value or by-reference.</li> </ul>"},{"location":"features/0116-evidence-exchange/#examiner-assertions","title":"Examiner Assertions","text":"<p><pre><code>{\n  \"examiner_assertions\": [\n    {\n      \"@id\": \"kycdoc4\",\n      \"approval_timestamp\": \"2017-06-21 09:04:088\",\n      \"description\": \"driver's license\",\n      \"vetting_process\": {\n        \"method\": \"remote\",\n        \"technology\": \"api\"\n      },\n      \"ipsp_did\": \"~3d5nh7900fn4\",\n      \"ipsp_claim\": &lt;base64url(file)&gt;,\n      \"ipsp_claim_sig\": \"3vvvb68b53d5nh7900fn499040cd9e89fg3kkh0f099c0021233728cf67945faf\",\n      \"examinerSignature\": \"f67945faf9e89fg3kkh3vvvb68b53d5nh7900fn499040cd3728c0f099c002123\"\n    }\n  ]\n}\n</code></pre> Description of attributes:</p> <ul> <li><code>approval_timestamp</code>: Date and time associated with when the Issuer approved assertion from IPSP.</li> <li><code>description</code>: A human readable description of the type of document.</li> <li><code>vetting_process</code>: Meta-data that allows the Issuer to specify the type of due diligence performed on the vetted evidence.</li> <li><code>methods</code>: One of two possible identity proofing methods: in-person, or remote.</li> <li><code>technology</code>: Free form description of the approach used to perform the validation. Possible values include but are not limited to: barcode, api, human-visual.</li> <li><code>ipsp_did</code>: The DID of the Identity Proofing Service Provider (IPSP).</li> <li><code>ipsp_claim</code>: Base64 encoding of the evidence that the IPSP used to perform its verification service.</li> <li><code>ipsp_claim_sig</code>: Required RSA/SHA-256 Signature of the IPSP's claim. This is required for downstream processing by the Verifier so that the Holder can demonstrate that the IPSP actually performed a verification service.</li> <li><code>examinerSignature</code>: Required RSA/SHA-256 Signature of the evidence. This is required for downstream processing by the Verifier so that the Holder can demonstrate that the Issuer attests to assessment (assertion) made by the IPSP.</li> </ul>"},{"location":"features/0116-evidence-exchange/#by-value-attachments","title":"By-value Attachments","text":"<pre><code>{\n  \"~attach\": [\n    {\n      \"@id\": \"kycdoc1\",\n      \"mime-type\": \"image/png\",\n      \"filename\": \"nys_dl.png\",\n      \"lastmod_time\": \"2017-06-21 09:04:088\",\n      \"description\": \"driver's license\",\n      \"vetting_process\": {\n        \"method\": \"in-person\",\n        \"technology\": \"barcode\"\n      },\n      \"data\": {\n        \"base64\": &lt;base64url(file)&gt;\n      },\n      \"examinerSignature\": \"f67945faf9e89fg3kkh3vvvb68b53d5nh7900fn499040cd3728c0f099c002123\"\n    },\n    {\n      \"@id\": \"kycdoc2\",\n      \"mime-type\": \"application/pdf\",\n      \"filename\": \"con_ed.pdf\",\n      \"lastmod_time\": \"2017-11-18 10:44:068\",\n      \"description\": \"ACME Electric Utility Bill\",\n      \"vetting_process\": {\n        \"method\": \"in-person\",\n        \"technology\": \"human-visual\"\n      },\n      \"data\": {\n        \"base64\": &lt;base64url(file)&gt;\n      },\n      \"examinerSignature\": \"945faf9e8999040cd3728c0f099c002123f67fg3kkh3vvvb68b53d5nh7900fn4\"\n    },\n    {\n      \"@id\": \"kycdoc3\",\n      \"mime-type\": \"image/jpg\",\n      \"filename\": \"nysccp.jpg\",\n      \"lastmod_time\": \"2015-03-19 14:35:062\",\n      \"description\": \"State Concealed Carry Permit\",\n      \"vetting_process\": {\n        \"method\": \"in-person\",\n        \"technology\": \"barcode\"\n      },\n      \"data\": {\n        \"sha256\": \"1d9eb668b53d99c002123f1ffa4db0cd3728c0f0945faf525c5ee4a2d4289904\",\n        \"base64\": &lt;base64url(file)&gt;\n      },\n      \"examinerSignature\": \"5nh7900fn499040cd3728c0f0945faf9e89kkh3vvvb68b53d99c002123f67fg3\"\n    }\n  ]\n}\n</code></pre> <p>This message adheres to the attribute content formats outlined in the Aries Attachments RFC  with the following additions:</p> <ul> <li><code>mime-type</code>: Describes the MIME type of the attached content. Optional but recommended.</li> <li><code>filename</code>: A hint about the name that might be used if this attachment is persisted as a file. It is not required, and need not be unique. If this field is present and mime-type is not, the extension on the filename may be used to infer a MIME type.</li> <li><code>lastmod_time</code>: A hint about when the content in this attachment was last modified.</li> <li><code>description</code>: A human readable description of the type of document.</li> <li><code>vetting_process</code>: See Examiner Assertions</li> <li><code>sha256</code>: Optional hash of the content. Can be useful as an integrity check by Holder.</li> <li><code>examinerSignature</code>: Required RSA/SHA-256 Signature of the document. This is required for downstream processing by the Verifier so that the Holder can demonstrate that the Issuer was the attesting source of the Original Document.</li> </ul>"},{"location":"features/0116-evidence-exchange/#by-reference-attachments","title":"By-reference Attachments","text":"<pre><code>{\n  \"~attach\": [\n    {\n      \"@id\": \"kycdoc1\",\n      \"mime-type\": \"image/png\",\n      \"filename\": \"nys_dl.png\",\n      \"lastmod_time\": \"2017-06-21 09:04:088\",\n      \"description\": \"driver's license\",\n      \"vetting_process\": {\n        \"method\": \"in-person\",\n        \"technology\": \"barcode\"\n      },\n      \"data\": {\n        \"sha256\": \"1d9eb668b53d99c002123f1ffa4db0cd3728c0f0945faf525c5ee4a2d4289904\",\n        \"links\": [\n          { \"url\": \"https://www.dropbox.com/s/r8rjizriaHw8T79hlidyAfe4DbWFcJYocef5/myDL.png\",\n            \"accesscode\": \"some_secret\"\n          }\n        ]\n      },\n      \"examinerSignature\": \"f67945faf9e89fg3kkh3vvvb68b53d5nh7900fn499040cd3728c0f099c002123\"\n    },\n    {\n      \"@id\": \"kycdoc2\",\n      \"mime-type\": \"application/pdf\",\n      \"filename\": \"con_ed.pdf\",\n      \"lastmod_time\": \"2017-11-18 10:44:068\",\n      \"description\": \"ACME Electric Utility Bill\",\n      \"vetting_process\": {\n        \"method\": \"remote\",\n        \"technology\": \"api\"\n      },\n      \"data\": {\n        \"sha256\": \"1d4db525c5ee4a2d42899040cd3728c0f0945faf9eb668b53d99c002123f1ffa\",\n        \"links\": [\n          { \"url\": \"https://mySSIAgent.com/w8T7AfkeyJYo4DbWFcmyocef5eyH\",\n            \"accesscode\": \"some_secret\"\n          }\n        ]\n      },\n      \"examinerSignature\": \"945faf9e8999040cd3728c0f099c002123f67fg3kkh3vvvb68b53d5nh7900fn4\"\n    },\n    {\n      \"@id\": \"kycdoc3\",\n      \"mime-type\": \"image/jpg\",\n      \"filename\": \"nysccp.jpg\",\n      \"lastmod_time\": \"2015-03-19 14:35:062\",\n      \"description\": \"State Concealed Carry Permit\",\n      \"vetting_process\": {\n        \"method\": \"in-person\",\n        \"technology\": \"barcode\"\n      },\n      \"data\": {\n        \"sha256\": \"b53d99c002123f1ffa2d42899040cd3728c0f0945fa1d4db525c5ee4af9eb668\",\n        \"links\": [\n          { \"url\": \"https://myssiAgent.com/mykeyoyHw8T7Afe4DbWFcJYocef5\",\n            \"accesscode\": null\n          }\n        ]\n      },\n      \"examinerSignature\": \"5nh7900fn499040cd3728c0f0945faf9e89kkh3vvvb68b53d99c002123f67fg3\"\n    }\n  ]\n}\n</code></pre> <p>This message adheres to the attribute content formats outlined in the Aries Attachments RFC  and builds on the By Value Attachments with the following additions:</p> <ul> <li><code>links</code>: A list of zero or more locations at which the content may be fetched.</li> <li><code>url</code>: Link to the external document.</li> <li><code>accesscode</code>: If required, the passcode need to authenticate access to the url.</li> </ul> <p>Upon completion of the Evidence Request and Response exchange, the Holder's Agent is now able to present any Verifier that has accepted a specific Issuer credential with the supporting evidence from the Issuer. This evidence, depending on the Holder's preferences may be direct or via a link to an external resource. For example, regardless of the delivery method used between the Issuer and Holder, the Holder's Agent may decide to fetch all documents and store them itself and then provide Verifiers with by-reference access upon request.</p>"},{"location":"features/0116-evidence-exchange/#evidence-access-request-message","title":"Evidence Access Request Message","text":"<p>Upon the successful processing of a credential proof presentation message, a Verifier may desire to request supporting evidence for the processed credential. This <code>evidence_access_request</code> message is built by the Verifier and sent to the  Holder's agent. Similar to the <code>request_evidence</code> message, the Verifier may use this message to get an update for new and existing credentials associated with the Holder. The intent of this message is for the Verifier to establish trust by obtaining a copy of the available evidence and performing the necessary content validation.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/evidence_exchange/1.0/evidence_access_request\",\n  \"@id\": \"7c3f991836-4ed5-f50e-7207-718e6151a389\",\n  \"for\": \"did:peer:1-F1220479cbc07c3f991725836a3aa2a581ca2029198aa420b9d99bc0e131d9f3e2cbe\",\n  \"as_of_time\": \"2019-07-23 18:05:06.123Z\",\n  \"credentials\": [\n      { \"@id\": \"cred-001\", \"issuerDID\": \"~BzCbsNYhMrjHiqZD\" },\n      { \"@id\": \"cred-002\", \"issuerDID\": \"~BzCbsNYhMrjHiqZD\" }\n  ]\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>credentials</code>: A list of credential IDs that the Verifier desires proof of evidence.</li> <li><code>@id</code>: Credential ID derived from a validated credential exchange (proof presentment).</li> <li><code>issuerDID</code>: The public DID of the Issuer that issued the credential represented by the associated ID. This DID is derived from the credential validation process.</li> </ul> <p></p> <p>This protocol is intended to be flexible and applicable to a variety of use cases. While our discussion has circulated around the use of the protocol as follow-up to the processing of a credential proof presentment flow, the fact is that the protocol can be used at any point after a Pair-wise DID Exchange has been successfully established and is therefore in the complete state as defined by the DID Exchange Protocol. An <code>IssuerDID</code> (or DID of the an entity that is one of the two parties in a private pair-wise relationship) is assumed to be known under all possible conditions once the relationship is in the complete state.</p>"},{"location":"features/0116-evidence-exchange/#evidence-access-response-message","title":"Evidence Access Response Message","text":"<p>This message is required for a Holder Agent in response to an <code>evidence_access_request</code> message. The format of the <code>~attach</code> attribute will be determined by the storage management preferences of the Holder's Agent. As such the Holder can respond by-value or by-reference. To build the response, the Holder will validate that the supplied Issuer DID corresponds to the credential represented by the supplied ID. If the Issuer relied on one or more IPSPs during the Identity Proofing Process, then this message will also include an inline attachment using the <code>examiner_assertions</code> attribute. Upon successful processing of a <code>evidence_access_response</code> message, the Verifier will store evidence details in its system of record.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/evidence_exchange/1.0/evidence_access_response\",\n  \"@id\": \"1517207d-f50e-4ed5-a389-6a4986d718e6\",\n  \"~thread\": { \"thid\": \"7c3f991836-4ed5-f50e-7207-718e6151a389\" },\n  \"for\": \"did:peer:1-F1220479cbc07c3f991725836a3aa2a581ca2029198aa420b9d99bc0e131d9f3e2cbe\",\n  \"as_of_time\": \"2019-07-23 18:05:06.123Z\",\n  \"credentials\": [\n    { \"@id\": \"cred-001\",\n      \"evidence\": [\n        {\"evidence_type\": \"Address\", \"evidence_ref\": [\"#kycdoc1\", \"#kycdoc4\"]},\n        {\"evidence_type\": \"Identity\", \"evidence_ref\": [\"#kycdoc2\"]},\n        {\"evidence_type\": \"Photo\", \"evidence_ref\": null}\n      ]\n    },\n    { \"@id\": \"cred-002\",\n      \"evidence\": [\n        {\"evidence_type\": \"Address\", \"evidence_ref\": [\"#kycdoc1\",\"#kycdoc3\"]},\n        {\"evidence_type\": \"Identity\", \"evidence_ref\": [\"#kycdoc3\"]},\n        {\"evidence_type\": \"Photo\", \"evidence_ref\": [\"#kycdoc1\"]}\n      ]\n    }\n  ],\n  \"examiner_assertions\": [ ... ],\n  \"~attach\": [ ...\n  ]\n}\n</code></pre> <p>This message adheres to the attribute content formats outlined in the Aries Attachments RFC  and leverages the same Evidence Response Message attribute descriptions.</p>"},{"location":"features/0116-evidence-exchange/#reference","title":"Reference","text":"<ul> <li>Centralized Shared-KYC Trends</li> <li>R3 KYC Registry Dutch Banks</li> <li>Canadian Banks</li> <li>Deutsche Bank and HSBC Shared-KYC POC</li> <li>Sample KYC Documentation requirements</li> <li>NYS Document Guide for Identification Services</li> <li>TSA Travelers Guide</li> <li>USA Identity Documents</li> <li>Aadhaar KYC Concepts</li> </ul>"},{"location":"features/0116-evidence-exchange/#drawbacks","title":"Drawbacks","text":"<p>This protocol does not vary much from a generic document exchange protocol. It can be argued that a special KYC Document exchange protocol is not needed. However, given the emphasis placed on KYC compliance during the early days of DIDComm adoption, we want to make sure that any special cases are addressed upfront so that we avoid adoption derailment factors.</p>"},{"location":"features/0116-evidence-exchange/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>As noted in the references section, there are a number of trending KYC Document proofing options that are being considered. Many leverage the notion of a centralized blockchain ledger for sharing documents. This effectively places control outside of the Holder and enables the sharing of documents in a B2B manner. Such approaches do not capitalize on the advantages of Pair-wise Peer DIDs.</p>"},{"location":"features/0116-evidence-exchange/#prior-art","title":"Prior art","text":"<p>This protocol builds on the foundational capabilities of DIDComm messages, most notable being the attachment decorator within DIDComm.</p>"},{"location":"features/0116-evidence-exchange/#unresolved-questions","title":"Unresolved questions","text":"<ol> <li>Should this be a separate protocol or an update to issuer-credential?</li> <li>What is the best way to handle access control for by-reference attachments?</li> <li>Are there best practices to be considered for when/why/how a Holder's Agent should store and manage attachments?</li> <li>Can this protocol help bootstrap a prototype for a Digital Notary and thereby demonstrate to the broader ecosystem the unnecessary attention being placed on alternative domain specific credential solutions like ISO-18013-5(mDL)?</li> </ol>"},{"location":"features/0116-evidence-exchange/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/","title":"Decentralized Digital Notary","text":""},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#preface","title":"Preface","text":"<p>The intent of this document is to describe the concepts of a Decentralized Digital Notary with respect to the bootstrapping of the decentralized identity ecosystem and to demonstrate using example user stories<sup>1</sup> the applicability of the Evidence Exchange Protocol.  </p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#overview","title":"Overview","text":""},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#problem-statement","title":"Problem Statement","text":"<p>How do we bootstrap the digital credential ecosystem when many of the issuing institutions responsible for foundational credentials (i.e.: brith certificate, drivers license, etc) tend to be laggards<sup>2</sup> when it comes to the adoption of emerging technology? What if we did not need to rely on these issuing institutions and instead leveraged the attestations of trusted third parties?</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#concept","title":"Concept","text":"<p>During the identity verification process, an entity may require access to the genesis documents from the Issuers of Origination before issuing credentials. We see such requirements in some of the routine identity instrument interactions of our daily lives such as obtaining a Driver's License or opening a Bank Account.</p> <p></p> <p>We assume that government agencies such and the DMV (drivers license) and Vital Records (brith certificate) will not be early adopters of digital credentials yet their associated Tier 1 Proofs are critical to the the creation of a network effect for the digital credential ecosystem.</p> <p>We therefore need a forcing function that will disrupt behavior. Image a trusted business entity, a Decentralized Digital Notary (DDN), that would take the responsibility of vouching for the existence of Original Documents (or Digital Assertions) and have the certitude to issue verifiable credentials attesting to personal data claims made by the Issuer of Origination.</p> <p></p> <p>Today (blue shaded activity), an individual receives Original Documents from issuing institutions and presents these as evidence to each Verifier. Moving forward (beige shaded activity), as a wide range of businesses consider acting as DDNs, our reliance on Issuers of Origination to be the on-ramps for an individuals digital identity experience diminishes. Overtime, our dependency on the proactive nature of such institutions becomes mute. Furthermore, the more successful DDNs become the more reactionary the laggards will need to be to protect their value in the ecosystem.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#applicable-businesses","title":"Applicable Businesses","text":"<p>Any entity that has the breath and reach to connect with consumers at scale would be an ideal candidate for the role of a DDN. Some examples include:</p> <ul> <li>Retail Banks</li> <li>Credit Unions</li> <li>Regional Rural Banks (India)</li> <li>Mobile Field Agents</li> <li>Background Screening Service Providers</li> </ul> <p>The monetization opportunities for such businesses will also vary. The linkages between proof-of-identity and proof-of-value can be achieved in several manners:</p> <ol> <li>Individual pays for issuance of certificates</li> <li>Verifier pays the underwriter with a payment instrument (i.e.: fiat or cryptocurrency). The payment is for the service of underwriting the screening of an individual so that the Verifier does not have to do it.\u2028</li> </ol>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#stories","title":"Stories","text":"<p>Presented herein are a series of user stories that incorporate the concepts of a DDN and the ability of a verifier to gain access to Issuer vetted Identity Evidence using the Evidence Exchange Protocol.</p> <p>The stories focus on the daily lifecycle activities of a two individuals who needs to open a brokerage account and/or update a Life Insurance Policy.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#persona","title":"Persona","text":"Name Role Eric An individual that desires to open a brokerage account. Stacy An individual that desires to open a brokerage account and also apply a Life Insurance Policy. Retail Bank DDN (Issuer) Thomas Notary at the Retail Bank familiar with the DDN Process. Brokerage Firm Verifier Dropbox Document Management Service iCertitude A hypothetical IPSP that provides a mobile convenient identity verification service that is fast, trusted and  reliable. Financial Cooperative A small local financial institution that is owned and operated by its members. It has positioned itself as a DDN (Issuer) by OEMing the iCertitude platform."},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#identity-proofing-examination-process","title":"Identity Proofing (Examination) Process","text":""},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#financial-cooperative-ddn-awareness","title":"Financial Cooperative (DDN Awareness)","text":"<p>Eric is a member of his neighborhood Financial Cooperative. He received an email notification that as a new member benefit, the bank is now offering members with the ability to begin their digital identity journey. Eric is given access to literature describing the extend to the bank's offering and a video of the process for how to get started. Eric watches the video, reads the online material and decides to take advantage of the banks offer.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#financial-cooperative-3rd-party-remote-vetting-process","title":"Financial Cooperative (3<sup>rd</sup> Party Remote Vetting Process)","text":"<p>Following his banks instructions, Eric downloads, installs and configures a Wallet App on his smartphone from the list of apps recommended by the bank. He also downloads the bank's iCertitude app. He uses the iCertitude Mobile app to step through a series of ID Proofing activities that allow the bank to establish a NIST IAL3 assurance rating. These steps include the scanning or some biometrics as well as his plastic drivers license. Upon completion of these activities, which are all performed using his smartphone without any human interactions with the bank, Eric receives a invite in his Wallet App to accept a new verifiable credential which is referred to as a Basic Assurance Credential. Eric opens the Wallet App, accepts the new credential and inspects it.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#retail-bank-ddn-awareness","title":"Retail Bank (DDN Awareness)","text":"<p>Stacy is a member of her neighborhood Retail Bank. She received an email notification that as a new member benefit, the bank is now offering members with the ability to begin their digital identity journey. Stacey is given access to literature describing the extend to the bank's offering and a video of the process for how to get started. Stacey watches the video, reads the online material and decides to make an appointment with her local bank notary and fill out the preliminary online forms.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#retail-bank-paper-vetting-process","title":"Retail Bank (Paper Vetting Process)","text":"<p>Stacey attends her appointment with Thomas. She came prepared to request digital credentials for the following Official Documents: SSN, Birth Certificate, proof of employment (paystub) and proof of address (utility bill). Thomas explains to Stacey that given the types of KYC Documents she desires to be digitally notarized, bank policy is to issue a single digital credential that attests to all the personal data she is prepared to present. The bank refers to this verifiable credential as the Basic KYC Credential and they use a common schema that is used by many DDNs in the Sovrin ecosystem.</p> <p>Note: This story depicts one approach. Clearly, the bank's policy could be to have a schema and credential for each Original Document.  </p> <p>Stacy supplied Thomas with the paper based credentials for each of the aforementioned documents. Thomas scans each document and performs the necessary vetting process according to business policies. Thomas explains that while the bank can issue Stacey her new digital credential for a fee of $10 USD renewable annually, access to her scanned documents would only be possible if she opts-in to the digital document management service on her online banking account. Through this support she is able to provide digital access to the scanned copies of her paper credentials that were vetted by the bank. Stacey agrees to opt-in.</p> <p>While Stacey is waiting for her documents to be digitally notarized, she downloads, installs and configures a Wallet App on her smartphone from the list of apps recommended by the bank. Upon completion of the vetting process, Thomas returns all Original Documents back to Stacey and explains to her where she can now request the delivery of her new digital credential in her online account. Stacey leaves the bank with her first digital credential on her device.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#retail-bank-hybrid-vetting-process","title":"Retail Bank (Hybrid Vetting Process)","text":"<p>During Stacey's preparation activity when she was filling out the  preliminary online forms before her appointment with Thomas, she remembered that she had scanned her recent proof of employment (paystub) and proof of address (utility bill) at home and stored them on her Dropbox account. She decides to use the section of the form to grant the bank access (url and password) to these files. When she attends her appointment with Thomas, the meeting is altered only by the fact that she has limited her requirement of physical document presentment. However, Thomas does explain to her that bank policy is that the bank does not use remote links in their digital document management service. Instead, the bank uses the Dropbox link to obtain a copy, perform the vetting process and then store the copy in-house and allow Stacey to gain access to a link for the document stored at the bank.  </p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#credential-management","title":"Credential Management","text":"<p>Later that evening, Stacey decides to explore her new Digital Credential features within her online bank account. She sees that she has the ability to request access to the vetted resources the bank has used to vouch for her digital identity. She opens her Wallet App and sends a <code>evidence_request</code> message to the bank. Within a few seconds she receives and processes the bank's <code>evidence_response</code> message. Her Wallet App allows her to view the evidence available to her:</p> Issuer Credential Evidence Type Original Document Retail Bank Basic KYC Credential Address Utility Bill Retail Bank Basic KYC Credential Address Employment PayStub Retail Bank Basic KYC Credential Identity SSN Retail Bank Basic KYC Credential Identity Birth Certificate Retail Bank Basic KYC Credential Photo Bank Member Photo <p>Recalling his review of the bank's new digital identity journey benefits, Eric decides to use his Wallet App to request access to the vetted resources the bank used to vouch for his new Basic Assurance Credential. He uses the Wallet App to initiate a <code>evidence_request</code> and <code>evidence_response</code> message flow.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#verification-process","title":"Verification Process","text":""},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#brokerage-account-digital-assertion-evidence","title":"Brokerage Account (Digital Assertion Evidence)","text":"<p>Eric decides to open a new brokerage account with a local Brokerage Firm. He opens the firms account registration page using his laptop web browser. The firm allows him to establish a new account and obtain a brokerage member credential if he can provide digitally verifiable proof of identity and address. Eric clicks to begin the onboarding process. He scans a QRCode using his Wallet App and accepts a connection request from the firm. He then receives a proof request from the firm and his Wallet App parsing the request and suggests he can respond using attributes from his Basic Assurance Credential. He responds to the proof request. Upon verification of his proof response, the firm sends Eric an offer for a Brokerage Membership Credential which he accepts. The firm also sends him an <code>evidence_access_request</code> and an explanation that the firm's policy for regulatory reasons is to obtain access to proof that the proper due-diligence was performed for Address, Identity and Photo. Eric uses his Wallet App to instruct his Cloud Agent to send an <code>evidence_access_response</code>. Upon processing of Eric's response, the firm establishes a Trust Score based on their policy for evidence based only on Digital Assertions and Remote Proofing processes.  </p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#brokerage-account-document-evidence","title":"Brokerage Account (Document Evidence)","text":"<p>Stacey decides she will open a new brokerage account with a local Brokerage Firm. She opens the firms account registration page using her laptop web browser. The firm allows her to establish a new account and obtain a brokerage member credential if she can provide digitally verifiable proof of identity, address and employment. Stacey clicks to begin the onboarding process. She scans a QRCode using her Wallet App and accepts a connection request from the firm. Using her Wallet App she responds to the proof request using digital credentials from her employer and her Retail Bank. Upon verification of her proof response, the firm sends Stacey an offer for a Brokerage Membership Credential which she accepts. The firm also sends her an <code>evidence_access_request</code> and an explanation that the firm's policy for regulatory reasons is to obtain access to the proof that the proper due-diligence was performed for Address, Identity, Photo and Employment. Stacey uses her Wallet App to instruct her Cloud Agent to send an <code>evidence_access_response</code>.  Upon processing of Stacey's response, the firm establishes a Trust Score based on their policy for evidence based on Original Documents and In-person Proofing processes.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#life-insurance-policy-didcomm-doc-sharing","title":"Life Insurance Policy (DIDComm Doc Sharing)","text":"<p>Stacey receives notification from her Insurance Company that they require an update to her life insurance policy account. The firm has undertaken a digital transformation strategy that impacts her 15yr old account. She has been given access to a new online portal and the choices on how to supply digital copies of her SSN and Birth Certificate. Stacey is too busy to take time to visit the Insurance Company to provide Original Documents for their vetting and digitization. She decides to submit her notarized digital copies.  She opens the companies account portal page using her laptop web browser. Stacey registers, signs in and scans a QRCode using her Wallet App. She accepts a connection request from the firm. She then responds to an <code>evidence_access_request</code> for proof of that KYC due-diligence was performed for Identity and Photo. Stacey uses her Wallet App to instruct her Cloud Agent to send an <code>evidence_access_response</code>.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#commentary","title":"Commentary","text":"<ol> <li>The concepts of a digital notary can be applied today in application domains such as (but not limited to) indirect auto lending and title management (auto, recreational vehicle, etc).</li> <li>Since 2015, AAMVA in conjunction with the ISO JTC1/SC27/WG10 18013-5 mDL Team has been working on a single credential solution for cross jurisdictional use amongst DMVs. This public sector activity is a key source of IAM industry motivation for alternative solutions to Credential Lifecycle Management. Government agencies will eventually need to address discussions around technical debit investments and defacto open source standards.</li> </ol>"},{"location":"features/0116-evidence-exchange/eep_glossary/","title":"Evidence Exchange Protocol Glossary","text":"<p>The following terms are either derived from terminology found in the NIST 800-63A Digital Identity Guidelines or introduced to help reinforce protocol concepts and associated use cases.</p> Term Definition Credential Service Provider (CSP) A trusted entity that issues verifiable credentials credentials. Either an Issuer of Origination for an Original Document or an Issuer of a Derived Credential. A DDN is an example of a CSP that issues Derived Credential. Decentralized Digital Notary (DDN) A trusted third party that enables digital interactions between Holders and Verifiers. As an issuer of digitally verifiable credentials, it creates permanent evidence that an Original Document existed in a certain form at a particular point in time. This role will be especially important to address scalability and the bootstrapping of the decentralized identity ecosystem since many Issuers of Origination may be laggards. DDN Insurer An entity (party) in an insurance contract that underwrites insurance risks associated with the activities of a DDN. This includes a willingness to pay compensation for any negligence on the part of the DDN for failure to perform the necessary due-diligence associated with the examination and vetting of Original Documents. Derived Credential An issued verifiable credential based on an identity proofing process over Original Documents or other Derived Credentials. Digital Assertion A non-physical (digital) form of evidence. Often in the form of a Digital Signature. A CSP may leverage the services of an IPSP and may then require the IPSP to digitally sign the content that is the subject of the assertion. Original Document Any issued artifact that satisfies the Original-Document Rule in accordance with principle of evidence law. The original artifact may be in writing or a mechanical, electronic form of publication. Such a document may also be referred to as a Foundational Document. Identity Evidence Information or documentation provided by the Holder to support the issuance of an Original Document. Identity evidence may be physical (e.g. a driver license) or Digital Assertion Identity Instrument Digital or physical, paper or plastic renderings of some subset of our personal data as defined by the providers of the instruments. The traditional physical object is an identification card. Many physical identity instruments contain public and encoded information about an entity. The encoded information, which is often stored using machine readable technologies like magnetic strips or barcodes, represents another rendering format of an individual\u2019s personal data. Digital identity instruments, pertain to an individual\u2019s personal data in a form that can be processed by a software program. Identity Proofing The process by which a CSP collects, validates, and verifies Identity Evidence. This process yields the attestations (claims of confidence) by which a CSP is then able to use to issue a Verifiable Credential. The sole objective of this process is to ensure the Holder of Identity Evidence is who they claim to be with a stated level of certitude. Identity Proofing Inquiry The objectives of an identity verification exercise. Some inquiries are focused topics such as address verification while others may be on achievement. Identity Proofing Service Provider (IPSP) A remote 3<sup>rd</sup> party service provider that carries out one or more aspects of an Identity Proofing process. Issuer of Origination The entity (business, organization, individual or government) that is the original publisher of an Original Document. Mobile Field Agents Location-based service providers that allow agencies to bring their services to remote (rural) customers. Tier 1 Proofs A category of foundational credentials (Original Documents) that are often required to prove identity and address during KYC or onboarding processes. Trust Framework Certification Authority An entity that adheres to a governance framework for a specific ecosystem and is responsible for overseeing and auditing the Level of Assurance a DDN (Relying Party) has within the ecosystem. Verifiable Credential A digital credential that is compliant with the W3C Verifiable Credential Specification."},{"location":"features/0124-did-resolution-protocol/","title":"Aries RFC 0124: DID Resolution Protocol 0.9","text":"<ul> <li>Authors: Markus Sabadello, Luis G\u00f3mez Alonso</li> <li>Status: PROPOSED</li> <li>Since: 2019-07-13</li> <li>Status Note: Not implemented, but has been discussed as part of the Aries DID Resolution work.</li> <li>Start Date: 2019-07-08</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0124-did-resolution-protocol/#summary","title":"Summary","text":"<p>Describes a DIDComm request-response protocol that can send a request to a remote DID Resolver to resolve DIDs and dereference DID URLs.</p>"},{"location":"features/0124-did-resolution-protocol/#motivation","title":"Motivation","text":"<p>DID Resolution is an important feature of Aries. It is a prerequisite for the <code>unpack()</code> function in DIDComm, especially in Cross-Domain Messaging, since cryptographic keys must be discovered from DIDs in order to enable trusted communication between the agents associated with DIDs. DID Resolution is also required for other operations, e.g. for verifying credentials or for discovering DIDComm service endpoints.</p> <p>Ideally, DID Resolution should be implemented as a local API (TODO: link to other RFC?). In some cases however, the DID Resolution function may be provided by a remote service. This RFC describes a DIDComm request-response protocol for such a remote DID Resolver.</p>"},{"location":"features/0124-did-resolution-protocol/#tutorial","title":"Tutorial","text":"<p>DID Resolution is a function that returns a DID Document for a DID. This function can be accessed via \"local\" bindings (e.g. SDK calls, command line tools) or \"remote\" bindings (e.g. HTTP(S), DIDComm).</p> <p>A DID Resolver MAY invoke another DID Resolver in order to delegate (part of) the DID Resolution and DID URL Dereferencing algorithms. For example, a DID Resolver may be invoked via a \"local\" binding (such as an Aries library call), which in turn invokes another DID Resolver via a \"remote\" binding (such as HTTP(S) or DIDComm).</p> <p></p>"},{"location":"features/0124-did-resolution-protocol/#name-and-version","title":"Name and Version","text":"<p>This defines the <code>did_resolution</code> protocol, version 0.1, as identified by the following PIURI:</p> <pre><code>https://didcomm.org/did_resolution/0.1\n</code></pre>"},{"location":"features/0124-did-resolution-protocol/#key-concepts","title":"Key Concepts","text":"<p>DID Resolution is the process of obtaining a DID Document for a given DID. This is one of four required operations that can be performed on any DID (\"Read\"; the other ones being \"Create\", \"Update\", and \"Deactivate\"). The details of these operations differ depending on the DID method. Building on top of DID Resolution, DID URL Dereferencing is the process of obtaining a resource for a given DID URL. Software and/or hardware that is able to execute these processes is called a DID Resolver.</p> <ul> <li>DID Resolver: Software and/or hardware that is capable of DID Resolution and optionally DID URL Dereferencing for at least one DID method.</li> <li>DID Resolution: An algorithm that takes a DID plus additional options as input and produces a DID Document or a DID Resolution Result as output. This algorithm relies on the \"Read\" operation of the applicable DID method.</li> <li>DID URL Dereferencing: An algorithm that takes a DID URL plus additional options as input and produces a DID Document, a DID Resolution Result, or various other types of resources as output. This algorithm relies on DID Resolution.</li> <li>DID Method: A definition of how a specific DID scheme can be implemented on a specific distributed ledger or network, including the precise method(s) by which DIDs are resolved and deactivated and DID Documents are written and updated.</li> </ul>"},{"location":"features/0124-did-resolution-protocol/#roles","title":"Roles","text":"<p>There are two parties and two roles (one for each party) in the <code>did_resolution</code> protocol: A <code>requester</code> and <code>resolver</code>.</p> <p>The <code>requester</code> wishes to resolve DIDs or dereference DID URLs.</p> <p>The\u00a0<code>resolver</code> conforms with the DID Resolution Specification. It is capable of resolving DIDs for at least one DID method.</p>"},{"location":"features/0124-did-resolution-protocol/#states","title":"States","text":""},{"location":"features/0124-did-resolution-protocol/#states-for-requester-role","title":"States for <code>requester</code> role","text":"EVENTS: send <code>resolve</code> receive <code>resolve_result</code> STATES preparing-request transition to \"awaiting-response\" different interaction awaiting-response impossible transition to \"done\" done"},{"location":"features/0124-did-resolution-protocol/#states-for-resolver-role","title":"States for <code>resolver</code> role","text":"EVENTS: receive <code>resolve</code> send <code>resolve_result</code> STATES awaiting-request transition to \"resolving\" impossible resolving new interaction transition to \"done\" done"},{"location":"features/0124-did-resolution-protocol/#states-for-requester-role-in-a-failure-scenario","title":"States for <code>requester</code> role in a failure scenario","text":"EVENTS: send <code>resolve</code> receive <code>resolve_result</code> STATES preparing-request transition to \"awaiting-response\" different interaction awaiting-response impossible error reporting problem reported"},{"location":"features/0124-did-resolution-protocol/#states-for-resolver-role-in-a-failure-scenario","title":"States for <code>resolver</code> role in a failure scenario","text":"EVENTS: receive <code>resolve</code> send <code>resolve_result</code> STATES awaiting-request transition to \"resolving\" impossible resolving new interaction error reporting problem reported"},{"location":"features/0124-did-resolution-protocol/#messages","title":"Messages","text":"<p>All messages in this protocol are part of the \"did_resolution 0.1\" message family uniquely identified by this DID reference: <code>https://didcomm.org/did_resolution/0.1</code></p>"},{"location":"features/0124-did-resolution-protocol/#resolve-message","title":"<code>resolve</code> message","text":"<p>The protocol begins when the <code>requester</code> sends a <code>resolve</code> message to the <code>resolver</code>. It looks like this:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/did_resolution/0.1/resolve\",\n    \"@id\": \"xhqMoTXfqhvAgtYxUSfaxbSiqWke9t\",\n    \"did\": \"did:sov:WRfXPg8dantKVubE3HX8pw\",\n    \"input_options\": {\n        \"result_type\": \"did-document\",\n        \"no_cache\": false\n    }\n}\n</code></pre> <p><code>@id</code> is required here, as it establishes a message thread that makes it possible to connect a subsequent response to this request.</p> <p><code>did</code> is required.</p> <p><code>input_options</code> is optional.</p> <p>For further details on the <code>did</code> and <code>input_options</code> fields, see Resolving a DID in the DID Resolution Spec.</p>"},{"location":"features/0124-did-resolution-protocol/#resolve_result-message","title":"<code>resolve_result</code> message","text":"<p>The <code>resolve_result</code> is the only allowed direct response to the <code>resolve</code> message. It represents the result of the DID Resolution function and contains a DID Document.</p> <p>It looks like this:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/did_resolution/0.1/resolve_result\",\n    \"~thread\": { \"thid\": \"xhqMoTXfqhvAgtYxUSfaxbSiqWke9t\" },\n    \"did_document\": {\n        \"@context\": \"https://w3id.org/did/v0.11\",\n        \"id\": \"did:sov:WRfXPg8dantKVubE3HX8pw\",\n        \"service\": [{\n            \"type\": \"did-communication\",\n            \"serviceEndpoint\": \"https://agent.example.com/\"\n        }],\n        \"publicKey\": [{\n            \"id\": \"did:sov:WRfXPg8dantKVubE3HX8pw#key-1\",\n            \"type\": \"Ed25519VerificationKey2018\",\n            \"publicKeyBase58\": \"~P7F3BNs5VmQ6eVpwkNKJ5D\"\n        }],\n        \"authentication\": [\"did:sov:WRfXPg8dantKVubE3HX8pw#key-1\"]\n    }\n}\n</code></pre> <p>If the <code>input_options</code> field of the <code>resolve</code> message contains an entry <code>result_type</code> with value <code>resolution-result</code>, then the <code>resolve_result</code> message contains a more extensive DID Resolution Result, which includes a DID Document plus additional metadata:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/did_resolution/0.1/resolve_result\",\n    \"~thread\": { \"thid\": \"xhqMoTXfqhvAgtYxUSfaxbSiqWke9t\" },\n    \"did_document\": {\n        \"@context\": \"https://w3id.org/did/v0.11\",\n        \"id\": \"did:sov:WRfXPg8dantKVubE3HX8pw\",\n        \"service\": [{\n            \"type\": \"did-communication\",\n            \"serviceEndpoint\": \"https://agent.example.com/\"\n        }],\n        \"publicKey\": [{\n            \"id\": \"did:sov:WRfXPg8dantKVubE3HX8pw#key-1\",\n            \"type\": \"Ed25519VerificationKey2018\",\n            \"publicKeyBase58\": \"~P7F3BNs5VmQ6eVpwkNKJ5D\"\n        }],\n        \"authentication\": [\"did:sov:WRfXPg8dantKVubE3HX8pw#key-1\"]\n    },\n    \"resolver_metadata\": {\n        \"driverId\": \"did:sov\",\n        \"driver\": \"HttpDriver\",\n        \"retrieved\": \"2019-07-09T19:73:24Z\",\n        \"duration\": 1015\n    },\n    \"method_metadata\": {\n        \"nymResponse\": { ... },\n        \"attrResponse\": { ... }\n    }\n}\n</code></pre>"},{"location":"features/0124-did-resolution-protocol/#problem-report-failure-message","title":"<code>problem-report</code> failure message","text":"<p>The <code>resolve_result</code> will also report failure messages in case of impossibility to resolve a DID. It represents the problem report indicating that the resolver could not resolve the DID, and the reason of the failure. It looks like this:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/did_resolution/0.1/resolve_result\",\n    \"~thread\": { \"thid\": \"xhqMoTXfqhvAgtYxUSfaxbSiqWke9t\" },\n    \"explain_ltxt\": \"Could not resolve DID did:sov:WRfXPg8dantKVubE3HX8pw not found by resolver xxx\",\n        ...\n}\n</code></pre>"},{"location":"features/0124-did-resolution-protocol/#reference","title":"Reference","text":"<ul> <li>Aries DID Resolution</li> <li>DID Spec</li> <li>DID Resolution Spec</li> <li>Peer DID Method</li> <li>Universal Resolver</li> </ul>"},{"location":"features/0124-did-resolution-protocol/#messages_1","title":"Messages","text":"<p>In the future, additional messages <code>dereference</code> and <code>dereference_result</code> may be defined in addition to <code>resolve</code> and <code>resolve_result</code> (see Unresolved questions).</p>"},{"location":"features/0124-did-resolution-protocol/#message-catalog","title":"Message Catalog","text":"<p>Status and error codes will be inherited from the DID Resolution Spec.</p>"},{"location":"features/0124-did-resolution-protocol/#drawbacks","title":"Drawbacks","text":"<p>Using a remote DID Resolver should only be considered a fallback when a local DID Resolver cannot be used. Relying on a remote DID Resolver raises the question of who operates it, can you trust its responses, and can MITM and other attacks occur? There is essentially a chicken-and-egg problem insofar as the purpose of DID Resolution is to discover metadata needed for trustable interaction with an entity, but the precondition is that interation with a DID Resolver must itself be trustable.</p> <p>Furthermore, the use of remote DID Resolvers may introduce central bottlenecks and undermine important design principles such as decentralization.</p> <p>See Binding Architectures and w3c-ccg/did-resolution#28 for additional thoughts.</p> <p>The security and trust issues may outweigh the benefits. Defining and implementing this RFC may lead developers to underestimate or ignore these issues associated with remote DID Resolvers.</p>"},{"location":"features/0124-did-resolution-protocol/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Despite the drawbacks of remote DID Resolvers, in some situations they can be useful, for example to support DID methods that are hard to implement in local agents with limited hard- and software capabilities.</p> <p>A special case of remote DID Resolvers occurs in the case of the Peer DID Method, where each party of a relationship essentially acts as a remote DID Resolver for other parties, i.e. each party fulfills both the <code>requester</code> and <code>resolver</code> roles defined in this RFC.</p> <p>An alternative to the DIDComm binding defined by this RFC is an HTTP(S) binding, which is defined by the DID Resolution Spec.</p>"},{"location":"features/0124-did-resolution-protocol/#prior-art","title":"Prior art","text":"<p>Resolution and dereferencing of identifiers have always played a key role in digital identity infrastructure.</p> <ul> <li>Yadis was an early discovery protocol.</li> <li>XRI Resolution defined the XRDS format and  a protocol for discovering them from HTTP(S) URIs and XRIs. The XRDS format later evolved into XRD and JRD.</li> <li>WebFinger is an HTTP-based protocol for discovering JRD documents about identifiers.</li> </ul>"},{"location":"features/0124-did-resolution-protocol/#unresolved-questions","title":"Unresolved questions","text":"<p>This RFC inherits a long list of unresolved questions and issues that currently exist in the DID Resolution Spec.</p> <p>We need to decide whether the DID Resolution and DID URL Dereferencing functions (<code>resolve()</code> and <code>dereference()</code>) should be exposed as the same message type, or as two different message types (including two different responses).</p>"},{"location":"features/0124-did-resolution-protocol/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0160-connection-protocol/","title":"0160: Connection Protocol","text":"<ul> <li>Authors: Ryan West, Daniel Bluhm, Matthew Hailstone, Stephen Curran, Sam Curren</li> <li>Status: ADOPTED (But should move to deprecated)</li> <li>Since: 2019-08-06</li> <li>Status Note: This is the protocol with existing uses. It is expected that RFC 0023 DID Exchange will replace this protocol.</li> <li>Supersedes: HIPE 0031 - Connection Protocol</li> <li>Start Date: 2018-06-29</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"features/0160-connection-protocol/#summary","title":"Summary","text":"<p>This RFC describes the protocol to establish connections between agents. </p>"},{"location":"features/0160-connection-protocol/#motivation","title":"Motivation","text":"<p>Indy agent developers want to create agents that are able to establish connections with each other and exchange secure information over those connections. For this to happen there must be a clear connection protocol.</p>"},{"location":"features/0160-connection-protocol/#tutorial","title":"Tutorial","text":"<p>We will explain how a connection is established, with the roles, states, and messages required.</p>"},{"location":"features/0160-connection-protocol/#roles","title":"Roles","text":"<p>Connection uses two roles: inviter and invitee.</p> <p>The inviter is the party that initiates the protocol with an <code>invitation</code> message. This party must already have an agent and be capable of creating DIDs and endpoints at which they are prepared to interact. It is desirable but not strictly required that inviters have the ability to help the invitee with the process and/or costs associated with acquiring an agent capable of participating in the ecosystem. For example, inviters may often be sponsoring institutions. The inviter sends a <code>connection-response</code> message at the end of the share phase.</p> <p>The invitee has less preconditions; the only requirement is that this party be capable of receiving invitations over traditional communication channels of some type, and acting on it in a way that leads to successful interaction. The invitee sends a <code>connection-request</code> message at the beginning of the share phase.</p> <p>In cases where both parties already possess SSI capabilities, deciding who plays the role of inviter and invitee might be a casual matter of whose phone is handier.</p>"},{"location":"features/0160-connection-protocol/#states","title":"States","text":""},{"location":"features/0160-connection-protocol/#null","title":"null","text":"<p>No connection exists or is in progress</p>"},{"location":"features/0160-connection-protocol/#invited","title":"invited","text":"<p>The invitation has been shared with the intended invitee(s), and they have not yet sent a connection_request.</p>"},{"location":"features/0160-connection-protocol/#requested","title":"requested","text":"<p>A connection_request has been sent by the invitee to the inviter based on the information in the invitation. </p>"},{"location":"features/0160-connection-protocol/#responded","title":"responded","text":"<p>A connection_response has been sent by the inviter to the invitee based on the information in the connection_request.</p>"},{"location":"features/0160-connection-protocol/#complete","title":"complete","text":"<p>The connection is valid and ready for use.</p> <p></p>"},{"location":"features/0160-connection-protocol/#errors","title":"Errors","text":"<p>There are no errors in this protocol during the invitation phase. For the request and response, there are two error messages possible for each phase: one for an active rejection and one for an unknown error. These errors are sent using a problem_report message type specific to the connection message family. The following list details <code>problem-code</code>s that may be sent:</p> <p>request_not_accepted - The error indicates that the request has been rejected for a reason listed in the error_report. Typical reasons include not accepting the method of the provided DID, unknown endpoint protocols, etc. The request can be resent after the appropriate corrections have been made.</p> <p>request_processing_error - This error is sent when the inviter was processing the request with the intent to accept the request, but some processing error occurred. This error indicates that the request should be resent as-is.</p> <p>response_not_accepted - The error indicates that the response has been rejected for a reason listed in the error_report. Typical reasons include not accepting the method of the provided DID, unknown endpoint protocols, invalid signature, etc. The response can be resent after the appropriate corrections have been made.</p> <p>response_processing_error - This error is sent when the invitee was processing the response with the intent to accept the response, but some processing error occurred. This error indicates that the response should be resent as-is.</p> <p>No errors are sent in timeout situations. If the inviter or invitee wishes to retract the messages they sent, they record so locally and return a <code>request_not_accepted</code> or <code>response_not_accepted</code> error when the other party sends a request or response .</p>"},{"location":"features/0160-connection-protocol/#error-message-example","title":"Error Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/connections/1.0/problem_report\",\n  \"@id\": \"5678876542345\",\n  \"~thread\": { \"thid\": \"&lt;@id of message related to problem&gt;\" },\n  \"~i10n\": { \"locale\": \"en\"},\n  \"problem-code\": \"request_not_accepted\", // matches codes listed above\n  \"explain\": \"Unsupported DID method for provided DID.\"\n}\n</code></pre>"},{"location":"features/0160-connection-protocol/#error-message-attributes","title":"Error Message Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is a problem_report within the connections family.</li> <li>The <code>~thread</code> attribute provides a context for the problem, referring to the message which contains the problem.</li> <li>Use of <code>~i10n</code> is encouraged, with at least locale defined for the message.</li> <li>The <code>problem-code</code> attribute contains one of a fixed set of codes defined in the list above.</li> <li>The <code>explain</code> attribute contains a human readable message which indicates the problem.</li> </ul>"},{"location":"features/0160-connection-protocol/#flow-overview","title":"Flow Overview","text":"<p>The inviter gives provisional connection information to the invitee.  The invitee uses provisional information to send a DID and DID document to the inviter. The inviter uses received DID document information to send a DID and DID document to the invitee. The invitee sends the inviter an ack or any other message that confirms the response was received.</p>"},{"location":"features/0160-connection-protocol/#0-invitation-to-connect","title":"0. Invitation to Connect","text":"<p>Note: This Invitation message is deprecated, and should use an invitation message from the Out Of Band Protocol</p> <p>An invitation to connect may be transferred using any method that can reliably transmit text. The result  must be the essential data necessary to initiate a Connection Request message. A connection invitation is an agent message with agent plaintext format, but is an out-of-band communication and therefore not communicated using wire level encoding or encryption. The necessary data that an invitation to connect must result in is:</p> <ul> <li> <p>suggested label</p> </li> <li> <p>publicly resolvable DID</p> </li> </ul> <p>OR</p> <ul> <li> <p>suggested label</p> </li> <li> <p>recipientKeys</p> </li> <li> <p>serviceEndpoint</p> </li> <li> <p>routingKeys (optional)</p> </li> </ul> <p>This information is used to create a provisional connection to the inviter. That connection will be made complete in the <code>connection_response</code> message.</p> <p>These attributes were chosen to parallel the attributes of a DID document for increased meaning. It is worth noting that <code>recipientKeys</code> and <code>routingKeys</code> must be inline keys, not DID key references when contained in an invitation. As in the DID document with <code>Ed25519VerificationKey2018</code> key types, the key must be base58 encoded.</p> <p>When considering routing and options for invitations, keep in mind that the more detail is in the connection invitation, the longer the URL will be and (if used) the more dense the QR code will be. Dense QR codes can be harder to scan.</p> <p>The inviter will either use an existing invitation DID, or provision a new one according to the DID method spec. They will then create the invitation message in one of the following forms.</p> <p>Invitation Message with Public Invitation DID:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/connections/1.0/invitation\",\n    \"@id\": \"12345678900987654321\",\n    \"label\": \"Alice\",\n    \"did\": \"did:sov:QmWbsNYhMrjHiqZDTUTEJs\"\n}\n</code></pre> <p>Invitation Message with Keys and URL endpoint:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/connections/1.0/invitation\",\n    \"@id\": \"12345678900987654321\",\n    \"label\": \"Alice\",\n    \"recipientKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"],\n    \"serviceEndpoint\": \"https://example.com/endpoint\",\n    \"routingKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"]\n}\n</code></pre> <p>Invitation Message with Keys and DID Service Endpoint Reference:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/connections/1.0/invitation\",\n    \"label\": \"Alice\",\n    \"recipientKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"],\n    \"serviceEndpoint\": \"did:sov:A2wBhNYhMrjHiqZDTUYH7u;routeid\",\n    \"routingKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"]\n}\n</code></pre>"},{"location":"features/0160-connection-protocol/#implicit-invitation","title":"Implicit Invitation","text":"<p>Any Public DID serves as an implicit invitation. If an invitee wishes to connect to any Public DID, They designate their own label and skip to the end of the Invitation Processing step. There is no need to encode the invitation or transmit the invitation. </p>"},{"location":"features/0160-connection-protocol/#routing-keys","title":"Routing Keys","text":"<p>If <code>routingKeys</code> is present and non-empty, additional forwarding wrapping will be necessary for the request message. See the explanation in the Request section.</p>"},{"location":"features/0160-connection-protocol/#agency-endpoint","title":"Agency Endpoint","text":"<p>The endpoint for the connection is either present in the invitation or available in the DID document of a presented DID. If the endpoint is not a URI but a DID itself, that DID refers to an Agency.</p> <p>In that case, the <code>serviceEndpoint</code> of the DID must be a URI, and the <code>recipientKeys</code> must contain a single key. That key is appended to the end of the list of <code>routingKeys</code> for processing. For more information about message forwarding and routing, see RFC 0094.</p>"},{"location":"features/0160-connection-protocol/#standard-invitation-encoding","title":"Standard Invitation Encoding","text":"<p>Using a standard invitation encoding allows for easier interoperability between multiple projects and software platforms. Using a URL for that standard encoding provides a built in fallback flow for users who are unable to automatically process the invitation. Those new users will load the URL in a browser as a default behavior, and will be presented with instructions on how to install software capable of processing the invitation. Already onboarded users will be able to process the invitation without loading in a browser via mobile app URL capture, or via capability detection after being loaded in a browser.</p> <p>The standard invitation format is a URL with a Base64URLEncoded json object as a query parameter. </p> <p>The Invitation URL format is as follows, with some elements described below:</p> <pre><code>https://&lt;domain&gt;/&lt;path&gt;?c_i=&lt;invitationstring&gt;\n</code></pre> <p><code>&lt;domain&gt;</code> and <code>&lt;path&gt;</code> should be kept as short as possible, and the full URL should return human readable instructions when loaded in a browser. This is intended to aid new users. The <code>c_i</code> query parameter is required and is reserved to contain the invitation string. Additional path elements or query parameters are allowed, and can be leveraged to provide coupons or other promise of payment for new users. </p> <p>The <code>&lt;invitationstring&gt;</code> is an agent plaintext message (not a wire level message) that has been base64 url encoded. For brevity, the json encoding should minimize unnecessary white space.</p> <pre><code>invitation_string = b64urlencode(&lt;invitation_message&gt;)\n</code></pre> <p>During encoding, whitespace from the json string should be eliminated to keep the resulting invitation string as short as possible.</p>"},{"location":"features/0160-connection-protocol/#example-invitation-encoding","title":"Example Invitation Encoding","text":"<p>Invitation:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/connections/1.0/invitation\",\n    \"@id\": \"12345678900987654321\",\n    \"label\": \"Alice\",\n    \"recipientKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"],\n    \"serviceEndpoint\": \"https://example.com/endpoint\",\n    \"routingKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"]\n}\n</code></pre> <p>Base 64 URL Encoded, with whitespace removed:</p> <pre><code>eyJAdHlwZSI6ImRpZDpzb3Y6QnpDYnNOWWhNcmpIaXFaRFRVQVNIZztzcGVjL2Nvbm5lY3Rpb25zLzEuMC9pbnZpdGF0aW9uIiwiQGlkIjoiMTIzNDU2Nzg5MDA5ODc2NTQzMjEiLCJsYWJlbCI6IkFsaWNlIiwicmVjaXBpZW50S2V5cyI6WyI4SEg1Z1lFZU5jM3o3UFlYbWQ1NGQ0eDZxQWZDTnJxUXFFQjNuUzdaZnU3SyJdLCJzZXJ2aWNlRW5kcG9pbnQiOiJodHRwczovL2V4YW1wbGUuY29tL2VuZHBvaW50Iiwicm91dGluZ0tleXMiOlsiOEhINWdZRWVOYzN6N1BZWG1kNTRkNHg2cUFmQ05ycVFxRUIzblM3WmZ1N0siXX0=\n</code></pre> <p>Example URL:</p> <pre><code>http://example.com/ssi?c_i=eyJAdHlwZSI6ImRpZDpzb3Y6QnpDYnNOWWhNcmpIaXFaRFRVQVNIZztzcGVjL2Nvbm5lY3Rpb25zLzEuMC9pbnZpdGF0aW9uIiwiQGlkIjoiMTIzNDU2Nzg5MDA5ODc2NTQzMjEiLCJsYWJlbCI6IkFsaWNlIiwicmVjaXBpZW50S2V5cyI6WyI4SEg1Z1lFZU5jM3o3UFlYbWQ1NGQ0eDZxQWZDTnJxUXFFQjNuUzdaZnU3SyJdLCJzZXJ2aWNlRW5kcG9pbnQiOiJodHRwczovL2V4YW1wbGUuY29tL2VuZHBvaW50Iiwicm91dGluZ0tleXMiOlsiOEhINWdZRWVOYzN6N1BZWG1kNTRkNHg2cUFmQ05ycVFxRUIzblM3WmZ1N0siXX0=\n</code></pre> <p>Invitation URLs can be transferred via any method that can send text, including an email, SMS, posting on a website, or via a QR Code. </p> <p>Example URL encoded as a QR Code:</p> <p></p>"},{"location":"features/0160-connection-protocol/#invitation-publishing","title":"Invitation Publishing","text":"<p>The inviter will then publish or transmit the invitation URL in a manner available to the intended invitee. After publishing, we have entered the invited state.</p>"},{"location":"features/0160-connection-protocol/#invitation-processing","title":"Invitation Processing","text":"<p>When they invitee receives the invitation URL, there are two possible user flows that depend on the SSI preparedness of the individual. If the individual is new to the SSI universe, they will likely load the URL in a browser. The resulting page will contain instructions on how to get started by installing software or a mobile app. That install flow will transfer the invitation message to the newly installed software. A user that already has those steps accomplished will have the URL received by software directly. That software will base64URL decode the string and can read the invitation message directly out of the <code>c_i</code> query parameter, without loading the URL.</p> <p>NOTE: In receiving the invitation, the base64url decode implementation used MUST correctly decode padded and unpadded base64URL encoded data.</p> <p>If the invitee wants to accept the connection invitation, they will use the information present in the invitation message to prepare the request</p>"},{"location":"features/0160-connection-protocol/#1-connection-request","title":"1. Connection Request","text":"<p>The connection request message is used to communicate the DID document of the invitee to the inviter using the provisional connection information present in the connection_invitation message.</p> <p>The invitee will provision a new DID according to the DID method spec. For a Peer DID, this involves creating a matching peer DID and key. The newly provisioned DID and DID document is presented in the connection_request message as follows:</p>"},{"location":"features/0160-connection-protocol/#example","title":"Example","text":"<pre><code>{\n  \"@id\": \"5678876542345\",\n  \"@type\": \"https://didcomm.org/connections/1.0/request\",\n  \"label\": \"Bob\",\n  \"connection\": {\n    \"DID\": \"B.did@B:A\",\n    \"DIDDoc\": {\n        \"@context\": \"https://w3id.org/did/v1\"\n        // DID document contents here.\n    }\n  }\n}\n</code></pre>"},{"location":"features/0160-connection-protocol/#attributes","title":"Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is a connection request.</li> <li>The <code>label</code> attribute provides a suggested label for the connection. This allows the user to tell multiple connection offers apart. This is not a trusted attribute.</li> <li>The <code>connection</code> attribute contains the <code>DID</code> and <code>DIDDoc</code> attributes. This format maintains consistency with the Response message where this attribute is signed.</li> <li>The <code>DID</code> indicates the DID of the user requesting the connection.</li> <li>The <code>DIDDoc</code> contains the DID document for the requesting user. If the DID method for the presented DID is not a peer method and the DID document is resolvable on a ledger, the <code>DIDDoc</code> attribute is optional.</li> </ul>"},{"location":"features/0160-connection-protocol/#diddoc-example","title":"DIDDoc Example","text":"<p>An example of the DID document contents is the following JSON. This format was implemented in some early agents as the DIDComm DIDDoc Conventions RFC was being formalized and so does not match that RFC exactly. For example, the use of the <code>IndyAgent</code> service endpoint. Future versions of this protocol will align precisely with that RFC.</p> <pre><code>{\n  \"@context\": \"https://w3id.org/did/v1\",\n  \"id\": \"did:sov:QUmsj7xwB82QAuuzfmvhAi\",\n  \"publicKey\": [\n    {\n      \"id\": \"did:sov:QUmsj7xwB82QAuuzfmvhAi#1\",\n      \"type\": \"Ed25519VerificationKey2018\",\n      \"controller\": \"did:sov:QUmsj7xwB82QAuuzfmvhAi\",\n      \"publicKeyBase58\": \"DoDMNYwMrSN8ygGKabgz5fLA9aWV4Vi8SLX6CiyN2H4a\"\n    }\n  ],\n  \"authentication\": [\n    {\n      \"type\": \"Ed25519SignatureAuthentication2018\",\n      \"publicKey\": \"did:sov:QUmsj7xwB82QAuuzfmvhAi#1\"\n    }\n  ],\n  \"service\": [\n    {\n      \"id\": \"did:sov:QUmsj7xwB82QAuuzfmvhAi;indy\",\n      \"type\": \"IndyAgent\",\n      \"priority\": 0,\n      \"recipientKeys\": [\n        \"DoDMNYwMrSN8ygGKabgz5fLA9aWV4Vi8SLX6CiyN2H4a\"\n      ],\n      \"serviceEndpoint\": \"http://192.168.65.3:8030\"\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0160-connection-protocol/#request-transmission","title":"Request Transmission","text":"<p>The Request message is encoded according to the standards of the Agent Wire Level Protocol, using the <code>recipientKeys</code> present in the invitation. </p> <p>If the <code>routingKeys</code> attribute was present and non-empty in the invitation, each key must be used to wrap the message in a forward request, then encoded according to the Agent Wire Level Protocol. This processing is in order of the keys in the list, with the last key in the list being the one for which the <code>serviceEndpoint</code> possesses the private key.</p> <p>The message is then transmitted to the <code>serviceEndpoint</code>.</p> <p>We are now in the <code>requested</code> state.</p>"},{"location":"features/0160-connection-protocol/#request-processing","title":"Request processing","text":"<p>After receiving the connection request, the inviter evaluates the provided DID and DID document according to the DID Method Spec.</p> <p>The inviter should check the information presented with the keys used in the wire-level message transmission to ensure they match.</p> <p>If the inviter wishes to accept the connection, they will persist the received information in their wallet. They will then either update the provisional connection information to rotate the key, or provision a new DID entirely. The choice here will depend on the nature of the DID used in the invitation.</p> <p>The inviter will then craft a connection response using the newly updated or provisioned information.</p>"},{"location":"features/0160-connection-protocol/#request-errors","title":"Request Errors","text":"<p>See Error Section above for message format details.</p> <p>request_rejected</p> <p>Possible reasons:</p> <ul> <li>Unsupported DID method for provided DID</li> <li>Expired Invitation</li> <li>DID Document Invalid</li> <li>Unsupported key type</li> <li>Unsupported endpoint protocol</li> </ul> <p>request_processing_error</p> <ul> <li>unknown processing error</li> </ul>"},{"location":"features/0160-connection-protocol/#2-connection-response","title":"2. Connection Response","text":"<p>The connection response message is used to complete the connection. This message is required in the flow, as it updates the provisional information presented in the invitation.</p>"},{"location":"features/0160-connection-protocol/#example_1","title":"Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/connections/1.0/response\",\n  \"@id\": \"12345678900987654321\",\n  \"~thread\": {\n    \"thid\": \"&lt;@id of request message&gt;\"\n  },\n  \"connection\": {\n    \"DID\": \"A.did@B:A\",\n    \"DIDDoc\": {\n      \"@context\": \"https://w3id.org/did/v1\"\n      // DID document contents here.\n    }\n  }\n}\n</code></pre> <p>The above message is required to be signed as described in RFC 0234 Signature Decorator. The <code>connection</code> attribute above will be base64URL encoded and included as part of the <code>sig_data</code> attribute of the signed field. The result looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/connections/1.0/response\",\n  \"@id\": \"12345678900987654321\",\n  \"~thread\": {\n    \"thid\": \"&lt;@id of request message&gt;\"\n  },\n  \"connection~sig\": {\n    \"@type\": \"https://didcomm.org/signature/1.0/ed25519Sha512_single\",\n    \"signature\": \"&lt;digital signature function output&gt;\",\n    \"sig_data\": \"&lt;base64URL(64bit_integer_from_unix_epoch||connection_attribute)&gt;\",\n    \"signer\": \"&lt;signing_verkey&gt;\"\n  }\n}\n</code></pre> <p>The <code>connection</code> attribute has been removed and it's contents combined with the timestamp  and encoded into the <code>sig_data</code> field of the new <code>connection~sig</code> attribute.</p> <p>Upon receipt, the signed attribute will be automatically unpacked and the signature verified. Signature information will be stored as message context, and the <code>connection</code> attribute will be replaced in it's original format before processing continues.</p> <p>The signature data must be used to verify against the invitation's <code>recipientKeys</code> for continuity. </p>"},{"location":"features/0160-connection-protocol/#attributes_1","title":"Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is a connection request.</li> <li>The <code>~thread</code> block contains a <code>thid</code> reference to the <code>@id</code> of the request message. </li> <li>The <code>connection</code> attribute contains the <code>DID</code> and <code>DIDDoc</code> attributes to enable simpler signing.</li> <li>The <code>DID</code> attribute is a required string value and denotes DID in use by the inviter. Note that this may not be the same DID used in the invitation.</li> <li>The <code>DIDDoc</code> attribute contains the associated DID document. If the DID method for the presented DID is not a peer method and the DID document is resolvable on a ledger, the <code>DIDDoc</code> attribute is optional.</li> </ul> <p>In addition to a new DID, the associated DID document might contain a new endpoint. This new DID and endpoint are to be used going forward in the connection.</p>"},{"location":"features/0160-connection-protocol/#response-transmission","title":"Response Transmission","text":"<p>The message should be packaged in the wire level format, using the keys from the request, and the new keys presented in the internal DID document.</p> <p>When the message is transmitted, we are now in the <code>responded</code> state.</p>"},{"location":"features/0160-connection-protocol/#response-processing","title":"Response Processing","text":"<p>When the invitee receives the <code>response</code> message, they will verify the <code>sig_data</code> provided. After validation, they will update their wallet with the new connection information. If the endpoint was changed, they may wish to execute a Trust Ping to verify that new endpoint.</p>"},{"location":"features/0160-connection-protocol/#response-errors","title":"Response Errors","text":"<p>See Error Section above for message format details.</p> <p>response_rejected</p> <p>Possible reasons:</p> <ul> <li>Unsupported DID method for provided DID</li> <li>Expired Request</li> <li>DID Document Invalid</li> <li>Unsupported key type</li> <li>Unsupported endpoint protocol</li> <li>Invalid Signature</li> </ul> <p>response_processing_error</p> <ul> <li>unknown processing error</li> </ul>"},{"location":"features/0160-connection-protocol/#3-connection-acknowledgement","title":"3. Connection Acknowledgement","text":"<p>After the Response is received, the connection is technically complete. This remains unconfirmed to the inviter however. The invitee SHOULD send a message to the inviter. As any message will confirm the connection, any message will do. </p> <p>Frequently, the parties of the connection will want to trade credentials to establish trust. In such a flow, those message will serve the function of acknowledging the connection without an extra confirmation message.</p> <p>If no message is needed immediately, a trust ping can be used to allow both parties confirm the connection.</p> <p>After a message is sent, the invitee in the <code>complete</code> state. Receipt of a message puts the inviter into the <code>complete</code> state.</p>"},{"location":"features/0160-connection-protocol/#next-steps","title":"Next Steps","text":"<p>The connection between the inviter and the invitee is now established. This connection has no trust associated with it. The next step should be the exchange of proofs to build trust sufficient for the purpose of the relationship.</p>"},{"location":"features/0160-connection-protocol/#connection-maintenance","title":"Connection Maintenance","text":"<p>Upon establishing a connection, it is likely that both Alice and Bob will want to perform some relationship maintenance such as key rotations. Future RFC updates will add these maintenance ../../features.</p>"},{"location":"features/0160-connection-protocol/#reference","title":"Reference","text":"<ul> <li>https://docs.google.com/document/d/1mRLPOK4VmU9YYdxHJSxgqBp19gNh3fT7Qk4Q069VPY8/edit#heading=h.7sxkr7hbou5i</li> <li>Agent to Agent Communication Video</li> <li>Agent to Agent Communication Presentation</li> <li>Problem_report message adopted into message family, following form defined by the Report Problem RFC</li> <li>Useful QR Code Generator: https://zxing.appspot.com/generator/</li> </ul>"},{"location":"features/0160-connection-protocol/#drawbacks","title":"Drawbacks","text":"<ul> <li>Public invitations (say, a slide at the end of a presentation) all use the same DID. This is not a problem for public institutions, and only provides a minor increase in correlation over sharing an endpoint, key, and routing information in a way that is observable by multiple parties.</li> </ul>"},{"location":"features/0160-connection-protocol/#prior-art","title":"Prior art","text":"<ul> <li>This process is similar to other key exchange protocols.</li> </ul>"},{"location":"features/0160-connection-protocol/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Should we eliminate the public DID option, and they just present an invitation with the connection key from their public DID document?</li> <li>Should invitations have <code>@id</code>s?</li> </ul>"},{"location":"features/0160-connection-protocol/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Framework - .NET passed agent connectathon tests, Feb 2019; MISSING test results Streetcred.id passed agent connectathon tests, Feb 2019; MISSING test results Aries Cloud Agent - Python ported from VON codebase that passed agent connectathon tests, Feb 2019; MISSING test results Aries Static Agent - Python implemented July 2019; MISSING test results Aries Protocol Test Suite ported from Indy Agent codebase that provided agent connectathon tests, Feb 2019; MISSING test results Indy Cloud Agent - Python passed agent connectathon tests, Feb 2019; MISSING test results"},{"location":"features/0183-revocation-notification/","title":"Aries RFC 0183: Revocation Notification 1.0","text":"<ul> <li>Authors: Keith Smith</li> <li>Status: ACCEPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Initial proposal after discussion on rocketchat</li> <li>Supersedes:</li> <li>Start Date: 2018-08-12</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0183-revocation-notification/#summary","title":"Summary","text":"<p>This RFC defines the message format which an issuer uses to notify a holder that a previously issued credential has been revoked.</p>"},{"location":"features/0183-revocation-notification/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> </ul>"},{"location":"features/0183-revocation-notification/#motivation","title":"Motivation","text":"<p>We need a standard protocol for an issuer to notify a holder that a previously issued credential has been revoked.</p> <p>For example, suppose a passport agency revokes Alice's passport. The passport agency (an issuer) may want to notify Alice (a holder) that her passport has been revoked so that she knows that she will be unable to use her passport to travel.</p>"},{"location":"features/0183-revocation-notification/#tutorial","title":"Tutorial","text":"<p>The Revocation Notification protocol is a very simple protocol consisting of a single message:</p> <ul> <li>Revoke - issuer to holder</li> </ul> <p>This simple protocol allows an issuer to choose to notify a holder that a previously issued credential has been revoked.</p> <p>It is the issuer's prerogative whether or not to notify the holder that a credential has been revoked.  It is not a security risk if the issuer does not notify the holder that the credential has been revoked, nor if the message is lost.  The holder will still be unable to use a revoked credential without this notification.</p>"},{"location":"features/0183-revocation-notification/#roles","title":"Roles","text":"<p>There are two parties involved in a Revocation Notification: <code>issuer</code> and <code>holder</code>. The <code>issuer</code> sends the <code>revoke</code> message to the <code>holder</code>.</p>"},{"location":"features/0183-revocation-notification/#messages","title":"Messages","text":"<p>The <code>revoke</code> message sent by the <code>issuer</code> to the <code>holder</code> is as follows:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/revocation_notification/1.0/revoke\",\n  \"@id\": \"&lt;uuid-revocation-notification&gt;\",\n  \"thread_id\": \"&lt;thread_id&gt;\",\n  \"comment\": \"Some comment\"\n}\n</code></pre> <p>Description of fields:</p> <ul> <li> <p><code>thread_id</code> (required) -- the thread ID of the issue-credential-v2 protocol which was used to issue one or more credentials that have been revoked by the issuer.  If multiple credentials were issued, each credential has a different credential format but contains the same claims as described here; therefore, this message notifies the holder that all of these credentials have been revoked.</p> </li> <li> <p><code>comment</code> (optional) -- a field that provides some human readable information about the revocation notification.  This is typically the reason for the revocation as deemed appropriate by the issuer.</p> </li> </ul>"},{"location":"features/0183-revocation-notification/#reference","title":"Reference","text":"<ul> <li>See the issue-credential-v2 protocol.</li> <li>See the thread ID description.</li> <li>See the Please ACK Decorator RFC.</li> </ul>"},{"location":"features/0183-revocation-notification/#drawbacks","title":"Drawbacks","text":"<p>If we later added support for more general event subscription and notification message flows, this would be redundant.</p>"},{"location":"features/0183-revocation-notification/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?  It is simple.</li> <li>What other designs have been considered and what is the rationale for not choosing them?  A more general event subscription and notification mechanism was considered but chose to keep this simple for the same reasons that the basic message was kept simple.</li> <li>What is the impact of not doing this?  There is no standard way of sending a revocation notification which is a common scenario.</li> </ul>"},{"location":"features/0183-revocation-notification/#prior-art","title":"Prior art","text":""},{"location":"features/0183-revocation-notification/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"features/0183-revocation-notification/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0193-coin-flip/","title":"Aries RFC 0193: Coin Flip Protocol 1.0","text":"<ul> <li>Authors: Daniel Hardman, Patrick St\u00fcrmlinger</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Start Date: 2019-08-19</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0193-coin-flip/#summary","title":"Summary","text":"<p>Specifies a safe way for two parties who are remote from one another and who do not trust one another to pick a random, binary outcome that neither can manipulate.</p>"},{"location":"features/0193-coin-flip/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> </ul>"},{"location":"features/0193-coin-flip/#motivation","title":"Motivation","text":"<p>To guarantee fairness, it is often important to pick one party in a protocol to make a choice about what to do next. We need a way to do this that it more or less mirrors the randomness of flipping a coin.</p>"},{"location":"features/0193-coin-flip/#tutorial","title":"Tutorial","text":""},{"location":"features/0193-coin-flip/#name-and-version","title":"Name and Version","text":"<p>This defines the <code>coinflip</code> protocol, version 1.x, as identified by the following PIURI:</p> <pre><code>https://github.com/hyperledger/aries-rfcs../../features/0193-coin-flip/1.0\n</code></pre>"},{"location":"features/0193-coin-flip/#roles","title":"Roles","text":"<p>There are 2 roles in the protocol: Recorder and Caller. These role names parallel the roles in a physical coin flip: the Recorder performs a process that freezes/records the state of a flipped coin, and the Caller announces the state that they predict, before the state is known. If the caller predicts the state correctly, then the caller chooses what happens next; otherwise, the recorder chooses.</p>"},{"location":"features/0193-coin-flip/#algorithm","title":"Algorithm","text":"<p>Before describing the messages, let's review the algorithm that will be used. This algorithm is not new; it is a simple commitment scheme described on wikipedia and implemented in various places. The RFC merely formalizes a simple commitment scheme for DIDComm in a way that the Caller chooses a side without knowing whether it's <code>win</code> or <code>lose</code>.</p> <ol> <li> <p>Recorder chooses a random UUID. A version 4 UUID is recommended, though any UUID version should be accepted. Note that the UUID is represented in lower case, with hyphens, and without enclosing curly braces. Suppose this value is <code>01bf7abd-aa80-4389-bf8c-dba0f250bb1b</code>. This UUID is called salt.</p> </li> <li> <p>Recorder builds two side strings by salting <code>win</code> and <code>lose</code> with the salt -- i.e., <code>win01bf7abd-aa80-4389-bf8c-dba0f250bb1b</code> and <code>lose01bf7abd-aa80-4389-bf8c-dba0f250bb1b</code>. Recorder then computes a SHA256 hash of each side string, which are <code>0C192E004440D8D6D6AF06A7A03A2B182903E9F048D4E7320DF6301DF0C135A5</code> and <code>C587E50CB48B1B0A3B5136BA9D238B739A6CD599EE2D16994537B75CA595C091</code> for our example, and randomly selects one side string as side1 and the other one as side2. Recorder sends them to Caller using the <code>propose</code> message described below. Those hashes do commit Recorder to all inputs, without revealing which one is <code>win</code> or <code>lose</code>, and it's the Recorder's way of posing the Caller the question, \"underside or topside\"?</p> </li> <li> <p>Caller announces their committed choice -- for instance, <code>side2</code>, using the 'call' message described below. This commits Caller to a particular side of the virtual coin.</p> </li> <li> <p>Recorder uses a 'reveal' message to reveal the salt. Caller is now able to rebuild both side strings and both parties discover whether Caller guessed the <code>win</code> side or not. If Caller guessed the <code>win</code> side, Caller won. Otherwise Recorder won. Neither party is able to manipulate the outcome. This is guaranteed by Caller being able to verify that Recorder proposed two valid options, i.e. one side winning and one side losing, and Recorder knowing not to reveal any disclosed information before Caller made their choice.</p> </li> </ol>"},{"location":"features/0193-coin-flip/#states","title":"States","text":"<p>The algorithm and the corresponding states are pictured in the following diagram:</p> <p></p>  Note: This diagram was made in draw.io. To make changes:  - upload the drawing HTML from this folder to the [draw.io](https://draw.io) site (Import From... Device),  - make changes, - export the picture as PNG and HTML to your local copy of this repo, and - submit a pull request.  <p>This diagram only depicts the so-called \"happy path\". It is possible to experience problems for various reasons. If either party detects such an event, they should abandon the protocol and emit a <code>problem-report</code> message to the other party. The <code>problem-report</code> message is adopted into this protocol for that purpose. Some values of <code>code</code> that may be used in such messages include:</p> <ul> <li><code>bad-message-sequence</code>: The message was sent out of order.</li> <li><code>bad-field-value</code>: The message contained a field with an invalid value. The offending fields are named in the <code>problem_items</code> array. </li> </ul>"},{"location":"features/0193-coin-flip/#reference","title":"Reference","text":""},{"location":"features/0193-coin-flip/#messages","title":"Messages","text":""},{"location":"features/0193-coin-flip/#propose","title":"<code>propose</code>","text":"<p>The protocol begins when Caller sends to Recorder a <code>propose</code> message that embodies Step 1 in the algorithm above. It looks like this:</p> <pre><code>{\n  \"@type\": \"https://github.com/hyperledger/aries-rfcs../../features/0193-coin-flip/1.0/propose\",\n  \"@id\": \"518be002-de8e-456e-b3d5-8fe472477a86\",\n  \"side1\": \"C587E50CB48B1B0A3B5136BA9D238B739A6CD599EE2D16994537B75CA595C091\",\n  \"side2\": \"0C192E004440D8D6D6AF06A7A03A2B182903E9F048D4E7320DF6301DF0C135A5\",\n  \"comment\": \"Make your choice and let's who goes first.\",\n  \"choice-id\": \"did:sov:SLfEi9esrjzybysFxQZbfq;spec/tictactoe/1.0/who-goes-first\",\n  \"caller-wins\": \"did:example:abc123\",  // Meaning of value defined in superprotocol\n  \"recorder-wins\": \"did:example:xyz456\", // Meaning of value defined in superprotocol\n  // Optional; connects to superprotocol\n  \"~thread\": { \n    \"pthid\": \"a2be4118-4f60-bacd-c9a0-dfb581d6fd96\" \n  }\n}\n</code></pre> <p>The <code>@type</code> and <code>@id</code> fields are standard for DIDComm. The <code>side1</code> and <code>side2</code> fields convey the data required by Step 2 of the algorithm. The optional <code>comment</code> field follows localization conventions and is irrelevant unless the coin flip intends to invite human participation. The <code>~thread.pthid</code> decorator is optional but should be common; it identifies the thread of the parent interaction (the superprotocol).</p> <p>The <code>choice-id</code> field formally names a choice that a superprotocol has defined, and tells how the string values of the <code>caller-wins</code> and <code>recorder-wins</code> fields will be interpreted. In the example above, the choice is defined in the Tic-Tac-Toe Protocol, which also specifies that <code>caller-wins</code> and <code>recorder-wins</code> will contain DIDs of the parties playing the game. Some other combinations that might make sense include:</p> <ul> <li> <p>In an auction protocol that uses a coin flip to break a tie between two bids of equal value, <code>choice-id</code> might be a string like <code>prefix/myauctionproto/1.0/bid-tie-break</code>, and the values of the <code>*-wins</code> fields might be the <code>id</code> properties of specific bid messages.</p> </li> <li> <p>In a protocol that models an American football game, the <code>choice-id</code> might be a string like <code>prefix/amfootball/1.0/who-kicks-off</code>, and the values of the <code>*-wins</code> fields might be the strings \"home\" and \"visitor\".</p> </li> <li> <p>In a protocol that models radioactive halflife, the decay of a particular neutron might use <code>choice-id</code> of <code>prefix/halflife/1.0/should-decay</code>, and the <code>*-wins</code> fields might be the strings \"yes\" and \"no\".</p> </li> </ul> <p>The <code>~timing.expires_time</code> decorator may be used to impose a time limit on the processing of this message. If used, the protocol must restart if the subsequent <code>call</code> message is not received by this time limit.</p>"},{"location":"features/0193-coin-flip/#call","title":"<code>call</code>","text":"<p>This message is sent from Caller to Recorder, and embodies Step 3 of the algorithm. It looks like this:</p> <pre><code>{\n  \"@type\": \"https://github.com/hyperledger/aries-rfcs../../features/0193-coin-flip/1.0/call\",\n  \"@id\": \"1173fe5f-86c9-47d7-911b-b8eac7d5f2ad\",\n  \"choice\": \"side2\",\n  \"comment\": \"I pick side 2.\",\n  \"~thread\": { \n    \"thid\": \"518be002-de8e-456e-b3d5-8fe472477a86\",\n    \"sender_order\": 1 \n  }\n}\n</code></pre> <p>Note the use of <code>~thread.thid</code> and <code>sender_order: 1</code> to connect this <code>call</code> to the preceding <code>propose</code>.</p> <p>The <code>~timing.expires_time</code> decorator may be used to impose a time limit on the processing of this message. If used, the protocol must restart if the subsequent <code>reveal</code> message is not received by this time limit.</p>"},{"location":"features/0193-coin-flip/#reveal","title":"<code>reveal</code>","text":"<p>This message is sent from Recorder to Caller, and embodies Step 4 of the algorithm. It looks like this:</p> <pre><code>{\n  \"@type\": \"https://github.com/hyperledger/aries-rfcs../../features/0193-coin-flip/1.0/reveal\",\n  \"@id\": \"e2a9454d-783d-4663-874e-29ad10776115\",\n  \"salt\": \"01bf7abd-aa80-4389-bf8c-dba0f250bb1b\",\n  \"winner\": \"caller\",\n  \"comment\": \"You win.\",\n  \"~thread\": { \n    \"thid\": \"518be002-de8e-456e-b3d5-8fe472477a86\",\n    \"sender_order\": 1 \n  }\n}\n</code></pre> <p>Note the use of <code>~thread.thid</code> and <code>sender_order: 1</code> to connect this <code>reveal</code> to the preceding <code>call</code>.</p> <p>The Caller should validate this message as follows:</p> <ul> <li>Confirm that SHA256 hashes of <code>win</code> and <code>lose</code> salted with salt results in the two side strings from the <code>propose</code> message. This check is important because it eliminates the possibility that the Recorder could introduce variation to the commitment.</li> </ul> <p>Having validated the message thus far, Caller determines the winner by checking if the self computed hash of <code>win&lt;salt&gt;</code> equals the given hash at the <code>propose</code> message at the position chosen with the <code>call</code> message or not. If yes, then the value of the <code>winner</code> field must be <code>caller</code>; if not, then it must be <code>recorder</code>. The <code>winner</code> field must be present in the message, and its value must be correct, for the <code>reveal</code> message to be deemed fully valid. This confirms that both parties understand the outcome, and it prevents a Recorder from asserting a false outcome that is accepted by careless validation logic on the Caller side.</p> <p>The <code>~timing.expires_time</code> decorator may be used to impose a time limit on the processing of this message. If used, the protocol must restart if the subsequent <code>ack</code> or the next message in the superprotocol is not received before the time limit.</p>"},{"location":"features/0193-coin-flip/#drawbacks","title":"Drawbacks","text":"<p>The protocol is a bit chatty.</p>"},{"location":"features/0193-coin-flip/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>It may be desirable to pick among more than 2 alternatives. This RFC could be extended easily to provide more options than win and lose. The algorithm itself would not change.</p>"},{"location":"features/0193-coin-flip/#prior-art","title":"Prior art","text":"<p>As mentioned in the introduction, the algorithm used in this protocol is a simple and well known form of cryptographic commitment, and is documented on Wikipedia. It is not new to this RFC.</p>"},{"location":"features/0193-coin-flip/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Do we need to use hashlink so we can move to a new hash algorithm if SHA256 is ever broken?</li> </ul>"},{"location":"features/0193-coin-flip/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0211-route-coordination/","title":"0211: Mediator Coordination Protocol","text":"<ul> <li>Authors: Sam Curren, Daniel Bluhm, Adam Burdett</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Discussed and implemented and part of AIP 2.0.</li> <li>Start Date: 2019-09-03</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"features/0211-route-coordination/#summary","title":"Summary","text":"<p>A protocol to coordinate mediation configuration between a mediating agent and the recipient.</p>"},{"location":"features/0211-route-coordination/#application-scope","title":"Application Scope","text":"<p>This protocol is needed when using an edge agent and a mediator agent from different vendors. Edge agents and mediator agents from the same vendor may use whatever protocol they wish without sacrificing interoperability.</p>"},{"location":"features/0211-route-coordination/#motivation","title":"Motivation","text":"<p>Use of the forward message in the Routing Protocol requires an exchange of information. The Recipient must know which endpoint and routing key(s) to share, and the Mediator needs to know which keys should be routed via this relationship.</p>"},{"location":"features/0211-route-coordination/#protocol","title":"Protocol","text":"<p>Name: coordinate-mediation</p> <p>Version: 1.0</p> <p>Base URI: <code>https://didcomm.org/coordinate-mediation/1.0/</code></p>"},{"location":"features/0211-route-coordination/#roles","title":"Roles","text":"<p>mediator - The agent that will be receiving <code>forward</code> messages on behalf of the recipient. recipient - The agent for whom the <code>forward</code> message payload is intended.</p>"},{"location":"features/0211-route-coordination/#flow","title":"Flow","text":"<p>A recipient may discover an agent capable of routing using the Feature Discovery Protocol. If protocol is supported with the mediator role, a recipient may send a <code>mediate-request</code> to initiate a routing relationship.</p> <p>First, the recipient sends a <code>mediate-request</code> message to the mediator. If the mediator is willing to route messages, it will respond with a <code>mediate-grant</code> message. The recipient will share the routing information in the grant message with other contacts.</p> <p>When a new key is used by the recipient, it must be registered with the mediator to enable route identification. This is done with a <code>keylist-update</code> message.</p> <p>The <code>keylist-update</code> and <code>keylist-query</code> methods are used over time to identify and remove keys that are no longer in use by the recipient.</p>"},{"location":"features/0211-route-coordination/#reference","title":"Reference","text":"<p>Note on terms: Early versions of this protocol included the concept of terms for mediation.  This concept has been removed from this version due to a need for further discussion on representing terms in DIDComm in general and lack of use of these terms in current implementations.</p>"},{"location":"features/0211-route-coordination/#mediation-request","title":"Mediation Request","text":"<p>This message serves as a request from the recipient to the mediator, asking for the permission (and routing information) to publish the endpoint as a mediator.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/mediate-request\",\n}\n</code></pre>"},{"location":"features/0211-route-coordination/#mediation-deny","title":"Mediation Deny","text":"<p>This message serves as notification of the mediator denying the recipient's request for mediation.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/mediate-deny\",\n}\n</code></pre>"},{"location":"features/0211-route-coordination/#mediation-grant","title":"Mediation Grant","text":"<p>A route grant message is a signal from the mediator to the recipient that permission is given to distribute the included information as an inbound route.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/mediate-grant\",\n    \"endpoint\": \"http://mediators-r-us.com\",\n    \"routing_keys\": [\"did:key:z6Mkfriq1MqLBoPWecGoDLjguo1sB9brj6wT3qZ5BxkKpuP6\"]\n}\n</code></pre> <p><code>endpoint</code>: The endpoint reported to mediation client connections.</p> <p><code>routing_keys</code>: List of keys in intended routing order. Key used as recipient of forward messages.</p>"},{"location":"features/0211-route-coordination/#keylist-update","title":"Keylist Update","text":"<p>Used to notify the mediator of keys in use by the recipient.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/keylist-update\",\n    \"updates\":[\n        {\n            \"recipient_key\": \"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\",\n            \"action\": \"add\"\n        }\n    ]\n}\n</code></pre> <p><code>recipient_key</code>: Key subject of the update.</p> <p><code>action</code>: One of <code>add</code> or <code>remove</code>.</p>"},{"location":"features/0211-route-coordination/#keylist-update-response","title":"Keylist Update Response","text":"<p>Confirmation of requested keylist updates.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/keylist-update-response\",\n    \"updated\": [\n        {\n            \"recipient_key\": \"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\",\n            \"action\": \"\" // \"add\" or \"remove\"\n            \"result\": \"\" // [client_error | server_error | no_change | success]\n        }\n    ]\n}\n</code></pre> <p><code>recipient_key</code>: Key subject of the update.</p> <p><code>action</code>: One of <code>add</code> or <code>remove</code>.</p> <p><code>result</code>: One of <code>client_error</code>, <code>server_error</code>, <code>no_change</code>, <code>success</code>; describes the resulting state of the keylist update.</p>"},{"location":"features/0211-route-coordination/#key-list-query","title":"Key List Query","text":"<p>Query mediator for a list of keys registered for this connection.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/keylist-query\",\n    \"paginate\": {\n        \"limit\": 30,\n        \"offset\": 0\n    }\n}\n</code></pre> <p><code>paginate</code> is optional.</p>"},{"location":"features/0211-route-coordination/#key-list","title":"Key List","text":"<p>Response to key list query, containing retrieved keys.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/keylist\",\n    \"keys\": [\n        {\n            \"recipient_key\": \"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"\n        }\n    ],\n    \"pagination\": {\n        \"count\": 30,\n        \"offset\": 30,\n        \"remaining\": 100\n    }\n}\n</code></pre> <p><code>pagination</code> is optional.</p>"},{"location":"features/0211-route-coordination/#encoding-of-keys","title":"Encoding of keys","text":"<p>All keys are encoded using the <code>did:key</code> method as per RFC0360.</p>"},{"location":"features/0211-route-coordination/#prior-art","title":"Prior art","text":"<p>There was an Indy HIPE that never made it past the PR process that described a similar approach. That HIPE led to a partial implementation of this inside the Aries Cloud Agent Python</p>"},{"location":"features/0211-route-coordination/#future-considerations","title":"Future Considerations","text":"<ul> <li>Should we allow listing keys by date? You could query keys in use by date?</li> <li>We are missing a way to check a single key (or a few keys) without doing a full list.</li> <li>Mediation grant supports only one endpoint. What can be done to support multiple endpoint options i.e. http, ws, etc.</li> <li>Requiring proof of key ownership (with a signature) would prevent an edge case where a malicious party registers a key for another party at the same mediator, and before the other party.</li> <li>How do we express terms and conditions for mediation?</li> </ul>"},{"location":"features/0211-route-coordination/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>None</li> </ul>"},{"location":"features/0211-route-coordination/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python Added in ACA-Py 0.6.0 MISSING test results**** DIDComm mediator Open source cloud-based mediator."},{"location":"features/0212-pickup/","title":"0212: Pickup Protocol","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: PROPOSED</li> <li>Since: 2019-09-03</li> <li>Status Note: Initial version</li> <li>Start Date: 2019-09-03</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0212-pickup/#summary","title":"Summary","text":"<p>A protocol to coordinate routing configuration between a routing agent and the recipient.</p>"},{"location":"features/0212-pickup/#motivation","title":"Motivation","text":"<p>Messages can be picked up simply by sending a message to the message holder with a <code>return_route</code> decorator specified. This mechanism is implicit, and lacks some desired behavior made possible by more explicit messages. This protocol is the explicit companion to the implicit method of picking up messages.</p>"},{"location":"features/0212-pickup/#tutorial","title":"Tutorial","text":""},{"location":"features/0212-pickup/#roles","title":"Roles","text":"<p>message_holder - The agent that has messages waiting for pickup by the recipient. recipient - The agent who is picking up messages. batch_sender - A message_holder that is capable of returning messages in a <code>batch</code>. batch_recipient - A recipient that is capable of receiving and processing a <code>batch</code> message.</p>"},{"location":"features/0212-pickup/#flow","title":"Flow","text":"<p>status can be used to see how many messages are pending. batch retrieval can be executed when many messages ...</p>"},{"location":"features/0212-pickup/#reference","title":"Reference","text":""},{"location":"features/0212-pickup/#statusrequest","title":"StatusRequest","text":"<p>Sent by the recipient to the message_holder to request a <code>status</code> message.</p> <pre><code>{\n  \"@id\": \"123456781\",\n  \"@type\": \"https://didcomm.org/messagepickup/1.0/status-request\"\n}\n</code></pre>"},{"location":"features/0212-pickup/#status","title":"Status","text":"<p>Status details about pending messages</p> <pre><code>{\n  \"@id\": \"123456781\",\n  \"@type\": \"https://didcomm.org/messagepickup/1.0/status\",\n  \"message_count\": 7,\n  \"duration_waited\": 3600,\n  \"last_added_time\": \"2019-05-01 12:00:00Z\",\n  \"last_delivered_time\": \"2019-05-01 12:00:01Z\",\n  \"last_removed_time\": \"2019-05-01 12:00:01Z\",\n  \"total_size\": 8096\n}\n</code></pre> <p><code>message_count</code> is the only required attribute. The others may be present if offered by the message_holder.</p>"},{"location":"features/0212-pickup/#batch-pickup","title":"Batch Pickup","text":"<p>A request to have multiple waiting messages sent inside a <code>batch</code> message.</p> <pre><code>{\n  \"@id\": \"123456781\",\n  \"@type\": \"https://didcomm.org/messagepickup/1.0/batch-pickup\",\n  \"batch_size\": 10\n}\n</code></pre>"},{"location":"features/0212-pickup/#batch","title":"Batch","text":"<p>A message that contains multiple waiting messages.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"https://didcomm.org/messagepickup/1.0/batch\",\n    \"messages~attach\": [\n        {\n            \"@id\" : \"06ca25f6-d3c5-48ac-8eee-1a9e29120c31\",\n            \"message\" : \"{\n                ...\n            }\"\n        },\n\n        {\n            \"@id\" : \"344a51cf-379f-40ab-ab2c-711dab3f53a9a\",\n            \"message\" : \"{\n                ...\n            }\"\n        }\n    ]\n}\n</code></pre>"},{"location":"features/0212-pickup/#message-query-with-message-id-list","title":"Message Query With Message Id List","text":"<p>A request to read single or multiple messages with a message message id array.</p> <pre><code>{\n  \"@id\": \"123456781\",\n  \"@type\": \"https://didcomm.org/messagepickup/1.0/list-pickup\",\n  \"message_ids\": [\n    \"06ca25f6-d3c5-48ac-8eee-1a9e29120c31\",\n    \"344a51cf-379f-40ab-ab2c-711dab3f53a9a\"\n  ]\n}\n</code></pre> <p><code>message_ids</code> message id array for picking up messages. Any message id in <code>message_ids</code> could be delivered via several ways to the recipient (Push notification or with an envoloped message).</p>"},{"location":"features/0212-pickup/#message-list-query-response","title":"Message List Query Response","text":"<p>A response to query with message id list.</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/messagepickup/1.0/list-response\",\n    \"messages~attach\": [\n        {\n            \"@id\" : \"06ca25f6-d3c5-48ac-8eee-1a9e29120c31\",\n            \"message\" : \"{\n                ...\n            }\"\n        },\n        {\n            \"@id\" : \"344a51cf-379f-40ab-ab2c-711dab3f53a9a\",\n            \"message\" : \"{\n                ...\n            }\"\n        }\n    ]\n}\n</code></pre>"},{"location":"features/0212-pickup/#noop","title":"Noop","text":"<p>Used to receive another message implicitly. This message has no expected behavior when received.</p> <pre><code>{\n  \"@id\": \"123456781\",\n  \"@type\": \"https://didcomm.org/messagepickup/1.0/noop\"\n}\n</code></pre>"},{"location":"features/0212-pickup/#prior-art","title":"Prior art","text":"<p>Concepts here borrow heavily from a document written by Andrew Whitehead of BCGov.</p>"},{"location":"features/0212-pickup/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>We are using multiple roles to indicate which portions of the protocol are supported by each party. This is a new thing we have not done before. Is this ok?</li> </ul>"},{"location":"features/0212-pickup/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0213-transfer-policy/","title":"0213: Transfer Policy Protocol","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: PROPOSED</li> <li>Since: 2019-09-03</li> <li>Status Note: Initial version</li> <li>Start Date: 2019-09-03</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0213-transfer-policy/#summary","title":"Summary","text":"<p>A protocol to share and request changes to policy that relates to message transfer.</p>"},{"location":"features/0213-transfer-policy/#motivation","title":"Motivation","text":"<p>Explicit Policy Enables clear expectations.</p>"},{"location":"features/0213-transfer-policy/#tutorial","title":"Tutorial","text":""},{"location":"features/0213-transfer-policy/#roles","title":"Roles","text":"<p>policy_holder uses the policy to manage messages directed to the recipient. recipient the agent the policy relates to.</p>"},{"location":"features/0213-transfer-policy/#reference","title":"Reference","text":""},{"location":"features/0213-transfer-policy/#policy-publish","title":"Policy Publish","text":"<p>Used to share current policy by policy holder. This can be sent unsolicited or in response to a <code>policy_share_request</code>.</p> <pre><code>{\n  \"@id\": \"123456781\",\n  \"@type\": \"https://didcomm.org/transferpolicy/1.0/policy\",\n  \"queue_max_duration\": 86400,\n  \"message_count_limit\": 1000,\n  \"message_size_limit\": 65536,\n  \"queue_size_limit\": 65536000,\n  \"pickup_allowed\": true,\n  \"delivery_retry_count_limit\": 5,\n  \"delivery_retry_count_seconds\": 86400,\n  \"delivery_retry_backoff\": \"exponential\"\n}\n</code></pre>"},{"location":"features/0213-transfer-policy/#policy-share-request","title":"Policy Share Request","text":"<p>Used to ask for a <code>policy</code> message to be sent.</p> <pre><code>{\n  \"@id\": \"123456781\",\n  \"@type\": \"https://didcomm.org/transferpolicy/1.0/policy_share_request\"\n}\n</code></pre>"},{"location":"features/0213-transfer-policy/#policy-change-request","title":"Policy Change Request","text":"<p>Sent to request a policy change. The expected response is a <code>policy</code> message.</p> <pre><code>{\n  \"@id\": \"123456781\",\n  \"@type\": \"https://didcomm.org/transferpolicy/1.0/policy_change_request\",\n  \"queue_max_duration\": 86400,\n  \"message_count_limit\": 1000,\n  \"message_size_limit\": 65536,\n  \"queue_size_limit\": 65536000,\n  \"pickup_allowed\": true,\n  \"delivery_retry_count_limit\": 5,\n  \"delivery_retry_count_seconds\": 86400,\n  \"delivery_retry_backoff\": \"exponential\"\n}\n</code></pre> <p>Only attributes that you desire to change need to be included.</p>"},{"location":"features/0213-transfer-policy/#prior-art","title":"Prior art","text":"<p>Concepts here borrow heavily from a document written by Andrew Whitehead of BCGov.</p>"},{"location":"features/0213-transfer-policy/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the attribute list too extensive for a first pass?</li> <li>Which policy attributes should be required? Which optional?</li> </ul>"},{"location":"features/0213-transfer-policy/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0214-help-me-discover/","title":"Aries RFC 0214: \"Help Me Discover\" Protocol","text":"<ul> <li>Authors: George Aristy, Daniel Hardman</li> <li>Status: PROPOSED</li> <li>Since: 2019-09-10</li> <li>Status Note: implementation is being explored by SecureKey</li> <li>Start Date: 2018-08-20</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0214-help-me-discover/#summary","title":"Summary","text":"<p>Describes how one party can ask another party for help discovering an unknown person, organization, thing, or chunk of data.</p>"},{"location":"features/0214-help-me-discover/#motivation","title":"Motivation","text":"<p>Asking a friend to help us discover something is an extremely common human interaction: \"Dad, I need a good mechanic. Do you know one who lives near me?\"</p> <p>Similar needs exist between devices in highly automated environments, as when a drone lands in hangar and queries a dispatcher agent to find maintenance robots who can repair an ailing motor.</p> <p>We need a way to perform these workflows with DIDComm.</p>"},{"location":"features/0214-help-me-discover/#tutorial","title":"Tutorial","text":""},{"location":"features/0214-help-me-discover/#name-and-version","title":"Name and version","text":"<p>This is the \"Help Me Discover\" protocol, version 1.0. It is uniquely identified by the following PIURI:</p> <pre><code>https://didcomm.org/help-me-discover/1.0\n</code></pre>"},{"location":"features/0214-help-me-discover/#roles-and-states","title":"Roles and States","text":"<p>This protocol embodies a standard request-response pattern, and therefore has requester and responder roles. A <code>request</code> message describes what's wanted. A <code>response</code> message conveys whatever knowledge the responder wants to offer to be helpful. Standard state evolution applies:</p> <p></p> <p></p>"},{"location":"features/0214-help-me-discover/#requirements","title":"Requirements","text":"<p>The following requirements do not change this simple framework, but they introduce some complexity into the messages:</p> <ul> <li>It must be possible to describe what's wanted using rich criteria, combinable to arbitrary levels of detail with boolean operators.</li> <li>It is desirable that criteria should be expressed in a way that harmonizes with proof requests, which also need a criteria language. </li> <li>It must be possible for the responder to give partial answers: \"I do know a good mechanic, but not one that lives close to you.\"</li> <li>It must be possible for the responder to give compound answers: \"Here's an item that satisfies critiera 1 and 3, and here's a different itme that satisfies criteria 2 and 4.\"</li> <li>It must be possible for this protocol to precede another protocol (e.g., RFC 0028 Introduce Protocol) in such a way that what follows can refer back to items in this protocol in an unambiguous way, as in \"Here's an introduction to the party that I just told you about, that satisfies criteria 3 and 4 from the 'Help Me Discover' request you recently made.\"</li> </ul>"},{"location":"features/0214-help-me-discover/#messages","title":"Messages","text":""},{"location":"features/0214-help-me-discover/#request","title":"<code>request</code>","text":"<p>A simple request message looks like this:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/help-me-discover/1.0/request\",\n    \"@id\": \"a2248fb5-d46e-4898-a781-2f03e5f23964\"\n    // human-readable, localizable, optional\n    \"comment\": \"any ideas?\",\n    // please help me discover match for this\n    \"desired\": { \n        \"all\": [ // equivalent of boolean AND -- please match this list\n            // first criterion: profession must equal \"mechanic\"\n            {\"profession\": \"mechanic\", \"id\": \"prof\"},\n            // second criterion in \"all\" list: any of the following (boolean OR)\n            {\n                \"any\": [\n                    // average rating &gt; 3.5\n                    {\"averageRating\": 3.5, \"op\": \"&gt;\", \"id\": \"rating\"},\n                    // list of certifications contains \"ASE\"\n                    {\"certifications\": \"ASE\", \"op\": \"CONTAINS\", \"id\": \"cert\"},\n                    // zipCode must be in this list\n                    {\"zipCode\": [\"12345\", \"12346\"], \"op\": \"IN\", \"id\": \"where\"}\n                ], // end of \"any\" list\n                \"n\": 2, // match at least 2 from the list\n                \"id\": \"2-of-3\"\n            }\n        ],\n        \"id\": \"everything\"\n    }\n}\n</code></pre> <p>In plain language, this particular request says:</p> <p>Please help me discover someone who's a mechanic, and who possesses at least 2 of the following 3 characteristis: they have an average rating of at least 3.5 stars; they have an ASE certification; they reside in zip code 12345 or 12346.</p> <p>The data type of <code>desired</code> is a criterion object. A criterion object can be of type <code>all</code> (boolean AND), type <code>any</code> (boolean OR), or <code>op</code> (a particular attribute is tested against a value with a specific operator). The <code>all</code> and <code>any</code> objects can nest one another arbitrarily deep.</p> <p>Parsing these criteria, and performing matches against them, can be done with the SGL library, which has ports for JavaScript and python. Other ports should be trivial; it's only a couple hundred lines of code. The hardest part of the work is giving the library an object model that contains candidates against which matching can be done.</p> <p>Notice that each criterion object has an <code>id</code> property. This is helpful because responses can now refer to the criteria by number to describe what they've matched.</p> <p>See Reference for fancier examples of requests.</p>"},{"location":"features/0214-help-me-discover/#response","title":"<code>response</code>","text":"<p>A <code>response</code> message looks like this:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/help-me-discover/1.0/response\",\n    \"@id\": \"5f2396b5-d84e-689e-78a1-2fa2248f03e4\"\n    \"~thread\": { \"thid\": \"a2248fb5-d46e-4898-a781-2f03e5f23964\" }\n    // human-readable, localizable, optional\n    \"comment\": \"here's the best I've got\", \n    \"candidates\": [\n        {\n            \"id\": \"Alice\",\n            \"@type\": \"person\",\n            \"matches\": [\"prof\",\"rating\",\"cert\",\"2-of-3\",\"everything\"]\n        },\n        {\n            \"id\": \"Bob\",\n            \"@type\": \"drone\",\n            \"matches\": [\"prof\",\"cert\",\"where\",\"2-of-3\",\"everything\"]\n        },\n        {\n            \"id\": \"Carol\",\n            \"matches\": [\"rating\",\"cert\",\"where\"]\n        }\n    ]\n}\n</code></pre> <p>In plain language, this response says:</p> <p>I found 3 candidates for you. One that I'll call \"Alice\" matches everything except your <code>where</code> criterion. One called \"Bob\" matches everything except your <code>rating</code> criterion. Once called \"Carol\" matches your <code>rating</code>, <code>cert</code>, and <code>where</code> criteria, but because she didn't match <code>prof</code>, she wasn't an overall match.</p>"},{"location":"features/0214-help-me-discover/#using-a-help-me-discover-response-in-subsequent-interactions","title":"Using a \"Help me discover\" response in subsequent interactions","text":"<p>A <code>candidate</code> in a response message like the one shown above can be referenced in a subsequent interactions by using the RFC 0xxx: Linkable DIDComm Message Paths mechanism. For example, if Fred wanted to ask for an introduction to Bob after engaging in the sample request-response sequence shown above, he could send a <code>request</code> message in the Introduce Protocol, where <code>to</code> (the party to whom he'd like to be introduced) included a <code>discovered</code> property that referenced the <code>candidate</code> with <code>id</code> equal to <code>\"Bob\"</code>:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/introduce/1.0/request\",\n  \"@id\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\",\n  \"to\": {\n    \"discovered\": \"didcomm:///5f2396b5-d84e-689e-78a1-2fa2248f03e4/.candidates%7B.id+%3D%3D%3D+%22Bob%22%7D\"\n  }\n}\n</code></pre>"},{"location":"features/0214-help-me-discover/#accuracy-trustworthiness-and-best-effort","title":"Accuracy, Trustworthiness, and Best Effort","text":"<p>As with these types of interactions in \"real life\", the \"help me discover\" protocol cannot make any guarantees about the suitability of the answers it generates. The responder could be malicious, misinformed, or simply lazy. The contract for the protocol is:</p> <ul> <li>Requesters should attempt to ask reasonable, respectful, answerable questions</li> <li>Responders who wish to be helpful should make a best effort to address criteria accurately</li> <li>There is likely to be a useful relationship between what the requester asks for and what the responder provides</li> </ul> <p>The requester must verify results independently, if their need for trust is high.</p>"},{"location":"features/0214-help-me-discover/#privacy-considerations","title":"Privacy Considerations","text":"<p>Just because Alice knows that Bob is a political dissident who uses a particular handle in online forms does not mean Alice should divulge that information to anybody who engages in the \"Help Me Discover\" protocol with her. When matching criteria focus on people, Alice should be careful and use good judgment about how much she honors a particular request for discovery. In particular, if Alice possesses data about Bob that was shared with her in a previous Present Proof Protocol, the terms of sharing may not permit her to divulge what she knows about Bob to an arbitrary third party. See the Data Consent Receipt RFC.</p> <p>These issues probably do not apply when the thing being discovered is not a private individual.</p>"},{"location":"features/0214-help-me-discover/#reference","title":"Reference","text":""},{"location":"features/0214-help-me-discover/#discover-someone-who-can-prove","title":"Discover someone who can prove","text":"<p>A <code>request</code> message can ask for someone that is capable of proving using verifiable credentials, as per RFC 0037:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/help-me-discover/1.0/request\",\n    \"@id\": \"248fb52a-4898-a781-d46e-e5f239642f03\"\n    \"desired\": { \n        // either subjectRole or subjectDid:\n        //   - subjectRole has value of role in protocol\n        //   - subjectDid has value of a DID (useful in N-Wise settings)\n        \"verb\": \"prove\", \n        \"subjectRole\": \"introducer\", \n        \"car.engine.rating\": \"4\", \n        \"op\": \"&gt;\", \n        \"id\": \"engineRating\"\n    }\n}\n</code></pre> <p>In plain language, this particular request says:</p> <p>Please help me discover someone who can act as introducer in a protocol, and can prove that a car's rating &gt; 4.</p> <p>Another example might be:</p> <pre><code>{\n    \"@id\": \"a2248fb5-d46e-4898-a781-2f03e5f23964\",\n    \"@type\": \"https://didcomm.org/help-me-discover/1.0/request\",\n    \"comment\": \"blood glucose\",\n    \"desired\": {\n        \"all\": [\n            {\n                \"id\": \"prof\",\n                \"profession\": \"medical-lab\"\n            },\n            {\n                \"id\": \"glucose\",\n                \"provides\": {\n                    \"from\": \"bloodtests\",\n                    \"just\": [\n                        \"glucose\"\n                    ],\n                    \"subject\": \"did:peer:introducer\"\n                }\n            }\n        ],\n        \"id\": \"everything\"\n    }\n}\n</code></pre> <p>This says:</p> <p>Please help me discover  that has profession = \"medical-lab\" and can provide measurements of the introducer's blood-glucose levels"},{"location":"features/0214-help-me-discover/#drawbacks","title":"Drawbacks","text":"<p>If we are not careful, this protocol could be used to discover attributes about third parties in a way that subverts privacy. See Privacy Considerations.</p>"},{"location":"features/0214-help-me-discover/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Need to reconcile against general subprotocol/superprotocol communication.</li> </ul>"},{"location":"features/0214-help-me-discover/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0234-signature-decorator/","title":"Aries RFC 0234: Signature Decorator","text":"<ul> <li>Authors: Kyle Den Hartog</li> <li>Status: RETIRED</li> <li>Since: 2020-10-14</li> <li>Status Note: This decorator is retired, replaced with the use of the signed form of the attachment decorator (RFC 0017)</li> <li>Supersedes: this HIPE (never merged)</li> <li>Start Date: 2019-01-07</li> <li>Tags: feature, decorator</li> </ul>"},{"location":"features/0234-signature-decorator/#rfc-archived","title":"RFC ARCHIVED","text":"<p>DO NOT USE THIS RFC.</p> <p>Use the signed form of the attachment decorator (RFC 0017) instead of this decorator.</p>"},{"location":"features/0234-signature-decorator/#summary","title":"Summary","text":"<p>The <code>~sig</code> field-level decorator enables non-repudiation by allowing an Agent to add a digital signature over a portion of a DIDComm message.</p>"},{"location":"features/0234-signature-decorator/#motivation","title":"Motivation","text":"<p>While today we support a standard way of authenticating messages in a repudiable way, we also see the need for non-repudiable digital signatures for use cases where high authenticity is necessary such as signing a bank loan. There's additional beneficial aspects around having the ability to prove provenance of a piece of data with a digital signature. These are all use cases which would benefit from a standardized format for non-repudiable digital signatures.</p> <p>This RFC outlines a field-level decorator that can be used to provide non-repudiable digital signatures in DIDComm messages. It also highlights a standard way to encode data such that it can be deterministically verified later.</p>"},{"location":"features/0234-signature-decorator/#tutorial","title":"Tutorial","text":"<p>This RFC introduces a new field-level decorator named <code>~sig</code> and maintains a registry of standard Signature Schemes applicable with it.</p> <p>The <code>~sig</code> field decorator may be used with any field of data. Its value MUST match the json object format of the chosen signature scheme. </p> <p>We'll use the following message as an example:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/example/1.0/test_message\",\n    \"@id\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\",\n    \"msg\": {\n        \"text\": \"Hello World!\",\n        \"speaker\": \"Bob\"\n    }\n}\n</code></pre> <p>Digitally signing the <code>msg</code> object with the <code>ed25519sha256_single</code> scheme results in a transformation of the original message to this:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/example/1.0/test_message\",\n    \"@id\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\",\n    \"msg~sig\": {\n      \"@type\": \"https://didcomm.org/signature/1.0/ed25519Sha512_single\",\n      \"sig_data\": \"base64URL(64bit_integer_from_unix_epoch|msg_object)\",\n      \"signature\": \"base64URL(digital signature function output)\",\n      \"signer\": \"base64URL(inlined_signing_verkey)\"\n    }\n}\n</code></pre> <p>The original <code>msg</code> object has been replaced with its <code>~sig</code>-decorated counterpart in order to prevent message bloat.</p> <p>When an Agent receives a DIDComm message with a field decorated with <code>~sig</code>, it runs the appropriate signature scheme algorithm and restores the DIDComm message's structure back to its original form.</p>"},{"location":"features/0234-signature-decorator/#reference","title":"Reference","text":""},{"location":"features/0234-signature-decorator/#applying-the-digital-signature","title":"Applying the digital signature","text":"<p>In general, the steps to construct a <code>~sig</code> are:</p> <ol> <li>Choose a signature scheme. This determines the <code>~sig</code> decorator's message type URI (the <code>@type</code> seen above) and the signature algorithm.</li> <li>Serialize the JSON object to be authenticated to a sequence of bytes (<code>msg</code> in the example above). This will be the plaintext input to the signature scheme.</li> <li>Construct the contents of the new <code>~sig</code> object according to the chosen signature scheme with the plaintext as input.</li> <li>Replace the original object (<code>msg</code> in the example above) with the new <code>~sig</code> object. The new object's label MUST be equal to the label of the original object appended with \"~sig\".</li> </ol>"},{"location":"features/0234-signature-decorator/#verifying-the-digital-signature","title":"Verifying the digital signature","text":"<p>The outcome of a successful signature verification is the replacement of the <code>~sig</code>-decorated object with its original representation:</p> <ol> <li>Select the signature scheme according to the message type URI (<code>ed25519sha256_single</code> in the example above)</li> <li>Run the signature scheme's verification algorithm with the <code>~sig</code>-decorated object as input.</li> <li>The software MUST cease further processing of the DIDComm message if the verification algorithm fails.</li> <li>Replace the <code>~sig</code>-decorated object with the output of the scheme's verification algorithm.</li> </ol> <p>The end result MUST be semantically identical to the original DIDComm message before application of the signature scheme (eg. the original example message above).</p>"},{"location":"features/0234-signature-decorator/#additional-considerations","title":"Additional considerations","text":"<p>The data to authenticate is base64URL-encoded and then embedded as-is so as to prevent false negative signature verifications that could potentially occur when sending JSON data which has no easy way to canonicalize the structure. Rather, by including the exact data in Base64URL encoding, the receiver can be certain that the data signed is the same as what was received. </p>"},{"location":"features/0234-signature-decorator/#signature-schemes","title":"Signature Schemes","text":"<p>This decorator should support a specific set of signatures while being extensible. The list of current supported schemes are outlined below.</p> Signature Scheme Scheme Spec ed25519Sha512_single spec <p>TODO provide template in this RFC directory. </p> <p>To add a new signature scheme to this registry, follow the template provided to detail the new scheme as well as provide some test cases to produce and verify the signature scheme is working.</p>"},{"location":"features/0234-signature-decorator/#drawbacks","title":"Drawbacks","text":"<p>Since digital signatures are non-repudiable, it's worth noting the privacy implications of using this functionality. In the event that a signer has chosen to share a message using a non-repudiable signature, they forgo the ability to prevent the verifier from sharing this signature on to other parties. This has potentially negative implications with regards to consent and privacy. </p> <p>Therefore, this functionality should only be used if non-repudiable digital signatures are absolutely necessary.</p>"},{"location":"features/0234-signature-decorator/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>JSON Web Signatures are an alternative to this specification in widespread use. We diverged from this specification for the following reasons:</p> <ul> <li>Does not support our need for message decorators (sign only parts of a DIDComm message)</li> <li>Does not support signature-aggregation featured in schemes like BLS signatures.</li> </ul>"},{"location":"features/0234-signature-decorator/#prior-art","title":"Prior art","text":"<p>IETF RFC 7515 (JSON Web Signatures)</p>"},{"location":"features/0234-signature-decorator/#unresolved-questions","title":"Unresolved questions","text":"<p>Does there need to be an signature suite agreement protocol similar to TLS cipher suites? - No, rather the receiver of the message can send an error response if they're unable to validate the signature.</p> <p>How should multiple signatures be represented? - While not supported in this version, one solution would be to support <code>[digital_sig1, digital_sig2]</code> for <code>signature</code> and <code>[verkey1, verkey2]</code> for <code>signer</code>.</p>"},{"location":"features/0234-signature-decorator/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Static Agent - Python <code>ed25519sha256_single</code> Aries Framework - .NET <code>ed25519sha256_single</code> Aries Framework - Go <code>ed25519sha256_single</code>"},{"location":"features/0234-signature-decorator/ed25519sha256_single/","title":"The <code>ed25519sha256_single</code> signature scheme","text":""},{"location":"features/0234-signature-decorator/ed25519sha256_single/#tutorial","title":"Tutorial","text":""},{"location":"features/0234-signature-decorator/ed25519sha256_single/#application","title":"Application","text":"<p>This scheme computes a single ed25519 digital signature over the input message. Its output is a <code>~sig</code> object with the following contents:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/signature/1.0/ed25519Sha512_single\",\n    \"sig_data\": \"base64URL(64bit_integer_from_unix_epoch|msg)\",\n    \"signature\": \"base64URL(ed25519 signature)\",\n    \"signer\": \"base64URL(inlined_ed25519_signing_verkey)\"\n}\n</code></pre> <ul> <li><code>@type</code> MUST be <code>https://didcomm.org/signature/1.0/ed25519Sha512_single</code></li> <li><code>sig_data</code> MUST be the base64URL encoding of a 64-bit integer prepended to the message</li> <li><code>signature</code> MUST be the base64URL encoding of the resulting ed25519 digital signature over <code>sig_data</code></li> <li><code>signer</code> MUST be the base64URL encoding of the corresponding ed25519 public key used to sign <code>sig_data</code></li> </ul>"},{"location":"features/0234-signature-decorator/ed25519sha256_single/#verification","title":"Verification","text":"<p>The successful outcome of this scheme is the <code>plaintext</code>.</p> <ol> <li>base64URL-decode <code>signer</code></li> <li>base64URL-decode <code>signature</code></li> <li>Verify the ed25519 signature over <code>sig_data</code> with the key provided in <code>signer</code></li> <li>Further processing is halted if verification fails and an \"authentication failure\" error is returned</li> <li>base64URL-decode the <code>sig_data</code></li> <li>Strip out the first 8 bytes</li> <li>Return the remaining bytes</li> </ol>"},{"location":"features/0249-rich-schema-contexts/","title":"Aries RFC 0249: Aries Rich Schema Contexts","text":"<ul> <li>Authors: Brent Zundel, Ken Ebert, Alexander Shcherbakov</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes: </li> <li>Start Date: 2019-06-07 </li> <li>Tags: feature, rich-schemas</li> </ul>"},{"location":"features/0249-rich-schema-contexts/#summary","title":"Summary","text":"<p>Every rich schema object may have an associated <code>@context</code>. Contexts are JSON or JSON-LD objects. They are the standard mechanism for defining shared semantic meaning among rich schema objects.</p> <p>Context objects are processed in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0249-rich-schema-contexts/#motivation","title":"Motivation","text":"<p><code>@context</code> is JSON-LD\u2019s namespacing mechanism. Contexts allow rich schema objects to use a common vocabulary when referring to common attributes, i.e. they provide an explicit shared semantic meaning.</p>"},{"location":"features/0249-rich-schema-contexts/#tutorial","title":"Tutorial","text":""},{"location":"features/0249-rich-schema-contexts/#intro-to-context","title":"Intro to @context","text":"<p><code>@context</code> is a JSON-LD construct that allows for namespacing and the establishment of a common vocabulary.</p> <p>Context object is immutable, so it's not possible to update existing Context,  If the Context needs to be evolved, a new Context with a new version or name needs to be created.</p> <p>Context object may be stored in either JSON or JSON-LD format.</p>"},{"location":"features/0249-rich-schema-contexts/#example-context","title":"Example Context","text":"<p>An example of the <code>content</code> field of a Context object: <pre><code>{\n    \"@context\": [\n        \"did:sov:UVj5w8DRzcmPVDpUMr4AZhJ\",\n        \"did:sov:JjmmTqGfgvCBnnPJRas6f8xT\",\n        \"did:sov:3FtTB4kzSyApkyJ6hEEtxNH4\",\n        {\n            \"dct\": \"http://purl.org/dc/terms/\",\n            \"rdf\": \"http://www.w3.org/1999/02/22-rdf-syntax-ns#\",\n            \"rdfs\": \"http://www.w3.org/2000/01/rdf-schema#\",\n            \"Driver\": \"did:sov:2mCyzXhmGANoVg5TnsEyfV8\",\n            \"DriverLicense\": \"did:sov:36PCT3Vj576gfSXmesDdAasc\",\n            \"CategoryOfVehicles\": \"DriverLicense:CategoryOfVehicles\"\n        }\n    ]\n}\n</code></pre></p>"},{"location":"features/0249-rich-schema-contexts/#data-registry-storage","title":"Data Registry Storage","text":"<p>Aries will provide a means for writing contexts to and reading contexts from a verifiable data registry (such as a distributed ledger).</p> <p><code>@context</code> will be written to the ledger in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0249-rich-schema-contexts/#aries-data-registry-interface","title":"Aries Data Registry Interface","text":"<p>Aries Data Registry Interface methods for adding and retrieving <code>@context</code> from the ledger comply with the generic approach described in Rich Schema Objects Common.</p> <p>This means the following methods can be used: - <code>write_rich_schema_object</code> - <code>read_rich_schema_object_by_id</code> - <code>read_rich_schema_object_by_metadata</code></p>"},{"location":"features/0249-rich-schema-contexts/#reference","title":"Reference","text":"<p>More information on the Verifiable Credential data model use of <code>@context</code> may be found here.</p> <p>More information on <code>@context</code> from the JSON-LD specification may be found here and here.</p> <ul> <li>0250: Rich Schema Objects</li> <li>0420: Rich Schema Objects Common </li> </ul>"},{"location":"features/0249-rich-schema-contexts/#drawbacks","title":"Drawbacks","text":"<p>Requiring a <code>@context</code> for each rich schema object introduces more complexity.</p>"},{"location":"features/0249-rich-schema-contexts/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>A context object is required by the W3C Verifiable Credentials Data Model specification.</li> <li>It also supports rich schema capabilities for credentials.</li> </ul>"},{"location":"features/0249-rich-schema-contexts/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the proposed interface generic enough to support other data registries?</li> <li>We are not defining Rich Schema objects as DID DOCs for now. We may re-consider this in future once DID DOC format is finalized.</li> <li>It may make sense to extend DID specification to include using DID for referencing Rich Schema objects.</li> <li>The proposed canonicalization form of a content to be used for DID's id-string generation is in a Draft version, so we  may find a better way to do it.</li> <li>We don't check if the specified <code>@context</code> is valid by resolving all external links. </li> </ul>"},{"location":"features/0249-rich-schema-contexts/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0281-rich-schemas/","title":"Aries RFC 0281: Aries Rich Schemas","text":"<ul> <li>Authors: Brent Zundel, Ken Ebert, Alexander Shcherbakov</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes: </li> <li>Start Date: 2019-06-07 </li> <li>Tags: feature, rich-schemas</li> </ul>"},{"location":"features/0281-rich-schemas/#summary","title":"Summary","text":"<p>The proposed schemas are JSON-LD objects. This allows credentials issued according to the proposed schemas to have a clear semantic meaning, so that the verifier can know what the issuer intended. They support explicitly typed properties and semantic inheritance. A schema may include other schemas as property types, or extend another schema with additional properties. For example a schema for \"employee\" may inherit from the schema for \"person.\"</p> <p>Schema objects are processed in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0281-rich-schemas/#motivation","title":"Motivation","text":"<p>Many organizations, such as HL7 who publish the FHIR standard for heath care data exchange, have invested time and effort into creating data schemas that are already in use. Many schemas are shared publicly via web sites such as https://schema.org/, whose mission is, \"to create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond.\"</p> <p>These schemas ought to be usable as the basis for verifiable credentials.</p> <p>Although verifiable credentials are the primary use case for schemas considered in this document, other future uses may include defining message formats or objects in a verifiable data registry.  </p>"},{"location":"features/0281-rich-schemas/#interoperability","title":"Interoperability","text":"<p>Existing applications make use of schemas to organize and semantically describe data. Using those same schemas within Aries verifiable credentials provides a means of connecting existing applications with this emerging technology. This allows for an easy migration path for those applications to incorporate verifiable credentials and join the Aries ecosystem.</p> <p>Aries is only one of several verifiable credentials ecosystems. Using schemas which may be shared among these ecosystems allows for semantic interoperability between them, and enables a path toward true multi-lateral credential exchange.</p> <p>Using existing schemas, created in accordance with widely-supported common standards, allows Aries verifiable credentials to benefit from the decades of effort and thought that went into those standards and to work with other applications which also adhere to those standards.</p>"},{"location":"features/0281-rich-schemas/#re-use","title":"Re-use","text":"<p>Rich schemas can be re-used within the Aries credential ecosystem. Because these schemas are hierarchical and composable, even unrelated schemas may share partial semantic meaning due to the commonality of sub-schemas within both. For example, a driver license schema and an employee record are not related schemas, but both may include a person schema.</p> <p>A schema that was created for a particular use-case and accepted within a trust framework may be re-used within other trust frameworks for their use-cases. The visibility of these schemas across trust boundaries increases the ability of these schemas to be examined in greater detail and evaluated for fitness of purpose. Over time the schemas will gain reputation. </p>"},{"location":"features/0281-rich-schemas/#extensibility","title":"Extensibility","text":"<p>Applications that are built on top of the Aries frameworks can use these schemas as a basis for complex data objects for use within the application, or exposed through external APIs.</p>"},{"location":"features/0281-rich-schemas/#immutability","title":"Immutability","text":"<p>One important aspect of relying on schemas to provide the semantic meaning of data within a verifiable credential, is that the meaning of the credential properties should not change. It is not enough for entities within the ecosystem to have a shared understanding of the data in the present, it may be necessary for them to have an understanding of the credential at the time it was issued and signed. This depends on the trust framework within which the credential was issued and the needs of the parties involved. A verifiable data registry can provide immutable storage of schemas.</p>"},{"location":"features/0281-rich-schemas/#tutorial","title":"Tutorial","text":""},{"location":"features/0281-rich-schemas/#intro-to-schemas","title":"Intro to Schemas","text":"<p><code>schema</code> objects are used to enforce structure and semantic meaning on a set of data. They allow Issuers to assert, and Holders and Verifiers to understand, a particular semantic meaning for the properties in a credential.</p> <p>Rich schemas are JSON-LD objects. Examples of the type of schemas supported here may be found at schema.org. At this time we do not support other schema representations such as RDFS, JSON Schema, XML Schema, OWL, etc.</p>"},{"location":"features/0281-rich-schemas/#properties","title":"Properties","text":"<p>Rich Schema properties follow the generic template defined in Rich Schema Common.</p> <p>Rich Schema's <code>content</code> field is a JSON-LD-serialized string with the following fields:</p>"},{"location":"features/0281-rich-schemas/#id","title":"@id","text":"<p>A rich schema must have an <code>@id</code> property. The value of this property must be equal to the <code>id</code> field which is a DID (see Identification of Rich Schema Objects). </p> <p>A rich schema may refer to the <code>@id</code> of another rich schema to define a parent schema. A property of a rich schema may use the <code>@id</code> of another rich schema as the value of its <code>@type</code> or <code>@id</code> property.</p> <p>A mapping object will contain the <code>@id</code> of the rich schema being mapped.</p> <p>A presentation definition will contain the <code>@id</code> of any schemas a holder may use to present proofs to a verifier.</p>"},{"location":"features/0281-rich-schemas/#type","title":"@type","text":"<p>A rich schema must have a <code>@type</code> property. The value of this property must be (or map to, via a context object) a URI. </p>"},{"location":"features/0281-rich-schemas/#context","title":"@context","text":"<p>A rich schema may have a <code>@context</code> property. If present, the value of this property must be a context object or a URI which can be dereferenced to obtain a context object.</p>"},{"location":"features/0281-rich-schemas/#use-in-verifiable-credentials","title":"Use in Verifiable Credentials","text":"<p>These schemas will be used in conjunction with the JSON-LD representation of the verifiable credentials data model to specify which properties may be included as part of the verifiable credential's <code>credentialSubject</code> property, as well as the types of the property values.</p> <p>The <code>@id</code> of a rich schema may be used as an additional value of the  type property property of a verifiable credential. Because the <code>type</code> values of a verifiable credential are not required to be dereferenced, in order for the rich schema to support assertion of the structure and semantic meaning of the claims in the credential, an additional reference to the rich schema should be made through the  credentialSchema property. This may be done as a direct reference to the rich schema <code>@id</code>, or via another rich schema object which references the rich schema <code>@id</code> such as a  credential definition  as would  be the case  for anonymous credentials, as discussed in the mapping section of the rich schema overview RFC.</p>"},{"location":"features/0281-rich-schemas/#data-registry-storage","title":"Data Registry Storage","text":"<p>Aries will provide a means for writing <code>schema</code> objects to and reading <code>schema</code> objects from a verifiable data registry (such as a distributed ledger).</p> <p>As discussed previously, the ability to specify the exact schema that was used to issue a verifiable credential, and the assurance  that the meaning of that schema has not changed, may be critical for the trust framework. Verifiable data registries which provide immutability guarantees provide this assurance. Some alternative storage mechanisms do not. Hashlinks, which may be used to verify the hash of web-based schemas, are one example. These can be used inform a verifier that a schema has changed, but do not provide access to the original version of the schema in the event the original schema has been updated.</p>"},{"location":"features/0281-rich-schemas/#example-schema","title":"Example Schema","text":"<p>An example of the <code>content</code> field of a Rich Schema object: <pre><code>   \"@id\": \"did:sov:2f9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n   \"@type\": \"rdfs:Class\",\n   \"@context\": {\n    \"schema\": \"http://schema.org/\",\n    \"bibo\": \"http://purl.org/ontology/bibo/\",\n    \"dc\": \"http://purl.org/dc/elements/1.1/\",\n    \"dcat\": \"http://www.w3.org/ns/dcat#\",\n    \"dct\": \"http://purl.org/dc/terms/\",\n    \"dcterms\": \"http://purl.org/dc/terms/\",\n    \"dctype\": \"http://purl.org/dc/dcmitype/\",\n    \"eli\": \"http://data.europa.eu/eli/ontology#\",\n    \"foaf\": \"http://xmlns.com/foaf/0.1/\",\n    \"owl\": \"http://www.w3.org/2002/07/owl#\",\n    \"rdf\": \"http://www.w3.org/1999/02/22-rdf-syntax-ns#\",\n    \"rdfa\": \"http://www.w3.org/ns/rdfa#\",\n    \"rdfs\": \"http://www.w3.org/2000/01/rdf-schema#\",\n    \"schema\": \"http://schema.org/\",\n    \"skos\": \"http://www.w3.org/2004/02/skos/core#\",\n    \"snomed\": \"http://purl.bioontology.org/ontology/SNOMEDCT/\",\n    \"void\": \"http://rdfs.org/ns/void#\",\n    \"xsd\": \"http://www.w3.org/2001/XMLSchema#\",\n    \"xsd1\": \"hhttp://www.w3.org/2001/XMLSchema#\"\n  },\n  \"@graph\": [\n    {\n      \"@id\": \"schema:recipeIngredient\",\n      \"@type\": \"rdf:Property\",\n      \"rdfs:comment\": \"A single ingredient used in the recipe, e.g. sugar, flour or garlic.\",\n      \"rdfs:label\": \"recipeIngredient\",\n      \"rdfs:subPropertyOf\": {\n        \"@id\": \"schema:supply\"\n      },\n      \"schema:domainIncludes\": {\n        \"@id\": \"schema:Recipe\"\n      },\n      \"schema:rangeIncludes\": {\n        \"@id\": \"schema:Text\"\n      }\n    },\n    {\n      \"@id\": \"schema:ingredients\",\n      \"schema:supersededBy\": {\n        \"@id\": \"schema:recipeIngredient\"\n      }\n    }\n  ]\n</code></pre> recipeIngredient schema from  schema.org.</p>"},{"location":"features/0281-rich-schemas/#data-registry-storage_1","title":"Data Registry Storage","text":"<p>Aries will provide a means for writing contexts to and reading contexts from a verifiable data registry (such as a distributed ledger).</p> <p>A Schema will be written to the ledger in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0281-rich-schemas/#aries-data-registry-interface","title":"Aries Data Registry Interface","text":"<p>Aries Data Registry Interface methods for adding and retrieving a Schema from the ledger comply with the generic approach described in Rich Schema Objects Common.</p> <p>This means the following methods can be used: - <code>write_rich_schema_object</code> - <code>read_rich_schema_object_by_id</code> - <code>read_rich_schema_object_by_metadata</code></p>"},{"location":"features/0281-rich-schemas/#reference","title":"Reference","text":"<p>More information on the Verifiable Credential data model use of <code>schemas</code> may be found here.</p> <ul> <li>0250: Rich Schema Objects</li> <li>0420: Rich Schema Objects Common </li> </ul>"},{"location":"features/0281-rich-schemas/#drawbacks","title":"Drawbacks","text":"<p>Rich schema objects introduce more complexity.</p>"},{"location":"features/0281-rich-schemas/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>A <code>schema</code> object is supported by the W3C Verifiable Credentials Data Model specification.</li> <li>It supports rich schema capabilities for credentials.</li> </ul>"},{"location":"features/0281-rich-schemas/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the proposed interface generic enough to support other data registries?</li> <li>We are not defining Rich Schema objects as DID DOCs for now. We may re-consider this in future once DID DOC format is finalized.</li> <li>It may make sense to extend DID specification to include using DID for referencing Rich Schema objects.</li> <li>The proposed canonicalization form of a content to be used for DID's id-string generation is in a Draft version, so we  may find a better way to do it.</li> <li>We don't check if the specified <code>@context</code> is valid by resolving all external links.</li> <li>We may introduce more discovery ../../features in future.</li> <li>Future work may include methods for anchoring to Indy a Rich Schema which is immutably stored elsewhere.</li> </ul>"},{"location":"features/0281-rich-schemas/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0303-v01-credential-exchange/","title":"Aries RFC 0303: V0.1 Credential Exchange (Deprecated)","text":"<ul> <li>Authors: Tomislav Markovski, Andrew Whitehead, Stephen Curran</li> <li>Status: RETIRED</li> <li>Since: 2019-11-12</li> <li>Status Note: Deprecated, but in common use in existing deployments of Aries agents. See Implementations </li> <li>Supersedes: HackMD Document</li> <li>Start Date: 2019-03-13</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0303-v01-credential-exchange/#summary","title":"Summary","text":"<p>The 0.1 version of the ZKP Credential Exchange protocol (based on Hyperledger Indy) covering both issuing credentials and presenting proof. These messages were implemented to enable demonstrating credential exchange amongst interoperating agents for IIW 28 in Mountain View, CA. The use of these message types continues to today (November 2019) and so they are being added as an RFC for historical completeness and to enable reference in Aries Interop Profile.</p>"},{"location":"features/0303-v01-credential-exchange/#motivation","title":"Motivation","text":"<p>Enables the exchange of Indy ZKP-based verifiable credentials - issuing verifiable credentials and proving claims from issued verifiable credentials.</p>"},{"location":"features/0303-v01-credential-exchange/#tutorial","title":"Tutorial","text":"<p>This RFC defines a minimal credential exchange protocols. For more details of a complete credential exchange protocol, see the Issue Credentials and Present Proof RFCs.</p>"},{"location":"features/0303-v01-credential-exchange/#issuing-a-credential","title":"Issuing a credential:","text":"<ol> <li>The issuer sends the holder a Credential Offer</li> <li>The holder responds with a Credential Request to the issuer</li> <li>The issuer sends a Credential Issue to the holder, issuing the credential</li> </ol>"},{"location":"features/0303-v01-credential-exchange/#presenting-a-proof","title":"Presenting a proof:","text":"<ol> <li>The verifier sends the holder/prover a Proof Request</li> <li>The holder/prover constructs a proof to satisfy the proof requests and sends the proof to the verifier</li> </ol>"},{"location":"features/0303-v01-credential-exchange/#reference","title":"Reference","text":"<p>The following messages are supported in this credential exchange protocol.</p>"},{"location":"features/0303-v01-credential-exchange/#issue-credential-protocol","title":"Issue Credential Protocol","text":"<p>The process begins with a <code>credential-offer</code>. The thread decorator is implied for all messages except the first.</p> <p>The  element is used in most messages and is the string returned from libindy for the given purpose - an escaped JSON string. The agent must process the string if there is a need to extract a data element from the JSON - for example to get the <code>cred-def-id</code> from the <code>credential-offer</code>. <p>Acknowledgments and Errors should be signalled via adopting the standard <code>ack</code> and <code>problem-report</code> message types, respectively.</p>"},{"location":"features/0303-v01-credential-exchange/#credential-offer","title":"Credential Offer","text":"<pre><code>{\n    \"@type\": \"https://didcomm.org/credential-issuance/0.1/credential-offer\",\n    \"@id\": \"&lt;uuid-offer&gt;\",\n    \"comment\": \"some comment\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"offer_json\": &lt;libindy json string&gt;\n}\n</code></pre>"},{"location":"features/0303-v01-credential-exchange/#credential-request","title":"Credential Request","text":"<pre><code>{\n    \"@type\": \"https://didcomm.org/credential-issuance/0.1/credential-request\",\n    \"@id\": \"&lt;uuid-request&gt;\",\n    \"comment\": \"some comment\",\n    \"request\": &lt;libindy json string&gt;\n}\n</code></pre>"},{"location":"features/0303-v01-credential-exchange/#credential-issue","title":"Credential Issue","text":"<pre><code>{\n    \"@type\": \"https://didcomm.org/credential-issuance/0.1/credential-issue\",\n    \"@id\": \"&lt;uuid-credential&gt;\",\n    \"issue\": &lt;libindy json string&gt;\n}\n</code></pre>"},{"location":"features/0303-v01-credential-exchange/#presentation-protocol","title":"Presentation Protocol","text":"<p>The message family to initiate a presentation. The verifier initiates the process. The thread decorator is implied on every message other than the first message. The <code>ack</code> and <code>problem-report</code> messages are to be adopted by this message family.</p>"},{"location":"features/0303-v01-credential-exchange/#presentation-request","title":"Presentation Request","text":"<pre><code>{\n    \"@type\": \"https://didcomm.org/credential-presentation/0.1/presentation-request\",\n    \"@id\": \"&lt;uuid-request&gt;\",\n    \"comment\": \"some comment\",\n    \"request\": &lt;libindy json string&gt;\n}\n</code></pre>"},{"location":"features/0303-v01-credential-exchange/#credential-presentation","title":"Credential Presentation","text":"<pre><code>{\n    \"@type\": \"https://didcomm.org/credential-presentation/0.1/credential-presentation\",\n    \"@id\": \"&lt;uuid-presentation&gt;\",\n    \"comment\": \"some comment\",\n    \"presentation\": &lt;libindy json string&gt;\n}\n</code></pre>"},{"location":"features/0303-v01-credential-exchange/#drawbacks","title":"Drawbacks","text":"<p>The RFC is not technically needed, but is useful to have as an Archived RFC of a feature in common usage.</p>"},{"location":"features/0303-v01-credential-exchange/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>N/A</p>"},{"location":"features/0303-v01-credential-exchange/#prior-art","title":"Prior art","text":"<p>N/A</p>"},{"location":"features/0303-v01-credential-exchange/#unresolved-questions","title":"Unresolved questions","text":"<p>N/A</p>"},{"location":"features/0303-v01-credential-exchange/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Framework - .NET .NET framework for building agents of all types; MISSING test results Streetcred.id Commercial mobile and web app built using Aries Framework - .NET; MISSING test results Aries Cloud Agent - Python Contributed by the government of British Columbia.; MISSING test results OSMA - Open Source Mobile Agent Open SOurce mobile app built on Aries Framework - .NET; MISSING test results"},{"location":"features/0309-didauthz/","title":"Aries RFC 0309: DIDAuthZ","text":"<ul> <li>Authors: George Aristy SecureKey Technologies</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes:</li> <li>Start Date: 2019-09-27</li> <li>Tags: feature, credentials</li> </ul>"},{"location":"features/0309-didauthz/#summary","title":"Summary","text":"<p>DIDAuthZ is an attribute-based resource discovery and authorization protocol for Layer 2 of the ToIP Stack<sup>[1]</sup>. It enables a requesting party to discover protected resources and obtain credentials that grant limited access to these resources with the authorization of their owner. These credentials can be configured such that the requesting party may further delegate unto others the authority to access these resources on their behalf.</p>"},{"location":"features/0309-didauthz/#motivation","title":"Motivation","text":"<p>In the online world, individuals frequently consent to a service provider gaining access to their protected resources located on a different service provider. Individuals are challenged with an authentication mechanism, informed of the resources being requested, consent to the use of their resources, and can later revoke access at any time. OAuth 2.0<sup>[6]</sup>, and other frameworks built on top of it, were developed to address this need.</p> <p>A DIDComm protocol<sup>[2]</sup> can address these use cases and enhance them with secure end-to-end encryption<sup>[3]</sup> independent of the transport used. The risk of correlation of the individual's relationships with other parties can be mitigated with the use of peer DIDs<sup>[4]</sup>. With a sufficiently flexible grammar, the encoding of the access scope can be fine-grained down to the individual items that are requested, congruent with the principle of selective disclosure<sup>[5]</sup>.</p> <p>It is expected that future higher-level protocols and governance frameworks<sup>[1]</sup> can leverage DIDAuthZ to enable authorized sharing of an identity owner's attributes held by a third party.</p>"},{"location":"features/0309-didauthz/#tutorial","title":"Tutorial","text":""},{"location":"features/0309-didauthz/#roles","title":"Roles","text":"<p>DIDAuthZ adapts the following roles from OAuth 2.0<sup>[6]</sup> and UMA 2.0<sup>[7]</sup>:</p> Resource Server (RS) An agent holding the protected resources. These resources MAY be credentials of which the subject MAY be a third party identity owner. The RS is also a resource owner at the root of the chain of delegation. Resource Owner (RO) An agent capable of granting access to a protected resource. The RO is a delegate of the RS to the extent encoded in a credential issued by the RS. Authorization Server (AS) An agent that protects, on the resource owner's behalf, resources held by the resource server. The AS is a delegate of the RO capable of issuing and refreshing access credentials. Requesting Party (RP) An agent that requests access to the resources held by the resource server. The RP is a delegate of the AS to the extent encoded in a credential issued by the AS. <p></p>"},{"location":"features/0309-didauthz/#transaction-flow","title":"Transaction Flow","text":"<p>The requesting party initiates a transaction by communicating directly with the authorization server with prior knowledge of their location.</p> <p></p> <p>(1) RP requests a resource</p> <p>The requesting party requests the authorization server for a resource. A description of the resource requested and the desired access is included in this request.</p> <p>TODO does the request need to also include proof of \"user engagement\"?</p> <p>(2) AS requests authorization from the RO</p> <p>The authorization server processes the request and determines if the resource owner's authorization is needed. The authorization server MUST obtain the resource owner's authorization if no previous grant of authorization is found in valid state. Otherwise, the authorization server MAY issue new access credentials to the requesting party without any interaction with the resource owner. In such a case, the authorization server MUST revoke all access credentials previously issued to the requesting party.</p> <p>The authorization server interacts with the resource owner through their existing DIDComm connection to obtain their authorization.</p> <p>(3) AS issues an access token to the RP</p> <p>The authorization server issues access credentials to the requesting party.</p> <p>(4) AS introduces the RP to the RS</p> <p>The authorization server connects the requesting party to the resource server via the Introduce Protocol<sup>[9]</sup>.</p>"},{"location":"features/0309-didauthz/#access-credentials","title":"Access Credentials","text":"<p>Access credentials are chained delegate credentials<sup>[17]</sup> used to access the protected resources. Embedded in them is proof of the chain of delegation and authorization.</p> <p></p> <p>(1) RS delegates unto RO</p> <p>The resource server issues a credential to the resource owner that identifies the latter as the owner of a subset of resources hosted by the former. It also identifies the resource owner's chosen authorization server in their respective role. The resources will also have been registered at the authorization server.</p> <p>(2) RO delegates unto AS</p> <p>The resource owner issues a grant-type credential to the authorization server at the end of each AS-RO interaction. This credential is derived from the one issued by the RS. It authorizes the AS to authorize access to the RP with a set scope.</p> <p>(3) AS issues access credential to RP</p> <p>The authorization server issues an access credential to the requesting party derived from the grant credential issued by the resource owner for this transaction. This credential encodes the same access scope as found in the parent credential.</p> <p>(4) RP presents proof of access credential to RS</p> <p>The requesting party shows proof of this access credential when attempting to access the resource on the resource server.</p>"},{"location":"features/0309-didauthz/#revocation","title":"Revocation","text":"<p>The resource server makes available a revocation registry and grants read/write access to both the resource owner and the authorization server.</p> <p></p>"},{"location":"features/0309-didauthz/#reference","title":"Reference","text":""},{"location":"features/0309-didauthz/#discovery-of-authorization-servers","title":"Discovery of authorization servers","text":"<p>The resource owner advertises their chosen authorization server to other parties with a new type of <code>service</code> definition in their DID document<sup>[8]</sup>:</p> <pre><code>{\n  \"@context\": [\"https://www.w3.org/ns/did/v1\", \"https://w3id.org/security/v1\"],\n  \"id\": \"did:example:123456789abcdefghi\",\n  \"publicKey\": [{\n    \"id\": \"did:example:123456789abcdefghi#keys-1\",\n    \"type\": \"Ed25519VerificationKey2018\",\n    \"controller\": \"did:example:123456789abcdefghi\",\n    \"publicKeyBase58\": \"H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV\"\n  }],\n  \"service\": [{\n    \"id\": \"did:example:123456789abcdefghi#did-authz\",\n    \"type\": \"did-authz\",\n    \"serviceEndpoint\": \"did:example:xyzabc456#auth-svc\"\n  }]\n}\n</code></pre> <p>TODO define json-ld context for new service type</p> <p>The mechanisms by which the resource owner discovers authorization servers are beyond the scope of this specification.</p> <p>Authorization servers MUST make available a DID document containing metadata about their service endpoints and capabilities at a well-known location.</p> <p>TODO define \"well-known locations\" in several transports</p> <p>TODO register well-known URI for http transport as per IETF RFC 5785</p>"},{"location":"features/0309-didauthz/#discovery-of-revocation-registry","title":"Discovery of revocation registry","text":"<p>TODO</p>"},{"location":"features/0309-didauthz/#resources","title":"Resources","text":""},{"location":"features/0309-didauthz/#describing-resources","title":"Describing resources","text":"<p>TODO</p>"},{"location":"features/0309-didauthz/#describing-access-scope","title":"Describing access scope","text":"<p>TODO</p>"},{"location":"features/0309-didauthz/#registering-resources","title":"Registering resources","text":"<p>TODO</p>"},{"location":"features/0309-didauthz/#requesting-resources","title":"Requesting resources","text":"<p>TODO</p>"},{"location":"features/0309-didauthz/#protocol-messages","title":"Protocol messages","text":"<p>TODO</p>"},{"location":"features/0309-didauthz/#gathering-consent-from-the-resource-owner","title":"Gathering consent from the resource owner","text":"<p>TODO didcomm messages</p>"},{"location":"features/0309-didauthz/#credentials","title":"Credentials","text":"<p>TODO format of these credentials, JWTs or JSON-LDs?</p> <p>TODO</p>"},{"location":"features/0309-didauthz/#drawbacks","title":"Drawbacks","text":"<p>(None)</p>"},{"location":"features/0309-didauthz/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"features/0309-didauthz/#prior-art","title":"Prior art","text":"<p>Aries RFC 0167</p> <p>The Data Consent Lifecycle<sup>[10]</sup> is a reference implementation of data privacy agreements based on the GDPR framework<sup>[11]</sup>. The identity owner grants access to a verifier in the form of a proof of possession of a credential issued by the issuer. The identity owner may grant access to several verifiers in this manner. Access cannot be revoked on a per-verifier basis. To revoke access to a verifier, the identity owner's credential needs to be revoked, which in turn revokes all existing proofs the identity owner may have provided. The identity owner does not have the means to revoke access to a third party without directly involving the issuer.</p> <p>OAuth 2.0</p> <p>OAuth 2.0<sup>[6]</sup> is a role-based authorization framework in widespread use that enables a third-party to obtain limited access to HTTP services on behalf of a resource owner. The access token's scope is a simple data structure composed of space-delimited strings more suitable for a role-based authorization model than an attribute-based model.</p> <p>Although allowing for different types of tokens to be issued to clients as credentials, only the use of bearer tokens was formalized<sup>[12]</sup>. As a result, most implementations use bearer tokens as credentials. An expiry is optionally set on these tokens, but they nevertheless pose an unacceptable security risk in an SSI context and other contexts with high-value resources and need extra layers of security to address the risks of theft and impersonation. M. Jones and D. Hardt recommend the use of TLS to protect these tokens <sup>[12]</sup>, but this transport is not guaranteed as a DIDComm message travels from the sender to the recipient. The specification for mac tokens<sup>[13]</sup> never materialized and its TLS Channel Binding Support was never specified, therefore not solving the issue of unwanted TLS termination in a hop. There is ongoing work in the draft for OAuth 2.0 Token Binding<sup>[14]</sup> that binds tokens to the cryptographic key material produced by the client, but it also relies on TLS as the means of transport.</p> <p>OpenID Connect 1.0</p> <p>OIDC<sup>[15]</sup> is \"a simple layer on top of the OAuth 2.0 protocol\" that standardizes simple data structures that contain claims about the end-user's identity.</p> <p>Being based upon OAuth 2.0, it suffers from the same security weaknesses - see the extensive section on Security Considerations that references the OAuth 2.0 Thread Model and Security Considerations<sup>[16]</sup>.</p> <p>User-Managed Access 2.0</p> <p>UMA<sup>[7]</sup> is an extension to OAuth 2.0 that formalizes the authorization server's role as a delegate of the resource owner in order for the latter to grant access to requesting parties asynchronously and independently from the time of access. It relies on pre-defined resource scopes<sup>18</sup> and is thus more suited to role-based access control.</p>"},{"location":"features/0309-didauthz/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"features/0309-didauthz/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0309-didauthz/#references","title":"References","text":"<ol> <li>Matthew Davie, Dan Gisolfi, Daniel Hardman, John Jordan, Darrell O'Donnell, Drummond Reed: Aries RFC 0289: Trust over IP Stack, status PROPOSED</li> <li>Daniel Hardman: Aries RFC 0005 - DIDComm, status DEMONSTRATED</li> <li>Kyle Den Hartog, Stephen Curran, Mike Lodder: Aries RFC 0019 - Encryption Envelope, status ACCEPTED</li> <li>Oskar Deventer, Christian Lundkvist, Marton Csernai, Kyle Den Hartor, Markus Sabadello, Sam Curren, Dan Gisolfi, Mike Varley, Sven Hammannn, John Jordan, Lovesh Harchandani, Devin Fisher, Tobias Looker, Brent Zundel, Stephen Currant: Peer DID Method Specification, W3C Editor's Draft 16 October 2019</li> <li>The Sovrin Foundation: The Sovrin Glossary, v2.0</li> <li>Ed. D. Hardt: IETF RFC 6749 - The OAuth 2.0 Authorization Framework, October 2012</li> <li>Ed. E. Maler, M. Machulak, J. Richer, T. Hardjono: IETF I-D - User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization, February 2019</li> <li>Drummond Reed, Manu Sporny, Dave Longley, Christopher Allen, Ryan Grant, Markus Sabadello: Decentralized Identifiers (DIDs) v1.0,  W3C First Public Working Draft 07 November 2019</li> <li>Daniel Hardman, Sam Curren, Stephen Curran, Tobias Looker, George Aristy: Aries RFC 0028 - Introduce Protocol 1.0, status PROPOSED</li> <li>Jan Lindquist, Dativa; Paul Knowles, Dativa; Mark Lizar, OpenConsent; Harshvardhan J. Pandit, ADAPT Centre, Trinity College Dublin: Aries RFC 0167 - Data Consent Lifecycle, status PROPOSED</li> <li>Intersoft Consulting: General Data Protection Regulation, November 2019</li> <li>M. Jones, D. Hardt: IETF RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage, October 2012</li> <li>J. Richer, W. Mills, P. Hunt: IETF I-D - OAuth 2.0 Message Authentication Code (MAC) Tokens, January 2014</li> <li>M. Jones, B. Campbell, J. Bradley, W. Denniss: IETF I-D - OAuth 2.0 Token Binding, October 2018</li> <li>N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, C. Mortimore: OpenID Connect Core 1.0, November 2014</li> <li>T. Lodderstedt, M. McGloin, P. Hunt: OAuth 2.0 Thread Model nd Security Considerations, January 2013</li> <li>Daniel Hardman, Lovesh Harchandani: Aries RFC 0104 - Chained Credentials, status PROPOSED</li> <li>E. Maler, M. Machulak, J. Richer, T. Hardjono: Federated Authorization for User-Managed Access (UMA) 2.0, February 2019</li> </ol>"},{"location":"features/0317-please-ack/","title":"Aries RFC 0317: Please ACK Decorator","text":"<ul> <li>Authors: Daniel Hardman, Timo Glastra</li> <li>Status: RETIRED</li> <li>Since: 2019-12-26</li> <li>Status Note: Attempts at implementation demonstrate that a general purpose <code>~please_ack</code> capability is not practical, and needs to be implemented on a per protocol basis, for protocols where the functionality makes sense.</li> <li>Start Date: 2018-12-26</li> <li>Tags: feature, decorator</li> </ul>"},{"location":"features/0317-please-ack/#retirement-of-please_ack","title":"Retirement of <code>~please_ack</code>","text":"<p>The <code>please_ack</code> decorator was initially added to Aries Interop Protocol 2.0. However, this was done prior to attempts at an implementation. When such an attempt was made, it was found that the decorator is not practical as a general purpose mechanism. The capability assumed that the feature would be general purpose and could be applied outside of the protocols with which it was used. That assumption proved impossible to implement. The inclusion of the <code>~please_ack</code> decorator cannot be implemented without altering any protocol with which it is used, and so it is not practical. Instead, any protocols that can benefit from such a feature can be extended to explicitly support the feature.</p> <p>For the <code>\"on\": [\"OUTCOME\"]</code> type of ACK, the problem manifests in two ways. First, the definition of <code>OUTCOME</code> is protocol (and in fact, protocol message) specific. The definition of \"complete\" for each message is specific to each message, so there is no \"general purpose\" way to know when an <code>OUTCOME</code> ACK is to be sent. Second, the addition of a <code>~please_ack</code> decorator changes the protocol state machine for a given protocol, introducing additional states, and hence, additional state handling. Supporting <code>\"on\": [\"OUTCOME\"]</code> processing requires making changes to all protocols, which would be better handled on a per protocol basis, and where useful (which, it was found, is rare), adding messages and states. For example, what is the point of an extra <code>ACK</code> message on an <code>OUTCOME</code> in the middle of a protocol that itself results in the sending of the response message?</p> <p>Our experimentation found that it would be easier to achieve a general purpose <code>\"on\": [\"RECEIPT\"]</code> capability, but even then there were problems. Most notably, the capability is most useful when added to the last message of a protocol, where the message sender would like confirmation that the recipient got the message. However, it is precisely that use of the feature that also introduces breaking changes to the protocol state machine for the protocols to which it applies, requiring per protocol updates. So while the feature would be marginally useful in some cases, the complexity cost of the capability -- and the lack of demand for its creation -- led us to retire the entire RFC.</p> <p>For more details on the great work done by Alexander Sukhachev @alexsdsr, please see these pull requests, including both the changes proposed in the PRs, and the subsequent conversations about the ../../features.</p> <ul> <li>Aries Cloud Agent Python PR 2540 - PleaseAck.md document</li> <li>Aries Cloud Agent Python PR 2546 - DRAFT: please_ack support PoC for the 0453-issue-credential-v2 protocol</li> <li>Aries RFCs - Update the 'unresolved questions' section of the 0317-please-ack RFC</li> </ul> <p>Much thanks for Alexander for the effort he put into trying to implement this capability.</p>"},{"location":"features/0317-please-ack/#summary","title":"Summary","text":"<p>Explains how one party can request an acknowledgment to and clarify the status of processes.</p>"},{"location":"features/0317-please-ack/#motivation","title":"Motivation","text":"<p>An acknowledgment or ACK is one of the most common procedures in protocols of all types. The ACK message is defined in Aries RFC 0015-acks and is adopted into other protocols for use at explicit points in the execution of a protocol. In addition to receiving ACKs at predefined places in a protocol, agents also need the ability to request additional ACKs at other points in an instance of a protocol. Such requests may or may not be answered by the other party, hence the \"please\" in the name of decorator.</p>"},{"location":"features/0317-please-ack/#tutorial","title":"Tutorial","text":"<p>If you are not familiar with the tutorial section of the ACK message,please review that first.</p> <p>Agents interact in very complex ways. They may use multiple transport mechanisms, across varied protocols, through long stretches of time. While we usually expect messages to arrive as sent, and to be processed as expected, a vital tool in the agent communication repertoire is the ability to request and receive acknowledgments to confirm a shared understanding.</p>"},{"location":"features/0317-please-ack/#requesting-an-ack-please_ack","title":"Requesting an ack (<code>~please_ack</code>)","text":"<p>A protocol may stipulate that an ack is always necessary in certain circumstances. Launch mechanics for spacecraft do this, because the stakes for a miscommunication are so high. In such cases, there is no need to request an ack, because it is hard-wired into the protocol definition. However, acks make a channel more chatty, and in doing so they may lead to more predictability and correlation for point-to-point communications. Requiring an ack is not always the right choice. For example, an ack should probably be optional at the end of credential issuance (\"I've received your credential. Thanks.\") or proving (\"I've received your proof, and it satisfied me. Thanks.\").</p> <p>In addition, circumstances at a given moment may make an ad hoc ack desirable even when it would normally NOT be needed. Suppose Alice likes to bid at online auctions. Normally she may submit a bid and be willing to wait for the auction to unfold organically to see the effect. But if she's bidding on a high-value item and is about to put her phone in airplane mode because her plane's ready to take off, she may want an immediate ACK that the bid was accepted.</p> <p>The dynamic need for acks is expressed with the <code>~please_ack</code> message decorator. An example of the decorator looks like this:</p> <pre><code>{\n  \"~please_ack\": {\n    \"on\": [\"RECEIPT\"]\n  }\n}\n</code></pre> <p>This says, \"Please send me an ack as soon as you receive this message.\"</p>"},{"location":"features/0317-please-ack/#examples","title":"Examples","text":"<p>Suppose AliceCorp and Bob are involved in credential issuance. Alice is an issuer; Bob wants to hold the issued credential.</p>"},{"location":"features/0317-please-ack/#on-receipt","title":"On Receipt","text":"<p>In the final required message of the <code>issue-credential</code> protocol, AliceCorp sends the credential to Bob. But AliceCorp wants to know for sure that Bob has received it, for its own accounting purposes. So it decorates the final message with an ack request:</p> <pre><code>{\n  \"~please_ack\": {\n    \"on\": [\"RECEIPT\"]\n  }\n}\n</code></pre> <p>Bob honors this request and returns an <code>ack</code> as soon as he receives it and stores its payload.</p>"},{"location":"features/0317-please-ack/#on-outcome","title":"On Outcome","text":"<p>Same as with the previous example, AliceCorp wants an acknowledgement from Bob. However, in contrast to the previous example that just requests an acknowledgement on receipt of message, this time AliceCorp wants to know for sure Bob verified the validity of the credential. To do this AliceCorp decorates the <code>issue-credential</code> message with an ack request for the <code>OUTCOME</code>.</p> <pre><code>{\n  \"~please_ack\": {\n    \"on\": [\"OUTCOME\"]\n  }\n}\n</code></pre> <p>Bob honors this request and returns an <code>ack</code> as soon as he has verified the validity of the issued credential.</p>"},{"location":"features/0317-please-ack/#reference","title":"Reference","text":""},{"location":"features/0317-please-ack/#please_ack-decorator","title":"<code>~please_ack</code> decorator","text":""},{"location":"features/0317-please-ack/#on","title":"<code>on</code>","text":"<p>The only field for the please ack decorator. Required array. Describes the circumstances under which an ack is desired. Possible values in this array include <code>RECEIPT</code> and <code>OUTCOME</code>.</p> <p>If both values are present, it means an acknowledgement is requested for both the receipt and outcome of the message</p>"},{"location":"features/0317-please-ack/#receipt","title":"<code>RECEIPT</code>","text":"<p>The <code>RECEIPT</code> acknowledgement is the easiest ack mechanism and requests that an ack is sent on receipt of the message. This way of requesting an ack is to verify whether the other agent successfully received the message. It implicitly means the agent was able to unpack the message, to see</p>"},{"location":"features/0317-please-ack/#outcome","title":"<code>OUTCOME</code>","text":"<p>The <code>OUTCOME</code> acknowledgement is the more advanced ack mechanism and requests that an ack is sent on outcome of the message. By default outcome means the message has been handled and processed without business logic playing a role in the decision.</p> <p>In the context of the issue credential protocol, by default, this would mean an ack is requested as soon as the received credentials is verified to be valid. It doesn't mean the actual contents of the credential are acknowledged. For the issue credential protocol it makes more sense to send the acknowledgement after the contents of the credential have also been verified.</p> <p>Therefore protocols can override the definition of outcome in the context of that protocol. Examples of protocols overriding this behavior are Issue Credential Protocol 2.0, Present Proof Protocol 2.0 and Revocation Notification Protocol 1.0</p>"},{"location":"features/0317-please-ack/#drawbacks","title":"Drawbacks","text":"<p>None specified.</p>"},{"location":"features/0317-please-ack/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>The first version of this RFC was a lot more advanced, but also introduced a lot of complexities. A lot of complex ../../features have been removed so it could be included in AIP 2.0 in a simpler form. More advanced ../../features from the initial RFC can be added back in when needed.</p>"},{"location":"features/0317-please-ack/#prior-art","title":"Prior art","text":"<p>None specified.</p>"},{"location":"features/0317-please-ack/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Security and privacy implications of <code>~please_ack</code> decorators. Could they be used to mount a denial-of-service attack or to sniff info that's undesirable?</li> <li>Signed (Non-repudiable) acks. How do you ask for an ACK that commits its sender to the acknowledgment in a way that's provable to third parties?</li> <li>Multiplexed acks. How do you ask for, and supply, an ACK to all of Alice's agents instead of just to the one who sent the ACK? Does each agent need to request the ACK separately? Are there denial-of-service or other security issues?</li> </ul>"},{"location":"features/0317-please-ack/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0327-crypto-service/","title":"Aries RFC 0327: Crypto service Protocol 1.0","text":"<ul> <li>Authors: Robert Mitwicki, Wolfgang Lamot</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes:</li> <li>Start Date: 2019-11-01</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0327-crypto-service/#summary","title":"Summary","text":"<p>Within decentralized data economy with user-centric approach the user is the one who should control data flows and all interaction even on 3<sup>rd</sup> parties platforms. To achieve that we start to talk about access instead of ownership of the data. Within the space we can identify some services which are dealing with the users data but they don't necessarily need to be able to see the data. In this category we have services like archive, data vaults, data transportation (IM, Email, Sent file), etc. To be able to better support privacy in such cases this document proposes a protocol which uses underlying security mechanisms within agents like <code>Lox</code> to provide an API for cryptographic operations like asymetric encryption/decryption, signature/verification, delegation (proxy re-encryption) to let those services provide an additional security layer on their platform within connection to SSI wallet agents.</p>"},{"location":"features/0327-crypto-service/#motivation","title":"Motivation","text":"<p>Identity management and key management are complex topics with which even big players have problems. To help companies and their products build secure and privacy preserving services with SSI they need a simple mechanism to get access to the cryptographic operations within components of the wallets.</p>"},{"location":"features/0327-crypto-service/#todays-best-practice-approach-to-cryptographically-secured-services","title":"Todays 'Best Practice' approach to cryptographically secured Services","text":"<p>Many 3<sup>rd</sup> party services today provide solutions like secure storage, encrypted communication, secure data transportation and to achieve that they are using secure keys to provide cryptography for their use cases. The problem is that in many cases those keys are generated and/or stored within the 3<sup>rd</sup> party Services - either in the Client App or in the Backend - which requires the users explicit trust into the 3<sup>rd</sup> parties good intentions.</p> <p>Even in the case that a 3<sup>rd</sup> party has the best possible intentions in keeping the users secrets save and private. There is still the increased risk for the users keys of leakage or beeing compromised while beeing stored with a (centralized) 3<sup>rd</sup> party Service.</p> <p>Last but not least the users usage of multiple such cryptografically secured services would lead to the distribution of the users secrets over different systems where the user needs to keep track of them and manage them via differnt 3<sup>rd</sup> party tools.</p>"},{"location":"features/0327-crypto-service/#vision-seperation-of-service-business-logic-and-identity-artefacts","title":"Vision - seperation of Service-(Business-)Logic and Identity Artefacts","text":"<p>In the context of SSI and decentralized identity the ideal solution is that the keys are generated within user agent and that the private (secret) key never leaves that place. This would be a clear seperation of a services business logic and the users keys which we also count to the users unique sets of identifying information (identity artefacts).</p> <p>After seperating these two domains their follows the obvious need for providing a general crypto API to the user wallet which allows to support generic use cases where a cryptographic layer is required in the 3<sup>rd</sup> party service business logic, for example:</p> <ul> <li>encrypted data in data vaults</li> <li>encrypted messages within 3<sup>rd</sup> party service</li> <li>additional security layers outside of Agent ecosystem, data transportation, messaging over non-DIDComm protocols.</li> <li>backup/restore systems</li> </ul> <p>The desired outcome would be to have an Agent which is able to expose a standardized Crypto Services API to external 3<sup>rd</sup> party services which then can implement cryptographically secured aplications without the need to have access to the actual user secrets.</p>"},{"location":"features/0327-crypto-service/#tutorial","title":"Tutorial","text":""},{"location":"features/0327-crypto-service/#name-and-version","title":"Name and Version","text":"<p>This defines the <code>crypto-service</code> protocol. version 1.0, as identified by the following PIURI:</p> <pre><code>TODO: Add PIURI when ready\n</code></pre>"},{"location":"features/0327-crypto-service/#roles","title":"Roles","text":"<p>The minimum amount of roles involved in the <code>crypto-service</code> protocol are: a <code>sender</code> and a <code>receiver</code>. The <code>sender</code> requests a specific cryptographic operation from the <code>receiver</code> and the <code>receiver</code> provides the result in a form of a payload or an error. The protocol could include more roles (e.g. a <code>proxy</code>) which could be involved in processes like delegation (proxy re-encryption), etc.</p>"},{"location":"features/0327-crypto-service/#constraints","title":"Constraints","text":"<p>Each message which is send to the agent requires an up front established relationship between sender and receiver in the form of an authorization. This means that the sender is allowed to use only the specific key which is meant for him. There should not be the case that the sender is able to trigger any operation with keys which where never used within his service.</p>"},{"location":"features/0327-crypto-service/#reference","title":"Reference","text":""},{"location":"features/0327-crypto-service/#examples","title":"Examples","text":"<p>Specific use case example:</p> <p>A platform providing secure document transportation between parties and archiving functionality.</p> <p>Actors:</p> <ul> <li><code>Sender</code>: user sending document</li> <li><code>Receiver</code>: user receiving document</li> <li><code>DocuArch</code>: platform providing secure document transportation and archiving</li> <li><code>DocuArchApp</code>: client side application allowing to up-/download and display documents</li> </ul> <p>Here is how it could work:</p> <ul> <li><code>Receiver</code> register to the services with his DID identity (via <code>DocuArchApp</code>)</li> <li><code>Receiver</code> share his DID with the <code>Sender</code></li> <li><code>Sender</code> knowing DID of the <code>Receiver</code> encrypts the document with <code>Receiver</code> public key and sends document on the platform</li> <li><code>DocuArch</code> securely transports that document to the <code>Receiver</code> at the same time archiving it for the <code>Sender</code> and <code>Receiver</code></li> <li><code>Receiver</code> is informed by the <code>DocuArchApp</code> that there is a new document to view.</li> <li><code>Receiver</code> securely logs into <code>DocuArchApp</code> with his DID identity</li> <li><code>Receiver</code> opens encrypted payload within <code>DocuArchApp</code></li> <li><code>DocuArchApp</code> sends request to the user Agent to decrypt the message for the <code>Receiver</code></li> <li>Agent decrypts the message and sends back the decrypted payload</li> <li><code>DocuArchApp</code> displays the decrypted payload within local app</li> </ul> <p>In this scenario <code>DocuArch</code> has no way to learn about what is in the payload which is sent between <code>Sender</code> and <code>Receiver</code> as only the person who is in possession of the private key is able to decrypt the payload - which is the <code>Receiver</code>. Therfore the decrypted payload is only available on the <code>Receivers</code> client side app which is in communication with the Agent on behalf of the users DID identity.</p> <p>Such ../../features within the Agent allow companies to build faster and more secure systems as the identity management and key management part comes from Agents and they just interact with it via API.</p>"},{"location":"features/0327-crypto-service/#messages","title":"Messages","text":"<p>Protocol: did:sov:1234;spec/crypto-service/1.0</p> <p>encrypt</p> <ul> <li>payload - raw data which should be encrypted</li> <li>key_id - reference to the specific did key which was used to establish connection with the service.</li> </ul> <pre><code>    {\n        \"@id\": \"1234567889\",\n        \"@type\": \"did:sov:1234;spec/crypto-service/1.0/encrypt\",\n        \"payload\": \"Text to be encrypted\",\n        \"key_id\": \"did:example:123456789abcdefghi#keys-1\"\n\n    }\n</code></pre> <p>decrypt</p> <ul> <li>encryptedPayload - encrypted payload to be decrypt</li> <li>key_id - reference to the specific did key which was used to establish connection with the service.</li> </ul> <pre><code>    {\n        \"@id\": \"1234567889\",\n        \"@type\": \"did:sov:1234;spec/crypto-service/1.0/decrypt\",\n        \"encryptedPayload\": \"ASDD@J(!@DJ!DASD!@F\",\n        \"key_id\": \"did:example:123456789abcdefghi#keys-1\"\n\n    }\n</code></pre> <p>sign</p> <ul> <li>payload - payload to be signed</li> <li>key_id - reference to the specific did key which was used to establish connection with the service.</li> </ul> <pre><code>    {\n        \"@id\": \"1234567889\",\n        \"@type\": \"did:sov:1234;spec/crypto-service/1.0/sign\",\n        \"payload\": \"I say so!\",\n        \"key_id\": \"did:example:123456789abcdefghi#keys-1\"\n\n    }\n</code></pre> <p>verify</p> <ul> <li>signature - signature to be verified</li> <li>key_id - reference to the specific did key which was used to establish connection with the service.</li> </ul> <pre><code>    {\n        \"@id\": \"1234567889\",\n        \"@type\": \"did:sov:1234;spec/crypto-service/1.0/verify\",\n        \"signature\": \"12312d8u182d812d9182d91827d179\",\n        \"key_id\": \"did:example:123456789abcdefghi#keys-1\"\n\n    }\n</code></pre> <p>delegate</p> <ul> <li>delegate - DID of the delegate identity for which the proxy re-encryption token shall be generated</li> <li>key_id - reference to the specific did key which was used to establish connection with the service.</li> </ul> <pre><code>    {\n        \"@id\": \"1234567889\",\n        \"@type\": \"did:sov:1234;spec/crypto-service/1.0/delegate\",\n        \"delegate\": \"did:example:ihgfedcba987654321\",\n        \"key_id\": \"did:example:123456789abcdefghi#keys-1\"\n\n    }\n</code></pre>"},{"location":"features/0327-crypto-service/#message-catalog","title":"Message Catalog","text":"<p>TODO: add error codes and response messages/statuses</p>"},{"location":"features/0327-crypto-service/#responses","title":"Responses","text":"<p>TODO</p>"},{"location":"features/0327-crypto-service/#drawbacks","title":"Drawbacks","text":""},{"location":"features/0327-crypto-service/#-potentialy-expose-agent-for-different-types-of-attacts-eg-someone-would-try-to-decrypt-your-private-documents-without-you-being-notice-of-that","title":"- Potentialy expose Agent for different types of attacts: e.g. someone would try to decrypt your private documents without you being notice of that.","text":""},{"location":"features/0327-crypto-service/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>We can not expect that each services will switch directly to the DIDComm and other ../../features of the agents. Not all ../../features are even desier to have within agent. But if the Agent can exposer base API for identity management and crypto operations this would allow others to build on top of it much more richer ans secure applications and platforms.</p> <p>We are not aware of any alternatives atm. Anyone?</p>"},{"location":"features/0327-crypto-service/#prior-art","title":"Prior art","text":"<p>Similar approach is taken within HSM world where API is expose to the outside world without exposing keys. Here we take same approach in the context of KMS within Agent.</p>"},{"location":"features/0327-crypto-service/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>How to check authorization that a given service is allowed to use a specific set of the keys?</li> <li>How to protect user against malicious requests?</li> <li>What other operations should be supported?</li> <li>What are the limitations in the context of payload?</li> </ul>"},{"location":"features/0327-crypto-service/#implementations","title":"Implementations","text":"<p>Implementation Notes</p> Name / Link Implementation Notes"},{"location":"features/0334-jwe-envelope/","title":"Aries RFC 0334: JWE envelope 1.0","text":"<ul> <li>Authors: Baha A. Shaaban (SecureKey Technologies Inc.), Troy Ronda (SecureKey Technologies Inc.)</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes:</li> <li>Start Date: 2019-11-01</li> <li>Tags: feature</li> </ul>"},{"location":"features/0334-jwe-envelope/#summary","title":"Summary","text":"<p>Agents need to use a common set of algorithms when exchanging and persisting data. This RFC supplies a cipher suite and examples for DIDComm envelopes.</p>"},{"location":"features/0334-jwe-envelope/#motivation","title":"Motivation","text":"<p>The goal of this RFC is to define cipher suites for Anoncrypt and Authcrypt such that we can achieve better compatibility with JOSE. We also aim to supply both a compliant suite and a constrained device suite. The compliant suite is suitable for implementations that contain AES hardware acceleration or desire to use NIST / FIPS algorithms (where possible).</p>"},{"location":"features/0334-jwe-envelope/#encryption-algorithms","title":"Encryption Algorithms","text":"<p>The next two sub-sections describe the encryption algorithms that must be supported. On devices with AES hardware acceleration or requiring compliance, AES GCM is the recommended algorithm. Otherwise, XChacha20Poly1305 should be used.</p>"},{"location":"features/0334-jwe-envelope/#content-encryption-algorithms","title":"Content Encryption Algorithms","text":"<p>The following table defines the supported content encryption algorithms for DIDComm JWE envelopes:</p> Content Encryption Encryption Algorithm identifier Authcrypt/Anoncrypt Reference A256CBC-HS512 (512 bit) AES_256_CBC_HMAC_SHA_512 Authcrypt/Anoncrypt ECDH-1PU section 2.1 and RFC 7518 section 5.2.5 AES-GCM (256 bit) A256GCM Anoncrypt RFC7518 section 5.1 and more specifically RFC7518 section 5.3 XChacha20Poly1305 XC20P Anoncrypt xchacha draft 03"},{"location":"features/0334-jwe-envelope/#key-encryption-algorithms","title":"Key Encryption Algorithms","text":"<p>The following table defines the supported key wrapping encryption algorithms for DIDComm JWE envelopes:</p> Key Encryption Encryption algorithm identifier Anoncrypt/Authcrypt ECDH-ES + AES key wrap ECDH-ES+A256KW Anoncrypt ECDH-1PU + AES key wrap ECDH-1PU+A256KW Authcrypt"},{"location":"features/0334-jwe-envelope/#curves-support","title":"Curves support","text":"<p>The following curves are supported:</p> Curve Name Curve identifier X25519 (aka Curve25519) X25519 (default) NIST P256 (aka SECG secp256r1 and ANSI X9.62 prime256v1, ref here) P-256 NIST P384 (aka SECG secp384r1, ref here) P-384 NIST P521 (aka SECG secp521r1, ref here) P-521 <p>Other curves are optional.</p>"},{"location":"features/0334-jwe-envelope/#security-consideration-for-curves","title":"Security Consideration for Curves","text":"<p>As noted in the ECDH-1PU IETF draft security considerations section, all implementations must ensure the following: <pre><code>When performing an ECDH key agreement between a static private key\nand any untrusted public key, care should be taken to ensure that the\npublic key is a valid point on the same curve as the private key.\nFailure to do so may result in compromise of the static private key.\nFor the NIST curves P-256, P-384, and P-521, appropriate validation\nroutines are given in Section 5.6.2.3.3 of [NIST.800-56A]. For the\ncurves used by X25519 and X448, consult the security considerations\nof [RFC7748].\n</code></pre></p>"},{"location":"features/0334-jwe-envelope/#jwe-examples","title":"JWE Examples","text":"<p>AES GCM encryption and key wrapping examples are found in Appendix C of the JSON Web Algorithm specs.</p> <p>The Proposed JWE Formats below lists a combination of content encryption and key wrapping algorithms formats.</p>"},{"location":"features/0334-jwe-envelope/#drawbacks","title":"Drawbacks","text":"<ul> <li>All new algorithm identifiers should be registered at IANA.</li> <li>XC20P</li> <li>ECDH-1PU+A256KW (already in IETF draft)</li> <li>ECDH-ES+XC20PKW</li> <li>ECDH-1PU+XC20PKW</li> <li>Security Considerations of ECDH-1PU (Section 4)</li> <li>X25519 is not yet part of SP 800-56A. See NIST post for more information.</li> </ul>"},{"location":"features/0334-jwe-envelope/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Our approach for AuthCrypt compliance is to use the NIST approved <code>One-Pass Unified Model for ECDH</code> scheme described in SP 800-56A Rev. 3. The JOSE version is defined as <code>ECDH-1PU</code> in this IETF draft.</p> <p>Aries agents currently use the envelope described in RFC0019. This envelope uses libsodium (NaCl) encryption/decryption, which is based on Salsa20Poly1305 algorithm.</p> <p>Another prior effort towards enhancing JWE compliance is to use XChacha20Poly1305 encryption and ECDH-SS key wrapping mode. See Aries-RFCs issue-133 and Go JWE Authcrypt package for an implementation detail. As ECDH-SS is not specified by JOSE, a new recipient header field, <code>spk</code>, was needed to contain the static encrypted public key of the sender. Additionally (X)Chacha20Poly1305 key wrapping is also not specified by JOSE. For these reasons, this option is mentioned here as reference only.</p>"},{"location":"features/0334-jwe-envelope/#jwe-formats","title":"JWE formats","text":""},{"location":"features/0334-jwe-envelope/#anoncrypt-using-ecdh-es-key-wrapping-mode-and-xc20p-content-encryption","title":"Anoncrypt using ECDH-ES key wrapping mode and XC20P content encryption","text":"<pre><code> {\n  \"protected\": base64url({\n      \"typ\": \"didcomm-envelope-enc\",\n      \"enc\": \"XC20P\", // or \"A256GCM\"\n  }),\n  \"recipients\": [\n    {\n      \"header\": {\n        \"kid\": base64url(recipient KID), // e.g: base64url(\"urn:123\") or base64url(jwk thumbprint as KID)\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"epk\": { // defining X25519 key as an example JWK, but this can be EC key as well \n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"-3bLMSHYDG3_LVNh-MJvoYs_a2sAEPr4jwFfFjTrmUo\" // sender's ephemeral public key value raw (no padding) base64url encoded\n        },\n        \"apu\": base64url(epk.x value above),\n        \"apv\": base64url(recipients[*].header.kid)\n      },\n      \"encrypted_key\": \"Sls6zrMW335GJsJe0gJU4x1HYC4TRBZS1kTS1GATEHfH_xGpNbrYLg\"\n    }\n  ],\n  \"aad\": \"base64url(sha256(concat('.',sort([recipients[0].kid, ..., recipients[n].kid])))))\",\n  \"iv\": \"K0PfgxVxLiW0Dslx\",\n  \"ciphertext\": \"Sg\",\n  \"tag\": \"PP31yGbQGBz9zgq9kAxhCA\"\n}\n</code></pre> <p><code>typ</code> header field is the DIDComm Transports value as mentioned in RFC-0025. This RFC states the prefix <code>application/</code> but according to IANA Media types the prefix is implied therefore not needed here.</p>"},{"location":"features/0334-jwe-envelope/#anoncrypt-using-ecdh-es-key-wrapping-mode-and-a256gcm-content-encryption","title":"Anoncrypt using ECDH-ES key wrapping mode and A256GCM content encryption","text":"<pre><code>{\n  \"protected\": base64url({\n          \"typ\": \"didcomm-envelope-enc\",\n          \"enc\": \"A256GCM\", // \"XC20P\"\n  }),\n  \"recipients\": [\n    {\n      \"header\": {\n        \"kid\": base64url(recipient KID),\n        \"alg\": \"ECDH-ES+XC20PKW\", // or \"ECDH-ES+A256KW\" with \"epk\" as EC key\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"aOH-76BRwkHf0nbGokaBsO6shW9McEs6jqVXaF0GNn4\" // sender's ephemeral public key value raw (no padding) base64url encoded\n        },\n        \"apu\": base64url(epk.x value above),\n        \"apv\": base64url(recipients[*].header.kid)\n      },\n      \"encrypted_key\": \"wXzKi-XXb6fj_KSY5BR5hTUsZIiAQKrxblTo3d50B1KIeFwBR98fzQ\"\n    }\n  ],\n  \"aad\": \"base64url(sha256(concat('.',sort([recipients[0].kid, ..., recipients[n].kid])))))\",\n  \"iv\": \"9yjR8zvgeQDZFbIS\",\n  \"ciphertext\": \"EvIk_Rr6Nd-0PqQ1LGimSqbKyx_qZjGnmt6nBDdCWUcd15yp9GTeYqN_q_FfG7hsO8c\",\n  \"tag\": \"9wP3dtNyJERoR7FGBmyF-w\"\n}\n</code></pre> <p>In the above two examples, <code>apu</code> is the encoded ephemeral key used to encrypt the cek stored in <code>encrypted_key</code> and <code>apv</code> is the encoded key id of the static public key of the recipient. Both are raw (no padding) base64Url encoded. <code>kid</code> is the value of a key ID in a DID document that should be resolvable to fetch the raw public key used.</p>"},{"location":"features/0334-jwe-envelope/#authcrypt-using-ecdh-1pu-key-wrapping-mode","title":"Authcrypt using ECDH-1PU key wrapping mode","text":"<pre><code>{\n    \"protected\": base64url({\n        \"typ\": \"didcomm-envelope-enc\",\n        \"enc\":\"A256CBC-HS512\", // or one of: \"A128CBC-HS256\", \"A192CBC-HS384\"\n        \"skid\": base64url(sender KID),\n        \"alg\": \"ECDH-1PU+A256KW\", // or \"ECDH-1PU+XC20P\" with \"epk\" as X25519 key\n        \"apu\": base64url(\"skid\" header value),\n        \"apv\": base64url(sha256(concat('.',sort([recipients[0].kid, ..., recipients[n].kid]))))),\n        \"epk\": {\n            \"kty\": \"EC\",\n            \"crv\": \"P-256\",\n            \"x\": \"gfdM68LgZWhHwdVyMAPh1oWqV_NcYGR4k7Bjk8uBGx8\",\n            \"y\": \"Gwtgz-Bl_2BQYdh4f8rd7y85LE7fyfdnb0cWyYCrAb4\"\n        }\n    }),\n    \"recipients\": [\n        {\n            \"header\": {\n                \"kid\": base64url(recipient KID)\n            },\n            \"encrypted_key\": \"base64url(encrypted CEK)\"\n        },\n       ...\n    ],\n    \"aad\": \"base64url(sha256(concat('.',sort([recipients[0].kid, ..., recipients[n].kid])))))\",\n    \"iv\": \"base64url(content encryption IV)\",\n    \"ciphertext\": \"base64url(XC20P(DIDComm payload, base64Url(json($protected)+'.'+$aad), content encryption IV, CEK))\"\n    \"tag\": \"base64url(AEAD Authentication Tag)\"\n}\n</code></pre> <p>With the recipients headers representing an ephemeral key that can be used to derive the key to be used for AEAD decryption of the CEK following the ECDH-1PU encryption scheme.</p> <p>The function <code>XC20P</code> in the example above is defined as the XChahcha20Poly1035 cipher function. This can be replaced by the AES-CBC+HMAC_SHA family of cipher functions for authcrypt or AES-GCM cipher function for anoncrypt.</p>"},{"location":"features/0334-jwe-envelope/#concrete-examples","title":"Concrete examples","text":"<p>See concrete anoncrypt and authcrypt examples</p>"},{"location":"features/0334-jwe-envelope/#jwe-detached-mode-nested-envelopes","title":"JWE detached mode nested envelopes","text":"<p>There are situations in DIDComm messaging where an envelope could be nested inside another envelope -- particularly RFC 46: Mediators and Relays. Normally nesting envelopes implies that the envelope payloads will incur additional encryption and encoding operations at each parent level in the nesting. This section describes a mechanism to extract the nested payloads outside the nesting structure to avoid these additional operations.</p>"},{"location":"features/0334-jwe-envelope/#detached-mode","title":"Detached mode","text":"<p>JWS defines detached mode where the payload can be removed. As stated in IETF RFC7515, this strategy has the following benefit:</p> <p>Note that this method needs no support from JWS libraries, as   applications can use this method by modifying the inputs and outputs   of standard JWS libraries.</p> <p>We will leverage a similar detached mode for JWE in the mechanism described below.</p>"},{"location":"features/0334-jwe-envelope/#mechanism","title":"Mechanism","text":"<p>Sender:</p> <ol> <li>Creates the \"final\" JWE intended for the recipient (normal JWE operation).</li> <li>Extracts the ciphertext and replace with an empty string.</li> <li>Creates the nested envelopes around the \"final\" JWE (but with the empty string ciphertext).</li> <li>Sends the nested envelope (normal JWE) plus the ciphertext from the \"final\" JWE.</li> </ol> <p>Mediator:</p> <ol> <li>Decrypt their layer (normal JWE operation). The detached ciphertext(s) are filtered out prior to invoking the JWE library (normal JWE structure).</li> <li>Remove the next detached ciphertext from the structure and insert back into the ciphertext field for the next nesting level.</li> </ol> <p>Receiver:</p> <ol> <li>Decrypts the \"final\" JWE (normal JWE operation).</li> </ol> <p>The detached ciphertext steps are repeated at each nesting level. In this case, an array of ciphertexts is sent along with the nested envelope.</p> <p>This solution has the following characteristics:</p> <ul> <li>Only encrypts the payload once.</li> <li>JWE headers and metadata are included in the nested envelope's ciphertext.</li> <li>Needs no support from JWE libraries.</li> <li>Requires a serialization structure for transporting both the nesting JWE and the detached ciphertexts (only when there is a nested envelope). See below.</li> <li>Requires some minor additional logic prior to invoking the JWE library.</li> </ul>"},{"location":"features/0334-jwe-envelope/#serialization","title":"Serialization","text":"<p>The extracted ciphertext serialization format should have additional thought for both compact and JSON modes. As a starting point:</p> <ul> <li>Compact mode: Each extracted ciphertext is appended to the end of the serialized \"final\" JWE (using dot separation). These extracted cipher texts are ordered according to the nesting (from innermost to outermost).</li> <li>JSON mode: The extracted ciphertext are placed into a JSON array. These extracted cipher texts are ordered according to the nesting (from innermost to outermost). The array is appended to the \"final\" JWE object as the <code>detached_ciphertext</code> field.</li> </ul> <p>For illustration, the following compact serialization represents nesting due to two mediators (the second mediator being closest to the Receiver).</p> <p>First Mediator receives: <pre><code>  BASE64URL(UTF8(JWE Protected Header for First Mediator)) || '.' ||\n  BASE64URL(JWE Encrypted Key for First Mediator) || '.' ||\n  BASE64URL(JWE Initialization Vector for First Mediator) || '.' ||\n  BASE64URL(JWE Ciphertext for First Mediator) || '.' ||\n  BASE64URL(JWE Authentication Tag for First Mediator) || '.' ||\n  BASE64URL(JWE Ciphertext for Receiver) || '.' ||\n  BASE64URL(JWE Ciphertext for Second Mediator)\n</code></pre></p> <p>Second Mediator receives: <pre><code>  BASE64URL(UTF8(JWE Protected Header for Second Mediator)) || '.' ||\n  BASE64URL(JWE Encrypted Key for Second Mediator) || '.' ||\n  BASE64URL(JWE Initialization Vector for Second Mediator) || '.' ||\n  BASE64URL(JWE Ciphertext for Second Mediator) || '.' ||\n  BASE64URL(JWE Authentication Tag for Second Mediator) || '.' ||\n  BASE64URL(JWE Ciphertext for Receiver)\n</code></pre></p> <p>Finally, the Receiver has a normal JWE (as usual): <pre><code>  BASE64URL(UTF8(JWE Protected Header for Receiver)) || '.' ||\n  BASE64URL(JWE Encrypted Key for Receiver) || '.' ||\n  BASE64URL(JWE Initialization Vector for Receiver) || '.' ||\n  BASE64URL(JWE Ciphertext for Receiver) || '.' ||\n  BASE64URL(JWE Authentication Tag for Receiver)\n</code></pre></p> <p>This illustration extends the serialization shown in RFC 7516.</p>"},{"location":"features/0334-jwe-envelope/#prior-art","title":"Prior art","text":"<ul> <li>The JWE family of encryption methods.</li> <li>Aries RFC 0019-encryption-envelope suggested envelope formats will be superseded by this RFC.</li> <li>Aries RFC 0025-didcomm-transports for the content type used in the proposed envelopes.</li> <li>minimal-cipher implementation</li> <li>Aries-Framework-Go has an experimental (X)Chacha20Poly1305 Packer implementation based on Aries-RFCs issue-133</li> <li>IANA Media Types</li> <li>Public Key Authenticated Encryption for JOSE: ECDH-1PU</li> <li>NIST SP 800-56A Rev. 3 Recommendation for Pair-Wise Key-Establishment schemes Using Discrete Logarithm Cryptography</li> <li>Appendix A of IETF 4492 listing equivalent curve names.</li> </ul>"},{"location":"features/0334-jwe-envelope/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What fields should Key identifiers in ES and 1PU key wrapping modes use? <code>kid</code> vs <code>id</code> (vs <code>skid</code> introduced in ECDH-1PU IETF document) or any other combination of fields. There is a discussion about this here.</li> <li> <p>Update:   The answer to this question is to keep <code>kid</code> definition as per the JWE/JWS family of specification definitions and use <code>skid</code> in the JWE protected header as defined in ECDH-1PU to represent a resolvable sender key id.</p> </li> <li> <p>What kind of keys to include in the JWE envelope? <code>Encryption</code> or <code>signing</code> keys? Currently, the existing Aries agents include <code>signing</code> (ED25519) keys for the sender and recipients and convert them to encryption (X25519) keys for encryption/decryption operations only. The drawback of this approach is the envelope transmitted by the agent contains signing public keys. There is a need to separate them from <code>encryption</code> keys. </p> </li> <li>Update:   The best way to separate the two keys is to use the DID document's KeyAgreement verification method in full description to store the <code>encryption</code> key so that it can be sent in the JWE envelope independently of the signing (DID authentication) key.</li> </ul>"},{"location":"features/0334-jwe-envelope/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes <p>Note: Aries Framework - Go is almost done with a first draft implementation of this RFC.</p>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/","title":"Table of Contents","text":"<ul> <li>Anoncrypt JWE Concrete examples</li> <li>Notes</li> <li>1 A256GCM Content Encryption<ul> <li>1.1 Multi recipients JWEs</li> <li>1.1.1 NIST P-256 keys</li> <li>1.1.2 NIST P-384 keys</li> <li>1.1.3 NIST P-521 keys</li> <li>1.1.4 X25519 keys</li> <li>1.2 Single Recipient JWEs</li> <li>1.2.1 NIST P-256 key</li> <li>1.2.2 NIST P-384 key</li> <li>1.2.3 NIST P-521 key</li> <li>1.2.4 X25519 key</li> </ul> </li> <li>2 XC20P content encryption<ul> <li>2.1 Multi recipients JWEs</li> <li>2.1.1 NIST P-256 keys</li> <li>2.1.2 NIST P-384 keys</li> <li>2.1.3 NIST P-521 keys</li> <li>2.1.4 X25519 keys</li> <li>2.2 Single Recipient JWEs</li> <li>2.2.1 NIST P-256 key</li> <li>2.2.2 NIST P-384 key</li> <li>2.2.3 NIST P-521 key</li> <li>2.2.4 X25519 key</li> </ul> </li> </ul> <p>Created by gh-md-toc</p>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#anoncrypt-jwe-concrete-examples","title":"Anoncrypt JWE Concrete examples","text":"<p>The following examples are for JWE anoncrypt packer for encrypting the payload <code>secret message</code> and aad value set as the concatenation of recipients' KIDs (ASCII sorted) joined by <code>.</code> for non-compact serializations (JWE Compact serializations don't have AAD).</p>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#notes","title":"Notes","text":"<ul> <li>all <code>x</code> and <code>y</code> key coordinates values below are raw (no padding) base64URL encoded.</li> <li>JWE envelopes with multi recipients use the General JWE JSON Serialization format.</li> <li>JWE envelopes with a single recipient will be shown in both serialization formats: as JWE Compact or Flattened JWE JSON.</li> <li>General JWE JSON Serialization format use. the above mentioned AAD value in their envelope.</li> <li>JWE Compact Serialization format does not support AAD values and therefore were built without it.</li> <li>all <code>apu</code> recipient header values are set to the raw (no padding) base64URL encoding of the corresponding recipient's ephemeral key's <code>x</code> value since Anoncrypt dosen't reveal the sender.</li> <li>all <code>apv</code> recipient header values are set to the raw (no padding) base64URL encoding of the corresponding recipient's <code>kid</code> value.</li> <li>The final aad used to encrypt the payload is the concatenation of the raw (no padding) base64URL encoded protected headers and <code>aad</code> JWE header joined by a <code>.</code>.</li> <li>Even though flattened serialization do support <code>aad</code>, the field is omitted in the below examples to be consistent with compact JWE serialization format. Implementations should support <code>aad</code> for flattened serialization regardless.</li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#1-a256gcm-content-encryption","title":"1 A256GCM Content Encryption","text":"<p>The packer generates the following protected headers for A256GCM content encryption in the below examples: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"A256GCM\",\"typ\":\"application/didcomm-encrypted+json\"}</code>     - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9</code></p>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#11-multi-recipients-jwes","title":"1.1 Multi recipients JWEs","text":""},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#111-nist-p-256-keys","title":"1.1.1 NIST P-256 keys","text":"<ul> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"2fpy_fK5FCsap0EbU1Om7QXoVoyvBv8gfdHY3ufIS9w\",\n  \"y\": \"TtVOc9c8ejMeqeaUs1CMS79w0-Al02Fw25WdVEb0DiI\",\n  \"d\": \"kEWLCAyDL8mgDLNnlb1am_B8wcaGAe7ViXx1tqKWTVc\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>s6-ZhI1hpx0kM3pDgOrVQs6mRd_8KfEXUkLg8lK7XNA</code></li> <li>Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"S9JVfrKenXIMiEUha1k8yt7Zw8d5_bSxEt6RJesPt1g\",\n  \"y\": \"KMWwZzb80uoAjCcuwQ3gSeyjMsbq02AyS7g1D2i7ZwM\",\n  \"d\": \"bHnnqFSAFROp4kLbfBfihHUg6PIviwRCt5foN2Romw4\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>2NfcF400LLr9Wa6QbkUikYUUcdsAUkZBy6ifrrXYI0U</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"tqn3J0p752xWq2T4M11Q8ZcidyEWfaray-2B84hjehg\",\n  \"y\": \"ewcqOkZtlGBfZmP9nr44tq7_vkBJ3fJe9u6TCEyMDh8\",\n  \"d\": \"5XlB_SQXVpA6Id1PNL4SJfrMhCC36xa0hSHB7WpwA9Y\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>xG9z3It37igQIB4Q9jbcKLVjcFvnXIvkuJdLNKFvRB4</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>2NfcF400LLr9Wa6QbkUikYUUcdsAUkZBy6ifrrXYI0U.s6-ZhI1hpx0kM3pDgOrVQs6mRd_8KfEXUkLg8lK7XNA.xG9z3It37igQIB4Q9jbcKLVjcFvnXIvkuJdLNKFvRB4</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>YyqAtGX-dZTiXaZnGazezl-jBXS4uka1sOFv8cV42uM</code></li> <li>Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"WVU3OHhXeVZLeC1WRVpIV2pWbFN3Z2NndFRtSjBfS09YOE9hTkdnQXNlUQ\",\n        \"apv\": \"czYtWmhJMWhweDBrTTNwRGdPclZRczZtUmRfOEtmRVhVa0xnOGxLN1hOQQ\",\n        \"kid\": \"s6-ZhI1hpx0kM3pDgOrVQs6mRd_8KfEXUkLg8lK7XNA\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"YU78xWyVKx-VEZHWjVlSwgcgtTmJ0_KOX8OaNGgAseQ\",\n          \"y\": \"AiHDxtQBrba6g3_d0tic8LeLZRMz7rqnghQ2DvJh0Xk\"\n        }\n      },\n      \"encrypted_key\": \"fnofbBoie-ywDVjd_Dcdw611KWabq0RptbEybN_AParPMI0qpOwm1Q\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"NkN3ZEt3ZEotczdIZHFpUzExR0x6bS1scVhlUW1TYWJjNXBvRnBaakdZbw\",\n        \"apv\": \"czYtWmhJMWhweDBrTTNwRGdPclZRczZtUmRfOEtmRVhVa0xnOGxLN1hOQQ\",\n        \"kid\": \"2NfcF400LLr9Wa6QbkUikYUUcdsAUkZBy6ifrrXYI0U\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"6CwdKwdJ-s7HdqiS11GLzm-lqXeQmSabc5poFpZjGYo\",\n          \"y\": \"mVsQl_AhZoHpC86UN49k6tAU5B2YLi0HIdWeaIvSQy8\"\n        }\n      },\n      \"encrypted_key\": \"qN1WX7DK0k2GW4qHK0SfQFTRrOM0GFUgzqqy58QTRWi62r9iItmPxA\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"aXZzeDhaVmowbEJ1c2pLNjZSS1dVN0JDRjJzal81QWlQb1VsS21KOHZkSQ\",\n        \"apv\": \"czYtWmhJMWhweDBrTTNwRGdPclZRczZtUmRfOEtmRVhVa0xnOGxLN1hOQQ\",\n        \"kid\": \"xG9z3It37igQIB4Q9jbcKLVjcFvnXIvkuJdLNKFvRB4\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"ivsx8ZVj0lBusjK66RKWU7BCF2sj_5AiPoUlKmJ8vdI\",\n          \"y\": \"Ea6i7ahugWrTZoc9UMq1e3aPmHm0bkGqxTDmoEMyYMU\"\n        }\n      },\n      \"encrypted_key\": \"Yds0G9wYyAaGf2ky9DAT0CITzoD4qHV1fUM-cH-mmGsx8TeFjYBVYw\"\n    }\n  ],\n  \"aad\": \"YyqAtGX-dZTiXaZnGazezl-jBXS4uka1sOFv8cV42uM\",\n  \"iv\": \"S9rOxQOd8H-gxZIv\",\n  \"ciphertext\": \"w3kl_QixTanzflQHpuM\",\n  \"tag\": \"4x5wmIBxrCjUpq4wxrWFDQ\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#112-nist-p-384-keys","title":"1.1.2 NIST P-384 keys","text":"<ul> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"lb17x-OBz2i1kQbkRtSKD3TY1MwIfUMyM8YtqXZXMj884hLJH2QtxmUWKyXIprcn\",\n  \"y\": \"PlT4CInTrA5zAroqwyww0BL6EipnEBTrtbWID8nADz6LFpf_27qlxIARy_iU5OcN\",\n  \"d\": \"JJgpIqGS5JuiKRnsEgGNlYw39pz-XGrsrmniuxlSik0BLwdb8-0K8Xxuqo6yW6NE\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>8wPpWWlLiMBYltw6AoWG3Z_SfgWmXanBHSwZFpQJ0Q0</code></li> <li>Recipient 2 public key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"ACZDXpzp6cKqsCcWq7sVOcCB_QZLd9ZfhoxhBKCbytrSKVKn7jV3Kv1XlsnH1RH7\",\n  \"y\": \"FQy3qBV-bn4K_5bQXucEPIOupMhEJS7YXCbm-fUb9ZdC59b0-5lbo7l65fkEL3ZO\",\n  \"d\": \"F4BlupNNnLfPOsml1MfBJgw6Oz89L6GnRiJnFi5ay5zVHTIcWzX81D060KsCjK9t\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>8l5z1lSVYFmv8QSboANWcj_UUh4bp3PlwEBNNHd2p3Q</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"msbHjsKVl0paXi-SWZ5_gEMgsMihBW9TEnfScKxfVlFMC6Hi5JIz1wgs58ugqaSX\",\n  \"y\": \"ppzaqlmAjA_iBymA2iBH56mHeTxckL8YNfmcSNa8hJoD4XYZ-4_x9mip-dh8o4gI\",\n  \"d\": \"YT0k8bBmPmecprG6tax6g00wG0JkprPcCqU1jvM86PAGGUU12fY7-Dfmqwhwv5U-\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>t1KsLfBBTG9iXIzyga6xV7RAur2j34dLGB3jqTDuTMo</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>8l5z1lSVYFmv8QSboANWcj_UUh4bp3PlwEBNNHd2p3Q.8wPpWWlLiMBYltw6AoWG3Z_SfgWmXanBHSwZFpQJ0Q0.t1KsLfBBTG9iXIzyga6xV7RAur2j34dLGB3jqTDuTMo</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>jgz9Cgt6lep5QPX0-GCkOMXujjRYgfiTslwut8BdX-0</code></li> <li>JWE: <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"OVdMemtDbjBlaEFxVTlwZjdvUEFZVUdOcHhkdTR2VWZUZVZxZzlVWEZUNVNPS0dTaDFwZ294aWhOb0tWZlpsNg\",\n        \"apv\": \"OHdQcFdXbExpTUJZbHR3NkFvV0czWl9TZmdXbVhhbkJIU3daRnBRSjBRMA\",\n        \"kid\": \"8wPpWWlLiMBYltw6AoWG3Z_SfgWmXanBHSwZFpQJ0Q0\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"9WLzkCn0ehAqU9pf7oPAYUGNpxdu4vUfTeVqg9UXFT5SOKGSh1pgoxihNoKVfZl6\",\n          \"y\": \"Yuwe4x6Seue5pegwF9px-RQqSxARjf5mHSwVW7ft6dC5TgXdCPzm3bTRW4qxR41X\"\n        }\n      },\n      \"encrypted_key\": \"Dj-4zbK_WbF_5nU1rfvT0dipMtwSUQvmluCrxwu-arKU2w59hN5ecQ\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"Q2hxMTBxU0duM3JQdHVKaFcwcEF1TzIxanh4WkVFb0xVQ1hkajNTbERfelZMamQ4ZHdwSmp5UXhQeEVSQ2ZOTw\",\n        \"apv\": \"OHdQcFdXbExpTUJZbHR3NkFvV0czWl9TZmdXbVhhbkJIU3daRnBRSjBRMA\",\n        \"kid\": \"8l5z1lSVYFmv8QSboANWcj_UUh4bp3PlwEBNNHd2p3Q\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"Chq10qSGn3rPtuJhW0pAuO21jxxZEEoLUCXdj3SlD_zVLjd8dwpJjyQxPxERCfNO\",\n          \"y\": \"9PkX3jqgkslA2Z8rijClt-1yX5uulFcbRl7dCaSgquCfYj0ZmOEVhQqdD9yh955n\"\n        }\n      },\n      \"encrypted_key\": \"LpoFtDL4ac0bx16AkyE4HmpK-F_ibPm1LvyQVo-eFaPEo9HW8FWz_Q\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"T0cyZUptVU05NENDS2w4U2lGVTJNQUhVUnJiRldRSm1xd25ya2VWUFN3NTMzX3lSakFMLVNscnhvZ29uSnBzbA\",\n        \"apv\": \"OHdQcFdXbExpTUJZbHR3NkFvV0czWl9TZmdXbVhhbkJIU3daRnBRSjBRMA\",\n        \"kid\": \"t1KsLfBBTG9iXIzyga6xV7RAur2j34dLGB3jqTDuTMo\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"OG2eJmUM94CCKl8SiFU2MAHURrbFWQJmqwnrkeVPSw533_yRjAL-SlrxogonJpsl\",\n          \"y\": \"suMc0ckI46jPlM0dn7O_4fIpxFAD74LrkOUO_tEKeHD1opEoK7H2iE-1STzjflEm\"\n        }\n      },\n      \"encrypted_key\": \"sAN-AeA0ZtInrhJYtzkNnWooDmXOOYo4mD1hMps8aV2Iw84GheOuMw\"\n    }\n  ],\n  \"aad\": \"jgz9Cgt6lep5QPX0-GCkOMXujjRYgfiTslwut8BdX-0\",\n  \"iv\": \"iHzMT8jUCFNsqsZY\",\n  \"ciphertext\": \"IiPn4-09-MFtJggB5yE\",\n  \"tag\": \"Na9kW8Fpw5j4IJ-fdf4jNA\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#113-nist-p-521-keys","title":"1.1.3 NIST P-521 keys","text":"<ul> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AHrw8TsyZzIkINFPCAS54Y7UoCI1XAlim95ROPykpjo4q2LvW_VWeBtJLU2SuqTFG4WX9VBzMg5Rq4gMj4oCpMFb\",\n  \"y\": \"AUs4vywsYYuRP0LhFvyI_ippvSY6Tv1S8sEzojd41Ubo86bFlCj5c_wHX2N6hplMU01WAcebPWc24plqF39pkNrK\",\n  \"d\": \"AEklgm76AbNl_nydbcINMgytfoZGRMI1mxfGcIiqw-KHENQMtlujImJrKMUd32njHS1M9e-WqAS8AHLoVdBZmkOo\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>9Miv3vUT2vQL0X80PyrLJm3bzGPuc_aKfPr4txRQIpA</code></li> <li>Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AcJh1U3InkhEW5uvh9x3H_ZkzSRY9aoleTYH0a_ZgVKhGrQrttUgQhzvdj8Oyy389Muu0l5slkKfE_FpNXUoSlq8\",\n  \"y\": \"AB8lDC62GR8b7lz_mboFcrBG4uAWNqQ-E-k4tYqBu8xJOV-v68FeuJKwC9WGFOiIUaCwSGUB4-cYeFPIxq9hxD7Y\",\n  \"d\": \"AXTDpK0Eu6EEZliWHe-zgiY1s23sTepAgmP8KeVTOXeeCnCL12pK4mc-UR9NpEYrxBp_A5srbhzNR5x7mZ1G4kLf\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>l4-wvmALQDp4g-UpilwCHmLZ_zUGfNawYSWQMoLphIk</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"AA63cinH0aZ7e0sLBFx0s3MKQTfvdFjSMVMQHpp5qIF6pWaxV9TrqXkJYkR2fuMqvIRSlH5mMK73kNfEubrvsd7H\",\n  \"y\": \"AY88QmJlRbAbCY9UyeDK0pYFHbSxgdMCauV2GC-W2w5uJekAWoeO9KxSY215W60whRHGRctrTc7LodcV8y7UKOyx\",\n  \"d\": \"AU4kFJPY9rZA89-ZYvoZX_qKPglplaWZdFKU3ZzjZvNt7rBBUuKumsf_khTFF8q-LxJKd11B0rng3PIQRuob4JW-\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>Ev1dKdei9chrjW2-l4bjdXXF5GDZ7CqTcQlGg1W_U24</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>9Miv3vUT2vQL0X80PyrLJm3bzGPuc_aKfPr4txRQIpA.Ev1dKdei9chrjW2-l4bjdXXF5GDZ7CqTcQlGg1W_U24.l4-wvmALQDp4g-UpilwCHmLZ_zUGfNawYSWQMoLphIk</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>uLMTdeuniYvCFTQTamK0pZwFVgkJooGL37HZLm8PVkM</code></li> <li>JWE: <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"QWNnNWlNaUNjNkozMFg5R3lrTXl4R0dobFFrXzFhRlhJTDQ1cF9DT2l3ODVscFVyR1BOSnNKTVRrdTRHYnlMdndlam9jVHp5ZVZjMUxrX1RWa3o0UmZ4YQ\",\n        \"apv\": \"OU1pdjN2VVQydlFMMFg4MFB5ckxKbTNiekdQdWNfYUtmUHI0dHhSUUlwQQ\",\n        \"kid\": \"9Miv3vUT2vQL0X80PyrLJm3bzGPuc_aKfPr4txRQIpA\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"Acg5iMiCc6J30X9GykMyxGGhlQk_1aFXIL45p_COiw85lpUrGPNJsJMTku4GbyLvwejocTzyeVc1Lk_TVkz4Rfxa\",\n          \"y\": \"AQgFgsVvOfebXZFk8TiBAJef9h6sVpQSJXed0xG3IolDYIllQ_OyQdlFpKHl2xCjgVxRihdf7mS_3SCzEtrcjEzy\"\n        }\n      },\n      \"encrypted_key\": \"juXV2ZGX2MjF1FgjTWke3MTkODrdpqZ_k-5IVqZ568bvN12i8W_KaQ\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"QVJLTGZTNWVoeUlacV9UWmJpbXdESndpYVBsckNMU2RqdG9aVFJSeTl0QVZQelQxbnlub1BYRWZIOHNNNklucDVKdWhvc3BHSVMxQzkzSk01Z1RkNzRtaQ\",\n        \"apv\": \"OU1pdjN2VVQydlFMMFg4MFB5ckxKbTNiekdQdWNfYUtmUHI0dHhSUUlwQQ\",\n        \"kid\": \"l4-wvmALQDp4g-UpilwCHmLZ_zUGfNawYSWQMoLphIk\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"ARKLfS5ehyIZq_TZbimwDJwiaPlrCLSdjtoZTRRy9tAVPzT1nynoPXEfH8sM6Inp5JuhospGIS1C93JM5gTd74mi\",\n          \"y\": \"Ad5hB3rVVxTqvSsiN7NNbClumX-AWTV6r29CHz2Jbcgo5tunFz-5-CwP6EvQNkFrzrOxQ5ViOW5F3pYV-yoksLgO\"\n        }\n      },\n      \"encrypted_key\": \"H-B3FBmwlGFIEtdfWti6tD8LwtuokxxPam5XO3V7wwWNoJ5sEy-LlA\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"QWRTZUxrVWxadHpXRkNDODBvNVYtYTB3Mjl3MjM2OWtLRXlPbUtiQzItVlV4ZEo0OVdBUV9rTVhTempNaE1ON1VMc25mT3pEWFp1QkhwZUVRTU1zbWF5VA\",\n        \"apv\": \"OU1pdjN2VVQydlFMMFg4MFB5ckxKbTNiekdQdWNfYUtmUHI0dHhSUUlwQQ\",\n        \"kid\": \"Ev1dKdei9chrjW2-l4bjdXXF5GDZ7CqTcQlGg1W_U24\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"AdSeLkUlZtzWFCC80o5V-a0w29w2369kKEyOmKbC2-VUxdJ49WAQ_kMXSzjMhMN7ULsnfOzDXZuBHpeEQMMsmayT\",\n          \"y\": \"AJKQo494spZjUW85ika3qNyLJJiv_J3FpsYnZt-Ml3q8IqXlHqQV_Nl3s7yn_pq8RWXl_yvo1NPiDWpoDMZ3sUNw\"\n        }\n      },\n      \"encrypted_key\": \"53dtd9R0bbGK96jsPJRu2woQJC7-yBaN-xDw5xSp-pwpCKg1idnZ5w\"\n    }\n  ],\n  \"aad\": \"uLMTdeuniYvCFTQTamK0pZwFVgkJooGL37HZLm8PVkM\",\n  \"iv\": \"11_dMZoXv9OaPIR2\",\n  \"ciphertext\": \"ofWv6sUZdYF3rX9A-jQ\",\n  \"tag\": \"TyH-Abl3XTGlkUgjHCE-Vw\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#114-x25519-keys","title":"1.1.4 X25519 keys","text":"<ul> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"2kvTqkwVF-YSurN533fi-ZDF4PbLbqa7ohC--DJa0nA\",\n  \"d\": \"sPUMndizynb_q6_u9fkbuU8V3I062-RlL114YnJ7KWY\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>eFf9x4K6jhnmAEvveQJo5rIQl32rZooOaNwlJsLf5JQ</code></li> <li>Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"cb-5cmxUy7xCfQCz0pEjYOGJOp0nf3cH7TU6siQ49wU\",\n  \"d\": \"oCw27m5T-QPr48F_f-CRWWqFgtFxpPISExMhSYQJmF8\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>NaUTcaFDyI3Ss48zMmeg1Dal0vhUpOYpWdwfKd2T2S8</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"pW_fX347OhGgYURSvuM5-NSKw7CgHzCuOZt5ovQCa3E\",\n  \"d\": \"sEZYN-iNbQ22ds1fC_hYgrp7PKbzAtiHqxPhvzon9HE\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>hzSul1PikxGRl7k_QdDfCCRMZP4POmt5eNYN0pbjSzE</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>NaUTcaFDyI3Ss48zMmeg1Dal0vhUpOYpWdwfKd2T2S8.eFf9x4K6jhnmAEvveQJo5rIQl32rZooOaNwlJsLf5JQ.hzSul1PikxGRl7k_QdDfCCRMZP4POmt5eNYN0pbjSzE</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>7iRNh25gyaA9Bpnx7axAbyyvbh-bXaPOz8SgvgGksNc</code></li> <li>JWE: <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"Q21aM1gzRFBnZFdQWjRKZFF4VVNMSjBKaEtRRXpJZWphV2cxT04tSE13WQ\",\n        \"apv\": \"ZUZmOXg0SzZqaG5tQUV2dmVRSm81cklRbDMyclpvb09hTndsSnNMZjVKUQ\",\n        \"kid\": \"eFf9x4K6jhnmAEvveQJo5rIQl32rZooOaNwlJsLf5JQ\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"CmZ3X3DPgdWPZ4JdQxUSLJ0JhKQEzIejaWg1ON-HMwY\"\n        }\n      },\n      \"encrypted_key\": \"ZFibn07y4G88HTB6haGfKJLQGWi2a25UVlioG93hgjs2BDIRaWRqzw\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"cU9MdWVjZmdaamJkOVRQYV9qbG5CeFAyak9FQjdOVkZKaGZ6UEk1OFNWOA\",\n        \"apv\": \"ZUZmOXg0SzZqaG5tQUV2dmVRSm81cklRbDMyclpvb09hTndsSnNMZjVKUQ\",\n        \"kid\": \"NaUTcaFDyI3Ss48zMmeg1Dal0vhUpOYpWdwfKd2T2S8\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"qOLuecfgZjbd9TPa_jlnBxP2jOEB7NVFJhfzPI58SV8\"\n        }\n      },\n      \"encrypted_key\": \"EKpcwck9zE0WjEq9E60dm_OJY0U2e1UlUAZE8LYfURo_saE2yzxx_A\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"RE1IOGFVVlpUZ2FXaFNaOUFtdFNDQ2M1aUZEbERCeDZnMC1URHpUTFZYUQ\",\n        \"apv\": \"ZUZmOXg0SzZqaG5tQUV2dmVRSm81cklRbDMyclpvb09hTndsSnNMZjVKUQ\",\n        \"kid\": \"hzSul1PikxGRl7k_QdDfCCRMZP4POmt5eNYN0pbjSzE\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"DMH8aUVZTgaWhSZ9AmtSCCc5iFDlDBx6g0-TDzTLVXQ\"\n        }\n      },\n      \"encrypted_key\": \"OeemM4fMI9538IcvG3OwhuVtugrRIoIJEB5iAVZBl7Q59yRr5VZTPQ\"\n    }\n  ],\n  \"aad\": \"7iRNh25gyaA9Bpnx7axAbyyvbh-bXaPOz8SgvgGksNc\",\n  \"iv\": \"9deRACZyiau7rIIc\",\n  \"ciphertext\": \"ombMWgwtw2QSfALdiDk\",\n  \"tag\": \"yRwaSiGsQCqYjIdMSwPPNg\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#12-single-recipient-jwes","title":"1.2 Single Recipient JWEs","text":"<p>Packing a message with 1 recipient using the Flattened JWE JSON serialization and Compact JWE serialization formats as mentioned in the notes above.</p>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#121-nist-p-256-key","title":"1.2.1 NIST P-256 key","text":"<ul> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"2fpy_fK5FCsap0EbU1Om7QXoVoyvBv8gfdHY3ufIS9w\",\n  \"y\": \"TtVOc9c8ejMeqeaUs1CMS79w0-Al02Fw25WdVEb0DiI\",\n  \"d\": \"kEWLCAyDL8mgDLNnlb1am_B8wcaGAe7ViXx1tqKWTVc\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>s6-ZhI1hpx0kM3pDgOrVQs6mRd_8KfEXUkLg8lK7XNA</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImFwdSI6IlJuY3lOa2RuVkZJME0ycHhORnB4Wm1GUlJqQkxjMk54U2poNlpFeFliMTlyVm0xZlNtRkJVbHBHVlEiLCJhcHYiOiJjell0V21oSk1XaHdlREJyVFROd1JHZFBjbFpSY3padFVtUmZPRXRtUlZoVmEweG5PR3hMTjFoT1FRIiwiY3R5IjoiYXBwbGljYXRpb24vZGlkY29tbS1wbGFpbitqc29uIiwiZW5jIjoiQTI1NkdDTSIsImVwayI6eyJjcnYiOiJQLTI1NiIsImt0eSI6IkVDIiwieCI6IkZ3MjZHZ1RSNDNqcTRacWZhUUYwS3NjcUo4emRMWG9fa1ZtX0phQVJaRlUiLCJ5IjoiNENfMk00V2dkcVp5cGdkaVVpMlZCQWsyVXFmYlJvU1AxaUQ3WHIzVGJJZyJ9LCJraWQiOiJzNi1aaEkxaHB4MGtNM3BEZ09yVlFzNm1SZF84S2ZFWFVrTGc4bEs3WE5BIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"encrypted_key\": \"l99n6MvHGvUKRrPORElnlerqmmhQc1WMzJ2pxt6H5gaSWPPsj4Gp0A\",\n  \"iv\": \"CKm9svwMrrXarfG2\",\n  \"ciphertext\": \"k_eAXa-uMtMYSVgJO0A\",\n  \"tag\": \"1cYhCprkvxYYfyNp_fJGUQ\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is: <code>eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImFwdSI6IlJuY3lOa2RuVkZJME0ycHhORnB4Wm1GUlJqQkxjMk54U2poNlpFeFliMTlyVm0xZlNtRkJVbHBHVlEiLCJhcHYiOiJjell0V21oSk1XaHdlREJyVFROd1JHZFBjbFpSY3padFVtUmZPRXRtUlZoVmEweG5PR3hMTjFoT1FRIiwiY3R5IjoiYXBwbGljYXRpb24vZGlkY29tbS1wbGFpbitqc29uIiwiZW5jIjoiQTI1NkdDTSIsImVwayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2IiwieCI6IkZ3MjZHZ1RSNDNqcTRacWZhUUYwS3NjcUo4emRMWG9fa1ZtX0phQVJaRlUiLCJ5IjoiNENfMk00V2dkcVp5cGdkaVVpMlZCQWsyVXFmYlJvU1AxaUQ3WHIzVGJJZyJ9LCJraWQiOiJzNi1aaEkxaHB4MGtNM3BEZ09yVlFzNm1SZF84S2ZFWFVrTGc4bEs3WE5BIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9.l99n6MvHGvUKRrPORElnlerqmmhQc1WMzJ2pxt6H5gaSWPPsj4Gp0A.CKm9svwMrrXarfG2.k_eAXa-uMtMYSVgJO0A.1cYhCprkvxYYfyNp_fJGUQ</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-ES+A256KW\",\n  \"apu\": \"RncyNkdnVFI0M2pxNFpxZmFRRjBLc2NxSjh6ZExYb19rVm1fSmFBUlpGVQ\",\n  \"apv\": \"czYtWmhJMWhweDBrTTNwRGdPclZRczZtUmRfOEtmRVhVa0xnOGxLN1hOQQ\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"A256GCM\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-256\",\n    \"x\": \"Fw26GgTR43jq4ZqfaQF0KscqJ8zdLXo_kVm_JaARZFU\",\n    \"y\": \"4C_2M4WgdqZypgdiUi2VBAk2UqfbRoSP1iD7Xr3TbIg\"\n  },\n  \"kid\": \"s6-ZhI1hpx0kM3pDgOrVQs6mRd_8KfEXUkLg8lK7XNA\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#122-nist-p-384-key","title":"1.2.2 NIST P-384 key","text":"<ul> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"lb17x-OBz2i1kQbkRtSKD3TY1MwIfUMyM8YtqXZXMj884hLJH2QtxmUWKyXIprcn\",\n  \"y\": \"PlT4CInTrA5zAroqwyww0BL6EipnEBTrtbWID8nADz6LFpf_27qlxIARy_iU5OcN\",\n  \"d\": \"JJgpIqGS5JuiKRnsEgGNlYw39pz-XGrsrmniuxlSik0BLwdb8-0K8Xxuqo6yW6NE\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>8wPpWWlLiMBYltw6AoWG3Z_SfgWmXanBHSwZFpQJ0Q0</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImFwdSI6ImNWSkZUMncwWTI5bmJUUkZhWGd3TURGd04zSXpaREl5U0VaQ2FXcHZOV2hmT1RGRE9HOTNjVU5yU2pSdlZWZzFRemh6ZUdOd00zTlhTMXBEZEZaWU13IiwiYXB2IjoiT0hkUWNGZFhiRXhwVFVKWmJIUjNOa0Z2VjBjeldsOVRabWRYYlZoaGJrSklVM2RhUm5CUlNqQlJNQSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsiY3J2IjoiUC0zODQiLCJrdHkiOiJFQyIsIngiOiJxUkVPbDRjb2dtNEVpeDAwMXA3cjNkMjJIRkJpam81aF85MUM4b3dxQ2tKNG9VWDVDOHN4Y3Azc1dLWkN0VlgzIiwieSI6Im5FbmRyZXVPNVFEWFp5eGVmWkJWRDhJeU53WkJER1AwZlJHdXN1LWZXV0NmWlJBdUVsNkZIaXMtSFRNS1puY0UifSwia2lkIjoiOHdQcFdXbExpTUJZbHR3NkFvV0czWl9TZmdXbVhhbkJIU3daRnBRSjBRMCIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ\",\n  \"encrypted_key\": \"OyvZQT0HdCIgDTQKgSbnMfX6iQvPVkOlurgNRqyZlyxj6XeZROYCEQ\",\n  \"iv\": \"sGHLr4VNPKylOCn7\",\n  \"ciphertext\": \"mfnbfoMx8LfXaWSY5po\",\n  \"tag\": \"_FxUsJeY06_bzGJ9vaAtMA\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImFwdSI6ImNWSkZUMncwWTI5bmJUUkZhWGd3TURGd04zSXpaREl5U0VaQ2FXcHZOV2hmT1RGRE9HOTNjVU5yU2pSdlZWZzFRemh6ZUdOd00zTlhTMXBEZEZaWU13IiwiYXB2IjoiT0hkUWNGZFhiRXhwVFVKWmJIUjNOa0Z2VjBjeldsOVRabWRYYlZoaGJrSklVM2RhUm5CUlNqQlJNQSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsIngiOiJxUkVPbDRjb2dtNEVpeDAwMXA3cjNkMjJIRkJpam81aF85MUM4b3dxQ2tKNG9VWDVDOHN4Y3Azc1dLWkN0VlgzIiwieSI6Im5FbmRyZXVPNVFEWFp5eGVmWkJWRDhJeU53WkJER1AwZlJHdXN1LWZXV0NmWlJBdUVsNkZIaXMtSFRNS1puY0UifSwia2lkIjoiOHdQcFdXbExpTUJZbHR3NkFvV0czWl9TZmdXbVhhbkJIU3daRnBRSjBRMCIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ.OyvZQT0HdCIgDTQKgSbnMfX6iQvPVkOlurgNRqyZlyxj6XeZROYCEQ.sGHLr4VNPKylOCn7.mfnbfoMx8LfXaWSY5po._FxUsJeY06_bzGJ9vaAtMA</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-ES+A256KW\",\n  \"apu\": \"cVJFT2w0Y29nbTRFaXgwMDFwN3IzZDIySEZCaWpvNWhfOTFDOG93cUNrSjRvVVg1QzhzeGNwM3NXS1pDdFZYMw\",\n  \"apv\": \"OHdQcFdXbExpTUJZbHR3NkFvV0czWl9TZmdXbVhhbkJIU3daRnBRSjBRMA\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"A256GCM\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-384\",\n    \"x\": \"qREOl4cogm4Eix001p7r3d22HFBijo5h_91C8owqCkJ4oUX5C8sxcp3sWKZCtVX3\",\n    \"y\": \"nEndreuO5QDXZyxefZBVD8IyNwZBDGP0fRGusu-fWWCfZRAuEl6FHis-HTMKZncE\"\n  },\n  \"kid\": \"8wPpWWlLiMBYltw6AoWG3Z_SfgWmXanBHSwZFpQJ0Q0\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#123-nist-p-521-key","title":"1.2.3 NIST P-521 key","text":"<ul> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AHrw8TsyZzIkINFPCAS54Y7UoCI1XAlim95ROPykpjo4q2LvW_VWeBtJLU2SuqTFG4WX9VBzMg5Rq4gMj4oCpMFb\",\n  \"y\": \"AUs4vywsYYuRP0LhFvyI_ippvSY6Tv1S8sEzojd41Ubo86bFlCj5c_wHX2N6hplMU01WAcebPWc24plqF39pkNrK\",\n  \"d\": \"AEklgm76AbNl_nydbcINMgytfoZGRMI1mxfGcIiqw-KHENQMtlujImJrKMUd32njHS1M9e-WqAS8AHLoVdBZmkOo\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>9Miv3vUT2vQL0X80PyrLJm3bzGPuc_aKfPr4txRQIpAs</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImFwdSI6ImRsRjZWRnBMWTFSS2JqUlROM0Z6Y0dGMFRGVldaR3hSVTB4clQyaDJUV2RuU0ZsaFRUaEZNRzFwZWpFemJtUXphRlEwUVVoR01XUm9WRWRPYTI5M09HUnlTVFZEU200dGRsbHdlbUZYWnkxcVoxSXRhWFEwIiwiYXB2IjoiT1UxcGRqTjJWVlF5ZGxGTU1GZzRNRkI1Y2t4S2JUTmlla2RRZFdOZllVdG1VSEkwZEhoU1VVbHdRUSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsiY3J2IjoiUC01MjEiLCJrdHkiOiJFQyIsIngiOiJBTDBNMDJTbkV5Wi1FdTZyS1dyUzFGWFpVRWk1RG9ieklJQjJHalBCTkpvczlkNTNkNFUtQUJ4ZFhZVXhqWktNUEhheU9RaVpfcjJLYzJsb1BvNEVmb3JlIiwieSI6IkFXSkxvVnNTS0l6SVF2VWtKVzIxakVmV2ZHTjhWck1tN2owSmtJb2JUVXlCSEJMa0o3SzFUU19zZ1FpOUkxb0tzRTJ5Mjh2WC1DREFKZGp3Z1FWNl9mLTIifSwia2lkIjoiOU1pdjN2VVQydlFMMFg4MFB5ckxKbTNiekdQdWNfYUtmUHI0dHhSUUlwQSIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ\",\n  \"encrypted_key\": \"rK_MtxEobFF8pyYU8T26U7LRlEdjm1ndq8sZoZ2h9BaAyuhE7bcuAA\",\n  \"iv\": \"X1V-4vkZ1qE3_Yhn\",\n  \"ciphertext\": \"XDf5mmhlDaJfTOp1z_4\",\n  \"tag\": \"se7e3wH5grcMEuJIAJbN9A\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImFwdSI6ImRsRjZWRnBMWTFSS2JqUlROM0Z6Y0dGMFRGVldaR3hSVTB4clQyaDJUV2RuU0ZsaFRUaEZNRzFwZWpFemJtUXphRlEwUVVoR01XUm9WRWRPYTI5M09HUnlTVFZEU200dGRsbHdlbUZYWnkxcVoxSXRhWFEwIiwiYXB2IjoiT1UxcGRqTjJWVlF5ZGxGTU1GZzRNRkI1Y2t4S2JUTmlla2RRZFdOZllVdG1VSEkwZEhoU1VVbHdRUSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsia3R5IjoiRUMiLCJjcnYiOiJQLTUyMSIsIngiOiJBTDBNMDJTbkV5Wi1FdTZyS1dyUzFGWFpVRWk1RG9ieklJQjJHalBCTkpvczlkNTNkNFUtQUJ4ZFhZVXhqWktNUEhheU9RaVpfcjJLYzJsb1BvNEVmb3JlIiwieSI6IkFXSkxvVnNTS0l6SVF2VWtKVzIxakVmV2ZHTjhWck1tN2owSmtJb2JUVXlCSEJMa0o3SzFUU19zZ1FpOUkxb0tzRTJ5Mjh2WC1DREFKZGp3Z1FWNl9mLTIifSwia2lkIjoiOU1pdjN2VVQydlFMMFg4MFB5ckxKbTNiekdQdWNfYUtmUHI0dHhSUUlwQSIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ.rK_MtxEobFF8pyYU8T26U7LRlEdjm1ndq8sZoZ2h9BaAyuhE7bcuAA.X1V-4vkZ1qE3_Yhn.XDf5mmhlDaJfTOp1z_4.se7e3wH5grcMEuJIAJbN9A</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-ES+A256KW\",\n  \"apu\": \"dlF6VFpLY1RKbjRTN3FzcGF0TFVWZGxRU0xrT2h2TWdnSFlhTThFMG1pejEzbmQzaFQ0QUhGMWRoVEdOa293OGRySTVDSm4tdllwemFXZy1qZ1ItaXQ0\",\n  \"apv\": \"OU1pdjN2VVQydlFMMFg4MFB5ckxKbTNiekdQdWNfYUtmUHI0dHhSUUlwQQ\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"A256GCM\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-521\",\n    \"x\": \"AL0M02SnEyZ-Eu6rKWrS1FXZUEi5DobzIIB2GjPBNJos9d53d4U-ABxdXYUxjZKMPHayOQiZ_r2Kc2loPo4Efore\",\n    \"y\": \"AWJLoVsSKIzIQvUkJW21jEfWfGN8VrMm7j0JkIobTUyBHBLkJ7K1TS_sgQi9I1oKsE2y28vX-CDAJdjwgQV6_f-2\"\n  },\n  \"kid\": \"9Miv3vUT2vQL0X80PyrLJm3bzGPuc_aKfPr4txRQIpA\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#124-x25519-key","title":"1.2.4 X25519 key","text":"<ul> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"2kvTqkwVF-YSurN533fi-ZDF4PbLbqa7ohC--DJa0nA\",\n  \"d\": \"sPUMndizynb_q6_u9fkbuU8V3I062-RlL114YnJ7KWY\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>eFf9x4K6jhnmAEvveQJo5rIQl32rZooOaNwlJsLf5JQ</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImFwdSI6IlluQldTM1IyVDJoWGJXOVRRMUJTV21oUk1HdFVaVzlYVDNFMWVrMXZTWGxhY0RCMVlrOU9XVTVXZHciLCJhcHYiOiJaVVptT1hnMFN6WnFhRzV0UVVWMmRtVlJTbTgxY2tsUmJETXljbHB2YjA5aFRuZHNTbk5NWmpWS1VRIiwiY3R5IjoiYXBwbGljYXRpb24vZGlkY29tbS1wbGFpbitqc29uIiwiZW5jIjoiQTI1NkdDTSIsImVwayI6eyJjcnYiOiJYMjU1MTkiLCJrdHkiOiJPS1AiLCJ4IjoiYnBWS3R2T2hXbW9TQ1BSWmhRMGtUZW9XT3E1ek1vSXlacDB1Yk9OWU5WdyJ9LCJraWQiOiJlRmY5eDRLNmpobm1BRXZ2ZVFKbzVySVFsMzJyWm9vT2FOd2xKc0xmNUpRIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"encrypted_key\": \"Pe7sGWcXxY9V7xdKWdpa5GvVinr_YWITRIVY8ic7WmKwY-Lh-3OJdA\",\n  \"iv\": \"Rx__OGcTo72Lv6jG\",\n  \"ciphertext\": \"UEFI2_OqNMki1cXraJA\",\n  \"tag\": \"Hc6WxwF2YGvewcWFmhzkrw\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImFwdSI6IlluQldTM1IyVDJoWGJXOVRRMUJTV21oUk1HdFVaVzlYVDNFMWVrMXZTWGxhY0RCMVlrOU9XVTVXZHciLCJhcHYiOiJaVVptT1hnMFN6WnFhRzV0UVVWMmRtVlJTbTgxY2tsUmJETXljbHB2YjA5aFRuZHNTbk5NWmpWS1VRIiwiY3R5IjoiYXBwbGljYXRpb24vZGlkY29tbS1wbGFpbitqc29uIiwiZW5jIjoiQTI1NkdDTSIsImVwayI6eyJrdHkiOiJPS1AiLCJjcnYiOiJYMjU1MTkiLCJ4IjoiYnBWS3R2T2hXbW9TQ1BSWmhRMGtUZW9XT3E1ek1vSXlacDB1Yk9OWU5WdyJ9LCJraWQiOiJlRmY5eDRLNmpobm1BRXZ2ZVFKbzVySVFsMzJyWm9vT2FOd2xKc0xmNUpRIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9.Pe7sGWcXxY9V7xdKWdpa5GvVinr_YWITRIVY8ic7WmKwY-Lh-3OJdA.Rx__OGcTo72Lv6jG.UEFI2_OqNMki1cXraJA.Hc6WxwF2YGvewcWFmhzkrw</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-ES+A256KW\",\n  \"apu\": \"YnBWS3R2T2hXbW9TQ1BSWmhRMGtUZW9XT3E1ek1vSXlacDB1Yk9OWU5Wdw\",\n  \"apv\": \"ZUZmOXg0SzZqaG5tQUV2dmVRSm81cklRbDMyclpvb09hTndsSnNMZjVKUQ\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"A256GCM\",\n  \"epk\": {\n    \"kty\": \"OKP\",\n    \"crv\": \"X25519\",\n    \"x\": \"bpVKtvOhWmoSCPRZhQ0kTeoWOq5zMoIyZp0ubONYNVw\"\n  },\n  \"kid\": \"eFf9x4K6jhnmAEvveQJo5rIQl32rZooOaNwlJsLf5JQ\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#2-xc20p-content-encryption","title":"2 XC20P content encryption","text":""},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#21-multi-recipients-jwes","title":"2.1 Multi recipients JWEs","text":"<p>The packer generates the following protected headers for XC20P content encryption in the below examples with XC20P enc: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"XC20P\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ</code></p> <p>The same notes above apply here.</p>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#211-nist-p-256-keys","title":"2.1.1 NIST P-256 keys","text":"<ul> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"kdAHozUe6HOhNC9_jsOI60FuHa64zHSwcZa0l22rXX4\",\n  \"y\": \"Sj3iIz_HimnXgLRWU-x_gXjVyF2R0rh6OhuD3gzhUMw\",\n  \"d\": \"NTV27xYkYkwDNYePKHlh6CIYHunx-6rn80cSATOI7rI\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>Ivxk0K5tz7csR7MDXllXWd7YJTQF4pS8IHHkIdepgpk</code></li> <li>Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"sx1ZNsP2rUKuoN0Xe6m2_Zly8wM_-CpuCkDNaOjFYtA\",\n  \"y\": \"lTti40XRekPxw4IfpheZDCxilwEoEWWxyO8d77W_sOo\",\n  \"d\": \"WsHT1GiMy4mxsxQ7mPYtg5Mn18I8PU2wHPttVGEOnXk\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>tkAt85t250uQ3Q3d8W731YJfqF0t1cCwGwWqRxqyQhM</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"AQoZIqg1y0fZ1qvYM5YuinxRtOXa6dMSXfgdYBgsEks\",\n  \"y\": \"JRxsX-U6go0VqWtMFCPFbUNSsLJYiQH7ij2i4-FVQh0\",\n  \"d\": \"Joal2Lk5w6-_C_HpRr__ZtxtJccwjwHZ7RxZe1-CTjY\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>SoySkmiLdE4c7Dp5URlH-DMVNq6-fGrkSpIgzLTYez0</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>Ivxk0K5tz7csR7MDXllXWd7YJTQF4pS8IHHkIdepgpk.SoySkmiLdE4c7Dp5URlH-DMVNq6-fGrkSpIgzLTYez0.tkAt85t250uQ3Q3d8W731YJfqF0t1cCwGwWqRxqyQhM</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>uPokzMsXWxloZTnb2sXzz05KBc_SI1giMmHAenTyMjQ</code></li> <li>Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"R1NNbnFqcGFQMlltUlRNRTVrNVhYT3E2M3FzZjd2emVtbnY5NENVTm9faw\",\n        \"apv\": \"SXZ4azBLNXR6N2NzUjdNRFhsbFhXZDdZSlRRRjRwUzhJSEhrSWRlcGdwaw\",\n        \"kid\": \"Ivxk0K5tz7csR7MDXllXWd7YJTQF4pS8IHHkIdepgpk\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"GSMnqjpaP2YmRTME5k5XXOq63qsf7vzemnv94CUNo_k\",\n          \"y\": \"tDCIMv5gZqyjZmHYvbHxUQO1zN7fH0n9athoWGlO8nI\"\n        }\n      },\n      \"encrypted_key\": \"n63_NKMEy_KOb_34nrTX_Yvbx3Sliee9yh3ZSqs6nm5vhAuCoBMoU40fSpZMB07QLdXKfrRjB4A-WoL_MjTpcpOZnxc1v2s-\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"N1ZNVG00NEFqc0J3amt6WU1STDk5SURRZUh6aWZaa0Q5Q0hSajJJdGtkOA\",\n        \"apv\": \"SXZ4azBLNXR6N2NzUjdNRFhsbFhXZDdZSlRRRjRwUzhJSEhrSWRlcGdwaw\",\n        \"kid\": \"tkAt85t250uQ3Q3d8W731YJfqF0t1cCwGwWqRxqyQhM\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"7VMTm44AjsBwjkzYMRL99IDQeHzifZkD9CHRj2Itkd8\",\n          \"y\": \"NnVWH1gP7qdqzv4Go-1lT_U02i6fJHhmZO33jt4R0Ys\"\n        }\n      },\n      \"encrypted_key\": \"V3Y_kLiogDKAa4p3MNyfh1IOfexv8rLJsZf5idwI2wJDngYzhNyzaV4kqJMMW6qyMaE4bX5LY-qRP4sPcYPwntMj70LUaC6I\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"NzJQTnJ4a1A2V3JCcV9wUkU4VU42T0I3WHFKUXJuZEZHZ3dERVloR21kdw\",\n        \"apv\": \"SXZ4azBLNXR6N2NzUjdNRFhsbFhXZDdZSlRRRjRwUzhJSEhrSWRlcGdwaw\",\n        \"kid\": \"SoySkmiLdE4c7Dp5URlH-DMVNq6-fGrkSpIgzLTYez0\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"72PNrxkP6WrBq_pRE8UN6OB7XqJQrndFGgwDEYhGmdw\",\n          \"y\": \"gDy2dRBTwt1tQBBSnztN0AqvzCu07yFN9FgG109ytsc\"\n        }\n      },\n      \"encrypted_key\": \"2b4op-H7wPoyzno3Krv65rOal2HNmaiDHnjGTywcHAppz-EgHS7hiqANeRCipCNhPj7VvZqe1PWf2m0qLIdBuUv7ryo_nw9E\"\n    }\n  ],\n  \"aad\": \"uPokzMsXWxloZTnb2sXzz05KBc_SI1giMmHAenTyMjQ\",\n  \"iv\": \"KShKEagQokU3UTGeYXw7LwWFankH-zK7\",\n  \"ciphertext\": \"6Z5YKgYQSmxSCtns064\",\n  \"tag\": \"hhW1Y5WgRM2t8-NiUMmKJw\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#212-nist-p-384-keys","title":"2.1.2 NIST P-384 keys","text":"<ul> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"5aCpGZXwubdOSedZl1wc5PHB175a990-bRo2QKzju6uyeXD6hBKcB6vUijQRILMr\",\n  \"y\": \"TeUA_qsYU8YmbHPA58QJuAJiUe0BEbi8Vuq88ZEWLudhJa4Dp5mBKuFEeJQcOQCa\",\n  \"d\": \"wTv7Yh4bZAfCfmz0qL_lKJNlMRYuXjWzE63p7y3mZW8DRtN5LgOE25QKO9v0xgKN\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>35E0yg0TinUSym5bQ5FnUgWirIrfK81p-QCxW7VzCrE</code></li> <li>Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"xYFotAHw0kaqsgkW-3ZirL2p3HC0tJCrrNsK-1MfgoUahWpoDiUpEapuLZrO_hz3\",\n  \"y\": \"LLUQ5gRSwn5x0sQJrByWSdWdqojAhizpsx9GPjvPP9uM4gv7jKUEoi0A-2doNSQR\",\n  \"d\": \"OLPQ8giwvg-pKMMaYTGB3O4RGNPtlX-tRZi3ltUb305nPMsuxplI71OQfTH3-Leq\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>wnJRuK09BydTKCPX9DEsf2hxSB1uzHdHrjLTtsiPUZw</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"DWdQi5HdkPpUEqHtQrLU8xR6hW3_IO-8RPcOY4_aI0VACCO9e8WNCFAcjAja5Q8Y\",\n  \"y\": \"jTan4mkzX1uRU9FRIvZgE1NKS-fUe86cl_xmLJ2jPl-A-EXmTHExVT8q63iVnvSC\",\n  \"d\": \"WnCGfWiiOCglkYWQh1t-KM_A8Pb_HXgUXEJFjg7iWT3SYUL2tgMQQ5w9IUNE-D0r\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>j9ZMlUQX9m9t8_6RmshAfMwHTIOE9_0Mv5bd5bQ4nKw</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>35E0yg0TinUSym5bQ5FnUgWirIrfK81p-QCxW7VzCrE.j9ZMlUQX9m9t8_6RmshAfMwHTIOE9_0Mv5bd5bQ4nKw.wnJRuK09BydTKCPX9DEsf2hxSB1uzHdHrjLTtsiPUZw</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>kOd8LfamiqCqZa4kZJPR0M3k11OjHo1dQgdgaI2HreU</code></li> <li>JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"Zmw3NTdwRFlKVE16YlcwVmdfUWgzTDlrZlRoQ25Dd25uaU81YlBmVkwwUFgxV19LbWpfRzVIT2VDV2NyMEdacQ\",\n        \"apv\": \"MzVFMHlnMFRpblVTeW01YlE1Rm5VZ1dpcklyZks4MXAtUUN4VzdWekNyRQ\",\n        \"kid\": \"35E0yg0TinUSym5bQ5FnUgWirIrfK81p-QCxW7VzCrE\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"fl757pDYJTMzbW0Vg_Qh3L9kfThCnCwnniO5bPfVL0PX1W_Kmj_G5HOeCWcr0GZq\",\n          \"y\": \"moRQSUo5C95n_W5H79i_HWYAIcpmX9Iq2OcuBRe4R9pXmW_p1_dbz7YKSXbJLpEo\"\n        }\n      },\n      \"encrypted_key\": \"fb6sCiAeFzPcfvHdIMKm051fkVioxgBKA6w3sIkw9t_mleCHe_bjFzK9_CfMA6E0aO8Y40WonGWYZ8oKIgRvItNWJsph6zr9\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"ZlcyRHFxR25SaFZHOXlKckN2TWZVRmJlR1RZRl9JWjJYQ1pPcGNvei1vSDJ2aVlERU54Wi1leGJ6c0l1bkoyNQ\",\n        \"apv\": \"MzVFMHlnMFRpblVTeW01YlE1Rm5VZ1dpcklyZks4MXAtUUN4VzdWekNyRQ\",\n        \"kid\": \"wnJRuK09BydTKCPX9DEsf2hxSB1uzHdHrjLTtsiPUZw\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"fW2DqqGnRhVG9yJrCvMfUFbeGTYF_IZ2XCZOpcoz-oH2viYDENxZ-exbzsIunJ25\",\n          \"y\": \"Pz-1Smflo-dAFZ0awotLqF0Qh5iurbbgcCJpN5ZnrrvBlnxiKuAD6o4ytxMS17f1\"\n        }\n      },\n      \"encrypted_key\": \"gGqdDnlCuymQYRwIIHU0Cv4BxUYpby8cjohgbfNc-3kilzLIXN0x53amLz6sxuFvvGjPMv7BykQfoQPZgXj5B5rN--3StojC\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"MTY0dUFMYXVkNmFLR29EMjF0NHd2dGN3QjRxUGNNRFlid3JWemVvY055Q05RelV1NlRTSVFEcExiT3pmMjJIeQ\",\n        \"apv\": \"MzVFMHlnMFRpblVTeW01YlE1Rm5VZ1dpcklyZks4MXAtUUN4VzdWekNyRQ\",\n        \"kid\": \"j9ZMlUQX9m9t8_6RmshAfMwHTIOE9_0Mv5bd5bQ4nKw\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"164uALaud6aKGoD21t4wvtcwB4qPcMDYbwrVzeocNyCNQzUu6TSIQDpLbOzf22Hy\",\n          \"y\": \"SmS8y6E1V87EkDIQfZVJGdyWPRR5gSQXIhNKUF4vDB1OYcMtG4AGFhHlMVNjCipa\"\n        }\n      },\n      \"encrypted_key\": \"ADkTont7J6MvkqtejyCZroaLhzBq6ehDlNJyiIsoV2L-vKOYWPfW2eyhk9_Q_Kc2mdfhsJeZ6S4YN2O1OVSvnGqho3zwKE_z\"\n    }\n  ],\n  \"aad\": \"kOd8LfamiqCqZa4kZJPR0M3k11OjHo1dQgdgaI2HreU\",\n  \"iv\": \"lhR0KWdWpo2TeiHgABGNLMYwGXmykQQX\",\n  \"ciphertext\": \"LMVb7K1-YqLUS9JtE0s\",\n  \"tag\": \"7UkWuQPffiWZIwS4sUc1Hg\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#213-nist-p-521-keys","title":"2.1.3 NIST P-521 keys","text":"<ul> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AIlOiZCrQMU83IOpoiMva75L_OqljXVakEJSjwAl5RaLmaNBZg-TXa0VKlAKTijGZAu_5gS_ZF82LRWDiltUHmX8\",\n  \"y\": \"AFXxgSPOlCNnHtRQE7JmngrT5jgc5kHhMJE82wvMYlyrUdB1kgjN8zJDKkMDJ_dw1U2bEKXmcoCepN654HqmCeNJ\",\n  \"d\": \"ASUBEC_crwIW50ke7p7EBjM0jnA3X7ziwT92TIVgHqTyFkEHKwuP_xbUSePfkhAgcEF2KHz48EgZJuDM6v4L2NXT\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>fr_FYdKBgF_lo1UzC133Tw382LhNDRk6TqwWUwYiytQ</code></li> <li>Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AT71NCmSChOaf38XudcZFpb7eS6GS3rRgjIeXC5AWm9uqjgk3XloPINvlOkATR9syfonjONi4dvgu6ED0gDKyni2\",\n  \"y\": \"AB6EuKG0Z5mnkw_Kk08EW1igFDoZ8tUzs67AoRrLM_CqufmehumGUBAAgPPyQ43HdZQRKn6UYaRn77JZ0kcUE8ZD\",\n  \"d\": \"AMYS0X7aTtbFL8gcSH8h0AkH1kfgJxqe-vyahUoijuM3WtKp0z7C0j-kT717p8xV4NEnIrP7IP9ewCdh21TwCfdJ\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>z70hxN-69UU6IBsqxWMsKa5LqSnCGhd0BKMihYIeHYM</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AcRZHKNmVZlxrKIcBsX-Z8KaGCJfPirBqOBWDylsVJCwvjEEMfJFS2GZtPwfQI5P561XAxjtb0ARPtucoyh5n4_Q\",\n  \"y\": \"AaU8wdiQUItNWJnDrgMK84HhyloKQyXWEYZoDEjppL4kXvIV4CUhfYkTXnTWACUgnVG1uXdycmJ-XhgqPGfezQVb\",\n  \"d\": \"AKfdXHWLY7WqaVVVLFBRyU7fd3EpfiQJW83IkuCk4tJ51PIO6Jzq17H0RI9XjK1YThz-cV1ZBXw9Q7ezDFusgL3k\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>bU2CyYAuV1kJtU8vTE27PaOh20yTgKBSThtjrYHedf8</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>bU2CyYAuV1kJtU8vTE27PaOh20yTgKBSThtjrYHedf8.fr_FYdKBgF_lo1UzC133Tw382LhNDRk6TqwWUwYiytQ.z70hxN-69UU6IBsqxWMsKa5LqSnCGhd0BKMihYIeHYM</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>gyaNc9X50RymOfupxfij36JjhkUG4SEiI4P8LQ0JCvI</code></li> <li>JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"QVdYTV9BOVF2WUZnUFYwMTRmUzk5LUNvX2dyS3BTZi1xbTJmeDdYRFpzekJrT2V3ZHlOSUp5S1gteFdQUUM1RWcwc0gtR0VnTGNWNXNRZThrNktuQWZYeA\",\n        \"apv\": \"ZnJfRllkS0JnRl9sbzFVekMxMzNUdzM4MkxoTkRSazZUcXdXVXdZaXl0UQ\",\n        \"kid\": \"fr_FYdKBgF_lo1UzC133Tw382LhNDRk6TqwWUwYiytQ\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"AWXM_A9QvYFgPV014fS99-Co_grKpSf-qm2fx7XDZszBkOewdyNIJyKX-xWPQC5Eg0sH-GEgLcV5sQe8k6KnAfXx\",\n          \"y\": \"ANlcV5mvTqpzGF8loKsBjC_UFkfg260SFwrabuTBn_4oi1l5wKx7yootfvqrgGG1ivbuMIZ4NndJsbreyUywddQS\"\n        }\n      },\n      \"encrypted_key\": \"SkZaMkjfoo-0PPQvWXottqV3dwOhcY7rCDckVkPRlxbj8jb_m4veIu-nx8jnkJMLUVqguKD_JhZ78MRAEikPg-gARUKyVRKV\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"SElkUWNuaGluTUhhaEw1eDNsUGYxZWlrbW13NUFxNE9SSUpwTFhiQVV4NVJZbjF2dFVSeld4UHc0aU9nY1FOWjJCbEZVU21Md0FaUmhvdlFfb2J1MmZr\",\n        \"apv\": \"ZnJfRllkS0JnRl9sbzFVekMxMzNUdzM4MkxoTkRSazZUcXdXVXdZaXl0UQ\",\n        \"kid\": \"z70hxN-69UU6IBsqxWMsKa5LqSnCGhd0BKMihYIeHYM\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"AByHUHJ4YpzB2oS-cd5T39XopJpsOQKuDkSCaS12wFMeUWJ9b7VEc1sT8OIjoHEDWdgZRVEpi8AGUYaL0P6G7tn5\",\n          \"y\": \"AFbfZdEiMwMy4rN0hzMl3XQgBpE98gE8A37bLLLZi-wAbyuNBhhGCWjxc2XSCRTn9IxBSV72Q8lttaIPWTRGsJPZ\"\n        }\n      },\n      \"encrypted_key\": \"qgNULlqzY68vVzd07nuuuCSqDewr1mu45xhzCFriEdYNvoFmGl_elZua6r0gyknDsskbLOM_zAhg86Ieafn87YT-jOKZWXvB\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"QWNJU1U1bVJwemJrYUs5TUs0ZVNHWXFBNFo5TFVwOF8yNHkwUnhmazExby1GazNvazZCUzk2X3REeWlfM0Y0bDhDU3VyanA3bUxhMGp4YVJ6M1NZbDRRMw\",\n        \"apv\": \"ZnJfRllkS0JnRl9sbzFVekMxMzNUdzM4MkxoTkRSazZUcXdXVXdZaXl0UQ\",\n        \"kid\": \"bU2CyYAuV1kJtU8vTE27PaOh20yTgKBSThtjrYHedf8\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"AcISU5mRpzbkaK9MK4eSGYqA4Z9LUp8_24y0Rxfk11o-Fk3ok6BS96_tDyi_3F4l8CSurjp7mLa0jxaRz3SYl4Q3\",\n          \"y\": \"AYfx95SYdTrF5-FFJ6DX8YIQ3-kI3zA2huvwAoE5on4tczuZtRDxAnXocVXwydU_hYFICv4F1_U2wf2MZxu5EjgO\"\n        }\n      },\n      \"encrypted_key\": \"N38f1rvfk00bHCRbAkMajaCmwIM6C96QNs5ck5i6EhoyONADKitu1E7FpMtwA7IBkLZXSPAz_2RRQg_yp494uh5unNgeIAsm\"\n    }\n  ],\n  \"aad\": \"gyaNc9X50RymOfupxfij36JjhkUG4SEiI4P8LQ0JCvI\",\n  \"iv\": \"y3t1nlPy-e5KlPZmhH6yvXweEnB50cW9\",\n  \"ciphertext\": \"twYiHmEUk1QZw-XbLbY\",\n  \"tag\": \"WsYbX9YDCcIAorqBbS2X_w\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#214-x25519-keys","title":"2.1.4 X25519 keys","text":"<ul> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"h5iIEBNlEHEhCgYLXAOXOofqYEA9Jo0Q1NUggjdwrVw\",\n  \"d\": \"oEGk3DVSpzrZR6mcUF0EXmijrATej7xnPdlcPJDz53M\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>S-qQ_rRIsrscxdmzuplVLW5bqoxj08KO6BBkLZAxh-E</code></li> <li>Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"xawtbSFE5QYe7KDcYRBlnyozY9uPTzlRQ3gClzHzt2Q\",\n  \"d\": \"yC7gzjKFdFwsCA4x7QL0S-eRhI2H966MjTdNA8IrMFw\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>m8EQ2XejsBRZ8sieSLapsS4-tO9ZQNjjxtjL6DOhP64</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"cvxZ6JaCIfmrTXiyHYNyqmxRSsUF8TEabuWOcZdgLT0\",\n  \"d\": \"IM-XG4jc_Zyd5yWdv1i7vruFK4X2LzNTRicHvPZNznU\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>oz3AtqUGnNpsT6OugQksyvY52HI36kCBtXqLE4joP3M</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>S-qQ_rRIsrscxdmzuplVLW5bqoxj08KO6BBkLZAxh-E.m8EQ2XejsBRZ8sieSLapsS4-tO9ZQNjjxtjL6DOhP64.oz3AtqUGnNpsT6OugQksyvY52HI36kCBtXqLE4joP3M</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>Iri2F6uTNldPiiJNYNrlVb_Nt_c2XlPVdDKfmlnkBn4</code></li> <li>JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"eE9ZYmZrX0VLbmJaQmRoU1lPclI3NFVWWmlqZFU3LWg3ZF9aTkJ4VW1rMA\",\n        \"apv\": \"Uy1xUV9yUklzcnNjeGRtenVwbFZMVzVicW94ajA4S082QkJrTFpBeGgtRQ\",\n        \"kid\": \"S-qQ_rRIsrscxdmzuplVLW5bqoxj08KO6BBkLZAxh-E\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"xOYbfk_EKnbZBdhSYOrR74UVZijdU7-h7d_ZNBxUmk0\"\n        }\n      },\n      \"encrypted_key\": \"gPbf9-YZLPoEoKmaU70H8O9fsKiPy8rNiNuAvKog4AhGfy1axF4LuMdAZgO4EixyS4WC9V6JnfaYxmt3tFiCx80YXZrVlTBO\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"eU9MMUM0blZzTzRTa1ROWDVRTlVCVl9iVmhJeVd1ZGdKOTlkRWdURDl5cw\",\n        \"apv\": \"Uy1xUV9yUklzcnNjeGRtenVwbFZMVzVicW94ajA4S082QkJrTFpBeGgtRQ\",\n        \"kid\": \"m8EQ2XejsBRZ8sieSLapsS4-tO9ZQNjjxtjL6DOhP64\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"yOL1C4nVsO4SkTNX5QNUBV_bVhIyWudgJ99dEgTD9ys\"\n        }\n      },\n      \"encrypted_key\": \"dsWHHkRbT9BWdgBl5MAUgNTenqiEjR4Z2cgaOLaraCDezRb051Z_muMo70-yJx1O9YDwLHq2V87dKQJX-byYtBeIR-5BubLm\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"RkdtN2t4aGJFNGVBLWJpM1l2WTZPNVBCd2YtTlhEZ29YaWwzS19zLW5tSQ\",\n        \"apv\": \"Uy1xUV9yUklzcnNjeGRtenVwbFZMVzVicW94ajA4S082QkJrTFpBeGgtRQ\",\n        \"kid\": \"oz3AtqUGnNpsT6OugQksyvY52HI36kCBtXqLE4joP3M\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"FGm7kxhbE4eA-bi3YvY6O5PBwf-NXDgoXil3K_s-nmI\"\n        }\n      },\n      \"encrypted_key\": \"sEygr10dbgwHRy8-ktu8jLcACTKD1g7LfEkUSV_mAZNr1P06RhijZTRq47xesJuPWF8lfkAsK-UETLJ92KGRmbgCdSHQQwaG\"\n    }\n  ],\n  \"aad\": \"Iri2F6uTNldPiiJNYNrlVb_Nt_c2XlPVdDKfmlnkBn4\",\n  \"iv\": \"MWxpdCQBhVoiskZF7QD3bLzgI-iBEE3O\",\n  \"ciphertext\": \"FtAX4yKH2a2dZqM6Zdk\",\n  \"tag\": \"lR8OsOJieRydzSvI-qpy5w\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#22-single-recipient-jwes","title":"2.2 Single Recipient JWEs","text":"<p>Packing a message with 1 recipient using the Flattened JWE JSON serialization and the Compact JWE serialization formats as mentioned in the notes above.</p>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#221-nist-p-256-key","title":"2.2.1 NIST P-256 key","text":"<ul> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"kdAHozUe6HOhNC9_jsOI60FuHa64zHSwcZa0l22rXX4\",\n  \"y\": \"Sj3iIz_HimnXgLRWU-x_gXjVyF2R0rh6OhuD3gzhUMw\",\n  \"d\": \"NTV27xYkYkwDNYePKHlh6CIYHunx-6rn80cSATOI7rI\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>Ivxk0K5tz7csR7MDXllXWd7YJTQF4pS8IHHkIdepgpk</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILUVTK1hDMjBQS1ciLCJhcHUiOiJUWEl4TnpCM2JqSTJXa00wY0Y5SFVDMTBNazlyVFd0ZmExOVJVRkYxY1hObk5IUlFNV0pMU0hCdk1BIiwiYXB2IjoiU1haNGF6QkxOWFI2TjJOelVqZE5SRmhzYkZoWFpEZFpTbFJSUmpSd1V6aEpTRWhyU1dSbGNHZHdhdyIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IlhDMjBQIiwiZXBrIjp7ImNydiI6IlAtMjU2Iiwia3R5IjoiRUMiLCJ4IjoiTXIxNzB3bjI2WkM0cF9HUC10Mk9rTWtfa19RUFF1cXNnNHRQMWJLSHBvMCIsInkiOiJ1MUMydEJuYlFwUS1YTWx0SHRFdWNJaFVod1FCeDBCbklLZFlkN3FLRVFFIn0sImtpZCI6Ikl2eGswSzV0ejdjc1I3TURYbGxYV2Q3WUpUUUY0cFM4SUhIa0lkZXBncGsiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"encrypted_key\": \"1k4IQgN6LIiV8mnNWUI2OyNXLRHvg75qZIyHf6_wtrBIYZlic1coUL3lekvesQpmLb1A9vip-pKi0yDKZOQIMtQS3TJ81EJJ\",\n  \"iv\": \"6Qky6FL-Uzpi5nvaZHobo3_8xqv-LF4h\",\n  \"ciphertext\": \"mqQ6nsR76RMLvNLkJgU\",\n  \"tag\": \"5S99fa_S2c4XsVrzM2rPDw\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILUVTK1hDMjBQS1ciLCJhcHUiOiJUWEl4TnpCM2JqSTJXa00wY0Y5SFVDMTBNazlyVFd0ZmExOVJVRkYxY1hObk5IUlFNV0pMU0hCdk1BIiwiYXB2IjoiU1haNGF6QkxOWFI2TjJOelVqZE5SRmhzYkZoWFpEZFpTbFJSUmpSd1V6aEpTRWhyU1dSbGNHZHdhdyIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IlhDMjBQIiwiZXBrIjp7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjoiTXIxNzB3bjI2WkM0cF9HUC10Mk9rTWtfa19RUFF1cXNnNHRQMWJLSHBvMCIsInkiOiJ1MUMydEJuYlFwUS1YTWx0SHRFdWNJaFVod1FCeDBCbklLZFlkN3FLRVFFIn0sImtpZCI6Ikl2eGswSzV0ejdjc1I3TURYbGxYV2Q3WUpUUUY0cFM4SUhIa0lkZXBncGsiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0.1k4IQgN6LIiV8mnNWUI2OyNXLRHvg75qZIyHf6_wtrBIYZlic1coUL3lekvesQpmLb1A9vip-pKi0yDKZOQIMtQS3TJ81EJJ.6Qky6FL-Uzpi5nvaZHobo3_8xqv-LF4h.mqQ6nsR76RMLvNLkJgU.5S99fa_S2c4XsVrzM2rPDw</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-ES+XC20PKW\",\n  \"apu\": \"TXIxNzB3bjI2WkM0cF9HUC10Mk9rTWtfa19RUFF1cXNnNHRQMWJLSHBvMA\",\n  \"apv\": \"SXZ4azBLNXR6N2NzUjdNRFhsbFhXZDdZSlRRRjRwUzhJSEhrSWRlcGdwaw\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"XC20P\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-256\",\n    \"x\": \"Mr170wn26ZC4p_GP-t2OkMk_k_QPQuqsg4tP1bKHpo0\",\n    \"y\": \"u1C2tBnbQpQ-XMltHtEucIhUhwQBx0BnIKdYd7qKEQE\"\n  },\n  \"kid\": \"Ivxk0K5tz7csR7MDXllXWd7YJTQF4pS8IHHkIdepgpk\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#222-nist-p-384-key","title":"2.2.2 NIST P-384 key","text":"<ul> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"5aCpGZXwubdOSedZl1wc5PHB175a990-bRo2QKzju6uyeXD6hBKcB6vUijQRILMr\",\n  \"y\": \"TeUA_qsYU8YmbHPA58QJuAJiUe0BEbi8Vuq88ZEWLudhJa4Dp5mBKuFEeJQcOQCa\",\n  \"d\": \"wTv7Yh4bZAfCfmz0qL_lKJNlMRYuXjWzE63p7y3mZW8DRtN5LgOE25QKO9v0xgKN\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>35E0yg0TinUSym5bQ5FnUgWirIrfK81p-QCxW7VzCrE</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILUVTK1hDMjBQS1ciLCJhcHUiOiJkbkJCYkVKc1pXUXlWM0YzTUY5VVNYTk1iM1JLVmpBek4ydzNOMmxDYzA5Mk0xRnhiSEZSVWxaSGNHeGZkRWR2UVc5VFNXRnpVR0kwY0RjeGFIVTBiUSIsImFwdiI6Ik16VkZNSGxuTUZScGJsVlRlVzAxWWxFMVJtNVZaMWRwY2tseVprczRNWEF0VVVONFZ6ZFdla055UlEiLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJjcnYiOiJQLTM4NCIsImt0eSI6IkVDIiwieCI6InZwQWxCbGVkMldxdzBfVElzTG90SlYwMzdsNzdpQnNPdjNRcWxxUVJWR3BsX3RHb0FvU0lhc1BiNHA3MWh1NG0iLCJ5IjoiU0Y3VEJDVnB5dTUwQ21vMzY0TWsyS2VyWGVwYnlYSklXZF8yTHNYMnNDMENWTkV1aFVJUHhFMmQtVjFVS1hwciJ9LCJraWQiOiIzNUUweWcwVGluVVN5bTViUTVGblVnV2lySXJmSzgxcC1RQ3hXN1Z6Q3JFIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"encrypted_key\": \"y7jUbtMzOyerWyPhTgTutFH0r18Ug6uF3FYdTCyp2V-PacHeR8OTsNEh7dEOQk9o5P9mXvcGvfGr2xFNtoBw561TPv_Iw2ZK\",\n  \"iv\": \"DOEADxox8cUL0jQ_H4hP67ymgscn8nQc\",\n  \"ciphertext\": \"hSjiRkcMflJJK18cuXU\",\n  \"tag\": \"SHN2rmcofMmnSqQ8htiCcQ\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILUVTK1hDMjBQS1ciLCJhcHUiOiJkbkJCYkVKc1pXUXlWM0YzTUY5VVNYTk1iM1JLVmpBek4ydzNOMmxDYzA5Mk0xRnhiSEZSVWxaSGNHeGZkRWR2UVc5VFNXRnpVR0kwY0RjeGFIVTBiUSIsImFwdiI6Ik16VkZNSGxuTUZScGJsVlRlVzAxWWxFMVJtNVZaMWRwY2tseVprczRNWEF0VVVONFZ6ZFdla055UlEiLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMzg0IiwieCI6InZwQWxCbGVkMldxdzBfVElzTG90SlYwMzdsNzdpQnNPdjNRcWxxUVJWR3BsX3RHb0FvU0lhc1BiNHA3MWh1NG0iLCJ5IjoiU0Y3VEJDVnB5dTUwQ21vMzY0TWsyS2VyWGVwYnlYSklXZF8yTHNYMnNDMENWTkV1aFVJUHhFMmQtVjFVS1hwciJ9LCJraWQiOiIzNUUweWcwVGluVVN5bTViUTVGblVnV2lySXJmSzgxcC1RQ3hXN1Z6Q3JFIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9.y7jUbtMzOyerWyPhTgTutFH0r18Ug6uF3FYdTCyp2V-PacHeR8OTsNEh7dEOQk9o5P9mXvcGvfGr2xFNtoBw561TPv_Iw2ZK.DOEADxox8cUL0jQ_H4hP67ymgscn8nQc.hSjiRkcMflJJK18cuXU.SHN2rmcofMmnSqQ8htiCcQ</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-ES+XC20PKW\",\n  \"apu\": \"dnBBbEJsZWQyV3F3MF9USXNMb3RKVjAzN2w3N2lCc092M1FxbHFRUlZHcGxfdEdvQW9TSWFzUGI0cDcxaHU0bQ\",\n  \"apv\": \"MzVFMHlnMFRpblVTeW01YlE1Rm5VZ1dpcklyZks4MXAtUUN4VzdWekNyRQ\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"XC20P\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-384\",\n    \"x\": \"vpAlBled2Wqw0_TIsLotJV037l77iBsOv3QqlqQRVGpl_tGoAoSIasPb4p71hu4m\",\n    \"y\": \"SF7TBCVpyu50Cmo364Mk2KerXepbyXJIWd_2LsX2sC0CVNEuhUIPxE2d-V1UKXpr\"\n  },\n  \"kid\": \"35E0yg0TinUSym5bQ5FnUgWirIrfK81p-QCxW7VzCrE\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#223-nist-p-521-key","title":"2.2.3 NIST P-521 key","text":"<ul> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AIlOiZCrQMU83IOpoiMva75L_OqljXVakEJSjwAl5RaLmaNBZg-TXa0VKlAKTijGZAu_5gS_ZF82LRWDiltUHmX8\",\n  \"y\": \"AFXxgSPOlCNnHtRQE7JmngrT5jgc5kHhMJE82wvMYlyrUdB1kgjN8zJDKkMDJ_dw1U2bEKXmcoCepN654HqmCeNJ\",\n  \"d\": \"ASUBEC_crwIW50ke7p7EBjM0jnA3X7ziwT92TIVgHqTyFkEHKwuP_xbUSePfkhAgcEF2KHz48EgZJuDM6v4L2NXT\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>fr_FYdKBgF_lo1UzC133Tw382LhNDRk6TqwWUwYiytQ</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILUVTK1hDMjBQS1ciLCJhcHUiOiJOa3hhTFd0bGNtczNTWEYzV1hCeE5FOUpYemt0U2tGSGEyMVZUVEl0ZDB0a1VtUlhUV1JxY2sxNlV6ZDVRelpuVTFnMFdHOVJWM0ZRZEdWRE1UTjVTWGxXY2tKVGNuWlJOWGhSZGtVNFVEQllOVTA1UW1GQiIsImFwdiI6IlpuSmZSbGxrUzBKblJsOXNiekZWZWtNeE16TlVkek00TWt4b1RrUlNhelpVY1hkWFZYZFphWGwwVVEiLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJjcnYiOiJQLTUyMSIsImt0eSI6IkVDIiwieCI6IkFPaTJmcEhxNU95S3NHS2F1RGlQX2ZpUUJwSmxETnZzQ25VWFZqSFk2ek0wdThndW9FbC1GNkVGcWo3WGd0ZDhpTWxhd1VxNzBPY1VMeFBEOUYtVFBRV2ciLCJ5IjoiQUVDX1VwU2poQzZlYnplSlBUc0JSb1YwNG9GdzZleDFRRzVpQW1OMm9hWVA3RVAtbU1YcEJRc2R3SEsyVFhpb1d5Q3ozZEU4d0JLUmZkcHFEaHdrRzFSaiJ9LCJraWQiOiJmcl9GWWRLQmdGX2xvMVV6QzEzM1R3MzgyTGhORFJrNlRxd1dVd1lpeXRRIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"encrypted_key\": \"bsghnB_jpcD8E7k1Q2lEizymrCDatLiMH5w9MmWtP6PkpQuonoXXoLk0T-qmC3hK7pEBHdji9YKxPT2NQ-2x7F1Tzf-juieh\",\n  \"iv\": \"SFKS4kMCTfU0tjUfn0YGh79rSWX9RGkP\",\n  \"ciphertext\": \"Fg9hiOjUvP3WU5c0tco\",\n  \"tag\": \"QJ2jlC_o-UiUvpFo7OF0Ew\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILUVTK1hDMjBQS1ciLCJhcHUiOiJOa3hhTFd0bGNtczNTWEYzV1hCeE5FOUpYemt0U2tGSGEyMVZUVEl0ZDB0a1VtUlhUV1JxY2sxNlV6ZDVRelpuVTFnMFdHOVJWM0ZRZEdWRE1UTjVTWGxXY2tKVGNuWlJOWGhSZGtVNFVEQllOVTA1UW1GQiIsImFwdiI6IlpuSmZSbGxrUzBKblJsOXNiekZWZWtNeE16TlVkek00TWt4b1RrUlNhelpVY1hkWFZYZFphWGwwVVEiLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJrdHkiOiJFQyIsImNydiI6IlAtNTIxIiwieCI6IkFPaTJmcEhxNU95S3NHS2F1RGlQX2ZpUUJwSmxETnZzQ25VWFZqSFk2ek0wdThndW9FbC1GNkVGcWo3WGd0ZDhpTWxhd1VxNzBPY1VMeFBEOUYtVFBRV2ciLCJ5IjoiQUVDX1VwU2poQzZlYnplSlBUc0JSb1YwNG9GdzZleDFRRzVpQW1OMm9hWVA3RVAtbU1YcEJRc2R3SEsyVFhpb1d5Q3ozZEU4d0JLUmZkcHFEaHdrRzFSaiJ9LCJraWQiOiJmcl9GWWRLQmdGX2xvMVV6QzEzM1R3MzgyTGhORFJrNlRxd1dVd1lpeXRRIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9.bsghnB_jpcD8E7k1Q2lEizymrCDatLiMH5w9MmWtP6PkpQuonoXXoLk0T-qmC3hK7pEBHdji9YKxPT2NQ-2x7F1Tzf-juieh.SFKS4kMCTfU0tjUfn0YGh79rSWX9RGkP.Fg9hiOjUvP3WU5c0tco.QJ2jlC_o-UiUvpFo7OF0Ew</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-ES+XC20PKW\",\n  \"apu\": \"NkxaLWtlcms3SXF3WXBxNE9JXzktSkFHa21VTTItd0tkUmRXTWRqck16Uzd5QzZnU1g0WG9RV3FQdGVDMTN5SXlWckJTcnZRNXhRdkU4UDBYNU05QmFB\",\n  \"apv\": \"ZnJfRllkS0JnRl9sbzFVekMxMzNUdzM4MkxoTkRSazZUcXdXVXdZaXl0UQ\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"XC20P\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-521\",\n    \"x\": \"AOi2fpHq5OyKsGKauDiP_fiQBpJlDNvsCnUXVjHY6zM0u8guoEl-F6EFqj7Xgtd8iMlawUq70OcULxPD9F-TPQWg\",\n    \"y\": \"AEC_UpSjhC6ebzeJPTsBRoV04oFw6ex1QG5iAmN2oaYP7EP-mMXpBQsdwHK2TXioWyCz3dE8wBKRfdpqDhwkG1Rj\"\n  },\n  \"kid\": \"fr_FYdKBgF_lo1UzC133Tw382LhNDRk6TqwWUwYiytQ\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#224-x25519-key","title":"2.2.4 X25519 key","text":"<ul> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"h5iIEBNlEHEhCgYLXAOXOofqYEA9Jo0Q1NUggjdwrVw\",\n  \"d\": \"oEGk3DVSpzrZR6mcUF0EXmijrATej7xnPdlcPJDz53M\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>S-qQ_rRIsrscxdmzuplVLW5bqoxj08KO6BBkLZAxh-E</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILUVTK1hDMjBQS1ciLCJhcHUiOiJjR1JKV1dNMlNVRm9SMnN3Unpsd1VHOUxPR1ZpYWtzM1QzbEpWMDlTV25oSVdsQm9hRmhWTWxoR1RRIiwiYXB2IjoiVXkxeFVWOXlVa2x6Y25OamVHUnRlblZ3YkZaTVZ6VmljVzk0YWpBNFMwODJRa0pyVEZwQmVHZ3RSUSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IlhDMjBQIiwiZXBrIjp7ImNydiI6IlgyNTUxOSIsImt0eSI6Ik9LUCIsIngiOiJwZElZYzZJQWhHazBHOXBQb0s4ZWJqSzdPeUlXT1JaeEhaUGhoWFUyWEZNIn0sImtpZCI6IlMtcVFfclJJc3JzY3hkbXp1cGxWTFc1YnFveGowOEtPNkJCa0xaQXhoLUUiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"encrypted_key\": \"VmgHr9mZuwN1dxRqd0B9n2yE4ErM14Mhri5XpYL93UVT5ZLGkUPKMG1-hdvLDhCUUdfJg5ronQke1HnOKcLgEgEO2Uh-jNHY\",\n  \"iv\": \"M7A2POrqH_lcXV_fwYgYGp3any_9sKFt\",\n  \"ciphertext\": \"gPNQD52uPxlA2881Ct4\",\n  \"tag\": \"JHq2fnYwqUYc3hUgUWaMsw\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILUVTK1hDMjBQS1ciLCJhcHUiOiJjR1JKV1dNMlNVRm9SMnN3Unpsd1VHOUxPR1ZpYWtzM1QzbEpWMDlTV25oSVdsQm9hRmhWTWxoR1RRIiwiYXB2IjoiVXkxeFVWOXlVa2x6Y25OamVHUnRlblZ3YkZaTVZ6VmljVzk0YWpBNFMwODJRa0pyVEZwQmVHZ3RSUSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IlhDMjBQIiwiZXBrIjp7Imt0eSI6Ik9LUCIsImNydiI6IlgyNTUxOSIsIngiOiJwZElZYzZJQWhHazBHOXBQb0s4ZWJqSzdPeUlXT1JaeEhaUGhoWFUyWEZNIn0sImtpZCI6IlMtcVFfclJJc3JzY3hkbXp1cGxWTFc1YnFveGowOEtPNkJCa0xaQXhoLUUiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0.VmgHr9mZuwN1dxRqd0B9n2yE4ErM14Mhri5XpYL93UVT5ZLGkUPKMG1-hdvLDhCUUdfJg5ronQke1HnOKcLgEgEO2Uh-jNHY.M7A2POrqH_lcXV_fwYgYGp3any_9sKFt.gPNQD52uPxlA2881Ct4.JHq2fnYwqUYc3hUgUWaMsw</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-ES+XC20PKW\",\n  \"apu\": \"cGRJWWM2SUFoR2swRzlwUG9LOGViaks3T3lJV09SWnhIWlBoaFhVMlhGTQ\",\n  \"apv\": \"Uy1xUV9yUklzcnNjeGRtenVwbFZMVzVicW94ajA4S082QkJrTFpBeGgtRQ\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"XC20P\",\n  \"epk\": {\n    \"kty\": \"OKP\",\n    \"crv\": \"X25519\",\n    \"x\": \"pdIYc6IAhGk0G9pPoK8ebjK7OyIWORZxHZPhhXU2XFM\"\n  },\n  \"kid\": \"S-qQ_rRIsrscxdmzuplVLW5bqoxj08KO6BBkLZAxh-E\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/","title":"Table of Contents","text":"<ul> <li>Authcrypt JWE Concrete examples</li> <li>Notes</li> <li>1 A256GCM Content Encryption<ul> <li>1.1 Multi recipients JWEs</li> <li>1.1.1 NIST P-256 keys</li> <li>1.1.2 NIST P-384 keys</li> <li>1.1.3 NIST P-521 keys</li> <li>1.1.4 X25519 keys</li> <li>1.2 Single Recipient JWEs</li> <li>1.2.1 NIST P-256 key</li> <li>1.2.2 NIST P-384 key</li> <li>1.2.3 NIST P-521 key</li> <li>1.2.4 X25519 key</li> </ul> </li> <li>2 XC20P content encryption<ul> <li>2.1 Multi recipients JWEs</li> <li>2.1.1 NIST P-256 keys</li> <li>2.1.2 NIST P-384 keys</li> <li>2.1.3 NIST P-521 keys</li> <li>2.1.4 X25519 keys</li> <li>2.2 Single Recipient JWEs</li> <li>2.2.1 NIST P-256 key</li> <li>2.2.2 NIST P-384 key</li> <li>2.2.3 NIST P-521 key</li> <li>2.2.4 X25519 key</li> </ul> </li> </ul> <p>Created by gh-md-toc</p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#authcrypt-jwe-concrete-examples","title":"Authcrypt JWE Concrete examples","text":"<p>The following examples are for JWE authcrypt packer for encrypting the payload <code>secret message</code> and aad value set as the concatenation of recipients' KIDs (ASCII sorted) joined by <code>.</code> for non-compact serializations (JWE Compact serializations don't have AAD).</p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#notes","title":"Notes","text":"<ul> <li>Since autchrypt requires the sender public key, it must be previously sent, out of band, to the recipient(s). For security reasons, the JWE envelope only includes the sender kid as <code>skid</code> in the protected headers. The recipient must be able to resolve the corresponding sender public key during unpack(JWE).</li> <li>all <code>x</code> and <code>y</code> key coordinates values below are raw (no padding) base64URL encoded.</li> <li>JWE envelopes with multi recipients use the General JWE JSON Serialization format.</li> <li>JWE envelopes with a single recipient will be shown either as JWE Compact or Flattened JWE JSON serialization format.</li> <li>General JWE JSON Serialization format uses the above mentioned AAD value in their envelope.</li> <li>JWE Compact Serialization format does not support AAD values and therefore were built without it.</li> <li>all <code>apu</code> recipient header values are set with the raw (no padding) base64URL encoding of the corresponding sender's <code>kid</code> (<code>skid</code>) value since authcrypt reveals the sender.</li> <li>all <code>apv</code> recipient header values are set with the raw (no padding) base64URL encoding of the corresponding recipient's <code>kid</code> value.</li> <li>The final aad used to encrypt the payload is the concatenation of the raw (no padding) base64URL encoded protected headers and <code>aad</code> JWE header joined by a <code>.</code>.</li> <li>Even though flattened serialization do support <code>aad</code>, the field is omitted in the below examples to be consistent with compact JWE serialization format. Implementations should support <code>aad</code> for flattened serialization regardless.</li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#1-a256gcm-content-encryption","title":"1 A256GCM Content Encryption","text":""},{"location":"features/0334-jwe-envelope/authcrypt-examples/#11-multi-recipients-jwes","title":"1.1 Multi recipients JWEs","text":""},{"location":"features/0334-jwe-envelope/authcrypt-examples/#111-nist-p-256-keys","title":"1.1.1 NIST P-256 keys","text":"<p>The packer generates the following protected headers that includes the skid: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"A256GCM\",\"skid\":\"6PBTUbcLB7-Z4fuAFn42oC1PaMsNmjheq1FeZEUgV_8\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwic2tpZCI6IjZQQlRVYmNMQjctWjRmdUFGbjQyb0MxUGFNc05tamhlcTFGZVpFVWdWXzgiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0</code></p> <ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"eFRTD4VaryfwIqLOpq7iuXmBbLjKPq5sVNzxwL7H1CI\",\n  \"y\": \"cIeogn-pLJXlCepb9BqwNKKW4tmNea3Is8G47aPob6M\",\n  \"d\": \"11NyNGrw4JoU7-_bwoZlVDTJi5vkMrSs4Nme_OHnx6Q\"\n}\n</code></pre></li> <li>Sender kid (aka <code>skid</code>, jwk thumbprint raw base64 URL encoded): <code>6PBTUbcLB7-Z4fuAFn42oC1PaMsNmjheq1FeZEUgV_8</code></li> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"UP08dxIWu14HWRCI48Tnohm7jhaJ87fFdvYyf0w4lkg\",\n  \"y\": \"ohZVfvhQViMGb_n-Y66TewBO2gtE_udG_DsNe8c-T8w\",\n  \"d\": \"O0ikvlb4fh7daJpqd9JIgYk5e-twB0IYyKpoqmb7ZCc\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>D_kHovGtLUZ_ssw_vhZcqsx3LvQ6qC5JK74iPf9vqwk</code></li> <li>Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"XgkWXrogHmvx-wee7KAhi-eP6dpoyUcDKn224vpOshw\",\n  \"y\": \"MAfbXLDMUOg6749jT0nDPZZIxfeozhdaKW6s3hutGHE\",\n  \"d\": \"WIKKCdNWrddYbOtkOxHLfETps1cEBHsPhqGtQPxaLho\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>pXCqiUJ-A6Zlp6LAvkBWLOXPMuww5Hy_PljoODMsGTw</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"xdS1ON9UCKA3s7yOv55fvlegYR5GsLPbOZWi_zsFyEM\",\n  \"y\": \"yeE__UlC9wEIbnCPjoOZa-nD2CN0uHtau7edhcmJiOg\",\n  \"d\": \"Dry6DWrItSzhXS_ep5bvoWHkJEhKKJU-VTkFmNxZ7PI\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>4CB-2PhtYR9WfjsFNb4rmvSmJozJAL4gRCg_am3oDhw</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>4CB-2PhtYR9WfjsFNb4rmvSmJozJAL4gRCg_am3oDhw.D_kHovGtLUZ_ssw_vhZcqsx3LvQ6qC5JK74iPf9vqwk.pXCqiUJ-A6Zlp6LAvkBWLOXPMuww5Hy_PljoODMsGTw</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>vo7O9me-lVJv6Y_vjz-rL8eWaa0Xy1WHm2IOsR_UEpk</code></li> <li>Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwic2tpZCI6IjZQQlRVYmNMQjctWjRmdUFGbjQyb0MxUGFNc05tamhlcTFGZVpFVWdWXzgiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"NlBCVFViY0xCNy1aNGZ1QUZuNDJvQzFQYU1zTm1qaGVxMUZlWkVVZ1ZfOA\",\n        \"apv\": \"RF9rSG92R3RMVVpfc3N3X3ZoWmNxc3gzTHZRNnFDNUpLNzRpUGY5dnF3aw\",\n        \"kid\": \"D_kHovGtLUZ_ssw_vhZcqsx3LvQ6qC5JK74iPf9vqwk\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"Vpj5VtHxMt5Xz3vnKA727nTMmJd4zbVcPmKjSyHvLvc\",\n          \"y\": \"C7ZLlNCTduhf2qMXjrY907-OdMw_6ixC3UttKCVqgjk\"\n        }\n      },\n      \"encrypted_key\": \"lIm78Z0OmYR5Jc5D416xjb9K3rkmcOgaEFVut4WyNDueoTnM9B86Ug\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"NlBCVFViY0xCNy1aNGZ1QUZuNDJvQzFQYU1zTm1qaGVxMUZlWkVVZ1ZfOA\",\n        \"apv\": \"RF9rSG92R3RMVVpfc3N3X3ZoWmNxc3gzTHZRNnFDNUpLNzRpUGY5dnF3aw\",\n        \"kid\": \"pXCqiUJ-A6Zlp6LAvkBWLOXPMuww5Hy_PljoODMsGTw\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"wDD9G8UK-I246qp6-A1qBPr6N2yX6nTfYb9Zotf898o\",\n          \"y\": \"KIW0m4mOlWzwnW9y1R9314keHj5W8b7eqUs_dT3LBEw\"\n        }\n      },\n      \"encrypted_key\": \"BjZsq3DwuggMu1YhSZIX7NydPNSIBOfHWVBEZ9t5yDzlt1am_LI8cg\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"NlBCVFViY0xCNy1aNGZ1QUZuNDJvQzFQYU1zTm1qaGVxMUZlWkVVZ1ZfOA\",\n        \"apv\": \"RF9rSG92R3RMVVpfc3N3X3ZoWmNxc3gzTHZRNnFDNUpLNzRpUGY5dnF3aw\",\n        \"kid\": \"4CB-2PhtYR9WfjsFNb4rmvSmJozJAL4gRCg_am3oDhw\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"CHaH39lqKhUQLcrmbL_sVBmVZQaLlDxNGI1WkcCB7ss\",\n          \"y\": \"R36X6eJ2dwPz8T7eto0Uije3KLOGAwzLUVUKWj0SxHk\"\n        }\n      },\n      \"encrypted_key\": \"YnLT86bjwgz4SsKUUiG6bf0AybQywN8k2wHa_E3hGLP3Nwo23CyekQ\"\n    }\n  ],\n  \"aad\": \"vo7O9me-lVJv6Y_vjz-rL8eWaa0Xy1WHm2IOsR_UEpk\",\n  \"iv\": \"mwMiQc4m9LaoqnIC\",\n  \"ciphertext\": \"wQGUFlLz9fHpDoACWEQ\",\n  \"tag\": \"Ma9X6kppUNUp5SYH74zXDw\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#112-nist-p-384-keys","title":"1.1.2 NIST P-384 keys","text":"<p>The packer generates the following protected headers that includes the skid: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"A256GCM\",\"skid\":\"0Bz8yRwu9eC8Gi7cYOwAKMJ8jysInhAtwH8k8m9MX04\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwic2tpZCI6IjBCejh5Und1OWVDOEdpN2NZT3dBS01KOGp5c0luaEF0d0g4azhtOU1YMDQiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0</code> - Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"UW1LtMXuZdFS0gyp0_F19uxHqECvCcJA7SmeeuRSSc_PQfsbZWXt5L0KyLYpNIQb\",\n  \"y\": \"FBdPcUvanB7igwkX0NN5rOvH3OKZ1gQHhcad7cCy6QNYKKz7lBWUUOmzypee31pS\",\n  \"d\": \"wrXW0wsFKjvpTWqOAd1mohRublQs4P014-U4_K-eTRFmzhkyLJqNn91dH_AHUc4-\"\n}\n</code></pre> - Sender kid (jwk thumbprint raw base64 URL encoded): <code>0Bz8yRwu9eC8Gi7cYOwAKMJ8jysInhAtwH8k8m9MX04</code> - Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"k3W_RR59uUG3HFlhhqNNmBDyFdMtWHxKAsJaxLBqQgQer3d3aAN-lfdxzGnHtwj1\",\n  \"y\": \"VMSy5zxFEGaGRINailLTUH6NlP0JO2qu0j0_UbS7Ng1b8JkzHDnDbjGgsLqVJaMM\",\n  \"d\": \"iM5K8uqNvFYJnuToMDBguGwUIlu1erT-K0g7NYtJrQnHZOumS8yIC4MCNC60Ch91\"\n}\n</code></pre> - Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>obCHRLVDx634Cax_Kr3B8fd_-xj5kAj0r0Kvvvmq1z8</code> - Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"W3iUHCzh_PWzUKONKeHwIKcjWNN--c7OlL2H23lV13C9tlkqOleFUmioW-AeitEk\",\n  \"y\": \"CIzVD6KsuDLyKQPm0r62LPZikkT2kiXJpLjcVO3op2kgePQkZ31xniKE0VbUBnTH\",\n  \"d\": \"V_vQwOqHVCGxSjX_dN8H5VXvOGYDRTGI00mNXwB0I0mKDd8kqCJmNtGlf-eUrbub\"\n}\n</code></pre> - Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>PfuTIXG60dvOwnFOfMxJ0i59_L7vqNytROX_bLRR-3M</code> - Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"bsX8qtEtj5IDLp9iDUKlgdu_3nluupFtFBrfIK1nza1bGZQRlZ3JG3PdBzVAoePz\",\n  \"y\": \"QX_2v0BHloNS7iWoB4CcO9UWHdtirMVmbNcB8ZGczCJOfUyjYcQxGr0RU_tGkFC4\",\n  \"d\": \"rQ-4ZmWn09CsCqRQJhpQhDeUZXeZ3cy_Pei-fchVPFTa2FnAzvjwEF2Nsm2f3MmR\"\n}\n</code></pre> - Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>VTVlkyBsoW4ey0sh7TMJBErLGeBeKQsOttFRrXD6eqI</code> - List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>PfuTIXG60dvOwnFOfMxJ0i59_L7vqNytROX_bLRR-3M.VTVlkyBsoW4ey0sh7TMJBErLGeBeKQsOttFRrXD6eqI.obCHRLVDx634Cax_Kr3B8fd_-xj5kAj0r0Kvvvmq1z8</code> - Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>m72Q9j28hFk0imbFVzqY4KfTE77L8itJoX75N3hwiwA</code> - Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwic2tpZCI6IjBCejh5Und1OWVDOEdpN2NZT3dBS01KOGp5c0luaEF0d0g4azhtOU1YMDQiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"MEJ6OHlSd3U5ZUM4R2k3Y1lPd0FLTUo4anlzSW5oQXR3SDhrOG05TVgwNA\",\n        \"apv\": \"b2JDSFJMVkR4NjM0Q2F4X0tyM0I4ZmRfLXhqNWtBajByMEt2dnZtcTF6OA\",\n        \"kid\": \"obCHRLVDx634Cax_Kr3B8fd_-xj5kAj0r0Kvvvmq1z8\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"cjJHtV4VkMCww9ig94-_4e4yMfo2WI4Rh4dZh6NkYFvz-EGylA7RLSO5TRC-JJ_G\",\n          \"y\": \"RJe2QisAYpfuTWTV6KVeoLGshsJqYokbcSUqdMxrFGXSp4ZMNrW4yj410Xsn6hy6\"\n        }\n      },\n      \"encrypted_key\": \"o0ZZ_xNtmUPcpQAK3kzjOLp8xWBJ31tr-ORQjXtwpqgTuvM_nvhk_w\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"MEJ6OHlSd3U5ZUM4R2k3Y1lPd0FLTUo4anlzSW5oQXR3SDhrOG05TVgwNA\",\n        \"apv\": \"b2JDSFJMVkR4NjM0Q2F4X0tyM0I4ZmRfLXhqNWtBajByMEt2dnZtcTF6OA\",\n        \"kid\": \"PfuTIXG60dvOwnFOfMxJ0i59_L7vqNytROX_bLRR-3M\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"u1HYhdUJGx49J6wSLYM_JLHTkJrkR7wMSm5uYZMH7ZpcC3qF8MUyKTuKN0FGCBcN\",\n          \"y\": \"K-XI-KAGd2jHebNq44yQrDA6Ubs5M99mIlre0chzI13bSLDOuUG4RJ8yjYjXysWF\"\n        }\n      },\n      \"encrypted_key\": \"iCV1_peiRwnsrrBQWmp7GOd-taee-Yk8t6XqJCZPGziglDpGBu_ZhA\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"MEJ6OHlSd3U5ZUM4R2k3Y1lPd0FLTUo4anlzSW5oQXR3SDhrOG05TVgwNA\",\n        \"apv\": \"b2JDSFJMVkR4NjM0Q2F4X0tyM0I4ZmRfLXhqNWtBajByMEt2dnZtcTF6OA\",\n        \"kid\": \"VTVlkyBsoW4ey0sh7TMJBErLGeBeKQsOttFRrXD6eqI\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"Twps_QU6ShP18uQFNCcdOx9sU9YrHBznNnSbhQD474tLUcnslq5Trubq3ogp-LTX\",\n          \"y\": \"oSES1a5xve9e-lKQ3NMN5_CW9Sii9rTorqUMggDzodLsRGm0Jud3HAy2-uE956Xq\"\n        }\n      },\n      \"encrypted_key\": \"dLDKyXeZJDcB_i1Tnn_EUxqCc2ukneaummXF_FwcbpnMH8B0eVizvA\"\n    }\n  ],\n  \"aad\": \"m72Q9j28hFk0imbFVzqY4KfTE77L8itJoX75N3hwiwA\",\n  \"iv\": \"nuuuri2fyNl3jBo6\",\n  \"ciphertext\": \"DCWevJuEo5dx-MmqPvw\",\n  \"tag\": \"Pyt1S_Smg9Pnd1u_5Z7nbA\"\n}\n</code></pre></p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#113-nist-p-521-keys","title":"1.1.3 NIST P-521 keys","text":"<p>The packer generates the following protected headers that includes the skid: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"A256GCM\",\"skid\":\"oq-WBIGQm-iHiNRj6nId4-E1QtY8exzp8C56SziUfeU\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwic2tpZCI6Im9xLVdCSUdRbS1pSGlOUmo2bklkNC1FMVF0WThleHpwOEM1NlN6aVVmZVUiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0</code> - Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AXKDGPnD6hlQIre8aEeu33bQffkfl-eQfQXgzNXQX7XFYt5GKA1N6w4-f0_Ci7fQNKGkQuCoAu5-6CNk9M_cHiDi\",\n  \"y\": \"Ae4-APhoZAmM99MdY9io9IZA43dN7dA006wlFb6LJ9bcusJOi5R-o3o3FhCjt5KTv_JxYbo6KU4PsBwQ1eeKyJ0U\",\n  \"d\": \"AP9l2wmQ85P5XD84CkEQVWHaX_46EDvHxLWHEKsHFSQYjEh6BDSuyy1TUNv68v8kpbLCDjvsBc3cIBqC4_T1r4pU\"\n}\n</code></pre> - Sender kid (jwk thumbprint raw base64 URL encoded): <code>oq-WBIGQm-iHiNRj6nId4-E1QtY8exzp8C56SziUfeU</code> - Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"ALmUHkd9Gi2NApJojNzzA34Qdd1-KLnq6jd2UJ9wl-xJzTQ2leg8qi3-hrFs7NqNfxqO6vE5bBoWYFeAcf3LqJOU\",\n  \"y\": \"AN-MutmkAXGzlgzSQJRnctHDcjQQNpRek-8BeqyUDXdZKNGKSMEAzw6Hnl3VdvsvihQfrxcajpx5PSnwxbbdakHq\",\n  \"d\": \"AKv-YbKdI6y8NRMP-e17-RjZyRTfGf0Xh9Og5g7q7aq0xS2mO59ttIJ67XHW5SPTBQDbltdUcydKroWNUIGvhKNv\"\n}\n</code></pre> - Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>wax1T_hGUvM0NmlbFJi2RizQ_gWajumI5j0Hx7CbgAw</code> - Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"ALmUHkd9Gi2NApJojNzzA34Qdd1-KLnq6jd2UJ9wl-xJzTQ2leg8qi3-hrFs7NqNfxqO6vE5bBoWYFeAcf3LqJOU\",\n  \"y\": \"AN-MutmkAXGzlgzSQJRnctHDcjQQNpRek-8BeqyUDXdZKNGKSMEAzw6Hnl3VdvsvihQfrxcajpx5PSnwxbbdakHq\",\n  \"d\": \"AKv-YbKdI6y8NRMP-e17-RjZyRTfGf0Xh9Og5g7q7aq0xS2mO59ttIJ67XHW5SPTBQDbltdUcydKroWNUIGvhKNv\"\n}\n</code></pre> - Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>XmLVV-CqMkTGQIe6-KecWZWtZVwORTMP2y5aqMPV7P4</code> - Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AHCbpo-299Q0Fk71CtBoPu-40-Z0UOu4cGZfgtHHwcu3ciMWVR8IWF4bgvFpAPfKG8Dqx7JJWO8uEgLE67A7aQOL\",\n  \"y\": \"AQ_JBjS3lt8zz3njFhUoJwEdSJMyrSfGPCLpaWkKuRo25k3im-7IjY8T43gvzZXYwV3PKKR3iJ1jnQCrYmfRrmva\",\n  \"d\": \"ACgCw3U3eWTYD5vcygoOpoGPost9TojYJH9FllyRuqwlS3L8dkZu7vKhFyoEg6Bo8AqcOUj5Mtgxhd6Wu02YvqK3\"\n}\n</code></pre> - Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>pRJtTY7V1pClPu8WEgEZonzaHq3K0El9Vcb8qmjucSg</code> - List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>S8s7FFL7f0fUMXt93WOWC-3PJrV1iuAmB_ZlCDyjXqs.XmLVV-CqMkTGQIe6-KecWZWtZVwORTMP2y5aqMPV7P4.pRJtTY7V1pClPu8WEgEZonzaHq3K0El9Vcb8qmjucSg</code> - Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>tOS8nLSCERw2V9WOZVo6cenGuM4DJvHse1dsvTk8_As</code> - Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwic2tpZCI6Im9xLVdCSUdRbS1pSGlOUmo2bklkNC1FMVF0WThleHpwOEM1NlN6aVVmZVUiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"b3EtV0JJR1FtLWlIaU5SajZuSWQ0LUUxUXRZOGV4enA4QzU2U3ppVWZlVQ\",\n        \"apv\": \"WG1MVlYtQ3FNa1RHUUllNi1LZWNXWld0WlZ3T1JUTVAyeTVhcU1QVjdQNA\",\n        \"kid\": \"XmLVV-CqMkTGQIe6-KecWZWtZVwORTMP2y5aqMPV7P4\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"AP630J9yi2UFBfRWKucXB8eu9-SSKbbbD1fzFhLgbI3xTRTRNMGm-U5EGHbplMLsOfP2pNxtAgo2-d6abiZiD6gg\",\n          \"y\": \"AE1Grtp1iFvySLN4yHVvE0kYWChqVfkO_kHEMujjL6vVu_AAOvl3aogquLv1zgduitCPbKRTno89r3rv0L0Kuj0M\"\n        }\n      },\n      \"encrypted_key\": \"FSYpXFfgPlSfj91VFQ4zAs0Wb3CEpWcBcGeW4nld9szVfb_WRbqTtA\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"b3EtV0JJR1FtLWlIaU5SajZuSWQ0LUUxUXRZOGV4enA4QzU2U3ppVWZlVQ\",\n        \"apv\": \"WG1MVlYtQ3FNa1RHUUllNi1LZWNXWld0WlZ3T1JUTVAyeTVhcU1QVjdQNA\",\n        \"kid\": \"S8s7FFL7f0fUMXt93WOWC-3PJrV1iuAmB_ZlCDyjXqs\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"Acw0XM1IZl63ltysb-ivw8zBhZ-Wz54SaXM_vGGea8Sa5w6VWdZflp1tibzHkfu4novFFpNbKtnCKi-28AqQnOYZ\",\n          \"y\": \"AajoBj0KMrlaIA17RKnShFNzIb1S81oLYZu5MXzAg-XvT8_q83dXajOCiYJLo3taUvHTlcPjkHMG3_8442DgWpU_\"\n        }\n      },\n      \"encrypted_key\": \"3ct4awH6xyp9BjA74Q_j6ot6F32okEYXbS2e6NIkiAgs-JGyEPWoxw\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"b3EtV0JJR1FtLWlIaU5SajZuSWQ0LUUxUXRZOGV4enA4QzU2U3ppVWZlVQ\",\n        \"apv\": \"WG1MVlYtQ3FNa1RHUUllNi1LZWNXWld0WlZ3T1JUTVAyeTVhcU1QVjdQNA\",\n        \"kid\": \"pRJtTY7V1pClPu8WEgEZonzaHq3K0El9Vcb8qmjucSg\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"APu-ArpY-GUntHG7BzTvUauKVP_YpCcVnZFX6r_VvYY2iPbFSZYxvUdUbX3TGK-Q92rTHNaNnutjbPcrCaBpJecM\",\n          \"y\": \"AONhGq1vGU20Wdrx1FT5SBdLOIvqOK_pxhTJZhS0Vwi_JYQdKN6PHrX9GyJ23ZhaY3bBKX6V2uzRJzV8Qam1FUbz\"\n        }\n      },\n      \"encrypted_key\": \"U51txv9yfZASl8tlT7GbNtLjeAqTHUVT4O9MEqBKaYIdAcA7Qd7dnw\"\n    }\n  ],\n  \"aad\": \"tOS8nLSCERw2V9WOZVo6cenGuM4DJvHse1dsvTk8_As\",\n  \"iv\": \"LJl-9ygxPGMAmVHP\",\n  \"ciphertext\": \"HOfi-W7mcQv93scr1z8\",\n  \"tag\": \"zaM6OfzhVhYCsqD2VW5ztw\"\n}\n</code></pre></p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#114-x25519-keys","title":"1.1.4 X25519 keys","text":"<p>The packer generates the following protected headers that includes the skid: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"A256GCM\",\"skid\":\"X5INSMIv_w4Q7pljH7xjeUrRAKiBGHavSmOYyyiRugc\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwic2tpZCI6Ilg1SU5TTUl2X3c0UTdwbGpIN3hqZVVyUkFLaUJHSGF2U21PWXl5aVJ1Z2MiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0</code> - Sender key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"WKkktGWkUB9hDITcqa1Z6MC8rcWy8fWtxuT7xwQF1lw\",\n  \"d\": \"-LEcVt6bW_ah9gY7H_WknTsg1MXq8yc42SrSJhqP0Vo\"\n}\n</code></pre> - Sender kid (jwk thumbprint raw base64 URL encoded): <code>X5INSMIv_w4Q7pljH7xjeUrRAKiBGHavSmOYyyiRugc</code> - Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"NJzDtIa7vjz-isjaI-6GKGDe2EUx26-D44d6jLILeBI\",\n  \"d\": \"MEBNdr6Tpb0XfD60NeHby-Tkmlpgr7pvVe7Q__sBbGw\"\n}\n</code></pre> - Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>2UR-nzYjVhsq0cZakWjE38-wUdG0S2EIrLZ8Eh0KVO0</code> - Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"_aiA8rwrayc2k9EL-mkqtSh8onyl_-EzVif3L-q-R20\",\n  \"d\": \"ALBfdypF_lAbBtWXhwvq9Rs7TGjcLd-iuDh0s3yWr2Y\"\n}\n</code></pre> - Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>dvDd4h1rHj-onj-Xz9O1KRIgkMhh3u23d-94brHbBKo</code> - Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"zuHJfrIarLGFga0OwZqDlvlI5P1bb9DFhAtdnI54pwQ\",\n  \"d\": \"8BVFAqxPHXB5W-EBxr-EjdUmA4HqY1gwDjiYvt0UxUk\"\n}\n</code></pre> - Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>hj57wbrmOygTc_ktMPqKMHdiL85FdiGJa5DKzoLIzeU</code> - List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>2UR-nzYjVhsq0cZakWjE38-wUdG0S2EIrLZ8Eh0KVO0.dvDd4h1rHj-onj-Xz9O1KRIgkMhh3u23d-94brHbBKo.hj57wbrmOygTc_ktMPqKMHdiL85FdiGJa5DKzoLIzeU</code> - Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>L-QV1cHI5u8U9BQa8_S4CFW-LhKNXHCjmqydtQYuSLw</code> - Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwic2tpZCI6Ilg1SU5TTUl2X3c0UTdwbGpIN3hqZVVyUkFLaUJHSGF2U21PWXl5aVJ1Z2MiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"WDVJTlNNSXZfdzRRN3Bsakg3eGplVXJSQUtpQkdIYXZTbU9ZeXlpUnVnYw\",\n        \"apv\": \"MlVSLW56WWpWaHNxMGNaYWtXakUzOC13VWRHMFMyRUlyTFo4RWgwS1ZPMA\",\n        \"kid\": \"2UR-nzYjVhsq0cZakWjE38-wUdG0S2EIrLZ8Eh0KVO0\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"IcuAA7zPN0mLt4GSZLQJ6f8p3yPALQaSyupbSRpDnwA\"\n        }\n      },\n      \"encrypted_key\": \"_GoKcbrlbPR8hdgpDdpotO4WvAKOzyOEXo5A2RlxVaEb0enFej2DFQ\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"WDVJTlNNSXZfdzRRN3Bsakg3eGplVXJSQUtpQkdIYXZTbU9ZeXlpUnVnYw\",\n        \"apv\": \"MlVSLW56WWpWaHNxMGNaYWtXakUzOC13VWRHMFMyRUlyTFo4RWgwS1ZPMA\",\n        \"kid\": \"dvDd4h1rHj-onj-Xz9O1KRIgkMhh3u23d-94brHbBKo\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"_BVh0oInkDiqnTkHKLvNMa8cldr79TZS00MJCYwZo3Y\"\n        }\n      },\n      \"encrypted_key\": \"gacTLNP-U5mYAHJLG9F97R52aG244NfLeWg_Dj4Fy0C96oIIN-3psw\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"WDVJTlNNSXZfdzRRN3Bsakg3eGplVXJSQUtpQkdIYXZTbU9ZeXlpUnVnYw\",\n        \"apv\": \"MlVSLW56WWpWaHNxMGNaYWtXakUzOC13VWRHMFMyRUlyTFo4RWgwS1ZPMA\",\n        \"kid\": \"hj57wbrmOygTc_ktMPqKMHdiL85FdiGJa5DKzoLIzeU\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"alPo4cjEjondCmz8mw8tntYxlpGPSLaqe3SSI_wu11s\"\n        }\n      },\n      \"encrypted_key\": \"q2RpqrdZA9mvVBGTvMNHg3P6SysnuCpfraLWhRseiQ1ImJWdLq53TA\"\n    }\n  ],\n  \"aad\": \"L-QV1cHI5u8U9BQa8_S4CFW-LhKNXHCjmqydtQYuSLw\",\n  \"iv\": \"J-OEJGFWvJ6rw9dX\",\n  \"ciphertext\": \"BvFi1vAzq0Uostj0_ms\",\n  \"tag\": \"C6itmqZ7ehMx9FF70fdGGQ\"\n}\n</code></pre></p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#12-single-recipient-jwes","title":"1.2 Single Recipient JWEs","text":"<p>Packing a message with 1 recipient using the Flattened JWE JSON serialization and Compact JWE serialization formats as mentioned in the notes above.</p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#121-nist-p-256-key","title":"1.2.1 NIST P-256 key","text":"<ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"eFRTD4VaryfwIqLOpq7iuXmBbLjKPq5sVNzxwL7H1CI\",\n  \"y\": \"cIeogn-pLJXlCepb9BqwNKKW4tmNea3Is8G47aPob6M\",\n  \"d\": \"11NyNGrw4JoU7-_bwoZlVDTJi5vkMrSs4Nme_OHnx6Q\"\n}\n</code></pre></li> <li>Sender kid (jwk thumbprint raw base64 URL encoded): <code>6PBTUbcLB7-Z4fuAFn42oC1PaMsNmjheq1FeZEUgV_8</code></li> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"UP08dxIWu14HWRCI48Tnohm7jhaJ87fFdvYyf0w4lkg\",\n  \"y\": \"ohZVfvhQViMGb_n-Y66TewBO2gtE_udG_DsNe8c-T8w\",\n  \"d\": \"O0ikvlb4fh7daJpqd9JIgYk5e-twB0IYyKpoqmb7ZCc\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>D_kHovGtLUZ_ssw_vhZcqsx3LvQ6qC5JK74iPf9vqwk</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILTFQVStBMjU2S1ciLCJhcHUiOiJObEJDVkZWaVkweENOeTFhTkdaMVFVWnVOREp2UXpGUVlVMXpUbTFxYUdWeE1VWmxXa1ZWWjFaZk9BIiwiYXB2IjoiUkY5clNHOTJSM1JNVlZwZmMzTjNYM1pvV21OeGMzZ3pUSFpSTm5GRE5VcExOelJwVUdZNWRuRjNhdyIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsiY3J2IjoiUC0yNTYiLCJrdHkiOiJFQyIsIngiOiJzODRGczRGeWRfSEVFQUN2R3dHak0wWDdGYUNwTlZ5cS1tM19MYXVwT2gwIiwieSI6IndsZzZoQnVnZElWMFlaekh1NHNQRnM0OXRtMGtXQlZjenQ0N25IenZ5UU0ifSwia2lkIjoiRF9rSG92R3RMVVpfc3N3X3ZoWmNxc3gzTHZRNnFDNUpLNzRpUGY5dnF3ayIsInNraWQiOiI2UEJUVWJjTEI3LVo0ZnVBRm40Mm9DMVBhTXNObWpoZXExRmVaRVVnVl84IiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"encrypted_key\": \"0L4GrPjXIy31JcEjV3sQj1Fbtb-dAtFPLng6mB0jyEyzDxzWcZZWag\",\n  \"iv\": \"V26sXdaKTIo6SDMn\",\n  \"ciphertext\": \"TJcEzgDbw5xDOMOwuuE\",\n  \"tag\": \"vgtkaTIM407IG8ZqLLRk6Q\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILTFQVStBMjU2S1ciLCJhcHUiOiJObEJDVkZWaVkweENOeTFhTkdaMVFVWnVOREp2UXpGUVlVMXpUbTFxYUdWeE1VWmxXa1ZWWjFaZk9BIiwiYXB2IjoiUkY5clNHOTJSM1JNVlZwZmMzTjNYM1pvV21OeGMzZ3pUSFpSTm5GRE5VcExOelJwVUdZNWRuRjNhdyIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsia3R5IjoiRUMiLCJjcnYiOiJQLTI1NiIsIngiOiJzODRGczRGeWRfSEVFQUN2R3dHak0wWDdGYUNwTlZ5cS1tM19MYXVwT2gwIiwieSI6IndsZzZoQnVnZElWMFlaekh1NHNQRnM0OXRtMGtXQlZjenQ0N25IenZ5UU0ifSwia2lkIjoiRF9rSG92R3RMVVpfc3N3X3ZoWmNxc3gzTHZRNnFDNUpLNzRpUGY5dnF3ayIsInNraWQiOiI2UEJUVWJjTEI3LVo0ZnVBRm40Mm9DMVBhTXNObWpoZXExRmVaRVVnVl84IiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9.0L4GrPjXIy31JcEjV3sQj1Fbtb-dAtFPLng6mB0jyEyzDxzWcZZWag.V26sXdaKTIo6SDMn.TJcEzgDbw5xDOMOwuuE.vgtkaTIM407IG8ZqLLRk6Q</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-1PU+A256KW\",\n  \"apu\": \"NlBCVFViY0xCNy1aNGZ1QUZuNDJvQzFQYU1zTm1qaGVxMUZlWkVVZ1ZfOA\",\n  \"apv\": \"RF9rSG92R3RMVVpfc3N3X3ZoWmNxc3gzTHZRNnFDNUpLNzRpUGY5dnF3aw\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"A256GCM\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-256\",\n    \"x\": \"s84Fs4Fyd_HEEACvGwGjM0X7FaCpNVyq-m3_LaupOh0\",\n    \"y\": \"wlg6hBugdIV0YZzHu4sPFs49tm0kWBVczt47nHzvyQM\"\n  },\n  \"kid\": \"D_kHovGtLUZ_ssw_vhZcqsx3LvQ6qC5JK74iPf9vqwk\",\n  \"skid\": \"6PBTUbcLB7-Z4fuAFn42oC1PaMsNmjheq1FeZEUgV_8\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#122-nist-p-384-key","title":"1.2.2 NIST P-384 key","text":"<ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"UW1LtMXuZdFS0gyp0_F19uxHqECvCcJA7SmeeuRSSc_PQfsbZWXt5L0KyLYpNIQb\",\n  \"y\": \"FBdPcUvanB7igwkX0NN5rOvH3OKZ1gQHhcad7cCy6QNYKKz7lBWUUOmzypee31pS\",\n  \"d\": \"wrXW0wsFKjvpTWqOAd1mohRublQs4P014-U4_K-eTRFmzhkyLJqNn91dH_AHUc4-\"\n}\n</code></pre></li> <li>Sender kid (jwk thumbprint raw base64 URL encoded): <code>0Bz8yRwu9eC8Gi7cYOwAKMJ8jysInhAtwH8k8m9MX04</code></li> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"k3W_RR59uUG3HFlhhqNNmBDyFdMtWHxKAsJaxLBqQgQer3d3aAN-lfdxzGnHtwj1\",\n  \"y\": \"VMSy5zxFEGaGRINailLTUH6NlP0JO2qu0j0_UbS7Ng1b8JkzHDnDbjGgsLqVJaMM\",\n  \"d\": \"iM5K8uqNvFYJnuToMDBguGwUIlu1erT-K0g7NYtJrQnHZOumS8yIC4MCNC60Ch91\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>obCHRLVDx634Cax_Kr3B8fd_-xj5kAj0r0Kvvvmq1z8</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILTFQVStBMjU2S1ciLCJhcHUiOiJNRUo2T0hsU2QzVTVaVU00UjJrM1kxbFBkMEZMVFVvNGFubHpTVzVvUVhSM1NEaHJPRzA1VFZnd05BIiwiYXB2IjoiYjJKRFNGSk1Wa1I0TmpNMFEyRjRYMHR5TTBJNFptUmZMWGhxTld0QmFqQnlNRXQyZG5adGNURjZPQSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsiY3J2IjoiUC0zODQiLCJrdHkiOiJFQyIsIngiOiJvZ1dJTHo4aXpDODNWNnFPNFVidHlSMTFadGdtRUMxQV9VM1JtVVV4dk9INE9lVW9xbUxXX295YjJXek5NTTZtIiwieSI6ImNobkphdHpRREJodzhqem5McUFmYWx3eFB3RmFKZjhVY2FzbjlmUWZyeUVWQ2FnRnRBYTNIb1FaSUxoeGxYSWUifSwia2lkIjoib2JDSFJMVkR4NjM0Q2F4X0tyM0I4ZmRfLXhqNWtBajByMEt2dnZtcTF6OCIsInNraWQiOiIwQno4eVJ3dTllQzhHaTdjWU93QUtNSjhqeXNJbmhBdHdIOGs4bTlNWDA0IiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"encrypted_key\": \"ojdzwycN1XFKuiwOmlgS4MHApmDAVKVZt1Zl7sgtJkafQRz81FUnZQ\",\n  \"iv\": \"VqEJ6p5J0ZTIw2ts\",\n  \"ciphertext\": \"jGznTL6ruVMXzV8xCA8\",\n  \"tag\": \"YA_A4pjqqaAeUNvEFnCx8Q\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILTFQVStBMjU2S1ciLCJhcHUiOiJNRUo2T0hsU2QzVTVaVU00UjJrM1kxbFBkMEZMVFVvNGFubHpTVzVvUVhSM1NEaHJPRzA1VFZnd05BIiwiYXB2IjoiYjJKRFNGSk1Wa1I0TmpNMFEyRjRYMHR5TTBJNFptUmZMWGhxTld0QmFqQnlNRXQyZG5adGNURjZPQSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsIngiOiJvZ1dJTHo4aXpDODNWNnFPNFVidHlSMTFadGdtRUMxQV9VM1JtVVV4dk9INE9lVW9xbUxXX295YjJXek5NTTZtIiwieSI6ImNobkphdHpRREJodzhqem5McUFmYWx3eFB3RmFKZjhVY2FzbjlmUWZyeUVWQ2FnRnRBYTNIb1FaSUxoeGxYSWUifSwia2lkIjoib2JDSFJMVkR4NjM0Q2F4X0tyM0I4ZmRfLXhqNWtBajByMEt2dnZtcTF6OCIsInNraWQiOiIwQno4eVJ3dTllQzhHaTdjWU93QUtNSjhqeXNJbmhBdHdIOGs4bTlNWDA0IiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9.ojdzwycN1XFKuiwOmlgS4MHApmDAVKVZt1Zl7sgtJkafQRz81FUnZQ.VqEJ6p5J0ZTIw2ts.jGznTL6ruVMXzV8xCA8.YA_A4pjqqaAeUNvEFnCx8Q</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-1PU+A256KW\",\n  \"apu\": \"MEJ6OHlSd3U5ZUM4R2k3Y1lPd0FLTUo4anlzSW5oQXR3SDhrOG05TVgwNA\",\n  \"apv\": \"b2JDSFJMVkR4NjM0Q2F4X0tyM0I4ZmRfLXhqNWtBajByMEt2dnZtcTF6OA\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"A256GCM\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-384\",\n    \"x\": \"ogWILz8izC83V6qO4UbtyR11ZtgmEC1A_U3RmUUxvOH4OeUoqmLW_oyb2WzNMM6m\",\n    \"y\": \"chnJatzQDBhw8jznLqAfalwxPwFaJf8Ucasn9fQfryEVCagFtAa3HoQZILhxlXIe\"\n  },\n  \"kid\": \"obCHRLVDx634Cax_Kr3B8fd_-xj5kAj0r0Kvvvmq1z8\",\n  \"skid\": \"0Bz8yRwu9eC8Gi7cYOwAKMJ8jysInhAtwH8k8m9MX04\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#123-nist-p-521-key","title":"1.2.3 NIST P-521 key","text":"<ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AXKDGPnD6hlQIre8aEeu33bQffkfl-eQfQXgzNXQX7XFYt5GKA1N6w4-f0_Ci7fQNKGkQuCoAu5-6CNk9M_cHiDi\",\n  \"y\": \"Ae4-APhoZAmM99MdY9io9IZA43dN7dA006wlFb6LJ9bcusJOi5R-o3o3FhCjt5KTv_JxYbo6KU4PsBwQ1eeKyJ0U\",\n  \"d\": \"AP9l2wmQ85P5XD84CkEQVWHaX_46EDvHxLWHEKsHFSQYjEh6BDSuyy1TUNv68v8kpbLCDjvsBc3cIBqC4_T1r4pU\"\n}\n</code></pre></li> <li>Sender kid (jwk thumbprint raw base64 URL encoded): <code>oq-WBIGQm-iHiNRj6nId4-E1QtY8exzp8C56SziUfeU</code></li> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"ALmUHkd9Gi2NApJojNzzA34Qdd1-KLnq6jd2UJ9wl-xJzTQ2leg8qi3-hrFs7NqNfxqO6vE5bBoWYFeAcf3LqJOU\",\n  \"y\": \"AN-MutmkAXGzlgzSQJRnctHDcjQQNpRek-8BeqyUDXdZKNGKSMEAzw6Hnl3VdvsvihQfrxcajpx5PSnwxbbdakHq\",\n  \"d\": \"AKv-YbKdI6y8NRMP-e17-RjZyRTfGf0Xh9Og5g7q7aq0xS2mO59ttIJ67XHW5SPTBQDbltdUcydKroWNUIGvhKNv\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>XmLVV-CqMkTGQIe6-KecWZWtZVwORTMP2y5aqMPV7P4</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILTFQVStBMjU2S1ciLCJhcHUiOiJiM0V0VjBKSlIxRnRMV2xJYVU1U2FqWnVTV1EwTFVVeFVYUlpPR1Y0ZW5BNFF6VTJVM3BwVldabFZRIiwiYXB2IjoiV0cxTVZsWXRRM0ZOYTFSSFVVbGxOaTFMWldOWFdsZDBXbFozVDFKVVRWQXllVFZoY1UxUVZqZFFOQSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsiY3J2IjoiUC01MjEiLCJrdHkiOiJFQyIsIngiOiJBRHdFcDBlZWJseGZhZHdkVFBlTV81b29MZGdHaWhLM3Bqd3AxakxXWmdxLUJrRV9IZDhnZFQ4RThOSFVvWjRFeWVvbWVKX3J0WGFlVnlHdjdoVzBPb1MtIiwieSI6IkFaY0Zzemg3RUstZ2lGQXRIZ2hPQ21uR3NNN1QzSzFjeUhBV0NwYXBqd2ZEclJjYnE5THdhQjFyRVVOdDMyYndLdWNNNG9idldkSndxVGE3SGVZYlNVOHUifSwia2lkIjoiWG1MVlYtQ3FNa1RHUUllNi1LZWNXWld0WlZ3T1JUTVAyeTVhcU1QVjdQNCIsInNraWQiOiJvcS1XQklHUW0taUhpTlJqNm5JZDQtRTFRdFk4ZXh6cDhDNTZTemlVZmVVIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"encrypted_key\": \"9OyKH83g7RoS-ykrAoQpqn6FUUuYxeKukJbk6y2x9wfoe__rM8sP4w\",\n  \"iv\": \"JO2ENu2k2O1OFgjl\",\n  \"ciphertext\": \"wpomqxgGqQIWQ_lWCm4\",\n  \"tag\": \"XgUX1EOGAePvjlcO7Dzb3A\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILTFQVStBMjU2S1ciLCJhcHUiOiJiM0V0VjBKSlIxRnRMV2xJYVU1U2FqWnVTV1EwTFVVeFVYUlpPR1Y0ZW5BNFF6VTJVM3BwVldabFZRIiwiYXB2IjoiV0cxTVZsWXRRM0ZOYTFSSFVVbGxOaTFMWldOWFdsZDBXbFozVDFKVVRWQXllVFZoY1UxUVZqZFFOQSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsia3R5IjoiRUMiLCJjcnYiOiJQLTUyMSIsIngiOiJBRHdFcDBlZWJseGZhZHdkVFBlTV81b29MZGdHaWhLM3Bqd3AxakxXWmdxLUJrRV9IZDhnZFQ4RThOSFVvWjRFeWVvbWVKX3J0WGFlVnlHdjdoVzBPb1MtIiwieSI6IkFaY0Zzemg3RUstZ2lGQXRIZ2hPQ21uR3NNN1QzSzFjeUhBV0NwYXBqd2ZEclJjYnE5THdhQjFyRVVOdDMyYndLdWNNNG9idldkSndxVGE3SGVZYlNVOHUifSwia2lkIjoiWG1MVlYtQ3FNa1RHUUllNi1LZWNXWld0WlZ3T1JUTVAyeTVhcU1QVjdQNCIsInNraWQiOiJvcS1XQklHUW0taUhpTlJqNm5JZDQtRTFRdFk4ZXh6cDhDNTZTemlVZmVVIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9.9OyKH83g7RoS-ykrAoQpqn6FUUuYxeKukJbk6y2x9wfoe__rM8sP4w.JO2ENu2k2O1OFgjl.wpomqxgGqQIWQ_lWCm4.XgUX1EOGAePvjlcO7Dzb3A</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-1PU+A256KW\",\n  \"apu\": \"b3EtV0JJR1FtLWlIaU5SajZuSWQ0LUUxUXRZOGV4enA4QzU2U3ppVWZlVQ\",\n  \"apv\": \"WG1MVlYtQ3FNa1RHUUllNi1LZWNXWld0WlZ3T1JUTVAyeTVhcU1QVjdQNA\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"A256GCM\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-521\",\n    \"x\": \"ADwEp0eeblxfadwdTPeM_5ooLdgGihK3pjwp1jLWZgq-BkE_Hd8gdT8E8NHUoZ4EyeomeJ_rtXaeVyGv7hW0OoS-\",\n    \"y\": \"AZcFszh7EK-giFAtHghOCmnGsM7T3K1cyHAWCpapjwfDrRcbq9LwaB1rEUNt32bwKucM4obvWdJwqTa7HeYbSU8u\"\n  },\n  \"kid\": \"XmLVV-CqMkTGQIe6-KecWZWtZVwORTMP2y5aqMPV7P4\",\n  \"skid\": \"oq-WBIGQm-iHiNRj6nId4-E1QtY8exzp8C56SziUfeU\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#124-x25519-key","title":"1.2.4 X25519 key","text":"<ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"WKkktGWkUB9hDITcqa1Z6MC8rcWy8fWtxuT7xwQF1lw\",\n  \"d\": \"-LEcVt6bW_ah9gY7H_WknTsg1MXq8yc42SrSJhqP0Vo\"\n}\n</code></pre></li> <li>Sender kid (jwk thumbprint raw base64 URL encoded): <code>X5INSMIv_w4Q7pljH7xjeUrRAKiBGHavSmOYyyiRugc</code></li> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"NJzDtIa7vjz-isjaI-6GKGDe2EUx26-D44d6jLILeBI\",\n  \"d\": \"MEBNdr6Tpb0XfD60NeHby-Tkmlpgr7pvVe7Q__sBbGw\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>2UR-nzYjVhsq0cZakWjE38-wUdG0S2EIrLZ8Eh0KVO0</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILTFQVStBMjU2S1ciLCJhcHUiOiJXRFZKVGxOTlNYWmZkelJSTjNCc2FrZzNlR3BsVlhKU1FVdHBRa2RJWVhaVGJVOVplWGxwVW5Wbll3IiwiYXB2IjoiTWxWU0xXNTZXV3BXYUhOeE1HTmFZV3RYYWtVek9DMTNWV1JITUZNeVJVbHlURm80Uldnd1MxWlBNQSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsiY3J2IjoiWDI1NTE5Iiwia3R5IjoiT0tQIiwieCI6InpxUDB0WHdqVVFxdnBvSVdqNS16U2Q0WVVZZjdmU2hta2dhR0dXRFFrbGsifSwia2lkIjoiMlVSLW56WWpWaHNxMGNaYWtXakUzOC13VWRHMFMyRUlyTFo4RWgwS1ZPMCIsInNraWQiOiJYNUlOU01Jdl93NFE3cGxqSDd4amVVclJBS2lCR0hhdlNtT1l5eWlSdWdjIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"encrypted_key\": \"o_tprm3F-VJE2kHFrCBtgbCVDag0Y6AwLm1jD6S3MUS_rHphYy033w\",\n  \"iv\": \"6GKRpv-Bs_2v_7a3\",\n  \"ciphertext\": \"qlfWYkCE7zu-aRVP3R8\",\n  \"tag\": \"oBDt6-tRYcLTMA7QhX0O2Q\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILTFQVStBMjU2S1ciLCJhcHUiOiJXRFZKVGxOTlNYWmZkelJSTjNCc2FrZzNlR3BsVlhKU1FVdHBRa2RJWVhaVGJVOVplWGxwVW5Wbll3IiwiYXB2IjoiTWxWU0xXNTZXV3BXYUhOeE1HTmFZV3RYYWtVek9DMTNWV1JITUZNeVJVbHlURm80Uldnd1MxWlBNQSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsia3R5IjoiT0tQIiwiY3J2IjoiWDI1NTE5IiwieCI6InpxUDB0WHdqVVFxdnBvSVdqNS16U2Q0WVVZZjdmU2hta2dhR0dXRFFrbGsifSwia2lkIjoiMlVSLW56WWpWaHNxMGNaYWtXakUzOC13VWRHMFMyRUlyTFo4RWgwS1ZPMCIsInNraWQiOiJYNUlOU01Jdl93NFE3cGxqSDd4amVVclJBS2lCR0hhdlNtT1l5eWlSdWdjIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9.o_tprm3F-VJE2kHFrCBtgbCVDag0Y6AwLm1jD6S3MUS_rHphYy033w.6GKRpv-Bs_2v_7a3.qlfWYkCE7zu-aRVP3R8.oBDt6-tRYcLTMA7QhX0O2Q</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to: <pre><code>{\n  \"alg\": \"ECDH-1PU+A256KW\",\n  \"apu\": \"WDVJTlNNSXZfdzRRN3Bsakg3eGplVXJSQUtpQkdIYXZTbU9ZeXlpUnVnYw\",\n  \"apv\": \"MlVSLW56WWpWaHNxMGNaYWtXakUzOC13VWRHMFMyRUlyTFo4RWgwS1ZPMA\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"A256GCM\",\n  \"epk\": {\n    \"kty\": \"OKP\",\n    \"crv\": \"X25519\",\n    \"x\": \"zqP0tXwjUQqvpoIWj5-zSd4YUYf7fShmkgaGGWDQklk\"\n  },\n  \"kid\": \"2UR-nzYjVhsq0cZakWjE38-wUdG0S2EIrLZ8Eh0KVO0\",\n  \"skid\": \"X5INSMIv_w4Q7pljH7xjeUrRAKiBGHavSmOYyyiRugc\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#2-xc20p-content-encryption","title":"2 XC20P content encryption","text":""},{"location":"features/0334-jwe-envelope/authcrypt-examples/#21-multi-recipients-jwes","title":"2.1 Multi recipients JWEs","text":""},{"location":"features/0334-jwe-envelope/authcrypt-examples/#211-nist-p-256-keys","title":"2.1.1 NIST P-256 keys","text":"<p>The packer generates the following protected headers that includes the skid: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"XC20P\",\"skid\":\"T1jGtZoU-Xa_5a1QKexUU0Jq9WKDtS7TCowVvjoFH04\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInNraWQiOiJUMWpHdFpvVS1YYV81YTFRS2V4VVUwSnE5V0tEdFM3VENvd1Z2am9GSDA0IiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9</code> - Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"46OXm1dUTO3MB-8zoxbn-9dk0khgeIqsKFO-nTJ9keM\",\n  \"y\": \"8IlrwB-dl5bFd5RT4YAbgAdj5Y-a9zhc9wCMnXDZDvA\",\n  \"d\": \"58GZDz9_opy-nEeaJ_cyEL63TO-l063aV5nLADCgsGY\"\n}\n</code></pre> - Sender kid (jwk thumbprint raw base64 URL encoded): <code>T1jGtZoU-Xa_5a1QKexUU0Jq9WKDtS7TCowVvjoFH04</code> - Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"r9MRjEQ7CBxAgMyEG3ZjIlkGCuRX0rTaBdbkAcY17hA\",\n  \"y\": \"MRSgHQycDFPdSABGv5V0Qd-2q7ebs_x0_fNFyabGgXU\",\n  \"d\": \"LK9yfSxuET5n5uZDNO-64sJKWxJs7LTkqhA4mAuKQnE\"\n}\n</code></pre> - Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>dmfXisqWjRT-tFpODOD-G0CBF6zjHywNUjrrD3IFmcs</code> - Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"PMhlaU_KNEWou004AEyAFoJi8vNOnY75ROiRzzjhDR0\",\n  \"y\": \"tEcJNRv2rqYlYWeRloRabcp2lRorRaZTLM0ZNBoEyN0\",\n  \"d\": \"t1-QysBdkbkpqEBDo_JPsi-6YqD24UoAGBrruI2XNhA\"\n}\n</code></pre> - Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>2_Sf_YshIFhQ11NH9muAxLWwyFUvJnfXbYFOAC-8HTw</code> - Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"V9dWH69KZ_bvrxdWgt5-o-KnZLcGuWjAKVWMueiQioM\",\n  \"y\": \"lvsUBieuXV6qL4R3L94fCJGu8SDifqh3fAtN2plPWX4\",\n  \"d\": \"llg97kts4YxIF-r3jn7wcZ-zV0hLcn_AydIKHDF-HJc\"\n}\n</code></pre> - Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>mKtrI7SV3z2U9XyhaaTYlQFX1ANi6Wkli8b3NWVq4C4</code> - List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>2_Sf_YshIFhQ11NH9muAxLWwyFUvJnfXbYFOAC-8HTw.dmfXisqWjRT-tFpODOD-G0CBF6zjHywNUjrrD3IFmcs.mKtrI7SV3z2U9XyhaaTYlQFX1ANi6Wkli8b3NWVq4C4</code> - Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>PNKzNc6e0MtDtIGamjsx2fytSu6t8GygofQbzTrtMNA</code> - Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInNraWQiOiJUMWpHdFpvVS1YYV81YTFRS2V4VVUwSnE5V0tEdFM3VENvd1Z2am9GSDA0IiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"VDFqR3Rab1UtWGFfNWExUUtleFVVMEpxOVdLRHRTN1RDb3dWdmpvRkgwNA\",\n        \"apv\": \"ZG1mWGlzcVdqUlQtdEZwT0RPRC1HMENCRjZ6akh5d05VanJyRDNJRm1jcw\",\n        \"kid\": \"dmfXisqWjRT-tFpODOD-G0CBF6zjHywNUjrrD3IFmcs\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"80NGcUh0mIy_XrcaAqD7GCHF0FU2W5j4Jt-wfwxvJVs\",\n          \"y\": \"KpsNL9A-FGgL7S97ce8wcWYc9J1Q6_luxKAFIu7BNIw\"\n        }\n      },\n      \"encrypted_key\": \"wGQO8LX7o9JmYI0PIGUruU7i6ybZYefsTanZuo7hIDyn21ix6fSFPOmvgjPxZ8q_-hZF2yGYtudfLiuPzXlybWJkmTlP9PcY\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"VDFqR3Rab1UtWGFfNWExUUtleFVVMEpxOVdLRHRTN1RDb3dWdmpvRkgwNA\",\n        \"apv\": \"ZG1mWGlzcVdqUlQtdEZwT0RPRC1HMENCRjZ6akh5d05VanJyRDNJRm1jcw\",\n        \"kid\": \"2_Sf_YshIFhQ11NH9muAxLWwyFUvJnfXbYFOAC-8HTw\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"4YrbAQCLLya1XqRvjfcYdonllWQulrLP7zE0ooclKXA\",\n          \"y\": \"B3tI8lsWHRwBQ19pAFzXiBkLgpE6leTeQT6b709gllE\"\n        }\n      },\n      \"encrypted_key\": \"5tY3t1JI8L6s974kmXbzKMaePHygNan2Qqpd1B0BiqBsjaHNUH2Unv1IMGiT3oQD0xXeVPAxQq7vNZgANitxBbgG_uxGiRld\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"VDFqR3Rab1UtWGFfNWExUUtleFVVMEpxOVdLRHRTN1RDb3dWdmpvRkgwNA\",\n        \"apv\": \"ZG1mWGlzcVdqUlQtdEZwT0RPRC1HMENCRjZ6akh5d05VanJyRDNJRm1jcw\",\n        \"kid\": \"mKtrI7SV3z2U9XyhaaTYlQFX1ANi6Wkli8b3NWVq4C4\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"-e9kPGp2rmtpFs2zzTaY6xfeXjr1Xua1vHCQZRKJ54s\",\n          \"y\": \"Mc7b8U06KHV__1-XMaReilLxa63LcICqsPtkZGXEkEs\"\n        }\n      },\n      \"encrypted_key\": \"zVQUQytYv4EmQS0zye3IsXiN_2ol-Qn2nvyaJgEPvNdwFuzTFPOupTl-PeOhkRvxPfuLlw5TKnSRyPUejP8zyHbBgUZ6gDmz\"\n    }\n  ],\n  \"aad\": \"PNKzNc6e0MtDtIGamjsx2fytSu6t8GygofQbzTrtMNA\",\n  \"iv\": \"UKgm1XTPf1QFDXoRWlf-KrsBRQKSwpBA\",\n  \"ciphertext\": \"pbwy8HEnr1hPA0Jt5ho\",\n  \"tag\": \"nUazXvxpMXGoL1__92CAyA\"\n}\n</code></pre></p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#212-nist-p-384-keys","title":"2.1.2 NIST P-384 keys","text":"<p>The packer generates the following protected headers that includes the skid: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"XC20P\",\"skid\":\"xXdnS3M4Bb497A0ko9c6H0D4NNbj1XpwGr4Tk9Fcw7k\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInNraWQiOiJ4WGRuUzNNNEJiNDk3QTBrbzljNkgwRDROTmJqMVhwd0dyNFRrOUZjdzdrIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9</code> - Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"bfuATmVQ_jxLIgfuhKNYrNRNu-VnK4FzTCCVRvycgekS8fIuC4rZS9uQi6Q2Ujwd\",\n  \"y\": \"XkVJ93cLKpeZeCMEOsHRKk4rse1zXpzY6yUibEtwZG9nFWF05Ro8OQs5fZVK2TWC\",\n  \"d\": \"OVzGxGyyaHGJpx1MoSwPjmWPas28sfq1tj7UkYFoK3ENsujmzUduAW6HwyaBlXRW\"\n}\n</code></pre> - Sender kid (jwk thumbprint raw base64 URL encoded): <code>xXdnS3M4Bb497A0ko9c6H0D4NNbj1XpwGr4Tk9Fcw7k</code> - Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"xhk5K7x4xw9OJpkFhmsY39jceQqx57psvcZstiNZmKbXD7kT9ajfGKFA6YA-ali5\",\n  \"y\": \"7Hj32-JDMNDYWRGy3f-0E9lbUGp6yURMaZ9M36Q_FPgljKgHa9i0Fn1ogr_zEmO3\",\n  \"d\": \"Pc3r6eg15XZeKgTDMPcGjf_SvImZxG4bDzgCh3QShClAwMdmoNbzPZGhBByNrlvO\"\n}\n</code></pre> - Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>aIlhDTWJmT-_Atad5EBbvbZPkPnz2IYT85I6T44kcE4</code> - Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"wqW3DUkUAT0Cyk3hq0KVJbqtPSJOoqulp_Tqa29jBEPliIJ9rnq7cRkJyxArCYAj\",\n  \"y\": \"ZfBtdTTVRh9SeQDCwsgAo15cCX2I-7J6xdyxDPyH8LBhbUA_8npHvNquKGta9p8x\",\n  \"d\": \"krddjYsOD4YIIkNjWXTrYV9rOVlmLNaeoLHChJ5oUr4c21LHxGL4xTI1bEoXKgJ2\"\n}\n</code></pre> - Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>02WdA5ip_Amam611KA6fdoTs533yZH-ovfpt8t9zVjg</code> - Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"If6iEafrkcL53mVYCbm5rmnwAw3kjb13gUjBoDePggO7xMiSFyej4wbTabdCyfbg\",\n  \"y\": \"nLX6lEce-9r19NA_nI5mGK3YFLiX9IYRgXZZCUd_Br91PaE8Mr1JR01utAPoGx36\",\n  \"d\": \"jriJKFpQfzJtOrp7PhGvH0osHJQJbZrAKjD95itivioVawzMz9wcI_h9VsFV3ff0\"\n}\n</code></pre> - Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>zeqnfYLFWtnJ_e5npBs7CtM5KkToyyM9kCKIFlcyId0</code> - List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>02WdA5ip_Amam611KA6fdoTs533yZH-ovfpt8t9zVjg.aIlhDTWJmT-_Atad5EBbvbZPkPnz2IYT85I6T44kcE4.zeqnfYLFWtnJ_e5npBs7CtM5KkToyyM9kCKIFlcyId0</code> - Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>CftHmHttuxR6mRrHe-zBXV2UEvL2wvZEt5yeFDhYSF8</code> - Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInNraWQiOiJ4WGRuUzNNNEJiNDk3QTBrbzljNkgwRDROTmJqMVhwd0dyNFRrOUZjdzdrIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"eFhkblMzTTRCYjQ5N0Ewa285YzZIMEQ0Tk5iajFYcHdHcjRUazlGY3c3aw\",\n        \"apv\": \"YUlsaERUV0ptVC1fQXRhZDVFQmJ2YlpQa1BuejJJWVQ4NUk2VDQ0a2NFNA\",\n        \"kid\": \"aIlhDTWJmT-_Atad5EBbvbZPkPnz2IYT85I6T44kcE4\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"k7SRlQ7EwCR8VZ-LF92zOgvpFDAed0mN3mmZeCHHDznZp5TLQShFT9TdnwgsvJFP\",\n          \"y\": \"ZHzkS9BD-I2DtNPhbXuTzf6vUnykdZPus9xZnRu1rWgxVtLQ8j-Jp4YoJgdQmcOu\"\n        }\n      },\n      \"encrypted_key\": \"BO597Rs1RU3ZU-WdzWPgRnPmRULcFBihZxE7Jvl3qw3VUmR5RUXY0Xy9k_dWRnuRCh9Yzxef7tXlqVMaL4KBCfaAbAEOReQw\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"eFhkblMzTTRCYjQ5N0Ewa285YzZIMEQ0Tk5iajFYcHdHcjRUazlGY3c3aw\",\n        \"apv\": \"YUlsaERUV0ptVC1fQXRhZDVFQmJ2YlpQa1BuejJJWVQ4NUk2VDQ0a2NFNA\",\n        \"kid\": \"02WdA5ip_Amam611KA6fdoTs533yZH-ovfpt8t9zVjg\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"QT9Q_zU9VE3K9r_50mKh7iG8SxYeXVvwnhykphMAk8akfnTeB7FIRC2MzFat9JMT\",\n          \"y\": \"3HeQPqQ_BS5vy2e2L7kgMhHNwNQ2K1pmL9LImrBg8XROuc9EaAGnFSQ439bZXg9y\"\n        }\n      },\n      \"encrypted_key\": \"oKVlxrYhp8Bvr6s6CW7DxTSCMIFMkqLjDP9sCIkLoetHlXM5Mngq46CUqHusKTceHdSOL8sGUbeSBo6lXRKArywtjiVVyStW\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"eFhkblMzTTRCYjQ5N0Ewa285YzZIMEQ0Tk5iajFYcHdHcjRUazlGY3c3aw\",\n        \"apv\": \"YUlsaERUV0ptVC1fQXRhZDVFQmJ2YlpQa1BuejJJWVQ4NUk2VDQ0a2NFNA\",\n        \"kid\": \"zeqnfYLFWtnJ_e5npBs7CtM5KkToyyM9kCKIFlcyId0\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"GGFw14WnABx5S__MLwjy7WPgmPzCNbygbJikSqwx1nQ7APAiIyLeiAeZnAFQSr8C\",\n          \"y\": \"Bjev4lkaRbd4Ery0vnO8Ox4QgIDGbuflmFq0HhL-QHIe3KhqxrqZqbQYGlDNudEv\"\n        }\n      },\n      \"encrypted_key\": \"S8vnyPjW_19Hws3-igk-cVTSqVTY0_D9SWahnYnWBFBqTdx0b0e8hf06Oiou31Ww-Y3p8Z3O_okqQGzZMWUMLSxUPeCR2ZWx\"\n    }\n  ],\n  \"aad\": \"CftHmHttuxR6mRrHe-zBXV2UEvL2wvZEt5yeFDhYSF8\",\n  \"iv\": \"jTaCuNXs4QdX6HuWvl5AsqIEv4nh2JMP\",\n  \"ciphertext\": \"7y463zoRKgVfpKh3EBw\",\n  \"tag\": \"8YKdJpF2DnQQwEkBcbuEnw\"\n}\n</code></pre></p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#213-nist-p-521-keys","title":"2.1.3 NIST P-521 keys","text":"<p>The packer generates the following protected headers that includes the skid: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"XC20P\",\"skid\":\"bq3OI5517dSIMeD9K3lTqvkvvkmsRtifD6tvjlrKYsU\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInNraWQiOiJicTNPSTU1MTdkU0lNZUQ5SzNsVHF2a3Z2a21zUnRpZkQ2dHZqbHJLWXNVIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9</code> - Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"ACN9T83BbPNn1eRyo-TrL0GyC7kBNQvgUxk55fCeQKDSTVhbzCKia7WecCUshyEF-BOQbfEsOIUCq3g7xY3VEeth\",\n  \"y\": \"APDIfDv6abLQ-Zb_p8PxwJe1x3U0-PdgXLNbtS7evGuUROHt79SVkpfXcZ3UaEc6cMoFfd2oMvbmUjCMM4-Sgipn\",\n  \"d\": \"AXCGyR9uXY8vDr7D4HvMxep-d5biQzgHR6WsdOF4R5M9qYb8FhRIQCMbmDSZzCuqgGgXrPRMPm5-omvWVeYqwwa3\"\n}\n</code></pre> - Sender kid (jwk thumbprint raw base64 URL encoded): <code>bq3OI5517dSIMeD9K3lTqvkvvkmsRtifD6tvjlrKYsU</code> - Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AZi-AxJkB09qw8dBnNrz53xM-wER0Y5IYXSEWSTtzI5Sdv_5XijQn9z-vGz1pMdww-C75GdpAzp2ghejZJSxbAd6\",\n  \"y\": \"AZzRvW8NBytGNbF3dyNOMHB0DHCOzGp8oYBv_ZCyJbQUUnq-TYX7j8-PlKe9Ce5acxZzrcUKVtJ4I8JgI5x9oXIW\",\n  \"d\": \"AHGOZNkAcQCdDZOpQRdbH-f89mpjY_kGmtEpTExd51CcRlHhXuuAr6jcgb8YStwy9FN7vCU1y5LnJfKhGUGrP2a4\"\n}\n</code></pre> - Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>7icoqReWFlpF16dzZD3rBgK1cJ265WzfF9sJJXqOe0M</code> - Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"ASRvWU-d_XI2S1UQb7PoXIXTLXd8vgLmFb-9mmmIrzTMmIXFXpsDN9_1-Xg_r3qkEg-zBjTi327GIseWFGMa0Mrp\",\n  \"y\": \"AJ0VyjDn4Rn6SKamFms4593mW5K936d4Jr7-J5OjJqTZtS6APgNkrwFjhKPHQfg7o8T4pmX7vlfFY5Flx7IOYJuw\",\n  \"d\": \"ALzWMohuwSqkiqqEhijiBoH6kJ580Dtxe7CfgqEboc5DG0pMtAUf-a91VbmR1U8bQox-B4_YRXoFLRns2tI_wPYz\"\n}\n</code></pre> - Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>BUEVQ3FlDsml4JYrLCwwsL5BUZt-hYwb2B0SoJ6dzHc</code> - Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AB2ke_2nVg95OP3Xb4Fg0Gg4KgfZZf3wBEYoOlGhXmHNCj56G10vnOe1hGRKIoD-JkPWuulcUtsIUO7r3Rz2mLP0\",\n  \"y\": \"AJTaqfF8d4cFv_fP4Uoqq-uCCObmyPsD1CphbCuCZumarfzjA5SpAQCdfz3No4Nhn53OqdcTkm654Yvfj1vOp5t6\",\n  \"d\": \"Af6Ba1x6i6glhRcR2RmZMZJ5BJXibpMB0TqjY_2Fe2LekS9QQK21JtrF20dj_gahxcrnfcn8oJ2xCrEMKaexgcsb\"\n}\n</code></pre> - Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>C9iN-jkTFBbTz3Yv3FquR3dAsHYnAIg1_hT0jsefLDE</code> - List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>7icoqReWFlpF16dzZD3rBgK1cJ265WzfF9sJJXqOe0M.BUEVQ3FlDsml4JYrLCwwsL5BUZt-hYwb2B0SoJ6dzHc.C9iN-jkTFBbTz3Yv3FquR3dAsHYnAIg1_hT0jsefLDE</code> - Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>VBNrffp39h1F6sg0dzkArcd2WjpKeqEvqt6HNXaVfKU</code> - Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInNraWQiOiJicTNPSTU1MTdkU0lNZUQ5SzNsVHF2a3Z2a21zUnRpZkQ2dHZqbHJLWXNVIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"YnEzT0k1NTE3ZFNJTWVEOUszbFRxdmt2dmttc1J0aWZENnR2amxyS1lzVQ\",\n        \"apv\": \"N2ljb3FSZVdGbHBGMTZkelpEM3JCZ0sxY0oyNjVXemZGOXNKSlhxT2UwTQ\",\n        \"kid\": \"7icoqReWFlpF16dzZD3rBgK1cJ265WzfF9sJJXqOe0M\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"ABd71Xomy3mv-mkAipKb18UQ-1xXt7tGDDwf0k5fpLADg1qK--Jhn8TdzyjTuve7rJQrlCJH4GjuQjCWVs4T7J_T\",\n          \"y\": \"ANrWrk69QRi4cr8ZbU2vF_0jSjTIUn-fQCHJtxLg3uuvLtzGW7oIEkUFJq_sTZXL_gaPdFIWlI4aIjKRgzOUP_ze\"\n        }\n      },\n      \"encrypted_key\": \"lZa-4LTyaDP01wmN8bvoD69MLl3VY2H_wNaNJ7kYzTFExlgYTPNrFJ5XL6T_h1DUULX0TYJVxbIWQeJ_x_7i-xSv7-BHbFcm\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"YnEzT0k1NTE3ZFNJTWVEOUszbFRxdmt2dmttc1J0aWZENnR2amxyS1lzVQ\",\n        \"apv\": \"N2ljb3FSZVdGbHBGMTZkelpEM3JCZ0sxY0oyNjVXemZGOXNKSlhxT2UwTQ\",\n        \"kid\": \"BUEVQ3FlDsml4JYrLCwwsL5BUZt-hYwb2B0SoJ6dzHc\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"ALGN2OH1_DKtEZ-990uL1kzHYhYmZD-stOdL6_NMReCKEPZil7Z1tsq0g9l0HNi6DWuMjNyiJCfDd1erWpByFAOX\",\n          \"y\": \"AQgB2aE_3GltqbWzKbWbLa6Fdq6jO4A3LrYUnNDNIuHY6eRH9sRU0yWjmcmWCoukT98wksXJ3isHr9-NqFuZLehi\"\n        }\n      },\n      \"encrypted_key\": \"bybMPkSjuSz8lLAPFJHrxjl1buE8cfONEzvQ2U64h8L0QEZPLK_VewbXVflEPNrOo3oTWlI_878GIKvkxJ8cJOD6a0kZmr87\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"YnEzT0k1NTE3ZFNJTWVEOUszbFRxdmt2dmttc1J0aWZENnR2amxyS1lzVQ\",\n        \"apv\": \"N2ljb3FSZVdGbHBGMTZkelpEM3JCZ0sxY0oyNjVXemZGOXNKSlhxT2UwTQ\",\n        \"kid\": \"C9iN-jkTFBbTz3Yv3FquR3dAsHYnAIg1_hT0jsefLDE\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"AZKyI6Mg8OdKUYqo3xuKjHiVrlV56_qGBzdwr86QSnebq3Y69Z0qETiTumQv5J3ECmZzs4DiETryRuzdHc2RkKBZ\",\n          \"y\": \"ARJJT7MWjTWWB7leblQgg7PYn_0deScO7AATlcnukFsLbzly0LHs1msVXaerQUCHPg2t-sYGxDP7w0iaDHB8k3Tj\"\n        }\n      },\n      \"encrypted_key\": \"nMGoNk1brn9uO9hlSa7NwVgFUMXnxpKKPkuFHSE2aM_N8q8wJbVBLC9rJ9sPIiSU20tq2sJXaAcoMteajOX6wj_Hzl1uRT1e\"\n    }\n  ],\n  \"aad\": \"VBNrffp39h1F6sg0dzkArcd2WjpKeqEvqt6HNXaVfKU\",\n  \"iv\": \"h0bbZygiAx9MMO2Huxym_QnwrXZHhdyQ\",\n  \"ciphertext\": \"LABYmf_sfPNGgls0wvk\",\n  \"tag\": \"z1rZOEgyryiW_3d5gxnMUQ\"\n}\n</code></pre></p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#214-x25519-keys","title":"2.1.4 X25519 keys","text":"<p>The packer generates the following protected headers that includes the skid: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"XC20P\",\"skid\":\"j8E-tcw1Z_eOCoKEH-7a9T532r8zXfcavbPZlofN0Ek\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInNraWQiOiJqOEUtdGN3MVpfZU9Db0tFSC03YTlUNTMycjh6WGZjYXZiUFpsb2ZOMEVrIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9</code> - Sender key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"g3Lpdd_DRgjK28qi0sR0-hI-zv7a1X52vpzKc6ZM1Qs\",\n  \"d\": \"cPU_Io7RRHNb_xkQ_D6u3ER4vSjvsILDCKwOj8kVHXQ\"\n}\n</code></pre> - Sender kid (jwk thumbprint raw base64 URL encoded): <code>j8E-tcw1Z_eOCoKEH-7a9T532r8zXfcavbPZlofN0Ek</code> - Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"VlhpUXj-oGs9ge-VLrmYF7Xuzy73YchIfckaYcQefBw\",\n  \"d\": \"QFHCCy0wzgJ_AlGMnjetTd0tnDaZ_7yqJODSV0d-kkg\"\n}\n</code></pre> - Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>_DHSbVaMeZxriDJn5VoHXYXo6BJacwZx_fGIBfCiJ5c</code> - Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"y52sexwATOR5J5znNp94MFx19J0rkgzNyLESMVhkE2M\",\n  \"d\": \"6NwEk3_8lKOwLaZM2YkLdW9MF2zDqMjAx_G-uDoAAkw\"\n}\n</code></pre> - Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>n2MxD23PaCkz7vptma_1j9X2JdUoCFLzrtYuDvOA0Kc</code> - Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"BYL51mNvx1LKD2wDfga_7GZc0YYI82HhRmHtXfiz_ko\",\n  \"d\": \"MLd_nsRRb_CSzc6Ou8TZFm-A17ZpT1Aen6fIvC6ZuV8\"\n}\n</code></pre> - Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>HHN2ZcES5ps7gCjK-06bCE4EjX_hh7nq2cWd-GfnI5s</code> - List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>HHN2ZcES5ps7gCjK-06bCE4EjX_hh7nq2cWd-GfnI5s._DHSbVaMeZxriDJn5VoHXYXo6BJacwZx_fGIBfCiJ5c.n2MxD23PaCkz7vptma_1j9X2JdUoCFLzrtYuDvOA0Kc</code> - Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>K1oFStibrX4x6LplTB0-tO3cwGiZzMvG_6w0LfguVuI</code> - Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInNraWQiOiJqOEUtdGN3MVpfZU9Db0tFSC03YTlUNTMycjh6WGZjYXZiUFpsb2ZOMEVrIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"ajhFLXRjdzFaX2VPQ29LRUgtN2E5VDUzMnI4elhmY2F2YlBabG9mTjBFaw\",\n        \"apv\": \"X0RIU2JWYU1lWnhyaURKbjVWb0hYWVhvNkJKYWN3WnhfZkdJQmZDaUo1Yw\",\n        \"kid\": \"_DHSbVaMeZxriDJn5VoHXYXo6BJacwZx_fGIBfCiJ5c\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"77VAbpx5xn2iavmhzZATXwGnxjRyxjBbtNzojdWP7wo\"\n        }\n      },\n      \"encrypted_key\": \"dvBscDJj2H6kZJgfdqazZ9pXZxUzai-mcExsdr11-RNvxxPd4_Cy6rolLSsY6ugm1sCo9BgRhAW1e6vxgTnY3Ctv0_xZIhvr\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"ajhFLXRjdzFaX2VPQ29LRUgtN2E5VDUzMnI4elhmY2F2YlBabG9mTjBFaw\",\n        \"apv\": \"X0RIU2JWYU1lWnhyaURKbjVWb0hYWVhvNkJKYWN3WnhfZkdJQmZDaUo1Yw\",\n        \"kid\": \"n2MxD23PaCkz7vptma_1j9X2JdUoCFLzrtYuDvOA0Kc\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"sZtHwxjaS51BR2SBGC32jFvUgVlABZ7rkBFqJk8ktXM\"\n        }\n      },\n      \"encrypted_key\": \"2gIQKw_QpnfGbIOso_XesSGWC9ZKu4-ox1eqRu71aS-nBWAbFrdJPqSY7gzAOGUNqg_o6mC1q7coG69G9yen37DIjcoR6mD1\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"ajhFLXRjdzFaX2VPQ29LRUgtN2E5VDUzMnI4elhmY2F2YlBabG9mTjBFaw\",\n        \"apv\": \"X0RIU2JWYU1lWnhyaURKbjVWb0hYWVhvNkJKYWN3WnhfZkdJQmZDaUo1Yw\",\n        \"kid\": \"HHN2ZcES5ps7gCjK-06bCE4EjX_hh7nq2cWd-GfnI5s\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"48AJF8kNoxfHXpUtBApRMUcTf8B0Ho4i_6CvGT4arGY\"\n        }\n      },\n      \"encrypted_key\": \"o_toInYq_NP45UqqFg461O6ruUNSQNKrBXRDA06JQ-faMUUfMGRtzNHK-FzrhtodZLW5bRFFFry9aFjwg5aYloe2JG9-fEcw\"\n    }\n  ],\n  \"aad\": \"K1oFStibrX4x6LplTB0-tO3cwGiZzMvG_6w0LfguVuI\",\n  \"iv\": \"tcThx2bVV8jhteYknijC-vxSED_BKPF8\",\n  \"ciphertext\": \"DUZLQAnWzApBFdwlZDg\",\n  \"tag\": \"YLuHzCD4xSTDxe_0AWukyw\"\n}\n</code></pre></p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#22-single-recipient-jwes","title":"2.2 Single Recipient JWEs","text":"<p>Packing a message with 1 recipient using the Flattened JWE JSON serialization and the Compact JWE serialization formats as mentioned in the notes above.</p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#221-nist-p-256-key","title":"2.2.1 NIST P-256 key","text":"<ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"46OXm1dUTO3MB-8zoxbn-9dk0khgeIqsKFO-nTJ9keM\",\n  \"y\": \"8IlrwB-dl5bFd5RT4YAbgAdj5Y-a9zhc9wCMnXDZDvA\",\n  \"d\": \"58GZDz9_opy-nEeaJ_cyEL63TO-l063aV5nLADCgsGY\"\n}\n</code></pre></li> <li>Sender kid (jwk thumbprint raw base64 URL encoded): <code>T1jGtZoU-Xa_5a1QKexUU0Jq9WKDtS7TCowVvjoFH04</code></li> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"r9MRjEQ7CBxAgMyEG3ZjIlkGCuRX0rTaBdbkAcY17hA\",\n  \"y\": \"MRSgHQycDFPdSABGv5V0Qd-2q7ebs_x0_fNFyabGgXU\",\n  \"d\": \"LK9yfSxuET5n5uZDNO-64sJKWxJs7LTkqhA4mAuKQnE\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>dmfXisqWjRT-tFpODOD-G0CBF6zjHywNUjrrD3IFmcs</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILTFQVStYQzIwUEtXIiwiYXB1IjoiVkRGcVIzUmFiMVV0V0dGZk5XRXhVVXRsZUZWVk1FcHhPVmRMUkhSVE4xUkRiM2RXZG1wdlJrZ3dOQSIsImFwdiI6IlpHMW1XR2x6Y1ZkcVVsUXRkRVp3VDBSUFJDMUhNRU5DUmpaNmFraDVkMDVWYW5KeVJETkpSbTFqY3ciLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJjcnYiOiJQLTI1NiIsImt0eSI6IkVDIiwieCI6Ik5ZM3Zra04wYTFPRTBuZk1UaDR4U25IU1A2c0VianYycWp5T3J6Rm9TNnMiLCJ5IjoibUhOdnZYUmVmV0lHcU4zTC1ZWnctdElMTXZlUURWcEEzSk55V20tR21HUSJ9LCJraWQiOiJkbWZYaXNxV2pSVC10RnBPRE9ELUcwQ0JGNnpqSHl3TlVqcnJEM0lGbWNzIiwic2tpZCI6IlQxakd0Wm9VLVhhXzVhMVFLZXhVVTBKcTlXS0R0UzdUQ293VnZqb0ZIMDQiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"encrypted_key\": \"dXV4byLXvAHCGKSNqOT87cOwTmdlhn9665LvwXre0BJqSectrLZVQZ4udqKCccgdZAGwmIct5T-uwGYz_tLkOUQBbTXBxHDt\",\n  \"iv\": \"ULEzDlTLgPXfS3a-SfspZmD02o53DfTB\",\n  \"ciphertext\": \"8Z4TLHADLiuHmQEFMrU\",\n  \"tag\": \"oJgQoovq__wSPgzco1udpA\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILTFQVStYQzIwUEtXIiwiYXB1IjoiVkRGcVIzUmFiMVV0V0dGZk5XRXhVVXRsZUZWVk1FcHhPVmRMUkhSVE4xUkRiM2RXZG1wdlJrZ3dOQSIsImFwdiI6IlpHMW1XR2x6Y1ZkcVVsUXRkRVp3VDBSUFJDMUhNRU5DUmpaNmFraDVkMDVWYW5KeVJETkpSbTFqY3ciLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2IiwieCI6Ik5ZM3Zra04wYTFPRTBuZk1UaDR4U25IU1A2c0VianYycWp5T3J6Rm9TNnMiLCJ5IjoibUhOdnZYUmVmV0lHcU4zTC1ZWnctdElMTXZlUURWcEEzSk55V20tR21HUSJ9LCJraWQiOiJkbWZYaXNxV2pSVC10RnBPRE9ELUcwQ0JGNnpqSHl3TlVqcnJEM0lGbWNzIiwic2tpZCI6IlQxakd0Wm9VLVhhXzVhMVFLZXhVVTBKcTlXS0R0UzdUQ293VnZqb0ZIMDQiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0.dXV4byLXvAHCGKSNqOT87cOwTmdlhn9665LvwXre0BJqSectrLZVQZ4udqKCccgdZAGwmIct5T-uwGYz_tLkOUQBbTXBxHDt.ULEzDlTLgPXfS3a-SfspZmD02o53DfTB.8Z4TLHADLiuHmQEFMrU.oJgQoovq__wSPgzco1udpA</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-1PU+XC20PKW\",\n  \"apu\": \"VDFqR3Rab1UtWGFfNWExUUtleFVVMEpxOVdLRHRTN1RDb3dWdmpvRkgwNA\",\n  \"apv\": \"ZG1mWGlzcVdqUlQtdEZwT0RPRC1HMENCRjZ6akh5d05VanJyRDNJRm1jcw\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"XC20P\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-256\",\n    \"x\": \"NY3vkkN0a1OE0nfMTh4xSnHSP6sEbjv2qjyOrzFoS6s\",\n    \"y\": \"mHNvvXRefWIGqN3L-YZw-tILMveQDVpA3JNyWm-GmGQ\"\n  },\n  \"kid\": \"dmfXisqWjRT-tFpODOD-G0CBF6zjHywNUjrrD3IFmcs\",\n  \"skid\": \"T1jGtZoU-Xa_5a1QKexUU0Jq9WKDtS7TCowVvjoFH04\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#222-nist-p-384-key","title":"2.2.2 NIST P-384 key","text":"<ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"bfuATmVQ_jxLIgfuhKNYrNRNu-VnK4FzTCCVRvycgekS8fIuC4rZS9uQi6Q2Ujwd\",\n  \"y\": \"XkVJ93cLKpeZeCMEOsHRKk4rse1zXpzY6yUibEtwZG9nFWF05Ro8OQs5fZVK2TWC\",\n  \"d\": \"OVzGxGyyaHGJpx1MoSwPjmWPas28sfq1tj7UkYFoK3ENsujmzUduAW6HwyaBlXRW\"\n}\n</code></pre></li> <li>Sender kid (jwk thumbprint raw base64 URL encoded): <code>xXdnS3M4Bb497A0ko9c6H0D4NNbj1XpwGr4Tk9Fcw7k</code></li> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"xhk5K7x4xw9OJpkFhmsY39jceQqx57psvcZstiNZmKbXD7kT9ajfGKFA6YA-ali5\",\n  \"y\": \"7Hj32-JDMNDYWRGy3f-0E9lbUGp6yURMaZ9M36Q_FPgljKgHa9i0Fn1ogr_zEmO3\",\n  \"d\": \"Pc3r6eg15XZeKgTDMPcGjf_SvImZxG4bDzgCh3QShClAwMdmoNbzPZGhBByNrlvO\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>aIlhDTWJmT-_Atad5EBbvbZPkPnz2IYT85I6T44kcE4</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILTFQVStYQzIwUEtXIiwiYXB1IjoiZUZoa2JsTXpUVFJDWWpRNU4wRXdhMjg1WXpaSU1FUTBUazVpYWpGWWNIZEhjalJVYXpsR1kzYzNhdyIsImFwdiI6IllVbHNhRVJVVjBwdFZDMWZRWFJoWkRWRlFtSjJZbHBRYTFCdWVqSkpXVlE0TlVrMlZEUTBhMk5GTkEiLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJjcnYiOiJQLTM4NCIsImt0eSI6IkVDIiwieCI6Inp1TjJhYTZBdmRHVVdjaHNyMTdBMENvOWFmcnlnRll6TjRxZlM0dnlNS05BTF83dVVhR1d2ZVBMNkpoc25MMnYiLCJ5IjoiZTJva1U5VWUzbE9CUWxEZnFVczE5NjFQU2tMTkg1d3U1V2NRd2ZuYzdEdmhsU2tXSU9iQWpoekhoVUVZUjRBZSJ9LCJraWQiOiJhSWxoRFRXSm1ULV9BdGFkNUVCYnZiWlBrUG56MklZVDg1STZUNDRrY0U0Iiwic2tpZCI6InhYZG5TM000QmI0OTdBMGtvOWM2SDBENE5OYmoxWHB3R3I0VGs5RmN3N2siLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"encrypted_key\": \"9bCR6CdqKSRLCFf_vShRhub1pNwoPRypHEqEMfamxy4ZcSp7y8SULzTs2rMmnBt8iJn1PiaBEYbsjsOgzgYamXQ-3OQeIg5z\",\n  \"iv\": \"ryiQAsZiEVcDqJb1jQpG9nQ0p50cXJSM\",\n  \"ciphertext\": \"xQiyTPTrLUFvTeVn9CI\",\n  \"tag\": \"b65D-L5AybH327bWsEIRUg\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILTFQVStYQzIwUEtXIiwiYXB1IjoiZUZoa2JsTXpUVFJDWWpRNU4wRXdhMjg1WXpaSU1FUTBUazVpYWpGWWNIZEhjalJVYXpsR1kzYzNhdyIsImFwdiI6IllVbHNhRVJVVjBwdFZDMWZRWFJoWkRWRlFtSjJZbHBRYTFCdWVqSkpXVlE0TlVrMlZEUTBhMk5GTkEiLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMzg0IiwieCI6Inp1TjJhYTZBdmRHVVdjaHNyMTdBMENvOWFmcnlnRll6TjRxZlM0dnlNS05BTF83dVVhR1d2ZVBMNkpoc25MMnYiLCJ5IjoiZTJva1U5VWUzbE9CUWxEZnFVczE5NjFQU2tMTkg1d3U1V2NRd2ZuYzdEdmhsU2tXSU9iQWpoekhoVUVZUjRBZSJ9LCJraWQiOiJhSWxoRFRXSm1ULV9BdGFkNUVCYnZiWlBrUG56MklZVDg1STZUNDRrY0U0Iiwic2tpZCI6InhYZG5TM000QmI0OTdBMGtvOWM2SDBENE5OYmoxWHB3R3I0VGs5RmN3N2siLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0.9bCR6CdqKSRLCFf_vShRhub1pNwoPRypHEqEMfamxy4ZcSp7y8SULzTs2rMmnBt8iJn1PiaBEYbsjsOgzgYamXQ-3OQeIg5z.ryiQAsZiEVcDqJb1jQpG9nQ0p50cXJSM.xQiyTPTrLUFvTeVn9CI.b65D-L5AybH327bWsEIRUg</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-1PU+XC20PKW\",\n  \"apu\": \"eFhkblMzTTRCYjQ5N0Ewa285YzZIMEQ0Tk5iajFYcHdHcjRUazlGY3c3aw\",\n  \"apv\": \"YUlsaERUV0ptVC1fQXRhZDVFQmJ2YlpQa1BuejJJWVQ4NUk2VDQ0a2NFNA\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"XC20P\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-384\",\n    \"x\": \"zuN2aa6AvdGUWchsr17A0Co9afrygFYzN4qfS4vyMKNAL_7uUaGWvePL6JhsnL2v\",\n    \"y\": \"e2okU9Ue3lOBQlDfqUs1961PSkLNH5wu5WcQwfnc7DvhlSkWIObAjhzHhUEYR4Ae\"\n  },\n  \"kid\": \"aIlhDTWJmT-_Atad5EBbvbZPkPnz2IYT85I6T44kcE4\",\n  \"skid\": \"xXdnS3M4Bb497A0ko9c6H0D4NNbj1XpwGr4Tk9Fcw7k\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#223-nist-p-521-key","title":"2.2.3 NIST P-521 key","text":"<ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"ACN9T83BbPNn1eRyo-TrL0GyC7kBNQvgUxk55fCeQKDSTVhbzCKia7WecCUshyEF-BOQbfEsOIUCq3g7xY3VEeth\",\n  \"y\": \"APDIfDv6abLQ-Zb_p8PxwJe1x3U0-PdgXLNbtS7evGuUROHt79SVkpfXcZ3UaEc6cMoFfd2oMvbmUjCMM4-Sgipn\",\n  \"d\": \"AXCGyR9uXY8vDr7D4HvMxep-d5biQzgHR6WsdOF4R5M9qYb8FhRIQCMbmDSZzCuqgGgXrPRMPm5-omvWVeYqwwa3\"\n}\n</code></pre></li> <li>Sender kid (jwk thumbprint raw base64 URL encoded): <code>bq3OI5517dSIMeD9K3lTqvkvvkmsRtifD6tvjlrKYsU</code></li> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AZi-AxJkB09qw8dBnNrz53xM-wER0Y5IYXSEWSTtzI5Sdv_5XijQn9z-vGz1pMdww-C75GdpAzp2ghejZJSxbAd6\",\n  \"y\": \"AZzRvW8NBytGNbF3dyNOMHB0DHCOzGp8oYBv_ZCyJbQUUnq-TYX7j8-PlKe9Ce5acxZzrcUKVtJ4I8JgI5x9oXIW\",\n  \"d\": \"AHGOZNkAcQCdDZOpQRdbH-f89mpjY_kGmtEpTExd51CcRlHhXuuAr6jcgb8YStwy9FN7vCU1y5LnJfKhGUGrP2a4\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>7icoqReWFlpF16dzZD3rBgK1cJ265WzfF9sJJXqOe0M</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILTFQVStYQzIwUEtXIiwiYXB1IjoiWW5FelQwazFOVEUzWkZOSlRXVkVPVXN6YkZSeGRtdDJkbXR0YzFKMGFXWkVOblIyYW14eVMxbHpWUSIsImFwdiI6Ik4ybGpiM0ZTWlZkR2JIQkdNVFprZWxwRU0zSkNaMHN4WTBveU5qVlhlbVpHT1hOS1NsaHhUMlV3VFEiLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJjcnYiOiJQLTUyMSIsImt0eSI6IkVDIiwieCI6IkFJemJtMzBZRGVIV21sXy1zeHE2c2NHbEdDS3ZuRmttR2pkc1hKOXN6bm5JQzFMSndvc1hqYmRRd29EX2NjbmtkcUtpaU4tNVVFZGtPTEZldDdXbG83bC0iLCJ5IjoiQVdDendGVjJtUFdYMnpaZzN0SHRpVE11SlhGaEtucWhUT0hPWXBzRF9uRlhGRFhrTlRyd0QyblpVNi1hU2g5Q0NLajF2N0x5VlJ0UE0ybzM5bkt3WEhXWiJ9LCJraWQiOiI3aWNvcVJlV0ZscEYxNmR6WkQzckJnSzFjSjI2NVd6ZkY5c0pKWHFPZTBNIiwic2tpZCI6ImJxM09JNTUxN2RTSU1lRDlLM2xUcXZrdnZrbXNSdGlmRDZ0dmpscktZc1UiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"encrypted_key\": \"-cL11h9eF6CRycMYxvJ6Ksmlf-97Vg2s_ziVnFF5RueiGrvKFmgQp09GIyxrMdTG2so6IRmifOlpwF0YPuzyThhmxToTyfpr\",\n  \"iv\": \"Q0sk9bMraCAJhZyFi3sOAYMoTac4ZuGj\",\n  \"ciphertext\": \"O6OlFqFMz587083_OMU\",\n  \"tag\": \"TyXZ30wpVZ6nmj16evdBnA\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILTFQVStYQzIwUEtXIiwiYXB1IjoiWW5FelQwazFOVEUzWkZOSlRXVkVPVXN6YkZSeGRtdDJkbXR0YzFKMGFXWkVOblIyYW14eVMxbHpWUSIsImFwdiI6Ik4ybGpiM0ZTWlZkR2JIQkdNVFprZWxwRU0zSkNaMHN4WTBveU5qVlhlbVpHT1hOS1NsaHhUMlV3VFEiLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJrdHkiOiJFQyIsImNydiI6IlAtNTIxIiwieCI6IkFJemJtMzBZRGVIV21sXy1zeHE2c2NHbEdDS3ZuRmttR2pkc1hKOXN6bm5JQzFMSndvc1hqYmRRd29EX2NjbmtkcUtpaU4tNVVFZGtPTEZldDdXbG83bC0iLCJ5IjoiQVdDendGVjJtUFdYMnpaZzN0SHRpVE11SlhGaEtucWhUT0hPWXBzRF9uRlhGRFhrTlRyd0QyblpVNi1hU2g5Q0NLajF2N0x5VlJ0UE0ybzM5bkt3WEhXWiJ9LCJraWQiOiI3aWNvcVJlV0ZscEYxNmR6WkQzckJnSzFjSjI2NVd6ZkY5c0pKWHFPZTBNIiwic2tpZCI6ImJxM09JNTUxN2RTSU1lRDlLM2xUcXZrdnZrbXNSdGlmRDZ0dmpscktZc1UiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0.-cL11h9eF6CRycMYxvJ6Ksmlf-97Vg2s_ziVnFF5RueiGrvKFmgQp09GIyxrMdTG2so6IRmifOlpwF0YPuzyThhmxToTyfpr.Q0sk9bMraCAJhZyFi3sOAYMoTac4ZuGj.O6OlFqFMz587083_OMU.TyXZ30wpVZ6nmj16evdBnA</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-1PU+XC20PKW\",\n  \"apu\": \"YnEzT0k1NTE3ZFNJTWVEOUszbFRxdmt2dmttc1J0aWZENnR2amxyS1lzVQ\",\n  \"apv\": \"N2ljb3FSZVdGbHBGMTZkelpEM3JCZ0sxY0oyNjVXemZGOXNKSlhxT2UwTQ\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"XC20P\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-521\",\n    \"x\": \"AIzbm30YDeHWml_-sxq6scGlGCKvnFkmGjdsXJ9sznnIC1LJwosXjbdQwoD_ccnkdqKiiN-5UEdkOLFet7Wlo7l-\",\n    \"y\": \"AWCzwFV2mPWX2zZg3tHtiTMuJXFhKnqhTOHOYpsD_nFXFDXkNTrwD2nZU6-aSh9CCKj1v7LyVRtPM2o39nKwXHWZ\"\n  },\n  \"kid\": \"7icoqReWFlpF16dzZD3rBgK1cJ265WzfF9sJJXqOe0M\",\n  \"skid\": \"bq3OI5517dSIMeD9K3lTqvkvvkmsRtifD6tvjlrKYsU\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#224-x25519-key","title":"2.2.4 X25519 key","text":"<ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"g3Lpdd_DRgjK28qi0sR0-hI-zv7a1X52vpzKc6ZM1Qs\",\n  \"d\": \"cPU_Io7RRHNb_xkQ_D6u3ER4vSjvsILDCKwOj8kVHXQ\"\n}\n</code></pre></li> <li>Sender kid (jwk thumbprint raw base64 URL encoded): <code>j8E-tcw1Z_eOCoKEH-7a9T532r8zXfcavbPZlofN0Ek</code></li> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"VlhpUXj-oGs9ge-VLrmYF7Xuzy73YchIfckaYcQefBw\",\n  \"d\": \"QFHCCy0wzgJ_AlGMnjetTd0tnDaZ_7yqJODSV0d-kkg\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>_DHSbVaMeZxriDJn5VoHXYXo6BJacwZx_fGIBfCiJ5c</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILTFQVStYQzIwUEtXIiwiYXB1IjoiYWpoRkxYUmpkekZhWDJWUFEyOUxSVWd0TjJFNVZEVXpNbkk0ZWxobVkyRjJZbEJhYkc5bVRqQkZhdyIsImFwdiI6IlgwUklVMkpXWVUxbFduaHlhVVJLYmpWV2IwaFlXVmh2TmtKS1lXTjNXbmhmWmtkSlFtWkRhVW8xWXciLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJjcnYiOiJYMjU1MTkiLCJrdHkiOiJPS1AiLCJ4IjoiWmdZTkJwcDlRZkZMZFpBT05LaUYxWGdRTkZCdW4tdkx4V25TeTF3ZDRRdyJ9LCJraWQiOiJfREhTYlZhTWVaeHJpREpuNVZvSFhZWG82QkphY3daeF9mR0lCZkNpSjVjIiwic2tpZCI6Imo4RS10Y3cxWl9lT0NvS0VILTdhOVQ1MzJyOHpYZmNhdmJQWmxvZk4wRWsiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"encrypted_key\": \"6AxohV0ygxzRGGxqKIMovkJf7rCyE1ymbVzxqVEVpioySTzd4Ociy8yTa4uo-wlVCFaKVxitFgD3bgtuidOw5J8r-CXjR42D\",\n  \"iv\": \"AEv2DrMR4rMV8preS0zndED_u11QNnQx\",\n  \"ciphertext\": \"c_RTSoNM5hFpOr3lEFU\",\n  \"tag\": \"m9GKNsP05SKYS9qdTvnsfA\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILTFQVStYQzIwUEtXIiwiYXB1IjoiYWpoRkxYUmpkekZhWDJWUFEyOUxSVWd0TjJFNVZEVXpNbkk0ZWxobVkyRjJZbEJhYkc5bVRqQkZhdyIsImFwdiI6IlgwUklVMkpXWVUxbFduaHlhVVJLYmpWV2IwaFlXVmh2TmtKS1lXTjNXbmhmWmtkSlFtWkRhVW8xWXciLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJrdHkiOiJPS1AiLCJjcnYiOiJYMjU1MTkiLCJ4IjoiWmdZTkJwcDlRZkZMZFpBT05LaUYxWGdRTkZCdW4tdkx4V25TeTF3ZDRRdyJ9LCJraWQiOiJfREhTYlZhTWVaeHJpREpuNVZvSFhZWG82QkphY3daeF9mR0lCZkNpSjVjIiwic2tpZCI6Imo4RS10Y3cxWl9lT0NvS0VILTdhOVQ1MzJyOHpYZmNhdmJQWmxvZk4wRWsiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0.6AxohV0ygxzRGGxqKIMovkJf7rCyE1ymbVzxqVEVpioySTzd4Ociy8yTa4uo-wlVCFaKVxitFgD3bgtuidOw5J8r-CXjR42D.AEv2DrMR4rMV8preS0zndED_u11QNnQx.c_RTSoNM5hFpOr3lEFU.m9GKNsP05SKYS9qdTvnsfA</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-1PU+XC20PKW\",\n  \"apu\": \"ajhFLXRjdzFaX2VPQ29LRUgtN2E5VDUzMnI4elhmY2F2YlBabG9mTjBFaw\",\n  \"apv\": \"X0RIU2JWYU1lWnhyaURKbjVWb0hYWVhvNkJKYWN3WnhfZkdJQmZDaUo1Yw\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"XC20P\",\n  \"epk\": {\n    \"kty\": \"OKP\",\n    \"crv\": \"X25519\",\n    \"x\": \"ZgYNBpp9QfFLdZAONKiF1XgQNFBun-vLxWnSy1wd4Qw\"\n  },\n  \"kid\": \"_DHSbVaMeZxriDJn5VoHXYXo6BJacwZx_fGIBfCiJ5c\",\n  \"skid\": \"j8E-tcw1Z_eOCoKEH-7a9T532r8zXfcavbPZlofN0Ek\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0335-http-over-didcomm/","title":"0335: HTTP Over DIDComm","text":"<ul> <li>Authors: Filip Burlacu (SecureKey)</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes:</li> <li>Start Date: 2019-11-26</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0335-http-over-didcomm/#summary","title":"Summary","text":"<p>Allows HTTP traffic to be routed over a DIDComm channel, so applications built to communicate over HTTP can make use of DID-based communication.</p>"},{"location":"features/0335-http-over-didcomm/#motivation","title":"Motivation","text":"<p>This protocol allows a client-server system that doesn't use DIDs or DIDComm to piggyback on top of a DID-based infrastructure, gaining the benefits of DIDs by using agents as HTTP proxies.</p> <p>Example use case:  Carl wants to apply for a car loan from his friendly neighborhood used car dealer. The dealer wants a proof of his financial stability from his bank, but he doesn't want to expose the identity of his bank, and his bank doesn't want to develop a custom in-house system (using DIDs) for anonymity. HTTP over DIDComm allows Carl to introduce his car dealer to his bank, using Aries agents and protocols, while all they need to do is install a standard agent to carry arbitrary HTTP messages.</p> <p>HTTP over DIDComm turns a dev + ops problem, of redesigning and deploying your server and client to use DID communication, into an ops problem - deploying Aries infrastructure in front of your server and to your clients.</p> <p>Using HTTP over DIDComm as opposed to HTTPS between a client and server offers some key benefits: - The client and server can use methods provided by Aries agents to verify their trust in the other party - for example, by presenting verifiable credential proofs. In particular, this allows decentralized client verification and trust, as opposed to client certs. - The client and server can be blind to each others' identities (for example, using fresh peer DIDs and communicating through a router), even while using their agents to ensure trust.</p>"},{"location":"features/0335-http-over-didcomm/#tutorial","title":"Tutorial","text":""},{"location":"features/0335-http-over-didcomm/#name-and-version","title":"Name and Version","text":"<p>This is the HTTP over DIDComm protocol. It is uniquely identified by the URI:</p> <pre><code>\"https://didcomm.org/http-over-didcomm/1.0\"\n</code></pre>"},{"location":"features/0335-http-over-didcomm/#concepts","title":"Concepts","text":"<p>This RFC assumes that you are familiar with DID communication, and the <code>~purpose</code> decorator.</p> <p>This protocol introduces a new message type which carries an HTTP message, and a method by which an Aries agent can serve as an HTTP proxy. The Aries agent determines the target agent to route the HTTP message through (for example, by parsing the HTTP message's request target), and when the target agent receives the message, it serves the message over HTTP.</p> <p>The specifics of determining the target agent or route are not part of this specification, allowing room for a wide array of uses: -  A network of enterprise servers behind agents, with the agents being a known, managed pool, with message routing controlled by business logic. - A privacy mix network, with in-browser agents making requests, and routing agents sending messages on random walks through the network until an agent serves the request over the public internet. - A network of service providers behind a routing network, accessed by clients, with any provider able to handle the same class of requests, so routing is based on efficiency/load. - A network of service providers behind a routing network, accessed by clients, where the routing network hides the identity of the service provider and client from each other.</p>"},{"location":"features/0335-http-over-didcomm/#protocol-flow","title":"Protocol Flow","text":"<p>This protocol takes an HTTP request-response loop and stretches it out across DIDComm, with agents in the middle serving as DIDComm relays, passing along messages.</p> <p>The entities involved in this protocol are as follows: - The client and server: the HTTP client and server, which could communicate via HTTP, but in this protocol communicate over DIDComm. - The client agent: the aries agent which receives the HTTP request from the client, and converts it to a DIDComm message, which it sends to the server agent, and translates the reply from the server agent into an HTTP response. - The server agent: the aries agent which receives the DIDComm request message from the client agent, creates an HTTP request for the server, receives the HTTP response, and translates it into a DIDComm message which it sends to the client agent.</p> <p></p> <p>Before a message can be sent, the server must register with its agent using the <code>~purpose</code> decorator, registering on one or more purpose tags.</p> <p>When a client sends an HTTP request to a client agent, the agent may need to maintain an open connection, or store a record of the client's identity/IP address, so the client can receive the coming response.</p> <p>The client agent can include some logic to decide whether to send the message, and may need to include some logic to decide where to route the message (note that in some architectures, another agent along the route makes the decision, so the agent might always send to the same target). If it does, it constructs a request DIDComm message (defined below) and sends it to the chosen server agent.</p> <p>The route taken by the DIDComm message between the client and server agents is not covered by this RFC.</p> <p>The server agent receives the request DIDComm message. It can include some logic to decide whether to permit the message to continue to the server. If so, it makes an HTTP request using the data in the request DIDComm message, and sends it to the server.</p> <p>Note: in some use-cases, it might make sense for the server agent to act as a transparent proxy, so the server thinks its talking directly to the client, while in others it might make sense to override client identity information so the server thinks it's connecting to the server agent, for example, as a gateway. In this case, the client agent could anonymize the request, rather than leaving it up to the server agent.</p> <p>This same anonymization can be done in the other direction as well.</p> <p>The communication happens in reverse when the server sends an HTTP response to its agent, which may again decide whether to permit it to continue. If so, the contents of the HTTP response are encoded into a response DIDComm message (defined below), sent to the client agent, which also makes a go/no-go decision, does some logic (for example, looking up its thread-id to client database) to figure out where the original request in this thread came from, encodes the response data into an HTTP response, and sends that response to the client.</p>"},{"location":"features/0335-http-over-didcomm/#message-format","title":"Message Format","text":"<p>DIDComm messages for this protocol look as follows:</p>"},{"location":"features/0335-http-over-didcomm/#request","title":"<code>request</code>","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/http-over-didcomm/1.0/request\",\n  \"@id\": \"2a0ec6db-471d-42ed-84ee-f9544db9da4b\",\n  \"~purpose\": [],\n  \"method\": &lt;method&gt;,\n  \"resource-uri\": &lt;resource uri value&gt;,\n  \"version\": &lt;version&gt;,\n  \"headers\": [],\n  \"body\": b64enc(body)\n}\n</code></pre> <p>The <code>body</code> field is optional.</p> <p>The <code>resource-uri</code> field is also optional - if omitted, the server agent needs to set the uri based on the server that is being sent the message.</p> <p>Each element of the <code>headers</code> array is an object with two elements: <code>{\"name\": \"&lt;header-name&gt;\", \"value\": \"&lt;header-value&gt;\"}</code>.</p>"},{"location":"features/0335-http-over-didcomm/#response","title":"<code>response</code>","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/http-over-didcomm/1.0/response\",\n  \"@id\": \"63d6f6cf-b723-4eaf-874b-ae13f3e3e5c5\",\n  \"~thread\": {\n    \"thid\": \"2a0ec6db-471d-42ed-84ee-f9544db9da4b\",\n    \"sender_order\": 1\n  },\n  \"status\": {\n      \"code\":\"\",\n      \"string\":\"\"\n  },\n  \"version\": &lt;version&gt;,\n  \"headers\": [],\n  \"body\": b64enc(body)\n}\n</code></pre> <p>Responses need to indicate their target - the client who sent the request. Response DIDComm messages must include a <code>~thread</code> decorator so the client agent can correlate thread IDs with its stored HTTP connections.</p> <p>The <code>body</code> field is optional.</p> <p>Each element of the <code>headers</code> array is an object with two elements: <code>{\"name\": \"&lt;header-name&gt;\", \"value\": \"&lt;header-value&gt;\"}</code>.</p>"},{"location":"features/0335-http-over-didcomm/#receiving-http-messages-over-didcomm","title":"Receiving HTTP Messages Over DIDComm","text":"<p>Aries agents intended to receive HTTP-over-DIDComm messages have many options for how they handle them, with configuration dependent on intended use. For example: - Serve the message over the internet, configured to use a DNS, etc. - Send the message to a specific server, set in configuration, for an enterprise system where a single server is behind an agent. - Send the message to a server which registered for the message's purpose.</p> <p>In cases where a specific server or application is always the target of certain messages, the server/application should register with the server agent on the specific purpose decorator. In cases where the agent may need to invoke additional logic, the agent itself can register a custom handler.</p> <p>An agent may implement filtering to accept or reject requests based on any combination of the purpose, sender, and request contents.</p>"},{"location":"features/0335-http-over-didcomm/#purpose-value","title":"Purpose Value","text":"<p>The purpose values used in the message should be values whose meanings are agreed upon by the client and server. For example, the purpose value can:  - indicate the required capabilities of the server that handles a request  - contain an anonymous identifier for the server, which has previously been communicated to the client.</p> <p>For example, to support the use of DIDComm as a client-anonymizing proxy, agents could use a purpose value like \"web-proxy\" to indicate that the HTTP request  (received by the server agent) should be made on the web.</p>"},{"location":"features/0335-http-over-didcomm/#reference","title":"Reference","text":""},{"location":"features/0335-http-over-didcomm/#determining-the-recipient-did-by-the-resource-uri","title":"Determining the recipient DID by the Resource URI","text":"<p>In an instance of the HTTP over DIDComm protocol, it is assumed that the client agent has the necessary information to be able to determine the DID of the server agent based on the resource-uri provided in the request. It's reasonable to implement a configuration API to allow a sender or administrator to specify the DID to be used for a particular URI.</p>"},{"location":"features/0335-http-over-didcomm/#-alive-timeout","title":"-Alive &amp; Timeout","text":"<p>The client agent should respect the timeout parameter provided in a keep-alive header if the request header is a keep-alive connection.</p> <p>If a client making an HTTP request expects a response over the same HTTP connection, its agent should keep this connection alive while it awaits a DIDComm response from the server agent, which it should recognize by the <code>~thread</code> decorator in the response message. Timing information can be provided in an optional <code>~timing</code> decorator. </p> <p>Agents implementing this RFC can make use of the <code>~transport</code> decorator to enable response along the same transport.</p>"},{"location":"features/0335-http-over-didcomm/#when-the-client-agent-is-the-server-agent","title":"When the Client Agent is the Server Agent","text":"<p>There is a degenerate case of this protocol where the client and server agents are the same agent. In this case, instead of constructing DIDComm messages, sending them to yourself, and then unpacking them, it would be reasonable to take incoming HTTP messages, apply any pre-send logic (filtering, etc), apply any post-receive logic, and then send them out over HTTP, as a simple proxy.</p> <p>To support this optimization/simplification, the client agent should recognize if the recipient DID is its own, after determining the DID from the resource URI.</p>"},{"location":"features/0335-http-over-didcomm/#http-error-codes","title":"HTTP Error Codes","text":"<p>Failures within the DIDComm protocol can inform the status code returned to the client. </p> <p>If the client agent waits for the time specified in the request keep-alive timeout field, it should respond with a standard 504 gateway timeout status.</p> <p>Error codes which are returned by the server will be transported over DIDComm as normal.</p>"},{"location":"features/0335-http-over-didcomm/#why-http1x","title":"Why HTTP/1.x?","text":"<p>The DIDComm messages in this protocol wrap HTTP/1(.x) messages for a few reasons:  - Wire-level benefits of HTTP/2 are lost by wrapping in DIDComm and sending over another transport (which could itself be HTTP/2)  - DIDComm is not, generally, intended to be a streaming or latency-critical transport layer, so HTTP responses, for example, can be sent complete, including their bodies, instead of being split into frames which are sent over DIDComm separately.</p> <p>The agents are free to support communicating with the client/server using HTTP/2 - the agents simply wait until they've received a complete request or response, before sending it onwards over DIDComm.</p>"},{"location":"features/0335-http-over-didcomm/#https","title":"HTTPS","text":"<p>The client and server can use HTTPS to communicate with their agents - this protocol only specifies that the messages sent over DIDComm are HTTP, not HTTPS.</p>"},{"location":"features/0335-http-over-didcomm/#partial-use-of-http-over-didcomm","title":"Partial use of HTTP over DIDComm","text":"<p>This protocol specifies the behaviour of clients, servers, and their agents. However, the client-side and server-side are decoupled by design, meaning a custom server or client, which obeys all the semantics in this RFC while diverging on technical details, can interoperate with other compliant applications.</p> <p>For example, a client-side agent can construct <code>request</code> messages based on internal logic rather than a request from an external application. On the server side, an agent can handle requests and send responses directly by registering its own listener on a purpose value, rather than having a separate application register.</p>"},{"location":"features/0335-http-over-didcomm/#drawbacks","title":"Drawbacks","text":"<p>You might find the cost too high, with wrapping your messages into HTTP messages, and then wrapping those into DIDComm envelopes. This cost includes the time it takes to wrap and unwrap payloads, as well as the increase in message size. Small messages and simple formats would benefit from being encoded as JSON payloads within custom DIDComm message formats, instead of being wrapped in HTTP messages within DIDComm messages. Large data might benefit from being sent over another channel, encrypted, with identification, decryption, and authentication information sent over DIDComm.</p>"},{"location":"features/0335-http-over-didcomm/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>The main alternative to the method proposed in this RFC is to implement DIDComm in your non-DIDComm applications, if you want them to be able to communicate with each other over DIDComm.</p> <p>Another alternative to sending HTTP messages over DIDComm is sending HTTPS over DIDComm, by establishing a TLS connection between the client and server over the DIDComm transport. This offers some tradeoffs and drawbacks which make it an edge case - it identifies the server with a certificate, it breaks the anonymity offered by DIDComm, and it is not necessary for security since DIDComm itself is securely encrypted and authenticated, and DIDComm messages can be transported over HTTPS as well.</p>"},{"location":"features/0335-http-over-didcomm/#prior-art","title":"Prior art","text":"<p>VPNs and onion routing (like Tor) provide solutions for similar use cases, but none so far use DIDs, which enable more complex use cases with privacy preservation.</p> <p>TLS/HTTPS, being HTTP over TLS, provides a similar transport-layer secure channel to HTTP over DIDComm. Note, this is why this RFC doesn't specify a means to perform HTTPS over DIDComm - DIDComm serves the same role as TLS does in HTTPS, but offers additional benefits: - Verifiable yet anonymous authentication of the client, for example, using delegated credentials. - Access to DIDComm mechanisms, such as using the introduce protocol to connect the client and server.</p>"},{"location":"features/0335-http-over-didcomm/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>Likely some specifics of go/no-go or routing logic</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>The routing and logic specifics of certain use cases</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"features/0335-http-over-didcomm/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0347-proof-negotiation/","title":"Aries RFC 0347: Proof Negotiation","text":"<ul> <li>Authors: Philipp Rieblinger, Sebastian Weidenbach</li> <li>Status: PROPOSED</li> <li>Since: 2019-12-13</li> <li>Status Note: Initial proposal after discussion on rocketchat</li> <li>Supersedes: </li> <li>Start Date: 2019-09-09</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0347-proof-negotiation/#summary","title":"Summary","text":"<p>This RFC proposes an extension to Aries RFC 0037: Present Proof Protocol 1.0 by taking the concept of groups out of the DID credential manifest and including them in the present proof protocol. Additionally to the rules described in the credential manifest, an option to provide alternative attributes with a weight is being introduced here. Also, the possibility to include not only attributes, but also credentials and openids in a proof by using a \"type\" was taken from the DID credential manifest.  The goal of this is an approach to make proof presentation more flexible, allowing attributes to be required or optional as well as allowing a choose-from-a-list scenario.  So far, proof requests were to be replied to with a proof response that contained all attributes listed in the proof request. To this, this RFC adds a way to mark attributes as optional, so that they are communicated as nice-to-have to the user of a wallet.</p>"},{"location":"features/0347-proof-negotiation/#motivation","title":"Motivation","text":"<p>We see a need in corporate identity and access management for a login process handling not only user authentication against an application, but also determining which privileges the user is being granted inside the application and which data the user must or may provide. Aries can provide this by combining a proof request with proof negotiation.</p>"},{"location":"features/0347-proof-negotiation/#use-case-example","title":"Use Case Example","text":"<p>A bank needs a customer to prove they are credit-worthy using Aries-based Self-Sovereign Identity. For this, the bank wants to make the proof of credit-worthyness flexible, in that an identity owner can offer different sets and combinations of credentials. For instance, this can be a choice between a certificate of credit-worthiness from another trusted bank or alternatively a set of credentials proving ownership over real estate and a large fortune in a bank account, for example. Optionally, an Identity Owner can add certain credentials to the proof to further prove worthiness in order to be able to obtain larger loans.</p>"},{"location":"features/0347-proof-negotiation/#tutorial","title":"Tutorial","text":"<p>A proof request sent to an identity owner defines the attributes to be included in the proof response, i.e. the ones to prove. To add a degree of flexibility to the process, it is possible to request attributes as necessary (meaning they have to be included in the response for it to be valid) or to allow the identity owner to pick one of or several of multiple attributes from a list. Furthermore, attributes can be marked as optional. For users, this procedure may look like the example of a privacy-friendly access permission process shown in the manifesto of Okuna, an open-source social network that is still in development at the time of this writing (click on \"continue with Okuna\" to see said example). Backend-wise, this may be implemented as follows:</p>"},{"location":"features/0347-proof-negotiation/#proof-request-with-attribute-negotiation","title":"Proof Request with attribute negotiation","text":"<p>This feature can be implemented building on top of the credential manifest developed by the Decentralized Identity Foundation. One feature the above concept by the Decentralized Identity Foundation lacks is a way of assigning a weight to attributes within the category \"one of\". It is possible that future implementations using this concept will want to prefer certain attributes over others in the same group if both are given, so a way of assigning these different priorities to attributes should be possible. Below is an the above example of a proof request to which a rule \"pick_weighted\" and a group D were added. Furthermore, the categories \"groups_required\" and \"groups_optional\" were added to be able to differentiate between required and optional attributes which the credential manifest did not.</p> <p>Example of a proof presentation request (from verifier):</p> <p><pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/request-presentation\",\n    \"@id\": \"98fd8d82-81a6-4409-acc2-c35ea39d0f28\",\n    \"comment\": \"some comment\",\n    \"request_presentations~attach\": [\n        {\n            \"@id\": \"libindy-request-presentation-0\",\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;yaml-formatted string describing attachments, base64url-encoded because of libindy&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> The base64url-encoded content above decodes to the following data structure, a presentation preview: <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/presentation-preview\",\n    \"@context\": \"https://path.to/schemas/credentials\",\n    \"comment\":\"some comment\",\n    \"~thread\": {\n        \"thid\": \"98fd8d82-81a6-4409-acc2-c35ea39d0f28\",\n        \"sender_order\": 0\n    }\n    \"credential\":\"proof_request\", // verifiable claims elements\n    \"groups_required\": [ // these groups are the key feature to this RFC\n            {\n                \"rule\":\"all\",\n                \"from\": [\"A\", \"B\"]\n            },\n            {\n                \"rule\": \"pick\",\n                \"count\": 1,\n                \"from\": [\"C\"]\n            },\n            {\n                \"rule\": \"pick_weighted\",\n                \"count\": 1,\n                \"from\": [\"D\"]\n            }\n        ],\n        \"groups_optional\": [\n            {\n                \"rule\": \"all\",\n                \"from\": [\"D\"]\n            }\n        ],\n    \"inputs\": [\n        {\n            \"type\": \"data\",\n            \"name\": \"routing_number\",\n            \"group\": [\"A\"],\n            \"cred_def_id\": \"&lt;cred_def_id&gt;\",\n            // \"mime-type\": \"&lt;mime-type&gt;\" is missing, so this defaults to a json-formatted string; if it was non-null, 'value' would be interpreted as a base64url-encoded string representing a binary BLOB with mime-type telling how to interpret it after base64url-decoding\n            \"value\": {\n                \"type\": \"string\",\n                \"maxLength\": 9\n            },\n        },\n        {\n            \"type\": \"data\",\n            \"name\": \"account_number\",\n            \"group\": [\"A\"], \n            \"cred_def_id\": \"&lt;cred_def_id&gt;\",\n            \"value\": {\n                \"type\": \"string\",\n                \"value\": \"12345678\"\n        },\n        {\n            \"type\": \"data\",\n            \"name\": \"current_residence_duration\",\n            \"group\": [\"A\"],\n            \"cred_def_id\": \"&lt;cred_def_id&gt;\",\n            \"value\": {\n                \"type\": \"number\",\n                \"maximum\": 150\n            }\n        },\n        {\n            \"type\": \"credential\",\n            \"group\": [\"C\"],\n            \"schema\": \"https://eu.com/claims/IDCard\",\n            \"constraints\": {\n                \"subset\": [\"prop1\", \"prop2.foo.bar\"],\n                \"issuers\": [\"did:foo:gov1\", \"did:bar:gov2\"]\n            }\n        },\n        {\n            \"type\": \"credential\",\n            \"group\": [\"C\"],\n            \"schema\": \"hub://did:foo:123/Collections/schema.us.gov/Passport\",\n            \"constraints\": {\n                \"issuers\": [\"did:foo:gov1\", \"did:bar:gov2\"]\n            }\n\n        },\n        {\n            \"type\": \"credential\",\n            \"group\": [\"B\"],\n            \"schema\": [\"https://claims.linkedin.com/WorkHistory\", \"https://about.me/WorkHistory\"],\n            \"constraints\": {\n                \"issuers\": [\"did:foo:auditor1\", \"did:bar:auditor2\"]\n            }\n        },\n        {\n            \"type\": \"credential\",\n            \"group\": [\"B\"],\n            \"schema\": \"https://claims.fico.org/CreditHistory\",\n            \"constraints\": {\n                \"issuers\": [\"did:foo:bank1\", \"did:bar:bank2\"]\n            }\n        },\n        {\n            \"type\": \"openid\",\n            \"group\": [\"A\"],\n            \"redirect\": \"https://login.microsoftonline.com/oauth/\"\n            \"parameters\": {\n                \"client_id\": \"dhfiuhsdre\",\n                \"scope\": \"openid+profile\"                    \n            }\n        },\n        {\n            \"type\": \"credential\",\n            \"group\": [\"D\"],\n            \"schema\": \"https://some.login.com/someattribute\",\n            \"constraints\": {\n                \"issuers\": [\"did:foo:iss1\", \"did:foo:iss2\"]\n            },\n            \"weight\": 0.8\n        },\n        {\n            \"type\": \"credential\",\n            \"group\": [\"D\"],\n            \"schema\": \"https://some.otherlogin.com/someotherattribute\",\n            \"constraints\": {\n                \"issuers\": [\"did:foox:iss1\", \"did:foox:iss2\"]\n            },\n            \"weight\": 0.2\n        }\n    ],\n    \"predicates\": [\n        {\n            \"name\": \"&lt;attribute_name&gt;\",\n            \"cred_def_id\": \"&lt;cred_def_id&gt;\",\n            \"predicate\": \"&lt;predicate&gt;\",\n            \"threshold\": &lt;threshold&gt;\n        }\n    ]\n}\n</code></pre></p>"},{"location":"features/0347-proof-negotiation/#valid-proof-response-with-attribute-negotiation","title":"Valid Proof Response with attribute negotiation","text":"<p>The following data structure is an example for a valid answer to the above credential request. It contains all attributes from groups A and B as well as one credential from each C and D. Note that the provided credential from Group D is the one weighted 0.2 as the owner did not have or was not willing to provide the one weighted 0.8.</p> <p>Valid proof presentation: <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/proof-presentation\",\n    \"@id\": \"98fd8d82-81a6-4409-acc2-c35ea39d0f28\",\n    \"comment\": \"some comment\",\n    \"presentations~attach\": [\n        {\n            \"@id\": \"libindy-presentation-0\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;yaml-formatted string describing attachments, base64url-encoded because of libindy&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> The base64url-encoded content above would decode to this data: <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/presentation-preview\",\n    \"@context\": \"https://path.to/schemas/credentials\"\n    \"comment\":\"some comment\",\n    \"~thread\": {\n        \"thid\": \"98f38d22-71b6-4449-adc2-c33ea39d1f29\",\n        \"sender_order\": 1,\n        \"received_orders\": {did:sov:abcxyz\":1}\n    }\n    \"credential\":\"proof_response\", // verifiable claims elements\n    \"inputs_provided\": [\n        {\n            \"type\": \"data\",\n            \"field\": \"routing_number\",\n            \"value\": \"123456\"\n        },\n        {\n            \"type\": \"data\",\n            \"field\": \"account_number\",\n            \"value\": \"12345678\"\n        },\n        {\n            \"type\": \"data\",\n            \"field\": \"current_residence_duration\",\n            \"value\": 8\n        },      \n        {\n            \"type\": \"credential\",\n            \"schema\": [\"https://claims.linkedin.com/WorkHistory\", \"https://about.me/WorkHistory\"],\n            \"issuer\": \"did:foo:auditor1\"\n        },\n        {\n            \"type\": \"credential\",\n            \"schema\": \"https://claims.fico.org/CreditHistory\",\n            \"issuer\": \"did:foo:bank1\"\n        },\n        {\n            \"type\": \"openid\",\n            \"redirect\": \"https://login.microsoftonline.com/oauth/\"\n            \"client_id\": \"dhfiuhsdre\",\n            \"profile\": \"...\"\n        },\n        {\n            \"type\": \"credential\",\n            \"schema\": \"https://eu.com/claims/IDCard\"\n            \"issuer\": \"did:foo:gov1\"\n        },\n        {\n        \"type\": \"credential\",\n            \"group\": [\"D\"],\n            \"schema\": \"https://some.otherlogin.com/someotherattribute\",\n            \"issuer\": \"did:foox:iss1\"\n        }\n    ],\n    \"predicates\": [ // empty in this case\n    ]\n}\n</code></pre></p>"},{"location":"features/0347-proof-negotiation/#reference","title":"Reference","text":"<p>The \"@id\"-Tag and thread decorator in the above JSON-messages is taken from RFC 0008.</p>"},{"location":"features/0347-proof-negotiation/#drawbacks","title":"Drawbacks","text":"<p>If a user needs to choose from a list of credentials each time a proof request with a \"pick_one\"-rule is being requested, some users may dislike this, as this process requires a significant amount of user interaction and, thereby, time. This could be mitigated by an 'optional'-rule which requests all of the options the 'pick one'-rule offers. Wallets can then offer two pre-settings: \"privacy first\", which offers as little data and as many interactions with the user as possible, while \"usability first\" automatically selects the 'optional'-rule and sends more data, not asking the user before everytime. The example dialog from the Okuna manifesto referred to before shows a great way to implement this. It offers the user the most privacy-friendly option by default (which is what the GDPR requires) or the prividing of optional data. Futhermore, the optional data can be customized to include or exclude specific data.</p>"},{"location":"features/0347-proof-negotiation/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Not implementing proof negotiation would mean that Aries-based Distributed Ledgers would be limited to a binary yes-or-no approach to authentication and authorization of a user, while this proof negotiation would add flexibility. An alternative way of implementing the proof negotiation is performing it ahead of the proof request in a seperate request and response. The problem with not implementing this feature would be that a proof request may need to be repeated over and over again with a different list of requested attributes each time, until a list is transferred which the specific user can reply to. This process would be unnecessarily complicated and can be facilitated by implementing this here concept.</p>"},{"location":"features/0347-proof-negotiation/#prior-art","title":"Prior art","text":"<p>RFC0037-present-proof is the foundation which this RFC builds on using groups from the credential manifest by  the decentralized identity foundation, a \"format that normalizes the definition of requirements for the issuance of a credential\".</p>"},{"location":"features/0347-proof-negotiation/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>The above proof request includes a schema ID for every credential requests. This was taken from the DID credential manifest. It may make more sense to include a credential definition ID there, as a credential could potentially be built from one credential definition but this credential definition from several schemas.</li> <li>The exact layout and syntax of the proof request above is open to debate, it was designed to stick as close as possible to existing RFCs and ../../concepts.</li> <li>Can this feature be implemented in a way that does not break proof requests from anoncreds version 1.x?</li> <li>Writing this RFC rose the question if the length of a proof request is limited in any way. A JSON-message containing the attributes in the proof can theoretically be infinitely long. Is this being handled in any way? It may lead to overflows at some point.</li> <li>This RFC describes the negotiation of a proof inside the proof request itself. Depending on the functionality around proofs it may be more desirable to implement the proof negotiation as a seperate protocol which is used before the actual proof request.</li> <li>It might be possible to accomplish the goal of this RFC by extending the present-preview message and adding prover functionality that allows the prover to select credentials they have to satisfy the request, just as is done in the proof request/proof process, but with the specific goal of only sending back a proposal, not a proof </li> </ul>"},{"location":"features/0347-proof-negotiation/#implementations","title":"Implementations","text":"Name / Link Implementation Notes"},{"location":"features/0348-transition-msg-type-to-https/","title":"Aries RFC 0348: Transition Message Type to HTTPs","text":"<ul> <li>Authors: Stephen Curran</li> <li>Status: RETIRED</li> <li>Since: 2020-08-26</li> <li>Status Note: In step 2 - community is updating implementations to send new formats. Target Completion Date: 2020.10.15 </li> <li>Supersedes:</li> <li>Start Date: 2019-12-13</li> <li>Tags: feature, community-update</li> </ul>"},{"location":"features/0348-transition-msg-type-to-https/#summary","title":"Summary","text":"<p>Per issue #225, the Aries community has agreed to change the prefix for protocol message types that currently use <code>did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/</code> to use <code>https://didcomm.org/</code>. Examples of the two message types forms are:</p> <ul> <li>Before: <code>did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/notification/1.0/ack</code></li> <li>After: <code>https://didcomm.org/notification/1.0/ack</code></li> </ul> <p>This RFC follows the guidance in RFC 0345 about community-coordinated updates to (try to) ensure that independently deployed, interoperable agents remain interoperable throughout this transition.</p> <p>The transition from the old to new formats will occur in four steps:</p> <ul> <li>DONE Pre-work: where we agree on the transition plan outlined in this RFC.</li> <li>Any RFC updates related to this transition needed before starting the transition are completed.</li> <li> <p>To Do: Identify if there any prerequisite RFC changes to be made.</p> </li> <li>DONE Step 1: Agent builders MUST update all agent code bases and deployments to accept incoming message types in the old (did) and new (https) formats. During this step, agents MUST default to sending out messages in the old format.</li> <li>Each agent builder SHOULD notify the community they have completed Step 1 by submitting a PR to update their entry in the implementations accordingly.</li> <li>IN PROGRESS Step 2: Agent builders MUST update all agent code bases and deployments to send out all messages using the new (https) format. The old (did) format is deprecated but will still be accepted. An agent deployment MAY send out an old format message type upon receipt of a message containing an old format message type.</li> <li>Each agent builder SHOULD notify the community they have completed Step 2 by submitting a PR to update their entry in the implementations accordingly.</li> <li>Step 3: Agent builders SHOULD update their deployments to remove all support for receiving the old format and MUST NOT send out messages using the old message type format.</li> </ul> <p>Note: Any RFCs that already use the new \"https\" message type should continue to use the use new format in all cases\u2014accepting and sending. New protocols defined in new and updated RFCs should use the new \"https\" format.</p> <p>The community coordination triggers between the steps above will be as follows:</p> <ul> <li>Pre-work to Step 1 - a PR to this RFC is merged that sets the RFC status to ACCEPTED.</li> <li>The ACCEPTED version of this RFC is included in the current Aries Interop Profile version.</li> <li>Step 1 to Step 2 - the community agrees that the majority of the deployed agents have completed Step 1. A PR to this RFC is merged that sets the RFC status to ADOPTED.</li> <li>Agent builders indicate completion of Step 1 by updating the Implementations section of this RFC.</li> <li>All other RFCs in this repo are updated to use the new message type format.</li> <li>The ADOPTED version of this RFC is included in the current Aries Interop Profile version.</li> <li>Step 2 to Step 3 - the community agrees that the majority of the deployed agents have completed Step 2. A PR to this RFC is merged that sets the RFC status to RETIRED.</li> <li>Agent builders indicate completion of Step 2 by updating the Implementations section of this RFC.</li> </ul>"},{"location":"features/0348-transition-msg-type-to-https/#motivation","title":"Motivation","text":"<p>To enable agent builders to independently update their code bases and deployed agents while maintaining interoperability.</p>"},{"location":"features/0348-transition-msg-type-to-https/#tutorial","title":"Tutorial","text":"<p>The general mechanism for this type of transition is documented in RFC 0345 about community-coordinated updates.</p> <p>The specific sequence of events to make this particular transition is outlined in the summary section of this RFC.</p>"},{"location":"features/0348-transition-msg-type-to-https/#reference","title":"Reference","text":"<p>See the summary section of this RFC for the details of this transition.</p>"},{"location":"features/0348-transition-msg-type-to-https/#drawbacks","title":"Drawbacks","text":"<p>None identified.</p>"},{"location":"features/0348-transition-msg-type-to-https/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>This approach balances the speed of adoption with the need for independent deployment and interoperability.</p>"},{"location":"features/0348-transition-msg-type-to-https/#prior-art","title":"Prior art","text":"<p>The approach outlined in RFC 0345 about community-coordinated updates is a well-known pattern for using deprecation to make breaking changes in an ecosystem. That said, this is the first attempt to use this approach in Aries. Adjustments to the transition plan will be made as needed, and RFC 0345 will be updated based on lessons learned in executing this plan.</p>"},{"location":"features/0348-transition-msg-type-to-https/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Are any changes to existing RFCs needed before starting Step 1?</li> </ul>"},{"location":"features/0348-transition-msg-type-to-https/#implementations","title":"Implementations","text":"<p>The following table lists the status of various agent code bases and deployments with respect to the steps of this transition. Agent builders MUST update this table as they complete steps of the transition.</p> Name / Link Implementation Notes Aries Protocol Test Suite No steps completed Aries Toolbox Completed Step 1 code change. Aries Framework - .NET Completed Step 1 code change Trinsic.id No steps completed Aries Cloud Agent - Python Completed Step 1 code change Aries Static Agent - Python No steps completed Aries Framework - Go Completed Step 2 Connect.Me No steps completed Verity No steps completed Pico Labs Completed Step 2 even though deprecated IBM Completed Step 1 code change IBM Agent Completed Step 1 Aries Cloud Agent - Pico Completed Step 2 code change Aries Framework JavaScript Completed Step 2 code change"},{"location":"features/0351-purpose-decorator/","title":"Aries RFC 0351: Purpose Decorator","text":"<ul> <li>Authors: Filip Burlacu</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes:</li> <li>Start Date: 2019-12-05</li> <li>Tags: feature, decorator</li> </ul>"},{"location":"features/0351-purpose-decorator/#summary","title":"Summary","text":"<p>This RFC allows Aries agents to serve as mediators or relays for applications that don't use DIDComm. It introduces: - A new decorator, the <code>~purpose</code> decorator, which defines the intent, usage, or contents of a message - A means for a recipient, who is not DIDComm-enabled, to register with an agent for messages with a particular purpose - A means for a sender, who is not DIDComm-enabled, to send messages with a given purpose through its agent to a target agent - Guidance for creating a protocol which uses the <code>~purpose</code> decorator to relay messages over DIDComm for non-DIDComm applications</p>"},{"location":"features/0351-purpose-decorator/#motivation","title":"Motivation","text":"<p>This specification allows applications that aren't Aries agents to communicate JSON messages over DIDComm using Aries agents analogously to mediators. Any agent which implements this protocol can relay arbitrary new types of message for clients - without having to be updated and redeployed.</p> <p>The purpose decorator can be used to implement client interfaces for Aries agents. For example: - A client application built using an Aries framework can use the purpose decorator for client-level messaging and protocols - Multiple client applications can connect to an agent, for example to process different types of messages, or to log for auditing purposes - A server with a remote API can include an Aries agent using the purpose decorator to provide a remote API over DIDComm - Multiple client applications can use a single agent to perform transactions on the agent owner's identity</p>"},{"location":"features/0351-purpose-decorator/#tutorial","title":"Tutorial","text":"<p>This RFC assumes familiarity with mediators and relays, attachments, and message threading.</p>"},{"location":"features/0351-purpose-decorator/#the-purpose-decorator","title":"The <code>~purpose</code> Decorator","text":"<p>The <code>~purpose</code> decorator is a JSON array which describes the semantics of a message - the role it plays within a protocol implemented using this RFC, for example, or the meaning of the data contained within. The purpose is the mechanism for determining which recipient(s) should be sent a message.</p> <p>Example: <code>\"~purpose\": [\"team:01453\", \"delivery\", \"geotag\", \"cred\"]</code></p> <p>Each element of the purpose array is a string. An agent provides some means for recipients to register on a purpose, or class of purposes, by indicating the particular string values they are interested in.</p> <p>The particular registration semantics are TBD. Some possible formats include: - A tagging system, where if a recipient registers on a list <code>\"foo\", \"bar\"</code>, it will be forwarded messages with purposes <code>[\"foo\", \"quux\"]</code> and <code>[\"baz\", \"bar\"]</code> - A hierarchical system, where if a recipient registers on a list <code>\"foo\", \"bar\"</code>, it will receive any message with purpose <code>[\"foo\", \"bar\", ...]</code> but not <code>[\"foo\", \"baz\", ...]</code> or <code>[\"baz\", \"foo\", \"bar\", ...]</code> - A hierarchical system with wildcards: <code>\"*\", \"foo\"</code> might match any message with purpose <code>[..., \"foo\", ...]</code></p>"},{"location":"features/0351-purpose-decorator/#handling-multiple-listeners","title":"Handling Multiple Listeners","text":""},{"location":"features/0351-purpose-decorator/#priority","title":"Priority","text":"<p>When multiple applications register for overlapping purposes, the agent needs a means to determine which application should receive the message, or which should receive it first. When an application registers on a purpose, it should set an integer priority. When the agent receives a message, it compares the priority of all matching listeners, choosing the lowest number value.</p>"},{"location":"features/0351-purpose-decorator/#fall-through","title":"Fall-Through","text":"<p>In some cases, an application that received a message can allow other listeners to process after it. In these cases, when the application is handling the message, it can indicate to the agent that it can fall-through, in which case the agent will provide the message to the next listener.</p> <p>Optionally, agents can support an always-falls-through configuration, for applications which:  - Will always fall through on the messages they receive, and  - Can always safely process concurrently with subsequent applications handling the same message.</p> <p>This allows the agent to send the message to such listeners concurrently with the next highest-priority listener that does not always-fall-through.</p>"},{"location":"features/0351-purpose-decorator/#example-protocol","title":"Example Protocol","text":"<p>This is an example protocol which makes use of the <code>~purpose</code> decorator and other Aries ../../concepts to provide a message format that can carry arbitrary payloads for non-DIDComm edge applications.</p>"},{"location":"features/0351-purpose-decorator/#key-concepts","title":"Key Concepts","text":"<p>This RFC allows messages to be sent over DIDComm by applications that are not DIDComm-enabled, by using Aries agents as intermediaries. Both the sender and the recipient can be non-DIDComm applications.</p>"},{"location":"features/0351-purpose-decorator/#non-didcomm-sender","title":"Non-DIDComm Sender","text":"<p>If the sender of the message is not a DIDComm-enabled agent, then it must rely on an agent as a trusted intermediary. This agent is assumed to have configured settings for message timing, communication endpoints, etc. </p> <ol> <li>The sender constructs a JSON message, and provides this to its agent, alongside specifying the purpose, and likely some indication of the destination of the message.</li> <li>The agent determines the recipient agent - this could be by logic, for example, based on the purpose decorator, or a DID specified by the sender.</li> <li>The agent wraps the sender's message and purpose in a DIDComm message, and sends it to the recipient agent.</li> </ol>"},{"location":"features/0351-purpose-decorator/#non-didcomm-recipient","title":"Non-DIDComm Recipient","text":"<p>A non-DIDComm recipient relies on trusted agents to relay messages to it, and can register with any number of agents for any number of purposes.</p> <ol> <li>The recipient registers with a trusted agent on certain purpose values.</li> <li>The agent receives a DIDComm message, and sees it has a purpose decorator.</li> <li>The agent looks through its recipient registry for all recipients which registered on a matching purpose.</li> <li>The Agent reverses the wrapping done by the sender agent, and forwards the wrapped message to all matching registered recipients.</li> </ol>"},{"location":"features/0351-purpose-decorator/#message-format","title":"Message Format","text":"<p>A DIDComm message, for a protocol implemented using this RFC, requires:  - A means to wrap the payload message  - A <code>~purpose</code> decorator</p> <p>This example protocol wraps the message within the <code>data</code> field. </p> <pre><code>{\n  \"@id\": \"123456789\",\n  \"@type\": \"https://example.org/didcomm-message\",\n  \"~purpose\": [],\n  \"data\" : {}\n}\n</code></pre> <p>For example: <pre><code>{\n  \"@id\": \"123456789\",\n  \"@type\": \"https://example.org/didcomm-message\",\n  \"~purpose\": [\"metrics\", \"latency\"],\n  \"data\": {\"mean\": 346457, \"median\": 2344}\n}\n</code></pre></p>"},{"location":"features/0351-purpose-decorator/#reference","title":"Reference","text":"<p>This section provides guidance for implementing protocols using this decorator.</p>"},{"location":"features/0351-purpose-decorator/#threading-timing","title":"Threading &amp; Timing","text":"<p>If a protocol implemented using this RFC requires back and forth communication, use the <code>~thread</code> decorator and transport return routing. This allows the recipient's agent to relay replies from the recipient to the sender.</p> <p>For senders and recipients that aren't aries agents, their respective agent must maintain context to correlate the DIDComm message thread, and the message thread of the communication protocol with the non-DIDComm application.</p> <p>If a message is threaded, it can be useful to include a <code>~timing</code> decorator for timing information. The sender's agent can construct this decorator from timing parameters (eg, timeout) in the communication channel with the sender, or have preconfigured settings.</p>"},{"location":"features/0351-purpose-decorator/#communication-with-non-didcomm-edge-applications","title":"Communication with Non-DIDComm Edge Applications","text":"<p>An organization using agents to relay messages for non-DIDComm edge applications is expected to secure the connections between their relay agents and their non-DIDComm edge applications. For example, running the agent as a service in the same container. If it is necessary for the organization to have a separate endpoint or mediator agent, it is recommended to have a thin relay agent as close as possible to the edge application, so internal messages sent to the mediator are also secured by DIDComm.</p>"},{"location":"features/0351-purpose-decorator/#drawbacks","title":"Drawbacks","text":"<p>TODO</p>"},{"location":"features/0351-purpose-decorator/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Alternative: defining a standard protocol for wrapping messages sent or received by non-DIDComm applications. This was the original design, but we've moved away from it because it was an unnecessary layer of specification, since custom protocols can use their own <code>@type</code> strings to specify their message formats, instead of using a two-layer system of <code>@type</code> and <code>data-type</code>.</li> </ul>"},{"location":"features/0351-purpose-decorator/#prior-art","title":"Prior art","text":"<ul> <li>The DIF Identity Hub has a mechanism for sending objects with semantic descriptors to identities, whereas this RFC defines a method whereby agents can transact the sending and receiving of such objects on behalf of their non-aries edge apps.</li> <li>Compare against the basic-message protocol, which uses aries agents as relays for person-person (or machine-person) communication. In contrast, this protocol uses aries agents as relays for machine-machine communication.</li> <li>The purpose decorator (as opposed to type enforcement like MIME) is similar to Intents in Android development.</li> <li>The hierarchical example for the purpose decorator is similar to Topics in MQTT.</li> </ul>"},{"location":"features/0351-purpose-decorator/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>We need to define the semantics of the purpose decorator - the examples provided above are potential directions the standard can go.</li> <li>Are there further semantics to define in this RFC rather than leave for specific implementations?</li> </ul>"},{"location":"features/0351-purpose-decorator/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0360-use-did-key/","title":"Aries RFC 0360: did:key Usage","text":"<ul> <li>Authors: Tobias Looker, Stephen Curran</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Referenced in a number of Aries RFCs and formalized as part of AIP 2.0 did:key method is a W3C CCG work item</li> <li>Start Date: 2019-12-17</li> <li>Tags: feature</li> </ul>"},{"location":"features/0360-use-did-key/#summary","title":"Summary","text":"<p>A number of RFCs that have been defined reference what amounts to a \"naked\" public key, such that the sender relies on the receiver knowing what type the key is and how it can be used. The application of this RFC will result in the replacement of \"naked\" verkeys (public keys) in some DIDComm/Aries protocols with the did:key ledgerless DID method, a format that concisely conveys useful information about the use of the key, including the public key type. While <code>did:key</code> is less a DID method than a transformation from a public key and type to an opinionated DIDDoc, it provides a versioning mechanism for supporting new/different cryptographic formats and its use makes clear how a public key is intended to be used. The method also enables support for using standard DID resolution mechanisms that may simplify the use of the key. The use of a DID to represent a public key is seen as odd by some in the community. Should a representation be found that is has better properties than a plain public key but is constrained to being \"just a key\", then we will consider changing from the <code>did:key</code> representation.</p> <p>To Do: Update link DID Key Method link (above) from Digital Bazaar to W3C repositories when they are created and populated.</p> <p>While it is well known in the Aries community that <code>did:key</code> is fundamentally different from the did:peer method that is the basis of Aries protocols, it must be re-emphasized here. This RFC does NOT imply any changes to the use of <code>did:peer</code> in Aries, nor does it change the content of a <code>did:peer</code> DIDDoc. This RFC only changes references to plain public keys in the JSON of some RFCs to use <code>did:key</code> in place of a plain text string.</p> <p>Should this RFC be ACCEPTED, a community coordinated update will be used to apply updates to the agent code bases and impacted RFCs.</p>"},{"location":"features/0360-use-did-key/#motivation","title":"Motivation","text":"<p>When one Aries agent inserts a public key into the JSON of an Aries message (for example, the <code>~service</code> decorator), it assumes that the recipient agent will use the key in the intended way. At the time this RFC is being written, this is easy because only one key type is in use by all agents. However, in order to enable the use of different cryptography algorithms, the public references must be extended to at least include the key type. The preferred and concise way to do that is the use of the multicodec mechanism, which provides a registry of encodings for known key types that are prefixed to the public key in a standard and concise way. did:key extends that mechanism by providing a templated way to transform the combination of public key and key type into a DID-standard DIDDoc.</p> <p>At the cost of adding/building a did:key resolver we get a DID standard way to access the key and key type, including specific information on how the key can be used. The resolver may be trivial or complex. In a trivial version, the key type is assumed, and the key can be easily extracted from the string. In a more complete implementation, the key type can be checked, and standard DID URL handling can be used to extract parts of the DIDDoc for specific purposes. For example, in the ed25519 <code>did:key</code> DIDDoc, the existence of the <code>keyAgreement</code> entry implies that the key can be used in a Diffie-Hellman exchange, without the developer guessing, or using the key incorrectly.</p> <p>Note that simply knowing the key type is not necessarily sufficient to be able to use the key. The cryptography supporting the processing data using the key must also be available in the agent. However, the multicodec and did:key capabilities will simplify adding support for new key types in the future.</p>"},{"location":"features/0360-use-did-key/#tutorial","title":"Tutorial","text":"<p>An example of the use of the replacement of a verkey with <code>did:key</code> can be found in the ~service decorator RFC. Notably in the example at the beginning of the tutorial section, the verkeys in the <code>recipientKeys</code> and <code>routingKeys</code> items would be changed from native keys to use <code>did:key</code> as follows:</p> <pre><code>{\n    \"@type\": \"somemessagetype\",\n    \"~service\": {\n        \"recipientKeys\": [\"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"],\n        \"routingKeys\": [\"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"]\n        \"serviceEndpoint\": \"https://example.com/endpoint\"\n    }\n}\n</code></pre> <p>Thus, <code>8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K</code> becomes <code>did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th</code> using the following transformations:</p> <ul> <li>Start with the original (presumably) base58 ed25519 public key</li> <li>Since we have only a naked public key, we must assume the format</li> <li>Base58 decode the public key to get the hex version</li> <li>Multicodec: Prefix with the unsigned varint of the algorithm type. In this case, that means prefixing the string with <code>unsigned_varint(0xed)</code> (which is <code>0xed 0x01</code>) for the key type of ed25519,</li> <li>the <code>0xed</code> is per the multicodec table (search for  <code>ed25519</code>).</li> <li>Note that unsigned varint handling varies by key type prefix, so don't just assume the same handling (e.g. <code>code+0x01</code>) for other key type prefixes. For a broader discussion of this see this issue comment in the <code>did:key</code> repo.</li> <li>Multibase: Base58 encode the result and prefix that with \"z\" to indicate base58 encoding</li> <li>DID: Prefix that with the DID Method prefix <code>did:key:</code></li> </ul> <p>The transformation above is only for illustration within this RFC. The <code>did:key</code> specification is the definitive source for the appropriate transformations.</p> <p>The <code>did:key</code> method uses the strings that are the DID, public key and key type to construct (\"resolve\") a DIDDoc based on a template defined by the <code>did:key</code> specification. Further, the <code>did:key</code> resolver generates, in the case of an ed25519 public signing key, a key that can be used as part of a Diffie-Hellman exchange appropriate for encryption in the <code>keyAgreement</code> section of the DIDDoc. Presumably, as the <code>did:key</code> method supports other key types, similar DIDDoc templates will become part of the specification. Key types that don't support a signing/key exchange transformation would not have a <code>keyAgreement</code> entry in the resolved DIDDoc.</p> <p>The following currently implemented RFCs would be affected by acceptance of this RFC. In these RFCs, the JSON items that currently contain naked public keys (mostly the items <code>recipientKeys</code> and <code>routingKeys</code>) would be changed to use <code>did:key</code> references where applicable. Note that in these items public DIDs could also be used if applicable for a given use case.</p> <ul> <li>0023-did-exchange - Invitation Message</li> <li>0028-introduce</li> <li>0056-service-decorator</li> <li>0160-connection-protocol</li> <li>0434-out-of-band-protocols</li> <li>0211-mediator-coordination-protocol</li> </ul> <p>Service entries in <code>did:peer</code> DIDDocs (such as in RFCs 0094-cross-domain-messaging and 0067-didcomm-diddoc-conventions) should NOT use a <code>did:key</code> public key representation. Instead, service entries in the DIDDoc should reference keys defined internally in the DIDDoc where appropriate.</p> <p>To Do: Discuss the use of <code>did:key</code> (or not) in the context of encryption envelopes. This will be part of the ongoing discussion about JWEs and the upcoming discussions about JWMs\u2014a soon-to-be-proposed specification. That conversation will likely go on in the DIF DIDComm Working Group.</p>"},{"location":"features/0360-use-did-key/#reference","title":"Reference","text":"<p>See the <code>did:key</code> specification. Note that the specification is still evolving.</p>"},{"location":"features/0360-use-did-key/#drawbacks","title":"Drawbacks","text":"<p>The <code>did:key</code> standard is not finalized.</p> <p>The DIDDoc \"resolved\" from a <code>did:key</code> probably has more entries in it than are needed for DIDComm. That said, the entries in the DIDDoc make it clear to a developer how they can use the public key.</p>"},{"location":"features/0360-use-did-key/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>We should not stick with the status quo and assume that all agents will always know the type of keys being used and how to use them.</p> <p>We should at minimum move to a scheme like multicodecs such that the key is self documenting and supports the versioning of cryptographic algorithms. However, even if we do that, we still have to document for developers how they should (and not should not) use the public key.</p> <p>Another logical alternative is to use a JWK. However, that representation only adds the type of the key (same as multicodecs) at the cost of being significantly more verbose.</p>"},{"location":"features/0360-use-did-key/#prior-art","title":"Prior art","text":"<p>To do - there are other instances of this pattern being used. Insert those here.</p>"},{"location":"features/0360-use-did-key/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>How to transition to the use of <code>did:key</code>.</li> <li>What will the initial accepted version of <code>did:key</code> look like?  It's probably close to its final form, with an expected resolution of the open question of what  a DIDDoc looks like if the key type is not ed25519.</li> </ul>"},{"location":"features/0360-use-did-key/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes</p> Name / Link Implementation Notes"},{"location":"features/0418-rich-schema-encoding/","title":"Aries RFC 0418: Aries Rich Schema Encoding Objects","text":"<ul> <li>Author: Ken Ebert, Mike Lodder, Brent Zundel, Alexander Shcherbakov</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes:</li> <li>Start Date: 2019-03-19</li> <li>Tags: feature, rich-schemas</li> </ul>"},{"location":"features/0418-rich-schema-encoding/#summary","title":"Summary","text":"<p>The introduction of rich schemas and their associated greater range of possible attribute value data types require correspondingly rich transformation algorithms. The purpose of the new encoding object is to specify the algorithm used to perform transformations of each attribute value data type into a canonical data encoding in a deterministic way. </p> <p>The initial use for these will be the transformation of attribute value data into 256-bit integers so that they can be incorporated into the anonymous credential signature schemes we use. The transformation algorithms will also allow for extending the cryptographic schemes and various sizes of canonical data encodings (256-bit, 384-bit, etc.). The transformation algorithms will allow for broader use of predicate proofs, and avoid hashed values as much as possible, as they do not support predicate proofs.</p> <p>Encoding objects are processed in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0418-rich-schema-encoding/#motivation","title":"Motivation","text":"<p>All attribute values to be signed in anonymous credentials must be transformed into 256-bit integers in order to support the  [Camenisch-Lysyanskaya signature][CL-signatures] scheme.</p> <p>The current methods for creating a credential only accept attributes which are encoded as 256-bit integers. The current possible source attribute types are integers and strings. No configuration method exists at this time to specify which transformation method will be applied to a particular attribute. All encoded attribute values rely on an implicit understanding of how they were encoded.</p> <p>The current set of canonical encodings consists of integers and hashed strings. The introduction of encoding objects allows for a means of extending the current set of canonical encodings to include integer representations of dates, lengths, boolean values, and floating point numbers. All encoding objects describe how an input is transformed into an encoding of an attribute value according to the transformation algorithm selected by the issuer.</p>"},{"location":"features/0418-rich-schema-encoding/#tutorial","title":"Tutorial","text":""},{"location":"features/0418-rich-schema-encoding/#intro-to-encoding-objects","title":"Intro to Encoding Objects","text":"<p>Encoding objects are JSON objects that describe the input types, transformation algorithms, and output encodings. The encoding object is stored on the ledger.</p>"},{"location":"features/0418-rich-schema-encoding/#properties","title":"Properties","text":"<p>Encoding's properties follow the generic template defined in  Rich Schema Common.</p> <p>Encoding's <code>content</code> field is a JSON-serialized string with the following fields:</p> <ul> <li><code>input</code>: a description of the input value.</li> <li><code>output</code>: a description of the output value.</li> <li><code>algorithm</code>:</li> <li><code>documentation</code>: a URL which references a specific github commit of   the documentation that fully describes the transformation algorithm.</li> <li><code>implementation</code>: a URL that links to a reference implementation of the   transformation algorithm. It is not necessary to use the implementation   linked to here, as long as the implementation used implements the same   transformation algorithm.</li> <li><code>description</code>: a brief description of the transformation algorithm.</li> <li><code>testVectors</code>: a URL which references a specific github commit of a selection of test vectors that may be used to provide assurance that a transformation algorithm implementation is correct. </li> </ul>"},{"location":"features/0418-rich-schema-encoding/#example-encoding","title":"Example Encoding","text":"<p>An example of the <code>content</code> field of an Encoding object: <pre><code>{\n    \"input\": {\n        \"id\": \"DateRFC3339\",\n        \"type\": \"string\"\n    },\n    \"output\": {\n        \"id\": \"UnixTime\",\n        \"type\": \"256-bit integer\"\n    },\n    \"algorithm\": {\n        \"description\": \"This encoding transforms an\n            RFC3339-formatted datetime object into the number\n            of seconds since January 1, 1970 (the Unix epoch).\",\n        \"documentation\": URL to specific github commit,\n        \"implementation\": URL to implementation\n    },\n    \"testVectors\": URL to specific github commit\n}\n</code></pre></p>"},{"location":"features/0418-rich-schema-encoding/#transformation-algorithms","title":"Transformation Algorithms","text":"<p>The purpose of a transformation algorithm is to deterministically convert a value into a different encoding. For example, an attribute value may be a string representation of a date, but the CL-signature signing mechanism requires all inputs to be 256-bit integers. The transformation algorithm takes this string value as input, parses it, and encodes it as a 256-bit integer.  </p> <p>It is anticipated that the encodings used for CL signatures and their associated transformation algorithms will be used primarily by two entities. First, the issuer will use the transformation algorithm to prepare credential values for signing. Second, the verifier will use the transformation algorithm to verify that revealed values were correctly encoded and signed, and to properly transform values against which predicates may be evaluated.</p>"},{"location":"features/0418-rich-schema-encoding/#integer-representation","title":"Integer Representation","text":"<p>In order to properly encode values as integers for use in predicate proofs, a common 256-bit integer representation is needed. Predicate proofs are kept simple by requiring all inputs to be represented as positive integers. To accomplish this, we introduce a zero-offset and map all integer results onto a range from 9 to 2<sup>256</sup> - 10. The zero point in this range is 2<sup>255</sup>. </p> <p>Any transformation algorithm which outputs an integer value should use this representation.</p>"},{"location":"features/0418-rich-schema-encoding/#floating-point-representation","title":"Floating Point Representation","text":"<p>In order to retain the provided precision of floating point values, we use Q number format, a binary, fixed-point number format. We use 64 fractional bits.</p>"},{"location":"features/0418-rich-schema-encoding/#reserved-values","title":"Reserved Values","text":"<p>For integer and floating point representations, there are some reserved numeric strings which have a special meaning.</p> Special Value Representation Description -\u221e 8 The largest negative number.Always less than any other valid integer. \u221e 2<sup>256</sup> - 9 The largest positive number.Always greater than any other valid integer. NULL 7 Indicates that the value of a field is not supplied.Not a valid value for comparisons. NaN 2<sup>256</sup> - 8 Floating point NaN.Not a valid value for comparisons. reserved 1 to 6 Reserved for future use. reserved 2<sup>256</sup> - 7 to 2<sup>256</sup> - 1 Reserved for future use."},{"location":"features/0418-rich-schema-encoding/#documentation","title":"Documentation","text":"<p>The value of the documentation field is intended to be a URL which, when dereferenced, will provide specific information about the transformation algorithm such that it may be implemented. We recommend that the URL reference some immutable content, such as a specific github commit, an IPFS file, etc.</p>"},{"location":"features/0418-rich-schema-encoding/#implementation","title":"Implementation","text":"<p>The value of the implementation field is intended to be a URL which, when dereferenced, will provide a reference implementation of the transformation algorithm.</p>"},{"location":"features/0418-rich-schema-encoding/#test-vectors","title":"Test Vectors","text":"<p>Test vectors are very important. Although not comprehensive, a set of public test vectors allows for multiple implementations to verify adherence to the transformation algorithm for the set. Test vectors should consist of a set of comma-separated input/output pairs. The input values should be read from the file as strings. The output values should be byte strings encoded as hex values.</p> <p>The value of the test_vectors field is intended to be a URL which, when dereferenced, will provide the file of test vectors. We recommend that the URL reference some immutable content, such as a specific github commit, an IPFS file, etc.</p>"},{"location":"features/0418-rich-schema-encoding/#data-registry-storage","title":"Data Registry Storage","text":"<p>Aries will provide a means for writing contexts to and reading contexts from a verifiable data registry (such as a distributed ledger).</p> <p>An Encoding object will be written to the ledger in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0418-rich-schema-encoding/#aries-data-registry-interface","title":"Aries Data Registry Interface","text":"<p>Aries Data Registry Interface methods for adding and retrieving an Encoding object from the ledger comply with the generic approach described in Rich Schema Objects Common.</p> <p>This means the following methods can be used: - <code>write_rich_schema_object</code> - <code>read_rich_schema_object_by_id</code> - <code>read_rich_schema_object_by_metadata</code></p>"},{"location":"features/0418-rich-schema-encoding/#reference","title":"Reference","text":"<p>The following is a  reference implementation of various transformation algorithms.</p> <p>Here is the paper that defines Camenisch-Lysyanskaya signatures.</p> <ul> <li>0250: Rich Schema Objects</li> <li>0420: Rich Schema Objects Common </li> </ul>"},{"location":"features/0418-rich-schema-encoding/#drawbacks","title":"Drawbacks","text":"<p>This increases the complexity of issuing verifiable credentials and verifiying the accompanying verifiable presentations. </p>"},{"location":"features/0418-rich-schema-encoding/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Encoding attribute values as integers is already part of using anonymous credentials, however the current method is implicit, and relies on use of a common implementation library for uniformity. If we do not include encodings as part of the Rich Schema effort, we will be left with an incomplete set of possible predicates, a lack of explicit mechanisms for issuers to specify which encoding methods they used, and a corresponding lack of verifiablity of signed attribute values.</p> <p>In another design that was considered, the encoding on the ledger was actually a function an end user could call, with the ledger nodes performing the transformation algorithm and returning the encoded value. The benefit of such a design would have been the guarantee of uniformity across encoded values. This design was rejected because of the unfeasibility of using the ledger nodes for such calculations and the privacy implications of submitting attribute values to a public ledger.</p>"},{"location":"features/0418-rich-schema-encoding/#prior-art","title":"Prior art","text":"<p>A description of a prior effort to add encodings to Indy may be found in this jira ticket and  pull request.</p> <p>What the prior effort lacked was a corresponding enhancement of schema infrastructure which would have provided the necessary typing of attribute values.</p>"},{"location":"features/0418-rich-schema-encoding/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the proposed interface generic enough to support other data registries?</li> <li>We are not defining Rich Schema objects as DID DOCs for now. We may re-consider this in future once DID DOC format is finalized.</li> <li>It may make sense to extend DID specification to include using DID for referencing Rich Schema objects.</li> <li>The proposed canonicalization form of a content to be used for DID's id-string generation is in a Draft version, so we  may find a better way to do it.</li> </ul>"},{"location":"features/0418-rich-schema-encoding/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0428-prepare-issue-rich-credential/","title":"0428: Prerequisites to Issue Rich Credential","text":"<ul> <li>Authors: Brent Zundel, Ken Ebert</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes: </li> <li>Start Date: 2020-02-19 </li> <li>Tags: feature, rich-schemas</li> </ul>"},{"location":"features/0428-prepare-issue-rich-credential/#summary","title":"Summary","text":"<p>Describes the prerequisites an issuer must ensure are in place before issuing a rich credential.</p>"},{"location":"features/0428-prepare-issue-rich-credential/#motivation","title":"Motivation","text":"<p>To inform issuers of the steps they should take in order to make sure they have the necessary rich schema objects in place before they use them to issue credentials.</p>"},{"location":"features/0428-prepare-issue-rich-credential/#tutorial","title":"Tutorial","text":""},{"location":"features/0428-prepare-issue-rich-credential/#rich-schema-credential-workflow","title":"Rich Schema Credential Workflow","text":"<ol> <li>The issuer checks the ledger to see if the credential definition he wants to use is already present.</li> <li>If not, the issuer checks the ledger to see if the mapping he wants to use    is already present.<ol> <li>If not, the issuer checks the ledger to see if the schemas he wants to   use are already present.<ol> <li>If not, anchor the context used by each schema to the ledger.</li> <li>Anchor the schemas on the ledger. Schema objects may refer to one or  more context objects.</li> </ol> </li> <li>Anchor to the ledger the mapping object that associates each claim with   one or more encoding objects and a corresponding attribute. (The issuer   selects schema properties and associated encodings to be included as   claims in the credential. Encoding objects refer to transformation   algorithms, documentation, and code which implements the transformation.   The claim is the data; the attribute is the transformed data represented   as a 256 bit integer that is signed. The mapping object refers to the   schema objects and encoding objects.)</li> </ol> </li> <li>Anchor a credential definition that refers to a single mapping object. The    credential definition contains public keys for each attribute. The credential    definition refers to the issuer DID.</li> <li>Using the credential definition, mapping, and schema(s) issue to the holder a credential based on the credential definition and the supplied claim data. The Issue Credential Protocol 1.0 will be the model for another RFC containing minor modifications to issue a credential using the new rich schema objects. </li> </ol> <p>Subsequent credentials may be issued by repeating only the last step.</p> <p></p>"},{"location":"features/0428-prepare-issue-rich-credential/#reference","title":"Reference","text":"<ul> <li>RFC 0250: Rich Schema Objects</li> <li>RFC 0420: Rich Schema Objects Common</li> <li>RFC 0249: Aries Rich Schema Contexts</li> <li>RFC 0281: Aries Rich Schemas</li> <li>RFC XXXX: Aries Rich Schema Mappings</li> <li>RFC XXXX: Aries Rich Schema Credential Definitions</li> <li>RFC 0036: Issue Credential Protocol 1.0</li> </ul>"},{"location":"features/0428-prepare-issue-rich-credential/#unresolved-questions","title":"Unresolved questions","text":"<p>RFCs for Rich Schema Mappings and Rich Schema Credential Definitions are  incomplete.</p>"},{"location":"features/0428-prepare-issue-rich-credential/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0429-prepare-req-rich-pres/","title":"0429: Prerequisites to Request Rich Presentation","text":"<ul> <li>Authors: Brent Zundel, Ken Ebert</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes: </li> <li>Start Date: 2020-02-19 </li> <li>Tags: feature, rich-schemas</li> </ul>"},{"location":"features/0429-prepare-req-rich-pres/#summary","title":"Summary","text":"<p>Describes the prerequisites a verifier must ensure are in place before requesting a rich presentation.</p>"},{"location":"features/0429-prepare-req-rich-pres/#motivation","title":"Motivation","text":"<p>To inform verifiers of the steps they should take in order to make sure they have the necessary rich schema objects in place before they use them to request proofs.</p>"},{"location":"features/0429-prepare-req-rich-pres/#tutorial","title":"Tutorial","text":""},{"location":"features/0429-prepare-req-rich-pres/#rich-schema-presentation-definition-workflow","title":"Rich Schema Presentation Definition Workflow","text":"<ol> <li>The verifier checks his wallet or the ledger to see if the presentation definition already exists. (The verifier determines which attribute or predicates he needs a holder to present to satisfy the verifier's business rules. Presentation definitions specify desired attributes and predicates).</li> <li>If not, the verifier creates a new presentation definition and stores the    presentation definition in his wallet locally and, optionally, anchors it to    the verifiable data registry. (Anchoring the presentation definition to the    verifiable data registry allows other verifiers to easily use it. It can be done by writing the full presentation definition's content to the ledger, or just writing a digital fingerprint/hash of the content.)</li> <li>Using the presentation definition, request a presentation from the holder. The Present Proof Protocol 1.0 will be the model for another RFC containing minor modifications for presenting a proof based on verifiable credentials using the new rich schema objects.</li> </ol>"},{"location":"features/0429-prepare-req-rich-pres/#reference","title":"Reference","text":"<ul> <li>RFC 0250: Rich Schema Objects</li> <li>RFC 0420: Rich Schema Objects Common</li> <li>RFC XXXX: Aries Rich Schema Presentation Definitions</li> <li>RFC 0037: Present Proof Protocol 1.0</li> </ul>"},{"location":"features/0429-prepare-req-rich-pres/#unresolved-questions","title":"Unresolved questions","text":"<p>The RFC for Rich Schema Presentation Definitions is incomplete.</p>"},{"location":"features/0429-prepare-req-rich-pres/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0434-outofband/","title":"Aries RFC 0434: Out-of-Band Protocol 1.1","text":"<ul> <li>Authors: Ryan West, Daniel Bluhm, Matthew Hailstone, Stephen Curran, Sam Curren, George Aristy</li> <li>Status: ADOPTED</li> <li>Since: 2020-03-01</li> <li>Status Note: This RFC extracts the <code>invitation</code> messages from the DID Exchange protocol (and perhaps Connection), and replaces the combined <code>present_proof/1.0/request</code> combined with the <code>~service</code> decorator to define an ephemeral (connection-less) challenge.</li> <li>Supersedes: Invitation Message in 0160-Connections and Invitation Message in 0023-DID-Exchange.</li> <li>Start Date: 2020-03-01</li> <li>Tags: feature, protocol, test-anomaly</li> <li>URI: <code>https://didcomm.org/out-of-band/%VER</code></li> </ul>"},{"location":"features/0434-outofband/#summary","title":"Summary","text":"<p>The Out-of-band protocol is used when you wish to engage with another agent and you don't have a DIDComm connection to use for the interaction.</p>"},{"location":"features/0434-outofband/#motivation","title":"Motivation","text":"<p>The use of the <code>invitation</code> in the Connection and DID Exchange protocols has been relatively successful, but has some shortcomings, as follows.</p>"},{"location":"features/0434-outofband/#connection-reuse","title":"Connection Reuse","text":"<p>A common pattern we have seen in the early days of Aries agents is a user with a browser getting to a point where a connection is needed between the website's (enterprise) agent and the user's mobile agent. A QR invitation is displayed, scanned and a protocol is executed to establish a connection. Life is good!</p> <p>However, with the current invitation processes, when the same user returns to the same page, the same process is executed (QR code, scan, etc.) and a new connection is created between the two agents. There is no way for the user's agent to say \"Hey, I've already got a connection with you. Let's use that one!\"</p> <p>We need the ability to reuse a connection.</p>"},{"location":"features/0434-outofband/#connection-establishment-versioning","title":"Connection Establishment Versioning","text":"<p>In the existing Connections and DID Exchange <code>invitation</code> handling, the inviter dictates what connection establishment protocol all invitee's will use. A more sustainable approach is for the inviter to offer the invitee a list of supported protocols and allow the invitee to use one that it supports.</p>"},{"location":"features/0434-outofband/#handling-of-all-out-of-band-messages","title":"Handling of all Out-of-Band Messages","text":"<p>We currently have two sets of out-of-band messages that cannot be delivered via DIDComm because there is no channel. We'd like to align those messages into a single \"out-of-band\" protocol so that their handling can be harmonized inside an agent, and a common QR code handling mechanism can be used.</p>"},{"location":"features/0434-outofband/#urls-and-qr-code-handling","title":"URLs and QR Code Handling","text":"<p>We'd like to have the specification of QR handling harmonized into a single RFC (this one).</p>"},{"location":"features/0434-outofband/#tutorial","title":"Tutorial","text":""},{"location":"features/0434-outofband/#key-concepts","title":"Key Concepts","text":"<p>The Out-of-band protocol is used when an agent doesn't know if it has a connection with another agent. This could be because you are trying to establish a new connection with that agent, you have connections but don't know who the other party is, or if you want to have a connection-less interaction. Since there is no DIDComm connection to use for the messages of this protocol, the messages are plaintext and sent out-of-band, such as via a QR code, in an email message or any other available channel. Since the delivery of out-of-band messages will often be via QR codes, this RFC also covers the use of QR codes.</p> <p>Two well known use cases for using an out-of-band protocol are:</p> <ul> <li>A user on a web browser wants to execute a protocol (for example, to issue a verifiable credential) between the website operator's agent and a user's agent. To enable the execution of the protocol, the two agents must first have a connection. An out-of-band message is used to trigger the creation of a new, or the reuse an existing, connection.</li> <li>A website operator wants to request something from a user on their site where there is no (known) connection with the user's agent, and there is no need to create a connection.</li> </ul> <p>In both cases, there is only a single out-of-band protocol message sent. The message responding to the out-of-band message is a DIDComm message from an appropriate protocol.</p> <p>Note that the website-to-agent model is not the only such interaction enabled by the out-of-band protocol, and a QR code is not the only delivery mechanism for out-of-band messages. However, they are useful as examples of the purpose of the protocol.</p>"},{"location":"features/0434-outofband/#roles","title":"Roles","text":"<p>The out-of-band protocol has two roles: sender and receiver.</p>"},{"location":"features/0434-outofband/#sender","title":"sender","text":"<p>The agent that generates the out-of-band message and makes it available to the other party.</p>"},{"location":"features/0434-outofband/#receiver","title":"receiver","text":"<p>The agent that receives the out-of-band message and decides how to respond. There is no out-of-band protocol message with which the receiver will respond. Rather, if they respond, they will use a message from another protocol that the sender understands.</p>"},{"location":"features/0434-outofband/#states","title":"States","text":"<p>The state machines for the sender and receiver are a bit odd for the out-of-band protocol because it consists of a single message that kicks off a co-protocol and ends when evidence of the co-protocol's launch is received, in the form of some response. In the following state machine diagrams we generically describe the response message from the receiver as being a DIDComm message.</p> <p>The sender state machine is as follows:</p> <p></p> <p>Note the \"optional\" reference under the second event in the <code>await-response</code> state. That is to indicate that an out-of-band message might be a single use message with a transition to done, or reusable message (received by many receivers) with a transition back to <code>await-response</code>.</p> <p>The receiver state machine is as follows:</p> <p></p> <p>Worth noting is the first event of the <code>done</code> state, where the receiver may receive the message multiple times. This represents, for example, an agent returning to the same website and being greeted with instances of the same QR code each time.</p>"},{"location":"features/0434-outofband/#messages","title":"Messages","text":"<p>The out-of-band protocol a single message that is sent by the sender.</p>"},{"location":"features/0434-outofband/#invitation-httpsdidcommorgout-of-bandverinvitation","title":"Invitation: <code>https://didcomm.org/out-of-band/%VER/invitation</code>","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/invitation\",\n  \"@id\": \"&lt;id used for context as pthid&gt;\",\n  \"label\": \"Faber College\",\n  \"goal_code\": \"issue-vc\",\n  \"goal\": \"To issue a Faber College Graduate credential\",\n  \"accept\": [\n    \"didcomm/aip2;env=rfc587\",\n    \"didcomm/aip2;env=rfc19\"\n  ],\n  \"handshake_protocols\": [\n    \"https://didcomm.org/didexchange/1.0\",\n    \"https://didcomm.org/connections/1.0\"\n  ],\n  \"requests~attach\": [\n    {\n      \"@id\": \"request-0\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"json\": \"&lt;json of protocol message&gt;\"\n      }\n    }\n  ],\n  \"services\": [\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]\n}\n</code></pre> <p>The items in the message are:</p> <ul> <li><code>@type</code> - the DIDComm message type</li> <li><code>@id</code> - the unique ID of the message. The ID should be used as the parent thread ID (<code>pthid</code>) for the response message, rather than the more common thread ID (<code>thid</code>) of the response message. This enables multiple uses of a single out-of-band message.</li> <li><code>label</code> - [optional] a self-attested string that the receiver may want to display to the user, likely about who sent the out-of-band message.</li> <li><code>goal_code</code> - [optional] a self-attested code the receiver may want to display to the user or use in automatically deciding what to do with the out-of-band message.</li> <li><code>goal</code> - [optional] a self-attested string that the receiver may want to display to the user about the context-specific goal of the out-of-band message.</li> <li><code>accept</code> - [optional] an array of media (aka mime) types in the order of preference of the sender that the receiver can use in responding to the message. If <code>accept</code> is not specified, the receiver uses its preferred choice to respond to the message. RFC 0044 provides a general discussion of media types.</li> <li><code>handshake_protocols</code> - [optional] an array of protocols in the order of preference of the sender that the receiver can use in responding to the message in order to create or reuse a connection with the sender. These are not arbitrary protocols but rather protocols that result in the establishment of a connection. One or both of <code>handshake_protocols</code> and <code>requests~attach</code> MUST be included in the message.</li> <li><code>requests~attach</code> - [optional] an attachment decorator containing an array of request messages in order of preference that the receiver can using in responding to the message. One or both of <code>handshake_protocols</code> and <code>requests~attach</code> MUST be included in the message.</li> <li>While the JSON form of the attachment is used in the example above, the sender could choose to use the base64 form.</li> <li><code>services</code> - an array of union types that the receiver uses when responding to the message. Each item is either a DIDComm <code>service</code> object (as per RFC0067) or a DID (as per Decentralized Identifiers v1.0). Additional details below.</li> </ul> <p>If only the <code>handshake_protocols</code> item is included, the initial interaction will complete with the establishment (or reuse) of the connection. Either side may then use that connection for any purpose. A common use case (but not required) would be for the sender to initiate another protocol after the connection is established to accomplish some shared goal.</p> <p>If only the <code>requests~attach</code> item is included, no new connection is expected to be created, although one could be used if the receiver knows such a connection already exists. The receiver responds to one of the messages in the <code>requests~attach</code> array. The <code>requests~attach</code> item might include the first message of a protocol from the sender, or might be a please-play-the-role message requesting the receiver initiate a protocol. If the protocol requires a further response from the sender to the receiver, the receiver must include a <code>~service</code> decorator for the sender to use in responding.</p> <p>If both the <code>handshake_protocols</code> and <code>requests~attach</code> items are included in the message, the receiver should first establish a connection and then respond (using that connection) to one of the messages in the <code>requests~attach</code> message. If a connection already exists between the parties, the receiver may respond immediately to the <code>request-attach</code> message using the established connection.</p>"},{"location":"features/0434-outofband/#reuse-messages","title":"Reuse Messages","text":"<p>While the receiver is expected to respond with an initiating message from a <code>handshake_protocols</code> or <code>requests~attach</code> item using an offered service, the receiver may be able to respond by reusing an existing connection. Specifically, if a connection they have was created from an out-of-band <code>invitation</code> from the same <code>services</code> DID of a new <code>invitation</code> message, the connection MAY be reused. The receiver may choose to not reuse the existing connection for privacy purposes and repeat a handshake protocol to receive a redundant connection. </p> <p>If a message has a service block instead of a DID in the <code>services</code> list, you may enable reuse by encoding the key and endpoint of the service block in a Peer DID numalgo 2 and using that DID instead of a service block.</p> <p>If the receiver desires to reuse the existing connection and a <code>requests~attach</code> item is included in the message, the receiver SHOULD respond to one of the attached messages using the existing connection.</p> <p>If the receiver desires to reuse the existing connection and no <code>requests~attach</code> item is included in the message, the receiver SHOULD attempt to do so with the <code>reuse</code> and <code>reuse-accepted</code> messages. This will notify the inviter that the existing connection should be used, along with the context that can be used for follow-on interactions.</p> <p>While the <code>invitation</code> message is passed unencrypted and out-of-band, both the <code>handshake-reuse</code> and <code>handshake-reuse-accepted</code> messages MUST be encrypted and transmitted as normal DIDComm messages.</p>"},{"location":"features/0434-outofband/#reuse-httpsdidcommorgout-of-bandverhandshake-reuse","title":"Reuse: <code>https://didcomm.org/out-of-band/%VER/handshake-reuse</code>","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/handshake-reuse\",\n  \"@id\": \"&lt;id&gt;\",\n  \"~thread\": {\n    \"thid\": \"&lt;same as @id&gt;\",\n    \"pthid\": \"&lt;The @id of the Out-of-Band invitation&gt;\"\n  }\n}\n</code></pre> <p>The items in the message are:</p> <ul> <li><code>@type</code> - the DIDComm message type</li> <li><code>@id</code> - the unique ID of the message. </li> <li><code>pthid</code> - the @id of the invitation message. This provides the context link for the inviter to prompt additional protocol interactions.</li> </ul> <p>Sending or receiving this message does not change the state of the existing connection.</p> <p>When the inviter receives the <code>handshake-reuse</code> message, they MUST respond with a <code>handshake-reuse-accepted</code> message to notify that invitee that the request to reuse the existing connection is successful.</p>"},{"location":"features/0434-outofband/#reuse-accepted-httpsdidcommorgout-of-bandverhandshake-reuse-accepted","title":"Reuse Accepted:  <code>https://didcomm.org/out-of-band/%VER/handshake-reuse-accepted</code>","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/handshake-reuse-accepted\",\n  \"@id\": \"&lt;id&gt;\",\n  \"~thread\": {\n    \"thid\": \"&lt;The Message @id of the reuse message&gt;\",\n    \"pthid\": \"&lt;The @id of the Out-of-Band invitation&gt;\"\n  }\n}\n</code></pre> <p>The items in the message are:</p> <ul> <li><code>@type</code> - the DIDComm message type</li> <li><code>@id</code> - the unique ID of the message. </li> <li><code>pthid</code> - the @id of the invitation message. This and the <code>thid</code> provides context for the invitee to know the reuse attempt succeeded.</li> </ul> <p>If this message is not received by the invitee, they should use the regular process. This message is a mechanism by which the invitee can detect a situation where the inviter no longer has a record of the connection and is unable to decrypt and process the <code>handshake-reuse</code> message.</p> <p>After sending this message, the inviter may continue any desired protocol interactions based on the context matched by the <code>pthid</code> present in the <code>handshake-reuse</code> message.</p>"},{"location":"features/0434-outofband/#responses","title":"Responses","text":"<p>The following table summarizes the different forms of the out-of-band <code>invitation</code> message depending on the presence (or not) of the <code>handshake_protocols</code> item, the <code>requests~attach</code> item and whether or not a connection between the agents already exists.</p> <code>handshake_protocols</code> Present? <code>requests~attach</code> Present? Existing connection? Receiver action(s) No No No Impossible Yes No No Uses the first supported protocol from <code>handshake_protocols</code> to make a new connection using the first supported <code>services</code> entry. No Yes No Send a response to the first supported request message using the first supported <code>services</code> entry. Include a <code>~service</code> decorator if the sender is expected to respond. No No Yes Impossible Yes Yes No Use the first supported protocol from <code>handshake_protocols</code> to make a new connection using the first supported <code>services</code> entry, and then send a response message to the first supported attachment message using the new connection. Yes No Yes Send a <code>handshake-reuse</code> message. No Yes Yes Send a response message to the first supported request message using the existing connection. Yes Yes Yes Send a response message to the first supported request message using the existing connection. <p>Both the <code>goal_code</code> and <code>goal</code> fields SHOULD be used with the localization service decorator. The two fields are to enable both human and machine handling of the out-of-band message. <code>goal_code</code> is to specify a generic, protocol level outcome for sending the out-of-band message (e.g. issue verifiable credential, request proof, etc.) that is suitable for machine handling and possibly human display, while <code>goal</code> provides context specific guidance, targeting mainly a person controlling the receiver's agent. The list of <code>goal_code</code> values is provided in the Message Catalog section of this RFC.</p>"},{"location":"features/0434-outofband/#the-services-item","title":"The <code>services</code> Item","text":"<p>As mentioned in the description above, the <code>services</code> item array is intended to be analogous to the <code>service</code> block of a DIDDoc. When not reusing an existing connection, the receiver scans the array and selects (according to the rules described below) a service entry to use for the response to the out-of-band message.</p> <p>There are two forms of entries in the <code>services</code> item array:</p> <ul> <li>a DID that is resolved to retrieve it's DIDDoc service block, and</li> <li>an inline service block.</li> </ul> <p>The following is an example of a two entry array, one of each form:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/invitation\",\n  \"@id\": \"&lt;id used for context as pthid&gt;\",\n  \"label\": \"Faber College\",\n  \"handshake_protocols\": [\"https://didcomm.org/didexchange/1.0\"],\n  \"services\": [\n    {\n      \"id\": \"#inline\",\n      \"type\": \"did-communication\",\n      \"recipientKeys\": [\"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"],\n      \"routingKeys\": [],\n      \"serviceEndpoint\": \"https://example.com:5000\"\n    },\n    \"did:sov:LjgpST2rjsoxYegQDRm7EL\"\n  ]\n}\n</code></pre> <p>The processing rules for the <code>services</code> block are:</p> <ul> <li>Use only entries where the <code>type</code> is equal to <code>did-communication</code>.</li> <li>Entries without a <code>type</code> are assumed to be <code>did-communication</code>.</li> <li>The sender MUST put the array into their order of preference, and, as such, the receiver SHOULD prefer the entries in order.</li> </ul> <p>The attributes in the inline form parallel the attributes of a DID Document for increased meaning. The <code>recipientKeys</code> and <code>routingKeys</code> within the inline block decorator MUST be <code>did:key</code> references.</p> <p>As defined in the DIDComm Cross Domain Messaging RFC, if <code>routingKeys</code> is present and non-empty, additional forwarding wrapping are necessary in the response message.</p> <p>When considering routing and options for out-of-band messages, keep in mind that the more detail in the message, the longer the URL will be and (if used) the more dense (and harder to scan) the QR code will be.</p>"},{"location":"features/0434-outofband/#service-endpoint","title":"Service Endpoint","text":"<p>The service endpoint used to transmit the response is either present in the out-of-band message or available in the DID Document of a presented DID. If the endpoint is itself a DID, the <code>serviceEndpoint</code> in the DIDDoc of the resolved DID MUST be a URI, and the <code>recipientKeys</code> MUST contain a single key. That key is appended to the end of the list of <code>routingKeys</code> for processing. For more information about message forwarding and routing, see RFC 0094 Cross Domain Messaging.</p>"},{"location":"features/0434-outofband/#adoption-messages","title":"Adoption Messages","text":"<p>The <code>problem_report</code> message MAY be adopted by the out-of-band protocol if the agent wants to respond with problem reports to invalid messages, such as attempting to reuse a single-use invitation.</p>"},{"location":"features/0434-outofband/#constraints","title":"Constraints","text":"<p>An existing connection can only be reused based on a DID in the <code>services</code> list in an out-of-band message.</p>"},{"location":"features/0434-outofband/#reference","title":"Reference","text":""},{"location":"features/0434-outofband/#messages-reference","title":"Messages Reference","text":"<p>The full description of the message in this protocol can be found in the Tutorial section of this RFC.</p>"},{"location":"features/0434-outofband/#localization","title":"Localization","text":"<p>The <code>goal_code</code> and <code>goal</code> fields SHOULD have localization applied. See the purpose of those fields in the message type definitions section and the message catalog section (immediately below).</p>"},{"location":"features/0434-outofband/#message-catalog","title":"Message Catalog","text":""},{"location":"features/0434-outofband/#goal_code","title":"<code>goal_code</code>","text":"<p>The following values are defined for the <code>goal_code</code> field:</p> Code (cd) English (en) issue-vc To issue a credential request-proof To request a proof create-account To create an account with a service p2p-messaging To establish a peer-to-peer messaging relationship"},{"location":"features/0434-outofband/#goal","title":"<code>goal</code>","text":"<p>The <code>goal</code> localization values are use case specific and localization is left to the agent implementor to enable using the techniques defined in the ~l10n RFC.</p>"},{"location":"features/0434-outofband/#roles-reference","title":"Roles Reference","text":"<p>The roles are defined in the Tutorial section of this RFC.</p>"},{"location":"features/0434-outofband/#states-reference","title":"States Reference","text":""},{"location":"features/0434-outofband/#initial","title":"initial","text":"<p>No out-of-band messages have been sent.</p>"},{"location":"features/0434-outofband/#await-response","title":"await-response","text":"<p>The sender has shared an out-of-band message with the intended receiver(s), and the sender has not yet received all of the responses. For a single-use out-of-band message, there will be only one response; for a multi-use out-of-band message, there is no defined limit on the number of responses.</p>"},{"location":"features/0434-outofband/#prepare-response","title":"prepare-response","text":"<p>The receiver has received the out-of-band message and is preparing a response. The response will not be an out-of-band protocol message, but a message from another protocol chosen based on the contents of the out-of-band message.</p>"},{"location":"features/0434-outofband/#done","title":"done","text":"<p>The out-of-band protocol has been completed. Note that if the out-of-band message was intended to be available to many receivers (a multiple use message), the sender returns to the await-response state rather than going to the done state.</p>"},{"location":"features/0434-outofband/#errors","title":"Errors","text":"<p>There is an optional courtesy error message stemming from an out-of-band message that the sender could provide if they have sufficient recipient information. If the out-of-band message is a single use message and the sender receives multiple responses and each receiver's response includes a way for the sender to respond with a DIDComm message, all but the first MAY be answered with a <code>problem_report</code>.</p>"},{"location":"features/0434-outofband/#error-message-example","title":"Error Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/problem_report\",\n  \"@id\": \"5678876542345\",\n  \"~thread\": { \"pthid\": \"&lt;@id of the OutofBand message&gt;\" },\n  \"description\": {\n    \"en\": \"The invitation has expired.\",\n    \"code\": \"expired-invitation\"\n  },\n  \"impact\": \"thread\"\n}\n</code></pre> <p>See the problem-report protocol for details on the items in the example.</p>"},{"location":"features/0434-outofband/#flow-overview","title":"Flow Overview","text":"<p>In an out-of-band message the sender gives information to the receiver about the kind of DIDComm protocol response messages it can handle and how to deliver the response. The receiver uses that information to determine what DIDComm protocol/message to use in responding to the sender, and (from the service item or an existing connection) how to deliver the response to the sender.</p> <p>The handling of the response is specified by the protocol used.</p> <p>To Do: Make sure that the following remains in the DID Exchange/Connections RFCs</p> <p>Any Published DID that expresses support for DIDComm by defining a  <code>service</code> that follows the DIDComm conventions serves as an implicit invitation. If an invitee wishes to connect to any Published DID, they need not wait for an out-of-band invitation message. Rather, they can designate their own label and initiate the appropriate protocol (e.g. 0160-Connections or 0023-DID-Exchange) for establishing a connection.</p>"},{"location":"features/0434-outofband/#standard-out-of-band-message-encoding","title":"Standard Out-of-Band Message Encoding","text":"<p>Using a standard out-of-band message encoding allows for easier interoperability between multiple projects and software platforms. Using a URL for that standard encoding provides a built in fallback flow for users who are unable to automatically process the message. Those new users will load the URL in a browser as a default behavior, and may be presented with instructions on how to install software capable of processing the message. Already onboarded users will be able to process the message without loading in a browser via mobile app URL capture, or via capability detection after being loaded in a browser.</p> <p>The standard out-of-band message format is a URL with a Base64Url encoded json object as a query parameter.</p> <p>Please note the difference between Base64Url and Base64 encoding.</p> <p>The Base64URL encoded JSON object SHOULD NOT use padding, but the decoding implementation used MUST correctly decode padded and unpadded Base64URL encoded data.</p> <p>The URL format is as follows, with some elements described below:</p> <pre><code>https://&lt;domain&gt;/&lt;path&gt;?oob=&lt;outofbandMessage&gt;\n</code></pre> <p><code>&lt;domain&gt;</code> and <code>&lt;path&gt;</code> should be kept as short as possible, and the full URL SHOULD return human readable instructions when loaded in a browser. This is intended to aid new users. The <code>oob</code> query parameter is required and is reserved to contain the out-of-band message string. Additional path elements or query parameters are allowed, and can be leveraged to provide coupons or other promise of payment for new users.</p> <p>To do: We need to rationalize this approach <code>https://</code> approach with the use of a special protocol (e.g. <code>didcomm://</code>) that will enable handling of the URL on mobile devices to automatically invoke an installed app on both Android and iOS. A user must be able to process the out-of-band message on the device of the agent (e.g. when the mobile device can't scan the QR code because it is on a web page on device).</p> <p>The <code>&lt;outofbandMessage&gt;</code> is an agent plaintext message (not a DIDComm message) that has been Base64Url encoded such that the resulting string can be safely used in a URL.</p> <pre><code>outofband_message = base64UrlEncode(&lt;outofbandMessage&gt;)\n</code></pre> <p>During Base64Url encoding, whitespace from the JSON string SHOULD be eliminated to keep the resulting out-of-band message string as short as possible.</p>"},{"location":"features/0434-outofband/#example-out-of-band-message-encoding","title":"Example Out-of-Band Message Encoding","text":"<p>Invitation:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/1.0/invitation\",\n  \"@id\": \"69212a3a-d068-4f9d-a2dd-4741bca89af3\",\n  \"label\": \"Faber College\",\n  \"goal_code\": \"issue-vc\",\n  \"goal\": \"To issue a Faber College Graduate credential\",\n  \"handshake_protocols\": [\"https://didcomm.org/didexchange/1.0\", \"https://didcomm.org/connections/1.0\"],\n  \"services\": [\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]\n}\n</code></pre> <p>Whitespace removed:</p> <pre><code>{\"@type\":\"https://didcomm.org/out-of-band/1.0/invitation\",\"@id\":\"69212a3a-d068-4f9d-a2dd-4741bca89af3\",\"label\":\"Faber College\",\"goal_code\":\"issue-vc\",\"goal\":\"To issue a Faber College Graduate credential\",\"handshake_protocols\":[\"https://didcomm.org/didexchange/1.0\",\"https://didcomm.org/connections/1.0\"],\"services\":[\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]}\n</code></pre> <p>Base64Url encoded:</p> <pre><code>eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0\n</code></pre> <p>Example URL with Base64Url encoded message:</p> <pre><code>http://example.com/ssi?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0\n</code></pre> <p>Out-of-band message URLs can be transferred via any method that can send text, including an email, SMS, posting on a website, or QR Code.</p> <p>Example URL encoded as a QR Code:</p> <p></p> <p>Example Email Message:</p> <pre><code>To: alice@alum.faber.edu\nFrom: studentrecords@faber.edu\nSubject: Your request to connect and receive your graduate verifiable credential\n\nDear Alice,\n\nTo receive your Faber College graduation certificate, click here to [connect](http://example.com/ssi?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0) with us, or paste the following into your browser:\n\nhttp://example.com/ssi?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0\n\nIf you don't have an identity agent for holding credentials, you will be given instructions on how you can get one.\n\nThanks,\n\nFaber College\nKnowledge is Good\n</code></pre>"},{"location":"features/0434-outofband/#url-shortening","title":"URL Shortening","text":"<p>It seems inevitable that the length of some out-of-band message will be too long to produce a useable QR code. Techniques to avoid unusable QR codes have been presented above, including using attachment links for requests, minimizing the routing of the response and eliminating unnecessary whitespace in the JSON. However, at some point a sender may need generate a very long URL. In that case, a DIDComm specific URL shortener redirection should be implemented by the sender as follows:</p> <ul> <li>The sender generates a unique URL for each shortened out-of-band message.</li> <li>The unique URL often includes a unique id component as part of the path or in a query parameter.</li> <li>The following URLs are valid examples:</li> <li><code>https://example.com/ssi?id=5f0e3ffb-3f92-4648-9868-0d6f8889e6f3</code></li> <li><code>https://example.com/8E6nEcJ26TTE</code></li> <li><code>https://example.com/sky/event/8DcnUW2h8m4jcfPdQ2uMN7/work-laptop-bag/s/u</code></li> <li>On receipt of this form of message, the agent MUST perform an HTTP GET to retrieve the associated out-of-band message. The agent SHOULD include an <code>Accept</code> header requesting the <code>application/json</code> MIME type.</li> <li>The sender MAY include a <code>Content-Type</code> header specifying <code>application/json; charset=utf-8</code>, and in the case where the agent included an <code>Accept</code> header for the <code>application/json</code> MIME type, the sender MUST include the header. If so, the sender MUST return the invitation in JSON format in the response body with a <code>status_code</code> of <code>200</code>.</li> <li>The sender MAY respond with a <code>status_code</code> of <code>301</code> or <code>302</code> and include a <code>Location</code> header specifying the long out-of-band message URL.</li> <li>This redirect option operates like many commercial URL shorteners. </li> <li>The sender MUST invalidate the URL after message retrieval or after an expiration time to prevent unintended parties from retrieving a copy of the message.</li> <li>A sender MUST NOT use a commercial URL shortener unless it supports invalidating the URL.</li> </ul> <p>A usable QR code will always be able to be generated from the shortened form of the URL.</p>"},{"location":"features/0434-outofband/#url-shortening-caveats","title":"URL Shortening Caveats","text":"<p>Some HTTP libraries don't support stopping redirects from occuring on reception of a <code>301</code> or <code>302</code>, in this instance the redirect is automatically followed and will result in a response that MAY have a status of <code>200</code> and MAY contain a URL that can be processed as a normal <code>Out-of-Band</code> message.</p> <p>If the agent performs a HTTP GET with the <code>Accept</code> header requesting <code>application/json</code> MIME type the response can either contain the message in <code>json</code> or result in a redirect, processing of the response should attempt to determine which response type is received and process the message accordingly.</p>"},{"location":"features/0434-outofband/#out-of-band-message-publishing","title":"Out-of-Band Message Publishing","text":"<p>The sender will publish or transmit the out-of-band message URL in a manner available to the intended receiver. After publishing, the sender is in the await-response state, will the receiver is in the prepare-response state.</p>"},{"location":"features/0434-outofband/#out-of-band-message-processing","title":"Out-of-Band Message Processing","text":"<p>If the receiver receives an <code>out-of-band</code> message in the form of a QR code, the receiver should attempt to decode the QR code to an out-of-band message URL for processing.</p> <p>When the receiver receives the out-of-band message URL, there are two possible user flows, depending on whether the individual has an Aries agent. If the individual is new to Aries, they will likely load the URL in a browser. The resulting page SHOULD contain instructions on how to get started by installing an Aries agent. That install flow will transfer the out-of-band message to the newly installed software.</p> <p>A user that already has those steps accomplished will have the URL received by software directly. That software will attempt to base64URL decode the string and can read the out-of-band message directly out of the <code>oob</code> query parameter, without loading the URL. If this process fails then the software should attempt the steps to process a shortened URL. </p> <p>NOTE: In receiving the out-of-band message, the base64url decode implementation used MUST correctly decode padded and unpadded base64URL encoded data.</p> <p>If the receiver wants to respond to the out-of-band message, they will use the information in the message to prepare the request, including:</p> <ul> <li>the <code>handshake_protocols</code> or <code>requests~attach</code> to determine the acceptable response messages, and</li> <li>the <code>services</code> block to determine how to get the response to the sender.</li> </ul>"},{"location":"features/0434-outofband/#correlating-responses-to-out-of-band-messages","title":"Correlating responses to Out-of-Band messages","text":"<p>The response to an out-of-band message MUST set its <code>~thread.pthid</code> equal to the <code>@id</code> property of the out-of-band message.</p> <p>Example referencing an explicit invitation:</p> <pre><code>{\n  \"@id\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n  \"@type\": \"https://didcomm.org/didexchange/1.0/request\",\n  \"~thread\": { \"pthid\": \"032fbd19-f6fd-48c5-9197-ba9a47040470\" },\n  \"label\": \"Bob\",\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n    \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n    \"jws\": {\n      \"header\": {\n        \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n      },\n      \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n      \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n    }\n  }\n}\n</code></pre>"},{"location":"features/0434-outofband/#response-transmission","title":"Response Transmission","text":"<p>The response message from the receiver is encoded according to the standards of the DIDComm encryption envelope, using the <code>service</code> block present in (or resolved from) the out-of-band invitation.</p>"},{"location":"features/0434-outofband/#reusing-connections","title":"Reusing Connections","text":"<p>If an out-of-band invitation has a DID in the <code>services</code> block, and the receiver determines it has previously established a connection with that DID, the receiver MAY send its response on the established connection. See Reuse Messages for details.</p>"},{"location":"features/0434-outofband/#receiver-error-handling","title":"Receiver Error Handling","text":"<p>If the receiver is unable to process the out-of-band message, the receiver may respond with a Problem Report identifying the problem using a DIDComm message. As with any response, the ~thread decorator of the <code>pthid</code> MUST be the <code>@id</code> of the out-of-band message. The problem report MUST be in the protocol of an expected response. An example of an error that might come up is that the receiver is not able to handle any of the proposed protocols in the out-of-band message. The receiver MAY include in the problem report a <code>~service</code> decorator that allows the sender to respond to the out-of-band message with a DIDComm message.</p>"},{"location":"features/0434-outofband/#response-processing","title":"Response processing","text":"<p>The sender MAY look up the corresponding out-of-band message identified in the response's <code>~thread.pthid</code> to determine whether it should accept the response. Information about the related out-of-band message protocol may be required to provide the sender with context about processing the response and what to do after the protocol completes.</p>"},{"location":"features/0434-outofband/#sender-error-handling","title":"Sender Error Handling","text":"<p>If the sender receives a Problem Report message from the receiver, the sender has several options for responding. The sender will receive the message as part of an offered protocol in the out-of-band message.</p> <p>If the receiver did not include a <code>~service</code> decorator in the response, the sender can only respond if it is still in session with the receiver. For example, if the sender is a website that displayed a QR code for the receiver to scan, the sender could create a new, presumably adjusted, out-of-band message, encode it and present it to the user in the same way as before.</p> <p>If the receiver included a <code>~service</code> decorator in the response, the sender can provide a new message to the receiver, even a new version of the original out-of-band message, and send it to the receiver. The new message MUST include a <code>~thread</code> decorator with the <code>thid</code> set to the <code>@id</code> from the problem report message.</p>"},{"location":"features/0434-outofband/#drawbacks","title":"Drawbacks","text":"<ul> <li>Publicly displayed out-of-band messages (say, a slide at the end of a presentation) all use the same DID. This is not a problem for institutions, and only provides a minor increase in correlation over sharing an endpoint, key, and routing information in a way that is observable by multiple parties.</li> </ul>"},{"location":"features/0434-outofband/#prior-art","title":"Prior art","text":"<ul> <li>The out-of-band message/response process is similar to other key exchange protocols.</li> <li>The Connections and DID Exchange protocols have (or had) their own <code>invitation</code> method.</li> <li>The <code>~service</code> decorator in combination with a request/response-type protocol message (such as present-proof/request) has previously used in place of the out-of-band <code>request</code> message.</li> </ul>"},{"location":"features/0434-outofband/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>None</li> </ul>"},{"location":"features/0434-outofband/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0445-rich-schema-mapping/","title":"Aries RFC 0445: Aries Rich Schema Mapping","text":"<ul> <li>Author: Alexander Shcherbakov, Ken Ebert, Brent Zundel</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes:</li> <li>Start Date: 2019-03-16</li> <li>Tags: feature, rich-schemas</li> </ul>"},{"location":"features/0445-rich-schema-mapping/#summary","title":"Summary","text":"<p>Mappings serve as a bridge between rich schemas and the flat array of signed integers. A mapping specifies the order in which attributes are transformed and signed. It consists of a set of graph paths and the encoding used for the attribute values specified by those graph paths. Each claim in a mapping has a reference to an encoding, and those encodings are defined in encoding objects.</p> <p>Mapping objects are processed in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0445-rich-schema-mapping/#motivation","title":"Motivation","text":"<p>Rich schemas are complex, hierarchical, and possibly nested objects. The Camenisch-Lysyanskaya signature scheme used by Indy requires the attributes to be represented by an array of 256-bit integers. Converting data specified by a rich schema into a flat array of integers requires a mapping object.</p>"},{"location":"features/0445-rich-schema-mapping/#tutorial","title":"Tutorial","text":""},{"location":"features/0445-rich-schema-mapping/#intro-to-mappings","title":"Intro to Mappings","text":"<p>Mappings are written to the ledger so they can be shared by multiple credential definitions.  A Credential Definition may only reference a single Mapping.</p> <p>One or more Mappings can be referenced by a Presentation Definition. The mappings serve as a vital part of the verification process. The verifier, upon receipt of a presentation must not only check that the array of integers signed by the issuer is valid, but that the attribute values were transformed and ordered according to the mapping referenced in the credential definition.</p> <p>A Mapping references one and only one Rich Schema object. If there is no Schema Object  a Mapping can reference, a new Schema must be created on the ledger. If a Mapping needs to map attributes from multiple Schemas, then a new Schema embedding the multiple Schemas  must be created and stored on the ledger.    </p> <p>Mappings need to be discoverable.</p> <p>Mapping is a JSON-LD object following the same structure (attributes and graph pathes)  as the corresponding Rich Schema. A Mapping may contain only a subset of the original Rich Schema's attributes.</p> <p>Every Mapping must have two default attributes required by any W3C compatible credential  (see W3C verifiable credential specification): <code>issuer</code> and <code>issuanceDate</code>.  Additionally, any other attributes that are considered optional by the W3C verifiable credential specification that will be included in the issued credential must be included in the Mapping. For example, <code>credentialStatus</code> or <code>expirationDate</code>. This allows the holder to selectively disclose these attributes in the same way as other attributes from the schema.</p> <p>The value of every schema attribute in a Mapping object is an array of the following pairs: - encoding object (referenced by its <code>id</code>) to be used for representation of the attribute as an integer - rank of the attribute to define the order in which the attribute is signed by the Issuer.</p> <p>The value is an array as the same attribute may be used in Credential Definition multiple times with different encodings. </p> <p>Note: The anonymous credential signature scheme currently used by Indy is Camenisch-Lysyanskaya signatures. It is the use of this signature scheme in combination with rich schema objects that necessitates a mapping object. If another signature scheme is used which does not have the same requirements, a mapping object may not be necessary or a different mapping object may need to be defined.</p>"},{"location":"features/0445-rich-schema-mapping/#properties","title":"Properties","text":"<p>Mapping's properties follow the generic template defined in  Rich Schema Common.</p> <p>Mapping's <code>content</code> field is a JSON-LD-serialized string with the following fields:</p>"},{"location":"features/0445-rich-schema-mapping/#id","title":"@id","text":"<p>A Mapping must have an <code>@id</code> property. The value of this property must be equal to the <code>id</code> field which is a DID (see Identification of Rich Schema Objects). </p>"},{"location":"features/0445-rich-schema-mapping/#type","title":"@type","text":"<p>A Mapping must have a <code>@type</code> property. The value of this property must be (or map to, via a context object) a URI. </p>"},{"location":"features/0445-rich-schema-mapping/#context","title":"@context","text":"<p>A Mapping may have a <code>@context</code> property. If present, the value of this property must be a context object or a URI which can be dereferenced to obtain a context object.</p>"},{"location":"features/0445-rich-schema-mapping/#schema","title":"schema","text":"<p>An <code>id</code> of the corresponding Rich Schema</p>"},{"location":"features/0445-rich-schema-mapping/#attributes","title":"attributes","text":"<p>A dict of all the schema attributes the Mapping object is going to map to encodings and use in credentials. An attribute may have nested attributes matching the schema structure.</p> <p>It must also contain the following default attributes required by any W3C compatible verifiable credential (plus any additional attributes that may have been included from the W3C verifiable credentials data model):   - <code>issuer</code>  - <code>issuanceDate</code>  - any additional attributes</p> <p>Every leaf attribute's value (including the default <code>issuer</code> and <code>issuanceDate</code> ones) is an array of the following pairs:</p> <ul> <li><code>enc</code> (string): Encoding object (referenced by its <code>id</code>) to be used for representation of the attribute as an integer. </li> <li><code>rank</code> (int): Rank of the attribute to define the order in which the attribute is signed by the Issuer. It is important that no two <code>rank</code> values may be identical.</li> </ul>"},{"location":"features/0445-rich-schema-mapping/#example-mapping","title":"Example Mapping","text":"<p>Let's consider a Rich Schema object with the following <code>content</code>: <pre><code>    '@id': \"did:sov:4e9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n    '@context': \"did:sov:2f9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n    '@type': \"rdfs:Class\",\n    \"rdfs:comment\": \"ISO18013 International Driver License\",\n    \"rdfs:label\": \"Driver License\",\n    \"rdfs:subClassOf\": {\n        \"@id\": \"sch:Thing\"\n    },\n    \"driver\": \"Driver\",\n    \"dateOfIssue\": \"Date\",\n    \"dateOfExpiry\": \"Date\",\n    \"issuingAuthority\": \"Text\",\n    \"licenseNumber\": \"Text\",\n    \"categoriesOfVehicles\": {\n        \"vehicleType\": \"Text\",\n        \"dateOfIssue\": \"Date\",\n        \"dateOfExpiry\": \"Date\",\n        \"restrictions\": \"Text\",\n    },\n    \"administrativeNumber\": \"Text\"\n</code></pre></p> <p>Then the corresponding Mapping object may have the following <code>content</code>.   Please note that we used all attributes from the original Schema except <code>dateOfExpiry</code>, <code>categoriesOfVehicles/dateOfExpiry</code> and <code>categoriesOfVehicles/restrictions</code>. Also, the <code>licenseNumber</code> attribute is used twice, but with different encodings.  It is important that no two <code>rank</code> values may be identical.  <pre><code>    '@id': \"did:sov:5e9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n    '@context': \"did:sov:2f9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n    '@type': \"rdfs:Class\",\n    \"schema\": \"did:sov:4e9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n    \"attributes\" : {\n        \"issuer\": [{\n            \"enc\": \"did:sov:9x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n            \"rank\": 1\n        }],\n        \"issuanceDate\": [{\n            \"enc\": \"did:sov:119F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n            \"rank\": 2\n        }],\n        \"expirationDate\": [{\n            \"enc\": \"did:sov:119F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n            \"rank\": 11\n        }],        \n        \"driver\": [{\n            \"enc\": \"did:sov:1x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n            \"rank\": 5\n        }],\n        \"dateOfIssue\": [{\n            \"enc\": \"did:sov:2x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n            \"rank\": 4\n        }],\n        \"issuingAuthority\": [{\n            \"enc\": \"did:sov:3x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n            \"rank\": 3\n        }],\n        \"licenseNumber\": [\n            {\n                \"enc\": \"did:sov:4x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n                \"rank\": 9\n            },\n            {\n                \"enc\": \"did:sov:5x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n                \"rank\": 10\n            },\n        ],\n        \"categoriesOfVehicles\": {\n            \"vehicleType\": [{\n                \"enc\": \"did:sov:6x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n                \"rank\": 6\n            }],\n            \"dateOfIssue\": [{\n             \"enc\": \"did:sov:7x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n                \"rank\": 7\n            }],\n        },\n        \"administrativeNumber\": [{\n            \"enc\": \"did:sov:8x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n            \"rank\": 8\n        }]\n    }\n</code></pre></p>"},{"location":"features/0445-rich-schema-mapping/#data-registry-storage","title":"Data Registry Storage","text":"<p>Aries will provide a means for writing contexts to and reading contexts from a verifiable data registry (such as a distributed ledger).</p> <p>A Mapping object will be written to the ledger in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0445-rich-schema-mapping/#aries-data-registry-interface","title":"Aries Data Registry Interface","text":"<p>Aries Data Registry Interface methods for adding and retrieving a Mapping object from the ledger comply with the generic approach described in Rich Schema Objects Common.</p> <p>This means the following methods can be used: - <code>write_rich_schema_object</code> - <code>read_rich_schema_object_by_id</code> - <code>read_rich_schema_object_by_metadata</code></p>"},{"location":"features/0445-rich-schema-mapping/#reference","title":"Reference","text":"<p>The following is a  reference implementation of various transformation algorithms.</p> <p>Here is the paper that defines Camenisch-Lysyanskaya signatures.</p> <ul> <li>0250: Rich Schema Objects</li> <li>0420: Rich Schema Objects Common </li> <li>W3C verifiable credential specification</li> </ul>"},{"location":"features/0445-rich-schema-mapping/#drawbacks","title":"Drawbacks","text":"<p>This increases the complexity of issuing verifiable credentials and verifiying the accompanying verifiable presentations. </p>"},{"location":"features/0445-rich-schema-mapping/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>A <code>schema</code> object is supported by the W3C Verifiable Credentials Data Model specification.</li> <li>It supports rich schema capabilities for credentials.</li> </ul>"},{"location":"features/0445-rich-schema-mapping/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the proposed interface generic enough to support other data registries?</li> <li>We are not defining Rich Schema objects as DID DOCs for now. We may re-consider this in future once DID DOC format is finalized.</li> <li>It may make sense to extend DID specification to include using DID for referencing Rich Schema objects.</li> <li>The proposed canonicalization form of a content to be used for DID's id-string generation is in a Draft version, so we  may find a better way to do it.</li> <li>We don't check if the specified <code>@context</code> is valid by resolving all external links.</li> </ul>"},{"location":"features/0445-rich-schema-mapping/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0446-rich-schema-cred-def/","title":"Aries RFC 0446: Aries Rich Schema Credential Definition","text":"<ul> <li>Author: Alexander Shcherbakov, Ken Ebert, Brent Zundel</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes:</li> <li>Start Date: 2019-03-16</li> <li>Tags: feature, rich-schemas</li> </ul>"},{"location":"features/0446-rich-schema-cred-def/#summary","title":"Summary","text":"<p>Credential Definition can be used by the Issuer to set public keys for a particular  Rich Schema   and Mapping. The public keys can be used for signing the credentials by the Issuer according to the order and encoding of attributes defined by the referenced Mapping.</p> <p>Credential Definition objects are processed in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0446-rich-schema-cred-def/#motivation","title":"Motivation","text":"<p>The current format for Indy credential definitions provides a method for issuers to specify a schema and provide public key data for credentials they issue. This ties the schema and public key data values to the issuer's DID. The verifier uses the credential definition to check the validity of each signed credential attribute presented to the verifier.</p> <p>The new credential definition object that uses rich schemas is a minor modification of the current Indy credential definition. The new format has the same public key data. In addition to referencing a schema, the new credential definition can also reference a mapping object.</p>"},{"location":"features/0446-rich-schema-cred-def/#tutorial","title":"Tutorial","text":""},{"location":"features/0446-rich-schema-cred-def/#intro-to-credential-definition","title":"Intro to Credential Definition","text":"<p>Credential definitions are written to the ledger so they can be used by holders and verifiers  in presentation protocol.</p> <p>A Credential Definition can reference a single Mapping and a single Rich Schema only.</p> <p>Credential Definition is a JSON object.</p> <p>Credential Definition should be immutable in most of the cases. Some application may consider it as a mutable object since the Issuer may rotate keys present there. However, rotation of Issuer's keys should be done carefully as it will invalidate all credentials issued for this key.</p>"},{"location":"features/0446-rich-schema-cred-def/#properties","title":"Properties","text":"<p>Credential definition's properties follow the generic template defined in  Rich Schema Common.</p> <p>Credential Definition's <code>content</code> field is a JSON-serialized string with the following fields:</p>"},{"location":"features/0446-rich-schema-cred-def/#signaturetype","title":"signatureType","text":"<p>Type of the signature. ZKP scheme <code>CL</code> (Camenisch-Lysyanskaya) is the only type currently supported in Indy. Other signature types, even those that do not support ZKPs, may still make use of the credential definition to link the issuer's public keys with the rich schema against which the verifiable credential was constructed.</p>"},{"location":"features/0446-rich-schema-cred-def/#mapping","title":"mapping","text":"<p>An <code>id</code> of the corresponding Mapping</p>"},{"location":"features/0446-rich-schema-cred-def/#schema","title":"schema","text":"<p>An <code>id</code> of the corresponding Rich Schema. The <code>mapping</code> must reference the same Schema.</p>"},{"location":"features/0446-rich-schema-cred-def/#publickey","title":"publicKey","text":"<p>Issuer's public keys. Consists of <code>primary</code> and <code>revocation</code> keys.</p>"},{"location":"features/0446-rich-schema-cred-def/#example-credential-definition","title":"Example Credential Definition","text":"<p>An example of the <code>content</code> field of a Credential Definition object: <pre><code>\"signatureType\": \"CL\",\n\"mapping\": \"did:sov:UVj5w8DRzcmPVDpUMr4AZhJ\",\n\"schema\": \"did:sov:U5x5w8DRzcmPVDpUMr4AZhJ\",\n\"publicKey\": {\n    \"primary\": \"...\",\n    \"revocation\": \"...\"\n}\n</code></pre></p>"},{"location":"features/0446-rich-schema-cred-def/#use-in-verifiable-credentials","title":"Use in Verifiable Credentials","text":"<p>A ZKP credential created according to the <code>CL</code> signature scheme must reference a Credential Definition used  for signing. A Credential Definition is referenced in the credentialSchema property. A Credential Definition is referenced by its <code>id</code>.</p>"},{"location":"features/0446-rich-schema-cred-def/#data-registry-storage","title":"Data Registry Storage","text":"<p>Aries will provide a means for writing contexts to and reading contexts from a verifiable data registry (such as a distributed ledger).</p> <p>A Credential Definition object will be written to the ledger in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0446-rich-schema-cred-def/#aries-data-registry-interface","title":"Aries Data Registry Interface","text":"<p>Aries Data Registry Interface methods for adding and retrieving a Credential Definition object from the ledger comply with the generic approach described in Rich Schema Objects Common.</p> <p>This means the following methods can be used: - <code>write_rich_schema_object</code> - <code>read_rich_schema_object_by_id</code> - <code>read_rich_schema_object_by_metadata</code></p>"},{"location":"features/0446-rich-schema-cred-def/#reference","title":"Reference","text":"<p>The following is a  reference implementation of various transformation algorithms.</p> <p>Here is the paper that defines Camenisch-Lysyanskaya signatures.</p> <ul> <li>0250: Rich Schema Objects</li> <li>0420: Rich Schema Objects Common </li> </ul>"},{"location":"features/0446-rich-schema-cred-def/#drawbacks","title":"Drawbacks","text":"<p>This increases the complexity of issuing verifiable credentials and verifiying the accompanying verifiable presentations. </p>"},{"location":"features/0446-rich-schema-cred-def/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>A <code>credentialSchema</code> object is supported by the W3C Verifiable Credentials Data Model specification.</li> <li>It supports rich schema capabilities for credentials.</li> </ul>"},{"location":"features/0446-rich-schema-cred-def/#prior-art","title":"Prior art","text":"<p>Indy already has a Credential Definition support. </p> <p>What the prior effort lacked was a corresponding enhancement of schema infrastructure which would have provided the necessary typing of attribute values.</p>"},{"location":"features/0446-rich-schema-cred-def/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the proposed interface generic enough to support other data registries?</li> <li>Of all the Rich Schema objects, the CredDef most closely fits the format of a DID DOC.</li> <li>However, we are not defining Rich Schema objects as DID DOCs for now. We may re-consider this in future once DID DOC format is finalized.</li> <li>It may make sense to extend DID specification to include using DID for referencing Rich Schema objects.</li> <li>The proposed canonicalization form of a content to be used for DID's id-string generation is in a Draft version, so we  may find a better way to do it.</li> </ul>"},{"location":"features/0446-rich-schema-cred-def/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0453-issue-credential-v2/","title":"Aries RFC 0453: Issue Credential Protocol 2.0","text":"<ul> <li>Authors: Nikita Khateev, Stephen Klump, Stephen Curran</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note:  See RFC 0454 for the presentation part of using credentials.</li> <li>Supersedes: RFC 0036 Issue Credential v1.x</li> <li>Start Date: 2020-03-23</li> <li>Tags: feature, decorator, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0453-issue-credential-v2/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> <li>20240313: Version 2.0 is the current version</li> <li>20240311: Removed references to payments in the protocol to clarify to those new to the protocol that they have not been implemented by anyone.</li> </ul> <p>For a period of time, versions 2.1 and 2.2 where defined in this RFC. Those definitions were added prior to any implementations, and to date, there are no known implementations available or planned. An attempt at implementing version 2.1 was not merged into the main branch of Aries Cloud Agent Python, deemed overly complicated and not worth the effort for what amounts to an edge case (issuing multiple credentials of the same type in a single protocol instance). Further, there is a version 3.0 of this protocol that has been specified and implemented that does not include these capabilities. Thus, a decision was made that versions 2.1 and 2.2 be removed as being not accepted by the community and overly complicated to both implement and migrate from. Those interested in seeing how those capabilities were specified can look at this protocol before they were removed.</p>"},{"location":"features/0453-issue-credential-v2/#20propose-credential-and-identifiers","title":"2.0/propose-credential and identifiers","text":"<p>Version 2.0 of the protocol is introduced because of a breaking changes in the propose-credential message, replacing the (indy-specific) filtration criteria with a generalized filter attachment to align with the rest of the messages in the protocol. The previous version is 1.1/propose-credential. Version 2.0 also uses &lt;angle brackets&gt; explicitly to mark all values that may vary between instances, such as identifiers and comments.</p> <p>The \"formats\" field is added to all the messages to enable the linking the specific attachment IDs with the the format (credential format and version) of the attachment.</p> <p>The details that are part of each message type about the different attachment formats serves as a registry of the known formats and versions.</p>"},{"location":"features/0453-issue-credential-v2/#summary","title":"Summary","text":"<p>Formalizes messages used to issue a credential--whether the credential is JWT-oriented, JSON-LD-oriented, or ZKP-oriented. The general flow is similar, and this protocol intends to handle all of them. If you are using a credential type that doesn't fit this protocol, please raise a Github issue.</p>"},{"location":"features/0453-issue-credential-v2/#motivation","title":"Motivation","text":"<p>We need a standard protocol for issuing credentials. This is the basis of interoperability between Issuers and Holders.</p>"},{"location":"features/0453-issue-credential-v2/#tutorial","title":"Tutorial","text":""},{"location":"features/0453-issue-credential-v2/#name-and-version","title":"Name and Version","text":"<p><code>issue-credential</code>, version 2.0</p>"},{"location":"features/0453-issue-credential-v2/#roles","title":"Roles","text":"<p>There are two roles in this protocol: Issuer and Holder. Technically, the latter role is only potential until the protocol completes; that is, the second party becomes a Holder of a credential by completing the protocol. However, we will use the term Holder throughout, to keep things simple.</p> <p>Note: When a holder of credentials turns around and uses those credentials to prove something, they become a Prover. In the sister RFC to this one, 0454: Present Proof Protocol 2.0, the Holder is therefore renamed to Prover. Sometimes in casual conversation, the Holder role here might be called \"Prover\" as well, but more formally, \"Holder\" is the right term at this phase of the credential lifecycle.</p>"},{"location":"features/0453-issue-credential-v2/#goals","title":"Goals","text":"<p>When the goals of each role are not available because of context, goal codes may be specifically included in protocol messages. This is particularly helpful to differentiate between credentials passed between the same parties for several different reasons. A goal code included should be considered to apply to the entire thread and is not necessary to be repeated on each message. Changing the goal code may be done by including the new code in a message. All goal codes are optional, and without default.</p>"},{"location":"features/0453-issue-credential-v2/#states","title":"States","text":"<p>The choreography diagram below details how state evolves in this protocol, in a \"happy path.\" The states include</p>"},{"location":"features/0453-issue-credential-v2/#issuer-states","title":"Issuer States","text":"<ul> <li>proposal-received</li> <li>offer-sent</li> <li>request-received</li> <li>credential-issued</li> <li>done</li> </ul>"},{"location":"features/0453-issue-credential-v2/#holder-states","title":"Holder States","text":"<ul> <li>proposal-sent</li> <li>offer-received</li> <li>request-sent</li> <li>credential-received</li> <li>done</li> </ul> <p>Errors might occur in various places. For example, an Issuer might offer a credential for a price that the Holder is unwilling to pay. All errors are modeled with a <code>problem-report</code> message. Easy-to-anticipate errors reset the flow as shown in the diagrams, and use the code <code>issuance-abandoned</code>; more exotic errors (e.g., server crashed at Issuer headquarters in the middle of a workflow) may have different codes but still cause the flow to be abandoned in the same way. That is, in this version of the protocol, all errors cause the state of both parties (the sender and the receiver of the <code>problem-report</code>) to revert to <code>null</code> (meaning it is no longer engaged in the protocol at all). Future versions of the protocol may allow more granular choices (e.g., requesting and receiving a (re-)send of the <code>issue-credential</code> message if the Holder times out while waiting in the <code>request-sent</code> state).</p> <p>The state table outlines the protocol states and transitions.</p>"},{"location":"features/0453-issue-credential-v2/#messages","title":"Messages","text":"<p>The Issue Credential protocol consists of these messages:</p> <ul> <li><code>propose-credential</code> - potential Holder to Issuer (optional). Tells what the Holder hopes to receive.</li> <li><code>offer-credential</code> - Issuer to potential Holder (optional for some credential implementations; required for Hyperledger Indy). Tells what the Issuer intends to issue, and possibly, the price the Issuer expects to be paid.</li> <li><code>request-credential</code> - potential Holder to Issuer. If neither of the previous message types is used, this is the message that begins the protocol.</li> <li><code>issue-credential</code> - Issuer to new Holder. Attachment payload contains the actual credential.</li> </ul> <p>In addition, the <code>ack</code> and <code>problem-report</code> messages are adopted into the protocol for confirmation and error handling.</p>"},{"location":"features/0453-issue-credential-v2/#message-attachments","title":"Message Attachments","text":"<p>This protocol is about the messages that must be exchanged to issue verifiable credentials, NOT about the specifics of particular verifiable credential schemes. DIDComm attachments are deliberately used in messages to isolate the protocol flow/semantics from the credential artifacts themselves as separate constructs. Attachments allow credential formats and this protocol to evolve through versioning milestones independently instead of in lockstep. Links are provided in the message descriptions below, to describe how the protocol adapts to specific verifiable credential implementations.</p> <p>The attachment items in the messages are arrays. The arrays are provided to support the issuing of different credential formats (e.g. ZKP, JSON-LD JWT, or other) containing the same data (claims). The arrays are not to be used for issuing credentials with different claims. The <code>formats</code> field of each message associates each attachment with the format (and version) of the attachment.</p> <p>A registry of attachment formats is provided in this RFC within the message type sections. A sub-section should be added for each attachment format type (and optionally, each version). Updates to the attachment type formats does NOT impact the versioning of the Issue Credential protocol. Formats are flexibly defined. For example, the first definitions are for <code>hlindy/cred-abstract@v2.0</code> et al., assuming that all Hyperledger Indy implementations and ledgers will use a common format. However, if a specific instance of Indy uses a different format, another format value can be documented as a new registry entry.</p> <p>Any of the 0017-attachments RFC embedded inline attachments can be used. In the examples below, <code>base64</code> is used in most cases, but implementations MUST expect any of the formats.</p>"},{"location":"features/0453-issue-credential-v2/#choreography-diagram","title":"Choreography Diagram","text":"<p>Note: This diagram was made in draw.io. To make changes:</p> <ul> <li>upload the drawing HTML from this folder to the draw.io site (Import From...GitHub),</li> <li>make changes,</li> <li>export the picture and HTML to your local copy of this repo, and</li> <li>submit a pull request.</li> </ul> <p>The protocol has 3 alternative beginnings:</p> <ol> <li>The Issuer can begin with an offer.</li> <li>The Holder can begin with a proposal.</li> <li>the Holder can begin with a request.</li> </ol> <p>The offer and proposal messages are part of an optional negotiation phase and may trigger back-and-forth counters. A request is not subject to negotiation; it can only be accepted or rejected.</p> <p></p>"},{"location":"features/0453-issue-credential-v2/#propose-credential","title":"Propose Credential","text":"<p>An optional message sent by the potential Holder to the Issuer to initiate the protocol or in response to an <code>offer-credential</code> message when the Holder wants some adjustments made to the credential data offered by Issuer.</p>  Note: In Hyperledger Indy, where the `request-credential` message can **only** be sent in response to an `offer-credential` message, the `propose-credential` message is the only way for a potential Holder to initiate the workflow.  <p>Message format:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/propose-credential\",\n    \"@id\": \"&lt;uuid of propose-message&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\"\n        }\n    ],\n    \"filters~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Proposal, so the proposal can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>credential_preview</code> -- an optional JSON-LD object that represents the credential data that Prover wants to receive. It matches the schema of Credential Preview.</li> <li><code>formats</code> -- contains an entry for each <code>filters~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable credential format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>filters~attach</code> -- an array of attachments that further define the credential being proposed. This might be used to clarify which formats or format versions are wanted.</li> </ul>"},{"location":"features/0453-issue-credential-v2/#propose-attachment-registry","title":"Propose Attachment Registry","text":"Credential Format Format Value Link to Attachment Format Comment DIF Credential Manifest <code>dif/credential-manifest@v1.0</code> <code>propose-credential</code> attachment format Linked Data Proof VC Detail <code>aries/ld-proof-vc-detail@v1.0</code> <code>ld-proof-vc-detail</code> attachment format Hyperledger Indy Credential Filter <code>hlindy/cred-filter@v2.0</code> <code>cred filter</code> format Hyperledger AnonCreds Credential Filter <code>anoncreds/credential-filter@v1.0</code> <code>Credential Filter</code> format"},{"location":"features/0453-issue-credential-v2/#offer-credential","title":"Offer Credential","text":"<p>A message sent by the Issuer to the potential Holder, describing the credential they intend to offer and possibly the price they expect to be paid. In Hyperledger Indy, this message is required, because it forces the Issuer to make a cryptographic commitment to the set of fields in the final credential and thus prevents Issuers from inserting spurious data. In credential implementations where this message is optional, an Issuer can use the message to negotiate the issuing following receipt of a <code>request-credential</code> message.</p> <p>Message Format:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/offer-credential\",\n    \"@id\": \"&lt;uuid of offer message&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"replacement_id\": \"&lt;issuer unique id&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"offers~attach\": [\n        {\n            \"@id\": \"&lt;attach@id value&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>replacement_id</code> -- an optional field to help coordinate credential replacement. When this is present and matches the <code>replacement_id</code> of a previously issued credential, it may be used to inform the recipient that the offered credential is considered to be a replacement to the previous credential. This value is unique to the issuer. It must not be used in a credential presentation.</li> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Offer, so the offer can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>credential_preview</code> -- a JSON-LD object that represents the credential data that Issuer is willing to issue. It matches the schema of Credential Preview;</li> <li><code>formats</code> -- contains an entry for each <code>offers~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable credential format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>offers~attach</code> -- an array of attachments that further define the credential being offered. This might be used to clarify which formats or format versions will be issued.</li> </ul> <p>It is possible for an Issuer to add a <code>~timing.expires_time</code> decorator to this message to convey the idea that the offer will expire at a particular point in the future. Such behavior is not a special part of this protocol, and support for it is not a requirement of conforming implementations; the <code>~timing</code> decorator is simply a general possibility for any DIDComm message. We mention it here just to note that the protocol can be enriched in composable ways.</p>"},{"location":"features/0453-issue-credential-v2/#offer-attachment-registry","title":"Offer Attachment Registry","text":"Credential Format Format Value Link to Attachment Format Comment DIF Credential Manifest <code>dif/credential-manifest@v1.0</code> <code>offer-credential</code> attachment format Hyperledger Indy Credential Abstract <code>hlindy/cred-abstract@v2.0</code> <code>cred abstract</code> format Linked Data Proof VC Detail <code>aries/ld-proof-vc-detail@v1.0</code> <code>ld-proof-vc-detail</code> attachment format Hyperledger AnonCreds Credential Offer <code>anoncreds/credential-offer@v1.0</code> <code>Credential Offer</code> format W3C VC - Data Integrity Proof Credential Offer <code>didcomm/w3c-di-vc-offer@v0.1</code> <code>Credential Offer</code> format"},{"location":"features/0453-issue-credential-v2/#request-credential","title":"Request Credential","text":"<p>This is a message sent by the potential Holder to the Issuer, to request the issuance of a credential. Where circumstances do not require a preceding Offer Credential message (e.g., there is no cost to issuance that the Issuer needs to explain in advance, and there is no need for cryptographic negotiation), this message initiates the protocol. When using the Hyperledger Indy AnonCreds verifiable credential format, this message can only be sent in response to an <code>offer-credential</code> message.</p> <p>Message Format:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/request-credential\",\n    \"@id\": \"&lt;uuid of request message&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"requests~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        },\n    ]\n}\n</code></pre> <p>Description of Fields:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Request, so it can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>formats</code> -- contains an entry for each <code>requests~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable credential format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>requests~attach</code> -- an array of attachments defining the requested formats for the credential.</li> </ul>"},{"location":"features/0453-issue-credential-v2/#request-attachment-registry","title":"Request Attachment Registry","text":"Credential Format Format Value Link to Attachment Format Comment DIF Credential Manifest <code>dif/credential-manifest@v1.0</code> <code>request-credential</code> attachment format Hyperledger Indy Credential Request <code>hlindy/cred-req@v2.0</code> <code>cred request</code> format Linked Data Proof VC Detail <code>aries/ld-proof-vc-detail@v1.0</code> <code>ld-proof-vc-detail</code> attachment format Hyperledger AnonCreds Credential Request <code>anoncreds/credential-request@v1.0</code> <code>Credential Request</code> format W3C VC - Data Integrity Proof Credential Request <code>didcomm/w3c-di-vc-request@v0.1</code> <code>Credential Request</code> format"},{"location":"features/0453-issue-credential-v2/#issue-credential","title":"Issue Credential","text":"<p>This message contains a verifiable credential being issued as an attached payload. It is sent in response to a valid Request Credential message.</p> <p>Message Format:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/issue-credential\",\n    \"@id\": \"&lt;uuid of issue message&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"replacement_id\": \"&lt;issuer unique id&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"credentials~attach\": [\n        {\n            \"@id\": \"&lt;attachment-id&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>replacement_id</code> -- an optional field that provides an identifier used to manage credential replacement. When this value is present and matches the <code>replacement_id</code> of a previously issued credential, this credential may be considered as a replacement for that credential. This value is unique to the issuer. It must not be used in a credential presentation.</li> <li><code>comment</code> -- an optional field that provides human readable information about the issued credential, so it can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>formats</code> -- contains an entry for each <code>credentials~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable credential format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>credentials~attach</code> -- an array of attachments containing the issued credentials.</li> </ul>"},{"location":"features/0453-issue-credential-v2/#credentials-attachment-registry","title":"Credentials Attachment Registry","text":"Credential Format Format Value Link to Attachment Format Comment Linked Data Proof VC <code>aries/ld-proof-vc@v1.0</code> <code>ld-proof-vc</code> attachment format Hyperledger Indy Credential <code>hlindy/cred@v2.0</code> credential format Hyperledger AnonCreds Credential <code>anoncreds/credential@v1.0</code> <code>Credential</code> format W3C VC - Data Integrity Proof Credential <code>didcomm/w3c-di-vc@v0.1</code> <code>Credential</code> format"},{"location":"features/0453-issue-credential-v2/#adopted-problem-report","title":"Adopted Problem Report","text":"<p>The problem-report message is adopted by this protocol. <code>problem-report</code> messages can be used by either party to indicate an error in the protocol.</p>"},{"location":"features/0453-issue-credential-v2/#preview-credential","title":"Preview Credential","text":"<p>This is not a message but an inner object for other messages in this protocol. It is used construct a preview of the data for the credential that is to be issued. Its schema follows:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/credential-preview\",\n    \"attributes\": [\n        {\n            \"name\": \"&lt;attribute name&gt;\",\n            \"mime-type\": \"&lt;type&gt;\",\n            \"value\": \"&lt;value&gt;\"\n        },\n        // more attributes\n    ]\n}\n</code></pre> <p>The main element is <code>attributes</code>. It is an array of (object) attribute specifications; the subsections below outline their semantics.</p>"},{"location":"features/0453-issue-credential-v2/#attribute-name","title":"Attribute Name","text":"<p>The mandatory <code>\"name\"</code> key maps to the attribute name as a string.</p>"},{"location":"features/0453-issue-credential-v2/#mime-type-and-value","title":"MIME Type and Value","text":"<p>The optional <code>mime-type</code> advises the issuer how to render a binary attribute, to judge its content for applicability before issuing a credential containing it. Its value parses case-insensitively in keeping with MIME type semantics of RFC 2045. If <code>mime-type</code> is missing, its value is null.</p> <p>The mandatory <code>value</code> holds the attribute value:</p> <ul> <li>if <code>mime-type</code> is missing (null), then <code>value</code> is a string. In other words, implementations interpret it the same as any other key+value pair in JSON</li> <li>if <code>mime-type</code> is not null, then <code>value</code> is always a base64url-encoded string that represents a binary BLOB, and <code>mime-type</code> tells how to interpret the BLOB after base64url-decoding.</li> </ul>"},{"location":"features/0453-issue-credential-v2/#threading","title":"Threading","text":"<p>Threading can be used to initiate a sub-protocol during an issue credential protocol instance. For example, during credential issuance, the Issuer may initiate a child message thread to execute the <code>Present Proof</code> sub-protocol to have the potential Holder (now acting as a Prover) prove attributes about themselves before issuing the credential. Depending on circumstances, this might be a best practice for preventing credential fraud at issuance time.</p> <p>If threading were added to all of the above messages, a <code>~thread</code> decorator would be present, and later messages in the flow would reference the <code>@id</code> of earlier messages to stitch the flow into a single coherent sequence. Details about threading can be found in the 0008: Message ID and Threading RFC.</p>"},{"location":"features/0453-issue-credential-v2/#limitations","title":"Limitations","text":"<p>Smart contracts may be missed in ecosystem, so operation \"issue credential after payment received\" is not atomic. It\u2019s possible case that malicious issuer will charge first and then will not issue credential in fact. But this situation should be easily detected and appropriate penalty should be applied in such type of networks.</p>"},{"location":"features/0453-issue-credential-v2/#negotiation-and-preview","title":"Negotiation and Preview","text":"<p>Negotiation prior to issuing the credential can be done using the <code>offer-credential</code> and <code>propose-credential</code> messages. A common negotiation use case would be about the data to go into the credential. For that, the <code>credential_preview</code> element is used.</p>"},{"location":"features/0453-issue-credential-v2/#drawbacks","title":"Drawbacks","text":"<p>None documented</p>"},{"location":"features/0453-issue-credential-v2/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Attention should be paid by the Aries community to other credential issuance protocols being proposed/used in other communities to ensure this RFC could support those protocols.</li> <li>Digital Bazaar has proposed the Credential Handler API (CHAPI) protocol that is being considered by the W3C Credentials Community Group.</li> </ul>"},{"location":"features/0453-issue-credential-v2/#prior-art","title":"Prior art","text":"<p>See RFC 0036 Issue Credential, v1.x.</p>"},{"location":"features/0453-issue-credential-v2/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>We might need to propose a new MIME type for credential (the same way as .docx is not processed as generic xml). See this issue against the W3C/vc-data-model.</li> </ul>"},{"location":"features/0453-issue-credential-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0454-present-proof-v2/","title":"Aries RFC 0454: Present Proof Protocol 2.0","text":"<ul> <li>Authors: Nikita Khateev, Stephen Curran</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note:  See RFC 0453 for the corresponding issue credential protocol.</li> <li>Supersedes: RFC 0037</li> <li>Start Date: 2020-05-27</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0454-present-proof-v2/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> <li>20240311: Version 2.0 is the current version</li> </ul> <p>For a period of time, versions 2.1 and 2.2 where defined in this RFC. Those definitions were added prior to any implementations, and to date, there are no known implementations available or planned. An attempt at implementing version 2.1 of the associated \"issue multiple credentials\" was not merged into the main branch of Aries Cloud Agent Python, deemed overly complicated and not worth the effort for what amounts to an edge case (presenting multiple presentations of the same type in a single protocol instance). Further, there is a version 3.0 of this protocol that has been specified and implemented that does not include these capabilities. Thus, a decision was made that versions 2.1 and 2.2 be removed as being not accepted by the community and overly complicated to both implement and migrate from. Those interested in seeing how those capabilities were specified can look at this protocol before they were removed.</p>"},{"location":"features/0454-present-proof-v2/#20-alignment-with-rfc-0453-issue-credential","title":"2.0 - Alignment with RFC 0453 Issue Credential","text":"<ul> <li>The \"formats\" field is added to all the messages to link the specific attachment IDs with the verifiable presentation format and version of the attachment.</li> <li>The details that are part of each message type about the different attachment formats serves as a registry of the known formats and versions.</li> <li>Version 2.0 uses &lt;angle brackets&gt; explicitly to mark all values that may vary between instances, such as identifiers and comments.</li> </ul>"},{"location":"features/0454-present-proof-v2/#summary","title":"Summary","text":"<p>A protocol supporting a general purpose verifiable presentation exchange regardless of the specifics of the underlying verifiable presentation request and verifiable presentation format.</p>"},{"location":"features/0454-present-proof-v2/#motivation","title":"Motivation","text":"<p>We need a standard protocol for a verifier to request a presentation from a prover, and for the prover to respond by presenting a proof to the verifier. When doing that exchange, we want to provide a mechanism for the participants to negotiate the underlying format and content of the proof.</p>"},{"location":"features/0454-present-proof-v2/#tutorial","title":"Tutorial","text":""},{"location":"features/0454-present-proof-v2/#name-and-version","title":"Name and Version","text":"<p><code>present-proof</code>, version 2.0</p>"},{"location":"features/0454-present-proof-v2/#key-concepts","title":"Key Concepts","text":"<p>This protocol is about the messages to support the presentation of verifiable claims, not about the specifics of particular verifiable presentation formats. DIDComm attachments are deliberately used in messages to make the protocol agnostic to specific verifiable presentation format payloads. Links are provided in the message data element descriptions to details of specific verifiable presentation implementation data structures.</p> <p>Diagrams in this protocol were made in draw.io. To make changes:</p> <ul> <li>upload the drawing HTML from this folder to the draw.io site (Import From...GitHub),</li> <li>make changes,</li> <li>export the picture and HTML to your local copy of this repo, and</li> <li>submit a pull request.</li> </ul>"},{"location":"features/0454-present-proof-v2/#roles","title":"Roles","text":"<p>The roles are <code>verifier</code> and <code>prover</code>.  The <code>verifier</code> requests the presentation of a proof and verifies the presentation, while the <code>prover</code> prepares the proof and presents it to the verifier. Optionally, although unlikely from a business sense, the <code>prover</code> may initiate an instance of the protocol using the <code>propose-presentation</code> message.</p>"},{"location":"features/0454-present-proof-v2/#goals","title":"Goals","text":"<p>When the goals of each role are not available because of context, goal codes may be specifically included in protocol messages. This is particularly helpful to differentiate between credentials passed between the same parties for several different reasons. A goal code included should be considered to apply to the entire thread and is not necessary to be repeated on each message. Changing the goal code may be done by including the new code in a message. All goal codes are optional, and without default.</p>"},{"location":"features/0454-present-proof-v2/#states","title":"States","text":"<p>The following states are defined and included in the state transition table below.</p>"},{"location":"features/0454-present-proof-v2/#states-for-verifier","title":"States for Verifier","text":"<ul> <li>request-sent</li> <li>proposal-received</li> <li>presentation-received</li> <li>abandoned</li> <li>done</li> </ul>"},{"location":"features/0454-present-proof-v2/#states-for-prover","title":"States for Prover","text":"<ul> <li>request-received</li> <li>proposal-sent</li> <li>presentation-sent</li> <li>abandoned</li> <li>done</li> </ul> <p>For the most part, these states map onto the transitions shown in both the state transition table above, and in the choreography diagram (below) in obvious ways. However, a few subtleties are worth highlighting:</p> <ul> <li> <p>The final states for both the prover and verifier are <code>done</code> or <code>abandoned</code>, and once reached, no further updates to the protocol instance are expected.</p> </li> <li> <p>The <code>ack-presentation</code> is sent or not based on the value of <code>will_confirm</code> in the <code>request-presentation</code>. Whether an <code>ack-presentation</code> is expected or not determines whether the states <code>presentation-sent</code> and <code>presentation-received</code> are used at all in a protocol instance.</p> </li> <li> <p>The <code>ack-presentation</code> message should reflect the business validation of the proof (does the proof satisfy the business need?) not just the cryptographic verification. Ideally, those are as tightly aligned as possible.</p> </li> <li> <p>When a Prover makes a (counter-)proposal, it transitions to the <code>proposal-sent</code> state. This state is only present by implication in the choreography diagram; it essentially equates to the null or begin state in that the Prover does nothing until a presentation request arrives, triggering the leftmost transition for the Prover.</p> </li> <li> <p>Errors might occur in various places. For example, a Prover might decide not to respond to a <code>presentation-request</code> or a verifier may time out waiting for the Prover to supply a <code>presentation</code>. Errors should trigger a <code>problem-report</code>. In this version of the protocol, all errors cause the state of both parties (the sender and the receiver of the <code>problem-report</code>) to transition to the terminal <code>abandoned</code> state (meaning it is no longer engaged in the protocol at all).</p> </li> </ul>"},{"location":"features/0454-present-proof-v2/#choreography-diagram","title":"Choreography Diagram","text":""},{"location":"features/0454-present-proof-v2/#messages","title":"Messages","text":"<p>The present proof protocol consists of these messages:</p> <ul> <li><code>propose-presentation</code> - Prover to Verifier (optional) - propose a presentation or send a counter-proposal in response to a <code>request-presentation</code> message</li> <li><code>request-presentation</code> - Verifier to Prover - request a presentation</li> <li><code>presentation</code> - Prover to Verifier - provide a presentation in response to a request</li> </ul> <p>In addition, the <code>ack</code> and <code>problem-report</code> messages are adopted into the protocol for confirmation and error handling.</p> <p>The messages that include <code>~attach</code> attachments may use any form of the embedded attachment. In the examples below, the forms of the attachment are arbitrary.</p> <p>The <code>~attach</code> array is to be used to enable a single presentation to be requested/delivered in different verifiable presentation formats. The ability to have multiple attachments must not be used to request/deliver multiple different presentations in a single instance of the protocol.</p>"},{"location":"features/0454-present-proof-v2/#propose-presentation","title":"Propose Presentation","text":"<p>An optional message sent by the prover to the verifier to initiate a proof presentation process, or in response to a <code>request-presentation</code> message when the prover wants to propose using a different presentation format or request. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/propose-presentation\",\n    \"@id\": \"&lt;uuid-propose-presentation&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"some comment\",\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"proposals~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"json\": \"&lt;json&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>comment</code> -- a field that provides some human readable information about the proposed presentation.</li> <li><code>formats</code> -- contains an entry for each <code>filter~attach</code> array entry, including an optional value of the attachment <code>@id</code> (if attachments are present) and the verifiable presentation format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>proposals~attach</code> -- an optional array of attachments that further define the presentation request being proposed. This might be used to clarify which formats or format versions are wanted.</li> </ul> <p>If the <code>proposals~attach</code> is not provided, the <code>attach_id</code> item in the <code>formats</code> array should not be provided. That form of the <code>propose-presentation</code> message is to indicate the presentation formats supported by the prover, independent of the verifiable presentation request content.</p>"},{"location":"features/0454-present-proof-v2/#negotiation-and-preview","title":"Negotiation and Preview","text":"<p>Negotiation prior to the delivery of the presentation can be done using the <code>propose-presentation</code> and <code>request-presentation</code> messages. The common negotiation use cases would be about the claims to go into the presentation and the format of the verifiable presentation.</p>"},{"location":"features/0454-present-proof-v2/#propose-attachment-registry","title":"Propose Attachment Registry","text":"Presentation Format Format Value Link to Attachment Format Comment Hyperledger Indy Proof Req <code>hlindy/proof-req@v2.0</code> proof request format Used to propose as well as request proofs. DIF Presentation Exchange <code>dif/presentation-exchange/definitions@v1.0</code> <code>propose-presentation</code> attachment format Hyperledger AnonCreds Proof Request <code>anoncreds/proof-request@v1.0</code> <code>Proof Request</code> format Used to propose as well as request proofs."},{"location":"features/0454-present-proof-v2/#request-presentation","title":"Request Presentation","text":"<p>From a verifier to a prover, the <code>request-presentation</code> message describes values that need to be revealed and predicates that need to be fulfilled. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/request-presentation\",\n    \"@id\": \"&lt;uuid-request&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"some comment\",\n    \"will_confirm\": true,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"request_presentations~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;base64 data&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>comment</code> -- a field that provides some human readable information about this request for a presentation.</li> <li><code>will_confirm</code> -- an optional field that defaults to <code>false</code> to indicate that the verifier will or will not send a post-presentation confirmation <code>ack</code> message</li> <li><code>formats</code> -- contains an entry for each <code>request_presentations~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable presentation request format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format Attachment registry immediately below.</li> <li><code>request_presentations~attach</code> -- an array of attachments containing the acceptable verifiable presentation requests.</li> </ul>"},{"location":"features/0454-present-proof-v2/#presentation-request-attachment-registry","title":"Presentation Request Attachment Registry","text":"Presentation Format Format Value Link to Attachment Format Comment Hyperledger Indy Proof Req <code>hlindy/proof-req@v2.0</code> proof request format Used to propose as well as request proofs. DIF Presentation Exchange <code>dif/presentation-exchange/definitions@v1.0</code> <code>propose-presentation</code> attachment format Hyperledger AnonCreds Proof Request <code>anoncreds/proof-request@v1.0</code> <code>Proof Request</code> format Used to propose as well as request proofs."},{"location":"features/0454-present-proof-v2/#presentation","title":"Presentation","text":"<p>This message is a response to a Presentation Request message and contains signed presentations. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/presentation\",\n    \"@id\": \"&lt;uuid-presentation&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"some comment\",\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"presentations~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"sha256\": \"f8dca1d901d18c802e6a8ce1956d4b0d17f03d9dc5e4e1f618b6a022153ef373\",\n                \"links\": [\"https://ibb.co/TtgKkZY\"]\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>comment</code> -- a field that provides some human readable information about this presentation.</li> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>formats</code> -- contains an entry for each <code>presentations~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable presentation format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format Attachment registry immediately below.</li> <li><code>presentations~attach</code> -- an array of attachments containing the presentation in the requested format(s).</li> </ul> <p>If the prover wants an acknowledgement that the presentation was accepted, this message may be decorated with the <code>~please-ack</code> decorator using the <code>OUTCOME</code> acknowledgement request. This is not necessary if the verifier has indicated it will send an <code>ack-presentation</code> using the <code>will_confirm</code> property. Outcome in the context of this protocol is the definition of \"successful\" as described in Ack Presentation. Note that this is different from the default behavior as described in 0317: Please ACK Decorator. It is then best practice for the new Verifier to respond with an explicit <code>ack</code> message as described in the please ack decorator RFC.</p>"},{"location":"features/0454-present-proof-v2/#presentations-attachment-registry","title":"Presentations Attachment Registry","text":"Presentation Format Format Value Link to Attachment Format Comment Hyperledger Indy Proof <code>hlindy/proof@v2.0</code> proof format DIF Presentation Exchange <code>dif/presentation-exchange/submission@v1.0</code> <code>propose-presentation</code> attachment format Hyperledger AnonCreds Proof <code>anoncreds/proof@v1.0</code> <code>Proof</code> format"},{"location":"features/0454-present-proof-v2/#ack-presentation","title":"Ack Presentation","text":"<p>A message from the verifier to the prover that the <code>Present Proof</code> protocol was completed successfully and is now in the <code>done</code> state. The message is an adopted <code>ack</code> from the RFC 0015 acks protocol. The definition of \"successful\" in this protocol means the acceptance of the presentation in whole, i.e. the proof is verified and the contents of the proof are acknowledged.</p>"},{"location":"features/0454-present-proof-v2/#problem-report","title":"Problem Report","text":"<p>A message from the verifier to the prover that follows the <code>presentation</code> message to indicate that the <code>Present Proof</code> protocol was completed unsuccessfully and is now in the <code>abandoned</code> state. The message is an adopted <code>problem-report</code> from the RFC 0015 report-problem protocol. The definition of \"unsuccessful\" from a business sense is up to the verifier. The elements of the <code>problem-report</code> message can provide information to the prover about why the protocol instance was unsuccessful.</p> <p>Either party may send a <code>problem-report</code> message earlier in the flow to terminate the protocol before its normal conclusion.</p>"},{"location":"features/0454-present-proof-v2/#reference","title":"Reference","text":"<p>Details are covered in the Tutorial section.</p>"},{"location":"features/0454-present-proof-v2/#drawbacks","title":"Drawbacks","text":"<p>The Indy format of the proposal attachment as proposed above does not allow nesting of logic along the lines of \"A and either B or C if D, otherwise A and B\", nor cross-credential options such as proposing a legal name issued by either (for example) a specific financial institution or government entity.</p> <p>The verifiable presentation standardization work being conducted in parallel to this in DIF and the W3C Credentials Community Group (CCG) should be included in at least the <code>Registry</code> tables of this document, and ideally used to eliminate the need for presentation format-specific options.</p>"},{"location":"features/0454-present-proof-v2/#rationale-and-alternatives","title":"Rationale and alternatives","text":""},{"location":"features/0454-present-proof-v2/#prior-art","title":"Prior art","text":"<p>The previous major version of this protocol is RFC 0037 Present Proof protocol and implementations.</p>"},{"location":"features/0454-present-proof-v2/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>There might need to be a way to associate a payment with the present proof protocol.</li> </ul>"},{"location":"features/0454-present-proof-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0482-coprotocol-protocol/","title":"Aries RFC 0482: Coprotocol Protocol 0.5","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Start Date: 2020-02-03</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0482-coprotocol-protocol/#summary","title":"Summary","text":"<p>Allows coprotocols to interact with one another.</p>"},{"location":"features/0482-coprotocol-protocol/#motivation","title":"Motivation","text":"<p>We need a standard way for one protocol to invoke another, giving it input, getting its output, detaching, and debugging.</p>"},{"location":"features/0482-coprotocol-protocol/#tutorial","title":"Tutorial","text":""},{"location":"features/0482-coprotocol-protocol/#name-and-version","title":"Name and Version","text":"<p>The name of this protocol is \"Coprotocol Protocol 0.5\" It is identified by the PIURI \"https://didcomm.org/coprotocol/0.5\".</p>"},{"location":"features/0482-coprotocol-protocol/#key-concepts","title":"Key Concepts","text":"<p>Please make sure you are familiar with the general concept of coprotocols, as set forth in Aries RFC 0478. A working knowledge of the terminology and mental model explained there are foundational.</p>"},{"location":"features/0482-coprotocol-protocol/#roles","title":"Roles","text":"<p>The <code>caller</code> role is played by the entity giving input and getting output. The <code>called</code> is the entity getting input and giving output.</p>"},{"location":"features/0482-coprotocol-protocol/#states","title":"States","text":"<p>The caller's normal state progression is <code>null</code> -&gt; <code>detached</code> -&gt; <code>attached</code> -&gt; <code>done</code>. It is also possible to return to a <code>detached</code> state without ever reaching <code>done</code>.</p> <p>The coprotocols normal state progression is <code>null</code> -&gt; <code>attached</code> -&gt; <code>done</code>.</p> <p></p>"},{"location":"features/0482-coprotocol-protocol/#messages","title":"Messages","text":"<p>Note: the discussion below is about how to launch and interact with any coprotocol. However, for concreteness we frame the walkthru in terms of a co-protocol that makes a payment. You can see an example definition of such a coprotocol in RFC 0478.</p> <p>The protocol consists of 5 messages: <code>bind</code>, <code>attach</code>, <code>input</code>, <code>output</code>, <code>detach</code> and the adopted <code>problem-report</code> (for propagating errors).</p> <p>The protocol begins with a <code>bind</code> message sent from <code>caller</code> to <code>called</code>. This message basically says, \"I would like to interact with a new coprotocol instance having the following characteristics and the following mapping of identifiers to roles.\" It might look like this: </p> <pre><code>{\n    \"@id\": \"4d116a88-1314-4af5-9b3c-848456b8b3dd\",\n    \"@type\": \"https://didcomm.org/coprotocol/1.0/bind\",\n    \"goal_code\": \"aries.buy.make-payment\",\n    \"co_binding_id\": null,\n    \"cast\": [\n        // Recipient of the bind message (id = null) should be payee.\n        {\"role\": \"payee\", \"id\": null},\n        // The payer will be did:peer:abc123.\n        {\"role\": \"payer\", \"id\": \"did:peer:abc123\" }\n    ]\n}\n</code></pre> <p>When a <code>called</code> agent receives this message, it should discover what protocol implementations are available that match the criteria, and sort the candidates by preference. (Note that additional criteria can be added besides those shown here; see the Reference section.) This could involve enumerating not-yet-loaded plugins. It could also involve negotiating a protocol with the remote party (e.g., the DID playing the role of <code>payer</code> in the example above) by querying its capabilities using the Discover Features Protocol. Of course, the capabilities of remote parties could also be cached to avoid this delay, or they could be predicted without confirmation, if circumstances suggest that's the best tradeoff. Once the candidates are sorted by preference, the best match should be selected. The coprotocol is NOT launched, but it is awaiting launch. The <code>called</code> agent should now generate an <code>attach</code> message that acknowledges the request to bind and tells the <code>caller</code> how to interact:</p> <pre><code>{\n    \"@id\": \"b3dd4d11-6a88-9b3c-4af5-848456b81314\",\n    \"@type\": \"https://didcomm.org/coprotocol/1.0/attach\",\n    \"~thread\": { \"pthid\": \"4d116a88-1314-4af5-9b3c-848456b8b3dd\"},\n    // This is the best match.\n    \"piuri\": \"https://didcomm.org/pay-with-venmo/1.3\"\n}\n</code></pre> <p>The <code>@id</code> of the <code>bind</code> message (also the <code>~thread.pthid</code> of the <code>attach</code> response) becomes a permanent identifier for the coprotocol binding. Both the caller and the coprotocol instance code can use it to lookup state as needed. The <code>caller</code> can now kick off/invoke the protocol with an <code>input</code> message:</p> <pre><code>{\n    \"@id\": \"56b81314-6a88-9b3c-4af5-b3dd4d118484\",\n    \"@type\": \"https://didcomm.org/coprotocol/1.0/input\",\n    \"~thread\": { \"pthid\": \"4d116a88-1314-4af5-9b3c-848456b8b3dd\"},\n    \"interaction_point\": \"invoke\",\n    \"data\": [\n        \"amount\": 1.23,\n        \"currency\": \"INR\",\n        \"bill_of_sale\": {\n            // describes what's being purchased\n        }\n    ]\n}\n</code></pre> <p>This allows the <code>caller</code> to invoke the bound coprotocol instance, and to pass it any number of named inputs.</p> <p>Later, when the coprotocol instance wants to emit an output from <code>called</code> to <code>caller</code>, it uses an <code>output</code> message (in this case, one matching the <code>preauth</code> interaction point declared in the sample coprotocol definition in RFC 0478):</p> <pre><code>{\n    \"@id\": \"9b3c56b8-6a88-f513-4a14-4d118484b3dd\",\n    \"@type\": \"https://didcomm.org/coprotocol/1.0/output\",\n    \"~thread\": { \"pthid\": \"4d116a88-1314-4af5-9b3c-848456b8b3dd\"},\n    \"interaction_point\": \"preauth\",\n    \"data\": [\n        \"code\": \"6a884d11-13149b3c\",\n    ]\n}\n</code></pre> <p>If a <code>caller</code> wants to detach, it uses a <code>detach</code> message. This leaves the coprotocol running on <code>called</code>; all inputs that it emits are sent to the bitbucket, and it advances on its normal state trajectory as if it were a wholly independent protocol:</p> <pre><code>{\n    \"@id\": \"7a3c56b8-5b88-d413-4a14-ca118484b3ee\",\n    \"@type\": \"https://didcomm.org/coprotocol/1.0/detach\",\n    \"~thread\": { \"pthid\": \"4d116a88-1314-4af5-9b3c-848456b8b3dd\"}\n}\n</code></pre> <p>A <code>caller</code> can re-attach by sending a new <code>bind</code> message; this time, the <code>co_binding_id</code> field should have the coprotocol binding id from the original <code>attach</code> message. Other fields in the message are optional; if present, they constitute a check that the binding in question has the properties the caller expects. The reattachment is confrimed by a new <code>attach</code> message.</p>"},{"location":"features/0482-coprotocol-protocol/#reference","title":"Reference","text":""},{"location":"features/0482-coprotocol-protocol/#bind","title":"<code>bind</code>","text":"<pre><code>{\n    \"@id\": \"4d116a88-1314-4af5-9b3c-848456b8b3dd\",\n    \"@type\": \"https://didcomm.org/coprotocol/1.0/bind\",\n    // I'd like to be bound to a coprotocol that achieves this goal.\n    \"goal_code\": \"aries.buy.make-payment\",\n    \"co_binding_id\": \n    // What is the intent about who plays which roles?\n    \"cast\": [\n        // Recipient of the bind message (id = null) should be payee.\n        {\"role\": \"payee\", \"id\": null},\n        // The payer will be did:peer:abc123.\n        {\"role\": \"payer\", \"id\": \"did:peer:abc123\" }\n    ],\n    // Optional and preferably omitted as it creates tight coupling;\n    // constrains bound coprotocol to just those that have a PIURI\n    // matching this wildcarded expression. \n    \"piuri_pat\": \"*/pay*\",\n    // If multiple matches are found, tells how to sort them to pick\n    // best match. \n    \"prefer\": [\n        // First prefer to bind a protocol that's often successful.\n        { \"attribute\": \"success_ratio\", \"direction\": \"d\" },\n        // Tie break by binding a protocol that's been run recently.\n        { \"attribute\": \"last_run_date\", \"direction\": \"d\" },\n        // Tie break by binding a protocol that's newer.\n        { \"attribute\": \"release_date\", \"direction\": \"d\" }\n        // Tie break by selecting protocols already running (false\n        // sorts before true).\n        { \"attribute\": \"running\", \"direction\": \"d\" }\n    ]\n}\n</code></pre>"},{"location":"features/0482-coprotocol-protocol/#attach","title":"<code>attach</code>","text":"<pre><code>{\n    \"@id\": \"b3dd4d11-6a88-9b3c-4af5-848456b81314\",\n    \"@type\": \"https://didcomm.org/coprotocol/1.0/attach\",\n    \"~thread\": { \"pthid\": \"4d116a88-1314-4af5-9b3c-848456b8b3dd\"},\n    // This is the best match.\n    \"piuri\": \"https://didcomm.org/pay-with-venmo/1.3\",\n    // Optional. Tells how long the caller has to take the next\n    // step binding will be held in an\n    // inactive state before being abandoned.\n    \"~timing.expires_time\": \"2020-06-23T18:42:07.124\"\n}\n</code></pre>"},{"location":"features/0482-coprotocol-protocol/#collateral","title":"Collateral","text":"<p>This section is optional. It could be used to reference files, code, relevant standards, oracles, test suites, or other artifacts that would be useful to an implementer. In general, collateral should be checked in with the RFC.</p>"},{"location":"features/0482-coprotocol-protocol/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"features/0482-coprotocol-protocol/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"features/0482-coprotocol-protocol/#prior-art","title":"Prior art","text":"<p>Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:</p> <ul> <li>Does this feature exist in other SSI ecosystems and what experience have their community had?</li> <li>For other teams: What lessons can we learn from other attempts?</li> <li>Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.</li> </ul> <p>This section is intended to encourage you as an author to think about the lessons from other implementers, provide readers of your proposal with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if they are an adaptation from other communities.</p> <p>Note that while precedent set by other communities is some motivation, it does not on its own motivate an enhancement proposal here. Please also take into consideration that Aries sometimes intentionally diverges from common identity ../../features.</p>"},{"location":"features/0482-coprotocol-protocol/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"features/0482-coprotocol-protocol/#implementations","title":"Implementations","text":"<p>NOTE: This section should remain in the RFC as is on first release. Remove this note and leave the rest of the text as is. Template text in all other sections should be replace.</p> <p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0496-transition-to-oob-and-did-exchange/","title":"Aries RFC 0496: Transition to the Out of Band Protocol","text":"<ul> <li>Authors: Stephen Curran</li> <li>Status: ADOPTED</li> <li>Since: 2021-11-24</li> <li>Status Note: In step 2 - All systems using OOB. Target Completion Date: 2024-07-02</li> <li>Supersedes:</li> <li>Start Date: 2020-06-07</li> <li>Tags: feature, community-update, test-anomaly</li> </ul>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#summary","title":"Summary","text":"<p>The Aries community has agreed to transition from using the <code>invitation</code> messages in RFC 0160 Connections and RFC 0023 DID Exchange to using the plaintext <code>invitation</code> message in RFC 0434 Out of Band and from using RFC 0160 to RFC 0023 for establishing agent-to-agent connections. As well, the community has agreed to transition from using RFC 0056 Service Decorator to execute connection-less instances of the RFC 0037 Present Proof protocol to using the out-of-band invitation message.</p> <p>This RFC follows the guidance in RFC 0345 about community-coordinated updates to (try to) ensure that independently deployed, interoperable agents remain interoperable throughout this transition.</p> <p>The transition from the old to new messages will occur in four steps:</p> <ul> <li>Pre-work: Agent builders agree on the transition plan outlined in this RFC and the target date for completing Step 1.</li> <li>Any RFC updates related to this transition needed before starting the transition are completed.</li> <li>Step 1: Agent builders update all agent code bases and deployments to accept incoming out-of-band messages requesting equivalent-to-current functionality.</li> <li>Equivalent-to-current functionality includes:<ul> <li>RFC 160 Connections invitations</li> <li>Connection-less Present Proof protocol instances using the service decorator</li> </ul> </li> <li>See the section below on Step 1 out-of-band messages</li> <li>During Step 1, all agents should continue to send the current invitation and connection-less protocol messages.</li> <li>Each agent builder SHOULD notify the community they have completed Step 1 by submitting a PR to update their entry in the implementations section of this RFC.</li> <li>Step 2: Agent builders update all agent code bases and deployments to send out out-of-band invitations equivalent to the current invitation and connection-less protocol messages, and Agent builders add full out-of-band protocol support to all agent code bases and deployments.</li> <li>Messages from existing RFCs being replaced by the out-of-band protocol are marked as <code>deprecated</code>.</li> <li>Full out-of-band support is NOT required\u2014just support for the out-of-band equivalents of the old <code>invitation</code> messages.</li> <li>When sending or receiving <code>did:peer</code> DIDs, the DIDs MUST conform to the Peer DID Specification.</li> <li>Each agent builder SHOULD notify the community they have completed Step 2 by submitting a PR to update their entry in the implementations section.</li> <li>Step 3: Support for the current invitation and connection-less protocol messages can be removed from all implementations and deployments, and all out-of-band <code>invitation</code> capabilities that align with the then current Aries Interop Profile (AIP) may be offered.</li> </ul>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#step-1-out-of-band-messages","title":"Step 1 Out-of-Band Messages","text":"<p>The definition of Step 1 has been deliberately defined to limit the impact of the changes on existing code bases. An implementation may be able to do as little as convert an incoming out-of-band protocol message into its \"current format\" equivalent and process the message, thus deferring larger changes to the message handling code. The following examples show the equivalence between out-of-band and current messages and the constraints on the out-of-band invitations used in Step 2.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#connection-invitationinline-diddoc-service-entry","title":"Connection Invitation\u2014Inline DIDDoc Service Entry","text":"<p>The following is the out-of-band <code>invitation</code> message equivalent to an RFC 0160 Connections <code>invitation</code> message that may be used in Step 2.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/1.0/invitation\",\n  \"@id\": \"1234-1234-1234-1234\",\n  \"label\": \"Faber College\",\n  \"goal_code\": \"establish-connection\",\n  \"goal\": \"To establish a connection\",\n  \"handshake_protocols\": [\"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/invitation\"],\n  \"service\": [\n      {\n        \"id\": \"#inline\"\n        \"type\": \"did-communication\",\n        \"recipientKeys\": [\"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"],\n        \"routingKeys\": [],\n        \"serviceEndpoint\": \"https://example.com:5000\"\n      }\n  ]\n}\n</code></pre> <p>The constraints on this form of the out-of-band <code>invitation</code> sent during Step 2 are:</p> <ul> <li><code>goal_code</code> and <code>goal</code> are ignored.</li> <li><code>handshake_protocols</code> MUST have exactly one entry and that entry must be <code>did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/invitation</code>.</li> <li><code>request~attach</code> MUST NOT be present.</li> <li><code>service</code> MUST have exactly one entry and be in the form above or be a single DID (but not both).</li> </ul> <p>This out-of-band message can be transformed to the following RFC 0160 Connection <code>invitation</code> message.</p> <pre><code>{\n  \"@type\": \"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/invitation\",\n  \"@id\": \"1234-1234-1234-1234\",\n  \"label\": \"Faber College\",\n  \"recipientKeys\": [\"6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"],\n  \"serviceEndpoint\": \"https://example.com:5000\",\n  \"routingKeys\": []\n}\n</code></pre> <p>Note the use of <code>did:key</code> in the out-of-band message and the \"naked\" public key in the connection message. Ideally, full support for <code>did:key</code> will be added during Step 1. However, if there is not time for an agent builder to add full support, the transformation can be accomplished using simple text transformations between the <code>did:key</code> format and the (only) public key format used in current Aries agents.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#connection-invitationdid-service-entry","title":"Connection Invitation\u2014DID Service Entry","text":"<p>If the out-of-band message <code>service</code> item is a single DID, the resulting transformed message is comparably different. For example, this out-of-band <code>invitation</code> message:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/invitation\",\n  \"@id\": \"&lt;id used for context as pthid&gt;\",\n  \"label\": \"Faber College\",\n  \"goal_code\": \"issue-vc\",\n  \"goal\": \"To issue a Faber College Graduate credential\",\n  \"handshake_protocols\": [\"https://didcomm.org/connections/1.0\"],\n  \"service\": [\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]\n}\n</code></pre> <p>The <code>did</code> form of the connection invitation is implied, as shown here:</p> <pre><code>{\n  \"@type\": \"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/invitation\",\n  \"@id\": \"1234-1234-1234-1234\",\n  \"label\": \"Faber College\",\n  \"did\": [\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]\n}\n</code></pre>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#connection-less-present-proof-request","title":"Connection-less Present Proof Request","text":"<p>The most common connection-less form being used in production is the <code>request-presentation</code> message from the RFC 0037 Present Proof protocol. The out-of-band invitation for that request looks like this, using the inline form of the service entry.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/invitation\",\n  \"@id\": \"1234-1234-1234-1234\",\n  \"label\": \"Faber College\",\n  \"goal_code\": \"present-proof\",\n  \"goal\": \"Request proof of some claims from verified credentials\",\n  \"request~attach\": [\n    {\n        \"@id\": \"request-0\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"json\": {\n                \"@type\": \"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/present-proof/1.0/request-presentation\",\n                \"@id\": \"&lt;uuid-request&gt;\",\n                \"comment\": \"some comment\",\n                \"request_presentations~attach\": [\n                    {\n                        \"@id\": \"libindy-request-presentation-0\",\n                        \"mime-type\": \"application/json\",\n                        \"data\":  {\n                            \"base64\": \"&lt;bytes for base64&gt;\"\n                        }\n                    }\n                ]\n            }\n        }\n    }\n  ],\n  \"service\": [\n      {\n        \"id\": \"#inline\",\n        \"type\": \"did-communication\",\n        \"recipientKeys\": [\"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"],\n        \"routingKeys\": [],\n        \"serviceEndpoint\": \"https://example.com:5000\"\n      }\n  ]\n}\n</code></pre> <p>The constraints on this form of the out-of-band <code>invitation</code> sent during Step 2 are:</p> <ul> <li><code>goal_code</code> is ignored and <code>goal</code> is used as the <code>comment</code>.</li> <li><code>handshake_protocols</code> MUST NOT be present.</li> <li><code>request~attach</code> MUST have exactly one entry and that entry must be a <code>request-presentation</code> message.</li> <li><code>service</code> MUST have exactly one entry and be in the form above or be a single DID (but not both).</li> </ul> <p>This out-of-band message can be transformed to the following RFC 0037 Present Proof <code>request-presentation</code> message with an RFC 0056 Service Decorator item.</p> <pre><code>{\n    \"@type\": \"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/present-proof/1.0/request-presentation\",\n    \"@id\": \"1234-1234-1234-1234\",\n    \"comment\": \"Request proof of some claims from verified credentials\",\n    \"~service\": {\n        \"recipientKeys\": [\"6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"],\n        \"routingKeys\": [],\n        \"serviceEndpoint\": \"https://example.com:5000\"\n    },\n    \"request_presentations~attach\": [\n        {\n            \"@id\": \"libindy-request-presentation-0\",\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>If the DID form of the out-of-band <code>invitation</code> message <code>service</code> entry was used, the <code>~service</code> item would be comparably altered.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#url-shortener-handling","title":"URL Shortener Handling","text":"<p>During Step 2 URL Shortening as defined in RFC 0434 Out of Band must be supported.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#between-step-triggers","title":"Between Step Triggers","text":"<p>The community coordination triggers between the steps above will be as follows:</p> <ul> <li>Pre-work to Step 1 - a PR to this RFC is merged that sets the RFC status to ACCEPTED.</li> <li>Step 1 to Step 2 - the community agrees that the majority of the deployed agents have completed Step 1. A PR to this RFC is merged that sets the RFC status to ADOPTED.</li> <li>Agent builders indicate completion of Step 1 by updating the Implementations section of this RFC.</li> <li>A PR to RFC 0160 Connections and RFC 0023 DID Exchange marks the <code>invitation</code> messages as deprecated.</li> <li>The ADOPTED version of this RFC is included in the then-current Aries Interop Profile version.</li> <li>Step 2 to Step 3 - the community agrees that the majority of the deployed agents have completed Step 2. A PR to this RFC is merged that sets the RFC status to RETIRED.</li> <li>Agent builders indicate completion of Step 2 by updating the Implementations section of this RFC.</li> </ul>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#motivation","title":"Motivation","text":"<p>To enable agent builders to independently update their code bases and deployed agents to support the out-of-band protocol while maintaining interoperability.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#tutorial","title":"Tutorial","text":"<p>The general mechanism for this type of transition is documented in RFC 0345 about community-coordinated updates.</p> <p>The specific sequence of events to make this particular transition is outlined in the summary section of this RFC.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#reference","title":"Reference","text":"<p>See the summary section of this RFC for the details of this transition.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#drawbacks","title":"Drawbacks","text":"<p>None identified.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>This approach balances the speed of adoption with the need for independent deployment and ongoing interoperability.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#prior-art","title":"Prior art","text":"<p>The approach outlined in RFC 0345 about community-coordinated updates is a well-known pattern for using deprecation to make breaking changes in an ecosystem. That said, this is the first attempt to use this approach in Aries. Adjustments to the transition plan will be made as needed, and RFC 0345 will be updated based on lessons learned in executing this plan.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Are the constraints on the proposed \"equivalent to existing\" messages sufficiently clear?</li> <li>Does the community want to support the connection-less <code>Issue Credential</code> process to be supported in Step 2?</li> </ul>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#implementations","title":"Implementations","text":"<p>The following table lists the status of various agent code bases and deployments with respect to Step 1 of this transition. Agent builders MUST update this table as they complete steps of the transition.</p> Name / Link Implementation Notes"},{"location":"features/0509-action-menu/","title":"Aries RFC 0509: Action Menu Protocol","text":"<ul> <li>Authors: [Andrew Whitehead],[Stephen Curran],[John Court]</li> <li>Status: DEMONSTRATED</li> <li>Since: 2020-07-02 </li> <li>Status Note: Implemented and demonstrated in the Aries Cloud Agent Python code base </li> <li>Supersedes: </li> <li>Start Date: 2020-06-24</li> <li>Tags: feature, protocol</li> <li>Protocol Name: action-menu</li> <li>Version: 1.0</li> <li>URI: <code>https://didcomm.org/action-menu/%VER</code></li> </ul>"},{"location":"features/0509-action-menu/#summary","title":"Summary","text":"<p>The action-menu protocol allows one Agent to present a set of heirarchical menus and actions to another user-facing Agent in a human friendly way. The protocol allows limited service discovery as well as simple data entry. While less flexible than HTML forms or a chat bot, it should be relatively easy to implement and provides a user interface which can be adapted for various platforms, including mobile agents.</p>"},{"location":"features/0509-action-menu/#motivation","title":"Motivation","text":"<p>Discovery of a peer Agent's capabilities or service offerings is currently reliant on knowledge obtained out-of-band.  There is no in-band DIDComm supported protocol for querying a peer to obtain a human freindly menu of their capabilities or service offerings. Whilst this protocol doesn't offer ledger wide discovery capabilities, it will allow one User Agent connected to another, to present a navigable menu and request offered services. The protocol also provides an interface definition language to define action menu display, selection and request submission.</p>"},{"location":"features/0509-action-menu/#tutorial","title":"Tutorial","text":""},{"location":"features/0509-action-menu/#name-and-version","title":"Name and Version","text":"<p><code>action-menu</code>, version 1.0</p>"},{"location":"features/0509-action-menu/#key-concepts","title":"Key Concepts","text":"<p>The action-menu protocol requires an active DIDComm connection before it can proceed.  One Agent behaves as a <code>requester</code> in the protocol whilst the other Agent represents a <code>responder</code>.  Conceptually the <code>responder</code> presents a list of actions which can be initiated by the <code>requester</code>. Actions are contained within a menu structure. Individual Actions may result in traversal to another menu or initiation of other Aries protocols such as a presentation request, an introduction proposal, a credential offer, an acknowledgement, or a problem report. </p> <p>The protocol can be initiated by either the <code>requester</code> asking for the root menu or the <code>responder</code> sending an unsolicited root menu.  The protocol ends when the <code>requester</code> issues a <code>perform</code> operation or an internal timeout on the <code>responder</code> causes it to discard menu context.  At any time a <code>requester</code> can reset the protocol by requesting the root menu from a <code>responder</code>.</p> <p>Whilst the protocol is defined here as uni-directional (i.e <code>requester</code> to <code>responder</code>), both Agents may support both <code>requester</code> and <code>responder</code> roles simultaneously. Such cases would result in two instances of the action-menu protocol operating in parrallel. </p>"},{"location":"features/0509-action-menu/#roles","title":"Roles","text":"<p>There are two roles in the action-menu protocol: <code>requester</code> and <code>responder</code>.</p> <p>The <code>requester</code> asks the <code>responder</code> for menu definitions, presents them to a user, and initiates subsequent action items from the menu through further requests to the <code>responder</code>.</p> <p>The <code>responder</code> presents an initial menu definition containing actionable elements to a <code>requestor</code> and then responds to subsequent action requests from the menu.  </p>"},{"location":"features/0509-action-menu/#states","title":"States","text":""},{"location":"features/0509-action-menu/#states-for-requester","title":"States for Requester","text":"State\u2003\u2003\u2003\u2003\u2003\u2003\u2003\u2003 Description null No menu has been requested or received awaiting-root-menu menu-request message has been sent and awaiting root menu response preparing-selection menu message has been received and a user selection is pending done perform message has been sent and protocol has finished. Perform actions can include requesting a new menu which will re-enter the state machine with the receive-menu event from the null state."},{"location":"features/0509-action-menu/#states-for-responder","title":"States for Responder","text":"State\u2003\u2003\u2003\u2003\u2003\u2003\u2003\u2003 Description null No menu has been requested or sent preparing-root-menu menu-request message has been received and preparing menu response for root menu awaiting-selection menu message has been sent and are awaiting a perform request done perform message has been received and protocol has finished. Perform actions can include requesting a new menu which will re-enter the state machine with the send-menu event from the null state."},{"location":"features/0509-action-menu/#messages","title":"Messages","text":""},{"location":"features/0509-action-menu/#menu","title":"menu","text":"<p>A <code>requestor</code> is expected to display only one active menu per connection when action menus are employed by the <code>responder</code>. A newly received menu is not expected to interrupt a user, but rather be made available for the user to inspect possible actions related to the <code>responder</code>.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/action-menu/%VER/menu\",\n  \"@id\": \"5678876542344\",\n  \"title\": \"Welcome to IIWBook\",\n  \"description\": \"IIWBook facilitates connections between attendees by verifying attendance and distributing connection invitations.\",\n  \"errormsg\": \"No IIWBook names were found.\",\n  \"options\": [\n    {\n      \"name\": \"obtain-email-cred\",\n      \"title\": \"Obtain a verified email credential\",\n      \"description\": \"Connect with the BC email verification service to obtain a verified email credential\"\n    },\n    {\n      \"name\": \"verify-email-cred\",\n      \"title\": \"Verify your participation\",\n      \"description\": \"Present a verified email credential to identify yourself\"\n    },\n    {\n      \"name\": \"search-introductions\",\n      \"title\": \"Search introductions\",\n      \"description\": \"Your email address must be verified to perform a search\",\n      \"disabled\": true\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0509-action-menu/#description-of-attributes","title":"Description of attributes","text":"<ul> <li><code>title</code> -- plain text string, should be displayed at the top of the menu</li> <li><code>description</code> -- plain text string, should be shown in smaller text below the title bar</li> <li><code>errormsg</code> -- optional plain text string sent to indicate that the last perform request did not work as expected. The text should be presented to the user in the title section</li> <li><code>options</code> -- one or more available actions which the <code>responder</code> supports and may be requested in a perform message.  </li> <li><code>disabled</code> -- optional indication that an option is unavailable due to certain requirements not yet being met</li> </ul>"},{"location":"features/0509-action-menu/#quick-forms","title":"Quick forms","text":"<p>Menu options may define a form property, which would direct the <code>requester</code> user to a client-generated form when the menu option is selected. The menu title should be shown at the top of the form, followed by the form description text if defined, followed by the list of form <code>params</code> in sequence. The form should also include a Cancel button to return to the menu, a Submit button (with an optional custom label defined by <code>submit-label</code>), and optionally a Clear button to reset the parameters to their default values.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/action-menu/%VER/menu\",\n  \"@id\": \"5678876542347\",\n  \"~thread\": {\n    \"thid\": \"5678876542344\"\n  },\n  \"title\": \"Attendance Verified\",\n  \"description\": \"\",\n  \"options\": [\n    {\n      \"name\": \"submit-invitation\",\n      \"title\": \"Submit an invitation\",\n      \"description\": \"Send an invitation for IIWBook to share with another participant\"\n    },\n    {\n      \"name\": \"search-introductions\",\n      \"title\": \"Search introductions\",\n      \"form\": {\n        \"description\": \"Enter a participant name below to perform a search.\",\n        \"params\": [\n          {\n            \"name\": \"query\",\n            \"title\": \"Participant name\",\n            \"default\": \"\",\n            \"description\": \"\",\n            \"required\": true,\n            \"type\": \"text\"\n          }\n        ],\n        \"submit-label\": \"Search\"\n      }\n    }\n  ]\n}\n</code></pre> <p>When the form is submitted, a perform message is generated containing values entered in the form. The <code>form</code> block may have an empty or missing <code>params</code> property in which case it acts as a simple confirmation dialog.</p> <p>Each entry in the <code>params</code> list must define a <code>name</code> and <code>title</code>. The <code>description</code> is optional (should be displayed as help text below the field) and the <code>type</code> defaults to \u2018text\u2019 if not provided (only the \u2018text\u2019 type is supported at this time). Parameters should default to <code>required</code> true, if not specified. Parameters may also define a <code>default</code> value (used when rendering or clearing the form).</p>"},{"location":"features/0509-action-menu/#menu-request","title":"menu-request","text":"<p>In addition to menus being pushed by the <code>responder</code>, the root menu can be re-requested at any time by the <code>requestor</code> sending a menu-request.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/action-menu/%VER/menu-request\",\n  \"@id\": \"5678876542345\"\n}\n</code></pre>"},{"location":"features/0509-action-menu/#perform","title":"perform","text":"<p>When the <code>requestor</code> user actions a menu option, a perform message is generated. It should be attached to the same thread as the menu. The active menu should close when an option is selected.</p> <p>The response to a perform message can be any type of agent message, including another menu message, a presentation request, an introduction proposal, a credential offer, an acknowledgement, or a problem report. Whatever the message type, it should normally reference the same message thread as the perform message.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/action-menu/%VER/perform\",\n  \"@id\": \"5678876542346\",\n  \"~thread\": {\n    \"thid\": \"5678876542344\"\n  },\n  \"name\": \"obtain-email-cred\",\n  \"params\": {}\n}\n</code></pre>"},{"location":"features/0509-action-menu/#description-of-attributes_1","title":"Description of attributes","text":"<ul> <li><code>name</code> -- the menu option being requested. This is taken from the <code>name</code> attribute of the <code>options</code> array elements in the menu </li> <li><code>params</code> -- optional dictionary containing any input parameters requested in a menu option <code>form</code> section.  The dictionary key values are taken from the <code>name</code> attributes of <code>params</code> array elements in the menu option <code>form</code>.</li> </ul>"},{"location":"features/0509-action-menu/#drawbacks","title":"Drawbacks","text":"<p>N/A </p>"},{"location":"features/0509-action-menu/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>N/A </p>"},{"location":"features/0509-action-menu/#prior-art","title":"Prior art","text":"<p>There are several existing RFCs that relate to the general problem of \"Discovery\" </p> <ul> <li>Aries RFC 0031 : Discover Features Protocol 1.0 -- This RFC provides Aries Protocol discovery between two Agents but no direction on user interface display or action handling.</li> <li>Aries RFC 0214 : \"Help Me Discover\" Protocol -- This RFC introduces the concept of a query language protocol between agents to obtain \"referal\" to a third agent. </li> </ul>"},{"location":"features/0509-action-menu/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>There needs to be some consideration around how the protocol may terminate due to <code>responder</code> side timeouts since maintaining menu context for connections consumes resources. Adoption of Aries RFC 0035 : Report Problem Protocol 1.0 is a viable solution</li> </ul>"},{"location":"features/0509-action-menu/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python MISSING test results"},{"location":"features/0510-dif-pres-exch-attach/","title":"Aries RFC 0510: Presentation-Exchange Attachment format for requesting and presenting proofs","text":"<ul> <li>Authors: George Aristy (SecureKey Technologies)</li> <li>Status: ADOPTED</li> <li>Since: 2020-07-21</li> <li>Status Note:  </li> <li>Supersedes: </li> <li>Start Date: 2020-07-21</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0510-dif-pres-exch-attach/#summary","title":"Summary","text":"<p>This RFC registers three attachment formats for use in the present-proof V2 protocol based on the Decentralized Identity Foundation's (DIF) Presentation Exchange specification (P-E). Two of these formats define containers for a presentation-exchange request object and another options object carrying additional parameters, while the third format is just a vessel for the final <code>presentation_submission</code> verifiable presentation transferred from the Prover to the Verifier.</p> <p>Presentation Exchange defines a data format capable of articulating a rich set of proof requirements from Verifiers, and also provides a means of describing the formats in which Provers must submit those proofs.</p> <p>A Verifier's defines their requirements in a <code>presentation_definition</code> containing <code>input_descriptors</code> that describe the credential(s) the proof(s) must be derived from as well as a rich set of operators that place <code>constraints</code> on those proofs (eg. \"must be issued from issuer X\" or \"<code>age</code> over X\", etc.).</p> <p>The Verifiable Presentation format of Presentation Submissions is used as opposed to OIDC tokens or CHAPI objects. For an alternative on how to tunnel OIDC messages over DIDComm, see HTTP-Over-DIDComm. CHAPI is an alternative transport to DIDComm.</p>"},{"location":"features/0510-dif-pres-exch-attach/#motivation","title":"Motivation","text":"<p>The Presentation Exchange specification (P-E) possesses a rich language for expressing a Verifier's criterion.</p> <p>P-E lends itself well to several transport mediums due to its limited scope as a data format, and is easily transported over DIDComm.</p> <p>It is furthermore desirable to make use of specifications developed in an open standards body.</p>"},{"location":"features/0510-dif-pres-exch-attach/#tutorial","title":"Tutorial","text":"<p>Complete examples of messages are provided in the reference section.</p> <p>The Verifier sends a <code>request-presentation</code> to the Prover containing a <code>presentation_definition</code>, along with a <code>domain</code> and <code>challenge</code> the Prover must sign over in the proof.</p> <p>The Prover can optionally respond to the Verifier's <code>request-presentation</code> with a <code>propose-presentation</code> message containing \"Input Descriptors\" that describe the proofs they can provide. The contents of the attachment is just the <code>input_descriptors</code> attribute of the <code>presentation_definition</code> object.</p> <p>The Prover responds with a <code>presentation</code> message containing a <code>presentation_submission</code>.</p>"},{"location":"features/0510-dif-pres-exch-attach/#reference","title":"Reference","text":""},{"location":"features/0510-dif-pres-exch-attach/#propose-presentation-attachment-format","title":"<code>propose-presentation</code> attachment format","text":"<p>Format identifier: <code>dif/presentation-exchange/definitions@v1.0</code></p>"},{"location":"features/0510-dif-pres-exch-attach/#examples-propose-presentation","title":"Examples: propose-presentation","text":"Complete message example <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/propose-presentation\",\n    \"@id\": \"fce30ed1-96f8-44c9-95cf-b274288009dc\",\n    \"comment\": \"some comment\",\n    \"formats\" : [{\n        \"attach_id\" : \"143c458d-1b1c-40c7-ab85-4d16808ddf0a\",\n        \"format\" : \"dif/presentation-exchange/definitions@v1.0\"\n    }],\n    \"proposal~attach\": [{\n        \"@id\": \"143c458d-1b1c-40c7-ab85-4d16808ddf0a\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"json\": {\n                \"input_descriptors\": [{\n                    \"id\": \"citizenship_input\",\n                    \"name\": \"US Passport\",\n                    \"group\": [\"A\"],\n                    \"schema\": [{\n                        \"uri\": \"hub://did:foo:123/Collections/schema.us.gov/passport.json\"\n                    }],\n                    \"constraints\": {\n                        \"fields\": [{\n                            \"path\": [\"$.credentialSubject.birth_date\", \"$.vc.credentialSubject.birth_date\", \"$.birth_date\"],\n                            \"filter\": {\n                                \"type\": \"date\",\n                                \"minimum\": \"1999-5-16\"\n                            }\n                        }]\n                    }\n                }]\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"features/0510-dif-pres-exch-attach/#request-presentation-attachment-format","title":"<code>request-presentation</code> attachment format","text":"<p>Format identifier: <code>dif/presentation-exchange/definitions@v1.0</code></p> <p>Since the format identifier defined above is the same as the one used in the <code>propose-presentation</code> message, it's recommended to consider both the message <code>@type</code> and the <code>format</code> to accuarately understand the contents of the attachment.</p> <p>The contents of the attachment is a JSON object containing the Verifier's presentation definition and an options object with proof options:</p> <pre><code>{\n    \"options\": {\n        \"challenge\": \"...\",\n        \"domain\": \"...\",\n    },\n    \"presentation_definition\": {\n        // presentation definition object\n    }\n}\n</code></pre>"},{"location":"features/0510-dif-pres-exch-attach/#the-options-object","title":"The options object","text":"<p>options is a container of additional parameters required for the Prover to fulfill the Verifier's request.</p> <p>Available options are:</p> Name Status Description <code>challenge</code> RECOMMENDED (for LD proofs) Random seed provided by the Verifier for LD Proofs. <code>domain</code> RECOMMENDED (for LD proofs) The operational domain of the requested LD proof."},{"location":"features/0510-dif-pres-exch-attach/#examples-request-presentation","title":"Examples: request-presentation","text":"Complete message example requesting a verifiable presentation with proof type Ed25519Signature2018 <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/request-presentation\",\n    \"@id\": \"0ac534c8-98ed-4fe3-8a41-3600775e1e92\",\n    \"comment\": \"some comment\",\n    \"formats\" : [{\n        \"attach_id\" : \"ed7d9b1f-9eed-4bde-b81c-3aa7485cf947\",\n        \"format\" : \"dif/presentation-exchange/definitions@v1.0\"\n    }],\n    \"request_presentations~attach\": [{\n        \"@id\": \"ed7d9b1f-9eed-4bde-b81c-3aa7485cf947\",\n        \"mime-type\": \"application/json\",\n        \"data\":  {\n            \"json\": {\n                \"options\": {\n                    \"challenge\": \"23516943-1d79-4ebd-8981-623f036365ef\",\n                    \"domain\": \"us.gov/DriversLicense\"\n                },\n                \"presentation_definition\": {\n                    \"input_descriptors\": [{\n                        \"id\": \"citizenship_input\",\n                        \"name\": \"US Passport\",\n                        \"group\": [\"A\"],\n                        \"schema\": [{\n                            \"uri\": \"hub://did:foo:123/Collections/schema.us.gov/passport.json\"\n                        }],\n                        \"constraints\": {\n                            \"fields\": [{\n                                \"path\": [\"$.credentialSubject.birth_date\", \"$.birth_date\"],\n                                \"filter\": {\n                                    \"type\": \"date\",\n                                    \"minimum\": \"1999-5-16\"\n                                }\n                            }]\n                        }\n                    }],\n                    \"format\": {\n                        \"ldp_vp\": {\n                            \"proof_type\": [\"Ed25519Signature2018\"]\n                        }\n                    }\n                }\n            }\n        }\n    }]\n}\n</code></pre> The same example but requesting the verifiable presentation with proof type BbsBlsSignatureProof2020 instead <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/request-presentation\",\n    \"@id\": \"0ac534c8-98ed-4fe3-8a41-3600775e1e92\",\n    \"comment\": \"some comment\",\n    \"formats\" : [{\n        \"attach_id\" : \"ed7d9b1f-9eed-4bde-b81c-3aa7485cf947\",\n        \"format\" : \"dif/presentation-exchange/definitions@v1.0\"\n    }],\n    \"request_presentations~attach\": [{\n        \"@id\": \"ed7d9b1f-9eed-4bde-b81c-3aa7485cf947\",\n        \"mime-type\": \"application/json\",\n        \"data\":  {\n            \"json\": {\n                \"options\": {\n                    \"challenge\": \"23516943-1d79-4ebd-8981-623f036365ef\",\n                    \"domain\": \"us.gov/DriversLicense\"\n                },\n                \"presentation_definition\": {\n                    \"input_descriptors\": [{\n                        \"id\": \"citizenship_input\",\n                        \"name\": \"US Passport\",\n                        \"group\": [\"A\"],\n                        \"schema\": [{\n                            \"uri\": \"hub://did:foo:123/Collections/schema.us.gov/passport.json\"\n                        }],\n                        \"constraints\": {\n                            \"fields\": [{\n                                \"path\": [\"$.credentialSubject.birth_date\", \"$.vc.credentialSubject.birth_date\", \"$.birth_date\"],\n                                \"filter\": {\n                                    \"type\": \"date\",\n                                    \"minimum\": \"1999-5-16\"\n                                }\n                            }],\n                            \"limit_disclosure\": \"required\"\n                        }\n                    }],\n                    \"format\": {\n                        \"ldp_vc\": {\n                            \"proof_type\": [\"BbsBlsSignatureProof2020\"]\n                        }\n                    }\n                }\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"features/0510-dif-pres-exch-attach/#presentation-attachment-format","title":"<code>presentation</code> attachment format","text":"<p>Format identifier: <code>dif/presentation-exchange/submission@v1.0</code></p> <p>The contents of the attachment is a Presentation Submission in a standard Verifiable Presentation format containing the proofs requested.</p>"},{"location":"features/0510-dif-pres-exch-attach/#examples-presentation","title":"Examples: presentation","text":"Complete message example <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/presentation\",\n    \"@id\": \"f1ca8245-ab2d-4d9c-8d7d-94bf310314ef\",\n    \"comment\": \"some comment\",\n    \"formats\" : [{\n        \"attach_id\" : \"2a3f1c4c-623c-44e6-b159-179048c51260\",\n        \"format\" : \"dif/presentation-exchange/submission@v1.0\"\n    }],\n    \"presentations~attach\": [{\n        \"@id\": \"2a3f1c4c-623c-44e6-b159-179048c51260\",\n        \"mime-type\": \"application/ld+json\",\n        \"data\": {\n            \"json\": {\n                \"@context\": [\n                    \"https://www.w3.org/2018/credentials/v1\",\n                    \"https://identity.foundation/presentation-exchange/submission/v1\"\n                ],\n                \"type\": [\n                    \"VerifiablePresentation\",\n                    \"PresentationSubmission\"\n                ],\n                \"presentation_submission\": {\n                    \"descriptor_map\": [{\n                        \"id\": \"citizenship_input\",\n                        \"path\": \"$.verifiableCredential.[0]\"\n                    }]\n                },\n                \"verifiableCredential\": [{\n                    \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n                    \"id\": \"https://eu.com/claims/DriversLicense\",\n                    \"type\": [\"EUDriversLicense\"],\n                    \"issuer\": \"did:foo:123\",\n                    \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n                    \"credentialSubject\": {\n                        \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n                        \"license\": {\n                            \"number\": \"34DGE352\",\n                            \"dob\": \"07/13/80\"\n                        }\n                    },\n                    \"proof\": {\n                        \"type\": \"RsaSignature2018\",\n                        \"created\": \"2017-06-18T21:19:10Z\",\n                        \"proofPurpose\": \"assertionMethod\",\n                        \"verificationMethod\": \"https://example.edu/issuers/keys/1\",\n                        \"jws\": \"...\"\n                    }\n                }],\n                \"proof\": {\n                    \"type\": \"RsaSignature2018\",\n                    \"created\": \"2018-09-14T21:19:10Z\",\n                    \"proofPurpose\": \"authentication\",\n                    \"verificationMethod\": \"did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1\",\n                    \"challenge\": \"1f44d55f-f161-4938-a659-f8026467f126\",\n                    \"domain\": \"4jt78h47fh47\",\n                    \"jws\": \"...\"\n                }\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"features/0510-dif-pres-exch-attach/#supported-features-of-presentation-exchange","title":"Supported Features of Presentation-Exchange","text":"<p>Level of support for Presentation-Exchange ../../features:</p> Feature Notes <code>presentation_definition.input_descriptors.id</code> <code>presentation_definition.input_descriptors.name</code> <code>presentation_definition.input_descriptors.purpose</code> <code>presentation_definition.input_descriptors.schema.uri</code> URI for the credential's schema. <code>presentation_definition.input_descriptors.constraints.fields.path</code> Array of JSONPath string expressions as defined in section 8. REQUIRED as per the spec. <code>presentation_definition.input_descriptors.constraints.fields.filter</code> JSONSchema descriptor. <code>presentation_definition.input_descriptors.constraints.limit_disclosure</code> <code>preferred</code> or <code>required</code> as defined in the spec and as supported by the Holder and Verifier proof mechanisms.Note that the Holder MUST have credentials with cryptographic proof suites that are capable of selective disclosure in order to respond to a request with <code>limit_disclosure: \"required\"</code>.See RFC0593 for appropriate crypto suites. <code>presentation_definition.input_descriptors.constraints.is_holder</code> <code>preferred</code> or <code>required</code> as defined in the spec.Note that this feature allows the Holder to present credentials with a different subject identifier than the DID used to establish the DIDComm connection with the Verifier. <code>presentation_definition.format</code> For JSONLD-based credentials: <code>ldp_vc</code> and <code>ldp_vp</code>. <code>presentation_definition.format.proof_type</code> For JSONLD-based credentials: <code>Ed25519Signature2018</code>, <code>BbsBlsSignature2020</code>, and <code>JsonWebSignature2020</code>. When specifying <code>ldp_vc</code>, <code>BbsBlsSignatureProof2020</code> may also be used."},{"location":"features/0510-dif-pres-exch-attach/#proof-formats","title":"Proof Formats","text":""},{"location":"features/0510-dif-pres-exch-attach/#constraints","title":"Constraints","text":"<p>Verifiable Presentations MUST be produced and consumed using the JSON-LD syntax.</p> <p>The proof types defined below MUST be registered in the Linked Data Cryptographic Suite Registry.</p> <p>The value of any <code>credentialSubject.id</code> in a credential MUST be a Dentralized Identifier (DID) conforming to the DID Syntax if present. This allows the Holder to authenticate as the credential's subject if required by the Verifier (see the <code>is_holder</code> property above). The Holder authenticates as the credential's subject by attaching an LD Proof on the enclosing Verifiable Presentation.</p>"},{"location":"features/0510-dif-pres-exch-attach/#proof-formats-on-credentials","title":"Proof Formats on Credentials","text":"<p>Aries agents implementing this RFC MUST support the formats outlined in RFC0593 for proofs on Verifiable Credentials.</p>"},{"location":"features/0510-dif-pres-exch-attach/#proof-formats-on-presentations","title":"Proof Formats on Presentations","text":"<p>Aries agents implementing this RFC MUST support the formats outlined below for proofs on Verifiable Presentations.</p>"},{"location":"features/0510-dif-pres-exch-attach/#ed25519signature2018","title":"Ed25519Signature2018","text":"<p>Specification.</p> <p>Request Parameters:</p> <ul> <li><code>presentation_definition.format</code>: <code>ldp_vp</code></li> <li><code>presentation_definition.format.proof_type</code>: <code>Ed25519Signature2018</code></li> <li><code>options.challenge</code>: (Optional) a random string value generated by the Verifier</li> <li><code>options.domain</code>: (Optional) a string value specified set by the Verifier</li> </ul> <p>Result:</p> <p>A Verifiable Presentation of type Presentation Submission containing the credentials requested under the <code>verifiableCredential</code> property and a <code>proof</code> property of type <code>Ed25519Signature2018</code>.</p> Example <pre><code>{\n    \"@context\": [\n        \"https://www.w3.org/2018/credentials/v1\",\n        \"https://identity.foundation/presentation-exchange/submission/v1\"\n    ],\n    \"type\": [\n        \"VerifiablePresentation\",\n        \"PresentationSubmission\"\n    ],\n    \"presentation_submission\": {\n        \"descriptor_map\": [{\n           \"id\": \"citizenship_input\",\n           \"path\": \"$.verifiableCredential.[0]\"\n        }]\n    },\n    \"verifiableCredential\": [{\n        \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n        \"id\": \"https://eu.com/claims/DriversLicense\",\n        \"type\": [\n            \"EUDriversLicense\"\n        ],\n        \"issuer\": \"did:foo:123\",\n        \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n        \"credentialSubject\": {\n            \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n            \"license\": {\n            \"number\": \"34DGE352\",\n            \"dob\": \"07/13/80\"\n          }\n        },\n        \"proof\": {\n            \"type\": \"RsaSignature2018\",\n            \"created\": \"2017-06-18T21:19:10Z\",\n            \"proofPurpose\": \"assertionMethod\",\n            \"verificationMethod\": \"https://example.edu/issuers/keys/1\",\n            \"jws\": \"...\"\n        }\n    }],\n    \"proof\": {\n      \"type\": \"Ed25519Signature2018\",\n      \"proofPurpose\": \"authentication\",\n      \"created\": \"2017-09-23T20:21:34Z\",\n      \"verificationMethod\": \"did:example:123456#key1\",\n      \"challenge\": \"2bbgh3dgjg2302d-d2b3gi423d42\",\n      \"domain\": \"example.org\",\n      \"jws\": \"eyJ0eXAiOiJK...gFWFOEjXk\"\n  }\n}\n</code></pre>"},{"location":"features/0510-dif-pres-exch-attach/#bbsblssignature2020","title":"BbsBlsSignature2020","text":"<p>Specification.</p> <p>Associated RFC: RFC0646.</p> <p>Request Parameters: * <code>presentation_definition.format</code>: <code>ldp_vp</code> * <code>presentation_definition.format.proof_type</code>: <code>BbsBlsSignature2020</code> * <code>options.challenge</code>: (Optional) a random string value generated by the Verifier * <code>options.domain</code>: (Optional) a string value specified set by the Verifier</p> <p>Result:</p> <p>A Verifiable Presentation of type Presentation Submission containing the credentials requested under the <code>verifiableCredential</code> property and a <code>proof</code> property of type <code>BbsBlsSignature2020</code>.</p> Example <pre><code>{\n    \"@context\": [\n        \"https://www.w3.org/2018/credentials/v1\",\n        \"https://w3id.org/security/v2\",\n        \"https://w3id.org/security/bbs/v1\",\n        \"https://identity.foundation/presentation-exchange/submission/v1\"\n    ],\n    \"type\": [\n        \"VerifiablePresentation\",\n        \"PresentationSubmission\"\n    ],\n    \"presentation_submission\": {\n        \"descriptor_map\": [{\n            \"id\": \"citizenship_input\",\n            \"path\": \"$.verifiableCredential.[0]\"\n        }]\n    },\n    \"verifiableCredential\": [{\n        \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n        \"id\": \"https://eu.com/claims/DriversLicense\",\n        \"type\": [\"EUDriversLicense\"],\n        \"issuer\": \"did:foo:123\",\n        \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n        \"credentialSubject\": {\n            \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n            \"license\": {\n                \"number\": \"34DGE352\",\n                \"dob\": \"07/13/80\"\n            }\n       },\n       \"proof\": {\n           \"type\": \"BbsBlsSignatureProof2020\",\n           \"created\": \"2020-04-25\",\n           \"verificationMethod\": \"did:example:489398593#test\",\n           \"proofPurpose\": \"assertionMethod\",\n           \"signature\": \"F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg==\"\n       }\n    }],\n    \"proof\": {\n        \"type\": \"BbsBlsSignature2020\",\n        \"created\": \"2020-04-25\",\n        \"verificationMethod\": \"did:example:489398593#test\",\n        \"proofPurpose\": \"authentication\",\n        \"proofValue\": \"F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg==\",\n        \"requiredRevealStatements\": [ 4, 5 ]\n    }\n}\n</code></pre> <p>Note: The above example is for illustrative purposes. In particular, note that whether a Verifier requests a <code>proof_type</code> of <code>BbsBlsSignature2020</code> has no bearing on whether the Holder is required to present credentials with proofs of type <code>BbsBlsSignatureProof2020</code>. The choice of proof types on the credentials is constrained by a) the available types registered in RFC0593 and b) additional constraints placed on them due to other aspects of the proof requested by the Verifier, such as requiring limited disclosure with the <code>limit_disclosure</code> property. In such a case, a proof type of <code>Ed25519Signature2018</code> in the credentials is not appropriate whereas <code>BbsBlsSignatureProof2020</code> is capable of selective disclosure.</p>"},{"location":"features/0510-dif-pres-exch-attach/#jsonwebsignature2020","title":"JsonWebSignature2020","text":"<p>Specification.</p> <p>Request Parameters:</p> <ul> <li><code>presentation_definition.format</code>: <code>ldp_vp</code></li> <li><code>presentation_definition.format.proof_type</code>: <code>JsonWebSignature2020</code></li> <li><code>options.challenge</code>: (Optional) a random string value generated by the Verifier</li> <li><code>options.domain</code>: (Optional) a string value specified set by the Verifier</li> </ul> <p>Result:</p> <p>A Verifiable Presentation of type Presentation Submission containing the credentials requested under the <code>verifiableCredential</code> property and a <code>proof</code> property of type <code>JsonWebSignature2020</code>.</p> Example <pre><code>{\n    \"@context\": [\n        \"https://www.w3.org/2018/credentials/v1\",\n        \"https://identity.foundation/presentation-exchange/submission/v1\"\n    ],\n    \"type\": [\n        \"VerifiablePresentation\",\n        \"PresentationSubmission\"\n    ],\n    \"presentation_submission\": {\n        \"descriptor_map\": [{\n           \"id\": \"citizenship_input\",\n           \"path\": \"$.verifiableCredential.[0]\"\n        }]\n    },\n    \"verifiableCredential\": [{\n        \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n        \"id\": \"https://eu.com/claims/DriversLicense\",\n        \"type\": [\n            \"EUDriversLicense\"\n        ],\n        \"issuer\": \"did:foo:123\",\n        \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n        \"credentialSubject\": {\n            \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n            \"license\": {\n            \"number\": \"34DGE352\",\n            \"dob\": \"07/13/80\"\n          }\n        },\n        \"proof\": {\n            \"type\": \"RsaSignature2018\",\n            \"created\": \"2017-06-18T21:19:10Z\",\n            \"proofPurpose\": \"assertionMethod\",\n            \"verificationMethod\": \"https://example.edu/issuers/keys/1\",\n            \"jws\": \"...\"\n        }\n    }],\n    \"proof\": {\n      \"type\": \"JsonWebSignature2020\",\n      \"proofPurpose\": \"authentication\",\n      \"created\": \"2017-09-23T20:21:34Z\",\n      \"verificationMethod\": \"did:example:123456#key1\",\n      \"challenge\": \"2bbgh3dgjg2302d-d2b3gi423d42\",\n      \"domain\": \"example.org\",\n      \"jws\": \"eyJ0eXAiOiJK...gFWFOEjXk\"\n  }\n}\n</code></pre> <p>Available JOSE key types are:</p> kty crv signature EC P-256 ES256 EC P-384 ES384"},{"location":"features/0510-dif-pres-exch-attach/#drawbacks","title":"Drawbacks","text":"<p>N/A</p>"},{"location":"features/0510-dif-pres-exch-attach/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>The <code>hlindy-zkp-v1.0</code> format is an alternative restricted to the Hyperledger Indy network.</li> </ul>"},{"location":"features/0510-dif-pres-exch-attach/#prior-art","title":"Prior art","text":"<ul> <li>OAuth 2.0 Rich Authorization Requests:   Provides a coarse object structure that implementers must extend to support their needs. Presentation Exchange   provides a rich set of operators out of the box.</li> </ul>"},{"location":"features/0510-dif-pres-exch-attach/#unresolved-questions","title":"Unresolved questions","text":"<p>TODO it is assumed the Verifier will initiate the protocol if they can transmit their presentation definition via an out-of-band channel  (eg. it is published on their website) with a <code>request-presentation</code> message, possibly delivered via an Out-of-Band invitation  (see RFC0434). For now, the Prover sends <code>propose-presentation</code> as a response to <code>request-presentation</code>.</p>"},{"location":"features/0510-dif-pres-exch-attach/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0511-dif-cred-manifest-attach/","title":"Aries RFC 0511: Credential-Manifest Attachment format for requesting and presenting credentials","text":"<ul> <li>Authors: George Aristy (SecureKey Technologies)</li> <li>Status: PROPOSED</li> <li>Since: 2020-07-22</li> <li>Status Note:</li> <li>Supersedes:</li> <li>Start Date: 2020-07-22</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0511-dif-cred-manifest-attach/#summary","title":"Summary","text":"<p>This RFC registers an attachment format for use in the issue-credential V2 based on the Decentralized Identity Foundation's (DIF) Credential Manifest specification. Credental Manifest describes a data format that specifies the inputs an Issuer requires for issuance of a credential. It relies on the closely-related Presentation Exchange specification to describe the required inputs and the format in which the Holder submits those inputs (a verifiable presentation).</p>"},{"location":"features/0511-dif-cred-manifest-attach/#motivation","title":"Motivation","text":"<p>The Credential Manifest specification lends itself well to several transport mediums due to its limited scope as a data format, and is easily transported over DIDComm.</p> <p>It is furthermore desirable to make use of specifications developed in an open standards body.</p>"},{"location":"features/0511-dif-cred-manifest-attach/#tutorial","title":"Tutorial","text":"<p>Complete examples of messages are provided in the reference section.</p> <p>Credential Manifests MAY be acquired by the Holder via out of band means, such as from a well-known location on the Issuer's website. This allows the Holder to initiate the <code>issue-credential</code> protocol with a <code>request-message</code> providing they also possess the requisite <code>challenge</code> and <code>domain</code> values. If they do not possess these values then the Issuer MAY respond with an <code>offer-credential</code> message.</p> <p>Otherwise the Holder MAY initiate the protocol with <code>propose-credential</code> in order to discover the Issuer's requirements.</p>"},{"location":"features/0511-dif-cred-manifest-attach/#reference","title":"Reference","text":""},{"location":"features/0511-dif-cred-manifest-attach/#propose-credential-attachment-format","title":"<code>propose-credential</code> attachment format","text":"<p>Format identifier: <code>dif/credential-manifest@v1.0</code></p> <p>The contents of the attachment is the minimal form of the Issuer's credential manifest describing the credential the Holder desires. It SHOULD contain the <code>issuer</code> and <code>credential</code> properties and no more.</p> <p>Complete message example:</p> <pre><code>{\n    \"@id\": \"8639505e-4ec5-41b9-bb31-ac6a7b800fe7\",\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/propose-credential\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\" : [{\n        \"attach_id\": \"b45ca1bc-5b3c-4672-a300-84ddf6fbbaea\",\n        \"format\": \"dif/credential-manifest@v1.0\"\n    }],\n    \"filters~attach\": [{\n        \"@id\": \"b45ca1bc-5b3c-4672-a300-84ddf6fbbaea\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"json\": {\n                \"issuer\": \"did:example:123\",\n                \"credential\": {\n                    \"name\": \"Washington State Class A Commercial Driver License\",\n                    \"schema\": \"ipfs:QmPXME1oRtoT627YKaDPDQ3PwA8tdP9rWuAAweLzqSwAWT\"\n                }\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"features/0511-dif-cred-manifest-attach/#offer-credential-attachment-format","title":"<code>offer-credential</code> attachment format","text":"<p>Format identifier: <code>dif/credential-manifest@v1.0</code></p> <p>The contents of the attachment is a JSON object containing the Issuer's credential manifest, a challenge and domain. All three attributes are REQUIRED.</p> <p>Example:</p> <pre><code>{\n    \"@id\": \"dfedaad3-bd7a-4c33-8337-fa94a547c0e2\",\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/offer-credential\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\" : [{\n        \"attach_id\" : \"76cd0d94-8eb6-4ef3-a094-af45d81e9528\",\n        \"format\" : \"dif/credential-manifest@v1.0\"\n    }],\n    \"offers~attach\": [{\n        \"@id\": \"76cd0d94-8eb6-4ef3-a094-af45d81e9528\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"json\": {\n                \"challenge\": \"1f44d55f-f161-4938-a659-f8026467f126\",\n                \"domain\": \"us.gov/DriverLicense\",\n                \"credential_manifest\": {\n                    // credential manifest object\n                }\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"features/0511-dif-cred-manifest-attach/#request-credential-attachment-format","title":"<code>request-credential</code> attachment format","text":"<p>Format identifier: <code>dif/credential-manifest@v1.0</code></p> <p>The contents of the attachment is a JSON object that describes the credential requested and provides the inputs the Issuer requires from the Holder before proceeding with issuance:</p> <pre><code>{\n    \"credential-manifest\": {\n        \"issuer\": \"did:example:123\",\n        \"credential\": {\n            \"name\": \"Washington State Class A Commercial Driver License\",\n            \"schema\": \"ipfs:QmPXME1oRtoT627YKaDPDQ3PwA8tdP9rWuAAweLzqSwAWT\"\n        }\n    },\n    \"presentation-submission\": {\n        // presentation submission object\n    }\n}\n</code></pre> <ul> <li><code>credential-manifest</code>: OPTIONAL. Required if the Holder starts the protocol with <code>request-credential</code>.</li> <li><code>presentation-submission</code>: OPTIONAL. Required as a response to the <code>presentation_definition</code> attribute in the Issuer's credential manifest, if present.</li> </ul> <p>If the Issuer's credential manifest does not include the <code>presentation_definition</code> attribute, and the Holder has initiated the protocol with <code>propose-credential</code>, then this attachment MAY be omitted entirely as the message thread provides sufficient context for this request.</p> <p>Implementors are STRONGLY discouraged from allowing BOTH <code>credential-manifest</code> and <code>presentation-submission</code>. The latter requires the Holder's knowledge of the necessary <code>challenge</code> and <code>domain</code>, both of which SHOULD provide sufficient context to the Issuer as to which credential is being requested.</p> <p>The following example shows a <code>request-credential</code> with a presentation submission. Notice the presentation's <code>proof</code> includes the <code>challenge</code> and <code>domain</code> acquired either through out-of-band means or via an <code>offer-credential</code> message.:</p> <pre><code>{\n    \"@id\": \"cf3a9301-6d4a-430f-ae02-b4a79ddc9706\",\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/request-credential\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\": [{\n        \"attach_id\": \"7cd11894-838a-45c0-a9ec-13e2d9d125a1\",\n        \"format\": \"dif/credential-manifest@v1.0\"\n    }],\n    \"requests~attach\": [{\n        \"@id\": \"7cd11894-838a-45c0-a9ec-13e2d9d125a1\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"json\": {\n                \"presentation-submission\": {\n                    \"@context\": [\n                        \"https://www.w3.org/2018/credentials/v1\",\n                        \"https://identity.foundation/presentation-exchange/submission/v1\"\n                    ],\n                    \"type\": [\n                        \"VerifiablePresentation\",\n                        \"PresentationSubmission\"\n                    ],\n                    \"presentation_submission\": {\n                        \"descriptor_map\": [{\n                            \"id\": \"citizenship_input\",\n                            \"path\": \"$.verifiableCredential.[0]\"\n                        }]\n                    },\n                    \"verifiableCredential\": [{\n                        \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n                        \"id\": \"https://us.gov/claims/Passport/723c62ab-f2f0-4976-9ec1-39992e20c9b1\",\n                        \"type\": [\"USPassport\"],\n                        \"issuer\": \"did:foo:123\",\n                        \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n                        \"credentialSubject\": {\n                            \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n                            \"birth_date\": \"2000-08-14\"\n                        },\n                        \"proof\": {\n                            \"type\": \"EcdsaSecp256k1VerificationKey2019\",\n                            \"created\": \"2017-06-18T21:19:10Z\",\n                            \"proofPurpose\": \"assertionMethod\",\n                            \"verificationMethod\": \"https://example.edu/issuers/keys/1\",\n                            \"jws\": \"...\"\n                        }\n                    }],\n                    \"proof\": {\n                        \"type\": \"RsaSignature2018\",\n                        \"created\": \"2018-09-14T21:19:10Z\",\n                        \"proofPurpose\": \"authentication\",\n                        \"verificationMethod\": \"did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1\",\n                        \"challenge\": \"1f44d55f-f161-4938-a659-f8026467f126\",\n                        \"domain\": \"us.gov/DriverLicense\",\n                        \"jws\": \"...\"\n                    }\n                }\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"features/0511-dif-cred-manifest-attach/#issue-credential-attachment-format","title":"<code>issue-credential</code> attachment format","text":"<p>This specification does not register any format identifier for the <code>issue-credential</code> message. The Issuer SHOULD set the <code>format</code> to the value that corresponds to the format the credentials are issued in.</p>"},{"location":"features/0511-dif-cred-manifest-attach/#drawbacks","title":"Drawbacks","text":"<p>N/A</p>"},{"location":"features/0511-dif-cred-manifest-attach/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>The <code>hlindy-zkp-v1.0</code> format is an alternative restricted to the Hyperledger Indy network.</li> </ul>"},{"location":"features/0511-dif-cred-manifest-attach/#prior-art","title":"Prior art","text":"<p>N/A</p>"},{"location":"features/0511-dif-cred-manifest-attach/#unresolved-questions","title":"Unresolved questions","text":"<p>N/A</p>"},{"location":"features/0511-dif-cred-manifest-attach/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0557-discover-features-v2/","title":"Aries RFC 0557: Discover Features Protocol v2.x","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Update to version 2.0 proposed in conjunction with DIDComm v2 efforts at DIF, where it became clear that we need to discover more than just protocol support of other agents. Included in AIP v2.0.</li> <li>Supersedes: version 1.0 of this protocol in RFC 0031, which was widely referenced in the Aries eocsystem in 2018 and 2019.</li> <li>Start Date: 2018-12-17</li> <li>URI: https://didcomm.org/discover-features/%VER</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"features/0557-discover-features-v2/#summary","title":"Summary","text":"<p>Describes how one agent can query another to discover which ../../features it supports, and to what extent.</p>"},{"location":"features/0557-discover-features-v2/#motivation","title":"Motivation","text":"<p>Though some agents will support just one feature and will be statically configured to interact with just one other party, many exciting uses of agents are more dynamic and unpredictable. When Alice and Bob meet, they won't know in advance which ../../features are supported by one another's agents. They need a way to find out.</p>"},{"location":"features/0557-discover-features-v2/#tutorial","title":"Tutorial","text":"<p>This is version 2.0 of the Discover Features protocol, and its fully qualified PIURI for the Discover Features protocol is:</p> <pre><code>https://didcomm.org/discover-features/2.0\n</code></pre> <p>This version is conceptually similar to version 1.0 of this protocol. It differs in its ability to ask about multiple feature types, and to ask multiple questions and receive multiple answers in a single round trip.</p>"},{"location":"features/0557-discover-features-v2/#roles","title":"Roles","text":"<p>There are two roles in the <code>discover-features</code> protocol: <code>requester</code> and <code>responder</code>. Normally, the requester asks the responder about the ../../features it supports, and the responder answers. Each role uses a single message type.</p> <p>It is also possible to proactively disclose ../../features; in this case a requester receives a response without asking for it. This may eliminate some chattiness in certain use cases (e.g., where two-way connectivity is limited).</p>"},{"location":"features/0557-discover-features-v2/#states","title":"States","text":"<p>The state progression is very simple. In the normal case, it is simple request-response; in a proactive disclosure, it's a simple one-way notification.</p>"},{"location":"features/0557-discover-features-v2/#requester","title":"Requester","text":""},{"location":"features/0557-discover-features-v2/#responder","title":"Responder","text":""},{"location":"features/0557-discover-features-v2/#messages","title":"Messages","text":""},{"location":"features/0557-discover-features-v2/#queries-message-type","title":"<code>queries</code> Message Type","text":"<p>A <code>discover-features/queries</code> message looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/2.0/queries\",\n  \"@id\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\",\n  \"queries\": [\n    { \"feature-type\": \"protocol\", \"match\": \"https://didcomm.org/tictactoe/1.*\" },\n    { \"feature-type\": \"goal-code\", \"match\": \"aries.*\" }\n  ]\n}\n</code></pre> <p>Queries messages contain one or more query objects in the <code>queries</code> array. Each query essentially says, \"Please tell me what ../../features of type X you support, where the feature identifiers match this (potentially wildcarded) string.\" This particular example asks an agent if it supports any 1.x versions of the tictactoe protocol, and if it supports any goal codes that begin with \"aries.\".</p> <p>Implementations of this protocol must recognize the following values for <code>feature-type</code>: <code>protocol</code>, <code>goal-code</code>, <code>gov-fw</code>, <code>didcomm-version</code>, and <code>decorator</code>/<code>header</code>. (The concept known as <code>decorator</code> in DIDComm v1 approximately maps to the concept known as <code>header</code> in DIDComm v2. The two values should be considered synonyms and must both be recognized.) Additional values of <code>feature-type</code> may be standardized by raising a PR against this RFC that defines the new type and increments the minor protocol version number; non-standardized values are also valid, but there is no guarantee that their semantics will be recognized.</p> <p>Identifiers for feature types vary. For protocols, identifiers are PIURIs. For goal codes, identifiers are goal code values. For governance frameworks, identifiers are URIs where the framework is published (typically the <code>data_uri</code> field if machine-readable. For DIDComm versions, identifiers are the URIs where DIDComm versions are developed (<code>https://github.com/hyperledger/aries-rfcs</code> for V1 and <code>https://github.com/decentralized-identity/didcomm-messaging</code> for V2; see \"Detecting DIDComm Versions\" in RFC 0044 for more details).</p> <p>The <code>match</code> field of a query descriptor may use the * wildcard. By itself, a <code>match</code> with just the wildcard says, \"I'm interested in anything you want to share with me.\" But usually, this wildcard will be to match a prefix that's a little more specific, as in the example that matches any 1.x version.</p> <p>Any agent may send another agent this message type at any time. Implementers of agents that intend to support dynamic relationships and rich ../../features are strongly encouraged to implement support for this message, as it is likely to be among the first messages exchanged with a stranger.</p>"},{"location":"features/0557-discover-features-v2/#disclosures-message-type","title":"<code>disclosures</code> Message Type","text":"<p>A <code>discover-features/disclosures</code> message looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/2.0/disclosures\",\n  \"~thread\": { \"thid\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\" },\n  \"disclosures\": [\n    {\n      \"feature-type\": \"protocol\",\n      \"id\": \"https://didcomm.org/tictactoe/1.0\",\n      \"roles\": [\"player\"]\n    },\n    {\n      \"feature-type\": \"goal-code\",\n      \"id\": \"aries.sell.goods.consumer\"\n    }\n  ]\n}\n</code></pre> <p>The <code>disclosures</code> field is a JSON array of zero or more disclosure objects that describe a feature. Each descriptor has a <code>feature-type</code> field that contains data corresponding to <code>feature-type</code> in a query object, and an <code>id</code> field that unambiguously identifies a single item of that feature type. When the item is a protocol, the disclosure object may also contain a <code>roles</code> array that enumerates the roles the responding agent can play in the associated protocol. Future feature types may add additional optional fields, though no other fields are being standardized with this version of the RFC.</p> <p>Disclosures messages say, \"Here are some ../../features I support (that matched your queries).\"</p>"},{"location":"features/0557-discover-features-v2/#sparse-disclosures","title":"Sparse Disclosures","text":"<p>Disclosures do not have to contain exhaustive detail. For example, the following response omits the optional <code>roles</code> field but may be just as useful as one that includes it:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/2.0/disclosures\",\n  \"~thread\": { \"thid\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\" },\n  \"disclosures\": [\n    {\"feature-type\": \"protocol\", \"id\": \"https://didcomm.org/tictactoe/1.0\"}\n  ]\n}\n</code></pre> <p>Less detail probably suffices because agents do not need to know everything about one another's implementations in order to start an interaction--usually the flow will organically reveal what's needed. For example, the <code>outcome</code> message in the <code>tictactoe</code> protocol isn't needed until the end, and is optional anyway. Alice can start a tictactoe game with Bob and will eventually see whether he has the right idea about <code>outcome</code> messages.</p> <p>The missing <code>roles</code> in this disclosure does not say, \"I support no roles in this protocol.\" It says, \"I support the protocol but I'm providing no detail about specific roles.\" Similar logic applies to any other omitted fields.</p> <p>An empty <code>disclosures</code> array does not say, \"I support no ../../features that match your query.\" It says, \"I'm not disclosing to you that I support any ../../features (that match your query).\" An agent might not tell another that it supports a feature for various reasons, including: the trust that it imputes to the other party based on cumulative interactions so far, whether it's in the middle of upgrading a plugin, whether it's currently under high load, and so forth. And responses to a <code>discover-features</code> query are not guaranteed to be true forever; agents can be upgraded or downgraded, although they probably won't churn in their feature profiles from moment to moment.</p>"},{"location":"features/0557-discover-features-v2/#privacy-considerations","title":"Privacy Considerations","text":"<p>Because the wildcards in a <code>queries</code> message can be very inclusive, the <code>discover-features</code> protocol could be used to mine information suitable for agent fingerprinting, in much the same way that browser fingerprinting works. This is antithetical to the ethos of our ecosystem, and represents bad behavior. Agents should use <code>discover-features</code> to answer legitimate questions, and not to build detailed profiles of one another. However, fingerprinting may be attempted anyway.</p> <p>For agents that want to maintain privacy, several best practices are recommended:</p>"},{"location":"features/0557-discover-features-v2/#follow-selective-disclosure","title":"Follow selective disclosure.","text":"<p>Only reveal supported ../../features based on trust in the relationship. Even if you support a protocol, you may not wish to use it in every relationship. Don't tell others about ../../features you do not plan to use with them.</p> <p>Patterns are easier to see in larger data samples. However, a pattern of ultra-minimal data is also a problem, so use good judgment about how forthcoming to be.</p>"},{"location":"features/0557-discover-features-v2/#vary-the-format-of-responses","title":"Vary the format of responses.","text":"<p>Sometimes, you might prettify your agent plaintext message one way, sometimes another.</p>"},{"location":"features/0557-discover-features-v2/#vary-the-order-of-items-in-the-disclosures-array","title":"Vary the order of items in the <code>disclosures</code> array.","text":"<p>If more than one key matches a query, do not always return them in alphabetical order or version order. If you do return them in order, do not always return them in ascending order.</p>"},{"location":"features/0557-discover-features-v2/#consider-adding-some-spurious-details","title":"Consider adding some spurious details.","text":"<p>If a query could match multiple ../../features, then occasionally you might add some made-up ../../features as matches. If a wildcard allows multiple versions of a protocol, then sometimes you might use some made-up versions. And sometimes not. (Doing this too aggressively might reveal your agent implementation, so use sparingly.)</p>"},{"location":"features/0557-discover-features-v2/#vary-how-you-query-too","title":"Vary how you query, too.","text":"<p>How you ask questions may also be fingerprintable.</p>"},{"location":"features/0557-discover-features-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0587-encryption-envelope-v2/","title":"Aries RFC 0587: Encryption Envelope v2","text":"<ul> <li>Authors: Baha A. Shaaban (SecureKey Technologies Inc.), Troy Ronda (SecureKey Technologies Inc.)</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Included as part of the \"prepare for DIDComm v2\" subtarget of AIP 2.0.</li> <li>Supersedes:</li> <li>Start Date: 2021-02-10</li> <li>Tags: feature</li> </ul>"},{"location":"features/0587-encryption-envelope-v2/#summary","title":"Summary","text":"<p>This RFC proposes that we support the definition of envelopes from DIDComm Messaging.</p>"},{"location":"features/0587-encryption-envelope-v2/#motivation","title":"Motivation","text":"<p>This RFC defines ciphersuites for envelopes such that we can achieve better compatability with DIDComm Messaging being specified at DIF. The ciphersuites defined in this RFC are a subset of the definitions in Aries RFC 0334-jwe-envelope.</p>"},{"location":"features/0587-encryption-envelope-v2/#encryption-algorithms","title":"Encryption Algorithms","text":"<p>DIDComm defines both the concept of authenticated sender encryption (aka <code>Authcrypt</code>) and anonymous sender encryption (aka <code>Anoncrypt</code>). In general, Aries RFCs and protocols use <code>Authcrypt</code> to exchange messages. In some limited scenarios (e.g., mediator and relays), an Aries RFC or protocol may define usage of <code>Anoncrypt</code>.</p> <p>ECDH-1PU draft 04 defines the JWE structure for <code>Authcrypt</code>. <code>ECDH-ES</code> from RFC 7518 defines the JWE structure for <code>Anoncrypt</code>. The following sections summarize the supported algorithms.</p>"},{"location":"features/0587-encryption-envelope-v2/#curves","title":"Curves","text":"<p>DIDComm Messaging (and this RFC) requires support for <code>X25519</code>, <code>P-256</code>, and <code>P-384</code>.</p> <ul> <li>P-256 (reference in RFC4492)</li> <li>P-384 (reference in RFC4492)</li> <li>P-521 (optional, reference in RFC4492)</li> <li>X25519 (reference in RFC7748)</li> </ul>"},{"location":"features/0587-encryption-envelope-v2/#content-encryption-algorithms","title":"Content Encryption Algorithms","text":"<p>DIDComm Messaging (and this RFC) requires support for both <code>XC20P</code> and <code>A256GCM</code> for Anoncrypt only and <code>A256CBC-HS512</code> for both Authcrypt and Anoncrypt.</p> <ul> <li>XC20P (XChaCha20Poly1305 - reference in xchacha draft 03)</li> <li>A256GCM (AES-GCM with a 256 bits key - reference in RFC7518 section 5.1 and more specifically RFC7518 section 5.3)</li> <li>A256CBC-HS512 (AES256-CBC+HMAC-SHA512 with a 512 bits key - reference in ECDH-1PU section 2.1 and RFC 7518 section 5.2.5) </li> </ul>"},{"location":"features/0587-encryption-envelope-v2/#key-wrapping-algorithms","title":"Key Wrapping Algorithms","text":"<p>DIDComm Messaging (and this RFC) requires support for <code>ECDH-1PU+A256KW</code> and <code>ECDH-ES+A256KW</code>.</p> <ul> <li>ECDH-1PU+A256KW (defined in ECDH-1PU draft 04)</li> <li>ECDH-ES+A256KW (defined in RFC 7518)</li> </ul>"},{"location":"features/0587-encryption-envelope-v2/#key-ids-kid-and-skid-headers-references-in-the-did-document","title":"Key IDs <code>kid</code> and <code>skid</code> headers references in the DID document","text":"<p>Keys used by DIDComm envelopes MUST be sourced from the DIDs exchanged between two agents. Specifically, both sender and recipients keys MUST be retrieved from the DID document's <code>KeyAgreement</code> verification section as per the DID Document Keys definition.</p> <p>When Alice is preparing an envelope intended for Bob, the packing process should use a key from both hers and Bob's DID document's <code>KeyAgreement</code> section.</p> <p>Assuming Alice has a DID Doc with the following <code>KeyAgreement</code> definition (source: DID V1 Example 17): <pre><code>{\n  \"@context\": \"https://www.w3.org/ns/did/v1\",\n  \"id\": \"did:example:123456789abcdefghi\",\n  ...\n  \"keyAgreement\": [\n    // this method can be used to perform key agreement as did:...fghi\n    \"did:example:123456789abcdefghi#keys-1\",\n    // this method is *only* approved for key agreement usage, it will not\n    // be used for any other verification relationship, so its full description is\n    // embedded here rather than using only a reference\n    {\n      \"id\": \"did:example:123#zC9ByQ8aJs8vrNXyDhPHHNNMSHPcaSgNpjjsBYpMMjsTdS\",\n      \"type\": \"X25519KeyAgreementKey2019\", // external (property value)\n      \"controller\": \"did:example:123\",\n      \"publicKeyBase58\": \"9hFgmPVfmBZwRvFEyniQDBkz9LmV7gDEqytWyGZLmDXE\"\n    }\n  ],\n  ...\n}\n</code></pre></p> <p>The envelope packing process should set the <code>skid</code> header with value <code>did:example:123456789abcdefghi#keys-1</code> in the envelope's protected headers and fetch the underlying key to execute ECDH-1PU key derivation for content key wrapping.</p> <p>Assuming she also has Bob's DID document which happens to include the following <code>KeyAgreement</code> section:</p> <pre><code>{\n  \"@context\": \"https://www.w3.org/ns/did/v1\",\n  \"id\": \"did:example:jklmnopqrstuvwxyz1\",\n  ...\n  \"keyAgreement\": [\n    {\n      \"id\": \"did:example:jklmnopqrstuvwxyz1#key-1\",\n      \"type\": \"X25519KeyAgreementKey2019\", // external (property value)\n      \"controller\": \"did:example:jklmnopqrstuvwxyz1\",\n      \"publicKeyBase58\": \"9hFgmPVfmBZwRvFEyniQDBkz9LmV7gDEqytWyGZLmDXE\"\n    }\n  ],\n  ...\n}\n</code></pre> <p>There should be only 1 entry in the recipients of the envelope, representing Bob. The corresponding <code>kid</code> header for this recipient MUST have <code>did:example:jklmnopqrstuvwxyz1#key-1</code> as value. The packing process MUST extract the public key bytes found in <code>publicKeyBase58</code> of Bob's DID Doc <code>KeyAgreement[0]</code> to execute the ECDH-1PU key derivation for content key wrapping.</p> <p>When Bob receives the envelope, the unpacking process on his end MUST resolve the <code>skid</code> protected header value using Alice's DID doc's <code>KeyAgreement[0]</code> in order to extract her public key. In Alice's DID Doc example above, <code>KeyAgreement[0]</code> is a reference id, it MUST be resolved from the main <code>VerificationMethod[]</code> of Alice's DID document (not shown in the example).</p> <p>Once resolved, the unpacker will then execute ECDH-1PU key derivation using this key and Bob's own recipient key found in the envelope's <code>recipients[0]</code> to unwrap the content encryption key.</p>"},{"location":"features/0587-encryption-envelope-v2/#protecting-the-skid-header","title":"Protecting the <code>skid</code> header","text":"<p>When the <code>skid</code> cannot be revealed in a plain-text JWE header (to avoid potentially leaking sender's key id), the <code>skid</code> MAY be encrypted for each recipient. In this case, instead of having a <code>skid</code> protected header in the envelope, each recipient MAY include an <code>encrypted_skid</code> header with a value based on the encryption of <code>skid</code> using ECDH-ES <code>Z</code> computation of the <code>epk</code> and the recipient's key as the encryption key.</p> <p>For applications that don't require this protection, they MAY use <code>skid</code> protected header directly without any additional recipient headers.</p> <p>Applications MUST use either <code>skid</code> protected header or <code>encrypted_skid</code> recipients header but not both in the same envelope.</p>"},{"location":"features/0587-encryption-envelope-v2/#ecdh-1pu-key-wrapping-and-common-protected-headers","title":"ECDH-1PU key wrapping and common protected headers","text":"<p>When using authcrypt, the 1PU draft requires mandates the use of AES_CBC_HMAC_SHA family of content encryption algorithms. To meet this requirement, JWE messages MUST use common <code>epk</code>, <code>apu</code>, <code>apv</code> and <code>alg</code> headers for all recipients. They MUST be set in the <code>protected</code> headers JWE section.</p> <p>As per this requirement, the JWE building must first encrypt the payload then use the resulting <code>tag</code> as part of the key derivation process when wrapping the <code>cek</code>.</p> <p>To meet this requirement, the above headers must be defined as follows: * <code>epk</code>: generated once for all recipients. It MUST be of the same type and curve as all recipient keys since kdf with the sender key must be on the same curve.  - Example: <code>\"epk\": {\"kty\": \"EC\",\"crv\": \"P-256\",\"x\": \"BVDo69QfyXAdl6fbK6-QBYIsxv0CsNMtuDDVpMKgDYs\",\"y\": \"G6bdoO2xblPHrKsAhef1dumrc0sChwyg7yTtTcfygHA\"}</code> * <code>apu</code>: similar to <code>skid</code>, this is the producer (sender) identifier, it MUST contain the <code>skid</code> value base64 RawURL (no padding) encoded. Note: this is base64URL(<code>skid</code> value).  - Example for <code>skid</code> mentioned in an earlier section above: <code>ZGlkOmV4YW1wbGU6MTIzNDU2Nzg5YWJjZGVmZ2hpI2tleXMtMQ</code> * <code>apv</code>: this represents the recipients' <code>kid</code> list. The list must be alphanumerically sorted, <code>kid</code> values will then be concatenated with a <code>.</code> and the final result MUST be base64 URL (no padding) encoding of the SHA256 hash of concatenated list. * <code>alg</code>: this is the key wrapping algorithm, ie: <code>ECDH-1PU+A256KW</code>.</p> <p>A final note about <code>skid</code> header: since the 1PU draft does not require this header, authcrypt implementations MUST be able to resolve the sender kid from the <code>APU</code> header if <code>skid</code> is not set.</p>"},{"location":"features/0587-encryption-envelope-v2/#media-type","title":"Media Type","text":"<p>The media type associated to this envelope is <code>application/didcomm-encrypted+json</code>. RFC 0044 provides a general discussion of media (aka mime) types.</p> <p>The media type of the envelope MUST be set in the <code>typ</code> property of the JWE and the media type of the payload MUST be set in the <code>cty</code> property of the JWE.</p> <p>For example, following the guidelines of RFC 0044, an encrypted envelope with a plaintext DIDComm v1 payload contains the <code>typ</code> property with the value <code>application/didcomm-encrypted+json</code> and <code>cty</code> property with the value <code>application/json;flavor=didcomm-msg</code>.</p> <p>As specified in IETF RFC 7515 and referenced in IETF RFC 7516, implementations  MUST also support media types that omit <code>application/</code>.  For example, <code>didcomm-encrypted+json</code> and <code>application/didcomm-encrypted+json</code> are treated as equivalent media types.</p> <p>As discussed in RFC 0434 and RFC 0067, the <code>accept</code> property is used to advertise supported media types. The <code>accept</code> property may contain an envelope media type or a combination of the envelope media type and the content media type. In cases where the content media type is not present, the expectation is that the appropriate content media type can be inferred. For example, <code>application/didcomm-envelope-enc</code> indicates both Envelope v1 and DIDComm v1 and <code>application/didcomm-encrypted+json</code> indicates both Envelope v2 and DIDComm v2. However, some agents may choose to support Envelope v2 with a DIDComm v1 message payload.</p> <p>In case the <code>accept</code> property is set in both the DID service block and the out-of-band message, the out-of-band property takes precedence.</p>"},{"location":"features/0587-encryption-envelope-v2/#didcomm-v2-transition","title":"DIDComm v2 Transition","text":"<p>As this RFC specifies the same envelope format as will be used in DIDComm v2, an implementor should detect if the payload contains DIDComm v1 content or the JWM from DIDComm v2. These payloads can be distinguished based on the <code>cty</code> property of the JWE.</p> <p>As discussed in RFC 0044, the content type for the plaintext DIDComm v1 message is <code>application/json;flavor=didcomm-msg</code>. When the <code>cty</code> property contains <code>application/json;flavor=didcomm-msg</code>, the payload is treated as DIDComm v1. DIDComm Messaging will specify appropriate media types for DIDComm v2. To advertise the combination of Envelope v2 with a DIDComm v1 message, the media type is <code>application/didcomm-encrypted+json;cty=application/json</code>.</p>"},{"location":"features/0587-encryption-envelope-v2/#additional-aip-impacts","title":"Additional AIP impacts","text":"<p>Implementors supporting an AIP sub-target that contains this RFC (e.g., <code>DIDCOMMV2PREP</code>) MAY choose to only support Envelope v2 without support for the original envelope declared in RFC 0019. In these cases, the <code>accept</code> property will not contain <code>didcomm/aip2;env=rfc19</code> media type.</p>"},{"location":"features/0587-encryption-envelope-v2/#drawbacks","title":"Drawbacks","text":"<p>The DIDComm v2 specification is a draft. However, the aries-framework-go project has already implemented the new envelope format.</p>"},{"location":"features/0587-encryption-envelope-v2/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Our approach for Authcrypt compliance is to use the NIST approved <code>One-Pass Unified Model for ECDH</code> scheme described in SP 800-56A Rev. 3. The JOSE version is defined as <code>ECDH-1PU</code> in this IETF draft.</p> <p>Aries agents currently use the envelope described in RFC0019. This envelope uses libsodium (NaCl) encryption/decryption, which is based on Salsa20Poly1305 algorithm.</p>"},{"location":"features/0587-encryption-envelope-v2/#prior-art","title":"Prior art","text":"<ul> <li>The JWE family of encryption methods.</li> <li>Aries RFC 0019-encryption-envelope suggested envelope formats will be superseded by this RFC.</li> <li>Aries RFC 0025-didcomm-transports for the content type used in the proposed envelopes.</li> <li>Aries RFC 0334-jwe-envelope.</li> <li>DIDComm Messaging.</li> <li>minimal-cipher implementation</li> <li>Public Key Authenticated Encryption for JOSE: ECDH-1PU</li> <li>NIST SP 800-56A Rev. 3 Recommendation for Pair-Wise Key-Establishment schemes Using Discrete Logarithm Cryptography</li> </ul>"},{"location":"features/0587-encryption-envelope-v2/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"features/0587-encryption-envelope-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0592-indy-attachments/","title":"Aries RFC 0592: Indy Attachment Formats for Requesting and Presenting Credentials","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Formalizes the Indy AnonCreds attachments for issuing credentials and presenting proofs. A part of the Indy AnonCreds subtarget of AIP v2.0.</li> <li>Supersedes: less formally documented Indy attachment formats documented in Aries RFC 0036, Aries RFC 0037, etc.</li> <li>Start Date: 2017-01-01</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0592-indy-attachments/#summary","title":"Summary","text":"<p>This RFC registers attachment formats used with Hyperledger Indy-style ZKP-oriented credentials in Issue Credential Protocol 2.0 and Present Proof Protocol 2.0. These formats are generally considered v2 formats, as they align with the \"anoncreds2\" work in Hyperledger Ursa and are a second generation implementation. They began to be used in production in 2018 and are in active deployment in 2021.</p>"},{"location":"features/0592-indy-attachments/#motivation","title":"Motivation","text":"<p>Allows Indy-style credentials to be used with credential-related protocols that take pluggable formats as payloads.</p>"},{"location":"features/0592-indy-attachments/#reference","title":"Reference","text":""},{"location":"features/0592-indy-attachments/#cred-filter-format","title":"cred filter format","text":"<p>The potential holder uses this format to propose criteria for a potential credential for the issuer to offer.</p> <p>The identifier for this format is <code>hlindy/cred-filter@v2.0</code>. It is a base64-encoded version of the data structure specifying zero or more criteria from the following (non-base64-encoded) structure:</p> <pre><code>{\n    \"schema_issuer_did\": \"&lt;schema_issuer_did&gt;\",\n    \"schema_name\": \"&lt;schema_name&gt;\",\n    \"schema_version\": \"&lt;schema_version&gt;\",\n    \"schema_id\": \"&lt;schema_identifier&gt;\",\n    \"issuer_did\": \"&lt;issuer_did&gt;\",\n    \"cred_def_id\": \"&lt;credential_definition_identifier&gt;\"\n}\n</code></pre> <p>The potential holder may not know, and need not specify, all of these criteria. For example, the holder might only know the schema name and the (credential) issuer DID. Recall that the potential holder may specify target attribute values and MIME types in the credential preview.</p> <p>For example, the JSON (non-base64-encoded) structure might look like this:</p> <pre><code>{\n    \"schema_issuer_did\": \"did:sov:4RW6QK2HZhHxa2tg7t1jqt\",\n    \"schema_name\": \"bcgov-mines-act-permit.bcgov-mines-permitting\",\n    \"issuer_did\": \"did:sov:4RW6QK2HZhHxa2tg7t1jqt\"\n}\n</code></pre> <p>A complete <code>propose-credential</code> message from the Issue Credential protocol 2.0 embeds this format at <code>/filters~attach/data/base64</code>:</p> <pre><code>{\n    \"@id\": \"&lt;uuid of propose message&gt;\",\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/propose-credential\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\" : [{\n        \"attach_id\": \"&lt;attach@id value&gt;\",\n        \"format\": \"hlindy/cred-filter@v2.0\"\n    }],\n    \"filters~attach\": [{\n        \"@id\": \"&lt;attach@id value&gt;\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"base64\": \"ewogICAgInNjaGVtYV9pc3N1ZXJfZGlkIjogImRpZDpzb3Y... (clipped)... LMkhaaEh4YTJ0Zzd0MWpxdCIKfQ==\"\n        }\n    }]\n}\n</code></pre>"},{"location":"features/0592-indy-attachments/#cred-abstract-format","title":"cred abstract format","text":"<p>This format is used to clarify the structure and semantics (but not the concrete data values) of a potential credential, in offers sent from issuer to potential holder.</p> <p>The identifier for this format is <code>hlindy/cred-abstract@v2.0</code>. It is a base64-encoded version of the data returned from <code>indy_issuer_create_credential_offer()</code>.</p> <p>The JSON (non-base64-encoded) structure might look like this:</p> <pre><code>{\n    \"schema_id\": \"4RW6QK2HZhHxa2tg7t1jqt:2:bcgov-mines-act-permit.bcgov-mines-permitting:0.2.0\",\n    \"cred_def_id\": \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    \"nonce\": \"57a62300-fbe2-4f08-ace0-6c329c5210e1\",\n    \"key_correctness_proof\" : &lt;key_correctness_proof&gt;\n}\n</code></pre> <p>A complete <code>offer-credential</code> message from the Issue Credential protocol 2.0 embeds this format at <code>/offers~attach/data/base64</code>:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/offer-credential\",\n    \"@id\": \"&lt;uuid of offer message&gt;\",\n    \"replacement_id\": \"&lt;issuer unique id&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\": \"hlindy/cred-abstract@v2.0\"\n        }\n    ],\n    \"offers~attach\": [\n        {\n            \"@id\": \"&lt;attach@id value&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"ewogICAgInNjaGVtYV9pZCI6ICI0Ulc2UUsySFpoS... (clipped)... jb3JyZWN0bmVzc19wcm9vZj4KfQ==\"\n            }\n        }\n    ]\n}\n</code></pre> <p>The same structure can be embedded at <code>/offers~attach/data/base64</code> in an <code>offer-credential</code> message. </p>"},{"location":"features/0592-indy-attachments/#cred-request-format","title":"cred request format","text":"<p>This format is used to formally request a credential. It differs from the credential abstract above in that it contains a cryptographic commitment to a link secret; an issuer can therefore use it to bind a concrete instance of an issued credential to the appropriate holder. (In contrast, the credential abstract describes the schema and cred def, but not enough information to actually issue to a specific holder.)</p> <p>The identifier for this format is <code>hlindy/cred-req@v2.0</code>. It is a base64-encoded version of the data returned from indy_prover_create_credential_req().</p> <p>The JSON (non-base64-encoded) structure might look like this:</p> <pre><code>{\n    \"prover_did\" : \"did:sov:abcxyz123\",\n    \"cred_def_id\" : \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    // Fields below can depend on Cred Def type\n    \"blinded_ms\" : &lt;blinded_master_secret&gt;,\n    \"blinded_ms_correctness_proof\" : &lt;blinded_ms_correctness_proof&gt;,\n    \"nonce\": \"fbe22300-57a6-4f08-ace0-9c5210e16c32\"\n}\n</code></pre> <p>A complete <code>request-credential</code> message from the Issue Credential protocol 2.0 embeds this format at <code>/requests~attach/data/base64</code>:</p> <pre><code>{\n    \"@id\": \"cf3a9301-6d4a-430f-ae02-b4a79ddc9706\",\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/request-credential\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\": [{\n        \"attach_id\": \"7cd11894-838a-45c0-a9ec-13e2d9d125a1\",\n        \"format\": \"hlindy/cred-req@v2.0\"\n    }],\n    \"requests~attach\": [{\n        \"@id\": \"7cd11894-838a-45c0-a9ec-13e2d9d125a1\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"base64\": \"ewogICAgInByb3Zlcl9kaWQiIDogImRpZDpzb3Y6YWJjeHl.. (clipped)... DAtNTdhNi00ZjA4LWFjZTAtOWM1MjEwZTE2YzMyIgp9\"\n        }\n    }]\n}\n</code></pre>"},{"location":"features/0592-indy-attachments/#credential-format","title":"credential format","text":"<p>A concrete, issued Indy credential may be transmitted over many protocols, but is specifically expected as the final message in Issuance Protocol 2.0. The identifier for its format is <code>hlindy/cred@v2.0</code>.</p> <p>This is a credential that's designed to be held but not shared directly. It is stored in the holder's wallet and used to derive a novel ZKP or W3C-compatible verifiable presentation just in time for each sharing of credential material.</p> <p>The encoded values of the credential MUST follow the encoding algorithm as described in Encoding Claims.</p> <p>This is the format emitted by libindy's indy_issuer_create_credential() function. It is JSON-based and might look like this:</p> <pre><code>{\n    \"schema_id\": \"4RW6QK2HZhHxa2tg7t1jqt:2:bcgov-mines-act-permit.bcgov-mines-permitting:0.2.0\",\n    \"cred_def_id\": \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    \"rev_reg_id\", \"EyN78DDGHyok8qw6W96UBY:4:EyN78DDGHyok8qw6W96UBY:3:CL:56389:CardossierOrgPerson:CL_ACCUM:1-1000\",\n    \"values\": {\n        \"attr1\" : {\"raw\": \"value1\", \"encoded\": \"value1_as_int\" },\n        \"attr2\" : {\"raw\": \"value2\", \"encoded\": \"value2_as_int\" }\n    },\n    // Fields below can depend on Cred Def type\n    \"signature\": &lt;signature&gt;,\n    \"signature_correctness_proof\": &lt;signature_correctness_proof&gt;\n    \"rev_reg\": &lt;revocation registry state&gt;\n    \"witness\": &lt;witness&gt;\n}\n</code></pre> <p>An exhaustive description of the format is out of scope here; it is more completely documented in white papers, source code, and other Indy materials.</p>"},{"location":"features/0592-indy-attachments/#proof-request-format","title":"proof request format","text":"<p>This format is used to formally request a verifiable presenation (proof) derived from an Indy-style ZKP-oriented credential. It can also be used by a holder to propose a presentation.</p> <p>The identifier for this format is <code>hlindy/proof-req@v2.0</code>. It is a base64-encoded version of the data returned from indy_prover_search_credentials_for_proof_req().</p> <p>Here is a sample proof request that embodies the following: \"Using a government-issued ID, disclose the credential holder\u2019s name and height, hide the credential holder\u2019s sex, get them to self-attest their phone number, and prove that their age is at least 18\":</p> <pre><code>{\n    \"nonce\": \u201c2934823091873049823740198370q23984710239847\u201d, \n    \"name\":\"proof_req_1\",\n    \"version\":\"0.1\",\n    \"requested_attributes\":{\n        \"attr1_referent\": {\"name\":\"sex\"},\n        \"attr2_referent\": {\"name\":\"phone\"},\n        \"attr3_referent\": {\"names\": [\"name\", \"height\"], \"restrictions\": &lt;restrictions specifying government-issued ID&gt;}\n    },\n    \"requested_predicates\":{\n        \"predicate1_referent\":{\"name\":\"age\",\"p_type\":\"&gt;=\",\"p_value\":18}\n    }\n}\n</code></pre>"},{"location":"features/0592-indy-attachments/#proof-format","title":"proof format","text":"<p>This is the format of an Indy-style ZKP. It plays the same role as a W3C-style verifiable presentation (VP) and can be mapped to one.</p> <p>The raw values encoded in the presentation SHOULD be verified against the encoded values using the encoding algorithm as described below in Encoding Claims.</p> <p>The identifier for this format is <code>hlindy/proof@v2.0</code>. It is a version of the (JSON-based) data emitted by libindy's indy_prover_create_proof()) function. A proof that responds to the previous proof request sample looks like this:</p> <pre><code>{\n  \"proof\":{\n    \"proofs\":[\n      {\n        \"primary_proof\":{\n          \"eq_proof\":{\n            \"revealed_attrs\":{\n              \"height\":\"175\",\n              \"name\":\"1139481716457488690172217916278103335\"\n            },\n            \"a_prime\":\"5817705...096889\",\n            \"e\":\"1270938...756380\",\n            \"v\":\"1138...39984052\",\n            \"m\":{\n              \"master_secret\":\"375275...0939395\",\n              \"sex\":\"3511483...897083518\",\n              \"age\":\"13430...63372249\"\n            },\n            \"m2\":\"1444497...2278453\"\n          },\n          \"ge_proofs\":[\n            {\n              \"u\":{\n                \"1\":\"152500...3999140\",\n                \"2\":\"147748...2005753\",\n                \"0\":\"8806...77968\",\n                \"3\":\"10403...8538260\"\n              },\n              \"r\":{\n                \"2\":\"15706...781609\",\n                \"3\":\"343...4378642\",\n                \"0\":\"59003...702140\",\n                \"DELTA\":\"9607...28201020\",\n                \"1\":\"180097...96766\"\n              },\n              \"mj\":\"134300...249\",\n              \"alpha\":\"827896...52261\",\n              \"t\":{\n                \"2\":\"7132...47794\",\n                \"3\":\"38051...27372\",\n                \"DELTA\":\"68025...508719\",\n                \"1\":\"32924...41082\",\n                \"0\":\"74906...07857\"\n              },\n              \"predicate\":{\n                \"attr_name\":\"age\",\n                \"p_type\":\"GE\",\n                \"value\":18\n              }\n            }\n          ]\n        },\n        \"non_revoc_proof\":null\n      }\n    ],\n    \"aggregated_proof\":{\n      \"c_hash\":\"108743...92564\",\n      \"c_list\":[ 6 arrays of 257 numbers between 0 and 255]\n    }\n  },\n  \"requested_proof\":{\n    \"revealed_attrs\":{\n      \"attr1_referent\":{\n        \"sub_proof_index\":0,\n        \"raw\":\"Alex\",\n        \"encoded\":\"1139481716457488690172217916278103335\"\n      }\n    },\n    \"revealed_attr_groups\":{\n      \"attr4_referent\":{\n        \"sub_proof_index\":0,\n        \"values\":{\n          \"name\":{\n            \"raw\":\"Alex\",\n            \"encoded\":\"1139481716457488690172217916278103335\"\n          },\n          \"height\":{\n            \"raw\":\"175\",\n            \"encoded\":\"175\"\n          }\n        }\n      }\n    },\n    \"self_attested_attrs\":{\n      \"attr3_referent\":\"8-800-300\"\n    },\n    \"unrevealed_attrs\":{\n      \"attr2_referent\":{\n        \"sub_proof_index\":0\n      }\n    },\n    \"predicates\":{\n      \"predicate1_referent\":{\n        \"sub_proof_index\":0\n      }\n    }\n  },\n  \"identifiers\":[\n    {\n      \"schema_id\":\"NcYxiDXkpYi6ov5FcYDi1e:2:gvt:1.0\",\n      \"cred_def_id\":\"NcYxi...cYDi1e:2:gvt:1.0:TAG_1\",\n      \"rev_reg_id\":null,\n      \"timestamp\":null\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0592-indy-attachments/#unrevealed-attributes","title":"Unrevealed Attributes","text":"<p>AnonCreds supports a holder responding to a proof request with some of the requested claims included in an <code>unrevealed_attrs</code> array, as seen in the example above, with <code>attr2_referent</code>. Assuming the rest of the proof is valid, AnonCreds will indicate that a proof with unrevealed attributes has been successfully verified. It is the responsibility of the verifier to determine if the purpose of the verification has been met if some of the attributes are not revealed.</p> <p>There are at least a few valid use cases for this approach:</p> <ul> <li>A verifier may ask for, but not require, that a prover provide all of the   requested attributes.</li> <li>A verifier may ask for claims from several credentials, expecting holders to   only have some of the credentials. The holders respond with claims from the   credentials they have, and leave the other attributes unrevealed.</li> <li>For example, a verifier may ask for a national identity card and an resident     card, knowing that most holders will have one or the other.</li> </ul>"},{"location":"features/0592-indy-attachments/#encoding-claims","title":"Encoding Claims","text":"<p>Claims in AnonCreds-based verifiable credentials are put into the credential in two forms, <code>raw</code> and <code>encoded</code>. <code>raw</code> is the actual data value, and <code>encoded</code> is the (possibly derived) integer value that is used in presentations. At this time, AnonCreds does not take an opinion on the method used for encoding the raw value.</p> <p>AnonCreds issuers and verifiers must agree on the encoding method so that the verifier can check that the <code>raw</code> value returned in a presentation corresponds to the proven <code>encoded</code> value. The following is the encoding algorithm that MUST be used by Issuers when creating credentials and SHOULD be verified by Verifiers receiving presentations:</p> <ul> <li>keep any 32-bit integer as is</li> <li>convert any string integer (e.g. <code>\"1234\"</code>) to be a 32-bit integer (e.g. <code>1234</code>)</li> <li>for data of any other type:</li> <li>convert to string (use string \"None\" for null)</li> <li>encode via utf-8 to bytes</li> <li>apply SHA-256 to digest the bytes</li> <li>convert the resulting digest bytes, big-endian, to integer</li> <li>stringify the integer as a decimal.</li> </ul> <p>An example implementation in Python can be found here.</p> <p>A gist of test value pairs can be found here.</p>"},{"location":"features/0592-indy-attachments/#notes-on-encoding-claims","title":"Notes on Encoding Claims","text":"<ul> <li>In converting any string integer to an integer, leading 0s in the string are (by definition) not part of the integer. The leading 0's remain in the (untouched) <code>raw</code> value.</li> <li>The use of AnonCreds predicates, such as proving \"older than 21\" based on a date of birth claim without sharing the date of birth, is based on an expression involving the <code>encoded</code> value. Thus, only <code>raw</code> integers or string integers can be used in AnonCreds predicates.</li> </ul>"},{"location":"features/0592-indy-attachments/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0593-json-ld-cred-attach/","title":"Aries RFC 0593: JSON-LD Credential Attachment format for requesting and issuing credentials","text":"<ul> <li>Authors: Timo Glastra (Animo Solutions), George Aristy (SecureKey Technologies)</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Included as part of the JSON-LD verifiable credentials subtarget of AIP v2.0.</li> <li>Supersedes:</li> <li>Start Date: 2021-02-17</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0593-json-ld-cred-attach/#summary","title":"Summary","text":"<p>This RFC registers an attachment format for use in the issue-credential V2 protocol based on JSON-LD credentials with Linked Data Proofs from the VC Data Model.</p> <p>It defines a minimal set of parameters needed to create a common understanding of the verifiable credential to issue. It is based on version 1.0 of the Verifiable Credentials Data Model which is a W3C recommendation since 19 November 2019.</p>"},{"location":"features/0593-json-ld-cred-attach/#motivation","title":"Motivation","text":"<p>The Issue Credential protocol needs an attachment format to be able to exchange JSON-LD credentials with Linked Data Proofs. It is desirable to make use of specifications developed in an open standards body, such as the Credential Manifest for which the attachment format is described in RFC 0511: Credential-Manifest Attachment format. However, the Credential Manifest is not finished and ready yet, and therefore there is a need to bridge the gap between standards.</p>"},{"location":"features/0593-json-ld-cred-attach/#tutorial","title":"Tutorial","text":"<p>Complete examples of messages are provided in the reference section.</p>"},{"location":"features/0593-json-ld-cred-attach/#reference","title":"Reference","text":""},{"location":"features/0593-json-ld-cred-attach/#ld-proof-vc-detail-attachment-format","title":"<code>ld-proof-vc-detail</code> attachment format","text":"<p>Format identifier: <code>aries/ld-proof-vc-detail@v1.0</code></p> <p>This format is used to formally propose, offer, or request a credential. The <code>credential</code> property should contain the credential as it is going to be issued, without the <code>proof</code> and <code>credentialStatus</code> properties. Options for these properties are specified in the <code>options</code> object.</p> <p>The JSON structure might look like this:</p> <pre><code>{\n  \"credential\": {\n    \"@context\": [\n      \"https://www.w3.org/2018/credentials/v1\",\n      \"https://www.w3.org/2018/credentials/examples/v1\"\n    ],\n    \"id\": \"urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5\",\n    \"type\": [\"VerifiableCredential\", \"UniversityDegreeCredential\"],\n    \"issuer\": \"did:key:z6MkodKV3mnjQQMB9jhMZtKD9Sm75ajiYq51JDLuRSPZTXrr\",\n    \"issuanceDate\": \"2020-01-01T19:23:24Z\",\n    \"expirationDate\": \"2021-01-01T19:23:24Z\",\n    \"credentialSubject\": {\n      \"id\": \"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\",\n      \"degree\": {\n        \"type\": \"BachelorDegree\",\n        \"name\": \"Bachelor of Science and Arts\"\n      }\n    }\n  },\n  \"options\": {\n    \"proofPurpose\": \"assertionMethod\",\n    \"created\": \"2020-04-02T18:48:36Z\",\n    \"domain\": \"example.com\",\n    \"challenge\": \"9450a9c1-4db5-4ab9-bc0c-b7a9b2edac38\",\n    \"credentialStatus\": {\n      \"type\": \"CredentialStatusList2017\"\n    },\n    \"proofType\": \"Ed25519Signature2018\"\n  }\n}\n</code></pre> <p>A complete <code>request credential</code> message form the Issue Credential protocol 2.0 might look like this:</p> <pre><code>{\n  \"@id\": \"7293daf0-ed47-4295-8cc4-5beb513e500f\",\n  \"@type\": \"https://didcomm.org/issue-credential/%VER/request-credential\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"13a3f100-38ce-4e96-96b4-ea8f30250df9\",\n      \"format\": \"aries/ld-proof-vc-detail@v1.0\"\n    }\n  ],\n  \"requests~attach\": [\n    {\n      \"@id\": \"13a3f100-38ce-4e96-96b4-ea8f30250df9\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"ewogICJjcmVkZW50aWFsIjogewogICAgIkBjb250...(clipped)...IkVkMjU1MTlTaWduYXR1cmUyMDE4IgogIH0KfQ==\"\n      }\n    }\n  ]\n}\n</code></pre> <ul> <li> <p><code>credential</code> - Required. Detail of the JSON-LD Credential that will be issued. Properties MUST align with the Verifiable Credentials Data Model. This also means all properties required by the data model MUST be present. The properties listed below are formally supported, but additional properties MAY be included if it conforms with the data model.</p> </li> <li> <p><code>@context</code></p> </li> <li><code>id</code></li> <li><code>type</code></li> <li><code>issuer</code></li> <li><code>issuanceDate</code></li> <li><code>expirationDate</code></li> <li> <p><code>credentialSubject</code></p> </li> <li> <p><code>options</code> - Required. Options for specifying how the linked data proof is created.</p> </li> <li> <p><code>proofType</code> - Required string. The proof type used for the proof. Should match suites registered in the Linked Data Cryptographic Suite Registry.</p> </li> <li><code>proofPurpose</code> - Optional string, default <code>assertionMethod</code>. The proof purpose used for the proof. Should match proof purposes registered in the Linked Data Proofs Specification.</li> <li><code>created</code> - Optional string, default current system time. The date and time of the proof (with a maximum accuracy in seconds).</li> <li><code>challenge</code> - Optional string. A challenge to include in the proof. SHOULD be provided by the requesting party of the credential (=holder).</li> <li><code>domain</code> - Optional string. The intended domain of validity for the proof.</li> <li><code>credentialStatus</code> - Optional object. The credential status mechanism to use for the credential. Omitting the property indicates the issued credential will not include a credential status.<ul> <li><code>type</code> - Required string. Credential status method type to use for the credential. Should match status method registered in the Verifiable Credential Extension Registry</li> </ul> </li> </ul> <p>The format is closely related to the Verifiable Credentials HTTP API, but diverts on some places. The main differences are:</p> <ul> <li>The types in the VC HTTP API are more restrictive (.e.g. <code>@context</code> must be array of strings). This format allows all fields to use the full syntax as described by the verifiable credentials data model.</li> <li>Instead of specifying the exact <code>verificationMethod</code>, the <code>proofType</code> that will be used for the credential can be specified.</li> </ul>"},{"location":"features/0593-json-ld-cred-attach/#ld-proof-vc-attachment-format","title":"<code>ld-proof-vc</code> attachment format","text":"<p>Format identifier: <code>aries/ld-proof-vc@v1.0</code></p> <p>This format is used to transmit a verifiable credential with linked data proof. The contents of the attachment is a standard JSON-LD Verifiable Credential object with linked data proof as defined by the Verifiable Credentials Data Model and the Linked Data Proofs specification.</p> <p>The JSON structure might look like this:</p> <pre><code>{\n  \"@context\": [\n    \"https://www.w3.org/2018/credentials/v1\",\n    \"https://www.w3.org/2018/credentials/examples/v1\"\n  ],\n  \"id\": \"http://example.gov/credentials/3732\",\n  \"type\": [\"VerifiableCredential\", \"UniversityDegreeCredential\"],\n  \"issuer\": {\n    \"id\": \"did:web:vc.transmute.world\"\n  },\n  \"issuanceDate\": \"2020-03-10T04:24:12.164Z\",\n  \"credentialSubject\": {\n    \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n    \"degree\": {\n      \"type\": \"BachelorDegree\",\n      \"name\": \"Bachelor of Science and Arts\"\n    }\n  },\n  \"proof\": {\n    \"type\": \"JsonWebSignature2020\",\n    \"created\": \"2020-03-21T17:51:48Z\",\n    \"verificationMethod\": \"did:web:vc.transmute.world#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A\",\n    \"proofPurpose\": \"assertionMethod\",\n    \"jws\": \"eyJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdLCJhbGciOiJFZERTQSJ9..OPxskX37SK0FhmYygDk-S4csY_gNhCUgSOAaXFXDTZx86CmI5nU9xkqtLWg-f4cqkigKDdMVdtIqWAvaYx2JBA\"\n  }\n}\n</code></pre> <p>A complete <code>issue-credential</code> message from the Issue Credential protocol 2.0 might look like this:</p> <pre><code>{\n  \"@id\": \"284d3996-ba85-45d9-964b-9fd5805517b6\",\n  \"@type\": \"https://didcomm.org/issue-credential/%VER/issue-credential\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"5b38af88-d36f-4f77-bb7a-2f04ab806eb8\",\n      \"format\": \"aries/ld-proof-vc@v1.0\"\n    }\n  ],\n  \"credentials~attach\": [\n    {\n      \"@id\": \"5b38af88-d36f-4f77-bb7a-2f04ab806eb8\",\n      \"mime-type\": \"application/ld+json\",\n      \"data\": {\n        \"base64\": \"ewogICAgICAgICAgIkBjb250ZXogWwogICAgICAg...(clipped)...RNVmR0SXFXZhWXgySkJBIgAgfQogICAgICAgIH0=\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0593-json-ld-cred-attach/#supported-proof-types","title":"Supported Proof Types","text":"<p>Following are the Linked Data proof types on Verifiable Credentials that MUST be supported for compliance with this RFC. All suites listed in the following table MUST be registered in the Linked Data Cryptographic Suite Registry:</p> Suite Spec Enables Selective disclosure? Enables Zero-knowledge proofs? Optional Ed25519Signature2018 Link No No No BbsBlsSignature2020** Link Yes No No JsonWebSignature2020*** Link No No Yes <p>** Note: see RFC0646 for details on how BBS+ signatures are to be produced and consumed by Aries agents.</p> <p>*** Note: P-256 and P-384 curves are supported.</p>"},{"location":"features/0593-json-ld-cred-attach/#drawbacks","title":"Drawbacks","text":"<p>N/A</p>"},{"location":"features/0593-json-ld-cred-attach/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>The <code>hlindy-zkp-v1.0</code> format is an alternative restricted to the Hyperledger Indy network. The <code>dif/credential-manifest@v1.0</code> allows to issue JSON-LD credentials but is not ready yet for usage.</li> </ul>"},{"location":"features/0593-json-ld-cred-attach/#prior-art","title":"Prior art","text":"<p>N/A</p>"},{"location":"features/0593-json-ld-cred-attach/#unresolved-questions","title":"Unresolved questions","text":"<p>N/A</p>"},{"location":"features/0593-json-ld-cred-attach/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0627-static-peer-dids/","title":"Aries RFC 0627: Static Peer DIDs","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: RETIRED</li> <li>Since: 2021-04-07</li> <li>Status Note: formally freezes a set of ../../features that have been relatively stable for about 18 months</li> <li>Start Date: 2021-03-24</li> <li>Tags: feature</li> </ul>"},{"location":"features/0627-static-peer-dids/#summary","title":"Summary","text":"<p>Formally documents a very crisp profile of peer DID functionality that can be referenced in Aries Interop Profiles.</p>"},{"location":"features/0627-static-peer-dids/#motivation","title":"Motivation","text":"<p>The Peer DID Spec includes a number of advanced ../../features that are still evolving. However, a subset of its functionality is easy to implement and would be helpful to freeze for the purpose of Aries interop.</p>"},{"location":"features/0627-static-peer-dids/#tutorial","title":"Tutorial","text":""},{"location":"features/0627-static-peer-dids/#spec-version","title":"Spec version","text":"<p>The Peer DID method spec is still undergoing minor evolution. However, it is relatively stable, particularly in the simpler ../../features.</p> <p>This Aries RFC targets the version of the spec that is dated April 2, 2021 in its rendered form, or github commit 202a913 in its source form. Note that the rendered form of the spec may update without warning, so the github commit is the better reference.</p>"},{"location":"features/0627-static-peer-dids/#targeted-layers","title":"Targeted layers","text":"<p>Support for peer DIDs is imagined to target configurable \"layers\" of interoperability:</p> <p></p> <p>For a careful definition of what these layers entail, please see https://identity.foundation/peer-did-method-spec/#layers-of-support.</p> <p>This Aries RFC targets Layers 1 and 2. That is, code that complies with this RFC would satisfy the required behaviors for Layer 1 and for Layer 2. Note, however, that Layer 2 is broken into accepting and giving static peer DIDs. An RFC-compliant implementation may choose to implement either side, or both.</p> <p>Support for Layer 3 (dynamic peer DIDs that have updatable state and that synchronize that state using Sync Connection Protocol as documented in Aries RFC 0030) is NOT required by this RFC. However, if there is an intent to support dynamic updates in the future, use of <code>numalgo</code> Method 1 is encouraged, as this allows static peer DIDs to acquire new state when dynamic support is added. (See next section.)</p>"},{"location":"features/0627-static-peer-dids/#targeted-generation-methods-numalgo","title":"Targeted Generation Methods (<code>numalgo</code>)","text":"<p>Peer DIDs can use several different algorithms to generate the entropy that constitutes their numeric basis. See https://identity.foundation/peer-did-method-spec/#generation-method for details.</p> <p>This RFC targets Method 0 (inception key without doc), Method 1 (genesis doc), and Method 2 (multiple inception keys). Code that complies with this RFC, and that intends to accept static DIDs at Layer 2a, MUST accept peer DIDs that use any of these methods. Code that intends to give peer DIDs (Layer 2b) MUST give peer DIDs that use at least one of these three methods.</p>"},{"location":"features/0627-static-peer-dids/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0641-linking-binary-objects-to-credentials/","title":"0641: Linking binary objects to credentials using hash based references","text":"<ul> <li>Authors: Berend Sliedrecht (Animo Solutions)</li> <li>Status: PROPOSED</li> <li>Since: 2021-04-22</li> <li>Status Note: Proposal</li> <li>Start Date: 2021-03-17</li> <li>Tags: feature, credentials</li> </ul>"},{"location":"features/0641-linking-binary-objects-to-credentials/#summary","title":"Summary","text":"<p>This RFC provides a solution for issuing and presenting credentials with external binary objects, after referred to as attachments. It is compatible with 0036: Issue Credential Protocol V1, 0453: Issue Credential Protocol V2, 0037: Present Proof V1 protocol and 0454: Present Proof V2 Protocol. These external attachments could consist of images, PDFs, zip files, movies, etc. Through the use of <code>DIDComm attachments</code>, 0017: Attachments, the data can be embedded directly into the attachment or externally hosted. In order to maintain integrity over these attachments, hashlinks are used as the checksum.</p>"},{"location":"features/0641-linking-binary-objects-to-credentials/#motivation","title":"Motivation","text":"<p>Many use cases, such as a rental agreement or medical data in a verifiable credential, rely on attachments, small or large. At this moment, it is possible to issue credentials with accompanying attachments. When the attachment is rather small, this will work fine. However, larger attachments cause inconsistent timing issues and are resource intensive.</p>"},{"location":"features/0641-linking-binary-objects-to-credentials/#tutorial","title":"Tutorial","text":"<p>It is already possible to issue and verify base64-encoded attachments in credentials. When a credential is getting larger and larger, it becomes more and more impractical as it has to be signed, which is time consuming and resource intensive. A solution for this is to use the attachments decorator. This decorator creates a way to externalize the attachment from the credential attributes. By allowing this, the signing will be faster and more consistent. However, DIDComm messages SHOULD stay small, like with SMTP or Bluetooth, as specified in 0017: Attachments. In the attachments decorator it is also possible to specify a list of URLs where the attachment might be located for download. This list of URLs is accompanied by a <code>sha256</code> tag that is a checksum over the file to maintain integrity. This <code>sha256</code> tag can only contain a sha256 hash and if another algorithm is preferred then the hashlink MUST be used as the checksum.</p> <p>When issuing and verifying a credential, messages have to be sent between the holder, issuer and verifier. In order to circumvent additional complexity, such as looking at previously sent credentials for the attachment, the attachments decorator, when containing an attachment, MUST be sent at all of the following steps:</p> <p>Issue Credential V1 &amp; V2</p> <ol> <li>Credential Proposal</li> <li>Credential Offer</li> <li>Credential Request</li> <li>Credential</li> </ol> <p>Present Proof V1 &amp; V2</p> <ol> <li>Presentation Proposal</li> <li>Presentation Request</li> <li>Presentation</li> </ol>"},{"location":"features/0641-linking-binary-objects-to-credentials/#linking","title":"Linking","text":"<p>When a credential is issued with an attachment in the attachments decorator, be it a base64-encoded file or a hosted file, the link has to be made between the credential and the attachment. The link MUST be made with the <code>attribute.value</code> of the credential and the <code>@id</code> tag of the attachment in the attachments decorator.</p>"},{"location":"features/0641-linking-binary-objects-to-credentials/#hashlink","title":"Hashlink","text":"<p>A hashlink, as specified in IETF: Cryptographic Hyperlinks, is a formatted hash that has a prefix of <code>hl:</code> and an optional suffix of metadata. The hash in the hashlink is a multihash, which means that according to the prefix of the hash it is possible to see which hashing algorithm and encoding algorithm has been chosen. An example of a hashlink would be:</p> <p><code>hl:zQmcWyBPyedDzHFytTX6CAjjpvqQAyhzURziwiBKDKgqx6R</code></p> <p>This example shows the prefix of <code>hl:</code> indicating that it is a hashlink and the hash after the prefix is a multihash.</p> <p>The hashlink also allows for opional metadata, such as; a list of URLs where the attachment is hosted and a MIME-type. These metadata values are encoded in the CBOR data format using the specified algortihm from section 3.1.2 in the IETF: Cryptographic Hyperlinks.</p> <p>When a holder receives a credential with hosted attachments, the holder MAY rehost these attachments. A holder would do this in order to prevent the phone-home problem. If a holder does not care about this issue, this is use case specific, this can be left out but should be considered.</p>"},{"location":"features/0641-linking-binary-objects-to-credentials/#inlined-attachments-as-a-credential-attribute","title":"Inlined Attachments as a Credential Attribute","text":"<p>Attachments can be inlined in the credential attribute as a base64-encoded string. With this, there is no need for the attachment decorator. Below is an example of embedding a base64-encoded file as a string in a credential attribute.</p> <pre><code>{\n  \"name\": \"Picture of a cat\",\n  \"mime-type\": \"image/png\",\n  \"value\": \"VGhpcyBpc ... (many bytes omitted) ... C4gSG93IG5pY2U=\"\n}\n</code></pre>"},{"location":"features/0641-linking-binary-objects-to-credentials/#attachments-inlined-in-the-attachment-decorator","title":"Attachments inlined in the Attachment Decorator","text":"<p>When the attachments decorator is used to issue a credential with a binary object, a link has to be made between the credential value and the corresponding attachment. This link MUST be a hash, specifically a hashlink based on the checksum of the attachment.</p> <p>As stated in 0008: message id and threading, the <code>@id</code> tag of the attachment MUST NOT contain a colon and MUST NOT be longer than 64 characters. because of this, the <code>@id</code> can not contain a hashlink and MUST contain the multihash with a maximum length of 64 characters. When a hash is longer than 64 character, use the first 64 characters.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/issue-credential/%VER/issue-credential\",\n  \"@id\": \"&lt;uuid of issue message&gt;\",\n  \"goal_code\": \"&lt;goal-code&gt;\",\n  \"replacement_id\": \"&lt;issuer unique id&gt;\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"&lt;attach@id value&gt;\",\n      \"format\": \"hlindy/cred@v2.0\"\n    }\n  ],\n  \"credentials~attach\": [\n    {\n      \"@id\": \"&lt;attachment-id&gt;\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"json\": {\n          \"schema_id\": \"4RW6QK2HZhHxa2tg7t1jqt:2:catSchema:0.3.0\",\n          \"cred_def_id\": \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58161:default\",\n          \"values\": {\n            \"pictureOfACat\": {\n              \"raw\": \"hl:zQmcWyBPyedDzHFytTX6CAjjpvqQAyhzURziwiBKDKgqx6R\",\n              \"encoded\": \"hl:zQmcWyBPyedDzHFytTX6CAjjpvqQAyhzURziwiBKDKgqx6R\"\n            }\n          },\n          \"signature\": \"&lt;signature&gt;\",\n          \"signature_correctness_proof\": \"&lt;signature_correctness_proof&gt;\"\n        }\n      }\n    }\n  ],\n  \"~attach\": [\n    {\n      \"@id\": \"zQmcWyBPyedDzHFytTX6CAjjpvqQAyhzURziwiBKDKgqx6R\",\n      \"mime-type\": \"image/png\",\n      \"filename\": \"cat.png\",\n      \"byte_count\": 2181,\n      \"lastmod_time\": \"2021-04-20 19:38:07Z\",\n      \"description\": \"Cute picture of a cat\",\n      \"data\": {\n        \"base64\": \"VGhpcyBpcyBhIGNv ... (many bytes omitted) ... R0ZXIgU0hJQkEgSU5VLg==\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0641-linking-binary-objects-to-credentials/#hosted-attachments","title":"Hosted attachments","text":"<p>The last method of adding a binary object in a credential is by using the attachments decorator in combination with external hosting. In the example below the attachment is hosted at two locations. These two URLs MUST point to the same file and match the integrity check with the <code>sha256</code> value. It is important to note that when an issuer hosts an attachment, and issues a credential with this attachment, that the holder rehosts this attachment to prevent the phone-home assosiation.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/issue-credential/%VER/issue-credential\",\n  \"@id\": \"&lt;uuid of issue message&gt;\",\n  \"goal_code\": \"&lt;goal-code&gt;\",\n  \"replacement_id\": \"&lt;issuer unique id&gt;\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"&lt;attach@id value&gt;\",\n      \"format\": \"hlindy/cred@v2.0\"\n    }\n  ],\n  \"credentials~attach\": [\n    {\n      \"@id\": \"&lt;attachment-id&gt;\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"json\": {\n          \"schema_id\": \"4RW6QK2HZhHxa2tg7t1jqt:2:catSchema:0.3.0\",\n          \"cred_def_id\": \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58161:default\",\n          \"values\": {\n            \"pictureOfACat\": {\n              \"raw\": \"hl:zQmcWyBPyedDzHFytTX6CAjjpvqQAyhzURziwiBKDKgqx6R\",\n              \"encoded\": \"hl:zQmcWyBPyedDzHFytTX6CAjjpvqQAyhzURziwiBKDKgqx6R\"\n            }\n          },\n          \"signature\": \"&lt;signature&gt;\",\n          \"signature_correctness_proof\": \"&lt;signature_correctness_proof&gt;\"\n        }\n      }\n    }\n  ],\n  \"~attach\": [\n    {\n      \"@id\": \"zQmcWyBPyedDzHFytTX6CAjjpvqQAyhzURziwiBKDKgqx6R\",\n      \"mime-type\": \"application/zip\",\n      \"filename\": \"cat.zip\",\n      \"byte_count\": 218187322,\n      \"lastmod_time\": \"2021-04-20 19:38:07Z\",\n      \"description\": \"Cute pictures of multiple cats\",\n      \"data\": {\n        \"links\": [\n          \"https://drive.google.com/kitty/cats.zip\",\n          \"s3://bucket/cats.zip\"\n        ]\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0641-linking-binary-objects-to-credentials/#matching","title":"Matching","text":"<p>Now that a link has been made between the attachment in the attachments decorator, it is possible to match the two together. When a credential is received and a value of an attribute starts with <code>hl:</code> it means that there is a linked attachment. To find the linked attachment to the credential attribute to following steps SHOULD be done:</p> <ol> <li>Extract the multihash from the credential attribute value</li> <li>Extract the first 64 characters of this multihash</li> <li>Loop over the <code>@id</code> tag of all the attachments in the attachment decorator</li> <li>Compare the value of the <code>@id</code> tag with the multihash</li> <li>If the <code>@id</code> tag matches with the multihash, then there is a link</li> <li>An integrity check can be done with the original, complete hashlink</li> </ol>"},{"location":"features/0641-linking-binary-objects-to-credentials/#reference","title":"Reference","text":"<p>When an issuer creates a value in a credential attribute with a prefix of <code>hl:</code>, but there is no attachment, a warning SHOULD be thrown.</p> <p>When DIDcomm V2 is implemented the attachment decorator will not contain the <code>sha256</code> tag anymore and it will be replaced by <code>hash</code> to allow for any algorithm. DIDcomm messaging Attachments</p>"},{"location":"features/0641-linking-binary-objects-to-credentials/#drawbacks","title":"Drawbacks","text":"<ul> <li>Hashlinks, multibase and multihash are not confirmed IETF RFCs yet</li> <li>Hosting some files at third party locations is not preferred</li> </ul>"},{"location":"features/0641-linking-binary-objects-to-credentials/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>The findings that large credentials are inconsistent and resource intensive are derived from issuing and verifying credentials of 100 kilobytes to 50 megabytes in Aries Framework JavaScript and Aries Cloudagent Python.</p> <p>The Identity Foundation is currently working on confidential storage, a way to allow access to your files based on DIDs. This storage would be a sleek fix for the last drawback.</p>"},{"location":"features/0641-linking-binary-objects-to-credentials/#prior-art","title":"Prior art","text":"<ul> <li>0017: Attachments discusses the attachments in DIDcomm messaging and formulates the attachment decorator.</li> <li>HIPE-0139: Image As Attribute Via Aries-0036 Issue-Credential Protocol has been written for the support of images in credentials. It points out that the attachment RFC and the issue credential RFC are separate and could drift apart.</li> <li>Linking and Exchanging Attachments with Verifiable Credentials describes the linking between the attachment the credential based on the <code>@id</code> tag.</li> </ul>"},{"location":"features/0641-linking-binary-objects-to-credentials/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>N/A</li> </ul>"},{"location":"features/0641-linking-binary-objects-to-credentials/#implementations","title":"Implementations","text":"Name / Link Implementation Notes"},{"location":"features/0646-bbs-credentials/","title":"0646: W3C Credential Exchange using BBS+ Signatures","text":"<ul> <li>Authors: Timo Glastra (Animo Solutions), Brent Zundel (Evernym)</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-28</li> <li>Status Note:</li> <li>Supersedes:</li> <li>Start Date: 2021-04-15</li> <li>Tags: feature</li> </ul>"},{"location":"features/0646-bbs-credentials/#summary","title":"Summary","text":"<p>This RFC describes how the Hyperledger Aries community should use BBS+ Signatures that conform with the Linked-Data Proofs Specification to perform exchange of credentials that comply with the W3C Verifiable Credential specification.</p> <p>Key ../../features include:</p> <ul> <li>zero-knowledge proofs (ZKPs),</li> <li>selective disclosure,</li> <li>private holder binding,</li> <li>signature blinding,</li> <li>compatibility with privacy preserving revocation.</li> </ul> <p>This RFC sets guidelines for their safe usage and describes privacy-enabling ../../features that should be incorporated.</p> <p>The usage of zero-knowledge proofs, selective disclosure and signature blinding are already supported using the specifications as described in this document. Support for private holder binding and privacy preserving revocation will be added in the future.</p>"},{"location":"features/0646-bbs-credentials/#motivation","title":"Motivation","text":"<p>Aries currently supports credential formats used by Indy (Anoncreds based on JSON) and Aries-Framework-Go. BBS+ signatures with JSON-LD Proofs provide a unified credential format that includes strong privacy protecting anti-correlation ../../features and wide interoperability with verifiable credentials outside the Aries ecosystem.</p>"},{"location":"features/0646-bbs-credentials/#tutorial","title":"Tutorial","text":""},{"location":"features/0646-bbs-credentials/#issuing-credentials","title":"Issuing Credentials","text":"<p>This section highlights the process of issuing credentials with BBS+ signatures. The first section (Creating BBS+ Credentials) highlights the process of creating credentials with BBS+ signatures, while the next section focusses on the the process of exchanging credentials with BBS+ signatures (Exchanging BBS+ Credentials).</p>"},{"location":"features/0646-bbs-credentials/#creating-bbs-credentials","title":"Creating BBS+ Credentials","text":"<p>The process to create verifiable credentials with BBS+ signatures is mostly covered by the VC Data Model and BBS+ LD-Proofs specifications. At the date of writing this RFC, the BBS+ LD-Proofs specification still has some unresolved issues. The issues are documented in the Issues with the BBS+ LD-Proofs specification section below.</p> <p>Aries implementations MUST use the BBS+ Signature Suite 2020 to create verifiable credentials with BBS+ signatures, identified by the <code>BbsBlsSignature2020</code> proof type.</p> <p>NOTE: Once the signature suites for bound signatures (private holder binding) are defined in the BBS+ LD-Proofs spec, the use of the <code>BbsBlsSignature2020</code> suite will be deprecated and superseded by the <code>BbsBlsBoundSignature2020</code> signature suite. See Private Holder Binding below for more information.</p>"},{"location":"features/0646-bbs-credentials/#identifiers-in-issued-credentials","title":"Identifiers in Issued Credentials","text":"<p>It is important to note that due to limitations of the underlying RDF canonicalization scheme, which is used by BBS+ LD-Proofs, issued credentials SHOULD NOT have any <code>id</code> properties, as the value of these properties will be revealed during the RDF canonicalization process, regardless of whether or not the holder chooses to disclose them.</p> <p>Credentials can make use of other identifier properties to create selectively disclosable identifiers. An example of this is the <code>identifier</code> property from the Citizenship Vocabulary</p>"},{"location":"features/0646-bbs-credentials/#private-holder-binding","title":"Private Holder Binding","text":"<p>A private holder binding allows the holder of a credential to authenticate itself without disclosing a correlating identifier (such as a DID) to the verifier. The current BBS+ LD-Proofs specification does not describe a mechanism yet to do private holder binding, but it is expected this will be done using two new signature suites: <code>BbsBlsBoundSignature2020</code> and <code>BbsBlsBoundSignatureProof2020</code>. Both suites feature a commitment to a private key held by the credential holder, for which they prove knowledge of when deriving proofs without ever directly revealing the private key, nor a unique identifier linked to the private key (e.g its complementary public pair).</p>"},{"location":"features/0646-bbs-credentials/#usage-of-credential-schema","title":"Usage of Credential Schema","text":"<p>The zero-knowledge proof section of the VC Data Model requires verifiable credentials used in zero-knowledge proof systems to include a credential definition using the <code>credentialSchema</code> property. Due to the nature of how BBS+ LD proofs work, it is NOT required to include the <code>credentialSchema</code> property. See Issue 726 in the VC Data Model.</p>"},{"location":"features/0646-bbs-credentials/#example-bbs-credential","title":"Example BBS+ Credential","text":"<p>Below is a complete example of a Verifiable Credential with BBS+ linked data proof.</p> <pre><code>{\n  \"@context\": [\n    \"https://www.w3.org/2018/credentials/v1\",\n    \"https://w3id.org/citizenship/v1\",\n    \"https://w3id.org/security/bbs/v1\" // &lt;-- BBS+ context\n  ],\n  \"id\": \"https://issuer.oidp.uscis.gov/credentials/83627465\",\n  \"type\": [\"VerifiableCredential\", \"PermanentResidentCard\"],\n  \"issuer\": \"did:example:489398593\",\n  \"identifier\": \"83627465\", // &lt;-- `identifier` property allows for seletively disclosable id property\n  \"name\": \"Permanent Resident Card\",\n  \"description\": \"Government of Example Permanent Resident Card.\",\n  \"issuanceDate\": \"2019-12-03T12:19:52Z\",\n  \"expirationDate\": \"2029-12-03T12:19:52Z\",\n  \"credentialSubject\": {\n    \"id\": \"did:example:b34ca6cd37bbf23\",\n    \"type\": [\"PermanentResident\", \"Person\"],\n    \"givenName\": \"JOHN\",\n    \"familyName\": \"SMITH\",\n    \"gender\": \"Male\",\n    \"image\": \"data:image/png;base64,iVBORw0KGgokJggg==\",\n    \"residentSince\": \"2015-01-01\",\n    \"lprCategory\": \"C09\",\n    \"lprNumber\": \"999-999-999\",\n    \"commuterClassification\": \"C1\",\n    \"birthCountry\": \"Bahamas\",\n    \"birthDate\": \"1958-07-17\"\n  },\n  \"proof\": {\n    \"type\": \"BbsBlsSignature2020\", // &lt;-- type must be `BbsBlsSignature2020`\n    \"created\": \"2020-10-16T23:59:31Z\",\n    \"proofPurpose\": \"assertionMethod\",\n    \"proofValue\": \"kAkloZSlK79ARnlx54tPqmQyy6G7/36xU/LZgrdVmCqqI9M0muKLxkaHNsgVDBBvYp85VT3uouLFSXPMr7Stjgq62+OCunba7bNdGfhM/FUsx9zpfRtw7jeE182CN1cZakOoSVsQz61c16zQikXM3w==\",\n    \"verificationMethod\": \"did:example:489398593#test\"\n  }\n}\n</code></pre>"},{"location":"features/0646-bbs-credentials/#exchanging-bbs-credentials","title":"Exchanging BBS+ Credentials","text":"<p>While the process of creating credentials with BBS+ signatures is defined in specifications outside of Aries, the process of exchanging credentials with BBS+ signatures is defined within Aries.</p> <p>Credentials with BBS+ signatures can be exchanged by following RFC 0453: Issue Credential Protocol 2.0. The Issue Credential 2.0 provides a registry of attachment formats that can be used for credential exchange. Currently, agents are expected to use the format as described in RFC 0593 (see below).</p> <p>NOTE: Once Credential Manifest v1.0 is released, RFC 0593 is expected to be deprecated and replaced by an updated version of RFC 0511: Credential-Manifest Attachment format</p>"},{"location":"features/0646-bbs-credentials/#0593-json-ld-credential-attachment-format","title":"0593: JSON-LD Credential Attachment format","text":"<p>RFC 0593: JSON-LD Credential Attachment format for requesting and issuing credentials defines a very simple, feature-poor attachment format for issuing JSON-LD credentials.</p> <p>The only requirement for exchanging BBS+ credentials, in addition to the requirements as specified in Creating BBS+ Credentials and RFC 0593, is the <code>options.proofType</code> in the <code>ld-proof-vc-detail</code> MUST be <code>BbsBlsSignature2020</code>.</p>"},{"location":"features/0646-bbs-credentials/#presenting-derived-credentials","title":"Presenting Derived Credentials","text":"<p>This section highlights the process of creating and presenting derived BBS+ credentials containing a BBS+ proof of knowledge.</p>"},{"location":"features/0646-bbs-credentials/#deriving-credentials","title":"Deriving Credentials","text":"<p>Deriving credentials should be done according to the BBS+ Signature Proof Suite 2020</p>"},{"location":"features/0646-bbs-credentials/#disclosing-required-properties","title":"Disclosing Required Properties","text":"<p>A verifiable presentation MUST NOT leak information that would enable the verifier to correlate the holder across multiple verifiable presentations.</p> <p>The above section from the VC Data Model may give the impression that it is allowed to omit required properties from a derived credential if this prevents correlation. However things the holder chooses to reveal are in a different category than things the holder MUST reveal. Derived credentials MUST disclose required properties, even if it can correlate them.</p> <p>E.g. a credential with <code>issuanceDate</code> of <code>2017-12-05T14:27:42Z</code> could create a correlating factor. However it is against the VC Data Model to not include the property. Take this into account when issuing credentials.</p>"},{"location":"features/0646-bbs-credentials/#transforming-blank-node-identifiers","title":"Transforming Blank Node Identifiers","text":"<p>This section will be removed once Issue 10 in the LD Proof BBS+ spec is resolved.</p> <p>For the verifier to be able to verify the signature of a derived credential it should be able to deterministically normalize the credentials statements for verification. RDF Dataset Canonicalization defines a way in which to allocate identifiers for blank nodes deterministically for normalization. However, the algorithm does not guarantee that the same blank node identifiers will be allocated in the event of modifications to the graph. Because selective disclosure of signed statements modifies the graph as presented to the verifier, the blank node identifiers must be transformed into actual node identifiers when presented to the verifier.</p> <p>The BBS+ LD-Proofs specification does not define a mechanism to transform blank node identifiers into actual identifiers. Current implementations use the mechanism as described in this Issue Comment. Some reference implementations:</p> <ul> <li>Aries Framework Go</li> <li>JSON-LD Signatures BBS</li> <li>Aries Cloud Agent Python</li> </ul>"},{"location":"features/0646-bbs-credentials/#verifying-presented-derived-credentials","title":"Verifying Presented Derived Credentials","text":""},{"location":"features/0646-bbs-credentials/#transforming-back-into-blank-node-identifiers","title":"Transforming Back into Blank Node Identifiers","text":"<p>This section will be removed once Issue 10 in the LD Proof BBS+ spec is resolved.</p> <p>Transforming the blank node identifiers into actual node identifiers in the derived credential means the verification data will be different from the verification data at issuance, invalidating the signature. Therefore the blank node identifier placeholders should be transformed back into blank node identifiers before verification.</p> <p>Same as with Transforming Blank Node Identifiers, current implementations use the mechanism as described in this Issue Comment. Some reference implementations:</p> <ul> <li>Aries Framework Go</li> <li>JSON-LD Signatures BBS</li> <li>Aries Cloud Agent Python</li> </ul>"},{"location":"features/0646-bbs-credentials/#exchanging-derived-credentials","title":"Exchanging Derived Credentials","text":"<p>The presentation of credentials with BBS+ signatures can be exchanged by following RFC 0454: Present Proof Protocol 2.0. The Present Proof Protocol 2.0 provides a registry of attachment formats that can be used for presentation exchange. Although agents can use any attachment format they want, agents are expected to use the format as described in RFC 0510 (see below).</p>"},{"location":"features/0646-bbs-credentials/#0510-presentation-exchange-attachment-format","title":"0510: Presentation-Exchange Attachment format","text":"<p>RFC 0510: Presentation-Exchange Attachment format for requesting and presenting proofs defines an attachment format based on the DIF Presentation Exchange specification.</p> <p>The following part of this section describes the requirements of exchanging derived credentials using the Presentation Exchange Attachment format, in addition to the requirements as specified above and in RFC 0510.</p> <p>The Presentation Exchange MUST include the <code>ldp_vp</code> Claim Format Designation. In turn the <code>proof_type</code> property of the <code>ldp_vp</code> claim format designation MUST include the <code>BbsBlsSignatureProof2020</code> proof type.</p>"},{"location":"features/0646-bbs-credentials/#example-bbs-derived-credential","title":"Example BBS+ Derived Credential","text":"<pre><code>{\n  \"@context\": [\n    \"https://www.w3.org/2018/credentials/v1\",\n    \"https://w3id.org/citizenship/v1\",\n    \"https://w3id.org/security/bbs/v1\" // BBS + Context\n  ],\n  \"id\": \"https://issuer.oidp.uscis.gov/credentials/83627465\",\n  \"type\": [\"PermanentResidentCard\", \"VerifiableCredential\"],\n  \"description\": \"Government of Example Permanent Resident Card.\",\n  \"identifier\": \"83627465\",\n  \"name\": \"Permanent Resident Card\",\n  \"credentialSubject\": {\n    \"id\": \"did:example:b34ca6cd37bbf23\",\n    \"type\": [\"Person\", \"PermanentResident\"],\n    \"familyName\": \"SMITH\",\n    \"gender\": \"Male\",\n    \"givenName\": \"JOHN\"\n  },\n  \"expirationDate\": \"2029-12-03T12:19:52Z\",\n  \"issuanceDate\": \"2019-12-03T12:19:52Z\",\n  \"issuer\": \"did:example:489398593\",\n  \"proof\": {\n    \"type\": \"BbsBlsSignatureProof2020\", // &lt;-- type must be `BbsBlsSignatureProof2020`\n    \"nonce\": \"wrmPiSRm+iBqnGBXz+/37LLYRZWirGgIORKHIkrgWVnHtb4fDe/4ZPZaZ+/RwGVJYYY=\",\n    \"proofValue\": \"ABkB/wbvt6213E9eJ+aRGbdG1IIQtx+IdAXALLNg2a5ENSGOIBxRGSoArKXwD/diieDWG6+0q8CWh7CViUqOOdEhYp/DonzmjoWbWECalE6x/qtyBeE7W9TJTXyK/yW6JKSKPz2ht4J0XLV84DZrxMF4HMrY7rFHvdE4xV7ULeC9vNmAmwYAqJfNwY94FG2erg2K2cg0AAAAdLfutjMuBO0JnrlRW6O6TheATv0xZZHP9kf1AYqPaxsYg0bq2XYzkp+tzMBq1rH3tgAAAAIDTzuPazvFHijdzuAgYg+Sg0ziF+Gw5Bz8r2cuvuSg1yKWqW1dM5GhGn6SZUpczTXuZuKGlo4cZrwbIg9wf4lBs3kQwWULRtQUXki9izmznt4Go98X/ElOguLLum4S78Gehe1ql6CXD1zS5PiDXjDzAAAACWz/sbigWpPmUqNA8YUczOuzBUvzmkpjVyL9aqf1e7rSZmN8CNa6dTGOzgKYgDGoIbSQR8EN8Ld7kpTIAdi4YvNZwEYlda/BR6oSrFCquafz7s/jeXyOYMsiVC53Zls9KEg64tG7n90XuZOyMk9RAdcxYRGligbFuG2Ap+rQ+rrELJaW7DWwFEI6cRnitZo6aS0hHmiOKKtJyA7KFbx27nBGd2y3JCvgYO6VUROQ//t3F4aRVI1U53e5N3MU+lt9GmFeL+Kv+2zV1WssScO0ZImDGDOvjDs1shnNSjIJ0RBNAo2YzhFKh3ExWd9WbiZ2/USSyomaSK4EzdTDqi2JCGdqS7IpooKSX/1Dp4K+d8HhPLGNLX4yfMoG9SnRfRQZZQ==\",\n    \"verificationMethod\": \"did:example:489398593#test\",\n    \"proofPurpose\": \"assertionMethod\",\n    \"created\": \"2020-10-16T23:59:31Z\"\n  }\n}\n</code></pre>"},{"location":"features/0646-bbs-credentials/#privacy-considerations","title":"Privacy Considerations","text":"<p>Private Holder Binding is an evolution of CL Signatures Linked Secrets.</p> <ul> <li><code>id</code> properties are always disclosed in derived credentials due to how JSON-LD works.</li> <li>Required properties from the VC Data Model MUST be disclosed in derived credentials.</li> <li>BBS+ credentials SHOULD not be used in conjunction with non-ZKP signature as this removes the privacy ../../features of BBS.</li> </ul>"},{"location":"features/0646-bbs-credentials/#reference","title":"Reference","text":""},{"location":"features/0646-bbs-credentials/#interoperability-with-existing-credential-formats","title":"Interoperability with Existing Credential Formats","text":"<p>We expect that many issuers will choose to shift exclusively to BBS+ credentials for the benefits described here. Accessing these benefits will require reissuing credentials that were previously in a different format.</p> <p>An issuer can issue duplicate credentials with both signature formats.</p> <p>A holder can hold both types of credentials. The holder wallet could display the two credentials as a single entry in their credential list if the data is the same (it\u2019s \u201cenhanced\u201d with both credential formats).</p> <p>A verifier can send a proof request for the formats that they choose to support.</p> <ul> <li>The holder wallet can provide the credential that fulfills that proof restriction. This allows old credentials to continue being used without being reissued.</li> <li>The verifier may accept credentials of multiple formats.</li> </ul>"},{"location":"features/0646-bbs-credentials/#issues-with-the-bbs-ld-proofs-specification","title":"Issues with the BBS+ LD-Proofs specification","text":"<ul> <li><code>requiredRevealStatements</code> will be removed (Issue 50)</li> <li><code>proofValue</code> and <code>nonce</code> must be base64 encoded (Issue 51)</li> <li><code>signature</code> must be updated to <code>proofValue</code> for the <code>BbsBlsSignature2020</code> suite (Issue 52)</li> <li>The application of blank node identifiers (Issue 10)</li> <li>Private holder binding (Issue 37)</li> </ul>"},{"location":"features/0646-bbs-credentials/#drawbacks","title":"Drawbacks","text":"<p>Existing implementations of BBS+ Signatures do not support ZKP proof predicates, but it is theoretically possible to support numeric date predicates. ZKP proof predicates are considered a key feature of CL signatures, and a migration to BBS+ LD-Proofs will lose this capability. The Indy maintainers consider this a reasonable trade-off to get the other benefits of BBS+ LD-Proofs. A mechanism to support predicates can hopefully be added in future work.</p> <p>As mentioned in the Private Holder Binding section, the BBS+ LD-Proofs specification does not define a mechanism for private holder binding yet. This means implementing this RFC does not provide all privacy-enabling ../../features that should be incorporated until the <code>BbsBlsBoundSignature2020</code> and <code>BbsBlsBoundSignatureProof2020</code> signature suites are formally defined.</p>"},{"location":"features/0646-bbs-credentials/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>BBS+ LD-Proofs is a reasonable evolution of CL Signatures, as it supports most of the same ../../features (with the exception of ZKP Proof Predicates), while producing smaller credentials that require less computation resources to validate (a key requirement for mobile use cases).</p> <p>BBS+ LD-Proofs are receiving broad support across the verifiable credentials implementation community, so supporting this signature format will be strategic for interoperability and allow Aries to promote the privacy preserving capabilities such as zero knowledge proofs and private holder binding.</p>"},{"location":"features/0646-bbs-credentials/#prior-art","title":"Prior art","text":"<p>Indy Anoncreds used CL Signatures to meet many of the use cases currently envisioned for BBS+ LD-Proofs.</p> <p>BBS+ Signatures were originally proposed by Boneh, Boyen, and Shacham in 2004.</p> <p>The approach was improved by Au, Susilo, and Mu in 2006.</p> <p>It was then further refined by Camenisch, Drijvers, and Lehmann in section 4.3 of this paper from 2016.</p> <p>In 2019, Evernym and Sovrin proposed BBS+ Signatures as the foundation for Indy Anoncreds 2.0, which in conjunction with Rich Schemas addressed a similar set of goals and capabilities as those addressed here, but were ultimately too heavy a solution.</p> <p>In 2020, Mattr provided a draft specification for BBS+ LD-Proofs that comply with the Linked Data proof specification in the W3C Credentials Community Group. The authors acknowledged that their approach did not support two key Anoncreds ../../features: proof predicates and link secrets.</p> <p>Aries RFC 593 describes the JSON-LD credential format.</p>"},{"location":"features/0646-bbs-credentials/#unresolved-questions","title":"Unresolved questions","text":"<p>See the above note in the Drawbacks Section about ZKP predicates.</p>"},{"location":"features/0646-bbs-credentials/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0685-pickup-v2/","title":"0685: Pickup Protocol 2.0","text":"<ul> <li>Authors: Sam Curren, James Ebert</li> <li>Status: ACCEPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Initial version</li> <li>Start Date: 2020-12-22</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0685-pickup-v2/#summary","title":"Summary","text":"<p>A protocol to facilitate an agent picking up messages held at a mediator.</p>"},{"location":"features/0685-pickup-v2/#motivation","title":"Motivation","text":"<p>Messages can be picked up simply by sending a message to the Mediator with a <code>return_route</code> decorator specified. This mechanism is implicit, and lacks some desired behavior made possible by more explicit messages.</p> <p>This protocol is the explicit companion to the implicit method of picking up messages.</p>"},{"location":"features/0685-pickup-v2/#tutorial","title":"Tutorial","text":""},{"location":"features/0685-pickup-v2/#roles","title":"Roles","text":"<p>Mediator - The agent that has messages waiting for pickup by the Recipient.</p> <p>Recipient - The agent who is picking up messages.</p>"},{"location":"features/0685-pickup-v2/#flow","title":"Flow","text":"<p>The <code>status-request</code> message is sent by the Recipient to the Mediator to query how many messages are pending.</p> <p>The <code>status</code> message is the response to <code>status-request</code> to communicate the state of the message queue.</p> <p>The <code>delivery-request</code> message is sent by the Recipient to request delivery of pending messages.</p> <p>The <code>message-received</code> message is sent by the Recipient to confirm receipt of delivered messages,  prompting the Mediator to clear messages from the queue.</p> <p>The <code>live-delivery-change</code> message is used to set the state of <code>live_delivery</code>. </p> <ul> <li>When Live Mode is enabled, messages that arrive when an existing connection exists are delivered over the connection immediately,  rather than being pushed to the queue. See Live Mode for more details.</li> </ul>"},{"location":"features/0685-pickup-v2/#reference","title":"Reference","text":"<p>Each message sent MUST use the <code>~transport</code> decorator as follows, which has been adopted from RFC 0092 transport return route protocol. This has been omitted from the examples for brevity.</p> <pre><code>\"~transport\": {\n    \"return_route\": \"all\"\n}\n</code></pre>"},{"location":"features/0685-pickup-v2/#message-types","title":"Message Types","text":""},{"location":"features/0685-pickup-v2/#status-request","title":"Status Request","text":"<p>Sent by the Recipient to the Mediator to request a <code>status</code> message.</p>"},{"location":"features/0685-pickup-v2/#example","title":"Example:","text":"<pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"https://didcomm.org/messagepickup/2.0/status-request\",\n    \"recipient_key\": \"&lt;key for messages&gt;\"\n}\n</code></pre> <p><code>recipient_key</code> is optional. When specified, the Mediator MUST only return status related to that recipient key. This allows the Recipient to discover if any messages are in the queue that were sent to a specific key. You can find more details about <code>recipient_key</code> and how it's managed in 0211-route-coordination.</p>"},{"location":"features/0685-pickup-v2/#status","title":"Status","text":"<p>Status details about waiting messages.</p>"},{"location":"features/0685-pickup-v2/#example_1","title":"Example:","text":"<pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"https://didcomm.org/messagepickup/2.0/status\",\n    \"recipient_key\": \"&lt;key for messages&gt;\",\n    \"message_count\": 7,\n    \"longest_waited_seconds\": 3600,\n    \"newest_received_time\": \"2019-05-01 12:00:00Z\",\n    \"oldest_received_time\": \"2019-05-01 12:00:01Z\",\n    \"total_bytes\": 8096,\n    \"live_delivery\": false\n}\n</code></pre> <p><code>message_count</code> is the only REQUIRED attribute. The others MAY be present if offered by the Mediator.</p> <p><code>longest_waited_seconds</code> is in seconds, and is the longest delay of any message in the queue.</p> <p><code>total_bytes</code> represents the total size of all messages.</p> <p>If a <code>recipient_key</code> was specified in the <code>status-request</code> message, the matching value MUST be specified  in the <code>recipient_key</code> attribute of the status message.</p> <p><code>live_delivery</code> state is also indicated in the status message. </p> <p>Note: due to the potential for confusing what the actual state of the message queue is, a status message MUST NOT be put on the pending message queue and MUST only be sent when the Recipient is actively connected (HTTP request awaiting response, WebSocket, etc.).</p>"},{"location":"features/0685-pickup-v2/#delivery-request","title":"Delivery Request","text":"<p>A request from the Recipient to the Mediator to have pending messages delivered. </p>"},{"location":"features/0685-pickup-v2/#examples","title":"Examples:","text":"<pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"https://didcomm.org/messagepickup/2.0/delivery-request\",\n    \"limit\": 10,\n    \"recipient_key\": \"&lt;key for messages&gt;\"\n}\n</code></pre> <pre><code>{\n    \"@type\": \"https://didcomm.org/messagepickup/2.0/delivery-request\",\n    \"limit\": 1\n}\n</code></pre> <p><code>limit</code> is a REQUIRED attribute, and after receipt of this message, the Mediator SHOULD deliver up to the <code>limit</code> indicated. </p> <p><code>recipient_key</code> is optional. When specified, the Mediator MUST only return messages sent to that recipient key.</p> <p>If no messages are available to be sent, a <code>status</code> message MUST be sent immediately.</p> <p>Delivered messages MUST NOT be deleted until delivery is acknowledged by a <code>messages-received</code> message.</p>"},{"location":"features/0685-pickup-v2/#message-delivery","title":"Message Delivery","text":"<p>Messages delivered from the queue must be delivered in a batch <code>delivery</code> message as attachments. The ID of each attachment is used to confirm receipt. The ID is an opaque value, and the Recipient should not infer anything from the value.</p> <p>The ONLY valid type of attachment for this message is a DIDComm Message in encrypted form.</p> <p>The <code>recipient_key</code> attribute is only included when responding to a <code>delivery-request</code> message that indicates a <code>recipient_key</code>.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"~thread\": {\n        \"thid\": \"&lt;message id of delivery-request message&gt;\"\n      },\n    \"@type\": \"https://didcomm.org/messagepickup/2.0/delivery\",\n    \"recipient_key\": \"&lt;key for messages&gt;\",\n    \"~attach\": [{\n        \"@id\": \"&lt;messageid&gt;\",\n        \"data\": {\n            \"base64\": \"\"\n        }\n    }]\n}\n</code></pre> <p>This method of delivery does incur an encoding cost, but is much simpler to implement and a more robust interaction.</p>"},{"location":"features/0685-pickup-v2/#messages-received","title":"Messages Received","text":"<p>After receiving messages, the Recipient sends an ack message indiciating  which messages are safe to clear from the queue.</p>"},{"location":"features/0685-pickup-v2/#example_2","title":"Example:","text":"<pre><code>{\n    \"@type\": \"https://didcomm.org/messagepickup/2.0/messages-received\",\n    \"message_id_list\": [\"123\",\"456\"]\n}\n</code></pre> <p><code>message_id_list</code> is a list of ids of each message received. The id of each message is present in the attachment descriptor of each attached message of a <code>delivery</code> message.</p> <p>Upon receipt of this message, the Mediator knows which messages have been received, and can remove them from the collection of queued messages with confidence. The mediator SHOULD send an updated <code>status</code> message reflecting the changes to the queue.</p>"},{"location":"features/0685-pickup-v2/#multiple-recipients","title":"Multiple Recipients","text":"<p>If a message arrives at a Mediator addressed to multiple Recipients, the message MUST be queued for each Recipient independently. If one of the addressed Recipients retrieves a message and indicates it has been received, that message MUST still be held and then removed by the other addressed Recipients.</p>"},{"location":"features/0685-pickup-v2/#live-mode","title":"Live Mode","text":"<p>Live mode is the practice of delivering newly arriving messages directly to a connected Recipient. It is disabled by default and only activated by the Recipient. Messages that arrive when Live Mode is off MUST be stored in the queue for retrieval as described above. If Live Mode is active, and the connection is broken, a new inbound connection starts with Live Mode disabled.</p> <p>Messages already in the queue are not affected by Live Mode - they must still be requested with <code>delivery-request</code> messages.</p> <p>Live mode MUST only be enabled when a persistent transport is used, such as WebSockets.</p> <p>Recipients have three modes of possible operation for message delivery with various abilities and level of development complexity:</p> <ol> <li>Never activate live mode. Poll for new messages with a <code>status_request</code> message, and retrieve them when available.</li> <li>Retrieve all messages from queue, and then activate Live Mode. This simplifies message processing logic in the Recipient.</li> <li>Activate Live Mode immediately upon connecting to the Mediator. Retrieve messages from the queue as possible. When receiving a message delivered live, the queue may be queried for any waiting messages delivered to the same key for processing.</li> </ol>"},{"location":"features/0685-pickup-v2/#live-mode-change","title":"Live Mode Change","text":"<p>Live Mode is changed with a <code>live-delivery-change</code> message.</p>"},{"location":"features/0685-pickup-v2/#example_3","title":"Example:","text":"<pre><code>{\n    \"@type\": \"https://didcomm.org/messagepickup/2.0/live-delivery-change\",\n    \"live_delivery\": true\n}\n</code></pre> <p>Upon receiving the <code>live_delivery_change</code> message, the Mediator MUST respond with a <code>status</code> message.</p> <p>If sent with <code>live_delivery</code> set to <code>true</code> on a connection incapable of live delivery, a <code>problem_report</code> SHOULD be sent as follows:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/notification/1.0/problem-report\",\n  \"~thread\": {\n    \"pthid\": \"&lt;message id of offending live_delivery_change&gt;\"\n  },\n  \"description\": \"Connection does not support Live Delivery\"\n}\n</code></pre>"},{"location":"features/0685-pickup-v2/#prior-art","title":"Prior art","text":"<p>Version 1.0 of this protocol served as the main inspiration for this version. Version 1.0 suffered from not being very explicit, and an incomplete model of message delivery signaling.</p>"},{"location":"features/0685-pickup-v2/#alternatives","title":"Alternatives","text":"<ul> <li>An alternative to deriving a message ID is to wrap each message in a delivery wrapper. This would enable the mediator to include a mediator managed id and metadata along with the message itself, but carries the downside of double encrypting messages and extra processing.</li> </ul>"},{"location":"features/0685-pickup-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0693-credential-representation/","title":"0693: Cross-Platform Credential Representation","text":"<ul> <li>Authors: Horacio Nunez (Kiva Protocol)</li> <li>Status: PROPOSED</li> <li>Since: 2021-07-06</li> <li>Status Note:</li> <li>Supersedes:</li> <li>Start Date: 2021-02-10</li> <li>Tags: feature</li> </ul>"},{"location":"features/0693-credential-representation/#summary","title":"Summary","text":"<p>Aries Agent developers currently build end user products without a standard method of rendering credentials. This RFC proposes how the Aries community can reuse available open technologies to build such a rendering method.</p> <p>Key results include: - Feasibility of cross platform rendering. - Enable branding of credentials.</p> <p>This RFC also enumerate the specific challenges that by using this method could be tackled next.</p>"},{"location":"features/0693-credential-representation/#motivation","title":"Motivation","text":"<p>The human computer interaction between agents and their users will always gravitate around credentials. This interaction is more useful for users when their representation resembles that of their conventional  (physical) counterparts.</p> <p>Achieving effortless semiotic parity with analog credentials doesn't come easy or cheap.  In fact, when reviewing new Aries-base projects, is always the case that the rendering of  credentials with any form of branding is a demanding portion of the roadmap.</p> <p>Since the work required here is never declarative the work never stops feeling sysyphean. Indeed, the cost of writing code of representing a credential remains constant over time, no matter how many times we do it.</p> <p>Imagine if we achieve declarative while empowering branding.</p>"},{"location":"features/0693-credential-representation/#entering-svg","title":"Entering SVG","text":"<p>The solution we propose is to adopt SVG as the default format to describe how to represent SSI credentials, and to  introduce a convention to ensure that credentials values could be embedded in the final user interface.  The following images illustrates how this can work:</p> <p></p>"},{"location":"features/0693-credential-representation/#svg-credential-values","title":"SVG + Credential Values","text":"<p>We propose a notation of the form <code>{{credential.values.[AttributeName]}}</code> and <code>{{credential.names.[AttributeName]}}</code>. This way both values and attributes names can be used in branding activities.</p>"},{"location":"features/0693-credential-representation/#cross-platform","title":"Cross Platform","text":"<p>Since SVG is a web standard based on XML there isn't a shortage of existing tools to power brand and engineering needs  right away. Indeed, any implementation will be powered by native SVG renderer and XML parser.</p>"},{"location":"features/0693-credential-representation/#future-work","title":"Future work","text":"<ul> <li>(RFC) A default credential representation to serves as community baseline</li> <li>(RFC) How to communicate the designated credential representation among agents.</li> <li>(RFC) Expand metadata available to include Revocation status.</li> <li>(Dev Tool) Standalone desktop tool to help design/brand a credential stored in an agent.</li> </ul>"},{"location":"features/0699-push-notifications-apns/","title":"Aries RFC 0699: Push Notifications apns Protocol 1.0","text":"<ul> <li>Authors: Timo Glastra (Animo Solutions) &amp; Berend Sliedrecht (Animo Solutions)</li> <li>Status: PROPOSED</li> <li>Since: 2021-10-07</li> <li>Status Note: Initial version</li> <li>Start Date: 2021-05-05</li> <li>Tags: feature, protocol</li> </ul> <p>Note: This protocol is currently written to support native push notifications for iOS via Apple Push Notification Service. For the implementation for Android (using fcm), please refer to 0734: Push Notifications fcm</p>"},{"location":"features/0699-push-notifications-apns/#summary","title":"Summary","text":"<p>A protocol to coordinate a push notification configuration between two agents.</p>"},{"location":"features/0699-push-notifications-apns/#motivation","title":"Motivation","text":"<p>This protocol would give an agent enough information to send push notifications about specific events to an iOS device. This would be of great benefit for mobile wallets, as a holder can be notified when new messages are pending at the mediator. Mobile applications, such as wallets, are often killed and can not receive messages from the mediator anymore. Push notifications would resolve this problem.</p>"},{"location":"features/0699-push-notifications-apns/#tutorial","title":"Tutorial","text":""},{"location":"features/0699-push-notifications-apns/#name-and-version","title":"Name and Version","text":"<p>URI: <code>https://didcomm.org/push-notifications-apns/1.0</code></p> <p>Protocol Identifier: <code>push-notifications-apns</code></p> <p>Version: <code>1.0</code></p> <p>Since apns only supports iOS, no <code>-ios</code> or <code>-android</code> is required as it is implicit.</p>"},{"location":"features/0699-push-notifications-apns/#key-concepts","title":"Key Concepts","text":"<p>When an agent would like to receive push notifications at record event changes, e.g. incoming credential offer, incoming connection request, etc., the agent could initiate the protocol by sending a message to the other agent.</p> <p>This protocol only defines how an agent would get the token which is necessary for push notifications.</p> <p>Each platform is has its own protocol so that we can easily use 0031: Discover Features 1.0 and 0557: Discover Features 2.X to see which specific services are supported by the other agent.</p>"},{"location":"features/0699-push-notifications-apns/#roles","title":"Roles","text":"<p>notification-sender</p> <p>notification-receiver</p> <p>The notification-sender is an agent who will send the notification-receiver notifications. The notification-receiver can get and set their push notification configuration at the notification-sender.</p>"},{"location":"features/0699-push-notifications-apns/#services","title":"Services","text":"<p>This RFC focusses on configuring the data necessary for pushing notifications to iOS, via apns.</p> <p>In order to implement this protocol, the set-device-info and get-device-info messages MUST be implemented by the notification-sender and device-info message MUST be implemented by the notification-receiver.</p>"},{"location":"features/0699-push-notifications-apns/#supported-services","title":"Supported Services","text":"<p>The protocol currently supports the following push notification services</p> <ul> <li>apns for iOS devices</li> </ul>"},{"location":"features/0699-push-notifications-apns/#messages","title":"Messages","text":"<p>When a notification-receiver wants to receive push notifications from the notification-sender, the notification-receiver has to send the following message:</p>"},{"location":"features/0699-push-notifications-apns/#set-device-info","title":"Set Device Info","text":"<p>Message to set the device info using the native iOS device token for push notifications.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-apns/1.0/set-device-info\",\n  \"@id\": \"&lt;UUID&gt;\",\n  \"device_token\": \"&lt;DEVICE_TOKEN&gt;\"\n}\n</code></pre> <p>Description of the fields:</p> <ul> <li><code>device_token</code> -- The token that is required by the notification provider (string, null)</li> </ul> <p>It is important to note that the set device info message can be used to set, update and remove the device info. To set, and update, these values the normal messages as stated above can be used. To remove yourself from receiving push notifications, you can send the same message where all values MUST be <code>null</code>. If either value is <code>null</code> a <code>problem-report</code> MAY be sent back with <code>missing-value</code>.</p>"},{"location":"features/0699-push-notifications-apns/#get-device-info","title":"Get Device Info","text":"<p>When a notification-receiver wants to get their push-notification configuration, they can send the following message:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-apns/1.0/get-device-info\",\n  \"@id\": \"&lt;UUID&gt;\"\n}\n</code></pre>"},{"location":"features/0699-push-notifications-apns/#device-info","title":"Device Info","text":"<p>Response to the get device info:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-apns/1.0/device-info\",\n  \"device_token\": \"&lt;DEVICE_TOKEN&gt;\",\n  \"~thread\": {\n    \"thid\": \"&lt;GET_DEVICE_INFO_UUID&gt;\"\n  }\n}\n</code></pre> <p>This message can be used by the notification-receiver to receive their device info, e.g. <code>device_token</code>. If the notification-sender does not have this field for that connection, a <code>problem-report</code> MAY be used as a response with <code>not-registered-for-push-notifications</code>.</p>"},{"location":"features/0699-push-notifications-apns/#adopted-messages","title":"Adopted messages","text":"<p>In addition, the <code>ack</code> message is adopted into the protocol for confirmation by the notification-sender. The ack message SHOULD be sent in response to any of the set-device-info messages.</p>"},{"location":"features/0699-push-notifications-apns/#sending-push-notifications","title":"Sending Push Notifications","text":"<p>When an agent wants to send a push notification to another agent, the payload of the push notifications MUST include the <code>@type</code> property, and COULD include the <code>message_tag</code> property, to indicate the message is sent by the notification-sender. Guidelines on notification messages are not defined.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-apns\",\n  \"message_tag\": \"&lt;MESSAGE_TAG&gt;\",\n  \"message_id\": \"&lt;MESSAGE_ID&gt;\",\n  ...\n}\n</code></pre> <p>Description of the fields:</p> <ul> <li><code>@type</code> -- Indicator of what kind of notification it is. (This could help the notification-receiver with parsing if a notification comes from another agent, for example)</li> <li><code>message_tag</code> -- Optional field to connect the push notification to a DIDcomm message. As defined in 0334: jwe-envelope or 0019: encryption-envelope.</li> <li><code>message_id</code> -- Optional field to pickup the message from the mediator that the notification was linked to. As defined in 0685: Pickup Protocol 2.0.</li> </ul>"},{"location":"features/0699-push-notifications-apns/#drawbacks","title":"Drawbacks","text":"<p>Each service requires a considerable amount of domain knowledge. The RFC can be extended with new services over time.</p> <p>The <code>@type</code> property in the push notification payload currently doesn't indicate which agent the push notification came from. In e.g. the instance of using multiple mediators, this means the notification-receiver does not know which mediator to retrieve the message from.</p>"},{"location":"features/0699-push-notifications-apns/#prior-art","title":"Prior art","text":"<ul> <li>This RFC is based on the implementation of the <code>AddDeviceInfoMessage</code> in Aries Framework .NET</li> </ul>"},{"location":"features/0699-push-notifications-apns/#unresolved-questions","title":"Unresolved questions","text":"<p>None</p>"},{"location":"features/0699-push-notifications-apns/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0721-revocation-notification-v2/","title":"Aries RFC 0721: Revocation Notification 2.0","text":"<ul> <li>Authors: Keith Smith, Daniel Bluhm, James Ebert</li> <li>Status: ACCEPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Updates the credential identifiers format after discussions while implementing RFC 0183 Revocation Notification</li> <li>Supersedes: RFC 0183 Revocation Notification</li> <li>Start Date: 2021-11-01</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0721-revocation-notification-v2/#summary","title":"Summary","text":"<p>This RFC defines the message format which an issuer uses to notify a holder that a previously issued credential has been revoked.</p>"},{"location":"features/0721-revocation-notification-v2/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> </ul>"},{"location":"features/0721-revocation-notification-v2/#motivation","title":"Motivation","text":"<p>We need a standard protocol for an issuer to notify a holder that a previously issued credential has been revoked or unrevoked.</p> <p>For example, suppose a passport agency revokes Alice's passport. The passport agency (an issuer) may want to notify Alice (a holder) that her passport has been revoked so that she knows that she will be unable to use her passport to travel.</p>"},{"location":"features/0721-revocation-notification-v2/#tutorial","title":"Tutorial","text":"<p>The Revocation Notification protocol is a very simple protocol consisting of two messages:</p> <ul> <li>Revoke - issuer to holder</li> <li>Unrevoke - issuer to holder</li> </ul> <p>This simple protocol allows an issuer to choose to notify a holder that a previously issued credential has been revoked or unrevoked.</p> <p>It is the issuer's prerogative whether or not to notify the holder that a credential has been (un)revoked.  It is not a security risk if the issuer does not notify the holder that the credential has been (un)revoked, nor if the message is lost.  The holder will still be unable to use a revoked credential without this notification.</p>"},{"location":"features/0721-revocation-notification-v2/#roles","title":"Roles","text":"<p>There are two parties involved in a Revocation Notification: <code>issuer</code> and <code>holder</code>. The <code>issuer</code> sends the <code>revoke</code> or <code>unrevoke</code> message to the <code>holder</code>.</p>"},{"location":"features/0721-revocation-notification-v2/#messages","title":"Messages","text":""},{"location":"features/0721-revocation-notification-v2/#revoke","title":"Revoke","text":"<p>The <code>revoke</code> message sent by the <code>issuer</code> to the <code>holder</code>. The holder should verify that the <code>revoke</code> message came from the connection that was originally used to issue the credential.</p> <p>Message format:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/revocation_notification/2.1/revoke\",\n  \"@id\": \"&lt;uuid-revocation-notification&gt;\",\n  \"revocation_format\": \"&lt;revocation_format&gt;\",\n  \"credential_id\": \"&lt;credential_id&gt;\",\n  \"comment\": \"Some comment\"\n}\n</code></pre> <p>Description of fields:</p> <ul> <li> <p><code>revocation_format</code> (required) -- the format of the credential revocation. Accepted values for the revocation format are provided in the \"Revocation Credential Identification Formats\" section immediately below.</p> </li> <li> <p><code>credential_id</code> (required) -- the individual credential identifier of a credential issued using the issue-credential-v2 protocol that has been revoked by the issuer. Accepted values for the credential id format are provided in the \"Revocation Credential Identification Formats\" section immediately below.</p> </li> <li> <p><code>comment</code> (optional) -- a field that provides some human readable information about the revocation notification.  This is typically the reason for the revocation as deemed appropriate by the issuer.</p> </li> </ul>"},{"location":"features/0721-revocation-notification-v2/#unrevoke","title":"Unrevoke","text":"<p>The <code>unrevoke</code> message sent by the <code>issuer</code> to the <code>holder</code>. The holder should verify that the <code>unrevoke</code> message came from the connection that was originally used to issue the credential.</p> <p>Message format:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/revocation_notification/2.1/unrevoke\",\n  \"@id\": \"&lt;uuid-revocation-notification&gt;\",\n  \"revocation_format\": \"&lt;revocation_format&gt;\",\n  \"credential_id\": \"&lt;credential_id&gt;\",\n  \"comment\": \"Some comment\"\n}\n</code></pre> <p>Description of fields:</p> <ul> <li> <p><code>revocation_format</code> (required) -- the format of the credential revocation. Accepted values for the revocation format are provided in the \"Revocation Credential Identification Formats\" section immediately below.</p> </li> <li> <p><code>credential_id</code> (required) -- the individual credential identifier of a credential issued using the issue-credential-v2 protocol that has been revoked by the issuer. Accepted values for the credential id format are provided in the \"Revocation Credential Identification Formats\" section immediately below.</p> </li> <li> <p><code>comment</code> (optional) -- a field that provides some human readable information about the revocation notification.  This is typically the reason for the revocation as deemed appropriate by the issuer.</p> </li> </ul>"},{"location":"features/0721-revocation-notification-v2/#revocation-credential-identification-formats","title":"Revocation Credential Identification Formats","text":"<p>In order to support multiple credential revocation formats, the following dictates the format of revocation formats and their credential ids. As additional credential revocation formats are determined their credential id formats should be added.</p> Revocation Format Credential Identifier Format Example <code>indy-anoncreds</code> <code>&lt;revocation-registry-id&gt;::&lt;credential-revocation-id&gt;</code> <code>AsB27X6KRrJFsqZ3unNAH6:4:AsB27X6KRrJFsqZ3unNAH6:3:cl:48187:default:CL_ACCUM:3b24a9b0-a979-41e0-9964-2292f2b1b7e9::1</code> <code>anoncreds</code> <code>&lt;revocation-registry-id&gt;::&lt;credential-revocation-id&gt;</code> <code>did:indy:sovrin:5nDyJVP1NrcPAttP3xwMB9/anoncreds/v0/REV_REG_DEF/56495/npdb/TAG1::1</code>"},{"location":"features/0721-revocation-notification-v2/#reference","title":"Reference","text":"<ul> <li>See the issue-credential-v2 protocol.</li> <li>See the Please ACK Decorator RFC.</li> </ul>"},{"location":"features/0721-revocation-notification-v2/#drawbacks","title":"Drawbacks","text":"<p>If we later added support for more general event subscription and notification message flows, this would be redundant.</p>"},{"location":"features/0721-revocation-notification-v2/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?  It is simple.</li> <li>What other designs have been considered and what is the rationale for not choosing them?  A more general event subscription and notification mechanism was considered but chose to keep this simple for the same reasons that the basic message was kept simple.</li> <li>What is the impact of not doing this?  There is no standard way of sending a revocation notification which is a common scenario.</li> </ul>"},{"location":"features/0721-revocation-notification-v2/#prior-art","title":"Prior art","text":""},{"location":"features/0721-revocation-notification-v2/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"features/0721-revocation-notification-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0728-device-binding-attachments/","title":"Aries RFC 0728 : Device Binding Attachments","text":"<ul> <li>Authors: Paul Bastian, Sebastian Bickerle</li> <li>Status: PROPOSED</li> <li>Since: 2022-04-07</li> <li>Status Note: This is an initial draft</li> <li>Start Date: 2022-01-01</li> <li>Tags: feature</li> </ul>"},{"location":"features/0728-device-binding-attachments/#summary","title":"Summary","text":"<p>Extends existing present-proof protocols to allow proofing the control of a hardware bound key embedded within a verfiable credential.</p>"},{"location":"features/0728-device-binding-attachments/#motivation","title":"Motivation","text":"<p>To enable use-cases which require a high level of assurance a verifier must reach a high degree of confidence that a verifiable credential (VC) can only be used by the person it was issued for. One way to enforce this requirement is that the issuer additionally binds the VC to a hardware bound public key and therefore binding the credential to the device, as discussed in the DIF Wallet Security WG. The issaunce process, including the attestation of the wallet and the hardware bound key is off-scope for this Aries RFC. A valid presentation of the VC then requires an additional challenge which proofs that the presenter is in control of the corresponding private key. Since the proof of control must be part of legitimate presentation it makes sense to extend all current <code>present-proof</code> protocols.</p> <p>Note: The focus so far has been on AnonCreds, we will also look into device binding of W3C VC, however this is currently lacking in the examples.</p> <p>Warning: This concept is primarily meant for regulated, high-security usecases. Please review the drawbacks before considering using this.</p>"},{"location":"features/0728-device-binding-attachments/#tutorial","title":"Tutorial","text":"<p>To proof the control of a hardware bound key the holder must answer a challenge for one or more public keys embedded within verifiable credentials.</p>"},{"location":"features/0728-device-binding-attachments/#challenge","title":"Challenge","text":"<p>The following challenge object must be provided by the verifier.</p>"},{"location":"features/0728-device-binding-attachments/#device-binding-challenge","title":"device-binding-challenge","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/device-binding/%ver/device-binding-challenge\",\n  \"@id\": \"&lt;uuid-challenge-response&gt;\",\n  \"nonce\": \"&lt;nonce&gt;\", // recommend at least 128-bit unsigned integer\n  \"requests\": [\n    {\n      \"id\": \"libindy-request-presentation-0\",\n      \"path\": \"$.requested_attributes.attr2_referent.names.hardwareDid\"\n    }\n  ]\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>nonce</code> -- a nonce which has to be signed by the holder to proof control</li> <li><code>requests</code> -- an array of referenced presentation requests</li> <li><code>id</code> -- reference to an attached presentation request of <code>request-presentation</code> message (e.g. libindy request)</li> <li><code>path</code> -- JsonPath to a requested attribute which represents a public key of a hardware bound key pair - represented as did:key</li> </ul> <p>The <code>device-binding-challenge</code> must be attached to the <code>request-presentations~attach</code> array of the <code>request-presentation</code> message defined by RFC-0037 and RFC-0454.</p>"},{"location":"features/0728-device-binding-attachments/#example-request-presentation-messages","title":"Example request-presentation messages","text":"<p>The following represents a request-presentation message with an attached libindy presentation request and a corresponding device-binding-challenge.</p> <p>Present Proof v1</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/request-presentation\",\n    \"@id\": \"&lt;uuid-request&gt;\",\n    \"comment\": \"some comment\",\n    \"request_presentations~attach\": [\n        {\n            \"@id\": \"libindy-request-presentation-0\",\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ],\n    \"device_binding~attach\": [\n        {\n            \"@id\": \"device-binding-challenge-0\"\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;device-binding-challenge&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Present Proof v2</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/2.0/request-presentation\",\n    \"@id\": \"&lt;uuid-request&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"some comment\",\n    \"will_confirm\": true,\n    \"present_multiple\": false,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"libindy-request-presentation-0\",\n            \"format\" : \"hlindy/proof-req@v2.0\",\n        }\n    ],\n    \"request_presentations~attach\": [\n        {\n            \"@id\": \"libindy-request-presentation-0\",\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;base64 data&gt;\"\n            }\n        }\n    ],\n    \"device_binding~attach\": [\n        {\n            \"@id\": \"device-binding-challenge-0\"\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;device-binding-challenge&gt;\" // inner object\n            }\n        }\n    ]\n}\n</code></pre>"},{"location":"features/0728-device-binding-attachments/#response","title":"Response","text":"<p>The following response must be generated by the holder of the VC.</p>"},{"location":"features/0728-device-binding-attachments/#device-binding-reponse","title":"device-binding-reponse","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/device-binding/%ver/device-binding-response\",\n  \"@id\": \"&lt;uuid-challenge-response&gt;\",\n  \"proofs\": [\n    {\n      \"id\": \"libindy-presentation-0\",\n      \"path\": \"$.requested_proof.revealed_attrs.attr1_referent.raw\"\n    }\n  ]\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>proofs</code> -- an array of proofs for different hardware keys which must match the <code>requests</code> array from the device-binding-challenge</li> <li><code>id</code> -- reference to presentation of VC with an embeded hardware bound key</li> <li><code>path</code> -- JsonPath to raw value of hardware bound public key within the attached presentation of the VC represented as did:key</li> </ul> <p>The <code>device-binding-response</code> must be attached to the <code>device_binding~attach</code> array of a <code>presentation</code> message defined by RFC-0037 or RFC-0454.</p> <ul> <li><code>jws</code> -- Nonce from device-binding-challenge signed with the corresponding private key as a Json Web Signature object, acording to Aries RFC-0017.</li> </ul>"},{"location":"features/0728-device-binding-attachments/#example-presentation-messages","title":"Example presentation messages","text":"<p>The following represents a presentation message with an attached libindy presentation and a corresponding device-binding-response.</p> <p>Present Proof v1</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/present-proof/1.0/presentation\",\n  \"@id\": \"&lt;uuid-presentation&gt;\",\n  \"comment\": \"some comment\",\n  \"presentations~attach\": [\n    {\n      \"@id\": \"libindy-presentation-0\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"&lt;bytes for base64&gt;\"\n      }\n    }\n  ],\n  \"device_binding~attach\": [\n    {\n      \"@id\": \"device-binding-response-0\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"&lt;device-binding-response&gt;\",\n        \"jws\": {\n          \"header\": {\n            \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n          },\n          \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n          \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n        }\n      }\n    }\n  ]\n}\n</code></pre> <p>Present Proof v2</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/presentation\",\n    \"@id\": \"&lt;uuid-presentation&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"some comment\",\n    \"last_presentation\": true,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"libindy-presentation-0\",\n            \"format\" : \"hlindy/proof-req@v2.0\",\n        }\n    ],\n    \"presentations~attach\": [\n        {\n            \"@id\": \"libindy-presentation-0\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;libindy presentation&gt;\"\n            }\n        }\n    ],\n    \"device_binding~attach\": [\n        {\n            \"@id\": \"device-binding-response-0\"\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;device-binding-response&gt;\",\n                \"jws\": {\n                    \"header\": {\n                        \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n                    },\n                    \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n                    \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n                }\n            }\n        }\n    ]\n}\n</code></pre>"},{"location":"features/0728-device-binding-attachments/#reference","title":"Reference","text":"<ul> <li>DIF Wallet Security Github Page</li> </ul>"},{"location":"features/0728-device-binding-attachments/#drawbacks","title":"Drawbacks","text":"<p>Including a hardware-bound public key (as an attribute) into a Verifiable Credential/AnonCred is necessary for this concept but introduces a globally unique and therefore trackable identifier. As this public key is revealed to the verifier, there is a higher risk of correlation. The Issuer must always use a hardware-bound key for a single credential and the Wallet should enforce to never reuse the key. Additionally, the holder should ideally be informed about the increased correlation risk by the wallet UX.</p>"},{"location":"features/0728-device-binding-attachments/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>The rationale behind this proposal is to formalize the way a holder wallet can proof the control of a (hardware-bound) key.</p> <p>This proposal tries to extend existing protocols to reduce the implementation effort for existing solutions. It might be reasonable to include this only in a new version of the present proof protocol (e.g. present-proof v3).</p>"},{"location":"features/0728-device-binding-attachments/#prior-art","title":"Prior art","text":"<p>None to our knowledge.</p>"},{"location":"features/0728-device-binding-attachments/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What is the best way to reference hardware bound keys within VCs and presentations?</li> <li>Do we need a standardised attribute name for the hardware backed public key (e.g. \"HardwareDid\")</li> <li>Can we just reference the hardware key within the request object?</li> <li>Is it required to explicitly define the accepted signing algorithm within the <code>device-binding-challenge</code> object?</li> <li>What kind of key encoding do we choose?</li> <li>did:key, base64-encoded JWK and did:jwk in discussion</li> </ul>"},{"location":"features/0728-device-binding-attachments/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0734-push-notifications-fcm/","title":"Aries RFC 0734: Push Notifications fcm Protocol 1.0","text":"<ul> <li>Authors: Timo Glastra (Animo Solutions) &amp; Berend Sliedrecht (Animo Solutions)</li> <li>Status: PROPOSED</li> <li>Since: 2022-05-12</li> <li>Status Note: Initial version</li> <li>Start Date: 2022-05-12</li> <li>Tags: feature, protocol</li> </ul> <p>Note: This protocol is currently written to support native push notifications using fcm. For the implementation for iOS (via apns), please refer to 0699: Push Notifications apns</p>"},{"location":"features/0734-push-notifications-fcm/#summary","title":"Summary","text":"<p>A protocol to coordinate a push notification configuration between two agents.</p>"},{"location":"features/0734-push-notifications-fcm/#motivation","title":"Motivation","text":"<p>This protocol would give an agent enough information to send push notifications about specific events to a device that supports fcm. This would be of great benefit for mobile wallets, as a holder can be notified when new messages are pending at the mediator. Mobile applications, such as wallets, are often killed and can not receive messages from the mediator anymore. Push notifications would resolve this problem.</p>"},{"location":"features/0734-push-notifications-fcm/#tutorial","title":"Tutorial","text":""},{"location":"features/0734-push-notifications-fcm/#name-and-version","title":"Name and Version","text":"<p>URI: <code>https://didcomm.org/push-notifications-fcm/1.0</code></p> <p>Protocol Identifier: <code>push-notifications-fcm</code></p> <p>Version: <code>1.0</code></p>"},{"location":"features/0734-push-notifications-fcm/#key-concepts","title":"Key Concepts","text":"<p>When an agent would like to receive push notifications at record event changes, e.g. incoming credential offer, incoming connection request, etc., the agent could initiate the protocol by sending a message to the other agent.</p> <p>This protocol only defines how an agent would get the token and platform that is necessary for push notifications.</p> <p>Each platform has its own protocol so that we can easily use 0031: Discover Features 1.0 and 0557: Discover Features 2.X to see which specific services are supported by the other agent.</p>"},{"location":"features/0734-push-notifications-fcm/#roles","title":"Roles","text":"<p>notification-sender</p> <p>notification-receiver</p> <p>The notification-sender is an agent who will send the notification-receiver notifications. The notification-receiver can get and set their push notification configuration at the notification-sender.</p>"},{"location":"features/0734-push-notifications-fcm/#services","title":"Services","text":"<p>This RFC focuses on configuring the data necessary for pushing notifications via Firebase Cloud Messaging.</p> <p>In order to implement this protocol, the set-device-info and get-device-info messages MUST be implemented by the notification-sender and device-info message MUST be implemented by the notification-receiver.</p>"},{"location":"features/0734-push-notifications-fcm/#supported-services","title":"Supported Services","text":"<p>The protocol currently supports the following push notification services</p> <ul> <li>Firebase Cloud Messaging</li> </ul>"},{"location":"features/0734-push-notifications-fcm/#messages","title":"Messages","text":"<p>When a notification-receiver wants to receive push notifications from the notification-sender, the notification-receiver has to send the following message:</p>"},{"location":"features/0734-push-notifications-fcm/#set-device-info","title":"Set Device Info","text":"<p>Message to set the device info using the fcm device token and device platform for push notifications.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-fcm/1.0/set-device-info\",\n  \"@id\": \"&lt;UUID&gt;\",\n  \"device_token\": \"&lt;DEVICE_TOKEN&gt;\",\n  \"device_platform\": \"&lt;DEVICE_PLATFORM&gt;\"\n}\n</code></pre> <p>Description of the fields:</p> <ul> <li><code>device_token</code> -- The token that is required by the notification provider (string, null)</li> <li><code>device_platform</code> -- The platform used by the sender, e.g. Android / iOS / Linux / etc. (string, null)</li> </ul> <p>It is important to note that the set device info message can be used to set, update and remove the device info. To set, and update, these values the normal messages as stated above can be used. To remove yourself from receiving push notifications, you can send the same message where all values MUST be <code>null</code>. If either value is <code>null</code>, a <code>problem-report</code> MAY be sent back with <code>missing-value</code>.</p>"},{"location":"features/0734-push-notifications-fcm/#get-device-info","title":"Get Device Info","text":"<p>When a notification-receiver wants to get their push-notification configuration, they can send the following message:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-fcm/1.0/get-device-info\",\n  \"@id\": \"&lt;UUID&gt;\"\n}\n</code></pre>"},{"location":"features/0734-push-notifications-fcm/#device-info","title":"Device Info","text":"<p>Response to the get device info:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-fcm/1.0/device-info\",\n  \"device_token\": \"&lt;DEVICE_TOKEN&gt;\",\n  \"device_platform\": \"&lt;DEVICE_PLATFORM&gt;\",\n  \"~thread\": {\n    \"thid\": \"&lt;GET_DEVICE_INFO_UUID&gt;\"\n  }\n}\n</code></pre> <p>This message can be used by the notification-receiver to receive their device info, e.g. <code>device_token</code> and <code>device_platform</code>. If the notification-sender does not have this field for that connection, a <code>problem-report</code> MAY be used as a response with <code>not-registered-for-push-notifications</code>.</p>"},{"location":"features/0734-push-notifications-fcm/#adopted-messages","title":"Adopted messages","text":"<p>In addition, the <code>ack</code> message is adopted into the protocol for confirmation by the notification-sender. The ack message SHOULD be sent in response to any of the set-device-info messages.</p>"},{"location":"features/0734-push-notifications-fcm/#sending-push-notifications","title":"Sending Push Notifications","text":"<p>When an agent wants to send a push notification to another agent, the payload of the push notifications MUST include the <code>@type</code> property, and COULD include the <code>message_tags</code> property, to indicate the message is sent by the notification-sender. Guidelines on notification messages are not defined.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-fcm\",\n  \"message_tags\": [\"&lt;MESSAGE_TAG&gt;\"],\n  \"message_ids\": [\"&lt;MESSAGE_ID&gt;\"],\n  ...\n}\n</code></pre> <p>Description of the fields:</p> <ul> <li><code>@type</code> -- Indicator of what kind of notification it is. (This could help the notification-receiver with parsing if a notification comes from another agent, for example)</li> <li><code>message_tag</code> -- Optional list field to connect the push notification to a DIDcomm message, this can be used for batching multiple messages to a single notification. As defined in 0334: jwe-envelope or 0019: encryption-envelope.</li> <li><code>message_ids</code> -- Optional list field to pickup the message from the mediator that the notification was linked to, this can be used for batching multiple messages to a single notification. As defined in 0685: Pickup Protocol 2.0.</li> </ul>"},{"location":"features/0734-push-notifications-fcm/#drawbacks","title":"Drawbacks","text":"<p>Each service requires a considerable amount of domain knowledge. The RFC can be extended with new services over time.</p> <p>The <code>@type</code> property in the push notification payload currently doesn't indicate which agent the push notification came from. In e.g. the instance of using multiple mediators, this means the notification-receiver does not know which mediator to retrieve the message from.</p>"},{"location":"features/0734-push-notifications-fcm/#prior-art","title":"Prior art","text":"<ul> <li>This RFC is based on the implementation of the <code>AddDeviceInfoMessage</code> in Aries Framework .NET</li> </ul>"},{"location":"features/0734-push-notifications-fcm/#unresolved-questions","title":"Unresolved questions","text":"<p>None</p>"},{"location":"features/0734-push-notifications-fcm/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0748-n-wise-did-exchange/","title":"Aries RFC 0748: N-wise DID Exchange Protocol 1.0","text":"<ul> <li>Authors: Mikhail Lytaev, Pavel Minenkov</li> <li>Status: DEMONSTRATED</li> <li>Since: 2022-08-03</li> <li>Status Note: Under research</li> <li>Supersedes:</li> <li>Start Date: 2022-06-03</li> <li>Tags: feature, protocol</li> <li>URI: https://didcomm.org/n-wise/1.0</li> </ul>"},{"location":"features/0748-n-wise-did-exchange/#summary","title":"Summary","text":"<p>This RFC defines a protocol for creating and managing relationships within a group of SSI subjects. In a certain sense, this RFC is a generalization of the pairwise concept and protocols 0160-connection-protocol and 0023-did-exchange for an arbitrary number of parties (n-wise).</p>"},{"location":"features/0748-n-wise-did-exchange/#motivation","title":"Motivation","text":"<p>SSI subjects and agents representing them must have a way to establish relationships with each other in a trustful manner. In the simplest case, when only two participants are involved, this goal is achieved using 0023-did-exchange protocol by creating and securely sharing their DID Documents directly between agents. However, it is often desirable to organize an interaction involving more than two paries. The number of parties of such an interaction may change over time, and most of the agents may be mobile ones. The simplest and most frequently used example of such interaction is a group chat in instant messenger. The trusted nature of SSI technology makes it possible to use group relationships for holding legally significant unions, such as board of directors, territorial community or dissertation councils.</p>"},{"location":"features/0748-n-wise-did-exchange/#tutorial","title":"Tutorial","text":""},{"location":"features/0748-n-wise-did-exchange/#name-and-version","title":"Name and Version","text":"<p>n-wise, version 1.0</p> <p>URI: https://didcomm.org/n-wise/1.0</p>"},{"location":"features/0748-n-wise-did-exchange/#registry-of-n-wise-states","title":"Registry of n-wise states","text":"<p>The current state of n-wise is an up-to-date list of the parties' DID Documents. In pairwise relation the state is stored by the participants and updated by a direct notification of the other party. When there are more than two participants, the problem of synchronizing the state of this n-wise (i.e. consensus) arising. It should be borne in mind that the state may change occasionally: users may be added or deleted, DID Documents may be modified (when keys are rotated or endpoints are changed).</p> <p>In principle, any trusted repository can act as a registry of n-wise states. The following options for storing the n-wise state can be distinguished:</p> <ul> <li> <p>This approach is the closest to 0023-did-exchange protocol. However since there are more than two participants, an additional consensus procedure is required to correctly account for changes in the n-wise state. This option is suitable if the participants are represented by cloud agents which are (almost) always online. In this case, a consensus can be established between them using the well-known algorithms (RAFT, Paxos, BFT). However, if most of the agents are mobile and are online only occasionally, the mentioned consensus algorithms are not applicable. So it is preferable to use external solutions for storing and updating the n-wise states.</p> </li> <li> </li> <li> <p>In this case, the task of recording and storing the state is taken over by a third-party distributed network. The network can verify incoming transactions by executing a smart contract, or accept all incoming transactions, so transaction validation takes place only on the participating agents.</p> </li> <li> </li> </ul> <p>The concept of pluggable consensus implies choosing the most appropriate way to maintain a registry of states, depending on the needs.</p> <p>N-wise state update is performed by committing the corresponding transaction to the registry of n-wise states. To get the current n-wise state, the agent receives a list of transactions from the registry of states, verifies them and applies sequentially, starting with the <code>genesisTx</code>. Incorrect transactions (without a proper signature or missing the required fields) are ignored. Thus, n-wise can be considered as a replicated state machine, which is executed on each participant.</p> <p>The specifics of recording and receiving transactions depend on the particular method of maintaining the n-wise registry and on a particular ledger. This RFC DOES NOT DEFINE specific n-wise registry implementations.</p>"},{"location":"features/0748-n-wise-did-exchange/#directly-on-the-agents-side-edge-chain","title":"Directly on the agent's side (Edge chain)","text":""},{"location":"features/0748-n-wise-did-exchange/#public-or-private-distributed-ledger","title":"Public or private distributed ledger","text":""},{"location":"features/0748-n-wise-did-exchange/#centralized-storage","title":"Centralized storage","text":"<ul> <li>This case is applicable when security requirements allow participants to trust a centralized solution.</li> </ul>"},{"location":"features/0748-n-wise-did-exchange/#roles","title":"Roles","text":"<ul> <li> <p>The party of n-wise. Has the right to:</p> <ul> <li>Modify its DID Document;</li> <li>Remove himself from n-wise;</li> <li>Invite new parties.</li> </ul> </li> <li> </li> <li> <p>In addition to user's rights, has the right to:</p> <ul> <li>Remove other users from n-wise;</li> <li>Modify n-wise meta information;</li> <li>Transfer its role to another user.</li> </ul> </li> <li> <p>There can be only one owner in n-wise at a time.</p> </li> <li> </li> <li> <p>Creator of the n-wise and the author of <code>genesisTx</code>. </p> </li> <li> <p>The creator automatically becomes the owner of n-wise after creation.</p> </li> <li> </li> <li> <p>The n-wise participant who initiates the invitation of a new one.</p> </li> <li> </li> <li> <p>The participant accepting the invitation and connecting to n-wise. If successful, the participant becomes a user of n-wise.</p> </li> </ul>"},{"location":"features/0748-n-wise-did-exchange/#user","title":"User","text":""},{"location":"features/0748-n-wise-did-exchange/#owner","title":"Owner","text":""},{"location":"features/0748-n-wise-did-exchange/#creator","title":"Creator","text":""},{"location":"features/0748-n-wise-did-exchange/#inviter","title":"Inviter","text":""},{"location":"features/0748-n-wise-did-exchange/#invitee","title":"Invitee","text":""},{"location":"features/0748-n-wise-did-exchange/#actions","title":"Actions","text":""},{"location":"features/0748-n-wise-did-exchange/#n-wise-creation","title":"N-wise creation","text":"<p>The creation begins with the initialization of the n-wise registry. This RFC DOES NOT SPECIFY the procedure for n-wise registry creation. After creating the registry, the creator commits the <code>genesisTx</code> transaction. The creator automatically obtains the role of owner. The creator MUST generate a unique DID and DID Document for n-wise.</p>"},{"location":"features/0748-n-wise-did-exchange/#invitation-of-a-new-party","title":"Invitation of a new party","text":"<p>Any n-wise party can create an invitation to join n-wise. First, inviter generates a pair of public and private invitation keys according to Ed25519. The public key of the invitation is pushed to the registry using the <code>invitationTx</code> transaction. Then the <code>Invitation</code> message with the invitation private key is sent out-of-band to the invitee. The invitation key pair is unique for each invitee and can be used only once.</p>"},{"location":"features/0748-n-wise-did-exchange/#accepting-the-invitation","title":"Accepting the invitation","text":"<p>Once <code>Invitation</code> received, the invite generates a unique DID and DID Document for the n-wise and commits <code>AddParticipantTx</code> transaction to the registry. It is NOT ALLOWED to reuse DID from other relationships.</p> <p>The process of adding a new participant is shown in the figure below</p> <p></p>"},{"location":"features/0748-n-wise-did-exchange/#updating-did-document","title":"Updating DID Document","text":"<p>Updating the user's DID Document is required for the key rotation or endpoint updating. To update the associated DID Document, user commits the <code>updateParticipantTx</code> transaction to the registry.</p>"},{"location":"features/0748-n-wise-did-exchange/#removing-a-party-form-n-wise","title":"Removing a party form n-wise","text":"<p>Removing is performed using the <code>removeParticipantTx</code> transaction. The user can delete itself (the corresponding transaction is signed by the user's public key). The owner can delete any user (the corresponding transaction is signed by the owner's public key).</p>"},{"location":"features/0748-n-wise-did-exchange/#updating-n-wise-meta-information","title":"Updating n-wise meta information","text":"<p>Meta information can be updated by the owner using the <code>updateMetadataTx</code> transaction.</p>"},{"location":"features/0748-n-wise-did-exchange/#transferring-the-owner-role-to-other-user","title":"Transferring the owner role to other user","text":"<p>The owner can transfer control of the n-wise to other user. The old owner loses the corresponding privileges and becomes a regular user. The operation is performed using the <code>NewOwnerTx</code> transaction.</p>"},{"location":"features/0748-n-wise-did-exchange/#notification-on-n-wise-state-update","title":"Notification on n-wise state update","text":"<p>Just after committing the transaction to the n-wise registry, the participant MUST send the <code>ledger-update-notify</code> message to all other parties. The participant who received <code>ledger-update-notify</code> SHOULD fetch updates from the n-wise registry.</p>"},{"location":"features/0748-n-wise-did-exchange/#didcomm-messaging-within-n-wise","title":"DIDComm messaging within n-wise","text":"<p>It is allowed to exchange DIDComm messages of any type within n-wise. The belonging of the sender to a certain n-wise is determined by the sender's verkey.</p> <p>This RFC DOES NOT DEFINE a procedure of exchanging messages within n-wise. In the simplest case, this can be implemented as sending a message to each participant in turn. In case of a large number of parties, it is advisable to consider using a centralized coordinator who would be responsible for the ordering and guaranteed sending of messages from the sender to the rest of parties.</p>"},{"location":"features/0748-n-wise-did-exchange/#reference","title":"Reference","text":""},{"location":"features/0748-n-wise-did-exchange/#n-wise-registry-transactions","title":"N-wise registry transactions","text":"<p>N-wise state is modified using transactions in the following form</p> <pre><code>{\n  \"type\": \"transaction type\",\n  ...\n  \"proof\" {\n    \"type\": \"JcsEd25519Signature2020\",\n    \"verificationMethod\": \"did:alice#key1\",\n    \"signatureValue\": \"...\"\n\n  }\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes","title":"Attributes","text":"<ul> <li><code>type</code> - required attribute, type of transaction;</li> <li><code>proof</code> - required attribute, transaction signature in JSON-LD Proof format;</li> <li><code>verificationMethod</code> - required attribute, depends on the specific type of transaction and is defined below.</li> </ul>"},{"location":"features/0748-n-wise-did-exchange/#genesistx","title":"GenesisTx","text":"<p>'GenesisTx' is a mandatory initial transaction that defines the basic properties of the n-wise.</p> <pre><code>{\n  \"type\": \"genesisTx\",\n  \"label\": \"Council\",\n  \"creatorNickname\": \"Alice\",\n  \"creatorDid\": \"did:alice\",\n  \"creatorDidDoc\": {\n   ..\n  },\n  \"ledgerType\": \"iota@1.0\",\n  \"metaInfo\" {\n    ...\n  }\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes_1","title":"Attributes","text":"<ul> <li><code>label</code> - required attribute, n-wise name;</li> <li><code>creatorNickname</code> - required attribute, creator nickname;</li> <li><code>creatorDid</code> - required attribute, DID of the creator;</li> <li><code>creatorDidDoc</code> - required attribute, DID Document of the creator;</li> <li><code>ledgerType</code> - required attribute, n-wise registry type;</li> <li><code>metaInfo</code> - optional attribute, additional n-wise meta information; the format is determined by a particular n-wise state implementation;</li> </ul> <p>The <code>genesisTx</code> transaction MUST be signed by the creator's public key defined in his DID Document.</p>"},{"location":"features/0748-n-wise-did-exchange/#invitationtx","title":"InvitationTx","text":"<p>This transaction adds the invitation public keys to the n-wise registry.</p> <pre><code>{\n  \"type\": \"invitationTx\",\n  \"publicKey\": [\n    {\n      \"id\": \"invitationVerkeyForBob\",\n      \"type\": \"Ed25519VerificationKey2018\",\n      \"publicKeyBase58\": \"arekhj893yh3489qh\"\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes_2","title":"Attributes","text":"<ul> <li><code>publicKey</code> - required attribute, array of invitation public keys;</li> <li><code>id</code> - required attribute, invitation public key ID;</li> <li><code>type</code> - required attribute, key type;</li> <li><code>publicKeyBase58</code> - required attribute, base58 encoded public key.</li> </ul> <p>invitationTx` MUST be signed by the user's public key defined in it's DID Document.</p>"},{"location":"features/0748-n-wise-did-exchange/#invitation-message","title":"Invitation message","text":"<p>The message is intended to invite a new participant. It is sent via an arbitrary communication channel (pairwise, QR code, e-mail, etc.).</p> <pre><code>{\n  \"@id\": \"5678876542345\",\n  \"@type\": \"https://didcomm.org/n-wise/1.0/invitation\",\n  \"label\": \"Invitaion to join n-wise\",\n  \"invitationKeyId\": \"invitationVerkeyForBob\",\n  \"invitationPrivateKeyBase58\": \"qAue25rghuFRhrue....\",\n  \"ledgerType\": \"iota@1.0\",\n  \"ledger~attach\": [\n    {\n      \"@id\": \"attachment id\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"&lt;bytes for base64&gt;\"\n      }\n    }  \n  ]\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes_3","title":"Attributes","text":"<ul> <li><code>label</code> - optional attribute, human readable invitation text;</li> <li><code>invitationKeyId</code> - required attribute, invitation key ID;</li> <li><code>invitationPrivateKeyBase58</code>- required attribute, base58 encoded invitation private key;</li> <li><code>ledgerType</code> - required attribute, n-wise registry type;</li> <li><code>ledger~attach</code> - optional attribute, attachment with meta information, required for connection to n-wise registry; defined by a particular registry implementation.</li> </ul>"},{"location":"features/0748-n-wise-did-exchange/#addparticipanttx","title":"AddParticipantTx","text":"<p>The transaction is designed to add a new user to n-wise.</p> <pre><code>{\n  \"id\": \"addParticipantTx\",\n  \"nickname\": \"Bob\",\n  \"did\": \"did:bob\",\n  \"didDoc\": {\n    ...\n  }\n\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes_4","title":"Attributes","text":"<ul> <li><code>nickname</code> - required attribute, user nickname;</li> <li><code>did</code> - required attribute, user's DID;</li> <li><code>didDoc</code> - required attribute, user's DID Document.</li> </ul> <p><code>AddParticipantTx</code> transaction MUST be signed by the invitation private key  (<code>invitationPrivateKeyBase58</code>), received in <code>Invitation</code> message. As committing the <code>AddParticipantTx</code> transaction, the corresponding invitation key pair is considered deactivated (other invitations cannot be signed by it).</p> <p>The transaction executor MUST verify if the invitation key was indeed previously added. Execution of the transaction entails the addition of a new party to n-wise.</p>"},{"location":"features/0748-n-wise-did-exchange/#updateparticipanttx","title":"UpdateParticipantTx","text":"<p>The transaction is intended to update information about the participant.</p> <pre><code>{\n  \"type\": \"updateParticipantTx\",\n  \"did\": \"did:bob\",\n  \"nickname\": \"Updated Bob\",\n  \"didDoc\" {\n    ...\n  }\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes_5","title":"Attributes","text":"<ul> <li><code>did</code> - requred attribute, DID of the updating user;</li> <li><code>nickname</code> - optional attribute, new nickname;</li> <li><code>didDoc</code> - optional attribute, new DID document.</li> </ul> <p>Transaction MUST be signed by the public key of the user being updated. The specified public key MUST be defined in the previous version of the DID Document.</p> <p>Execution of the transaction entails updating information about the participant.</p>"},{"location":"features/0748-n-wise-did-exchange/#removeparticipanttx","title":"RemoveParticipantTx","text":"<p>The transaction is designed to remove a party from n-wise.</p> <pre><code>{\n  \"type\": \"removeParticipantTx\",\n  \"did\": \"did:bob\"\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes_6","title":"Attributes","text":"<ul> <li><code>did</code> - requred attribute, DID of the removing user;</li> </ul> <p>The execution of the transaction entails the removal of the user and his DID Document from the list of n-wise parties.</p> <p>The transaction MUST be signed by the public key of the user who is going to be removed from n-wise, or with the public key of the owner.</p>"},{"location":"features/0748-n-wise-did-exchange/#updatemetadatatx","title":"UpdateMetadataTx","text":"<p>The transaction is intended to update the meta-information about n-wise.</p> <pre><code>{\n    \"type\": \"updateMetadataTx\",\n    \"label\": \"Updated Council\"\n    \"metaInfo\": {\n      ...\n    }\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes_7","title":"Attributes","text":"<ul> <li><code>label</code> - optional attribute, new n-wise name;</li> <li><code>metaInfo</code> - optional attribute, new n-wise meta-information.</li> </ul> <p>The transaction MUST be signed by the owner's public key.</p>"},{"location":"features/0748-n-wise-did-exchange/#newownertx","title":"NewOwnerTx","text":"<p>The transaction is intended to transfer the owner role to another user. The old owner simultaneously becomes a regular user.</p> <pre><code>{\n    \"type\": \"newOwnerTx\",\n    \"did\": \"did:bob\"\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes_8","title":"Attributes","text":"<ul> <li><code>did</code> required attribute, new owner's DID.</li> </ul> <p>The transaction MUST be signed by the owner's public key.</p>"},{"location":"features/0748-n-wise-did-exchange/#ledger-update-notify","title":"ledger-update-notify","text":"<p>The message is intended to notify participants about the  modifications of the n-wise state.</p> <pre><code>{\n  \"@id\": \"4287428424\",\n  \"@type\": \"https://didcomm.org/n-wise/1.0/ledger-update-notify\"\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#drawbacks","title":"Drawbacks","text":"<ul> <li>External DLT is required;</li> <li>The user hierarchy is quite primitive.</li> </ul>"},{"location":"features/0748-n-wise-did-exchange/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Public DID methods use blockchain networks or other public storages for its DID Documents. Peer DID rejects the use of external storage, which is absolutely justified for a pairwise relationship, since a DID Document can be stored by the other participant. If there are more than two participants, consensus on the list of DID Documents is required. N-wise is  somewhat of a middle ground between a Peer DID (DID document is stored only by a partner) and a public DID (DID document is available to everyone in the internet). So, the concept of n-wise state registry was introduced in this RFC, and its specific implementations (consensus between participants or a third-party trusted registry) remain at the discretion of the  n-wise creator. The concept of microledger is also considerable to use for the n-wise state registry.</p> <p>One more promising high-level concept for building n-wise protocols is Gossyp.</p>"},{"location":"features/0748-n-wise-did-exchange/#prior-art","title":"Prior art","text":"<p>The term of n-wise was proposed in Peer DID specification, and previously discussed in document. However, no strict formalization of this process was proposed, as well as the need for consensus between the participants was not noted.</p>"},{"location":"features/0748-n-wise-did-exchange/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Who should be responsible for the order of transactions?</li> <li>How to define specific n-wise state registry implementations (separate RFCs?)</li> <li>How to make a flexible user hierarchy?</li> </ul>"},{"location":"features/0748-n-wise-did-exchange/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Sirius SDK Java IOTA Ledger based implementation (IOTA n-wise registry spec). See a detailed example in Jupyter notebook."},{"location":"features/0755-oca-for-aries/","title":"0755: Overlays Capture Architecture (OCA) For Aries","text":"<ul> <li>Authors: Stephen Curran</li> <li>Status: DEMONSTRATED</li> <li>Since: 2024-03-02</li> <li>Status Note: Implemented in the Bifold Wallet</li> <li>Start Date: 2022-09-25</li> <li>Version: 1.0</li> <li>Tags: feature</li> </ul>"},{"location":"features/0755-oca-for-aries/#summary","title":"Summary","text":"<p>Overlays Capture Architecture (OCA) is, per the OCA specification, a \"standardized global solution for data capture and exchange.\" Given a data structure (such as a verifiable credential), OCA allows for the creation of purpose-specific overlays of information about that data structure. Each overlay provides some knowledge (human and machine-readable) about the overall data structure or the individual attributes within it. The information in the overlays makes it possible to create useful software for capturing data, displaying it and exchanging it. While the OCA website and OCA specification can be reviewed for a detailed background of OCA and its various purposes, in this RFC we'll focus on its purpose in Aries, which is quite constrained and pragmatic--a mechanism for an issuer to provide information about a verifiable credential to allow holder and verifier software to display the credential in a human-friendly way, including using the viewers preferred language, and the issuer's preferred branding. The image below shows an Aries mobile Wallet displaying the same credential without and with OCA overlays applied in two languages. All of the differences in the latter two screenshots from the first come from issuer-supplied OCA data.</p> <p></p> <p>This RFC formalizes how Aries verifiable credential issuers can make a JSON OCA Bundle (a set of related OCA overlays about a base data structure) available to holders and verifiers that includes the following information for each type of credential they issue.</p> <ul> <li>Metadata about the credential, such as the Classification system upon which   the credential is based.</li> <li>Metadata about the credential in multiple languages, such as its name,   description, the name and description of the issuer and so on.</li> <li>Type, format, encoding, standard and units information about the credential's raw   attribute data.</li> <li>Metadata about the attributes within the credential in multiple languages,   such as a label and help text.</li> <li>A set of branding elements (logo, background image, color and so on) that   holder and verifier software are expected to use in displaying the credential.</li> </ul> <p>The standard flow of data between participants is as follows:</p> <ul> <li>An issuer creates an OCA Bundle for each type of verifiable credential it issues.</li> <li>During credential issuance using [RFC 0453 Issue Credential V2 v2.2 (or later) protocol] the issuer MAY include in the protocol's <code>credential-offer</code> or <code>credential</code> messages the OCA Bundle for the credential type as an <code>oca-bundle</code> issue credential supplement.</li> <li>When provided, the holder software has full access to the OCA information published by that issuer and can use the OCA data to render the credential for its user(s) in the language of their choice, with credential branding from the issuer, based on the RFC0756 OCA for Aries Style Guide.</li> <li>The holder MAY share the OCA Bundle with a verifier by using [RFC 0453 Issue Credential V2 v2.2 (or later) protocol] to add the <code>oca-bundle</code> credential supplement received from the issuer.</li> <li>On receipt, the verifier software has full access to the OCA information published by that issuer and can use the OCA data to render the credential for its user(s) in the language of their choice, with credential branding from the issuer, based on the RFC0756 OCA for Aries Style Guide.</li> </ul> <p>While the issuer providing the OCA Bundle for a credential type using the credential supplement mechanism is the typical flow (as detailed in this RFC), other flows, outside of the scope of this RFC are possible. See the rationale and alternatives section of this RFC for some examples.</p>"},{"location":"features/0755-oca-for-aries/#motivation","title":"Motivation","text":"<p>The core data models for verifiable credentials are more concerned about the correct cryptographic processing of the credentials than about general processing of the attribute data, and the user experience of those using credentials. An AnonCreds verifiable credential contains the bare minimum of metadata about a credential--basically, just the developer-style names for the type of credential and the attributes within it. JSON-LD-based verifiable credentials has the capacity to add more information about the attributes in a credential, but the data is not easily accessed and is provided to enable machine processing rather than improving user experience.</p> <p>OCA allows credential issuers to declare information about the verifiable credential types it issues to improve the handling of those credentials by holder and verifier Aries agents, and to improve the on-screen display of the credentials, through the application of issuer-specified branding elements.</p>"},{"location":"features/0755-oca-for-aries/#tutorial","title":"Tutorial","text":"<p>The tutorial section of this RFC defines the coordination necessary for an the creation, publishing, retrieval and use of an OCA Bundle for a given type of verifiable credential.</p> <pre><code>In this overview, we assume the the use of OCA specifically for verifiable\ncredentials, and further, specifically for AnonCreds verifiable credentials. OCA\ncan also be used be applied to any data structure, not just verifiable\ncredentials, and for other verifiable credential models, such as those based on\nthe JSON-LD- or JWT-style verifiable credentials. As the Aries\ncommunity applies OCA to other styles of verifiable credential, we\nwill extend this RFC.\n</code></pre>"},{"location":"features/0755-oca-for-aries/#issuer-activities","title":"Issuer Activities","text":"<p>The use of OCA as defined in this RFC begins with an issuer preparing an OCA Bundle for each type of credential they issue. An OCA Bundle is a JSON data structure consisting of the Capture Base, and some additional overlays of different types (listed in the next section).</p> <p>While an OCA Bundle can be manually maintained in an OCA Bundle JSON file, a common method of maintaining OCA source data is to use a spreadsheet, and generating the OCA Bundle from the Excel source. See the section of this RFC called OCA Tooling for a link to an OCA Source spreadsheet, and information on tools available for managing the OCA Source data and generating a corresponding OCA Bundle.</p> <p>The creation of the OCA Bundle and the configuration of the issuer's Aries Framework to deliver the OCA Bundle during credential issuance should be all that a specific issuer needs to do in using OCA for Aries. An Aries Framework that supports OCA for Aries should handle the rest of the technical requirements.</p>"},{"location":"features/0755-oca-for-aries/#oca-specification-overlays","title":"OCA Specification Overlays","text":"<p>All OCA data is based on a Capture Base, which defines the data structure described in the overlays. For AnonCreds, the Capture Base attributes MUST be the list of attributes in the AnonCreds schema for the given credential type. The Capture Base also MUST contain:</p> <ul> <li>the type of each attribute, based on an enumerated list of types defined in   the OCA   specification</li> <li>a list of the base attributes that will hold Personally Identifiable Information (PII) in an issued credential. An issuer SHOULD use the Kantara Initiative's Blinding Identity Taxonomy to identify the attributes to flag as being PII.</li> </ul> <p>With the Capture Base defined, the following additional overlay types MAY be created by the Issuer and SHOULD be expected by holders and verifiers. Overlay types flagged \"multilingual\" may have multiple instances of the overlay, one for each issuer-supported language (e.g en for English, fr French, SP Spanish, etc.) or country-language (e.g., en-CA for Canadian English, fr-CA for Canadian French), as defined in the OCA Specification about languages.</p> <p>An OCA Bundle that contains overlay types that a holder or verifier does not expect MUST be processed, with the unexpected overlays ignored.</p> <ul> <li>The Character Encoding Overlay contains the encoding for each attribute in the capture base.</li> <li>The Format Overlay provides the input structure for each data attribute. The format may be useful to the holder (or verifier) in displaying the data in a style expected by the user, such as knowing that a given field of <code>type</code> binary is an image in <code>image/jpeg</code> format.</li> <li>The multilingual Label Overlay provides a label to be used for each attribute for a given language. The label overlay also includes labels for attributes with enumerated values (called categories in the OCA specification). For example, a data attribute containing the codes \"EN\", \"FR\", \"SP\" could have a category entries that indicate the codes correspond to \"English\", \"French\" and \"Spanish\", respectively.</li> <li>The multilingual Information Overlay provides a description or help text about each attribute for a given language. There will be one overlay per issuer-supported language.</li> <li>The multilingual Meta Overlay contains information about the credential itself. For Aries, the meta overlay SHOULD include the following additional name/value pairs, specific to the OCA for Aries use case:</li> <li><code>name</code> - the name of the credential.</li> <li><code>description</code> - a description of the credential.</li> <li><code>issuer</code> - the name of the issuer of the credential.</li> <li><code>issuer_description</code> - a description for the issuer of the credential.</li> <li><code>issuer_url</code> - a URL for the issuer of the credential.</li> <li><code>credential_help_text</code> - help text about the credential</li> <li><code>credential_support_url</code> - a URL for a service providing support in the use of the credential.</li> <li>The Unit Overlay   allows the issuer to declare the units of measurement for the attributes in   the overlay.</li> <li>The Standard Overlay indicates that some or all of the attributes use   specific data standards populating the attribute in a credential. This might   be used, for example, for defining the standard applied in populating a data   attribute with a date or date/time.</li> <li>The Entry Code Overlay contains a list of enumerated values for each   data attribute that uses enumerated values. An example might be a list of   regional jurisdiction (such as provinces or states) short forms that will be   placed in an attribute (e.g., NY, ND, AL, CA, etc.). The attributes in the   credential are expected to be populated with one of the enumerated values.</li> <li>The Entry Overlay contains a language-specific list of the meanings for   each enumerated value for each data attribute that uses enumerated values. For   our example of short forms of jurisdictions, the \"meanings\" would be the   expanded list per language supported (English, French, Spanish, etc.) of   jurisdictions (e.g., New York, North Dakota, Alabama, California, etc.).</li> </ul>"},{"location":"features/0755-oca-for-aries/#aries-specific-dates-in-the-oca-format-overlay","title":"Aries-Specific Dates in the OCA Format Overlay","text":"<p>In AnonCreds, zero-knowledge proof (ZKP) predicates (used, for example, to prove older than a given age based on date of birth without sharing the actual date of birth) must be based on integers. In the AnonCreds/Aries community, common ways for representing dates and date/times as integers so that they can be used in ZKP predicates are the <code>dateint</code> and <code>Unix Time</code> formats, respectively.</p> <ul> <li> <p>\"<code>dateint</code>\" is a credential attribute that uses the Aries <code>dateint</code> specification as described in Aries RFC 0592. Briefly, <code>dateint</code> is a date (YYYYMMDD) provided in a credential attribute as an integer (for example <code>September 29, 2022</code> is the integer <code>20220929</code> or <code>20,220,929</code>). <code>dateint</code> is also part of ISO standard 1989 for COBOL Programming Interfaces, described here in an IBM document.</p> </li> <li> <p>\"<code>Unix Time</code>\" is a credential attribute that is a date/time timestamp constructed according to the <code>Unix Time</code> Unix/POSIX data standard. Briefly, <code>Unix Time</code> is a date/time represented as the number of seconds since January 1, 1970 UTC.</p> </li> </ul> <p>In an OCA for Aries OCA Bundle, a <code>dateint</code> and <code>Unix Time</code> attributes MUST have the following values in the indicated overlays:</p> <ul> <li><code>dateint</code></li> <li>datatype <code>DateTime</code> in the Capture Base</li> <li>standard <code>urn:iso:std:iso:1989</code> in the Standard Overlay</li> <li>character encoding <code>utf-8</code> in the Character Encoding Overlay</li> <li>format <code>YYYYMMDD</code> in the Format Overlay</li> <li>Example: <code>20230114</code> for \"January 14, 2023\"</li> <li><code>Unix Time</code></li> <li>datatype <code>DateTime</code> in the Capture Base</li> <li>standard <code>urn:unix:unix-time</code> in the Standard Overlay</li> <li>character encoding <code>utf-8</code> in the Character Encoding Overlay</li> <li>format <code>epoch</code> in the Format Overlay</li> <li>Example: <code>1673715495</code> for \"Sat Jan 14 2023 16:58:15 GMT+0000\"</li> </ul> <p>A recipient of an OCA Bundle with the combination of overlay values referenced above for <code>dateint</code> and <code>Unix Time</code> SHOULD convert the integer attribute data into a date or date/time (respectively) and display the information as appropriate for the user. For example, a mobile app should display the data as a date or date/time based on the user's language/country setting and timezone, possibly combined with an app setting for showing the data in short, medium, long or full form.</p>"},{"location":"features/0755-oca-for-aries/#aries-specific-branding-overlay","title":"Aries Specific \"branding\" Overlay","text":"<p>In addition to the core OCA Overlays listed earlier, Aries issuers MAY include an additional Aries-specific extension overlay, the \"branding\" overlay, that gives the issuer a way to provide a set of data elements about the branding that they would like to see applied to a given type of credential. The <code>branding overlay</code> is similar to the multilanguage Meta overlay (e.g. ones for English, French and Spanish), with a specified set of name/value pairs. Holders (and verifiers) use the branding values from the issuer when rendering a credential of that type according the RFC0756 OCA for Aries Style Guide.</p> <p>An example of the use of the branding overlay is as follows, along with a definition of the name/value pair elements, and a sample image of how the elements are to be used. The sample is provide only to convey the concept of the branding overlay and how it is to be used. Issuers, holders and verifiers should refer to RFC0756 OCA for Aries Style Guide for details on how the elements are to be provided and used in displaying credentials.</p> <pre><code>{\n    \"type\": \"aries/overlays/branding/1.0\"\n    \"digest\": \"EBQbQEV6qSEGDzGLj1CqT4e6yzESjPimF-Swmyltw5jU\",\n    \"capture_base\": \"EKpcSmz06sJs0b4g24e0Jc7OerbJrGN2iMVEnwLYKBS8\",\n    \"logo\": \"https://raw.githubusercontent.com/hyperledger/aries-rfcs/oca4aries../../features/0755-oca-for-aries/best-bc-logo.png\",\n    \"background_image\": \"https://raw.githubusercontent.com/hyperledger/aries-rfcs/oca4aries../../features/best-bc-background-image.png\",\n    \"background_image_slice\": \"https://raw.githubusercontent.com/hyperledger/aries-rfcs/oca4aries../../features/best-bc-background-image-slice.png\",\n    \"primary_background_color\": \"#003366\",\n    \"secondary_background_color\": \"#003366\",\n    \"secondary_attribute\": \"given_names\",\n    \"primary_attribute\": \"family_name\",\n    \"secondary_attribute\": \"given_names\",\n    \"issued_date_attribute\": \"\",\n    \"expiry_date_attribute\": \"expiry_date_dateint\",\n}\n</code></pre> <p></p> <ul> <li>OCA Overlay-related items:</li> <li><code>type</code> - a the type of the overlay, using the <code>aries</code> namespace.</li> <li><code>digest</code> - the self-addressing identifier (SAID) for the overlay. Note that in this example, the SAID is not accurate for the data in the example.</li> <li><code>capture_base</code> - the self-addressing identifier (SAID) for the capture base to which this overlay applies.</li> <li><code>logo</code> - a URI for a logo to display on the credential in some contexts. The URI can be an HTTP URL, a hashlink or, to support inline images, a data URL (e.g.: <code>data:image/png;base64,...</code>) as defined by the Data URL Scheme. The logo MUST adhere to the logo properties defined in RFC0756 OCA for Aries Style Guide.</li> <li><code>background_image</code> - a URI for a background image to display with the credential in some contexts. The URI could be an HTTP URL, a hashlink or, to support inline images, a data URL (e.g.: <code>data:image/png;base64,...</code>) as defined by the Data URL Scheme. The image MUST adhere to the background image properties defined in RFC0756 OCA for Aries Style Guide.</li> <li><code>background_image_slice</code> - a URI for a background image slice to display with the credential in some contexts. The URI could be a HTTP URL, a hashlink or, to support inline images, a data URL (e.g.: <code>data:image/png;base64,...</code>) as defined by the Data URL Scheme. The image MUST adhere to the background image slice properties defined in RFC0756 OCA for Aries Style Guide.</li> <li><code>primary_background_color</code> - hex color code for the primary background color of the   credential to be used in some contexts.</li> <li><code>secondary_background_color</code> - hex color code for the secondary background color of the   credential to be used in some contexts.</li> <li><code>primary_attribute</code> - the name of a capture base attribute to be displayed on   the credential in some contexts.</li> <li><code>secondary_attribute</code> - the name of a capture base attribute to be displayed on   the credential in some contexts.</li> <li><code>issued_date_attribute</code> - the name of a capture base attribute that is the date   of issuance of the credential. If there is no such attribute, leave blank.</li> <li><code>expiry_date_attribute</code> - the name of a capture base attribute that is the   expiry date of the credential. If there is no such attribute, leave blank.</li> </ul> <p>It is deliberate that the credential branding defined in this RFC does not attempt to achieve pixel-perfect on screen rendering of the equivalent paper credential. There are two reasons for this:</p> <ul> <li>First, studies have shown that issuers do not want people to think that the digital credentials they have in their mobile wallet can be used as literal replacements for paper during person-to-person (non-digital) verifications by the holder showing their mobile device screen to the verifier. By showing verifiers their screen, the holder may be oversharing their personal data. As well, digital credentials are even easier to forge than paper credentials when they are to be verified by a human, and we want to discourage using digital credentials in that way.</li> <li>Second, having each issuer provide pixel-perfect layout guidance to Aries agents that supports a responsive user interface on a wide range of devices (laptops, tablets and thousands of mobile phones) is extraordinarily complex. Further, a wallet wanting to provide a consistent, helpful user experience will be severely hampered by displaying credentials with many (perhaps hundreds) of completely different credential layouts and styles.</li> </ul> <p>Instead, the guidance in this RFC and the RFC0756 OCA for Aries Style Guide gives the issuer a few ways to brand their credentials, and holder/verifier apps information on how to use those issuer-provided elements in a manner consistent for all issuers and all credentials.</p>"},{"location":"features/0755-oca-for-aries/#oca-issuer-tools","title":"OCA Issuer Tools","text":"<p>An Aries OCA Bundle can be managed as pure JSON as found in this sample OCA for Aries OCA Bundle. However, managing such multilingual content in JSON is not easy, particularly if the language translations come from team members not comfortable with working in JSON. An easier way to manage the data is to use an OCA source spreadsheet for most of the data, some in a source JSON file, and to use a converter to create the OCA Bundle JSON from the two sources. We recommend that an issuer maintain the spreadsheet file and source JSON in version control and use a pipeline action to generate the OCA Bundle when the source files are updated.</p> <p>The OCA Source Spreadsheet, an example of which is attached to this RFC, contains the following:</p> <ul> <li>An introductory tab about the OCA content in the spreadsheet.</li> <li>A tab with instructions on using the spreadsheet.</li> <li>A \"Main\" tab with the \"Capture Base\" data, along with data for other, non-multilingual overlays.</li> <li>A language or country-language code tab per country-language to be supported by the issuer   containing the source data for all multilingual overlays.</li> </ul> <p>The JSON Source file contains the Aries-specific Branding Overlay. Attached to this RFC is an example Branding Overlay JSON file that issuers can use to start.</p> <p>The following is how to create an OCA Source spreadsheet and from that, generate an OCA Bundle. Over time, we expect that this part of the RFC will be clarified as the tooling evolves.</p> <ul> <li>Creating/Maintaining the Excel File</li> <li>Make a copy of the latest OCA Template from the [Human Colossus Foundation].</li> <li>Fill in the \"Main\" tab with the attributes from the schema, completing the     relevant columns for each attribute. Current columns to complete:<ul> <li>CB-CL: Classification</li> <li>CB-AN: Attribute Name</li> <li>CB-AT: Attribute Type</li> <li>CB-FA: Flagged Attribute</li> <li>OL-CH: Character Encoding</li> <li>OL-FT: Format</li> <li>OL-ST: Standard</li> <li>OL-EC: Entry Codes</li> <li>OL-UT: Unit</li> </ul> </li> <li>As needed, populate the columns for \"dateint\" and \"Unix Time\" attributes as indicated in the Aries Specific Dates in the OCA Formats Overlay section of this document.</li> <li>Rename the sample language tab (<code>en</code>) to one of the language or language-country that as an issuer, you want to support.</li> <li>Fill in the data in columns other than C (which is automatically populated from the <code>Main</code> tab) for the first language as appropriate.</li> <li>Populate column A and B as follows:<ul> <li>In column A (<code>OL-MN: Meta [Attribute Name]</code>), add the values:</li> <li>\"name\"</li> <li>\"description\"</li> <li>\"issuer\"</li> <li>\"issuer_description\"</li> <li>\"issuer_url\"</li> <li>\"credential_help_text\"</li> <li>\"credential_support_url\"</li> <li>\"watermark\"<ul> <li>The \"watermark\" is used to mark non-production credentials, as described in the \"non-production watermark\" section of RFC0756 OCA for Aries Style Guide</li> </ul> </li> <li>Complete column B (<code>OL-MV: Meta [Attribute Value]</code>) as appropriate for each column A name (listed above).</li> </ul> </li> <li>Duplicate and rename the initial language tab for each language or language-country that as an issuer, you want to support.</li> <li>Update each additional language tab.</li> <li>Creating/Maintaining the Branding JSON file</li> <li>Make a copy of the attached example branding JSON file, and update the values for the credential you are issuing.</li> <li>Generating the OCA Bundle from the OCA for Aries Source files:</li> <li>Use the open source OCA Parser from the Human Colossus Foundation to convert the     spreadsheet to JSON. The current command to use is <code>parser parse oca --path &lt;OCA Excel File&gt; &gt; &lt;output Excel JSON OCA Bundle&gt;</code></li> <li>Use the open source jq utility to add the <code>branding.json</code> file to the JSON Excel output to produce the OCA Bundle with the following command, replacing the file names in the command with the ones for your use:<ul> <li><code>jq \".[].overlays += $(cat BRANDING-JSON-FILE)\" OCA-EXCEL-FILE &gt; OCA-BUNDLE-JSON-FILE</code></li> <li>From a command line in this folder, the following command can be run to generate the OCA Bundle JSON to standard output:</li> <li><code>jq \".[].overlays += $(cat branding.json)\" OCA4AriesExcel.json</code></li> </ul> </li> </ul> <p>NOTE: The <code>capture_base</code> and <code>digest</code> fields in the branding overlay of the resulting OCA Bundle JSON file will not be updated to be proper self-addressing identifiers (SAIDs) as required by the OCA Specification. We are looking into how to automate the updating of those data elements.</p> <p>Scripting the generation process should be relatively simple, and our expectation is that the community will evolve the [Parser from the Human Colossus Foundation] to simplify the process further.</p> <p>Over time, we expect to see other tooling become available--notably, a tool for issuers to see what credentials will look like when their OCA Bundle is applied.</p>"},{"location":"features/0755-oca-for-aries/#issuing-a-credential","title":"Issuing A Credential","text":"<p>This section of the specification remains under consideration. The use of the <code>credential supplement</code> as currently described here is somewhat problematic for a number of reasons.</p> <ul> <li>The issuer has no way to update the OCA Bundle for a given holder after   issueance. We see this as a likely use case to enable, for example, an   issuer supporting additional languages over time.</li> <li>The \"External Attachments\" risk, as described in this section of this   RFC.</li> <li>The complicated way for a verifier to get an OCA Bundle when needed after a   presentation.</li> </ul> <p>We are currently investigating if an OCA Bundle can be published to the same VDR as holds an AnonCreds Schema or Credential Definition. We think that would overcome each of those concerns and make it easier to both publish and retrieve OCA Bundles.</p> <p>The currently preferred mechanism for an issuer to provide an OCA Bundle to a holder is when issuing a credential using RFC0453 Issue Credential, version 2.2 or later, the issuer provides, in the credential offer message, an OCA Bundle as a credential supplement.</p> <ul> <li>The supplement type MUST be <code>oca-bundle</code>.</li> <li>The OCA Bundle MUST be in the JSON form of an OCA Bundle, not the ZIP format.</li> <li>The attachment MUST be signed by the issuer, and may be of type <code>base64url</code>, meaning the OCA Bundle is embedded in the message, or of type <code>link</code>.</li> </ul> <p>The reason OCA Bundle attachment must be signed by the issuer so that if the holder passes the OCA Bundle on to the verifier, the verifier can be certain that the issuer provided the OCA Bundle, and that it was not created by a malicious holder.</p> <p>Issuers should be aware that to ensure that the signature on a linked OCA Bundle (using the attachment type <code>link</code>) remains verifiable, the content resolved by the link must not change over time. For example, an Issuer might publish their OCA Bundles in a public GitHub repository, and send a link to the OCA Bundle during issuance. In that case the Issuer is advised to send a commit-based GitHub URL, rather than a branch-based reference. The Issuer may update the OCA Bundle sent to different holders over time, but once issued, each OCA Bundle MUST remain accessible.</p>"},{"location":"features/0755-oca-for-aries/#warning-external-attachments","title":"Warning: External Attachments","text":"<p>The use of an attachment of type <code>link</code> for the OCA Bundle itself, or the use of external references to the images in the branding Overlay could provide malicious issuers with a mechanism for tracking the use of a holder's verifiable credential. Specifically, the issuer could:</p> <ul> <li>Make any or all of the OCA bundle external references a unique identifier for   the holder.</li> <li>When the holder retrieves the OCA bundle, the issuer does not learn anything   useful as they already know they have issued a credential to that holder.</li> <li>If the holder passes the OCA bundle to verifiers and the verifiers resolve the   external references, the malicious issuer would learn that the holder has used   their verifiable credential in a presentation, and perhaps, with what verifier.</li> </ul> <p>A holder MAY choose not to attach an OCA Bundle to a verifier if it contains any external references. Non-malicious issuers are encouraged to not use external references in their OCA Bundles and as such, to minimize the inlined images in the branding overlay.</p>"},{"location":"features/0755-oca-for-aries/#holder-activities","title":"Holder Activities","text":"<p>Before processing a credential and an associated OCA Bundle, the holder SHOULD determine if the issuer is known in an ecosystem and has a sufficiently positive reputation. For example, the holder might determine if the issuer is in a suitable Trust Registry or request a presentation from the issuer about their identity.</p> <p>On receipt of a credential with an OCA Bundle supplement, the holder SHOULD retrieve the OCA Bundle attachment, verify the signature is from the issuer's public DID, verify the signature, and verify that the [OCA Capture Base] is for the credential being offered or issued to the holder. If verified, the holder should associate the OCA Bundle with the credential, including the signature.</p> <p>The holder SHOULD take appropriate security precautions in handling the remainder of the OCA data, especially the images as they could contain a malicious payload. The security risk is comparable to a browser receiving a web page containing images.</p> <p>Holder software should be implemented to use the OCA Bundle when processing and displaying the credential as noted in the list below. Developers of holder software should be familiar with the overlays the issuer is likely to provide (see list here) and how to use them according to RFC0756 OCA for Aries Style Guide.</p> <ul> <li>Check the country and language settings of the current user and use the appropriate multilingual overlays to respect those settings in displaying credential metadata and attributes (labels, etc.).</li> <li>Consider adding multilingual informational popups in your app using the per   attribute data in the \"information\" overlay.</li> <li>Consider using the PII flag in the Capture Base to provide guidance to the   user about the sharing of PII.</li> <li>Use the branding overlay and RFC0756 OCA for Aries Style Guide in   displaying the credential in various contexts (e.g., in a credential offer   prompt, in a list, selected from a list, alone on a page, etc.).</li> <li>Process the attribute data using the <code>type</code>, <code>character encoding</code>, <code>format</code>,   <code>unit</code> and <code>standard</code> overlays and display tha attributes appropriately for a   given user. For example, display dates in a form suitable for the language and   country settings of the user.</li> <li>Where enumerated names are used for credential attributes, retrieve and use   the name-value pairs in the Entry Code Overlay and Entry Overlay to display the data.</li> <li>Use the OCA-provide metadata about the credential, such as the   name/description of the issuer, name/description of the credential type.</li> </ul> <p>A recommended tactic when adding OCA support to a holder is when a credential is issued without an associated OCA Bundle, generate an OCA Bundle for the credential using the information available about the type of the credential, default images, and randomly generated colors. That allows for the creation of screens that assume an OCA Bundle is available. The RFC0756 OCA for Aries Style Guide contains guidelines for doing that.</p>"},{"location":"features/0755-oca-for-aries/#adding-oca-bundles-to-present-proof-messages","title":"Adding OCA Bundles to Present Proof Messages","text":"<p>Once a holder has an OCA Bundle that was issued with the credential, it MAY pass the OCA Bundle to a verifier when a presenting a proof that includes claims from that credential. This can be done via the present proof credential supplements approach, similar to what used when the credential was issued to the holder. When constructing the <code>present_proof</code> message to hold a proof, the holder would iterate through the credentials in the proof, and if there is an issuer-supplied OCA Bundle for the credentials, add the OCA Bundle as a supplement to the message. The signature from the Issuer MUST be included with the supplement.</p> <p>A holder SHOULD NOT send an OCA Bundle to a verifier if the OCA Bundle is a link, or if any of the data items in the OCA Bundle are links, as noted in the in the warning about external attachments in OCA Bundles.</p>"},{"location":"features/0755-oca-for-aries/#verifier-activities","title":"Verifier Activities","text":"<p>On receipt of a presentation with OCA Bundle supplements, the verifier SHOULD retrieve the OCA Bundle attachments, verify the signatures are from the credential issuers' public DIDs, verify the signatures, and verify that the [OCA Capture Base] is for the credentials being presented to the verifier. If verified, the verifier should associate the OCA Bundle with the source credential from the presentation.</p> <p>On receipt of a presentation with OCA Bundle supplements, the verifier MAY process the OCA Bundle attachment and verify the issuer's signature. If it verifies, the verifier should associate the OCA Bundle with the source credential from the presentation. The verifier SHOULD take appropriate security precautions in handling the data, especially the images. The holder software should be implemented to use the OCA Bundle when processing and displaying the credential as noted in the list below.</p> <p>Developers of verifier software should be familiar with the overlays the issuer is likely to provide (see list here) and how to use them according to RFC0756 OCA for Aries Style Guide. The list of how to use the OCA Bundle as a holder applies equally to verifiers.</p>"},{"location":"features/0755-oca-for-aries/#reference","title":"Reference","text":"<ul> <li>The OCA Specification</li> <li>RFC0756 OCA for Aries Style Guide</li> </ul>"},{"location":"features/0755-oca-for-aries/#drawbacks","title":"Drawbacks","text":"<ul> <li>The use of credential supplements might not be the best way to publish OCA   Bundles. The Aries community is currently investigating if OCA Bundles can be   published to the Verifiable Data Registry upon which the schema and credential   definition are published.</li> <li>As noted in this warning, the use of links   either for OCA Bundles or for the images that are embedded in OCA Bundles are   both extremely useful and problematic. It would be nice to be able to allow   links for/in the OCA Bundles without the potential of being used to track the   holder.</li> <li>If the OCA Bundle is passed to the holder as a link, the issuer must continue   to make that content available for as long as the holder might retain the   credential. Putting the OCA Bundle on a verifiable data registry (such as a   ledger/blockchain) might be a good way to publish such data.</li> <li>The processing of an OCA Bundle, and particularly the processing of images in   the branding overlay, provide an attack vector for malicious issuers.   Developers of holder software SHOULD take precautions in handling and   displaying the data.</li> </ul>"},{"location":"features/0755-oca-for-aries/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>The OCA architecture seems well suited to the Aries verifiable credential use case, supporting the important capabilities of data formats, accessibility support, multilingual support and the desire for issuers to brand their credentials.</li> <li>The use of JSON-LD could provide some of the required capabilities covered by OCA (such as multilingual labels), but that solution requires adding considerable overhead and far more complicated processing to achieve a minimum of the capabilities available through OCA.</li> <li>The current situation of having almost no metadata about credentials is extremely limiting.</li> <li>Extracting best available metadata from the Schema and Credential Definition     objects, converting developer attribute/credential names of human friendly     (e.g. \"given_name\" to Given Name, or \"ssn\" to \"Ssn\") and using that for the     display of a credential.</li> <li>The random generation of a background color for a given credential for use   when displaying a credential.</li> <li>There are other flows that could be used to get an OCA Bundle to holders and verifiers.</li> <li>A publisher of a schema might also publish an OCA Bundle based on the schema, for anyone to use.</li> <li>An Aries agent vendor (such as the creator of an Aries mobile wallet) might create a repository of OCA Bundles of common credential types for deployments of their agent.</li> <li>When using such alternatives, agents retrieving an OCA Bundle should have a way to verify the source of the OCA Bundle, such as having a cryptographic signature over the OCA Bundle from the designated publisher.</li> </ul>"},{"location":"features/0755-oca-for-aries/#prior-art","title":"Prior art","text":"<p>None, as far as we are aware.</p>"},{"location":"features/0755-oca-for-aries/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Are there better ways for issuers to publish OCA Bundles for consumption by   holders/verifiers?</li> <li>How do we balance the prevention of possible tracking by issuers, and the use   of links to OCA Bundles or assets within OCA Bundles.</li> </ul>"},{"location":"features/0755-oca-for-aries/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0756-oca-for-aries-style-guide/","title":"0756: OCA for Aries Style Guide","text":"<ul> <li>Authors: Stephen Curran</li> <li>Status: DEMONSTRATED</li> <li>Since: 2023-01-05</li> <li>Status Note: Implemented in the Bifold Wallet</li> <li>Supersedes: N/A</li> <li>Start Date: 2022-11-15</li> <li>Version: 1.0</li> <li>Tags: feature</li> </ul>"},{"location":"features/0756-oca-for-aries-style-guide/#summary","title":"Summary","text":"<p>Support for credential branding in Aries agents is provided by information provided from the issuer of a given credential type using Overlays Capture Architecture (OCA) overlays. Aries agents (software) use the issuer-provided OCA data when displaying (rendering) the issuer\u2019s credential on screens. This style guide is for issuers to know what information to include in the OCA overlays and how those elements will be used by holders and verifiers. The style guide is also for Aries holder and verifier software makers about how to use the OCA data provided from issuers for a given credential type. It is up to the software makers to use OCA data provided by the issuers as outlined in this guide.</p> <p>For more information about the use of OCA in Aries, please see RFC0755 OCA for Aries</p>"},{"location":"features/0756-oca-for-aries-style-guide/#motivation","title":"Motivation","text":"<p>OCA Bundles is intended to be used by ALL Aries issuers and ALL Aries Holders. Some Aries verifiers might also use OCA Bundles. This Style Guide provides guidance for issuers about what overlays to populate and with what information, and guidance for holders (and verifiers) about how to use the OCA Bundle data provided by the issuers when rendering Credentials on screen.</p> <ul> <li>Issuers SHOULD follow this Style Guide in preparing an OCA Bundle for each   credential type they issue. Holders (and verifiers) expect issuers to follow   the guidance provided in this RFC.</li> <li>Holder creators (and verifiers) SHOULD follow this Style Guide in   rendering credentials for users. Issuers expect holders (and verifiers) to   follow the guidance provided in this RFC.</li> </ul> <p>Issuers, holders and verifiers expect other issuers, holders and verifiers to follow this Style Guide. Issuers, holders and verifiers not following this Style Guide will likely cause end users to see unpredictable and potential \"unfriendly\" results when credentials are displayed.</p> <p>It is in the best interest of the Aries community as a whole for those writing Aries agent software to use OCA Bundles and to follow this Style Guide in displaying credentials.</p>"},{"location":"features/0756-oca-for-aries-style-guide/#tutorial","title":"Tutorial","text":"<p>Before reviewing this Style Guide, please review and be familiar with RFC0755 OCA for Aries. It provides the technical details about OCA, the issuer role in creating an OCA Bundle and delivering to holders (and optionally, from holders to verifiers) and the holders role in extracting information from the OCA Bundle about a held credential. This Style Guide provides the details about what each participant is expected to do in creating OCA Bundles and using the data in OCA Bundles to render credentials on screen.</p>"},{"location":"features/0756-oca-for-aries-style-guide/#oca-for-aries-style-guide","title":"OCA for Aries Style Guide","text":"<p>A Credential User Interface (UI) pulls from a issuer-provided OCA Bundle the following elements:</p> <ul> <li>Meta Overlays (multilingual):<ul> <li>Credential name</li> <li>Issuer name</li> <li>Issuer description</li> <li>Issuer URL</li> <li>Credential help text</li> <li>Credential support URL</li> <li>Non-Production watermark</li> </ul> </li> <li>\u201cbranding\u201d Overlay:<ul> <li>logo - a URI for an inline or external logo image to display with the credential. See details below about the use and requirements for the image.</li> <li>background_image -  a URI for an inline or external background image to display with the credential. See details below about the use and requirements for the image.</li> <li>background_image_slice -  a URI for an inline or external background image slice to display with the credential. See details below about the use and requirements for the image.</li> <li>primary_background_color - an RGB color code for the credential background</li> <li>secondary_background_color - an RGB color code for the credential background highlight background color.</li> <li>primary_attribute - the name of the primary capture base attribute to display \\ on the credential.</li> <li>secondary_attribute - the name of the secondary capture base attribute to \\ display on the credential.</li> <li>issued_date_attribute - the name of a capture base attribute that is the date of issuance of the credential. If there is no such attribute, leave it blank.</li> <li>expiry_date_attribute - the name of a capture base attribute that is the expiry date of the credential. If there is no such attribute, leave it blank.</li> </ul> </li> </ul>"},{"location":"features/0756-oca-for-aries-style-guide/#credential-layouts","title":"Credential Layouts","text":"<p>This style guide defines three layouts for credentials, the credential list layout, the stacked list layout, and the single credential layout. Holders and verifiers SHOULD display credentials using only these layouts in the context of a screen containing either a list of credentials or a single credential, respectively. Holders and verifiers MAY display other relevant information on the page along with one of the layouts.</p> <p>The stacked list is the same as the credential layout, with the credentials that are stacked cutoff between elements 6 and 7. Examples of the stacked layout can be seen in the Stacking section of this document. In the Stacked layout, one of the credentials in the stack may be displayed using the full credential list layout.</p> Credential List Layout Single Credential Layout <p>Figure: Credential Layouts</p> <p>The numbered items in the layouts are as follows. In the list, the OCA data element(s) is provided first, and, where the needed data element(s) is not available through an OCA Bundle, a calculation for a fallback is defined. It is good practice to have code that populates a per credential data structure with data from the credential\u2019s OCA Bundle if available, and if not, populated by the fallbacks. That way, the credentials are displayed in the same way with or without an OCA Bundle per credential. Unless noted, all of the data elements come from the \u201cbranding\u201d overlay. Items 10 and 11 are not included in the layouts but are included to document the fallbacks for those values.</p> <ol> <li><code>logo</code><ul> <li>Fallback: First letter of the alias of the DIDComm connection</li> </ul> </li> <li><code>background_image_slice</code> if present, else <code>secondary_background_color</code><ul> <li>Fallback: Black overlay at 24% opacity</li> </ul> </li> <li><code>primary_background_color</code><ul> <li>Fallback: Randomly generated color</li> </ul> </li> <li>Credential Status derived from revocation status and expiry date (if available)<ul> <li>Fallback: Empty</li> </ul> </li> <li>Meta overlay item <code>issuer_name</code><ul> <li>Fallback: Alias of the DIDComm connection</li> </ul> </li> <li>Meta overlay item <code>name</code><ul> <li>Fallback: The AnonCreds Credential Definition <code>tag</code>, unless the value is either <code>credential</code> or <code>default</code>, otherwise the AnonCreds <code>schema_name</code> attribute from the AnonCreds schema</li> </ul> </li> <li><code>primary_attribute</code><ul> <li>Fallback: Empty</li> </ul> </li> <li><code>secondary_attribute</code><ul> <li>Fallback: Empty</li> </ul> </li> <li><code>background_image</code> if present, else <code>secondary_background_color</code><ul> <li>Fallback: Black overlay at 24% opacity (default)</li> </ul> </li> <li><code>issued_date_attribute</code><ul> <li>Fallback: If tracked, the date the credential was received by the Holder, else empty.</li> </ul> </li> <li><code>expiry_date_attribute</code><ul> <li>Fallback: Empty</li> </ul> </li> </ol> <p></p> <p>Figure: Template layers</p> <p>The font color is either black or white, as determined by calculating contrast levels (following Web Content Accessibility Guidelines) against the background colors from either the OCA Bundle or the generated defaults.</p> <p>Figure: example of a credential with no override specifications</p>"},{"location":"features/0756-oca-for-aries-style-guide/#logo-image-specifications","title":"Logo Image Specifications","text":"<p>The image in the top left corner is a space for the issuer logo. This space should not be used for anything other than the issuer logo. The logo image may be masked to fit within a rounded square with varying corner radii. Thus, the logo must be a square image (aspect ratio 1:1), as noted in the table below. The background is default white, therefore logo files with a transparent background will overlay a white background.</p> <p>The following are the specifications for the credential logo for issuers. </p> <p>Images should be as small as possible to balance quality and download speed. To ensure image quality on all devices, it is recommended to use vector based file types such as SVG. </p> Preferred file type     SVG, JPG, PNG with transparent background,      Aspect ratio     1:1     Recommended image size     240x240 px     Color space     RGB"},{"location":"features/0756-oca-for-aries-style-guide/#background-image-slice-specifications","title":"Background Image Slice Specifications","text":"<p>For issuers to better represent their brand, issuers may specify an image slice that will be used as outlined in the samples below. Note the use of the image in a long, narrow space and the dynamic height. The image slice will be top aligned, scaled (preserving aspect ratio) and cropped as needed to fill the space.</p> <p>Credential height is dependent on the content and can be unpredictable. Different languages (English, French, etc.) will add more length to names, OS level settings such as font changes or text enlargement will unpredictably change the height of the credential. The recommended image size below is suggested to accommodate for most situations. Note that since the image is top aligned, the top area of the image is certain to be displayed, while the bottom section of the image may not always be visible. </p> <p></p> <p>Figure: Examples of the image slice behavior</p> <p>Types of images best used in this area are abstract images or graphical art. Do not use images that are difficult to interpret when cropped.</p> Do <p> Use an abstract image that can work even when cropped unexpectedly.      Don\u2019t <p> Use images that are hard to interpret when cropped. Avoid words     <p>Figure: Background image slice Do\u2019s and Don\u2019ts</p> Preferred file type     SVG, PNG, JPG     Aspect ratio     1:10     Recommended image size     120x1200 px     Color space     RGB"},{"location":"features/0756-oca-for-aries-style-guide/#background-image-specifications","title":"Background Image Specifications","text":"<p>The background image is to give issuers more opportunities to represent their brand and is used in some credential display screens. Avoid text in the background image.</p> Do <p> Use an image that represents your brand.     Don\u2019t <p> Use this image as a marketing platform. Avoid the use of text.     <p>Figure: Background image Do\u2019s and Don\u2019ts</p> Preferred file type     SVG, PNG, JPG     Aspect ratio     3:1     Recommended image size     1080x360 px     Color space     RGB"},{"location":"features/0756-oca-for-aries-style-guide/#credential-status","title":"Credential Status","text":"<p>To reduce visual clutter, the issued date (if present), expiry date (if present), and revocation status (if applicable) may be interpreted by an icon at the top right corner when:</p> <ul> <li>A new credential has been added, based on issued_date_attribute, if set, or for a holder agent/wallet, the date the credential was received.</li> <li>A credential is revoked, if the credential is revocable and is known to have been revoked.</li> <li>A credential is expiring soon or expired, based on expiry_date_attribute, if set.</li> </ul> <p></p> <p>Figure: An example demonstrating how the revocation date, expiry date or issued date may be represented.</p> <p>The interpretation of the issued date, expiry date and revocation status may be dependent on the holder software, such as a wallet. For example, the specific icons used may vary by wallet, or the full status data may be printed over the credential.</p>"},{"location":"features/0756-oca-for-aries-style-guide/#credential-name-and-issuer-name-guidelines","title":"Credential name and Issuer name guidelines","text":"<p>Issuers should be mindful of the length of text on the credential as lengthy text will dynamically change the height of the credential. Expansive credentials risk reducing the number of fully visible credentials in a list.</p> <p></p> <p>Figure: An example demonstrating how lengthy credentials can limit the number of visible credentials.</p> <p>Be mindful of other factors that may increase the length of text and hence, the height of the credential such as translated languages or the font size configured at the OS level.</p> <p></p> <p>Figure: Examples showing the treatment of lengthy names</p>"},{"location":"features/0756-oca-for-aries-style-guide/#primary-and-secondary-attribute-guidelines","title":"Primary and Secondary Attribute Guidelines","text":"<p>If issuers expect people to hold multiples of their credentials of the same type, they may want to specify a primary and secondary attribute to display on the card face. </p> <p>Note that wallet builders or holders may limit the visibility of the primary and secondary attributes on the card face to mitigate privacy concerns. Issuers can expect that these attributes may be fully visible, redacted, or hidden.</p> <p>To limit personal information from being displayed on a card face, only specify what is absolutely necessary for wallet holders to differentiate between credentials of the same type. Do not display private information such as medical related attributes.</p> Do <p> Use attributes that help users identify their credentials. Always consider if a primary and secondary attribute is absolutely necessary.     Don\u2019t <p> Display attributes that contain private information.     <p>Figure: Primary/secondary attribute Do\u2019s and Don\u2019ts</p>"},{"location":"features/0756-oca-for-aries-style-guide/#non-production-watermark","title":"Non-production watermark","text":"<p>To identify non-production credentials, issuers can add a watermark to their credentials. The watermark is a simple line of text that can be customized depending on the issuer needs. The line of text will also appear as a prefix to the credential name. The line of text should be succinct to ensure legibility. This watermark is not intended to be used for any other purpose than to mark non-production credentials. Ensure proper localization to the watermark is present in all languages.</p> <p>Example text include:</p> <ul> <li>DEMO</li> <li>SAMPLE</li> <li>NON-PRODUCTION</li> <li>TEST</li> <li>DEVELOPMENT</li> <li>DO NOT USE </li> </ul> Do <p> Use succinct words to describe the type of issued credential. This ensures legibility and does not increase the size of the credential unnecessarily.     Don\u2019t <p> Use long works or words that do not describe non-production credentials."},{"location":"features/0756-oca-for-aries-style-guide/#credential-resizing","title":"Credential resizing","text":"<p>Credential size depends on the content of the credential and the size of the device. Text areas are resized according to the width. </p> <p></p> <p>Figure: Treatment of the credential template on different devices</p> <p></p> <p>Figure: An example of credential on different devices</p>"},{"location":"features/0756-oca-for-aries-style-guide/#stacking","title":"Stacking","text":"<p>Credentials may be stacked to overlap each other to increase the number of visible credentials in the viewport. The header remains unchanged. The issuer name, logo and credential name will always be visible but the primary and secondary attributes and the image slice will be obscured. </p> <p></p> <p>Figure: An example of stacked credentials with default and enlarged text.</p>"},{"location":"features/0756-oca-for-aries-style-guide/#accessibility","title":"Accessibility","text":"<p>The alt-tags for the logo and background images come from the multilingual OCA Meta Overlay for the issuer name and credential type name. </p>"},{"location":"features/0756-oca-for-aries-style-guide/#more-variations","title":"More Variations","text":"<p>To view more credential variations using this template, view the Adobe XD file.</p>"},{"location":"features/0756-oca-for-aries-style-guide/#drawbacks","title":"Drawbacks","text":"<p>Defining and requesting adherence to a style guide is a lofty goal. With so many independent issuers, holders and verifiers using Aries, it is a challenge to get everyone to agree on a single way to display credentials for users. However, the alternative of everyone \"doing their own thing\", perhaps in small groups, will result in a poor experience for users, and be frustrating to both issuers trying to convey their brand, and holders (and verifiers) trying to create a beautiful experience for their users.</p>"},{"location":"features/0756-oca-for-aries-style-guide/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>In coming up with this Style Guide, we consider how much control to give issuers, ultimately deciding that given them too much control (e.g., pixel precise layout of their credential) creates a usage/privacy risk (people using their credentials by showing them on screen, with all private data showing), is technical extremely difficult given the variations of holder devices, and likely to result in a very poor user experience.</p> <p>A user experience group in Canada came up with the core design, and the Aries Working Group reviewed and approved of the Style Guide.</p>"},{"location":"features/0756-oca-for-aries-style-guide/#prior-art","title":"Prior art","text":"<p>The basic concept of giving issuers a small set of parameters that they could control in branding of their data is used in many applications and communities. Relevant to the credential use case is the application of this concept in the Apple Wallet and Google Wallet. Core to this is the setting of expectations of all of the participants of how their data will be used, and how to use the data provided. In the Aries holder (and verifier) case, unlike that of the Apple Wallet and Google Wallet, is that there is not just one holder that is using the data from many issuers to render the data on screen, but many holders that are expected to adhere to this Style Guide.</p>"},{"location":"features/0756-oca-for-aries-style-guide/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>A challenge will be in evolving this Style Guide based on new input from those that use it over time. We expect the Aries RFC version process to be sufficient. However, this is the first time that this process has been applied to a user experience \"protocol\", as opposed to a technical, messaging protocol.</li> </ul>"},{"location":"features/0756-oca-for-aries-style-guide/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0771-anoncreds-attachments/","title":"Aries RFC 0771: AnonCreds Attachment Formats for Requesting and Presenting Credentials","text":"<ul> <li>Authors: Timo Glastra, Daniel Hardman</li> <li>Status: PROPOSED</li> <li>Since: 2023-02-24</li> <li>Status Note: Formalizes the AnonCreds attachments for issuing credentials and presenting proofs over DIDComm.</li> <li>Supersedes: Hyperledger Indy specific AnonCreds attachment formats documented in Aries RFC 0592.</li> <li>Start Date: 2023-02-24</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0771-anoncreds-attachments/#summary","title":"Summary","text":"<p>This RFC registers attachment formats used with Hyperledger AnonCreds ZKP-oriented credentials in the Issue Credential Protocol 2.0 and Present Proof Protocol 2.0. If not specified otherwise, this follows the rules as defined in the AnonCreds Specification.</p>"},{"location":"features/0771-anoncreds-attachments/#motivation","title":"Motivation","text":"<p>Allows AnonCreds credentials to be used with credential-related protocols that take pluggable formats as payloads.</p>"},{"location":"features/0771-anoncreds-attachments/#reference","title":"Reference","text":""},{"location":"features/0771-anoncreds-attachments/#credential-filter-format","title":"Credential Filter format","text":"<p>The potential holder uses this format to propose criteria for a potential credential for the issuer to offer. The format defined here is not part of the AnonCreds spec, but is a Hyperledger Aries-specific message.</p> <p>The identifier for this format is <code>anoncreds/credential-filter@v1.0</code>. The data structure allows specifying zero or more criteria from the following structure:</p> <pre><code>{\n  \"schema_issuer_id\": \"&lt;schema_issuer_id&gt;\",\n  \"schema_name\": \"&lt;schema_name&gt;\",\n  \"schema_version\": \"&lt;schema_version&gt;\",\n  \"schema_id\": \"&lt;schema_identifier&gt;\",\n  \"issuer_id\": \"&lt;issuer_id&gt;\",\n  \"cred_def_id\": \"&lt;credential_definition_identifier&gt;\"\n}\n</code></pre> <p>The potential holder may not know, and need not specify, all of these criteria. For example, the holder might only know the schema name and the (credential) issuer id. Recall that the potential holder may specify target attribute values and MIME types in the credential preview.</p> <p>For example, the JSON structure might look like this:</p> <pre><code>{\n  \"schema_issuer_id\": \"did:sov:4RW6QK2HZhHxa2tg7t1jqt\",\n  \"schema_name\": \"bcgov-mines-act-permit.bcgov-mines-permitting\",\n  \"issuer_id\": \"did:sov:4RW6QK2HZhHxa2tg7t1jqt\"\n}\n</code></pre> <p>A complete <code>propose-credential</code> message from the Issue Credential protocol 2.0 embeds this format as an attachment in the <code>filters~attach</code> array:</p> <pre><code>{\n  \"@id\": \"&lt;uuid of propose message&gt;\",\n  \"@type\": \"https://didcomm.org/issue-credential/%VER/propose-credential\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"&lt;attach@id value&gt;\",\n      \"format\": \"anoncreds/credential-filter@v1.0\"\n    }\n  ],\n  \"filters~attach\": [\n    {\n      \"@id\": \"&lt;attach@id value&gt;\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"ewogICAgInNjaGVtYV9pc3N1ZXJfZGlkIjogImRpZDpzb3Y... (clipped)... LMkhaaEh4YTJ0Zzd0MWpxdCIKfQ==\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0771-anoncreds-attachments/#credential-offer-format","title":"Credential Offer format","text":"<p>This format is used to clarify the structure and semantics (but not the concrete data values) of a potential credential, in offers sent from issuer to potential holder.</p> <p>The identifier for this format is <code>anoncreds/credential-offer@v1.0</code>. It must follow the structure of a Credential Offer as defined in the AnonCreds specification.</p> <p>The JSON structure might look like this:</p> <pre><code>{\n    \"schema_id\": \"4RW6QK2HZhHxa2tg7t1jqt:2:bcgov-mines-act-permit.bcgov-mines-permitting:0.2.0\",\n    \"cred_def_id\": \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    \"nonce\": \"57a62300-fbe2-4f08-ace0-6c329c5210e1\",\n    \"key_correctness_proof\" : &lt;key_correctness_proof&gt;\n}\n</code></pre> <p>A complete <code>offer-credential</code> message from the Issue Credential protocol 2.0 embeds this format as an attachment in the <code>offers~attach</code> array:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/offer-credential\",\n    \"@id\": \"&lt;uuid of offer message&gt;\",\n    \"replacement_id\": \"&lt;issuer unique id&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\": \"anoncreds/credential-offer@v1.0\"\n        }\n    ],\n    \"offers~attach\": [\n        {\n            \"@id\": \"&lt;attach@id value&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"ewogICAgInNjaGVtYV9pZCI6ICI0Ulc2UUsySFpoS... (clipped)... jb3JyZWN0bmVzc19wcm9vZj4KfQ==\"\n            }\n        }\n    ]\n}\n</code></pre>"},{"location":"features/0771-anoncreds-attachments/#credential-request-format","title":"Credential Request format","text":"<p>This format is used to formally request a credential. It differs from the Credential Offer above in that it contains a cryptographic commitment to a link secret; an issuer can therefore use it to bind a concrete instance of an issued credential to the appropriate holder. (In contrast, the credential offer describes the schema and cred definition, but not enough information to actually issue to a specific holder.)</p> <p>The identifier for this format is <code>anoncreds/credential-request@v1.0</code>. It must follow the structure of a Credential Request as defined in the AnonCreds specification.</p> <p>The JSON structure might look like this:</p> <pre><code>{\n    \"entropy\" : \"e7bc23ad-1ac8-4dbc-92dd-292ec80c7b77\",\n    \"cred_def_id\" : \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    // Fields below can depend on Cred Def type\n    \"blinded_ms\" : &lt;blinded_master_secret&gt;,\n    \"blinded_ms_correctness_proof\" : &lt;blinded_ms_correctness_proof&gt;,\n    \"nonce\": \"fbe22300-57a6-4f08-ace0-9c5210e16c32\"\n}\n</code></pre> <p>A complete <code>request-credential</code> message from the Issue Credential protocol 2.0 embeds this format as an attachment in the <code>requests~attach</code> array:</p> <pre><code>{\n  \"@id\": \"cf3a9301-6d4a-430f-ae02-b4a79ddc9706\",\n  \"@type\": \"https://didcomm.org/issue-credential/%VER/request-credential\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"7cd11894-838a-45c0-a9ec-13e2d9d125a1\",\n      \"format\": \"anoncreds/credential-request@v1.0\"\n    }\n  ],\n  \"requests~attach\": [\n    {\n      \"@id\": \"7cd11894-838a-45c0-a9ec-13e2d9d125a1\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"ewogICAgInByb3Zlcl9kaWQiIDogImRpZDpzb3Y6YWJjeHl.. (clipped)... DAtNTdhNi00ZjA4LWFjZTAtOWM1MjEwZTE2YzMyIgp9\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0771-anoncreds-attachments/#credential-format","title":"Credential format","text":"<p>A concrete, issued AnonCreds credential may be transmitted over many protocols, but is specifically expected as the final message in Issuance Protocol 2.0. The identifier for this format is <code>anoncreds/credential@v1.0</code>.</p> <p>This is a credential that's designed to be held but not shared directly. It is stored in the holder's wallet and used to derive a novel ZKP or W3C-compatible verifiable presentation just in time for each sharing of credential material.</p> <p>The encoded values of the credential MUST follow the encoding algorithm as described in Encoding Attribute Data. It must follow the structure of a Credential as defined in the AnonCreds specification.</p> <p>The JSON structure might look like this:</p> <pre><code>{\n    \"schema_id\": \"4RW6QK2HZhHxa2tg7t1jqt:2:bcgov-mines-act-permit.bcgov-mines-permitting:0.2.0\",\n    \"cred_def_id\": \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    \"rev_reg_id\", \"EyN78DDGHyok8qw6W96UBY:4:EyN78DDGHyok8qw6W96UBY:3:CL:56389:CardossierOrgPerson:CL_ACCUM:1-1000\",\n    \"values\": {\n        \"attr1\" : {\"raw\": \"value1\", \"encoded\": \"value1_as_int\" },\n        \"attr2\" : {\"raw\": \"value2\", \"encoded\": \"value2_as_int\" }\n    },\n    // Fields below can depend on Cred Def type\n    \"signature\": &lt;signature&gt;,\n    \"signature_correctness_proof\": &lt;signature_correctness_proof&gt;\n    \"rev_reg\": &lt;revocation registry state&gt;\n    \"witness\": &lt;witness&gt;\n}\n</code></pre> <p>An exhaustive description of the format is out of scope here; it is more completely documented in the AnonCreds Specification.</p>"},{"location":"features/0771-anoncreds-attachments/#proof-request-format","title":"Proof Request format","text":"<p>This format is used to formally request a verifiable presenation (proof) derived from an AnonCreds-style ZKP-oriented credential.</p> <p>The format can also be used to propose a presentation, in this case the <code>nonce</code> field MUST NOT be provided. The <code>nonce</code> field is required when the proof request is used to request a proof.</p> <p>The identifier for this format is <code>anoncreds/proof-request@v1.0</code>. It must follow the structure of a Proof as defined in the AnonCreds specification.</p> <p>Here is a sample proof request that embodies the following: \"Using a government-issued ID, disclose the credential holder\u2019s name and height, hide the credential holder\u2019s sex, get them to self-attest their phone number, and prove that their age is at least 18\":</p> <pre><code>{\n    \"nonce\": \"2934823091873049823740198370q23984710239847\",\n    \"name\":\"proof_req_1\",\n    \"version\":\"0.1\",\n    \"requested_attributes\":{\n        \"attr1_referent\": {\"name\":\"sex\"},\n        \"attr2_referent\": {\"name\":\"phone\"},\n        \"attr3_referent\": {\"names\": [\"name\", \"height\"], \"restrictions\": &lt;restrictions specifying government-issued ID&gt;}\n    },\n    \"requested_predicates\":{\n        \"predicate1_referent\":{\"name\":\"age\",\"p_type\":\"&gt;=\",\"p_value\":18}\n    }\n}\n</code></pre>"},{"location":"features/0771-anoncreds-attachments/#proof-format","title":"Proof format","text":"<p>This is the format of an AnonCreds-style ZKP. The raw values encoded in the presentation MUST be verified against the encoded values using the encoding algorithm as described in Encoding Attribute Data</p> <p>The identifier for this format is <code>anoncreds/proof@v1.0</code>. It must follow the structure of a Presentation as defined in the AnonCreds specification.</p> <p>A proof that responds to the previous proof request sample looks like this:</p> <pre><code>{\n  \"proof\":{\n    \"proofs\":[\n      {\n        \"primary_proof\":{\n          \"eq_proof\":{\n            \"revealed_attrs\":{\n              \"height\":\"175\",\n              \"name\":\"1139481716457488690172217916278103335\"\n            },\n            \"a_prime\":\"5817705...096889\",\n            \"e\":\"1270938...756380\",\n            \"v\":\"1138...39984052\",\n            \"m\":{\n              \"master_secret\":\"375275...0939395\",\n              \"sex\":\"3511483...897083518\",\n              \"age\":\"13430...63372249\"\n            },\n            \"m2\":\"1444497...2278453\"\n          },\n          \"ge_proofs\":[\n            {\n              \"u\":{\n                \"1\":\"152500...3999140\",\n                \"2\":\"147748...2005753\",\n                \"0\":\"8806...77968\",\n                \"3\":\"10403...8538260\"\n              },\n              \"r\":{\n                \"2\":\"15706...781609\",\n                \"3\":\"343...4378642\",\n                \"0\":\"59003...702140\",\n                \"DELTA\":\"9607...28201020\",\n                \"1\":\"180097...96766\"\n              },\n              \"mj\":\"134300...249\",\n              \"alpha\":\"827896...52261\",\n              \"t\":{\n                \"2\":\"7132...47794\",\n                \"3\":\"38051...27372\",\n                \"DELTA\":\"68025...508719\",\n                \"1\":\"32924...41082\",\n                \"0\":\"74906...07857\"\n              },\n              \"predicate\":{\n                \"attr_name\":\"age\",\n                \"p_type\":\"GE\",\n                \"value\":18\n              }\n            }\n          ]\n        },\n        \"non_revoc_proof\":null\n      }\n    ],\n    \"aggregated_proof\":{\n      \"c_hash\":\"108743...92564\",\n      \"c_list\":[ 6 arrays of 257 numbers between 0 and 255]\n    }\n  },\n  \"requested_proof\":{\n    \"revealed_attrs\":{\n      \"attr1_referent\":{\n        \"sub_proof_index\":0,\n        \"raw\":\"Alex\",\n        \"encoded\":\"1139481716457488690172217916278103335\"\n      }\n    },\n    \"revealed_attr_groups\":{\n      \"attr4_referent\":{\n        \"sub_proof_index\":0,\n        \"values\":{\n          \"name\":{\n            \"raw\":\"Alex\",\n            \"encoded\":\"1139481716457488690172217916278103335\"\n          },\n          \"height\":{\n            \"raw\":\"175\",\n            \"encoded\":\"175\"\n          }\n        }\n      }\n    },\n    \"self_attested_attrs\":{\n      \"attr3_referent\":\"8-800-300\"\n    },\n    \"unrevealed_attrs\":{\n      \"attr2_referent\":{\n        \"sub_proof_index\":0\n      }\n    },\n    \"predicates\":{\n      \"predicate1_referent\":{\n        \"sub_proof_index\":0\n      }\n    }\n  },\n  \"identifiers\":[\n    {\n      \"schema_id\":\"NcYxiDXkpYi6ov5FcYDi1e:2:gvt:1.0\",\n      \"cred_def_id\":\"NcYxi...cYDi1e:2:gvt:1.0:TAG_1\",\n      \"rev_reg_id\":null,\n      \"timestamp\":null\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0771-anoncreds-attachments/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0780-data-urls-images/","title":"RFC 0780: Use Data URLs for Images and More in Credential Attributes","text":"<ul> <li>Authors: Stephen Curran, Clecio Varjao</li> <li>Status: DEMONSTRATED</li> <li>Since: 2024-03-02</li> <li>Status Note: Implemented in the Bifold Wallet</li> <li>Supersedes: None</li> <li>Start Date: 2023-03-31</li> <li>Tags: feature</li> </ul>"},{"location":"features/0780-data-urls-images/#summary","title":"Summary","text":"<p>Some credentials include attributes that are not simple strings or numbers, such as images or JSON data structures. When complex data is put in an attribute the issuer SHOULD issue the attribute as a Data URL, as defined in IETF RFC 2397, and whose use is described in this Mozilla Developer Documentation article.</p> <p>On receipt of all credentials and presentations, holders and verifiers SHOULD check all string attributes to determine if they are Data URLs. If so, they SHOULD securely process the data according to the metadata information in the Data URL, including:</p> <ul> <li>the MIME type of the data (such as <code>image/png</code> or <code>application/json</code>)</li> <li>whether the data is base64 encoded.</li> </ul> <p>This allows, for example, an Aries Mobile Wallet to detect that a data element is an image and how it is encoded, and display it for the user as an image, not as a long (long) string of gibberish.</p>"},{"location":"features/0780-data-urls-images/#motivation","title":"Motivation","text":"<p>Holders and verifiers want to enable a delightful user experience when an issuer issues attributes that contain other than strings or numbers, such as an image or a JSON data structure. In such cases, the holder and verifiers need a way to know the format of the data so it can be processed appropriately and displayed usefully. While the Aries community encourages the use of the Overlays Capture Architecture specification as outlined in RFC 0755 OCA for Aries for such information, there will be times where an OCA Bundle is not available for a given credential. In the absence of an OCA Bundle, the holders and verifiers of such attributes need data type information for processing and displaying the attributes.</p>"},{"location":"features/0780-data-urls-images/#tutorial","title":"Tutorial","text":"<p>An issuer wants to issue a verifiable credential that contains an image, such as a photo of the holder to which the credential is issued. Issuing such an attribute is typically done by converting the image to a base64 string. This is handled by the various verifiable credential formats supported by Aries issuers. The challenge is to convey to the holder and verifiers that the attribute is not \"just another string\" that can be displayed on screen to the user. By making the attribute a Data URL, the holder and verifiers can detect the type and encoding of the attribute, process it, and display it correctly.</p> <p>For example, this image (from the IETF 2793 specification):</p> <p></p> <p>can be issued as the attribute <code>photo</code> in a verifiable credential with its value a Data URL as follows:</p> <pre><code>{\n\"photo\": \"data:image/png;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAwAAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFzByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSpa/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJlZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uisF81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PHhhx4dbgYKAAA7\"\n}\n</code></pre> <p>The syntax of a Data URL is described in IETF RFC 2397. The \\ version is: <ul> <li><code>data:</code> -- hardcoded.</li> <li><code>&lt;MIME type&gt;</code> -- optional, the MIME type of the data.</li> <li><code>;base64</code> -- optional, if present, the data is base64 encoded.</li> <li><code>,</code> -- hardcoded separator.</li> <li><code>&lt;data&gt;</code> -- the attribute data in the specified encoding.</li> </ul> <p>A holder or verifier receiving a credential or presentation MUST check each attribute is a string, and if so, if it is a Data URL (likely by using a regular expression). If it is a Data URL it should be securely processed accordingly.</p> <p>Aries Data URL verifiable credential attributes MUST include the <code>&lt;MIME type&gt;</code>.</p>"},{"location":"features/0780-data-urls-images/#image-size","title":"Image Size","text":"<p>A separate issue from the use of Data URLs is how large an image (or other data type) can be put into an attribute and issued as a verifiable credential. That is an issue that is dependent on the verifiable credential implementation and other factors. For AnonCreds credentials, the attribute will be treated as a string, a hash will be calculated over the string, and the resulting number will be signed--just as for any string. The size of the image does not matter. However, there may be other components in your deployment that might impact how big an attribute in a credential can be. Many in the community have successfully experimented with the use of images in credentials, so consulting others on the question might be helpful.</p> <p>For the purpose of this RFC, the amount of data in the attribute is not relevant.</p>"},{"location":"features/0780-data-urls-images/#security","title":"Security","text":"<p>As noted in this Mozilla Developer Documentation and this Mozilla Security Blog Post about Data URLs, Data URLs are blocked from being used in the Address Bar of all major browsers. That is because Data URLs may contain HTML that can contain anything, including HTML forms that collect data from users. Since Aries holder and verifier agents are not general purpose content presentation engines (as are browsers) the use of Data URLs are less of a security risk. Regardless, holders and verifiers MUST limit their processing of attributes containing Data URLs to displaying the data, and not executing the data. Further, Aries holders and verifiers MUST stay up on dependency vulnerabilities, such as images constructed to exploit vulnerabilities in libraries that display images.</p>"},{"location":"features/0780-data-urls-images/#reference","title":"Reference","text":"<p>References for implementing this RFC are:</p> <ul> <li>IETF RFC 2397</li> <li>Mozilla Developer Documentation</li> <li>Stack Overflow Article on a Data URL Regex</li> <li>A GitHub Gist of JavaScript to detect a data URL</li> </ul>"},{"location":"features/0780-data-urls-images/#drawbacks","title":"Drawbacks","text":"<p>The Aries community is moving to the use of the [Overlay Capture Architecture Specification] to provide a more generalized way to accomplish the same thing (understanding the meaning, format and encoding of attributes), so this RFC is duplicating a part of that capability. That said, it is easier and faster for issuers to start using, and for holders and verifiers to detect and use.</p> <p>Issuers may choose to issue Data URLs with MIME types not commonly known to Aries holder and verifier components. In such cases, the holder or verifier MUST NOT display the data.</p> <p>Even if the MIME type of the data is known to the holders and verifiers, it may not be obvious how to present the data on screen in a useful way. For example, an attribute holding a JSON data structure with an array of values may not easily be displayed.</p>"},{"location":"features/0780-data-urls-images/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>We considered using the same approach as is used in RFC 0441 Present Proof Best Practices of a special suffix (<code>_img</code>) for the attribute name in a credential to indicate that the attribute held an image. However, that provides far less information than this approach (e.g., what type of image?), and its use is limited to images. This RFC defines a far more complete, standard, and useful approach.</p> <p>As noted in the drawbacks section, this same functionality can (and should) be achieved with the broad deployment of [Overlay Capture Architecture Specification] and RFC 0755 OCA for Aries. However, the full deployment of RFC 0755 OCA for Aries will take some time, and in the meantime, this is a \"quick and easy\" alternate solution that is useful alongside OCA for Aries.</p>"},{"location":"features/0780-data-urls-images/#prior-art","title":"Prior art","text":"<p>In the use cases of which we are aware of issuers putting images and JSON structures into attributes, there was no indicator of the attribute content, and the holders and verifiers were assumed to either \"know\" about the data content based on the type of credential, or they just displayed the data as a string.</p>"},{"location":"features/0780-data-urls-images/#unresolved-questions","title":"Unresolved questions","text":"<p>Should this RFC define a list (or the location of a list) of MIME types that Aries issuers can use in credential attributes?</p> <p>For supported MIME types that do not have obvious display methods (such as JSON), should there be a convention for how to display the data?</p>"},{"location":"features/0780-data-urls-images/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0793-unqualfied-dids-transition/","title":"Aries RFC 0793: Unqualified DID Transition","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: ACCEPTED</li> <li>Since: 2023-07-11</li> <li>Status Note: In Step 1 - Target Deployment Date: 2024-07-02 </li> <li>Supersedes:</li> <li>Start Date: 2023-07-11</li> <li>Tags: feature, community-update</li> </ul>"},{"location":"features/0793-unqualfied-dids-transition/#summary","title":"Summary","text":"<p>Historically, Aries use of the Indy SDK's wallet included the use of 'unqualified DIDs' or DIDs without a did: prefix and method.  This transition documents the process of migrating any such DIDs still in use to fully qualified DIDs.</p> <p>This process involves the adoption of the Rotate DID protocol and algorithm 4 of the Peer DID Method, then the rotation from the unqualified DIDs to any fully qualified DID, with preference for did:peer:4.</p> <p>The adoption of these specs will further prepare the Aries community for adoption of DIDComm v2 by providing an avenue for adding DIDComm v2 compatible endpoints.</p> <p>Codebases that do not use unqualified DIDs MUST still adopt DID Rotation and did:peer:4 as part of this process, even if no unqualified DIDs must be rotated.</p> <p>This RFC follows the guidance in RFC 0345 about community-coordinated updates to (try to) ensure that independently deployed, interoperable agents remain interoperable throughout this transition.</p> <p>The transition from the unqualified to qualified DIDs will occur in four steps:</p> <ul> <li>Pre-work: where we agree on the transition plan outlined in this RFC.</li> <li>Finalize did:peer:4 details, including feature discovery support of did:peer:4.</li> <li>Verify transisiton plan and code.</li> <li>Step 1: Agent builders MUST update all agent code bases and deployments to support DID Rotation and did:peer:4. </li> <li>Each agent builder SHOULD notify the community they have completed Step 1 by submitting a PR to update their entry in the implementations accordingly.</li> <li>Target Date for code update: 2024-05-01</li> <li>Target Date for deployment update: 2024-07-02</li> <li>Step 2: Agent builders using unqualified DIDs MUST no longer use new unqualified DIDs, and MUST use DID Rotation to rotate to a fully qualified DID.</li> <li>Each agent builder SHOULD notify the community they have completed Step 2 by submitting a PR to update their entry in the implementations accordingly.</li> <li>Target Date for finishing step 2: 2024-11-01</li> <li>Step 3: Agent builders SHOULD update their deployments to remove all support for receiving unqualified DIDs from other agents.</li> </ul> <p>The community coordination triggers between the steps above will be as follows:</p> <ul> <li>Pre-work to Step 1 - a PR to this RFC is merged that sets the RFC status to ACCEPTED.</li> <li>The ACCEPTED version of this RFC is included in the current Aries Interop Profile version.</li> <li>Step 1 to Step 2 - the community agrees that the majority of the deployed agents have completed Step 1. A PR to this RFC is merged that sets the RFC status to ADOPTED.</li> <li>Agent builders indicate completion of Step 1 by updating the Implementations section of this RFC.</li> <li>All other RFCs in this repo are updated to use the new message type format.</li> <li>The ADOPTED version of this RFC is included in the current Aries Interop Profile version.</li> <li>Step 2 to Step 3 - the community agrees that the majority of the deployed agents have completed Step 2. A PR to this RFC is merged that sets the RFC status to RETIRED.</li> <li>Agent builders indicate completion of Step 2 by updating the Implementations section of this RFC.</li> </ul>"},{"location":"features/0793-unqualfied-dids-transition/#motivation","title":"Motivation","text":"<p>To enable agent builders to independently update their code bases and deployed agents while maintaining interoperability.</p>"},{"location":"features/0793-unqualfied-dids-transition/#tutorial","title":"Tutorial","text":"<p>The general mechanism for this type of transition is documented in RFC 0345 about community-coordinated updates.</p> <p>The specific sequence of events to make this particular transition is outlined in the summary section of this RFC.</p>"},{"location":"features/0793-unqualfied-dids-transition/#reference","title":"Reference","text":"<p>See the summary section of this RFC for the details of this transition.</p>"},{"location":"features/0793-unqualfied-dids-transition/#drawbacks","title":"Drawbacks","text":"<p>None identified.</p>"},{"location":"features/0793-unqualfied-dids-transition/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>This approach balances the speed of adoption with the need for independent deployment and interoperability.</p>"},{"location":"features/0793-unqualfied-dids-transition/#prior-art","title":"Prior art","text":"<p>The approach outlined in RFC 0345 about community-coordinated updates is a well-known pattern for using deprecation to make breaking changes in an ecosystem. That said, this is the first attempt to use this approach in Aries. Adjustments to the transition plan will be made as needed, and RFC 0345 will be updated based on lessons learned in executing this plan.</p>"},{"location":"features/0793-unqualfied-dids-transition/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Are any changes to existing RFCs needed before starting Step 1?</li> </ul>"},{"location":"features/0793-unqualfied-dids-transition/#implementations","title":"Implementations","text":"<p>The following table lists the status of various agent code bases and deployments with respect to the steps of this transition. Agent builders MUST update this table as they complete steps of the transition.</p> Name / Link Implementation Notes Aries Protocol Test Suite No steps completed Aries Framework - .NET No steps completed Trinsic.id No steps completed Aries Cloud Agent - Python No steps completed Aries Static Agent - Python No steps completed Aries Framework - Go No steps completed Connect.Me No steps completed Verity No steps completed Pico Labs No steps completed IBM No steps completed IBM Agent No steps completed Aries Cloud Agent - Pico No steps completed Aries Framework JavaScript No steps completed"},{"location":"features/0794-did-rotate/","title":"Aries RFC 0794: DID Rotate 1.0","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: ACCEPTED</li> <li>Since: 2024-03-02</li> <li>Status Note: Implemented in the Aries Cloud Agent Python</li> <li>Start Date: 2023-08-18 </li> <li>Tags: feature, protocol</li> <li>URI: https://didcomm.org/did-rotate/1.0</li> </ul>"},{"location":"features/0794-did-rotate/#summary","title":"Summary","text":"<p>This protocol signals the change of DID in use between parties.</p> <p>This protocol is only applicable to DIDComm v1 - in DIDComm v2 use the more efficient DID Rotation header.</p>"},{"location":"features/0794-did-rotate/#motivation","title":"Motivation","text":"<p>This mechanism allows a party in a relationship to change the DID they use to identify themselves in that relationship. This may be used to switch DID methods, but also to switch to a new DID within the same DID method. For non-updatable DID methods, this allows updating DID Doc attributes such as service endpoints. Inspired by (but different from) the DID rotation feature of the DIDComm Messaging (DIDComm v2) spec.</p>"},{"location":"features/0794-did-rotate/#implications-for-software-implementations","title":"Implications for Software Implementations","text":"<p>Implementations will need to consider how data (public keys, DIDs and the ID for the relationship) related to the relationship is managed. If the relationship DIDs are used as identifiers, those identifiers may need to be updated during the rotation to maintain data integrity. For example, both parties might have to retain and be able to use as identifiers for the relationship the existing DID and the rotated to DID, and their related keys for a period of time until the rotation is complete.</p>"},{"location":"features/0794-did-rotate/#tutorial","title":"Tutorial","text":""},{"location":"features/0794-did-rotate/#name-and-version","title":"Name and Version","text":"<p>DID Rotate 1.0</p> <p>URI: https://didcomm.org/did-rotate/1.0/"},{"location":"features/0794-did-rotate/#roles","title":"Roles","text":"<p>rotating_party: this party is rotating the DID in use for this relationship. They send the <code>rotate</code> message.</p> <p>observing_party: this party is notified of the DID rotation</p>"},{"location":"features/0794-did-rotate/#messages","title":"Messages","text":""},{"location":"features/0794-did-rotate/#rotate","title":"Rotate","text":"<p>Message Type URI: https://didcomm.org/did-rotate/1.0/rotate</p> <p><code>to_did</code>: The new DID to be used to identify the rotating_party</p> <pre><code>{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/did-rotate/1.0/rotate\",\n    \"to_did\": \"did:example:newdid\",\n\n}\n</code></pre> <p>The rotating_party is expected to receive messages on both the existing and new DIDs and their associated keys for a reasonable period that MUST extend at least until the following <code>ack</code> message has been received.</p> <p>This message MUST be sent using AuthCrypt or as a signed message in order to establish the provenance of the new DID. In Aries implementations, messages sent within the context of a relationship are by default sent using AuthCrypt. Proper provenance prevents injection attacks that seek to take over a relationship. Any rotate message received without being authcrypted or signed MUST be discarded and not processed.</p> <p>DIDComm v1 uses public keys as the outer message identifiers. This means that rotation to a new DID using the same public key will not result in a change for new inbound messages. The observing_party must not assume that the new DID uses the same keys as the existing relationship.</p>"},{"location":"features/0794-did-rotate/#ack","title":"Ack","text":"<p>Message Type URI: https://didcomm.org/did-rotate/1.0/ack</p> <p>This message has been adopted from [the <code>ack</code> protocol] (https://github.com/hyperledger/aries-rfcs/tree/main../../features/0015-acks).</p> <p>This message is still sent to the prior DID to acknowledge the receipt of the rotation. Following messages will be sent to the new DID.</p> <p>In order to correctly process out of order messages, the The observing_party may choose to receive messages from the old DID for a reasonable period. This allows messages sent before rotation but received after rotation in the case of out of order message delivery.</p> <p>In this message, the <code>thid</code> (Thread ID) MUST be included to allow the <code>rotating_party</code> to correlate it with the sent <code>rotate</code> message.</p> <pre><code>{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/did-rotate/1.0/ack\",\n      \"~thread\"          : {\n        \"thid\": \"&lt;id of rotate message&gt;\"\n    },\n\n}\n</code></pre>"},{"location":"features/0794-did-rotate/#problem-report","title":"Problem Report","text":"<p>Message Type URI: https://didcomm.org/did-rotate/1.0/problem-report</p> <p>This message has been adopted from [the <code>report-problem</code> protocol] (https://github.com/hyperledger/aries-rfcs/blob/main../../features/0035-report-problem/README.md).</p> <p>If the observing_party receives a <code>rotate</code> message with a DID that they cannot resolve, they MUST return a problem-report message.</p> <p>The <code>description</code> <code>code</code> must be set to one of the following: - e.did.unresolvable - used for a DID who's method is supported, but will not resolve - e.did.method_unsupported - used for a DID method for which the <code>observing_party</code> does not support resolution. - e.did.doc_unsupported - used for a DID for which the <code>observing_party</code> does not find information sufficient for a DIDComm connection in the resolved DID Document. This would include compatible key types and a DIDComm capable service endpoint.</p> <p>Upon receiving this message, the <code>rotating_party</code> must not complete the rotation and resolve the issue. Further rotation attempts must happen in a new thread.</p> <pre><code>{\n  \"@type\"            : \"https://didcomm.org/did-rotate/1.0/problem-report\",\n  \"@id\"              : \"an identifier that can be used to discuss this error message\",\n  \"~thread\"          : {\n        \"pthid\": \"&lt;id of rotate message&gt;\"\n    },\n  \"description\"      : { \"en\": \"DID Unresolvable\", \"code\": \"e.did.unresolvable\" },\n  \"problem_items\"    : [ {\"did\": \"&lt;did_passed_in_rotate&gt;\"} ],\n}\n</code></pre>"},{"location":"features/0794-did-rotate/#hangup","title":"Hangup","text":"<p>Message Type URI: https://didcomm.org/did-rotate/1.0/hangup</p> <p>This message is sent by the rotating_party to inform the observing_party that they are done with the relationship and will no longer be responding.</p> <p>There is no response message.</p> <p>Use of this message does not require or indicate that all data has been deleted by either party, just that interaction has ceased.</p> <pre><code>{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/did-rotate/1.0/hangup\"\n}\n</code></pre>"},{"location":"features/0794-did-rotate/#prior-art","title":"Prior art","text":"<p>This protocol is inspired by the rotation feature of DIDComm Messaging (DIDComm v2). The implementation differs in important ways. The DIDComm v2 method is a post rotate operation: the first message sent AFTER the rotation contains the prior DID and a signature authorizing the rotation. This is efficient, but requires the use of a message header and a higher level of integration with message processing. This protocol is a pre rotate operation: notifying the other party of the new DID in advance is a less efficient but simpler approach. This was done to minimize adoption pain. The pending move to DIDComm v2 will provide the efficiency.</p>"},{"location":"features/0794-did-rotate/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0804-didcomm-rpc/","title":"0804: DIDComm Remote Procedure Call (DRPC)","text":"<ul> <li>Authors: Clecio Varjao (BC Gov), Stephen Curran (BC Gov), Akiff Manji (BC Gov)</li> <li>Status: DEMONSTRATED</li> <li>Since: 2024-03-02</li> <li>Status Note: Implemented in an Aries Cloud Agent Python plugin, and Credo TS</li> <li>Supersedes:</li> <li>Start Date: 2023-11-29</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0804-didcomm-rpc/#summary","title":"Summary","text":"<p>The DIDComm Remote Procedure Call (DRPC) protocol enables a JSON-RPC-based request-response interaction to be carried out across a DIDComm channel. The protocol is designed to enable custom interactions between connected agents, and to allow for the rapid prototyping of experimental DIDComm protocols. An agent sends a DIDComm message to request a JSON-RPC service be invoked by another agent, and gets back the JSON-RPC-format response in subsequent DIDComm message. The protocol enables any request to be conveyed that the other agent understands. Out of scope of this protocol is how the requesting agent discovers the services available from the responding agent, and how the two agents know the semantics of the specified JSON-RPC requests and responses. By using DIDComm between the requesting and responding agents, the security and privacy benefits of DIDComm are accomplished, and the generic parameters of the requests allow for flexibility in how and where the protocol can be used.</p>"},{"location":"features/0804-didcomm-rpc/#motivation","title":"Motivation","text":"<p>There are several use cases that are driving the initial need for this protocol.</p>"},{"location":"features/0804-didcomm-rpc/#app-attestation","title":"App Attestation","text":"<p>A mobile wallet needs to get an app attestation verifiable credential from the wallet publisher. To do that, the wallet and publisher need to exchange information specific to to the attestation process with the Google and Apple stores. The sequence is as follows:</p> <ul> <li>The wallet decides (for some reason) it needs an App Attestation credential   from its publisher.</li> <li>If not already available, a DIDComm connection between the wallet and the   attestation service is created.</li> <li>The wallet uses the DRPC protocol to request a nonce from the service to be   used in the attestation. The service responds with the nonce.</li> <li>The wallet uses a new instance of the DRPC protocol to request the attestation   be performed. The service responds with the status of the attestation process.</li> <li>The service completes the business process by initiating an Issue Credential   process to issue an attestation verifiable credential.</li> </ul> <p>The wallet and service are using instances of three protocols (two DRPC and one Issue Credential) to carry out a full business process. Each participant must have knowledge of the full business process--there is nothing inherent in the DRPC protocol about this process, or how it is being used. The DRPC protocol is included to provide a generic request-response mechanism that alleviates the need for formalizing special purpose protocols.</p> <p>App attestation is a likely candidate for a having its own DIDComm protocol. This use of DRPC is ideal for developing and experimenting with the necessary agent interactions before deciding on if a use-specific protocol is needed and its semantics.</p>"},{"location":"features/0804-didcomm-rpc/#video-verification-service","title":"Video Verification Service","text":"<p>A second example is using the DRPC protocol is to implement a custom video verification service that is used by a specific mobile wallet implementation and a proprietary backend service prior to issuing a credential to the wallet. Since the interactions are to a proprietary service, so an open specification does not make sense, but the use of DIDComm is valuable. In this example, the wallet communicates over DIDComm to a Credential Issuer agent that (during verification) proxies the requests/responses to a backend (\"behind the firewall\") service. The wallet is implemented to use DRPC protocol instances to initiate the verification and receive the actions needed to carry out the steps of the verification (take picture, take video, instruct movements, etc.), sending to the Issuer agent the necessary data. The Issuer conveys the requests to the verification service and the responses back to the mobile wallet. At the end of the process, the Issuer can see the result of the process, and decide on the next actions between it and the mobile wallet, such as issuing a credential.</p> <p>Again, after using the DRPC protocol for developing and experimenting with the implementation, the creators of the protocol can decide to formalize their own custom, end-to-end protocol, or continue to use the DRPC protocol instances. Important is that they can begin development without doing any Aries frameworks customizations or plugins by using DRPC.</p>"},{"location":"features/0804-didcomm-rpc/#tutorial","title":"Tutorial","text":""},{"location":"features/0804-didcomm-rpc/#name-and-version","title":"Name and Version","text":"<p>This is the DRPC protocol. It is uniquely identified by the URI:</p> <pre><code>\"https://didcomm.org/drpc/1.0\"\n</code></pre>"},{"location":"features/0804-didcomm-rpc/#key-concepts","title":"Key Concepts","text":"<p>This RFC assumes that you are familiar with DID communication.</p> <p>The protocol consists of a DIDComm <code>request</code> message carrying an arbitrary JSON-RPC request to a responding agent, and a second message that carries the result of processing the request back to the client of the first message. The interpretation of the request, how to carry out the request, the content of the response, and the interpretation of the response, are all up to the business logic (controllers) of the participating agents. There is no discovery of remote services offered by agents--it is assumed that the two participants are aware of the DRPC capabilities of one another through some other means. For example, from the App Attestation use case, functionality to carry out the app attestation process, and the service to use it is built into the mobile wallet.</p> <p>Those unfamiliar with JSON-RPC, the <code>&lt;tl;dr&gt;</code> is that it is a very simple request response protocol using JSON where the only data shared is:</p> <ul> <li>a <code>method</code> that defines what needs to be done,</li> <li>some <code>params</code> in JSON that are up to the requester/server to agree on, and</li> <li>an (optional) <code>id</code> to connect the response to the request.</li> </ul> <p>The response is likewise simple:</p> <ul> <li>a <code>result</code> item if the invocation completed successful containing the return results,</li> <li>an <code>error</code> item if the invocation failed, containing details about the failure, and</li> <li>the <code>id</code> from the request.</li> </ul> <p>An example of a simple JSON-RPC request/response pair from the specification is:</p> <pre><code>--&gt; {\"jsonrpc\": \"2.0\", \"method\": \"subtract\", \"params\": [42, 23], \"id\": 1}\n&lt;-- {\"jsonrpc\": \"2.0\", \"result\": 19, \"id\": 1}\n</code></pre> <p>A JSON-RPC request may be a batch of requests, each with a different <code>id</code> value, and the response a similar array, with an entry for each of the requests.</p> <p>JSON-RPC follows a similar \"parameters defined by the message type\" pattern as DIDComm. As a result, in this protocol we do not need to add any special handling around the <code>params</code> such as Base64 encoding, signing, headers and so on, as the parties interacting with the protocol by definition must have a shared understanding of the content of the <code>params</code> and can define any special handling needed amongst themselves.</p> <p>It is expected (although not required) that an Aries Framework receiving a DRPC message will simply pass to its associated \"business logic\" (controller) the request from the client, and wait on the controller to provide the response content to be sent back to the original client. Apart from the messaging processing applied to all inbound and outbound messages, the Aries Framework will not perform any of the actual processing of the request.</p>"},{"location":"features/0804-didcomm-rpc/#roles","title":"Roles","text":"<p>There are two roles, adopted from the JSON-RPC specification, in the protocol <code>client</code> and <code>server</code>:</p> <ul> <li>The <code>client</code> initiates the protocol, sending a request to the <code>server</code>.</li> <li>The <code>server</code> carries out the request however they see fit. The <code>server</code>   may process the request themselves, or might invoke another service to process   the request. The <code>server</code> might be unable or unwilling to carry out the   request.</li> <li>The <code>server</code> returns the response from the request in a message to the <code>client</code>.</li> </ul>"},{"location":"features/0804-didcomm-rpc/#states","title":"States","text":""},{"location":"features/0804-didcomm-rpc/#client-states","title":"Client States","text":"<p>The <code>client</code> agent goes through the following states:</p> <ul> <li>request-sent</li> <li>completed</li> </ul> <p>The state transition table for the <code>client</code> is:</p> State / Events Send Request Receive Response Start Transition to request-sent request-sent Transition to complete completed problem-report received Transition to abandoned abandoned"},{"location":"features/0804-didcomm-rpc/#server-states","title":"Server States","text":"<p>The <code>server</code> agent goes through the following states:</p> <ul> <li>request-received</li> <li>completed</li> </ul> <p>The state transition table for the <code>server</code> is:</p> State / Events Receive Request Send Response or Problem Report Start Transition to request-received request-received Transition to complete completed"},{"location":"features/0804-didcomm-rpc/#messages","title":"Messages","text":"<p>The following are the messages in the DRPC protocol. The <code>response</code> message handles all positive responses, so the <code>ack</code> (RFC 0015 ACKs) message is NOT adopted by this protocol. The RFC 0035 Report Problem is adopted by this protocol in the event that a <code>request</code> is not recognizable as a JSON-RPC message and as such, a JSON-RPC response message cannot be created. See the details below in the Problem Report Message section.</p>"},{"location":"features/0804-didcomm-rpc/#request-message","title":"Request Message","text":"<p>The <code>request</code> message is sent by the <code>client</code> to initiate the protocol. The message contains the JSON-RPC information necessary for the <code>server</code> to process the request, prepare the response, and send the response message back to the <code>client</code>. It is assumed the <code>client</code> knows what types of requests the <code>server</code> is prepared to receive and process. If the <code>server</code> does not know how to process the error, JSON-RPC has a standard response, outlined in the response message section below. How the <code>client</code> and <code>server</code> coordinate that understanding is out of scope of this protocol.</p> <p>The <code>request</code> message uses the same JSON items as JSON-RPC, skipping the <code>id</code> in favor of the existing DIDComm <code>@id</code> and thread handling.</p> <pre><code>  {\n    \"@type\": \"https://didcomm.org/drpc/1.0/request\",\n    \"@id\": \"2a0ec6db-471d-42ed-84ee-f9544db9da4b\",\n    \"request\" : {\"jsonrpc\": \"2.0\", \"method\": \"subtract\", \"params\": [42, 23], \"id\": 1}\n  }\n</code></pre> <p>The items in the message are as follows:</p> <ul> <li><code>@type</code> -- required, must be as above</li> <li><code>@id</code> -- required, must be as defined in [RFC 0005 DIDComm]</li> <li><code>request</code> -- required, an item containing a JSON-RPC request JSON structure.</li> <li><code>request</code> MUST be either a single JSON-RPC request, or an array of JSON-RPC requests.</li> <li>Each JSON-RPC request MUST have the <code>jsonrpc</code> and <code>method</code> items.</li> <li>Each JSON-RPC request MAY have the <code>params</code> and <code>id</code> items.<ul> <li>See the details below about the handling of <code>notification</code> JSON-RPC requests, requests where the <code>id</code> field is omitted.</li> </ul> </li> <li>See the JSON-RPC specification for details about the <code>jsonrpc</code>, <code>method</code>, <code>params</code> and <code>id</code> JSON items.</li> </ul> <p>Per the JSON-RPC specification, if the <code>id</code> field of a JSON-RPC request is omitted, the <code>server</code> should not respond. In this DRPC DIDComm protocol, the <code>server</code> is always expected to send a <code>response</code>, but MUST NOT include a JSON-RPC response for any JSON-RPC request for which the <code>id</code> is omitted. This is covered further in the response message section (below).</p>"},{"location":"features/0804-didcomm-rpc/#response-message","title":"Response Message","text":"<p>A <code>response</code> message is sent by the <code>server</code> to following the processing of the request to convey the output of the processing to the <code>client</code>. As with the <code>request</code> the format mostly exactly that of a JSON-RPC response.</p> <p>If the <code>request</code> is unrecognizable as a JSON-RPC message such that a JSON-RPC message cannot be generated, the <code>server</code> SHOULD send a RFC 0035 Report Problem message to the <code>client</code>.</p> <p>It is assumed the <code>client</code> understands what the contents of the <code>response</code> message means in the context of the protocol instance. How the <code>client</code> and <code>server</code> coordinate that understanding is out of scope of this protocol.</p> <pre><code>  {\n    \"@type\": \"https://didcomm.org/drpc/1.0/response\",\n    \"@id\": \"63d6f6cf-b723-4eaf-874b-ae13f3e3e5c5\",\n    \"response\": {\"jsonrpc\": \"2.0\", \"result\": 19, \"id\": 1}\n  }\n</code></pre> <p>The items in the message are as follows:</p> <ul> <li><code>@type</code> -- required, must be as above</li> <li><code>@id</code> -- required, must be as defined in [RFC 0005 DIDComm]</li> <li><code>response</code> -- required, an item containing a JSON-RPC response JSON structure.</li> <li><code>response</code> MUST be either single (possibly empty) JSON-RPC response,     or an array of JSON-RPC responses.<ul> <li>If all of the JSON-RPC requests in the <code>request</code> message are   notifications (e.g., the <code>id</code> item is omitted), the DIDComm <code>response</code>   message MUST be sent back with the value: <code>\"response\" : {}</code>.</li> </ul> </li> <li>Each JSON-RPC response MUST have the <code>jsonrpc</code> and <code>id</code> items, and either a <code>result</code> or <code>error</code> item.<ul> <li>See the JSON-RPC specification for details about the <code>jsonrpc</code>, <code>id</code>, <code>result</code> and <code>error</code> JSON items.</li> </ul> </li> </ul> <p>As with all DIDComm messages that are not the first in a protocol instance, a <code>~thread</code> decorator MUST be included in the <code>response</code> message.</p> <p>The special handling of the \"all JSON-RPC requests are notifications\" described above is to simplify the DRPC handling to know when a DRPC protocol instance is complete. If a <code>response</code> message is not always required, the DRPC handler would have to inspect the <code>request</code> message to look for <code>id</code>s to determine when the protocol completes.</p> <p>If the <code>server</code> does not understand how to process a given JSON-RPC request, a <code>response</code> error SHOULD be returned (as per the JSON-RPC specification) with:</p> <ul> <li><code>error.code</code> value <code>-32601</code>,</li> <li><code>error.message</code> set to <code>Method not found</code>, and</li> <li>no <code>error.data</code> item.</li> </ul>"},{"location":"features/0804-didcomm-rpc/#problem-report-message","title":"Problem Report Message","text":"<p>A RFC 0035 Report Problem message SHOULD be sent by the <code>server</code> instead of a <code>response</code> message only if the <code>request</code> is unrecognizable as a JSON-RPC message. An JSON-RPC errors MUST be provided to the <code>client</code> by the <code>server</code> via the <code>response</code> message, not a <code>problem-report</code>. The <code>client</code> MUST NOT respond to a <code>response</code> message, even if the <code>response</code> message is not a valid JSON-RPC response.  This is because once the <code>server</code> sends the <code>response</code>, the protocol is in the <code>completed</code> state (from the <code>server</code>'s perspective) and so is subject to deletion. As such, a follow up <code>problem-report</code> message would have an invalid <code>thid</code> (thread ID) and (at best) be thrown away by the <code>server</code>.</p>"},{"location":"features/0804-didcomm-rpc/#constraints","title":"Constraints","text":"<p>The primary constraint with this protocol is that the two parties using the protocol must understand one another--what JSON-RPC request(s) to use, what parameters to provide, how to process the those requests, what the <code>response</code> means, and so on. It is not a protocol to be used between arbitrary parties, but rather one where the parties have knowledge outside of DIDComm of one another and their mutual capabilities.</p> <p>On the other hand, that constraint enables great flexibility for explicitly collaborating agents (such as a mobile wallet and the agent of its manufacturer) to accomplish request-response transactions over DIDComm without needing to define additional DIDComm protocols. More complex interactions can be accomplished by carrying out a sequence of DRPC protocol instances between agents.</p> <p>The flexibility the DRPC protocol allows for experimenting with specific interactions between agents that could later evolve into formal DIDComm \"fit for purpose\" protocols.</p>"},{"location":"features/0804-didcomm-rpc/#reference","title":"Reference","text":""},{"location":"features/0804-didcomm-rpc/#codes-catalog","title":"Codes Catalog","text":"<p>A JSON-RPC request codes catalog could be developed over time and be included in this part of the RFC. This might an intermediate step in transitioning a given interaction implemented using DRPC into formally specified interaction. On the other hand, simply defining a full DIDComm protocol will often be a far better approach.</p> <p>At this time, there are no codes to be cataloged.</p>"},{"location":"features/0804-didcomm-rpc/#drawbacks","title":"Drawbacks","text":"<p>Anything that can be done by using the DRPC protocol can be accomplished by a formally defined protocol specific to the task to be accomplished. The advantage of the DRPC protocol is that pairs of agent instances that are explicitly collaborating can use this protocol without having to first define a task-specific protocol.</p>"},{"location":"features/0804-didcomm-rpc/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>We considered not supporting the notification and batch forms of the JSON-RPC specification, and decided it made sense to allow for the full support of the JSON-RPC specification, including requests of those forms. That said, we also found that the concept of not having a DRPC <code>response</code> message in some (likely, rare) cases based on the contents of the <code>request</code> JSON item (e.g., when all of the <code>id</code>s are omitted from the JSON-RPC requests) would unnecessarily complicate the DIDComm protocol instance handling about when it is complete. As a result, a DRPC <code>response</code> message is always required.</p> <p>This design builds on the experience of implementations of this kind of feature using RFC 0095 Basic Message and RFC 0335 HTTP Over DIDComm. This design tries to build off the learnings gained from both of those implementations.</p> <p>Based on feedback to an original version of the RFC, we looked as well at using gRPC as the core of this protocol, versus JSON-RPC. Our assessment was that gRPC was a much heavier weight mechanism that required more effort between parties to define and implement what will often be a very simple request-response transaction -- at the level of defining a DIDComm protocol.</p> <p>The use of <code>params</code> and leaving the content and semantics of the params up to the <code>client</code> and <code>server</code> means that they can define the appropriate handling of the parameters. This eliminates the need for the protocol to define, for example, that some data needs to be Base64 encoding for transmission, or if some values need to be cryptographically signed. Such details are left to the participants and how they are using the protocol.</p>"},{"location":"features/0804-didcomm-rpc/#prior-art","title":"Prior art","text":"<p>This protocol has similar goals to the RFC 0335 HTTP Over DIDComm protocol, but takes a lighter weight, more flexible approach. We expect that implementing HTTP over DIDComm using this protocol will be as easy as using RFC 0335 HTTP Over DIDComm, where the JSON-RPC request's <code>params</code> data structure holds the <code>headers</code> and <code>body</code> elements for the HTTP request. On the other hand, using the explicit RFC 0335 HTTP Over DIDComm is might be a better choice if it is available and exactly what is needed.</p> <p>One of the example use cases for this protocol has been implemented by \"hijacking\" the RFC 0095 Basic Message protocol to carry out the needed request/response actions. This approach is less than ideal in that:</p> <ul> <li>That is not the intended use of RFC 0095 Basic Message, which is to send a   basic, human consumable message to the other agent.</li> <li>The request method and parameters have to be encoded into the basic message.</li> <li>The RFC 0095 Basic Message protocol is a single message protocols, so each   request-response interaction requires two instances of the protocol, and for   the controllers to manage connecting the interactions together.</li> </ul>"},{"location":"features/0804-didcomm-rpc/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Should we include the idea of a <code>request</code> having a goal code (RFC 0519 Goal Codes)?</li> </ul>"},{"location":"features/0804-didcomm-rpc/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0809-w3c-data-integrity-credential-attachment/","title":"Aries RFC 0809: W3C Verifiable Credential Data Integrity Attachment format for requesting and issuing credentials","text":"<ul> <li>Authors: Timo Glastra (Animo Solutions)</li> <li>Status: DEMONSTRATED</li> <li>Since: 2024-01-10</li> <li>Status Note: Implemented in Aries Cloud Agent Python and Credo</li> <li>Supersedes: Aries RFC 0593: JSON-LD Credential Attachment</li> <li>Start Date: 2023-12-18</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#summary","title":"Summary","text":"<p>This RFC registers an attachment format for use in the issue-credential V2 protocol based on W3C Verifiable Credentials with Data Integrity Proofs from the VC Data Model.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#motivation","title":"Motivation","text":"<p>The Issue Credential protocol needs an attachment format to be able to exchange W3C verifiable credentials. It is desirable to make use of specifications developed in an open standards body, such as the Credential Manifest for which the attachment format is described in RFC 0511: Credential-Manifest Attachment format. However, the Credential Manifest is not finished and ready yet, and therefore there is a need to bridge the gap between standards.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#tutorial","title":"Tutorial","text":"<p>Complete examples of messages are provided in the reference section.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#reference","title":"Reference","text":""},{"location":"features/0809-w3c-data-integrity-credential-attachment/#credential-offer-attachment-format","title":"Credential Offer Attachment Format","text":"<p>Format identifier: <code>didcomm/w3c-di-vc-offer@v0.1</code></p> <pre><code>{\n  \"data_model_versions_supported\": [\"1.1\", \"2.0\"],\n  \"binding_required\": true,\n  \"binding_method\": {\n    \"anoncreds_link_secret\": {\n      \"nonce\": \"1234\",\n      \"cred_def_id\": \"did:key:z6MkwXG2WjeQnNxSoynSGYU8V9j3QzP3JSqhdmkHc6SaVWoT/credential-definition\",\n      \"key_correctness_proof\": \"&lt;key_correctness_proof&gt;\"\n    },\n    \"didcomm_signed_attachment\": {\n      \"algs_supported\": [\"EdDSA\"],\n      \"did_methods_supported\": [\"key\", \"web\"],\n      \"nonce\": \"1234\"\n    }\n  },\n  \"credential\": {\n    \"@context\": [\n      \"https://www.w3.org/2018/credentials/v1\",\n      \"https://w3id.org/security/data-integrity/v2\",\n      {\n        \"@vocab\": \"https://www.w3.org/ns/credentials/issuer-dependent#\"\n      }\n    ],\n    \"type\": [\"VerifiableCredential\"],\n    \"issuer\": \"did:key:z6MkwXG2WjeQnNxSoynSGYU8V9j3QzP3JSqhdmkHc6SaVWoT\",\n    \"issuanceDate\": \"2024-01-10T04:44:29.563418Z\",\n    \"credentialSubject\": {\n      \"height\": 175,\n      \"age\": 28,\n      \"name\": \"Alex\",\n      \"sex\": \"male\"\n    }\n  }\n}\n</code></pre> <ul> <li><code>data_model_versions_supported</code> - Required. List of strings indicating the supported VC Data Model versions. The list MUST contain at least one value. The values MUST be a valid data model version. Current supported values include <code>1.1</code> and <code>2.0</code>.</li> <li><code>binding_required</code> - Optional. Boolean indicating whether the credential MUST be bound to the holder. If omitted, the credential is not required to be bound to the holder. If set to <code>true</code>, the credential MUST be bound to the holder using at least one of the binding methods defined in <code>binding_method</code>.</li> <li><code>binding_method</code> - Required if <code>binding_required</code> is true. Object containing key-value pairs of binding methods supported by the issuer to bind the credential to a holder. If the value is omitted, this indicates the issuer does not support any binding methods for issuance of the credential. See Binding Methods for a registry of default binding methods supported as part of this RFC.</li> <li><code>credential</code> - Required. The credential to be issued. The credential MUST be compliant with the first <code>data_model_versions_supported</code> entry version of VC Data Model, except for the omission of a set required keys that may only be known at the time of issuance. See Credential Offer Exceptions for a list of exceptions. The credential MUST NOT contain any proofs. Some properties MAY be omitted if they will only be available at time of issuance, such as <code>issuanceDate</code>, <code>issuer</code>, <code>credentialSubject.id</code>, <code>credentialStatus</code>, <code>credentialStatus.id</code>.</li> </ul>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#credential-offer-exceptions","title":"Credential Offer Exceptions","text":"<p>To allow for validation of the <code>credential</code> according to the corresponding VC Data Model version, the <code>credential</code> in the offer MUST be conformant to the corresponding VC Data Model version, except for the exceptions listed below. This still allows the credential to be validated, knowing which deviations are possible.</p> <p>The list of exception is as follows:</p> <ul> <li><code>issuanceDate</code> (v1.1) or <code>validFrom</code> (v2.0) can be omitted, or set to a placeholder value.</li> <li><code>issuer</code> (or <code>issuer.id</code> if issuer is an object) can be omitted</li> <li><code>credentialSubject.id</code> can be omitted</li> <li><code>credentialStatus</code></li> <li>Either the whole <code>credentialStatus</code> can be omitted</li> <li>OR the <code>credentialStatus.type</code> can be present, but other required fields that are dynamic can be omitted (such as the <code>statusListIndex</code> and <code>statusListCredential</code> in case of Bitstring Status List)</li> </ul>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#credential-request-attachment-format","title":"Credential Request Attachment Format","text":"<p>Format identifier: <code>didcomm/w3c-di-vc-request@v0.1</code></p> <p>This format is used to request a verifiable credential. The JSON structure might look like this:</p> <pre><code>{\n  \"data_model_version\": \"2.0\",\n  \"binding_proof\": {\n    \"anoncreds_link_secret\": {\n      \"entropy\": \"&lt;random-entropy&gt;\",\n      \"cred_def_id\": \"did:key:z6MkwXG2WjeQnNxSoynSGYU8V9j3QzP3JSqhdmkHc6SaVWoT/credential-definition\",\n      \"blinded_ms\": {},\n      \"blinded_ms_corectness_proof\": {},\n      \"nonce\": \"&lt;random-nonce&gt;\"\n    },\n    \"didcomm_signed_attachment\": {\n      \"attachment_id\": \"&lt;@id of the attachment&gt;\"\n    }\n  }\n}\n</code></pre> <ul> <li><code>data_model_version</code> - Required. The data model version of the credential to be issued. The value MUST be a valid data model version and match one of the values from the <code>data_model_versions_supported</code> offer.</li> <li><code>binding_proof</code> - Required if <code>binding_required</code> is <code>true</code> in the offer. Object containing key-value pairs of proofs for the binding to the holder. The keys MUST match keys of the <code>binding_method</code> object from the offer. See Binding Methods for a registry of default binding methods supported as part of this RFC.</li> </ul>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#credential-attachment-format","title":"Credential Attachment Format","text":"<p>Format identifier: <code>didcomm/w3c-di-vc@v0.1</code></p> <p>This format is used to transmit a verifiable credential. The JSON structure might look like this:</p> <pre><code>{\n  \"credential\": {\n    // vc with proof object or array\n  }\n}\n</code></pre> <ul> <li><code>credential</code> - The signed credential. MUST be a valid verifiable credential object with one or more proofs and MUST conform to VC Data Model version as defined in the <code>data_model_version</code> of the request.</li> </ul> <p>It is up to the issuer to the pick an appropriate cryptographic suite to sign the credential. The issuer may use the cryptographic binding material provided by the holder to select the cryptographic suite. For example, when the <code>anoncreds_link_secret</code> binding method is used, the issuer should use an <code>DataIntegrityProof</code> with the <code>anoncredsvc-2023</code> cryptographic suite. When a holder provides a signed attachment as part of the binding proof using the <code>EdDSA</code> JWA alg, the issuer could use a <code>DateIntegrityProof</code> with the <code>eddsa-rdfc-2022</code> cryptographic suite. However, it is not required for the cryptographic suite used for the signature on the credential to be in any way related to the cryptographic suite used for the binding proof, unless the binding method explicitly requires this (for example the <code>anoncreds_link_secret</code> binding method).</p> <p>A complete <code>issue-credential</code> message from the Issue Credential protocol 2.0 might look like this:</p> <pre><code>{\n  \"@id\": \"284d3996-ba85-45d9-964b-9fd5805517b6\",\n  \"@type\": \"https://didcomm.org/issue-credential/2.0/issue-credential\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"5b38af88-d36f-4f77-bb7a-2f04ab806eb8\",\n      \"format\": \"didcomm/w3c-di-vc@v0.1\"\n    }\n  ],\n  \"credentials~attach\": [\n    {\n      \"@id\": \"5b38af88-d36f-4f77-bb7a-2f04ab806eb8\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"ewogICAgICAgICAgIkBjb250ZXogWwogICAgICAg...(clipped)...RNVmR0SXFXZhWXgySkJBIgAgfQogICAgICAgIH0=\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#binding-methods","title":"Binding Methods","text":"<p>The attachment format supports different methods to bind the credential to the receiver of the credential. In the offer message the issuer can indicate which binding methods are supported in the <code>binding_methods</code> object. Each key represents the id of the supported binding method.</p> <p>This section defines a set of binding methods supported by this attachment format, but other binding methods may be used. Based on the binding method, the request needs to include a <code>binding_proof</code> object where the key matches the key of the binding method from the offer.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#anoncreds-link-secret","title":"AnonCreds Link Secret","text":"<p>Identifier: <code>anoncreds_link_secret</code></p> <p>This binding method is intended to be used in combination with a credential containing an AnonCreds proof.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#binding-method-in-offer","title":"Binding Method in Offer","text":"<p>The structure of the binding method in the offer MUST match the structure of the Credential Offer as defiend in the AonCreds specification, with the exclusion of the <code>schema_id</code> key.</p> <pre><code>{\n  \"nonce\": \"1234\",\n  \"cred_def_id\": \"did:key:z6MkwXG2WjeQnNxSoynSGYU8V9j3QzP3JSqhdmkHc6SaVWoT/credential-definition\",\n  \"key_correctness_proof\": {\n    /* key correctness proof object */\n  }\n}\n</code></pre>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#binding-proof-in-request","title":"Binding Proof in Request","text":"<p>The structure of the binding proof in the request MUST match the structure of the Credential Request as defined in the AnonCreds specification.</p> <pre><code>{\n  \"anoncreds_link_secret\": {\n    \"entropy\": \"&lt;random-entropy&gt;\",\n    \"blinded_ms\": {\n      /* blinded ms object */\n    },\n    \"blinded_ms_corectness_proof\": {\n      /* blinded ms correctness proof object */\n    },\n    \"nonce\": \"&lt;random-nonce&gt;\"\n  }\n}\n</code></pre>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#binding-in-credential","title":"Binding in Credential","text":"<p>The issued credential should be bound to the holder by including the blinded link secret in the credential as defined in the Issue Credential section of the AnonCreds specification. Credential bound using the AnonCreds link secret binding method MUST contain an proof with <code>proof.type</code> value of <code>DataIntegrityProof</code> and <code>cryptosuite</code> value of <code>anoncredsvc-2023</code>, and conform to the AnonCreds W3C Verifiable Credential Representation.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#didcomm-signed-attachment","title":"DIDComm Signed Attachment","text":"<p>Identifier: <code>didcomm_signed_attachment</code></p> <p>This binding method leverages DIDComm signed attachments to bind a credential to a specific key and/or identifier.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#binding-method-in-offer_1","title":"Binding Method in Offer","text":"<pre><code>{\n  \"didcomm_signed_attachment\": {\n    \"algs_supported\": [\"EdDSA\"],\n    \"did_methods_supported\": [\"key\"],\n    \"nonce\": \"b19439b0-4dc9-4c28-b796-99d17034fb5c\"\n  }\n}\n</code></pre> <ul> <li><code>algs_supported</code> - Required. List of strings indicating the Json Web Algorithms supported by the issuer for verifying the signed attachment. The list MUST contain at least one value. The values MUST be a valid algorithm identifier as defined in the JSON Web Signature and Encryption Algorithms registry.</li> <li><code>did_methods_supported</code> - Required. List of strings indicating which did methods are supported by the issuer for binding the credential to the holder. The list MUST contain at least one value. Values should ONLY include the method identifier of the did method. Examples values include <code>key</code> or <code>web</code>.</li> <li><code>nonce</code> - Required. Nonce to be used in the request to prevent replay attacks of the signed attachment.</li> </ul>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#binding-proof-in-request_1","title":"Binding Proof in Request","text":"<p>The binding proof in the request points to an appended attachment containing the signed attachment.</p> <pre><code>{\n  \"didcomm_signed_attachment\": {\n    \"attachment_id\": \"&lt;@id of the attachment&gt;\"\n  }\n}\n</code></pre> <ul> <li><code>attachment_id</code> - The id of the appended attachment included in the request message that contains the signed attachment.</li> </ul>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#signed-attachment-content","title":"Signed Attachment Content","text":"<p>The attachment MUST be signed by including a signature in the <code>jws</code> field of the attachment. The data MUST be a JSON document encoded in the <code>base64</code> field of the attachment. The structure of the signed attachment is described below.</p> <p>JWS Payload</p> <pre><code>{\n  \"nonce\": \"&lt;request_nonce&gt;\",\n}\n</code></pre> <ul> <li><code>nonce</code> - Required. The <code>nonce</code> from the <code>didcomm_signed_attachment</code> object within <code>binding_method</code> from the credential offer</li> </ul> <p>Protected Header</p> <pre><code>{\n  \"alg\": \"EdDSA\",\n  \"kid\": \"did:key:z6MkkwiqX7BvkBbi37aNx2vJkCEYSKgHd2Jcgh4AUhi4YY1u#z6MkkwiqX7BvkBbi37aNx2vJkCEYSKgHd2Jcgh4AUhi4YY1u\"\n}\n</code></pre> <ul> <li><code>alg</code>: REQUIRED. A digital signature algorithm identifier such as per IANA \"JSON Web Signature and Encryption Algorithms\" registry. MUST NOT be none or an identifier for a symmetric algorithm (MAC). MUST match one of the <code>algs_supported</code> entries from the offer <code>binding_method</code> object.</li> <li><code>kid</code>: REQUIRED. JOSE Header containing the DID URL pointing to a specific key in a did document. The did method of the DID URL MUST match with one of the <code>did_methods_supported</code> from the offer <code>binding_method</code> object.</li> </ul> <p>A signed binding request attachment appended to a request message might look like this:</p> <pre><code>{\n  \"@id\": \"284d3996-ba85-45d9-964b-9fd5805517b6\",\n  \"@type\": \"https://didcomm.org/issue-credential/2.0/request-credential\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"5b38af88-d36f-4f77-bb7a-2f04ab806eb8\",\n      \"format\": \"didcomm/w3c-di-vc-request@v0.1\"\n    }\n  ],\n  \"~attach\": [\n    {\n      \"@id\": \"123\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"&lt;base64-encoded-json-attachment-content&gt;\",\n        \"jws\": {\n          \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n          \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n        }\n      }\n    }\n  ],\n  \"credentials~attach\": [\n    {\n      \"@id\": \"5b38af88-d36f-4f77-bb7a-2f04ab806eb8\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"ewogICAgICAgICAgIkBjb250ZXogWwogICAgICAg...(clipped)...RNVmR0SXFXZhWXgySkJBIgAgfQogICAgICAgIH0=\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#binding-in-credential_1","title":"Binding in Credential","text":"<p>The issued credential should be bound to the holder by including the did in the credential as <code>credentialSubject.id</code> or <code>holder</code>.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#drawbacks","title":"Drawbacks","text":"<ul> <li>While it has a similar setup and structure compared to OpenID for Verifiable Credential Issuance, this attachment format only focuses on issuance of W3C Verifiable Credentials. Therefore another (but probably quite similar) attachment format needs to be defined to support issuance of non-W3C VCs</li> <li>There is currently no way for an issuer or holder to indicate which cryptographic suites they support for the signature of the credential. Currently it's at the discretion of the issuer to decide which cryptographic suite to use. In a future (minor) version we can add an optional way for a) the issuer to indicate which cryptographic suites they support, and b) the holder to indicate which cryptographic suites they support.</li> <li>There is currently no attachment format defined for a credential proposal. This makes it impossible for a holder to initiate the issuance of a credential using this attachment format. In a future (minor) version the proposal attachment format can be added.</li> </ul>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>RFC 0593: JSON-LD Credential Attachment, W3C VC API allows issuance of credentials using only linked data signatures, while RFC 0592: Indy Attachment supports issuance of AnonCreds credentials. This attachment format aims to support issuance of both previous attachment formats (while for AnonCreds it now being in the W3C model), as well as supporting additional ../../features such as issuance W3C JWT VCs, credentials with multiple proofs, and cryptographic binding of the credential to the holder.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#prior-art","title":"Prior art","text":"<p>The attachment format in this RFC is heavily inspired by RFC 0593: JSON-LD Credential Attachment, W3C VC API and OpenID for Verifiable Credential Issuance.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#unresolved-questions","title":"Unresolved questions","text":""}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Welcome","text":"<p>This repo holds Request for Comment (RFCs) for the Aries project. They describe important topics (not minor details) that we want to standardize across the Aries ecosystem.</p> <p>If you are here to learn about Aries, we recommend you use the the RFC Index for a current listing of all RFCs and their statuses.</p> <p>There are 2 types of Aries RFCs:</p> <ul> <li>RFCs that describe individual features (in the <code>./features</code> folder)</li> <li>RFCs that explain concepts underpinning many features (in the <code>./concepts</code> folder)</li> </ul> <p>RFCs are for developers building on Aries. They don't provide guidance on how Aries components implement features internally; individual Aries repos have design docs for that. Each Aries RFC includes an \"implementations\" section and all RFCs with a status greater than <code>Proposed</code> should have at least one listed implementation.</p>"},{"location":"#rfc-lifecycle","title":"RFC Lifecycle","text":"<p>RFCs go through a standard lifecycle.</p> <p></p>"},{"location":"#proposed","title":"PROPOSED","text":"<p>To propose an RFC, use these instructions to raise a PR against the repo. Proposed RFCs are considered a \"work in progress\", even after they are merged. In other words, they haven't been endorsed by the community yet, but they seem like reasonable ideas worth exploring.</p>"},{"location":"#demonstrated","title":"DEMONSTRATED","text":"<p>Demonstrated RFCs have one or more implementations available, listed in the \"Implementations\" section of the RFC document. As with the PROPOSED status, demonstrated RFCs haven't been endorsed by the community, but the ideas put forth have been more thoroughly explored through the implementation(s). The demonstrated status is an optional step in the lifecycle. For protocol-related RFCs, work on protocol tests SHOULD begin in the test suite repo by the time this status is assigned.</p>"},{"location":"#accepted","title":"ACCEPTED","text":"<p>To get an RFC accepted, build consensus for your RFC on chat and in community meetings. If your RFC is a feature that's protocol- or decorator-related, it MUST have reasonable tests in the test suite repo, it MUST list the test suite in the protocol RFC's Implementations section, at least one other implementation must have passed the relevant portions of the test suite, and all implementations listed in this section of the RFC MUST hyperlink to their test results. An accepted RFC is incubating on a standards track; the community has decided to polish it and is exploring or pursuing implementation.</p>"},{"location":"#adopted","title":"ADOPTED","text":"<p>To get an RFC adopted, socialize and implement. An RFC gets this status once it has significant momentum--when implementations accumulate, or when the mental model it advocates has begun to permeate our discourse. In other words, adoption is acknowledgment of a de facto standard.</p> <p>To refine an RFC, propose changes to it through additional PRs. Typically these changes are driven by experience that accumulates during or after adoption. Minor refinements that just improve clarity can happen inline with lightweight review. Status is still ADOPTED.</p>"},{"location":"#stalled","title":"STALLED","text":"<p>An RFC is stalled when a proposed RFC makes no progress towards implementation such that it is extremely unlikely it will ever move forward. The stalled state differs from retired in that it is an RFC that has never been implemented or superseded. Like the retired state, it is (likely) an end state and the RFC will not proceed further. Such an RFC remains in the repository on the off chance it will ring a chord with others, be returned to the proposed state, and continue to evolve.</p>"},{"location":"#retired","title":"RETIRED","text":"<p>An RFC is retired when it is withdrawn from community consideration by its authors, when implementation seems permanently stalled, or when significant refinements require a superseding document. If a retired RFC has been superseded, its <code>Superseded By</code> field should contain a link to the newer spec, and the newer spec's <code>Supersedes</code> field should contain a link to the older spec. Permalinks are not broken.</p>"},{"location":"#changing-an-rfc-status","title":"Changing an RFC Status","text":"<p>See notes about this in Contributing.</p>"},{"location":"#about","title":"About","text":""},{"location":"#license","title":"License","text":"<p>This repository is licensed under an Apache 2 License. It is protected by a Developer Certificate of Origin on every commit. This means that any contributions you make must be licensed in an Apache-2-compatible way, and must be free from patent encumbrances or additional terms and conditions. By raising a PR, you certify that this is the case for your contribution.</p> <p>For more instructions about contributing, see Contributing.</p>"},{"location":"#acknowledgement","title":"Acknowledgement","text":"<p>The structure and a lot of the initial language of this repository was borrowed from Indy HIPEs, which borrowed it from Rust RFC. Their good work has made the setup of this repository much quicker and better than it otherwise would have been. If you are not familiar with the Rust community, you should check them out.</p>"},{"location":"0000-template-protocol/","title":"Aries RFC 0000: Your Protocol 0.9","text":"<ul> <li>Authors: your name -- email is optional</li> <li>Status: PROPOSED</li> <li>Since: 2019-12-26 (date you submit your PR)</li> <li>Status Note: (explanation of current status)  </li> <li>Supersedes: (link to anything this RFC supersedes)</li> <li>Start Date: 2018-12-26 (date you started working on this idea)</li> <li>Tags: feature, protocol</li> <li>URI: https://didcomm.org/your_protocol_name/%VER</li> </ul>"},{"location":"0000-template-protocol/#summary","title":"Summary","text":"<p>One paragraph explanation of the feature.</p> <p>If the RFC you are proposing is NOT a protocol, please use this template as a starting point.</p> <p>When completing this template and before submitting as a PR, please remove the template text in sections (other than Implementations). The implementations section should remain as is.</p>"},{"location":"0000-template-protocol/#motivation","title":"Motivation","text":"<p>Why are we doing this? What use cases does it support? What is the expected outcome?</p>"},{"location":"0000-template-protocol/#tutorial","title":"Tutorial","text":""},{"location":"0000-template-protocol/#name-and-version","title":"Name and Version","text":"<p>Name and Version</p> <p>Specify the official name of the protocol and its version, e.g., \"My Protocol 0.9\".</p> <p>Protocol names are often either lower_snake_case or kebob-case. The non-version components of the protocol named are matched exactly.</p> <p>URI: <code>https://didcomm.org/lets_do_lunch/&lt;version&gt;/&lt;messageType&gt;</code></p> <p>Message types and protocols are identified with special URIs that match certain conventions. See Message Type and Protocol Identifier URIs for more details.</p> <p>The version of a protocol is declared carefully. See Semver Rules for Protocols for details.</p>"},{"location":"0000-template-protocol/#key-concepts","title":"Key Concepts","text":"<p>This is short--a paragraph or two. It defines terms and describes the flow of the interaction at a very high level. Key preconditions should be noted (e.g., \"You can't issue a credential until you have completed the connection protocol first\"), as well as ways the protocol can start and end, and what can go wrong. The section might also talk about timing constraints and other assumptions. After reading this section, a developer should know what problem your protocol solves, and should have a rough idea of how the protocol works in its simpler variants.</p>"},{"location":"0000-template-protocol/#roles","title":"Roles","text":"<p>See this note for definitions of the terms \"role\", \"participant\", and \"party\".</p> <p>Provides a formal name to each role in the protocol, says who and how many can play each role, and describes constraints associated with those roles (e.g., \"You can only issue a credential if you have a DID on the public ledger\"). The issue of qualification for roles can also be explored (e.g., \"The holder of the credential must be known to the issuer\").</p> <p>The formal names for each role are important because they are used when agents discover one another's capabilities; an agent doesn't just claim that it supports a protocol; it makes a claim about which roles in the protocol it supports. An agent that supports credential issuance and an agent that supports credential holding may have very different features, but they both use the credential-issuance protocol. By convention, role names use lower-kebab-case and are compared case-sensitively.</p>"},{"location":"0000-template-protocol/#states","title":"States","text":"<p>This section lists the possible states that exist for each role. It also enumerates the events (often but not always messages) that can occur, including errors, and what should happen to state as a result. A formal representation of this information is provided in a state machine matrix. It lists events as columns, and states as rows; a cell answers the question, \"If I am in state X (=row), and event Y (=column) occurs, what happens to my state?\" The Tic Tac Toe example is typical.</p> <p>Choreography Diagrams from BPMN are good artifacts here, as are PUML sequence diagrams and UML-style state machine diagrams. The matrix form is nice because it forces an exhaustive analysis of every possible event. The diagram styles are often simpler to create and consume, and the PUML and BPMN forms have the virtue that they can support line-by-line diffs when checked in with source code. However, they don't offer an easy way to see if all possible flows have been considered; what they may NOT describe isn't obvious. This--and the freedom from fancy tools--is why the matrix form is used in many early RFCs. We leave it up to the community to settle on whether it wants to strongly recommend specific diagram types.</p> <p>The formal names for each state are important, as they are used in <code>ack</code>s and <code>problem-report</code>s). For example, a <code>problem-report</code> message declares which state the sender arrived at because of the problem. This helps other participants to react to errors with confidence. Formal state names are also used in the agent test suite, in log messages, and so forth.</p> <p>By convention, state names use lower-kebab-case. They are compared case-sensitively.</p> <p>State management in protocols is a deep topic. For more information, please see State Details and State Machines.</p>"},{"location":"0000-template-protocol/#messages","title":"Messages","text":"<p>This section describes each message in the protocol. It should also note the names and versions of messages from other message families that are adopted by the protocol (e.g., an <code>ack</code> or a <code>problem-report</code>). Typically this section is written as a narrative, showing each message type in the context of an end-to-end sample interaction. All possible fields may not appear; an exhaustive catalog is saved for the \"Reference\" section.</p> <p>Sample messages that are presented in the narrative should also be checked in next to the markdown of the RFC, in DIDComm Plaintext format.</p> <p>The message element of a message type URI are typically lower_camel_case or lower-kebab-case, matching the style of the protocol. JSON items in messages are lower_camel_case and inconsistency in the application of a style within a message is frowned upon by the community.</p>"},{"location":"0000-template-protocol/#adopted-messages","title":"Adopted Messages","text":"<p>Many protocols should use general-purpose messages such as <code>ack</code> and <code>problem-report</code>) at certain points in an interaction. This reuse is strongly encouraged because it helps us avoid defining redundant message types--and the code to handle them--over and over again (see DRY principle).</p> <p>However, using messages with generic values of <code>@type</code> (e.g., <code>\"@type\": \"https://didcomm.org/notification/1.0/ack\"</code>) introduces a challenge for agents as they route messages to their internal routines for handling. We expect internal handlers to be organized around protocols, since a protocol is a discrete unit of business value as well as a unit of testing in our agent test suite. Early work on agents has gravitated towards pluggable, routable protocols as a unit of code encapsulation and dependency as well. Thus the natural routing question inside an agent, when it sees a message, is \"Which protocol handler should I route this message to, based on its @type?\" A generic <code>ack</code> can't be routed this way.</p> <p>Therefore, we allow a protocol to adopt messages into its namespace. This works very much like python's <code>from module import symbol</code> syntax. It changes the <code>@type</code> attribute of the adopted message. Suppose a <code>rendezvous</code> protocol is identified by the URI <code>https://didcomm.org/rendezvous/2.0</code>, and its definition announces that it has adopted generic 1.x <code>ack</code> messages. When such <code>ack</code> messages are sent, the <code>@type</code> should now use the alias defined inside the namespace of the <code>rendezvous</code> protocol:</p> <p></p> <p>Adoption should be declared in an \"Adopted\" subsection of \"Messages\". When adoption is specified, it should include a minimum adopted version of the adopted message type: \"This protocol adopts <code>ack</code> with version &gt;= 1.4\". All versions of the adopted message that share the same major number should be compatible, given the semver rules that apply to protocols.</p>"},{"location":"0000-template-protocol/#constraints","title":"Constraints","text":"<p>Many protocols have constraints that help parties build trust. For example, in buying a house, the protocol includes such things as commission paid to realtors to guarantee their incentives, title insurance, earnest money, and a phase of the process where a home inspection takes place. If you are documenting a protocol that has attributes like these, explain them here. If not, the section can be omitted.</p>"},{"location":"0000-template-protocol/#reference","title":"Reference","text":"<p>All of the sections of reference are optional. If none are needed, the \"Reference\" section can be deleted.</p>"},{"location":"0000-template-protocol/#messages-details","title":"Messages Details","text":"<p>Unless the \"Messages\" section under \"Tutorial\" covered everything that needs to be known about all message fields, this is where the data type, validation rules, and semantics of each field in each message type are details. Enumerating possible values, or providing ABNF or regexes is encouraged. Following conventions such as those for date- and time-related fields can save a lot of time here.</p> <p>Each message type should be associated with one or more roles in the  protocol. That is, it should be clear which roles can send and receive which message types.</p> <p>If the \"Tutorial\" section covers everything about the messages, this section should be deleted.</p>"},{"location":"0000-template-protocol/#examples","title":"Examples","text":"<p>This section is optional. It can be used to show alternate flows through the protocol.</p>"},{"location":"0000-template-protocol/#collateral","title":"Collateral","text":"<p>This section is optional. It could be used to reference files, code, relevant standards, oracles, test suites, or other artifacts that would be useful to an implementer. In general, collateral should be checked in with the RFC.</p>"},{"location":"0000-template-protocol/#localization","title":"Localization","text":"<p>If communication in the protocol involves humans, then localization of message content may be relevant. Default settings for localization of all messages in the protocol can be specified in an <code>l10n.json</code> file described here and checked in with the RFC. See \"Decorators at Message Type Scope\" in the Localization RFC.</p>"},{"location":"0000-template-protocol/#codes-catalog","title":"Codes Catalog","text":"<p>If the protocol has a formally defined catalog of codes (e.g., for errors or for statuses), define them in this section. See \"Message Codes and Catalogs\" in the Localization RFC.</p>"},{"location":"0000-template-protocol/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"0000-template-protocol/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"0000-template-protocol/#prior-art","title":"Prior art","text":"<p>Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:</p> <ul> <li>Does this feature exist in other SSI ecosystems and what experience have their community had?</li> <li>For other teams: What lessons can we learn from other attempts?</li> <li>Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.</li> </ul> <p>This section is intended to encourage you as an author to think about the lessons from other implementers, provide readers of your proposal with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if they are an adaptation from other communities.</p> <p>Note that while precedent set by other communities is some motivation, it does not on its own motivate an enhancement proposal here. Please also take into consideration that Aries sometimes intentionally diverges from common identity features.</p>"},{"location":"0000-template-protocol/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"0000-template-protocol/#implementations","title":"Implementations","text":"<p>NOTE: This section should remain in the RFC as is on first release. Remove this note and leave the rest of the text as is. Template text in all other sections should be removed before submitting your Pull Request.</p> <p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"0000-template/","title":"Title (Ex. 0000: RFC Topic)","text":"<ul> <li>Authors: your name -- email is optional</li> <li>Status: PROPOSED</li> <li>Since: 2019-12-26 (date you submit your PR)</li> <li>Status Note: (explanation of current status)  </li> <li>Supersedes: (link to anything this RFC supersedes)</li> <li>Start Date: 2018-12-26 (date you started working on this idea)</li> <li>Tags: concept</li> </ul>"},{"location":"0000-template/#summary","title":"Summary","text":"<p>One paragraph explanation of the feature.</p> <p>NOTE: If you are creating a protocol RFC, please use this template instead.</p>"},{"location":"0000-template/#motivation","title":"Motivation","text":"<p>Why are we doing this? What use cases does it support? What is the expected outcome?</p>"},{"location":"0000-template/#tutorial","title":"Tutorial","text":"<p>Explain the proposal as if it were already implemented and you were teaching it to another Aries contributor or Aries consumer. That generally means:</p> <ul> <li>Introducing new named concepts.</li> <li>Explaining the feature largely in terms of examples.</li> <li>Explaining how Aries contributors and/or consumers should think about the feature, and how it should impact the way they use the ecosystem.</li> <li>If applicable, provide sample error messages, deprecation warnings, or migration guidance.</li> </ul> <p>Some enhancement proposals may be more aimed at contributors (e.g. for consensus internals); others may be more aimed at consumers.</p>"},{"location":"0000-template/#reference","title":"Reference","text":"<p>Provide guidance for implementers, procedures to inform testing, interface definitions, formal function prototypes, error codes, diagrams, and other technical details that might be looked up. Strive to guarantee that:</p> <ul> <li>Interactions with other features are clear.</li> <li>Implementation trajectory is well defined.</li> <li>Corner cases are dissected by example.</li> </ul>"},{"location":"0000-template/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"0000-template/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"0000-template/#prior-art","title":"Prior art","text":"<p>Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:</p> <ul> <li>Does this feature exist in other SSI ecosystems and what experience have their community had?</li> <li>For other teams: What lessons can we learn from other attempts?</li> <li>Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.</li> </ul> <p>This section is intended to encourage you as an author to think about the lessons from other implementers, provide readers of your proposal with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if they are an adaptation from other communities.</p> <p>Note that while precedent set by other communities is some motivation, it does not on its own motivate an enhancement proposal here. Please also take into consideration that Aries sometimes intentionally diverges from common identity features.</p>"},{"location":"0000-template/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"0000-template/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"LICENSE/","title":"License","text":"<pre><code>                             Apache License\n                       Version 2.0, January 2004\n                    http://www.apache.org/licenses/\n</code></pre> <p>TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION</p> <ol> <li> <p>Definitions.</p> <p>\"License\" shall mean the terms and conditions for use, reproduction,   and distribution as defined by Sections 1 through 9 of this document.</p> <p>\"Licensor\" shall mean the copyright owner or entity authorized by   the copyright owner that is granting the License.</p> <p>\"Legal Entity\" shall mean the union of the acting entity and all   other entities that control, are controlled by, or are under common   control with that entity. For the purposes of this definition,   \"control\" means (i) the power, direct or indirect, to cause the   direction or management of such entity, whether by contract or   otherwise, or (ii) ownership of fifty percent (50%) or more of the   outstanding shares, or (iii) beneficial ownership of such entity.</p> <p>\"You\" (or \"Your\") shall mean an individual or Legal Entity   exercising permissions granted by this License.</p> <p>\"Source\" form shall mean the preferred form for making modifications,   including but not limited to software source code, documentation   source, and configuration files.</p> <p>\"Object\" form shall mean any form resulting from mechanical   transformation or translation of a Source form, including but   not limited to compiled object code, generated documentation,   and conversions to other media types.</p> <p>\"Work\" shall mean the work of authorship, whether in Source or   Object form, made available under the License, as indicated by a   copyright notice that is included in or attached to the work   (an example is provided in the Appendix below).</p> <p>\"Derivative Works\" shall mean any work, whether in Source or Object   form, that is based on (or derived from) the Work and for which the   editorial revisions, annotations, elaborations, or other modifications   represent, as a whole, an original work of authorship. For the purposes   of this License, Derivative Works shall not include works that remain   separable from, or merely link (or bind by name) to the interfaces of,   the Work and Derivative Works thereof.</p> <p>\"Contribution\" shall mean any work of authorship, including   the original version of the Work and any modifications or additions   to that Work or Derivative Works thereof, that is intentionally   submitted to Licensor for inclusion in the Work by the copyright owner   or by an individual or Legal Entity authorized to submit on behalf of   the copyright owner. For the purposes of this definition, \"submitted\"   means any form of electronic, verbal, or written communication sent   to the Licensor or its representatives, including but not limited to   communication on electronic mailing lists, source code control systems,   and issue tracking systems that are managed by, or on behalf of, the   Licensor for the purpose of discussing and improving the Work, but   excluding communication that is conspicuously marked or otherwise   designated in writing by the copyright owner as \"Not a Contribution.\"</p> <p>\"Contributor\" shall mean Licensor and any individual or Legal Entity   on behalf of whom a Contribution has been received by Licensor and   subsequently incorporated within the Work.</p> </li> <li> <p>Grant of Copyright License. Subject to the terms and conditions of       this License, each Contributor hereby grants to You a perpetual,       worldwide, non-exclusive, no-charge, royalty-free, irrevocable       copyright license to reproduce, prepare Derivative Works of,       publicly display, publicly perform, sublicense, and distribute the       Work and such Derivative Works in Source or Object form.</p> </li> <li> <p>Grant of Patent License. Subject to the terms and conditions of       this License, each Contributor hereby grants to You a perpetual,       worldwide, non-exclusive, no-charge, royalty-free, irrevocable       (except as stated in this section) patent license to make, have made,       use, offer to sell, sell, import, and otherwise transfer the Work,       where such license applies only to those patent claims licensable       by such Contributor that are necessarily infringed by their       Contribution(s) alone or by combination of their Contribution(s)       with the Work to which such Contribution(s) was submitted. If You       institute patent litigation against any entity (including a       cross-claim or counterclaim in a lawsuit) alleging that the Work       or a Contribution incorporated within the Work constitutes direct       or contributory patent infringement, then any patent licenses       granted to You under this License for that Work shall terminate       as of the date such litigation is filed.</p> </li> <li> <p>Redistribution. You may reproduce and distribute copies of the       Work or Derivative Works thereof in any medium, with or without       modifications, and in Source or Object form, provided that You       meet the following conditions:</p> <p>(a) You must give any other recipients of the Work or       Derivative Works a copy of this License; and</p> <p>(b) You must cause any modified files to carry prominent notices       stating that You changed the files; and</p> <p>\u00a9 You must retain, in the Source form of any Derivative Works       that You distribute, all copyright, patent, trademark, and       attribution notices from the Source form of the Work,       excluding those notices that do not pertain to any part of       the Derivative Works; and</p> <p>(d) If the Work includes a \"NOTICE\" text file as part of its       distribution, then any Derivative Works that You distribute must       include a readable copy of the attribution notices contained       within such NOTICE file, excluding those notices that do not       pertain to any part of the Derivative Works, in at least one       of the following places: within a NOTICE text file distributed       as part of the Derivative Works; within the Source form or       documentation, if provided along with the Derivative Works; or,       within a display generated by the Derivative Works, if and       wherever such third-party notices normally appear. The contents       of the NOTICE file are for informational purposes only and       do not modify the License. You may add Your own attribution       notices within Derivative Works that You distribute, alongside       or as an addendum to the NOTICE text from the Work, provided       that such additional attribution notices cannot be construed       as modifying the License.</p> <p>You may add Your own copyright statement to Your modifications and   may provide additional or different license terms and conditions   for use, reproduction, or distribution of Your modifications, or   for any such Derivative Works as a whole, provided Your use,   reproduction, and distribution of the Work otherwise complies with   the conditions stated in this License.</p> </li> <li> <p>Submission of Contributions. Unless You explicitly state otherwise,       any Contribution intentionally submitted for inclusion in the Work       by You to the Licensor shall be under the terms and conditions of       this License, without any additional terms or conditions.       Notwithstanding the above, nothing herein shall supersede or modify       the terms of any separate license agreement you may have executed       with Licensor regarding such Contributions.</p> </li> <li> <p>Trademarks. This License does not grant permission to use the trade       names, trademarks, service marks, or product names of the Licensor,       except as required for reasonable and customary use in describing the       origin of the Work and reproducing the content of the NOTICE file.</p> </li> <li> <p>Disclaimer of Warranty. Unless required by applicable law or       agreed to in writing, Licensor provides the Work (and each       Contributor provides its Contributions) on an \"AS IS\" BASIS,       WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or       implied, including, without limitation, any warranties or conditions       of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A       PARTICULAR PURPOSE. You are solely responsible for determining the       appropriateness of using or redistributing the Work and assume any       risks associated with Your exercise of permissions under this License.</p> </li> <li> <p>Limitation of Liability. In no event and under no legal theory,       whether in tort (including negligence), contract, or otherwise,       unless required by applicable law (such as deliberate and grossly       negligent acts) or agreed to in writing, shall any Contributor be       liable to You for damages, including any direct, indirect, special,       incidental, or consequential damages of any character arising as a       result of this License or out of the use or inability to use the       Work (including but not limited to damages for loss of goodwill,       work stoppage, computer failure or malfunction, or any and all       other commercial damages or losses), even if such Contributor       has been advised of the possibility of such damages.</p> </li> <li> <p>Accepting Warranty or Additional Liability. While redistributing       the Work or Derivative Works thereof, You may choose to offer,       and charge a fee for, acceptance of support, warranty, indemnity,       or other liability obligations and/or rights consistent with this       License. However, in accepting such obligations, You may act only       on Your own behalf and on Your sole responsibility, not on behalf       of any other Contributor, and only if You agree to indemnify,       defend, and hold each Contributor harmless for any liability       incurred by, or claims asserted against, such Contributor by reason       of your accepting any such warranty or additional liability.</p> </li> </ol> <p>END OF TERMS AND CONDITIONS</p> <p>APPENDIX: How to apply the Apache License to your work.</p> <pre><code>  To apply the Apache License to your work, attach the following\n  boilerplate notice, with the fields enclosed by brackets \"[]\"\n  replaced with your own identifying information. (Don't include\n  the brackets!)  The text should be enclosed in the appropriate\n  comment syntax for the file format. We also recommend that a\n  file or class name and description of purpose be included on the\n  same \"printed page\" as the copyright notice for easier\n  identification within third-party archives.\n</code></pre> <p>Copyright [yyyy] [name of copyright owner]</p> <p>Licensed under the Apache License, Version 2.0 (the \"License\");    you may not use this file except in compliance with the License.    You may obtain a copy of the License at</p> <pre><code>   http://www.apache.org/licenses/LICENSE-2.0\n</code></pre> <p>Unless required by applicable law or agreed to in writing, software    distributed under the License is distributed on an \"AS IS\" BASIS,    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.    See the License for the specific language governing permissions and    limitations under the License.</p>"},{"location":"MAINTAINERS/","title":"Maintainers","text":""},{"location":"MAINTAINERS/#active-maintainers","title":"Active Maintainers","text":"Name Github LFID Daniel Hardman dhh1128 George Aristy llorllale Nathan George nage Stephen Curran swcurran Drummond Reed talltree Sam Curren TelegramSam"},{"location":"MAINTAINERS/#emeritus-maintainers","title":"Emeritus Maintainers","text":"Name Github LFID"},{"location":"MAINTAINERS/#becoming-a-maintainer","title":"Becoming a Maintainer","text":"<p>The Aries community welcomes contributions. Contributors may progress to become a maintainer. To become a maintainer the following steps occur, roughly in order.</p> <ul> <li>5 significant changes have been authored by the proposed maintainer and   accepted.</li> <li>The proposed maintainer has the sponsorship of at least one other maintainer.</li> <li>This sponsoring maintainer will create a PR modifying the list of     maintainers.</li> <li>The proposed maintainer accepts the nomination and expresses a willingness     to be a long-term (more than 6 month) committer.</li> <li>This would be a comment in the above PR.</li> <li>This PR will be communicated in all appropriate communication channels. It     should be mentioned in any maintainer/community call. It should also be     posted to the appropriate mailing list or chat channels if they exist.</li> <li>Approval by at least 3 current maintainers within two weeks of the proposal or   an absolute majority of current maintainers.</li> <li>These votes will be recorded in the PR modifying the list of maintainers.</li> <li>No veto by another maintainer within two weeks of proposal are recorded.</li> <li>All vetoes must be accompanied by a public explanation as a comment in the     PR for adding this maintainer</li> <li>The explanation of the veto must be reasonable.</li> <li>A veto can be retracted, in that case the approval/veto timeframe is reset.</li> <li>It is bad form to veto, retract, and veto again.</li> <li>The proposed maintainer becomes a maintainer</li> <li>Either two weeks have passed since the third approval,</li> <li>Or an absolute majority of maintainers approve.</li> <li>In either case, no maintainer presents a veto.</li> </ul>"},{"location":"MAINTAINERS/#removing-maintainers","title":"Removing Maintainers","text":"<p>Being a maintainer is not a status symbol or a title to be maintained indefinitely. It will occasionally be necessary and appropriate to move a maintainer to emeritus status. This can occur in the following situations:</p> <ul> <li>Resignation of a maintainer.</li> <li>Violation of the Code of Conduct warranting removal.</li> <li>Inactivity.</li> <li>A general measure of inactivity will be no commits or code review comments     for one reporting quarter, although this will not be strictly enforced if     the maintainer expresses a reasonable intent to continue contributing.</li> <li>Reasonable exceptions to inactivity will be granted for known long term     leave such as parental leave and medical leave.</li> <li>Other unspecified circumstances.</li> </ul> <p>Like adding a maintainer the record and governance process for moving a maintainer to emeritus status is recorded in the github PR making that change.</p> <p>Returning to active status from emeritus status uses the same steps as adding a new maintainer. Note that the emeritus maintainer already has the 5 required significant changes as there is no contribution time horizon for those.</p>"},{"location":"RFCindex/","title":"Aries RFCs by Status","text":""},{"location":"RFCindex/#adopted","title":"ADOPTED","text":"<ul> <li>0003: Protocols (2019-04-01, 10 impls \u2014 <code>concept</code>)</li> <li>0005: DID Communication (2019-11-21, 10 impls \u2014 <code>concept</code>)</li> <li>0008: Message ID and Threading (2018-10-01, 5 impls \u2014 <code>concept</code>)</li> <li>0011: Decorators (2019-01-31, 10 impls \u2014 <code>concept</code> <code>decorator</code>)</li> <li>0015: ACKs (2024-05-01, 4 impls \u2014 <code>feature</code>)</li> <li>0017: Attachments (2024-05-01, 2 impls \u2014 <code>concept</code>)</li> <li>0019: Encryption Envelope (2019-05-04, 7 impls \u2014 <code>feature</code>)</li> <li>0020: Message Types (2019-05-24, 8 impls \u2014 <code>concept</code>)</li> <li>0021: DIDComm Message Anatomy (2019-05-25 \u2014 <code>concept</code> <code>decorator</code>)</li> <li>0023: DID Exchange v1 (2021-04-15, 1 impl \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0025: DIDComm Transports (2019-12-05 \u2014 <code>feature</code>)</li> <li>0031: Discover Features Protocol 1.0 (2019-05-01, 2 impls \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0035: Report Problem Protocol 1.0 (2024-05-01, 3 impls \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0036: Issue Credential Protocol 1.0 (2019-05-28, 1 impl \u2014 <code>feature</code> <code>decorator</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> <li>0037: Present Proof Protocol 1.0 (2019-05-28, 1 impl \u2014 <code>feature</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> <li>0048: Trust Ping Protocol 1.0 (2019-02-01, 6 impls \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0092: Transports Return Route (2024-05-01, 2 impls \u2014 <code>feature</code>)</li> <li>0094: Cross-Domain Messaging (2024-05-01 \u2014 <code>concept</code>)</li> <li>0095: Basic Message Protocol 1.0 (2019-08-06, 6 impls \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0160: Connection Protocol (2019-08-06, 6 impls \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0211: Mediator Coordination Protocol (2024-05-01, 2 impls \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0302: Aries Interop Profile (2021-01-06 \u2014 <code>concept</code>)</li> <li>0360: did:key Usage (2024-05-01 \u2014 <code>feature</code>)</li> <li>0434: Out-of-Band Protocol 1.1 (2020-03-01 \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0441: Prover and Verifier Best Practices for Proof Presentation (2024-05-01 \u2014 <code>concept</code> <code>credentials</code>)</li> <li>0453: Issue Credential Protocol 2.0 (2021-04-15 \u2014 <code>feature</code> <code>decorator</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> <li>0454: Present Proof Protocol 2.0 (2021-04-15 \u2014 <code>feature</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> <li>0496: Transition to the Out of Band Protocol (2021-11-24 \u2014 <code>feature</code> <code>community-update</code> <code>test-anomaly</code>)</li> <li>0510: Presentation-Exchange Attachment format for requesting and presenting proofs (2020-07-21 \u2014 <code>feature</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> <li>0557: Discover Features Protocol v2.x (2024-05-01 \u2014 <code>feature</code> <code>protocol</code> <code>test-anomaly</code>)</li> <li>0592: Indy Attachment Formats for Requesting and Presenting Credentials (2021-04-15 \u2014 <code>feature</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> <li>0593: JSON-LD Credential Attachment format for requesting and issuing credentials (2021-04-15 \u2014 <code>feature</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> </ul>"},{"location":"RFCindex/#accepted","title":"ACCEPTED","text":"<ul> <li>0004: Agents (2019-01-15, 11 impls \u2014 <code>concept</code>)</li> <li>0006: SSI Notation (2018-09-01, 1 impl \u2014 <code>concept</code>)</li> <li>0044: DIDComm File and MIME Types (2021-04-15 \u2014 <code>feature</code>)</li> <li>0046: Mediators and Relays (2019-02-01, 3 impls \u2014 <code>concept</code>)</li> <li>0047: JSON-LD Compatibility (2019-02-20 \u2014 <code>concept</code> <code>decorator</code>)</li> <li>0049: Repudiation (2019-03-01 \u2014 <code>concept</code>)</li> <li>0050: Wallets (2018-07-01, 1 impl \u2014 <code>concept</code>)</li> <li>0183: Revocation Notification 1.0 (2024-05-01 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0519: Goal Codes (2021-04-15 \u2014 <code>concept</code>)</li> <li>0587: Encryption Envelope v2 (2021-04-15 \u2014 <code>feature</code>)</li> <li>0646: W3C Credential Exchange using BBS+ Signatures (2021-04-28 \u2014 <code>feature</code>)</li> <li>0685: Pickup Protocol 2.0 (2024-05-01 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0721: Revocation Notification 2.0 (2024-05-01 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0793: Unqualified DID Transition (2023-07-11, 12 impls \u2014 <code>feature</code> <code>community-update</code>)</li> <li>0794: DID Rotate 1.0 (2024-03-02 \u2014 <code>feature</code> <code>protocol</code>)</li> </ul>"},{"location":"RFCindex/#demonstrated","title":"DEMONSTRATED","text":"<ul> <li>0032: Message Timing (2019-05-01, 1 impl \u2014 <code>feature</code>)</li> <li>0042: LOX -- A more secure pluggable framework for protecting wallet keys (2019-05-30, 1 impl \u2014 <code>feature</code>)</li> <li>0043: l10n (Locali[s|z]ation) (2019-04-01, 4 impls \u2014 <code>feature</code> <code>decorator</code>)</li> <li>0113: Question Answer Protocol 0.9 (2019-07-05, 2 impls \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0509: Action Menu Protocol (2020-07-02 , 1 impl \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0748: N-wise DID Exchange Protocol 1.0 (2022-08-03, 1 impl \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0755: Overlays Capture Architecture (OCA) For Aries (2024-03-02 \u2014 <code>feature</code>)</li> <li>0756: OCA for Aries Style Guide (2023-01-05 \u2014 <code>feature</code>)</li> <li>0780: Use Data URLs for Images and More in Credential Attributes (2024-03-02 \u2014 <code>feature</code>)</li> <li>0804: DIDComm Remote Procedure Call (DRPC) (2024-03-02 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0809: W3C Verifiable Credential Data Integrity Attachment format for requesting and issuing credentials (2024-01-10 \u2014 <code>feature</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> </ul>"},{"location":"RFCindex/#proposed","title":"PROPOSED","text":"<ul> <li>0028: Introduce Protocol 1.0 (2019-04-15 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0034: Message Tracing (2018-10-24 \u2014 <code>feature</code> <code>decorator</code>)</li> <li>0056: Service Decorator (2019-06-03 \u2014 <code>feature</code> <code>decorator</code>)</li> <li>0066: Non-Repudiable Signature for Cryptographic Envelope (2019-04-15 \u2014 <code>feature</code>)</li> <li>0067: DIDComm DID document conventions (2019-06-10 \u2014 <code>feature</code>)</li> <li>0074: DIDComm Best Practices (2019-06-10 \u2014 <code>concept</code>)</li> <li>0103: Indirect Identity Control (2019-06-04 \u2014 <code>concept</code> <code>credentials</code>)</li> <li>0104: Chained Credentials (2019-09-09 \u2014 <code>concept</code> <code>credentials</code>)</li> <li>0124: DID Resolution Protocol 0.9 (2019-07-13 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0167: Data Consent Lifecycle (2019-08-07 (updated 2019-03-16) \u2014 <code>concept</code>)</li> <li>0212: Pickup Protocol (2019-09-03 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0213: Transfer Policy Protocol (2019-09-03 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0214: \"Help Me Discover\" Protocol (2019-09-10 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0231: Biometric Service Provider (2019-09-24 \u2014 <code>concept</code>)</li> <li>0268: Unified DIDCOMM Deeplinking (2019-10-23 \u2014 <code>concept</code>)</li> <li>0270: Interop Test Suite (2019-10-25 \u2014 <code>concept</code>)</li> <li>0345: Community Coordinated Update (2019-12-26 (date you submit your PR) \u2014 <code>concept</code>)</li> <li>0346: DIDComm Between Two Mobile Agents Using Cloud Agent Mediator (2019-06-23 \u2014 <code>concept</code>)</li> <li>0347: Proof Negotiation (2019-12-13 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0430: Machine-Readable Governance Frameworks (2020-02-24 \u2014 <code>concept</code>)</li> <li>0440: KMS Architectures  (2020-03-06 \u2014 <code>concept</code>)</li> <li>0511: Credential-Manifest Attachment format for requesting and presenting credentials (2020-07-22 \u2014 <code>feature</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> <li>0559: Privacy-Preserving Proof of Uniqueness (2020-10-21 \u2014 <code>concept</code>)</li> <li>0566: Issuer-Hosted Custodial Agents (2020-11-16 \u2014 <code>concept</code>)</li> <li>0641: Linking binary objects to credentials using hash based references (2021-04-22 \u2014 <code>feature</code> <code>credentials</code>)</li> <li>0693: Cross-Platform Credential Representation (2021-07-06 \u2014 <code>feature</code>)</li> <li>0699: Push Notifications apns Protocol 1.0 (2021-10-07 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0700: Out-of-Band through redirect (2021-10-08 \u2014 <code>concept</code> <code>decorator</code>)</li> <li>0728: Device Binding Attachments (2022-04-07 \u2014 <code>feature</code>)</li> <li>0734: Push Notifications fcm Protocol 1.0 (2022-05-12 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0757: Push Notification (2022-11-02  \u2014 <code>concept</code>)</li> <li>0771: AnonCreds Attachment Formats for Requesting and Presenting Credentials (2023-02-24 \u2014 <code>feature</code> <code>protocol</code> <code>credentials</code> <code>test-anomaly</code>)</li> <li>0799: Aries Long Term Support Releases (2023-11-07  \u2014 <code>concept</code>)</li> </ul>"},{"location":"RFCindex/#stalled","title":"STALLED","text":"<ul> <li>0024: DIDComm over XMPP (2024-04-03 \u2014 <code>feature</code>)</li> <li>0029: Message Trust Contexts (2024-04-03, 3 impls \u2014 <code>concept</code>)</li> <li>0030: Sync Connection Protocol 1.0 (2024-04-03 \u2014 <code>feature</code> <code>decorator</code> <code>protocol</code>)</li> <li>0075: Payment Decorators (2024-04-03 \u2014 <code>feature</code> <code>decorator</code>)</li> <li>0114: Predefined Identities (2024-04-03 \u2014 <code>feature</code>)</li> <li>0116: Evidence Exchange Protocol 0.9 (2024-04-03 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0193: Coin Flip Protocol 1.0  (2024-04-03 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0207: Credential Fraud Threat Model (2024-04-03 \u2014 <code>concept</code> <code>credentials</code>)</li> <li>0217: Linkable Message Paths (2024-04-03 \u2014 <code>concept</code>)</li> <li>0249: Aries Rich Schema Contexts (2024-04-03 \u2014 <code>feature</code> <code>rich-schemas</code>)</li> <li>0250: Rich Schema Objects (2024-04-03 \u2014 <code>concept</code> <code>rich-schemas</code>)</li> <li>0257: Private Credential Issuance (2024-04-03 \u2014 <code>concept</code> <code>protocol</code>)</li> <li>0281: Aries Rich Schemas (2024-04-03 \u2014 <code>feature</code> <code>rich-schemas</code>)</li> <li>0289: The Trust Over IP Stack (2024-04-03 \u2014 <code>concept</code> <code>stack</code> <code>trust layer</code> <code>governance framework</code>)</li> <li>0309: DIDAuthZ (2024-04-03 \u2014 <code>feature</code> <code>credentials</code>)</li> <li>0327: Crypto service Protocol 1.0 (2024-04-03 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0334: JWE envelope 1.0 (2024-04-03 \u2014 <code>feature</code>)</li> <li>0335: HTTP Over DIDComm (2024-04-03 \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0351: Purpose Decorator (2024-04-03 \u2014 <code>feature</code> <code>decorator</code>)</li> <li>0418: Aries Rich Schema Encoding Objects (2024-04-03 \u2014 <code>feature</code> <code>rich-schemas</code>)</li> <li>0420: Rich Schema Objects Common (2024-04-03 \u2014 <code>concept</code> <code>rich-schemas</code>)</li> <li>0428: Prerequisites to Issue Rich Credential (2024-04-03 \u2014 <code>feature</code> <code>rich-schemas</code>)</li> <li>0429: Prerequisites to Request Rich Presentation (2024-04-03 \u2014 <code>feature</code> <code>rich-schemas</code>)</li> <li>0445: Aries Rich Schema Mapping (2024-04-03 \u2014 <code>feature</code> <code>rich-schemas</code>)</li> <li>0446: Aries Rich Schema Credential Definition (2024-04-03 \u2014 <code>feature</code> <code>rich-schemas</code>)</li> <li>0478: Coprotocols (2024-04-03 \u2014 <code>concept</code> <code>protocol</code>)</li> <li>0482: Coprotocol Protocol 0.5 (2024-04-03 \u2014 <code>feature</code> <code>protocol</code>)</li> </ul>"},{"location":"RFCindex/#retired","title":"RETIRED","text":"<ul> <li>0013: Overlays (2023-01-15 \u2014 <code>concept</code>)</li> <li>0051: Decentralized Key Management (2024-04-03, 2 impls \u2014 <code>concept</code>)</li> <li>0234: Signature Decorator (2020-10-14, 3 impls \u2014 <code>feature</code> <code>decorator</code>)</li> <li>0303: V0.1 Credential Exchange (Deprecated) (2019-11-12, 4 impls \u2014 <code>feature</code> <code>protocol</code>)</li> <li>0317: Please ACK Decorator (2019-12-26 \u2014 <code>feature</code> <code>decorator</code>)</li> <li>0348: Transition Message Type to HTTPs (2020-08-26, 14 impls \u2014 <code>feature</code> <code>community-update</code>)</li> <li>0627: Static Peer DIDs (2021-04-07 \u2014 <code>feature</code>)</li> </ul> <p>(This file is machine-generated; see code/generate_index.py.)</p>"},{"location":"SECURITY/","title":"Hyperledger Security Policy","text":""},{"location":"SECURITY/#reporting-a-security-bug","title":"Reporting a Security Bug","text":"<p>If you think you have discovered a security issue in any of the Hyperledger projects, we'd love to hear from you. We will take all security bugs seriously and if confirmed upon investigation we will patch it within a reasonable amount of time and release a public security bulletin discussing the impact and credit the discoverer.</p> <p>There are two ways to report a security bug. The easiest is to email a description of the flaw and any related information (e.g. reproduction steps, version) to security at hyperledger dot org.</p> <p>The other way is to file a confidential security bug in our JIRA bug tracking system. Be sure to set the \u201cSecurity Level\u201d to \u201cSecurity issue\u201d.</p> <p>The process by which the Hyperledger Security Team handles security bugs is documented further in our Defect Response page on our wiki.</p>"},{"location":"contributing/","title":"Contributing","text":""},{"location":"contributing/#contributing","title":"Contributing","text":""},{"location":"contributing/#do-you-need-an-rfc","title":"Do you need an RFC?","text":"<p>Use an RFC to advocate substantial changes to the Aries ecosystem, where those changes need to be understood by developers who use Aries. Minor changes are not RFC-worthy, and changes that are internal in nature, invisible to those consuming Aries, should be documented elsewhere.</p>"},{"location":"contributing/#preparation","title":"Preparation","text":"<p>Before writing an RFC, consider exploring the idea on the aries chat channel, on community calls (see the Hyperledger Community Calendar), or on aries@lists.hyperledger.org. Encouraging feedback from maintainers is a good sign that you're on the right track.</p>"},{"location":"contributing/#how-to-propose-an-rfc","title":"How to propose an RFC","text":"<ul> <li>Fork the RFC repo.</li> <li>Pick a descriptive folder name for your RFC. Don't pick a number yet.     See Best Practices: RFC Naming     for guidance.</li> <li>Decide which parent folder is appropriate for your RFC.     If it is about a specific protocol or decorator or feature, its parent     should be <code>/features</code>; if it is about a concept that will be used in many     different features, its parent should be <code>/concepts</code>.</li> <li>Create the folder and copy either <code>0000-template.md</code> or <code>0000-template-protocol.md</code> (if your RFC is for a protocol) to <code>&lt;parent&gt;/&lt;your folder name&gt;/README.md</code>.</li> <li>Fill in the RFC. Use MUST and SHOULD per standard conventions. Put care into the details: RFCs that do not present     convincing motivation, demonstrate an understanding of the impact of the     design, or are disingenuous about the drawbacks or alternatives tend to be     poorly received. You can add supporting artifacts, such as diagrams and sample     data, in the RFC's folder. Make sure you follow community-endorsed best     practices.</li> <li>Consider how the RFC should be tagged.</li> <li>Assign a number to your RFC. Get the number by loading this web page (or,     if you want to do it the hard way, by inspecting open and closed PRs against     this repo to figure out what the next PR number will be). Rename your folder from     <code>&lt;your folder name&gt;</code> to <code>&lt;your 4-digit number&gt;-&lt;your folder name&gt;</code>. At the     top of your README.md, modify the title so it is in the form: <code>&lt;your 4-digit     number&gt;: Friendly Version of Your Title</code>.</li> <li>Commit and push your changes.</li> <li>Submit a pull request.</li> </ul> <p>Make sure that all of your commits satisfy the DCO requirements of the repo and conform to the license restrictions noted below.</p> <p>The RFC Maintainers will check to see if the process has been followed, and request any process changes before merging the PR.</p> <p>When the PR is merged, your RFC is now formally in the PROPOSED state.</p>"},{"location":"contributing/#changing-an-rfc-status","title":"Changing an RFC Status","text":"<p>The lifecycle of an RFC is driven by the author or current champion of the RFC. To move an RFC along in the lifecycle, submit a PR with the following characteristics:</p> <ul> <li>The PR should ONLY change the RFC status. Note that this requires refreshing the index (<code>python code/generate_index.py &amp;&amp; pytest code</code>).</li> <li>The title of the PR should include a deadline date for merging the PR and the referenced RFC.</li> <li>Example: <code>Status to Accepted, deadline 2019.08.15, RFC 0095-basic-message</code></li> <li>The PR comment should document why the status is being changed.</li> <li>The deadline date should be 2 weeks after announcing the proposed status change on an Aries WG call. The PR should also be announced on the #aries  channel.</li> <li>Barring negative feedback from the community, the repo's maintainers should merge the PR after the deadline.</li> <li>The deadline should be moved by two weeks after addressing each substantive change to the RFC made during the status change review period.</li> </ul>"},{"location":"contributing/#how-to-get-an-rfc-demonstrated","title":"How to get an RFC demonstrated","text":"<p>If your RFC is a feature, it's common (though not strictly required) for it to go to a DEMONSTRATED state next. Write some code that embodies the concepts in the RFC. Publish the code. Then submit a PR that adds your early implementation to the Implementations section, and that changes the status to DEMONSTRATED. These PRs should be accepted immediately, as long as all unit tests pass.</p>"},{"location":"contributing/#how-to-get-an-rfc-accepted","title":"How to get an RFC accepted","text":"<p>After your RFC is merged and officially acquires the PROPOSED status, the RFC will receive feedback from the larger community, and the author should be prepared to revise it. Updates may be made via pull request, and those changes will be merged as long as the process is followed.</p> <p>When you believe that the RFC is mature enough (feedback is somewhat resolved, consensus is emerging, and implementation against it makes sense), submit a PR that changes the status to ACCEPTED. The status change PR will remain open until the maintainers agree on the status change.</p> <p>NOTE: contributors who used the Indy HIPE process prior to May 2019 should see the acceptance process substantially simplified under this approach. The bar for acceptance is not perfect consensus and all issues resolved; it's just general agreement that a doc is \"close enough\" that it makes sense to put it on a standards track where it can be improved as implementation teaches us what to tweak.</p>"},{"location":"contributing/#how-to-get-an-rfc-adopted","title":"How to get an RFC adopted","text":"<p>An accepted RFC is a standards-track document. It becomes an acknowledged standard when there is evidence that the community is deriving meaningful value from it. So:</p> <ul> <li>Implement the ideas, and find out who else is implementing.</li> <li>Socialize the ideas. Use them in other RFCs and documentation.</li> <li>Update the agent test suite to reflect the ideas.</li> </ul> <p>When you believe an RFC is a de facto standard, raise a PR that changes the status to ADOPTED.  If the community is friendly to the idea, the doc will enter a two-week \"Final Comment Period\" (FCP), after which there will be a vote on disposition.</p>"},{"location":"contributing/#intellectual-property","title":"Intellectual Property","text":"<p>This repository is licensed under an Apache 2 License. It is protected by a Developer Certificate of Origin on every commit. This means that any contributions you make must be licensed in an Apache-2-compatible way, and must be free from patent encumbrances or additional terms and conditions. By raising a PR, you certify that this is the case for your contribution.</p>"},{"location":"contributing/#signing-off-commits-dco","title":"Signing off commits (DCO)","text":"<p>If you are here because you forgot to sign off your commits, fear not. Check out how to sign off previous commits</p> <p>We use developer certificate of origin (DCO) in all Hyperledger repositories, so to get your pull requests accepted, you must certify your commits by signing off on each commit.</p>"},{"location":"contributing/#signing-off-your-current-commit","title":"Signing off your current commit","text":"<ul> <li><code>$ git commit -s -m \"your commit message\"</code></li> <li>To see if your commits have been signed off, run <code>$ git log</code>. Any commits including a line with <code>Signed-off-by: Example Author &lt;author.email@example.com&gt;</code> are signed off.</li> <li>If you need to re-sign the most current commit, use <code>$ git commit --amend --no-edit -s</code>.</li> </ul> <p>The <code>-s</code> flag signs off the commit message with your name and email.</p>"},{"location":"contributing/#how-to-sign-off-previous-commits","title":"How to Sign Off Previous Commits","text":"<ol> <li>Use <code>$ git log</code> to see which commits need to be signed off. Any commits missing a line with <code>Signed-off-by: Example Author &lt;author.email@example.com&gt;</code> need to be re-signed.</li> <li>Go into interactive rebase mode using <code>$ git rebase -i HEAD~X</code> where X is the number of commits up to the most current commit you would like to see.</li> <li>You will see a list of the commits in a text file. On the line after each commit you need to sign off, add <code>exec git commit --amend --no-edit -s</code> with the lowercase <code>-s</code> adding a text signature in the commit body. Example that signs both commits:</li> </ol> <pre><code>pick 12345 commit message\nexec git commit --amend --no-edit -s\npick 67890 commit message\nexec git commit --amend --no-edit -s\n</code></pre> <ol> <li> <p>If you need to re-sign a bunch of previous commits at once, find the earliest commit missing the sign off line using <code>$ git log</code> and use that the HASH of the commit before it in this command:    <pre><code> $ git rebase --exec 'git commit --amend --no-edit -n -s' -i HASH.\n</code></pre>    This will sign off every commit from most recent to right before the HASH.</p> </li> <li> <p>You will probably need to do a force push (<code>$ git push -f</code>) if you had previously pushed unsigned commits to remote.</p> </li> </ol>"},{"location":"github-issues/","title":"Submitting Issues","text":""},{"location":"github-issues/#github-issues","title":"Github Issues","text":"<p>RFCs that are not on the brink of changing status are discussed through Github Issues. We generally use Issues to discuss changes that are controversial, and PRs to propose changes that are vetted. This keeps the PR backlog small.</p> <p>Any community member can open an issue; specify the RFC number in the issue title so the relationship is clear. For example, to open an issue on RFC 0025, an appropriate title for the issue might be:</p> <pre><code>RFC 0025: Need better diagram in Reference section\n</code></pre> <p>When the community feels that it's reasonable to suggest a formal status change for an RFC, best efforts are made to resolve all open issues against it. Then a PR is raised against the RFC's main README.md, where the status field in the header is updated. Discussion about the status change typically takes place in the comment stream for the PR, with issues being reserved for non-status-change topics.</p>"},{"location":"tags/","title":"Tags on RFCs","text":"<p>We categorize RFCs with tags to enrich searches. The meaning of tags is given below.</p>"},{"location":"tags/#protocol","title":"<code>protocol</code>","text":"<p>Defines one or more protocols that explain how messages are passed to accomplish a stateful interaction.</p>"},{"location":"tags/#decorator","title":"<code>decorator</code>","text":"<p>Defines one or more decorators that act as mixins to DIDComm messages. Decorators can be added to many different message types without explicitly declaring them in message schemas.</p>"},{"location":"tags/#feature","title":"<code>feature</code>","text":"<p>Defines a specific, concrete feature that agents might support.</p>"},{"location":"tags/#concept","title":"<code>concept</code>","text":"<p>Defines a general aspect of the Aries mental model, or a pattern that manifests in many different features.</p>"},{"location":"tags/#community-update","title":"<code>community-update</code>","text":"<p>An RFC that tracks a community-coordinated update, as described in RFC 0345. Such updates enable independently deployed, interoperable agents to remain interoperable throughout the transition.</p>"},{"location":"tags/#credentials","title":"<code>credentials</code>","text":"<p>Relates to verifiable credentials.</p>"},{"location":"tags/#rich-schemas","title":"<code>rich-schemas</code>","text":"<p>Relates to next-generation schemas, such as those used by https://schema.org, as used in verifiable credentials.</p>"},{"location":"tags/#test-anomaly","title":"<code>test-anomaly</code>","text":"<p>Violates some aspect of our policy on writing tests for protocols before allowing their status to progress beyond DEMONSTRATED. RFCs should only carry this tag temporarily, to grandfather something where test improvements are happening in the background. When this tag is applied to an RFC, unit tests run by our CI/CD pipeline will emit a warning rather than an error about missing tests, IFF each implementation that lacks tests formats its notes about test results like this:</p> <pre><code>name of impl | [MISSING test results](/tags.md#test-anomaly)\n</code></pre>"},{"location":"aip2/0003-protocols/","title":"Aries RFC 0003: Protocols","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-04-01</li> <li>Status Note: standards track and beginning to influence many mental models, but not yet ADOPTED.</li> <li>Supersedes: Indy PR #69</li> <li>Start Date: 2018-12-28</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0003-protocols/#summary","title":"Summary","text":"<p>Defines peer-to-peer application-level protocols in the context of interactions among agent-like things, and shows how they should be designed and documented.</p> <p></p>"},{"location":"aip2/0003-protocols/#table-of-contents","title":"Table of Contents","text":"<ul> <li>Aries RFC 0003: Protocols</li> <li>Summary</li> <li>Motivation</li> <li>Tutorial<ul> <li>What is a Protocol?</li> <li>Relationship to APIs</li> <li>Decentralized</li> <li>Types of Protocols</li> <li>Agent Design</li> <li>Composable</li> <li>Message Types</li> <li>Handling Unrecognized Items in Messages</li> <li>Ingredients</li> <li>How to Define a Protocol</li> <li>Security Considerations</li> <li>Replay Attacks</li> </ul> </li> <li>Reference<ul> <li>Message Type and Protocol Identifier URIs</li> <li>MTURI</li> <li>PIURI</li> <li>Semver Rules for Protocols</li> <li>Semver Examples<ul> <li>Initiator</li> <li>Recipient Rules</li> </ul> </li> <li>State Details and State Machines</li> <li>State Machines</li> <li>Processing Points</li> <li>Roles, Participants, Parties, and Controllers</li> <li>Roles</li> <li>Participants</li> <li>Parties</li> <li>Controllers</li> <li>Instructions for Protocol RFCs</li> </ul> </li> <li>Drawbacks</li> <li>Rationale and alternatives</li> <li>Prior art<ul> <li>BPMN</li> <li>WSDL</li> <li>Swagger / OpenAPI</li> <li>Other</li> </ul> </li> <li>Unresolved questions</li> <li>Implementations</li> </ul>"},{"location":"aip2/0003-protocols/#motivation","title":"Motivation","text":"<p>APIs in the style of Swagger are familiar to nearly all developers, and it's a common assumption that we should use them to solve the problems at hand in the decentralized identity space. However, to truly decentralize, we must think about interactions at a higher level of generalization. Protocols can model all APIs, but not the other way around. This matters. We need to explain why.</p> <p>We also need to show how a protocol is defined, so the analog to defining a Swagger API is demystified.</p>"},{"location":"aip2/0003-protocols/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0003-protocols/#what-is-a-protocol","title":"What is a Protocol?","text":"<p>A protocol is a recipe for a stateful interaction. Protocols are all around us, and are so ordinary that we take them for granted. Each of the following interactions is stateful, and has conventions that constitute a sort of \"recipe\":</p> <ul> <li>Ordering food at a restaurant</li> <li>Buying a house</li> <li>Playing a game of chess, checkers, tic-tac-toe, etc.</li> <li>Bidding on an item in an online auction.</li> <li>Going through security at the airport when we fly</li> <li>Applying for a loan</li> </ul> <p>In the context of decentralized identity, protocols manifest at many different levels of the stack: at the lowest levels of networking, in cryptographic algorithms like Diffie Hellman, in the management of DIDs, in the conventions of DIDComm, and in higher-level interactions that solve problems for people with only minimal interest in the technology they're using. However, this RFC focuses on the last of these layers, where use cases and personas are transformed into ../../features with obvious social value like:</p> <ul> <li>Connecting with one another</li> <li>Requesting and issuing credentials</li> <li>Proving things using credentials</li> <li>Discovering things</li> <li>Delegating</li> <li>Buying and Selling</li> <li>Negotiating</li> <li>Enacting and enforcing contracts</li> <li>Putting things in escrow (and taking them out again)</li> <li>Scheduling</li> <li>Auditing</li> <li>Reporting errors</li> <li>Cooperative debugging</li> </ul> <p>When \"protocol\" is used in an Aries context without any qualifying adjective, it is referencing a recipe for a high-level interaction like these. Lower-level protocols are usually described more specifically and possibly with other verbiage: \"cryptographic algorithms\", \"DID management procedures\", \"DIDComm conventions\", \"transports\", and so forth. This helps us focus \"protocol\" on the place where application developers that consume Aries do most of the work that creates value.</p>"},{"location":"aip2/0003-protocols/#relationship-to-apis","title":"Relationship to APIs","text":"<p>The familiar world of web APIs is a world of protocols, but it comes with constraints antithetical to decentralized identity:</p> <ul> <li>It assumes all interactions are between a client and a server--either two parties, or N parties mediated by a central server. Thus, the server is a natural locus for surveillance and hacking.</li> <li>It assumes security is asymmetric--not using DIDs, but driven by certs on a server and by a session for the client.</li> <li>It assumes the transport is HTTP. This is problematic for pure mobile-to-mobile, or for use cases where the transport is complex or asymmetric.</li> <li>Because the server can never initiate an interaction, it requires at least one party to be continuously online.</li> </ul> <p>Protocols impose none of these constraints. Web APIs can easily be modeled as protocols where the transport is HTTP and the payload is a message, and the Aries community actively does this. We are not opposed to APIs. We just want to describe and standardize the higher level abstraction so we don't have a web solution and a BlueTooth solution that are diverged for no good reason.</p>"},{"location":"aip2/0003-protocols/#decentralized","title":"Decentralized","text":"<p>As used in the agent/DIDComm world, protocols are decentralized. This means there is not an overseer for the protocol, guaranteeing information flow, enforcing behaviors, and ensuring a coherent view. It is a subtle but important divergence from API-centric approaches, where a server holds state against which all other parties (clients) operate. Instead, all parties are peers, and they interact by mutual consent and with a (hopefully) shared understanding of the rules and goals. Protocols are like a dance\u2014not one that's choreographed or directed, but one where the parties make dynamic decisions and react to them.</p> <p></p>"},{"location":"aip2/0003-protocols/#types-of-protocols","title":"Types of Protocols","text":"<p>The simplest protocol style is notification. This style involves two parties, but it is one-way: the <code>notifier</code> emits a message, and the protocol ends when the <code>notified</code> receives it. The basic message protocol uses this style.</p> <p></p> <p>Slightly more complex is the request-response protocol style. This style involve two parties, with the <code>requester</code> making the first move, and the <code>responder</code> completing the interaction. The Discover Features Protocol uses this style. Note that with protocols as Aries models them (and unlike an HTTP request), the request-response messages are asynchronous.</p> <p></p> <p>However, more complex protocols exist. The Introduce Protocol involves three parties, not two. The issue credential protocol includes up to six message types (including <code>ack</code> and <code>problem_report</code>), two of which (<code>proposal</code> and <code>offer</code>) can be used to interactively negotiate details of the elements of the subsequent messages in the protocol.</p> <p>See this subsection for definitions of the terms \"role\", \"participant\", and \"party\".</p>"},{"location":"aip2/0003-protocols/#agent-design","title":"Agent Design","text":"<p>Protocols are the key unit of interoperable extensibility in agents and agent-like things. To add a new interoperable feature to an agent, give it the ability to handle a new protocol.</p> <p>When agents receive messages, they map the messages to a protocol handler and possibly to an interaction state that was previously persisted. This is the analog to routes, route handlers, and sessions in web APIs, and could actually be implemented as such if the transport for the protocol is HTTP. The protocol handler is code that knows the rules of a particular protocol; the interaction state tracks progress through an interaction. For more information, see the agents explainer\u2014RFC 0004 and the DIDComm explainer\u2014RFC 0005.</p>"},{"location":"aip2/0003-protocols/#composable","title":"Composable","text":"<p>Protocols are composable--meaning that you can build complex ones from simple ones. The protocol for asking someone to repeat their last sentence can be part of the protocol for ordering food at a restaurant. It's common to ask a potential driver's license holder to prove their street address before issuing the license. In protocol terms, this is nicely modeled as the present proof being invoked in the middle of an issue credential protocol.</p> <p>When we run one protocol inside another, we call the inner protocol a subprotocol, and the outer protocol a superprotocol. A given protocol may be a subprotocol in some contexts, and a standalone protocol in others. In some contexts, a protocol may be a subprotocol from one perspective, and a superprotocol from another (as when protocols are nested at least 3 deep).</p> <p></p> <p>Commonly, protocols wait for subprotocols to complete, and then they continue. A good example of this is mentioned above\u2014starting an issue credential flow, but requiring the potential issuer and/or the potential holder to prove something to one another before completing the process.</p> <p>In other cases, a protocol B is not \"contained\" inside protocol A. Rather, A triggers B, then continues in parallel, without waiting for B to complete. This coprotocol relationship is analogous to relationship between coroutines in computer science. In the Introduce Protocol, the final step is to begin a connection protocol between the two introducees-- but the introduction coprotocol completes when the connect coprotocol starts, not when it completes.</p> <p></p>"},{"location":"aip2/0003-protocols/#message-types","title":"Message Types","text":"<p>A protocol includes a number of message types that enable the execution of an instance of a protocol. Collectively, the message types of a protocol become the skeleton of its interface. Most of the message types are defined with the protocol, but several key message types, notably acks and problem reports are defined in separate RFCs and <code>adopted</code> into a protocol. This ensures that the structure of such messages is standardized, but used in the context of the protocol adopting the message types.</p>"},{"location":"aip2/0003-protocols/#handling-unrecognized-items-in-messages","title":"Handling Unrecognized Items in Messages","text":"<p>In the semver section of this document there is discussion of the handling of mismatches in minor versions supported and received. Notably, a recipient that supports a given minor version of a protocol less than that of a received protocol message should ignore any unrecognized fields in the message. Such handling of unrecognized data items applies more generally than just minor version mismatches. A recipient of a message from a supported major version of a protocol should ignore any unrecognized items in a received message, even if the supported and minor versions are the same. When items from the message are ignored, the recipient may want to send a warning <code>problem-report</code> message with code <code>fields-ignored</code>.</p>"},{"location":"aip2/0003-protocols/#ingredients","title":"Ingredients","text":"<p>A protocol has the following ingredients:</p> <ul> <li>Name and semver-compatible   version</li> <li>URI that uniquely identifies it</li> <li>Messages (primary message family)</li> <li>Adopted messages</li> <li>Roles</li> <li>State and sequencing rules</li> <li>Events that can change state -- notably, messages, but also errors, timeouts, and other things</li> <li>Constraints that provide trust and incentives</li> </ul>"},{"location":"aip2/0003-protocols/#how-to-define-a-protocol","title":"How to Define a Protocol","text":"<p>To define a protocol, write an RFC. Specific instructions for protocol RFCs, and a discussion about the theory behind detailed protocol ../../concepts, are given in the instructions for protocol RFCs and in the protocol RFC template.</p> <p>The tictactoe protocol is attached to this RFC as an example.</p> <p></p>"},{"location":"aip2/0003-protocols/#security-considerations","title":"Security Considerations","text":""},{"location":"aip2/0003-protocols/#replay-attacks","title":"Replay Attacks","text":"<p>It should be noted that when defining a protocol that has domain specific requirements around preventing replay attacks, an <code>@id</code> property SHOULD be required. Given an <code>@id</code> field is most commonly set to be a UUID, it should provide randomness comparable to that of a nonce in preventing replay attacks. However, this means that care will be needed in processing of the <code>@id</code> field to make sure its value has not been used before. In some cases, nonces require being unpredictable as well. In this case, greater review should be taken as to how the <code>@id</code> field should be used in the domain specific protocol. In the event where the <code>@id</code> field is not adequate for preventing replay attacks, it's recommended that an additional <code>nonce</code> field be required by the domain specific protocol specification.</p>"},{"location":"aip2/0003-protocols/#reference","title":"Reference","text":""},{"location":"aip2/0003-protocols/#message-type-and-protocol-identifier-uris","title":"Message Type and Protocol Identifier URIs","text":"<p>Message types and protocols are identified with URIs that match certain conventions.</p>"},{"location":"aip2/0003-protocols/#mturi","title":"MTURI","text":"<p>A message type URI (MTURI) identifies message types unambiguously. Standardizing its format is important because it is parsed by agents that will map messages to handlers--basically, code will look at this string and say, \"Do I have something that can handle this message type inside protocol X version Y?\"</p> <p>When this analysis happens, strings should be compared for byte-wise equality in all segments except version. This means that case, unicode normalization, and punctuation differences all matter. It is thus best practice to avoid protocol and message names that differ only in subtle, easy-to-mistake ways.</p> <p>Comparison of the version segment of an MTURI or PIURI should follow semver rules and is discussed in the semver section of this document.</p> <p>The URI MUST be composed as follows:</p> <p></p> <pre><code>message-type-uri  = doc-uri delim protocol-name\n    \"/\" protocol-version \"/\" message-type-name\ndelim             = \"?\" / \"/\" / \"&amp;\" / \":\" / \";\" / \"=\"\nprotocol-name     = identifier\nprotocol-version  = semver\nmessage-type-name = identifier\nidentifier        = alpha *(*(alphanum / \"_\" / \"-\" / \".\") alphanum)\n</code></pre> <p>It can be loosely matched and parsed with the following regex:</p> <pre><code>    (.*?)([a-z0-9._-]+)/(\\d[^/]*)/([a-z0-9._-]+)$\n</code></pre> <p>A match will have captures groups of (1) = <code>doc-uri</code>, (2) = <code>protocol-name</code>, (3) = <code>protocol-version</code>, and (4) = <code>message-type-name</code>.</p> <p>The goals of this URI are, in descending priority:</p> <ul> <li> <p>Code can use the URI to route messages to protocol handlers using semver rules.</p> </li> <li> <p>The definition of a protocol should be tied to the URI such that it is semantically stable. This means that once version 1.0 of a protocol is defined, its definition should not change in ways that would break implementations.</p> </li> <li> <p>Developers can discover information about novel protocols, using the URI to browse or search the web.</p> </li> </ul> <p>The <code>doc-uri</code> portion is any URI that exposes documentation about protocols. A developer should be able to browse to that URI and use human intelligence to look up the named and versioned protocol. Optionally and preferably, the full URI may produce a page of documentation about the specific message type, with no human mediation involved.</p>"},{"location":"aip2/0003-protocols/#piuri","title":"PIURI","text":"<p>A shorter URI that follows the same conventions but lacks the <code>message-type-name</code> portion is called a protocol identifier URI (PIURI).</p> <p></p> <pre><code>protocol-identifier-uri  = doc-uri delim protocol-name\n    \"/\" semver\n</code></pre> <p>Its loose matcher regex is:</p> <pre><code>    (.*?)([a-z0-9._-]+)/(\\d[^/]*)/?$\n</code></pre> <p>The following are examples of valid MTURIs and PIURIs:</p> <ul> <li><code>http://example.com/protocols?which=lets_do_lunch/1.0/</code> (PIURI with fully automated lookup of protocol docs)</li> <li><code>http://example.com/message_types?which=lets_do_lunch/1.0/proposal</code> (MTURI)</li> <li><code>https://github.com/hyperledger/aries-rfcs/tree/18c4f82:trust_ping/1.0/ping</code>    (MTURI). Note that this URI returns a 404 error if followed directly--but    per rules described above, the developer should browse to the doc root    (https://github.com/hyperledger/aries-rfcs/tree/18c4f82) and look for documentation on the <code>trust_ping/1.0</code> protocol.</li> <li><code>https://didcomm.org/trust_ping/1.0/ping</code> (MTURI) This    uses an https reference that could serve    information about protocols.</li> </ul>"},{"location":"aip2/0003-protocols/#semver-rules-for-protocols","title":"Semver Rules for Protocols","text":"<p>Semver rules apply to protocols, with the version of a protocol is expressed in the <code>semver</code> portion of its identifying URI. The \"ingredients\" of a protocol combine to form a public API in the semver sense. Core Aries protocols specify only major and minor elements in a version; the patch component is not used. Non-core protocols may choose to use the patch element.</p> <p>The major and minor versions of protocols match semver semantics:</p> <ul> <li>Clarification updates that do not change the \"public API\" of the protocol can be made with community support without changing the minor version of the protocol.</li> <li>An individual message type can add new optional fields, or deprecate existing fields, with only a change to its protocol's minor version. Similarly, a protocol can add new or deprecate message types with only a change to the minor version.</li> <li>Changes that remove fields or message types, that make formerly optional things required, or that alter the state machine in incompatible ways, must result in an increase of the major version of the protocol/primary message family.</li> </ul> <p>Within a given major version of a protocol, an agent should:</p> <ul> <li>Respond to a minimum supported minor version, defaulting to \"0\".</li> <li>An agent SHOULD keep minimum supported minor version at \"0\" unless it is unsecure or extremely complicated to do so.</li> <li>Respond with or initiate a protocol instance the current fully supported minor version.</li> </ul> <p>This leads to the following received message handling rules:</p> <ul> <li>Message types received with minor versions below the minimum MAY be ignored, or preferably, MAY be answered only with a <code>problem-report</code> message with code <code>version-not-supported</code>.</li> <li>Message types received with a minor version at or higher than the minimum supported and less than the current minor version are processed as follows:</li> <li>The processing MAY be with the same minor version of the received message.<ul> <li>To support this, an implementation must implement each minor version from minimum to current within the major version.</li> </ul> </li> <li>The processing MAY be with the current minor version (higher than received).<ul> <li>This approach is used when maintaining each minor version from minimum to current within the major version is impractical.</li> <li>Recipients of the response message SHOULD detect from the response PIURI that a higher minor version was used in the response, and to compensate if needed and as necessary.</li> <li>Prior wording of this protocol included the following suggestion that is now considered deprecated. See note below about deprecating the \"warning\" problem reports.</li> <li>In addition to responding with the protocol message (if necessary), the agent MAY also want to send a warning <code>problem-report</code> message with code <code>version-with-degraded-../../features</code>.</li> </ul> </li> <li>Message types received with a minor version higher than the current minor version MUST be processed with any unrecognized fields ignored.</li> <li>The response MUST use the current minor version.</li> <li>Recipients of the response message SHOULD detect from the response PIURI that a lower minor version was used in the response, and to compensate if needed and as necessary.</li> <li>Prior wording of this protocol included the following that is now considered deprecated. See note below about deprecating the \"warning\" problem reports.<ul> <li>In addition to responding with the protocol message, an agent MAY send a warning <code>problem-report</code> message with code <code>fields-ignored-due-to-version-mismatch</code></li> </ul> </li> </ul> <p>Note: The deprecation of the \"warning\" <code>problem-reports</code> in cases of minor version mismatches is because the recipient of the response can detect the mismatch by looking at the PIURI, making the \"warning\" unnecessary, and because the <code>problem-report</code> message may be received after (and definitely at a different time than) the response message, and so the warning is of very little value to the recipient. Recipients should still be aware that minor version mismatch warning <code>problem-report</code> messages may be received and handle them appropriately, likely by quietly ignoring them.</p> <p>As documented in the semver documentation, these requirements are not applied when major version 0 is used. In that case, minor version increments are considered breaking.</p> <p>Agents may support multiple major versions and select which major version to use when initiating an instance of the protocol.</p> <p>An agent should reject messages from protocols or unsupported protocol major versions with a <code>problem-report</code> message with code <code>version-not-supported</code>. Agents that receive such a <code>problem-report</code> message may use the discover ../../features protocol to resolve the mismatch.</p>"},{"location":"aip2/0003-protocols/#semver-examples","title":"Semver Examples","text":""},{"location":"aip2/0003-protocols/#initiator","title":"Initiator","text":"<p>Unless Alice's agent (the initiator of a protocol) knows from prior history that it should do something different, it should begin a protocol using the highest version number that it supports. For example, if A.1 supports versions 2.0 through 2.2 of protocol X, it should use 2.2 as the version in the message type of its first message.</p>"},{"location":"aip2/0003-protocols/#recipient-rules","title":"Recipient Rules","text":"<p>Agents for Bob (the recipient) should reject messages from protocols with major versions different from those they support. For major version 0, they should also reject protocols with minor versions they don't support, since semver stipulates that ../../features are not stable before 1.0. For example, if B.1 supports only versions 2.0 and 2.1 of protocol X, it should reject any messages from version 3 or version 1 or 0. In most cases, rejecting a message means sending a <code>problem-report</code> that the message is unsupported. The <code>code</code> field in such messages should be <code>version-not-supported</code>. Agents that receive such a <code>problem-report</code> can then use the Discover Features Protocol to resolve version problems.</p> <p>Recipient agents should accept messages that differ from their own supported version of a protocol only in the patch, prerelease, and/or build fields, whether these differences make the message earlier or later than the version the recipient prefers. These messages will be robustly compatible.</p> <p>For major version &gt;= 1, recipients should also accept messages that differ only in that the message's minor version is earlier than their own preference. In such a case, the recipient should degrade gracefully to use the earlier version of the protocol. If the earlier version lacks important ../../features, the recipient may optionally choose to send, in addition to a response, a <code>problem-report</code> with code <code>version-with-degraded-../../features</code>.</p> <p>If a recipient supports protocol X version 1.0, it should tentatively accept messages with later minor versions (e.g., 1.2). Message types that differ in only in minor version are guaranteed to be compatible for the feature set of the earlier version. That is, a 1.0-capable agent can support 1.0 ../../features using a 1.2 message, though of course it will lose any ../../features that 1.2 added. Thus, accepting such a message could have two possible outcomes:</p> <ol> <li> <p>The message at version 1.2 might look and behave exactly like it did at version 1.0, in which case the message will process without any trouble.</p> </li> <li> <p>The message might contain some fields that are unrecognized and need to be ignored.</p> </li> </ol> <p>In case 2, it is best practice for the recipient to send a <code>problem-report</code> that is a warning, not an error, announcing that some fields could not be processed (code = <code>fields-ignored-due-to-version-mismatch</code>). Such a message is in addition to any response that the protocol demands of the recipient.</p> <p>If the recipient of a protocol's initial message generates a response, the response should use the latest major.minor protocol version that both parties support and know about. Generally, all messages after the first use only major.minor</p> <p></p>"},{"location":"aip2/0003-protocols/#state-details-and-state-machines","title":"State Details and State Machines","text":"<p>While some protocols have only one sequence of states to manage, in most different roles perceive the interaction differently. The sequence of states for each role needs to be described with care in the RFC.</p>"},{"location":"aip2/0003-protocols/#state-machines","title":"State Machines","text":"<p>By convention, protocol state and sequence rules are described using the concept of state machines, and we encourage developers who implement protocols to build them that way.</p> <p>Among other benefits, this helps with error handling: when one agent sends a <code>problem-report</code> message to another, the message can make it crystal clear which state it has fallen back to as a result of the error.</p> <p>Many developers will have encountered a formal of definition of state machines as they wrote parsers or worked on other highly demanding tasks, and may worry that state machines are heavy and intimidating. But as they are used in Aries protocols, state machines are straightforward and elegant. They cleanly encapsulate logic that would otherwise be a bunch of conditionals scattered throughout agent code. The tictactoe example protocol example includes a complete state machine in less than 50 lines of python code, with tests.</p> <p>For an extended discussion of how state machines can be used, including in nested protocols, and with hooks that let custom processing happen at each point in a flow, see https://github.com/dhh1128/distributed-state-machine.</p>"},{"location":"aip2/0003-protocols/#processing-points","title":"Processing Points","text":"<p>A protocol definition describes key points in the flow where business logic can attach. Some of these processing points are obvious, because the protocol makes calls for decisions to be made. Others are implicit. Some examples include:</p> <ul> <li>The beginning and end.</li> <li>The launch of a subprotocol.</li> <li>The completion of a subprotocol, or the subprotocol changing state.</li> <li>Sending a message. (For each send, the sender could choose to go silent and abandon the interaction instead, though many protocols would ask for notification to be emitted as best practice.)</li> <li>(Receiving a message_. (Requires validation, then integration with policy and processes internal to the agent and its sovereign domain, to move the interaction forward.)</li> </ul>"},{"location":"aip2/0003-protocols/#roles-participants-parties-and-controllers","title":"Roles, Participants, Parties, and Controllers","text":""},{"location":"aip2/0003-protocols/#roles","title":"Roles","text":"<p>The roles in a protocol are the perspectives (responsibilities, privileges) that parties take in an interaction.</p> <p>This perspective is manifested in three general ways:</p> <ul> <li>by the expectations that a party takes on in a protocol (ex. a role may be expected to do something to start a protocol).</li> <li>by the messages that a party can and does use in the course of the protocol (some messages may be reserved for a single role, while other may used by some if not all roles).</li> <li>by the state and the transition rules</li> </ul> <p>Like parties, roles are normally known at the start of the protocol but this is not a requirement.</p> <p>In an auction protocol, there are only two roles\u2014auctioneer and bidder\u2014even though there may be many parties involved.</p>"},{"location":"aip2/0003-protocols/#participants","title":"Participants","text":"<p>The participants in a protocol are the agents that send and/or receive plaintext application-level messages that embody the protocol's interaction. Alice, Bob, and Carol may each have a cloud agent, a laptop, and a phone; if they engage in an introduction protocol using phones, then the agents on their phones are the participants. If the phones talk directly over Bluetooth, this is particularly clear--but even if the phones leverage push notifications and HTTP such that cloud agents help with routing, only the phone agents are participants, because only they maintain state for the interaction underway. (The cloud agents would be facilitators, and the laptops would be bystanders). When a protocol is complete, the participant agents know about the outcome; they may need to synchronize or replicate their state before other agents of the parties are aware.</p>"},{"location":"aip2/0003-protocols/#parties","title":"Parties","text":"<p>The parties to a protocol are the entities directly responsible for achieving the protocol's goals. When a protocol is high-level, parties are typically people or organizations; as protocols become lower-level, parties may be specific agents tasked with detail work through delegation.</p> <p>Imagine a situation where Alice wants a vacation. She engages with a travel agent named Bob. Together, they begin an \"arrange a vacation\" protocol. Alice is responsible for expressing her parameters and proving her willingness to pay; Bob is responsible for running a bunch of subprotocols to work out the details. Alice and Bob--not software agents they use--are parties to this high-level protocol, since they share responsibility for its goals.</p> <p>As soon as Alice has provided enough direction and hangs up the phone, Bob begins a sub-protocol with a hotel to book a room for Alice. This sub-protocol has related but different goals--it is about booking a particular hotel room, not about the vacation as a whole. We can see the difference when we consider that Bob could abandon the booking and choose a different hotel entirely, without affecting the overarching \"arrange a vacation\" protocol.</p> <p>With the change in goal, the parties have now changed, too. Bob and a hotel concierge are the ones responsible for making the \"book a hotel room\" protocol progress. Alice is an approver and indirect stakeholder, but she is not doing the work. (In RACI terms, Alice is an \"accountable\" or \"approving\" entity, but only Bob and the concierge are \"responsible\" parties.)</p> <p>Now, as part of the hotel reservation, Bob tells the concierge that the guest would like access to a waverunner to play in the ocean on day 2. The concierge engages in a sub-sub-protocol to reserve the waverunner. The goal of this sub-sub-protocol is to reserve the equipment, not to book a hotel or arrange a vacation. The parties to this sub-sub-protocol are the concierge and the person or automated system that manages waverunners.</p> <p>Often, parties are known at the start of a protocol; however, that is not a requirement. Some protocols might commence with some parties not yet known or assigned.</p> <p>For many protocols, there are only two parties, and they are in a pairwise relationship. Other protocols are more complex. Introductions involves three; an auction may involve many.</p> <p>Normally, the parties that are involved in a protocol also participate in the interaction but this is not always the case. Consider a gossip protocol, two parties may be talking about a third party. In this case, the third party would not even know that the protocol was happening and would definitely not participate.</p>"},{"location":"aip2/0003-protocols/#controllers","title":"Controllers","text":"<p>The controllers in a protocol are entities that make decisions. They may or may not be direct parties.</p> <p>Imagine a remote chess game between Bob and Carol, conducted with software agents. The chess protocol isn't technically about how to select a wise chess move; it's about communicating the moves so parties achieve the shared goal of running a game to completion. Yet choices about moves are clearly made as the protocol unfolds. These choices are made by controllers--Bob and Carol--while the agents responsible for the work of moving the game forward wait with the protocol suspended.</p> <p>In this case, Bob and Carol could be analyzed as parties to the protocol, as well as controllers. But in other cases, the ../../concepts are distinct. For example, in a protocol to issue credentials, the issuing institution might use an AI and/or business automation as a controller.</p>"},{"location":"aip2/0003-protocols/#instructions-for-protocol-rfcs","title":"Instructions for Protocol RFCs","text":"<p>A protocol RFC conforms to general RFC patterns, but includes some specific substructure.</p> <p></p> <p>Please see the special protocol RFC template for details.</p>"},{"location":"aip2/0003-protocols/#drawbacks","title":"Drawbacks","text":"<p>This RFC creates some formalism around defining protocols. It doesn't go nearly as far as SOAP or CORBA/COM did, but it is slightly more demanding of a protocol author than the familiar world of RESTful Swagger/OpenAPI.</p> <p>The extra complexity is justified by the greater demands that agent-to-agent communications place on the protocol definition. See notes in Prior Art section for details.</p>"},{"location":"aip2/0003-protocols/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Some of the simplest DIDComm protocols could be specified in a Swagger/OpenAPI style. This would give some nice tooling. However, not all fit into that mold. It may be desirable to create conversion tools that allow Swagger interop.</p>"},{"location":"aip2/0003-protocols/#prior-art","title":"Prior art","text":""},{"location":"aip2/0003-protocols/#bpmn","title":"BPMN","text":"<p>BPMN (Business Process Model and Notation) is a graphical language for modeling flows of all types (plus things less like our protocols as well). BPMN is a mature standard sponsored by OMG(Object Management Group). It has a nice tool ecosystem (such as this). It also has an XML file format, so the visual diagrams have a two-way transformation to and from formal written language. And it has a code generation mode, where BPMN can be used to drive executable behavior if diagrams are sufficiently detailed and sufficiently standard. (Since BPMN supports various extensions and is often used at various levels of formality, execution is not its most common application.)</p> <p>BPMN began with a focus on centralized processes (those driven by a business entity), with diagrams organized around the goal of the point-of-view entity and what they experience in the interaction. This is somewhat different from a DIDComm protocol where any given entity may experience the goal and the scope of interaction differently; the state machine for a home inspector in the \"buy a home\" protocol is quite different, and somewhat separable, from the state machine of the buyer, and that of the title insurance company.</p> <p>BPMN 2.0 introduced the notion of a choreography, which is much closer to the concept of an A2A protocol, and which has quite an elegant and intuitive visual representation. However, even a BPMN choreography doesn't have a way to discuss interactions with decorators, adoption of generic messages, and other A2A-specific concerns. Thus, we may lean on BPMN for some diagramming tasks, but it is not a substitute for the RFC definition procedure described here.</p>"},{"location":"aip2/0003-protocols/#wsdl","title":"WSDL","text":"<p>WSDL (Web Services Description Language) is a web-centric evolution of earlier, RPC-style interface definition languages like IDL in all its varieties and CORBA. These technologies describe a called interface, but they don't describe the caller, and they lack a formalism for capturing state changes, especiall by the caller. They are also out of favor in the programmer community at present, as being too heavy, too fragile, or poorly supported by current tools.</p>"},{"location":"aip2/0003-protocols/#swagger-openapi","title":"Swagger / OpenAPI","text":"<p>Swagger / OpenAPI overlaps with some of the concerns of protocol definition in agent-to-agent  interactions. We like the tools and the convenience of the paradigm  offered by OpenAPI, but where these two do not overlap, we have impedance.</p> <p>Agent-to-agent protocols must support more than 2 roles, or  two roles that are peers, whereas RESTful web services assume just client  and server--and only the server has a documented API.</p> <p>Agent-to-agent protocols are fundamentally asynchronous,  whereas RESTful web services mostly assume synchronous request~response.</p> <p>Agent-to-agent protocols have complex considerations for diffuse trust,  whereas RESTful web services centralize trust in the web server.</p> <p>Agent-to-agent protocols need to support transports beyond HTTP, whereas  RESTful web services do not.</p> <p>Agent-to-agent protocols are nestable, while  RESTful web services don't provide any special support for that construct.</p>"},{"location":"aip2/0003-protocols/#other","title":"Other","text":"<ul> <li>Pdef (Protocol Definition Language): An alternative to Swagger.</li> <li>JSON RPC: Defines how invocation of  remote methods can be accomplished by passing JSON messages. However, the  RPC paradigm assumes request/response pairs, and does not provide a way  to describe state and roles carefully.</li> <li>IPC Protocol Definition Language (IPDL):  This is much closer to agent protocols in terms of its scope of concerns  than OpenAPI. However, it is C++ only, and intended for use within browser  plugins.</li> </ul>"},{"location":"aip2/0003-protocols/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Should we write a Swagger translator?</li> <li>If not swagger, what formal definition format should we use in the future?</li> </ul>"},{"location":"aip2/0003-protocols/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python several protocols, circa Feb 2019 Aries Framework - .NET several protocols, circa Feb 2019 Streetcred.id several protocols, circa Feb 2019 Aries Cloud Agent - Python numerous protocols plus extension mechanism for pluggable protocols Aries Static Agent - Python 2 or 3 protocols Aries Framework - Go DID Exchange Connect.Me mature but proprietary protocols; community protocols in process Verity mature but proprietary protocols; community protocols in process Aries Protocol Test Suite 2 or 3 core protocols; active work to implement all that are ACCEPTED, since this tests conformance of other agents Pico Labs implemented protocols: connections, trust_ping, basicmessage, routing"},{"location":"aip2/0003-protocols/roles-participants-etc/","title":"Roles participants etc","text":""},{"location":"aip2/0003-protocols/roles-participants-etc/#roles-participants-parties-and-controllers","title":"Roles, Participants, Parties, and Controllers","text":""},{"location":"aip2/0003-protocols/roles-participants-etc/#roles","title":"Roles","text":"<p>The roles in a protocol are the perspectives (responsibilities, privileges) that parties take i an interaction.</p> <p>This perspective is manifested in three general ways:</p> <ul> <li>by the expectations that a party takes on in a protocol (ex. a role may be expected to do something to start a protocol).</li> <li>by the messages that a party can and does use in the course of the protocol (some messages may be reserved for a single role, while other may used by some if not all roles).</li> <li>by the state and the transition rules</li> </ul> <p>Like parties, roles are normally known at the start of the protocol but this is not a requirement.</p> <p>In an auction protocol, there are only two roles\u2014auctioneer and bidder\u2014even though there may be many parties involved.</p>"},{"location":"aip2/0003-protocols/roles-participants-etc/#participants","title":"Participants","text":"<p>The participants in a protocol are the agents that send and/or receive plaintext application-level messages that embody the protocol's interaction. Alice, Bob, and Carol may each have a cloud agent, a laptop, and a phone; if they engage in an introduction protocol using phones, then the agents on their phones are the participants. If the phones talk directly over Bluetooth, this is particularly clear--but even if the phones leverage push notifications and HTTP such that cloud agents help with routing, only the phone agents are participants, because only they maintain state for the interaction underway. (The cloud agents would be facilitators, and the laptops would be bystanders). When a protocol is complete, the participant agents know about the outcome; they may need to synchronize or replicate their state before other agents of the parties are aware.</p>"},{"location":"aip2/0003-protocols/roles-participants-etc/#parties","title":"Parties","text":"<p>The parties to a protocol are the entities directly responsible for achieving the protocol's goals. When a protocol is high-level, parties are typically people or organizations; as protocols become lower-level, parties may be specific agents tasked with detail work through delegation.</p> <p>Imagine a situation where Alice wants a vacation. She engages with a travel agent named Bob. Together, they begin an \"arrange a vacation\" protocol. Alice is responsible for expressing her parameters and proving her willingness to pay; Bob is responsible for running a bunch of subprotocols to work out the details. Alice and Bob--not software agents they use--are parties to this high-level protocol, since they share responsibility for its goals.</p> <p>As soon as Alice has provided enough direction and hangs up the phone, Bob begins a sub-protocol with a hotel to book a room for Alice. This sub-protocol has related but different goals--it is about booking a particular hotel room, not about the vacation as a whole. We can see the difference when we consider that Bob could abandon the booking and choose a different hotel entirely, without affecting the overarching \"arrange a vacation\" protocol.</p> <p>With the change in goal, the parties have now changed, too. Bob and a hotel concierge are the ones responsible for making the \"book a hotel room\" protocol progress. Alice is an approver and indirect stakeholder, but she is not doing the work. (In RACI terms, Alice is an \"accountable\" or \"approving\" entity, but only Bob and the concierge are \"responsible\" parties.)</p> <p>Now, as part of the hotel reservation, Bob tells the concierge that the guest would like access to a waverunner to play in the ocean on day 2. The concierge engages in a sub-sub-protocol to reserve the waverunner. The goal of this sub-sub-protocol is to reserve the equipment, not to book a hotel or arrange a vacation. The parties to this sub-sub-protocol are the concierge and the person or automated system that manages waverunners.</p> <p>Often, parties are known at the start of a protocol; however, that is not a requirement. Some protocols might commence with some parties not yet known or assigned.</p> <p>For many protocols, there are only two parties, and they are in a pairwise relationship. Other protocols are more complex. Introductions involves three; an auction may involve many.</p> <p>Normally, the parties that are involved in a protocol also participate in the interaction but this is not always the case. Consider a gossip protocol, two parties may be talking about a third party. In this case, the third party would not even know that the protocol was happening and would definitely not participate.</p>"},{"location":"aip2/0003-protocols/roles-participants-etc/#controllers","title":"Controllers","text":"<p>The controllers in a protocol are entities that make decisions. They may or may not be direct parties.</p> <p>Imagine a remote chess game between Bob and Carol, conducted with software agents. The chess protocol isn't technically about how to select a wise chess move; it's about communicating the moves so parties achieve the shared goal of running a game to completion. Yet choices about moves are clearly made as the protocol unfolds. These choices are made by controllers--Bob and Carol--while the agents responsible for the work of moving the game forward wait with the protocol suspended.</p> <p>In this case, Bob and Carol could be analyzed as parties to the protocol, as well as controllers. But in other cases, the concepts are distinct. For example, in a protocol to issue credentials, the issuing institution might use an AI and/or business automation as a controller.</p>"},{"location":"aip2/0003-protocols/tictactoe/","title":"Tic Tac Toe Protocol 1.0","text":""},{"location":"aip2/0003-protocols/tictactoe/#summary","title":"Summary","text":"<p>Describes a simple protocol, already familiar to most developers, as a way to demonstrate how all protocols should be documented.</p>"},{"location":"aip2/0003-protocols/tictactoe/#motivation","title":"Motivation","text":"<p>Playing tic-tac-toe is a good way to test whether agents are working properly, since it requires two parties to take turns and to communicate reliably about state. However, it is also pretty simple, and it has a low bar for trust (it's not dangerous to play tic-tac-toe with a malicious stranger). Thus, we expect agent tic-tac-toe to be a good way to test basic plumbing and to identify functional gaps. The game also provides a way of testing interactions with the human owners of agents, or of hooking up an agent AI.</p>"},{"location":"aip2/0003-protocols/tictactoe/#tutorial","title":"Tutorial","text":"<p>Tic-tac-toe is a simple game where players take turns placing Xs and Os in a 3x3 grid, attempting to capture 3 cells of the grid in a straight line.</p>"},{"location":"aip2/0003-protocols/tictactoe/#name-and-version","title":"Name and Version","text":"<p>This defines the <code>tictactoe</code> protocol, version 1.x, as identified by the following PIURI:</p> <pre><code>did:sov:SLfEi9esrjzybysFxQZbfq;spec/tictactoe/1.0\n</code></pre>"},{"location":"aip2/0003-protocols/tictactoe/#key-concepts","title":"Key Concepts","text":"<p>A tic-tac-toe game is an interaction where 2 parties take turns to make up to 9 moves. It starts when either party proposes the game, and ends when one of the parties wins, or when all all cells in the grid are occupied but nobody has won (a draw).</p> <p>Note: Optionally, a Tic-Tac-Toe game can be preceded by a Coin Flip Protocol to decide who goes first. This is not a high-value enhancement, but we add it for illustration purposes. If used, the <code>choice-id</code> field in the initial <code>propose</code> message of the Coin Flip should have the value <code>did:sov:SLfEi9esrjzybysFxQZbfq;spec/tictactoe/1.0/who-goes-first</code>, and the <code>caller-wins</code> and <code>flipper-wins</code> fields should contain the DIDs of the two players.</p> <p>Illegal moves and moving out of turn are errors that trigger a complaint from the other player. However, they do not scuttle the interaction. A game can also be abandoned in an unfinished state by either player, for any reason. Games can last any amount of time.</p> <pre><code>About the Key Concepts section: Here we describe the flow at a very\nhigh level. We identify preconditions, ways the protocol can start\nand end, and what can go wrong. We also talk about timing\nconstraints and other assumptions.\n</code></pre>"},{"location":"aip2/0003-protocols/tictactoe/#roles","title":"Roles","text":"<p>There are two parties in a tic-tac-toe game, but only one role, <code>player</code>. One player places 'X' for the duration of a game; the other places 'O'. There are no special requirements about who can be a player. The parties do not need to be trusted or even known to one another, either at the outset or as the game proceeds. No prior setup is required, other than an ability to communicate.</p> <pre><code>About the Roles section: Here we name the roles in the protocol,\nsay who and how many can play each role, and describe constraints.\nWe also explore qualifications for roles.\n</code></pre>"},{"location":"aip2/0003-protocols/tictactoe/#states","title":"States","text":"<p>The states of each <code>player</code> in the protocol evolve according to the following state machine:</p> <p></p> <p>When a player is in the <code>my-move</code> state, possible valid events include <code>send move</code> (the normal case), <code>send outcome</code> (if the player decides to abandon the game), and <code>receive outcome</code> (if the other player decides to abandon). A <code>receive move</code> event could conceivably occur, too-- but it would be an error on the part of the other player, and would trigger a <code>problem-report</code> message as described above, leaving the state unchanged.</p> <p>In the <code>their-move</code> state, <code>send move</code> is an impossible event for a properly behaving player. All 3 of the other events could occur, causing a state transition.</p> <p>In the <code>wrap-up</code> state, the game is over, but communication with the outcome message has not yet occurred. The logical flow is <code>send outcome</code>, whereupon the player transitions to the <code>done</code> state.</p> <pre><code>About the States section: Here we explain which states exist for each\nrole. We also enumerate the events that can occur, including messages,\nerrors, or events triggered by surrounding context, and what should\nhappen to state as a result. In this protocol, we only have one role,\nand thus only one state machine matrix. But in many protocols, each\nrole may have a different state machine.\n</code></pre>"},{"location":"aip2/0003-protocols/tictactoe/#messages","title":"Messages","text":"<p>All messages in this protocol are part of the \"tictactoe 1.0\" message family uniquely identified by this DID reference: <code>did:sov:SLfEi9esrjzybysFxQZbfq;spec/tictactoe/1.0</code></p> NOTE 1: All the messages defined in a protocol should follow  DIDComm best practices as far as how they name fields and define their data types and semantics.  NOTE 2 about the \"DID Reference\" URI that appears here: DIDs can be resolved     to a DID doc that contains an endpoint, to which everything after a     semicolon can be appended. Thus, if this DID is publicly registered     and its DID doc gives an endpoint of http://example.com, this URI     would mean that anyone can find a formal definition of the protocol at     http://example.com/spec/tictactoe/1.0. It is also possible to use a     traditional URI here, such as http://example.com/spec/tictactoe/1.0.     If that sort of URI is used, it is best practice for it to reference     immutable content, as with a link to specific commit on github:       https://github.com/hyperledger/aries-rfcs/blob/ab7a04f/concepts/0003-protocols/tictactoe/README.md#messages"},{"location":"aip2/0003-protocols/tictactoe/#move-message","title":"<code>move</code> message","text":"<p>The protocol begins when one party sends a <code>move</code> message to the other. It looks like this:</p> <p></p> <p><code>@id</code> is required here, as it establishes a message thread that will govern the rest of the game.</p> <p><code>me</code> tells which mark (X or O) the sender is placing. It is required.</p> <p><code>moves</code> is optional in the first message of the interaction. If missing or empty, the sender of the first message is inviting the recipient to make the first move. If it contains a move, the sender is moving first.</p> <p>Moves are strings like \"X:B2\" that match the regular expression <code>(?i)[XO]:[A-C][1-3]</code>. They identify a mark to be placed (\"X\" or \"O\") and a position in the 3x3 grid. The grid's columns and rows are numbered like familiar spreadsheets, with columns A, B, and C, and rows 1, 2, and 3.</p> <p><code>comment</code> is optional and probably not used much, but could be a way for players to razz one another or chat as they play. It follows the conventions of localized messages.</p> <p>Other decorators could be placed on tic-tac-toe messages, such as those to enable message timing to force players to make a move within a certain period of time.</p>"},{"location":"aip2/0003-protocols/tictactoe/#subsequent-moves","title":"Subsequent Moves","text":"<p>Once the initial <code>move</code> message has been sent, game play continues by each player taking turns sending responses, which are also <code>move</code> messages. With each new message the <code>move</code> array inside the message grows by one, ensuring that the players agree on the current accumulated state of the game. The <code>me</code> field is still required and must accurately reflect the role of the message sender; it thus alternates values between <code>X</code> and <code>O</code>.</p> <p>Subsequent messages in the game use the message threading mechanism where the <code>@id</code> of the first <code>move</code> becomes the <code>~thread.thid</code> for the duration of the game.</p> <p>An evolving sequence of <code>move</code> messages might thus look like this, suppressing all fields except what's required:</p>"},{"location":"aip2/0003-protocols/tictactoe/#messagemove-2","title":"Message/Move 2","text":"<p>This is the first message in the thread that's sent by the <code>player</code> placing \"O\"; hence it has <code>myindex</code> = 0.</p>"},{"location":"aip2/0003-protocols/tictactoe/#messagemove-3","title":"Message/Move 3","text":"<p>This is the second message in the thread by the player placing \"X\"; hence it has <code>myindex</code> = 1.</p>"},{"location":"aip2/0003-protocols/tictactoe/#messagemove-4","title":"Message/Move 4","text":"<p>...and so forth.</p> <p>Note that the order of the items in the <code>moves</code> array is NOT significant. The state of the game at any given point of time is fully captured by the moves, regardless of the order in which they were made.</p> <p>If a player makes an illegal move or another error occurs, the other player can complain using a problem-report message, with <code>explain.@l10n.code</code> set to one of the values defined in the Message Catalog section (see below).</p>"},{"location":"aip2/0003-protocols/tictactoe/#outcome-message","title":"<code>outcome</code> message","text":"<p>Game play ends when one player sends a <code>move</code> message that manages to mark 3 cells in a row. Thereupon, it is best practice, but not strictly required, for the other player to send an acknowledgement in the form of an <code>outcome</code> message.</p> <p></p> <p>The <code>moves</code> and <code>me</code> fields from a <code>move</code> message can also, optionally, be included to further document state. The <code>winner</code> field is required. Its value may be \"X\", \"O\", or--in the case of a draw--\"none\".</p> <p>This <code>outcome</code> message can also be used to document an abandoned game, in which case <code>winner</code> is <code>null</code>, and <code>comment</code> can be used to explain why (e.g., timeout, loss of interest).</p> <pre><code>About the Messages section: Here we explain the message types, but\nalso which roles send which messages, what sequencing rules apply,\nand how errors may occur during the flow. The message begins with\nan announcement of the identifier and version of the message\nfamily, and also enumerates error codes to be used with problem\nreports. This protocol is simple enough that we document the\ndatatypes and validation rules for fields inline in the narrative;\nin more complex protocols, we'd move that text into the Reference\n&gt; Messages section instead.\n</code></pre>"},{"location":"aip2/0003-protocols/tictactoe/#constraints","title":"Constraints","text":"<p>Players do not have to trust one another. Messages do not have to be authcrypted, although anoncrypted messages still have to have a path back to the sender to be useful.</p> <pre><code>About the Constraints section: Many protocols have rules\nor mechanisms that help parties build trust. For example, in buying\na house, the protocol includes such things as commission paid to\nrealtors to guarantee their incentives, title insurance, earnest\nmoney, and a phase of the process where a home inspection takes\nplace. If you are documenting a protocol that has attributes like\nthese, explain them here.\n</code></pre>"},{"location":"aip2/0003-protocols/tictactoe/#reference","title":"Reference","text":"<pre><code>About the Reference section: If the Tutorial &gt; Messages section\nsuppresses details, we would add a Messages section here to\nexhaustively describe each field. We could also include an\nExamples section to show variations on the main flow.\n</code></pre>"},{"location":"aip2/0003-protocols/tictactoe/#collateral","title":"Collateral","text":"<p>A reference implementation of the logic of a game is provided with this RFC as python 3.x code. See game.py. There is also a simple hand-coded AI that can play the game when plugged into an agent (see ai.py), and a set of unit tests that prove correctness (see test_tictactoe.py).</p> <p>A full implementation of the state machine is provided as well; see state_machine.py and test_state_machine.py.</p> <p>The game can be played interactively by running <code>python game.py</code>.</p>"},{"location":"aip2/0003-protocols/tictactoe/#localization","title":"Localization","text":"<p>The only localizable field in this message family is <code>comment</code> on both <code>move</code> and <code>outcome</code> messages. It contains ad hoc text supplied by the sender, instead of a value selected from an enumeration and identified by <code>code</code> for use with message catalogs. This means the only approach to localize <code>move</code> or <code>outcome</code> messages is to submit <code>comment</code> fields to an automated translation service. Because the locale of <code>tictactoe</code> messages is not predefined, each message must be decorated with <code>~l10n.locale</code> to make automated translation possible.</p> <p>There is one other way that localization is relevant to this protocol: in error messages. Errors are communicated through the general problem-report message type rather than through a special message type that's part of the <code>tictactoe</code> family. However, we define a catalog of tictactoe-specific error codes below to make this protocol's specific error strings localizable. </p> <p>Thus, all instances of this message family carry localization metadata in the form of an implicit <code>~l10n</code> decorator that looks like this:</p> <p></p> <p>This JSON fragment is checked in next to the narrative content of this RFC as ~l10n.json, for easy machine parsing.</p> <p>Individual messages can use the <code>~l10n</code> decorator to supplement or override these settings.</p> <p>For more information about localization concepts, see the RFC about localized messages.</p>"},{"location":"aip2/0003-protocols/tictactoe/#message-catalog","title":"Message Catalog","text":"<p>To facilitate localization of error messages, all instances of this message family assume the following catalog in their <code>~l10n</code> data:</p> <p></p> <p>When referencing this catalog, please be sure you have the correct version. The official, immutable URL to this version of the catalog file is:</p> <pre><code>https://github.com/hyperledger/indy-hipe/blob/fc7a6028/text/tictactoe-protocol/catalog.json\n</code></pre> <p>This JSON fragment is checked in next to the narrative content of this RFC as catalog.json, for easy machine parsing. The catalog currently contains localized alternatives only for English. Other language contributions would be welcome.</p> <p>For more information, see the Message Catalog section of the localization HIPE.</p>"},{"location":"aip2/0003-protocols/tictactoe/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Verity Commercially licensed enterprise agent, SaaS or on-prem. Pico Labs Open source TicTacToe for Pico Agents"},{"location":"aip2/0004-agents/","title":"Aries RFC 0004: Agents","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2019-01-15</li> <li>Status Note: On a standards track and beginning to influence many mental models, but not yet ADOPTED. </li> <li>Supersedes: Indy HIPE 0002</li> <li>Start Date: 2017-11-01 (approx, backdated)</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0004-agents/#summary","title":"Summary","text":"<p>Provide a high-level introduction to the ../../concepts of agents in the self-sovereign identity ecosystem.</p>"},{"location":"aip2/0004-agents/#tutorial","title":"Tutorial","text":"<p>Managing an identity is complex. We need tools to help us.</p> <p>In the physical world, we often delegate complexity to trusted proxies that can help. We hire an accountant to do our taxes, a real estate agent to help us buy a house, and a talent agent to help us pitch an album to a recording studio.</p> <p>On the digital landscape, humans and organizations (and sometimes, things) cannot directly consume and emit bytes, store and manage data, or perform the crypto that self-sovereign identity demands. They need delegates--agents--to help. Agents are a vital dimension across which we exercise sovereignty over identity.</p> <p></p>"},{"location":"aip2/0004-agents/#essential-characteristics","title":"Essential Characteristics","text":"<p>When we use the term \"agent\" in the SSI community, we more properly mean \"an agent of self-sovereign identity.\" This means something more specific than just a \"user agent\" or a \"software agent.\" Such an agent has three defining characteristics:</p> <ol> <li>It acts as a fiduciary on behalf of a single identity owner (or, for agents of things like IoT devices, pets, and similar things, a single controller).</li> <li>It holds cryptographic keys that uniquely embody its delegated authorization.</li> <li>It interacts using interoperable DIDComm protocols.</li> </ol> <p>These characteristics don't tie an agent to any particular blockchain. It is possible to implement agents without any use of blockchain at all (e.g., with peer DIDs), and some efforts to do so are quite active.</p>"},{"location":"aip2/0004-agents/#canonical-examples","title":"Canonical Examples","text":"<p>Three types of agents are especially common:</p> <ol> <li>A mobile app that Alice uses to manage credentials and to connect to others is an agent for Alice.</li> <li>A cloud-based service that Alice uses to expose a stable endpoint where other agents can talk to her is an agent for Alice.</li> <li>A server run by Faber College, allowing it to issue credentials to its students, is an agent for Faber.</li> </ol> <p>Depending on your perspective, you might describe these agents in various ways. #1 can correctly be called a \"mobile\" or \"edge\" or \"rich\" agent. #2 can be called a \"cloud\" or \"routing\" agent. #3 can be called an \"on-prem\" or \"edge\" or \"advanced\" agent. See Categorizing Agents for a discussion about why multiple labels are correct.</p> <p>Agents can be other things as well. They can big or small, complex or simple. They can interact and be packaged in various ways.  They can be written in a host of programming languages. Some are more canonical than others. But all the ones we intend to interact with in the self-sovereign identity problem domain share the three essential characteristics described above.</p>"},{"location":"aip2/0004-agents/#how-agents-talk","title":"How Agents Talk","text":"<p>DID communication (DIDComm), and the protocols built atop it are each rich subjects unto themselves. Here, we will stay very high-level.</p> <p>Agents can use many different communication transports: HTTP(S) 1.x and 2.0, WebSockets, IRC, Bluetooth, AMQP, NFC, Signal, email, push notifications to mobile devices, ZMQ, and more. However, all A2A is message-based, and is secured by modern, best-practice public key cryptography. How messages flow over a transport may vary--but their security and privacy toolset, their links to the DIDs and DID Docs of identity owners, and the ways their messages are packaged and handled are standard.</p> <p>Agents connect to one another through a standard connection protocol, discover one another's endpoints and keys through standard DID Docs, discover one another's ../../features in a standard way, and maintain relationships in a standard way. All of these points of standardization are what makes them interoperable.</p> <p>Because agents speak so many different ways, and because many of them won't have a permanent, accessible point of presence on the network, they can't all be thought of as web servers with a Swagger-compatible API for request-response. The analog to an API construct in agent-land is protocols. These are patterns for stateful interactions. They specify things like, \"If you want to negotiate a sale with an agent, send it a message of type X. It will respond with a message of type Y or type Z, or with an error message of type W. Repeat until the negotiation finishes.\" Some interesting A2A protocols include the one where two parties connect to one another to build a relationship, the one where agents discover which protocols they each support, the one where credentials are issued, and the one where proof is requested and sent. Hundreds of other protocols are being defined.</p>"},{"location":"aip2/0004-agents/#how-to-get-an-agent","title":"How to Get an Agent","text":"<p>As the ecosystem for self-sovereign identity matures, the average person or organization will get an agent by downloading it from the app store, installing it with their OS package manager, or subscribing to it as a service. However, the availability of quality pre-packaged agents is still limited today.</p> <p>Agent providers are emerging in the marketplace, though. Some are governments, NGOs, or educational institutions that offer agents for free; others are for-profit ventures. If you'd like suggestions about ready-to-use agent offerings, please describe your use case in <code>#aries</code> on chat.hyperledger.org.</p> <p>There is also intense activity in the SSI community around building custom agents and the tools and processes that enable them. A significant amount of early work occurred in the Indy Agent Community with some of those efforts materializing in the indy-agent repo on github.com and other code bases. The indy-agent repo is now deprecated but is still valuable in demonstrating the basics of agents. With the introduction of Hyperledger Aries, agent efforts are migrating from the Indy Agent community.</p> <p>Hyperledger Aries provides a number of code bases ranging from agent frameworks to tools to aid in development to ready-to-use agents.</p>"},{"location":"aip2/0004-agents/#how-to-write-an-agent","title":"How to Write an Agent","text":"<p>This is one of the most common questions that Aries newcomers ask. It's a challenging one to answer, because it's so open-ended. It's sort of like someone asking, \"Can you give me a recipe for dinner?\" The obvious follow-up question would be, \"What type of dinner did you have in mind?\"</p> <p>Here are some thought questions to clarify intent:</p> <ul> <li>Do you need an agent for people or institutions (or an IoT thing)?</li> <li>Will the agent run on a mobile device, in a cloud, on a server,   or elsewhere?</li> <li>Will the agent be on and connected to the internet constantly, or   will it run only from time to time?</li> <li>Which protocols should your agent implement? (In other words, what   sort of work do you want to delegate to it?)</li> <li>Will your agent talk, listen, or both? What channels/transports   will it use?</li> <li>What interesting requirements does your agent have with respect to   security, privacy, scale, and performance?</li> </ul>"},{"location":"aip2/0004-agents/#general-patterns","title":"General Patterns","text":"<p>We said it's hard to provide a recipe for an agent without specifics. However, the majority of agents do have two things in common: they listen to and process A2A messages, and they use a wallet to manage keys, credentials, and other sensitive material. Unless you have uses cases that involve IoT, cron jobs, or web hooks, your agent is likely to fit this mold.</p> <p>The heart of such an agent is probably a messaging handling loop, with pluggable protocols to give it new capabilities, and pluggable transports to let it talk in different ways. The pseudocode for its main function might look like this:</p>"},{"location":"aip2/0004-agents/#pseudocode-for-main","title":"Pseudocode for main()","text":"<pre><code>1  While not done:\n2      Get next message.\n3      Verify it (decrypt, identify sender, check signature...).\n3      Look at the type of the plaintext message.\n4      Find a plugged in protocol handler that matches that type.\n5      Give plaintext message and security metadata to handler.\n</code></pre> <p>Line 2 can be done via standard HTTP dispatch, or by checking an email inbox, or in many other ways. Line 3 can be quite sophisticated--the sender will not be Alice, but rather one of the agents that she has authorized. Verification may involve consulting cached information and/or a blockchain where a DID and DID Doc are stored, among other things.</p> <p>The pseudocode for each protocol handler it loads might look like:</p>"},{"location":"aip2/0004-agents/#pseudocode-for-protocol-handler","title":"Pseudocode for protocol handler","text":"<pre><code>1  Check authorization against metadata. Reject if needed.\n2  Read message header. Is it part of an ongoing interaction?\n3  If yes, load persisted state.\n4  Process the message and update interaction state.\n5  If a response is appropriate:\n6      Prepare response content.\n7      Ask my outbound comm module to package and send it.\n</code></pre> <p>Line 4 is the workhorse. For example, if the interaction is about issuing credentials and this agent is doing the issuance, this would be where it looks up the material for the credential in internal databases, formats it appropriately, and records the fact that the credential has now been built. Line 6 might be where that credential is attached to an outgoing message for transmission to the recipient.</p> <p>The pseudocode for the outbound communication module might be:</p>"},{"location":"aip2/0004-agents/#pseudocode-for-outbound","title":"Pseudocode for outbound","text":"<pre><code>1  Iterate through all pluggable transports to find best one to use\n     with the intended recipient.\n2  Figure out how to route the message over the selected transport.\n3  Serialize the message content and encrypt it appropriately.\n4  Send the message.\n</code></pre> <p>Line 2 can be complex. It involves looking up one or more endpoints in the DID Doc of the recipient, and finding an intersection between transports they use, and transports the sender can speak. Line 3 requires the keys of the sender, which would normally be held in a wallet.</p> <p>If you are building this sort of code using Aries technology, you will certainly want to use Aries Agent SDK. This gives you a ready-made, highly secure wallet that can be adapted to many requirements. It also provides easy functions to serialize and encrypt. Many of the operations you need to do are demonstrated in the SDK's /doc/how-tos folder, or in its Getting Started Guide.</p>"},{"location":"aip2/0004-agents/#how-to-learn-more","title":"How to Learn More","text":"<ul> <li>Hang out and ask questions on <code>#aries</code> on chat.hyperledger.org.</li> <li>Use the mailing list: aries@lists.hyperledger.org</li> <li>Follow the Aries Cloud Agent - Python Getting Started Guide (for developers)</li> <li>Study the Aries Protocol Test Suite |</li> <li>Study the sample mobile agent at github.com/sovrin-foundation/connector-app.</li> <li>Browse other RFCs.</li> <li>Attend the Aries working group on Wednesdays. (See HL community calendar for details; note that the default timezone is GMT.)</li> <li>Review this slide deck   about integrating agents with familiar web development paradigms.</li> </ul>"},{"location":"aip2/0004-agents/#reference","title":"Reference","text":""},{"location":"aip2/0004-agents/#categorizing-agents","title":"Categorizing Agents","text":"<p>Agents can be categorized in various ways, and these categories lead to terms you're likely to encounter in RFCs and other documentation. Understanding the categories will help the definitions make sense.</p>"},{"location":"aip2/0004-agents/#by-trust","title":"By Trust","text":"<p>A trustable agent runs in an environment that's under the direct control of its owner; the owner can trust it without incurring much risk. A semi-trustable agent runs in an environment where others besides the owner may have access, so giving it crucial secrets is less advisable. (An untrustable delegate should never be an agent, by definition, so we don't use that term.)</p> <p>Note that these distinctions highlight what is advisable, not how much trust the owner actually extends.</p>"},{"location":"aip2/0004-agents/#by-location","title":"By Location","text":"<p>Two related but deprecated terms are edge agent and cloud agent. You will probably hear these terms in the community or read them in docs. The problem with them is that they suggest location, but were formally defined to imply levels of trust. When they were chosen, location and levels of trust were seen as going together--you trust your edge more, and your cloud less. We've since realized that a trustable agent could exist in the cloud, if it is directly controlled by the owner, and a semi-trustable agent could be on-prem, if the owner's control is indirect. Thus we are trying to correct usage and make \"edge\" and \"cloud\" about location instead.</p>"},{"location":"aip2/0004-agents/#by-platform","title":"By Platform","text":"<ul> <li>Mobile -- likely trustable</li> <li>Workstation -- likely trustable</li> <li>Server -- could be trustable or semi-trustable</li> <li>Embedded -- trustable or semi-trustable</li> <li>Browser (web assembly or javascript) -- likely semi-trustable</li> <li>Blockchain (embodied in smart contract -- trustable?)</li> <li>Mesh (IoT\u2026)</li> <li>Paper?</li> </ul>"},{"location":"aip2/0004-agents/#by-complexity","title":"By Complexity","text":"<p>We can arrange agents on a continuum, from simple to complex. The simplest agents are static--they are preconfigured for a single relationship. Thin agents are somewhat fancier. Thick agents are fancier still, and rich agents exhibit the most sophistication and flexibility:</p> <p></p> <p>A nice visualization of several dimensions of agent category has been built by Michael Herman:</p> <p></p>"},{"location":"aip2/0004-agents/#the-agent-ness-continuum","title":"The Agent-ness Continuum","text":"<p>The tutorial above gives three essential characteristics of agents, and lists some canonical examples. This may make it feel like agent-ness is pretty binary. However, we've learned that reality is more fuzzy.</p> <p>Having a tight definition of an agent may not matter in all cases. However, it is important when we are trying to understand interoperability goals. We want agents to be able to interact with one another. Does that mean they must interact with every piece of software that is even marginally agent-like? Probably not.</p> <p>Some attributes that are not technically necessary in agents include:</p> <ul> <li>Has a wallet (common, but not universal)</li> <li>Establishes new connections (some may use only a small set of preconfigured connections)</li> <li>Exchanges credentials and proofs (some may not use these protocols)</li> <li>Both listens and talks (some may only listen or only talk)</li> </ul> <p>Agents that lack these characteristics can still be fully interoperable.</p> <p>Some interesting examples of less prototypical agents or agent-like things include:</p>"},{"location":"aip2/0004-agents/#dif-hubs","title":"DIF Hubs","text":"<p>A DIF Identity Hub is construct that resembles agents in some ways, but that focuses on the data-sharing aspects of identity. Currently DIF Hubs do not use the protocols known to the Aries community, and vice versa. However, there are efforts to bridge that gap.</p>"},{"location":"aip2/0004-agents/#identity-wallets","title":"Identity Wallets","text":"<p>\"Identity wallet\" is a term that's carefully defined in our ecosystem, and in strict, technical usage it maps to a concept much closer to \"database\" than \"agent\". This is because it is an inert storage container, not an active interacter. However, in casual usage, it may mean the software that uses a wallet to do identity work--in which case it is definitely an agent.</p>"},{"location":"aip2/0004-agents/#crypto-wallets","title":"Crypto Wallets","text":"<p>Cryptocurrency wallets are quite agent-like in that they hold keys and represent a user. However, they diverge from the agent definition in that they talk proprietary protocols to blockchains, rather than A2A to other agents.</p>"},{"location":"aip2/0004-agents/#uport","title":"uPort","text":"<p>The uPort app is an edge agent. Here, too, there are efforts to bridge a protocol gap.</p>"},{"location":"aip2/0004-agents/#learning-machine","title":"Learning Machine","text":"<p>The credential issuance technology offered by Learning Machine, and the app used to share those credentials, are agents of institutions and individuals, respectively. Again, there is a protocol gap to bridge.</p>"},{"location":"aip2/0004-agents/#cron-jobs","title":"Cron Jobs","text":"<p>A cron job that runs once a night at Faber, scanning a database and revoking credentials that have changes status during the day, is an agent for Faber. This is true even though it doesn't listen for incoming messages (it only talks revocation protocol to the ledger). In order to talk that protocol, it must hold keys delegated by Faber, and it is surely Faber's fiduciary.</p>"},{"location":"aip2/0004-agents/#operating-systems","title":"Operating Systems","text":"<p>The operating system on a laptop could be described as agent-like, in that it works for a single owner and may have a keystore. However, it doesn't talk A2A to other agents--at least not yet. (OSes that service multiple users fit the definition less.)</p>"},{"location":"aip2/0004-agents/#devices","title":"Devices","text":"<p>A device can be thought of as an agent (e.g., Alice's phone as an edge agent). However, strictly speaking, one device might run multiple agents, so this is only casually correct.</p>"},{"location":"aip2/0004-agents/#sovrin-mainnet","title":"Sovrin MainNet","text":"<p>The Sovrin MainNet can be thought of as an agent for the Sovrin community (but NOT the Sovrin Foundation, which codifies the rules but leaves operation of the network to its stewards). Certainly, the blockchain holds keys, uses A2A protocols, and acts in a fiduciary capacity toward the community to further its interests. The only challenge with this perspective is that the Sovrin community has a very fuzzy identity.</p>"},{"location":"aip2/0004-agents/#validators","title":"Validators","text":"<p>Validator nodes on a particular blockchain are agents of the stewards that operate them.</p>"},{"location":"aip2/0004-agents/#digital-assistants","title":"Digital Assistants","text":"<p>Digital assistants like Alexa and Google Home are somewhat agent-like. However, the Alexa in the home of the Jones family is probably not an agent for either the Jones family or Amazon. It accepts delegated work from anybody who talks to it (instead of a single controlling identity), and all current implementations are totally antithetical to the ethos of privacy and security required by self-sovereign identity. Although it interfaces with Amazon to download data and ../../features, it isn't Amazon's fiduciary, either. It doesn't hold keys that allow it to represent its owner. The protocols it uses are not interactions with other agents, but with non-agent entities. Perhaps agents and digtal assistants will converge in the future.</p>"},{"location":"aip2/0004-agents/#doorbell","title":"Doorbell","text":"<p>An doorbell that emits a simple signal each time it is pressed is not an agent. It doesn't represent a fiduciary or hold keys. (However, a fancy IoT doorbell that reports to Alice's mobile agent using an A2A protocol would be an agent.)</p>"},{"location":"aip2/0004-agents/#microservices","title":"Microservices","text":"<p>A microservice run by AcmeCorp to integrate with its vendors is not an agent for Acme's vendors. Depending on whether it holds keys and uses A2A protocols, it may or may not be an agent for Acme.</p>"},{"location":"aip2/0004-agents/#human-delegates","title":"Human Delegates","text":"<p>A human delegate who proves empowerment through keys might be thought of as an agent.</p>"},{"location":"aip2/0004-agents/#paper","title":"Paper","text":"<p>The keys for an agent can be stored on paper. This storage basically constitutes a wallet. It isn't an agent. However, it can be thought of as playing the role of an agent in some cases when designing backup and recovery solutions.</p>"},{"location":"aip2/0004-agents/#prior-art","title":"Prior art","text":"<ul> <li>Alan Kay, the recipient of a Turing Award and the coiner of the term \"Object-Oriented Programming\", has emphasized the value of message-passing architectures in numerous places. What he called \"objects\" are conceptually similar to what we are calling \"agents.\" Not surprisingly, the agent ecosystem echoes some aspects of the design of SmallTalk, Objective-C, Erlang Actors, Akka Actors, and similar approaches.</li> <li>The design of the web includes the concept of browsers and similar tech, and refers to them as \"user agents\" in various RFCs. These are not true SSI agents, but they provide an example of ubiquitous helper tech that is the forerunner of the agents described here.</li> </ul>"},{"location":"aip2/0004-agents/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community Aries Framework - .NET .NET framework for building agents of all types Streetcred.id Commercial mobile and web app built using Aries Framework for .NET Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Aries Framework - Go For building agents, hubs and other DIDComm ../../features in GoLang. Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem. Aries Protocol Test Suite Pico Labs Pico Agents protocols: connections, trust_ping, basicmessage, routing Rust Agent Rust implementation of a framework for building agents of all types"},{"location":"aip2/0005-didcomm/","title":"Aries RFC 0005: DID Communication","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-11-21</li> <li>Status Note: Mature as concept, with multiple implementations.</li> <li>Supersedes: Indy PR #98</li> <li>Start Date: 2018-01-05 (approx, backdated)</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0005-didcomm/#summary","title":"Summary","text":"<p>Explain the basics of DID communication (DIDComm) at a high level, and link to other RFCs to promote deeper exploration.</p> <p>NOTE: The version of DIDComm collectively defined in Aries RFCs is known by the label \"DIDComm V1.\" A newer version of DIDComm (\"DIDComm V2\") is now being incubated at DIF. Many ../../concepts are the same between the two versions, but there are some differences in the details. For information about detecting V1 versus V2, see Detecting DIDComm Versions.</p>"},{"location":"aip2/0005-didcomm/#motivation","title":"Motivation","text":"<p>The DID communication between agents and agent-like things is a rich subject with a lot of tribal knowledge. Newcomers to the decentralized identity ecosystem tend to bring mental models that are subtly divergent from its paradigm. When they encounter dissonance, DIDComm becomes mysterious. We need a standard high-level reference.</p>"},{"location":"aip2/0005-didcomm/#tutorial","title":"Tutorial","text":"<p>This discussion assumes that you have a reasonable grasp on topics like self-sovereign identity, DIDs and DID docs, and agents. If you find yourself lost, please review that material for background and starting assumptions.</p> <p>Agent-like things have to interact with one another to get work done. How they talk in general is DIDComm, the subject of this RFC. The specific interactions enabled by DIDComm--connecting and maintaining relationships, issuing credentials, providing proof, etc.--are called protocols; they are described elsewhere.</p>"},{"location":"aip2/0005-didcomm/#rough-overview","title":"Rough Overview","text":"<p>A typical DIDComm interaction works like this:</p>  Imagine Alice wants to negotiate with Bob to sell something online, and that DIDComm, not direct human communication, is involved. This means Alice's agent and Bob's agent are going to exchange a series of messages.  Alice may just press a button and be unaware of details, but underneath, her agent begins by preparing a plaintext JSON message about the proposed sale. (The particulars are irrelevant here, but would be described in the spec for a \"sell something\" protocol.) It then looks up Bob's DID Doc to access two key pieces of information:  * An endpoint (web, email, etc) where messages can be delivered to Bob. * The public key that Bob's agent is using in the Alice:Bob relationship.  Now Alice's agent uses Bob's public key to encrypt the plaintext so that only Bob's agent can read it, adding authentication with its own private key. The agent arranges delivery to Bob. This \"arranging\" can involve various hops and intermediaries. It can be complex.  Bob's agent eventually receives and decrypts the message, authenticating its origin as Alice using her public key. It prepares its response and routes it back using a reciprocal process (plaintext -&gt; lookup endpoint and public key for Alice -&gt; encrypt with authentication -&gt; arrange delivery).  <p>That's it.</p> <p>Well, mostly. The description is pretty good, if you squint, but it does not fit all DIDComm interactions:</p> <ul> <li>DIDComm doesn't always involve turn-taking and request-response.</li> <li>DIDComm interactions can involve more than 2 parties, and the parties are not always individuals.</li> <li>DIDComm may include formats other than JSON.</li> </ul> <p>Before we provide more details, let's explore what drives the design of DIDComm.</p>"},{"location":"aip2/0005-didcomm/#goals-and-ramifications","title":"Goals and Ramifications","text":"<p>The DIDComm design attempts to be:</p> <ol> <li>Secure</li> <li>Private</li> <li>Interoperable</li> <li>Transport-agnostic</li> <li>Extensible</li> </ol> <p>As a list of buzz words, this may elicit nods rather than surprise. However, several items have deep ramifications.</p> <p>Taken together, Secure and Private require that the protocol be decentralized and maximally opaque to the surveillance economy.</p> <p>Interoperable means that DIDComm should work across programming languages, blockchains, vendors, OS/platforms, networks, legal jurisdictions, geos, cryptographies, and hardware--as well as across time. That's quite a list. It means that DIDComm intends something more than just compatibility within Aries; it aims to be a future-proof lingua franca of all self-sovereign interactions.</p> <p>Transport-agnostic means that it should be possible to use DIDComm over HTTP(S) 1.x and 2.0, WebSockets, IRC, Bluetooth, AMQP, NFC, Signal, email, push notifications to mobile devices, Ham radio, multicast, snail mail, carrier pigeon, and more.</p> <p>All software design involves tradeoffs. These goals, prioritized as shown, lead down an interesting path.</p>"},{"location":"aip2/0005-didcomm/#message-based-asynchronous-and-simplex","title":"Message-Based, Asynchronous, and Simplex","text":"<p>The dominant paradigm in mobile and web development today is duplex request-response. You call an API with certain inputs, and you get back a response with certain outputs over the same channel, shortly thereafter. This is the world of OpenAPI (Swagger), and it has many virtues.</p> <p>Unfortunately, many agents are not good analogs to web servers. They may be mobile devices that turn off at unpredictable intervals and that lack a stable connection to the network. They may need to work peer-to-peer, when the internet is not available. They may need to interact in time frames of hours or days, not with 30-second timeouts. They may not listen over the same channel that they use to talk.</p> <p>Because of this, the fundamental paradigm for DIDComm is message-based, asynchronous, and simplex. Agent X sends a message over channel A. Sometime later, it may receive a response from Agent Y over channel B. This is much closer to an email paradigm than a web paradigm.</p> <p>On top of this foundation, it is possible to build elegant, synchronous request-response interactions. All of us have interacted with a friend who's emailing or texting us in near-realtime. However, interoperability begins with a least-common-denominator assumption that's simpler.</p>"},{"location":"aip2/0005-didcomm/#message-level-security-reciprocal-authentication","title":"Message-Level Security, Reciprocal Authentication","text":"<p>The security and privacy goals, and the asynchronous+simplex design decision, break familiar web assumptions in another way. Servers are commonly run by institutions, and we authenticate them with certificates. People and things are usually authenticated to servers by some sort of login process quite different from certificates, and this authentication is cached in a session object that expires. Furthermore, web security is provided at the transport level (TLS); it is not an independent attribute of the messages themselves.</p> <p>In a partially disconnected world where a comm channel is not assumed to support duplex request-response, and where the security can't be ignored as a transport problem, traditional TLS, login, and expiring sessions are impractical. Furthermore, centralized servers and certificate authorities perpetuate a power and UX imbalance between servers and clients that doesn't fit with the peer-oriented DIDComm.</p> <p>DIDComm uses public key cryptography, not certificates from some parties and passwords from others. Its security guarantees are independent of the transport over which it flows. It is sessionless (though sessions can easily be built atop it). When authentication is required, all parties do it the same way.</p>"},{"location":"aip2/0005-didcomm/#reference","title":"Reference","text":"<p>The following RFCs profide additional information: * 0021: DIDComm Message Anatomy * 0020: Message Types * 0011: Decorators * 0008: Message ID and Threading * 0019: Encryption Envelope * 0025: Agent Transports</p>"},{"location":"aip2/0005-didcomm/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community Aries Framework - .NET .NET framework for building agents of all types Streetcred.id Commercial mobile and web app built using Aries Framework - .NET Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Aries Framework - Go For building agents, hubs and other DIDComm ../../features in GoLang. Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem. Aries Protocol Test Suite Pico Labs Pico Agents protocols: connections, trust_ping, basicmessage, routing"},{"location":"aip2/0008-message-id-and-threading/","title":"Aries RFC 0008: Message ID and Threading","text":"<ul> <li>Authors: Daniel Bluhm, Sam Curren, Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2018-10-01</li> <li>Status Note: Implemented broadly in Indy, but not yet elsewhere.</li> <li>Start Date: 2018-08-03</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0008-message-id-and-threading/#summary","title":"Summary","text":"<p>Definition of the message @id field and the ~thread decorator.</p>"},{"location":"aip2/0008-message-id-and-threading/#motivation","title":"Motivation","text":"<p>Referring to messages is useful in many interactions. A standard method of adding a message ID promotes good patterns in message families. When multiple messages are coordinated in a message flow, the threading pattern helps avoid having to re-roll the same spec for each message family that needs it.</p>"},{"location":"aip2/0008-message-id-and-threading/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0008-message-id-and-threading/#message-ids","title":"Message IDs","text":"<p>Message IDs are specified with the @id attribute, which comes from JSON-LD. The sender of the message is responsible for creating the message ID, and any message can be identified by the combination of the sender and the message ID. Message IDs should be considered to be opaque identifiers by any recipients.</p>"},{"location":"aip2/0008-message-id-and-threading/#message-id-requirements","title":"Message ID Requirements","text":"<ul> <li>A short stream of characters matching regex <code>[-_./a-ZA-Z0-9]{8,64}</code> (Note the   special semantics of a dotted suffix on IDs,   as described in the message tracing HIPE proposal)</li> <li>Should be compared case-sensitive (no case folding)</li> <li>Sufficiently unique</li> <li>UUID recommended</li> </ul>"},{"location":"aip2/0008-message-id-and-threading/#example","title":"Example","text":"<pre><code>{\n    \"@type\": \"did:example:12345...;spec/example_family/1.0/example_type\",\n    \"@id\": \"98fd8d72-80f6-4419-abc2-c65ea39d0f38\",\n    \"example_attribute\": \"stuff\"\n}\n</code></pre> <p>The following was pulled from this document written by Daniel Hardman and stored in the Sovrin Foundation's <code>protocol</code> repository.</p>"},{"location":"aip2/0008-message-id-and-threading/#threaded-messages","title":"Threaded Messages","text":"<p>Message threading will be implemented as a decorator to messages, for example:</p> <pre><code>{\n    \"@type\": \"did:example:12345...;spec/example_family/1.0/example_type\",\n    \"@id\": \"98fd8d72-80f6-4419-abc2-c65ea39d0f38\",\n    \"~thread\": {\n        \"thid\": \"98fd8d72-80f6-4419-abc2-c65ea39d0f38\",\n        \"pthid\": \"1e513ad4-48c9-444e-9e7e-5b8b45c5e325\",\n        \"sender_order\": 3,\n        \"received_orders\": {\"did:sov:abcxyz\":1},\n        \"goal_code\": \"aries.vc.issue\"\n    },\n    \"example_attribute\": \"example_value\"\n}\n</code></pre> <p>The <code>~thread</code> decorator is generally required on any type of response, since this is what connects it with the original request.</p> <p>While not recommended, the initial message of a new protocol instance MAY have an empty (<code>{}</code>) <code>~thread</code> item. Aries agents receiving a message with an empty <code>~thread</code> item MUST gracefully handle such a message.</p>"},{"location":"aip2/0008-message-id-and-threading/#thread-object","title":"Thread object","text":"<p>A thread object has the following fields discussed below:</p> <ul> <li><code>thid</code>: The ID of the message that serves as the thread start.</li> <li><code>pthid</code>: An optional parent <code>thid</code>. Used when branching or nesting a new interaction off of an existing one.</li> <li><code>sender_order</code>: A number that tells where this message fits in the sequence of all messages that the current sender has contributed to this thread.</li> <li><code>received_orders</code>: Reports the highest <code>sender_order</code> value that the sender has seen   from other sender(s) on the thread. (This value is often missing if it   is the first message in an interaction, but should be used otherwise,   as it provides an implicit ACK.)</li> <li><code>goal_code</code>: Optional. See RFC 0519: Goal Codes.</li> </ul>"},{"location":"aip2/0008-message-id-and-threading/#thread-id-thid","title":"Thread ID (<code>thid</code>)","text":"<p>Because multiple interactions can happen simultaneously, it's important to differentiate between them. This is done with a Thread ID or <code>thid</code>.</p> <p>If the Thread object is defined and a <code>thid</code> is given, the Thread ID is the value given there. But if the Thread object is not defined in a message, the Thread ID is  implicitly defined as the Message ID (<code>@id</code>) of the given message and that message is the first message of a new thread.</p>"},{"location":"aip2/0008-message-id-and-threading/#sender-order-sender_order","title":"Sender Order (<code>sender_order</code>)","text":"<p>It is desirable to know how messages within a thread should be ordered. However, it is very difficult to know with confidence the absolute ordering of events scattered across a distributed system. Alice and Bob may each send a message before receiving the other's response, but be unsure whether their message was composed before the other's. Timestamping cannot resolve an impasse. Therefore, there is no unified absolute ordering of all messages within a thread--but there is an ordering of all messages emitted by a each participant.</p> <p>In a given thread, the first message from each party has a <code>sender_order</code> value of 0, the second message sent from each party has a <code>sender_order</code> value of 1, and so forth. Note that both Alice and Bob use 0 and 1, without regard to whether the other party may be known to have used them. This gives a strong ordering with respect to each party's messages, and it means that any message can be uniquely identified in an interaction by its <code>thid</code>, the sender DID and/or key, and the <code>sender_order</code>.</p>"},{"location":"aip2/0008-message-id-and-threading/#received-orders-received_orders","title":"Received Orders (<code>received_orders</code>)","text":"<p>In an interaction, it may be useful for the recipient of a message to know if their last message was received. A <code>received_orders</code> value addresses this need, and could be included as a best practice to help detect missing messages.</p> <p>In the example above, if Alice is the sender, and Bob is identified by <code>did:sov:abcxyz</code>, then Alice is saying, \"Here's my message with index 3 (<code>sender_order</code>=3), and I'm sending it in response to your message 1 (<code>received_orders: {&lt;bob's DID&gt;: 1}</code>. Apparently Alice has been more chatty than Bob in this exchange.</p> <p>The <code>received_orders</code> field is plural to acknowledge the possibility of multiple parties. In pairwise interactions, this may seem odd. However, n-wise interactions are possible (e.g., in a doctor ~ hospital ~ patient n-wise relationship). Even in pairwise, multiple agents on either side may introduce other actors. This may happen even if an interaction is designed to be 2-party (e.g., an intermediate party emits an error unexpectedly).</p> <p>In an interaction with more parties, the <code>received_orders</code> object has a key/value pair for each <code>actor</code>/<code>sender_order</code>, where <code>actor</code> is a DID or a key for an agent:</p> <pre><code>\"received_orders\": {\"did:sov:abcxyz\":1, \"did:sov:defghi\":14}\n</code></pre> <p>Here, the <code>received_orders</code> fragment makes a claim about the last <code>sender_order</code> that the sender observed from <code>did:sov:abcxyz</code> and <code>did:sov:defghi</code>. The sender of this fragment is presumably some other DID, implying that 3 parties are participating. Any parties unnamed in <code>received_orders</code> have an undefined value for <code>received_orders</code>. This is NOT the same as saying that they have made no observable contribution to the thread. To make that claim, use the special value <code>-1</code>, as in:</p> <pre><code>\"received_orders\": {\"did:sov:abcxyz\":1, \"did:sov:defghi\":14, \"did:sov:jklmno\":-1}\n</code></pre>"},{"location":"aip2/0008-message-id-and-threading/#example_1","title":"Example","text":"<p>As an example, Alice is an issuer and she offers a credential to Bob.</p> <ul> <li>Alice sends a CRED_OFFER as the start of a new thread, <code>@id</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0.</li> <li>Bob responds with a CRED_REQUEST, <code>@id</code>=&lt;uuid2&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0, <code>received_orders:{alice:0}</code>.</li> <li>Alice sends a CRED, <code>@id</code>=&lt;uuid3&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=1, <code>received_orders:{bob:0}</code>.</li> <li>Bob responds with an ACK, <code>@id</code>=&lt;uuid4&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=1, <code>received_orders:{alice:1}</code>.</li> </ul>"},{"location":"aip2/0008-message-id-and-threading/#nested-interactions-parent-thread-id-or-pthid","title":"Nested interactions (Parent Thread ID or <code>pthid</code>)","text":"<p>Sometimes there are interactions that need to occur with the same party, while an existing interaction is in-flight.</p> <p>When an interaction is nested within another, the initiator of a new interaction can include a Parent Thread ID (<code>pthid</code>). This signals to the other party that this is a thread that is branching off of an existing interaction.</p>"},{"location":"aip2/0008-message-id-and-threading/#nested-example","title":"Nested Example","text":"<p>As before, Alice is an issuer and she offers a credential to Bob. This time, she wants a bit more information before she is comfortable providing a credential.</p> <ul> <li>Alice sends a CRED_OFFER as the start of a new thread, <code>@id</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0.</li> <li>Bob responds with a CRED_REQUEST, <code>@id</code>=&lt;uuid2&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0, <code>received_orders:{alice:0}</code>.</li> <li>Alice sends a PROOF_REQUEST, <code>@id</code>=&lt;uuid3&gt;, <code>pthid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0. Note the subthread, the parent thread ID, and the reset <code>sender_order</code> value.</li> <li>Bob sends a PROOF, <code>@id</code>=&lt;uuid4&gt;, <code>thid</code>=&lt;uuid3&gt;,<code>sender_order</code>=0, <code>received_orders:{alice:0}</code>.</li> <li>Alice sends a CRED, <code>@id</code>=&lt;uuid5&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=1, <code>received_orders:{bob:0}</code>.</li> <li>Bob responds with an ACK, <code>@id</code>=&lt;uuid6&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=1, <code>received_orders:{alice:1}</code>.</li> </ul> <p>All of the steps are the same, except the two bolded steps that are part of a nested interaction.</p>"},{"location":"aip2/0008-message-id-and-threading/#implicit-threads","title":"Implicit Threads","text":"<p>Threads reference a Message ID as the origin of the thread. This allows any message to be the start of a thread, even if not originally intended. Any message without an explicit <code>~thread</code> attribute can be considered to have the following <code>~thread</code> attribute implicitly present.</p> <pre><code>\"~thread\": {\n    \"thid\": &lt;same as @id of the outer message&gt;,\n    \"sender_order\": 0\n}\n</code></pre>"},{"location":"aip2/0008-message-id-and-threading/#implicit-replies","title":"Implicit Replies","text":"<p>A message that contains a <code>~thread</code> block with a <code>thid</code> different from the outer message <code>@id</code>, but no <code>sender_order</code> is considered an implicit reply. Implicit replies have a <code>sender_order</code> of <code>0</code> and an <code>received_orders:{other:0}</code>. Implicit replies should only be used when a further message thread is not anticipated. When further messages in the thread are expected, a full regular <code>~thread</code> block should be used.</p> <p>Example Message with am Implicit Reply:</p> <p><pre><code>{\n    \"@id\": \"&lt;@id of outer message&gt;\",\n    \"~thread\": {\n        \"thid\": \"&lt;different than @id of outer message&gt;\"\n    }\n}\n</code></pre> Effective Message with defaults in place: <pre><code>{\n    \"@id\": \"&lt;@id of outer message&gt;\",\n    \"~thread\": {\n        \"thid\": \"&lt;different than @id of outer message&gt;\"\n        \"sender_order\": 0,\n        \"received_orders\": { \"DID of sender\":0 }\n    }\n}\n</code></pre></p>"},{"location":"aip2/0008-message-id-and-threading/#reference","title":"Reference","text":"<ul> <li>Message Packaging document from Sovrin Foundation Protocol Repo</li> <li>Very brief summary of discussion from Agent Summit on Decorators</li> </ul>"},{"location":"aip2/0008-message-id-and-threading/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"aip2/0008-message-id-and-threading/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Implement threading for each message type that needs it.</li> </ul>"},{"location":"aip2/0008-message-id-and-threading/#prior-art","title":"Prior art","text":"<p>If you're aware of relevant prior-art, please add it here.</p>"},{"location":"aip2/0008-message-id-and-threading/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Using a wrapping method for threading has been discussed but most seemed in favor of the annotated method. Any remaining arguments to be made in favor of the wrapping method?</li> </ul>"},{"location":"aip2/0008-message-id-and-threading/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem. Aries Protocol Test Suite"},{"location":"aip2/0011-decorators/","title":"Aries RFC 0011: Decorators","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-01-31</li> <li>Status Note: broadly used in Indy, but not yet harmonized with DIF work on hubs.</li> <li>Start Date: 2018-12-14</li> <li>Tags: concept, decorator</li> </ul>"},{"location":"aip2/0011-decorators/#summary","title":"Summary","text":"<p>Explain how decorators work in DID communication.</p>"},{"location":"aip2/0011-decorators/#motivation","title":"Motivation","text":"<p>Certain semantic patterns manifest over and over again in communication. For example, all communication needs the pattern of testing the type of message received. The pattern of identifying a message and referencing it later is likely to be useful in a high percentage of all protocols that are ever written. A pattern that associates messages with debugging/tracing/timing metadata is equally relevant. And so forth.</p> <p>We need a way to convey metadata that embodies these patterns, without complicating schemas, bloating core definitions, managing complicated inheritance hierarchies, or confusing one another. It needs to be elegant, powerful, and adaptable.</p>"},{"location":"aip2/0011-decorators/#tutorial","title":"Tutorial","text":"<p>A decorator is an optional chunk of JSON that conveys metadata. Decorators are not declared in a core schema but rather supplementary to it. Decorators add semantic content broadly relevant to messaging in general, and not so much tied to the problem domain of a specific type of interaction.</p> <p>You can think of decorators as a sort of mixin for agent-to-agent messaging. This is not a perfect analogy, but it is a good one. Decorators in DIDComm also have some overlap (but not a direct congruence) with annotations in Java, attributes in C#, and both decorators and annotations in python.</p>"},{"location":"aip2/0011-decorators/#simple-example","title":"Simple Example","text":"<p>Imagine we are designing a protocol and associated messages to arrange meetings between two people. We might come up with a <code>meeting_proposal</code> message that looks like this:</p> <pre><code>{\n  \"@id\": \"e2987006-a18a-4544-9596-5ad0d9390c8b\",\n  \"@type\": \"did:sov:8700e296a1458aad0d93;spec/meetings/1.0/proposal\",\n  \"proposed_time\": \"2019-12-23 17:00\",\n  \"proposed_place\": \"at the cathedral, Barf\u00fcsserplatz, Basel\",\n  \"comment\": \"Let's walk through the Christmas market.\"\n}\n</code></pre> <p>Now we tackle the <code>meeting_proposal_response</code> messages. Maybe we start with something exceedingly simple, like:</p> <pre><code>{\n  \"@id\": \"d9390ce2-8ba1-4544-9596-9870065ad08a\",\n  \"@type\": \"did:sov:8700e296a1458aad0d93;spec/meetings/1.0/response\",\n  \"agree\": true,\n  \"comment\": \"See you there!\"\n}\n</code></pre> <p>But we quickly realize that the asynchronous nature of messaging will expose a gap in our message design: if Alice receives two meeting proposals from Bob at the same time, there is nothing to bind a response back to the specific proposal it addresses.</p> <p>We could extend the schema of our response so it contains an <code>thread</code> that references the <code>@id</code> of the original proposal. This would work. However, it does not satsify the DRY principle of software design, because when we tackle the protocol for negotiating a purchase between buyer and seller next week, we will need the same solution all over again. The result would be a proliferation of schemas that all address the same basic need for associating request and response. Worse, they might do it in different ways, cluttering the mental model for everyone and making the underlying patterns less obvious.</p> <p>What we want instead is a way to inject into any message the idea of a thread, such that we can easily associate responses with requests, errors with the messages that triggered them, and child interactions that branch off of the main one. This is the subject of the message threading RFC, and the solution is the <code>~thread</code> decorator, which can be added to any response:</p> <p><pre><code>{\n  \"@id\": \"d9390ce2-8ba1-4544-9596-9870065ad08a\",\n  \"@type\": \"did:sov:8700e296a1458aad0d93;spec/meetings/1.0/response\",\n  \"~thread\": {\"thid\": \"e2987006-a18a-4544-9596-5ad0d9390c8b\"},\n  \"agree\": true,\n  \"comment\": \"See you there!\"\n}\n</code></pre> This chunk of JSON is defined independent of any particular message schema, but is understood to be available in all DIDComm schemas.</p>"},{"location":"aip2/0011-decorators/#basic-conventions","title":"Basic Conventions","text":"<p>Decorators are defined in RFCs that document a general pattern such as message threading RFC or message localization. The documentation for a decorator explains its semantics and offers examples.</p> <p>Decorators are recognized by name. The name must begin with the <code>~</code> character (which is reserved in DIDComm messages for decorator use), and be a short, single-line string suitable for use as a JSON attribute name.</p> <p>Decorators may be simple key:value pairs <code>\"~foo\": \"bar\"</code>. Or they may associate a key with a more complex structure:</p> <pre><code>\"~thread\": {\n  \"thid\": \"e2987006-a18a-4544-9596-5ad0d9390c8b\",\n  \"pthid\": \"0c8be298-45a1-48a4-5996-d0d95a397006\",\n  \"sender_order\": 0\n}\n</code></pre> <p>Decorators should be thought of as supplementary to the problem-domain-specific fields of a message, in that they describe general communication issues relevant to a broad array of message types. Entities that handle messages should treat all unrecognized fields as valid but meaningless, and decorators are no exception. Thus, software that doesn't recognize a decorator should ignore it.</p> <p>However, this does not mean that decorators are necessarily optional. Some messages may intend something tied so tightly to a decorator's semantics that the decorator effectively becomes required. An example of this is the relationship between a general error reporting mechanism and the <code>~thread</code> decorator: it's not very helpful to report errors without the context that a thread provides.</p> <p>Because decorators are general by design and intent, we don't expect namespacing to be a major concern. The community agrees on decorators that everybody will recognize, and they acquire global scope upon acceptance. Their globalness is part of their utility. Effectively, decorator names are like reserved words in a shared public language of messages.</p> <p>Namespacing is also supported, as we may discover legitimate uses. When namespaces are desired, dotted name notation is used, as in <code>~mynamespace.mydecoratorname</code>. We may elaborate this topic more in the future.</p> <p>Decorators are orthogonal to JSON-LD constructs in DIDComm messages.</p>"},{"location":"aip2/0011-decorators/#versioning","title":"Versioning","text":"<p>We hope that community-defined decorators are very stable. However, new fields (a non-breaking change) might need to be added to complex decorators; occasionally, more significant changes might be necessary as well. Therefore, decorators do support semver-style versioning, but in a form that allows details to be ignored unless or until they become important. The rules are:</p> <ol> <li>As with all other aspects of DIDComm messages, unrecognized fields in decorators must be ignored.</li> <li>Version information can be appended to the name of a decorator, as in <code>~mydecorator/1</code>. Only a major version (never minor or patch) is used, since:<ul> <li>Minor version variations should not break decorator handling code.</li> <li>The dot character <code>.</code> is reserved for namespacing within field names.</li> <li>The extra complexity is not worth the small amount of value it might add.</li> </ul> </li> <li>A decorator without a version is considered to be synonymous with version 1.0, and the version-less form is preferred. This allows version numbers to be added only in the uncommon cases where they are necessary.</li> </ol>"},{"location":"aip2/0011-decorators/#decorator-scope","title":"Decorator Scope","text":"<p>A decorator may be understood to decorate (add semantics) at several different scopes. The discussion thus far has focused on message decorators, and this is by far the most important scope to understand. But there are more possibilities.</p> <p>Suppose we wanted to decorate an individual field. This can be done with a field decorator, which is a sibling field to the field it decorates. The name of decorated field is combined with a decorator suffix, as follows:</p> <p><pre><code>{\n  \"note\": \"Let's have a picnic.\",\n  \"note~l10n\": { ... }\n}\n</code></pre> In this example, taken from the localization pattern, <code>note~l10n</code> decorates <code>note</code>.</p> <p>Besides a single message or a single field, consider the following scopes as decorator targets:</p> <ul> <li>Message Family: An decorator can be declared in documentation for the   message family, explaining semantics that apply to all message instances in the   family unless overridden at a narrower scope. This is not the same as declaring the   decorator's structure to be part of the schema of a message family; this is saying   that the field values in a concrete instance of a decorator applies to all instances   of a message family. The localization pattern contemplates this usage as a way to   declare default localization semantics.</li> <li>Message Type:   A decorator can be declared in the documentation on a specific message   type. If this happens, semantics of the decorator on the message type should be   understood as overriding or enriching the semantics of that same decorator on the   parent message family, since the scope is becoming more specific.</li> <li>Message Thread or thread tree: A participant in a   thread could send a message containing nothing but the <code>~thread</code> with one or   more additional decorators inside it. This should be viewed as a statement of semantics that   apply to subsequent communications from the sender, on that thread, until further   notice or until overridden at the scope of an individual message instance. (While   powerful, applying a decorator to this scope may be a burden on receivers because   it requires them to be stateful. Therefore this usage, though theoretically possible,   may be undesirable. If community members want to explore this, they are encouraged   to discuss broadly, first.)</li> <li>Connection. It is conceivable that Alice could bundle up a set of decorators   and send them to Bob as a way of saying \"Hey, Bob: unless/until subsequent interactions   give you more specific semantics, here's a set of semantics (settings for our connection)   that you should assume for all interactions.\" (This may or may not be useful. It introduces ambiguity--should settings declared   at this scope override those at the scope of a message family or message type? It   also adds a burden of remembering to another party; some of what informs the interaction   isn't present in the bits that flow later on. Thus, this style of decorator is also   left as a possibility for future exploration and is not actively supported at present.)</li> </ul>"},{"location":"aip2/0011-decorators/#reference","title":"Reference","text":"<p>This section of this RFC will be kept up-to-date with a list of globally accepted decorators, and links to the RFCs that define them.</p> <ul> <li><code>~thread</code>: provide request/reply and threading semantics</li> <li><code>~timing</code>: timestamps, expiration, elapsed time</li> <li><code>~trace</code>: collaborative debugging and monitoring</li> <li><code>~l10n</code>: localization support</li> </ul>"},{"location":"aip2/0011-decorators/#drawbacks","title":"Drawbacks","text":"<p>By having fields that are meaningful yet not declared in core schemas, we run the risk that parsing and validation routines will fail to enforce details that are significant but invisible. We also accept the possibility that interop may look good on paper, but fail due to different understandings of important metadata.</p> <p>We believe this risk will take care of itself, for the most part, as real-life usage accumulates and decorators become a familiar and central part of the thinking for developers who work with agent-to-agent communication.</p>"},{"location":"aip2/0011-decorators/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>There is ongoing work in the <code>#indy-semantics</code> channel on Rocket.Chat to explore the concept of overlays. These are layers of additional meaning that accumulate above a schema base. Decorators as described here are quite similar in intent. There are some subtle differences, though. The most interesting is that decorators as described here may be applied to things that are not schema-like (e.g., to a message family as a whole, or to a connection, not just to an individual message).</p> <p>We may be able to resolve these two worldviews, such that decorators are viewed as overlays and inherit some overlay goodness as a result. However, it is unlikely that decorators will change significantly in form or substance as a result. We thus believe the current mental model is already RFC-worthy, and represents a reasonable foundation for immediate use.</p>"},{"location":"aip2/0011-decorators/#prior-art","title":"Prior art","text":"<p>See references to similar ../../features in programming languages like Java, C#, and Python, mentiond above.</p> <p>See also this series of blog posts about semantic gaps and the need to manage intent in a declarative style: [ Lacunas Everywhere, Bridging the Lacuna Humana, Introducing Marks, Mountains,  Molehills, and Markedness ]</p>"},{"location":"aip2/0011-decorators/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Are we doing enough about namespacing and collision avoidance with JSON-LD?</li> <li>What should we do, if anything, about versioning decorators?</li> <li>What should we do, if anything, about applying decorators to stateful scopes   like a connection or a thread?</li> </ul>"},{"location":"aip2/0011-decorators/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries RFCs: RFC 0008, RFC 0017, RFC 0015, RFC 0023, RFC 0043, RFC 0056, RFC 0075 many implemented RFCs depend on decorators... Indy Cloud Agent - Python message threading Aries Framework - .NET message threading Streetcred.id message threading Aries Cloud Agent - Python message threading, attachments Aries Static Agent - Python message threading Aries Framework - Go message threading Connect.Me message threading Verity message threading Aries Protocol Test Suite message threading"},{"location":"aip2/0015-acks/","title":"Aries RFC 0015: ACKs","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Broadly implemented, adopted into many protocols and part of AIP 1 and 2.</li> <li>Start Date: 2018-12-26</li> <li>Tags: feature</li> </ul>"},{"location":"aip2/0015-acks/#summary","title":"Summary","text":"<p>Explains how one party can send acknowledgment messages (ACKs) to confirm receipt and clarify the status of complex processes.</p>"},{"location":"aip2/0015-acks/#change-log","title":"Change log","text":"<ul> <li> <p>Mar 22, 2022: Clarification that an Ack <code>Fail</code> must not be used, and that a Report Problem must be used in its place. Remove Ack <code>Fail</code> from the RFC.</p> </li> <li> <p>Mar 25, 2020: In the ~thread decorator section of the sample in the Explicit ACKs section, 'myindex' was changed to 'sender_order' and 'lrecs' to 'received_orders'. This is in accordance with the field names as defined in RFC 0008.</p> </li> </ul>"},{"location":"aip2/0015-acks/#motivation","title":"Motivation","text":"<p>An acknowledgment or ACK is one of the most common procedures in protocols of all types. We need a flexible, powerful, and easy way to send such messages in agent-to-agent interactions.</p>"},{"location":"aip2/0015-acks/#tutorial","title":"Tutorial","text":"<p>Confirming a shared understanding matters whenever independent parties interact. We buy something on Amazon; moments later, our email client chimes to tell us of a new message with subject \"Thank you for your recent order.\" We verbally accept a new job, but don't rest easy until we've also emailed the signed offer letter back to our new boss. We change a password on an online account, and get a text at our recovery phone number so both parties know the change truly originated with the account's owner.</p> <p>When formal acknowledgments are missing, we get nervous. And rightfully so; most of us have a story of a package that was lost in the mail, or a web form that didn't submit the way we expected.</p> <p>Agents interact in very complex ways. They may use multiple transport mechanisms, across varied protocols, through long stretches of time. While we usually expect messages to arrive as sent, and to be processed as expected, a vital tool in the agent communication repertoire is the receipt of acknowledgments to confirm a shared understanding.</p>"},{"location":"aip2/0015-acks/#implicit-acks","title":"Implicit ACKs","text":"<p>Message threading includes a lightweight, automatic sort of ACK in the form of the <code>~thread.received_orders</code> field. This allows Alice to report that she has received Bob's recent message that had <code>~thread.sender_order</code> = N. We expect threading to be best practice in many use cases, and we expect interactions to often happen reliably enough and quickly enough that implicit ACKs provide high value. If you are considering ACKs but are not familiar with that mechanism, make sure you understand it, first. This RFC offers a supplement, not a replacement.</p>"},{"location":"aip2/0015-acks/#explicit-acks","title":"Explicit ACKs","text":"<p>Despite the goodness of implicit ACKs, there are many circumstances where a reply will not happen immediately. Explicit ACKs can be vital here.</p> <p>Explicit ACKS may also be vital at the end of an interaction, when work is finished: a credential has been issued, a proof has been received, a payment has been made. In such a flow, an implicit ACK meets the needs of the party who received the final message, but the other party may want explicit closure. Otherwise they can't know with confidence about the final outcome of the flow.</p> <p>Rather than inventing a new \"interaction has been completed successfully\" message for each protocol, an all-purpose <code>ack</code> message type is recommended. It looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/notification/1.0/ack\",\n  \"@id\": \"06d474e0-20d3-4cbf-bea6-6ba7e1891240\",\n  \"status\": \"OK\",\n  \"~thread\": {\n    \"thid\": \"b271c889-a306-4737-81e6-6b2f2f8062ae\",\n    \"sender_order\": 4,\n    \"received_orders\": {\"did:sov:abcxyz\": 3}\n  }\n}\n</code></pre> <p>It may also be appropriate to send an ack at other key points in an interaction (e.g., when a key rotation notice is received).</p>"},{"location":"aip2/0015-acks/#adopting-acks","title":"Adopting acks","text":"<p>As discussed in 0003: Protocols, a protocol can adopt the ack message into its own namespace. This allows the type of an ack to change from:     <code>https://didcomm.org/notification/1.0/ack</code> to something like:     <code>https://didcomm.org/otherProtocol/2.0/ack</code>. Thus, message routing logic can see the ack as part of the other protocol, and send it to the relevant handler--but still have all the standardization of generic acks.</p>"},{"location":"aip2/0015-acks/#ack-status","title":"ack status","text":"<p>The <code>status</code> field in an ack tells whether the ack is final or not with respect to the message being acknowledged. It has 2 predefined values: <code>OK</code> (which means an outcome has occurred, and it was positive); and <code>PENDING</code>, which acknowledges that no outcome is yet known.</p> <p>There is not an ack <code>status</code> of <code>FAIL</code>. In the case of a protocol failure a Report Problem message must be used to inform the other party(ies). For more details, see the next section.</p> <p>In addition, more advanced ack usage is possible. See the details in the Reference section.</p>"},{"location":"aip2/0015-acks/#relationship-to-problem-report","title":"Relationship to <code>problem-report</code>","text":"<p>Negative outcomes do not necessarily mean that something bad happened; perhaps Alice comes to hope that Bob rejects her offer to buy his house because she's found something better--and Bob does that, without any error occurring. This is not a FAIL in a problem sense; it's a FAIL in the sense that the offer to buy did not lead to the outcome Alice intended when she sent it.</p> <p>This raises the question of errors. Any time an unexpected problem arises, best practice is to report it to the sender of the message that triggered the problem. This is the subject of the problem reporting mechanism.</p> <p>A <code>problem_report</code> is inherently a sort of ACK. In fact, the <code>ack</code> message type and the <code>problem_report</code> message type are both members of the same <code>notification</code> message family. Both help a sender learn about status. Therefore, a requirement for an <code>ack</code> is that a status of <code>FAIL</code> be satisfied by a <code>problem_report</code> message.</p> <p>However, there is some subtlety in the use of the two types of messages. Some <code>ack</code>s may be sent before a final outcome, so a final <code>problem_report</code> may not be enough. As well, an ack request may be sent after a previous <code>ack</code> or <code>problem_report</code> was lost in transit. Because of these caveats, developers whose code creates or consumes acks should be thoughtful about where the two message types overlap, and where they do not. Carelessness here is likely to cause subtle, hard-to-duplicate surprises from time to time.</p>"},{"location":"aip2/0015-acks/#custom-acks","title":"Custom ACKs","text":"<p>This mechanism cannot address all possible ACK use cases. Some ACKs may require custom data to be sent, and some acknowledgment schemes may be more sophisticated or fine-grained that the simple settings offered here. In such cases, developers should write their own ACK message type(s) and maybe their own decorators. However, reusing the field names and conventions in this RFC may still be desirable, if there is significant overlap in the ../../concepts.</p>"},{"location":"aip2/0015-acks/#requesting-acks","title":"Requesting ACKs","text":"<p>A decorator, <code>~please_ack</code>, allows one agent to request an ad hoc ACK from another agent. This is described in the 0317-please-ack RFC.</p>"},{"location":"aip2/0015-acks/#reference","title":"Reference","text":""},{"location":"aip2/0015-acks/#ack-message","title":"<code>ack</code> message","text":""},{"location":"aip2/0015-acks/#status","title":"<code>status</code>","text":"<p>Required, values <code>OK</code> or <code>PENDING</code>. As discussed above, this tells whether the ack is final or not with respect to the message being acknowledged.</p>"},{"location":"aip2/0015-acks/#threadthid","title":"<code>~thread.thid</code>","text":"<p>Required. This links the <code>ack</code> back to the message that requested it.</p> <p>All other fields in an <code>ack</code> are present or absent per requirements of ordinary messages.</p>"},{"location":"aip2/0015-acks/#drawbacks-and-alternatives","title":"Drawbacks and Alternatives","text":"<p>None identified.</p>"},{"location":"aip2/0015-acks/#prior-art","title":"Prior art","text":"<p>See notes above about the implicit ACK mechanism in <code>~thread.received_orders</code>.</p>"},{"location":"aip2/0015-acks/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Muliplexed acks. How do you supply an ACK to all of Alice's agents instead of just to the one who involved in the current protocol?</li> </ul>"},{"location":"aip2/0015-acks/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes RFC 0036: Issue Credential Protocol ACKs are adopted by this protocol. RFC 0037: Present Proof Protocol ACKs are adopted by this protocol. RFC 0193: Coin Flip Protocol ACKs are adopted as a subprotocol. Aries Cloud Agent - Python Contributed by the Government of British Columbia."},{"location":"aip2/0017-attachments/","title":"Aries RFC 0017: Attachments","text":"<ul> <li>Authors: Daniel Hardman, Sam Curren, Andrew Whitehead</li> <li>Status: ACCEPTED</li> <li>Since: 2019-01-31</li> <li>Status Note: Used in a number of other RFCs.</li> <li>Start Date: 2018-12-24</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0017-attachments/#summary","title":"Summary","text":"<p>Explains the three canonical ways to attach data to an agent message.</p>"},{"location":"aip2/0017-attachments/#motivation","title":"Motivation","text":"<p>DIDComm messages use a structured format with a defined schema and a small inventory of scalar data types (string, number, date, etc). However, it will be quite common for messages to supplement formalized exchange with arbitrary data--images, documents, or types of media not yet invented.</p> <p>We need a way to \"attach\" such content to DIDComm messages. This method must be flexible, powerful, and usable without requiring new schema updates for every dynamic variation.</p>"},{"location":"aip2/0017-attachments/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0017-attachments/#messages-versus-data","title":"Messages versus Data","text":"<p>Before explaining how to associate data with a message, it is worth pondering exactly how these two categories of information differ. It is common for newcomers to DIDComm to argue that messages are just data, and vice versa. After all, any data can be transmitted over DIDComm; doesn't that turn it into a message? And any message can be saved; doesn't that make it data?</p> <p>While it is true that messages and data are highly related, some semantic differences matter:</p> <ul> <li> <p>Messages are primarily about communication. Their meaning is tied to a communication context. Messages are a mechanism whereby state evolves in a protocol. Protocols are versioned according to the structure and semantics of messages. Messages are usually small, consisting of a modest number of fields with a structure that's focused on furthering the goals of their protocol.</p> </li> <li> <p>Data has meaning at rest, in many different DIDComm protocols, or in important contexts beyond DIDComm. Data may be very large and very complex. It may come in formats that are quite independent from DIDComm, versioned independently from the protocols that share it. Data may be produced, consumed or handled as part of a protocol, but the actual content of the data is usually not where processing at the protocol level focuses. In agent codebases, it would be common for data handling to be implemented in different classes or libraries from the handlers for messages.</p> </li> </ul> <p>Some examples:</p> <ul> <li> <p>A protocol to negotiate the release of medical records might cause X-Rays, genomes, and many other artifacts to be transmitted. These artifacts are data, whereas the information packets that arrange the transmission and provide a carrying mechanism for the artifacts are messages.</p> </li> <li> <p>A DIDComm message can be used to report an error. Descriptive parameters that change how the error is processed are probably part of the message, whereas a log file that provides supporting information should be thought of as data rather than the message.</p> </li> <li> <p>The protocol for issuing credentials consists of messages that flow through certain steps. One of the steps eventually delivers a credential. The credential is data; it has meaning even when the protocol is complete, and the protocol version may evolve independent of the data format of the credential itself. The fact that the credential is transmitted through a message does not change the credential's primary status as data.</p> </li> <li> <p>A protocol to schedule a venue for an event might produce a confirmation message when it finishes. This message might include a map of the venue, instructions about how to unlock the gate, pictures of certain resources, and so forth. This collateral is data, whereas the messages that signal progression through the steps of scheduling are not.</p> </li> <li> <p>The DID Exchange Protocol exchanges messages to establish a connection between two parties. Part of what's exchanged is a DID Doc. The DID Doc is more like data than it is like an ordinary message, since it has meaning at rest and outside the protocol.</p> </li> </ul> <p>The line between these two ../../concepts may not be perfectly crisp in all cases, and that is okay. It is clear enough, most of the time, to provide context for the central question of this RFC, which is:</p> <p>How do we send data along with messages?</p>"},{"location":"aip2/0017-attachments/#3-ways","title":"3 Ways","text":"<p>Data can be \"attached\" to DIDComm messages in 3 ways:</p> <ol> <li>Inlining</li> <li>Embedding</li> <li>Appending</li> </ol>"},{"location":"aip2/0017-attachments/#inlining","title":"Inlining","text":"<p>In inlining, data is directly assigned as the value paired with a JSON key in a DIDComm message. For example, a message about arranging a rendezvous may inline data about a location: </p> <p>This inlined data is in Google Maps pinning format. It has a meaning at rest, outside the message that conveys it, and the versioning of its structure may evolve independently of the versioning of the rendezvous protocol.</p> <p>Only JSON data can be inlined, since any other data format would break JSON format rules.</p>"},{"location":"aip2/0017-attachments/#embedding","title":"Embedding","text":"<p>In embedding, a JSON data structure called an attachment descriptor is assigned as the value paired with a JSON key in a DIDComm message. (Or, an array of attachment descriptors could be assigned.) By convention, the key name for such attachment fields ends with <code>~attach</code>, making it a field-level decorator that can share common handling logic in agent code. The attachment descriptor structure describes the MIME type and other properties of the data, in much the same way that MIME headers and body describe and contain an attachment in an email message. Given an imaginary protocol that photographers could use to share their favorite photo with friends, the embedded data might manifest like this:</p> <p></p> <p>Embedding is a less direct mechanism than inlining, because the data is no longer readable by a human inspecting the message; it is base64url-encoded instead. A benefit of this approach is that the data can be any MIME type instead of just JSON, and that the data comes with useful metadata that can facilitate saving it as a separate file.</p>"},{"location":"aip2/0017-attachments/#appending","title":"Appending","text":"<p>Appending is accomplished using the <code>~attach</code> decorator, which can be added to any message to include arbitrary data. The decorator is an array of attachment descriptor structures (the same structure used for embedding). For example, a message that conveys evidence found at a crime scene might include the following decorator:</p> <p></p>"},{"location":"aip2/0017-attachments/#choosing-the-right-approach","title":"Choosing the right approach","text":"<p>These methods for attaching sit along a continuum that is somewhat like the continuum between strong, statically typed languages versus dynamic, duck-typed languages in programming. The more strongly typed the attachments are, the more strongly bound the attachments are to the protocol that conveys them. Each choice has advantages and disadvantages.</p> <p></p> <p>Inlined data is strongly typed; the schema for its associated message must specify the name of the data field, plus what type of data it contains. Its format is always some kind of JSON--often JSON-LD with a <code>@type</code> and/or <code>@context</code> field to provide greater clarity and some independence of versioning. Simple and small data is the best fit for inlining. As mentioned earlier, the Connection Protocol inlines a DID Doc in its <code>connection_request</code> and <code>connection_response</code> messages.</p> <p>Embedded data is still associated with a known field in the message schema, but it can have a broader set of possible formats. A credential exchange protocol might embed a credential in the final message that does credential issuance.</p> <p>Appended attachments are the most flexible but also the hardest to run through semantically sophisticated processing. They do not require any specific declaration in the schema of a message, although they can be referenced in fields defined by the schema via their nickname (see below). A protocol that needs to pass an arbitrary collection of artifacts without strong knowledge of their semantics might find this helpful, as in the example mentioned above, where scheduling a venue causes various human-usable payloads to be delivered.</p>"},{"location":"aip2/0017-attachments/#ids-for-attachments","title":"IDs for attachments","text":"<p>The <code>@id</code> field within an attachment descriptor is used to refer unambiguously to an appended (or less ideally, embedded) attachment, and works like an HTML anchor. It is resolved relative to the root <code>@id</code> of the message and only has to be unique within a message. For example, imagine a fictional message type that's used to apply for an art scholarship, that requires photos of art demonstrating techniques A, B, and C. We could have 3 different attachment descriptors--but what if the same work of art demonstrates both technique A and technique B? We don't want to attach the same photo twice...</p> <p>What we can do is stipulate that the datatype of <code>A_pic</code>, <code>B_pic</code>, and <code>C_pic</code> is an attachment reference, and that the references will point to appended attachments. A fragment of the result might look like this:</p> <p></p> <p>Another example of nickname use appeared in the first example of appended attachments above, where the <code>notes</code> field refered to the <code>@id</code>s of the various attachments.</p> <p>This indirection offers several benefits:</p> <ul> <li>The same attachment may be referenced at more than one place in the schema, without duplicating the content.</li> <li>The message may now include any number of attachments besides the 3 that are required, and mingle them freely with the others. (In our example, perhaps the student wants to add side and overhead shots of each work of art, not just front views).</li> <li>Attachments may now have formal semantics, instead of requiring human intelligence to handle. (How many times have we written emails with multiple attachments, and added verbiage like, \"My photo of the door is attached as image1.jpeg; my photo of the damaged trunk is attached as image2.jpeg\"?)</li> </ul> <p>We could use this same technique with embedded attachments (that is, assign a nickname to an embedded attachment, and refer to that nickname in another field where attached data could be embedded), but this is not considered best practice. The reason is that it requires a field in the schema to have two possible data types--one a string that's a nickname reference, and one an attachment descriptor. Generally, we like fields to have a single datatype in a schema.</p>"},{"location":"aip2/0017-attachments/#content-formats","title":"Content Formats","text":"<p>There are multiple ways to include content in an attachment. Only one method should be used per attachment.</p>"},{"location":"aip2/0017-attachments/#base64url","title":"base64url","text":"<p>This content encoding is an obvious choice for any content different than JSON. You can embed content of any type using this method. Examples are plentiful throughout the document. Note that this encoding is always base64url encoding, not plain base64, and that padding is not required. Code that reads this encoding SHOULD tolerate the presence or absence of padding and base64 versus base64url encodings equally well, but code that writes this encoding SHOULD omit the padding to guarantee alignment with encoding rules in the JOSE (JW*) family of specs.</p>"},{"location":"aip2/0017-attachments/#json","title":"json","text":"<p>If you are embedding an attachment that is JSON, you can embed it directly in JSON format to make access easier, by replacing <code>data.base64</code> with <code>data.json</code>, where the value assigned to <code>data.json</code> is the attached content:</p> <p></p> <p>This is an overly trivial example of GeoJSON, but hopefully it illustrates the technique. In cases where there is no mime type to declare, it may be helpful to use JSON-LD's <code>@type</code> construct to clarify the specific flavor of JSON in the embedded attachment.</p>"},{"location":"aip2/0017-attachments/#links","title":"links","text":"<p>All examples discussed so far include an attachment by value--that is, the attachment's bytes are directly inlined in the message in some way. This is a useful mode of data delivery, but it is not the only mode.</p> <p>Another way that attachment data can be incorporated is by reference. For example, you can link to the content on a web server by replacing <code>data.base64</code> or <code>data.json</code> with <code>data.links</code> in an attachment descriptor:</p> <p></p> <p>When you provide such a link, you are creating a logical association between the message and an attachment that can be fetched separately. This makes it possible to send brief descriptors of attachments and to make the downloading of the heavy content optional (or parallelizable) for the recipient.</p> <p>The <code>links</code> field is plural (an array) to allow multiple locations to be offered for the same content. This allows an agent to fetch attachments using whichever mechanism(s) are best suited to its individual needs and capabilities.</p>"},{"location":"aip2/0017-attachments/#supported-uri-types","title":"Supported URI Types","text":"<p>The set of supported URI types in an attachment link is limited to:</p> <ul> <li>HTTP</li> <li>HTTPS</li> </ul> <p>Additional URI types may be added via updates to this RFC.</p> <p>If an attachment link with an unsupported URI is received, the agent SHOULD respond with a Problem Report indicated the problem.</p> <p>An ecosystem (coordinating set of agents working in a specific business area) may agree to support other URI types within that ecosystem. As such, implementing a mechanism to easily add support for other attachment link URI types might be useful, but is not required.</p>"},{"location":"aip2/0017-attachments/#signing-attachments","title":"Signing Attachments","text":"<p>In some cases it may be desirable to sign an attachment in addition to or instead of signing the message as a whole. Consider a home-buying protocol; the home inspection needs to be signed even when it is removed from a messaging flow. Attachments may also be signed by a party separate from the sender of the message, or using a different signing key when the sender is performing key rotation.</p> <p>Embedded and appended attachments support signatures by the addition of a <code>data.jws</code> field containing a signature in JWS (RFC 7515) format with Detached Content. The payload of the JWS is the raw bytes of the attachment, appropriately base64url-encoded per JWS rules. If these raw bytes are incorporated by value in the DIDComm message, they are already base64url-encoded in <code>data.base64</code> and are thus directly substitutable for the suppressed <code>data.jws.payload</code> field; if they are externally referenced, then the bytes must be fetched via the URI in <code>data.links</code> and base64url-encoded before the JWS can be fully reconstituted. Signatures over inlined JSON attachments are not currently defined as this depends upon a canonical serialization for the data.</p> <p>Sample JWS-signed attachment:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/xhomebuy/1.0/home_insp\",\n  \"inspection_date\": \"2020-03-25\",\n  \"inspection_address\": \"123 Villa de Las Fuentes, Toledo, Spain\",\n  \"comment\": \"Here's that report you asked for.\",\n  \"report~attach\": {\n    \"mime-type\": \"application/pdf\",\n    \"filename\": \"Garcia-inspection-March-25.pdf\",\n    \"data\": {\n      \"base64\": \"eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ... (bytes omitted to shorten)\",\n      \"jws\": {\n        // payload: ...,  &lt;-- omitted: refer to base64 content when validating\n        \"header\": {\n          \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n        },\n        \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n        \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n      }\n    }\n  }\n}\n</code></pre> <p>Here, the JWS structure inlines a public key value in did:key format within the unprotected header's <code>kid</code> field. It may also use a DID URL to reference a key within a resolvable DIDDoc. Supported DID URLs should specify a timestamp and/or version for the containing document.</p> <p>The JWS protected header consists of at least the following parameter indicating an Edwards curve digital signature:</p> <pre><code>{\n  \"alg\": \"EdDSA\"\n}\n</code></pre> <p>Additional protected and unprotected header parameters may be included in the JWS and must be ignored by implementations if not specifically supported. Any registered header parameters defined by the JWS RFC must be used according to the specification if present.</p> <p>Multiple signatures may be included using the JWS General Serialization syntax. When a single signature is present, the Flattened Serialization syntax should be preferred. Because each JWS contains an unprotected header with the signing key information, the JWS Compact Serialization cannot be supported.</p>"},{"location":"aip2/0017-attachments/#size-considerations","title":"Size Considerations","text":"<p>DIDComm messages should be small, as a general rule. Just as it's a bad idea to send email messages with multi-GB attachments, it would be bad to send DIDComm messages with huge amounts of data inside them. Remember, a message is about advancing a protocol; usually that can be done without gigabytes or even megabytes of JSON fields. Remember as well that DIDComm messages may be sent over channels having size constraints tied to the transport--an HTTP POST or Bluetooth or NFC or AMQP payload of more than a few MB may be problematic.</p> <p>Size pressures in messaging are likely to come from attached data. A good rule of thumb might be to not make DIDComm messages bigger than email or MMS messages--whenever more data needs to be attached, use the inclusion-by-reference technique to allow the data to be fetched separately.</p>"},{"location":"aip2/0017-attachments/#security-implications","title":"Security Implications","text":"<p>Attachments are a notorious vector for malware and mischief with email. For this reason, agents that support attachments MUST perform input validation on attachments, and MUST NOT invoke risky actions on attachments until such validation has been performed. The status of input validation with respect to attachment data MUST be reflected in the Message Trust Context associated with the data's message.</p>"},{"location":"aip2/0017-attachments/#privacy-implications","title":"Privacy Implications","text":"<p>When attachments are inlined, they enjoy the same security and transmission guarantees as all agent communication. However, given the right context, a large inlined attachment may be recognizable by its size, even if it is carefully encrypted.</p> <p>If attachment content is fetched from an external source, then new complications arise. The security guarantees may change. Data streamed from a CDN may be observable in flight. URIs may be correlating. Content may not be immutable or tamper-resistant.</p> <p>However, these issues are not necessarily a problem. If a DIDComm message wants to attach a 4 GB ISO file of a linux distribution, it may be perfectly fine to do so in the clear. Downloading it is unlikely to introduce strong correlation, encryption is unnecessary, and the torrent itself prevents malicious modification.</p> <p>Code that handles attachments will need to use wise policy to decide whether attachments are presented in a form that meets its needs.</p>"},{"location":"aip2/0017-attachments/#reference","title":"Reference","text":""},{"location":"aip2/0017-attachments/#attachment-descriptor-structure","title":"Attachment Descriptor structure","text":"<ul> <li> <p><code>@id</code>: A JSON-LD construct that uniquely identifies attached content within the scope of a given message. Recommended on appended attachment descriptors. Possible but generally unused on embedded attachment descriptors. Never required if no references to the attachment exist; if omitted, then there is no way to refer to the attachment later in the thread, in error messages, and so forth. Because <code>@id</code> is used to compose URIs, it is recommended that this name be brief and avoid spaces and other characters that require URI escaping.</p> </li> <li> <p><code>description</code>: An optional human-readable description of the content.</p> </li> <li> <p><code>filename</code>: A hint about the name that might be used if this attachment is persisted as a file. It is not required, and need not be unique. If this field is present and <code>mime-type</code> is not, the extension on the filename may be used to infer a MIME type.</p> </li> <li> <p><code>mime-type</code>: Describes the MIME type of the attached content. Optional but recommended.</p> </li> <li> <p><code>lastmod_time</code>: A hint about when the content in this attachment was last modified.</p> </li> <li> <p><code>byte_count</code>: Optional, and mostly relevant when content is included by reference instead of by value. Lets the receiver guess how expensive it will be, in time, bandwidth, and storage, to fully fetch the attachment.</p> </li> <li> <p><code>data</code>: A JSON object that gives access to the actual content of the attachment. Contains the following subfields:</p> </li> <li> <p><code>jws</code>: A JSON Web Signature over the content of the attachment. Optional.</p> </li> <li> <p><code>sha256</code>: The hash of the content. Optional. Used as an integrity check if   content is inlined. if content is only referenced, then including this field   makes the content tamper-evident. This may be redundant, if the content is   stored in an inherently immutable container like content-addressable storage.   This may also be undesirable, if dynamic content at a specified link is   beneficial. Including a hash without including a way to fetch the content via   link is a form of proof of existence.</p> </li> <li> <p><code>links</code>: A list of zero or more locations at which the content may be fetched.   Optional.</p> </li> <li> <p><code>base64</code>: Base64url-encoded data, when representing arbitrary content inline instead   of via <code>links</code>. Optional.</p> </li> <li> <p><code>json</code>: Directly embedded JSON data, when representing content inline instead of   via <code>links</code>, and when the content is natively conveyable as JSON. Optional.</p> </li> </ul>"},{"location":"aip2/0017-attachments/#drawbacks","title":"Drawbacks","text":"<p>By providing 3 different choices, we impose additional complexity on agents that will receive messages. They have to handle attachments in 3 different modes.</p>"},{"location":"aip2/0017-attachments/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Originally, we only proposed the most flexible method of attaching--appending. However, feedback from the community suggested that stronger binding to schema was desirable. Inlining was independently invented, and is suggested by JSON-LD anyway. Embedding without appending eliminates some valuable ../../features such as unnamed and undeclared ad-hoc attachments. So we ended up wanting to support all 3 modes.</p>"},{"location":"aip2/0017-attachments/#prior-art","title":"Prior art","text":"<p>Multipart MIME (see RFCs 822, 1341, and 2045) defines a mechanism somewhat like this. Since we are using JSON instead of email messages as the core model, we can't use these mechanisms directly. However, they are an inspiration for what we are showing here.</p>"},{"location":"aip2/0017-attachments/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>N/A</li> </ul>"},{"location":"aip2/0017-attachments/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python in credential exchange Streetcred.id Commercial mobile and web app built using Aries Framework - .NET"},{"location":"aip2/0019-encryption-envelope/","title":"Aries RFC 0019: Encryption Envelope","text":"<ul> <li>Authors: Kyle Den Hartog, Stephen Curran, Sam Curren, Mike Lodder</li> <li>Status: ADOPTED</li> <li>Since: 2019-05-04</li> <li>Status Note:  </li> <li>Supersedes: INDY 0028 Wire Level Format</li> <li>Start Date: 2018-07-10 (approximate, backdated)</li> <li>Tags: feature</li> </ul>"},{"location":"aip2/0019-encryption-envelope/#summary","title":"Summary","text":"<p>There are two layers of messages that combine to enable interoperable self-sovereign agent-to-agent communication. At the highest level are DIDComm Plaintext Messages - messages sent between identities to accomplish some shared goal (e.g., establishing a connection, issuing a verifiable credential, sharing a chat). DIDComm Plaintext Messages are delivered via the second, lower layer of messaging - DIDComm Encrypted Envelopes. A DIDComm Encrypted Envelope is a wrapper (envelope) around a plaintext message to permit secure sending and routing. A plaintext message going from its sender to its receiver passes through many agents, and an encryption envelope is used for each hop of the journey.</p> <p>This RFC describes the DIDComm Encrypted Envelope format and the <code>pack()</code> and <code>unpack()</code> functions that implement this format.</p>"},{"location":"aip2/0019-encryption-envelope/#motivation","title":"Motivation","text":"<p>Encryption envelopes use a standard format built on JSON Web Encryption - RFC 7516. This format is not captive to Aries; it requires no special Aries worldview or Aries dependencies to implement. Rather, it is a general-purpose solution to the question of how to encrypt, decrypt, and route messages as they pass over any transport(s). By documenting the format here, we hope to provide a point of interoperability for developers of agents inside and outside the Aries ecosystem.</p> <p>We also document how Aries implements its support for the DIDComm Encrypted Envelope format through the <code>pack()</code> and <code>unpack()</code> functions. For developers of Aries, this is a sort of design doc; for those who want to implement the format in other tech stacks, it may be a useful reference.</p>"},{"location":"aip2/0019-encryption-envelope/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0019-encryption-envelope/#assumptions","title":"Assumptions","text":"<p>We assume that each sending agent knows:</p> <ul> <li>Its intended recipient(s).</li> <li>What encryption (if any) is appropriate.</li> <li>If encryption will be used, a public key of the receiving agent.</li> <li>The physical endpoint to use for the receiver, and the appropriate transport protocol (https, zmq, etc.).</li> </ul> <p>The assumptions can be made because either the message is being sent to an agent within the sending agent's domain and so the sender knows the internal configuration of agents, or the message is being sent outside the sending agent's domain and interoperability requirements are in force to define the sending agent's behaviour.</p>"},{"location":"aip2/0019-encryption-envelope/#example-scenario","title":"Example Scenario","text":"<p>The example of Alice and Bob's sovereign domains is used for illustrative purposes in defining this RFC.</p> <p></p> <p>In the diagram above:</p> <ul> <li>Alice has</li> <li>1 Edge agent - \"1\"</li> <li>1 Routing agent - \"2\"</li> <li>1 Domain Endpoint - \"8\"</li> <li>Bob has</li> <li>3 Edge Agents - \"4\", \"5\" and \"6\"<ul> <li>\"6\" is an Edge agent in the cloud, \"4\" and \"5\" are physical devices.</li> </ul> </li> <li>1 Routing agent - \"3\"</li> <li>1 Domain Endpoint - \"9\"</li> </ul> <p>For the purposes of this discussion we are defining the Encryption Envelope agent message flow to be:</p> <p>1 \u2192 2 \u2192 8 \u2192 9 \u2192 3 \u2192 4</p> <p>However, that flow is just one of several that could match this configuration. What we know for sure is that:</p> <ul> <li>1 is the Sender agent in this case and so must send the first or original message.</li> <li>9 is the Domain Endpoint of Bob's domain and so must receive the message as an Encrypted Envelope.</li> <li>4 is the Receiver in this case and so must receive (and should be able to read) the first or original message.</li> </ul>"},{"location":"aip2/0019-encryption-envelope/#encrypted-envelopes","title":"Encrypted Envelopes","text":"<p>An encrypted envelope is used to transport any plaintext message from one agent directly to another. In our example message flow above, there are five encrypted envelopes sent, one for each hop in the flow. The process to send an encrypted envelope consists of the following steps:</p> <ul> <li>Call the standard function <code>pack()</code> to wrap the plaintext message</li> <li>Send the encrypted envelope using the transport protocol defined by the receiving endpoint</li> <li>Receive the encrypted envelope</li> <li>Call the standard function <code>unpack()</code> to retrieve the plaintext message (and possibly its provenance) from the encrypted envelope</li> </ul> <p>This is repeated with each hop, but the encrypted envelopes are nested, such that the plaintext is never visible until it reaches its final recipient.</p>"},{"location":"aip2/0019-encryption-envelope/#implementation","title":"Implementation","text":"<p>We will describe the pack and unpack algorithms, and their output, in terms of Aries' initial implementation, which may evolve over time. Other implementations could be built, but they would need to emit and consume similar inputs and outputs.</p> <p>The data structures emitted and consumed by these algorithms are described in a formal schema.</p>"},{"location":"aip2/0019-encryption-envelope/#authcrypt-mode-vs-anoncrypt-mode","title":"Authcrypt mode vs. Anoncrypt mode","text":"<p>When packing and unpacking are done in a way that the sender is anonymous, we say that we are in anoncrypt mode. When the sender is revealed, we are in authcrypt mode. Authcrypt mode reveals the sender to the recipient only; it is not the same as a non-repudiable signature. See the RFC about non-repudiable signatures, and this discussion about the theory of non-repudiation.</p>"},{"location":"aip2/0019-encryption-envelope/#pack-message","title":"Pack Message","text":""},{"location":"aip2/0019-encryption-envelope/#pack_message-interface","title":"pack_message() interface","text":"<p>packed_message = pack_message(wallet_handle, message, receiver_verkeys, sender_verkey)</p>"},{"location":"aip2/0019-encryption-envelope/#pack_message-params","title":"pack_message() Params:","text":"<ul> <li>wallet_handle: handle to the wallet that contains the sender's secrets.</li> <li>message: the message (plaintext, or nested encrypted envelope) as a string. If it's JSON object it should be in string format first</li> <li>receiver_verkeys: a list of recipient verkeys as string containing a JSON array</li> <li>sender_verkey: the sender's verkey as a string. This verkey is used to look up the sender's private key so the wallet can put supply it as input to the encryption algorithm. When an empty string (\"\") is passed in this parameter, anoncrypt mode is used</li> </ul>"},{"location":"aip2/0019-encryption-envelope/#pack_message-return-value-authcrypt-mode","title":"pack_message() return value (Authcrypt mode)","text":"<p>This is an example of an outputted message encrypting for two verkeys using Authcrypt.</p> <pre><code>{\n    \"protected\": \"eyJlbmMiOiJ4Y2hhY2hhMjBwb2x5MTMwNV9pZXRmIiwidHlwIjoiSldNLzEuMCIsImFsZyI6IkF1dGhjcnlwdCIsInJlY2lwaWVudHMiOlt7ImVuY3J5cHRlZF9rZXkiOiJMNVhEaEgxNVBtX3ZIeFNlcmFZOGVPVEc2UmZjRTJOUTNFVGVWQy03RWlEWnl6cFJKZDhGVzBhNnFlNEpmdUF6IiwiaGVhZGVyIjp7ImtpZCI6IkdKMVN6b1d6YXZRWWZOTDlYa2FKZHJRZWpmenRONFhxZHNpVjRjdDNMWEtMIiwiaXYiOiJhOEltaW5zdFhIaTU0X0otSmU1SVdsT2NOZ1N3RDlUQiIsInNlbmRlciI6ImZ0aW13aWlZUkc3clJRYlhnSjEzQzVhVEVRSXJzV0RJX2JzeERxaVdiVGxWU0tQbXc2NDE4dnozSG1NbGVsTThBdVNpS2xhTENtUkRJNHNERlNnWkljQVZYbzEzNFY4bzhsRm9WMUJkREk3ZmRLT1p6ckticUNpeEtKaz0ifX0seyJlbmNyeXB0ZWRfa2V5IjoiZUFNaUQ2R0RtT3R6UkVoSS1UVjA1X1JoaXBweThqd09BdTVELTJJZFZPSmdJOC1ON1FOU3VsWXlDb1dpRTE2WSIsImhlYWRlciI6eyJraWQiOiJIS1RBaVlNOGNFMmtLQzlLYU5NWkxZajRHUzh1V0NZTUJ4UDJpMVk5Mnp1bSIsIml2IjoiRDR0TnRIZDJyczY1RUdfQTRHQi1vMC05QmdMeERNZkgiLCJzZW5kZXIiOiJzSjdwaXU0VUR1TF9vMnBYYi1KX0pBcHhzYUZyeGlUbWdwWmpsdFdqWUZUVWlyNGI4TVdtRGR0enAwT25UZUhMSzltRnJoSDRHVkExd1Z0bm9rVUtvZ0NkTldIc2NhclFzY1FDUlBaREtyVzZib2Z0d0g4X0VZR1RMMFE9In19XX0=\",\n    \"iv\": \"ZqOrBZiA-RdFMhy2\",\n    \"ciphertext\": \"K7KxkeYGtQpbi-gNuLObS8w724mIDP7IyGV_aN5AscnGumFd-SvBhW2WRIcOyHQmYa-wJX0MSGOJgc8FYw5UOQgtPAIMbSwVgq-8rF2hIniZMgdQBKxT_jGZS06kSHDy9UEYcDOswtoLgLp8YPU7HmScKHSpwYY3vPZQzgSS_n7Oa3o_jYiRKZF0Gemamue0e2iJ9xQIOPodsxLXxkPrvvdEIM0fJFrpbeuiKpMk\",\n    \"tag\": \"kAuPl8mwb0FFVyip1omEhQ==\"\n}\n</code></pre> <p>The base64URL encoded <code>protected</code> decodes to this: <pre><code>{\n    \"enc\": \"xchacha20poly1305_ietf\",\n    \"typ\": \"JWM/1.0\",\n    \"alg\": \"Authcrypt\",\n    \"recipients\": [\n        {\n            \"encrypted_key\": \"L5XDhH15Pm_vHxSeraY8eOTG6RfcE2NQ3ETeVC-7EiDZyzpRJd8FW0a6qe4JfuAz\",\n            \"header\": {\n                \"kid\": \"GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL\",\n                \"iv\": \"a8IminstXHi54_J-Je5IWlOcNgSwD9TB\",\n                \"sender\": \"ftimwiiYRG7rRQbXgJ13C5aTEQIrsWDI_bsxDqiWbTlVSKPmw6418vz3HmMlelM8AuSiKlaLCmRDI4sDFSgZIcAVXo134V8o8lFoV1BdDI7fdKOZzrKbqCixKJk=\"\n            }\n        },\n        {\n            \"encrypted_key\": \"eAMiD6GDmOtzREhI-TV05_Rhippy8jwOAu5D-2IdVOJgI8-N7QNSulYyCoWiE16Y\",\n            \"header\": {\n                \"kid\": \"HKTAiYM8cE2kKC9KaNMZLYj4GS8uWCYMBxP2i1Y92zum\",\n                \"iv\": \"D4tNtHd2rs65EG_A4GB-o0-9BgLxDMfH\",\n                \"sender\": \"sJ7piu4UDuL_o2pXb-J_JApxsaFrxiTmgpZjltWjYFTUir4b8MWmDdtzp0OnTeHLK9mFrhH4GVA1wVtnokUKogCdNWHscarQscQCRPZDKrW6boftwH8_EYGTL0Q=\"\n            }\n        }\n    ]\n}\n</code></pre></p>"},{"location":"aip2/0019-encryption-envelope/#pack-output-format-authcrypt-mode","title":"pack output format (Authcrypt mode)","text":"<pre><code>    {\n        \"protected\": \"b64URLencoded({\n            \"enc\": \"xchachapoly1305_ietf\",\n            \"typ\": \"JWM/1.0\",\n            \"alg\": \"Authcrypt\",\n            \"recipients\": [\n                {\n                    \"encrypted_key\": base64URLencode(libsodium.crypto_box(my_key, their_vk, cek, cek_iv))\n                    \"header\": {\n                          \"kid\": \"base58encode(recipient_verkey)\",\n                           \"sender\" : base64URLencode(libsodium.crypto_box_seal(their_vk, base58encode(sender_vk)),\n                            \"iv\" : base64URLencode(cek_iv)\n                }\n            },\n            ],\n        })\",\n        \"iv\": &lt;b64URLencode(iv)&gt;,\n        \"ciphertext\": b64URLencode(encrypt_detached({'@type'...}, protected_value_encoded, iv, cek),\n        \"tag\": &lt;b64URLencode(tag)&gt;\n    }\n</code></pre>"},{"location":"aip2/0019-encryption-envelope/#authcrypt-pack-algorithm","title":"Authcrypt pack algorithm","text":"<ol> <li>generate a content encryption key (symmetrical encryption key)</li> <li>encrypt the CEK for each recipient's public key using Authcrypt (steps below)<ol> <li>set <code>encrypted_key</code> value to base64URLencode(libsodium.crypto_box(my_key, their_vk, cek, cek_iv))<ul> <li>Note it this step we're encrypting the cek, so it can be decrypted by the recipient</li> </ul> </li> <li>set <code>sender</code> value to base64URLencode(libsodium.crypto_box_seal(their_vk, sender_vk_string))<ul> <li>Note in this step we're encrypting the sender_verkey to protect sender anonymity</li> </ul> </li> <li>base64URLencode(cek_iv) and set to <code>iv</code> value in the header<ul> <li>Note the cek_iv in the header is used for the <code>encrypted_key</code> where as <code>iv</code> is for ciphertext</li> </ul> </li> </ol> </li> <li>base64URLencode the <code>protected</code> value</li> <li>encrypt the <code>message</code> using libsodium.crypto_aead_chacha20poly1305_ietf_encrypt_detached(message, protected_value_encoded, iv, cek) this is the ciphertext.</li> <li>base64URLencode the iv, ciphertext, and tag then serialize the format into the output format listed above.</li> </ol> <p>For a reference implementation, see https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/commands/crypto.rs</p>"},{"location":"aip2/0019-encryption-envelope/#pack_message-return-value-anoncrypt-mode","title":"pack_message() return value (Anoncrypt mode)","text":"<p>This is an example of an outputted message encrypted for two verkeys using Anoncrypt.</p> <pre><code>{\n    \"protected\": \"eyJlbmMiOiJ4Y2hhY2hhMjBwb2x5MTMwNV9pZXRmIiwidHlwIjoiSldNLzEuMCIsImFsZyI6IkFub25jcnlwdCIsInJlY2lwaWVudHMiOlt7ImVuY3J5cHRlZF9rZXkiOiJYQ044VjU3UTF0Z2F1TFcxemdqMVdRWlEwV0RWMFF3eUVaRk5Od0Y2RG1pSTQ5Q0s1czU4ZHNWMGRfTlpLLVNNTnFlMGlGWGdYRnZIcG9jOGt1VmlTTV9LNWxycGJNU3RqN0NSUHNrdmJTOD0iLCJoZWFkZXIiOnsia2lkIjoiR0oxU3pvV3phdlFZZk5MOVhrYUpkclFlamZ6dE40WHFkc2lWNGN0M0xYS0wifX0seyJlbmNyeXB0ZWRfa2V5IjoiaG5PZUwwWTl4T3ZjeTVvRmd0ZDFSVm05ZDczLTB1R1dOSkN0RzRsS3N3dlljV3pTbkRsaGJidmppSFVDWDVtTU5ZdWxpbGdDTUZRdmt2clJEbkpJM0U2WmpPMXFSWnVDUXY0eVQtdzZvaUE9IiwiaGVhZGVyIjp7ImtpZCI6IjJHWG11Q04ySkN4U3FNUlZmdEJITHhWSktTTDViWHl6TThEc1B6R3FRb05qIn19XX0=\",\n    \"iv\": \"M1GneQLepxfDbios\",\n    \"ciphertext\": \"iOLSKIxqn_kCZ7Xo7iKQ9rjM4DYqWIM16_vUeb1XDsmFTKjmvjR0u2mWFA48ovX5yVtUd9YKx86rDVDLs1xgz91Q4VLt9dHMOfzqv5DwmAFbbc9Q5wHhFwBvutUx5-lDZJFzoMQHlSAGFSBrvuApDXXt8fs96IJv3PsL145Qt27WLu05nxhkzUZz8lXfERHwAC8FYAjfvN8Fy2UwXTVdHqAOyI5fdKqfvykGs6fV\",\n    \"tag\": \"gL-lfmD-MnNj9Pr6TfzgLA==\"\n}\n</code></pre> <p>The protected data decodes to this:</p> <pre><code>{\n    \"enc\": \"xchacha20poly1305_ietf\",\n    \"typ\": \"JWM/1.0\",\n    \"alg\": \"Anoncrypt\",\n    \"recipients\": [\n        {\n            \"encrypted_key\": \"XCN8V57Q1tgauLW1zgj1WQZQ0WDV0QwyEZFNNwF6DmiI49CK5s58dsV0d_NZK-SMNqe0iFXgXFvHpoc8kuViSM_K5lrpbMStj7CRPskvbS8=\",\n            \"header\": {\n                \"kid\": \"GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL\"\n            }\n        },\n        {\n            \"encrypted_key\": \"hnOeL0Y9xOvcy5oFgtd1RVm9d73-0uGWNJCtG4lKswvYcWzSnDlhbbvjiHUCX5mMNYulilgCMFQvkvrRDnJI3E6ZjO1qRZuCQv4yT-w6oiA=\",\n            \"header\": {\n                \"kid\": \"2GXmuCN2JCxSqMRVftBHLxVJKSL5bXyzM8DsPzGqQoNj\"\n            }\n        }\n    ]\n}\n</code></pre>"},{"location":"aip2/0019-encryption-envelope/#pack-output-format-anoncrypt-mode","title":"pack output format (Anoncrypt mode)","text":"<pre><code>    {\n         \"protected\": \"b64URLencoded({\n            \"enc\": \"xchachapoly1305_ietf\",\n            \"typ\": \"JWM/1.0\",\n            \"alg\": \"Anoncrypt\",\n            \"recipients\": [\n                {\n                    \"encrypted_key\": base64URLencode(libsodium.crypto_box_seal(their_vk, cek)),\n                    \"header\": {\n                        \"kid\": base58encode(recipient_verkey),\n                    }\n                },\n            ],\n         })\",\n         \"iv\": b64URLencode(iv),\n         \"ciphertext\": b64URLencode(encrypt_detached({'@type'...}, protected_value_encoded, iv, cek),\n         \"tag\": b64URLencode(tag)\n    }\n</code></pre>"},{"location":"aip2/0019-encryption-envelope/#anoncrypt-pack-algorithm","title":"Anoncrypt pack algorithm","text":"<ol> <li>generate a content encryption key (symmetrical encryption key)</li> <li>encrypt the CEK for each recipient's public key using Anoncrypt (steps below)<ol> <li>set <code>encrypted_key</code> value to base64URLencode(libsodium.crypto_box_seal(their_vk, cek))<ul> <li>Note it this step we're encrypting the cek, so it can be decrypted by the recipient</li> </ul> </li> </ol> </li> <li>base64URLencode the <code>protected</code> value</li> <li>encrypt the message using libsodium.crypto_aead_chacha20poly1305_ietf_encrypt_detached(message, protected_value_encoded, iv, cek) this is the ciphertext.</li> <li>base64URLencode the iv, ciphertext, and tag then serialize the format into the output format listed above.</li> </ol> <p>For a reference implementation, see https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/commands/crypto.rs</p>"},{"location":"aip2/0019-encryption-envelope/#unpack-message","title":"Unpack Message","text":""},{"location":"aip2/0019-encryption-envelope/#unpack_message-interface","title":"unpack_message() interface","text":"<p>unpacked_message = unpack_message(wallet_handle, jwe)</p>"},{"location":"aip2/0019-encryption-envelope/#unpack_message-params","title":"unpack_message() Params","text":"<ul> <li>wallet_handle: wallet handle that contains the sender_verkey</li> <li>jwe: a message which was returned from a pack_message() and follows the scheme format described below</li> </ul>"},{"location":"aip2/0019-encryption-envelope/#unpack-algorithm","title":"Unpack Algorithm","text":"<ol> <li>seralize data, so it can be used<ul> <li>For example, in rust-lang this has to be seralized as a struct.</li> </ul> </li> <li>Lookup the <code>kid</code> for each recipient in the wallet to see if the wallet possesses a private key associated with the public key listed</li> <li>Check if a <code>sender</code> field is used.<ul> <li>If a sender is included use auth_decrypt to decrypt the <code>encrypted_key</code> by doing the following:<ol> <li>decrypt sender verkey using libsodium.crypto_box_seal_open(my_private_key, base64URLdecode(sender))</li> <li>decrypt cek using libsodium.crypto_box_open(my_private_key, sender_verkey, encrypted_key, cek_iv)</li> <li>decrypt ciphertext using libsodium.crypto_aead_chacha20poly1305_ietf_open_detached(base64URLdecode(ciphertext_bytes), base64URLdecode(protected_data_as_bytes), base64URLdecode(nonce), cek)</li> <li>return <code>message</code>, <code>recipient_verkey</code> and <code>sender_verkey</code> following the authcrypt format listed below</li> </ol> </li> <li>If a sender is NOT included use anon_decrypt to decrypt the <code>encrypted_key</code> by doing the following:<ol> <li>decrypt <code>encrypted_key</code> using libsodium.crypto_box_seal_open(my_private_key, encrypted_key)</li> <li>decrypt ciphertext using libsodium.crypto_aead_chacha20poly1305_ietf_open_detached(base64URLdecode(ciphertext_bytes), base64URLdecode(protected_data_as_bytes), base64URLdecode(nonce), cek)</li> <li>return <code>message</code> and <code>recipient_verkey</code> following the anoncrypt format listed below</li> </ol> </li> </ul> </li> </ol> <p>NOTE: In the unpack algorithm, the base64url decode implementation used MUST correctly decode padded and unpadded base64URL encoded data.</p> <p>For a reference unpack implementation, see https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/commands/crypto.rs</p>"},{"location":"aip2/0019-encryption-envelope/#unpack_message-return-values-authcrypt-mode","title":"unpack_message() return values (authcrypt mode)","text":"<pre><code>{\n    \"message\": \"{ \\\"@id\\\": \\\"123456780\\\",\\\"@type\\\":\\\"https://didcomm.org/basicmessage/1.0/message\\\",\\\"sent_time\\\": \\\"2019-01-15 18:42:01Z\\\",\\\"content\\\": \\\"Your hovercraft is full of eels.\\\"}\",\n    \"recipient_verkey\": \"HKTAiYM8cE2kKC9KaNMZLYj4GS8uWCYMBxP2i1Y92zum\",\n    \"sender_verkey\": \"DWwLsbKCRAbYtfYnQNmzfKV7ofVhMBi6T4o3d2SCxVuX\"\n}\n</code></pre>"},{"location":"aip2/0019-encryption-envelope/#unpack_message-return-values-anoncrypt-mode","title":"unpack_message() return values (anoncrypt mode)","text":"<pre><code>{\n    \"message\": \"{ \\\"@id\\\": \\\"123456780\\\",\\\"@type\\\":\\\"https://didcomm.org/basicmessage/1.0/message\\\",\\\"sent_time\\\": \\\"2019-01-15 18:42:01Z\\\",\\\"content\\\": \\\"Your hovercraft is full of eels.\\\"}\",\n    \"recipient_verkey\": \"2GXmuCN2JCxSqMRVftBHLxVJKSL5bXyzM8DsPzGqQoNj\"\n}\n</code></pre>"},{"location":"aip2/0019-encryption-envelope/#additional-notes","title":"Additional Notes","text":"<ul> <li> <p>All <code>kid</code> values used currently are base58 encoded ed25519 keys. If other keys types are used, say secp256k1, base58 encoding should also be used here for interoperability.</p> </li> <li> <p>All algorithm APIs which use libsodium are from sodiumoxide rust wrapping of the original C implementation.</p> </li> </ul>"},{"location":"aip2/0019-encryption-envelope/#drawbacks","title":"Drawbacks","text":"<p>The current implementation of the <code>pack()</code> message is currently Hyperledger Aries specific. It is based on common crypto libraries (NaCl), but the wrappers are not commonly used outside of Aries. There's currently work being done to fine alignment on a cross-ecosystem interoperable protocol, but this hasn't been achieved yet. This work will hopefully bridge this gap.</p>"},{"location":"aip2/0019-encryption-envelope/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>As the JWE standard currently stands, it does not follow this format. We're actively working with the lead writer of the JWE spec to find alignment and are hopeful the changes needed can be added.</p> <p>We've also looked at using the Message Layer Security (MLS) specification. This specification shows promise for adoption later on with more maturity. Additionally because they aren't hiding metadata related to the sender (Sender Anonymity), we would need to see some changes made to the specification before we could adopt this spec.</p>"},{"location":"aip2/0019-encryption-envelope/#prior-art","title":"Prior art","text":"<p>The JWE family of encryption methods.</p>"},{"location":"aip2/0019-encryption-envelope/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>How transport protocols (https, zmq, etc.) will be be used to send Encrypted Envelopes?<ul> <li>These will need to be defined using separate RFCs. For example, HTTP might POST a message and place it in the body of the HTTP POST.</li> </ul> </li> <li>How will the encrypted envelopes work with routing tables to pass a message through a domain, potentially over various transport protocols?<ul> <li>There's not much certainty whether routing tables or some other mechanism will be used. This needs to be defined in another RFC.</li> </ul> </li> <li>If the encryption envelope protocol fails, how is that failure passed back to those involved in the transmission?<ul> <li>This should be handled using the Report Problem Protocol which is currently demonstrated RFC #35 by Stephen Curran.</li> </ul> </li> </ul>"},{"location":"aip2/0019-encryption-envelope/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community Aries Framework - .NET .NET framework for building agents of all types Streetcred.id Commercial mobile and web app built using Aries Framework - .NET Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Aries Framework - Go For building agents, hubs and other DIDComm ../../features in GoLang. Aries Protocol Test Suite"},{"location":"aip2/0019-encryption-envelope/schema/","title":"Schema","text":"<p>This spec is according JSON Schema v0.7 <pre><code>{\n    \"id\": \"https://github.com/hyperledger/indy-agent/wiremessage.json\",\n    \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n    \"title\": \"Json Web Message format\",\n    \"type\": \"object\",\n    \"required\": [\"ciphertext\", \"iv\", \"protected\", \"tag\"],\n    \"properties\": {\n        \"protected\": {\n            \"type\": \"object\",\n            \"description\": \"Additional authenticated message data base64URL encoded, so it can be verified by the recipient using the tag\",\n            \"required\": [\"enc\", \"typ\", \"alg\", \"recipients\"],\n            \"properties\": {\n                \"enc\": {\n                    \"type\": \"string\",\n                    \"enum\": [\"xchacha20poly1305_ietf\"],\n                    \"description\": \"The authenticated encryption algorithm used to encrypt the ciphertext\"\n                },\n                \"typ\": { \n                    \"type\": \"string\",\n                    \"description\": \"The message type. Ex: JWM/1.0\"\n                },\n                \"alg\": {\n                    \"type\": \"string\",\n                    \"enum\": [ \"authcrypt\", \"anoncrypt\"]\n                },\n                \"recipients\": {\n                    \"type\": \"array\",\n                    \"description\": \"A list of the recipients who the message is encrypted for\",\n                    \"items\": {\n                        \"type\": \"object\",\n                        \"required\": [\"encrypted_key\", \"header\"],\n                        \"properties\": {\n                            \"encrypted_key\": {\n                                \"type\": \"string\",\n                                \"description\": \"The key used for encrypting the ciphertext. This is also referred to as a cek\"\n                            },\n                            \"header\": {\n                                \"type\": \"object\",\n                                \"required\": [\"kid\"],\n                                \"description\": \"The recipient to whom this message will be sent\",\n                                \"properties\": {\n                                    \"kid\": {\n                                        \"type\": \"string\",\n                                        \"description\": \"base58 encoded verkey of the recipient.\"\n                                    }\n                                }\n                            }\n                        }\n                    }\n                 },     \n            },\n        },\n        \"iv\": {\n            \"type\": \"string\",\n            \"description\": \"base64 URL encoded nonce used to encrypt ciphertext\"\n        },\n        \"ciphertext\": {\n            \"type\": \"string\",\n            \"description\": \"base64 URL encoded authenticated encrypted message\"\n        },\n        \"tag\": {\n            \"type\": \"string\",\n            \"description\": \"Integrity checksum/tag base64URL encoded to check ciphertext, protected, and iv\"\n        }\n    }\n}\n</code></pre></p>"},{"location":"aip2/0020-message-types/","title":"Aries RFC 0020: Message Types","text":"<ul> <li>Authors: Daniel Bluhm, Sam Curren</li> <li>Status: ADOPTED</li> <li>Since: 2019-05-24</li> <li>Status Note:  </li> <li>Supersedes: HIPE 0021 Message Types</li> <li>Start Date: 2018-07-06</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0020-message-types/#summary","title":"Summary","text":"<p>Define structure of message type strings used in agent to agent communication, describe their resolution to documentation URIs, and offer guidelines for protocol specifications.</p>"},{"location":"aip2/0020-message-types/#motivation","title":"Motivation","text":"<p>A clear convention to follow for agent developers is necessary for interoperability and continued progress as a community.</p>"},{"location":"aip2/0020-message-types/#tutorial","title":"Tutorial","text":"<p>A \"Message Type\" is a required attribute of all communications sent between parties. The message type instructs the receiving agent how to interpret the content and what content to expect as part of a given message.</p> <p>Types are specified within a message using the <code>@type</code> attribute:</p> <pre><code>{\n    \"@type\": \"&lt;message type string&gt;\",\n    // other attributes\n}\n</code></pre> <p>Message types are URIs that may resolve to developer documentation for the message type, as described in Protocol URIs. We recommend that message type URIs be HTTP URLs.</p>"},{"location":"aip2/0020-message-types/#aries-core-message-namespace","title":"Aries Core Message Namespace","text":"<p><code>https://didcomm.org/</code> is used to namespace protocols defined by the community as \"core protocols\" or protocols that agents should minimally support.</p> <p>The <code>didcomm.org</code> DNS entry is currently controlled by the Decentralized Identity Foundation (DIF) based on their role in standardizing the DIDComm Messaging specification.</p>"},{"location":"aip2/0020-message-types/#protocols","title":"Protocols","text":"<p>Protocols provide a logical grouping for message types. These protocols, along with each type belonging to that protocol, are to be defined in future RFCs or through means appropriate to subprojects.</p>"},{"location":"aip2/0020-message-types/#protocol-versioning","title":"Protocol Versioning","text":"<p>Version numbering should essentially follow Semantic Versioning 2.0.0, excluding patch version number. To summarize, a change in the major protocol version number indicates a breaking change while the minor protocol version number indicates non-breaking additions.</p>"},{"location":"aip2/0020-message-types/#message-type-design-guidelines","title":"Message Type Design Guidelines","text":"<p>These guidelines are guidelines on purpose. There will be situations where a good design will have to choose between conflicting points, or ignore all of them. The goal should always be clear and good design.</p>"},{"location":"aip2/0020-message-types/#respect-reserved-attribute-names","title":"Respect Reserved Attribute Names","text":"<p>Reserved attributes are prefixed with an <code>@</code> sign, such as <code>@type</code>. Don't use this prefix for an attribute, even if use of that specific attribute is undefined.</p>"},{"location":"aip2/0020-message-types/#avoid-ambiguous-attribute-names","title":"Avoid ambiguous attribute names","text":"<p>Data, id, and package, are often terrible names. Adjust the name to enhance meaning. For example, use  <code>message_id</code> instead of <code>id</code>.</p>"},{"location":"aip2/0020-message-types/#avoid-names-with-special-characters","title":"Avoid names with special characters","text":"<p>Technically, attribute names can be any valid json key (except prefixed with @, as mentioned above). Practically, you should avoid using special characters, including those that need to be escaped. Underscores and dashes [_,-] are totally acceptable, but you should avoid quotation marks, punctuation, and other symbols.</p>"},{"location":"aip2/0020-message-types/#use-attributes-consistently-within-a-protocol","title":"Use attributes consistently within a protocol","text":"<p>Be consistent with attribute names between the different types within a protocol. Only use the same attribute name for the same data. If the attribute values are similar, but not exactly the same, adjust the name to indicate the difference.</p>"},{"location":"aip2/0020-message-types/#nest-attributes-only-when-useful","title":"Nest Attributes only when useful","text":"<p>Attributes do not need to be nested under a top level attribute, but can be to organize related attributes. Nesting all message attributes under one top level attribute is usually not a good idea.</p>"},{"location":"aip2/0020-message-types/#design-examples","title":"Design Examples","text":""},{"location":"aip2/0020-message-types/#example-1","title":"Example 1","text":"<pre><code>{\n    \"@type\": \"did:example:00000;spec/pizzaplace/1.0/pizzaorder\",\n    \"content\": {\n        \"id\": 15,\n        \"name\": \"combo\",\n        \"prepaid?\": true,\n        \"ingredients\": [\"pepperoni\", \"bell peppers\", \"anchovies\"]\n    }\n}\n</code></pre> <p>Suggestions: Ambiguous names, unnecessary nesting, symbols in names.</p>"},{"location":"aip2/0020-message-types/#example-1-fixed","title":"Example 1 Fixed","text":"<pre><code>{\n    \"@type\": \"did:example:00000;spec/pizzaplace/1.0/pizzaorder\",\n    \"table_id\": 15,\n    \"pizza_name\": \"combo\",\n    \"prepaid\": true,\n    \"ingredients\": [\"pepperoni\", \"bell peppers\", \"anchovies\"]\n}\n</code></pre>"},{"location":"aip2/0020-message-types/#reference","title":"Reference","text":"<ul> <li>Daniel Hardman's Agent Summit Notes</li> <li>Stephen Curran's presentation summarizing the Agent Summit</li> <li>Semantic Versioning</li> <li>DIDComm Message Anatomy</li> </ul>"},{"location":"aip2/0020-message-types/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community Aries Framework - .NET .NET framework for building agents of all types Streetcred.id Commercial mobile and web app built using Aries Framework - .NET Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Aries Framework - Go For building agents, hubs and other DIDComm ../../features in GoLang. Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem."},{"location":"aip2/0023-did-exchange/","title":"Aries RFC 0023: DID Exchange Protocol 1.0","text":"<ul> <li>Authors: Ryan West, Daniel Bluhm, Matthew Hailstone, Stephen Curran, Sam Curren, Stephen Curran, George Aristy</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Replaces RFC 0160 - Connection Protocol and is a part of AIP 2.0.</li> <li>Supersedes: RFC 0160 - Connection Protocol</li> <li>Start Date: 2018-06-29</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"aip2/0023-did-exchange/#summary","title":"Summary","text":"<p>This RFC describes the protocol to exchange DIDs between agents when establishing a DID based relationship.</p>"},{"location":"aip2/0023-did-exchange/#motivation","title":"Motivation","text":"<p>Aries agent developers want to create agents that are able to establish relationships with each other and exchange secure information using keys and endpoints in DID Documents. For this to happen there must be a clear protocol to exchange DIDs.</p>"},{"location":"aip2/0023-did-exchange/#tutorial","title":"Tutorial","text":"<p>We will explain how DIDs are exchanged, with the roles, states, and messages required.</p>"},{"location":"aip2/0023-did-exchange/#roles","title":"Roles","text":"<p>The DID Exchange Protocol uses two roles: requester and responder.</p> <p>The requester is the party that initiates this protocol after receiving an <code>invitation</code> message (using RFC 0434 Out of Band) or by using an implied invitation from a public DID. For example, a verifier might get the DID of the issuer of a credential they are verifying, and use information in the DIDDoc for that DID as the basis for initiating an instance of this protocol.</p> <p>Since the requester receiving an explicit invitation may not have an Aries agent, it is desirable, but not strictly, required that sender of the invitation (who has the responder role in this protocol) have the ability to help the requester with the process and/or costs associated with acquiring an agent capable of participating in the ecosystem. For example, the sender of an invitation may often be sponsoring institutions.</p> <p>The responder, who is the sender of an explicit invitation or the publisher of a DID with an implicit invitation, must have an agent capable of interacting with other agents via DIDComm.</p> <p>In cases where both parties already possess SSI capabilities, deciding who plays the role of requester and responder  might be a casual matter of whose phone is handier.</p>"},{"location":"aip2/0023-did-exchange/#states","title":"States","text":""},{"location":"aip2/0023-did-exchange/#requester","title":"Requester","text":"<p>The requester goes through the following states per the State Machine Tables below</p> <ul> <li>start</li> <li>invitation-received</li> <li>request-sent</li> <li>response-received</li> <li>abandoned</li> <li>completed</li> </ul>"},{"location":"aip2/0023-did-exchange/#responder","title":"Responder","text":"<p>The responder goes through the following states per the State Machine Tables below</p> <ul> <li>start</li> <li>invitation-sent</li> <li>request-received</li> <li>response-sent</li> <li>abandoned</li> <li>completed</li> </ul>"},{"location":"aip2/0023-did-exchange/#state-machine-tables","title":"State Machine Tables","text":"<p>The following are the requester and responder state machines.</p> <p>The <code>invitation-sent</code> and <code>invitation-received</code> are technically outside this protocol, but are useful to show in the state machine as the invitation is the trigger to start the protocol and is referenced from the protocol as the parent thread (<code>pthid</code>).  This is discussed in more detail below.</p> <p>The <code>abandoned</code> and <code>completed</code> states are terminal states and there is no expectation that the protocol can be continued (or even referenced) after reaching those states.</p> <p></p>"},{"location":"aip2/0023-did-exchange/#errors","title":"Errors","text":"<p>After receiving an explicit invitation, the requester may send a <code>problem-report</code> to the responder using the information in the invitation to either restart the invitation process (returning to the <code>start</code> state) or to abandon the protocol. The <code>problem-report</code> may be an adopted  <code>Out of Band</code> protocol message or an adopted <code>DID Exchange</code> protocol message, depending on where in the processing of the invitation the error was detected.</p> <p>During the <code>request</code> / <code>response</code> part of the protocol, there are two protocol-specific error messages possible: one for an active rejection and one for an unknown error. These errors are sent using a problem_report message type specific to the DID Exchange Protocol. These errors do not transition the protocol to the <code>abandoned</code> state. The following list details <code>problem-code</code>s that may be sent in these cases:</p> <p>request_not_accepted - The error indicates that the <code>request</code> message has been rejected for a reason listed in the <code>error_report</code>. Typical reasons include not accepting the method of the provided DID, unknown endpoint protocols, etc. The <code>request</code> can be resent after the appropriate corrections have been made.</p> <p>request_processing_error - This error is sent when the responder was processing the request with the intent to accept the request, but some processing error occurred. This error indicates that the <code>request</code> should be resent as-is.</p> <p>response_not_accepted - The error indicates that the <code>response</code> has been rejected for a reason listed in the <code>error_report</code>. Typical reasons include not accepting the method of the provided DID, unknown endpoint protocols, invalid signature, etc. The <code>response</code> can be resent after the appropriate corrections have been made.</p> <p>response_processing_error - This error is sent when the requester was processing the <code>response</code> with the intent to accept the response, but some processing error occurred. This error indicates that the <code>response</code> should be resent as-is.</p> <p>If other errors occur, the corresponding party may send a <code>problem-report</code> to inform the other party they are abandoning the protocol.</p> <p>No errors are sent in timeout situations. If the requester or responder wishes to retract the messages they sent, they record so locally and return a <code>request_not_accepted</code> or <code>response_not_accepted</code> error when the other party sends a <code>request</code> or <code>response</code>.</p>"},{"location":"aip2/0023-did-exchange/#error-message-example","title":"Error Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/didexchange/1.0/problem_report\",\n  \"@id\": \"5678876542345\",\n  \"~thread\": { \"thid\": \"&lt;@id of message related to problem&gt;\" },\n  \"~l10n\": { \"locale\": \"en\"},\n  \"problem-code\": \"request_not_accepted\", // matches codes listed above\n  \"explain\": \"Unsupported DID method for provided DID.\"\n}\n</code></pre>"},{"location":"aip2/0023-did-exchange/#error-message-attributes","title":"Error Message Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is a problem_report within the didexchange protocol.</li> <li>The <code>~thread</code> attribute provides a context for the problem, referring to the message which contains the problem.</li> <li>Use of <code>~l10n</code> is encouraged, with at least locale defined for the message.</li> <li>The <code>problem-code</code> attribute contains one of a fixed set of codes defined in the list above.</li> <li>The <code>explain</code> attribute contains a human readable message which indicates the problem.</li> </ul>"},{"location":"aip2/0023-did-exchange/#flow-overview","title":"Flow Overview","text":"<ul> <li>The responder gives provisional information to the requester using an explicit <code>invitation</code> message from the <code>out-of-band</code> protocol or an implicit invitation in a DID the responder publishes.</li> <li>In the <code>out-of-band</code> protocol, the responder is called the sender, and the requester is called the receiver.</li> <li>The requester uses the provisional information to send a DID and DID Doc to the responder in a <code>request</code> message.</li> <li>The responder uses sent DID Doc information to send a DID and DID Doc to the requester in a <code>response</code> message.</li> <li>The requester sends the responder a <code>complete</code> message that confirms the <code>response</code> message was received.</li> </ul>"},{"location":"aip2/0023-did-exchange/#implicit-and-explicit-invitations","title":"Implicit and Explicit Invitations","text":"<p>The DID Exchange Protocol is preceded by  - either knowledge of a resolvable DID (an implicit invitation)  - or by a <code>out-of-band/%VER/invitation</code> message from the Out Of Band Protocols RFC. </p> <p>The information needed to construct the <code>request</code> message to start the protocol is used - either from the resolved DID Document  - or the <code>service</code> element of the <code>handshake_protocols</code> attribute of the <code>invitation</code>.</p>"},{"location":"aip2/0023-did-exchange/#1-exchange-request","title":"1. Exchange Request","text":"<p>The <code>request</code> message is used to communicate the DID document of the requester to the responder using the provisional service information present in the (implicit or explicit) invitation.</p> <p>The requester may provision a new DID according to the DID method spec. For a Peer DID, this involves creating a matching peer DID and key. The newly provisioned DID and DID Doc is presented in the <code>request</code> message as follows:</p>"},{"location":"aip2/0023-did-exchange/#request-message-example","title":"Request Message Example","text":"<pre><code>{\n  \"@id\": \"5678876542345\",\n  \"@type\": \"https://didcomm.org/didexchange/1.0/request\",\n  \"~thread\": { \n      \"thid\": \"5678876542345\",\n      \"pthid\": \"&lt;id of invitation&gt;\"\n  },\n  \"label\": \"Bob\",\n  \"goal_code\": \"aries.rel.build\",\n  \"goal\": \"To create a relationship\",\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n      \"@id\": \"d2ab6f2b-5646-4de3-8c02-762f553ab804\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n         \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n         \"jws\": {\n            \"header\": {\n               \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n            },\n            \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n            \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n            }\n      }\n   }\n}\n</code></pre>"},{"location":"aip2/0023-did-exchange/#request-message-attributes","title":"Request Message Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is an exchange request.</li> <li>The <code>~thread</code> decorator MUST be included:</li> <li>It MUST include the ID of the parent thread (<code>pthid</code>) such that the <code>request</code> can be correlated to the corresponding (implicit or explicit) <code>invitation</code>. More on correlation below.</li> <li>It MAY include the <code>thid</code> property. This works according to the <code>thid</code> property in the thread decorator, meaning that if <code>thid</code> is not defined it is implicitly defined as the <code>@id</code> on the same <code>request</code> message.</li> <li>The <code>label</code> attribute provides a suggested label for the DID being exchanged. This allows the user to tell multiple exchange requests apart. This is not a trusted attribute. (See note on <code>label</code> below)</li> <li>The <code>goal_code</code> (optional) is a self-attested code the receiver may want to display to the user or use in automatically deciding what to do with the request message. The goal code might be used particularly when the request is sent to a resolvable DID without reference to a specfic invitation.</li> <li>The goal (optional) is a self-attested string that the receiver may want to display to the user about the context-specific goal of the request message.</li> <li>The <code>did</code> attribute MUST be included. It indicates the DID being exchanged.</li> <li>The <code>did_doc~attach</code> (optional), contains the DIDDoc associated with the <code>did</code>, if required.</li> <li>If the <code>did</code> is resolvable (either an inline <code>peer:did</code> or a publicly resolvable DID), the <code>did_doc~attach</code> attribute should not be included.</li> <li>If the DID is a <code>did:peer</code> DID, the DIDDoc must be as outlined in RFC 0627 Static Peer DIDs.</li> </ul> <p>The <code>label</code> property was intended to be declared as an optional property, but was added to the RFC as a required property. If an agent wishes to not use a label in the request, an empty string (<code>\"\"</code>) or the set value <code>Unspecified</code> may be used to indicate a non-value. This approach ensures existing AIP 2.0 implementations do not break.</p>"},{"location":"aip2/0023-did-exchange/#correlating-requests-to-invitations","title":"Correlating requests to invitations","text":"<p>An invitation is presented in one of two forms:</p> <ul> <li>An explicit out-of-band invitation with its own <code>@id</code>.</li> <li>An implicit invitation contained in a DID document's <code>service</code> attribute that conforms to the DIDComm conventions.</li> </ul> <p>When a <code>request</code> responds to an explicit invitation, its <code>~thread.pthid</code> MUST be equal to the <code>@id</code> property of the invitation as described in the out-of-band RFC.</p> <p>When a <code>request</code> responds to an implicit invitation, its <code>~thread.pthid</code> MUST contain a DID URL that resolves to the specific <code>service</code> on a DID document that contains the invitation.</p>"},{"location":"aip2/0023-did-exchange/#example-referencing-an-explicit-invitation","title":"Example Referencing an Explicit Invitation","text":"<pre><code>{\n  \"@id\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n  \"@type\": \"https://didcomm.org/didexchange/1.0/request\",\n  \"~thread\": { \n      \"thid\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n      \"pthid\": \"032fbd19-f6fd-48c5-9197-ba9a47040470\" \n  },\n  \"label\": \"Bob\",\n  \"goal_code\": \"aries.rel.build\",\n  \"goal\": \"To create a relationship\",\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n      \"@id\": \"d2ab6f2b-5646-4de3-8c02-762f553ab804\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n         \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n         \"jws\": {\n            \"header\": {\n               \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n            },\n            \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n            \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n            }\n      }\n   }\n}\n</code></pre>"},{"location":"aip2/0023-did-exchange/#example-referencing-an-implicit-invitation","title":"Example Referencing an Implicit Invitation","text":"<pre><code>{\n  \"@id\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n  \"@type\": \"https://didcomm.org/didexchange/1.0/request\",\n  \"~thread\": { \n      \"thid\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n      \"pthid\": \"did:example:21tDAKCERh95uGgKbJNHYp#didcomm\" \n  },\n  \"label\": \"Bob\",\n  \"goal_code\": \"aries.rel.build\",\n  \"goal\": \"To create a relationship\",\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n      \"@id\": \"d2ab6f2b-5646-4de3-8c02-762f553ab804\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n         \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n         \"jws\": {\n            \"header\": {\n               \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n            },\n            \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n            \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n            }\n      }\n   }\n}\n</code></pre>"},{"location":"aip2/0023-did-exchange/#request-transmission","title":"Request Transmission","text":"<p>The <code>request</code> message is encoded according to the standards of the Encryption Envelope, using the <code>recipientKeys</code> present in the invitation.</p> <p>If the <code>routingKeys</code> attribute was present and non-empty in the invitation, each key must be used to wrap the message in a forward request, then encoded in an Encryption Envelope. This processing is in order of the keys in the list, with the last key in the list being the one for which the <code>serviceEndpoint</code> possesses the private key.</p> <p>The message is then transmitted to the <code>serviceEndpoint</code>.</p> <p>The requester is in the <code>request-sent</code> state. When received, the responder is in the <code>request-received</code> state.</p>"},{"location":"aip2/0023-did-exchange/#request-processing","title":"Request processing","text":"<p>After receiving the exchange request, the responder evaluates the provided DID and DID Doc according to the DID Method Spec.</p> <p>The responder should check the information presented with the keys used in the wire-level message transmission to ensure they match.</p> <p>The responder MAY look up the corresponding invitation identified in the request's <code>~thread.pthid</code> to determine whether it should accept this exchange request.</p> <p>If the responder wishes to continue the exchange, they will persist the received information in their wallet. They will then either update the provisional service information to rotate the key, or provision a new DID entirely. The choice here will depend on the nature of the DID used in the invitation.</p> <p>The responder will then craft an exchange response using the newly updated or provisioned information.</p>"},{"location":"aip2/0023-did-exchange/#request-errors","title":"Request Errors","text":"<p>See Error Section above for message format details.</p>"},{"location":"aip2/0023-did-exchange/#request-rejected","title":"Request Rejected","text":"<p>Possible reasons:</p> <ul> <li>Unsupported DID method for provided DID</li> <li>Expired Invitation</li> <li>DID Doc Invalid</li> <li>Unsupported key type</li> <li>Unsupported endpoint protocol</li> <li>Missing reference to invitation</li> </ul>"},{"location":"aip2/0023-did-exchange/#request-processing-error","title":"Request Processing Error","text":"<ul> <li>unknown processing error</li> </ul>"},{"location":"aip2/0023-did-exchange/#2-exchange-response","title":"2. Exchange Response","text":"<p>The exchange response message is used to complete the exchange. This message is required in the flow, as it updates the provisional information presented in the invitation.</p>"},{"location":"aip2/0023-did-exchange/#response-message-example","title":"Response Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/didexchange/1.0/response\",\n  \"@id\": \"12345678900987654321\",\n  \"~thread\": {\n    \"thid\": \"&lt;The Thread ID is the Message ID (@id) of the first message in the thread&gt;\"\n  },\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n      \"@id\": \"d2ab6f2b-5646-4de3-8c02-762f553ab804\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n         \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n         \"jws\": {\n            \"header\": {\n               \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n            },\n            \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n            \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n            }\n      }\n   }\n}\n</code></pre> <p>The invitation's <code>recipientKeys</code> should be dedicated to envelopes authenticated encryption throughout the exchange. These keys are usually defined in the <code>KeyAgreement</code> DID verification relationship.</p>"},{"location":"aip2/0023-did-exchange/#response-message-attributes","title":"Response Message Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is an exchange request.</li> <li>The <code>~thread</code> decorator MUST be included. It contains a <code>thid</code> reference to the <code>@id</code> of the request message.</li> <li>The <code>did</code> attribute MUST be included. It denotes the DID in use by the responder. Note that this MAY NOT be the same DID used in the invitation.</li> <li>The <code>did_doc~attach</code> optional, contains the DID Doc associated with the <code>did</code>, if required.</li> <li>If the <code>did</code> is resolvable (either an inline <code>peer:did</code> or a publicly resolvable DID), the <code>did_doc~attach</code> attribute should not be included.</li> <li>If the DID is a <code>did:peer</code> identifier, the DIDDoc must be as outlined in RFC 0627 Static Peer DIDs.</li> </ul> <p>In addition to a new DID, the associated DID Doc might contain a new endpoint. This new DID and endpoint are to be used going forward in the relationship.</p>"},{"location":"aip2/0023-did-exchange/#response-transmission","title":"Response Transmission","text":"<p>The message should be packaged in the encrypted envelope format, using the keys from the request, and the new keys presented in the internal did doc.</p> <p>When the message is sent, the responder are now in the <code>response-sent</code> state. On receipt, the requester is in the <code>response-received</code> state.</p>"},{"location":"aip2/0023-did-exchange/#response-processing","title":"Response Processing","text":"<p>When the requester receives the <code>response</code> message, they will decrypt the authenticated envelope which confirms the source's authenticity. After decryption validation, they will update their wallet with the new information, and use that information in sending the <code>complete</code> message.</p>"},{"location":"aip2/0023-did-exchange/#response-errors","title":"Response Errors","text":"<p>See Error Section above for message format details.</p>"},{"location":"aip2/0023-did-exchange/#response-rejected","title":"Response Rejected","text":"<p>Possible reasons:</p> <ul> <li>unsupported DID method for provided DID</li> <li>Expired Request</li> <li>DID Doc Invalid</li> <li>Unsupported key type</li> <li>Unsupported endpoint protocol</li> <li>Invalid Signature</li> </ul>"},{"location":"aip2/0023-did-exchange/#response-processing-error","title":"Response Processing Error","text":"<ul> <li>unknown processing error</li> </ul>"},{"location":"aip2/0023-did-exchange/#3-exchange-complete","title":"3. Exchange Complete","text":"<p>The exchange <code>complete</code> message is used to confirm the exchange to the responder. This message is required in the flow, as it marks the exchange complete. The responder may then invoke any protocols desired based on the context expressed via the <code>pthid</code> in the DID Exchange protocol.</p>"},{"location":"aip2/0023-did-exchange/#complete-message-example","title":"Complete Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/didexchange/1.0/complete\",\n  \"@id\": \"12345678900987654321\",\n  \"~thread\": {\n    \"thid\": \"&lt;The Thread ID is the Message ID (@id) of the first message in the thread&gt;\",\n    \"pthid\": \"&lt;pthid used in request message&gt;\"\n  }\n}\n</code></pre> <p>The <code>pthid</code> is required in this message, and must be identical to the <code>pthid</code> used in the <code>request</code> message.</p> <p>After a <code>complete</code> message is sent, the requester is in the <code>completed</code> terminal state. Receipt of the message puts the responder into the <code>completed</code> state.</p>"},{"location":"aip2/0023-did-exchange/#complete-errors","title":"Complete Errors","text":"<p>See Error Section above for message format details.</p>"},{"location":"aip2/0023-did-exchange/#complete-rejected","title":"Complete Rejected","text":"<p>This is unlikely to occur with other than an unknown processing error (covered below), so no possible reasons are listed. As experience is gained with the protocol, possible reasons may be added.</p>"},{"location":"aip2/0023-did-exchange/#complete-processing-error","title":"Complete Processing Error","text":"<ul> <li>unknown processing error</li> </ul>"},{"location":"aip2/0023-did-exchange/#next-steps","title":"Next Steps","text":"<p>The exchange between the requester and the responder has been completed. This relationship has no trust associated with it. The next step should be to increase the trust to a sufficient level for the purpose of the relationship, such as through an exchange of proofs.</p>"},{"location":"aip2/0023-did-exchange/#peer-did-maintenance","title":"Peer DID Maintenance","text":"<p>When Peer DIDs are used in an exchange, it is likely that both the requester and responder will want to perform some relationship maintenance such as key rotations. Future RFC updates will add these maintenance ../../features.</p>"},{"location":"aip2/0023-did-exchange/#reference","title":"Reference","text":"<ul> <li>https://docs.google.com/document/d/1mRLPOK4VmU9YYdxHJSxgqBp19gNh3fT7Qk4Q069VPY8/edit#heading=h.7sxkr7hbou5i</li> <li>Agent to Agent Communication Video</li> <li>Agent to Agent Communication Presentation</li> <li>Problem_report message adopted into message family, following form defined by the Problem Report HIPE</li> <li>RFC0519 Goal Codes</li> </ul>"},{"location":"aip2/0023-did-exchange/#drawbacks","title":"Drawbacks","text":"<p>N/A at this time</p>"},{"location":"aip2/0023-did-exchange/#prior-art","title":"Prior art","text":"<ul> <li>This process is similar to other key exchange protocols.</li> </ul>"},{"location":"aip2/0023-did-exchange/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>N/A at this time</li> </ul>"},{"location":"aip2/0023-did-exchange/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Trinsic.id Commercial mobile and web app built using Aries Framework - .NET MISSING test results"},{"location":"aip2/0025-didcomm-transports/","title":"Aries RFC 0025: DIDComm Transports","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: ADOPTED</li> <li>Since: 2019-12-05</li> <li>Status Note:  </li> <li>Supersedes: INDY PR 94</li> <li>Start Date: 2019-02-26</li> <li>Tags: feature</li> </ul>"},{"location":"aip2/0025-didcomm-transports/#summary","title":"Summary","text":"<p>This RFC Details how different transports are to be used for Agent Messaging.</p>"},{"location":"aip2/0025-didcomm-transports/#motivation","title":"Motivation","text":"<p>Agent Messaging is designed to be transport independent, including message encryption and agent message format. Each transport does have unique ../../features, and we need to standardize how the transport ../../features are (or are not) applied.</p>"},{"location":"aip2/0025-didcomm-transports/#reference","title":"Reference","text":"<p>Standardized transport methods are detailed here.</p>"},{"location":"aip2/0025-didcomm-transports/#https","title":"HTTP(S)","text":"<p>HTTP(S) is the first, and most used transport for DID Communication that has received heavy attention. </p> <p>While it is recognized that all DIDComm messages are secured through strong encryption, making HTTPS somewhat redundant, it will likely cause issues with mobile clients because venders (Apple and Google) are limiting application access to the HTTP protocol. For example, on iOS 9 or above where [ATS])(https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity) is in effect, any URLs using HTTP must have an exception hard coded in the application prior to uploading to the iTunes Store. This makes DIDComm unreliable as the agent initiating the the request provides an endpoint for communication that the mobile client must use. If the agent provides a URL using the HTTP protocol it will likely be unusable due to low level operating system limitations.</p> <p>As a best practice, when HTTP is used in situations where a mobile client (iOS or Android) may be involved it is highly recommended to use the HTTPS protocol, specifically TLS 1.2 or above. </p> <p>Other important notes on the subject of using HTTP(S) include:</p> <ul> <li>Messages are transported via HTTP POST.</li> <li>The MIME Type for the POST request is <code>application/didcomm-envelope-enc</code>; see RFC 0044: DIDComm File and MIME Types for more details.</li> <li>A received message should be responded to with a 202 Accepted status code. This indicates that the request was received, but not necessarily processed. Accepting a 200 OK status code is allowed.</li> <li>POST requests are considered transmit only by default. No agent messages will be returned in the response. This behavior may be modified with additional signaling.</li> <li>Using HTTPS with TLS 1.2 or greater with a forward secret cipher will provide Perfect Forward Secrecy (PFS) on the transmission leg.</li> </ul>"},{"location":"aip2/0025-didcomm-transports/#known-implementations","title":"Known Implementations","text":"<p>Aries Cloud Agent - Python Aries Framework - .NET</p>"},{"location":"aip2/0025-didcomm-transports/#websocket","title":"Websocket","text":"<p>Websockets are an efficient way to transmit multiple messages without the overhead of individual requests.</p> <ul> <li>Each message is transmitted individually in an Encryption Envelope.</li> <li>The trust of each message comes from the Encryption Envelope, not the socket connection itself.</li> <li>Websockets are considered transmit only by default. Messages will only flow from the agent that opened the socket. This behavior may be modified with additional signaling.</li> <li>Using Secure Websockets (wss://) with TLS 1.2 or greater with a forward secret cipher will provide Perfect Forward Secrecy (PFS) on the transmission leg.</li> </ul>"},{"location":"aip2/0025-didcomm-transports/#known-implementations_1","title":"Known Implementations","text":"<p>Aries Cloud Agent - Python Aries Framework - .NET</p>"},{"location":"aip2/0025-didcomm-transports/#xmpp","title":"XMPP","text":"<p>XMPP is an effective transport for incoming DID-Communication messages directly to mobile agents, like smartphones.</p> <ul> <li>Incoming DID-Communication messages will arrive, even if the mobile agent is behind a firewall and network-address-translation (NAT).</li> <li>Incoming DID-Communication messages continue to arrive, even when the IP address of the mobile agent changes (switching between, 3G, 4G, Wifi, roaming, ...).</li> <li>Independent of cloud agents and routing agents, as messages arrive directly at the mobile agent.</li> <li>Well suited for direct consumer-to-consumer SSI transactions, from one mobile agent directly to another mobile agent without any DID-Communication intermediaries.</li> <li>Simple encapsulation of DIDcom messages, getting trust from the DIDcom Encryption Envelope.</li> <li>Specified in Aries RFC 0024: DIDCom-over-XMPP</li> </ul>"},{"location":"aip2/0025-didcomm-transports/#known-implementations_2","title":"Known Implementations","text":"<p>XMPP is implemented in the Openfire Server open source project. Integration with DID Communication agents is work-in-progress.</p>"},{"location":"aip2/0025-didcomm-transports/#other-transports","title":"Other Transports","text":"<p>Other transports may be used for Agent messaging. As they are developed, this RFC should be updated with appropriate standards for the transport method. A PR should be raised against this doc to facilitate discussion of the proposed additions and/or updates. New transports should highlight the common elements of the transport (such as an HTTP response code for the HTTP transport) and how they should be applied.</p>"},{"location":"aip2/0025-didcomm-transports/#message-routing","title":"Message Routing","text":"<p>The transports described here are used between two agents. In the case of message routing, a message will travel across multiple agent connections. Each intermediate agent (see Mediators and Relays) may use a different transport. These transport details are not made known to the sender, who only knows the keys of Mediators and the first endpoint of the route.</p>"},{"location":"aip2/0025-didcomm-transports/#message-context","title":"Message Context","text":"<p>The transport used from a previous agent can be recorded in the message trust context. This is particularly true of controlled network environments, where the transport may have additional security considerations not applicable on the public internet. The transport recorded in the message context only records the last transport used, and not any previous routing steps as described in the Message Routing section of this document.</p>"},{"location":"aip2/0025-didcomm-transports/#transport-testing","title":"Transport Testing","text":"<p>Transports which operate on IP based networks can be tested by an Agent Test Suite through a transport adapter. Some transports may be more difficult to test in a general sense, and may need specialized testing frameworks. An agent with a transport not yet supported by any testing suites may have non-transport testing performed by use of a routing agent.</p>"},{"location":"aip2/0025-didcomm-transports/#drawbacks","title":"Drawbacks","text":"<p>Setting transport standards may prevent some uses of each transport method.</p>"},{"location":"aip2/0025-didcomm-transports/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Without standards for each transport, the assumptions of each agent may not align and prevent communication before each message can be unpacked and evaluated.</li> </ul>"},{"location":"aip2/0025-didcomm-transports/#prior-art","title":"Prior art","text":"<p>Several agent implementations already exist that follow similar conventions.</p>"},{"location":"aip2/0025-didcomm-transports/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"aip2/0025-didcomm-transports/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0035-report-problem/","title":"Aries RFC 0035: Report Problem Protocol 1.0","text":"<ul> <li>Authors: Stephen Curran, Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2021-03-15</li> <li>Status Note: Implemented in multiple codebases.</li> <li>Supersedes: Indy HIPE PR #65</li> <li>Start Date: 2018-11-26</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"aip2/0035-report-problem/#summary","title":"Summary","text":"<p>Describes how to report errors and warnings in a powerful, interoperable way. All implementations of SSI agent or hub technology SHOULD implement this RFC.</p>"},{"location":"aip2/0035-report-problem/#motivation","title":"Motivation","text":"<p>Effective reporting of errors and warnings is difficult in any system, and particularly so in decentralized systems such as remotely collaborating agents. We need to surface problems, and their supporting context, to people who want to know about them (and perhaps separately, to people who can actually fix them). This is especially challenging when a problem is detected well after and well away from its cause, and when multiple parties may need to cooperate on a solution.</p> <p>Interoperability is perhaps more crucial with problem reporting than with any other aspect of DIDComm, since an agent written by one developer MUST be able to understand an error reported by an entirely different team. Notice how different this is from normal enterprise software development, where developers only need to worry about understanding their own errors.</p> <p>The goal of this RFC is to provide agents with tools and techniques possible to address these challenges. It makes two key contributions:</p> <ul> <li>A protocol that helps an Agent report problems with appropriate   context. We expect this to be a subprotocol of nearly every interesting application-level   protocol; messages from it may even be adopted into other protocols.</li> <li>An inventory of problem categories and best practices for handling them.</li> </ul>"},{"location":"aip2/0035-report-problem/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0035-report-problem/#error-vs-warning-vs-problem","title":"\"Error\" vs. \"Warning\" vs. \"Problem\"","text":"<p>The distinction between \"error\" and \"warning\" is often thought of as one of severity -- errors are really bad, and warnings are only somewhat bad. This is reinforced by the way logging platforms assign numeric constants to ERROR vs. WARN log events, and by the way compilers let warnings be suppressed but refuse to ignore errors.</p> <p>However, any cybersecurity professional will tell you that warnings sometimes signal deep and scary problems that should not be ignored, and most veteran programmers can tell war stories that reinforce this wisdom. A deeper analysis of warnings reveals that what truly differentiates them from errors is not their lesser severity, but rather their greater ambiguity. Warnings are problems that require human judgment to evaluate, whereas errors are unambiguously bad.</p> <p>The mechanism for reporting problems in DIDComm cannot make a simplistic assumption that all agents are configured to run with a particular verbosity or debug level. Each agent must let other agents decide for themselves, based on policy or user preference, what do do about various issues. For this reason, we use the generic term \"problem\" instead of the more specific and semantically opinionated term \"error\" (or \"warning\") to describe the general situation we're addressing. \"Problem\" includes any deviation from the so-called \"happy path\" of an interaction. This could include situations where the severity is unknown and must be evaluated by a human, as well as surprising events (e.g., a decision by a human to alter the basis for in-flight messaging by moving from one device to another).</p>"},{"location":"aip2/0035-report-problem/#specific-challenges","title":"Specific Challenges","text":"<p>All of the following challenges need to be addressed.</p> <ol> <li>Report problems to external parties interacting with us.   For example, AliceCorp has to be able to tell Bob that it can\u2019t issue the   credential he requested because his payment didn\u2019t go through.</li> <li>Report problems to other entities inside our own domain. For example,   AliceCorp\u2019s agent #1 has to be able to report to AliceCorp agent #2 that   it is out of disk space.</li> <li>Report in a way that provides human beings with useful context and guidance   to troubleshoot.   Most developers know of cases where error reporting was technically correct but   completely useless. Bad communication about problems is one of the most common   causes of UX debacles. Humans using agents will speak different languages, have   differing degrees of technical competence, and have different software and hardware   resources. They may lack context about what their agents are doing, such as when   a DIDComm interaction occurs as a result of scheduled or policy-driven actions.   This makes context and guidance crucial.</li> <li>Map a problem backward in time, space, and circumstances, so when it is   studied, its original context is available. This is particularly difficult   in DIDComm, which is transport-agnostic and inherently asynchronous, and   which takes place on an inconsistently connected digital landscape.</li> <li>Support localization using techniques in the l10n RFC.</li> <li>Provide consistent, locale-independent problem codes, not just localized text,   so problems can be researched in knowledge bases, on Stack Overflow, and in   other internet forums, regardless of the natural language in which a message   displays. This also helps meaning remain stable as wording is tweaked.</li> <li>Provide a registry of well known problem codes that are carefully defined and   localized, to maximize shared understanding. Maintaining an exhaustive list   of all possible things that can go wrong with all possible agents in all possible   interactions is completely unrealistic. However, it may be possible to maintain   a curated subset. While we can't enumerate everything that can go wrong in a   financial transaction, a code for \"insufficient funds\" might have near-universal   usefulness. Compare the posix error inventory in errorno.h.</li> <li>Facilitate automated problem handling by agents, not just manual handling by humans.   Perfect automation may be impossible, but high levels of automation should be   doable.</li> <li>Clarify how the problem affects an in-progress interaction. Does a failure to   process payment reset the interaction to the very beginning of the protocol, or   just back to the previous step, where payment was requested? This requires problems   to be matched in a formal way to the state machine of a protocol underway.</li> </ol>"},{"location":"aip2/0035-report-problem/#the-report-problem-protocol","title":"The <code>report-problem</code> protocol","text":"<p>Reporting problems uses a simple one-step notification protocol. Its official PIURI is:</p> <pre><code>https://didcomm.org/report-problem/1.0\n</code></pre> <p>The protocol includes the standard <code>notifier</code> and <code>notified</code> roles. It defines a single message type <code>problem-report</code>, introduced here. It also adopts the <code>ack</code> message from the <code>ACK 1.0</code> protocol, to accommodate the possibility that the <code>~please_ack</code> decorator may be used on the  notification.</p> <p>A <code>problem-report</code> communicates about a problem when an agent-to-agent message is possible and a recipient for the problem report is known. This covers, for example, cases where a Sender's message gets to an intended Recipient, but the Recipient is unable to process the message for some reason and wants to notify the Sender. It may also be relevant in cases where the recipient of the <code>problem-report</code> is not a message Sender. Of course, a reporting technique that depends on message delivery doesn't apply when the error reporter can't identify or communicate with the proper recipient.</p>"},{"location":"aip2/0035-report-problem/#the-problem-report-message-type","title":"The <code>problem-report</code> message type","text":"<p>Only <code>description.code</code> is required, but a maximally verbose <code>problem-report</code> could contain all of the following:</p> <pre><code>{\n  \"@type\"            : \"https://didcomm.org/report-problem/1.0/problem-report\",\n  \"@id\"              : \"an identifier that can be used to discuss this error message\",\n  \"~thread\"          : \"info about the threading context in which the error occurred (if any)\",\n  \"description\"      : { \"en\": \"localized message\", \"code\": \"symbolic-name-for-error\" },\n  \"problem_items\"    : [ {\"&lt;item descrip&gt;\": \"value\"} ],\n  \"who_retries\"      : \"enum: you | me | both | none\",\n  \"fix_hint\"         : { \"en\": \"localized error-instance-specific hint of how to fix issue\"},\n  \"impact\"           : \"enum: message | thread | connection\",\n  \"where\"            : \"enum: you | me | other - enum: cloud | edge | wire | agency | ..\",\n  \"noticed_time\"     : \"&lt;time&gt;\",\n  \"tracking_uri\"     : \"\",\n  \"escalation_uri\"   : \"\"\n}\n</code></pre>"},{"location":"aip2/0035-report-problem/#field-reference","title":"Field Reference","text":"<p>Some fields will be relevant and useful in many use cases, but not always. Including empty or null fields is discouraged; best practice is to include as many fields as you can fill with useful data, and to omit the others.</p> <p>@id: An identifier for this message, as described in the message threading RFC. This decorator is STRONGLY recommended, because enables a dialog about the problem itself in a branched thread (e.g., suggest a retry, report a resolution, ask for more information).</p> <p>~thread: A thread decorator that places the <code>problem-report</code> into a thread context. If the problem was triggered in the processing of a message, then the triggering message is the head of a new thread of which the problem report is the second member (<code>~thread.sender_order</code> = 0). In such cases, the <code>~thread.pthid</code> (parent thread id) here would be the <code>@id</code> of the triggering message. If the problem-report is unrelated to a message, the thread decorator is mostly redundant, as <code>~thread.thid</code> must equal <code>@id</code>.</p> <p>description: Contains human-readable, localized alternative string(s) that explain the problem. It is highly recommended that the message follow use the guidance in the l10n RFC, allowing the error to be searched on the web and documented formally.</p> <p>description.code: Required. Contains the code that indicates the problem being communicated. Codes are described in protocol RFCs and other relevant places. New Codes SHOULD follow the Problem Code naming convention detailed in the DIDComm v2 spec.</p> <p>problem_items: A list of one or more key/value pairs that are parameters about the problem. Some examples might be:</p> <ul> <li>a list of arguments that didn\u2019t pass input validation</li> <li>the name of a file or URL that could not be fetched</li> <li>the name of a crypto algorithm that the receiving agent didn\u2019t support</li> </ul> <p>All items should have in common the fact that they exemplify the problem described by the code (e.g., each is an invalid param, or each is an unresponsive URL, or each is an unrecognized crypto algorithm, etc).</p> <p>Each item in the list must be a tagged pair (a JSON {key:value}, where the key names the parameter or item, and the value is the actual problem text/number/value. For example, to report that two different endpoints listed in party B\u2019s DID Doc failed to respond when they were contacted, the code might contain \"endpoint-not-responding\", and the problem_items property might contain:</p> <pre><code>[\n  {\"endpoint1\": \"http://agency.com/main/endpoint\"},\n  {\"endpoint2\": \"http://failover.agency.com/main/endpoint\"}\n]\n</code></pre> <p>who_retries: value is the string \"you\", the string \"me\", the string \"both\", or the string \"none\". This property tells whether a problem is considered permanent and who the sender of the problem report believes should have the responsibility to resolve it by retrying. Rules about how many times to retry, and who does the retry, and under what circumstances, are not enforceable and not expressed in the message text. This property is thus not a strong commitment to retry--only a recommendation of who should retry, with the assumption that retries will often occur if they make sense.</p> <p>[TODO: figure out how to identify parties &gt; 2 in n-wise interaction]</p> <p>fix_hint: Contains human-readable, localized suggestions about how to fix this instance of the problem. If present, this should be viewed as overriding general hints found in a message catalog.</p> <p>impact: A string describing the breadth of impact of the problem. An enumerated type:</p> <ul> <li>\"message\" (this is a problem with a single message only; the rest of the interaction may still be fine),</li> <li>\"thread\" (this is a problem that endangers or invalidates the entire thread),</li> <li>\"connection\" (this is a problem that endangers or invalidates the entire connection).</li> </ul> <p>where: A string that describes where the error happened, from the perspective of the reporter, and that uses the \"you\" or \"me\" or \"other\" prefix, followed by a suffix like \"cloud\", \"edge\", \"wire\", \"agency\", etc.</p> <p>noticed_time: Standard time entry (ISO-8601 UTC with at least day precision and up to millisecond precision) of when the problem was detected.</p> <p>[TODO: should we refer to timestamps in a standard way (\"date\"? \"time\"? \"timestamp\"? \"when\"?)]</p> <p>tracking_uri: Provides a URI that allows the recipient to track the status of the error. For example, if the error is related to a service that is down, the URI could be used to monitor the status of the service, so its return to operational status could be automatically discovered.</p> <p>escalation_uri: Provides a URI where additional help on the issue can be received. For example, this might be a \"mailto\" and email address for the Help Desk associated with a currently down service.</p>"},{"location":"aip2/0035-report-problem/#sample","title":"Sample","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/notification/1.0/problem-report\",\n  \"@id\": \"7c9de639-c51c-4d60-ab95-103fa613c805\",\n  \"~thread\": {\n    \"pthid\": \"1e513ad4-48c9-444e-9e7e-5b8b45c5e325\",\n    \"sender_order\": 1\n  },\n  \"~l10n\"            : {\"catalog\": \"https://didcomm.org/error-codes\"},\n  \"description\"      : \"Unable to find a route to the specified recipient.\",\n  \"description~l10n\" : {\"code\": \"cant-find-route\" },\n  \"problem_items\"    : [\n      { \"recipient\": \"did:sov:C805sNYhMrjHiqZDTUASHg\" }\n  ],\n  \"who_retries\"      : \"you\",\n  \"impact\"           : \"message\",\n  \"noticed_time\"     : \"2019-05-27 18:23:06Z\"\n}\n</code></pre>"},{"location":"aip2/0035-report-problem/#categorized-examples-of-errors-and-current-best-practice-handling","title":"Categorized Examples of Errors and (current) Best Practice Handling","text":"<p>The following is a categorization of a number of examples of errors and (current) Best Practice handling for those types of errors. The new <code>problem-report</code> message type is used for some of these categories, but not all.</p>"},{"location":"aip2/0035-report-problem/#unknown-error","title":"Unknown Error","text":"<p>Errors of a known error code will be processed according to the understanding of what the code means. Support of a protocol includes support and proper processing of the error codes detailed within that protocol.</p> <p>Any unknown error code that starts with <code>w.</code> in the DIDComm v2 style may be considered a warning, and the flow of the active protocol SHOULD continue. All other unknown error codes SHOULD be considered to be an end to the active protocol.</p>"},{"location":"aip2/0035-report-problem/#error-while-processing-a-received-message","title":"Error While Processing a Received Message","text":"<p>An Agent Message sent by a Sender and received by its intended Recipient cannot be processed.</p>"},{"location":"aip2/0035-report-problem/#examples","title":"Examples:","text":"<ul> <li>An error occurs in the processing of the message (e.g. missing required parameters, bad data in parameters, etc.)</li> <li>The recipient has no message handler for the message type</li> <li>A message request is rejected because of a policy</li> <li>\"Access denied\" scenarios</li> </ul>"},{"location":"aip2/0035-report-problem/#recommended-handling","title":"Recommended Handling","text":"<p>The Recipient should send the Sender a <code>problem-report</code> Agent Message detailing the issue.</p> <p>The last example deserves an additional comment about whether there should be a response sent at all. Particularly in cases where trust in the message sender is low (e.g. when establishing the connection), an Agent may not want to send any response to a rejected message as even a negative response could reveal correlatable information. That said, if a response is provided, the <code>problem-report</code> message type should be used.</p>"},{"location":"aip2/0035-report-problem/#error-while-routing-a-message","title":"Error While Routing A Message","text":"<p>An Agent in the routing flow of getting a message from a Sender to the Agent Message Recipient cannot route the message.</p>"},{"location":"aip2/0035-report-problem/#examples_1","title":"Examples:","text":"<ul> <li>Unknown \"To\" destination for the message</li> <li>Insufficient resources (disk space, network access)</li> <li>Unable to decrypt the message</li> </ul>"},{"location":"aip2/0035-report-problem/#recommended-handling_1","title":"Recommended Handling","text":"<p>If the Sender is known to the Agent having the problem, send a <code>problem-report</code> Agent Message detailing at least that a blocking issue occurred, and if relevant (such as in the first example), some details about the issue. If the message is valid, and the problem is related to a lack of resources (e.g. the second issue), also send a <code>problem-report</code> message to an escalation point within the domain.</p> <p>Alternatively, the capabilities described in 0034: Message Tracing could be used to inform others of the fact that an issue occurred.</p>"},{"location":"aip2/0035-report-problem/#messages-triggered-about-a-transaction","title":"Messages Triggered about a Transaction","text":""},{"location":"aip2/0035-report-problem/#examples_2","title":"Examples:","text":"<ul> <li>\"You\u2019re asking for more information than we agreed to\" or \"You\u2019re giving me more than I expected.\"</li> <li>Couldn\u2019t pay (insufficient funds, payment mechanism is offline\u2026)</li> <li>You violated the terms of service we agreed to, because I see that my info has been leaked.</li> <li>Your credential has been revoked (asynchronous)</li> <li>A is unwilling to consent to the terms and conditions that B proposes.</li> </ul>"},{"location":"aip2/0035-report-problem/#recommended-handling_2","title":"Recommended Handling","text":"<p>These types of error scenarios represent a gray error in handling between using the generic <code>problem-report</code> message format, or a message type that is part of the current transaction's message family. For example, the \"Your credential has been revoked\" might well be included as a part of the (TBD) standard Credentials Exchange message family. The \"more information\" example might be a generic error across a number of message families and so should trigger a <code>problem-report</code>) or, might be specific to the ongoing thread (e.g. Credential Exchange) and so be better handled by a defined message within that thread and that message family.</p> <p>The current advice on which to use in a given scenario is to consider how the recipient will handle the message. If the handler will need to process the response in a specific way for the transaction, then a message family-specific message type should be used. If the error is cross-cutting such that a common handler can be used across transaction contexts, then a generic <code>problem-report</code> should be used.</p> <p>\"Current advice\" implies that as we gain more experience with Agent To Agent messaging, the recommendations could get more precise.</p>"},{"location":"aip2/0035-report-problem/#messaging-channel-settings","title":"Messaging Channel Settings","text":""},{"location":"aip2/0035-report-problem/#examples_3","title":"Examples","text":"<ul> <li>\"Please resend so a different one of my agents can read this.\", or, \"Agent X no longer in service. Use Agent Y instead.\"</li> <li>A received a message from B that it cannot understand (message garbled, can\u2019t be decrypted, is of an unrecognized type, uses crypto from a library that A doesn\u2019t have, etc)</li> <li>A wants to report to B that it believes A has been hacked, or that it is under attack</li> <li>A wants to report to B that it believes B has been hacked, or that it is under attack</li> <li>Version incompatibilities of various kinds (transport version incompatibilities [http 1.1 vs. 2.0]; agent message type version incompatibilities)</li> </ul>"},{"location":"aip2/0035-report-problem/#recommended-handling_3","title":"Recommended Handling","text":"<p>These types of messages might or might not be triggered during the receipt and processing of a message, but either way, they are unrelated to the message and are really about the communication channel between the entities. In such cases, the recommended approach is to use a (TBD) standard message family to notify and rectify the issue (e.g. change the attributes of a connection). The definition of that message family is outside the scope of this RFC.</p>"},{"location":"aip2/0035-report-problem/#timeouts","title":"Timeouts","text":"<p>A special generic class of errors that deserves mention is the timeout, where a Sender sends out a message and does not receive back a response in a given time. In a distributed environment such as Agent to Agent messaging, these are particularly likely - and particularly difficult to handle gracefully. The potential reasons for timeouts are numerous:</p> <ul> <li>loss of connectivity</li> <li>resource errors with one of the Agents between the Sender and Receiver</li> <li>not yet detected key rotations (cached DIDDocs and encryption keys)</li> <li>errors occurring in an Agent unaware of the Sender (so cannot notify the sender of the issue)</li> <li>Recipient offline for an extended period</li> <li>disinterest on the part of the Recipient (received, but no response sent back)</li> </ul>"},{"location":"aip2/0035-report-problem/#recommended-handling_4","title":"Recommended Handling","text":"<p>Appropriate timeout handling is extremely contextual, with two key parameters driving the handling - the length of the waiting period before triggering the timeout and the response to a triggered timeout.</p> <p>The time to wait for a response should be dynamic by at least type of message, and ideally learned through experience. Messages requiring human interaction should have an inherently longer timeout period than a message expected to be handled automatically. Beyond that, it would be good for Agents to track response times by message type (and perhaps other parameters) and adjust timeouts to match observed patterns.</p> <p>When a timeout is received there are three possible responses, handled automatically or based on feedback from the user:</p> <ul> <li>Wait longer</li> <li>Retry</li> <li>Give up</li> </ul> <p>An automated \"wait longer\" response might be used when first interacting with a particular message type or identity, as the response cadence is learned.</p> <p>If the decision is to retry, it would be good to have support in areas covered by other RFCs. First, it would be helpful (and perhaps necessary) for the threading decorator to support the concept of retries, so that a Recipient would know when a message is a retry of an already sent message.  Next, on \"forward\" message types, Agents might want to know that a message was a retry such that they can consider refreshing DIDDoc/encryption key cache before sending the message along. It could also be helpful for a retry to interact with the Tracing facility so that more information could be gathered about why messages are not getting to their destination.</p> <p>Excessive retrying can exacerbate an existing system issue. If the reason for the timeout is because there is a \"too many messages to be processed\" situation, then sending retries simply makes the problem worse. As such, a reasonable backoff strategy should be used (e.g. exponentially increasing times between retries). As well, a strategy used at Uber is to flag and handle retries differently from regular messages. The analogy with Uber is not pure - that is a single-vendor system - but the notion of flagging retries such that retry messages can be handled differently is a good approach.</p>"},{"location":"aip2/0035-report-problem/#caveat-problem-report-loops","title":"Caveat: Problem Report Loops","text":"<p>Implementers should consider and mitigate the risk of an endless loop of error messages. For example:</p> <ul> <li>Alice sends a message to Bob that Bob doesn't recognize. Bob sends a <code>Problem Report</code> message to Alice.</li> <li>Alice doesn't understand the message from Bob and sends a <code>Problem Report</code> to Bob.</li> <li>Bob doesn't understand the message from Alice and sends a <code>Problem Report</code> to Alice. And so on...</li> </ul>"},{"location":"aip2/0035-report-problem/#recommended-handling_5","title":"Recommended Handling","text":"<p>How agents mitigate the risk of this problem is implementation specific, balancing loop-tracking overhead versus the likelihood of occurrence. For example, an agent implementation might have a counter on a connection object that is incremented when certain types of <code>Problem Report</code> messages are sent on that connection, and reset when any other message is sent. The agent could stop sending those types of <code>Problem Report</code> messages after the counter reaches a given value.</p>"},{"location":"aip2/0035-report-problem/#reference","title":"Reference","text":"<p>TBD</p>"},{"location":"aip2/0035-report-problem/#drawbacks","title":"Drawbacks","text":"<p>In many cases, a specific <code>problem-report</code> message is necessary, so formalizing the format of the message is also preferred over leaving it to individual implementations. There is no drawback to specifying that format now.</p> <p>As experience is gained with handling distributed errors, the recommendations provided in this RFC will have to evolve.</p>"},{"location":"aip2/0035-report-problem/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>The error type specification mechanism builds on the same approach used by the message type specifications. It's possible that additional capabilities could be gained by making runtime use of the error type specification - e.g. for the broader internationalization of the error messages.</p> <p>The main alternative to a formally defined error type format is leaving it to individual implementations to handle error notifications, which will not lead to an effective solution.</p>"},{"location":"aip2/0035-report-problem/#prior-art","title":"Prior art","text":"<p>A brief search was done for error handling in messaging systems with few useful results found. Perhaps the best was the Uber article referenced in the \"Timeout\" section above.</p>"},{"location":"aip2/0035-report-problem/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Can the Tracing facility provide a trusted way to better handle distributed errors in a production environment?</li> <li>Denial of service via problems that spam the wrong person with   a problem report.</li> </ul>"},{"location":"aip2/0035-report-problem/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes RFC 0036: Issue Credential Protocol The <code>problem-report</code> message is adopted by this protocol. MISSING test results RFC 0037: Present Proof Protocol The <code>problem-report</code> message is adopted by this protocol. MISSING test results Trinsic.id Commercial mobile and web app built using Aries Framework - .NET MISSING test results"},{"location":"aip2/0044-didcomm-file-and-mime-types/","title":"Aries RFC 0044: DIDComm File and MIME Types","text":"<ul> <li>Authors: Daniel Hardman, Kyle Den Hartog</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Revised as part of AIP 2.0 to ease the upcoming transition from DIDComm v1 to DIDComm v2.</li> <li>Start Date: 2018-11-13</li> <li>Tags: feature</li> </ul>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#summary","title":"Summary","text":"<p>Defines the media (MIME) types and file types that hold DIDComm messages in encrypted, signed, and plaintext forms. Covers DIDComm V1, plus a little of V2 to clarify how DIDComm versions are detected.</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#motivation","title":"Motivation","text":"<p>Most work on DIDComm so far has assumed HTTP as a transport. However, we know that DID communication is transport-agnostic. We should be able to say the same thing no matter which channel we use.</p> <p>An incredibly important channel or transport for messages is digital files. Files can be attached to messages in email or chat, can be carried around on a thumb drive, can be backed up, can be distributed via CDN, can be replicated on distributed file systems like IPFS, can be inserted in an object store or in content-addressable storage, can be viewed and modified in editors, and support a million other uses.</p> <p>We need to define how files and attachments can contain DIDComm messages, and what the semantics of processing such files will be.</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0044-didcomm-file-and-mime-types/#media-types","title":"Media Types","text":"<p>Media types are based on the conventions of RFC6838. Similar to RFC7515, the <code>application/</code> prefix MAY be omitted and the recipient MUST treat media types not containing <code>/</code> as having the <code>application/</code> prefix present.</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#didcomm-v1-encrypted-envelope-dee","title":"DIDComm v1 Encrypted Envelope (*.dee)","text":"<p>The raw bytes of an encrypted envelope may be persisted to a file without any modifications whatsoever. In such a case, the data will be encrypted and packaged such that only specific receiver(s) can process it. However, the file will contain a JOSE-style header that can be used by magic bytes algorithms to detect its type reliably.</p> <p>The file extension associated with this filetype is <code>dee</code>, giving a globbing pattern  of <code>*.dee</code>; this should be be read as \"STAR DOT D E E\" or as \"D E E\" files.</p> <p>The name of this file format is \"DIDComm V1 Encrypted Envelope.\" We expect people to say, \"I am looking at a DIDComm V1 Encrypted Envelope\", or \"This file is in DIDComm V1 Encrypted Envelope format\", or \"Does my editor have a DIDComm V1 Encrypted Envelope plugin?\"</p> <p>Although the format of encrypted envelopes is derived from JSON and the JWT/JWE family of specs, no useful processing of these files will take place by viewing them as JSON, and viewing them as generic JWEs will greatly constrain which semantics are applied. Therefore, the recommended MIME type for *.dee files is <code>application/didcomm-envelope-enc</code>, with <code>application/jwe</code> as a fallback, and <code>application/json</code> as an even less desirable fallback. (In this, we are making a choice similar to the one that views <code>*.docx</code> files primarily as <code>application/msword</code> instead of <code>application/xml</code>.) If format evolution takes place, the version could become a parameter as described in RFC 1341: <code>application/didcomm-envelope-enc;v=2</code>.</p> <p>A recipient using the media type value MUST treat it as if <code>\u201capplication/\u201d</code> were prepended to any <code>\"typ\"</code> or <code>\"cty\"</code> value not containing a \u2018/\u2019 in compliance  with the JWE /JWS  family of specs.</p> <p>The default action for DIDComm V1 Encrypted Envelopes (what happens when a user double-clicks one) should be <code>Handle</code> (that is, process the message as if it had just arrived by some other transport), if the software handling the message is an agent. In other types of software, the default action might be to view the file. Other useful actions might include <code>Send</code>, <code>Attach</code> (to email, chat, etc), <code>Open with agent</code>, and <code>Decrypt to *.dp</code>.</p> <p>NOTE: The analog to this content type in DIDComm v2 is called a \"DIDComm Encrypted Message.\" Its format is slightly different. For more info, see Detecting DIDComm Versions below.</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#didcomm-v1-signed-envelopes-dse","title":"DIDComm V1 Signed Envelopes (*.dse)","text":"<p>When DIDComm messages are signed, the signing uses a JWS signing envelope. Often signing is unnecessary, since authenticated encryption proves the sender of the message to the recipient(s), but sometimes when non-repudiation is required, this envelope is used. It is also required when the recipient of a message is unknown, but tamper-evidence is still required, as in the case of a public invitation.</p> <p>By convention, DIDComm Signed Envelopes contain plaintext; if encryption is used in combination with signing, the DSE goes inside the DEE.</p> <p>The file extension associated with this filetype is <code>dse</code>, giving a globbing pattern  of <code>*.dse</code>; this should be be read as \"STAR DOT D S E\" or as \"D S E\" files.</p> <p>The name of this file format is \"DIDComm V1 Signed Envelope.\" We expect people to say, \"I am looking at a DIDComm V1 Signed Envelope\", or \"This file is in DIDComm V1 Signed Envelope format\", or \"Does my editor have a DIDComm V1 Signed Envelope plugin?\"</p> <p>As with *.dee files, the best way to hande *.dse files is to map them to a custom MIME type. The recommendation is <code>application/didcomm-sig-env</code>, with <code>application/jws</code> as a fallback, and <code>application/json</code> as an even less desirable fallback.</p> <p>A recipient using the media type value MUST treat it as if <code>\u201capplication/\u201d</code> were prepended to any <code>\"typ\"</code> or <code>\"cty\"</code> value not containing a \u2018/\u2019 in compliance  with the JWE /JWS family of specs.</p> <p>The default action for DIDComm V1 Signed Envelopes (what happens when a user double-clicks one) should be <code>Validate</code> (that is, process the signature to see if it is valid.</p> <p>NOTE: The analog to this content type in DIDComm v2 is called a \"DIDComm Signed Message.\" Its format is slightly different. For more info, see Detecting DIDComm Versions below.</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#didcomm-v1-messages-dm","title":"DIDComm V1 Messages (*.dm)","text":"<p>The plaintext representation of a DIDComm message--something like a credential offer, a proof request, a connection invitation, or anything else worthy of a DIDComm protocol--is JSON. As such, it should be editable by anything that expects JSON.</p> <p>However, all such files have some additional conventions, over and above the simple requirements of JSON. For example, key decorators have special meaning ( <code>@id</code>, <code>~thread</code>, <code>@trace</code> , etc). Nonces may be especially significant. The format of particular values such as DID and DID+key references is important. Therefore, we refer to these messages generically as JSON, but we also define a file format for tools that are aware of the additional semantics.</p> <p>The file extension associated with this filetype is <code>*.dm</code>, and should be read as \"STAR DOT D M\" or \"D M\" files. If a format evolution takes place, a subsequent version could be noted by appending a digit, as in <code>*.dm2</code> for second-generation <code>dm</code> files.</p> <p>The name of this file format is \"DIDComm V1 Message.\" We expect people to say, \"I am looking at a DIDComm V1 Message\", or \"This file is in DIDComm V1 Message format\", or \"Does my editor have a DIDComm V1 Message plugin?\" For extra clarity, it is acceptable to add the adjective \"plaintext\", as in \"DIDComm V1 Plaintext Message.\"</p> <p>The most specific MIME type of *.dm files is <code>application/json;flavor=didcomm-msg</code>--or, if more generic handling is appropriate, just  <code>application/json</code>.</p> <p>A recipient using the media type value MUST treat it as if <code>\u201capplication/\u201d</code> were prepended to any <code>\"typ\"</code> or <code>\"cty\"</code> value not containing a \u2018/\u2019 in compliance  with the JWE /JWS family of specs.</p> <p>The default action for DIDComm V1 Messages should be to <code>View</code> or <code>Validate</code> them. Other interesting actions might be <code>Encrypt to *.dee</code>, <code>Sign to *.dse</code>, and <code>Find definition of protocol</code>.</p> <p>NOTE: The analog to this content type in DIDComm v2 is called a \"DIDComm Plaintext Message.\" Its format is slightly different. For more info, see Detecting DIDComm Versions below.</p> <p>As a general rule, DIDComm messages that are being sent in production use cases of DID communication should be stored in encrypted form (<code>*.dee</code>) at rest. There are cases where this might not be preferred, e.g., providing documentation of the format of message or during a debugging scenario using message tracing. However, these are exceptional cases. Storing meaningful <code>*.dm</code> files decrypted is not a security best practice, since it replaces all the privacy and security guarantees provided by the DID communication mechanism with only the ACLs and other security barriers that are offered by the container.</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#native-object-representation","title":"Native Object representation","text":"<p>This is not a file format, but rather an in-memory form of a DIDComm Message using whatever object hierarchy is natural for a programming language to map to and from JSON. For example, in python, the natural Native Object format is a dict that contains properties indexed by strings. This is the representation that python's <code>json</code> library expects when converting to JSON, and the format it produces when converting from JSON. In Java, Native Object format might be a bean. In C++, it might be a <code>std::map&lt;std::string, variant&gt;</code>...</p> <p>There can be more than one Native Object representation for a given programming language.</p> <p>Native Object forms are never rendered directly to files; rather, they are serialized to DIDComm Plaintext Format and then persisted (likely after also encrypting to DIDComm V1 Encrypted Envelope).</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#negotiating-compatibility","title":"Negotiating Compatibility","text":"<p>When parties want to communicate via DIDComm, a number of mechanisms must align. These include:</p> <ol> <li>The type of service endpoint used by each party</li> <li>The key types used for encryption and/or signing</li> <li>The format of the encryption and/or signing envelopes</li> <li>The encoding of plaintext messages</li> <li>The protocol used to forward and route</li> <li>The protocol embodied in the plaintext messages</li> </ol> <p>Although DIDComm allows flexibility in each of these choices, it is not expected that a given DIDComm implementation will support many permutations. Rather, we expect a few sets of choices that commonly go together. We call a set of choices that work well together a profile. Profiles are identified by a string that matches the conventions of IANA media types, but they express choices about plaintext, encryption, signing, and routing in a single value. The following profile identifiers are defined in this version of the RFC:</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#defined-profiles","title":"Defined Profiles","text":"<ul> <li><code>didcomm/aip1</code>: The encryption envelope, signing mechanism, plaintext conventions, and routing algorithms embodied in Aries AIP 1.0, circa 2020.</li> <li><code>didcomm/aip2;env=rfc19</code>: The signing mechanism, plaintext conventions, and routing algorithms embodied in Aries AIP 2.0, circa 2021 -- with the old-style encryption envelope from Aries RFC 0019. This legal variant of AIP 2.0 minimizes differences with codebases that shipped AIP 1.0 support.</li> <li><code>didcomm/aip2;env=rfc587</code>: The signing mechanism, plaintext conventions, and routing algorithms embodied in Aries AIP 2.0, circa 2021 -- with the new-style encryption envelope from Aries RFC 0587. This legal variant of AIP 2.0 lays the foundation for DIDComm v2 support by anticipating the eventual envelope change.</li> <li><code>didcomm/v2</code>: The encryption envelope, signing mechanism, plaintext conventions, and routing algorithms embodied in the DIDComm messaging spec.</li> </ul> <p>Profiles are named in the <code>accept</code> section of a DIDComm service endpoint and in an out-of-band message. When Alice declares that she accepts <code>didcomm/aip2;env=rfc19</code>, she is making a declaration about more than her own endpoint. She is saying that all publicly visible steps in an inbound route to her will use the <code>didcomm/aip2;env=rfc19</code> profile, such that a sender only has to use <code>didcomm/aip2;env=rfc19</code> choices to get the message from Alice's outermost mediator to Alice's edge. It is up to Alice to select and configure mediators and internal routing in such a way that this is true for the sender.</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#detecting-didcomm-versions","title":"Detecting DIDComm Versions","text":"<p>Because media types differ from DIDComm V1 to V2, and because media types are easy to communicate in headers and message fields, they are a convenient way to detect which version of DIDComm applies in a given context:</p> Nature of Content V1 V2 encrypted <code>application/didcomm-envelope-enc</code>DIDComm V1 Encrypted Envelope*.dee <code>application/didcomm-encrypted+json</code>DIDComm Encrypted Message*.dcem signed <code>application/didcomm-sig-env</code>DIDComm V1 Signed Envelope*.dse <code>application/didcomm-signed+json</code>DIDComm Signed Message*.dcsm plaintext <code>application/json;flavor=didcomm-msg</code>DIDComm V1 Message*.dm <code>application/didcomm-plain+json</code>DIDComm Plaintext Message*.dcpm <p>It is also recommended that agents implementing Discover Features Protocol v2 respond to queries about supported DIDComm versions using the <code>didcomm-version</code> feature name. This allows queries about what an agent is willing to support, whereas the media type mechanism describes what is in active use. The values that should be returned from such a query are URIs that tell where DIDComm versions are developed:</p> Version URI V1 https://github.com/hyperledger/aries-rfcs V2 https://github.com/decentralized-identity/didcomm-messaging"},{"location":"aip2/0044-didcomm-file-and-mime-types/#what-it-means-to-implement-this-rfc","title":"What it means to \"implement\" this RFC","text":"<p>For the purposes of Aries Interop Profiles, an agent \"implements\" this RFC when:</p> <ul> <li>If it encounters references to DIDComm V1 media types (e.g., in HTTP headers, in attachments, or in the fields of DIDComm messages where a media type is expected), it imputes the meaning documented here.</li> <li>If it characterizes DIDComm V1 content in its own outbound communication or UI, it does so with the media type strings, friendly names, and file extensions documented here.</li> </ul>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#reference","title":"Reference","text":"<p>The file extensions and MIME types described here are also accompanied by suggested graphics. Vector forms of these graphics are available.</p>"},{"location":"aip2/0044-didcomm-file-and-mime-types/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0046-mediators-and-relays/","title":"Aries RFC 0046: Mediators and Relays","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2019-02-01</li> <li>Status Note: Socialized and broadly understood in other conceptual RFCs about routing.</li> <li>Start Date: 2018-12-01</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0046-mediators-and-relays/#summary","title":"Summary","text":"<p>The mental model for agent-to-agent messaging (A2A) messaging includes two important communication primitives that have a meaning unique to our ecosystem: mediator and relay.</p> <p>A mediator is a participant in agent-to-agent message delivery that must be modeled by the sender. It has its own keys and will deliver messages only after decrypting an outer envelope to reveal a <code>forward</code> request. Many types of mediators may exist, but two important ones should be widely understood, as they commonly manifest in DID Docs:</p> <ol> <li>A service that hosts many cloud agents at a single endpoint to provide herd privacy (an \"agency\") is a mediator.</li> <li>A cloud-based agent that routes between/among the edges of a sovereign domain is a mediator.</li> </ol> <p>A relay is an entity that passes along agent-to-agent messages, but that can be ignored when the sender considers encryption choices. It does not decrypt anything. Relays can be used to change the transport for a message (e.g., accept an HTTP POST, then turn around and emit an email; accept a Bluetooth transmission, then turn around and emit something in a message queue). Mix networks like TOR are an important type of relay.</p> <p>Read on to explore how agent-to-agent communication can model complex topologies and flows using these two primitives.</p>"},{"location":"aip2/0046-mediators-and-relays/#motivation","title":"Motivation","text":"<p>When we describe agent-to-agent communication, it is convenient to think of an interaction only in terms of Alice and Bob and their agents. We say things like: \"Alice's agent sends a message to Bob's agent\" -- or perhaps \"Alice's edge agent sends a message to Bob's cloud agent, which forwards it to Bob's edge agent\".</p> <p>Such statements adopt a useful level of abstraction--one that's highly recommended for most discussions. However, they make a number of simplifications. By modeling the roles of mediators and relays in routing, we can support routes that use multiple transports, routes that are not fully known (or knowable) to the sender, routes that pass through mix networks, and other advanced and powerful ../../concepts.</p>"},{"location":"aip2/0046-mediators-and-relays/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0046-mediators-and-relays/#key-concepts","title":"Key Concepts","text":"<p>Let's define mediators and relays by exploring how they manifest in a series of communication scenarios between Alice and Bob.</p>"},{"location":"aip2/0046-mediators-and-relays/#scenario-1-base","title":"Scenario 1 (base)","text":"<p>Alice and Bob are both employees of a large corporation. They work in the same office, but have never met. The office has a rule that all messages between employees must be encrypted. They use paper messages and physical delivery as the transport. Alice writes a note, encrypts it so only Bob can read it, puts it in an envelope addressed to Bob, and drops the envelope on a desk that she has been told belongs to Bob. This desk is in fact Bob's, and he later picks up the message, decrypts it, and reads it.</p> <p></p> <p>In this scenario, there is no mediator, and no relay.</p>"},{"location":"aip2/0046-mediators-and-relays/#scenario-2-a-gatekeeper","title":"Scenario 2: a gatekeeper","text":"<p>Imagine that Bob hires an executive assistant, Carl, to filter his mail. Bob won't open any mail unless Carl looks at it and decides that it's worthy of Bob's attention.</p> <p>Alice has to change her behavior. She continues to package a message for Bob, but now she must account for Carl as well. She take the envelope for Bob, and places it inside a new envelope addressed to Carl. Inside the outer envelope, and next to the envelope destined for Bob, Alice writes Carl an encrypted note: \"This inner envelope is for Bob. Please forward.\"</p> <p></p> <p>Here, Carl is acting as a mediator. He is mostly just passing messages along. But because he is processing a message himself, and because Carl is interposed between Alice and Bob, he affects the behavior of the sender. He is a known entity in the route.</p>"},{"location":"aip2/0046-mediators-and-relays/#scenario-3-transparent-indirection","title":"Scenario 3: transparent indirection","text":"<p>All is the same as the base scenario (Carl has been fired), except that Bob is working from home when Alice's message lands on his desk. Bob has previously arranged with his friend Darla, who lives near him, to pick up any mail that's on his desk and drop it off at his house at the end of the work day. Darla sees Alice's note and takes it home to Bob.</p> <p></p> <p>In this scenario, Darla is acting as a relay. Note that Bob arranges for Darla to do this without notifying Alice, and that Alice does not need to adjust her behavior in any way for the relay to work.</p>"},{"location":"aip2/0046-mediators-and-relays/#scenario-4-more-indirection","title":"Scenario 4: more indirection","text":"<p>Like scenario 3, Darla brings Bob his mail at home. However, Bob isn't at home when his mail arrives. He's had to rush out on an errand, but he's left instructions with his son, Emil, to open any work mail, take a photo of the letter, and text him the photo. Emil intends to do this, but the camera on his phone misfires, so he convinces his sister, Francis, to take the picture on her phone and email it to him. Then he texts the photo to Bob, as arranged.</p> <p></p> <p>Here, Emil and Francis are also acting as relays. Note that nobody knows about the full route. Alice thinks she's delivering directly to Bob. So does Darla. Bob knows about Darla and Emil, but not about Francis.</p> <p>Note, too, how the transport is changing from physical mail to email to text.</p> <p>To the party immediately upstream (closer to the sender), a relay is indistinguishable from the next party downstream (closer to the recipient). A party anywhere in the chain can insert one or more relays upstream from themselves, as long as those relays are not upstream of another named party (sender or mediator).</p>"},{"location":"aip2/0046-mediators-and-relays/#more-scenarios","title":"More Scenarios","text":"<p>Mediators and relays can be combined in any order and any amount in variations on our fictional scenario. Bob could employ Carl as a mediator, and Carl could work from home and arrange delivery via George, then have his daughter Hannah run messages back to Bob's desk at work. Carl could hire his own mediator. Darla could arrange or Ivan to substitute for her when she goes on vacation. And so forth.</p>"},{"location":"aip2/0046-mediators-and-relays/#more-traditional-usage","title":"More Traditional Usage","text":"<p>The scenarios used above are somewhat artificial. Our most familiar agent-to-agent scenarios involve edge agents running on mobile devices and accessible through bluetooth or push notification, and cloud agents that use electronic protocols as their transport. Let's see how relays and mediators apply there.</p>"},{"location":"aip2/0046-mediators-and-relays/#scenario-5-traditional-base","title":"Scenario 5 (traditional base)","text":"<p>Alice's cloud agent wants to talk to Bob's cloud agent. Bob's cloud agent is listening at http://bob.com/agent. Alice encrypts a message for Bob and posts it to that URL.</p> <p></p> <p>In this scenario, we are using a direct transport with neither a mediator nor a relay.</p> <p>If you are familiar with common routing patterns and you are steeped in HTTP, you are likely objecting at this point, pointing out ways that this description diverges from best practice, including what's prescribed in other RFC. You may be eager to explain why this is a privacy problem, for example.</p> <p>You are not wrong, exactly. But please suspend those concerns and hang with me. This is about what's theoretically possible in the mental model. Besides, I would note that virtually the same diagram could be used for a Bluetooth agent conversation:</p> <p></p>"},{"location":"aip2/0046-mediators-and-relays/#scenario-6-herd-hosting","title":"Scenario 6: herd hosting","text":"<p>Let's tweak Scenario 5 slightly by saying that Bob's agent is one of thousands that are hosted at the same URL. Maybe the URL is now http://agents-r-us.com/inbox. Now if Alice wants to talk to Bob's cloud agent, she has to cope with a mediator. She wraps the encrypted message for Bob's cloud agent inside a <code>forward</code> message that's addressed to and encrypted for the agent of agents-r-us that functions as a gatekeeper.</p> <p></p> <p>This scenario is one that highlights an external mediator--so-called because the mediator lives outside the sovereign domain of the final recipient.</p>"},{"location":"aip2/0046-mediators-and-relays/#scenario-7-intra-domain-dispatch","title":"Scenario 7: intra-domain dispatch","text":"<p>Now let's subtract agents-r-us. We're back to Bob's cloud agent listening directly at http://bob.com/agent. However, let's say that Alice has a different goal--now she wants to talk to the edge agent running on Bob's mobile device. This agent doesn't have a permanent IP address, so Bob uses his own cloud agent as a mediator. He tells Alice that his mobile device agent can only be reached via his cloud agent.</p> <p></p> <p>Once again, this causes Alice to modify her behavior. Again, she wraps her encrypted message. The inner message is enclosed in an outer envelope, and the outer envelope is passed to the mediator.</p> <p>This scenario highlights an internal mediator. Internal and external mediators introduce similar ../../features and similar constraints; the relevant difference is that internal mediators live within the sovereign domain of the recipient, and may thus be worthy of greater trust.</p>"},{"location":"aip2/0046-mediators-and-relays/#scenario-8-double-mediation","title":"Scenario 8: double mediation","text":"<p>Now let's combine. Bob's cloud agent is hosted at agents-r-us, AND Alice wants to reach Bob's mobile:</p> <p></p> <p>This is a common pattern with HTTP-based cloud agents plus mobile edge agents, which is the most common deployment pattern we expect for many users of self-sovereign identity. Note that the properties of the agency and the routing agent are not particularly special--they are just an external and an internal mediator, respectively.</p>"},{"location":"aip2/0046-mediators-and-relays/#related-concepts","title":"Related Concepts","text":""},{"location":"aip2/0046-mediators-and-relays/#routes-are-one-way-not-duplex","title":"Routes are One-Way (not duplex)","text":"<p>In all of this discussion, note that we are analyzing only a flow from Alice to Bob. How Bob gets a message back to Alice is a completely separate question. Just because Carl, Darla, Emil, Francis, and Agents-R-Us may be involved in how messages flow from Alice to Bob, does not mean they are involved in flow the opposite direction.</p> <p>Note how this breaks the simple assumptions of pure request-response technologies like HTTP, that assume the channel in (request) is also the channel out (response). Duplex request-response can be modeled with A2A, but doing so requires support that may not always be available, plus cooperative behavior governed by the <code>~thread</code> decorator.</p>"},{"location":"aip2/0046-mediators-and-relays/#conventions-on-direction","title":"Conventions on Direction","text":"<p>For any given one-way route, the direction of flow is always from sender to receiver. We could use many different metaphors to talk about the \"closer to sender\" and \"closer to receiver\" directions -- upstream and downstream, left and right, before and after, in and out. We've chosen to standardize on two:</p> <ul> <li> <p>The SSI Notation uses directional arrows. A message from Alice to Bob is notated as either <code>A --&gt; B</code> or <code>B &lt;-- A</code> -- whether the arrow faces left or right, it always points to Bob.</p> </li> <li> <p>In text, we use the words source-ward and dest-ward to clarify whether we are moving toward the sender, or toward the receiver, respectively. \"Dest-ward\" always corresponds to where the arrow is pointing and to later points in time; \"source-ward\" is the opposite direction. All messages, whether requests, responses, or otherwise, always flow dest-ward.</p> </li> </ul>"},{"location":"aip2/0046-mediators-and-relays/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem. DIDComm mediator Open source cloud-based mediator with Firebase support."},{"location":"aip2/0047-json-ld-compatibility/","title":"Aries RFC 0047: JSON-LD Compatibility","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2019-02-20</li> <li>Status Note: Has guided Indy design choices for several months. Not yet ratified by greater Aries community. </li> <li>Supersedes: Indy HIPE 0035</li> <li>Start Date: 2019-01-23</li> <li>Tags: concept, decorator</li> </ul>"},{"location":"aip2/0047-json-ld-compatibility/#summary","title":"Summary","text":"<p>Explains the goals of DID Communication with respect to JSON-LD, and how Aries proposes to accomplish them.</p>"},{"location":"aip2/0047-json-ld-compatibility/#motivation","title":"Motivation","text":"<p>JSON-LD is a familiar body of conventions that enriches the expressive power of plain JSON. It is natural for people who arrive in the DID Communication (DIDComm) ecosystem to wonder whether we are using JSON-LD--and if so, how. We need a coherent answer that clarifies our intentions and that keeps us true to those intentions as the ecosystem evolves.</p>"},{"location":"aip2/0047-json-ld-compatibility/#tutorial","title":"Tutorial","text":"<p>The JSON-LD spec is a recommendation work product of the W3C RDF Working Group Since it was formally recommended as version 1.0 in 2014, the JSON for Linking Data Community Group has taken up not-yet-standards-track work on a 1.1 update.</p> <p>JSON-LD has significant gravitas in identity circles. It gives to JSON some capabilities that are sorely needed to model the semantic web, including linking, namespacing, datatyping, signing, and a strong story for schema (partly through the use of JSON-LD on schema.org).</p> <p>However, JSON-LD also comes with some conceptual and technical baggage. It can be hard for developers to master its subtleties; it requires very flexible parsing behavior after built-in JSON support is used to deserialize; it references a family of related specs that have their own learning curve; the formality of its test suite and libraries may get in the way of a developer who just wants to read and write JSON and \"get stuff done.\"</p> <p>In addition, the problem domain of DIDComm is somewhat different from the places where JSON-LD has the most traction. The sweet spot for DIDComm is small, relatively simple JSON documents where code behavior is strongly bound to the needs of a specific interaction. DIDComm needs to work with extremely simple agents on embedded platforms. Such agents may experience full JSON-LD support as an undue burden when they don't even have a familiar desktop OS. They don't need arbitrary semantic complexity.</p> <p>If we wanted to use email technology to send a verifiable credential, we would model the credential as an attachment, not enrich the schema of raw email message bodies. DIDComm invites a similar approach.</p>"},{"location":"aip2/0047-json-ld-compatibility/#goal","title":"Goal","text":"<p>The DIDComm messaging effort that began in the Indy community wants to benefit from the accessibility of ordinary JSON, but leave an easy path for more sophisticated JSON-LD-driven patterns when the need arises. We therefore set for ourselves this goal:</p> <p>Be compatible with JSON-LD, such that advanced use cases can take advantage   of it where it makes sense, but impose no dependencies on the mental model or   the tooling of JSON-LD for the casual developer.</p>"},{"location":"aip2/0047-json-ld-compatibility/#what-the-casual-developer-needs-to-know","title":"What the Casual Developer Needs to Know","text":"<ul> <li> <p>The <code>@</code> character in DIDComm messages is reserved for JSON-LD-isms. Any usage of JSON keys that begin with this character is required to be JSON-LD-compatible, and any time you see it, you are seeing JSON-LD at work.</p> </li> <li> <p><code>@type</code> and <code>@id</code> are required at the root of every message. The meaning of these fields in DIDComm matches JSON-LD's expectations, but you don't need to learn JSON-LD to use them.</p> </li> <li> <p>JSON-LD's more advanced mechanisms are an option--not invoked ad hoc on a message-by-message basis, but specified in the formal description of a message family. You will know how much JSON-LD is relevant to a protocol when you implement it. In general, the community will want to discuss usage of new JSON-LD constructs before embracing them in protocols with broad interoperability intentions, because of the goal articulated above.</p> </li> <li> <p>The decorator concept in DIDComm is orthogonal to JSON-LD, and is far more likely to be relevant to your early learning. See the Decorator RFC.</p> </li> </ul> <p>That's it.</p>"},{"location":"aip2/0047-json-ld-compatibility/#details","title":"Details","text":"<p>Compatibility with JSON-LD was evaluated against version 1.1 of the JSON-LD spec, current in early 2019. If material changes in the spec are forthcoming, a new analysis may be worthwhile. Our current understanding follows.</p>"},{"location":"aip2/0047-json-ld-compatibility/#type","title":"<code>@type</code>","text":"<p>The type of a DIDComm message, and its associated route or handler in dispatching code, is given by the JSON-LD <code>@type</code> property at the root of a message. JSON-LD requires this value to be an IRI. DIDComm DID references are fully compliant. Instances of <code>@type</code> on any node other than a message root have JSON-LD meaning, but no predefined relevance in DIDComm.</p>"},{"location":"aip2/0047-json-ld-compatibility/#id","title":"<code>@id</code>","text":"<p>The identifier for a DIDComm message is given by the JSON-LD <code>@id</code> property at the root of a message. JSON-LD requires this value to be an IRI. DIDComm message IDs are relative IRIs, and can be converted to absolute form as described in RFC 0217: Linkable Message Paths. Instances of <code>@id</code> on any node other than a message root have JSON-LD meaning, but no predefined relevance in DIDComm.</p>"},{"location":"aip2/0047-json-ld-compatibility/#context","title":"<code>@context</code>","text":"<p>This is JSON-LD\u2019s namespacing mechanism. It is active in DIDComm messages, but can be ignored for simple processing, in the same way namespaces in XML are often ignored for simple tasks.</p> <p>Every DIDComm message has an associated <code>@context</code>, but we have chosen to follow the procedure described in section 6 of the JSON-LD spec, which focuses on how ordinary JSON can be intepreted as JSON-LD by communicating <code>@context</code> out of band.</p> <p>DIDComm messages communicate the context out of band by specifying it in the protocol definition (e.g., RFC) for the associated message type; thus, the value of <code>@type</code> indirectly gives the relevant <code>@context</code>. In advanced use cases, <code>@context</code> may appear in a DIDComm message, supplementing this behavior.</p>"},{"location":"aip2/0047-json-ld-compatibility/#ordering","title":"Ordering","text":"<p>JSON-LD specifies that the order of items in arrays is NOT significant, and notes (correctly) that this is the opposite of the standard assumption for plain JSON. This makes sense when viewed through the lens of JSON-LD\u2019s role as a transformation of RDF.</p> <p>Since we want to violate as few assumptions as possible for a developer with general knowledge of JSON, DIDComm messages reverse this default, making arrays an ordered construct, as if all DIDComm message <code>@context</code>s contained something like:</p> <p><pre><code>\"each field\": { \"@container\": \"@list\"}\n</code></pre> To contravene the default, use a JSON-LD construction like this in <code>@context</code>:</p> <pre><code>\"myfield\": { \"@container\": \"@set\"}\n</code></pre>"},{"location":"aip2/0047-json-ld-compatibility/#decorators","title":"Decorators","text":"<p>Decorators are JSON fragments that can be included in any DIDComm message. They enter the formally defined JSON-LD namespace via a JSON-LD fragment that is automatically imputed to every DIDComm message:</p> <pre><code>\"@context\": {\n  \"@vocab\": \"https://github.com/hyperledger/aries-rfcs/\"\n}\n</code></pre> <p>All decorators use the reserved prefix char <code>~</code> (tilde). For more on decorators, see the Decorator RFC.</p>"},{"location":"aip2/0047-json-ld-compatibility/#signing","title":"Signing","text":"<p>JSON-LD is associated but not strictly bound to a signing mechanism, LD-Signatures. It\u2019s a good mechanism, but it comes with some baggage: you must canonicalize, which means you must resolve every \u201cterm\u201d (key name) to its fully qualified form by expanding contexts before signing. This raises the bar for JSON-LD sophistication and library dependencies.</p> <p>The DIDComm community is not opposed to using LD Signatures for problems that need them, but has decided not to adopt the mechanism across the board. There is another signing mechanism that is far simpler, and adequate for many scenarios. We\u2019ll use whichever scheme is best suited to circumstances.</p>"},{"location":"aip2/0047-json-ld-compatibility/#type-coercion","title":"Type Coercion","text":"<p>DIDComm messages generally do not need this feature of JSON-LD, because there are well understood conventions around date-time datatypes, and individual RFCs that define each message type can further clarify such subtleties. However, it is available on a message-type-definition basis (not ad hoc).</p>"},{"location":"aip2/0047-json-ld-compatibility/#node-references","title":"Node References","text":"<p>JSON-LD lets one field reference another. See example 93 (note  that the ref could have just been \u201c#me\u201d instead of the fully qualified IRI).  We may need this construct at some point in DIDComm, but it is not in active  use yet.</p>"},{"location":"aip2/0047-json-ld-compatibility/#internationalization-and-localization","title":"Internationalization and Localization","text":"<p>JSON-LD describes a mechanism for this. It has approximately the same ../../features as the one described in Aries RFC 0043, with a few exceptions:</p> <ul> <li>The JSON-LD mechanism only applies to strings; it is explicitly disallowed for describing dates, numbers, or any strings that coerce to dates or numbers.</li> <li>The JSON-LD mechanism is language-centric rather than locale-centric. For example, it doesn't specify sort order, time-of-day, or currency semantics.</li> <li>There is no notion of a code that maps to strings--just a notion of strings that all have the same meaning. This means it doesn\u2019t help us solve the problem of locale-independent error codes.</li> <li>The notion of mappings of values for different locales is separable into an external catalog, but only if a value is referenced or included implicitly in a doc. In other words, a processor has to see the full message catalog when evaluating the doc.</li> <li>It\u2019s a bit awkward to retrofit onto an existing schema, because it requires a redefinition of the field that contains localized values, from being a single string to being a dictionary with language mappings. In other words, the schema before and after a developer adds localization support is not just different by new, optional fields; it is a breaking change. This contrasts with the indy PR approach, where the language mapping can be added after the fact, and gets associated by convention.</li> <li>It doesn\u2019t support localization of keys--only values. There are corner cases where key localization is desirable.</li> </ul> <p>Because of these misalignments, the DIDComm ecosystem plans to use its own solution to this problem.</p>"},{"location":"aip2/0047-json-ld-compatibility/#additional-json-ld-constructs","title":"Additional JSON-LD Constructs","text":"<p>The following JSON-LD keywords may be useful in DIDComm at some point in the future: <code>@base</code>, <code>@index</code>, <code>@container</code> (cf <code>@list</code> and <code>@set</code>), <code>@nest</code>, <code>@value</code>, <code>@graph</code>, <code>@prefix</code>, <code>@reverse</code>, <code>@version</code>.</p>"},{"location":"aip2/0047-json-ld-compatibility/#drawbacks","title":"Drawbacks","text":"<p>By attempting compatibility but only lightweight usage of JSON-LD, we are neither all-in on JSON-LD, nor all-out. This could cause confusion. We are making the bet that most developers won't need to know or care about the details; they'll simply learn that <code>@type</code> and <code>@id</code> are special, required fields on messages. Designers of protocols will need to know a bit more.</p>"},{"location":"aip2/0047-json-ld-compatibility/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>We could go all-in on JSON-LD. This would require adoption of sophisticated parsing that is impractical on embedded platforms, but it would add a lot of semantic sophistication.</li> <li>We could avoid JSON-LD entirely. This would force us to reinvent the wheel in some cases, and it would be frustrating to our friends in other SSI communities that are more JSON-LD-centric.</li> </ul>"},{"location":"aip2/0047-json-ld-compatibility/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the reversal of JSON-LD's default of unordered arrays valid?</li> <li>Is there a good way to discover that new DIDComm proposals should consider JSON-LD solutions, and make sure such questions get evaluated thoughtfully?</li> </ul>"},{"location":"aip2/0047-json-ld-compatibility/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0048-trust-ping/","title":"Aries RFC 0048: Trust Ping Protocol 1.0","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-02-01</li> <li>Status Note: Numerous implementations. </li> <li>Supersedes: Indy HIPE 0032</li> <li>Start Date: 2018-12-11</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"aip2/0048-trust-ping/#summary","title":"Summary","text":"<p>Describe a standard way for agents to test connectivity, responsiveness, and security of a pairwise channel.</p>"},{"location":"aip2/0048-trust-ping/#motivation","title":"Motivation","text":"<p>Agents are distributed. They are not guaranteed to be connected or running all the time. They support a variety of transports, speak a variety of protocols, and run software from many different vendors.</p> <p>This can make it very difficult to prove that two agents have a functional pairwise channel. Troubleshooting connectivity, responsivenes, and security is vital.</p>"},{"location":"aip2/0048-trust-ping/#tutorial","title":"Tutorial","text":"<p>This protocol is analogous to the familiar <code>ping</code> command in networking--but because it operates over agent-to-agent channels, it is transport agnostic and asynchronous, and it can produce insights into privacy and security that a regular ping cannot.</p>"},{"location":"aip2/0048-trust-ping/#roles","title":"Roles","text":"<p>There are two parties in a trust ping: the <code>sender</code> and the <code>receiver</code>. The sender initiates the trust ping. The receiver responds. If the receiver wants to do a ping of their own, they can, but this is a new interaction in which they become the sender.</p>"},{"location":"aip2/0048-trust-ping/#messages","title":"Messages","text":"<p>The trust ping interaction begins when <code>sender</code> creates a <code>ping</code> message like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/trust_ping/1.0/ping\",\n  \"@id\": \"518be002-de8e-456e-b3d5-8fe472477a86\",\n  \"~timing\": {\n    \"out_time\": \"2018-12-15 04:29:23Z\",\n    \"expires_time\": \"2018-12-15 05:29:23Z\",\n    \"delay_milli\": 0\n  },\n  \"comment\": \"Hi. Are you listening?\",\n  \"response_requested\": true\n}\n</code></pre> <p>Only <code>@type</code> and <code>@id</code> are required; <code>~timing.out_time</code>, <code>~timing.expires_time</code>,  and <code>~timing.delay_milli</code> are optional message timing decorators, and <code>comment</code> follows the conventions of localizable message fields. If present, it may be used to display a human-friendly description of the ping to a user that gives approval to respond. (Whether an agent responds to a trust ping is a decision for each agent owner to make, per policy and/or interaction with their agent.)</p> <p>The <code>response_requested</code> field deserves special mention. The normal expectation of a trust ping is that it elicits a response. However, it may be desirable to do a unilateral trust ping at times--communicate information without any expecation of a reaction. In this case, <code>\"response_requested\": false</code> may be used. This might be useful, for example, to defeat correlation between request and response (to generate noise). Or agents A and B might agree that periodically A will ping B without a response, as a way of evidencing that A is up and functional. If <code>response_requested</code> is false, then the receiver MUST NOT respond.</p> <p>When the message arrives at the receiver, assuming that <code>response_requested</code> is not <code>false</code>, the receiver should reply as quickly as possible with a <code>ping_response</code> message that looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/trust_ping/1.0/ping_response\",\n  \"@id\": \"e002518b-456e-b3d5-de8e-7a86fe472847\",\n  \"~thread\": { \"thid\": \"518be002-de8e-456e-b3d5-8fe472477a86\" },\n  \"~timing\": { \"in_time\": \"2018-12-15 04:29:28Z\", \"out_time\": \"2018-12-15 04:31:00Z\"},\n  \"comment\": \"Hi yourself. I'm here.\"\n}\n</code></pre> <p>Here, <code>@type</code> and <code>~thread</code> are required, and the rest is optional.</p>"},{"location":"aip2/0048-trust-ping/#trust","title":"Trust","text":"<p>This is the \"trust ping protocol\", not just the \"ping protocol.\" The \"trust\" in its name comes from several ../../features that the interaction gains by virtue of its use of standard agent-to-agent conventions:</p> <ol> <li> <p>Messages should be associated with a message trust context that allows sender and receiver to evaluate how much trust can be placed in the channel. For example, both sender and receiver can check whether messages are encrypted with suitable algorithms and keys.</p> </li> <li> <p>Messages may be targeted at any known agent in the other party's sovereign domain, using cross-domain routing conventions, and may be encrypted and packaged to expose exactly and only the information desired, at each hop along the way. This allows two parties to evaluate the completeness of a channel and the alignment of all agents that maintain it.</p> </li> <li> <p>This interaction may be traced using the general message tracing mechanism.</p> </li> </ol>"},{"location":"aip2/0048-trust-ping/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull  request to add your implementation. If the implementation is open source,  include a link to the repo or to the implementation within the repo. Please be  consistent in the \"Name\" field so that a mechanical processing of the RFCs can  generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community; MISSING test results Aries Framework - .NET .NET framework for building agents of all types; MISSING test results Streetcred.id Commercial mobile and web app built using Aries Framework - .NET; MISSING test results Aries Cloud Agent - Python Contributed by the government of British Columbia.; MISSING test results Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases.; MISSING test results Aries Protocol Test Suite MISSING test results"},{"location":"aip2/0050-wallets/","title":"Aries RFC 0050: Wallets","text":"<ul> <li>Authors: Daniel Hardman, Darko Kulic, Vyacheslav Gudkov, Mike Lodder</li> <li>Status: ACCEPTED</li> <li>Since: 2018-07-01</li> <li>Status Note: Fully implemented in Indy SDK, but not yet socialized well in the broader Aries community. Needs some updates to promote better key management; see related RFC about lox. </li> <li>Supersedes: Indy HIPE 0013</li> <li>Start Date: 2018-05-22</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0050-wallets/#summary","title":"Summary","text":"<p>Specify the external interfaces of identity wallets in the Indy ecosystem, as well as some background ../../concepts, theory, tradeoffs, and internal implementation guidelines.</p> <p></p>"},{"location":"aip2/0050-wallets/#motivation","title":"Motivation","text":"<p>Wallets are a familiar component metaphor that SSI has adopted from the world of cryptocurrencies. The translation isn't perfect, though; crypto wallets have only a subset of the ../../features that an identity wallet needs. This causes problems, as coders may approach wallets in Indy with assumptions that are more narrow than our actual design target.</p> <p>Since wallets are a major vector for hacking and cybersecurity issues, casual or fuzzy wallet requirements are a recipe for frustration or disaster. Divergent and substandard implementations could undermine security more broadly. This argues for as much design guidance and implementation help as possible.</p> <p>Wallets are also a unit of identity portability--if an identity owner doesn't like how her software is working, she should be able to exercise her self- sovereignty by taking the contents of her wallet to a new service. This implies that wallets need certain types of interoperability in the ecosystem, if they are to avoid vendor lock-in.</p> <p>All of these reasons--to clarify design scope, to provide uniform high security, and to guarantee interop--suggest that we need a formal RFC to document wallet architecture.</p>"},{"location":"aip2/0050-wallets/#tutorial","title":"Tutorial","text":"<p>(For a slide deck that gives a simplified overview of all the content in this RFC, please see http://bit.ly/2JUcIiT. The deck also includes a link to a recorded presentation, if you prefer something verbal and interactive.)</p>"},{"location":"aip2/0050-wallets/#what-is-an-identity-wallet","title":"What Is an Identity Wallet?","text":"<p>Informally, an identity wallet (preferably not just \"wallet\") is a digital container for data that's needed to control a self-sovereign identity. We borrow this metaphor from physical wallets:</p> <p></p> <p>Notice that we do not carry around in a physical wallet every document, key, card, photo, piece of currency, or credential that we possess. A wallet is a mechanism of convenient control, not an exhaustive repository. A wallet is portable. A wallet is worth safeguarding. Good wallets are organized so we can find things easily. A wallet has a physical location.</p> <p>What does suggest about identity wallets?</p>"},{"location":"aip2/0050-wallets/#types-of-sovereign-data","title":"Types of Sovereign Data","text":"<p>Before we give a definitive answer to that question, let's take a detour for a moment to consider digital data. Actors in a self-sovereign identity ecosystem may own or control many different types of data:</p> <ul> <li>encryption and signing keys</li> <li>payment keys</li> <li>link secrets</li> <li>PII about themselves or others</li> <li>credentials</li> <li>personal documents (e.g., last year's tax filing, journal, love letters)</li> <li>digital breadcrumbs (e.g., purchase history)</li> <li>photos and videos</li> <li>receipts</li> <li>health records</li> </ul> <p>...and much more. Different subsets of data may be worthy of different protection efforts:</p> <p></p> <p>The data can also show huge variety in its size and in its richness:</p> <p></p> <p>Because of the sensitivity difference, the size and richness difference, joint ownership, and different needs for access in different circumstances, we may store digital data in many different locations, with different backup regimes, different levels of security, and different cost profiles.</p>"},{"location":"aip2/0050-wallets/#whats-out-of-scope","title":"What's Out of Scope","text":""},{"location":"aip2/0050-wallets/#not-a-vault","title":"Not a Vault","text":"<p>This variety suggests that an identity wallet as a loose grab-bag of all our digital \"stuff\" will give us a poor design. We won't be able to make good tradeoffs that satisfy everybody; some will want rigorous, optimized search; others will want to minimize storage footprint; others will be concerned about maximizing security.</p> <p>We reserve the term vault to refer to the complex collection of all an identity owner's data:</p> <p></p> <p>Note that a vault can contain an identity wallet. A vault is an important construct, and we may want to formalize its interface. But that is not the subject of this spec.</p>"},{"location":"aip2/0050-wallets/#not-a-cryptocurrency-wallet","title":"Not A Cryptocurrency Wallet","text":"<p>The cryptocurrency community has popularized the term \"wallet\"--and because identity wallets share with crypto wallets both high-tech crypto and a need to store secrets, it is tempting to equate these two ../../concepts. However, an identity wallet can hold more than just cryptocurrency keys, just as a physical wallet can hold more than paper currency. Also, identity wallets may need to manage hundreds of millions of relationships (in the case of large organizations), whereas most crypto wallets manage a small number of keys:</p> <p></p>"},{"location":"aip2/0050-wallets/#not-a-gui","title":"Not a GUI","text":"<p>As used in this spec, an identity wallet is not a visible application, but rather a data store. Although user interfaces (superb ones!) can and should be layered on top of wallets, from indy's perspective the wallet itself consists of a container and its data; its friendly face is a separate construct. We may casually refer to an application as a \"wallet\", but what we really mean is that the application provides an interface to the underlying wallet.</p> <p>This is important because if a user changes which app manages his identity, he should be able to retain the wallet data itself. We are aiming for a better portability story than browsers offer (where if you change browsers, you may be able to export+import your bookmarks, but you have to rebuild all sessions and logins from scratch).</p>"},{"location":"aip2/0050-wallets/#personas","title":"Personas","text":"<p>Wallets have many stakeholders. However, three categories of wallet users are especially impactful on design decisions, so we define a persona for each.</p>"},{"location":"aip2/0050-wallets/#alice-individual-identity-owner","title":"Alice (individual identity owner)","text":"<p>Alice owns several devices, and she has an agent in the cloud. She has a thousand relationships--some with institutions, some with other people. She has a couple hundred credentials. She owns three different types of cryptocurrency. She doesn\u2019t issue or revoke credentials--she just uses them. She receives proofs from other entities (people and orgs). Her main tool for exercising a self-sovereign identity is an app on a mobile device.</p>"},{"location":"aip2/0050-wallets/#faber-intitutional-identity-owner","title":"Faber (intitutional identity owner)","text":"<p>Faber College has an on-prem data center as well as many resources and processes in public and private clouds. It has relationships with a million students, alumni, staff, former staff, applicants, business partners, suppliers, and so forth. Faber issues credentials and must manage their revocation. Faber may use crypto tokens to sell and buy credentials and proofs.</p>"},{"location":"aip2/0050-wallets/#the-org-book-trust-hub","title":"The Org Book (trust hub)","text":"<p>The Org Book holds credentials (business licenses, articles of incorporation, health permits, etc) issued by various government agencies, about millions of other business entities. It needs to index and search credentials quickly. Its data is public. It serves as a reference for many relying parties--thus its trust hub role.</p>"},{"location":"aip2/0050-wallets/#use-cases","title":"Use Cases","text":"<p>The specific uses cases for an identity wallet are too numerous to fully list, but we can summarize them as follows:</p> <p>As an identity owner (any of the personas above), I want to manage identity and its relationships in a way that guarantees security and privacy:</p> <ul> <li>Create an identity</li> <li>Setup protective policies</li> <li>Govern agents</li> <li>Connect and interact with others</li> <li>Recover and revoke</li> <li>Take an identity somewhere else</li> </ul>"},{"location":"aip2/0050-wallets/#managing-secrets","title":"Managing Secrets","text":"<p>Certain sensitive things require special handling. We would never expect to casually lay an ebola zaire sample on the counter in our bio lab; rather, it must never leave a special controlled isolation chamber.</p> <p></p> <p>Cybersecurity in wallets can be greatly enhanced if we take a similar tack with high-value secrets. We prefer to generate such secrets in their final resting place, possibly using a seed if we need determinism. We only use such secrets in their safe place, instead of passing them out to untrusted parties.</p> <p>TPMs, HSMs, and so forth follow these rules. Indy\u2019s current wallet interface does, too. You can\u2019t get private keys out.</p>"},{"location":"aip2/0050-wallets/#composition","title":"Composition","text":"<p>The foregoing discussions about cybersecurity, the desirability of design guidance and careful implementation, and wallet data that includes but is not limited to secrets motivates the following logical organization of identity wallets in Indy:</p> <p></p> <p>The world outside a wallet interfaces with the wallet through a public interface provided by indy-sdk, and implemented only once. This is the block labeled <code>encryption, query (wallet core)</code> in the diagram. The implementation in this layer guarantees proper encryption and secret-handling. It also provides some query ../../features. Records (items) to be stored in a wallet are referenced by a public handle if they are secrets. This public handle might be a public key in a key pair, for example. Records that are not secrets can be returned directly across the API boundary.</p> <p>Underneath, this common wallet code in libindy is supplemented with pluggable storage-- a technology that provides persistence and query ../../features. This pluggable storage could be a file system, an object store, an RDBMS, a NoSQL DB, a Graph DB, a key~value store, or almost anything similar. The pluggable storage is registered with the wallet layer by providing a series of C-callable functions (callbacks). The storage layer doesn't have to worry about encryption at all; by the time data reaches it, it is encrypted robustly, and the layer above the storage takes care of translating queries to and from encrypted form for external consumers of the wallet.</p>"},{"location":"aip2/0050-wallets/#tags-and-queries","title":"Tags and Queries","text":"<p>Searchability in wallets is facilitated with a tagging mechanism. Each item in a wallet can be associated with zero or more tags, where a tag is a <code>key=value</code> pair. Items can be searched based on the tags associated with them, and tag values can be strings or numbers. With a good inventory of tags in a wallet, searching can be robust and efficient--but there is no support for joins, subqueries, and other RDBMS-like constructs, as this would constrain the type of storage plugin that could be written.</p> <p>An example of the tags on a wallet item that is a credential might be:</p> <pre><code>  item-name = \"My Driver's License\"\n  date-issued = \"2018-05-23\"\n  issuer-did = \"ABC\"\n  schema = \"DEF\"\n</code></pre> <p>Tag names and tag values are both case-sensitive.</p> <p>Because tag values are normally encrypted, most tag values can only be tested using the <code>$eq</code>, <code>$neq</code> or <code>$in</code> operators (see Wallet Query Language, next). However, it is possible to force a tag to be stored in the wallet as plain text by naming it with a special prefix, <code>~</code> (tilde). This enables operators like <code>$gt</code>, <code>$lt</code>, and <code>$like</code>. Such tags lose their security guarantees but provide for richer queries; it is up to applications and their users to decide whether the tradeoff is appropriate.</p>"},{"location":"aip2/0050-wallets/#wallet-query-language","title":"Wallet Query Language","text":"<p>Wallets can be searched and filtered using a simple, JSON-based query language. We call this Wallet Query Language (WQL). WQL is designed to require no fancy parsing by storage plugins, and to be easy enough for developers to learn in just a few minutes. It is inspired by MongoDB's query syntax, and can be mapped to SQL, GraphQL, and other query languages supported by storage backends, with minimal effort.</p> <p>Formal definition of WQL language is the following:</p> <pre><code>query = {subquery}\nsubquery = {subquery, ..., subquery} // means subquery AND ... AND subquery\nsubquery = $or: [{subquery},..., {subquery}] // means subquery OR ... OR subquery\nsubquery = $not: {subquery} // means NOT (subquery)\nsubquery = \"tagName\": tagValue // means tagName == tagValue\nsubquery = \"tagName\": {$neq: tagValue} // means tagName != tagValue\nsubquery = \"tagName\": {$gt: tagValue} // means tagName &gt; tagValue\nsubquery = \"tagName\": {$gte: tagValue} // means tagName &gt;= tagValue\nsubquery = \"tagName\": {$lt: tagValue} // means tagName &lt; tagValue\nsubquery = \"tagName\": {$lte: tagValue} // means tagName &lt;= tagValue\nsubquery = \"tagName\": {$like: tagValue} // means tagName LIKE tagValue\nsubquery = \"tagName\": {$in: [tagValue, ..., tagValue]} // means tagName IN (tagValue, ..., tagValue)\n</code></pre>"},{"location":"aip2/0050-wallets/#sample-wql-query-1","title":"Sample WQL Query 1","text":"<p>Get all credentials where subject like \u2018Acme%\u2019 and issue_date &gt; last week. (Note here that the name of the issue date tag begins with a tilde, telling the wallet to store its value unencrypted, which makes the <code>$gt</code> operator possible.)</p> <pre><code>{\n  \"~subject\": {\"$like\": \"Acme%\"},\n  \"~issue_date\": {\"$gt\": 2018-06-01}\n}\n</code></pre>"},{"location":"aip2/0050-wallets/#sample-wql-query-2","title":"Sample WQL Query 2","text":"<p>Get all credentials about me where schema in (a, b, c) and issuer in (d, e, f).</p> <pre><code>{\n  \"schema_id\": {\"$in\": [\"a\", \"b\", \"c\"]},\n  \"issuer_id\": {\"$in\": [\"d\", \"e\", \"f\"]},\n  \"holder_role\": \"self\"\n}\n</code></pre>"},{"location":"aip2/0050-wallets/#encryption","title":"Encryption","text":"<p>Wallets need very robust encryption. However, they must also be searchable, and the encryption must be equally strong regardless of which storage technology is used. We want to be able to hide data patterns in the encrypted data, such that an attacker cannot see common prefixes on keys, or common fragments of data in encrypted values. And we want to rotate the key that protects a wallet without having to re-encrypt all its content. This suggests that a trivial encryption scheme, where we pick a symmetric key and encrypt everything with it, is not adequate.</p> <p>Instead, wallet encryption takes the following approach:</p> <ul> <li>For attributes of items that are searchable  (<code>type</code>, <code>id</code>, <code>tag_name</code>,   <code>tag_value</code>):</li> <li>The same input produces the same output.</li> <li>Every attribute \"column\" has its own key. That is, there's an encryption key for     all <code>type</code> attributes, a different encryption key for all <code>id</code> attributes,     and so forth.</li> <li>Initialization vector is HMAC-256 value of the field being encrypted.</li> <li> <p>Two more keys are needed for HMAC--one for <code>type</code> and <code>id</code> and one for     <code>tag_name</code> and <code>tag_value</code>.</p> </li> <li> <p>For item values:</p> </li> <li>A new value key is generated for each item value.</li> <li>Value key is encrypted using key for that field. (Value key also has a \"column\"     key that contributes to its encryption.)</li> <li> <p>Initialization vector is generated every time for both encryptions.</p> </li> <li> <p>For wallet keys:</p> </li> <li>Encrypted with master key with random initialization vector.</li> </ul> <p>The 7 \"column\" keys are concatenated and encrypted with a wallet master key,  then saved into the metadata of the wallet. This allows the master key to be rotated  without re-encrypting all the items in the wallet.</p> <p>Today, all encryption is done using ChaCha20-Poly1305, with HMAC-SHA256. This is a solid, secure encryption algorithm, well tested and widely supported. However, we anticipate the desire to use different cipher suites, so in the future we will make the cipher suite pluggable.</p> <p>The way the individual fields are encrypted is shown in the following diagram. Here, data is shown as if stored in a relational database with tables. Wallet storage may or may not use tables, but regardless of how the storage distributes and divides the data, the logical relationships and the encryption shown in the diagram apply.</p> <p></p>"},{"location":"aip2/0050-wallets/#pluggable-storage","title":"Pluggable Storage","text":"<p>Although Indy infrastructure will provide only one wallet implementation it will allow to plug different storages for covering of different use cases. Default storage shipped with libindy will be sqlite based and well suited for agents running on edge devices. The API endpoint <code>register_wallet_storage</code> will allow Indy Developers to register a custom storage implementation as a set of handlers.</p> <p>A storage implementation does not need any special security ../../features. It stores data that was already encrypted by libindy (or data that needs no encryption/protection, in the case of unencrypted tag values). It searches data in whatever form it is persisted, without any translation. It returns data as persisted, and lets the common wallet infrastructure in libindy decrypt it before return it to the user.</p>"},{"location":"aip2/0050-wallets/#secure-enclaves","title":"Secure Enclaves","text":"<p>Secure Enclaves are purposely designed to manage, generate, and securely store cryptographic material. Enclaves can be either specially designed hardware (e.g. HSM, TPM) or trusted execution environments (TEE) that isolate code and data from operating systems (e.g. Intel SGX, AMD SVE, ARM Trustzone). Enclaves can replace common cryptographic operations that wallets perform (e.g. encryption, signing). Some secrets cannot be stored in wallets like the key that encrypts the wallet itself or keys that are backed up. These cannot be stored in enclaves as keys stored in enclaves cannot be extracted. Enclaves can still protect these secrets via a mechanism called wrapping.</p>"},{"location":"aip2/0050-wallets/#enclave-wrapping","title":"Enclave Wrapping","text":"<p>Suppose I have a secret, X, that needs maximum protection. However, I can\u2019t store X in my secure enclave because I need to use it for operations that the enclave can\u2019t do for me; I need direct access. So how to I extend enclave protections to encompass my secret?</p> <p>I ask the secure enclave to generate a key, Y, that will be used to protect X. Y is called a wrapping key. I give X to the secure enclave and ask that it be encrypted with wrapping key Y. The enclave returns X\u2019 (ciphertext of X, now called a wrapped secret), which I can leave on disk with confidence; it cannot be decrypted to X without involving the secure enclave. Later, when I want to decrypt, I give wrapped secret X\u2019 to the secure enclave and ask it to give me back X by decrypting with wrapping key Y.</p> <p></p> <p>You could ask whether this really increases security. If you can get into the enclave, you can wrap or unwrap at will.</p> <p>The answer is that an unwrapped secret is protected by only one thing--whatever ACLs exist on the filesystem or storage where it resides. A wrapped secret is protected by two things--the ACLs and the enclave. OS access may breach either one, but pulling a hard drive out of a device will not breach the enclave.</p>"},{"location":"aip2/0050-wallets/#paper-wallets","title":"Paper Wallets","text":"<p>It is possible to persist wallet data to physical paper (or, for that matter, to etched metal or other physical media) instead of a digital container. Such data has attractive storage properties (e.g., may survive natural disasters, power outages, and other challenges that would destroy digital data). Of course, by leaving the digital realm, the data loses its accessibility over standard APIs.</p> <p>We anticipate that paper wallets will play a role in backup and recovery, and possibly in enabling SSI usage by populations that lack easy access to smartphones or the internet. Our wallet design should be friendly to such usage, but physical persistence of data is beyond the scope of Indy's plugin storage model and thus not explored further in this RFC.</p>"},{"location":"aip2/0050-wallets/#backup-and-recovery","title":"Backup and Recovery","text":"<p>Wallets need a backup and recovery feature, and also a way to export data and import it. Indy's wallet API includes an export function and an import function that may be helpful in such use cases. Today, the export is unfiltered--all data is exported. The import is also all-or-nothing and must be to an empty wallet; it is not possible to import selectively or to update existing records during import.</p> <p>A future version of import and export may add filtering, overwrite, and progress callbacks. It may also allow supporting or auxiliary data (other than what the wallet directly persists) to be associated with the export/import payload.</p> <p>For technical details on how export and import work, please see the internal design docs.</p>"},{"location":"aip2/0050-wallets/#reference","title":"Reference","text":"<ul> <li>Wallet Design</li> </ul>"},{"location":"aip2/0050-wallets/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>We could implement wallets purely as built already in the cryptocurrency world. This would give us great security (except for crypto wallets that are cloud based), and perhaps moderately good usability.</p> <p>However, it would also mean we could not store credentials in wallets. Indy would then need an alternate mechanism to scan some sort of container when trying to satisfy a proof request. And it would mean that a person's identity would not be portable via a single container; rather, if you wanted to take your identity to a new place, you'd have to copy all crypto keys in your crypto wallet, plus copy all your credentials using some other mechanism. It would also fragment the places where you could maintain an audit trail of your SSI activities.</p>"},{"location":"aip2/0050-wallets/#prior-art","title":"Prior art","text":"<p>See comment about crypto wallets, above.</p>"},{"location":"aip2/0050-wallets/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What is the relationship between a threading model in pluggable storage and   the threading model of wallets? Is it always legal to be reading and writing   wallets from multiple threads at the same time?</li> </ul>"},{"location":"aip2/0050-wallets/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy SDK Most agents that implement wallets get their wallet support from Indy SDK. These are not listed separately."},{"location":"aip2/0092-transport-return-route/","title":"Aries RFC 0092: Transports Return Route","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: ACCEPTED</li> <li>Since: 2019-12-06</li> <li>Status Note:  </li> <li>Supersedes: INDY HIPE PR 116</li> <li>Start Date: 2019-03-04</li> <li>Tags: feature</li> </ul>"},{"location":"aip2/0092-transport-return-route/#summary","title":"Summary","text":"<p>Agents can indicate that an inbound message transmission may also be used as a return route for messages. This allows for transports of increased efficiency as well as agents without an inbound route.</p>"},{"location":"aip2/0092-transport-return-route/#motivation","title":"Motivation","text":"<p>Inbound HTTP and Websockets are used only for receiving messages by default. Return messages are sent using their own outbound connections. Including a decorator allows the receiving agent to know that using the inbound connection as a return route is acceptable. This allows two way communication with agents that may not have an inbound route available. Agents without an inbound route include mobile agents, and agents that use a client (and not a server) for communication.</p> <p>This decorator is intended to facilitate message communication between a client based agent (an agent that can only operate as a client, not a server) and the server based agents they communicate directly with. Use on messages that will be forwarded is not allowed.</p>"},{"location":"aip2/0092-transport-return-route/#tutorial","title":"Tutorial","text":"<p>When you send a message through a connection, you can use the <code>~transport</code> decorator on the message and specify <code>return_route</code>. The value of <code>return_route</code> is discussed in the Reference section of this document.</p> <pre><code>{\n    \"~transport\": {\n        \"return_route\": \"all\"\n    }\n}\n</code></pre>"},{"location":"aip2/0092-transport-return-route/#reference","title":"Reference","text":"<ul> <li> <p><code>return_route</code> has the following acceptable values:</p> </li> <li> <p><code>none</code>: Default. No messages should be returned over this connection.</p> </li> <li><code>all</code>: Send all messages for this cryptographic key over the connection.</li> <li><code>thread</code>: Send all messages matching the cryptographic key and thread specified in the <code>return_route_thread</code> attribute.</li> </ul> <p>The <code>~transport</code> decorator should be processed after unpacking and prior to routing the message to a message handler.</p> <p>For HTTP transports, the presence of this message decorator indicates that the receiving agent MAY hold onto the connection and use it to return messages as designated. HTTP transports will only be able to receive at most one message at a time. Websocket transports are capable of receiving multiple messages.</p> <p>Compliance with this indicator is optional for agents generally, but required for agents wishing to connect with client based agents.</p>"},{"location":"aip2/0092-transport-return-route/#drawbacks","title":"Drawbacks","text":"<ul> <li>Application varies between transports, adding complexity to agent development.</li> </ul>"},{"location":"aip2/0092-transport-return-route/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Using a transport level decorator makes this behavior transport agnostic.</li> </ul>"},{"location":"aip2/0092-transport-return-route/#prior-art","title":"Prior art","text":"<p>The Decorators RFC describes scope of decorators. Transport isn't one of the scopes listed.</p>"},{"location":"aip2/0092-transport-return-route/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Protocol Test Suite Used in Tests"},{"location":"aip2/0094-cross-domain-messaging/","title":"Aries RFC 0094: Cross-Domain Messaging","text":"<ul> <li>Authors: Stephen Curran</li> <li>Status: ACCEPTED</li> <li>Since: 2018-10-29</li> <li>Status Note: Socialized and broadly understood in other conceptual RFCs about routing. </li> <li>Supersedes: 0022-Cross-Domain-Messaging</li> <li>Start Date: 2018-08-13</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0094-cross-domain-messaging/#summary","title":"Summary","text":"<p>There are two layers of messages that combine to enable interoperable self-sovereign identity DIDcomm (formerly called Agent-to-Agent) communication. At the highest level are Agent Messages - messages sent between Identities to accomplish some shared goal. For example, establishing a connection between identities, issuing a Verifiable Credential from an Issuer to a Holder or even the simple delivery of a text Instant Message from one person to another. Agent Messages are delivered via the second, lower layer of messaging - encryption envelopes. An encryption envelope is a wrapper (envelope) around an Agent Message to enable the secure delivery of a message from one Agent directly to another Agent. An Agent Message going from its Sender to its Receiver may be passed through a number of Agents, and an encryption envelope is used for each hop of the journey.</p> <p>This RFC addresses Cross Domain messaging to enable interoperability. This is one of a series of related RFCs that address interoperability, including DIDDoc Conventions, Agent Messages and Encryption Envelope. Those RFCs should be considered together in understanding DIDcomm messaging.</p> <p>In order to send a message from one Identity to another, the sending Identity must know something about the Receiver's domain - the Receiver's configuration of Agents. This RFC outlines how a domain MUST present itself to enable the Sender to know enough to be able to send a message to an Agent in the domain.  In support of that, a DIDcomm protocol (currently consisting of just one Message Type) is introduced to route messages through a network of Agents in both the Sender and Receiver's domain. This RFC provides the specification of the \"Forward\" Agent Message Type - an envelope that indicates the destination of a message without revealing anything about the message.</p> <p>The goal of this RFC is to define the rules that domains MUST follow to enable the delivery of Agent messages from a Sending Agent to a Receiver Agent in a secure and privacy-preserving manner.</p>"},{"location":"aip2/0094-cross-domain-messaging/#motivation","title":"Motivation","text":"<p>The purpose of this RFC and its related RFCs is to define a layered messaging protocol such that we can ignore the delivery of messages as we discuss the much richer Agent Messaging types and interactions. That is, we can assume that there is no need to include in an Agent message anything about how to route the message to the Receiver - it just magically happens. Alice (via her App Agent) sends a message to Bob, and (because of implementations based on this series of RFCs) we can ignore how the actual message got to Bob's App Agent.</p> <p>Put another way - these RFCs are about envelopes. They define a way to put a message - any message - into an envelope, put it into an outbound mailbox and have it magically appear in the Receiver's inbound mailbox in a secure and privacy-preserving manner. Once we have that, we can focus on letters and not how letters are sent.</p> <p>Most importantly for Agent to Agent interoperability, this RFC clearly defines the assumptions necessary to deliver a message from one domain to another - e.g. what exactly does Alice have to know about Bob's domain to send Bob a message?</p>"},{"location":"aip2/0094-cross-domain-messaging/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0094-cross-domain-messaging/#core-messaging-goals","title":"Core Messaging Goals","text":"<p>These are vital design goals for this RFC:</p> <ol> <li>Sender Encapsulation: We SHOULD minimize what the Receiver has to know about the domain (routing tree or agent infrastructure) of the Sender in order for them to communicate.</li> <li>Receiver Encapsulation: We SHOULD minimize what the Sender has to know about the domain (routing tree or agent infrastructure) of the Receiver in order for them to communicate.</li> <li>Independent Keys: Private signing keys SHOULD NOT be shared between agents; each agent SHOULD be separately identifiable for accounting and authorization/revocation purposes.</li> <li>Need To Know Information Sharing: Information made available to intermediary agents between the Sender and Receiver SHOULD be minimized to what is needed to perform the agent's role in the process.</li> </ol>"},{"location":"aip2/0094-cross-domain-messaging/#assumptions","title":"Assumptions","text":"<p>The following are assumptions upon which this RFC is predicated.</p>"},{"location":"aip2/0094-cross-domain-messaging/#terminology","title":"Terminology","text":"<p>The following terms are used in this RFC with the following meanings:</p> <ul> <li>Domain - a set of Agents collaborating on behalf of an Identity</li> <li>It's assumed that the Agents of a Domain were developed by a single vendor and so MAY have implementation-specific mechanisms for tracking extra information about one another.</li> <li>An example of two Domains is provided in the image below.</li> <li>Edge Agents - the Agents involved in sending (creating) and receiving (processing) an Agent Message</li> <li>Sender - the Agent sending an original Agent Message</li> <li>Receiver - the Agent intended to receive an Agent Message from the Sender</li> <li>Note: A message MAY pass through many Agents between the Sender and Receiver</li> <li>Domain Endpoint - a physical endpoint for messages into domains that MUST be assumed to be shared across many Identities</li> <li>Shared by many identities (e.g. https://endpoint.agentsRus.com)</li> <li>Agency - the handler for messages sent to the Domain Endpoint.</li> <li>Mediators - agents explicitly known to the sender as part of routing messages to a Receiver.</li> <li>DID - reference to the literal Decentralized ID text</li> <li>e.g. did:sov:1234abcd</li> <li>DID#keyname - reference to the DID appended with \"#\" and a specific key from the DIDDoc</li> <li>e.g. did:sov:1234abcd#1 references key \"1\" of the \"did:sov:1234abcd\" DIDDoc.</li> <li>Note: The #keyname is NOT the actual Public Key - it's a reference to an entry in the DIDDoc that contains the Public Key.</li> </ul>"},{"location":"aip2/0094-cross-domain-messaging/#diddoc","title":"DIDDoc","text":"<p>The term \"DIDDoc\" is used in this RFC as it is defined in the DID Specification:</p> <ul> <li>a collection of public keys and endpoints,</li> <li>controlled by an identity,</li> <li>associated with a DID, and</li> <li>used for a relationship.</li> </ul> <p>A DID can be resolved to get its corresponding DIDDoc by any Agent that needs access to the DIDDoc. This is true whether talking about a DID on a Public Ledger, or a pairwise DID (using the did:peer method) persisted only to the parties of the relationship. In the case of pairwise DIDs, it's the (implementation specific) domain's responsibility to ensure such resolution is available to all Agents requiring it within the domain.</p>"},{"location":"aip2/0094-cross-domain-messaging/#messages-are-private","title":"Messages are Private","text":"<p>Agent Messages sent from a Sender to a Receiver SHOULD be private. That is, the Sender SHOULD encrypt the message with a public key for the Receiver. Any agent in between the Sender and Receiver will know only to whom the message is intended (by DID and possibly keyname within the DID), not anything about the message.</p>"},{"location":"aip2/0094-cross-domain-messaging/#the-sender-knows-the-receiver","title":"The Sender Knows The Receiver","text":"<p>This RFC assumes that the Sender knows the Receiver's DID and, within the DIDDoc for that DID, the keyname to use for the Receiver's Agent. How the Sender knows the DID and keyname to send the message is not defined within this RFC - that is a higher level concern.</p> <p>The Receiver's DID MAY be a public or pairwise DID, and MAY be on a Public Ledger or only shared between the parties of the relationship.</p>"},{"location":"aip2/0094-cross-domain-messaging/#example-domain-and-diddoc","title":"Example: Domain and DIDDoc","text":"<p>The following is an example of an arbitrary pair of domains that will be helpful in defining the requirements in this RFC.</p> <p></p> <p>In the diagram above:</p> <ul> <li>Alice has</li> <li>1 Edge Agent - \"1\"</li> <li>1 Routing Agent - \"2\"</li> <li>1 Domain Endpoint - \"8\"</li> <li>Bob has</li> <li>3 Edge Agents - \"4\", \"5\" and \"6\"<ul> <li>\"6\" is an Edge Agent in the cloud, \"4\" and \"5\" are physical devices.</li> </ul> </li> <li>1 Routing Agent - \"3\"</li> <li>1 Domain Endpoint - \"9\"</li> </ul>"},{"location":"aip2/0094-cross-domain-messaging/#bobs-did-for-his-relationship-with-alice","title":"Bob's DID for his Relationship with Alice","text":"<p>Bob\u2019s domain has 3 devices he uses for processing messages - two phones (4 and 5) and a cloud-based agent (6). However, in Bob's relationship with Alice, he ONLY uses one phone (4) and the cloud-based agent (6). Thus the key for device 5 is left out of the DIDDoc (see below).</p> <p>Note that the keyname for the Routing Agent (3) is called \"routing\". This is an example of the kind of convention needed to allow the Sender's agents to know the keys for Agents with a designated role in the receiving domain - as defined in the <code>DIDDoc Conventions</code> RFC.</p> <pre><code>{\n  \"@context\": \"https://w3id.org/did/v1\",\n  \"id\": \"did:sov:1234abcd\",\n  \"publicKey\": [\n    {\"id\": \"routing\", \"type\": \"RsaVerificationKey2018\",  \"owner\": \"did:sov:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC X\u2026\"},\n    {\"id\": \"4\", \"type\": \"RsaVerificationKey2018\",  \"owner\": \"did:sov:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC 9\u2026\"},\n    {\"id\": \"6\", \"type\": \"RsaVerificationKey2018\",  \"owner\": \"did:sov:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC A\u2026\"}\n  ],\n  \"authentication\": [\n    {\"type\": \"RsaSignatureAuthentication2018\", \"publicKey\": \"did:sov:1234abcd#4\"}\n  ],\n  \"service\": [\n    {\n      \"id\": \"did:example:123456789abcdefghi;did-communication\",\n      \"type\": \"did-communication\",\n      \"priority\" : 0,\n      \"recipientKeys\" : [ \"did:example:1234abcd#4\" ],\n      \"routingKeys\" : [ \"did:example:1234abcd#3\" ],\n      \"serviceEndpoint\" : \"did:example:xd45fr567794lrzti67;did-communication\"\n    }\n  ]\n}\n</code></pre> <p>For the purposes of this discussion we are defining the message flow to be:</p> <p>1 \u2192 2 \u2192 8 \u2192 9 \u2192 3 \u2192 4</p> <p>However, that flow is arbitrary and only one hop is actually required:</p> <ul> <li>1 is the Sender in this case and so must send the first message.</li> <li>4 is the Receiver in this case and so must receive the message.</li> </ul>"},{"location":"aip2/0094-cross-domain-messaging/#encryption-envelopes","title":"Encryption Envelopes","text":"<p>An encryption envelope is used to transport any Agent Message from one Agent directly to another. In our example message flow above, there are five encryption envelopes sent, one for each hop in the flow. The separate Encryption Envelope RFC covers those details.</p>"},{"location":"aip2/0094-cross-domain-messaging/#agent-message-format","title":"Agent Message Format","text":"<p>An Agent Message defines the format of messages processed by Agents. Details about the general form of Agent Messages can be found in the Agent Messages RFC.</p> <p>This RFC specifies (below) the \"Forward\" message type, a part of the \"Routing\" family of Agent Messages.</p>"},{"location":"aip2/0094-cross-domain-messaging/#did-diddoc-and-routing","title":"DID, DIDDoc and Routing","text":"<p>A DID owned by the Receiver is resolvable by the Sender as a DIDDoc using either a Public Ledger or using pairwise DIDs based on the <code>did:peer</code> method. The related DIDcomm DIDDoc Conventions RFC defines the required contents of a DIDDoc created by the receiving entity. Notably, the DIDDoc given to the Sender by the Receiver specifies the required routing of the message through an optional set of mediators.</p>"},{"location":"aip2/0094-cross-domain-messaging/#cross-domain-interoperability","title":"Cross Domain Interoperability","text":"<p>A key goal for interoperability is that we want other domains to know just enough about the configuration of a domain to which they are delivering a message, but no more. The following walks through those minimum requirements.</p>"},{"location":"aip2/0094-cross-domain-messaging/#required-the-did-and-diddoc","title":"Required: The DID and DIDDoc","text":"<p>As noted above, the Sender of an Agent to Agent Message has the DID of the Receiver, and knows the key(s) from the DIDDoc to use for the Receiver's Agent(s).</p> <p>Example: Alice wants to send a message from her phone (1) to Bob's phone (4). She has Bob's B:did@A:B, the DID/DIDDoc Bob created and gave to Alice to use for their relationship. Alice created A:did@A:B and gave that to Bob, but we don't need to use that in this example. The content of the DIDDoc for B:did@A:B is presented above.</p>"},{"location":"aip2/0094-cross-domain-messaging/#required-end-to-end-encryption-of-the-agent-message","title":"Required: End-to-End encryption of the Agent Message","text":"<p>The Agent Message from the Sender SHOULD be hidden from all Agents other than the Receiver. Thus, it SHOULD be encrypted with the public key of the Receiver. Based on our assumptions, the Sender can get the public key of the Receiver agent because they know the DID#keyname string, can resolve the DID to the DIDDoc and find the public key associated with DID#keyname in the DIDDoc. In our example above, that is the key associated with \"did:sov:1234abcd#4\".</p> <p>Most Sender-to-Receiver messages will be sent between parties that have shared pairwise DIDs (using the <code>did:peer</code> method). When that is true, the Sender will (usually) AuthCrypt the message. If that is not the case, or for some other reason the Sender does not want to AuthCrypt the message, AnonCrypt will be used. In either case, the Indy-SDK <code>pack()</code> function handles the encryption.</p> <p>If there are mediators specified in the DID service endpoint for the Receiver agent, the Sender must wrap the message for the Receiver in a 'Forward' message for each mediator. It is assumed that the Receiver can determine the from <code>did</code> based on the <code>to</code> DID (or the sender's verkey) using their pairwise relationship.</p> <pre><code>{\n  \"@type\" : \"https://didcomm.org/routing/1.0/forward\",\n  \"@id\": \"54ad1a63-29bd-4a59-abed-1c5b1026e6fd\",\n  \"to\"   : \"did:sov:1234abcd#4\",\n  \"msg\"  : { json object from &lt;pack(AgentMessage,valueOf(did:sov:1234abcd#4), privKey(A.did@A:B#1))&gt; }\n}\n</code></pre> <p>Notes</p> <ul> <li>the <code>@type</code> value is in the precise URI format for the \"forward\" message type</li> <li>Indy-SDK's \"pack\" function is used to AuthCrypt the message using the Receiver's public key and the Sender's private key.</li> <li>If the Sender wishes to remain anonymous or knows the Receiver does not know the Sender's public key, AnonCrypt is used.</li> <li>More details about the Indy-SDK <code>pack()</code> function can be found in the Encryption Envelope RFC.</li> <li>The Indy-SDK's \"unpack()\" function MUST return the public key of the private key used to sign the message. See the note below for the background on this.</li> <li>Additional <code>forward</code> messages are created to wrap each forward for each mediator.</li> </ul> <p>The bullet above about the unpack() function returning the signer's public key deserves some additional attention. The Receiver of the message knows from the \"to\" field the DID to which the message was sent. From that, the Receiver is expected to be able to determine the DID of the Sender, and from that, access the Sender's DIDDoc. However, knowing the DIDDoc is not enough to know from whom the message was sent - which key was used to send the message, and hence, which Agent controls the Sending private key. This information MUST be made known to the Receiver (from unpack()) when AuthCrypt is used so that the Receiver knows which key was used to the send the message and can, for example, use that key in responding to the arriving Message.</p> <p>The Sender can now send the Forward Agent Message on its way via the first of the encryption envelope. In our example, the Sender sends the Agent Message to 2 (in the Sender's domain), who in turn sends it to 8. That of course, is arbitrary - the Sender's Domain could have any configuration of Agents for outbound messages. The Agent Message above is passed unchanged, with each Agent able to see the <code>@type</code>, <code>to</code> and <code>msg</code> fields as described above. This continues until the outer <code>forward</code> message gets to the Receiver's first mediator or the Receiver's agent (if there are no mediators). Each agent decrypts the received encrypted envelope and either forwards it (if a mediator) or processes it (if the Receiver Agent). Per the Encryption Envelope RFC, between Agents the Agent Message is pack()'d and unpack()'d as appropriate or required.</p> <p>The diagram below shows an example use of the <code>forward</code> messages to encrypt the message all the way to the Receiver with two mediators in between - a shared domain endpoint (aka https://agents-r-us.com) and a routing agent owned by the receiving entity.</p> <p></p>"},{"location":"aip2/0094-cross-domain-messaging/#required-cross-domain-encryption","title":"Required: Cross Domain Encryption","text":"<p>While within a domain the Agents MAY choose to use encryption or not when sending messages from Agent to Agent, encryption MUST be used when sending a message into the Receiver's domain. The endpoint agent unpack()'s the encryption envelope and processes the message - usually a <code>forward</code>. Note that within a domain, the agents may use arbitrary relays for messages, unknown to the sender. How the agents within the domain knows where to send the message is implementation specific - likely some sort of dynamic DID-to-Agent routing table. If the path to the receiving agent includes mediators, the message must go through those mediators in order (for example, through 3 in our example) as the message being forwarded has been encrypted for the mediators.</p>"},{"location":"aip2/0094-cross-domain-messaging/#required-mediators-process-forward-messages","title":"Required: Mediators Process Forward Messages","text":"<p>When a mediator (eventually) receives the message, it determines it is the target of the (current) outer forward Agent Message and so decrypts the message's <code>msg</code> value to reveal the inner \"Forward\" message.  Mediators use their (implementation specific) knowledge to map from the <code>to</code> field to deliver the message to the physical endpoint of the next agent to process the message on it's way to the Receiver.</p>"},{"location":"aip2/0094-cross-domain-messaging/#required-the-receiver-app-agent-decryptsprocesses-the-agent-message","title":"Required: The Receiver App Agent Decrypts/Processes the Agent Message","text":"<p>When the Receiver Agent receives the message, it determines it is the target of the forward message, decrypts the payload and processes the message.</p>"},{"location":"aip2/0094-cross-domain-messaging/#exposed-data","title":"Exposed Data","text":"<p>The following summarizes the information needed by the Sender's agents:</p> <ul> <li>The DID to use for the relationship, and its related DIDDoc</li> <li>A public key entry for the Receiver agent</li> <li>From the DIDDoc, a service entry for each Receiver agent that includes:</li> <li>a public DID or physical endpoint and public key for the endpoint agent.</li> <li>An optional order list of public keys (<code>RoutingKeys</code>) of mediators used by the Receiver in delivering the message.</li> </ul> <p>The DIDDoc will have a public key entry for each additional Agent message Receiver and each mediator.</p> <p>In many cases, the entry for the endpoint agent should be a public DID, as it will likely be operated by an agency (for example, https://agents-r-us.com) rather than by the Receiver entity (for example, a person). By making that a public DID in that case, the agency can rotate its public key(s) for receiving messages in a single operation, rather than having to notify each identity owner and in turn having them update the public key in every pairwise DID that uses that endpoint.</p>"},{"location":"aip2/0094-cross-domain-messaging/#data-not-exposed","title":"Data Not Exposed","text":"<p>Given the sequence specified above, the following data is NOT exposed to the Sender's agents:</p> <ul> <li>The relays within the Receiver's domain</li> <li>Receiver agents the identity chooses not to include in a given DIDDoc</li> <li>The physical endpoints of agents within the Receiver's domain (other than the Domain Endpoint)</li> <li>The physical endpoints and, as required, associated public keys, are shared as needed by the agents within the Receiver's domain.</li> </ul>"},{"location":"aip2/0094-cross-domain-messaging/#message-types","title":"Message Types","text":"<p>The following Message Types are defined in this RFC.</p>"},{"location":"aip2/0094-cross-domain-messaging/#corerouting10forward","title":"Core:Routing:1.0:Forward","text":"<p>The core message type \"forward\", version 1.0 of the \"routing\" family is defined in this RFC. An example of the message is the following:</p> <pre><code>{\n  \"@type\" : \"https://didcomm.org/routing/1.0/forward\",\n  \"@id\": \"54ad1a63-29bd-4a59-abed-1c5b1026e6fd\",\n  \"to\"   : \"did:sov:1234abcd#4\",\n  \"msg\"  : { json object from &lt;pack(AgentMessage,valueOf(did:sov:1234abcd#4), privKey(A.did@A:B#1))&gt; }\n}\n</code></pre> <p>The <code>to</code> field is required and takes one of two forms:</p> <ul> <li>A DID without a key reference (e.g. <code>did:sov:1234abcd</code>)</li> <li>A DID with a key reference (e.g. <code>did:sov:1234abcd#4</code>)</li> </ul> <p>The first form is used when sending forward messages across one or more agents that do not need to know the details of a domain. The Receiver of the message is the designated <code>Routing Agent</code> in the Receiver Domain, as it controls the key used to decrypt messages sent to the domain, but not to a specific Agent.</p> <p>The second form is used when the precise key (and hence, the Agent controlling that key) is used to encrypt the Agent Message placed in the <code>msg</code> field.</p> <p>The <code>msg</code> field calls the Indy-SDK <code>pack()</code> function to encrypt the Agent Message to be forwarded. The Sender calls the <code>pack()</code> with the suitable arguments to AnonCrypt or AuthCrypt the message. The <code>pack()</code> and <code>unpack()</code> functions are described in more detail in the Encryption Envelope RFC.</p>"},{"location":"aip2/0094-cross-domain-messaging/#reference","title":"Reference","text":"<p>See the other RFCs referenced in this document:</p> <ul> <li>DIDcomm</li> <li>Encryption Envelope</li> <li>Agent Messages</li> <li>DIDDoc Conventions</li> </ul>"},{"location":"aip2/0094-cross-domain-messaging/#drawbacks","title":"Drawbacks","text":"<p>N/A</p>"},{"location":"aip2/0094-cross-domain-messaging/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>A number of discussions were held about this RFC. In those discussions, the rationale for the RFC evolved into the text, and the alternatives were eliminated. See prior versions of the superseded HIPE (in status section, above) for details.</p> <p>A suggestion was made that the following optional parameters could be defined in the \"routing/1.0/forward\" message type:</p> <ul> <li>forward-after: specify that the message should not be forwarded until the system clock shows a particular time, or until a particular interval has elapsed. This could be useful to defeat timing correlations. Particular agents might not support it.</li> <li>mix-config: artificially introduce extra hops to obscure path (use a mix network like TOR)</li> </ul> <p>The optional parameters have been left off for now, but could be added in this RFC or to a later version of the message type.</p>"},{"location":"aip2/0094-cross-domain-messaging/#prior-art","title":"Prior art","text":"<p>N/A</p>"},{"location":"aip2/0094-cross-domain-messaging/#unresolved-questions","title":"Unresolved questions","text":"<p>N/A</p>"},{"location":"aip2/0094-cross-domain-messaging/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0095-basic-message/","title":"Aries RFC 0095: Basic Message Protocol 1.0","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: ADOPTED</li> <li>Since: 2019-08-06</li> <li>Status Note:  </li> <li>Supersedes: Indy 0033</li> <li>Start Date: 2019-01-16</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"aip2/0095-basic-message/#summary","title":"Summary","text":"<p>The BasicMessage protocol describes a stateless, easy to support user message protocol. It has a single message type used to communicate.</p>"},{"location":"aip2/0095-basic-message/#motivation","title":"Motivation","text":"<p>It is a useful feature to be able to communicate human written messages. BasicMessage is the most basic form of this written message communication, explicitly excluding advanced ../../features to make implementation easier.</p>"},{"location":"aip2/0095-basic-message/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0095-basic-message/#roles","title":"Roles","text":"<p>There are two roles in this protocol: sender and receiver. It is anticipated that both roles are supported by agents that provide an interface for humans, but it is possible for an agent to only act as a sender (do not process received messages) or a receiver (will never send messages).</p>"},{"location":"aip2/0095-basic-message/#states","title":"States","text":"<p>There are not really states in this protocol, as sending a message leaves both parties in the same state they were before.</p>"},{"location":"aip2/0095-basic-message/#out-of-scope","title":"Out of Scope","text":"<p>There are many useful ../../features of user messaging systems that we will not be adding to this protocol. We anticipate the development of more advanced and full-featured message protocols to fill these needs. Features that are considered out of scope for this protocol include:</p> <ul> <li>read receipts</li> <li>emojii responses</li> <li>typing indicators</li> <li>message replies (threading)</li> <li>multi-party (group) messages</li> <li>attachments</li> </ul>"},{"location":"aip2/0095-basic-message/#reference","title":"Reference","text":"<p>Protocol: https://didcomm.org/basicmessage/1.0/</p> <p>message</p> <ul> <li>sent_time - timestamp in ISO 8601 UTC</li> <li>content - content of the user intended message as a string.</li> <li>The <code>~l10n</code> block SHOULD be used, but only the <code>locale</code> presented.</li> </ul> <p>Example:</p> <pre><code>{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/basicmessage/1.0/message\",\n    \"~l10n\": { \"locale\": \"en\" },\n    \"sent_time\": \"2019-01-15 18:42:01Z\",\n    \"content\": \"Your hovercraft is full of eels.\"\n}\n</code></pre>"},{"location":"aip2/0095-basic-message/#drawbacks","title":"Drawbacks","text":"<ul> <li>Creating this basicmessage may inhibit the creation of more advanced user messaging protocols.</li> <li>After more advanced user messaging protocols are created, the need to support this protocol may be annoying.</li> </ul>"},{"location":"aip2/0095-basic-message/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Basic user messaging creates an easy useful feature in the early days of agent messaging.</li> <li>Even in the presence of better protocols, it can still be useful for basic devices or service messaging.</li> </ul>"},{"location":"aip2/0095-basic-message/#prior-art","title":"Prior art","text":"<p>BasicMessage has parallels to SMS, which led to the later creation of MMS and even the still-under-development RCS.</p>"},{"location":"aip2/0095-basic-message/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Receive receipts (NOT read receipts) may be implicitly supported by an ack decorator with pre-processing support.</li> </ul>"},{"location":"aip2/0095-basic-message/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community; MISSING test results Aries Framework - .NET .NET framework for building agents of all types; MISSING test results Streetcred.id Commercial mobile and web app built using Aries Framework - .NET; MISSING test results Aries Cloud Agent - Python Contributed by the government of British Columbia.; MISSING test results Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases.; MISSING test results Aries Protocol Test Suite ; MISSING test results"},{"location":"aip2/0183-revocation-notification/","title":"Aries RFC 0183: Revocation Notification 1.0","text":"<ul> <li>Authors: [Keith Smith]</li> <li>Status: PROPOSED</li> <li>Since: 2019-08-12</li> <li>Status Note: Initial proposal after discussion on rocketchat</li> <li>Supersedes:</li> <li>Start Date: 2018-08-12</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"aip2/0183-revocation-notification/#summary","title":"Summary","text":"<p>This RFC defines the message format which an issuer uses to notify a holder that a previously issued credential has been revoked.</p>"},{"location":"aip2/0183-revocation-notification/#motivation","title":"Motivation","text":"<p>We need a standard protocol for an issuer to notify a holder that a previously issued credential has been revoked.</p> <p>For example, suppose a passport agency revokes Alice's passport. The passport agency (an issuer) may want to notify Alice (a holder) that her passport has been revoked so that she knows that she will be unable to use her passport to travel.</p>"},{"location":"aip2/0183-revocation-notification/#tutorial","title":"Tutorial","text":"<p>The Revocation Notification protocol is a very simple protocol consisting of a single message:</p> <ul> <li>Revoke - issuer to holder</li> </ul> <p>This simple protocol allows an issuer to choose to notify a holder that a previously issued credential has been revoked.</p> <p>It is the issuer's prerogative whether or not to notify the holder that a credential has been revoked.  It is not a security risk if the issuer does not notify the holder that the credential has been revoked, nor if the message is lost.  The holder will still be unable to use a revoked credential without this notification.</p>"},{"location":"aip2/0183-revocation-notification/#roles","title":"Roles","text":"<p>There are two parties involved in a Revocation Notification: <code>issuer</code> and <code>holder</code>. The <code>issuer</code> sends the <code>revoke</code> message to the <code>holder</code>.</p>"},{"location":"aip2/0183-revocation-notification/#messages","title":"Messages","text":"<p>The <code>revoke</code> message sent by the <code>issuer</code> to the <code>holder</code> is as follows:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/revocation_notification/1.0/revoke\",\n  \"@id\": \"&lt;uuid-revocation-notification&gt;\",\n  \"~please_ack\": [\"RECEIPT\",\"OUTCOME\"],\n  \"thread_id\": \"&lt;thread_id&gt;\",\n  \"comment\": \"Some comment\"\n}\n</code></pre> <p>Description of fields:</p> <ul> <li> <p><code>~please_ack</code> (optional) -- as described by the Please ACK Decorator RFC.  If <code>OUTCOME</code> is specified, the <code>holder</code> should send an ack when the holder's agent has successfully notified the holder of the revocation.</p> </li> <li> <p><code>thread_id</code> (required) -- the thread ID of the issue-credential-v2 protocol which was used to issue one or more credentials that have been revoked by the issuer.  If multiple credentials were issued, each credential has a different credential format but contains the same claims as described here; therefore, this message notifies the holder that all of these credentials have been revoked.</p> </li> <li> <p><code>comment</code> (optional) -- a field that provides some human readable information about the revocation notification.  This is typically the reason for the revocation as deemed appropriate by the issuer.</p> </li> </ul>"},{"location":"aip2/0183-revocation-notification/#reference","title":"Reference","text":"<ul> <li>See the issue-credential-v2 protocol.</li> <li>See the thread ID description.</li> <li>See the Please ACK Decorator RFC.</li> </ul>"},{"location":"aip2/0183-revocation-notification/#drawbacks","title":"Drawbacks","text":"<p>If we later added support for more general event subscription and notification message flows, this would be redundant.</p>"},{"location":"aip2/0183-revocation-notification/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?  It is simple.</li> <li>What other designs have been considered and what is the rationale for not choosing them?  A more general event subscription and notification mechanism was considered but chose to keep this simple for the same reasons that the basic message was kept simple.</li> <li>What is the impact of not doing this?  There is no standard way of sending a revocation notification which is a common scenario.</li> </ul>"},{"location":"aip2/0183-revocation-notification/#prior-art","title":"Prior art","text":""},{"location":"aip2/0183-revocation-notification/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"aip2/0183-revocation-notification/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0211-route-coordination/","title":"0211: Mediator Coordination Protocol","text":"<ul> <li>Authors: Sam Curren, Daniel Bluhm, Adam Burdett</li> <li>Status: ACCEPTED</li> <li>Since: 2021-03-15</li> <li>Status Note: Discussed and implemented and part of AIP 2.0.</li> <li>Start Date: 2019-09-03</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"aip2/0211-route-coordination/#summary","title":"Summary","text":"<p>A protocol to coordinate mediation configuration between a mediating agent and the recipient.</p>"},{"location":"aip2/0211-route-coordination/#application-scope","title":"Application Scope","text":"<p>This protocol is needed when using an edge agent and a mediator agent from different vendors. Edge agents and mediator agents from the same vendor may use whatever protocol they wish without sacrificing interoperability.</p>"},{"location":"aip2/0211-route-coordination/#motivation","title":"Motivation","text":"<p>Use of the forward message in the Routing Protocol requires an exchange of information. The Recipient must know which endpoint and routing key(s) to share, and the Mediator needs to know which keys should be routed via this relationship.</p>"},{"location":"aip2/0211-route-coordination/#protocol","title":"Protocol","text":"<p>Name: coordinate-mediation</p> <p>Version: 1.0</p> <p>Base URI: <code>https://didcomm.org/coordinate-mediation/1.0/</code></p>"},{"location":"aip2/0211-route-coordination/#roles","title":"Roles","text":"<p>mediator - The agent that will be receiving <code>forward</code> messages on behalf of the recipient. recipient - The agent for whom the <code>forward</code> message payload is intended.</p>"},{"location":"aip2/0211-route-coordination/#flow","title":"Flow","text":"<p>A recipient may discover an agent capable of routing using the Feature Discovery Protocol. If protocol is supported with the mediator role, a recipient may send a <code>mediate-request</code> to initiate a routing relationship.</p> <p>First, the recipient sends a <code>mediate-request</code> message to the mediator. If the mediator is willing to route messages, it will respond with a <code>mediate-grant</code> message. The recipient will share the routing information in the grant message with other contacts.</p> <p>When a new key is used by the recipient, it must be registered with the mediator to enable route identification. This is done with a <code>keylist-update</code> message.</p> <p>The <code>keylist-update</code> and <code>keylist-query</code> methods are used over time to identify and remove keys that are no longer in use by the recipient.</p>"},{"location":"aip2/0211-route-coordination/#reference","title":"Reference","text":"<p>Note on terms: Early versions of this protocol included the concept of terms for mediation.  This concept has been removed from this version due to a need for further discussion on representing terms in DIDComm in general and lack of use of these terms in current implementations.</p>"},{"location":"aip2/0211-route-coordination/#mediation-request","title":"Mediation Request","text":"<p>This message serves as a request from the recipient to the mediator, asking for the permission (and routing information) to publish the endpoint as a mediator.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/mediate-request\",\n}\n</code></pre>"},{"location":"aip2/0211-route-coordination/#mediation-deny","title":"Mediation Deny","text":"<p>This message serves as notification of the mediator denying the recipient's request for mediation.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/mediate-deny\",\n}\n</code></pre>"},{"location":"aip2/0211-route-coordination/#mediation-grant","title":"Mediation Grant","text":"<p>A route grant message is a signal from the mediator to the recipient that permission is given to distribute the included information as an inbound route.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/mediate-grant\",\n    \"endpoint\": \"http://mediators-r-us.com\",\n    \"routing_keys\": [\"did:key:z6Mkfriq1MqLBoPWecGoDLjguo1sB9brj6wT3qZ5BxkKpuP6\"]\n}\n</code></pre> <p><code>endpoint</code>: The endpoint reported to mediation client connections.</p> <p><code>routing_keys</code>: List of keys in intended routing order. Key used as recipient of forward messages.</p>"},{"location":"aip2/0211-route-coordination/#keylist-update","title":"Keylist Update","text":"<p>Used to notify the mediator of keys in use by the recipient.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/keylist-update\",\n    \"updates\":[\n        {\n            \"recipient_key\": \"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\",\n            \"action\": \"add\"\n        }\n    ]\n}\n</code></pre> <p><code>recipient_key</code>: Key subject of the update.</p> <p><code>action</code>: One of <code>add</code> or <code>remove</code>.</p>"},{"location":"aip2/0211-route-coordination/#keylist-update-response","title":"Keylist Update Response","text":"<p>Confirmation of requested keylist updates.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/keylist-update-response\",\n    \"updated\": [\n        {\n            \"recipient_key\": \"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\",\n            \"action\": \"\" // \"add\" or \"remove\"\n            \"result\": \"\" // [client_error | server_error | no_change | success]\n        }\n    ]\n}\n</code></pre> <p><code>recipient_key</code>: Key subject of the update.</p> <p><code>action</code>: One of <code>add</code> or <code>remove</code>.</p> <p><code>result</code>: One of <code>client_error</code>, <code>server_error</code>, <code>no_change</code>, <code>success</code>; describes the resulting state of the keylist update.</p>"},{"location":"aip2/0211-route-coordination/#key-list-query","title":"Key List Query","text":"<p>Query mediator for a list of keys registered for this connection.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/keylist-query\",\n    \"paginate\": {\n        \"limit\": 30,\n        \"offset\": 0\n    }\n}\n</code></pre> <p><code>paginate</code> is optional.</p>"},{"location":"aip2/0211-route-coordination/#key-list","title":"Key List","text":"<p>Response to key list query, containing retrieved keys.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/keylist\",\n    \"keys\": [\n        {\n            \"recipient_key\": \"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"\n        }\n    ],\n    \"pagination\": {\n        \"count\": 30,\n        \"offset\": 30,\n        \"remaining\": 100\n    }\n}\n</code></pre> <p><code>pagination</code> is optional.</p>"},{"location":"aip2/0211-route-coordination/#encoding-of-keys","title":"Encoding of keys","text":"<p>All keys are encoded using the <code>did:key</code> method as per RFC0360.</p>"},{"location":"aip2/0211-route-coordination/#prior-art","title":"Prior art","text":"<p>There was an Indy HIPE that never made it past the PR process that described a similar approach. That HIPE led to a partial implementation of this inside the Aries Cloud Agent Python</p>"},{"location":"aip2/0211-route-coordination/#future-considerations","title":"Future Considerations","text":"<ul> <li>Should we allow listing keys by date? You could query keys in use by date?</li> <li>We are missing a way to check a single key (or a few keys) without doing a full list.</li> <li>Mediation grant supports only one endpoint. What can be done to support multiple endpoint options i.e. http, ws, etc.</li> <li>Requiring proof of key ownership (with a signature) would prevent an edge case where a malicious party registers a key for another party at the same mediator, and before the other party.</li> <li>How do we express terms and conditions for mediation?</li> </ul>"},{"location":"aip2/0211-route-coordination/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>None</li> </ul>"},{"location":"aip2/0211-route-coordination/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python Added in ACA-Py 0.6.0 MISSING test results**** DIDComm mediator Open source cloud-based mediator."},{"location":"aip2/0360-use-did-key/","title":"Aries RFC 0360: did:key Usage","text":"<ul> <li>Authors: Tobias Looker, Stephen Curran</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Referenced in a number of Aries RFCs and formalized as part of AIP 2.0 did:key method is a W3C CCG work item</li> <li>Start Date: 2019-12-17</li> <li>Tags: feature</li> </ul>"},{"location":"aip2/0360-use-did-key/#summary","title":"Summary","text":"<p>A number of RFCs that have been defined reference what amounts to a \"naked\" public key, such that the sender relies on the receiver knowing what type the key is and how it can be used. The application of this RFC will result in the replacement of \"naked\" verkeys (public keys) in some DIDComm/Aries protocols with the did:key ledgerless DID method, a format that concisely conveys useful information about the use of the key, including the public key type. While <code>did:key</code> is less a DID method than a transformation from a public key and type to an opinionated DIDDoc, it provides a versioning mechanism for supporting new/different cryptographic formats and its use makes clear how a public key is intended to be used. The method also enables support for using standard DID resolution mechanisms that may simplify the use of the key. The use of a DID to represent a public key is seen as odd by some in the community. Should a representation be found that is has better properties than a plain public key but is constrained to being \"just a key\", then we will consider changing from the <code>did:key</code> representation.</p> <p>To Do: Update link DID Key Method link (above) from Digital Bazaar to W3C repositories when they are created and populated.</p> <p>While it is well known in the Aries community that <code>did:key</code> is fundamentally different from the did:peer method that is the basis of Aries protocols, it must be re-emphasized here. This RFC does NOT imply any changes to the use of <code>did:peer</code> in Aries, nor does it change the content of a <code>did:peer</code> DIDDoc. This RFC only changes references to plain public keys in the JSON of some RFCs to use <code>did:key</code> in place of a plain text string.</p> <p>Should this RFC be ACCEPTED, a community coordinated update will be used to apply updates to the agent code bases and impacted RFCs.</p>"},{"location":"aip2/0360-use-did-key/#motivation","title":"Motivation","text":"<p>When one Aries agent inserts a public key into the JSON of an Aries message (for example, the <code>~service</code> decorator), it assumes that the recipient agent will use the key in the intended way. At the time this RFC is being written, this is easy because only one key type is in use by all agents. However, in order to enable the use of different cryptography algorithms, the public references must be extended to at least include the key type. The preferred and concise way to do that is the use of the multicodec mechanism, which provides a registry of encodings for known key types that are prefixed to the public key in a standard and concise way. did:key extends that mechanism by providing a templated way to transform the combination of public key and key type into a DID-standard DIDDoc.</p> <p>At the cost of adding/building a did:key resolver we get a DID standard way to access the key and key type, including specific information on how the key can be used. The resolver may be trivial or complex. In a trivial version, the key type is assumed, and the key can be easily extracted from the string. In a more complete implementation, the key type can be checked, and standard DID URL handling can be used to extract parts of the DIDDoc for specific purposes. For example, in the ed25519 <code>did:key</code> DIDDoc, the existence of the <code>keyAgreement</code> entry implies that the key can be used in a Diffie-Hellman exchange, without the developer guessing, or using the key incorrectly.</p> <p>Note that simply knowing the key type is not necessarily sufficient to be able to use the key. The cryptography supporting the processing data using the key must also be available in the agent. However, the multicodec and did:key capabilities will simplify adding support for new key types in the future.</p>"},{"location":"aip2/0360-use-did-key/#tutorial","title":"Tutorial","text":"<p>An example of the use of the replacement of a verkey with <code>did:key</code> can be found in the ~service decorator RFC. Notably in the example at the beginning of the tutorial section, the verkeys in the <code>recipientKeys</code> and <code>routingKeys</code> items would be changed from native keys to use <code>did:key</code> as follows:</p> <pre><code>{\n    \"@type\": \"somemessagetype\",\n    \"~service\": {\n        \"recipientKeys\": [\"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"],\n        \"routingKeys\": [\"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"]\n        \"serviceEndpoint\": \"https://example.com/endpoint\"\n    }\n}\n</code></pre> <p>Thus, <code>8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K</code> becomes <code>did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th</code> using the following transformations:</p> <ul> <li>Start with the original (presumably) base58 ed25519 public key</li> <li>Since we have only a naked public key, we must assume the format</li> <li>Base58 decode the public key to get the hex version</li> <li>Multicodec: Prefix with the unsigned varint of the algorithm type. In this case, that means prefixing the string with <code>unsigned_varint(0xed)</code> (which is <code>0xed 0x01</code>) for the key type of ed25519,</li> <li>the <code>0xed</code> is per the multicodec table (search for  <code>ed25519</code>).</li> <li>Note that unsigned varint handling varies by key type prefix, so don't just assume the same handling (e.g. <code>code+0x01</code>) for other key type prefixes. For a broader discussion of this see this issue comment in the <code>did:key</code> repo.</li> <li>Multibase: Base58 encode the result and prefix that with \"z\" to indicate base58 encoding</li> <li>DID: Prefix that with the DID Method prefix <code>did:key:</code></li> </ul> <p>The transformation above is only for illustration within this RFC. The <code>did:key</code> specification is the definitive source for the appropriate transformations.</p> <p>The <code>did:key</code> method uses the strings that are the DID, public key and key type to construct (\"resolve\") a DIDDoc based on a template defined by the <code>did:key</code> specification. Further, the <code>did:key</code> resolver generates, in the case of an ed25519 public signing key, a key that can be used as part of a Diffie-Hellman exchange appropriate for encryption in the <code>keyAgreement</code> section of the DIDDoc. Presumably, as the <code>did:key</code> method supports other key types, similar DIDDoc templates will become part of the specification. Key types that don't support a signing/key exchange transformation would not have a <code>keyAgreement</code> entry in the resolved DIDDoc.</p> <p>The following currently implemented RFCs would be affected by acceptance of this RFC. In these RFCs, the JSON items that currently contain naked public keys (mostly the items <code>recipientKeys</code> and <code>routingKeys</code>) would be changed to use <code>did:key</code> references where applicable. Note that in these items public DIDs could also be used if applicable for a given use case.</p> <ul> <li>0023-did-exchange - Invitation Message</li> <li>0028-introduce</li> <li>0056-service-decorator</li> <li>0160-connection-protocol</li> <li>0434-out-of-band-protocols</li> <li>0211-mediator-coordination-protocol</li> </ul> <p>Service entries in <code>did:peer</code> DIDDocs (such as in RFCs 0094-cross-domain-messaging and 0067-didcomm-diddoc-conventions) should NOT use a <code>did:key</code> public key representation. Instead, service entries in the DIDDoc should reference keys defined internally in the DIDDoc where appropriate.</p> <p>To Do: Discuss the use of <code>did:key</code> (or not) in the context of encryption envelopes. This will be part of the ongoing discussion about JWEs and the upcoming discussions about JWMs\u2014a soon-to-be-proposed specification. That conversation will likely go on in the DIF DIDComm Working Group.</p>"},{"location":"aip2/0360-use-did-key/#reference","title":"Reference","text":"<p>See the <code>did:key</code> specification. Note that the specification is still evolving.</p>"},{"location":"aip2/0360-use-did-key/#drawbacks","title":"Drawbacks","text":"<p>The <code>did:key</code> standard is not finalized.</p> <p>The DIDDoc \"resolved\" from a <code>did:key</code> probably has more entries in it than are needed for DIDComm. That said, the entries in the DIDDoc make it clear to a developer how they can use the public key.</p>"},{"location":"aip2/0360-use-did-key/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>We should not stick with the status quo and assume that all agents will always know the type of keys being used and how to use them.</p> <p>We should at minimum move to a scheme like multicodecs such that the key is self documenting and supports the versioning of cryptographic algorithms. However, even if we do that, we still have to document for developers how they should (and not should not) use the public key.</p> <p>Another logical alternative is to use a JWK. However, that representation only adds the type of the key (same as multicodecs) at the cost of being significantly more verbose.</p>"},{"location":"aip2/0360-use-did-key/#prior-art","title":"Prior art","text":"<p>To do - there are other instances of this pattern being used. Insert those here.</p>"},{"location":"aip2/0360-use-did-key/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>How to transition to the use of <code>did:key</code>.</li> <li>What will the initial accepted version of <code>did:key</code> look like?  It's probably close to its final form, with an expected resolution of the open question of what  a DIDDoc looks like if the key type is not ed25519.</li> </ul>"},{"location":"aip2/0360-use-did-key/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes</p> Name / Link Implementation Notes"},{"location":"aip2/0434-outofband/","title":"Aries RFC 0434: Out-of-Band Protocol 1.1","text":"<ul> <li>Authors: Ryan West, Daniel Bluhm, Matthew Hailstone, Stephen Curran, Sam Curren, George Aristy</li> <li>Status: ADOPTED</li> <li>Since: 2020-03-01</li> <li>Status Note: This RFC extracts the <code>invitation</code> messages from the DID Exchange protocol (and perhaps Connection), and replaces the combined <code>present_proof/1.0/request</code> combined with the <code>~service</code> decorator to define an ephemeral (connection-less) challenge.</li> <li>Supersedes: Invitation Message in 0160-Connections and Invitation Message in 0023-DID-Exchange.</li> <li>Start Date: 2020-03-01</li> <li>Tags: feature, protocol, test-anomaly</li> <li>URI: <code>https://didcomm.org/out-of-band/%VER</code></li> </ul>"},{"location":"aip2/0434-outofband/#summary","title":"Summary","text":"<p>The Out-of-band protocol is used when you wish to engage with another agent and you don't have a DIDComm connection to use for the interaction.</p>"},{"location":"aip2/0434-outofband/#motivation","title":"Motivation","text":"<p>The use of the <code>invitation</code> in the Connection and DID Exchange protocols has been relatively successful, but has some shortcomings, as follows.</p>"},{"location":"aip2/0434-outofband/#connection-reuse","title":"Connection Reuse","text":"<p>A common pattern we have seen in the early days of Aries agents is a user with a browser getting to a point where a connection is needed between the website's (enterprise) agent and the user's mobile agent. A QR invitation is displayed, scanned and a protocol is executed to establish a connection. Life is good!</p> <p>However, with the current invitation processes, when the same user returns to the same page, the same process is executed (QR code, scan, etc.) and a new connection is created between the two agents. There is no way for the user's agent to say \"Hey, I've already got a connection with you. Let's use that one!\"</p> <p>We need the ability to reuse a connection.</p>"},{"location":"aip2/0434-outofband/#connection-establishment-versioning","title":"Connection Establishment Versioning","text":"<p>In the existing Connections and DID Exchange <code>invitation</code> handling, the inviter dictates what connection establishment protocol all invitee's will use. A more sustainable approach is for the inviter to offer the invitee a list of supported protocols and allow the invitee to use one that it supports.</p>"},{"location":"aip2/0434-outofband/#handling-of-all-out-of-band-messages","title":"Handling of all Out-of-Band Messages","text":"<p>We currently have two sets of out-of-band messages that cannot be delivered via DIDComm because there is no channel. We'd like to align those messages into a single \"out-of-band\" protocol so that their handling can be harmonized inside an agent, and a common QR code handling mechanism can be used.</p>"},{"location":"aip2/0434-outofband/#urls-and-qr-code-handling","title":"URLs and QR Code Handling","text":"<p>We'd like to have the specification of QR handling harmonized into a single RFC (this one).</p>"},{"location":"aip2/0434-outofband/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0434-outofband/#key-concepts","title":"Key Concepts","text":"<p>The Out-of-band protocol is used when an agent doesn't know if it has a connection with another agent. This could be because you are trying to establish a new connection with that agent, you have connections but don't know who the other party is, or if you want to have a connection-less interaction. Since there is no DIDComm connection to use for the messages of this protocol, the messages are plaintext and sent out-of-band, such as via a QR code, in an email message or any other available channel. Since the delivery of out-of-band messages will often be via QR codes, this RFC also covers the use of QR codes.</p> <p>Two well known use cases for using an out-of-band protocol are:</p> <ul> <li>A user on a web browser wants to execute a protocol (for example, to issue a verifiable credential) between the website operator's agent and a user's agent. To enable the execution of the protocol, the two agents must first have a connection. An out-of-band message is used to trigger the creation of a new, or the reuse an existing, connection.</li> <li>A website operator wants to request something from a user on their site where there is no (known) connection with the user's agent, and there is no need to create a connection.</li> </ul> <p>In both cases, there is only a single out-of-band protocol message sent. The message responding to the out-of-band message is a DIDComm message from an appropriate protocol.</p> <p>Note that the website-to-agent model is not the only such interaction enabled by the out-of-band protocol, and a QR code is not the only delivery mechanism for out-of-band messages. However, they are useful as examples of the purpose of the protocol.</p>"},{"location":"aip2/0434-outofband/#roles","title":"Roles","text":"<p>The out-of-band protocol has two roles: sender and receiver.</p>"},{"location":"aip2/0434-outofband/#sender","title":"sender","text":"<p>The agent that generates the out-of-band message and makes it available to the other party.</p>"},{"location":"aip2/0434-outofband/#receiver","title":"receiver","text":"<p>The agent that receives the out-of-band message and decides how to respond. There is no out-of-band protocol message with which the receiver will respond. Rather, if they respond, they will use a message from another protocol that the sender understands.</p>"},{"location":"aip2/0434-outofband/#states","title":"States","text":"<p>The state machines for the sender and receiver are a bit odd for the out-of-band protocol because it consists of a single message that kicks off a co-protocol and ends when evidence of the co-protocol's launch is received, in the form of some response. In the following state machine diagrams we generically describe the response message from the receiver as being a DIDComm message.</p> <p>The sender state machine is as follows:</p> <p></p> <p>Note the \"optional\" reference under the second event in the <code>await-response</code> state. That is to indicate that an out-of-band message might be a single use message with a transition to done, or reusable message (received by many receivers) with a transition back to <code>await-response</code>.</p> <p>The receiver state machine is as follows:</p> <p></p> <p>Worth noting is the first event of the <code>done</code> state, where the receiver may receive the message multiple times. This represents, for example, an agent returning to the same website and being greeted with instances of the same QR code each time.</p>"},{"location":"aip2/0434-outofband/#messages","title":"Messages","text":"<p>The out-of-band protocol a single message that is sent by the sender.</p>"},{"location":"aip2/0434-outofband/#invitation-httpsdidcommorgout-of-bandverinvitation","title":"Invitation: <code>https://didcomm.org/out-of-band/%VER/invitation</code>","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/invitation\",\n  \"@id\": \"&lt;id used for context as pthid&gt;\",\n  \"label\": \"Faber College\",\n  \"goal_code\": \"issue-vc\",\n  \"goal\": \"To issue a Faber College Graduate credential\",\n  \"accept\": [\n    \"didcomm/aip2;env=rfc587\",\n    \"didcomm/aip2;env=rfc19\"\n  ],\n  \"handshake_protocols\": [\n    \"https://didcomm.org/didexchange/1.0\",\n    \"https://didcomm.org/connections/1.0\"\n  ],\n  \"requests~attach\": [\n    {\n      \"@id\": \"request-0\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"json\": \"&lt;json of protocol message&gt;\"\n      }\n    }\n  ],\n  \"services\": [\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]\n}\n</code></pre> <p>The items in the message are:</p> <ul> <li><code>@type</code> - the DIDComm message type</li> <li><code>@id</code> - the unique ID of the message. The ID should be used as the parent thread ID (<code>pthid</code>) for the response message, rather than the more common thread ID (<code>thid</code>) of the response message. This enables multiple uses of a single out-of-band message.</li> <li><code>label</code> - [optional] a self-attested string that the receiver may want to display to the user, likely about who sent the out-of-band message.</li> <li><code>goal_code</code> - [optional] a self-attested code the receiver may want to display to the user or use in automatically deciding what to do with the out-of-band message.</li> <li><code>goal</code> - [optional] a self-attested string that the receiver may want to display to the user about the context-specific goal of the out-of-band message.</li> <li><code>accept</code> - [optional] an array of media (aka mime) types in the order of preference of the sender that the receiver can use in responding to the message. If <code>accept</code> is not specified, the receiver uses its preferred choice to respond to the message. RFC 0044 provides a general discussion of media types.</li> <li><code>handshake_protocols</code> - [optional] an array of protocols in the order of preference of the sender that the receiver can use in responding to the message in order to create or reuse a connection with the sender. These are not arbitrary protocols but rather protocols that result in the establishment of a connection. One or both of <code>handshake_protocols</code> and <code>requests~attach</code> MUST be included in the message.</li> <li><code>requests~attach</code> - [optional] an attachment decorator containing an array of request messages in order of preference that the receiver can using in responding to the message. One or both of <code>handshake_protocols</code> and <code>requests~attach</code> MUST be included in the message.</li> <li>While the JSON form of the attachment is used in the example above, the sender could choose to use the base64 form.</li> <li><code>services</code> - an array of union types that the receiver uses when responding to the message. Each item is either a DIDComm <code>service</code> object (as per RFC0067) or a DID (as per Decentralized Identifiers v1.0). Additional details below.</li> </ul> <p>If only the <code>handshake_protocols</code> item is included, the initial interaction will complete with the establishment (or reuse) of the connection. Either side may then use that connection for any purpose. A common use case (but not required) would be for the sender to initiate another protocol after the connection is established to accomplish some shared goal.</p> <p>If only the <code>requests~attach</code> item is included, no new connection is expected to be created, although one could be used if the receiver knows such a connection already exists. The receiver responds to one of the messages in the <code>requests~attach</code> array. The <code>requests~attach</code> item might include the first message of a protocol from the sender, or might be a please-play-the-role message requesting the receiver initiate a protocol. If the protocol requires a further response from the sender to the receiver, the receiver must include a <code>~service</code> decorator for the sender to use in responding.</p> <p>If both the <code>handshake_protocols</code> and <code>requests~attach</code> items are included in the message, the receiver should first establish a connection and then respond (using that connection) to one of the messages in the <code>requests~attach</code> message. If a connection already exists between the parties, the receiver may respond immediately to the <code>request-attach</code> message using the established connection.</p>"},{"location":"aip2/0434-outofband/#reuse-messages","title":"Reuse Messages","text":"<p>While the receiver is expected to respond with an initiating message from a <code>handshake_protocols</code> or <code>requests~attach</code> item using an offered service, the receiver may be able to respond by reusing an existing connection. Specifically, if a connection they have was created from an out-of-band <code>invitation</code> from the same <code>services</code> DID of a new <code>invitation</code> message, the connection MAY be reused. The receiver may choose to not reuse the existing connection for privacy purposes and repeat a handshake protocol to receive a redundant connection. </p> <p>If a message has a service block instead of a DID in the <code>services</code> list, you may enable reuse by encoding the key and endpoint of the service block in a Peer DID numalgo 2 and using that DID instead of a service block.</p> <p>If the receiver desires to reuse the existing connection and a <code>requests~attach</code> item is included in the message, the receiver SHOULD respond to one of the attached messages using the existing connection.</p> <p>If the receiver desires to reuse the existing connection and no <code>requests~attach</code> item is included in the message, the receiver SHOULD attempt to do so with the <code>reuse</code> and <code>reuse-accepted</code> messages. This will notify the inviter that the existing connection should be used, along with the context that can be used for follow-on interactions.</p> <p>While the <code>invitation</code> message is passed unencrypted and out-of-band, both the <code>handshake-reuse</code> and <code>handshake-reuse-accepted</code> messages MUST be encrypted and transmitted as normal DIDComm messages.</p>"},{"location":"aip2/0434-outofband/#reuse-httpsdidcommorgout-of-bandverhandshake-reuse","title":"Reuse: <code>https://didcomm.org/out-of-band/%VER/handshake-reuse</code>","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/handshake-reuse\",\n  \"@id\": \"&lt;id&gt;\",\n  \"~thread\": {\n    \"thid\": \"&lt;same as @id&gt;\",\n    \"pthid\": \"&lt;The @id of the Out-of-Band invitation&gt;\"\n  }\n}\n</code></pre> <p>The items in the message are:</p> <ul> <li><code>@type</code> - the DIDComm message type</li> <li><code>@id</code> - the unique ID of the message. </li> <li><code>pthid</code> - the @id of the invitation message. This provides the context link for the inviter to prompt additional protocol interactions.</li> </ul> <p>Sending or receiving this message does not change the state of the existing connection.</p> <p>When the inviter receives the <code>handshake-reuse</code> message, they MUST respond with a <code>handshake-reuse-accepted</code> message to notify that invitee that the request to reuse the existing connection is successful.</p>"},{"location":"aip2/0434-outofband/#reuse-accepted-httpsdidcommorgout-of-bandverhandshake-reuse-accepted","title":"Reuse Accepted:  <code>https://didcomm.org/out-of-band/%VER/handshake-reuse-accepted</code>","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/handshake-reuse-accepted\",\n  \"@id\": \"&lt;id&gt;\",\n  \"~thread\": {\n    \"thid\": \"&lt;The Message @id of the reuse message&gt;\",\n    \"pthid\": \"&lt;The @id of the Out-of-Band invitation&gt;\"\n  }\n}\n</code></pre> <p>The items in the message are:</p> <ul> <li><code>@type</code> - the DIDComm message type</li> <li><code>@id</code> - the unique ID of the message. </li> <li><code>pthid</code> - the @id of the invitation message. This and the <code>thid</code> provides context for the invitee to know the reuse attempt succeeded.</li> </ul> <p>If this message is not received by the invitee, they should use the regular process. This message is a mechanism by which the invitee can detect a situation where the inviter no longer has a record of the connection and is unable to decrypt and process the <code>handshake-reuse</code> message.</p> <p>After sending this message, the inviter may continue any desired protocol interactions based on the context matched by the <code>pthid</code> present in the <code>handshake-reuse</code> message.</p>"},{"location":"aip2/0434-outofband/#responses","title":"Responses","text":"<p>The following table summarizes the different forms of the out-of-band <code>invitation</code> message depending on the presence (or not) of the <code>handshake_protocols</code> item, the <code>requests~attach</code> item and whether or not a connection between the agents already exists.</p> <code>handshake_protocols</code> Present? <code>requests~attach</code> Present? Existing connection? Receiver action(s) No No No Impossible Yes No No Uses the first supported protocol from <code>handshake_protocols</code> to make a new connection using the first supported <code>services</code> entry. No Yes No Send a response to the first supported request message using the first supported <code>services</code> entry. Include a <code>~service</code> decorator if the sender is expected to respond. No No Yes Impossible Yes Yes No Use the first supported protocol from <code>handshake_protocols</code> to make a new connection using the first supported <code>services</code> entry, and then send a response message to the first supported attachment message using the new connection. Yes No Yes Send a <code>handshake-reuse</code> message. No Yes Yes Send a response message to the first supported request message using the existing connection. Yes Yes Yes Send a response message to the first supported request message using the existing connection. <p>Both the <code>goal_code</code> and <code>goal</code> fields SHOULD be used with the localization service decorator. The two fields are to enable both human and machine handling of the out-of-band message. <code>goal_code</code> is to specify a generic, protocol level outcome for sending the out-of-band message (e.g. issue verifiable credential, request proof, etc.) that is suitable for machine handling and possibly human display, while <code>goal</code> provides context specific guidance, targeting mainly a person controlling the receiver's agent. The list of <code>goal_code</code> values is provided in the Message Catalog section of this RFC.</p>"},{"location":"aip2/0434-outofband/#the-services-item","title":"The <code>services</code> Item","text":"<p>As mentioned in the description above, the <code>services</code> item array is intended to be analogous to the <code>service</code> block of a DIDDoc. When not reusing an existing connection, the receiver scans the array and selects (according to the rules described below) a service entry to use for the response to the out-of-band message.</p> <p>There are two forms of entries in the <code>services</code> item array:</p> <ul> <li>a DID that is resolved to retrieve it's DIDDoc service block, and</li> <li>an inline service block.</li> </ul> <p>The following is an example of a two entry array, one of each form:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/invitation\",\n  \"@id\": \"&lt;id used for context as pthid&gt;\",\n  \"label\": \"Faber College\",\n  \"handshake_protocols\": [\"https://didcomm.org/didexchange/1.0\"],\n  \"services\": [\n    {\n      \"id\": \"#inline\",\n      \"type\": \"did-communication\",\n      \"recipientKeys\": [\"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"],\n      \"routingKeys\": [],\n      \"serviceEndpoint\": \"https://example.com:5000\"\n    },\n    \"did:sov:LjgpST2rjsoxYegQDRm7EL\"\n  ]\n}\n</code></pre> <p>The processing rules for the <code>services</code> block are:</p> <ul> <li>Use only entries where the <code>type</code> is equal to <code>did-communication</code>.</li> <li>Entries without a <code>type</code> are assumed to be <code>did-communication</code>.</li> <li>The sender MUST put the array into their order of preference, and, as such, the receiver SHOULD prefer the entries in order.</li> </ul> <p>The attributes in the inline form parallel the attributes of a DID Document for increased meaning. The <code>recipientKeys</code> and <code>routingKeys</code> within the inline block decorator MUST be <code>did:key</code> references.</p> <p>As defined in the DIDComm Cross Domain Messaging RFC, if <code>routingKeys</code> is present and non-empty, additional forwarding wrapping are necessary in the response message.</p> <p>When considering routing and options for out-of-band messages, keep in mind that the more detail in the message, the longer the URL will be and (if used) the more dense (and harder to scan) the QR code will be.</p>"},{"location":"aip2/0434-outofband/#service-endpoint","title":"Service Endpoint","text":"<p>The service endpoint used to transmit the response is either present in the out-of-band message or available in the DID Document of a presented DID. If the endpoint is itself a DID, the <code>serviceEndpoint</code> in the DIDDoc of the resolved DID MUST be a URI, and the <code>recipientKeys</code> MUST contain a single key. That key is appended to the end of the list of <code>routingKeys</code> for processing. For more information about message forwarding and routing, see RFC 0094 Cross Domain Messaging.</p>"},{"location":"aip2/0434-outofband/#adoption-messages","title":"Adoption Messages","text":"<p>The <code>problem_report</code> message MAY be adopted by the out-of-band protocol if the agent wants to respond with problem reports to invalid messages, such as attempting to reuse a single-use invitation.</p>"},{"location":"aip2/0434-outofband/#constraints","title":"Constraints","text":"<p>An existing connection can only be reused based on a DID in the <code>services</code> list in an out-of-band message.</p>"},{"location":"aip2/0434-outofband/#reference","title":"Reference","text":""},{"location":"aip2/0434-outofband/#messages-reference","title":"Messages Reference","text":"<p>The full description of the message in this protocol can be found in the Tutorial section of this RFC.</p>"},{"location":"aip2/0434-outofband/#localization","title":"Localization","text":"<p>The <code>goal_code</code> and <code>goal</code> fields SHOULD have localization applied. See the purpose of those fields in the message type definitions section and the message catalog section (immediately below).</p>"},{"location":"aip2/0434-outofband/#message-catalog","title":"Message Catalog","text":""},{"location":"aip2/0434-outofband/#goal_code","title":"<code>goal_code</code>","text":"<p>The following values are defined for the <code>goal_code</code> field:</p> Code (cd) English (en) issue-vc To issue a credential request-proof To request a proof create-account To create an account with a service p2p-messaging To establish a peer-to-peer messaging relationship"},{"location":"aip2/0434-outofband/#goal","title":"<code>goal</code>","text":"<p>The <code>goal</code> localization values are use case specific and localization is left to the agent implementor to enable using the techniques defined in the ~l10n RFC.</p>"},{"location":"aip2/0434-outofband/#roles-reference","title":"Roles Reference","text":"<p>The roles are defined in the Tutorial section of this RFC.</p>"},{"location":"aip2/0434-outofband/#states-reference","title":"States Reference","text":""},{"location":"aip2/0434-outofband/#initial","title":"initial","text":"<p>No out-of-band messages have been sent.</p>"},{"location":"aip2/0434-outofband/#await-response","title":"await-response","text":"<p>The sender has shared an out-of-band message with the intended receiver(s), and the sender has not yet received all of the responses. For a single-use out-of-band message, there will be only one response; for a multi-use out-of-band message, there is no defined limit on the number of responses.</p>"},{"location":"aip2/0434-outofband/#prepare-response","title":"prepare-response","text":"<p>The receiver has received the out-of-band message and is preparing a response. The response will not be an out-of-band protocol message, but a message from another protocol chosen based on the contents of the out-of-band message.</p>"},{"location":"aip2/0434-outofband/#done","title":"done","text":"<p>The out-of-band protocol has been completed. Note that if the out-of-band message was intended to be available to many receivers (a multiple use message), the sender returns to the await-response state rather than going to the done state.</p>"},{"location":"aip2/0434-outofband/#errors","title":"Errors","text":"<p>There is an optional courtesy error message stemming from an out-of-band message that the sender could provide if they have sufficient recipient information. If the out-of-band message is a single use message and the sender receives multiple responses and each receiver's response includes a way for the sender to respond with a DIDComm message, all but the first MAY be answered with a <code>problem_report</code>.</p>"},{"location":"aip2/0434-outofband/#error-message-example","title":"Error Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/problem_report\",\n  \"@id\": \"5678876542345\",\n  \"~thread\": { \"pthid\": \"&lt;@id of the OutofBand message&gt;\" },\n  \"description\": {\n    \"en\": \"The invitation has expired.\",\n    \"code\": \"expired-invitation\"\n  },\n  \"impact\": \"thread\"\n}\n</code></pre> <p>See the problem-report protocol for details on the items in the example.</p>"},{"location":"aip2/0434-outofband/#flow-overview","title":"Flow Overview","text":"<p>In an out-of-band message the sender gives information to the receiver about the kind of DIDComm protocol response messages it can handle and how to deliver the response. The receiver uses that information to determine what DIDComm protocol/message to use in responding to the sender, and (from the service item or an existing connection) how to deliver the response to the sender.</p> <p>The handling of the response is specified by the protocol used.</p> <p>To Do: Make sure that the following remains in the DID Exchange/Connections RFCs</p> <p>Any Published DID that expresses support for DIDComm by defining a  <code>service</code> that follows the DIDComm conventions serves as an implicit invitation. If an invitee wishes to connect to any Published DID, they need not wait for an out-of-band invitation message. Rather, they can designate their own label and initiate the appropriate protocol (e.g. 0160-Connections or 0023-DID-Exchange) for establishing a connection.</p>"},{"location":"aip2/0434-outofband/#standard-out-of-band-message-encoding","title":"Standard Out-of-Band Message Encoding","text":"<p>Using a standard out-of-band message encoding allows for easier interoperability between multiple projects and software platforms. Using a URL for that standard encoding provides a built in fallback flow for users who are unable to automatically process the message. Those new users will load the URL in a browser as a default behavior, and may be presented with instructions on how to install software capable of processing the message. Already onboarded users will be able to process the message without loading in a browser via mobile app URL capture, or via capability detection after being loaded in a browser.</p> <p>The standard out-of-band message format is a URL with a Base64Url encoded json object as a query parameter.</p> <p>Please note the difference between Base64Url and Base64 encoding.</p> <p>The URL format is as follows, with some elements described below:</p> <pre><code>https://&lt;domain&gt;/&lt;path&gt;?oob=&lt;outofbandMessage&gt;\n</code></pre> <p><code>&lt;domain&gt;</code> and <code>&lt;path&gt;</code> should be kept as short as possible, and the full URL SHOULD return human readable instructions when loaded in a browser. This is intended to aid new users. The <code>oob</code> query parameter is required and is reserved to contain the out-of-band message string. Additional path elements or query parameters are allowed, and can be leveraged to provide coupons or other promise of payment for new users.</p> <p>To do: We need to rationalize this approach <code>https://</code> approach with the use of a special protocol (e.g. <code>didcomm://</code>) that will enable handling of the URL on mobile devices to automatically invoke an installed app on both Android and iOS. A user must be able to process the out-of-band message on the device of the agent (e.g. when the mobile device can't scan the QR code because it is on a web page on device).</p> <p>The <code>&lt;outofbandMessage&gt;</code> is an agent plaintext message (not a DIDComm message) that has been Base64Url encoded such that the resulting string can be safely used in a URL.</p> <pre><code>outofband_message = base64UrlEncode(&lt;outofbandMessage&gt;)\n</code></pre> <p>During Base64Url encoding, whitespace from the JSON string SHOULD be eliminated to keep the resulting out-of-band message string as short as possible.</p>"},{"location":"aip2/0434-outofband/#example-out-of-band-message-encoding","title":"Example Out-of-Band Message Encoding","text":"<p>Invitation:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/1.0/invitation\",\n  \"@id\": \"69212a3a-d068-4f9d-a2dd-4741bca89af3\",\n  \"label\": \"Faber College\",\n  \"goal_code\": \"issue-vc\",\n  \"goal\": \"To issue a Faber College Graduate credential\",\n  \"handshake_protocols\": [\"https://didcomm.org/didexchange/1.0\", \"https://didcomm.org/connections/1.0\"],\n  \"services\": [\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]\n}\n</code></pre> <p>Whitespace removed:</p> <pre><code>{\"@type\":\"https://didcomm.org/out-of-band/1.0/invitation\",\"@id\":\"69212a3a-d068-4f9d-a2dd-4741bca89af3\",\"label\":\"Faber College\",\"goal_code\":\"issue-vc\",\"goal\":\"To issue a Faber College Graduate credential\",\"handshake_protocols\":[\"https://didcomm.org/didexchange/1.0\",\"https://didcomm.org/connections/1.0\"],\"services\":[\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]}\n</code></pre> <p>Base64Url encoded:</p> <pre><code>eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0=\n</code></pre> <p>Example URL with Base64Url encoded message:</p> <pre><code>http://example.com/ssi?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0=\n</code></pre> <p>Out-of-band message URLs can be transferred via any method that can send text, including an email, SMS, posting on a website, or QR Code.</p> <p>Example URL encoded as a QR Code:</p> <p></p> <p>Example Email Message:</p> <pre><code>To: alice@alum.faber.edu\nFrom: studentrecords@faber.edu\nSubject: Your request to connect and receive your graduate verifiable credential\n\nDear Alice,\n\nTo receive your Faber College graduation certificate, click here to [connect](http://example.com/ssi?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0=) with us, or paste the following into your browser:\n\nhttp://example.com/ssi?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0=\n\nIf you don't have an identity agent for holding credentials, you will be given instructions on how you can get one.\n\nThanks,\n\nFaber College\nKnowledge is Good\n</code></pre>"},{"location":"aip2/0434-outofband/#url-shortening","title":"URL Shortening","text":"<p>It seems inevitable that the length of some out-of-band message will be too long to produce a useable QR code. Techniques to avoid unusable QR codes have been presented above, including using attachment links for requests, minimizing the routing of the response and eliminating unnecessary whitespace in the JSON. However, at some point a sender may need generate a very long URL. In that case, a DIDComm specific URL shortener redirection should be implemented by the sender as follows:</p> <ul> <li>The sender generates a unique URL for each shortened out-of-band message.</li> <li>The unique URL often includes a unique id component as part of the path or in a query parameter.</li> <li>The following URLs are valid examples:</li> <li><code>https://example.com/ssi?id=5f0e3ffb-3f92-4648-9868-0d6f8889e6f3</code></li> <li><code>https://example.com/8E6nEcJ26TTE</code></li> <li><code>https://example.com/sky/event/8DcnUW2h8m4jcfPdQ2uMN7/work-laptop-bag/s/u</code></li> <li>On receipt of this form of message, the agent MUST perform an HTTP GET to retrieve the associated out-of-band message. The agent SHOULD include an <code>Accept</code> header requesting the <code>application/json</code> MIME type.</li> <li>The sender MAY include a <code>Content-Type</code> header specifying <code>application/json; charset=utf-8</code>, and in the case where the agent included an <code>Accept</code> header for the <code>application/json</code> MIME type, the sender MUST include the header. If so, the sender MUST return the invitation in JSON format in the response body with a <code>status_code</code> of <code>200</code>.</li> <li>The sender MAY respond with a <code>status_code</code> of <code>301</code> or <code>302</code> and include a <code>Location</code> header specifying the long out-of-band message URL.</li> <li>This redirect option operates like many commercial URL shorteners. </li> <li>The sender MUST invalidate the URL after message retrieval or after an expiration time to prevent unintended parties from retrieving a copy of the message.</li> <li>A sender MUST NOT use a commercial URL shortener unless it supports invalidating the URL.</li> </ul> <p>A usable QR code will always be able to be generated from the shortened form of the URL.</p>"},{"location":"aip2/0434-outofband/#url-shortening-caveats","title":"URL Shortening Caveats","text":"<p>Some HTTP libraries don't support stopping redirects from occuring on reception of a <code>301</code> or <code>302</code>, in this instance the redirect is automatically followed and will result in a response that MAY have a status of <code>200</code> and MAY contain a URL that can be processed as a normal <code>Out-of-Band</code> message.</p> <p>If the agent performs a HTTP GET with the <code>Accept</code> header requesting <code>application/json</code> MIME type the response can either contain the message in <code>json</code> or result in a redirect, processing of the response should attempt to determine which response type is received and process the message accordingly.</p>"},{"location":"aip2/0434-outofband/#out-of-band-message-publishing","title":"Out-of-Band Message Publishing","text":"<p>The sender will publish or transmit the out-of-band message URL in a manner available to the intended receiver. After publishing, the sender is in the await-response state, will the receiver is in the prepare-response state.</p>"},{"location":"aip2/0434-outofband/#out-of-band-message-processing","title":"Out-of-Band Message Processing","text":"<p>If the receiver receives an <code>out-of-band</code> message in the form of a QR code, the receiver should attempt to decode the QR code to an out-of-band message URL for processing.</p> <p>When the receiver receives the out-of-band message URL, there are two possible user flows, depending on whether the individual has an Aries agent. If the individual is new to Aries, they will likely load the URL in a browser. The resulting page SHOULD contain instructions on how to get started by installing an Aries agent. That install flow will transfer the out-of-band message to the newly installed software.</p> <p>A user that already has those steps accomplished will have the URL received by software directly. That software will attempt to base64URL decode the string and can read the out-of-band message directly out of the <code>oob</code> query parameter, without loading the URL. If this process fails then the software should attempt the steps to process a shortened URL. </p> <p>NOTE: In receiving the out-of-band message, the base64url decode implementation used MUST correctly decode padded and unpadded base64URL encoded data.</p> <p>If the receiver wants to respond to the out-of-band message, they will use the information in the message to prepare the request, including:</p> <ul> <li>the <code>handshake_protocols</code> or <code>requests~attach</code> to determine the acceptable response messages, and</li> <li>the <code>services</code> block to determine how to get the response to the sender.</li> </ul>"},{"location":"aip2/0434-outofband/#correlating-responses-to-out-of-band-messages","title":"Correlating responses to Out-of-Band messages","text":"<p>The response to an out-of-band message MUST set its <code>~thread.pthid</code> equal to the <code>@id</code> property of the out-of-band message.</p> <p>Example referencing an explicit invitation:</p> <pre><code>{\n  \"@id\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n  \"@type\": \"https://didcomm.org/didexchange/1.0/request\",\n  \"~thread\": { \"pthid\": \"032fbd19-f6fd-48c5-9197-ba9a47040470\" },\n  \"label\": \"Bob\",\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n    \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n    \"jws\": {\n      \"header\": {\n        \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n      },\n      \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n      \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n    }\n  }\n}\n</code></pre>"},{"location":"aip2/0434-outofband/#response-transmission","title":"Response Transmission","text":"<p>The response message from the receiver is encoded according to the standards of the DIDComm encryption envelope, using the <code>service</code> block present in (or resolved from) the out-of-band invitation.</p>"},{"location":"aip2/0434-outofband/#reusing-connections","title":"Reusing Connections","text":"<p>If an out-of-band invitation has a DID in the <code>services</code> block, and the receiver determines it has previously established a connection with that DID, the receiver MAY send its response on the established connection. See Reuse Messages for details.</p>"},{"location":"aip2/0434-outofband/#receiver-error-handling","title":"Receiver Error Handling","text":"<p>If the receiver is unable to process the out-of-band message, the receiver may respond with a Problem Report identifying the problem using a DIDComm message. As with any response, the ~thread decorator of the <code>pthid</code> MUST be the <code>@id</code> of the out-of-band message. The problem report MUST be in the protocol of an expected response. An example of an error that might come up is that the receiver is not able to handle any of the proposed protocols in the out-of-band message. The receiver MAY include in the problem report a <code>~service</code> decorator that allows the sender to respond to the out-of-band message with a DIDComm message.</p>"},{"location":"aip2/0434-outofband/#response-processing","title":"Response processing","text":"<p>The sender MAY look up the corresponding out-of-band message identified in the response's <code>~thread.pthid</code> to determine whether it should accept the response. Information about the related out-of-band message protocol may be required to provide the sender with context about processing the response and what to do after the protocol completes.</p>"},{"location":"aip2/0434-outofband/#sender-error-handling","title":"Sender Error Handling","text":"<p>If the sender receives a Problem Report message from the receiver, the sender has several options for responding. The sender will receive the message as part of an offered protocol in the out-of-band message.</p> <p>If the receiver did not include a <code>~service</code> decorator in the response, the sender can only respond if it is still in session with the receiver. For example, if the sender is a website that displayed a QR code for the receiver to scan, the sender could create a new, presumably adjusted, out-of-band message, encode it and present it to the user in the same way as before.</p> <p>If the receiver included a <code>~service</code> decorator in the response, the sender can provide a new message to the receiver, even a new version of the original out-of-band message, and send it to the receiver. The new message MUST include a <code>~thread</code> decorator with the <code>thid</code> set to the <code>@id</code> from the problem report message.</p>"},{"location":"aip2/0434-outofband/#drawbacks","title":"Drawbacks","text":"<ul> <li>Publicly displayed out-of-band messages (say, a slide at the end of a presentation) all use the same DID. This is not a problem for institutions, and only provides a minor increase in correlation over sharing an endpoint, key, and routing information in a way that is observable by multiple parties.</li> </ul>"},{"location":"aip2/0434-outofband/#prior-art","title":"Prior art","text":"<ul> <li>The out-of-band message/response process is similar to other key exchange protocols.</li> <li>The Connections and DID Exchange protocols have (or had) their own <code>invitation</code> method.</li> <li>The <code>~service</code> decorator in combination with a request/response-type protocol message (such as present-proof/request) has previously used in place of the out-of-band <code>request</code> message.</li> </ul>"},{"location":"aip2/0434-outofband/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>None</li> </ul>"},{"location":"aip2/0434-outofband/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0441-present-proof-best-practices/","title":"0441: Prover and Verifier Best Practices for Proof Presentation","text":"<ul> <li>Authors: Stephen Klump</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Interoperability guidance when using Indy AnonCreds Present Proof. An element of the Indy AnonCreds subtarget for AIP v2.0.</li> <li>Start Date: 2020-10-31</li> <li>Tags: concept, credentials</li> </ul>"},{"location":"aip2/0441-present-proof-best-practices/#summary","title":"Summary","text":"<p>This work prescribes best practices for provers in credential selection (toward proof presentation), for verifiers in proof acceptance, and for both regarding non-revocation interval semantics in fulfilment of the Present Proof protocol RFC0037. Of particular instance is behaviour against presentation requests and presentations in their various non-revocation interval profiles.</p>"},{"location":"aip2/0441-present-proof-best-practices/#motivation","title":"Motivation","text":"<p>Agents should behave consistently in automatically selecting credentials and proving presentations.</p>"},{"location":"aip2/0441-present-proof-best-practices/#tutorial","title":"Tutorial","text":"<p>The subsections below introduce constructs and outline best practices for provers and verifiers.</p>"},{"location":"aip2/0441-present-proof-best-practices/#presentation-requests-and-non-revocation-intervals","title":"Presentation Requests and Non-Revocation Intervals","text":"<p>This section prescribes norms and best practices in formulating and interpreting non-revocation intervals on proof requests.</p>"},{"location":"aip2/0441-present-proof-best-practices/#semantics-of-non-revocation-interval-presence-and-absence","title":"Semantics of Non-Revocation Interval Presence and Absence","text":"<p>The presence of a non-revocation interval applicable to a requested item (see below) in a presentation request signifies that the verifier requires proof of non-revocation status of the credential providing that item.</p> <p>The absence of any non-revocation interval applicable to a requested item signifies that the verifier has no interest in its credential's non-revocation status.</p> <p>A revocable or non-revocable credential may satisfy a presentation request with or without a non-revocation interval. The presence of a non-revocation interval conveys that if the prover presents a revocable credential, the presentation must include proof of non-revocation. Its presence does not convey any restriction on the revocability of the credential to present: in many cases the verifier cannot know whether a prover's credential is revocable or not.</p>"},{"location":"aip2/0441-present-proof-best-practices/#non-revocation-interval-applicability-to-requested-items","title":"Non-Revocation Interval Applicability to Requested Items","text":"<p>A requested item in a presentation request is an attribute or a predicate, proof of which the verifier requests presentation. A non-revocation interval within a presentation request is specifically applicable, generally applicable, or inapplicable to a requested item.</p> <p>Within a presentation request, a top-level non-revocation interval is generally  applicable to all requested items. A non-revocation interval defined particularly for  a requested item is specifically applicable to that requested attribute or predicate but inapplicable to all others.</p> <p>A non-revocation interval specifically applicable to a requested item overrides any generally applicable non-revocation interval: no requested item may have both.</p> <p>For example, in the following (indy) proof request</p> <pre><code>{\n    \"name\": \"proof-request\",\n    \"version\": \"1.0\",\n    \"nonce\": \"1234567890\",\n    \"requested_attributes\": {\n        \"legalname\": {\n            \"name\": \"legalName\",\n            \"restrictions\": [\n                {\n                    \"issuer_did\": \"WgWxqztrNooG92RXvxSTWv\"\n                }\n            ]\n        },\n        \"regdate\": {\n            \"name\": \"regDate\",\n            \"restrictions\": [\n                {\n                    \"issuer_did\": \"WgWxqztrNooG92RXvxSTWv\"\n                }\n            ],\n            \"non_revoked\": {\n                \"from\": 1600001000,\n                \"to\": 1600001000\n            }\n        }\n    },\n    \"requested_predicates\": {\n    },\n    \"non_revoked\": {\n        \"from\": 1600000000,\n        \"to\": 1600000000\n    }\n}\n</code></pre> <p>the non-revocation interval on 1600000000 is generally applicable to the referent <code>\"legalname\"</code> while the non-revocation interval on 1600001000 specifically applicable to referent <code>\"regdate\"</code>.</p>"},{"location":"aip2/0441-present-proof-best-practices/#semantics-of-non-revocation-interval-endpoints","title":"Semantics of Non-Revocation Interval Endpoints","text":"<p>A non-revocation interval contains <code>\"from\"</code> and <code>\"to\"</code> (integer) EPOCH times. For historical reasons, any timestamp within this interval is technically acceptable in a non-revocation subproof. However, these semantics allow for ambiguity in cases where revocation occurs within the interval, and in cases where the ledger supports reinstatement. These best practices require the <code>\"from\"</code> value, should the prover specify it, to equal the <code>\"to\"</code> value: this approach fosters deterministic outcomes.</p> <p>A missing <code>\"from\"</code> specification defaults to the same value as the interval's <code>\"to\"</code> value. In other words, the non-revocation intervals</p> <pre><code>{\n    \"to\": 1234567890\n}\n</code></pre> <p>and</p> <pre><code>{\n    \"from\": 1234567890,\n    \"to\": 1234567890\n}\n</code></pre> <p>are semantically equivalent.</p>"},{"location":"aip2/0441-present-proof-best-practices/#verifier-non-revocation-interval-formulation","title":"Verifier Non-Revocation Interval Formulation","text":"<p>The verifier MUST specify, as current INDY-HIPE 11 notes, the same integer EPOCH time for both ends of the interval, or else omit the <code>\"from\"</code> key and value. In effect, where the presentation request specifies a non-revocation interval, the verifier MUST request a non-revocation instant.</p>"},{"location":"aip2/0441-present-proof-best-practices/#prover-non-revocation-interval-processing","title":"Prover Non-Revocation Interval Processing","text":"<p>In querying the nodes for revocation status, given a revocation interval on a single instant (i.e., on <code>\"from\"</code> and <code>\"to\"</code> the same, or <code>\"from\"</code> absent), the prover MUST query the ledger for all germane revocation updates from registry creation through that instant (i.e., from zero through <code>\"to\"</code> value): if the credential has been revoked prior to the instant, the revocation necessarily will appear in the aggregate delta.</p>"},{"location":"aip2/0441-present-proof-best-practices/#provers-presentation-proposals-and-presentation-requests","title":"Provers, Presentation Proposals, and Presentation Requests","text":"<p>In fulfilment of the RFC0037 Present Proof protocol, provers may initiate with a presentation proposal or verifiers may initiate with a presentation request. In the former case, the prover has both a presentation proposal and a presentation request; in the latter case, the prover has only a presentation request.</p>"},{"location":"aip2/0441-present-proof-best-practices/#credential-selection-best-practices","title":"Credential Selection Best Practices","text":"<p>This section specifies a prover's best practices in matching a credential to a requested item. The specification pertains to automated credential selection: obviously, a human user may select any credential in response to a presentation request; it is up to the verifier to verify the resulting presentation as satisfactory or not.</p> <p>Note that where a prover selects a revocable credential for inclusion in response to a requested item with a non-revocation interval in the presentation request, the prover MUST create a corresponding sub-proof of non-revocation at a timestamp within that non-revocation interval (insofar as possible; see below).</p>"},{"location":"aip2/0441-present-proof-best-practices/#with-presentation-proposal","title":"With Presentation Proposal","text":"<p>If prover initiated the protocol with a presentation proposal specifying a value (or predicate threshold) for an attribute, and the presentation request does not require a different value for it, then the prover MUST select a credential matching the presentation proposal, in addition to following the best practices below regarding the presentation request.</p>"},{"location":"aip2/0441-present-proof-best-practices/#preference-for-irrevocable-credentials","title":"Preference for Irrevocable Credentials","text":"<p>In keeping with the specification above, presentation of an irrevocable credential ipso facto constitutes proof of non-revocation. Provers MUST always prefer irrevocable credentials to revocable credentials, when the wallet has both satisfying a requested item, whether the requested item has an applicable non-revocation interval or not. Note that if a non-revocation interval is applicable to a credential's requested item in the presentation request, selecting an irrevocable credential for presentation may lead to a missing timestamp at the verifier (see below).</p> <p>If only revocable credentials are available to satisfy a requested item with no applicable non-revocation interval, the prover MUST present such for proof. As per above, the absence of a non-revocation interval signifies that the verifier has no interest in its revocation status.</p>"},{"location":"aip2/0441-present-proof-best-practices/#verifiers-presentations-and-timestamps","title":"Verifiers, Presentations, and Timestamps","text":"<p>This section prescribes verifier best practices concerning a received presentation by its timestamps against the corresponding presentation request's non-revocation intervals.</p>"},{"location":"aip2/0441-present-proof-best-practices/#timestamp-for-irrevocable-credential","title":"Timestamp for Irrevocable Credential","text":"<p>A presentation's inclusion of a timestamp pertaining to an irrevocable credential evinces tampering: the verifier MUST reject such a presentation.</p>"},{"location":"aip2/0441-present-proof-best-practices/#missing-timestamp","title":"Missing Timestamp","text":"<p>A presentation with no timestamp for a revocable credential purporting to satisfy a requested item in the corresponding presentation request, where the requested item has an applicable non-revocation interval, evinces tampering: the verifier MUST reject such a presentation.</p> <p>It is licit for a presentation to have no timestamp for an irrevocable credential: the applicable non-revocation interval is superfluous in the presentation request.</p>"},{"location":"aip2/0441-present-proof-best-practices/#timestamp-outside-non-revocation-interval","title":"Timestamp Outside Non-Revocation Interval","text":"<p>A presentation may include a timestamp outside of a the non-revocation interval applicable to the requested item that a presented credential purports to satisfy. If the latest timestamp from the ledger for a presented credential's revocation registry predates the non-revocation interval, but the timestamp is not in the future (relative to the instant of presentation proof, with a reasonable allowance for clock skew), the verifier MUST log and continue the proof verification process.</p> <p>Any timestamp in the future (relative to the instant of presentation proof, with a reasonable allowance for clock skew) evinces tampering: the verifier MUST reject a presentation with a future timestamp. Similarly, any timestamp predating the creation of its corresponding credential's revocation registry on the ledger evinces tampering: the verifier MUST reject a presentation with such a timestamp.</p>"},{"location":"aip2/0441-present-proof-best-practices/#dates-and-predicates","title":"Dates and Predicates","text":"<p>This section prescribes issuer and verifier best practices concerning representing dates for use in predicate proofs (eg proving Alice is over 21 without revealing her birth date).</p>"},{"location":"aip2/0441-present-proof-best-practices/#dates-in-credentials","title":"Dates in Credentials","text":"<p>In order for dates to be used in a predicate proof they MUST be expressed as an Int32. While unix timestamps could work for this, it has several drawbacks including: can't represent dates outside of the years 1901-2038, isn't human readable, and is overly precise in that birth time down to the second is generally not needed for an age check. To address these issues, date attributes SHOULD be represented as integers in the form YYYYMMDD (eg 19991231). This addresses the issues with unix timestamps (or any seconds-since-epoch system) while still allowing date values to be compared with &lt; &gt; operators. Note that this system won't work for any general date math (eg adding or subtracting days), but it will work for predicate proofs which just require comparisons. In order to make it clear that this format is being used, the attribute name SHOULD have the suffix <code>_dateint</code>. Since most datetime libraries don't include this format, here are some examples of helper functions written in typescript.</p>"},{"location":"aip2/0441-present-proof-best-practices/#dates-in-presentations","title":"Dates in Presentations","text":"<p>When constructing a proof request, the verifier SHOULD express the minimum/maximum date as an integer in the form YYYYMMDD. For example if today is Jan 1, 2021 then the verifier would request that <code>bithdate_dateint</code> is before or equal to Jan 1 2000 so <code>&lt;= 20000101</code>. The holder MUST construct a predicate proof with a YYYYMMDD represented birth date less than that value to satisfy the proof request.</p>"},{"location":"aip2/0441-present-proof-best-practices/#reference","title":"Reference","text":"<ul> <li>RFC 0037: Present Proof protocol</li> <li>INDY-HIPE 11: Indy revocation.</li> </ul>"},{"location":"aip2/0441-present-proof-best-practices/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"aip2/0453-issue-credential-v2/","title":"Aries RFC 0453: Issue Credential Protocol 2.0","text":"<ul> <li>Authors: Nikita Khateev, Stephen Klump, Stephen Curran</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note:  See RFC 0454 for the presentation part of using credentials.</li> <li>Supersedes: RFC 0036 Issue Credential v1.x</li> <li>Start Date: 2020-03-23</li> <li>Tags: feature, decorator, protocol, credentials, test-anomaly</li> </ul>"},{"location":"aip2/0453-issue-credential-v2/#version-change-log","title":"Version Change Log","text":"<ul> <li>20240311 Removed references to payments in the protocol to clarify to those new to the protocol that they have not been implemented by anyone.</li> <li>20240313 Version 2.0 is the current version</li> </ul> <p>For a period of time, versions 2.1 and 2.2 where defined in this RFC. Those definitions were added prior to any implementations, and to date, there are no known implementations available or planned. An attempt at implementing version 2.1 was not merged into the main branch of Aries Cloud Agent Python, deemed overly complicated and not worth the effort for what amounts to an edge case (issuing multiple credentials of the same type in a single protocol instance). Further, there is a version 3.0 of this protocol that has been specified and implemented that does not include these capabilities. Thus, a decision was made that versions 2.1 and 2.2 be removed as being not accepted by the community and overly complicated to both implement and migrate from. Those interested in seeing how those capabilities were specified can look at this protocol before they were removed.</p>"},{"location":"aip2/0453-issue-credential-v2/#20propose-credential-and-identifiers","title":"2.0/propose-credential and identifiers","text":"<p>Version 2.0 of the protocol is introduced because of a breaking changes in the propose-credential message, replacing the (indy-specific) filtration criteria with a generalized filter attachment to align with the rest of the messages in the protocol. The previous version is 1.1/propose-credential. Version 2.0 also uses &lt;angle brackets&gt; explicitly to mark all values that may vary between instances, such as identifiers and comments.</p> <p>The \"formats\" field is added to all the messages to enable the linking the specific attachment IDs with the the format (credential format and version) of the attachment.</p> <p>The details that are part of each message type about the different attachment formats serves as a registry of the known formats and versions.</p>"},{"location":"aip2/0453-issue-credential-v2/#summary","title":"Summary","text":"<p>Formalizes messages used to issue a credential--whether the credential is JWT-oriented, JSON-LD-oriented, or ZKP-oriented. The general flow is similar, and this protocol intends to handle all of them. If you are using a credential type that doesn't fit this protocol, please raise a Github issue.</p>"},{"location":"aip2/0453-issue-credential-v2/#motivation","title":"Motivation","text":"<p>We need a standard protocol for issuing credentials. This is the basis of interoperability between Issuers and Holders.</p>"},{"location":"aip2/0453-issue-credential-v2/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0453-issue-credential-v2/#name-and-version","title":"Name and Version","text":"<p><code>issue-credential</code>, version 2.0</p>"},{"location":"aip2/0453-issue-credential-v2/#roles","title":"Roles","text":"<p>There are two roles in this protocol: Issuer and Holder. Technically, the latter role is only potential until the protocol completes; that is, the second party becomes a Holder of a credential by completing the protocol. However, we will use the term Holder throughout, to keep things simple.</p> <p>Note: When a holder of credentials turns around and uses those credentials to prove something, they become a Prover. In the sister RFC to this one, 0454: Present Proof Protocol 2.0, the Holder is therefore renamed to Prover. Sometimes in casual conversation, the Holder role here might be called \"Prover\" as well, but more formally, \"Holder\" is the right term at this phase of the credential lifecycle.</p>"},{"location":"aip2/0453-issue-credential-v2/#goals","title":"Goals","text":"<p>When the goals of each role are not available because of context, goal codes may be specifically included in protocol messages. This is particularly helpful to differentiate between credentials passed between the same parties for several different reasons. A goal code included should be considered to apply to the entire thread and is not necessary to be repeated on each message. Changing the goal code may be done by including the new code in a message. All goal codes are optional, and without default.</p>"},{"location":"aip2/0453-issue-credential-v2/#states","title":"States","text":"<p>The choreography diagram below details how state evolves in this protocol, in a \"happy path.\" The states include</p>"},{"location":"aip2/0453-issue-credential-v2/#issuer-states","title":"Issuer States","text":"<ul> <li>proposal-received</li> <li>offer-sent</li> <li>request-received</li> <li>credential-issued</li> <li>done</li> </ul>"},{"location":"aip2/0453-issue-credential-v2/#holder-states","title":"Holder States","text":"<ul> <li>proposal-sent</li> <li>offer-received</li> <li>request-sent</li> <li>credential-received</li> <li>done</li> </ul> <p>Errors might occur in various places. For example, an Issuer might offer a credential for a price that the Holder is unwilling to pay. All errors are modeled with a <code>problem-report</code> message. Easy-to-anticipate errors reset the flow as shown in the diagrams, and use the code <code>issuance-abandoned</code>; more exotic errors (e.g., server crashed at Issuer headquarters in the middle of a workflow) may have different codes but still cause the flow to be abandoned in the same way. That is, in this version of the protocol, all errors cause the state of both parties (the sender and the receiver of the <code>problem-report</code>) to revert to <code>null</code> (meaning it is no longer engaged in the protocol at all). Future versions of the protocol may allow more granular choices (e.g., requesting and receiving a (re-)send of the <code>issue-credential</code> message if the Holder times out while waiting in the <code>request-sent</code> state).</p> <p>The state table outlines the protocol states and transitions.</p>"},{"location":"aip2/0453-issue-credential-v2/#messages","title":"Messages","text":"<p>The Issue Credential protocol consists of these messages:</p> <ul> <li><code>propose-credential</code> - potential Holder to Issuer (optional). Tells what the Holder hopes to receive.</li> <li><code>offer-credential</code> - Issuer to potential Holder (optional for some credential implementations; required for Hyperledger Indy). Tells what the Issuer intends to issue, and possibly, the price the Issuer expects to be paid.</li> <li><code>request-credential</code> - potential Holder to Issuer. If neither of the previous message types is used, this is the message that begins the protocol.</li> <li><code>issue-credential</code> - Issuer to new Holder. Attachment payload contains the actual credential.</li> </ul> <p>In addition, the <code>ack</code> and <code>problem-report</code> messages are adopted into the protocol for confirmation and error handling.</p>"},{"location":"aip2/0453-issue-credential-v2/#message-attachments","title":"Message Attachments","text":"<p>This protocol is about the messages that must be exchanged to issue verifiable credentials, NOT about the specifics of particular verifiable credential schemes. DIDComm attachments are deliberately used in messages to isolate the protocol flow/semantics from the credential artifacts themselves as separate constructs. Attachments allow credential formats and this protocol to evolve through versioning milestones independently instead of in lockstep. Links are provided in the message descriptions below, to describe how the protocol adapts to specific verifiable credential implementations.</p> <p>The attachment items in the messages are arrays. The arrays are provided to support the issuing of different credential formats (e.g. ZKP, JSON-LD JWT, or other) containing the same data (claims). The arrays are not to be used for issuing credentials with different claims. The <code>formats</code> field of each message associates each attachment with the format (and version) of the attachment.</p> <p>A registry of attachment formats is provided in this RFC within the message type sections. A sub-section should be added for each attachment format type (and optionally, each version). Updates to the attachment type formats does NOT impact the versioning of the Issue Credential protocol. Formats are flexibly defined. For example, the first definitions are for <code>hlindy/cred-abstract@v2.0</code> et al., assuming that all Hyperledger Indy implementations and ledgers will use a common format. However, if a specific instance of Indy uses a different format, another format value can be documented as a new registry entry.</p> <p>Any of the 0017-attachments RFC embedded inline attachments can be used. In the examples below, <code>base64</code> is used in most cases, but implementations MUST expect any of the formats.</p>"},{"location":"aip2/0453-issue-credential-v2/#choreography-diagram","title":"Choreography Diagram","text":"<p>Note: This diagram was made in draw.io. To make changes:</p> <ul> <li>upload the drawing HTML from this folder to the draw.io site (Import From...GitHub),</li> <li>make changes,</li> <li>export the picture and HTML to your local copy of this repo, and</li> <li>submit a pull request.</li> </ul> <p>The protocol has 3 alternative beginnings:</p> <ol> <li>The Issuer can begin with an offer.</li> <li>The Holder can begin with a proposal.</li> <li>the Holder can begin with a request.</li> </ol> <p>The offer and proposal messages are part of an optional negotiation phase and may trigger back-and-forth counters. A request is not subject to negotiation; it can only be accepted or rejected.</p> <p></p>"},{"location":"aip2/0453-issue-credential-v2/#propose-credential","title":"Propose Credential","text":"<p>An optional message sent by the potential Holder to the Issuer to initiate the protocol or in response to an <code>offer-credential</code> message when the Holder wants some adjustments made to the credential data offered by Issuer.</p>  Note: In Hyperledger Indy, where the `request-credential` message can **only** be sent in response to an `offer-credential` message, the `propose-credential` message is the only way for a potential Holder to initiate the workflow.  <p>Message format:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/propose-credential\",\n    \"@id\": \"&lt;uuid of propose-message&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\"\n        }\n    ],\n    \"filters~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Proposal, so the proposal can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>credential_preview</code> -- an optional JSON-LD object that represents the credential data that Prover wants to receive. It matches the schema of Credential Preview.</li> <li><code>formats</code> -- contains an entry for each <code>filters~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable credential format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>filters~attach</code> -- an array of attachments that further define the credential being proposed. This might be used to clarify which formats or format versions are wanted.</li> </ul>"},{"location":"aip2/0453-issue-credential-v2/#propose-attachment-registry","title":"Propose Attachment Registry","text":"Credential Format Format Value Link to Attachment Format Comment DIF Credential Manifest <code>dif/credential-manifest@v1.0</code> <code>propose-credential</code> attachment format Linked Data Proof VC Detail <code>aries/ld-proof-vc-detail@v1.0</code> <code>ld-proof-vc-detail</code> attachment format Hyperledger Indy Credential Filter <code>hlindy/cred-filter@v2.0</code> <code>cred filter</code> format Hyperledger AnonCreds Credential Filter <code>anoncreds/credential-filter@v1.0</code> <code>Credential Filter</code> format"},{"location":"aip2/0453-issue-credential-v2/#offer-credential","title":"Offer Credential","text":"<p>A message sent by the Issuer to the potential Holder, describing the credential they intend to offer and possibly the price they expect to be paid. In Hyperledger Indy, this message is required, because it forces the Issuer to make a cryptographic commitment to the set of fields in the final credential and thus prevents Issuers from inserting spurious data. In credential implementations where this message is optional, an Issuer can use the message to negotiate the issuing following receipt of a <code>request-credential</code> message.</p> <p>Message Format:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/offer-credential\",\n    \"@id\": \"&lt;uuid of offer message&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"replacement_id\": \"&lt;issuer unique id&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"offers~attach\": [\n        {\n            \"@id\": \"&lt;attach@id value&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>replacement_id</code> -- an optional field to help coordinate credential replacement. When this is present and matches the <code>replacement_id</code> of a previously issued credential, it may be used to inform the recipient that the offered credential is considered to be a replacement to the previous credential. This value is unique to the issuer. It must not be used in a credential presentation.</li> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Offer, so the offer can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>credential_preview</code> -- a JSON-LD object that represents the credential data that Issuer is willing to issue. It matches the schema of Credential Preview;</li> <li><code>formats</code> -- contains an entry for each <code>offers~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable credential format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>offers~attach</code> -- an array of attachments that further define the credential being offered. This might be used to clarify which formats or format versions will be issued.</li> </ul> <p>It is possible for an Issuer to add a <code>~timing.expires_time</code> decorator to this message to convey the idea that the offer will expire at a particular point in the future. Such behavior is not a special part of this protocol, and support for it is not a requirement of conforming implementations; the <code>~timing</code> decorator is simply a general possibility for any DIDComm message. We mention it here just to note that the protocol can be enriched in composable ways.</p>"},{"location":"aip2/0453-issue-credential-v2/#offer-attachment-registry","title":"Offer Attachment Registry","text":"Credential Format Format Value Link to Attachment Format Comment DIF Credential Manifest <code>dif/credential-manifest@v1.0</code> <code>offer-credential</code> attachment format Hyperledger Indy Credential Abstract <code>hlindy/cred-abstract@v2.0</code> <code>cred abstract</code> format Linked Data Proof VC Detail <code>aries/ld-proof-vc-detail@v1.0</code> <code>ld-proof-vc-detail</code> attachment format Hyperledger AnonCreds Credential Offer <code>anoncreds/credential-offer@v1.0</code> <code>Credential Offer</code> format W3C VC - Data Integrity Proof Credential Offer <code>didcomm/w3c-di-vc-offer@v0.1</code> <code>Credential Offer</code> format"},{"location":"aip2/0453-issue-credential-v2/#request-credential","title":"Request Credential","text":"<p>This is a message sent by the potential Holder to the Issuer, to request the issuance of a credential. Where circumstances do not require a preceding Offer Credential message (e.g., there is no cost to issuance that the Issuer needs to explain in advance, and there is no need for cryptographic negotiation), this message initiates the protocol. When using the Hyperledger Indy AnonCreds verifiable credential format, this message can only be sent in response to an <code>offer-credential</code> message.</p> <p>Message Format:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/request-credential\",\n    \"@id\": \"&lt;uuid of request message&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"requests~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        },\n    ]\n}\n</code></pre> <p>Description of Fields:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Request, so it can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>formats</code> -- contains an entry for each <code>requests~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable credential format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>requests~attach</code> -- an array of attachments defining the requested formats for the credential.</li> </ul>"},{"location":"aip2/0453-issue-credential-v2/#request-attachment-registry","title":"Request Attachment Registry","text":"Credential Format Format Value Link to Attachment Format Comment DIF Credential Manifest <code>dif/credential-manifest@v1.0</code> <code>request-credential</code> attachment format Hyperledger Indy Credential Request <code>hlindy/cred-req@v2.0</code> <code>cred request</code> format Linked Data Proof VC Detail <code>aries/ld-proof-vc-detail@v1.0</code> <code>ld-proof-vc-detail</code> attachment format Hyperledger AnonCreds Credential Request <code>anoncreds/credential-request@v1.0</code> <code>Credential Request</code> format W3C VC - Data Integrity Proof Credential Request <code>didcomm/w3c-di-vc-request@v0.1</code> <code>Credential Request</code> format"},{"location":"aip2/0453-issue-credential-v2/#issue-credential","title":"Issue Credential","text":"<p>This message contains a verifiable credential being issued as an attached payload. It is sent in response to a valid Request Credential message.</p> <p>Message Format:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/issue-credential\",\n    \"@id\": \"&lt;uuid of issue message&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"replacement_id\": \"&lt;issuer unique id&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"credentials~attach\": [\n        {\n            \"@id\": \"&lt;attachment-id&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>replacement_id</code> -- an optional field that provides an identifier used to manage credential replacement. When this value is present and matches the <code>replacement_id</code> of a previously issued credential, this credential may be considered as a replacement for that credential. This value is unique to the issuer. It must not be used in a credential presentation.</li> <li><code>comment</code> -- an optional field that provides human readable information about the issued credential, so it can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>formats</code> -- contains an entry for each <code>credentials~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable credential format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>credentials~attach</code> -- an array of attachments containing the issued credentials.</li> </ul> <p>If the issuer wants an acknowledgement that he issued credential was accepted, this message must be decorated with the <code>~please-ack</code> decorator using the <code>OUTCOME</code> acknowledgement request. Outcome in the context of this protocol means the acceptance of the credential in whole, i.e. the credential is verified and the contents of the credential are acknowledged. Note that this is different from the default behavior as described in 0317: Please ACK Decorator. It is then best practice for the new Holder to respond with an explicit <code>ack</code> message as described in the please ack decorator RFC.</p>"},{"location":"aip2/0453-issue-credential-v2/#credentials-attachment-registry","title":"Credentials Attachment Registry","text":"Credential Format Format Value Link to Attachment Format Comment Linked Data Proof VC <code>aries/ld-proof-vc@v1.0</code> <code>ld-proof-vc</code> attachment format Hyperledger Indy Credential <code>hlindy/cred@v2.0</code> credential format Hyperledger AnonCreds Credential <code>anoncreds/credential@v1.0</code> <code>Credential</code> format W3C VC - Data Integrity Proof Credential <code>didcomm/w3c-di-vc@v0.1</code> <code>Credential</code> format"},{"location":"aip2/0453-issue-credential-v2/#adopted-problem-report","title":"Adopted Problem Report","text":"<p>The problem-report message is adopted by this protocol. <code>problem-report</code> messages can be used by either party to indicate an error in the protocol.</p>"},{"location":"aip2/0453-issue-credential-v2/#preview-credential","title":"Preview Credential","text":"<p>This is not a message but an inner object for other messages in this protocol. It is used construct a preview of the data for the credential that is to be issued. Its schema follows:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/credential-preview\",\n    \"attributes\": [\n        {\n            \"name\": \"&lt;attribute name&gt;\",\n            \"mime-type\": \"&lt;type&gt;\",\n            \"value\": \"&lt;value&gt;\"\n        },\n        // more attributes\n    ]\n}\n</code></pre> <p>The main element is <code>attributes</code>. It is an array of (object) attribute specifications; the subsections below outline their semantics.</p>"},{"location":"aip2/0453-issue-credential-v2/#attribute-name","title":"Attribute Name","text":"<p>The mandatory <code>\"name\"</code> key maps to the attribute name as a string.</p>"},{"location":"aip2/0453-issue-credential-v2/#mime-type-and-value","title":"MIME Type and Value","text":"<p>The optional <code>mime-type</code> advises the issuer how to render a binary attribute, to judge its content for applicability before issuing a credential containing it. Its value parses case-insensitively in keeping with MIME type semantics of RFC 2045. If <code>mime-type</code> is missing, its value is null.</p> <p>The mandatory <code>value</code> holds the attribute value:</p> <ul> <li>if <code>mime-type</code> is missing (null), then <code>value</code> is a string. In other words, implementations interpret it the same as any other key+value pair in JSON</li> <li>if <code>mime-type</code> is not null, then <code>value</code> is always a base64url-encoded string that represents a binary BLOB, and <code>mime-type</code> tells how to interpret the BLOB after base64url-decoding.</li> </ul>"},{"location":"aip2/0453-issue-credential-v2/#threading","title":"Threading","text":"<p>Threading can be used to initiate a sub-protocol during an issue credential protocol instance. For example, during credential issuance, the Issuer may initiate a child message thread to execute the <code>Present Proof</code> sub-protocol to have the potential Holder (now acting as a Prover) prove attributes about themselves before issuing the credential. Depending on circumstances, this might be a best practice for preventing credential fraud at issuance time.</p> <p>If threading were added to all of the above messages, a <code>~thread</code> decorator would be present, and later messages in the flow would reference the <code>@id</code> of earlier messages to stitch the flow into a single coherent sequence. Details about threading can be found in the 0008: Message ID and Threading RFC.</p>"},{"location":"aip2/0453-issue-credential-v2/#limitations","title":"Limitations","text":"<p>Smart contracts may be missed in ecosystem, so operation \"issue credential after payment received\" is not atomic. It\u2019s possible case that malicious issuer will charge first and then will not issue credential in fact. But this situation should be easily detected and appropriate penalty should be applied in such type of networks.</p>"},{"location":"aip2/0453-issue-credential-v2/#negotiation-and-preview","title":"Negotiation and Preview","text":"<p>Negotiation prior to issuing the credential can be done using the <code>offer-credential</code> and <code>propose-credential</code> messages. A common negotiation use case would be about the data to go into the credential. For that, the <code>credential_preview</code> element is used.</p>"},{"location":"aip2/0453-issue-credential-v2/#drawbacks","title":"Drawbacks","text":"<p>None documented</p>"},{"location":"aip2/0453-issue-credential-v2/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Attention should be paid by the Aries community to other credential issuance protocols being proposed/used in other communities to ensure this RFC could support those protocols.</li> <li>Digital Bazaar has proposed the Credential Handler API (CHAPI) protocol that is being considered by the W3C Credentials Community Group.</li> </ul>"},{"location":"aip2/0453-issue-credential-v2/#prior-art","title":"Prior art","text":"<p>See RFC 0036 Issue Credential, v1.x.</p>"},{"location":"aip2/0453-issue-credential-v2/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>We might need to propose a new MIME type for credential (the same way as .docx is not processed as generic xml). See this issue against the W3C/vc-data-model.</li> </ul>"},{"location":"aip2/0453-issue-credential-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0454-present-proof-v2/","title":"Aries RFC 0454: Present Proof Protocol 2.0","text":"<ul> <li>Authors: Nikita Khateev, Stephen Curran</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note:  See RFC 0453 for the corresponding issue credential protocol.</li> <li>Supersedes: RFC 0037</li> <li>Start Date: 2020-05-27</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"aip2/0454-present-proof-v2/#version-change-log","title":"Version Change Log","text":"<ul> <li>Version 2.0 is the current version</li> </ul> <p>For a period of time, versions 2.1 and 2.2 where defined in this RFC. Those definitions were added prior to any implementations, and to date, there are no known implementations available or planned. An attempt at implementing version 2.1 of the associated \"issue multiple credentials\" was not merged into the main branch of Aries Cloud Agent Python, deemed overly complicated and not worth the effort for what amounts to an edge case (presenting multiple presentations of the same type in a single protocol instance). Further, there is a version 3.0 of this protocol that has been specified and implemented that does not include these capabilities. Thus, a decision was made that versions 2.1 and 2.2 be removed as being not accepted by the community and overly complicated to both implement and migrate from. Those interested in seeing how those capabilities were specified can look at this protocol before they were removed.</p>"},{"location":"aip2/0454-present-proof-v2/#20-alignment-with-rfc-0453-issue-credential","title":"2.0 - Alignment with RFC 0453 Issue Credential","text":"<ul> <li>The \"formats\" field is added to all the messages to link the specific attachment IDs with the verifiable presentation format and version of the attachment.</li> <li>The details that are part of each message type about the different attachment formats serves as a registry of the known formats and versions.</li> <li>Version 2.0 uses &lt;angle brackets&gt; explicitly to mark all values that may vary between instances, such as identifiers and comments.</li> </ul>"},{"location":"aip2/0454-present-proof-v2/#summary","title":"Summary","text":"<p>A protocol supporting a general purpose verifiable presentation exchange regardless of the specifics of the underlying verifiable presentation request and verifiable presentation format.</p>"},{"location":"aip2/0454-present-proof-v2/#motivation","title":"Motivation","text":"<p>We need a standard protocol for a verifier to request a presentation from a prover, and for the prover to respond by presenting a proof to the verifier. When doing that exchange, we want to provide a mechanism for the participants to negotiate the underlying format and content of the proof.</p>"},{"location":"aip2/0454-present-proof-v2/#tutorial","title":"Tutorial","text":""},{"location":"aip2/0454-present-proof-v2/#name-and-version","title":"Name and Version","text":"<p><code>present-proof</code>, version 2.0</p>"},{"location":"aip2/0454-present-proof-v2/#key-concepts","title":"Key Concepts","text":"<p>This protocol is about the messages to support the presentation of verifiable claims, not about the specifics of particular verifiable presentation formats. DIDComm attachments are deliberately used in messages to make the protocol agnostic to specific verifiable presentation format payloads. Links are provided in the message data element descriptions to details of specific verifiable presentation implementation data structures.</p> <p>Diagrams in this protocol were made in draw.io. To make changes:</p> <ul> <li>upload the drawing HTML from this folder to the draw.io site (Import From...GitHub),</li> <li>make changes,</li> <li>export the picture and HTML to your local copy of this repo, and</li> <li>submit a pull request.</li> </ul>"},{"location":"aip2/0454-present-proof-v2/#roles","title":"Roles","text":"<p>The roles are <code>verifier</code> and <code>prover</code>.  The <code>verifier</code> requests the presentation of a proof and verifies the presentation, while the <code>prover</code> prepares the proof and presents it to the verifier. Optionally, although unlikely from a business sense, the <code>prover</code> may initiate an instance of the protocol using the <code>propose-presentation</code> message.</p>"},{"location":"aip2/0454-present-proof-v2/#goals","title":"Goals","text":"<p>When the goals of each role are not available because of context, goal codes may be specifically included in protocol messages. This is particularly helpful to differentiate between credentials passed between the same parties for several different reasons. A goal code included should be considered to apply to the entire thread and is not necessary to be repeated on each message. Changing the goal code may be done by including the new code in a message. All goal codes are optional, and without default.</p>"},{"location":"aip2/0454-present-proof-v2/#states","title":"States","text":"<p>The following states are defined and included in the state transition table below.</p>"},{"location":"aip2/0454-present-proof-v2/#states-for-verifier","title":"States for Verifier","text":"<ul> <li>request-sent</li> <li>proposal-received</li> <li>presentation-received</li> <li>abandoned</li> <li>done</li> </ul>"},{"location":"aip2/0454-present-proof-v2/#states-for-prover","title":"States for Prover","text":"<ul> <li>request-received</li> <li>proposal-sent</li> <li>presentation-sent</li> <li>abandoned</li> <li>done</li> </ul> <p>For the most part, these states map onto the transitions shown in both the state transition table above, and in the choreography diagram (below) in obvious ways. However, a few subtleties are worth highlighting:</p> <ul> <li> <p>The final states for both the prover and verifier are <code>done</code> or <code>abandoned</code>, and once reached, no further updates to the protocol instance are expected.</p> </li> <li> <p>The <code>ack-presentation</code> is sent or not based on the value of <code>will_confirm</code> in the <code>request-presentation</code>. A verifier may send an <code>ack-presentation</code> message in response to the prover including the <code>~please_ack</code> decorator in the <code>presentation</code> message. Whether an <code>ack-presentation</code> is expected or not determines whether the states <code>presentation-sent</code> and <code>presentation-received</code> are used at all in a protocol instance.</p> </li> <li> <p>The <code>ack-presentation</code> message should reflect the business validation of the proof (does the proof satisfy the business need?) not just the cryptographic verification. Ideally, those are as tightly aligned as possible.</p> </li> <li> <p>When a Prover makes a (counter-)proposal, it transitions to the <code>proposal-sent</code> state. This state is only present by implication in the choreography diagram; it essentially equates to the null or begin state in that the Prover does nothing until a presentation request arrives, triggering the leftmost transition for the Prover.</p> </li> <li> <p>Errors might occur in various places. For example, a Prover might decide not to respond to a <code>presentation-request</code> or a verifier may time out waiting for the Prover to supply a <code>presentation</code>. Errors should trigger a <code>problem-report</code>. In this version of the protocol, all errors cause the state of both parties (the sender and the receiver of the <code>problem-report</code>) to transition to the terminal <code>abandoned</code> state (meaning it is no longer engaged in the protocol at all).</p> </li> </ul>"},{"location":"aip2/0454-present-proof-v2/#choreography-diagram","title":"Choreography Diagram","text":""},{"location":"aip2/0454-present-proof-v2/#messages","title":"Messages","text":"<p>The present proof protocol consists of these messages:</p> <ul> <li><code>propose-presentation</code> - Prover to Verifier (optional) - propose a presentation or send a counter-proposal in response to a <code>request-presentation</code> message</li> <li><code>request-presentation</code> - Verifier to Prover - request a presentation</li> <li><code>presentation</code> - Prover to Verifier - provide a presentation in response to a request</li> </ul> <p>In addition, the <code>ack</code> and <code>problem-report</code> messages are adopted into the protocol for confirmation and error handling.</p> <p>The messages that include <code>~attach</code> attachments may use any form of the embedded attachment. In the examples below, the forms of the attachment are arbitrary.</p> <p>The <code>~attach</code> array is to be used to enable a single presentation to be requested/delivered in different verifiable presentation formats. The ability to have multiple attachments must not be used to request/deliver multiple different presentations in a single instance of the protocol.</p>"},{"location":"aip2/0454-present-proof-v2/#propose-presentation","title":"Propose Presentation","text":"<p>An optional message sent by the prover to the verifier to initiate a proof presentation process, or in response to a <code>request-presentation</code> message when the prover wants to propose using a different presentation format or request. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/propose-presentation\",\n    \"@id\": \"&lt;uuid-propose-presentation&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"some comment\",\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"proposals~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"json\": \"&lt;json&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>comment</code> -- a field that provides some human readable information about the proposed presentation.</li> <li><code>formats</code> -- contains an entry for each <code>filter~attach</code> array entry, including an optional value of the attachment <code>@id</code> (if attachments are present) and the verifiable presentation format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>proposals~attach</code> -- an optional array of attachments that further define the presentation request being proposed. This might be used to clarify which formats or format versions are wanted.</li> </ul> <p>If the <code>proposals~attach</code> is not provided, the <code>attach_id</code> item in the <code>formats</code> array should not be provided. That form of the <code>propose-presentation</code> message is to indicate the presentation formats supported by the prover, independent of the verifiable presentation request content.</p>"},{"location":"aip2/0454-present-proof-v2/#negotiation-and-preview","title":"Negotiation and Preview","text":"<p>Negotiation prior to the delivery of the presentation can be done using the <code>propose-presentation</code> and <code>request-presentation</code> messages. The common negotiation use cases would be about the claims to go into the presentation and the format of the verifiable presentation.</p>"},{"location":"aip2/0454-present-proof-v2/#propose-attachment-registry","title":"Propose Attachment Registry","text":"Presentation Format Format Value Link to Attachment Format Comment Hyperledger Indy Proof Req <code>hlindy/proof-req@v2.0</code> proof request format Used to propose as well as request proofs. DIF Presentation Exchange <code>dif/presentation-exchange/definitions@v1.0</code> <code>propose-presentation</code> attachment format Hyperledger AnonCreds Proof Request <code>anoncreds/proof-request@v1.0</code> <code>Proof Request</code> format Used to propose as well as request proofs."},{"location":"aip2/0454-present-proof-v2/#request-presentation","title":"Request Presentation","text":"<p>From a verifier to a prover, the <code>request-presentation</code> message describes values that need to be revealed and predicates that need to be fulfilled. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/request-presentation\",\n    \"@id\": \"&lt;uuid-request&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"some comment\",\n    \"will_confirm\": true,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"request_presentations~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;base64 data&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>comment</code> -- a field that provides some human readable information about this request for a presentation.</li> <li><code>will_confirm</code> -- an optional field that defaults to <code>false</code> to indicate that the verifier will or will not send a post-presentation confirmation <code>ack</code> message</li> <li><code>formats</code> -- contains an entry for each <code>request_presentations~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable presentation request format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format Attachment registry immediately below.</li> <li><code>request_presentations~attach</code> -- an array of attachments containing the acceptable verifiable presentation requests.</li> </ul>"},{"location":"aip2/0454-present-proof-v2/#presentation-request-attachment-registry","title":"Presentation Request Attachment Registry","text":"Presentation Format Format Value Link to Attachment Format Comment Hyperledger Indy Proof Req <code>hlindy/proof-req@v2.0</code> proof request format Used to propose as well as request proofs. DIF Presentation Exchange <code>dif/presentation-exchange/definitions@v1.0</code> <code>propose-presentation</code> attachment format Hyperledger AnonCreds Proof Request <code>anoncreds/proof-request@v1.0</code> <code>Proof Request</code> format Used to propose as well as request proofs."},{"location":"aip2/0454-present-proof-v2/#presentation","title":"Presentation","text":"<p>This message is a response to a Presentation Request message and contains signed presentations. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/presentation\",\n    \"@id\": \"&lt;uuid-presentation&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"some comment\",\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"presentations~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"sha256\": \"f8dca1d901d18c802e6a8ce1956d4b0d17f03d9dc5e4e1f618b6a022153ef373\",\n                \"links\": [\"https://ibb.co/TtgKkZY\"]\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>comment</code> -- a field that provides some human readable information about this presentation.</li> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>formats</code> -- contains an entry for each <code>presentations~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable presentation format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format Attachment registry immediately below.</li> <li><code>presentations~attach</code> -- an array of attachments containing the presentation in the requested format(s).</li> </ul> <p>If the prover wants an acknowledgement that the presentation was accepted, this message may be decorated with the <code>~please-ack</code> decorator using the <code>OUTCOME</code> acknowledgement request. This is not necessary if the verifier has indicated it will send an <code>ack-presentation</code> using the <code>will_confirm</code> property. Outcome in the context of this protocol is the definition of \"successful\" as described in Ack Presentation. Note that this is different from the default behavior as described in 0317: Please ACK Decorator. It is then best practice for the new Verifier to respond with an explicit <code>ack</code> message as described in the please ack decorator RFC.</p>"},{"location":"aip2/0454-present-proof-v2/#presentations-attachment-registry","title":"Presentations Attachment Registry","text":"Presentation Format Format Value Link to Attachment Format Comment Hyperledger Indy Proof <code>hlindy/proof@v2.0</code> proof format DIF Presentation Exchange <code>dif/presentation-exchange/submission@v1.0</code> <code>propose-presentation</code> attachment format Hyperledger AnonCreds Proof <code>anoncreds/proof@v1.0</code> <code>Proof</code> format"},{"location":"aip2/0454-present-proof-v2/#ack-presentation","title":"Ack Presentation","text":"<p>A message from the verifier to the prover that the <code>Present Proof</code> protocol was completed successfully and is now in the <code>done</code> state. The message is an adopted <code>ack</code> from the RFC 0015 acks protocol. The definition of \"successful\" in this protocol means the acceptance of the presentation in whole, i.e. the proof is verified and the contents of the proof are acknowledged.</p>"},{"location":"aip2/0454-present-proof-v2/#problem-report","title":"Problem Report","text":"<p>A message from the verifier to the prover that follows the <code>presentation</code> message to indicate that the <code>Present Proof</code> protocol was completed unsuccessfully and is now in the <code>abandoned</code> state. The message is an adopted <code>problem-report</code> from the RFC 0015 report-problem protocol. The definition of \"unsuccessful\" from a business sense is up to the verifier. The elements of the <code>problem-report</code> message can provide information to the prover about why the protocol instance was unsuccessful.</p> <p>Either party may send a <code>problem-report</code> message earlier in the flow to terminate the protocol before its normal conclusion.</p>"},{"location":"aip2/0454-present-proof-v2/#reference","title":"Reference","text":"<p>Details are covered in the Tutorial section.</p>"},{"location":"aip2/0454-present-proof-v2/#drawbacks","title":"Drawbacks","text":"<p>The Indy format of the proposal attachment as proposed above does not allow nesting of logic along the lines of \"A and either B or C if D, otherwise A and B\", nor cross-credential options such as proposing a legal name issued by either (for example) a specific financial institution or government entity.</p> <p>The verifiable presentation standardization work being conducted in parallel to this in DIF and the W3C Credentials Community Group (CCG) should be included in at least the <code>Registry</code> tables of this document, and ideally used to eliminate the need for presentation format-specific options.</p>"},{"location":"aip2/0454-present-proof-v2/#rationale-and-alternatives","title":"Rationale and alternatives","text":""},{"location":"aip2/0454-present-proof-v2/#prior-art","title":"Prior art","text":"<p>The previous major version of this protocol is RFC 0037 Present Proof protocol and implementations.</p>"},{"location":"aip2/0454-present-proof-v2/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>There might need to be a way to associate a payment with the present proof protocol.</li> </ul>"},{"location":"aip2/0454-present-proof-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0510-dif-pres-exch-attach/","title":"Aries RFC 0510: Presentation-Exchange Attachment format for requesting and presenting proofs","text":"<ul> <li>Authors: George Aristy (SecureKey Technologies)</li> <li>Status: ADOPTED</li> <li>Since: 2020-07-21</li> <li>Status Note:  </li> <li>Supersedes: </li> <li>Start Date: 2020-07-21</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"aip2/0510-dif-pres-exch-attach/#summary","title":"Summary","text":"<p>This RFC registers three attachment formats for use in the present-proof V2 protocol based on the Decentralized Identity Foundation's (DIF) Presentation Exchange specification (P-E). Two of these formats define containers for a presentation-exchange request object and another options object carrying additional parameters, while the third format is just a vessel for the final <code>presentation_submission</code> verifiable presentation transferred from the Prover to the Verifier.</p> <p>Presentation Exchange defines a data format capable of articulating a rich set of proof requirements from Verifiers, and also provides a means of describing the formats in which Provers must submit those proofs.</p> <p>A Verifier's defines their requirements in a <code>presentation_definition</code> containing <code>input_descriptors</code> that describe the credential(s) the proof(s) must be derived from as well as a rich set of operators that place <code>constraints</code> on those proofs (eg. \"must be issued from issuer X\" or \"<code>age</code> over X\", etc.).</p> <p>The Verifiable Presentation format of Presentation Submissions is used as opposed to OIDC tokens or CHAPI objects. For an alternative on how to tunnel OIDC messages over DIDComm, see HTTP-Over-DIDComm. CHAPI is an alternative transport to DIDComm.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#motivation","title":"Motivation","text":"<p>The Presentation Exchange specification (P-E) possesses a rich language for expressing a Verifier's criterion.</p> <p>P-E lends itself well to several transport mediums due to its limited scope as a data format, and is easily transported over DIDComm.</p> <p>It is furthermore desirable to make use of specifications developed in an open standards body.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#tutorial","title":"Tutorial","text":"<p>Complete examples of messages are provided in the reference section.</p> <p>The Verifier sends a <code>request-presentation</code> to the Prover containing a <code>presentation_definition</code>, along with a <code>domain</code> and <code>challenge</code> the Prover must sign over in the proof.</p> <p>The Prover can optionally respond to the Verifier's <code>request-presentation</code> with a <code>propose-presentation</code> message containing \"Input Descriptors\" that describe the proofs they can provide. The contents of the attachment is just the <code>input_descriptors</code> attribute of the <code>presentation_definition</code> object.</p> <p>The Prover responds with a <code>presentation</code> message containing a <code>presentation_submission</code>.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#reference","title":"Reference","text":""},{"location":"aip2/0510-dif-pres-exch-attach/#propose-presentation-attachment-format","title":"<code>propose-presentation</code> attachment format","text":"<p>Format identifier: <code>dif/presentation-exchange/definitions@v1.0</code></p>"},{"location":"aip2/0510-dif-pres-exch-attach/#examples-propose-presentation","title":"Examples: propose-presentation","text":"Complete message example <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/propose-presentation\",\n    \"@id\": \"fce30ed1-96f8-44c9-95cf-b274288009dc\",\n    \"comment\": \"some comment\",\n    \"formats\" : [{\n        \"attach_id\" : \"143c458d-1b1c-40c7-ab85-4d16808ddf0a\",\n        \"format\" : \"dif/presentation-exchange/definitions@v1.0\"\n    }],\n    \"proposal~attach\": [{\n        \"@id\": \"143c458d-1b1c-40c7-ab85-4d16808ddf0a\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"json\": {\n                \"input_descriptors\": [{\n                    \"id\": \"citizenship_input\",\n                    \"name\": \"US Passport\",\n                    \"group\": [\"A\"],\n                    \"schema\": [{\n                        \"uri\": \"hub://did:foo:123/Collections/schema.us.gov/passport.json\"\n                    }],\n                    \"constraints\": {\n                        \"fields\": [{\n                            \"path\": [\"$.credentialSubject.birth_date\", \"$.vc.credentialSubject.birth_date\", \"$.birth_date\"],\n                            \"filter\": {\n                                \"type\": \"date\",\n                                \"minimum\": \"1999-5-16\"\n                            }\n                        }]\n                    }\n                }]\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"aip2/0510-dif-pres-exch-attach/#request-presentation-attachment-format","title":"<code>request-presentation</code> attachment format","text":"<p>Format identifier: <code>dif/presentation-exchange/definitions@v1.0</code></p> <p>Since the format identifier defined above is the same as the one used in the <code>propose-presentation</code> message, it's recommended to consider both the message <code>@type</code> and the <code>format</code> to accuarately understand the contents of the attachment.</p> <p>The contents of the attachment is a JSON object containing the Verifier's presentation definition and an options object with proof options:</p> <pre><code>{\n    \"options\": {\n        \"challenge\": \"...\",\n        \"domain\": \"...\",\n    },\n    \"presentation_definition\": {\n        // presentation definition object\n    }\n}\n</code></pre>"},{"location":"aip2/0510-dif-pres-exch-attach/#the-options-object","title":"The options object","text":"<p>options is a container of additional parameters required for the Prover to fulfill the Verifier's request.</p> <p>Available options are:</p> Name Status Description <code>challenge</code> RECOMMENDED (for LD proofs) Random seed provided by the Verifier for LD Proofs. <code>domain</code> RECOMMENDED (for LD proofs) The operational domain of the requested LD proof."},{"location":"aip2/0510-dif-pres-exch-attach/#examples-request-presentation","title":"Examples: request-presentation","text":"Complete message example requesting a verifiable presentation with proof type Ed25519Signature2018 <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/request-presentation\",\n    \"@id\": \"0ac534c8-98ed-4fe3-8a41-3600775e1e92\",\n    \"comment\": \"some comment\",\n    \"formats\" : [{\n        \"attach_id\" : \"ed7d9b1f-9eed-4bde-b81c-3aa7485cf947\",\n        \"format\" : \"dif/presentation-exchange/definitions@v1.0\"\n    }],\n    \"request_presentations~attach\": [{\n        \"@id\": \"ed7d9b1f-9eed-4bde-b81c-3aa7485cf947\",\n        \"mime-type\": \"application/json\",\n        \"data\":  {\n            \"json\": {\n                \"options\": {\n                    \"challenge\": \"23516943-1d79-4ebd-8981-623f036365ef\",\n                    \"domain\": \"us.gov/DriversLicense\"\n                },\n                \"presentation_definition\": {\n                    \"input_descriptors\": [{\n                        \"id\": \"citizenship_input\",\n                        \"name\": \"US Passport\",\n                        \"group\": [\"A\"],\n                        \"schema\": [{\n                            \"uri\": \"hub://did:foo:123/Collections/schema.us.gov/passport.json\"\n                        }],\n                        \"constraints\": {\n                            \"fields\": [{\n                                \"path\": [\"$.credentialSubject.birth_date\", \"$.birth_date\"],\n                                \"filter\": {\n                                    \"type\": \"date\",\n                                    \"minimum\": \"1999-5-16\"\n                                }\n                            }]\n                        }\n                    }],\n                    \"format\": {\n                        \"ldp_vp\": {\n                            \"proof_type\": [\"Ed25519Signature2018\"]\n                        }\n                    }\n                }\n            }\n        }\n    }]\n}\n</code></pre> The same example but requesting the verifiable presentation with proof type BbsBlsSignatureProof2020 instead <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/request-presentation\",\n    \"@id\": \"0ac534c8-98ed-4fe3-8a41-3600775e1e92\",\n    \"comment\": \"some comment\",\n    \"formats\" : [{\n        \"attach_id\" : \"ed7d9b1f-9eed-4bde-b81c-3aa7485cf947\",\n        \"format\" : \"dif/presentation-exchange/definitions@v1.0\"\n    }],\n    \"request_presentations~attach\": [{\n        \"@id\": \"ed7d9b1f-9eed-4bde-b81c-3aa7485cf947\",\n        \"mime-type\": \"application/json\",\n        \"data\":  {\n            \"json\": {\n                \"options\": {\n                    \"challenge\": \"23516943-1d79-4ebd-8981-623f036365ef\",\n                    \"domain\": \"us.gov/DriversLicense\"\n                },\n                \"presentation_definition\": {\n                    \"input_descriptors\": [{\n                        \"id\": \"citizenship_input\",\n                        \"name\": \"US Passport\",\n                        \"group\": [\"A\"],\n                        \"schema\": [{\n                            \"uri\": \"hub://did:foo:123/Collections/schema.us.gov/passport.json\"\n                        }],\n                        \"constraints\": {\n                            \"fields\": [{\n                                \"path\": [\"$.credentialSubject.birth_date\", \"$.vc.credentialSubject.birth_date\", \"$.birth_date\"],\n                                \"filter\": {\n                                    \"type\": \"date\",\n                                    \"minimum\": \"1999-5-16\"\n                                }\n                            }],\n                            \"limit_disclosure\": \"required\"\n                        }\n                    }],\n                    \"format\": {\n                        \"ldp_vc\": {\n                            \"proof_type\": [\"BbsBlsSignatureProof2020\"]\n                        }\n                    }\n                }\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"aip2/0510-dif-pres-exch-attach/#presentation-attachment-format","title":"<code>presentation</code> attachment format","text":"<p>Format identifier: <code>dif/presentation-exchange/submission@v1.0</code></p> <p>The contents of the attachment is a Presentation Submission in a standard Verifiable Presentation format containing the proofs requested.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#examples-presentation","title":"Examples: presentation","text":"Complete message example <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/presentation\",\n    \"@id\": \"f1ca8245-ab2d-4d9c-8d7d-94bf310314ef\",\n    \"comment\": \"some comment\",\n    \"formats\" : [{\n        \"attach_id\" : \"2a3f1c4c-623c-44e6-b159-179048c51260\",\n        \"format\" : \"dif/presentation-exchange/submission@v1.0\"\n    }],\n    \"presentations~attach\": [{\n        \"@id\": \"2a3f1c4c-623c-44e6-b159-179048c51260\",\n        \"mime-type\": \"application/ld+json\",\n        \"data\": {\n            \"json\": {\n                \"@context\": [\n                    \"https://www.w3.org/2018/credentials/v1\",\n                    \"https://identity.foundation/presentation-exchange/submission/v1\"\n                ],\n                \"type\": [\n                    \"VerifiablePresentation\",\n                    \"PresentationSubmission\"\n                ],\n                \"presentation_submission\": {\n                    \"descriptor_map\": [{\n                        \"id\": \"citizenship_input\",\n                        \"path\": \"$.verifiableCredential.[0]\"\n                    }]\n                },\n                \"verifiableCredential\": [{\n                    \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n                    \"id\": \"https://eu.com/claims/DriversLicense\",\n                    \"type\": [\"EUDriversLicense\"],\n                    \"issuer\": \"did:foo:123\",\n                    \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n                    \"credentialSubject\": {\n                        \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n                        \"license\": {\n                            \"number\": \"34DGE352\",\n                            \"dob\": \"07/13/80\"\n                        }\n                    },\n                    \"proof\": {\n                        \"type\": \"RsaSignature2018\",\n                        \"created\": \"2017-06-18T21:19:10Z\",\n                        \"proofPurpose\": \"assertionMethod\",\n                        \"verificationMethod\": \"https://example.edu/issuers/keys/1\",\n                        \"jws\": \"...\"\n                    }\n                }],\n                \"proof\": {\n                    \"type\": \"RsaSignature2018\",\n                    \"created\": \"2018-09-14T21:19:10Z\",\n                    \"proofPurpose\": \"authentication\",\n                    \"verificationMethod\": \"did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1\",\n                    \"challenge\": \"1f44d55f-f161-4938-a659-f8026467f126\",\n                    \"domain\": \"4jt78h47fh47\",\n                    \"jws\": \"...\"\n                }\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"aip2/0510-dif-pres-exch-attach/#supported-features-of-presentation-exchange","title":"Supported Features of Presentation-Exchange","text":"<p>Level of support for Presentation-Exchange ../../features:</p> Feature Notes <code>presentation_definition.input_descriptors.id</code> <code>presentation_definition.input_descriptors.name</code> <code>presentation_definition.input_descriptors.purpose</code> <code>presentation_definition.input_descriptors.schema.uri</code> URI for the credential's schema. <code>presentation_definition.input_descriptors.constraints.fields.path</code> Array of JSONPath string expressions as defined in section 8. REQUIRED as per the spec. <code>presentation_definition.input_descriptors.constraints.fields.filter</code> JSONSchema descriptor. <code>presentation_definition.input_descriptors.constraints.limit_disclosure</code> <code>preferred</code> or <code>required</code> as defined in the spec and as supported by the Holder and Verifier proof mechanisms.Note that the Holder MUST have credentials with cryptographic proof suites that are capable of selective disclosure in order to respond to a request with <code>limit_disclosure: \"required\"</code>.See RFC0593 for appropriate crypto suites. <code>presentation_definition.input_descriptors.constraints.is_holder</code> <code>preferred</code> or <code>required</code> as defined in the spec.Note that this feature allows the Holder to present credentials with a different subject identifier than the DID used to establish the DIDComm connection with the Verifier. <code>presentation_definition.format</code> For JSONLD-based credentials: <code>ldp_vc</code> and <code>ldp_vp</code>. <code>presentation_definition.format.proof_type</code> For JSONLD-based credentials: <code>Ed25519Signature2018</code>, <code>BbsBlsSignature2020</code>, and <code>JsonWebSignature2020</code>. When specifying <code>ldp_vc</code>, <code>BbsBlsSignatureProof2020</code> may also be used."},{"location":"aip2/0510-dif-pres-exch-attach/#proof-formats","title":"Proof Formats","text":""},{"location":"aip2/0510-dif-pres-exch-attach/#constraints","title":"Constraints","text":"<p>Verifiable Presentations MUST be produced and consumed using the JSON-LD syntax.</p> <p>The proof types defined below MUST be registered in the Linked Data Cryptographic Suite Registry.</p> <p>The value of any <code>credentialSubject.id</code> in a credential MUST be a Dentralized Identifier (DID) conforming to the DID Syntax if present. This allows the Holder to authenticate as the credential's subject if required by the Verifier (see the <code>is_holder</code> property above). The Holder authenticates as the credential's subject by attaching an LD Proof on the enclosing Verifiable Presentation.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#proof-formats-on-credentials","title":"Proof Formats on Credentials","text":"<p>Aries agents implementing this RFC MUST support the formats outlined in RFC0593 for proofs on Verifiable Credentials.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#proof-formats-on-presentations","title":"Proof Formats on Presentations","text":"<p>Aries agents implementing this RFC MUST support the formats outlined below for proofs on Verifiable Presentations.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#ed25519signature2018","title":"Ed25519Signature2018","text":"<p>Specification.</p> <p>Request Parameters:</p> <ul> <li><code>presentation_definition.format</code>: <code>ldp_vp</code></li> <li><code>presentation_definition.format.proof_type</code>: <code>Ed25519Signature2018</code></li> <li><code>options.challenge</code>: (Optional) a random string value generated by the Verifier</li> <li><code>options.domain</code>: (Optional) a string value specified set by the Verifier</li> </ul> <p>Result:</p> <p>A Verifiable Presentation of type Presentation Submission containing the credentials requested under the <code>verifiableCredential</code> property and a <code>proof</code> property of type <code>Ed25519Signature2018</code>.</p> Example <pre><code>{\n    \"@context\": [\n        \"https://www.w3.org/2018/credentials/v1\",\n        \"https://identity.foundation/presentation-exchange/submission/v1\"\n    ],\n    \"type\": [\n        \"VerifiablePresentation\",\n        \"PresentationSubmission\"\n    ],\n    \"presentation_submission\": {\n        \"descriptor_map\": [{\n           \"id\": \"citizenship_input\",\n           \"path\": \"$.verifiableCredential.[0]\"\n        }]\n    },\n    \"verifiableCredential\": [{\n        \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n        \"id\": \"https://eu.com/claims/DriversLicense\",\n        \"type\": [\n            \"EUDriversLicense\"\n        ],\n        \"issuer\": \"did:foo:123\",\n        \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n        \"credentialSubject\": {\n            \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n            \"license\": {\n            \"number\": \"34DGE352\",\n            \"dob\": \"07/13/80\"\n          }\n        },\n        \"proof\": {\n            \"type\": \"RsaSignature2018\",\n            \"created\": \"2017-06-18T21:19:10Z\",\n            \"proofPurpose\": \"assertionMethod\",\n            \"verificationMethod\": \"https://example.edu/issuers/keys/1\",\n            \"jws\": \"...\"\n        }\n    }],\n    \"proof\": {\n      \"type\": \"Ed25519Signature2018\",\n      \"proofPurpose\": \"authentication\",\n      \"created\": \"2017-09-23T20:21:34Z\",\n      \"verificationMethod\": \"did:example:123456#key1\",\n      \"challenge\": \"2bbgh3dgjg2302d-d2b3gi423d42\",\n      \"domain\": \"example.org\",\n      \"jws\": \"eyJ0eXAiOiJK...gFWFOEjXk\"\n  }\n}\n</code></pre>"},{"location":"aip2/0510-dif-pres-exch-attach/#bbsblssignature2020","title":"BbsBlsSignature2020","text":"<p>Specification.</p> <p>Associated RFC: RFC0646.</p> <p>Request Parameters: * <code>presentation_definition.format</code>: <code>ldp_vp</code> * <code>presentation_definition.format.proof_type</code>: <code>BbsBlsSignature2020</code> * <code>options.challenge</code>: (Optional) a random string value generated by the Verifier * <code>options.domain</code>: (Optional) a string value specified set by the Verifier</p> <p>Result:</p> <p>A Verifiable Presentation of type Presentation Submission containing the credentials requested under the <code>verifiableCredential</code> property and a <code>proof</code> property of type <code>BbsBlsSignature2020</code>.</p> Example <pre><code>{\n    \"@context\": [\n        \"https://www.w3.org/2018/credentials/v1\",\n        \"https://w3id.org/security/v2\",\n        \"https://w3id.org/security/bbs/v1\",\n        \"https://identity.foundation/presentation-exchange/submission/v1\"\n    ],\n    \"type\": [\n        \"VerifiablePresentation\",\n        \"PresentationSubmission\"\n    ],\n    \"presentation_submission\": {\n        \"descriptor_map\": [{\n            \"id\": \"citizenship_input\",\n            \"path\": \"$.verifiableCredential.[0]\"\n        }]\n    },\n    \"verifiableCredential\": [{\n        \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n        \"id\": \"https://eu.com/claims/DriversLicense\",\n        \"type\": [\"EUDriversLicense\"],\n        \"issuer\": \"did:foo:123\",\n        \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n        \"credentialSubject\": {\n            \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n            \"license\": {\n                \"number\": \"34DGE352\",\n                \"dob\": \"07/13/80\"\n            }\n       },\n       \"proof\": {\n           \"type\": \"BbsBlsSignatureProof2020\",\n           \"created\": \"2020-04-25\",\n           \"verificationMethod\": \"did:example:489398593#test\",\n           \"proofPurpose\": \"assertionMethod\",\n           \"signature\": \"F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg==\"\n       }\n    }],\n    \"proof\": {\n        \"type\": \"BbsBlsSignature2020\",\n        \"created\": \"2020-04-25\",\n        \"verificationMethod\": \"did:example:489398593#test\",\n        \"proofPurpose\": \"authentication\",\n        \"proofValue\": \"F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg==\",\n        \"requiredRevealStatements\": [ 4, 5 ]\n    }\n}\n</code></pre> <p>Note: The above example is for illustrative purposes. In particular, note that whether a Verifier requests a <code>proof_type</code> of <code>BbsBlsSignature2020</code> has no bearing on whether the Holder is required to present credentials with proofs of type <code>BbsBlsSignatureProof2020</code>. The choice of proof types on the credentials is constrained by a) the available types registered in RFC0593 and b) additional constraints placed on them due to other aspects of the proof requested by the Verifier, such as requiring limited disclosure with the <code>limit_disclosure</code> property. In such a case, a proof type of <code>Ed25519Signature2018</code> in the credentials is not appropriate whereas <code>BbsBlsSignatureProof2020</code> is capable of selective disclosure.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#jsonwebsignature2020","title":"JsonWebSignature2020","text":"<p>Specification.</p> <p>Request Parameters:</p> <ul> <li><code>presentation_definition.format</code>: <code>ldp_vp</code></li> <li><code>presentation_definition.format.proof_type</code>: <code>JsonWebSignature2020</code></li> <li><code>options.challenge</code>: (Optional) a random string value generated by the Verifier</li> <li><code>options.domain</code>: (Optional) a string value specified set by the Verifier</li> </ul> <p>Result:</p> <p>A Verifiable Presentation of type Presentation Submission containing the credentials requested under the <code>verifiableCredential</code> property and a <code>proof</code> property of type <code>JsonWebSignature2020</code>.</p> Example <pre><code>{\n    \"@context\": [\n        \"https://www.w3.org/2018/credentials/v1\",\n        \"https://identity.foundation/presentation-exchange/submission/v1\"\n    ],\n    \"type\": [\n        \"VerifiablePresentation\",\n        \"PresentationSubmission\"\n    ],\n    \"presentation_submission\": {\n        \"descriptor_map\": [{\n           \"id\": \"citizenship_input\",\n           \"path\": \"$.verifiableCredential.[0]\"\n        }]\n    },\n    \"verifiableCredential\": [{\n        \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n        \"id\": \"https://eu.com/claims/DriversLicense\",\n        \"type\": [\n            \"EUDriversLicense\"\n        ],\n        \"issuer\": \"did:foo:123\",\n        \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n        \"credentialSubject\": {\n            \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n            \"license\": {\n            \"number\": \"34DGE352\",\n            \"dob\": \"07/13/80\"\n          }\n        },\n        \"proof\": {\n            \"type\": \"RsaSignature2018\",\n            \"created\": \"2017-06-18T21:19:10Z\",\n            \"proofPurpose\": \"assertionMethod\",\n            \"verificationMethod\": \"https://example.edu/issuers/keys/1\",\n            \"jws\": \"...\"\n        }\n    }],\n    \"proof\": {\n      \"type\": \"JsonWebSignature2020\",\n      \"proofPurpose\": \"authentication\",\n      \"created\": \"2017-09-23T20:21:34Z\",\n      \"verificationMethod\": \"did:example:123456#key1\",\n      \"challenge\": \"2bbgh3dgjg2302d-d2b3gi423d42\",\n      \"domain\": \"example.org\",\n      \"jws\": \"eyJ0eXAiOiJK...gFWFOEjXk\"\n  }\n}\n</code></pre> <p>Available JOSE key types are:</p> kty crv signature EC P-256 ES256 EC P-384 ES384"},{"location":"aip2/0510-dif-pres-exch-attach/#drawbacks","title":"Drawbacks","text":"<p>N/A</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>The <code>hlindy-zkp-v1.0</code> format is an alternative restricted to the Hyperledger Indy network.</li> </ul>"},{"location":"aip2/0510-dif-pres-exch-attach/#prior-art","title":"Prior art","text":"<ul> <li>OAuth 2.0 Rich Authorization Requests:   Provides a coarse object structure that implementers must extend to support their needs. Presentation Exchange   provides a rich set of operators out of the box.</li> </ul>"},{"location":"aip2/0510-dif-pres-exch-attach/#unresolved-questions","title":"Unresolved questions","text":"<p>TODO it is assumed the Verifier will initiate the protocol if they can transmit their presentation definition via an out-of-band channel  (eg. it is published on their website) with a <code>request-presentation</code> message, possibly delivered via an Out-of-Band invitation  (see RFC0434). For now, the Prover sends <code>propose-presentation</code> as a response to <code>request-presentation</code>.</p>"},{"location":"aip2/0510-dif-pres-exch-attach/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0519-goal-codes/","title":"0519: Goal Codes","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Used in several protocols that are part of AIP 2.0, such as the Out-of-Band protocol.</li> <li>Start Date: 2020-01-01</li> <li>Tags: concept</li> </ul>"},{"location":"aip2/0519-goal-codes/#summary","title":"Summary","text":"<p>Explain how different parties in an SSI ecosystem can communicate about their intentions in a way that is understandable by humans and by automated software.</p>"},{"location":"aip2/0519-goal-codes/#motivation","title":"Motivation","text":"<p>Agents exist to achieve the intents of their owners. Those intents largely unfold through protocols. Sometimes intelligent action in these protocols depends on a party declaring their intent. We need a standard way to do that.</p>"},{"location":"aip2/0519-goal-codes/#tutorial","title":"Tutorial","text":"<p>Our early learnings in SSI focused on VC-based proving with a very loose, casual approach to context. We did demos where Alice connects with a potential employer, Acme Corp -- and we assumed that each of the interacting parties had a shared understanding of one another's needs and purposes.</p> <p>But in a mature SSI ecosystem, where unknown agents can contact one another for arbitrary reasons, this context is not always easy to deduce. Acme Corp's agent may support many different protocols, and Alice may interact with Acme in the capacity of customer or potential employee or vendor. Although we have feature discovery to learn what's possible, and we have machine-readable governance frameworks to tell us what rules might apply in a given context, we haven't had a way to establish the context in the first place. When Alice contacts Acme, a context is needed before a governance framework is selectable, and before we know which ../../features are desirable.</p> <p>The key ingredient in context is intent. If Alice says to Acme, \"I'd like to connect,\", Acme wants to be able to trigger different behavior depending on whether Alice's intent is to be a customer, apply for a job, or audit Acme's taxes. This is the purpose of a goal code.</p>"},{"location":"aip2/0519-goal-codes/#the-goal-code-datatype","title":"The goal code datatype","text":"<p>To express intent, this RFC formally introduces the goal code datatype. When a field in a DIDComm message contains a goal code, its semantics and format match the description given here. (Goal codes are often declared via the <code>~thread</code> decorator, but may also appear in ordinary message fields. See the Scope section below. Convention is to name this field \"goal_code\" where possible; however, this is only a convention, and individual protocols may adapt to it however they wish.)</p> <p>TODO: should we make a decorator out of this, so protocols don't have to declare it, and so any message can have a goal code? Or should we just let protocols declare a field in whatever message makes sense?</p> <p>Protocols use fields of this type as a way to express the intent of the message sender, thus coloring the larger context. In a sense, goal codes are to DIDComm what the <code>subject:</code> field is to email -- except that goal codes have formalized meanings to make them recognizable to automation.</p> <p>Goal codes use a standard format. They are lower-cased, kebab-punctuated strings. ASCII and English are recommended, as they are intended to be read by the software developer community, not by human beings; however, full UTF-8 is allowed. They support hierarchical dotted notation, where more general categories are to the left of a dot, and more specific categories are to the right. Some example goal codes might be:</p> <ul> <li><code>aries.sell.consumer.fitness</code></li> <li><code>meetupcorp.personal.date</code></li> <li><code>dif.employment.check-references</code></li> <li><code>cci.healthcare.arrange</code></li> </ul> <p>Goals are inherently self-attested. Thus, goal codes don't represent objective fact that a recipient can rely upon in a strong sense; subsequent interactions can always yield surprises. Even so, goal codes let agents triage interactions and find misalignments early; there's no point in engaging if their goals are incompatible. This has significant benefits for spam prevention, among other things.</p>"},{"location":"aip2/0519-goal-codes/#verbs","title":"Verbs","text":"<p>Notice the verbs in the examples: <code>sell</code>, <code>date</code>, <code>hire</code>, and <code>arrange</code>. Goals typically involve action; a complete goal code should have one or more verbs in it somewhere. Turning verbs into nouns (e.g., <code>employment.references</code> instead of <code>employment.check-references</code>) is considered bad form. (Some namespaces may put the verbs at the end; some may put them in the middle. That's a purely stylistic choice.)</p>"},{"location":"aip2/0519-goal-codes/#directionality","title":"Directionality","text":"<p>Notice, too, that the verbs may imply directionality. A goal with the <code>sell</code> verb implies that the person announcing the goal is a would-be seller, not a buyer. We could imagine a more general verb like <code>engage-in-commerce</code> that would allow either behavior. However, that would often be a mistake. The value of goal codes is that they let agents align around intent; announcing that you want to engage in general commerce without clarifying whether you intend to sell or buy may be too vague to help the other party make decisions. </p> <p>It is conceivable that this would lead to parallel branchs of a goal ontology that differ only in the direction of their verb. Thus, we could imagine <code>sell.A</code> and <code>sell.B</code> being shadowed by <code>buy.A</code> and <code>buy.B</code>. This might be necessary if a family of protocols allow either party to initiate an interaction and declare the goal, and if both parties view the goals as perfect mirror images. However, practical considerations may make this kind of parallelism unlikely. A random party contacting an individual to sell something may need to be quite clear about the type of selling they intend, to make it past a spam filter. In contrast, a random individual arriving at the digital storefront of a mega retailer may be quite vague about the type of buying they intend. Thus, the <code>buy.*</code> side of the namespace may need much less detail than the <code>sell.*</code> side.</p>"},{"location":"aip2/0519-goal-codes/#goals-for-others","title":"Goals for others","text":"<p>Related to directionality, it may occasionally be desirable to propose goals to others, rather than adovcating your own: \"Let &lt;parties = us = Alice, Bob, and Carol&gt; &lt;goal = hold an auction&gt; -- I nominate Carol to be the &lt;role = auctioneer&gt; and get us started.\" The difference between a normal message and an unusual one like this is not visible in the goal code; it should be exposed in additional fields that associate the goal with a particular identifier+role pair. Essentially, you are proposing a goal to another party, and these extra fields clarify who should receive the proposal, and what role/perspective they might take with respect to the goal.</p> <p>Making proposals like this may be a feature in some protocols. Where it is, the protocols determine the message field names for the goal code, the role, and the DID associated with the role and goal.</p>"},{"location":"aip2/0519-goal-codes/#matching","title":"Matching","text":"<p>The goal code <code>cci.healthcare</code> is considered a more general form of the code <code>cci.healthcare.procedure</code>, which is more general than <code>cci.healthcare.procedure.schedule</code>. Because these codes are hierarchical, wildcards and fuzzy matching are possible for either a sender or a recipient of a message. Filename-style globbing semantics are used.</p> <p>A sender agent can specify that their owner's goal is just <code>meetupcorp.personal</code> without clarifying more; this is like specifying that a file is located under a folder named \"meetupcorp/personal\" without specifying where; any file \"under\" that folder -- or the folder itself -- would match the pattern. A recipient agent can have a policy that says, \"Reject any attempts to connect if the goal code of the other party is <code>aries.sell.*</code>. Notice how this differs from <code>aries.sell*</code>; the first looks for things \"inside\" <code>aries.sell</code>; the latter looks for things \"inside\" <code>aries</code> that have names beginning with <code>sell</code>.</p>"},{"location":"aip2/0519-goal-codes/#scope","title":"Scope","text":"<p>When is a declared goal known to color interactions, and when is it undefined? </p> <p>We previously noted that goal codes are a bit like the <code>subject:</code> header on an email; they contextualize everything that follows in that thread. We don't generally want to declare a goal outside of a thread context, because that would prevent an agent from engaging in two goals at the same time.</p> <p>Given these two observations, we can say that a goal applies as soon as it is declared, and it continues to apply to all messages in the same thread. It is also inherited by implication through a thread's <code>pthid</code> field; that is, a parent thread's goal colors the child thread unless/until overridden.</p>"},{"location":"aip2/0519-goal-codes/#namespacing","title":"Namespacing","text":"<p>To avoid collision and ambiguity in code values, we need to support namespacing in our goal codes. Since goals are only a coarse-grained alignment mechanism, however, we don't need perfect decentralized precision. Confusion isn't much more than an annoyance; the worst that could happen is that two agents discover one or two steps into a protocol that they're not as aligned as they supposed. They need to be prepared to tolerate that outcome in any case.</p> <p>Thus, we follow the same general approach that's used in java's packaging system, where organizations and communities use a self-declared prefix for their ecosystem as the leftmost segment or segments of a family of identifiers (goal codes) they manage. Unlike java, though, these need not be tied to DNS in any way. We recommend a single segment namespace that is a unique string, and that is an alias for a URI identifying the origin ecosystem. (In other words, you don't need to start with \"com.yourcorp.yourproduct\" -- \"yourcorp\" is probably fine.)</p> <p>The <code>aries</code> namespace alias is reserved for goal codes defined in Aries RFCs. The URI aliased by this name is TBD. See the Reference section for more details.</p>"},{"location":"aip2/0519-goal-codes/#versioning","title":"Versioning","text":"<p>Semver-style semantics don't map to goals in an simple way; it is not obvious what constitutes a \"major\" versus a \"minor\" difference in a goal, or a difference that's not worth tracking at all. The content of a goal \u2014 the only thing that might vary across versions \u2014 is simply its free-form description, and that varies according to human judgment. Many different versions of a protocol are likely to share the goal to make a payment or to introduce two strangers. A goal is likely to be far more stable than the details of how it is accomplished.</p> <p>Because of these considerations, goal codes do not impose an explicit versioning mechanism. However, one is reserved for use, in the unusual cases where it may be helpful. It is to append <code>-v</code> plus a numeric suffix: <code>my-goal-code-v1</code>, <code>my-goal-code-v2</code>, etc. Goal codes that vary only by this suffix should be understood as ordered-by-numeric-suffix evolutions of one another, and goal codes that do not intend to express versioning should not use this convention for something else. A variant of the goal code without any version suffix is equivalent to a variant with the <code>-v1</code> suffix. This allows human intuition about the relatedness of different codes, and it allows useful wildcard matching across versions. It also treats all version-like changes to a goal as breaking (semver \"major\") changes, which is probably a safe default.</p> <p>Families of goal codes are free to use this convention if they need it, or to invent a non-conflicting one of their own. However, we repeat our observation that versioning in goal codes is often inappropriate and unnecessary.</p>"},{"location":"aip2/0519-goal-codes/#declaring-goal-codes","title":"Declaring goal codes","text":""},{"location":"aip2/0519-goal-codes/#standalone-rfcs-or-similar-sources","title":"Standalone RFCs or Similar Sources","text":"<p>Any URI-referencable document can declare famlies or ontologies of goal codes. In the context of Aries, we encourage standalone RFCs for this purpose if the goals seem likely to be relevant in many contexts. Other communities may of course document goal codes in their own specs -- either dedicated to goal codes, or as part of larger topics. The following block is a sample of how we recommend that such goal codes be declared. Note that each code is individually hyperlink-able, and each is associated with a brief human-friendly description in one or more languages. This description may be used in menuing mechanisms such as the one described in Action Menu Protocol.</p>"},{"location":"aip2/0519-goal-codes/#goal-codes","title":"goal codes","text":""},{"location":"aip2/0519-goal-codes/#ariessell","title":"<code>aries.sell</code>","text":"<p>en: Sell something. Assumes two parties (buyer/seller). es: Vender algo. Asume que dos partes participan (comprador/vendedor).</p>"},{"location":"aip2/0519-goal-codes/#ariessellgoodsconsumer","title":"<code>aries.sell.goods.consumer</code>","text":"<p>en: Sell tangible goods of interest to general consumers.</p>"},{"location":"aip2/0519-goal-codes/#ariessellservicesconsumer","title":"<code>aries.sell.services.consumer</code>","text":"<p>en: Sell services of interest to general consumers.</p>"},{"location":"aip2/0519-goal-codes/#ariessellservicesenterprise","title":"<code>aries.sell.services.enterprise</code>","text":"<p>en: Sell services of interest to enterprises.</p>"},{"location":"aip2/0519-goal-codes/#in-didcomm-based-protocol-specs","title":"In DIDComm-based Protocol Specs","text":"<p>Occasionally, goal codes may have meaning only within the context of a specific protocol. In such cases, it may be appropriate to declare the goal codes directly in a protocol spec. This can be done using a section of the RFC as described above.</p> <p>More commonly, however, a protocol will accomplish one or more goals (e.g., when the protocol is fulfilling a co-protocol interface), or will require a participant to identify a goal at one or more points in a protocol flow. In such cases, the goal codes are probably declared external to the protocol. If they can be enumerated, they should still be referenced (hyperlinked to their respective definitions) in the protocol RFC.</p>"},{"location":"aip2/0519-goal-codes/#in-governance-frameworks","title":"In Governance Frameworks","text":"<p>Goal codes can also be (re-)declared in a machine-readable governance framework. </p>"},{"location":"aip2/0519-goal-codes/#reference","title":"Reference","text":""},{"location":"aip2/0519-goal-codes/#known-namespace-aliases","title":"Known Namespace Aliases","text":"<p>No central registry of namespace aliases is maintained; you need not register with an authority to create a new one. Just pick an alias with good enough uniqueness, and socialize it within your community. For convenience of collision avoidance, however, we maintain a table of aliases that are typically used in global contexts, and welcome PRs from anyone who wants to update it.</p> alias used by URI aries Hyperledger Aries Community TBD"},{"location":"aip2/0519-goal-codes/#well-known-goal-codes","title":"Well-known goal codes","text":"<p>The following goal codes are defined here because they already have demonstrated utility, based on early SSI work in Aries and elsewhere.</p>"},{"location":"aip2/0519-goal-codes/#ariesvc","title":"<code>aries.vc</code>","text":"<p>Participate in some form of VC-based interaction. </p>"},{"location":"aip2/0519-goal-codes/#ariesvcissue","title":"<code>aries.vc.issue</code>","text":"<p>Issue a verifiable credential. </p>"},{"location":"aip2/0519-goal-codes/#ariesvcverify","title":"<code>aries.vc.verify</code>","text":"<p>Verify or validate VC-based assertions.</p>"},{"location":"aip2/0519-goal-codes/#ariesvcrevoke","title":"<code>aries.vc.revoke</code>","text":"<p>Revoke a VC.</p>"},{"location":"aip2/0519-goal-codes/#ariesrel","title":"<code>aries.rel</code>","text":"<p>Create, maintain, or end something that humans would consider a relationship. This may be accomplished by establishing, updating or deleting a DIDComm messaging connection that provides a secure communication channel for the relationship. The DIDComm connection itself is not the relationship, but would be used to carry out interactions between the parties to facilitate the relationship.</p>"},{"location":"aip2/0519-goal-codes/#ariesrelbuild","title":"<code>aries.rel.build</code>","text":"<p>Create a relationship. Carries the meaning implied today by a LinkedIn invitation to connect or a Facebook \"Friend\" request. Could be as limited as creating a DIDComm Connection.</p>"},{"location":"aip2/0519-goal-codes/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"aip2/0557-discover-features-v2/","title":"Aries RFC 0557: Discover Features Protocol v2.x","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Update to version 2.0 proposed in conjunction with DIDComm v2 efforts at DIF, where it became clear that we need to discover more than just protocol support of other agents. Included in AIP v2.0.</li> <li>Supersedes: version 1.0 of this protocol in RFC 0031, which was widely referenced in the Aries eocsystem in 2018 and 2019.</li> <li>Start Date: 2018-12-17</li> <li>URI: https://didcomm.org/discover-features/%VER</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"aip2/0557-discover-features-v2/#summary","title":"Summary","text":"<p>Describes how one agent can query another to discover which ../../features it supports, and to what extent.</p>"},{"location":"aip2/0557-discover-features-v2/#motivation","title":"Motivation","text":"<p>Though some agents will support just one feature and will be statically configured to interact with just one other party, many exciting uses of agents are more dynamic and unpredictable. When Alice and Bob meet, they won't know in advance which ../../features are supported by one another's agents. They need a way to find out.</p>"},{"location":"aip2/0557-discover-features-v2/#tutorial","title":"Tutorial","text":"<p>This is version 2.0 of the Discover Features protocol, and its fully qualified PIURI for the Discover Features protocol is:</p> <pre><code>https://didcomm.org/discover-features/2.0\n</code></pre> <p>This version is conceptually similar to version 1.0 of this protocol. It differs in its ability to ask about multiple feature types, and to ask multiple questions and receive multiple answers in a single round trip.</p>"},{"location":"aip2/0557-discover-features-v2/#roles","title":"Roles","text":"<p>There are two roles in the <code>discover-features</code> protocol: <code>requester</code> and <code>responder</code>. Normally, the requester asks the responder about the ../../features it supports, and the responder answers. Each role uses a single message type.</p> <p>It is also possible to proactively disclose ../../features; in this case a requester receives a response without asking for it. This may eliminate some chattiness in certain use cases (e.g., where two-way connectivity is limited).</p>"},{"location":"aip2/0557-discover-features-v2/#states","title":"States","text":"<p>The state progression is very simple. In the normal case, it is simple request-response; in a proactive disclosure, it's a simple one-way notification.</p>"},{"location":"aip2/0557-discover-features-v2/#requester","title":"Requester","text":""},{"location":"aip2/0557-discover-features-v2/#responder","title":"Responder","text":""},{"location":"aip2/0557-discover-features-v2/#messages","title":"Messages","text":""},{"location":"aip2/0557-discover-features-v2/#queries-message-type","title":"<code>queries</code> Message Type","text":"<p>A <code>discover-features/queries</code> message looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/2.0/queries\",\n  \"@id\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\",\n  \"queries\": [\n    { \"feature-type\": \"protocol\", \"match\": \"https://didcomm.org/tictactoe/1.*\" },\n    { \"feature-type\": \"goal-code\", \"match\": \"aries.*\" }\n  ]\n}\n</code></pre> <p>Queries messages contain one or more query objects in the <code>queries</code> array. Each query essentially says, \"Please tell me what ../../features of type X you support, where the feature identifiers match this (potentially wildcarded) string.\" This particular example asks an agent if it supports any 1.x versions of the tictactoe protocol, and if it supports any goal codes that begin with \"aries.\".</p> <p>Implementations of this protocol must recognize the following values for <code>feature-type</code>: <code>protocol</code>, <code>goal-code</code>, <code>gov-fw</code>, <code>didcomm-version</code>, and <code>decorator</code>/<code>header</code>. (The concept known as <code>decorator</code> in DIDComm v1 approximately maps to the concept known as <code>header</code> in DIDComm v2. The two values should be considered synonyms and must both be recognized.) Additional values of <code>feature-type</code> may be standardized by raising a PR against this RFC that defines the new type and increments the minor protocol version number; non-standardized values are also valid, but there is no guarantee that their semantics will be recognized.</p> <p>Identifiers for feature types vary. For protocols, identifiers are PIURIs. For goal codes, identifiers are goal code values. For governance frameworks, identifiers are URIs where the framework is published (typically the <code>data_uri</code> field if machine-readable. For DIDComm versions, identifiers are the URIs where DIDComm versions are developed (<code>https://github.com/hyperledger/aries-rfcs</code> for V1 and <code>https://github.com/decentralized-identity/didcomm-messaging</code> for V2; see \"Detecting DIDComm Versions\" in RFC 0044 for more details).</p> <p>The <code>match</code> field of a query descriptor may use the * wildcard. By itself, a <code>match</code> with just the wildcard says, \"I'm interested in anything you want to share with me.\" But usually, this wildcard will be to match a prefix that's a little more specific, as in the example that matches any 1.x version.</p> <p>Any agent may send another agent this message type at any time. Implementers of agents that intend to support dynamic relationships and rich ../../features are strongly encouraged to implement support for this message, as it is likely to be among the first messages exchanged with a stranger.</p>"},{"location":"aip2/0557-discover-features-v2/#disclosures-message-type","title":"<code>disclosures</code> Message Type","text":"<p>A <code>discover-features/disclosures</code> message looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/2.0/disclosures\",\n  \"~thread\": { \"thid\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\" },\n  \"disclosures\": [\n    {\n      \"feature-type\": \"protocol\",\n      \"id\": \"https://didcomm.org/tictactoe/1.0\",\n      \"roles\": [\"player\"]\n    },\n    {\n      \"feature-type\": \"goal-code\",\n      \"id\": \"aries.sell.goods.consumer\"\n    }\n  ]\n}\n</code></pre> <p>The <code>disclosures</code> field is a JSON array of zero or more disclosure objects that describe a feature. Each descriptor has a <code>feature-type</code> field that contains data corresponding to <code>feature-type</code> in a query object, and an <code>id</code> field that unambiguously identifies a single item of that feature type. When the item is a protocol, the disclosure object may also contain a <code>roles</code> array that enumerates the roles the responding agent can play in the associated protocol. Future feature types may add additional optional fields, though no other fields are being standardized with this version of the RFC.</p> <p>Disclosures messages say, \"Here are some ../../features I support (that matched your queries).\"</p>"},{"location":"aip2/0557-discover-features-v2/#sparse-disclosures","title":"Sparse Disclosures","text":"<p>Disclosures do not have to contain exhaustive detail. For example, the following response omits the optional <code>roles</code> field but may be just as useful as one that includes it:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/2.0/disclosures\",\n  \"~thread\": { \"thid\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\" },\n  \"disclosures\": [\n    {\"feature-type\": \"protocol\", \"id\": \"https://didcomm.org/tictactoe/1.0\"}\n  ]\n}\n</code></pre> <p>Less detail probably suffices because agents do not need to know everything about one another's implementations in order to start an interaction--usually the flow will organically reveal what's needed. For example, the <code>outcome</code> message in the <code>tictactoe</code> protocol isn't needed until the end, and is optional anyway. Alice can start a tictactoe game with Bob and will eventually see whether he has the right idea about <code>outcome</code> messages.</p> <p>The missing <code>roles</code> in this disclosure does not say, \"I support no roles in this protocol.\" It says, \"I support the protocol but I'm providing no detail about specific roles.\" Similar logic applies to any other omitted fields.</p> <p>An empty <code>disclosures</code> array does not say, \"I support no ../../features that match your query.\" It says, \"I'm not disclosing to you that I support any ../../features (that match your query).\" An agent might not tell another that it supports a feature for various reasons, including: the trust that it imputes to the other party based on cumulative interactions so far, whether it's in the middle of upgrading a plugin, whether it's currently under high load, and so forth. And responses to a <code>discover-features</code> query are not guaranteed to be true forever; agents can be upgraded or downgraded, although they probably won't churn in their feature profiles from moment to moment.</p>"},{"location":"aip2/0557-discover-features-v2/#privacy-considerations","title":"Privacy Considerations","text":"<p>Because the wildcards in a <code>queries</code> message can be very inclusive, the <code>discover-features</code> protocol could be used to mine information suitable for agent fingerprinting, in much the same way that browser fingerprinting works. This is antithetical to the ethos of our ecosystem, and represents bad behavior. Agents should use <code>discover-features</code> to answer legitimate questions, and not to build detailed profiles of one another. However, fingerprinting may be attempted anyway.</p> <p>For agents that want to maintain privacy, several best practices are recommended:</p>"},{"location":"aip2/0557-discover-features-v2/#follow-selective-disclosure","title":"Follow selective disclosure.","text":"<p>Only reveal supported ../../features based on trust in the relationship. Even if you support a protocol, you may not wish to use it in every relationship. Don't tell others about ../../features you do not plan to use with them.</p> <p>Patterns are easier to see in larger data samples. However, a pattern of ultra-minimal data is also a problem, so use good judgment about how forthcoming to be.</p>"},{"location":"aip2/0557-discover-features-v2/#vary-the-format-of-responses","title":"Vary the format of responses.","text":"<p>Sometimes, you might prettify your agent plaintext message one way, sometimes another.</p>"},{"location":"aip2/0557-discover-features-v2/#vary-the-order-of-items-in-the-disclosures-array","title":"Vary the order of items in the <code>disclosures</code> array.","text":"<p>If more than one key matches a query, do not always return them in alphabetical order or version order. If you do return them in order, do not always return them in ascending order.</p>"},{"location":"aip2/0557-discover-features-v2/#consider-adding-some-spurious-details","title":"Consider adding some spurious details.","text":"<p>If a query could match multiple ../../features, then occasionally you might add some made-up ../../features as matches. If a wildcard allows multiple versions of a protocol, then sometimes you might use some made-up versions. And sometimes not. (Doing this too aggressively might reveal your agent implementation, so use sparingly.)</p>"},{"location":"aip2/0557-discover-features-v2/#vary-how-you-query-too","title":"Vary how you query, too.","text":"<p>How you ask questions may also be fingerprintable.</p>"},{"location":"aip2/0557-discover-features-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0592-indy-attachments/","title":"Aries RFC 0592: Indy Attachment Formats for Requesting and Presenting Credentials","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Formalizes the Indy AnonCreds attachments for issuing credentials and presenting proofs. A part of the Indy AnonCreds subtarget of AIP v2.0.</li> <li>Supersedes: less formally documented Indy attachment formats documented in Aries RFC 0036, Aries RFC 0037, etc.</li> <li>Start Date: 2017-01-01</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"aip2/0592-indy-attachments/#summary","title":"Summary","text":"<p>This RFC registers attachment formats used with Hyperledger Indy-style ZKP-oriented credentials in Issue Credential Protocol 2.0 and Present Proof Protocol 2.0. These formats are generally considered v2 formats, as they align with the \"anoncreds2\" work in Hyperledger Ursa and are a second generation implementation. They began to be used in production in 2018 and are in active deployment in 2021.</p>"},{"location":"aip2/0592-indy-attachments/#motivation","title":"Motivation","text":"<p>Allows Indy-style credentials to be used with credential-related protocols that take pluggable formats as payloads.</p>"},{"location":"aip2/0592-indy-attachments/#reference","title":"Reference","text":""},{"location":"aip2/0592-indy-attachments/#cred-filter-format","title":"cred filter format","text":"<p>The potential holder uses this format to propose criteria for a potential credential for the issuer to offer.</p> <p>The identifier for this format is <code>hlindy/cred-filter@v2.0</code>. It is a base64-encoded version of the data structure specifying zero or more criteria from the following (non-base64-encoded) structure:</p> <pre><code>{\n    \"schema_issuer_did\": \"&lt;schema_issuer_did&gt;\",\n    \"schema_name\": \"&lt;schema_name&gt;\",\n    \"schema_version\": \"&lt;schema_version&gt;\",\n    \"schema_id\": \"&lt;schema_identifier&gt;\",\n    \"issuer_did\": \"&lt;issuer_did&gt;\",\n    \"cred_def_id\": \"&lt;credential_definition_identifier&gt;\"\n}\n</code></pre> <p>The potential holder may not know, and need not specify, all of these criteria. For example, the holder might only know the schema name and the (credential) issuer DID. Recall that the potential holder may specify target attribute values and MIME types in the credential preview.</p> <p>For example, the JSON (non-base64-encoded) structure might look like this:</p> <pre><code>{\n    \"schema_issuer_did\": \"did:sov:4RW6QK2HZhHxa2tg7t1jqt\",\n    \"schema_name\": \"bcgov-mines-act-permit.bcgov-mines-permitting\",\n    \"issuer_did\": \"did:sov:4RW6QK2HZhHxa2tg7t1jqt\"\n}\n</code></pre> <p>A complete <code>propose-credential</code> message from the Issue Credential protocol 2.0 embeds this format at <code>/filters~attach/data/base64</code>:</p> <pre><code>{\n    \"@id\": \"&lt;uuid of propose message&gt;\",\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/propose-credential\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\" : [{\n        \"attach_id\": \"&lt;attach@id value&gt;\",\n        \"format\": \"hlindy/cred-filter@v2.0\"\n    }],\n    \"filters~attach\": [{\n        \"@id\": \"&lt;attach@id value&gt;\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"base64\": \"ewogICAgInNjaGVtYV9pc3N1ZXJfZGlkIjogImRpZDpzb3Y... (clipped)... LMkhaaEh4YTJ0Zzd0MWpxdCIKfQ==\"\n        }\n    }]\n}\n</code></pre>"},{"location":"aip2/0592-indy-attachments/#cred-abstract-format","title":"cred abstract format","text":"<p>This format is used to clarify the structure and semantics (but not the concrete data values) of a potential credential, in offers sent from issuer to potential holder.</p> <p>The identifier for this format is <code>hlindy/cred-abstract@v2.0</code>. It is a base64-encoded version of the data returned from <code>indy_issuer_create_credential_offer()</code>.</p> <p>The JSON (non-base64-encoded) structure might look like this:</p> <pre><code>{\n    \"schema_id\": \"4RW6QK2HZhHxa2tg7t1jqt:2:bcgov-mines-act-permit.bcgov-mines-permitting:0.2.0\",\n    \"cred_def_id\": \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    \"nonce\": \"57a62300-fbe2-4f08-ace0-6c329c5210e1\",\n    \"key_correctness_proof\" : &lt;key_correctness_proof&gt;\n}\n</code></pre> <p>A complete <code>offer-credential</code> message from the Issue Credential protocol 2.0 embeds this format at <code>/offers~attach/data/base64</code>:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/offer-credential\",\n    \"@id\": \"&lt;uuid of offer message&gt;\",\n    \"replacement_id\": \"&lt;issuer unique id&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\": \"hlindy/cred-abstract@v2.0\"\n        }\n    ],\n    \"offers~attach\": [\n        {\n            \"@id\": \"&lt;attach@id value&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"ewogICAgInNjaGVtYV9pZCI6ICI0Ulc2UUsySFpoS... (clipped)... jb3JyZWN0bmVzc19wcm9vZj4KfQ==\"\n            }\n        }\n    ]\n}\n</code></pre> <p>The same structure can be embedded at <code>/offers~attach/data/base64</code> in an <code>offer-credential</code> message. </p>"},{"location":"aip2/0592-indy-attachments/#cred-request-format","title":"cred request format","text":"<p>This format is used to formally request a credential. It differs from the credential abstract above in that it contains a cryptographic commitment to a link secret; an issuer can therefore use it to bind a concrete instance of an issued credential to the appropriate holder. (In contrast, the credential abstract describes the schema and cred def, but not enough information to actually issue to a specific holder.)</p> <p>The identifier for this format is <code>hlindy/cred-req@v2.0</code>. It is a base64-encoded version of the data returned from indy_prover_create_credential_req().</p> <p>The JSON (non-base64-encoded) structure might look like this:</p> <pre><code>{\n    \"prover_did\" : \"did:sov:abcxyz123\",\n    \"cred_def_id\" : \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    // Fields below can depend on Cred Def type\n    \"blinded_ms\" : &lt;blinded_master_secret&gt;,\n    \"blinded_ms_correctness_proof\" : &lt;blinded_ms_correctness_proof&gt;,\n    \"nonce\": \"fbe22300-57a6-4f08-ace0-9c5210e16c32\"\n}\n</code></pre> <p>A complete <code>request-credential</code> message from the Issue Credential protocol 2.0 embeds this format at <code>/requests~attach/data/base64</code>:</p> <pre><code>{\n    \"@id\": \"cf3a9301-6d4a-430f-ae02-b4a79ddc9706\",\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/request-credential\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\": [{\n        \"attach_id\": \"7cd11894-838a-45c0-a9ec-13e2d9d125a1\",\n        \"format\": \"hlindy/cred-req@v2.0\"\n    }],\n    \"requests~attach\": [{\n        \"@id\": \"7cd11894-838a-45c0-a9ec-13e2d9d125a1\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"base64\": \"ewogICAgInByb3Zlcl9kaWQiIDogImRpZDpzb3Y6YWJjeHl.. (clipped)... DAtNTdhNi00ZjA4LWFjZTAtOWM1MjEwZTE2YzMyIgp9\"\n        }\n    }]\n}\n</code></pre>"},{"location":"aip2/0592-indy-attachments/#credential-format","title":"credential format","text":"<p>A concrete, issued Indy credential may be transmitted over many protocols, but is specifically expected as the final message in Issuance Protocol 2.0. The identifier for its format is <code>hlindy/cred@v2.0</code>.</p> <p>This is a credential that's designed to be held but not shared directly. It is stored in the holder's wallet and used to derive a novel ZKP or W3C-compatible verifiable presentation just in time for each sharing of credential material.</p> <p>The encoded values of the credential MUST follow the encoding algorithm as described in Encoding Claims.</p> <p>This is the format emitted by libindy's indy_issuer_create_credential() function. It is JSON-based and might look like this:</p> <pre><code>{\n    \"schema_id\": \"4RW6QK2HZhHxa2tg7t1jqt:2:bcgov-mines-act-permit.bcgov-mines-permitting:0.2.0\",\n    \"cred_def_id\": \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    \"rev_reg_id\", \"EyN78DDGHyok8qw6W96UBY:4:EyN78DDGHyok8qw6W96UBY:3:CL:56389:CardossierOrgPerson:CL_ACCUM:1-1000\",\n    \"values\": {\n        \"attr1\" : {\"raw\": \"value1\", \"encoded\": \"value1_as_int\" },\n        \"attr2\" : {\"raw\": \"value2\", \"encoded\": \"value2_as_int\" }\n    },\n    // Fields below can depend on Cred Def type\n    \"signature\": &lt;signature&gt;,\n    \"signature_correctness_proof\": &lt;signature_correctness_proof&gt;\n    \"rev_reg\": &lt;revocation registry state&gt;\n    \"witness\": &lt;witness&gt;\n}\n</code></pre> <p>An exhaustive description of the format is out of scope here; it is more completely documented in white papers, source code, and other Indy materials.</p>"},{"location":"aip2/0592-indy-attachments/#proof-request-format","title":"proof request format","text":"<p>This format is used to formally request a verifiable presenation (proof) derived from an Indy-style ZKP-oriented credential. It can also be used by a holder to propose a presentation.</p> <p>The identifier for this format is <code>hlindy/proof-req@v2.0</code>. It is a base64-encoded version of the data returned from indy_prover_search_credentials_for_proof_req().</p> <p>Here is a sample proof request that embodies the following: \"Using a government-issued ID, disclose the credential holder\u2019s name and height, hide the credential holder\u2019s sex, get them to self-attest their phone number, and prove that their age is at least 18\":</p> <pre><code>{\n    \"nonce\": \u201c2934823091873049823740198370q23984710239847\u201d, \n    \"name\":\"proof_req_1\",\n    \"version\":\"0.1\",\n    \"requested_attributes\":{\n        \"attr1_referent\": {\"name\":\"sex\"},\n        \"attr2_referent\": {\"name\":\"phone\"},\n        \"attr3_referent\": {\"names\": [\"name\", \"height\"], \"restrictions\": &lt;restrictions specifying government-issued ID&gt;}\n    },\n    \"requested_predicates\":{\n        \"predicate1_referent\":{\"name\":\"age\",\"p_type\":\"&gt;=\",\"p_value\":18}\n    }\n}\n</code></pre>"},{"location":"aip2/0592-indy-attachments/#proof-format","title":"proof format","text":"<p>This is the format of an Indy-style ZKP. It plays the same role as a W3C-style verifiable presentation (VP) and can be mapped to one.</p> <p>The raw values encoded in the presentation SHOULD be verified against the encoded values using the encoding algorithm as described below in Encoding Claims.</p> <p>The identifier for this format is <code>hlindy/proof@v2.0</code>. It is a version of the (JSON-based) data emitted by libindy's indy_prover_create_proof()) function. A proof that responds to the previous proof request sample looks like this:</p> <pre><code>{\n  \"proof\":{\n    \"proofs\":[\n      {\n        \"primary_proof\":{\n          \"eq_proof\":{\n            \"revealed_attrs\":{\n              \"height\":\"175\",\n              \"name\":\"1139481716457488690172217916278103335\"\n            },\n            \"a_prime\":\"5817705...096889\",\n            \"e\":\"1270938...756380\",\n            \"v\":\"1138...39984052\",\n            \"m\":{\n              \"master_secret\":\"375275...0939395\",\n              \"sex\":\"3511483...897083518\",\n              \"age\":\"13430...63372249\"\n            },\n            \"m2\":\"1444497...2278453\"\n          },\n          \"ge_proofs\":[\n            {\n              \"u\":{\n                \"1\":\"152500...3999140\",\n                \"2\":\"147748...2005753\",\n                \"0\":\"8806...77968\",\n                \"3\":\"10403...8538260\"\n              },\n              \"r\":{\n                \"2\":\"15706...781609\",\n                \"3\":\"343...4378642\",\n                \"0\":\"59003...702140\",\n                \"DELTA\":\"9607...28201020\",\n                \"1\":\"180097...96766\"\n              },\n              \"mj\":\"134300...249\",\n              \"alpha\":\"827896...52261\",\n              \"t\":{\n                \"2\":\"7132...47794\",\n                \"3\":\"38051...27372\",\n                \"DELTA\":\"68025...508719\",\n                \"1\":\"32924...41082\",\n                \"0\":\"74906...07857\"\n              },\n              \"predicate\":{\n                \"attr_name\":\"age\",\n                \"p_type\":\"GE\",\n                \"value\":18\n              }\n            }\n          ]\n        },\n        \"non_revoc_proof\":null\n      }\n    ],\n    \"aggregated_proof\":{\n      \"c_hash\":\"108743...92564\",\n      \"c_list\":[ 6 arrays of 257 numbers between 0 and 255]\n    }\n  },\n  \"requested_proof\":{\n    \"revealed_attrs\":{\n      \"attr1_referent\":{\n        \"sub_proof_index\":0,\n        \"raw\":\"Alex\",\n        \"encoded\":\"1139481716457488690172217916278103335\"\n      }\n    },\n    \"revealed_attr_groups\":{\n      \"attr4_referent\":{\n        \"sub_proof_index\":0,\n        \"values\":{\n          \"name\":{\n            \"raw\":\"Alex\",\n            \"encoded\":\"1139481716457488690172217916278103335\"\n          },\n          \"height\":{\n            \"raw\":\"175\",\n            \"encoded\":\"175\"\n          }\n        }\n      }\n    },\n    \"self_attested_attrs\":{\n      \"attr3_referent\":\"8-800-300\"\n    },\n    \"unrevealed_attrs\":{\n      \"attr2_referent\":{\n        \"sub_proof_index\":0\n      }\n    },\n    \"predicates\":{\n      \"predicate1_referent\":{\n        \"sub_proof_index\":0\n      }\n    }\n  },\n  \"identifiers\":[\n    {\n      \"schema_id\":\"NcYxiDXkpYi6ov5FcYDi1e:2:gvt:1.0\",\n      \"cred_def_id\":\"NcYxi...cYDi1e:2:gvt:1.0:TAG_1\",\n      \"rev_reg_id\":null,\n      \"timestamp\":null\n    }\n  ]\n}\n</code></pre>"},{"location":"aip2/0592-indy-attachments/#unrevealed-attributes","title":"Unrevealed Attributes","text":"<p>AnonCreds supports a holder responding to a proof request with some of the requested claims included in an <code>unrevealed_attrs</code> array, as seen in the example above, with <code>attr2_referent</code>. Assuming the rest of the proof is valid, AnonCreds will indicate that a proof with unrevealed attributes has been successfully verified. It is the responsibility of the verifier to determine if the purpose of the verification has been met if some of the attributes are not revealed.</p> <p>There are at least a few valid use cases for this approach:</p> <ul> <li>A verifier may ask for, but not require, that a prover provide all of the   requested attributes.</li> <li>A verifier may ask for claims from several credentials, expecting holders to   only have some of the credentials. The holders respond with claims from the   credentials they have, and leave the other attributes unrevealed.</li> <li>For example, a verifier may ask for a national identity card and an resident     card, knowing that most holders will have one or the other.</li> </ul>"},{"location":"aip2/0592-indy-attachments/#encoding-claims","title":"Encoding Claims","text":"<p>Claims in AnonCreds-based verifiable credentials are put into the credential in two forms, <code>raw</code> and <code>encoded</code>. <code>raw</code> is the actual data value, and <code>encoded</code> is the (possibly derived) integer value that is used in presentations. At this time, AnonCreds does not take an opinion on the method used for encoding the raw value.</p> <p>AnonCreds issuers and verifiers must agree on the encoding method so that the verifier can check that the <code>raw</code> value returned in a presentation corresponds to the proven <code>encoded</code> value. The following is the encoding algorithm that MUST be used by Issuers when creating credentials and SHOULD be verified by Verifiers receiving presentations:</p> <ul> <li>keep any 32-bit integer as is</li> <li>convert any string integer (e.g. <code>\"1234\"</code>) to be a 32-bit integer (e.g. <code>1234</code>)</li> <li>for data of any other type:</li> <li>convert to string (use string \"None\" for null)</li> <li>encode via utf-8 to bytes</li> <li>apply SHA-256 to digest the bytes</li> <li>convert the resulting digest bytes, big-endian, to integer</li> <li>stringify the integer as a decimal.</li> </ul> <p>An example implementation in Python can be found here.</p> <p>A gist of test value pairs can be found here.</p>"},{"location":"aip2/0592-indy-attachments/#notes-on-encoding-claims","title":"Notes on Encoding Claims","text":"<ul> <li>In converting any string integer to an integer, leading 0s in the string are (by definition) not part of the integer. The leading 0's remain in the (untouched) <code>raw</code> value.</li> <li>The use of AnonCreds predicates, such as proving \"older than 21\" based on a date of birth claim without sharing the date of birth, is based on an expression involving the <code>encoded</code> value. Thus, only <code>raw</code> integers or string integers can be used in AnonCreds predicates.</li> </ul>"},{"location":"aip2/0592-indy-attachments/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"aip2/0593-json-ld-cred-attach/","title":"Aries RFC 0593: JSON-LD Credential Attachment format for requesting and issuing credentials","text":"<ul> <li>Authors: Timo Glastra (Animo Solutions), George Aristy (SecureKey Technologies)</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Included as part of the JSON-LD verifiable credentials subtarget of AIP v2.0.</li> <li>Supersedes:</li> <li>Start Date: 2021-02-17</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"aip2/0593-json-ld-cred-attach/#summary","title":"Summary","text":"<p>This RFC registers an attachment format for use in the issue-credential V2 protocol based on JSON-LD credentials with Linked Data Proofs from the VC Data Model.</p> <p>It defines a minimal set of parameters needed to create a common understanding of the verifiable credential to issue. It is based on version 1.0 of the Verifiable Credentials Data Model which is a W3C recommendation since 19 November 2019.</p>"},{"location":"aip2/0593-json-ld-cred-attach/#motivation","title":"Motivation","text":"<p>The Issue Credential protocol needs an attachment format to be able to exchange JSON-LD credentials with Linked Data Proofs. It is desirable to make use of specifications developed in an open standards body, such as the Credential Manifest for which the attachment format is described in RFC 0511: Credential-Manifest Attachment format. However, the Credential Manifest is not finished and ready yet, and therefore there is a need to bridge the gap between standards.</p>"},{"location":"aip2/0593-json-ld-cred-attach/#tutorial","title":"Tutorial","text":"<p>Complete examples of messages are provided in the reference section.</p>"},{"location":"aip2/0593-json-ld-cred-attach/#reference","title":"Reference","text":""},{"location":"aip2/0593-json-ld-cred-attach/#ld-proof-vc-detail-attachment-format","title":"<code>ld-proof-vc-detail</code> attachment format","text":"<p>Format identifier: <code>aries/ld-proof-vc-detail@v1.0</code></p> <p>This format is used to formally propose, offer, or request a credential. The <code>credential</code> property should contain the credential as it is going to be issued, without the <code>proof</code> and <code>credentialStatus</code> properties. Options for these properties are specified in the <code>options</code> object.</p> <p>The JSON structure might look like this:</p> <pre><code>{\n  \"credential\": {\n    \"@context\": [\n      \"https://www.w3.org/2018/credentials/v1\",\n      \"https://www.w3.org/2018/credentials/examples/v1\"\n    ],\n    \"id\": \"urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5\",\n    \"type\": [\"VerifiableCredential\", \"UniversityDegreeCredential\"],\n    \"issuer\": \"did:key:z6MkodKV3mnjQQMB9jhMZtKD9Sm75ajiYq51JDLuRSPZTXrr\",\n    \"issuanceDate\": \"2020-01-01T19:23:24Z\",\n    \"expirationDate\": \"2021-01-01T19:23:24Z\",\n    \"credentialSubject\": {\n      \"id\": \"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\",\n      \"degree\": {\n        \"type\": \"BachelorDegree\",\n        \"name\": \"Bachelor of Science and Arts\"\n      }\n    }\n  },\n  \"options\": {\n    \"proofPurpose\": \"assertionMethod\",\n    \"created\": \"2020-04-02T18:48:36Z\",\n    \"domain\": \"example.com\",\n    \"challenge\": \"9450a9c1-4db5-4ab9-bc0c-b7a9b2edac38\",\n    \"credentialStatus\": {\n      \"type\": \"CredentialStatusList2017\"\n    },\n    \"proofType\": \"Ed25519Signature2018\"\n  }\n}\n</code></pre> <p>A complete <code>request credential</code> message form the Issue Credential protocol 2.0 might look like this:</p> <pre><code>{\n  \"@id\": \"7293daf0-ed47-4295-8cc4-5beb513e500f\",\n  \"@type\": \"https://didcomm.org/issue-credential/%VER/request-credential\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"13a3f100-38ce-4e96-96b4-ea8f30250df9\",\n      \"format\": \"aries/ld-proof-vc-detail@v1.0\"\n    }\n  ],\n  \"requests~attach\": [\n    {\n      \"@id\": \"13a3f100-38ce-4e96-96b4-ea8f30250df9\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"ewogICJjcmVkZW50aWFsIjogewogICAgIkBjb250...(clipped)...IkVkMjU1MTlTaWduYXR1cmUyMDE4IgogIH0KfQ==\"\n      }\n    }\n  ]\n}\n</code></pre> <ul> <li> <p><code>credential</code> - Required. Detail of the JSON-LD Credential that will be issued. Properties MUST align with the Verifiable Credentials Data Model. This also means all properties required by the data model MUST be present. The properties listed below are formally supported, but additional properties MAY be included if it conforms with the data model.</p> </li> <li> <p><code>@context</code></p> </li> <li><code>id</code></li> <li><code>type</code></li> <li><code>issuer</code></li> <li><code>issuanceDate</code></li> <li><code>expirationDate</code></li> <li> <p><code>credentialSubject</code></p> </li> <li> <p><code>options</code> - Required. Options for specifying how the linked data proof is created.</p> </li> <li> <p><code>proofType</code> - Required string. The proof type used for the proof. Should match suites registered in the Linked Data Cryptographic Suite Registry.</p> </li> <li><code>proofPurpose</code> - Optional string, default <code>assertionMethod</code>. The proof purpose used for the proof. Should match proof purposes registered in the Linked Data Proofs Specification.</li> <li><code>created</code> - Optional string, default current system time. The date and time of the proof (with a maximum accuracy in seconds).</li> <li><code>challenge</code> - Optional string. A challenge to include in the proof. SHOULD be provided by the requesting party of the credential (=holder).</li> <li><code>domain</code> - Optional string. The intended domain of validity for the proof.</li> <li><code>credentialStatus</code> - Optional object. The credential status mechanism to use for the credential. Omitting the property indicates the issued credential will not include a credential status.<ul> <li><code>type</code> - Required string. Credential status method type to use for the credential. Should match status method registered in the Verifiable Credential Extension Registry</li> </ul> </li> </ul> <p>The format is closely related to the Verifiable Credentials HTTP API, but diverts on some places. The main differences are:</p> <ul> <li>The types in the VC HTTP API are more restrictive (.e.g. <code>@context</code> must be array of strings). This format allows all fields to use the full syntax as described by the verifiable credentials data model.</li> <li>Instead of specifying the exact <code>verificationMethod</code>, the <code>proofType</code> that will be used for the credential can be specified.</li> </ul>"},{"location":"aip2/0593-json-ld-cred-attach/#ld-proof-vc-attachment-format","title":"<code>ld-proof-vc</code> attachment format","text":"<p>Format identifier: <code>aries/ld-proof-vc@v1.0</code></p> <p>This format is used to transmit a verifiable credential with linked data proof. The contents of the attachment is a standard JSON-LD Verifiable Credential object with linked data proof as defined by the Verifiable Credentials Data Model and the Linked Data Proofs specification.</p> <p>The JSON structure might look like this:</p> <pre><code>{\n  \"@context\": [\n    \"https://www.w3.org/2018/credentials/v1\",\n    \"https://www.w3.org/2018/credentials/examples/v1\"\n  ],\n  \"id\": \"http://example.gov/credentials/3732\",\n  \"type\": [\"VerifiableCredential\", \"UniversityDegreeCredential\"],\n  \"issuer\": {\n    \"id\": \"did:web:vc.transmute.world\"\n  },\n  \"issuanceDate\": \"2020-03-10T04:24:12.164Z\",\n  \"credentialSubject\": {\n    \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n    \"degree\": {\n      \"type\": \"BachelorDegree\",\n      \"name\": \"Bachelor of Science and Arts\"\n    }\n  },\n  \"proof\": {\n    \"type\": \"JsonWebSignature2020\",\n    \"created\": \"2020-03-21T17:51:48Z\",\n    \"verificationMethod\": \"did:web:vc.transmute.world#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A\",\n    \"proofPurpose\": \"assertionMethod\",\n    \"jws\": \"eyJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdLCJhbGciOiJFZERTQSJ9..OPxskX37SK0FhmYygDk-S4csY_gNhCUgSOAaXFXDTZx86CmI5nU9xkqtLWg-f4cqkigKDdMVdtIqWAvaYx2JBA\"\n  }\n}\n</code></pre> <p>A complete <code>issue-credential</code> message from the Issue Credential protocol 2.0 might look like this:</p> <pre><code>{\n  \"@id\": \"284d3996-ba85-45d9-964b-9fd5805517b6\",\n  \"@type\": \"https://didcomm.org/issue-credential/%VER/issue-credential\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"5b38af88-d36f-4f77-bb7a-2f04ab806eb8\",\n      \"format\": \"aries/ld-proof-vc@v1.0\"\n    }\n  ],\n  \"credentials~attach\": [\n    {\n      \"@id\": \"5b38af88-d36f-4f77-bb7a-2f04ab806eb8\",\n      \"mime-type\": \"application/ld+json\",\n      \"data\": {\n        \"base64\": \"ewogICAgICAgICAgIkBjb250ZXogWwogICAgICAg...(clipped)...RNVmR0SXFXZhWXgySkJBIgAgfQogICAgICAgIH0=\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"aip2/0593-json-ld-cred-attach/#supported-proof-types","title":"Supported Proof Types","text":"<p>Following are the Linked Data proof types on Verifiable Credentials that MUST be supported for compliance with this RFC. All suites listed in the following table MUST be registered in the Linked Data Cryptographic Suite Registry:</p> Suite Spec Enables Selective disclosure? Enables Zero-knowledge proofs? Optional Ed25519Signature2018 Link No No No BbsBlsSignature2020** Link Yes No No JsonWebSignature2020*** Link No No Yes <p>** Note: see RFC0646 for details on how BBS+ signatures are to be produced and consumed by Aries agents.</p> <p>*** Note: P-256 and P-384 curves are supported.</p>"},{"location":"aip2/0593-json-ld-cred-attach/#drawbacks","title":"Drawbacks","text":"<p>N/A</p>"},{"location":"aip2/0593-json-ld-cred-attach/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>The <code>hlindy-zkp-v1.0</code> format is an alternative restricted to the Hyperledger Indy network. The <code>dif/credential-manifest@v1.0</code> allows to issue JSON-LD credentials but is not ready yet for usage.</li> </ul>"},{"location":"aip2/0593-json-ld-cred-attach/#prior-art","title":"Prior art","text":"<p>N/A</p>"},{"location":"aip2/0593-json-ld-cred-attach/#unresolved-questions","title":"Unresolved questions","text":"<p>N/A</p>"},{"location":"aip2/0593-json-ld-cred-attach/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0003-protocols/","title":"Aries RFC 0003: Protocols","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-04-01</li> <li>Status Note: standards track and beginning to influence many mental models, but not yet ADOPTED.</li> <li>Supersedes: Indy PR #69</li> <li>Start Date: 2018-12-28</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0003-protocols/#summary","title":"Summary","text":"<p>Defines peer-to-peer application-level protocols in the context of interactions among agent-like things, and shows how they should be designed and documented.</p> <p></p>"},{"location":"concepts/0003-protocols/#table-of-contents","title":"Table of Contents","text":"<ul> <li>Aries RFC 0003: Protocols</li> <li>Summary</li> <li>Motivation</li> <li>Tutorial<ul> <li>What is a Protocol?</li> <li>Relationship to APIs</li> <li>Decentralized</li> <li>Types of Protocols</li> <li>Agent Design</li> <li>Composable</li> <li>Message Types</li> <li>Handling Unrecognized Items in Messages</li> <li>Ingredients</li> <li>How to Define a Protocol</li> <li>Security Considerations</li> <li>Replay Attacks</li> </ul> </li> <li>Reference<ul> <li>Message Type and Protocol Identifier URIs</li> <li>MTURI</li> <li>PIURI</li> <li>Semver Rules for Protocols</li> <li>Semver Examples<ul> <li>Initiator</li> <li>Recipient Rules</li> </ul> </li> <li>State Details and State Machines</li> <li>State Machines</li> <li>Processing Points</li> <li>Roles, Participants, Parties, and Controllers</li> <li>Roles</li> <li>Participants</li> <li>Parties</li> <li>Controllers</li> <li>Instructions for Protocol RFCs</li> </ul> </li> <li>Drawbacks</li> <li>Rationale and alternatives</li> <li>Prior art<ul> <li>BPMN</li> <li>WSDL</li> <li>Swagger / OpenAPI</li> <li>Other</li> </ul> </li> <li>Unresolved questions</li> <li>Implementations</li> </ul>"},{"location":"concepts/0003-protocols/#motivation","title":"Motivation","text":"<p>APIs in the style of Swagger are familiar to nearly all developers, and it's a common assumption that we should use them to solve the problems at hand in the decentralized identity space. However, to truly decentralize, we must think about interactions at a higher level of generalization. Protocols can model all APIs, but not the other way around. This matters. We need to explain why.</p> <p>We also need to show how a protocol is defined, so the analog to defining a Swagger API is demystified.</p>"},{"location":"concepts/0003-protocols/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0003-protocols/#what-is-a-protocol","title":"What is a Protocol?","text":"<p>A protocol is a recipe for a stateful interaction. Protocols are all around us, and are so ordinary that we take them for granted. Each of the following interactions is stateful, and has conventions that constitute a sort of \"recipe\":</p> <ul> <li>Ordering food at a restaurant</li> <li>Buying a house</li> <li>Playing a game of chess, checkers, tic-tac-toe, etc.</li> <li>Bidding on an item in an online auction.</li> <li>Going through security at the airport when we fly</li> <li>Applying for a loan</li> </ul> <p>In the context of decentralized identity, protocols manifest at many different levels of the stack: at the lowest levels of networking, in cryptographic algorithms like Diffie Hellman, in the management of DIDs, in the conventions of DIDComm, and in higher-level interactions that solve problems for people with only minimal interest in the technology they're using. However, this RFC focuses on the last of these layers, where use cases and personas are transformed into ../../features with obvious social value like:</p> <ul> <li>Connecting with one another</li> <li>Requesting and issuing credentials</li> <li>Proving things using credentials</li> <li>Discovering things</li> <li>Delegating</li> <li>Buying and Selling</li> <li>Negotiating</li> <li>Enacting and enforcing contracts</li> <li>Putting things in escrow (and taking them out again)</li> <li>Scheduling</li> <li>Auditing</li> <li>Reporting errors</li> <li>Cooperative debugging</li> </ul> <p>When \"protocol\" is used in an Aries context without any qualifying adjective, it is referencing a recipe for a high-level interaction like these. Lower-level protocols are usually described more specifically and possibly with other verbiage: \"cryptographic algorithms\", \"DID management procedures\", \"DIDComm conventions\", \"transports\", and so forth. This helps us focus \"protocol\" on the place where application developers that consume Aries do most of the work that creates value.</p>"},{"location":"concepts/0003-protocols/#relationship-to-apis","title":"Relationship to APIs","text":"<p>The familiar world of web APIs is a world of protocols, but it comes with constraints antithetical to decentralized identity:</p> <ul> <li>It assumes all interactions are between a client and a server--either two parties, or N parties mediated by a central server. Thus, the server is a natural locus for surveillance and hacking.</li> <li>It assumes security is asymmetric--not using DIDs, but driven by certs on a server and by a session for the client.</li> <li>It assumes the transport is HTTP. This is problematic for pure mobile-to-mobile, or for use cases where the transport is complex or asymmetric.</li> <li>Because the server can never initiate an interaction, it requires at least one party to be continuously online.</li> </ul> <p>Protocols impose none of these constraints. Web APIs can easily be modeled as protocols where the transport is HTTP and the payload is a message, and the Aries community actively does this. We are not opposed to APIs. We just want to describe and standardize the higher level abstraction so we don't have a web solution and a BlueTooth solution that are diverged for no good reason.</p>"},{"location":"concepts/0003-protocols/#decentralized","title":"Decentralized","text":"<p>As used in the agent/DIDComm world, protocols are decentralized. This means there is not an overseer for the protocol, guaranteeing information flow, enforcing behaviors, and ensuring a coherent view. It is a subtle but important divergence from API-centric approaches, where a server holds state against which all other parties (clients) operate. Instead, all parties are peers, and they interact by mutual consent and with a (hopefully) shared understanding of the rules and goals. Protocols are like a dance\u2014not one that's choreographed or directed, but one where the parties make dynamic decisions and react to them.</p> <p></p>"},{"location":"concepts/0003-protocols/#types-of-protocols","title":"Types of Protocols","text":"<p>The simplest protocol style is notification. This style involves two parties, but it is one-way: the <code>notifier</code> emits a message, and the protocol ends when the <code>notified</code> receives it. The basic message protocol uses this style.</p> <p></p> <p>Slightly more complex is the request-response protocol style. This style involve two parties, with the <code>requester</code> making the first move, and the <code>responder</code> completing the interaction. The Discover Features Protocol uses this style. Note that with protocols as Aries models them (and unlike an HTTP request), the request-response messages are asynchronous.</p> <p></p> <p>However, more complex protocols exist. The Introduce Protocol involves three parties, not two. The issue credential protocol includes up to six message types (including <code>ack</code> and <code>problem_report</code>), two of which (<code>proposal</code> and <code>offer</code>) can be used to interactively negotiate details of the elements of the subsequent messages in the protocol.</p> <p>See this subsection for definitions of the terms \"role\", \"participant\", and \"party\".</p>"},{"location":"concepts/0003-protocols/#agent-design","title":"Agent Design","text":"<p>Protocols are the key unit of interoperable extensibility in agents and agent-like things. To add a new interoperable feature to an agent, give it the ability to handle a new protocol.</p> <p>When agents receive messages, they map the messages to a protocol handler and possibly to an interaction state that was previously persisted. This is the analog to routes, route handlers, and sessions in web APIs, and could actually be implemented as such if the transport for the protocol is HTTP. The protocol handler is code that knows the rules of a particular protocol; the interaction state tracks progress through an interaction. For more information, see the agents explainer\u2014RFC 0004 and the DIDComm explainer\u2014RFC 0005.</p>"},{"location":"concepts/0003-protocols/#composable","title":"Composable","text":"<p>Protocols are composable--meaning that you can build complex ones from simple ones. The protocol for asking someone to repeat their last sentence can be part of the protocol for ordering food at a restaurant. It's common to ask a potential driver's license holder to prove their street address before issuing the license. In protocol terms, this is nicely modeled as the present proof being invoked in the middle of an issue credential protocol.</p> <p>When we run one protocol inside another, we call the inner protocol a subprotocol, and the outer protocol a superprotocol. A given protocol may be a subprotocol in some contexts, and a standalone protocol in others. In some contexts, a protocol may be a subprotocol from one perspective, and a superprotocol from another (as when protocols are nested at least 3 deep).</p> <p></p> <p>Commonly, protocols wait for subprotocols to complete, and then they continue. A good example of this is mentioned above\u2014starting an issue credential flow, but requiring the potential issuer and/or the potential holder to prove something to one another before completing the process.</p> <p>In other cases, a protocol B is not \"contained\" inside protocol A. Rather, A triggers B, then continues in parallel, without waiting for B to complete. This coprotocol relationship is analogous to relationship between coroutines in computer science. In the Introduce Protocol, the final step is to begin a connection protocol between the two introducees-- but the introduction coprotocol completes when the connect coprotocol starts, not when it completes.</p> <p></p>"},{"location":"concepts/0003-protocols/#message-types","title":"Message Types","text":"<p>A protocol includes a number of message types that enable the execution of an instance of a protocol. Collectively, the message types of a protocol become the skeleton of its interface. Most of the message types are defined with the protocol, but several key message types, notably acks and problem reports are defined in separate RFCs and <code>adopted</code> into a protocol. This ensures that the structure of such messages is standardized, but used in the context of the protocol adopting the message types.</p>"},{"location":"concepts/0003-protocols/#handling-unrecognized-items-in-messages","title":"Handling Unrecognized Items in Messages","text":"<p>In the semver section of this document there is discussion of the handling of mismatches in minor versions supported and received. Notably, a recipient that supports a given minor version of a protocol less than that of a received protocol message should ignore any unrecognized fields in the message. Such handling of unrecognized data items applies more generally than just minor version mismatches. A recipient of a message from a supported major version of a protocol should ignore any unrecognized items in a received message, even if the supported and minor versions are the same. When items from the message are ignored, the recipient may want to send a warning <code>problem-report</code> message with code <code>fields-ignored</code>.</p>"},{"location":"concepts/0003-protocols/#ingredients","title":"Ingredients","text":"<p>A protocol has the following ingredients:</p> <ul> <li>Name and semver-compatible   version</li> <li>URI that uniquely identifies it</li> <li>Messages (primary message family)</li> <li>Adopted messages</li> <li>Roles</li> <li>State and sequencing rules</li> <li>Events that can change state -- notably, messages, but also errors, timeouts, and other things</li> <li>Constraints that provide trust and incentives</li> </ul>"},{"location":"concepts/0003-protocols/#how-to-define-a-protocol","title":"How to Define a Protocol","text":"<p>To define a protocol, write an RFC. Specific instructions for protocol RFCs, and a discussion about the theory behind detailed protocol ../../concepts, are given in the instructions for protocol RFCs and in the protocol RFC template.</p> <p>The tictactoe protocol is attached to this RFC as an example.</p> <p></p>"},{"location":"concepts/0003-protocols/#security-considerations","title":"Security Considerations","text":""},{"location":"concepts/0003-protocols/#replay-attacks","title":"Replay Attacks","text":"<p>It should be noted that when defining a protocol that has domain specific requirements around preventing replay attacks, an <code>@id</code> property SHOULD be required. Given an <code>@id</code> field is most commonly set to be a UUID, it should provide randomness comparable to that of a nonce in preventing replay attacks. However, this means that care will be needed in processing of the <code>@id</code> field to make sure its value has not been used before. In some cases, nonces require being unpredictable as well. In this case, greater review should be taken as to how the <code>@id</code> field should be used in the domain specific protocol. In the event where the <code>@id</code> field is not adequate for preventing replay attacks, it's recommended that an additional <code>nonce</code> field be required by the domain specific protocol specification.</p>"},{"location":"concepts/0003-protocols/#reference","title":"Reference","text":""},{"location":"concepts/0003-protocols/#message-type-and-protocol-identifier-uris","title":"Message Type and Protocol Identifier URIs","text":"<p>Message types and protocols are identified with URIs that match certain conventions.</p>"},{"location":"concepts/0003-protocols/#mturi","title":"MTURI","text":"<p>A message type URI (MTURI) identifies message types unambiguously. Standardizing its format is important because it is parsed by agents that will map messages to handlers--basically, code will look at this string and say, \"Do I have something that can handle this message type inside protocol X version Y?\"</p> <p>When this analysis happens, strings should be compared for byte-wise equality in all segments except version. This means that case, unicode normalization, and punctuation differences all matter. It is thus best practice to avoid protocol and message names that differ only in subtle, easy-to-mistake ways.</p> <p>Comparison of the version segment of an MTURI or PIURI should follow semver rules and is discussed in the semver section of this document.</p> <p>The URI MUST be composed as follows:</p> <p></p> <pre><code>message-type-uri  = doc-uri delim protocol-name\n    \"/\" protocol-version \"/\" message-type-name\ndelim             = \"?\" / \"/\" / \"&amp;\" / \":\" / \";\" / \"=\"\nprotocol-name     = identifier\nprotocol-version  = semver\nmessage-type-name = identifier\nidentifier        = alpha *(*(alphanum / \"_\" / \"-\" / \".\") alphanum)\n</code></pre> <p>It can be loosely matched and parsed with the following regex:</p> <pre><code>    (.*?)([a-z0-9._-]+)/(\\d[^/]*)/([a-z0-9._-]+)$\n</code></pre> <p>A match will have captures groups of (1) = <code>doc-uri</code>, (2) = <code>protocol-name</code>, (3) = <code>protocol-version</code>, and (4) = <code>message-type-name</code>.</p> <p>The goals of this URI are, in descending priority:</p> <ul> <li> <p>Code can use the URI to route messages to protocol handlers using semver rules.</p> </li> <li> <p>The definition of a protocol should be tied to the URI such that it is semantically stable. This means that once version 1.0 of a protocol is defined, its definition should not change in ways that would break implementations.</p> </li> <li> <p>Developers can discover information about novel protocols, using the URI to browse or search the web.</p> </li> </ul> <p>The <code>doc-uri</code> portion is any URI that exposes documentation about protocols. A developer should be able to browse to that URI and use human intelligence to look up the named and versioned protocol. Optionally and preferably, the full URI may produce a page of documentation about the specific message type, with no human mediation involved.</p>"},{"location":"concepts/0003-protocols/#piuri","title":"PIURI","text":"<p>A shorter URI that follows the same conventions but lacks the <code>message-type-name</code> portion is called a protocol identifier URI (PIURI).</p> <p></p> <pre><code>protocol-identifier-uri  = doc-uri delim protocol-name\n    \"/\" semver\n</code></pre> <p>Its loose matcher regex is:</p> <pre><code>    (.*?)([a-z0-9._-]+)/(\\d[^/]*)/?$\n</code></pre> <p>The following are examples of valid MTURIs and PIURIs:</p> <ul> <li><code>http://example.com/protocols?which=lets_do_lunch/1.0/</code> (PIURI with fully automated lookup of protocol docs)</li> <li><code>http://example.com/message_types?which=lets_do_lunch/1.0/proposal</code> (MTURI)</li> <li><code>https://github.com/hyperledger/aries-rfcs/tree/18c4f82:trust_ping/1.0/ping</code>    (MTURI). Note that this URI returns a 404 error if followed directly--but    per rules described above, the developer should browse to the doc root    (https://github.com/hyperledger/aries-rfcs/tree/18c4f82) and look for documentation on the <code>trust_ping/1.0</code> protocol.</li> <li><code>https://didcomm.org/trust_ping/1.0/ping</code> (MTURI) This    uses an https reference that could serve    information about protocols.</li> </ul>"},{"location":"concepts/0003-protocols/#semver-rules-for-protocols","title":"Semver Rules for Protocols","text":"<p>Semver rules apply to protocols, with the version of a protocol is expressed in the <code>semver</code> portion of its identifying URI. The \"ingredients\" of a protocol combine to form a public API in the semver sense. Core Aries protocols specify only major and minor elements in a version; the patch component is not used. Non-core protocols may choose to use the patch element.</p> <p>The major and minor versions of protocols match semver semantics:</p> <ul> <li>Clarification updates that do not change the \"public API\" of the protocol can be made with community support without changing the minor version of the protocol.</li> <li>An individual message type can add new optional fields, or deprecate existing fields, with only a change to its protocol's minor version. Similarly, a protocol can add new or deprecate message types with only a change to the minor version.</li> <li>Changes that remove fields or message types, that make formerly optional things required, or that alter the state machine in incompatible ways, must result in an increase of the major version of the protocol/primary message family.</li> </ul> <p>Within a given major version of a protocol, an agent should:</p> <ul> <li>Respond to a minimum supported minor version, defaulting to \"0\".</li> <li>An agent SHOULD keep minimum supported minor version at \"0\" unless it is unsecure or extremely complicated to do so.</li> <li>Respond with or initiate a protocol instance the current fully supported minor version.</li> </ul> <p>This leads to the following received message handling rules:</p> <ul> <li>Message types received with minor versions below the minimum MAY be ignored, or preferably, MAY be answered only with a <code>problem-report</code> message with code <code>version-not-supported</code>.</li> <li>Message types received with a minor version at or higher than the minimum supported and less than the current minor version are processed as follows:</li> <li>The processing MAY be with the same minor version of the received message.<ul> <li>To support this, an implementation must implement each minor version from minimum to current within the major version.</li> </ul> </li> <li>The processing MAY be with the current minor version (higher than received).<ul> <li>This approach is used when maintaining each minor version from minimum to current within the major version is impractical.</li> <li>Recipients of the response message SHOULD detect from the response PIURI that a higher minor version was used in the response, and to compensate if needed and as necessary.</li> <li>Prior wording of this protocol included the following suggestion that is now considered deprecated. See note below about deprecating the \"warning\" problem reports.</li> <li>In addition to responding with the protocol message (if necessary), the agent MAY also want to send a warning <code>problem-report</code> message with code <code>version-with-degraded-../../features</code>.</li> </ul> </li> <li>Message types received with a minor version higher than the current minor version MUST be processed with any unrecognized fields ignored.</li> <li>The response MUST use the current minor version.</li> <li>Recipients of the response message SHOULD detect from the response PIURI that a lower minor version was used in the response, and to compensate if needed and as necessary.</li> <li>Prior wording of this protocol included the following that is now considered deprecated. See note below about deprecating the \"warning\" problem reports.<ul> <li>In addition to responding with the protocol message, an agent MAY send a warning <code>problem-report</code> message with code <code>fields-ignored-due-to-version-mismatch</code></li> </ul> </li> </ul> <p>Note: The deprecation of the \"warning\" <code>problem-reports</code> in cases of minor version mismatches is because the recipient of the response can detect the mismatch by looking at the PIURI, making the \"warning\" unnecessary, and because the <code>problem-report</code> message may be received after (and definitely at a different time than) the response message, and so the warning is of very little value to the recipient. Recipients should still be aware that minor version mismatch warning <code>problem-report</code> messages may be received and handle them appropriately, likely by quietly ignoring them.</p> <p>As documented in the semver documentation, these requirements are not applied when major version 0 is used. In that case, minor version increments are considered breaking.</p> <p>Agents may support multiple major versions and select which major version to use when initiating an instance of the protocol.</p> <p>An agent should reject messages from protocols or unsupported protocol major versions with a <code>problem-report</code> message with code <code>version-not-supported</code>. Agents that receive such a <code>problem-report</code> message may use the discover ../../features protocol to resolve the mismatch.</p>"},{"location":"concepts/0003-protocols/#semver-examples","title":"Semver Examples","text":""},{"location":"concepts/0003-protocols/#initiator","title":"Initiator","text":"<p>Unless Alice's agent (the initiator of a protocol) knows from prior history that it should do something different, it should begin a protocol using the highest version number that it supports. For example, if A.1 supports versions 2.0 through 2.2 of protocol X, it should use 2.2 as the version in the message type of its first message.</p>"},{"location":"concepts/0003-protocols/#recipient-rules","title":"Recipient Rules","text":"<p>Agents for Bob (the recipient) should reject messages from protocols with major versions different from those they support. For major version 0, they should also reject protocols with minor versions they don't support, since semver stipulates that ../../features are not stable before 1.0. For example, if B.1 supports only versions 2.0 and 2.1 of protocol X, it should reject any messages from version 3 or version 1 or 0. In most cases, rejecting a message means sending a <code>problem-report</code> that the message is unsupported. The <code>code</code> field in such messages should be <code>version-not-supported</code>. Agents that receive such a <code>problem-report</code> can then use the Discover Features Protocol to resolve version problems.</p> <p>Recipient agents should accept messages that differ from their own supported version of a protocol only in the patch, prerelease, and/or build fields, whether these differences make the message earlier or later than the version the recipient prefers. These messages will be robustly compatible.</p> <p>For major version &gt;= 1, recipients should also accept messages that differ only in that the message's minor version is earlier than their own preference. In such a case, the recipient should degrade gracefully to use the earlier version of the protocol. If the earlier version lacks important ../../features, the recipient may optionally choose to send, in addition to a response, a <code>problem-report</code> with code <code>version-with-degraded-../../features</code>.</p> <p>If a recipient supports protocol X version 1.0, it should tentatively accept messages with later minor versions (e.g., 1.2). Message types that differ in only in minor version are guaranteed to be compatible for the feature set of the earlier version. That is, a 1.0-capable agent can support 1.0 ../../features using a 1.2 message, though of course it will lose any ../../features that 1.2 added. Thus, accepting such a message could have two possible outcomes:</p> <ol> <li> <p>The message at version 1.2 might look and behave exactly like it did at version 1.0, in which case the message will process without any trouble.</p> </li> <li> <p>The message might contain some fields that are unrecognized and need to be ignored.</p> </li> </ol> <p>In case 2, it is best practice for the recipient to send a <code>problem-report</code> that is a warning, not an error, announcing that some fields could not be processed (code = <code>fields-ignored-due-to-version-mismatch</code>). Such a message is in addition to any response that the protocol demands of the recipient.</p> <p>If the recipient of a protocol's initial message generates a response, the response should use the latest major.minor protocol version that both parties support and know about. Generally, all messages after the first use only major.minor</p> <p></p>"},{"location":"concepts/0003-protocols/#state-details-and-state-machines","title":"State Details and State Machines","text":"<p>While some protocols have only one sequence of states to manage, in most different roles perceive the interaction differently. The sequence of states for each role needs to be described with care in the RFC.</p>"},{"location":"concepts/0003-protocols/#state-machines","title":"State Machines","text":"<p>By convention, protocol state and sequence rules are described using the concept of state machines, and we encourage developers who implement protocols to build them that way.</p> <p>Among other benefits, this helps with error handling: when one agent sends a <code>problem-report</code> message to another, the message can make it crystal clear which state it has fallen back to as a result of the error.</p> <p>Many developers will have encountered a formal of definition of state machines as they wrote parsers or worked on other highly demanding tasks, and may worry that state machines are heavy and intimidating. But as they are used in Aries protocols, state machines are straightforward and elegant. They cleanly encapsulate logic that would otherwise be a bunch of conditionals scattered throughout agent code. The tictactoe example protocol example includes a complete state machine in less than 50 lines of python code, with tests.</p> <p>For an extended discussion of how state machines can be used, including in nested protocols, and with hooks that let custom processing happen at each point in a flow, see https://github.com/dhh1128/distributed-state-machine.</p>"},{"location":"concepts/0003-protocols/#processing-points","title":"Processing Points","text":"<p>A protocol definition describes key points in the flow where business logic can attach. Some of these processing points are obvious, because the protocol makes calls for decisions to be made. Others are implicit. Some examples include:</p> <ul> <li>The beginning and end.</li> <li>The launch of a subprotocol.</li> <li>The completion of a subprotocol, or the subprotocol changing state.</li> <li>Sending a message. (For each send, the sender could choose to go silent and abandon the interaction instead, though many protocols would ask for notification to be emitted as best practice.)</li> <li>(Receiving a message_. (Requires validation, then integration with policy and processes internal to the agent and its sovereign domain, to move the interaction forward.)</li> </ul>"},{"location":"concepts/0003-protocols/#roles-participants-parties-and-controllers","title":"Roles, Participants, Parties, and Controllers","text":""},{"location":"concepts/0003-protocols/#roles","title":"Roles","text":"<p>The roles in a protocol are the perspectives (responsibilities, privileges) that parties take in an interaction.</p> <p>This perspective is manifested in three general ways:</p> <ul> <li>by the expectations that a party takes on in a protocol (ex. a role may be expected to do something to start a protocol).</li> <li>by the messages that a party can and does use in the course of the protocol (some messages may be reserved for a single role, while other may used by some if not all roles).</li> <li>by the state and the transition rules</li> </ul> <p>Like parties, roles are normally known at the start of the protocol but this is not a requirement.</p> <p>In an auction protocol, there are only two roles\u2014auctioneer and bidder\u2014even though there may be many parties involved.</p>"},{"location":"concepts/0003-protocols/#participants","title":"Participants","text":"<p>The participants in a protocol are the agents that send and/or receive plaintext application-level messages that embody the protocol's interaction. Alice, Bob, and Carol may each have a cloud agent, a laptop, and a phone; if they engage in an introduction protocol using phones, then the agents on their phones are the participants. If the phones talk directly over Bluetooth, this is particularly clear--but even if the phones leverage push notifications and HTTP such that cloud agents help with routing, only the phone agents are participants, because only they maintain state for the interaction underway. (The cloud agents would be facilitators, and the laptops would be bystanders). When a protocol is complete, the participant agents know about the outcome; they may need to synchronize or replicate their state before other agents of the parties are aware.</p>"},{"location":"concepts/0003-protocols/#parties","title":"Parties","text":"<p>The parties to a protocol are the entities directly responsible for achieving the protocol's goals. When a protocol is high-level, parties are typically people or organizations; as protocols become lower-level, parties may be specific agents tasked with detail work through delegation.</p> <p>Imagine a situation where Alice wants a vacation. She engages with a travel agent named Bob. Together, they begin an \"arrange a vacation\" protocol. Alice is responsible for expressing her parameters and proving her willingness to pay; Bob is responsible for running a bunch of subprotocols to work out the details. Alice and Bob--not software agents they use--are parties to this high-level protocol, since they share responsibility for its goals.</p> <p>As soon as Alice has provided enough direction and hangs up the phone, Bob begins a sub-protocol with a hotel to book a room for Alice. This sub-protocol has related but different goals--it is about booking a particular hotel room, not about the vacation as a whole. We can see the difference when we consider that Bob could abandon the booking and choose a different hotel entirely, without affecting the overarching \"arrange a vacation\" protocol.</p> <p>With the change in goal, the parties have now changed, too. Bob and a hotel concierge are the ones responsible for making the \"book a hotel room\" protocol progress. Alice is an approver and indirect stakeholder, but she is not doing the work. (In RACI terms, Alice is an \"accountable\" or \"approving\" entity, but only Bob and the concierge are \"responsible\" parties.)</p> <p>Now, as part of the hotel reservation, Bob tells the concierge that the guest would like access to a waverunner to play in the ocean on day 2. The concierge engages in a sub-sub-protocol to reserve the waverunner. The goal of this sub-sub-protocol is to reserve the equipment, not to book a hotel or arrange a vacation. The parties to this sub-sub-protocol are the concierge and the person or automated system that manages waverunners.</p> <p>Often, parties are known at the start of a protocol; however, that is not a requirement. Some protocols might commence with some parties not yet known or assigned.</p> <p>For many protocols, there are only two parties, and they are in a pairwise relationship. Other protocols are more complex. Introductions involves three; an auction may involve many.</p> <p>Normally, the parties that are involved in a protocol also participate in the interaction but this is not always the case. Consider a gossip protocol, two parties may be talking about a third party. In this case, the third party would not even know that the protocol was happening and would definitely not participate.</p>"},{"location":"concepts/0003-protocols/#controllers","title":"Controllers","text":"<p>The controllers in a protocol are entities that make decisions. They may or may not be direct parties.</p> <p>Imagine a remote chess game between Bob and Carol, conducted with software agents. The chess protocol isn't technically about how to select a wise chess move; it's about communicating the moves so parties achieve the shared goal of running a game to completion. Yet choices about moves are clearly made as the protocol unfolds. These choices are made by controllers--Bob and Carol--while the agents responsible for the work of moving the game forward wait with the protocol suspended.</p> <p>In this case, Bob and Carol could be analyzed as parties to the protocol, as well as controllers. But in other cases, the ../../concepts are distinct. For example, in a protocol to issue credentials, the issuing institution might use an AI and/or business automation as a controller.</p>"},{"location":"concepts/0003-protocols/#instructions-for-protocol-rfcs","title":"Instructions for Protocol RFCs","text":"<p>A protocol RFC conforms to general RFC patterns, but includes some specific substructure.</p> <p></p> <p>Please see the special protocol RFC template for details.</p>"},{"location":"concepts/0003-protocols/#drawbacks","title":"Drawbacks","text":"<p>This RFC creates some formalism around defining protocols. It doesn't go nearly as far as SOAP or CORBA/COM did, but it is slightly more demanding of a protocol author than the familiar world of RESTful Swagger/OpenAPI.</p> <p>The extra complexity is justified by the greater demands that agent-to-agent communications place on the protocol definition. See notes in Prior Art section for details.</p>"},{"location":"concepts/0003-protocols/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Some of the simplest DIDComm protocols could be specified in a Swagger/OpenAPI style. This would give some nice tooling. However, not all fit into that mold. It may be desirable to create conversion tools that allow Swagger interop.</p>"},{"location":"concepts/0003-protocols/#prior-art","title":"Prior art","text":""},{"location":"concepts/0003-protocols/#bpmn","title":"BPMN","text":"<p>BPMN (Business Process Model and Notation) is a graphical language for modeling flows of all types (plus things less like our protocols as well). BPMN is a mature standard sponsored by OMG(Object Management Group). It has a nice tool ecosystem (such as this). It also has an XML file format, so the visual diagrams have a two-way transformation to and from formal written language. And it has a code generation mode, where BPMN can be used to drive executable behavior if diagrams are sufficiently detailed and sufficiently standard. (Since BPMN supports various extensions and is often used at various levels of formality, execution is not its most common application.)</p> <p>BPMN began with a focus on centralized processes (those driven by a business entity), with diagrams organized around the goal of the point-of-view entity and what they experience in the interaction. This is somewhat different from a DIDComm protocol where any given entity may experience the goal and the scope of interaction differently; the state machine for a home inspector in the \"buy a home\" protocol is quite different, and somewhat separable, from the state machine of the buyer, and that of the title insurance company.</p> <p>BPMN 2.0 introduced the notion of a choreography, which is much closer to the concept of an A2A protocol, and which has quite an elegant and intuitive visual representation. However, even a BPMN choreography doesn't have a way to discuss interactions with decorators, adoption of generic messages, and other A2A-specific concerns. Thus, we may lean on BPMN for some diagramming tasks, but it is not a substitute for the RFC definition procedure described here.</p>"},{"location":"concepts/0003-protocols/#wsdl","title":"WSDL","text":"<p>WSDL (Web Services Description Language) is a web-centric evolution of earlier, RPC-style interface definition languages like IDL in all its varieties and CORBA. These technologies describe a called interface, but they don't describe the caller, and they lack a formalism for capturing state changes, especiall by the caller. They are also out of favor in the programmer community at present, as being too heavy, too fragile, or poorly supported by current tools.</p>"},{"location":"concepts/0003-protocols/#swagger-openapi","title":"Swagger / OpenAPI","text":"<p>Swagger / OpenAPI overlaps with some of the concerns of protocol definition in agent-to-agent  interactions. We like the tools and the convenience of the paradigm  offered by OpenAPI, but where these two do not overlap, we have impedance.</p> <p>Agent-to-agent protocols must support more than 2 roles, or  two roles that are peers, whereas RESTful web services assume just client  and server--and only the server has a documented API.</p> <p>Agent-to-agent protocols are fundamentally asynchronous,  whereas RESTful web services mostly assume synchronous request~response.</p> <p>Agent-to-agent protocols have complex considerations for diffuse trust,  whereas RESTful web services centralize trust in the web server.</p> <p>Agent-to-agent protocols need to support transports beyond HTTP, whereas  RESTful web services do not.</p> <p>Agent-to-agent protocols are nestable, while  RESTful web services don't provide any special support for that construct.</p>"},{"location":"concepts/0003-protocols/#other","title":"Other","text":"<ul> <li>Pdef (Protocol Definition Language): An alternative to Swagger.</li> <li>JSON RPC: Defines how invocation of  remote methods can be accomplished by passing JSON messages. However, the  RPC paradigm assumes request/response pairs, and does not provide a way  to describe state and roles carefully.</li> <li>IPC Protocol Definition Language (IPDL):  This is much closer to agent protocols in terms of its scope of concerns  than OpenAPI. However, it is C++ only, and intended for use within browser  plugins.</li> </ul>"},{"location":"concepts/0003-protocols/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Should we write a Swagger translator?</li> <li>If not swagger, what formal definition format should we use in the future?</li> </ul>"},{"location":"concepts/0003-protocols/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python several protocols, circa Feb 2019 Aries Framework - .NET several protocols, circa Feb 2019 Streetcred.id several protocols, circa Feb 2019 Aries Cloud Agent - Python numerous protocols plus extension mechanism for pluggable protocols Aries Static Agent - Python 2 or 3 protocols Aries Framework - Go DID Exchange Connect.Me mature but proprietary protocols; community protocols in process Verity mature but proprietary protocols; community protocols in process Aries Protocol Test Suite 2 or 3 core protocols; active work to implement all that are ACCEPTED, since this tests conformance of other agents Pico Labs implemented protocols: connections, trust_ping, basicmessage, routing"},{"location":"concepts/0003-protocols/roles-participants-etc/","title":"Roles participants etc","text":""},{"location":"concepts/0003-protocols/roles-participants-etc/#roles-participants-parties-and-controllers","title":"Roles, Participants, Parties, and Controllers","text":""},{"location":"concepts/0003-protocols/roles-participants-etc/#roles","title":"Roles","text":"<p>The roles in a protocol are the perspectives (responsibilities, privileges) that parties take i an interaction.</p> <p>This perspective is manifested in three general ways:</p> <ul> <li>by the expectations that a party takes on in a protocol (ex. a role may be expected to do something to start a protocol).</li> <li>by the messages that a party can and does use in the course of the protocol (some messages may be reserved for a single role, while other may used by some if not all roles).</li> <li>by the state and the transition rules</li> </ul> <p>Like parties, roles are normally known at the start of the protocol but this is not a requirement.</p> <p>In an auction protocol, there are only two roles\u2014auctioneer and bidder\u2014even though there may be many parties involved.</p>"},{"location":"concepts/0003-protocols/roles-participants-etc/#participants","title":"Participants","text":"<p>The participants in a protocol are the agents that send and/or receive plaintext application-level messages that embody the protocol's interaction. Alice, Bob, and Carol may each have a cloud agent, a laptop, and a phone; if they engage in an introduction protocol using phones, then the agents on their phones are the participants. If the phones talk directly over Bluetooth, this is particularly clear--but even if the phones leverage push notifications and HTTP such that cloud agents help with routing, only the phone agents are participants, because only they maintain state for the interaction underway. (The cloud agents would be facilitators, and the laptops would be bystanders). When a protocol is complete, the participant agents know about the outcome; they may need to synchronize or replicate their state before other agents of the parties are aware.</p>"},{"location":"concepts/0003-protocols/roles-participants-etc/#parties","title":"Parties","text":"<p>The parties to a protocol are the entities directly responsible for achieving the protocol's goals. When a protocol is high-level, parties are typically people or organizations; as protocols become lower-level, parties may be specific agents tasked with detail work through delegation.</p> <p>Imagine a situation where Alice wants a vacation. She engages with a travel agent named Bob. Together, they begin an \"arrange a vacation\" protocol. Alice is responsible for expressing her parameters and proving her willingness to pay; Bob is responsible for running a bunch of subprotocols to work out the details. Alice and Bob--not software agents they use--are parties to this high-level protocol, since they share responsibility for its goals.</p> <p>As soon as Alice has provided enough direction and hangs up the phone, Bob begins a sub-protocol with a hotel to book a room for Alice. This sub-protocol has related but different goals--it is about booking a particular hotel room, not about the vacation as a whole. We can see the difference when we consider that Bob could abandon the booking and choose a different hotel entirely, without affecting the overarching \"arrange a vacation\" protocol.</p> <p>With the change in goal, the parties have now changed, too. Bob and a hotel concierge are the ones responsible for making the \"book a hotel room\" protocol progress. Alice is an approver and indirect stakeholder, but she is not doing the work. (In RACI terms, Alice is an \"accountable\" or \"approving\" entity, but only Bob and the concierge are \"responsible\" parties.)</p> <p>Now, as part of the hotel reservation, Bob tells the concierge that the guest would like access to a waverunner to play in the ocean on day 2. The concierge engages in a sub-sub-protocol to reserve the waverunner. The goal of this sub-sub-protocol is to reserve the equipment, not to book a hotel or arrange a vacation. The parties to this sub-sub-protocol are the concierge and the person or automated system that manages waverunners.</p> <p>Often, parties are known at the start of a protocol; however, that is not a requirement. Some protocols might commence with some parties not yet known or assigned.</p> <p>For many protocols, there are only two parties, and they are in a pairwise relationship. Other protocols are more complex. Introductions involves three; an auction may involve many.</p> <p>Normally, the parties that are involved in a protocol also participate in the interaction but this is not always the case. Consider a gossip protocol, two parties may be talking about a third party. In this case, the third party would not even know that the protocol was happening and would definitely not participate.</p>"},{"location":"concepts/0003-protocols/roles-participants-etc/#controllers","title":"Controllers","text":"<p>The controllers in a protocol are entities that make decisions. They may or may not be direct parties.</p> <p>Imagine a remote chess game between Bob and Carol, conducted with software agents. The chess protocol isn't technically about how to select a wise chess move; it's about communicating the moves so parties achieve the shared goal of running a game to completion. Yet choices about moves are clearly made as the protocol unfolds. These choices are made by controllers--Bob and Carol--while the agents responsible for the work of moving the game forward wait with the protocol suspended.</p> <p>In this case, Bob and Carol could be analyzed as parties to the protocol, as well as controllers. But in other cases, the concepts are distinct. For example, in a protocol to issue credentials, the issuing institution might use an AI and/or business automation as a controller.</p>"},{"location":"concepts/0003-protocols/tictactoe/","title":"Tic Tac Toe Protocol 1.0","text":""},{"location":"concepts/0003-protocols/tictactoe/#summary","title":"Summary","text":"<p>Describes a simple protocol, already familiar to most developers, as a way to demonstrate how all protocols should be documented.</p>"},{"location":"concepts/0003-protocols/tictactoe/#motivation","title":"Motivation","text":"<p>Playing tic-tac-toe is a good way to test whether agents are working properly, since it requires two parties to take turns and to communicate reliably about state. However, it is also pretty simple, and it has a low bar for trust (it's not dangerous to play tic-tac-toe with a malicious stranger). Thus, we expect agent tic-tac-toe to be a good way to test basic plumbing and to identify functional gaps. The game also provides a way of testing interactions with the human owners of agents, or of hooking up an agent AI.</p>"},{"location":"concepts/0003-protocols/tictactoe/#tutorial","title":"Tutorial","text":"<p>Tic-tac-toe is a simple game where players take turns placing Xs and Os in a 3x3 grid, attempting to capture 3 cells of the grid in a straight line.</p>"},{"location":"concepts/0003-protocols/tictactoe/#name-and-version","title":"Name and Version","text":"<p>This defines the <code>tictactoe</code> protocol, version 1.x, as identified by the following PIURI:</p> <pre><code>did:sov:SLfEi9esrjzybysFxQZbfq;spec/tictactoe/1.0\n</code></pre>"},{"location":"concepts/0003-protocols/tictactoe/#key-concepts","title":"Key Concepts","text":"<p>A tic-tac-toe game is an interaction where 2 parties take turns to make up to 9 moves. It starts when either party proposes the game, and ends when one of the parties wins, or when all all cells in the grid are occupied but nobody has won (a draw).</p> <p>Note: Optionally, a Tic-Tac-Toe game can be preceded by a Coin Flip Protocol to decide who goes first. This is not a high-value enhancement, but we add it for illustration purposes. If used, the <code>choice-id</code> field in the initial <code>propose</code> message of the Coin Flip should have the value <code>did:sov:SLfEi9esrjzybysFxQZbfq;spec/tictactoe/1.0/who-goes-first</code>, and the <code>caller-wins</code> and <code>flipper-wins</code> fields should contain the DIDs of the two players.</p> <p>Illegal moves and moving out of turn are errors that trigger a complaint from the other player. However, they do not scuttle the interaction. A game can also be abandoned in an unfinished state by either player, for any reason. Games can last any amount of time.</p> <pre><code>About the Key Concepts section: Here we describe the flow at a very\nhigh level. We identify preconditions, ways the protocol can start\nand end, and what can go wrong. We also talk about timing\nconstraints and other assumptions.\n</code></pre>"},{"location":"concepts/0003-protocols/tictactoe/#roles","title":"Roles","text":"<p>There are two parties in a tic-tac-toe game, but only one role, <code>player</code>. One player places 'X' for the duration of a game; the other places 'O'. There are no special requirements about who can be a player. The parties do not need to be trusted or even known to one another, either at the outset or as the game proceeds. No prior setup is required, other than an ability to communicate.</p> <pre><code>About the Roles section: Here we name the roles in the protocol,\nsay who and how many can play each role, and describe constraints.\nWe also explore qualifications for roles.\n</code></pre>"},{"location":"concepts/0003-protocols/tictactoe/#states","title":"States","text":"<p>The states of each <code>player</code> in the protocol evolve according to the following state machine:</p> <p></p> <p>When a player is in the <code>my-move</code> state, possible valid events include <code>send move</code> (the normal case), <code>send outcome</code> (if the player decides to abandon the game), and <code>receive outcome</code> (if the other player decides to abandon). A <code>receive move</code> event could conceivably occur, too-- but it would be an error on the part of the other player, and would trigger a <code>problem-report</code> message as described above, leaving the state unchanged.</p> <p>In the <code>their-move</code> state, <code>send move</code> is an impossible event for a properly behaving player. All 3 of the other events could occur, causing a state transition.</p> <p>In the <code>wrap-up</code> state, the game is over, but communication with the outcome message has not yet occurred. The logical flow is <code>send outcome</code>, whereupon the player transitions to the <code>done</code> state.</p> <pre><code>About the States section: Here we explain which states exist for each\nrole. We also enumerate the events that can occur, including messages,\nerrors, or events triggered by surrounding context, and what should\nhappen to state as a result. In this protocol, we only have one role,\nand thus only one state machine matrix. But in many protocols, each\nrole may have a different state machine.\n</code></pre>"},{"location":"concepts/0003-protocols/tictactoe/#messages","title":"Messages","text":"<p>All messages in this protocol are part of the \"tictactoe 1.0\" message family uniquely identified by this DID reference: <code>did:sov:SLfEi9esrjzybysFxQZbfq;spec/tictactoe/1.0</code></p> NOTE 1: All the messages defined in a protocol should follow  DIDComm best practices as far as how they name fields and define their data types and semantics.  NOTE 2 about the \"DID Reference\" URI that appears here: DIDs can be resolved     to a DID doc that contains an endpoint, to which everything after a     semicolon can be appended. Thus, if this DID is publicly registered     and its DID doc gives an endpoint of http://example.com, this URI     would mean that anyone can find a formal definition of the protocol at     http://example.com/spec/tictactoe/1.0. It is also possible to use a     traditional URI here, such as http://example.com/spec/tictactoe/1.0.     If that sort of URI is used, it is best practice for it to reference     immutable content, as with a link to specific commit on github:       https://github.com/hyperledger/aries-rfcs/blob/ab7a04f/concepts/0003-protocols/tictactoe/README.md#messages"},{"location":"concepts/0003-protocols/tictactoe/#move-message","title":"<code>move</code> message","text":"<p>The protocol begins when one party sends a <code>move</code> message to the other. It looks like this:</p> <p></p> <p><code>@id</code> is required here, as it establishes a message thread that will govern the rest of the game.</p> <p><code>me</code> tells which mark (X or O) the sender is placing. It is required.</p> <p><code>moves</code> is optional in the first message of the interaction. If missing or empty, the sender of the first message is inviting the recipient to make the first move. If it contains a move, the sender is moving first.</p> <p>Moves are strings like \"X:B2\" that match the regular expression <code>(?i)[XO]:[A-C][1-3]</code>. They identify a mark to be placed (\"X\" or \"O\") and a position in the 3x3 grid. The grid's columns and rows are numbered like familiar spreadsheets, with columns A, B, and C, and rows 1, 2, and 3.</p> <p><code>comment</code> is optional and probably not used much, but could be a way for players to razz one another or chat as they play. It follows the conventions of localized messages.</p> <p>Other decorators could be placed on tic-tac-toe messages, such as those to enable message timing to force players to make a move within a certain period of time.</p>"},{"location":"concepts/0003-protocols/tictactoe/#subsequent-moves","title":"Subsequent Moves","text":"<p>Once the initial <code>move</code> message has been sent, game play continues by each player taking turns sending responses, which are also <code>move</code> messages. With each new message the <code>move</code> array inside the message grows by one, ensuring that the players agree on the current accumulated state of the game. The <code>me</code> field is still required and must accurately reflect the role of the message sender; it thus alternates values between <code>X</code> and <code>O</code>.</p> <p>Subsequent messages in the game use the message threading mechanism where the <code>@id</code> of the first <code>move</code> becomes the <code>~thread.thid</code> for the duration of the game.</p> <p>An evolving sequence of <code>move</code> messages might thus look like this, suppressing all fields except what's required:</p>"},{"location":"concepts/0003-protocols/tictactoe/#messagemove-2","title":"Message/Move 2","text":"<p>This is the first message in the thread that's sent by the <code>player</code> placing \"O\"; hence it has <code>myindex</code> = 0.</p>"},{"location":"concepts/0003-protocols/tictactoe/#messagemove-3","title":"Message/Move 3","text":"<p>This is the second message in the thread by the player placing \"X\"; hence it has <code>myindex</code> = 1.</p>"},{"location":"concepts/0003-protocols/tictactoe/#messagemove-4","title":"Message/Move 4","text":"<p>...and so forth.</p> <p>Note that the order of the items in the <code>moves</code> array is NOT significant. The state of the game at any given point of time is fully captured by the moves, regardless of the order in which they were made.</p> <p>If a player makes an illegal move or another error occurs, the other player can complain using a problem-report message, with <code>explain.@l10n.code</code> set to one of the values defined in the Message Catalog section (see below).</p>"},{"location":"concepts/0003-protocols/tictactoe/#outcome-message","title":"<code>outcome</code> message","text":"<p>Game play ends when one player sends a <code>move</code> message that manages to mark 3 cells in a row. Thereupon, it is best practice, but not strictly required, for the other player to send an acknowledgement in the form of an <code>outcome</code> message.</p> <p></p> <p>The <code>moves</code> and <code>me</code> fields from a <code>move</code> message can also, optionally, be included to further document state. The <code>winner</code> field is required. Its value may be \"X\", \"O\", or--in the case of a draw--\"none\".</p> <p>This <code>outcome</code> message can also be used to document an abandoned game, in which case <code>winner</code> is <code>null</code>, and <code>comment</code> can be used to explain why (e.g., timeout, loss of interest).</p> <pre><code>About the Messages section: Here we explain the message types, but\nalso which roles send which messages, what sequencing rules apply,\nand how errors may occur during the flow. The message begins with\nan announcement of the identifier and version of the message\nfamily, and also enumerates error codes to be used with problem\nreports. This protocol is simple enough that we document the\ndatatypes and validation rules for fields inline in the narrative;\nin more complex protocols, we'd move that text into the Reference\n&gt; Messages section instead.\n</code></pre>"},{"location":"concepts/0003-protocols/tictactoe/#constraints","title":"Constraints","text":"<p>Players do not have to trust one another. Messages do not have to be authcrypted, although anoncrypted messages still have to have a path back to the sender to be useful.</p> <pre><code>About the Constraints section: Many protocols have rules\nor mechanisms that help parties build trust. For example, in buying\na house, the protocol includes such things as commission paid to\nrealtors to guarantee their incentives, title insurance, earnest\nmoney, and a phase of the process where a home inspection takes\nplace. If you are documenting a protocol that has attributes like\nthese, explain them here.\n</code></pre>"},{"location":"concepts/0003-protocols/tictactoe/#reference","title":"Reference","text":"<pre><code>About the Reference section: If the Tutorial &gt; Messages section\nsuppresses details, we would add a Messages section here to\nexhaustively describe each field. We could also include an\nExamples section to show variations on the main flow.\n</code></pre>"},{"location":"concepts/0003-protocols/tictactoe/#collateral","title":"Collateral","text":"<p>A reference implementation of the logic of a game is provided with this RFC as python 3.x code. See game.py. There is also a simple hand-coded AI that can play the game when plugged into an agent (see ai.py), and a set of unit tests that prove correctness (see test_tictactoe.py).</p> <p>A full implementation of the state machine is provided as well; see state_machine.py and test_state_machine.py.</p> <p>The game can be played interactively by running <code>python game.py</code>.</p>"},{"location":"concepts/0003-protocols/tictactoe/#localization","title":"Localization","text":"<p>The only localizable field in this message family is <code>comment</code> on both <code>move</code> and <code>outcome</code> messages. It contains ad hoc text supplied by the sender, instead of a value selected from an enumeration and identified by <code>code</code> for use with message catalogs. This means the only approach to localize <code>move</code> or <code>outcome</code> messages is to submit <code>comment</code> fields to an automated translation service. Because the locale of <code>tictactoe</code> messages is not predefined, each message must be decorated with <code>~l10n.locale</code> to make automated translation possible.</p> <p>There is one other way that localization is relevant to this protocol: in error messages. Errors are communicated through the general problem-report message type rather than through a special message type that's part of the <code>tictactoe</code> family. However, we define a catalog of tictactoe-specific error codes below to make this protocol's specific error strings localizable. </p> <p>Thus, all instances of this message family carry localization metadata in the form of an implicit <code>~l10n</code> decorator that looks like this:</p> <p></p> <p>This JSON fragment is checked in next to the narrative content of this RFC as ~l10n.json, for easy machine parsing.</p> <p>Individual messages can use the <code>~l10n</code> decorator to supplement or override these settings.</p> <p>For more information about localization concepts, see the RFC about localized messages.</p>"},{"location":"concepts/0003-protocols/tictactoe/#message-catalog","title":"Message Catalog","text":"<p>To facilitate localization of error messages, all instances of this message family assume the following catalog in their <code>~l10n</code> data:</p> <p></p> <p>When referencing this catalog, please be sure you have the correct version. The official, immutable URL to this version of the catalog file is:</p> <pre><code>https://github.com/hyperledger/indy-hipe/blob/fc7a6028/text/tictactoe-protocol/catalog.json\n</code></pre> <p>This JSON fragment is checked in next to the narrative content of this RFC as catalog.json, for easy machine parsing. The catalog currently contains localized alternatives only for English. Other language contributions would be welcome.</p> <p>For more information, see the Message Catalog section of the localization HIPE.</p>"},{"location":"concepts/0003-protocols/tictactoe/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Verity Commercially licensed enterprise agent, SaaS or on-prem. Pico Labs Open source TicTacToe for Pico Agents"},{"location":"concepts/0004-agents/","title":"Aries RFC 0004: Agents","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2019-01-15</li> <li>Status Note: On a standards track and beginning to influence many mental models, but not yet ADOPTED. </li> <li>Supersedes: Indy HIPE 0002</li> <li>Start Date: 2017-11-01 (approx, backdated)</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0004-agents/#summary","title":"Summary","text":"<p>Provide a high-level introduction to the ../../concepts of agents in the self-sovereign identity ecosystem.</p>"},{"location":"concepts/0004-agents/#tutorial","title":"Tutorial","text":"<p>Managing an identity is complex. We need tools to help us.</p> <p>In the physical world, we often delegate complexity to trusted proxies that can help. We hire an accountant to do our taxes, a real estate agent to help us buy a house, and a talent agent to help us pitch an album to a recording studio.</p> <p>On the digital landscape, humans and organizations (and sometimes, things) cannot directly consume and emit bytes, store and manage data, or perform the crypto that self-sovereign identity demands. They need delegates--agents--to help. Agents are a vital dimension across which we exercise sovereignty over identity.</p> <p></p>"},{"location":"concepts/0004-agents/#essential-characteristics","title":"Essential Characteristics","text":"<p>When we use the term \"agent\" in the SSI community, we more properly mean \"an agent of self-sovereign identity.\" This means something more specific than just a \"user agent\" or a \"software agent.\" Such an agent has three defining characteristics:</p> <ol> <li>It acts as a fiduciary on behalf of a single identity owner (or, for agents of things like IoT devices, pets, and similar things, a single controller).</li> <li>It holds cryptographic keys that uniquely embody its delegated authorization.</li> <li>It interacts using interoperable DIDComm protocols.</li> </ol> <p>These characteristics don't tie an agent to any particular blockchain. It is possible to implement agents without any use of blockchain at all (e.g., with peer DIDs), and some efforts to do so are quite active.</p>"},{"location":"concepts/0004-agents/#canonical-examples","title":"Canonical Examples","text":"<p>Three types of agents are especially common:</p> <ol> <li>A mobile app that Alice uses to manage credentials and to connect to others is an agent for Alice.</li> <li>A cloud-based service that Alice uses to expose a stable endpoint where other agents can talk to her is an agent for Alice.</li> <li>A server run by Faber College, allowing it to issue credentials to its students, is an agent for Faber.</li> </ol> <p>Depending on your perspective, you might describe these agents in various ways. #1 can correctly be called a \"mobile\" or \"edge\" or \"rich\" agent. #2 can be called a \"cloud\" or \"routing\" agent. #3 can be called an \"on-prem\" or \"edge\" or \"advanced\" agent. See Categorizing Agents for a discussion about why multiple labels are correct.</p> <p>Agents can be other things as well. They can big or small, complex or simple. They can interact and be packaged in various ways.  They can be written in a host of programming languages. Some are more canonical than others. But all the ones we intend to interact with in the self-sovereign identity problem domain share the three essential characteristics described above.</p>"},{"location":"concepts/0004-agents/#how-agents-talk","title":"How Agents Talk","text":"<p>DID communication (DIDComm), and the protocols built atop it are each rich subjects unto themselves. Here, we will stay very high-level.</p> <p>Agents can use many different communication transports: HTTP(S) 1.x and 2.0, WebSockets, IRC, Bluetooth, AMQP, NFC, Signal, email, push notifications to mobile devices, ZMQ, and more. However, all A2A is message-based, and is secured by modern, best-practice public key cryptography. How messages flow over a transport may vary--but their security and privacy toolset, their links to the DIDs and DID Docs of identity owners, and the ways their messages are packaged and handled are standard.</p> <p>Agents connect to one another through a standard connection protocol, discover one another's endpoints and keys through standard DID Docs, discover one another's ../../features in a standard way, and maintain relationships in a standard way. All of these points of standardization are what makes them interoperable.</p> <p>Because agents speak so many different ways, and because many of them won't have a permanent, accessible point of presence on the network, they can't all be thought of as web servers with a Swagger-compatible API for request-response. The analog to an API construct in agent-land is protocols. These are patterns for stateful interactions. They specify things like, \"If you want to negotiate a sale with an agent, send it a message of type X. It will respond with a message of type Y or type Z, or with an error message of type W. Repeat until the negotiation finishes.\" Some interesting A2A protocols include the one where two parties connect to one another to build a relationship, the one where agents discover which protocols they each support, the one where credentials are issued, and the one where proof is requested and sent. Hundreds of other protocols are being defined.</p>"},{"location":"concepts/0004-agents/#how-to-get-an-agent","title":"How to Get an Agent","text":"<p>As the ecosystem for self-sovereign identity matures, the average person or organization will get an agent by downloading it from the app store, installing it with their OS package manager, or subscribing to it as a service. However, the availability of quality pre-packaged agents is still limited today.</p> <p>Agent providers are emerging in the marketplace, though. Some are governments, NGOs, or educational institutions that offer agents for free; others are for-profit ventures. If you'd like suggestions about ready-to-use agent offerings, please describe your use case in <code>#aries</code> on chat.hyperledger.org.</p> <p>There is also intense activity in the SSI community around building custom agents and the tools and processes that enable them. A significant amount of early work occurred in the Indy Agent Community with some of those efforts materializing in the indy-agent repo on github.com and other code bases. The indy-agent repo is now deprecated but is still valuable in demonstrating the basics of agents. With the introduction of Hyperledger Aries, agent efforts are migrating from the Indy Agent community.</p> <p>Hyperledger Aries provides a number of code bases ranging from agent frameworks to tools to aid in development to ready-to-use agents.</p>"},{"location":"concepts/0004-agents/#how-to-write-an-agent","title":"How to Write an Agent","text":"<p>This is one of the most common questions that Aries newcomers ask. It's a challenging one to answer, because it's so open-ended. It's sort of like someone asking, \"Can you give me a recipe for dinner?\" The obvious follow-up question would be, \"What type of dinner did you have in mind?\"</p> <p>Here are some thought questions to clarify intent:</p> <ul> <li>Do you need an agent for people or institutions (or an IoT thing)?</li> <li>Will the agent run on a mobile device, in a cloud, on a server,   or elsewhere?</li> <li>Will the agent be on and connected to the internet constantly, or   will it run only from time to time?</li> <li>Which protocols should your agent implement? (In other words, what   sort of work do you want to delegate to it?)</li> <li>Will your agent talk, listen, or both? What channels/transports   will it use?</li> <li>What interesting requirements does your agent have with respect to   security, privacy, scale, and performance?</li> </ul>"},{"location":"concepts/0004-agents/#general-patterns","title":"General Patterns","text":"<p>We said it's hard to provide a recipe for an agent without specifics. However, the majority of agents do have two things in common: they listen to and process A2A messages, and they use a wallet to manage keys, credentials, and other sensitive material. Unless you have uses cases that involve IoT, cron jobs, or web hooks, your agent is likely to fit this mold.</p> <p>The heart of such an agent is probably a messaging handling loop, with pluggable protocols to give it new capabilities, and pluggable transports to let it talk in different ways. The pseudocode for its main function might look like this:</p>"},{"location":"concepts/0004-agents/#pseudocode-for-main","title":"Pseudocode for main()","text":"<pre><code>1  While not done:\n2      Get next message.\n3      Verify it (decrypt, identify sender, check signature...).\n3      Look at the type of the plaintext message.\n4      Find a plugged in protocol handler that matches that type.\n5      Give plaintext message and security metadata to handler.\n</code></pre> <p>Line 2 can be done via standard HTTP dispatch, or by checking an email inbox, or in many other ways. Line 3 can be quite sophisticated--the sender will not be Alice, but rather one of the agents that she has authorized. Verification may involve consulting cached information and/or a blockchain where a DID and DID Doc are stored, among other things.</p> <p>The pseudocode for each protocol handler it loads might look like:</p>"},{"location":"concepts/0004-agents/#pseudocode-for-protocol-handler","title":"Pseudocode for protocol handler","text":"<pre><code>1  Check authorization against metadata. Reject if needed.\n2  Read message header. Is it part of an ongoing interaction?\n3  If yes, load persisted state.\n4  Process the message and update interaction state.\n5  If a response is appropriate:\n6      Prepare response content.\n7      Ask my outbound comm module to package and send it.\n</code></pre> <p>Line 4 is the workhorse. For example, if the interaction is about issuing credentials and this agent is doing the issuance, this would be where it looks up the material for the credential in internal databases, formats it appropriately, and records the fact that the credential has now been built. Line 6 might be where that credential is attached to an outgoing message for transmission to the recipient.</p> <p>The pseudocode for the outbound communication module might be:</p>"},{"location":"concepts/0004-agents/#pseudocode-for-outbound","title":"Pseudocode for outbound","text":"<pre><code>1  Iterate through all pluggable transports to find best one to use\n     with the intended recipient.\n2  Figure out how to route the message over the selected transport.\n3  Serialize the message content and encrypt it appropriately.\n4  Send the message.\n</code></pre> <p>Line 2 can be complex. It involves looking up one or more endpoints in the DID Doc of the recipient, and finding an intersection between transports they use, and transports the sender can speak. Line 3 requires the keys of the sender, which would normally be held in a wallet.</p> <p>If you are building this sort of code using Aries technology, you will certainly want to use Aries Agent SDK. This gives you a ready-made, highly secure wallet that can be adapted to many requirements. It also provides easy functions to serialize and encrypt. Many of the operations you need to do are demonstrated in the SDK's /doc/how-tos folder, or in its Getting Started Guide.</p>"},{"location":"concepts/0004-agents/#how-to-learn-more","title":"How to Learn More","text":"<ul> <li>Hang out and ask questions on <code>#aries</code> on chat.hyperledger.org.</li> <li>Use the mailing list: aries@lists.hyperledger.org</li> <li>Follow the Aries Cloud Agent - Python Getting Started Guide (for developers)</li> <li>Study the Aries Protocol Test Suite |</li> <li>Study the sample mobile agent at github.com/sovrin-foundation/connector-app.</li> <li>Browse other RFCs.</li> <li>Attend the Aries working group on Wednesdays. (See HL community calendar for details; note that the default timezone is GMT.)</li> <li>Review this slide deck   about integrating agents with familiar web development paradigms.</li> </ul>"},{"location":"concepts/0004-agents/#reference","title":"Reference","text":""},{"location":"concepts/0004-agents/#categorizing-agents","title":"Categorizing Agents","text":"<p>Agents can be categorized in various ways, and these categories lead to terms you're likely to encounter in RFCs and other documentation. Understanding the categories will help the definitions make sense.</p>"},{"location":"concepts/0004-agents/#by-trust","title":"By Trust","text":"<p>A trustable agent runs in an environment that's under the direct control of its owner; the owner can trust it without incurring much risk. A semi-trustable agent runs in an environment where others besides the owner may have access, so giving it crucial secrets is less advisable. (An untrustable delegate should never be an agent, by definition, so we don't use that term.)</p> <p>Note that these distinctions highlight what is advisable, not how much trust the owner actually extends.</p>"},{"location":"concepts/0004-agents/#by-location","title":"By Location","text":"<p>Two related but deprecated terms are edge agent and cloud agent. You will probably hear these terms in the community or read them in docs. The problem with them is that they suggest location, but were formally defined to imply levels of trust. When they were chosen, location and levels of trust were seen as going together--you trust your edge more, and your cloud less. We've since realized that a trustable agent could exist in the cloud, if it is directly controlled by the owner, and a semi-trustable agent could be on-prem, if the owner's control is indirect. Thus we are trying to correct usage and make \"edge\" and \"cloud\" about location instead.</p>"},{"location":"concepts/0004-agents/#by-platform","title":"By Platform","text":"<ul> <li>Mobile -- likely trustable</li> <li>Workstation -- likely trustable</li> <li>Server -- could be trustable or semi-trustable</li> <li>Embedded -- trustable or semi-trustable</li> <li>Browser (web assembly or javascript) -- likely semi-trustable</li> <li>Blockchain (embodied in smart contract -- trustable?)</li> <li>Mesh (IoT\u2026)</li> <li>Paper?</li> </ul>"},{"location":"concepts/0004-agents/#by-complexity","title":"By Complexity","text":"<p>We can arrange agents on a continuum, from simple to complex. The simplest agents are static--they are preconfigured for a single relationship. Thin agents are somewhat fancier. Thick agents are fancier still, and rich agents exhibit the most sophistication and flexibility:</p> <p></p> <p>A nice visualization of several dimensions of agent category has been built by Michael Herman:</p> <p></p>"},{"location":"concepts/0004-agents/#the-agent-ness-continuum","title":"The Agent-ness Continuum","text":"<p>The tutorial above gives three essential characteristics of agents, and lists some canonical examples. This may make it feel like agent-ness is pretty binary. However, we've learned that reality is more fuzzy.</p> <p>Having a tight definition of an agent may not matter in all cases. However, it is important when we are trying to understand interoperability goals. We want agents to be able to interact with one another. Does that mean they must interact with every piece of software that is even marginally agent-like? Probably not.</p> <p>Some attributes that are not technically necessary in agents include:</p> <ul> <li>Has a wallet (common, but not universal)</li> <li>Establishes new connections (some may use only a small set of preconfigured connections)</li> <li>Exchanges credentials and proofs (some may not use these protocols)</li> <li>Both listens and talks (some may only listen or only talk)</li> </ul> <p>Agents that lack these characteristics can still be fully interoperable.</p> <p>Some interesting examples of less prototypical agents or agent-like things include:</p>"},{"location":"concepts/0004-agents/#dif-hubs","title":"DIF Hubs","text":"<p>A DIF Identity Hub is construct that resembles agents in some ways, but that focuses on the data-sharing aspects of identity. Currently DIF Hubs do not use the protocols known to the Aries community, and vice versa. However, there are efforts to bridge that gap.</p>"},{"location":"concepts/0004-agents/#identity-wallets","title":"Identity Wallets","text":"<p>\"Identity wallet\" is a term that's carefully defined in our ecosystem, and in strict, technical usage it maps to a concept much closer to \"database\" than \"agent\". This is because it is an inert storage container, not an active interacter. However, in casual usage, it may mean the software that uses a wallet to do identity work--in which case it is definitely an agent.</p>"},{"location":"concepts/0004-agents/#crypto-wallets","title":"Crypto Wallets","text":"<p>Cryptocurrency wallets are quite agent-like in that they hold keys and represent a user. However, they diverge from the agent definition in that they talk proprietary protocols to blockchains, rather than A2A to other agents.</p>"},{"location":"concepts/0004-agents/#uport","title":"uPort","text":"<p>The uPort app is an edge agent. Here, too, there are efforts to bridge a protocol gap.</p>"},{"location":"concepts/0004-agents/#learning-machine","title":"Learning Machine","text":"<p>The credential issuance technology offered by Learning Machine, and the app used to share those credentials, are agents of institutions and individuals, respectively. Again, there is a protocol gap to bridge.</p>"},{"location":"concepts/0004-agents/#cron-jobs","title":"Cron Jobs","text":"<p>A cron job that runs once a night at Faber, scanning a database and revoking credentials that have changes status during the day, is an agent for Faber. This is true even though it doesn't listen for incoming messages (it only talks revocation protocol to the ledger). In order to talk that protocol, it must hold keys delegated by Faber, and it is surely Faber's fiduciary.</p>"},{"location":"concepts/0004-agents/#operating-systems","title":"Operating Systems","text":"<p>The operating system on a laptop could be described as agent-like, in that it works for a single owner and may have a keystore. However, it doesn't talk A2A to other agents--at least not yet. (OSes that service multiple users fit the definition less.)</p>"},{"location":"concepts/0004-agents/#devices","title":"Devices","text":"<p>A device can be thought of as an agent (e.g., Alice's phone as an edge agent). However, strictly speaking, one device might run multiple agents, so this is only casually correct.</p>"},{"location":"concepts/0004-agents/#sovrin-mainnet","title":"Sovrin MainNet","text":"<p>The Sovrin MainNet can be thought of as an agent for the Sovrin community (but NOT the Sovrin Foundation, which codifies the rules but leaves operation of the network to its stewards). Certainly, the blockchain holds keys, uses A2A protocols, and acts in a fiduciary capacity toward the community to further its interests. The only challenge with this perspective is that the Sovrin community has a very fuzzy identity.</p>"},{"location":"concepts/0004-agents/#validators","title":"Validators","text":"<p>Validator nodes on a particular blockchain are agents of the stewards that operate them.</p>"},{"location":"concepts/0004-agents/#digital-assistants","title":"Digital Assistants","text":"<p>Digital assistants like Alexa and Google Home are somewhat agent-like. However, the Alexa in the home of the Jones family is probably not an agent for either the Jones family or Amazon. It accepts delegated work from anybody who talks to it (instead of a single controlling identity), and all current implementations are totally antithetical to the ethos of privacy and security required by self-sovereign identity. Although it interfaces with Amazon to download data and ../../features, it isn't Amazon's fiduciary, either. It doesn't hold keys that allow it to represent its owner. The protocols it uses are not interactions with other agents, but with non-agent entities. Perhaps agents and digtal assistants will converge in the future.</p>"},{"location":"concepts/0004-agents/#doorbell","title":"Doorbell","text":"<p>An doorbell that emits a simple signal each time it is pressed is not an agent. It doesn't represent a fiduciary or hold keys. (However, a fancy IoT doorbell that reports to Alice's mobile agent using an A2A protocol would be an agent.)</p>"},{"location":"concepts/0004-agents/#microservices","title":"Microservices","text":"<p>A microservice run by AcmeCorp to integrate with its vendors is not an agent for Acme's vendors. Depending on whether it holds keys and uses A2A protocols, it may or may not be an agent for Acme.</p>"},{"location":"concepts/0004-agents/#human-delegates","title":"Human Delegates","text":"<p>A human delegate who proves empowerment through keys might be thought of as an agent.</p>"},{"location":"concepts/0004-agents/#paper","title":"Paper","text":"<p>The keys for an agent can be stored on paper. This storage basically constitutes a wallet. It isn't an agent. However, it can be thought of as playing the role of an agent in some cases when designing backup and recovery solutions.</p>"},{"location":"concepts/0004-agents/#prior-art","title":"Prior art","text":"<ul> <li>Alan Kay, the recipient of a Turing Award and the coiner of the term \"Object-Oriented Programming\", has emphasized the value of message-passing architectures in numerous places. What he called \"objects\" are conceptually similar to what we are calling \"agents.\" Not surprisingly, the agent ecosystem echoes some aspects of the design of SmallTalk, Objective-C, Erlang Actors, Akka Actors, and similar approaches.</li> <li>The design of the web includes the concept of browsers and similar tech, and refers to them as \"user agents\" in various RFCs. These are not true SSI agents, but they provide an example of ubiquitous helper tech that is the forerunner of the agents described here.</li> </ul>"},{"location":"concepts/0004-agents/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community Aries Framework - .NET .NET framework for building agents of all types Streetcred.id Commercial mobile and web app built using Aries Framework for .NET Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Aries Framework - Go For building agents, hubs and other DIDComm ../../features in GoLang. Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem. Aries Protocol Test Suite Pico Labs Pico Agents protocols: connections, trust_ping, basicmessage, routing Rust Agent Rust implementation of a framework for building agents of all types"},{"location":"concepts/0005-didcomm/","title":"Aries RFC 0005: DID Communication","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-11-21</li> <li>Status Note: Mature as concept, with multiple implementations.</li> <li>Supersedes: Indy PR #98</li> <li>Start Date: 2018-01-05 (approx, backdated)</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0005-didcomm/#summary","title":"Summary","text":"<p>Explain the basics of DID communication (DIDComm) at a high level, and link to other RFCs to promote deeper exploration.</p> <p>NOTE: The version of DIDComm collectively defined in Aries RFCs is known by the label \"DIDComm V1.\" A newer version of DIDComm (\"DIDComm V2\") is now being incubated at DIF. Many ../../concepts are the same between the two versions, but there are some differences in the details. For information about detecting V1 versus V2, see Detecting DIDComm Versions.</p>"},{"location":"concepts/0005-didcomm/#motivation","title":"Motivation","text":"<p>The DID communication between agents and agent-like things is a rich subject with a lot of tribal knowledge. Newcomers to the decentralized identity ecosystem tend to bring mental models that are subtly divergent from its paradigm. When they encounter dissonance, DIDComm becomes mysterious. We need a standard high-level reference.</p>"},{"location":"concepts/0005-didcomm/#tutorial","title":"Tutorial","text":"<p>This discussion assumes that you have a reasonable grasp on topics like self-sovereign identity, DIDs and DID docs, and agents. If you find yourself lost, please review that material for background and starting assumptions.</p> <p>Agent-like things have to interact with one another to get work done. How they talk in general is DIDComm, the subject of this RFC. The specific interactions enabled by DIDComm--connecting and maintaining relationships, issuing credentials, providing proof, etc.--are called protocols; they are described elsewhere.</p>"},{"location":"concepts/0005-didcomm/#rough-overview","title":"Rough Overview","text":"<p>A typical DIDComm interaction works like this:</p>  Imagine Alice wants to negotiate with Bob to sell something online, and that DIDComm, not direct human communication, is involved. This means Alice's agent and Bob's agent are going to exchange a series of messages.  Alice may just press a button and be unaware of details, but underneath, her agent begins by preparing a plaintext JSON message about the proposed sale. (The particulars are irrelevant here, but would be described in the spec for a \"sell something\" protocol.) It then looks up Bob's DID Doc to access two key pieces of information:  * An endpoint (web, email, etc) where messages can be delivered to Bob. * The public key that Bob's agent is using in the Alice:Bob relationship.  Now Alice's agent uses Bob's public key to encrypt the plaintext so that only Bob's agent can read it, adding authentication with its own private key. The agent arranges delivery to Bob. This \"arranging\" can involve various hops and intermediaries. It can be complex.  Bob's agent eventually receives and decrypts the message, authenticating its origin as Alice using her public key. It prepares its response and routes it back using a reciprocal process (plaintext -&gt; lookup endpoint and public key for Alice -&gt; encrypt with authentication -&gt; arrange delivery).  <p>That's it.</p> <p>Well, mostly. The description is pretty good, if you squint, but it does not fit all DIDComm interactions:</p> <ul> <li>DIDComm doesn't always involve turn-taking and request-response.</li> <li>DIDComm interactions can involve more than 2 parties, and the parties are not always individuals.</li> <li>DIDComm may include formats other than JSON.</li> </ul> <p>Before we provide more details, let's explore what drives the design of DIDComm.</p>"},{"location":"concepts/0005-didcomm/#goals-and-ramifications","title":"Goals and Ramifications","text":"<p>The DIDComm design attempts to be:</p> <ol> <li>Secure</li> <li>Private</li> <li>Interoperable</li> <li>Transport-agnostic</li> <li>Extensible</li> </ol> <p>As a list of buzz words, this may elicit nods rather than surprise. However, several items have deep ramifications.</p> <p>Taken together, Secure and Private require that the protocol be decentralized and maximally opaque to the surveillance economy.</p> <p>Interoperable means that DIDComm should work across programming languages, blockchains, vendors, OS/platforms, networks, legal jurisdictions, geos, cryptographies, and hardware--as well as across time. That's quite a list. It means that DIDComm intends something more than just compatibility within Aries; it aims to be a future-proof lingua franca of all self-sovereign interactions.</p> <p>Transport-agnostic means that it should be possible to use DIDComm over HTTP(S) 1.x and 2.0, WebSockets, IRC, Bluetooth, AMQP, NFC, Signal, email, push notifications to mobile devices, Ham radio, multicast, snail mail, carrier pigeon, and more.</p> <p>All software design involves tradeoffs. These goals, prioritized as shown, lead down an interesting path.</p>"},{"location":"concepts/0005-didcomm/#message-based-asynchronous-and-simplex","title":"Message-Based, Asynchronous, and Simplex","text":"<p>The dominant paradigm in mobile and web development today is duplex request-response. You call an API with certain inputs, and you get back a response with certain outputs over the same channel, shortly thereafter. This is the world of OpenAPI (Swagger), and it has many virtues.</p> <p>Unfortunately, many agents are not good analogs to web servers. They may be mobile devices that turn off at unpredictable intervals and that lack a stable connection to the network. They may need to work peer-to-peer, when the internet is not available. They may need to interact in time frames of hours or days, not with 30-second timeouts. They may not listen over the same channel that they use to talk.</p> <p>Because of this, the fundamental paradigm for DIDComm is message-based, asynchronous, and simplex. Agent X sends a message over channel A. Sometime later, it may receive a response from Agent Y over channel B. This is much closer to an email paradigm than a web paradigm.</p> <p>On top of this foundation, it is possible to build elegant, synchronous request-response interactions. All of us have interacted with a friend who's emailing or texting us in near-realtime. However, interoperability begins with a least-common-denominator assumption that's simpler.</p>"},{"location":"concepts/0005-didcomm/#message-level-security-reciprocal-authentication","title":"Message-Level Security, Reciprocal Authentication","text":"<p>The security and privacy goals, and the asynchronous+simplex design decision, break familiar web assumptions in another way. Servers are commonly run by institutions, and we authenticate them with certificates. People and things are usually authenticated to servers by some sort of login process quite different from certificates, and this authentication is cached in a session object that expires. Furthermore, web security is provided at the transport level (TLS); it is not an independent attribute of the messages themselves.</p> <p>In a partially disconnected world where a comm channel is not assumed to support duplex request-response, and where the security can't be ignored as a transport problem, traditional TLS, login, and expiring sessions are impractical. Furthermore, centralized servers and certificate authorities perpetuate a power and UX imbalance between servers and clients that doesn't fit with the peer-oriented DIDComm.</p> <p>DIDComm uses public key cryptography, not certificates from some parties and passwords from others. Its security guarantees are independent of the transport over which it flows. It is sessionless (though sessions can easily be built atop it). When authentication is required, all parties do it the same way.</p>"},{"location":"concepts/0005-didcomm/#reference","title":"Reference","text":"<p>The following RFCs profide additional information: * 0021: DIDComm Message Anatomy * 0020: Message Types * 0011: Decorators * 0008: Message ID and Threading * 0019: Encryption Envelope * 0025: Agent Transports</p>"},{"location":"concepts/0005-didcomm/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community Aries Framework - .NET .NET framework for building agents of all types Streetcred.id Commercial mobile and web app built using Aries Framework - .NET Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Aries Framework - Go For building agents, hubs and other DIDComm ../../features in GoLang. Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem. Aries Protocol Test Suite Pico Labs Pico Agents protocols: connections, trust_ping, basicmessage, routing"},{"location":"concepts/0006-ssi-notation/","title":"Aries RFC 0006: SSI Notation","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2018-09-01</li> <li>Status Note: broadly accepted but not heavily used; may need greater usage before it's ready for ADOPTED status.</li> <li>Start Date: 2018-05-03</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0006-ssi-notation/#summary","title":"Summary","text":"<p>This RFC describes a simple, standard notation for various ../../concepts related to decentralized and self-sovereign identity (SSI).</p> <p>The notation could be used in design docs, other RFCs, source code comments, chat channels, scripts, debug logs, and miscellaneous technical materials throughout the Aries ecosystem. We hope it is also used in the larger SSI community.</p> <p>This RFC is complementary to official terms like the ones curated in the TOIP Concepts and Terminology Working group, the Sovrin Glossary, and so forth.</p>"},{"location":"concepts/0006-ssi-notation/#motivation","title":"Motivation","text":"<p>All technical materials in our ecosystem hinge on fundamental ../../concepts of self-sovereign identity such as controllers, keys, DIDs, and agents. We need a standard, documented notation to refer to such things, so we can use it consistently, and so we can link to the notation's spec for definitive usage.</p>"},{"location":"concepts/0006-ssi-notation/#tutorial","title":"Tutorial","text":"<p>The following explanation is meant to be read sequentially and should provide a friendly overview for most who encounter the RFC. See the Reference section for quick lookup.</p>"},{"location":"concepts/0006-ssi-notation/#requirements","title":"Requirements","text":"<p>This notation aims to be:</p> <ul> <li>Precise</li> <li>Consistent</li> <li>Terse</li> <li>Easy to learn, understand, guess, and remember</li> <li>Representable in 7-bit ASCII plain text</li> </ul> <p>The final requirement deserves special comment. Cryptologists are a major stakeholder in SSI theory. They already have many notational conventions, some more standardized than others. Generally, their notation derives from advanced math and uses specialized symbols and fonts. These experts also tend to intersect strongly with academic circles, where LaTeX and similar rendering technologies are common.</p> <p>Despite the intersection between SSI, cryptology, and academia, SSI has to serve a broader audience. Its practicioners are not just mathematicians; they may include support and IT staff, lawyers specializing in intellectual property, business people, auditors, regulators, and individuals sometimes called \"end users.\" In particular, SSI ecosystems are built and maintained by coders. Coders regularly write docs in markdown and html. They interact with one another on chat. They write emails and source code where comments might need to be embedded. They create UML diagrams. They type in shells. They paste code into slide decks and word processors. All of these behaviors militate against a notation that requires complex markup.</p> <p>Instead, we want something simple, clean, and universally supported. Hence the 7-bit ASCII requirement. A future version of this RFC, or an addendum to it, might explain how to map this 7-bit ASCII notation to various schemes that use mathematical symbols and are familiar to experts from other fields.</p>"},{"location":"concepts/0006-ssi-notation/#solution","title":"Solution","text":""},{"location":"concepts/0006-ssi-notation/#controllers-and-subjects","title":"Controllers and Subjects","text":"<p>An identified thing (the referent of an identifier) is called an identity subject. Identity subjects can include:</p> <ul> <li>passive things (pets, digital documents, symphonies, rivers, asteroids, strains of bacteria...)</li> <li>active things (people, institutions, IoT devices)</li> </ul> <p>The latter category may also act as an identity controller -- something that projects its intent with respect to identity onto the digital landscape.</p> <p>When an identity controller controls its own identity, we say that it has self sovereignty -- and we call it a self. (The term identity owner was originally used for an identity controller managing itself, but this hid some of the nuance and introduced legal ../../concepts of ownership that are problematic, so we'll avoid it here.)</p> <p>In our notation, selves (or identity controllers) are denoted with a single upper-case ASCII alpha, often corresponding to a first initial of their human-friendly name. For example, Alice might be represented as <code>A</code>. By preference, the first half of the alphabet is used (because \"x\", \"y\", and \"z\" tend to have other ad-hoc meanings). When reading aloud, the spoken form of a symbol like this is the name of the letter. The relevant ABNF fragment is:</p> <p>```ABNF   ucase-alpha    = %x41-5A            ; A-Z   lcase-alpha    = %x61-7A            ; a-z   digit          = %x30-39            ; 0-9</p> <p>self = ucase-alpha   ```</p> <p>Identity subjects that are not self-controlled are referenced in our notation using a single lower-case ASCII alpha. For example, a movie might be <code>m</code>. For clarity in scenarios where multiple subjects are referenced, it is best to choose letters that differ in something other than case.</p> <pre><code>  controlled = lcase-alpha\n\n  subject = self / controlled\n</code></pre> <p>The set of devices, keys, endpoints, data, and other resources controlled by or for a given subject is called the subject's identity domain (or just domain for short). When the controller is a self, the domain is self-sovereign; otherwise, the domain is controlled. Either way, the domain of an identity subject is like its private universe, so the name or symbol of a subject is often used to denote its domain as well; context eliminates ambiguity. You will see examples of this below.</p>"},{"location":"concepts/0006-ssi-notation/#association","title":"Association","text":"<p>Elements associated with a domain are named in a way that makes their association clear, using a <code>name@context</code> pattern familiar from email addresses: <code>1@A</code> (\u201cone at A\u201d) is agent 1 in A\u2019s sovereign domain. (Note how we use an erstwhile identity owner symbol, <code>A</code>, to reference a domain here, but there is no ambiguity.) This fully qualified form of a subject reference is useful for clarification but is often not necessary.</p> <p>In addition to domains, this same associating notation may be used where a relationship is the context, because sometimes the association is to the relationship rather than to a participant. See the DID example in the next section.</p>"},{"location":"concepts/0006-ssi-notation/#agents","title":"Agents","text":"<p>Agents are not subjects. They neither control or own a domain; rather, they live and act within it. They take instructions from the domain's controller. Agents (and hubs, and other things like them) are the first example of elements associated with an identity subject. Despite this, agent-ish things are the primary focus of interactions within SSI ecosystems.</p> <p>Additionally, agents are distinct from devices, even though we often (and inaccurately) used them interchangeably. We may say things like \"Alice's iPhone sends a message\" when we more precisely mean \"the agent on Alice's iPhone sends a message.\" In reality, there may be zero, one, or more than one agents running on a particular device.</p> <p>Agents are numbered and are represented by up to three digits and then with an association. In most discussions, one digit is plenty, but three digits are allowed so agents can be conveniently grouped by prefix (e.g., all edge agents in Alice's domain might begin with <code>1</code>, and all cloud might begin with <code>2</code>).</p> <pre><code>agent = 1*3digit \"@\" subject\n</code></pre>"},{"location":"concepts/0006-ssi-notation/#devices","title":"Devices","text":"<p>Devices are another element inside a subject's domain. They are represented with two or more lower-case ASCII alphanumerics or underscore characters, where the first char cannot be a digit. They end with an association: <code>bobs_car@B</code>, <code>drone4@F</code>, <code>alices_iphone9@A</code>.</p> <pre><code>name-start-char = lcase-alpha / \"_\"            ; a-z or underscore\nname-other-char = digit / lcase-alpha / \"_\"    ; 0-9 or a-z or underscore\ndevice = name-start-char 1*name-other-char \"@\" subject\n</code></pre>"},{"location":"concepts/0006-ssi-notation/#cross-domain-relationships","title":"Cross-Domain Relationships","text":""},{"location":"concepts/0006-ssi-notation/#short-form-more-common","title":"Short Form (more common)","text":"<p>Alice\u2019s pairwise relationship with Bob is represented with colon notation: <code>A:B</code>. This is read aloud as \u201cA to B\u201d (preferred because it\u2019s short; alternatives such as \u201cthe A B relationship\u201d or \u201cA colon B\u201d or \u201cA with respect to B\u201d are also valid). When written in the other order, it represents the same relationship as seen from Bob\u2019s point of view. Note that passive subjects may also participate in relationships: <code>A:bobs_car</code>. (Contrast Intra-Domain Relationships below.)</p> <p>N-wise relationships (e.g., doctor, hospital, patient) are written with the perspective-governing subject's identifier, a single colon, then by all other identifiers for members of the relationship, in alphabetical order, separated by <code>+</code>: <code>A:B+C</code>, <code>B:A+C</code>. This is read aloud as in \"A to B plus C.\"</p> <pre><code>next-subject = \"+\" subject\nshort-relationship = subject \":\" subject *next-subject\n</code></pre>"},{"location":"concepts/0006-ssi-notation/#long-form","title":"Long Form","text":"<p>Short form is convenient and brief, but it is inconsistent because each party to the relationship describes it differently. Sometimes this may be undesirable, so a long and consistent form is also supported. The long form of both pairwise and N-way relationships lists all participants to the right of the colon, in alphabetical order. Thus the long forms of the Alice to Bob relationship might be <code>A:A+B</code> (for Alice's view of this relationship) and <code>B:A+B</code> (for Bob's view). For a doctor, hospital, patient relationship, we might have <code>D:D+H+P</code>, <code>H:D+H+P</code>, and <code>P:D+H+P</code>. Note how the enumeration of parties to the right of the colon is consistent.</p> <p>Long form and short form are allowed to vary freely; any tools that parses this notation should treat them as synonyms and stylistic choices only.</p> <p>The ABNF for long form is identical to short form, except that we are guaranteed that after the colon, we will see at least two parties and one <code>+</code> character:</p> <pre><code>long-relationship = subject \":\" subject 1*next-subject\n</code></pre>"},{"location":"concepts/0006-ssi-notation/#generalized-relationships","title":"Generalized Relationships","text":""},{"location":"concepts/0006-ssi-notation/#contexts","title":"Contexts","text":"<p>Some models for SSI emphasize the concept of personas or contexts. These are essentially \"masks\" that an identity controller enables, exposing a limited subset of the subject's identity to an audience that shares that context. For example, Alice might assume one persona in her employment relationships, another for government interactions, another for friends, and another when she's a customer.</p> <p>Contexts or personas can be modeled as a relationship with a generalized audience: <code>A:Work</code>, <code>A:Friends</code>.</p> <pre><code>general-audience = ucase-alpha 1*name-other-char\ngeneral-relationship = subject \":\" general-audience\nrelationship = short-relationship / long-relationship / general-relationship\n</code></pre>"},{"location":"concepts/0006-ssi-notation/#any","title":"Any","text":"<p>The concept of public DIDs suggests that someone may think about a relationship as unbounded, or as not varying no matter who the other subject is. For example, a company may create a public DID and advertise it to the world, intending for this connection point to begin relationships with customers, partners, and vendors alike. While best practice suggests that such relationships be used with care, and that they primarily serve to bootstrap pairwise relationships, the notation still needs to represent the possibility.</p> <p>The token <code>Any</code> is reserved for these semantics. If Acme Corp is represented as <code>A</code>, then Acme's public persona could be denoted with <code>A:Any</code>. When <code>Any</code> is used, it is never the subject whose perspective is captured; it is always a faceless \"other\". This means that <code>Any</code> appears only on the right side of a colon in a relationship, and it probably doesn't make sense to combine it with other participants since it would subsume them all.</p>"},{"location":"concepts/0006-ssi-notation/#self","title":"Self","text":"<p>It is sometimes useful to model a relationship with onesself. This is done with the reserved token <code>Self</code>.</p>"},{"location":"concepts/0006-ssi-notation/#intra-domain-relationships","title":"Intra-Domain Relationships","text":"<p>Within a domain, relationships among agents or devices is sometimes interesting. Such relationships use the <code>~</code> (tilde) character. Thus, the intra-domain relationship between Alice's agent 1 and agent 2 is written <code>1~2</code> and read as \"one tilde two\".</p>"},{"location":"concepts/0006-ssi-notation/#constituents","title":"Constituents","text":"<p>Items that belong to a domain rather than having independent identity of their own (for example, data, money, keys) use dot notation for containment or ownership: <code>A.ls</code>, (A\u2019s link secret), <code>A.policy</code>, etc.</p> <p>Names for constituents use the same rules as names for agents and devices.</p> <p>Alice\u2019s DID for her relationship with Bob is an inert constituent datum, but it is properly associated with the relationship rather than just Alice. It is thus represented with <code>A.did@A:B</code>. (The token <code>did</code> is reserved for DIDs). This is read as \u201cA\u2019s DID at A to B\u201d. Bob\u2019s complementary DID would be <code>B.did@B:A</code>.</p> <pre><code>inert = name-start-char 1*name-other-char\nnested = \".\" inert\nowned-inert = subject 1*nested\n\nassociated-to = identity-owner / relationship\nassociated = subject 0*nested \"@\" associated-to\n</code></pre> <p>If <code>A</code> has a cloud agent <code>2</code>, then the public key (verification key or verkey) and private, secret key (signing key or sigkey) used by <code>2</code> in <code>A:B</code> would be: <code>2.pk@A:B</code> and <code>2.sk@A:B</code>. This is read as \u201c2 dot P K at A to B\u201d and \u201c2 dot S K at A to B\u201d. Here, <code>2</code> is known to belong to <code>A</code> because it takes <code>A</code>\u2019s perspective on <code>A:B</code>--it would be equivalent but unnecessary to write <code>A.2.pk@A:B</code>.</p>"},{"location":"concepts/0006-ssi-notation/#did-docs-and-did-references","title":"DID Docs and DID References","text":"<p>The mention of keys belonging to agents naturally raises the question of DID docs and the things they contain. How do they relate to our notation?</p> <p>DIDs are designed to be URIs, and items that carry an <code>id</code> property within a DID Doc can be referenced with standard URI fragment notation. This allows someone, for example, to refer to the first public key used by one of the agents owned by Alice with a notation like: <code>did:sov:VUrvFeWW2cPv9hkNZ2ms2a;#key1</code>.</p> <p>This notation is important and useful, but it is somewhat orthogonal to the concerns of this RFC. In the context of SSI notation, we are not DID-centric; we are subject centric, and subject are identified by a single capital alpha instead of by their DID. This helps with brevity. It lets us ignore the specific DID value and instead focus on the higher level semantics; compare:</p> <code>{A.did@A:B}/B --&gt; B</code> <p>...to:</p> <code>did:sov:PXqKt8sVsDu9T7BpeNqBfe</code> sends its DID for <code>did:sov:6tb15mkMRagD7YA3SBZg3p</code> to <code>did:sov:6tb15mkMRagD7YA3SBZg3p</code>, using the agent possessing <code>did:sov:PXqKt8sVsDu9T7BpeNqBfe;#key1</code> to encrypt with the corresponding signing key. <p>We expect DID reference notation (the verbose text above) to be relevant for concrete communication between computers, and SSI notation (the terse equivalent shown first) to be more convenient for symbolic, higher level discussions between human beings. Occasionally, we may get very specific and map SSI notation into DID notation (e.g., <code>A.1.vk = did:sov:PXqKt8sVsDu9T7BpeNqBfe;#key1</code>).</p>"},{"location":"concepts/0006-ssi-notation/#counting-and-iteration","title":"Counting and Iteration","text":"<p>Sometimes, a concept or value evolves over time. For example, a given discussion might need to describe a DID Doc or an endpoint or a key across multiple state changes. In mathematical notation, this would typically be modeled with subscripts. In our notation, we use square brackets, and we number beginning from zero. <code>A.pk[0]@A:B</code> would be the first pubkey used by A in the <code>A:B</code> relationship; <code>A.pk[1]@A:B</code> would be the second pubkey, and so on. Likewise, a sequence of messages could be represented with <code>msg[0]</code>, <code>msg[1]</code>, and <code>msg[2]</code>.</p>"},{"location":"concepts/0006-ssi-notation/#messages","title":"Messages","text":"<p>Messages are represented as quoted string literals, or with the reserved token <code>msg</code>, or with kebab-case names that explain their semantics, as in <code>cred-offer</code>:</p> <pre><code>string-literal = %x22 c-literal %x22\nkebab-char = lcase-alpha / digit\nkebab-suffix = \"-\" 1*hint-char\nkebab-msg = 1*kebab-char *kebab-suffix\nmessage = \"msg\" / string-literal / kebab-msg\n</code></pre>"},{"location":"concepts/0006-ssi-notation/#payments","title":"Payments","text":"<p>Economic activity is part of rich SSI ecosystems, and requires notation. A payment address is denoted with the <code>pay</code> reserved token; <code>A.pay[4]</code> would be A's fifth payment address. The public key and secret key for a payment address use the <code>ppk</code> and <code>psk</code> reserved token, respectively. Thus, one way to reference the payment keys for that payment address would be <code>A.pay[4].ppk</code> and <code>A.pay[4].psk</code>. (Keys are normally held by agents, not by people--and every agent has its own keys. Thus, another notation for the public key pertaining to this address might be <code>A.1.pay[4].ppk</code>. This is an area of clumsiness that needs further study.)</p>"},{"location":"concepts/0006-ssi-notation/#encryption","title":"Encryption","text":"<p>Encryption deserves special consideration in the SSI world. It often figures prominently in discussions about security and privacy, and our notation needs to be able to represent it carefully.</p> <p>The following crypto operations are recognized by the notation, without making a strong claim about how the operations are implemented. (For example, inline Diffie Helman and an ephemeral symmetric key might be used for the *_crypt algorithms. What is interesting to the notation isn't the low-level details, but the general semantics achieved.)</p> <ul> <li> <p><code>anon_crypt(msg, recipient_pubkey)</code> -- Encrypt only for recipient, achieving confidentiality. Sender is anonymous. Parties may have had no prior contact, though sender must discover recipient's pubkey. The message is tamper evident.</p> </li> <li> <p><code>auth_crypt(msg, recipient_pubkey, sender_privkey)</code> -- Encrypt only for recipient, achieving confidentiality. Recipient learns sender\u2019s pubkey but can\u2019t prove to anybody else who the sender is (making the message repudiable). Parties may have had no prior contact, though sender must discover recipient's pubkey. The message is tamper evident.</p> </li> <li> <p><code>sign(msg, signer_privkeys)</code> -- Associate a signature with a message, making the message non-repudiable. This also makes the message tamper-evident. A signature does not automatically encrypt and therefore is not a way to achieve confidentiality. Note that complex signature schemes (multisig, M of N, ring) use this operation as well.</p> </li> <li> <p><code>verify(msg, signature, signer_pubkeys)</code> -- Verify a signature over a message with select keys. Note that complex verification schemes (multiverify, M of N, ring) use this operation as well.</p> </li> <li> <p><code>sym_crypt(msg, sym_key)</code> -- Symmetrically encrypt for anyone who has the symmetric key, achieving a limited form of confidentiality. Key must be shared in advance with both parties. Likely tamper evident. If multiple parties know the symmetric key, the sender is not knowable to the recipient.</p> </li> </ul> <p>The notation for these crypto primitives uses curly braces around the message, with suffixes to clarify semantics. Generally, it identifies a recipient as an identity owner or thing, without clarifying the key that's used--the pairwise key for their DID is assumed.</p> <pre><code>asymmetric   = \"/\"                                   ; suffix\nsymmetric    = \"*\"                                   ; suffix\nsign         = \"#\"                                   ; suffix\nmultiplex    = \"%\"                                   ; suffix\nverify       = \"?\"                                   ; suffix\n\nanon-crypt   = \"{\" message \"}\" asymmetric subject          ; e.g., {\"hi\"}/B\n\n                ; sender is first subject in relationship, receiver is second\nauth-crypt   = \"{\" message \"}\" asymmetric short-relationship ; e.g., {\"hi\"}/A:B\n\nsym-crypt    = \"{\" message \"}\" symmetric subject           ; e.g., {\"hi\"}*B\n\nverify       = \"{\" message \"}\" verify subject              ; e.g., {\"hi\"}?B\n</code></pre> <p>The relative order of suffixes reflects whether encryption or signing takes place first: <code>{\"hello\"}*B#</code> says that symmetric encryption happens first, and then a signature is computed over the cypertext; <code>{\"hello\"#}*B</code> says that plaintext is signed, and then both the plaintext and the signature are encrypted. (The <code>{\"hello\"}#*B</code> variant is nonsensical because it splits the encryption notation in half).</p> <p>All suffixes can be further decorated with a parenthesized algorithm name, if precision is required: <code>{\"hello\"}*(aes256)B</code> or <code>{\"hello\"}/(rsa1024)A:B</code> or <code>{\"hello\"#(ecdsa)}/B</code>.</p> <p>With signing, usually the signer and sender are assumed to be identical, and the notation omits any clarification about the signer. However, this can be added after <code>#</code> to be explicit. Thus, <code>{msg#B}/C</code> would be a message with plaintext signed by B, anon-encrypted for C. Similarly, <code>{msg#(ring-rabin)BGJM}/A:C</code> would be a message with plaintext signed according to a Rabin ring signature algorithm, by B, G, J, and M, and then auth-encrypted by A for C.</p> <p>Signing verification would be over the corresponding message and which entities perform the action. <code>{msg#A}?B</code> would be a message with plaintext signed by A verified by B. <code>{msg#(threshold-sig)ABC}?DE</code> would be a plaintext message signed according to a threshold signature algorithm by A, B, C and then verified by D and E.</p> <p>Multiplexed asymmetric encryption is noted above, but has not yet been described. This is a technique whereby a message body is encrypted with an ephemeral symmetric key, and then the ephemeral key is encrypted asymmetrically for multiple potential recipients (each of which has a unique but tiny payload [the key] to decrypt, which in turn unlocks the main payload). The notation for this looks like <code>{msg}%BCDE</code> for multiplexed anon_crypt (sender is anonymous), and like <code>{msg}%A:BCDE</code> for multiplexed auth_crypt (sender is authenticated by their private key).</p>"},{"location":"concepts/0006-ssi-notation/#other-punctuation","title":"Other punctuation","text":"<p>Message sending is represented with arrows: <code>-&gt;</code> is most common, though <code>&lt;-</code> is also reasonable in some cases. Message content and notes about sending can be embedded in the hyphens of sending arrow, as in this example, where the notation says an unknown party uses http to transmit \"hello\", anon-enrcypted for Alice:</p> <p><code>&lt;unknown&gt; -- http: {\"hello\"}/A --&gt; 1</code></p> <p>Parentheses have traditional meaning (casual usage in written language, plus grouping and precedence).</p> <p>Angle braces <code>&lt;</code> and <code>&gt;</code> are for placeholders; any reasonable explanatory text may appear inside the angle braces, so to represent Alice's relationship with a not-yet-known subject, the notation might show something like <code>A:&lt;TBD&gt;</code>.</p>"},{"location":"concepts/0006-ssi-notation/#reference","title":"Reference","text":""},{"location":"concepts/0006-ssi-notation/#examples","title":"Examples","text":"<ul> <li><code>A</code>: a self (sovereign identity subject) like Alice or Acme Corp.</li> <li><code>alices_pixel@A</code> or <code>bobs_alexa@B</code>: an object in a given domain</li> <li><code>7@A</code>: an agent, arbitrarily assigned number 7</li> <li><code>A:B</code> or <code>A:A+B</code>: The Alice to Bob relationship, as seen from Alice's perspective (short form, then long form). Bob's view of this relationship would be <code>B:A</code> or <code>B:A+B</code>.</li> <li><code>B:ACD</code> or <code>B:A+B+C+D</code>: The 4-way relationship between A, B, C, and D, as seen from B's perspective (short form, then long form)</li> <li><code>A:Dating</code>: Alice's dating persona</li> <li><code>A.pay[3].ppk</code>: The public payment key for the fourth payment address belonging to A.</li> <li><code>F.did@F:Any</code>: Faber's public DID.</li> <li><code>C.ls</code>: Carol's link secret.</li> <li><code>D.padr</code>: Doug's policy address.</li> <li><code>F.state@F:A</code>: F's state for the F:A relationship.</li> <li><code>A.uri@A:B</code>: Alice's URI (endpoint of DID doc) in the Alice to Bob relationship.</li> <li><code>F.uri@F:Any</code>: The endpoint where the DID doc for Faber's public DID is hosted.</li> <li><code>escrow-offer</code>: A message that represents step 1a in a standard negotiation about escrow. (The escrow concept is unknown to the notation, and we don't know the format of its messages, but we know they are used in a standard way because of the <code>-offer</code> kebab suffix).</li> <li><code>{msg}/A</code>: A message anon-encrypted for A.</li> <li><code>{\"hello\"}/A:B</code>: A message auth-encrypted for B by A.</li> <li><code>{bail-req#(p2sh)DF}/(rsa)B</code>: A message that represents step 1b or step 2 in a standard negotiaion about bail. This message was signed as plaintext using the p2sh multisig algorithm by D and F, and was then anon-encrypted for B using an RSA algorithm.</li> <li><code>{advice-receipt}*A</code>: A message that that represents step 4 in a standard negotiaion about advice. The message was symmetrically encrypted and sent to A.</li> <li><code>{msg[4]}%C:1+2</code>: A message (5<sup>th</sup> in sequence) that was multiplex-encrypted by C for agents 1 and 2.</li> </ul>"},{"location":"concepts/0006-ssi-notation/#reserved-tokens","title":"Reserved Tokens","text":"<ul> <li><code>Any</code>: The name for the public side of a relationship between a specific subject and the public.</li> <li><code>Self</code>: The name for one's one identity in a self relationship.</li> <li><code>did</code>: The DID belonging to an subject in a given relationship, as in <code>A.did@A:B</code></li> <li><code>ipk</code> and <code>isk</code>: Issuer public (verification) key and issuer secret key.</li> <li><code>key</code>: A symmetric key.</li> <li><code>ls</code>: The link secret belonging to an subject, as in <code>A.ls</code>.</li> <li><code>state</code>: The state belonging to an subject in a given relationship, as in <code>A.state@A:B</code></li> <li><code>msg</code>: A generic message.</li> <li><code>-offer</code>: kebab suffix for messages that express willingness to give    something.</li> <li><code>padr</code>: a policy address, as in <code>F.padr</code>.</li> <li><code>pay</code>: A payment address belonging to an identity owner, as in <code>C.pay</code>.</li> <li><code>ppk</code> and <code>psk</code>: Payment address public (verification) and secret key (control    cryptocurrency).</li> <li><code>pk</code>: The public verification key (verkey) portion of an asymmetric keypair. The more specific form, <code>vk</code>, is only recommended if elliptic curve crypto is specifically intended.</li> <li><code>-receipt</code>: kebab suffix for messages that formally acknowledge receipt after receiving a delivered item.</li> <li><code>-req</code>: kebab suffix for messages that formally request something.</li> <li><code>rpk</code> and <code>rsk</code>: Revocation public (verification) and secret key.</li> <li><code>sk</code>: The private key (privkey, sigkey) portion of an asymmetric keypair.</li> <li><code>uri</code>: An endpoint for a relationship, as in <code>B.uri@A:B</code></li> <li><code>vk</code>: The public verification key (verkey) portion of an asymmetric keypair. The more generic form, <code>pk</code>, is recommended instead, unless elliptic curve crypto is specifically intended.</li> <li><code>wallet</code>: An identity wallet belonging to an subject.</li> </ul>"},{"location":"concepts/0006-ssi-notation/#abnf","title":"ABNF","text":"<pre><code>ucase-alpha    = %x41-5A                        ; A-Z\nlcase-alpha    = %x61-7A                        ; a-z\ndigit          = %x30-39                        ; 0-9\nname-start-char = lcase-alpha / \"_\"             ; a-z or underscore\nname-other-char = digit / lcase-alpha / \"_\"     ; 0-9 or a-z or underscore\n\nidentity-owner = ucase-alpha\nthing = lcase-alpha\nsubject = identity-owner / thing\n\nagent = 1*3digit \"@\" subject\ndevice = name-start-char 1*name-other-char \"@\" subject\n\nnext-subject = \"+\" subject\nshort-relationship = subject \":\" subject *next-subject\nlong-relationship = subject \":\" subject 1*next-subject\ngeneral-audience = ucase-alpha 1*name-other-char\ngeneral-relationship = subject \":\" general-audience\nrelationship = short-relationship / long-relationship / general-relationship\n\ninert = name-start-char 1*name-other-char\nnested = \".\" inert\nowned-inert = subject 1*nested\n\nassociated-to = identity-owner / relationship\nassociated = subject 0*nested \"@\" associated-to\n\nstring-literal = %x22 c-literal %x22\nkebab-char = lcase-alpha / digit\nkebab-suffix = \"-\" 1*hint-char\nkebab-msg = 1*kebab-char *kebab-suffix\nmessage = \"msg\" / string-literal / kebab-msg\n\nasymmetric   = \"/\"                                   ; suffix\nsymmetric    = \"*\"                                   ; suffix\nsign         = \"#\"                                   ; suffix\nmultiplex    = \"%\"                                   ; suffix\n\nanon-crypt   = \"{\" message \"}\" asymmetric subject          ; e.g., {\"hi\"}/B\n\n                ; sender is first subject in relationship, receiver is second\nauth-crypt   = \"{\" message asymmetric short-relationship ; e.g., {\"hi\"}/A:B\n\nsym-crypt    = \"{\" message \"}\" symmetric subject           ; e.g., {\"hi\"}*B\n</code></pre>"},{"location":"concepts/0006-ssi-notation/#drawbacks","title":"Drawbacks","text":"<ul> <li>Creates one more formalism to learn. SSI is already a dense topic with a steep learning curve.</li> <li>Creates something that needs to be version-controlled.</li> </ul>"},{"location":"concepts/0006-ssi-notation/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Could use informal verbiage instead. However, it would be inconsistent and poorly documented.</li> </ul>"},{"location":"concepts/0006-ssi-notation/#prior-art","title":"Prior art","text":"<ul> <li> <p>LaTeX provides powerful and beautiful rendering of complex formal ../../concepts, and uses escape sequences that are pure ASCII. There is a JVM-based parser/renderer for Latex; perhaps similar things exist for other programming languages as well.</p> <p>However, LaTeX has drawbacks. It focuses on rendering, not on the semantics behind what's rendered. In this respect, it is a bit like HTML 1.0 before CSS--you can bold or underline, but you're usually encoding what something looks like, not what it means. (LaTeX does support logical styles and sections, but this introduces far more complexity than we need.)</p> <p>The LaTeX snippet <code>e^{-x_y}</code> should render like this:</p> <p></p> <p>This is great--but it doesn't say anything about what <code>e</code>, <code>x</code>, and <code>y</code> mean. Thus a LaTeX solution would still have to define conventions for meaning in a separate spec. These conventions would have to find representations that are not obvious (LaTeX recommends no particular rendering for encryption functions, keys, ownership, association). And such a spec would have to be careful not to ascribe meaning to a rendering that conflicts with assumptions of knowledgeable LaTeX users (e.g., using <code>\\sqrt</code> for something other than its mathematical square root function in the vocabulary would raise eyebrows).</p> <p>Highly formatted LaTeX is also quite verbose.</p> <p>A very simple form of LaTeX could be used (e.g., just superscripts and subscripts)-- but this would have to solve some of the problems mentioned below, in the DKMS section.</p> </li> <li> <p>ASCIIMath has many of the same benefits and drawbacks as LaTeX. It is less ubiquitous.</p> </li> <li> <p>The key management notation introduced in \"DKMS (Decentralized Key Management System) V3\" overlaps significantly with the concerns of this notation (render this diagram for an example). However, it does not encompass all the concerns explored here, so it would have to be expanded before it could be complete.</p> </li> </ul> <p>Also, experiments with superscripts and subscripts in this format led to semantic   dead ends or undesirable nesting when patterns were applied consistently. For   example, one thought had us representing Alice's verkey, signing key, and DID for her   Bob relationship with A<sub>B</sub><sup>VK</sup>, A<sub>B</sub><sup>SK</sup>.   and A<sub>B</sub><sup>DID</sup>. This was fine until we asked how to represent   the verkey for Alice's agent in the Alice to Bob relationship; is that   A<sub>B</sub><sup>DID<sup>VK</sup></sup>? And what about Alice's link secret, that   isn't relationship-specific? And how would we handle N-way relationships?</p>"},{"location":"concepts/0006-ssi-notation/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Do we need to support non-ASCII characters in the notation? (I suggest no--for coders   wishing to share simple algebra-like notes in comments or on chat, ASCII is a reasonable   least-common denominator usable with any keyboard or natural language. Adding more complicates   too many things.)</li> <li>Do we need special notation for credentials, proofs, and the like? If so, how does   this relate to ZKLang?</li> <li>Do we need notation for security contexts of messages?</li> </ul>"},{"location":"concepts/0006-ssi-notation/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Peer DID Method Spec uses notation in diagrams"},{"location":"concepts/0008-message-id-and-threading/","title":"Aries RFC 0008: Message ID and Threading","text":"<ul> <li>Authors: Daniel Bluhm, Sam Curren, Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2018-10-01</li> <li>Status Note: Implemented broadly in Indy, but not yet elsewhere.</li> <li>Start Date: 2018-08-03</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0008-message-id-and-threading/#summary","title":"Summary","text":"<p>Definition of the message @id field and the ~thread decorator.</p>"},{"location":"concepts/0008-message-id-and-threading/#motivation","title":"Motivation","text":"<p>Referring to messages is useful in many interactions. A standard method of adding a message ID promotes good patterns in message families. When multiple messages are coordinated in a message flow, the threading pattern helps avoid having to re-roll the same spec for each message family that needs it.</p>"},{"location":"concepts/0008-message-id-and-threading/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0008-message-id-and-threading/#message-ids","title":"Message IDs","text":"<p>Message IDs are specified with the @id attribute, which comes from JSON-LD. The sender of the message is responsible for creating the message ID, and any message can be identified by the combination of the sender and the message ID. Message IDs should be considered to be opaque identifiers by any recipients.</p>"},{"location":"concepts/0008-message-id-and-threading/#message-id-requirements","title":"Message ID Requirements","text":"<ul> <li>A short stream of characters matching regex <code>[-_./a-ZA-Z0-9]{8,64}</code> (Note the   special semantics of a dotted suffix on IDs,   as described in the message tracing HIPE proposal)</li> <li>Should be compared case-sensitive (no case folding)</li> <li>Sufficiently unique</li> <li>UUID recommended</li> </ul>"},{"location":"concepts/0008-message-id-and-threading/#example","title":"Example","text":"<pre><code>{\n    \"@type\": \"did:example:12345...;spec/example_family/1.0/example_type\",\n    \"@id\": \"98fd8d72-80f6-4419-abc2-c65ea39d0f38\",\n    \"example_attribute\": \"stuff\"\n}\n</code></pre> <p>The following was pulled from this document written by Daniel Hardman and stored in the Sovrin Foundation's <code>protocol</code> repository.</p>"},{"location":"concepts/0008-message-id-and-threading/#threaded-messages","title":"Threaded Messages","text":"<p>Message threading will be implemented as a decorator to messages, for example:</p> <pre><code>{\n    \"@type\": \"did:example:12345...;spec/example_family/1.0/example_type\",\n    \"@id\": \"98fd8d72-80f6-4419-abc2-c65ea39d0f38\",\n    \"~thread\": {\n        \"thid\": \"98fd8d72-80f6-4419-abc2-c65ea39d0f38\",\n        \"pthid\": \"1e513ad4-48c9-444e-9e7e-5b8b45c5e325\",\n        \"sender_order\": 3,\n        \"received_orders\": {\"did:sov:abcxyz\":1},\n        \"goal_code\": \"aries.vc.issue\"\n    },\n    \"example_attribute\": \"example_value\"\n}\n</code></pre> <p>The <code>~thread</code> decorator is generally required on any type of response, since this is what connects it with the original request.</p> <p>While not recommended, the initial message of a new protocol instance MAY have an empty (<code>{}</code>) <code>~thread</code> item. Aries agents receiving a message with an empty <code>~thread</code> item MUST gracefully handle such a message.</p>"},{"location":"concepts/0008-message-id-and-threading/#thread-object","title":"Thread object","text":"<p>A thread object has the following fields discussed below:</p> <ul> <li><code>thid</code>: The ID of the message that serves as the thread start.</li> <li><code>pthid</code>: An optional parent <code>thid</code>. Used when branching or nesting a new interaction off of an existing one.</li> <li><code>sender_order</code>: A number that tells where this message fits in the sequence of all messages that the current sender has contributed to this thread.</li> <li><code>received_orders</code>: Reports the highest <code>sender_order</code> value that the sender has seen   from other sender(s) on the thread. (This value is often missing if it   is the first message in an interaction, but should be used otherwise,   as it provides an implicit ACK.)</li> <li><code>goal_code</code>: Optional. See RFC 0519: Goal Codes.</li> </ul>"},{"location":"concepts/0008-message-id-and-threading/#thread-id-thid","title":"Thread ID (<code>thid</code>)","text":"<p>Because multiple interactions can happen simultaneously, it's important to differentiate between them. This is done with a Thread ID or <code>thid</code>.</p> <p>If the Thread object is defined and a <code>thid</code> is given, the Thread ID is the value given there. But if the Thread object is not defined in a message, the Thread ID is  implicitly defined as the Message ID (<code>@id</code>) of the given message and that message is the first message of a new thread.</p>"},{"location":"concepts/0008-message-id-and-threading/#sender-order-sender_order","title":"Sender Order (<code>sender_order</code>)","text":"<p>It is desirable to know how messages within a thread should be ordered. However, it is very difficult to know with confidence the absolute ordering of events scattered across a distributed system. Alice and Bob may each send a message before receiving the other's response, but be unsure whether their message was composed before the other's. Timestamping cannot resolve an impasse. Therefore, there is no unified absolute ordering of all messages within a thread--but there is an ordering of all messages emitted by a each participant.</p> <p>In a given thread, the first message from each party has a <code>sender_order</code> value of 0, the second message sent from each party has a <code>sender_order</code> value of 1, and so forth. Note that both Alice and Bob use 0 and 1, without regard to whether the other party may be known to have used them. This gives a strong ordering with respect to each party's messages, and it means that any message can be uniquely identified in an interaction by its <code>thid</code>, the sender DID and/or key, and the <code>sender_order</code>.</p>"},{"location":"concepts/0008-message-id-and-threading/#received-orders-received_orders","title":"Received Orders (<code>received_orders</code>)","text":"<p>In an interaction, it may be useful for the recipient of a message to know if their last message was received. A <code>received_orders</code> value addresses this need, and could be included as a best practice to help detect missing messages.</p> <p>In the example above, if Alice is the sender, and Bob is identified by <code>did:sov:abcxyz</code>, then Alice is saying, \"Here's my message with index 3 (<code>sender_order</code>=3), and I'm sending it in response to your message 1 (<code>received_orders: {&lt;bob's DID&gt;: 1}</code>. Apparently Alice has been more chatty than Bob in this exchange.</p> <p>The <code>received_orders</code> field is plural to acknowledge the possibility of multiple parties. In pairwise interactions, this may seem odd. However, n-wise interactions are possible (e.g., in a doctor ~ hospital ~ patient n-wise relationship). Even in pairwise, multiple agents on either side may introduce other actors. This may happen even if an interaction is designed to be 2-party (e.g., an intermediate party emits an error unexpectedly).</p> <p>In an interaction with more parties, the <code>received_orders</code> object has a key/value pair for each <code>actor</code>/<code>sender_order</code>, where <code>actor</code> is a DID or a key for an agent:</p> <pre><code>\"received_orders\": {\"did:sov:abcxyz\":1, \"did:sov:defghi\":14}\n</code></pre> <p>Here, the <code>received_orders</code> fragment makes a claim about the last <code>sender_order</code> that the sender observed from <code>did:sov:abcxyz</code> and <code>did:sov:defghi</code>. The sender of this fragment is presumably some other DID, implying that 3 parties are participating. Any parties unnamed in <code>received_orders</code> have an undefined value for <code>received_orders</code>. This is NOT the same as saying that they have made no observable contribution to the thread. To make that claim, use the special value <code>-1</code>, as in:</p> <pre><code>\"received_orders\": {\"did:sov:abcxyz\":1, \"did:sov:defghi\":14, \"did:sov:jklmno\":-1}\n</code></pre>"},{"location":"concepts/0008-message-id-and-threading/#example_1","title":"Example","text":"<p>As an example, Alice is an issuer and she offers a credential to Bob.</p> <ul> <li>Alice sends a CRED_OFFER as the start of a new thread, <code>@id</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0.</li> <li>Bob responds with a CRED_REQUEST, <code>@id</code>=&lt;uuid2&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0, <code>received_orders:{alice:0}</code>.</li> <li>Alice sends a CRED, <code>@id</code>=&lt;uuid3&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=1, <code>received_orders:{bob:0}</code>.</li> <li>Bob responds with an ACK, <code>@id</code>=&lt;uuid4&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=1, <code>received_orders:{alice:1}</code>.</li> </ul>"},{"location":"concepts/0008-message-id-and-threading/#nested-interactions-parent-thread-id-or-pthid","title":"Nested interactions (Parent Thread ID or <code>pthid</code>)","text":"<p>Sometimes there are interactions that need to occur with the same party, while an existing interaction is in-flight.</p> <p>When an interaction is nested within another, the initiator of a new interaction can include a Parent Thread ID (<code>pthid</code>). This signals to the other party that this is a thread that is branching off of an existing interaction.</p>"},{"location":"concepts/0008-message-id-and-threading/#nested-example","title":"Nested Example","text":"<p>As before, Alice is an issuer and she offers a credential to Bob. This time, she wants a bit more information before she is comfortable providing a credential.</p> <ul> <li>Alice sends a CRED_OFFER as the start of a new thread, <code>@id</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0.</li> <li>Bob responds with a CRED_REQUEST, <code>@id</code>=&lt;uuid2&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0, <code>received_orders:{alice:0}</code>.</li> <li>Alice sends a PROOF_REQUEST, <code>@id</code>=&lt;uuid3&gt;, <code>pthid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=0. Note the subthread, the parent thread ID, and the reset <code>sender_order</code> value.</li> <li>Bob sends a PROOF, <code>@id</code>=&lt;uuid4&gt;, <code>thid</code>=&lt;uuid3&gt;,<code>sender_order</code>=0, <code>received_orders:{alice:0}</code>.</li> <li>Alice sends a CRED, <code>@id</code>=&lt;uuid5&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=1, <code>received_orders:{bob:0}</code>.</li> <li>Bob responds with an ACK, <code>@id</code>=&lt;uuid6&gt;, <code>thid</code>=98fd8d72-80f6-4419-abc2-c65ea39d0f38, <code>sender_order</code>=1, <code>received_orders:{alice:1}</code>.</li> </ul> <p>All of the steps are the same, except the two bolded steps that are part of a nested interaction.</p>"},{"location":"concepts/0008-message-id-and-threading/#implicit-threads","title":"Implicit Threads","text":"<p>Threads reference a Message ID as the origin of the thread. This allows any message to be the start of a thread, even if not originally intended. Any message without an explicit <code>~thread</code> attribute can be considered to have the following <code>~thread</code> attribute implicitly present.</p> <pre><code>\"~thread\": {\n    \"thid\": &lt;same as @id of the outer message&gt;,\n    \"sender_order\": 0\n}\n</code></pre>"},{"location":"concepts/0008-message-id-and-threading/#implicit-replies","title":"Implicit Replies","text":"<p>A message that contains a <code>~thread</code> block with a <code>thid</code> different from the outer message <code>@id</code>, but no <code>sender_order</code> is considered an implicit reply. Implicit replies have a <code>sender_order</code> of <code>0</code> and an <code>received_orders:{other:0}</code>. Implicit replies should only be used when a further message thread is not anticipated. When further messages in the thread are expected, a full regular <code>~thread</code> block should be used.</p> <p>Example Message with am Implicit Reply:</p> <p><pre><code>{\n    \"@id\": \"&lt;@id of outer message&gt;\",\n    \"~thread\": {\n        \"thid\": \"&lt;different than @id of outer message&gt;\"\n    }\n}\n</code></pre> Effective Message with defaults in place: <pre><code>{\n    \"@id\": \"&lt;@id of outer message&gt;\",\n    \"~thread\": {\n        \"thid\": \"&lt;different than @id of outer message&gt;\"\n        \"sender_order\": 0,\n        \"received_orders\": { \"DID of sender\":0 }\n    }\n}\n</code></pre></p>"},{"location":"concepts/0008-message-id-and-threading/#reference","title":"Reference","text":"<ul> <li>Message Packaging document from Sovrin Foundation Protocol Repo</li> <li>Very brief summary of discussion from Agent Summit on Decorators</li> </ul>"},{"location":"concepts/0008-message-id-and-threading/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"concepts/0008-message-id-and-threading/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Implement threading for each message type that needs it.</li> </ul>"},{"location":"concepts/0008-message-id-and-threading/#prior-art","title":"Prior art","text":"<p>If you're aware of relevant prior-art, please add it here.</p>"},{"location":"concepts/0008-message-id-and-threading/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Using a wrapping method for threading has been discussed but most seemed in favor of the annotated method. Any remaining arguments to be made in favor of the wrapping method?</li> </ul>"},{"location":"concepts/0008-message-id-and-threading/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem. Aries Protocol Test Suite"},{"location":"concepts/0011-decorators/","title":"Aries RFC 0011: Decorators","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-01-31</li> <li>Status Note: broadly used in Indy, but not yet harmonized with DIF work on hubs.</li> <li>Start Date: 2018-12-14</li> <li>Tags: concept, decorator</li> </ul>"},{"location":"concepts/0011-decorators/#summary","title":"Summary","text":"<p>Explain how decorators work in DID communication.</p>"},{"location":"concepts/0011-decorators/#motivation","title":"Motivation","text":"<p>Certain semantic patterns manifest over and over again in communication. For example, all communication needs the pattern of testing the type of message received. The pattern of identifying a message and referencing it later is likely to be useful in a high percentage of all protocols that are ever written. A pattern that associates messages with debugging/tracing/timing metadata is equally relevant. And so forth.</p> <p>We need a way to convey metadata that embodies these patterns, without complicating schemas, bloating core definitions, managing complicated inheritance hierarchies, or confusing one another. It needs to be elegant, powerful, and adaptable.</p>"},{"location":"concepts/0011-decorators/#tutorial","title":"Tutorial","text":"<p>A decorator is an optional chunk of JSON that conveys metadata. Decorators are not declared in a core schema but rather supplementary to it. Decorators add semantic content broadly relevant to messaging in general, and not so much tied to the problem domain of a specific type of interaction.</p> <p>You can think of decorators as a sort of mixin for agent-to-agent messaging. This is not a perfect analogy, but it is a good one. Decorators in DIDComm also have some overlap (but not a direct congruence) with annotations in Java, attributes in C#, and both decorators and annotations in python.</p>"},{"location":"concepts/0011-decorators/#simple-example","title":"Simple Example","text":"<p>Imagine we are designing a protocol and associated messages to arrange meetings between two people. We might come up with a <code>meeting_proposal</code> message that looks like this:</p> <pre><code>{\n  \"@id\": \"e2987006-a18a-4544-9596-5ad0d9390c8b\",\n  \"@type\": \"did:sov:8700e296a1458aad0d93;spec/meetings/1.0/proposal\",\n  \"proposed_time\": \"2019-12-23 17:00\",\n  \"proposed_place\": \"at the cathedral, Barf\u00fcsserplatz, Basel\",\n  \"comment\": \"Let's walk through the Christmas market.\"\n}\n</code></pre> <p>Now we tackle the <code>meeting_proposal_response</code> messages. Maybe we start with something exceedingly simple, like:</p> <pre><code>{\n  \"@id\": \"d9390ce2-8ba1-4544-9596-9870065ad08a\",\n  \"@type\": \"did:sov:8700e296a1458aad0d93;spec/meetings/1.0/response\",\n  \"agree\": true,\n  \"comment\": \"See you there!\"\n}\n</code></pre> <p>But we quickly realize that the asynchronous nature of messaging will expose a gap in our message design: if Alice receives two meeting proposals from Bob at the same time, there is nothing to bind a response back to the specific proposal it addresses.</p> <p>We could extend the schema of our response so it contains an <code>thread</code> that references the <code>@id</code> of the original proposal. This would work. However, it does not satsify the DRY principle of software design, because when we tackle the protocol for negotiating a purchase between buyer and seller next week, we will need the same solution all over again. The result would be a proliferation of schemas that all address the same basic need for associating request and response. Worse, they might do it in different ways, cluttering the mental model for everyone and making the underlying patterns less obvious.</p> <p>What we want instead is a way to inject into any message the idea of a thread, such that we can easily associate responses with requests, errors with the messages that triggered them, and child interactions that branch off of the main one. This is the subject of the message threading RFC, and the solution is the <code>~thread</code> decorator, which can be added to any response:</p> <p><pre><code>{\n  \"@id\": \"d9390ce2-8ba1-4544-9596-9870065ad08a\",\n  \"@type\": \"did:sov:8700e296a1458aad0d93;spec/meetings/1.0/response\",\n  \"~thread\": {\"thid\": \"e2987006-a18a-4544-9596-5ad0d9390c8b\"},\n  \"agree\": true,\n  \"comment\": \"See you there!\"\n}\n</code></pre> This chunk of JSON is defined independent of any particular message schema, but is understood to be available in all DIDComm schemas.</p>"},{"location":"concepts/0011-decorators/#basic-conventions","title":"Basic Conventions","text":"<p>Decorators are defined in RFCs that document a general pattern such as message threading RFC or message localization. The documentation for a decorator explains its semantics and offers examples.</p> <p>Decorators are recognized by name. The name must begin with the <code>~</code> character (which is reserved in DIDComm messages for decorator use), and be a short, single-line string suitable for use as a JSON attribute name.</p> <p>Decorators may be simple key:value pairs <code>\"~foo\": \"bar\"</code>. Or they may associate a key with a more complex structure:</p> <pre><code>\"~thread\": {\n  \"thid\": \"e2987006-a18a-4544-9596-5ad0d9390c8b\",\n  \"pthid\": \"0c8be298-45a1-48a4-5996-d0d95a397006\",\n  \"sender_order\": 0\n}\n</code></pre> <p>Decorators should be thought of as supplementary to the problem-domain-specific fields of a message, in that they describe general communication issues relevant to a broad array of message types. Entities that handle messages should treat all unrecognized fields as valid but meaningless, and decorators are no exception. Thus, software that doesn't recognize a decorator should ignore it.</p> <p>However, this does not mean that decorators are necessarily optional. Some messages may intend something tied so tightly to a decorator's semantics that the decorator effectively becomes required. An example of this is the relationship between a general error reporting mechanism and the <code>~thread</code> decorator: it's not very helpful to report errors without the context that a thread provides.</p> <p>Because decorators are general by design and intent, we don't expect namespacing to be a major concern. The community agrees on decorators that everybody will recognize, and they acquire global scope upon acceptance. Their globalness is part of their utility. Effectively, decorator names are like reserved words in a shared public language of messages.</p> <p>Namespacing is also supported, as we may discover legitimate uses. When namespaces are desired, dotted name notation is used, as in <code>~mynamespace.mydecoratorname</code>. We may elaborate this topic more in the future.</p> <p>Decorators are orthogonal to JSON-LD constructs in DIDComm messages.</p>"},{"location":"concepts/0011-decorators/#versioning","title":"Versioning","text":"<p>We hope that community-defined decorators are very stable. However, new fields (a non-breaking change) might need to be added to complex decorators; occasionally, more significant changes might be necessary as well. Therefore, decorators do support semver-style versioning, but in a form that allows details to be ignored unless or until they become important. The rules are:</p> <ol> <li>As with all other aspects of DIDComm messages, unrecognized fields in decorators must be ignored.</li> <li>Version information can be appended to the name of a decorator, as in <code>~mydecorator/1</code>. Only a major version (never minor or patch) is used, since:<ul> <li>Minor version variations should not break decorator handling code.</li> <li>The dot character <code>.</code> is reserved for namespacing within field names.</li> <li>The extra complexity is not worth the small amount of value it might add.</li> </ul> </li> <li>A decorator without a version is considered to be synonymous with version 1.0, and the version-less form is preferred. This allows version numbers to be added only in the uncommon cases where they are necessary.</li> </ol>"},{"location":"concepts/0011-decorators/#decorator-scope","title":"Decorator Scope","text":"<p>A decorator may be understood to decorate (add semantics) at several different scopes. The discussion thus far has focused on message decorators, and this is by far the most important scope to understand. But there are more possibilities.</p> <p>Suppose we wanted to decorate an individual field. This can be done with a field decorator, which is a sibling field to the field it decorates. The name of decorated field is combined with a decorator suffix, as follows:</p> <p><pre><code>{\n  \"note\": \"Let's have a picnic.\",\n  \"note~l10n\": { ... }\n}\n</code></pre> In this example, taken from the localization pattern, <code>note~l10n</code> decorates <code>note</code>.</p> <p>Besides a single message or a single field, consider the following scopes as decorator targets:</p> <ul> <li>Message Family: An decorator can be declared in documentation for the   message family, explaining semantics that apply to all message instances in the   family unless overridden at a narrower scope. This is not the same as declaring the   decorator's structure to be part of the schema of a message family; this is saying   that the field values in a concrete instance of a decorator applies to all instances   of a message family. The localization pattern contemplates this usage as a way to   declare default localization semantics.</li> <li>Message Type:   A decorator can be declared in the documentation on a specific message   type. If this happens, semantics of the decorator on the message type should be   understood as overriding or enriching the semantics of that same decorator on the   parent message family, since the scope is becoming more specific.</li> <li>Message Thread or thread tree: A participant in a   thread could send a message containing nothing but the <code>~thread</code> with one or   more additional decorators inside it. This should be viewed as a statement of semantics that   apply to subsequent communications from the sender, on that thread, until further   notice or until overridden at the scope of an individual message instance. (While   powerful, applying a decorator to this scope may be a burden on receivers because   it requires them to be stateful. Therefore this usage, though theoretically possible,   may be undesirable. If community members want to explore this, they are encouraged   to discuss broadly, first.)</li> <li>Connection. It is conceivable that Alice could bundle up a set of decorators   and send them to Bob as a way of saying \"Hey, Bob: unless/until subsequent interactions   give you more specific semantics, here's a set of semantics (settings for our connection)   that you should assume for all interactions.\" (This may or may not be useful. It introduces ambiguity--should settings declared   at this scope override those at the scope of a message family or message type? It   also adds a burden of remembering to another party; some of what informs the interaction   isn't present in the bits that flow later on. Thus, this style of decorator is also   left as a possibility for future exploration and is not actively supported at present.)</li> </ul>"},{"location":"concepts/0011-decorators/#reference","title":"Reference","text":"<p>This section of this RFC will be kept up-to-date with a list of globally accepted decorators, and links to the RFCs that define them.</p> <ul> <li><code>~thread</code>: provide request/reply and threading semantics</li> <li><code>~timing</code>: timestamps, expiration, elapsed time</li> <li><code>~trace</code>: collaborative debugging and monitoring</li> <li><code>~l10n</code>: localization support</li> </ul>"},{"location":"concepts/0011-decorators/#drawbacks","title":"Drawbacks","text":"<p>By having fields that are meaningful yet not declared in core schemas, we run the risk that parsing and validation routines will fail to enforce details that are significant but invisible. We also accept the possibility that interop may look good on paper, but fail due to different understandings of important metadata.</p> <p>We believe this risk will take care of itself, for the most part, as real-life usage accumulates and decorators become a familiar and central part of the thinking for developers who work with agent-to-agent communication.</p>"},{"location":"concepts/0011-decorators/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>There is ongoing work in the <code>#indy-semantics</code> channel on Rocket.Chat to explore the concept of overlays. These are layers of additional meaning that accumulate above a schema base. Decorators as described here are quite similar in intent. There are some subtle differences, though. The most interesting is that decorators as described here may be applied to things that are not schema-like (e.g., to a message family as a whole, or to a connection, not just to an individual message).</p> <p>We may be able to resolve these two worldviews, such that decorators are viewed as overlays and inherit some overlay goodness as a result. However, it is unlikely that decorators will change significantly in form or substance as a result. We thus believe the current mental model is already RFC-worthy, and represents a reasonable foundation for immediate use.</p>"},{"location":"concepts/0011-decorators/#prior-art","title":"Prior art","text":"<p>See references to similar ../../features in programming languages like Java, C#, and Python, mentiond above.</p> <p>See also this series of blog posts about semantic gaps and the need to manage intent in a declarative style: [ Lacunas Everywhere, Bridging the Lacuna Humana, Introducing Marks, Mountains,  Molehills, and Markedness ]</p>"},{"location":"concepts/0011-decorators/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Are we doing enough about namespacing and collision avoidance with JSON-LD?</li> <li>What should we do, if anything, about versioning decorators?</li> <li>What should we do, if anything, about applying decorators to stateful scopes   like a connection or a thread?</li> </ul>"},{"location":"concepts/0011-decorators/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries RFCs: RFC 0008, RFC 0017, RFC 0015, RFC 0023, RFC 0043, RFC 0056, RFC 0075 many implemented RFCs depend on decorators... Indy Cloud Agent - Python message threading Aries Framework - .NET message threading Streetcred.id message threading Aries Cloud Agent - Python message threading, attachments Aries Static Agent - Python message threading Aries Framework - Go message threading Connect.Me message threading Verity message threading Aries Protocol Test Suite message threading"},{"location":"concepts/0013-overlays/","title":"Aries RFC 0013: Overlays","text":"<ul> <li>Authors: Paul Knowles, The Human Colossus Foundation</li> <li>Status: RETIRED</li> <li>Since: 2023-01-15</li> <li>Status Note: Although this RFP is in the retired status, the use of overlays and the Overlays Capture Architecture (OCA) is active in Aries. This RFP is an early of the OCA specification, and its content is replaced by the Overlays Capture Architecture Specification. The use of OCA in Aries is described in RFC 0755: OCA for Aries.</li> <li>Start Date: 2018-10-01</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0017-attachments/","title":"Aries RFC 0017: Attachments","text":"<ul> <li>Authors: Daniel Hardman, Sam Curren, Andrew Whitehead</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Used in a number of other RFCs.</li> <li>Start Date: 2018-12-24</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0017-attachments/#summary","title":"Summary","text":"<p>Explains the three canonical ways to attach data to an agent message.</p>"},{"location":"concepts/0017-attachments/#motivation","title":"Motivation","text":"<p>DIDComm messages use a structured format with a defined schema and a small inventory of scalar data types (string, number, date, etc). However, it will be quite common for messages to supplement formalized exchange with arbitrary data--images, documents, or types of media not yet invented.</p> <p>We need a way to \"attach\" such content to DIDComm messages. This method must be flexible, powerful, and usable without requiring new schema updates for every dynamic variation.</p>"},{"location":"concepts/0017-attachments/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0017-attachments/#messages-versus-data","title":"Messages versus Data","text":"<p>Before explaining how to associate data with a message, it is worth pondering exactly how these two categories of information differ. It is common for newcomers to DIDComm to argue that messages are just data, and vice versa. After all, any data can be transmitted over DIDComm; doesn't that turn it into a message? And any message can be saved; doesn't that make it data?</p> <p>While it is true that messages and data are highly related, some semantic differences matter:</p> <ul> <li> <p>Messages are primarily about communication. Their meaning is tied to a communication context. Messages are a mechanism whereby state evolves in a protocol. Protocols are versioned according to the structure and semantics of messages. Messages are usually small, consisting of a modest number of fields with a structure that's focused on furthering the goals of their protocol.</p> </li> <li> <p>Data has meaning at rest, in many different DIDComm protocols, or in important contexts beyond DIDComm. Data may be very large and very complex. It may come in formats that are quite independent from DIDComm, versioned independently from the protocols that share it. Data may be produced, consumed or handled as part of a protocol, but the actual content of the data is usually not where processing at the protocol level focuses. In agent codebases, it would be common for data handling to be implemented in different classes or libraries from the handlers for messages.</p> </li> </ul> <p>Some examples:</p> <ul> <li> <p>A protocol to negotiate the release of medical records might cause X-Rays, genomes, and many other artifacts to be transmitted. These artifacts are data, whereas the information packets that arrange the transmission and provide a carrying mechanism for the artifacts are messages.</p> </li> <li> <p>A DIDComm message can be used to report an error. Descriptive parameters that change how the error is processed are probably part of the message, whereas a log file that provides supporting information should be thought of as data rather than the message.</p> </li> <li> <p>The protocol for issuing credentials consists of messages that flow through certain steps. One of the steps eventually delivers a credential. The credential is data; it has meaning even when the protocol is complete, and the protocol version may evolve independent of the data format of the credential itself. The fact that the credential is transmitted through a message does not change the credential's primary status as data.</p> </li> <li> <p>A protocol to schedule a venue for an event might produce a confirmation message when it finishes. This message might include a map of the venue, instructions about how to unlock the gate, pictures of certain resources, and so forth. This collateral is data, whereas the messages that signal progression through the steps of scheduling are not.</p> </li> <li> <p>The DID Exchange Protocol exchanges messages to establish a connection between two parties. Part of what's exchanged is a DID Doc. The DID Doc is more like data than it is like an ordinary message, since it has meaning at rest and outside the protocol.</p> </li> </ul> <p>The line between these two ../../concepts may not be perfectly crisp in all cases, and that is okay. It is clear enough, most of the time, to provide context for the central question of this RFC, which is:</p> <p>How do we send data along with messages?</p>"},{"location":"concepts/0017-attachments/#3-ways","title":"3 Ways","text":"<p>Data can be \"attached\" to DIDComm messages in 3 ways:</p> <ol> <li>Inlining</li> <li>Embedding</li> <li>Appending</li> </ol>"},{"location":"concepts/0017-attachments/#inlining","title":"Inlining","text":"<p>In inlining, data is directly assigned as the value paired with a JSON key in a DIDComm message. For example, a message about arranging a rendezvous may inline data about a location: </p> <p>This inlined data is in Google Maps pinning format. It has a meaning at rest, outside the message that conveys it, and the versioning of its structure may evolve independently of the versioning of the rendezvous protocol.</p> <p>Only JSON data can be inlined, since any other data format would break JSON format rules.</p>"},{"location":"concepts/0017-attachments/#embedding","title":"Embedding","text":"<p>In embedding, a JSON data structure called an attachment descriptor is assigned as the value paired with a JSON key in a DIDComm message. (Or, an array of attachment descriptors could be assigned.) By convention, the key name for such attachment fields ends with <code>~attach</code>, making it a field-level decorator that can share common handling logic in agent code. The attachment descriptor structure describes the MIME type and other properties of the data, in much the same way that MIME headers and body describe and contain an attachment in an email message. Given an imaginary protocol that photographers could use to share their favorite photo with friends, the embedded data might manifest like this:</p> <p></p> <p>Embedding is a less direct mechanism than inlining, because the data is no longer readable by a human inspecting the message; it is base64url-encoded instead. A benefit of this approach is that the data can be any MIME type instead of just JSON, and that the data comes with useful metadata that can facilitate saving it as a separate file.</p>"},{"location":"concepts/0017-attachments/#appending","title":"Appending","text":"<p>Appending is accomplished using the <code>~attach</code> decorator, which can be added to any message to include arbitrary data. The decorator is an array of attachment descriptor structures (the same structure used for embedding). For example, a message that conveys evidence found at a crime scene might include the following decorator:</p> <p></p>"},{"location":"concepts/0017-attachments/#choosing-the-right-approach","title":"Choosing the right approach","text":"<p>These methods for attaching sit along a continuum that is somewhat like the continuum between strong, statically typed languages versus dynamic, duck-typed languages in programming. The more strongly typed the attachments are, the more strongly bound the attachments are to the protocol that conveys them. Each choice has advantages and disadvantages.</p> <p></p> <p>Inlined data is strongly typed; the schema for its associated message must specify the name of the data field, plus what type of data it contains. Its format is always some kind of JSON--often JSON-LD with a <code>@type</code> and/or <code>@context</code> field to provide greater clarity and some independence of versioning. Simple and small data is the best fit for inlining. As mentioned earlier, the Connection Protocol inlines a DID Doc in its <code>connection_request</code> and <code>connection_response</code> messages.</p> <p>Embedded data is still associated with a known field in the message schema, but it can have a broader set of possible formats. A credential exchange protocol might embed a credential in the final message that does credential issuance.</p> <p>Appended attachments are the most flexible but also the hardest to run through semantically sophisticated processing. They do not require any specific declaration in the schema of a message, although they can be referenced in fields defined by the schema via their nickname (see below). A protocol that needs to pass an arbitrary collection of artifacts without strong knowledge of their semantics might find this helpful, as in the example mentioned above, where scheduling a venue causes various human-usable payloads to be delivered.</p>"},{"location":"concepts/0017-attachments/#ids-for-attachments","title":"IDs for attachments","text":"<p>The <code>@id</code> field within an attachment descriptor is used to refer unambiguously to an appended (or less ideally, embedded) attachment, and works like an HTML anchor. It is resolved relative to the root <code>@id</code> of the message and only has to be unique within a message. For example, imagine a fictional message type that's used to apply for an art scholarship, that requires photos of art demonstrating techniques A, B, and C. We could have 3 different attachment descriptors--but what if the same work of art demonstrates both technique A and technique B? We don't want to attach the same photo twice...</p> <p>What we can do is stipulate that the datatype of <code>A_pic</code>, <code>B_pic</code>, and <code>C_pic</code> is an attachment reference, and that the references will point to appended attachments. A fragment of the result might look like this:</p> <p></p> <p>Another example of nickname use appeared in the first example of appended attachments above, where the <code>notes</code> field refered to the <code>@id</code>s of the various attachments.</p> <p>This indirection offers several benefits:</p> <ul> <li>The same attachment may be referenced at more than one place in the schema, without duplicating the content.</li> <li>The message may now include any number of attachments besides the 3 that are required, and mingle them freely with the others. (In our example, perhaps the student wants to add side and overhead shots of each work of art, not just front views).</li> <li>Attachments may now have formal semantics, instead of requiring human intelligence to handle. (How many times have we written emails with multiple attachments, and added verbiage like, \"My photo of the door is attached as image1.jpeg; my photo of the damaged trunk is attached as image2.jpeg\"?)</li> </ul> <p>We could use this same technique with embedded attachments (that is, assign a nickname to an embedded attachment, and refer to that nickname in another field where attached data could be embedded), but this is not considered best practice. The reason is that it requires a field in the schema to have two possible data types--one a string that's a nickname reference, and one an attachment descriptor. Generally, we like fields to have a single datatype in a schema.</p>"},{"location":"concepts/0017-attachments/#content-formats","title":"Content Formats","text":"<p>There are multiple ways to include content in an attachment. Only one method should be used per attachment.</p>"},{"location":"concepts/0017-attachments/#base64url","title":"base64url","text":"<p>This content encoding is an obvious choice for any content different than JSON. You can embed content of any type using this method. Examples are plentiful throughout the document. Note that this encoding is always base64url encoding, not plain base64, and that padding is not required. Code that reads this encoding SHOULD tolerate the presence or absence of padding and base64 versus base64url encodings equally well, but code that writes this encoding SHOULD omit the padding to guarantee alignment with encoding rules in the JOSE (JW*) family of specs.</p>"},{"location":"concepts/0017-attachments/#json","title":"json","text":"<p>If you are embedding an attachment that is JSON, you can embed it directly in JSON format to make access easier, by replacing <code>data.base64</code> with <code>data.json</code>, where the value assigned to <code>data.json</code> is the attached content:</p> <p></p> <p>This is an overly trivial example of GeoJSON, but hopefully it illustrates the technique. In cases where there is no mime type to declare, it may be helpful to use JSON-LD's <code>@type</code> construct to clarify the specific flavor of JSON in the embedded attachment.</p>"},{"location":"concepts/0017-attachments/#links","title":"links","text":"<p>All examples discussed so far include an attachment by value--that is, the attachment's bytes are directly inlined in the message in some way. This is a useful mode of data delivery, but it is not the only mode.</p> <p>Another way that attachment data can be incorporated is by reference. For example, you can link to the content on a web server by replacing <code>data.base64</code> or <code>data.json</code> with <code>data.links</code> in an attachment descriptor:</p> <p></p> <p>When you provide such a link, you are creating a logical association between the message and an attachment that can be fetched separately. This makes it possible to send brief descriptors of attachments and to make the downloading of the heavy content optional (or parallelizable) for the recipient.</p> <p>The <code>links</code> field is plural (an array) to allow multiple locations to be offered for the same content. This allows an agent to fetch attachments using whichever mechanism(s) are best suited to its individual needs and capabilities.</p>"},{"location":"concepts/0017-attachments/#supported-uri-types","title":"Supported URI Types","text":"<p>The set of supported URI types in an attachment link is limited to:</p> <ul> <li>HTTP</li> <li>HTTPS</li> </ul> <p>Additional URI types may be added via updates to this RFC.</p> <p>If an attachment link with an unsupported URI is received, the agent SHOULD respond with a Problem Report indicated the problem.</p> <p>An ecosystem (coordinating set of agents working in a specific business area) may agree to support other URI types within that ecosystem. As such, implementing a mechanism to easily add support for other attachment link URI types might be useful, but is not required.</p>"},{"location":"concepts/0017-attachments/#signing-attachments","title":"Signing Attachments","text":"<p>In some cases it may be desirable to sign an attachment in addition to or instead of signing the message as a whole. Consider a home-buying protocol; the home inspection needs to be signed even when it is removed from a messaging flow. Attachments may also be signed by a party separate from the sender of the message, or using a different signing key when the sender is performing key rotation.</p> <p>Embedded and appended attachments support signatures by the addition of a <code>data.jws</code> field containing a signature in JWS (RFC 7515) format with Detached Content. The payload of the JWS is the raw bytes of the attachment, appropriately base64url-encoded per JWS rules. If these raw bytes are incorporated by value in the DIDComm message, they are already base64url-encoded in <code>data.base64</code> and are thus directly substitutable for the suppressed <code>data.jws.payload</code> field; if they are externally referenced, then the bytes must be fetched via the URI in <code>data.links</code> and base64url-encoded before the JWS can be fully reconstituted. Signatures over inlined JSON attachments are not currently defined as this depends upon a canonical serialization for the data.</p> <p>Sample JWS-signed attachment:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/xhomebuy/1.0/home_insp\",\n  \"inspection_date\": \"2020-03-25\",\n  \"inspection_address\": \"123 Villa de Las Fuentes, Toledo, Spain\",\n  \"comment\": \"Here's that report you asked for.\",\n  \"report~attach\": {\n    \"mime-type\": \"application/pdf\",\n    \"filename\": \"Garcia-inspection-March-25.pdf\",\n    \"data\": {\n      \"base64\": \"eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ... (bytes omitted to shorten)\",\n      \"jws\": {\n        // payload: ...,  &lt;-- omitted: refer to base64 content when validating\n        \"header\": {\n          \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n        },\n        \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n        \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n      }\n    }\n  }\n}\n</code></pre> <p>Here, the JWS structure inlines a public key value in did:key format within the unprotected header's <code>kid</code> field. It may also use a DID URL to reference a key within a resolvable DIDDoc. Supported DID URLs should specify a timestamp and/or version for the containing document.</p> <p>The JWS protected header consists of at least the following parameter indicating an Edwards curve digital signature:</p> <pre><code>{\n  \"alg\": \"EdDSA\"\n}\n</code></pre> <p>Additional protected and unprotected header parameters may be included in the JWS and must be ignored by implementations if not specifically supported. Any registered header parameters defined by the JWS RFC must be used according to the specification if present.</p> <p>Multiple signatures may be included using the JWS General Serialization syntax. When a single signature is present, the Flattened Serialization syntax should be preferred. Because each JWS contains an unprotected header with the signing key information, the JWS Compact Serialization cannot be supported.</p>"},{"location":"concepts/0017-attachments/#size-considerations","title":"Size Considerations","text":"<p>DIDComm messages should be small, as a general rule. Just as it's a bad idea to send email messages with multi-GB attachments, it would be bad to send DIDComm messages with huge amounts of data inside them. Remember, a message is about advancing a protocol; usually that can be done without gigabytes or even megabytes of JSON fields. Remember as well that DIDComm messages may be sent over channels having size constraints tied to the transport--an HTTP POST or Bluetooth or NFC or AMQP payload of more than a few MB may be problematic.</p> <p>Size pressures in messaging are likely to come from attached data. A good rule of thumb might be to not make DIDComm messages bigger than email or MMS messages--whenever more data needs to be attached, use the inclusion-by-reference technique to allow the data to be fetched separately.</p>"},{"location":"concepts/0017-attachments/#security-implications","title":"Security Implications","text":"<p>Attachments are a notorious vector for malware and mischief with email. For this reason, agents that support attachments MUST perform input validation on attachments, and MUST NOT invoke risky actions on attachments until such validation has been performed. The status of input validation with respect to attachment data MUST be reflected in the Message Trust Context associated with the data's message.</p>"},{"location":"concepts/0017-attachments/#privacy-implications","title":"Privacy Implications","text":"<p>When attachments are inlined, they enjoy the same security and transmission guarantees as all agent communication. However, given the right context, a large inlined attachment may be recognizable by its size, even if it is carefully encrypted.</p> <p>If attachment content is fetched from an external source, then new complications arise. The security guarantees may change. Data streamed from a CDN may be observable in flight. URIs may be correlating. Content may not be immutable or tamper-resistant.</p> <p>However, these issues are not necessarily a problem. If a DIDComm message wants to attach a 4 GB ISO file of a linux distribution, it may be perfectly fine to do so in the clear. Downloading it is unlikely to introduce strong correlation, encryption is unnecessary, and the torrent itself prevents malicious modification.</p> <p>Code that handles attachments will need to use wise policy to decide whether attachments are presented in a form that meets its needs.</p>"},{"location":"concepts/0017-attachments/#reference","title":"Reference","text":""},{"location":"concepts/0017-attachments/#attachment-descriptor-structure","title":"Attachment Descriptor structure","text":"<ul> <li> <p><code>@id</code>: A JSON-LD construct that uniquely identifies attached content within the scope of a given message. Recommended on appended attachment descriptors. Possible but generally unused on embedded attachment descriptors. Never required if no references to the attachment exist; if omitted, then there is no way to refer to the attachment later in the thread, in error messages, and so forth. Because <code>@id</code> is used to compose URIs, it is recommended that this name be brief and avoid spaces and other characters that require URI escaping.</p> </li> <li> <p><code>description</code>: An optional human-readable description of the content.</p> </li> <li> <p><code>filename</code>: A hint about the name that might be used if this attachment is persisted as a file. It is not required, and need not be unique. If this field is present and <code>mime-type</code> is not, the extension on the filename may be used to infer a MIME type.</p> </li> <li> <p><code>mime-type</code>: Describes the MIME type of the attached content. Optional but recommended.</p> </li> <li> <p><code>lastmod_time</code>: A hint about when the content in this attachment was last modified.</p> </li> <li> <p><code>byte_count</code>: Optional, and mostly relevant when content is included by reference instead of by value. Lets the receiver guess how expensive it will be, in time, bandwidth, and storage, to fully fetch the attachment.</p> </li> <li> <p><code>data</code>: A JSON object that gives access to the actual content of the attachment. Contains the following subfields:</p> </li> <li> <p><code>jws</code>: A JSON Web Signature over the content of the attachment. Optional.</p> </li> <li> <p><code>sha256</code>: The hash of the content. Optional. Used as an integrity check if   content is inlined. if content is only referenced, then including this field   makes the content tamper-evident. This may be redundant, if the content is   stored in an inherently immutable container like content-addressable storage.   This may also be undesirable, if dynamic content at a specified link is   beneficial. Including a hash without including a way to fetch the content via   link is a form of proof of existence.</p> </li> <li> <p><code>links</code>: A list of zero or more locations at which the content may be fetched.   Optional.</p> </li> <li> <p><code>base64</code>: Base64url-encoded data, when representing arbitrary content inline instead   of via <code>links</code>. Optional.</p> </li> <li> <p><code>json</code>: Directly embedded JSON data, when representing content inline instead of   via <code>links</code>, and when the content is natively conveyable as JSON. Optional.</p> </li> </ul>"},{"location":"concepts/0017-attachments/#drawbacks","title":"Drawbacks","text":"<p>By providing 3 different choices, we impose additional complexity on agents that will receive messages. They have to handle attachments in 3 different modes.</p>"},{"location":"concepts/0017-attachments/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Originally, we only proposed the most flexible method of attaching--appending. However, feedback from the community suggested that stronger binding to schema was desirable. Inlining was independently invented, and is suggested by JSON-LD anyway. Embedding without appending eliminates some valuable ../../features such as unnamed and undeclared ad-hoc attachments. So we ended up wanting to support all 3 modes.</p>"},{"location":"concepts/0017-attachments/#prior-art","title":"Prior art","text":"<p>Multipart MIME (see RFCs 822, 1341, and 2045) defines a mechanism somewhat like this. Since we are using JSON instead of email messages as the core model, we can't use these mechanisms directly. However, they are an inspiration for what we are showing here.</p>"},{"location":"concepts/0017-attachments/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>N/A</li> </ul>"},{"location":"concepts/0017-attachments/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python in credential exchange Streetcred.id Commercial mobile and web app built using Aries Framework - .NET"},{"location":"concepts/0020-message-types/","title":"Aries RFC 0020: Message Types","text":"<ul> <li>Authors: Daniel Bluhm, Sam Curren</li> <li>Status: ADOPTED</li> <li>Since: 2019-05-24</li> <li>Status Note:  </li> <li>Supersedes: HIPE 0021 Message Types</li> <li>Start Date: 2018-07-06</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0020-message-types/#summary","title":"Summary","text":"<p>Define structure of message type strings used in agent to agent communication, describe their resolution to documentation URIs, and offer guidelines for protocol specifications.</p>"},{"location":"concepts/0020-message-types/#motivation","title":"Motivation","text":"<p>A clear convention to follow for agent developers is necessary for interoperability and continued progress as a community.</p>"},{"location":"concepts/0020-message-types/#tutorial","title":"Tutorial","text":"<p>A \"Message Type\" is a required attribute of all communications sent between parties. The message type instructs the receiving agent how to interpret the content and what content to expect as part of a given message.</p> <p>Types are specified within a message using the <code>@type</code> attribute:</p> <pre><code>{\n    \"@type\": \"&lt;message type string&gt;\",\n    // other attributes\n}\n</code></pre> <p>Message types are URIs that may resolve to developer documentation for the message type, as described in Protocol URIs. We recommend that message type URIs be HTTP URLs.</p>"},{"location":"concepts/0020-message-types/#aries-core-message-namespace","title":"Aries Core Message Namespace","text":"<p><code>https://didcomm.org/</code> is used to namespace protocols defined by the community as \"core protocols\" or protocols that agents should minimally support.</p> <p>The <code>didcomm.org</code> DNS entry is currently controlled by the Decentralized Identity Foundation (DIF) based on their role in standardizing the DIDComm Messaging specification.</p>"},{"location":"concepts/0020-message-types/#protocols","title":"Protocols","text":"<p>Protocols provide a logical grouping for message types. These protocols, along with each type belonging to that protocol, are to be defined in future RFCs or through means appropriate to subprojects.</p>"},{"location":"concepts/0020-message-types/#protocol-versioning","title":"Protocol Versioning","text":"<p>Version numbering should essentially follow Semantic Versioning 2.0.0, excluding patch version number. To summarize, a change in the major protocol version number indicates a breaking change while the minor protocol version number indicates non-breaking additions.</p>"},{"location":"concepts/0020-message-types/#message-type-design-guidelines","title":"Message Type Design Guidelines","text":"<p>These guidelines are guidelines on purpose. There will be situations where a good design will have to choose between conflicting points, or ignore all of them. The goal should always be clear and good design.</p>"},{"location":"concepts/0020-message-types/#respect-reserved-attribute-names","title":"Respect Reserved Attribute Names","text":"<p>Reserved attributes are prefixed with an <code>@</code> sign, such as <code>@type</code>. Don't use this prefix for an attribute, even if use of that specific attribute is undefined.</p>"},{"location":"concepts/0020-message-types/#avoid-ambiguous-attribute-names","title":"Avoid ambiguous attribute names","text":"<p>Data, id, and package, are often terrible names. Adjust the name to enhance meaning. For example, use  <code>message_id</code> instead of <code>id</code>.</p>"},{"location":"concepts/0020-message-types/#avoid-names-with-special-characters","title":"Avoid names with special characters","text":"<p>Technically, attribute names can be any valid json key (except prefixed with @, as mentioned above). Practically, you should avoid using special characters, including those that need to be escaped. Underscores and dashes [_,-] are totally acceptable, but you should avoid quotation marks, punctuation, and other symbols.</p>"},{"location":"concepts/0020-message-types/#use-attributes-consistently-within-a-protocol","title":"Use attributes consistently within a protocol","text":"<p>Be consistent with attribute names between the different types within a protocol. Only use the same attribute name for the same data. If the attribute values are similar, but not exactly the same, adjust the name to indicate the difference.</p>"},{"location":"concepts/0020-message-types/#nest-attributes-only-when-useful","title":"Nest Attributes only when useful","text":"<p>Attributes do not need to be nested under a top level attribute, but can be to organize related attributes. Nesting all message attributes under one top level attribute is usually not a good idea.</p>"},{"location":"concepts/0020-message-types/#design-examples","title":"Design Examples","text":""},{"location":"concepts/0020-message-types/#example-1","title":"Example 1","text":"<pre><code>{\n    \"@type\": \"did:example:00000;spec/pizzaplace/1.0/pizzaorder\",\n    \"content\": {\n        \"id\": 15,\n        \"name\": \"combo\",\n        \"prepaid?\": true,\n        \"ingredients\": [\"pepperoni\", \"bell peppers\", \"anchovies\"]\n    }\n}\n</code></pre> <p>Suggestions: Ambiguous names, unnecessary nesting, symbols in names.</p>"},{"location":"concepts/0020-message-types/#example-1-fixed","title":"Example 1 Fixed","text":"<pre><code>{\n    \"@type\": \"did:example:00000;spec/pizzaplace/1.0/pizzaorder\",\n    \"table_id\": 15,\n    \"pizza_name\": \"combo\",\n    \"prepaid\": true,\n    \"ingredients\": [\"pepperoni\", \"bell peppers\", \"anchovies\"]\n}\n</code></pre>"},{"location":"concepts/0020-message-types/#reference","title":"Reference","text":"<ul> <li>Daniel Hardman's Agent Summit Notes</li> <li>Stephen Curran's presentation summarizing the Agent Summit</li> <li>Semantic Versioning</li> <li>DIDComm Message Anatomy</li> </ul>"},{"location":"concepts/0020-message-types/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community Aries Framework - .NET .NET framework for building agents of all types Streetcred.id Commercial mobile and web app built using Aries Framework - .NET Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Aries Framework - Go For building agents, hubs and other DIDComm ../../features in GoLang. Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem."},{"location":"concepts/0021-didcomm-message-anatomy/","title":"Aries RFC 0021: DIDComm Message Anatomy","text":"<ul> <li>Authors: Tobias Looker, Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-05-25</li> <li>Start Date: 2019-05-25</li> <li>Tags: concept, decorator</li> </ul>"},{"location":"concepts/0021-didcomm-message-anatomy/#summary","title":"Summary","text":"<p>Explain the basics of DID communication messages at a high level, and link to other RFCs to promote deeper exploration.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#motivation","title":"Motivation","text":"<p>Promote a deeper understanding of the DIDComm message anatomy through a overarching view of the two distinct levels of messages in a single place.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#tutorial","title":"Tutorial","text":"<p>DIDComm messages are comprised of the following two main layers, which are not dissimilar to how postal messages occur in the real world.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#envelope-level","title":"Envelope Level","text":"<p>As the name suggests, <code>envelope</code> borrows from the analogy of how physical messages are handled in the postal system, this message format level acts as the digital envelope for DIDComm messages.</p> <p>There are two main variations of the envelope level format which are defined to cater for the different audiences and use cases DIDComm messages serve.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#1-encrypted","title":"1. Encrypted","text":"<p>This format is for when the audience of the message is a DID or DID's known to the sender, in this case the message can be prepared and encrypted with the key information present in the audiences DID docs.</p> <p>Within this encrypted format, there are multiple sub-formats which give rise to different properties.</p> <ol> <li>Anonymous Encrypted format This format is when a message is encrypted to a recipient in an anonymous fashion, and it does not include any sender information.</li> <li>Authenticated Encrypted format This format is when a message is encrypted to a recipient and sender information is included through the use of authenticated encryption. With this format only the true recipient(s) can both decrypt the message and authenticate its content is truly from the sender.</li> <li>Signed Encrypted format This format is when a message is encrypted to the recipient and sender information is included along with a non-repudiable signature. In this case the recipient(s) is still the only party that can decrypt the message. However, because the underlying message includes non-repudiability, authentication of the decrypted message content can be done by any party who knows the sender.</li> </ol>"},{"location":"concepts/0021-didcomm-message-anatomy/#2-signed-unencrypted","title":"2. Signed Unencrypted","text":"<p>This format is for when the audience of the message is unknown (for example some form of public challenge). This format is signed, so that when a member of the audience receives the message they can authenticate the message with its non-repudiable signature.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#serialization-format","title":"Serialization Format","text":"<p>All of the envelope level formats are achieved through JOSE based structures. The encrypted formats uses a JWE structure, whereas the signed unencrypted format uses a JWS structure.</p> <p>Details on the encrypted forms are found here</p> <p>Details on the signed un-encrypted are TBC</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#content-level","title":"Content Level","text":"<p>This level to continue the postal metaphor is the content inside the envelope and contains the message.</p> <p>At this level, several conventions are defined around how messages are structured, which facilitates in message identification and processing.</p> <p>The most important ../../concepts to introduce about these conventions are the following.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#message-type","title":"Message Type","text":"<p>Every message contains a message type which allows the context of the message to be established and therefore process the content, see here for more information. It is also important to note that in DIDComm, the message identification does not just identify the message, the message type also identifies the associated protocol. These protocols are essentially a group of related messages that are together required to achieve some form of multi-step flow see here for more information.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#message-id","title":"Message Id","text":"<p>Every message contains a message id which is uniquely generated by the sender, this allows unique identification of the message. See here for more information.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#decorators","title":"Decorators","text":"<p>DIDComm messages at a content level allow for the support of re-usable conventions that are present across multiple messages in order to handle the same functionality in a consistent manner.</p> <p>A relevant analogy for decorators, is that they are like HTTP headers in a HTTP request. The same HTTP header is often reused as a convention across multiple requests to achieve cross cutting functionality.</p> <p>See here for more details.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#serialization-format_1","title":"Serialization Format","text":"<p>At present all content level messages are represented as JSON. Further more these messages are also JSON-LD sympathetic however they do not have full and direct support for JSON-LD.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#reference","title":"Reference","text":"<p>All references are defined inline where required.</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"concepts/0021-didcomm-message-anatomy/#rationale-and-alternatives","title":"Rationale and alternatives","text":""},{"location":"concepts/0021-didcomm-message-anatomy/#prior-art","title":"Prior art","text":""},{"location":"concepts/0021-didcomm-message-anatomy/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"concepts/0021-didcomm-message-anatomy/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0029-message-trust-contexts/","title":"Aries RFC 0029: Message Trust Contexts","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: Not practically applied.</li> <li>Supersedes: Indy HIPE PR #120</li> <li>Start Date: 2018-02-10 (approx, backdated)</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0029-message-trust-contexts/#summary","title":"Summary","text":"<p>Introduces the concept of Message Trust Contexts and describes how they are populated and used.</p>"},{"location":"concepts/0029-message-trust-contexts/#motivation","title":"Motivation","text":"<p>An important aim of DID Communication is to let parties achieve high trust. Such trust is vital in cases where money changes hands and identity is at stake. However, sometimes lower trust is fine; playing tic-tac-toe ought to be safe through agents, even with a malicious stranger.</p> <p>We may intuitively understand the differences in these situations, but intuition isn't the best guide when designing a secure ecosystem. Trust is a complex, multidimensional phenomenon. We need a formal way to analyze it, and to test its suitability in particular circumstances.</p>"},{"location":"concepts/0029-message-trust-contexts/#tutorial","title":"Tutorial","text":"<p>When Alice sends a message to Bob, how much should Bob trust it?</p> <p>This is not a binary question, with possible answers of \"completely\" or \"not at all\". Rather, it is a nuanced question that should consider many factors. Some clarifying questions might include:</p> <ul> <li> <p>How much does Bob know about Alice? And what evidence is behind that knowledge?</p> </li> <li> <p>Was the confidentiality and integrity of the message protected while it was in transit? If so:</p> <ul> <li>How strong is the encryption algorithm?</li> <li>How good are the protections on the keys?</li> <li>Is perfect forward secrecy being used?</li> </ul> </li> <li> <p>Does Bob have any kind of prior relationship to Alice, such that history increases (or decreases) trust?</p> </li> <li> <p>Is the message repudiable, or is Alice speaking \"on the record\"?</p> </li> <li> <p>Could Alice use a malformed message to attack Bob (e.g., with buffer overflows, numeric range errors, unexpected fields, and so forth)?</p> </li> </ul>"},{"location":"concepts/0029-message-trust-contexts/#message-trust-contexts","title":"Message Trust Contexts","text":"<p>The DID Communication ecosystem formalizes the idea of a Message Trust Context (MTC) to expose such questions, make their answers explicit, and encourage thoughtful choices based on the answers.</p> <p>An MTC is an object that holds trust context for a message. This context follows a message throughout its processing journey inside the agent that receives it, and it should be analyzed and updated for decision-making purposes throughout.</p> <p>Protocols should be designed with standard MTCs in mind. Thus, it is desirable that all implementations share common names for certain ../../concepts, so we can discuss them conveniently in design docs, error messages, logs, and so forth. The standard dimensions of trust tracked in an MTC break down into two groups:</p>"},{"location":"concepts/0029-message-trust-contexts/#crypto-related","title":"Crypto-related","text":"<ul> <li>Confidentiality: Could the plaintext content of the message I just received over this channel have been observed by another party?</li> <li>Integrity: Could the message have been tampered with since it was sent?</li> <li>Authenticated Origin: Can I know the identity of the original sender with confidence? And if so, on what basis--were multiple factors of auth required to use the keys that encrypted the message? Were biometrics at play?</li> <li>Nonrepudiation: Can I prove the identity of the sender to a third party? Note that this guarantee may or may not be a desirable quality.</li> <li>PFS: Is perfect forward secrecy active?</li> <li>Uniqueness: Can I know that this message is not being sent as part of a replay attack?</li> <li>Limited Scope: Does the sender identify me in a way that is only meaningful inside a narrow context (e.g., pairwise or nwise relationship), to preserve my privacy? Or did they use a published DID that would correlate me?</li> </ul>"},{"location":"concepts/0029-message-trust-contexts/#input-validations","title":"Input validations","text":"<ul> <li>Size OK: Do I know that the message will not overflow internal buffers or persistent storage?</li> <li>Deserialize OK: Does the plaintext message deserialize into native object representation?</li> <li>Keys OK: As a native object, do the keys (property names) and structure match what was expected? In some approaches to deserialization, it may be combined with the previous question--but in languages that produce a loose dictionary from JSON, it is distinct.</li> <li>Values OK: As a native object, do the values for properties match the datatypes, sizes, and constraints that were expected?</li> </ul> <p>In code, these types of trust are written using whatever naming convention matches the implementer's programming language, so <code>authenticated_origin</code> and <code>authenticatedOrigin</code> are synonyms of each other and of <code>Authenticated Origin</code>.</p>"},{"location":"concepts/0029-message-trust-contexts/#notation","title":"Notation","text":"<p>In protocol designs, the requirements of a message trust context should be declared when message types are defined. For example, the <code>credential_offer</code> message in the <code>credential_issuance</code> protocol should not be accepted unless it has <code>Integrity</code> and <code>Authenticated Origin</code> in its MTC (because otherwise a MITM could interfere). The definition of the message type should say this. Its RFC does this by notating:</p> <pre><code>mtc: +integrity +authenticated_origin\n</code></pre> <p>When a loan is digitally signed, we probably need:</p> <pre><code>mtc: +integrity +authenticated_origin +nonrepudiation\n</code></pre> <p>The labels for these trust types are long, but they can be shortened if they remain unambiguous. Notice, too, that all of the official MTC fields have unique intial letters. We can therefore abbreviate unambiguously:</p> <pre><code>mtc: +i +a +n\n</code></pre> <p>Any type of trust that does not appear in MTC notation is assumed to be <code>undefined</code> (meaning no claim is made about it either way, perhaps because it hasn't been evaluated or because it doesn't matter). However, sometimes we need to make a lack of trust explicit. We might claim in a protocol definition that a particular type of trust is definitely not required. Or we might want to show that we evaluated a particular trust at runtime, and had a negative outcome. In such cases, we can do this:</p> <pre><code>mtc: +i +a -n\n</code></pre> <p>Here, we are explicitly denying that <code>nonrepudiation</code> is part of the trust context.</p> <p>For further terseness in our notation, spaces can be omitted:</p> <pre><code>mtc: +i+a-n\n</code></pre> <p>Finally, an mtc that makes no explicit positive or negative claims (undefined) is written as:</p> <pre><code>mtc: ?\n</code></pre> <p>This MTC notation is a supplement to SSI Notation and should be treated as equally normative. Such notation might be useful in log files and error messages, among other things. See Using a Message Trust Context at Runtime below.</p>"},{"location":"concepts/0029-message-trust-contexts/#custom-trust","title":"Custom Trust","text":"<p>Specific agents may make trust distinctions that are helpful in their own problem domains. For example, some agents may evaluate trust on the physical location or IP address of a sender, or on the time of day that a message arrives. Others may use DIDComm for internal processes that have unique trust requirements over and above those that matter in interoperable scenarios, such as whether a message emanates from a machine running endpoint compliance software, or whether it has passed through intrusion detection or data loss prevention filters.</p> <p>Agent implementations are encouraged to add their own trust dimensions to their own implementations of a Message Trust Context, as long as they do not redefine the standard labels. In cases where custom trust types introduce ambiguity with trust labels, MTC notation requires enough letters to disambiguate labels. So if a complex custom MTC has fields named <code>intrusion_detect_ok</code>, <code>ipaddr_ok</code> (which both start like the standard <code>integrity</code>), and <code>endpoint_compliance</code> (which has no ambiguity with a standard token) it might be notated as:</p> <pre><code>mtc: +c+a+inte+intr+ip-n-p-e\n</code></pre> <p>Here, <code>inte</code> matches the standard label <code>integrity</code>, whereas <code>intr</code> and <code>ip</code> are known to be custom because they don't match a standard label; <code>e</code> is custom but only a single letter because it is unambiguous.</p>"},{"location":"concepts/0029-message-trust-contexts/#populating-a-message-trust-context-at-runtime","title":"Populating a Message Trust Context at Runtime","text":"<p>A Message Trust Context comes into being when it arrives on the wire at the receiving agent and begins its processing flow.</p> <p>The first step may be an input validation to confirm that the message doesn't exceed a max size. If so, the empty MTC is updated with <code>+s</code>.</p> <p>Another early step is decryption. This should allow population of the <code>confidentiality</code> and <code>authenticated_origin</code> dimensions, at least.</p> <p>Subsequent layers of code that do additional analysis should update the MTC as appropriate. For example, if a signature is not analyzed and validated until after the decryption step, the signature's presence or absence should cause <code>nonrepudiation</code> and maybe <code>integrity</code> to be updated. Similarly, once the plaintext of a message is known to be a valid enough to deserialize into an object, the MTC acquires <code>+deserialize_ok</code>. Later, when the fields of the message's native object representation have been analyzed to make sure they conform to a particular structure, it should be updated again with <code>+key_ok</code>. And so forth.</p>"},{"location":"concepts/0029-message-trust-contexts/#using-a-message-trust-context-at-runtime","title":"Using a Message Trust Context at Runtime","text":"<p>As message processing happens, the MTC isn't just updated. It should constantly be queried, and decisions should be made on the basis of what the MTC says. These decisions can vary according to the preferences of agent developers and the policies of agent owners. Some agents may choose not to accept any messages that are <code>-a</code>, for example, while others may be content to talk with anonymous senders. The recommendations of protocol designers should never be ignored, however; it is probably wrong to accept a <code>-n</code> message that signs a loan, even if agent policy is lax about other things. Formally declared MTCs in a protocol design may be linked to security proofs...</p> <p>Part of the intention with the terse MTC notation is that conversations about agent trust should be easy and interoperable. When agents send one another <code>problem-report</code> messages, they can turn MTCs into human-friendly text, but also use this notation: \"Unable to accept a payment from message that lacks Integrity guarantees (-i).\" This notation can help diagnose trust problems in logs. It may also be helpful with message tracing, feature discovery, and agent testing.</p>"},{"location":"concepts/0029-message-trust-contexts/#attachments","title":"Attachments","text":"<p>MTCs apply to the entirety of the associated message's attributes. However, embedded and appended message attachments present the unique situation of nested content with the potential for a trust context that differs from the parent message.</p> <p>The attachment descriptor, used for both embedded and appended attachments, shares the same MTC as the parent message. Unpacked attachment data have their own Trust Contexts populated as appropriate depending on how the data was retrieved, whether the attachment is signed, whether an integrity checksum was provided and verified, etc.</p> <p>Attachments delivered by the parent message, i.e. as base64url-encoded data, inherit relevant trust contexts from the parent, such as <code>confidentiality</code> and <code>authenticated_origin</code>, when the message was delivered as an authenticated encrypted message.</p> <p>Attachments retrieved from a remote resource populate their trust context as relevant to the retrieval mechanism.</p>"},{"location":"concepts/0029-message-trust-contexts/#reference","title":"Reference","text":"<p>A complete reference implementation of MTCs in python is attached to this RFC (see mtc.py). It could easily be extended with custom trust dimensions, and it would be simple to port to other programming languages. Note that the implementation includes unit tests written in pytest style, and has only been tested on python 3.x.</p>"},{"location":"concepts/0029-message-trust-contexts/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes MTC reference impl Reference impl in python, checked in with RFC. Includes unit tests. Aries Protocol Test Suite Aries Static Agent - Python Largely inspired by reference implementation; MTC populated and made available to handlers."},{"location":"concepts/0046-mediators-and-relays/","title":"Aries RFC 0046: Mediators and Relays","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2019-02-01</li> <li>Status Note: Socialized and broadly understood in other conceptual RFCs about routing.</li> <li>Start Date: 2018-12-01</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0046-mediators-and-relays/#summary","title":"Summary","text":"<p>The mental model for agent-to-agent messaging (A2A) messaging includes two important communication primitives that have a meaning unique to our ecosystem: mediator and relay.</p> <p>A mediator is a participant in agent-to-agent message delivery that must be modeled by the sender. It has its own keys and will deliver messages only after decrypting an outer envelope to reveal a <code>forward</code> request. Many types of mediators may exist, but two important ones should be widely understood, as they commonly manifest in DID Docs:</p> <ol> <li>A service that hosts many cloud agents at a single endpoint to provide herd privacy (an \"agency\") is a mediator.</li> <li>A cloud-based agent that routes between/among the edges of a sovereign domain is a mediator.</li> </ol> <p>A relay is an entity that passes along agent-to-agent messages, but that can be ignored when the sender considers encryption choices. It does not decrypt anything. Relays can be used to change the transport for a message (e.g., accept an HTTP POST, then turn around and emit an email; accept a Bluetooth transmission, then turn around and emit something in a message queue). Mix networks like TOR are an important type of relay.</p> <p>Read on to explore how agent-to-agent communication can model complex topologies and flows using these two primitives.</p>"},{"location":"concepts/0046-mediators-and-relays/#motivation","title":"Motivation","text":"<p>When we describe agent-to-agent communication, it is convenient to think of an interaction only in terms of Alice and Bob and their agents. We say things like: \"Alice's agent sends a message to Bob's agent\" -- or perhaps \"Alice's edge agent sends a message to Bob's cloud agent, which forwards it to Bob's edge agent\".</p> <p>Such statements adopt a useful level of abstraction--one that's highly recommended for most discussions. However, they make a number of simplifications. By modeling the roles of mediators and relays in routing, we can support routes that use multiple transports, routes that are not fully known (or knowable) to the sender, routes that pass through mix networks, and other advanced and powerful ../../concepts.</p>"},{"location":"concepts/0046-mediators-and-relays/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0046-mediators-and-relays/#key-concepts","title":"Key Concepts","text":"<p>Let's define mediators and relays by exploring how they manifest in a series of communication scenarios between Alice and Bob.</p>"},{"location":"concepts/0046-mediators-and-relays/#scenario-1-base","title":"Scenario 1 (base)","text":"<p>Alice and Bob are both employees of a large corporation. They work in the same office, but have never met. The office has a rule that all messages between employees must be encrypted. They use paper messages and physical delivery as the transport. Alice writes a note, encrypts it so only Bob can read it, puts it in an envelope addressed to Bob, and drops the envelope on a desk that she has been told belongs to Bob. This desk is in fact Bob's, and he later picks up the message, decrypts it, and reads it.</p> <p></p> <p>In this scenario, there is no mediator, and no relay.</p>"},{"location":"concepts/0046-mediators-and-relays/#scenario-2-a-gatekeeper","title":"Scenario 2: a gatekeeper","text":"<p>Imagine that Bob hires an executive assistant, Carl, to filter his mail. Bob won't open any mail unless Carl looks at it and decides that it's worthy of Bob's attention.</p> <p>Alice has to change her behavior. She continues to package a message for Bob, but now she must account for Carl as well. She take the envelope for Bob, and places it inside a new envelope addressed to Carl. Inside the outer envelope, and next to the envelope destined for Bob, Alice writes Carl an encrypted note: \"This inner envelope is for Bob. Please forward.\"</p> <p></p> <p>Here, Carl is acting as a mediator. He is mostly just passing messages along. But because he is processing a message himself, and because Carl is interposed between Alice and Bob, he affects the behavior of the sender. He is a known entity in the route.</p>"},{"location":"concepts/0046-mediators-and-relays/#scenario-3-transparent-indirection","title":"Scenario 3: transparent indirection","text":"<p>All is the same as the base scenario (Carl has been fired), except that Bob is working from home when Alice's message lands on his desk. Bob has previously arranged with his friend Darla, who lives near him, to pick up any mail that's on his desk and drop it off at his house at the end of the work day. Darla sees Alice's note and takes it home to Bob.</p> <p></p> <p>In this scenario, Darla is acting as a relay. Note that Bob arranges for Darla to do this without notifying Alice, and that Alice does not need to adjust her behavior in any way for the relay to work.</p>"},{"location":"concepts/0046-mediators-and-relays/#scenario-4-more-indirection","title":"Scenario 4: more indirection","text":"<p>Like scenario 3, Darla brings Bob his mail at home. However, Bob isn't at home when his mail arrives. He's had to rush out on an errand, but he's left instructions with his son, Emil, to open any work mail, take a photo of the letter, and text him the photo. Emil intends to do this, but the camera on his phone misfires, so he convinces his sister, Francis, to take the picture on her phone and email it to him. Then he texts the photo to Bob, as arranged.</p> <p></p> <p>Here, Emil and Francis are also acting as relays. Note that nobody knows about the full route. Alice thinks she's delivering directly to Bob. So does Darla. Bob knows about Darla and Emil, but not about Francis.</p> <p>Note, too, how the transport is changing from physical mail to email to text.</p> <p>To the party immediately upstream (closer to the sender), a relay is indistinguishable from the next party downstream (closer to the recipient). A party anywhere in the chain can insert one or more relays upstream from themselves, as long as those relays are not upstream of another named party (sender or mediator).</p>"},{"location":"concepts/0046-mediators-and-relays/#more-scenarios","title":"More Scenarios","text":"<p>Mediators and relays can be combined in any order and any amount in variations on our fictional scenario. Bob could employ Carl as a mediator, and Carl could work from home and arrange delivery via George, then have his daughter Hannah run messages back to Bob's desk at work. Carl could hire his own mediator. Darla could arrange or Ivan to substitute for her when she goes on vacation. And so forth.</p>"},{"location":"concepts/0046-mediators-and-relays/#more-traditional-usage","title":"More Traditional Usage","text":"<p>The scenarios used above are somewhat artificial. Our most familiar agent-to-agent scenarios involve edge agents running on mobile devices and accessible through bluetooth or push notification, and cloud agents that use electronic protocols as their transport. Let's see how relays and mediators apply there.</p>"},{"location":"concepts/0046-mediators-and-relays/#scenario-5-traditional-base","title":"Scenario 5 (traditional base)","text":"<p>Alice's cloud agent wants to talk to Bob's cloud agent. Bob's cloud agent is listening at http://bob.com/agent. Alice encrypts a message for Bob and posts it to that URL.</p> <p></p> <p>In this scenario, we are using a direct transport with neither a mediator nor a relay.</p> <p>If you are familiar with common routing patterns and you are steeped in HTTP, you are likely objecting at this point, pointing out ways that this description diverges from best practice, including what's prescribed in other RFC. You may be eager to explain why this is a privacy problem, for example.</p> <p>You are not wrong, exactly. But please suspend those concerns and hang with me. This is about what's theoretically possible in the mental model. Besides, I would note that virtually the same diagram could be used for a Bluetooth agent conversation:</p> <p></p>"},{"location":"concepts/0046-mediators-and-relays/#scenario-6-herd-hosting","title":"Scenario 6: herd hosting","text":"<p>Let's tweak Scenario 5 slightly by saying that Bob's agent is one of thousands that are hosted at the same URL. Maybe the URL is now http://agents-r-us.com/inbox. Now if Alice wants to talk to Bob's cloud agent, she has to cope with a mediator. She wraps the encrypted message for Bob's cloud agent inside a <code>forward</code> message that's addressed to and encrypted for the agent of agents-r-us that functions as a gatekeeper.</p> <p></p> <p>This scenario is one that highlights an external mediator--so-called because the mediator lives outside the sovereign domain of the final recipient.</p>"},{"location":"concepts/0046-mediators-and-relays/#scenario-7-intra-domain-dispatch","title":"Scenario 7: intra-domain dispatch","text":"<p>Now let's subtract agents-r-us. We're back to Bob's cloud agent listening directly at http://bob.com/agent. However, let's say that Alice has a different goal--now she wants to talk to the edge agent running on Bob's mobile device. This agent doesn't have a permanent IP address, so Bob uses his own cloud agent as a mediator. He tells Alice that his mobile device agent can only be reached via his cloud agent.</p> <p></p> <p>Once again, this causes Alice to modify her behavior. Again, she wraps her encrypted message. The inner message is enclosed in an outer envelope, and the outer envelope is passed to the mediator.</p> <p>This scenario highlights an internal mediator. Internal and external mediators introduce similar ../../features and similar constraints; the relevant difference is that internal mediators live within the sovereign domain of the recipient, and may thus be worthy of greater trust.</p>"},{"location":"concepts/0046-mediators-and-relays/#scenario-8-double-mediation","title":"Scenario 8: double mediation","text":"<p>Now let's combine. Bob's cloud agent is hosted at agents-r-us, AND Alice wants to reach Bob's mobile:</p> <p></p> <p>This is a common pattern with HTTP-based cloud agents plus mobile edge agents, which is the most common deployment pattern we expect for many users of self-sovereign identity. Note that the properties of the agency and the routing agent are not particularly special--they are just an external and an internal mediator, respectively.</p>"},{"location":"concepts/0046-mediators-and-relays/#related-concepts","title":"Related Concepts","text":""},{"location":"concepts/0046-mediators-and-relays/#routes-are-one-way-not-duplex","title":"Routes are One-Way (not duplex)","text":"<p>In all of this discussion, note that we are analyzing only a flow from Alice to Bob. How Bob gets a message back to Alice is a completely separate question. Just because Carl, Darla, Emil, Francis, and Agents-R-Us may be involved in how messages flow from Alice to Bob, does not mean they are involved in flow the opposite direction.</p> <p>Note how this breaks the simple assumptions of pure request-response technologies like HTTP, that assume the channel in (request) is also the channel out (response). Duplex request-response can be modeled with A2A, but doing so requires support that may not always be available, plus cooperative behavior governed by the <code>~thread</code> decorator.</p>"},{"location":"concepts/0046-mediators-and-relays/#conventions-on-direction","title":"Conventions on Direction","text":"<p>For any given one-way route, the direction of flow is always from sender to receiver. We could use many different metaphors to talk about the \"closer to sender\" and \"closer to receiver\" directions -- upstream and downstream, left and right, before and after, in and out. We've chosen to standardize on two:</p> <ul> <li> <p>The SSI Notation uses directional arrows. A message from Alice to Bob is notated as either <code>A --&gt; B</code> or <code>B &lt;-- A</code> -- whether the arrow faces left or right, it always points to Bob.</p> </li> <li> <p>In text, we use the words source-ward and dest-ward to clarify whether we are moving toward the sender, or toward the receiver, respectively. \"Dest-ward\" always corresponds to where the arrow is pointing and to later points in time; \"source-ward\" is the opposite direction. All messages, whether requests, responses, or otherwise, always flow dest-ward.</p> </li> </ul>"},{"location":"concepts/0046-mediators-and-relays/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem. DIDComm mediator Open source cloud-based mediator with Firebase support."},{"location":"concepts/0047-json-ld-compatibility/","title":"Aries RFC 0047: JSON-LD Compatibility","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2019-02-20</li> <li>Status Note: Has guided Indy design choices for several months. Not yet ratified by greater Aries community. </li> <li>Supersedes: Indy HIPE 0035</li> <li>Start Date: 2019-01-23</li> <li>Tags: concept, decorator</li> </ul>"},{"location":"concepts/0047-json-ld-compatibility/#summary","title":"Summary","text":"<p>Explains the goals of DID Communication with respect to JSON-LD, and how Aries proposes to accomplish them.</p>"},{"location":"concepts/0047-json-ld-compatibility/#motivation","title":"Motivation","text":"<p>JSON-LD is a familiar body of conventions that enriches the expressive power of plain JSON. It is natural for people who arrive in the DID Communication (DIDComm) ecosystem to wonder whether we are using JSON-LD--and if so, how. We need a coherent answer that clarifies our intentions and that keeps us true to those intentions as the ecosystem evolves.</p>"},{"location":"concepts/0047-json-ld-compatibility/#tutorial","title":"Tutorial","text":"<p>The JSON-LD spec is a recommendation work product of the W3C RDF Working Group Since it was formally recommended as version 1.0 in 2014, the JSON for Linking Data Community Group has taken up not-yet-standards-track work on a 1.1 update.</p> <p>JSON-LD has significant gravitas in identity circles. It gives to JSON some capabilities that are sorely needed to model the semantic web, including linking, namespacing, datatyping, signing, and a strong story for schema (partly through the use of JSON-LD on schema.org).</p> <p>However, JSON-LD also comes with some conceptual and technical baggage. It can be hard for developers to master its subtleties; it requires very flexible parsing behavior after built-in JSON support is used to deserialize; it references a family of related specs that have their own learning curve; the formality of its test suite and libraries may get in the way of a developer who just wants to read and write JSON and \"get stuff done.\"</p> <p>In addition, the problem domain of DIDComm is somewhat different from the places where JSON-LD has the most traction. The sweet spot for DIDComm is small, relatively simple JSON documents where code behavior is strongly bound to the needs of a specific interaction. DIDComm needs to work with extremely simple agents on embedded platforms. Such agents may experience full JSON-LD support as an undue burden when they don't even have a familiar desktop OS. They don't need arbitrary semantic complexity.</p> <p>If we wanted to use email technology to send a verifiable credential, we would model the credential as an attachment, not enrich the schema of raw email message bodies. DIDComm invites a similar approach.</p>"},{"location":"concepts/0047-json-ld-compatibility/#goal","title":"Goal","text":"<p>The DIDComm messaging effort that began in the Indy community wants to benefit from the accessibility of ordinary JSON, but leave an easy path for more sophisticated JSON-LD-driven patterns when the need arises. We therefore set for ourselves this goal:</p> <p>Be compatible with JSON-LD, such that advanced use cases can take advantage   of it where it makes sense, but impose no dependencies on the mental model or   the tooling of JSON-LD for the casual developer.</p>"},{"location":"concepts/0047-json-ld-compatibility/#what-the-casual-developer-needs-to-know","title":"What the Casual Developer Needs to Know","text":"<ul> <li> <p>The <code>@</code> character in DIDComm messages is reserved for JSON-LD-isms. Any usage of JSON keys that begin with this character is required to be JSON-LD-compatible, and any time you see it, you are seeing JSON-LD at work.</p> </li> <li> <p><code>@type</code> and <code>@id</code> are required at the root of every message. The meaning of these fields in DIDComm matches JSON-LD's expectations, but you don't need to learn JSON-LD to use them.</p> </li> <li> <p>JSON-LD's more advanced mechanisms are an option--not invoked ad hoc on a message-by-message basis, but specified in the formal description of a message family. You will know how much JSON-LD is relevant to a protocol when you implement it. In general, the community will want to discuss usage of new JSON-LD constructs before embracing them in protocols with broad interoperability intentions, because of the goal articulated above.</p> </li> <li> <p>The decorator concept in DIDComm is orthogonal to JSON-LD, and is far more likely to be relevant to your early learning. See the Decorator RFC.</p> </li> </ul> <p>That's it.</p>"},{"location":"concepts/0047-json-ld-compatibility/#details","title":"Details","text":"<p>Compatibility with JSON-LD was evaluated against version 1.1 of the JSON-LD spec, current in early 2019. If material changes in the spec are forthcoming, a new analysis may be worthwhile. Our current understanding follows.</p>"},{"location":"concepts/0047-json-ld-compatibility/#type","title":"<code>@type</code>","text":"<p>The type of a DIDComm message, and its associated route or handler in dispatching code, is given by the JSON-LD <code>@type</code> property at the root of a message. JSON-LD requires this value to be an IRI. DIDComm DID references are fully compliant. Instances of <code>@type</code> on any node other than a message root have JSON-LD meaning, but no predefined relevance in DIDComm.</p>"},{"location":"concepts/0047-json-ld-compatibility/#id","title":"<code>@id</code>","text":"<p>The identifier for a DIDComm message is given by the JSON-LD <code>@id</code> property at the root of a message. JSON-LD requires this value to be an IRI. DIDComm message IDs are relative IRIs, and can be converted to absolute form as described in RFC 0217: Linkable Message Paths. Instances of <code>@id</code> on any node other than a message root have JSON-LD meaning, but no predefined relevance in DIDComm.</p>"},{"location":"concepts/0047-json-ld-compatibility/#context","title":"<code>@context</code>","text":"<p>This is JSON-LD\u2019s namespacing mechanism. It is active in DIDComm messages, but can be ignored for simple processing, in the same way namespaces in XML are often ignored for simple tasks.</p> <p>Every DIDComm message has an associated <code>@context</code>, but we have chosen to follow the procedure described in section 6 of the JSON-LD spec, which focuses on how ordinary JSON can be intepreted as JSON-LD by communicating <code>@context</code> out of band.</p> <p>DIDComm messages communicate the context out of band by specifying it in the protocol definition (e.g., RFC) for the associated message type; thus, the value of <code>@type</code> indirectly gives the relevant <code>@context</code>. In advanced use cases, <code>@context</code> may appear in a DIDComm message, supplementing this behavior.</p>"},{"location":"concepts/0047-json-ld-compatibility/#ordering","title":"Ordering","text":"<p>JSON-LD specifies that the order of items in arrays is NOT significant, and notes (correctly) that this is the opposite of the standard assumption for plain JSON. This makes sense when viewed through the lens of JSON-LD\u2019s role as a transformation of RDF.</p> <p>Since we want to violate as few assumptions as possible for a developer with general knowledge of JSON, DIDComm messages reverse this default, making arrays an ordered construct, as if all DIDComm message <code>@context</code>s contained something like:</p> <p><pre><code>\"each field\": { \"@container\": \"@list\"}\n</code></pre> To contravene the default, use a JSON-LD construction like this in <code>@context</code>:</p> <pre><code>\"myfield\": { \"@container\": \"@set\"}\n</code></pre>"},{"location":"concepts/0047-json-ld-compatibility/#decorators","title":"Decorators","text":"<p>Decorators are JSON fragments that can be included in any DIDComm message. They enter the formally defined JSON-LD namespace via a JSON-LD fragment that is automatically imputed to every DIDComm message:</p> <pre><code>\"@context\": {\n  \"@vocab\": \"https://github.com/hyperledger/aries-rfcs/\"\n}\n</code></pre> <p>All decorators use the reserved prefix char <code>~</code> (tilde). For more on decorators, see the Decorator RFC.</p>"},{"location":"concepts/0047-json-ld-compatibility/#signing","title":"Signing","text":"<p>JSON-LD is associated but not strictly bound to a signing mechanism, LD-Signatures. It\u2019s a good mechanism, but it comes with some baggage: you must canonicalize, which means you must resolve every \u201cterm\u201d (key name) to its fully qualified form by expanding contexts before signing. This raises the bar for JSON-LD sophistication and library dependencies.</p> <p>The DIDComm community is not opposed to using LD Signatures for problems that need them, but has decided not to adopt the mechanism across the board. There is another signing mechanism that is far simpler, and adequate for many scenarios. We\u2019ll use whichever scheme is best suited to circumstances.</p>"},{"location":"concepts/0047-json-ld-compatibility/#type-coercion","title":"Type Coercion","text":"<p>DIDComm messages generally do not need this feature of JSON-LD, because there are well understood conventions around date-time datatypes, and individual RFCs that define each message type can further clarify such subtleties. However, it is available on a message-type-definition basis (not ad hoc).</p>"},{"location":"concepts/0047-json-ld-compatibility/#node-references","title":"Node References","text":"<p>JSON-LD lets one field reference another. See example 93 (note  that the ref could have just been \u201c#me\u201d instead of the fully qualified IRI).  We may need this construct at some point in DIDComm, but it is not in active  use yet.</p>"},{"location":"concepts/0047-json-ld-compatibility/#internationalization-and-localization","title":"Internationalization and Localization","text":"<p>JSON-LD describes a mechanism for this. It has approximately the same ../../features as the one described in Aries RFC 0043, with a few exceptions:</p> <ul> <li>The JSON-LD mechanism only applies to strings; it is explicitly disallowed for describing dates, numbers, or any strings that coerce to dates or numbers.</li> <li>The JSON-LD mechanism is language-centric rather than locale-centric. For example, it doesn't specify sort order, time-of-day, or currency semantics.</li> <li>There is no notion of a code that maps to strings--just a notion of strings that all have the same meaning. This means it doesn\u2019t help us solve the problem of locale-independent error codes.</li> <li>The notion of mappings of values for different locales is separable into an external catalog, but only if a value is referenced or included implicitly in a doc. In other words, a processor has to see the full message catalog when evaluating the doc.</li> <li>It\u2019s a bit awkward to retrofit onto an existing schema, because it requires a redefinition of the field that contains localized values, from being a single string to being a dictionary with language mappings. In other words, the schema before and after a developer adds localization support is not just different by new, optional fields; it is a breaking change. This contrasts with the indy PR approach, where the language mapping can be added after the fact, and gets associated by convention.</li> <li>It doesn\u2019t support localization of keys--only values. There are corner cases where key localization is desirable.</li> </ul> <p>Because of these misalignments, the DIDComm ecosystem plans to use its own solution to this problem.</p>"},{"location":"concepts/0047-json-ld-compatibility/#additional-json-ld-constructs","title":"Additional JSON-LD Constructs","text":"<p>The following JSON-LD keywords may be useful in DIDComm at some point in the future: <code>@base</code>, <code>@index</code>, <code>@container</code> (cf <code>@list</code> and <code>@set</code>), <code>@nest</code>, <code>@value</code>, <code>@graph</code>, <code>@prefix</code>, <code>@reverse</code>, <code>@version</code>.</p>"},{"location":"concepts/0047-json-ld-compatibility/#drawbacks","title":"Drawbacks","text":"<p>By attempting compatibility but only lightweight usage of JSON-LD, we are neither all-in on JSON-LD, nor all-out. This could cause confusion. We are making the bet that most developers won't need to know or care about the details; they'll simply learn that <code>@type</code> and <code>@id</code> are special, required fields on messages. Designers of protocols will need to know a bit more.</p>"},{"location":"concepts/0047-json-ld-compatibility/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>We could go all-in on JSON-LD. This would require adoption of sophisticated parsing that is impractical on embedded platforms, but it would add a lot of semantic sophistication.</li> <li>We could avoid JSON-LD entirely. This would force us to reinvent the wheel in some cases, and it would be frustrating to our friends in other SSI communities that are more JSON-LD-centric.</li> </ul>"},{"location":"concepts/0047-json-ld-compatibility/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the reversal of JSON-LD's default of unordered arrays valid?</li> <li>Is there a good way to discover that new DIDComm proposals should consider JSON-LD solutions, and make sure such questions get evaluated thoughtfully?</li> </ul>"},{"location":"concepts/0047-json-ld-compatibility/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0049-repudiation/","title":"Aries RFC 0049: Repudiation","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2019-03-01</li> <li>Status Note: Well understood and baked into various protocol designs and DIDComm processes--but not yet ratified by the larger Aries community. </li> <li>Supersedes: Indy HIPE 0037</li> <li>Start Date: 2018-03-01 (backdated)</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0049-repudiation/#summary","title":"Summary","text":"<p>Explain DID Communication's perspective on repudiation, and how this influences the DIDComm approach to digital signatures.</p>"},{"location":"concepts/0049-repudiation/#motivation","title":"Motivation","text":"<p>A very common mistake among newcomers to cryptography is to assume that digital signatures are the best way to prove the origin of data. While it is true that digital signatures can be used in this way, over-signing creates a digital exhaust that can lead to serious long-term privacy problems. We do use digital signatures, but we want to be very deliberate about when and why--and by default, we want to use a more limited technique called authenticated encryption. This doc explains the distinction and its implications.</p>"},{"location":"concepts/0049-repudiation/#tutorial","title":"Tutorial","text":"<p>If Carol receives a message that purports to come from Alice, she may naturally ask:</p> <p>Do I know that this really came from Alice?</p> <p>This is a fair question, and an important one. There are two ways to answer it:</p> <ul> <li>Alice can send in a way that's repudiable</li> <li>Alice can send in a way that's non-repudiable</li> </ul> <p>Both of these approaches can answer Carol's question, but they differ   in who can trust the answer. If Carol knows Alice is the sender,  but can't prove it to anybody else, then we say the  message is publicly repudiable; if Carol can prove the origin  to others, then we say the message is non-repudiable.</p> <p>The repudiable variant is accomplished with a technique called authenticated encryption.</p> <p>The non-repudiable variant is accomplished with digital signatures.</p>"},{"location":"concepts/0049-repudiation/#how-authenticated-encryption-works","title":"How Authenticated Encryption Works","text":"<p>Repudiable sending may sound mysterious, but it's actually quite simple.  Alice and Carol can negotiate a shared secret and trust one another not to  leak it. Thereafter, if Alice sends Carol a message that uses the shared  secret (e.g., it's encrypted by a negotiated symmetric  encryption key), then Carol knows the sender must be Alice. However,  she can't prove it to anyone, because Alice's immediate counter-response  could be, \"Carol could have encrypted this herself. She knows the key, too.\"  Notice that this only works in a pairwise channel.</p>"},{"location":"concepts/0049-repudiation/#signatures","title":"Signatures","text":"<p>Non-repudiable messages are typically accomplished with digital  signatures. With signatures, everyone can examine a signature to verify  its provenance.</p> <p>Fancy signature schemes such as ring signatures may represent intermediate  positions, where the fact that a signature was provided by a member of  a group is known--but not which specific member did the signing.</p>"},{"location":"concepts/0049-repudiation/#why-and-when-to-use-each-strategy","title":"Why and When To Use Each Strategy","text":"<p>A common mistake is to assume that digital signatures should be used everywhere because they give the most guarantees. This is a misunderstanding of who needs which guarantees under which conditions.</p> <p>If Alice tells a secret to Carol, who should decide whether the secret is reshared--Alice, or Carol?</p> <p></p> <p>In an SSI paradigm, the proper, desirable default is that a sender of secrets should retain the ability to decide if their secrets are shareable, not give that guarantee away.</p> <p>If Alice sends a repudiable message, she gets a guarantee that Carol can't reshare it in a way that damages Alice. On the other hand, if she sends a message that's digitally signed, she has no control over where Carol shares the secret and proves its provenance. Hopefully Carol has Alice's best interests at heart, and has good judgment and solid cybersecurity...</p> <p>There are certainly cases where non-repudiation is appropriate. If  Alice is entering into a borrower:lender relationship with Carol,  Carol needs to prove to third parties that Alice, and only Alice,  incurred the legal obligation.</p> <p>DIDComm supports both modes of communication. However, properly modeled  interactions tend to favor repudiable messages; non-repudiation must be  a deliberate choice. For this reason, we assume repudiable until  an explicit signature is required (in which case the <code>sign()</code> crypto  primitive is invoked). This matches the physical world, where most  communication is casual and does not carry the weight of legal  accountability--and should not.</p>"},{"location":"concepts/0049-repudiation/#unknown-recipients","title":"Unknown Recipients","text":"<p>Imagine that Alice wants to broadcast a message. She doesn't know who will receive it, so she can't use authenticated encryption. Yet she wants anyone who receives it to know that it truly comes from her.</p> <p>In this situation, digital signatures are required. Note, however, that Alice is trading some privacy for her ability to publicly prove message origin.</p>"},{"location":"concepts/0049-repudiation/#reference","title":"Reference","text":"<p>Authenticated encryption is not something we invented. It is well described in the documentation for libsodium. It is implemented there, and also in the pure javascript port, TweetNacl.</p>"},{"location":"concepts/0049-repudiation/#drawbacks","title":"Drawbacks","text":"<p>The main reason not to emphasize authenticated encryption over digital signatures is that we seem to encounter a steady impedance from people who are signature-oriented. It is hard and time-consuming to reset expectations. However, we have concluded that the gains in privacy are worth the effort.</p>"},{"location":"concepts/0049-repudiation/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0050-wallets/","title":"Aries RFC 0050: Wallets","text":"<ul> <li>Authors: Daniel Hardman, Darko Kulic, Vyacheslav Gudkov, Mike Lodder</li> <li>Status: ACCEPTED</li> <li>Since: 2018-07-01</li> <li>Status Note: Fully implemented in Indy SDK, but not yet socialized well in the broader Aries community. Needs some updates to promote better key management; see related RFC about lox. </li> <li>Supersedes: Indy HIPE 0013</li> <li>Start Date: 2018-05-22</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0050-wallets/#summary","title":"Summary","text":"<p>Specify the external interfaces of identity wallets in the Indy ecosystem, as well as some background ../../concepts, theory, tradeoffs, and internal implementation guidelines.</p> <p></p>"},{"location":"concepts/0050-wallets/#motivation","title":"Motivation","text":"<p>Wallets are a familiar component metaphor that SSI has adopted from the world of cryptocurrencies. The translation isn't perfect, though; crypto wallets have only a subset of the ../../features that an identity wallet needs. This causes problems, as coders may approach wallets in Indy with assumptions that are more narrow than our actual design target.</p> <p>Since wallets are a major vector for hacking and cybersecurity issues, casual or fuzzy wallet requirements are a recipe for frustration or disaster. Divergent and substandard implementations could undermine security more broadly. This argues for as much design guidance and implementation help as possible.</p> <p>Wallets are also a unit of identity portability--if an identity owner doesn't like how her software is working, she should be able to exercise her self- sovereignty by taking the contents of her wallet to a new service. This implies that wallets need certain types of interoperability in the ecosystem, if they are to avoid vendor lock-in.</p> <p>All of these reasons--to clarify design scope, to provide uniform high security, and to guarantee interop--suggest that we need a formal RFC to document wallet architecture.</p>"},{"location":"concepts/0050-wallets/#tutorial","title":"Tutorial","text":"<p>(For a slide deck that gives a simplified overview of all the content in this RFC, please see http://bit.ly/2JUcIiT. The deck also includes a link to a recorded presentation, if you prefer something verbal and interactive.)</p>"},{"location":"concepts/0050-wallets/#what-is-an-identity-wallet","title":"What Is an Identity Wallet?","text":"<p>Informally, an identity wallet (preferably not just \"wallet\") is a digital container for data that's needed to control a self-sovereign identity. We borrow this metaphor from physical wallets:</p> <p></p> <p>Notice that we do not carry around in a physical wallet every document, key, card, photo, piece of currency, or credential that we possess. A wallet is a mechanism of convenient control, not an exhaustive repository. A wallet is portable. A wallet is worth safeguarding. Good wallets are organized so we can find things easily. A wallet has a physical location.</p> <p>What does suggest about identity wallets?</p>"},{"location":"concepts/0050-wallets/#types-of-sovereign-data","title":"Types of Sovereign Data","text":"<p>Before we give a definitive answer to that question, let's take a detour for a moment to consider digital data. Actors in a self-sovereign identity ecosystem may own or control many different types of data:</p> <ul> <li>encryption and signing keys</li> <li>payment keys</li> <li>link secrets</li> <li>PII about themselves or others</li> <li>credentials</li> <li>personal documents (e.g., last year's tax filing, journal, love letters)</li> <li>digital breadcrumbs (e.g., purchase history)</li> <li>photos and videos</li> <li>receipts</li> <li>health records</li> </ul> <p>...and much more. Different subsets of data may be worthy of different protection efforts:</p> <p></p> <p>The data can also show huge variety in its size and in its richness:</p> <p></p> <p>Because of the sensitivity difference, the size and richness difference, joint ownership, and different needs for access in different circumstances, we may store digital data in many different locations, with different backup regimes, different levels of security, and different cost profiles.</p>"},{"location":"concepts/0050-wallets/#whats-out-of-scope","title":"What's Out of Scope","text":""},{"location":"concepts/0050-wallets/#not-a-vault","title":"Not a Vault","text":"<p>This variety suggests that an identity wallet as a loose grab-bag of all our digital \"stuff\" will give us a poor design. We won't be able to make good tradeoffs that satisfy everybody; some will want rigorous, optimized search; others will want to minimize storage footprint; others will be concerned about maximizing security.</p> <p>We reserve the term vault to refer to the complex collection of all an identity owner's data:</p> <p></p> <p>Note that a vault can contain an identity wallet. A vault is an important construct, and we may want to formalize its interface. But that is not the subject of this spec.</p>"},{"location":"concepts/0050-wallets/#not-a-cryptocurrency-wallet","title":"Not A Cryptocurrency Wallet","text":"<p>The cryptocurrency community has popularized the term \"wallet\"--and because identity wallets share with crypto wallets both high-tech crypto and a need to store secrets, it is tempting to equate these two ../../concepts. However, an identity wallet can hold more than just cryptocurrency keys, just as a physical wallet can hold more than paper currency. Also, identity wallets may need to manage hundreds of millions of relationships (in the case of large organizations), whereas most crypto wallets manage a small number of keys:</p> <p></p>"},{"location":"concepts/0050-wallets/#not-a-gui","title":"Not a GUI","text":"<p>As used in this spec, an identity wallet is not a visible application, but rather a data store. Although user interfaces (superb ones!) can and should be layered on top of wallets, from indy's perspective the wallet itself consists of a container and its data; its friendly face is a separate construct. We may casually refer to an application as a \"wallet\", but what we really mean is that the application provides an interface to the underlying wallet.</p> <p>This is important because if a user changes which app manages his identity, he should be able to retain the wallet data itself. We are aiming for a better portability story than browsers offer (where if you change browsers, you may be able to export+import your bookmarks, but you have to rebuild all sessions and logins from scratch).</p>"},{"location":"concepts/0050-wallets/#personas","title":"Personas","text":"<p>Wallets have many stakeholders. However, three categories of wallet users are especially impactful on design decisions, so we define a persona for each.</p>"},{"location":"concepts/0050-wallets/#alice-individual-identity-owner","title":"Alice (individual identity owner)","text":"<p>Alice owns several devices, and she has an agent in the cloud. She has a thousand relationships--some with institutions, some with other people. She has a couple hundred credentials. She owns three different types of cryptocurrency. She doesn\u2019t issue or revoke credentials--she just uses them. She receives proofs from other entities (people and orgs). Her main tool for exercising a self-sovereign identity is an app on a mobile device.</p>"},{"location":"concepts/0050-wallets/#faber-intitutional-identity-owner","title":"Faber (intitutional identity owner)","text":"<p>Faber College has an on-prem data center as well as many resources and processes in public and private clouds. It has relationships with a million students, alumni, staff, former staff, applicants, business partners, suppliers, and so forth. Faber issues credentials and must manage their revocation. Faber may use crypto tokens to sell and buy credentials and proofs.</p>"},{"location":"concepts/0050-wallets/#the-org-book-trust-hub","title":"The Org Book (trust hub)","text":"<p>The Org Book holds credentials (business licenses, articles of incorporation, health permits, etc) issued by various government agencies, about millions of other business entities. It needs to index and search credentials quickly. Its data is public. It serves as a reference for many relying parties--thus its trust hub role.</p>"},{"location":"concepts/0050-wallets/#use-cases","title":"Use Cases","text":"<p>The specific uses cases for an identity wallet are too numerous to fully list, but we can summarize them as follows:</p> <p>As an identity owner (any of the personas above), I want to manage identity and its relationships in a way that guarantees security and privacy:</p> <ul> <li>Create an identity</li> <li>Setup protective policies</li> <li>Govern agents</li> <li>Connect and interact with others</li> <li>Recover and revoke</li> <li>Take an identity somewhere else</li> </ul>"},{"location":"concepts/0050-wallets/#managing-secrets","title":"Managing Secrets","text":"<p>Certain sensitive things require special handling. We would never expect to casually lay an ebola zaire sample on the counter in our bio lab; rather, it must never leave a special controlled isolation chamber.</p> <p></p> <p>Cybersecurity in wallets can be greatly enhanced if we take a similar tack with high-value secrets. We prefer to generate such secrets in their final resting place, possibly using a seed if we need determinism. We only use such secrets in their safe place, instead of passing them out to untrusted parties.</p> <p>TPMs, HSMs, and so forth follow these rules. Indy\u2019s current wallet interface does, too. You can\u2019t get private keys out.</p>"},{"location":"concepts/0050-wallets/#composition","title":"Composition","text":"<p>The foregoing discussions about cybersecurity, the desirability of design guidance and careful implementation, and wallet data that includes but is not limited to secrets motivates the following logical organization of identity wallets in Indy:</p> <p></p> <p>The world outside a wallet interfaces with the wallet through a public interface provided by indy-sdk, and implemented only once. This is the block labeled <code>encryption, query (wallet core)</code> in the diagram. The implementation in this layer guarantees proper encryption and secret-handling. It also provides some query ../../features. Records (items) to be stored in a wallet are referenced by a public handle if they are secrets. This public handle might be a public key in a key pair, for example. Records that are not secrets can be returned directly across the API boundary.</p> <p>Underneath, this common wallet code in libindy is supplemented with pluggable storage-- a technology that provides persistence and query ../../features. This pluggable storage could be a file system, an object store, an RDBMS, a NoSQL DB, a Graph DB, a key~value store, or almost anything similar. The pluggable storage is registered with the wallet layer by providing a series of C-callable functions (callbacks). The storage layer doesn't have to worry about encryption at all; by the time data reaches it, it is encrypted robustly, and the layer above the storage takes care of translating queries to and from encrypted form for external consumers of the wallet.</p>"},{"location":"concepts/0050-wallets/#tags-and-queries","title":"Tags and Queries","text":"<p>Searchability in wallets is facilitated with a tagging mechanism. Each item in a wallet can be associated with zero or more tags, where a tag is a <code>key=value</code> pair. Items can be searched based on the tags associated with them, and tag values can be strings or numbers. With a good inventory of tags in a wallet, searching can be robust and efficient--but there is no support for joins, subqueries, and other RDBMS-like constructs, as this would constrain the type of storage plugin that could be written.</p> <p>An example of the tags on a wallet item that is a credential might be:</p> <pre><code>  item-name = \"My Driver's License\"\n  date-issued = \"2018-05-23\"\n  issuer-did = \"ABC\"\n  schema = \"DEF\"\n</code></pre> <p>Tag names and tag values are both case-sensitive.</p> <p>Because tag values are normally encrypted, most tag values can only be tested using the <code>$eq</code>, <code>$neq</code> or <code>$in</code> operators (see Wallet Query Language, next). However, it is possible to force a tag to be stored in the wallet as plain text by naming it with a special prefix, <code>~</code> (tilde). This enables operators like <code>$gt</code>, <code>$lt</code>, and <code>$like</code>. Such tags lose their security guarantees but provide for richer queries; it is up to applications and their users to decide whether the tradeoff is appropriate.</p>"},{"location":"concepts/0050-wallets/#wallet-query-language","title":"Wallet Query Language","text":"<p>Wallets can be searched and filtered using a simple, JSON-based query language. We call this Wallet Query Language (WQL). WQL is designed to require no fancy parsing by storage plugins, and to be easy enough for developers to learn in just a few minutes. It is inspired by MongoDB's query syntax, and can be mapped to SQL, GraphQL, and other query languages supported by storage backends, with minimal effort.</p> <p>Formal definition of WQL language is the following:</p> <pre><code>query = {subquery}\nsubquery = {subquery, ..., subquery} // means subquery AND ... AND subquery\nsubquery = $or: [{subquery},..., {subquery}] // means subquery OR ... OR subquery\nsubquery = $not: {subquery} // means NOT (subquery)\nsubquery = \"tagName\": tagValue // means tagName == tagValue\nsubquery = \"tagName\": {$neq: tagValue} // means tagName != tagValue\nsubquery = \"tagName\": {$gt: tagValue} // means tagName &gt; tagValue\nsubquery = \"tagName\": {$gte: tagValue} // means tagName &gt;= tagValue\nsubquery = \"tagName\": {$lt: tagValue} // means tagName &lt; tagValue\nsubquery = \"tagName\": {$lte: tagValue} // means tagName &lt;= tagValue\nsubquery = \"tagName\": {$like: tagValue} // means tagName LIKE tagValue\nsubquery = \"tagName\": {$in: [tagValue, ..., tagValue]} // means tagName IN (tagValue, ..., tagValue)\n</code></pre>"},{"location":"concepts/0050-wallets/#sample-wql-query-1","title":"Sample WQL Query 1","text":"<p>Get all credentials where subject like \u2018Acme%\u2019 and issue_date &gt; last week. (Note here that the name of the issue date tag begins with a tilde, telling the wallet to store its value unencrypted, which makes the <code>$gt</code> operator possible.)</p> <pre><code>{\n  \"~subject\": {\"$like\": \"Acme%\"},\n  \"~issue_date\": {\"$gt\": 2018-06-01}\n}\n</code></pre>"},{"location":"concepts/0050-wallets/#sample-wql-query-2","title":"Sample WQL Query 2","text":"<p>Get all credentials about me where schema in (a, b, c) and issuer in (d, e, f).</p> <pre><code>{\n  \"schema_id\": {\"$in\": [\"a\", \"b\", \"c\"]},\n  \"issuer_id\": {\"$in\": [\"d\", \"e\", \"f\"]},\n  \"holder_role\": \"self\"\n}\n</code></pre>"},{"location":"concepts/0050-wallets/#encryption","title":"Encryption","text":"<p>Wallets need very robust encryption. However, they must also be searchable, and the encryption must be equally strong regardless of which storage technology is used. We want to be able to hide data patterns in the encrypted data, such that an attacker cannot see common prefixes on keys, or common fragments of data in encrypted values. And we want to rotate the key that protects a wallet without having to re-encrypt all its content. This suggests that a trivial encryption scheme, where we pick a symmetric key and encrypt everything with it, is not adequate.</p> <p>Instead, wallet encryption takes the following approach:</p> <ul> <li>For attributes of items that are searchable  (<code>type</code>, <code>id</code>, <code>tag_name</code>,   <code>tag_value</code>):</li> <li>The same input produces the same output.</li> <li>Every attribute \"column\" has its own key. That is, there's an encryption key for     all <code>type</code> attributes, a different encryption key for all <code>id</code> attributes,     and so forth.</li> <li>Initialization vector is HMAC-256 value of the field being encrypted.</li> <li> <p>Two more keys are needed for HMAC--one for <code>type</code> and <code>id</code> and one for     <code>tag_name</code> and <code>tag_value</code>.</p> </li> <li> <p>For item values:</p> </li> <li>A new value key is generated for each item value.</li> <li>Value key is encrypted using key for that field. (Value key also has a \"column\"     key that contributes to its encryption.)</li> <li> <p>Initialization vector is generated every time for both encryptions.</p> </li> <li> <p>For wallet keys:</p> </li> <li>Encrypted with master key with random initialization vector.</li> </ul> <p>The 7 \"column\" keys are concatenated and encrypted with a wallet master key,  then saved into the metadata of the wallet. This allows the master key to be rotated  without re-encrypting all the items in the wallet.</p> <p>Today, all encryption is done using ChaCha20-Poly1305, with HMAC-SHA256. This is a solid, secure encryption algorithm, well tested and widely supported. However, we anticipate the desire to use different cipher suites, so in the future we will make the cipher suite pluggable.</p> <p>The way the individual fields are encrypted is shown in the following diagram. Here, data is shown as if stored in a relational database with tables. Wallet storage may or may not use tables, but regardless of how the storage distributes and divides the data, the logical relationships and the encryption shown in the diagram apply.</p> <p></p>"},{"location":"concepts/0050-wallets/#pluggable-storage","title":"Pluggable Storage","text":"<p>Although Indy infrastructure will provide only one wallet implementation it will allow to plug different storages for covering of different use cases. Default storage shipped with libindy will be sqlite based and well suited for agents running on edge devices. The API endpoint <code>register_wallet_storage</code> will allow Indy Developers to register a custom storage implementation as a set of handlers.</p> <p>A storage implementation does not need any special security ../../features. It stores data that was already encrypted by libindy (or data that needs no encryption/protection, in the case of unencrypted tag values). It searches data in whatever form it is persisted, without any translation. It returns data as persisted, and lets the common wallet infrastructure in libindy decrypt it before return it to the user.</p>"},{"location":"concepts/0050-wallets/#secure-enclaves","title":"Secure Enclaves","text":"<p>Secure Enclaves are purposely designed to manage, generate, and securely store cryptographic material. Enclaves can be either specially designed hardware (e.g. HSM, TPM) or trusted execution environments (TEE) that isolate code and data from operating systems (e.g. Intel SGX, AMD SVE, ARM Trustzone). Enclaves can replace common cryptographic operations that wallets perform (e.g. encryption, signing). Some secrets cannot be stored in wallets like the key that encrypts the wallet itself or keys that are backed up. These cannot be stored in enclaves as keys stored in enclaves cannot be extracted. Enclaves can still protect these secrets via a mechanism called wrapping.</p>"},{"location":"concepts/0050-wallets/#enclave-wrapping","title":"Enclave Wrapping","text":"<p>Suppose I have a secret, X, that needs maximum protection. However, I can\u2019t store X in my secure enclave because I need to use it for operations that the enclave can\u2019t do for me; I need direct access. So how to I extend enclave protections to encompass my secret?</p> <p>I ask the secure enclave to generate a key, Y, that will be used to protect X. Y is called a wrapping key. I give X to the secure enclave and ask that it be encrypted with wrapping key Y. The enclave returns X\u2019 (ciphertext of X, now called a wrapped secret), which I can leave on disk with confidence; it cannot be decrypted to X without involving the secure enclave. Later, when I want to decrypt, I give wrapped secret X\u2019 to the secure enclave and ask it to give me back X by decrypting with wrapping key Y.</p> <p></p> <p>You could ask whether this really increases security. If you can get into the enclave, you can wrap or unwrap at will.</p> <p>The answer is that an unwrapped secret is protected by only one thing--whatever ACLs exist on the filesystem or storage where it resides. A wrapped secret is protected by two things--the ACLs and the enclave. OS access may breach either one, but pulling a hard drive out of a device will not breach the enclave.</p>"},{"location":"concepts/0050-wallets/#paper-wallets","title":"Paper Wallets","text":"<p>It is possible to persist wallet data to physical paper (or, for that matter, to etched metal or other physical media) instead of a digital container. Such data has attractive storage properties (e.g., may survive natural disasters, power outages, and other challenges that would destroy digital data). Of course, by leaving the digital realm, the data loses its accessibility over standard APIs.</p> <p>We anticipate that paper wallets will play a role in backup and recovery, and possibly in enabling SSI usage by populations that lack easy access to smartphones or the internet. Our wallet design should be friendly to such usage, but physical persistence of data is beyond the scope of Indy's plugin storage model and thus not explored further in this RFC.</p>"},{"location":"concepts/0050-wallets/#backup-and-recovery","title":"Backup and Recovery","text":"<p>Wallets need a backup and recovery feature, and also a way to export data and import it. Indy's wallet API includes an export function and an import function that may be helpful in such use cases. Today, the export is unfiltered--all data is exported. The import is also all-or-nothing and must be to an empty wallet; it is not possible to import selectively or to update existing records during import.</p> <p>A future version of import and export may add filtering, overwrite, and progress callbacks. It may also allow supporting or auxiliary data (other than what the wallet directly persists) to be associated with the export/import payload.</p> <p>For technical details on how export and import work, please see the internal design docs.</p>"},{"location":"concepts/0050-wallets/#reference","title":"Reference","text":"<ul> <li>Wallet Design</li> </ul>"},{"location":"concepts/0050-wallets/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>We could implement wallets purely as built already in the cryptocurrency world. This would give us great security (except for crypto wallets that are cloud based), and perhaps moderately good usability.</p> <p>However, it would also mean we could not store credentials in wallets. Indy would then need an alternate mechanism to scan some sort of container when trying to satisfy a proof request. And it would mean that a person's identity would not be portable via a single container; rather, if you wanted to take your identity to a new place, you'd have to copy all crypto keys in your crypto wallet, plus copy all your credentials using some other mechanism. It would also fragment the places where you could maintain an audit trail of your SSI activities.</p>"},{"location":"concepts/0050-wallets/#prior-art","title":"Prior art","text":"<p>See comment about crypto wallets, above.</p>"},{"location":"concepts/0050-wallets/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What is the relationship between a threading model in pluggable storage and   the threading model of wallets? Is it always legal to be reading and writing   wallets from multiple threads at the same time?</li> </ul>"},{"location":"concepts/0050-wallets/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy SDK Most agents that implement wallets get their wallet support from Indy SDK. These are not listed separately."},{"location":"concepts/0051-dkms/","title":"Aries RFC 0051: Decentralized Key Management","text":"<ul> <li>Authors: Drummond Reed et al.</li> <li>Status: RETIRED</li> <li>Since: 2024-04-03</li> <li>Status Note: Covered elsewhere and not specific to Aries.</li> <li>Start Date: 2018-09-01 (approx, backdated)</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0051-dkms/#summary","title":"Summary","text":"<p>Describes a general approach to key management in a decentralized, self-sovereign world. We expect Aries to embody the principles described here; this doc is likely to color numerous protocols  and ecosystem ../../features.</p>"},{"location":"concepts/0051-dkms/#motivation","title":"Motivation","text":"<p>A decentralized key management system (DKMS) is an approach to cryptographic key management where there is no central authority. DKMS leverages the security, immutability, availability, and resiliency properties of distributed ledgers to provide highly scalable key distribution, verification, and recovery.</p> <p>Key management is vital to exercising sovereignty in a digital ecosystem, and decentralization is a vital principle as well. Therefore, we need a coherent and comprehensive statement of philosophy and architecture on this vital nexus of topics.</p>"},{"location":"concepts/0051-dkms/#tutorial","title":"Tutorial","text":"<p>The bulk of the content for this RFC is located in the official architecture documentation -- dkms-v4.md; readers are encouraged to go there to learn more. Here we present only the highest-level background context, for those who may be unaware of some basics.</p>"},{"location":"concepts/0051-dkms/#background-concepts","title":"Background Concepts","text":""},{"location":"concepts/0051-dkms/#key-types","title":"Key Types","text":"<p>DKMS uses the following key types: 1. Master keys: Keys that are not cryptographically protected. They are distributed manually or initially installed and protected by procedural controls and physical or electronic isolation. 2. Key encrypting keys: Symmetric or public keys used for key transport or storage of other keys. 3. Data keys: Used to provide cryptographic operations on user data (e.g., encryption, authentication).</p> <p>The keys at one level are used to protect items at a lower level. Consequently, special measures are used to protect master keys, including severely limiting access and use, hardware protection, and providing access to the key only under shared control.</p>"},{"location":"concepts/0051-dkms/#key-loss","title":"Key Loss","text":"<p>Key loss means the owner no longer controls the key and it can assume there is no further risk of compromise. For example devices unable to function due to water, electricity, breaking, fire, hardware failure, acts of God, etc.</p>"},{"location":"concepts/0051-dkms/#compromise","title":"Compromise","text":"<p>Key compromise means that private keys and/or master keys have become or can become known either passively or actively.</p>"},{"location":"concepts/0051-dkms/#recovery","title":"Recovery","text":"<p>In decentralized identity management, recovery is important since identity owners have no \u201chigher authority\u201d to turn to for recovery. 1. Offline recovery uses physical media or removable digital media to store recovery keys. 2. Social recovery employs entities trusted by the identity owner called \"trustees\" who store recovery data on an identity owners behalf\u2014typically in the trustees own agent(s).</p> <p>These methods are not exclusive and should be combined with key rotation and revocation for proper security.</p>"},{"location":"concepts/0051-dkms/#reference","title":"Reference","text":"<ol> <li>Design and architecture</li> <li>Public Registry for Agent Authorization Policy. An identity owner creates a policy on the ledger that defines its agents and their authorizations.    Agents while acting on the behalf of the identity owner need to prove that they are authorised. More details</li> <li>Shamir Secret</li> <li>Trustee Protocols</li> </ol>"},{"location":"concepts/0051-dkms/#drawbacks-rationale-and-alternatives-prior-art-unresolved-questions","title":"Drawbacks, Rationale and alternatives, Prior art, Unresolved Questions","text":"<p>The material that's normally in these sections of a RFC appears in the official architecture documentation -- dkms-v4.md.</p>"},{"location":"concepts/0051-dkms/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy SDK partial: backup Connect.Me partial: backup, sync to cloud"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/","title":"Agent Authz policy (changes for ledger)","text":"<p>Objective: Prove agents are authorized to provide proof of claims and authorize and de-authorize other agents</p>"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#assumptions","title":"Assumptions","text":"<ol> <li>The ledger maintains a global accumulator that holds commitments sent by the agents.</li> <li>The global accumulator is maintained by the each node so every node knows the accumulator private key</li> <li>Agent auth policy txns are stored at the identity ledger.</li> <li>Each auth policy is uniquely identified by a policy address <code>I</code>.</li> <li>One agent can belong to several authz policies, thus several different <code>I</code>'s.</li> <li>An agent can have several authorizations. Following are the list of authorizations:</li> <li>PROVE</li> <li>PROVE_GRANT</li> <li>PROVE_REVOKE</li> <li>ADMIN</li> </ol>"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#transactions","title":"Transactions","text":""},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#agent_authz","title":"AGENT_AUTHZ","text":"<p>An authz policy is created/updated by an <code>AGENT_AUTHZ</code> transaction. A transaction creating a new authz policy: <pre><code>{\n    identifier: &lt;transaction sender's verification key&gt;\n    signature: &lt;signature created by the sender's public key&gt;,\n    req_id: &lt;a nonce&gt;,\n    operation: {\n        type: AGENT_AUTHZ,\n        address: &lt;policy address, I&gt;,\n        verkey: &lt;optional, verification key of the agent&gt;,\n        authorization: &lt;optional, a bitset&gt;,\n        commitment: &lt;optional&gt;\n    }\n} \n</code></pre> address: The policy address, this is a unique identifier of an authz policy. Is a large number (size/range TBD). If the ledger has never seen the provided policy address, it considers the transaction a creation of a new authz policy else it is considered an update of an existing policy identifier by the address. verkey: An ed25519 verkey of the agent to which the <code>authorization</code> corresponds. This is optional when a new policy is being created as <code>identifier</code> is sufficient. This verkey should be kept different from any DID verkey to avoid correlation.  authorization: A bitset indicating which authorizations are being given to the agent, it is ignored when creating a new policy (the ledger does not know <code>I</code>). The various bits indicate different authorizations:</p> <pre><code>0 None (revoked)\n1 ADMIN (all)\n2 PROVE\n3 PROVE_GRANT\n4 PROVE_REVOKE\n5 \"Reserved for future\"\n6 \"Reserved for future\"\n7  ... \n   ... \n</code></pre> <p>While creating a new policy, this field's value is ignored and the creator agent has all authorizations. For any subsequent policy transactions, the ledger checks if the sender (author to be precise, since anyone can send a transaction once a signature has been done) of transaction has the authorization to make the transaction, eg. The author of txn has <code>PROVE_GRANT</code> if it is giving a <code>PROVE</code> authorization to another agent. Future Work: When we support <code>m-of-n</code> authorization, <code>verkey</code> would be a map stating the policy and the verkeys</p> <p>commitment: This is a number (size/range TBD) given by the agent when it is being given a <code>PROVE</code> authorization. Thus this field is only needed when a policy is being created or an agent is being given the <code>PROVE</code> authorization. The ledger upon receiving this commitment checks if the commitment is prime and if it is then it updates the global accumulator with this commitment. Efficient primality testing algorithms like BPSW or ECPP can be used but the exact algorithm is yet to be decided.  If the commitment is not prime (in case of creation or update of policy address) then the transaction is rejected. The ledger rejects the transaction if it has already seen the commitment as part of another transaction.  In case of creation of new policy or an agent being given <code>PROVE</code> authorization, the ledger responds with the accumulator value after the update with this commitment.</p>"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#get_agent_authz","title":"GET_AGENT_AUTHZ","text":"<p>This query is sent by any client to check what the authz policy of any address <code>I</code> is <pre><code>{\n    ...,\n    operation: {\n        type: GET_AGENT_AUTHZ,\n        address: &lt;policy address, I&gt;,\n    }\n} \n</code></pre></p> <p>The ledger replies with all the agents, their associated authorizations and the commitments of the address <code>I</code>.</p>"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#get_agent_authz_accum","title":"GET_AGENT_AUTHZ_ACCUM","text":"<p>This query is sent by anyone to get the value of the accumulator.  <pre><code>{\n    ...,\n    operation: {\n        type: GET_AGENT_AUTHZ_ACCUM,\n    accum_id: &lt;id of either the provisioned agents accumulator or the revoked agent accumulator&gt;\n    }\n} \n</code></pre> The ledger returns the global accumulator with the id. Both accumulators are add only; the client checks that commitment is present in one accumulator AND not present in other accumulator.</p>"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#data-structures","title":"Data structures","text":""},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#ledger","title":"Ledger","text":"<p>Each authz transaction goes in the identity ledger.</p>"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#state-trie","title":"State trie.","text":"<p>The state stores: 1. Accumulator: The accumulator is stored in the trie at name <code>&lt;special byte denoting an authz prove accumulator&gt;</code> with value as the value of accumulator.  2. Policies: The state stores one name for each policy, the name is <code>&lt;special byte denoting an authz policy&gt;:&lt;policy address&gt;</code>, the value at this name is a hash. The hash is determined deterministically serializing (RLP encoding from ethereum, we already use this) this data structure: </p> <pre><code>[\n  [&lt;agent verkey1&gt;, &lt;authorization bitset&gt;, [commitment&gt;]],\n  [&lt;agent verkey2&gt;, &lt;authorization bitset&gt;, [commitment&gt;]],\n  [&lt;agent verkey3&gt;, &lt;authorization bitset&gt;, [commitment&gt;]],\n]\n</code></pre> <p>The hash of above can then be used to lookup (it is not, more on this later) the exact authorization policy in a separate name-value store. This is done to keep the database backing the state (trie) smaller.</p>"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#caches","title":"Caches","text":"<p>There is an agent_authz cache used for optimisations are: The cache is a name-value store (leveldb) and offers a constant lookup time for lookup by name. 1. Policy values: The authorization of each agent per policy. The values for the keys are rlp encoding of the list of at most 2 items, <code>authorization bitset</code> with each bit respresenting a different auth, <code>commitment</code> is optional and relevant only when agent has the <code>PROVE</code> authorization.</p> <p><pre><code>{\n  &lt;policy address 1&gt;&lt;delimiter&gt;&lt;agent verkey 1&gt;: &lt;authorization bitset&gt;:&lt;commitment&gt;,\n  &lt;policy address 1&gt;&lt;delimiter&gt;&lt;agent verkey 2&gt;: &lt;authorization bitset&gt;:&lt;commitment&gt;,\n  &lt;policy address 1&gt;&lt;delimiter&gt;&lt;agent verkey 3&gt;: &lt;authorization bitset&gt;:&lt;commitment&gt;,\n  &lt;policy address 2&gt;&lt;delimiter&gt;&lt;agent verkey 1&gt;: &lt;authorization bitset&gt;:&lt;commitment&gt;,\n  &lt;policy address 2&gt;&lt;delimiter&gt;&lt;agent verkey 2&gt;: &lt;authorization bitset&gt;:&lt;commitment&gt;,\n  ....\n}\n</code></pre> These names are used by the nodes during processing any transaction.</p> <ol> <li>Accumulator value: Value of each accumulator is stored corresponding to the special byte indicating the global accumulator. <pre><code>{\n  &lt;special_byte&gt;: &lt;accumulator value&gt;,\n}\n</code></pre></li> </ol> <p>During processing of any write transaction, the node updates the ledger, state and caches after the txn is successful but for querying (client as well as its own like validation, etc) it only uses caches since caches are more efficient than state trie. The state trie is only used for state proofs.  </p> <ol> <li>TODO: Maintaining a set of commitments: Each node maintains a set of see commitments and does not allow duplicate commitments. Its kept in key value store with constant lookup time for commitment lookup.</li> </ol>"},{"location":"concepts/0051-dkms/agent-authz-policy-ledger-interactions/#code-organisation","title":"Code organisation.","text":"<p>These changes would be implemented as a separate plugin. The plugin will not introduce new ledger or state but will introduce the cache described above. The plugin will introduce a new request handler which will subclass the <code>DomainRequestHandler</code>. The plugin's new request handler will introduce 1 <code>write_type</code> and 2 <code>query_types</code> and methods to handle those.</p>"},{"location":"concepts/0051-dkms/dkms-v4/","title":"DKMS (Decentralized Key Management System) Design and Architecture V4","text":"<p>2019-03-29</p> <p>Authors: Drummond Reed, Jason Law, Daniel Hardman, Mike Lodder</p> <p>Contributors: Christopher Allen, Devin Fisher, Nathan George, Lovesh Harchandani, Dmitry Khovratovich, Corin Kochenower, Brent Zundel, Nathan George</p> <p>Advisors: Stephen Wilson</p> <p>STATUS: This design and architecture for a decentralized key management system (DKMS) has been developed by Evernym Inc. under a contract with the U.S. Department of Homeland Security Science &amp; Technology Directorate. This fourth draft is being released on 29 Mar 2019 to begin an open public review and comment process in preparation for DKMS to be submitted to a standards development organization such as OASIS for formal standardization.</p> <p>Acknowledgements: </p> <ul> <li> <p>Work on DKMS Design and Architecture has been funded in part by a Small Business Innovation Research (SBIR) grant from the U.S. Department of Homeland Security Science and Technology Directorate. The content of this specification does not necessarily reflect the position or the policy of the U.S. Government and no official endorsement should be inferred.</p> </li> <li> <p>The Internet Security Research Lab at Brigham Young University gathered feedback on decentralized key management and recovery from user surveys and UX usability studies. They also provided feedback on earlier drafts of this document. Contributions were made by Kent Seamons (faculty), Daniel Zappala (faculty), Ken Reese, Brad Spendlove, Trevor Smith, and Luke Dickinson.</p> </li> </ul> <p>Table of Contents</p> <ol> <li>Introduction</li> <li>Design Goals and Requirements</li> <li>High Level Architecture</li> <li>Ledger Architecture</li> <li>Key Management Architecture</li> <li>Recovery Methods</li> <li>Recovery From Key Loss</li> <li>Recovery From Key Compromise</li> <li>DKMS Protocol</li> <li>Protocol Flows</li> <li>Open Issues and Future Work</li> <li>Future Standardization</li> </ol>"},{"location":"concepts/0051-dkms/dkms-v4/#1-introduction","title":"1. Introduction","text":""},{"location":"concepts/0051-dkms/dkms-v4/#11-overview","title":"1.1. Overview","text":"<p>DKMS (Decentralized Key Management System) is a new approach to cryptographic key management intended for use with blockchain and distributed ledger technologies (DLTs) where there are no centralized authorities. DKMS inverts a core assumption of conventional PKI (public key infrastructure) architecture, namely that public key certificates will be issued by centralized or federated certificate authorities (CAs). With DKMS, the initial \"root of trust\" for all participants is any distributed ledger or decentralized protocol that supports a new form of root identity record called a DID (decentralized identifier).</p> <p>A DID is a globally unique identifier that is generated cryptographically and self-registered with the identity owner\u2019s choice of a DID-compatible distributed ledger or decentralized protocol so no central registration authority is required. Each DID points to a DID document\u2014a JSON or JSON-LD object containing the associated public verification key(s) and addresses of services such as off-ledger agent(s) supporting secure peer-to-peer interactions with the identity owner. For more on DIDs, see the DID Primer. For more on peer-to-peer interactions, see the DID Communication explainer.</p> <p>Since no third party is involved in the initial registration of a DID and DID document, it begins as \"trustless\". From this starting point, trust between DID-identified peers can be built up through the exchange of verifiable credentials\u2014credentials about identity attributes that include cryptographic proof of authenticity of authorship. These proofs can be verified by reference to the issuer\u2019s DID and DID document. For more about verifiable credentials, see the  Verifiable Credentials Primer. </p> <p>This decentralized web of trust model leverages the security, immutability, availability, and resiliency properties of distributed ledgers to provide highly scalable key distribution, verification, and recovery. This inversion of conventional public key infrastructure (PKI) into decentralized PKI (DPKI) removes centralized gatekeepers, making the benefits of PKI accessible to everyone. However this lack of centralized authorities for DKMS shifts the majority of responsibility for key management directly to participating identity owners. This demands the decentralized equivalent of the centralized cryptographic key management systems (CKMS) that are the current best practice in most enterprises. The purpose of this document is to specify a design and architecture that fulfills this market need.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#12-market-need","title":"1.2. Market Need","text":"<p>X.509 public key certificates, as used in the TLS/SSL protocol for HTTPS secure Web browsing, have become the most widely adopted PKI in the world. However this system requires that all certificates be obtained from a relatively small list of trusted authorities\u2014and that any changes to these certificates also be approved by someone in this chain of trust.</p> <p>This creates political and structural barriers to establishing and updating authoritative data. This friction is great enough that only a small fraction of Internet users are currently in position to use public/private key cryptography for their own identity, security, privacy, and trust management. This inability for people and organizations to interact privately as independent, verifiable peers on their own terms has many consequences:</p> <ol> <li> <p>It forces individuals and smaller organizations to rely on large federated identity providers and certificate authorities who are in a position to dictate security, privacy and business policies.</p> </li> <li> <p>It restricts the number of ways in which peers can discover each other and build new trust relationships\u2014which in turn limits the health and resiliency of the digital economy.</p> </li> <li> <p>It discourages the use of modern cryptography for increased security and privacy, weakening our cybersecurity infrastructure.</p> </li> </ol> <p>Decentralized technologies such as distributed ledgers and edge protocols can remove these barriers and make it much easier to share and verify public keys. This enables each entity to manage its own authoritative key material without requiring approval from other parties. Furthermore, those changes can be seen immediately by the entity\u2019s peers without requiring them to change their software or \"certificate store\".</p> <p>Maturing DLTs and protocols will bring DPKI into the mainstream\u2014a combination of DIDs for decentralized identification and DKMS for decentralized key management. DPKI will provide a simple, secure, way to generate strong public/private key pairs, register them for easy discovery and verification, and rotate and retire them as needed to maintain strong security and privacy.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#13-benefits","title":"1.3. Benefits","text":"<p>DKMS architecture and DPKI provides the following major benefits:</p> <ol> <li> <p>No single point of failure. With DKMS, there is no central CA or other registration authority whose failure can jeopardize large swaths of users.</p> </li> <li> <p>Interoperability. DKMS will enable any two identity owners and their applications to perform key exchange and create encrypted P2P connections without reliance on proprietary software, service providers, or federations.</p> </li> <li> <p>Portability. DKMS will enable identity owners to avoid being locked into any specific implementation of a DKMS-compatible wallet, agent, or agency. Identity owners should\u2014with the appropriate security safeguards\u2014be able to use the DKMS protocol itself to move the contents of their wallet (though not necessarily the actual cryptographic keys) between compliant DKMS implementations.</p> </li> <li> <p>Resilient trust infrastructure. DKMS incorporates all the advantages of distributed ledger technology for decentralized access to cryptographically verifiable data. It then adds on top of it a distributed web of trust where any peer can exchange keys, form connections, and issue/accept verifiable credentials from any other peer.</p> </li> <li> <p>Key recovery. Rather than app-specific or domain-specific key recovery solutions, DKMS can build robust key recovery directly into the infrastructure, including agent-automated encrypted backup, DKMS key escrow services, and social recovery of keys, for example by backing up or sharding keys across trusted DKMS connections and agents.</p> </li> </ol>"},{"location":"concepts/0051-dkms/dkms-v4/#2-design-goals-and-requirements","title":"2. Design Goals and Requirements","text":""},{"location":"concepts/0051-dkms/dkms-v4/#21-conventional-ckms-requirements-nist-800-130-analysis","title":"2.1. Conventional CKMS Requirements: NIST 800-130 Analysis","text":"<p>As a general rule, DKMS requirements are a derivation of CKMS requirements, adjusted for the lack of centralized authorities or systems for key management operations. Evernym\u2019s DKMS team and subcontractors performed an extensive analysis of the applicability of conventional CKMS requirements to DKMS using  NIST Special Publication 800-130: A Framework for Designing Cryptographic Key Management Systems. For a summary of the results, see:</p> <ul> <li> <p>Evernym HSHQDC-17-C-00018 - DKMS Requirements Spreadsheet Based On NIST 800-130</p> </li> <li> <p>Evernym HSHQDC-17-C-00018 - DKMS Requirements Text Based on NIST 800-130</p> </li> <li> <p>Evernym HSHQDC-17-C-00018 - DKMS Requirements Report - 30 June 2017</p> </li> </ul> <p>The most relevant special requirements are highlighted in the following sections.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#22-decentralization","title":"2.2. Decentralization","text":"<p>The DKMS design MUST NOT assume any reliance on a centralized authority for the system as a whole. The DKMS design MUST assume all participants are independent actors identified with DIDs conformant with the Decentralized Identifiers (DID) specification but otherwise acting in their own decentralized security and privacy domains. The DKMS design MUST support options for decentralized key recovery.</p> <p>What distinguishes DKMS from conventional CKMS is the fact that the entire design assumes decentralization: outside of the \"meta-policies\" established by the DKMS specification itself, there is no central authority to dictate policies that apply to all users. So global DKMS infrastructure must achieve interoperability organically based on a shared set of specifications, just like the Internet.</p> <p>Note that the need to maintain decentralization is most acute when it comes to key recovery: the advantages of decentralization are nullified if key recovery mechanisms reintroduce centralization.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#23-privacy-and-pseudonymity","title":"2.3. Privacy and Pseudonymity","text":"<p>The DKMS design MUST NOT introduce new means of correlating participants by virtue of using the DKMS standards. The DKMS design SHOULD increase privacy and security by enabling the use of pseudonyms, selective disclosure, and encrypted private channels of communication.</p> <p>Conventional PKI and CKMS rarely have anti-correlation as a primary requirement. DKMS should ensure that participants will have more, not less, control over their privacy as well as their security. This facet of DKMS requires an vigilant application of all the principles of Privacy by Design.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#24-usability","title":"2.4. Usability","text":"<p>DIDs and DKMS components intended to be used by individual identity owners MUST be safely usable without any special training or knowledge of cryptography or key management.</p> <p>In many ways this follows from decentralization: in a DKMS, there is no central authority to teach everyone how to use it or require specific user training. It must be automated and intuitive to a very high degree, similar to the usability achieved by modern encrypted OTT messaging products like Whatsapp, iMessage, and Signal.</p> <p>According to the BYU Internet Security Research Lab, this level of usability is a necessary property of any successfully deployed system. \"We spent the 1990s building and deploying security that wasn\u2019t really needed, and now that it\u2019s actually desirable, we\u2019re finding that nobody can use it\" [Guttman and Grigg, IEEE Security and Privacy, 2005]. The DKMS needs to be able to support a broad spectrum of applications, with both manual and automatic key management, in order to satisfy the numerous security and usability requirements of those applications.</p> <p>Again, this requirement is particularly acute when it comes to key recovery. Because there is no central authority to fall back on, the key recovery options must not only be anticipated and implemented in advance, but they must be easy enough for a non-technical user to employ while still preventing exploitation by an attacker.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#25-automation","title":"2.5. Automation","text":"<p>To maximize usability, the DKMS design SHOULD automate as many key management functions as possible while still meeting security and privacy requirements.</p> <p>This design principle follows directly from the usability requirement, and also from the inherent complexity of maintaining the security, privacy, and integrity of cryptographic primitives combined with the general lack of knowledge of most Internet users about any of these subjects.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#26-key-derivation","title":"2.6. Key Derivation","text":"<p>In DKMS design it is NOT RECOMMENDED to copy private keys directly between wallets, even over encrypted connections. It is RECOMMENDED to use derived keys whenever possible to enable agent-specific and device-specific revocation.</p> <p>This design principle is based on security best practices, and also the growing industry experience with the BIP32 standard for management of the large numbers of private keys required by Bitcoin and other cryptocurrencies. However DKMS architecture can also accomplish this goal in other ways, such as using key signing keys (\"key endorsement\").</p>"},{"location":"concepts/0051-dkms/dkms-v4/#27-delegation-and-guardianship","title":"2.7. Delegation and Guardianship","text":"<p>The DKMS design MUST enable key management to be delegated by one identity owner to another, including the DID concept of delegation.</p> <p>Although DKMS infrastructure enables \"self-sovereign identity\"\u2014digital identifiers and identity wallets that are completely under the control of an identity owner and cannot be taken away by a third-party\u2014not all individuals have the ability to be self-sovereign. They may be operating at a physical, economic, or network disadvantage that requires another identity owner (individual or org) to act as an agent on their behalf. </p> <p>Other identity owners may simply prefer to have others manage their keys for purposes of convenience, efficiency, or safety. In either case, this means DKMS architecture needs to incorporate the concept of delegation as defined in the Decentralized Identifiers (DID) specification and in the Sovrin Glossary.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#28-portability","title":"2.8. Portability","text":"<p>The DKMS design MUST enable an identity owner\u2019s DKMS-compliant key management capabilities to be portable across multiple DKMS-compliant devices, applications, and service providers.</p> <p>While the NIST 800-130 specifications have an entire section on interoperability, those requirements are focused primarily on interoperability of CKMS components with each other and with external CKMS systems. They do not encompass the need for a decentralized identity owner to be able to port their key management capabilities from one CKMS device, application, or service provider to another.</p> <p>This is the DID and DKMS equivalent of telephone number portability, and it is critical not only for the general acceptance of DKMS infrastructure, but to support the ability of DID owners to act with full autonomy and independence. As with telephone number portability, it also helps ensure a robust and competitive marketplace for DKMS-compliant products and services. (NOTE:  Note that \"portability\" here refers to the ability of a DID owner to use the same DID across multiple devices, software applications, service providers, etc. It does not mean that a particular DID that uses a particular DID method is portable across different distributed ledgers. DID methods are ledger-specific.)</p>"},{"location":"concepts/0051-dkms/dkms-v4/#29-extensibility","title":"2.9. Extensibility","text":"<p>The DKMS design SHOULD be capable of being extended to support new cryptographic algorithms, keys, data structures, and modules, as well as new distributed ledger technologies and other security and privacy innovations.</p> <p>Section 7 of NIST 800-130 includes several requirements for conventional CKMS to be able to transition to newer and stronger cryptographic algorithms, but it does not go as far as is required for DKMS infrastructure, which must be capable of adapting to evolving Internet security and privacy infrastructure as well as rapid advances in distributed ledger technologies.</p> <p>It is worth noting that the DKMS specifications will not themselves include a trust framework (also called a governance framework; rather, one or more trust frameworks can be layered over them to formalize certain types of extensions. This provides a flexible and adaptable method of extending DKMS to meet the needs of specific communities.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#210-simplicity","title":"2.10. Simplicity","text":"<p>Given the inherent complexity of key management, the DKMS design SHOULD aim to be as simple and interoperable as possible by pushing complexity to the edges and to extensions.</p> <p>Simplicity and elegance of design are common traits of most successful decentralized systems, starting with the packet-based design of the Internet itself. The less complex a system is, the easier it is to debug, evaluate, and adapt to future changes. Especially in light of the highly comprehensive scope of NIST 800-130, this requirement highlights a core difference with conventional CKMS design: the DKMS specification should NOT try to do everything, e.g., enumerate every possible type of key or role of user or application, but let those be defined locally in a way that is interoperable with the rest of the system.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#211-open-system-and-open-standard","title":"2.11. Open System and Open Standard","text":"<p>The DKMS design MUST be an open system based on open, royalty-free standards.</p> <p>While many CKMS systems are deployed using proprietary technology, the baseline DKMS infrastructure must, like the Internet itself, be an open, royalty-free system. It may, of course, have many proprietary extensions and solutions built on top of it.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#3-high-level-architecture","title":"3. High-Level Architecture","text":"<p>At a high level, DKMS architecture consists of three logical layers:</p> <ol> <li> <p>The DID layer is the foundational layer consisting of DIDs registered and resolved via distributed ledgers and/or decentralized protocols.</p> </li> <li> <p>The cloud layer consists of server-side agents and wallets that provide a means of communicating and mediating between the DID layer and the edge layer. This layer enables encrypted peer-to-peer communications for exchange and verification of DIDs, public keys, and verifiable credentials.</p> </li> <li> <p>The edge layer consists of the local devices, agents, and wallets used directly by identity owners to generate and store most private keys and perform most key management operations.</p> </li> </ol> <p>Figure 1 is an overview of this three-layer architecture:</p> <p></p> <p>Figure 1: The high-level three-layer DKMS architecture</p> <p>Figure 2 is a more detailed picture of the relationship between the different types of agents and wallets in DKMS architecture.</p> <p></p> <p>Figure 2: Diagram of the types of agents and connections in DKMS architecture.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#31-the-did-decentralized-identifier-layer","title":"3.1. The DID (Decentralized Identifier) Layer","text":"<p>The foundation for DKMS is laid by the DID specification. DIDs can work with any decentralized source of truth such as a distributed ledger or edge protocol for which a DID method\u2014a way of creating, reading, updating, and revoking a DID\u2014has been specified. As globally unique identifiers, DIDs are patterned after URNs (Uniform Resource Names): colon-delimited strings consisting of a scheme name followed by a DID method name followed by a method-specific identifier. Here is an example DID that uses the Sovrin DID method:</p> <p>did:sov:21tDAKCERh95uGgKbJNHYp</p> <p>Each DID method specification defines:</p> <ol> <li> <p>The specific source of truth against which the DID method operates;</p> </li> <li> <p>The format of the method-specific identifier;</p> </li> <li> <p>The CRUD operations (create, read, update, delete) for DIDs and DID documents on that ledger.</p> </li> </ol> <p>DID resolver code can then be written to perform these CRUD operations on the target system with respect to any DID conforming to that DID method specification. Note that some distributed ledger technologies (DLTs) and distributed networks are better suited to DIDs than others. The DID specification itself is neutral with regard to DLTs; it is anticipated that those DLTs that are best suited for the purpose of DIDs will see the highest adoption rates.there will be Darwinian selection of the DLTs that are best fit for the purpose of DIDs.</p> <p>From a digital identity perspective, the primary problem that DIDs and DID documents solve is the need for a universally available, decentralized root of trust that any application or system can rely upon to discover and verify credentials about the DID subject. Such a solution enables us to move \"beyond federation\" into a world where any peer can enter into trusted interactions with any other peer, just as the Internet enabled any two peers to connect and communicate.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#32-the-cloud-layer-cloud-agents-and-cloud-wallets","title":"3.2. The Cloud Layer: Cloud Agents and Cloud Wallets","text":"<p>While the DID specification covers the bottom layer of a decentralized public key infrastructure, the DKMS spec will concentrate on the two layers above it. The first of these, the cloud layer, is the server-side infrastructure that mediates between the ultimate peers\u2014the edge devices used directly by identity owners\u2014and the DID layer.</p> <p>While not strictly necessary from a pure logical point-of-view, in practice this server-side DKMS layer plays a similar role in DID infrastructure as email servers play in SMTP email infrastructure or Web servers play in Web infrastructure. Like email or Web servers, cloud agents and cloud wallets are designed to be available 24 x 7 to send and receive communications on behalf of their identity owners. They are also designed to perform communications, encryption, key management, data management, and data storage and backup processes that are not typically feasible for edge devices given their typical computational power, bandwidth, storage capacity, reliability and/or availability.</p> <p>Cloud agents and wallets will typically be hosted by a service provider called an agency. Agencies could be operated by any type of service provider\u2014ISPs, telcos, search engines, social networks, banks, utility companies, governments, etc. A third party agency is not a requirement of DKMS architecture\u2014any identity owner can also host their own cloud agents.</p> <p>From an architectural standpoint, it is critical that the cloud layer be designed so that it does not \"recentralize\" any aspect of DKMS. In other words, even if an identity owner chooses to use a specific DKMS service provider for a specific set of cloud agent functions, the identity owner should be able to substitute another DKMS service provider at a later date and retain complete portability of her DKMS keys, data and metadata.</p> <p>Another feature of the cloud layer is that cloud agents can use DIDs and DID documents to automatically negotiate mutually authenticated secure connections with each other using DID Communication, a protocol being designed for this purpose.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#33-the-edge-layer-edge-agents-and-edge-wallets","title":"3.3. The Edge Layer: Edge Agents and Edge Wallets","text":"<p>The edge layer is vital to DKMS because it is where identity owners interact directly with computing devices, operating systems, and applications. This layer consists of DKMS edge agents and edge wallets that are under the direct control of identity owners. When designed and implemented correctly, edge devices, agents, and wallets can also be the safest place to store private keys and other cryptographic material. They are the least accessible for network intrusion, and even a successful attack on any single client device would yield the private data for only a single user or at most a small family of users.</p> <p>Therefore, the edge layer is where most DKMS private keys and link secrets are generated and where most key operations and storage are performed. To meet the security and privacy requirements, DKMS architecture makes the following two assumptions:</p> <ol> <li> <p>A DKMS agent is always installed in an environment that includes a secure element or Trusted Platform Module (for simplicity, this document will use the term \"secure element\" or \u201cSE\u201d for this module).</p> </li> <li> <p>Private keys used by the agent never leave the secure element. </p> </li> </ol> <p>By default edge agents are always paired with a corresponding cloud agent due to the many DKMS operations that a cloud agent enables, including communications via the DKMS protocol to other edge and cloud agents. However this is not strictly necessary. As shown in Figure 1, edge agents could also communicate directly, peer-to-peer, via a protocol such as Bluetooth, NFC, or another mesh network protocol. Edge agents may also establish secure connections with cloud agents or with others using DID Communication.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#34-verifiable-credentials","title":"3.4. Verifiable Credentials","text":"<p>By themselves, DIDs are \"trustless\", i.e., they carry no more inherent trust than an IP address. The primary difference is that they provide a mechanism for resolving the DID to a DID document containing the necessary cryptographic keys and endpoints to bootstrap secure communications with the associated agent.</p> <p>To achieve a higher level of trust, DKMS agents may exchange digitally signed credentials called verifiable credentials. Verifiable credentials are being standardized by the W3C Working Group of the same name. The purpose is summarized in the charter:</p> <p>It is currently difficult to express banking account information, education qualifications, healthcare data, and other sorts of machine-readable personal information that has been verified by a 3<sup>rd</sup> party on the Web. These sorts of data are often referred to as verifiable credentials. The mission of the Verifiable Credentials Working Group is to make expressing, exchanging, and verifying credentials easier and more secure on the Web.</p> <p>The following diagram from the W3C Verifiable Claims Working Group illustrates the primary roles in the verifiable credential ecosystem and the close relationship between DIDs and verifiable credentials.</p> <p></p> <p>Figure 3: The W3C Verifiable Credentials ecosystem</p> <p>Note that what is being verified in a verifiable credential is the signature of the credential issuer. The strength of the actual credential depends on the degree of trust the verifier has in the issuer. For example, if a bank issues a credential saying that the subject of the credential has a certain credit card number, a merchant can rely on the credential if the merchant has a high degree of trust in the bank.</p> <p>The Verifiable Claims Working Group is standardizing both the format of credentials and of digital signatures on the credentials. Different digital signature formats require different cryptographic key material. For example, credentials that use a zero-knowledge signature format such as Camenisch-Lysyanskaya (CL) signatures require a \"master secret\" or \u201clink secret\u201d that enables the prover (the identity owner) to make proofs about the credential without revealing the underlying data or signatures in the credential (or the prover's DID with respect to the credential issuer). This allows for \"credential presentations\" that are unlinkable to each other. Link secrets are another type of cryptographic key material that must be stored in DKMS wallets.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#4-ledger-architecture","title":"4. Ledger Architecture","text":"<p>A fundamental feature of DIDs and DKMS is that they will work with any modern blockchain, distributed ledger, distributed database, or distributed file system capable of supporting a DID method (which has a relatively simple set of requirements\u2014see the DID specification). For simplicity, this document will refer to all of these systems as \"ledgers\".</p> <p>There are a variety of ledger designs and governance models as illustrated in Figure 4. </p> <p></p> <p>Figure 4: Blockchain and distributed ledger governance models</p> <p>Public ledgers are available for anyone to access, while private ledgers have restricted access. Permissionless ledgers allow anyone to run a validator node of the ledger (a node that participates in the consensus protocol), and thus require proof-of-work, proof-of-stake, or other protections against Sybil attacks. Permissioned ledgers restrict who can run a validator node, and thus can typically operate at a higher transaction rate.</p> <p>For decentralized identity management, a core requirement of DIDs and DKMS is that they can interoperate with any of these ledgers. However for privacy and scalability reasons, certain types of ledgers play specific roles in DKMS architecture.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#41-public-ledgers","title":"4.1. Public Ledgers","text":"<p>Public ledgers, whether permissionless or permissioned, are crucial to DKMS infrastructure because they provide an open global root of trust. To the extent that a particular public ledger has earned the public\u2019s trust that it is strong enough to withstand attacks, tampering, or censorship, it is in a position to serve as a strong, universally-available root of trust for DIDs and the DID documents necessary for decentralized key management.</p> <p>Such a publicly available root of trust is particularly important for:</p> <ol> <li> <p>Public DIDs (also called \"anywise DIDs\") that need to be recognized as trust anchors by a large number of verifiers.</p> </li> <li> <p>Schema and credential definitions needed for broad semantic interoperability of verifiable credentials.</p> </li> <li> <p>Revocation registries needed for revocation of verifiable credentials that use proofs.</p> </li> <li> <p>Policy registries needed for authorization and revocation of DKMS agents (see section 9.2).</p> </li> <li> <p>Anchoring transactions posted for verification or coordination purposes by smart contracts or other ledgers, including microledgers (below).</p> </li> </ol>"},{"location":"concepts/0051-dkms/dkms-v4/#42-private-ledgers","title":"4.2. Private Ledgers","text":"<p>Although public ledgers may also be used for private DIDs\u2014DIDs that are intended for use only by a restricted audience\u2014this requires that their DID documents be carefully provisioned and managed to avoid any information that can be used for attack or correlation. This threat is lessened if private DIDs are registered and managed on a private ledger that has restricted access. However the larger the ledger, the more it will require the same precautions as a public ledger.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#43-microledgers","title":"4.3. Microledgers","text":"<p>From a privacy perspective\u2014and particularly for compliance with privacy regulations such as the EU General Data Protection Regulation (GDPR)\u2014the ideal identifier is a pairwise pseudonymous DID. This DID (and its corresponding DID document) is only known to the two parties in a relationship.</p> <p>Because pairwise pseudonymous DID documents contain the public keys and service endpoints necessary for the respective DKMS agents to connect and send encrypted, signed messages to each other, there is no need for pairwise pseudonymous DIDs to be registered on a public ledger or even a conventional private ledger. Rather they can use microledgers. </p> <p>A microledger is essentially identical to a conventional private ledger except it has only as many nodes as it has parties to the relationship. The same cryptographic steps are used:</p> <ol> <li> <p>Transactions are digitally signed by authorized private key(s).</p> </li> <li> <p>Transactions are cryptographically ordered and tamper evident.</p> </li> <li> <p>Transactions are replicated efficiently across agents using simple consensus protocols. These protocol, and the microledgers that provide their persistent state, constitute a root of trust for the relationship.</p> </li> </ol> <p>Microledgers are effectively permissionless because anyone can operate one in cooperation with anyone else\u2014only the parties to the microledger relationship need to agree. If there is a danger of the parties to the microledger getting \"out of sync\" (e.g., if an attacker has compromised one party's agents such that the party's state is deadlocked, or one party's agents have all been lost so that the party is unable to receive a change-of-state from the other), the party\u2019s agents can register a dead drop point. This is a pre-established endpoint and keys both parties can use to re-sync their microledgers and restore their connection.</p> <p>Microledgers play a special role in DKMS architecture because they are used to maintain pairwise pseudonymous connections between DKMS agents. The use of microledgers also helps enormously with the problems of scale\u2014they can significantly reduce the load on public ledgers by moving management of pairwise pseudonymous DIDs and DID documents directly to DKMS agents.</p> <p>The protocols associated with microledgers include:</p> <ul> <li>A protocol to formally connect two parties and exchange DID Documents.</li> <li>A protocol to update and synchronize DID Documents.</li> <li>A protocol to query DID Documents.</li> </ul> <p>Today, the only known example of this approach is the <code>did:peer</code> method. It is possible that alternative implementations will emerge.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#5-key-management-architecture","title":"5. Key Management Architecture","text":"<p>DKMS adheres to the principle of key separation where keys for different purposes should be cryptographically separated. This avoids use of the same key for multiple purposes. Keys are classified based on usage and the nature of information being protected. Any change to a key requires that the relevant DID method ensure that the change comes from the identity owner or her authorized delegate. All requests by unauthorized entities must be ignored or flagged by the DKMS agent. If anyone else can change any key material, the security of the system is compromised. </p> <p>DKMS architecture addresses what keys are needed, how they are used, where they should be stored and protected, how long they should live, and how they are revoked and/or recovered when lost or compromised.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#51-key-types-and-key-descriptions","title":"5.1. Key Types and Key Descriptions","text":"<p>NIST 800-130 framework requirement 6.1 requires a CKMS to specify and define each key type used. The following key layering and policies can be applied.</p> <ol> <li> <p>Master keys:             </p> <ol> <li> <p>Keys at the highest level, in that they themselves are not cryptographically protected. They are distributed manually or initially installed and protected by procedural controls and physical or electronic isolation.</p> </li> <li> <p>MAY be used for deriving other keys;</p> </li> <li> <p>MUST NOT ever be stored in cleartext.</p> </li> <li> <p>SHOULD never be stored in a single encrypted form, but only:</p> <ol> <li> <p>Saved in secure offline storage;</p> </li> <li> <p>Secured by high secure encrypted vaults, such as a secure element, TPM, or TEE.</p> </li> <li> <p>Distributed using a technique such as Shamir secret sharing;</p> </li> <li> <p>Derived from secure multiparty computation.</p> </li> <li> <p>Saved somewhere that requires secure interactions to access (which could mean slower retrieval times).</p> </li> </ol> </li> <li> <p>SHOULD be used only for creating signatures as proof of delegation for other keys.</p> </li> <li> <p>MUST be forgotten immediately after use\u2013securely erased from memory, disk, and every location that accessed the key in plain text. </p> </li> </ol> </li> <li> <p>Key encrypting keys              </p> <ol> <li> <p>Symmetric or public keys used for key transport or storage of other keys.</p> </li> <li> <p>MAY themselves be secured under other keys.</p> </li> <li> <p>If they are not ephemeral, they SHOULD be stored in secure access-controlled devices, used in those devices and never exposed.</p> </li> </ol> </li> <li> <p>Data keys    </p> <ol> <li> <p>Used to provide cryptographic operations on user data (e.g., encryption, authentication). These are generally short-term symmetric keys; however, asymmetric signature private keys may also be considered data keys, and these are usually longer-term keys.</p> </li> <li> <p>SHOULD be dedicated to specific roles, such as authentication, securing communications, protecting storage, proving authorized delegation, constructing credentials, or generating proofs.</p> </li> </ol> </li> </ol> <p>The keys at one layer are used to protect items at a lower level. This constraint is intended to make attacks more difficult, and to limit exposure resulting from compromise of a specific key. For example, compromise of a key-encrypting-key (of which a master key is a special case) affects all keys protected thereunder. Consequently, special measures are used to protect master keys, including severely limiting access and use, hardware protection, and providing access to the key only under shared control.   </p> <p>In addition to key layering hierarchy, keys may be classified based on temporal considerations: </p> <ol> <li> <p>Long-term keys. These include master keys, often key-encrypting keys, and keys used to facilitate key agreement.   </p> </li> <li> <p>Short-term keys. These include keys established by key transport or key agreement, often used as data keys or session keys for a single communications session.</p> </li> </ol> <p>In general, communications applications involve short-term keys, while data storage applications require longer-term keys. Long-term keys typically protect short-term keys. </p> <p>The following policies apply to key descriptions:</p> <ol> <li> <p>Any DKMS-compliant key SHOULD use a DID-compliant key description.</p> </li> <li> <p>This key description MUST be published at least in the governing DID method specification.</p> </li> <li> <p>This key description SHOULD be aggregated in the Key Description Registry maintained by the W3C Credentials Community Group.</p> </li> </ol> <p>DKMS key management must encompass the keys needed by different DID methods as well as different verifiable credentials exchange protocols and signature formats. The following list includes the initial key types required by the Sovrin DID Method Spec and the Sovrin protocol for verifiable credentials exchange:</p> <ol> <li> <p>Link secret: (one per entity) A high-entropy 256-bit integer included in every credential in blinded form. Used for proving credentials were issued to the same logical identity. A logical identity only has one link secret. The first DKMS agent provisioned by an identity owner creates this value and stores it in an encrypted wallet or in a secure element if available. Agents that receive credentials and present proofs must know this value. It can be transferred over secure channels between agents as necessary. If the link secret is changed, credentials issued with the new link secret value cannot be correlated with credentials using the old link secret value.</p> </li> <li> <p>DID keys: (one per relationship per agent) Ed25519 keys used for non-repudiation signing and verification for DIDs. Each agent manages their own set of DID keys.</p> </li> <li> <p>Agent policy keys: (one per agent) Ed25519 key pairs used with the agent policy registry. See section 9.2. The public key is stored with the agent policy registry. Transactions made to the policy registry are signed by the private key. The keys are used in zero-knowledge during proof presentation to show the agent is authorized by the identity owner to present the proof. Unauthorized agents MUST NOT be trusted by verifiers.</p> </li> <li> <p>Agent recovery keys: (a fraction per trustee) Ed25519 keys. A public key is stored by the agent and used for encrypting backups. The private key is saved to an offline medium or split into shares and given to trustees. To encrypt a backup, an ephemeral X25519 key pair is created where the ephemeral private key is used to perform a Diffie-Hellman agreement with the public recovery key to create a wallet encryption key. The private ephemeral key is forgotten and the ephemeral public key is stored with the encrypted wallet backup. To decrypt a backup, the private recovery key performs a Diffie-Hellman agreement with the ephemeral public key to create the same wallet encryption key.</p> </li> <li> <p>Wallet encryption keys: (one per wallet segment) 256 bit symmetric keys for encrypting wallets and backups. The key is generated by an agent then wrapped using secure enclaves (preferred) or derived from user inputs like strong passwords (see section 5.2). It MUST NOT be stored directly in secure enclaves when portability is a requirement.</p> </li> <li> <p>Wallet permission keys: (one per permission) Symmetric keys or Ed25519 keypairs that allow fine-grained permissions over various data stored in the wallet i.e. wallet read-only access, credential group write access, or write all access.</p> </li> </ol>"},{"location":"concepts/0051-dkms/dkms-v4/#52-key-generation","title":"5.2. Key Generation","text":"<p>NIST 800-130 framework requirement 6.19 requires that a CKMS design shall specify the key-generation methods to be used in the CKMS for each type of key. The following policies can be applied.</p> <ol> <li> <p>For any key represented in a DID document, the generation method MUST be included in the key description specification.</p> </li> <li> <p>Any parameters necessary to understand the generated key MUST be included in the key description.</p> </li> <li> <p>The key description SHOULD NOT include any metadata that enables correlation across key pairs.</p> </li> <li> <p>DKMS key types SHOULD use derivation functions that simplify and standardize key recovery. </p> </li> </ol> <p>A secure method for key creation is to use a seed value combined with a derivation algorithm. Key derivation functions (KDF), pseudo random number generators (PRNG), and Bitcoin\u2019s BIP32 standard for hierarchical deterministic (HD) keys are all examples of key creation using a seed value with a derivation function or mapping.</p> <p>Hardware based key generation (like HSMs or TPMS) is usually more secure as they are typically designed to include more factors like white noise and temperature which are harder to corrupt.</p> <p>If KDFs or PRNGs are used, a passphrase, biometric input, or social data from multiple users combined with random salt SHOULD be used as the input to create the seed. Alternately a QR code or words from a list such as the PGP word list can be used. In either case, the input MUST NOT be stored anywhere connected to the Internet.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#53-multi-device-management","title":"5.3. Multi-Device Management","text":"<p>Each device hosts an edge agent and edge wallet. All keys except for the link secret are unique per device. This allows for fine-grained (e.g., per relationship) control of authorized devices, as well as remote revocation. As part of the process for provisioning an edge agent, owners must choose what capabilities to grant. Capabilities must be flexible so owners can add or remove them depending on their needs.</p> <p>Wallet permissions SHOULD be controlled using keys that grant fixed permissions. One example of such a system is Cryptree.</p> <p>It is recommended that private keys never be reused across agents. If a secret is shared across agents, then there must be a way to remotely revoke the agent using a distributed ledger such that the secret is rendered useless on that agent. The DKMS architecture uses ledgers and diffused trust to enable fine grained control over individual keys and entire devices. An agent policy registry located on a ledger allows an owner to define agent authorizations and control over those authorizations. (See 9.2 Policy Registries). Agents must notify each other when a new agent is added to an authorized pool or removed in order to warn identity owners of unauthorized or malicious agents with a cloud agent acting as the synchronization hub.</p> <p>Techniques like distributed hash tables or gossip protocols SHOULD be employed to keep device data synchronized.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#54-key-portability-and-migration","title":"5.4. Key Portability and Migration","text":"<p>As mentioned in section 2.8, portability of DKMS wallets and keys is an important requirement\u2014if agencies or other service providers could \"lock-in\" identity owners, DIDs and DKMS would no longer be decentralized. Thus the DKMS protocol MUST support identity owners migrating their edge agents and cloud agents to the agency of their choice (including self-hosting). Agency-to-agency migration is not fully defined in this version of DKMS architecture, but it will be specified in a future version. See section 11.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#6-recovery-methods","title":"6. Recovery Methods","text":"<p>In key management, key recovery specifies how keys are reconstituted in case of loss or compromise. In decentralized identity management, recovery is even more important since identity owners have no \"higher authority\" to turn to for recovery.</p> <p>In this version of DKMS architecture, two recovery methods are recommended:</p> <ol> <li> <p>Offline recovery uses physical media or removable digital media to store recovery keys.</p> </li> <li> <p>Social recovery employs \"trustees\" who store encrypted recovery data on an identity owners behalf\u2014typically in the trustees own agent(s).</p> </li> </ol> <p>These methods are not exclusive, i.e., both can be employed for additional safety.</p> <p>Both methods operate against encrypted backups of the identity owner\u2019s digital identity wallet. Backups are encrypted by the edge agent with a backup recovery key. See section 5.1. While such backups may be stored in many locations, for simplicity this version of DKMS architecture assumes that cloud agents will provide an automated backup service for their respective edge agents.</p> <p>Future versions of this specification MAY specify additional recovery methods, include remote biometric recovery and recovery cooperatives.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#61-offline-recovery","title":"6.1. Offline Recovery","text":"<p>Offline recovery is the conventional form of backup. It can be performed using many different methods. In DKMS architecture, the standard strategy is to store an encrypted backup of the identity owner\u2019s wallet at the owner\u2019s cloud agent, and then store a private backup recovery key offline. The private backup recovery key can be printed to a paper wallet as one or more QR codes or text strings. It can also be saved to a file on a detachable media device such as a removable disk, hardware wallet or USB key. </p> <p>The primary downside to offline recovery is that the identity owner must not only safely store the offline copy, but remember the location and be able to able to access the offline copy when it is needed to recover.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#62-social-recovery","title":"6.2. Social Recovery","text":"<p>Social recovery has two advantages over offline recovery:</p> <ol> <li> <p>The identity owner does not have to create an offline backup\u2014the social recovery setup process can be accomplished entirely online.</p> </li> <li> <p>The identity owner does not have to safely store and remember the location of the offline backup.</p> </li> </ol> <p>However it is not a panacea:</p> <ol> <li> <p>The identity owner still needs to remember her trustees.</p> </li> <li> <p>Social recovery opens the opportunity, however remote, for an identity owner\u2019s trustees to collude to take over the identity owner\u2019s digital identity wallet.</p> </li> </ol> <p>A trustee is any person, institution, or service that agrees to assist an identity owner during recovery by (1) securely storing recovery material (called a \"share\") until a recovery is needed, and (2) positively identifying the identity owner and the authenticity of a recovery request before authorizing release of their shares.</p> <p>This second step is critical. Trustees MUST strongly authenticate an identity owner during recovery so as to detect if an attacker is trying exploit them to steal a key or secret. Software should aid in ensuring the authentication is strong, for example, confirming the trustee actually conversed with Alice, as opposed to getting an email from her.</p> <p>For social recovery, agents SHOULD split keys into shares and distribute them to trustees instead of sending each trustee a full copy. When recovery is needed, trustees can be contacted and the key will be recovered once enough shares have been received. An efficient and secure threshold secret sharing scheme, like Shamir's Secret Sharing, SHOULD be used to generate the shares and recombine them. The number of trustees to use is the decision of the identity owner, however it is RECOMMENDED to use at least three with a threshold of at least two. </p> <p>The shares may be encrypted by a key derived from a KDF or PRNG whose input is something only the identity owner knows, has, or is or any combination of these.</p> <p></p> <p>Figure 5: Key sharing using Shamir Secret Sharing</p> <p>As the adoption interest in decentralized identity grows, social recovery has become a major focus of additional research and development in the industry. For example, at the Rebooting the Web of Trust #8 conference held in Barcelona 1-3 March 2019, six papers on the topic were submitted (note that several of these also have extensive bibliographies):</p> <ol> <li> <p>A New Approach to Social Key Recovery by Christopher Allen and Mark Friedenbach</p> </li> <li> <p>Security Considerations of Shamir's Secret Sharing by Peg</p> </li> <li> <p>Implementing of Threshold Schemes by Daan Sprenkels</p> </li> <li> <p>Social Key Recovery Design and Implementation by Hank Chiu, Hankuan Yu, Justin Lin &amp; Jon Tsai</p> </li> <li> <p>SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes by The TREZOR Team</p> </li> </ol> <p>In addition, two new papers on the topic were started at the conference and are still in development at the time of publication:</p> <ol> <li> <p>Shamir Secret Sharing Best Practices by Christopher Allen et al.</p> </li> <li> <p>Evaluating Social Schemes for Recovering Control of an Identifier by Sean Gilligan, Peg, Adin Schmahmann, and Andrew Hughes</p> </li> </ol>"},{"location":"concepts/0051-dkms/dkms-v4/#7-recovery-from-key-loss","title":"7. Recovery From Key Loss","text":"<p>Key loss as defined in this document means the owner can assume there is no further risk of compromise. Such scenarios include devices unable to function due to water, electricity, breaking, fire, hardware failure, acts of God, etc.  </p>"},{"location":"concepts/0051-dkms/dkms-v4/#71-agent-policy-key-loss","title":"7.1. Agent Policy Key Loss","text":"<p>Loss of an agent policy key means the agent no longer has proof authorization and cannot make updates to the agent policy registry on the ledger. Identity owners SHOULD have backup agent policy keys that can revoke the current active agent policy key from the agent policy registry and issue a new agent policy key to the replacement agent.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#72-did-key-loss","title":"7.2. DID Key Loss","text":"<p>Loss of a DID key means the agent can no longer authenticate over the channel and cannot rotate the key. This key MUST be recoverable from the encrypted backup.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#73-link-secret-loss","title":"7.3. Link Secret Loss","text":"<p>Loss of the link secret means the owner can no longer generate proofs for the verifiable credentials in her possession or be issued credentials under the same identity. The link secret MUST be recoverable from the encrypted backup.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#74-credential-loss","title":"7.4. Credential Loss","text":"<p>Loss of credentials requires the owner to contact his credential issuers, reauthenticate, and request the issuers revoke existing credentials, if recovery from a backup is not possible. Credentials SHOULD be recoverable from the encrypted backup. </p>"},{"location":"concepts/0051-dkms/dkms-v4/#75-relationship-state-recovery","title":"7.5. Relationship State Recovery","text":"<p>Recovery of relationship state due to any of the above key-loss scenarios is enabled via the dead drop mechanism.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#8-recovery-from-key-compromise","title":"8. Recovery From Key Compromise","text":"<p>Key compromise means that private keys and/or master keys have become or can become known either passively or actively. </p> <ol> <li> <p>\"Passively\" means the identity owner is not aware of the compromise. An attacker may be eavesdropping or have remote communications with the agent but has not provided direct evidence of intrusion or malicious activity, such as impersonating the identity owner or committing fraud.</p> </li> <li> <p>\"Actively\" means the identity owner knows her keys have been exposed. For example, the owner is locked out of her own devices and/or DKMS agents and wallets, or becomes aware of abuse or fraud.</p> </li> </ol> <p>To protect from either, there are techniques available: rotation, revocation, and quick recovery. Rotation helps to limit a passive compromise, while revocation and quick recovery help to limit an active one.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#81-key-rotation","title":"8.1. Key Rotation","text":"<p>Keys SHOULD be changed periodically to limit tampering. When keys are rotated, the previous keys are revoked and new ones are added. It is RECOMMENDED for keys to expire for the following reasons:</p> <ul> <li> <p>Technology advances. Encryption (and encryption breaking) technologies are constantly advancing.  Expiring keys helps enforce migrating to better technologies.</p> </li> <li> <p>Mitigation of compromises. Keys that change often prevent attackers from using them even if they are able to steal them. Expiring keys spreads this immunity.</p> </li> <li> <p>Changing needs. Key owners may only use certain secrets while performing a specific task. The task may end after a certain date and all secrets tied to that task should also be terminated. Expiring keys helps enforce this this policy.</p> </li> </ul>"},{"location":"concepts/0051-dkms/dkms-v4/#82-key-revocation","title":"8.2. Key Revocation","text":"<p>DKMS keys MUST be revocable. Verifiers MUST be able to determine the revocation status of a DKMS key. It is not good enough to simply forget a key because that does not protect against key compromise. Control over who can update a revocation list MUST be enforced so attackers cannot maliciously revoke user keys. (Note that a key revoked by an attacker reveals that the attacker knows a secret.)</p>"},{"location":"concepts/0051-dkms/dkms-v4/#83-agent-policy-key-compromise","title":"8.3. Agent Policy Key Compromise","text":"<p>Compromise of an agent\u2019s policy key means an attacker can use the agent to impersonate the owner for proof presentation and make changes to the agent policy registry. Owners must be able to revoke any of their devices to prevent impersonation. For example, if the owner knows her device has been stolen, she will want to revoke all device permissions so even if the thief manages to break into the agent the DKMS data value is limited. Identity owners SHOULD have backup agent policy keys that are authorized to revoke the compromised key from the agent policy registry and issue a new agent policy key to the replacement agent.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#84-did-key-compromise","title":"8.4. DID Key Compromise","text":"<p>Compromise of a DID key means an attacker can use the channel to impersonate the owner as well as potentially lock the owner out from further use if the attacker rotates the key before the owner realizes what has happened. This attack surface is minimized if keys are rotated on a regular basis. An identity owner MUST also be able to trigger a rotation manually upon discovery of a compromise. Owners SHOULD implement a diffuse trust model among multiple agents where a single compromised agent is not able to revoke a key because more than one agent is required to approve the action. </p>"},{"location":"concepts/0051-dkms/dkms-v4/#85-link-secret-compromise","title":"8.5. Link Secret Compromise","text":"<p>Compromise of the owner link secret means an attacker may impersonate the owner when receiving verifiable credentials or use existing credentials for proof presentation. Note that unless the attacker is also able to use an agent that has \"PROVE\" authorization, the verifier will be able to detect an unauthorized agent. At this point the owner SHOULD revoke her credentials and request for them to be reissued with a new link secret.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#86-credential-compromise","title":"8.6. Credential Compromise","text":"<p>Compromise of a verifiable credential means an attacker has learned the attributes of the credential. Unless the attacker also manages to compromise the link secret and an authorized agent, he is not able to assert the credential, so the only loss is control of the underlying data.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#87-relationship-state-recovery","title":"8.7. Relationship State Recovery","text":"<p>Recovery of relationship state due to any of the above key-compromise scenarios is enabled via the dead drop mechanism.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#9-dkms-protocol","title":"9. DKMS Protocol","text":""},{"location":"concepts/0051-dkms/dkms-v4/#91-microledger-transactions","title":"9.1. Microledger Transactions","text":"<p>DKMS architecture uses microledgers to represent the state of the authorized keys in a relationship. Just as with conventional ledgers, the structure is such that the parties to a relationship can verify it at any moment in time, as can a third party for auditing purposes. Microledgers are used between two parties where each party signs transactions using their DID keys. This allow changes to DID keys to be propagated in a secure manner where each transaction is signed with an existing key authorized in earlier transactions. </p>"},{"location":"concepts/0051-dkms/dkms-v4/#92-policy-registries","title":"9.2. Policy Registries","text":"<p>Each Identity Owner creates an authorization policy on the ledger. The policy allows an agent to have some combination of authorizations. This is a public record, but no information needs to be shared with any other party. Its purpose is to allow for management of device authorization in a flexible way, by allowing for agents to prove in zero knowledge that they are authorized by the identity owner.</p> <ul> <li>The authorization policy has a unique address on the ledger.</li> <li>Each of the identity owner's agents has a secret value.</li> <li>The agent makes a blinded commitment to the secret value.</li> <li>The agent then makes another blinded commitment to both the first commitment and the policy address.</li> <li>The first commitment is stored in the PROVE section of the authorization policy.</li> <li>The second commitment is stored by the ledger in a global registry (shared by all identity owners, or at least a large number of them, for herd privacy).</li> </ul> <p>When an agent is granted PROVE authorization, by adding a commitment to the agent's secret value to PROVE section of the authorization policy, the ledger adds the second commitment to the global prover registry. When an agent loses its PROVE authorization, the ledger removes the associated commitment from the prover registry. The ledger can enforce sophisticated owner defined rules like requiring multiple signatures to authorize updates to the Policy.</p> <p>An agent can now prove in zero knowledge that it is authorized because the ledger maintains a global registry for all agents with PROVE authorization for all identity owners. An agent can prove that its secret value and the policy address in which that value is given PROVE authorization are part of the global policy registry without revealing the secret value, or the policy address. By using a zero knowledge proof, the global policy registry does not enable correlation of any specific identity owner.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#93-authenticated-encryption","title":"9.3. Authenticated Encryption","text":"<p>The use of DIDs and microledgers allows communication between agents to use authenticated encryption. Agents use their DID verification keys for authenticating each other whenever a communication channel is established. Microledgers allow DID keys to have rooted mutual authentication for any two parties with a DID. In the sequence diagrams in section 10, all agent-to-agent communications that uses authenticated encryption is indicated by bold blue arrows.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#94-recovery-connection","title":"9.4. Recovery connection","text":"<p>Each Identity Owner begins a recovery operation by requesting their respective recovery information from trustees. After a trustee has confirmed the request originated with the identity owner and not a malicious party, a recovery connection is formed. This special type of connection is meant only for recovery purposes. Recovery connections are decommissioned when the minimum number of recovery shares have been received and the original encrypted wallet data has been restored. Identity owners can then resume normal connections because their keys have been recovered. Trustees SHOULD only send recovery shares to identity owners over a recovery connection.  </p>"},{"location":"concepts/0051-dkms/dkms-v4/#95-dead-drops","title":"9.5. Dead Drops","text":"<p>In scenarios where two parties to a connection move agencies (and thus service endpoints) at the same time, or one party's agents have been compromised such that it can no longer send or receive relationship state changes, there is a need for recovery not just of keys and agents, but of the state of the relationship. These scenarios may include malicious compromise of agents by an attacker such that neither the party nor the attacker controls enough agents to meet the thresholds set in the DID Document or the Authorization Policy, or complete loss of all agents due to some catastrophic event.</p> <p>In some cases, relationship state may be recoverable via encrypted backup of the agent wallets. In the event that this is not possible, the parties can make use of a dead drop to recover their relationship state.</p> <p>A dead drop is established and maintained as part of a pairwise relationship. The dead drop consists of a service endpoint and the public keys needed to verify the package that may be retrieved from that endpoint. The keys needed for the dead drop are derived from a combination of a Master key and the pairwise DID of the relationship that is being recovered.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#10-protocol-flows","title":"10. Protocol Flows","text":"<p>This section contains the UML sequence diagrams for all standard DKMS key management operations that use the DKMS protocol. Diagrams are listed in logical order of usage but may be reviewed in any order. Cross-references to reusable protocol sequences are represented as notes in blue. Other comments are in yellow.</p> <p>Table 1 is a glossary of the DKMS key names and types used in these diagrams.</p> Key Name Description A<sub>p</sub><sup>x-sv</sup> Agent Policy Secret Value for agent x A<sub>p</sub><sup>x-svc</sup> Agent Policy Secret Value Commitment for agent x A<sub>p</sub><sup>x-ac</sup> Agent Policy Address Commitment for agent x A<sub>A</sub><sup>x-ID</sup> Alice's Agent to Agent Identifier for agent x A<sub>A</sub><sup>x-vk</sup> Alice's Agent to Agent Public Verification Key for agent x A<sub>A</sub><sup>x-sk</sup> Alice's Agent to Agent Private Signing Key for agent x A<sub>B</sub><sup>DID</sup> Alice\u2019s DID for connection with Bob A<sub>B</sub><sup>x</sup> Alice\u2019s key pair for connection with Bob for agent x A<sub>B</sub><sup>x-vk</sup> Alice\u2019s Public Verification Key for connection with Bob for agent x A<sub>B</sub><sup>x-sk</sup> Alice\u2019s Private Signing Key for connection with Bob for agent x A<sub>W</sub><sup>x-k</sup> Wallet Encryption Key for agent x A<sub>LS</sub> Alice's Link Secret <p>Table 1: DKMS key names used in this section</p>"},{"location":"concepts/0051-dkms/dkms-v4/#101-edge-agent-start","title":"10.1. Edge Agent Start","text":"<p>An identity owner\u2019s experience with DKMS begins with her first installation of a DKMS edge agent. This startup routine is reused by many other protocol sequences because it is needed each time an identity owner installs a new DKMS edge agent.</p> <p></p> <p>The first step after successful installation is to prompt the identity owner whether he/she already has a DKMS identity wallet or is instantiating one for the first time. If the owner already has a wallet, the owner is prompted to determine if the new edge agent installation is for the purpose of adding a new edge agent, or recovering from a lost or compromised edge agent. Each of these options references another protocol pattern.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#102-provision-new-agent","title":"10.2. Provision New Agent","text":"<p>Any time a new agent is provisioned\u2014regardless of whether it is an edge agent or a cloud agent\u2014the same sequence of steps are necessary to set up the associated wallet and secure communications with the new agent.</p> <p></p> <p>As noted in section 3.3, DKMS architecture recommends that a DKMS agent be installed in an environment that includes a secure element. So the first step is for the edge agent to set up the credential the identity owner will use to unlock the secure element. On modern smartphones this will typically be a biometric, but it could be a PIN, passcode, or other factor, or a combination of factors.</p> <p>The edge agent then requests the secure element to create the key pairs necessary to establish the initial agent policies and to secure agent-to-agent communications. The edge agent also generates a ID to uniquely identify the agent across the identity owner\u2019s set of DKMS agents.</p> <p>Finally the edge agent requests the secure element to create a wallet encryption key and then uses it to encrypt the edge wallet.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#103-first-edge-agent","title":"10.3. First Edge Agent","text":"<p>The first time a new identity owner installs an edge agent, it must also set up the DKMS components that enable the identity owner to manage multiple separate DIDs and verifiable credentials as if they were from one logically unified digital identity. It must also lay the groundwork for the identity owner to install additional DKMS agents on other devices, each of which will maintain its own DKMS identity wallet while still enabling the identity owner to act as if they were all part of one logically unified identity wallet.</p> <p></p> <p>Link secrets are defined in section 5.1 and policy registries in section 9.2. The edge agent first needs to generate and store the link secret in the edge wallet. It then needs to generate the policy registry address and store it in the edge wallet. Now it is ready to update the agent policy registry.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#104-update-agent-policy-registry","title":"10.4. Update Agent Policy Registry","text":"<p>As explained in section 9.2, an agent policy registry is the master control point that an identity owner uses to authorize and revoke DKMS agent proof authorization (edge or cloud).</p> <p></p> <p>Each time the identity owner takes an action to add, revoke, or change the permissions for an agent, the policy registry is updated. For example, at the end of the protocol sequence in section 10.3, the action is to write the first policy registry entries that authorize the first edge agent.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#105-add-cloud-agent","title":"10.5. Add Cloud Agent","text":"<p>The final step in first-time setup of an edge agent is creation of the corresponding cloud agent. As explained in section 3.3, the default in DKMS architecture is to always pair an edge agent with a corresponding cloud agent due to the many different key management functions this combination can automate.</p> <p></p> <p></p> <p>The process of registering a cloud agent begins with the edge agent contacting the agency agent. For purposes of this document, we will assume that the edge agent has a relationship with one or more agencies, and has a trusted method (such as a pre-installed DID) for establishing a secure connection using authenticated encryption.</p> <p>The target agency first returns a request for the consent required from the identity owner to register the cloud agent together with a request for the authorizations to be granted to the cloud agent. By default, cloud agents have no authorizations other than those granted by the identity owner. This enables identity owners to control what tasks a cloud agent may or may not perform on the identity owner\u2019s behalf.</p> <p>Once the identity owner has returned consent and the selected authorizations, the agency agent provisions the new cloud agent and registers the cloud agent\u2019s service endpoint using the agency\u2019s routing extension. Note that this service endpoint is used only in agent-to-agent communications that are internal to the identity owner\u2019s own agent domain. Outward-facing service endpoints are assigned as part of adding connections with their own DIDs.</p> <p>Once these tasks are performed, the results are returned to the edge agent and stored security in the edge wallet.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#106-add-new-edge-agent","title":"10.6. Add New Edge Agent","text":"<p>Each time an identity owner installs a new edge agent after their first edge agent, the process must initialize the new agent and grant it the necessary authorizations to begin acting on the identity owner\u2019s behalf.</p> <p></p> <p>Provisioning of the new edge agent (Edge Agent 2) starts by the identity owner installing the edge agent software (section 10.2) and then receiving instructions about how to provision the new edge agent from an existing edge agent (Edge Agent 1). Note that Edge Agent 1 must the authorization to add a new edge agent (not all edge agents have such authorization). The identity owner must also select the authorizations the edge agent will have (DKMS agent developers will compete to make such policy choices easy and intuitive for identity owners).</p> <p>There are multiple options for how the Edge Agent 2 may receive authorization from Edge Agent 1. One common method is for Edge Agent 1 to display a QR code or other machine-readable code scanned by Edge Agent 2. Another way is for Edge Agent 1 to provide a passcode or passphrase that the identity owner types into Edge Agent 2. Another method is sending an SMS or email with a helper URL. In all methods the ultimate result is that Edge Agent 2 must be able to connect via authenticated encryption with Edge Agent 1 in order to verify the connection and pass the new agent-to-agent encryption keys that will be used for secure communications between the two agents.</p> <p>Once this is confirmed by both agents, Edge Agent 1 will then use the Update Agent Policy Registry sequence (section 10.4) to add authorizations to the policy registry for Edge Agent 2.</p> <p>Once that is confirmed, provisioning of Edge Agent 2 is completed when Edge Agent 1 send the link secret and any verifiable credentials that the identity owner has authorized Edge Agent 2 to handle to Edge Agent 2, which securely stores them in Edge Agent 2\u2019s wallet.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#107-add-connection-to-public-did","title":"10.7. Add Connection to Public DID","text":"<p>The primary purpose of DIDs and DKMS is to enable trusted digital connections. One of the most common use cases is when an identity owner needs to create a connection to an entity that has a public DID, for example any website that wants to support trusted decentralized identity connections with its users (for registration, authentication, verifiable credentials exchange, secure communications, etc.)</p> <p></p> <p></p> <p>Note that this sequence is entirely about agent-to-agent communications between DKMS agents to create a shared microledger and populate it with the pairwise pseudonymous DIDs that Alice and Org assign to each other together with the public keys and service endpoints they need to enable their agents to use authenticated encryption.</p> <p>First Alice\u2019s edge agent creates the key pair and DID that it will assign to Org and uses those to initialize a new microledger. It then sends a request for Alice\u2019s cloud agent to add its own key pair that Alice authorizes to act on that DID. These are returned to Alice\u2019s edge agent who adds them to the microledger.</p> <p>Next Alice\u2019s edge agent creates and sends a connection invitation to Alice\u2019s cloud agent. Alice\u2019s cloud agent resolves Org\u2019s DID to its DID document to discover the endpoint for Org\u2019s cloud agent (this resolution step is not shown in the diagram above). It then forwards the invitation to Org\u2019s cloud agent who in turn forwards it to the system operating as Org\u2019s edge agent.</p> <p>Org\u2019s edge agent performs the mirror image of the same steps Alice\u2019s edge agent took to create its own DID and key pair for Alice, adding those to the microledger, and authorizing its cloud agent to act on its behalf in this new relationship. </p> <p>When that is complete, Org\u2019s edge agent returns its microledger updates via authenticated encryption to its cloud agent which forwards them to Alice\u2019s cloud agent and finally to Alice\u2019s edge agent. This completes the connection and Alice is notified of success.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#108-add-connection-to-private-did-provisioned","title":"10.8. Add Connection to Private DID (Provisioned)","text":"<p>The other common use case for trusted connections is private peer-to-peer connections between two parties that do not initially connect via one or the other\u2019s public DIDs. These connections can be initiated any way that one party can share a unique invitation address, i.e., via a URL sent via text, email, or posted on a blog, website, LinkedIn profile, etc.</p> <p></p> <p></p> <p>The flow in this sequence diagram is very similar to the flow in section 10.8 where Alice is connecting to a public organization. The only difference is that rather than beginning with Alice\u2019s edge agent knowing a public DID for the Org, Alice\u2019s edge agent knows Bob\u2019s invitation address. This is a service, typically provided by an agency, that enables Bob\u2019s cloud agent to accept connection invitations (typically with appropriate spam protections and other forms of connection invitation filtering).</p> <p>The end result is the same as in section 10.8: Alice and Bob have established a shared microledger with the pairwise pseudonymous DIDs and the public keys and endpoints they need to maintain their relationship. Note that with DIDs and DKMS, this is the first connection that Alice and Bob can maintain for life (and beyond) that is not dependent on any centralized service provider or registry. And this connection is available for Alice and Bob to use with any application they wish to authorize.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#109-add-connection-to-private-did-unprovisioned","title":"10.9. Add Connection to Private DID (Unprovisioned)","text":"<p>This sequence is identical to section 10.8 except that Bob does not yet have a DKMS agent or wallet. So it addresses what is necessary for Alice to invite Bob to both start using a DKMS agent and to form a connection with Alice at the same time.</p> <p></p> <p></p> <p>The only difference between this sequence diagram and section 10.8 is the invitation delivery process. In 10.8, Bob already has a cloud agent, so the invitation can be delivered to an invitation address established at the hosting agency. In this sequence, Bob does not yet have cloud agent, so the invitation must be: a) anchored at a helper URL (typically provided by an agency), and b) delivered to Bob via some out-of-band means (typically an SMS, email, or other medium that can communicate a helper URL).</p> <p>When Bob receives the invitation, Bob clicks on the URL to go to the helper page and receive instructions about the invitation and how he can download a DKMS edge agent. He follows the instructions, installs the edge agent, which in turn provisions Bob\u2019s cloud agent. When provisioning is complete, Bob\u2019s edge agent retrieves Alice\u2019s connection invitation from the helper URL. Since Bob is now fully provisioned, the rest of the sequence proceeds identically to section 10.8.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#1010-rotate-did-keys","title":"10.10. Rotate DID Keys","text":"<p>As described in section 8.1, key rotation is a core security feature of DKMS. This diagram illustrates athe protocol for key rotation.</p> <p></p> <p></p> <p>Key rotation may be triggered by expiration of a key or by an another event such as agent recovery. The process begins with the identity owner\u2019s edge agent generating its own new keys. If keys also need to be rotated in the cloud agent, the edge agent sends a key change request.</p> <p>The identity owner\u2019s agent policy may require that key rotation requires authorization from two or more edge agents. If so, the first edge agent generates a one time passcode or QR code that the identity owner can use to authorize the key rotation at the second edge agent. Once the passcode is verified, the second edge agent signs the key rotation request and sends it to the first edge agent.</p> <p>Once the necessary authorizations have been received, the first edge agent writes the changes to the microledger for that DID. It then sends the updates to the microledger to the cloud agent for the other party to the DID relationship (Bob), who forwards it to Bob\u2019s edge agent. Bob\u2019s edge agent verifies the updates and adds the changes to its copy of the microledger.</p> <p>Bob\u2019s edge agent then needs to broadcast the changes to Bob\u2019s cloud agent and any other edge agent that Bob has authorized to interact with Alice. Once this is done, Alice and Bob are \"in sync\" with the rotated keys, and their connection is at full strength.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#1011-delete-connection","title":"10.11. Delete Connection","text":"<p>In decentralized identity, identity owners are always in control of their relationships. This means either party to a connection can terminate the relationship by deleting it. This diagram illustrates Alice deleting the connection she had with Bob.</p> <p></p> <p>All that is required to delete a connection is for the edge agent to add a DISABLE event to the microledger she established with Bob. As always, this change is propagated to Alice\u2019s cloud agent and any other edge agents authorized to interact with the DID she assigned to Bob.</p> <p>Note that, just like in the real world, it is optional for Alice to notify Bob of this change in the state of their relationship. If she chooses to do so, her edge agent will propagate the DISABLE event to Bob\u2019s copy of the microledger. If, when, and how Bob is notified by his edge agent(s) depends on Bob\u2019s notification policies.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#1012-revoke-edge-agent","title":"10.12. Revoke Edge Agent","text":"<p>Key revocation is also a required feature of DKMS architecture as discussed in section 8.2. Revocation of keys for a specific DID is accomplished either through rotation of those keys (section 10.10) or deletion of the connection (section 10.11). However in certain cases, an identity owner may need to revoke an entire edge agent, effectively disabling all keys managed by that agent. This is appropriate if a device is lost, stolen, or suspected of compromise.</p> <p></p> <p>Revoking an edge agent is done from another edge agent that is authorized to revoke agents. If a single edge agent is authorized, the process is straightforward. The revoking edge agent sends a signed request to the policy registry address (section 9.2) on the ledger holding the policy registry. The ledger performs the update. The revoking edge agent then \"removes\" the keys for the revoked edge agent by disabling them.</p> <p>As a best practice, this event also should trigger key rotation by the edge agent.</p> <p>Note that an identity owner may have a stronger revocation policy, such as requiring two edge agents to authorize revocation of another edge agent. This sequence is very similar to requiring two edge agents to authorize a key rotation as described in section 10.10. However it could also cause Alice to be locked out of her edge agents if an attacker can gain control of enough devices. In this case Alice could use one of her recovery options (sections 10.16 and 10.17).</p>"},{"location":"concepts/0051-dkms/dkms-v4/#1013-recovery-setup","title":"10.13. Recovery Setup","text":"<p>As discussed in section 6, recovery is a paramount feature of DKMS\u2014in decentralized key management, there is no \"forgot password\" button (and if there were, it would be a major security vulnerability). So it is particularly important that it be easy and natural for an identity owner to select and configure recovery options.</p> <p></p> <p>The process begins with Alice\u2019s edge agent prompting Alice to select among the two recovery options described in section 6: offline recovery and social recovery. Her edge agent then creates a key pair for backup encryption, encrypts a backup of her edge wallet, and stores it with her cloud agent.</p> <p>If Alice chooses social recovery, the next step is for Alice to add trustees as described in section 10.14. Once the trustee has accepted Alice\u2019s invitation, Alice\u2019s edge agent creates and shares a recovery data share for each trustee. This is a shard of a file containing a copy of her backup encryption key, her link secret, and the special recovery endpoint that was set up by her cloud agent when the recovery invitation was created (see section 10.14).</p> <p>Alice\u2019s edge agent sends this recovery data share to her cloud agent who forwards it to the cloud agent for each of her trustees. Each cloud agent securely stores the share so its identity owner is ready in helping Alice to recover should the need arise. (See sections 10.17 and 10.18 for the actual social recovery process.)</p> <p>If Alice chooses offline recovery, her edge agent first creates a \"paper wallet\", which typically consists of a QR code or string of text that encodes the same data as in a recovery data share. Her edge agent then displays that paper wallet data to Alice for printing and storing in a safe place. Note that one of the primary usability challenges with offline recovery methods is Alice:</p> <ol> <li> <p>Following through with storage of the paper wallet.</p> </li> <li> <p>Properly securing storage of the paper wallet over long periods of time.</p> </li> <li> <p>Remembering the location of the paper wallet over long periods of time.</p> </li> </ol> <p>To some extent these can be addressed if the edge agent periodically reminds the identity owner to verify that his/her paper wallet is securely stored in a known location.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#1014-add-trustee","title":"10.14. Add Trustee","text":"<p>The secret to implementing social recovery in DKMS is using DKMS agents to automate the process of securely storing, sharing, and recovering encrypted backups of DKMS wallets with several of the identity owner\u2019s connections. In DKMS architecture, these connections are currently called trustees. (Note: this is a placeholder term pending further usability research on the best name for this new role.)</p> <p></p> <p>Trustees are selected by the identity owner based on the owner\u2019s trust. For each trustee, the edge agent requests the cloud agent to create a trustee invitation. The cloud agent generates and registers with the agency a unique URL that will be used only for this purpose. The edge agent then creates a recovery data share (defined in 10.13) and shards it as defined by the identity owner\u2019s recovery policy.</p> <p>At this point there are two options for delivering the trustee invitation depending on whether the identity owner already has a connection with the trustee or not. If a connection exists, the edge agent sends the invitation to the cloud agent who forwards it to the trustee\u2019s cloud agent who forwards it to an edge agent who notifies the trustee of the invitation.</p> <p>If a connection does not exist, the recovery invitation is delivered out of band in a process very similar to adding a connection to a private DID (sections 10.8 and 10.9).</p> <p>Once the trustee accepts the invitation, the response is returned to identity owner\u2019s edge agent to complete the recovery setup process (section 10.13).</p>"},{"location":"concepts/0051-dkms/dkms-v4/#1015-update-recovery-setup","title":"10.15. Update Recovery Setup","text":"<p>With DKMS infrastructure, key recovery is a lifelong process. A DKMS wallet filled with keys, DIDs, and verifiable credentials is an asset constantly increasing in value. Thus it is critical that identity owners be able to update their recovery methods as their circumstances, devices, and connections change.</p> <p></p> <p>For social recovery, an identity owner may wish to add new trustees or delete existing ones. Whenever this happens, the owner\u2019s edge agent must recalculate new recovery data shares to shard among the new set of trustees. This is a two step process: the new share must first be sent to all trustees in the new set and an acknowledgement must be received from all of them. Once that it done, the edge agent can send a commitment message to all trustees in the new set to complete the process.</p> <p>Updating offline recovery data is simply a matter of repeating the process of creating and printing out a paper wallet. An edge agent can automatically inform its identity owner of the need to do this when circumstances require it as well as automatically remind its owner to keep such offline information safe and accessible.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#1016-offline-recovery","title":"10.16. Offline Recovery","text":"<p>One advantage of the offline recovery process is that it can be performed very quickly by the identity owner because it has no dependencies on outside parties.</p> <p></p> <p>The identity owner simply initiates recovery on a newly installed edge agent. The edge agent prompts to scan the paper wallet (or input the text). From this data, it extracts the special recovery endpoint registered in the recovery setup process (section 10.13) and the backup decryption key. It then requests the encrypted backup from the recovery endpoint (which routes to the identity owner\u2019s cloud agent), decrypts it, restores the edge wallet, and replaces the agent keys with new keys. The final steps are to update the agent policy registry and, as a best practice, rotate all DID keys.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#1017-social-recovery","title":"10.17. Social Recovery","text":"<p>Social recovery, while more complex than offline recovery, is also more automated, flexible, and resilient. The secret to making it easy and intuitive for identity owners is using DKMS agents to automate every aspect of the process except for the most social step: verification of the actual identity of the identity owner by trustees.</p> <p></p> <p></p> <p>Social recovery, like offline recovery, begins with the installation of a fresh edge agent. The identity owner selects the social recovery option and is prompted for the contact data her edge agent and cloud agent will need to send special new connection requests to her trustees. These special connection requests are then issued as described in section 10.8.</p> <p>These special connection requests are able to leverage the same secure DKMS infrastructure as the original connections while at the same time carrying the metadata needed for the trustee\u2019s edge agent to recognize it is a recovery request. At that point, the single most important step in social recovery happens: the trustee verifying that it is really Alice making the recovery request, and not an impersonator using social engineering.</p> <p>Once the trustee is satisfied with the verification, the edge agent prompts the trustee to perform the next most important step: select the existing connection with Alice so that the trustee edge agent knows which connection is trying to recover. Only the trustee\u2014a human being\u2014can be trusted to make this association.</p> <p>At this point, the edge agent can correlate the old connection to Alice with the new connection to Alice, so it knows which recovery data share to select (see section 10.13). It can then decrypt the recovery data share with the identity owner\u2019s private key, extracts the recovery endpoint, and re-encrypt the recovery data share with the public key of Alice\u2019s new edge agent.</p> <p>Now the trustee\u2019s edge agent is ready to return the recovery data share to Alice\u2019s new cloud agent via the recovery endpoint. The cloud agent forwards it to Alice\u2019s new edge agent. Once Alice\u2019s new edge agent has the required set of recovery data shares, it decrypts and assembles them. It then uses that recovery data to complete the same final steps as offline recovery described in section 10.16.</p>"},{"location":"concepts/0051-dkms/dkms-v4/#11-open-issues-and-future-work","title":"11. Open Issues and Future Work","text":"<ol> <li> <p>DID specification. The DKMS specification has major dependencies on the DID specification which is still in progress at the W3C Credentials Community Group. Although we are not concerned that the resulting specification will not support DKMS requirements, we cannot be specific about certain details of how DKMS will interact with DIDs until that specification is finalized. However the strong market interest in DIDs led the Credentials Community Group to author an extensive DID Use Cases document and submit a Decentralized Identifier Working Group charter to the W3C for consideration as a full Working Group. </p> </li> <li> <p>DID methods. The number of DID methods has grown substantially as shown by the unofficial DID Method Registry maintained by the W3C Credentials Community Group. Because different DID methods may support different levels of assurance about DKMS keys, more work may be required to assess about the role of different ledgers as a decentralized source of truth and the requirements of each ledger for the hosting of DIDs and DID documents.</p> </li> <li> <p>Verifiable credentials interoperability. The W3C Verifiable Claims Working Group is currently preparing its 1.0 Candidate Recommendation. As verifiable credentials mature, we need to say more about how different DKMS wallets and agents from different vendors can support interoperable verifiable credentials, including those with zero-knowledge credentials and proofs. Again, this may need to extend to an adjacent protocol.</p> </li> <li> <p>DKMS wallet and agent portability. As mentioned in section 5.4, this aspect of the DKMS protocol is not fully specified and needs to be addressed in a subsequent version. This area of work is particularly active in the Hyperledger Indy Agent development community. A recent \"connectathon\" hosted by the Sovrin Foundation had 32 developers testing agent-to-agent protocol interoperability among 9 different code bases.</p> </li> <li> <p>Secure elements, TPMs, and TEEs. Since DKMS is highly dependent on secure elements, more work is needed to specify how a device can communicate or verify its own security capabilities or its ability to attest to authentication factors for the identity owner.</p> </li> <li> <p>Biometrics. While they can play a special role in the DKMS architecture because of their ability to intrinsically identify a unique individual, this same quality means a privacy breach of biometric attributes could be disastrous because they may be unrecoverable. So determining the role of biometrics and biometric service providers is a major area of future work.</p> </li> <li> <p>Spam and DDOS attacks. There are several areas where this must be considered, particularly in relation to connection requests (section 10.7).</p> </li> <li> <p>DID phishing. DKMS can only enable security, it cannot by itself prevent a malicious actor or agency sending malicious invitations to form malicious connections that appear to be legitimate connection invitations (section 10.9).</p> </li> <li> <p>Usability testing. Although early research on the usability of DKMS wallets and agents was carried out by BYU Internet Security Research Lab, much more work remains to be done to develop the highly repeatable \"user ceremonies\" necessary for DKMS to succeed in the mass market.</p> </li> </ol>"},{"location":"concepts/0051-dkms/dkms-v4/#12-future-standardization","title":"12. Future Standardization","text":"<p>It is the recommendation of the authors that the work described in this document be carried forward to full Internet standardization. We believe OASIS is a strong candidate for this work due to its hosting of the Key Management Interoperability Protocol (KMIP) at the KMIP Technical Committee since 2010. Please contact the authors if you are interested in contributing to organizing an open standard effort for DKMS.</p>"},{"location":"concepts/0051-dkms/shamir_secret/","title":"Shamir secret API (indy-crypto and indy-sdk)","text":"<p>Objective: <code>indy-crypto</code> exposes the low level API for generating and reconstructing secrets. <code>indy-sdk</code> uses the underlying <code>indy-crypto</code> and exposes an API to shard a JSON message, store the shards and reconstitute the secret.</p>"},{"location":"concepts/0051-dkms/shamir_secret/#indy-crypto","title":"Indy-crypto","text":"<ol> <li><code>shard_secret(secret: bytes, m: u8, n: u8, sign_shares: Option&lt;bool&gt;) -&gt; Result&lt;Vec&lt;Share&gt;, IndyCryptoError&gt;</code>. Splits the bytes of the secret <code>secret</code> in <code>n</code> different shares and <code>m-of-n</code> shares are required to reconstitute the secret. <code>sign_shares</code> if provided, all shards are signed.  </li> <li><code>recover_secret(shards: Vec&lt;Share&gt;, verify_signatures: Option&lt;bool&gt;) -&gt; Result&lt;Vec&lt;u8&gt;, IndyCryptoError&gt;</code>. Recover the secret from the given <code>shards</code>. <code>verify_signatures</code> if given verifies the signatures.</li> </ol>"},{"location":"concepts/0051-dkms/shamir_secret/#indy-sdk","title":"Indy-sdk","text":"<ol> <li><code>shard_JSON(msg: String, m: u8, n: u8, sign_shares: Option&lt;bool&gt;) -&gt; Result&lt;Vec&lt;String&gt;, IndyError&gt;</code> Takes the message as a JSON string and serialises it to bytes and passes it to <code>shard_secret</code> of <code>indy-crypto</code>. The serialisation has to be deterministic, i.e the same JSON should always serialise to same bytes everytime. The resulting <code>Share</code> given by <code>indy-crypto</code> is converted to JSON before returning. </li> <li><code>shard_JSON_with_wallet_data(wallet_handle: i32, msg: String, wallet_keys:Vec&lt;&amp;str&gt;, m: u8, n: u8, sign_shares: Option&lt;bool&gt;) -&gt; Result&lt;Vec&lt;String&gt;, IndyError&gt;</code> Takes the message as a JSON string, updates the JSON with key-values from wallet given by handle <code>wallet_handle</code>, keys present in the vector <code>wallet_keys</code> and passes the resulting JSON to <code>shard_JSON</code>. </li> <li><code>recover_secret(shards: Vec&lt;String&gt;, verify_signatures: Option&lt;bool&gt;) -&gt; Result&lt;String, IndyError&gt;</code> Takes a collection of shards each encoded as JSON, deserialises them into <code>Share</code>s and passes them to <code>recover_secret</code> from <code>indy-crypto</code>. It converts the resulting secret back to JSON before returning it.</li> <li><code>shard_JSON_and_store_shards(wallet_handle: i32, msg: String, m: u8, n: u8, sign_shares: Option&lt;bool&gt;) -&gt; Result&lt;String, IndyError&gt;</code> Shards the given JSON using <code>shard_JSON</code> and store shards as a JSON array (each shard is an object in itself) in the wallet given by <code>wallet_handle</code>. Returns the wallet key used to store the shards.</li> </ol>"},{"location":"concepts/0051-dkms/trustee_protocols/","title":"Trustee Setup Protocol","text":"<p>Objective: Provide the messages and data formats so an identity owner can choose, update, remove trustees and their delegated capabilities.</p>"},{"location":"concepts/0051-dkms/trustee_protocols/#assumptions","title":"Assumptions","text":"<ol> <li>An identity owner selects a connection to become a trustee</li> <li>Trustees can be granted various capabilities by identity owners<ol> <li>Safeguarding a recovery share. This will be the most common</li> <li>Revoke an authorized agent on behalf of an identity owner</li> <li>Provision a new agent on behalf of an identity owner</li> <li>Be an administrator for managing identity owner agents</li> </ol> </li> <li>Trustees agree to any new specified capabilities before any action is taken</li> <li>Trustees will safeguard recovery shares. Their app will encrypt the share and not expose it to anyone else</li> <li>Trustees authenticate out-of-band an identity owner when a recovery event occurs</li> <li>The Trustees' app should only send a recovery share to an identity owner after they have been authenticated</li> <li>All messages will use a standard DIDComm Envelope.</li> </ol>"},{"location":"concepts/0051-dkms/trustee_protocols/#messages-and-structures","title":"Messages and Structures","text":"<p>Messages are formatted as JSON. All binary encodings use base64url. All messages include the following fields:</p> <ol> <li>version \\&lt;string&gt;: The semantic version of the message data format.</li> <li>type \\&lt;string&gt;: The message type.</li> </ol>"},{"location":"concepts/0051-dkms/trustee_protocols/#capabilty_offer","title":"CAPABILTY_OFFER","text":"<p>Informs a connection that the identity owner wishes to make them a trustee. The message includes information about what capabilities the identity owner has chosen to grant a trustee and how long the offer is valid. This message adds the following fields</p> <p>expires \\&lt;string&gt;: 64-bit unsigned big-endian integer. The number of seconds elapsed between January 1, 1970 UTC and the time the offer will expire if no request message is received. This value is purely informative.\\ capabilities \\&lt;list[string]&gt;: A list of capabilities that the trustee will be granted. They can include</p> <ol> <li>RECOVERY_SHARE: The trustee will be given a recovery share</li> <li>REVOKE_AUTHZ: The trustee can revoke agents</li> <li>PROVISION_AUTHZ: The trustee can provision new agents</li> <li>ADMIN_AUTHZ: The trustee is an administrator of agents</li> </ol> <pre><code>{\n  \"version\": \"0.1\",\n  \"type\": \"CAPABILITY_OFFER\",\n  \"capabilities\": [\"RECOVERY_SHARE\", \"REVOKE_AUTHZ\", \"PROVISION_AUTHZ\"]\n  \"expires\": 1517428815\n}\n</code></pre>"},{"location":"concepts/0051-dkms/trustee_protocols/#capabilty_request","title":"CAPABILTY_REQUEST","text":"<p>Sent to an identity owner in response to a TRUSTEE_OFFER message. The message includes includes information for which capabilities the trustee has agreed. This message adds the following fields</p> <p>for_id \\&lt;string&gt;: The nonce sent in the TRUSTEE_OFFER message.\\ capabilities \\&lt;object[string,string]&gt;: A name value object that contains the trustee's response for each privilege.\\ authorizationKeys \\&lt;list[string]&gt;: The public keys that the trustee will use to verify her actions with the authz policy registry on behalf of the identity owner.</p> <pre><code>{\n  \"version\": \"0.1\",\n  \"type\": \"CAPABILITY_REQUEST\",\n  \"authorizationKeys\": [\"Rtna123KPuQWEcxzbNMjkb\"]\n  \"capabilities\": [\"RECOVERY_SHARE\", \"REVOKE_AUTHZ\"]\n}\n</code></pre>"},{"location":"concepts/0051-dkms/trustee_protocols/#capability_response","title":"CAPABILITY_RESPONSE","text":"<p>Sends the identity owner policy address and/or recovery data and metadata to a recovery trustee. A trustee should send a confirmation message that this message was received.</p> <p>address \\&lt;string&gt;: The identity owner's policy address. Only required if the trustee has a key in the authz policy registry.\\ share \\&lt;object&gt;: The actual recovery share data in the format given in the next section. Only required if the trustee has the RECOVERY_SHARE privilege.</p> <pre><code>{\n  \"version\": \"0.1\",\n  \"type\": \"CAPABILITY_RESPONSE\",\n  \"address\": \"b3AFkei98bf3R2s\"\n  \"share\": {\n    ...\n  }\n}\n</code></pre>"},{"location":"concepts/0051-dkms/trustee_protocols/#trust_ping","title":"TRUST_PING","text":"<p>Authenticates a party to the identity owner for out of band communication.</p> <p>challenge \\&lt;object&gt;: A message that a party should respond to so the identity owner can be authenticated. Contains a question field for the other party to answer and a list of valid_responses.</p> <pre><code>{\n  \"version\": \"0.1\",\n  \"type\": \"TRUST_PING\",\n  \"challenge\": {\n    ...\n  }\n}\n</code></pre> <p>challenge will look like the example below but allows for future changes as needed.\\ question \\&lt;string&gt;: The question for the other party to answer.\\ valid_responses \\&lt;list[string]&gt;: A list of valid responses that the party can give in return.</p> <pre><code>{\n    \"question\": \"Are you on a call with CULedger?\",\n    \"valid_responses\": [\"Yes\", \"No\"]\n}\n</code></pre>"},{"location":"concepts/0051-dkms/trustee_protocols/#trust_pong","title":"TRUST_PONG","text":"<p>The response message for the TRUST_PING message.</p> <pre><code>  \"version\": \"0.1\",\n  \"type\": \"TRUST_PONG\",\n  \"answer\": {\n    \"answerValue\": \"Yes\"\n  }\n</code></pre>"},{"location":"concepts/0051-dkms/trustee_protocols/#key_heartbeat_request","title":"KEY_HEARTBEAT_REQUEST","text":"<p>Future_Work: Verifies a trustee/agent has and is using the public keys that were given to the identity owner. These keys</p> <p>authorizationKeys \\&lt;list[string]&gt;: Public keys the identity owner knows that belong to the trustee/agent.</p> <pre><code>{\n  \"version\": \"0.1\",\n  \"type\": \"KEY_HEARTBEAT_REQUEST\",\n  \"authorizationKeys\": [\"Rtna123KPuQWEcxzbNMjkb\"]\n}\n</code></pre>"},{"location":"concepts/0051-dkms/trustee_protocols/#key_heartbeat_response","title":"KEY_HEARTBEAT_RESPONSE","text":"<p>Future_Work: The updated keys sent back from the trustee/agent </p>"},{"location":"concepts/0051-dkms/trustee_protocols/#recovery_share_response","title":"RECOVERY_SHARE_RESPONSE","text":"<p>Future_Work: After an identity owner receives a challenge from a trustee, an application prompts her to complete the challenge. This message contains her response.</p> <p>for_id \\&lt;string&gt;: The nonce sent in the RECOVERY_SHARE_CHALLENGE message.\\ response \\&lt;object&gt;: The response from the identity owner.</p> <pre><code>{\n  \"version\": \"0.1\",\n  \"type\": \"RECOVERY_SHARE_RESPONSE\",\n  \"response\": {\n    ...\n  }\n}\n</code></pre> <p>response will look like the example below but allows for future changes as needed.</p> <pre><code>{\n  \"pin\": \"3qA5h7\"\n}\n</code></pre>"},{"location":"concepts/0051-dkms/trustee_protocols/#recovery-share-data-structure","title":"Recovery Share Data Structure","text":"<p>Recovery shares are formatted in JSON with the following fields:</p> <ol> <li>version \\&lt;string&gt;: The semantic version of the recovery share data format.</li> <li>source_did: The identity owner DID that sent this share to the trustee</li> <li>tag \\&lt;string&gt;: A value used to verify that all the shares are for the same secret. The identity owner compares this to every share to make sure they are the same.</li> <li>shareValue \\&lt;string&gt;: The share binary value.</li> <li>hint \\&lt;object&gt;: Hint data that contains the following fields:<ol> <li>trustees \\&lt;list[string]&gt;: A list of all the recovery trustee names associated with this share. These names are only significant to the identity owner. Helps to aid in recovery by providing some metadata for the identity owner and the application.</li> <li>threshold \\&lt;integer&gt;: The minimum number of shares needed to recover the key. Helps to aid in recovery by providing some metadata for the identity owner and the application.</li> </ol> </li> </ol> <pre><code>{\n  \"version\": \"0.1\",\n  \"source_did\": \"did:sov:asbdfa32135\"\n  \"tag\": \"ze4152Bsxo90\",\n  \"shareValue\": \"abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ123456789\"\n  \"hint\": {\n    \"theshold\": 3,\n    \"trustees\": [\"Mike L\", \"Lovesh\", \"Corin\", \"Devin\", \"Drummond\"]\n  }\n}\n</code></pre>"},{"location":"concepts/0074-didcomm-best-practices/","title":"Aries RFC 0074: DIDComm Best Practices","text":"<ul> <li>Authors: Devin Fisher, Daniel Hardman</li> <li>Status: PROPOSED</li> <li>Since: 2019-06-10</li> <li>Status Note: This captures some tribal knowledge from the Indy community. However, it is by no means uniformly accepted inside that group, and it has never been shared in a larger context. Therefore, the RFC is currently fodder for discussion.</li> <li>Start Date: 2019-01-15</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0074-didcomm-best-practices/#summary","title":"Summary","text":"<p>Identifies some conventions that are generally accepted as best practice by developers of DIDComm software. Explains their rationale. This document is a recommendation, not normative.</p>"},{"location":"concepts/0074-didcomm-best-practices/#motivation","title":"Motivation","text":"<p>By design, DIDComm architecture is extremely flexible. Besides adapting well to many platforms, programming languages, and idioms, this let us leave matters of implementation style in the hands of developers. We don't want framework police trying to enforce rigid paradigms.</p> <p>However, some best practices are worth documenting. There is tribal knowledge in the community that represents battle scars. Collaboration is fostered if learning curves don't have to proliferate. Therefore, we offer the following guidelines.</p>"},{"location":"concepts/0074-didcomm-best-practices/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0074-didcomm-best-practices/#normative-language","title":"Normative language","text":"<p>RFCs about protocols and DIDComm behaviors follow commonly understood conventions about normative language, including words like \"MUST\", \"SHOULD\", and \"MAY\". These conventions are documented in IETF's RFC 2119. Existing documents that were written before we clarified our intention to follow these conventions are grandfathered but should be updated to conform.</p>"},{"location":"concepts/0074-didcomm-best-practices/#names","title":"Names","text":"<p>Names show up in lots of places in our work. We name RFCs, ../../concepts defined in those RFCs, protocols, message types, keys in JSON, and much more.</p> <p>The two most important best practices with names are:</p> <ul> <li>Pick descriptive and accurate names. Thoughtfully chosen names can save enormous amounts of commenting and documentation.</li> <li>Be consistent. Particularly within an RFC and especially within the JSON for a set of related messages.</li> <li>For example, don't mix snake_case and other conventions within a single family of DIDComm messages.</li> </ul> <p>These are so common-sense that we won't argue them. But a few other points are worthy of comment.</p>"},{"location":"concepts/0074-didcomm-best-practices/#snake_case-and-variants","title":"snake_case and variants","text":"<p>Nearly all code uses multi-word tokens as names. Different programming ecosystems have different conventions for managing them: <code>camelCase</code>, <code>TitleCase</code>, <code>snake_case</code>, <code>kabob-case</code>, <code>SHOUT_CASE</code>, etc. We want to avoid a religious debate about these conventions, and we want to leave developers the freedom to choose their own styles. However, we also want to avoid random variation that makes it hard to predict the correct form. Therefore, we try to stay idiomatic in the language we're using, and many of our tokens are defined to compare case-insensitive with punctuation omitted, so the differences melt away. This is the case with protocol names and message type names, for example; it means that you should interpret \"TicTacToe\" and \"tic-tac-toe\" and \"ticTacToe\" as being the same protocol. If you are writing a java function for it, by all means use \"ticTacToe\"; if you are writing CSS, by all means use \"tic-tac-toe\".</p> <p>The community tries to use <code>snake_case</code> in JSON key names, even though camelCase is slightly more common. This is not a hard-and-fast rule; in particular, a few constructs from DID Docs leak into DIDComm, and these use the camelCase style that those specs expect. However, it was felt that snake_case was mildly preferable because it didn't raise the questions about acronyms that camelCase does (is it \"zeroOutRAMAlgorithm\", \"zeroOutRamAlgorithm\", or \"zeroOutRAMalgorithm\"?).</p> <p>The main rule to follow with respect to case is: Use the same convention as the rest of the code around you, and in JSON that's intended to be interoperable, use snake_case unless you have a good reason not to. Definitely use the same case conventions as the other keys in the same JSON schema.</p>"},{"location":"concepts/0074-didcomm-best-practices/#pluralization","title":"Pluralization","text":"<p>The names of JSON items that represent arrays should be pluralized whenever possible, while singleton items should not.</p>"},{"location":"concepts/0074-didcomm-best-practices/#terminology-and-notation","title":"Terminology and Notation","text":"<p>Use terms correctly and consistently.</p> <p>The Sovrin Glossary V2 is considered a definitive source of terms. We will probably move it over to Aries at some point as an officially sponsored artifact of this group. RFC 0006: SSI Notation is also a definitive reference.</p> <p>RFCs in general should make every effort to define new terms only when needed, to be clear about the ../../concepts they are labeling, and use prior work consistently. If you find a misalignment in the terminology or notation used by RFCs, please open a github issue.</p>"},{"location":"concepts/0074-didcomm-best-practices/#terseness-and-abbreviations","title":"Terseness and abbreviations","text":"<p>We like obvious abbreviations like \"ipaddr\" and \"inet\" and \"doc\" and \"conn\". We also formally define abbreviations or acronyms for terms and then use the short forms as appropriate.</p> <p>However, we don't value terseness so much that we are willing to give up clarity. Abbreviating \"wallet\" as \"wal\" or \"agent\" as \"ag\" is quirky and discouraged.</p>"},{"location":"concepts/0074-didcomm-best-practices/#rfc-naming","title":"RFC naming","text":"<p>RFCs that define a protocol should be named in the form <code>&lt;do something&gt;-protocol</code>, where <code>&lt;do-something&gt;</code> is a verb phrase like <code>issue-credential</code>, or possibly a noun phrase like <code>did-exchange</code>--something that makes the theme of the protocol obvious. The intent is to be clear; a protocol name like \"connection\" is too vague because you can do lots of things with connections.</p> <p>Protocol RFCs need to be versioned thoughtfully. However, we do not put version numbers in a protocl RFC's folder name. Rather, the RFC folder contains all versions of the protocol, with the latest version documented in README.md, and earlier versions documented in subdocs named according to version, as in <code>version-0.9.md</code> or similar. The main README.md should contain a section of links to previous versions. This allows the most natural permalink for a protocol to be a link to the current version, but it also allows us to link to previous versions explicitly if we need to.</p> <p>RFCs that define a decorator should be named in the form <code>&lt;decorator name&gt;-decorator</code>, as in <code>timing-decorator</code> or <code>trace-decorator</code>.</p>"},{"location":"concepts/0074-didcomm-best-practices/#json","title":"JSON","text":"<p>Json is a very flexible data format. This can be nice, but it can also lead to data modeled in ways that cause a lot of bother for some programming languages. Therefore, we recommend the following choices.</p>"},{"location":"concepts/0074-didcomm-best-practices/#no-variable-type-arrays","title":"No Variable Type Arrays","text":"<p>Every element in an array should be the same data type. This is helpful for statically and strongly typed programming languages that want arrays of something more specific than a base Object class. A violating example:</p> <p><pre><code>[\n   {\n    \"id\":\"324234\",\n    \"data\":\"1/3/2232\"\n   },\n   {\n    \"x_pos\":3251,\n    \"y_pos\":11,\n    \"z_pos\":55\n   }\n]\n</code></pre> Notice that the first object and the second object in the array have no structure in common.</p> <p>Although the benefit of this convention is especially obvious for some programming languages,  it is helpful in all languages to keep parsing logic predictable and reducing branching  cod epaths.</p>"},{"location":"concepts/0074-didcomm-best-practices/#dont-treat-objects-as-associative-arrays","title":"Don't Treat Objects as Associative Arrays","text":"<p>Many loosely typed programming languages conflate the concept of an associative array (dict, map) with the concept of object. In python, for example, an object is just a <code>dict</code> with some syntactic sugar, and python's JSON serialization handles the two interchangeably when serializing.</p> <p>This makes it tempting to do the same thing in JSON. An unhappy example:</p> <pre><code>{\n    \"usage\": {\n        \"194.52.101.254\": 34,\n        \"73.183.146.222\": 55,\n        \"149.233.52.170\": 349\n    }\n}\n</code></pre> <p>Notice that the keys of the <code>usage</code> object are unbounded; as the set of IP addresses grows, the set of keys in <code>usage</code> grows as well. JSON is an \"object notation\", and <code>{...}</code> is a JSON object -- NOT a JSON associative array--but this type of modeling ignores that. If we model data this way, we'll end up with an \"object\" that could have dozens, hundreds, thousands, or millions of keys with identical semantics but different names. That's not how objects are supposed to work.</p> <p>Note as well that the keys here, such as \"192.52.101.254\", are not appropriate identifiers in most programming languages. This means that unless deserialization code maps the keys to keys in an associative array (dict, map), it will not be able to handle the data at all. Also, this way to model the data assumes that we know how lookups will be done (in this case, ipaddr\u2192number); it doesn't leave any flexibility for other access patterns.</p> <p>A better way to model this type of data is as a JSON array, where each item in the array is a tuple of known field types with known field names. This is only slightly more verbose. It allows deserialization to map to one or more lookup data structures per preference, and is handled equally well in strongly, statically typed programming languages and in loosely typed languages:</p> <pre><code>{\n    \"usage\": [\n        { \"ip\": \"194.52.101.254\", \"num\": 34 },\n        { \"ip\": \"73.183.146.222\", \"num\": 55 },\n        { \"ip\": \"149.233.52.170\", \"num\": 349 }\n    ]\n}\n</code></pre>"},{"location":"concepts/0074-didcomm-best-practices/#numeric-field-properties","title":"Numeric Field Properties","text":"<p>Json numeric fields are very flexible. As wikipedia notes in its discussion about JSON numeric primitives:</p> <pre><code>Number: a signed decimal number that may contain a fractional part and may use exponential\nE notation, but cannot include non-numbers such as NaN. The format makes no distinction\nbetween integer and floating-point. JavaScript uses a double-precision floating-point format\nfor all its numeric values, but other languages implementing JSON may encode numbers\ndifferently.\n</code></pre> <p>Knowing that something is a number may be enough in javascript, but in many other programming languages, more clarity is helpful or even required. If the intent is for the number to be a non-negative or positive-only integer, say so when your field is defined in a protocol. If you know the valid range, give it. Specify whether the field is nullable.</p> <p>Per the first guideline above about names, name your numeric fields in a way that makes it clear they are numbers: \"references\" is a bad name in this respect (could be a hyperlink, an array, a string, etc), whereas \"reference_count\" or \"num_of_refs\" is much better.</p>"},{"location":"concepts/0074-didcomm-best-practices/#date-time-conventions","title":"Date Time Conventions","text":"<p>Representing date- and time-related data in JSON is a source of huge variation, since the datatype for the data isn't obvious even before it's serialized. A quick survey of source code across industries and geos shows that dates, times, and timestamps are handled with great inconsistency outside JSON as well. Some common storage types include:</p> <ul> <li>32-bit (signed or unsigned) seconds since epoch (Jan 1, 1970 and Jan 1, 1980 are both used)</li> <li>64-bit 100-nanosecond intervals since Jan 1, 1601</li> <li>Floating-point days and fractions of days since Dec 30, 1899</li> <li>Whole integer days since Jan 1, 1900</li> <li>Floating point scientific time (billions of years since big bang)</li> <li>clock ticks since OS booted</li> <li>milliseconds since OS booted</li> </ul> <p>Of course, many of these datatypes have special rules about their relationship to timezones, which further complicates matters. And timezone handling is notoriously inconsistent, all on its own.</p> <p>Some common names for the fields that store these times include:</p> <ul> <li>&lt;something&gt;Time</li> <li>&lt;something&gt;Date</li> <li>&lt;something&gt;Timestamp</li> <li>&lt;something&gt;Millis or * &lt;something&gt;Ms or &lt;something&gt;Secs</li> </ul> <p>The intent of this RFC is NOT to eliminate all diversity. There are good reasons why these different datatypes exist. However, we would like DIDComm messages to use broadly understood naming conventions that clearly communicate date- and time-related semantics, so that where there is diversity, it's because of different use cases, not just chaos.</p> <p>By convention, DIDComm field suffixes communicate datatype and semantics for date- and time-related ideas, as described below. As we've stressed before, conventions are recommendations only. However:</p> <ol> <li> <p>It is strongly preferred that developers not ignore these perfectly usable conventions unless they have a good reason (e.g., a need to measure the age of the universe in seconds in scientific notation, or a need for ancient dates in a genealogy or archeology use case).</p> </li> <li> <p>Developers should never contradict the conventions. That is, if a developer sees a date- or time-related field that appears to match what's documented here, the assumption of alignment ought to be safe. Divergence should use new conventions, not redefine these.</p> </li> </ol> <p>Field names like \"expires\" or \"lastmod\" are deprecated, because they don't say enough about what to expect from the values. (Is \"expires\" a boolean? Or is it a date/time? If the latter, what is its granularity and format?)</p>"},{"location":"concepts/0074-didcomm-best-practices/#_date","title":"<code>_date</code>","text":"<p>Used for fields that have only date precision, no time component. For example, <code>birth_date</code> or <code>expiration_date</code>. Such fields should be represented as strings in ISO 8601 format (yyyy-mm-dd). They should contain a timezone indicator if and only if it's meaningful (see Timezone Offset Notation).</p>"},{"location":"concepts/0074-didcomm-best-practices/#_time","title":"<code>_time</code>","text":"<p>Used for fields that identify a moment with both date and time precision. For example, <code>arrival_time</code> might communicate when a train reaches the station. The datatype of such fields is a string in ISO 8601 format (yyyy-mm-ddTHH:MM:SS.xxx...) using the Gregorian calendar, and the timezone defaults to UTC. However: * Precision can vary from minute to microsecond or greater. * It is strongly recommended to use the \"Z\" suffix to make UTC   explicit: \"2018-05-27 18:22Z\" * The capital 'T' that separates date from time in ISO 8601 can freely vary with a space. (Many datetime formatters support this variation, for greater readability.) * If local time is needed, Timezone Offset Notation is used.</p>"},{"location":"concepts/0074-didcomm-best-practices/#_sched","title":"<code>_sched</code>","text":"<p>Holds a string that expresses appointment-style schedules such as \"the first Thursday of each month, at 7 pm\". The format of these strings is recommended to follow ISO 8601's Repeating Intervals notation where possible. Otherwise, the format of such strings may vary; the suffix doesn't stipulate a single format, but just the semantic commonality of scheduling.</p>"},{"location":"concepts/0074-didcomm-best-practices/#_clock","title":"<code>_clock</code>","text":"<p>Describes wall time without reference to a date, as in <code>13:57</code>. Uses ISO 8601 formatted strings and a 24-hour cycle, not AM/PM.</p>"},{"location":"concepts/0074-didcomm-best-practices/#_t","title":"<code>_t</code>","text":"<p>Used just like <code>_time</code>, but for unsigned integer seconds since Jan 1, 1970 (with no opinion about whether it's a 32-bit or 64-bit value). Thus, a field that captures a last modified timestamp for a file, as number of seconds since Jan 1, 1970 would be <code>lastmod_t</code>. This suffix was chosen for resonance with Posix's <code>time_t</code> datatype, which has similar semantics.</p>"},{"location":"concepts/0074-didcomm-best-practices/#_tt","title":"<code>_tt</code>","text":"<p>Used just like <code>_time</code> and <code>_t</code>, but for 100-nanosecond intervals since Jan 1, 1601. This matches the semantics of the Windows FILETIME datatype.</p>"},{"location":"concepts/0074-didcomm-best-practices/#_sec-or-subunits-of-seconds-_milli-_micro-_nano","title":"<code>_sec</code> or subunits of seconds (<code>_milli</code>, <code>_micro</code>, <code>_nano</code>)","text":"<p>Used for fields that tell how long something took. For example, a field describing how long a system waited before retry might be named <code>retry_milli</code>. Normally, this field would be represented as an unsigned positive integer.</p>"},{"location":"concepts/0074-didcomm-best-practices/#_dur","title":"<code>_dur</code>","text":"<p>Tells duration (elapsed time) in friendly, calendar based units as a string, using the conventions of ISO 8601's Duration concept. <code>Y</code> = year, <code>M</code> = month, <code>W</code> = week, <code>D</code> = day, <code>H</code> = hour, <code>M</code> = minute, <code>S</code> = second: \"P3Y2M5D11H\" = 3 years, 2 months, 5 days, 11 hours. 'M' can be preceded by 'T' to resolve ambiguity between months and minutes: \"PT1M3S\" = 1 minute, 3 seconds, whereas \"P1M3S\" = 1 month, 3 seconds.</p>"},{"location":"concepts/0074-didcomm-best-practices/#_when","title":"<code>_when</code>","text":"<p>For vague or imprecise dates and date ranges. Fragments of ISO 8601 are preferred, as in \"1939-12\" for \"December 1939\". The token \"to\" is reserved for inclusive ranges, and the token \"circa\" is reserved to make fuzziness explicit, with \"CE\" and \"BCE\" also reserved. Thus, Cleopatra's <code>birth_when</code> might be \"circa 30 BCE\", and the timing of the Industrial Revolution might have a <code>happened_when</code> of \"circa 1760 to 1840\".</p>"},{"location":"concepts/0074-didcomm-best-practices/#timezone-offset-notation","title":"Timezone Offset Notation","text":"<p>Most timestamping can and should be done in UTC, and should use the \"Z\" suffix to make the Zero/Zulu/UTC timezone explicit.</p> <p>However, sometimes the local time and the UTC time for an event are both of interest. This is common with news events that are tied to a geo, as with the time that an earthquake is felt at its epicenter. When this is the case, rather than use two fields, it is recommended to use timezone offset notation (the \"+0800\" in \"2018-05-27T18:22+08:00\"). Except for the \"Z\" suffix of UTC, timezone name notation is deprecated, because timezones can change their definitions according to the whim of local lawmakers, and because resolving the names requires expensive dictionary lookup. Note that this convention is exactly how ISO 8601 handles the timezone issue.</p>"},{"location":"concepts/0074-didcomm-best-practices/#blobs","title":"Blobs","text":"<p>In general, blobs are encoded as base64url strings in DIDComm.</p>"},{"location":"concepts/0074-didcomm-best-practices/#unicode","title":"Unicode","text":"<p>UTF-8 is our standard way to represent unicode strings in JSON and all other contexts. For casual definition, this is sufficient detail.</p> <p>For advanced use cases, it may be necessary to understand subtleties like Unicode normalization forms and canonical equivalence. We generally assume that we can compare strings for equality and sort order using a simple binary algorithm. This is approximately but (in some corner cases) not exactly the same as assuming that text is in NFC normalization form with no case folding expectations and no extraneous surrogate pairs. Where more precision is required, the definition of DIDComm message fields should provide it.</p>"},{"location":"concepts/0074-didcomm-best-practices/#hyperlinks","title":"Hyperlinks","text":"<p>This repo is designed to be browsed as HTML. Browsing can be done directly through github, but we may publish the content using Github Pages and/or ReadTheDocs. As a result, some hyperlink hygiene is observed to make the content as useful as possible:</p> <ul> <li>Hyperlinks (both internal to the repo and external to it) must not be broken.</li> <li>Fragments like <code>#heading-title</code> must correctly reference a real markdown heading.</li> <li>Hyperlinks to an RFC should point to the RFC's README.md rather than to a folder with (possibly) many documents.</li> <li>Hyperlinks from one RFC to another should be in relative form (<code>../../features/my-rfc/README.md</code>), not in absolute form (<code>../../features/my-rfc/README.md</code>) or external form (<code>https://github.com/hyperledger/aries-rfcs/blob/main../../features/my-rfc/README.md</code>). This lets us move or embed the content, and it prevents branch names from cluttering the hyperlink.</li> </ul> <p>These rules are enforced by a unit test that runs <code>code/check_links.py</code>. To run it, go to the root of the repo and run <code>pytest code</code> -- or simply invoke the <code>check_links</code> script directly. Normally, <code>check_links</code> does not test external hyperlinks on the web, because it is too time-consuming; if you want that check, add <code>--full</code> as a command-line argument.</p>"},{"location":"concepts/0074-didcomm-best-practices/#security-considerations","title":"Security Considerations","text":""},{"location":"concepts/0074-didcomm-best-practices/#replay-attacks","title":"Replay attacks","text":"<p>It should be noted that when defining a protocol that has domain specific requirements around preventing replay attacks an <code>@id</code> property SHOULD be required. Given the <code>@id</code> field is most commonly set to be a UUID, it usually provides sufficient randomness that a nonce would in preventing replay attacks. This means that sufficient care will be needed in processing of the <code>@id</code> field however, to make sure the <code>@id</code> field hasn't been used before. In some cases, nonces require being unpredictable as well. In this case, greater review should be taken as to how the <code>@id</code> field should be used in the domain specific protocol. Additionally, in the event where the <code>@id</code> field is not adequate, it's recommended that an additional <code>nonce</code> field be required by the domain specific protocol specification.</p>"},{"location":"concepts/0074-didcomm-best-practices/#reference","title":"Reference","text":"<ul> <li>Discussion of date and time datatypes on Wikipedia</li> <li>ISO 8601</li> <li>Unicode TR 15 on Normalization Forms</li> <li>DIDComm's stance on JSON-LD Compatibility</li> <li>DIDComm localization</li> </ul>"},{"location":"concepts/0074-didcomm-best-practices/#drawbacks","title":"Drawbacks","text":"<p>The main concern with this type of RFC is that it will produce more heat than light -- that is, that developers will debate minutiae instead of getting stuff done. We hope that the conventions here feel reasonable and lightweight enough to avoid that.</p>"},{"location":"concepts/0074-didcomm-best-practices/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>If we weren't using JSON, but rather something like ProtoBuf or MsgPack, datatype handling would probably   require less conventions, but we would still have a similar need.</li> <li>JSON-LD allows some forms of datatype coercion,   but not enough to satisfy all our requirements. It is also considered overly heavy in terms of   parsing and validation dependencies. See DIDComm's stance on JSON-LD Compatibility</li> </ul>"},{"location":"concepts/0074-didcomm-best-practices/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What other conventions do we need?</li> </ul>"},{"location":"concepts/0074-didcomm-best-practices/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0094-cross-domain-messaging/","title":"Aries RFC 0094: Cross-Domain Messaging","text":"<ul> <li>Authors: Stephen Curran</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Socialized and broadly understood in other conceptual RFCs about routing. </li> <li>Supersedes: 0022-Cross-Domain-Messaging</li> <li>Start Date: 2018-08-13</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0094-cross-domain-messaging/#summary","title":"Summary","text":"<p>There are two layers of messages that combine to enable interoperable self-sovereign identity DIDcomm (formerly called Agent-to-Agent) communication. At the highest level are Agent Messages - messages sent between Identities to accomplish some shared goal. For example, establishing a connection between identities, issuing a Verifiable Credential from an Issuer to a Holder or even the simple delivery of a text Instant Message from one person to another. Agent Messages are delivered via the second, lower layer of messaging - encryption envelopes. An encryption envelope is a wrapper (envelope) around an Agent Message to enable the secure delivery of a message from one Agent directly to another Agent. An Agent Message going from its Sender to its Receiver may be passed through a number of Agents, and an encryption envelope is used for each hop of the journey.</p> <p>This RFC addresses Cross Domain messaging to enable interoperability. This is one of a series of related RFCs that address interoperability, including DIDDoc Conventions, Agent Messages and Encryption Envelope. Those RFCs should be considered together in understanding DIDcomm messaging.</p> <p>In order to send a message from one Identity to another, the sending Identity must know something about the Receiver's domain - the Receiver's configuration of Agents. This RFC outlines how a domain MUST present itself to enable the Sender to know enough to be able to send a message to an Agent in the domain.  In support of that, a DIDcomm protocol (currently consisting of just one Message Type) is introduced to route messages through a network of Agents in both the Sender and Receiver's domain. This RFC provides the specification of the \"Forward\" Agent Message Type - an envelope that indicates the destination of a message without revealing anything about the message.</p> <p>The goal of this RFC is to define the rules that domains MUST follow to enable the delivery of Agent messages from a Sending Agent to a Receiver Agent in a secure and privacy-preserving manner.</p>"},{"location":"concepts/0094-cross-domain-messaging/#motivation","title":"Motivation","text":"<p>The purpose of this RFC and its related RFCs is to define a layered messaging protocol such that we can ignore the delivery of messages as we discuss the much richer Agent Messaging types and interactions. That is, we can assume that there is no need to include in an Agent message anything about how to route the message to the Receiver - it just magically happens. Alice (via her App Agent) sends a message to Bob, and (because of implementations based on this series of RFCs) we can ignore how the actual message got to Bob's App Agent.</p> <p>Put another way - these RFCs are about envelopes. They define a way to put a message - any message - into an envelope, put it into an outbound mailbox and have it magically appear in the Receiver's inbound mailbox in a secure and privacy-preserving manner. Once we have that, we can focus on letters and not how letters are sent.</p> <p>Most importantly for Agent to Agent interoperability, this RFC clearly defines the assumptions necessary to deliver a message from one domain to another - e.g. what exactly does Alice have to know about Bob's domain to send Bob a message?</p>"},{"location":"concepts/0094-cross-domain-messaging/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0094-cross-domain-messaging/#core-messaging-goals","title":"Core Messaging Goals","text":"<p>These are vital design goals for this RFC:</p> <ol> <li>Sender Encapsulation: We SHOULD minimize what the Receiver has to know about the domain (routing tree or agent infrastructure) of the Sender in order for them to communicate.</li> <li>Receiver Encapsulation: We SHOULD minimize what the Sender has to know about the domain (routing tree or agent infrastructure) of the Receiver in order for them to communicate.</li> <li>Independent Keys: Private signing keys SHOULD NOT be shared between agents; each agent SHOULD be separately identifiable for accounting and authorization/revocation purposes.</li> <li>Need To Know Information Sharing: Information made available to intermediary agents between the Sender and Receiver SHOULD be minimized to what is needed to perform the agent's role in the process.</li> </ol>"},{"location":"concepts/0094-cross-domain-messaging/#assumptions","title":"Assumptions","text":"<p>The following are assumptions upon which this RFC is predicated.</p>"},{"location":"concepts/0094-cross-domain-messaging/#terminology","title":"Terminology","text":"<p>The following terms are used in this RFC with the following meanings:</p> <ul> <li>Domain - a set of Agents collaborating on behalf of an Identity</li> <li>It's assumed that the Agents of a Domain were developed by a single vendor and so MAY have implementation-specific mechanisms for tracking extra information about one another.</li> <li>An example of two Domains is provided in the image below.</li> <li>Edge Agents - the Agents involved in sending (creating) and receiving (processing) an Agent Message</li> <li>Sender - the Agent sending an original Agent Message</li> <li>Receiver - the Agent intended to receive an Agent Message from the Sender</li> <li>Note: A message MAY pass through many Agents between the Sender and Receiver</li> <li>Domain Endpoint - a physical endpoint for messages into domains that MUST be assumed to be shared across many Identities</li> <li>Shared by many identities (e.g. https://endpoint.agentsRus.com)</li> <li>Agency - the handler for messages sent to the Domain Endpoint.</li> <li>Mediators - agents explicitly known to the sender as part of routing messages to a Receiver.</li> <li>DID - reference to the literal Decentralized ID text</li> <li>e.g. did:sov:1234abcd</li> <li>DID#keyname - reference to the DID appended with \"#\" and a specific key from the DIDDoc</li> <li>e.g. did:sov:1234abcd#1 references key \"1\" of the \"did:sov:1234abcd\" DIDDoc.</li> <li>Note: The #keyname is NOT the actual Public Key - it's a reference to an entry in the DIDDoc that contains the Public Key.</li> </ul>"},{"location":"concepts/0094-cross-domain-messaging/#diddoc","title":"DIDDoc","text":"<p>The term \"DIDDoc\" is used in this RFC as it is defined in the DID Specification:</p> <ul> <li>a collection of public keys and endpoints,</li> <li>controlled by an identity,</li> <li>associated with a DID, and</li> <li>used for a relationship.</li> </ul> <p>A DID can be resolved to get its corresponding DIDDoc by any Agent that needs access to the DIDDoc. This is true whether talking about a DID on a Public Ledger, or a pairwise DID (using the did:peer method) persisted only to the parties of the relationship. In the case of pairwise DIDs, it's the (implementation specific) domain's responsibility to ensure such resolution is available to all Agents requiring it within the domain.</p>"},{"location":"concepts/0094-cross-domain-messaging/#messages-are-private","title":"Messages are Private","text":"<p>Agent Messages sent from a Sender to a Receiver SHOULD be private. That is, the Sender SHOULD encrypt the message with a public key for the Receiver. Any agent in between the Sender and Receiver will know only to whom the message is intended (by DID and possibly keyname within the DID), not anything about the message.</p>"},{"location":"concepts/0094-cross-domain-messaging/#the-sender-knows-the-receiver","title":"The Sender Knows The Receiver","text":"<p>This RFC assumes that the Sender knows the Receiver's DID and, within the DIDDoc for that DID, the keyname to use for the Receiver's Agent. How the Sender knows the DID and keyname to send the message is not defined within this RFC - that is a higher level concern.</p> <p>The Receiver's DID MAY be a public or pairwise DID, and MAY be on a Public Ledger or only shared between the parties of the relationship.</p>"},{"location":"concepts/0094-cross-domain-messaging/#example-domain-and-diddoc","title":"Example: Domain and DIDDoc","text":"<p>The following is an example of an arbitrary pair of domains that will be helpful in defining the requirements in this RFC.</p> <p></p> <p>In the diagram above:</p> <ul> <li>Alice has</li> <li>1 Edge Agent - \"1\"</li> <li>1 Routing Agent - \"2\"</li> <li>1 Domain Endpoint - \"8\"</li> <li>Bob has</li> <li>3 Edge Agents - \"4\", \"5\" and \"6\"<ul> <li>\"6\" is an Edge Agent in the cloud, \"4\" and \"5\" are physical devices.</li> </ul> </li> <li>1 Routing Agent - \"3\"</li> <li>1 Domain Endpoint - \"9\"</li> </ul>"},{"location":"concepts/0094-cross-domain-messaging/#bobs-did-for-his-relationship-with-alice","title":"Bob's DID for his Relationship with Alice","text":"<p>Bob\u2019s domain has 3 devices he uses for processing messages - two phones (4 and 5) and a cloud-based agent (6). However, in Bob's relationship with Alice, he ONLY uses one phone (4) and the cloud-based agent (6). Thus the key for device 5 is left out of the DIDDoc (see below).</p> <p>Note that the keyname for the Routing Agent (3) is called \"routing\". This is an example of the kind of convention needed to allow the Sender's agents to know the keys for Agents with a designated role in the receiving domain - as defined in the <code>DIDDoc Conventions</code> RFC.</p> <pre><code>{\n  \"@context\": \"https://w3id.org/did/v1\",\n  \"id\": \"did:sov:1234abcd\",\n  \"publicKey\": [\n    {\"id\": \"routing\", \"type\": \"RsaVerificationKey2018\",  \"owner\": \"did:sov:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC X\u2026\"},\n    {\"id\": \"4\", \"type\": \"RsaVerificationKey2018\",  \"owner\": \"did:sov:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC 9\u2026\"},\n    {\"id\": \"6\", \"type\": \"RsaVerificationKey2018\",  \"owner\": \"did:sov:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC A\u2026\"}\n  ],\n  \"authentication\": [\n    {\"type\": \"RsaSignatureAuthentication2018\", \"publicKey\": \"did:sov:1234abcd#4\"}\n  ],\n  \"service\": [\n    {\n      \"id\": \"did:example:123456789abcdefghi;did-communication\",\n      \"type\": \"did-communication\",\n      \"priority\" : 0,\n      \"recipientKeys\" : [ \"did:example:1234abcd#4\" ],\n      \"routingKeys\" : [ \"did:example:1234abcd#3\" ],\n      \"serviceEndpoint\" : \"did:example:xd45fr567794lrzti67;did-communication\"\n    }\n  ]\n}\n</code></pre> <p>For the purposes of this discussion we are defining the message flow to be:</p> <p>1 \u2192 2 \u2192 8 \u2192 9 \u2192 3 \u2192 4</p> <p>However, that flow is arbitrary and only one hop is actually required:</p> <ul> <li>1 is the Sender in this case and so must send the first message.</li> <li>4 is the Receiver in this case and so must receive the message.</li> </ul>"},{"location":"concepts/0094-cross-domain-messaging/#encryption-envelopes","title":"Encryption Envelopes","text":"<p>An encryption envelope is used to transport any Agent Message from one Agent directly to another. In our example message flow above, there are five encryption envelopes sent, one for each hop in the flow. The separate Encryption Envelope RFC covers those details.</p>"},{"location":"concepts/0094-cross-domain-messaging/#agent-message-format","title":"Agent Message Format","text":"<p>An Agent Message defines the format of messages processed by Agents. Details about the general form of Agent Messages can be found in the Agent Messages RFC.</p> <p>This RFC specifies (below) the \"Forward\" message type, a part of the \"Routing\" family of Agent Messages.</p>"},{"location":"concepts/0094-cross-domain-messaging/#did-diddoc-and-routing","title":"DID, DIDDoc and Routing","text":"<p>A DID owned by the Receiver is resolvable by the Sender as a DIDDoc using either a Public Ledger or using pairwise DIDs based on the <code>did:peer</code> method. The related DIDcomm DIDDoc Conventions RFC defines the required contents of a DIDDoc created by the receiving entity. Notably, the DIDDoc given to the Sender by the Receiver specifies the required routing of the message through an optional set of mediators.</p>"},{"location":"concepts/0094-cross-domain-messaging/#cross-domain-interoperability","title":"Cross Domain Interoperability","text":"<p>A key goal for interoperability is that we want other domains to know just enough about the configuration of a domain to which they are delivering a message, but no more. The following walks through those minimum requirements.</p>"},{"location":"concepts/0094-cross-domain-messaging/#required-the-did-and-diddoc","title":"Required: The DID and DIDDoc","text":"<p>As noted above, the Sender of an Agent to Agent Message has the DID of the Receiver, and knows the key(s) from the DIDDoc to use for the Receiver's Agent(s).</p> <p>Example: Alice wants to send a message from her phone (1) to Bob's phone (4). She has Bob's B:did@A:B, the DID/DIDDoc Bob created and gave to Alice to use for their relationship. Alice created A:did@A:B and gave that to Bob, but we don't need to use that in this example. The content of the DIDDoc for B:did@A:B is presented above.</p>"},{"location":"concepts/0094-cross-domain-messaging/#required-end-to-end-encryption-of-the-agent-message","title":"Required: End-to-End encryption of the Agent Message","text":"<p>The Agent Message from the Sender SHOULD be hidden from all Agents other than the Receiver. Thus, it SHOULD be encrypted with the public key of the Receiver. Based on our assumptions, the Sender can get the public key of the Receiver agent because they know the DID#keyname string, can resolve the DID to the DIDDoc and find the public key associated with DID#keyname in the DIDDoc. In our example above, that is the key associated with \"did:sov:1234abcd#4\".</p> <p>Most Sender-to-Receiver messages will be sent between parties that have shared pairwise DIDs (using the <code>did:peer</code> method). When that is true, the Sender will (usually) AuthCrypt the message. If that is not the case, or for some other reason the Sender does not want to AuthCrypt the message, AnonCrypt will be used. In either case, the Indy-SDK <code>pack()</code> function handles the encryption.</p> <p>If there are mediators specified in the DID service endpoint for the Receiver agent, the Sender must wrap the message for the Receiver in a 'Forward' message for each mediator. It is assumed that the Receiver can determine the from <code>did</code> based on the <code>to</code> DID (or the sender's verkey) using their pairwise relationship.</p> <pre><code>{\n  \"@type\" : \"https://didcomm.org/routing/1.0/forward\",\n  \"@id\": \"54ad1a63-29bd-4a59-abed-1c5b1026e6fd\",\n  \"to\"   : \"did:sov:1234abcd#4\",\n  \"msg\"  : { json object from &lt;pack(AgentMessage,valueOf(did:sov:1234abcd#4), privKey(A.did@A:B#1))&gt; }\n}\n</code></pre> <p>Notes</p> <ul> <li>the <code>@type</code> value is in the precise URI format for the \"forward\" message type</li> <li>Indy-SDK's \"pack\" function is used to AuthCrypt the message using the Receiver's public key and the Sender's private key.</li> <li>If the Sender wishes to remain anonymous or knows the Receiver does not know the Sender's public key, AnonCrypt is used.</li> <li>More details about the Indy-SDK <code>pack()</code> function can be found in the Encryption Envelope RFC.</li> <li>The Indy-SDK's \"unpack()\" function MUST return the public key of the private key used to sign the message. See the note below for the background on this.</li> <li>Additional <code>forward</code> messages are created to wrap each forward for each mediator.</li> </ul> <p>The bullet above about the unpack() function returning the signer's public key deserves some additional attention. The Receiver of the message knows from the \"to\" field the DID to which the message was sent. From that, the Receiver is expected to be able to determine the DID of the Sender, and from that, access the Sender's DIDDoc. However, knowing the DIDDoc is not enough to know from whom the message was sent - which key was used to send the message, and hence, which Agent controls the Sending private key. This information MUST be made known to the Receiver (from unpack()) when AuthCrypt is used so that the Receiver knows which key was used to the send the message and can, for example, use that key in responding to the arriving Message.</p> <p>The Sender can now send the Forward Agent Message on its way via the first of the encryption envelope. In our example, the Sender sends the Agent Message to 2 (in the Sender's domain), who in turn sends it to 8. That of course, is arbitrary - the Sender's Domain could have any configuration of Agents for outbound messages. The Agent Message above is passed unchanged, with each Agent able to see the <code>@type</code>, <code>to</code> and <code>msg</code> fields as described above. This continues until the outer <code>forward</code> message gets to the Receiver's first mediator or the Receiver's agent (if there are no mediators). Each agent decrypts the received encrypted envelope and either forwards it (if a mediator) or processes it (if the Receiver Agent). Per the Encryption Envelope RFC, between Agents the Agent Message is pack()'d and unpack()'d as appropriate or required.</p> <p>The diagram below shows an example use of the <code>forward</code> messages to encrypt the message all the way to the Receiver with two mediators in between - a shared domain endpoint (aka https://agents-r-us.com) and a routing agent owned by the receiving entity.</p> <p></p>"},{"location":"concepts/0094-cross-domain-messaging/#required-cross-domain-encryption","title":"Required: Cross Domain Encryption","text":"<p>While within a domain the Agents MAY choose to use encryption or not when sending messages from Agent to Agent, encryption MUST be used when sending a message into the Receiver's domain. The endpoint agent unpack()'s the encryption envelope and processes the message - usually a <code>forward</code>. Note that within a domain, the agents may use arbitrary relays for messages, unknown to the sender. How the agents within the domain knows where to send the message is implementation specific - likely some sort of dynamic DID-to-Agent routing table. If the path to the receiving agent includes mediators, the message must go through those mediators in order (for example, through 3 in our example) as the message being forwarded has been encrypted for the mediators.</p>"},{"location":"concepts/0094-cross-domain-messaging/#required-mediators-process-forward-messages","title":"Required: Mediators Process Forward Messages","text":"<p>When a mediator (eventually) receives the message, it determines it is the target of the (current) outer forward Agent Message and so decrypts the message's <code>msg</code> value to reveal the inner \"Forward\" message.  Mediators use their (implementation specific) knowledge to map from the <code>to</code> field to deliver the message to the physical endpoint of the next agent to process the message on it's way to the Receiver.</p>"},{"location":"concepts/0094-cross-domain-messaging/#required-the-receiver-app-agent-decryptsprocesses-the-agent-message","title":"Required: The Receiver App Agent Decrypts/Processes the Agent Message","text":"<p>When the Receiver Agent receives the message, it determines it is the target of the forward message, decrypts the payload and processes the message.</p>"},{"location":"concepts/0094-cross-domain-messaging/#exposed-data","title":"Exposed Data","text":"<p>The following summarizes the information needed by the Sender's agents:</p> <ul> <li>The DID to use for the relationship, and its related DIDDoc</li> <li>A public key entry for the Receiver agent</li> <li>From the DIDDoc, a service entry for each Receiver agent that includes:</li> <li>a public DID or physical endpoint and public key for the endpoint agent.</li> <li>An optional order list of public keys (<code>RoutingKeys</code>) of mediators used by the Receiver in delivering the message.</li> </ul> <p>The DIDDoc will have a public key entry for each additional Agent message Receiver and each mediator.</p> <p>In many cases, the entry for the endpoint agent should be a public DID, as it will likely be operated by an agency (for example, https://agents-r-us.com) rather than by the Receiver entity (for example, a person). By making that a public DID in that case, the agency can rotate its public key(s) for receiving messages in a single operation, rather than having to notify each identity owner and in turn having them update the public key in every pairwise DID that uses that endpoint.</p>"},{"location":"concepts/0094-cross-domain-messaging/#data-not-exposed","title":"Data Not Exposed","text":"<p>Given the sequence specified above, the following data is NOT exposed to the Sender's agents:</p> <ul> <li>The relays within the Receiver's domain</li> <li>Receiver agents the identity chooses not to include in a given DIDDoc</li> <li>The physical endpoints of agents within the Receiver's domain (other than the Domain Endpoint)</li> <li>The physical endpoints and, as required, associated public keys, are shared as needed by the agents within the Receiver's domain.</li> </ul>"},{"location":"concepts/0094-cross-domain-messaging/#message-types","title":"Message Types","text":"<p>The following Message Types are defined in this RFC.</p>"},{"location":"concepts/0094-cross-domain-messaging/#corerouting10forward","title":"Core:Routing:1.0:Forward","text":"<p>The core message type \"forward\", version 1.0 of the \"routing\" family is defined in this RFC. An example of the message is the following:</p> <pre><code>{\n  \"@type\" : \"https://didcomm.org/routing/1.0/forward\",\n  \"@id\": \"54ad1a63-29bd-4a59-abed-1c5b1026e6fd\",\n  \"to\"   : \"did:sov:1234abcd#4\",\n  \"msg\"  : { json object from &lt;pack(AgentMessage,valueOf(did:sov:1234abcd#4), privKey(A.did@A:B#1))&gt; }\n}\n</code></pre> <p>The <code>to</code> field is required and takes one of two forms:</p> <ul> <li>A DID without a key reference (e.g. <code>did:sov:1234abcd</code>)</li> <li>A DID with a key reference (e.g. <code>did:sov:1234abcd#4</code>)</li> </ul> <p>The first form is used when sending forward messages across one or more agents that do not need to know the details of a domain. The Receiver of the message is the designated <code>Routing Agent</code> in the Receiver Domain, as it controls the key used to decrypt messages sent to the domain, but not to a specific Agent.</p> <p>The second form is used when the precise key (and hence, the Agent controlling that key) is used to encrypt the Agent Message placed in the <code>msg</code> field.</p> <p>The <code>msg</code> field calls the Indy-SDK <code>pack()</code> function to encrypt the Agent Message to be forwarded. The Sender calls the <code>pack()</code> with the suitable arguments to AnonCrypt or AuthCrypt the message. The <code>pack()</code> and <code>unpack()</code> functions are described in more detail in the Encryption Envelope RFC.</p>"},{"location":"concepts/0094-cross-domain-messaging/#reference","title":"Reference","text":"<p>See the other RFCs referenced in this document:</p> <ul> <li>DIDcomm</li> <li>Encryption Envelope</li> <li>Agent Messages</li> <li>DIDDoc Conventions</li> </ul>"},{"location":"concepts/0094-cross-domain-messaging/#drawbacks","title":"Drawbacks","text":"<p>N/A</p>"},{"location":"concepts/0094-cross-domain-messaging/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>A number of discussions were held about this RFC. In those discussions, the rationale for the RFC evolved into the text, and the alternatives were eliminated. See prior versions of the superseded HIPE (in status section, above) for details.</p> <p>A suggestion was made that the following optional parameters could be defined in the \"routing/1.0/forward\" message type:</p> <ul> <li>forward-after: specify that the message should not be forwarded until the system clock shows a particular time, or until a particular interval has elapsed. This could be useful to defeat timing correlations. Particular agents might not support it.</li> <li>mix-config: artificially introduce extra hops to obscure path (use a mix network like TOR)</li> </ul> <p>The optional parameters have been left off for now, but could be added in this RFC or to a later version of the message type.</p>"},{"location":"concepts/0094-cross-domain-messaging/#prior-art","title":"Prior art","text":"<p>N/A</p>"},{"location":"concepts/0094-cross-domain-messaging/#unresolved-questions","title":"Unresolved questions","text":"<p>N/A</p>"},{"location":"concepts/0094-cross-domain-messaging/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0103-indirect-identity-control/","title":"Aries RFC 0103: Indirect Identity Control","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: PROPOSED</li> <li>Since: 2019-06-04</li> <li>Status Note: Currently under study for implementation in various pilots and POCs. See, for example, the Sovrin Foundation's Guardianship Task Force.</li> <li>Start Date: 2019-05-10</li> <li>Tags: concept, credentials</li> </ul>"},{"location":"concepts/0103-indirect-identity-control/#summary","title":"Summary","text":"<p>Compares and contrasts three forms of indirect identity control that have much in common and that should be explored together: delegation, guardianship, and controllership. Recommends mechanisms that allow identity technology to model each with flexibility, precision, and safety. These recommendations can be applied to many decentralized identity and credentialing ecosystems--not just to the ones best known in Hyperledger circles. </p>"},{"location":"concepts/0103-indirect-identity-control/#motivation","title":"Motivation","text":"<p>In most situations, we expect identity owners to directly control their own identities. This is the ideal that gives \"self-sovereign identity\" its name. However, control is not so simple in many situations:</p> <ul> <li> <p>A corporation is governed by a Board of Directors, executives, and employees with multiple levels of delegated authority. The control relationships are dynamic and complex. (delegation)</p> </li> <li> <p>Parents typically manage the identities of their young children. Adult children may need to exercise the identity of a parent with dementia, or of a parent who recently passed away. (guardianship)</p> </li> <li> <p>A self-driving car may be capable of many independent actions, but behind such a smart device must be a human entity that takes legal responsibility. (controllership)</p> </li> </ul> <p>We need to understand how such situations color the interactions we have in an identity ecosystem.</p>"},{"location":"concepts/0103-indirect-identity-control/#tutorial","title":"Tutorial","text":"<p>Although the Sovrin Foundation advocates a specific approach to verifiable credentials, its glossary offers a useful analysis of indirect identity control that applies to any approach. Appendix C of the Sovrin Glossary V2 defines three forms of indirect identity control relationship--delegation, guardianship, controllership--matching the three bulleted examples above. Reviewing that document is highly recommended. It is the product of careful collaboration by experts in many fields, includes useful examples, and is clear and thorough.</p> <p>Here, we will simply reproduce two diagrams as a summary:</p> <p></p> <p></p> <p>Note: The type of delegation described in Appendix C, and the type we focus on in this doc, is one that crosses identity boundaries. There is another type that happens within an identity, as Alice delegates work to her various agents. For the time being, ignore this intra-identity delegation; it is explored more carefully near the end of the Delegation Details doc.</p>"},{"location":"concepts/0103-indirect-identity-control/#commonalities","title":"Commonalities","text":"<p>All of these forms of identity control share the issue of indirectness. All of them introduce risks beyond the ones that dominate in direct identity management. All of them complicate information flows and behavior. And they are inter-related; guardians and controllers often need to delegate, delegates may become controllers, and so forth.</p> <p>The solutions for each ought to have much in common, too--and that is the case. These forms of indirect identity control use similarly structured credentials in similar ways, in the context of similarly structured trust frameworks. Understanding and implementing support for one of them should give developers and organizations a massive headstart in implementing the others.</p> <p>Before we provide details about solutions, let's explore what's common and unique about each of the three forms of indirect identity control. </p>"},{"location":"concepts/0103-indirect-identity-control/#compare-and-contrast","title":"Compare and Contrast","text":""},{"location":"concepts/0103-indirect-identity-control/#delegation","title":"Delegation","text":"<p>Delegation can be either transparent or opaque, depending on whether it's obvious to an external party that a delegate is involved. A lawyer that files a court motion in their own name, but on behalf of a client, is a transparent delegate. A nurse who transcribes a doctor's oral instructions may be performing record-keeping as an opaque delegate, if the nurse is unnamed in the record.</p> <p>Transparent delegation is safer and provides a better audit trail than opaque delegation. It is closer to the ethos of self-sovereign identity. However, opaque delegation is a fact of life; sometimes a CEO wants her personal assistant to send a note or meeting invitation in a way that impersonates rather than explicitly representing her.</p> <p>Delegation needs constraints. These can take many forms, such as:</p>"},{"location":"concepts/0103-indirect-identity-control/#constraints","title":"Constraints","text":"<ul> <li>Time (for what period(s) delegate has that status)</li> <li>Place (in what physical or virtual locations delegate is approved)</li> <li>Function (legal vs. medical vs. educational)</li> <li>Circumstances (for particular event(s))</li> <li>Biometrics (for delegator involvement)</li> <li>Relationships (who delegate can interact with)</li> <li>Attributes (data/credentials -- what delegate can know or prove about delegator)</li> <li>Agents (what software/devices delegate can use)</li> <li>Cooperation (act as delegate with joint approval of other delegates)</li> <li>Oversight (audit trail, reporting)</li> </ul> <p>Delegation needs to be revokable.</p> <p>Delegates should not mix identity data for themselves with data that may belong to the delegator.</p> <p>The rules of how delegation work need to be spelled out in a trust framework.</p> <p>Sometimes, the indirect authority of a delegate should be recursively extensible (allow sub-delegation). Other times, this may be inappropriate.</p> <p>Use cases and other specifics of delegation are explored in greater depth in the Delegation Details doc.</p>"},{"location":"concepts/0103-indirect-identity-control/#guardianship","title":"Guardianship","text":"<p>Guardianship has all the bolded properties of delegation: transparent or opaque styles, constraints, revocation, the need to not mix identity data, the need for a trust framework, and the potential for recursive extensibility. It also adds some unique considerations.</p> <p>Since guardianship does not always derive from dependent consent (that is, the dependent is often unable to exercise sovereignty), the dependent in a guardianship relationship is particularly vulnerable to abuse from within.</p> <p></p> <p>Because of this risk, guardianship is the most likely of the three forms of indirect control to require an audit trail and to involve legal formalities. Its trust frameworks are typically the most nuanced and complex.</p> <p>Guardianship is also the form of indirect identity control with the most complications related to privacy.</p> <p>Guardianship must have a rationale -- a justification that explains why the guardian has that status. Not all rationales are equally strong; a child lacking an obvious parent may receive a temporary guardian, but this guardian's status could change if a parent is found. Having a formal rationale allows conflicting guardianship claims to be adjudicated.</p> <p></p> <p>Either the guardian role or specific guardianship duties may be delegated. An example of the former is when a parent leaves on a long, dangerous trip, and appoints a grandparent to be guardian in their absence. An example of the latter is when a parent asks a grandparent to drive a child to the school to sign up for the soccer team. When the guardian role is delegated, the result is a new guardian. When only guardianship duties are delegated, this is simple delegation and ceases to be guardianship.</p> <p>Use cases and other specifics of guardianship are explored in greater depth in the Guardianship Details doc.</p>"},{"location":"concepts/0103-indirect-identity-control/#controllership","title":"Controllership","text":"<p>Controllership shares nearly all bolded ../../features with delegation. It is usually transparent because things are usually known not to be identity owners in their interactions, and things are assumed not to control themselves.</p> <p>Like guardianship, controllership has a rationale. Usually, it is rooted in property ownership, but occasionally it might derive from court appointment. Also like guardianship, either the role or specific duties of controllership may be delegated. When controllership involves animals instead of machines, it may have risks of abuse and complex protections and trust frameworks.</p> <p>Unlike guardianship, controlled things usually require minimal privacy. However, things that constantly identify their controller(s) in a correlatable fashion may undermine the privacy of controllers in ways that are unexpected.</p> <p>Use cases and other specifics of controllership are explored in greater depth in the Controllership Details doc.</p>"},{"location":"concepts/0103-indirect-identity-control/#solution","title":"Solution","text":"<p>We recommend that all three forms of indirect identity control be modeled with some common ingredients:</p> <ul> <li> <p>A proxy trust framework that specifies the rules and conventions in force for a particular class of indirect identity control use cases.</p> </li> <li> <p>A proxy credential that binds a controlled entity to its proxy and clarifies the nature and limits of the control for that specific relationship.</p> </li> <li> <p>A proxy challenge that evaluates the proxy credential in a particular context, proving or disproving the legitimacy of indirect control and creating opportunities for auditing and enforcement.</p> </li> </ul> <p>Here, \"proxy\" is used as a generic cover term for all three forms of indirect identity control. Each ingredient has a variant for each form (e.g., delegate credential, guardian credential, controller credential), and they have minor differences. However, they work so similarly that they'll be described generically, with differences noted where necessary.</p>"},{"location":"concepts/0103-indirect-identity-control/#proxy-trust-framework","title":"Proxy Trust Framework","text":"<p>A proxy trust framework is a published, versioned document (or collection of documents) that's accessible by URI. Writing one doesn't have to be a massive undertaking; see the sample guardianship trust framework for a simple example).</p> <p>It should answer at least the following questions:</p> <ol> <li> <p>What is the trust framework's formal name, version, and URI? (The name cannot include a <code>/</code> character due to how it's paired with version in credential <code>type</code> fields. The version must follow semver rules.)</p> </li> <li> <p>In what geos and legal jurisdictions is it valid?</p> </li> <li> <p>On what rationales are proxies appointed? (For guardianship, these might include values like <code>kinship</code> and <code>court_order</code>. Each rationale needs to be formally defined, named, and published at a URI, because proxy credentials will reference them. This question is mostly irrelevant to delegation, where the rationale is always an action of the delegator.)</p> </li> <li> <p>What are the required and recommended behaviors of a proxy (holder), issuer, and verifier? How will this be enforced?</p> </li> <li> <p>What permissions vis-a-vis the proxied identity govern proxy actions? (For a delegate, these might include values like <code>sign</code>, <code>pay</code>, or <code>arrange_travel</code>. For a guardian, these might include values like <code>financial</code>, <code>medical</code>, <code>do_not_resuscitate</code>, <code>foreign_travel</code>, or <code>new_relationships</code>. Like rationales, permissions need to be formally defined and referencable by URI.)</p> </li> <li> <p>What are possible constraints on a proxy? (Constraints are bound to particular proxies, whereas a permission model is bound to the identity that the proxy is controlling; this distinction will make more sense in an example. Some constraints might include <code>geo_radius</code>, <code>jurisdiction</code>, <code>biometric_consent_freshness</code>, and so forth. These values also need to be formally defined and referencable by URI.)</p> </li> <li> <p>What auditing mechanisms are required, recommended, or allowed?</p> </li> <li> <p>What appeal mechanisms are required or supported?</p> </li> <li> <p>What proxy challenge procedures are best practice?</p> </li> <li> <p>What freshness rules are used for revocation testing and offline mode?</p> </li> </ol>"},{"location":"concepts/0103-indirect-identity-control/#proxy-credential","title":"Proxy Credential","text":"<p>A proxy credential conforms to the Verifiable Credential Data Model 1.0. It can use any style of proof or data format (JSON-LD, JWT, Sovrin ZKP, etc). It is recognizable as a proxy credential by the following characteristics:</p> <ol> <li> <p>Its <code>@context</code> field, besides including the \"https://www.w3.org/2018/credentials/v1\" required of all VCs, also includes a reference to this spec: \"https://github.com/hyperledger/aries-rfcs../../concepts/0103-indirect-identity-control\".</p> </li> <li> <p>Its <code>type</code> field contains, in addition to \"VerifiableCredential\", a string in the format:</p> <p></p> <p>...where <code>form</code> is one of the letters D (for Delegation), G (for Guardianship), or C (for controllership), <code>trust framework</code> is the name that a Proxy Trust Framework formally declares for itself, <code>tfver</code> is its version, and <code>variant</code> is a specific schema named in the trust framework. A regex that matches this pattern is: <code>Proxy\\.([DGC])/([^/]+)/(\\d+[^/]*)/(.+)</code>, and an example of a matching string is: <code>Proxy.G/UNICEF Vulnerable Populations Trust Framework/1.0/ChildGuardian</code>.</p> </li> <li> <p>The metadata fields for the credential include <code>trustFrameworkURI</code> (the value of which is a URI linking to the relevant trust framework), <code>auditURI</code> (the value of which is a URI linking to a third-party auditing service, and which may be constrained or empty as specified in the trust framework), and <code>appealURI</code> (the value of which is a URI linking to an arbitration or adjudication authority for the credential, and which may be constrained or empty as specified in the trust framework).</p> </li> <li> <p>The <code>credentialSubject</code> section of the credential describes a subject called <code>holder</code> and a subject called <code>proxied</code>. The holder is the delegate, guardian, or controller; the proxied is the delegator, dependent, or controlled thing.</p> </li> <li> <p><code>credentialSubject.holder.type</code> must be a URI pointing to a schema for <code>credentialSubject.holder</code> as defined in the trust framework. The schema must include the following fields:</p> <ul> <li> <p><code>role</code>: A string naming the role that the holder plays in the permissioning scheme of the dependent. These roles must be formally defined in the trust framework. For example, a guardian credential might identify the holder (guardian) as playing the <code>next_of_kin</code> role, and this <code>next_of_kin</code> role might be granted a subset of all permissions that are possible for the dependent's identity. A controllership credential for a drone might identify the holder (controller) as playing the <code>pilot</code> role, which has different permissions from the <code>maintenance_crew</code> role.</p> </li> <li> <p><code>rationaleURI</code>: Required for guardian credentials, optional for the other types. This links to a formal definition in the trust framework of a justification for holding identity control status. For guardians, the rationaleURI might point to a definition of the <code>blood_relative</code> or <code>tribal_member</code> rationale, for example. For controllers, the rationaleURI might point to a definition of <code>legal_appointment</code> or <code>property_owner</code>.</p> </li> </ul> <p>The schema may also include zero or more <code>credentialSubject.holder.constraint.*</code> fields. These fields would be used to limit the time, place, or circumstances in which the proxy may operate.</p> </li> <li> <p><code>credentialSubject.proxied.type</code> must be a URI pointing to a schema for <code>credentialSubject.proxied</code> as defined in the trust framework. The schema must include a <code>permissions</code> field. This field contains an array of SGL rules, each of which is a JSON object in the form:</p> <pre><code>{\"grant\": privileges, \"when\": condition}\n</code></pre> <p>A complete example for a guardianship use case is provided in the SGL tutorial.</p> </li> <li> <p>The credential MAY or MUST contain additional fields under <code>credentialSubject.holder</code> that describe the holder (e.g., the holder's name, DID, biometric, etc.). If the credential is based on ZKP/link secret technologies, then these may be unnecessary, because the holder can bind their proxy credential to other credentials that prove who they are. If not, then the credential MUST contain such fields.</p> </li> <li> <p>The credential MUST contain additional fields under <code>credentialSubject.proxied</code> that describe the proxied identity (e.g., a dependent's name or biometric; a pet's RFID tag; a drone's serial number).</p> </li> </ol>"},{"location":"concepts/0103-indirect-identity-control/#proxy-challenge","title":"Proxy Challenge","text":"<p>A proxy challenge is an interaction in which the proxy must justify the control they are exerting over the proxied identity. The heart of the challenge is a request for a verifiable presentation based on a proxy credential, followed by an evaluation of the evidence. This evaluation includes traditional credential verification, but also a comparison of a proxy's role (<code>credentialSubject.holder.role</code>) to permissions (<code>credentialSubject.proxied.permissions</code>), and a comparison of circumstances to constraints (<code>credentialSubject.holder.constraints.*</code>). It may also involve the creation of an audit trail, depending on the value of the <code>auditURI</code> field.</p> <p>During the verifiable presentation, the holder MUST disclose all of the following fields:</p> <ul> <li><code>@context</code></li> <li><code>type</code></li> <li><code>issuanceDate</code> (if present in schema)</li> <li><code>expirationDate</code> (if present in schema)</li> <li><code>credentialStatus</code> (if present in schema)</li> <li><code>issuer</code></li> <li><code>trustFramework</code></li> <li><code>auditURI</code></li> <li><code>appealURI</code></li> <li><code>credentialSubject.holder.type</code></li> <li><code>credentialSubject.holder.role</code></li> <li><code>credentialSubject.holder.rationaleURI</code></li> <li><code>credentialSubject.holder.constraints.*</code></li> <li><code>credentialSubject.proxied.type</code></li> <li><code>credentialSubject.proxied.permissions</code></li> </ul> <p>In addition, the holder MUST prove that the proxy is the intended holder of the credential, to whatever standard is required by the trust framework. This can be done by disclosing additional fields under <code>credentialSubject.holder</code>, or by proving things about the holder in zero knowledge, if the credential supports ZKPs. In the latter case, proofs about the holder could also come from other credentials in the holder's possession, linked to the proxy credential through the link secret.</p> <p>The holder MUST also prove that the proxied identity is correct, to whatever standard is required by the trust framework. This can be done by disclosing additional fields under <code>credentialSubject.proxied</code>, or by proving things about the subject in zero knowledge.</p> <p>[TODO: discuss moments when proxy challenges may be vital; see https://docs.google.com/presentation/d/1aq45aUHTOK_WhFEICboXQrp7dalpLm9-MGg77Nsn50s/edit#slide=id.g59fffee7a0_0_39 ]</p> <p>[TODO: discuss offline mode, freshness, and revocation]</p>"},{"location":"concepts/0103-indirect-identity-control/#reference","title":"Reference","text":"<p>A complete sample of a guardianship trust framework and credential schema are attached for reference. Please also see the details about each form of indirect identity control:</p> <ul> <li>Delegation Details</li> <li>Guardianship Details</li> <li>Controllership Details</li> </ul>"},{"location":"concepts/0103-indirect-identity-control/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0103-indirect-identity-control/controllership-details/","title":"Controllership Details","text":"<ul> <li>How controlled things can undermine privacy</li> <li>controllership and delegation</li> <li>Ethical considerations and the duty continuum</li> <li>Informal controllership by owner</li> <li>How controllership becomes transparent</li> <li>sample trust framework (DignifID?)</li> </ul>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/","title":"Delegation Details","text":"<p>Three basic approaches to delegation are possible:</p> <ol> <li>Delegate by expressing intent in a DID Doc.</li> <li>Delegate with verifiable credentials.</li> <li>Delegate by sharing a wallet.</li> </ol> <p>The alternative of delegating via the <code>authorization</code> section of a DID Doc (option #1) is unnecessarily fragile, cumbersome, redundant, and expensive to implement. The theory of delegation with DIDs and credentials has been explored thoughtfully in many places (see Prior Art and References). The emergent consensus is:</p> <ul> <li> <p>Formal delegation is best accomplished with a credential (option 2). This creates an audit trail, makes it possible to declare and enforce limits on what the delegate can do, takes advantage of standard verification and revocation features, and makes recursive delegation possible but not automatic.</p> </li> <li> <p>Informal (undeclared, invisible) delegation could be accomplished by granting access to a shared wallet (option 3). However, this introduces risks of abuse that make it unsuitable for use cases requiring high standards of security, accountability, and privacy.</p> </li> </ul>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#use-cases","title":"Use Cases","text":"<p>The following use cases are good tests of whether we're implementing delegation properly.</p>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#1-thrift-bank-employees","title":"1. Thrift Bank Employees","text":"<p>Thrift Bank wishes to issue employee credentials to its employees, giving them delegated authority to perform certain actions on behalf of the bank (e.g., open their till, unlock the front door, etc). Thrist has a DID, but wishes to grant credential-issuing authority to its Human Resources Department (which has a separate DID). In turn, the HR department wishes to further delegate this authority to the Personnel Division. Inside of the Personnel division, three employees, Cathy, Stan, and Janet will ultimately be responsible for issuing the employee credentials.</p> <ul> <li>Cathy, Stan, and Janet should not have the ability to further delegate the authority.</li> <li>The employee credentials should include the proof of delegated authority.</li> <li>Revocation of the authority to issue the employee credential should be possible at any point along the chain of delegation</li> <li>Proving non-revocation of delegated authority should be possible by Cathy, Stan, and Janet without the need for the Bank, HR, or Personnel to be involved.</li> <li>Revoking the authority to issue the credential should not invalidate the issued employee credentials.</li> </ul>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#2-u-rent-a-car","title":"2. U-Rent-a-Car","text":"<p>U-Rent-a-Car is a multinational company that owns a large fleet of vehicles. Its national headquarters issues a credential, C1, to its regional office in Quebec, authorizing U-Rent-a-Car Quebec to delegate driving privileges to customers, for cars owned by the parent company. Alice rents a car from U-Rent-a-Car Quebec. U-Rent-a-Car Quebec issues a driving privileges credential, C2, to Alice. C2 gives Alice the privilege to drive the car from Monday through Friday of a particular week. Alice climbs in the car and uses her C2 credential to prove to the car (which acts as verifier) that she is an authorized driver. She gets pulled over for speeding on Wednesday and uses C2 to prove to the police that she is the authorized driver of the car. On Thursday night Alice goes to a fancy restaurant. She uses valet parking. She issues credential C3 to the valet, allowing him to drive the car within 100 meters of the restaurant, for the next 2 hours while she is at the restaurant. The valet uses this credential to drive the car to the parking garage. While Alice eats, law enforcement goes to U-Rent-a-Car Quebec with a search warrant for the car. The law enforcement agency has discovered that the previous driver of the car was a criminal. It asks U-Rent-a-Car Quebec to revoke C2, because they don\u2019t want the car to be driven any more, in case evidence is accidentally destroyed. At the end of dinner, Alice goes to the valet and asks for her car to be returned. The valet goes to the car and attempts to open the door using C3. The car tests the validity of the delegation chain of C3, and discovers that C2 has been revoked, making C3 invalid. The car refuses to open the door. Alice has to take Uber to get home. Law enforcement officials take possession of the car.</p>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#3-acme-departments","title":"3. Acme Departments","text":"<p>Acme wants its HR department to issue Acme Employment Credentials, its Accounting department to issue Purchase Orders and Letters of Credit, its Marketing department to officially sign press releases, and so forth. All of these departments should be provably associated with Acme and acting under Acme\u2019s name in an official capacity.</p>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#4-members-of-an-llc","title":"4. Members of an LLC","text":"<p>Like #3, but simpler. 3 or 4 people each need signing authority for the LLC, so LLC delegates that authority.</p>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#approaches-to-recursive-delegation","title":"Approaches to recursive delegation","text":"<p>TODO 1. Root authority delegates directly at every level. 2. Follow the chain 3. Embed the chain</p>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#revocation","title":"Revocation","text":"<p>[TODO]</p>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#infra-identity-delegation","title":"Infra-identity Delegation","text":"<p>TODO</p>"},{"location":"concepts/0103-indirect-identity-control/delegation-details/#prior-art-and-references","title":"Prior Art and References","text":"<p>All of the following sources have contributed valuable thinking about delegation:</p> <ul> <li>\"Traversing the Web of Trust: A Protocol for Trusting the Issuer of a Verifiable Credential\", by Stephen Curran, Feb 2018.</li> <li>\"Delegation of Authority for Organizations + Services w/DID\u2019s + VerfCreds (IIW session, April 2018)</li> <li>\"Digital Identity: A Chain of Claims\", by Tim Bouma, May 2018. (See also several other posts by Tim about his work on the Pan-Canadian Trust Framework.)</li> <li>Appendix C of the W3C Verifiable Credentials Spec</li> <li>Object Capabilities for Linked Data</li> <li>Section 5.3 of the DID Spec</li> <li>\"Delegation Concepts in Sovrin\"</li> <li>\"Human Agency Has a Standard\", by Adrian Gropper</li> </ul>"},{"location":"concepts/0103-indirect-identity-control/guardianship-details/","title":"Guardianship Details","text":"<p>For a complete walkthrough or demo of how guardianship works, see this demo script.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-details/#use-cases","title":"Use Cases","text":"<p>See https://docs.google.com/presentation/d/1qUYQa7U1jczEFun3a7sB3lKHIprlwd7brfOU9hEJ34U/edit?usp=sharing</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-details/#who-appoints-a-guardian-rationales","title":"Who appoints a guardian (rationales)","text":"<p>See https://docs.google.com/presentation/d/1aq45aUHTOK_WhFEICboXQrp7dalpLm9-MGg77Nsn50s/edit#slide=id.g59fffee7a0_0_0</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-details/#transparent-vs-opaque","title":"Transparent vs. Opaque","text":"<p>See https://docs.google.com/presentation/d/1aq45aUHTOK_WhFEICboXQrp7dalpLm9-MGg77Nsn50s/edit#slide=id.g59fffee7a0_0_46</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-details/#modes-of-guardianship","title":"Modes of Guardianship","text":"<p>Holding-Based, Impersonation, Doc-based</p> <p>See https://docs.google.com/presentation/d/1aq45aUHTOK_WhFEICboXQrp7dalpLm9-MGg77Nsn50s/edit#slide=id.g59fffee7a0_0_265</p> <p>See also https://docs.google.com/presentation/d/1aq45aUHTOK_WhFEICboXQrp7dalpLm9-MGg77Nsn50s/edit#slide=id.g59fffee7a0_0_280, https://docs.google.com/presentation/d/1aq45aUHTOK_WhFEICboXQrp7dalpLm9-MGg77Nsn50s/edit#slide=id.g59fffee7a0_0_295, https://docs.google.com/presentation/d/1aq45aUHTOK_WhFEICboXQrp7dalpLm9-MGg77Nsn50s/edit#slide=id.g59fffee7a0_0_307</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-details/#guardians-and-wallets","title":"Guardians and Wallets","text":"<p>Need to work on \"wallets\" term See https://docs.google.com/presentation/d/1aq45aUHTOK_WhFEICboXQrp7dalpLm9-MGg77Nsn50s/edit#slide=id.g59fffee7a0_0_365</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-details/#guardians-and-delegation","title":"Guardians and Delegation","text":"<p>TODO</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-details/#privacy-considerations","title":"Privacy Considerations","text":""},{"location":"concepts/0103-indirect-identity-control/guardianship-details/#diffuse-trust","title":"Diffuse Trust","text":""},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/schema/","title":"Sample Guardianship Schema","text":"<p>This document presents a sample schema for a guardian credential appropriate to the IRC-as-guardian-of-Mya-in-a-refugee-camp use case. It is accompanied by a sample trust framework.</p> <p>The raw schema is here:</p> <p></p> <p>For general background on guardianship and its associated credentials, see this slide presentation.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/schema/#how-to-use","title":"How to Use","text":"<p>The schema documented here could be passed as the <code>attrs</code> arg to the <code>indy_issuer_create_schema()</code> method in libindy. The \"1.0\" in this document's name refers to the fact that we are using Indy 1.0-style schemas; we aren't trying to use the rich schema constructs that will be available to us when the \"schema 2.0\" effort is mature.</p> <p>The actual JSON you would need to pass to the <code>indy_issuer_create_schema()</code> method is given in the attached schema.json file. In code, if you place that file's content in a string variable and pass the variable as the <code>attrs</code> arg, the schema will be registered on the ledger. You might use values like \"Red Cross Vulnerable Populations Guardianship Cred\" and \"1.0\" as the <code>name</code> and <code>version</code> args to that same function. You can see an example of how to make the call by looking at the \"Save Schema and Credential Definition\" How-To in Indy SDK.</p> <p>See the accompanying trust framework for an explanation of individual fields.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/","title":"Sample Guardianship Trust Framework","text":"<p>This document describes a sample trust framework for guardianship appropriate to the IRC-as-guardian-of-Mya-in-a-refugee-camp use case. It is accompanied by a sample schema for a guardian credential.</p> <p>For general background on guardianship and its associated credentials, see this slide presentation.</p> <p>The trust framework shown here is a reasonable starting point, and it demonstrates the breadth of issues well. However, it probably would need significantly more depth to provide enough guidance for developers writing production software, and to be legally robust in many different jurisdictions.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#name-version-author","title":"Name, Version, Author","text":"<p>This is the \"Sovrin ID4All Vulnerable Populations Guardianship Trust Framework\", version \"1.0\". The trust framework is abbreviated in credential names and elsewhere as \"SIVPGTF\". It is maintained by the Sovrin ID4All Working Group. Credentials using the schema described here are known as gcreds.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#scope","title":"Scope","text":"<p>The trust framework applies to situations where NGOs like the International Red Cross/Red Crescent, UNICEF, or Doctors Without Borders are servicing large populations of vulnerable refugees, both children and adults, in formal camps. It assumes that the camps have at least modest, intermittent access to telecommunications, and that that they operate with at least tacit approval from relevant legal authorities. It may not provide enough guidance or protections in situations involving active combat, or in legal jurisdictions where rule of law is very tenuous.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#rationales-for-guardianship","title":"Rationales for Guardianship","text":"<p>In this framework, guardianship is based on one or more of the following formally defined rationales:</p> <ul> <li><code>dependent-appointment</code>: The dependent was capable of appointing a guardian, and chose to appoint the named guardian(s) to that role. This is considered the strongest rationale for guardianship.</li> <li><code>kinship</code>: The dependent is known to be vulnerable because of age or disability. The guardian is related to the dependent and thus has a natural claim to guardianship status. This trust framework formally recognizes the following kinship relationships, in order from strongest to weakest: <code>biological-parent</code>, <code>step-parent</code>, <code>sibling</code>, <code>grandparent</code>, <code>aunt-or-uncle</code>, <code>first-cousin</code>, <code>indirect-relative</code>, <code>tribe-adult</code>. Kinships weaker than <code>first-cousin</code> are considered invalid as the rationale for guardianship by themselves.</li> <li><code>adjudicated</code>: A legal authority, or a council consisting of 5 grandmothers, chose the guardian.</li> <li><code>self</code>: No suitable guardian could be found on another basis, but the dependent needed a guardian, so the guardian assumed the status until a better alternative could be found.</li> </ul>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#identifying-a-guardian","title":"Identifying a guardian","text":"<p>This framework assumes that credentials will use ZKP technology. Thus, no holder attributes are embedded in a gcred except for the holder's blinded link secret. During a guardian challenge, the holder should include appropriate identifying evidence based on ZKP credential linking.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#identifying-a-dependent","title":"Identifying a dependent","text":"<p>This framework defines the following formal ways to identify a dependent in a gcred:</p> <ul> <li><code>credentialSubject.first_name</code></li> <li><code>credentialSubject.last_name</code></li> <li><code>credentialSubject.birth_date</code></li> <li><code>credentialSubject.gender</code></li> <li><code>credentialSubject.native_language</code></li> <li><code>credentialSubject.identifying_marks</code></li> <li><code>credentialSubject.photo</code></li> <li><code>credentialSubject.iris</code></li> <li><code>credentialSubject.fingerprint</code></li> </ul> <p>These fields should appear in all gcreds. First name should be the name that the dependent acknowledges and answers to, not necessarily the legal first name. Last name may be empty if it is unknown. Birth date may be approximate. Photo is required and must be a color photo of at least 800x800 pixel resolution, taken at the time the guardian credential is issued, showing the dependent only, in good light. At least one of iris and fingerprint are strongly recommended, but neither is required.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#permissions","title":"Permissions","text":"<p>Guardians may be assigned some or all of the following formally defined permissions in this trust framework:</p> <ul> <li><code>routine-medical-care</code>: Consent to normal medical treatment, including vaccinations, HIV tests, prescriptions, hospitalization, dental procedures, surgeries, and so forth.</li> <li><code>do-not-resuscitate</code>: Consent to discontinue life support.</li> <li><code>school</code>: Enroll or unenroll dependent in school programs. Customize courses of instruction.</li> <li><code>necessaries</code>: Receive food, hygiene items, clothing, and other materials allocated to the dependent.</li> <li><code>gender-identity</code>: Specify the gender by which the dependent shall be known.</li> <li><code>religious-observance</code>: Require the dependent to observe religious practices, or consent for the dependent not to do so.</li> <li><code>light-travel</code>: Take the dependent outside the camp, returning before dark.</li> <li><code>extended-travel</code>: Take the dependent outside the camp for extended periods.</li> <li><code>unenroll</code>: Permanently remove the dependent from the camp's care.</li> <li><code>contracts</code>: Enter into financial or other legally binding arrangements on behalf of the dependent.</li> <li><code>marriage-family-planning</code>: Give consent for the dependent to marry, or require them to do so. Direct the use   contraceptives.</li> <li><code>delegate</code>: Give permission to a non-guardian to exercise some of the guardian's privileges, possibly with restrictions.</li> <li><code>successor</code>: Designate a replacement to assume guardian duties.</li> <li><code>authorize</code>: Configure the permissions of self or other guardians.</li> </ul>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#constraints","title":"Constraints","text":"<p>A guardian's ability to control the dependent may be constrained in the following formal ways by guardian credentials that use this trust framework:</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#boundary","title":"Boundary","text":"<p>Guardian can only operate within named boundaries, such as the boundaries of a country, province, city, military command, river, etc. Boundaries are specified as a localized, comma-separated list of strings, where each locale section begins with a <code>|</code> (pipe) character followed by an ISO639 language code followed by a <code>:</code> (colon) character, followed by data. All localized values must describe the same constraints; if one locale's description is more permissive than another's, the most restrictive interpretation must be used. An example might be:</p> <pre><code>\"constraints.boundaries\": \"|en: West side of Euphrates river, within Baghdad city limits\n    |es: lado oeste del r\u00edo Eufrates, dentro del centro de Bagdad\n    |fr: c\u00f4t\u00e9 ouest de l'Euphrate, dans les limites de la ville de Bagdad\n    |ar: \u0627\u0644\u062c\u0627\u0646\u0628 \u0627\u0644\u063a\u0631\u0628\u064a \u0645\u0646 \u0646\u0647\u0631 \u0627\u0644\u0641\u0631\u0627\u062a \u060c \u062f\u0627\u062e\u0644 \u062d\u062f\u0648\u062f \u0645\u062f\u064a\u0646\u0629 \u0628\u063a\u062f\u0627\u062f\"\n</code></pre>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#point-of-origin-and-radius","title":"Point of Origin and Radius","text":"<p>The <code>constraints.point_of_origin</code> and <code>radius</code> fields are an additional or alternative way to specify a geographical constraint. They must be used together. Point of origin is a string that may use latitude/longitude notation (e.g., \"@40.4043328,-111.7761829,15z\"), or a landmark. Landmarks must be localized as described previously. Radius is an integer measured in kilometers.</p> <pre><code>\"constraints.point_of_origin\": \"|en: Red Crescent Sunrise Camp\"\n\"constraints.radius_km\": 10\n</code></pre>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#jurisdictions","title":"Jurisdictions","text":"<p>This is a comma-separated list of legal jurisdictions where the guardianship applies. It is also localized:</p> <pre><code>\"constraints.jurisdictions\": \"|en: EU, India, Bangladesh\"\n</code></pre>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#trigger-and-circumstances","title":"Trigger and Circumstances","text":"<p>These are human-friendly description of circumstances that must apply in order to make the guardian's status active. It may be used in conjunction with a trigger (see next). It is vital that the wording of these fields be carefully chosen to minimize ambiguity; carelessness could invite abuse. Note that each of these fields could be used separately. A trigger by itself would unconditionally confer guardianship status; circumstances without a trigger would require re-evaluation with every guardianship challenge and might be used as long as an adult is unconscious or diagnosed with dementia, or while traveling with a child, for example.</p> <pre><code>\"constraints.trigger\": \"|en: Death of parent\"\n\"constraints.circumstances\": \"|en: While a parent or adult sibling is unavailable, and no\n    new guardian has been adjudicated.\n    |ar: \u0641\u064a \u062d\u064a\u0646 \u0623\u0646 \u0623\u062d\u062f \u0627\u0644\u0648\u0627\u0644\u062f\u064a\u0646 \u0623\u0648 \u0627\u0644\u0623\u0634\u0642\u0627\u0621 \u0627\u0644\u0628\u0627\u0644\u063a\u064a\u0646 \u063a\u064a\u0631 \u0645\u062a\u0648\u0641\u0631 \u060c \u0648\u0644\u064a\u0633\n         \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u0627\u0644\u0648\u0635\u064a \u0627\u0644\u062c\u062f\u064a\u062f \u062a\u0645 \u0627\u0644\u0641\u0635\u0644 \u0641\u064a\u0647.\"\n</code></pre>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#timing","title":"Timing","text":"<p>These allow calendar restrictions. Both start time and end time are expressed as ISO8601 timestamps in UTC timezone, but can be limited to day- instead of hour-and-minute-precision (in which case timezone is irrelevant). Start time is inclusive, whereas end time is exclusive (as soon as the date and time equals or exceeds end time, the guardianship becomes invalid). Either value can be used by itself, in addition to being used in combination.</p> <pre><code>\"constraints.startTime\": \"2019-07-01T18:00\"\n\"constraints.endTime\": \"2019-08-01\"\n</code></pre>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#auditing","title":"Auditing","text":"<p>It is strongly recommended that an audit trail be produced any time a guardian performs any action on behalf of the dependent, except for <code>school</code> and <code>necessaries</code>. Reports of auditable events are accomplished by generating a JSON document in the following format:</p> <pre><code>{\n    \"@type\": \"SIVPGTF audit/1.0\",\n    \"event_time\": \"2019-07-25T18:03:26\",\n    \"event_place\": \"@40.4043328,-111.7761829,15z\",\n    \"challenger\": \"amy.smith@redcross.org\",\n    \"witness\": \"fred.jones@redcross.org\",\n    \"guardian\": \"Farooq Abdul Sami\",\n    \"rationale\": \"natural parent\",\n    \"dependent\": \"Isabel Sami, DOB 2009-05-21\",\n    \"event\": \"enroll in class, receive books\",\n    \"justifying_permissions\": \"school, necessaries\"\n    \"evidence\": // base64-encoded photo of Farooq and Isabel\n}\n</code></pre>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#appeal","title":"Appeal","text":"<p>NGO staff (who receive delegated authority from the NGO that acts as guardian), and a council of 5 grandmothers maintain a balance of powers. Decisions of either group may be appealed to the other. Conformant NGOs must identify a resource that can adjudicate an escalated appeal, and this resource must be independent in all respects--legal, financial, human, and otherwise--from the NGO. This resource must have contact information in the form of a phone number, web site, or email address, and the contact info must be provided in the guardian credential in the <code>appeal_uri</code> field.</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#freshness-and-offline-operation","title":"Freshness and Offline Operation","text":"<p>[TODO]</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#revocation","title":"Revocation","text":"<p>[TODO]</p>"},{"location":"concepts/0103-indirect-identity-control/guardianship-sample/trust-framework/#best-practices","title":"Best Practices","text":"<ul> <li>Perform a guardian challenge whenever a guardian attempts an action requiring permissions other than <code>school</code> and <code>necessaries</code>.</li> <li>Require the disclosure of dependent photo and the comparison of the photo to the dependent, who must be physically present, for all operations using the <code>routine-medical-care</code>, <code>do-not-resuscitate</code>, <code>gender-identity</code>, and <code>light-travel</code> permissions.</li> <li>Require a biometric match (fingerprint or iris strongly preferred, or else photo plus two related adult witnesses) for the <code>extended travel</code>, <code>unenroll</code>, <code>contracts</code>, and <code>marriage-family-planning</code> permissions to be exercised where possible.</li> </ul>"},{"location":"concepts/0104-chained-credentials/","title":"Aries RFC 0104: Chained Credentials","text":"<ul> <li>Authors: Daniel Hardman, Lovesh Harchandani</li> <li>Status: PROPOSED</li> <li>Since: 2019-09-09</li> <li>Status Note: Updated 2019-11-04 after discussion at IIW at on Aries community calls, and again 2020-01-07. Various aspects of this are implemented, or in the process of being implemented, in Hyperledger Ursa and Hyperledger Indy. This doc will be updated based on learnings.</li> <li>Start Date: 2019-08-01</li> <li>Tags: concept, credentials</li> </ul>"},{"location":"concepts/0104-chained-credentials/#note-editable-images","title":"Note: editable images","text":"<p>See here for original images used in this RFC.</p>"},{"location":"concepts/0104-chained-credentials/#note-terminology-update","title":"Note: terminology update","text":"<p>\"Chained credentials\" were previously called \"delegatable credentials.\" The new term is broader and more accurate. Delegation remains a use case for the mechanism, but is no longer its exclusive focus.</p>"},{"location":"concepts/0104-chained-credentials/#summary","title":"Summary","text":"<p>Describes a set of conventions, collectively called chained credentials, that allows data in a verifiable credential (VC) to be traced back to its origin while retaining its verifiable quality. This chaining alters trust dynamics. It means that issuers late in a chain can skip complex issuer setup, and do not need the same strong, globally recognizable reputation that's important for true roots of trust. It increases the usefulness of offline verification. It enables powerful delegation of privileges, which unlocks many new verifiable credential use cases.</p> <p>Chained credentials do not require any modification to the standard data model for verifiable credentials; rather, they leverage the data model in a simple, predictable way. Chaining conventions work (with some feature variations) for any W3C-conformant verifiable credential type, not just the ones developed inside Hyperledger.</p>"},{"location":"concepts/0104-chained-credentials/#note-object-capabilities","title":"Note: object capabilities","text":"<p>When chained credentials are used to delegate, the result is an object capabilities (OCAP) solution similar to ZCAP-LD in scope, ../../features, and intent. However, such chained capabilities accomplish their goals a bit differently. See here for an explanation of the divergence and redundancy.</p>"},{"location":"concepts/0104-chained-credentials/#note-sister-rfc","title":"Note: sister RFC","text":"<p>This RFC is complements Aries RFC 0103: Indirect Identity Control. That doc describes how delegation (and related control mechanisms like delegation and controllership) can be represented in credentials and governed; this one describes an underlying infrastructure to enable such a model. The ZKP implementation of this RFC comes from Hyperledger Ursa and depends on cryptography described by Camenisch et al. in 2017.</p>"},{"location":"concepts/0104-chained-credentials/#motivation","title":"Motivation","text":"<p>There is a tension between the decentralization that we want in a VC ecosystem, and the way that trust tends to centralize because knowledge and reputation are unevenly distributed. We want anyone to be able to attest to anything they like--but we know that verifiers care very much about the reputation of the parties that make those attestations.</p> <p>We can say that verifiers will choose which issuers they trust. However, this places a heavy burden on them--verifiers can't afford to vett every potential issuer of credentials they might encounter. The result will be a tendency to accept credentials only from a short list of issuers, which leads back to centralization.</p> <p>This tendency also creates problems with delegation. If all delegation has to be validated through a few authorities, a lot of the flexibility and power of delegation is frustrated.</p> <p>We'd like a VC landscape where a tiny startup can issue an employment credential with holder attributes taken as seriously as one from a massive global conglomerate--and with no special setup by verifiers to trust them equally. And we'd like parents to be able to delegate childcare decisions to a babysitter on the spur of the moment--and have the babysitter be able to prove it when she calls an ambulance.</p>"},{"location":"concepts/0104-chained-credentials/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0104-chained-credentials/#data-provenance","title":"Data provenance","text":"<p>Our confidence in data depends on the data's origin and chain of custody--its provenance.</p> <p>Journalists and academics cite sources. The highest quality sources explain how primary data was derived, and what inferences are reasonable to draw from it. Better sources, and better links to those sources, create better trust.</p> <p>With credentials, the direct reporter of data is the issuer--but the issuer is not always the data's source. When Acme's HR department issues an employment credential that includes Bob the employee's name, the source of Bob's name is probably government-issued ID, not Acme's subjective opinion. Acme is reporting data that originated elsewhere.</p> <p></p> <p>Acme should cite its sources. Even when citations are unstructured and unsigned, they may still be helpful to humans. But we may be able to do better. If the provenance of an employee's name is verifiable in the same way as other credential data, then Acme's reputation with respect to that assertion becomes almost unimportant; the data's ability to foster trust is derived from the reputation of its true source, plus the algorithm that verifies that source.</p> <p>This matters.</p> <p>One of the challenges with traditional trust on the web is the all-or-nothing model of trust for certificate authorities. A website in an obscure corner of the globe uses an odd CA; browser manufacturers must debate whether that CA deserves to be on the list of globally trusted attesters. If yes, then any cert the CA issues will be silently believed; if no, then none will. UX pressure has often decided the debate in favor of trust by default; the result has been very long lists of trusted CAs, and a corresponding parade of junk certificates and abuse.</p> <p>Provenanced data helps verifiable credentials avoid the same conundrum. The set of original sources for a person's legal name is far smaller than the set of secondary entities that might issue credentials containing that data, so verifiers need only a short list of trusted sources for that data, no matter how many issuers they see. When they evaluate an employment credential, they will be able to see that the employee's name comes from a passport issued by the government, while the hire date is directly attested by the company. This lets the verifier nuance trust in granular and useful ways. </p>"},{"location":"concepts/0104-chained-credentials/#delegation-as-provenance-of-authority","title":"Delegation as provenance of authority","text":"<p>Delegation can be modeled as a data provenance issue, where the data in question is an authorization. Suppose Alice, the CEO of Thrift Bank, has the authority to do many tasks, and that one of them is to negotiate contracts. As the company grows, she decides that the company needs a role called \"Corporate Counsel\", and she hires Carl for the job. She wants to give Carl a credential that says he has the authority to negotiate contracts. The provenance of Carl's authority is Alice's own authority.</p> <p></p> <p>Notice how parallel this diagram is to the previous one.</p>"},{"location":"concepts/0104-chained-credentials/#chaining","title":"Chaining","text":"<p>Both of the examples given above imagine a single indirection between a data source and the issuer who references it. But of course many use cases will be far more complex. Perhaps the government attests Bob's name; this becomes the basis for Bob's employer's attestation, which in turn becomes the basis for an attestation by the contractor that processes payroll for Bob's employer. Or perhaps authorization from Alice to corporate counsel gets further delegated. In either case, the result will be a data provenance chain:</p> <p></p> <p>This is the basis for the chained credential mechanism that gives this RFC its name. Chained credentials contain information about the provenance of some or all of the data they embody; this allows a verifier to trace the data backward, possibly through several links, to its origin, and to evaluate trust on that basis.</p>"},{"location":"concepts/0104-chained-credentials/#use-cases","title":"Use cases","text":"<p>Many use cases exist for conveying provenance for the data inside verifiable credentials:</p> <ul> <li>A person wants to use an airplane ticket to gain access to a boarding area in an airport. The airplaine ticket contains data directly attested by the carrier, as well as data attested by the passport that the passenger used during check in, plus data attested by the credit card company that the passenger used to buy the ticket, plus maybe data attested by personnel at a security checkpoint. Verification of this data should impute different trust to different fields on the ticket depending on the provenance of the data. </li> <li>An oversight body wants to certify election results, based on results reported (as VCs) by each precint. Precints in turn want to certify results based on data emitted (as VCs) by polling stations. The oversight body wants to show that its certification is dependent on data that it received and believed to be genuine, not on direct observation in every polling location.</li> <li>Company A wants to delegate to B (a vendor of HR services) the management of A's employees, including the issuance of employee-of-A credentials that are in turn used to act on behalf of A.</li> <li>A scientific organization that operates exploratory drones wants to delegate pilot privileges to some staff members, and maintenance privileges to other staff members.</li> <li>A parent wants to delegate medical care decisions to a babysitter for a few hours.</li> </ul>"},{"location":"concepts/0104-chained-credentials/#acid-test","title":"Acid Test","text":"<p>Although these situations sound different, their underlying characteristics are surprisingly similar--and so are those of other use cases we've identified. We therefore chose a single situation as being prototypical. If we address it well, our solution will embody all the characteristics we want. The situation is this:</p> <p></p>"},{"location":"concepts/0104-chained-credentials/#chain-of-provenance-for-authority-delegation","title":"Chain of Provenance for Authority (Delegation)","text":"<p>The national headquarters of Ur Wheelz (a car rental company) issues a verifiable credential, C1, to its regional office in Houston, authorizing Ur Wheelz Houston to rent, maintain, sell, drive, and delegate driving privileges to customers, for certain cars owned by the national company. </p> <p>Alice rents a car from Ur Wheelz Houston. Ur Wheelz Houston issues a driving privileges credential, C2, to Alice. C2 gives Alice the privilege to drive the car on a particular week, within the state of Texas, and to further delegate that privilege. Alice uses her C2 credential to prove to the car (which is a fancy future car that acts as verifier) that she is an authorized driver; this is what unlocks the door.</p> <p>Alice gets pulled over for speeding on Wednesday and uses C2 to prove to the police that she is the authorized driver of the car.</p> <p>On Thursday night Alice goes to a fancy restaurant. She uses valet parking. She issues credential C3 to the valet, allowing him to drive the car within 100 meters of the restaurant, for the next 2 hours while she is at the restaurant. Alice chooses to constrain C3 so the valet cannot further delegate. The valet uses C3 to unlock and drive the car to the parking garage.</p>"},{"location":"concepts/0104-chained-credentials/#revocation","title":"Revocation","text":"<p>While Alice eats, law enforcement officers go to Ur Wheelz Houston with a search warrant for the car. They have discovered that the previous driver of the car was a criminal. They ask Ur Wheelz to revoke C2, because they don\u2019t want the car to be driven any more, in case evidence is accidentally destroyed.</p> <p>At the end of dinner, Alice goes to the valet and asks for her car to be returned. The valet goes to the car and attempts to open the door using C3. The car tests the validity of the delegation chain of C3, and discovers that C2 has been revoked, making C3 invalid. The car refuses to open the door. Alice has to take Uber to get home. Law enforcement takes possession of the car.</p>"},{"location":"concepts/0104-chained-credentials/#how-chained-credentials-address-this-use-case","title":"How chained credentials address this use case","text":"<p>A chained credential is a verifiable credential that contains provenanced data, linking it back to its source. In this case, the provenanced data is about authority, and each credential in the chain functions like a capability token, granting its holder privileges that derive from an upstream issuer's own authority.</p>"},{"location":"concepts/0104-chained-credentials/#note-delegate-credentials","title":"Note: delegate credentials","text":"<p>We call this subtype of chained credential a delegate credential. We'll try to describe the provenance chain in generic terms as much as possible, but the delegation problem domain will occasionally color our verbiage... All delegate credentials are chained; not all chained credentials are delegate credentials.</p> <p>The first entity in the provenance chain for authority (Ur Wheels National, in our acid use case) is called the root attester, and is probably an institution configured for traditional credential issuance (e.g., with a public DID to which reputation attaches; in Indy, this entity also publishes a credential definition). All downstream entities in the provenance chain can participate without special setup. They need not have public DIDs or credential definitions. This is because the strength of the assertion does not depend on their reputation; rather, it depends on the robustness of the algorithm that walks the provenance chain back to its root. Only the root attester needs public reputation.</p>"},{"location":"concepts/0104-chained-credentials/#note-contrast-with-acls","title":"Note: contrast with ACLs","text":"<p>When chained credentials are used to convey authority (the delegate credential subtype), they are quite different from ACLs. ACLs map an identity to a list of permissions. Delegate credentials entitle their holder to whatever permissions the credential enumerates. Holding may or may not be transferrable. If it is not transferrable, then fraud prevention must be considered. If the credential isn't bound to a holder, then it's a bearer token and is an even more canonical OCAP.</p>"},{"location":"concepts/0104-chained-credentials/#special-sauce","title":"Special Sauce","text":"<p>A chained credential delivers these ../../features by obeying some special conventions over and above the core requirements of an ordinary VC:</p> <ol> <li> <p>It contains a special field named <code>schema</code> that is a base64url-encoded representation of its own schema. This makes the credential self-contained in the sense that it doesn't depend on a schema or credential definition defined by an external authority (though it could optionally embody one). This field is always disclosed in presentations.</p> </li> <li> <p>It contains a special field named <code>provenanceProofs</code>. The field is an array, where each member of the array is a tuple (also a JSON array). The first member of each tuple is a list of field names; the second member of each tuple is an embedded W3C verifiable presentation that proves the provenance of the values in those fields. In the case of delegate credentials, <code>provenanceProofs</code> is proving the provenance of a field named <code>authorization</code>.</p> <p>Using credentials C1, C2, and C3 from our example use case, the <code>authorization</code> tuple in <code>provenanceProofs</code> of C1 includes a presentation that proves, on the basis of a car title that's a traditional, non-provenanced VC, that Ur Wheelz National had the authority to delegate a certain set of privileges X to Ur Wheelz Houston. The <code>authorization</code> tuple in <code>provenanceProofs</code> of C2 proves that Ur Wheelz Houston had authority to delegate Y (a subset of the authority in X) to Alice, and also that Ur Wheelz Houston derived its authority from Ur Wheelz National, who had the authority to delegate X to Ur Wheelz Houston. Similarly, the <code>authorization</code> tuple in C3's <code>provenanceProofs</code> is an extension of the <code>authorization</code> tuple in C2's <code>provenanceProofs</code>\u2014now proving that Alice had the authority to delegate Z to the valet, plus all the other delegations in the upstream credentials.</p> <p></p> <p>When a presentation is created from a chained credential, <code>provenanceProofs</code> is either disclosed (for non-ZKP proofs), or is used as evidence to prove the same thing (for ZKPs).</p> </li> <li> <p>It is associated (through a name in its <code>type</code> field array and through a URI in its <code>trustFrameworkURI</code> field) with a trust framework that describes provenancing rules. For general chained credentials, this is optional; for delegate credentails, it is required. The trust framework may partially describe the semantics of some schema variants for a family of chained credentials, as well as how provenance is attenuated or categorized. For example, a trust framework jointly published by Ur Wheelz and other car rental companies might describe delegate credential schemas for car owners, car rental offices, drivers, insurers, maintenance staff, and guest users of cars. It might specify that the permissions delegatable in these credentials include <code>drive</code>, <code>maintain</code>, <code>rent</code>, <code>sell</code>, <code>retire</code>, <code>delegate-further</code>, and so forth. The trust framework would do more than enumerate these values; it would define exactly what they mean, how they interact with one another, and what permissions are expected to be in force in various circumstances.</p> </li> <li> <p>The reputation of non-root holders in a provenance chain become irrelevant as far as credential trust is concerned--trust is based on an unbroken chain back to a root public attester, not on published, permanent characteristics of secondary issuers. Only the root attester needs to have a public DID. Other issuer keys and DIDs can be private and pairwise.</p> </li> <li> <p>If it is a delegate credential, it also meets all the requirements to be a proxy credential as described in Aries RFC 0103: Indirect Identity Control. Specifically:</p> <ul> <li> <p>It uses <code>credentialSubject.holder.*</code> fields to bind it to a particular holder, if applicable.</p> </li> <li> <p>It uses <code>credentialSubject.proxied.*</code> fields to describe the upstream delegator to whatever extent is required.</p> </li> <li> <p>It uses <code>credentialSubject.holder.role</code> and <code>credentialSubject.proxied.permissions</code> to grant permissions to the holder. See Delegating Permissions for more details.</p> </li> <li> <p>It may use <code>credentialSubject.holder.constraints.*</code> to impose restrictions on how/when/under what circumstances the delegation is appropriate.</p> </li> </ul> </li> </ol>"},{"location":"concepts/0104-chained-credentials/#whats-not-different","title":"What's not different","text":"<p>Proof of non-revocation uses the same mechanism as the underlying credentialing system. For ZKPs, this means that merkle tree or accumulator state is checked against the ledger or against any other source of truth that the root attester in the chain specifies; no conferring with upstream issuers is required. See ZKP Revocation in the reference section. For non-ZKP credentials, this probably means consulting revocation lists or similar.</p> <p>Offline mode works exactly the same way as it works for ordinary credentials, and with exactly the same latency and caching properties.</p> <p>Chained credentials may contain ordinary credential attributes that describe the holder or other subjects, including ZKP-style blinded link secrets. This allows chained credentials to be combined with other VCs in composite presentations.</p>"},{"location":"concepts/0104-chained-credentials/#sample-credentials","title":"Sample credentials","text":"<p>Here is JSON that might embody credentials C1, C2, and C3 from our use case. Note that these examples suppress a few details that seem uninteresting, and they also introduce some new ../../concepts that are described more fully in the Reference section.</p>"},{"location":"concepts/0104-chained-credentials/#c1-delegates-management-of-car-to-ur-wheelz-houston","title":"C1 (delegates management of car to Ur Wheelz Houston)","text":"<pre><code>{\n    \"@context\": [\"https://w3.org/2018/credentials/v1\", \"https://github.com/hyperledger/aries-rfcs/tree/main../../concepts/0104-delegatable-credentials\"],\n    \"type\": [\"VerifiableCredential\", \"Proxy.D/CarRentalTF/1.0/subsidiary\"],\n    \"schema\": \"WwogICJAY29udGV4dCIsIC8vSlN... (clipped for brevity) ...ob2x\",\n    \"provenanceProofs\": [\n        [[\"authorization\"], {\n            // proof that Ur Wheelz National owns the car\n            }]\n    ],\n    // Optional. Might be used to identify the car in question.\n    \"credentialSubject.car.VIN\": \"1HGES26721L024785\",\n    \"credentialSubject.proxied.permissions\": {\n        \"grant\": [\"rent\", \"maintain\", \"sell\", \"drive\", \"delegate\"], \n        \"when\": { \"role\": \"regional_office\" } \n    }\n    // Optional. Binds the credential to a business name.\n    \"credentialSubject.holder.name\": \"Ur Wheelz Houston\",\n    // Optional. Binds the credential to the public DID of Houston office.\n    \"credentialSubject.holder.id\": \"did:example:12345\",\n    \"credentialSubject.holder.role\": \"regional_office\",\n}\n</code></pre>"},{"location":"concepts/0104-chained-credentials/#c2-delegates-permission-to-alice-to-drive-subdelegate","title":"C2 (delegates permission to Alice to drive, subdelegate)","text":"<pre><code>{\n    // @context, type, schema are similar to previous\n    \"provenanceProofs\": {\n        [[\"authorization\"], {\n            // proof that Ur Wheelz Houston could delegate\n            }]\n    },\n    // Optional. Might be used to identify the car in question.\n    \"credentialSubject.car.VIN\": \"1HGES26721L024785\",\n    \"credentialSubject.proxied.permissions\": {\n        \"grant\": [\"drive\", \"delegate\"], \n        \"when\": { \"role\": \"renter\" } \n    }\n    // Optional. Binds the credential to a business name.\n    \"credentialSubject.holder.name\": \"Alice Jones\",\n    // Optional. Binds the credential to the public DID of Houston office.\n    \"credentialSubject.holder.id\": \"did:example:12345\",\n    \"credentialSubject.holder.role\": \"renter\",\n    // Limit dates when delegation is active\n    \"credentialSubject.holder.constraints.startTime\": \"2020-05-20T14:00Z\",\n    \"credentialSubject.holder.constraints.endTime\": \"2020-05-27T14:00Z\",\n    // Provide a boundary within which delegation is active\n    \"credentialSubject.holder.constraints.boundary\": \"USA:TX\"\n}\n</code></pre>"},{"location":"concepts/0104-chained-credentials/#c3-delegates-permission-to-valet-to-drive","title":"C3 (delegates permission to valet to drive)","text":"<pre><code>{\n    // @context, type, schema are similar to previous\n    \"delegationProof\": {\n        [[\"authorization\"], {\n            // proof that Alice could delegate\n            }]\n    },\n    // Optional. Might be used to identify the car in question.\n    \"credentialSubject.car.VIN\": \"1HGES26721L024785\",\n    \"credentialSubject.proxied.permissions\": {\n        \"grant\": [\"drive\"], \n        \"when\": { \"role\": \"valet\" } \n    }\n    // Optional. Binds the credential to a business name.\n    \"credentialSubject.holder.name\": \"Alice Jones\",\n    // Optional. Binds the credential to the public DID of Houston office.\n    \"credentialSubject.holder.id\": \"did:example:12345\",\n    \"credentialSubject.holder.role\": \"valet\",\n    \"credentialSubject.holder.constraints.startTime\": \"2020-05-25T04:00Z\",\n    \"credentialSubject.holder.constraints.endTime\": \"2020-05-25T06:00Z\",\n    // Give a place where delegation is active.\n    \"credentialSubject.holder.constraints.pointOfOrigin\": \"@29.7690295,-95.5293445,12z\",\n    \"credentialSubject.holder.constraints.radiusKm\": 0.1,\n}\n</code></pre>"},{"location":"concepts/0104-chained-credentials/#reference","title":"Reference","text":""},{"location":"concepts/0104-chained-credentials/#delegating-permissions","title":"Delegating Permissions","text":"<p>In theory, we could just enumerate permissions in delegate credentials in a special VC field named <code>permissions</code>. To delegate the <code>drive</code> and <code>delegate</code> privileges to Alice, this would mean we'd need a credential field like this:</p> <pre><code>{\n    // ... rest of credential fields ...\n\n    \"permissions\": [\"drive\", \"delegate\"]\n}\n</code></pre> <p>Such a technique is adequate for many delegation use cases, and is more or less how ZCAP-LD works. However, it has two important limitations:</p> <ul> <li>It doesn't support aggregate delegation\u2014delegating to a group of holders who must act together to acquire the permission. Example: there is no obvious way for a company to delegate signing permissions to 3 members of its board as a collective unit\u2014only to single board members as individuals.</li> <li>It doesn't convey context in ways that lets humans adjudicate the intent of the delegator. This is a requirement for guardianship, and possibly for some other specialized delegation use cases.</li> </ul> <p>To address these additional requirements, delegate credentials split the granting of permissions into two fields instead of one:</p> <ol> <li>The permission model that provides context for the credential is expressed in a special field named <code>credentialSubject.proxied.permissions</code>. This field contains an SGL rule that embodies the semantics of the delegation.</li> <li>The holder (delegate) is given a named role in that overall permission scheme in a special field named <code>credentialSubject.holder.role</code>. This role has to reference something from <code>...permissions</code>. </li> </ol> <p>In our Ur Wheelz / Alice use case, the extra expressive power of these two fields is not especially interesting. The credential that Alice carries might look like this:</p> <pre><code>{\n    // ... rest of credential fields ...\n\n    \"credentialSubject.proxied.permissions\": { \n        \"grant\": [\"drive\"], \n        \"when\": { \"role\": \"renter\" } \n    }\n    \"credentialSubject.holder.role\": [\"renter\"]\n}\n</code></pre> <p>Since <code>credentialSubject.holder.role</code> says that Alice has the <code>renter</code> role, the grant of <code>drive</code> applies to her. We expect permissions to always apply directly to the holder in simple cases like this.</p> <p>But in the case of a corporation that wants to delegate signing privileges to 3 board members, the benefit of the two-field approach is clearer. Each board member gets a delegate credential that looks like this:</p> <pre><code>{\n    // ... rest of credential fields ...\n\n    \"credentialSubject.proxied.permissions\": { \n        \"grant\": [\"sign\"], \n        \"when\": { \"role\": \"board\", \"n\": 3 } \n    }\n    \"credentialSubject.holder.role\": [\"board\"]\n}\n</code></pre> <p>Now a verifier can say to one credential-holding board member, \"I see that you have part of the signing privilege. Can you find me two other board members who agree with this action?\"</p>"},{"location":"concepts/0104-chained-credentials/#privacy-considerations","title":"Privacy Considerations","text":"<p>Non-ZKP-based chained credentials reveal the public identity of the immediate downstream holder to each issuer (delegator) -- and they reveal the public identiy of all upstream members of the chain to the holder.</p> <p>ZKP-based chained credentials offer more granular choices. See ZKP Variants and their privacy implications below.</p>"},{"location":"concepts/0104-chained-credentials/#embedded-schema","title":"Embedded schema","text":"<p>Often, the schema of a chained credential might be decided (or created) by the issuer. In some cases, the schema might be decided by the delegatee or specified fully or partially in a trust framework. </p> <p>It is the responsibility of each issuer to ensure that the special <code>schema</code> attribute is present and that the credential matches it.</p>"},{"location":"concepts/0104-chained-credentials/#zkp-revocation","title":"ZKP Revocation","text":"<p>When a chained credential is issued, a unique credential id is assigned to it by its issuer and then the revocation registry is updated to track which credential id was issued by which issuer. During proof presentation, the prover proves in zero knowledge that its credential is not revoked. When a credential is to be revoked, the issuer of the credential sends a signed message to the revocation registry asking it to mark the credential id as revoked. Note that this allows only the issuer of the credential to revoke the credential and does not allow, for example, the delegator to revoke any credential that was issued by its delegatee. However, this can be achieved by the verifier mandating that each credential in the chain of credentials is non-revoked. When a PCF decides to revoke the PTR credential, every subsequent credential should be considered revoked.</p> <p>In practice, there are more attributes associated with the credential id in the revocation registry than just the public key. The registry also tracks the timestamps of issuance and revocation of the credential id and the prover is able to prove in zero knowledge about those data points as well. The way we imagine revocation being implemented is having a merkle tree with each leaf corresponding to a credential id, so for a binary tree of height 8, there are 2^8 = 256 leaves and leaf number 1 will correspond to credential id 1, leaf number 2 will correspond to credential id 2, and so on. The data at the leaf consists of the public key of the issuer, the issuance timestamp and the revocation timestamp. We imagine the use of Bulletproofs merkle tree gadget to do such proofs like we plan to do for the upcoming version of anonymous credentials.</p>"},{"location":"concepts/0104-chained-credentials/#zkp-variants-and-their-privacy-implications","title":"ZKP Variants and their privacy implications","text":"<p>There are two general categories of chained anonymous credentials, distinguished by the tradeoff they make between privacy and efficiency. Choosing between them should depend on whether privacy between intermediate issuers is required.</p> <p>The more efficient category provides no privacy among the issuers but only verifiers. Suppose the holder, say Alice, requests a chained credential from the root attestor, say Acme Corp., which it further attests to a downstream issuer Bob which further delegates to another downstream issuer Carol. Here Carol knows the identity (a public key) of Bob and both Carol and Bob know the identity of Alice but when Carol or Bob uses its credential to create a proof and send it to the verifier, the verifier only learns about the identity of the root attester.</p> <p>Less efficient but more private schemes (isolating attestors more completely) also exist.</p> <p>The first academic paper in the following list describes a scheme which does not allow for privacy between attestors, but that is more efficient; the second and third papers make the opposite tradeoff.</p> <ol> <li>Practical UC-Secure Delegatable Credentials with Attributes and Their Application to Blockchain.</li> <li>Delegatable Attribute-based Anonymous Credentials from Dynamically Malleable Signatures</li> <li>Delegatable Anonymous Credentials from Mercurial Signatures </li> </ol> <p>In the first scheme, each issuer passes on its received credentials to the issuer it is delegating to. In the above Acme Corp., Alice, Bob and Carol example, if when Alice delegates to Bob, it gives Bob a new credential but also a copy of the credential it received from Acme Corp. And when Bob delegates to Carol, he gives a new credential to Carol but also the copies of credential it got from Alice and the one Alice had got from Acme Corp. The verifier while getting a proof from, say Carol, does not learn the about the Alice, Bob or Carol but learns that there were 2 issuers between Acme Corp and the proof presenter. It also learns the number of attributes in each credential in the chain of credentials.</p> <p>In the second and third scheme, during delegation, the delegator gives only one credential to the delegatee derived from its credential but the delegatee randomizes its identity each time. The second scheme's efficiency is comparable to the first scheme's but it has a trusted authority which can deanonymize any issuer given a proof created from that issuer's credential. This might be fine in cases where the PCF can be safely made the trusted authority and is not assumed to colluding with the verifiers to deanonymize the users.</p> <p>In the third scheme, another limitation exists that non-root issuers cannot add any more attributes to the credential than the root issuer did.</p>"},{"location":"concepts/0104-chained-credentials/#drawbacks","title":"Drawbacks","text":"<p>If the trust framework is not properly defined, malicious parties might be able to get credentials from delegators leading to priviledge escalation. </p>"},{"location":"concepts/0104-chained-credentials/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>An expensive alternative of delegatable credentials is the holder to get credential directly from the root issuer. The expensiveness of this is not just computational but operational too.</p>"},{"location":"concepts/0104-chained-credentials/#prior-art","title":"Prior art","text":"<p>Delegatable anonymous credentials have been explored since the last decade and the first efficient (somewhat) came in 2009 by Belenkiy et al. in \"Randomizable proofs and delegatable anonymous credentials\". Although this was a significant efficiency improvement over previous works, it was still impractical. Chase et al. gave a conceptually novel construction of delegatable anonymous credentials in 2013 in \"Complex unary transformations and delegatable anonymous credentials\" but the resulting construction was essentially as inefficient as that of Belenkiy et al. </p>"},{"location":"concepts/0104-chained-credentials/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0104-chained-credentials/contrast-zcap-ld/","title":"Contrast zcap ld","text":""},{"location":"concepts/0104-chained-credentials/contrast-zcap-ld/#why-not-zcap-ld","title":"Why not ZCAP-LD?","text":"<p>The object capability model is great, and ZCAP-LD is an interesting solution that exposes that goodness to the VC ecosystem. However, we had the following concerns when we first encountered its spec (originally entitled \"OCAP-LD\"):</p> <ul> <li> <p>It invents a new document format type, with associated new parsing and validation logic. We wondered whether a VC itself, instead of a new type of doc, could convey an object capability. Using a VC to convey delegation, instead of a new doc type, would minimize new code and possibly give a natural adaptation path for all VC ecosystems. (In fairness to ZCAP-LD, the reuse is fairly substantial with ZCAP-LD if your VC impl is JSON-LD centric. So this concern mainly resonates for people coming from a JWT- or ZKP-centric world.)</p> </li> <li> <p>ZCAP-LD's mechanism for validating the non-revocation status of each credential in the delegation chain seemed to follow the same revocation checking pattern as traditional non-ZKP credentials. This results in a workflow where everyone upstream in a delegated credential chain finds out each time a credential is used, which is a privacy concern.</p> </li> <li> <p>We had concerns about fragility. When issuers are massive institutions that are online 24x7x365, this may not be deeply problematic, but we wanted a solution that could be used by issuers that are regularly offline.</p> </li> <li> <p>It wasn't obvious to us how to use ZCAP-LD when ZKPs are a desirable feature.</p> </li> <li> <p>We needed to integrate delegation with the concepts of guardianship and controllership (e.g., so a guardian could delegate and a delegate could be a guardian). This required some commonality among the 3 modes of proxy identity control that was not modeled in ZCAP-LD.</p> </li> <li> <p>We wanted to use delegation features to faciliate issuance by private individuals, while short-circuiting the relatively demanding setup that normal VC issuance requires.  </p> </li> </ul> <p>For these reasons, we spent some time working out a somewhat similar mechanism. We hope we can reconcile the two at some point. For now, though, this doc just describes our alternative path.</p>"},{"location":"concepts/0167-data-consent-lifecycle/","title":"Aries RFC 0167: Data Consent Lifecycle","text":"<ul> <li>Authors: Jan Lindquist, Dativa; Paul Knowles, Dativa; Mark Lizar, OpenConsent; Harshvardhan J. Pandit, ADAPT Centre, Trinity College Dublin</li> <li>Status: PROPOSED</li> <li>Since: 2019-08-07 (updated 2019-03-16)</li> <li>Status Note: This RFC is under development. The reference implementation was recently added.</li> <li>Supersedes: Indy HIPE PR #55: Consent Receipt</li> <li>Start Date: 2018-11-08</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0167-data-consent-lifecycle/#table-of-contents","title":"Table of Contents","text":"<ul> <li>Summary</li> <li>Motivation</li> <li>Overview</li> <li>Concepts</li> <li>Use Cases</li> <li>Implementation Guidelines<ul> <li>Collect Personal Data</li> <li>Personal Data Processing Schema</li> <li>Example: schemas</li> <li>Blockchain Prerequisites</li> <li>Data Consent Receipt Certificate</li> <li>Initial agreement of privacy agreement</li> <li>Proof Request</li> <li>Performing Proof Request</li> <li>Certification Revocation</li> </ul> </li> <li>Implementation Reference</li> <li>Reference</li> <li>Annex A: PDP Schema mapping to Kantara Consent Receipt</li> <li>Prior art<ul> <li>ETL process</li> <li>Personal Data Terms and Conditions</li> </ul> </li> <li>Unresolved questions</li> <li>Plan</li> <li>ToDo</li> <li>Comments</li> </ul>"},{"location":"concepts/0167-data-consent-lifecycle/#summary","title":"Summary","text":"<p>This  RFC illustrates a reference implementation for generating a consent proof for use with DLT (Distributed Ledger Technology).  Presenting a person controlled consent proof data control architecture and supply chain permissions, that is linked to the single consent proof.</p> <p>The objective of this RFC is to move this  reference implementation, once comments are processed, to a working implementation RFC, demonstrating a proof of consent for DLT.</p> <p>This RFC  breaks down key components to generate an explicit consent directive with the use of a personal data processing notice (PDP-N) specification which is provided with this RFC as a template for smart privacy.  Appendix - PDP - Notice Spec (DLC Extension for CR v2)</p> <p>This reference RFC utilises a unified legal data control vocabulary for notification and consent records and receipts  (see Appendix A), maintained by the W3C Data Privacy Vocabulary Control Community Group (DPV), where the unified data control vocabulary is actively being maintained.</p> <p>This RFC modularizes data capture to make the mappings interchangeable with overlays  (OCA -Ref), to facilitate scale of data control sets across contexts, domains and jurisdictions.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#motivation","title":"Motivation","text":"<p>A key challenge with privacy and personal data sharing and self-initiated consent is to establish trust. There is no trust in the personal data based economy. GDPR Article 25, Data Protection by Design and by Default, lists recommendations on how private data is processed. Here we list the technology changes required to implement that GDPR article. Note the RFC focuses on formalizing the processing agreement associated with the consent, rather than on informal consent dialogue.</p> <p>Hyperledger Aries provides the perfect framework for managing personal data, especially personal identifiable information (PII), when necessary data is restricted to protect the identity of the individual or data subject. Currently, the privacy policy that is agreed to when signing up for a new service dictates how personal data is processed and for which purpose. There is no clear technology to hold a company accountable for the privacy policy. By using blockchain and the data consent receipt, accountability of a privacy policy can be reached. The data consent is not limited to a single data controller (or institution) and data subject (or individual), but to a series of institutions that process the data from the original data subject. The beauty of the proposal in this RFC is that accountability is extended to ALL parties using the data subject's personal data. When the data subject withdraws consent, the data consent receipt agreement is withdrawn, too.</p> <p>GDPR lacks specifics regarding how technology should be or can be used to enforce obligations. This RFC provides a viable alternative with the mechanisms to bring accountability and at the same time protecting personal data.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#overview","title":"Overview","text":"<p>Three key components need to be in place:</p> <ol> <li> <p>Schema bases/overlays</p> </li> <li> <p>Consent Lifecycle</p> </li> <li> <p>Wallet</p> </li> </ol> <p>Schema bases/overlays describes a standard approach to data capture that separates raw schema building blocks from additional semantic layers such as data entry business logic and constraints, knowledge about data sensitivity, and so forth (refer to [RFC 0013: Overlays for details). The data consent lifecycle covers the data consent receipt certificate, proof request and revocation. The wallet is where all data is stored which requires a high level of security and control by individual or institution. This RFC will cover the consent lifecycle.</p> <p>The Concepts section below explains the RFC in GDPR terms. There is an attempt to align with the vocabulary in the W3C Data Privacy Vocabulary specification.</p> <p>The consent lifecycle will be based on self sovereign identity (SSI) to  ensure that the individual (data subject) has full control of their personal information. To help illustrate how SSI is applied several use cases along a reference implementation will help show the relation between the data subject, data controller and data processor.</p> <p></p>"},{"location":"concepts/0167-data-consent-lifecycle/#concepts","title":"Concepts","text":"<p>These are some ../../concepts that are important to understand when reviewing this RFC.</p> <p>Secondary Data Controller: The terms \"data subject\" and \"data controller\" (see GDPR Article 4, items 1 and 7) should be well understood. The data controller is responsible for the data that is shared beyond their control. A data controller which does not itself collect data but receives it from another controller is termed a 'secondary' data controller. Even though the secondary data controller is independent in its processing of personal data, GDPR requires the primary or original data controller to be responsible for sharing data under the given consent. The 3<sup>rd</sup> party becomes a secondary controller under the responsibility of the original data controller. Important to note that if a 3<sup>rd</sup> party does not share the collected data back to the original data controller, then the 3<sup>rd</sup> party is considered an independent data controller (add reference to CIEU).</p> <p>Opt-in / Opt-out: These terms describe a request to use personal data beyond the limits of legitimate reasons for conducting a service. If for example the data is shared with a 3<sup>rd</sup> party a consent or opt-in is required. At any point the data subject may withdraw the consent through an opt-out.</p> <p>Expiration: The consent may have time limitations that may require being renewed and does not automatically renew. The data subject may have a yearly subscription or for purposes of a trial there needs to be a mechanism to ensure the consent is limited to the duration of the service.</p> <p>Storage limitation: PII data should not be stored indefinitely and need to have a clear storage limitation. Storage limitation as defined by GDPR is limiting how long PII data is kept to fulfill the legitimate reasons of a service.</p> <p>Processing TTL: Indy currently supports proof only limited to a specific point in time. For companies that collect data over time to check for proof every minute is not a viable solution. The processing TTL gives allowances for data ingestion to be done for an extended period without requiring performing new proof request. Examples will be given that explain the usage of the term.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#use-cases","title":"Use Cases","text":"<p>These are the use cases to help understand the implementation guide. A reference implementation will help in the development.</p> <ol> <li> <p>Alice (data subject) gives data consent by accepting a privacy agreement.</p> </li> <li> <p>Acme (3<sup>rd</sup> party data controller) requests proof that data consent     was given</p> </li> <li> <p>Alice terminates privacy agreement, thus withdrawing her data consent.</p> </li> </ol> <p>Note: additional use cases may be developed based on contributions to this RFC.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#implementation-guidelines","title":"Implementation Guidelines","text":""},{"location":"concepts/0167-data-consent-lifecycle/#collect-personal-data","title":"Collect Personal Data","text":"<p>These are the steps covered with collect personal data:</p> <ul> <li>list personal Identifiable data points</li> <li>list quasi-identifiable data points</li> </ul> <p>The [Blinding Identity Taxonomy] provides a compressive list of data points that are considered sensitive and shall be handled with higher level of security.</p> <p>Section will expand terms of the explanation of personal identifiable and quasi-identifiable terms.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#personal-data-processing-schema","title":"Personal Data Processing Schema","text":"<p>The personal data processing (PDP) schema captures attributes used to defines the conditions of collecting data and conditions how data may be shared or used.</p> <p>These are the PDP schema attributes:</p> Category Attribute Brief description Comment Data subset DID of associated schema or overlay Data object identifier All data objects Industry Scope [1] A predefined description of the industry scope of the issuer. All data objects Storage (raw) Expiration Date The definitive date on which data revocation throughout the chain of engaged private data lockers of all Data Controllers and sub-Data Controllers will automatically occur. In other words when the PDP expires. Access-Window Limitation (Restricted-Time) How long data is kept in the system before being removed. Different from expiration date attribute limitation indicates how long personal data may be used beyond the PDP expires. Request to be forgotten supersedes the limitation. Access-Window PII pseudonymization Data stored with pseudonymization. Conditions of access to are given under purpose attribute of \"Access\" category. Encryption Method of psuedonymization Specify algorithm used for performing anonymisation that is acceptable. Encryption Geographic restriction The data storage has geo location restrictions (country). Demarcation No share The data shall not be shared outside of the Data Controller responsibility. When set no 3<sup>rd</sup> party or Secondary Data Controller are allowed. Demarcation Access (1-n) Purpose The purpose for processing data shall be specified (refer to GDPR Article 4, clause 2, for details on processing details). Applies to both a Data Controller and Secondary Data Controller. Access-Window policyUrl Reference to privacy policy URL that describes policy in human readable form. Access-Window Requires 3PP PDP [2] A PDP is required between Data Controller and Secondary Data Controller in the form of code of conduct agreement. Access-Window Single Use The data is shared only for the purpose of completing the interaction at hand. \"Expiration-Date\" is set to the date of interaction completion. Access-Window PII anonymisation Data stored with no PII association. Encryption [3] Method of anonymisation Specify algorithm used for performing anonymisation that is acceptable. Encryption Multi-attribute anonymisation Quasi-identifiable data may be combined create a finger print of the data subject. When set a method of multi-attribute anonymisation is applied on the data Encryption Method of multi-attribute anonymisation Specifify algorithm used for performing anonymisation that is acceptable (K-anonymity). Encryption Ongoing Use The data is shared for repeated use by the recipient, with no end date or end conditions. However, the data subject may alter the terms of use in the future, and if the alteration in terms is unacceptable to the data controller, the data controller acknowledges that it will thereby incur a duty to delete. In other words, the controller uses the data at the ongoing sufferance of its owner. Access-Window Collection Frequency (Refresh) How frequently the data can be accessed. The collection may be limited to once a day or 1 hour. Purpose of attribute is protect data subject to create a profile of behavior. Access-Window Validity TTL If collection is continuous the validity TTL specifies when to perform new verification. Verification is to check customer withdrew consent. Note this is method for revocation. Access-Window No correlation No correlation is allowed for subset. This means no external data shall be combined for example public data record of the data subject. Correlation Inform correlation Correlation is shared with data subject and what data was combined related to them. Correlation Open correlation Correlation is open and does not need to be informed to data subject. Correlation"},{"location":"concepts/0167-data-consent-lifecycle/#notes","title":"Notes","text":""},{"location":"concepts/0167-data-consent-lifecycle/#1","title":"1","text":"<p>As the PDP schema may be the only compulsory linked schema specified in every schema metadata block, we have an opportunity to store the \"Framework Description\" - a description of the business framework of the issuer.</p> <p>Predefined values could be imported from the GICS \"Description\" entries, or, where missing, NECS \"Description\" entries, courtesy of filtration through the Global Industry Classification Standard (GICS) or New Economy Classification Standard (NECS) ontologies.</p> <p>The predefined values could be determined by the next highest level code to the stored GICS \"Sub-industry\" code (or NECS \"SubSector\" code) held in the associated metadata attribute of the primary schema base to add flexibility of choice for the Issuer.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#2","title":"2","text":"<p>If a PDP is required between the Data Controller (Issuer) and sub-Data Controller, we should have a field(s) to store the Public DID (or Private Data Locker ID) of the sub-Data Controller(s). This will be vital to ensure auto-revocation from all associated private data lockers on the date of expiry.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#3","title":"3","text":"<p>As the \"PII Attribute\" schema object is already in place for Issuer's to flag sensitive data according to the Blinding Identity Taxonomy (BIT), we already have a mechanism in place for PII. Once flagged, we can obviously encrypt sensitive data. Some considerations post PII flagging: (i.) In the Issuer's Private Data Locker : The default position should be to encrypt all sensitive elements. However, the issuer should be able to specify if any of the flagged sensitive elements should remain unencrypted in their private locker. (ii.) In a Public Data Store : all sensitive elements should always be encrypted</p>"},{"location":"concepts/0167-data-consent-lifecycle/#example-schemas","title":"Example: Schemas","text":"<p>When defining a schema there will be a consent schema associated with it.</p> <pre><code>SCHEMA = {\n      did: \"did:sov:3214abcd\",\n    name: 'Demographics',\n    description: \"Created by Faber\",\n    version: '1.0',\n    # MANDATORY KEYS\n    attr_names: {\n      brthd: Date,\n      ageic: Integer\n    },\n    consent: did:schema:27312381238123  # reference to consent schema\n    # Attributes flagged according to the Blinding Identity Taxonomy\n    # by the issuer of the schema\n    # OPTIONAL KEYS\n    frmsrc: \"DEM\"\n}\n</code></pre> <p>The original schema will have a consent schema reference.</p> <pre><code>CONSENT_SCHEMA = {\n    did: \"did:schema:27312381238123\",\n    name: 'Consent schema for consumer behaviour data',\n    description: \"Created by Faber\",\n    version: '1.0',\n    # MANDATORY KEYS\n    attr_names: {\n      expiration: Date,\n      limitation: Date,\n      dictatedBy: String,\n      validityTTL: Integer\n    }\n}\n</code></pre> <p>The consent schema will have specific attributes for managing data.</p> Attribute Purpose Type expiration How long consent valid for Date limitation How long is data kept Date dictatedBy Who sets expiration and limitation String validityTTL Duration proof is valid for purposes of data processing Integer <p>The issuer may optionally define an overlay that sets the consent schema values without input from the data subject.</p> <pre><code>CONSENT_RECEIPT_OVERLAY = {\n  did: \"did:sov:5678abcd\",\n  type: \"spec/overlay/1.0/consent_entry\",\n  name: \"Consent receipt entry overlay for clinical trial\",\n  default_values: [\n    :expiration =&gt; 3 years,\n    :limitation =&gt; 2 years,\n    :dictatedBy = &lt;reference to issuer&gt; # ??? Should the DID of the issuer's DID be used?\n    :validityTTL =&gt; 1 month\n    ]\n}\n</code></pre> <p>If some attributes are identified as sensitive based on the Blinding Identity Taxonomy when a sensitivity overlay is created.</p> <pre><code>SENSITIVE_OVERLAY = {\n    did: \"did:sov:12idksjabcd\",\n  type: \"spec/overlay/1.0/bit\",\n  name: \"Sensitive data for private entity\",\n  attributes: [\n      :ageic\n  ]\n}\n</code></pre> <p>To finalise a consent a proof schema has to be created which lists which schemas and overlays applied and values. The proof is kept off ledger in the wallet.</p> <pre><code>PROOF_SCHEMA = {\n    did: \"did:schema:12341dasd\",\n    name: 'Credential Proof schema',\n    description: \"Created by Rosche\",\n    version: '1.0',\n    # MANDATORY KEYS\n    attr_names: {\n      createdAt: DateTime,           # How long consent valid for.\n      proof_key: \"&lt;crypto asset&gt;\",   # How long data is kept.\n      # Include all the schema did that were agreed upon\n      proof_of: [ \"did:sov:3214abcd\", \"did:sov:1234abcd\"]\n    }\n}\n</code></pre>"},{"location":"concepts/0167-data-consent-lifecycle/#blockchain-prerequisites","title":"Blockchain Prerequisites","text":"<p>These are the considerations when setting up the ledger:</p> <ul> <li>Ledger setup</li> <li>Wallet setup</li> <li>Types of entities</li> <li>Agents (working on behalf of entity)</li> <li>Communication between entities</li> <li>Onboarding</li> <li>Onboarding of data subject</li> </ul>"},{"location":"concepts/0167-data-consent-lifecycle/#data-consent-receipt-certificate","title":"Data Consent Receipt Certificate","text":"<p>These are the steps covered with data consent receipt certificate:</p> <ul> <li>initial agreement of privacy agreement</li> <li>update agreement with changed terms of use</li> <li>update agreement with new opt-in</li> <li>terminate agreement</li> <li>apply option to forget</li> </ul>"},{"location":"concepts/0167-data-consent-lifecycle/#initial-agreement-of-privacy-agreement","title":"Initial agreement of privacy agreement","text":"<p>The following flow diagram for setting up privacy agreement.</p> <p></p>"},{"location":"concepts/0167-data-consent-lifecycle/#proof-request","title":"Proof Request","text":"<p>These are the steps covered with proof request:</p> <ul> <li>performing proof request</li> <li>performing proof request without personal data</li> <li>auditing of proof request by Data Authority</li> </ul> <p>The proof request serves multiple purposes. The main one being the conditions of access are auditable. If a data controller encounters a situation they need to show the consent and conditions of accessing data are meet the proof request provides the evidence. The data subject also has more control of the proof request and in situations the revocation of certificate is not performed this becomes an extra safe guard. An important aspect with proof request is that it can be done without requiring to share any personal data.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#performing-proof-request","title":"Performing Proof Request","text":"<p>The following flow diagram for setting up privacy agreement.</p> <p></p>"},{"location":"concepts/0167-data-consent-lifecycle/#certification-revocation","title":"Certification Revocation","text":"<p>These are the steps covered with certification revocation:</p> <ul> <li> <p>data subject initiated revocation</p> </li> <li> <p>data controller initiated revocation</p> </li> <li> <p>data authority initiated revocation (if owns schema base)</p> </li> </ul>"},{"location":"concepts/0167-data-consent-lifecycle/#implementation-reference","title":"Implementation Reference","text":"<p>A python jupyter notebook is available as reference implementation  to help with implementation. The base for this example is  getting-started jupyter notebook. In order to run the example take the following steps.</p> <ol> <li> <p>Clone indy-sdk \\</p> <pre><code> git clone https://github.com/hyperledger/indy-sdk.git\n</code></pre> <ol> <li>Copy over following files to doc/getting-started \\</li> <li>consent-flow.ipynb</li> <li>docker-compose.yml *</li> </ol> <p>Note * - Reason for changing the docker-compose.yml is to be able to    view consent-flow.ipynb.</p> </li> <li> <p>Ready to start docker-compose \\</p> <p>docker-compose up 4. Open html link and run consent-flow.ipynb</p> </li> </ol>"},{"location":"concepts/0167-data-consent-lifecycle/#reference","title":"Reference","text":"<p>Provide guidance for implementers, procedures to inform testing, interface definitions, formal function prototypes, error codes, diagrams, and other technical details that might be looked up. Strive to guarantee that:</p> <ul> <li> <p>Interactions with other ../../features are clear.</p> </li> <li> <p>Implementation trajectory is well defined.</p> </li> <li> <p>Corner cases are dissected by example.</p> </li> <li> <p>General Data Protection Regulation\\     REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE     COUNCIL of 27 April 2016</p> </li> <li> <p>Data Privacy Vocabulary v0.1\\     Draft Community Group Report 26 July 2019\\     [https://www.w3.org/ns/dpv]</p> </li> <li> <p>Hyperledger Aries is infrastructure for blockchain-rooted,     peer-to-peer interactions\\     [https://github.com/hyperledger/aries-rfcs]</p> </li> <li> <p>Overlays\\     [../0013-overlays/README.md]</p> </li> <li> <p>Blinding Identity Taxonomy\\     Created by Andrew Hughes, last modified on Jun 19, 2019\\     [https://kantarainitiative.org/confluence/display/infosharing/Blinding+Identity+Taxonomy]</p> </li> <li> <p>W3C Verifiable Credential     https://www.w3.org/TR/vc-data-model/</p> </li> </ul>"},{"location":"concepts/0167-data-consent-lifecycle/#annex-a-pdp-schema-mapping-to-kantara-consent-receipt","title":"Annex A: PDP Schema mapping to Kantara Consent Receipt","text":"<p>Kantara has defined a Consent Receipt with a list of mandatory and optional attributes. This annex maps the attributes to the PDP. Many of the attributes are supported through the ledger and is not directly included in the PDP.</p> <p>Note: The draft used for this annex was file \"Consent receipt annex for 29184.docx\".</p> Kantara attribute Hyperledger Indy mapping Version Schema registration Jurisdiction Agent registration Consent Timestamp PDP signed certificate Collection Method - Consent Receipt ID PDP signed certificate Public Key Ledger Language Overlays PII Principal ID Schema/Agent registration PII Controller Agent registration On Behalf Agent registration (1) PII Controller Contract Agent registration (2) PII Controller Address Agent registration PII Controller Email Agent registration PII Controller Phone Agent registration PII Controller URL [OPTIONAL] - Privacy Policy PDP services PDP purposes PDP Purpose Category - Consent Type PDP PII Categories - Primary Purpose PDP Termination Ledger Third Party Name PDP Sensitive PII Schema base <p>Notes</p> <p>(1) Agent may be of type Cloud Agent which works on behalf of an Issuer     (Data Controller). When the institution when they register in     blockchain should make it clear who are they registering on behalf.</p> <p>(2) Controller Contact may change over time and is not a good reference     to be used when accepting a consent. If required suggest include as     part of Agent registration (or requirement)</p>"},{"location":"concepts/0167-data-consent-lifecycle/#prior-art","title":"Prior art","text":""},{"location":"concepts/0167-data-consent-lifecycle/#etl-process","title":"ETL process","text":"<p>Current data processing of PII date is not based on blockchain. Data is processed through ETL routines (ex. AWS API Gateway and Lambda) with a data warehouse (ex. AWS Redshift). The enforcement of GDPR is based on adding configuration routines to enforce storage limitations. Most data warehouses do not implement pseudonymization and may instead opt to have a very short storage limitation of a couple of months. The current practice is to collect as much data as possible which goes against data minimisation.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#personal-data-terms-and-conditions","title":"Personal Data Terms and Conditions","text":"<p>The Customer Commons iniative (customercommons.org) has developed a [terms and conditions] for personal data usage. The implementation of these terms and conditions will be tied to the schema and overlay definitions. The overlay will specify the conditions of sharing. For more broader conditions the schema will have new attributes for actual consent for data sharing. The work by Hypeledger Aries and Customer Commons complement each other.</p>"},{"location":"concepts/0167-data-consent-lifecycle/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"concepts/0167-data-consent-lifecycle/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0167-data-consent-lifecycle/#plan","title":"Plan","text":"<ul> <li>Upload consent demo to Indy-sdk</li> </ul>"},{"location":"concepts/0167-data-consent-lifecycle/#todo","title":"ToDo","text":"<ul> <li>Update schema examples</li> </ul>"},{"location":"concepts/0167-data-consent-lifecycle/#comments","title":"Comments","text":"Question From Date Answer Where is consent recorded? Harsh 2019-07-31 There are several types of consent listed below. Where the actual consent is recorded needs Specialised Consent (legal)Generic Consent (legal)General Data Processing Consent"},{"location":"concepts/0207-credential-fraud-threat-model/","title":"0207: Credential Fraud Threat Model","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created. Socialized on an informal credential fraud study group (https://groups.google.com/d/forum/credential-fraud-study) circa 2019.  </li> <li>Start Date: 2019-05-23</li> <li>Tags: concept, credentials</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#summary","title":"Summary","text":"<p>Provides a model for analyzing and preventing fraud with verifiable credentials.</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#motivation","title":"Motivation","text":"<p>Cybersecurity experts often view technology through the lens of a threat model that helps implementers methodically discover and remediate vulnerabilities.</p> <p>Verifiable credentials are a new technology that has enormous potential to shape the digital landscape. However, when used carelessly, they could bring to digital, remote interactions many of the same abuse possibilities that criminals have exploited for generations in face-to-face interactions.</p> <p>We need a base threat model for the specific subdiscipline of verifiable credentials, so implementations and deployments have a clear view of how vulnerabilities might arise, and how they can be eliminated. More specific threat models can build atop this general foundation.</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0207-credential-fraud-threat-model/#scope","title":"Scope","text":"<p>Verifiable credentials are a way to establish trust. They provide value for login, authorization, reputation, and data sharing, and they enable an entire ecosystem of loosely cooperating parties that use different software, follow different business processes, and require different levels of assurance.</p> <p>This looseness and variety presents a challenge. Exhaustively detailing every conceivable abuse in such an ecosystem would be nearly as daunting as trying to model all risk on the internet.</p> <p>This threat model therefore takes a narrower view. We assume the digital landscape (e.g., the internet) as context, with all its vulnerabilities and mitigating best practices. We focus on just the ways that the risks and mitigations for verifiable credential fraud are unique.</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#definition","title":"Definition","text":"<p>Fraud: intentional deception to secure unfair or unlawful gain, or to hurt a victim. Contrast hoax, which is deception for annoyance or entertainment. (paraphrase from Wikipedia)</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#relation-to-familiar-methods","title":"Relation to familiar methods","text":"<p>There are many methods for constructing threat models, including STRIDE, PASTA, LINDDUN, CVSS, and so forth. These are excellent tools. We use insights from them to construct what's offered here, and we borrow some terminology. We recommend them to any issuer, holder, or verifier that wants to deepen their expertise. They are an excellent complement to this RFC.</p> <p>However, this RFC is an actual model, not a method. Also, early exploration of the threat space suggests that with verifiable credentials, patterns of remediation grow more obvious if we categorize vulnerabilities in a specialized way. Therefore, what follows is more than just the mechanical expansion of the STRIDE algorithm or the PASTA process.</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#data-flow-diagram","title":"Data Flow Diagram","text":"<p>Data flows in a verifiable credential ecosystem in approximately the following way:</p> <p></p> <p>Some verifiable credential models include an additional flow (arrow) directly from issuers to verifiers, if they call for revocation to be tested by consulting a revocation list maintained by the issuer.</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#key-questions","title":"Key Questions","text":"<p>Fraud could be categorized in many ways--for example, by how much damage it causes, how easy it is to detect, or how common it is. However, we get predictive power and true insight when we focus on characteristics that lead to different risk profiles and different remediations. For verifiable credentials, this suggests a focus on the following 4 questions:</p> <ol> <li>Who is the perpetrator?</li> <li>Who is directly deceived?</li> <li>When is the deception committed?</li> <li>Where (on which fact) is the deception focused? </li> </ol> <p>We can think of these questions as orthogonal dimensions, where each question is like an axis that has many possible positions or answers. We will enumerate as many answers to these questions as we can, and assign each answer a formal name. Then we can use a terse, almost mathematical notation in the form <code>(w + x + y + z)</code> (where <code>w</code> is an answer to question 1, <code>x</code> is an answer to question 2, and so forth) to identify a fraud potential in 4-dimensional space. For example, a fraud where the holder fools the issuer at time of issuance about subject data might be given by the locus: <code>(liar-holder + fool-issuer + issuance-time + bad-subject-claims)</code>.</p> <p></p> <p>What follows is an exploration of each question and a beginning set of associated answers. We provide at least one example of a situation that embodies each answer, notated with \u21e8. Our catalog is unlikely to be exhaustive; criminal creativity  will find new expressions as we eliminate potential in the obvious places. However, these answers are complete enough to provide significant insight into the risks and remediations in the ecosystem.</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#1-who-is-the-perpetrator","title":"1. Who is the perpetrator?","text":"<ul> <li>1.1 liar-issuer \u21e8 Issuer lies about a fact (e.g., birthdate). \u21e8 Issuer charges to issue a college diploma, but turns out not to be accredited. \u21e8 Issuer signs credential with the wrong key, making it useless.</li> <li>1.2 liar-holder \u21e8 Holder lets a friend use the credential. \u21e8 Holder attests to something that\u2019s not true, that gets incorporated into cred (e.g., claims they haven\u2019t had any seizures lately, as driver\u2019s license is issued--but has actually had them).</li> <li>1.3 liar-subject \u21e8 A subject that is not the holder convinces Issuer of attributes that weren\u2019t actually true. liar-verifier \u21e8 Verifier replays a presentation to impersonate holder.</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#third-parties","title":"third parties","text":"<ul> <li>1.4 fake-issuer \u21e8 charges \u00a350 for a diploma from Oxford, but isn\u2019t actually Oxford.</li> <li>1.5 fake-holder \u21e8 Mallory pretends to be Alice and gets Alice's driver\u2019s license issued to Mallory instead.</li> <li>1.6 fake-verifier \u21e8 Gets holder to prove something to the wrong person.</li> <li>1.7 hacker \u21e8 Hacker alters issuer\u2019s internal DB upon which creds are based. \u21e8 Hacker checks revocation lists on Alice\u2019s credentials to create a fake trail of her proving activities.</li> <li>1.8 malicious-node \u21e8 Malicious node of blockchain reports invalid state of blockchain or revocation upon which validation depends.</li> <li>1.9 malicious-resolver \u21e8 Ledger client or similar claims DID state that is wrong.</li> <li>1.10 malicious-server \u21e8 Serves incorrect revocation list or similar data.</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#combinations","title":"combinations","text":"<ul> <li>1.11 colluding-issuer-holder \u21e8 Deceive verifier by holder presenting and issuer claiming non-revoked cred--but really cred was revoked and the rest of the world knows it.</li> <li>1.12 colluding-issuer-verifier \u21e8 Coordinate to correlate holder without holder knowing. \u21e8 Embed info in the credential that the holder doesn\u2019t realize.</li> <li>1.13 colluding-holder-verifier \u21e8 Deceive issuer about a proving interaction that didn\u2019t actually happen.</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#2-who-is-directly-deceived","title":"2. Who is directly deceived?","text":"<ul> <li>2.1 fool-verifier \u21e8 Present data that doesn\u2019t satisfy a presentation request but convince verifier to accept anyway. \u21e8 Convince verifier to leak data that was proved to them, contrary to terms of use that applied when holder gave data to them.</li> <li>2.2 fool-issuer \u21e8 Convince issuer to reissue without revoking old credential, allowing double spend. \u21e8 Get issuer to issue with faulty data.</li> <li>2.3 fool-holder \u21e8 Verifier gets holder to reveal attributes that are more correlating than they realize, or to reveal without consent. \u21e8 Anonymous person extorts holder claiming to have proof that holder did something embarrassing.</li> <li>2.4 fool-subject \u21e8 Put subject attributes in a credential they didn\u2019t consent to.</li> <li>2.5 fool-auditor \u21e8 Build fake evidence that something was proved when it wasn\u2019t. \u21e8 Remove evidence that something was proved. \u21e8 Build fake evidence that something was NOT proved, when it was. \u21e8 Fake evidence (or evidence that\u2019s circumstantial and true, but irrelevant) presented to law enforcement to harass a holder.</li> <li>2.6 fool-twin \u21e8 A person named \u201cJohn Smith\u201d is extorted with a true credential about \u201cJohn Smith\u201d (a different one) doing something nefarious -- threat to reveal.</li> </ul> <p>Combinations of the above?</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#3-when-is-the-deception-committed","title":"3. When is the deception committed?","text":"<ul> <li>3.1 connection-time \u21e8 insert MITM when two identities first connect--but possibly don\u2019t take advantage of the redirection until a strategic time in the future.</li> <li>3.2 proving-time \u21e8 Get verifier to believe the wrong thing from the presentation.</li> <li>3.3 post-proving-time \u21e8 Lull verifier into continuing to believe something that\u2019s no longer true, but that was true when it was proved long ago.</li> <li>3.4 revocation-time \u21e8 MITM pretends to record revocation but doesn\u2019t actually do so.</li> <li>3.5 revocation-check-time \u21e8 MITM serves up bogus revocation data.</li> <li>3.6 cache-refresh-time \u21e8 Malware on Verifier system changes local record of how long it\u2019s been since testing credential, delaying a needed check.</li> <li>3.7 cache-check-time</li> <li>3.8 before-issuance-time \u21e8 Convince the issuer of something untrue that will alter what they attest about the subject.</li> <li>3.9 issuance-time \u21e8 Issue to the wrong person. \u21e8 Issue twice when intention was one cred per person.</li> <li>3.10 post-issuance-time \u21e8 Convince issuer to revoke for no good reason.</li> <li>3.11 multi-time \u21e8 Fraud must happen at two or more different times to accomplish its objective.</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#4-where-on-which-fact-is-the-deception-focused","title":"4. Where (on which fact) is the deception focused?","text":""},{"location":"concepts/0207-credential-fraud-threat-model/#identity","title":"identity","text":"<ul> <li>4.1 bad-holder-identity \u21e8 Impersonate holder by proving with a device that the holder doesn\u2019t control.</li> <li>4.2 bad-subject-identity \u21e8 Put the wrong father in a birth certificate.</li> <li>4.3 bad-issuer-identity \u21e8 Sign credential with a key belonging to the IRS\u2019s HR department instead of the IRS\u2019s main government agency key.</li> <li>4.4 bad-verifier-identity \u21e8 Get prover to prove something to a MITM pretending to be the legitimate verifier.</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#claims","title":"claims","text":"<ul> <li>4.5 bad-subject-claims</li> <li>4.6 inadequate-claims \u21e8 Get verifier to assume something beyond what the evidence actually supports.</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#context","title":"context","text":"<ul> <li>4.7 bad-timestamp \u21e8 Fraud hinges on claiming a different time for an event than the time it actually occurred.</li> <li>4.8 bad-ledger-read \u21e8 Malicious ledger client returns incorrect data from a query of the ledger. </li> <li>4.9 bad-ledger-write \u21e8 Malicious ledger client alters data before writing it to the ledger.</li> <li>4.10 bad-revoc-read \u21e8 False revocation status is reported when a revocation list or revocation registry is read.</li> <li>4.11 bad-revoc-write \u21e8 Revocation status is not updated when a request to update is submitted.</li> <li>4.12 bad-payment \u21e8 A payment amount, timestamp, or responsibile party is falsified.</li> <li>4.13 bad-did-resolve \u21e8 Invalid or stale results are returned when a DID is resolved.</li> <li>4.14 bad-tamper-check \u21e8 Data is tampered with, but the tampering is not detected.</li> <li>4.15 missing-evidence \u21e8 Issuer subverts audit by removing evidence that they discriminated when a loan was issued.</li> <li>4.16 bad-evidence \u21e8 Issuer subverts audit by creating falsified evidence that they behaved properly when a loan was issued.</li> <li>4.17 bad-compliance \u21e8 Verifier asserts to government or to holder that they\u2019ve complied with GDPR, but this is not actually true.</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#reference","title":"Reference","text":"<p>Provide guidance for implementers, procedures to inform testing, interface definitions, formal function prototypes, error codes, diagrams, and other technical details that might be looked up. Strive to guarantee that:</p> <ul> <li>Interactions with other ../../features are clear.</li> <li>Implementation trajectory is well defined.</li> <li>Corner cases are dissected by example.</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#prior-art","title":"Prior art","text":"<p>Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:</p> <ul> <li>Does this feature exist in other SSI ecosystems and what experience have their community had?</li> <li>For other teams: What lessons can we learn from other attempts?</li> <li>Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.</li> </ul> <p>This section is intended to encourage you as an author to think about the lessons from other implementers, provide readers of your proposal with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if they are an adaptation from other communities.</p> <p>Note that while precedent set by other communities is some motivation, it does not on its own motivate an enhancement proposal here. Please also take into consideration that Aries sometimes intentionally diverges from common identity ../../features.</p>"},{"location":"concepts/0207-credential-fraud-threat-model/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"concepts/0207-credential-fraud-threat-model/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0217-linkable-message-paths/","title":"Aries RFC 0217: Linkable Message Paths","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Start Date: 2019-08-26</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0217-linkable-message-paths/#summary","title":"Summary","text":"<p>Describes how to hyperlink to specific elements of specific DIDComm messages.</p>"},{"location":"concepts/0217-linkable-message-paths/#motivation","title":"Motivation","text":"<p>It must be possible to refer to specific pieces of data in specific DIDComm messages. This allows a message later in a protocol to refer to data in a message that preceded it, which is useful for stitching together subprotocols, debugging, error handling, logging, and various other scenarios.</p>"},{"location":"concepts/0217-linkable-message-paths/#tutorial","title":"Tutorial","text":"<p>There are numerous approaches to the general problem of referencing/querying a piece of data in a JSON document. We have chosen JSPath as our solution to that part of the problem; see Prior Art for a summary of that option and a comparison to alternatives.</p> <p>What we need, over and above JSPath, is a URI-oriented way to refer to an individual message, so the rest of the referencing mechanism has a JSON document to start from.</p>"},{"location":"concepts/0217-linkable-message-paths/#didcomm-message-uris","title":"DIDComm Message URIs","text":"<p>A DIDComm message URI (DMURI) is a string that references a sent/received message, using standard URI syntax as specified in RFC 3986. It takes one of the following forms:</p> <ol> <li><code>didcomm://&lt;thid&gt;/&lt;msgid&gt;</code></li> <li><code>didcomm://./&lt;msgid&gt;</code> or <code>didcomm://../&lt;msgid&gt;</code></li> <li><code>didcomm:///&lt;msgid&gt;</code> (note 3 slashes)</li> <li><code>didcomm://&lt;sender&gt;@&lt;thid&gt;/&lt;senderorder&gt;</code></li> </ol> <p>Here, <code>&lt;msgid&gt;</code> is replaced with the value of the <code>@id</code> property of a plaintext DIDComm message; <code>&lt;thid&gt;</code> is replaced with the <code>~thread.thid</code> property, <code>&lt;sender&gt;</code> is replaced with a DID, and <code>&lt;senderorder&gt;</code> is replaced with a zero-based index (the Nth message emitted in the thread by that sender). </p> <p>Form 1 is called absolute form, and is the prefered form of DMURI to use when talking about messages outside the context of an active thread (e.g., in log files)</p> <p>Form 2 is called relative form, and is a convenient way for one message to refer to another within an ongoing interaction. It is relatively explicit and terse. It uses 1 or 2 dots to reference the current or parent thread, and then provides the message id with that thread as context. Referencing more distant parent threads is done with absolute form.</p> <p>Form 3 is called simple form. It omits the thread id entirely. It is maximally short and usually clear enough. However, it is slightly less preferred than forms 1 and 2 because it is possible that some senders might not practice good message ID hygeine that guarantees global message ID uniqueness. When that happens, a message ID could get reused, making this form ambiguous. The most recent message that is known to match the message id must be assumed.</p> <p>Form 4 is called ordered form. It is useful for referencing a message that was never received, making the message's internal <code>@id</code> property unavailable. It might be used to request a resend of a lost message that is uncovered by the gap detection mechanism in DIDComm's message threading.</p> <p>Only parties who have sent or received messages can dereference DMURIs. However, the URIs should be transmittable through any number of third parties who do not understand them, without any loss of utility.</p>"},{"location":"concepts/0217-linkable-message-paths/#combining-a-dmuri-with-a-jspath","title":"Combining a DMURI with a JSPath","text":"<p>A JSPath is concatenated to a DMURI by using an intervening slash delimiter:</p> <p><code>didcomm:///e56085f9-4fe5-40a4-bf15-6438751b3ae8/.~timing.expires_time</code></p> <p>If a JSPath uses characters from RFC 3986's reserved characters list in a context where they have special meaning, they must be percent-encoded.</p>"},{"location":"concepts/0217-linkable-message-paths/#reference","title":"Reference","text":"<p>Provide guidance for implementers, procedures to inform testing, interface definitions, formal function prototypes, error codes, diagrams, and other technical details that might be looked up. Strive to guarantee that:</p> <ul> <li>Interactions with other ../../features are clear.</li> <li>Implementation trajectory is well defined.</li> <li>Corner cases are dissected by example.</li> </ul>"},{"location":"concepts/0217-linkable-message-paths/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"concepts/0217-linkable-message-paths/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"concepts/0217-linkable-message-paths/#prior-art","title":"Prior art","text":"<ul> <li>JSPath: the one we're using. Simple and relatively current, with clean syntax.</li> <li>JSONPath: superseded by JSONQuery</li> <li>JSONQuery: also looks a bit old</li> <li>JSONSelect: old. More like CSS selectors</li> <li>JSONiq: powerful and current, but focuses more on querying; may be overkill for just referencing a subobject</li> </ul>"},{"location":"concepts/0217-linkable-message-paths/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"concepts/0217-linkable-message-paths/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0231-biometric-service-provider/","title":"Aries RFC 0231: Biometric Service Provider","text":"<ul> <li>Authors: John Callahan, Daniel Hardman, Asem Othman</li> <li>Status: PROPOSED</li> <li>Since: 2019-09-24</li> <li>Status Note: Proposed for now based on authors joint work</li> <li>Start Date: 2019-06-01</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0231-biometric-service-provider/#summary","title":"Summary","text":"<p>Biometric services for Identity Verification, Authentication, Recovery and other use cases referred to in Aries RFCs including DKMS.</p>"},{"location":"concepts/0231-biometric-service-provider/#motivation","title":"Motivation","text":"<p>Biometrics play a special role in many identity use cases because of their ability to intrinsically identify a unique individual, but their use depends on a variety of factors including liveness, matching accuracy, ease of acquisition, security and privacy. Use of biometrics is already well established in most countries for domestic and international travel, banking and law enforcement.  In banking, know-your-customer (KYC) and anti-money laundering (AML) laws require some form of biometric(s) when establishing accounts.</p> <p>In this specification, we characterize the functions and schema that biometric service providers (BSPs) must implement to ensure a uniform interface to clients: wallets and agents.  For example, current Automated Biometric Information Systems (ABIS) and other standards (IEEE 2410, FIDO) provide a subset of services but often require proprietary adaptors due to the fragmented history of the biometric market: different modalities (face, fingerprint, iris, etc.) require different functions, schema, and registration information.  More recently, standards have begun to specify functions and schema across biometric modalities.  This specification will adopt these approaches and treat biometric data within an encrypted envelope across modalities.</p>"},{"location":"concepts/0231-biometric-service-provider/#tutorial","title":"Tutorial","text":"<p>One goal of the Biometric Service Provider (BSP) specification is to allow for self-sovereign biometric credentials in a holder's wallet or cloud agent trusted by issuers and verifiers:</p> <p></p> <p>An issuer may collect biometric information from a holder in order to issue credentials (biometric or not). Likewise, a verifier may require biometric matching against the holder's credentials for authentication.  In either case, issuers, holders and verifiers may need to rely on 3<sup>rd</sup> party services to perform biometric matching functions for comparison to authoritative databases.</p>"},{"location":"concepts/0231-biometric-service-provider/#basics","title":"Basics","text":"<p>In general, biometrics are collected during registration from a person and stored for later comparisons.  The registration data is called the Initial Biometric Vector (IBV).  During subsequent sessions, a biometric reading is taken called the Candidate Biometric Vector (CBV) and \"matched\" to the IBV:</p> <p></p> <p>Both the IBV and CBV must be securely stored on a mobile device or server often with the help of hardware-based encryption mechanisms such as a Trusted Execution Environment (TEE) or Hardware Security Module (HSM).  The CBV is typically ephemeral and discarded (using secure erasure) following the match operation.</p> <p>If the IBV and/or CBV are used on a server, any exchange must use strong encryption between client and server if transmitted over public or private networks in case of interception.  Failure to properly protect the collection, transmission, storage and processing of biometric data is a serious offense in most countries and violations are subject to severe fines and/or imprisonment.</p>"},{"location":"concepts/0231-biometric-service-provider/#example-aadhaar","title":"Example: Aadhaar","text":"<p>The Aadhaar system is an operational biometric that provides identity proofing and identity verification services for over 1 billion people in India.  Aadhaar is comprised of many elements with authentication as the most common use case:</p> <p></p> <p>Authentication Service Agents (ASAs) are licensed by the Government of India to pass the verification request via secure channels to the Unique Identification Authority of India (UIDAI) data centre where IBVs are retrieved and matched to incoming CBVs from Authentication User Agencies (AUA) that broker user authentication sessions from point-of-sale (PoS) terminals:</p>"},{"location":"concepts/0231-biometric-service-provider/#use-cases","title":"Use Cases","text":"<p>A Biometric Service Provider (BSP) supports the following use cases. In each case, we distinguish whether the use case requires one-to-one (1:1) matching or one-to-many (1:N) matching:</p> <ol> <li> <p>Device Unlocking - primarily introduced to solve the inconvenience of typing a password into a small mobile device, face and single-digit fingerprint was introduced to mobile devices to protect access to the device resources.  This is a 1:1 match operation.</p> </li> <li> <p>Authentication - the dominant use case for biometrics.  Users must prove they sufficiently match the IBV created during registration in order to access local and remote resources including doors, cars, servers, etc. This is a 1:1 match operation.</p> </li> <li> <p>Identification - an unknown person presents for purposes of determining their identity against a database of registered persons. This is a 1:N match operation because the database(s) must be searched for all IBVs of matching identities.</p> </li> <li> <p>Identity Verification - a person claims a specific identity with associated metadata (e.g., name, address, etc.) and provides a CBV for match against that person's registered biometric data to confirm the claim.  This is a 1:1 match operation.</p> </li> <li> <p>Identity Proofing - a person claims a specific identity with associated metadata (e.g., name, address, etc.) and provides a CBV for match against all persons in database(s) in order to determine the efficacy of their claims and any counter-claims.  This is a 1:N match operation because the database(s) must be searched for all IBVs of matching identities.</p> </li> <li> <p>Deduplication - given a CBV, match against IBVs of all registered identities to determine if already present or not in the database(s). This is a 1:N matching operation.</p> </li> <li> <p>Fraud prevention - A match operation could return confidence score(s) (0..1) rather than a simply boolean.  Confidence score(s) express the probability that the candidate is not an imposter and could be used in risk analysis engines.  This may be a use case for BSP clients.</p> </li> <li> <p>Recovery - Using biometric shards, a process using one's biometrics to recover lost private keys associated with a credential is possible using secret sharing.  This may be a use case for BSP clients.</p> </li> </ol> <p>The previous diagram describing the IBV and CBV collection and matching during registration and presentation did not specify where the IBV is persisted nor where the match operation is performed.  In general, we can divide the use cases into 4 categories depending on where the IBV is persisted and where the match must occur:</p> <p></p> <p>Mobile-Mobile: The IBV is stored on the mobile device and the match with the CBV occurs on the mobile device</p> <p>Mobile-Server: The IBV is stored on the mobile device, but the match occurs on a server</p> <p>Server-Mobile: The IBV is stored on a server, but the match occurs on a mobile device</p> <p>Server-Server: The IBV is stored on a server and the match occurs on a server</p>"},{"location":"concepts/0231-biometric-service-provider/#use-case-1-identity-proofing","title":"Use case 1: Identity Proofing","text":""},{"location":"concepts/0231-biometric-service-provider/#use-case-2-recovery","title":"Use case 2: Recovery","text":""},{"location":"concepts/0231-biometric-service-provider/#reference","title":"Reference","text":"<p>The NIST 800-63-3 publications are guidelines that establish levels of assurance (LOA) for identity proofing (Volume A), authentication (Volume B), and federation (Volume C).  The Biometric Service Provider (BSP) specification deals primarily with identity proofing and authentication.</p> <p>A common misconception is that a biometric is like a password, but cannot be replaced upon loss or compromise.  A biometric is private but not secret, whereas a password is secret and private.  Used correctly, biometrics require presentation attack detection (PAD), also called liveness, to ensure that the sensor is presented with a live face, fingerprints, etc. of a subject rather than a spoof, i.e., a photo, fake fingertips, etc.  Indeed, NIST 800-63-3B requires presence of a person in front of a witness for Identity Assurance Level 3 (IAL3) in identity proofing use cases.NIST characterizes the identity proofing process as follows:</p> <p></p> <p>Remote use of biometrics is increasing as well to streamline on-boarding and recovery processes without having to present to an official.  NIST 800-63-3A introduced remote identity proofing for IAL2 in 2017 with some form of PAD strongly recommended (by reference to NIST 800-63-3B).  Typically, additional measures are combined with biometrics including knowledge-based authentication (KBA), risk scoring and document-based verification to reduce fraud.  </p>"},{"location":"concepts/0231-biometric-service-provider/#protection","title":"Protection","text":"<p>Biometric data is highly sensitive and must be protected wherever and whenever it is collected, transmitted, stored and processed.  In general, some simple rules of thumb include:</p> <ul> <li>Protect biometric data at collection (sensor safeguards)</li> <li>Protect biometric data at rest (special hardware, TPM/TEE, database encryption)</li> <li>Protect biometric data in transit (encrypted communications)</li> <li>Protect biometric data during match (volatile memory protections)</li> <li>Never log biometric data!</li> <li>The Candidate Biometric Vector (CBV) is ephemeral</li> </ul>"},{"location":"concepts/0231-biometric-service-provider/#issues","title":"Issues","text":"<ul> <li>Should define biometric verifiable credential schema(s)</li> <li>Biometric modality agnostic</li> <li>Accommodate Biometric shards</li> <li>Integrate with Ursa crypto</li> <li>Integrate with service endpoint model</li> <li>Allows Issuers, Verifiers, and Holder wallets &amp; agents to invoke services like:</li> <li>Registration </li> <li>Matching</li> <li>Deduplication</li> <li>Verification</li> <li>Provides new services</li> <li>Fuzzy matching</li> <li>Shard management (for DKMS) including Horcrux-based storage options</li> <li>Holder-specific biometric matching \u201cmachine\u201d (using ZK-STARKs)</li> <li>Compatible with trust relationships</li> <li>Supports DID connections/Trust relationships (Holder \u27f7 BSP \u27f7 Verifier)</li> </ul>"},{"location":"concepts/0231-biometric-service-provider/#drawbacks","title":"Drawbacks","text":"<p>Biometrics are explicitly required in many global regulations including NIST (USA), Aadhaar (India), INE (Mexico), and RENIEC (Peru) but also standardized by international organizations for travel (IATA) and finance (FATF).</p>"},{"location":"concepts/0231-biometric-service-provider/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>By addressing biometrics, we seek to provide explicit guidance to developers who will undoubtedly encounter them in many identity credentialing and authentication processes.</p>"},{"location":"concepts/0231-biometric-service-provider/#prior-art","title":"Prior art","text":"<p>Several biometric standards exist that provide frameworks for biometric services including the FIDO family of standards and IEEE 2410.  Within each biometric modality, standards exist to encode representations of biometric information.  For example, fingerprints can be captured as raw images in JPEG or PNG format but also represented as vectors of minutiae encoded in the WSQ format.</p>"},{"location":"concepts/0231-biometric-service-provider/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What is the threat model?</li> <li>Alignment with other RFCs</li> <li>Distributed Key Management RFC (Open Issues and Future Work section)</li> <li>Credential Fraud RFC (Threat model, Patterns &amp; Anti-Patterns)</li> <li>Relation to</li> <li>IEEE 2410 (BOPS)</li> <li>FIDO and new FIDO IDWG (Identity Verification)</li> </ul>"},{"location":"concepts/0231-biometric-service-provider/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0250-rich-schemas/","title":"RFC 0250: Rich Schema Objects","text":"<ul> <li>Author: Ken Ebert, Brent Zundel</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No recent progress and no implementations have been created.</li> <li>Supersedes: this HIPE</li> <li>Start Date: 2019-03-19</li> <li>Tags: concept, rich-schemas</li> </ul>"},{"location":"concepts/0250-rich-schemas/#summary","title":"Summary","text":"<p>A high-level description of the components of an anonymous credential ecosystem that supports rich schemas, W3C Verifiable Credentials and Presentations, and correspondingly rich presentation requests. Rich schemas are hierarchically composable graph-based representations of complex data. For these rich schemas to be incorporated into the aries anonymous credential ecosystem, we also introduce such objects as mappings, encodings, presentation definitions and their associated contexts.</p> <p>Though the goal of this RFC is to describe how rich schemas may be used with anonymous credentials, it will be noted that many of the objects described here may be used to allow any credential system to make use of rich schemas.</p> <p>This RFC provides a brief description of each rich schema object. Future RFCs will provide greater detail for each individual object and will be linked to from this document. The further RFCs will contain examples for each object.</p>"},{"location":"concepts/0250-rich-schemas/#motivation","title":"Motivation","text":""},{"location":"concepts/0250-rich-schemas/#standards-compliance","title":"Standards Compliance","text":"<p>The W3C Verifiable Claims Working Group (VCWG) will soon be releasing a verifiable credential data model. This proposal introduces aries anonymous credentials and presentations which are in compliance with that standard.</p>"},{"location":"concepts/0250-rich-schemas/#interoperability","title":"Interoperability","text":"<p>Compliance with the VCWG data model introduces the possibility of interoperability with other credentials that also comply with the standard. The verifiable credential data model specification is limited to defining the data structure of verifiable credentials and presentations. This includes defining extension points, such as \"proof\" or \"credentialStatus.\"</p> <p>The extensions themselves are outside the scope of the current specification, so interoperability beyond the data model layer will require shared understanding of the extensions used. Work on interoperability of the extensions will be an important aspect of maturing the data model specification and associated protocols.</p> <p>Additionally, the new rich schemas are compatible with or the same as existing schemas defined by industry standards bodies and communities of interest. This means that the rich schemas should be interoperable with those found on schema.org, for example. Schemas can also be readily defined for those organizations that have standards for data representation, but who do not have an existing formal schema representation.</p>"},{"location":"concepts/0250-rich-schemas/#shared-semantic-meaning","title":"Shared Semantic Meaning","text":"<p>The rich schemas and associated constructs are linked data objects that have an explicitly shared context. This allows for all entities in the ecosystem to operate with a shared vocabulary.</p> <p>Because rich schemas are composable, the potential data types that may be used for field values are themselves specified in schemas that are linked to in the property definitions. The shared semantic meaning gives greater assurance that the meaning of the claims in a presentation is in harmony with the semantics the issuer intended to attest when they signed the credential.</p>"},{"location":"concepts/0250-rich-schemas/#improved-predicate-proofs","title":"Improved Predicate Proofs","text":"<p>Introducing standard encoding methods for most data types will enable predicate proof support for floating point numbers, dates and times, and other assorted measurements. We also introduce a mapping object that ties intended encoding methods to each schema property that may be signed so that an issuer will have the ability to canonically specify how the data they wish to sign maps to the signature they provide.</p>"},{"location":"concepts/0250-rich-schemas/#use-of-json-ld","title":"Use of JSON-LD","text":"<p>Rich schema objects primarily wish to benefit from the accessibility of ordinary JSON, but require more sophisticated JSON-LD-driven patterns when the need arises.</p> <p>Each rich schema object will specify the extent to which it supports JSON-LD functionality, and the extent to which JSON-LD processing may be required.</p>"},{"location":"concepts/0250-rich-schemas/#what-the-casual-developer-needs-to-know","title":"What the Casual Developer Needs to Know","text":"<ul> <li> <p>The <code>@</code> character in rich schema objects is reserved for JSON-LD-isms. Any usage of JSON keys that begin with this character is required to be JSON-LD-compatible, and any time you see it, you are seeing JSON-LD at work.</p> </li> <li> <p><code>@context</code> and <code>@type</code> are required at the root of every object. The meaning of these fields in rich schema objects matches JSON-LD's expectations, but you don't need to learn JSON-LD to use them.</p> </li> <li> <p>JSON-LD's more advanced mechanisms are an option--not invoked ad hoc for every type of rich schema object, but specified in the formal description of each rich schema object. Most rich schema objects use no more JSON-LD than <code>@context</code>, <code>@type</code>, and <code>@id</code>.</p> </li> </ul>"},{"location":"concepts/0250-rich-schemas/#details","title":"Details","text":"<p>Compatibility with JSON-LD was evaluated against version 1.1 of the JSON-LD spec, current in early 2019. If material changes in the spec are forthcoming, a new analysis may be worthwhile. Our current understanding follows.</p>"},{"location":"concepts/0250-rich-schemas/#type","title":"<code>@type</code>","text":"<p>The type of an rich schema object, or of an embedded object within a rich schema object, is given by the JSON-LD <code>@type</code> property. JSON-LD requires this value to be an IRI.</p>"},{"location":"concepts/0250-rich-schemas/#id","title":"<code>@id</code>","text":"<p>The identifier for a rich schema object is given by the JSON-LD <code>@id</code> property. JSON-LD requires this value to be an IRI.</p>"},{"location":"concepts/0250-rich-schemas/#context","title":"<code>@context</code>","text":"<p>This is JSON-LD\u2019s namespacing mechanism. It is active in rich schema objects, but can usually be ignored for simple processing, in the same way namespaces in XML are often ignored for simple tasks.</p> <p>Every rich schema object has an associated <code>@context</code>, but for many of them we have chosen to follow the procedure described in section 6 of the JSON-LD spec, which focuses on how ordinary JSON can be interpreted as JSON-LD.</p> <p>Contexts are JSON objects. They are the standard mechanism for defining shared semantic meaning among rich schema objects. Contexts allow schemas, mappings, presentations, etc. to use a common vocabulary when referring to common attributes, i.e. they provide an explicit shared semantic meaning.</p>"},{"location":"concepts/0250-rich-schemas/#ordering","title":"Ordering","text":"<p>JSON-LD specifies that the order of items in arrays is NOT significant, and notes that this is the opposite of the standard assumption for plain JSON. This makes sense when viewed through the lens of JSON-LD\u2019s role as a transformation of RDF, and is a concept supported by rich schema objects.</p>"},{"location":"concepts/0250-rich-schemas/#tutorial","title":"Tutorial","text":"<p>The object ecosystem for anonymous credentials that make use of rich schemas has a lot of familiar items: credentials, credential definitions, schemas, and presentations. Each of these objects has been changed, some slightly, some more significantly, in order to take advantage of the benefits of contextually rich linked schemas and W3C verifiable credentials. More information on each of these objects can be found below.</p> <p>In addition to the familiar objects, we introduce some new objects: contexts, mappings, encodings, and presentation definitions. These serve to bridge between our current powerful signatures and the rich schemas, as well as to take advantage of some of the new capabilities that are introduced.</p> <p> Relationship graph of rich schema objects </p>"},{"location":"concepts/0250-rich-schemas/#verifiable-credentials","title":"Verifiable Credentials","text":"<p>The Verifiable Claims Working Group of the W3C is working to publish a Verifiable Credentials data model specification. Put simply, the goal of the new data format for anonymous credentials is to comply with the W3C specification.</p> <p>The data model introduces some standard properties and a shared vocabulary so that different producers of credentials can better inter-operate.</p>"},{"location":"concepts/0250-rich-schemas/#rich-schemas","title":"Rich Schemas","text":"<p>The proposed rich schemas are JSON-LD objects. This allows credentials issued according to them to have a clear semantic meaning, so that the verifier can know what the issuer intended. They also support explicitly typed properties and semantic inheritance. A schema may include other schemas as property types, or extend another schema with additional properties. For example a schema for \"employee\" may inherit from the schema for \"person.\"</p> <p>Rich schemas are an object that may be used by any verifiable credential system.</p>"},{"location":"concepts/0250-rich-schemas/#mappings","title":"Mappings","text":"<p>Rich schemas are complex, hierarchical, and possibly nested objects. The Camenisch-Lysyanskaya signature scheme used in anonymous credentials requires the attributes to be represented by an array of 256-bit integers. Converting data specified by a rich schema into a flat array of integers requires a mapping object.</p> <p>Mappings serve as a bridge between rich schemas and the flat array of signed integers. A mapping specifies the order in which attributes are transformed and signed. It consists of a set of graph paths and the encoding used for the attribute values specified by those graph paths. Each claim in a mapping has a reference to an encoding, and those encodings are defined in encoding objects.</p> <p>Mappings are written to a data registry so they can be shared by multiple credential definitions. They need to be discoverable. When a mapping has been created or selected by an issuer, it is made part of the credential definition.</p> <p>The mappings serve as a vital part of the verification process. The verifier, upon receipt of a presentation must not only check that the array of integers signed by the issuer is valid, but that the attribute values were transformed and ordered according to the mapping referenced in the credential definition.</p> <p>Note: The anonymous credential signature scheme introduced here is Camenisch-Lysyanskaya signatures. It is the use of this signature scheme in combination with rich schema objects that necessitates a mapping object. If another signature scheme is used which does not have the same requirements, a mapping object may not be necessary or a different mapping object may need to be defined.</p>"},{"location":"concepts/0250-rich-schemas/#encodings","title":"Encodings","text":"<p>All attribute values to be signed in an anonymous credential must be transformed into 256-bit integers in order to support the current Camenisch-Lysyanskaya signature scheme.</p> <p>The introduction of rich schemas and their associated range of possible attribute value data types require correspondingly rich encoding algorithms. The purpose of the encoding object is to specify the algorithm used to perform transformations for each attribute value data type. The encoding algorithms will also allow for extending the cryptographic schemes and various sizes of encodings (256-bit, 384-bit, etc.). The encoding algorithms will allow for broad use of predicate proofs, and avoid hashed values where they are not needed, as hashed values do not support predicate proofs.</p> <p>Encodings, at their heart, describe an algorithm for converting data from one format to another, in a deterministic way. They can therefore be used in myriad ways, not only for the values of attributes within anonymous credentials.</p> <p>Encoding objects are written to a data registry. Encoding objects also allow for a means of extending the standard set of encodings.</p>"},{"location":"concepts/0250-rich-schemas/#credential-definitions","title":"Credential Definitions","text":"<p>Credential definitions provide a method for issuers to specify a schema and mapping object, and provide public key data for anonymous credentials they issue. This ties the schema and public key data values to the issuer. The verifier uses the credential definition to check the validity of each signed credential attribute presented to the verifier.</p>"},{"location":"concepts/0250-rich-schemas/#presentation-definitions","title":"Presentation Definitions","text":"<p>A presentation definition is the means whereby a verifier asks for data from a holder. It contains a set of named desired proof attributes with corresponding restrictions that limit the potential sources for the attribute data according to the desired source schema, issuer DID, credential definition, etc. A presentation definition also contains a similar set of requested predicate proofs, with named attributes and restrictions.</p> <p>It may be helpful to think of a presentation definition as the mirror image of a mapping object. Where a mapping object specifies the graph paths of the attributes to be signed, a presentation definition specifies the graph query that may be fulfilled by such graph paths. The presentation definition does not need to concern itself with specifying a particular mapping that contains the desired graph paths, any mapping that contains those graph paths may be acceptable. The fact that multiple graph paths might satisfy the query adds some complexity to the presentation definition. The query may also restrict the acceptable set of issuers and credential definitions and specify the desired predicates.</p> <p>A presentation definition is expressed using JSON-LD and may be stored in a data registry. This supports re-use, interoperability, and a much richer set of communication options. Multiple verifiers can use the same presentation definitions. A community may specify acceptable presentation definitions for its verifiers, and this acceptable set may be adopted by other communities. Credential offers may include the presentation definition the issuer would like fulfilled by the holder before issuing them a credential. Presentation requests may also be more simply negotiated by pointing to alternative acceptable presentation definitions. Writing a presentation definition to a data registry also allows it to be publicly reviewed for privacy and security considerations and gain or lose reputation.</p> <p>Presentation definitions specify the set of information that a verifier wants from a holder. This is useful regardless of the underlying credential scheme.</p>"},{"location":"concepts/0250-rich-schemas/#presentations","title":"Presentations","text":"<p>The presentation object that makes use of rich schemas is defined by the W3C Verifiable Credentials Data Model, and is known in the specification as a verifiable presentation. The verifiable presentation is defined as a way to present multiple credentials to a verifier in a single package.</p> <p>As with most rich schema objects, verifiable presentations will be useful for credential systems beyond anonymous credentials.</p> <p>The claims that make up a presentation are specified by the presentation definition. For anonymous credentials, the credentials from which these claims originate are used to create new derived credentials that only contain the specified claims and the cryptographic material necessary for proofs. </p> <p>The type of claims in derived credentials is also specified by the presentation definition. These types include revealed and predicate proof claims, for those credential systems which support them. </p> <p>The presentation contains the cryptographic material needed to support a proof that source credentials are all held by the same entity. For anonymous credentials, this is accomplished by proving knowledge of a link secret.</p> <p>A presentation refers to the presentation definition it fulfills. For anonymous credentials, is also refers to the credential definitions on the data registry associated with the source credentials. A presentation is not stored on a data registry.</p> <p>The following image illustrates the relationship between anonymous credentials and presentations:</p> <p></p>"},{"location":"concepts/0250-rich-schemas/#presentation-description","title":"Presentation Description","text":"<p>There may be a number of ways a presentation definition can be used by a holder to produce a presentation, based on the graph queries and other restrictions in the presentation definition. A presentation description describes the source credentials and the process that was used to derive a presentation from them.</p>"},{"location":"concepts/0250-rich-schemas/#reference","title":"Reference","text":"<p>This document draws on a number of other documents, most notably the W3C verifiable credentials and presentation data model.</p> <p>The signature types used for anonymous credentials are the same as those currently used in Indy's anonymous credential and Fabric's idemix systems. Here is the paper that defines Camenisch-Lysyanskaya signatures. They are the source for Indy's AnonCreds protocol.</p>"},{"location":"concepts/0250-rich-schemas/#drawbacks","title":"Drawbacks","text":"<ul> <li> <p>Rich schemas are complex.</p> </li> <li> <p>The formats rely largely on JSON-LD serialization and may be dependent on full or limited JSON-LD processing.</p> </li> </ul>"},{"location":"concepts/0250-rich-schemas/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>This design has the following benefits:   - It complies with the upcoming Verifiable Credentials standard.   - It allows for interoperability with existing schemas, such as those   found on schema.org.   - It adds security guarantees by providing means for validation of   attribute encodings.   - It allows for a broad range of value types to be used in predicate   proofs.   - It introduces presentation definitions that allow for proof   negotiation, rich presentation specification, and an assurance   that the presentation requested complies with security and privacy   concerns.   - It supports discoverability of schemas, mappings, encodings,   presentation definitions, etc.</p>"},{"location":"concepts/0250-rich-schemas/#unresolved-questions","title":"Unresolved questions","text":"<p>This technology is intended for implementation at the SDK API level. It does not address UI tools for the creation or editing of these objects.</p> <p>Variable length attribute lists are only partially addressed using mappings. Variable lists of attributes may be specified by a rich schema, but the maximum number of attributes that may be signed as part of the list must be determined at the time of mapping creation.</p>"},{"location":"concepts/0250-rich-schemas/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0257-private-credential-issuance/","title":"Aries RFC 0257: Private Credential Issuance","text":"<ul> <li>Authors: Daniel Hardman and Lovesh Harchandani</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No recent progress and no implementations have been created.</li> <li>Start Date: 2019-08-26</li> <li>Tags: concept, protocol</li> </ul>"},{"location":"concepts/0257-private-credential-issuance/#summary","title":"Summary","text":"<p>This document describes an approach to let private individuals issue credentials without needing to have a public DID or credential definition on the ledger but more importantly without disclosing their identity to the credential receiver or the verifier. The idea is for the private individual to anchor its identity in a public entity (DID) like an organization. The public entity issues a credential to the private individual which acts as a permission for the private individual to issue credentials on behalf of the public entity. To say it another way, the public entity is delegating the issuance capability to the private individual. The receiver of the delegated credential (from the private individual) does not learn the identity of the private individual but only learn that the public entity has allowed this private individual to issue credentials on its behalf. When such a credential is used for a proof, the verifier's knowledge of the issuer is same as the credential receiver, it only knows identity of the public entity. The contrasts the current anonymous credential scheme used by Aries where the credential receiver and proof verifier know the identity of the credential issuer. Additionally, using the same cryptographic techniques, the private individual can delegate issuance rights further, if allowed by the public entity. </p>"},{"location":"concepts/0257-private-credential-issuance/#motivation","title":"Motivation","text":"<p>As they\u2019ve been implemented so far, verifiable credentials in general, and Indy-style credentials in particular, are not well suited to helping private individuals issue. Here are some use cases we don\u2019t address:</p>"},{"location":"concepts/0257-private-credential-issuance/#recommendations","title":"Recommendations","text":"<p>Alice wants to give Bob a credential saying that he did good work for her as a plumber.</p>"},{"location":"concepts/0257-private-credential-issuance/#testimony","title":"Testimony","text":"<p>Alice isn\u2019t necessarily recommending Bob, but she\u2019s willing to say that he was physically present at her house at 9 am on July 31.</p>"},{"location":"concepts/0257-private-credential-issuance/#payment-receipts","title":"Payment receipts","text":"<p>Bob, a private person selling a car, wants to issue a receipt to Alice, confirming that she paid him the price he was asking.</p>"},{"location":"concepts/0257-private-credential-issuance/#agreements","title":"Agreements","text":"<p>Alice wants to issue a receipt to Carol, acknowledging that she is taking custody of a valuable painting and accepting responsibility for its safety. Essentially, this is Alice formalizing her half of a contract between peers. Carol wants to issue a receipt to Alice, formalizing her agreement to the contract as well. Note that consent receipts, whether they be for data sharing or medical procedures, fall into this category, but the category is broader than consent.</p>"},{"location":"concepts/0257-private-credential-issuance/#delegation","title":"Delegation","text":"<p>Alice wants to let Darla, a babysitter, have the right to seek medical care for her children in Alice\u2019s absence.</p> <p>The reasons why these use cases aren\u2019t well handled are:</p>"},{"location":"concepts/0257-private-credential-issuance/#issuers-are-publicly-disclosed","title":"Issuers are publicly disclosed.","text":"<p>Alice would have to create a wholly public persona and DID for her issuer role--and all issuance she did with that DID would be correlatable. This endangers privacy. (Non-Indy credentials have exactly this same problem; there is nothing about ZKPs that makes this problem arise. But proponents of other credential ecosystems don't consider this risk a concern, so they may not think their credentialing solution has a problem.)</p>"},{"location":"concepts/0257-private-credential-issuance/#issuance-requires-tooling-setup-and-ongoing-maintenance","title":"Issuance requires tooling, setup, and ongoing maintenance.","text":"<p>An issuer needs to register a credential definition and a revocation registry on the ledger, and needs to maintain revocation status. This is an expensive hassle for private individuals. (Setup for credential issuance in non-ZKP ecosystems is also a problem, particularly for revocation. However, it may be more demanding for Indy due to the need for a credential definition and due to the more sophisticated revocation model.)</p>"},{"location":"concepts/0257-private-credential-issuance/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0257-private-credential-issuance/#delegatable-credentials-as-a-tool","title":"Delegatable credentials as a tool","text":"<p>Delegatable Credentials are a useful tool that we can use to solve this problem. They function like special Object Capabilities (OCAP) tokens, and may offer the beginnings of a solution. They definitely address the delegation use cases, at least. Their properties include:</p> <ul> <li> <p>A root issuer that is willing to go through setup and maintenance hassle creates a normal Indy credential and issues it to a normal Indy holder.</p> </li> <li> <p>This root holder can generate a new credential, based on the first one, that extends all or part of the trust from the root credential into a new delegate credential held by a delegate holder. The process of delegating subsets of trust through new delegate credentials can be repeated as often as needed.</p> </li> <li> <p>Each delegate credential embeds a pre-generated proof that the delegate holder derives their authority from the root holder through an unbroken chain of delegation. This proof can use ZKP techniques that are non-correlating and non-identifying of everyone in the chain other than the root issuer. For example, it might prove that the proximate holder was an over-21 resident of a particular city, as supported by evidence from their driver\u2019s license--and that the proximate holder received delegated authority from a root holder that was was the proximate holder\u2019s employer. Embedding proofs of delegation in this way eliminates the need to interact with anyone in the delegation chain. The only thing that these embedded, pre-generated proofs cannot contain is proof of non-revocation. That must be tested by interacting with the blockchain.</p> </li> <li> <p>Only the root issuer has to go through a setup process.</p> </li> <li> <p>Only the root issuer, not any holders in a delegation chain, must be publicly disclosed.</p> </li> <li> <p>All holders can revoke anything that they delegated, by using a revocation mechanism (possibly but not necessarily on a ledger) provided by the root issuer. This registry is unusual compared to that of ordinary credentials, in that others besides the creator of the registry (delegate holders) can write to it directly.</p> </li> </ul>"},{"location":"concepts/0257-private-credential-issuance/#applying-delegatable-credentials-to-other-use-cases","title":"Applying Delegatable Credentials to Other Use Cases","text":"<p>Here is how we might apply delegatable credentials to the private-individuals-can-issue problem.</p> <p>A new kind of issuer is needed, called a private credential facilitator (PCF). The job of a PCF is to eliminate some of the setup and maintenance hassle for private individual issuers by acting as a root issuer in a delegatable credential chain.</p> <p>On demand, a PCF is willing to issue a personal trust root (PTR) credential to any individual who asks. A PTR is a delegatable credential that points to a delegation trust framework where particular delegation patterns and credential schemas are defined. The PTR grants all privileges in that trust framework to its holder. It may also contain fields that describe the holder in certain ways (e.g., the holder is named Alice, the holder has a particular birth date or passport number or credit card number, the holder has a blinded link secret with a certain value, etc), based on things that the individual holder has proved to the PCF. The PCF is not making any strong claim about holder attributes when it issues these PTR credentials; it's just adding a few attributes that can be easily re-proved by Alice in the future, and that can be used to reliably link the holder to more traditional credentials with higher bars for trust. In some ways the PCF acts like a notary by endorsing or passing along credential attributes that originated elsewhere.</p> <p>For example, Alice might approach a PCF and ask for a PTR that she can use as a homeowner who wishes to delegate certain privileges in her smart home to AirBnB guests. The PCF would (probably for a fee) ask Alice to prove her name, address, and home ownership with either verifiable or non-digital credentials, agree with Alice on a trust framework that's useful for AirBnB scenarios, and create a PTR for Alice that gives Alice all privileges for her home under that trust framework.</p> <p>With this PTR in hand, Alice can now begin to delegate or subdivide permissions in whatever way she chooses, without a public DID and without going through any issuer setup herself. She issues (delegates) credentials to each guest, allowing them to adjust the thermostat and unlock the front doors, but not to schedule maintenance on the furnace. Each delegated credential she issues traces its trust back to the PTR and from there, to the PCF.</p> <p>Alice can revoke any credential she has delegated in this way, without coordinating either upstream or downstream. The PCF she contracted with gave her access to do this by either configuring their own revocation registry on the ledger so it was writable by Alice's DID as well as their own, or by providing a database or other source of truth where revocation info could be stored and edited by any of its customers.</p> <p>This use of delegatable credentials is obvious, and helpful. But what's cooler and less obvious is that Alice can also use the PTR and delegatable credential mechanism to address non-delegation use cases. For example, she can issue a degenerate delegated credential to Bob the plumber, granting him zero privileges but attesting to Alice's 5-star rating for the job he did. Bob can use this credential to build his reputation, and can prove that each recommendation is unique because each such recommendation credential is bound to a different link secret, which in turn traces back to a unique human due to the PCF's vetting of Alice when Alice enrolled in the service. If Alice agrees to include information about herself in the recommendation credential, Bob can even display credential-based recommendations (and proofs derived therefrom) on his website, showing that recommendation A came from a woman named Alice who lived in postal code X, whereas recommendation B came from a man named Bob who lived in postal code Y.</p> <p>Lets consider another case where an employee issues a delegated credential on the basis of a credential issued to by the employer. Lets say the PCF is an employer. The PCF issues a PTR credential to each of its employee using which the employee can issue recommendation credentials to different 3<sup>rd</sup> party service providers associated with the employer. The recommender (employee) while issuing a recommendation credential proves that he has a valid non-revoked PTR credential from the PCF. The credential contains the id of the employee, the rating, other data and is signed by the employee's private key. The 3<sup>rd</sup> party service provider can discover the employee's public key from the employer's hosted database. Now the service provider can use this credential to create proofs which do not reveal the identity of the employee but only the employer. If the verifier wanted more protection, he could demand that the service provider verifiably encrypt the employee ID from the PTR credential for the employer such that if the employer wishes (in case of any dispute), deanonymize the employee by decrypting the encrypted employee ID.</p> <p>Alice can issue testimony credentials in the same way she issues recommendation credentials. And she can issue payment receipts the same way.</p>"},{"location":"concepts/0257-private-credential-issuance/#more-about-reputation-management","title":"More about Reputation Management","text":"<p>Reputation requires a tradeoff with privacy; we haven't figured out anonymous reputation yet. If Alice's recommendation of Bob as a plumber (or her testimony that Bob was at her house yesterday) is going to carry any weight, people who see it need to know that the credential used as evidence truly came from a woman named Alice--not from Bob himself. And they need to know that Alice couldn't distort reputation by submitting dozens of recommendations or eyewitness accounts herself.</p> <p>Therefore, issuance of by private individuals should start by carefully answering this question:</p> <p>What characteristic(s) of the issuer will make this credential useful?</p> <p>The characteristics might include:</p> <ul> <li>A combination of the issuer\u2019s attributes that allows verifiers to tell two different issuers apart. Let\u2019s call these data items distinguishing factors.</li> <li>Any attributes of the issuer that may give her credential gravitas / relevance to future verifiers: location, proof of issuer reputation, possibly demographics. Let\u2019s call these data items weighting factors.</li> </ul> <p>Weighting factors are probably irrelevant to payment receipts and agreements; proofs in these use cases are about binary matching, not degree.</p> <p>All of our use cases for individual issuance care about distinguishing factors. Sometimes the distinguishing factors might be fuzzy (enough to tell that Alice-1 recommending Bob as a plumber is different from Alice-2, but not enough to strongly identify); other times they have to be exact. They do need distinguishing factors, though. Where these factors could maybe be fuzzy in recommendations or  do matter, though. In many cases, the distinguishing factors need to be strongly identifying, whereas for recommendations or testimony, fuzzier distinguishing factors might  probably don\u2019t care about weighting factors.</p> <p>Distinguishing factors and weighting factors should be embedded in each delegated credential, to the degree that they will be needed in downstream use to facilitate reputation. In some cases, we may want to use verifiable encryption to embed some of them. This would allow Alice to give an eyewitness testimony credential to Bob, to still remain anonymous from Bob, but to prove to Bob at the time of private issuance that Alice's strong personal identifiers are present, and could be revealed by Alice's PCF (or a designated 3<sup>rd</sup> party) if Bob comes up with a compelling reason.</p>"},{"location":"concepts/0257-private-credential-issuance/#reference","title":"Reference","text":""},{"location":"concepts/0257-private-credential-issuance/#todo","title":"TODO","text":""},{"location":"concepts/0257-private-credential-issuance/#drawbacks","title":"Drawbacks","text":""},{"location":"concepts/0257-private-credential-issuance/#todo_1","title":"TODO","text":""},{"location":"concepts/0257-private-credential-issuance/#rationale-and-alternatives","title":"Rationale and alternatives","text":""},{"location":"concepts/0257-private-credential-issuance/#todo_2","title":"TODO","text":""},{"location":"concepts/0257-private-credential-issuance/#prior-art","title":"Prior art","text":""},{"location":"concepts/0257-private-credential-issuance/#todo_3","title":"TODO","text":""},{"location":"concepts/0257-private-credential-issuance/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"concepts/0257-private-credential-issuance/#todo_4","title":"TODO","text":""},{"location":"concepts/0257-private-credential-issuance/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/","title":"Aries RFC 0268: Unified DIDCOMM Deeplinking","text":"<ul> <li>Authors: Dev Bharel, Alexi Falquier</li> <li>Status: PROPOSED</li> <li>Since: 2019-10-23</li> <li>Status Note: Proposed</li> <li>Start Date: 2018-10-04</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#summary","title":"Summary","text":"<p>A set of specifications for mobile agents to standardize around to provide better interoperable support for DIDCOMM compliant messages. Standards around the way agents intepret these encoded messages allow increased user choice when picking agents. </p> <p>This RFC lists a series of standards which must be followed by an Aires compatible agent for it to be considered interoperable with other agents. </p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#motivation","title":"Motivation","text":"<p>As more and more mobile agents come to market, the user base for these wallets will become increasingly fragmented. As one of the core tennats of SSI is interoperability we want to ensure that messages passed to users from these wallets are in formats that any wallet can digest. We want to ensure that the onboarding experience for new users is as seemless and unified as possible. </p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#tutorial","title":"Tutorial","text":"<p>Alice wants to invite Bob to connect with her. Alice sends Bob a invitation link generated by her Mobile Agent (a wallet provided by ACME Corp). </p> <p>The invitation url takes the form of: \"www.acmecorp.com/invite?d_m=XXXXX\" where the text following the query parameter \"d_m\" is the base64url-encoded invitation. </p> <p>Bob recieves this link and opens it on his phone. Since he doesn't have an Aires wallet, he gets directed to the webpage, \"acmecorp.com/invite\" where there's a list of wallets for each platform that he can choose and pick from. On the page is also the ACME Corp offical wallet. </p> <p>Bob decides to download the ACME Corp wallet and clicks on the link again. Because the ACME Corp wallet registered 'www.acmecorp.com' as it's deeplink, Bob gets prompted to open it in the ACME Corp app. </p> <p>Alice sends a similar invite to Charlie. Charlie uses a wallet distributed by Open Corp. Open Corp does not have the \"acmecorp.com\" URI registered as their deeplink, because they do not own that domain. </p> <p>When Charlie lands on that page, along with the offer for wallets is a QR Code with the encoded invitation and a button that states \"Open in App\". This button launches the didcomm:// custom protocol, which is registered by ALL Aires compatible wallets (in the same way e-mail apps all register mailto: ).</p> <p>Pressing the button prompts Charlie's phone to open the app that can handle didcomm://, which happens to be the wallet app by Open Corp. </p> <p>In both instances, Alice does not need to worry about what wallet the counter party is using and can send didcomm messages with the assurance that the counter party will have a onboarding experience waiting for them even if they don't have a wallet already. </p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#reference","title":"Reference","text":""},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#uri-registration","title":"URI Registration","text":"<p>Each mobile agent should register their own URI to open in app. These URI's should point to a landing invitation page.</p> <p>An example of such a URI page/invitation: \"www.spaceman.id/invite?d_m=\" In this case, if the recepient of this URL has an app that's registered Spaceman.id as it's domain (likely a wallet published by spaceman.id) then it will open the invation in app. If the recepient does not have the app installed, they'll have a page open on their mobile browser with suggestions for DIDCOMM compliant wallets. </p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#invitation-page","title":"Invitation Page","text":"<p>The Invitation page users land on must have a list of DIDCOMM compliant agents for each platform (iOS, Android). A list of these can be found here:</p> <p>The Invitation page must also show the encoded message as a scannable QR code and have a button (\"Open in App\") to manually launch the didcomm:// protcol.  The QR code helps interactions between web and mobile agent wallets. </p> <p>The button to manually launch the didcomm:// protocol allows other Aires wallets on their phone to launch to handle the message, even if they haven't registered that specific URI. Alternatively you can use a library to automatically launch the didcomm:// prefix when the webpage is opened.</p> <p>The Invitation page should also run a URL shortner service. This would help passing messages between services easily without needing to pass massive strings around. This also prevents polluting closed source properitary services with links. </p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#deeplink-prefix","title":"Deeplink Prefix","text":"<p>There must exist a common prefix for mobile agents to register for DIDCOMM messages. This vastly improves interoperability between agents and messages, as they can be opened by any wallet. As the messages are all off the DIDCOMM family, we think the prefix that is best suited is didcomm:// </p> <p>All Mobile Agents should register didcomm:// as affilated with their app to both iOS and Android. This will enable users to be prompted to use their wallet when they  recieve a DIDCOMM message.</p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#message-requirements","title":"Message Requirements","text":"<p>Proposed is a change to the query parameter usually used for the passing of the message from 'c_i' which stands for connection invite to the more inclusive 'd_m' which stands for DIDCOMM message. </p> <p>Furthermore, messages must also be base64 encoded serialized jsons, stripped of any excess space and as small as possible. </p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#drawbacks","title":"Drawbacks","text":"<p>This puts extra work on wallet developers to ensure a good experience. </p> <p>On iOS only one app can be registered to handle <code>didcomm://</code> at a time; the first one to be installed will prevent others from using this custom scheme.</p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>This allows each wallet to define their own invite page (or use an existing page provided by the community) while providing a common protocol scheme (didcomm://) for all applications. </p> <p>If we don't do this, there's a chance that wallet applications become unable to communicate with each other effecively during the onboarding process, leading to fragmentation, much like in the IM world. </p>"},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#prior-art","title":"Prior Art","text":""},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#unresolved-questions","title":"Unresolved Questions","text":""},{"location":"concepts/0268-unified-didcomm-agent-deeplinking/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes.</p> Name / Link Implementation Notes"},{"location":"concepts/0270-interop-test-suite/","title":"0270: Interop Test Suite","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: PROPOSED</li> <li>Since: 2019-10-25</li> <li>Status Note: Codifies some thinking about scope and mental model that are already socialized. Provides some new thinking as well.</li> <li>Supersedes: Partially, and in some ways, Indy HIPE 0015 and Indy HIPE 0016. Also, represents answers to questions that the community first posed in this HackMD doc and first attempted to answer in the indy-agent repo.</li> <li>Start Date: 2018-10-25</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0270-interop-test-suite/#summary","title":"Summary","text":"<p>Describes the goals, scope, and interoperability contract of the Aries Interop Test Suite. Does NOT serve as a design doc for the test suite code, or as a developer guide explaining how the test suite can be run; see the test suite codebase for that.</p>"},{"location":"concepts/0270-interop-test-suite/#motivation","title":"Motivation","text":"<p>The Aries Interop Test Suite makes SSI interoperability publicly and objectively measurable. It is a major deliverable of the Aries project as a whole--not a minor detail that only test zealots care about. It's important that the entire SSI community understand what it offers, how it works, what its results mean, and how it should be used.</p>"},{"location":"concepts/0270-interop-test-suite/#tutorial","title":"Tutorial","text":"<p>Interoperability is a buzzword in the SSI/decentralized identity space. We all want it.</p> <p>Without careful effort, though, interoperability is subjective and slippery. If products A and B implement the same spec, or if they demo cooperation in a single workflow, does that mean they can be used together? How much? For how long? Across which release boundaries? With what feature caveats?</p> <p>We need a methodology that gives crisp answers to questions like these--and it needs to be more efficient than continuously exercising every feature of every product against ../../features of every other product.</p> <p>However, it's important to temper our ambitions. Standards, community specs, and reference implementations exist, and many of them come with tests or test suites of their own. Products can test themselves with these tools, and with custom tests written by their dev staffs, and make rough guesses about interoperability. The insight we're after is a bit different.</p>"},{"location":"concepts/0270-interop-test-suite/#goals","title":"Goals","text":"<p>What we need is a tool that achieves these goals:</p> <ol> <li> <p>Evaluate practical interoperability of agents.</p> <p>Other software that offers SSI ../../features should also be testable. Here, such components are conflated with agents for simplicity, but it's understood that the suite targets protocol participants no matter what their technical classification.</p> </li> </ol> <p>Focus on remote interactions that deliver business value: high-level protocols built atop DIDComm, such as credential issuance, proving, and introducing, where each participant uses different software. DID methods, ledgers, crypto libraries, credential implementations, and DIDComm infrastructure should have separate tests that are out of scope here. None of these generate deep insight into whether packaged software is interoperable enough to justify purchase decisions; that's the gap we need to plug.</p> <ol> <li> <p>Describe results in a formal, granular, reproducible way that supports comparison between agents A and B, and between A at two different points of time or in two different configurations.</p> <p>This implies a structured report, as well as support for versioning of the suite, the agents under test, and the results.</p> </li> <li> <p>Track the collective community state of the art, so measurements are comprehensive and up-to-date, and so new ideas automatically encounter pressure to be vetted for interoperability.</p> <p>The test suite isn't a compliance tool, and it should be unopinionated about what's important and what's not. However, it should embody a broad list of testable ../../features--certainly, ones that are standard, and often, ones that are still maturing.</p> </li> </ol>"},{"location":"concepts/0270-interop-test-suite/#dos-and-donts","title":"Dos and Don'ts","text":"<p>Based on the preceding context, the following rules guide our understanding of the test suite scope:</p> <ul> <li>DO organize testing around protocols, as this is the major way that interoperability questions manifest. \"Can agent X issue credentials in a way that agent Y accepts?\" is a question about whether X and Y support a common protocol.</li> <li>DO test many protocols.</li> <li>DO allow easy extension for new protocols, both as contributions inside the codebase and as external code added after the test suite is installed.</li> <li>DO evaluate unhappy paths (timeouts, brownouts, graceful handling of version incompatibilities, reporting, troubleshooting...), since practical interoperability is often a function of robustness in suboptimal circumstances. </li> <li>DO test all relevant versions of each protocol. (The test suite does not need to maintain an unreasonably comprehensive inventory of all protocols; old protocols could be retired if they become difficult to support. An agent wishing to certify against an old protocol could download an old version of the test suite to certify. However, we generally want the test suite to support both breadth--many protocols--and depth--multiple protocol versions if they are all in active use.)</li> <li>DO test roles in a protocol separately, and DO test only one agent at a time. The question isn't \"Does agent X support the issuance protocol?\" but rather \"Does agent X support role Y in the issuance protocol?\" All roles in a protocol other than the one role for the one tested agent should be played by the test suite. </li> <li>DO test required and optional decorators to the extent that they are relevant to interoperability.</li> <li>DO distinguish between required and optional ../../features of a protocol in results.</li> <li>DO provide value for agents that talk over transports besides HTTP: BlueTooth, SMTP, AMQP, and so forth -- but DON'T get bogged down in all the permutations of transport and routing.</li> <li>DO describe results in a formally defined data structure that can be prettified in various ways.</li> <li>DO allow the test suite to be an automated step in a CI/CD pipeline.</li> <li>DO evaluate message correctness, but touch more lightly on data correctness. See this discussion about the distinction between messages and data, and note how the Issue Credential and Present Proof protocols push credential and presentation format to a concern about the format of attached data, so the data can evolve at a different rate from the protocol.</li> </ul> <ul> <li>DON'T attempt to replace proper unit, functional, or integration tests for agents.</li> <li>DON'T attempt to replace pen-testing or security analyses.</li> <li>DON'T attempt to replace formal methods (proofs of correctness/eventual consistency/security guarantees)</li> <li>DON'T test governance, policy, regulatory compliance, or similar high-level concerns outside fundamental interoperability. </li> <li>DON'T require manual interaction.</li> <li>DON'T artificially link one protocol's results to another's.</li> <li>DON'T attempt to release the test suite in sync with other Aries artifacts. Rather, use an independent release cadence that many uncoordinated agent projects can leverage per their own convenience.</li> <li>DON'T impose unreasonable processes, tools, architecture constraints, or dependencies on builders of agents or test suite contributors. For example, if the test suite required the agent under test to be instrumented, and the instrumentation library weren't available on certain platforms, that would violate this rule. It should be possible for just about any agent to be put under test, long after its initial design, just by implementing the backchannel.</li> <li>DON'T require that the test suite be runnable by an independent third party; trust results as reported by an agent's own developers. The suite might be relevant in a certification process, but is not intended to embody a certification process in and of itself.</li> <li>DON'T worry about test suite performance much. We want tests to run in minutes, so we shouldn't do anything ridiculously time-consuming--but simplicity of the suite is more important than its efficiency.</li> </ul>"},{"location":"concepts/0270-interop-test-suite/#general-approach","title":"General Approach","text":"<p>We've chosen to pursue these goals by maintaining a modular interop test suite as a deliverable of the Aries project. The test suite is an agent in its own right, albeit an agent with deliberate misbehaviors, a security model unsuitable for production deployment, an independent release schedule, and a desire to use every possible version of every protocol.</p> <p>Currently the suite lives in the <code>aries-protocol-test-suite</code> repo, but the location and codebase could change without invalidating this RFC; the location is an implementation detail.</p>"},{"location":"concepts/0270-interop-test-suite/#contract-between-suite-and-agent-under-test","title":"Contract Between Suite and Agent Under Test","text":"<p>The contract between the test suite and the agents it tests is:</p>"},{"location":"concepts/0270-interop-test-suite/#suite-will","title":"Suite will...","text":"<ol> <li> <p>Be packaged for local installation.</p> <p>Packaging could take various convenient forms. Those testing an agent install the suite in an environment that they control, where their agent is already running, and then configure the suite to talk to their agent.</p> </li> <li> <p>Evaluate the agent under test by engaging in protocol interactions over a frontchannel, and control the interactions over a backchannel.</p> <p>Note: Initially, this doc stipulated that both channels should use DIDComm over HTTP. This has triggered some dissonance. If an agent doesn't want to talk HTTP, should it have to, just to be tested? If an agent wants to be controlled over a RESTful interface, shouldn't it be allowed to do that? Answers to the preceding two questions have been proposed (use a generic adapter to transform the protocol, but don't make the test suite talk on a different frontchannel; unless all agents expose the same RESTful interface, the only thing we can count on is that agents will have DIDComm support, and the only methdology we have for uniform specification is to describe a DIDComm-based protocol, so yes, backchannel should be DIDComm). These two incompatible opinions are both alive and well in the community, and we are not yet converging on a consensus. Therefore, the actual implementation of the frontchannel and backchannel remains a bit muddy right now. Perhaps matters will clarify as we think longer and/or as we gain experience with implementation.</p> <p>Over the frontchannel, the test suite and the agent under test look like ordinary agents in the ecosystem; any messages sent over this channel could occur in the wild, with no clue that either party is in testing mode.</p> <p>The backchannel is the place where testing mode manifests. It lets the agent's initial state be set and reset with precision, guarantees its choices at forks in a workflow, eliminates any need for manual interaction, and captures notifications from the agent about errors. Depending on the agent under test, this backchannel may be very simple, or more complex. For more details, see Backchannel below.</p> <p>Agents that interact over other transports on either channel can use transport adapters provided by the test suite, or write their own. HTTP is the least common denominator transport into which any other transports are reinterpreted. Adapting is the job of the agent developer, not the test suite--but the suite will try to make this as easy as possible.</p> <p></p> </li> <li> <p>Not probe for agent ../../features. Instead, it will just run whatever subset of its test inventory is declared relevant by the agent under test.</p> <p>This lets simple agents do simple integrations with the test suite, and avoid lots of needless error handling on both sides.</p> </li> <li> <p>Use a set of predefined identities and a set of starting conditions that all agents under test must be able to recognize on demand; these are referenced on the backchannel in control messages. See Predefined Inventory below.</p> </li> <li> <p>Run tests in arbitrary orders and combinations, but only run one test at a time.</p> <p>Some agents may support lots of concurrency, but the test suite should not assume that all agents do.</p> </li> <li> <p>Produce an interop profile for the agent under test, with respect to the tested ../../features, for every successful run of the test suite.</p> <p>A \"successful\" run is one where the test suite runs to completion and believes it has valid data; it has nothing to do with how many tests are passed by the agent under test. The test suite will not emit profiles for unsuccessful runs.</p> <p>Interop profiles emitted by the test suite are the artifacts that should be hyperlinked in the Implementation Notes section of protocol RFCs. They could also be published (possibly in a prettified form) in release notes, distributed as a product or documentation artifact, or returned as an attachment with the <code>disclose</code> message of the Discover Features protocol.</p> </li> <li> <p>Have a very modest footprint in RAM and on disk, so running it in Docker containers, VMs, and CI/CD pipelines is practical.</p> </li> <li> <p>Run on modern desktop and server operating systems, but not necessarily on embedded or mobile platforms. However, since it interacts with the agent under test over a remote messaging technology, it should be able to test agents running on any platform that's capable of interacting over HTTP or over a transport that can be adapted to HTTP.</p> </li> <li> <p>Enforce reasonable timeouts unless configured not to do so (see note about user interaction below).</p> </li> </ol>"},{"location":"concepts/0270-interop-test-suite/#agent-under-test-will","title":"Agent under test will...","text":"<ol> <li> <p>Provide a consistent name for itself, and a semver-compatible version, so test results can be compared across test suite runs.</p> </li> <li> <p>Use the test suite configuration mechanism to make a claim about the tests that it believes are relevant, based on the ../../features and roles it implements.</p> </li> <li> <p>Implement a distinction between test mode and non-test mode, such that:</p> <ul> <li> <p>Test mode causes the agent to expose and use a backchannel--but the backchannel does not introduce a risk of abuse in production mode.</p> </li> <li> <p>Test mode either causes the agent to need no interaction with a user (preferred), or is combined with test suite config that turns off timeouts (not ideal but may be useful for debugging and mobile agents). This is necessary so the test suite can be automated, or so unpredictable timing on user interaction doesn't cause spurious results.</p> </li> </ul> <p>The mechanism for implementing this mode distinction could be extremely primitive (conditional compilation, cmdline switches, config file, different binaries). It simply has to preserve ordinary control in the agent under test when it's in production, while ceding some control to the test suite as the suite runs.</p> </li> <li> <p>Faithfully create the start conditions implied by named states from the Predefined Inventory, when requested on the backchannel.</p> </li> <li> <p>Accurately report errors on the backchannel.</p> </li> </ol>"},{"location":"concepts/0270-interop-test-suite/#reference","title":"Reference","text":""},{"location":"concepts/0270-interop-test-suite/#releasing-and-versioning","title":"Releasing and Versioning","text":"<p>Defining a release and versioning scheme is important, because the test suite's version is embedded in every interop profile it generates, and people who read test suite output need to reason about whether the results from two different test suites are comparable. By picking the right conventions, we can also avoid a lot of complexity and maintenance overhead.</p> <p>The test suite releases implicitly with every merged commit, and is versioned in a semver-compatible way as follows:</p> <ul> <li> <p>The <code>major</code> version of the test suite version corresponds to the provisions of the contract defined in this RFC. Any breaking changes in this RFC will require an increment of the major number.</p> </li> <li> <p>The <code>minor</code> version of the test suite is a count of how many protocol+version combinations the community knows about. This number is derived from a list of known PIURIs that's autogenerated from metadata about protocols in the <code>aries-rfcs</code> repo. Publishing or versioning a protocol in the community thus automatically causes the test suite's minor version to increment.</p> </li> <li> <p>The <code>patch</code> version of the test suite is the 7-character short form of the git commit hash for the source code from which it is built.</p> </li> </ul> <p>The major version should change rarely, after significant community debate. The minor version should update on a weekly or monthly sort of timeframe as protocols accumulate and evolve in the community--without near-zero release effort by contributors to the test suite. The patch version is updated automatically with every commit. This is a very light process, but it still allows the test suite on Monday and the test suite on Friday to report versions like <code>1.39.5e22189</code> and <code>1.40.c5d8aaf</code>, to know which version of the test suite is later, to know that both versions implement the same contract, and to know that the later version is backwards-compatible with the earlier one.</p>"},{"location":"concepts/0270-interop-test-suite/#test-naming-and-grouping","title":"Test Naming and Grouping","text":"<p>Tests in the test suite are named in a comma-separated form that groups them by protocol, version, role, and behavior, in that order. For example, a test of the <code>holder</code> role in version <code>1.0</code> of the the <code>issue-credential</code> protocol, that checks to see if the holder sends a proper <code>ack</code> at the end, might be named:</p> <pre><code>issue-credential,1.0,holder,sends-final-ack\n</code></pre> <p>Because of punctuation, this format cannot be reflected in function names in code, and it also will probably not be reflected in file names in the test suite codebase. However, it provides useful grouping behavior when sorted, and it is convenient for parsing. It lets agents under test declare patterns of relevant tests with wildcards. An agent that supports the credential issuance but not holding, and that only supports the 1.1 version of the <code>issue-credential</code> protocol, can tell the test suite what's relevant with:</p> <pre><code>issue-credential,1.1,issuer,*\n</code></pre>"},{"location":"concepts/0270-interop-test-suite/#interop-profile","title":"Interop Profile","text":"<p>The results of a test suite run are represented in a JSON object that looks like this:</p> <pre><code>{\n    \"@type\": \"Aries Test Suite Interop Profile v1\"\n    \"suite_version\": \"1.39.5e22189\",\n    \"under_test_name\": \"Aries Static Agent Python\",\n    \"under_test_version\": \"0.9.3\",\n    \"test_time\": \"2019-11-23T18:59:06\", // when test suite launched\n    \"results\": [\n        {\"name\": \"issue-credential,1.0,holder,ignores-spurious-response\", \"pass\": false },\n        {\"name\": \"issue-credential,1.0,holder,sends-final-ack\", \"pass\": true },\n    ]\n}\n</code></pre>"},{"location":"concepts/0270-interop-test-suite/#backchannel","title":"Backchannel","text":"<p>While the concept of a backchannel has been accepted by the community, there is not alignment with the definition of the backchannel provided here. Rather than maintaining this section as related work in the community evolves the concept, we're adding this note to say \"this section will likely change.\" Once backchannel implementations stabilize with a core definition, we'll refine this section as appropriate.</p> <p>The backchannel between test suite and agent under test is managed as a standard DIDComm protocol. The identifier for the message family is X. The messages include:</p> <ul> <li><code>reset-state</code>: Sent from suite to agent. Throws away all current state and gives keys and relationships that must exist in the KMS, by referencing named items from the Predefined Inventory.</li> <li><code>start</code>: Sent from suite to agent. Triggers the agent under test to make the first move in a protocol. Identifies the role the agent should take, and possibly the message type the agent should emit to start, if more than one start message is possible. Also identifies the roles and endpoints for any other participants.</li> <li><code>control-next</code>: Sent from suite to agent. Tells the agent under test what to do the next time it is their turn to make a decision in the protocol. For example, if the protocol under test is tic-tac-toe, this might tell the agent under test what move to make. Does this in a generic way by attaching an approximation of the plaintext message the test suite wants the agent under test to emit. The agent can examine this JSON and act accordingly.</li> <li><code>problem-report</code>: Sent from agent to suite to report errors in the testing procedure itself. Any such message invalidates and abandons the current test.</li> <li><code>report-state-change</code>: Sent from agent to suite to report that it is now in a new state in the protocol.</li> </ul>"},{"location":"concepts/0270-interop-test-suite/#predefined-inventory","title":"Predefined Inventory","text":"<p>TODO: link to the predefined identity for the test suite created by Daniel B, plus the RFC about other predefined DIDs. Any and all of these should be names as possible existing states in the KMS. Other initial states:</p> <ul> <li>totally empty KMS</li> <li>corrupt KMS</li> <li>100 random DIDs from various DID methods, with ratios per method configurable</li> </ul>"},{"location":"concepts/0270-interop-test-suite/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"concepts/0270-interop-test-suite/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0289-toip-stack/","title":"0289: The Trust Over IP Stack","text":"<ul> <li>Authors: Matthew Davie, Dan Gisolfi, Daniel Hardman, John Jordan, Darrell O'Donnell, Drummond Reed, Oskar van Deventer</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No recent progress and no implementations have been created.</li> <li>Start Date: 2019-01-01</li> <li>Tags: concept, stack, trust layer, governance framework</li> </ul>"},{"location":"concepts/0289-toip-stack/#summary","title":"Summary","text":"<p>This Aries concept RFC introduces a complete architecture for Internet-scale digital trust that integrates cryptographic trust at the machine layer with human trust at the business, legal, and social layers.</p>"},{"location":"concepts/0289-toip-stack/#motivations","title":"Motivations","text":"<p>The importance of interoperability for the widespread adoption of an information network architecture has been proven by the dramatic rise to dominance of the Internet [1]. A key driver of the Internet's rise to dominance was the open source implementation of the TCP/IP stack in Version 4.2 of Berkeley Software Distrbution (BSD) of UNIX [2]. This widely-adopted open source implementation of the TCP/IP stack offered the capability for any two peer devices to form a connection and exchange data packets regardless of their local network. In addition, secure protocol suites such as the Secure Sockets Layer (SSL), and its modern version, Transport Layer Security (TLS), have been protecting Internet transactions since 1995.</p> <p>Without a doubt, implementations of the TCP/IP stack, followed by SSL/TLS, have driven a tremendous amount of innovation over the last 30 years. However, although protocols such as TLS offer world-class security, the architecture over which they have been built leaves a significant and widely-recognized gap: a means for any peer to establish trust over these digital connections. For example, while TLS does allow a user to trust she is accessing the right website, it does not offer, at least in an usable way, a way for the user to log in, or prove her identity, to the website. This gap has often been referred to as \"the Internet's missing identity layer\" [3].</p> <p>The purpose of this Aries Concept RFC is to fill this gap by defining a standard information network architecture that developers can implement to establish trusted relationships over digital communicatons networks.</p>"},{"location":"concepts/0289-toip-stack/#architectural-layering-of-the-trust-over-ip-stack","title":"Architectural Layering of the Trust over IP Stack","text":"<p>Since the ultimate purpose of an \"identity layer\" is not actually to identify entities, but to facilitate the trust they need to interact, co-author John Jordan coined the term Trust over IP (ToIP) for this stack. Figure 1 is a diagram of its four layers:</p> <p></p> <p>Figure 1: The ToIP stack</p> <p>Note that it is actually a \"dual stack\": two parallel stacks encompassing both technology and governance. This reflects the fact that digital trust cannot be achieved by technology alone, but only by humans and technology working together.</p> <p>Important: The ToIP stack does not define specific governance frameworks. Rather it is a metamodel for how to design and implement digital governance frameworks that can be universally referenced, understood, and consumed in order to facilitate transitive trust online. This approach to defining governance makes it easier for  humans\u2014and the software agents that represent us at Layer Two\u2014to make trust decisions both within and across trust boundaries.</p> <p>The ToIP Governance Stack plays a special role in ToIP architecture. See the descriptions of the specialized governance frameworks at each layer and also the special section on Scaling Digital Trust.</p>"},{"location":"concepts/0289-toip-stack/#layer-one-public-utilities-for-decentralized-identifiers-dids","title":"Layer One: Public Utilities for Decentralized Identifiers (DIDs)","text":"<p>The ToIP stack is fundamentally made possible by new advancements in cryptography and distributed systems, including blockchains and distributed ledgers. Their high availability and cryptographic verifiability enable strong roots of trust that are decentralized so they will not serve as single points of failure.</p>"},{"location":"concepts/0289-toip-stack/#dids","title":"DIDs","text":"<p>Adapting these decentralized systems to be the base layer of the ToIP stack required a new type of globally unique identifier called a Decentralized Identifier (DID). Starting with a research grant from the U.S. Department of Homeland Security Science &amp; Technology division, the DID specification [4] and the DID Primer [5] were contributed to the W3C Credentials Community Group in June 2017. In September 2019 the W3C launched the DID Working Group to complete the job of turning DIDs into a full W3C standard [6].</p> <p>DIDs are defined by an RFC 3986-compliant URI scheme designed to provide four core properties:</p> <ol> <li>Permanence. A DID effectively functions as a Uniform Resource Name (URN) [7], i.e., once assigned to an entity (called the DID subject), a DID is a persistent identifier for that entity that should never be reassigned to another entity.</li> <li>Resolvability. A DID resolves to a DID document\u2014a data structure (encoded in JSON or other syntaxes) describing the public key(s) and service endpoint(s) necessary to engage in trusted interactions with the DID subject.</li> <li>Cryptographic verifiability. The cryptographic material in a DID document that enables a DID subject to prove cryptographic control of a DID.</li> <li>Decentralization. Because a DID is cryptographically generated and verified, it does not require a centralized registration authority such as those needed for phone numbers, IP addresses, or domain names today.</li> </ol> <p>Figure 2 shows the resemblance between DID syntax and URN syntax (RFC 8141).</p> <p></p> <p>Figure 2: How DID syntax resembles URN syntax</p>"},{"location":"concepts/0289-toip-stack/#did-methods","title":"DID Methods","text":"<p>Like the URN specification, the DID specification also defines a generic URI scheme which is in turn used for defining other specific URI schemes. With DIDs, these are called DID methods. Each DID method is defined by its own DID method specification that must include:</p> <ol> <li>The target system (technically called a verifiable data registry) against which the DID method operates. In the ToIP stack this is called a utility. Note that a utility is not required to be implemented as a blockchain or distributed ledger. DID methods can be designed to work with any type of distributed database, file system, or other system that can anchor a cryptographic root of trust.</li> <li>The DID method name.</li> <li>The syntax of the DID method-specific string.</li> <li>The CRUD (Create, Read, Update, Delete) operations for DIDs and DID documents that conform to the specification.</li> </ol> <p>DIDs have already proved to be a popular solution to decentralized PKI (public key infrastructure) [8]. Over 40 DID methods have already been registered in the informal DID Method Registry [9] hosted by the W3C Credentials Community Group (which the W3C DID Working Group is planning to incorporate into a formal registry as one of its deliverables). The CCG DID Method Registry currently include methods for:</p> <ul> <li>Permissionless blockchains such as Bitcoin (three methods), Ethereum (six methods), Veres One, IOTA, RChain, Ontology, etc.</li> <li>Permissioned ledgers such as the Sovrin ledger.</li> <li>Distributed file systems such as IPFS.</li> <li>Ledgerless P2P networks such as git, JLINC, and peer DIDs.</li> </ul>"},{"location":"concepts/0289-toip-stack/#utility-governance-frameworks","title":"Utility Governance Frameworks","text":"<p>A Layer One public utility may choose any governance model suited to the the constraints of its business model, legal model, and technical architecture. This is true whether the public utility is operated as a blockchain, distributed ledger, or decentralized file store, or whether it is permissioned, permissionless, or any hybrid. (Note that even permissionless blockchain networks still have rules\u2014formal or informal\u2014governing who can update the code.)</p> <p>All ToIP architecture requires is that the governance model conform to the requirements of the ToIP Governance Stack to support both interoperability and transitive trust. This includes transparent identification of the governance authority, the governance framework, and participant nodes or operators; transparent discovery of nodes and/or service endpoints; and transparent security, privacy, data protection, and other operational policies. See the Governance section below.</p> <p>Utility governance frameworks that conform to the ToIP Governance Stack model will support standard roles for all types of utility governance authorities. For example, the role currently supported by public-permissioned utilities such as those based on Hyperledger Indy include:</p> <ul> <li>Transaction Authors: initiate transactions</li> <li>Transaction Endorsers: permission transactions for Transaction Authors</li> <li>Stewards: operate a node of the ledger</li> </ul>"},{"location":"concepts/0289-toip-stack/#layer-one-support-for-higher-layers","title":"Layer One Support for Higher Layers","text":"<p>DIDs and DID documents are not the only cryptographic data structures needed to support the higher layers. Others include:</p> <ul> <li>Schemas define the claims (attributes) that can be included in verifiable credentials (Layer Three).</li> <li>Credential definitions specify the claims and related metadata needed by an issuer of verifiable credentials (Layer Three).</li> <li>Revocation Registries are cryptographic accumulators that enable credential issuers to revoke credentials while still protecting the privacy of the credential holder (Layer Three).</li> <li>Agent Authorization Policies are also cryptographic accumulators that enable credential holders to activate and deactivate agents operating on their behalf at Layer Two. (For more information, see section 5.1 of DKMS Design and Architecture.)</li> </ul> <p>In summary, the interoperability of Layer One is currently defined by the W3C DID specification and by Aries RFCs for the other cryptographic data structures listed above. Any DID registry that supports all of these data structures can work with any agent, wallet, and secure data store that operates at Layer Two.</p>"},{"location":"concepts/0289-toip-stack/#layer-two-the-didcomm-protocol","title":"Layer Two: The DIDComm Protocol","text":"<p>The second layer of the Trust over IP stack is defined by the DIDComm secure messaging standards [10]. This family of specifications, which are now being defined in the DIDComm Working Group at the Decentralized Identity Foundation, establish a cryptographic means by which any two software agents (peers) can securely communicate either directly edge-to-edge or via intermediate cloud agents as shown in Figure 3).</p> <p></p> <p>Figure 3: At Layer Two, agents communicate peer-to-peer using DIDComm standards</p>"},{"location":"concepts/0289-toip-stack/#peer-dids-and-did-to-did-connections","title":"Peer DIDs and DID-to-DID Connections","text":"<p>A fundamental feature of DIDComm is that by default all DID-to-DID connections are established and secured using pairwise pseudonymous peer DIDs as defined in the Peer DID Method Specification [11]. These DIDs are based on key pairs generated and stored by the local cryptographic key management system (KMS, aka \"wallet\") maintained by each agent. Agents then use the DID Exchange protocol to exchange peer DIDs and DID documents in order to establish and maintain secure private connections between each other\u2014including key rotation or revocation as needed during the lifetime of a trusted relationship.</p> <p>Because all of the components of peer DIDs and DID-to-DID connections are created, stored, and managed at Layer Two, there is no need for them to be registered in a Layer One public utility. In fact there are good privacy and security reasons not to\u2014these components can stay entirely private to the peers. As a general rule, the only ToIP actors who should need public DIDs at Layer One are:</p> <ol> <li>Credential issuers as explained in Layer Three below.</li> <li>Governance authorities at any layer as explained in the section on Scaling Digital Trust.</li> </ol> <p>This also means that, once formed, DID-to-DID connections can be used for any type of secure communications between the peers. Furthermore, these connections are capable of lasting literally forever. There are no intermediary service providers of any kind involved. The only reason a DID-to-DID connection needs to broken is if one or both of the peers no longer wants it.</p>"},{"location":"concepts/0289-toip-stack/#agents-and-wallets","title":"Agents and Wallets","text":"<p>At Layer Two, every agent is paired with a digital wallet\u2014or more accurately a KMS (key management system). This KMS can be anything from a very simple static file on an embedded device to a highly sophisticated enterprise-grade key server. Regardless of the complexity, the job of the KMS is to safeguard sensitive data: key pairs, zero-knowledge proof blinded secrets, verifiable credentials, and any other cryptographic material needed to establish and maintain technical trust.</p> <p>This job includes the difficult challenge of recovery after a device is lost or stolen or a KMS is hacked or corrupted. This is the province of decentralized key management. For more details, see the Decentralized Key Management System (DKMS) Design and Architecture document [12], and Dr. Sam Smith's paper on KERI (Key Event Receipt Infrastructure) [13].</p>"},{"location":"concepts/0289-toip-stack/#secure-data-stores","title":"Secure Data Stores","text":"<p>Agents may also be paired with a secure data store\u2014a database with three special properties:</p> <ol> <li>It is controlled exclusively by the DID controller (person, organization, or thing) and not by any intermediary or third party.</li> <li>All the data is encrypted with private keys in the subject\u2019s KMS.</li> <li>If a DID controller has more than one secure data store, the set of stores can be automatically synchronized according to the owner\u2019s preferences.</li> </ol> <p>Work on standardizing secure data stores has been proceeding in several projects in addition to Hyperledger Aries\u2014primarily at the Decentralized Identity Foundation (DIF) and the W3C Credentials Community Group. This has culminated in the formation of the Secure Data Store (SDS) Working Group at DIF.</p>"},{"location":"concepts/0289-toip-stack/#guardianship-and-guardian-agentswallets","title":"Guardianship and Guardian Agents/Wallets","text":"<p>The ToIP stack cannot become a universal layer for digital trust if it ignores the one-third of the world's population that do not have smartphones or Internet access\u2014or the physical, mental, or economic capacity to use ToIP-enabled infrastructure. This underscores the need for the ToIP layer to robustly support the concept of digital guardianship\u2014the combination of a hosted cloud agent/wallet service and an individual or organization willing to take legal responsibility for managing that cloud agent/wallet on behalf of the person under guardianship, called the dependent.</p> <p>For more about all aspects of digital guardianship, see the Sovrin Foundation white paper On Guardianship in Self-Sovereign Identity [14].</p>"},{"location":"concepts/0289-toip-stack/#provider-governance-frameworks","title":"Provider Governance Frameworks","text":"<p>At Layer Two, governance is needed primarily to establish  interoperability testing and certification requirements, including security, privacy, data protection, for the following roles:</p> <ul> <li>Hardware Developers who provider ToIP-compliant hardware, e.g., secure enclaves, trusted execution environments, HSMs.</li> <li>Software Developers who provider ToIP-compliant agents, wallets, secure data stores, etc.</li> <li>Agencies who host ToIP-compliant cloud agents for individuals, organizations, and guardians.</li> </ul>"},{"location":"concepts/0289-toip-stack/#layer-two-support-for-higher-layers","title":"Layer Two Support for Higher Layers","text":"<p>The purpose of Layer Two is to enable peers to form secure DID-to-DID connections so they can:</p> <ol> <li>Issue, exchange, and verify credentials over these connections using the data exchange protocols at Layer Three.</li> <li>Access the Layer One cryptographic data structures needed to issue and verify Layer Three credentials regardless of the public utility used by the issuer.</li> <li>Migrate and port ToIP data between agents, wallets, and  secure data stores without restriction. This data portability is critical to the broad adoption and interoperability of ToIP.</li> </ol>"},{"location":"concepts/0289-toip-stack/#layer-three-data-exchange-protocols","title":"Layer Three: Data Exchange Protocols","text":"<p>Layer One and Layer Two together enable the establishment of cryptographic trust (also called technical trust) between peers. By contrast, the purpose of Layers Three and Four is to establish human trust between peers\u2014trust between real-world individuals and organizations and the things with which they interact (devices, sensors, appliances, vehicles, buildings, etc.)</p> <p>Part of the power of the DIDComm protocol at Layer Two is that it lays the foundation for secure, private agent-to-agent connections that can now \"speak\" any number of data exchange protocols. From the standpoint of the ToIP stack, the most important of these are protocols that support the exchange of verifiable credentials.</p>"},{"location":"concepts/0289-toip-stack/#the-verifiable-credentials-data-model","title":"The Verifiable Credentials Data Model","text":"<p>After several years of incubation led by Manu Sporny, David Longley, and other members of the W3C Credentials Community Group, the W3C Verifiable Claims Working Group (VCWG) was formed in 2017 and produced the Verifiable Credentials Data Model 1.0 which became a W3C Recommendation in September 2019 [15].</p> <p>Figure 4 is a diagram of the three core roles in verifiable credential exchange\u2014often called the \"trust triangle\". For more information see the Verifiable Credentials Primer [16].</p> <p></p> <p>Figure 4: The three primary roles in the W3C Verifiable Credentials Data Model</p> <p>The core goal of the Verifiable Credentials standard is to enable us to finally have the digital equivalent of the physical credentials we store in our physical wallets to provide proof of our identity and attributes every day. This is why the presentation of a verifiable credential to a verified is call a proof\u2014it is both a cryptographic proof and a proof of some set of attributes or relationships a verifier needs to make a trust decision.</p>"},{"location":"concepts/0289-toip-stack/#credential-proof-types","title":"Credential Proof Types","text":"<p>The Verifiable Credentials Data Model 1.0 supports several different cryptographic proof types:</p> <ol> <li>JSON Web Tokens (JWTs) secured using JSON Web Signatures.</li> <li>Linked Data Signatures using JSON-LD.</li> <li>Zero Knowledge Proofs (ZKPs) using Camenisch-Lysyanskaya Signatures.</li> </ol> <p>All three proof types address specific needs in the market:</p> <ul> <li>JWTs are widely used in the JOSE stack and federated identity infrastructure.</li> <li>Linked Data Signatures are used in wide-area data integration and other Semantic Web applications.</li> <li>ZKP-based credentials enable credential holders to selectively disclose claims to verifiers without unintentional correlation\u2014a significant advancement in Privacy by Design architecture that simplifies compliance with the EU General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), and similar data protection regulations.</li> </ul> <p>To support all three of these credential proof types in the ToIP stack means:</p> <ul> <li>Layer One must support the data structures necessary to issue and verify each proof type.</li> <li>Layer Two agents, wallets, and secure data stores must support storage and export of the cryptographic materials needed for each proof type.</li> <li>Layer Three must support credential exchange protocols for each proof type.</li> </ul>"},{"location":"concepts/0289-toip-stack/#credential-exchange-protocols","title":"Credential Exchange Protocols","text":"<p>At Layer Three, the exchange of verifiable credentials is performed by agents using data exchange protocols layered over the DIDComm protocol. These data exchange protocol specifications are being published as part of the DIDComm suite [10]. Credential exchange protocols are unique to each credential proof type because the request and response formats are different. The goal of the ToIP technology stack is to standardize all supported credential exchange protocols so that any ToIP-compatible agent, wallet, and secure data store can work with any other agent, wallet, and secure data store.</p> <p>With fully interoperable verifiable credentials, any issuer may issue any set of claims to any holder who can then prove them to any verifier. Every verifier can decide which issuers and which claims it will trust. This is a fully decentralized system that uses the same trust triangle as the physical credentials we carry in our physical wallets today. This simple, universal trust model can be adapted to any set of requirements from any trust community. Even better, in most cases it does not require new  policies or business relationships. Instead the same policies that apply to existing physical credentials can just be applied to a new, more flexible and useful digital format.</p>"},{"location":"concepts/0289-toip-stack/#credential-governance-frameworks","title":"Credential Governance Frameworks","text":"<p>Since Layer Three is where the ToIP stack crosses over from technical trust to human trust, this is the layer where governance frameworks become a critical component for interoperability and scalability of digital trust ecosystems. Credential governance frameworks can be used to specify:</p> <ul> <li>Credential schema definitions.</li> <li>The rules governing who can serve as the authoritative issuers for those credentials.</li> <li>The policies those issuers must follow to issue and revoke those credentials.</li> <li>Applicable business models, liability frameworks, and insurance models.</li> </ul> <p>Standard roles that credential governance frameworks can define under the ToIP Governance Stack model include:</p> <ul> <li>Authoritative Issuers are issuers authorized by the governance authority to issue specific types of credentials at specific levels of assurance</li> <li>Credential Registries are alternative holders of credentials to support other uses, such as public searchable directory services.</li> <li>Insurers provide insurance to issuers operating under the terms of the governance framework.</li> </ul>"},{"location":"concepts/0289-toip-stack/#layer-three-support-for-higher-layers","title":"Layer Three Support for Higher Layers","text":"<p>Layer Three enables human trust\u2014in the form of verifiable assertions about entities, attributes and relationships\u2014to be layered over the cryptographic trust provided by Layers One and Two. Layer Four is the application ecosystems that request and consume these verifiable credentials in order to support the specific trust models and policies of their own digital trust ecosystem.</p>"},{"location":"concepts/0289-toip-stack/#layer-four-application-ecosystems","title":"Layer Four: Application Ecosystems","text":"<p>Layer Four is the layer where humans interact with applications in order to engage in trusted interactions that serve a specific business, legal, or social purpose. Just as applications call the TCP/IP stack to communicate over the Internet, applications call the ToIP stack to register DIDs, form connections, obtain and exchange verifiable credentials, and engage in trusted data exchange using the protocols in Layers One, Two, and Three.</p> <p>The ToIP stack no more  limits the applications that can be built on it than the TCP/IP stack  limits the applications that can be built on the Internet. The ToIP stack simply defines the \"tools and rules\"\u2014technology and governance\u2014for those applications to interoperate within digital trust ecosystems that provide the security, privacy, and data protection that their members expect. The ToIP stack also enables the consistent user experience of trust decisions across applications and ecosystems that is critical to achieving widespread trust online\u2014just as a consistent user experience of the controls for driving a car (steering wheel, gas pedal, brakes, turn signals) are critical to the safety of drivers throughout the world.</p>"},{"location":"concepts/0289-toip-stack/#ecosystem-governance-frameworks","title":"Ecosystem Governance Frameworks","text":"<p>Layer Four is where humans will directly experience the ToIP Governance Stack\u2014specifically the trust marks and policy promises of ecosystem governance frameworks. These specify the purpose, principes, and policies that apply to all  governance authorities and governance frameworks operating within that ecosystem\u2014at all four levels of the ToIP stack.</p> <p>The ToIP Governance Stack will define standard roles that can be included in an ecosystem governance framework (EGF) including:</p> <ul> <li>Member Directories the provide both human- and machine-searchable listings of the public DIDs and other searchable attributes of participants in the EGF.</li> <li>Auditors who can audit participants in a EGF for compliance with the EGF policies.</li> <li>Accreditors who can accredit auditors when a EGF needs to scale nationally or globally.</li> </ul> <p>To fully understand the scope and power of ecosystem governance frameworks, let us dive deeper into the special role of the ToIP Governance Stack.</p>"},{"location":"concepts/0289-toip-stack/#scaling-digital-trust","title":"Scaling Digital Trust","text":"<p>The top half of Figure 5 below shows the basic trust triangle architecture used by verifiable credentials. The bottom half shows a second trust triangle\u2014the governance trust triangle\u2014that can solve a number of problems related to the real-world adoption and scalability of verifiable credentials and the ToIP stack.</p> <p></p> <p>Figure 5: The special role of governance frameworks</p>"},{"location":"concepts/0289-toip-stack/#governance-authorities","title":"Governance Authorities","text":"<p>The governance trust triangle in Figure 5 represents the same governance model that exists for many of the most successful physical credentials we use every day: passports, driving licenses, credit cards, health insurance cards, etc.</p> <p>These credentials are \"backed\" by rules and policies that in many cases have taken decades to evolve. These rules and policies have been developed, published, and enforced by many different types of existing governance authorities\u2014private companies, industry consortia, financial networks, and of course governments.</p> <p>The same model can be applied to verifiable credentials simply by having these same governance authorities\u2014or new ones formed explicitly for ToIP governance\u2014publish digital governance frameworks. Any group of issuers who want to standardize, strengthen, and scale the credentials they offer can join together under the auspices of a sponsoring authority to craft a governance framework. No matter the form of the organization\u2014government, consortia, association, cooperative\u2014the purpose is the same: define the business, legal, and technical rules under which the members agree to operate in order to achieve trust.</p> <p>This of course is exactly how Mastercard and Visa\u2014two of the world\u2019s largest trust networks\u2014have scaled. Any bank or merchant can verify in seconds that another bank or merchant is a member of the network and thus bound by its rules.</p> <p>With the ToIP stack, this governance architecture can be applied to any set of roles and/or credentials, for any trust community, of any size, in any jurisdiction.</p> <p>As an historical note, some facets of the ToIP governance stack are inspired by the Sovrin Governance Framework (SGF) [17] developed starting in 2017 by the Sovrin Foundation, the governance authority for the Sovrin public ledger for self-sovereign identity (SSI).</p>"},{"location":"concepts/0289-toip-stack/#defining-a-governance-framework","title":"Defining a Governance Framework","text":"<p>In addition to the overall metamodel, the ToIP governance stack will provide an architectural model for individual governance frameworks at any level. This enables the components of the governance framework to be expressed in a standard, modular format so they can be easily indexed and referenced both internally and externally from other governance frameworks.</p> <p>Figure 6 shows this basic architectural model:</p> <p></p> <p>Figure 6: Anatomy of a governance framework</p>"},{"location":"concepts/0289-toip-stack/#discovery-and-verification-of-authoritative-issuers","title":"Discovery and Verification of Authoritative Issuers","text":"<p>Verifiers often need to verify that a credential was issued by an authoritative issuer. The ToIP stack will give governance authorities multiple mechanisms for designating their set of authoritative issuers (these options are non-exclusive\u2014they can each be used independently or in any combination):</p> <ol> <li>DID Documents. The governance authority can publish the list of their DIDs in a DID document on one or more public utilities of its choice.</li> <li>Member Directories. A governance authority can publish a \"whitelist\" of DIDs via a whitelisting service available at a standard service endpoint published in the governance authority\u2019s own DID document.</li> <li>Credential registries. If search and discovery of authoritative issuers is desired, a governance authority can publish verifiable credentials containing both the DID and additional attributes for each authoritative issuer in a credential registry.  Note that in this case the credential registry serves as a separate, cryptographically-verifiable holder of the credential\u2014a holder that is not the subject of the credential, but which can independently prove the validity of the credential.</li> <li>Verifiable credentials. As shown in Figure 5, the governance authority (or its designated auditors) can issue verifiable credentials to the authoritative issuers, which they in turn can provide directly to verifiers or indirectly via credential holders.</li> </ol>"},{"location":"concepts/0289-toip-stack/#discovery-and-verification-of-authoritative-verifiers","title":"Discovery and Verification of Authoritative Verifiers","text":"<p>Holders often need to verify that a credential was requested by an authoritative verifier, e.g. as part of a \u2018machine readable governance framework\u2019. The ToIP stack will give governance authorities multiple mechanisms for designating their set of authoritative verifiers (these options are non-exclusive\u2014they can be used independently or in any combination):</p> <ol> <li>DID Documents. The governance authority can publish the list of their DIDs in a DID document on one or more verifiable data registries of its choice.</li> <li>Member Directories. A governance authority can publish a \"whitelist\" of DIDs via a whitelisting service available at a standard service endpoint published in the governance authority\u2019s own DID document.</li> <li>Credential registries. If search and discovery of authoritative verifiers is desired, a governance authority can publish verifiable credentials containing both the DID and additional attributes for each authoritative verifiers in a credential registry.  Note that in this case the credential registry serves as a separate, cryptographically-verifiable holder of the credential\u2014a holder that is not the subject of the credential, but which can independently prove the validity of the credential.</li> <li>Verifiable credentials. Similar to Figure 5, the governance authority (or its designated auditors) can issue verifiable credentials to the authoritative issuers in the governance framework. Those issuers can in turn provide proofs directly to holders or verifiers.</li> </ol>"},{"location":"concepts/0289-toip-stack/#countermeasures-against-coercion","title":"Countermeasures against coercion","text":"<p>The concept of \"self-sovereign\" identity presumes that parties are free to enter a transaction, to share personal and confidential information, and to walk away when requests by the other party are deemed unreasonable or even unlawful. In practice, this is often not the case: \"What do you give an 800-pound gorilla?\", answer: \"Anything that it asks for\". Examples of such 800-pound gorillas are some big-tech websites, immigration offices and uniformed individuals alleging to represent law-enforcement [20][21]. Also the typical client-server nature of web transactions reinforces this power imbalance, where the human party behind its client agent feels coerced in surrendering personal data as otherwise they are denied access to a product, service or location. Point in case are the infamous cookie walls, where a visitor of a website get the choice between \"accept all cookies or go into the maze-without-exit\".</p> <p>Governance frameworks may be certified to implement one or more potential countermeasures against different types of coercion. In case of a machine readable governance framework, some of such countermeasures may be automatically enforced, safeguarding its user from being coerced into action against their own interest. Different governance frameworks may choose different balances between full self-sovereignty and tight control, depending of the interests that are at play as well as applicable legislation.</p> <p>The following are examples of potential countermeasures against coercion. The governance framework can stimulate or enforce that some verifiable credentials are only presented when the holder agent determines that some requirements are satisfied. When a requirement is not fulfilled, the user is warned about the violation and the holder agent may refuse presentation of the requested verifiable credential. 1. Require authoritative verifier. Verifiers would need to be authorized within the applicable governance framework, see also section \u201cDiscovery and Verification of Authoritative Verifiers\u201d. 2. Require evidence collection. Requests for presentation of verifiable credentials may hold up as evidence in court, if the electronic signature on the requests is linked to the verifier in a non-repudiable way. 3. Require enabling anonymous complaints. The above evidence collection may be compromised if the holder can be uniquely identified from the collected evidence. So a governance framework may require the blinding of holder information, as well as instance-identifiable information about the evidence itself. 4. Require remote/proxy verification. Verification has only value to a holder, if it results in a positive decision by the verifier. Hence a holder should preferably only surrender personal data if such warrants a positive decision. It would save travel, if the requested decision is access to a physical facility. It would in any case prevent unnecessary disclosure of personal data. Some verifiers may consider their decision criteria confidential. Hence, different governance frameworks may choose different balances between holder privacy and verifier confidentiality. 5. Require complying holder agent. Some rogue holder agents may surrender personal data against the policies of the governance framework associated with that data. Issuers of such data may require verification of compliance of the holder\u2019s agent before issuing. 6. Require what-you-know authentication. Holders may be forced to surrender biometric authentication by rogue verifiers as well as some state jurisdictions. This is the reason that many bank apps require \u201cwhat-you-know\u201d authentication, next to biometric \u201cwhat-you-are\u201d or device-based \u201cwhat-you-have\u201d authentication. This may be needed even for when then the user views its own personal data in the app without electronic presentation, as some 800-pound gorillas require watching over the shoulder.</p>"},{"location":"concepts/0289-toip-stack/#interoperability-with-other-governance-frameworks","title":"Interoperability with Other Governance Frameworks","text":"<p>The ToIP governance stack is designed to be compatible with\u2014and an implementation vehicle for\u2014national governance frameworks such as the Pan-Canadian Trust Framework (PCTF) [18] being developed through a public/private sector collaboration with the Digital Identity and Authentication Council of Canada (DIACC). It should also interoperate with regional and local governance frameworks of all kinds. For example, the Province of British Columbia (BC) has implemented a ToIP-compatible verifiable credential registry service called OrgBook BC. OrgBook is a holder service for legally registered entities in BC that was built using Indy Catalyst and Hyperledger Aries Cloud Agent - Python. Other provinces such as Ontario and Alberta as well as the Canadian federal government have begun to experiment with these services for business credentials, giving rise to new kind of network where trust is at the edge. For more information see the VON (Verifiable Organization Network) [19].</p>"},{"location":"concepts/0289-toip-stack/#building-a-world-of-interoperable-digital-trust-ecosystems","title":"Building a World of Interoperable Digital Trust Ecosystems","text":"<p>The Internet is a network of networks, where the interconnections between each network are facilitated through the TCP/IP stack. The ToIP-enable Internet is a digital trust ecosystem of digital trust ecosystems, where the interconnections between each digital trust ecosystem are facilitated through the ToIP stack. The boundaries of each digital trust ecosystem are determined by the governance framework(s) under which its members are operating.</p> <p>This allows the ToIP-enabled Internet to reflect the same diversity and richness the Internet has today, but with a new ability to form and maintain trust relationships of any kind\u2014personal, business, social, academic, political\u2014at any distance. These trust relationships can cross trust boundaries as easily as IP packets can cross network boundaries today.</p>"},{"location":"concepts/0289-toip-stack/#conclusion-a-trust-layer-for-the-internet","title":"Conclusion: A Trust Layer for the Internet","text":"<p>The purpose of the ToIP stack is to define a strong, decentralized, privacy-respecting trust layer for the Internet. It leverages blockchain technology and other new developments in cryptography, decentralized systems, cloud computing, mobile computing, and digital governance to solve longstanding problems in establishing and maintaining digital trust.</p> <p>This RFC will be updated to track the evolution of the ToIP stack as it is further developed, both through Hyperledger Aries and via other projects at the Linux Foundation. We welcome comments and contributions.</p>"},{"location":"concepts/0289-toip-stack/#references","title":"References","text":"<ol> <li>Petros Kavassalis, Richard Jay Solomon, Pierre-Jean Benghozi, The Internet: a Paradigmatic Rupture in Cumulative Telecom Evolution, Industrial and Corporate Change, 1996; accessed September 5 2019.</li> <li>FreeBSD, What, a real UNIX\u00ae?, accessed September 5, 2019.</li> <li>Kim Cameron, The Laws of Identity, May 2005; accessed November 2, 2019.</li> <li>Drummond Reed, Manu Sporny, Markus Sabadello, David Longley, Christopher Allen, Ryan Grant, Decentralized Identifiers (DIDs) v1.0, December 2019; accessed January 24, 2020.</li> <li>W3C Credentials Community Group, DID Primer, January 2019; accessed July 6, 2019.</li> <li>W3C DID Working Group, Home Page, September 2019; accessed November 2, 2019.</li> <li>Uniform Resource Names (URNs), RFC 8141, April 2017; accessed November 2, 2019.</li> <li>Greg Slepak, Christopher Allen, et al, Decentralized Public Key Infrastructure, December 2015, accessed January 24, 2020.</li> <li>W3C Credentials Community Group, DID Method Registry, June 2019; accessed July 6, 2019.</li> <li>Daniel Hardman, DID Communication, January 2019; accessed July 6, 2019.</li> <li>Daniel Hardman et al, Peer DID Method 1.0 Specification, July 2019; accessed July 6, 2019.</li> <li>Drummond Reed, Jason Law, Daniel Hardman, Mike Lodder, DKMS Design and Architecture V4, March 2019; accessed November 2, 2019.</li> <li>Samuel M. Smith, Key Event Receipt Infrastructure (KERI) , July 2019, accessed February 4, 2020.</li> <li>Sovrin Governance Framework Working Group, On Guardianship in Self-Sovereign Identity, December 2019, accessed April 10, 2020.</li> <li>Manu Sporny, Grant Noble, Dave Longley, Daniel C. Burnett, Brent Zundel, Verifiable Credentials Data Model 1.0, September 2019; accessed November 2, 2019.</li> <li>Manu Sporny, Verifiable Credentials Primer, February 2019; accessed July 6, 2019.</li> <li>Sovrin Foundation, Sovrin Governance Framework V2, March 2019; accessed December 21, 2019.</li> <li>DIACC, Pan-Canadian Trust Framework, May 2019; accessed July 6, 2019.</li> <li>Governments of British Columbia, Ontario, and Canada, Verifiable Organizations Network (VON),June 2019; accessed July 6, 2019.</li> <li>Oskar van Deventer et al, TNO, Netherlands, Self-Sovereign Identity - The Good, The Bad And The Ugly, May 2019.</li> <li>Oskar van Deventer (TNO), Alexander Blom (Bloqzone), Line Kofoed (Bloqzone) Verify the Verifier - anti-coersion by design, October 2020.</li> </ol>"},{"location":"concepts/0289-toip-stack/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0302-aries-interop-profile/","title":"0302: Aries Interop Profile","text":"<ul> <li>Authors: Stephen Curran, John Jordan Province of British Columbia</li> <li>Status: ADOPTED</li> <li>Since: 2021-01-06</li> <li>Status Note: This RFC defines an Aries Interop Profile process and Aries Interop Profile versions</li> <li>Supersedes:</li> <li>Start Date: 2019-11-06</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0302-aries-interop-profile/#summary","title":"Summary","text":"<p>This RFC defines the process for the community of Aries agent builders to:</p> <ul> <li>enumerate a versioned set of Aries concept and feature RFCs which are collectively referred to as 'Aries Interop Profile Vx.y'</li> <li>track Aries Interop Profile versions.</li> </ul> <p>\"Agent builders\" are organizations or teams that are developing open source code upon which agents can be built (e.g. aries-framework-dotnet), or deployable agents (e.g. Aries Mobile Agent Xamarin), or commercially available agents.</p> <p>An Aries Interop Profile (AIP) version provides a clearly defined set of versions of RFCs for Aries agent builders to target their agent implementation when they wish it to be interoperable with other agents supporting the same Aries Interop Profile version. The Aries Interop Profile versioning process is intended to provide clarity and predictability for Aries agent builders and others in the broader Aries community. The process is not concerned with proposing new, or evolving existing, RFCs, nor with the development of Aries code bases.</p> <p>At all times, the Reference section of this RFC defines one or more current Aries Interop Profile versions -- a number and set of links to specific commits of concept and ../../features RFCs, along with a list of all previous Aries Interop Profile versions. Several current Aries Interop Profile versions can coexist during periods when multiple major Aries Interop Profile versions are in active use (e.g. 1.x and 2.x). Each entry in the previous versions list includes a link to the commit of this RFC associated with that Aries Interop Profile version. The Reference section MAY include one <code>&lt;major&gt;.next</code> version for each existing current major Aries Interop Profile versions. Such \"next\" versions are proposals for what is to be included in the next minor AIP version.</p> <p>Once a suitably populated Aries test suite is available, each Aries Interop Profile version will include a link to the relevant subset of test cases. The test cases will include only those targeting the specific versions of the ../../concepts and ../../features RFCs in that version of Aries Interop Profile. A process for maintaining the link between the Aries Interop Profile version and the test cases will be defined in this RFC once the Aries test suite is further evolved.</p> <p>This RFC includes a section maintained by Aries agent builders listing their Aries agents or agent deployments (whether open or closed source). This list SHOULD include the following information for each listed agent:</p> <ul> <li>The name, version and link to the agent (code or deployment)</li> <li>The type of the agent (see below)</li> <li>The name and link to the builder(s)</li> <li>The version of Aries Interop Profile supported</li> <li>A link to the test suite results or a summary of caveats/details about the agent's AIP support</li> <li>Notes about the agent</li> </ul> <p>An Aries agent builder SHOULD include an entry in the table per major version supported. Until there is a sufficiently rich test suite that produces linkable results, builders SHOULD link to and maintain a page that summarizes any exceptions and extensions to the agent's AIP support.</p> <p>The type of the agent MUST be selected from an enumerated list above the table of builder agents.</p>"},{"location":"concepts/0302-aries-interop-profile/#motivation","title":"Motivation","text":"<p>The establishment of Aries Interop Profile versions defined by the Aries agent builder community allows the independent creation of interoperable Aries agents by different Aries agent builders. Whether building open or closed source implementations, an agent that aligns with the set of RFC versions listed as part of an Aries Interop Profile version should be interoperable with any other agent built to align with that same version.</p>"},{"location":"concepts/0302-aries-interop-profile/#tutorial","title":"Tutorial","text":"<p>This RFC MUST contain the current Aries Interop Profile versions as defined by a version number and a set of links to concept and feature RFCs which have been agreed to by a community of Aries agent builders. \"Agreement\" is defined as when the community agrees to merge a Pull Request (PR) to this RFC that affects an Aries Interop Profile version number and/or any of the links to concept and feature RFCs. PRs that do not impact the Aries Interop Profile version number or links can (in general) be merged with less community scrutiny.</p> <p>Each link to a concept or feature RFCs MUST be to a specific commit of that RFC. RFCs in the list MAY be flagged as deprecated. Linked RFCs that reference external specs or standards MUST refer to as specific a version of the external resource as possible.</p> <p>Aries Interop Profile versions SHOULD have a link (or links) to a version (specific commit) of a test suite (or test cases) which SHOULD be used to verify compliance with the corresponding version of Aries Interop Profile. Aries agent builders MAY self-report their test results as part of their entries in the list of agents.</p> <p>Aries Interop Profile versions MUST evolve at a pace determined by the Aries agent builder community. This pace SHOULD be at a regular time interval so as to facilitate the independent but interoperable release of Aries Agents. Aries agent builders are encouraged to propose either updates to the list of RFCs supported by Aries Interop Profile through GitHub Issues or via a Pull Request. Such updates MAY trigger a change in the Aries Interop Profile version number.</p> <p>All previous versions of Aries Interop Profile MUST be listed in the Previous Versions section of the RFP and must include a link to the latest commit of this RFC at the time that version was active.</p> <p>A script in the <code>/code</code> folder of this repo can be run to list RFCs within an AIP version that have changed since the AIP version was set. For script usage information run the following from the root of the repo:</p> <p><code>python code/aipUpdates.py --help</code></p>"},{"location":"concepts/0302-aries-interop-profile/#sub-targets","title":"Sub-targets","text":"<p>AIP 2.0 is organized into a set of base requirements, and additional optional targets. These requirements are listed below. When indicating levels of support for AIP 2.0, subtargets are indicated in this format: <code>AIP 2.0/INDYCREDS/MEDIATE</code> with the subtargets listed in any order.</p> <p>Any RFCs within a single AIP Version and it's subtargets MUST refer to the exact same version of the RFC.</p>"},{"location":"concepts/0302-aries-interop-profile/#discover-features-usage","title":"Discover Features Usage","text":"<p>AIP Targets can be disclosed in the discover_../../features protocol, using the <code>feature-type</code> of <code>aip</code>. The feature's <code>id</code> is <code>AIP&lt;major&gt;.&lt;minor&gt;</code> for base compatibility, and <code>AIP&lt;major&gt;.&lt;minor&gt;/&lt;subtarget&gt;</code> for subtargets, each subtarget being included individually.</p> <p>Example:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/2.0/disclosures\",\n  \"disclosures\": [\n    {\n      \"feature-type\": \"aip\",\n      \"id\": \"AIP2.0\",\n    },\n    {\n      \"feature-type\": \"aip\",\n      \"id\": \"AIP2.0/INDYCRED\"\n    }\n  ]\n}\n</code></pre>"},{"location":"concepts/0302-aries-interop-profile/#reference","title":"Reference","text":"<p>The Aries Interop Profile version number and links to other RFCs in this section SHOULD only be updated with the agreement of the Aries agent builder community. There MAY be multiple active major Aries Interop Profile versions. A list of previous versions of Aries Interop Profile are listed after the current version(s).</p>"},{"location":"concepts/0302-aries-interop-profile/#aries-interop-profile-version-10","title":"Aries Interop Profile Version: 1.0","text":"<p>The initial version of Aries Interop Profile, based on the existing implementations such as aries-cloudagent-python, aries-framework-dotnet, Open Source Mobile Agent and Streetcred.id's IOS agent. Agents adhering to AIP 1.0 should be able to establish connections, exchange credentials and complete a connection-less proof-request/proof transaction.</p> RFC Type RFC/Link to RFC Version Concept 0003-protocols Concept 0004-agents Concept 0005-didcomm Concept 0008-message-id-and-threading Concept 0011-decorators Concept 0017-attachments Concept 0020-message-types Concept 0046-mediators-and-relays Concept 0047-json-LD-compatibility Concept 0050-wallets Concept 0094-cross-domain messaging Feature 0015-acks Feature 0019-encryption-envelope Feature 0160-connection-protocol Feature 0025-didcomm-transports Feature 0035-report-problem Feature 0036-issue-credential Feature 0037-present-proof Feature 0056-service-decorator"},{"location":"concepts/0302-aries-interop-profile/#changelog-aip-10","title":"Changelog - AIP 1.0","text":"<p>The original commit used in the definition of AIP 1.0 was: 64e5e55</p> <p>The following clarifications have been made to RFCs that make up AIP 1.0:</p> <ul> <li>RFC 0160 Connection: <code>signers</code> was updated to <code>signer</code> in the Signature decorator example, following the RFC.</li> </ul>"},{"location":"concepts/0302-aries-interop-profile/#aip-v10-test-suite","title":"AIP v1.0 Test Suite","text":"<p>To Do: Link(s) to version(s) of the test suite/test cases applicable to this Aries Interop Profile version.</p>"},{"location":"concepts/0302-aries-interop-profile/#aries-interop-profile-version-20","title":"Aries Interop Profile Version: 2.0","text":"<p>The following are the goals used in selecting RFC versions for inclusion in AIP 2.0, and the RFCs added as a result of each goal:</p> <ul> <li> <p>From AIP 1.0: Aries Agents must be able to establish connections, exchange credentials and complete a connection-less proof-request/proof transaction.</p> </li> <li> <p>Aries agents must be able to reuse connections.</p> </li> <li> <p>RFCs 0434, 0023, 0519, 0360</p> </li> <li> <p>Enable access to actionable information in Mobile Agents to enable improvements in the user experience (vs. AIP 1.0-based mobile agents).</p> </li> <li> <p>RFCs 0183, 0095, 0557</p> </li> <li> <p>Improve support for credential revocation use cases, independent of the revocation mechanism being used.</p> </li> <li> <p>RFCs 0183</p> </li> <li> <p>Improve the low-level messaging cryptography and enable a transition to DIDComm 2.0 to improve the security of the communication paths between agents.</p> </li> <li> <p>RFCs 0044, 0360, 0334</p> </li> <li> <p>Use protocols and standards that support multiple ledger types and verifiable credential formats.</p> </li> <li> <p>RFCs 0434, 0023, 0453, 0454</p> </li> <li> <p>Where appropriate, enable standard mediator coordination capabilities for mobile agents and multi-tenant agencies.</p> </li> <li>RFC 0211</li> </ul>"},{"location":"concepts/0302-aries-interop-profile/#aip-20-changelog-by-pull-requests","title":"AIP 2.0 Changelog by Pull Requests","text":"<p>Since approval of the AIP 2.0 profile, the following RFCs have been clarified by updating the commit in the link to the RFC:</p> <ul> <li>2022-03: RFC 0004 Agents, RFC 0005 DIDComm, RFC 0046 Mediators and Relays, RFC 0211 Route Coordination</li> <li>Note: In this update, a number of RFCs were changed solely for the purpose     of changing a link in the RFC to reference the \"main\" branch.</li> <li> <p>Pull request: #724</p> </li> <li> <p>2022-06: RFC 0023 DID Exchange, RFC 0025 DIDComm Transports, RFC 0434 Out of Band</p> </li> <li> <p>Pull request: #739</p> </li> <li> <p>2024-02: Clarifications and removals of RFCs that have been determined to be impractical for AIP 2.0.</p> </li> <li>See the AIP 2.0 RFC Removed section for details about the removed RFCs</li> <li>See the updated implementer's note on encryption envelopes in AIP 2.0 that highlights the removal of RFC 0587-encryption-envelope-v2.</li> <li> <p>Pull request: #814</p> </li> <li> <p>2024-03: Clarifications and removals of RFCs that have been determined to be impractical for AIP 2.0.</p> </li> <li>See the AIP 2.0 RFC Removed section for details about the removed RFCs</li> <li>Pull request: #820</li> </ul>"},{"location":"concepts/0302-aries-interop-profile/#aip-20-changelog-by-clarifications","title":"AIP 2.0 Changelog by Clarifications","text":"<p>The original commit used in the definition of AIP 2.0 was: <code>b3a3942ef052039e73cd23d847f42947f8287da2</code></p> <p>The following clarifications have been made to RFCs that make up AIP 2.0. This list excludes commits changed solely because of status changes:</p> <ul> <li>RFC 0003 Protocols: A correction to the tic-tac-toe example protocol was made; clarifications and additional guidance about the handling of minor differences in protocols by implementations.</li> <li>RFC 0017 Attachments: A clarification was made around the use of base64url encoding/decoding.</li> <li>RFC 0441 Present Proof Best Practices: A convention for representing dates to enable simple \"older than\" predicates was added.</li> <li>RFC 0592 Indy Attachment Format: The encoding algorithm used for credential attributes was added from RFC 0036.</li> <li>RFC 0008 Message ID and Threading: Clarification on having an empty <code>~thread</code> on a first message.</li> <li>RFC 0519 Goal Codes: Added some commonly used Goal Codes.</li> <li>RFC 0015 Acks: Clarification that an \"Ack\" value should not be \"Fail\" and Acks relationship with RFC 0035 Problem Report.</li> <li>RFC 0023 DID Exchange: Status update to Adopted, added to example the use of a DID Rotate attachment to include a signature on the the DID.</li> <li>RFC 0035 Report Problem: Clarification that a <code>description.code</code> is required, clarification on conventions for warnings.</li> <li>RFC 0044 DIDComm File and MIME Types: Clarifications on fallbacks for the mime types and why, and on using JWEs.</li> <li>RFC 0211 Route Coordination: Clarification to add a missing comma to an example.</li> <li>RFC 0434 Out of Band: Clarification that did:peer:2 can be used for reuse.</li> <li>RFC 0453 Issue Credential: Clarification about the protocol version (2.0) and that payments are not part of AIP 2.0.</li> <li>RFC 0454 Present Proof: Clarification about the protocol version (2.0) and that payments are not part of AIP 2.0.</li> <li>RFC 0592 Indy Attachments: Clarification on handling \"unrevealed attributes\" and on encoding integer strings as numbers (e.g. encoding both <code>\"1\"</code> vs. <code>1</code> as integers)</li> <li>RFC 0510 DIF Presentation Exchange Attachment: Correction of reference into the DIF spec that there is an \"s\" on \"definitions\" in <code>dif/presentation-exchange/definitions@v1.0</code></li> </ul>"},{"location":"concepts/0302-aries-interop-profile/#base-requirements","title":"Base Requirements","text":"RFC Type RFC/Link to RFC Version Note Concept 0003-protocols AIP V1.0, Reformatted Concept 0004-agents AIP V1.0, Unchanged Concept 0005-didcomm AIP V1.0, Minimally Updated Concept 0008-message-id-and-threading AIP V1.0, Updated Concept 0011-decorators AIP V1.0, Updated Concept 0017-attachments AIP V1.0, Updated Concept 0020-message-types AIP V1.0, UpdatedMandates message prefix <code>https://didcomm.org</code> for Aries Protocol messages. Concept 0046-mediators-and-relays AIP V1.0, Minimally Updated Concept 0047-json-LD-compatibility AIP V1.0, Minimally Updated Concept 0050-wallets AIP V1.0, Unchanged Concept 0094-cross-domain messaging AIP V1.0, Updated Concept 0519-goal-codes Feature 0015-acks AIP V1.0, Updated Feature 0019-encryption-envelope AIP V1.0, UpdatedSee envelope note below Feature 0023-did-exchange Feature 0025-didcomm-transports AIP V1.0, Minimally Updated Feature 0035-report-problem AIP V1.0, Updated Feature 0044-didcomm-file-and-mime-types Feature 0048-trust-ping Feature 0183-revocation-notification Feature 0360-use-did-key Feature 0434-outofband Feature 0453-issue-credential-v2 Update to V2 Protocol Feature 0454-present-proof-v2 Update to V2 Protocol Feature 0557-discover-features-v2"},{"location":"concepts/0302-aries-interop-profile/#mediate-mediator-coordination","title":"MEDIATE: Mediator Coordination","text":"RFC Type RFC/Link to RFC Version Note Feature 0211-route-coordination Feature 0092-transport-return-route"},{"location":"concepts/0302-aries-interop-profile/#indycred-indy-based-credentials","title":"INDYCRED: Indy Based Credentials","text":"RFC Type RFC/Link to RFC Version Note Feature 0592-indy-attachments  Evolved from AIP V1.0 Concept 0441-present-proof-best-practices"},{"location":"concepts/0302-aries-interop-profile/#ldcred-json-ld-based-credentials","title":"LDCRED: JSON-LD Based Credentials","text":"RFC Type RFC/Link to RFC Version Note Feature 0593-json-ld-cred-attach Feature 0510-dif-pres-exch-attach"},{"location":"concepts/0302-aries-interop-profile/#bbscred-bbs-based-credentials","title":"BBSCRED: BBS+ Based Credentials","text":"RFC Type RFC/Link to RFC Version Note Feature 0593-json-ld-cred-attach Feature 0646-bbs-credentials Feature 0510-dif-pres-exch-attach"},{"location":"concepts/0302-aries-interop-profile/#chat-chat-related-features","title":"CHAT: Chat related ../../features","text":"RFC Type RFC/Link to RFC Version Note Feature 0095-basic-message"},{"location":"concepts/0302-aries-interop-profile/#aip-20-rfcs-removed","title":"AIP 2.0 RFCs Removed","text":"<p>[!WARNING] After discussion amongst the Aries implementers, the following RFCs initially in AIP 2.0 have been removed as both never implemented (as far as we know) and/or impractical to implement. Since the RFCs have never been implemented, their removal does not have a practical impact on implementations. Commentary below the table listing the removed RFCs provides the reasoning for the removal of each RFC.</p> RFC Type RFC/Link to RFC Version Note Feature 0317-please-ack Removed from AIP 2.0 Feature 0587-encryption-envelope-v2 Removed from AIP 2.0 Feature 0627-static-peer-dids The use of static peer DIDs in Aries has evolved and all AIP 2.0 implementations should be using DID Peer types 4 (preferred), 1 or 2. <ul> <li>0317-please-ack: While the idea of a generic ACK request to be sent either immediately <code>on receipt</code>, or <code>after processing</code> seemed like a good idea, attempts to implement the feature proved ill-advised.</li> <li>The feature was never implemented, and there have been (as far as we know) no requests for its implementation. A good idea in theory, but not needed in practice.</li> <li>The <code>on receipt</code> use of <code>please-ack</code> might be feasible as a generic feature, but does not appear to be useful except in protocol specific ways, such as in implementing a texting protocol to get \"read receipts\". However, even in that case, it is not useful for the existing 0095-basic-messaging protocol, because the protocol will be complete (and likely deleted) before the <code>ack</code> can be sent back to the sender. When an <code>on receipt</code> ACK is needed, it is much preferred to add it in a protocol specific way vs. in a generic way.</li> <li>The <code>after processing</code> use of <code>please-ack</code> turned out to be impossible because its introduction changes every protocol state machine in protocol specific ways. We have determined that it is not possible to \"generically\" (without changing each protocol) to add such a feature and so we have decided that if there is a use case of <code>please-ack</code>-style functionality in a given protocol, it should be added/included in that protocol. Further, no one has requested that the feature be used in any implementation.</li> <li>See the RFC 0317 Please Ack for more details on it's change of status to <code>RETIRED</code> and links to unmerged PRs that attempted to design and implement the functionality.</li> <li>0587-encryption-envelope-v2</li> <li>While this RFC will be crucial when the transition to DIDComm v2 is started, it is not of use until then, and hence not applicable to AIP 2.0.</li> <li>0627-static-peer-dids: The inclusion of static peer DIDs was a transitory approach as the DID Peer specification evolved. The use of static peer DIDs is not in use in Aries, the DID Peer specification has stabilized, and the existing implementations are settled on the use of <code>did:peer</code> <code>4</code> (preferred), <code>2</code> and in some cases <code>1</code>. The removal of static peer DIDs from AIP 2.0 is to indicate where the community is currently and to lead newcomers to the community to follow the existing practices in the use of DID Peer.</li> </ul>"},{"location":"concepts/0302-aries-interop-profile/#aip-v20-test-suite","title":"AIP v2.0 Test Suite","text":"<p>The Aries Agent Test Harness has a set of tests tagged to exercise AIP 1.0 and AIP 2.0, including the extended targets.</p>"},{"location":"concepts/0302-aries-interop-profile/#implementers-note-about-didcomm-envelopes-and-the-accept-element","title":"Implementers Note about DIDComm Envelopes and the <code>ACCEPT</code> element","text":"<p>[!WARNING] The following paragraph is struck out as no longer relevant, since the 0587-encryption-envelope-v2 RFC has been removed from AIP 2.0. The upcoming (to be defined) AIP 3.0 will include the transition from DIDComm v1 to the next DIDComm generation, and at that time, the 0587-encryption-envelope-v2 will again be relevant.</p> <p>AIP 2.0 contains two RFCs that reference envelopes 0019-encryption-envelope and 0587-encryption-envelope-v2 (links above). The important feature that Aries implementers should understand to differentiate which envelope format can or is being used by an agent is the <code>accept</code> element of the DIDComm service endpoint and the out-of-band <code>invitation</code> message. If the <code>accept</code> element is not present, the agent can only use the RFC 0019-encryption-envelope present. If it is present, the values indicate the envelope format(s) the agent does support. See the RFCs for additional details.</p>"},{"location":"concepts/0302-aries-interop-profile/#previous-versions","title":"Previous Versions","text":"<ul> <li>None</li> </ul> <p>Will be the version number as a link to the latest commit of this RFC while the version was current.</p>"},{"location":"concepts/0302-aries-interop-profile/#aries-agent-builders-and-agents","title":"Aries Agent Builders and Agents","text":"<p>A list of agents that claim compatibility with versions of Aries Interop Profile. A entry can be included per agent and per major Aries Interop Profile version.</p> <p>The agent type MUST be one of the following:</p> <ul> <li>Mobile - A mobile agent; does not require mediator routing capabilities, credential issuing capabilities.</li> <li>I/V - A cloud-based Issuer/Verifier agent; does not require credential holding support.</li> <li>Mediator - A mediator/relay agent; does not require verifiable credential exchange protocol capabilities.</li> <li>Holder - A cloud-based holder/prover agent; does not require credential issuing capabilities.</li> <li>Framework - A general purpose agent code base for an agent that is the basis for deployments of agents; typically supports all AIP protocols.</li> </ul> Name / Version / Link Agent Type Builder / Link Aries Interop Profile Version Test Results Notes"},{"location":"concepts/0302-aries-interop-profile/#drawbacks","title":"Drawbacks","text":"<p>It may be difficult to agree on the exact list of RFCs to support in a given version.</p>"},{"location":"concepts/0302-aries-interop-profile/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Continuing with the current informal discussions of what agents/frameworks should support and when is an ineffective way of enabling independent building of interoperable agents.</p>"},{"location":"concepts/0302-aries-interop-profile/#prior-art","title":"Prior art","text":"<p>This is a typical approach to creating an early protocol certification program.</p>"},{"location":"concepts/0302-aries-interop-profile/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>The community agreement process for setting Aries Interop Profile versions needs to be tried and adjusted as appropriate.</li> <li>The tracking of who is part of the Aries agent builders community needs to be defined so we know who should have the strongest say in the setting of Aries Interop Profile versions.</li> <li>Should the Implementations table in all RFCs (below) be used for the agent builders table (above)?  Or, should we eliminate the per RFC \u201cimplementations table (below and in all RFCs) and just use this RFC to track implementations?</li> </ul>"},{"location":"concepts/0302-aries-interop-profile/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0345-community-coordinated-update/","title":"0345: Community Coordinated Update","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: PROPOSED</li> <li>Since: 2019-12-26 (date you submit your PR)</li> <li>Status Note: Initial Draft</li> <li>Start Date: 2019-12-06</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0345-community-coordinated-update/#summary","title":"Summary","text":"<p>This RFC describes the recommended process for coordinating a community update. This is not a mandate; this process should be adapted as useful to the circumstances of the update being performed.</p>"},{"location":"concepts/0345-community-coordinated-update/#motivation","title":"Motivation","text":"<p>Occasionally, an update will be needed that requires a coordinated change to be made across the community. These should be rare, but are inevitable. The steps in this process help avoid a coordinated software deployment, where multiple teams must fit a tight timeline of software deployment to avoid compatibility problems. Tightly coordinated software deployments are difficult and problematic, and should be avoided whenever possible.</p>"},{"location":"concepts/0345-community-coordinated-update/#tutorial","title":"Tutorial","text":"<p>This process descries how to move from OLD to NEW. OLD and NEW represent the required change, where OLD represents the item being replaced, and NEW represents the item OLD will be replaced with. Often, these will be strings. </p> <p>In brief, we first accept OLD and NEW while still defaulting to OLD, Then we default to NEW (while still accepting OLD), and then we remove support for OLD. These steps are coordinated with the community with a gracious timeline to allow for development cycles and deployment ease.</p>"},{"location":"concepts/0345-community-coordinated-update/#prerequisite-community-agreement-on-change","title":"Prerequisite: Community agreement on change.","text":"<p>Before these steps are taken, the community MUST agree on the change to be made. </p>"},{"location":"concepts/0345-community-coordinated-update/#step-1-accept-old-and-new","title":"Step 1: Accept OLD and NEW","text":"<p>The first step of the process is to accept both OLD and NEW from other agents. Typically, this is done by detecting and converting one string to the other in as few places in the software as possible. This allows the software to use a common value internally, and constrains the change logic to where the values are received.</p> <p>OLD should still be sent on outbound communication to other agents.</p> <p>During step 1, it is acceptable (but optional) to begin sending NEW when receiving NEW from the other agent. OLD should still be sent by default when the other Agent's support is unknown.</p> <p>This step is formalized by writing and RFC detailing which changes are expected in this update. This step is scheduled in the community by including the update RFC in a new version of the Interop Profile and setting a community target. The schedule should allow a generous time for development, generally between 1 and 3 months.</p> <p>Step 1 Coordination: This is the most critical coordination step. The community should have completed step 1 before moving to step 2.</p>"},{"location":"concepts/0345-community-coordinated-update/#step-2-default-to-new","title":"Step 2: Default to NEW","text":"<p>The second step changes the outbound value in use from OLD to NEW. Communication will not break with agents who have completed Step 1. </p> <p>OLD must still be accepted during step 2. OLD becomes deprecated.</p> <p>During step 2, it is acceptable (but optional) to keep sending OLD when receiving OLD from the other agent. NEW should still be sent by default when the other Agent's support is unknown.</p> <p>This step is formalized by writing an RFC detailing which changes are expected in this update. This step is scheduled by including the update RFC in a new version of the Interop Profile and setting a community target date. The schedule should allow a generous time for development, generally between 1 and 3 months.</p> <p>Step 2 Coordination: The community should complete step 2 before moving to step 3 to assure that OLD is no longer being sent prior to removing support.</p>"},{"location":"concepts/0345-community-coordinated-update/#step-3-remove-support-for-old","title":"Step 3: Remove support for OLD.","text":"<p>Software will be updated to remove support for OLD. Continued use is expected to result in a failure or error as appropriate</p> <p>This step is formalized by writing an RFC detailing which changes are expected in this update. Upon acceptance of the RFC, OLD is considered invalid. At this point, nobody should be sending the OLD.</p> <p>Step 3 Coordination: The deadline for step 3 is less important than the previous steps, and may be scheduled at the convenience of each development team.</p>"},{"location":"concepts/0345-community-coordinated-update/#reference","title":"Reference","text":"<p>This process should only be used for changes that are not detectable via the Discover Features protocol, either because the Discover Features Protocol cannot yet be run or the Discover Features Protocol does not reveal the change.</p>"},{"location":"concepts/0345-community-coordinated-update/#changes-not-applicable-to-this-process","title":"Changes NOT applicable to this process","text":"<p>Any changes that can be handled by increasing the version of a protocol should do so. The new version can be scheduled via Interop Profile directly without this process.</p> <p>Example proper applications of this process include switching the base common Message Type URI, and DID Doc Service Types.</p>"},{"location":"concepts/0345-community-coordinated-update/#pace","title":"Pace","text":"<p>The pace for Steps 1 and 2 should be appropriate for the change in question, but should allow generous time to allow for developer scheduling, testing, and production deployment schedules. App store approval process sometimes take a bit of time. A generous time allowance eases the burden of implementing the change.</p>"},{"location":"concepts/0345-community-coordinated-update/#drawbacks","title":"Drawbacks","text":"<p>This approach invites the drawbacks of sanity, unpanicked deployments, and steady forward community progress.</p>"},{"location":"concepts/0345-community-coordinated-update/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>The only other general approach is a tightly coordinated rollout, which should be avoided.</li> </ul>"},{"location":"concepts/0345-community-coordinated-update/#prior-art","title":"Prior art","text":"<p>This process was discussed in Issue 318 and in person at the 2019 December Aries Connectathon.</p>"},{"location":"concepts/0345-community-coordinated-update/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Should template RFCs be included for the steps outlined?</li> </ul>"},{"location":"concepts/0345-community-coordinated-update/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/","title":"0346: DIDComm Between Two Mobile Agents Using Cloud Agent Mediator","text":"<ul> <li>Author: Sukalpo Mitra</li> <li>Start Date: 2019-06-23</li> <li>Tags: concept</li> <li>Status: PROPOSED</li> <li>Status Date: 2019-06-23</li> <li>Status Note: ???</li> </ul>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#summary","title":"Summary","text":"<p>Explains how one mobile edge agent can send messages to another mobile edge agent through cloud agents. The sender edge agent also determines the route of the message. The recipient, on the other hand, can consume messages at its own pace and time.</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#motivation","title":"Motivation","text":"<p>The DIDCOMM between two mobile edge agents should be easy and intuitive for a beginner to visualize and to implement.</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#scenario","title":"Scenario","text":"<p>Alice sends a connection request message to Bob and Bob sends back an acceptance response. For simplicity's sake, we will only consider the cloud agents in play while sending and receiving a message for Alice.</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#cloud-agent-registration-process","title":"Cloud Agent Registration Process","text":"<p>A registration process is necessary for an edge agent to discover cloud agents that it can use to send a message through them. Cloud agents in the simplest form are routers hosted as a web application that solves the problem of availability by providing a persistent IP address. The Web server has a wallet of it's own storing its private key as a provisioning record, along with any information needed to forward messages to other agents. Alice wants to accept a connection invitation from Bob. But before doing so Alice needs to register herself with one or more cloud agents. The more cloud agents she registers with the more cloud agents she can use in transporting her message to Bob. To register herself with a cloud agent she visits the website of a cloud agent and simply scans a QR code.</p> <p>The cloud agent registration invite looks like below</p> <pre><code>{\u200b\n    \"@type\": \"https://didcomm.org/didexchange/1.0/cloudagentregistrationinvitation\",\u200b\n    \"@id\": \"12345678900987654321\",\u200b\n    \"label\": \"CloudAgentA\",\u200b\n    \"recipientKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"],\u200b\n    \"serviceEndpoint\": \"https://cloudagenta.com/endpoint\",\n    \"responseEndpoint\": \"https://cloudagenta.com/response\", \n    \"consumer\": \"b1004443feff4f3cba25c45ef35b492c\",\n    \"consumerEndpoint\" : \"https://cloudagenta.com/consume\"\u200b\n}\u200b\n</code></pre> <p>The registration data is base64url-encoded and is added to alink as part of the c_a_r query param. The recipient key is the public key of \"Cloud Agent A\". The service endpoint is where the edge agent should send the message to. Response endpoint is where a response that is being sent to Alice should be sent to. For example, if Bob wants to send a message to Alice, then Bob should send the message to the response endpoint. Consumer endpoint is where Alice's edge agent should consume the messages that are sent to her. The \"Consumer\" is an identifier to identify Alice's edge agent by the cloud agent \"A\". This identifier is different with each cloud agent and hence provides low correlation risk. Each time an invitation QR code is generated, a new consumer id is generated. No acknowledgment is required to be sent to the cloud agent or vice versa as the consumer-generated is never repeated.</p> <p>All the endpoint data and the public key of the cloud agents are then stored as non secret records in Alice's wallet with a tag \"cloud-agent\"</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#how-connection-request-from-alice-flows-to-bob","title":"How connection request from Alice flows to Bob","text":"<p>When Alice scans Bob's QR code invitation. It starts preparing the connection request message. It first queries the wallet record service for records tagged with \"cloud-agent\" and puts them in a list. The edge agent now randomly chooses one from the list (say Cloud Agent \"A\") and creates a new list without the cloud agent that is already chosen. Alice's edge agent creates the connection request message json and adds the service endpoint as the chosen cloud agent's response endpoint together with its consumer id. </p> <pre><code>\"serviceEndpoint\": \"https://cloudagenta.com/response/b1004443feff4f3cba25c45ef35b492c\"\n</code></pre> <p>It then packs this message by Bob's recipient key and then creates another json message structure like the below by ising the forward message type</p> <pre><code>{\u200b\n    \"@type\": \"https://didcomm.org/routing/1.0/forward\",\u200b\n    \"@id\": \"12345678900987654321\",\u200b\n    \"msg\": \"&lt;Encrypted message for Bob here&gt;\",\n    \"to\": \"&lt;Service endpoint of Bob&gt;\"\u200b\n}\u200b\n</code></pre> <p>It then packs it with the public key of cloud agent \"A\".</p> <p>Now it randomly chooses cloud agent from the new list and keeps on repeating the process of writing the message forwarding request.</p> <p>For example, say the next random cloud agent that it chooses is Cloud Agent \"C\". So now it creates another message forward json structure as below</p> <p><pre><code>{\u200b\n    \"@type\": \"https://didcomm.org/routing/1.0/forward\",\u200b\n    \"@id\": \"12345678900987654321\",\u200b\n    \"msg\": \"&lt;Encrypted message for Cloud Agent A&gt;\",\n    \"to\": \"&lt;Service endpoint of Cloud Agent A&gt;\"\u200b\n}\u200b\n</code></pre> And then packs with Cloud Agent \"C\"'s public key.</p> <p>This process happens till it has exhausted all the list of the cloud agent in the list and then sends the message to the service endpoint of the last cloud agent (say Cloud Agent \"B\") chosen.  For example, the message could have randomly been packed for this path, B-&gt;C-&gt;A where A is one of Bob's cloud agents that stores the message on the distributed log.</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#message-forwarding-process-by-cloud-agents","title":"Message Forwarding process by cloud agents","text":"<p>When the message is reached to cloud agent \"B\", the message is first unpacked by cliud agent \"B\"'s private key. It then finds out the message type is of \"forward\". It then processes the message by taking the value of the \"message\" attribute in the decrypted json and sending it to the forwardTo URI.</p> <p>Thus Cloud Agent \"B\" unpacks the message and forward the message to Cloud Agent \"C\" who then again unpacks and forwards it to Cloud Agent \"A\". Cloud Agent \"A\" ultimately unpacks and forwards it to Bob's edge agent (For simplicity sake we are not describing how the message reaches Bob through Bob's registered cloud agents)</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#bob-returns-a-response-back","title":"Bob returns a response back","text":"<p>Bob when recives the connection request message from Alice. It then creates a connection accept response and sends the response back to Alice at the service endpoint of Alice which is </p> <pre><code>\"serviceEndpoint\": \"https://cloudagenta.com/response/b1004443feff4f3cba25c45ef35b492c\"\n</code></pre> <p>For simplicity sake, we are not describing how the message ends up at the above endpoint from Bob after multiple routing through Bob's cloud agents. When the message actually ends up at the service endpoint mentioned by Alice, which is the response endpoint of cloud agent \"A\", the cloud agent simply stores it in a distributed log(NEEDS A LINK TO KAFKA INBOX RFC) using the consumer id as a key</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#alice-consumes-connection-accepted-response-from-bob","title":"Alice consumes connection accepted response from Bob","text":"<p>Alice's edge agent periodically checks the consumer endpoint of all the cloud agents it has registered with. For each cloud agent, Alice passes the unique consumer id that was used in registration so that cloud agent can return the correct messages. When it does the same for cloud agent \"A\", it simply consumes the message from the distributed log.</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#drawbacks-and-alternatives","title":"Drawbacks and Alternatives","text":"<p>In other suggested message formatting protocol Alice would provide a list of routing keys and the endpoint of the first hop in the chain of cloud agents. That gives allice confidence that bob is forced to use the path she has provided. The proposed routing in this RFC lacks that confidence. In contrast, routing with a list of routing keys requires a lot of overhead set up before establishing a connection. This proposed routing simplifies that overhead and provides more flexibility.</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#related-art","title":"Related art","text":"<p>[related-art] #prior-art Aries-rfc Aries RFC 0046: Mediators and Relays</p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#prior-art","title":"Prior art","text":""},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#unresolved-questions","title":"Unresolved questions","text":"<p>Does separation of a \"service endpoint\" and \"Consumer endpoint\" provide a point of correlation that can be avoided by handling all messages through a single service endpoint?</p> <p>Can a cloud agent have their own army of servers that just basically looks into a registry of servers and randomly chooses an entry and exit node and a bunch of hops and just passes the message along. The exit node will then pass the message to the next cloud agent?  </p>"},{"location":"concepts/0346-didcomm-between-two-mobile-agents/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0420-rich-schemas-common/","title":"0420: Rich Schema Objects Common","text":"<ul> <li>Author: Alexander Shcherbakov, Brent Zundel, Ken Ebert </li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No recent progress and no implementations have been created.</li> <li>Start Date: 2020-02-05</li> <li>Tags: concept, rich-schemas</li> </ul>"},{"location":"concepts/0420-rich-schemas-common/#summary","title":"Summary","text":"<p>A low-level description of the components of an anonymous credential ecosystem that supports rich schemas, W3C Verifiable Credentials and Presentations, and correspondingly rich presentation requests. </p> <p>Please see 0250: Rich Schema Objects  for high-level description.</p> <p>This RFC provides more low-level description of Rich Schema objects defining how they are identified and referenced. It also defines a general template and common part for all Rich Schema objects. </p>"},{"location":"concepts/0420-rich-schemas-common/#motivation","title":"Motivation","text":"<p>Please see 0250: Rich Schema Objects for use cases and high-level description of why Rich Schemas are needed.</p> <p>This RFC serves as a low-level design of common parts between all Rich Schema objects, and can help developers to  properly implement Rich Schema transactions on the Ledger and the corresponding client API. </p>"},{"location":"concepts/0420-rich-schemas-common/#tutorial-general-principles","title":"Tutorial: General Principles","text":"<p>By Rich Schema objects we mean all objects related to Rich Schema concept (Context, Rich Schema, Encoding, Mapping, Credential Definition, Presentation Definition)</p> <p>Let's discuss a number of items common for all Rich Schema objects</p>"},{"location":"concepts/0420-rich-schemas-common/#components-and-repositories","title":"Components and Repositories","text":"<p>The complete architecture for every Rich Schema object involves three separate components: - <code>aries-vdri</code>: This is the location of the <code>aries-verifiable-data-registy-interface</code>. Changes to this code will enable users of any data registry with an <code>aries-vdri</code>-compatible data manager to handle Rich Schema objects. - Specific Verifiable Data Registry implementation (for example, <code>indy-vdr</code>). It needs to comply with the interface described by the <code>aries-verifiable-data-registry-interface</code> and is built to plug in to the aries ecosystem. It contains the code to communicate with a specific data registry (ledger).</p> <ul> <li>Specific Data Registry (Ledger) implementation (for example, <code>indy-node</code>). Changes to this code will enable a Rich Schema object to be written to and retrieved from a data registry.</li> </ul>"},{"location":"concepts/0420-rich-schemas-common/#immutability-of-rich-schema-objects","title":"Immutability of Rich Schema Objects","text":"<p>The following Rich Schema objects are immutable: - Context - Rich Schema - Encoding - Mapping</p> <p>The following Rich Schema objects can be mutable: - Credential Definition - Presentation Definition</p> <p>Credential Definition and Presentation Definition should be immutable in most of the cases, but some applications may consider them as mutable objects.</p> <p>Credential Definition can be considered as a mutable object since the Issuer may rotate keys present there. However, rotation of Issuer's keys should be done carefully as it will invalidate all credentials issued for this key.</p> <p>Presentation Definition can be considered as a mutable object since restrictions to Issuers, Schemas and  Credential Definitions to be used in proof may evolve.  For example, Issuer's key for a given Credential Definition may be compromised, so  Presentation Definition can be updated to exclude this Credential Definition from the list of recommended ones. </p> <p>Please note, that some ledgers (Indy Ledger for example) have configurable auth rules which allow to have restrictions on mutability of particular objects, so that it can be up to applications and network administrators to decide if Credential Definition and Presentation Definition  are mutable. </p>"},{"location":"concepts/0420-rich-schemas-common/#identification-of-rich-schema-objects","title":"Identification of Rich Schema Objects","text":"<ul> <li>Every Rich Schema object is identified by a unique ID</li> <li>DID can be used as the ID.<ul> <li>The id-string of the DID is the base58 representation of the SHA2-256 hash of the canonical form  of the <code>content</code> field (see How Rich Schema objects are stored in the Data Registry.  The canonicalization scheme we recommend is the IETF draft   JSON Canonicalization Scheme (JCS). </li> </ul> </li> <li>There is additional metadata (aliases) that can identify Rich Schema objects on the ledger  in a more user-friendly way.</li> <li>rs_name </li> <li>rs_version</li> <li>rs_type </li> <li>Issuer's or Endorser's DID is not part of metadata, which means that Rich Schema objects of a given type must be unique among all Issuers and Endorsers.      </li> </ul> <p>The suggested Identification scheme allows to have a unique Identifier for any Rich Schema object.  DID's method name (for example <code>did:sov</code>) allows to identify Rich Schema objects with equal content within different  data registries (ledgers).   </p>"},{"location":"concepts/0420-rich-schemas-common/#referencing-rich-schema-objects","title":"Referencing Rich Schema Objects","text":"<ul> <li>Any Rich Schema object is referenced by other Rich Schema objects by its ID (DID).</li> <li>A Rich Schema object may reference a Rich Schema object from another ledger (as defined by DID's method name).</li> </ul>"},{"location":"concepts/0420-rich-schemas-common/#relationship","title":"Relationship","text":"<ul> <li>A credential definition refers to a single mapping object</li> <li>A mapping object refers to a single schema object</li> <li>If there is no existent single schema to be referenced by a mapping object, a new schema must be created potentially referencing or extending existing ones.</li> <li>Each attribute in a schema may be included in the mapping one or more times (it is possible to encode a single attribute  in multiple ways). A mapping may map only a subset of the attributes of a schema.</li> <li>A presentation definition refers to 1 or more schema, mapping or credential definition objects.</li> </ul> <p>A presentation definition may use only a subset of the attributes of a schema.  </p> <p></p>"},{"location":"concepts/0420-rich-schemas-common/#usage-of-json-ld","title":"Usage of JSON-LD","text":"<p>The following Rich Schema objects must be in JSON-LD format: - Schema - Mapping  - Presentation Definition</p> <p>Context object can also be in JSON-LD format.</p> <p>If a Rich Schema object is a JSON-LD object, the <code>content</code>'s <code>@id</code> field must be equal to the <code>id</code>.</p> <p>More details about JSON-LD usage may be found in the RFCs for specific rich schema objects.</p>"},{"location":"concepts/0420-rich-schemas-common/#how-rich-schema-objects-are-stored-in-the-data-registry","title":"How Rich Schema objects are stored in the Data Registry","text":"<p>Any write request for Rich Schema object has the same fields: <pre><code>'id': &lt;Rich Schema object's ID&gt;                # DID string \n'content': &lt;Rich Schema object as JSON&gt;        # JSON-serialized string\n'rs_name': &lt;rich schema object name&gt;           # string\n'rs_version': &lt;rich schema object version&gt;     # string\n'rs_type': &lt;rich schema object type&gt;           # string enum (currently one of `ctx`, `sch`, `map`, `enc`, `cdf`, `pdf`)\n'ver': &lt;format version&gt;                        # string                              \n</code></pre> - <code>id</code> is a unique ID (for example a DID with a id-string being base58 representation of the SHA2-256 hash of the <code>content</code> field) - The <code>content</code> field here contains a Rich Schema object in JSON-LD format (see 0250: Rich Schema Objects). It's passed and stored as-is. The <code>content</code> field must be serialized in the canonical form. The canonicalization scheme we recommend is the IETF draft   JSON Canonicalization Scheme (JCS). - <code>metadata</code> contains additional fields which can be used for human-readable identification   - <code>ver</code> defines the version of the format. It defines what fields and metadata are there, how <code>id</code> is generated, what hash function is used there, etc.  - Author's and Endorser's DIDs are also passed as a common metadata fields for any Request. </p> <p>If a Rich Schema object is a JSON-LD object, the <code>content</code>'s <code>@id</code> field must be equal to the <code>id</code>.</p>"},{"location":"concepts/0420-rich-schemas-common/#querying-rich-schema-objects-from-the-data-registry","title":"Querying Rich Schema objects from the Data Registry","text":"<ul> <li>Any Rich Schema object can be obtained from a Data Registry (Ledger) by its ID (DID).</li> <li>It should be possible to get Rich Schema objects by metadata as well: <code>(rs_name, rs_version, rs_type)</code>.</li> <li>Currently it's supposed that every Rich Schema object is queried individually, so it's up to clients and applications to get, query and cache all dependent Rich Schema objects.</li> <li>We may support resolving a Rich Schema object by a DID as a DID DOC object once aries-vdr interface for DID resolving is defined and DID DOC specification is finalized.</li> </ul> <p>The following information is returned from the Ledger in a reply for any get request of a Rich Schema object: <pre><code>'id': &lt;Rich Schema object's ID&gt;              # DID string \n'content': &lt;Rich Schema object as JSON&gt;      # JSON-serialized string\n'rs_name': &lt;rich schema object name&gt;         # string\n'rs_version': &lt;rich schema object version&gt;   # string\n'rs_type': &lt;rich schema object type&gt;         # string enum (currently one of `ctx`, `sch`, `map`, `enc`, `cdf`, `pdf`)\n'ver': &lt;format version&gt;                      # string\n'from': &lt;author DID&gt;,                        # DID string\n'endorser': &lt;endorser DID&gt;,                  # DID string\n</code></pre></p> <p>Common fields specific to a Ledger are also returned. </p>"},{"location":"concepts/0420-rich-schemas-common/#aries-data-registry-interface","title":"Aries Data Registry Interface","text":"<p>We can have a unified API to write and read Rich Schema objects from a Data Registry. Just two methods are sufficient to handle all Rich Schema types: - <code>write_rich_schema_object</code> - <code>read_rich_schema_object_request</code></p>"},{"location":"concepts/0420-rich-schemas-common/#write_rich_schema_object","title":"write_rich_schema_object","text":"<p><pre><code>Writes a Rich Schema object to the ledger.\n\n#Params\nsubmitter: information about submitter\ndata: {\n    id: Rich Schema object's unique ID for example a DID with an id-string being\n        base58 representation of the SHA2-256 hash of the `content` field),\n    content: Rich Schema object as a JSON or JSON-LD string,\n    rs_name: Rich Schema object name,\n    rs_version: Rich Schema object version,\n    rs_type: Rich schema object type's enum string (currently one of `ctx`, `sch`, `map`, `enc`, `cdf`, `pdf`),\n    ver: the version of the generic object template\n},\nregistry: identifier for the registry\n\n#Returns\nregistry_response: result as json,\nerror: {\n    code: aries common error code,\n    description:  aries common error description\n}\n</code></pre> The combination of <code>rs_type</code>, <code>rs_name</code>, and <code>rs_version</code> must be unique among all rich schema objects on the ledger.</p>"},{"location":"concepts/0420-rich-schemas-common/#read_rich_schema_object_by_id","title":"read_rich_schema_object_by_id","text":"<pre><code>Reads a Rich Schema object from the ledger by its unique ID.\n\n#Params\nsubmitter (optional): information about submitter\ndata: {\n    id: Rich Schema object's ID (as a DID for example),\n    ver: the version of the generic object template\n},\nregistry: identifier for the registry\n\n#Returns\nregistry_response: result as json,\nerror: {\n    code: aries common error code,\n    description:  aries common error description\n}\n</code></pre>"},{"location":"concepts/0420-rich-schemas-common/#read_rich_schema_object_by_metadata","title":"read_rich_schema_object_by_metadata","text":"<pre><code>Reads a Rich Schema object from the ledger by its unique combination of (name, version, type)\n\n#Params\nsubmitter (optional): information about submitter\ndata: {\n    rs_name: Rich Schema object name,\n    rs_version: Rich Schema object version,\n    rs_type: Rich schema object type's enum string (currently one of `ctx`, `sch`, `map`, `enc`, `cdf`, `pdf`),\n    ver: the version of the generic object template\n},\nregistry: identifier for the registry\n\n#Returns\nregistry_response: result as json,\nerror: {\n    code: aries common error code,\n    description:  aries common error description\n}\n</code></pre>"},{"location":"concepts/0420-rich-schemas-common/#reference","title":"Reference","text":"<ul> <li>0250: Rich Schema Objects</li> <li>0249: Aries Rich Schema Contexts </li> <li>0281: Aries Rich Schemas</li> </ul>"},{"location":"concepts/0420-rich-schemas-common/#drawbacks","title":"Drawbacks","text":"<p>Rich schema objects introduce more complexity.</p>"},{"location":"concepts/0420-rich-schemas-common/#rationale-and-alternatives","title":"Rationale and alternatives","text":""},{"location":"concepts/0420-rich-schemas-common/#rich-schema-object-id","title":"Rich Schema object ID","text":"<p>The following options on how a Rich Schema object can be identified exist: - DID unique for each Rich Schema - DID URL with the origin (issuer's) DID as a base - DID URL with a unique (not issuer-related) DID as a base - UUID or other unique ID</p> <p>UUID doesn't provide global resolvability. We can not say what ledger the Rich Schema object belongs to  by looking at the UUID.</p> <p>DID and DID URL give persistence, global resolvability and decentralization. We can resolve the DID and understand what ledger the Rich Schema object belongs to. Also we can see that the object with the same id-string on different ledger is the same object (if id-string is calculated against a canonicalized hash of the content).  </p> <p>However, Rich Schema's DIDs don't have cryptographic verifiability property of common DIDs, so this is a DID not associated with keys in general case. This DID belongs neither to person nor organization nor thing.</p> <p>Using Issuer's DID (origin DID) as a base for DID URL may be too Indy-specific as other ledgers may not have an Issuer DID. Also it links a Rich Schema object to the Issuer belonging to a particular ledger. </p> <p>So, we are proposing to use a unique DID for each Rich Schema object as it gives more natural way to identify  an entity in the distributed ledger world.  </p>"},{"location":"concepts/0420-rich-schemas-common/#rich-schema-object-as-did-doc","title":"Rich Schema object as DID DOC","text":"<p>If Rich Schema objects are identified by a unique DID, then a natural question is whether each Rich Schema object  needs to be presented as a DID DOC and resolved by a DID in a generic way.</p> <p>We are not requiring to define Rich Schema objects as DID DOCs for now. We may re-consider this in future once DID DOC format is finalized.</p>"},{"location":"concepts/0420-rich-schemas-common/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the proposed interface generic enough to support other data registries?</li> <li>We are not defining Rich Schema objects as DID DOCs for now. We may re-consider this in future  once aries-vdr interface for DID resolving is defined and DID DOC specification is finalized.</li> <li>Whether we should extend DID to be a standard for Rich Schema object IDs.</li> <li>Whether the proposed way to make a Canonicalization form of a content to be used for DID's id-string generation is good enough. </li> </ul>"},{"location":"concepts/0420-rich-schemas-common/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0430-machine-readable-governance-frameworks/","title":"Aries RFC 0430: Machine-Readable Governance Frameworks","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: PROPOSED</li> <li>Since: 2020-02-24</li> <li>Status Note: early proposal only  </li> <li>Start Date: 2020-02-24</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#summary","title":"Summary","text":"<p>Explains how governance frameworks are embodied in formal data structures, so it's possible to react to them with software, not just with human intelligence.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#motivation","title":"Motivation","text":"<p>We need to be able to write software that reacts to arbitrary governance frameworks in standard ways. This will allow various desirable ../../features.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#tutorial","title":"Tutorial","text":"<p>A governance framework (also called a trust framework in some contexts) is a set of rules that establish trust about process (and indirectly, about outcomes) in a given context. For example, the rules that bind buyers, merchants, vendors, and a global credit card company like Mastercard or Visa constitute a governance framework in a financial services context \u2014 and they have a corresponding trust mark to make the governance framework's relevance explicit. The rules by which certificate authorities are vetted and accepted by browser manufacturers, and by which CAs issue derivative certificates, constitute a governance framework in a web context. Trust frameworks are like guy wires: they balance opposing forces to produce careful alignment and optimal behavior.</p> <p></p> <p>Decentralized identity doesn't eliminate all forms of centralized authority, but its opt-in collaboration, openness, and peer orientation makes the need for trust rules particularly compelling. Somehow, a community needs to agree on answers to questions like these:</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#sample-questions-answered-in-a-trust-framework","title":"Sample Questions Answered in a Trust Framework","text":"<ul> <li>Which institutions should be trusted to attest key facts such as an individual's citizenship, graduation from college, HIV status, membership in an ethnic group, credit worthiness, etc?</li> <li>How do rules about consent, privacy, and repudiation influence the flow of data?</li> <li>Who can hold which parties accountable, and how, and when?</li> <li>What levels of assurance are required for certain privileges?</li> <li>How auditable must various activities be?</li> <li>How do incentives and reputation work?</li> <li>What terms of service are standard, odd-but-reasonable, or prohibited?</li> </ul> <p>Many industry groups are exploring these questions, and are building careful documentation of the answers they produce. It is not the purpose of this RFC to duplicate or guide such work. Rather, it's our goal to answer a secondary question:</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#the-question-tackled-by-this-rfc","title":"The Question Tackled By This RFC","text":"<p>How can answers to these questions be represented so they are consumable as artifacts of software policy? </p> <p>When we have good answers to this question, we can address feature requests like the following:</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#desirable-features","title":"Desirable Features","text":"<ul> <li>All the software used at a refugee camp \u2014 whether built by the United Nations, by an NGO like Doctors Without Borders, by startups providing identity wallets to individuals, or by military personnel \u2014 has a shared understanding about standards of proof, consent, enforcement, appeal, and privacy.</li> <li>Rules in an ecosystem can be versioned and updated formally, and parties who interact can know unambiguously whether their expectations align. If there is a misalignment, it is easy to identify the particulars.</li> <li>A user of an SSI-centric mobile app can be prompted about whether they'd like to accept as proof credentials issued under the rules of governance framework X (e.g., the governance framework for accredited institutions of higher education in Germany) \u2014 allowing them to accept or reject entire categories of proof without having to track the DIDs and business practices of every individual issuer they might encounter.</li> </ul>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#sample-data-structure","title":"Sample Data Structure","text":"<p>Trust frameworks generally begin as human-friendly content. They have to be created, reviewed, and agreed upon by experts from various disciplines: legal, business, humanitarian, government, trade groups, advocacy groups, etc. Developers can help by surfacing how rules are (or are not) susceptible to modeling in formal data structures. This can lead to an iterative process, where data structures and human conversations create refinement pressure on each other until the framework is ready for release.</p> <p>[TODO: The following blurb of JSON is one way to embody what we're after. I can imagine other approaches but haven't thought them through in detail. I'm less interested in the details of the JSON, for now, than in the ../../concepts we're trying to communicate and automate. So have a conversation about whether this format works for us, or should be tweaked/replaced.]</p> <p>Each problem domain will probably have unique requirements. Therefore, we start with a general governance framework recipe, but plan for extension. We use JSON-LD for this purpose. Here we present a simple example for the problem domain of university credentials in Germany. It manifests just the components of a governance framework that are common across all contexts; additional JSON-LD <code>@context</code> values can be added to introduce more structure as needed. (See Field Details for explanatory comments.)</p> <pre><code>{\n    \"@context\": [\n        // The first context must be this RFC's context. It defines core properties.\n        \"https://github.com/hyperledger/aries-rfcs/blob/main../../concepts/0430-machine-readable-governance-frameworks/context.jsonld\", \n        // Additional contexts can be added to extend.\n        \"https://kmk.org/uni-accred-trust-fw\"\n    ],\n    \"name\": \"Universit\u00e4tsakkreditierung\"\n    \"version\": \"1.0\",\n    \"logo\": \"http://kmk.org/uni-accred-trust-fw/logo.png\",\n    \"description\": \"Governs accredited colleges and universities in Germany.\",\n    \"docs_uri\": \"http://https://kmk.org/uni-accred-trust-fw/v1\",\n    \"data_uri\": \"http://https://kmk.org/uni-accred-trust-fw/v1/tf.json\",\n    \"topics\": [\"education\"],\n    \"jurisdictions\": [\"de\", \"eu\"],\n    \"geos\": [\"Deutschland\"],\n    \"roles\": [\"accreditor\", \"school\", \"graduate\", \"safe-verifier\"],\n    \"privileges\": [\n        {\"name\": \"accredit\", \"uri\": \"http://kmk.org/tf/accredit\"},\n        {\"name\": \"issue-edu\", \"uri\": \"http://kmk.org/tf/issue-edu\"},\n        {\"name\": \"hold-edu\", \"uri\": \"http://kmk.org/tf/hold-edu\"},\n        {\"name\": \"request-proof\", \"uri\", \"http://kmk.org/tf/request-proof\"\n    ],\n    \"duties\": [\n        {\"name\": \"safe-accredit\", \"uri\": \"http://kmk.org/tf/responsible-accredit\"},\n        {\"name\": \"GDPR-dat-control\", \"uri\": \"http://europa.eu/gdpr/trust-fw/gdpr-data-controller\"}\n        {\"name\": \"GDPR-edu-verif\", \"uri\": \"http://kmk.org/tf/gdpr-verif\"}\n        {\"name\": \"accept-kmk-tos\", \"uri\": \"http://kmk.org/tf/tos\"}\n    ],\n    \"define\": [\n        {\"name\": \"KMK\": \"id\": \"did:example:abc123\"},\n        {\"name\": \"KMK\": \"id\": \"did:anotherexample:def456\"},\n    ], \n    \"rules\": [\n        {\"grant\": [\"accredit\"], \"when\": {\"name\": \"KMK\"},\n            \"duties\": [\"safe-accredit\"]},\n        {\"grant\": [\"issue-edu\"], \"when\": {\n                // Proof request (see RFC 0037) specifying that\n                // institution is accredited by KMK.\n            },\n            // Any party who fulfills these criteria is considered\n            // to have the \"school\" role.\n            \"thus\": [\"school\"],\n            // And is considered to have the \"GDPR-dat-control\" duty.\n            \"duties\": [\"GDPR-dat-control\", \"accept-kmk-tos\"]\n        },\n        {\"grant\": \"hold-edu\", \"when\": {\n                // Proof request specifying that holder is a human.\n                // The presence of this item in the GF means that\n                // conforming issuers are supposed to verify\n                // humanness before issuing. Issuers can impose\n                // additional criteria; this is just the base\n                // requirement.\n            },\n            // Any party who fulfills these criteria is considered\n            // to qualify for the \"graduate\" role.\n            \"thus\": \"graduate\",\n            \"duties\": [\"accept-kmk-tos\"]\n        },\n        // In this governance framework, anyone can request proof based\n        // on credentials, as long as they demonstrate that they possess\n        // an \"approved verifier\" credential.\n        {\n            \"grant\": \"request-proof\", \"when\": {\n                // Proof request specifying that the party must possess\n                // a credential that makes them an approved verifier.\n                // The presence of this item in the GF means that\n                // provers should, at a minimum, verify the verifiers\n                // in this way before sharing proof. Provers can impose\n                // additional criteria of their own; this is just the\n                // base requirement.\n            }, \"thus\": \"safe-verifier\",\n            \"duties\": [\"GDPR-edu-verif\", \"accept-kmk-tos\"]\n        },\n        // Is there an authority that audits interactions?\n        \"audit\": {\n            // Where should reports be submitted via http POST?\n            \"uri\": \"http://kmk.org/audit\",\n            // How likely is it that a given interaction needs to\n            // be audited? Each party in the interaction picks a\n            // random number between 0 and 1, inclusive; if the number\n            // is &lt;= this number, then that party submits a report about it.\n            \"probability\": \"0.01\"\n        },\n        // Is there an authority to whom requests for redress can\n        // be made, if one party feels like another violates\n        // the governance framework? \n        \"redress\": {\n            \"uri\": \"http://kmk.org/redress\"\n        }\n    }    \n}\n</code></pre>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#using-the-sample","title":"Using the Sample","text":"<p>Let's look at how the above structure can be used to influence behavior of verifiable credential management software, and the parties that use it.</p> <p>We begin by noticing that KMK (KultusMinisterKonferenz), the accrediting body for universities in Germany, has a privileged role in this governance framework. It is given the right to operate as \"KMK\" as long as it proves control of one of the two DIDs named in the <code>define</code> array. </p> <p>We posit an issuer, Faber College, that wants to issue credentials compliant with this governance framework. This means that Faber College wants the <code>issue-edu</code> privilege defined at http://kmk.org/tf/issue-edu (see the second item in the <code>privileges</code> array). It wants to create credentials that contain the following field: <code>\"trust_framework\": \"http://https://kmk.org/uni-accred-trust-fw/v1/tf.json\"</code> (see the <code>data_uri</code> field). It wants to have a credential from KMK proving its accreditation (see second item in the <code>rules</code> array).</p> <p>Faber is required by this governance framework to accept the terms of service published at http://kmk.org/tf/tos, because it can't get the <code>issue-edu</code> privilege without incurring that duty (see the <code>accept-kmk-tos</code> duty in the second item in the <code>rules</code> array). KMK by implication incurs the obligation to enforce these terms of service when it issues a credential attesting Faber's accreditation and compliance with the governance framework.</p> <p>Assuming that Faber proceeds and satisfies KMK, Faber is now considered a <code>school</code> as far as this governance framework is concerned.</p> <p>Now, let us suppose that Alice, a student at Faber, wants to get a diploma as a verifiable credential. In addition to whatever else Faber does before it gives Alice a diploma, Faber is obligated by the governance framework to challenge Alice to prove she's a human being (see <code>when</code> in the third item of the <code>rules</code> array). Hopefully this is easy, and was done long before graduation. :-) It is also obligated to introduce Alice to the terms of service for KMK, since Alice will be acquiring the <code>graduate</code> role and this rule has the <code>accept-kmk-tos</code> duty. How Faber does this is something that might be clarified in the terms of service that Faber already accepted; we'll narrate one possible approach.</p> <p>Alice is holding a mobile app that manages credentials for her. She clicks an invitation to receive a credential in some way. What she sees next on her screen might look something like this:</p> <p></p> <p>Her app knew to display this message because the issuer, Faber College, communicated its reliance on this governance framework (by referencing its <code>data_uri</code>) as part of an early step in the issuance process (e.g., in the invitation or in the <code>offer-credential</code> message). Notice how metadata from the governance framework \u2014 its title, version, topics, and descriptions \u2014 show up in the prompt. Notice as well that governance frameworks have reputations. This helps users determine whether the rules are legitimate and worth using. The \"More Info\" tab would link to the governance framework's <code>docs_uri</code> page.</p> <p>Alice doesn't have to re-accept the governance framework if she's already using it (e.g., if she already activated it in her mobile app because it's relevant to other credentials she holds). As a person works regularly within a particular credential domain, decisions like these will become cached and seamless. However, we're showing the step here, for completeness.</p> <p>Suppose that Alice accepts the proposed rules. The governance framework requires that she also accept the KMK terms of service. These might require her to report any errors in her credential promptly, and clarify that she has the right to appeal under certain conditions (see the <code>redress</code> section of the governance framework data structure). They might also discuss the KMK governance framework's requirement for random auditing (see the <code>audit</code> section).</p> <p>A natural way to introduce Alice to these topics might be to combine them with a normal \"Accept terms of service\" screen for Faber itself. Many issuers are likely to ask holders to agree to how they want to manage revocation, privacy, and GDPR compliance; including information about terms that Faber inherited from the governance framework would be an easy addition.</p> <p>Suppose, therefore, that Alice is next shown a \"Terms of Service\" screen like the following.</p> <p></p> <p>Note the hyperlink back to the governance framework; if Alice already accepted the governance framework in another context, this helps her know what governance framework is in effect for a given credential.</p> <p>After Alice accepts the terms, she now proceeds with the issuance workflow. For the most part, she can forget about the governance framework attached to her credential \u2014 but the software doesn't. Some of the screens it might show her, because of information that it reads in the governance framework, include things like:</p> <p></p> <p>Or, alternatively:</p> <p></p> <p>In either case, proof of the issuer's qualifications was requested automatically, using canned criteria (see the second item in the governance framework's <code>rules</code> array).</p> <p>A similar kind of check can be performed on verifiers:</p> <p></p> <p>Or, alternatively:</p> <p></p> <p>Trust framework knowledge can also be woven into other parts of a UI, as for example:</p> <p></p> <p>And:</p> <p></p> <p>And:</p> <p></p> <p>The point here is not the specifics in the UI we're positing. Different UX designers may make different choices. Rather, it's that by publishing a carefully versioned, machine-readable governance framework, such UIs become possible. The user's experience becomes less about individual circumstances, and more about general patterns that have known reputations, dependable safeguards, and so forth.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#versioning","title":"Versioning","text":"<p>Trust framework data structures follow semver rules:</p> <ul> <li> <p>A major change is one that breaks the trust status of another party as a result of the change. Examples include:</p> <ul> <li>Altering the internal structure of the JSON in a breaking way, such that software can no longer process the structure. (Software is required to ignore fields in this structure that it doesn't understand, so simply adding things won't do this.)</li> <li>Disallowing a formerly defined field.</li> <li>Making a field required that used to be optional.</li> <li>Removing a defined role or privilege, such that relationships built under an old version of the framework are no longer explainable in an updated version.</li> <li>Changing how privileges are granted, in such a way that a party who had privileges before would lose them across the update.</li> <li>Substantive changes to terms of service.</li> </ul> </li> <li> <p>A minor change adds precision or options to an existing governance framework, without invalidating trust built with proximate, preceding versions. For example:</p> <ul> <li>Adding new roles or privileges.</li> <li>Changing URIs or minor details of auditing, redress, or terms of service.</li> <li>Changing privilege grants such that existing parties with existing privileges get new privileges as well.</li> </ul> </li> <li> <p>Patch versions of governance frameworks are supported but generally not displayed. They should be safe to accept automatically. They include things like:</p> <ul> <li>Adding new topics (hash tags).</li> <li>Tweaking descriptions.</li> </ul> </li> </ul>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#localization","title":"Localization","text":"<p>Trust frameworks can offer localized alternatives of text using the same mechanism described in RFC 0043: l10n; treat the governance framework JSON as a DIDComm message and use decorators as it describes.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#reference","title":"Reference","text":"<p>We've tried to make the sample JSON above self-describing. All fields are optional except the governance framework's <code>name</code>, <code>version</code>, <code>data_uri</code>, and at least one <code>define</code> or <code>rules</code> item to confer some trust.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#field-details","title":"Field Details","text":""},{"location":"concepts/0430-machine-readable-governance-frameworks/#name","title":"<code>name</code>","text":"<p>A short descriptive string that explains the governance framework's purpose and focus. Extends http://schema.org/name.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#version","title":"<code>version</code>","text":"<p>A semver-formatted value. Typically only major and minor segments are used, but patch should also be supported if present. Extends http://schema.org/version with the major/minor semantics discussed under Versioning above.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#logo","title":"<code>logo</code>","text":"<p>A URI that references something visually identifying for this framework, suitable for display to a user. Extends http://schema.org/logo.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#description","title":"<code>description</code>","text":"<p>Longer explanatory comment about the purpose and scope of the framework. Extends http://schema.org/description.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#docs_uri","title":"<code>docs_uri</code>","text":"<p>Where is this governance framework officially published in human-readable form? A human should be able to browse here to learn more. Extends http://schema.org/url.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#data_uri","title":"<code>data_uri</code>","text":"<p>Where is this governance framework officially published as a machine-readable data structure? A computer should be able to GET this JSON (MIME type = application/json) at the specified URI.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#topics","title":"<code>topics</code>","text":"<p>In which problem domains is this governance framework relevant? Think of these like hash tags; they constitute a loose, overlapping topic cloud rather than a normative taxonomy; the purpose is to facilitate search.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#geos","title":"<code>geos</code>","text":"<p>In which geographies is this governance framework relevant? May be redundant with jurisdictions in many cases.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#jurisdictions","title":"<code>jurisdictions</code>","text":"<p>In which legal jurisdictions is this governance framework relevant? Values here should use ISO 639-2 or 3 language code, possibly narrowed to a standard province and even county/city using <code>&gt;</code> as the narrowing character, plus standard abbreviations where useful: <code>us&gt;tx&gt;houston</code> for \"Houston, Texas, USA\" or <code>ca&gt;qc</code> for the province of Quebec in Canada.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#roles","title":"<code>roles</code>","text":"<p>Names all the roles that are significant to understanding interactions in this governance framework. These map to X in rules like \"X can do Y if Z.\"</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#privileges","title":"<code>privileges</code>","text":"<p>Names all the privileges that are significant to understanding interactions in this governance framework. These map to Y in rules like \"X can do Y if Z.\" Each privilege is defined for humans at the specified URI, so a person can understand what it entails.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#duties","title":"<code>duties</code>","text":"<p>Name all the duties that are significant to understanding interactions in this governance framework. Each duty is defined for humans at the specified URI, so a person can understand what it entails.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#define","title":"<code>define</code>","text":"<p>Uses an array of <code>{\"name\":x, \"id\": did value}</code> objects to define key participants in the ecosystem.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#rules","title":"<code>rules</code>","text":"<p>Uses SGL syntax to describe role-based rules of behavior like \"X can do Y if Z,\" where Z is a criterion following \"when\". </p> <p>Another sample governance framework (including the human documentation that would accompany the data structure) is presented as part of the discussion of guardianship in RFC 0103.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#drawbacks","title":"Drawbacks","text":""},{"location":"concepts/0430-machine-readable-governance-frameworks/#timing","title":"Timing?","text":"<p>It may be early in the evolution of the ecosystem to attempt to standardize governance framework structure. (On the other hand, if we don't standardize now, we may be running the risk of unwise divergence.)</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#overkill","title":"Overkill?","text":"<p>Joe Andrieu has pointed out on W3C CCG mailing list discussions that some important use cases for delegation involve returning to the issuer of a directed capability to receive the intended privilege. This contrasts with the way verifiable credentials are commonly used (across trust domain boundaries).</p> <p>Joe notes that governance frameworks are unnecessary (and perhaps counterproductive) for the simpler, within-boundary case; if the issuer of a directed capability is also the arbiter of trust in the end, credentials may be overkill. To the extent that Joe's insight applies, it may suggest that formalizing governance framework data structures is also overkill in some use cases.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>We could leave governance frameworks as entirely human-consumable artifacts. This would cause developers to interpret each set of such artifacts into code in a unique way. Bespoke adaptation might result in more polished UX and impose less learning curve on users, but it would also create larger integration burdens and greater difficulty in assessing trust.</li> </ul>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#prior-art","title":"Prior art","text":"<p>Some of the work on consent receipts, both in the Kantara Initiative and here in RFC 0167, overlaps to a small degree. However, this effort and that one are mainly complementary rather than conflicting.</p>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>How do we enumerate canonical proof requests, and map them to circumstances appropriately?</li> <li>How do we test whether those circumstances apply? </li> </ul>"},{"location":"concepts/0430-machine-readable-governance-frameworks/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0430-machine-readable-governance-frameworks/gov-fw-covid-19/","title":"Gov fw covid 19","text":"<pre><code>{\n    \"@context\": [\n        \"https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks\", \n        \"https://fightthevirus.org/covid19-fw\"\n    ],\n    \"name\": \"COVID-19 Creds\"\n    \"1.0\",\n    \"description\": \"Which health-related credentials can be trusted for which levels of assurance, given which assumptions.\",\n    \"docs_uri\": \"http://fightthevirus.org/covid19-fw/v1\",\n    \"data_uri\": \"http://fightthevirus.org/covid19-fw/v1/tf.json\",\n    \"topics\": [\"health\", \"public safety\"],\n    \"jurisdictions\": [\"us\", \"uk\", \"eu\"],\n    \"roles\": [\"healthcare-provider\", \"healthcare-worker\", \"patient\"],\n    \"privileges\": [\n        {\"name\": \"travel\", \"uri\": \"http://ftv.org/tf/travel\"},\n        {\"name\": \"receive-healthcare\", \"uri\": \"http://ftv.org/tf/be-patient\"},\n        {\"name\": \"tlc-fragile\", \"uri\": \"http://ftv.org/tf/tlc\"},\n        {\"name\": \"visit-hot-zone\", \"uri\": \"http://ftv.org/tf/visit\"}\n    ],\n    // Name all the duties that are significant to understanding\n    // interactions in this governance framework. Each duty is defined for humans\n    // at the specified URI, so a person can understand what it\n    // entails.\n    \"duties\": [\n        {\"name\": \"safe-accredit\", \"uri\": \"http://kmk.org/tf/responsible-accredit\"},\n        {\"name\": \"GDPR-dat-control\", \"uri\": \"http://europa.eu/gdpr/trust-fw/gdpr-data-controller\"}\n        {\"name\": \"GDPR-edu-verif\", \"uri\": \"http://kmk.org/tf/gdpr-verif\"}\n        {\"name\": \"accept-kmk-tos\", \"uri\": \"http://kmk.org/tf/tos\"}\n    ],\n    // Use DIDs to define key participants in the ecosystem. KMK is\n    // the accreditation authority for higher education in Germany.\n    // Here we show it using two different DIDs.\n    \"define\": [\n        {\"name\": \"KMK\": \"id\": \"did:example:abc123\"},\n        {\"name\": \"KMK\": \"id\": \"did:anotherexample:def456\"},\n    ], \n    // Describe role-based rules of behavior like \"X can do Y if Z,\"\n    // where Z is a criterion following \"when\".\n    \"rules\": [\n        {\"grant\": [\"accredit\"], \"when\": {\"name\": \"KMK\"},\n            \"duties\": [\"safe-accredit\"]},\n        {\"grant\": [\"issue-edu\"], \"when\": {\n                // Proof request (see RFC 0037) specifying that\n                // institution is accredited by KMK.\n            },\n            // Any party who fulfills these criteria is considered\n            // to have the \"school\" role.\n            \"thus\": [\"school\"],\n            // And is considered to have the \"GDPR-dat-control\" duty.\n            \"duties\": [\"GDPR-dat-control\", \"accept-kmk-tos\"]\n        },\n        {\"grant\": \"hold-edu\", \"when\": {\n                // Proof request specifying that holder is a human.\n                // The presence of this item in the TF means that\n                // conforming issuers are supposed to verify\n                // humanness before issuing. Issuers can impose\n                // additional criteria; this is just the base\n                // requirement.\n            },\n            // Any party who fulfills these criteria is considered\n            // to qualify for the \"graduate\" role.\n            \"thus\": \"graduate\",\n            \"duties\": [\"accept-kmk-tos\"]\n        },\n        // In this governance framework, anyone can request proof based\n        // on credentials. No criteria are tested to map an entity\n        // to the \"anyone\" role.\n        {\n            \"grant\": \"request-proof\", \"thus\": \"anyone\",\n            \"duties\": [\"GDPR-edu-verif\", \"accept-kmk-tos\"]\n        },\n    ],\n    // Is there an authority that audits interactions?\n    \"audit\": {\n        // Where should reports be submitted via http POST?\n        \"uri\": \"http://kmk.org/audit\",\n        // How likely is it that a given interaction needs to\n        // be audited? Each party in the interaction picks a\n        // random number between 0 and 1, inclusive; if the number\n        // is &lt;= this number, then that party submits a report about it.\n        \"probability\": \"0.01\"\n    },\n    // Is there an authority to whom requests for redress can\n    // be made, if one party feels like another violates\n    // the governance framework? \n    \"redress\": {\n        \"uri\": \"http://kmk.org/redress\"\n    }\n}   \n</code></pre>"},{"location":"concepts/0440-kms-architectures/","title":"0440: KMS Architectures","text":"<ul> <li>Authors: Michael Lodder</li> <li>Status: PROPOSED</li> <li>Since: 2020-03-06</li> <li>Status Note: Proposed</li> <li>Supersedes: Wallets, uses ../../concepts from LOX</li> <li>Start Date: 2019-12-02</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0440-kms-architectures/#summary","title":"Summary","text":"<p>A Key Management Service (KMS) is designed to handle protecting sensitive agent information like keys, credentials, protocol state, and other data.  User authentication, access control policies, and cryptography are used in various combinations to mitigate various threat models and minimize risk. However, how to do this in practice is not intuitive and done incorrectly results in flawed or weak designs.  This RFC proposes best practices for designing a KMS that offers reasonable tradeoffs in flexibility for implementers with strong data security and privacy guarantees.</p>"},{"location":"concepts/0440-kms-architectures/#motivation","title":"Motivation","text":"<p>A KMS needs to be flexible to support various needs that arise when implementing agents. Mobile device needs are very different from an enterprise server environment, but ultimately the secrets still need to be protected in all environments. Some KMSs have already been implemented but fail to consider all the various threat models that exist within their designs. Some overlook good authentication schemes. Some misuse cryptography making the implementation insecure. A good KMS should provide the ability to configure alternative algorithms that are validated against specific standards like the Federal Information Processing Standards (FIPS). This RFC is meant to reduce the chances that an insecure implementation could be deployed while raising awareness of principles used in more secure designs.</p>"},{"location":"concepts/0440-kms-architectures/#tutorial","title":"Tutorial","text":"<p>A KMS can be broken into three main components with each component having potential subcategories. These components are designed to handle specific use cases and should be plug-and-play. The components are listed below and described in detail in the following sections:</p> <ol> <li>Enclave - <ul> <li>Safeguards cryptographic keys</li> <li>Key Generation<ul> <li>Encryption</li> <li>Digital Signatures</li> <li>Key exchange</li> <li>Proof generation and verification </li> </ul> </li> </ul> </li> <li>Persistence - <ul> <li>Stores non-key data<ul> <li>Verifiable credentials</li> <li>Protocol states</li> <li>DID documents</li> <li>Other metadata</li> </ul> </li> </ul> </li> <li>LOX - <ul> <li>Handle user authentication</li> <li>Access control enforcement</li> <li>Session/context establishment and management to the previous layers as described here.</li> </ul> </li> </ol>"},{"location":"concepts/0440-kms-architectures/#architecture","title":"Architecture","text":"<p>LOX sits between clients and the other subsystems. LOX asks the Enclave to do specific cryptographic operations and may pass the results to clients or Persistence or LOX may consume the results itself. The persistence layer does not directly interact with the enclave layer nor does the enclave layer interact directly with the persistence layer.</p> <p></p>"},{"location":"concepts/0440-kms-architectures/#lox","title":"LOX","text":"<p>LOX is the first layer KMS consumers will encounter and where the bulk of KMS work for implementers happens. LOX is divided into the following subcomponents that are not mutually exclusive:</p> <ol> <li>Authentication - Credentials for accessing the KMS and how to communicate with the KMS. Username/Passwords, PINS, Cryptographic keys, Verifiable credentials, Key fobs, key cards, and OpenID Connect are common methods for this layer. Any sensitive data handled by in this layer should be cleared from memory and minimize its footprint. </li> <li>Access control - Policies that indicate who can access the data and how data are handled. </li> <li>Audit - Logging about who does what and when and how verbose are the details </li> </ol> <p>Connecting to a KMS is usually done using functional system or library API calls, physical means like USB, or networks like Bluetooth, SSH, or HTTPS. These connections should be secured using encryption techniques like TLS or SSH or Signal other methods to prevent eavesdropping on  authentication credentials from end users. This is often the most vulnerable part of the system because its easy to  design something with weak security like passwords with only 6 characters and sent in plaintext.  It is preferred to use keys and multi-factor authentication techniques for connecting to LOX. Since password based sign ins are the most common, the following is a list of good methods for handling password based sign ins.</p>"},{"location":"concepts/0440-kms-architectures/#use-hashing-specially-designed-for-passwords","title":"Use hashing specially designed for passwords","text":"<p>Password based hashes are designed to be slow so the outputs are not so easily subjected to a brute-force dictionary attack. Simply hashing the password with cryptographic algorithms like Sha2/Sha3/Blake2 is not good enough. Below is a list of approved algorithms</p> <ol> <li>PBKDF2</li> <li>Bcrypt</li> <li>Scrypt</li> <li>Argon2</li> </ol> <p>The settings for using each of these should be enough to make even the strongest hardware take about 1-2 seconds to complete. The recommended settings in each section, also apply to mobile devices.</p> <p>PBKDF2</p> <p>Many applications use PBKDF2 which is NIST approved. However, PBKDF2 can use any SHA-family hash algorithm. Thus, it can be made weak if paired with SHA1 for example. When using PBKDF2, choose SHA2-512, which is significantly slower in current GPUs. The PBKDF2 parameters are</p> <ul> <li><code>N</code> - iterations count (the number of hashes to perform, \u2265100K recommended)</li> <li><code>password</code> - the input password</li> <li><code>salt</code> - securely-generated random bytes (128 bits recommended)</li> <li><code>hash</code> - The hash algorithm to use (SHA2-512 recommended)</li> </ul> <p>Bcrypt</p> <p>Bcrypt is a functional variant of the Blowfish cipher designed specially for password hashing. Unfortunately, the password sizes are limited to the first 72 bytes, any extra bytes are ignored. The recommended number of rounds  to use is \u226514. Bcrypt can support up to 31 rounds. Bcrypt is less resistant to ASIC and GPU attacks because it uses constant memory making it easier to build hardware-accelerated password crackers. When properly configured, Bcrypt is considered secure and is widely used in practice.</p> <ul> <li><code>N</code> - number of rounds (\u226514 recommended)</li> <li><code>password</code> - the input password</li> <li><code>salt</code> - securely-generated random bytes (128 bits recommended)</li> </ul> <p>Scrypt</p> <p>Scrypt is designed to make it costly to perform large-scale custom hardware attacks by requiring large amounts of memory. It is memory-intensive on purpose to prevent GPU, ASIC and FPGA attacks.  Scrypt offers multiple parameters:</p> <ul> <li><code>N</code> - iterations count (affects memory and CPU usage), e.g. 16384 or 2048</li> <li><code>r</code> - block size (affects memory and CPU usage), e.g. 8</li> <li><code>p</code> - parallelism factor (threads to run in parallel - affects the memory, CPU usage), usually 1</li> <li><code>password</code> - the input password</li> <li><code>salt</code> - securely-generated random bytes (128 bits recommended)</li> <li><code>derived-key-length</code> - how many bytes to generate as output, e.g. 32 bytes (256 bits)</li> </ul> <p>The memory in Scrypt is accessed in strongly dependent order at each step, so the memory access speed is the algorithm's bottleneck. The memory required is calculated as <code>128 * N * r * p</code> bytes. Example: 128*16384*8*1 = 16MB</p> <p>Choosing parameters depends on how much waiting is desired and what level of security (cracking resistance) should be achieved.</p> <p>MyEtherWallet uses N=8192, r=8, p=1. This is not considered strong enough for crypto wallets. Parameters of N=16384,r=8,p=1 (RAM = 2MB) typically take around 0.5 seconds, used for interactive sign ins. This doesn't hammer server side performance too much where many users can login at the same time. N=1048576,r=8,p=1 (RAM = 1GB) takes around 2-3 seconds. Scrypt is considered highly secure when properly configured.</p> <p>Argon2</p> <p>Argon2 is optimized for the x86 architecture and exploits the cache and memory layouts of modern Intel and AMD processors. It was the password hash competition winner and is recommended over PBKDF2, Bcrypt and Scrypt. Not recommended for ARM ABI's as performance tends to be much slower. This performance hit seem be desirable but what tends to happen is the parameters are configured lower for ARM environments to be reasonable but then can be cracked at 2-3 times faster when the hash is brute-forced on x86. Argon2 comes in three flavors: Argon2d, Argon2i and Argon2id and uses the  following parameters</p> <ul> <li>Argon2d - provides strong GPU resistance, but has potential side-channel attacks. Best if used on end-user machines where side channel attacks are less likely to happen.</li> <li>Argon2i - provides less GPU resistance, but has no side-channel attacks. Best if used for server-side sign ins.</li> <li> <p>Argon2id - combines both. Runs Argon2i first then Argon2d second, thus providing both side-channel attack protection and brute-force cost savings.</p> </li> <li> <p><code>password</code> - the input password</p> </li> <li><code>salt</code> - securely-generated random bytes (128 bits recommended)</li> <li><code>N</code> - number of iterations to perform</li> <li><code>m</code> - amount of memory to use in kilobytes</li> <li><code>p</code> - degree of parallelism (number of threads)</li> <li><code>derived-key-length</code> - how many bytes to generate as output, e.g. 32 bytes (256 bits)</li> </ul> <p>Parameters p=2,m=65536,n=128 typically take around 0.5 seconds, used for interactive sign ins. Moderate parameters are p=3,m=262144,n=192 typically take around 2-3 seconds, and sensitive parameters are p=4,m=1048576,n=256. Always time it in your environments.</p>"},{"location":"concepts/0440-kms-architectures/#session-establishment","title":"Session establishment","text":"<p>Upon authentication to LOX, LOX should establish connections to the enclave component and persistence component which should appear opaque to the client. LOX may need to authenticate to the enclave component or persistence component depending on where client access credentials are stored by implementors. Its preferable to store these in keychains or keystores if possible where the access is determined by the operating system and can include stronger mechanisms like TouchID or FaceID and hardware tokens in addition to passwords or pins. As described in LOX, the credentials for accessing the enclave and persistence layer can then be retrieved or generated if the client is new and stored in a secure manner. </p>"},{"location":"concepts/0440-kms-architectures/#using-os-keychain","title":"Using OS Keychain","text":""},{"location":"concepts/0440-kms-architectures/#using-password-based-key-derivation","title":"Using Password based key derivation","text":""},{"location":"concepts/0440-kms-architectures/#session-management","title":"Session management","text":"<p>Active connections to these other layers may possibly be pooled for efficiency reasons but care must be taken to avoid accidental permission grants. For example, Alice must not be able to use Bob's connection and Bob for Alice. However, the same database connection credentials might be used transparently for Alice and Bob, in which  case the database connection can be reused. This should be an exception as credential sharing is strongly discouraged. Auditing in the database might not be able to determine whether Alice or Bob performed a specific query.  Connections to enclaves and persistence usually requires session or context objects to be handled.  These must not be returned to clients, but rather maintained by LOX. When a client connection is closed, these must be securely deleted and/or closed.</p> <p></p>"},{"location":"concepts/0440-kms-architectures/#enclave","title":"Enclave","text":"<p>The enclave handles as many operations related to cryptography and key management as possible to ensure keys are adequately protected. Keys can potentially be stolen by means of side channel attacks from memory, disk, operational timing, voltage, heat, extraction, and others. Each enclave has been designed to consider certain threat models and mitigate these risks. For example, a Thales HSM is very different than a Yubico HSM or an Intel SGX Enclave. The correct mental model is to think about the formal guarantees that are needed and pick and choose/design the enclave layer to suite those needs. Build the system that meets the definition(s) of security then prove it meets the requirements. An enclave functions as a specialized cryptography component. The enclave provides APIs for passing in data to be operated on and executes its various cryptographic operations internally and only returns results to callers. The following is a list of operations that enclaves can support. The list will vary depending on the vendor.</p> <ol> <li>Generate asymmetric key</li> <li>Generate symmetric key</li> <li>Generate random</li> <li>Put key</li> <li>Delete key</li> <li>Wrap key</li> <li>Unwrap key</li> <li>Export wrapped key</li> <li>Import wrapped key</li> <li>List keys</li> <li>Update key metadata/capability</li> <li>Get key info/metadata</li> <li>Derive key agreement</li> <li>Sign</li> <li>Verify</li> <li>Encrypt</li> <li>Decrypt</li> <li>Get enclave info - metadata about the enclave like device info, version, manufacturer</li> <li>Query enclave capability</li> <li>Audit - e.g. enable/disable auditing</li> <li>Log - e.g. read audit logs</li> <li>Attestation - e.g. generate proofs about the enclave</li> </ol> <p>Most hardware implementations do not allow key material to be passed through the API, even in encrypted form, so a system of external references is required that allows keys to be referenced in a way that supports:</p> <ol> <li>Consistency - The same ID refers to the same key every time.</li> <li>Naming schemes - such as RSA_PSS_2048_8192_SHA256</li> </ol> <p>Some enclaves do support key material to be passed through the API. If allowed, these are called Key blocks. Key blocks are how a key is formatted when passed into or out of the enclave. See here.</p> <p>In keeping with the drive for enclaves to be simple and hard to mess up, the proposal is to make key IDs in the enclave storage be simple UTF-8 string names, and leave the underlying provider implementation to deal with the complexities of translation, key rollover, duplication and so on. Each of these operations uses different parameters and the enclave should specify what it allows and what it does not. If code needs to discover the capabilities on the fly, it is much more efficient to query the enclave if it supports it rather than return a list of capabilities that are search externally.</p> <p>Enclaves also store metadata with each key. This metadata consists of</p> <ol> <li>Attributes - e.g. key id, label, tag</li> <li>Access Constraints - e.g. require passcode or biometric auth to use</li> <li>Access Controls - e.g. can decrypt, can verify, can sign, exportable when wrapped</li> </ol>"},{"location":"concepts/0440-kms-architectures/#attributes","title":"Attributes","text":"<p>Attributes describe a key and do not enforce any particular permission about it. Such attributes typically include</p> <ol> <li>Identifier - e.g. f12f149d-e8d9-427c-85c7-f116f87f2e70 or 5a71028a74f1ad9f3f39 or 9s5m7EEJq1zZyc or 158</li> <li>Alias - e.g. fcb9ec81-d613-4c0f-a023-470155f38f92 or 1BC6HUi1soNML. Useful to sharing key but using a different id. Audits would show which one was used.</li> <li>Label or Description - e.g. Alice to Bob's DID key</li> <li>Class - e.g. public, private, symmetric</li> <li>Tag - e.g. sign, verify, did</li> <li>Type - e.g. aes, rsa, ecdsa, ed25519</li> <li>Size in bits - e.g. 256, 2048</li> <li>Creator - i.e. the original creator/owner</li> <li>Creation date</li> <li>Last modification date</li> <li>Always sensitive - i.e. was created with sensitive flag and never removed this control</li> <li>Never exported - i.e. never left the enclave</li> <li>Derived from - e.g. use PBKDF2 on this value to generate the key, or reference another key as a seed derived using HKDF</li> </ol> <p>Most of these attributes cannot change like Size in bits and are read-only. Aliases, Labels, and Tags are the only Attributes that can change. Enclaves allow 1 to many aliases and tags but only one label. The enclave should specify how many tags and aliases may be used. A common number is 5 for both.</p>"},{"location":"concepts/0440-kms-architectures/#access-constraints","title":"Access Constraints","text":"<p>Constraints restrict key access to be done under certain conditions like who is accessing the key like the owner(s) or group(s), password or biometric authentication, when host is unlocked like in mobile devices, always accessible. Constraints must be honored by the enclave to consumers to have confidence and trust. Possible constraints are:</p> <ol> <li>Owner(s) - e.g. who is allowed to access and use the key.</li> <li>User presence - e.g. require additional authentication like passcode or biometric auth (TouchID/FaceID). Authentication is on a per key basis vs just owner. Must be owner and meet additional authentication requirements.</li> <li>Biometric - e.g. require biometric authentication</li> <li>Passcode - e.g. require passcode authentication</li> <li>Fresh Interval - e.g. allowed time between additional authentications, 10 minutes is acceptable for extra sensitive keys</li> </ol> <p>Each of these can be mixed in combinations of AND and OR conjunctions. For example, key ABC might have the following constraints</p> <p>OR ( AND (Owner, User presence, Passcode), AND(Owner, User presence, Biometric) ) This requires the owner to enter an additional passcode OR biometric authentication to access the key.</p>"},{"location":"concepts/0440-kms-architectures/#access-controls","title":"Access Controls","text":"<p>Enclaves use access controls to restrict what operations keys are allowed to perform and who is allowed to use them. Controls are set during key generation and may or may not be permitted to change depending on the vendor or settings. Controls are stored with the key and enforced by the enclave. Possible access controls are:</p> <ol> <li>Can Key Agreement - e.g. Diffie-Hellman</li> <li>Can Derive - e.g. serve as seed to other keys</li> <li>Can Decrypt - e.g. can decrypt data for private keys and symmetric keys</li> <li>Can Encrypt - e.g. can encrypt data for public keys and symmetric keys</li> <li>Can Wrap - e.g. can be used to wrap another key to be exported</li> <li>Can Unwrap - e.g. can be used to unwrap a key that was exported</li> <li>Can Sign - e.g. can create digital signatures for private keys and MACs for symmetric keys</li> <li>Can Verify - e.g. can verify digital signatures for public keys and MACs for symmetric keys</li> <li>Can Attest - e.g. can be used to prove information about the enclave</li> <li>Is Exportable - e.g. can be exported from the enclave.</li> <li>Is Sensitive - e.g. can only be exported in an encrypted format.</li> <li>Is Synchronizable - e.g. can only be exported directly to another enclave</li> <li>Is Modifiable - e.g. can any controls be changed</li> <li>Is Visible - e.g. is the key available to clients outside the enclave or used internally.</li> <li>Valid Until Date - e.g. can use until this date, afterwards the key cannot be used</li> </ol> <p>To mitigate certain attacks like key material leaking in derive and encrypt functions, keys should be as limited as possible to one task (see here and here). For example, allowing concatenation of a base key to another key should be discouraged as it has the potential to perform key extraction attacks (see Clulow. Clulow shows that a key with decrypt and wrap capabilities can export a key then be used to decrypt it. This applies to both symmetric keys with decrypt and wrap and its variant where the wrapping key is a public key and the decryption key is the corresponding private key). The correct mental model to follow for enclave implementors is to model an intruder than can call any API command in any order he likes using any values that he knows. Sensitive and unexportable keys should never be directly readable and should not be changeable into nonsensitive and exportable. If a key can wrap, it should not be allowed to decrypt. Some of these controls should be considered sticky\u2013\u2013cannot be changed to mitigate these attacks like sensitive. This is useful when combined with conflicting controls like wrap and decrypt.</p> <p>Exporting key requirements</p> <p>The most secure model is to not allow keys to leave an enclave. However, in practice, this is not always reasonable. Backups, replications must be made, keys must be shared between two enclaves for data to be shared by two parties. When a key is lifted from the enclave, its attributes, constraints and controls must correctly bind with it. When a key lands in another enclave, the enclave must honor the attributes, constraints and controls with which it came. The wrapping format should be used to correctly bind key attributes, constraints and controls to the key. This prevents attacks where the key is wrapped and unwrapped twice with conflicting metadata as described by Delaune et. al, Cachin et.al, Cortier and Steel and Bortolozzo.</p>"},{"location":"concepts/0440-kms-architectures/#templates","title":"Templates","text":"<p>Some enclaves support creating templates such that keys can be generated and wrapped following secure guidelines in a reproducible way. Define separate templates for key generation and key wrapping.</p>"},{"location":"concepts/0440-kms-architectures/#final-enclave-notes","title":"Final enclave notes","text":"<p>Hardware enclaves typically have limited storage space like a few megabytes. A hardware enclave could be used to protect a software enclave that has a much higher storage capacity. A KMS is not limited to just one enclave. Cloud access security brokers (cloud enclaves) like Hashicorp Vault, Amazon\u2019s Cloud HSM, Iron Core Labs, Azure Key Vault, and Box Keysafe require trusting a SaaS vendor will store them in a place that is not vulnerable to data breaches. Even then, there is no assurance that the vendor, or one of their partners, won\u2019t access the secret material. This doesn't belittle their value, it's just another point to consider when using SaaS enclaves. Keys should be shared as little as possible if at all. Keys should be as short lived as possible and have a single purpose. This limits the need to replicate keys to other agents, either for dual functionality or recovery purposes, as well as damage in the event of a compromise.</p>"},{"location":"concepts/0440-kms-architectures/#persistence","title":"Persistence","text":"<p>This layer is meant to store other data in a KMS like credentials and protocol state. This layer could be optional for static agents where they store very little if anything. Credentials that access the persistence layer should stored in the enclave layer or with LOX in keychains. For example, if the persistence layer is a postgres database, the username/password or keypair to authenticate to the database could be stored in the enclave rather than a config file. Upon a successful authentication to LOX, these credentials are retrieved to connect to postgres and put into a connection pool. This is more secure than storing credentials in config files, environment variables or prompting them from user input.</p> <p>The most common storage mechanism is a SQL database. Designers should consider their system requirements in terms of performance, environments, user access control, system administrator access, then read Kamara\u2019s blog on how to develop encrypted databases (see 1, 2, 3, 4). For example, mobile environments vs enterprise environments. Mobile environments probably won\u2019t have a network adversary when using secure storage or an Honest-but-curious adversary where as enterprise environments will. Should the query engine be able to decrypt data prior to filtering or should it run on encrypted data and the querier performs decryption? Neither of these is considered wrong per se, but each comes with a set of trade offs. In the case of query engine decryption, there is no need to write a separate query mechanism and databases can execute as they normally do with a slight decrease in performance from decryption and encryption. However, the data reader must trust the query engine to not leak data or encryption keys. If the querier performs data encryption/decryption, no trust is given to the query engine but additional work must be performed before handing data to the engine and this searchable encryption is still vulnerable to access pattern leakage. What is practical engineering vs design vs theory? Theory is about what can and can\u2019t be done and why. Design is about using efficient primitives and protocols. Engineering is about effective and secure implementation.</p> <p>Implementers should consider the following threats and adversary sections.</p> <p>Threats * Memory access patterns leakage - Attackers can infer contents and/or importance of data based on how it is accessed and frequency of access. Attacker learns the set of matching records. * Volume leakage - Attacker learns the number of records/responses. * Search pattern leakage - Attackers can infer the contents and/or importance of data based on search patterns\u2013attacker can easily judge whether any two queries are generated from the same keywords or not. * Rank leakage - Attacker can infer or learn which data was queried * Side channel leakage - Attackers can access or learn the value of the secret material used to protect data confidentiality and integrity through side channels like memory inspection, RAM scraping attacks with swap access, and timing attacks [8]. * Microarchitectural attacks - Attacker is able to learn secrets through covert channels that target processors (Spectre/Meltdown)</p> <p>Adversary * Network adversary - observes traffic on the network. In addition to snooping and lurking, they can also perform fingerprinting attacks to learn who are the endpoints and correlate them to identical entities. * Snapshot adversary - breaks into server, snapshots system memory or storage. Sees copy of encrypted data but does not see transcripts related to any queries. Trade off between functionality and security. * Persistent adversary - corrupts server for a period of time, sees all communication transcripts. * Honest but curious adversary - System Administrator that can watch accesses to the data</p> <p>Disk Encryption This feature can help with encryption-at-rest requirements but only protects the data if the disk is off. Once booted, then an attacker can read it as easily as a system administrator and thus provides very little protection. Data can and usually is stolen via other methods like software vulnerabilities or virus\u2019. Useful if the storage hardware is not virtualized like in the cloud and is mobile like a laptop, phone, USB drives. If storage is in the cloud or network, it's worth more to invest in host-based intrusion prevention, intrusion detection systems, cloud, and file encryption  (see Sastry, Yegulalp, and Why Full Disk Encryption Isn't Enough).</p> <p>Application vs Database Encryption Databases provide varying levels of built-in encryption methods. SQL Server and SQLCipher are examples of databases that provide Transparent Data Encryption\u2013the users don\u2019t even know the data is encrypted, it\u2019s transparent to their knowledge. This works similar to Disk Encryption in that it mostly protects the database data at rest, but as soon as the user is connected, the data can be read in plaintext. A further abstraction is Postgres and SQL Server allowing database keys to be partially managed by the database to encrypt columns or cells and the user must supply either all or some of the keys and manage them separately. The last approach is for applications to manage all encryption. This has the advantage of being storage agnostic. Postgres permits the keys to be stored separately from the encrypted columns. When the data are queried, the key is passed to the query engine and the data are decrypted temporarily in memory to check the query.</p> <p>If the application is handling encryption, this means the query engine only operates on encrypted data vs allowing it decrypt and read the data directly. The tradeoff is a different query method/language will have to be used than provided by the persistence layer.</p> <p>Many databases are networked which requires another layer of protection like TLS or SSH.</p>"},{"location":"concepts/0440-kms-architectures/#data-storage","title":"Data storage","text":"<p>Metadata for data includes access controls and constraints. Controls dictate what can be done with the data, Constraints dictate who can access it. These could be managed by the underlying persistence application or it can be enforced by LOX before returning the data to the client. The constraints and controls indicate permissions to end clients and not necessarily to anything outside of the persistence layer. This is not like designing an enclave. Persistence is meant to be for more general purpose data that may or may not be sensitive. Metadata about the data includes attributes, constraints, and controls in a similar manner to the enclave.</p>"},{"location":"concepts/0440-kms-architectures/#access-constraints_1","title":"Access constraints","text":"<p>Constraints restrict data access to be done under certain conditions like who is accessing like the owner(s) or group(s). Constraints must be honored by the persistence layer or LOX to consumers to have confidence and trust. Possible constraints are:</p> <ol> <li>Identity or roles</li> <li>Context - i.e. what contexts can this data be used. For example, a credential may be restricted to be used only in a work environment if desired.</li> </ol>"},{"location":"concepts/0440-kms-architectures/#access-controls_1","title":"Access controls","text":"<ol> <li>Crypto Protection - e.g. which key id(s) and algorithm are used to protect this data. This allows data to re-encrypted, transformed via functional encryption in the future when keys are rotated or ciphers are deemed weak or insecure.</li> <li>Is Exportable - e.g. can the data leave the KMS</li> <li>Is Modifiable</li> <li>Can Delete</li> <li>Valid Until Date</li> </ol>"},{"location":"concepts/0440-kms-architectures/#reference","title":"Reference","text":"<p>Indy Wallet implements this in part and is one of the first attempts at this architecture. Indy Wallet doesn't use LOX yet, functions similar to an enclave in that it does not give direct access to private keys and uses key ids to execute operations. It supports a flexible persistence layer to be either SQLite or Postgres. The top layer encrypts data before it is queried or sent to the persistence layer and decrypted when returned. Aries Mayaguez is another implementation</p>"},{"location":"concepts/0440-kms-architectures/#drawbacks","title":"Drawbacks","text":"<p>There are additional complexities related to handling keys and other data as two distinct entities and it might be faster to combine them with a potential security tradeoff.</p>"},{"location":"concepts/0440-kms-architectures/#prior-art","title":"Prior art","text":"<p>PKCS#11 and  KMIP were developed for key management strictly for enclaves. These design patterns are not limited to just key management but any sensitive data.</p>"},{"location":"concepts/0440-kms-architectures/#unresolved-questions","title":"Unresolved questions","text":"<p>Is providing access constraints to the persistence layer necessary? Could this be removed? What are the consequences? Are there any missing constraints and controls for the enclave or persistence layer?</p>"},{"location":"concepts/0440-kms-architectures/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes</p> Name / Link Implementation Notes"},{"location":"concepts/0441-present-proof-best-practices/","title":"0441: Prover and Verifier Best Practices for Proof Presentation","text":"<ul> <li>Authors: Stephen Klump</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Interoperability guidance when using AnonCreds Present Proof. An element of the AnonCreds subtarget for AIP v2.0.</li> <li>Start Date: 2020-10-31</li> <li>Tags: concept, credentials</li> </ul>"},{"location":"concepts/0441-present-proof-best-practices/#summary","title":"Summary","text":"<p>This work prescribes best practices for provers in credential selection (toward proof presentation), for verifiers in proof acceptance, and for both regarding non-revocation interval semantics in fulfilment of the Present Proof protocol RFC0037. Of particular instance is behaviour against presentation requests and presentations in their various non-revocation interval profiles.</p>"},{"location":"concepts/0441-present-proof-best-practices/#motivation","title":"Motivation","text":"<p>Agents should behave consistently in automatically selecting credentials and proving presentations.</p>"},{"location":"concepts/0441-present-proof-best-practices/#tutorial","title":"Tutorial","text":"<p>The subsections below introduce constructs and outline best practices for provers and verifiers.</p>"},{"location":"concepts/0441-present-proof-best-practices/#presentation-requests-and-non-revocation-intervals","title":"Presentation Requests and Non-Revocation Intervals","text":"<p>This section prescribes norms and best practices in formulating and interpreting non-revocation intervals on proof requests.</p>"},{"location":"concepts/0441-present-proof-best-practices/#semantics-of-non-revocation-interval-presence-and-absence","title":"Semantics of Non-Revocation Interval Presence and Absence","text":"<p>The presence of a non-revocation interval applicable to a requested item (see below) in a presentation request signifies that the verifier requires proof of non-revocation status of the credential providing that item.</p> <p>The absence of any non-revocation interval applicable to a requested item signifies that the verifier has no interest in its credential's non-revocation status.</p> <p>A revocable or non-revocable credential may satisfy a presentation request with or without a non-revocation interval. The presence of a non-revocation interval conveys that if the prover presents a revocable credential, the presentation must include proof of non-revocation. Its presence does not convey any restriction on the revocability of the credential to present: in many cases the verifier cannot know whether a prover's credential is revocable or not.</p>"},{"location":"concepts/0441-present-proof-best-practices/#non-revocation-interval-applicability-to-requested-items","title":"Non-Revocation Interval Applicability to Requested Items","text":"<p>A requested item in a presentation request is an attribute or a predicate, proof of which the verifier requests presentation. A non-revocation interval within a presentation request is specifically applicable, generally applicable, or inapplicable to a requested item.</p> <p>Within a presentation request, a top-level non-revocation interval is generally  applicable to all requested items. A non-revocation interval defined particularly for  a requested item is specifically applicable to that requested attribute or predicate but inapplicable to all others.</p> <p>A non-revocation interval specifically applicable to a requested item overrides any generally applicable non-revocation interval: no requested item may have both.</p> <p>For example, in the following (indy) proof request</p> <pre><code>{\n    \"name\": \"proof-request\",\n    \"version\": \"1.0\",\n    \"nonce\": \"1234567890\",\n    \"requested_attributes\": {\n        \"legalname\": {\n            \"name\": \"legalName\",\n            \"restrictions\": [\n                {\n                    \"issuer_did\": \"WgWxqztrNooG92RXvxSTWv\"\n                }\n            ]\n        },\n        \"regdate\": {\n            \"name\": \"regDate\",\n            \"restrictions\": [\n                {\n                    \"issuer_did\": \"WgWxqztrNooG92RXvxSTWv\"\n                }\n            ],\n            \"non_revoked\": {\n                \"from\": 1600001000,\n                \"to\": 1600001000\n            }\n        }\n    },\n    \"requested_predicates\": {\n    },\n    \"non_revoked\": {\n        \"from\": 1600000000,\n        \"to\": 1600000000\n    }\n}\n</code></pre> <p>the non-revocation interval on 1600000000 is generally applicable to the referent <code>\"legalname\"</code> while the non-revocation interval on 1600001000 specifically applicable to referent <code>\"regdate\"</code>.</p>"},{"location":"concepts/0441-present-proof-best-practices/#semantics-of-non-revocation-interval-endpoints","title":"Semantics of Non-Revocation Interval Endpoints","text":"<p>A non-revocation interval contains <code>\"from\"</code> and <code>\"to\"</code> (integer) EPOCH times. For historical reasons, any timestamp within this interval is technically acceptable in a non-revocation subproof. However, these semantics allow for ambiguity in cases where revocation occurs within the interval, and in cases where the ledger supports reinstatement. These best practices require the <code>\"from\"</code> value, should the prover specify it, to equal the <code>\"to\"</code> value: this approach fosters deterministic outcomes.</p> <p>A missing <code>\"from\"</code> specification defaults to the same value as the interval's <code>\"to\"</code> value. In other words, the non-revocation intervals</p> <pre><code>{\n    \"to\": 1234567890\n}\n</code></pre> <p>and</p> <pre><code>{\n    \"from\": 1234567890,\n    \"to\": 1234567890\n}\n</code></pre> <p>are semantically equivalent.</p>"},{"location":"concepts/0441-present-proof-best-practices/#verifier-non-revocation-interval-formulation","title":"Verifier Non-Revocation Interval Formulation","text":"<p>The verifier MUST specify, as current INDY-HIPE 11 notes, the same integer EPOCH time for both ends of the interval, or else omit the <code>\"from\"</code> key and value. In effect, where the presentation request specifies a non-revocation interval, the verifier MUST request a non-revocation instant.</p>"},{"location":"concepts/0441-present-proof-best-practices/#prover-non-revocation-interval-processing","title":"Prover Non-Revocation Interval Processing","text":"<p>In querying the nodes for revocation status, given a revocation interval on a single instant (i.e., on <code>\"from\"</code> and <code>\"to\"</code> the same, or <code>\"from\"</code> absent), the prover MUST query the ledger for all germane revocation updates from registry creation through that instant (i.e., from zero through <code>\"to\"</code> value): if the credential has been revoked prior to the instant, the revocation necessarily will appear in the aggregate delta.</p>"},{"location":"concepts/0441-present-proof-best-practices/#provers-presentation-proposals-and-presentation-requests","title":"Provers, Presentation Proposals, and Presentation Requests","text":"<p>In fulfilment of the RFC0037 Present Proof protocol, provers may initiate with a presentation proposal or verifiers may initiate with a presentation request. In the former case, the prover has both a presentation proposal and a presentation request; in the latter case, the prover has only a presentation request.</p>"},{"location":"concepts/0441-present-proof-best-practices/#credential-selection-best-practices","title":"Credential Selection Best Practices","text":"<p>This section specifies a prover's best practices in matching a credential to a requested item. The specification pertains to automated credential selection: obviously, a human user may select any credential in response to a presentation request; it is up to the verifier to verify the resulting presentation as satisfactory or not.</p> <p>Note that where a prover selects a revocable credential for inclusion in response to a requested item with a non-revocation interval in the presentation request, the prover MUST create a corresponding sub-proof of non-revocation at a timestamp within that non-revocation interval (insofar as possible; see below).</p>"},{"location":"concepts/0441-present-proof-best-practices/#with-presentation-proposal","title":"With Presentation Proposal","text":"<p>If prover initiated the protocol with a presentation proposal specifying a value (or predicate threshold) for an attribute, and the presentation request does not require a different value for it, then the prover MUST select a credential matching the presentation proposal, in addition to following the best practices below regarding the presentation request.</p>"},{"location":"concepts/0441-present-proof-best-practices/#preference-for-irrevocable-credentials","title":"Preference for Irrevocable Credentials","text":"<p>In keeping with the specification above, presentation of an irrevocable credential ipso facto constitutes proof of non-revocation. Provers MUST always prefer irrevocable credentials to revocable credentials, when the wallet has both satisfying a requested item, whether the requested item has an applicable non-revocation interval or not. Note that if a non-revocation interval is applicable to a credential's requested item in the presentation request, selecting an irrevocable credential for presentation may lead to a missing timestamp at the verifier (see below).</p> <p>If only revocable credentials are available to satisfy a requested item with no applicable non-revocation interval, the prover MUST present such for proof. As per above, the absence of a non-revocation interval signifies that the verifier has no interest in its revocation status.</p>"},{"location":"concepts/0441-present-proof-best-practices/#verifiers-presentations-and-timestamps","title":"Verifiers, Presentations, and Timestamps","text":"<p>This section prescribes verifier best practices concerning a received presentation by its timestamps against the corresponding presentation request's non-revocation intervals.</p>"},{"location":"concepts/0441-present-proof-best-practices/#timestamp-for-irrevocable-credential","title":"Timestamp for Irrevocable Credential","text":"<p>A presentation's inclusion of a timestamp pertaining to an irrevocable credential evinces tampering: the verifier MUST reject such a presentation.</p>"},{"location":"concepts/0441-present-proof-best-practices/#missing-timestamp","title":"Missing Timestamp","text":"<p>A presentation with no timestamp for a revocable credential purporting to satisfy a requested item in the corresponding presentation request, where the requested item has an applicable non-revocation interval, evinces tampering: the verifier MUST reject such a presentation.</p> <p>It is licit for a presentation to have no timestamp for an irrevocable credential: the applicable non-revocation interval is superfluous in the presentation request.</p>"},{"location":"concepts/0441-present-proof-best-practices/#timestamp-outside-non-revocation-interval","title":"Timestamp Outside Non-Revocation Interval","text":"<p>A presentation may include a timestamp outside of a the non-revocation interval applicable to the requested item that a presented credential purports to satisfy. If the latest timestamp from the ledger for a presented credential's revocation registry predates the non-revocation interval, but the timestamp is not in the future (relative to the instant of presentation proof, with a reasonable allowance for clock skew), the verifier MUST log and continue the proof verification process.</p> <p>Any timestamp in the future (relative to the instant of presentation proof, with a reasonable allowance for clock skew) evinces tampering: the verifier MUST reject a presentation with a future timestamp. Similarly, any timestamp predating the creation of its corresponding credential's revocation registry on the ledger evinces tampering: the verifier MUST reject a presentation with such a timestamp.</p>"},{"location":"concepts/0441-present-proof-best-practices/#dates-and-predicates","title":"Dates and Predicates","text":"<p>This section prescribes issuer and verifier best practices concerning representing dates for use in predicate proofs (eg proving Alice is over 21 without revealing her birth date).</p>"},{"location":"concepts/0441-present-proof-best-practices/#dates-in-credentials","title":"Dates in Credentials","text":"<p>In order for dates to be used in a predicate proof they MUST be expressed as an Int32. While unix timestamps could work for this, it has several drawbacks including: can't represent dates outside of the years 1901-2038, isn't human readable, and is overly precise in that birth time down to the second is generally not needed for an age check. To address these issues, date attributes SHOULD be represented as integers in the form YYYYMMDD (eg 19991231). This addresses the issues with unix timestamps (or any seconds-since-epoch system) while still allowing date values to be compared with &lt; &gt; operators. Note that this system won't work for any general date math (eg adding or subtracting days), but it will work for predicate proofs which just require comparisons. In order to make it clear that this format is being used, the attribute name SHOULD have the suffix <code>_dateint</code>. Since most datetime libraries don't include this format, here are some examples of helper functions written in typescript.</p>"},{"location":"concepts/0441-present-proof-best-practices/#dates-in-presentations","title":"Dates in Presentations","text":"<p>When constructing a proof request, the verifier SHOULD express the minimum/maximum date as an integer in the form YYYYMMDD. For example if today is Jan 1, 2021 then the verifier would request that <code>bithdate_dateint</code> is before or equal to Jan 1 2000 so <code>&lt;= 20000101</code>. The holder MUST construct a predicate proof with a YYYYMMDD represented birth date less than that value to satisfy the proof request.</p>"},{"location":"concepts/0441-present-proof-best-practices/#reference","title":"Reference","text":"<ul> <li>RFC 0037: Present Proof protocol</li> <li>INDY-HIPE 11: Indy revocation.</li> </ul>"},{"location":"concepts/0441-present-proof-best-practices/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0478-coprotocols/","title":"Aries RFC 0478: Coprotocols","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No recent progress and no implementations have been created.</li> <li>Start Date: 2020-02-03</li> <li>Tags: concept, protocol</li> </ul>"},{"location":"concepts/0478-coprotocols/#summary","title":"Summary","text":"<p>Explains how one protocol can invoke and interact with others, giving inputs and receiving outputs and errors.</p>"},{"location":"concepts/0478-coprotocols/#motivation","title":"Motivation","text":"<p>It's common for complex business workflows to be composed from smaller, configurable units of logic. It's also common for multiple processes to unfold in interrelated ways, such that a complex goal is choreagraphed from semi-independent tasks. Enabling flexible constructions like this is one of the major goals of protocols built atop DIDComm. We need a standard methodology for doing so.</p>"},{"location":"concepts/0478-coprotocols/#tutorial","title":"Tutorial","text":"<p>A protocol is any recipe for a stateful interaction. DIDComm itself is a protocol, as are many primitives atop which it is built, such as HTTP, Diffie-Hellman key exchange, and so forth. However, when we talk about protocols in decentralized identity, without any qualifiers, we usually mean application-level interactions like credential issuance, feature discovery, third-party introductions, and so forth. These protocols are message-based interactions that use DIDComm.</p> <p>We want these protocols to be composable. In the middle of issuing credentials, we may want to challenge the potential holder for proof -- and in the middle of challenging for proof, maybe we want to negotiate payment. We could build proving into issuing, and payment into proving, but this runs counter to the DRY principle and to general best practice in encapsulation. A good developer writing a script to issue credentials would probably isolate payment and proving logic in separate functions or libraries, and would strive for loose coupling so each could evolve independently.</p> <p>Agents that run protocols have goals like those of the script developer. How we achieve them is the subject of this RFC.</p>"},{"location":"concepts/0478-coprotocols/#subroutines","title":"Subroutines","text":"<p>In the world of computer science, a subroutine is a vital abstraction for complex flows. It breaks logic into small, reusable chunks that are easy for a human to understand and document, and it formalizes their interfaces. Code calls a subroutine by referencing it via name or address, providing specified arguments as input. The subroutine computes on this input, eventually producing an output; the details don't interest the caller. While the subroutine is busy, the caller typically waits. Callers can often avoid recompilation when details inside subroutines change. Subroutines can come from pluggable libraries. These can be written by different programmers in different programming languages, as long as a calling convention is shared.</p> <p>Thinking of protocols as analogs to subroutines suggests some interesting questions:  </p> <ul> <li>How do we invoke one protocol from another?</li> <li>How does a protocol emit an output?</li> <li>What is the calling convention?</li> <li>How do errors propagate (or exceptions get thrown and handled)?</li> <li>How can we make protocols work like higher-order functions (functions that take other functions as parameters)?</li> </ul>"},{"location":"concepts/0478-coprotocols/#coroutines","title":"Coroutines","text":"<p>Before we answer these questions, let's think about a generalization of subroutines that's slightly less familiar to some programmers: coroutines. Coroutines achieve the same encapsulation and reusability as subroutines, but as a category they are more flexible and powerful. Coroutines may be, but aren't required to be, call-stack \"children\" of their callers; they may have complex lifecycles that begin or end outside the caller's lifespan. Coroutines may receive inputs at multiple points, not just at launch. They may yield outputs at multiple points, too. Subroutines are just the simplest variant of coroutines.</p> <p>The flexiblity of coroutines gives options to programmers, and it explains why most programming languages evolve to offer them as first-class constructs when they encounter demanding requirements for asynchronicity, performance, or scale. For example, early versions of python lacked the concept of coroutines; if you wrote a loop over <code>range(1, 1000000)</code>, python allocated and filled a container holding 1 million numbers, and then iterated over the container. When generators (a type of coroutine) were added to the language, the underlying logic changed. Now <code>range(1, 1000000)</code> is a coroutine invocation that trades execution state back and forth with its sibling caller routine. The first time it is invoked, it receives and stores its input values, then produces one output (the lower bound of the range). Each subsequent time through the loop it is invoked again; it increments its internal state and yields a new output back to the caller. No allocations occur, and an early break from the loop wastes nothing.</p> <p>If we want to choose one conceptual parallel for how protocols relate to one another, we should think of them as coroutines, not subroutines; doing so constrains us less. Although payment as a subroutine inside credential issuance sounds plausible at first glance, it turns out to be clumsy under deeper analysis. A payment protocol yields more than one output -- typically a preauthorization at an intermediate stage, then a final outcome when it completes. At the preauthorization stage, it should accept graceful cancellation (a second input, after launch). And high-speed, bulk issuance of credentials is likely to benefit from payment and issuance being partly parallelized instead of purely sequential.</p> <p></p> <p>Similarly, a handshake protocol like DID Exchange or Connection is best framed as a coprotocol of Introduce; this makes it easy for Introduce to complete as soon as the handshake begins, instead of waiting for the handshake to finish as if it were a subroutine.</p> <p>By thinking of cross-protocol interactions like coroutine interactions, we get the best of both worlds: where the interaction is just subroutine-like, the model lets us simplify; where we need more flexibility and power, the model still fits.</p> <p>Protocols don't have to support the types of coprotocol interactions we're describing here; protocols developed by Aries developers have already proven their value even without it. But to unlock their full potential, adding coprotocol support to new and existing protocol definitions may be worthwhile. This requires only a modest update to a protocol RFC, and creates little extra work for implementers.</p>"},{"location":"concepts/0478-coprotocols/#the-simple-approach-that-falls-apart","title":"The simple approach that falls apart","text":"<p>When the DIDComm community first began thinking about one protocol invoking another, we imagined that the interface to the called coprotocol would simply be its first message. For example, if verfiable credential issuer Acme Corp wanted to demand payment for a credential during an issuance protocol with Bob, Acme would send to Bob a <code>request_payment</code> message that constituted the first message in a <code>make_payment</code> protocol. This would create an instance of the payment protocol running alongside issuance; issuance could then wait until it completed before proceeding. And Bob wouldn't need to lift a finger to make it work, if he already supported the payment protocol.</p> <p>Unfortunately, this approach looks less attractive after study: </p> <ul> <li> <p>It creates a tight coupling between issuance and payment. The logic inside issuance must know exactly what data format, semantics, and versioning rules apply to the payment protocol, in order to generate its first message. If the payment protocol changes, the issuance protocol breaks. There is no flexibility in issuance to negotiate an optimal payment protocol from among several alternatives that both parties support. The implementation of issuance is too opinionated about how to approach a logically independent task.</p> </li> <li> <p>It doesn't give Bob any context. We don't want to inconvenience Bob to support payment in conjunction with issuance, but we DO want Bob to know that the payment protocol instance he participates in is related to the credential issuance protocol that's also underway. This is more than just connecting the two with DIDComm's message threading; if one protocol is abandoned or completes or fails, something probably needs to happen in the other.</p> </li> <li> <p>It doesn't let Bob be the first mover. What if Bob should be requesting payment instead of Acme? (The Protocol Role Request Protocol partly addresses this need, but lacks a formal way to give Bob data as input.)  </p> </li> <li> <p>It doesn't explain how the payment protocol emits output that its caller can consume. Individual agents could code proprietary answers to this question, but interoperability would be lost.</p> </li> <li> <p>It doesn't offer a signalling mechanism that would let the two protocols proceed in parallel, syncing up only when necessary.</p> </li> <li> <p>It doesn't explain how errors propagate, or how to decide what they mean for the calling protocol.</p> </li> </ul>"},{"location":"concepts/0478-coprotocols/#general-interface-needs","title":"General Interface Needs","text":"<p>What we want, instead, is a formal declaration of something a bit like a coprotocol's \"function signature.\" It needs to describe the inputs that launch the protocol, and the outputs and/or errors emitted as it finishes. It should hide implementation details and remain stable across irrelevant internal changes. </p> <p>We need to bind compatible coprotocols to one another using the metadata in these declarations. And since coprotocol discovery may have to satisfy a remote party, not just a local one, our binding needs to work well dynamically, and late, and with optional, possibly overlapping plugins providing implementations. This suggests that our declarations must be rich and flexible about binding criteria \u2014 it must be possible to match on something more than just a coprotocol name and/or arg count+type.</p> <p>An interesting divergence from the function signature parallel is that we may have to describe inputs and outputs (and errors) at multiple interaction points, not just the coprotocol's initial invocation. </p> <p>Another subtlety is that protocol interfaces need to be partitioned by role; the experience of a payer and a payee with respect to a payment protocol may be quite different. The interface offered by a coprotocol must vary by which role the invoked coprotocol instance embodies.</p> <p>Given all these considerations, we choose to describe coprotocol interfaces using a set of function-like signatures, not just one. We use a function-like notation to make them as terse and intuitive as possible for developers.</p>"},{"location":"concepts/0478-coprotocols/#example","title":"Example","text":"<p>Suppose we are writing a credential issuance protocol, and we want to use coprotocols to add support for situations where the issuer expects payment partway through the overall flow. We'd like it to be possible for our payment step to use Venmo/Zelle, or cryptocurrency, or traditional credit cards, or anything else that issuers and holders agree upon. So we want to encapsulate the payment problem as a pluggable, discoverable, negotiable coprotocol.</p> <p>We do a little research and discover that many DIDComm-based payment protocols exist. Three of them advertise support for the same coprotocol interface:</p> <pre><code>goal: aries.buy.make-payment\npayee:\n  get:\n      - invoke(amount: float, currency: str, bill_of_sale: str) @ null\n      - proceed(continue: bool) @ requested:, waiting-for-commit\n  give:\n      - preauth(code: str) @ waiting-for-commit\n      - return(confirmation_code: str) @ finalizing\n</code></pre> <p>In plain English, the declared coprotocol semantics are:</p> <p>This is a coprotocol interface for protocols that facilitate the <code>aries.buy.make-payment</code> goal code. The <code>payee</code> role in this coprotocol gets input at two interaction points, \"invoke\" and \"proceed\". Invoke happens when state is null (at launch); \"proceed\" happens when state is \"requested\" or \"waiting-for-commit.\" At invoke, the caller of the co-protocol provides 3 inputs: an amount, a currency, and a bill of sale. At proceed, the caller decides whether to continue. Implementations of this coprotocol interface also give output at two interaction points, \"preauth\" and \"return.\" At preauth, the output is a string that's a preauth code; at return, the output is a confirmation code.</p>"},{"location":"concepts/0478-coprotocols/#simplified-description-only","title":"Simplified description only","text":"<p>It's important to understand that this interface is NOT the same as the protocol's direct interface (the message family and state machine that a protocol impl must provide to implement the protocol as documented). It is, instead, a simplified encapuslation -- just like a function signature is a simplified encapsulation of a coroutine. A function impl can rename its args for internal use. It can have steps that the caller doesn't know about. The same is true for protocols: their role names, state names, message types and versions, and field names in messages don't need to be exposed directly in a coprotocol interface; they just need a mapping that the protocol understands internally. The specific payment protocol implementation might look like this (don't worry about details; the point is just that some might exist):</p> <p></p> <p>When we describe this as a coprotocol, we omit most of its details, and we change some verbiage. The existence of the <code>payee</code>, <code>gateway</code> and <code>blockchain</code> roles is suppressed (though we now have an implicit new role -- the caller of the coprotocol that gives what the protocol gets, and gets what the protocol gives). Smart contracts disappear. The concept of <code>handle to pending txn</code> is mapped to the coprotocol's <code>preauth</code> construct, and <code>txn hash</code> is mapped to the coprotocol's <code>confirmation_code</code>. As a coprotocol, the payee can interact according to a far simpler understanding, where the caller asks the payee to engage in a payment protocol, expose some simple hooks, and notify on completion:</p> <p></p>"},{"location":"concepts/0478-coprotocols/#calling-convention","title":"Calling Convention","text":"<p>More details are needed to understand exactly how the caller and the coprotocol communicate. There are two sources of such details:</p> <ol> <li>Proprietary methods</li> <li>Standard Aries-style DIDComm protocol</li> </ol> <p>Proprietary methods allow aggressive optimization. They may be appropriate when it's known that the caller and the coprotocol will share the same process space on a single device, and the code for both will come from a single codebase. In such cases, there is no need to use DIDComm to communicate.</p> <p>Answer 2 may be more chatty, but is better when the coprotocol might be invoked remotely (e.g., Acme's server A is in the middle of issuance and wants to invoke payment to run on server B), or where the codebases for each party to the interaction need some independence.</p> <p>The expectation is that co-protocols share a compatible trust domain; that is, coprotocol interactions occur within the scope of one identity rather than across identity boundaries. Thus, interoperability is not a strong requirement. Nonetheless, approaching this question as a standard protocol problem leads to a clean, loosely couple architecture with little incremental cost in an agent. Therefore, a protocol for coprotocol coordination has been developed. This is the subject of sister document Aries RFC 0482: Coprotocol Protocol.</p>"},{"location":"concepts/0478-coprotocols/#reference","title":"Reference","text":"<p>More about optional fields and syntax in a coprotocol declaration.</p> <p>How to add a coprotocol decl to a protocol.</p>"},{"location":"concepts/0478-coprotocols/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"concepts/0478-coprotocols/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"concepts/0478-coprotocols/#prior-art","title":"Prior art","text":"<p>Coroutines \u2014 the computer science scaffolding against which coprotocols are modeled \u2014 are extensively discussed in the literature of various compiler developer communities. The discussion about adding support for this feature in Rust is particularly good background reading: https://users.rust-lang.org/t/coroutines-and-rust/9058</p>"},{"location":"concepts/0478-coprotocols/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"concepts/0478-coprotocols/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0519-goal-codes/","title":"0519: Goal Codes","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Used in several protocols that are part of AIP 2.0, such as the Out-of-Band protocol.</li> <li>Start Date: 2020-01-01</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0519-goal-codes/#summary","title":"Summary","text":"<p>Explain how different parties in an SSI ecosystem can communicate about their intentions in a way that is understandable by humans and by automated software.</p>"},{"location":"concepts/0519-goal-codes/#motivation","title":"Motivation","text":"<p>Agents exist to achieve the intents of their owners. Those intents largely unfold through protocols. Sometimes intelligent action in these protocols depends on a party declaring their intent. We need a standard way to do that.</p>"},{"location":"concepts/0519-goal-codes/#tutorial","title":"Tutorial","text":"<p>Our early learnings in SSI focused on VC-based proving with a very loose, casual approach to context. We did demos where Alice connects with a potential employer, Acme Corp -- and we assumed that each of the interacting parties had a shared understanding of one another's needs and purposes.</p> <p>But in a mature SSI ecosystem, where unknown agents can contact one another for arbitrary reasons, this context is not always easy to deduce. Acme Corp's agent may support many different protocols, and Alice may interact with Acme in the capacity of customer or potential employee or vendor. Although we have feature discovery to learn what's possible, and we have machine-readable governance frameworks to tell us what rules might apply in a given context, we haven't had a way to establish the context in the first place. When Alice contacts Acme, a context is needed before a governance framework is selectable, and before we know which ../../features are desirable.</p> <p>The key ingredient in context is intent. If Alice says to Acme, \"I'd like to connect,\", Acme wants to be able to trigger different behavior depending on whether Alice's intent is to be a customer, apply for a job, or audit Acme's taxes. This is the purpose of a goal code.</p>"},{"location":"concepts/0519-goal-codes/#the-goal-code-datatype","title":"The goal code datatype","text":"<p>To express intent, this RFC formally introduces the goal code datatype. When a field in a DIDComm message contains a goal code, its semantics and format match the description given here. (Goal codes are often declared via the <code>~thread</code> decorator, but may also appear in ordinary message fields. See the Scope section below. Convention is to name this field \"goal_code\" where possible; however, this is only a convention, and individual protocols may adapt to it however they wish.)</p> <p>TODO: should we make a decorator out of this, so protocols don't have to declare it, and so any message can have a goal code? Or should we just let protocols declare a field in whatever message makes sense?</p> <p>Protocols use fields of this type as a way to express the intent of the message sender, thus coloring the larger context. In a sense, goal codes are to DIDComm what the <code>subject:</code> field is to email -- except that goal codes have formalized meanings to make them recognizable to automation.</p> <p>Goal codes use a standard format. They are lower-cased, kebab-punctuated strings. ASCII and English are recommended, as they are intended to be read by the software developer community, not by human beings; however, full UTF-8 is allowed. They support hierarchical dotted notation, where more general categories are to the left of a dot, and more specific categories are to the right. Some example goal codes might be:</p> <ul> <li><code>aries.sell.consumer.fitness</code></li> <li><code>meetupcorp.personal.date</code></li> <li><code>dif.employment.check-references</code></li> <li><code>cci.healthcare.arrange</code></li> </ul> <p>Goals are inherently self-attested. Thus, goal codes don't represent objective fact that a recipient can rely upon in a strong sense; subsequent interactions can always yield surprises. Even so, goal codes let agents triage interactions and find misalignments early; there's no point in engaging if their goals are incompatible. This has significant benefits for spam prevention, among other things.</p>"},{"location":"concepts/0519-goal-codes/#verbs","title":"Verbs","text":"<p>Notice the verbs in the examples: <code>sell</code>, <code>date</code>, <code>hire</code>, and <code>arrange</code>. Goals typically involve action; a complete goal code should have one or more verbs in it somewhere. Turning verbs into nouns (e.g., <code>employment.references</code> instead of <code>employment.check-references</code>) is considered bad form. (Some namespaces may put the verbs at the end; some may put them in the middle. That's a purely stylistic choice.)</p>"},{"location":"concepts/0519-goal-codes/#directionality","title":"Directionality","text":"<p>Notice, too, that the verbs may imply directionality. A goal with the <code>sell</code> verb implies that the person announcing the goal is a would-be seller, not a buyer. We could imagine a more general verb like <code>engage-in-commerce</code> that would allow either behavior. However, that would often be a mistake. The value of goal codes is that they let agents align around intent; announcing that you want to engage in general commerce without clarifying whether you intend to sell or buy may be too vague to help the other party make decisions. </p> <p>It is conceivable that this would lead to parallel branchs of a goal ontology that differ only in the direction of their verb. Thus, we could imagine <code>sell.A</code> and <code>sell.B</code> being shadowed by <code>buy.A</code> and <code>buy.B</code>. This might be necessary if a family of protocols allow either party to initiate an interaction and declare the goal, and if both parties view the goals as perfect mirror images. However, practical considerations may make this kind of parallelism unlikely. A random party contacting an individual to sell something may need to be quite clear about the type of selling they intend, to make it past a spam filter. In contrast, a random individual arriving at the digital storefront of a mega retailer may be quite vague about the type of buying they intend. Thus, the <code>buy.*</code> side of the namespace may need much less detail than the <code>sell.*</code> side.</p>"},{"location":"concepts/0519-goal-codes/#goals-for-others","title":"Goals for others","text":"<p>Related to directionality, it may occasionally be desirable to propose goals to others, rather than adovcating your own: \"Let &lt;parties = us = Alice, Bob, and Carol&gt; &lt;goal = hold an auction&gt; -- I nominate Carol to be the &lt;role = auctioneer&gt; and get us started.\" The difference between a normal message and an unusual one like this is not visible in the goal code; it should be exposed in additional fields that associate the goal with a particular identifier+role pair. Essentially, you are proposing a goal to another party, and these extra fields clarify who should receive the proposal, and what role/perspective they might take with respect to the goal.</p> <p>Making proposals like this may be a feature in some protocols. Where it is, the protocols determine the message field names for the goal code, the role, and the DID associated with the role and goal.</p>"},{"location":"concepts/0519-goal-codes/#matching","title":"Matching","text":"<p>The goal code <code>cci.healthcare</code> is considered a more general form of the code <code>cci.healthcare.procedure</code>, which is more general than <code>cci.healthcare.procedure.schedule</code>. Because these codes are hierarchical, wildcards and fuzzy matching are possible for either a sender or a recipient of a message. Filename-style globbing semantics are used.</p> <p>A sender agent can specify that their owner's goal is just <code>meetupcorp.personal</code> without clarifying more; this is like specifying that a file is located under a folder named \"meetupcorp/personal\" without specifying where; any file \"under\" that folder -- or the folder itself -- would match the pattern. A recipient agent can have a policy that says, \"Reject any attempts to connect if the goal code of the other party is <code>aries.sell.*</code>. Notice how this differs from <code>aries.sell*</code>; the first looks for things \"inside\" <code>aries.sell</code>; the latter looks for things \"inside\" <code>aries</code> that have names beginning with <code>sell</code>.</p>"},{"location":"concepts/0519-goal-codes/#scope","title":"Scope","text":"<p>When is a declared goal known to color interactions, and when is it undefined? </p> <p>We previously noted that goal codes are a bit like the <code>subject:</code> header on an email; they contextualize everything that follows in that thread. We don't generally want to declare a goal outside of a thread context, because that would prevent an agent from engaging in two goals at the same time.</p> <p>Given these two observations, we can say that a goal applies as soon as it is declared, and it continues to apply to all messages in the same thread. It is also inherited by implication through a thread's <code>pthid</code> field; that is, a parent thread's goal colors the child thread unless/until overridden.</p>"},{"location":"concepts/0519-goal-codes/#namespacing","title":"Namespacing","text":"<p>To avoid collision and ambiguity in code values, we need to support namespacing in our goal codes. Since goals are only a coarse-grained alignment mechanism, however, we don't need perfect decentralized precision. Confusion isn't much more than an annoyance; the worst that could happen is that two agents discover one or two steps into a protocol that they're not as aligned as they supposed. They need to be prepared to tolerate that outcome in any case.</p> <p>Thus, we follow the same general approach that's used in java's packaging system, where organizations and communities use a self-declared prefix for their ecosystem as the leftmost segment or segments of a family of identifiers (goal codes) they manage. Unlike java, though, these need not be tied to DNS in any way. We recommend a single segment namespace that is a unique string, and that is an alias for a URI identifying the origin ecosystem. (In other words, you don't need to start with \"com.yourcorp.yourproduct\" -- \"yourcorp\" is probably fine.)</p> <p>The <code>aries</code> namespace alias is reserved for goal codes defined in Aries RFCs. The URI aliased by this name is TBD. See the Reference section for more details.</p>"},{"location":"concepts/0519-goal-codes/#versioning","title":"Versioning","text":"<p>Semver-style semantics don't map to goals in an simple way; it is not obvious what constitutes a \"major\" versus a \"minor\" difference in a goal, or a difference that's not worth tracking at all. The content of a goal \u2014 the only thing that might vary across versions \u2014 is simply its free-form description, and that varies according to human judgment. Many different versions of a protocol are likely to share the goal to make a payment or to introduce two strangers. A goal is likely to be far more stable than the details of how it is accomplished.</p> <p>Because of these considerations, goal codes do not impose an explicit versioning mechanism. However, one is reserved for use, in the unusual cases where it may be helpful. It is to append <code>-v</code> plus a numeric suffix: <code>my-goal-code-v1</code>, <code>my-goal-code-v2</code>, etc. Goal codes that vary only by this suffix should be understood as ordered-by-numeric-suffix evolutions of one another, and goal codes that do not intend to express versioning should not use this convention for something else. A variant of the goal code without any version suffix is equivalent to a variant with the <code>-v1</code> suffix. This allows human intuition about the relatedness of different codes, and it allows useful wildcard matching across versions. It also treats all version-like changes to a goal as breaking (semver \"major\") changes, which is probably a safe default.</p> <p>Families of goal codes are free to use this convention if they need it, or to invent a non-conflicting one of their own. However, we repeat our observation that versioning in goal codes is often inappropriate and unnecessary.</p>"},{"location":"concepts/0519-goal-codes/#declaring-goal-codes","title":"Declaring goal codes","text":""},{"location":"concepts/0519-goal-codes/#standalone-rfcs-or-similar-sources","title":"Standalone RFCs or Similar Sources","text":"<p>Any URI-referencable document can declare famlies or ontologies of goal codes. In the context of Aries, we encourage standalone RFCs for this purpose if the goals seem likely to be relevant in many contexts. Other communities may of course document goal codes in their own specs -- either dedicated to goal codes, or as part of larger topics. The following block is a sample of how we recommend that such goal codes be declared. Note that each code is individually hyperlink-able, and each is associated with a brief human-friendly description in one or more languages. This description may be used in menuing mechanisms such as the one described in Action Menu Protocol.</p>"},{"location":"concepts/0519-goal-codes/#goal-codes","title":"goal codes","text":""},{"location":"concepts/0519-goal-codes/#ariessell","title":"<code>aries.sell</code>","text":"<p>en: Sell something. Assumes two parties (buyer/seller). es: Vender algo. Asume que dos partes participan (comprador/vendedor).</p>"},{"location":"concepts/0519-goal-codes/#ariessellgoodsconsumer","title":"<code>aries.sell.goods.consumer</code>","text":"<p>en: Sell tangible goods of interest to general consumers.</p>"},{"location":"concepts/0519-goal-codes/#ariessellservicesconsumer","title":"<code>aries.sell.services.consumer</code>","text":"<p>en: Sell services of interest to general consumers.</p>"},{"location":"concepts/0519-goal-codes/#ariessellservicesenterprise","title":"<code>aries.sell.services.enterprise</code>","text":"<p>en: Sell services of interest to enterprises.</p>"},{"location":"concepts/0519-goal-codes/#in-didcomm-based-protocol-specs","title":"In DIDComm-based Protocol Specs","text":"<p>Occasionally, goal codes may have meaning only within the context of a specific protocol. In such cases, it may be appropriate to declare the goal codes directly in a protocol spec. This can be done using a section of the RFC as described above.</p> <p>More commonly, however, a protocol will accomplish one or more goals (e.g., when the protocol is fulfilling a co-protocol interface), or will require a participant to identify a goal at one or more points in a protocol flow. In such cases, the goal codes are probably declared external to the protocol. If they can be enumerated, they should still be referenced (hyperlinked to their respective definitions) in the protocol RFC.</p>"},{"location":"concepts/0519-goal-codes/#in-governance-frameworks","title":"In Governance Frameworks","text":"<p>Goal codes can also be (re-)declared in a machine-readable governance framework. </p>"},{"location":"concepts/0519-goal-codes/#reference","title":"Reference","text":""},{"location":"concepts/0519-goal-codes/#known-namespace-aliases","title":"Known Namespace Aliases","text":"<p>No central registry of namespace aliases is maintained; you need not register with an authority to create a new one. Just pick an alias with good enough uniqueness, and socialize it within your community. For convenience of collision avoidance, however, we maintain a table of aliases that are typically used in global contexts, and welcome PRs from anyone who wants to update it.</p> alias used by URI aries Hyperledger Aries Community TBD"},{"location":"concepts/0519-goal-codes/#well-known-goal-codes","title":"Well-known goal codes","text":"<p>The following goal codes are defined here because they already have demonstrated utility, based on early SSI work in Aries and elsewhere.</p>"},{"location":"concepts/0519-goal-codes/#ariesvc","title":"<code>aries.vc</code>","text":"<p>Participate in some form of VC-based interaction. </p>"},{"location":"concepts/0519-goal-codes/#ariesvcissue","title":"<code>aries.vc.issue</code>","text":"<p>Issue a verifiable credential. </p>"},{"location":"concepts/0519-goal-codes/#ariesvcverify","title":"<code>aries.vc.verify</code>","text":"<p>Verify or validate VC-based assertions.</p>"},{"location":"concepts/0519-goal-codes/#ariesvcrevoke","title":"<code>aries.vc.revoke</code>","text":"<p>Revoke a VC.</p>"},{"location":"concepts/0519-goal-codes/#ariesrel","title":"<code>aries.rel</code>","text":"<p>Create, maintain, or end something that humans would consider a relationship. This may be accomplished by establishing, updating or deleting a DIDComm messaging connection that provides a secure communication channel for the relationship. The DIDComm connection itself is not the relationship, but would be used to carry out interactions between the parties to facilitate the relationship.</p>"},{"location":"concepts/0519-goal-codes/#ariesrelbuild","title":"<code>aries.rel.build</code>","text":"<p>Create a relationship. Carries the meaning implied today by a LinkedIn invitation to connect or a Facebook \"Friend\" request. Could be as limited as creating a DIDComm Connection.</p>"},{"location":"concepts/0519-goal-codes/#ariesvcverifieronce","title":"<code>aries.vc.verifier.once</code>","text":"<p>Create a DIDComm connection for the sole purpose of doing the one-time execution of a Present Proof protocol. Once the protocol execution is complete, both sides SHOULD delete the connection, as it will not be used again by either side.</p> <p>The purpose of the goal code flow is to accomplish the equivalent of a \"connection-less\" present proof by having the agents establish a DIDComm connection, execute the present proof protocol, and delete the connection. The need for this goal code is when an actual connection-less present proof cannot be used because the out-of-band (OOB) message (including the presentation request) is too large for the transport being used--most often a QR code (although it may be useful for Bluetooth scenarios as well)--and a URL shortner option is not available. By using a one-time connection, the OOB message is small enough to fit into easily into a QR code, the present proof protocol can be executed using the established connection, and at the end of the interaction, no connection remains for either side to use or manage.</p>"},{"location":"concepts/0519-goal-codes/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0530-goal-human-readable-verified-identifer/","title":"Aries RFC 0530: Goal - Human Readable Verifiable Identifier","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: PROPOSED</li> <li>Since: 2020-08-26</li> <li>Status Note: Early Proposal</li> <li>Start Date: 2020-08-26</li> <li>Tags: goalcode</li> </ul>"},{"location":"concepts/0530-goal-human-readable-verified-identifer/#summary","title":"Summary","text":"<p>DIDs are not human friendly. DIDComm provides a secure connection between two DIDs. This goal code seeks to provide a verifiable, human readable identifier from one party to another.</p>"},{"location":"concepts/0530-goal-human-readable-verified-identifer/#motivation","title":"Motivation","text":"<p>Presenting a Human Readable Verifiable Identifier over a DIDComm connection aids the user in positive connection identification. It also plays a role in Man-in-the-Middle (MitM) attack prevention.</p>"},{"location":"concepts/0530-goal-human-readable-verified-identifer/#reference","title":"Reference","text":""},{"location":"concepts/0530-goal-human-readable-verified-identifer/#goal-code","title":"Goal Code","text":"<p><code>aries.receive.verifiable.identifier</code></p>"},{"location":"concepts/0530-goal-human-readable-verified-identifer/#explanation","title":"Explanation","text":"<p>The party presenting this goal code has a goal of receiving a human readable verifiable identifier from the party it presents it to.</p>"},{"location":"concepts/0530-goal-human-readable-verified-identifer/#key-concepts","title":"Key Concepts","text":"<p>Human Readable implies that the identifier is meaningful to a human. This might be an identifier already used to communicate, such as an email address, phone number, website domain name, or social media account name.</p> <p>A Verifiable identifier requires that some level of assurance is provided that control has been proven over the identifier. </p> <p>Governance Frameworks that serve this goal code must provide details about which identifiers are acceptable, and how they are to be verified.  </p>"},{"location":"concepts/0530-goal-human-readable-verified-identifer/#governance-frameworks","title":"Governance Frameworks","text":"<p>The following Governance Frameworks are related to this goal code.</p> <ul> <li>Domain Control </li> <li>Email Ownership</li> </ul>"},{"location":"concepts/0530-goal-human-readable-verified-identifer/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"concepts/0530-goal-human-readable-verified-identifer/#implementations","title":"Implementations","text":"<p>NOTE: This section should remain in the RFC as is on first release. Remove this note and leave the rest of the text as is. Template text in all other sections should be removed before submitting your Pull Request.</p> <p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0535-email-access-governance-framework/","title":"0535: Email Access Governance Framework","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: PROPOSED</li> <li>Since: 2020-09-16</li> <li>Status Note: Proposed, but in need of specifics to put into action.</li> <li>Start Date: 2020-07-14</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"concepts/0535-email-access-governance-framework/#summary","title":"Summary","text":"<p>Note: This RFC was created in advance of the Credential Trust Establishment spec work at the DIF. The ../../concepts are good, but the governance mechanism should be updated to use this newer spec before action is taken.</p> <p>This Governance Framework is community managed.</p> <p>When making connections from one person to another over DIDComm, it is useful to be able to gain proof of something to verify that the connection is with the right person and has not been subject to a MITM attack. We expect this Governance Framework to be one of many used for the purpose of helping to verify identity attributes in the creation of trusted channels.</p> <p>This is an early attempt at the creation and use of of a practical governance framework. As Governance Framework technology improves, we expect this particular framework to be replaced.</p>"},{"location":"concepts/0535-email-access-governance-framework/#purpose","title":"Purpose","text":"<p>To facilitate the verification of email access between two parties over DIDComm and related technologies.</p>"},{"location":"concepts/0535-email-access-governance-framework/#details","title":"Details","text":""},{"location":"concepts/0535-email-access-governance-framework/#goal-codes","title":"Goal Codes","text":"<p>This Governance framework satisfies the following goal code(s):</p> <p><code>aries.receive.verifiable.identifier</code></p>"},{"location":"concepts/0535-email-access-governance-framework/#protocols","title":"Protocols","text":"<p><code>https://didcomm.org/present-proof/2.0/</code></p>"},{"location":"concepts/0535-email-access-governance-framework/#roles","title":"Roles","text":"<p>issuer: Responsible for issuing credentials according to the requirements of this governance framework.</p>"},{"location":"concepts/0535-email-access-governance-framework/#schemas","title":"Schemas","text":"<p>TODO: schemas listed here</p>"},{"location":"concepts/0535-email-access-governance-framework/#issuers","title":"Issuers","text":"<p>BCGov (DID?)</p>"},{"location":"concepts/0535-email-access-governance-framework/#issue-requirements","title":"Issue Requirements","text":"<p>Issuers must validate email ownership by sending an email to the email address in question. The email MUST contain a link for the user to click, or a code to be entered in a verification step. After verifying that the clicked link or entered code matches, the credential may be issued.</p> <p>Issued credentials should indicate an expiration date no longer than 6 months from the date of verification.</p>"},{"location":"concepts/0535-email-access-governance-framework/#revocation","title":"Revocation","text":"<p>This framework does not currently use revocation, relying upon the expiration date to prevent widespread issues.</p>"},{"location":"concepts/0535-email-access-governance-framework/#allowable-verification-purposes","title":"Allowable Verification Purposes","text":"<p>Email addresses revealed in this manner may be used for the following purposes:</p> <ul> <li>Displaying to recipient.</li> <li>Checking against address book.</li> </ul> <p>Use outside these purposes, including the following examples, violates the allowed uses as specified by this governance framework.</p> <ul> <li>Sending email to the address without explicit additional approval of the user.</li> <li>Sharing email address with any other party.</li> </ul>"},{"location":"concepts/0535-email-access-governance-framework/#machine-readable-document","title":"Machine Readable Document","text":"<p>Located here.</p>"},{"location":"concepts/0535-email-access-governance-framework/#notes","title":"Notes","text":"<ul> <li>The machine readable document is as simple as possible by design. As related technology improves, the document will be updated to reflect these changes.</li> <li>Code for the indy email verification service: https://github.com/bcgov/indy-email-verification that could be used as a basis for an issuer.</li> </ul>"},{"location":"concepts/0535-email-access-governance-framework/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Which networks?</li> <li>Need Schemas and Issuers</li> </ul>"},{"location":"concepts/0535-email-access-governance-framework/#uses","title":"Uses","text":"<p>The following libraries or applications use this Governance Framework.</p> Name / Link Implementation Notes"},{"location":"concepts/0559-pppu/","title":"Aries RFC 0559: Privacy-Preserving Proof of Uniqueness","text":"<ul> <li>Authors: Daniel Hardman, Drummond Reed, Lovesh Harchandani, Jason Law, Brent Zundel</li> <li>Status: PROPOSED</li> <li>Since: 2020-10-21</li> <li>Status Note: documents ideas mentioned at RWOT 9 (Sep 2019) and in informal conversations before and since. This is a defensive publication by the Aries community, to prevent such ideas from being encumbered by patents.  </li> <li>Start Date: 2019-02-13 (first formal writeup of the ../../concepts)</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0559-pppu/#summary","title":"Summary","text":"<p>Documents two techniques that, while preserving holder privacy, can guarantee a single use of a verifiable credential by any given unique holder -- the so-called \"one person one vote\" outcome that's often desirable in VC use cases.</p>"},{"location":"concepts/0559-pppu/#motivation","title":"Motivation","text":"<p>Many actions need to be constrained such that a given actor (usually, a human being) can only perform the action once. In government and stockholder elections, we want each voter to cast a single vote. At national borders, we want a visa to allow entrance only a single time before a visitor leaves. In refugee camps, homeless shelters, and halfway houses, we want each guest to access food or medication a single time per distribution event.</p> <p>Solving this problem without privacy is relatively straightforward. We require credentials that disclose a person\u2019s identity, and we track the identities to make sure each is authorized once. This pattern can be used with physical credentials, or with their digital equivalent.</p> <p>The problem is that each actor\u2019s behavior is tracked with this method, because it requires the recording of identity. Instead of just enforcing one-person-one-vote, we create a history of every instance when person X voted, which voting station they attended, what time they cast their vote, and so forth. We create similar records about personal travel or personal medication usage. Such information can be abused to surveil, to harass, to intrude, or to spam.</p> <p>What we need is a way to prove that an action is associated with a unique actor, and thus enforce the one-actor-one-action constraint, without disclosing that actor\u2019s identity in a way that erodes privacy. Although we began with examples of privacy for humans, we also want a solution for groups or institutions wishing to remain anonymous, or for devices, software entities, or other internet-of-things actors that have a similar need.</p>"},{"location":"concepts/0559-pppu/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0559-pppu/#solution-1","title":"Solution 1","text":"<p>This solution allows uniqueness to be imposed on provers during an arbitrary context chosen by the verifier, with no unusual setup at issuance time. For example, a verifier could decide to constrain a particular credential holder to proving something only once per hour, or once during a given contest or election. The price of this flexibility is that the credential holder must have a digital credential that already has important uniqueness guarantees (e.g., a driver's license, a passport, etc).</p> <p>In contrast, solution 2 imposes uniqueness at issuance time, but requires no  other credential with special guarantees.</p>"},{"location":"concepts/0559-pppu/#components","title":"Components","text":"<p>The following components are required to solve this problem:</p>"},{"location":"concepts/0559-pppu/#a","title":"A","text":"<p>one issuance to identified holder \u2014 A trustworthy process that issues verifiable credentials exactly once to an identified holder. (This is not new. Governments have such processes today to prevent issuing two driver\u2019s licenses or two passports to the same person.)</p>"},{"location":"concepts/0559-pppu/#b","title":"B","text":"<p>one issuance to anonymous holder \u2014 A method of issuing a credential only once to an anonymous holder. (This is not new. Scanning a biometric from an anonymous party, and then checking it against a list of known patterns with no additional metadata, is one way to do this. There are other, more cryptographic methods, as discussed below.)</p>"},{"location":"concepts/0559-pppu/#c","title":"C","text":"<p>strong binding \u2014 A mechanism for strongly associating credentials with a specific credential holder, such that they are not usable by anyone other than the proper holder. (This is not new. Embedding a biometric such as a fingerprint or a photo in a credential is a simple example of such a mechanism.)</p>"},{"location":"concepts/0559-pppu/#d","title":"D","text":"<p>linking mechanism \u2014 A mechanism for proving that it is valid to combine information from multiple credentials because they describe the same credential holder, without revealing the common link between those credentials. (An easy and familiar way to prove combinability is to embed a common characteristic in each credential. For example, two credentials that are both about a person with the same social security number can be assumed to describe the same person. What is required here goes one step further--we need a way to prove that two credentials contain the same data, or were built from the same data, without revealing that data at all. This is also not new. Cryptographic commitments provide one possible answer.)</p>"},{"location":"concepts/0559-pppu/#e","title":"E","text":"<p>proving without revealing \u2014 A method for proving the correctness of information derived from a credential, without sharing the credential information itself. (This is not new. In cryptographic circles, one such technique is known as a zero-knowledge proof. It allows Alice to hold a credential that contains her birthdate, but to prove she is over 65 years old instead of revealing the birthdate itself.)</p>"},{"location":"concepts/0559-pppu/#walkthru","title":"Walkthru","text":"<p>We will describe how this solution uses components A-E to help a fictional voter, Alice, in an interaction with a fictional government, G. Alice wishes to remain anonymous but still cast her vote in an election; G wishes to guarantee one-citizen-one-vote, but to retain no additional information that would endanger Alice\u2019s privacy. Extrapolating from a voting scenario to other situations that require uniqueness is left as an exercise for the reader.</p> <p>The solution works like this:</p> <ol> <li> <p>Alice receives a voter credential, C1, from G. C1 strongly identifies Alice, perhaps containing her name, address, birthdate, and so forth. It is possession of this credential that proves a right to vote. G issues only one such credential to each actor. (component A)</p> </li> <li> <p>C1 is bound to Alice so it can\u2019t be used by anyone else. (component C)</p> </li> <li> <p>C1 also contains data provided by Alice, and derived from a secret that only Alice knows, such that Alice can link C1 to other credentials with similarly derived data because she knows the secret. (component D)</p> <p></p> <p>Steps 1-3: Alice receives a voter credential from G.</p> </li> <li> <p>Alice arrives to vote and asserts her privilege to a different government agency, G\u2019, that administers the election.</p> </li> <li> <p>G\u2019 chooses a random identifier, X, for the anonymous person (Alice) that wants to vote.</p> </li> <li> <p>G\u2019 asks this anonymous voter (Alice) to provide data suitable for embedding in a new credential, such that the new credential and her old credential can be proved combinable. (component D).</p> </li> <li> <p>G\u2019 verifies that it has not issued a credential to this anonymous person previously. (component B)</p> </li> <li> <p>G\u2019 issues a new credential, C2, to the anonymous voter. C2 contains the random identifier X, plus the data that Alice provided in step 6. (This means the party playing the role of Verifier temporarily becomes a JIT Issuer.)</p> <p></p> <p>Steps 4-8: Anonymous (Alice) receives a unique credential from G\u2019.</p> </li> <li> <p>G\u2019 asks the anonymous voter to prove, without revealing any identifying information from C1 (component E) the following assertions:</p> <ul> <li>They possess a C1 and C2 that are combinable (component D)</li> <li>The C2 possessed by this anonymous voter contains the randomly-generated value X that was just chosen and embedded in the C2 issued by G\u2019. At this point X is revealed.</li> </ul> <p></p> <p>Step 9: Alice proves C1 and C2 are combinable and C2 contains X.</p> </li> </ol> <p>This solves the problem because:</p> <ul> <li>Each actor can only receive one C1 from G.</li> <li>Each actor can only receive one C2 from G\u2019.</li> <li>C1 cannot be shared or transferred.</li> <li>It is valid to combine information from C1 and C2 (they belong to the same actor), because of the first assertion in step 9.</li> <li>C2 is the same C2 that was just generated for the person asking to vote (it could not have been substituted), because it contains X as demonstrated by the second assertion in step 9.</li> <li>No identifying information in C1 is revealed.</li> </ul> <p>Both credentials are required. If a person only has C1, then there is no way to enforce single usage while remaining anonymous. If a person only has C2, then there is no reason to believe the unique person who shows up to vote actually deserves the voting privilege. It is the combination that proves uniqueness of the person in the voting event, plus privilege to cast a vote. Zero-knowledge proving is also required, or else the strongly identifying information in C1 may leak.</p> <p>As mentioned earlier, this same mechanism can be applied to scenarios besides voting, and can be used by actors other than individual human beings. G (the issuer of C1) and G\u2019 (the verifier of C1 and issuer of C2) do not need to be related entities, as long as G1 trusts G. What is common to all applications of the technique is that uniqueness is proved in a context chosen by the verifier, privilege is based on previously issued and strongly identifying credentials, and yet the anonymity of the credential holder is preserved.</p>"},{"location":"concepts/0559-pppu/#building-in-aries","title":"Building in Aries","text":"<p>Ingredients to build this solution are available in Aries or other Hyperledger projects (Ursa, Indy) today:</p> <ul> <li> <p>The behavior of component A could be enforced by a machine-readable governance framework.</p> </li> <li> <p>Component B can be built using an approach described here; a more general description was published much earlier, in a seminal \"Clone Wars\" paper by Camenisch et al.</p> </li> <li> <p>Component C can be accomplished using Indy's link secret construct, which uses Pedersen commitments to embed in a credential a blinded version of a secret known only to the holder. As mentioned earlier, biometric bindings are also an option. Depending on requirements for level of assurance, a simple binding by DID control may also work.</p> </li> <li> <p>Component D is a mainstream feature in Indy's anoncreds library today; it combines credentials by demonstrating mathematically that they each contain a differently blinded derivation of the same link secret. A more general form of this is available in Ursa; it demonstrates that any two fields are equal in two credentials without revealing the field values. [[TODO: need link]].</p> </li> <li> <p>Component E is available in Indy's anoncreds as well as in recent work done on BBS+ signatures by Mattr [[TODO: need link]].</p> </li> </ul>"},{"location":"concepts/0559-pppu/#solution-2","title":"Solution 2","text":"<p>This is another solution that accomplishes approximately the same goal as solution 1. It is particularly helpful in voting. It has much in common with the earlier approach, but differs in that uniqueness must be planned for at time of issuance (instead of being imposed just in time at verification). The issuer signs a serial number to each unique holder, and the holder then makes a Pedersen Commitment to their unique serial number while the voting is open. The holder cannot vote twice or change their vote. The voter\u2019s privacy is preserved.</p>"},{"location":"concepts/0559-pppu/#walkthru_1","title":"Walkthru","text":"<p>Suppose a poll is being conducted with p number of options as m1, m2, m3,... mp and each poll has a unique id I. Acme Corp is conducting the poll and Alice is considered an eligible voter by Acme Corp because Alice has a credential C from Acme Corp.</p>"},{"location":"concepts/0559-pppu/#goals","title":"Goals","text":"<ul> <li> <p>Ballot privacy: Alice should be able to participate in the poll without Acme corp finding out which poll option was chosen by Alice.</p> </li> <li> <p>One vote per voter: Alice should not be able to vote more than once.</p> </li> <li> <p>Immutable Ballot: Alice should be bound to her ballot, i.e. she should not be able to change her vote.</p> </li> <li> <p>Valid choice: Alice should not be able to vote for any option than the valid ones, i.e. other than m1, m2, m3,... mp.</p> </li> <li> <p>Verifiability: Alice should be able to check that her vote is being counted.</p> </li> <li> <p>No preview: Before the poll terminates, no one should be able to decide the outcome or even the favored option. This avoids bias.</p> </li> </ul> <p>Additional condition: In some cases the poll conduction entity, Acme Corp, in this case, may be accused of creating Sybil identities vote to influence the poll. This can be mitigated if an additional constraint is enforced where only those are eligible to vote who can prove that their credential C was issued before the poll started (or at least some time t before the poll started), i.e. Alice should be able to prove to anyone that her credential C was issued to anyone.</p>"},{"location":"concepts/0559-pppu/#setup","title":"Setup","text":"<p>Acme corp has hosted an application AS that maintains a merkle tree and the application follows some rules to update the tree. This application should be auditable meaning that anyone should be able to check whether the application is updating the tree as per the rules and the incoming data. Thus this application could be hosted on a blockchain, or within a trusted execution environment like SGX. Also the application server maintains a dynamic set where set membership check is efficient. The merkle tree is readable by all poll participants.</p> <p>There are 2 different functions defined F1 and F2 both of which take 2 inputs and return one output and they are not invertible, even knowing one input and output should not reveal other input. The output of both on same input must be different. Thus these can be modeled as different hash functions like SHA2 and SHA3 or SHA2 with domain separation. But we want these functions to R1CS friendly so we choose a hash function like MiMC with domain separation.</p>"},{"location":"concepts/0559-pppu/#basic-idea","title":"Basic idea","text":"<p>Alice generates a serial number and gets a blind signature from Acme Corp over the serial number. Then Alice creates her vote and sends the \"encrypted\" vote with the serial number and signature to the application server. Application server accepts the vote if the signature is valid and it has not seen that serial number before. It will then update the merkle tree with the \"encrypted\" vote and return a signed proof to Alice of the update. When the poll terminates, Alice will then submit the decryption key to the application server which can then decrypt the vote and do the tally.</p>"},{"location":"concepts/0559-pppu/#detailed-description","title":"Detailed description","text":"<ul> <li>Acme corp conducts a poll with p choices, m1, m2,..mp. The poll is given a unique identifier I.</li> <li>Alice wants to participate in the poll. She has a credential C from Acme with link secret l.</li> <li>Alice constructs serial number S using F1. S = F1(l, I).</li> <li>Alice blinds S and then obtains a blind signature (blind Schnorr works) from Amce Corp over it. Alice might have proved her ownership of credential C.</li> <li>Alice decides to vote for m2. She needs to commit to her vote as a Pedersen commitment. The randomness for the Pedersen commitment r is computed using F2.    r = F2(l, I). The committed vote now becomes gm2.hr. Let V = gm2.hr.</li> <li>Alice sends V and S and the signature over S from Acme to application server AS. Alice also sends a proof which proves the following:</li> <li>Alice owns a credential C from Acme Corp. This can be done with CL or BBS+ signature. Additionally, it can be proved that C was issued some time ago to achieve characteristic 5.</li> <li>Serial number S is constructed from the link secret l of C and poll identifier I using F1. This can be done with Bulletproofs by using proof of knowledge of preimage. We have proving knowledge of preimage implemented. The part about establishing equivalence with link secret l has to be done.</li> <li>V is correctly formed in this way gm2.hr. This is a standard Schnorr proof.</li> <li>V's randomness r is constructed from the link secret l of C and poll identifier I using F2. Again done with Bulletproofs above and circuit to prove knowledge of opening of Pedersen commitment. The 2<sup>nd</sup> part is to be implemented.</li> <li>V's message m2 is one of m1, m2,..mp. This can be done with set membership proof of committed value with Bulletproofs. We have it implemented already.</li> <li>If application server AS accepts a proof, it returns the signed merkle proof of the presence of V in the tree to Alice.</li> <li>Alice can anytime check that her V is present in the tree.</li> <li>Once poll completes, Alice can reveal opening of V to AS and then result of poll can be computed.</li> <li>Before the poll completes (and voter reveals their m and r, no one can know which option has been voted the most or least or not at all. </li> </ul>"},{"location":"concepts/0559-pppu/#rationale-and-alternatives","title":"Rationale and alternatives","text":""},{"location":"concepts/0559-pppu/#prior-art","title":"Prior art","text":""},{"location":"concepts/0559-pppu/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"concepts/0559-pppu/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/","title":"0566: Issuer-Hosted Custodial Agents","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: PROPOSED</li> <li>Since: 2020-11-16</li> <li>Status Note: Draft</li> <li>Start Date: 2020-10-27</li> <li>Tags: concept</li> </ul> <p>In the fully realized world of Self Soverign Identity, credential holders are equipped with capable agents to help them manage credentials and other SSI interactions. Before we arrive in that world, systems that facilitate the transition from the old model of centralized systems to the new decentralized models will be necessary and useful.</p> <p>One of the common points for a transition system is the issuance of credentials. Today's centralized systems contain information within an information silo. Issuing credentials requires the recipient to have an agent capable of receiving and managing the credential. Until the SSI transition is complete, some users will not have an agent of their own.</p> <p>Some users don't have the technology or the skills to use an agent, and there may be users who don't want to participate.</p> <p>In spite of the difficulties, there are huge advantages to transition to a decentralized system. Even when users don't understand the technology, they do care about the benefits it provides.</p> <p>This situation leaves the issuer with a choice: Maintain both a centralized system AND a decentralized SSI one, or enable their users to participate in the decentralized world.</p> <p>This paper addresses the second option: How to facilitate a transition to a decentralized world by providing issuer-hosted custodial agents.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#issuer-hosted-custodial-agents","title":"Issuer-Hosted Custodial Agents","text":"<p>A custodial agent is an agent hosted on behalf of someone else. This model is common in the cryptocurrency space. An Issuer-Hosted Custodial Agent is exactly what it sounds like: an agent hosted for the holder of a credential by the issuer of the credential.</p> <p>This custodial arrangement involves managing the credentials for the user, but also managing the keys for the user. Key management on behalf of another is often called guardianship.</p> <p>An alternative to hosting the agent directly is to pay for the hosting by a third party provider. This arrangement addresses some, but not all, of the issues in this paper.</p> <p>This custodial arrangement is only necessary for the users without their own agents. Users running their own agents (often a mobile app), will manage their own keys and their own credentials.</p> <p>For the users with their own agents, the decentralized world has taken full effect: they have their own data, and can participate fully in the SSI ecosystem.</p> <p>For the users with hosted custodial agents, they have only made a partial transition. The data is still hosted by the issuer. With appropriate limits, this storage model is no worse than a centralized system. Despite the data storage being the same, a hosted agent provides the ability to migrate to another agent if the user desires.</p> <p>Hosting agents for users might sound like a costly endeavor, but hosted agents contain an advantage. Most hosted agents will only be used by their owners for a small amount of time, most likely similar to their interaction with the centralized system it replaces. This means that the costs are substantially lower than hosting a full agent.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#hosted-agent-interaction","title":"Hosted Agent Interaction","text":"<p>Hosted agents have some particular challenges in providing effective user interaction. Detailed below are several options that can be used alone or in combination.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#browser-based","title":"Browser Based","text":"<p>Providing a browser based user interface for a user is a common solution when the user will have access to a computer. Authentication will likely use something familiar like a username and password.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#authorizing-actions","title":"Authorizing Actions","text":"<p>The user will often need a way to authorize actions that their agent will perform. A good option for this is via the use of a basic cell phone through SMS text messages or voice prompts. Less urgent actions can use an email sent to the user, prompting the user to login and authorize the actions.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#offline-paper-based","title":"Offline / Paper based","text":"<p>At times the user will have no available technology for their use. In this case, providing QR codes printed on paper with accompanying instructions will allow the user to facilitate verifier (and perhaps another issuer) access to their cloud agent. QR Codes, such as those detailed in the Out Of Band Protocol, can contain both information for connecting to agent AND an interaction to perform. Presenting the QR code for scanning can serve as a form of consent for the prescribed action within the QR code. Printed QR codes can be provided by the issuer at the time of custodial agent creation, or from within a web interface available to the user.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#kiosk-based","title":"Kiosk based","text":"<p>Kiosks can be useful to provide onsite interaction with a hosted agent. Kiosk authentication might take place via username and password, smartcard, or USB crypto key, with the possible inclusion of a biometric. Kiosks must be careful to fully remove any cached data when a session closes. Any biometric data used must be carefully managed between the kiosk and the hosted agent.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#smartphone-app","title":"Smartphone App","text":"<p>While it is common for a smartphone app to be an agent by itself, there are cases where a smartphone app can act as a remote for the hosted agent. In this iteraction, keys, credentials, and other wallet related data is held in the custodial agent. The mobile app acts as a remote viewer and a way for the user to authorize actions taken by the custodial agent.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#best-practices","title":"Best Practices","text":"<p>The following best practices should be followed to ensure proper operation and continued transition to a fully realized SSI architecture. Most of these practices depend upon and support one another.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#defend-the-ssi-architecture","title":"Defend the SSI architecture","text":"<p>When issuers host custodial agents, care must be taken to avoid shortcuts that would violate SSI architecture. Deviations will frequently lead to incompatibilities.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#didcomm-protocol-based-integration","title":"DIDComm Protocol based Integration","text":"<p>Communication between hosted agents and credential issuing agent must be based on published DIDComm protocols. Any communication which eliminates the use of a DID must be avoided. Whenever possible, these should be well adopted community protocols. If the case a new protocol is needed for a particular interaction, this must be fully documented and published, to allow other agents to become compatible by adopting the new protocol.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#allow-bring-your-own-agents","title":"Allow bring-your-own agents","text":"<p>The onboarding process must allow users to bring their own compatible agents. This will be possible as long as any communication is protocol based. No ../../features available to hosted agents should be blocked from user provided agents.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#limit-wallet-scope-to-data-originating-from-the-issuer","title":"Limit wallet scope to data originating from the issuer","text":"<p>Issuer hosted agents should have limits placed on them to prevent general use. This will prevent the agent from accepting additional credentials and data outside the scope of the issuer, therefore introducing responsibility for data that was never intended. This limtation must not limit the user in how they use the credentials issued, only in the acceptance of credentials and data from other issuers or parties. The use of policy and filters should be used to limit the types of credentials that can be held, which issuers should be allowed, and which protocols are enabled. None of these restrictions are necessary for bring-your-own agents provided by users.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#allow-migrate-from-hosted-to-bring-your-own","title":"Allow migrate from hosted to bring-your-own","text":"<p>Users must be allowed to transition from an issuer-hosted agent to an agent of their choosing. This can happen either via a backup in a standard format, or via re-issuing relevant credentials.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#transparent-to-the-verifier","title":"Transparent to the verifier","text":"<p>A verifier should not be able to tell the difference between a custodial hosted agent vs a bring-your-own agent.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#action-log","title":"Action Log","text":"<p>All actions taken by the wallet should be preserved in a log viewable to the user. This includes how actions were authorized, such as a named policy or confirmation via text message.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#encrypted-wallets","title":"Encrypted Wallets","text":"<p>Hosted wallet data should be encrypted at rest.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#independant-key-management","title":"Independant key management","text":"<p>Keys used for hosted agents should have key mangement isolated from the issuer keys. Access to the keys for hosted agents should be carefully limited to the minimum required personnel. All key access should be logged.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#hosted-agent-isolation","title":"Hosted Agent Isolation","text":"<p>Agents must be sufficiently isolated from each other to prevent a malicious user from accessing another user's agent or data or causing interruptions to the operation of another agent.</p>"},{"location":"concepts/0566-issuer-hosted-custodidal-agents/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0700-oob-through-redirect/","title":"Aries RFC 0700: Out-of-Band through redirect","text":"<ul> <li>Authors: Sudesh Shetty</li> <li>Status: PROPOSED</li> <li>Since: 2021-10-08</li> <li>Status Note: implementation is being explored by SecureKey</li> <li>Start Date: 2019-10-08</li> <li>Tags: concept, decorator</li> </ul>"},{"location":"concepts/0700-oob-through-redirect/#summary","title":"Summary","text":"<p>Describes how one party can redirect to another party by passing out-of-band message as a query string and also recommends how to redirect back once protocol is over.  </p>"},{"location":"concepts/0700-oob-through-redirect/#motivation","title":"Motivation","text":"<p>In current day e-commerce applications, while performing checkout users are usually presented with various payment options, like direct payment options or through some payment gateways.  User then chooses an option, gets redirected to a payment application and then gets redirected back once transaction is over.  </p> <p>Similarly, sending an out-of-band invitation through redirect plays an important role in web based applications where an inviter who is aware of invitee application or a selection service should be able to send invitation through redirect. Once invitee accepts the invitation and protocol gets over, then invitee should also be able to redirect back to URL shared through DIDComm message during protocol execution.  The redirect can happen within the same device (ex: clicking a link) or between devices (ex: scanning a QR code).</p>"},{"location":"concepts/0700-oob-through-redirect/#scenario","title":"Scenario","text":"<p>Best example scenario would be how an issuer or a verifier applications trying to connect to holder applications for performing present proof or issuer credential protocol. A user who visits an issuer application can click on a link or scan a QR code to redirect to a holder application with an out-of-band message in query string (or redirect to a selection service showing available holder applications to choose from).  User's holder application decodes invitation from query string, performs issue credential protocol and redirects user back to URL it received through DIDComm message from issuer during execution of protocol.</p>"},{"location":"concepts/0700-oob-through-redirect/#tutorial","title":"Tutorial","text":"<p>There are 2 roles in this flow,</p> <ul> <li>requestor, the one who sends out-of-band invitation using query string to initiate a protocol.</li> <li>recipient, the one who receives out-of-band invitation and also the one who is asked to redirect back to requestor once protocol is over. </li> </ul>"},{"location":"concepts/0700-oob-through-redirect/#redirect-invitation-url","title":"Redirect Invitation URL","text":"<p>A redirect URL from inviter to connect can consist of following elements,</p> <ul> <li><code>domain and path</code>: domain and path are managed by inviter application and it can be a target application to which this out-of-band invitation is targeted. The target application can be a agent based application or a selection service which can present various application selection options to user.</li> <li><code>out-of-band message</code>: A query parameter <code>oob</code> containing out-of-band message of Base64URLEncoded json format. Refer Standard Out-of-Band Message Encoding to learn more.</li> <li><code>out-of-band message ID</code>: It seems inevitable that the length of some out-of-band message will be too long to produce a useable redirect URL or QR Code. A query parameter <code>oobid</code> containing out-of-band invitation URL which can be resolved to fetch actual invitation message. Refer Out-of-Band URL Shortening to learn more.</li> </ul>"},{"location":"concepts/0700-oob-through-redirect/#sample-1-redirect-invitation","title":"Sample 1: redirect invitation","text":"<p>Invitation:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/1.0/invitation\",\n  \"@id\": \"69212a3a-d068-4f9d-a2dd-4741bca89af3\",\n  \"label\": \"Faber College\",\n  \"goal_code\": \"issue-vc\",\n  \"goal\": \"To issue a Faber College Graduate credential\",\n  \"handshake_protocols\": [\"https://didcomm.org/didexchange/1.0\", \"https://didcomm.org/connections/1.0\"],\n  \"services\": [\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]\n}\n</code></pre> <p>Whitespace removed:</p> <pre><code>{\"@type\":\"https://didcomm.org/out-of-band/1.0/invitation\",\"@id\":\"69212a3a-d068-4f9d-a2dd-4741bca89af3\",\"label\":\"Faber College\",\"goal_code\":\"issue-vc\",\"goal\":\"To issue a Faber College Graduate credential\",\"handshake_protocols\":[\"https://didcomm.org/didexchange/1.0\",\"https://didcomm.org/connections/1.0\"],\"services\":[\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]}\n</code></pre> <p>Base 64 URL Encoded:</p> <pre><code>eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCAiZ29hbF9jb2RlIjoiaXNzdWUtdmMiLCJnb2FsIjoiVG8gaXNzdWUgYSBGYWJlciBDb2xsZWdlIEdyYWR1YXRlIGNyZWRlbnRpYWwiLCJoYW5kc2hha2VfcHJvdG9jb2xzIjpbImh0dHBzOi8vZGlkY29tbS5vcmcvZGlkZXhjaGFuZ2UvMS4wIiwiaHR0cHM6Ly9kaWRjb21tLm9yZy9jb25uZWN0aW9ucy8xLjAiXSwic2VydmljZSI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0\n</code></pre> <p>Example URL: targeting recipient 'recipient.example.com'</p> <pre><code>http://recipient.example.com/handle?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCAiZ29hbF9jb2RlIjoiaXNzdWUtdmMiLCJnb2FsIjoiVG8gaXNzdWUgYSBGYWJlciBDb2xsZWdlIEdyYWR1YXRlIGNyZWRlbnRpYWwiLCJoYW5kc2hha2VfcHJvdG9jb2xzIjpbImh0dHBzOi8vZGlkY29tbS5vcmcvZGlkZXhjaGFuZ2UvMS4wIiwiaHR0cHM6Ly9kaWRjb21tLm9yZy9jb25uZWN0aW9ucy8xLjAiXSwic2VydmljZSI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0\n</code></pre> <p>Out-of-band invitation redirect URLs can be transferred via text message, email, SMS, posting on a website, or QR Code.</p> <p>Example URL encoded as a QR Code:</p> <p></p>"},{"location":"concepts/0700-oob-through-redirect/#sample-2-redirect-invitation-url","title":"Sample 2: redirect invitation URL","text":"<p>Invitation URL from requestor which resolves to an out-of-band invitation:</p> <pre><code>https://requestor.example.com/ssi?id=5f0e3ffb-3f92-4648-9868-0d6f8889e6f3\n</code></pre> <p>Base 64 URL Encoded:</p> <pre><code>aHR0cHM6Ly9yZXF1ZXN0b3IuZXhhbXBsZS5jb20vc3NpP2lkPTVmMGUzZmZiLTNmOTItNDY0OC05ODY4LTBkNmY4ODg5ZTZmMw==\n</code></pre> <p>Example URL: targeting recipient 'recipient.example.com'</p> <pre><code>http://recipient.example.com/handle?oobid=aHR0cHM6Ly9yZXF1ZXN0b3IuZXhhbXBsZS5jb20vc3NpP2lkPTVmMGUzZmZiLTNmOTItNDY0OC05ODY4LTBkNmY4ODg5ZTZmMw==\n</code></pre> <p>Out-of-band invitation redirect URLs can be transferred via text message, email, SMS, posting on a website, or QR Code.</p> <p>Example URL encoded as a QR Code:</p> <p></p>"},{"location":"concepts/0700-oob-through-redirect/#web-redirect-decorator","title":"<code>~web-redirect</code> Decorator","text":"<p>In some scenarios, requestor would require recipient to redirect back after completion of protocol execution to proceed with further processing. For example, a verifier would request a holder application to redirect back  once present-proof protocol is over so that it can show credential verification results to user and navigate the user to further steps.</p> <p>The optional <code>~web-redirect</code> SHOULD be used in DIDComm message sent by requestor during protocol execution to send redirect information to recipient if required.</p> <p>This decorator may not be needed in many cases where requestor has control over the flow of application based on protocol status.  But this will be helpful in cases where an application has little or no control over user's navigation.  For example, in a web browser where user redirected from a verifier web application to his wallet application in a same window through some wallet selection wizard and some third party logins.  In this case once the protocol execution is over,  verifier can send a URL to wallet application requesting redirect.  This decorator is also useful switching from wallet mobile app to verifier mobile app in a mobile device.</p> <pre><code>\"~web-redirect\": {\n  \"status\": \"OK\",\n  \"url\": \"https://example.com/handle-success/51e63a5f-93e1-46ac-b269-66bb22591bfa\"\n}\n</code></pre> <p>where,</p> <ul> <li><code>status</code>: The value of this property MUST be one of the statuses defined here</li> <li><code>url</code>: URL to which recipient of this message is requested to redirect.</li> </ul> <p>Some of the DIDComm messages which can use <code>~web-redirect</code> details to send redirect request.</p> <ul> <li>protocol acknowledgment messages</li> <li>problem reports</li> <li>protocol messages which concludes the protocol, like Issue Credential message.</li> </ul>"},{"location":"concepts/0700-oob-through-redirect/#putting-all-together","title":"Putting all together","text":""},{"location":"concepts/0700-oob-through-redirect/#sending-invitation-to-recipient-through-redirect","title":"Sending Invitation to Recipient through redirect","text":"<ul> <li> <p>Step 1 - requestor prepares out-of-band redirect URL : requestor prepares URL using encoded JSON invitation or using a URL which resolves to an invitation.  Domain and target of URL can be a known recipient.</p> </li> <li> <p>Step 2: requestor presents redirect URL to user: redirect URL can be presented to user as a link, mobile deep link, QR Code, SMS, Email etc.  For example, user visits a verifier application and presented with link or QRCode to share his or her credentials.</p> </li> <li> <p>Step 3: user redirects to recipient: user clicks on link or scans QR code and then authenticates himself or herself in redirected application.  For example, user clicks on a link to share credentials in a verifier application, gets redirected to a holder application and logs in using his or her login credentials.</p> </li> <li> <p>Step 4: recipient accepts invitation, connects with requestor and executes protocol: recipient application decodes invitation, accepts it and executes DIDComm protocol. For example, holder application accepts invitation from a verifier, performs present proof and meanwhile shows credential interaction screen to user for consent.</p> </li> <li> <p>Step 5: requestor shares web redirect info to recipient for next step: requestor sends <code>~web-redirect</code> to recipient application through acknowledgement, problem report or any other DIDComm message which concludes protocol.  For example, verifier sending its success page URL as part of acknowledgement message to user after successful completion present proof protocol.</p> </li> <li> <p>Step 6: user redirected back to requestor: recipient application extracts redirect info from <code>~web-redirect</code> and redirects.  For example where user is presented with successful credential verification screen and asked to proceed with further steps.</p> </li> </ul>"},{"location":"concepts/0700-oob-through-redirect/#sending-invitation-to-selection-service-through-redirect","title":"Sending Invitation to Selection Service through redirect","text":"<p>This flow is similar to previous flow but target domain and path of invitation redirect URL will be selection service which presents user with various options to choose recipient application of choice. So in Step 3, user redirects to a selection service which guides user to select right recipient. For example a scenario where user is presented with various holder application providers to choose from while sharing/saving his or her verifiable credentials.</p>"},{"location":"concepts/0700-oob-through-redirect/#reference","title":"Reference","text":"<ul> <li>Wallet And Credential Interactions</li> </ul>"},{"location":"concepts/0700-oob-through-redirect/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>How different recipient applications registers with a selection service and establishing trust between requestor, recipient and selection service are out of scope of this RFC.</p>"},{"location":"concepts/0700-oob-through-redirect/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"concepts/0757-push-notification/","title":"0757: Push Notification","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: PROPOSED</li> <li>Since: 2022-11-02 </li> <li>Status Note:  </li> <li>Start Date: 2022-11-02 </li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0757-push-notification/#summary","title":"Summary","text":"<p>This RFC Describes the general concept of push notification as it applies to Aries Agents. There are a variety of push notification systems and methods, each of which is described in it's own feature RFC.</p> <p>Note: These protocols operate only between a mobile app and it's mediator(s). There is no requirement to use these protocols when mobile apps and mediator services are provided as a bundle. These protocols exist to facilitate cooperation between open source mediators and mobile apps not necessarily developed between the same parties.</p>"},{"location":"concepts/0757-push-notification/#motivation","title":"Motivation","text":"<p>Mobile agents typically require the use of Mediators to receive DIDComm Messages. When messages arrive at a mediator, it is optimal to send a push notification to the mobile device to signal that a message is waiting. This provides a good user experience and allows mobile agents to be responsive without sacrificing battery life by routinly checking for new messages.</p>"},{"location":"concepts/0757-push-notification/#tutorial","title":"Tutorial","text":"<p>Though push notification is common mobile platforms, there are a variety of different systems with various requirements and mecanisms. Most of them follow a familiar pattern:</p>"},{"location":"concepts/0757-push-notification/#setup-phase","title":"Setup Phase","text":"<ol> <li>Notification Sender (mediator) registers with a push notification service. This typically involves some signup procedure.</li> <li>Notification Recipient (mobile app) registers with the push notification service. This typically involves some signup procedure. For some platforms, or for a mediator and mobile app by the same vendor, this will be accomplished in step 1.</li> <li>Notification Recipient (mobile app) adds code (with config values obtained in step 2) to connect to the push notification service.</li> <li>Notification Recipient (mobile app) communicates necessary information to the Notification Sender (mediator) for use in sending notifications.</li> </ol>"},{"location":"concepts/0757-push-notification/#notification-phase","title":"Notification Phase","text":"<ol> <li>A message arrives at the Notification Sender (mediator) destined for the Notification Recipient (mobile app).</li> <li>Notification Sender (mediator) calls an API associated with the push notification service with notification details, typically using the information obtained in step 4.</li> <li>Notification Recipient (mobile app) is notified (typically via a callback function) of the notification details.</li> <li>Notification Recipient (mobile app) then connects to the Notification Sender (mediator) and receives waiting messages.</li> </ol> <p>In spite of the flow similarities between the push notification platforms, the implementations, libraries used, and general code paths vary substantially.  Each push notification method is described in it's own protocol. This allows the protocol to fit the specific needs and terminology of the notification method it enables. Feature Discovery can be used between the Notification Sender and the Notification Recipient to discover push notification compatibility.</p>"},{"location":"concepts/0757-push-notification/#public-mediators","title":"Public Mediators","text":"<p>Some push notification methods require matching keys or secrets to be used in both sending and receiving notifications. This requirement makes these push notification methods unusable by public mediators.</p> <p>Public mediators SHOULD only implement push notification methods that do not require sharing secrets or keys with application implementations.</p>"},{"location":"concepts/0757-push-notification/#push-notification-protcols","title":"Push Notification Protcols","text":"<p>0699 - Push Notification APNS 1.0 (Apple Push Notification Service)</p>"},{"location":"concepts/0757-push-notification/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"concepts/0781-trust-input-protocol/","title":"RFC 0781: Trust Input Protocol","text":"<ul> <li>Authors: Mathieu Glaude, Subhasis Ojha</li> <li>Status: PROPOSED</li> <li>Since: 2023-11-23</li> <li>Status Note: New RFC being proposed</li> <li>Supersedes: None</li> <li>Start Date: 2023-11-23</li> </ul> <p>## Summary</p> <p>The Trust Input Protocol is a conceptual framework designed to assist with the making of trust decisions within digital interactions. It emphasizes the importance of both technical (cryptographic) trust and human trust. The protocol introduces the concept of \"Trust Inputs,\" which are sources of information that assist entities in making trust decisions. For the purpose of this RFC, trust inputs may only come from Trust Registries that support DIDComm-based messaging, based on RFC 0160: Connection Protocol. The first use case that this framework looks to support is allowing verifiers of a digital credential proof presentation to query the authoritativeness of digital credential issuers against trust registries.</p> <p>## Motivation</p> <p>The primary motivation for creating a Trust Input Protocol is to address the challenges of establishing trust in digital interactions. As digital transactions become more prevalent, there's a growing need to ensure that parties can trust each other, especially in contexts where real or perceived risks are involved. Traditional cryptographic methods provide technical trust, ensuring that data hasn't been altered or falsified. However, they don't address the human aspect of trust, such as verifying the authenticity of a claim or ensuring that a claim has been issued by a recognized authority. The Trust Input Protocol aims to bridge this gap by providing a framework where parties can seek trust inputs from various sources to make informed trust decisions. Although we focus on trust registries in the short-term, we imagine this protocol being capable of allowing trust decision making entities to seek inputs from sources outside of trust registries. For this reason, we will use the broader term <code>trust-input</code>.</p> <p></p> <p>This above diagram was taken from a June 29, 2023 presentation given to the Trust over IP Foundation (Slides, Recording).</p> <p>Trust registries are authoritative sources of information that we can use as inputs to make trust decisions. In the digital credentialing world, we can imagine sometimes needing to check an authoritative source to know if a credential was issued by an authority. And the reason for a protocol? We want to make sure we avoid building proprietary solutions and rather work with the community to develop standards and protocols that can be used by any implementer.</p> <p>Inspiration for this protocol was taken from RFC 0113: Question Answer Protocol. We have gone beyond this protocol by adding structure to it, since we need a standard method for requesting for authorization related to credential issuance contexts.</p> <p>## Tutorial</p> <p>This RFC introduces a protocol for interacting with trust registries. The identifier for the message family used by this protocol is <code>trust-input</code>, and the fully qualified URI for its definition is: </p> <p>https://didcomm.org/trust-input/1.0</p> <p>## Roles</p> <p>There are two roles in the <code>trust-input</code> protocol: <code>requestor</code> and <code>trust-registry</code>. The <code>requestor</code> asks the <code>trust-registry</code> if credential metadata of a verifiable credential shared by a holder was issued by an authorized issuer, and the <code>trust-registry</code> responds with an answer. Any type of entity can be a requestor and inquire about the authority of an issuing entity. All the requests sent by the requestor are sent in a single message type, and the same is true for the response from the <code>trust-registry</code>.</p> <p>## States</p> <p>This is a classic two-step request~response interaction, so it uses the predefined state machines for any <code>requestor</code> and <code>trust-registry</code>:</p> <p></p> <p>## Messages</p> <p>### query Message Type</p> <p>A trust-input-protocol/query message looks like this:</p> <pre><code>{\n\"@type\": \"https://didcomm.org/trust-input/1.0/query\",\n    \"@id\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\",\n    \"query\": {\n            \"trust-task\":\"issuance\",\n            \"include-governance\":\"yes\",\n            \"credentialmetadata\":[\n                {\n                \"credential-id\": \"http://university.example/credentials/1872\",\n            \"credential-format\": \"1\",\n                \"issuer-did\": \"did:example:123456abcdef\"\n                }\n            ]\n        },\n    \"comment\": \"Please tell me if this issuer is authoritative to issue this credential type...\"\n}\n</code></pre> <p>The query message says, \u201c Please tell me if the issuer: \u2018did:example:123456abcdef\u2019 is authorized to issue the credential: \u2018http://university.example/credentials/1872\u2019. And please give me information about the governance framework that governs the trust registry operation.\u201d Please refer to the Localisation section below for further details.</p> <p>The <code>requestor</code> can send an array of issuers and credentials in their request to the trust registry. If they\u2019re seeking multiple trust inputs from a single trust registry, they can get them in a single request.</p> <p>The values for <code>credential-format</code> are:</p> <pre><code>1 = AnonCreds\n2 = JSON-LD\n3 = JWT\n</code></pre> <p>Additional formats can be supported and added to this above list.</p> <p>The credential field within the requestor\u2019s <code>query</code> may include a * wildcard. An example use of this could be \u201cI\u2019m interested in knowing all the credentials that this specific issuer is authorized to offer\u201d. This may be useful for discovery purposes.</p>"},{"location":"concepts/0781-trust-input-protocol/#response-message-type","title":"response Message Type","text":"<p>A trust-input/response message looks like this:</p> <pre><code>{ \n\"@type\": \"https://didcomm.org/trust-input/1.0/response\",\n\"~thread\": {\n        \"thid\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\" \n    },\n    \"governance\":\"http://university.example/governanceframework\",\n    \"response\":[    \n{\n            \"credential-id\": \"http://university.example/credentials/1872\",\n            \"status\": \"2\",\n            \"status_date\":\"yyyy'-'MM'-'dd'T'HH':'mm':'ss'.'fff'Z'\"\n            }\n    ]\n}\n</code></pre> <p>The <code>response</code> field is a JSON array of response support descriptor objects that matches the query. Each descriptor has a <code>credential-id</code> that contains a credential (fully qualified verifiable credential id), plus the current authoritative <code>status</code> of the credential issuer to issue said credential.</p> <p>The response returns the current status of the credential issuer(s) against their authority to issue credentials at the time of <code>query</code>.</p> <p>The values for <code>status</code> are:</p> <pre><code>1 = Not found\n2 = Valid\n3 = Expired (not renewed after the previous valid registration period) [when was it expired]\n4 = Terminated (voluntary termination by the registered party) [when was it terminated]\n5 = Revoked [when was it revoked]\n</code></pre> <p>For status values 3, 4, 5; the trust registry will return a date value of when that status became that value.</p> <p>A <code>query</code> which contains a *wildcard would return all the credentials offered by the issuer\u2019s DID. The date format returned in the response is a web UTC format. The date represents  the status changes of status values and the <code>requestor</code> can use that info to make their trust decision.</p>"},{"location":"concepts/0781-trust-input-protocol/#trust-registry-considerations","title":"Trust Registry Considerations","text":""},{"location":"concepts/0781-trust-input-protocol/#connection-establishment","title":"Connection Establishment","text":"<p>The connection between the <code>requestor</code> and the <code>trust-registry</code> is established via an out-of-band message sent to the <code>requestor</code>. Other connection methods such as RFC 0160 can also be used.</p>"},{"location":"concepts/0781-trust-input-protocol/#identifier","title":"Identifier","text":"<p><code>trust-registry</code> must have a resolvable Verifiable Identifier (VID).</p>"},{"location":"concepts/0781-trust-input-protocol/#governance","title":"Governance","text":"<p>The trust registries that an entity using this protocol will interact with should ensure their trust registries are aligned with the Trust over IP\u2019s Trust Registry Governance Framework.</p> <p>A governance document must be published to be able to respond to a request that asks for governance.</p>"},{"location":"concepts/0781-trust-input-protocol/#localization","title":"Localization","text":"<p>Because the <code>requestor</code> is being returned a status number to represent the status, the implementers can use this to localise it in the language of their choice and make it friendly to their application or user experience.</p> <p>The <code>query</code> message contains a <code>comment</code> field that is localizable. This field is optional and may not be often used, but when it is, it is to provide a human-friendly justification for the query. An agent that consults its master before answering a query could present the content of this field as an explanation of the request.</p> <p>All message types in this family thus have the following implicit decorator:</p> <pre><code>{\n\n\"~l10n\": {\n    \"locales\": { \"en\": [\"comment\"] },\n    \"catalogs\": [\"https://github.com/hyperledger/aries-rfcs../../features/trust-input/requestor/catalog.json\"]\n\n        }\n}\n</code></pre> <p>For more information, see the localization RFC.</p>"},{"location":"concepts/0781-trust-input-protocol/#open-topics","title":"Open Topics","text":"<ul> <li>How to implement using RFC 0434: Out-of-Band Protocol 1.1? We plan to leave this out of scope until a further version.</li> <li>Governance on how the credential id is entered into a trust registry will be required. And this is dependent on the credential format. So there will likely be a required field in the trust registry for credential format, which would then dictate how the credential id is entered. The format for the credential metadata in the trust registry must align with the format received by the <code>requestor</code>.</li> </ul>"},{"location":"concepts/0781-trust-input-protocol/#acknowledgements","title":"Acknowledgements","text":"<p>Although many people helped with the thinking behind this protocol, the authors would like to specifically thank these following people for their support and contributions:</p> <ul> <li> <p>British Columbia Government - Kyle Robinson and Nancy Norris</p> </li> <li> <p>CIRA - Jacques Latour and Jesse Carter</p> </li> <li> <p>Continuum Loop - Darrell O\u2019Donnell</p> </li> <li> <p>IDLab - Cosanna Preston-Idedia and Hadrien Seymour-Provencher</p> </li> <li> <p>Trust over IP\u2019s Trust Registry Task Force</p> </li> </ul>"},{"location":"concepts/0781-trust-input-protocol/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name/Link Implementation Notes nborbit.io Commercial trust task orchestration application built by Northern Block using Aries Cloud Agent Python (ACA-Py)."},{"location":"concepts/0799-long-term-support/","title":"0799: Aries Long Term Support Releases","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: PROPOSED</li> <li>Since: 2023-11-07 </li> <li>Start Date: 2023-11-07 </li> <li>Tags: concept</li> </ul> <p>Long Term Support Releases of Aries projects will assist those using the software to integrate within their development processes.</p>"},{"location":"concepts/0799-long-term-support/#motivation","title":"Motivation","text":"<p>Long Term Support releases allow stable use of projects without frequent code updates. Designating LTS releases frees projects to develop ../../features without worry of disrupting those seeking feature stable deployments. </p>"},{"location":"concepts/0799-long-term-support/#project-lts-releases","title":"Project LTS Releases","text":"<ul> <li>Details specific to each project will be found within the relevant repositories. </li> <li>Projects SHOULD create an LTS policy within the code repository for the project. </li> <li>Projects MAY alter any of these suggestions to match the needs of the project.</li> </ul>"},{"location":"concepts/0799-long-term-support/#lts-release-tagging","title":"LTS Release Tagging","text":"<ul> <li>No Specific version number scheme for LTS releases are set Aries-wide. Each project can use any version numbering they desire. Projects must have a way to indicate patch releases.</li> <li>The README.md file within each repository must indicate which version is an LTS release, with a link to the release or branch of the LTS</li> <li>Each LTS release MUST include detailed release notes detailing the changes from the last LTS release, including complex details or gotchas.</li> <li>It is recommended, when possible, to designate an LTS release when a project reaches compliance with an Interop Profile, including an AIP.</li> </ul>"},{"location":"concepts/0799-long-term-support/#lts-support-timeline","title":"LTS Support Timeline","text":"<ul> <li>Each LTS release MUST be supported for at least 9 months AFTER the next LTS release is designated.</li> <li>When the next LTS release is designated, the prior LTS release must clearly indicate the End of Support Date at least 9 months in future.</li> <li>A branch SHOULD be created to ease bugfixes and the maintenance of LTS patch releases.</li> <li>If a support term in excess of the minimum 9 months is chosen and and End of Support Date published, that period MUST be honored for that release.</li> <li>Projects may may designate an LTS release with any candance desired by the project.</li> <li>Frequent LTS relases may result in multiple LTS releases receiving support. Seeking community input for LTS release timing may decrease support efforts.</li> </ul>"},{"location":"concepts/0799-long-term-support/#lts-release-updates","title":"LTS Release Updates","text":"<ul> <li>Each LTS release MUST be updated for security updates via patch releases for the duration of its support lifetime.</li> <li>Each LTS release MAY include bugfixes that impact usability of the release.</li> <li>LTS patch releases MUST include detailed release notes.</li> <li>Updates MUST NOT include API updates, programatic interface changes, or major logic changes.</li> </ul>"},{"location":"concepts/0799-long-term-support/#references","title":"References","text":"<p>This policy is inspired by the Fabric LTS Policy https://hyperledger.github.io/fabric-rfcs/text/0005-lts-release-strategy.html</p>"},{"location":"concepts/0812-compression-dictionary/","title":"0812: Compressing DIDComm messages using dictionaries","text":"<ul> <li>Authors: Kim Ebert</li> <li>Status: PROPOSED</li> <li>Since: 2022-</li> <li>Status Note: Compression theory  </li> <li>Supersedes: </li> <li>Start Date: 2022-03-10</li> <li>Tags: concept</li> </ul>"},{"location":"concepts/0812-compression-dictionary/#summary","title":"Summary","text":"<p>Using Dictionary Compression, higher compression rates can be achieved for small messages with known entries.</p>"},{"location":"concepts/0812-compression-dictionary/#motivation","title":"Motivation","text":"<p>DIDComm messages contain well know values and are often short in size. Using dictionary based compression may reduce the overall size of messages that may be transmitted or stored.</p>"},{"location":"concepts/0812-compression-dictionary/#tutorial","title":"Tutorial","text":""},{"location":"concepts/0812-compression-dictionary/#training","title":"Training","text":"<p>The first step is to determine the type of data that needs to be provided for training, and generating a number of requests that meets that criteria.</p> <p>An example of creating such an invite using Aca-py and curl</p> <pre><code>curl -X POST \"http://127.0.0.1:8150/out-of-band/create-invitation\" -H \"accept: application/json\" -H \"Content-Type: application/json\" -d \"{ \\\"alias\\\": \\\"\\\", \\\"attachments\\\": [ ], \\\"handshake_protocols\\\": [ \\\"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0\\\" ], \\\"metadata\\\": {}, \\\"my_label\\\": \\\"\\\", \\\"use_public_did\\\": false}\"\n</code></pre> <p>Result:</p> <pre><code>{\"invitation_url\": \"https://localhost:443?oob=eyJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9vdXQtb2YtYmFuZC8xLjAvaW52aXRhdGlvbiIsICJAaWQiOiAiYTYwZDhlYTAtZDg1Zi00NDJkLTk0NTktZTk2NWEyYjg3Nzg1IiwgInNlcnZpY2VzIjogW3siaWQiOiAiI2lubGluZSIsICJ0eXBlIjogImRpZC1jb21tdW5pY2F0aW9uIiwgInJlY2lwaWVudEtleXMiOiBbImRpZDprZXk6ejZNa296SGNjNzI0ajlGOFJBR214bTFOY3hpVlhtOE10c0NMQ0paWktacWRwd0Z3Il0sICJyb3V0aW5nS2V5cyI6IFsiZGlkOmtleTp6Nk1rcTNycDg1cm1qTjRwdnN5WUpWTlZoVXZBNUJwTWFlNkd5MlBUUzVZaHdVelIiLCAiZGlkOmtleTp6Nk1rbnZwTmEzQXdWOHl6SHJaM0s3WXVDdU1adXBiSEt0ZDJwVDN4U3NzODRqenEiXSwgInNlcnZpY2VFbmRwb2ludCI6ICJodHRwczovL21lZGlhdG9yNC50ZXN0LmluZGljaW90ZWNoLmlvOjQ0MyJ9XSwgImhhbmRzaGFrZV9wcm90b2NvbHMiOiBbImRpZDpzb3Y6QnpDYnNOWWhNcmpIaXFaRFRVQVNIZztzcGVjL2RpZGV4Y2hhbmdlLzEuMCJdLCAibGFiZWwiOiAiTGFiIn0=\", \"invitation\": {\"@type\": \"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/out-of-band/1.0/invitation\", \"@id\": \"a60d8ea0-d85f-442d-9459-e965a2b87785\", \"services\": [{\"id\": \"#inline\", \"type\": \"did-communication\", \"recipientKeys\": [\"did:key:z6MkozHcc724j9F8RAGmxm1NcxiVXm8MtsCLCJZZKZqdpwFw\"], \"routingKeys\": [\"did:key:z6Mkq3rp85rmjN4pvsyYJVNVhUvA5BpMae6Gy2PTS5YhwUzR\", \"did:key:z6MknvpNa3AwV8yzHrZ3K7YuCuMZupbHKtd2pT3xSss84jzq\"], \"serviceEndpoint\": \"https://localhost:443\"}], \"handshake_protocols\": [\"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0\"], \"label\": \"Lab\"}, \"state\": \"initial\", \"trace\": false, \"invi_msg_id\": \"a60d8ea0-d85f-442d-9459-e965a2b87785\"}\n</code></pre> <p>We then extract the data required for the invitation.</p> <pre><code>{\"@type\": \"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/out-of-band/1.0/invitation\", \"@id\": \"2dbf6f36-8dc0-4b35-9558-dab26e3ae3c3\", \"services\": [{\"id\": \"#inline\", \"type\": \"did-communication\", \"recipientKeys\": [\"did:key:z6MkqfRyf4ycr6HFpo4XyhQp8gBwdBW51Z2yXnxg11AuFZT6\"], \"routingKeys\": [\"did:key:z6Mkq3rp85rmjN4pvsyYJVNVhUvA5BpMae6Gy2PTS5YhwUzR\", \"did:key:z6MknvpNa3AwV8yzHrZ3K7YuCuMZupbHKtd2pT3xSss84jzq\"], \"serviceEndpoint\": \"https://localhost:443\"}], \"handshake_protocols\": [\"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0\"], \"label\": \"Lab\"}\n</code></pre> <p>Finally, we strip out the keys that are specific to the local agent, leaving content that can easily be compressed.</p> <pre><code>{\"@type\": \"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/out-of-band/1.0/invitation\", \"@id:\": \"\", \"services\": [{\"id\": \"#inline\", \"type\": \"did-communication\", \"recipientKeys\": [\"did:key:\"], \"routingKeys\": [\"did:key:\", \"did:key:\"], \"serviceEndpoint\": \"https://:443\"}], \"handshake_protocols\": [\"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0\"], \"label\": \"Lab\"}\n</code></pre> <p>We do this a hundred or so times, and include other configuration options of interest. ( Research into what should be included here could provide some value )</p> <p>We then create the dictionary.</p> <pre><code>zstd --train ./data/* -o dict\n</code></pre> <p>This dictionary can now be used to compress the data before it is base64 encoded into the url.</p>"},{"location":"concepts/0812-compression-dictionary/#the-compressed-out-of-band-message","title":"The Compressed Out of Band Message","text":"<p>Using a unique url parameter for compressed out of band messages, the client can determine the alternative behavior to follow.</p> <p>The coob message includes the following binary data. The first 4 bytes indicate the dictary to be used, perhaps as an unsiged long. Or alternatively we could use a d= parameter for the storage of the dictionary id.</p> <p>Dictionary IDs would be used to indicate which dictionary the client should use. Occassionally, ARIES may release a new dictionary. This new dictionary should not be used for limited time to allow all clients to get the latest dictionaries. These dictionaries could be auto-retrieved by the clients when connection to the internet is available.</p> <p>The rest of the coob data is the a compressed zstd binary output. After the binary data is combined together, the data is base64url encoded.</p> <pre><code>https://localhost:443?c=sztd&amp;d=1&amp;oob=KLUv_Wc3PnoBMAG1BgBijCwjEIfWAzs-1Bd8YPpweoDAqvElxVlFB2t_B0mLRHdVVVVVwQ1ZRjAL7yxb-TIysjm8Ed-yTeWLF1qo8MlxiEaMtHI3fSrdFbppodFuTwhO6WsiVbU3ECY-bHpEdFBAg8QUpAG-8RKYVKWACeQ87VWx2H7qLWqW-QNtLAt11M6HIEmkxwYucGqk1akI2O1ABcPSONJHGQaQDJnr8mtWyfL4Ho4t6nhZ-XGX-8dUCIn_JQ8CCgCVXyJ1RAnO_AEwww7QY1FQCCwIETfkSRDzzwJ-R-kV6uOdbQ==\n</code></pre> <p>The URL is reduced from 794 bytes to 370 bytes.(46.6 % of original size) There difference in the QR codes can be seen below.</p> <p> </p>"},{"location":"concepts/0812-compression-dictionary/#redirect-on-failure","title":"Redirect on failure","text":"<p>If the client cannot decode the coob message, or does not have the appropriate dictionary, the client can visit the url and will be redirected to the decompressed url.</p>"},{"location":"concepts/0812-compression-dictionary/#dictionary-storage","title":"Dictionary Storage","text":"<p>Dictionaries could be stored along side the RFCs, or an alternative method for transfering dictionaries between clients could be derived.</p>"},{"location":"concepts/0812-compression-dictionary/#drawbacks","title":"Drawbacks","text":"<p>Dictionaries may need to be regularly rebuilt to adjust to new protocols. Some dictionaries may not provide any compression benefits depending upon the message.</p>"},{"location":"concepts/0812-compression-dictionary/#rationale-and-alternatives","title":"Rationale and alternatives","text":""},{"location":"concepts/0812-compression-dictionary/#qr-code-quality","title":"QR Code Quality","text":"<p>By reducing the size of QR codes for offline or cases where URL redirects are not available, the QR code becomes more manageable.</p>"},{"location":"concepts/0812-compression-dictionary/#reducing-need-for-redirect-support","title":"Reducing need for redirect support","text":"<p>URL Shorterning services may introduce privacy concerns</p>"},{"location":"concepts/0812-compression-dictionary/#binary-based-format","title":"Binary based format","text":"<p>Instead of using compression, a binary file format would reduce overall message size.</p>"},{"location":"concepts/0812-compression-dictionary/#standard-compression-without-dictionaries","title":"Standard Compression without dictionaries","text":""},{"location":"concepts/0812-compression-dictionary/#gzip","title":"gzip","text":"<p>Using</p> <pre><code>gzip -9\n</code></pre> <p>We can reduce the size of the Out of Band invitation.</p> <pre><code>https://localhost:443?c=gzip&amp;oob=H4sICODx-mUCA3RtcC50eHQAhZFdb5swFIbv9ysqdjtCykdC2E3TbC1qCpqaDy1M02Ts03CSYDvYkEDV_z6cTVsvJu3a5338nPO-WDe6lWBFVxZDFinRRLfdLFfppkiqXYzH7NNyNV3E249KAnVErW3xbOeEM-d6MHSQN6iJRsGtD1fWDTIDIqMhC4EMbRYGz7bvu8ye-MHEhskoIG4ejsdhYMYVVA1SUH3m24v1K_se-QE5mOc3XjYVZVlzpH--qoCiROB6Du0FcNHfQxt1o2QvupjSsevvJnfh0_S-PJfXKT3j-msZJlrNHmcPWTbPjkye7k7Wd4PrF0O-_Sfs6FUyDKpyl_qyUe3mYZ2ui1UzDW5lQmB037pflotgU5xW3ZNRe5vljUyJNz2tw7aLq8ybjzf1rE6yWubxXDNXLr3zQqnQ33XHi8jvm3zmTArk2uxfaC1V5DglMCRaVP5Ag9ID5AwpCg20GKCIfN-zXg2h6LtRBdnDD1kJLag4_F3pf_X2M3CmPWELpt6L0YHkcDAejyS3Xt_9BC2pH8MxAgAA\n</code></pre> <p>Using gzip, we can reduce the size of the Out of Band invitation from 775 bytes to 590 bytes. (76.13 % of original size)</p>"},{"location":"concepts/0812-compression-dictionary/#zstd-without-a-dictionary","title":"ZSTD without a dictionary","text":"<p>Using</p> <pre><code>zstd -9\n</code></pre> <p>We can reduce the size of the Out of Band invitation.</p> <pre><code>https://localhost:443?c=zstd&amp;oob=KLUv_WQxAW0MAPbYVCjgzMwDaJPAFkV01uPxaHNM71pq1L8QfLwg044FcGs2cBMMwwwjDC8ESQBJAE4AEMhKUkIT1LRQg_q0DQe1XxAXAvHi33T_dz9qMAYie6kGTWBoeziqnjVBxqJELJWDrPOWprs2DKY1SWhQfVhX9m1cVNEzuAsiRQsSBone1-QeLv-p2AD34RQiDjMBopHSo1YrxJvLEVagb0Cf7Oufv3pX_3ochyvk9zn3AyIFxKKK2ut_nWtqPh5TkyjlgDgEoWSa8pkqWbJ7YmnZyy5P4mEekynrrBCcF09kolj-rkNo8WwYilJpkEAFh9MrG1CRz7JdsMsCBtRflpiG66iZu6mTub89HBE9CZ5sO9kkywIAFVGjDBzXKMczl2714_YtB1e8cZclfEM3bS_dKuIkZYWfsVXf-Ovb-4ytfTNkhzd961wUVTrvve37ONuLEBE7oUZOHRQgMMKgpQeLQytzAcvFxYE1CCvGeoAVfTFYf7zoaWmohyZtK6wtoqCuRTa3JQrbbxSl8RATCDPtnYPf\n</code></pre> <p>Using zstd without a dictionary, we can reduce the Out of Band invitation from 775 bytes to 582 bytes. (75.10 % of original size)</p>"},{"location":"concepts/0812-compression-dictionary/#didcomm-compression","title":"DIDComm Compression","text":"<p>It would be possible to use compression in DIDComm communications. Each message would be compressed individually, as DIDComm doesn't guarentee the order of messages being delievered.</p> <p>Things to consider</p> <ul> <li>Compress may not want to be used until Discover ../../features is shared</li> <li>It may be possible to sharing custom dictionaries as a separate protocol</li> </ul>"},{"location":"concepts/0812-compression-dictionary/#process-of-creating-new-dictionaries","title":"Process of creating new dictionaries","text":"<p>To be defined</p>"},{"location":"concepts/0812-compression-dictionary/#distribution-of-dictionaries","title":"Distribution of dictionaries","text":"<p>If dictionaries are used, they should be included in DIDComm libraries The dictionaries may be a dependency of a DIDComm library</p>"},{"location":"concepts/0812-compression-dictionary/#prior-art","title":"Prior art","text":"<p>[zstd] (http://facebook.github.io/zstd/) zstd manual brotli zlib DEFLATE</p>"},{"location":"concepts/0812-compression-dictionary/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Where are dictionaries stored</li> <li>How do we specify compression will be used for DIDComm messages</li> <li>What to do when a client doesn't support compression.</li> </ul>"},{"location":"concepts/0812-compression-dictionary/#implementations","title":"Implementations","text":"<p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0015-acks/","title":"Aries RFC 0015: ACKs","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Broadly implemented, adopted into many protocols and part of AIP 1 and 2.</li> <li>Start Date: 2018-12-26</li> <li>Tags: feature</li> </ul>"},{"location":"features/0015-acks/#summary","title":"Summary","text":"<p>Explains how one party can send acknowledgment messages (ACKs) to confirm receipt and clarify the status of complex processes.</p>"},{"location":"features/0015-acks/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> <li>20220322: Clarification that an Ack <code>Fail</code> must not be used, and that a Report Problem must be used in its place. Remove Ack <code>Fail</code> from the RFC.</li> <li>20200325: In the ~thread decorator section of the sample in the Explicit ACKs section, 'myindex' was changed to 'sender_order' and 'lrecs' to 'received_orders'. This is in accordance with the field names as defined in RFC 0008.</li> </ul>"},{"location":"features/0015-acks/#motivation","title":"Motivation","text":"<p>An acknowledgment or ACK is one of the most common procedures in protocols of all types. We need a flexible, powerful, and easy way to send such messages in agent-to-agent interactions.</p>"},{"location":"features/0015-acks/#tutorial","title":"Tutorial","text":"<p>Confirming a shared understanding matters whenever independent parties interact. We buy something on Amazon; moments later, our email client chimes to tell us of a new message with subject \"Thank you for your recent order.\" We verbally accept a new job, but don't rest easy until we've also emailed the signed offer letter back to our new boss. We change a password on an online account, and get a text at our recovery phone number so both parties know the change truly originated with the account's owner.</p> <p>When formal acknowledgments are missing, we get nervous. And rightfully so; most of us have a story of a package that was lost in the mail, or a web form that didn't submit the way we expected.</p> <p>Agents interact in very complex ways. They may use multiple transport mechanisms, across varied protocols, through long stretches of time. While we usually expect messages to arrive as sent, and to be processed as expected, a vital tool in the agent communication repertoire is the receipt of acknowledgments to confirm a shared understanding.</p>"},{"location":"features/0015-acks/#implicit-acks","title":"Implicit ACKs","text":"<p>Message threading includes a lightweight, automatic sort of ACK in the form of the <code>~thread.received_orders</code> field. This allows Alice to report that she has received Bob's recent message that had <code>~thread.sender_order</code> = N. We expect threading to be best practice in many use cases, and we expect interactions to often happen reliably enough and quickly enough that implicit ACKs provide high value. If you are considering ACKs but are not familiar with that mechanism, make sure you understand it, first. This RFC offers a supplement, not a replacement.</p>"},{"location":"features/0015-acks/#explicit-acks","title":"Explicit ACKs","text":"<p>Despite the goodness of implicit ACKs, there are many circumstances where a reply will not happen immediately. Explicit ACKs can be vital here.</p> <p>Explicit ACKS may also be vital at the end of an interaction, when work is finished: a credential has been issued, a proof has been received, a payment has been made. In such a flow, an implicit ACK meets the needs of the party who received the final message, but the other party may want explicit closure. Otherwise they can't know with confidence about the final outcome of the flow.</p> <p>Rather than inventing a new \"interaction has been completed successfully\" message for each protocol, an all-purpose <code>ack</code> message type is recommended. It looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/notification/1.0/ack\",\n  \"@id\": \"06d474e0-20d3-4cbf-bea6-6ba7e1891240\",\n  \"status\": \"OK\",\n  \"~thread\": {\n    \"thid\": \"b271c889-a306-4737-81e6-6b2f2f8062ae\",\n    \"sender_order\": 4,\n    \"received_orders\": {\"did:sov:abcxyz\": 3}\n  }\n}\n</code></pre> <p>It may also be appropriate to send an ack at other key points in an interaction (e.g., when a key rotation notice is received).</p>"},{"location":"features/0015-acks/#adopting-acks","title":"Adopting acks","text":"<p>As discussed in 0003: Protocols, a protocol can adopt the ack message into its own namespace. This allows the type of an ack to change from:     <code>https://didcomm.org/notification/1.0/ack</code> to something like:     <code>https://didcomm.org/otherProtocol/2.0/ack</code>. Thus, message routing logic can see the ack as part of the other protocol, and send it to the relevant handler--but still have all the standardization of generic acks.</p>"},{"location":"features/0015-acks/#ack-status","title":"ack status","text":"<p>The <code>status</code> field in an ack tells whether the ack is final or not with respect to the message being acknowledged. It has 2 predefined values: <code>OK</code> (which means an outcome has occurred, and it was positive); and <code>PENDING</code>, which acknowledges that no outcome is yet known.</p> <p>There is not an ack <code>status</code> of <code>FAIL</code>. In the case of a protocol failure a Report Problem message must be used to inform the other party(ies). For more details, see the next section.</p> <p>In addition, more advanced ack usage is possible. See the details in the Reference section.</p>"},{"location":"features/0015-acks/#relationship-to-problem-report","title":"Relationship to <code>problem-report</code>","text":"<p>Negative outcomes do not necessarily mean that something bad happened; perhaps Alice comes to hope that Bob rejects her offer to buy his house because she's found something better--and Bob does that, without any error occurring. This is not a FAIL in a problem sense; it's a FAIL in the sense that the offer to buy did not lead to the outcome Alice intended when she sent it.</p> <p>This raises the question of errors. Any time an unexpected problem arises, best practice is to report it to the sender of the message that triggered the problem. This is the subject of the problem reporting mechanism.</p> <p>A <code>problem_report</code> is inherently a sort of ACK. In fact, the <code>ack</code> message type and the <code>problem_report</code> message type are both members of the same <code>notification</code> message family. Both help a sender learn about status. Therefore, a requirement for an <code>ack</code> is that a status of <code>FAIL</code> be satisfied by a <code>problem_report</code> message.</p> <p>However, there is some subtlety in the use of the two types of messages. Some <code>ack</code>s may be sent before a final outcome, so a final <code>problem_report</code> may not be enough. As well, an ack request may be sent after a previous <code>ack</code> or <code>problem_report</code> was lost in transit. Because of these caveats, developers whose code creates or consumes acks should be thoughtful about where the two message types overlap, and where they do not. Carelessness here is likely to cause subtle, hard-to-duplicate surprises from time to time.</p>"},{"location":"features/0015-acks/#custom-acks","title":"Custom ACKs","text":"<p>This mechanism cannot address all possible ACK use cases. Some ACKs may require custom data to be sent, and some acknowledgment schemes may be more sophisticated or fine-grained that the simple settings offered here. In such cases, developers should write their own ACK message type(s) and maybe their own decorators. However, reusing the field names and conventions in this RFC may still be desirable, if there is significant overlap in the ../../concepts.</p>"},{"location":"features/0015-acks/#reference","title":"Reference","text":""},{"location":"features/0015-acks/#ack-message","title":"<code>ack</code> message","text":""},{"location":"features/0015-acks/#status","title":"<code>status</code>","text":"<p>Required, values <code>OK</code> or <code>PENDING</code>. As discussed above, this tells whether the ack is final or not with respect to the message being acknowledged.</p>"},{"location":"features/0015-acks/#threadthid","title":"<code>~thread.thid</code>","text":"<p>Required. This links the <code>ack</code> back to the message that requested it.</p> <p>All other fields in an <code>ack</code> are present or absent per requirements of ordinary messages.</p>"},{"location":"features/0015-acks/#drawbacks-and-alternatives","title":"Drawbacks and Alternatives","text":"<p>None identified.</p>"},{"location":"features/0015-acks/#prior-art","title":"Prior art","text":"<p>See notes above about the implicit ACK mechanism in <code>~thread.received_orders</code>.</p>"},{"location":"features/0015-acks/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Muliplexed acks. How do you supply an ACK to all of Alice's agents instead of just to the one who involved in the current protocol?</li> </ul>"},{"location":"features/0015-acks/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes RFC 0036: Issue Credential Protocol ACKs are adopted by this protocol. RFC 0037: Present Proof Protocol ACKs are adopted by this protocol. RFC 0193: Coin Flip Protocol ACKs are adopted as a subprotocol. Aries Cloud Agent - Python Contributed by the Government of British Columbia."},{"location":"features/0019-encryption-envelope/","title":"Aries RFC 0019: Encryption Envelope","text":"<ul> <li>Authors: Kyle Den Hartog, Stephen Curran, Sam Curren, Mike Lodder</li> <li>Status: ADOPTED</li> <li>Since: 2019-05-04</li> <li>Status Note:  </li> <li>Supersedes: INDY 0028 Wire Level Format</li> <li>Start Date: 2018-07-10 (approximate, backdated)</li> <li>Tags: feature</li> </ul>"},{"location":"features/0019-encryption-envelope/#summary","title":"Summary","text":"<p>There are two layers of messages that combine to enable interoperable self-sovereign agent-to-agent communication. At the highest level are DIDComm Plaintext Messages - messages sent between identities to accomplish some shared goal (e.g., establishing a connection, issuing a verifiable credential, sharing a chat). DIDComm Plaintext Messages are delivered via the second, lower layer of messaging - DIDComm Encrypted Envelopes. A DIDComm Encrypted Envelope is a wrapper (envelope) around a plaintext message to permit secure sending and routing. A plaintext message going from its sender to its receiver passes through many agents, and an encryption envelope is used for each hop of the journey.</p> <p>This RFC describes the DIDComm Encrypted Envelope format and the <code>pack()</code> and <code>unpack()</code> functions that implement this format.</p>"},{"location":"features/0019-encryption-envelope/#motivation","title":"Motivation","text":"<p>Encryption envelopes use a standard format built on JSON Web Encryption - RFC 7516. This format is not captive to Aries; it requires no special Aries worldview or Aries dependencies to implement. Rather, it is a general-purpose solution to the question of how to encrypt, decrypt, and route messages as they pass over any transport(s). By documenting the format here, we hope to provide a point of interoperability for developers of agents inside and outside the Aries ecosystem.</p> <p>We also document how Aries implements its support for the DIDComm Encrypted Envelope format through the <code>pack()</code> and <code>unpack()</code> functions. For developers of Aries, this is a sort of design doc; for those who want to implement the format in other tech stacks, it may be a useful reference.</p>"},{"location":"features/0019-encryption-envelope/#tutorial","title":"Tutorial","text":""},{"location":"features/0019-encryption-envelope/#assumptions","title":"Assumptions","text":"<p>We assume that each sending agent knows:</p> <ul> <li>Its intended recipient(s).</li> <li>What encryption (if any) is appropriate.</li> <li>If encryption will be used, a public key of the receiving agent.</li> <li>The physical endpoint to use for the receiver, and the appropriate transport protocol (https, zmq, etc.).</li> </ul> <p>The assumptions can be made because either the message is being sent to an agent within the sending agent's domain and so the sender knows the internal configuration of agents, or the message is being sent outside the sending agent's domain and interoperability requirements are in force to define the sending agent's behaviour.</p>"},{"location":"features/0019-encryption-envelope/#example-scenario","title":"Example Scenario","text":"<p>The example of Alice and Bob's sovereign domains is used for illustrative purposes in defining this RFC.</p> <p></p> <p>In the diagram above:</p> <ul> <li>Alice has</li> <li>1 Edge agent - \"1\"</li> <li>1 Routing agent - \"2\"</li> <li>1 Domain Endpoint - \"8\"</li> <li>Bob has</li> <li>3 Edge Agents - \"4\", \"5\" and \"6\"<ul> <li>\"6\" is an Edge agent in the cloud, \"4\" and \"5\" are physical devices.</li> </ul> </li> <li>1 Routing agent - \"3\"</li> <li>1 Domain Endpoint - \"9\"</li> </ul> <p>For the purposes of this discussion we are defining the Encryption Envelope agent message flow to be:</p> <p>1 \u2192 2 \u2192 8 \u2192 9 \u2192 3 \u2192 4</p> <p>However, that flow is just one of several that could match this configuration. What we know for sure is that:</p> <ul> <li>1 is the Sender agent in this case and so must send the first or original message.</li> <li>9 is the Domain Endpoint of Bob's domain and so must receive the message as an Encrypted Envelope.</li> <li>4 is the Receiver in this case and so must receive (and should be able to read) the first or original message.</li> </ul>"},{"location":"features/0019-encryption-envelope/#encrypted-envelopes","title":"Encrypted Envelopes","text":"<p>An encrypted envelope is used to transport any plaintext message from one agent directly to another. In our example message flow above, there are five encrypted envelopes sent, one for each hop in the flow. The process to send an encrypted envelope consists of the following steps:</p> <ul> <li>Call the standard function <code>pack()</code> to wrap the plaintext message</li> <li>Send the encrypted envelope using the transport protocol defined by the receiving endpoint</li> <li>Receive the encrypted envelope</li> <li>Call the standard function <code>unpack()</code> to retrieve the plaintext message (and possibly its provenance) from the encrypted envelope</li> </ul> <p>This is repeated with each hop, but the encrypted envelopes are nested, such that the plaintext is never visible until it reaches its final recipient.</p>"},{"location":"features/0019-encryption-envelope/#implementation","title":"Implementation","text":"<p>We will describe the pack and unpack algorithms, and their output, in terms of Aries' initial implementation, which may evolve over time. Other implementations could be built, but they would need to emit and consume similar inputs and outputs.</p> <p>The data structures emitted and consumed by these algorithms are described in a formal schema.</p>"},{"location":"features/0019-encryption-envelope/#authcrypt-mode-vs-anoncrypt-mode","title":"Authcrypt mode vs. Anoncrypt mode","text":"<p>When packing and unpacking are done in a way that the sender is anonymous, we say that we are in anoncrypt mode. When the sender is revealed, we are in authcrypt mode. Authcrypt mode reveals the sender to the recipient only; it is not the same as a non-repudiable signature. See the RFC about non-repudiable signatures, and this discussion about the theory of non-repudiation.</p>"},{"location":"features/0019-encryption-envelope/#pack-message","title":"Pack Message","text":""},{"location":"features/0019-encryption-envelope/#pack_message-interface","title":"pack_message() interface","text":"<p>packed_message = pack_message(wallet_handle, message, receiver_verkeys, sender_verkey)</p>"},{"location":"features/0019-encryption-envelope/#pack_message-params","title":"pack_message() Params:","text":"<ul> <li>wallet_handle: handle to the wallet that contains the sender's secrets.</li> <li>message: the message (plaintext, or nested encrypted envelope) as a string. If it's JSON object it should be in string format first</li> <li>receiver_verkeys: a list of recipient verkeys as string containing a JSON array</li> <li>sender_verkey: the sender's verkey as a string. This verkey is used to look up the sender's private key so the wallet can put supply it as input to the encryption algorithm. When an empty string (\"\") is passed in this parameter, anoncrypt mode is used</li> </ul>"},{"location":"features/0019-encryption-envelope/#pack_message-return-value-authcrypt-mode","title":"pack_message() return value (Authcrypt mode)","text":"<p>This is an example of an outputted message encrypting for two verkeys using Authcrypt.</p> <pre><code>{\n    \"protected\": \"eyJlbmMiOiJ4Y2hhY2hhMjBwb2x5MTMwNV9pZXRmIiwidHlwIjoiSldNLzEuMCIsImFsZyI6IkF1dGhjcnlwdCIsInJlY2lwaWVudHMiOlt7ImVuY3J5cHRlZF9rZXkiOiJMNVhEaEgxNVBtX3ZIeFNlcmFZOGVPVEc2UmZjRTJOUTNFVGVWQy03RWlEWnl6cFJKZDhGVzBhNnFlNEpmdUF6IiwiaGVhZGVyIjp7ImtpZCI6IkdKMVN6b1d6YXZRWWZOTDlYa2FKZHJRZWpmenRONFhxZHNpVjRjdDNMWEtMIiwiaXYiOiJhOEltaW5zdFhIaTU0X0otSmU1SVdsT2NOZ1N3RDlUQiIsInNlbmRlciI6ImZ0aW13aWlZUkc3clJRYlhnSjEzQzVhVEVRSXJzV0RJX2JzeERxaVdiVGxWU0tQbXc2NDE4dnozSG1NbGVsTThBdVNpS2xhTENtUkRJNHNERlNnWkljQVZYbzEzNFY4bzhsRm9WMUJkREk3ZmRLT1p6ckticUNpeEtKaz0ifX0seyJlbmNyeXB0ZWRfa2V5IjoiZUFNaUQ2R0RtT3R6UkVoSS1UVjA1X1JoaXBweThqd09BdTVELTJJZFZPSmdJOC1ON1FOU3VsWXlDb1dpRTE2WSIsImhlYWRlciI6eyJraWQiOiJIS1RBaVlNOGNFMmtLQzlLYU5NWkxZajRHUzh1V0NZTUJ4UDJpMVk5Mnp1bSIsIml2IjoiRDR0TnRIZDJyczY1RUdfQTRHQi1vMC05QmdMeERNZkgiLCJzZW5kZXIiOiJzSjdwaXU0VUR1TF9vMnBYYi1KX0pBcHhzYUZyeGlUbWdwWmpsdFdqWUZUVWlyNGI4TVdtRGR0enAwT25UZUhMSzltRnJoSDRHVkExd1Z0bm9rVUtvZ0NkTldIc2NhclFzY1FDUlBaREtyVzZib2Z0d0g4X0VZR1RMMFE9In19XX0=\",\n    \"iv\": \"ZqOrBZiA-RdFMhy2\",\n    \"ciphertext\": \"K7KxkeYGtQpbi-gNuLObS8w724mIDP7IyGV_aN5AscnGumFd-SvBhW2WRIcOyHQmYa-wJX0MSGOJgc8FYw5UOQgtPAIMbSwVgq-8rF2hIniZMgdQBKxT_jGZS06kSHDy9UEYcDOswtoLgLp8YPU7HmScKHSpwYY3vPZQzgSS_n7Oa3o_jYiRKZF0Gemamue0e2iJ9xQIOPodsxLXxkPrvvdEIM0fJFrpbeuiKpMk\",\n    \"tag\": \"kAuPl8mwb0FFVyip1omEhQ==\"\n}\n</code></pre> <p>The base64URL encoded <code>protected</code> decodes to this: <pre><code>{\n    \"enc\": \"xchacha20poly1305_ietf\",\n    \"typ\": \"JWM/1.0\",\n    \"alg\": \"Authcrypt\",\n    \"recipients\": [\n        {\n            \"encrypted_key\": \"L5XDhH15Pm_vHxSeraY8eOTG6RfcE2NQ3ETeVC-7EiDZyzpRJd8FW0a6qe4JfuAz\",\n            \"header\": {\n                \"kid\": \"GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL\",\n                \"iv\": \"a8IminstXHi54_J-Je5IWlOcNgSwD9TB\",\n                \"sender\": \"ftimwiiYRG7rRQbXgJ13C5aTEQIrsWDI_bsxDqiWbTlVSKPmw6418vz3HmMlelM8AuSiKlaLCmRDI4sDFSgZIcAVXo134V8o8lFoV1BdDI7fdKOZzrKbqCixKJk=\"\n            }\n        },\n        {\n            \"encrypted_key\": \"eAMiD6GDmOtzREhI-TV05_Rhippy8jwOAu5D-2IdVOJgI8-N7QNSulYyCoWiE16Y\",\n            \"header\": {\n                \"kid\": \"HKTAiYM8cE2kKC9KaNMZLYj4GS8uWCYMBxP2i1Y92zum\",\n                \"iv\": \"D4tNtHd2rs65EG_A4GB-o0-9BgLxDMfH\",\n                \"sender\": \"sJ7piu4UDuL_o2pXb-J_JApxsaFrxiTmgpZjltWjYFTUir4b8MWmDdtzp0OnTeHLK9mFrhH4GVA1wVtnokUKogCdNWHscarQscQCRPZDKrW6boftwH8_EYGTL0Q=\"\n            }\n        }\n    ]\n}\n</code></pre></p>"},{"location":"features/0019-encryption-envelope/#pack-output-format-authcrypt-mode","title":"pack output format (Authcrypt mode)","text":"<pre><code>    {\n        \"protected\": \"b64URLencoded({\n            \"enc\": \"xchachapoly1305_ietf\",\n            \"typ\": \"JWM/1.0\",\n            \"alg\": \"Authcrypt\",\n            \"recipients\": [\n                {\n                    \"encrypted_key\": base64URLencode(libsodium.crypto_box(my_key, their_vk, cek, cek_iv))\n                    \"header\": {\n                          \"kid\": \"base58encode(recipient_verkey)\",\n                           \"sender\" : base64URLencode(libsodium.crypto_box_seal(their_vk, base58encode(sender_vk)),\n                            \"iv\" : base64URLencode(cek_iv)\n                }\n            },\n            ],\n        })\",\n        \"iv\": &lt;b64URLencode(iv)&gt;,\n        \"ciphertext\": b64URLencode(encrypt_detached({'@type'...}, protected_value_encoded, iv, cek),\n        \"tag\": &lt;b64URLencode(tag)&gt;\n    }\n</code></pre>"},{"location":"features/0019-encryption-envelope/#authcrypt-pack-algorithm","title":"Authcrypt pack algorithm","text":"<ol> <li>generate a content encryption key (symmetrical encryption key)</li> <li>encrypt the CEK for each recipient's public key using Authcrypt (steps below)<ol> <li>set <code>encrypted_key</code> value to base64URLencode(libsodium.crypto_box(my_key, their_vk, cek, cek_iv))<ul> <li>Note it this step we're encrypting the cek, so it can be decrypted by the recipient</li> </ul> </li> <li>set <code>sender</code> value to base64URLencode(libsodium.crypto_box_seal(their_vk, sender_vk_string))<ul> <li>Note in this step we're encrypting the sender_verkey to protect sender anonymity</li> </ul> </li> <li>base64URLencode(cek_iv) and set to <code>iv</code> value in the header<ul> <li>Note the cek_iv in the header is used for the <code>encrypted_key</code> where as <code>iv</code> is for ciphertext</li> </ul> </li> </ol> </li> <li>base64URLencode the <code>protected</code> value</li> <li>encrypt the <code>message</code> using libsodium.crypto_aead_chacha20poly1305_ietf_encrypt_detached(message, protected_value_encoded, iv, cek) this is the ciphertext.</li> <li>base64URLencode the iv, ciphertext, and tag then serialize the format into the output format listed above.</li> </ol> <p>For a reference implementation, see https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/commands/crypto.rs</p>"},{"location":"features/0019-encryption-envelope/#pack_message-return-value-anoncrypt-mode","title":"pack_message() return value (Anoncrypt mode)","text":"<p>This is an example of an outputted message encrypted for two verkeys using Anoncrypt.</p> <pre><code>{\n    \"protected\": \"eyJlbmMiOiJ4Y2hhY2hhMjBwb2x5MTMwNV9pZXRmIiwidHlwIjoiSldNLzEuMCIsImFsZyI6IkFub25jcnlwdCIsInJlY2lwaWVudHMiOlt7ImVuY3J5cHRlZF9rZXkiOiJYQ044VjU3UTF0Z2F1TFcxemdqMVdRWlEwV0RWMFF3eUVaRk5Od0Y2RG1pSTQ5Q0s1czU4ZHNWMGRfTlpLLVNNTnFlMGlGWGdYRnZIcG9jOGt1VmlTTV9LNWxycGJNU3RqN0NSUHNrdmJTOD0iLCJoZWFkZXIiOnsia2lkIjoiR0oxU3pvV3phdlFZZk5MOVhrYUpkclFlamZ6dE40WHFkc2lWNGN0M0xYS0wifX0seyJlbmNyeXB0ZWRfa2V5IjoiaG5PZUwwWTl4T3ZjeTVvRmd0ZDFSVm05ZDczLTB1R1dOSkN0RzRsS3N3dlljV3pTbkRsaGJidmppSFVDWDVtTU5ZdWxpbGdDTUZRdmt2clJEbkpJM0U2WmpPMXFSWnVDUXY0eVQtdzZvaUE9IiwiaGVhZGVyIjp7ImtpZCI6IjJHWG11Q04ySkN4U3FNUlZmdEJITHhWSktTTDViWHl6TThEc1B6R3FRb05qIn19XX0=\",\n    \"iv\": \"M1GneQLepxfDbios\",\n    \"ciphertext\": \"iOLSKIxqn_kCZ7Xo7iKQ9rjM4DYqWIM16_vUeb1XDsmFTKjmvjR0u2mWFA48ovX5yVtUd9YKx86rDVDLs1xgz91Q4VLt9dHMOfzqv5DwmAFbbc9Q5wHhFwBvutUx5-lDZJFzoMQHlSAGFSBrvuApDXXt8fs96IJv3PsL145Qt27WLu05nxhkzUZz8lXfERHwAC8FYAjfvN8Fy2UwXTVdHqAOyI5fdKqfvykGs6fV\",\n    \"tag\": \"gL-lfmD-MnNj9Pr6TfzgLA==\"\n}\n</code></pre> <p>The protected data decodes to this:</p> <pre><code>{\n    \"enc\": \"xchacha20poly1305_ietf\",\n    \"typ\": \"JWM/1.0\",\n    \"alg\": \"Anoncrypt\",\n    \"recipients\": [\n        {\n            \"encrypted_key\": \"XCN8V57Q1tgauLW1zgj1WQZQ0WDV0QwyEZFNNwF6DmiI49CK5s58dsV0d_NZK-SMNqe0iFXgXFvHpoc8kuViSM_K5lrpbMStj7CRPskvbS8=\",\n            \"header\": {\n                \"kid\": \"GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL\"\n            }\n        },\n        {\n            \"encrypted_key\": \"hnOeL0Y9xOvcy5oFgtd1RVm9d73-0uGWNJCtG4lKswvYcWzSnDlhbbvjiHUCX5mMNYulilgCMFQvkvrRDnJI3E6ZjO1qRZuCQv4yT-w6oiA=\",\n            \"header\": {\n                \"kid\": \"2GXmuCN2JCxSqMRVftBHLxVJKSL5bXyzM8DsPzGqQoNj\"\n            }\n        }\n    ]\n}\n</code></pre>"},{"location":"features/0019-encryption-envelope/#pack-output-format-anoncrypt-mode","title":"pack output format (Anoncrypt mode)","text":"<pre><code>    {\n         \"protected\": \"b64URLencoded({\n            \"enc\": \"xchachapoly1305_ietf\",\n            \"typ\": \"JWM/1.0\",\n            \"alg\": \"Anoncrypt\",\n            \"recipients\": [\n                {\n                    \"encrypted_key\": base64URLencode(libsodium.crypto_box_seal(their_vk, cek)),\n                    \"header\": {\n                        \"kid\": base58encode(recipient_verkey),\n                    }\n                },\n            ],\n         })\",\n         \"iv\": b64URLencode(iv),\n         \"ciphertext\": b64URLencode(encrypt_detached({'@type'...}, protected_value_encoded, iv, cek),\n         \"tag\": b64URLencode(tag)\n    }\n</code></pre>"},{"location":"features/0019-encryption-envelope/#anoncrypt-pack-algorithm","title":"Anoncrypt pack algorithm","text":"<ol> <li>generate a content encryption key (symmetrical encryption key)</li> <li>encrypt the CEK for each recipient's public key using Anoncrypt (steps below)<ol> <li>set <code>encrypted_key</code> value to base64URLencode(libsodium.crypto_box_seal(their_vk, cek))<ul> <li>Note it this step we're encrypting the cek, so it can be decrypted by the recipient</li> </ul> </li> </ol> </li> <li>base64URLencode the <code>protected</code> value</li> <li>encrypt the message using libsodium.crypto_aead_chacha20poly1305_ietf_encrypt_detached(message, protected_value_encoded, iv, cek) this is the ciphertext.</li> <li>base64URLencode the iv, ciphertext, and tag then serialize the format into the output format listed above.</li> </ol> <p>For a reference implementation, see https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/commands/crypto.rs</p>"},{"location":"features/0019-encryption-envelope/#unpack-message","title":"Unpack Message","text":""},{"location":"features/0019-encryption-envelope/#unpack_message-interface","title":"unpack_message() interface","text":"<p>unpacked_message = unpack_message(wallet_handle, jwe)</p>"},{"location":"features/0019-encryption-envelope/#unpack_message-params","title":"unpack_message() Params","text":"<ul> <li>wallet_handle: wallet handle that contains the sender_verkey</li> <li>jwe: a message which was returned from a pack_message() and follows the scheme format described below</li> </ul>"},{"location":"features/0019-encryption-envelope/#unpack-algorithm","title":"Unpack Algorithm","text":"<ol> <li>seralize data, so it can be used<ul> <li>For example, in rust-lang this has to be seralized as a struct.</li> </ul> </li> <li>Lookup the <code>kid</code> for each recipient in the wallet to see if the wallet possesses a private key associated with the public key listed</li> <li>Check if a <code>sender</code> field is used.<ul> <li>If a sender is included use auth_decrypt to decrypt the <code>encrypted_key</code> by doing the following:<ol> <li>decrypt sender verkey using libsodium.crypto_box_seal_open(my_private_key, base64URLdecode(sender))</li> <li>decrypt cek using libsodium.crypto_box_open(my_private_key, sender_verkey, encrypted_key, cek_iv)</li> <li>decrypt ciphertext using libsodium.crypto_aead_chacha20poly1305_ietf_open_detached(base64URLdecode(ciphertext_bytes), base64URLdecode(protected_data_as_bytes), base64URLdecode(nonce), cek)</li> <li>return <code>message</code>, <code>recipient_verkey</code> and <code>sender_verkey</code> following the authcrypt format listed below</li> </ol> </li> <li>If a sender is NOT included use anon_decrypt to decrypt the <code>encrypted_key</code> by doing the following:<ol> <li>decrypt <code>encrypted_key</code> using libsodium.crypto_box_seal_open(my_private_key, encrypted_key)</li> <li>decrypt ciphertext using libsodium.crypto_aead_chacha20poly1305_ietf_open_detached(base64URLdecode(ciphertext_bytes), base64URLdecode(protected_data_as_bytes), base64URLdecode(nonce), cek)</li> <li>return <code>message</code> and <code>recipient_verkey</code> following the anoncrypt format listed below</li> </ol> </li> </ul> </li> </ol> <p>NOTE: In the unpack algorithm, the base64url decode implementation used MUST correctly decode padded and unpadded base64URL encoded data.</p> <p>For a reference unpack implementation, see https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/commands/crypto.rs</p>"},{"location":"features/0019-encryption-envelope/#unpack_message-return-values-authcrypt-mode","title":"unpack_message() return values (authcrypt mode)","text":"<pre><code>{\n    \"message\": \"{ \\\"@id\\\": \\\"123456780\\\",\\\"@type\\\":\\\"https://didcomm.org/basicmessage/1.0/message\\\",\\\"sent_time\\\": \\\"2019-01-15 18:42:01Z\\\",\\\"content\\\": \\\"Your hovercraft is full of eels.\\\"}\",\n    \"recipient_verkey\": \"HKTAiYM8cE2kKC9KaNMZLYj4GS8uWCYMBxP2i1Y92zum\",\n    \"sender_verkey\": \"DWwLsbKCRAbYtfYnQNmzfKV7ofVhMBi6T4o3d2SCxVuX\"\n}\n</code></pre>"},{"location":"features/0019-encryption-envelope/#unpack_message-return-values-anoncrypt-mode","title":"unpack_message() return values (anoncrypt mode)","text":"<pre><code>{\n    \"message\": \"{ \\\"@id\\\": \\\"123456780\\\",\\\"@type\\\":\\\"https://didcomm.org/basicmessage/1.0/message\\\",\\\"sent_time\\\": \\\"2019-01-15 18:42:01Z\\\",\\\"content\\\": \\\"Your hovercraft is full of eels.\\\"}\",\n    \"recipient_verkey\": \"2GXmuCN2JCxSqMRVftBHLxVJKSL5bXyzM8DsPzGqQoNj\"\n}\n</code></pre>"},{"location":"features/0019-encryption-envelope/#additional-notes","title":"Additional Notes","text":"<ul> <li> <p>All <code>kid</code> values used currently are base58 encoded ed25519 keys. If other keys types are used, say secp256k1, base58 encoding should also be used here for interoperability.</p> </li> <li> <p>All algorithm APIs which use libsodium are from sodiumoxide rust wrapping of the original C implementation.</p> </li> </ul>"},{"location":"features/0019-encryption-envelope/#drawbacks","title":"Drawbacks","text":"<p>The current implementation of the <code>pack()</code> message is currently Hyperledger Aries specific. It is based on common crypto libraries (NaCl), but the wrappers are not commonly used outside of Aries. There's currently work being done to fine alignment on a cross-ecosystem interoperable protocol, but this hasn't been achieved yet. This work will hopefully bridge this gap.</p>"},{"location":"features/0019-encryption-envelope/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>As the JWE standard currently stands, it does not follow this format. We're actively working with the lead writer of the JWE spec to find alignment and are hopeful the changes needed can be added.</p> <p>We've also looked at using the Message Layer Security (MLS) specification. This specification shows promise for adoption later on with more maturity. Additionally because they aren't hiding metadata related to the sender (Sender Anonymity), we would need to see some changes made to the specification before we could adopt this spec.</p>"},{"location":"features/0019-encryption-envelope/#prior-art","title":"Prior art","text":"<p>The JWE family of encryption methods.</p>"},{"location":"features/0019-encryption-envelope/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>How transport protocols (https, zmq, etc.) will be be used to send Encrypted Envelopes?<ul> <li>These will need to be defined using separate RFCs. For example, HTTP might POST a message and place it in the body of the HTTP POST.</li> </ul> </li> <li>How will the encrypted envelopes work with routing tables to pass a message through a domain, potentially over various transport protocols?<ul> <li>There's not much certainty whether routing tables or some other mechanism will be used. This needs to be defined in another RFC.</li> </ul> </li> <li>If the encryption envelope protocol fails, how is that failure passed back to those involved in the transmission?<ul> <li>This should be handled using the Report Problem Protocol which is currently demonstrated RFC #35 by Stephen Curran.</li> </ul> </li> </ul>"},{"location":"features/0019-encryption-envelope/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community Aries Framework - .NET .NET framework for building agents of all types Streetcred.id Commercial mobile and web app built using Aries Framework - .NET Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases. Aries Framework - Go For building agents, hubs and other DIDComm ../../features in GoLang. Aries Protocol Test Suite"},{"location":"features/0019-encryption-envelope/schema/","title":"Schema","text":"<p>This spec is according JSON Schema v0.7 <pre><code>{\n    \"id\": \"https://github.com/hyperledger/indy-agent/wiremessage.json\",\n    \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n    \"title\": \"Json Web Message format\",\n    \"type\": \"object\",\n    \"required\": [\"ciphertext\", \"iv\", \"protected\", \"tag\"],\n    \"properties\": {\n        \"protected\": {\n            \"type\": \"object\",\n            \"description\": \"Additional authenticated message data base64URL encoded, so it can be verified by the recipient using the tag\",\n            \"required\": [\"enc\", \"typ\", \"alg\", \"recipients\"],\n            \"properties\": {\n                \"enc\": {\n                    \"type\": \"string\",\n                    \"enum\": [\"xchacha20poly1305_ietf\"],\n                    \"description\": \"The authenticated encryption algorithm used to encrypt the ciphertext\"\n                },\n                \"typ\": { \n                    \"type\": \"string\",\n                    \"description\": \"The message type. Ex: JWM/1.0\"\n                },\n                \"alg\": {\n                    \"type\": \"string\",\n                    \"enum\": [ \"authcrypt\", \"anoncrypt\"]\n                },\n                \"recipients\": {\n                    \"type\": \"array\",\n                    \"description\": \"A list of the recipients who the message is encrypted for\",\n                    \"items\": {\n                        \"type\": \"object\",\n                        \"required\": [\"encrypted_key\", \"header\"],\n                        \"properties\": {\n                            \"encrypted_key\": {\n                                \"type\": \"string\",\n                                \"description\": \"The key used for encrypting the ciphertext. This is also referred to as a cek\"\n                            },\n                            \"header\": {\n                                \"type\": \"object\",\n                                \"required\": [\"kid\"],\n                                \"description\": \"The recipient to whom this message will be sent\",\n                                \"properties\": {\n                                    \"kid\": {\n                                        \"type\": \"string\",\n                                        \"description\": \"base58 encoded verkey of the recipient.\"\n                                    }\n                                }\n                            }\n                        }\n                    }\n                 },     \n            },\n        },\n        \"iv\": {\n            \"type\": \"string\",\n            \"description\": \"base64 URL encoded nonce used to encrypt ciphertext\"\n        },\n        \"ciphertext\": {\n            \"type\": \"string\",\n            \"description\": \"base64 URL encoded authenticated encrypted message\"\n        },\n        \"tag\": {\n            \"type\": \"string\",\n            \"description\": \"Integrity checksum/tag base64URL encoded to check ciphertext, protected, and iv\"\n        }\n    }\n}\n</code></pre></p>"},{"location":"features/0023-did-exchange/","title":"Aries RFC 0023: DID Exchange v1","text":"<ul> <li>Authors: Ryan West, Daniel Bluhm, Matthew Hailstone, Sam Curren, Stephen Curran, George Aristy</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Replaces RFC 0160 - Connection Protocol and is a part of AIP 2.0.</li> <li>Supersedes: RFC 0160 - Connection Protocol</li> <li>Start Date: 2018-06-29</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"features/0023-did-exchange/#summary","title":"Summary","text":"<p>This RFC describes the protocol to exchange DIDs between agents when establishing a DID based relationship.</p>"},{"location":"features/0023-did-exchange/#motivation","title":"Motivation","text":"<p>Aries agent developers want to create agents that are able to establish relationships with each other and exchange secure information using keys and endpoints in DID Documents. For this to happen there must be a clear protocol to exchange DIDs.</p>"},{"location":"features/0023-did-exchange/#version-change-log","title":"Version Change Log","text":""},{"location":"features/0023-did-exchange/#version-11-signed-rotations-without-did-documents","title":"Version 1.1 -  Signed Rotations without DID Documents","text":"<p>Added the optional <code>did_rotate~attach</code> attachment for provenance of rotation without an attached DID Document.</p>"},{"location":"features/0023-did-exchange/#tutorial","title":"Tutorial","text":"<p>We will explain how DIDs are exchanged, with the roles, states, and messages required.</p>"},{"location":"features/0023-did-exchange/#roles","title":"Roles","text":"<p>The DID Exchange Protocol uses two roles: requester and responder.</p> <p>The requester is the party that initiates this protocol after receiving an <code>invitation</code> message (using RFC 0434 Out of Band) or by using an implied invitation from a public DID. For example, a verifier might get the DID of the issuer of a credential they are verifying, and use information in the DIDDoc for that DID as the basis for initiating an instance of this protocol.</p> <p>Since the requester receiving an explicit invitation may not have an Aries agent, it is desirable, but not strictly, required that sender of the invitation (who has the responder role in this protocol) have the ability to help the requester with the process and/or costs associated with acquiring an agent capable of participating in the ecosystem. For example, the sender of an invitation may often be sponsoring institutions.</p> <p>The responder, who is the sender of an explicit invitation or the publisher of a DID with an implicit invitation, must have an agent capable of interacting with other agents via DIDComm.</p> <p>In cases where both parties already possess SSI capabilities, deciding who plays the role of requester and responder  might be a casual matter of whose phone is handier.</p>"},{"location":"features/0023-did-exchange/#states","title":"States","text":""},{"location":"features/0023-did-exchange/#requester","title":"Requester","text":"<p>The requester goes through the following states per the State Machine Tables below</p> <ul> <li>start</li> <li>invitation-received</li> <li>request-sent</li> <li>response-received</li> <li>abandoned</li> <li>completed</li> </ul>"},{"location":"features/0023-did-exchange/#responder","title":"Responder","text":"<p>The responder goes through the following states per the State Machine Tables below</p> <ul> <li>start</li> <li>invitation-sent</li> <li>request-received</li> <li>response-sent</li> <li>abandoned</li> <li>completed</li> </ul>"},{"location":"features/0023-did-exchange/#state-machine-tables","title":"State Machine Tables","text":"<p>The following are the requester and responder state machines.</p> <p>The <code>invitation-sent</code> and <code>invitation-received</code> are technically outside this protocol, but are useful to show in the state machine as the invitation is the trigger to start the protocol and is referenced from the protocol as the parent thread (<code>pthid</code>).  This is discussed in more detail below.</p> <p>The <code>abandoned</code> and <code>completed</code> states are terminal states and there is no expectation that the protocol can be continued (or even referenced) after reaching those states.</p> <p></p>"},{"location":"features/0023-did-exchange/#errors","title":"Errors","text":"<p>After receiving an explicit invitation, the requester may send a <code>problem-report</code> to the responder using the information in the invitation to either restart the invitation process (returning to the <code>start</code> state) or to abandon the protocol. The <code>problem-report</code> may be an adopted  <code>Out of Band</code> protocol message or an adopted <code>DID Exchange</code> protocol message, depending on where in the processing of the invitation the error was detected.</p> <p>During the <code>request</code> / <code>response</code> part of the protocol, there are two protocol-specific error messages possible: one for an active rejection and one for an unknown error. These errors are sent using a problem_report message type specific to the DID Exchange Protocol. These errors do not transition the protocol to the <code>abandoned</code> state. The following list details <code>problem-code</code>s that may be sent in these cases:</p> <p>request_not_accepted - The error indicates that the <code>request</code> message has been rejected for a reason listed in the <code>error_report</code>. Typical reasons include not accepting the method of the provided DID, unknown endpoint protocols, etc. The <code>request</code> can be resent after the appropriate corrections have been made.</p> <p>request_processing_error - This error is sent when the responder was processing the request with the intent to accept the request, but some processing error occurred. This error indicates that the <code>request</code> should be resent as-is.</p> <p>response_not_accepted - The error indicates that the <code>response</code> has been rejected for a reason listed in the <code>error_report</code>. Typical reasons include not accepting the method of the provided DID, unknown endpoint protocols, invalid signature, etc. The <code>response</code> can be resent after the appropriate corrections have been made.</p> <p>response_processing_error - This error is sent when the requester was processing the <code>response</code> with the intent to accept the response, but some processing error occurred. This error indicates that the <code>response</code> should be resent as-is.</p> <p>If other errors occur, the corresponding party may send a <code>problem-report</code> to inform the other party they are abandoning the protocol.</p> <p>No errors are sent in timeout situations. If the requester or responder wishes to retract the messages they sent, they record so locally and return a <code>request_not_accepted</code> or <code>response_not_accepted</code> error when the other party sends a <code>request</code> or <code>response</code>.</p>"},{"location":"features/0023-did-exchange/#error-message-example","title":"Error Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/didexchange/1.1/problem_report\",\n  \"@id\": \"5678876542345\",\n  \"~thread\": { \"thid\": \"&lt;@id of message related to problem&gt;\" },\n  \"~l10n\": { \"locale\": \"en\"},\n  \"problem-code\": \"request_not_accepted\", // matches codes listed above\n  \"explain\": \"Unsupported DID method for provided DID.\"\n}\n</code></pre>"},{"location":"features/0023-did-exchange/#error-message-attributes","title":"Error Message Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is a problem_report within the didexchange protocol.</li> <li>The <code>~thread</code> attribute provides a context for the problem, referring to the message which contains the problem.</li> <li>Use of <code>~l10n</code> is encouraged, with at least locale defined for the message.</li> <li>The <code>problem-code</code> attribute contains one of a fixed set of codes defined in the list above.</li> <li>The <code>explain</code> attribute contains a human readable message which indicates the problem.</li> </ul>"},{"location":"features/0023-did-exchange/#flow-overview","title":"Flow Overview","text":"<ul> <li>The responder gives provisional information to the requester using an explicit <code>invitation</code> message from the <code>out-of-band</code> protocol or an implicit invitation in a DID the responder publishes.</li> <li>In the <code>out-of-band</code> protocol, the responder is called the sender, and the requester is called the receiver.</li> <li>The requester uses the provisional information to send a DID and DID Doc to the responder in a <code>request</code> message.</li> <li>The responder uses sent DID Doc information to send a DID and DID Doc to the requester in a <code>response</code> message.</li> <li>The requester sends the responder a <code>complete</code> message that confirms the <code>response</code> message was received.</li> </ul>"},{"location":"features/0023-did-exchange/#implicit-and-explicit-invitations","title":"Implicit and Explicit Invitations","text":"<p>The DID Exchange Protocol is preceded by  - either knowledge of a resolvable DID (an implicit invitation)  - or by a <code>out-of-band/%VER/invitation</code> message from the Out Of Band Protocols RFC. </p> <p>The information needed to construct the <code>request</code> message to start the protocol is used - either from the resolved DID Document  - or the <code>service</code> element of the <code>handshake_protocols</code> attribute of the <code>invitation</code>.</p>"},{"location":"features/0023-did-exchange/#1-exchange-request","title":"1. Exchange Request","text":"<p>The <code>request</code> message is used to communicate the DID document of the requester to the responder using the provisional service information present in the (implicit or explicit) invitation.</p> <p>The requester may provision a new DID according to the DID method spec. For a Peer DID, this involves creating a matching peer DID and key. The newly provisioned DID and DID Doc is presented in the <code>request</code> message as follows:</p>"},{"location":"features/0023-did-exchange/#request-message-example","title":"Request Message Example","text":"<pre><code>{\n  \"@id\": \"5678876542345\",\n  \"@type\": \"https://didcomm.org/didexchange/1.1/request\",\n  \"~thread\": { \n      \"thid\": \"5678876542345\",\n      \"pthid\": \"&lt;id of invitation&gt;\"\n  },\n  \"label\": \"Bob\",\n  \"goal_code\": \"aries.rel.build\",\n  \"goal\": \"To create a relationship\",\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n      \"@id\": \"d2ab6f2b-5646-4de3-8c02-762f553ab804\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n         \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n         \"jws\": {\n            \"header\": {\n               \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n            },\n            \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n            \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n            }\n      }\n   }\n}\n</code></pre>"},{"location":"features/0023-did-exchange/#request-message-attributes","title":"Request Message Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is an exchange request.</li> <li>The <code>~thread</code> decorator MUST be included:</li> <li>It MUST include the ID of the parent thread (<code>pthid</code>) such that the <code>request</code> can be correlated to the corresponding (implicit or explicit) <code>invitation</code>. More on correlation below.</li> <li>It MAY include the <code>thid</code> property. This works according to the <code>thid</code> property in the thread decorator, meaning that if <code>thid</code> is not defined it is implicitly defined as the <code>@id</code> on the same <code>request</code> message.</li> <li>The <code>label</code> attribute provides a suggested label for the DID being exchanged. This allows the user to tell multiple exchange requests apart. This is not a trusted attribute. (See note on <code>label</code> below)</li> <li>The <code>goal_code</code> (optional) is a self-attested code the receiver may want to display to the user or use in automatically deciding what to do with the request message. The goal code might be used particularly when the request is sent to a resolvable DID without reference to a specfic invitation.</li> <li>The goal (optional) is a self-attested string that the receiver may want to display to the user about the context-specific goal of the request message.</li> <li>The <code>did</code> attribute MUST be included. It indicates the DID being exchanged.</li> <li>The <code>did_doc~attach</code> (optional), contains the DIDDoc associated with the <code>did</code>, if required.</li> <li>If the <code>did</code> is resolvable (either an inline <code>peer:did</code> or a publicly resolvable DID), the <code>did_doc~attach</code> attribute should not be included.</li> <li>If the DID is a <code>did:peer</code> DID, the DIDDoc must be as outlined in RFC 0627 Static Peer DIDs.</li> </ul> <p>The <code>label</code> property was intended to be declared as an optional property, but was added to the RFC as a required property. If an agent wishes to not use a label in the request, an empty string (<code>\"\"</code>) or the set value <code>Unspecified</code> may be used to indicate a non-value. This approach ensures existing AIP 2.0 implementations do not break.</p>"},{"location":"features/0023-did-exchange/#correlating-requests-to-invitations","title":"Correlating requests to invitations","text":"<p>An invitation is presented in one of two forms:</p> <ul> <li>An explicit out-of-band invitation with its own <code>@id</code>.</li> <li>An implicit invitation contained in a DID document's <code>service</code> attribute that conforms to the DIDComm conventions.</li> </ul> <p>When a <code>request</code> responds to an explicit invitation, its <code>~thread.pthid</code> MUST be equal to the <code>@id</code> property of the invitation as described in the out-of-band RFC.</p> <p>When a <code>request</code> responds to an implicit invitation, its <code>~thread.pthid</code> MUST contain a DID URL that resolves to the specific <code>service</code> on a DID document that contains the invitation.</p>"},{"location":"features/0023-did-exchange/#example-referencing-an-explicit-invitation","title":"Example Referencing an Explicit Invitation","text":"<pre><code>{\n  \"@id\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n  \"@type\": \"https://didcomm.org/didexchange/1.1/request\",\n  \"~thread\": { \n      \"thid\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n      \"pthid\": \"032fbd19-f6fd-48c5-9197-ba9a47040470\" \n  },\n  \"label\": \"Bob\",\n  \"goal_code\": \"aries.rel.build\",\n  \"goal\": \"To create a relationship\",\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n      \"@id\": \"d2ab6f2b-5646-4de3-8c02-762f553ab804\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n         \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n         \"jws\": {\n            \"header\": {\n               \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n            },\n            \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n            \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n            }\n      }\n   }\n}\n</code></pre>"},{"location":"features/0023-did-exchange/#example-referencing-an-implicit-invitation","title":"Example Referencing an Implicit Invitation","text":"<pre><code>{\n  \"@id\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n  \"@type\": \"https://didcomm.org/didexchange/1.1/request\",\n  \"~thread\": { \n      \"thid\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n      \"pthid\": \"did:example:21tDAKCERh95uGgKbJNHYp#didcomm\" \n  },\n  \"label\": \"Bob\",\n  \"goal_code\": \"aries.rel.build\",\n  \"goal\": \"To create a relationship\",\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n      \"@id\": \"d2ab6f2b-5646-4de3-8c02-762f553ab804\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n         \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n         \"jws\": {\n            \"header\": {\n               \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n            },\n            \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n            \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n            }\n      }\n   }\n}\n</code></pre>"},{"location":"features/0023-did-exchange/#request-transmission","title":"Request Transmission","text":"<p>The <code>request</code> message is encoded according to the standards of the Encryption Envelope, using the <code>recipientKeys</code> present in the invitation.</p> <p>If the <code>routingKeys</code> attribute was present and non-empty in the invitation, each key must be used to wrap the message in a forward request, then encoded in an Encryption Envelope. This processing is in order of the keys in the list, with the last key in the list being the one for which the <code>serviceEndpoint</code> possesses the private key.</p> <p>The message is then transmitted to the <code>serviceEndpoint</code>.</p> <p>The requester is in the <code>request-sent</code> state. When received, the responder is in the <code>request-received</code> state.</p>"},{"location":"features/0023-did-exchange/#request-processing","title":"Request processing","text":"<p>After receiving the exchange request, the responder evaluates the provided DID and DID Doc according to the DID Method Spec.</p> <p>The responder should check the information presented with the keys used in the wire-level message transmission to ensure they match.</p> <p>The responder MAY look up the corresponding invitation identified in the request's <code>~thread.pthid</code> to determine whether it should accept this exchange request.</p> <p>If the responder wishes to continue the exchange, they will persist the received information in their wallet. They will then either update the provisional service information to rotate the key, or provision a new DID entirely. The choice here will depend on the nature of the DID used in the invitation.</p> <p>The responder will then craft an exchange response using the newly updated or provisioned information.</p>"},{"location":"features/0023-did-exchange/#request-errors","title":"Request Errors","text":"<p>See Error Section above for message format details.</p>"},{"location":"features/0023-did-exchange/#request-rejected","title":"Request Rejected","text":"<p>Possible reasons:</p> <ul> <li>Unsupported DID method for provided DID</li> <li>Expired Invitation</li> <li>DID Doc Invalid</li> <li>Unsupported key type</li> <li>Unsupported endpoint protocol</li> <li>Missing reference to invitation</li> </ul>"},{"location":"features/0023-did-exchange/#request-processing-error","title":"Request Processing Error","text":"<ul> <li>unknown processing error</li> </ul>"},{"location":"features/0023-did-exchange/#2-exchange-response","title":"2. Exchange Response","text":"<p>The exchange response message is used to complete the exchange. This message is required in the flow, as it updates the provisional information presented in the invitation.</p>"},{"location":"features/0023-did-exchange/#response-message-example","title":"Response Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/didexchange/1.1/response\",\n  \"@id\": \"12345678900987654321\",\n  \"~thread\": {\n    \"thid\": \"&lt;The Thread ID is the Message ID (@id) of the first message in the thread&gt;\"\n  },\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n      \"@id\": \"d2ab6f2b-5646-4de3-8c02-762f553ab804\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n         \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n         \"jws\": {\n            \"header\": {\n               \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n            },\n            \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n            \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n            }\n      }\n   },\n   \"did_rotate~attach\": {\n      \"mime-type\": \"text/string\",\n      \"data\": {\n         \"base64\": \"Qi5kaWRAQjpB\",\n         \"jws\": {\n         \"header\": {\n            \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n         },\n         \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n         \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n         }\n      }\n   }\n}\n</code></pre> <p>The invitation's <code>recipientKeys</code> should be dedicated to envelopes authenticated encryption throughout the exchange. These keys are usually defined in the <code>KeyAgreement</code> DID verification relationship.</p>"},{"location":"features/0023-did-exchange/#response-message-attributes","title":"Response Message Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is an exchange request.</li> <li>The <code>~thread</code> decorator MUST be included. It contains a <code>thid</code> reference to the <code>@id</code> of the request message.</li> <li>The <code>did</code> attribute MUST be included. It denotes the DID in use by the responder. Note that this MAY NOT be the same DID used in the invitation.</li> <li>The <code>did_doc~attach</code> optional, contains the DID Doc associated with the <code>did</code>, if required.</li> <li>If the <code>did</code> is resolvable (either an inline <code>did:peer</code> or a publicly resolvable DID), the <code>did_doc~attach</code> attribute should not be included.</li> <li>If the DID is a <code>did:peer</code> identifier, the DIDDoc must be as outlined in RFC 0627 Static Peer DIDs.</li> <li>The <code>did_rotate~attach</code> attribute is optional, but SHOULD be included if the <code>did</code> attribute is resolvable and the <code>did_doc~attach</code> is not included. The value is the Base64url encoded DID, and signed with the key used in the invitation.</li> </ul> <p>In addition to a new DID, the associated DID Doc might contain a new endpoint. This new DID and endpoint are to be used going forward in the relationship.</p>"},{"location":"features/0023-did-exchange/#response-transmission","title":"Response Transmission","text":"<p>The message should be packaged in the encrypted envelope format, using the keys from the request, and the new keys presented in the internal did doc.</p> <p>When the message is sent, the responder are now in the <code>response-sent</code> state. On receipt, the requester is in the <code>response-received</code> state.</p>"},{"location":"features/0023-did-exchange/#response-processing","title":"Response Processing","text":"<p>When the requester receives the <code>response</code> message, they will decrypt the authenticated envelope which confirms the source's authenticity. After decryption validation, the signature on the <code>did_doc~attach</code> or <code>did_rotate~attach</code> MUST be validated, if present. The key used in the signature MUST match the key used in the invitation. After attachment signature validation, they will update their wallet with the new information, and use that information in sending the <code>complete</code> message.</p>"},{"location":"features/0023-did-exchange/#response-errors","title":"Response Errors","text":"<p>See Error Section above for message format details.</p>"},{"location":"features/0023-did-exchange/#response-rejected","title":"Response Rejected","text":"<p>Possible reasons:</p> <ul> <li>unsupported DID method for provided DID</li> <li>Expired Request</li> <li>DID Doc Invalid</li> <li>Unsupported key type</li> <li>Unsupported endpoint protocol</li> <li>Invalid Signature</li> </ul>"},{"location":"features/0023-did-exchange/#response-processing-error","title":"Response Processing Error","text":"<ul> <li>unknown processing error</li> </ul>"},{"location":"features/0023-did-exchange/#3-exchange-complete","title":"3. Exchange Complete","text":"<p>The exchange <code>complete</code> message is used to confirm the exchange to the responder. This message is required in the flow, as it marks the exchange complete. The responder may then invoke any protocols desired based on the context expressed via the <code>pthid</code> in the DID Exchange protocol.</p>"},{"location":"features/0023-did-exchange/#complete-message-example","title":"Complete Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/didexchange/1.1/complete\",\n  \"@id\": \"12345678900987654321\",\n  \"~thread\": {\n    \"thid\": \"&lt;The Thread ID is the Message ID (@id) of the first message in the thread&gt;\",\n    \"pthid\": \"&lt;pthid used in request message&gt;\"\n  }\n}\n</code></pre> <p>The <code>pthid</code> is required in this message, and must be identical to the <code>pthid</code> used in the <code>request</code> message.</p> <p>After a <code>complete</code> message is sent, the requester is in the <code>completed</code> terminal state. Receipt of the message puts the responder into the <code>completed</code> state.</p>"},{"location":"features/0023-did-exchange/#complete-errors","title":"Complete Errors","text":"<p>See Error Section above for message format details.</p>"},{"location":"features/0023-did-exchange/#complete-rejected","title":"Complete Rejected","text":"<p>This is unlikely to occur with other than an unknown processing error (covered below), so no possible reasons are listed. As experience is gained with the protocol, possible reasons may be added.</p>"},{"location":"features/0023-did-exchange/#complete-processing-error","title":"Complete Processing Error","text":"<ul> <li>unknown processing error</li> </ul>"},{"location":"features/0023-did-exchange/#next-steps","title":"Next Steps","text":"<p>The exchange between the requester and the responder has been completed. This relationship has no trust associated with it. The next step should be to increase the trust to a sufficient level for the purpose of the relationship, such as through an exchange of proofs.</p>"},{"location":"features/0023-did-exchange/#peer-did-maintenance","title":"Peer DID Maintenance","text":"<p>When Peer DIDs are used in an exchange, it is likely that both the requester and responder will want to perform some relationship maintenance such as key rotations. Future RFC updates will add these maintenance ../../features.</p>"},{"location":"features/0023-did-exchange/#reference","title":"Reference","text":"<ul> <li>https://docs.google.com/document/d/1mRLPOK4VmU9YYdxHJSxgqBp19gNh3fT7Qk4Q069VPY8/edit#heading=h.7sxkr7hbou5i</li> <li>Agent to Agent Communication Video</li> <li>Agent to Agent Communication Presentation</li> <li>Problem_report message adopted into message family, following form defined by the Problem Report HIPE</li> <li>RFC0519 Goal Codes</li> </ul>"},{"location":"features/0023-did-exchange/#drawbacks","title":"Drawbacks","text":"<p>N/A at this time</p>"},{"location":"features/0023-did-exchange/#prior-art","title":"Prior art","text":"<ul> <li>This process is similar to other key exchange protocols.</li> </ul>"},{"location":"features/0023-did-exchange/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>N/A at this time</li> </ul>"},{"location":"features/0023-did-exchange/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Trinsic.id Commercial mobile and web app built using Aries Framework - .NET MISSING test results"},{"location":"features/0024-didcomm-over-xmpp/","title":"Aries RFC 0024: DIDComm over XMPP","text":"<ul> <li>Authors: Oskar van Deventer, Galit Rahim, Alexander Blom</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes: Indy DIDComm-over-XMPP</li> <li>Start Date: 2019-04-23</li> <li>Tags: feature</li> </ul>"},{"location":"features/0024-didcomm-over-xmpp/#summary","title":"Summary","text":"<p>While DIDComm leaves its users free to choose any underlying communication protocol, for peer-to-peer DID relationships with one or both parties behind a firewall actually getting the messages to the other party is not straightforward.</p> <p>Fortunately this is a classical problem, encountered by all realtime communication protocols, and it is therefore natural to use one of these protocols to deal with the obstacles posed by firewalls. The DIDComm-over-XMPP feature provides an architecture to exchange DIDComm connection protocol messages over XMPP, using XMPP to solve any firewall issues.</p> <p>DIDComm-over-XMPP enables:</p> <ul> <li>Initiation, use, maintenance and termination of a trusted electronic relationship</li> <li>DIDComm agents being available for incoming DIDComm messages despite being behind a firewall</li> <li>Binding of that relationship to a human-to-human communication channel</li> </ul> <p>and all of this in spite of the presence of firewalls.</p> <p>Editor's note: A reference should be added to Propose HIPE: Transports  #94</p>"},{"location":"features/0024-didcomm-over-xmpp/#motivation","title":"Motivation","text":"<p>Currently, all examples of service endpoint in the W3C DID specification use HTTP. This assumes that the endpoint is running an HTTP server and firewalls have been opened to allow this traffic to pass through. This assumption typically fails for DIDComm agents behind LAN firewalls or using cellular networks. As a consequence, such DIDComm agents can be expected to be unavailable for incoming DIDComm messages, whereas several use cases require this. The following is an example of this.</p> <p>A consumer contacts a customer service agent of his health insurance company, and is subsequently asked for proof of identity before getting answers to his personal health related questions. DIDcom could be of use here, replacing privacy sensitive and time consuming questions in order to establish the consumers' identity with an exchange of verifiable credentials using DIDcom.  In that case, the agent would just send a DIDComm message to the caller to link the ongoing human-to-human communication session to a DIDComm agent-to-agent communication session. The DIDComm connection protocol would then enable the setting up and maintenance of a trusted electronic relationship, to be used to exchange verifiable credentials. Replace insurance company with any sizeable business to consumer company and one realizes that this use case is far from insignificant.</p> <p>Unfortunately, by itself, the parties DIDcom agents will be unable to bypass the firewalls involved and exchange DIDcom messages. Therefore XMPP is called to the rescue to serve as the transport protocol which is capable with firewalls. Once the firewalls issue is solved, DIDcom can be put to use in all of these cases.</p> <p>The XMPP protocol is a popular protocol for chat and messaging. It has a client-server structure that bypasses any firewall issues.</p>"},{"location":"features/0024-didcomm-over-xmpp/#tutorial","title":"Tutorial","text":"<p>The DIDComm-over-XMPP feature provides an architecture for the transport of DIDComm messages over an XMPP network, using XMPP to bypass any firewalls at the receiving side.</p>"},{"location":"features/0024-didcomm-over-xmpp/#didcomm","title":"DIDComm","text":"<p>The DIDComm wire message format is specified in HIPE 0028-wire-message-format. It can carry among others the DIDComm connection protocol, as specified in Hyperledger Indy Hipe 0031. The purpose of the latter protocol is to set up a trusted electronic relationship between two parties (natural person, legal person, ...). Technically, the trust relationship involves the following</p> <ul> <li>Univocal identification of the parties within the context of the relationship</li> <li>Secure exchange of keys to encrypt and verify messages between agents of the parties</li> <li>Secure exchange of service end points to be reachable at in the future</li> <li>Secure exchange of verifiable credentials and other messages that require secure exchange</li> </ul> <p>W3C specifies Data Model and Syntaxes for Decentralized Identifiers (DIDs). This specification introduces Decentralized Identifiers, DIDs, for identification. A DID can be resolved into a DID Document that contains the associated keys and service endpoints, see also W3C's A Primer for Decentralized Identifiers. W3C provides a DID Method Registry for a complete list of all known DID Method specifications. Many of the DID methods use an unambiguous source of truth to resolve a DID Document, e.g. a well governed public blockchain. An exception is the Peer DID method that relies on the peers, i.e. parties in the trusted electronic relationship to maintain the DID Document.</p>"},{"location":"features/0024-didcomm-over-xmpp/#xmpp","title":"XMPP","text":"<p>Extensible Messaging and Presence Protocol (XMPP) is a communication protocol for message-oriented middleware based on XML (Extensible Markup Language). It enables the near-real-time exchange of structured yet extensible data between any two or more network entities. Designed to be extensible, the protocol has been used also for publish-subscribe systems, signalling for VoIP, video, file transfer, gaming, the Internet of Things applications such as the smart grid, and social networking services.</p> <p>Unlike most instant messaging protocols, XMPP is defined in an open standard and uses an open systems approach of development and application, by which anyone may implement an XMPP service and interoperate with other organizations' implementations. Because XMPP is an open protocol, implementations can be developed using any software license and many server, client, and library implementations are distributed as free and open-source software. Numerous freeware and commercial software implementations also exist.</p> <p>XMPP uses 3 types of messages:</p> Message Type Description PRESENSE Inform listeners that agent is online MESSAGE Sending message to other agent IQ MESSAGE Asking for response from other agent <p></p>"},{"location":"features/0024-didcomm-over-xmpp/#didcomm-over-xmpp","title":"DIDComm over XMPP","text":""},{"location":"features/0024-didcomm-over-xmpp/#use-of-message-normative","title":"Use of MESSAGE (normative)","text":"<p>A DIDComm wire message shall be sent send as plaintext XMPP MESSAGE, without any additional identifiers.</p>"},{"location":"features/0024-didcomm-over-xmpp/#service-endpoint-normative","title":"Service endpoint (normative)","text":"<p>A DIDComm-over-XMPP service shall comply to the following.</p> <ol> <li>The id shall have a DID fragment \"#xmpp\".</li> <li>The type shall be \"XmppService\".</li> <li>The serviceEndpoint</li> <li>shall not have a resource part (i.e. \"/...resource...\")</li> <li>shall comply to the following ABNF.</li> </ol> <pre><code>xmpp-service-endpoint = \"xmpp:\" userpart \"@did.\" domainpart\n  userpart = 1\\*CHAR\n  domainpart = 1\\*CHAR 1\\*(\".\" 1\\*char)\n  CHAR = %x01-7F\n</code></pre> <p>The reason for not allowing a resources part is that DIDComm messages are addressed to the person/entity associated with the DID, and not to any particular device.</p> <p>A receiving XMPP client shall identify an incoming XMPP message as a DIDComm message, if the serviceEndpoint complies to the above. It shall pass any DIDComm message to its DIDComm agent.</p> <p>The following is an example of a complient DIDComm-over-XMPP service endpoint.</p> <pre><code>{\n  \"service\": [{\n    \"id\": \"did:example:123456789abcdefghi#xmpp\",\n    \"type\": \"XmppService\",\n    \"serviceEndpoint\": \"xmpp:bob@did.bar.com\"\n  }]\n}\n</code></pre>"},{"location":"features/0024-didcomm-over-xmpp/#userpart-generation-informative","title":"Userpart generation (informative)","text":"<p>There are multiple methods how the userpart of the DIDComm-over-XMPP serviceEndpoint may be generated.</p> <p>Editor's note: Should the description below be interpreted as informative, or should there be any signalling to indicate which userpart-generating method was used?</p> <p>Method 1: Same userpart as for human user</p> <p>In this method, the userpart is the same as used for human-to-human XMPP-based chat, and the resource part is removed. Here is an example.</p> <pre><code>Human-to-human XMPP address: xmpp:alice@foo.com/phone\n--&gt;\nDIDComm-over-XMPP serviceEndpoint: xmpp:alice@did.foo.com\n</code></pre> <p>The advantage of this method is its simplicity. An XMPP servicer needs to be configured only once to support this convention. No further registration actions are needed by any of the the users for its XMPP clients.</p> <p>The disadvantage of this method is that it creates a strong correlation point, which may conflict with privacy requirements.</p> <p>Editor's note: More advantages or disadvantages?</p> <p>A typical application of Method 1 is when there is an ongoing human-to-human (or human-to-bot) chat session that uses XMPP and the two parties what to set up a pairwise DID relationship. One can skip Step 0 \"Invitation to Connect\" (HIPE 0031) and immediately perform Step 1 \"Connection Request\".</p> <p>Method 2: Random userpart</p> <p>In this method, the userpart is randomly generated by either the XMPP client or the XMPP server, and it is rotated at a regular basis. Here is an example.</p> <pre><code>DIDComm-over-XMPP serviceEndpoint: xmpp:RllH91rcFdE@did.foo.com\n</code></pre> <p>The advantage of this method is low correlation and hence high privacy. If the DIDComm-over-XMPP serviceEndpoint is rotated after each set of XMPP exchange (\"session\"), then it cannot be correlated with subsequent XMPP exchanges.</p> <p>The disadvantage of this method is the high operational complexity of this method. It requires a client to keep a reserve of random XMPP addresses with the XMPP server. It significantly increases the routing tables of the XMPP server. It also places a burden on both DIDComm agents, because of the rapid rotation of DID Documents.</p> <p>Editor's note: More advantages or disadvantages?</p>"},{"location":"features/0024-didcomm-over-xmpp/#reference","title":"Reference","text":"<p>For use of XMPP, it is recommended to use Openfire Server open source project, including 2 plugins to enable server caching and message carbon copy. This will enable sending DIDcom to mulitple endpoints of the same person.</p> <p>Editor's note: Add references to the 2 plugins</p> <p>XMPP servers handle messages sent to a user@host (or \"bare\") XMPP address with no resource by delivering that message only to the resource with the highest priority for the target user. Some server implementations, however, have chosen to send these messages to all of the online resources for the target user. If the target user is online with multiple resources when the original message is sent, a conversation ensues on one of the user's devices; if the user subsequently switches devices, parts of the conversation may end up on the alternate device, causing the user to be confused, misled, or annoyed.</p> <p>To solve this is is recommended to use the plugin \"Message Carbons\". It will ensure that all of target user devices get both sides of all conversations in order to avoid user confusion. As a pleasant side-effect, information about the current state of a conversation is shared between all of a user's clients that implement this protocol.</p> <p>Editor's note: Add reference to \"Message Carbons\"</p>"},{"location":"features/0024-didcomm-over-xmpp/#drawbacks","title":"Drawbacks","text":"<p>Editor's note: Add drawbacks</p>"},{"location":"features/0024-didcomm-over-xmpp/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>All service endpoint examples from W3C's Data Model and Syntaxes for Decentralized Identifiers (DIDs) are HTTP. So if a consumer would want to be reachable for incoming DIDComm messages, then it should run an HTTP service on its consumer device and take actions to open firewalls (and handle network-address translations) towards its device. Such scenario is technically completely unrealistic, not to mention the security implications of such scenario.</p> <p>XMPP was specifically designed for incoming messages to consumer devices. XMPP's client-server structure overcomes any firewall issues.</p>"},{"location":"features/0024-didcomm-over-xmpp/#prior-art","title":"Prior art","text":"<p>Editor's note: Add prior art</p>"},{"location":"features/0024-didcomm-over-xmpp/#unresolved-questions","title":"Unresolved questions","text":"<p>Editor's note: Any unresolved questions?</p>"},{"location":"features/0024-didcomm-over-xmpp/#security-considerations","title":"Security considerations","text":"<p>Editor's note: Add security considerations</p>"},{"location":"features/0024-didcomm-over-xmpp/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0025-didcomm-transports/","title":"Aries RFC 0025: DIDComm Transports","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: ADOPTED</li> <li>Since: 2019-12-05</li> <li>Status Note:  </li> <li>Supersedes: INDY PR 94</li> <li>Start Date: 2019-02-26</li> <li>Tags: feature</li> </ul>"},{"location":"features/0025-didcomm-transports/#summary","title":"Summary","text":"<p>This RFC Details how different transports are to be used for Agent Messaging.</p>"},{"location":"features/0025-didcomm-transports/#motivation","title":"Motivation","text":"<p>Agent Messaging is designed to be transport independent, including message encryption and agent message format. Each transport does have unique ../../features, and we need to standardize how the transport ../../features are (or are not) applied.</p>"},{"location":"features/0025-didcomm-transports/#reference","title":"Reference","text":"<p>Standardized transport methods are detailed here.</p>"},{"location":"features/0025-didcomm-transports/#https","title":"HTTP(S)","text":"<p>HTTP(S) is the first, and most used transport for DID Communication that has received heavy attention. </p> <p>While it is recognized that all DIDComm messages are secured through strong encryption, making HTTPS somewhat redundant, it will likely cause issues with mobile clients because venders (Apple and Google) are limiting application access to the HTTP protocol. For example, on iOS 9 or above where [ATS])(https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity) is in effect, any URLs using HTTP must have an exception hard coded in the application prior to uploading to the iTunes Store. This makes DIDComm unreliable as the agent initiating the the request provides an endpoint for communication that the mobile client must use. If the agent provides a URL using the HTTP protocol it will likely be unusable due to low level operating system limitations.</p> <p>As a best practice, when HTTP is used in situations where a mobile client (iOS or Android) may be involved it is highly recommended to use the HTTPS protocol, specifically TLS 1.2 or above. </p> <p>Other important notes on the subject of using HTTP(S) include:</p> <ul> <li>Messages are transported via HTTP POST.</li> <li>The MIME Type for the POST request is <code>application/didcomm-envelope-enc</code>; see RFC 0044: DIDComm File and MIME Types for more details.</li> <li>A received message should be responded to with a 202 Accepted status code. This indicates that the request was received, but not necessarily processed. Accepting a 200 OK status code is allowed.</li> <li>POST requests are considered transmit only by default. No agent messages will be returned in the response. This behavior may be modified with additional signaling.</li> <li>Using HTTPS with TLS 1.2 or greater with a forward secret cipher will provide Perfect Forward Secrecy (PFS) on the transmission leg.</li> </ul>"},{"location":"features/0025-didcomm-transports/#known-implementations","title":"Known Implementations","text":"<p>Aries Cloud Agent - Python Aries Framework - .NET</p>"},{"location":"features/0025-didcomm-transports/#websocket","title":"Websocket","text":"<p>Websockets are an efficient way to transmit multiple messages without the overhead of individual requests.</p> <ul> <li>Each message is transmitted individually in an Encryption Envelope.</li> <li>The trust of each message comes from the Encryption Envelope, not the socket connection itself.</li> <li>Websockets are considered transmit only by default. Messages will only flow from the agent that opened the socket. This behavior may be modified with additional signaling.</li> <li>Using Secure Websockets (wss://) with TLS 1.2 or greater with a forward secret cipher will provide Perfect Forward Secrecy (PFS) on the transmission leg.</li> </ul>"},{"location":"features/0025-didcomm-transports/#known-implementations_1","title":"Known Implementations","text":"<p>Aries Cloud Agent - Python Aries Framework - .NET</p>"},{"location":"features/0025-didcomm-transports/#xmpp","title":"XMPP","text":"<p>XMPP is an effective transport for incoming DID-Communication messages directly to mobile agents, like smartphones.</p> <ul> <li>Incoming DID-Communication messages will arrive, even if the mobile agent is behind a firewall and network-address-translation (NAT).</li> <li>Incoming DID-Communication messages continue to arrive, even when the IP address of the mobile agent changes (switching between, 3G, 4G, Wifi, roaming, ...).</li> <li>Independent of cloud agents and routing agents, as messages arrive directly at the mobile agent.</li> <li>Well suited for direct consumer-to-consumer SSI transactions, from one mobile agent directly to another mobile agent without any DID-Communication intermediaries.</li> <li>Simple encapsulation of DIDcom messages, getting trust from the DIDcom Encryption Envelope.</li> <li>Specified in Aries RFC 0024: DIDCom-over-XMPP</li> </ul>"},{"location":"features/0025-didcomm-transports/#known-implementations_2","title":"Known Implementations","text":"<p>XMPP is implemented in the Openfire Server open source project. Integration with DID Communication agents is work-in-progress.</p>"},{"location":"features/0025-didcomm-transports/#other-transports","title":"Other Transports","text":"<p>Other transports may be used for Agent messaging. As they are developed, this RFC should be updated with appropriate standards for the transport method. A PR should be raised against this doc to facilitate discussion of the proposed additions and/or updates. New transports should highlight the common elements of the transport (such as an HTTP response code for the HTTP transport) and how they should be applied.</p>"},{"location":"features/0025-didcomm-transports/#message-routing","title":"Message Routing","text":"<p>The transports described here are used between two agents. In the case of message routing, a message will travel across multiple agent connections. Each intermediate agent (see Mediators and Relays) may use a different transport. These transport details are not made known to the sender, who only knows the keys of Mediators and the first endpoint of the route.</p>"},{"location":"features/0025-didcomm-transports/#message-context","title":"Message Context","text":"<p>The transport used from a previous agent can be recorded in the message trust context. This is particularly true of controlled network environments, where the transport may have additional security considerations not applicable on the public internet. The transport recorded in the message context only records the last transport used, and not any previous routing steps as described in the Message Routing section of this document.</p>"},{"location":"features/0025-didcomm-transports/#transport-testing","title":"Transport Testing","text":"<p>Transports which operate on IP based networks can be tested by an Agent Test Suite through a transport adapter. Some transports may be more difficult to test in a general sense, and may need specialized testing frameworks. An agent with a transport not yet supported by any testing suites may have non-transport testing performed by use of a routing agent.</p>"},{"location":"features/0025-didcomm-transports/#drawbacks","title":"Drawbacks","text":"<p>Setting transport standards may prevent some uses of each transport method.</p>"},{"location":"features/0025-didcomm-transports/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Without standards for each transport, the assumptions of each agent may not align and prevent communication before each message can be unpacked and evaluated.</li> </ul>"},{"location":"features/0025-didcomm-transports/#prior-art","title":"Prior art","text":"<p>Several agent implementations already exist that follow similar conventions.</p>"},{"location":"features/0025-didcomm-transports/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"features/0025-didcomm-transports/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0028-introduce/","title":"Aries RFC 0028: Introduce Protocol 1.0","text":"<ul> <li>Authors: Daniel Hardman, Sam Curren, Stephen Curran, Tobias Looker, George Aristy</li> <li>Status: PROPOSED</li> <li>Since: 2019-04-15</li> <li>Status Note: Referenced in some discussions about the peer DID method spec and n-wise DIDs, but not yet implemented.</li> <li>Start Date: 2019-03-27</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0028-introduce/#summary","title":"Summary","text":"<p>Describes how a go-between can introduce two parties that it already knows, but that do not know each other.</p>"},{"location":"features/0028-introduce/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> </ul>"},{"location":"features/0028-introduce/#motivation","title":"Motivation","text":"<p>Introductions are a fundamental activity in human relationships. They allow us to bootstrap contact information and trust. They are also a source of virality. We need a standard way to do introductions in an SSI ecosystem, and it needs to be flexible, secure, privacy-respecting, and well documented.</p>"},{"location":"features/0028-introduce/#tutorial","title":"Tutorial","text":""},{"location":"features/0028-introduce/#name-and-version","title":"Name and Version","text":"<p>This is the Introduce 1.0 protocol. It is uniquely identified by the URI:</p> <pre><code>\"https://didcomm.org/introduce/1.0\"\n</code></pre>"},{"location":"features/0028-introduce/#key-concepts","title":"Key Concepts","text":""},{"location":"features/0028-introduce/#basic-use-case","title":"Basic Use Case","text":"<p>Introductions target scenarios like this:</p> <p>Alice knows Bob and Carol, and can talk to each of them. She wants to introduce them in a way that allows a relationship to form.</p> <p></p> <p>This use case is worded carefully; it is far more adaptable than it may appear at first glance. The Advanced Use Cases section later in the doc explores many variations. But the early part of this document focuses on the simplest reading of the use case.</p>"},{"location":"features/0028-introduce/#goal","title":"Goal","text":"<p>When we introduce two friends, we may hope that a new friendship ensues. But technically, the introduction is complete when we provide the opportunity for a relationship--what the parties do with that opportunity is a separate question.</p> <p>Likewise, the goal of our formal introduction protocol should be crisply constrained. Alice wants to gather consent and contact information from Bob and Carol; then she wants to invite them to connect. What they do with her invitation after that is not under her control, and is outside the scope of the introduction.</p> <p>This suggests an important insight about the relationship between the introduce protocol and the Out-Of-Band protocols: they overlap. The invitation to form a relationship, which begins the Out-Of-Band protocols, is also the final step in an introduction.</p> <p>Said differently, the goal of the introduce protocol is to start the Out-Of-Band protocols.</p>"},{"location":"features/0028-introduce/#transferring-trust","title":"Transferring Trust","text":"<p>[TODO: talk about how humans do introductions instead of just introducing themselves to strangers because it raises trust. Example of Delta Airlines introducing you to Heathrow Airport; you trust that you're really talking to Heathrow based on Delta's asertion.]</p>"},{"location":"features/0028-introduce/#roles","title":"Roles","text":"<p>There are three [TODO:do we want to support introducing more than 2 at a time?] participants in the protocol, but only two roles.</p> <p>The introducer begins the process and must know the other two parties. Alice is the introducer in the diagram above. The other two participants are both introducees.</p>"},{"location":"features/0028-introduce/#states","title":"States","text":"<p>In a successful introduction, the introducer state progresses from <code>[start] -&gt; arranging -&gt; delivering -&gt; confirming (optional) -&gt; [done]</code>. Confirming is accomplished with an ACK to an introducee to let them know that their out-of-band message was forwarded.</p> <p>Meanwhile, each introducee progresses from <code>[start] -&gt; deciding -&gt; waiting -&gt; [done]</code>.</p> <p>Of course, errors and optional choices complicate the possibilities. The full state machine for each party are:</p> <p></p> <p>The subtleties are explored in the Advanced Use Cases section.</p>"},{"location":"features/0028-introduce/#messages","title":"Messages","text":""},{"location":"features/0028-introduce/#proposal","title":"<code>proposal</code>","text":"<p>This message informs an introducee that an introducer wants to perform an introduction, and requests approval to do so. It works the same way that proposals do in double-opt-in introductions in the non-agent world:</p> <p></p> <p>The DIDComm message looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/introduce/1.0/proposal\",\n  \"@id\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\",\n  \"to\": {\n    \"name\": \"Bob\"\n  }\n}\n</code></pre> <p>The <code>to</code> field contains an introducee descriptor that provides context about the introduction, helping the party receiving the proposal to evaluate whether they wish to accept it. Depending on how much context is available between introducer and introducee independent of the formal proposal message, this can be as simple as a name, or something fancier (see Advanced Use Cases below).</p>"},{"location":"features/0028-introduce/#response","title":"<code>response</code>","text":"<p>A standard example of the message that an introducee sends in response to an introduction proposal would be:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/introduce/1.0/response\",\n  \"@id\": \"283e15b5-a3f7-43e7-bac8-b75e4e7a0a25\",\n  \"~thread\": {\"thid\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\"},\n  \"approve\": true,\n  \"oob-message\": {\n    \"@type\": \"https://didcomm.org/out-of-band/1.0/invitation\",\n    \"@id\": \"12345678900987654321\",\n    \"label\": \"Robert\",\n    \"goal\": \"To issue a Faber College Graduate credential\",\n    \"goal_code\": \"issue-vc\",\n    \"handshake_protocols\": [\n      \"https://didcomm.org/didexchange/1.0\",\n      \"https://didcomm.org/connections/1.0\"\n    ],\n    \"service\": [\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]\n  }\n}\n</code></pre> <p>A simpler response, also valid, might look like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/introduce/1.0/response\",\n  \"@id\": \"283e15b5-a3f7-43e7-bac8-b75e4e7a0a25\",\n  \"~thread\": {\"thid\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\"},\n  \"approve\": true\n}\n</code></pre> <p>The difference between the two forms is whether the response contains a valid out-of-band message (see RFC 0434). Normally, it should--but sometimes, an introducee may not be able to (or may not want to) share a DIDComm endpoint to facilitate the introduction. In such cases, the stripped-down variant may be the right choice. See the Advanced Use Cases section for more details.</p> <p>At least one of the more complete variants must be received by an introducer to successfully complete the introduction, because the final step in the protocol is to begin one of the Out-Of-Band protocols by forwarding the message from one introducee to the other.</p>"},{"location":"features/0028-introduce/#note-on-the-ouf-of-band-messages","title":"Note on the ouf-of-band messages","text":"<p>These messages are not a member of the <code>introductions/1.0</code> protocol; they are not even adopted. They belong to the out-of-band protocols, and are no different from the message that two parties would generate when one invites the other with no intermediary, except that:</p> <ul> <li>It is delivered by the introducer, not by either of the introducees.</li> <li>It has a <code>~thread</code> decorator that identifies the introduction as its parent thread.</li> <li>If introducees already have DIDComm capabilities, it can be delivered over standard DIDComm channels. If one of the introducees does NOT have a DID-based channel with the introducer, then the message must be delivered to that introducee using the non-DIDComm channel. [TODO: is there a way for the introducer, rather than the other introducee, to \"sponsor\" the introducee that needs SSI onboarding?]</li> <li>If the message is delivered over a DIDComm channel, it is unusual in that it is from a party other than the one that owns the channel.</li> </ul>"},{"location":"features/0028-introduce/#request","title":"<code>request</code>","text":"<p>This message asks for an introduction to be made. This message also uses the <code>introducee descriptor</code> block, to tell the potential introducer which introducee is the object of the sender's interest:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/introduce/1.0/request\",\n  \"@id\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\",\n  \"please_introduce_to\": {\n    \"name\": \"Carol\",\n    \"description\": \"The woman who spoke after you at the PTA meeting last night.\",\n    \"expected\": true\n  },\n  \"nwise\": false,\n  \"~timing\": { \"expires_time\": \"2019-04-23 18:00Z\" }\n}\n</code></pre> <p>The recipient can choose whether or not to honor it in their own way, on their own schedule. However, a <code>problem_report</code> could be returned if the recipient chooses not to honor it.</p>"},{"location":"features/0028-introduce/#advanced-use-cases","title":"Advanced Use Cases","text":"<p>Any of the parties can be an organization or thing instead of a person.</p> <p></p> <p>Bob and Carol may actually know each other already, without Alice realizing it. The introduction may be rejected. It may create a new pairwise relationship between Bob and Carol that is entirely invisible to Alice. Or it may create an n-wise relationship in which Alice, Bob, and Carol know one another by the same identifiers.</p> <p>Some specific examples follow.</p>"},{"location":"features/0028-introduce/#one-introducee-cant-do-didcomm","title":"One introducee can't do DIDComm","text":"<p>The Out-Of-Band Protocols allow the invited party to be onboarded (acquire software and an agent) as part of the workflow.</p> <p></p> <p>Introductions support this use case, too. In such a case, the introducer sends a standard <code>proposal</code> to the introducee that DOES have DIDComm capabilities, but conveys the equivalent of a <code>proposal</code> over a non-DIDComm channel to the other introducee. The <code>response</code> from the DIDComm-capable introducee must include an out-of-band message with a deep link for onboarding, and this is sent to the introducee that needs onboarding.</p>"},{"location":"features/0028-introduce/#neither-introducee-can-do-didcomm","title":"Neither introducee can do DIDComm","text":"<p>In this case, the introducer first goes through onboarding via one of the Out-Of-Band protocols with one introducee. Once that introducee can do DIDComm, the previous workflow is used.</p>"},{"location":"features/0028-introduce/#introducer-doesnt-have-didcomm-capabilities","title":"Introducer doesn't have DIDComm capabilities","text":"<p>This might happen if AliceCorp wants to connect two of its customers. AliceCorp may not be able to talk to either of its customers over DIDComm channels, but it doesn't know whether they can talk to each other that way.</p> <p></p> <p>In this case, the introducer conveys the same information that a <code>proposal</code> would contain, using non-DIDComm channels. As long as one of the introducees sends back some kind of response that includes approval and an out-of-band message, the message can be delivered. The entire interaction is DIDComm-less.</p>"},{"location":"features/0028-introduce/#one-introducee-has-a-public-did-with-a-standing-invitation","title":"One introducee has a public DID with a standing invitation","text":"<p>This might happen if Alice wants to introduce Bob to CarolCorp, and CarolCorp has published a <code>connection-invitation</code> for general use.</p> <p></p> <p>As introducer, Alice simply has to forward CarolCorp's <code>connection-invitation</code> to Bob. No <code>proposal</code> message needs to be sent to CarolCorp; this is the <code>skip proposal</code> event shown in the introducer's state machine.</p>"},{"location":"features/0028-introduce/#introducee-requests-introduction","title":"Introducee requests introduction","text":"<p>Alice still acts as the introducer, but Bob now asks Alice to introduce him to a candidate introducee discovered a priori with the <code>help-me-discover</code> protocol:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/introduce/1.0/request\",\n  \"@id\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\",\n  \"please_introduce_to\": {\n      \"discovered\": \"didcomm:///5f2396b5-d84e-689e-78a1-2fa2248f03e4/.candidates%7B.id+%3D%3D%3D+%22Carol%22%7D\"\n  },\n  \"~timing\": { \"expires_time\": \"2019-04-23 18:00Z\" }\n}\n</code></pre> <p>This <code>request</code> message includes a <code>discovered</code> property with a linkable message path that uniquely identifies the candidate introducee.</p>"},{"location":"features/0028-introduce/#requesting-confirmation","title":"Requesting confirmation","text":"<p>[TODO: A field in the <code>response</code> where an introducee asks to be notified that the introduction has been made?]</p>"},{"location":"features/0028-introduce/#other-stuff","title":"Other stuff","text":"<ul> <li>Using acks to report status of introduction efforts.</li> <li>Timeouts.</li> <li>Introducing multiple parties at the same time?</li> </ul> <p>[TODO: What if Alice is introducing Bob, a public entity with no connection to her, to Carol, a private person? Can she just relay Bob's invitation that he published on his website? Are there security or privacy implications? What if she is introducing 2 public entities and has a connection to neither?]</p>"},{"location":"features/0028-introduce/#reference","title":"Reference","text":""},{"location":"features/0028-introduce/#proposal_1","title":"<code>proposal</code>","text":"<p>In the tutorial narrative, only a simple proposal was presented. A fancier version might be:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/introduce/1.0/proposal\",\n  \"@id\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\",\n  \"to\": {\n    \"name\": \"Kaiser Hospital\",\n    \"description\": \"Where I want to schedule your MRI. NOTE: NOT the one downtown!\",\n    \"description~l10n\": { \"locale\": \"en\", \"es\": \"Donde se toma el MRI; no en el centro\"},\n    \"where\": \"@34.0291739,-118.3589892,12z\",\n    \"img~attach\": {\n      \"description\": \"view from Marina Blvd\",\n      \"mime-type\": \"image/png\",\n      \"filename\": \"kaiser_culver_google.jpg\",\n      \"content\": {\n        \"link\": \"http://bit.ly/2FKkby3\",\n        \"byte_count\": 47738,\n        \"sha256\": \"cd5f24949f453385c89180207ddb1523640ac8565a214d1d37c4014910a4593e\"\n      }\n    },\n    \"proposed\": false\n  },\n  \"nwise\": true,\n  \"~timing\": { \"expires_time\": \"2019-04-23 18:00Z\" }\n}\n</code></pre> <p>This adds a number of fields to the introducee descriptor. Each is optional and may be appropriate in certain circumstances. Most should be self-explanatory, but the <code>proposed</code> field deserves special comment. This tells whether the described introducee has received a proposal of their own, or will be introduced without that step.</p> <p>This example also adds the <code>nwise</code> field to the proposal. When <code>nwise</code> is present and its value is <code>true</code>, the proposal is to establish an nwise relationship in which the introducer participates, as opposed to a pairwise relationship in which only the introducees participate.</p> <p>[TODO: do we care about having a response signed? Security? MITM?]</p>"},{"location":"features/0028-introduce/#errors","title":"Errors","text":"<p>[TODO: What can go wrong.]</p>"},{"location":"features/0028-introduce/#localization","title":"Localization","text":"<p>[TODO: the <code>description</code> field in an introducee descriptor. Error codes/catalog.]</p>"},{"location":"features/0028-introduce/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"features/0028-introduce/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"features/0028-introduce/#prior-art","title":"Prior art","text":"<p>Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:</p> <ul> <li>Does this feature exist in other SSI ecosystems and what experience have their community had?</li> <li>For other teams: What lessons can we learn from other attempts?</li> <li>Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.</li> </ul> <p>This section is intended to encourage you as an author to think about the lessons from other implementers, provide readers of your proposal with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if they are an adaptation from other communities.</p> <p>Note that while precedent set by other communities is some motivation, it does not on its own motivate an enhancement proposal here. Please also take into consideration that Indy sometimes intentionally diverges from common identity ../../features.</p>"},{"location":"features/0028-introduce/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"features/0028-introduce/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0030-sync-connection/","title":"Aries RFC 0030: Sync Connection Protocol 1.0","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes: Indy HIPE PR #104</li> <li>Start Date: 2018-10-01</li> <li>Tags: feature, decorator, protocol</li> </ul>"},{"location":"features/0030-sync-connection/#summary","title":"Summary","text":"<p>Define a set of non-centralized protocols (that is, ones that do not involve a common store of state like a blockchain), whereby parties using peer DIDs can synchronize the state of their shared relationship by direct communication with one another.</p>"},{"location":"features/0030-sync-connection/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> </ul>"},{"location":"features/0030-sync-connection/#motivation","title":"Motivation","text":"<p>For Alice and Bob to interact, they must establish and maintain state. This state includes all the information in a DID Document: endpoint, keys, and associated authorizations.</p> <p>The DID exchange protocol describes how these DID Docs are initially exchanged as a relationship is built. However, its mandate ends when a connection is established. This RFC focuses on how peers maintain their relationship thereafter, as DID docs evolve.</p>"},{"location":"features/0030-sync-connection/#tutorial","title":"Tutorial","text":"<p>Note 1: This RFC assumes you are thoroughly familiar with terminology and constructs from the peer DID method spec. Check there if you need background.</p> <p>Note 2: Most protocols between identity owners deal only with messages that cross a domain boundary--what Alice sends to Bob, or vice versa. What Alice does internally is generally none of Bob's business, since interoperability is a function of messages that are passed to external parties, not events that happen inside one's own domain. However, this protocol has some special requirements. Alice may have multiple agents, and Bob's behavior must account for the possibility that each of them has a different view of current relationship state. Alice has a responsibility to share and harmonize the view of state among her agents. Bob doesn't need to know exactly how she does it--but he does need to know that she's doing it, somehow--and he may need to cooperate with Alice to intelligently resolve divergences. For this reason, we describe the protocol as if it involved message passing within a domain in addition to message passing across domains. This is a simplification. The true, precise requirement for compliance is that implementers must pass messages across domains as described here, and they must appear to an outside observer as if they were passing messages within their domain as the protocol stipulates--but if they achieve the intra-domain results using some other mechanism besides DIDComm message passing, that is fine.</p>"},{"location":"features/0030-sync-connection/#name-and-version","title":"Name and Version","text":"<p>This RFC defines the <code>sync_connection</code> protocol, version 1.x, as identified by the following PIURI:</p> <pre><code>https://didcomm.org/sync_connection/1.0\n</code></pre> <p>Of course, subsequent evolutions of the protocol will replace <code>1.0</code> with an appropriate update per semver rules.</p> <p>A related, minor protocol is also defined in subdocs of this RFC:</p> <ul> <li>Abandon Connection Protocol</li> </ul>"},{"location":"features/0030-sync-connection/#roles","title":"Roles","text":"<p>The only role defined in this protocol is <code>peer</code>. However, see this note in the peer DID method spec for some subtleties.</p>"},{"location":"features/0030-sync-connection/#states","title":"States","text":"<p>This is a steady-state protocol, meaning that the state of participants does not change. Instead, all participants are continuously in a <code>syncing</code> state.</p>"},{"location":"features/0030-sync-connection/#messages","title":"Messages","text":""},{"location":"features/0030-sync-connection/#sync_state","title":"<code>sync_state</code>","text":"<p>This message announces that the sender wants to synchronize state with the recipient. This could happen because the sender suspects they are out of sync,  or because the sender wants to change the state by announcing new, never-before-seen  information. The recipient can be another agent within the same sovereign domain, or it can be an agent on the other side of the relationship. A sample looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/sync-connection/1.0/sync_state\",\n  \"@id\": \"e61586dd-f50e-4ed5-a389-716a49817207\",\n  \"for\": \"did:peer:11-479cbc07c3f991725836a3aa2a581ca2029198aa420b9d99bc0e131d9f3e2cbe\",\n  \"base_hash\": \"d48f058771956a305e12a3b062a3ac81bd8653d7b1a88dd07db8f663f37bf8e0\",\n  \"base_hash_time\": \"2019-07-23 18:05:06.123Z\",\n  \"deltas\": [\n    {\n      \"id\": \"040aaa5e-1a27-40d8-8d53-13a00b82d235\",\n      \"change\": \"ewogICJwdWJsaWNLZXkiOiBbCiAgICB...ozd1htcVBWcGZrY0pDd0R3biIKICAgIH0KICBdCn0=\",\n      \"by\": [ {\"key\": \"H3C2AVvL\", \"sig\": \"if8ooA+32YZc4SQBvIDDY9tgTa...i4VvND87PUqq5/0vsNFEGIIEDA==\"} ],\n      \"when\": \"2019-07-18T15:49:22.03Z\"\n    }\n  ]\n}\n</code></pre> <p>Note that the values in the <code>change</code> and <code>sig</code> fields have been shortened for readability.</p> <p>The properties in this message include:</p> <p>*<code>for</code>: Identifies which state is being synchronized. * <code>base_hash</code>: Identifies a shared state against which deltas should be   applied. See State Hashes for more details. * <code>base_hash_time</code>: An ISO 8601-formatted UTC timestamp,   identifying when the sender believes that the base hash became the   current state. This value need not be highly accurate, and different agents in   Alice and Bob's ecosystem may have different opinions about an appropriate   timestamp for the selected base hash. Like timestamps in email headers, it merely   provides a rough approximation of timeframe. * <code>deltas</code>: Gives a list of deltas that should be applied to the   DID doc, beginning at the specified state.</p> <p>When this message is received, the following processing happens:</p> <ul> <li>The <code>base_hash</code>  and <code>deltas</code> properties are checked for consistency. If any errors are detected, a <code>problem_report</code> message is returned, using message threading  to pinpoint the message that triggered the problem. No further processing occurs.</li> <li>If the recipient already has the same state, it sends an ACK.</li> <li>If the recipient knew about a subset of the delta, but not all of it, it applies what is left of the delta, and sends an ACK.</li> <li>If the recipient has a more evolved state, the recipient sends a reply that is a new <code>sync_state</code> message informing the sender of new information. As with the ACKs, this new message is known to be a reply to the original <code>sync_state</code> because its <code>~thread</code> decorator identifies the previous message's <code>@id</code> as its <code>thid</code>.</li> <li>If the recipient does not recognize the <code>base_hash</code>, it selects a hash from a point in time earlier than <code>base_hash_time</code> and sends back a new <code>sync_state</code> message with that earlier base.</li> <li>Because of the nature of the CRDT rules in the peer DID spec, truly problematic merge conflicts cannot occur. All objects in the DID doc that have an <code>id</code> property are immutable, and ordering of operations does not need to be highly consistent. Furthermore, an object in both deleted and undeleted state must be deemed to be deleted. However, if the recipient detects a trivial conflict, the delta with the <code>id</code> that sorts smaller/lower is selected.</li> </ul>"},{"location":"features/0030-sync-connection/#state-hashes","title":"State Hashes","text":"<p>To reliably describe the state of a DID doc at any given moment, we need a quick way to characterize its content. We could do this with a merkle tree, but the strong ordering of that structure is problematic--different participants may receive different deltas in different orders, and this is okay. What matters is whether they have applied the same set of deltas.</p> <p>To achieve this goal, the <code>id</code> properties of all received deltas are sorted and concatenated, and then the string undergoes a SHA256 hash. This produces a state hash.</p>"},{"location":"features/0030-sync-connection/#best-practices","title":"Best Practices","text":"<p>The following best practices will dramatically improve the robustness of state synchronization, both within and across domains. Software implementing this protocol is not required to do any of these things, but they are strongly recommended.</p>"},{"location":"features/0030-sync-connection/#the-state-decorator","title":"The <code>~state</code> decorator","text":"<p>Agents using peer DIDs should attach the <code>~state</code> decorator to messages to help each other discover when state synchronization is needed. This decorator has the following format:</p> <pre><code>\"~state\": [\n  {\"did\": \"&lt;my did&gt;\", \"state_hash\": \"&lt;my state hash&gt;\"},\n  {\"did\": \"&lt;your did&gt;\", \"state_hash\": \"&lt;your state hash&gt;\"}\n]\n</code></pre> <p>In n-wise relationships, there may be more than 2 entries in the list.</p> <p>The goal is to always describe the current known state hashes for each domain. It is also best practice for the recipient of the message to send a <code>sync_state</code> message back to the sender any time it detects a discrepancy.</p>"},{"location":"features/0030-sync-connection/#pending-commits","title":"Pending Commits","text":"<p>Agents should never commit to a change of state until they know that at least one other agent (on either side of the relationship) agrees to the change. This will significantly decrease the likelihood of merge conflicts. For example, an agent that wants to rotate a key should report the key rotation to someone, and receive an ACK, before it commits to use the new key. This guarantees that there will be gravitas and confirmation of the change, and is a reasonable requirement, since a change that nobody knows about is useless, anyway.</p>"},{"location":"features/0030-sync-connection/#routing-cloud-agent-rules","title":"Routing (Cloud) Agent Rules","text":"<p>It is best practice for routing agents (typically in the cloud) to enforce the following rules:</p> <ul> <li>Never deliver a message to an edge agent that shouldn't receive it, according to state  that the routing agent knows. Instead, reply with a <code>problem_report</code> about the state  being out of sync, followed by a <code>sync_state</code> message to initiate a reconciliation of  the differences.</li> <li>Never deliver a message from an agent that shouldn't be sending it, according to state that the routing agent knows. As with the previous rule, initiate a reconciliation first.</li> <li>Attempt to propagate state changes proactively.</li> </ul>"},{"location":"features/0030-sync-connection/#proactive-sync","title":"Proactive Sync","text":"<p>Any time that an agent has reason to suspect that it may be out of sync, it should attempt to reconcile. For example, if a mobile device has been turned off for an extended period of time, it should check with other agents to see if state has evolved, once it is able to communicate again.</p>"},{"location":"features/0030-sync-connection/#test-cases","title":"Test Cases","text":"<p>Because this protocol encapsulates a lot of potential complexity, and many corner cases, it is particularly important that implementations exercise the full range of scenarios in the Test Cases doc. Community members are encouraged to submit new test cases if they find situations that are not covered.</p>"},{"location":"features/0030-sync-connection/#reference","title":"Reference","text":""},{"location":"features/0030-sync-connection/#state-and-sequence-rules","title":"State and Sequence Rules","text":"<p>[TODO: create state machine matrices that show which messages can be sent in which states, causing which transitions]</p>"},{"location":"features/0030-sync-connection/#message-type-detail","title":"Message Type Detail","text":"<p>[TODO: explain every possible field of every possible message type]</p>"},{"location":"features/0030-sync-connection/#localized-message-catalog","title":"Localized Message Catalog","text":"<p>[TODO: define some localized strings that could be used with these messages, in errors or at other generally useful points?]</p>"},{"location":"features/0030-sync-connection/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0030-sync-connection/test_cases/","title":"Test Cases for Sync Connection Protocol","text":""},{"location":"features/0030-sync-connection/test_cases/#given","title":"Given","text":"<p>Let us assume that Alice and Bob each have 4 agents (A.1-A.4 and B.1-B.4, respectively), and that each of these agents possesses one key pair that's authorized to authenticate and do certain things in the DID Doc.</p> <p>A.1 and B.1 are routing (cloud) agents, where A.2-4 and B.2-4 run on edge devices that are imperfectly connected. A.1 and B.1 do not appear in the <code>authentication</code> section of their respective DID Docs, and thus cannot login on Alice and Bob's behalf.</p> <p>Let us further assume that Alice and Bob each have  two \"recovery keys\": A.5 and A.6; B.5 and B.6. These keys are not held by agents, but are printed on paper and held in a vault, or are sharded to friends. They are highly privileged but very difficult to use, since they would have to be digitized or unsharded and given to an agent before they would be useful.</p> <p>\"Admin\" operations like adding keys and granting privileges to them require either one of the privileged recovery keys, or 2 of the other agent keys to agree.</p> <p>Let us further assume that the initial state of Alice's domain, as described above, is known as A.state[0], and that Bob's state is B.state[0].</p> <p>These states may be represented by the following <code>authorization</code> section of each DID Doc:</p> <p>[TODO]</p>"},{"location":"features/0030-sync-connection/test_cases/#scenarios-each-starts-over-at-the-initial-conditions","title":"Scenarios (each starts over at the initial conditions)","text":"<ol> <li> <p>A.1 attempts to rotate its key by sending a <code>sync_state</code> message to A.2. Expected outcome: Should receive ACK, and A.2's state should be updated. Once A.1 receives the ACK, it should commit the pending change in its own  key. Until it receives the ACK, it should NOT commit the pending change.</p> </li> <li> <p>Like #1, except that message goes to B.1 and B.1's state is what should be updated.</p> </li> <li> <p>A.1 attempts to send a message to B.1, using the <code>~relstate</code> decorator, claiming states with <code>hash(A.state[0])</code> and <code>hash(B.state[0])</code>. Expected outcome: B.1 accepts the message.</p> </li> <li> <p>As #3, except that A.1 claims the current states are random hashes. Expected outcome: B.1 sends back a problem report, plus two <code>sync_state</code> messages (one with <code>who</code> = \"me\" and one with <code>who</code> = \"you\"). Each has an empty <code>deltas</code> array and <code>base_state</code> = the correct base state hash.</p> </li> <li> <p>A.1 attempts to rotate the key for A.2 by sending a <code>sync_state</code> message to any other agent. Expected outcome: change is rejected with a problem report that points out that A.1 is not authorized to rotate any key other than itself.</p> </li> </ol>"},{"location":"features/0030-sync-connection/abandon-connection-protocol/","title":"Abandon Connection Protocol 1.0","text":""},{"location":"features/0030-sync-connection/abandon-connection-protocol/#summary","title":"Summary","text":"<p>Describes how parties using peer DIDs can notify one another that they are abandoning the connection.</p>"},{"location":"features/0030-sync-connection/abandon-connection-protocol/#motivation","title":"Motivation","text":"<p>We need a way to tell another party that we are abandoning the connection. This is not strictly required, but it is good hygiene.</p>"},{"location":"features/0030-sync-connection/abandon-connection-protocol/#tutorial","title":"Tutorial","text":""},{"location":"features/0030-sync-connection/abandon-connection-protocol/#name-and-version","title":"Name and Version","text":"<p>This RFC defines the <code>abandon_connection</code> protocol, version 1.x, as identified by the following PIURI:</p> <pre><code>https://didcomm.org/abandon_connection/1.0\n</code></pre> <p>Of course, subsequent evolutions of the protocol will replace <code>1.0</code> with an appropriate update per semver rules.</p>"},{"location":"features/0030-sync-connection/abandon-connection-protocol/#roles","title":"Roles","text":"<p>This is a classic one-step notification, so it uses the predefined roles of <code>notifier</code> and <code>notified</code>.</p> <p></p>"},{"location":"features/0030-sync-connection/abandon-connection-protocol/#state-machines","title":"State Machines","text":"<p>No state changes during this protocol, although overarching state could change once it completes. Therefore no state machines are required.</p>"},{"location":"features/0030-sync-connection/abandon-connection-protocol/#messages","title":"Messages","text":""},{"location":"features/0030-sync-connection/abandon-connection-protocol/#announce","title":"<code>announce</code>","text":"<p>This message is used to announce that a party is abandoning the relationship. In a self-sovereign paradigm, abandoning a relationship can be done unilaterally, and does not require formal announcement. Indeed, sometimes a formal announcement is impossible, if one of the parties is offline. So while using this message is encouraged and best practice, it is not mandatory.</p> <p>An <code>announce</code> message from Alice to Bob looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/abandon_connection/1.0/announce\",\n  \"@id\": \"c17147d2-ada6-4d3c-a489-dc1e1bf778ab\"\n}\n</code></pre> <p>If Bob receives a message like this, he should assume that Alice no longer considers herself part of \"us\", and take appropriate action. This could include destroying data about Alice that he has accumulated over the course of their relationship, removing her peer DID and its public key(s) and endpoints from his wallet, and so forth. The nature of the relationship, the need for a historical audit trail, regulatory requirements, and many other factors may influence what's appropriate; the protocol simply requires that the message be understood to have permanent termination semantics.</p>"},{"location":"features/0031-discover-features/","title":"Aries RFC 0031: Discover Features Protocol 1.0","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED (may be RETIRED when v2.0 of the protocol has enough gravitas)</li> <li>Since: 2019-05-01</li> <li>Status Note: One of our earliest DIDComm protocols; reached FCP (standards track) status in Indy, and implemented in at least two codebases there. Converted to an Aries RFC Implemented in a handful of Aries codebases. With the advent of DIDComm v2 at DIF, it became clear that we wanted to discover ../../features beyond just protocol support, so this version of the protocol is now superseded by v2.0 in RFC 0557.</li> <li>Supersedes: Indy HIPE PR #73.</li> <li>Start Date: 2018-12-17</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"features/0031-discover-features/#summary","title":"Summary","text":"<p>Describes how agents can query one another to discover which ../../features it supports, and to what extent.</p>"},{"location":"features/0031-discover-features/#motivation","title":"Motivation","text":"<p>Though some agents will support just one protocol and will be statically configured to interact with just one other party, many exciting uses of agents are more dynamic and unpredictable. When Alice and Bob meet, they won't know in advance which ../../features are supported by one another's agents. They need a way to find out.</p>"},{"location":"features/0031-discover-features/#tutorial","title":"Tutorial","text":"<p>This RFC introduces a protocol for discussing the protocols an agent can handle. The identifier for the message family used by this protocol is <code>discover-features</code>, and the fully qualified URI for its definition is:</p> <pre><code>https://didcomm.org/discover-features/1.0\n</code></pre> <p>This protocol is now superseded by v2.0 in RFC 0557. Prefer the new version where practical.  </p>"},{"location":"features/0031-discover-features/#roles","title":"Roles","text":"<p>There are two roles in the <code>discover-features</code> protocol: <code>requester</code> and <code>responder</code>. The requester asks the responder about the protocols it supports, and the responder answers. Each role uses a single message type.</p>"},{"location":"features/0031-discover-features/#states","title":"States","text":"<p>This is a classic two-step request~response interaction, so it uses the predefined state machines for any <code>requester</code> and <code>responder</code>:</p> <p></p>"},{"location":"features/0031-discover-features/#messages","title":"Messages","text":""},{"location":"features/0031-discover-features/#query-message-type","title":"<code>query</code> Message Type","text":"<p>A <code>discover-features/query</code> message looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/1.0/query\",\n  \"@id\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\",\n  \"query\": \"https://didcomm.org/tictactoe/1.*\",\n  \"comment\": \"I'm wondering if we can play tic-tac-toe...\"\n}\n</code></pre> <p>Query messages say, \"Please tell me what your capabilities are with respect to the protocols that match this string.\" This particular example asks if another agent knows any 1.x versions of the tictactoe protocol.</p> <p>The <code>query</code> field may use the * wildcard. By itself, a query with just the wildcard says, \"I'm interested in anything you want to share with me.\" But usually, this wildcard will be to match a prefix that's a little more specific, as in the example that matches any 1.x version.</p> <p>Any agent may send another agent this message type at any time. Implementers of agents that intend to support dynamic relationships and rich ../../features are strongly encouraged to implement support for this message, as it is likely to be among the first messages exchanged with a stranger.</p>"},{"location":"features/0031-discover-features/#disclose-message-type","title":"<code>disclose</code> Message Type","text":"<p>A <code>discover-features/disclose</code> message looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/1.0/disclose\",\n  \"~thread\": { \"thid\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\" },\n  \"protocols\": [\n    {\n      \"pid\": \"https://didcomm.org/tictactoe/1.0\",\n      \"roles\": [\"player\"]\n    }\n  ]\n}\n</code></pre> <p>The <code>protocols</code> field is a JSON array of protocol support descriptor objects that match the query. Each descriptor has a <code>pid</code> that contains a protocol version (fully qualified message family identifier such as <code>https://didcomm.org/tictactoe/1.0</code>), plus a <code>roles</code> array that enumerates the roles the responding agent can play in the associated protocol.</p> <p>Response messages say, \"Here are some protocols I support that matched your query, and some things I can do with each one.\"</p>"},{"location":"features/0031-discover-features/#sparse-responses","title":"Sparse Responses","text":"<p>Responses do not have to contain exhaustive detail. For example, the following response is probably just as good:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/1.0/disclose\",\n  \"~thread\": { \"thid\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\" },\n  \"protocols\": [\n    {\"pid\": \"https://didcomm.org/tictactoe/1.0\"}\n  ]\n}\n</code></pre> <p>The reason why less detail probably suffices is that agents do not need to know everything about one another's implementations in order to start an interaction--usually the flow will organically reveal what's needed. For example, the <code>outcome</code> message in the <code>tictactoe</code> protocol isn't needed until the end, and is optional anyway. Alice can start a tictactoe game with Bob and will eventually see whether he has the right idea about <code>outcome</code> messages.</p> <p>The missing <code>roles</code> in this response does not say, \"I support no roles in this protocol.\" It says, \"I support the protocol but I'm providing no detail about specific roles.\"</p> <p>Even an empty <code>protocols</code> map does not say, \"I support no protocols that match your query.\" It says, \"I'm not telling you that I support any protocols that match your query.\" An agent might not tell another that it supports a protocol for various reasons, including: the trust that it imputes to the other party based on cumulative interactions so far, whether it's in the middle of upgrading a plugin, whether it's currently under high load, and so forth. And responses to a <code>discover-features</code> request are not guaranteed to be true forever; agents can be upgraded or downgraded, although they probably won't churn in their protocol support from moment to moment.</p>"},{"location":"features/0031-discover-features/#privacy-considerations","title":"Privacy Considerations","text":"<p>Because the regex in a <code>request</code> message can be very inclusive, the <code>discover-features</code> protocol could be used to mine information suitable for agent fingerprinting, in much the same way that browser fingerprinting works. This is antithetical to the ethos of our ecosystem, and represents bad behavior. Agents should use <code>discover-features</code> to answer legitimate questions, and not to build detailed profiles of one another. However, fingerprinting may be attempted anyway.</p> <p>For agents that want to maintain privacy, several best practices are recommended:</p>"},{"location":"features/0031-discover-features/#follow-selective-disclosure","title":"Follow selective disclosure.","text":"<p>Only reveal supported ../../features based on trust in the relationship. Even if you support a protocol, you may not wish to use it in every relationship. Don't tell others about protocols you do not plan to use with them.</p> <p>Patterns are easier to see in larger data samples. However, a pattern of ultra-minimal data is also a problem, so use good judgment about how forthcoming to be.</p>"},{"location":"features/0031-discover-features/#vary-the-format-of-responses","title":"Vary the format of responses.","text":"<p>Sometimes, you might prettify your agent plaintext message one way, sometimes another.</p>"},{"location":"features/0031-discover-features/#vary-the-order-of-items-in-the-protocols-array","title":"Vary the order of items in the <code>protocols</code> array.","text":"<p>If more than one key matches a query, do not always return them in alphabetical order or version order. If you do return them in order, do not always return them in ascending order.</p>"},{"location":"features/0031-discover-features/#consider-adding-some-spurious-details","title":"Consider adding some spurious details.","text":"<p>If a query could match multiple message families, then occasionally you might add some made-up message family names as matches. If a regex allows multiple versions of a protocol, then sometimes you might use some made-up versions. And sometimes not. (Doing this too aggressively might reveal your agent implementation, so use sparingly.)</p>"},{"location":"features/0031-discover-features/#vary-how-you-query-too","title":"Vary how you query, too.","text":"<p>How you ask questions may also be fingerprintable.</p>"},{"location":"features/0031-discover-features/#reference","title":"Reference","text":""},{"location":"features/0031-discover-features/#localization","title":"Localization","text":"<p>The <code>query</code> message contains a <code>comment</code> field that is localizable. This field is optional and may not be often used, but when it is, it is to provide a human-friendly justification for the query. An agent that consults its master before answering a query could present the content of this field as an explanation of the request.</p> <p>All message types in this family thus have the following implicit decorator:</p> <pre><code>{\n\n  \"~l10n\": {\n    \"locales\": { \"en\": [\"comment\"] },\n    \"catalogs\": [\"https://github.com/hyperledger/aries-rfcs/blob/a9ad499../../features/0031-discover-features/catalog.json\"]\n  }\n\n}\n</code></pre>"},{"location":"features/0031-discover-features/#message-catalog","title":"Message Catalog","text":"<p>As shown in the above <code>~l10n</code> decorator, all agents using this protocol have a simple message catalog in scope. This allows agents to send <code>problem-report</code>s to complain about something related to <code>discover-features</code> issues. The catalog looks like this (see catalog.json):</p> <pre><code>{\n  \"query-too-intrusive\": {\n    \"en\": \"Protocol query asked me to reveal too much information.\"\n  }\n}\n</code></pre> <p>For more information, see the localization RFC.</p>"},{"location":"features/0031-discover-features/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Do we want to support the discovery of ../../features that are not protocol-related?</li> </ul>"},{"location":"features/0031-discover-features/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Streetcred.id Commercial mobile and web app built using Aries Framework - .NET MISSING test results Aries Protocol Test Suite"},{"location":"features/0032-message-timing/","title":"Aries RFC 0032: Message Timing","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: DEMONSTRATED</li> <li>Since: 2019-05-01</li> <li>Status Note: Broadly socialized but not yet implemented. </li> <li>Supersedes: Indy RFC PR #68</li> <li>Start Date: 2018-12-11</li> <li>Tags: feature</li> </ul>"},{"location":"features/0032-message-timing/#summary","title":"Summary","text":"<p>Explain how timing of agent messages can be communicated and constrained.</p>"},{"location":"features/0032-message-timing/#motivation","title":"Motivation","text":"<p>Many timing considerations influence asynchronous messaging delivery. We need a standard way to talk about them.</p>"},{"location":"features/0032-message-timing/#tutorial","title":"Tutorial","text":"<p>This RFC introduces a decorator to communicate about timing of messages. It is compatible with, but independent from, conventions around date and time fields in messages.</p> <p>Timing attributes of messages can be described with the <code>~timing</code> decorator. It offers a number of optional subfields:</p> <pre><code>\"~timing\": {\n  \"in_time\":  \"2019-01-23 18:03:27.123Z\",\n  \"out_time\": \"2019-01-23 18:03:27.123Z\",\n  \"stale_time\": \"2019-01-24 18:25Z\",\n  \"expires_time\": \"2019-01-25 18:25Z\",\n  \"delay_milli\": 12345,\n  \"wait_until_time\": \"2019-01-24 00:00Z\"\n}\n</code></pre> <p>The meaning of these fields is:</p> <ul> <li><code>in_time</code>: The timestamp when the preceding message in this thread   (the one that elicited this message as a response) was received. Or, on   a dynamically composed <code>forward</code> message, the timestamp when an upstream   relay first received the message it's now asking to be forwarded.</li> <li><code>out_time</code>: The timestamp when the message was emitted. At least millisecond   precision is preferred, though second precision is acceptable.</li> <li><code>stale_time</code>: Ideally, the decorated message should be processed by the   the specified timestamp. After that, the message may become irrelevant   or less meaningful than intended. This is a hint only.</li> <li><code>expires_time</code>: The decorated message should be considered invalid or expired   if encountered after the specified timestamp. This is a much stronger claim   than the one for <code>stale_time</code>; it says that the receiver should cancel   attempts to process it once the deadline is past, because the sender won't   stand behind it any longer. While processing of the received message should   stop, the thread of the message should be retained as the sender may send an   updated/replacement message. In the case that the sender does not follow up,   the policy of the receiver agent related to abandoned threads would presumably   be used to eventually delete the thread.</li> <li><code>delay_milli</code>: Wait at least this many milliseconds before processing the   message. This may be useful to defeat temporal correlation. It is recommended   that agents supporting this field should not honor requests for delays longer   than 10 minutes (600,000 milliseconds).</li> <li><code>wait_until_time</code>: Wait until this time before processing the message.</li> </ul> <p>All information in these fields should be considered best-effort. That is, the sender makes a best effort to communicate accurately, and the receiver makes a best effort to use the information intelligently. In this respect, these values are like timestamps in email headers--they are generally useful, but not expected to be perfect. Receivers are not required to honor them exactly.</p> <p>An agent may ignore the <code>~timing</code> decorator entirely or implement the <code>~timing</code> decorator and silently ignore any of the fields it chooses not to support.</p>"},{"location":"features/0032-message-timing/#timing-in-routing","title":"Timing in Routing","text":"<p>Most usage of the <code>~timing</code> decorator is likely to focus on application-oriented messages processed at the edge. <code>in_time</code> and <code>out_time</code>, for example, are mainly useful so Bob can know how long Alice took to ponder her response to his love letter. In onion routing, where one edge agent prepares all layers of the <code>forward</code> wrapping, it makes no sense to apply them to <code>forward</code> messages. However, if a relay is composing new <code>forward</code> messages dynamically, these fields could be used to measure the delay imposed by that relay. All the other fields have meaning in routing.</p>"},{"location":"features/0032-message-timing/#timing-and-threads","title":"Timing and Threads","text":"<p>When a message is a reply, then <code>in_time</code> on an application-focused message is useful. However, <code>out_time</code> and all other fields are meaningful regardless of whether threading is active.</p>"},{"location":"features/0032-message-timing/#reference","title":"Reference","text":"<ul> <li>Discussion of date and time datatypes on Wikipedia</li> <li>ISO 8601</li> </ul>"},{"location":"features/0032-message-timing/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes RFC 0193: Coin Flip Protocol Uses <code>~timing.expires_time</code> to time out each step of the coin flip."},{"location":"features/0034-message-tracing/","title":"Aries RFC 0034: Message Tracing","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: PROPOSED</li> <li>Since: 2018-10-24</li> <li>Status Note: Not yet implemented broadly, but Evernym has been exploring it as a solution to some debugging needs.</li> <li>Start Date: 2018-10-24</li> <li>Tags: feature, decorator</li> </ul>"},{"location":"features/0034-message-tracing/#summary","title":"Summary","text":"<p>Define a mechanism to track what happens in a complex DIDComm interactions, to make troubleshooting and auditing easier.</p>"},{"location":"features/0034-message-tracing/#motivation","title":"Motivation","text":"<p>Anyone who has searched trash and spam folders for a missing email knows that when messages don't elicit the expected reaction, troubleshooting can be tricky. Aries-style agent-to-agent communication is likely to manifest many of the same challenges as email, in that it may be routed to multiple places, by multiple parties, with incomplete visibility into the meaning or state associated with individual messages. Aries's communication is even more opaque than ordinary email, in that it is transport agnostic and encrypted...</p> <p>In a future world where DIDComm technology is ubiquitous, people may send messages from one agent to another, and wonder why nothing happened, or why a particular error is reported. They will need answers.</p> <p>Also, developers and testers who are working with DIDComm-based protocols need a way to debug.</p>"},{"location":"features/0034-message-tracing/#tutorial","title":"Tutorial","text":""},{"location":"features/0034-message-tracing/#basics","title":"Basics","text":"<p>Many systems that deliver physical packages offer a \"cerified delivery\" or \"return receipt requested\" feature. To activate the feature, a sender affixes a special label to the package, announcing who should be notified, and how. Handlers of the package then cooperate to satisfy the request.</p> <p></p> <p>DIDComm thread tracing works on a similar principle. When tracing is desired, a sender adds to the normal message metadata a special decorator that the message handler can see. If the handler notices the decorator and chooses to honor the request, it emits a notification to provide tracing.</p> <p>The main complication is that DIDComm message routing uses nested layers of encryption. What is visible to one message handler may not be visible to another. Therefore, the decorator must be repeated in every layer of nesting where tracing is required. Although this makes tracing somewhat verbose, it also provides precision; troubleshooting can focus only on one problematic section of an overall route, and can degrade privacy selectively.</p>"},{"location":"features/0034-message-tracing/#decorator","title":"Decorator","text":"<p>Tracing is requested by decorating the JSON plaintext of an DIDComm message (which will  often be a forward message, but could also be the terminal message unpacked  and handled at its final destination) with the <code>~trace</code> attribute. Here is the simplest possible example:</p> <pre><code>{\n  \"@type\": \"did:sov:BzCBs...;spec/routing/1.0/forward\",\n  \"@id\": \"abc-def-...\",\n  \"msg\": \"U2Vl...\",\n  \"~trace\": {\n    \"target\": \"http://example.com/tracer\",\n    \"full_thread\": true\n  }\n}\n</code></pre> <p>The <code>\"target\"</code> can refer to a url (as above) or the term <code>\"log\"</code>, which is a request to append trace information to the standard log file.  (Information can then be manually collated from agents.)</p> <p>This example asks the handler of the message to perform an HTTP POST of a trace report about the message to the URI <code>http://example.com/tracer</code>.</p> <p>The service listening for trace reports--called the trace sink-- doesn't have to have any special characteristics, other than support for HTTP 1.1 or SMTP (for <code>mailto:</code> URIs) and the ability to receive small plaintext payloads rapidly. It may use TLS, but it is not required to. If TLS is used, the parties that submit reports should accept the certificate without strong checking, even if it is expired or invalid. The rationale for this choice is:</p> <ol> <li>It is the sender's trust in the tracing service, not the handler's trust, that matters.</li> <li>Tracing is inherently unsafe and non-privacy-preserving, in that it introduces    an eavesdropper and a channel with uncertain security guarantees. Trying to secure the    eavesdropper is a waste of effort.</li> <li>Introducing a strong dependency on PKI-based trust into a protocol that exists to improve    PKI feels wrong-headed.</li> <li>When tracing is needed, the last thing we should do is create another fragility to    troubleshoot.</li> </ol>"},{"location":"features/0034-message-tracing/#trace-reports","title":"Trace Reports","text":"<p>The body of the HTTP request (the trace report) is a JSON document that looks like this:</p> <pre><code>{\n  \"@type\": \"did:sov:BzCBs...;spec/1.0/trace_report\",\n  \"msg_id\": \"abc-def-...df\",\n  \"thread_id\": \"hij-klm-nop-...qr\",\n  \"handler\": \"did:sov:1234abcd#3\",\n  \"ellapsed_milli\": 27,\n  \"traced_type\": \"did:sov:BzCBs...;spec/routing/1.0/forward\",\n  \"str_time\": \"2018-03-27 18:23:45.123Z\",\n  \"timestamp\": \"1234567890.123456\",\n  \"outcome\": \"OK ...\"\n}\n</code></pre>"},{"location":"features/0034-message-tracing/#subtleties","title":"Subtleties","text":""},{"location":"features/0034-message-tracing/#message-ids","title":"Message IDs","text":"<p>If messages have a different <code>@id</code> attribute at each hop in a delivery chain, then a trace of the message at hop 1 and a trace of the message at hop 2 will not appear to have any connection when the reports are analyzed together.</p> <p></p> <p>To solve this problem, traced messages may use an ID convention that permits ordering. Assume that the inner application message has a base ID, X. Containing messages (e.g., <code>forward</code> messages) have IDs in the form X.1, X.2, X.3, and so forth -- where numbers represent the order in which the messages will be handled. Notice in the sample trace report above that the <code>for_id</code> of the trace report message is <code>98fd8d72-80f6-4419-abc2-c65ea39d0f38.1</code>. This implies that it is tracing the first hop of inner, application message with id <code>98fd8d72-80f6-4419-abc2-c65ea39d0f38</code>.</p>"},{"location":"features/0034-message-tracing/#delegation","title":"Delegation","text":"<p>Sometimes, a message is sent before it is fully wrapped for all hops in its route. This can happen, for example, if Alice's edge agent delegates to Alice's cloud agent the message preparation for later stages of routing.</p> <p>In such cases, tracing for the delegated portion of the route should default to inherit the tracing choice of the portion of the route already seen. To override this, the <code>~trace</code> decorator placed on the initial message from Alice's edge to Alice's cloud can include the optional <code>full-route</code> attribute, with its value set to <code>true</code> or <code>false</code>.</p> <p>This tells handlers that are wrapping subsequent portions of a routed message to either propagate or truncate the routing request in any new <code>forward</code> messages they compose.</p>"},{"location":"features/0034-message-tracing/#timing-and-sequencing","title":"Timing and Sequencing","text":"<p>Each trace report includes a UTC timestamp from the reporting handler. This timestamp should be computed at the instant a trace report is prepared--not when it is queued or delivered. Even so, it offers only a rough approximation of when something happened. Since system clocks from handlers may not be synchronized, there is no guarantee of precision or of agreement among timestamps.</p> <p>In addition, trace reports may be submitted asynchronously with respect to the message handling they document. Thus, a trace report could arrive out of sequence, even if the handling it describes occurred correctly. This makes it vital to order trace reports according to the ID sequencing convention described above.</p>"},{"location":"features/0034-message-tracing/#tracing-the-original-sender","title":"Tracing the original sender","text":"<p>The original sender may not run a message handling routine that triggers tracing. However, as a best practice, senders that enable tracing should send a trace report when they send, so the beginning of a routing sequence is documented. This report should reference X.0 in <code>for_id</code>, where X is the ID of the inner application message for the final recipient.</p>"},{"location":"features/0034-message-tracing/#handling-a-message-more-than-once","title":"Handling a message more than once","text":"<p>A particular handler may wish to document multiple phases of processing for a message. For example, it may choose to emit a trace report when the message is received, and again when the message is \"done.\" In such cases, the proper sequence of the two messages, both of which will have the same <code>for_id</code> attribute, is given by the relative sequence of the timestamps.</p> <p>Processing time for each handler--or for phases within a handler--is given by the <code>elapsed_milli</code> attribute.</p>"},{"location":"features/0034-message-tracing/#privacy","title":"Privacy","text":"<p>Tracing inherently compromises privacy. It is totally voluntary, and handlers should not honor trace requests if they have reason to believe they have been inserted for nefarious purposes. However, the fact that the trace reports can only be requested by the same entities that send the messages, and that they are encrypted in the same way as any other plaintext that a handler eventually sees, puts privacy controls in the hands of the ultimate sender and receiver.</p>"},{"location":"features/0034-message-tracing/#tracing-entire-threads","title":"Tracing entire threads","text":"<p>If a sender wishes to enable threading for an entire multi-step interaction between multiple parties, the <code>full_thread</code> attribute can be included on an inner application, with its value set to <code>true</code>. This signals to recipients that the sender wishes to have tracing turned on until the interaction is complete. Recipients may or may not honor such requests. If they don't, they may choose to send an error to the sender explaining why they are not honoring the request.</p>"},{"location":"features/0034-message-tracing/#reference","title":"Reference","text":""},{"location":"features/0034-message-tracing/#trace-decorator-trace","title":"Trace decorator (<code>~trace</code>)","text":"<p>Value is any URI. At least <code>http</code>, <code>https</code>, and <code>mailto</code> should be supported. If mail is sent, the message subject should be \"trace report for ?\", where ? is the value of the <code>for_id</code> attribute in the report, and the email body should contain the plaintext of the report, as utf8.</p>"},{"location":"features/0034-message-tracing/#trace-report-attributes","title":"Trace Report Attributes","text":"<ul> <li><code>@type</code>: Should always be <code>\"https://didcomm.org/tracing/1.0/trace_report\"</code>,    or some evolved version thereof. Required for version control and to support trace sinks    that process other HTTP payloads as well.</li> <li><code>msg_id</code>: The ID of the message that the handler is looking at when it composes the    trace report. Required.</li> <li><code>thread_id</code>: The ID of the protocol thread.  Required.</li> <li><code>handler</code>: A string that identifies the handler in a way that's useful for troubleshooting purposes.    For example, it might identify a particular agent by DID+keyref, or it might be a friendly    string like \"iPhone\" or \"AgentsRUs Cloud Agent, geocaching extension v1.3.7\". Optional but    encouraged.</li> <li><code>elapsed_milli</code>: How many milliseconds did the handler have this message before composing    the trace report? If the same handler emits more than one trace report, how long has it    been since the last trace was composed? Optional but encouraged.</li> <li><code>traced_type</code>: What was the message type of the traced message? Optional but encouraged.</li> <li><code>str_time</code>: What was the UTC timestamp of the system clock of the handler    when the handler composed the trace report? ISO 8601 format with millisecond precision.    Optional but encouraged.</li> <li><code>timestamp</code>: Value fo the <code>str_time</code> field in milliseconds (UNIX time format).</li> <li><code>outcome</code>: A string that describes the outcome of the message handling. The string MUST   begin with one of the following tokens: <code>\"OK\"</code> (meaning the handler completed its processing   successfully; <code>\"ERR\"</code> (the handler failed), or <code>\"PEND\"</code> (the handler is still working on the   message and does not know the final outcome). After this token, the string SHOULD contain   a parenthetical explanation suitable for use by humans that want to troubleshoot. For <code>forward</code>   messages that have an outcome of <code>OK</code>, the recommended explanation is something like   <code>\"(forwarded to did:sov:1234abcd#4)\"</code>.</li> </ul>"},{"location":"features/0034-message-tracing/#drawbacks","title":"Drawbacks","text":"<p>Tracing makes network communication quite noisy. It imposes a burden on message handlers. It may also incur performance penalties.</p>"},{"location":"features/0034-message-tracing/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Wireshark and similar network monitoring tools could give some visibility into agent-to-agent interactions. However, it would be hard to make sense of bytes on the wire, due to encryption and the way individual messages may be divorced from routing or thread context.</p> <p>Proprietary tracing could be added to the agents built by particular vendors. However, this would have limited utility if an interaction involved software not made by that vendor.</p>"},{"location":"features/0034-message-tracing/#prior-art","title":"Prior art","text":"<p>The message threading RFC and the error reporting RFC touch on similar subjects, but are distinct.</p>"},{"location":"features/0034-message-tracing/#unresolved-questions","title":"Unresolved questions","text":"<p>None.</p>"},{"location":"features/0034-message-tracing/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0035-report-problem/","title":"Aries RFC 0035: Report Problem Protocol 1.0","text":"<ul> <li>Authors: Stephen Curran, Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Implemented in multiple codebases.</li> <li>Supersedes: Indy HIPE PR #65</li> <li>Start Date: 2018-11-26</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"features/0035-report-problem/#summary","title":"Summary","text":"<p>Describes how to report errors and warnings in a powerful, interoperable way. All implementations of SSI agent or hub technology SHOULD implement this RFC.</p>"},{"location":"features/0035-report-problem/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> </ul>"},{"location":"features/0035-report-problem/#motivation","title":"Motivation","text":"<p>Effective reporting of errors and warnings is difficult in any system, and particularly so in decentralized systems such as remotely collaborating agents. We need to surface problems, and their supporting context, to people who want to know about them (and perhaps separately, to people who can actually fix them). This is especially challenging when a problem is detected well after and well away from its cause, and when multiple parties may need to cooperate on a solution.</p> <p>Interoperability is perhaps more crucial with problem reporting than with any other aspect of DIDComm, since an agent written by one developer MUST be able to understand an error reported by an entirely different team. Notice how different this is from normal enterprise software development, where developers only need to worry about understanding their own errors.</p> <p>The goal of this RFC is to provide agents with tools and techniques possible to address these challenges. It makes two key contributions:</p> <ul> <li>A protocol that helps an Agent report problems with appropriate   context. We expect this to be a subprotocol of nearly every interesting application-level   protocol; messages from it may even be adopted into other protocols.</li> <li>An inventory of problem categories and best practices for handling them.</li> </ul>"},{"location":"features/0035-report-problem/#tutorial","title":"Tutorial","text":""},{"location":"features/0035-report-problem/#error-vs-warning-vs-problem","title":"\"Error\" vs. \"Warning\" vs. \"Problem\"","text":"<p>The distinction between \"error\" and \"warning\" is often thought of as one of severity -- errors are really bad, and warnings are only somewhat bad. This is reinforced by the way logging platforms assign numeric constants to ERROR vs. WARN log events, and by the way compilers let warnings be suppressed but refuse to ignore errors.</p> <p>However, any cybersecurity professional will tell you that warnings sometimes signal deep and scary problems that should not be ignored, and most veteran programmers can tell war stories that reinforce this wisdom. A deeper analysis of warnings reveals that what truly differentiates them from errors is not their lesser severity, but rather their greater ambiguity. Warnings are problems that require human judgment to evaluate, whereas errors are unambiguously bad.</p> <p>The mechanism for reporting problems in DIDComm cannot make a simplistic assumption that all agents are configured to run with a particular verbosity or debug level. Each agent must let other agents decide for themselves, based on policy or user preference, what do do about various issues. For this reason, we use the generic term \"problem\" instead of the more specific and semantically opinionated term \"error\" (or \"warning\") to describe the general situation we're addressing. \"Problem\" includes any deviation from the so-called \"happy path\" of an interaction. This could include situations where the severity is unknown and must be evaluated by a human, as well as surprising events (e.g., a decision by a human to alter the basis for in-flight messaging by moving from one device to another).</p>"},{"location":"features/0035-report-problem/#specific-challenges","title":"Specific Challenges","text":"<p>All of the following challenges need to be addressed.</p> <ol> <li>Report problems to external parties interacting with us.   For example, AliceCorp has to be able to tell Bob that it can\u2019t issue the   credential he requested because his payment didn\u2019t go through.</li> <li>Report problems to other entities inside our own domain. For example,   AliceCorp\u2019s agent #1 has to be able to report to AliceCorp agent #2 that   it is out of disk space.</li> <li>Report in a way that provides human beings with useful context and guidance   to troubleshoot.   Most developers know of cases where error reporting was technically correct but   completely useless. Bad communication about problems is one of the most common   causes of UX debacles. Humans using agents will speak different languages, have   differing degrees of technical competence, and have different software and hardware   resources. They may lack context about what their agents are doing, such as when   a DIDComm interaction occurs as a result of scheduled or policy-driven actions.   This makes context and guidance crucial.</li> <li>Map a problem backward in time, space, and circumstances, so when it is   studied, its original context is available. This is particularly difficult   in DIDComm, which is transport-agnostic and inherently asynchronous, and   which takes place on an inconsistently connected digital landscape.</li> <li>Support localization using techniques in the l10n RFC.</li> <li>Provide consistent, locale-independent problem codes, not just localized text,   so problems can be researched in knowledge bases, on Stack Overflow, and in   other internet forums, regardless of the natural language in which a message   displays. This also helps meaning remain stable as wording is tweaked.</li> <li>Provide a registry of well known problem codes that are carefully defined and   localized, to maximize shared understanding. Maintaining an exhaustive list   of all possible things that can go wrong with all possible agents in all possible   interactions is completely unrealistic. However, it may be possible to maintain   a curated subset. While we can't enumerate everything that can go wrong in a   financial transaction, a code for \"insufficient funds\" might have near-universal   usefulness. Compare the posix error inventory in errorno.h.</li> <li>Facilitate automated problem handling by agents, not just manual handling by humans.   Perfect automation may be impossible, but high levels of automation should be   doable.</li> <li>Clarify how the problem affects an in-progress interaction. Does a failure to   process payment reset the interaction to the very beginning of the protocol, or   just back to the previous step, where payment was requested? This requires problems   to be matched in a formal way to the state machine of a protocol underway.</li> </ol>"},{"location":"features/0035-report-problem/#the-report-problem-protocol","title":"The <code>report-problem</code> protocol","text":"<p>Reporting problems uses a simple one-step notification protocol. Its official PIURI is:</p> <pre><code>https://didcomm.org/report-problem/1.0\n</code></pre> <p>The protocol includes the standard <code>notifier</code> and <code>notified</code> roles. It defines a single message type <code>problem-report</code>, introduced here.</p> <p>A <code>problem-report</code> communicates about a problem when an agent-to-agent message is possible and a recipient for the problem report is known. This covers, for example, cases where a Sender's message gets to an intended Recipient, but the Recipient is unable to process the message for some reason and wants to notify the Sender. It may also be relevant in cases where the recipient of the <code>problem-report</code> is not a message Sender. Of course, a reporting technique that depends on message delivery doesn't apply when the error reporter can't identify or communicate with the proper recipient.</p>"},{"location":"features/0035-report-problem/#the-problem-report-message-type","title":"The <code>problem-report</code> message type","text":"<p>Only <code>description.code</code> is required, but a maximally verbose <code>problem-report</code> could contain all of the following:</p> <pre><code>{\n  \"@type\"            : \"https://didcomm.org/report-problem/1.0/problem-report\",\n  \"@id\"              : \"an identifier that can be used to discuss this error message\",\n  \"~thread\"          : \"info about the threading context in which the error occurred (if any)\",\n  \"description\"      : { \"en\": \"localized message\", \"code\": \"symbolic-name-for-error\" },\n  \"problem_items\"    : [ {\"&lt;item descrip&gt;\": \"value\"} ],\n  \"who_retries\"      : \"enum: you | me | both | none\",\n  \"fix_hint\"         : { \"en\": \"localized error-instance-specific hint of how to fix issue\"},\n  \"impact\"           : \"enum: message | thread | connection\",\n  \"where\"            : \"enum: you | me | other - enum: cloud | edge | wire | agency | ..\",\n  \"noticed_time\"     : \"&lt;time&gt;\",\n  \"tracking_uri\"     : \"\",\n  \"escalation_uri\"   : \"\"\n}\n</code></pre>"},{"location":"features/0035-report-problem/#field-reference","title":"Field Reference","text":"<p>Some fields will be relevant and useful in many use cases, but not always. Including empty or null fields is discouraged; best practice is to include as many fields as you can fill with useful data, and to omit the others.</p> <p>@id: An identifier for this message, as described in the message threading RFC. This decorator is STRONGLY recommended, because enables a dialog about the problem itself in a branched thread (e.g., suggest a retry, report a resolution, ask for more information).</p> <p>~thread: A thread decorator that places the <code>problem-report</code> into a thread context. If the problem was triggered in the processing of a message, then the triggering message is the head of a new thread of which the problem report is the second member (<code>~thread.sender_order</code> = 0). In such cases, the <code>~thread.pthid</code> (parent thread id) here would be the <code>@id</code> of the triggering message. If the problem-report is unrelated to a message, the thread decorator is mostly redundant, as <code>~thread.thid</code> must equal <code>@id</code>.</p> <p>description: Contains human-readable, localized alternative string(s) that explain the problem. It is highly recommended that the message follow use the guidance in the l10n RFC, allowing the error to be searched on the web and documented formally.</p> <p>description.code: Required. Contains the code that indicates the problem being communicated. Codes are described in protocol RFCs and other relevant places. New Codes SHOULD follow the Problem Code naming convention detailed in the DIDComm v2 spec.</p> <p>problem_items: A list of one or more key/value pairs that are parameters about the problem. Some examples might be:</p> <ul> <li>a list of arguments that didn\u2019t pass input validation</li> <li>the name of a file or URL that could not be fetched</li> <li>the name of a crypto algorithm that the receiving agent didn\u2019t support</li> </ul> <p>All items should have in common the fact that they exemplify the problem described by the code (e.g., each is an invalid param, or each is an unresponsive URL, or each is an unrecognized crypto algorithm, etc).</p> <p>Each item in the list must be a tagged pair (a JSON {key:value}, where the key names the parameter or item, and the value is the actual problem text/number/value. For example, to report that two different endpoints listed in party B\u2019s DID Doc failed to respond when they were contacted, the code might contain \"endpoint-not-responding\", and the problem_items property might contain:</p> <pre><code>[\n  {\"endpoint1\": \"http://agency.com/main/endpoint\"},\n  {\"endpoint2\": \"http://failover.agency.com/main/endpoint\"}\n]\n</code></pre> <p>who_retries: value is the string \"you\", the string \"me\", the string \"both\", or the string \"none\". This property tells whether a problem is considered permanent and who the sender of the problem report believes should have the responsibility to resolve it by retrying. Rules about how many times to retry, and who does the retry, and under what circumstances, are not enforceable and not expressed in the message text. This property is thus not a strong commitment to retry--only a recommendation of who should retry, with the assumption that retries will often occur if they make sense.</p> <p>[TODO: figure out how to identify parties &gt; 2 in n-wise interaction]</p> <p>fix_hint: Contains human-readable, localized suggestions about how to fix this instance of the problem. If present, this should be viewed as overriding general hints found in a message catalog.</p> <p>impact: A string describing the breadth of impact of the problem. An enumerated type:</p> <ul> <li>\"message\" (this is a problem with a single message only; the rest of the interaction may still be fine),</li> <li>\"thread\" (this is a problem that endangers or invalidates the entire thread),</li> <li>\"connection\" (this is a problem that endangers or invalidates the entire connection).</li> </ul> <p>where: A string that describes where the error happened, from the perspective of the reporter, and that uses the \"you\" or \"me\" or \"other\" prefix, followed by a suffix like \"cloud\", \"edge\", \"wire\", \"agency\", etc.</p> <p>noticed_time: Standard time entry (ISO-8601 UTC with at least day precision and up to millisecond precision) of when the problem was detected.</p> <p>[TODO: should we refer to timestamps in a standard way (\"date\"? \"time\"? \"timestamp\"? \"when\"?)]</p> <p>tracking_uri: Provides a URI that allows the recipient to track the status of the error. For example, if the error is related to a service that is down, the URI could be used to monitor the status of the service, so its return to operational status could be automatically discovered.</p> <p>escalation_uri: Provides a URI where additional help on the issue can be received. For example, this might be a \"mailto\" and email address for the Help Desk associated with a currently down service.</p>"},{"location":"features/0035-report-problem/#sample","title":"Sample","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/notification/1.0/problem-report\",\n  \"@id\": \"7c9de639-c51c-4d60-ab95-103fa613c805\",\n  \"~thread\": {\n    \"pthid\": \"1e513ad4-48c9-444e-9e7e-5b8b45c5e325\",\n    \"sender_order\": 1\n  },\n  \"~l10n\"            : {\"catalog\": \"https://didcomm.org/error-codes\"},\n  \"description\"      : \"Unable to find a route to the specified recipient.\",\n  \"description~l10n\" : {\"code\": \"cant-find-route\" },\n  \"problem_items\"    : [\n      { \"recipient\": \"did:sov:C805sNYhMrjHiqZDTUASHg\" }\n  ],\n  \"who_retries\"      : \"you\",\n  \"impact\"           : \"message\",\n  \"noticed_time\"     : \"2019-05-27 18:23:06Z\"\n}\n</code></pre>"},{"location":"features/0035-report-problem/#categorized-examples-of-errors-and-current-best-practice-handling","title":"Categorized Examples of Errors and (current) Best Practice Handling","text":"<p>The following is a categorization of a number of examples of errors and (current) Best Practice handling for those types of errors. The new <code>problem-report</code> message type is used for some of these categories, but not all.</p>"},{"location":"features/0035-report-problem/#unknown-error","title":"Unknown Error","text":"<p>Errors of a known error code will be processed according to the understanding of what the code means. Support of a protocol includes support and proper processing of the error codes detailed within that protocol.</p> <p>Any unknown error code that starts with <code>w.</code> in the DIDComm v2 style may be considered a warning, and the flow of the active protocol SHOULD continue. All other unknown error codes SHOULD be considered to be an end to the active protocol.</p>"},{"location":"features/0035-report-problem/#error-while-processing-a-received-message","title":"Error While Processing a Received Message","text":"<p>An Agent Message sent by a Sender and received by its intended Recipient cannot be processed.</p>"},{"location":"features/0035-report-problem/#examples","title":"Examples:","text":"<ul> <li>An error occurs in the processing of the message (e.g. missing required parameters, bad data in parameters, etc.)</li> <li>The recipient has no message handler for the message type</li> <li>A message request is rejected because of a policy</li> <li>\"Access denied\" scenarios</li> </ul>"},{"location":"features/0035-report-problem/#recommended-handling","title":"Recommended Handling","text":"<p>The Recipient should send the Sender a <code>problem-report</code> Agent Message detailing the issue.</p> <p>The last example deserves an additional comment about whether there should be a response sent at all. Particularly in cases where trust in the message sender is low (e.g. when establishing the connection), an Agent may not want to send any response to a rejected message as even a negative response could reveal correlatable information. That said, if a response is provided, the <code>problem-report</code> message type should be used.</p>"},{"location":"features/0035-report-problem/#error-while-routing-a-message","title":"Error While Routing A Message","text":"<p>An Agent in the routing flow of getting a message from a Sender to the Agent Message Recipient cannot route the message.</p>"},{"location":"features/0035-report-problem/#examples_1","title":"Examples:","text":"<ul> <li>Unknown \"To\" destination for the message</li> <li>Insufficient resources (disk space, network access)</li> <li>Unable to decrypt the message</li> </ul>"},{"location":"features/0035-report-problem/#recommended-handling_1","title":"Recommended Handling","text":"<p>If the Sender is known to the Agent having the problem, send a <code>problem-report</code> Agent Message detailing at least that a blocking issue occurred, and if relevant (such as in the first example), some details about the issue. If the message is valid, and the problem is related to a lack of resources (e.g. the second issue), also send a <code>problem-report</code> message to an escalation point within the domain.</p> <p>Alternatively, the capabilities described in 0034: Message Tracing could be used to inform others of the fact that an issue occurred.</p>"},{"location":"features/0035-report-problem/#messages-triggered-about-a-transaction","title":"Messages Triggered about a Transaction","text":""},{"location":"features/0035-report-problem/#examples_2","title":"Examples:","text":"<ul> <li>\"You\u2019re asking for more information than we agreed to\" or \"You\u2019re giving me more than I expected.\"</li> <li>Couldn\u2019t pay (insufficient funds, payment mechanism is offline\u2026)</li> <li>You violated the terms of service we agreed to, because I see that my info has been leaked.</li> <li>Your credential has been revoked (asynchronous)</li> <li>A is unwilling to consent to the terms and conditions that B proposes.</li> </ul>"},{"location":"features/0035-report-problem/#recommended-handling_2","title":"Recommended Handling","text":"<p>These types of error scenarios represent a gray error in handling between using the generic <code>problem-report</code> message format, or a message type that is part of the current transaction's message family. For example, the \"Your credential has been revoked\" might well be included as a part of the (TBD) standard Credentials Exchange message family. The \"more information\" example might be a generic error across a number of message families and so should trigger a <code>problem-report</code>) or, might be specific to the ongoing thread (e.g. Credential Exchange) and so be better handled by a defined message within that thread and that message family.</p> <p>The current advice on which to use in a given scenario is to consider how the recipient will handle the message. If the handler will need to process the response in a specific way for the transaction, then a message family-specific message type should be used. If the error is cross-cutting such that a common handler can be used across transaction contexts, then a generic <code>problem-report</code> should be used.</p> <p>\"Current advice\" implies that as we gain more experience with Agent To Agent messaging, the recommendations could get more precise.</p>"},{"location":"features/0035-report-problem/#messaging-channel-settings","title":"Messaging Channel Settings","text":""},{"location":"features/0035-report-problem/#examples_3","title":"Examples","text":"<ul> <li>\"Please resend so a different one of my agents can read this.\", or, \"Agent X no longer in service. Use Agent Y instead.\"</li> <li>A received a message from B that it cannot understand (message garbled, can\u2019t be decrypted, is of an unrecognized type, uses crypto from a library that A doesn\u2019t have, etc)</li> <li>A wants to report to B that it believes A has been hacked, or that it is under attack</li> <li>A wants to report to B that it believes B has been hacked, or that it is under attack</li> <li>Version incompatibilities of various kinds (transport version incompatibilities [http 1.1 vs. 2.0]; agent message type version incompatibilities)</li> </ul>"},{"location":"features/0035-report-problem/#recommended-handling_3","title":"Recommended Handling","text":"<p>These types of messages might or might not be triggered during the receipt and processing of a message, but either way, they are unrelated to the message and are really about the communication channel between the entities. In such cases, the recommended approach is to use a (TBD) standard message family to notify and rectify the issue (e.g. change the attributes of a connection). The definition of that message family is outside the scope of this RFC.</p>"},{"location":"features/0035-report-problem/#timeouts","title":"Timeouts","text":"<p>A special generic class of errors that deserves mention is the timeout, where a Sender sends out a message and does not receive back a response in a given time. In a distributed environment such as Agent to Agent messaging, these are particularly likely - and particularly difficult to handle gracefully. The potential reasons for timeouts are numerous:</p> <ul> <li>loss of connectivity</li> <li>resource errors with one of the Agents between the Sender and Receiver</li> <li>not yet detected key rotations (cached DIDDocs and encryption keys)</li> <li>errors occurring in an Agent unaware of the Sender (so cannot notify the sender of the issue)</li> <li>Recipient offline for an extended period</li> <li>disinterest on the part of the Recipient (received, but no response sent back)</li> </ul>"},{"location":"features/0035-report-problem/#recommended-handling_4","title":"Recommended Handling","text":"<p>Appropriate timeout handling is extremely contextual, with two key parameters driving the handling - the length of the waiting period before triggering the timeout and the response to a triggered timeout.</p> <p>The time to wait for a response should be dynamic by at least type of message, and ideally learned through experience. Messages requiring human interaction should have an inherently longer timeout period than a message expected to be handled automatically. Beyond that, it would be good for Agents to track response times by message type (and perhaps other parameters) and adjust timeouts to match observed patterns.</p> <p>When a timeout is received there are three possible responses, handled automatically or based on feedback from the user:</p> <ul> <li>Wait longer</li> <li>Retry</li> <li>Give up</li> </ul> <p>An automated \"wait longer\" response might be used when first interacting with a particular message type or identity, as the response cadence is learned.</p> <p>If the decision is to retry, it would be good to have support in areas covered by other RFCs. First, it would be helpful (and perhaps necessary) for the threading decorator to support the concept of retries, so that a Recipient would know when a message is a retry of an already sent message.  Next, on \"forward\" message types, Agents might want to know that a message was a retry such that they can consider refreshing DIDDoc/encryption key cache before sending the message along. It could also be helpful for a retry to interact with the Tracing facility so that more information could be gathered about why messages are not getting to their destination.</p> <p>Excessive retrying can exacerbate an existing system issue. If the reason for the timeout is because there is a \"too many messages to be processed\" situation, then sending retries simply makes the problem worse. As such, a reasonable backoff strategy should be used (e.g. exponentially increasing times between retries). As well, a strategy used at Uber is to flag and handle retries differently from regular messages. The analogy with Uber is not pure - that is a single-vendor system - but the notion of flagging retries such that retry messages can be handled differently is a good approach.</p>"},{"location":"features/0035-report-problem/#caveat-problem-report-loops","title":"Caveat: Problem Report Loops","text":"<p>Implementers should consider and mitigate the risk of an endless loop of error messages. For example:</p> <ul> <li>Alice sends a message to Bob that Bob doesn't recognize. Bob sends a <code>Problem Report</code> message to Alice.</li> <li>Alice doesn't understand the message from Bob and sends a <code>Problem Report</code> to Bob.</li> <li>Bob doesn't understand the message from Alice and sends a <code>Problem Report</code> to Alice. And so on...</li> </ul>"},{"location":"features/0035-report-problem/#recommended-handling_5","title":"Recommended Handling","text":"<p>How agents mitigate the risk of this problem is implementation specific, balancing loop-tracking overhead versus the likelihood of occurrence. For example, an agent implementation might have a counter on a connection object that is incremented when certain types of <code>Problem Report</code> messages are sent on that connection, and reset when any other message is sent. The agent could stop sending those types of <code>Problem Report</code> messages after the counter reaches a given value.</p>"},{"location":"features/0035-report-problem/#reference","title":"Reference","text":"<p>TBD</p>"},{"location":"features/0035-report-problem/#drawbacks","title":"Drawbacks","text":"<p>In many cases, a specific <code>problem-report</code> message is necessary, so formalizing the format of the message is also preferred over leaving it to individual implementations. There is no drawback to specifying that format now.</p> <p>As experience is gained with handling distributed errors, the recommendations provided in this RFC will have to evolve.</p>"},{"location":"features/0035-report-problem/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>The error type specification mechanism builds on the same approach used by the message type specifications. It's possible that additional capabilities could be gained by making runtime use of the error type specification - e.g. for the broader internationalization of the error messages.</p> <p>The main alternative to a formally defined error type format is leaving it to individual implementations to handle error notifications, which will not lead to an effective solution.</p>"},{"location":"features/0035-report-problem/#prior-art","title":"Prior art","text":"<p>A brief search was done for error handling in messaging systems with few useful results found. Perhaps the best was the Uber article referenced in the \"Timeout\" section above.</p>"},{"location":"features/0035-report-problem/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Can the Tracing facility provide a trusted way to better handle distributed errors in a production environment?</li> <li>Denial of service via problems that spam the wrong person with   a problem report.</li> </ul>"},{"location":"features/0035-report-problem/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes RFC 0036: Issue Credential Protocol The <code>problem-report</code> message is adopted by this protocol. MISSING test results RFC 0037: Present Proof Protocol The <code>problem-report</code> message is adopted by this protocol. MISSING test results Trinsic.id Commercial mobile and web app built using Aries Framework - .NET MISSING test results"},{"location":"features/0036-issue-credential/","title":"Aries RFC 0036: Issue Credential Protocol 1.0","text":"<ul> <li>Authors: Nikita Khateev</li> <li>Status: ADOPTED (But should move to deprecated)</li> <li>Since: 2019-05-28</li> <li>Status Note:  See RFC 0037 for the presentation part of using credentials.</li> <li>Supersedes: Indy HIPE PR #89; also Credential Exchange 0.1 -- IIW 2019</li> <li>Start Date: 2019-01-30</li> <li>Tags: feature, decorator, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0036-issue-credential/#version-change-log","title":"Version Change Log","text":""},{"location":"features/0036-issue-credential/#11propose-credential","title":"1.1/propose-credential","text":"<p>In version 1.1 of the propose-credential message, the following optional fields were added: schema_name, schema_version, and issuer_did.</p> <p>The previous version is 1.0/propose-credential.</p>"},{"location":"features/0036-issue-credential/#summary","title":"Summary","text":"<p>Formalizes messages used to issue a credential--whether the credential is JWT-oriented, JSON-LD-oriented, or ZKP-oriented. The general flow is similar, and this protocol intends to handle all of them. If you are using a credential type that doesn't fit this protocol, please raise a Github issue.</p>"},{"location":"features/0036-issue-credential/#motivation","title":"Motivation","text":"<p>We need a standard protocol for issuing credentials. This is the basis of interoperability between Issuers and Holders.</p>"},{"location":"features/0036-issue-credential/#tutorial","title":"Tutorial","text":""},{"location":"features/0036-issue-credential/#roles","title":"Roles","text":"<p>There are two roles in this protocol: Issuer and Holder. Technically, the latter role is only potential until the protocol completes; that is, the second party becomes a Holder of a credential by completing the protocol. However, we will use the term Holder throughout, to keep things simple.</p> <p>Note: When a holder of credentials turns around and uses those credentials to prove something, they become a Prover. In the sister RFC to this one, 0037: Present Proof, the Holder is therefore renamed to Prover. Sometimes in casual conversation, the Holder role here might be called \"Prover\" as well, but more formally, \"Holder\" is the right term at this phase of the credential lifecycle.</p>"},{"location":"features/0036-issue-credential/#states","title":"States","text":"<p>The choreography diagrams shown below detail how state evolves in this protocol, in a \"happy path.\" The states include:</p>"},{"location":"features/0036-issue-credential/#states-for-issuer","title":"states for Issuer","text":"<ul> <li>proposal-received</li> <li>offer-sent</li> <li>request-received</li> <li>credential-issued</li> <li>done</li> </ul>"},{"location":"features/0036-issue-credential/#states-for-holder","title":"states for Holder","text":"<ul> <li>proposal-sent</li> <li>offer-received</li> <li>request-sent</li> <li>credential-received</li> <li>done</li> </ul> <p>Errors might occur in various places. For example, an Issuer might offer a credential for a price that the Holder is unwilling to pay. All errors are modeled with a <code>problem-report</code> message. Easy-to-anticipate errors reset the flow as shown in the diagrams, and use the code <code>issuance-abandoned</code>; more exotic errors (e.g., server crashed at Issuer headquarters in the middle of a workflow) may have different codes but still cause the flow to be abandoned in the same way. That is, in this version of the protocol, all errors cause the state of both parties (the sender and the receiver of the <code>problem-report</code>) to revert to <code>null</code> (meaning it is no longer engaged in the protocol at all). Future versions of the protocol may allow more granular choices (e.g., requesting and receiving a (re-)send of the <code>issue-credential</code> message if the Holder times out while waiting in the <code>request-sent</code> state).</p>"},{"location":"features/0036-issue-credential/#messages","title":"Messages","text":"<p>The Issue Credential protocol consists of these messages:</p> <ul> <li><code>propose-credential</code> - potential Holder to Issuer (optional). Tells what the Holder hopes to receive.</li> <li><code>offer-credential</code> - Issuer to potential Holder (optional for some credential implementations; required for Hyperledger Indy). Tells what the Issuer intends to issue, and possibly, the price the Issuer expects to be paid.</li> <li><code>request-credential</code> - potential Holder to Issuer. If neither of the previous message types is used, this is the message that begins the protocol.</li> <li><code>issue-credential</code> - Issuer to new Holder. Attachment payload contains the actual credential.</li> </ul> <p>In addition, the <code>ack</code> and <code>problem-report</code> messages are adopted into the protocol for confirmation and error handling.</p> <p>Note: This protocol is about the messages that must be exchanged to issue verifiable credentials, NOT about the specifics of particular verifiable credential schemes. DIDComm attachments are deliberately used in messages to isolate the protocol flow/semantics from the credential artifacts themselves as separate constructs. Attachments allow credential formats and this protocol to evolve through versioning milestones independently instead of in lockstep. Links are provided in the message descriptions below, to describe how the protocol adapts to specific verifiable credential implementations.</p>"},{"location":"features/0036-issue-credential/#choreography-diagram","title":"Choreography Diagram","text":"Note: This diagram was made in draw.io. To make changes:  - upload the drawing HTML from this folder to the [draw.io](https://draw.io) site (Import From...GitHub), - make changes, - export the picture and HTML to your local copy of this repo, and - submit a pull request.  <p>The protocol has 3 alternative beginnings:</p> <ol> <li>The Issuer can begin with an offer.</li> <li>The Holder can begin with a proposal.</li> <li>the Holder can begin with a request.</li> </ol> <p>The offer and proposal messages are part of an optional negotiation phase and may trigger back-and-forth counters. A request is not subject to negotiation; it can only be accepted or rejected.</p> <p></p>"},{"location":"features/0036-issue-credential/#propose-credential","title":"Propose Credential","text":"<p>An optional message sent by the potential Holder to the Issuer to initiate the protocol or in response to a <code>offer-credential</code> message when the Holder wants some adjustments made to the credential data offered by Issuer.</p> <p>Note: In Hyperledger Indy, where the <code>request-credential</code> message can only be sent in response to an <code>offer-credential</code> message, the <code>propose-credential</code> message is the only way for a potential Holder to initiate the workflow.</p> <p>Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/1.1/propose-credential\",\n    \"@id\": \"&lt;uuid-of-propose-message&gt;\",\n    \"comment\": \"some comment\",\n    \"credential_proposal\": &lt;json-ld object&gt;,\n    \"schema_issuer_did\": \"DID of the proposed schema issuer\",\n    \"schema_id\": \"Schema ID string\",\n    \"schema_name\": \"Schema name string\",\n    \"schema_version\": \"Schema version string\",\n    \"cred_def_id\": \"Credential Definition ID string\"\n    \"issuer_did\": \"DID of the proposed issuer\"\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Proposal, so the proposal can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>credential_proposal</code> -- an optional JSON-LD object that represents the credential data that Prover wants to receive. It matches the schema of Credential Preview.</li> <li><code>schema_issuer_did</code> -- optional filter to request credential based on a particular Schema issuer DID.</li> <li><code>schema_id</code> -- optional filter to request credential based on a particular Schema. This might be helpful when requesting a version 1 passport instead of a version 2 passport, for example.</li> <li><code>schema_name</code> -- optional filter to request credential based on a schema name. This is useful to allow a more user-friendly experience of requesting a credential by schema name.</li> <li><code>schema_version</code> -- optional filter to request credential based on a schema version. This is useful to allow a more user-friendly experience of requesting a credential by schema name and version.</li> <li><code>cred_def_id</code> -- optional filter to request credential based on a particular Credential Definition. This might be helpful when requesting a commercial driver's license instead of an ordinary driver's license, for example.</li> <li><code>issuer_did</code> -- optional filter to request a credential issued by the owner of a particular DID.</li> </ul>"},{"location":"features/0036-issue-credential/#offer-credential","title":"Offer Credential","text":"<p>A message sent by the Issuer to the potential Holder, describing the credential they intend to offer and possibly the price they expect to be paid. In Hyperledger Indy, this message is required, because it forces the Issuer to make a cryptographic commitment to the set of fields in the final credential and thus prevents Issuers from inserting spurious data. In credential implementations where this message is optional, an Issuer can use the message to negotiate the issuing following receipt of a <code>request-credential</code> message.</p> <p>Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/1.0/offer-credential\",\n    \"@id\": \"&lt;uuid-of-offer-message&gt;\",\n    \"comment\": \"some comment\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"offers~attach\": [\n        {\n            \"@id\": \"libindy-cred-offer-0\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Offer, so the offer can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>credential_preview</code> -- a JSON-LD object that represents the credential data that Issuer is willing to issue. It matches the schema of Credential Preview;</li> <li><code>offers~attach</code> -- an array of attachments that further define the credential being offered. This might be used to clarify which formats or format versions will be issued.</li> <li>For Indy, the attachment includes a nonce and key correctness proof to facilitate integrity checks. It is a base64url-encoded version of the data returned from <code>indy_issuer_create_credential_offer()</code>.</li> </ul> <p>The Issuer may add a <code>~payment-request</code> decorator to this message to convey the need for payment before issuance. See the payment section below for more details.</p> <p>It is possible for an Issuer to add a <code>~timing.expires_time</code> decorator to this message to convey the idea that the offer will expire at a particular point in the future. Such behavior is not a special part of this protocol, and support for it is not a requirement of conforming implementations; the <code>~timing</code> decorator is simply a general possibility for any DIDComm message. We mention it here just to note that the protocol can be enriched in composable ways.</p>"},{"location":"features/0036-issue-credential/#request-credential","title":"Request Credential","text":"<p>This is a message sent by the potential Holder to the Issuer, to request the issuance of a credential. Where circumstances do not require a preceding Offer Credential message (e.g., there is no cost to issuance that the Issuer needs to explain in advance, and there is no need for cryptographic negotiation), this message initiates the protocol. In Hyperledger Indy, this message can only be sent in response to an Offer Credential message.</p> <p>Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/1.0/request-credential\",\n    \"@id\": \"&lt;uuid-of-request-message&gt;\",\n    \"comment\": \"some comment\",\n    \"requests~attach\": [\n        {\n            \"@id\": \"attachment id\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        },\n    ]\n}\n</code></pre> <p>Description of Fields:</p> <ul> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Request, so it can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>requests~attach</code> -- an array of attachments defining the requested formats for the credential.</li> <li>For Indy, the attachment is a base64url-encoded version of the data returned from <code>indy_prover_create_credential_req()</code>.</li> </ul> <p>This message may have a <code>~payment-receipt</code> decorator to prove to the Issuer that the potential Holder has satisfied a payment requirement. See the payment section below.</p>"},{"location":"features/0036-issue-credential/#issue-credential","title":"Issue Credential","text":"<p>This message contains as attached payload the credentials being issued and is sent in response to a valid Request Credential message.</p> <p>Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/1.0/issue-credential\",\n    \"@id\": \"&lt;uuid-of-issue-message&gt;\",\n    \"comment\": \"some comment\",\n    \"credentials~attach\": [\n        {\n            \"@id\": \"libindy-cred-0\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>comment</code> -- an optional field that provides human readable information about the issued credential, so it can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>credentials~attach</code> -- an array of attachments containing the issued credentials.</li> <li>For Indy, the attachment contains data from libindy about credential to be issued, base64url-encoded, as returned from <code>libindy</code>. For more information see the Libindy API.</li> </ul> <p>If the issuer wants an acknowledgement that the issued credential was accepted, this message must be decorated with <code>~please-ack</code>, and it is then best practice for the new Holder to respond with an explicit <code>ack</code> message as described in 0317: Please ACK Decorator.</p>"},{"location":"features/0036-issue-credential/#encoding-claims-for-indy-based-verifiable-credentials","title":"Encoding Claims for Indy-based Verifiable Credentials","text":"<p>Claims in Hyperledger Indy-based verifiable credentials are put into the credential in two forms, <code>raw</code> and <code>encoded</code>. <code>raw</code> is the actual data value, and <code>encoded</code> is the (possibly derived) integer value that is used in presentations. At this time, Indy does not take an opinion on the method used for encoding the raw value. This will change with the Rich Schema work that is underway in the Indy/Aries community, where the encoding method will be part of the credential metadata available from the public ledger.</p> <p>Until the Rich Schema mechanism is deployed, Aries issuers and verifiers must agree on the encoding method so that the verifier can check that the <code>raw</code> value returned in a presentation corresponds to the proven <code>encoded</code> value. The following is the encoding algorithm that MUST be used by Issuers when creating credentials and SHOULD be verified by Verifiers receiving presentations:</p> <ul> <li>keep any 32-bit integer as is</li> <li>for data of any other type:</li> <li>convert to string (use string \"None\" for null)</li> <li>encode via utf-8 to bytes</li> <li>apply SHA-256 to digest the bytes</li> <li>convert the resulting digest bytes, big-endian, to integer</li> <li>stringify the integer as a decimal.</li> </ul> <p>An example implementation in Python can be found here.</p> <p>A gist of test value pairs can be found here.</p>"},{"location":"features/0036-issue-credential/#preview-credential","title":"Preview Credential","text":"<p>This is not a message but an inner object for other messages in this protocol. It is used construct a preview of the data for the credential that is to be issued. Its schema follows:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/1.0/credential-preview\",\n    \"attributes\": [\n        {\n            \"name\": \"&lt;attribute name&gt;\",\n            \"mime-type\": \"&lt;type&gt;\",\n            \"value\": \"&lt;value&gt;\"\n        },\n        // more attributes\n    ]\n}\n</code></pre> <p>The main element is <code>attributes</code>. It is an array of (object) attribute specifications; the subsections below outline their semantics.</p>"},{"location":"features/0036-issue-credential/#attribute-name","title":"Attribute Name","text":"<p>The mandatory <code>\"name\"</code> key maps to the attribute name as a string.</p>"},{"location":"features/0036-issue-credential/#mime-type-and-value","title":"MIME Type and Value","text":"<p>The optional <code>mime-type</code> advises the issuer how to render a binary attribute, to judge its content for applicability before issuing a credential containing it. Its value parses case-insensitively in keeping with MIME type semantics of RFC 2045. If <code>mime-type</code> is missing, its value is null.</p> <p>The mandatory <code>value</code> holds the attribute value:</p> <ul> <li>if <code>mime-type</code> is missing (null), then <code>value</code> is a string. In other words, implementations interpret it the same as any other key+value pair in JSON</li> <li>if <code>mime-type</code> is not null, then <code>value</code> is always a base64url-encoded string that represents a binary BLOB, and <code>mime-type</code> tells how to interpret the BLOB after base64url-decoding.</li> </ul>"},{"location":"features/0036-issue-credential/#threading","title":"Threading","text":"<p>Threading can be used to initiate a sub-protocol during an issue credential protocol instance. For example, during credential issuance, the Issuer may initiate a child message thread to execute the <code>Present Proof</code> sub-protocol to have the potential Holder (now acting as a Prover) prove attributes about themselves before issuing the credential. Depending on circumstances, this might be a best practice for preventing credential fraud at issuance time.</p> <p>If threading were added to all of the above messages, a <code>~thread</code> decorator would be present, and later messages in the flow would reference the <code>@id</code> of earlier messages to stitch the flow into a single coherent sequence. Details about threading can be found in the 0008: Message ID and Threading RFC.</p>"},{"location":"features/0036-issue-credential/#payments-during-credential-exchange","title":"Payments during credential exchange","text":"<p>Credentialing ecosystems may wish to associate credential issuance with payments by fiat currency or tokens. This is common with non-digital credentials today; we pay a fee when we apply for a passport or purchase a plane ticket. Instead or in addition, some circumstances may fit a mode where payment is made each time a credential is used, as when a Verifier pays a Prover for verifiable medical data to be used in research, or when a Prover pays a Verifier as part of a workflow that applies for admittance to a university. For maximum flexibility, we mention payment possibilities here as well as in the sister 0037: Present Proof RFC.</p>"},{"location":"features/0036-issue-credential/#payment-decorators","title":"Payment decorators","text":"<p>Wherever they happen and whoever they involve, payments are accomplished with optional payment decorators. See 0075: Payment Decorators.</p>"},{"location":"features/0036-issue-credential/#payment-flow","title":"Payment flow","text":"<p>A <code>~payment-request</code> may decorate a Credential Offer from Issuer to Holder. When they do, a corresponding <code>~payment-receipt</code> should be provided on the Credential Request returned to the Issuer.</p> <p>During credential presentation, the Verifier may pay the Holder as compensation for Holder for disclosing data. This would require a <code>~payment-request</code> in a Presentation Proposal message, and a corresponding <code>~payment-receipt</code> in the subsequent Presentation Request. If such a workflow begins with the Presentation Request, the Prover may sending back a Presentation (counter-)Proposal with appropriate decorator inside it.</p>"},{"location":"features/0036-issue-credential/#limitations","title":"Limitations","text":"<p>Smart contracts may be missed in ecosystem, so operation \"issue credential after payment received\" is not atomic. It\u2019s possible case that malicious issuer will charge first and then will not issue credential in fact. But this situation should be easily detected and appropriate penalty should be applied in such type of networks.</p>"},{"location":"features/0036-issue-credential/#negotiation-and-preview","title":"Negotiation and Preview","text":"<p>Negotiation prior to issuing the credential can be done using the <code>offer-credential</code> and <code>propose-credential</code> messages. A common negotiation use case would be about the data to go into the credential. For that, the <code>credential_preview</code> element is used.</p>"},{"location":"features/0036-issue-credential/#reference","title":"Reference","text":"<ul> <li>VCX -- this implementation might not be perfect and needs to be improved, you can gather some info on parameters' purpose from it</li> <li>A pre-RFC (labelled version 0.1) implementation of the protocol was implemented by a number of groups in the Hyperledger Indy community leading up to IIW28 in April 2019. The protocol defined and implemented can be reviewed here. It was the basis of the IIWBook demo from BC Gov and collaborators.</li> </ul>"},{"location":"features/0036-issue-credential/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"features/0036-issue-credential/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"features/0036-issue-credential/#prior-art","title":"Prior art","text":"<p>Similar (but simplified) credential exchanged was already implemented in von-anchor.</p>"},{"location":"features/0036-issue-credential/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>We might need to propose a new MIME type for credential (the same way as .docx is not processed as generic xml). The issue in W3C/vc-data-model: https://github.com/w3c/vc-data-model/issues/421</li> <li>It is a common practice when changing some attributes in credential to revoke the old credential and issue a new one. It might be useful to have an element in the <code>offer-credential</code> message to indicate a connection between a now revoked credential and the new credential being offered.</li> <li>We might need some explicit documentation for nested <code>@type</code> fields.</li> <li>There should be a way to ask for some payment with <code>offer-credential</code> and to send a payment (or payment receipt) in the request-credential.</li> </ul>"},{"location":"features/0036-issue-credential/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Streetcred.id Commercial mobile and web app built using Aries Framework - .NET MISSING test results"},{"location":"features/0037-present-proof/","title":"Aries RFC 0037: Present Proof Protocol 1.0","text":"<ul> <li>Authors: Nikita Khateev</li> <li>Status: ADOPTED (But should move to deprecated)</li> <li>Since: 2019-05-28</li> <li>Status Note:  This v1.x version of the protocol will be replaced by version v2 defined in RFC 454.</li> <li>Supersedes: Indy HIPE PR #89; also Credential Exchange 0.1 -- IIW 2019</li> <li>Start Date: 2019-01-30</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0037-present-proof/#summary","title":"Summary","text":"<p>Formalization and generalization of existing message formats used for presenting a proof according to existing RFCs about message formats.</p>"},{"location":"features/0037-present-proof/#motivation","title":"Motivation","text":"<p>We need to define a standard protocol for presenting a proof.</p>"},{"location":"features/0037-present-proof/#tutorial","title":"Tutorial","text":"<p>The present proof protocol consists of these messages:</p> <ul> <li>Propose Proof - Prover to Verifier (optional)</li> <li>Request Proof - Verifier to Prover</li> <li>Present Proof - Prover to Verifier</li> </ul> <p>In addition, the <code>ack</code> and <code>problem-report</code> messages are adopted into the protocol for confirmation and error handling.</p> <p>This protocol is about the messages to support the presentation of verifiable claims, not about the specifics of particular verifiable presentation mechanisms. This is challenging since at the time of writing this version of the protocol, there is only one supported verifiable presentation mechanism(Hyperledger Indy). DIDComm attachments are deliberately used in messages to try to make this protocol agnostic to the specific verifiable presentation mechanism payloads. Links are provided in the message data element descriptions to details of specific verifiable presentation implementation data structures.</p> <p>Diagrams in this protocol were made in draw.io. To make changes:</p> <ul> <li>upload the drawing HTML from this folder to the draw.io site (Import From...GitHub),</li> <li>make changes,</li> <li>export the picture and HTML to your local copy of this repo, and</li> <li>submit a pull request.</li> </ul>"},{"location":"features/0037-present-proof/#states","title":"States","text":""},{"location":"features/0037-present-proof/#states-for-verifier","title":"states for Verifier","text":"<ul> <li>request-sent</li> <li>proposal-received</li> <li>request-received</li> <li>presentation-received</li> <li>done</li> </ul>"},{"location":"features/0037-present-proof/#states-for-prover","title":"states for Prover","text":"<ul> <li>request-received</li> <li>proposal-sent</li> <li>presentation-sent</li> <li>reject-sent</li> <li>done</li> </ul> <p>For the most part, these states map onto the transitions shown in the choreography diagram in obvious ways. However, a few subtleties are worth highlighting:</p> <ul> <li>The final transitions for the Verifier (Send Presentation Reject, Send Presentation Ack, and Receive Presentation Reject) all result in a final <code>done</code> state, but this <code>done</code> may or may not be the Verifier's intended outcome. We may want to tweak this in a future version of the protocol.</li> <li>A similar situation exists with the final transitions for the Prover and its final transitions (Send Presentation Reject, Receive Presentation Ack, and Receive Presentation Reject).</li> <li>When a Prover makes a (counter-)proposal, it transitions to the <code>proposal-sent</code> state. This state is only present by implication in the choreography diagram; it essentially equates to the null or begin state in that the Prover does nothing until a presentation request arrives, triggering the leftmost transition for the Prover.</li> </ul> <p>Errors might occur in various places. For example, a Verifier might time out waiting for the Prover to supply a presentation. Errors trigger a <code>problem-report</code>. In this version of the protocol, all errors cause the state of both parties (the sender and the receiver of the <code>problem-report</code>) to revert to <code>null</code> (meaning it is no longer engaged in the protocol at all). Future versions of the protocol may allow more granular choices.</p>"},{"location":"features/0037-present-proof/#choreography-diagram","title":"Choreography Diagram:","text":""},{"location":"features/0037-present-proof/#propose-presentation","title":"Propose Presentation","text":"<p>An optional message sent by the Prover to the verifier to initiate a proof presentation process, or in response to a <code>request-presentation</code> message when the Prover wants to propose using a different presentation format. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/propose-presentation\",\n    \"@id\": \"&lt;uuid-propose-presentation&gt;\",\n    \"comment\": \"some comment\",\n    \"presentation_proposal\": &lt;json-ld object&gt;\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>comment</code> -- a field that provides some human readable information about the proposed presentation.</li> <li><code>presentation_proposal</code> -- a JSON-LD object that represents the presentation example that Prover wants to provide. It should follow the schema of Presentation Preview;</li> </ul>"},{"location":"features/0037-present-proof/#request-presentation","title":"Request Presentation","text":"<p>From a verifier to a prover, the <code>request-presentation</code> message describes values that need to be revealed and predicates that need to be fulfilled. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/request-presentation\",\n    \"@id\": \"&lt;uuid-request&gt;\",\n    \"comment\": \"some comment\",\n    \"request_presentations~attach\": [\n        {\n            \"@id\": \"libindy-request-presentation-0\",\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>comment</code> -- a field that provides some human readable information about this request for a presentation.</li> <li><code>request_presentations~attach</code> -- an array of attachments defining the acceptable formats for the presentation.</li> <li>For Indy, the attachment contains data from libindy about the presentation request, base64url-encoded, as returned from <code>libindy</code>. For more information see the Libindy API.</li> </ul>"},{"location":"features/0037-present-proof/#presentation","title":"Presentation","text":"<p>This message is a response to a Presentation Request message and contains signed presentations. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/presentation\",\n    \"@id\": \"&lt;uuid-presentation&gt;\",\n    \"comment\": \"some comment\",\n    \"presentations~attach\": [\n        {\n            \"@id\": \"libindy-presentation-0\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>comment</code> -- a field that provides some human readable information about this presentation.</li> <li><code>presentations~attach</code> -- an array of attachments containing the presentation in the requested format(s).</li> <li>For Indy, the attachment contains data from libindy that is the presentation, base64url-encoded, as returned from <code>libindy</code>. For more information see the Libindy API.</li> </ul>"},{"location":"features/0037-present-proof/#verifying-claims-of-indy-based-verifiable-credentials","title":"Verifying Claims of Indy-based Verifiable Credentials","text":"<p>Claims in Hyperledger Indy-based verifiable credentials are put into the credential in two forms, <code>raw</code> and <code>encoded</code>. <code>raw</code> is the actual data value, and <code>encoded</code> is the (possibly derived) integer value that is used in presentations. At this time, Indy does not take an opinion on the method used for encoding the raw value. This will change with the Rich Schema work that is underway in the Indy/Aries community, where the encoding method will be part of the credential metadata available from the public ledger.</p> <p>Until the Rich Schema mechanism is deployed, the Aries issuers and verifiers must agree on an encoding method so that the verifier can check that the <code>raw</code> value returned in a presentation corresponds to the proven <code>encoded</code> value. The following is the encoding algorithm that MUST be used by Issuers when creating credentials and SHOULD be verified by Verifiers receiving presentations:</p> <ul> <li>keep any 32-bit integer as is</li> <li>for data of any other type:</li> <li>convert to string (use string \"None\" for null)</li> <li>encode via utf-8 to bytes</li> <li>apply SHA-256 to digest the bytes</li> <li>convert the resulting digest bytes, big-endian, to integer</li> <li>stringify the integer as a decimal.</li> </ul> <p>An example implementation in Python can be found here.</p> <p>A gist of test value pairs can be found here.</p>"},{"location":"features/0037-present-proof/#presentation-preview","title":"Presentation Preview","text":"<p>This is not a message but an inner object for other messages in this protocol. It is used to construct a preview of the data for the presentation. Its schema follows:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/presentation-preview\",\n    \"attributes\": [\n        {\n            \"name\": \"&lt;attribute_name&gt;\",\n            \"cred_def_id\": \"&lt;cred_def_id&gt;\",\n            \"mime-type\": \"&lt;type&gt;\",\n            \"value\": \"&lt;value&gt;\",\n            \"referent\": \"&lt;referent&gt;\"\n        },\n        // more attributes\n    ],\n    \"predicates\": [\n        {\n            \"name\": \"&lt;attribute_name&gt;\",\n            \"cred_def_id\": \"&lt;cred_def_id&gt;\",\n            \"predicate\": \"&lt;predicate&gt;\",\n            \"threshold\": &lt;threshold&gt;\n        },\n        // more predicates\n    ]\n}\n</code></pre> <p>The preview identifies attributes and predicates to present.</p>"},{"location":"features/0037-present-proof/#attributes","title":"Attributes","text":"<p>The mandatory <code>\"attributes\"</code> key maps to a list (possibly empty to propose a presentation with no attributes) of specifications, one per attribute. Each such specification proposes its attribute's characteristics for creation within a presentation.</p>"},{"location":"features/0037-present-proof/#attribute-name","title":"Attribute Name","text":"<p>The mandatory <code>\"name\"</code> key maps to the name of the attribute.</p>"},{"location":"features/0037-present-proof/#credential-definition-identifier","title":"Credential Definition Identifier","text":"<p>The optional <code>\"cred_def_id\"</code> key maps to the credential definition identifier of the credential with the current attribute. Note that since it is the holder who creates the preview and the holder possesses the corresponding credential, the holder must know its credential definition identifier.</p> <p>If the key is absent, the preview specifies attribute's posture in the presentation as a self-attested attribute. A self-attested attribute does not come from a credential, and hence any attribute specification without the <code>\"cred_def_id\"</code> key cannot use a <code>\"referent\"</code> key as per Referent below.</p>"},{"location":"features/0037-present-proof/#mime-type-and-value","title":"MIME Type and Value","text":"<p>The optional <code>mime-type</code> advises the verifier how to render a binary attribute, to judge its content for applicability before accepting a presentation containing it. Its value parses case-insensitively in keeping with MIME type semantics of RFC 2045. If <code>mime-type</code> is missing, its value is null.</p> <p>The optional <code>value</code>, when present, holds the value of the attribute to reveal in presentation:</p> <ul> <li>if <code>mime-type</code> is missing (null), then <code>value</code> is a string. In other words, implementations interpret it the same as any other key+value pair in JSON</li> <li>if <code>mime-type</code> is not null, then <code>value</code> is always a base64url-encoded string that represents a binary BLOB, and <code>mime-type</code> tells how to interpret the BLOB after base64-decoding.</li> </ul> <p>An attribute specification must specify a <code>value</code>, a <code>cred_def_id</code>, or both:</p> <ul> <li>if <code>value</code> is present and <code>cred_def_id</code> is absent, the preview proposes a self-attested attribute;</li> <li>if <code>value</code> and <code>cred_def_id</code> are both present, the preview proposes a verifiable claim to reveal in the presentation;</li> <li>if <code>value</code> is absent and <code>cred_def_id</code> is present, the preview proposes a verifiable claim not to reveal in the presentation.</li> </ul>"},{"location":"features/0037-present-proof/#referent","title":"Referent","text":"<p>The optional <code>referent</code> can be useful in specifying multiple-credential presentations. Its value indicates which credential will supply the attribute in the presentation. Sharing a <code>referent</code> value between multiple attribute specifications indicates that the holder's same credential supplies the attribute.</p> <p>Any attribute specification using a <code>referent</code> must also have a <code>cred_def_id</code>; any attribute specifications sharing a common <code>referent</code> value must all have the same <code>cred_def_id</code> value (see Credential Definition Identifier above).</p> <p>For example, a holder with multiple account credentials could use a presentation preview such as</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/presentation-preview\",\n    \"attributes\": [\n        {\n            \"name\": \"account\",\n            \"cred_def_id\": \"BzCbsNYhMrjHiqZDTUASHg:3:CL:1234:tag\",\n            \"value\": \"12345678\",\n            \"referent\": \"0\"\n        },\n        {\n            \"name\": \"streetAddress\",\n            \"cred_def_id\": \"BzCbsNYhMrjHiqZDTUASHg:3:CL:1234:tag\",\n            \"value\": \"123 Main Street\",\n            \"referent\": \"0\"\n        },\n    ],\n    \"predicates\": [\n    ]\n}\n</code></pre> <p>to prompt a verifier to request proof of account number and street address from the same account, rather than potentially an account number and street address from distinct accounts.</p>"},{"location":"features/0037-present-proof/#predicates","title":"Predicates","text":"<p>The mandatory <code>\"predicates\"</code> key maps to a list (possibly empty to propose a presentation with no predicates) of predicate specifications, one per predicate. Each such specification proposes its predicate's characteristics for creation within a presentation.</p>"},{"location":"features/0037-present-proof/#attribute-name_1","title":"Attribute Name","text":"<p>The mandatory <code>\"name\"</code> key maps to the name of the attribute.</p>"},{"location":"features/0037-present-proof/#credential-definition-identifier_1","title":"Credential Definition Identifier","text":"<p>The mandatory <code>\"cred_def_id\"</code> key maps to the credential definition identifier of the credential with the current attribute. Note that since it is the holder who creates the preview and the holder possesses the corresponding credential, the holder must know its credential definition identifier.</p>"},{"location":"features/0037-present-proof/#predicate","title":"Predicate","text":"<p>The mandatory <code>\"predicate\"</code> key maps to the predicate operator: <code>\"&lt;\"</code>, <code>\"&lt;=\"</code>, <code>\"&gt;=\"</code>, <code>\"&gt;\"</code>.</p>"},{"location":"features/0037-present-proof/#threshold-value","title":"Threshold Value","text":"<p>The mandatory <code>\"threshold\"</code> key maps to the threshold value for the predicate.</p>"},{"location":"features/0037-present-proof/#negotiation-and-preview","title":"Negotiation and Preview","text":"<p>Negotiation prior to the presentation can be done using the <code>propose-presentation</code> and <code>request-presentation</code> messages. A common negotiation use case would be about the data to go into the presentation. For that, the <code>presentation-preview</code> element is used.</p>"},{"location":"features/0037-present-proof/#reference","title":"Reference","text":"<ul> <li>VCX -- this implementation might not be perfect and needs to be improved, you can gather some info on parameters purpose from it</li> <li>A pre-RFC (labeled version 0.1) implementation of the protocol was implemented by a number of groups in the Hyperledger Indy community leading up to IIW28 in April 2019. The protocol can be found here. It was the basis of the IIWBook demo from BC Gov and collaborators.</li> </ul>"},{"location":"features/0037-present-proof/#drawbacks","title":"Drawbacks","text":"<p>The presentation preview as proposed above does not allow nesting of predicate logic along the lines of \"A and either B or C if D, otherwise A and B\", nor cross-credential-definition predicates such as proposing a legal name from either a financial institution or selected government entity.</p> <p>The presentation preview may be indy-centric, as it assumes the inclusion of at most one credential per credential definition. In addition, it prescribes exactly four predicates and assumes mutual understanding of their semantics (e.g., could <code>\"&gt;=\"</code> imply a lexicographic order for non-integer values, and if so, where to specify character collation algorithm?).</p> <p>Finally, the inclusion of non-revocation timestamps may become desirable at the preview stage; the standard as proposed does not accommodate such.</p>"},{"location":"features/0037-present-proof/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"features/0037-present-proof/#prior-art","title":"Prior art","text":"<p>Similar (but simplified) credential exchange was already implemented in von-anchor.</p>"},{"location":"features/0037-present-proof/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>We might need some explicit documentation for nested <code>@type</code> fields.</li> <li>There might need to be a way to associate a payment with the present proof protocol.</li> </ul>"},{"location":"features/0037-present-proof/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Streetcred.id Commercial mobile and web app built using Aries Framework - .NET MISSING test results"},{"location":"features/0042-lox/","title":"Aries RFC 0042: LOX -- A more secure pluggable framework for protecting wallet keys","text":"<ul> <li>Authors: Michael Lodder</li> <li>Status: DEMONSTRATED</li> <li>Since: 2019-05-30</li> <li>Start Date: 2019-05-30</li> <li>Tags: feature</li> </ul>"},{"location":"features/0042-lox/#summary","title":"Summary","text":"<p>Wallets are protected by secrets that must live outside of the wallet. This document proposes the Lox framework for managing the wallet access key(s).</p>"},{"location":"features/0042-lox/#motivation","title":"Motivation","text":"<p>Wallets currently use a single key to access the wallet. The key is provided directly or derived from a password. However, this is prone to misuse as most developers have little experience in key management. Right now there are no recommendations for protecting a key provided by Aries forcing implementors to choose methods based on their company's or organization's policies or practices.</p> <p>Here Millenial Mike demonstrates this process.</p> <p></p> <p>Some implementors have no policy or practice in place at all to follow leaving them to make bad decisions about managing wallet key storage and protection. For example, when creating an API token for Amazon's AWS, Amazon generates a secret key on a user's behalf and is downloaded to a CSV file. Many programmers do not know how to best protect these downloaded credentials because they must be used in a program to make API calls. They don't which of the following is the best option. They typically:</p> <ul> <li>Put these credentials directly in the program like most do as constant variables but this is a terrible option because attackers can analyze the code and extract it.</li> <li>Use environment variables. If so, should it passed as at the command level or put in a global variable registry? Both are susceptible to sniffing memory, process information, or inspecting command history.</li> <li>Read a config file that contains the credentials but must rely on the security of the operating system to manage access control.</li> </ul> <p>The less commonly used or known solution involves keyrings, hardware security modules (HSM), trusted execution environments (TEE), and secure enclaves.</p>"},{"location":"features/0042-lox/#keyrings","title":"Keyrings","text":"<p>Keyrings come preinstalled with modern operating systems without requiring installing additional software, but other keyrings software packages can be installed that function in a similar way. Operating systems protect keyring contents in encrypted files with access controls based on the logged in user and process accessing them. The keyring can only be unlocked if the same user, process, and keyring credentials are used when the keyring is created. Keyring credentials can be any combination of passwords, pins, keys, cyber tokens, and biometrics. In principle, a system's keyring should be able to keep credentials away from <code>root</code> (as in, the attacker can use the credential as long as they have access, but they can't extract the credential for persistence and assuming no other attacks like Foreshadow). Mac OS X, Windows, Linux Gnome-Keyring and KWallet, Android, and iOS have built-in enclaves that are protected by the operating system.</p> <p>Some systems back keyrings with hardware to increase security. The following flow chart illustrates how a keyring functions.</p> <p></p>"},{"location":"features/0042-lox/#secure-enclaves","title":"Secure Enclaves","text":"<p>Secure enclaves are used to describe HSMs, TPMs, and TEEs. An explaination of how secure enclaves work is detailed here.</p>"},{"location":"features/0042-lox/#details","title":"Details","text":"<p>To avoid the overuse of repeating each of these to describe a highly secure environment, the term enclave will be used to indicate all of them synonymously. Enclaves are specially designed to safeguard secrets but can be complex to use with varying APIs and libraries and are accessed using multiple various combinations of credentials. However, these complexities cause many to avoid using them.</p> <p>Where to put the wallet access credentials that are directly used by applications or people is called the top-level credential problem. Lox aims to provide guidance and aid in adopting best practices and developing code to address the top level credential problem\u2013-the credential used to protect all others\u2013the keys to the kingdom\u2013or a secret that is used directly by Aries that if compromised would yield disastrous consequences and give access to the wallet.</p>"},{"location":"features/0042-lox/#tutorial","title":"Tutorial","text":"<p>Lox is a layer that is designed to be an API for storing secrets with pluggable backends that implement reasonable defaults but is flexible to support various others that may be used.</p> <p>The default enclave will be the operating system keychain. Lox will also allow for many different enclaves that are optimal for storing keys like YubiKey, Hashicorp Vault, Intel SGX, or other methods supported by Hyperledger Ursa. Other hardware security modules can be plugged into the system via USB or accessed via the cloud. Trusted Platform Modules (TPMs) now come standard with many laptops and higher end tablets. Communication to enclaves can be done using drivers or over Unix or TCP sockets, or the Windows Communication Framework.</p> <p>The goal of Lox is to remove the complexity of the various enclaves by choosing the best secure defaults and hiding details that are prone to be misused or misunderstood, making it easier to secure the wallet.</p> <p></p>"},{"location":"features/0042-lox/#reference","title":"Reference","text":"<p>Currently, there are two methods that are used to open a wallet: provide the wallet encryption key or use a password based key derivation function to derive the key. Neither of these methods is directly terrible but there are concerns. Where should the symmetric encryption key be stored? What settings should be chosen for Argon2id? Argon2id also does not scale horizontally because settings that are secure for a desktop can be very slow to execute on a mobile device in the order of tens of seconds to minutes. To make it usable, the settings must be dialed down for the mobile device, but this allows faster attacks from a hacker. Also, passwords are often weak in that they are short, easily guessed, and have low entropy.</p> <p>Lox, on the other hand, allows a wallet user to access a wallet providing the ID of the credential that will be used to open the wallet, then letting the secure enclave handle authenticating the owner and securing access control. The enclave will restrict access to the currently logged in user so even an administrator cannot read the enclave contents or even access the hardware or TEE.</p> <p>For example, a user creates a new wallet and instead of specifying a key, can specify an ID like <code>youthful_burnell</code>. The user is prompted to provide the enclave credentials like biometrics, pins, authenticator tokens, etc. If successful, Lox creates the wallet access key, stores it in the enclave, opens the wallet, and securely wipes the memory holding the key. The calling program can even store the ID value since this alone is not enough to access the enclave. The program must also be running as the same owner of the secret. This allows static agents to store the ID in a config file without having to store the key.</p> <p>Enclaves will usually remain unlocked until certain events occur like: when the system goes to sleep, after a set time interval passes, the user logs out. When the event occurs, the enclave reverts to its locked state which requires providing the credentials again. These settings can be modified if needed like only going to the locked state after system boot up.</p> <p>The benefits provided by Lox are these</p> <ol> <li>Avoid having Aries users reinvent the wheel when they manage secrets just like an enclave but in less secure ways.</li> <li>Securely create keys with sufficient entropy from trusted cryptographic sources.</li> <li>Safely use keys and wipe them from memory when finished to limit side-channel attacks.</li> <li>Support for pluggable enclave backends by providing a single API. This flexible architecture allows for the wallet key to be protected by a different enclave on each system its stored.</li> <li>Hide various enclave implementations and complexity to increase misuse-resistance.</li> </ol> <p>The first API iteration proposal includes the following functions</p> <pre><code>function lox_create_wallet(wallet_name: String, config: Map&lt;String, ...&gt;)\nfunction lox_open_wallet(wallet_name: String, config: Map&lt;String, ...&gt;)\n</code></pre> <p><code>wallet_name</code> can be any human readable string. This value will vary based on the enclaves requirements as some allow different characters than others. <code>config</code> can include anything needed to specify the enclave and access it like a service name, remote IP address, and other miscellaneous settings. If nothing is specified, the operating system's default enclave will be used.</p> <p>Lox will be used to access the wallet in addition to providing the raw key for those that do not want to use Lox and want to continue to manage their own keys in their own way. Essentially a raw key provided to the wallet is setting the enclave backend to be a null provider. The function for deriving the wallet key from a password should be deprecated for reasons described earlier and use Lox instead.</p>"},{"location":"features/0042-lox/#drawbacks","title":"Drawbacks","text":"<p>This adds another layer to wallet security. The APIs must be thought through to accommodate as many possible enclaves that could be used as possible. Hardware enclave vendor APIs are similar but are all different and have not unified behind a common standard yet. Trying to account for all of these will be difficult and may require changes to the API.</p>"},{"location":"features/0042-lox/#prior-art","title":"Prior art","text":"<p>A brief overview of enclaves and their services have been discussed in the Indy wallet HIPE.</p>"},{"location":"features/0042-lox/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What enclaves should be supported besides the default provided by the operating system?</li> </ul>"},{"location":"features/0042-lox/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Reference Code Example rust code that implements Lox using OS keychains"},{"location":"features/0042-lox/reference_code/","title":"Lox","text":"<p>A command line tool for accessing various keychains or secure enclaves.</p>"},{"location":"features/0042-lox/reference_code/#the-problem","title":"The problem","text":"<p>Applications use several credentials today to secure data locally and during transmitted. However, bad habits happen when safeguarding these credentials. For example, when creating an API token for Amazon's AWS, Amazon generates a secret key on a user's behalf and is downloaded to a CSV file. Programmers do not know how to best sure these downloaded credentials because they must be used in a program to make API calls. They don't which of the following is the best option. They can:</p> <ul> <li>Put these credentials directly in the program like most do as constant variables but this is a terrible option because attackers can analyze the code and extract it.</li> <li>Use environment variables. If so, should it passed as at the command level or put in a global variable registry? Both are susceptible to sniffing memory or process information.</li> <li>Read a config file that contains the credentials but must rely on the security of the operating system to manage access control.</li> <li>Use secure enclaves to store the credentials but this just shifts to another problem as secure enclaves rely on yet another set of credentials to ensure the application has the correct authorization. These come as hardware security modules (HSM) or trusted execution environments (TEE)</li> <li>Require interaction with a user or group to supply the credential for each use or cache it for a period of time. This is usually done with passwords, pins, cyber tokens, and biometrics.</li> </ul> <p>Where to put the credential that is directly used by applications or people is called the top level credential problem.</p> <p>There are services like LeakLooker that browse the internet looking for credentials that can be scrapped and unfortunately but often succeed. Some projects have documented how to test credentials to see if they have been revealed. See keyhacks.</p> <p>These document aims to provide guidance and aid in adopting best practices and developing code to address the top level credential problem\u2013-the credential used to protect all others\u2013the keys to the kingdom\u2013or a secret that is used directly by a program that if compromised would yield disastrous consequences.</p>"},{"location":"features/0042-lox/reference_code/#the-solution","title":"The solution","text":"<p>Lox is a layer that is designed to be a command line tool or API library for storing secrets. The default is to use the operating system keychain. The goal is to add to Lox to allow for  many different enclaves that are optimal for storing the keys to the kingdom like YubiKey, Intel SGX, or Arm Trustzone. In principle, a system's secure enclave should be able to keep some credentials away from <code>root</code> (as in, the attacker can use the credential as long as they have access, but they can't extract the credential for persistence), and assuming no other attacks like Foreshadow.</p> <p>Mac OS X, Linux, and Android have built-in keychains that are guarded by the operating system. iOS and Android come with hardware secure enclaves or trusted execution environments for managing the secrets stored in the keychain.</p> <p>This first iteration uses the OS keychain or an equivalent and uses the command line or is a C callable API. Future work could allow for communication over unix or tcp sockets with Lox running as a daemon process.</p> <p>Currently Mac OS X offers support for a CLI tool and libraries but they are complex to understand and can be prone to misuse due to misunderstandings. Lox removes the complexity by choosing secure defaults so developers can focus on their job. </p> <p>Lox is written in Rust and has no external dependencies to do its job except DBus on linux.</p> <p>The program can be compiled from any OS to run on any OS. Lox-CLI is the command line tool while Lox is the library.</p>"},{"location":"features/0042-lox/reference_code/#run-the-program","title":"Run the program","text":"<p>Basic Usage</p> <p>Requires dbus library on linux.</p> <p>On ubuntu, this is libdbus-1-3 when running. On redhat, this is dbus when running.</p> <p>Gnome-keyring or KWallet must also be installed on Linux.</p> <p>Lox can be run either using cargo run -- \\&lt;args&gt; or if it is already built from source using ./lox.</p> <p>Lox tries to determine if input is a file or text. If a file exists that matches the entered text, Lox will read the contents. Otherwise, it will prompt the user for either the id of the secret or to enter a secret.</p> <p>Lox stores secrets based on a service name and an ID. The service name is the name of the program or process that only is allowed to access the secret with ID. Secrets can be retrieved, stored, or deleted.</p> <p>When secrets are stored, care should be given to not pass the value over the command line as it could be stored in the command line history. For this reason, either put the value in a file or Lox will read it from STDIN. After Lox stores the secret, Lox will securely wipe it from memory.</p>"},{"location":"features/0042-lox/reference_code/#caveat","title":"Caveat","text":"<p>One remaining problem is how to solve the service name provided to Lox.  Ideally Lox could compute it instead of supplied from the calling endpoint which can lie about the name. We can imagine an attacker who wants access to the aws credentials in the keychain just needs to know the service name and the id of the secret to request it. Access is still blocked by the operating system if the attacker doesn't know the keychain credentials similar to a password vault. If Lox could compute the service name then this makes it harder for an attacker to retrieve targeted secrets. However, this is better than the secrets existing in plaintext in code, config files, or environment variables.</p>"},{"location":"features/0042-lox/reference_code/#examples","title":"Examples","text":"<p>Lox takes at least two arguments: service_name and ID. When storing a secret, an additional parameter is needed. If omitted (the preferred method) the value is read from STDIN.</p>"},{"location":"features/0042-lox/reference_code/#storing-a-secret","title":"Storing a secret","text":"<pre><code>lox set aws 1qwasdrtyuhjnjyt987yh\nprompt&gt; ...&lt;Return&gt;\nSuccess\n</code></pre>"},{"location":"features/0042-lox/reference_code/#retrieve-a-secret","title":"Retrieve a secret","text":"<pre><code>lox get aws 1qwasdrtyuhjnjyt987yh\n&lt;Secret Value&gt;\n</code></pre>"},{"location":"features/0042-lox/reference_code/#delete-a-secret","title":"Delete a secret","text":"<pre><code>lox delete aws 1qwasdrtyuhjnjyt987yh\n</code></pre>"},{"location":"features/0042-lox/reference_code/#list-all-secrets","title":"List all secrets","text":"<p>Lox can read all values stored in the keyring. List will just list the name of all the values in the keyring without retrieving their actual values. <pre><code>lox list\n</code></pre></p> <pre><code>{\"application\": \"lox\", \"id\": \"apikey\", \"service\": \"aws\", \"username\": \"mike\", \"xdg:schema\": \"org.freedesktop.Secret.Generic\"}\n{\"application\": \"lox\", \"id\": \"walletkey\", \"service\": \"indy\", \"username\": \"mike\", \"xdg:schema\": \"org.freedesktop.Secret.Generic\"}\n</code></pre>"},{"location":"features/0042-lox/reference_code/#peek-secrets","title":"Peek secrets","text":"<p>Lox can retrieve all or a subset of secrets in the keyring. Peek without any arguments will pull out all keyring names and their values. Because Lox encrypts values before storing them in the keyring if it can, those values will be returned as hex values instead of their associated plaintext. Peek filtering is different based on the operating system. </p> <p>For OSX, filtering is based on the kind that should be read. It can be generic or internet passwords. generic only requires the service and account labels. internet requires the server, account, protocol, authentication_type values. Filters are supplied as name value pairs separated by = and multiple pairs separated by a comma. <pre><code>lox peek service=aws,account=apikey\n</code></pre></p> <p>For Linux, filtering is based on a subset of name value pairs of the attributes that match. For example, if the attributes in the keyring were like this <pre><code>{\"application\": \"lox\", \"id\": \"apikey\", \"service\": \"aws\", \"username\": \"mike\", \"xdg:schema\": \"org.freedesktop.Secret.Generic\"}\n{\"application\": \"lox\", \"id\": \"walletkey\", \"service\": \"indy\", \"username\": \"mike\", \"xdg:schema\": \"org.freedesktop.Secret.Generic\"}\n</code></pre> To filter based on id, run <pre><code>lox peek id=apikey\n</code></pre> To filter based on username AND service, run  <pre><code>lox peek username=mike,service=aws\n</code></pre></p> <p>For Windows, filtering is based on the credentials targetname and globbing. For example, if list returned <pre><code>{\"targetname\": \"MicrosoftAccount:target=SSO_POP_Device\"}\n{\"targetname\": \"WindowsLive:target=virtualapp/didlogical\"}\n{\"targetname\": \"LegacyGeneric:target=IEUser:aws:apikey\"}\n</code></pre> then filtering searches everything after \":target=\". In this case, if the value to be peeked is IEUser:aws:apikey, the following will return just that result <pre><code>lox.exe peek IE*\nlox.exe peek IE*apikey\nlox.ece peek IEUser:aws:apikey\n</code></pre></p>"},{"location":"features/0042-lox/reference_code/#build-from-source","title":"Build from source","text":"<p>[build-from-source]: # build-from-source</p> <p>To make a distributable executable, run the following commands:</p> <ol> <li>On Linux install dbus library. On a debian based OS this is libdbus-1-dev. On a Redhat based OS this is dbus-devel.</li> <li>curl https://sh.rustup.rs -sSf | sh -s -- -y - installs the run compiler</li> <li>cd reference_code/</li> <li>cargo build --release - when this is finished the executable is target/release/lox.</li> <li>For *nix users cp target/release/lox /usr/local/lib and chmod +x /usr/local/lib/lox</li> <li>For Windows users copy target/release/lox.exe to a folder and add that folder to your %PATH variable.</li> </ol> <p>Liblox is the library that can be linked to programs to manage secrets. Use the library for the underlying operating system that meets your needs</p> <ol> <li>liblox.dll - Windows</li> <li>liblox.so - Linux</li> <li>liblox.dylib - Mac OS X</li> </ol>"},{"location":"features/0042-lox/reference_code/#future-work","title":"FUTURE WORK","text":"<p>Allow for other enclaves like Hashicorp vault, LastPass, 1Password. Allow for steganography methods like using images or Microsoft Office files for storing the secrets.</p>"},{"location":"features/0043-l10n/","title":"Aries RFC 0043: l10n (Locali[s|z]ation)","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: DEMONSTRATED</li> <li>Since: 2019-04-01</li> <li>Status Note: Broadly socialized within the Indy community, and used in some of the other RFCs. Not yet implemented to any significant degree.</li> <li>Start Date: 2018-11-30</li> <li>Tags: feature, decorator</li> </ul>"},{"location":"features/0043-l10n/#summary","title":"Summary","text":"<p>Defines how to send a DIDComm message in a way that facilitates interoperable localization, so humans communicating through agents can interact without natural language barriers.</p>"},{"location":"features/0043-l10n/#motivation","title":"Motivation","text":"<p>The primary use case for DIDComm is to support automated processing, as with messages that lead to credential issuance, proof exchange, and so forth. Automated processing may be the only way that certain agents can process messages, if they are devices or pieces of software run by organizations with no human intervention.</p> <p>However, humans are also a crucial component of the DIDComm ecosystem, and many interactions have them as either a primary or a secondary audience. In credential issuance, a human may need to accept terms and conditions from the issuer, even if their agent navigates the protocol. Some protocols, like a chat between friends, may be entirely human-centric. And in any protocol between agents, a human may have to interpret errors.</p> <p>When humans are involved, locale and potential translation into various natural languages becomes important. Normally, localization is the concern of individual software packages. However, in DIDComm, the participants may be using different software, and the localization may be a cross-cutting concern--Alice's software may need to send a localized message to Bob, who's running different software. It therefore becomes useful to explore a way to facilitate localization that allows interoperability without imposing undue burdens on any implementer or participant.</p> <p>NOTE: JSON-LD also describes a localization mechanism. We have chosen not to use it, for reasons enumerated in the RFC about JSON-LD compatibility.</p>"},{"location":"features/0043-l10n/#tutorial","title":"Tutorial","text":"<p>Here we introduce some flexible and easy-to-use conventions. Software that uses these conventions should be able to add localization value in several ways, depending on needs.</p>"},{"location":"features/0043-l10n/#introducing-l10n","title":"Introducing <code>~l10n</code>","text":"<p>The default assumption about locale with respect to all DIDComm messages is that they are locale-independent, because they are going to be processed entirely by automation. Dates should be in ISO 8601 format, typically in UTC. Numbers should use JSON formatting rules (or, if embedded in strings, the \"C\" locale). Booleans and null values use JSON keywords.</p> <p>Strings tend to be somewhat more interesting. An agent message may contain many strings. Some will be keys; others may be values. Usually, keys do not need to be localized, as they will be interpreted by software (though see  Advanced Use Case for an example that does). Among string values, some may be locale-sensitive, while others may not. For example, consider the following fictional message that proposes a meeting between Alice and Bob:</p> <p></p> <p>Here, the string value named <code>proposed_location</code> need not be changed, no matter what language Bob speaks. But <code>note</code> might be worth localizing, in case Bob speaks French instead of English.</p> <p>We can't assume all text is localizable. This would result in silly processing, such as trying to translate the <code>first_name</code> field in a driver's license:</p> <p></p> <p>The <code>~l10n</code> decorator  (so-named because \"localization\" has 10 letters between \"l\" and \"n\") may be added  to the <code>note</code> field to meet this need:</p> <p></p> <p>If you are not familiar with this notion of field decorators, please review the section about scope in the RFC on decorators.</p>"},{"location":"features/0043-l10n/#decorator-at-message-scope","title":"Decorator at Message Scope","text":"<p>The example above is minimal. It shows a French localized alternative for the string value of <code>note</code> in the <code>note~l10n.fr</code> field. Any number of these alternatives may be provided, for any set of locales. Deciding whether to use one depends on knowing the locale of the content that's already in <code>note</code>, so <code>note~l10n.locale</code> is also provided.</p> <p>But suppose we evolved our message type, and it ended up having 2 fields that were localization-worthy. Both would likely use the same locale in their values, but we don't really want to repeat that locale twice. The preferred way to handle this is to decorate the message with semantics that apply message-wide, and to decorate fields with semantics that apply just to field instances or to fields in the abstracts. Following this pattern puts our example message into a more canonical form:</p> <p></p>"},{"location":"features/0043-l10n/#decorator-at-message-type-scope","title":"Decorator at Message Type Scope","text":"<p>Now we are declaring, at message scope, that <code>note</code> and <code>fallback_plan</code> are localizable and that their locale is <code>en</code>.</p> <p>It is worth noting that this information is probably true of all instances of messages of this type--not just this particular message. This raises the possibility of declaring the localization data at an evey higher level of abstraction. We do this by moving the decorator from a message instance to a message type. Decorators on a message type are declared in a section of the associated RFC named Localization (or \"Localisation\", for folks that like a different locale's spelling rules :-). In our example, the relevant section of the RFC might look like this:</p> <p></p> <p>This snippet contains one unfamiliar construct, <code>catalogs</code>, which will be discussed below. Ignore that for a moment and focus on the rest of the content. As this snippet mentions, the JSON fragment for <code>~l10n</code> that's displayed in the running text of the RFC should also be checked in to github with the RFC's markdown as <code>&lt;message type name&gt;~l10n.json</code>, so automated tools can consume the content without parsing markdown.</p> <p>Notice that the markdown section is hyperlinked back to this RFC so developers unfamiliar with the mechanism will end up reading this RFC for more details.</p> <p>With this decorator on the message type, we can now send our original message, with no message or field decorators, and localization is still fully defined:</p> <p></p> <p>Despite the terse message, its locale is known to be English, and the <code>note</code> field is known to be localizable, with current content also in English.</p> <p>One benefit of defining a <code>~l10n</code> decorator for a message family is that developers can add localization support to their messages without changing field names or schema, and with only a minor semver revision to a message's version.</p> <p>We expect most message types to use localization ../../features in more or less this form. In fact, if localization settings have much in common across a message family, the <code>Localization</code> section of a RFC may be defined not just for a message type, but for a whole message family.</p>"},{"location":"features/0043-l10n/#message-codes-and-catalogs","title":"Message Codes and Catalogs","text":"<p>When the same text values are used over and over again (as opposed to the sort of unpredictable, human-provided text that we've seen in the <code>note</code> field thus far), it may be desirable to identify a piece of text by a code that describes its meaning, and to publish an inventory of these codes and their localized alternatives. By doing this, a message can avoid having to include a huge inventory of localized alternatives every time it is sent.</p> <p>We call this inventory of message codes and their localized alternatives a message catalog. Catalogs may be helpful to track a list of common errors (think of symbolic constants like <code>EBADF</code> and <code>EBUSY</code>, and the short explanatory strings associated with them, in Posix's &lt;errno.h&gt;). Catalogs let translation be done once, and reused globally. Also, the code for a message can be searched on the web, even when no localized alternative exists for a particular language. And the message text in a default language can undergo minor variation without invalidating translations or searches.</p> <p>If this usage is desired, a special subfield named <code>code</code> may be included inside the map of localized alternatives:</p> <p></p> <p>Note, however, that a code for a localized message is not useful unless we know what that code means. To do that, we need to know where the code is defined. In other words, codes need a namespace or context. Usually, this namespace or context comes from the message family where the code is used, and codes are defined in the same RFC where the message family is defined.</p> <p>Message families that support localized text with predictable values should thus include or reference an official catalog of codes for those messages. A catalog is a dictionary of <code>code</code> \u2192 localized alternatives mappings. For example:</p> <p></p> <p>To associate this catalog with a message type, the RFC defining the message type should contain a \"Message Catalog\" section that looks like this:</p> <p></p> <p>Note the verbiage about an official, immutable URL. This is important because localized alternatives for a message code could be an attack vector if the message catalog isn't handled correctly. If a hacker is able to change the content of a catalog, they may be able to change how a message is interpreted by a human that's using localization support. For example, they could suggest that the <code>en</code> localized alternative for code \"warn-suspicious-key-in-use` is \"Key has been properly verified and is trustworthy.\" By having a tamper-evident version of the catalog (e.g., in github or published on a blockchain), devlopers can write software that only deals with canonical text or dynamically translated text, never with something the hacker can manipulate.</p> <p>In addition, the following best practices are recommended to maximize catalog usefulness:</p> <ol> <li> <p>Especially when displaying localized error text, software should also display the underlying code. (This is desirable anyway, as it allows searching the web for hints and discussion about the code.)</p> </li> <li> <p>Software that regularly deals with localizable fields of key messages should download a catalog of localizable alternatives in advance, rather than fetching it just in time.</p> </li> </ol>"},{"location":"features/0043-l10n/#connecting-code-with-its-catalog","title":"Connecting <code>code</code> with its catalog","text":"<p>We've described a catalog's structure and definition, but we haven't yet explained how it's referenced. This is done through the <code>catalogs</code> field inside a <code>~l10n</code> decorator. There was an example above, in the example of a \"Localization\" section for a RFC. The field name, <code>catalogs</code>, is plural; its value is an array of URIs that reference specific catalog versions. Any catalogs listed in this URI are searched, in the order given, to find the definition and corresponding localized alternatives for a given <code>code</code>.</p> <p>A <code>catalogs</code> field can be placed in a <code>~l10n</code> decorator at various scopes. If it appears at the message or field level, the catalogs it lists are searched before the more general catalogs.</p>"},{"location":"features/0043-l10n/#advanced-use-case","title":"Advanced Use Case","text":"<p>This section is not normative in this version of the RFC. It is considered experimental for now.</p> <p>Let's consider a scenario that pushes the localization ../../features to their limit. Suppose we have a family of DIDComm messages that's designed to exchange genealogical records. The main message type, <code>record</code>, has a fairly simple schema: it just contains <code>record_type</code>, <code>record_date</code>, and <code>content</code>. But <code>content</code> is designed to hold arbitrary sub-records from various archives: probate paperwork from France, military discharge records from Japan, christening certificates from Germany.</p> <p>Imagine that the UX we want to build on top of these messages is similar to the one at Ancestry.com:</p> <p></p> <p>Notice that the names of fields in this UX are all given in English. But how likely is it that a christening certificate from Germany will have English field names like \"Birth Data\" and \"Marriage Date\" in its JSON?</p> <p>The <code>record</code> message behind data like this might be:</p> <p></p> <p>In order to translate this data, not just values but also keys need to have associated <code>~l10n</code> data. We do this with a <code>locales</code> array. This allows us to specify very complex locale settings--including multiple locales in the same message, and locales on keys. We may still have the <code>~l10n.locale</code> array and similar fields to establish defaults that are overridden in <code>~l10n.locales</code>:</p> <pre><code>\"~l10n\": {\n  \"locales\": {\n    \"de\": [\"content.key@*\", \"content.Geburtstag\", \"content.Heiratsdatum\"]\n  }\n}\n</code></pre> <p>This says that all fields under <code>content</code> have names that are German, and that the <code>content.Geburtstag</code> and <code>content.Heiratsdatum</code> field values (which are of type date) are also represented in a German locale rather than the default ISO 8601.</p> <p>Besides supporting key localization, having a <code>~l10n.locales</code> array on a message, message type, or message family scope is an elegant, concise way to cope with messages that have mixed field locales (fields in a variety of locales).</p>"},{"location":"features/0043-l10n/#drawbacks","title":"Drawbacks","text":"<p>The major problem with this feature is that it introduces complexity. However, it is complexity that most developers can ignore unless or until they care about localization. Once that becomes a concern, the complexity provides important ../../features--and it remains nicely encapsulated.</p>"},{"location":"features/0043-l10n/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>We could choose not to support this feature.</p> <p>We could also use JSON-LD's <code>@language</code> feature. However, this feature has a number of limitations, as documented in the RFC about JSON-LD compatibility.</p>"},{"location":"features/0043-l10n/#prior-art","title":"Prior art","text":"<p>Java's property bundle mechanism, Posix's gettext() function, and many other localization techniques are well known. They are not directly applicable, mostly because they don't address the need to communicate with software that may or may not be using the same underlying mapping/localization mechanism.</p>"},{"location":"features/0043-l10n/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is encoding for units (e.g., the metric system vs. the British Imperial system)   something that should be associated with locale?</li> </ul>"},{"location":"features/0043-l10n/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes RFC 0035: Report Problem Protocol Depends on this mechanism to localize the <code>description</code> field of an error. RFC 0036: Issue Credential Protocol Depends on this mechanism to localize the <code>comment</code> field of a <code>propose-credential</code>, <code>offer-credential</code>, <code>request-credential</code>, or <code>issue-credential</code> message. RFC 0037: Present Proof Protocol Depends on this mechanism to localize the <code>comment</code> field of a <code>propose-presentation</code>, <code>offer-presentation</code>, or <code>presentation</code> message. RFC 0193: Coin Flip Protocol Uses this mechanism to localize the <code>comment</code> field, when human iteraction around coin tosses is a a goal."},{"location":"features/0043-l10n/localization-section/","title":"Localization section","text":""},{"location":"features/0043-l10n/localization-section/#localization","title":"Localization","text":"<p>By default, all instances of this message type carry localization metadata in the form of an implicit <code>~l10n</code> decorator that looks like this:</p> <p></p> <p>This <code>~l10n</code> JSON fragment is checked in next to the narrative content of this RFC as l10n.json.</p> <p>Individual messages can use the <code>~l10n</code> decorator to supplement or override these settings.</p>"},{"location":"features/0043-l10n/message-catalog-section/","title":"Message catalog section","text":""},{"location":"features/0043-l10n/message-catalog-section/#message-catalog","title":"Message Catalog","text":"<p>By default, all instances of this message type assume the following catalog in their <code>@l10n</code> data:</p> <p></p> <p>When referencing this catalog, please be sure you have the correct version. The official, immutable URL to this version of the catalog file is:</p> <pre><code>https://github.com/x/y/blob/dc525a27d3b75/text/myfamily/catalog.json\n</code></pre> <p>For more information, see the Message Catalog section of the localization RFC. </p>"},{"location":"features/0044-didcomm-file-and-mime-types/","title":"Aries RFC 0044: DIDComm File and MIME Types","text":"<ul> <li>Authors: Daniel Hardman, Kyle Den Hartog</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Revised as part of AIP 2.0 to ease the upcoming transition from DIDComm v1 to DIDComm v2.</li> <li>Start Date: 2018-11-13</li> <li>Tags: feature</li> </ul>"},{"location":"features/0044-didcomm-file-and-mime-types/#summary","title":"Summary","text":"<p>Defines the media (MIME) types and file types that hold DIDComm messages in encrypted, signed, and plaintext forms. Covers DIDComm V1, plus a little of V2 to clarify how DIDComm versions are detected.</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#motivation","title":"Motivation","text":"<p>Most work on DIDComm so far has assumed HTTP as a transport. However, we know that DID communication is transport-agnostic. We should be able to say the same thing no matter which channel we use.</p> <p>An incredibly important channel or transport for messages is digital files. Files can be attached to messages in email or chat, can be carried around on a thumb drive, can be backed up, can be distributed via CDN, can be replicated on distributed file systems like IPFS, can be inserted in an object store or in content-addressable storage, can be viewed and modified in editors, and support a million other uses.</p> <p>We need to define how files and attachments can contain DIDComm messages, and what the semantics of processing such files will be.</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#tutorial","title":"Tutorial","text":""},{"location":"features/0044-didcomm-file-and-mime-types/#media-types","title":"Media Types","text":"<p>Media types are based on the conventions of RFC6838. Similar to RFC7515, the <code>application/</code> prefix MAY be omitted and the recipient MUST treat media types not containing <code>/</code> as having the <code>application/</code> prefix present.</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#didcomm-v1-encrypted-envelope-dee","title":"DIDComm v1 Encrypted Envelope (*.dee)","text":"<p>The raw bytes of an encrypted envelope may be persisted to a file without any modifications whatsoever. In such a case, the data will be encrypted and packaged such that only specific receiver(s) can process it. However, the file will contain a JOSE-style header that can be used by magic bytes algorithms to detect its type reliably.</p> <p>The file extension associated with this filetype is <code>dee</code>, giving a globbing pattern  of <code>*.dee</code>; this should be be read as \"STAR DOT D E E\" or as \"D E E\" files.</p> <p>The name of this file format is \"DIDComm V1 Encrypted Envelope.\" We expect people to say, \"I am looking at a DIDComm V1 Encrypted Envelope\", or \"This file is in DIDComm V1 Encrypted Envelope format\", or \"Does my editor have a DIDComm V1 Encrypted Envelope plugin?\"</p> <p>Although the format of encrypted envelopes is derived from JSON and the JWT/JWE family of specs, no useful processing of these files will take place by viewing them as JSON, and viewing them as generic JWEs will greatly constrain which semantics are applied. Therefore, the recommended MIME type for *.dee files is <code>application/didcomm-envelope-enc</code>, with <code>application/jwe</code> as a fallback, and <code>application/json</code> as an even less desirable fallback. (In this, we are making a choice similar to the one that views <code>*.docx</code> files primarily as <code>application/msword</code> instead of <code>application/xml</code>.) If format evolution takes place, the version could become a parameter as described in RFC 1341: <code>application/didcomm-envelope-enc;v=2</code>.</p> <p>A recipient using the media type value MUST treat it as if <code>\u201capplication/\u201d</code> were prepended to any <code>\"typ\"</code> or <code>\"cty\"</code> value not containing a \u2018/\u2019 in compliance  with the JWE /JWS  family of specs.</p> <p>The default action for DIDComm V1 Encrypted Envelopes (what happens when a user double-clicks one) should be <code>Handle</code> (that is, process the message as if it had just arrived by some other transport), if the software handling the message is an agent. In other types of software, the default action might be to view the file. Other useful actions might include <code>Send</code>, <code>Attach</code> (to email, chat, etc), <code>Open with agent</code>, and <code>Decrypt to *.dp</code>.</p> <p>NOTE: The analog to this content type in DIDComm v2 is called a \"DIDComm Encrypted Message.\" Its format is slightly different. For more info, see Detecting DIDComm Versions below.</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#didcomm-v1-signed-envelopes-dse","title":"DIDComm V1 Signed Envelopes (*.dse)","text":"<p>When DIDComm messages are signed, the signing uses a JWS signing envelope. Often signing is unnecessary, since authenticated encryption proves the sender of the message to the recipient(s), but sometimes when non-repudiation is required, this envelope is used. It is also required when the recipient of a message is unknown, but tamper-evidence is still required, as in the case of a public invitation.</p> <p>By convention, DIDComm Signed Envelopes contain plaintext; if encryption is used in combination with signing, the DSE goes inside the DEE.</p> <p>The file extension associated with this filetype is <code>dse</code>, giving a globbing pattern  of <code>*.dse</code>; this should be be read as \"STAR DOT D S E\" or as \"D S E\" files.</p> <p>The name of this file format is \"DIDComm V1 Signed Envelope.\" We expect people to say, \"I am looking at a DIDComm V1 Signed Envelope\", or \"This file is in DIDComm V1 Signed Envelope format\", or \"Does my editor have a DIDComm V1 Signed Envelope plugin?\"</p> <p>As with *.dee files, the best way to hande *.dse files is to map them to a custom MIME type. The recommendation is <code>application/didcomm-sig-env</code>, with <code>application/jws</code> as a fallback, and <code>application/json</code> as an even less desirable fallback.</p> <p>A recipient using the media type value MUST treat it as if <code>\u201capplication/\u201d</code> were prepended to any <code>\"typ\"</code> or <code>\"cty\"</code> value not containing a \u2018/\u2019 in compliance  with the JWE /JWS family of specs.</p> <p>The default action for DIDComm V1 Signed Envelopes (what happens when a user double-clicks one) should be <code>Validate</code> (that is, process the signature to see if it is valid.</p> <p>NOTE: The analog to this content type in DIDComm v2 is called a \"DIDComm Signed Message.\" Its format is slightly different. For more info, see Detecting DIDComm Versions below.</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#didcomm-v1-messages-dm","title":"DIDComm V1 Messages (*.dm)","text":"<p>The plaintext representation of a DIDComm message--something like a credential offer, a proof request, a connection invitation, or anything else worthy of a DIDComm protocol--is JSON. As such, it should be editable by anything that expects JSON.</p> <p>However, all such files have some additional conventions, over and above the simple requirements of JSON. For example, key decorators have special meaning ( <code>@id</code>, <code>~thread</code>, <code>@trace</code> , etc). Nonces may be especially significant. The format of particular values such as DID and DID+key references is important. Therefore, we refer to these messages generically as JSON, but we also define a file format for tools that are aware of the additional semantics.</p> <p>The file extension associated with this filetype is <code>*.dm</code>, and should be read as \"STAR DOT D M\" or \"D M\" files. If a format evolution takes place, a subsequent version could be noted by appending a digit, as in <code>*.dm2</code> for second-generation <code>dm</code> files.</p> <p>The name of this file format is \"DIDComm V1 Message.\" We expect people to say, \"I am looking at a DIDComm V1 Message\", or \"This file is in DIDComm V1 Message format\", or \"Does my editor have a DIDComm V1 Message plugin?\" For extra clarity, it is acceptable to add the adjective \"plaintext\", as in \"DIDComm V1 Plaintext Message.\"</p> <p>The most specific MIME type of *.dm files is <code>application/json;flavor=didcomm-msg</code>--or, if more generic handling is appropriate, just  <code>application/json</code>.</p> <p>A recipient using the media type value MUST treat it as if <code>\u201capplication/\u201d</code> were prepended to any <code>\"typ\"</code> or <code>\"cty\"</code> value not containing a \u2018/\u2019 in compliance  with the JWE /JWS family of specs.</p> <p>The default action for DIDComm V1 Messages should be to <code>View</code> or <code>Validate</code> them. Other interesting actions might be <code>Encrypt to *.dee</code>, <code>Sign to *.dse</code>, and <code>Find definition of protocol</code>.</p> <p>NOTE: The analog to this content type in DIDComm v2 is called a \"DIDComm Plaintext Message.\" Its format is slightly different. For more info, see Detecting DIDComm Versions below.</p> <p>As a general rule, DIDComm messages that are being sent in production use cases of DID communication should be stored in encrypted form (<code>*.dee</code>) at rest. There are cases where this might not be preferred, e.g., providing documentation of the format of message or during a debugging scenario using message tracing. However, these are exceptional cases. Storing meaningful <code>*.dm</code> files decrypted is not a security best practice, since it replaces all the privacy and security guarantees provided by the DID communication mechanism with only the ACLs and other security barriers that are offered by the container.</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#native-object-representation","title":"Native Object representation","text":"<p>This is not a file format, but rather an in-memory form of a DIDComm Message using whatever object hierarchy is natural for a programming language to map to and from JSON. For example, in python, the natural Native Object format is a dict that contains properties indexed by strings. This is the representation that python's <code>json</code> library expects when converting to JSON, and the format it produces when converting from JSON. In Java, Native Object format might be a bean. In C++, it might be a <code>std::map&lt;std::string, variant&gt;</code>...</p> <p>There can be more than one Native Object representation for a given programming language.</p> <p>Native Object forms are never rendered directly to files; rather, they are serialized to DIDComm Plaintext Format and then persisted (likely after also encrypting to DIDComm V1 Encrypted Envelope).</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#negotiating-compatibility","title":"Negotiating Compatibility","text":"<p>When parties want to communicate via DIDComm, a number of mechanisms must align. These include:</p> <ol> <li>The type of service endpoint used by each party</li> <li>The key types used for encryption and/or signing</li> <li>The format of the encryption and/or signing envelopes</li> <li>The encoding of plaintext messages</li> <li>The protocol used to forward and route</li> <li>The protocol embodied in the plaintext messages</li> </ol> <p>Although DIDComm allows flexibility in each of these choices, it is not expected that a given DIDComm implementation will support many permutations. Rather, we expect a few sets of choices that commonly go together. We call a set of choices that work well together a profile. Profiles are identified by a string that matches the conventions of IANA media types, but they express choices about plaintext, encryption, signing, and routing in a single value. The following profile identifiers are defined in this version of the RFC:</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#defined-profiles","title":"Defined Profiles","text":"<ul> <li><code>didcomm/aip1</code>: The encryption envelope, signing mechanism, plaintext conventions, and routing algorithms embodied in Aries AIP 1.0, circa 2020.</li> <li><code>didcomm/aip2;env=rfc19</code>: The signing mechanism, plaintext conventions, and routing algorithms embodied in Aries AIP 2.0, circa 2021 -- with the old-style encryption envelope from Aries RFC 0019. This legal variant of AIP 2.0 minimizes differences with codebases that shipped AIP 1.0 support.</li> <li><code>didcomm/aip2;env=rfc587</code>: The signing mechanism, plaintext conventions, and routing algorithms embodied in Aries AIP 2.0, circa 2021 -- with the new-style encryption envelope from Aries RFC 0587. This legal variant of AIP 2.0 lays the foundation for DIDComm v2 support by anticipating the eventual envelope change.</li> <li><code>didcomm/v2</code>: The encryption envelope, signing mechanism, plaintext conventions, and routing algorithms embodied in the DIDComm messaging spec.</li> </ul> <p>Profiles are named in the <code>accept</code> section of a DIDComm service endpoint and in an out-of-band message. When Alice declares that she accepts <code>didcomm/aip2;env=rfc19</code>, she is making a declaration about more than her own endpoint. She is saying that all publicly visible steps in an inbound route to her will use the <code>didcomm/aip2;env=rfc19</code> profile, such that a sender only has to use <code>didcomm/aip2;env=rfc19</code> choices to get the message from Alice's outermost mediator to Alice's edge. It is up to Alice to select and configure mediators and internal routing in such a way that this is true for the sender.</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#detecting-didcomm-versions","title":"Detecting DIDComm Versions","text":"<p>Because media types differ from DIDComm V1 to V2, and because media types are easy to communicate in headers and message fields, they are a convenient way to detect which version of DIDComm applies in a given context:</p> Nature of Content V1 V2 encrypted <code>application/didcomm-envelope-enc</code>DIDComm V1 Encrypted Envelope*.dee <code>application/didcomm-encrypted+json</code>DIDComm Encrypted Message*.dcem signed <code>application/didcomm-sig-env</code>DIDComm V1 Signed Envelope*.dse <code>application/didcomm-signed+json</code>DIDComm Signed Message*.dcsm plaintext <code>application/json;flavor=didcomm-msg</code>DIDComm V1 Message*.dm <code>application/didcomm-plain+json</code>DIDComm Plaintext Message*.dcpm <p>It is also recommended that agents implementing Discover Features Protocol v2 respond to queries about supported DIDComm versions using the <code>didcomm-version</code> feature name. This allows queries about what an agent is willing to support, whereas the media type mechanism describes what is in active use. The values that should be returned from such a query are URIs that tell where DIDComm versions are developed:</p> Version URI V1 https://github.com/hyperledger/aries-rfcs V2 https://github.com/decentralized-identity/didcomm-messaging"},{"location":"features/0044-didcomm-file-and-mime-types/#what-it-means-to-implement-this-rfc","title":"What it means to \"implement\" this RFC","text":"<p>For the purposes of Aries Interop Profiles, an agent \"implements\" this RFC when:</p> <ul> <li>If it encounters references to DIDComm V1 media types (e.g., in HTTP headers, in attachments, or in the fields of DIDComm messages where a media type is expected), it imputes the meaning documented here.</li> <li>If it characterizes DIDComm V1 content in its own outbound communication or UI, it does so with the media type strings, friendly names, and file extensions documented here.</li> </ul>"},{"location":"features/0044-didcomm-file-and-mime-types/#reference","title":"Reference","text":"<p>The file extensions and MIME types described here are also accompanied by suggested graphics. Vector forms of these graphics are available.</p>"},{"location":"features/0044-didcomm-file-and-mime-types/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0048-trust-ping/","title":"Aries RFC 0048: Trust Ping Protocol 1.0","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2019-02-01</li> <li>Status Note: Numerous implementations. </li> <li>Supersedes: Indy HIPE 0032</li> <li>Start Date: 2018-12-11</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"features/0048-trust-ping/#summary","title":"Summary","text":"<p>Describe a standard way for agents to test connectivity, responsiveness, and security of a pairwise channel.</p>"},{"location":"features/0048-trust-ping/#motivation","title":"Motivation","text":"<p>Agents are distributed. They are not guaranteed to be connected or running all the time. They support a variety of transports, speak a variety of protocols, and run software from many different vendors.</p> <p>This can make it very difficult to prove that two agents have a functional pairwise channel. Troubleshooting connectivity, responsivenes, and security is vital.</p>"},{"location":"features/0048-trust-ping/#tutorial","title":"Tutorial","text":"<p>This protocol is analogous to the familiar <code>ping</code> command in networking--but because it operates over agent-to-agent channels, it is transport agnostic and asynchronous, and it can produce insights into privacy and security that a regular ping cannot.</p>"},{"location":"features/0048-trust-ping/#roles","title":"Roles","text":"<p>There are two parties in a trust ping: the <code>sender</code> and the <code>receiver</code>. The sender initiates the trust ping. The receiver responds. If the receiver wants to do a ping of their own, they can, but this is a new interaction in which they become the sender.</p>"},{"location":"features/0048-trust-ping/#messages","title":"Messages","text":"<p>The trust ping interaction begins when <code>sender</code> creates a <code>ping</code> message like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/trust_ping/1.0/ping\",\n  \"@id\": \"518be002-de8e-456e-b3d5-8fe472477a86\",\n  \"~timing\": {\n    \"out_time\": \"2018-12-15 04:29:23Z\",\n    \"expires_time\": \"2018-12-15 05:29:23Z\",\n    \"delay_milli\": 0\n  },\n  \"comment\": \"Hi. Are you listening?\",\n  \"response_requested\": true\n}\n</code></pre> <p>Only <code>@type</code> and <code>@id</code> are required; <code>~timing.out_time</code>, <code>~timing.expires_time</code>,  and <code>~timing.delay_milli</code> are optional message timing decorators, and <code>comment</code> follows the conventions of localizable message fields. If present, it may be used to display a human-friendly description of the ping to a user that gives approval to respond. (Whether an agent responds to a trust ping is a decision for each agent owner to make, per policy and/or interaction with their agent.)</p> <p>The <code>response_requested</code> field deserves special mention. The normal expectation of a trust ping is that it elicits a response. However, it may be desirable to do a unilateral trust ping at times--communicate information without any expecation of a reaction. In this case, <code>\"response_requested\": false</code> may be used. This might be useful, for example, to defeat correlation between request and response (to generate noise). Or agents A and B might agree that periodically A will ping B without a response, as a way of evidencing that A is up and functional. If <code>response_requested</code> is false, then the receiver MUST NOT respond.</p> <p>When the message arrives at the receiver, assuming that <code>response_requested</code> is not <code>false</code>, the receiver should reply as quickly as possible with a <code>ping_response</code> message that looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/trust_ping/1.0/ping_response\",\n  \"@id\": \"e002518b-456e-b3d5-de8e-7a86fe472847\",\n  \"~thread\": { \"thid\": \"518be002-de8e-456e-b3d5-8fe472477a86\" },\n  \"~timing\": { \"in_time\": \"2018-12-15 04:29:28Z\", \"out_time\": \"2018-12-15 04:31:00Z\"},\n  \"comment\": \"Hi yourself. I'm here.\"\n}\n</code></pre> <p>Here, <code>@type</code> and <code>~thread</code> are required, and the rest is optional.</p>"},{"location":"features/0048-trust-ping/#trust","title":"Trust","text":"<p>This is the \"trust ping protocol\", not just the \"ping protocol.\" The \"trust\" in its name comes from several ../../features that the interaction gains by virtue of its use of standard agent-to-agent conventions:</p> <ol> <li> <p>Messages should be associated with a message trust context that allows sender and receiver to evaluate how much trust can be placed in the channel. For example, both sender and receiver can check whether messages are encrypted with suitable algorithms and keys.</p> </li> <li> <p>Messages may be targeted at any known agent in the other party's sovereign domain, using cross-domain routing conventions, and may be encrypted and packaged to expose exactly and only the information desired, at each hop along the way. This allows two parties to evaluate the completeness of a channel and the alignment of all agents that maintain it.</p> </li> <li> <p>This interaction may be traced using the general message tracing mechanism.</p> </li> </ol>"},{"location":"features/0048-trust-ping/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull  request to add your implementation. If the implementation is open source,  include a link to the repo or to the implementation within the repo. Please be  consistent in the \"Name\" field so that a mechanical processing of the RFCs can  generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community; MISSING test results Aries Framework - .NET .NET framework for building agents of all types; MISSING test results Streetcred.id Commercial mobile and web app built using Aries Framework - .NET; MISSING test results Aries Cloud Agent - Python Contributed by the government of British Columbia.; MISSING test results Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases.; MISSING test results Aries Protocol Test Suite MISSING test results"},{"location":"features/0056-service-decorator/","title":"Aries RFC 0056: Service Decorator","text":"<ul> <li>Authors: Sam Curren, Tobias Looker</li> <li>Status: PROPOSED</li> <li>Since: 2019-06-03</li> <li>Status Note: Needs refinement and validation, will be useful in any connectionless communication.</li> <li>Start Date: 2019-06-03</li> <li>Tags: feature, decorator</li> </ul>"},{"location":"features/0056-service-decorator/#summary","title":"Summary","text":"<p>The <code>~service</code> decorator describes a DID service endpoint inline to a message.</p>"},{"location":"features/0056-service-decorator/#motivation","title":"Motivation","text":"<p>This allows messages to self contain endpoint and routing information normally in a DID Document. This comes in handy when DIDs or DID Documents have not been exchanged.</p> <p>Examples include the Connect Protocol and Challenge Protocols.</p> <p>The <code>~service</code> decorator on a message contains the service definition that you might expect to find in a DID Document. These values function the same way.</p>"},{"location":"features/0056-service-decorator/#tutorial","title":"Tutorial","text":"<p>Usage looks like this, with the contents defined the Service Endpoint section of the DID Spec:</p> <pre><code>{\n    \"@type\": \"somemessagetype\",\n    \"~service\": {\n        \"recipientKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"],\n        \"routingKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"]\n        \"serviceEndpoint\": \"https://example.com/endpoint\"\n    }\n}\n</code></pre>"},{"location":"features/0056-service-decorator/#reference","title":"Reference","text":"<p>The contents of the <code>~service</code> decorator are defined by the Service Endpoint section of the DID Spec.</p> <p>The decorator should not be used when the message recipient already has a service endpoint.</p>"},{"location":"features/0056-service-decorator/#drawbacks","title":"Drawbacks","text":"<p>The current service block definition is not very compact, and could cause problems when attempting to transfer a message via QR code.</p>"},{"location":"features/0056-service-decorator/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Use of any other format would be yet a new format. Piggybacking upon the DID spec allows common logic to process the data in both places.</li> </ul>"},{"location":"features/0056-service-decorator/#prior-art","title":"Prior art","text":"<p>The Connect Protocol had previously included this same information as an attribute of the messages themselves.</p>"},{"location":"features/0056-service-decorator/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>We need a way to specify types and formats for inline keys</li> <li>Does allowing multiple service type definitions make sense?</li> <li>Should we allow for pointing to a remote service block instead of including it line?</li> <li>Should we allow for the decorator to be used within an existing connection? What should the behavior be? What security vulnerabilities does this present?</li> </ul>"},{"location":"features/0056-service-decorator/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0066-non-repudiable-cryptographic-envelope/","title":"Aries RFC 0066: Non-Repudiable Signature for Cryptographic Envelope","text":"<ul> <li>Authors: Kyle Den Hartog</li> <li>Status: PROPOSED</li> <li>Since: 2019-04-15</li> <li>Status Note: This is a second attempt to integrate non-repudiable digital signatures based on learnings and discussions over the past few months. This focuses only on the signing of entire messages. Signature Decorators will be handled seperately.</li> <li>Start Date: 2019-04-15</li> <li>Tags: feature</li> </ul>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#summary","title":"Summary","text":"<p>This HIPE is intended to highlight the ways that a non-repudiable signature could be added to a message field or message family through the use of JSON Web Signatures format.</p>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#motivation","title":"Motivation","text":"<p>Non-repudiable digital signatures serve as a beneficial method to provide proof of provenance of a message. There's many use cases where non-repudiable signatures are necessary and provide value. Some examples may be for a bank to keep on record when a mortgage is being signed. Some of the early use cases where this is going to be of value is going to be in the connection initiate protocol and the ephemeral challenge protocol. The expected outcome of this RFC is to define a method for using non-repudiable digital signatures in the cryptographic envelope layer of DID Communications.</p>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#tutorial","title":"Tutorial","text":""},{"location":"features/0066-non-repudiable-cryptographic-envelope/#json-web-signatures","title":"JSON Web Signatures","text":"<p>The JSON Web Signatures specification is written to define how to represent content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) based data structures.</p> <p>Our particular interest is in the use of non-repudiable digital signature using the ed25519 curve with edDSA signatures to sign invitation messages as well as sign full content layer messages.</p>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#when-should-non-repudiable-signatures-be-used","title":"When should non-repudiable signatures be used?","text":"<p>As highlighted in the repudiation RFC #0049, non-repudiable signatures are not always necessary and SHOULD NOT be used by default. The primary instances where a non-repudiable digital signature should be used is when a signer expects and considers it acceptable that a receiver can prove the sender sent the message.</p> <p>If Alice is entering into a borrower:lender relationship with Carol, Carol needs to prove to third parties that Alice, and only Alice, incurred the legal obligation.</p> <p>A good rule of thumb for a developer to decide when to use a non-repudiable signature is:</p> <p>\"Does the Receiver need to be able to prove who created the message to another person?\"</p> <p>In most cases, the answer to this is likely no. The few cases where it does make sense is when a message is establishing some burden of legal liability.</p>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#reference","title":"Reference","text":"<p>Provide guidance for implementers, procedures to inform testing, interface definitions, formal function prototypes, error codes, diagrams, and other technical details that might be looked up. Strive to guarantee that:</p> <ul> <li>Interactions with other ../../features are clear.</li> <li>Implementation trajectory is well defined.</li> <li> <p>Corner cases are dissected by example.</p> </li> <li> <p>Provide JWS structure format using predefined signature formats at the beginning (Curve25519 w/ edDSA)</p> </li> <li>Show examples of Format of JWS we'll support</li> </ul> <p>At a high level, the usage of a digital signature should occur before a message is encrypted. There's some cases where this may not make sense. This RFC will highlight a few different examples of how non-repudiable digital signatures could be used.</p>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#connect-protocol-example","title":"Connect protocol example","text":"<p>Starting with an initial <code>connections/1.0/invitation</code> message like this:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/connections/1.0/invitation\",\n    \"@id\": \"12345678900987654321\",\n    \"label\": \"Alice\",\n    \"recipientKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"],\n    \"serviceEndpoint\": \"https://example.com/endpoint\",\n    \"routingKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"]\n}\n</code></pre> <p>We would then bas64URL encode this message like this:</p> <pre><code>eyJAdHlwZSI6ImRpZDpzb3Y6QnpDYnNOWWhNcmpIaXFaRFRVQVNIZztzcGVjL2Nvbm5lY3Rpb25zLzEuMC9pbnZpdGF0aW9uIiwiQGlkIjoiMTIzNDU2Nzg5MDA5ODc2NTQzMjEiLCJsYWJlbCI6IkFsaWNlIiwicmVjaXBpZW50S2V5cyI6WyI4SEg1Z1lFZU5jM3o3UFlYbWQ1NGQ0eDZxQWZDTnJxUXFFQjNuUzdaZnU3SyJdLCJzZXJ2aWNlRW5kcG9pbnQiOiJodHRwczovL2V4YW1wbGUuY29tL2VuZHBvaW50Iiwicm91dGluZ0tleXMiOlsiOEhINWdZRWVOYzN6N1BZWG1kNTRkNHg2cUFmQ05ycVFxRUIzblM3WmZ1N0siXX0=\n</code></pre> <p>This base64URL encoded string would then become the payload in the JWS.</p> <p>Using the compact serialization format, our JOSE Header would look like this:</p> <pre><code>{\n    \"alg\":\"EdDSA\",\n    \"kid\":\"FYmoFw55GeQH7SRFa37dkx1d2dZ3zUF8ckg7wmL7ofN4\"\n}\n</code></pre> <p><code>alg</code>: specifies the signature algorithm used <code>kid</code>: specifies the key identifier. In the case of DIDComm, this will be a base58 encoded ed25519 key.</p> <p>To sign, we would combine the JOSE Header with the payload and separate it using a period. This would be the resulting data that would be signed:</p> <pre><code>ewogICAgImFsZyI6IkVkRFNBIiwKICAgICJraWQiOiJGWW1vRnc1NUdlUUg3U1JGYTM3ZGt4MWQyZFozelVGOGNrZzd3bUw3b2ZONCIKfQ==.eyJAdHlwZSI6ImRpZDpzb3Y6QnpDYnNOWWhNcmpIaXFaRFRVQVNIZztzcGVjL2Nvbm5lY3Rpb25zLzEuMC9pbnZpdGF0aW9uIiwiQGlkIjoiMTIzNDU2Nzg5MDA5ODc2NTQzMjEiLCJsYWJlbCI6IkFsaWNlIiwicmVjaXBpZW50S2V5cyI6WyI4SEg1Z1lFZU5jM3o3UFlYbWQ1NGQ0eDZxQWZDTnJxUXFFQjNuUzdaZnU3SyJdLCJzZXJ2aWNlRW5kcG9pbnQiOiJodHRwczovL2V4YW1wbGUuY29tL2VuZHBvaW50Iiwicm91dGluZ0tleXMiOlsiOEhINWdZRWVOYzN6N1BZWG1kNTRkNHg2cUFmQ05ycVFxRUIzblM3WmZ1N0siXX0=\n</code></pre> <p>and the resulting signature would be:</p> <pre><code>cwKY4Qhz0IFG9rGqNjcR-6K1NJqgyoGhso28ZGYkOPNI3C8rO6lmjwYstY0Fa2ew8jaFB-jWQN55kOTL5oHVDQ==\n</code></pre> <p>The final output would then produce this:</p> <pre><code>ewogICAgImFsZyI6IkVkRFNBIiwKICAgICJraWQiOiJGWW1vRnc1NUdlUUg3U1JGYTM3ZGt4MWQyZFozelVGOGNrZzd3bUw3b2ZONCIKfQ==.eyJAdHlwZSI6ImRpZDpzb3Y6QnpDYnNOWWhNcmpIaXFaRFRVQVNIZztzcGVjL2Nvbm5lY3Rpb25zLzEuMC9pbnZpdGF0aW9uIiwiQGlkIjoiMTIzNDU2Nzg5MDA5ODc2NTQzMjEiLCJsYWJlbCI6IkFsaWNlIiwicmVjaXBpZW50S2V5cyI6WyI4SEg1Z1lFZU5jM3o3UFlYbWQ1NGQ0eDZxQWZDTnJxUXFFQjNuUzdaZnU3SyJdLCJzZXJ2aWNlRW5kcG9pbnQiOiJodHRwczovL2V4YW1wbGUuY29tL2VuZHBvaW50Iiwicm91dGluZ0tleXMiOlsiOEhINWdZRWVOYzN6N1BZWG1kNTRkNHg2cUFmQ05ycVFxRUIzblM3WmZ1N0siXX0=.cwKY4Qhz0IFG9rGqNjcR-6K1NJqgyoGhso28ZGYkOPNI3C8rO6lmjwYstY0Fa2ew8jaFB-jWQN55kOTL5oHVDQ==\n</code></pre>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#basic-message-protocol-example","title":"Basic Message protocol example","text":""},{"location":"features/0066-non-repudiable-cryptographic-envelope/#sign-and-encrypt-process","title":"Sign and encrypt process","text":"<p>Next is an example that showcases what a basic message would look like. Since this message would utilize a connection to encrypt the message, we will produce a JWS first, and then encrypt the outputted compact JWS.</p> <p>We would first encode our JOSE Header which looks like this:</p> <pre><code>{\n    \"alg\": \"edDSA\",\n    \"kid\": \"7XVZJUuKtfYeN1W4Dq2Tw2ameG6gC1amxL7xZSsZxQCK\"\n}\n</code></pre> <p>and when base64url encoded it would be converted to this:</p> <pre><code>eyJhbGciOiAiZWREU0EiLCAia2lkIjogIjdYVlpKVXVLdGZZZU4xVzREcTJUdzJhbWVHNmdDMWFteEw3eFpTc1p4UUNLIn0=\n</code></pre> <p>Next we'll take our content layer message which as an example is the JSON provided:</p> <pre><code>{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/basicmessage/1.0/message\",\n    \"~l10n\": { \"locale\": \"en\" },\n    \"sent_time\": \"2019-01-15 18:42:01Z\",\n    \"content\": \"Your hovercraft is full of eels.\"\n}\n</code></pre> <p>and now we'll base64url encode this message which results in this output:</p> <pre><code>eyJjb250ZW50IjogIllvdXIgaG92ZXJjcmFmdCBpcyBmdWxsIG9mIGVlbHMuIiwgInNlbnRfdGltZSI6ICIyMDE5LTAxLTE1IDE4OjQyOjAxWiIsICJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9iYXNpY21lc3NhZ2UvMS4wL21lc3NhZ2UiLCAiQGlkIjogIjEyMzQ1Njc4MCIsICJ-bDEwbiI6IHsibG9jYWxlIjogImVuIn19\n</code></pre> <p>Next, they should be concatenated using a period (.) as a delimiter character which would produce this output:</p> <pre><code>eyJhbGciOiAiZWREU0EiLCAia2lkIjogIjdYVlpKVXVLdGZZZU4xVzREcTJUdzJhbWVHNmdDMWFteEw3eFpTc1p4UUNLIn0=.eyJjb250ZW50IjogIllvdXIgaG92ZXJjcmFmdCBpcyBmdWxsIG9mIGVlbHMuIiwgInNlbnRfdGltZSI6ICIyMDE5LTAxLTE1IDE4OjQyOjAxWiIsICJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9iYXNpY21lc3NhZ2UvMS4wL21lc3NhZ2UiLCAiQGlkIjogIjEyMzQ1Njc4MCIsICJ-bDEwbiI6IHsibG9jYWxlIjogImVuIn19\n</code></pre> <p>The signature for the signature data is:</p> <pre><code>FV7Yyz7i31EKoqS_cycQRr2pN59Q5Ojoxnr7uf6yZBqylnUZW2jCk_LesgWy5ZEux2K6dkrZh7q9pUs9dEsJBQ==\n</code></pre> <p>The signature should be concatenated to the signed data above resulting in this final string:</p> <pre><code>eyJhbGciOiAiZWREU0EiLCAia2lkIjogIjdYVlpKVXVLdGZZZU4xVzREcTJUdzJhbWVHNmdDMWFteEw3eFpTc1p4UUNLIn0=.eyJjb250ZW50IjogIllvdXIgaG92ZXJjcmFmdCBpcyBmdWxsIG9mIGVlbHMuIiwgInNlbnRfdGltZSI6ICIyMDE5LTAxLTE1IDE4OjQyOjAxWiIsICJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9iYXNpY21lc3NhZ2UvMS4wL21lc3NhZ2UiLCAiQGlkIjogIjEyMzQ1Njc4MCIsICJ-bDEwbiI6IHsibG9jYWxlIjogImVuIn19.FV7Yyz7i31EKoqS_cycQRr2pN59Q5Ojoxnr7uf6yZBqylnUZW2jCk_LesgWy5ZEux2K6dkrZh7q9pUs9dEsJBQ==\n</code></pre> <p>The last step is to encrypt this base64URL encoded string as the message in pack which will complete the cryptographic envelope.</p> <p>The output of this message then becomes:</p> <pre><code>{\"protected\":\"eyJlbmMiOiJ4Y2hhY2hhMjBwb2x5MTMwNV9pZXRmIiwidHlwIjoiSldNLzEuMCIsImFsZyI6IkF1dGhjcnlwdCIsInJlY2lwaWVudHMiOlt7ImVuY3J5cHRlZF9rZXkiOiJac2dYVWdNVGowUk9lbFBTT09lRGxtaE9sbngwMkVVYjZCbml4QjBESGtEZFRLaGc3ZlE1Tk1zcjU3bzA5WDZxIiwiaGVhZGVyIjp7ImtpZCI6IjRXenZOWjJjQUt6TXM4Nmo2S1c5WGZjMmhLdTNoaFd4V1RydkRNbWFSTEFiIiwiaXYiOiJsOWJHVnlyUnRseUNMX244UmNEakJVb1I3eU5sdEZqMCIsInNlbmRlciI6Imh4alZMRWpXcmY0RFplUGFsRGJnYzVfNmFMN2ltOGs1WElQWnBqTURlUzZaUS1jcEFUaGNzNVdiT25uaVFBM2Z0ZnlYWDJkVUc0dVZ3WHhOTHdMTXRqV3lxNkNKeDdUWEdBQW9ZY0RMMW1aaTJxd2xZMGlDQ2N0dHdNVT0ifX1dfQ==\",\"iv\":\"puCgKCfsOb5gRG81\",\"ciphertext\":\"EpHaC0ZMXQakM4n8Fxbedq_3UhiJHq6vd_I4NNz3N7aDbq7-0F6OXi--VaR7xoTqAyJjrOTYmy1SqivSkGmKaCcpFwC9Shdo_vcMFzIxu90_m3MG1xKNsvDmQBFnD0qgjPPXxmxTlmmYLSdA3JaHpEx1K9gYgGqv4X5bgWZqzFCoevyOlD5a2bDZBY5Mn__IT1pVzjbMbDeSgM2nOztWyF0baXwrqczBW-Msx-uP5HNlLdz02FPbMnRP6MYyw6q0wI0EqwzzwH81bZzHKrTVHT2-M_aIEQp9lKGLhnSW3-aIOpSzonGOriyDukfTpvsCUZEd_X1u0G3iZKxYCbIKaj_ARLbb6idlRngVGW9LYYaw7Xay83exp22gflvLmmN25Xzo1vLlaDaFr9h-J_QAvFebCHgWjl1kcodBRc2jhoMVSpEXJHoI5qMrlVvh45PLTEjxy7y5FHQ1L8klwWZN5EIwui3ExIOA8RwYDlp8-HLib_uqB7hNzVUYC0iPd1KTiNIcidYVdAoPpdtLDOh-KCmPB9RkjVUqSlwNYUAAnfY8OJXuBLHP2nWiYUDA6VDbvrv4npW88VMdsFDk_QzvDRvg7gkW8x8jNd8=\",\"tag\":\"B4UilbBNSUr3QcALtVxTEw==\"}\n</code></pre>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#decrypt-and-verify-process","title":"Decrypt and Verify process","text":"<p>To Decrypt and verify the JWS first unpack the message, which provides this result:</p> <pre><code>{\n    \"message\":\"eyJhbGciOiAiZWREU0EiLCAia2lkIjogIjdYVlpKVXVLdGZZZU4xVzREcTJUdzJhbWVHNmdDMWFteEw3eFpTc1p4UUNLIn0=.eyJjb250ZW50IjogIllvdXIgaG92ZXJjcmFmdCBpcyBmdWxsIG9mIGVlbHMuIiwgInNlbnRfdGltZSI6ICIyMDE5LTAxLTE1IDE4OjQyOjAxWiIsICJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9iYXNpY21lc3NhZ2UvMS4wL21lc3NhZ2UiLCAiQGlkIjogIjEyMzQ1Njc4MCIsICJ-bDEwbiI6IHsibG9jYWxlIjogImVuIn19.FV7Yyz7i31EKoqS_cycQRr2pN59Q5Ojoxnr7uf6yZBqylnUZW2jCk_LesgWy5ZEux2K6dkrZh7q9pUs9dEsJBQ==\",\n    \"recipient_verkey\":\"4WzvNZ2cAKzMs86j6KW9Xfc2hKu3hhWxWTrvDMmaRLAb\",\n    \"sender_verkey\":\"7XVZJUuKtfYeN1W4Dq2Tw2ameG6gC1amxL7xZSsZxQCK\"\n}\n</code></pre> <p>Parse the <code>message</code> field splitting on the second period <code>.</code> You should then have this as the payload:</p> <pre><code>eyJhbGciOiAiZWREU0EiLCAia2lkIjogIjdYVlpKVXVLdGZZZU4xVzREcTJUdzJhbWVHNmdDMWFteEw3eFpTc1p4UUNLIn0=.eyJjb250ZW50IjogIllvdXIgaG92ZXJjcmFmdCBpcyBmdWxsIG9mIGVlbHMuIiwgInNlbnRfdGltZSI6ICIyMDE5LTAxLTE1IDE4OjQyOjAxWiIsICJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9iYXNpY21lc3NhZ2UvMS4wL21lc3NhZ2UiLCAiQGlkIjogIjEyMzQ1Njc4MCIsICJ-bDEwbiI6IHsibG9jYWxlIjogImVuIn19\n</code></pre> <p>and the signature will be base64URL encoded and look like this:</p> <pre><code>FV7Yyz7i31EKoqS_cycQRr2pN59Q5Ojoxnr7uf6yZBqylnUZW2jCk_LesgWy5ZEux2K6dkrZh7q9pUs9dEsJBQ==\n</code></pre> <p>Now decode the signature and then convert the signature  and payload to bytes and use <code>crypto.crypto_verify()</code> API in IndySDK</p> <p>Your message has now been verified.</p> <p>To get the original message, you'll again parse the JWS this time taking the second section only which looks like this:</p> <pre><code>eyJjb250ZW50IjogIllvdXIgaG92ZXJjcmFmdCBpcyBmdWxsIG9mIGVlbHMuIiwgInNlbnRfdGltZSI6ICIyMDE5LTAxLTE1IDE4OjQyOjAxWiIsICJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9iYXNpY21lc3NhZ2UvMS4wL21lc3NhZ2UiLCAiQGlkIjogIjEyMzQ1Njc4MCIsICJ-bDEwbiI6IHsibG9jYWxlIjogImVuIn19\n</code></pre> <p>Now Base64URL decode that section and you'll get the original message:</p> <pre><code>{\n    \"content\": \"Your hovercraft is full of eels.\",\n    \"sent_time\": \"2019-01-15 18:42:01Z\",\n    \"@type\": \"https://didcomm.org/basicmessage/1.0/message\",\n    \"@id\": \"123456780\",\n    \"~l10n\": {\"locale\": \"en\"}\n}\n</code></pre>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#modifications-to-packunpack-api","title":"Modifications to pack()/unpack() API","text":"<ul> <li>Things to consider:<ul> <li>Combining this all into the pack/unpack API would require two additional APIs. One to handle signing, and one to indicate a message isn't encrypted.</li> <li>I like the idea of combining the API. However, I'm not a fan of the idea of incorporating a plaintext message into pack to support the connect protocol.</li> <li>My preference would be to create a seperate API specifically for the connect protocol given that it's an edge case.</li> <li>How would this affect the ephemeral challenge protocol as well as the \"spectrum of trust\" which was highlight by One of Daniel Hardman's previous posts?</li> </ul> </li> </ul>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#drawbacks","title":"Drawbacks","text":"<p>Through the choice of a JWS formatted structure we imply that an off the shelf library will support this structure. However, it's uncommon for libraries to support the edDSA signature algorithm even though it's a valid algorithm based on the IANA registry. This means that most implementations that support this will either need to add this signature algorithm to another JWS library or</p>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?<ul> <li>Given the support for ed25519 keys throughout the ecosystem, this seemed like the best fit for initial support. Over time, it may make sense to add additional support for other key types like Secp256k1 or RSA.</li> <li>The rational for supporting JWS is that it contains the bare minimum information to deterministically verify the payload (given JSON doesn't need to be ordered, but a signature must have the same byte order) and self contain the key and algorithm used.</li> <li>The compact serialization was chosen instead of the JSON serialization because it's assumed that senders will not be multi-signing messages at this time.</li> </ul> </li> <li>What other designs have been considered and what is the rationale for not choosing them?<ul> <li>CBOR supports a signature scheme called CBOR Web Signatures, but was not chosen because the DIDComm protocol is largely JSON based.</li> <li>JWTs were not chosen because they are a constrained form of JWS. This allows us to add JWT support if needed in the future, while not limiting ourselves early in the design process.</li> </ul> </li> <li>What is the impact of not doing this?<ul> <li>By not using JWTs we move away from a common dependency that many other SSI ecosystems support already for their credentials. However, many JWT libraries do not support ed25519 which is currently the only key type used.</li> </ul> </li> </ul>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#prior-art","title":"Prior art","text":"<p>The majority of prior art discussions are mentioned above in the rationale and alternatives section. Some prior art that was considered when selecting this system is how closely it aligns with OpenID Connect systems. This has the possibility to converge with Self Issued OpenID Connect systems when running over HTTP, but doesn't specifically constrain to an particular transport mechanism. This is a distinct advantage for backward compatibility.</p>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Was the usage of a JWT a better option for broader SSI adoption and backwards compatibility (e.g. Active directory and OpenID Connect)?</li> <li> </li> </ul>"},{"location":"features/0066-non-repudiable-cryptographic-envelope/#is-limiting-to-only-ed25519-key-types-an-unnecessary-restraint-given-the-broad-support-needed-for-didcomm","title":"Is limiting to only ed25519 key types an unnecessary restraint given the broad support needed for DIDComm?","text":""},{"location":"features/0066-non-repudiable-cryptographic-envelope/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0067-didcomm-diddoc-conventions/","title":"Aries RFC 0067: DIDComm DID document conventions","text":"<ul> <li>Authors: Tobias Looker, Stephen Curran</li> <li>Status: PROPOSED</li> <li>Since: 2019-06-10</li> <li>Status Note: This revises the former INDY HIPE</li> <li>Start Date: 2019-04-15</li> <li>Tags: feature</li> </ul>"},{"location":"features/0067-didcomm-diddoc-conventions/#summary","title":"Summary","text":"<p>Explain the DID document conventions required to enable DID communications.</p>"},{"location":"features/0067-didcomm-diddoc-conventions/#motivation","title":"Motivation","text":"<p>Standardization of these conventions is essential to promoting interoperability of DID communications.</p>"},{"location":"features/0067-didcomm-diddoc-conventions/#tutorial","title":"Tutorial","text":""},{"location":"features/0067-didcomm-diddoc-conventions/#did-documents","title":"DID documents","text":"<p>A DID document is the associated data model to a DID, it contains important associated cryptographic information and a declaration of capabilities the DID supports.</p> <p>Of particular interested to this RFC is the definition of service endpoints. The primary object of this RFC is to document the DID communication service type and describe the associated conventions.</p>"},{"location":"features/0067-didcomm-diddoc-conventions/#service-conventions","title":"Service Conventions","text":"<p>As referenced above within the DID specification lies a section called service endpoints, this section of the DID document is reserved for <code>any type of service the entity wishes to advertise, including decentralized identity management services for further discovery, authentication, authorization, or interaction</code>.</p> <p>When a DID document wishes to express support for DID communications, the following service definition is defined.</p> <pre><code>{\n  \"service\": [{\n    \"id\": \"did:example:123456789abcdefghi#did-communication\",\n    \"type\": \"did-communication\",\n    \"priority\" : 0,\n    \"recipientKeys\" : [ \"did:example:123456789abcdefghi#1\" ],\n    \"routingKeys\" : [ \"did:example:123456789abcdefghi#1\" ],\n    \"accept\": [\n      \"didcomm/aip2;env=rfc587\",\n      \"didcomm/aip2;env=rfc19\"\n    ],\n    \"serviceEndpoint\": \"https://agent.example.com/\"\n  }]\n}\n</code></pre> <ul> <li>id : Required by the Service Endpoints Spec.</li> <li>type : Required by the Service Endpoints Spec. It is mandatory that this field is set to <code>did-communication</code></li> <li>priority : This represents the priority of the service endpoint, used for distinction when multiple <code>did-communication</code> service endpoints are present in a single DID document. It is mandatory that this field is set to an unsigned integer with the default value of <code>0</code>.</li> <li>recipientKeys : This is an array of did key references used to denote the default recipients of an endpoint. (note-1)</li> <li>routingKeys: This is an array of did key references, ordered from most destward to most srcward, used to denote the individual routing hops in between the sender and recipients. See TBC for more information on how routing is intended to operate.</li> <li><code>accept</code> - [optional] an array of media types in the order of preference for sending a message to the endpoint.  If <code>accept</code> is not specified, the sender uses its preferred choice for sending a message to the endpoint.  RFC 0044 provides a general discussion of media types.</li> <li>serviceEndpoint : Required by the Service Endpoints Spec. This URL based endpoint is used to declare how the message should be sent. DID communication is transport agnostic, and therefore leverages existing application level transport protocols. However for each transport defined, which is identified by the URL scheme e.g <code>http</code>, a set of transport specific considerations are defined see transports for more details.</li> </ul> <p>Notes 1. The keys featured in this array must resolve to keys of the same type, for example a mix <code>Ed25519VerificationKey2018</code> or <code>RsaVerificationKey2018</code> in the same array is invalid.</p>"},{"location":"features/0067-didcomm-diddoc-conventions/#message-preparation-conventions","title":"Message Preparation Conventions","text":"<p>Below describes the process under which a DID communication message is prepared and sent to a DID based on the conventions declared in the associated DID document. The scenario in which the below is predicated has the following conditions.     - The sender possesses the DID document for the intended recipient(s) of a DID communication message.     - The sender has created a content level message that is now ready to be prepared for sending to the intended recipient(s).</p> <ol> <li>The sender resolves the relevant <code>did-communication</code> service of the intended recipient(s) DID document.</li> <li>The sender resolves the recipient keys present in the <code>recipientKeys</code> array of the service declaration.</li> <li>Using the resolved keys, the sender takes the content level message and packs it inside an encrypted envelope for the recipient keys. (note-2)</li> <li>The sender then inspects the <code>routingKeys</code> array, if it is found to be empty, then the process skips to step 5. Otherwise, the sender prepares a content level message of type <code>forward</code>. The resolved keys from the <code>recipientKeys</code> array is set as the contents of the <code>to</code> field in the forward message and the encrypted envelope from the previous step is set as the contents of the <code>msg</code> field in the forward message. Following this, for each element in the <code>routingKeys</code> array the following sub-process is repeated:<ol> <li>The sender resolves the current key in the routing array and takes the outputted encrypted envelope from the previous step and packs it inside a new encrypted envelope for the current key.</li> <li>The sender prepares a content level message of type <code>forward</code>. The current key in the routing array is set as the contents of the <code>to</code> field in the forward message and the encrypted envelope from the previous step is set as the contents of the <code>msg</code> field in the forward message.</li> </ol> </li> <li>Resolve the service endpoint:<ul> <li>If the endpoint is a valid DID URL, check that it resolves to another DID service definition. If the resolution is successful the process from step 2. is repeated using the message outputted from this process as the input message.</li> <li>If the service endpoint is not a DID URL, send the message using the transport protocol declared by the URL's scheme.</li> </ul> </li> </ol> <p>Notes 1. There are two main situations that an agent will be in prior to preparing a new message.</p> <ul> <li>The agent is responding to a message that has just been received and has the context of the sender key of the previous message. In this case, a targeted lookup of the <code>did-communication</code> service definition can be done to find the service definition that ../../features the sender key as a recipient key which would ensure that the response was delivered back to the sender.</li> <li>The agent is creating a new message to a connection and will use the default <code>did-communication</code> service definition for preparation of a message. In this case, the default <code>did-communication</code> service definition would be used by resolving the lowest priority service definition from the connections DID document.</li> </ul> <ol> <li>When preparing this envelope the sender has two main choices to make around properties to include in envelope <ul> <li>Whether to include sender information</li> <li>Whether to include a non-reputable signature</li> </ul> </li> </ol>"},{"location":"features/0067-didcomm-diddoc-conventions/#example-domain-and-did-document","title":"Example: Domain and DID document","text":"<p>The following is an example of an arbitrary pair of domains that will be helpful in providing context to conventions defined above.</p> <p></p> <p>In the diagram above:</p> <ul> <li>Alice has</li> <li>1 Edge Agent - \"1\"</li> <li>1 Cloud Agent - \"2\"</li> <li>1 Domain Endpoint - \"8\"</li> <li>Bob has</li> <li>2 Edge Agents - \"4\", \"5\"</li> <li>2 Cloud Agents - \"3\", \"6\"</li> <li>1 Domain Endpoint - \"9\"</li> </ul>"},{"location":"features/0067-didcomm-diddoc-conventions/#bobs-did-document-for-his-relationship-with-alice","title":"Bob's DID document for his Relationship with Alice","text":"<p>Bob\u2019s domain has 3 devices he uses for processing messages - two phones (4 and 5) and a cloud-based agent (6). As well, Bob has one agent that he uses as a mediator (3) that can hold messages for the two phones when they are offline. However, in Bob's relationship with Alice, he ONLY uses one phone (4) and the cloud-based agent (6). Thus the key for device 5 is left out of the DID document (see below). For further privacy preservation, Bob also elects to use a shared domain endpoint (agents-r-us), giving him an extra layer of isolation from correlation. This is represented by the <code>serviceEndpoint</code> in the service definition not directly resolving to an endpoint URI rather resolving to another <code>did-communication</code> service definition which is owned and controlled by the endpoint owner (agents-r-us).</p> <p>Bobs DID document given to Alice</p> <pre><code>{\n  \"@context\": \"https://w3id.org/did/v1\",\n  \"id\": \"did:example:1234abcd\",\n  \"publicKey\": [\n    {\"id\": \"3\", \"type\": \"RsaVerificationKey2018\",  \"controller\": \"did:example:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC X\u2026\"},\n    {\"id\": \"4\", \"type\": \"RsaVerificationKey2018\",  \"controller\": \"did:example:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC 9\u2026\"},\n    {\"id\": \"6\", \"type\": \"RsaVerificationKey2018\",  \"controller\": \"did:example:1234abcd\",\"publicKeyPem\": \"-----BEGIN PUBLIC A\u2026\"}\n  ],\n  \"authentication\": [\n    {\"type\": \"RsaSignatureAuthentication2018\", \"publicKey\": \"did:example:1234abcd#4\"}\n  ],\n  \"service\": [\n    {\n      \"id\": \"did:example:123456789abcdefghi;did-communication\",\n      \"type\": \"did-communication\",\n      \"priority\" : 0,\n      \"recipientKeys\" : [ \"did:example:1234abcd#4\" ],\n      \"routingKeys\" : [ \"did:example:1234abcd#3\" ],\n      \"serviceEndpoint\" : \"did:example:xd45fr567794lrzti67;did-communication\"\n    }\n  ]\n}\n</code></pre> <p>Agents r Us DID document - resolvable by Alice</p> <pre><code>{\n  \"@context\": \"https://w3id.org/did/v1\",\n  \"id\": \"did:example:xd45fr567794lrzti67\",\n  \"publicKey\": [\n    {\"id\": \"1\", \"type\": \"RsaVerificationKey2018\",  \"controller\": \"did:example:xd45fr567794lrzti67\",\"publicKeyPem\": \"-----BEGIN PUBLIC X\u2026\"},\n  ],\n  \"authentication\": [\n    {\"type\": \"RsaSignatureAuthentication2018\", \"publicKey\": \"did:example:xd45fr567794lrzti67#1\"}\n  ],\n  \"service\": [\n    {\n      \"id\": \"did:example:xd45fr567794lrzti67;did-communication\",\n      \"type\": \"did-communication\",\n      \"priority\" : 0,\n      \"recipientKeys\" : [ \"did:example:xd45fr567794lrzti67#1\" ],\n      \"routingKeys\" : [ ],\n      \"serviceEndpoint\" : \"http://agents-r-us.com\"\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0067-didcomm-diddoc-conventions/#message-preparation-example","title":"Message Preparation Example","text":"<p>Alices agent goes to prepare a message <code>desired_msg</code> for Bob.</p> <ol> <li>Alices agent resolves the above DID document <code>did:example:1234abcd</code> for Bob and resolves the <code>did-communication</code> service definition.</li> <li>Alices agent then packs <code>desired_msg</code> in an encrypted envelope message to the resolved keys defined in the <code>recipientKeys</code> array.</li> <li>Because the <code>routingKeys</code> array is not empty, a content level message of type <code>forward</code> is prepared where the <code>to</code> field of the forward message is set to the resolved keys and the <code>msg</code> field of the forward message is set to the encrypted envelope from the previous step.</li> <li>The resulting forward message from the previous step is then packed inside another encrypted envelope for the first and only key in the <code>routingKeys</code> array.</li> <li>Inspection of the service endpoint, reveals it is a did url and leads to resolving another <code>did-communication</code> service definition, this time owned and controlled by <code>agents-r-us</code>.</li> <li>Because in the <code>agents-r-us</code> service definition there is a recipient key. A content level message of type <code>forward</code> is prepared where the <code>to</code> field of the forward message is set to the recipient key and the <code>msg</code> field of the forward message is set to the encrypted envelope from the previous step.</li> <li>This content message is then packed in a encrypted envelope for the recipient key in <code>agents-r-us</code> service definition.</li> <li>Finally as the endpoint listed in the serviceEndpoint field for the <code>agents-r-us</code> <code>did-communication</code> service definition is a valid endpoint URL, the message is transmitted in accordance with the URL's protocol.</li> </ol>"},{"location":"features/0067-didcomm-diddoc-conventions/#reference","title":"Reference","text":""},{"location":"features/0067-didcomm-diddoc-conventions/#rationale-and-alternatives","title":"Rationale and alternatives","text":""},{"location":"features/0067-didcomm-diddoc-conventions/#prior-art","title":"Prior art","text":"<ul> <li>DID Communication Message Anatomy</li> <li>DID Communication Encryption Envelope</li> </ul>"},{"location":"features/0067-didcomm-diddoc-conventions/#unresolved-questions","title":"Unresolved questions","text":"<p>The following remain unresolved:</p> <ul> <li>The convention for packing the message for the required routes is dependent on the array order of key references, which could be viewed as a weak/brittle convention.</li> </ul>"},{"location":"features/0067-didcomm-diddoc-conventions/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0075-payment-decorators/","title":"Aries RFC 0075: Payment Decorators","text":"<ul> <li>Authors: Sam Curren, Daniel Hardman, Tomislav Markovski</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes: Indy HIPE PR #129</li> <li>Start Date: 2019-04-22</li> <li>Tags: feature, decorator</li> </ul>"},{"location":"features/0075-payment-decorators/#summary","title":"Summary","text":"<p>Defines the <code>~payment_request</code>, <code>payment_internal_response</code>, and <code>~payment_receipt</code> decorators. These offer standard payment ../../features in all DIDComm interactions, and let DIDComm take advantage of the W3C's Payment Request API in an interoperable way.</p>"},{"location":"features/0075-payment-decorators/#motivation","title":"Motivation","text":"<p>Instead of inventing custom messages for payments in each protocol, arbitrary messages can express payment semantics with payment decorators. Individual protocol specs should clarify on which messages and under which conditions the decorators are used.</p>"},{"location":"features/0075-payment-decorators/#tutorial","title":"Tutorial","text":"<p>The W3C's Payment Request API governs interactions between three parties:</p> <ol> <li>payer</li> <li>payee</li> <li>payment method</li> </ol> <p>The payer is usually imagined to be a person operating a web browser, the payee is imagined to be an online store, and the payment method might be something like a credit card processing service. The payee emits a PaymentRequest JSON structure (step 1 below); this causes the payee to be prompted (step 2, \"Render\"). The payer decides whether to pay, and if so, which payment method and options she prefers (step 3, \"Configure\"). The payer's choices are embodied in a PaymentResponse JSON structure (step 4). This is then used to select the appropriate codepath and inputs to invoke the desired payment method (step 5).</p> <p></p> <p>Notice that this flow does not include anything coming back to the payer. In this API, the PaymentResponse structure embodies a response from the payer to the payer's own agent, expressing choices about which credit card to use and which shipping options are desired; it's not a response that crosses identity boundaries. That's reasonable because this is the Payment Request API, not a Payment Roundtrip API. It's only about requesting payments, not completing payments or reporting results. Also, each payment method will have unique APIs for fulfillment and receipts; the W3C Payment Request spec does not attempt to harmonize them, though some work in that direction is underway in the separate Payment Handler API spec.</p> <p>In DIDComm, the normal emphasis is on interactions between parties with different identities. This makes PaymentResponse and the communication that elicits it (steps 2-4) a bit unusual from a DIDComm perspective; normally DIDComm would use the word \"response\" for something that comes back from Bob, after Alice asks Bob a question. It also makes the scope of the W3C API feel incomplete, because we'd like to be able to model the entire flow, not just part of it.</p> <p>The DIDComm payment decorators map to the W3C API as follows:</p> <ul> <li>DIDComm's <code>payment_request</code> decorator is exactly equivalent to the JSON representation of PaymentRequest in the W3C API, including all internal fields and semantics, and the use of camelCase.</li> <li>DIDComm's <code>payment_internal_response</code> decorator is exactly equivalent to the JSON representation of PaymentResponse in the W3C API. However, we never expect it to appear on messages that cross a sovereign domain boundary. It is only relevant if Alice has two agents that want to confer about Alice's choices in responding to a <code>payment_request</code>, and is thus not relevant to interoperability. However, it is defined so internal conversations about Alice's choices may leverage a standard mechanism, if they like.</li> <li>DIDComm's <code>payment_receipt</code> decorator has no analog in the W3C spec, because it encapsulates proof from payer to payee, that payment has actually taken place.</li> <li>Neither DIDComm nor the W3C spec define messages for the interaction between payer and payment method handler. Rather, both allow this communication to be proprietary. At a future date, perhaps standardization will happen here.</li> </ul>"},{"location":"features/0075-payment-decorators/#reference","title":"Reference","text":""},{"location":"features/0075-payment-decorators/#payment_request","title":"<code>~payment_request</code>","text":"<p>Please see the PaymentRequest interface docs in the W3C spec for a full reference, or Section 2, Examples of Usage in the W3C spec for a narration that builds a PaymentRequest from first principles.</p> <p>The following is a sample <code>~payment_request</code> decorator with some interesting details to suggest what's possible:</p> <pre><code>{\n  \"~payment_request\": {\n    \"methodData\": [\n      {\n        \"supportedMethods\": \"basic-card\",\n        \"data\": {\n          \"supportedNetworks\": [\"visa\", \"mastercard\"],\n          \"payeeId\": \"12345\"\n        },\n      },\n      {\n        \"supportedMethods\": \"sovrin\",\n        \"data\": {\n          \"supportedNetworks\": [\"sov\", \"sov:test\", \"ibm-indy\"],\n          \"payeeId\": \"XXXX\"\n        },\n      }\n    ],\n    \"details\": {\n      \"id\": \"super-store-order-123-12312\",\n      \"displayItems\": [\n        {\n          \"label\": \"Sub-total\",\n          \"amount\": { \"currency\": \"USD\", \"value\": \"55.00\" },\n        },\n        {\n          \"label\": \"Sales Tax\",\n          \"amount\": { \"currency\": \"USD\", \"value\": \"5.00\" },\n          \"type\": \"tax\"\n        },\n      ],\n      \"total\": {\n        \"label\": \"Total due\",\n        // The total is USD$65.00 here because we need to\n        // add shipping (below). The selected shipping\n        // costs USD$5.00.\n        \"amount\": { \"currency\": \"USD\", \"value\": \"65.00\" }\n      },\n      \"shippingOptions\": [\n        {\n          \"id\": \"standard\",\n          \"label\": \"Ground Shipping (2 days)\",\n          \"amount\": { \"currency\": \"USD\", \"value\": \"5.00\" },\n          \"selected\": true,\n        },\n        {\n          \"id\": \"drone\",\n          \"label\": \"Drone Express (2 hours)\",\n          \"amount\": { \"currency\": \"USD\", \"value\": \"25.00\" }\n        }\n      ],\n      \"modifiers\": [\n        {\n          \"additionalDisplayItems\": [{\n            \"label\": \"Card processing fee\",\n            \"amount\": { \"currency\": \"USD\", \"value\": \"3.00\" },\n          }],\n          \"supportedMethods\": \"basic-card\",\n          \"total\": {\n            \"label\": \"Total due\",\n            \"amount\": { \"currency\": \"USD\", \"value\": \"68.00\" },\n          },\n          \"data\": {\n            \"supportedNetworks\": [\"visa\"],\n          },\n        },\n        {\n          \"supportedMethods\": \"sovrin\",\n          \"total\": {\n            \"label\": \"Total due\",\n            \"amount\": { \"currency\": \"SOV\", \"value\": \"2254\" },\n          },\n        },\n      ]\n    },\n    \"options\": {\n      \"requestPayerEmail\": false,\n      \"requestPayerName\": true,\n      \"requestPayerPhone\": false,\n      \"requestShipping\": true\n    }\n  }\n}\n</code></pre> <p>The <code>details.id</code> field contains an invoice number, shopping cart ID, or similar identifier that unambiguously identifies the goods and services for which payment is requested. The <code>payeeId</code> field would contain a payment address for cryptocurrency payment methods, or a merchant ID for credit cards. The <code>modifiers</code> section shows how the requested payment amount should be modified if the <code>basic-card</code> method is selected. That specific example is discussed in greater detail in the W3C spec. It also shows how the currency could be changed if a token-based method is selected instead of a fiat-based method. See the separate W3C spec on Payment Method IDs.</p> <p>Note that standard DIDComm localization can be used to provide localized alternatives to the <code>label</code> fields; this is a DIDComm-specific extension.</p> <p>This example shows <code>options</code> where the payee is requesting self-attested data from the payer. DIDComm offers the option of replacing this simple approach with a sophisticated presentation request based on verifiable credentials. The simple approach is fine where self-attested data is enough; the VC approach is useful when assurance of the data must be higher (e.g., a verified email address), or where fancy logic about what's required (Name plus either Email or Phone) is needed.</p> <p>The DIDComm <code>payment_request</code> decorator may be combined with the <code>~timing.expires_time</code> decorator to express the idea that the payment must be made within a certain time period or else the price or availability of merchandise is not guaranteed.</p>"},{"location":"features/0075-payment-decorators/#payment_internal_response","title":"<code>~payment_internal_response</code>","text":"<p>This decorator exactly matches PaymentResponse from the W3C API and will not be further described here. A useful example of a response is given in the related Basic Card Response doc.</p>"},{"location":"features/0075-payment-decorators/#payment_receipt","title":"<code>~payment_receipt</code>","text":"<p>This decorator on a message indicates that a payment has been made. It looks like this (note the snake_case since we are not matching a W3C spec):</p> <pre><code>{\n  \"~payment_receipt\": {\n      \"request_id\": \"super-store-order-123-12312\",\n      \"selected_method\": \"sovrin\",\n      \"selected_shippingOption\": \"standard\",\n      \"transaction_id\": \"abc123\",\n      \"proof\": \"directly verifiable proof of payment\",\n      \"payeeId\": \"XXXX\",\n      \"amount\": { \"currency\": \"SOV\", \"value\": \"2254\" }\n  }\n}\n</code></pre> <p>request_id: This contains the <code>details.id</code> of <code>~payment_request</code> that this payment receipt satisfies.</p> <p>selected_method: Which payment method was chosen to pay.</p> <p>selected_shippingOption: Which shipping option was chosen.</p> <p>transaction_id: A transaction identifier that can be checked by the payee to verify that funds were transferred, and that the transfer relates to this payment request instead of another. This might be a ledger's transaction ID, for example.</p> <p>proof: Optional. A base64url-encoded blob that contains directly verifiable proof that the transaction took place. This might be useful for payments enacted by a triple-signed receipt mechanism, for example. When this is present, <code>transaction_id</code> becomes optional. For ledgers that support state proofs, the state proof could be offered here.</p>"},{"location":"features/0075-payment-decorators/#example","title":"Example","text":"<p>Here is a rough description of how these decorators might be used in a protocol to issue credentials. We are not guaranteeing that the message details will remain up-to-date as that protocol evolves; this is only for purposes of general illustration.</p>"},{"location":"features/0075-payment-decorators/#credential-offer","title":"Credential Offer","text":"<p>This message is sent by the issuer; it indicates that payment is requested for the credential under discussion.</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue_credential/1.0/offer_credential\",\n    \"@id\": \"5bc1989d-f5c1-4eb1-89dd-21fd47093d96\",\n    \"cred_def_id\": \"KTwaKJkvyjKKf55uc6U8ZB:3:CL:59:tag1\",\n    \"~payment_request\": {\n        \"methodData\": [\n          {\n            \"supportedMethods\": \"ETH\",\n            \"data\": {\n              \"payeeId\": \"0xD15239C7e7dDd46575DaD9134a1bae81068AB2A4\"\n            },\n          }\n        ],\n        \"details\": {\n          \"id\": \"0a2bc4a6-1f45-4ff0-a046-703c71ab845d\",\n          \"displayItems\": [\n            {\n              \"label\": \"commercial driver's license\",\n              \"amount\": { \"currency\": \"ETH\", \"value\": \"0.0023\" },\n            }\n          ],\n          \"total\": {\n            \"label\": \"Total due\",\n            \"amount\": { \"currency\": \"ETH\", \"value\": \"0.0023\" }\n          }\n        }\n      },\n    \"credential_preview\": &lt;json-ld object&gt;,\n    ///...\n}\n</code></pre>"},{"location":"features/0075-payment-decorators/#example-credential-request","title":"Example Credential Request","text":"<p>This Credential Request is sent to the issuer, indicating that they have paid the requested amount.</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue_credential/1.0/request_credential\",\n    \"@id\": \"94af9be9-5248-4a65-ad14-3e7a6c3489b6\",\n    \"~thread\": { \"thid\": \"5bc1989d-f5c1-4eb1-89dd-21fd47093d96\" },\n    \"cred_def_id\": \"KTwaKJkvyjKKf55uc6U8ZB:3:CL:59:tag1\",\n    \"~payment_receipt\": {\n      \"request_id\": \"0a2bc4a6-1f45-4ff0-a046-703c71ab845d\",\n      \"selected_method\": \"ETH\",\n      \"transaction_id\": \"0x5674bfea99c480e110ea61c3e52783506e2c467f108b3068d642712aca4ea479\",\n      \"payeeId\": \"0xD15239C7e7dDd46575DaD9134a1bae81068AB2A4\",\n      \"amount\": { \"currency\": \"ETH\", \"value\": \"0.0023\" }\n    }\n\n    ///...\n}\n</code></pre>"},{"location":"features/0075-payment-decorators/#drawbacks","title":"Drawbacks","text":"<p>TBD</p>"},{"location":"features/0075-payment-decorators/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>We could allow each message family to indicate payment information independently. This would be very flexible, but tedious and very messy.</li> <li>We could not include payment information in messages, but that would limit useful applications.</li> </ul>"},{"location":"features/0075-payment-decorators/#prior-art","title":"Prior art","text":"<ul> <li>Indy HIPE PR #129 contains an earlier version of this thinking.</li> </ul>"},{"location":"features/0075-payment-decorators/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What about a receipt that covers multiple invoices?</li> <li>The W3C spec allows almost free variation in the fields used to communicate to specific payment methods. Do we want to standardize? Do we need to link to specific payment method definitions? Do we need to define our new payment methods (e.g., cryptocurrency-based) to be aligned with existing ones?</li> </ul>"},{"location":"features/0075-payment-decorators/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0092-transport-return-route/","title":"Aries RFC 0092: Transports Return Route","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note:  </li> <li>Supersedes: INDY HIPE PR 116</li> <li>Start Date: 2019-03-04</li> <li>Tags: feature</li> </ul>"},{"location":"features/0092-transport-return-route/#summary","title":"Summary","text":"<p>Agents can indicate that an inbound message transmission may also be used as a return route for messages. This allows for transports of increased efficiency as well as agents without an inbound route.</p>"},{"location":"features/0092-transport-return-route/#motivation","title":"Motivation","text":"<p>Inbound HTTP and Websockets are used only for receiving messages by default. Return messages are sent using their own outbound connections. Including a decorator allows the receiving agent to know that using the inbound connection as a return route is acceptable. This allows two way communication with agents that may not have an inbound route available. Agents without an inbound route include mobile agents, and agents that use a client (and not a server) for communication.</p> <p>This decorator is intended to facilitate message communication between a client based agent (an agent that can only operate as a client, not a server) and the server based agents they communicate directly with. Use on messages that will be forwarded is not allowed.</p>"},{"location":"features/0092-transport-return-route/#tutorial","title":"Tutorial","text":"<p>When you send a message through a connection, you can use the <code>~transport</code> decorator on the message and specify <code>return_route</code>. The value of <code>return_route</code> is discussed in the Reference section of this document.</p> <pre><code>{\n    \"~transport\": {\n        \"return_route\": \"all\"\n    }\n}\n</code></pre>"},{"location":"features/0092-transport-return-route/#reference","title":"Reference","text":"<ul> <li> <p><code>return_route</code> has the following acceptable values:</p> </li> <li> <p><code>none</code>: Default. No messages should be returned over this connection.</p> </li> <li><code>all</code>: Send all messages for this cryptographic key over the connection.</li> <li><code>thread</code>: Send all messages matching the cryptographic key and thread specified in the <code>return_route_thread</code> attribute.</li> </ul> <p>The <code>~transport</code> decorator should be processed after unpacking and prior to routing the message to a message handler.</p> <p>For HTTP transports, the presence of this message decorator indicates that the receiving agent MAY hold onto the connection and use it to return messages as designated. HTTP transports will only be able to receive at most one message at a time. Websocket transports are capable of receiving multiple messages.</p> <p>Compliance with this indicator is optional for agents generally, but required for agents wishing to connect with client based agents.</p>"},{"location":"features/0092-transport-return-route/#drawbacks","title":"Drawbacks","text":"<ul> <li>Application varies between transports, adding complexity to agent development.</li> </ul>"},{"location":"features/0092-transport-return-route/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Using a transport level decorator makes this behavior transport agnostic.</li> </ul>"},{"location":"features/0092-transport-return-route/#prior-art","title":"Prior art","text":"<p>The Decorators RFC describes scope of decorators. Transport isn't one of the scopes listed.</p>"},{"location":"features/0092-transport-return-route/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python Contributed by the government of British Columbia. Aries Protocol Test Suite Used in Tests"},{"location":"features/0095-basic-message/","title":"Aries RFC 0095: Basic Message Protocol 1.0","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: ADOPTED</li> <li>Since: 2019-08-06</li> <li>Status Note:  </li> <li>Supersedes: Indy 0033</li> <li>Start Date: 2019-01-16</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"features/0095-basic-message/#summary","title":"Summary","text":"<p>The BasicMessage protocol describes a stateless, easy to support user message protocol. It has a single message type used to communicate.</p>"},{"location":"features/0095-basic-message/#motivation","title":"Motivation","text":"<p>It is a useful feature to be able to communicate human written messages. BasicMessage is the most basic form of this written message communication, explicitly excluding advanced ../../features to make implementation easier.</p>"},{"location":"features/0095-basic-message/#tutorial","title":"Tutorial","text":""},{"location":"features/0095-basic-message/#roles","title":"Roles","text":"<p>There are two roles in this protocol: sender and receiver. It is anticipated that both roles are supported by agents that provide an interface for humans, but it is possible for an agent to only act as a sender (do not process received messages) or a receiver (will never send messages).</p>"},{"location":"features/0095-basic-message/#states","title":"States","text":"<p>There are not really states in this protocol, as sending a message leaves both parties in the same state they were before.</p>"},{"location":"features/0095-basic-message/#out-of-scope","title":"Out of Scope","text":"<p>There are many useful ../../features of user messaging systems that we will not be adding to this protocol. We anticipate the development of more advanced and full-featured message protocols to fill these needs. Features that are considered out of scope for this protocol include:</p> <ul> <li>read receipts</li> <li>emojii responses</li> <li>typing indicators</li> <li>message replies (threading)</li> <li>multi-party (group) messages</li> <li>attachments</li> </ul>"},{"location":"features/0095-basic-message/#reference","title":"Reference","text":"<p>Protocol: https://didcomm.org/basicmessage/1.0/</p> <p>message</p> <ul> <li>sent_time - timestamp in ISO 8601 UTC</li> <li>content - content of the user intended message as a string.</li> <li>The <code>~l10n</code> block SHOULD be used, but only the <code>locale</code> presented.</li> </ul> <p>Example:</p> <pre><code>{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/basicmessage/1.0/message\",\n    \"~l10n\": { \"locale\": \"en\" },\n    \"sent_time\": \"2019-01-15 18:42:01Z\",\n    \"content\": \"Your hovercraft is full of eels.\"\n}\n</code></pre>"},{"location":"features/0095-basic-message/#drawbacks","title":"Drawbacks","text":"<ul> <li>Creating this basicmessage may inhibit the creation of more advanced user messaging protocols.</li> <li>After more advanced user messaging protocols are created, the need to support this protocol may be annoying.</li> </ul>"},{"location":"features/0095-basic-message/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Basic user messaging creates an easy useful feature in the early days of agent messaging.</li> <li>Even in the presence of better protocols, it can still be useful for basic devices or service messaging.</li> </ul>"},{"location":"features/0095-basic-message/#prior-art","title":"Prior art","text":"<p>BasicMessage has parallels to SMS, which led to the later creation of MMS and even the still-under-development RCS.</p>"},{"location":"features/0095-basic-message/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Receive receipts (NOT read receipts) may be implicitly supported by an ack decorator with pre-processing support.</li> </ul>"},{"location":"features/0095-basic-message/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Indy Cloud Agent - Python Reference agent implementation contributed by Sovrin Foundation and Community; MISSING test results Aries Framework - .NET .NET framework for building agents of all types; MISSING test results Streetcred.id Commercial mobile and web app built using Aries Framework - .NET; MISSING test results Aries Cloud Agent - Python Contributed by the government of British Columbia.; MISSING test results Aries Static Agent - Python Useful for cron jobs and other simple, automated use cases.; MISSING test results Aries Protocol Test Suite ; MISSING test results"},{"location":"features/0113-question-answer/","title":"Aries RFC 0113: Question Answer Protocol 0.9","text":"<ul> <li>Authors: Douglas Wightman</li> <li>Status: DEMONSTRATED</li> <li>Since: 2019-07-05</li> <li>Start Date: 2019-02-07</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0113-question-answer/#summary","title":"Summary","text":"<p>A simple protocol where a questioner asks a responder a question with at least one valid answer.  The responder then replies with an answer or ignores the question.</p> <pre><code>Note: While there is a need in the future for a robust negotiation protocol\nthis is not it. This is for simple question/answer exchanges.\n</code></pre>"},{"location":"features/0113-question-answer/#motivation","title":"Motivation","text":"<p>There are many instances where one party needs an answer to a specific question from another party. These can be related to consent, proof of identity, authentication, or choosing from a list of options. For example, when receiving a phone call a customer service representative can ask a question to the customer\u2019s phone to authenticate the caller, \u201cAre you on the phone with our representative?\u201d. The same could be done to authorize transactions, validate logins (2FA), accept terms and conditions, and any other simple, non-negotiable exchanges.</p>"},{"location":"features/0113-question-answer/#tutorial","title":"Tutorial","text":"<p>We'll describe this protocol in terms of a [Challenge/Response] https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication) scenario where a customer service representative for Faber Bank questions its customer Alice, who is speaking with them on the phone, to answer whether it is really her.</p>"},{"location":"features/0113-question-answer/#interaction","title":"Interaction","text":"<p>Using an already established pairwise connection and agent-to-agent communication Faber will send a question to Alice with one or more valid responses with an optional deadline and Alice can select one of the valid responses or ignore the question. If she selects one of the valid responses she will respond with her answer.</p>"},{"location":"features/0113-question-answer/#roles","title":"Roles","text":"<p>There are two parties in a typical question/answer interaction. The first party (Questioner) issues the question with its valid answers and the second party (Responder) responds with the selected answer. The parties must have already exchanged pairwise keys and created a connection. These pairwise can be used to encrypt and verify the response. When the answer has been sent questioner can know with a high level of certainty that it was sent by responder.</p> <p>In this tutorial Faber (the questioner) initiates the interaction and creates and sends the question to Alice. The question includes the valid responses, which can optionally be signed for non-repudiability.</p> <p>In this tutorial Alice (the responder) receives the packet and must respond to the question (or ignore it, which is not an answer) by encrypting either the positive or the negative response_code (signing both is invalid).</p>"},{"location":"features/0113-question-answer/#messages","title":"Messages","text":"<p>All messages in this protocol are part of the \"Question/Answer 1.0\" message family uniquely identified by this DID reference:</p> <pre><code>https://didcomm.org/questionanswer/1.0\n</code></pre> <p>The protocol begins when the questioner sends a <code>questionanswer</code> message to the responder:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/questionanswer/1.0/question\",\n  \"@id\": \"518be002-de8e-456e-b3d5-8fe472477a86\",\n  \"question_text\": \"Alice, are you on the phone with Bob from Faber Bank right now?\",\n  \"question_detail\": \"This is optional fine-print giving context to the question and its various answers.\",\n  \"nonce\": \"&lt;valid_nonce&gt;\",\n  \"signature_required\": true,\n  \"valid_responses\" : [\n    {\"text\": \"Yes, it's me\"},\n    {\"text\": \"No, that's not me!\"}],\n  \"~timing\": {\n    \"expires_time\": \"2018-12-13T17:29:06+0000\"\n  }\n}\n</code></pre> <p>The responder receives this message and chooses the answer. If the signature is required then she uses her private pairwise key to sign  her response.</p> <pre><code>Note: Alice should sign the following: the question, the chosen answer,\nand the nonce: HASH(&lt;question_text&gt;+&lt;answer_text&gt;+&lt;nonce&gt;), this keeps a\nrecord of each part of the transaction.\n</code></pre> <p>The response message is then sent using the ~sig message decorator:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/questionanswer/1.0/answer\",\n  \"~thread\": { \"thid\": \"518be002-de8e-456e-b3d5-8fe472477a86\", \"seqnum\": 0 },\n  \"response\": \"Yes, it's me\",\n  \"response~sig\": {\n    \"@type\": \"https://didcomm.org/signature/1.0/ed25519Sha512_single\"\n    \"signature\": \"&lt;digital signature function output&gt;\",\n    \"sig_data\": \"&lt;base64url(HASH(\"Alice, are you on the phone with Bob?\"+\"Yes, it's me\"+\"&lt;nonce&gt;\"))&gt;\",\n    \"signers\": [\"&lt;responder_key&gt;\"],\n    }\n  \"~timing\": {\n    \"out_time\": \"2018-12-13T17:29:34+0000\"\n  }\n}\n</code></pre> <p>The questioner then checks the signature against the sig_data.</p>"},{"location":"features/0113-question-answer/#optional-elements","title":"Optional Elements","text":"<p>The \"question_detail\" field is optional. It can be used to give \"fine print\"-like context around the question and all of its valid responses. While this could always be displayed, some UIs may choose to only make it available on-demand, in a \"More info...\" kind of way.</p> <p>~timing.expires_time is optional ~response~sig is optional when \"signature_required\" is false</p>"},{"location":"features/0113-question-answer/#business-cases-and-auditing","title":"Business cases and auditing","text":"<p>In the above scenario, Faber bank can audit the reply and prove that only Alice's pairwise key signed the response  (a cryptographic API like Indy-SDK can be used to guarantee the responder's signature). Conversely, Alice can also use her key to prove or dispute the validity of the signature. The cryptographic guarantees central to agent-to-agent communication and digital signatures create a trustworthy protocol for obtaining a committed answer from a pairwise connection. This  protocol can be used for approving wire transfers, accepting EULAs, or even selecting an item from a food menu. Of course,  as with a real world signature, Alice should be careful about what she signs.</p>"},{"location":"features/0113-question-answer/#invalid-replies","title":"Invalid replies","text":"<p>The responder may send an invalid, incomplete, or unsigned response. In this case the questioner must decide what to do. As with normal verbal communication, if the response is not understood the question can be asked again, maybe with increased emphasis. Or the questioner may determine the lack of a valid response is a response in and of itself. This depends on the parties involved and the question being asked. For example, in the exchange above, if the question times out or the answer is not \"Yes, it's me\" then Faber would probably choose to discontinue the phone call.</p>"},{"location":"features/0113-question-answer/#trust-and-constraints","title":"Trust and Constraints","text":"<p>Using already established pairwise relationships allows each side to trust each other. The responder can know who sent the message and the questioner knows that only the responder could have encrypted the response. This response gives a high level of trust to the exchange.</p>"},{"location":"features/0113-question-answer/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Connect.Me Free mobile app from Evernym. Installed via app store on iOS and Android. Verity Commercially licensed enterprise agent, SaaS or on-prem."},{"location":"features/0114-predefined-identities/","title":"Aries RFC 0114: Predefined Identities","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Start Date: 2019-07-10</li> <li>Tags: feature</li> </ul>"},{"location":"features/0114-predefined-identities/#summary","title":"Summary","text":"<p>Documents some keys, DIDs, and DID Docs that may be useful for testing, simulation, and spec writing. The fake ones are the DIDComm / identity analogs to the reserved domain \"example.com\" that was allocated for testing purposes with DNS and other internet systems -- or to Microsoft's example Contoso database and website used to explore and document web development ../../concepts.</p>"},{"location":"features/0114-predefined-identities/#real-identities","title":"Real Identities","text":"<p>The following real--NOT fake--identities are worth publicly documenting.</p>"},{"location":"features/0114-predefined-identities/#aries-community","title":"Aries community","text":"<p>The collective Aries developer community is represented by:</p> <pre><code>did:sov:BzCbsNYhMrjHiqZDTUASHg -- verkey = 6zJ9dboyug451A8dtLgsjmjyguQcmq823y7vHP6vT2Eu\n</code></pre> <p>This DID is currently allocated, but not actually registered on Sovrin's mainnet. You will see this DID in a number of RFCs, as the basis of a PIURI that identifies a community-defined protocol. You DO NOT have to actually resolve this DID or relate to a Sovrin identity to use Aries or its RFCs; think of this more like the opaque URNs that are sometimes used in XML namespacing. At some point it may be registered, but nothing else in the preceding summary will change.</p> <p>The community controls a second DID that is useful for defining message families that are not canonical (e.g., in the sample tic-tac-toe protocol). It is:</p> <pre><code>did:sov:SLfEi9esrjzybysFxQZbfq -- verkey = Ep1puxjTDREwEyz91RYzn7arKL2iKQaDEB5kYDUUUwh5\n</code></pre> <p>This community may create DIDs for itself from other DID methods, too. If so, we will publish them here.</p>"},{"location":"features/0114-predefined-identities/#subgroups","title":"Subgroups","text":"<p>The Aries community may create subgroups with their own DIDs. If so, we may publish such information here.</p>"},{"location":"features/0114-predefined-identities/#allied-communities","title":"Allied communities","text":"<p>Other groups such as DIF, the W3C Crecentials Community Group, and so forth may wish to define identities and announce their associated DIDs here.</p>"},{"location":"features/0114-predefined-identities/#fake-identities","title":"Fake Identities","text":"<p>The identity material shown below is not registered anywhere. This is because sometimes our tests or demos are about registering or connecting, and because the identity material is intended to be somewhat independent of a specific blockchain instance. Instead, we define values and give them names, permalinks, and semantics in this RFC. This lets us have a shared understanding of how we expect them to behave in various contexts.</p> <p>WARNING: Below you will see some published secrets. By disclosing private keys and/or their seeds, we are compromising the keypairs. This fake identity material is thus NOT trustworthy for anything; the world knows the secrets, and now you do, too. <code>:-)</code> You can test or simulate workflows with these keys. You might use them in debugging and development. But you should never use them as the basis of real trust.</p>"},{"location":"features/0114-predefined-identities/#dids","title":"DIDs","text":""},{"location":"features/0114-predefined-identities/#alice-sov-1","title":"alice-sov-1","text":"<p>This DID, the <code>alice-sov-1</code> DID with value <code>did:sov:UrDaZsMUpa91DqU3vrGmoJ</code>, is associated with a very simplistic Indy/Sovrin identity. It has a single keypair (Key 1 below) that it uses for everything. In demos or tests, its genesis DID Doc looks like this:</p> <pre><code>{\n    \"@context\": \"https://w3id.org/did/v0.11\",\n    \"id\": \"did:sov:UrDaZsMUpa91DqU3vrGmoJ\",\n    \"service\": [{\n        \"type\": \"did-communication\",\n        \"serviceEndpoint\": \"https://localhost:23456\"\n    }],\n    \"publicKey\": [{\n        \"id\": \"#key-1\",\n        \"type\": \"Ed25519VerificationKey2018\",\n        \"publicKeyBase58\": \"GBMBzuhw7XgSdbNffh8HpoKWEdEN6hU2Q5WqL1KQTG5Z\"\n    }],\n    \"authentication\": [\"#key-1\"]\n}\n</code></pre>"},{"location":"features/0114-predefined-identities/#bob-many-1","title":"bob-many-1","text":"<p>This DID, the <code>bob-many-1</code> DID with value <code>did:sov:T9nQQ8CjAhk2oGAgAw1ToF</code>, is associated with a much more flexible, complex identity than <code>alice-sov-1</code>. It places every test keypair except Key 1 in the <code>authentication</code> section of its DID Doc. This means you should be able to talk to Bob using the types of crypto common in many communities, not just Indy/Sovrin. Its genesis DID doc looks like this:</p> <pre><code>{\n    \"@context\": \"https://w3id.org/did/v0.11\",\n    \"id\": \"did:sov:T9nQQ8CjAhk2oGAgAw1ToF\",\n    \"service\": [{\n        \"type\": \"did-communication\",\n        \"serviceEndpoint\": \"https://localhost:23457\"\n    }],\n    \"publicKey\": [{\n        \"id\": \"#key-2\",\n        \"type\": \"Ed25519VerificationKey2018\",\n        \"controller\": \"#id\",\n        \"publicKeyBase58\": \"FFhViHkJwqA15ruKmHQUoZYtc5ZkddozN3tSjETrUH9z\"\n      },\n      {\n        \"id\": \"#key-3\",\n        \"type\": \"Secp256k1VerificationKey2018\",\n        \"controller\": \"#id\",\n        \"publicKeyHex\": \"3056301006072a8648ce3d020106052b8104000a03420004a34521c8191d625ff811c82a24a60ff9f174c8b17a7550c11bba35dbf97f3f04392e6a9c6353fd07987e016122157bf56c487865036722e4a978bb6cd8843fa8\"\n      },\n      {\n        \"id\": \"#key-4\",\n        \"type\": \"RsaVerificationKey2018\",\n        \"controller\": \"#id\",\n        \"publicKeyPem\": \"-----BEGIN PUBLIC KEY-----\\r\\nMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlOJu6TyygqxfWT7eLtGDwajtN\\r\\nFOb9I5XRb6khyfD1Yt3YiCgQWMNW649887VGJiGr/L5i2osbl8C9+WJTeucF+S76\\r\\nxFxdU6jE0NQ+Z+zEdhUTooNRaY5nZiu5PgDB0ED/ZKBUSLKL7eibMxZtMlUDHjm4\\r\\ngwQco1KRMDSmXSMkDwIDAQAB\\r\\n-----END PUBLIC KEY-----\"\n      },\n      {\n        \"id\": \"#key-5\",\n        \"type\": \"RsaVerificationKey2018\",\n        \"controller\": \"#id\",\n        \"publicKeyPem\": \"-----BEGIN PUBLIC KEY-----\\r\\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAoZp7md4nkmmFvkoHhQMw\\r\\nN0lcpYeKfeinKir7zYWFLmpClZHawZKLkB52+nnY4w9ZlKhc4Yosrw/N0h1sZlVZ\\r\\nfOQBnzFUQCea6uK/4BKHPhiHpN73uOwu5TAY4BHS7fsXRLPgQFB6o6iy127o2Jfb\\r\\nUVpbNU/rJGxVI2K1BIzkfrXAJ0pkjkdP7OFE6yRLU4ZcATWSIPwGvlF6a0/QPC3B\\r\\nbTvp2+DYPDC4pKWxNF/qOwOnMWqxGq6ookn12N/GufA/Ugv3BTVoy7I7Q9SXty4u\\r\\nUat19OBJVIqBOMgXsyDz0x/C6lhBR2uQ1K06XRa8N4hbfcgkSs+yNBkLfBl7N80Q\\r\\n0Wkq2PHetzQU12dPnz64vvr6s0rpYIo20VtLzhYA8ZxseGc3s7zmY5QWYx3ek7Vu\\r\\nwPv9QQzcmtIQQsUbekPoLnKLt6wJhPIGEr4tPXy8bmbaThRMx4tjyEQYy6d+uD0h\\r\\nXTLSjZ1SccMRqLxoPtTWVNXKY1E84EcS/QkqlY4AthLFBL6r+lnm+DlNaG8LMwCm\\r\\ncz5NMag9ooM9IqgdDYhUpWYDSdOvDubtz1YZ4hjQhaofdC2AkPXRiQvMy/Nx9WjQ\\r\\nn4z387kz5PK5YbadoZYkwtFttmxJ/EQkkhGEDTXoSRTufv+qjXDsmhEsdaNkvcDP\\r\\n1uiCSY19UWe5LQhIMbR0u/0CAwEAAQ==\\r\\n-----END PUBLIC KEY-----\"\n      },\n    ],\n    \"authentication\": [\"#key-2\", \"#key-3\", \"#key-4\", \"#key-5\", \"#key-6\"]\n}\n</code></pre> <p>[TODO: define DIDs from other ecosystems that put the same set of keys in their DID docs -- maybe <code>bob-many-2</code> is a did:eth using these same keys, and <code>bob-many-3</code> is a did:btc using them...]</p>"},{"location":"features/0114-predefined-identities/#keys","title":"Keys","text":""},{"location":"features/0114-predefined-identities/#key-1-ed25519","title":"Key 1 (Ed25519)","text":"<p>This key is used by the <code>alice-sov-1</code> DID, but could also be used with other DIDs defined elsewhere.</p> <pre><code>signing key (private)\nGa3v3SyNsvv1QhSCrEAQfJiyxQYUdZzQARkCosSWrXbT\n\nhex seed (private; in a form usable by Indy CLI)\ne756c41c1b5c48d3be0f7b5c7aa576d2709f13b67c9078c7ded047fe87c8a79e\n\nverkey (public)\nGBMBzuhw7XgSdbNffh8HpoKWEdEN6hU2Q5WqL1KQTG5Z\n\nas a Sovrin DID\ndid:sov:UrDaZsMUpa91DqU3vrGmoJ\n</code></pre>"},{"location":"features/0114-predefined-identities/#key-2-ed25519","title":"Key 2 (Ed25519)","text":"<p>This key is used by the <code>bob-many-1</code> DID, but could also be used with other DIDs defined elsewhere.</p> <pre><code>signing key (private)\nFE2EYN25vcQmCU52MkiHuXHKqR46TwjFU4D4TGaYDRyd\n\nhex seed (private)\nd3598fea152e6a480faa676a76e545de7db9ac1093b9cee90b031d9625f3ce64\n\nverkey (public)\nFFhViHkJwqA15ruKmHQUoZYtc5ZkddozN3tSjETrUH9z\n\nas a Sovrin DID\ndid:sov:T9nQQ8CjAhk2oGAgAw1ToF\n</code></pre>"},{"location":"features/0114-predefined-identities/#key-3-secp256k1","title":"Key 3 (Secp256k1)","text":"<p>This key is used by the <code>bob-many-1</code> DID, but could also be used with other DIDs defined elsewhere.</p> <pre><code>-----BEGIN EC PRIVATE KEY-----\nMHQCAQEEIMFcUvDujXt0/C48vm1Wfj8ADlrGsHCHzp//2mUARw79oAcGBSuBBAAK\noUQDQgAEo0UhyBkdYl/4EcgqJKYP+fF0yLF6dVDBG7o12/l/PwQ5LmqcY1P9B5h+\nAWEiFXv1bEh4ZQNnIuSpeLts2IQ/qA==\n-----END EC PRIVATE KEY-----\n\n-----BEGIN PUBLIC KEY-----\nMFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAEo0UhyBkdYl/4EcgqJKYP+fF0yLF6dVDB\nG7o12/l/PwQ5LmqcY1P9B5h+AWEiFXv1bEh4ZQNnIuSpeLts2IQ/qA==\n-----END PUBLIC KEY-----\n\npublic key as hex\n3056301006072a8648ce3d020106052b8104000a03420004a34521c8191d625ff811c82a24a60ff9f174c8b17a7550c11bba35dbf97f3f04392e6a9c6353fd07987e016122157bf56c487865036722e4a978bb6cd8843fa8\n</code></pre>"},{"location":"features/0114-predefined-identities/#key-4-1024-bit-rsa","title":"Key 4 (1024-bit RSA)","text":"<p>This key is used by the <code>bob-many-1</code> DID, but could also be used with other DIDs defined elsewhere.</p> <pre><code>-----BEGIN RSA PRIVATE KEY-----\nMIICXQIBAAKBgQDlOJu6TyygqxfWT7eLtGDwajtNFOb9I5XRb6khyfD1Yt3YiCgQ\nWMNW649887VGJiGr/L5i2osbl8C9+WJTeucF+S76xFxdU6jE0NQ+Z+zEdhUTooNR\naY5nZiu5PgDB0ED/ZKBUSLKL7eibMxZtMlUDHjm4gwQco1KRMDSmXSMkDwIDAQAB\nAoGAfY9LpnuWK5Bs50UVep5c93SJdUi82u7yMx4iHFMc/Z2hfenfYEzu+57fI4fv\nxTQ//5DbzRR/XKb8ulNv6+CHyPF31xk7YOBfkGI8qjLoq06V+FyBfDSwL8KbLyeH\nm7KUZnLNQbk8yGLzB3iYKkRHlmUanQGaNMIJziWOkN+N9dECQQD0ONYRNZeuM8zd\n8XJTSdcIX4a3gy3GGCJxOzv16XHxD03GW6UNLmfPwenKu+cdrQeaqEixrCejXdAF\nz/7+BSMpAkEA8EaSOeP5Xr3ZrbiKzi6TGMwHMvC7HdJxaBJbVRfApFrE0/mPwmP5\nrN7QwjrMY+0+AbXcm8mRQyQ1+IGEembsdwJBAN6az8Rv7QnD/YBvi52POIlRSSIM\nV7SwWvSK4WSMnGb1ZBbhgdg57DXaspcwHsFV7hByQ5BvMtIduHcT14ECfcECQATe\naTgjFnqE/lQ22Rk0eGaYO80cc643BXVGafNfd9fcvwBMnk0iGX0XRsOozVt5Azil\npsLBYuApa66NcVHJpCECQQDTjI2AQhFc1yRnCU/YgDnSpJVm1nASoRUnU8Jfm3Oz\nuku7JUXcVpt08DFSceCEX9unCuMcT72rAQlLpdZir876\n-----END RSA PRIVATE KEY-----\n\n-----BEGIN PUBLIC KEY-----\nMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlOJu6TyygqxfWT7eLtGDwajtN\nFOb9I5XRb6khyfD1Yt3YiCgQWMNW649887VGJiGr/L5i2osbl8C9+WJTeucF+S76\nxFxdU6jE0NQ+Z+zEdhUTooNRaY5nZiu5PgDB0ED/ZKBUSLKL7eibMxZtMlUDHjm4\ngwQco1KRMDSmXSMkDwIDAQAB\n-----END PUBLIC KEY-----\n</code></pre>"},{"location":"features/0114-predefined-identities/#key-5-4096-bit-rsa","title":"Key 5 (4096-bit RSA)","text":"<p>This key is used by the <code>bob-many-1</code> DID, but could also be used with other DIDs defined elsewhere.</p> <pre><code>-----BEGIN RSA PRIVATE KEY-----\nMIIJKAIBAAKCAgEAoZp7md4nkmmFvkoHhQMwN0lcpYeKfeinKir7zYWFLmpClZHa\nwZKLkB52+nnY4w9ZlKhc4Yosrw/N0h1sZlVZfOQBnzFUQCea6uK/4BKHPhiHpN73\nuOwu5TAY4BHS7fsXRLPgQFB6o6iy127o2JfbUVpbNU/rJGxVI2K1BIzkfrXAJ0pk\njkdP7OFE6yRLU4ZcATWSIPwGvlF6a0/QPC3BbTvp2+DYPDC4pKWxNF/qOwOnMWqx\nGq6ookn12N/GufA/Ugv3BTVoy7I7Q9SXty4uUat19OBJVIqBOMgXsyDz0x/C6lhB\nR2uQ1K06XRa8N4hbfcgkSs+yNBkLfBl7N80Q0Wkq2PHetzQU12dPnz64vvr6s0rp\nYIo20VtLzhYA8ZxseGc3s7zmY5QWYx3ek7VuwPv9QQzcmtIQQsUbekPoLnKLt6wJ\nhPIGEr4tPXy8bmbaThRMx4tjyEQYy6d+uD0hXTLSjZ1SccMRqLxoPtTWVNXKY1E8\n4EcS/QkqlY4AthLFBL6r+lnm+DlNaG8LMwCmcz5NMag9ooM9IqgdDYhUpWYDSdOv\nDubtz1YZ4hjQhaofdC2AkPXRiQvMy/Nx9WjQn4z387kz5PK5YbadoZYkwtFttmxJ\n/EQkkhGEDTXoSRTufv+qjXDsmhEsdaNkvcDP1uiCSY19UWe5LQhIMbR0u/0CAwEA\nAQKCAgBWzqj+ajtPhqd1JEcNyDyqNhoyQLDAGa1SFWzVZZe46xOBTKv5t0KI1BSN\nT86VibVRCW97J8IA97hT2cJU5hv/3mqQnOro2114Nv1i3BER5hNXGP5ws04thryW\nAH0RoQNKwGUBpzl5mDEZUFZ7oncJKEQ+SwPAuQCy1V7vZs+G0RK7CFcjpmLkl81x\nkjl0UIQzkhdA6KCmsxXTdzggW2O/zaM9nXYKPxGwP+EEhVFJChlRjkI8Vv32z0vk\nh7A0ST16UTsL7Tix0rfLI/OrTn9LF5NxStmZNB1d5v30FwtiqXkGcQn/12QhGjxz\nrLbGDdU3p773AMJ1Ac8NhpKN0vXo7NOh9qKEq0KfLy+AD6CIDB9pjZIolajqFOmO\nRENAP9eY/dP7EJNTSU84GJn8csQ4imOIYqp0FkRhigshMbr7bToUos+/OlHYbMry\nr/I8VdMt4xazMK5PtGn9oBzfv/ovNyrQxv562rtx3G996HFF6+kCVC3mBtTHe0p2\nVKNJaXlQSkEyrYAOqhnMvIfIMuuG2+hIuv5LBBdCyv6YC4ER2RsaXHt4ZBfsbPfO\nTEP4YCJTuLc+Fyg1f01EsuboB0JmvzNyiK+lBp8FsxiqwpIExriBCPJgaxoWJMFh\nxrRzTXwBWkJaDhYVbc2bn8TtJE6uEC9m4B7IUQOrXXKyOTqUgQKCAQEAzJl16J3Y\nYjkeJORmvi2J1UbaaBJAeCB7jwXlarwAq8sdxEqdDoRB6cZhWX0VMH46oaUA+Ldx\nCoO2iMgOrs0p6dJOj1ybtIhiX9PJTzstd5WEltU/mov+DzlBiKg78dFi/B5HfE/F\nKIDx4gTcD//sahooMqbg78QfOO+JjLrvT7TljL/puOAM8LTytZqOaDIDwnblpSgZ\nJcCqochmz9b7f7NHbgVrBkXZTsgbH6Dw4H7T0WC4K4P4dJW8Js18r+xN3W8/ZhmY\nlxTDZy40LlUy7++Ha+v8vZ4cRJKq2sdTtt9Z/ZYDfpCDT5ZmGS/gDloGean9mivG\nlt/zgDswEUji9QKCAQEAyjPKsBitJ39S26H/hp5oZRad1MOXgXPpbu8ARmHooKP3\nQ0dtnreBLzIQxxIitp3GjzJFU9r/tqy/ylOhIGAt+340KoSye3gGpvxZImMAIIR9\ns03GE5AHJ4J5NIxQKX+g9o0fV44bVNrLzAnHaZh+Bi4xbLatBJABgN2TnjA8lx7x\nlrqb99VpKLZP7DGxK7o0Ji4qerMPeIVoJ9RaUkTYguJaXG22nPeKfDiI13xlm1RU\nptulJG3CkRYp48Udmqb1b+67KMOxKL1ISGhuzqitOY+Ua1sM5SEFyukEhMuK6/uM\nSCAVl9aNHU5vx95D/T7onPAnxNqDObWeZi2HWoif6QKCAQEAxC4BmOKBMO2Dsewv\nd/tCRnaBxXh6yLScxS7qI8XQ/ujryeOhZOH8MaQ+hAgj4TOoFIaav+FlSqewxsbN\nDV876S/2lBBAXILJkQkJ5ibgGeIMGHSxYAcLvJ0x8U8e62fSedyuvsveSFAbnpT6\nTX0fuz0Jfkf1NvHe3kEQqxgzj0HtOWBrQxHSVpuqfeeM1OvgHv7Sg+JG+qQa+LWn\nn3KMBI5q11vqm0EudRP6rgEr9pallAYhkdggy+knWC2AeU8j+kdJiyTP403Nb4om\nDqczCE2slBbbaRXKFRZtLQojgx32s+i7wQfgYNfdXhlBxYEc5FvTB5kh+lkSqsoV\n9PzmYQKCAQBrQHGAWnZt/uEqUpFBDID/LbHmCyEvrxXgm7EfpAtKOe6LpzWD/H3v\nVLUFgp8bEjEh/146jm0YriTE4vsSOzHothZhfyVUzGNq62s0DCMjHGO4WcZ41eqV\nkGVN9CcI/AObA1veiygAKFX1EjLN1e7yxEm/Cl5XjzLc8aq9O4TH+8fVVYIpQO+Y\ngqt98xWwxgGnRtGNZ7ELEmgeyEpoXNAjDIE1iZRVShAQt8QN2JPkgiSspNDBs96C\nKqlpgUKkp26EQrLPeo1buJrAnXQ49ct8PqZRE2iRmKSD7nlRHs2/Qhw0naAWe905\n8ELmVwTlLRshM1lE10rHr4gnVnr3EIURAoIBAFXLQXV9CuLoV9nosprVYbhSWLMj\nO9ChjgGfCmqi3gQecJxctwNlo3l8f5W2ZBrIqgWFsrxzHd2Ll4k2k/IcFa4jtz9+\nPrSGZz8TEkM5ERSwDd1QXNE/P7AV6EDs/W/V0T5G1RE82YGkf0PNM+drJ/r/I4HS\nN0DDlZb8YwjkP1tT8x3I+vx9bLWczbsMhrwIEUPQJZxMSdZ+DMM45TwAXyp9aLzU\npa9CdL1gAtSLA7AmcafGeUIA7N1evRYuUVWhhSRjPX55hGBoO0u9fxZIPRTf0dcK\nHHK05KthUPh7W5TXSPbni/GyuNg3H7kavT7ANHOwI77CfaKFgxLrZan+sAk=\n-----END RSA PRIVATE KEY-----\n\n-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAoZp7md4nkmmFvkoHhQMw\nN0lcpYeKfeinKir7zYWFLmpClZHawZKLkB52+nnY4w9ZlKhc4Yosrw/N0h1sZlVZ\nfOQBnzFUQCea6uK/4BKHPhiHpN73uOwu5TAY4BHS7fsXRLPgQFB6o6iy127o2Jfb\nUVpbNU/rJGxVI2K1BIzkfrXAJ0pkjkdP7OFE6yRLU4ZcATWSIPwGvlF6a0/QPC3B\nbTvp2+DYPDC4pKWxNF/qOwOnMWqxGq6ookn12N/GufA/Ugv3BTVoy7I7Q9SXty4u\nUat19OBJVIqBOMgXsyDz0x/C6lhBR2uQ1K06XRa8N4hbfcgkSs+yNBkLfBl7N80Q\n0Wkq2PHetzQU12dPnz64vvr6s0rpYIo20VtLzhYA8ZxseGc3s7zmY5QWYx3ek7Vu\nwPv9QQzcmtIQQsUbekPoLnKLt6wJhPIGEr4tPXy8bmbaThRMx4tjyEQYy6d+uD0h\nXTLSjZ1SccMRqLxoPtTWVNXKY1E84EcS/QkqlY4AthLFBL6r+lnm+DlNaG8LMwCm\ncz5NMag9ooM9IqgdDYhUpWYDSdOvDubtz1YZ4hjQhaofdC2AkPXRiQvMy/Nx9WjQ\nn4z387kz5PK5YbadoZYkwtFttmxJ/EQkkhGEDTXoSRTufv+qjXDsmhEsdaNkvcDP\n1uiCSY19UWe5LQhIMbR0u/0CAwEAAQ==\n-----END PUBLIC KEY-----\n</code></pre>"},{"location":"features/0114-predefined-identities/#key-6-ed25519","title":"Key 6 (Ed25519)","text":"<p>This key is used by the <code>bob-many-1</code> DID, but could also be used with other DIDs defined elsewhere.</p> <pre><code>signing key (private)\n9dTU6xawVQJprz7zYGCiTJCGjHdW5EcZduzRU4z69p64\n\nhex seed (private; in a form usable by Indy CLI)\n803454c9429467530b17e8e571df5442b6620ac06ab0172d943ab9e01f6d4e31\n\nverkey (public)\n4zZJaPg26FYcLZmqm99K2dz99agHd5rkhuYGCcKntAZ4\n\nas a Sovrin DID\ndid:sov:8KrDpiKkHsFyDm3ZM36Rwm\n</code></pre>"},{"location":"features/0114-predefined-identities/#tools-to-generate-your-own-identity-material","title":"Tools to generate your own identity material","text":"<ul> <li>Digital Bazaar's DID tool</li> <li>uPort tool</li> <li>Ed25519 and Indy-compatible DIDs in pure client-side javascript</li> <li>Hyperledger Indy CLI</li> </ul>"},{"location":"features/0114-predefined-identities/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0116-evidence-exchange/","title":"Aries RFC 0116: Evidence Exchange Protocol 0.9","text":"<ul> <li>Authors: Dan Gisolfi</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Start Date: 2019-07-05</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0116-evidence-exchange/#summary","title":"Summary","text":"<p>The goal of this protocol is to allow Holders to provider an inquiring Verifier with a secure and trusted mechanism for obtaining access to the foundational evidence that enabled the Issuer the assurances necessary to create the Verifiable Credential(s) that the Holder has presented to the Verifier. To this end, a P2P evidence exchange protocol is required that will allow parties using Pair-wise Peer DIDs to exchange evidence in support of the issuance of Verified Credentials without any dependencies on a  centralized storage facility.</p>"},{"location":"features/0116-evidence-exchange/#motivation","title":"Motivation","text":"<p>During the identity verification process, an entity may require access to the genesis documents used to establish digital credentials issued by a credential issuing entity or Credential Service Provider (CSP).  In support of the transition from existing business verification processes to emerging business processes that rely on digitally verified credentials using protocols such as 0036-issue-credential and 0037-present-proof, we need to establish a protocol that allow entities to make this transition while remaining compliant with business and regulatory requirements. Therefore, we need a mechanism for Verifiers to obtain access to vetted evidence (physical or digital information or documentation) without requiring a relationship or interaction with the Issuer.</p> <p>While this protocol should be supported by all persona, its relevance to decentralized identity ecosystems is highly dependent on the business policies of a market segment of Verifiers. For more details see the Persona section.</p> <p>While technology advancements around identity verification are improving, business policies (most often grounded in risk mitigation) will not change at the same rate of speed. For example, just because a financial institution in Singapore is willing to rely on the KYC due-diligence processing of another institution, we should not assume that the banks in another geolocation (i.e: Hong Kong) can embrace the same level of trust. For this reason, we must enable Verifiers with the option to obtain evidence that backs any assertions made by digital credential issuers.</p> <p>Based on a web-of-trust and cryptographic processing techniques, Verifiers of digital credentials can fulfill their identity proofing workflow requirements. However, business policies and regulatory compliance may require them to have evidence for oversight activities such as but not limited to government mandated Anti-Money Laundering (AML) Compliance audits.</p> <p>Verifiers or relying parties (RPs) of digital credentials need to make informed decisions about the risk of accepting a digital identity before trusting the digital credential and granting associated privileges. To mitigate such risk, the Verifier may need to understand the strength of the identity proofing process. According to a December 2015 - NIST Information Technology Laboratory Workshop Report, Measuring Strength of Identity Proofing, there are two (2) identity proofing methods that can be leveraged by a CSP:</p> Proofing Method Description In-Person Identity Proofing Holder is required to present themselves and their documentation directly to a trained representative of an identity proofing agency. Remote Identity Proofing Holder is not expected to present themselves or their documents at a physical location. Validation and verification of presented data (including digital documents) is performed programmatically against one or more corroborating authoritative sources of data. <p>If the In-Person Identity Proofing method is used, the strength can easily be determined by allowing the Verifier to gain access to any Original Documents used by the Issuer of a Derived Credential. In the situation where a Remote Identity Proofing method is used, confidence in the strength of the identity proofing process can be determined by allowing the Verifier to gain access to Digital Assertions used by the Issuer of a Derived Credential.</p>"},{"location":"features/0116-evidence-exchange/#problem-scope","title":"Problem Scope","text":"<p>This protocol is intended to address the following challenging questions:</p> <ol> <li> <p>What evidence (information or documentation) was used to establish the level of certitude necessary to allow an Issuer to issue a Verifiable Credential?</p> </li> <li> <p>For each Identity Proofing Inquiry (challenge) such as Address, Identity, Photo and Achievement, which forms of evidence was used by the Issuer of the Verifiable Credential?</p> </li> <li> <p>When the Issuer's Examinier relies on an Identity Proofing Service Provider (IPSP) as part of its Remote Identity Proofing process:</p> </li> <li> <p>Can the IPSP provide a Digital Assertion in association with the Identity Instrument they have vetted as part of their service to the Examiner?</p> </li> <li> <p>Can the Issuer provide a Digital Assertion in association with its certitude in the reliability of its due-diligence activity that is dependent on 3<sup>rd</sup> parties?</p> </li> <li> <p>When the Issuer relies on trained examiners for its In-Person Identity Proofing process, can the Issuer provide access to the digitally scanned documents either by-value or by-reference?</p> </li> </ol>"},{"location":"features/0116-evidence-exchange/#assurance-levels","title":"Assurance Levels","text":"<p>Organizations that implement Identity Proofing generally seek to balance cost, convenience, and security for both the Issuer and the Holder. Examples of these tradeoffs include:</p> <ul> <li>Adjusting the complexity of a Remote Identity Proofing process to improve user experience can reduce the quality of the verification process;</li> <li>Overly complex proofing processes can result in increased abandonment which is unacceptable to some service providers;</li> <li>Overly generalized processes based on expected population characteristics (e.g., national origin, country of residency) can lead to persons that are unable to complete proofing as they may not share such characteristics.</li> </ul> <p>To mitigate the risk associated with such tradeoffs, the NIST 800-63A Digital Identity Guidelines outline three (3) levels of identity proofing assurance. These levels describe the degree of due-diligence performed during an Identity Proofing Process. See Section 5.2 Identity Assurance Levels Table 5-1.</p> <p>Users of this protocol will need to understand the type of evidence that was collected and how it was confirmed so that they can adhere to any business processes that require IAL2 or IAL3  assurance levels supported by Strong or Superior forms of evidence.</p>"},{"location":"features/0116-evidence-exchange/#dematerialization-of-physical-documents","title":"Dematerialization of physical documents","text":"<p>Today, entities (businesses, organizations, government agencies) maintain existing processes for the gathering, examination and archiving of physical documents. These entities may retain a copy of a physical document, a scanned digital copy or both. Using manual or automated procedures, the information encapsulated within these documents is extracted and stored as personal data attestations about the document presenter within a system of record (SOR).</p> <p></p> <p>As decentralized identity technologies begin to be adopted, these entities can transform these attestations into Verifiable Credentials.</p>"},{"location":"features/0116-evidence-exchange/#understanding-kyc","title":"Understanding KYC","text":"<p>Know Your Customer (KYC) is a process by which entities (business, governments, organizations) obtain information about the identity and address of their customers. This process helps to ensure that the services that the entity provides are not misused. KYC procedures vary based on geolocation and industry. For example, the KYC documents required to open a bank account in India versus the USA may differ but the basic intent of demonstrating proof of identity and address are similar. Additionally, the KYC documents necessary to meet business processing requirements for enrollment in a university may differ from that of onboarding a new employee.</p> <p>Regardless of the type of KYC processing performed by an entity, there may be regulatory or business best practice requirements that mandate access to any Original Documents presented as evidence during the KYC process. As entities transition from paper/plastic based identity proofing practices to Verifiable Credentials there may exist (albeit only for a transitional period) the need to gain access to the Identity Evidence that an Issuer examined before issuing credentials.</p> <p>This process is time consuming and costly for the credential Issuer and often redundant and inconvenient for the Holder. Some industry attempts have been made to establish centrally controlled B2B sharing schemas to help reduce such impediments to the Issuer. These approaches are typically viewed as vital for the betterment of the Issuers and Verifiers and are not designed for or motivated by the data privacy concerns of the Holder. The purpose of this protocol is to place the Holder at the center of the P2P C2B exchange of Identity Evidence while allowing Verifiers to gain confidence in identity proofing assurance levels.</p>"},{"location":"features/0116-evidence-exchange/#evidence-vetting-workflow","title":"Evidence Vetting Workflow","text":"<p>The Verifiable Credentials Specification describes three key stakeholders in an ecosystem that manages digital credentials: Issuers, Holders and Verifiers. However, before an Issuer can attest to claims about a Holder, an Examiner must perform the required vetting, due diligence, regulatory compliance and other tasks needed to establish confidence in making a claim about an identity trait associated with a Holder. The actions of the Examiner may include physical validation of information (i.e.: comparison of real person to a photo) as well as reliance on third party services as part of its vetting process. Depending on the situational context of a credential request or the type of privileges to be granted, the complexity of the vetting process taken by an examiner to confirm the truth about a specific trait may vary.</p> <p></p> <p>An identity Holder may present to an Examiner Identity Evidence in the form of a physical document or other forms of Identity Instruments to resolve Identity Proofing Inquires. The presentment of these types of evidence may come in a variety of formats:</p> <ul> <li><code>Paper/Plastic</code>: Typically associated with a face to face interaction for the exchange of documents.</li> <li><code>Digital Copy</code>: Typically associated with an online exchange whereby the the Holder uploads a scanned image of the original source (Paper/Plastic) document.</li> <li><code>URL</code>: Holder can provide a link to a digital document version of the original source (Paper/Plastic) document on some 3<sup>rd</sup> Party file storage solution:</li> <li>Document Storage Provider (Dropbox, iCloud)</li> <li>Credential Issuing Agent (Retail Bank, Credit Union, Verification Service Provider)</li> </ul>"},{"location":"features/0116-evidence-exchange/#evidence-access-matrix","title":"Evidence Access Matrix","text":"<p>Note: Assumption herein is that original documents are never forfeited by an individual.</p> Original Source Format Issuer Archived Format Verifier Business Process Format Protocol Requirement Paper/Plastic Paper-Copy n/a n/a Paper/Plastic Digital Copy Digital Copy Access by Value Paper/Plastic Digital Copy URL Access by Reference Digital Copy Digital Copy Digital Copy Access by Value Digital Copy Digital Copy URL Access by Reference Digital Scan Digital Copy Digital Copy Digital Assertion URL Digital Copy Digital Copy Access by Value URL Digital Copy URL Access by Reference"},{"location":"features/0116-evidence-exchange/#why-a-peer-did-protocol","title":"Why a Peer DID Protocol?","text":"<p>In a decentralized identity ecosystem where peer relationships no longer depend on a centralized authority for the source of truth, why should a Verifier refer to some 3<sup>rd</sup> party or back to the issuing institution for capturing Identity Evidence?</p> <ul> <li>Centralized Shared-KYC Providers: While there seems to be a trend to build shared ledgers that manage the exchange of KYC documents and data, we can not ignore the user-centric privacy by design principle that is foundational to decentralized identity solutions. Pair-wise Peer DIDs offer an alternative approach that is independent of any central source of truth, and are intended to be cheap, fast, scalable, and secure. The advantages of Pair-wise Peer DIDs make them suitable for most private relationships between people, organizations, and things.</li> <li>Issuer Communications: B2B interactions between a Verifier of a credential and the Issuer of the credential injects unnecessary correlation and behavior privacy risks for the Holder.</li> </ul>"},{"location":"features/0116-evidence-exchange/#solution-concepts","title":"Solution Concepts","text":""},{"location":"features/0116-evidence-exchange/#protocol-assumptions","title":"Protocol Assumptions","text":"<ol> <li>Holder must present Identity Evidence access to Verifier such that Verifier can be assured that the Issuer vetted the evidence.</li> <li>Some business processes and/or regulatory compliance requirements may demand that a Verifier gains access to the Original Documents vetted by a credential Issuer.</li> <li>Some Issuers may accept digital access links to documents as input into vetting process. This is often associated with Issuers who will accept copies of the Original Documents.</li> <li>Some Issuer may accept Digital Assertions from IPSPs as evidence of their due-diligence process. Examples of such IPSPs are: Acuant, Au10tix, IWS, Onfido and 1Kosmos.</li> </ol>"},{"location":"features/0116-evidence-exchange/#protocol-objectives","title":"Protocol Objectives","text":"<p>In order for a Verifier to avoid or reduce evidence vetting expenses it must be able to:</p> <ul> <li>be convinced that a trusted entity has performed the necessary vetting;</li> <li>know, if required, that access to the original vetted evidence is possible.</li> </ul> <p>This implies that the protocol must address the following evidence concerns:</p> Interaction Type Challenge Protocol Approach Examiner-to-Holder How does Issuer provide Holder with proof that it has vetted Identity Evidence? Issuer signs hash of the evidence and presents signature to Holder. Holder-to-Verifier How does Holder present Verifier with evidence that the Issuer of a Credential vetted Identity Evidence? Holder presents verifier with digitally signed hash of evidence, public DID of Issuer and access to a copy of the digital evidence. Verifier-to-FileStorageProvider How does Verifier access the evidence in digital format (base64)? Issuer or Holder must provide secure access to a digital copy of the document. Verifier-to-Verifier How does Verifier validate that Issuer attests to the vetting of the Identity Evidence for personal data claims encapsulated in issued credentials? Verifier gains access to the digital evidence, fetches the public key associated with the Issuer's DID and validates Issuer's signature of document hash."},{"location":"features/0116-evidence-exchange/#protocol-outcome","title":"Protocol Outcome","text":"<p>This protocol is intended to be a compliment to the foundational (issuance, verification) protocols for credential lifecycle management in support of the Verifiable Credentials Specification. Overtime, it is assumed that the exchange of Identity Evidence will no longer be necessary as digital credentials become ubiquitous. In the meantime, the trust in and access to Identity Evidence can be achieved in private peer to peer relationships using the Peer DID Spec.</p>"},{"location":"features/0116-evidence-exchange/#persona","title":"Persona","text":"<p>This protocol addresses the business policy needs of a market segment of Verifiers. Agent Software used by the following persona is required to support this market segment.</p> Persona Applicability Examiner Entities that perform In-Person and/or Remote Identity Proofing processes and need to support potential requests for evidence in support of the issuance of Verifiable Credentials based on the results of such processes. Issuer Entities with the certitude to share with a Holder supporting evidence for the due-diligence performed in association with attestations backing an issued Verifiable Credential. Holder A recipient of a Verifiable Credential, that desires to proactively gather supporting evidence of such a credential incase a Verifier should inquire. Verifier Entities that require access to Original Documents or Digital Assertions because they can not (for business policy reasons) rely on the identity proofing due-diligence of others. These entities may refer to a Trust Score based on their own business heuristics associated with the type of evidence supplied: Original Documents, Digital Assertions."},{"location":"features/0116-evidence-exchange/#user-stories","title":"User Stories","text":"<p>An example of the applicability of this protocol to real world user scenarios is discussed in the context of a decentralized digital notary where the credential issuing institution is not the issuer of the original source document(s) or digital assertions.</p>"},{"location":"features/0116-evidence-exchange/#evidence-types","title":"Evidence Types","text":"<p>In the context of this protocol, Identity Evidence represents physical or digital information-based artifacts that support a belief to common Identity Proofing Inquires (challenges):</p> <ul> <li>Proof of Identity: Are you who you claim to be?</li> <li>Proof of Address: Do you reside at a valid and confirmed place of residence?</li> <li>Proof of Photo: Can you present either a physical or digital image that can be compared with corroborating authoritative sources of data?</li> <li>Proof of Achievement: Have you accomplished what you claim to have achieved?</li> <li>Proof of Privilege: Have you been granted certain rights or affiliations?</li> </ul> <p>The following, non-exhaustive, list of physical information-based artifacts (documents) are used as evidence when confronted with common identity related inquires. They are often accompanied with a recent photograph. Since this protocol is intended to be agnostic of business and regulatory processes, the types of acceptable documents will vary.</p> Proof Type Sample Documents Address Passport, Voter\u2019s Identity Card, Utility Bill (Gas, Electric, Telephone/Mobile), Bank Account Statement, Letter from any recognized public authority or public servant, Credit Card Statement, House Purchase deed, Lease agreement along with last 3 months rent receipt, Employer\u2019s certificate for residence proof Identity Passport, PAN Card, Voter\u2019s Identity Card, Driving License, Photo identity proof of Central or State government, Ration card with photograph, Letter from a recognized public authority or public servant, Bank Pass Book bearing photograph, Employee identity card of a listed company or public sector company, Identity card of University or board of education Photo Passport, Pistol Permit, Photo identity proof of Central or State government Achievement Diploma, Certificate Privilege Membership/Loyalty Card, Health Insurance Card <p>These forms of Identity Evidence are examples of trusted credentials that an Examiner relies on during their vetting process.</p> <p></p>"},{"location":"features/0116-evidence-exchange/#tutorial","title":"Tutorial","text":"<p>The evidence exchange protocol builds on the attachment decorator within DIDComm using the the Inlining Method for Digital Assertions and the Appending Method for Original Documents.</p> <p>The protocol is comprised of the following messages and associated actions:</p> Interaction Type Message Process Actions Holder to Issuer Request Evidence Holder reviews the list of credentials it has received from the Issuer and sends an <code>evidence_request</code> message to Issuer's agent. Issuer to Holder Evidence Response Issuer collects Identity Evidence associated with each requested credential ID and sends an <code>evidence_response</code> message to Holder's agent. Upon receipt, the Holder stores evidence data in Wallet. Verifier to Holder Evidence Access Request Verifier builds and sends an <code>evidence_access_request</code> message to Holder's agent. Holder to Verifier Evidence Access Response Holder builds and sends an <code>evidence_access_response</code> message to the Verifier's agent. Verifier fetches requested Identity Evidence and performs digital signature validation on each. Verifier stores evidence in system of record. <p></p>"},{"location":"features/0116-evidence-exchange/#request-evidence-message","title":"Request Evidence Message","text":"<p>This message should be used as an accompaniment to an issue credential message. Upon receipt and storage of a credential the Holder should compose an <code>evidence_request</code> for each credential received from the Issuer. The Holder may use this message to get an update for new and existing credentials from the Issuer.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/evidence_exchange/1.0/evidence_request\",\n  \"@id\": \"6a4986dd-f50e-4ed5-a389-718e61517207\",\n  \"for\": \"did:peer:1-F1220479cbc07c3f991725836a3aa2a581ca2029198aa420b9d99bc0e131d9f3e2cbe\",\n  \"as_of_time\": \"2019-07-23 18:05:06.123Z\",\n  \"credentials\": [\"cred-001\", \"cred-002\"],\n  \"request-type\": \"by-value\"\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>credentials</code>: A list of credential IDs associated with this pair-wise relationship with the Issuer.</li> <li><code>request-type</code>: Stipulates how the Holder's Agent will manage the document access. If <code>by-value</code>, then a copy of the document will be stored by the Holder. If <code>by-reference</code>, then the storage provider service used by the Issuer will be the source of the document and any access control mechanisms will also need to be conveyed.</li> </ul> <p></p>"},{"location":"features/0116-evidence-exchange/#evidence-response-message","title":"Evidence Response Message","text":"<p>This message is required for an Issuer Agent in response to an <code>evidence_request</code> message. The format of the <code>~attach</code> attribute will be determined by the value of the <code>request_type</code> attribute in the associated request message from the Holder. If the Issuer relied on one or more IPSPs during the Identity Proofing Process, then this message will also include an inline attachment using the <code>examiner_assertions</code> attribute.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/evidence_exchange/1.0/evidence_response\",\n  \"@id\": \"1517207d-f50e-4ed5-a389-6a4986d718e6\",\n  \"~thread\": { \"thid\": \"6a4986dd-f50e-4ed5-a389-718e61517207\" },\n  \"for\": \"did:peer:1-F1220479cbc07c3f991725836a3aa2a581ca2029198aa420b9d99bc0e131d9f3e2cbe\",\n  \"as_of_time\": \"2019-07-23 18:05:06.123Z\",\n  \"credentials\": [\n    { \"@id\": \"cred-001\",\n      \"evidence\": [\n        {\"evidence_type\": \"Address\", \"evidence_ref\": [\"#kycdoc1\", \"#kycdoc4\"]},\n        {\"evidence_type\": \"Identity\", \"evidence_ref\": [\"#kycdoc2\"]},\n        {\"evidence_type\": \"Photo\", \"evidence_ref\": null}\n      ]\n    },\n    { \"@id\": \"cred-002\",\n      \"evidence\": [\n        {\"evidence_type\": \"Address\", \"evidence_ref\": [\"#kycdoc1\",\"#kycdoc3\"]},\n        {\"evidence_type\": \"Identity\", \"evidence_ref\": [\"#kycdoc3\"]},\n        {\"evidence_type\": \"Photo\", \"evidence_ref\": [\"#kycdoc1\"]}\n      ]\n    }\n  ],\n  \"examiner_assertions\": [ ... ],\n  \"~attach\": [ ... ]\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>credentials</code>: A list of credential IDs each containing an array of evidence.</li> <li><code>@id</code>: Corresponds to each ID associated with the list of credential IDs supplied by the Holder in the <code>evidence_request</code> message.</li> <li><code>evidence</code>: An array of evidence attachments associated with each type of evidence the Issuer has established for a specific credential.<ul> <li><code>evidence_type</code>: Stipulates the type of KYC Document proofing (Address, Identity or Photo) that the Issuer performed for a set of attachments.</li> <li><code>evidence_ref</code>: An array of attachment reference IDs pertaining to the list of evidence used by the Issuer to establish confidence about the Holder.</li> </ul> </li> <li><code>examiner_assertions</code>: An array of inline attachments for Digital Assertions.</li> <li><code>~attach</code>: An array of appended attachments for Original Documents either by-value or by-reference.</li> </ul>"},{"location":"features/0116-evidence-exchange/#examiner-assertions","title":"Examiner Assertions","text":"<p><pre><code>{\n  \"examiner_assertions\": [\n    {\n      \"@id\": \"kycdoc4\",\n      \"approval_timestamp\": \"2017-06-21 09:04:088\",\n      \"description\": \"driver's license\",\n      \"vetting_process\": {\n        \"method\": \"remote\",\n        \"technology\": \"api\"\n      },\n      \"ipsp_did\": \"~3d5nh7900fn4\",\n      \"ipsp_claim\": &lt;base64url(file)&gt;,\n      \"ipsp_claim_sig\": \"3vvvb68b53d5nh7900fn499040cd9e89fg3kkh0f099c0021233728cf67945faf\",\n      \"examinerSignature\": \"f67945faf9e89fg3kkh3vvvb68b53d5nh7900fn499040cd3728c0f099c002123\"\n    }\n  ]\n}\n</code></pre> Description of attributes:</p> <ul> <li><code>approval_timestamp</code>: Date and time associated with when the Issuer approved assertion from IPSP.</li> <li><code>description</code>: A human readable description of the type of document.</li> <li><code>vetting_process</code>: Meta-data that allows the Issuer to specify the type of due diligence performed on the vetted evidence.</li> <li><code>methods</code>: One of two possible identity proofing methods: in-person, or remote.</li> <li><code>technology</code>: Free form description of the approach used to perform the validation. Possible values include but are not limited to: barcode, api, human-visual.</li> <li><code>ipsp_did</code>: The DID of the Identity Proofing Service Provider (IPSP).</li> <li><code>ipsp_claim</code>: Base64 encoding of the evidence that the IPSP used to perform its verification service.</li> <li><code>ipsp_claim_sig</code>: Required RSA/SHA-256 Signature of the IPSP's claim. This is required for downstream processing by the Verifier so that the Holder can demonstrate that the IPSP actually performed a verification service.</li> <li><code>examinerSignature</code>: Required RSA/SHA-256 Signature of the evidence. This is required for downstream processing by the Verifier so that the Holder can demonstrate that the Issuer attests to assessment (assertion) made by the IPSP.</li> </ul>"},{"location":"features/0116-evidence-exchange/#by-value-attachments","title":"By-value Attachments","text":"<pre><code>{\n  \"~attach\": [\n    {\n      \"@id\": \"kycdoc1\",\n      \"mime-type\": \"image/png\",\n      \"filename\": \"nys_dl.png\",\n      \"lastmod_time\": \"2017-06-21 09:04:088\",\n      \"description\": \"driver's license\",\n      \"vetting_process\": {\n        \"method\": \"in-person\",\n        \"technology\": \"barcode\"\n      },\n      \"data\": {\n        \"base64\": &lt;base64url(file)&gt;\n      },\n      \"examinerSignature\": \"f67945faf9e89fg3kkh3vvvb68b53d5nh7900fn499040cd3728c0f099c002123\"\n    },\n    {\n      \"@id\": \"kycdoc2\",\n      \"mime-type\": \"application/pdf\",\n      \"filename\": \"con_ed.pdf\",\n      \"lastmod_time\": \"2017-11-18 10:44:068\",\n      \"description\": \"ACME Electric Utility Bill\",\n      \"vetting_process\": {\n        \"method\": \"in-person\",\n        \"technology\": \"human-visual\"\n      },\n      \"data\": {\n        \"base64\": &lt;base64url(file)&gt;\n      },\n      \"examinerSignature\": \"945faf9e8999040cd3728c0f099c002123f67fg3kkh3vvvb68b53d5nh7900fn4\"\n    },\n    {\n      \"@id\": \"kycdoc3\",\n      \"mime-type\": \"image/jpg\",\n      \"filename\": \"nysccp.jpg\",\n      \"lastmod_time\": \"2015-03-19 14:35:062\",\n      \"description\": \"State Concealed Carry Permit\",\n      \"vetting_process\": {\n        \"method\": \"in-person\",\n        \"technology\": \"barcode\"\n      },\n      \"data\": {\n        \"sha256\": \"1d9eb668b53d99c002123f1ffa4db0cd3728c0f0945faf525c5ee4a2d4289904\",\n        \"base64\": &lt;base64url(file)&gt;\n      },\n      \"examinerSignature\": \"5nh7900fn499040cd3728c0f0945faf9e89kkh3vvvb68b53d99c002123f67fg3\"\n    }\n  ]\n}\n</code></pre> <p>This message adheres to the attribute content formats outlined in the Aries Attachments RFC  with the following additions:</p> <ul> <li><code>mime-type</code>: Describes the MIME type of the attached content. Optional but recommended.</li> <li><code>filename</code>: A hint about the name that might be used if this attachment is persisted as a file. It is not required, and need not be unique. If this field is present and mime-type is not, the extension on the filename may be used to infer a MIME type.</li> <li><code>lastmod_time</code>: A hint about when the content in this attachment was last modified.</li> <li><code>description</code>: A human readable description of the type of document.</li> <li><code>vetting_process</code>: See Examiner Assertions</li> <li><code>sha256</code>: Optional hash of the content. Can be useful as an integrity check by Holder.</li> <li><code>examinerSignature</code>: Required RSA/SHA-256 Signature of the document. This is required for downstream processing by the Verifier so that the Holder can demonstrate that the Issuer was the attesting source of the Original Document.</li> </ul>"},{"location":"features/0116-evidence-exchange/#by-reference-attachments","title":"By-reference Attachments","text":"<pre><code>{\n  \"~attach\": [\n    {\n      \"@id\": \"kycdoc1\",\n      \"mime-type\": \"image/png\",\n      \"filename\": \"nys_dl.png\",\n      \"lastmod_time\": \"2017-06-21 09:04:088\",\n      \"description\": \"driver's license\",\n      \"vetting_process\": {\n        \"method\": \"in-person\",\n        \"technology\": \"barcode\"\n      },\n      \"data\": {\n        \"sha256\": \"1d9eb668b53d99c002123f1ffa4db0cd3728c0f0945faf525c5ee4a2d4289904\",\n        \"links\": [\n          { \"url\": \"https://www.dropbox.com/s/r8rjizriaHw8T79hlidyAfe4DbWFcJYocef5/myDL.png\",\n            \"accesscode\": \"some_secret\"\n          }\n        ]\n      },\n      \"examinerSignature\": \"f67945faf9e89fg3kkh3vvvb68b53d5nh7900fn499040cd3728c0f099c002123\"\n    },\n    {\n      \"@id\": \"kycdoc2\",\n      \"mime-type\": \"application/pdf\",\n      \"filename\": \"con_ed.pdf\",\n      \"lastmod_time\": \"2017-11-18 10:44:068\",\n      \"description\": \"ACME Electric Utility Bill\",\n      \"vetting_process\": {\n        \"method\": \"remote\",\n        \"technology\": \"api\"\n      },\n      \"data\": {\n        \"sha256\": \"1d4db525c5ee4a2d42899040cd3728c0f0945faf9eb668b53d99c002123f1ffa\",\n        \"links\": [\n          { \"url\": \"https://mySSIAgent.com/w8T7AfkeyJYo4DbWFcmyocef5eyH\",\n            \"accesscode\": \"some_secret\"\n          }\n        ]\n      },\n      \"examinerSignature\": \"945faf9e8999040cd3728c0f099c002123f67fg3kkh3vvvb68b53d5nh7900fn4\"\n    },\n    {\n      \"@id\": \"kycdoc3\",\n      \"mime-type\": \"image/jpg\",\n      \"filename\": \"nysccp.jpg\",\n      \"lastmod_time\": \"2015-03-19 14:35:062\",\n      \"description\": \"State Concealed Carry Permit\",\n      \"vetting_process\": {\n        \"method\": \"in-person\",\n        \"technology\": \"barcode\"\n      },\n      \"data\": {\n        \"sha256\": \"b53d99c002123f1ffa2d42899040cd3728c0f0945fa1d4db525c5ee4af9eb668\",\n        \"links\": [\n          { \"url\": \"https://myssiAgent.com/mykeyoyHw8T7Afe4DbWFcJYocef5\",\n            \"accesscode\": null\n          }\n        ]\n      },\n      \"examinerSignature\": \"5nh7900fn499040cd3728c0f0945faf9e89kkh3vvvb68b53d99c002123f67fg3\"\n    }\n  ]\n}\n</code></pre> <p>This message adheres to the attribute content formats outlined in the Aries Attachments RFC  and builds on the By Value Attachments with the following additions:</p> <ul> <li><code>links</code>: A list of zero or more locations at which the content may be fetched.</li> <li><code>url</code>: Link to the external document.</li> <li><code>accesscode</code>: If required, the passcode need to authenticate access to the url.</li> </ul> <p>Upon completion of the Evidence Request and Response exchange, the Holder's Agent is now able to present any Verifier that has accepted a specific Issuer credential with the supporting evidence from the Issuer. This evidence, depending on the Holder's preferences may be direct or via a link to an external resource. For example, regardless of the delivery method used between the Issuer and Holder, the Holder's Agent may decide to fetch all documents and store them itself and then provide Verifiers with by-reference access upon request.</p>"},{"location":"features/0116-evidence-exchange/#evidence-access-request-message","title":"Evidence Access Request Message","text":"<p>Upon the successful processing of a credential proof presentation message, a Verifier may desire to request supporting evidence for the processed credential. This <code>evidence_access_request</code> message is built by the Verifier and sent to the  Holder's agent. Similar to the <code>request_evidence</code> message, the Verifier may use this message to get an update for new and existing credentials associated with the Holder. The intent of this message is for the Verifier to establish trust by obtaining a copy of the available evidence and performing the necessary content validation.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/evidence_exchange/1.0/evidence_access_request\",\n  \"@id\": \"7c3f991836-4ed5-f50e-7207-718e6151a389\",\n  \"for\": \"did:peer:1-F1220479cbc07c3f991725836a3aa2a581ca2029198aa420b9d99bc0e131d9f3e2cbe\",\n  \"as_of_time\": \"2019-07-23 18:05:06.123Z\",\n  \"credentials\": [\n      { \"@id\": \"cred-001\", \"issuerDID\": \"~BzCbsNYhMrjHiqZD\" },\n      { \"@id\": \"cred-002\", \"issuerDID\": \"~BzCbsNYhMrjHiqZD\" }\n  ]\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>credentials</code>: A list of credential IDs that the Verifier desires proof of evidence.</li> <li><code>@id</code>: Credential ID derived from a validated credential exchange (proof presentment).</li> <li><code>issuerDID</code>: The public DID of the Issuer that issued the credential represented by the associated ID. This DID is derived from the credential validation process.</li> </ul> <p></p> <p>This protocol is intended to be flexible and applicable to a variety of use cases. While our discussion has circulated around the use of the protocol as follow-up to the processing of a credential proof presentment flow, the fact is that the protocol can be used at any point after a Pair-wise DID Exchange has been successfully established and is therefore in the complete state as defined by the DID Exchange Protocol. An <code>IssuerDID</code> (or DID of the an entity that is one of the two parties in a private pair-wise relationship) is assumed to be known under all possible conditions once the relationship is in the complete state.</p>"},{"location":"features/0116-evidence-exchange/#evidence-access-response-message","title":"Evidence Access Response Message","text":"<p>This message is required for a Holder Agent in response to an <code>evidence_access_request</code> message. The format of the <code>~attach</code> attribute will be determined by the storage management preferences of the Holder's Agent. As such the Holder can respond by-value or by-reference. To build the response, the Holder will validate that the supplied Issuer DID corresponds to the credential represented by the supplied ID. If the Issuer relied on one or more IPSPs during the Identity Proofing Process, then this message will also include an inline attachment using the <code>examiner_assertions</code> attribute. Upon successful processing of a <code>evidence_access_response</code> message, the Verifier will store evidence details in its system of record.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/evidence_exchange/1.0/evidence_access_response\",\n  \"@id\": \"1517207d-f50e-4ed5-a389-6a4986d718e6\",\n  \"~thread\": { \"thid\": \"7c3f991836-4ed5-f50e-7207-718e6151a389\" },\n  \"for\": \"did:peer:1-F1220479cbc07c3f991725836a3aa2a581ca2029198aa420b9d99bc0e131d9f3e2cbe\",\n  \"as_of_time\": \"2019-07-23 18:05:06.123Z\",\n  \"credentials\": [\n    { \"@id\": \"cred-001\",\n      \"evidence\": [\n        {\"evidence_type\": \"Address\", \"evidence_ref\": [\"#kycdoc1\", \"#kycdoc4\"]},\n        {\"evidence_type\": \"Identity\", \"evidence_ref\": [\"#kycdoc2\"]},\n        {\"evidence_type\": \"Photo\", \"evidence_ref\": null}\n      ]\n    },\n    { \"@id\": \"cred-002\",\n      \"evidence\": [\n        {\"evidence_type\": \"Address\", \"evidence_ref\": [\"#kycdoc1\",\"#kycdoc3\"]},\n        {\"evidence_type\": \"Identity\", \"evidence_ref\": [\"#kycdoc3\"]},\n        {\"evidence_type\": \"Photo\", \"evidence_ref\": [\"#kycdoc1\"]}\n      ]\n    }\n  ],\n  \"examiner_assertions\": [ ... ],\n  \"~attach\": [ ...\n  ]\n}\n</code></pre> <p>This message adheres to the attribute content formats outlined in the Aries Attachments RFC  and leverages the same Evidence Response Message attribute descriptions.</p>"},{"location":"features/0116-evidence-exchange/#reference","title":"Reference","text":"<ul> <li>Centralized Shared-KYC Trends</li> <li>R3 KYC Registry Dutch Banks</li> <li>Canadian Banks</li> <li>Deutsche Bank and HSBC Shared-KYC POC</li> <li>Sample KYC Documentation requirements</li> <li>NYS Document Guide for Identification Services</li> <li>TSA Travelers Guide</li> <li>USA Identity Documents</li> <li>Aadhaar KYC Concepts</li> </ul>"},{"location":"features/0116-evidence-exchange/#drawbacks","title":"Drawbacks","text":"<p>This protocol does not vary much from a generic document exchange protocol. It can be argued that a special KYC Document exchange protocol is not needed. However, given the emphasis placed on KYC compliance during the early days of DIDComm adoption, we want to make sure that any special cases are addressed upfront so that we avoid adoption derailment factors.</p>"},{"location":"features/0116-evidence-exchange/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>As noted in the references section, there are a number of trending KYC Document proofing options that are being considered. Many leverage the notion of a centralized blockchain ledger for sharing documents. This effectively places control outside of the Holder and enables the sharing of documents in a B2B manner. Such approaches do not capitalize on the advantages of Pair-wise Peer DIDs.</p>"},{"location":"features/0116-evidence-exchange/#prior-art","title":"Prior art","text":"<p>This protocol builds on the foundational capabilities of DIDComm messages, most notable being the attachment decorator within DIDComm.</p>"},{"location":"features/0116-evidence-exchange/#unresolved-questions","title":"Unresolved questions","text":"<ol> <li>Should this be a separate protocol or an update to issuer-credential?</li> <li>What is the best way to handle access control for by-reference attachments?</li> <li>Are there best practices to be considered for when/why/how a Holder's Agent should store and manage attachments?</li> <li>Can this protocol help bootstrap a prototype for a Digital Notary and thereby demonstrate to the broader ecosystem the unnecessary attention being placed on alternative domain specific credential solutions like ISO-18013-5(mDL)?</li> </ol>"},{"location":"features/0116-evidence-exchange/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/","title":"Decentralized Digital Notary","text":""},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#preface","title":"Preface","text":"<p>The intent of this document is to describe the concepts of a Decentralized Digital Notary with respect to the bootstrapping of the decentralized identity ecosystem and to demonstrate using example user stories<sup>1</sup> the applicability of the Evidence Exchange Protocol.  </p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#overview","title":"Overview","text":""},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#problem-statement","title":"Problem Statement","text":"<p>How do we bootstrap the digital credential ecosystem when many of the issuing institutions responsible for foundational credentials (i.e.: brith certificate, drivers license, etc) tend to be laggards<sup>2</sup> when it comes to the adoption of emerging technology? What if we did not need to rely on these issuing institutions and instead leveraged the attestations of trusted third parties?</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#concept","title":"Concept","text":"<p>During the identity verification process, an entity may require access to the genesis documents from the Issuers of Origination before issuing credentials. We see such requirements in some of the routine identity instrument interactions of our daily lives such as obtaining a Driver's License or opening a Bank Account.</p> <p></p> <p>We assume that government agencies such and the DMV (drivers license) and Vital Records (brith certificate) will not be early adopters of digital credentials yet their associated Tier 1 Proofs are critical to the the creation of a network effect for the digital credential ecosystem.</p> <p>We therefore need a forcing function that will disrupt behavior. Image a trusted business entity, a Decentralized Digital Notary (DDN), that would take the responsibility of vouching for the existence of Original Documents (or Digital Assertions) and have the certitude to issue verifiable credentials attesting to personal data claims made by the Issuer of Origination.</p> <p></p> <p>Today (blue shaded activity), an individual receives Original Documents from issuing institutions and presents these as evidence to each Verifier. Moving forward (beige shaded activity), as a wide range of businesses consider acting as DDNs, our reliance on Issuers of Origination to be the on-ramps for an individuals digital identity experience diminishes. Overtime, our dependency on the proactive nature of such institutions becomes mute. Furthermore, the more successful DDNs become the more reactionary the laggards will need to be to protect their value in the ecosystem.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#applicable-businesses","title":"Applicable Businesses","text":"<p>Any entity that has the breath and reach to connect with consumers at scale would be an ideal candidate for the role of a DDN. Some examples include:</p> <ul> <li>Retail Banks</li> <li>Credit Unions</li> <li>Regional Rural Banks (India)</li> <li>Mobile Field Agents</li> <li>Background Screening Service Providers</li> </ul> <p>The monetization opportunities for such businesses will also vary. The linkages between proof-of-identity and proof-of-value can be achieved in several manners:</p> <ol> <li>Individual pays for issuance of certificates</li> <li>Verifier pays the underwriter with a payment instrument (i.e.: fiat or cryptocurrency). The payment is for the service of underwriting the screening of an individual so that the Verifier does not have to do it.\u2028</li> </ol>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#stories","title":"Stories","text":"<p>Presented herein are a series of user stories that incorporate the concepts of a DDN and the ability of a verifier to gain access to Issuer vetted Identity Evidence using the Evidence Exchange Protocol.</p> <p>The stories focus on the daily lifecycle activities of a two individuals who needs to open a brokerage account and/or update a Life Insurance Policy.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#persona","title":"Persona","text":"Name Role Eric An individual that desires to open a brokerage account. Stacy An individual that desires to open a brokerage account and also apply a Life Insurance Policy. Retail Bank DDN (Issuer) Thomas Notary at the Retail Bank familiar with the DDN Process. Brokerage Firm Verifier Dropbox Document Management Service iCertitude A hypothetical IPSP that provides a mobile convenient identity verification service that is fast, trusted and  reliable. Financial Cooperative A small local financial institution that is owned and operated by its members. It has positioned itself as a DDN (Issuer) by OEMing the iCertitude platform."},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#identity-proofing-examination-process","title":"Identity Proofing (Examination) Process","text":""},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#financial-cooperative-ddn-awareness","title":"Financial Cooperative (DDN Awareness)","text":"<p>Eric is a member of his neighborhood Financial Cooperative. He received an email notification that as a new member benefit, the bank is now offering members with the ability to begin their digital identity journey. Eric is given access to literature describing the extend to the bank's offering and a video of the process for how to get started. Eric watches the video, reads the online material and decides to take advantage of the banks offer.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#financial-cooperative-3rd-party-remote-vetting-process","title":"Financial Cooperative (3<sup>rd</sup> Party Remote Vetting Process)","text":"<p>Following his banks instructions, Eric downloads, installs and configures a Wallet App on his smartphone from the list of apps recommended by the bank. He also downloads the bank's iCertitude app. He uses the iCertitude Mobile app to step through a series of ID Proofing activities that allow the bank to establish a NIST IAL3 assurance rating. These steps include the scanning or some biometrics as well as his plastic drivers license. Upon completion of these activities, which are all performed using his smartphone without any human interactions with the bank, Eric receives a invite in his Wallet App to accept a new verifiable credential which is referred to as a Basic Assurance Credential. Eric opens the Wallet App, accepts the new credential and inspects it.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#retail-bank-ddn-awareness","title":"Retail Bank (DDN Awareness)","text":"<p>Stacy is a member of her neighborhood Retail Bank. She received an email notification that as a new member benefit, the bank is now offering members with the ability to begin their digital identity journey. Stacey is given access to literature describing the extend to the bank's offering and a video of the process for how to get started. Stacey watches the video, reads the online material and decides to make an appointment with her local bank notary and fill out the preliminary online forms.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#retail-bank-paper-vetting-process","title":"Retail Bank (Paper Vetting Process)","text":"<p>Stacey attends her appointment with Thomas. She came prepared to request digital credentials for the following Official Documents: SSN, Birth Certificate, proof of employment (paystub) and proof of address (utility bill). Thomas explains to Stacey that given the types of KYC Documents she desires to be digitally notarized, bank policy is to issue a single digital credential that attests to all the personal data she is prepared to present. The bank refers to this verifiable credential as the Basic KYC Credential and they use a common schema that is used by many DDNs in the Sovrin ecosystem.</p> <p>Note: This story depicts one approach. Clearly, the bank's policy could be to have a schema and credential for each Original Document.  </p> <p>Stacy supplied Thomas with the paper based credentials for each of the aforementioned documents. Thomas scans each document and performs the necessary vetting process according to business policies. Thomas explains that while the bank can issue Stacey her new digital credential for a fee of $10 USD renewable annually, access to her scanned documents would only be possible if she opts-in to the digital document management service on her online banking account. Through this support she is able to provide digital access to the scanned copies of her paper credentials that were vetted by the bank. Stacey agrees to opt-in.</p> <p>While Stacey is waiting for her documents to be digitally notarized, she downloads, installs and configures a Wallet App on her smartphone from the list of apps recommended by the bank. Upon completion of the vetting process, Thomas returns all Original Documents back to Stacey and explains to her where she can now request the delivery of her new digital credential in her online account. Stacey leaves the bank with her first digital credential on her device.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#retail-bank-hybrid-vetting-process","title":"Retail Bank (Hybrid Vetting Process)","text":"<p>During Stacey's preparation activity when she was filling out the  preliminary online forms before her appointment with Thomas, she remembered that she had scanned her recent proof of employment (paystub) and proof of address (utility bill) at home and stored them on her Dropbox account. She decides to use the section of the form to grant the bank access (url and password) to these files. When she attends her appointment with Thomas, the meeting is altered only by the fact that she has limited her requirement of physical document presentment. However, Thomas does explain to her that bank policy is that the bank does not use remote links in their digital document management service. Instead, the bank uses the Dropbox link to obtain a copy, perform the vetting process and then store the copy in-house and allow Stacey to gain access to a link for the document stored at the bank.  </p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#credential-management","title":"Credential Management","text":"<p>Later that evening, Stacey decides to explore her new Digital Credential features within her online bank account. She sees that she has the ability to request access to the vetted resources the bank has used to vouch for her digital identity. She opens her Wallet App and sends a <code>evidence_request</code> message to the bank. Within a few seconds she receives and processes the bank's <code>evidence_response</code> message. Her Wallet App allows her to view the evidence available to her:</p> Issuer Credential Evidence Type Original Document Retail Bank Basic KYC Credential Address Utility Bill Retail Bank Basic KYC Credential Address Employment PayStub Retail Bank Basic KYC Credential Identity SSN Retail Bank Basic KYC Credential Identity Birth Certificate Retail Bank Basic KYC Credential Photo Bank Member Photo <p>Recalling his review of the bank's new digital identity journey benefits, Eric decides to use his Wallet App to request access to the vetted resources the bank used to vouch for his new Basic Assurance Credential. He uses the Wallet App to initiate a <code>evidence_request</code> and <code>evidence_response</code> message flow.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#verification-process","title":"Verification Process","text":""},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#brokerage-account-digital-assertion-evidence","title":"Brokerage Account (Digital Assertion Evidence)","text":"<p>Eric decides to open a new brokerage account with a local Brokerage Firm. He opens the firms account registration page using his laptop web browser. The firm allows him to establish a new account and obtain a brokerage member credential if he can provide digitally verifiable proof of identity and address. Eric clicks to begin the onboarding process. He scans a QRCode using his Wallet App and accepts a connection request from the firm. He then receives a proof request from the firm and his Wallet App parsing the request and suggests he can respond using attributes from his Basic Assurance Credential. He responds to the proof request. Upon verification of his proof response, the firm sends Eric an offer for a Brokerage Membership Credential which he accepts. The firm also sends him an <code>evidence_access_request</code> and an explanation that the firm's policy for regulatory reasons is to obtain access to proof that the proper due-diligence was performed for Address, Identity and Photo. Eric uses his Wallet App to instruct his Cloud Agent to send an <code>evidence_access_response</code>. Upon processing of Eric's response, the firm establishes a Trust Score based on their policy for evidence based only on Digital Assertions and Remote Proofing processes.  </p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#brokerage-account-document-evidence","title":"Brokerage Account (Document Evidence)","text":"<p>Stacey decides she will open a new brokerage account with a local Brokerage Firm. She opens the firms account registration page using her laptop web browser. The firm allows her to establish a new account and obtain a brokerage member credential if she can provide digitally verifiable proof of identity, address and employment. Stacey clicks to begin the onboarding process. She scans a QRCode using her Wallet App and accepts a connection request from the firm. Using her Wallet App she responds to the proof request using digital credentials from her employer and her Retail Bank. Upon verification of her proof response, the firm sends Stacey an offer for a Brokerage Membership Credential which she accepts. The firm also sends her an <code>evidence_access_request</code> and an explanation that the firm's policy for regulatory reasons is to obtain access to the proof that the proper due-diligence was performed for Address, Identity, Photo and Employment. Stacey uses her Wallet App to instruct her Cloud Agent to send an <code>evidence_access_response</code>.  Upon processing of Stacey's response, the firm establishes a Trust Score based on their policy for evidence based on Original Documents and In-person Proofing processes.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#life-insurance-policy-didcomm-doc-sharing","title":"Life Insurance Policy (DIDComm Doc Sharing)","text":"<p>Stacey receives notification from her Insurance Company that they require an update to her life insurance policy account. The firm has undertaken a digital transformation strategy that impacts her 15yr old account. She has been given access to a new online portal and the choices on how to supply digital copies of her SSN and Birth Certificate. Stacey is too busy to take time to visit the Insurance Company to provide Original Documents for their vetting and digitization. She decides to submit her notarized digital copies.  She opens the companies account portal page using her laptop web browser. Stacey registers, signs in and scans a QRCode using her Wallet App. She accepts a connection request from the firm. She then responds to an <code>evidence_access_request</code> for proof of that KYC due-diligence was performed for Identity and Photo. Stacey uses her Wallet App to instruct her Cloud Agent to send an <code>evidence_access_response</code>.</p>"},{"location":"features/0116-evidence-exchange/digital_notary_usecase/#commentary","title":"Commentary","text":"<ol> <li>The concepts of a digital notary can be applied today in application domains such as (but not limited to) indirect auto lending and title management (auto, recreational vehicle, etc).</li> <li>Since 2015, AAMVA in conjunction with the ISO JTC1/SC27/WG10 18013-5 mDL Team has been working on a single credential solution for cross jurisdictional use amongst DMVs. This public sector activity is a key source of IAM industry motivation for alternative solutions to Credential Lifecycle Management. Government agencies will eventually need to address discussions around technical debit investments and defacto open source standards.</li> </ol>"},{"location":"features/0116-evidence-exchange/eep_glossary/","title":"Evidence Exchange Protocol Glossary","text":"<p>The following terms are either derived from terminology found in the NIST 800-63A Digital Identity Guidelines or introduced to help reinforce protocol concepts and associated use cases.</p> Term Definition Credential Service Provider (CSP) A trusted entity that issues verifiable credentials credentials. Either an Issuer of Origination for an Original Document or an Issuer of a Derived Credential. A DDN is an example of a CSP that issues Derived Credential. Decentralized Digital Notary (DDN) A trusted third party that enables digital interactions between Holders and Verifiers. As an issuer of digitally verifiable credentials, it creates permanent evidence that an Original Document existed in a certain form at a particular point in time. This role will be especially important to address scalability and the bootstrapping of the decentralized identity ecosystem since many Issuers of Origination may be laggards. DDN Insurer An entity (party) in an insurance contract that underwrites insurance risks associated with the activities of a DDN. This includes a willingness to pay compensation for any negligence on the part of the DDN for failure to perform the necessary due-diligence associated with the examination and vetting of Original Documents. Derived Credential An issued verifiable credential based on an identity proofing process over Original Documents or other Derived Credentials. Digital Assertion A non-physical (digital) form of evidence. Often in the form of a Digital Signature. A CSP may leverage the services of an IPSP and may then require the IPSP to digitally sign the content that is the subject of the assertion. Original Document Any issued artifact that satisfies the Original-Document Rule in accordance with principle of evidence law. The original artifact may be in writing or a mechanical, electronic form of publication. Such a document may also be referred to as a Foundational Document. Identity Evidence Information or documentation provided by the Holder to support the issuance of an Original Document. Identity evidence may be physical (e.g. a driver license) or Digital Assertion Identity Instrument Digital or physical, paper or plastic renderings of some subset of our personal data as defined by the providers of the instruments. The traditional physical object is an identification card. Many physical identity instruments contain public and encoded information about an entity. The encoded information, which is often stored using machine readable technologies like magnetic strips or barcodes, represents another rendering format of an individual\u2019s personal data. Digital identity instruments, pertain to an individual\u2019s personal data in a form that can be processed by a software program. Identity Proofing The process by which a CSP collects, validates, and verifies Identity Evidence. This process yields the attestations (claims of confidence) by which a CSP is then able to use to issue a Verifiable Credential. The sole objective of this process is to ensure the Holder of Identity Evidence is who they claim to be with a stated level of certitude. Identity Proofing Inquiry The objectives of an identity verification exercise. Some inquiries are focused topics such as address verification while others may be on achievement. Identity Proofing Service Provider (IPSP) A remote 3<sup>rd</sup> party service provider that carries out one or more aspects of an Identity Proofing process. Issuer of Origination The entity (business, organization, individual or government) that is the original publisher of an Original Document. Mobile Field Agents Location-based service providers that allow agencies to bring their services to remote (rural) customers. Tier 1 Proofs A category of foundational credentials (Original Documents) that are often required to prove identity and address during KYC or onboarding processes. Trust Framework Certification Authority An entity that adheres to a governance framework for a specific ecosystem and is responsible for overseeing and auditing the Level of Assurance a DDN (Relying Party) has within the ecosystem. Verifiable Credential A digital credential that is compliant with the W3C Verifiable Credential Specification."},{"location":"features/0124-did-resolution-protocol/","title":"Aries RFC 0124: DID Resolution Protocol 0.9","text":"<ul> <li>Authors: Markus Sabadello, Luis G\u00f3mez Alonso</li> <li>Status: PROPOSED</li> <li>Since: 2019-07-13</li> <li>Status Note: Not implemented, but has been discussed as part of the Aries DID Resolution work.</li> <li>Start Date: 2019-07-08</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0124-did-resolution-protocol/#summary","title":"Summary","text":"<p>Describes a DIDComm request-response protocol that can send a request to a remote DID Resolver to resolve DIDs and dereference DID URLs.</p>"},{"location":"features/0124-did-resolution-protocol/#motivation","title":"Motivation","text":"<p>DID Resolution is an important feature of Aries. It is a prerequisite for the <code>unpack()</code> function in DIDComm, especially in Cross-Domain Messaging, since cryptographic keys must be discovered from DIDs in order to enable trusted communication between the agents associated with DIDs. DID Resolution is also required for other operations, e.g. for verifying credentials or for discovering DIDComm service endpoints.</p> <p>Ideally, DID Resolution should be implemented as a local API (TODO: link to other RFC?). In some cases however, the DID Resolution function may be provided by a remote service. This RFC describes a DIDComm request-response protocol for such a remote DID Resolver.</p>"},{"location":"features/0124-did-resolution-protocol/#tutorial","title":"Tutorial","text":"<p>DID Resolution is a function that returns a DID Document for a DID. This function can be accessed via \"local\" bindings (e.g. SDK calls, command line tools) or \"remote\" bindings (e.g. HTTP(S), DIDComm).</p> <p>A DID Resolver MAY invoke another DID Resolver in order to delegate (part of) the DID Resolution and DID URL Dereferencing algorithms. For example, a DID Resolver may be invoked via a \"local\" binding (such as an Aries library call), which in turn invokes another DID Resolver via a \"remote\" binding (such as HTTP(S) or DIDComm).</p> <p></p>"},{"location":"features/0124-did-resolution-protocol/#name-and-version","title":"Name and Version","text":"<p>This defines the <code>did_resolution</code> protocol, version 0.1, as identified by the following PIURI:</p> <pre><code>https://didcomm.org/did_resolution/0.1\n</code></pre>"},{"location":"features/0124-did-resolution-protocol/#key-concepts","title":"Key Concepts","text":"<p>DID Resolution is the process of obtaining a DID Document for a given DID. This is one of four required operations that can be performed on any DID (\"Read\"; the other ones being \"Create\", \"Update\", and \"Deactivate\"). The details of these operations differ depending on the DID method. Building on top of DID Resolution, DID URL Dereferencing is the process of obtaining a resource for a given DID URL. Software and/or hardware that is able to execute these processes is called a DID Resolver.</p> <ul> <li>DID Resolver: Software and/or hardware that is capable of DID Resolution and optionally DID URL Dereferencing for at least one DID method.</li> <li>DID Resolution: An algorithm that takes a DID plus additional options as input and produces a DID Document or a DID Resolution Result as output. This algorithm relies on the \"Read\" operation of the applicable DID method.</li> <li>DID URL Dereferencing: An algorithm that takes a DID URL plus additional options as input and produces a DID Document, a DID Resolution Result, or various other types of resources as output. This algorithm relies on DID Resolution.</li> <li>DID Method: A definition of how a specific DID scheme can be implemented on a specific distributed ledger or network, including the precise method(s) by which DIDs are resolved and deactivated and DID Documents are written and updated.</li> </ul>"},{"location":"features/0124-did-resolution-protocol/#roles","title":"Roles","text":"<p>There are two parties and two roles (one for each party) in the <code>did_resolution</code> protocol: A <code>requester</code> and <code>resolver</code>.</p> <p>The <code>requester</code> wishes to resolve DIDs or dereference DID URLs.</p> <p>The\u00a0<code>resolver</code> conforms with the DID Resolution Specification. It is capable of resolving DIDs for at least one DID method.</p>"},{"location":"features/0124-did-resolution-protocol/#states","title":"States","text":""},{"location":"features/0124-did-resolution-protocol/#states-for-requester-role","title":"States for <code>requester</code> role","text":"EVENTS: send <code>resolve</code> receive <code>resolve_result</code> STATES preparing-request transition to \"awaiting-response\" different interaction awaiting-response impossible transition to \"done\" done"},{"location":"features/0124-did-resolution-protocol/#states-for-resolver-role","title":"States for <code>resolver</code> role","text":"EVENTS: receive <code>resolve</code> send <code>resolve_result</code> STATES awaiting-request transition to \"resolving\" impossible resolving new interaction transition to \"done\" done"},{"location":"features/0124-did-resolution-protocol/#states-for-requester-role-in-a-failure-scenario","title":"States for <code>requester</code> role in a failure scenario","text":"EVENTS: send <code>resolve</code> receive <code>resolve_result</code> STATES preparing-request transition to \"awaiting-response\" different interaction awaiting-response impossible error reporting problem reported"},{"location":"features/0124-did-resolution-protocol/#states-for-resolver-role-in-a-failure-scenario","title":"States for <code>resolver</code> role in a failure scenario","text":"EVENTS: receive <code>resolve</code> send <code>resolve_result</code> STATES awaiting-request transition to \"resolving\" impossible resolving new interaction error reporting problem reported"},{"location":"features/0124-did-resolution-protocol/#messages","title":"Messages","text":"<p>All messages in this protocol are part of the \"did_resolution 0.1\" message family uniquely identified by this DID reference: <code>https://didcomm.org/did_resolution/0.1</code></p>"},{"location":"features/0124-did-resolution-protocol/#resolve-message","title":"<code>resolve</code> message","text":"<p>The protocol begins when the <code>requester</code> sends a <code>resolve</code> message to the <code>resolver</code>. It looks like this:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/did_resolution/0.1/resolve\",\n    \"@id\": \"xhqMoTXfqhvAgtYxUSfaxbSiqWke9t\",\n    \"did\": \"did:sov:WRfXPg8dantKVubE3HX8pw\",\n    \"input_options\": {\n        \"result_type\": \"did-document\",\n        \"no_cache\": false\n    }\n}\n</code></pre> <p><code>@id</code> is required here, as it establishes a message thread that makes it possible to connect a subsequent response to this request.</p> <p><code>did</code> is required.</p> <p><code>input_options</code> is optional.</p> <p>For further details on the <code>did</code> and <code>input_options</code> fields, see Resolving a DID in the DID Resolution Spec.</p>"},{"location":"features/0124-did-resolution-protocol/#resolve_result-message","title":"<code>resolve_result</code> message","text":"<p>The <code>resolve_result</code> is the only allowed direct response to the <code>resolve</code> message. It represents the result of the DID Resolution function and contains a DID Document.</p> <p>It looks like this:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/did_resolution/0.1/resolve_result\",\n    \"~thread\": { \"thid\": \"xhqMoTXfqhvAgtYxUSfaxbSiqWke9t\" },\n    \"did_document\": {\n        \"@context\": \"https://w3id.org/did/v0.11\",\n        \"id\": \"did:sov:WRfXPg8dantKVubE3HX8pw\",\n        \"service\": [{\n            \"type\": \"did-communication\",\n            \"serviceEndpoint\": \"https://agent.example.com/\"\n        }],\n        \"publicKey\": [{\n            \"id\": \"did:sov:WRfXPg8dantKVubE3HX8pw#key-1\",\n            \"type\": \"Ed25519VerificationKey2018\",\n            \"publicKeyBase58\": \"~P7F3BNs5VmQ6eVpwkNKJ5D\"\n        }],\n        \"authentication\": [\"did:sov:WRfXPg8dantKVubE3HX8pw#key-1\"]\n    }\n}\n</code></pre> <p>If the <code>input_options</code> field of the <code>resolve</code> message contains an entry <code>result_type</code> with value <code>resolution-result</code>, then the <code>resolve_result</code> message contains a more extensive DID Resolution Result, which includes a DID Document plus additional metadata:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/did_resolution/0.1/resolve_result\",\n    \"~thread\": { \"thid\": \"xhqMoTXfqhvAgtYxUSfaxbSiqWke9t\" },\n    \"did_document\": {\n        \"@context\": \"https://w3id.org/did/v0.11\",\n        \"id\": \"did:sov:WRfXPg8dantKVubE3HX8pw\",\n        \"service\": [{\n            \"type\": \"did-communication\",\n            \"serviceEndpoint\": \"https://agent.example.com/\"\n        }],\n        \"publicKey\": [{\n            \"id\": \"did:sov:WRfXPg8dantKVubE3HX8pw#key-1\",\n            \"type\": \"Ed25519VerificationKey2018\",\n            \"publicKeyBase58\": \"~P7F3BNs5VmQ6eVpwkNKJ5D\"\n        }],\n        \"authentication\": [\"did:sov:WRfXPg8dantKVubE3HX8pw#key-1\"]\n    },\n    \"resolver_metadata\": {\n        \"driverId\": \"did:sov\",\n        \"driver\": \"HttpDriver\",\n        \"retrieved\": \"2019-07-09T19:73:24Z\",\n        \"duration\": 1015\n    },\n    \"method_metadata\": {\n        \"nymResponse\": { ... },\n        \"attrResponse\": { ... }\n    }\n}\n</code></pre>"},{"location":"features/0124-did-resolution-protocol/#problem-report-failure-message","title":"<code>problem-report</code> failure message","text":"<p>The <code>resolve_result</code> will also report failure messages in case of impossibility to resolve a DID. It represents the problem report indicating that the resolver could not resolve the DID, and the reason of the failure. It looks like this:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/did_resolution/0.1/resolve_result\",\n    \"~thread\": { \"thid\": \"xhqMoTXfqhvAgtYxUSfaxbSiqWke9t\" },\n    \"explain_ltxt\": \"Could not resolve DID did:sov:WRfXPg8dantKVubE3HX8pw not found by resolver xxx\",\n        ...\n}\n</code></pre>"},{"location":"features/0124-did-resolution-protocol/#reference","title":"Reference","text":"<ul> <li>Aries DID Resolution</li> <li>DID Spec</li> <li>DID Resolution Spec</li> <li>Peer DID Method</li> <li>Universal Resolver</li> </ul>"},{"location":"features/0124-did-resolution-protocol/#messages_1","title":"Messages","text":"<p>In the future, additional messages <code>dereference</code> and <code>dereference_result</code> may be defined in addition to <code>resolve</code> and <code>resolve_result</code> (see Unresolved questions).</p>"},{"location":"features/0124-did-resolution-protocol/#message-catalog","title":"Message Catalog","text":"<p>Status and error codes will be inherited from the DID Resolution Spec.</p>"},{"location":"features/0124-did-resolution-protocol/#drawbacks","title":"Drawbacks","text":"<p>Using a remote DID Resolver should only be considered a fallback when a local DID Resolver cannot be used. Relying on a remote DID Resolver raises the question of who operates it, can you trust its responses, and can MITM and other attacks occur? There is essentially a chicken-and-egg problem insofar as the purpose of DID Resolution is to discover metadata needed for trustable interaction with an entity, but the precondition is that interation with a DID Resolver must itself be trustable.</p> <p>Furthermore, the use of remote DID Resolvers may introduce central bottlenecks and undermine important design principles such as decentralization.</p> <p>See Binding Architectures and w3c-ccg/did-resolution#28 for additional thoughts.</p> <p>The security and trust issues may outweigh the benefits. Defining and implementing this RFC may lead developers to underestimate or ignore these issues associated with remote DID Resolvers.</p>"},{"location":"features/0124-did-resolution-protocol/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Despite the drawbacks of remote DID Resolvers, in some situations they can be useful, for example to support DID methods that are hard to implement in local agents with limited hard- and software capabilities.</p> <p>A special case of remote DID Resolvers occurs in the case of the Peer DID Method, where each party of a relationship essentially acts as a remote DID Resolver for other parties, i.e. each party fulfills both the <code>requester</code> and <code>resolver</code> roles defined in this RFC.</p> <p>An alternative to the DIDComm binding defined by this RFC is an HTTP(S) binding, which is defined by the DID Resolution Spec.</p>"},{"location":"features/0124-did-resolution-protocol/#prior-art","title":"Prior art","text":"<p>Resolution and dereferencing of identifiers have always played a key role in digital identity infrastructure.</p> <ul> <li>Yadis was an early discovery protocol.</li> <li>XRI Resolution defined the XRDS format and  a protocol for discovering them from HTTP(S) URIs and XRIs. The XRDS format later evolved into XRD and JRD.</li> <li>WebFinger is an HTTP-based protocol for discovering JRD documents about identifiers.</li> </ul>"},{"location":"features/0124-did-resolution-protocol/#unresolved-questions","title":"Unresolved questions","text":"<p>This RFC inherits a long list of unresolved questions and issues that currently exist in the DID Resolution Spec.</p> <p>We need to decide whether the DID Resolution and DID URL Dereferencing functions (<code>resolve()</code> and <code>dereference()</code>) should be exposed as the same message type, or as two different message types (including two different responses).</p>"},{"location":"features/0124-did-resolution-protocol/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0160-connection-protocol/","title":"0160: Connection Protocol","text":"<ul> <li>Authors: Ryan West, Daniel Bluhm, Matthew Hailstone, Stephen Curran, Sam Curren</li> <li>Status: ADOPTED (But should move to deprecated)</li> <li>Since: 2019-08-06</li> <li>Status Note: This is the protocol with existing uses. It is expected that RFC 0023 DID Exchange will replace this protocol.</li> <li>Supersedes: HIPE 0031 - Connection Protocol</li> <li>Start Date: 2018-06-29</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"features/0160-connection-protocol/#summary","title":"Summary","text":"<p>This RFC describes the protocol to establish connections between agents. </p>"},{"location":"features/0160-connection-protocol/#motivation","title":"Motivation","text":"<p>Indy agent developers want to create agents that are able to establish connections with each other and exchange secure information over those connections. For this to happen there must be a clear connection protocol.</p>"},{"location":"features/0160-connection-protocol/#tutorial","title":"Tutorial","text":"<p>We will explain how a connection is established, with the roles, states, and messages required.</p>"},{"location":"features/0160-connection-protocol/#roles","title":"Roles","text":"<p>Connection uses two roles: inviter and invitee.</p> <p>The inviter is the party that initiates the protocol with an <code>invitation</code> message. This party must already have an agent and be capable of creating DIDs and endpoints at which they are prepared to interact. It is desirable but not strictly required that inviters have the ability to help the invitee with the process and/or costs associated with acquiring an agent capable of participating in the ecosystem. For example, inviters may often be sponsoring institutions. The inviter sends a <code>connection-response</code> message at the end of the share phase.</p> <p>The invitee has less preconditions; the only requirement is that this party be capable of receiving invitations over traditional communication channels of some type, and acting on it in a way that leads to successful interaction. The invitee sends a <code>connection-request</code> message at the beginning of the share phase.</p> <p>In cases where both parties already possess SSI capabilities, deciding who plays the role of inviter and invitee might be a casual matter of whose phone is handier.</p>"},{"location":"features/0160-connection-protocol/#states","title":"States","text":""},{"location":"features/0160-connection-protocol/#null","title":"null","text":"<p>No connection exists or is in progress</p>"},{"location":"features/0160-connection-protocol/#invited","title":"invited","text":"<p>The invitation has been shared with the intended invitee(s), and they have not yet sent a connection_request.</p>"},{"location":"features/0160-connection-protocol/#requested","title":"requested","text":"<p>A connection_request has been sent by the invitee to the inviter based on the information in the invitation. </p>"},{"location":"features/0160-connection-protocol/#responded","title":"responded","text":"<p>A connection_response has been sent by the inviter to the invitee based on the information in the connection_request.</p>"},{"location":"features/0160-connection-protocol/#complete","title":"complete","text":"<p>The connection is valid and ready for use.</p> <p></p>"},{"location":"features/0160-connection-protocol/#errors","title":"Errors","text":"<p>There are no errors in this protocol during the invitation phase. For the request and response, there are two error messages possible for each phase: one for an active rejection and one for an unknown error. These errors are sent using a problem_report message type specific to the connection message family. The following list details <code>problem-code</code>s that may be sent:</p> <p>request_not_accepted - The error indicates that the request has been rejected for a reason listed in the error_report. Typical reasons include not accepting the method of the provided DID, unknown endpoint protocols, etc. The request can be resent after the appropriate corrections have been made.</p> <p>request_processing_error - This error is sent when the inviter was processing the request with the intent to accept the request, but some processing error occurred. This error indicates that the request should be resent as-is.</p> <p>response_not_accepted - The error indicates that the response has been rejected for a reason listed in the error_report. Typical reasons include not accepting the method of the provided DID, unknown endpoint protocols, invalid signature, etc. The response can be resent after the appropriate corrections have been made.</p> <p>response_processing_error - This error is sent when the invitee was processing the response with the intent to accept the response, but some processing error occurred. This error indicates that the response should be resent as-is.</p> <p>No errors are sent in timeout situations. If the inviter or invitee wishes to retract the messages they sent, they record so locally and return a <code>request_not_accepted</code> or <code>response_not_accepted</code> error when the other party sends a request or response .</p>"},{"location":"features/0160-connection-protocol/#error-message-example","title":"Error Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/connections/1.0/problem_report\",\n  \"@id\": \"5678876542345\",\n  \"~thread\": { \"thid\": \"&lt;@id of message related to problem&gt;\" },\n  \"~i10n\": { \"locale\": \"en\"},\n  \"problem-code\": \"request_not_accepted\", // matches codes listed above\n  \"explain\": \"Unsupported DID method for provided DID.\"\n}\n</code></pre>"},{"location":"features/0160-connection-protocol/#error-message-attributes","title":"Error Message Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is a problem_report within the connections family.</li> <li>The <code>~thread</code> attribute provides a context for the problem, referring to the message which contains the problem.</li> <li>Use of <code>~i10n</code> is encouraged, with at least locale defined for the message.</li> <li>The <code>problem-code</code> attribute contains one of a fixed set of codes defined in the list above.</li> <li>The <code>explain</code> attribute contains a human readable message which indicates the problem.</li> </ul>"},{"location":"features/0160-connection-protocol/#flow-overview","title":"Flow Overview","text":"<p>The inviter gives provisional connection information to the invitee.  The invitee uses provisional information to send a DID and DID document to the inviter. The inviter uses received DID document information to send a DID and DID document to the invitee. The invitee sends the inviter an ack or any other message that confirms the response was received.</p>"},{"location":"features/0160-connection-protocol/#0-invitation-to-connect","title":"0. Invitation to Connect","text":"<p>Note: This Invitation message is deprecated, and should use an invitation message from the Out Of Band Protocol</p> <p>An invitation to connect may be transferred using any method that can reliably transmit text. The result  must be the essential data necessary to initiate a Connection Request message. A connection invitation is an agent message with agent plaintext format, but is an out-of-band communication and therefore not communicated using wire level encoding or encryption. The necessary data that an invitation to connect must result in is:</p> <ul> <li> <p>suggested label</p> </li> <li> <p>publicly resolvable DID</p> </li> </ul> <p>OR</p> <ul> <li> <p>suggested label</p> </li> <li> <p>recipientKeys</p> </li> <li> <p>serviceEndpoint</p> </li> <li> <p>routingKeys (optional)</p> </li> </ul> <p>This information is used to create a provisional connection to the inviter. That connection will be made complete in the <code>connection_response</code> message.</p> <p>These attributes were chosen to parallel the attributes of a DID document for increased meaning. It is worth noting that <code>recipientKeys</code> and <code>routingKeys</code> must be inline keys, not DID key references when contained in an invitation. As in the DID document with <code>Ed25519VerificationKey2018</code> key types, the key must be base58 encoded.</p> <p>When considering routing and options for invitations, keep in mind that the more detail is in the connection invitation, the longer the URL will be and (if used) the more dense the QR code will be. Dense QR codes can be harder to scan.</p> <p>The inviter will either use an existing invitation DID, or provision a new one according to the DID method spec. They will then create the invitation message in one of the following forms.</p> <p>Invitation Message with Public Invitation DID:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/connections/1.0/invitation\",\n    \"@id\": \"12345678900987654321\",\n    \"label\": \"Alice\",\n    \"did\": \"did:sov:QmWbsNYhMrjHiqZDTUTEJs\"\n}\n</code></pre> <p>Invitation Message with Keys and URL endpoint:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/connections/1.0/invitation\",\n    \"@id\": \"12345678900987654321\",\n    \"label\": \"Alice\",\n    \"recipientKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"],\n    \"serviceEndpoint\": \"https://example.com/endpoint\",\n    \"routingKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"]\n}\n</code></pre> <p>Invitation Message with Keys and DID Service Endpoint Reference:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/connections/1.0/invitation\",\n    \"label\": \"Alice\",\n    \"recipientKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"],\n    \"serviceEndpoint\": \"did:sov:A2wBhNYhMrjHiqZDTUYH7u;routeid\",\n    \"routingKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"]\n}\n</code></pre>"},{"location":"features/0160-connection-protocol/#implicit-invitation","title":"Implicit Invitation","text":"<p>Any Public DID serves as an implicit invitation. If an invitee wishes to connect to any Public DID, They designate their own label and skip to the end of the Invitation Processing step. There is no need to encode the invitation or transmit the invitation. </p>"},{"location":"features/0160-connection-protocol/#routing-keys","title":"Routing Keys","text":"<p>If <code>routingKeys</code> is present and non-empty, additional forwarding wrapping will be necessary for the request message. See the explanation in the Request section.</p>"},{"location":"features/0160-connection-protocol/#agency-endpoint","title":"Agency Endpoint","text":"<p>The endpoint for the connection is either present in the invitation or available in the DID document of a presented DID. If the endpoint is not a URI but a DID itself, that DID refers to an Agency.</p> <p>In that case, the <code>serviceEndpoint</code> of the DID must be a URI, and the <code>recipientKeys</code> must contain a single key. That key is appended to the end of the list of <code>routingKeys</code> for processing. For more information about message forwarding and routing, see RFC 0094.</p>"},{"location":"features/0160-connection-protocol/#standard-invitation-encoding","title":"Standard Invitation Encoding","text":"<p>Using a standard invitation encoding allows for easier interoperability between multiple projects and software platforms. Using a URL for that standard encoding provides a built in fallback flow for users who are unable to automatically process the invitation. Those new users will load the URL in a browser as a default behavior, and will be presented with instructions on how to install software capable of processing the invitation. Already onboarded users will be able to process the invitation without loading in a browser via mobile app URL capture, or via capability detection after being loaded in a browser.</p> <p>The standard invitation format is a URL with a Base64URLEncoded json object as a query parameter. </p> <p>The Invitation URL format is as follows, with some elements described below:</p> <pre><code>https://&lt;domain&gt;/&lt;path&gt;?c_i=&lt;invitationstring&gt;\n</code></pre> <p><code>&lt;domain&gt;</code> and <code>&lt;path&gt;</code> should be kept as short as possible, and the full URL should return human readable instructions when loaded in a browser. This is intended to aid new users. The <code>c_i</code> query parameter is required and is reserved to contain the invitation string. Additional path elements or query parameters are allowed, and can be leveraged to provide coupons or other promise of payment for new users. </p> <p>The <code>&lt;invitationstring&gt;</code> is an agent plaintext message (not a wire level message) that has been base64 url encoded. For brevity, the json encoding should minimize unnecessary white space.</p> <pre><code>invitation_string = b64urlencode(&lt;invitation_message&gt;)\n</code></pre> <p>During encoding, whitespace from the json string should be eliminated to keep the resulting invitation string as short as possible.</p>"},{"location":"features/0160-connection-protocol/#example-invitation-encoding","title":"Example Invitation Encoding","text":"<p>Invitation:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/connections/1.0/invitation\",\n    \"@id\": \"12345678900987654321\",\n    \"label\": \"Alice\",\n    \"recipientKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"],\n    \"serviceEndpoint\": \"https://example.com/endpoint\",\n    \"routingKeys\": [\"8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K\"]\n}\n</code></pre> <p>Base 64 URL Encoded, with whitespace removed:</p> <pre><code>eyJAdHlwZSI6ImRpZDpzb3Y6QnpDYnNOWWhNcmpIaXFaRFRVQVNIZztzcGVjL2Nvbm5lY3Rpb25zLzEuMC9pbnZpdGF0aW9uIiwiQGlkIjoiMTIzNDU2Nzg5MDA5ODc2NTQzMjEiLCJsYWJlbCI6IkFsaWNlIiwicmVjaXBpZW50S2V5cyI6WyI4SEg1Z1lFZU5jM3o3UFlYbWQ1NGQ0eDZxQWZDTnJxUXFFQjNuUzdaZnU3SyJdLCJzZXJ2aWNlRW5kcG9pbnQiOiJodHRwczovL2V4YW1wbGUuY29tL2VuZHBvaW50Iiwicm91dGluZ0tleXMiOlsiOEhINWdZRWVOYzN6N1BZWG1kNTRkNHg2cUFmQ05ycVFxRUIzblM3WmZ1N0siXX0=\n</code></pre> <p>Example URL:</p> <pre><code>http://example.com/ssi?c_i=eyJAdHlwZSI6ImRpZDpzb3Y6QnpDYnNOWWhNcmpIaXFaRFRVQVNIZztzcGVjL2Nvbm5lY3Rpb25zLzEuMC9pbnZpdGF0aW9uIiwiQGlkIjoiMTIzNDU2Nzg5MDA5ODc2NTQzMjEiLCJsYWJlbCI6IkFsaWNlIiwicmVjaXBpZW50S2V5cyI6WyI4SEg1Z1lFZU5jM3o3UFlYbWQ1NGQ0eDZxQWZDTnJxUXFFQjNuUzdaZnU3SyJdLCJzZXJ2aWNlRW5kcG9pbnQiOiJodHRwczovL2V4YW1wbGUuY29tL2VuZHBvaW50Iiwicm91dGluZ0tleXMiOlsiOEhINWdZRWVOYzN6N1BZWG1kNTRkNHg2cUFmQ05ycVFxRUIzblM3WmZ1N0siXX0=\n</code></pre> <p>Invitation URLs can be transferred via any method that can send text, including an email, SMS, posting on a website, or via a QR Code. </p> <p>Example URL encoded as a QR Code:</p> <p></p>"},{"location":"features/0160-connection-protocol/#invitation-publishing","title":"Invitation Publishing","text":"<p>The inviter will then publish or transmit the invitation URL in a manner available to the intended invitee. After publishing, we have entered the invited state.</p>"},{"location":"features/0160-connection-protocol/#invitation-processing","title":"Invitation Processing","text":"<p>When they invitee receives the invitation URL, there are two possible user flows that depend on the SSI preparedness of the individual. If the individual is new to the SSI universe, they will likely load the URL in a browser. The resulting page will contain instructions on how to get started by installing software or a mobile app. That install flow will transfer the invitation message to the newly installed software. A user that already has those steps accomplished will have the URL received by software directly. That software will base64URL decode the string and can read the invitation message directly out of the <code>c_i</code> query parameter, without loading the URL.</p> <p>NOTE: In receiving the invitation, the base64url decode implementation used MUST correctly decode padded and unpadded base64URL encoded data.</p> <p>If the invitee wants to accept the connection invitation, they will use the information present in the invitation message to prepare the request</p>"},{"location":"features/0160-connection-protocol/#1-connection-request","title":"1. Connection Request","text":"<p>The connection request message is used to communicate the DID document of the invitee to the inviter using the provisional connection information present in the connection_invitation message.</p> <p>The invitee will provision a new DID according to the DID method spec. For a Peer DID, this involves creating a matching peer DID and key. The newly provisioned DID and DID document is presented in the connection_request message as follows:</p>"},{"location":"features/0160-connection-protocol/#example","title":"Example","text":"<pre><code>{\n  \"@id\": \"5678876542345\",\n  \"@type\": \"https://didcomm.org/connections/1.0/request\",\n  \"label\": \"Bob\",\n  \"connection\": {\n    \"DID\": \"B.did@B:A\",\n    \"DIDDoc\": {\n        \"@context\": \"https://w3id.org/did/v1\"\n        // DID document contents here.\n    }\n  }\n}\n</code></pre>"},{"location":"features/0160-connection-protocol/#attributes","title":"Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is a connection request.</li> <li>The <code>label</code> attribute provides a suggested label for the connection. This allows the user to tell multiple connection offers apart. This is not a trusted attribute.</li> <li>The <code>connection</code> attribute contains the <code>DID</code> and <code>DIDDoc</code> attributes. This format maintains consistency with the Response message where this attribute is signed.</li> <li>The <code>DID</code> indicates the DID of the user requesting the connection.</li> <li>The <code>DIDDoc</code> contains the DID document for the requesting user. If the DID method for the presented DID is not a peer method and the DID document is resolvable on a ledger, the <code>DIDDoc</code> attribute is optional.</li> </ul>"},{"location":"features/0160-connection-protocol/#diddoc-example","title":"DIDDoc Example","text":"<p>An example of the DID document contents is the following JSON. This format was implemented in some early agents as the DIDComm DIDDoc Conventions RFC was being formalized and so does not match that RFC exactly. For example, the use of the <code>IndyAgent</code> service endpoint. Future versions of this protocol will align precisely with that RFC.</p> <pre><code>{\n  \"@context\": \"https://w3id.org/did/v1\",\n  \"id\": \"did:sov:QUmsj7xwB82QAuuzfmvhAi\",\n  \"publicKey\": [\n    {\n      \"id\": \"did:sov:QUmsj7xwB82QAuuzfmvhAi#1\",\n      \"type\": \"Ed25519VerificationKey2018\",\n      \"controller\": \"did:sov:QUmsj7xwB82QAuuzfmvhAi\",\n      \"publicKeyBase58\": \"DoDMNYwMrSN8ygGKabgz5fLA9aWV4Vi8SLX6CiyN2H4a\"\n    }\n  ],\n  \"authentication\": [\n    {\n      \"type\": \"Ed25519SignatureAuthentication2018\",\n      \"publicKey\": \"did:sov:QUmsj7xwB82QAuuzfmvhAi#1\"\n    }\n  ],\n  \"service\": [\n    {\n      \"id\": \"did:sov:QUmsj7xwB82QAuuzfmvhAi;indy\",\n      \"type\": \"IndyAgent\",\n      \"priority\": 0,\n      \"recipientKeys\": [\n        \"DoDMNYwMrSN8ygGKabgz5fLA9aWV4Vi8SLX6CiyN2H4a\"\n      ],\n      \"serviceEndpoint\": \"http://192.168.65.3:8030\"\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0160-connection-protocol/#request-transmission","title":"Request Transmission","text":"<p>The Request message is encoded according to the standards of the Agent Wire Level Protocol, using the <code>recipientKeys</code> present in the invitation. </p> <p>If the <code>routingKeys</code> attribute was present and non-empty in the invitation, each key must be used to wrap the message in a forward request, then encoded according to the Agent Wire Level Protocol. This processing is in order of the keys in the list, with the last key in the list being the one for which the <code>serviceEndpoint</code> possesses the private key.</p> <p>The message is then transmitted to the <code>serviceEndpoint</code>.</p> <p>We are now in the <code>requested</code> state.</p>"},{"location":"features/0160-connection-protocol/#request-processing","title":"Request processing","text":"<p>After receiving the connection request, the inviter evaluates the provided DID and DID document according to the DID Method Spec.</p> <p>The inviter should check the information presented with the keys used in the wire-level message transmission to ensure they match.</p> <p>If the inviter wishes to accept the connection, they will persist the received information in their wallet. They will then either update the provisional connection information to rotate the key, or provision a new DID entirely. The choice here will depend on the nature of the DID used in the invitation.</p> <p>The inviter will then craft a connection response using the newly updated or provisioned information.</p>"},{"location":"features/0160-connection-protocol/#request-errors","title":"Request Errors","text":"<p>See Error Section above for message format details.</p> <p>request_rejected</p> <p>Possible reasons:</p> <ul> <li>Unsupported DID method for provided DID</li> <li>Expired Invitation</li> <li>DID Document Invalid</li> <li>Unsupported key type</li> <li>Unsupported endpoint protocol</li> </ul> <p>request_processing_error</p> <ul> <li>unknown processing error</li> </ul>"},{"location":"features/0160-connection-protocol/#2-connection-response","title":"2. Connection Response","text":"<p>The connection response message is used to complete the connection. This message is required in the flow, as it updates the provisional information presented in the invitation.</p>"},{"location":"features/0160-connection-protocol/#example_1","title":"Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/connections/1.0/response\",\n  \"@id\": \"12345678900987654321\",\n  \"~thread\": {\n    \"thid\": \"&lt;@id of request message&gt;\"\n  },\n  \"connection\": {\n    \"DID\": \"A.did@B:A\",\n    \"DIDDoc\": {\n      \"@context\": \"https://w3id.org/did/v1\"\n      // DID document contents here.\n    }\n  }\n}\n</code></pre> <p>The above message is required to be signed as described in RFC 0234 Signature Decorator. The <code>connection</code> attribute above will be base64URL encoded and included as part of the <code>sig_data</code> attribute of the signed field. The result looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/connections/1.0/response\",\n  \"@id\": \"12345678900987654321\",\n  \"~thread\": {\n    \"thid\": \"&lt;@id of request message&gt;\"\n  },\n  \"connection~sig\": {\n    \"@type\": \"https://didcomm.org/signature/1.0/ed25519Sha512_single\",\n    \"signature\": \"&lt;digital signature function output&gt;\",\n    \"sig_data\": \"&lt;base64URL(64bit_integer_from_unix_epoch||connection_attribute)&gt;\",\n    \"signer\": \"&lt;signing_verkey&gt;\"\n  }\n}\n</code></pre> <p>The <code>connection</code> attribute has been removed and it's contents combined with the timestamp  and encoded into the <code>sig_data</code> field of the new <code>connection~sig</code> attribute.</p> <p>Upon receipt, the signed attribute will be automatically unpacked and the signature verified. Signature information will be stored as message context, and the <code>connection</code> attribute will be replaced in it's original format before processing continues.</p> <p>The signature data must be used to verify against the invitation's <code>recipientKeys</code> for continuity. </p>"},{"location":"features/0160-connection-protocol/#attributes_1","title":"Attributes","text":"<ul> <li>The <code>@type</code> attribute is a required string value that denotes that the received message is a connection request.</li> <li>The <code>~thread</code> block contains a <code>thid</code> reference to the <code>@id</code> of the request message. </li> <li>The <code>connection</code> attribute contains the <code>DID</code> and <code>DIDDoc</code> attributes to enable simpler signing.</li> <li>The <code>DID</code> attribute is a required string value and denotes DID in use by the inviter. Note that this may not be the same DID used in the invitation.</li> <li>The <code>DIDDoc</code> attribute contains the associated DID document. If the DID method for the presented DID is not a peer method and the DID document is resolvable on a ledger, the <code>DIDDoc</code> attribute is optional.</li> </ul> <p>In addition to a new DID, the associated DID document might contain a new endpoint. This new DID and endpoint are to be used going forward in the connection.</p>"},{"location":"features/0160-connection-protocol/#response-transmission","title":"Response Transmission","text":"<p>The message should be packaged in the wire level format, using the keys from the request, and the new keys presented in the internal DID document.</p> <p>When the message is transmitted, we are now in the <code>responded</code> state.</p>"},{"location":"features/0160-connection-protocol/#response-processing","title":"Response Processing","text":"<p>When the invitee receives the <code>response</code> message, they will verify the <code>sig_data</code> provided. After validation, they will update their wallet with the new connection information. If the endpoint was changed, they may wish to execute a Trust Ping to verify that new endpoint.</p>"},{"location":"features/0160-connection-protocol/#response-errors","title":"Response Errors","text":"<p>See Error Section above for message format details.</p> <p>response_rejected</p> <p>Possible reasons:</p> <ul> <li>Unsupported DID method for provided DID</li> <li>Expired Request</li> <li>DID Document Invalid</li> <li>Unsupported key type</li> <li>Unsupported endpoint protocol</li> <li>Invalid Signature</li> </ul> <p>response_processing_error</p> <ul> <li>unknown processing error</li> </ul>"},{"location":"features/0160-connection-protocol/#3-connection-acknowledgement","title":"3. Connection Acknowledgement","text":"<p>After the Response is received, the connection is technically complete. This remains unconfirmed to the inviter however. The invitee SHOULD send a message to the inviter. As any message will confirm the connection, any message will do. </p> <p>Frequently, the parties of the connection will want to trade credentials to establish trust. In such a flow, those message will serve the function of acknowledging the connection without an extra confirmation message.</p> <p>If no message is needed immediately, a trust ping can be used to allow both parties confirm the connection.</p> <p>After a message is sent, the invitee in the <code>complete</code> state. Receipt of a message puts the inviter into the <code>complete</code> state.</p>"},{"location":"features/0160-connection-protocol/#next-steps","title":"Next Steps","text":"<p>The connection between the inviter and the invitee is now established. This connection has no trust associated with it. The next step should be the exchange of proofs to build trust sufficient for the purpose of the relationship.</p>"},{"location":"features/0160-connection-protocol/#connection-maintenance","title":"Connection Maintenance","text":"<p>Upon establishing a connection, it is likely that both Alice and Bob will want to perform some relationship maintenance such as key rotations. Future RFC updates will add these maintenance ../../features.</p>"},{"location":"features/0160-connection-protocol/#reference","title":"Reference","text":"<ul> <li>https://docs.google.com/document/d/1mRLPOK4VmU9YYdxHJSxgqBp19gNh3fT7Qk4Q069VPY8/edit#heading=h.7sxkr7hbou5i</li> <li>Agent to Agent Communication Video</li> <li>Agent to Agent Communication Presentation</li> <li>Problem_report message adopted into message family, following form defined by the Report Problem RFC</li> <li>Useful QR Code Generator: https://zxing.appspot.com/generator/</li> </ul>"},{"location":"features/0160-connection-protocol/#drawbacks","title":"Drawbacks","text":"<ul> <li>Public invitations (say, a slide at the end of a presentation) all use the same DID. This is not a problem for public institutions, and only provides a minor increase in correlation over sharing an endpoint, key, and routing information in a way that is observable by multiple parties.</li> </ul>"},{"location":"features/0160-connection-protocol/#prior-art","title":"Prior art","text":"<ul> <li>This process is similar to other key exchange protocols.</li> </ul>"},{"location":"features/0160-connection-protocol/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Should we eliminate the public DID option, and they just present an invitation with the connection key from their public DID document?</li> <li>Should invitations have <code>@id</code>s?</li> </ul>"},{"location":"features/0160-connection-protocol/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Framework - .NET passed agent connectathon tests, Feb 2019; MISSING test results Streetcred.id passed agent connectathon tests, Feb 2019; MISSING test results Aries Cloud Agent - Python ported from VON codebase that passed agent connectathon tests, Feb 2019; MISSING test results Aries Static Agent - Python implemented July 2019; MISSING test results Aries Protocol Test Suite ported from Indy Agent codebase that provided agent connectathon tests, Feb 2019; MISSING test results Indy Cloud Agent - Python passed agent connectathon tests, Feb 2019; MISSING test results"},{"location":"features/0183-revocation-notification/","title":"Aries RFC 0183: Revocation Notification 1.0","text":"<ul> <li>Authors: Keith Smith</li> <li>Status: ACCEPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Initial proposal after discussion on rocketchat</li> <li>Supersedes:</li> <li>Start Date: 2018-08-12</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0183-revocation-notification/#summary","title":"Summary","text":"<p>This RFC defines the message format which an issuer uses to notify a holder that a previously issued credential has been revoked.</p>"},{"location":"features/0183-revocation-notification/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> </ul>"},{"location":"features/0183-revocation-notification/#motivation","title":"Motivation","text":"<p>We need a standard protocol for an issuer to notify a holder that a previously issued credential has been revoked.</p> <p>For example, suppose a passport agency revokes Alice's passport. The passport agency (an issuer) may want to notify Alice (a holder) that her passport has been revoked so that she knows that she will be unable to use her passport to travel.</p>"},{"location":"features/0183-revocation-notification/#tutorial","title":"Tutorial","text":"<p>The Revocation Notification protocol is a very simple protocol consisting of a single message:</p> <ul> <li>Revoke - issuer to holder</li> </ul> <p>This simple protocol allows an issuer to choose to notify a holder that a previously issued credential has been revoked.</p> <p>It is the issuer's prerogative whether or not to notify the holder that a credential has been revoked.  It is not a security risk if the issuer does not notify the holder that the credential has been revoked, nor if the message is lost.  The holder will still be unable to use a revoked credential without this notification.</p>"},{"location":"features/0183-revocation-notification/#roles","title":"Roles","text":"<p>There are two parties involved in a Revocation Notification: <code>issuer</code> and <code>holder</code>. The <code>issuer</code> sends the <code>revoke</code> message to the <code>holder</code>.</p>"},{"location":"features/0183-revocation-notification/#messages","title":"Messages","text":"<p>The <code>revoke</code> message sent by the <code>issuer</code> to the <code>holder</code> is as follows:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/revocation_notification/1.0/revoke\",\n  \"@id\": \"&lt;uuid-revocation-notification&gt;\",\n  \"thread_id\": \"&lt;thread_id&gt;\",\n  \"comment\": \"Some comment\"\n}\n</code></pre> <p>Description of fields:</p> <ul> <li> <p><code>thread_id</code> (required) -- the thread ID of the issue-credential-v2 protocol which was used to issue one or more credentials that have been revoked by the issuer.  If multiple credentials were issued, each credential has a different credential format but contains the same claims as described here; therefore, this message notifies the holder that all of these credentials have been revoked.</p> </li> <li> <p><code>comment</code> (optional) -- a field that provides some human readable information about the revocation notification.  This is typically the reason for the revocation as deemed appropriate by the issuer.</p> </li> </ul>"},{"location":"features/0183-revocation-notification/#reference","title":"Reference","text":"<ul> <li>See the issue-credential-v2 protocol.</li> <li>See the thread ID description.</li> <li>See the Please ACK Decorator RFC.</li> </ul>"},{"location":"features/0183-revocation-notification/#drawbacks","title":"Drawbacks","text":"<p>If we later added support for more general event subscription and notification message flows, this would be redundant.</p>"},{"location":"features/0183-revocation-notification/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?  It is simple.</li> <li>What other designs have been considered and what is the rationale for not choosing them?  A more general event subscription and notification mechanism was considered but chose to keep this simple for the same reasons that the basic message was kept simple.</li> <li>What is the impact of not doing this?  There is no standard way of sending a revocation notification which is a common scenario.</li> </ul>"},{"location":"features/0183-revocation-notification/#prior-art","title":"Prior art","text":""},{"location":"features/0183-revocation-notification/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"features/0183-revocation-notification/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0193-coin-flip/","title":"Aries RFC 0193: Coin Flip Protocol 1.0","text":"<ul> <li>Authors: Daniel Hardman, Patrick St\u00fcrmlinger</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Start Date: 2019-08-19</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0193-coin-flip/#summary","title":"Summary","text":"<p>Specifies a safe way for two parties who are remote from one another and who do not trust one another to pick a random, binary outcome that neither can manipulate.</p>"},{"location":"features/0193-coin-flip/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> </ul>"},{"location":"features/0193-coin-flip/#motivation","title":"Motivation","text":"<p>To guarantee fairness, it is often important to pick one party in a protocol to make a choice about what to do next. We need a way to do this that it more or less mirrors the randomness of flipping a coin.</p>"},{"location":"features/0193-coin-flip/#tutorial","title":"Tutorial","text":""},{"location":"features/0193-coin-flip/#name-and-version","title":"Name and Version","text":"<p>This defines the <code>coinflip</code> protocol, version 1.x, as identified by the following PIURI:</p> <pre><code>https://github.com/hyperledger/aries-rfcs../../features/0193-coin-flip/1.0\n</code></pre>"},{"location":"features/0193-coin-flip/#roles","title":"Roles","text":"<p>There are 2 roles in the protocol: Recorder and Caller. These role names parallel the roles in a physical coin flip: the Recorder performs a process that freezes/records the state of a flipped coin, and the Caller announces the state that they predict, before the state is known. If the caller predicts the state correctly, then the caller chooses what happens next; otherwise, the recorder chooses.</p>"},{"location":"features/0193-coin-flip/#algorithm","title":"Algorithm","text":"<p>Before describing the messages, let's review the algorithm that will be used. This algorithm is not new; it is a simple commitment scheme described on wikipedia and implemented in various places. The RFC merely formalizes a simple commitment scheme for DIDComm in a way that the Caller chooses a side without knowing whether it's <code>win</code> or <code>lose</code>.</p> <ol> <li> <p>Recorder chooses a random UUID. A version 4 UUID is recommended, though any UUID version should be accepted. Note that the UUID is represented in lower case, with hyphens, and without enclosing curly braces. Suppose this value is <code>01bf7abd-aa80-4389-bf8c-dba0f250bb1b</code>. This UUID is called salt.</p> </li> <li> <p>Recorder builds two side strings by salting <code>win</code> and <code>lose</code> with the salt -- i.e., <code>win01bf7abd-aa80-4389-bf8c-dba0f250bb1b</code> and <code>lose01bf7abd-aa80-4389-bf8c-dba0f250bb1b</code>. Recorder then computes a SHA256 hash of each side string, which are <code>0C192E004440D8D6D6AF06A7A03A2B182903E9F048D4E7320DF6301DF0C135A5</code> and <code>C587E50CB48B1B0A3B5136BA9D238B739A6CD599EE2D16994537B75CA595C091</code> for our example, and randomly selects one side string as side1 and the other one as side2. Recorder sends them to Caller using the <code>propose</code> message described below. Those hashes do commit Recorder to all inputs, without revealing which one is <code>win</code> or <code>lose</code>, and it's the Recorder's way of posing the Caller the question, \"underside or topside\"?</p> </li> <li> <p>Caller announces their committed choice -- for instance, <code>side2</code>, using the 'call' message described below. This commits Caller to a particular side of the virtual coin.</p> </li> <li> <p>Recorder uses a 'reveal' message to reveal the salt. Caller is now able to rebuild both side strings and both parties discover whether Caller guessed the <code>win</code> side or not. If Caller guessed the <code>win</code> side, Caller won. Otherwise Recorder won. Neither party is able to manipulate the outcome. This is guaranteed by Caller being able to verify that Recorder proposed two valid options, i.e. one side winning and one side losing, and Recorder knowing not to reveal any disclosed information before Caller made their choice.</p> </li> </ol>"},{"location":"features/0193-coin-flip/#states","title":"States","text":"<p>The algorithm and the corresponding states are pictured in the following diagram:</p> <p></p>  Note: This diagram was made in draw.io. To make changes:  - upload the drawing HTML from this folder to the [draw.io](https://draw.io) site (Import From... Device),  - make changes, - export the picture as PNG and HTML to your local copy of this repo, and - submit a pull request.  <p>This diagram only depicts the so-called \"happy path\". It is possible to experience problems for various reasons. If either party detects such an event, they should abandon the protocol and emit a <code>problem-report</code> message to the other party. The <code>problem-report</code> message is adopted into this protocol for that purpose. Some values of <code>code</code> that may be used in such messages include:</p> <ul> <li><code>bad-message-sequence</code>: The message was sent out of order.</li> <li><code>bad-field-value</code>: The message contained a field with an invalid value. The offending fields are named in the <code>problem_items</code> array. </li> </ul>"},{"location":"features/0193-coin-flip/#reference","title":"Reference","text":""},{"location":"features/0193-coin-flip/#messages","title":"Messages","text":""},{"location":"features/0193-coin-flip/#propose","title":"<code>propose</code>","text":"<p>The protocol begins when Caller sends to Recorder a <code>propose</code> message that embodies Step 1 in the algorithm above. It looks like this:</p> <pre><code>{\n  \"@type\": \"https://github.com/hyperledger/aries-rfcs../../features/0193-coin-flip/1.0/propose\",\n  \"@id\": \"518be002-de8e-456e-b3d5-8fe472477a86\",\n  \"side1\": \"C587E50CB48B1B0A3B5136BA9D238B739A6CD599EE2D16994537B75CA595C091\",\n  \"side2\": \"0C192E004440D8D6D6AF06A7A03A2B182903E9F048D4E7320DF6301DF0C135A5\",\n  \"comment\": \"Make your choice and let's who goes first.\",\n  \"choice-id\": \"did:sov:SLfEi9esrjzybysFxQZbfq;spec/tictactoe/1.0/who-goes-first\",\n  \"caller-wins\": \"did:example:abc123\",  // Meaning of value defined in superprotocol\n  \"recorder-wins\": \"did:example:xyz456\", // Meaning of value defined in superprotocol\n  // Optional; connects to superprotocol\n  \"~thread\": { \n    \"pthid\": \"a2be4118-4f60-bacd-c9a0-dfb581d6fd96\" \n  }\n}\n</code></pre> <p>The <code>@type</code> and <code>@id</code> fields are standard for DIDComm. The <code>side1</code> and <code>side2</code> fields convey the data required by Step 2 of the algorithm. The optional <code>comment</code> field follows localization conventions and is irrelevant unless the coin flip intends to invite human participation. The <code>~thread.pthid</code> decorator is optional but should be common; it identifies the thread of the parent interaction (the superprotocol).</p> <p>The <code>choice-id</code> field formally names a choice that a superprotocol has defined, and tells how the string values of the <code>caller-wins</code> and <code>recorder-wins</code> fields will be interpreted. In the example above, the choice is defined in the Tic-Tac-Toe Protocol, which also specifies that <code>caller-wins</code> and <code>recorder-wins</code> will contain DIDs of the parties playing the game. Some other combinations that might make sense include:</p> <ul> <li> <p>In an auction protocol that uses a coin flip to break a tie between two bids of equal value, <code>choice-id</code> might be a string like <code>prefix/myauctionproto/1.0/bid-tie-break</code>, and the values of the <code>*-wins</code> fields might be the <code>id</code> properties of specific bid messages.</p> </li> <li> <p>In a protocol that models an American football game, the <code>choice-id</code> might be a string like <code>prefix/amfootball/1.0/who-kicks-off</code>, and the values of the <code>*-wins</code> fields might be the strings \"home\" and \"visitor\".</p> </li> <li> <p>In a protocol that models radioactive halflife, the decay of a particular neutron might use <code>choice-id</code> of <code>prefix/halflife/1.0/should-decay</code>, and the <code>*-wins</code> fields might be the strings \"yes\" and \"no\".</p> </li> </ul> <p>The <code>~timing.expires_time</code> decorator may be used to impose a time limit on the processing of this message. If used, the protocol must restart if the subsequent <code>call</code> message is not received by this time limit.</p>"},{"location":"features/0193-coin-flip/#call","title":"<code>call</code>","text":"<p>This message is sent from Caller to Recorder, and embodies Step 3 of the algorithm. It looks like this:</p> <pre><code>{\n  \"@type\": \"https://github.com/hyperledger/aries-rfcs../../features/0193-coin-flip/1.0/call\",\n  \"@id\": \"1173fe5f-86c9-47d7-911b-b8eac7d5f2ad\",\n  \"choice\": \"side2\",\n  \"comment\": \"I pick side 2.\",\n  \"~thread\": { \n    \"thid\": \"518be002-de8e-456e-b3d5-8fe472477a86\",\n    \"sender_order\": 1 \n  }\n}\n</code></pre> <p>Note the use of <code>~thread.thid</code> and <code>sender_order: 1</code> to connect this <code>call</code> to the preceding <code>propose</code>.</p> <p>The <code>~timing.expires_time</code> decorator may be used to impose a time limit on the processing of this message. If used, the protocol must restart if the subsequent <code>reveal</code> message is not received by this time limit.</p>"},{"location":"features/0193-coin-flip/#reveal","title":"<code>reveal</code>","text":"<p>This message is sent from Recorder to Caller, and embodies Step 4 of the algorithm. It looks like this:</p> <pre><code>{\n  \"@type\": \"https://github.com/hyperledger/aries-rfcs../../features/0193-coin-flip/1.0/reveal\",\n  \"@id\": \"e2a9454d-783d-4663-874e-29ad10776115\",\n  \"salt\": \"01bf7abd-aa80-4389-bf8c-dba0f250bb1b\",\n  \"winner\": \"caller\",\n  \"comment\": \"You win.\",\n  \"~thread\": { \n    \"thid\": \"518be002-de8e-456e-b3d5-8fe472477a86\",\n    \"sender_order\": 1 \n  }\n}\n</code></pre> <p>Note the use of <code>~thread.thid</code> and <code>sender_order: 1</code> to connect this <code>reveal</code> to the preceding <code>call</code>.</p> <p>The Caller should validate this message as follows:</p> <ul> <li>Confirm that SHA256 hashes of <code>win</code> and <code>lose</code> salted with salt results in the two side strings from the <code>propose</code> message. This check is important because it eliminates the possibility that the Recorder could introduce variation to the commitment.</li> </ul> <p>Having validated the message thus far, Caller determines the winner by checking if the self computed hash of <code>win&lt;salt&gt;</code> equals the given hash at the <code>propose</code> message at the position chosen with the <code>call</code> message or not. If yes, then the value of the <code>winner</code> field must be <code>caller</code>; if not, then it must be <code>recorder</code>. The <code>winner</code> field must be present in the message, and its value must be correct, for the <code>reveal</code> message to be deemed fully valid. This confirms that both parties understand the outcome, and it prevents a Recorder from asserting a false outcome that is accepted by careless validation logic on the Caller side.</p> <p>The <code>~timing.expires_time</code> decorator may be used to impose a time limit on the processing of this message. If used, the protocol must restart if the subsequent <code>ack</code> or the next message in the superprotocol is not received before the time limit.</p>"},{"location":"features/0193-coin-flip/#drawbacks","title":"Drawbacks","text":"<p>The protocol is a bit chatty.</p>"},{"location":"features/0193-coin-flip/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>It may be desirable to pick among more than 2 alternatives. This RFC could be extended easily to provide more options than win and lose. The algorithm itself would not change.</p>"},{"location":"features/0193-coin-flip/#prior-art","title":"Prior art","text":"<p>As mentioned in the introduction, the algorithm used in this protocol is a simple and well known form of cryptographic commitment, and is documented on Wikipedia. It is not new to this RFC.</p>"},{"location":"features/0193-coin-flip/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Do we need to use hashlink so we can move to a new hash algorithm if SHA256 is ever broken?</li> </ul>"},{"location":"features/0193-coin-flip/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0211-route-coordination/","title":"0211: Mediator Coordination Protocol","text":"<ul> <li>Authors: Sam Curren, Daniel Bluhm, Adam Burdett</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Discussed and implemented and part of AIP 2.0.</li> <li>Start Date: 2019-09-03</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"features/0211-route-coordination/#summary","title":"Summary","text":"<p>A protocol to coordinate mediation configuration between a mediating agent and the recipient.</p>"},{"location":"features/0211-route-coordination/#application-scope","title":"Application Scope","text":"<p>This protocol is needed when using an edge agent and a mediator agent from different vendors. Edge agents and mediator agents from the same vendor may use whatever protocol they wish without sacrificing interoperability.</p>"},{"location":"features/0211-route-coordination/#motivation","title":"Motivation","text":"<p>Use of the forward message in the Routing Protocol requires an exchange of information. The Recipient must know which endpoint and routing key(s) to share, and the Mediator needs to know which keys should be routed via this relationship.</p>"},{"location":"features/0211-route-coordination/#protocol","title":"Protocol","text":"<p>Name: coordinate-mediation</p> <p>Version: 1.0</p> <p>Base URI: <code>https://didcomm.org/coordinate-mediation/1.0/</code></p>"},{"location":"features/0211-route-coordination/#roles","title":"Roles","text":"<p>mediator - The agent that will be receiving <code>forward</code> messages on behalf of the recipient. recipient - The agent for whom the <code>forward</code> message payload is intended.</p>"},{"location":"features/0211-route-coordination/#flow","title":"Flow","text":"<p>A recipient may discover an agent capable of routing using the Feature Discovery Protocol. If protocol is supported with the mediator role, a recipient may send a <code>mediate-request</code> to initiate a routing relationship.</p> <p>First, the recipient sends a <code>mediate-request</code> message to the mediator. If the mediator is willing to route messages, it will respond with a <code>mediate-grant</code> message. The recipient will share the routing information in the grant message with other contacts.</p> <p>When a new key is used by the recipient, it must be registered with the mediator to enable route identification. This is done with a <code>keylist-update</code> message.</p> <p>The <code>keylist-update</code> and <code>keylist-query</code> methods are used over time to identify and remove keys that are no longer in use by the recipient.</p>"},{"location":"features/0211-route-coordination/#reference","title":"Reference","text":"<p>Note on terms: Early versions of this protocol included the concept of terms for mediation.  This concept has been removed from this version due to a need for further discussion on representing terms in DIDComm in general and lack of use of these terms in current implementations.</p>"},{"location":"features/0211-route-coordination/#mediation-request","title":"Mediation Request","text":"<p>This message serves as a request from the recipient to the mediator, asking for the permission (and routing information) to publish the endpoint as a mediator.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/mediate-request\",\n}\n</code></pre>"},{"location":"features/0211-route-coordination/#mediation-deny","title":"Mediation Deny","text":"<p>This message serves as notification of the mediator denying the recipient's request for mediation.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/mediate-deny\",\n}\n</code></pre>"},{"location":"features/0211-route-coordination/#mediation-grant","title":"Mediation Grant","text":"<p>A route grant message is a signal from the mediator to the recipient that permission is given to distribute the included information as an inbound route.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/mediate-grant\",\n    \"endpoint\": \"http://mediators-r-us.com\",\n    \"routing_keys\": [\"did:key:z6Mkfriq1MqLBoPWecGoDLjguo1sB9brj6wT3qZ5BxkKpuP6\"]\n}\n</code></pre> <p><code>endpoint</code>: The endpoint reported to mediation client connections.</p> <p><code>routing_keys</code>: List of keys in intended routing order. Key used as recipient of forward messages.</p>"},{"location":"features/0211-route-coordination/#keylist-update","title":"Keylist Update","text":"<p>Used to notify the mediator of keys in use by the recipient.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/keylist-update\",\n    \"updates\":[\n        {\n            \"recipient_key\": \"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\",\n            \"action\": \"add\"\n        }\n    ]\n}\n</code></pre> <p><code>recipient_key</code>: Key subject of the update.</p> <p><code>action</code>: One of <code>add</code> or <code>remove</code>.</p>"},{"location":"features/0211-route-coordination/#keylist-update-response","title":"Keylist Update Response","text":"<p>Confirmation of requested keylist updates.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/keylist-update-response\",\n    \"updated\": [\n        {\n            \"recipient_key\": \"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\",\n            \"action\": \"\" // \"add\" or \"remove\"\n            \"result\": \"\" // [client_error | server_error | no_change | success]\n        }\n    ]\n}\n</code></pre> <p><code>recipient_key</code>: Key subject of the update.</p> <p><code>action</code>: One of <code>add</code> or <code>remove</code>.</p> <p><code>result</code>: One of <code>client_error</code>, <code>server_error</code>, <code>no_change</code>, <code>success</code>; describes the resulting state of the keylist update.</p>"},{"location":"features/0211-route-coordination/#key-list-query","title":"Key List Query","text":"<p>Query mediator for a list of keys registered for this connection.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/keylist-query\",\n    \"paginate\": {\n        \"limit\": 30,\n        \"offset\": 0\n    }\n}\n</code></pre> <p><code>paginate</code> is optional.</p>"},{"location":"features/0211-route-coordination/#key-list","title":"Key List","text":"<p>Response to key list query, containing retrieved keys.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"&lt;baseuri&gt;/keylist\",\n    \"keys\": [\n        {\n            \"recipient_key\": \"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"\n        }\n    ],\n    \"pagination\": {\n        \"count\": 30,\n        \"offset\": 30,\n        \"remaining\": 100\n    }\n}\n</code></pre> <p><code>pagination</code> is optional.</p>"},{"location":"features/0211-route-coordination/#encoding-of-keys","title":"Encoding of keys","text":"<p>All keys are encoded using the <code>did:key</code> method as per RFC0360.</p>"},{"location":"features/0211-route-coordination/#prior-art","title":"Prior art","text":"<p>There was an Indy HIPE that never made it past the PR process that described a similar approach. That HIPE led to a partial implementation of this inside the Aries Cloud Agent Python</p>"},{"location":"features/0211-route-coordination/#future-considerations","title":"Future Considerations","text":"<ul> <li>Should we allow listing keys by date? You could query keys in use by date?</li> <li>We are missing a way to check a single key (or a few keys) without doing a full list.</li> <li>Mediation grant supports only one endpoint. What can be done to support multiple endpoint options i.e. http, ws, etc.</li> <li>Requiring proof of key ownership (with a signature) would prevent an edge case where a malicious party registers a key for another party at the same mediator, and before the other party.</li> <li>How do we express terms and conditions for mediation?</li> </ul>"},{"location":"features/0211-route-coordination/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>None</li> </ul>"},{"location":"features/0211-route-coordination/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python Added in ACA-Py 0.6.0 MISSING test results**** DIDComm mediator Open source cloud-based mediator."},{"location":"features/0212-pickup/","title":"0212: Pickup Protocol","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: PROPOSED</li> <li>Since: 2019-09-03</li> <li>Status Note: Initial version</li> <li>Start Date: 2019-09-03</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0212-pickup/#summary","title":"Summary","text":"<p>A protocol to coordinate routing configuration between a routing agent and the recipient.</p>"},{"location":"features/0212-pickup/#motivation","title":"Motivation","text":"<p>Messages can be picked up simply by sending a message to the message holder with a <code>return_route</code> decorator specified. This mechanism is implicit, and lacks some desired behavior made possible by more explicit messages. This protocol is the explicit companion to the implicit method of picking up messages.</p>"},{"location":"features/0212-pickup/#tutorial","title":"Tutorial","text":""},{"location":"features/0212-pickup/#roles","title":"Roles","text":"<p>message_holder - The agent that has messages waiting for pickup by the recipient. recipient - The agent who is picking up messages. batch_sender - A message_holder that is capable of returning messages in a <code>batch</code>. batch_recipient - A recipient that is capable of receiving and processing a <code>batch</code> message.</p>"},{"location":"features/0212-pickup/#flow","title":"Flow","text":"<p>status can be used to see how many messages are pending. batch retrieval can be executed when many messages ...</p>"},{"location":"features/0212-pickup/#reference","title":"Reference","text":""},{"location":"features/0212-pickup/#statusrequest","title":"StatusRequest","text":"<p>Sent by the recipient to the message_holder to request a <code>status</code> message.</p> <pre><code>{\n  \"@id\": \"123456781\",\n  \"@type\": \"https://didcomm.org/messagepickup/1.0/status-request\"\n}\n</code></pre>"},{"location":"features/0212-pickup/#status","title":"Status","text":"<p>Status details about pending messages</p> <pre><code>{\n  \"@id\": \"123456781\",\n  \"@type\": \"https://didcomm.org/messagepickup/1.0/status\",\n  \"message_count\": 7,\n  \"duration_waited\": 3600,\n  \"last_added_time\": \"2019-05-01 12:00:00Z\",\n  \"last_delivered_time\": \"2019-05-01 12:00:01Z\",\n  \"last_removed_time\": \"2019-05-01 12:00:01Z\",\n  \"total_size\": 8096\n}\n</code></pre> <p><code>message_count</code> is the only required attribute. The others may be present if offered by the message_holder.</p>"},{"location":"features/0212-pickup/#batch-pickup","title":"Batch Pickup","text":"<p>A request to have multiple waiting messages sent inside a <code>batch</code> message.</p> <pre><code>{\n  \"@id\": \"123456781\",\n  \"@type\": \"https://didcomm.org/messagepickup/1.0/batch-pickup\",\n  \"batch_size\": 10\n}\n</code></pre>"},{"location":"features/0212-pickup/#batch","title":"Batch","text":"<p>A message that contains multiple waiting messages.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"https://didcomm.org/messagepickup/1.0/batch\",\n    \"messages~attach\": [\n        {\n            \"@id\" : \"06ca25f6-d3c5-48ac-8eee-1a9e29120c31\",\n            \"message\" : \"{\n                ...\n            }\"\n        },\n\n        {\n            \"@id\" : \"344a51cf-379f-40ab-ab2c-711dab3f53a9a\",\n            \"message\" : \"{\n                ...\n            }\"\n        }\n    ]\n}\n</code></pre>"},{"location":"features/0212-pickup/#message-query-with-message-id-list","title":"Message Query With Message Id List","text":"<p>A request to read single or multiple messages with a message message id array.</p> <pre><code>{\n  \"@id\": \"123456781\",\n  \"@type\": \"https://didcomm.org/messagepickup/1.0/list-pickup\",\n  \"message_ids\": [\n    \"06ca25f6-d3c5-48ac-8eee-1a9e29120c31\",\n    \"344a51cf-379f-40ab-ab2c-711dab3f53a9a\"\n  ]\n}\n</code></pre> <p><code>message_ids</code> message id array for picking up messages. Any message id in <code>message_ids</code> could be delivered via several ways to the recipient (Push notification or with an envoloped message).</p>"},{"location":"features/0212-pickup/#message-list-query-response","title":"Message List Query Response","text":"<p>A response to query with message id list.</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/messagepickup/1.0/list-response\",\n    \"messages~attach\": [\n        {\n            \"@id\" : \"06ca25f6-d3c5-48ac-8eee-1a9e29120c31\",\n            \"message\" : \"{\n                ...\n            }\"\n        },\n        {\n            \"@id\" : \"344a51cf-379f-40ab-ab2c-711dab3f53a9a\",\n            \"message\" : \"{\n                ...\n            }\"\n        }\n    ]\n}\n</code></pre>"},{"location":"features/0212-pickup/#noop","title":"Noop","text":"<p>Used to receive another message implicitly. This message has no expected behavior when received.</p> <pre><code>{\n  \"@id\": \"123456781\",\n  \"@type\": \"https://didcomm.org/messagepickup/1.0/noop\"\n}\n</code></pre>"},{"location":"features/0212-pickup/#prior-art","title":"Prior art","text":"<p>Concepts here borrow heavily from a document written by Andrew Whitehead of BCGov.</p>"},{"location":"features/0212-pickup/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>We are using multiple roles to indicate which portions of the protocol are supported by each party. This is a new thing we have not done before. Is this ok?</li> </ul>"},{"location":"features/0212-pickup/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0213-transfer-policy/","title":"0213: Transfer Policy Protocol","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: PROPOSED</li> <li>Since: 2019-09-03</li> <li>Status Note: Initial version</li> <li>Start Date: 2019-09-03</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0213-transfer-policy/#summary","title":"Summary","text":"<p>A protocol to share and request changes to policy that relates to message transfer.</p>"},{"location":"features/0213-transfer-policy/#motivation","title":"Motivation","text":"<p>Explicit Policy Enables clear expectations.</p>"},{"location":"features/0213-transfer-policy/#tutorial","title":"Tutorial","text":""},{"location":"features/0213-transfer-policy/#roles","title":"Roles","text":"<p>policy_holder uses the policy to manage messages directed to the recipient. recipient the agent the policy relates to.</p>"},{"location":"features/0213-transfer-policy/#reference","title":"Reference","text":""},{"location":"features/0213-transfer-policy/#policy-publish","title":"Policy Publish","text":"<p>Used to share current policy by policy holder. This can be sent unsolicited or in response to a <code>policy_share_request</code>.</p> <pre><code>{\n  \"@id\": \"123456781\",\n  \"@type\": \"https://didcomm.org/transferpolicy/1.0/policy\",\n  \"queue_max_duration\": 86400,\n  \"message_count_limit\": 1000,\n  \"message_size_limit\": 65536,\n  \"queue_size_limit\": 65536000,\n  \"pickup_allowed\": true,\n  \"delivery_retry_count_limit\": 5,\n  \"delivery_retry_count_seconds\": 86400,\n  \"delivery_retry_backoff\": \"exponential\"\n}\n</code></pre>"},{"location":"features/0213-transfer-policy/#policy-share-request","title":"Policy Share Request","text":"<p>Used to ask for a <code>policy</code> message to be sent.</p> <pre><code>{\n  \"@id\": \"123456781\",\n  \"@type\": \"https://didcomm.org/transferpolicy/1.0/policy_share_request\"\n}\n</code></pre>"},{"location":"features/0213-transfer-policy/#policy-change-request","title":"Policy Change Request","text":"<p>Sent to request a policy change. The expected response is a <code>policy</code> message.</p> <pre><code>{\n  \"@id\": \"123456781\",\n  \"@type\": \"https://didcomm.org/transferpolicy/1.0/policy_change_request\",\n  \"queue_max_duration\": 86400,\n  \"message_count_limit\": 1000,\n  \"message_size_limit\": 65536,\n  \"queue_size_limit\": 65536000,\n  \"pickup_allowed\": true,\n  \"delivery_retry_count_limit\": 5,\n  \"delivery_retry_count_seconds\": 86400,\n  \"delivery_retry_backoff\": \"exponential\"\n}\n</code></pre> <p>Only attributes that you desire to change need to be included.</p>"},{"location":"features/0213-transfer-policy/#prior-art","title":"Prior art","text":"<p>Concepts here borrow heavily from a document written by Andrew Whitehead of BCGov.</p>"},{"location":"features/0213-transfer-policy/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the attribute list too extensive for a first pass?</li> <li>Which policy attributes should be required? Which optional?</li> </ul>"},{"location":"features/0213-transfer-policy/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0214-help-me-discover/","title":"Aries RFC 0214: \"Help Me Discover\" Protocol","text":"<ul> <li>Authors: George Aristy, Daniel Hardman</li> <li>Status: PROPOSED</li> <li>Since: 2019-09-10</li> <li>Status Note: implementation is being explored by SecureKey</li> <li>Start Date: 2018-08-20</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0214-help-me-discover/#summary","title":"Summary","text":"<p>Describes how one party can ask another party for help discovering an unknown person, organization, thing, or chunk of data.</p>"},{"location":"features/0214-help-me-discover/#motivation","title":"Motivation","text":"<p>Asking a friend to help us discover something is an extremely common human interaction: \"Dad, I need a good mechanic. Do you know one who lives near me?\"</p> <p>Similar needs exist between devices in highly automated environments, as when a drone lands in hangar and queries a dispatcher agent to find maintenance robots who can repair an ailing motor.</p> <p>We need a way to perform these workflows with DIDComm.</p>"},{"location":"features/0214-help-me-discover/#tutorial","title":"Tutorial","text":""},{"location":"features/0214-help-me-discover/#name-and-version","title":"Name and version","text":"<p>This is the \"Help Me Discover\" protocol, version 1.0. It is uniquely identified by the following PIURI:</p> <pre><code>https://didcomm.org/help-me-discover/1.0\n</code></pre>"},{"location":"features/0214-help-me-discover/#roles-and-states","title":"Roles and States","text":"<p>This protocol embodies a standard request-response pattern, and therefore has requester and responder roles. A <code>request</code> message describes what's wanted. A <code>response</code> message conveys whatever knowledge the responder wants to offer to be helpful. Standard state evolution applies:</p> <p></p> <p></p>"},{"location":"features/0214-help-me-discover/#requirements","title":"Requirements","text":"<p>The following requirements do not change this simple framework, but they introduce some complexity into the messages:</p> <ul> <li>It must be possible to describe what's wanted using rich criteria, combinable to arbitrary levels of detail with boolean operators.</li> <li>It is desirable that criteria should be expressed in a way that harmonizes with proof requests, which also need a criteria language. </li> <li>It must be possible for the responder to give partial answers: \"I do know a good mechanic, but not one that lives close to you.\"</li> <li>It must be possible for the responder to give compound answers: \"Here's an item that satisfies critiera 1 and 3, and here's a different itme that satisfies criteria 2 and 4.\"</li> <li>It must be possible for this protocol to precede another protocol (e.g., RFC 0028 Introduce Protocol) in such a way that what follows can refer back to items in this protocol in an unambiguous way, as in \"Here's an introduction to the party that I just told you about, that satisfies criteria 3 and 4 from the 'Help Me Discover' request you recently made.\"</li> </ul>"},{"location":"features/0214-help-me-discover/#messages","title":"Messages","text":""},{"location":"features/0214-help-me-discover/#request","title":"<code>request</code>","text":"<p>A simple request message looks like this:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/help-me-discover/1.0/request\",\n    \"@id\": \"a2248fb5-d46e-4898-a781-2f03e5f23964\"\n    // human-readable, localizable, optional\n    \"comment\": \"any ideas?\",\n    // please help me discover match for this\n    \"desired\": { \n        \"all\": [ // equivalent of boolean AND -- please match this list\n            // first criterion: profession must equal \"mechanic\"\n            {\"profession\": \"mechanic\", \"id\": \"prof\"},\n            // second criterion in \"all\" list: any of the following (boolean OR)\n            {\n                \"any\": [\n                    // average rating &gt; 3.5\n                    {\"averageRating\": 3.5, \"op\": \"&gt;\", \"id\": \"rating\"},\n                    // list of certifications contains \"ASE\"\n                    {\"certifications\": \"ASE\", \"op\": \"CONTAINS\", \"id\": \"cert\"},\n                    // zipCode must be in this list\n                    {\"zipCode\": [\"12345\", \"12346\"], \"op\": \"IN\", \"id\": \"where\"}\n                ], // end of \"any\" list\n                \"n\": 2, // match at least 2 from the list\n                \"id\": \"2-of-3\"\n            }\n        ],\n        \"id\": \"everything\"\n    }\n}\n</code></pre> <p>In plain language, this particular request says:</p> <p>Please help me discover someone who's a mechanic, and who possesses at least 2 of the following 3 characteristis: they have an average rating of at least 3.5 stars; they have an ASE certification; they reside in zip code 12345 or 12346.</p> <p>The data type of <code>desired</code> is a criterion object. A criterion object can be of type <code>all</code> (boolean AND), type <code>any</code> (boolean OR), or <code>op</code> (a particular attribute is tested against a value with a specific operator). The <code>all</code> and <code>any</code> objects can nest one another arbitrarily deep.</p> <p>Parsing these criteria, and performing matches against them, can be done with the SGL library, which has ports for JavaScript and python. Other ports should be trivial; it's only a couple hundred lines of code. The hardest part of the work is giving the library an object model that contains candidates against which matching can be done.</p> <p>Notice that each criterion object has an <code>id</code> property. This is helpful because responses can now refer to the criteria by number to describe what they've matched.</p> <p>See Reference for fancier examples of requests.</p>"},{"location":"features/0214-help-me-discover/#response","title":"<code>response</code>","text":"<p>A <code>response</code> message looks like this:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/help-me-discover/1.0/response\",\n    \"@id\": \"5f2396b5-d84e-689e-78a1-2fa2248f03e4\"\n    \"~thread\": { \"thid\": \"a2248fb5-d46e-4898-a781-2f03e5f23964\" }\n    // human-readable, localizable, optional\n    \"comment\": \"here's the best I've got\", \n    \"candidates\": [\n        {\n            \"id\": \"Alice\",\n            \"@type\": \"person\",\n            \"matches\": [\"prof\",\"rating\",\"cert\",\"2-of-3\",\"everything\"]\n        },\n        {\n            \"id\": \"Bob\",\n            \"@type\": \"drone\",\n            \"matches\": [\"prof\",\"cert\",\"where\",\"2-of-3\",\"everything\"]\n        },\n        {\n            \"id\": \"Carol\",\n            \"matches\": [\"rating\",\"cert\",\"where\"]\n        }\n    ]\n}\n</code></pre> <p>In plain language, this response says:</p> <p>I found 3 candidates for you. One that I'll call \"Alice\" matches everything except your <code>where</code> criterion. One called \"Bob\" matches everything except your <code>rating</code> criterion. Once called \"Carol\" matches your <code>rating</code>, <code>cert</code>, and <code>where</code> criteria, but because she didn't match <code>prof</code>, she wasn't an overall match.</p>"},{"location":"features/0214-help-me-discover/#using-a-help-me-discover-response-in-subsequent-interactions","title":"Using a \"Help me discover\" response in subsequent interactions","text":"<p>A <code>candidate</code> in a response message like the one shown above can be referenced in a subsequent interactions by using the RFC 0xxx: Linkable DIDComm Message Paths mechanism. For example, if Fred wanted to ask for an introduction to Bob after engaging in the sample request-response sequence shown above, he could send a <code>request</code> message in the Introduce Protocol, where <code>to</code> (the party to whom he'd like to be introduced) included a <code>discovered</code> property that referenced the <code>candidate</code> with <code>id</code> equal to <code>\"Bob\"</code>:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/introduce/1.0/request\",\n  \"@id\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\",\n  \"to\": {\n    \"discovered\": \"didcomm:///5f2396b5-d84e-689e-78a1-2fa2248f03e4/.candidates%7B.id+%3D%3D%3D+%22Bob%22%7D\"\n  }\n}\n</code></pre>"},{"location":"features/0214-help-me-discover/#accuracy-trustworthiness-and-best-effort","title":"Accuracy, Trustworthiness, and Best Effort","text":"<p>As with these types of interactions in \"real life\", the \"help me discover\" protocol cannot make any guarantees about the suitability of the answers it generates. The responder could be malicious, misinformed, or simply lazy. The contract for the protocol is:</p> <ul> <li>Requesters should attempt to ask reasonable, respectful, answerable questions</li> <li>Responders who wish to be helpful should make a best effort to address criteria accurately</li> <li>There is likely to be a useful relationship between what the requester asks for and what the responder provides</li> </ul> <p>The requester must verify results independently, if their need for trust is high.</p>"},{"location":"features/0214-help-me-discover/#privacy-considerations","title":"Privacy Considerations","text":"<p>Just because Alice knows that Bob is a political dissident who uses a particular handle in online forms does not mean Alice should divulge that information to anybody who engages in the \"Help Me Discover\" protocol with her. When matching criteria focus on people, Alice should be careful and use good judgment about how much she honors a particular request for discovery. In particular, if Alice possesses data about Bob that was shared with her in a previous Present Proof Protocol, the terms of sharing may not permit her to divulge what she knows about Bob to an arbitrary third party. See the Data Consent Receipt RFC.</p> <p>These issues probably do not apply when the thing being discovered is not a private individual.</p>"},{"location":"features/0214-help-me-discover/#reference","title":"Reference","text":""},{"location":"features/0214-help-me-discover/#discover-someone-who-can-prove","title":"Discover someone who can prove","text":"<p>A <code>request</code> message can ask for someone that is capable of proving using verifiable credentials, as per RFC 0037:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/help-me-discover/1.0/request\",\n    \"@id\": \"248fb52a-4898-a781-d46e-e5f239642f03\"\n    \"desired\": { \n        // either subjectRole or subjectDid:\n        //   - subjectRole has value of role in protocol\n        //   - subjectDid has value of a DID (useful in N-Wise settings)\n        \"verb\": \"prove\", \n        \"subjectRole\": \"introducer\", \n        \"car.engine.rating\": \"4\", \n        \"op\": \"&gt;\", \n        \"id\": \"engineRating\"\n    }\n}\n</code></pre> <p>In plain language, this particular request says:</p> <p>Please help me discover someone who can act as introducer in a protocol, and can prove that a car's rating &gt; 4.</p> <p>Another example might be:</p> <pre><code>{\n    \"@id\": \"a2248fb5-d46e-4898-a781-2f03e5f23964\",\n    \"@type\": \"https://didcomm.org/help-me-discover/1.0/request\",\n    \"comment\": \"blood glucose\",\n    \"desired\": {\n        \"all\": [\n            {\n                \"id\": \"prof\",\n                \"profession\": \"medical-lab\"\n            },\n            {\n                \"id\": \"glucose\",\n                \"provides\": {\n                    \"from\": \"bloodtests\",\n                    \"just\": [\n                        \"glucose\"\n                    ],\n                    \"subject\": \"did:peer:introducer\"\n                }\n            }\n        ],\n        \"id\": \"everything\"\n    }\n}\n</code></pre> <p>This says:</p> <p>Please help me discover  that has profession = \"medical-lab\" and can provide measurements of the introducer's blood-glucose levels"},{"location":"features/0214-help-me-discover/#drawbacks","title":"Drawbacks","text":"<p>If we are not careful, this protocol could be used to discover attributes about third parties in a way that subverts privacy. See Privacy Considerations.</p>"},{"location":"features/0214-help-me-discover/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Need to reconcile against general subprotocol/superprotocol communication.</li> </ul>"},{"location":"features/0214-help-me-discover/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0234-signature-decorator/","title":"Aries RFC 0234: Signature Decorator","text":"<ul> <li>Authors: Kyle Den Hartog</li> <li>Status: RETIRED</li> <li>Since: 2020-10-14</li> <li>Status Note: This decorator is retired, replaced with the use of the signed form of the attachment decorator (RFC 0017)</li> <li>Supersedes: this HIPE (never merged)</li> <li>Start Date: 2019-01-07</li> <li>Tags: feature, decorator</li> </ul>"},{"location":"features/0234-signature-decorator/#rfc-archived","title":"RFC ARCHIVED","text":"<p>DO NOT USE THIS RFC.</p> <p>Use the signed form of the attachment decorator (RFC 0017) instead of this decorator.</p>"},{"location":"features/0234-signature-decorator/#summary","title":"Summary","text":"<p>The <code>~sig</code> field-level decorator enables non-repudiation by allowing an Agent to add a digital signature over a portion of a DIDComm message.</p>"},{"location":"features/0234-signature-decorator/#motivation","title":"Motivation","text":"<p>While today we support a standard way of authenticating messages in a repudiable way, we also see the need for non-repudiable digital signatures for use cases where high authenticity is necessary such as signing a bank loan. There's additional beneficial aspects around having the ability to prove provenance of a piece of data with a digital signature. These are all use cases which would benefit from a standardized format for non-repudiable digital signatures.</p> <p>This RFC outlines a field-level decorator that can be used to provide non-repudiable digital signatures in DIDComm messages. It also highlights a standard way to encode data such that it can be deterministically verified later.</p>"},{"location":"features/0234-signature-decorator/#tutorial","title":"Tutorial","text":"<p>This RFC introduces a new field-level decorator named <code>~sig</code> and maintains a registry of standard Signature Schemes applicable with it.</p> <p>The <code>~sig</code> field decorator may be used with any field of data. Its value MUST match the json object format of the chosen signature scheme. </p> <p>We'll use the following message as an example:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/example/1.0/test_message\",\n    \"@id\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\",\n    \"msg\": {\n        \"text\": \"Hello World!\",\n        \"speaker\": \"Bob\"\n    }\n}\n</code></pre> <p>Digitally signing the <code>msg</code> object with the <code>ed25519sha256_single</code> scheme results in a transformation of the original message to this:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/example/1.0/test_message\",\n    \"@id\": \"df3b699d-3aa9-4fd0-bb67-49594da545bd\",\n    \"msg~sig\": {\n      \"@type\": \"https://didcomm.org/signature/1.0/ed25519Sha512_single\",\n      \"sig_data\": \"base64URL(64bit_integer_from_unix_epoch|msg_object)\",\n      \"signature\": \"base64URL(digital signature function output)\",\n      \"signer\": \"base64URL(inlined_signing_verkey)\"\n    }\n}\n</code></pre> <p>The original <code>msg</code> object has been replaced with its <code>~sig</code>-decorated counterpart in order to prevent message bloat.</p> <p>When an Agent receives a DIDComm message with a field decorated with <code>~sig</code>, it runs the appropriate signature scheme algorithm and restores the DIDComm message's structure back to its original form.</p>"},{"location":"features/0234-signature-decorator/#reference","title":"Reference","text":""},{"location":"features/0234-signature-decorator/#applying-the-digital-signature","title":"Applying the digital signature","text":"<p>In general, the steps to construct a <code>~sig</code> are:</p> <ol> <li>Choose a signature scheme. This determines the <code>~sig</code> decorator's message type URI (the <code>@type</code> seen above) and the signature algorithm.</li> <li>Serialize the JSON object to be authenticated to a sequence of bytes (<code>msg</code> in the example above). This will be the plaintext input to the signature scheme.</li> <li>Construct the contents of the new <code>~sig</code> object according to the chosen signature scheme with the plaintext as input.</li> <li>Replace the original object (<code>msg</code> in the example above) with the new <code>~sig</code> object. The new object's label MUST be equal to the label of the original object appended with \"~sig\".</li> </ol>"},{"location":"features/0234-signature-decorator/#verifying-the-digital-signature","title":"Verifying the digital signature","text":"<p>The outcome of a successful signature verification is the replacement of the <code>~sig</code>-decorated object with its original representation:</p> <ol> <li>Select the signature scheme according to the message type URI (<code>ed25519sha256_single</code> in the example above)</li> <li>Run the signature scheme's verification algorithm with the <code>~sig</code>-decorated object as input.</li> <li>The software MUST cease further processing of the DIDComm message if the verification algorithm fails.</li> <li>Replace the <code>~sig</code>-decorated object with the output of the scheme's verification algorithm.</li> </ol> <p>The end result MUST be semantically identical to the original DIDComm message before application of the signature scheme (eg. the original example message above).</p>"},{"location":"features/0234-signature-decorator/#additional-considerations","title":"Additional considerations","text":"<p>The data to authenticate is base64URL-encoded and then embedded as-is so as to prevent false negative signature verifications that could potentially occur when sending JSON data which has no easy way to canonicalize the structure. Rather, by including the exact data in Base64URL encoding, the receiver can be certain that the data signed is the same as what was received. </p>"},{"location":"features/0234-signature-decorator/#signature-schemes","title":"Signature Schemes","text":"<p>This decorator should support a specific set of signatures while being extensible. The list of current supported schemes are outlined below.</p> Signature Scheme Scheme Spec ed25519Sha512_single spec <p>TODO provide template in this RFC directory. </p> <p>To add a new signature scheme to this registry, follow the template provided to detail the new scheme as well as provide some test cases to produce and verify the signature scheme is working.</p>"},{"location":"features/0234-signature-decorator/#drawbacks","title":"Drawbacks","text":"<p>Since digital signatures are non-repudiable, it's worth noting the privacy implications of using this functionality. In the event that a signer has chosen to share a message using a non-repudiable signature, they forgo the ability to prevent the verifier from sharing this signature on to other parties. This has potentially negative implications with regards to consent and privacy. </p> <p>Therefore, this functionality should only be used if non-repudiable digital signatures are absolutely necessary.</p>"},{"location":"features/0234-signature-decorator/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>JSON Web Signatures are an alternative to this specification in widespread use. We diverged from this specification for the following reasons:</p> <ul> <li>Does not support our need for message decorators (sign only parts of a DIDComm message)</li> <li>Does not support signature-aggregation featured in schemes like BLS signatures.</li> </ul>"},{"location":"features/0234-signature-decorator/#prior-art","title":"Prior art","text":"<p>IETF RFC 7515 (JSON Web Signatures)</p>"},{"location":"features/0234-signature-decorator/#unresolved-questions","title":"Unresolved questions","text":"<p>Does there need to be an signature suite agreement protocol similar to TLS cipher suites? - No, rather the receiver of the message can send an error response if they're unable to validate the signature.</p> <p>How should multiple signatures be represented? - While not supported in this version, one solution would be to support <code>[digital_sig1, digital_sig2]</code> for <code>signature</code> and <code>[verkey1, verkey2]</code> for <code>signer</code>.</p>"},{"location":"features/0234-signature-decorator/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Static Agent - Python <code>ed25519sha256_single</code> Aries Framework - .NET <code>ed25519sha256_single</code> Aries Framework - Go <code>ed25519sha256_single</code>"},{"location":"features/0234-signature-decorator/ed25519sha256_single/","title":"The <code>ed25519sha256_single</code> signature scheme","text":""},{"location":"features/0234-signature-decorator/ed25519sha256_single/#tutorial","title":"Tutorial","text":""},{"location":"features/0234-signature-decorator/ed25519sha256_single/#application","title":"Application","text":"<p>This scheme computes a single ed25519 digital signature over the input message. Its output is a <code>~sig</code> object with the following contents:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/signature/1.0/ed25519Sha512_single\",\n    \"sig_data\": \"base64URL(64bit_integer_from_unix_epoch|msg)\",\n    \"signature\": \"base64URL(ed25519 signature)\",\n    \"signer\": \"base64URL(inlined_ed25519_signing_verkey)\"\n}\n</code></pre> <ul> <li><code>@type</code> MUST be <code>https://didcomm.org/signature/1.0/ed25519Sha512_single</code></li> <li><code>sig_data</code> MUST be the base64URL encoding of a 64-bit integer prepended to the message</li> <li><code>signature</code> MUST be the base64URL encoding of the resulting ed25519 digital signature over <code>sig_data</code></li> <li><code>signer</code> MUST be the base64URL encoding of the corresponding ed25519 public key used to sign <code>sig_data</code></li> </ul>"},{"location":"features/0234-signature-decorator/ed25519sha256_single/#verification","title":"Verification","text":"<p>The successful outcome of this scheme is the <code>plaintext</code>.</p> <ol> <li>base64URL-decode <code>signer</code></li> <li>base64URL-decode <code>signature</code></li> <li>Verify the ed25519 signature over <code>sig_data</code> with the key provided in <code>signer</code></li> <li>Further processing is halted if verification fails and an \"authentication failure\" error is returned</li> <li>base64URL-decode the <code>sig_data</code></li> <li>Strip out the first 8 bytes</li> <li>Return the remaining bytes</li> </ol>"},{"location":"features/0249-rich-schema-contexts/","title":"Aries RFC 0249: Aries Rich Schema Contexts","text":"<ul> <li>Authors: Brent Zundel, Ken Ebert, Alexander Shcherbakov</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes: </li> <li>Start Date: 2019-06-07 </li> <li>Tags: feature, rich-schemas</li> </ul>"},{"location":"features/0249-rich-schema-contexts/#summary","title":"Summary","text":"<p>Every rich schema object may have an associated <code>@context</code>. Contexts are JSON or JSON-LD objects. They are the standard mechanism for defining shared semantic meaning among rich schema objects.</p> <p>Context objects are processed in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0249-rich-schema-contexts/#motivation","title":"Motivation","text":"<p><code>@context</code> is JSON-LD\u2019s namespacing mechanism. Contexts allow rich schema objects to use a common vocabulary when referring to common attributes, i.e. they provide an explicit shared semantic meaning.</p>"},{"location":"features/0249-rich-schema-contexts/#tutorial","title":"Tutorial","text":""},{"location":"features/0249-rich-schema-contexts/#intro-to-context","title":"Intro to @context","text":"<p><code>@context</code> is a JSON-LD construct that allows for namespacing and the establishment of a common vocabulary.</p> <p>Context object is immutable, so it's not possible to update existing Context,  If the Context needs to be evolved, a new Context with a new version or name needs to be created.</p> <p>Context object may be stored in either JSON or JSON-LD format.</p>"},{"location":"features/0249-rich-schema-contexts/#example-context","title":"Example Context","text":"<p>An example of the <code>content</code> field of a Context object: <pre><code>{\n    \"@context\": [\n        \"did:sov:UVj5w8DRzcmPVDpUMr4AZhJ\",\n        \"did:sov:JjmmTqGfgvCBnnPJRas6f8xT\",\n        \"did:sov:3FtTB4kzSyApkyJ6hEEtxNH4\",\n        {\n            \"dct\": \"http://purl.org/dc/terms/\",\n            \"rdf\": \"http://www.w3.org/1999/02/22-rdf-syntax-ns#\",\n            \"rdfs\": \"http://www.w3.org/2000/01/rdf-schema#\",\n            \"Driver\": \"did:sov:2mCyzXhmGANoVg5TnsEyfV8\",\n            \"DriverLicense\": \"did:sov:36PCT3Vj576gfSXmesDdAasc\",\n            \"CategoryOfVehicles\": \"DriverLicense:CategoryOfVehicles\"\n        }\n    ]\n}\n</code></pre></p>"},{"location":"features/0249-rich-schema-contexts/#data-registry-storage","title":"Data Registry Storage","text":"<p>Aries will provide a means for writing contexts to and reading contexts from a verifiable data registry (such as a distributed ledger).</p> <p><code>@context</code> will be written to the ledger in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0249-rich-schema-contexts/#aries-data-registry-interface","title":"Aries Data Registry Interface","text":"<p>Aries Data Registry Interface methods for adding and retrieving <code>@context</code> from the ledger comply with the generic approach described in Rich Schema Objects Common.</p> <p>This means the following methods can be used: - <code>write_rich_schema_object</code> - <code>read_rich_schema_object_by_id</code> - <code>read_rich_schema_object_by_metadata</code></p>"},{"location":"features/0249-rich-schema-contexts/#reference","title":"Reference","text":"<p>More information on the Verifiable Credential data model use of <code>@context</code> may be found here.</p> <p>More information on <code>@context</code> from the JSON-LD specification may be found here and here.</p> <ul> <li>0250: Rich Schema Objects</li> <li>0420: Rich Schema Objects Common </li> </ul>"},{"location":"features/0249-rich-schema-contexts/#drawbacks","title":"Drawbacks","text":"<p>Requiring a <code>@context</code> for each rich schema object introduces more complexity.</p>"},{"location":"features/0249-rich-schema-contexts/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>A context object is required by the W3C Verifiable Credentials Data Model specification.</li> <li>It also supports rich schema capabilities for credentials.</li> </ul>"},{"location":"features/0249-rich-schema-contexts/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the proposed interface generic enough to support other data registries?</li> <li>We are not defining Rich Schema objects as DID DOCs for now. We may re-consider this in future once DID DOC format is finalized.</li> <li>It may make sense to extend DID specification to include using DID for referencing Rich Schema objects.</li> <li>The proposed canonicalization form of a content to be used for DID's id-string generation is in a Draft version, so we  may find a better way to do it.</li> <li>We don't check if the specified <code>@context</code> is valid by resolving all external links. </li> </ul>"},{"location":"features/0249-rich-schema-contexts/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0281-rich-schemas/","title":"Aries RFC 0281: Aries Rich Schemas","text":"<ul> <li>Authors: Brent Zundel, Ken Ebert, Alexander Shcherbakov</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes: </li> <li>Start Date: 2019-06-07 </li> <li>Tags: feature, rich-schemas</li> </ul>"},{"location":"features/0281-rich-schemas/#summary","title":"Summary","text":"<p>The proposed schemas are JSON-LD objects. This allows credentials issued according to the proposed schemas to have a clear semantic meaning, so that the verifier can know what the issuer intended. They support explicitly typed properties and semantic inheritance. A schema may include other schemas as property types, or extend another schema with additional properties. For example a schema for \"employee\" may inherit from the schema for \"person.\"</p> <p>Schema objects are processed in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0281-rich-schemas/#motivation","title":"Motivation","text":"<p>Many organizations, such as HL7 who publish the FHIR standard for heath care data exchange, have invested time and effort into creating data schemas that are already in use. Many schemas are shared publicly via web sites such as https://schema.org/, whose mission is, \"to create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond.\"</p> <p>These schemas ought to be usable as the basis for verifiable credentials.</p> <p>Although verifiable credentials are the primary use case for schemas considered in this document, other future uses may include defining message formats or objects in a verifiable data registry.  </p>"},{"location":"features/0281-rich-schemas/#interoperability","title":"Interoperability","text":"<p>Existing applications make use of schemas to organize and semantically describe data. Using those same schemas within Aries verifiable credentials provides a means of connecting existing applications with this emerging technology. This allows for an easy migration path for those applications to incorporate verifiable credentials and join the Aries ecosystem.</p> <p>Aries is only one of several verifiable credentials ecosystems. Using schemas which may be shared among these ecosystems allows for semantic interoperability between them, and enables a path toward true multi-lateral credential exchange.</p> <p>Using existing schemas, created in accordance with widely-supported common standards, allows Aries verifiable credentials to benefit from the decades of effort and thought that went into those standards and to work with other applications which also adhere to those standards.</p>"},{"location":"features/0281-rich-schemas/#re-use","title":"Re-use","text":"<p>Rich schemas can be re-used within the Aries credential ecosystem. Because these schemas are hierarchical and composable, even unrelated schemas may share partial semantic meaning due to the commonality of sub-schemas within both. For example, a driver license schema and an employee record are not related schemas, but both may include a person schema.</p> <p>A schema that was created for a particular use-case and accepted within a trust framework may be re-used within other trust frameworks for their use-cases. The visibility of these schemas across trust boundaries increases the ability of these schemas to be examined in greater detail and evaluated for fitness of purpose. Over time the schemas will gain reputation. </p>"},{"location":"features/0281-rich-schemas/#extensibility","title":"Extensibility","text":"<p>Applications that are built on top of the Aries frameworks can use these schemas as a basis for complex data objects for use within the application, or exposed through external APIs.</p>"},{"location":"features/0281-rich-schemas/#immutability","title":"Immutability","text":"<p>One important aspect of relying on schemas to provide the semantic meaning of data within a verifiable credential, is that the meaning of the credential properties should not change. It is not enough for entities within the ecosystem to have a shared understanding of the data in the present, it may be necessary for them to have an understanding of the credential at the time it was issued and signed. This depends on the trust framework within which the credential was issued and the needs of the parties involved. A verifiable data registry can provide immutable storage of schemas.</p>"},{"location":"features/0281-rich-schemas/#tutorial","title":"Tutorial","text":""},{"location":"features/0281-rich-schemas/#intro-to-schemas","title":"Intro to Schemas","text":"<p><code>schema</code> objects are used to enforce structure and semantic meaning on a set of data. They allow Issuers to assert, and Holders and Verifiers to understand, a particular semantic meaning for the properties in a credential.</p> <p>Rich schemas are JSON-LD objects. Examples of the type of schemas supported here may be found at schema.org. At this time we do not support other schema representations such as RDFS, JSON Schema, XML Schema, OWL, etc.</p>"},{"location":"features/0281-rich-schemas/#properties","title":"Properties","text":"<p>Rich Schema properties follow the generic template defined in Rich Schema Common.</p> <p>Rich Schema's <code>content</code> field is a JSON-LD-serialized string with the following fields:</p>"},{"location":"features/0281-rich-schemas/#id","title":"@id","text":"<p>A rich schema must have an <code>@id</code> property. The value of this property must be equal to the <code>id</code> field which is a DID (see Identification of Rich Schema Objects). </p> <p>A rich schema may refer to the <code>@id</code> of another rich schema to define a parent schema. A property of a rich schema may use the <code>@id</code> of another rich schema as the value of its <code>@type</code> or <code>@id</code> property.</p> <p>A mapping object will contain the <code>@id</code> of the rich schema being mapped.</p> <p>A presentation definition will contain the <code>@id</code> of any schemas a holder may use to present proofs to a verifier.</p>"},{"location":"features/0281-rich-schemas/#type","title":"@type","text":"<p>A rich schema must have a <code>@type</code> property. The value of this property must be (or map to, via a context object) a URI. </p>"},{"location":"features/0281-rich-schemas/#context","title":"@context","text":"<p>A rich schema may have a <code>@context</code> property. If present, the value of this property must be a context object or a URI which can be dereferenced to obtain a context object.</p>"},{"location":"features/0281-rich-schemas/#use-in-verifiable-credentials","title":"Use in Verifiable Credentials","text":"<p>These schemas will be used in conjunction with the JSON-LD representation of the verifiable credentials data model to specify which properties may be included as part of the verifiable credential's <code>credentialSubject</code> property, as well as the types of the property values.</p> <p>The <code>@id</code> of a rich schema may be used as an additional value of the  type property property of a verifiable credential. Because the <code>type</code> values of a verifiable credential are not required to be dereferenced, in order for the rich schema to support assertion of the structure and semantic meaning of the claims in the credential, an additional reference to the rich schema should be made through the  credentialSchema property. This may be done as a direct reference to the rich schema <code>@id</code>, or via another rich schema object which references the rich schema <code>@id</code> such as a  credential definition  as would  be the case  for anonymous credentials, as discussed in the mapping section of the rich schema overview RFC.</p>"},{"location":"features/0281-rich-schemas/#data-registry-storage","title":"Data Registry Storage","text":"<p>Aries will provide a means for writing <code>schema</code> objects to and reading <code>schema</code> objects from a verifiable data registry (such as a distributed ledger).</p> <p>As discussed previously, the ability to specify the exact schema that was used to issue a verifiable credential, and the assurance  that the meaning of that schema has not changed, may be critical for the trust framework. Verifiable data registries which provide immutability guarantees provide this assurance. Some alternative storage mechanisms do not. Hashlinks, which may be used to verify the hash of web-based schemas, are one example. These can be used inform a verifier that a schema has changed, but do not provide access to the original version of the schema in the event the original schema has been updated.</p>"},{"location":"features/0281-rich-schemas/#example-schema","title":"Example Schema","text":"<p>An example of the <code>content</code> field of a Rich Schema object: <pre><code>   \"@id\": \"did:sov:2f9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n   \"@type\": \"rdfs:Class\",\n   \"@context\": {\n    \"schema\": \"http://schema.org/\",\n    \"bibo\": \"http://purl.org/ontology/bibo/\",\n    \"dc\": \"http://purl.org/dc/elements/1.1/\",\n    \"dcat\": \"http://www.w3.org/ns/dcat#\",\n    \"dct\": \"http://purl.org/dc/terms/\",\n    \"dcterms\": \"http://purl.org/dc/terms/\",\n    \"dctype\": \"http://purl.org/dc/dcmitype/\",\n    \"eli\": \"http://data.europa.eu/eli/ontology#\",\n    \"foaf\": \"http://xmlns.com/foaf/0.1/\",\n    \"owl\": \"http://www.w3.org/2002/07/owl#\",\n    \"rdf\": \"http://www.w3.org/1999/02/22-rdf-syntax-ns#\",\n    \"rdfa\": \"http://www.w3.org/ns/rdfa#\",\n    \"rdfs\": \"http://www.w3.org/2000/01/rdf-schema#\",\n    \"schema\": \"http://schema.org/\",\n    \"skos\": \"http://www.w3.org/2004/02/skos/core#\",\n    \"snomed\": \"http://purl.bioontology.org/ontology/SNOMEDCT/\",\n    \"void\": \"http://rdfs.org/ns/void#\",\n    \"xsd\": \"http://www.w3.org/2001/XMLSchema#\",\n    \"xsd1\": \"hhttp://www.w3.org/2001/XMLSchema#\"\n  },\n  \"@graph\": [\n    {\n      \"@id\": \"schema:recipeIngredient\",\n      \"@type\": \"rdf:Property\",\n      \"rdfs:comment\": \"A single ingredient used in the recipe, e.g. sugar, flour or garlic.\",\n      \"rdfs:label\": \"recipeIngredient\",\n      \"rdfs:subPropertyOf\": {\n        \"@id\": \"schema:supply\"\n      },\n      \"schema:domainIncludes\": {\n        \"@id\": \"schema:Recipe\"\n      },\n      \"schema:rangeIncludes\": {\n        \"@id\": \"schema:Text\"\n      }\n    },\n    {\n      \"@id\": \"schema:ingredients\",\n      \"schema:supersededBy\": {\n        \"@id\": \"schema:recipeIngredient\"\n      }\n    }\n  ]\n</code></pre> recipeIngredient schema from  schema.org.</p>"},{"location":"features/0281-rich-schemas/#data-registry-storage_1","title":"Data Registry Storage","text":"<p>Aries will provide a means for writing contexts to and reading contexts from a verifiable data registry (such as a distributed ledger).</p> <p>A Schema will be written to the ledger in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0281-rich-schemas/#aries-data-registry-interface","title":"Aries Data Registry Interface","text":"<p>Aries Data Registry Interface methods for adding and retrieving a Schema from the ledger comply with the generic approach described in Rich Schema Objects Common.</p> <p>This means the following methods can be used: - <code>write_rich_schema_object</code> - <code>read_rich_schema_object_by_id</code> - <code>read_rich_schema_object_by_metadata</code></p>"},{"location":"features/0281-rich-schemas/#reference","title":"Reference","text":"<p>More information on the Verifiable Credential data model use of <code>schemas</code> may be found here.</p> <ul> <li>0250: Rich Schema Objects</li> <li>0420: Rich Schema Objects Common </li> </ul>"},{"location":"features/0281-rich-schemas/#drawbacks","title":"Drawbacks","text":"<p>Rich schema objects introduce more complexity.</p>"},{"location":"features/0281-rich-schemas/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>A <code>schema</code> object is supported by the W3C Verifiable Credentials Data Model specification.</li> <li>It supports rich schema capabilities for credentials.</li> </ul>"},{"location":"features/0281-rich-schemas/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the proposed interface generic enough to support other data registries?</li> <li>We are not defining Rich Schema objects as DID DOCs for now. We may re-consider this in future once DID DOC format is finalized.</li> <li>It may make sense to extend DID specification to include using DID for referencing Rich Schema objects.</li> <li>The proposed canonicalization form of a content to be used for DID's id-string generation is in a Draft version, so we  may find a better way to do it.</li> <li>We don't check if the specified <code>@context</code> is valid by resolving all external links.</li> <li>We may introduce more discovery ../../features in future.</li> <li>Future work may include methods for anchoring to Indy a Rich Schema which is immutably stored elsewhere.</li> </ul>"},{"location":"features/0281-rich-schemas/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0303-v01-credential-exchange/","title":"Aries RFC 0303: V0.1 Credential Exchange (Deprecated)","text":"<ul> <li>Authors: Tomislav Markovski, Andrew Whitehead, Stephen Curran</li> <li>Status: RETIRED</li> <li>Since: 2019-11-12</li> <li>Status Note: Deprecated, but in common use in existing deployments of Aries agents. See Implementations </li> <li>Supersedes: HackMD Document</li> <li>Start Date: 2019-03-13</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0303-v01-credential-exchange/#summary","title":"Summary","text":"<p>The 0.1 version of the ZKP Credential Exchange protocol (based on Hyperledger Indy) covering both issuing credentials and presenting proof. These messages were implemented to enable demonstrating credential exchange amongst interoperating agents for IIW 28 in Mountain View, CA. The use of these message types continues to today (November 2019) and so they are being added as an RFC for historical completeness and to enable reference in Aries Interop Profile.</p>"},{"location":"features/0303-v01-credential-exchange/#motivation","title":"Motivation","text":"<p>Enables the exchange of Indy ZKP-based verifiable credentials - issuing verifiable credentials and proving claims from issued verifiable credentials.</p>"},{"location":"features/0303-v01-credential-exchange/#tutorial","title":"Tutorial","text":"<p>This RFC defines a minimal credential exchange protocols. For more details of a complete credential exchange protocol, see the Issue Credentials and Present Proof RFCs.</p>"},{"location":"features/0303-v01-credential-exchange/#issuing-a-credential","title":"Issuing a credential:","text":"<ol> <li>The issuer sends the holder a Credential Offer</li> <li>The holder responds with a Credential Request to the issuer</li> <li>The issuer sends a Credential Issue to the holder, issuing the credential</li> </ol>"},{"location":"features/0303-v01-credential-exchange/#presenting-a-proof","title":"Presenting a proof:","text":"<ol> <li>The verifier sends the holder/prover a Proof Request</li> <li>The holder/prover constructs a proof to satisfy the proof requests and sends the proof to the verifier</li> </ol>"},{"location":"features/0303-v01-credential-exchange/#reference","title":"Reference","text":"<p>The following messages are supported in this credential exchange protocol.</p>"},{"location":"features/0303-v01-credential-exchange/#issue-credential-protocol","title":"Issue Credential Protocol","text":"<p>The process begins with a <code>credential-offer</code>. The thread decorator is implied for all messages except the first.</p> <p>The  element is used in most messages and is the string returned from libindy for the given purpose - an escaped JSON string. The agent must process the string if there is a need to extract a data element from the JSON - for example to get the <code>cred-def-id</code> from the <code>credential-offer</code>. <p>Acknowledgments and Errors should be signalled via adopting the standard <code>ack</code> and <code>problem-report</code> message types, respectively.</p>"},{"location":"features/0303-v01-credential-exchange/#credential-offer","title":"Credential Offer","text":"<pre><code>{\n    \"@type\": \"https://didcomm.org/credential-issuance/0.1/credential-offer\",\n    \"@id\": \"&lt;uuid-offer&gt;\",\n    \"comment\": \"some comment\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"offer_json\": &lt;libindy json string&gt;\n}\n</code></pre>"},{"location":"features/0303-v01-credential-exchange/#credential-request","title":"Credential Request","text":"<pre><code>{\n    \"@type\": \"https://didcomm.org/credential-issuance/0.1/credential-request\",\n    \"@id\": \"&lt;uuid-request&gt;\",\n    \"comment\": \"some comment\",\n    \"request\": &lt;libindy json string&gt;\n}\n</code></pre>"},{"location":"features/0303-v01-credential-exchange/#credential-issue","title":"Credential Issue","text":"<pre><code>{\n    \"@type\": \"https://didcomm.org/credential-issuance/0.1/credential-issue\",\n    \"@id\": \"&lt;uuid-credential&gt;\",\n    \"issue\": &lt;libindy json string&gt;\n}\n</code></pre>"},{"location":"features/0303-v01-credential-exchange/#presentation-protocol","title":"Presentation Protocol","text":"<p>The message family to initiate a presentation. The verifier initiates the process. The thread decorator is implied on every message other than the first message. The <code>ack</code> and <code>problem-report</code> messages are to be adopted by this message family.</p>"},{"location":"features/0303-v01-credential-exchange/#presentation-request","title":"Presentation Request","text":"<pre><code>{\n    \"@type\": \"https://didcomm.org/credential-presentation/0.1/presentation-request\",\n    \"@id\": \"&lt;uuid-request&gt;\",\n    \"comment\": \"some comment\",\n    \"request\": &lt;libindy json string&gt;\n}\n</code></pre>"},{"location":"features/0303-v01-credential-exchange/#credential-presentation","title":"Credential Presentation","text":"<pre><code>{\n    \"@type\": \"https://didcomm.org/credential-presentation/0.1/credential-presentation\",\n    \"@id\": \"&lt;uuid-presentation&gt;\",\n    \"comment\": \"some comment\",\n    \"presentation\": &lt;libindy json string&gt;\n}\n</code></pre>"},{"location":"features/0303-v01-credential-exchange/#drawbacks","title":"Drawbacks","text":"<p>The RFC is not technically needed, but is useful to have as an Archived RFC of a feature in common usage.</p>"},{"location":"features/0303-v01-credential-exchange/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>N/A</p>"},{"location":"features/0303-v01-credential-exchange/#prior-art","title":"Prior art","text":"<p>N/A</p>"},{"location":"features/0303-v01-credential-exchange/#unresolved-questions","title":"Unresolved questions","text":"<p>N/A</p>"},{"location":"features/0303-v01-credential-exchange/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Framework - .NET .NET framework for building agents of all types; MISSING test results Streetcred.id Commercial mobile and web app built using Aries Framework - .NET; MISSING test results Aries Cloud Agent - Python Contributed by the government of British Columbia.; MISSING test results OSMA - Open Source Mobile Agent Open SOurce mobile app built on Aries Framework - .NET; MISSING test results"},{"location":"features/0309-didauthz/","title":"Aries RFC 0309: DIDAuthZ","text":"<ul> <li>Authors: George Aristy SecureKey Technologies</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes:</li> <li>Start Date: 2019-09-27</li> <li>Tags: feature, credentials</li> </ul>"},{"location":"features/0309-didauthz/#summary","title":"Summary","text":"<p>DIDAuthZ is an attribute-based resource discovery and authorization protocol for Layer 2 of the ToIP Stack<sup>[1]</sup>. It enables a requesting party to discover protected resources and obtain credentials that grant limited access to these resources with the authorization of their owner. These credentials can be configured such that the requesting party may further delegate unto others the authority to access these resources on their behalf.</p>"},{"location":"features/0309-didauthz/#motivation","title":"Motivation","text":"<p>In the online world, individuals frequently consent to a service provider gaining access to their protected resources located on a different service provider. Individuals are challenged with an authentication mechanism, informed of the resources being requested, consent to the use of their resources, and can later revoke access at any time. OAuth 2.0<sup>[6]</sup>, and other frameworks built on top of it, were developed to address this need.</p> <p>A DIDComm protocol<sup>[2]</sup> can address these use cases and enhance them with secure end-to-end encryption<sup>[3]</sup> independent of the transport used. The risk of correlation of the individual's relationships with other parties can be mitigated with the use of peer DIDs<sup>[4]</sup>. With a sufficiently flexible grammar, the encoding of the access scope can be fine-grained down to the individual items that are requested, congruent with the principle of selective disclosure<sup>[5]</sup>.</p> <p>It is expected that future higher-level protocols and governance frameworks<sup>[1]</sup> can leverage DIDAuthZ to enable authorized sharing of an identity owner's attributes held by a third party.</p>"},{"location":"features/0309-didauthz/#tutorial","title":"Tutorial","text":""},{"location":"features/0309-didauthz/#roles","title":"Roles","text":"<p>DIDAuthZ adapts the following roles from OAuth 2.0<sup>[6]</sup> and UMA 2.0<sup>[7]</sup>:</p> Resource Server (RS) An agent holding the protected resources. These resources MAY be credentials of which the subject MAY be a third party identity owner. The RS is also a resource owner at the root of the chain of delegation. Resource Owner (RO) An agent capable of granting access to a protected resource. The RO is a delegate of the RS to the extent encoded in a credential issued by the RS. Authorization Server (AS) An agent that protects, on the resource owner's behalf, resources held by the resource server. The AS is a delegate of the RO capable of issuing and refreshing access credentials. Requesting Party (RP) An agent that requests access to the resources held by the resource server. The RP is a delegate of the AS to the extent encoded in a credential issued by the AS. <p></p>"},{"location":"features/0309-didauthz/#transaction-flow","title":"Transaction Flow","text":"<p>The requesting party initiates a transaction by communicating directly with the authorization server with prior knowledge of their location.</p> <p></p> <p>(1) RP requests a resource</p> <p>The requesting party requests the authorization server for a resource. A description of the resource requested and the desired access is included in this request.</p> <p>TODO does the request need to also include proof of \"user engagement\"?</p> <p>(2) AS requests authorization from the RO</p> <p>The authorization server processes the request and determines if the resource owner's authorization is needed. The authorization server MUST obtain the resource owner's authorization if no previous grant of authorization is found in valid state. Otherwise, the authorization server MAY issue new access credentials to the requesting party without any interaction with the resource owner. In such a case, the authorization server MUST revoke all access credentials previously issued to the requesting party.</p> <p>The authorization server interacts with the resource owner through their existing DIDComm connection to obtain their authorization.</p> <p>(3) AS issues an access token to the RP</p> <p>The authorization server issues access credentials to the requesting party.</p> <p>(4) AS introduces the RP to the RS</p> <p>The authorization server connects the requesting party to the resource server via the Introduce Protocol<sup>[9]</sup>.</p>"},{"location":"features/0309-didauthz/#access-credentials","title":"Access Credentials","text":"<p>Access credentials are chained delegate credentials<sup>[17]</sup> used to access the protected resources. Embedded in them is proof of the chain of delegation and authorization.</p> <p></p> <p>(1) RS delegates unto RO</p> <p>The resource server issues a credential to the resource owner that identifies the latter as the owner of a subset of resources hosted by the former. It also identifies the resource owner's chosen authorization server in their respective role. The resources will also have been registered at the authorization server.</p> <p>(2) RO delegates unto AS</p> <p>The resource owner issues a grant-type credential to the authorization server at the end of each AS-RO interaction. This credential is derived from the one issued by the RS. It authorizes the AS to authorize access to the RP with a set scope.</p> <p>(3) AS issues access credential to RP</p> <p>The authorization server issues an access credential to the requesting party derived from the grant credential issued by the resource owner for this transaction. This credential encodes the same access scope as found in the parent credential.</p> <p>(4) RP presents proof of access credential to RS</p> <p>The requesting party shows proof of this access credential when attempting to access the resource on the resource server.</p>"},{"location":"features/0309-didauthz/#revocation","title":"Revocation","text":"<p>The resource server makes available a revocation registry and grants read/write access to both the resource owner and the authorization server.</p> <p></p>"},{"location":"features/0309-didauthz/#reference","title":"Reference","text":""},{"location":"features/0309-didauthz/#discovery-of-authorization-servers","title":"Discovery of authorization servers","text":"<p>The resource owner advertises their chosen authorization server to other parties with a new type of <code>service</code> definition in their DID document<sup>[8]</sup>:</p> <pre><code>{\n  \"@context\": [\"https://www.w3.org/ns/did/v1\", \"https://w3id.org/security/v1\"],\n  \"id\": \"did:example:123456789abcdefghi\",\n  \"publicKey\": [{\n    \"id\": \"did:example:123456789abcdefghi#keys-1\",\n    \"type\": \"Ed25519VerificationKey2018\",\n    \"controller\": \"did:example:123456789abcdefghi\",\n    \"publicKeyBase58\": \"H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV\"\n  }],\n  \"service\": [{\n    \"id\": \"did:example:123456789abcdefghi#did-authz\",\n    \"type\": \"did-authz\",\n    \"serviceEndpoint\": \"did:example:xyzabc456#auth-svc\"\n  }]\n}\n</code></pre> <p>TODO define json-ld context for new service type</p> <p>The mechanisms by which the resource owner discovers authorization servers are beyond the scope of this specification.</p> <p>Authorization servers MUST make available a DID document containing metadata about their service endpoints and capabilities at a well-known location.</p> <p>TODO define \"well-known locations\" in several transports</p> <p>TODO register well-known URI for http transport as per IETF RFC 5785</p>"},{"location":"features/0309-didauthz/#discovery-of-revocation-registry","title":"Discovery of revocation registry","text":"<p>TODO</p>"},{"location":"features/0309-didauthz/#resources","title":"Resources","text":""},{"location":"features/0309-didauthz/#describing-resources","title":"Describing resources","text":"<p>TODO</p>"},{"location":"features/0309-didauthz/#describing-access-scope","title":"Describing access scope","text":"<p>TODO</p>"},{"location":"features/0309-didauthz/#registering-resources","title":"Registering resources","text":"<p>TODO</p>"},{"location":"features/0309-didauthz/#requesting-resources","title":"Requesting resources","text":"<p>TODO</p>"},{"location":"features/0309-didauthz/#protocol-messages","title":"Protocol messages","text":"<p>TODO</p>"},{"location":"features/0309-didauthz/#gathering-consent-from-the-resource-owner","title":"Gathering consent from the resource owner","text":"<p>TODO didcomm messages</p>"},{"location":"features/0309-didauthz/#credentials","title":"Credentials","text":"<p>TODO format of these credentials, JWTs or JSON-LDs?</p> <p>TODO</p>"},{"location":"features/0309-didauthz/#drawbacks","title":"Drawbacks","text":"<p>(None)</p>"},{"location":"features/0309-didauthz/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"features/0309-didauthz/#prior-art","title":"Prior art","text":"<p>Aries RFC 0167</p> <p>The Data Consent Lifecycle<sup>[10]</sup> is a reference implementation of data privacy agreements based on the GDPR framework<sup>[11]</sup>. The identity owner grants access to a verifier in the form of a proof of possession of a credential issued by the issuer. The identity owner may grant access to several verifiers in this manner. Access cannot be revoked on a per-verifier basis. To revoke access to a verifier, the identity owner's credential needs to be revoked, which in turn revokes all existing proofs the identity owner may have provided. The identity owner does not have the means to revoke access to a third party without directly involving the issuer.</p> <p>OAuth 2.0</p> <p>OAuth 2.0<sup>[6]</sup> is a role-based authorization framework in widespread use that enables a third-party to obtain limited access to HTTP services on behalf of a resource owner. The access token's scope is a simple data structure composed of space-delimited strings more suitable for a role-based authorization model than an attribute-based model.</p> <p>Although allowing for different types of tokens to be issued to clients as credentials, only the use of bearer tokens was formalized<sup>[12]</sup>. As a result, most implementations use bearer tokens as credentials. An expiry is optionally set on these tokens, but they nevertheless pose an unacceptable security risk in an SSI context and other contexts with high-value resources and need extra layers of security to address the risks of theft and impersonation. M. Jones and D. Hardt recommend the use of TLS to protect these tokens <sup>[12]</sup>, but this transport is not guaranteed as a DIDComm message travels from the sender to the recipient. The specification for mac tokens<sup>[13]</sup> never materialized and its TLS Channel Binding Support was never specified, therefore not solving the issue of unwanted TLS termination in a hop. There is ongoing work in the draft for OAuth 2.0 Token Binding<sup>[14]</sup> that binds tokens to the cryptographic key material produced by the client, but it also relies on TLS as the means of transport.</p> <p>OpenID Connect 1.0</p> <p>OIDC<sup>[15]</sup> is \"a simple layer on top of the OAuth 2.0 protocol\" that standardizes simple data structures that contain claims about the end-user's identity.</p> <p>Being based upon OAuth 2.0, it suffers from the same security weaknesses - see the extensive section on Security Considerations that references the OAuth 2.0 Thread Model and Security Considerations<sup>[16]</sup>.</p> <p>User-Managed Access 2.0</p> <p>UMA<sup>[7]</sup> is an extension to OAuth 2.0 that formalizes the authorization server's role as a delegate of the resource owner in order for the latter to grant access to requesting parties asynchronously and independently from the time of access. It relies on pre-defined resource scopes<sup>18</sup> and is thus more suited to role-based access control.</p>"},{"location":"features/0309-didauthz/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"features/0309-didauthz/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0309-didauthz/#references","title":"References","text":"<ol> <li>Matthew Davie, Dan Gisolfi, Daniel Hardman, John Jordan, Darrell O'Donnell, Drummond Reed: Aries RFC 0289: Trust over IP Stack, status PROPOSED</li> <li>Daniel Hardman: Aries RFC 0005 - DIDComm, status DEMONSTRATED</li> <li>Kyle Den Hartog, Stephen Curran, Mike Lodder: Aries RFC 0019 - Encryption Envelope, status ACCEPTED</li> <li>Oskar Deventer, Christian Lundkvist, Marton Csernai, Kyle Den Hartor, Markus Sabadello, Sam Curren, Dan Gisolfi, Mike Varley, Sven Hammannn, John Jordan, Lovesh Harchandani, Devin Fisher, Tobias Looker, Brent Zundel, Stephen Currant: Peer DID Method Specification, W3C Editor's Draft 16 October 2019</li> <li>The Sovrin Foundation: The Sovrin Glossary, v2.0</li> <li>Ed. D. Hardt: IETF RFC 6749 - The OAuth 2.0 Authorization Framework, October 2012</li> <li>Ed. E. Maler, M. Machulak, J. Richer, T. Hardjono: IETF I-D - User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization, February 2019</li> <li>Drummond Reed, Manu Sporny, Dave Longley, Christopher Allen, Ryan Grant, Markus Sabadello: Decentralized Identifiers (DIDs) v1.0,  W3C First Public Working Draft 07 November 2019</li> <li>Daniel Hardman, Sam Curren, Stephen Curran, Tobias Looker, George Aristy: Aries RFC 0028 - Introduce Protocol 1.0, status PROPOSED</li> <li>Jan Lindquist, Dativa; Paul Knowles, Dativa; Mark Lizar, OpenConsent; Harshvardhan J. Pandit, ADAPT Centre, Trinity College Dublin: Aries RFC 0167 - Data Consent Lifecycle, status PROPOSED</li> <li>Intersoft Consulting: General Data Protection Regulation, November 2019</li> <li>M. Jones, D. Hardt: IETF RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage, October 2012</li> <li>J. Richer, W. Mills, P. Hunt: IETF I-D - OAuth 2.0 Message Authentication Code (MAC) Tokens, January 2014</li> <li>M. Jones, B. Campbell, J. Bradley, W. Denniss: IETF I-D - OAuth 2.0 Token Binding, October 2018</li> <li>N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, C. Mortimore: OpenID Connect Core 1.0, November 2014</li> <li>T. Lodderstedt, M. McGloin, P. Hunt: OAuth 2.0 Thread Model nd Security Considerations, January 2013</li> <li>Daniel Hardman, Lovesh Harchandani: Aries RFC 0104 - Chained Credentials, status PROPOSED</li> <li>E. Maler, M. Machulak, J. Richer, T. Hardjono: Federated Authorization for User-Managed Access (UMA) 2.0, February 2019</li> </ol>"},{"location":"features/0317-please-ack/","title":"Aries RFC 0317: Please ACK Decorator","text":"<ul> <li>Authors: Daniel Hardman, Timo Glastra</li> <li>Status: RETIRED</li> <li>Since: 2019-12-26</li> <li>Status Note: Attempts at implementation demonstrate that a general purpose <code>~please_ack</code> capability is not practical, and needs to be implemented on a per protocol basis, for protocols where the functionality makes sense.</li> <li>Start Date: 2018-12-26</li> <li>Tags: feature, decorator</li> </ul>"},{"location":"features/0317-please-ack/#retirement-of-please_ack","title":"Retirement of <code>~please_ack</code>","text":"<p>The <code>please_ack</code> decorator was initially added to Aries Interop Protocol 2.0. However, this was done prior to attempts at an implementation. When such an attempt was made, it was found that the decorator is not practical as a general purpose mechanism. The capability assumed that the feature would be general purpose and could be applied outside of the protocols with which it was used. That assumption proved impossible to implement. The inclusion of the <code>~please_ack</code> decorator cannot be implemented without altering any protocol with which it is used, and so it is not practical. Instead, any protocols that can benefit from such a feature can be extended to explicitly support the feature.</p> <p>For the <code>\"on\": [\"OUTCOME\"]</code> type of ACK, the problem manifests in two ways. First, the definition of <code>OUTCOME</code> is protocol (and in fact, protocol message) specific. The definition of \"complete\" for each message is specific to each message, so there is no \"general purpose\" way to know when an <code>OUTCOME</code> ACK is to be sent. Second, the addition of a <code>~please_ack</code> decorator changes the protocol state machine for a given protocol, introducing additional states, and hence, additional state handling. Supporting <code>\"on\": [\"OUTCOME\"]</code> processing requires making changes to all protocols, which would be better handled on a per protocol basis, and where useful (which, it was found, is rare), adding messages and states. For example, what is the point of an extra <code>ACK</code> message on an <code>OUTCOME</code> in the middle of a protocol that itself results in the sending of the response message?</p> <p>Our experimentation found that it would be easier to achieve a general purpose <code>\"on\": [\"RECEIPT\"]</code> capability, but even then there were problems. Most notably, the capability is most useful when added to the last message of a protocol, where the message sender would like confirmation that the recipient got the message. However, it is precisely that use of the feature that also introduces breaking changes to the protocol state machine for the protocols to which it applies, requiring per protocol updates. So while the feature would be marginally useful in some cases, the complexity cost of the capability -- and the lack of demand for its creation -- led us to retire the entire RFC.</p> <p>For more details on the great work done by Alexander Sukhachev @alexsdsr, please see these pull requests, including both the changes proposed in the PRs, and the subsequent conversations about the ../../features.</p> <ul> <li>Aries Cloud Agent Python PR 2540 - PleaseAck.md document</li> <li>Aries Cloud Agent Python PR 2546 - DRAFT: please_ack support PoC for the 0453-issue-credential-v2 protocol</li> <li>Aries RFCs - Update the 'unresolved questions' section of the 0317-please-ack RFC</li> </ul> <p>Much thanks for Alexander for the effort he put into trying to implement this capability.</p>"},{"location":"features/0317-please-ack/#summary","title":"Summary","text":"<p>Explains how one party can request an acknowledgment to and clarify the status of processes.</p>"},{"location":"features/0317-please-ack/#motivation","title":"Motivation","text":"<p>An acknowledgment or ACK is one of the most common procedures in protocols of all types. The ACK message is defined in Aries RFC 0015-acks and is adopted into other protocols for use at explicit points in the execution of a protocol. In addition to receiving ACKs at predefined places in a protocol, agents also need the ability to request additional ACKs at other points in an instance of a protocol. Such requests may or may not be answered by the other party, hence the \"please\" in the name of decorator.</p>"},{"location":"features/0317-please-ack/#tutorial","title":"Tutorial","text":"<p>If you are not familiar with the tutorial section of the ACK message,please review that first.</p> <p>Agents interact in very complex ways. They may use multiple transport mechanisms, across varied protocols, through long stretches of time. While we usually expect messages to arrive as sent, and to be processed as expected, a vital tool in the agent communication repertoire is the ability to request and receive acknowledgments to confirm a shared understanding.</p>"},{"location":"features/0317-please-ack/#requesting-an-ack-please_ack","title":"Requesting an ack (<code>~please_ack</code>)","text":"<p>A protocol may stipulate that an ack is always necessary in certain circumstances. Launch mechanics for spacecraft do this, because the stakes for a miscommunication are so high. In such cases, there is no need to request an ack, because it is hard-wired into the protocol definition. However, acks make a channel more chatty, and in doing so they may lead to more predictability and correlation for point-to-point communications. Requiring an ack is not always the right choice. For example, an ack should probably be optional at the end of credential issuance (\"I've received your credential. Thanks.\") or proving (\"I've received your proof, and it satisfied me. Thanks.\").</p> <p>In addition, circumstances at a given moment may make an ad hoc ack desirable even when it would normally NOT be needed. Suppose Alice likes to bid at online auctions. Normally she may submit a bid and be willing to wait for the auction to unfold organically to see the effect. But if she's bidding on a high-value item and is about to put her phone in airplane mode because her plane's ready to take off, she may want an immediate ACK that the bid was accepted.</p> <p>The dynamic need for acks is expressed with the <code>~please_ack</code> message decorator. An example of the decorator looks like this:</p> <pre><code>{\n  \"~please_ack\": {\n    \"on\": [\"RECEIPT\"]\n  }\n}\n</code></pre> <p>This says, \"Please send me an ack as soon as you receive this message.\"</p>"},{"location":"features/0317-please-ack/#examples","title":"Examples","text":"<p>Suppose AliceCorp and Bob are involved in credential issuance. Alice is an issuer; Bob wants to hold the issued credential.</p>"},{"location":"features/0317-please-ack/#on-receipt","title":"On Receipt","text":"<p>In the final required message of the <code>issue-credential</code> protocol, AliceCorp sends the credential to Bob. But AliceCorp wants to know for sure that Bob has received it, for its own accounting purposes. So it decorates the final message with an ack request:</p> <pre><code>{\n  \"~please_ack\": {\n    \"on\": [\"RECEIPT\"]\n  }\n}\n</code></pre> <p>Bob honors this request and returns an <code>ack</code> as soon as he receives it and stores its payload.</p>"},{"location":"features/0317-please-ack/#on-outcome","title":"On Outcome","text":"<p>Same as with the previous example, AliceCorp wants an acknowledgement from Bob. However, in contrast to the previous example that just requests an acknowledgement on receipt of message, this time AliceCorp wants to know for sure Bob verified the validity of the credential. To do this AliceCorp decorates the <code>issue-credential</code> message with an ack request for the <code>OUTCOME</code>.</p> <pre><code>{\n  \"~please_ack\": {\n    \"on\": [\"OUTCOME\"]\n  }\n}\n</code></pre> <p>Bob honors this request and returns an <code>ack</code> as soon as he has verified the validity of the issued credential.</p>"},{"location":"features/0317-please-ack/#reference","title":"Reference","text":""},{"location":"features/0317-please-ack/#please_ack-decorator","title":"<code>~please_ack</code> decorator","text":""},{"location":"features/0317-please-ack/#on","title":"<code>on</code>","text":"<p>The only field for the please ack decorator. Required array. Describes the circumstances under which an ack is desired. Possible values in this array include <code>RECEIPT</code> and <code>OUTCOME</code>.</p> <p>If both values are present, it means an acknowledgement is requested for both the receipt and outcome of the message</p>"},{"location":"features/0317-please-ack/#receipt","title":"<code>RECEIPT</code>","text":"<p>The <code>RECEIPT</code> acknowledgement is the easiest ack mechanism and requests that an ack is sent on receipt of the message. This way of requesting an ack is to verify whether the other agent successfully received the message. It implicitly means the agent was able to unpack the message, to see</p>"},{"location":"features/0317-please-ack/#outcome","title":"<code>OUTCOME</code>","text":"<p>The <code>OUTCOME</code> acknowledgement is the more advanced ack mechanism and requests that an ack is sent on outcome of the message. By default outcome means the message has been handled and processed without business logic playing a role in the decision.</p> <p>In the context of the issue credential protocol, by default, this would mean an ack is requested as soon as the received credentials is verified to be valid. It doesn't mean the actual contents of the credential are acknowledged. For the issue credential protocol it makes more sense to send the acknowledgement after the contents of the credential have also been verified.</p> <p>Therefore protocols can override the definition of outcome in the context of that protocol. Examples of protocols overriding this behavior are Issue Credential Protocol 2.0, Present Proof Protocol 2.0 and Revocation Notification Protocol 1.0</p>"},{"location":"features/0317-please-ack/#drawbacks","title":"Drawbacks","text":"<p>None specified.</p>"},{"location":"features/0317-please-ack/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>The first version of this RFC was a lot more advanced, but also introduced a lot of complexities. A lot of complex ../../features have been removed so it could be included in AIP 2.0 in a simpler form. More advanced ../../features from the initial RFC can be added back in when needed.</p>"},{"location":"features/0317-please-ack/#prior-art","title":"Prior art","text":"<p>None specified.</p>"},{"location":"features/0317-please-ack/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Security and privacy implications of <code>~please_ack</code> decorators. Could they be used to mount a denial-of-service attack or to sniff info that's undesirable?</li> <li>Signed (Non-repudiable) acks. How do you ask for an ACK that commits its sender to the acknowledgment in a way that's provable to third parties?</li> <li>Multiplexed acks. How do you ask for, and supply, an ACK to all of Alice's agents instead of just to the one who sent the ACK? Does each agent need to request the ACK separately? Are there denial-of-service or other security issues?</li> </ul>"},{"location":"features/0317-please-ack/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0327-crypto-service/","title":"Aries RFC 0327: Crypto service Protocol 1.0","text":"<ul> <li>Authors: Robert Mitwicki, Wolfgang Lamot</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes:</li> <li>Start Date: 2019-11-01</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0327-crypto-service/#summary","title":"Summary","text":"<p>Within decentralized data economy with user-centric approach the user is the one who should control data flows and all interaction even on 3<sup>rd</sup> parties platforms. To achieve that we start to talk about access instead of ownership of the data. Within the space we can identify some services which are dealing with the users data but they don't necessarily need to be able to see the data. In this category we have services like archive, data vaults, data transportation (IM, Email, Sent file), etc. To be able to better support privacy in such cases this document proposes a protocol which uses underlying security mechanisms within agents like <code>Lox</code> to provide an API for cryptographic operations like asymetric encryption/decryption, signature/verification, delegation (proxy re-encryption) to let those services provide an additional security layer on their platform within connection to SSI wallet agents.</p>"},{"location":"features/0327-crypto-service/#motivation","title":"Motivation","text":"<p>Identity management and key management are complex topics with which even big players have problems. To help companies and their products build secure and privacy preserving services with SSI they need a simple mechanism to get access to the cryptographic operations within components of the wallets.</p>"},{"location":"features/0327-crypto-service/#todays-best-practice-approach-to-cryptographically-secured-services","title":"Todays 'Best Practice' approach to cryptographically secured Services","text":"<p>Many 3<sup>rd</sup> party services today provide solutions like secure storage, encrypted communication, secure data transportation and to achieve that they are using secure keys to provide cryptography for their use cases. The problem is that in many cases those keys are generated and/or stored within the 3<sup>rd</sup> party Services - either in the Client App or in the Backend - which requires the users explicit trust into the 3<sup>rd</sup> parties good intentions.</p> <p>Even in the case that a 3<sup>rd</sup> party has the best possible intentions in keeping the users secrets save and private. There is still the increased risk for the users keys of leakage or beeing compromised while beeing stored with a (centralized) 3<sup>rd</sup> party Service.</p> <p>Last but not least the users usage of multiple such cryptografically secured services would lead to the distribution of the users secrets over different systems where the user needs to keep track of them and manage them via differnt 3<sup>rd</sup> party tools.</p>"},{"location":"features/0327-crypto-service/#vision-seperation-of-service-business-logic-and-identity-artefacts","title":"Vision - seperation of Service-(Business-)Logic and Identity Artefacts","text":"<p>In the context of SSI and decentralized identity the ideal solution is that the keys are generated within user agent and that the private (secret) key never leaves that place. This would be a clear seperation of a services business logic and the users keys which we also count to the users unique sets of identifying information (identity artefacts).</p> <p>After seperating these two domains their follows the obvious need for providing a general crypto API to the user wallet which allows to support generic use cases where a cryptographic layer is required in the 3<sup>rd</sup> party service business logic, for example:</p> <ul> <li>encrypted data in data vaults</li> <li>encrypted messages within 3<sup>rd</sup> party service</li> <li>additional security layers outside of Agent ecosystem, data transportation, messaging over non-DIDComm protocols.</li> <li>backup/restore systems</li> </ul> <p>The desired outcome would be to have an Agent which is able to expose a standardized Crypto Services API to external 3<sup>rd</sup> party services which then can implement cryptographically secured aplications without the need to have access to the actual user secrets.</p>"},{"location":"features/0327-crypto-service/#tutorial","title":"Tutorial","text":""},{"location":"features/0327-crypto-service/#name-and-version","title":"Name and Version","text":"<p>This defines the <code>crypto-service</code> protocol. version 1.0, as identified by the following PIURI:</p> <pre><code>TODO: Add PIURI when ready\n</code></pre>"},{"location":"features/0327-crypto-service/#roles","title":"Roles","text":"<p>The minimum amount of roles involved in the <code>crypto-service</code> protocol are: a <code>sender</code> and a <code>receiver</code>. The <code>sender</code> requests a specific cryptographic operation from the <code>receiver</code> and the <code>receiver</code> provides the result in a form of a payload or an error. The protocol could include more roles (e.g. a <code>proxy</code>) which could be involved in processes like delegation (proxy re-encryption), etc.</p>"},{"location":"features/0327-crypto-service/#constraints","title":"Constraints","text":"<p>Each message which is send to the agent requires an up front established relationship between sender and receiver in the form of an authorization. This means that the sender is allowed to use only the specific key which is meant for him. There should not be the case that the sender is able to trigger any operation with keys which where never used within his service.</p>"},{"location":"features/0327-crypto-service/#reference","title":"Reference","text":""},{"location":"features/0327-crypto-service/#examples","title":"Examples","text":"<p>Specific use case example:</p> <p>A platform providing secure document transportation between parties and archiving functionality.</p> <p>Actors:</p> <ul> <li><code>Sender</code>: user sending document</li> <li><code>Receiver</code>: user receiving document</li> <li><code>DocuArch</code>: platform providing secure document transportation and archiving</li> <li><code>DocuArchApp</code>: client side application allowing to up-/download and display documents</li> </ul> <p>Here is how it could work:</p> <ul> <li><code>Receiver</code> register to the services with his DID identity (via <code>DocuArchApp</code>)</li> <li><code>Receiver</code> share his DID with the <code>Sender</code></li> <li><code>Sender</code> knowing DID of the <code>Receiver</code> encrypts the document with <code>Receiver</code> public key and sends document on the platform</li> <li><code>DocuArch</code> securely transports that document to the <code>Receiver</code> at the same time archiving it for the <code>Sender</code> and <code>Receiver</code></li> <li><code>Receiver</code> is informed by the <code>DocuArchApp</code> that there is a new document to view.</li> <li><code>Receiver</code> securely logs into <code>DocuArchApp</code> with his DID identity</li> <li><code>Receiver</code> opens encrypted payload within <code>DocuArchApp</code></li> <li><code>DocuArchApp</code> sends request to the user Agent to decrypt the message for the <code>Receiver</code></li> <li>Agent decrypts the message and sends back the decrypted payload</li> <li><code>DocuArchApp</code> displays the decrypted payload within local app</li> </ul> <p>In this scenario <code>DocuArch</code> has no way to learn about what is in the payload which is sent between <code>Sender</code> and <code>Receiver</code> as only the person who is in possession of the private key is able to decrypt the payload - which is the <code>Receiver</code>. Therfore the decrypted payload is only available on the <code>Receivers</code> client side app which is in communication with the Agent on behalf of the users DID identity.</p> <p>Such ../../features within the Agent allow companies to build faster and more secure systems as the identity management and key management part comes from Agents and they just interact with it via API.</p>"},{"location":"features/0327-crypto-service/#messages","title":"Messages","text":"<p>Protocol: did:sov:1234;spec/crypto-service/1.0</p> <p>encrypt</p> <ul> <li>payload - raw data which should be encrypted</li> <li>key_id - reference to the specific did key which was used to establish connection with the service.</li> </ul> <pre><code>    {\n        \"@id\": \"1234567889\",\n        \"@type\": \"did:sov:1234;spec/crypto-service/1.0/encrypt\",\n        \"payload\": \"Text to be encrypted\",\n        \"key_id\": \"did:example:123456789abcdefghi#keys-1\"\n\n    }\n</code></pre> <p>decrypt</p> <ul> <li>encryptedPayload - encrypted payload to be decrypt</li> <li>key_id - reference to the specific did key which was used to establish connection with the service.</li> </ul> <pre><code>    {\n        \"@id\": \"1234567889\",\n        \"@type\": \"did:sov:1234;spec/crypto-service/1.0/decrypt\",\n        \"encryptedPayload\": \"ASDD@J(!@DJ!DASD!@F\",\n        \"key_id\": \"did:example:123456789abcdefghi#keys-1\"\n\n    }\n</code></pre> <p>sign</p> <ul> <li>payload - payload to be signed</li> <li>key_id - reference to the specific did key which was used to establish connection with the service.</li> </ul> <pre><code>    {\n        \"@id\": \"1234567889\",\n        \"@type\": \"did:sov:1234;spec/crypto-service/1.0/sign\",\n        \"payload\": \"I say so!\",\n        \"key_id\": \"did:example:123456789abcdefghi#keys-1\"\n\n    }\n</code></pre> <p>verify</p> <ul> <li>signature - signature to be verified</li> <li>key_id - reference to the specific did key which was used to establish connection with the service.</li> </ul> <pre><code>    {\n        \"@id\": \"1234567889\",\n        \"@type\": \"did:sov:1234;spec/crypto-service/1.0/verify\",\n        \"signature\": \"12312d8u182d812d9182d91827d179\",\n        \"key_id\": \"did:example:123456789abcdefghi#keys-1\"\n\n    }\n</code></pre> <p>delegate</p> <ul> <li>delegate - DID of the delegate identity for which the proxy re-encryption token shall be generated</li> <li>key_id - reference to the specific did key which was used to establish connection with the service.</li> </ul> <pre><code>    {\n        \"@id\": \"1234567889\",\n        \"@type\": \"did:sov:1234;spec/crypto-service/1.0/delegate\",\n        \"delegate\": \"did:example:ihgfedcba987654321\",\n        \"key_id\": \"did:example:123456789abcdefghi#keys-1\"\n\n    }\n</code></pre>"},{"location":"features/0327-crypto-service/#message-catalog","title":"Message Catalog","text":"<p>TODO: add error codes and response messages/statuses</p>"},{"location":"features/0327-crypto-service/#responses","title":"Responses","text":"<p>TODO</p>"},{"location":"features/0327-crypto-service/#drawbacks","title":"Drawbacks","text":""},{"location":"features/0327-crypto-service/#-potentialy-expose-agent-for-different-types-of-attacts-eg-someone-would-try-to-decrypt-your-private-documents-without-you-being-notice-of-that","title":"- Potentialy expose Agent for different types of attacts: e.g. someone would try to decrypt your private documents without you being notice of that.","text":""},{"location":"features/0327-crypto-service/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>We can not expect that each services will switch directly to the DIDComm and other ../../features of the agents. Not all ../../features are even desier to have within agent. But if the Agent can exposer base API for identity management and crypto operations this would allow others to build on top of it much more richer ans secure applications and platforms.</p> <p>We are not aware of any alternatives atm. Anyone?</p>"},{"location":"features/0327-crypto-service/#prior-art","title":"Prior art","text":"<p>Similar approach is taken within HSM world where API is expose to the outside world without exposing keys. Here we take same approach in the context of KMS within Agent.</p>"},{"location":"features/0327-crypto-service/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>How to check authorization that a given service is allowed to use a specific set of the keys?</li> <li>How to protect user against malicious requests?</li> <li>What other operations should be supported?</li> <li>What are the limitations in the context of payload?</li> </ul>"},{"location":"features/0327-crypto-service/#implementations","title":"Implementations","text":"<p>Implementation Notes</p> Name / Link Implementation Notes"},{"location":"features/0334-jwe-envelope/","title":"Aries RFC 0334: JWE envelope 1.0","text":"<ul> <li>Authors: Baha A. Shaaban (SecureKey Technologies Inc.), Troy Ronda (SecureKey Technologies Inc.)</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes:</li> <li>Start Date: 2019-11-01</li> <li>Tags: feature</li> </ul>"},{"location":"features/0334-jwe-envelope/#summary","title":"Summary","text":"<p>Agents need to use a common set of algorithms when exchanging and persisting data. This RFC supplies a cipher suite and examples for DIDComm envelopes.</p>"},{"location":"features/0334-jwe-envelope/#motivation","title":"Motivation","text":"<p>The goal of this RFC is to define cipher suites for Anoncrypt and Authcrypt such that we can achieve better compatibility with JOSE. We also aim to supply both a compliant suite and a constrained device suite. The compliant suite is suitable for implementations that contain AES hardware acceleration or desire to use NIST / FIPS algorithms (where possible).</p>"},{"location":"features/0334-jwe-envelope/#encryption-algorithms","title":"Encryption Algorithms","text":"<p>The next two sub-sections describe the encryption algorithms that must be supported. On devices with AES hardware acceleration or requiring compliance, AES GCM is the recommended algorithm. Otherwise, XChacha20Poly1305 should be used.</p>"},{"location":"features/0334-jwe-envelope/#content-encryption-algorithms","title":"Content Encryption Algorithms","text":"<p>The following table defines the supported content encryption algorithms for DIDComm JWE envelopes:</p> Content Encryption Encryption Algorithm identifier Authcrypt/Anoncrypt Reference A256CBC-HS512 (512 bit) AES_256_CBC_HMAC_SHA_512 Authcrypt/Anoncrypt ECDH-1PU section 2.1 and RFC 7518 section 5.2.5 AES-GCM (256 bit) A256GCM Anoncrypt RFC7518 section 5.1 and more specifically RFC7518 section 5.3 XChacha20Poly1305 XC20P Anoncrypt xchacha draft 03"},{"location":"features/0334-jwe-envelope/#key-encryption-algorithms","title":"Key Encryption Algorithms","text":"<p>The following table defines the supported key wrapping encryption algorithms for DIDComm JWE envelopes:</p> Key Encryption Encryption algorithm identifier Anoncrypt/Authcrypt ECDH-ES + AES key wrap ECDH-ES+A256KW Anoncrypt ECDH-1PU + AES key wrap ECDH-1PU+A256KW Authcrypt"},{"location":"features/0334-jwe-envelope/#curves-support","title":"Curves support","text":"<p>The following curves are supported:</p> Curve Name Curve identifier X25519 (aka Curve25519) X25519 (default) NIST P256 (aka SECG secp256r1 and ANSI X9.62 prime256v1, ref here) P-256 NIST P384 (aka SECG secp384r1, ref here) P-384 NIST P521 (aka SECG secp521r1, ref here) P-521 <p>Other curves are optional.</p>"},{"location":"features/0334-jwe-envelope/#security-consideration-for-curves","title":"Security Consideration for Curves","text":"<p>As noted in the ECDH-1PU IETF draft security considerations section, all implementations must ensure the following: <pre><code>When performing an ECDH key agreement between a static private key\nand any untrusted public key, care should be taken to ensure that the\npublic key is a valid point on the same curve as the private key.\nFailure to do so may result in compromise of the static private key.\nFor the NIST curves P-256, P-384, and P-521, appropriate validation\nroutines are given in Section 5.6.2.3.3 of [NIST.800-56A]. For the\ncurves used by X25519 and X448, consult the security considerations\nof [RFC7748].\n</code></pre></p>"},{"location":"features/0334-jwe-envelope/#jwe-examples","title":"JWE Examples","text":"<p>AES GCM encryption and key wrapping examples are found in Appendix C of the JSON Web Algorithm specs.</p> <p>The Proposed JWE Formats below lists a combination of content encryption and key wrapping algorithms formats.</p>"},{"location":"features/0334-jwe-envelope/#drawbacks","title":"Drawbacks","text":"<ul> <li>All new algorithm identifiers should be registered at IANA.</li> <li>XC20P</li> <li>ECDH-1PU+A256KW (already in IETF draft)</li> <li>ECDH-ES+XC20PKW</li> <li>ECDH-1PU+XC20PKW</li> <li>Security Considerations of ECDH-1PU (Section 4)</li> <li>X25519 is not yet part of SP 800-56A. See NIST post for more information.</li> </ul>"},{"location":"features/0334-jwe-envelope/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Our approach for AuthCrypt compliance is to use the NIST approved <code>One-Pass Unified Model for ECDH</code> scheme described in SP 800-56A Rev. 3. The JOSE version is defined as <code>ECDH-1PU</code> in this IETF draft.</p> <p>Aries agents currently use the envelope described in RFC0019. This envelope uses libsodium (NaCl) encryption/decryption, which is based on Salsa20Poly1305 algorithm.</p> <p>Another prior effort towards enhancing JWE compliance is to use XChacha20Poly1305 encryption and ECDH-SS key wrapping mode. See Aries-RFCs issue-133 and Go JWE Authcrypt package for an implementation detail. As ECDH-SS is not specified by JOSE, a new recipient header field, <code>spk</code>, was needed to contain the static encrypted public key of the sender. Additionally (X)Chacha20Poly1305 key wrapping is also not specified by JOSE. For these reasons, this option is mentioned here as reference only.</p>"},{"location":"features/0334-jwe-envelope/#jwe-formats","title":"JWE formats","text":""},{"location":"features/0334-jwe-envelope/#anoncrypt-using-ecdh-es-key-wrapping-mode-and-xc20p-content-encryption","title":"Anoncrypt using ECDH-ES key wrapping mode and XC20P content encryption","text":"<pre><code> {\n  \"protected\": base64url({\n      \"typ\": \"didcomm-envelope-enc\",\n      \"enc\": \"XC20P\", // or \"A256GCM\"\n  }),\n  \"recipients\": [\n    {\n      \"header\": {\n        \"kid\": base64url(recipient KID), // e.g: base64url(\"urn:123\") or base64url(jwk thumbprint as KID)\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"epk\": { // defining X25519 key as an example JWK, but this can be EC key as well \n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"-3bLMSHYDG3_LVNh-MJvoYs_a2sAEPr4jwFfFjTrmUo\" // sender's ephemeral public key value raw (no padding) base64url encoded\n        },\n        \"apu\": base64url(epk.x value above),\n        \"apv\": base64url(recipients[*].header.kid)\n      },\n      \"encrypted_key\": \"Sls6zrMW335GJsJe0gJU4x1HYC4TRBZS1kTS1GATEHfH_xGpNbrYLg\"\n    }\n  ],\n  \"aad\": \"base64url(sha256(concat('.',sort([recipients[0].kid, ..., recipients[n].kid])))))\",\n  \"iv\": \"K0PfgxVxLiW0Dslx\",\n  \"ciphertext\": \"Sg\",\n  \"tag\": \"PP31yGbQGBz9zgq9kAxhCA\"\n}\n</code></pre> <p><code>typ</code> header field is the DIDComm Transports value as mentioned in RFC-0025. This RFC states the prefix <code>application/</code> but according to IANA Media types the prefix is implied therefore not needed here.</p>"},{"location":"features/0334-jwe-envelope/#anoncrypt-using-ecdh-es-key-wrapping-mode-and-a256gcm-content-encryption","title":"Anoncrypt using ECDH-ES key wrapping mode and A256GCM content encryption","text":"<pre><code>{\n  \"protected\": base64url({\n          \"typ\": \"didcomm-envelope-enc\",\n          \"enc\": \"A256GCM\", // \"XC20P\"\n  }),\n  \"recipients\": [\n    {\n      \"header\": {\n        \"kid\": base64url(recipient KID),\n        \"alg\": \"ECDH-ES+XC20PKW\", // or \"ECDH-ES+A256KW\" with \"epk\" as EC key\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"aOH-76BRwkHf0nbGokaBsO6shW9McEs6jqVXaF0GNn4\" // sender's ephemeral public key value raw (no padding) base64url encoded\n        },\n        \"apu\": base64url(epk.x value above),\n        \"apv\": base64url(recipients[*].header.kid)\n      },\n      \"encrypted_key\": \"wXzKi-XXb6fj_KSY5BR5hTUsZIiAQKrxblTo3d50B1KIeFwBR98fzQ\"\n    }\n  ],\n  \"aad\": \"base64url(sha256(concat('.',sort([recipients[0].kid, ..., recipients[n].kid])))))\",\n  \"iv\": \"9yjR8zvgeQDZFbIS\",\n  \"ciphertext\": \"EvIk_Rr6Nd-0PqQ1LGimSqbKyx_qZjGnmt6nBDdCWUcd15yp9GTeYqN_q_FfG7hsO8c\",\n  \"tag\": \"9wP3dtNyJERoR7FGBmyF-w\"\n}\n</code></pre> <p>In the above two examples, <code>apu</code> is the encoded ephemeral key used to encrypt the cek stored in <code>encrypted_key</code> and <code>apv</code> is the encoded key id of the static public key of the recipient. Both are raw (no padding) base64Url encoded. <code>kid</code> is the value of a key ID in a DID document that should be resolvable to fetch the raw public key used.</p>"},{"location":"features/0334-jwe-envelope/#authcrypt-using-ecdh-1pu-key-wrapping-mode","title":"Authcrypt using ECDH-1PU key wrapping mode","text":"<pre><code>{\n    \"protected\": base64url({\n        \"typ\": \"didcomm-envelope-enc\",\n        \"enc\":\"A256CBC-HS512\", // or one of: \"A128CBC-HS256\", \"A192CBC-HS384\"\n        \"skid\": base64url(sender KID),\n        \"alg\": \"ECDH-1PU+A256KW\", // or \"ECDH-1PU+XC20P\" with \"epk\" as X25519 key\n        \"apu\": base64url(\"skid\" header value),\n        \"apv\": base64url(sha256(concat('.',sort([recipients[0].kid, ..., recipients[n].kid]))))),\n        \"epk\": {\n            \"kty\": \"EC\",\n            \"crv\": \"P-256\",\n            \"x\": \"gfdM68LgZWhHwdVyMAPh1oWqV_NcYGR4k7Bjk8uBGx8\",\n            \"y\": \"Gwtgz-Bl_2BQYdh4f8rd7y85LE7fyfdnb0cWyYCrAb4\"\n        }\n    }),\n    \"recipients\": [\n        {\n            \"header\": {\n                \"kid\": base64url(recipient KID)\n            },\n            \"encrypted_key\": \"base64url(encrypted CEK)\"\n        },\n       ...\n    ],\n    \"aad\": \"base64url(sha256(concat('.',sort([recipients[0].kid, ..., recipients[n].kid])))))\",\n    \"iv\": \"base64url(content encryption IV)\",\n    \"ciphertext\": \"base64url(XC20P(DIDComm payload, base64Url(json($protected)+'.'+$aad), content encryption IV, CEK))\"\n    \"tag\": \"base64url(AEAD Authentication Tag)\"\n}\n</code></pre> <p>With the recipients headers representing an ephemeral key that can be used to derive the key to be used for AEAD decryption of the CEK following the ECDH-1PU encryption scheme.</p> <p>The function <code>XC20P</code> in the example above is defined as the XChahcha20Poly1035 cipher function. This can be replaced by the AES-CBC+HMAC_SHA family of cipher functions for authcrypt or AES-GCM cipher function for anoncrypt.</p>"},{"location":"features/0334-jwe-envelope/#concrete-examples","title":"Concrete examples","text":"<p>See concrete anoncrypt and authcrypt examples</p>"},{"location":"features/0334-jwe-envelope/#jwe-detached-mode-nested-envelopes","title":"JWE detached mode nested envelopes","text":"<p>There are situations in DIDComm messaging where an envelope could be nested inside another envelope -- particularly RFC 46: Mediators and Relays. Normally nesting envelopes implies that the envelope payloads will incur additional encryption and encoding operations at each parent level in the nesting. This section describes a mechanism to extract the nested payloads outside the nesting structure to avoid these additional operations.</p>"},{"location":"features/0334-jwe-envelope/#detached-mode","title":"Detached mode","text":"<p>JWS defines detached mode where the payload can be removed. As stated in IETF RFC7515, this strategy has the following benefit:</p> <p>Note that this method needs no support from JWS libraries, as   applications can use this method by modifying the inputs and outputs   of standard JWS libraries.</p> <p>We will leverage a similar detached mode for JWE in the mechanism described below.</p>"},{"location":"features/0334-jwe-envelope/#mechanism","title":"Mechanism","text":"<p>Sender:</p> <ol> <li>Creates the \"final\" JWE intended for the recipient (normal JWE operation).</li> <li>Extracts the ciphertext and replace with an empty string.</li> <li>Creates the nested envelopes around the \"final\" JWE (but with the empty string ciphertext).</li> <li>Sends the nested envelope (normal JWE) plus the ciphertext from the \"final\" JWE.</li> </ol> <p>Mediator:</p> <ol> <li>Decrypt their layer (normal JWE operation). The detached ciphertext(s) are filtered out prior to invoking the JWE library (normal JWE structure).</li> <li>Remove the next detached ciphertext from the structure and insert back into the ciphertext field for the next nesting level.</li> </ol> <p>Receiver:</p> <ol> <li>Decrypts the \"final\" JWE (normal JWE operation).</li> </ol> <p>The detached ciphertext steps are repeated at each nesting level. In this case, an array of ciphertexts is sent along with the nested envelope.</p> <p>This solution has the following characteristics:</p> <ul> <li>Only encrypts the payload once.</li> <li>JWE headers and metadata are included in the nested envelope's ciphertext.</li> <li>Needs no support from JWE libraries.</li> <li>Requires a serialization structure for transporting both the nesting JWE and the detached ciphertexts (only when there is a nested envelope). See below.</li> <li>Requires some minor additional logic prior to invoking the JWE library.</li> </ul>"},{"location":"features/0334-jwe-envelope/#serialization","title":"Serialization","text":"<p>The extracted ciphertext serialization format should have additional thought for both compact and JSON modes. As a starting point:</p> <ul> <li>Compact mode: Each extracted ciphertext is appended to the end of the serialized \"final\" JWE (using dot separation). These extracted cipher texts are ordered according to the nesting (from innermost to outermost).</li> <li>JSON mode: The extracted ciphertext are placed into a JSON array. These extracted cipher texts are ordered according to the nesting (from innermost to outermost). The array is appended to the \"final\" JWE object as the <code>detached_ciphertext</code> field.</li> </ul> <p>For illustration, the following compact serialization represents nesting due to two mediators (the second mediator being closest to the Receiver).</p> <p>First Mediator receives: <pre><code>  BASE64URL(UTF8(JWE Protected Header for First Mediator)) || '.' ||\n  BASE64URL(JWE Encrypted Key for First Mediator) || '.' ||\n  BASE64URL(JWE Initialization Vector for First Mediator) || '.' ||\n  BASE64URL(JWE Ciphertext for First Mediator) || '.' ||\n  BASE64URL(JWE Authentication Tag for First Mediator) || '.' ||\n  BASE64URL(JWE Ciphertext for Receiver) || '.' ||\n  BASE64URL(JWE Ciphertext for Second Mediator)\n</code></pre></p> <p>Second Mediator receives: <pre><code>  BASE64URL(UTF8(JWE Protected Header for Second Mediator)) || '.' ||\n  BASE64URL(JWE Encrypted Key for Second Mediator) || '.' ||\n  BASE64URL(JWE Initialization Vector for Second Mediator) || '.' ||\n  BASE64URL(JWE Ciphertext for Second Mediator) || '.' ||\n  BASE64URL(JWE Authentication Tag for Second Mediator) || '.' ||\n  BASE64URL(JWE Ciphertext for Receiver)\n</code></pre></p> <p>Finally, the Receiver has a normal JWE (as usual): <pre><code>  BASE64URL(UTF8(JWE Protected Header for Receiver)) || '.' ||\n  BASE64URL(JWE Encrypted Key for Receiver) || '.' ||\n  BASE64URL(JWE Initialization Vector for Receiver) || '.' ||\n  BASE64URL(JWE Ciphertext for Receiver) || '.' ||\n  BASE64URL(JWE Authentication Tag for Receiver)\n</code></pre></p> <p>This illustration extends the serialization shown in RFC 7516.</p>"},{"location":"features/0334-jwe-envelope/#prior-art","title":"Prior art","text":"<ul> <li>The JWE family of encryption methods.</li> <li>Aries RFC 0019-encryption-envelope suggested envelope formats will be superseded by this RFC.</li> <li>Aries RFC 0025-didcomm-transports for the content type used in the proposed envelopes.</li> <li>minimal-cipher implementation</li> <li>Aries-Framework-Go has an experimental (X)Chacha20Poly1305 Packer implementation based on Aries-RFCs issue-133</li> <li>IANA Media Types</li> <li>Public Key Authenticated Encryption for JOSE: ECDH-1PU</li> <li>NIST SP 800-56A Rev. 3 Recommendation for Pair-Wise Key-Establishment schemes Using Discrete Logarithm Cryptography</li> <li>Appendix A of IETF 4492 listing equivalent curve names.</li> </ul>"},{"location":"features/0334-jwe-envelope/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What fields should Key identifiers in ES and 1PU key wrapping modes use? <code>kid</code> vs <code>id</code> (vs <code>skid</code> introduced in ECDH-1PU IETF document) or any other combination of fields. There is a discussion about this here.</li> <li> <p>Update:   The answer to this question is to keep <code>kid</code> definition as per the JWE/JWS family of specification definitions and use <code>skid</code> in the JWE protected header as defined in ECDH-1PU to represent a resolvable sender key id.</p> </li> <li> <p>What kind of keys to include in the JWE envelope? <code>Encryption</code> or <code>signing</code> keys? Currently, the existing Aries agents include <code>signing</code> (ED25519) keys for the sender and recipients and convert them to encryption (X25519) keys for encryption/decryption operations only. The drawback of this approach is the envelope transmitted by the agent contains signing public keys. There is a need to separate them from <code>encryption</code> keys. </p> </li> <li>Update:   The best way to separate the two keys is to use the DID document's KeyAgreement verification method in full description to store the <code>encryption</code> key so that it can be sent in the JWE envelope independently of the signing (DID authentication) key.</li> </ul>"},{"location":"features/0334-jwe-envelope/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes <p>Note: Aries Framework - Go is almost done with a first draft implementation of this RFC.</p>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/","title":"Table of Contents","text":"<ul> <li>Anoncrypt JWE Concrete examples</li> <li>Notes</li> <li>1 A256GCM Content Encryption<ul> <li>1.1 Multi recipients JWEs</li> <li>1.1.1 NIST P-256 keys</li> <li>1.1.2 NIST P-384 keys</li> <li>1.1.3 NIST P-521 keys</li> <li>1.1.4 X25519 keys</li> <li>1.2 Single Recipient JWEs</li> <li>1.2.1 NIST P-256 key</li> <li>1.2.2 NIST P-384 key</li> <li>1.2.3 NIST P-521 key</li> <li>1.2.4 X25519 key</li> </ul> </li> <li>2 XC20P content encryption<ul> <li>2.1 Multi recipients JWEs</li> <li>2.1.1 NIST P-256 keys</li> <li>2.1.2 NIST P-384 keys</li> <li>2.1.3 NIST P-521 keys</li> <li>2.1.4 X25519 keys</li> <li>2.2 Single Recipient JWEs</li> <li>2.2.1 NIST P-256 key</li> <li>2.2.2 NIST P-384 key</li> <li>2.2.3 NIST P-521 key</li> <li>2.2.4 X25519 key</li> </ul> </li> </ul> <p>Created by gh-md-toc</p>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#anoncrypt-jwe-concrete-examples","title":"Anoncrypt JWE Concrete examples","text":"<p>The following examples are for JWE anoncrypt packer for encrypting the payload <code>secret message</code> and aad value set as the concatenation of recipients' KIDs (ASCII sorted) joined by <code>.</code> for non-compact serializations (JWE Compact serializations don't have AAD).</p>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#notes","title":"Notes","text":"<ul> <li>all <code>x</code> and <code>y</code> key coordinates values below are raw (no padding) base64URL encoded.</li> <li>JWE envelopes with multi recipients use the General JWE JSON Serialization format.</li> <li>JWE envelopes with a single recipient will be shown in both serialization formats: as JWE Compact or Flattened JWE JSON.</li> <li>General JWE JSON Serialization format use. the above mentioned AAD value in their envelope.</li> <li>JWE Compact Serialization format does not support AAD values and therefore were built without it.</li> <li>all <code>apu</code> recipient header values are set to the raw (no padding) base64URL encoding of the corresponding recipient's ephemeral key's <code>x</code> value since Anoncrypt dosen't reveal the sender.</li> <li>all <code>apv</code> recipient header values are set to the raw (no padding) base64URL encoding of the corresponding recipient's <code>kid</code> value.</li> <li>The final aad used to encrypt the payload is the concatenation of the raw (no padding) base64URL encoded protected headers and <code>aad</code> JWE header joined by a <code>.</code>.</li> <li>Even though flattened serialization do support <code>aad</code>, the field is omitted in the below examples to be consistent with compact JWE serialization format. Implementations should support <code>aad</code> for flattened serialization regardless.</li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#1-a256gcm-content-encryption","title":"1 A256GCM Content Encryption","text":"<p>The packer generates the following protected headers for A256GCM content encryption in the below examples: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"A256GCM\",\"typ\":\"application/didcomm-encrypted+json\"}</code>     - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9</code></p>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#11-multi-recipients-jwes","title":"1.1 Multi recipients JWEs","text":""},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#111-nist-p-256-keys","title":"1.1.1 NIST P-256 keys","text":"<ul> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"2fpy_fK5FCsap0EbU1Om7QXoVoyvBv8gfdHY3ufIS9w\",\n  \"y\": \"TtVOc9c8ejMeqeaUs1CMS79w0-Al02Fw25WdVEb0DiI\",\n  \"d\": \"kEWLCAyDL8mgDLNnlb1am_B8wcaGAe7ViXx1tqKWTVc\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>s6-ZhI1hpx0kM3pDgOrVQs6mRd_8KfEXUkLg8lK7XNA</code></li> <li>Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"S9JVfrKenXIMiEUha1k8yt7Zw8d5_bSxEt6RJesPt1g\",\n  \"y\": \"KMWwZzb80uoAjCcuwQ3gSeyjMsbq02AyS7g1D2i7ZwM\",\n  \"d\": \"bHnnqFSAFROp4kLbfBfihHUg6PIviwRCt5foN2Romw4\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>2NfcF400LLr9Wa6QbkUikYUUcdsAUkZBy6ifrrXYI0U</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"tqn3J0p752xWq2T4M11Q8ZcidyEWfaray-2B84hjehg\",\n  \"y\": \"ewcqOkZtlGBfZmP9nr44tq7_vkBJ3fJe9u6TCEyMDh8\",\n  \"d\": \"5XlB_SQXVpA6Id1PNL4SJfrMhCC36xa0hSHB7WpwA9Y\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>xG9z3It37igQIB4Q9jbcKLVjcFvnXIvkuJdLNKFvRB4</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>2NfcF400LLr9Wa6QbkUikYUUcdsAUkZBy6ifrrXYI0U.s6-ZhI1hpx0kM3pDgOrVQs6mRd_8KfEXUkLg8lK7XNA.xG9z3It37igQIB4Q9jbcKLVjcFvnXIvkuJdLNKFvRB4</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>YyqAtGX-dZTiXaZnGazezl-jBXS4uka1sOFv8cV42uM</code></li> <li>Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"WVU3OHhXeVZLeC1WRVpIV2pWbFN3Z2NndFRtSjBfS09YOE9hTkdnQXNlUQ\",\n        \"apv\": \"czYtWmhJMWhweDBrTTNwRGdPclZRczZtUmRfOEtmRVhVa0xnOGxLN1hOQQ\",\n        \"kid\": \"s6-ZhI1hpx0kM3pDgOrVQs6mRd_8KfEXUkLg8lK7XNA\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"YU78xWyVKx-VEZHWjVlSwgcgtTmJ0_KOX8OaNGgAseQ\",\n          \"y\": \"AiHDxtQBrba6g3_d0tic8LeLZRMz7rqnghQ2DvJh0Xk\"\n        }\n      },\n      \"encrypted_key\": \"fnofbBoie-ywDVjd_Dcdw611KWabq0RptbEybN_AParPMI0qpOwm1Q\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"NkN3ZEt3ZEotczdIZHFpUzExR0x6bS1scVhlUW1TYWJjNXBvRnBaakdZbw\",\n        \"apv\": \"czYtWmhJMWhweDBrTTNwRGdPclZRczZtUmRfOEtmRVhVa0xnOGxLN1hOQQ\",\n        \"kid\": \"2NfcF400LLr9Wa6QbkUikYUUcdsAUkZBy6ifrrXYI0U\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"6CwdKwdJ-s7HdqiS11GLzm-lqXeQmSabc5poFpZjGYo\",\n          \"y\": \"mVsQl_AhZoHpC86UN49k6tAU5B2YLi0HIdWeaIvSQy8\"\n        }\n      },\n      \"encrypted_key\": \"qN1WX7DK0k2GW4qHK0SfQFTRrOM0GFUgzqqy58QTRWi62r9iItmPxA\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"aXZzeDhaVmowbEJ1c2pLNjZSS1dVN0JDRjJzal81QWlQb1VsS21KOHZkSQ\",\n        \"apv\": \"czYtWmhJMWhweDBrTTNwRGdPclZRczZtUmRfOEtmRVhVa0xnOGxLN1hOQQ\",\n        \"kid\": \"xG9z3It37igQIB4Q9jbcKLVjcFvnXIvkuJdLNKFvRB4\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"ivsx8ZVj0lBusjK66RKWU7BCF2sj_5AiPoUlKmJ8vdI\",\n          \"y\": \"Ea6i7ahugWrTZoc9UMq1e3aPmHm0bkGqxTDmoEMyYMU\"\n        }\n      },\n      \"encrypted_key\": \"Yds0G9wYyAaGf2ky9DAT0CITzoD4qHV1fUM-cH-mmGsx8TeFjYBVYw\"\n    }\n  ],\n  \"aad\": \"YyqAtGX-dZTiXaZnGazezl-jBXS4uka1sOFv8cV42uM\",\n  \"iv\": \"S9rOxQOd8H-gxZIv\",\n  \"ciphertext\": \"w3kl_QixTanzflQHpuM\",\n  \"tag\": \"4x5wmIBxrCjUpq4wxrWFDQ\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#112-nist-p-384-keys","title":"1.1.2 NIST P-384 keys","text":"<ul> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"lb17x-OBz2i1kQbkRtSKD3TY1MwIfUMyM8YtqXZXMj884hLJH2QtxmUWKyXIprcn\",\n  \"y\": \"PlT4CInTrA5zAroqwyww0BL6EipnEBTrtbWID8nADz6LFpf_27qlxIARy_iU5OcN\",\n  \"d\": \"JJgpIqGS5JuiKRnsEgGNlYw39pz-XGrsrmniuxlSik0BLwdb8-0K8Xxuqo6yW6NE\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>8wPpWWlLiMBYltw6AoWG3Z_SfgWmXanBHSwZFpQJ0Q0</code></li> <li>Recipient 2 public key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"ACZDXpzp6cKqsCcWq7sVOcCB_QZLd9ZfhoxhBKCbytrSKVKn7jV3Kv1XlsnH1RH7\",\n  \"y\": \"FQy3qBV-bn4K_5bQXucEPIOupMhEJS7YXCbm-fUb9ZdC59b0-5lbo7l65fkEL3ZO\",\n  \"d\": \"F4BlupNNnLfPOsml1MfBJgw6Oz89L6GnRiJnFi5ay5zVHTIcWzX81D060KsCjK9t\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>8l5z1lSVYFmv8QSboANWcj_UUh4bp3PlwEBNNHd2p3Q</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"msbHjsKVl0paXi-SWZ5_gEMgsMihBW9TEnfScKxfVlFMC6Hi5JIz1wgs58ugqaSX\",\n  \"y\": \"ppzaqlmAjA_iBymA2iBH56mHeTxckL8YNfmcSNa8hJoD4XYZ-4_x9mip-dh8o4gI\",\n  \"d\": \"YT0k8bBmPmecprG6tax6g00wG0JkprPcCqU1jvM86PAGGUU12fY7-Dfmqwhwv5U-\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>t1KsLfBBTG9iXIzyga6xV7RAur2j34dLGB3jqTDuTMo</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>8l5z1lSVYFmv8QSboANWcj_UUh4bp3PlwEBNNHd2p3Q.8wPpWWlLiMBYltw6AoWG3Z_SfgWmXanBHSwZFpQJ0Q0.t1KsLfBBTG9iXIzyga6xV7RAur2j34dLGB3jqTDuTMo</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>jgz9Cgt6lep5QPX0-GCkOMXujjRYgfiTslwut8BdX-0</code></li> <li>JWE: <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"OVdMemtDbjBlaEFxVTlwZjdvUEFZVUdOcHhkdTR2VWZUZVZxZzlVWEZUNVNPS0dTaDFwZ294aWhOb0tWZlpsNg\",\n        \"apv\": \"OHdQcFdXbExpTUJZbHR3NkFvV0czWl9TZmdXbVhhbkJIU3daRnBRSjBRMA\",\n        \"kid\": \"8wPpWWlLiMBYltw6AoWG3Z_SfgWmXanBHSwZFpQJ0Q0\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"9WLzkCn0ehAqU9pf7oPAYUGNpxdu4vUfTeVqg9UXFT5SOKGSh1pgoxihNoKVfZl6\",\n          \"y\": \"Yuwe4x6Seue5pegwF9px-RQqSxARjf5mHSwVW7ft6dC5TgXdCPzm3bTRW4qxR41X\"\n        }\n      },\n      \"encrypted_key\": \"Dj-4zbK_WbF_5nU1rfvT0dipMtwSUQvmluCrxwu-arKU2w59hN5ecQ\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"Q2hxMTBxU0duM3JQdHVKaFcwcEF1TzIxanh4WkVFb0xVQ1hkajNTbERfelZMamQ4ZHdwSmp5UXhQeEVSQ2ZOTw\",\n        \"apv\": \"OHdQcFdXbExpTUJZbHR3NkFvV0czWl9TZmdXbVhhbkJIU3daRnBRSjBRMA\",\n        \"kid\": \"8l5z1lSVYFmv8QSboANWcj_UUh4bp3PlwEBNNHd2p3Q\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"Chq10qSGn3rPtuJhW0pAuO21jxxZEEoLUCXdj3SlD_zVLjd8dwpJjyQxPxERCfNO\",\n          \"y\": \"9PkX3jqgkslA2Z8rijClt-1yX5uulFcbRl7dCaSgquCfYj0ZmOEVhQqdD9yh955n\"\n        }\n      },\n      \"encrypted_key\": \"LpoFtDL4ac0bx16AkyE4HmpK-F_ibPm1LvyQVo-eFaPEo9HW8FWz_Q\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"T0cyZUptVU05NENDS2w4U2lGVTJNQUhVUnJiRldRSm1xd25ya2VWUFN3NTMzX3lSakFMLVNscnhvZ29uSnBzbA\",\n        \"apv\": \"OHdQcFdXbExpTUJZbHR3NkFvV0czWl9TZmdXbVhhbkJIU3daRnBRSjBRMA\",\n        \"kid\": \"t1KsLfBBTG9iXIzyga6xV7RAur2j34dLGB3jqTDuTMo\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"OG2eJmUM94CCKl8SiFU2MAHURrbFWQJmqwnrkeVPSw533_yRjAL-SlrxogonJpsl\",\n          \"y\": \"suMc0ckI46jPlM0dn7O_4fIpxFAD74LrkOUO_tEKeHD1opEoK7H2iE-1STzjflEm\"\n        }\n      },\n      \"encrypted_key\": \"sAN-AeA0ZtInrhJYtzkNnWooDmXOOYo4mD1hMps8aV2Iw84GheOuMw\"\n    }\n  ],\n  \"aad\": \"jgz9Cgt6lep5QPX0-GCkOMXujjRYgfiTslwut8BdX-0\",\n  \"iv\": \"iHzMT8jUCFNsqsZY\",\n  \"ciphertext\": \"IiPn4-09-MFtJggB5yE\",\n  \"tag\": \"Na9kW8Fpw5j4IJ-fdf4jNA\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#113-nist-p-521-keys","title":"1.1.3 NIST P-521 keys","text":"<ul> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AHrw8TsyZzIkINFPCAS54Y7UoCI1XAlim95ROPykpjo4q2LvW_VWeBtJLU2SuqTFG4WX9VBzMg5Rq4gMj4oCpMFb\",\n  \"y\": \"AUs4vywsYYuRP0LhFvyI_ippvSY6Tv1S8sEzojd41Ubo86bFlCj5c_wHX2N6hplMU01WAcebPWc24plqF39pkNrK\",\n  \"d\": \"AEklgm76AbNl_nydbcINMgytfoZGRMI1mxfGcIiqw-KHENQMtlujImJrKMUd32njHS1M9e-WqAS8AHLoVdBZmkOo\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>9Miv3vUT2vQL0X80PyrLJm3bzGPuc_aKfPr4txRQIpA</code></li> <li>Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AcJh1U3InkhEW5uvh9x3H_ZkzSRY9aoleTYH0a_ZgVKhGrQrttUgQhzvdj8Oyy389Muu0l5slkKfE_FpNXUoSlq8\",\n  \"y\": \"AB8lDC62GR8b7lz_mboFcrBG4uAWNqQ-E-k4tYqBu8xJOV-v68FeuJKwC9WGFOiIUaCwSGUB4-cYeFPIxq9hxD7Y\",\n  \"d\": \"AXTDpK0Eu6EEZliWHe-zgiY1s23sTepAgmP8KeVTOXeeCnCL12pK4mc-UR9NpEYrxBp_A5srbhzNR5x7mZ1G4kLf\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>l4-wvmALQDp4g-UpilwCHmLZ_zUGfNawYSWQMoLphIk</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"AA63cinH0aZ7e0sLBFx0s3MKQTfvdFjSMVMQHpp5qIF6pWaxV9TrqXkJYkR2fuMqvIRSlH5mMK73kNfEubrvsd7H\",\n  \"y\": \"AY88QmJlRbAbCY9UyeDK0pYFHbSxgdMCauV2GC-W2w5uJekAWoeO9KxSY215W60whRHGRctrTc7LodcV8y7UKOyx\",\n  \"d\": \"AU4kFJPY9rZA89-ZYvoZX_qKPglplaWZdFKU3ZzjZvNt7rBBUuKumsf_khTFF8q-LxJKd11B0rng3PIQRuob4JW-\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>Ev1dKdei9chrjW2-l4bjdXXF5GDZ7CqTcQlGg1W_U24</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>9Miv3vUT2vQL0X80PyrLJm3bzGPuc_aKfPr4txRQIpA.Ev1dKdei9chrjW2-l4bjdXXF5GDZ7CqTcQlGg1W_U24.l4-wvmALQDp4g-UpilwCHmLZ_zUGfNawYSWQMoLphIk</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>uLMTdeuniYvCFTQTamK0pZwFVgkJooGL37HZLm8PVkM</code></li> <li>JWE: <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"QWNnNWlNaUNjNkozMFg5R3lrTXl4R0dobFFrXzFhRlhJTDQ1cF9DT2l3ODVscFVyR1BOSnNKTVRrdTRHYnlMdndlam9jVHp5ZVZjMUxrX1RWa3o0UmZ4YQ\",\n        \"apv\": \"OU1pdjN2VVQydlFMMFg4MFB5ckxKbTNiekdQdWNfYUtmUHI0dHhSUUlwQQ\",\n        \"kid\": \"9Miv3vUT2vQL0X80PyrLJm3bzGPuc_aKfPr4txRQIpA\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"Acg5iMiCc6J30X9GykMyxGGhlQk_1aFXIL45p_COiw85lpUrGPNJsJMTku4GbyLvwejocTzyeVc1Lk_TVkz4Rfxa\",\n          \"y\": \"AQgFgsVvOfebXZFk8TiBAJef9h6sVpQSJXed0xG3IolDYIllQ_OyQdlFpKHl2xCjgVxRihdf7mS_3SCzEtrcjEzy\"\n        }\n      },\n      \"encrypted_key\": \"juXV2ZGX2MjF1FgjTWke3MTkODrdpqZ_k-5IVqZ568bvN12i8W_KaQ\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"QVJLTGZTNWVoeUlacV9UWmJpbXdESndpYVBsckNMU2RqdG9aVFJSeTl0QVZQelQxbnlub1BYRWZIOHNNNklucDVKdWhvc3BHSVMxQzkzSk01Z1RkNzRtaQ\",\n        \"apv\": \"OU1pdjN2VVQydlFMMFg4MFB5ckxKbTNiekdQdWNfYUtmUHI0dHhSUUlwQQ\",\n        \"kid\": \"l4-wvmALQDp4g-UpilwCHmLZ_zUGfNawYSWQMoLphIk\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"ARKLfS5ehyIZq_TZbimwDJwiaPlrCLSdjtoZTRRy9tAVPzT1nynoPXEfH8sM6Inp5JuhospGIS1C93JM5gTd74mi\",\n          \"y\": \"Ad5hB3rVVxTqvSsiN7NNbClumX-AWTV6r29CHz2Jbcgo5tunFz-5-CwP6EvQNkFrzrOxQ5ViOW5F3pYV-yoksLgO\"\n        }\n      },\n      \"encrypted_key\": \"H-B3FBmwlGFIEtdfWti6tD8LwtuokxxPam5XO3V7wwWNoJ5sEy-LlA\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"QWRTZUxrVWxadHpXRkNDODBvNVYtYTB3Mjl3MjM2OWtLRXlPbUtiQzItVlV4ZEo0OVdBUV9rTVhTempNaE1ON1VMc25mT3pEWFp1QkhwZUVRTU1zbWF5VA\",\n        \"apv\": \"OU1pdjN2VVQydlFMMFg4MFB5ckxKbTNiekdQdWNfYUtmUHI0dHhSUUlwQQ\",\n        \"kid\": \"Ev1dKdei9chrjW2-l4bjdXXF5GDZ7CqTcQlGg1W_U24\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"AdSeLkUlZtzWFCC80o5V-a0w29w2369kKEyOmKbC2-VUxdJ49WAQ_kMXSzjMhMN7ULsnfOzDXZuBHpeEQMMsmayT\",\n          \"y\": \"AJKQo494spZjUW85ika3qNyLJJiv_J3FpsYnZt-Ml3q8IqXlHqQV_Nl3s7yn_pq8RWXl_yvo1NPiDWpoDMZ3sUNw\"\n        }\n      },\n      \"encrypted_key\": \"53dtd9R0bbGK96jsPJRu2woQJC7-yBaN-xDw5xSp-pwpCKg1idnZ5w\"\n    }\n  ],\n  \"aad\": \"uLMTdeuniYvCFTQTamK0pZwFVgkJooGL37HZLm8PVkM\",\n  \"iv\": \"11_dMZoXv9OaPIR2\",\n  \"ciphertext\": \"ofWv6sUZdYF3rX9A-jQ\",\n  \"tag\": \"TyH-Abl3XTGlkUgjHCE-Vw\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#114-x25519-keys","title":"1.1.4 X25519 keys","text":"<ul> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"2kvTqkwVF-YSurN533fi-ZDF4PbLbqa7ohC--DJa0nA\",\n  \"d\": \"sPUMndizynb_q6_u9fkbuU8V3I062-RlL114YnJ7KWY\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>eFf9x4K6jhnmAEvveQJo5rIQl32rZooOaNwlJsLf5JQ</code></li> <li>Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"cb-5cmxUy7xCfQCz0pEjYOGJOp0nf3cH7TU6siQ49wU\",\n  \"d\": \"oCw27m5T-QPr48F_f-CRWWqFgtFxpPISExMhSYQJmF8\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>NaUTcaFDyI3Ss48zMmeg1Dal0vhUpOYpWdwfKd2T2S8</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"pW_fX347OhGgYURSvuM5-NSKw7CgHzCuOZt5ovQCa3E\",\n  \"d\": \"sEZYN-iNbQ22ds1fC_hYgrp7PKbzAtiHqxPhvzon9HE\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>hzSul1PikxGRl7k_QdDfCCRMZP4POmt5eNYN0pbjSzE</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>NaUTcaFDyI3Ss48zMmeg1Dal0vhUpOYpWdwfKd2T2S8.eFf9x4K6jhnmAEvveQJo5rIQl32rZooOaNwlJsLf5JQ.hzSul1PikxGRl7k_QdDfCCRMZP4POmt5eNYN0pbjSzE</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>7iRNh25gyaA9Bpnx7axAbyyvbh-bXaPOz8SgvgGksNc</code></li> <li>JWE: <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"Q21aM1gzRFBnZFdQWjRKZFF4VVNMSjBKaEtRRXpJZWphV2cxT04tSE13WQ\",\n        \"apv\": \"ZUZmOXg0SzZqaG5tQUV2dmVRSm81cklRbDMyclpvb09hTndsSnNMZjVKUQ\",\n        \"kid\": \"eFf9x4K6jhnmAEvveQJo5rIQl32rZooOaNwlJsLf5JQ\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"CmZ3X3DPgdWPZ4JdQxUSLJ0JhKQEzIejaWg1ON-HMwY\"\n        }\n      },\n      \"encrypted_key\": \"ZFibn07y4G88HTB6haGfKJLQGWi2a25UVlioG93hgjs2BDIRaWRqzw\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"cU9MdWVjZmdaamJkOVRQYV9qbG5CeFAyak9FQjdOVkZKaGZ6UEk1OFNWOA\",\n        \"apv\": \"ZUZmOXg0SzZqaG5tQUV2dmVRSm81cklRbDMyclpvb09hTndsSnNMZjVKUQ\",\n        \"kid\": \"NaUTcaFDyI3Ss48zMmeg1Dal0vhUpOYpWdwfKd2T2S8\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"qOLuecfgZjbd9TPa_jlnBxP2jOEB7NVFJhfzPI58SV8\"\n        }\n      },\n      \"encrypted_key\": \"EKpcwck9zE0WjEq9E60dm_OJY0U2e1UlUAZE8LYfURo_saE2yzxx_A\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+A256KW\",\n        \"apu\": \"RE1IOGFVVlpUZ2FXaFNaOUFtdFNDQ2M1aUZEbERCeDZnMC1URHpUTFZYUQ\",\n        \"apv\": \"ZUZmOXg0SzZqaG5tQUV2dmVRSm81cklRbDMyclpvb09hTndsSnNMZjVKUQ\",\n        \"kid\": \"hzSul1PikxGRl7k_QdDfCCRMZP4POmt5eNYN0pbjSzE\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"DMH8aUVZTgaWhSZ9AmtSCCc5iFDlDBx6g0-TDzTLVXQ\"\n        }\n      },\n      \"encrypted_key\": \"OeemM4fMI9538IcvG3OwhuVtugrRIoIJEB5iAVZBl7Q59yRr5VZTPQ\"\n    }\n  ],\n  \"aad\": \"7iRNh25gyaA9Bpnx7axAbyyvbh-bXaPOz8SgvgGksNc\",\n  \"iv\": \"9deRACZyiau7rIIc\",\n  \"ciphertext\": \"ombMWgwtw2QSfALdiDk\",\n  \"tag\": \"yRwaSiGsQCqYjIdMSwPPNg\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#12-single-recipient-jwes","title":"1.2 Single Recipient JWEs","text":"<p>Packing a message with 1 recipient using the Flattened JWE JSON serialization and Compact JWE serialization formats as mentioned in the notes above.</p>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#121-nist-p-256-key","title":"1.2.1 NIST P-256 key","text":"<ul> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"2fpy_fK5FCsap0EbU1Om7QXoVoyvBv8gfdHY3ufIS9w\",\n  \"y\": \"TtVOc9c8ejMeqeaUs1CMS79w0-Al02Fw25WdVEb0DiI\",\n  \"d\": \"kEWLCAyDL8mgDLNnlb1am_B8wcaGAe7ViXx1tqKWTVc\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>s6-ZhI1hpx0kM3pDgOrVQs6mRd_8KfEXUkLg8lK7XNA</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImFwdSI6IlJuY3lOa2RuVkZJME0ycHhORnB4Wm1GUlJqQkxjMk54U2poNlpFeFliMTlyVm0xZlNtRkJVbHBHVlEiLCJhcHYiOiJjell0V21oSk1XaHdlREJyVFROd1JHZFBjbFpSY3padFVtUmZPRXRtUlZoVmEweG5PR3hMTjFoT1FRIiwiY3R5IjoiYXBwbGljYXRpb24vZGlkY29tbS1wbGFpbitqc29uIiwiZW5jIjoiQTI1NkdDTSIsImVwayI6eyJjcnYiOiJQLTI1NiIsImt0eSI6IkVDIiwieCI6IkZ3MjZHZ1RSNDNqcTRacWZhUUYwS3NjcUo4emRMWG9fa1ZtX0phQVJaRlUiLCJ5IjoiNENfMk00V2dkcVp5cGdkaVVpMlZCQWsyVXFmYlJvU1AxaUQ3WHIzVGJJZyJ9LCJraWQiOiJzNi1aaEkxaHB4MGtNM3BEZ09yVlFzNm1SZF84S2ZFWFVrTGc4bEs3WE5BIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"encrypted_key\": \"l99n6MvHGvUKRrPORElnlerqmmhQc1WMzJ2pxt6H5gaSWPPsj4Gp0A\",\n  \"iv\": \"CKm9svwMrrXarfG2\",\n  \"ciphertext\": \"k_eAXa-uMtMYSVgJO0A\",\n  \"tag\": \"1cYhCprkvxYYfyNp_fJGUQ\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is: <code>eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImFwdSI6IlJuY3lOa2RuVkZJME0ycHhORnB4Wm1GUlJqQkxjMk54U2poNlpFeFliMTlyVm0xZlNtRkJVbHBHVlEiLCJhcHYiOiJjell0V21oSk1XaHdlREJyVFROd1JHZFBjbFpSY3padFVtUmZPRXRtUlZoVmEweG5PR3hMTjFoT1FRIiwiY3R5IjoiYXBwbGljYXRpb24vZGlkY29tbS1wbGFpbitqc29uIiwiZW5jIjoiQTI1NkdDTSIsImVwayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2IiwieCI6IkZ3MjZHZ1RSNDNqcTRacWZhUUYwS3NjcUo4emRMWG9fa1ZtX0phQVJaRlUiLCJ5IjoiNENfMk00V2dkcVp5cGdkaVVpMlZCQWsyVXFmYlJvU1AxaUQ3WHIzVGJJZyJ9LCJraWQiOiJzNi1aaEkxaHB4MGtNM3BEZ09yVlFzNm1SZF84S2ZFWFVrTGc4bEs3WE5BIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9.l99n6MvHGvUKRrPORElnlerqmmhQc1WMzJ2pxt6H5gaSWPPsj4Gp0A.CKm9svwMrrXarfG2.k_eAXa-uMtMYSVgJO0A.1cYhCprkvxYYfyNp_fJGUQ</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-ES+A256KW\",\n  \"apu\": \"RncyNkdnVFI0M2pxNFpxZmFRRjBLc2NxSjh6ZExYb19rVm1fSmFBUlpGVQ\",\n  \"apv\": \"czYtWmhJMWhweDBrTTNwRGdPclZRczZtUmRfOEtmRVhVa0xnOGxLN1hOQQ\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"A256GCM\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-256\",\n    \"x\": \"Fw26GgTR43jq4ZqfaQF0KscqJ8zdLXo_kVm_JaARZFU\",\n    \"y\": \"4C_2M4WgdqZypgdiUi2VBAk2UqfbRoSP1iD7Xr3TbIg\"\n  },\n  \"kid\": \"s6-ZhI1hpx0kM3pDgOrVQs6mRd_8KfEXUkLg8lK7XNA\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#122-nist-p-384-key","title":"1.2.2 NIST P-384 key","text":"<ul> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"lb17x-OBz2i1kQbkRtSKD3TY1MwIfUMyM8YtqXZXMj884hLJH2QtxmUWKyXIprcn\",\n  \"y\": \"PlT4CInTrA5zAroqwyww0BL6EipnEBTrtbWID8nADz6LFpf_27qlxIARy_iU5OcN\",\n  \"d\": \"JJgpIqGS5JuiKRnsEgGNlYw39pz-XGrsrmniuxlSik0BLwdb8-0K8Xxuqo6yW6NE\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>8wPpWWlLiMBYltw6AoWG3Z_SfgWmXanBHSwZFpQJ0Q0</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImFwdSI6ImNWSkZUMncwWTI5bmJUUkZhWGd3TURGd04zSXpaREl5U0VaQ2FXcHZOV2hmT1RGRE9HOTNjVU5yU2pSdlZWZzFRemh6ZUdOd00zTlhTMXBEZEZaWU13IiwiYXB2IjoiT0hkUWNGZFhiRXhwVFVKWmJIUjNOa0Z2VjBjeldsOVRabWRYYlZoaGJrSklVM2RhUm5CUlNqQlJNQSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsiY3J2IjoiUC0zODQiLCJrdHkiOiJFQyIsIngiOiJxUkVPbDRjb2dtNEVpeDAwMXA3cjNkMjJIRkJpam81aF85MUM4b3dxQ2tKNG9VWDVDOHN4Y3Azc1dLWkN0VlgzIiwieSI6Im5FbmRyZXVPNVFEWFp5eGVmWkJWRDhJeU53WkJER1AwZlJHdXN1LWZXV0NmWlJBdUVsNkZIaXMtSFRNS1puY0UifSwia2lkIjoiOHdQcFdXbExpTUJZbHR3NkFvV0czWl9TZmdXbVhhbkJIU3daRnBRSjBRMCIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ\",\n  \"encrypted_key\": \"OyvZQT0HdCIgDTQKgSbnMfX6iQvPVkOlurgNRqyZlyxj6XeZROYCEQ\",\n  \"iv\": \"sGHLr4VNPKylOCn7\",\n  \"ciphertext\": \"mfnbfoMx8LfXaWSY5po\",\n  \"tag\": \"_FxUsJeY06_bzGJ9vaAtMA\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImFwdSI6ImNWSkZUMncwWTI5bmJUUkZhWGd3TURGd04zSXpaREl5U0VaQ2FXcHZOV2hmT1RGRE9HOTNjVU5yU2pSdlZWZzFRemh6ZUdOd00zTlhTMXBEZEZaWU13IiwiYXB2IjoiT0hkUWNGZFhiRXhwVFVKWmJIUjNOa0Z2VjBjeldsOVRabWRYYlZoaGJrSklVM2RhUm5CUlNqQlJNQSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsIngiOiJxUkVPbDRjb2dtNEVpeDAwMXA3cjNkMjJIRkJpam81aF85MUM4b3dxQ2tKNG9VWDVDOHN4Y3Azc1dLWkN0VlgzIiwieSI6Im5FbmRyZXVPNVFEWFp5eGVmWkJWRDhJeU53WkJER1AwZlJHdXN1LWZXV0NmWlJBdUVsNkZIaXMtSFRNS1puY0UifSwia2lkIjoiOHdQcFdXbExpTUJZbHR3NkFvV0czWl9TZmdXbVhhbkJIU3daRnBRSjBRMCIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ.OyvZQT0HdCIgDTQKgSbnMfX6iQvPVkOlurgNRqyZlyxj6XeZROYCEQ.sGHLr4VNPKylOCn7.mfnbfoMx8LfXaWSY5po._FxUsJeY06_bzGJ9vaAtMA</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-ES+A256KW\",\n  \"apu\": \"cVJFT2w0Y29nbTRFaXgwMDFwN3IzZDIySEZCaWpvNWhfOTFDOG93cUNrSjRvVVg1QzhzeGNwM3NXS1pDdFZYMw\",\n  \"apv\": \"OHdQcFdXbExpTUJZbHR3NkFvV0czWl9TZmdXbVhhbkJIU3daRnBRSjBRMA\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"A256GCM\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-384\",\n    \"x\": \"qREOl4cogm4Eix001p7r3d22HFBijo5h_91C8owqCkJ4oUX5C8sxcp3sWKZCtVX3\",\n    \"y\": \"nEndreuO5QDXZyxefZBVD8IyNwZBDGP0fRGusu-fWWCfZRAuEl6FHis-HTMKZncE\"\n  },\n  \"kid\": \"8wPpWWlLiMBYltw6AoWG3Z_SfgWmXanBHSwZFpQJ0Q0\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#123-nist-p-521-key","title":"1.2.3 NIST P-521 key","text":"<ul> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AHrw8TsyZzIkINFPCAS54Y7UoCI1XAlim95ROPykpjo4q2LvW_VWeBtJLU2SuqTFG4WX9VBzMg5Rq4gMj4oCpMFb\",\n  \"y\": \"AUs4vywsYYuRP0LhFvyI_ippvSY6Tv1S8sEzojd41Ubo86bFlCj5c_wHX2N6hplMU01WAcebPWc24plqF39pkNrK\",\n  \"d\": \"AEklgm76AbNl_nydbcINMgytfoZGRMI1mxfGcIiqw-KHENQMtlujImJrKMUd32njHS1M9e-WqAS8AHLoVdBZmkOo\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>9Miv3vUT2vQL0X80PyrLJm3bzGPuc_aKfPr4txRQIpAs</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImFwdSI6ImRsRjZWRnBMWTFSS2JqUlROM0Z6Y0dGMFRGVldaR3hSVTB4clQyaDJUV2RuU0ZsaFRUaEZNRzFwZWpFemJtUXphRlEwUVVoR01XUm9WRWRPYTI5M09HUnlTVFZEU200dGRsbHdlbUZYWnkxcVoxSXRhWFEwIiwiYXB2IjoiT1UxcGRqTjJWVlF5ZGxGTU1GZzRNRkI1Y2t4S2JUTmlla2RRZFdOZllVdG1VSEkwZEhoU1VVbHdRUSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsiY3J2IjoiUC01MjEiLCJrdHkiOiJFQyIsIngiOiJBTDBNMDJTbkV5Wi1FdTZyS1dyUzFGWFpVRWk1RG9ieklJQjJHalBCTkpvczlkNTNkNFUtQUJ4ZFhZVXhqWktNUEhheU9RaVpfcjJLYzJsb1BvNEVmb3JlIiwieSI6IkFXSkxvVnNTS0l6SVF2VWtKVzIxakVmV2ZHTjhWck1tN2owSmtJb2JUVXlCSEJMa0o3SzFUU19zZ1FpOUkxb0tzRTJ5Mjh2WC1DREFKZGp3Z1FWNl9mLTIifSwia2lkIjoiOU1pdjN2VVQydlFMMFg4MFB5ckxKbTNiekdQdWNfYUtmUHI0dHhSUUlwQSIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ\",\n  \"encrypted_key\": \"rK_MtxEobFF8pyYU8T26U7LRlEdjm1ndq8sZoZ2h9BaAyuhE7bcuAA\",\n  \"iv\": \"X1V-4vkZ1qE3_Yhn\",\n  \"ciphertext\": \"XDf5mmhlDaJfTOp1z_4\",\n  \"tag\": \"se7e3wH5grcMEuJIAJbN9A\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImFwdSI6ImRsRjZWRnBMWTFSS2JqUlROM0Z6Y0dGMFRGVldaR3hSVTB4clQyaDJUV2RuU0ZsaFRUaEZNRzFwZWpFemJtUXphRlEwUVVoR01XUm9WRWRPYTI5M09HUnlTVFZEU200dGRsbHdlbUZYWnkxcVoxSXRhWFEwIiwiYXB2IjoiT1UxcGRqTjJWVlF5ZGxGTU1GZzRNRkI1Y2t4S2JUTmlla2RRZFdOZllVdG1VSEkwZEhoU1VVbHdRUSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsia3R5IjoiRUMiLCJjcnYiOiJQLTUyMSIsIngiOiJBTDBNMDJTbkV5Wi1FdTZyS1dyUzFGWFpVRWk1RG9ieklJQjJHalBCTkpvczlkNTNkNFUtQUJ4ZFhZVXhqWktNUEhheU9RaVpfcjJLYzJsb1BvNEVmb3JlIiwieSI6IkFXSkxvVnNTS0l6SVF2VWtKVzIxakVmV2ZHTjhWck1tN2owSmtJb2JUVXlCSEJMa0o3SzFUU19zZ1FpOUkxb0tzRTJ5Mjh2WC1DREFKZGp3Z1FWNl9mLTIifSwia2lkIjoiOU1pdjN2VVQydlFMMFg4MFB5ckxKbTNiekdQdWNfYUtmUHI0dHhSUUlwQSIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ.rK_MtxEobFF8pyYU8T26U7LRlEdjm1ndq8sZoZ2h9BaAyuhE7bcuAA.X1V-4vkZ1qE3_Yhn.XDf5mmhlDaJfTOp1z_4.se7e3wH5grcMEuJIAJbN9A</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-ES+A256KW\",\n  \"apu\": \"dlF6VFpLY1RKbjRTN3FzcGF0TFVWZGxRU0xrT2h2TWdnSFlhTThFMG1pejEzbmQzaFQ0QUhGMWRoVEdOa293OGRySTVDSm4tdllwemFXZy1qZ1ItaXQ0\",\n  \"apv\": \"OU1pdjN2VVQydlFMMFg4MFB5ckxKbTNiekdQdWNfYUtmUHI0dHhSUUlwQQ\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"A256GCM\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-521\",\n    \"x\": \"AL0M02SnEyZ-Eu6rKWrS1FXZUEi5DobzIIB2GjPBNJos9d53d4U-ABxdXYUxjZKMPHayOQiZ_r2Kc2loPo4Efore\",\n    \"y\": \"AWJLoVsSKIzIQvUkJW21jEfWfGN8VrMm7j0JkIobTUyBHBLkJ7K1TS_sgQi9I1oKsE2y28vX-CDAJdjwgQV6_f-2\"\n  },\n  \"kid\": \"9Miv3vUT2vQL0X80PyrLJm3bzGPuc_aKfPr4txRQIpA\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#124-x25519-key","title":"1.2.4 X25519 key","text":"<ul> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"2kvTqkwVF-YSurN533fi-ZDF4PbLbqa7ohC--DJa0nA\",\n  \"d\": \"sPUMndizynb_q6_u9fkbuU8V3I062-RlL114YnJ7KWY\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>eFf9x4K6jhnmAEvveQJo5rIQl32rZooOaNwlJsLf5JQ</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImFwdSI6IlluQldTM1IyVDJoWGJXOVRRMUJTV21oUk1HdFVaVzlYVDNFMWVrMXZTWGxhY0RCMVlrOU9XVTVXZHciLCJhcHYiOiJaVVptT1hnMFN6WnFhRzV0UVVWMmRtVlJTbTgxY2tsUmJETXljbHB2YjA5aFRuZHNTbk5NWmpWS1VRIiwiY3R5IjoiYXBwbGljYXRpb24vZGlkY29tbS1wbGFpbitqc29uIiwiZW5jIjoiQTI1NkdDTSIsImVwayI6eyJjcnYiOiJYMjU1MTkiLCJrdHkiOiJPS1AiLCJ4IjoiYnBWS3R2T2hXbW9TQ1BSWmhRMGtUZW9XT3E1ek1vSXlacDB1Yk9OWU5WdyJ9LCJraWQiOiJlRmY5eDRLNmpobm1BRXZ2ZVFKbzVySVFsMzJyWm9vT2FOd2xKc0xmNUpRIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"encrypted_key\": \"Pe7sGWcXxY9V7xdKWdpa5GvVinr_YWITRIVY8ic7WmKwY-Lh-3OJdA\",\n  \"iv\": \"Rx__OGcTo72Lv6jG\",\n  \"ciphertext\": \"UEFI2_OqNMki1cXraJA\",\n  \"tag\": \"Hc6WxwF2YGvewcWFmhzkrw\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImFwdSI6IlluQldTM1IyVDJoWGJXOVRRMUJTV21oUk1HdFVaVzlYVDNFMWVrMXZTWGxhY0RCMVlrOU9XVTVXZHciLCJhcHYiOiJaVVptT1hnMFN6WnFhRzV0UVVWMmRtVlJTbTgxY2tsUmJETXljbHB2YjA5aFRuZHNTbk5NWmpWS1VRIiwiY3R5IjoiYXBwbGljYXRpb24vZGlkY29tbS1wbGFpbitqc29uIiwiZW5jIjoiQTI1NkdDTSIsImVwayI6eyJrdHkiOiJPS1AiLCJjcnYiOiJYMjU1MTkiLCJ4IjoiYnBWS3R2T2hXbW9TQ1BSWmhRMGtUZW9XT3E1ek1vSXlacDB1Yk9OWU5WdyJ9LCJraWQiOiJlRmY5eDRLNmpobm1BRXZ2ZVFKbzVySVFsMzJyWm9vT2FOd2xKc0xmNUpRIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9.Pe7sGWcXxY9V7xdKWdpa5GvVinr_YWITRIVY8ic7WmKwY-Lh-3OJdA.Rx__OGcTo72Lv6jG.UEFI2_OqNMki1cXraJA.Hc6WxwF2YGvewcWFmhzkrw</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-ES+A256KW\",\n  \"apu\": \"YnBWS3R2T2hXbW9TQ1BSWmhRMGtUZW9XT3E1ek1vSXlacDB1Yk9OWU5Wdw\",\n  \"apv\": \"ZUZmOXg0SzZqaG5tQUV2dmVRSm81cklRbDMyclpvb09hTndsSnNMZjVKUQ\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"A256GCM\",\n  \"epk\": {\n    \"kty\": \"OKP\",\n    \"crv\": \"X25519\",\n    \"x\": \"bpVKtvOhWmoSCPRZhQ0kTeoWOq5zMoIyZp0ubONYNVw\"\n  },\n  \"kid\": \"eFf9x4K6jhnmAEvveQJo5rIQl32rZooOaNwlJsLf5JQ\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#2-xc20p-content-encryption","title":"2 XC20P content encryption","text":""},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#21-multi-recipients-jwes","title":"2.1 Multi recipients JWEs","text":"<p>The packer generates the following protected headers for XC20P content encryption in the below examples with XC20P enc: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"XC20P\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ</code></p> <p>The same notes above apply here.</p>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#211-nist-p-256-keys","title":"2.1.1 NIST P-256 keys","text":"<ul> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"kdAHozUe6HOhNC9_jsOI60FuHa64zHSwcZa0l22rXX4\",\n  \"y\": \"Sj3iIz_HimnXgLRWU-x_gXjVyF2R0rh6OhuD3gzhUMw\",\n  \"d\": \"NTV27xYkYkwDNYePKHlh6CIYHunx-6rn80cSATOI7rI\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>Ivxk0K5tz7csR7MDXllXWd7YJTQF4pS8IHHkIdepgpk</code></li> <li>Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"sx1ZNsP2rUKuoN0Xe6m2_Zly8wM_-CpuCkDNaOjFYtA\",\n  \"y\": \"lTti40XRekPxw4IfpheZDCxilwEoEWWxyO8d77W_sOo\",\n  \"d\": \"WsHT1GiMy4mxsxQ7mPYtg5Mn18I8PU2wHPttVGEOnXk\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>tkAt85t250uQ3Q3d8W731YJfqF0t1cCwGwWqRxqyQhM</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"AQoZIqg1y0fZ1qvYM5YuinxRtOXa6dMSXfgdYBgsEks\",\n  \"y\": \"JRxsX-U6go0VqWtMFCPFbUNSsLJYiQH7ij2i4-FVQh0\",\n  \"d\": \"Joal2Lk5w6-_C_HpRr__ZtxtJccwjwHZ7RxZe1-CTjY\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>SoySkmiLdE4c7Dp5URlH-DMVNq6-fGrkSpIgzLTYez0</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>Ivxk0K5tz7csR7MDXllXWd7YJTQF4pS8IHHkIdepgpk.SoySkmiLdE4c7Dp5URlH-DMVNq6-fGrkSpIgzLTYez0.tkAt85t250uQ3Q3d8W731YJfqF0t1cCwGwWqRxqyQhM</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>uPokzMsXWxloZTnb2sXzz05KBc_SI1giMmHAenTyMjQ</code></li> <li>Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"R1NNbnFqcGFQMlltUlRNRTVrNVhYT3E2M3FzZjd2emVtbnY5NENVTm9faw\",\n        \"apv\": \"SXZ4azBLNXR6N2NzUjdNRFhsbFhXZDdZSlRRRjRwUzhJSEhrSWRlcGdwaw\",\n        \"kid\": \"Ivxk0K5tz7csR7MDXllXWd7YJTQF4pS8IHHkIdepgpk\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"GSMnqjpaP2YmRTME5k5XXOq63qsf7vzemnv94CUNo_k\",\n          \"y\": \"tDCIMv5gZqyjZmHYvbHxUQO1zN7fH0n9athoWGlO8nI\"\n        }\n      },\n      \"encrypted_key\": \"n63_NKMEy_KOb_34nrTX_Yvbx3Sliee9yh3ZSqs6nm5vhAuCoBMoU40fSpZMB07QLdXKfrRjB4A-WoL_MjTpcpOZnxc1v2s-\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"N1ZNVG00NEFqc0J3amt6WU1STDk5SURRZUh6aWZaa0Q5Q0hSajJJdGtkOA\",\n        \"apv\": \"SXZ4azBLNXR6N2NzUjdNRFhsbFhXZDdZSlRRRjRwUzhJSEhrSWRlcGdwaw\",\n        \"kid\": \"tkAt85t250uQ3Q3d8W731YJfqF0t1cCwGwWqRxqyQhM\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"7VMTm44AjsBwjkzYMRL99IDQeHzifZkD9CHRj2Itkd8\",\n          \"y\": \"NnVWH1gP7qdqzv4Go-1lT_U02i6fJHhmZO33jt4R0Ys\"\n        }\n      },\n      \"encrypted_key\": \"V3Y_kLiogDKAa4p3MNyfh1IOfexv8rLJsZf5idwI2wJDngYzhNyzaV4kqJMMW6qyMaE4bX5LY-qRP4sPcYPwntMj70LUaC6I\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"NzJQTnJ4a1A2V3JCcV9wUkU4VU42T0I3WHFKUXJuZEZHZ3dERVloR21kdw\",\n        \"apv\": \"SXZ4azBLNXR6N2NzUjdNRFhsbFhXZDdZSlRRRjRwUzhJSEhrSWRlcGdwaw\",\n        \"kid\": \"SoySkmiLdE4c7Dp5URlH-DMVNq6-fGrkSpIgzLTYez0\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"72PNrxkP6WrBq_pRE8UN6OB7XqJQrndFGgwDEYhGmdw\",\n          \"y\": \"gDy2dRBTwt1tQBBSnztN0AqvzCu07yFN9FgG109ytsc\"\n        }\n      },\n      \"encrypted_key\": \"2b4op-H7wPoyzno3Krv65rOal2HNmaiDHnjGTywcHAppz-EgHS7hiqANeRCipCNhPj7VvZqe1PWf2m0qLIdBuUv7ryo_nw9E\"\n    }\n  ],\n  \"aad\": \"uPokzMsXWxloZTnb2sXzz05KBc_SI1giMmHAenTyMjQ\",\n  \"iv\": \"KShKEagQokU3UTGeYXw7LwWFankH-zK7\",\n  \"ciphertext\": \"6Z5YKgYQSmxSCtns064\",\n  \"tag\": \"hhW1Y5WgRM2t8-NiUMmKJw\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#212-nist-p-384-keys","title":"2.1.2 NIST P-384 keys","text":"<ul> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"5aCpGZXwubdOSedZl1wc5PHB175a990-bRo2QKzju6uyeXD6hBKcB6vUijQRILMr\",\n  \"y\": \"TeUA_qsYU8YmbHPA58QJuAJiUe0BEbi8Vuq88ZEWLudhJa4Dp5mBKuFEeJQcOQCa\",\n  \"d\": \"wTv7Yh4bZAfCfmz0qL_lKJNlMRYuXjWzE63p7y3mZW8DRtN5LgOE25QKO9v0xgKN\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>35E0yg0TinUSym5bQ5FnUgWirIrfK81p-QCxW7VzCrE</code></li> <li>Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"xYFotAHw0kaqsgkW-3ZirL2p3HC0tJCrrNsK-1MfgoUahWpoDiUpEapuLZrO_hz3\",\n  \"y\": \"LLUQ5gRSwn5x0sQJrByWSdWdqojAhizpsx9GPjvPP9uM4gv7jKUEoi0A-2doNSQR\",\n  \"d\": \"OLPQ8giwvg-pKMMaYTGB3O4RGNPtlX-tRZi3ltUb305nPMsuxplI71OQfTH3-Leq\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>wnJRuK09BydTKCPX9DEsf2hxSB1uzHdHrjLTtsiPUZw</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"DWdQi5HdkPpUEqHtQrLU8xR6hW3_IO-8RPcOY4_aI0VACCO9e8WNCFAcjAja5Q8Y\",\n  \"y\": \"jTan4mkzX1uRU9FRIvZgE1NKS-fUe86cl_xmLJ2jPl-A-EXmTHExVT8q63iVnvSC\",\n  \"d\": \"WnCGfWiiOCglkYWQh1t-KM_A8Pb_HXgUXEJFjg7iWT3SYUL2tgMQQ5w9IUNE-D0r\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>j9ZMlUQX9m9t8_6RmshAfMwHTIOE9_0Mv5bd5bQ4nKw</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>35E0yg0TinUSym5bQ5FnUgWirIrfK81p-QCxW7VzCrE.j9ZMlUQX9m9t8_6RmshAfMwHTIOE9_0Mv5bd5bQ4nKw.wnJRuK09BydTKCPX9DEsf2hxSB1uzHdHrjLTtsiPUZw</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>kOd8LfamiqCqZa4kZJPR0M3k11OjHo1dQgdgaI2HreU</code></li> <li>JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"Zmw3NTdwRFlKVE16YlcwVmdfUWgzTDlrZlRoQ25Dd25uaU81YlBmVkwwUFgxV19LbWpfRzVIT2VDV2NyMEdacQ\",\n        \"apv\": \"MzVFMHlnMFRpblVTeW01YlE1Rm5VZ1dpcklyZks4MXAtUUN4VzdWekNyRQ\",\n        \"kid\": \"35E0yg0TinUSym5bQ5FnUgWirIrfK81p-QCxW7VzCrE\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"fl757pDYJTMzbW0Vg_Qh3L9kfThCnCwnniO5bPfVL0PX1W_Kmj_G5HOeCWcr0GZq\",\n          \"y\": \"moRQSUo5C95n_W5H79i_HWYAIcpmX9Iq2OcuBRe4R9pXmW_p1_dbz7YKSXbJLpEo\"\n        }\n      },\n      \"encrypted_key\": \"fb6sCiAeFzPcfvHdIMKm051fkVioxgBKA6w3sIkw9t_mleCHe_bjFzK9_CfMA6E0aO8Y40WonGWYZ8oKIgRvItNWJsph6zr9\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"ZlcyRHFxR25SaFZHOXlKckN2TWZVRmJlR1RZRl9JWjJYQ1pPcGNvei1vSDJ2aVlERU54Wi1leGJ6c0l1bkoyNQ\",\n        \"apv\": \"MzVFMHlnMFRpblVTeW01YlE1Rm5VZ1dpcklyZks4MXAtUUN4VzdWekNyRQ\",\n        \"kid\": \"wnJRuK09BydTKCPX9DEsf2hxSB1uzHdHrjLTtsiPUZw\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"fW2DqqGnRhVG9yJrCvMfUFbeGTYF_IZ2XCZOpcoz-oH2viYDENxZ-exbzsIunJ25\",\n          \"y\": \"Pz-1Smflo-dAFZ0awotLqF0Qh5iurbbgcCJpN5ZnrrvBlnxiKuAD6o4ytxMS17f1\"\n        }\n      },\n      \"encrypted_key\": \"gGqdDnlCuymQYRwIIHU0Cv4BxUYpby8cjohgbfNc-3kilzLIXN0x53amLz6sxuFvvGjPMv7BykQfoQPZgXj5B5rN--3StojC\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"MTY0dUFMYXVkNmFLR29EMjF0NHd2dGN3QjRxUGNNRFlid3JWemVvY055Q05RelV1NlRTSVFEcExiT3pmMjJIeQ\",\n        \"apv\": \"MzVFMHlnMFRpblVTeW01YlE1Rm5VZ1dpcklyZks4MXAtUUN4VzdWekNyRQ\",\n        \"kid\": \"j9ZMlUQX9m9t8_6RmshAfMwHTIOE9_0Mv5bd5bQ4nKw\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"164uALaud6aKGoD21t4wvtcwB4qPcMDYbwrVzeocNyCNQzUu6TSIQDpLbOzf22Hy\",\n          \"y\": \"SmS8y6E1V87EkDIQfZVJGdyWPRR5gSQXIhNKUF4vDB1OYcMtG4AGFhHlMVNjCipa\"\n        }\n      },\n      \"encrypted_key\": \"ADkTont7J6MvkqtejyCZroaLhzBq6ehDlNJyiIsoV2L-vKOYWPfW2eyhk9_Q_Kc2mdfhsJeZ6S4YN2O1OVSvnGqho3zwKE_z\"\n    }\n  ],\n  \"aad\": \"kOd8LfamiqCqZa4kZJPR0M3k11OjHo1dQgdgaI2HreU\",\n  \"iv\": \"lhR0KWdWpo2TeiHgABGNLMYwGXmykQQX\",\n  \"ciphertext\": \"LMVb7K1-YqLUS9JtE0s\",\n  \"tag\": \"7UkWuQPffiWZIwS4sUc1Hg\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#213-nist-p-521-keys","title":"2.1.3 NIST P-521 keys","text":"<ul> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AIlOiZCrQMU83IOpoiMva75L_OqljXVakEJSjwAl5RaLmaNBZg-TXa0VKlAKTijGZAu_5gS_ZF82LRWDiltUHmX8\",\n  \"y\": \"AFXxgSPOlCNnHtRQE7JmngrT5jgc5kHhMJE82wvMYlyrUdB1kgjN8zJDKkMDJ_dw1U2bEKXmcoCepN654HqmCeNJ\",\n  \"d\": \"ASUBEC_crwIW50ke7p7EBjM0jnA3X7ziwT92TIVgHqTyFkEHKwuP_xbUSePfkhAgcEF2KHz48EgZJuDM6v4L2NXT\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>fr_FYdKBgF_lo1UzC133Tw382LhNDRk6TqwWUwYiytQ</code></li> <li>Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AT71NCmSChOaf38XudcZFpb7eS6GS3rRgjIeXC5AWm9uqjgk3XloPINvlOkATR9syfonjONi4dvgu6ED0gDKyni2\",\n  \"y\": \"AB6EuKG0Z5mnkw_Kk08EW1igFDoZ8tUzs67AoRrLM_CqufmehumGUBAAgPPyQ43HdZQRKn6UYaRn77JZ0kcUE8ZD\",\n  \"d\": \"AMYS0X7aTtbFL8gcSH8h0AkH1kfgJxqe-vyahUoijuM3WtKp0z7C0j-kT717p8xV4NEnIrP7IP9ewCdh21TwCfdJ\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>z70hxN-69UU6IBsqxWMsKa5LqSnCGhd0BKMihYIeHYM</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AcRZHKNmVZlxrKIcBsX-Z8KaGCJfPirBqOBWDylsVJCwvjEEMfJFS2GZtPwfQI5P561XAxjtb0ARPtucoyh5n4_Q\",\n  \"y\": \"AaU8wdiQUItNWJnDrgMK84HhyloKQyXWEYZoDEjppL4kXvIV4CUhfYkTXnTWACUgnVG1uXdycmJ-XhgqPGfezQVb\",\n  \"d\": \"AKfdXHWLY7WqaVVVLFBRyU7fd3EpfiQJW83IkuCk4tJ51PIO6Jzq17H0RI9XjK1YThz-cV1ZBXw9Q7ezDFusgL3k\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>bU2CyYAuV1kJtU8vTE27PaOh20yTgKBSThtjrYHedf8</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>bU2CyYAuV1kJtU8vTE27PaOh20yTgKBSThtjrYHedf8.fr_FYdKBgF_lo1UzC133Tw382LhNDRk6TqwWUwYiytQ.z70hxN-69UU6IBsqxWMsKa5LqSnCGhd0BKMihYIeHYM</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>gyaNc9X50RymOfupxfij36JjhkUG4SEiI4P8LQ0JCvI</code></li> <li>JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"QVdYTV9BOVF2WUZnUFYwMTRmUzk5LUNvX2dyS3BTZi1xbTJmeDdYRFpzekJrT2V3ZHlOSUp5S1gteFdQUUM1RWcwc0gtR0VnTGNWNXNRZThrNktuQWZYeA\",\n        \"apv\": \"ZnJfRllkS0JnRl9sbzFVekMxMzNUdzM4MkxoTkRSazZUcXdXVXdZaXl0UQ\",\n        \"kid\": \"fr_FYdKBgF_lo1UzC133Tw382LhNDRk6TqwWUwYiytQ\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"AWXM_A9QvYFgPV014fS99-Co_grKpSf-qm2fx7XDZszBkOewdyNIJyKX-xWPQC5Eg0sH-GEgLcV5sQe8k6KnAfXx\",\n          \"y\": \"ANlcV5mvTqpzGF8loKsBjC_UFkfg260SFwrabuTBn_4oi1l5wKx7yootfvqrgGG1ivbuMIZ4NndJsbreyUywddQS\"\n        }\n      },\n      \"encrypted_key\": \"SkZaMkjfoo-0PPQvWXottqV3dwOhcY7rCDckVkPRlxbj8jb_m4veIu-nx8jnkJMLUVqguKD_JhZ78MRAEikPg-gARUKyVRKV\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"SElkUWNuaGluTUhhaEw1eDNsUGYxZWlrbW13NUFxNE9SSUpwTFhiQVV4NVJZbjF2dFVSeld4UHc0aU9nY1FOWjJCbEZVU21Md0FaUmhvdlFfb2J1MmZr\",\n        \"apv\": \"ZnJfRllkS0JnRl9sbzFVekMxMzNUdzM4MkxoTkRSazZUcXdXVXdZaXl0UQ\",\n        \"kid\": \"z70hxN-69UU6IBsqxWMsKa5LqSnCGhd0BKMihYIeHYM\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"AByHUHJ4YpzB2oS-cd5T39XopJpsOQKuDkSCaS12wFMeUWJ9b7VEc1sT8OIjoHEDWdgZRVEpi8AGUYaL0P6G7tn5\",\n          \"y\": \"AFbfZdEiMwMy4rN0hzMl3XQgBpE98gE8A37bLLLZi-wAbyuNBhhGCWjxc2XSCRTn9IxBSV72Q8lttaIPWTRGsJPZ\"\n        }\n      },\n      \"encrypted_key\": \"qgNULlqzY68vVzd07nuuuCSqDewr1mu45xhzCFriEdYNvoFmGl_elZua6r0gyknDsskbLOM_zAhg86Ieafn87YT-jOKZWXvB\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"QWNJU1U1bVJwemJrYUs5TUs0ZVNHWXFBNFo5TFVwOF8yNHkwUnhmazExby1GazNvazZCUzk2X3REeWlfM0Y0bDhDU3VyanA3bUxhMGp4YVJ6M1NZbDRRMw\",\n        \"apv\": \"ZnJfRllkS0JnRl9sbzFVekMxMzNUdzM4MkxoTkRSazZUcXdXVXdZaXl0UQ\",\n        \"kid\": \"bU2CyYAuV1kJtU8vTE27PaOh20yTgKBSThtjrYHedf8\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"AcISU5mRpzbkaK9MK4eSGYqA4Z9LUp8_24y0Rxfk11o-Fk3ok6BS96_tDyi_3F4l8CSurjp7mLa0jxaRz3SYl4Q3\",\n          \"y\": \"AYfx95SYdTrF5-FFJ6DX8YIQ3-kI3zA2huvwAoE5on4tczuZtRDxAnXocVXwydU_hYFICv4F1_U2wf2MZxu5EjgO\"\n        }\n      },\n      \"encrypted_key\": \"N38f1rvfk00bHCRbAkMajaCmwIM6C96QNs5ck5i6EhoyONADKitu1E7FpMtwA7IBkLZXSPAz_2RRQg_yp494uh5unNgeIAsm\"\n    }\n  ],\n  \"aad\": \"gyaNc9X50RymOfupxfij36JjhkUG4SEiI4P8LQ0JCvI\",\n  \"iv\": \"y3t1nlPy-e5KlPZmhH6yvXweEnB50cW9\",\n  \"ciphertext\": \"twYiHmEUk1QZw-XbLbY\",\n  \"tag\": \"WsYbX9YDCcIAorqBbS2X_w\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#214-x25519-keys","title":"2.1.4 X25519 keys","text":"<ul> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"h5iIEBNlEHEhCgYLXAOXOofqYEA9Jo0Q1NUggjdwrVw\",\n  \"d\": \"oEGk3DVSpzrZR6mcUF0EXmijrATej7xnPdlcPJDz53M\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>S-qQ_rRIsrscxdmzuplVLW5bqoxj08KO6BBkLZAxh-E</code></li> <li>Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"xawtbSFE5QYe7KDcYRBlnyozY9uPTzlRQ3gClzHzt2Q\",\n  \"d\": \"yC7gzjKFdFwsCA4x7QL0S-eRhI2H966MjTdNA8IrMFw\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>m8EQ2XejsBRZ8sieSLapsS4-tO9ZQNjjxtjL6DOhP64</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"cvxZ6JaCIfmrTXiyHYNyqmxRSsUF8TEabuWOcZdgLT0\",\n  \"d\": \"IM-XG4jc_Zyd5yWdv1i7vruFK4X2LzNTRicHvPZNznU\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>oz3AtqUGnNpsT6OugQksyvY52HI36kCBtXqLE4joP3M</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>S-qQ_rRIsrscxdmzuplVLW5bqoxj08KO6BBkLZAxh-E.m8EQ2XejsBRZ8sieSLapsS4-tO9ZQNjjxtjL6DOhP64.oz3AtqUGnNpsT6OugQksyvY52HI36kCBtXqLE4joP3M</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>Iri2F6uTNldPiiJNYNrlVb_Nt_c2XlPVdDKfmlnkBn4</code></li> <li>JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInR5cCI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tZW5jcnlwdGVkK2pzb24ifQ\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"eE9ZYmZrX0VLbmJaQmRoU1lPclI3NFVWWmlqZFU3LWg3ZF9aTkJ4VW1rMA\",\n        \"apv\": \"Uy1xUV9yUklzcnNjeGRtenVwbFZMVzVicW94ajA4S082QkJrTFpBeGgtRQ\",\n        \"kid\": \"S-qQ_rRIsrscxdmzuplVLW5bqoxj08KO6BBkLZAxh-E\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"xOYbfk_EKnbZBdhSYOrR74UVZijdU7-h7d_ZNBxUmk0\"\n        }\n      },\n      \"encrypted_key\": \"gPbf9-YZLPoEoKmaU70H8O9fsKiPy8rNiNuAvKog4AhGfy1axF4LuMdAZgO4EixyS4WC9V6JnfaYxmt3tFiCx80YXZrVlTBO\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"eU9MMUM0blZzTzRTa1ROWDVRTlVCVl9iVmhJeVd1ZGdKOTlkRWdURDl5cw\",\n        \"apv\": \"Uy1xUV9yUklzcnNjeGRtenVwbFZMVzVicW94ajA4S082QkJrTFpBeGgtRQ\",\n        \"kid\": \"m8EQ2XejsBRZ8sieSLapsS4-tO9ZQNjjxtjL6DOhP64\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"yOL1C4nVsO4SkTNX5QNUBV_bVhIyWudgJ99dEgTD9ys\"\n        }\n      },\n      \"encrypted_key\": \"dsWHHkRbT9BWdgBl5MAUgNTenqiEjR4Z2cgaOLaraCDezRb051Z_muMo70-yJx1O9YDwLHq2V87dKQJX-byYtBeIR-5BubLm\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-ES+XC20PKW\",\n        \"apu\": \"RkdtN2t4aGJFNGVBLWJpM1l2WTZPNVBCd2YtTlhEZ29YaWwzS19zLW5tSQ\",\n        \"apv\": \"Uy1xUV9yUklzcnNjeGRtenVwbFZMVzVicW94ajA4S082QkJrTFpBeGgtRQ\",\n        \"kid\": \"oz3AtqUGnNpsT6OugQksyvY52HI36kCBtXqLE4joP3M\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"FGm7kxhbE4eA-bi3YvY6O5PBwf-NXDgoXil3K_s-nmI\"\n        }\n      },\n      \"encrypted_key\": \"sEygr10dbgwHRy8-ktu8jLcACTKD1g7LfEkUSV_mAZNr1P06RhijZTRq47xesJuPWF8lfkAsK-UETLJ92KGRmbgCdSHQQwaG\"\n    }\n  ],\n  \"aad\": \"Iri2F6uTNldPiiJNYNrlVb_Nt_c2XlPVdDKfmlnkBn4\",\n  \"iv\": \"MWxpdCQBhVoiskZF7QD3bLzgI-iBEE3O\",\n  \"ciphertext\": \"FtAX4yKH2a2dZqM6Zdk\",\n  \"tag\": \"lR8OsOJieRydzSvI-qpy5w\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#22-single-recipient-jwes","title":"2.2 Single Recipient JWEs","text":"<p>Packing a message with 1 recipient using the Flattened JWE JSON serialization and the Compact JWE serialization formats as mentioned in the notes above.</p>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#221-nist-p-256-key","title":"2.2.1 NIST P-256 key","text":"<ul> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"kdAHozUe6HOhNC9_jsOI60FuHa64zHSwcZa0l22rXX4\",\n  \"y\": \"Sj3iIz_HimnXgLRWU-x_gXjVyF2R0rh6OhuD3gzhUMw\",\n  \"d\": \"NTV27xYkYkwDNYePKHlh6CIYHunx-6rn80cSATOI7rI\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>Ivxk0K5tz7csR7MDXllXWd7YJTQF4pS8IHHkIdepgpk</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILUVTK1hDMjBQS1ciLCJhcHUiOiJUWEl4TnpCM2JqSTJXa00wY0Y5SFVDMTBNazlyVFd0ZmExOVJVRkYxY1hObk5IUlFNV0pMU0hCdk1BIiwiYXB2IjoiU1haNGF6QkxOWFI2TjJOelVqZE5SRmhzYkZoWFpEZFpTbFJSUmpSd1V6aEpTRWhyU1dSbGNHZHdhdyIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IlhDMjBQIiwiZXBrIjp7ImNydiI6IlAtMjU2Iiwia3R5IjoiRUMiLCJ4IjoiTXIxNzB3bjI2WkM0cF9HUC10Mk9rTWtfa19RUFF1cXNnNHRQMWJLSHBvMCIsInkiOiJ1MUMydEJuYlFwUS1YTWx0SHRFdWNJaFVod1FCeDBCbklLZFlkN3FLRVFFIn0sImtpZCI6Ikl2eGswSzV0ejdjc1I3TURYbGxYV2Q3WUpUUUY0cFM4SUhIa0lkZXBncGsiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"encrypted_key\": \"1k4IQgN6LIiV8mnNWUI2OyNXLRHvg75qZIyHf6_wtrBIYZlic1coUL3lekvesQpmLb1A9vip-pKi0yDKZOQIMtQS3TJ81EJJ\",\n  \"iv\": \"6Qky6FL-Uzpi5nvaZHobo3_8xqv-LF4h\",\n  \"ciphertext\": \"mqQ6nsR76RMLvNLkJgU\",\n  \"tag\": \"5S99fa_S2c4XsVrzM2rPDw\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILUVTK1hDMjBQS1ciLCJhcHUiOiJUWEl4TnpCM2JqSTJXa00wY0Y5SFVDMTBNazlyVFd0ZmExOVJVRkYxY1hObk5IUlFNV0pMU0hCdk1BIiwiYXB2IjoiU1haNGF6QkxOWFI2TjJOelVqZE5SRmhzYkZoWFpEZFpTbFJSUmpSd1V6aEpTRWhyU1dSbGNHZHdhdyIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IlhDMjBQIiwiZXBrIjp7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjoiTXIxNzB3bjI2WkM0cF9HUC10Mk9rTWtfa19RUFF1cXNnNHRQMWJLSHBvMCIsInkiOiJ1MUMydEJuYlFwUS1YTWx0SHRFdWNJaFVod1FCeDBCbklLZFlkN3FLRVFFIn0sImtpZCI6Ikl2eGswSzV0ejdjc1I3TURYbGxYV2Q3WUpUUUY0cFM4SUhIa0lkZXBncGsiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0.1k4IQgN6LIiV8mnNWUI2OyNXLRHvg75qZIyHf6_wtrBIYZlic1coUL3lekvesQpmLb1A9vip-pKi0yDKZOQIMtQS3TJ81EJJ.6Qky6FL-Uzpi5nvaZHobo3_8xqv-LF4h.mqQ6nsR76RMLvNLkJgU.5S99fa_S2c4XsVrzM2rPDw</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-ES+XC20PKW\",\n  \"apu\": \"TXIxNzB3bjI2WkM0cF9HUC10Mk9rTWtfa19RUFF1cXNnNHRQMWJLSHBvMA\",\n  \"apv\": \"SXZ4azBLNXR6N2NzUjdNRFhsbFhXZDdZSlRRRjRwUzhJSEhrSWRlcGdwaw\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"XC20P\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-256\",\n    \"x\": \"Mr170wn26ZC4p_GP-t2OkMk_k_QPQuqsg4tP1bKHpo0\",\n    \"y\": \"u1C2tBnbQpQ-XMltHtEucIhUhwQBx0BnIKdYd7qKEQE\"\n  },\n  \"kid\": \"Ivxk0K5tz7csR7MDXllXWd7YJTQF4pS8IHHkIdepgpk\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#222-nist-p-384-key","title":"2.2.2 NIST P-384 key","text":"<ul> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"5aCpGZXwubdOSedZl1wc5PHB175a990-bRo2QKzju6uyeXD6hBKcB6vUijQRILMr\",\n  \"y\": \"TeUA_qsYU8YmbHPA58QJuAJiUe0BEbi8Vuq88ZEWLudhJa4Dp5mBKuFEeJQcOQCa\",\n  \"d\": \"wTv7Yh4bZAfCfmz0qL_lKJNlMRYuXjWzE63p7y3mZW8DRtN5LgOE25QKO9v0xgKN\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>35E0yg0TinUSym5bQ5FnUgWirIrfK81p-QCxW7VzCrE</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILUVTK1hDMjBQS1ciLCJhcHUiOiJkbkJCYkVKc1pXUXlWM0YzTUY5VVNYTk1iM1JLVmpBek4ydzNOMmxDYzA5Mk0xRnhiSEZSVWxaSGNHeGZkRWR2UVc5VFNXRnpVR0kwY0RjeGFIVTBiUSIsImFwdiI6Ik16VkZNSGxuTUZScGJsVlRlVzAxWWxFMVJtNVZaMWRwY2tseVprczRNWEF0VVVONFZ6ZFdla055UlEiLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJjcnYiOiJQLTM4NCIsImt0eSI6IkVDIiwieCI6InZwQWxCbGVkMldxdzBfVElzTG90SlYwMzdsNzdpQnNPdjNRcWxxUVJWR3BsX3RHb0FvU0lhc1BiNHA3MWh1NG0iLCJ5IjoiU0Y3VEJDVnB5dTUwQ21vMzY0TWsyS2VyWGVwYnlYSklXZF8yTHNYMnNDMENWTkV1aFVJUHhFMmQtVjFVS1hwciJ9LCJraWQiOiIzNUUweWcwVGluVVN5bTViUTVGblVnV2lySXJmSzgxcC1RQ3hXN1Z6Q3JFIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"encrypted_key\": \"y7jUbtMzOyerWyPhTgTutFH0r18Ug6uF3FYdTCyp2V-PacHeR8OTsNEh7dEOQk9o5P9mXvcGvfGr2xFNtoBw561TPv_Iw2ZK\",\n  \"iv\": \"DOEADxox8cUL0jQ_H4hP67ymgscn8nQc\",\n  \"ciphertext\": \"hSjiRkcMflJJK18cuXU\",\n  \"tag\": \"SHN2rmcofMmnSqQ8htiCcQ\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILUVTK1hDMjBQS1ciLCJhcHUiOiJkbkJCYkVKc1pXUXlWM0YzTUY5VVNYTk1iM1JLVmpBek4ydzNOMmxDYzA5Mk0xRnhiSEZSVWxaSGNHeGZkRWR2UVc5VFNXRnpVR0kwY0RjeGFIVTBiUSIsImFwdiI6Ik16VkZNSGxuTUZScGJsVlRlVzAxWWxFMVJtNVZaMWRwY2tseVprczRNWEF0VVVONFZ6ZFdla055UlEiLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMzg0IiwieCI6InZwQWxCbGVkMldxdzBfVElzTG90SlYwMzdsNzdpQnNPdjNRcWxxUVJWR3BsX3RHb0FvU0lhc1BiNHA3MWh1NG0iLCJ5IjoiU0Y3VEJDVnB5dTUwQ21vMzY0TWsyS2VyWGVwYnlYSklXZF8yTHNYMnNDMENWTkV1aFVJUHhFMmQtVjFVS1hwciJ9LCJraWQiOiIzNUUweWcwVGluVVN5bTViUTVGblVnV2lySXJmSzgxcC1RQ3hXN1Z6Q3JFIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9.y7jUbtMzOyerWyPhTgTutFH0r18Ug6uF3FYdTCyp2V-PacHeR8OTsNEh7dEOQk9o5P9mXvcGvfGr2xFNtoBw561TPv_Iw2ZK.DOEADxox8cUL0jQ_H4hP67ymgscn8nQc.hSjiRkcMflJJK18cuXU.SHN2rmcofMmnSqQ8htiCcQ</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-ES+XC20PKW\",\n  \"apu\": \"dnBBbEJsZWQyV3F3MF9USXNMb3RKVjAzN2w3N2lCc092M1FxbHFRUlZHcGxfdEdvQW9TSWFzUGI0cDcxaHU0bQ\",\n  \"apv\": \"MzVFMHlnMFRpblVTeW01YlE1Rm5VZ1dpcklyZks4MXAtUUN4VzdWekNyRQ\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"XC20P\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-384\",\n    \"x\": \"vpAlBled2Wqw0_TIsLotJV037l77iBsOv3QqlqQRVGpl_tGoAoSIasPb4p71hu4m\",\n    \"y\": \"SF7TBCVpyu50Cmo364Mk2KerXepbyXJIWd_2LsX2sC0CVNEuhUIPxE2d-V1UKXpr\"\n  },\n  \"kid\": \"35E0yg0TinUSym5bQ5FnUgWirIrfK81p-QCxW7VzCrE\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#223-nist-p-521-key","title":"2.2.3 NIST P-521 key","text":"<ul> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AIlOiZCrQMU83IOpoiMva75L_OqljXVakEJSjwAl5RaLmaNBZg-TXa0VKlAKTijGZAu_5gS_ZF82LRWDiltUHmX8\",\n  \"y\": \"AFXxgSPOlCNnHtRQE7JmngrT5jgc5kHhMJE82wvMYlyrUdB1kgjN8zJDKkMDJ_dw1U2bEKXmcoCepN654HqmCeNJ\",\n  \"d\": \"ASUBEC_crwIW50ke7p7EBjM0jnA3X7ziwT92TIVgHqTyFkEHKwuP_xbUSePfkhAgcEF2KHz48EgZJuDM6v4L2NXT\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>fr_FYdKBgF_lo1UzC133Tw382LhNDRk6TqwWUwYiytQ</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILUVTK1hDMjBQS1ciLCJhcHUiOiJOa3hhTFd0bGNtczNTWEYzV1hCeE5FOUpYemt0U2tGSGEyMVZUVEl0ZDB0a1VtUlhUV1JxY2sxNlV6ZDVRelpuVTFnMFdHOVJWM0ZRZEdWRE1UTjVTWGxXY2tKVGNuWlJOWGhSZGtVNFVEQllOVTA1UW1GQiIsImFwdiI6IlpuSmZSbGxrUzBKblJsOXNiekZWZWtNeE16TlVkek00TWt4b1RrUlNhelpVY1hkWFZYZFphWGwwVVEiLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJjcnYiOiJQLTUyMSIsImt0eSI6IkVDIiwieCI6IkFPaTJmcEhxNU95S3NHS2F1RGlQX2ZpUUJwSmxETnZzQ25VWFZqSFk2ek0wdThndW9FbC1GNkVGcWo3WGd0ZDhpTWxhd1VxNzBPY1VMeFBEOUYtVFBRV2ciLCJ5IjoiQUVDX1VwU2poQzZlYnplSlBUc0JSb1YwNG9GdzZleDFRRzVpQW1OMm9hWVA3RVAtbU1YcEJRc2R3SEsyVFhpb1d5Q3ozZEU4d0JLUmZkcHFEaHdrRzFSaiJ9LCJraWQiOiJmcl9GWWRLQmdGX2xvMVV6QzEzM1R3MzgyTGhORFJrNlRxd1dVd1lpeXRRIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"encrypted_key\": \"bsghnB_jpcD8E7k1Q2lEizymrCDatLiMH5w9MmWtP6PkpQuonoXXoLk0T-qmC3hK7pEBHdji9YKxPT2NQ-2x7F1Tzf-juieh\",\n  \"iv\": \"SFKS4kMCTfU0tjUfn0YGh79rSWX9RGkP\",\n  \"ciphertext\": \"Fg9hiOjUvP3WU5c0tco\",\n  \"tag\": \"QJ2jlC_o-UiUvpFo7OF0Ew\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILUVTK1hDMjBQS1ciLCJhcHUiOiJOa3hhTFd0bGNtczNTWEYzV1hCeE5FOUpYemt0U2tGSGEyMVZUVEl0ZDB0a1VtUlhUV1JxY2sxNlV6ZDVRelpuVTFnMFdHOVJWM0ZRZEdWRE1UTjVTWGxXY2tKVGNuWlJOWGhSZGtVNFVEQllOVTA1UW1GQiIsImFwdiI6IlpuSmZSbGxrUzBKblJsOXNiekZWZWtNeE16TlVkek00TWt4b1RrUlNhelpVY1hkWFZYZFphWGwwVVEiLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJrdHkiOiJFQyIsImNydiI6IlAtNTIxIiwieCI6IkFPaTJmcEhxNU95S3NHS2F1RGlQX2ZpUUJwSmxETnZzQ25VWFZqSFk2ek0wdThndW9FbC1GNkVGcWo3WGd0ZDhpTWxhd1VxNzBPY1VMeFBEOUYtVFBRV2ciLCJ5IjoiQUVDX1VwU2poQzZlYnplSlBUc0JSb1YwNG9GdzZleDFRRzVpQW1OMm9hWVA3RVAtbU1YcEJRc2R3SEsyVFhpb1d5Q3ozZEU4d0JLUmZkcHFEaHdrRzFSaiJ9LCJraWQiOiJmcl9GWWRLQmdGX2xvMVV6QzEzM1R3MzgyTGhORFJrNlRxd1dVd1lpeXRRIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9.bsghnB_jpcD8E7k1Q2lEizymrCDatLiMH5w9MmWtP6PkpQuonoXXoLk0T-qmC3hK7pEBHdji9YKxPT2NQ-2x7F1Tzf-juieh.SFKS4kMCTfU0tjUfn0YGh79rSWX9RGkP.Fg9hiOjUvP3WU5c0tco.QJ2jlC_o-UiUvpFo7OF0Ew</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-ES+XC20PKW\",\n  \"apu\": \"NkxaLWtlcms3SXF3WXBxNE9JXzktSkFHa21VTTItd0tkUmRXTWRqck16Uzd5QzZnU1g0WG9RV3FQdGVDMTN5SXlWckJTcnZRNXhRdkU4UDBYNU05QmFB\",\n  \"apv\": \"ZnJfRllkS0JnRl9sbzFVekMxMzNUdzM4MkxoTkRSazZUcXdXVXdZaXl0UQ\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"XC20P\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-521\",\n    \"x\": \"AOi2fpHq5OyKsGKauDiP_fiQBpJlDNvsCnUXVjHY6zM0u8guoEl-F6EFqj7Xgtd8iMlawUq70OcULxPD9F-TPQWg\",\n    \"y\": \"AEC_UpSjhC6ebzeJPTsBRoV04oFw6ex1QG5iAmN2oaYP7EP-mMXpBQsdwHK2TXioWyCz3dE8wBKRfdpqDhwkG1Rj\"\n  },\n  \"kid\": \"fr_FYdKBgF_lo1UzC133Tw382LhNDRk6TqwWUwYiytQ\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/anoncrypt-examples/#224-x25519-key","title":"2.2.4 X25519 key","text":"<ul> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"h5iIEBNlEHEhCgYLXAOXOofqYEA9Jo0Q1NUggjdwrVw\",\n  \"d\": \"oEGk3DVSpzrZR6mcUF0EXmijrATej7xnPdlcPJDz53M\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>S-qQ_rRIsrscxdmzuplVLW5bqoxj08KO6BBkLZAxh-E</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILUVTK1hDMjBQS1ciLCJhcHUiOiJjR1JKV1dNMlNVRm9SMnN3Unpsd1VHOUxPR1ZpYWtzM1QzbEpWMDlTV25oSVdsQm9hRmhWTWxoR1RRIiwiYXB2IjoiVXkxeFVWOXlVa2x6Y25OamVHUnRlblZ3YkZaTVZ6VmljVzk0YWpBNFMwODJRa0pyVEZwQmVHZ3RSUSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IlhDMjBQIiwiZXBrIjp7ImNydiI6IlgyNTUxOSIsImt0eSI6Ik9LUCIsIngiOiJwZElZYzZJQWhHazBHOXBQb0s4ZWJqSzdPeUlXT1JaeEhaUGhoWFUyWEZNIn0sImtpZCI6IlMtcVFfclJJc3JzY3hkbXp1cGxWTFc1YnFveGowOEtPNkJCa0xaQXhoLUUiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"encrypted_key\": \"VmgHr9mZuwN1dxRqd0B9n2yE4ErM14Mhri5XpYL93UVT5ZLGkUPKMG1-hdvLDhCUUdfJg5ronQke1HnOKcLgEgEO2Uh-jNHY\",\n  \"iv\": \"M7A2POrqH_lcXV_fwYgYGp3any_9sKFt\",\n  \"ciphertext\": \"gPNQD52uPxlA2881Ct4\",\n  \"tag\": \"JHq2fnYwqUYc3hUgUWaMsw\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILUVTK1hDMjBQS1ciLCJhcHUiOiJjR1JKV1dNMlNVRm9SMnN3Unpsd1VHOUxPR1ZpYWtzM1QzbEpWMDlTV25oSVdsQm9hRmhWTWxoR1RRIiwiYXB2IjoiVXkxeFVWOXlVa2x6Y25OamVHUnRlblZ3YkZaTVZ6VmljVzk0YWpBNFMwODJRa0pyVEZwQmVHZ3RSUSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IlhDMjBQIiwiZXBrIjp7Imt0eSI6Ik9LUCIsImNydiI6IlgyNTUxOSIsIngiOiJwZElZYzZJQWhHazBHOXBQb0s4ZWJqSzdPeUlXT1JaeEhaUGhoWFUyWEZNIn0sImtpZCI6IlMtcVFfclJJc3JzY3hkbXp1cGxWTFc1YnFveGowOEtPNkJCa0xaQXhoLUUiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0.VmgHr9mZuwN1dxRqd0B9n2yE4ErM14Mhri5XpYL93UVT5ZLGkUPKMG1-hdvLDhCUUdfJg5ronQke1HnOKcLgEgEO2Uh-jNHY.M7A2POrqH_lcXV_fwYgYGp3any_9sKFt.gPNQD52uPxlA2881Ct4.JHq2fnYwqUYc3hUgUWaMsw</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-ES+XC20PKW\",\n  \"apu\": \"cGRJWWM2SUFoR2swRzlwUG9LOGViaks3T3lJV09SWnhIWlBoaFhVMlhGTQ\",\n  \"apv\": \"Uy1xUV9yUklzcnNjeGRtenVwbFZMVzVicW94ajA4S082QkJrTFpBeGgtRQ\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"XC20P\",\n  \"epk\": {\n    \"kty\": \"OKP\",\n    \"crv\": \"X25519\",\n    \"x\": \"pdIYc6IAhGk0G9pPoK8ebjK7OyIWORZxHZPhhXU2XFM\"\n  },\n  \"kid\": \"S-qQ_rRIsrscxdmzuplVLW5bqoxj08KO6BBkLZAxh-E\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/","title":"Table of Contents","text":"<ul> <li>Authcrypt JWE Concrete examples</li> <li>Notes</li> <li>1 A256GCM Content Encryption<ul> <li>1.1 Multi recipients JWEs</li> <li>1.1.1 NIST P-256 keys</li> <li>1.1.2 NIST P-384 keys</li> <li>1.1.3 NIST P-521 keys</li> <li>1.1.4 X25519 keys</li> <li>1.2 Single Recipient JWEs</li> <li>1.2.1 NIST P-256 key</li> <li>1.2.2 NIST P-384 key</li> <li>1.2.3 NIST P-521 key</li> <li>1.2.4 X25519 key</li> </ul> </li> <li>2 XC20P content encryption<ul> <li>2.1 Multi recipients JWEs</li> <li>2.1.1 NIST P-256 keys</li> <li>2.1.2 NIST P-384 keys</li> <li>2.1.3 NIST P-521 keys</li> <li>2.1.4 X25519 keys</li> <li>2.2 Single Recipient JWEs</li> <li>2.2.1 NIST P-256 key</li> <li>2.2.2 NIST P-384 key</li> <li>2.2.3 NIST P-521 key</li> <li>2.2.4 X25519 key</li> </ul> </li> </ul> <p>Created by gh-md-toc</p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#authcrypt-jwe-concrete-examples","title":"Authcrypt JWE Concrete examples","text":"<p>The following examples are for JWE authcrypt packer for encrypting the payload <code>secret message</code> and aad value set as the concatenation of recipients' KIDs (ASCII sorted) joined by <code>.</code> for non-compact serializations (JWE Compact serializations don't have AAD).</p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#notes","title":"Notes","text":"<ul> <li>Since autchrypt requires the sender public key, it must be previously sent, out of band, to the recipient(s). For security reasons, the JWE envelope only includes the sender kid as <code>skid</code> in the protected headers. The recipient must be able to resolve the corresponding sender public key during unpack(JWE).</li> <li>all <code>x</code> and <code>y</code> key coordinates values below are raw (no padding) base64URL encoded.</li> <li>JWE envelopes with multi recipients use the General JWE JSON Serialization format.</li> <li>JWE envelopes with a single recipient will be shown either as JWE Compact or Flattened JWE JSON serialization format.</li> <li>General JWE JSON Serialization format uses the above mentioned AAD value in their envelope.</li> <li>JWE Compact Serialization format does not support AAD values and therefore were built without it.</li> <li>all <code>apu</code> recipient header values are set with the raw (no padding) base64URL encoding of the corresponding sender's <code>kid</code> (<code>skid</code>) value since authcrypt reveals the sender.</li> <li>all <code>apv</code> recipient header values are set with the raw (no padding) base64URL encoding of the corresponding recipient's <code>kid</code> value.</li> <li>The final aad used to encrypt the payload is the concatenation of the raw (no padding) base64URL encoded protected headers and <code>aad</code> JWE header joined by a <code>.</code>.</li> <li>Even though flattened serialization do support <code>aad</code>, the field is omitted in the below examples to be consistent with compact JWE serialization format. Implementations should support <code>aad</code> for flattened serialization regardless.</li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#1-a256gcm-content-encryption","title":"1 A256GCM Content Encryption","text":""},{"location":"features/0334-jwe-envelope/authcrypt-examples/#11-multi-recipients-jwes","title":"1.1 Multi recipients JWEs","text":""},{"location":"features/0334-jwe-envelope/authcrypt-examples/#111-nist-p-256-keys","title":"1.1.1 NIST P-256 keys","text":"<p>The packer generates the following protected headers that includes the skid: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"A256GCM\",\"skid\":\"6PBTUbcLB7-Z4fuAFn42oC1PaMsNmjheq1FeZEUgV_8\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwic2tpZCI6IjZQQlRVYmNMQjctWjRmdUFGbjQyb0MxUGFNc05tamhlcTFGZVpFVWdWXzgiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0</code></p> <ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"eFRTD4VaryfwIqLOpq7iuXmBbLjKPq5sVNzxwL7H1CI\",\n  \"y\": \"cIeogn-pLJXlCepb9BqwNKKW4tmNea3Is8G47aPob6M\",\n  \"d\": \"11NyNGrw4JoU7-_bwoZlVDTJi5vkMrSs4Nme_OHnx6Q\"\n}\n</code></pre></li> <li>Sender kid (aka <code>skid</code>, jwk thumbprint raw base64 URL encoded): <code>6PBTUbcLB7-Z4fuAFn42oC1PaMsNmjheq1FeZEUgV_8</code></li> <li>Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"UP08dxIWu14HWRCI48Tnohm7jhaJ87fFdvYyf0w4lkg\",\n  \"y\": \"ohZVfvhQViMGb_n-Y66TewBO2gtE_udG_DsNe8c-T8w\",\n  \"d\": \"O0ikvlb4fh7daJpqd9JIgYk5e-twB0IYyKpoqmb7ZCc\"\n}\n</code></pre></li> <li>Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>D_kHovGtLUZ_ssw_vhZcqsx3LvQ6qC5JK74iPf9vqwk</code></li> <li>Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"XgkWXrogHmvx-wee7KAhi-eP6dpoyUcDKn224vpOshw\",\n  \"y\": \"MAfbXLDMUOg6749jT0nDPZZIxfeozhdaKW6s3hutGHE\",\n  \"d\": \"WIKKCdNWrddYbOtkOxHLfETps1cEBHsPhqGtQPxaLho\"\n}\n</code></pre></li> <li>Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>pXCqiUJ-A6Zlp6LAvkBWLOXPMuww5Hy_PljoODMsGTw</code></li> <li>Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"xdS1ON9UCKA3s7yOv55fvlegYR5GsLPbOZWi_zsFyEM\",\n  \"y\": \"yeE__UlC9wEIbnCPjoOZa-nD2CN0uHtau7edhcmJiOg\",\n  \"d\": \"Dry6DWrItSzhXS_ep5bvoWHkJEhKKJU-VTkFmNxZ7PI\"\n}\n</code></pre></li> <li>Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>4CB-2PhtYR9WfjsFNb4rmvSmJozJAL4gRCg_am3oDhw</code></li> <li>List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>4CB-2PhtYR9WfjsFNb4rmvSmJozJAL4gRCg_am3oDhw.D_kHovGtLUZ_ssw_vhZcqsx3LvQ6qC5JK74iPf9vqwk.pXCqiUJ-A6Zlp6LAvkBWLOXPMuww5Hy_PljoODMsGTw</code></li> <li>Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>vo7O9me-lVJv6Y_vjz-rL8eWaa0Xy1WHm2IOsR_UEpk</code></li> <li>Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwic2tpZCI6IjZQQlRVYmNMQjctWjRmdUFGbjQyb0MxUGFNc05tamhlcTFGZVpFVWdWXzgiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"NlBCVFViY0xCNy1aNGZ1QUZuNDJvQzFQYU1zTm1qaGVxMUZlWkVVZ1ZfOA\",\n        \"apv\": \"RF9rSG92R3RMVVpfc3N3X3ZoWmNxc3gzTHZRNnFDNUpLNzRpUGY5dnF3aw\",\n        \"kid\": \"D_kHovGtLUZ_ssw_vhZcqsx3LvQ6qC5JK74iPf9vqwk\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"Vpj5VtHxMt5Xz3vnKA727nTMmJd4zbVcPmKjSyHvLvc\",\n          \"y\": \"C7ZLlNCTduhf2qMXjrY907-OdMw_6ixC3UttKCVqgjk\"\n        }\n      },\n      \"encrypted_key\": \"lIm78Z0OmYR5Jc5D416xjb9K3rkmcOgaEFVut4WyNDueoTnM9B86Ug\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"NlBCVFViY0xCNy1aNGZ1QUZuNDJvQzFQYU1zTm1qaGVxMUZlWkVVZ1ZfOA\",\n        \"apv\": \"RF9rSG92R3RMVVpfc3N3X3ZoWmNxc3gzTHZRNnFDNUpLNzRpUGY5dnF3aw\",\n        \"kid\": \"pXCqiUJ-A6Zlp6LAvkBWLOXPMuww5Hy_PljoODMsGTw\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"wDD9G8UK-I246qp6-A1qBPr6N2yX6nTfYb9Zotf898o\",\n          \"y\": \"KIW0m4mOlWzwnW9y1R9314keHj5W8b7eqUs_dT3LBEw\"\n        }\n      },\n      \"encrypted_key\": \"BjZsq3DwuggMu1YhSZIX7NydPNSIBOfHWVBEZ9t5yDzlt1am_LI8cg\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"NlBCVFViY0xCNy1aNGZ1QUZuNDJvQzFQYU1zTm1qaGVxMUZlWkVVZ1ZfOA\",\n        \"apv\": \"RF9rSG92R3RMVVpfc3N3X3ZoWmNxc3gzTHZRNnFDNUpLNzRpUGY5dnF3aw\",\n        \"kid\": \"4CB-2PhtYR9WfjsFNb4rmvSmJozJAL4gRCg_am3oDhw\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"CHaH39lqKhUQLcrmbL_sVBmVZQaLlDxNGI1WkcCB7ss\",\n          \"y\": \"R36X6eJ2dwPz8T7eto0Uije3KLOGAwzLUVUKWj0SxHk\"\n        }\n      },\n      \"encrypted_key\": \"YnLT86bjwgz4SsKUUiG6bf0AybQywN8k2wHa_E3hGLP3Nwo23CyekQ\"\n    }\n  ],\n  \"aad\": \"vo7O9me-lVJv6Y_vjz-rL8eWaa0Xy1WHm2IOsR_UEpk\",\n  \"iv\": \"mwMiQc4m9LaoqnIC\",\n  \"ciphertext\": \"wQGUFlLz9fHpDoACWEQ\",\n  \"tag\": \"Ma9X6kppUNUp5SYH74zXDw\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#112-nist-p-384-keys","title":"1.1.2 NIST P-384 keys","text":"<p>The packer generates the following protected headers that includes the skid: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"A256GCM\",\"skid\":\"0Bz8yRwu9eC8Gi7cYOwAKMJ8jysInhAtwH8k8m9MX04\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwic2tpZCI6IjBCejh5Und1OWVDOEdpN2NZT3dBS01KOGp5c0luaEF0d0g4azhtOU1YMDQiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0</code> - Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"UW1LtMXuZdFS0gyp0_F19uxHqECvCcJA7SmeeuRSSc_PQfsbZWXt5L0KyLYpNIQb\",\n  \"y\": \"FBdPcUvanB7igwkX0NN5rOvH3OKZ1gQHhcad7cCy6QNYKKz7lBWUUOmzypee31pS\",\n  \"d\": \"wrXW0wsFKjvpTWqOAd1mohRublQs4P014-U4_K-eTRFmzhkyLJqNn91dH_AHUc4-\"\n}\n</code></pre> - Sender kid (jwk thumbprint raw base64 URL encoded): <code>0Bz8yRwu9eC8Gi7cYOwAKMJ8jysInhAtwH8k8m9MX04</code> - Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"k3W_RR59uUG3HFlhhqNNmBDyFdMtWHxKAsJaxLBqQgQer3d3aAN-lfdxzGnHtwj1\",\n  \"y\": \"VMSy5zxFEGaGRINailLTUH6NlP0JO2qu0j0_UbS7Ng1b8JkzHDnDbjGgsLqVJaMM\",\n  \"d\": \"iM5K8uqNvFYJnuToMDBguGwUIlu1erT-K0g7NYtJrQnHZOumS8yIC4MCNC60Ch91\"\n}\n</code></pre> - Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>obCHRLVDx634Cax_Kr3B8fd_-xj5kAj0r0Kvvvmq1z8</code> - Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"W3iUHCzh_PWzUKONKeHwIKcjWNN--c7OlL2H23lV13C9tlkqOleFUmioW-AeitEk\",\n  \"y\": \"CIzVD6KsuDLyKQPm0r62LPZikkT2kiXJpLjcVO3op2kgePQkZ31xniKE0VbUBnTH\",\n  \"d\": \"V_vQwOqHVCGxSjX_dN8H5VXvOGYDRTGI00mNXwB0I0mKDd8kqCJmNtGlf-eUrbub\"\n}\n</code></pre> - Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>PfuTIXG60dvOwnFOfMxJ0i59_L7vqNytROX_bLRR-3M</code> - Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"bsX8qtEtj5IDLp9iDUKlgdu_3nluupFtFBrfIK1nza1bGZQRlZ3JG3PdBzVAoePz\",\n  \"y\": \"QX_2v0BHloNS7iWoB4CcO9UWHdtirMVmbNcB8ZGczCJOfUyjYcQxGr0RU_tGkFC4\",\n  \"d\": \"rQ-4ZmWn09CsCqRQJhpQhDeUZXeZ3cy_Pei-fchVPFTa2FnAzvjwEF2Nsm2f3MmR\"\n}\n</code></pre> - Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>VTVlkyBsoW4ey0sh7TMJBErLGeBeKQsOttFRrXD6eqI</code> - List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>PfuTIXG60dvOwnFOfMxJ0i59_L7vqNytROX_bLRR-3M.VTVlkyBsoW4ey0sh7TMJBErLGeBeKQsOttFRrXD6eqI.obCHRLVDx634Cax_Kr3B8fd_-xj5kAj0r0Kvvvmq1z8</code> - Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>m72Q9j28hFk0imbFVzqY4KfTE77L8itJoX75N3hwiwA</code> - Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwic2tpZCI6IjBCejh5Und1OWVDOEdpN2NZT3dBS01KOGp5c0luaEF0d0g4azhtOU1YMDQiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"MEJ6OHlSd3U5ZUM4R2k3Y1lPd0FLTUo4anlzSW5oQXR3SDhrOG05TVgwNA\",\n        \"apv\": \"b2JDSFJMVkR4NjM0Q2F4X0tyM0I4ZmRfLXhqNWtBajByMEt2dnZtcTF6OA\",\n        \"kid\": \"obCHRLVDx634Cax_Kr3B8fd_-xj5kAj0r0Kvvvmq1z8\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"cjJHtV4VkMCww9ig94-_4e4yMfo2WI4Rh4dZh6NkYFvz-EGylA7RLSO5TRC-JJ_G\",\n          \"y\": \"RJe2QisAYpfuTWTV6KVeoLGshsJqYokbcSUqdMxrFGXSp4ZMNrW4yj410Xsn6hy6\"\n        }\n      },\n      \"encrypted_key\": \"o0ZZ_xNtmUPcpQAK3kzjOLp8xWBJ31tr-ORQjXtwpqgTuvM_nvhk_w\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"MEJ6OHlSd3U5ZUM4R2k3Y1lPd0FLTUo4anlzSW5oQXR3SDhrOG05TVgwNA\",\n        \"apv\": \"b2JDSFJMVkR4NjM0Q2F4X0tyM0I4ZmRfLXhqNWtBajByMEt2dnZtcTF6OA\",\n        \"kid\": \"PfuTIXG60dvOwnFOfMxJ0i59_L7vqNytROX_bLRR-3M\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"u1HYhdUJGx49J6wSLYM_JLHTkJrkR7wMSm5uYZMH7ZpcC3qF8MUyKTuKN0FGCBcN\",\n          \"y\": \"K-XI-KAGd2jHebNq44yQrDA6Ubs5M99mIlre0chzI13bSLDOuUG4RJ8yjYjXysWF\"\n        }\n      },\n      \"encrypted_key\": \"iCV1_peiRwnsrrBQWmp7GOd-taee-Yk8t6XqJCZPGziglDpGBu_ZhA\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"MEJ6OHlSd3U5ZUM4R2k3Y1lPd0FLTUo4anlzSW5oQXR3SDhrOG05TVgwNA\",\n        \"apv\": \"b2JDSFJMVkR4NjM0Q2F4X0tyM0I4ZmRfLXhqNWtBajByMEt2dnZtcTF6OA\",\n        \"kid\": \"VTVlkyBsoW4ey0sh7TMJBErLGeBeKQsOttFRrXD6eqI\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"Twps_QU6ShP18uQFNCcdOx9sU9YrHBznNnSbhQD474tLUcnslq5Trubq3ogp-LTX\",\n          \"y\": \"oSES1a5xve9e-lKQ3NMN5_CW9Sii9rTorqUMggDzodLsRGm0Jud3HAy2-uE956Xq\"\n        }\n      },\n      \"encrypted_key\": \"dLDKyXeZJDcB_i1Tnn_EUxqCc2ukneaummXF_FwcbpnMH8B0eVizvA\"\n    }\n  ],\n  \"aad\": \"m72Q9j28hFk0imbFVzqY4KfTE77L8itJoX75N3hwiwA\",\n  \"iv\": \"nuuuri2fyNl3jBo6\",\n  \"ciphertext\": \"DCWevJuEo5dx-MmqPvw\",\n  \"tag\": \"Pyt1S_Smg9Pnd1u_5Z7nbA\"\n}\n</code></pre></p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#113-nist-p-521-keys","title":"1.1.3 NIST P-521 keys","text":"<p>The packer generates the following protected headers that includes the skid: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"A256GCM\",\"skid\":\"oq-WBIGQm-iHiNRj6nId4-E1QtY8exzp8C56SziUfeU\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwic2tpZCI6Im9xLVdCSUdRbS1pSGlOUmo2bklkNC1FMVF0WThleHpwOEM1NlN6aVVmZVUiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0</code> - Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AXKDGPnD6hlQIre8aEeu33bQffkfl-eQfQXgzNXQX7XFYt5GKA1N6w4-f0_Ci7fQNKGkQuCoAu5-6CNk9M_cHiDi\",\n  \"y\": \"Ae4-APhoZAmM99MdY9io9IZA43dN7dA006wlFb6LJ9bcusJOi5R-o3o3FhCjt5KTv_JxYbo6KU4PsBwQ1eeKyJ0U\",\n  \"d\": \"AP9l2wmQ85P5XD84CkEQVWHaX_46EDvHxLWHEKsHFSQYjEh6BDSuyy1TUNv68v8kpbLCDjvsBc3cIBqC4_T1r4pU\"\n}\n</code></pre> - Sender kid (jwk thumbprint raw base64 URL encoded): <code>oq-WBIGQm-iHiNRj6nId4-E1QtY8exzp8C56SziUfeU</code> - Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"ALmUHkd9Gi2NApJojNzzA34Qdd1-KLnq6jd2UJ9wl-xJzTQ2leg8qi3-hrFs7NqNfxqO6vE5bBoWYFeAcf3LqJOU\",\n  \"y\": \"AN-MutmkAXGzlgzSQJRnctHDcjQQNpRek-8BeqyUDXdZKNGKSMEAzw6Hnl3VdvsvihQfrxcajpx5PSnwxbbdakHq\",\n  \"d\": \"AKv-YbKdI6y8NRMP-e17-RjZyRTfGf0Xh9Og5g7q7aq0xS2mO59ttIJ67XHW5SPTBQDbltdUcydKroWNUIGvhKNv\"\n}\n</code></pre> - Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>wax1T_hGUvM0NmlbFJi2RizQ_gWajumI5j0Hx7CbgAw</code> - Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"ALmUHkd9Gi2NApJojNzzA34Qdd1-KLnq6jd2UJ9wl-xJzTQ2leg8qi3-hrFs7NqNfxqO6vE5bBoWYFeAcf3LqJOU\",\n  \"y\": \"AN-MutmkAXGzlgzSQJRnctHDcjQQNpRek-8BeqyUDXdZKNGKSMEAzw6Hnl3VdvsvihQfrxcajpx5PSnwxbbdakHq\",\n  \"d\": \"AKv-YbKdI6y8NRMP-e17-RjZyRTfGf0Xh9Og5g7q7aq0xS2mO59ttIJ67XHW5SPTBQDbltdUcydKroWNUIGvhKNv\"\n}\n</code></pre> - Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>XmLVV-CqMkTGQIe6-KecWZWtZVwORTMP2y5aqMPV7P4</code> - Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AHCbpo-299Q0Fk71CtBoPu-40-Z0UOu4cGZfgtHHwcu3ciMWVR8IWF4bgvFpAPfKG8Dqx7JJWO8uEgLE67A7aQOL\",\n  \"y\": \"AQ_JBjS3lt8zz3njFhUoJwEdSJMyrSfGPCLpaWkKuRo25k3im-7IjY8T43gvzZXYwV3PKKR3iJ1jnQCrYmfRrmva\",\n  \"d\": \"ACgCw3U3eWTYD5vcygoOpoGPost9TojYJH9FllyRuqwlS3L8dkZu7vKhFyoEg6Bo8AqcOUj5Mtgxhd6Wu02YvqK3\"\n}\n</code></pre> - Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>pRJtTY7V1pClPu8WEgEZonzaHq3K0El9Vcb8qmjucSg</code> - List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>S8s7FFL7f0fUMXt93WOWC-3PJrV1iuAmB_ZlCDyjXqs.XmLVV-CqMkTGQIe6-KecWZWtZVwORTMP2y5aqMPV7P4.pRJtTY7V1pClPu8WEgEZonzaHq3K0El9Vcb8qmjucSg</code> - Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>tOS8nLSCERw2V9WOZVo6cenGuM4DJvHse1dsvTk8_As</code> - Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwic2tpZCI6Im9xLVdCSUdRbS1pSGlOUmo2bklkNC1FMVF0WThleHpwOEM1NlN6aVVmZVUiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"b3EtV0JJR1FtLWlIaU5SajZuSWQ0LUUxUXRZOGV4enA4QzU2U3ppVWZlVQ\",\n        \"apv\": \"WG1MVlYtQ3FNa1RHUUllNi1LZWNXWld0WlZ3T1JUTVAyeTVhcU1QVjdQNA\",\n        \"kid\": \"XmLVV-CqMkTGQIe6-KecWZWtZVwORTMP2y5aqMPV7P4\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"AP630J9yi2UFBfRWKucXB8eu9-SSKbbbD1fzFhLgbI3xTRTRNMGm-U5EGHbplMLsOfP2pNxtAgo2-d6abiZiD6gg\",\n          \"y\": \"AE1Grtp1iFvySLN4yHVvE0kYWChqVfkO_kHEMujjL6vVu_AAOvl3aogquLv1zgduitCPbKRTno89r3rv0L0Kuj0M\"\n        }\n      },\n      \"encrypted_key\": \"FSYpXFfgPlSfj91VFQ4zAs0Wb3CEpWcBcGeW4nld9szVfb_WRbqTtA\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"b3EtV0JJR1FtLWlIaU5SajZuSWQ0LUUxUXRZOGV4enA4QzU2U3ppVWZlVQ\",\n        \"apv\": \"WG1MVlYtQ3FNa1RHUUllNi1LZWNXWld0WlZ3T1JUTVAyeTVhcU1QVjdQNA\",\n        \"kid\": \"S8s7FFL7f0fUMXt93WOWC-3PJrV1iuAmB_ZlCDyjXqs\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"Acw0XM1IZl63ltysb-ivw8zBhZ-Wz54SaXM_vGGea8Sa5w6VWdZflp1tibzHkfu4novFFpNbKtnCKi-28AqQnOYZ\",\n          \"y\": \"AajoBj0KMrlaIA17RKnShFNzIb1S81oLYZu5MXzAg-XvT8_q83dXajOCiYJLo3taUvHTlcPjkHMG3_8442DgWpU_\"\n        }\n      },\n      \"encrypted_key\": \"3ct4awH6xyp9BjA74Q_j6ot6F32okEYXbS2e6NIkiAgs-JGyEPWoxw\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"b3EtV0JJR1FtLWlIaU5SajZuSWQ0LUUxUXRZOGV4enA4QzU2U3ppVWZlVQ\",\n        \"apv\": \"WG1MVlYtQ3FNa1RHUUllNi1LZWNXWld0WlZ3T1JUTVAyeTVhcU1QVjdQNA\",\n        \"kid\": \"pRJtTY7V1pClPu8WEgEZonzaHq3K0El9Vcb8qmjucSg\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"APu-ArpY-GUntHG7BzTvUauKVP_YpCcVnZFX6r_VvYY2iPbFSZYxvUdUbX3TGK-Q92rTHNaNnutjbPcrCaBpJecM\",\n          \"y\": \"AONhGq1vGU20Wdrx1FT5SBdLOIvqOK_pxhTJZhS0Vwi_JYQdKN6PHrX9GyJ23ZhaY3bBKX6V2uzRJzV8Qam1FUbz\"\n        }\n      },\n      \"encrypted_key\": \"U51txv9yfZASl8tlT7GbNtLjeAqTHUVT4O9MEqBKaYIdAcA7Qd7dnw\"\n    }\n  ],\n  \"aad\": \"tOS8nLSCERw2V9WOZVo6cenGuM4DJvHse1dsvTk8_As\",\n  \"iv\": \"LJl-9ygxPGMAmVHP\",\n  \"ciphertext\": \"HOfi-W7mcQv93scr1z8\",\n  \"tag\": \"zaM6OfzhVhYCsqD2VW5ztw\"\n}\n</code></pre></p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#114-x25519-keys","title":"1.1.4 X25519 keys","text":"<p>The packer generates the following protected headers that includes the skid: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"A256GCM\",\"skid\":\"X5INSMIv_w4Q7pljH7xjeUrRAKiBGHavSmOYyyiRugc\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwic2tpZCI6Ilg1SU5TTUl2X3c0UTdwbGpIN3hqZVVyUkFLaUJHSGF2U21PWXl5aVJ1Z2MiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0</code> - Sender key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"WKkktGWkUB9hDITcqa1Z6MC8rcWy8fWtxuT7xwQF1lw\",\n  \"d\": \"-LEcVt6bW_ah9gY7H_WknTsg1MXq8yc42SrSJhqP0Vo\"\n}\n</code></pre> - Sender kid (jwk thumbprint raw base64 URL encoded): <code>X5INSMIv_w4Q7pljH7xjeUrRAKiBGHavSmOYyyiRugc</code> - Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"NJzDtIa7vjz-isjaI-6GKGDe2EUx26-D44d6jLILeBI\",\n  \"d\": \"MEBNdr6Tpb0XfD60NeHby-Tkmlpgr7pvVe7Q__sBbGw\"\n}\n</code></pre> - Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>2UR-nzYjVhsq0cZakWjE38-wUdG0S2EIrLZ8Eh0KVO0</code> - Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"_aiA8rwrayc2k9EL-mkqtSh8onyl_-EzVif3L-q-R20\",\n  \"d\": \"ALBfdypF_lAbBtWXhwvq9Rs7TGjcLd-iuDh0s3yWr2Y\"\n}\n</code></pre> - Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>dvDd4h1rHj-onj-Xz9O1KRIgkMhh3u23d-94brHbBKo</code> - Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"zuHJfrIarLGFga0OwZqDlvlI5P1bb9DFhAtdnI54pwQ\",\n  \"d\": \"8BVFAqxPHXB5W-EBxr-EjdUmA4HqY1gwDjiYvt0UxUk\"\n}\n</code></pre> - Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>hj57wbrmOygTc_ktMPqKMHdiL85FdiGJa5DKzoLIzeU</code> - List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>2UR-nzYjVhsq0cZakWjE38-wUdG0S2EIrLZ8Eh0KVO0.dvDd4h1rHj-onj-Xz9O1KRIgkMhh3u23d-94brHbBKo.hj57wbrmOygTc_ktMPqKMHdiL85FdiGJa5DKzoLIzeU</code> - Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>L-QV1cHI5u8U9BQa8_S4CFW-LhKNXHCjmqydtQYuSLw</code> - Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJBMjU2R0NNIiwic2tpZCI6Ilg1SU5TTUl2X3c0UTdwbGpIN3hqZVVyUkFLaUJHSGF2U21PWXl5aVJ1Z2MiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"WDVJTlNNSXZfdzRRN3Bsakg3eGplVXJSQUtpQkdIYXZTbU9ZeXlpUnVnYw\",\n        \"apv\": \"MlVSLW56WWpWaHNxMGNaYWtXakUzOC13VWRHMFMyRUlyTFo4RWgwS1ZPMA\",\n        \"kid\": \"2UR-nzYjVhsq0cZakWjE38-wUdG0S2EIrLZ8Eh0KVO0\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"IcuAA7zPN0mLt4GSZLQJ6f8p3yPALQaSyupbSRpDnwA\"\n        }\n      },\n      \"encrypted_key\": \"_GoKcbrlbPR8hdgpDdpotO4WvAKOzyOEXo5A2RlxVaEb0enFej2DFQ\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"WDVJTlNNSXZfdzRRN3Bsakg3eGplVXJSQUtpQkdIYXZTbU9ZeXlpUnVnYw\",\n        \"apv\": \"MlVSLW56WWpWaHNxMGNaYWtXakUzOC13VWRHMFMyRUlyTFo4RWgwS1ZPMA\",\n        \"kid\": \"dvDd4h1rHj-onj-Xz9O1KRIgkMhh3u23d-94brHbBKo\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"_BVh0oInkDiqnTkHKLvNMa8cldr79TZS00MJCYwZo3Y\"\n        }\n      },\n      \"encrypted_key\": \"gacTLNP-U5mYAHJLG9F97R52aG244NfLeWg_Dj4Fy0C96oIIN-3psw\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+A256KW\",\n        \"apu\": \"WDVJTlNNSXZfdzRRN3Bsakg3eGplVXJSQUtpQkdIYXZTbU9ZeXlpUnVnYw\",\n        \"apv\": \"MlVSLW56WWpWaHNxMGNaYWtXakUzOC13VWRHMFMyRUlyTFo4RWgwS1ZPMA\",\n        \"kid\": \"hj57wbrmOygTc_ktMPqKMHdiL85FdiGJa5DKzoLIzeU\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"alPo4cjEjondCmz8mw8tntYxlpGPSLaqe3SSI_wu11s\"\n        }\n      },\n      \"encrypted_key\": \"q2RpqrdZA9mvVBGTvMNHg3P6SysnuCpfraLWhRseiQ1ImJWdLq53TA\"\n    }\n  ],\n  \"aad\": \"L-QV1cHI5u8U9BQa8_S4CFW-LhKNXHCjmqydtQYuSLw\",\n  \"iv\": \"J-OEJGFWvJ6rw9dX\",\n  \"ciphertext\": \"BvFi1vAzq0Uostj0_ms\",\n  \"tag\": \"C6itmqZ7ehMx9FF70fdGGQ\"\n}\n</code></pre></p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#12-single-recipient-jwes","title":"1.2 Single Recipient JWEs","text":"<p>Packing a message with 1 recipient using the Flattened JWE JSON serialization and Compact JWE serialization formats as mentioned in the notes above.</p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#121-nist-p-256-key","title":"1.2.1 NIST P-256 key","text":"<ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"eFRTD4VaryfwIqLOpq7iuXmBbLjKPq5sVNzxwL7H1CI\",\n  \"y\": \"cIeogn-pLJXlCepb9BqwNKKW4tmNea3Is8G47aPob6M\",\n  \"d\": \"11NyNGrw4JoU7-_bwoZlVDTJi5vkMrSs4Nme_OHnx6Q\"\n}\n</code></pre></li> <li>Sender kid (jwk thumbprint raw base64 URL encoded): <code>6PBTUbcLB7-Z4fuAFn42oC1PaMsNmjheq1FeZEUgV_8</code></li> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"UP08dxIWu14HWRCI48Tnohm7jhaJ87fFdvYyf0w4lkg\",\n  \"y\": \"ohZVfvhQViMGb_n-Y66TewBO2gtE_udG_DsNe8c-T8w\",\n  \"d\": \"O0ikvlb4fh7daJpqd9JIgYk5e-twB0IYyKpoqmb7ZCc\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>D_kHovGtLUZ_ssw_vhZcqsx3LvQ6qC5JK74iPf9vqwk</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILTFQVStBMjU2S1ciLCJhcHUiOiJObEJDVkZWaVkweENOeTFhTkdaMVFVWnVOREp2UXpGUVlVMXpUbTFxYUdWeE1VWmxXa1ZWWjFaZk9BIiwiYXB2IjoiUkY5clNHOTJSM1JNVlZwZmMzTjNYM1pvV21OeGMzZ3pUSFpSTm5GRE5VcExOelJwVUdZNWRuRjNhdyIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsiY3J2IjoiUC0yNTYiLCJrdHkiOiJFQyIsIngiOiJzODRGczRGeWRfSEVFQUN2R3dHak0wWDdGYUNwTlZ5cS1tM19MYXVwT2gwIiwieSI6IndsZzZoQnVnZElWMFlaekh1NHNQRnM0OXRtMGtXQlZjenQ0N25IenZ5UU0ifSwia2lkIjoiRF9rSG92R3RMVVpfc3N3X3ZoWmNxc3gzTHZRNnFDNUpLNzRpUGY5dnF3ayIsInNraWQiOiI2UEJUVWJjTEI3LVo0ZnVBRm40Mm9DMVBhTXNObWpoZXExRmVaRVVnVl84IiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"encrypted_key\": \"0L4GrPjXIy31JcEjV3sQj1Fbtb-dAtFPLng6mB0jyEyzDxzWcZZWag\",\n  \"iv\": \"V26sXdaKTIo6SDMn\",\n  \"ciphertext\": \"TJcEzgDbw5xDOMOwuuE\",\n  \"tag\": \"vgtkaTIM407IG8ZqLLRk6Q\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILTFQVStBMjU2S1ciLCJhcHUiOiJObEJDVkZWaVkweENOeTFhTkdaMVFVWnVOREp2UXpGUVlVMXpUbTFxYUdWeE1VWmxXa1ZWWjFaZk9BIiwiYXB2IjoiUkY5clNHOTJSM1JNVlZwZmMzTjNYM1pvV21OeGMzZ3pUSFpSTm5GRE5VcExOelJwVUdZNWRuRjNhdyIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsia3R5IjoiRUMiLCJjcnYiOiJQLTI1NiIsIngiOiJzODRGczRGeWRfSEVFQUN2R3dHak0wWDdGYUNwTlZ5cS1tM19MYXVwT2gwIiwieSI6IndsZzZoQnVnZElWMFlaekh1NHNQRnM0OXRtMGtXQlZjenQ0N25IenZ5UU0ifSwia2lkIjoiRF9rSG92R3RMVVpfc3N3X3ZoWmNxc3gzTHZRNnFDNUpLNzRpUGY5dnF3ayIsInNraWQiOiI2UEJUVWJjTEI3LVo0ZnVBRm40Mm9DMVBhTXNObWpoZXExRmVaRVVnVl84IiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9.0L4GrPjXIy31JcEjV3sQj1Fbtb-dAtFPLng6mB0jyEyzDxzWcZZWag.V26sXdaKTIo6SDMn.TJcEzgDbw5xDOMOwuuE.vgtkaTIM407IG8ZqLLRk6Q</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-1PU+A256KW\",\n  \"apu\": \"NlBCVFViY0xCNy1aNGZ1QUZuNDJvQzFQYU1zTm1qaGVxMUZlWkVVZ1ZfOA\",\n  \"apv\": \"RF9rSG92R3RMVVpfc3N3X3ZoWmNxc3gzTHZRNnFDNUpLNzRpUGY5dnF3aw\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"A256GCM\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-256\",\n    \"x\": \"s84Fs4Fyd_HEEACvGwGjM0X7FaCpNVyq-m3_LaupOh0\",\n    \"y\": \"wlg6hBugdIV0YZzHu4sPFs49tm0kWBVczt47nHzvyQM\"\n  },\n  \"kid\": \"D_kHovGtLUZ_ssw_vhZcqsx3LvQ6qC5JK74iPf9vqwk\",\n  \"skid\": \"6PBTUbcLB7-Z4fuAFn42oC1PaMsNmjheq1FeZEUgV_8\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#122-nist-p-384-key","title":"1.2.2 NIST P-384 key","text":"<ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"UW1LtMXuZdFS0gyp0_F19uxHqECvCcJA7SmeeuRSSc_PQfsbZWXt5L0KyLYpNIQb\",\n  \"y\": \"FBdPcUvanB7igwkX0NN5rOvH3OKZ1gQHhcad7cCy6QNYKKz7lBWUUOmzypee31pS\",\n  \"d\": \"wrXW0wsFKjvpTWqOAd1mohRublQs4P014-U4_K-eTRFmzhkyLJqNn91dH_AHUc4-\"\n}\n</code></pre></li> <li>Sender kid (jwk thumbprint raw base64 URL encoded): <code>0Bz8yRwu9eC8Gi7cYOwAKMJ8jysInhAtwH8k8m9MX04</code></li> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"k3W_RR59uUG3HFlhhqNNmBDyFdMtWHxKAsJaxLBqQgQer3d3aAN-lfdxzGnHtwj1\",\n  \"y\": \"VMSy5zxFEGaGRINailLTUH6NlP0JO2qu0j0_UbS7Ng1b8JkzHDnDbjGgsLqVJaMM\",\n  \"d\": \"iM5K8uqNvFYJnuToMDBguGwUIlu1erT-K0g7NYtJrQnHZOumS8yIC4MCNC60Ch91\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>obCHRLVDx634Cax_Kr3B8fd_-xj5kAj0r0Kvvvmq1z8</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILTFQVStBMjU2S1ciLCJhcHUiOiJNRUo2T0hsU2QzVTVaVU00UjJrM1kxbFBkMEZMVFVvNGFubHpTVzVvUVhSM1NEaHJPRzA1VFZnd05BIiwiYXB2IjoiYjJKRFNGSk1Wa1I0TmpNMFEyRjRYMHR5TTBJNFptUmZMWGhxTld0QmFqQnlNRXQyZG5adGNURjZPQSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsiY3J2IjoiUC0zODQiLCJrdHkiOiJFQyIsIngiOiJvZ1dJTHo4aXpDODNWNnFPNFVidHlSMTFadGdtRUMxQV9VM1JtVVV4dk9INE9lVW9xbUxXX295YjJXek5NTTZtIiwieSI6ImNobkphdHpRREJodzhqem5McUFmYWx3eFB3RmFKZjhVY2FzbjlmUWZyeUVWQ2FnRnRBYTNIb1FaSUxoeGxYSWUifSwia2lkIjoib2JDSFJMVkR4NjM0Q2F4X0tyM0I4ZmRfLXhqNWtBajByMEt2dnZtcTF6OCIsInNraWQiOiIwQno4eVJ3dTllQzhHaTdjWU93QUtNSjhqeXNJbmhBdHdIOGs4bTlNWDA0IiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"encrypted_key\": \"ojdzwycN1XFKuiwOmlgS4MHApmDAVKVZt1Zl7sgtJkafQRz81FUnZQ\",\n  \"iv\": \"VqEJ6p5J0ZTIw2ts\",\n  \"ciphertext\": \"jGznTL6ruVMXzV8xCA8\",\n  \"tag\": \"YA_A4pjqqaAeUNvEFnCx8Q\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILTFQVStBMjU2S1ciLCJhcHUiOiJNRUo2T0hsU2QzVTVaVU00UjJrM1kxbFBkMEZMVFVvNGFubHpTVzVvUVhSM1NEaHJPRzA1VFZnd05BIiwiYXB2IjoiYjJKRFNGSk1Wa1I0TmpNMFEyRjRYMHR5TTBJNFptUmZMWGhxTld0QmFqQnlNRXQyZG5adGNURjZPQSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsIngiOiJvZ1dJTHo4aXpDODNWNnFPNFVidHlSMTFadGdtRUMxQV9VM1JtVVV4dk9INE9lVW9xbUxXX295YjJXek5NTTZtIiwieSI6ImNobkphdHpRREJodzhqem5McUFmYWx3eFB3RmFKZjhVY2FzbjlmUWZyeUVWQ2FnRnRBYTNIb1FaSUxoeGxYSWUifSwia2lkIjoib2JDSFJMVkR4NjM0Q2F4X0tyM0I4ZmRfLXhqNWtBajByMEt2dnZtcTF6OCIsInNraWQiOiIwQno4eVJ3dTllQzhHaTdjWU93QUtNSjhqeXNJbmhBdHdIOGs4bTlNWDA0IiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9.ojdzwycN1XFKuiwOmlgS4MHApmDAVKVZt1Zl7sgtJkafQRz81FUnZQ.VqEJ6p5J0ZTIw2ts.jGznTL6ruVMXzV8xCA8.YA_A4pjqqaAeUNvEFnCx8Q</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-1PU+A256KW\",\n  \"apu\": \"MEJ6OHlSd3U5ZUM4R2k3Y1lPd0FLTUo4anlzSW5oQXR3SDhrOG05TVgwNA\",\n  \"apv\": \"b2JDSFJMVkR4NjM0Q2F4X0tyM0I4ZmRfLXhqNWtBajByMEt2dnZtcTF6OA\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"A256GCM\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-384\",\n    \"x\": \"ogWILz8izC83V6qO4UbtyR11ZtgmEC1A_U3RmUUxvOH4OeUoqmLW_oyb2WzNMM6m\",\n    \"y\": \"chnJatzQDBhw8jznLqAfalwxPwFaJf8Ucasn9fQfryEVCagFtAa3HoQZILhxlXIe\"\n  },\n  \"kid\": \"obCHRLVDx634Cax_Kr3B8fd_-xj5kAj0r0Kvvvmq1z8\",\n  \"skid\": \"0Bz8yRwu9eC8Gi7cYOwAKMJ8jysInhAtwH8k8m9MX04\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#123-nist-p-521-key","title":"1.2.3 NIST P-521 key","text":"<ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AXKDGPnD6hlQIre8aEeu33bQffkfl-eQfQXgzNXQX7XFYt5GKA1N6w4-f0_Ci7fQNKGkQuCoAu5-6CNk9M_cHiDi\",\n  \"y\": \"Ae4-APhoZAmM99MdY9io9IZA43dN7dA006wlFb6LJ9bcusJOi5R-o3o3FhCjt5KTv_JxYbo6KU4PsBwQ1eeKyJ0U\",\n  \"d\": \"AP9l2wmQ85P5XD84CkEQVWHaX_46EDvHxLWHEKsHFSQYjEh6BDSuyy1TUNv68v8kpbLCDjvsBc3cIBqC4_T1r4pU\"\n}\n</code></pre></li> <li>Sender kid (jwk thumbprint raw base64 URL encoded): <code>oq-WBIGQm-iHiNRj6nId4-E1QtY8exzp8C56SziUfeU</code></li> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"ALmUHkd9Gi2NApJojNzzA34Qdd1-KLnq6jd2UJ9wl-xJzTQ2leg8qi3-hrFs7NqNfxqO6vE5bBoWYFeAcf3LqJOU\",\n  \"y\": \"AN-MutmkAXGzlgzSQJRnctHDcjQQNpRek-8BeqyUDXdZKNGKSMEAzw6Hnl3VdvsvihQfrxcajpx5PSnwxbbdakHq\",\n  \"d\": \"AKv-YbKdI6y8NRMP-e17-RjZyRTfGf0Xh9Og5g7q7aq0xS2mO59ttIJ67XHW5SPTBQDbltdUcydKroWNUIGvhKNv\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>XmLVV-CqMkTGQIe6-KecWZWtZVwORTMP2y5aqMPV7P4</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILTFQVStBMjU2S1ciLCJhcHUiOiJiM0V0VjBKSlIxRnRMV2xJYVU1U2FqWnVTV1EwTFVVeFVYUlpPR1Y0ZW5BNFF6VTJVM3BwVldabFZRIiwiYXB2IjoiV0cxTVZsWXRRM0ZOYTFSSFVVbGxOaTFMWldOWFdsZDBXbFozVDFKVVRWQXllVFZoY1UxUVZqZFFOQSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsiY3J2IjoiUC01MjEiLCJrdHkiOiJFQyIsIngiOiJBRHdFcDBlZWJseGZhZHdkVFBlTV81b29MZGdHaWhLM3Bqd3AxakxXWmdxLUJrRV9IZDhnZFQ4RThOSFVvWjRFeWVvbWVKX3J0WGFlVnlHdjdoVzBPb1MtIiwieSI6IkFaY0Zzemg3RUstZ2lGQXRIZ2hPQ21uR3NNN1QzSzFjeUhBV0NwYXBqd2ZEclJjYnE5THdhQjFyRVVOdDMyYndLdWNNNG9idldkSndxVGE3SGVZYlNVOHUifSwia2lkIjoiWG1MVlYtQ3FNa1RHUUllNi1LZWNXWld0WlZ3T1JUTVAyeTVhcU1QVjdQNCIsInNraWQiOiJvcS1XQklHUW0taUhpTlJqNm5JZDQtRTFRdFk4ZXh6cDhDNTZTemlVZmVVIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"encrypted_key\": \"9OyKH83g7RoS-ykrAoQpqn6FUUuYxeKukJbk6y2x9wfoe__rM8sP4w\",\n  \"iv\": \"JO2ENu2k2O1OFgjl\",\n  \"ciphertext\": \"wpomqxgGqQIWQ_lWCm4\",\n  \"tag\": \"XgUX1EOGAePvjlcO7Dzb3A\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILTFQVStBMjU2S1ciLCJhcHUiOiJiM0V0VjBKSlIxRnRMV2xJYVU1U2FqWnVTV1EwTFVVeFVYUlpPR1Y0ZW5BNFF6VTJVM3BwVldabFZRIiwiYXB2IjoiV0cxTVZsWXRRM0ZOYTFSSFVVbGxOaTFMWldOWFdsZDBXbFozVDFKVVRWQXllVFZoY1UxUVZqZFFOQSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsia3R5IjoiRUMiLCJjcnYiOiJQLTUyMSIsIngiOiJBRHdFcDBlZWJseGZhZHdkVFBlTV81b29MZGdHaWhLM3Bqd3AxakxXWmdxLUJrRV9IZDhnZFQ4RThOSFVvWjRFeWVvbWVKX3J0WGFlVnlHdjdoVzBPb1MtIiwieSI6IkFaY0Zzemg3RUstZ2lGQXRIZ2hPQ21uR3NNN1QzSzFjeUhBV0NwYXBqd2ZEclJjYnE5THdhQjFyRVVOdDMyYndLdWNNNG9idldkSndxVGE3SGVZYlNVOHUifSwia2lkIjoiWG1MVlYtQ3FNa1RHUUllNi1LZWNXWld0WlZ3T1JUTVAyeTVhcU1QVjdQNCIsInNraWQiOiJvcS1XQklHUW0taUhpTlJqNm5JZDQtRTFRdFk4ZXh6cDhDNTZTemlVZmVVIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9.9OyKH83g7RoS-ykrAoQpqn6FUUuYxeKukJbk6y2x9wfoe__rM8sP4w.JO2ENu2k2O1OFgjl.wpomqxgGqQIWQ_lWCm4.XgUX1EOGAePvjlcO7Dzb3A</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-1PU+A256KW\",\n  \"apu\": \"b3EtV0JJR1FtLWlIaU5SajZuSWQ0LUUxUXRZOGV4enA4QzU2U3ppVWZlVQ\",\n  \"apv\": \"WG1MVlYtQ3FNa1RHUUllNi1LZWNXWld0WlZ3T1JUTVAyeTVhcU1QVjdQNA\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"A256GCM\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-521\",\n    \"x\": \"ADwEp0eeblxfadwdTPeM_5ooLdgGihK3pjwp1jLWZgq-BkE_Hd8gdT8E8NHUoZ4EyeomeJ_rtXaeVyGv7hW0OoS-\",\n    \"y\": \"AZcFszh7EK-giFAtHghOCmnGsM7T3K1cyHAWCpapjwfDrRcbq9LwaB1rEUNt32bwKucM4obvWdJwqTa7HeYbSU8u\"\n  },\n  \"kid\": \"XmLVV-CqMkTGQIe6-KecWZWtZVwORTMP2y5aqMPV7P4\",\n  \"skid\": \"oq-WBIGQm-iHiNRj6nId4-E1QtY8exzp8C56SziUfeU\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#124-x25519-key","title":"1.2.4 X25519 key","text":"<ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"WKkktGWkUB9hDITcqa1Z6MC8rcWy8fWtxuT7xwQF1lw\",\n  \"d\": \"-LEcVt6bW_ah9gY7H_WknTsg1MXq8yc42SrSJhqP0Vo\"\n}\n</code></pre></li> <li>Sender kid (jwk thumbprint raw base64 URL encoded): <code>X5INSMIv_w4Q7pljH7xjeUrRAKiBGHavSmOYyyiRugc</code></li> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"NJzDtIa7vjz-isjaI-6GKGDe2EUx26-D44d6jLILeBI\",\n  \"d\": \"MEBNdr6Tpb0XfD60NeHby-Tkmlpgr7pvVe7Q__sBbGw\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>2UR-nzYjVhsq0cZakWjE38-wUdG0S2EIrLZ8Eh0KVO0</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILTFQVStBMjU2S1ciLCJhcHUiOiJXRFZKVGxOTlNYWmZkelJSTjNCc2FrZzNlR3BsVlhKU1FVdHBRa2RJWVhaVGJVOVplWGxwVW5Wbll3IiwiYXB2IjoiTWxWU0xXNTZXV3BXYUhOeE1HTmFZV3RYYWtVek9DMTNWV1JITUZNeVJVbHlURm80Uldnd1MxWlBNQSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsiY3J2IjoiWDI1NTE5Iiwia3R5IjoiT0tQIiwieCI6InpxUDB0WHdqVVFxdnBvSVdqNS16U2Q0WVVZZjdmU2hta2dhR0dXRFFrbGsifSwia2lkIjoiMlVSLW56WWpWaHNxMGNaYWtXakUzOC13VWRHMFMyRUlyTFo4RWgwS1ZPMCIsInNraWQiOiJYNUlOU01Jdl93NFE3cGxqSDd4amVVclJBS2lCR0hhdlNtT1l5eWlSdWdjIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"encrypted_key\": \"o_tprm3F-VJE2kHFrCBtgbCVDag0Y6AwLm1jD6S3MUS_rHphYy033w\",\n  \"iv\": \"6GKRpv-Bs_2v_7a3\",\n  \"ciphertext\": \"qlfWYkCE7zu-aRVP3R8\",\n  \"tag\": \"oBDt6-tRYcLTMA7QhX0O2Q\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILTFQVStBMjU2S1ciLCJhcHUiOiJXRFZKVGxOTlNYWmZkelJSTjNCc2FrZzNlR3BsVlhKU1FVdHBRa2RJWVhaVGJVOVplWGxwVW5Wbll3IiwiYXB2IjoiTWxWU0xXNTZXV3BXYUhOeE1HTmFZV3RYYWtVek9DMTNWV1JITUZNeVJVbHlURm80Uldnd1MxWlBNQSIsImN0eSI6ImFwcGxpY2F0aW9uL2RpZGNvbW0tcGxhaW4ranNvbiIsImVuYyI6IkEyNTZHQ00iLCJlcGsiOnsia3R5IjoiT0tQIiwiY3J2IjoiWDI1NTE5IiwieCI6InpxUDB0WHdqVVFxdnBvSVdqNS16U2Q0WVVZZjdmU2hta2dhR0dXRFFrbGsifSwia2lkIjoiMlVSLW56WWpWaHNxMGNaYWtXakUzOC13VWRHMFMyRUlyTFo4RWgwS1ZPMCIsInNraWQiOiJYNUlOU01Jdl93NFE3cGxqSDd4amVVclJBS2lCR0hhdlNtT1l5eWlSdWdjIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9.o_tprm3F-VJE2kHFrCBtgbCVDag0Y6AwLm1jD6S3MUS_rHphYy033w.6GKRpv-Bs_2v_7a3.qlfWYkCE7zu-aRVP3R8.oBDt6-tRYcLTMA7QhX0O2Q</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to: <pre><code>{\n  \"alg\": \"ECDH-1PU+A256KW\",\n  \"apu\": \"WDVJTlNNSXZfdzRRN3Bsakg3eGplVXJSQUtpQkdIYXZTbU9ZeXlpUnVnYw\",\n  \"apv\": \"MlVSLW56WWpWaHNxMGNaYWtXakUzOC13VWRHMFMyRUlyTFo4RWgwS1ZPMA\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"A256GCM\",\n  \"epk\": {\n    \"kty\": \"OKP\",\n    \"crv\": \"X25519\",\n    \"x\": \"zqP0tXwjUQqvpoIWj5-zSd4YUYf7fShmkgaGGWDQklk\"\n  },\n  \"kid\": \"2UR-nzYjVhsq0cZakWjE38-wUdG0S2EIrLZ8Eh0KVO0\",\n  \"skid\": \"X5INSMIv_w4Q7pljH7xjeUrRAKiBGHavSmOYyyiRugc\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#2-xc20p-content-encryption","title":"2 XC20P content encryption","text":""},{"location":"features/0334-jwe-envelope/authcrypt-examples/#21-multi-recipients-jwes","title":"2.1 Multi recipients JWEs","text":""},{"location":"features/0334-jwe-envelope/authcrypt-examples/#211-nist-p-256-keys","title":"2.1.1 NIST P-256 keys","text":"<p>The packer generates the following protected headers that includes the skid: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"XC20P\",\"skid\":\"T1jGtZoU-Xa_5a1QKexUU0Jq9WKDtS7TCowVvjoFH04\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInNraWQiOiJUMWpHdFpvVS1YYV81YTFRS2V4VVUwSnE5V0tEdFM3VENvd1Z2am9GSDA0IiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9</code> - Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"46OXm1dUTO3MB-8zoxbn-9dk0khgeIqsKFO-nTJ9keM\",\n  \"y\": \"8IlrwB-dl5bFd5RT4YAbgAdj5Y-a9zhc9wCMnXDZDvA\",\n  \"d\": \"58GZDz9_opy-nEeaJ_cyEL63TO-l063aV5nLADCgsGY\"\n}\n</code></pre> - Sender kid (jwk thumbprint raw base64 URL encoded): <code>T1jGtZoU-Xa_5a1QKexUU0Jq9WKDtS7TCowVvjoFH04</code> - Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"r9MRjEQ7CBxAgMyEG3ZjIlkGCuRX0rTaBdbkAcY17hA\",\n  \"y\": \"MRSgHQycDFPdSABGv5V0Qd-2q7ebs_x0_fNFyabGgXU\",\n  \"d\": \"LK9yfSxuET5n5uZDNO-64sJKWxJs7LTkqhA4mAuKQnE\"\n}\n</code></pre> - Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>dmfXisqWjRT-tFpODOD-G0CBF6zjHywNUjrrD3IFmcs</code> - Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"PMhlaU_KNEWou004AEyAFoJi8vNOnY75ROiRzzjhDR0\",\n  \"y\": \"tEcJNRv2rqYlYWeRloRabcp2lRorRaZTLM0ZNBoEyN0\",\n  \"d\": \"t1-QysBdkbkpqEBDo_JPsi-6YqD24UoAGBrruI2XNhA\"\n}\n</code></pre> - Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>2_Sf_YshIFhQ11NH9muAxLWwyFUvJnfXbYFOAC-8HTw</code> - Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"V9dWH69KZ_bvrxdWgt5-o-KnZLcGuWjAKVWMueiQioM\",\n  \"y\": \"lvsUBieuXV6qL4R3L94fCJGu8SDifqh3fAtN2plPWX4\",\n  \"d\": \"llg97kts4YxIF-r3jn7wcZ-zV0hLcn_AydIKHDF-HJc\"\n}\n</code></pre> - Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>mKtrI7SV3z2U9XyhaaTYlQFX1ANi6Wkli8b3NWVq4C4</code> - List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>2_Sf_YshIFhQ11NH9muAxLWwyFUvJnfXbYFOAC-8HTw.dmfXisqWjRT-tFpODOD-G0CBF6zjHywNUjrrD3IFmcs.mKtrI7SV3z2U9XyhaaTYlQFX1ANi6Wkli8b3NWVq4C4</code> - Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>PNKzNc6e0MtDtIGamjsx2fytSu6t8GygofQbzTrtMNA</code> - Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInNraWQiOiJUMWpHdFpvVS1YYV81YTFRS2V4VVUwSnE5V0tEdFM3VENvd1Z2am9GSDA0IiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"VDFqR3Rab1UtWGFfNWExUUtleFVVMEpxOVdLRHRTN1RDb3dWdmpvRkgwNA\",\n        \"apv\": \"ZG1mWGlzcVdqUlQtdEZwT0RPRC1HMENCRjZ6akh5d05VanJyRDNJRm1jcw\",\n        \"kid\": \"dmfXisqWjRT-tFpODOD-G0CBF6zjHywNUjrrD3IFmcs\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"80NGcUh0mIy_XrcaAqD7GCHF0FU2W5j4Jt-wfwxvJVs\",\n          \"y\": \"KpsNL9A-FGgL7S97ce8wcWYc9J1Q6_luxKAFIu7BNIw\"\n        }\n      },\n      \"encrypted_key\": \"wGQO8LX7o9JmYI0PIGUruU7i6ybZYefsTanZuo7hIDyn21ix6fSFPOmvgjPxZ8q_-hZF2yGYtudfLiuPzXlybWJkmTlP9PcY\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"VDFqR3Rab1UtWGFfNWExUUtleFVVMEpxOVdLRHRTN1RDb3dWdmpvRkgwNA\",\n        \"apv\": \"ZG1mWGlzcVdqUlQtdEZwT0RPRC1HMENCRjZ6akh5d05VanJyRDNJRm1jcw\",\n        \"kid\": \"2_Sf_YshIFhQ11NH9muAxLWwyFUvJnfXbYFOAC-8HTw\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"4YrbAQCLLya1XqRvjfcYdonllWQulrLP7zE0ooclKXA\",\n          \"y\": \"B3tI8lsWHRwBQ19pAFzXiBkLgpE6leTeQT6b709gllE\"\n        }\n      },\n      \"encrypted_key\": \"5tY3t1JI8L6s974kmXbzKMaePHygNan2Qqpd1B0BiqBsjaHNUH2Unv1IMGiT3oQD0xXeVPAxQq7vNZgANitxBbgG_uxGiRld\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"VDFqR3Rab1UtWGFfNWExUUtleFVVMEpxOVdLRHRTN1RDb3dWdmpvRkgwNA\",\n        \"apv\": \"ZG1mWGlzcVdqUlQtdEZwT0RPRC1HMENCRjZ6akh5d05VanJyRDNJRm1jcw\",\n        \"kid\": \"mKtrI7SV3z2U9XyhaaTYlQFX1ANi6Wkli8b3NWVq4C4\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-256\",\n          \"x\": \"-e9kPGp2rmtpFs2zzTaY6xfeXjr1Xua1vHCQZRKJ54s\",\n          \"y\": \"Mc7b8U06KHV__1-XMaReilLxa63LcICqsPtkZGXEkEs\"\n        }\n      },\n      \"encrypted_key\": \"zVQUQytYv4EmQS0zye3IsXiN_2ol-Qn2nvyaJgEPvNdwFuzTFPOupTl-PeOhkRvxPfuLlw5TKnSRyPUejP8zyHbBgUZ6gDmz\"\n    }\n  ],\n  \"aad\": \"PNKzNc6e0MtDtIGamjsx2fytSu6t8GygofQbzTrtMNA\",\n  \"iv\": \"UKgm1XTPf1QFDXoRWlf-KrsBRQKSwpBA\",\n  \"ciphertext\": \"pbwy8HEnr1hPA0Jt5ho\",\n  \"tag\": \"nUazXvxpMXGoL1__92CAyA\"\n}\n</code></pre></p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#212-nist-p-384-keys","title":"2.1.2 NIST P-384 keys","text":"<p>The packer generates the following protected headers that includes the skid: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"XC20P\",\"skid\":\"xXdnS3M4Bb497A0ko9c6H0D4NNbj1XpwGr4Tk9Fcw7k\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInNraWQiOiJ4WGRuUzNNNEJiNDk3QTBrbzljNkgwRDROTmJqMVhwd0dyNFRrOUZjdzdrIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9</code> - Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"bfuATmVQ_jxLIgfuhKNYrNRNu-VnK4FzTCCVRvycgekS8fIuC4rZS9uQi6Q2Ujwd\",\n  \"y\": \"XkVJ93cLKpeZeCMEOsHRKk4rse1zXpzY6yUibEtwZG9nFWF05Ro8OQs5fZVK2TWC\",\n  \"d\": \"OVzGxGyyaHGJpx1MoSwPjmWPas28sfq1tj7UkYFoK3ENsujmzUduAW6HwyaBlXRW\"\n}\n</code></pre> - Sender kid (jwk thumbprint raw base64 URL encoded): <code>xXdnS3M4Bb497A0ko9c6H0D4NNbj1XpwGr4Tk9Fcw7k</code> - Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"xhk5K7x4xw9OJpkFhmsY39jceQqx57psvcZstiNZmKbXD7kT9ajfGKFA6YA-ali5\",\n  \"y\": \"7Hj32-JDMNDYWRGy3f-0E9lbUGp6yURMaZ9M36Q_FPgljKgHa9i0Fn1ogr_zEmO3\",\n  \"d\": \"Pc3r6eg15XZeKgTDMPcGjf_SvImZxG4bDzgCh3QShClAwMdmoNbzPZGhBByNrlvO\"\n}\n</code></pre> - Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>aIlhDTWJmT-_Atad5EBbvbZPkPnz2IYT85I6T44kcE4</code> - Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"wqW3DUkUAT0Cyk3hq0KVJbqtPSJOoqulp_Tqa29jBEPliIJ9rnq7cRkJyxArCYAj\",\n  \"y\": \"ZfBtdTTVRh9SeQDCwsgAo15cCX2I-7J6xdyxDPyH8LBhbUA_8npHvNquKGta9p8x\",\n  \"d\": \"krddjYsOD4YIIkNjWXTrYV9rOVlmLNaeoLHChJ5oUr4c21LHxGL4xTI1bEoXKgJ2\"\n}\n</code></pre> - Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>02WdA5ip_Amam611KA6fdoTs533yZH-ovfpt8t9zVjg</code> - Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"If6iEafrkcL53mVYCbm5rmnwAw3kjb13gUjBoDePggO7xMiSFyej4wbTabdCyfbg\",\n  \"y\": \"nLX6lEce-9r19NA_nI5mGK3YFLiX9IYRgXZZCUd_Br91PaE8Mr1JR01utAPoGx36\",\n  \"d\": \"jriJKFpQfzJtOrp7PhGvH0osHJQJbZrAKjD95itivioVawzMz9wcI_h9VsFV3ff0\"\n}\n</code></pre> - Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>zeqnfYLFWtnJ_e5npBs7CtM5KkToyyM9kCKIFlcyId0</code> - List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>02WdA5ip_Amam611KA6fdoTs533yZH-ovfpt8t9zVjg.aIlhDTWJmT-_Atad5EBbvbZPkPnz2IYT85I6T44kcE4.zeqnfYLFWtnJ_e5npBs7CtM5KkToyyM9kCKIFlcyId0</code> - Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>CftHmHttuxR6mRrHe-zBXV2UEvL2wvZEt5yeFDhYSF8</code> - Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInNraWQiOiJ4WGRuUzNNNEJiNDk3QTBrbzljNkgwRDROTmJqMVhwd0dyNFRrOUZjdzdrIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"eFhkblMzTTRCYjQ5N0Ewa285YzZIMEQ0Tk5iajFYcHdHcjRUazlGY3c3aw\",\n        \"apv\": \"YUlsaERUV0ptVC1fQXRhZDVFQmJ2YlpQa1BuejJJWVQ4NUk2VDQ0a2NFNA\",\n        \"kid\": \"aIlhDTWJmT-_Atad5EBbvbZPkPnz2IYT85I6T44kcE4\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"k7SRlQ7EwCR8VZ-LF92zOgvpFDAed0mN3mmZeCHHDznZp5TLQShFT9TdnwgsvJFP\",\n          \"y\": \"ZHzkS9BD-I2DtNPhbXuTzf6vUnykdZPus9xZnRu1rWgxVtLQ8j-Jp4YoJgdQmcOu\"\n        }\n      },\n      \"encrypted_key\": \"BO597Rs1RU3ZU-WdzWPgRnPmRULcFBihZxE7Jvl3qw3VUmR5RUXY0Xy9k_dWRnuRCh9Yzxef7tXlqVMaL4KBCfaAbAEOReQw\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"eFhkblMzTTRCYjQ5N0Ewa285YzZIMEQ0Tk5iajFYcHdHcjRUazlGY3c3aw\",\n        \"apv\": \"YUlsaERUV0ptVC1fQXRhZDVFQmJ2YlpQa1BuejJJWVQ4NUk2VDQ0a2NFNA\",\n        \"kid\": \"02WdA5ip_Amam611KA6fdoTs533yZH-ovfpt8t9zVjg\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"QT9Q_zU9VE3K9r_50mKh7iG8SxYeXVvwnhykphMAk8akfnTeB7FIRC2MzFat9JMT\",\n          \"y\": \"3HeQPqQ_BS5vy2e2L7kgMhHNwNQ2K1pmL9LImrBg8XROuc9EaAGnFSQ439bZXg9y\"\n        }\n      },\n      \"encrypted_key\": \"oKVlxrYhp8Bvr6s6CW7DxTSCMIFMkqLjDP9sCIkLoetHlXM5Mngq46CUqHusKTceHdSOL8sGUbeSBo6lXRKArywtjiVVyStW\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"eFhkblMzTTRCYjQ5N0Ewa285YzZIMEQ0Tk5iajFYcHdHcjRUazlGY3c3aw\",\n        \"apv\": \"YUlsaERUV0ptVC1fQXRhZDVFQmJ2YlpQa1BuejJJWVQ4NUk2VDQ0a2NFNA\",\n        \"kid\": \"zeqnfYLFWtnJ_e5npBs7CtM5KkToyyM9kCKIFlcyId0\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-384\",\n          \"x\": \"GGFw14WnABx5S__MLwjy7WPgmPzCNbygbJikSqwx1nQ7APAiIyLeiAeZnAFQSr8C\",\n          \"y\": \"Bjev4lkaRbd4Ery0vnO8Ox4QgIDGbuflmFq0HhL-QHIe3KhqxrqZqbQYGlDNudEv\"\n        }\n      },\n      \"encrypted_key\": \"S8vnyPjW_19Hws3-igk-cVTSqVTY0_D9SWahnYnWBFBqTdx0b0e8hf06Oiou31Ww-Y3p8Z3O_okqQGzZMWUMLSxUPeCR2ZWx\"\n    }\n  ],\n  \"aad\": \"CftHmHttuxR6mRrHe-zBXV2UEvL2wvZEt5yeFDhYSF8\",\n  \"iv\": \"jTaCuNXs4QdX6HuWvl5AsqIEv4nh2JMP\",\n  \"ciphertext\": \"7y463zoRKgVfpKh3EBw\",\n  \"tag\": \"8YKdJpF2DnQQwEkBcbuEnw\"\n}\n</code></pre></p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#213-nist-p-521-keys","title":"2.1.3 NIST P-521 keys","text":"<p>The packer generates the following protected headers that includes the skid: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"XC20P\",\"skid\":\"bq3OI5517dSIMeD9K3lTqvkvvkmsRtifD6tvjlrKYsU\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInNraWQiOiJicTNPSTU1MTdkU0lNZUQ5SzNsVHF2a3Z2a21zUnRpZkQ2dHZqbHJLWXNVIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9</code> - Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"ACN9T83BbPNn1eRyo-TrL0GyC7kBNQvgUxk55fCeQKDSTVhbzCKia7WecCUshyEF-BOQbfEsOIUCq3g7xY3VEeth\",\n  \"y\": \"APDIfDv6abLQ-Zb_p8PxwJe1x3U0-PdgXLNbtS7evGuUROHt79SVkpfXcZ3UaEc6cMoFfd2oMvbmUjCMM4-Sgipn\",\n  \"d\": \"AXCGyR9uXY8vDr7D4HvMxep-d5biQzgHR6WsdOF4R5M9qYb8FhRIQCMbmDSZzCuqgGgXrPRMPm5-omvWVeYqwwa3\"\n}\n</code></pre> - Sender kid (jwk thumbprint raw base64 URL encoded): <code>bq3OI5517dSIMeD9K3lTqvkvvkmsRtifD6tvjlrKYsU</code> - Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AZi-AxJkB09qw8dBnNrz53xM-wER0Y5IYXSEWSTtzI5Sdv_5XijQn9z-vGz1pMdww-C75GdpAzp2ghejZJSxbAd6\",\n  \"y\": \"AZzRvW8NBytGNbF3dyNOMHB0DHCOzGp8oYBv_ZCyJbQUUnq-TYX7j8-PlKe9Ce5acxZzrcUKVtJ4I8JgI5x9oXIW\",\n  \"d\": \"AHGOZNkAcQCdDZOpQRdbH-f89mpjY_kGmtEpTExd51CcRlHhXuuAr6jcgb8YStwy9FN7vCU1y5LnJfKhGUGrP2a4\"\n}\n</code></pre> - Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>7icoqReWFlpF16dzZD3rBgK1cJ265WzfF9sJJXqOe0M</code> - Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"ASRvWU-d_XI2S1UQb7PoXIXTLXd8vgLmFb-9mmmIrzTMmIXFXpsDN9_1-Xg_r3qkEg-zBjTi327GIseWFGMa0Mrp\",\n  \"y\": \"AJ0VyjDn4Rn6SKamFms4593mW5K936d4Jr7-J5OjJqTZtS6APgNkrwFjhKPHQfg7o8T4pmX7vlfFY5Flx7IOYJuw\",\n  \"d\": \"ALzWMohuwSqkiqqEhijiBoH6kJ580Dtxe7CfgqEboc5DG0pMtAUf-a91VbmR1U8bQox-B4_YRXoFLRns2tI_wPYz\"\n}\n</code></pre> - Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>BUEVQ3FlDsml4JYrLCwwsL5BUZt-hYwb2B0SoJ6dzHc</code> - Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AB2ke_2nVg95OP3Xb4Fg0Gg4KgfZZf3wBEYoOlGhXmHNCj56G10vnOe1hGRKIoD-JkPWuulcUtsIUO7r3Rz2mLP0\",\n  \"y\": \"AJTaqfF8d4cFv_fP4Uoqq-uCCObmyPsD1CphbCuCZumarfzjA5SpAQCdfz3No4Nhn53OqdcTkm654Yvfj1vOp5t6\",\n  \"d\": \"Af6Ba1x6i6glhRcR2RmZMZJ5BJXibpMB0TqjY_2Fe2LekS9QQK21JtrF20dj_gahxcrnfcn8oJ2xCrEMKaexgcsb\"\n}\n</code></pre> - Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>C9iN-jkTFBbTz3Yv3FquR3dAsHYnAIg1_hT0jsefLDE</code> - List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>7icoqReWFlpF16dzZD3rBgK1cJ265WzfF9sJJXqOe0M.BUEVQ3FlDsml4JYrLCwwsL5BUZt-hYwb2B0SoJ6dzHc.C9iN-jkTFBbTz3Yv3FquR3dAsHYnAIg1_hT0jsefLDE</code> - Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>VBNrffp39h1F6sg0dzkArcd2WjpKeqEvqt6HNXaVfKU</code> - Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInNraWQiOiJicTNPSTU1MTdkU0lNZUQ5SzNsVHF2a3Z2a21zUnRpZkQ2dHZqbHJLWXNVIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"YnEzT0k1NTE3ZFNJTWVEOUszbFRxdmt2dmttc1J0aWZENnR2amxyS1lzVQ\",\n        \"apv\": \"N2ljb3FSZVdGbHBGMTZkelpEM3JCZ0sxY0oyNjVXemZGOXNKSlhxT2UwTQ\",\n        \"kid\": \"7icoqReWFlpF16dzZD3rBgK1cJ265WzfF9sJJXqOe0M\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"ABd71Xomy3mv-mkAipKb18UQ-1xXt7tGDDwf0k5fpLADg1qK--Jhn8TdzyjTuve7rJQrlCJH4GjuQjCWVs4T7J_T\",\n          \"y\": \"ANrWrk69QRi4cr8ZbU2vF_0jSjTIUn-fQCHJtxLg3uuvLtzGW7oIEkUFJq_sTZXL_gaPdFIWlI4aIjKRgzOUP_ze\"\n        }\n      },\n      \"encrypted_key\": \"lZa-4LTyaDP01wmN8bvoD69MLl3VY2H_wNaNJ7kYzTFExlgYTPNrFJ5XL6T_h1DUULX0TYJVxbIWQeJ_x_7i-xSv7-BHbFcm\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"YnEzT0k1NTE3ZFNJTWVEOUszbFRxdmt2dmttc1J0aWZENnR2amxyS1lzVQ\",\n        \"apv\": \"N2ljb3FSZVdGbHBGMTZkelpEM3JCZ0sxY0oyNjVXemZGOXNKSlhxT2UwTQ\",\n        \"kid\": \"BUEVQ3FlDsml4JYrLCwwsL5BUZt-hYwb2B0SoJ6dzHc\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"ALGN2OH1_DKtEZ-990uL1kzHYhYmZD-stOdL6_NMReCKEPZil7Z1tsq0g9l0HNi6DWuMjNyiJCfDd1erWpByFAOX\",\n          \"y\": \"AQgB2aE_3GltqbWzKbWbLa6Fdq6jO4A3LrYUnNDNIuHY6eRH9sRU0yWjmcmWCoukT98wksXJ3isHr9-NqFuZLehi\"\n        }\n      },\n      \"encrypted_key\": \"bybMPkSjuSz8lLAPFJHrxjl1buE8cfONEzvQ2U64h8L0QEZPLK_VewbXVflEPNrOo3oTWlI_878GIKvkxJ8cJOD6a0kZmr87\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"YnEzT0k1NTE3ZFNJTWVEOUszbFRxdmt2dmttc1J0aWZENnR2amxyS1lzVQ\",\n        \"apv\": \"N2ljb3FSZVdGbHBGMTZkelpEM3JCZ0sxY0oyNjVXemZGOXNKSlhxT2UwTQ\",\n        \"kid\": \"C9iN-jkTFBbTz3Yv3FquR3dAsHYnAIg1_hT0jsefLDE\",\n        \"epk\": {\n          \"kty\": \"EC\",\n          \"crv\": \"P-521\",\n          \"x\": \"AZKyI6Mg8OdKUYqo3xuKjHiVrlV56_qGBzdwr86QSnebq3Y69Z0qETiTumQv5J3ECmZzs4DiETryRuzdHc2RkKBZ\",\n          \"y\": \"ARJJT7MWjTWWB7leblQgg7PYn_0deScO7AATlcnukFsLbzly0LHs1msVXaerQUCHPg2t-sYGxDP7w0iaDHB8k3Tj\"\n        }\n      },\n      \"encrypted_key\": \"nMGoNk1brn9uO9hlSa7NwVgFUMXnxpKKPkuFHSE2aM_N8q8wJbVBLC9rJ9sPIiSU20tq2sJXaAcoMteajOX6wj_Hzl1uRT1e\"\n    }\n  ],\n  \"aad\": \"VBNrffp39h1F6sg0dzkArcd2WjpKeqEvqt6HNXaVfKU\",\n  \"iv\": \"h0bbZygiAx9MMO2Huxym_QnwrXZHhdyQ\",\n  \"ciphertext\": \"LABYmf_sfPNGgls0wvk\",\n  \"tag\": \"z1rZOEgyryiW_3d5gxnMUQ\"\n}\n</code></pre></p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#214-x25519-keys","title":"2.1.4 X25519 keys","text":"<p>The packer generates the following protected headers that includes the skid: - Generated protected headers: <code>{\"cty\":\"application/didcomm-plain+json\",\"enc\":\"XC20P\",\"skid\":\"j8E-tcw1Z_eOCoKEH-7a9T532r8zXfcavbPZlofN0Ek\",\"typ\":\"application/didcomm-encrypted+json\"}</code>   - raw (no padding) base64URL encoded: <code>eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInNraWQiOiJqOEUtdGN3MVpfZU9Db0tFSC03YTlUNTMycjh6WGZjYXZiUFpsb2ZOMEVrIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9</code> - Sender key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"g3Lpdd_DRgjK28qi0sR0-hI-zv7a1X52vpzKc6ZM1Qs\",\n  \"d\": \"cPU_Io7RRHNb_xkQ_D6u3ER4vSjvsILDCKwOj8kVHXQ\"\n}\n</code></pre> - Sender kid (jwk thumbprint raw base64 URL encoded): <code>j8E-tcw1Z_eOCoKEH-7a9T532r8zXfcavbPZlofN0Ek</code> - Recipient 1 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"VlhpUXj-oGs9ge-VLrmYF7Xuzy73YchIfckaYcQefBw\",\n  \"d\": \"QFHCCy0wzgJ_AlGMnjetTd0tnDaZ_7yqJODSV0d-kkg\"\n}\n</code></pre> - Recipient 1 kid (jwk thumbprint raw base64 URL encoded): <code>_DHSbVaMeZxriDJn5VoHXYXo6BJacwZx_fGIBfCiJ5c</code> - Recipient 2 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"y52sexwATOR5J5znNp94MFx19J0rkgzNyLESMVhkE2M\",\n  \"d\": \"6NwEk3_8lKOwLaZM2YkLdW9MF2zDqMjAx_G-uDoAAkw\"\n}\n</code></pre> - Recipient 2 kid (jwk thumbprint raw base64 URL encoded): <code>n2MxD23PaCkz7vptma_1j9X2JdUoCFLzrtYuDvOA0Kc</code> - Recipient 3 key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"BYL51mNvx1LKD2wDfga_7GZc0YYI82HhRmHtXfiz_ko\",\n  \"d\": \"MLd_nsRRb_CSzc6Ou8TZFm-A17ZpT1Aen6fIvC6ZuV8\"\n}\n</code></pre> - Recipient 3 kid (jwk thumbprint raw, no padding, base64 URL encoded): <code>HHN2ZcES5ps7gCjK-06bCE4EjX_hh7nq2cWd-GfnI5s</code> - List of kids used for AAD for the above recipients (sorted <code>kid</code> values joined with <code>.</code>): <code>HHN2ZcES5ps7gCjK-06bCE4EjX_hh7nq2cWd-GfnI5s._DHSbVaMeZxriDJn5VoHXYXo6BJacwZx_fGIBfCiJ5c.n2MxD23PaCkz7vptma_1j9X2JdUoCFLzrtYuDvOA0Kc</code> - Resulting AAD value (sha256 of above list raw, no padding, base64 URL encoded): <code>K1oFStibrX4x6LplTB0-tO3cwGiZzMvG_6w0LfguVuI</code> - Finally, packing the payload outputs the following JWE (pretty printed for readability): <pre><code>{\n  \"protected\": \"eyJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsInNraWQiOiJqOEUtdGN3MVpfZU9Db0tFSC03YTlUNTMycjh6WGZjYXZiUFpsb2ZOMEVrIiwidHlwIjoiYXBwbGljYXRpb24vZGlkY29tbS1lbmNyeXB0ZWQranNvbiJ9\",\n  \"recipients\": [\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"ajhFLXRjdzFaX2VPQ29LRUgtN2E5VDUzMnI4elhmY2F2YlBabG9mTjBFaw\",\n        \"apv\": \"X0RIU2JWYU1lWnhyaURKbjVWb0hYWVhvNkJKYWN3WnhfZkdJQmZDaUo1Yw\",\n        \"kid\": \"_DHSbVaMeZxriDJn5VoHXYXo6BJacwZx_fGIBfCiJ5c\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"77VAbpx5xn2iavmhzZATXwGnxjRyxjBbtNzojdWP7wo\"\n        }\n      },\n      \"encrypted_key\": \"dvBscDJj2H6kZJgfdqazZ9pXZxUzai-mcExsdr11-RNvxxPd4_Cy6rolLSsY6ugm1sCo9BgRhAW1e6vxgTnY3Ctv0_xZIhvr\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"ajhFLXRjdzFaX2VPQ29LRUgtN2E5VDUzMnI4elhmY2F2YlBabG9mTjBFaw\",\n        \"apv\": \"X0RIU2JWYU1lWnhyaURKbjVWb0hYWVhvNkJKYWN3WnhfZkdJQmZDaUo1Yw\",\n        \"kid\": \"n2MxD23PaCkz7vptma_1j9X2JdUoCFLzrtYuDvOA0Kc\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"sZtHwxjaS51BR2SBGC32jFvUgVlABZ7rkBFqJk8ktXM\"\n        }\n      },\n      \"encrypted_key\": \"2gIQKw_QpnfGbIOso_XesSGWC9ZKu4-ox1eqRu71aS-nBWAbFrdJPqSY7gzAOGUNqg_o6mC1q7coG69G9yen37DIjcoR6mD1\"\n    },\n    {\n      \"header\": {\n        \"alg\": \"ECDH-1PU+XC20PKW\",\n        \"apu\": \"ajhFLXRjdzFaX2VPQ29LRUgtN2E5VDUzMnI4elhmY2F2YlBabG9mTjBFaw\",\n        \"apv\": \"X0RIU2JWYU1lWnhyaURKbjVWb0hYWVhvNkJKYWN3WnhfZkdJQmZDaUo1Yw\",\n        \"kid\": \"HHN2ZcES5ps7gCjK-06bCE4EjX_hh7nq2cWd-GfnI5s\",\n        \"epk\": {\n          \"kty\": \"OKP\",\n          \"crv\": \"X25519\",\n          \"x\": \"48AJF8kNoxfHXpUtBApRMUcTf8B0Ho4i_6CvGT4arGY\"\n        }\n      },\n      \"encrypted_key\": \"o_toInYq_NP45UqqFg461O6ruUNSQNKrBXRDA06JQ-faMUUfMGRtzNHK-FzrhtodZLW5bRFFFry9aFjwg5aYloe2JG9-fEcw\"\n    }\n  ],\n  \"aad\": \"K1oFStibrX4x6LplTB0-tO3cwGiZzMvG_6w0LfguVuI\",\n  \"iv\": \"tcThx2bVV8jhteYknijC-vxSED_BKPF8\",\n  \"ciphertext\": \"DUZLQAnWzApBFdwlZDg\",\n  \"tag\": \"YLuHzCD4xSTDxe_0AWukyw\"\n}\n</code></pre></p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#22-single-recipient-jwes","title":"2.2 Single Recipient JWEs","text":"<p>Packing a message with 1 recipient using the Flattened JWE JSON serialization and the Compact JWE serialization formats as mentioned in the notes above.</p>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#221-nist-p-256-key","title":"2.2.1 NIST P-256 key","text":"<ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"46OXm1dUTO3MB-8zoxbn-9dk0khgeIqsKFO-nTJ9keM\",\n  \"y\": \"8IlrwB-dl5bFd5RT4YAbgAdj5Y-a9zhc9wCMnXDZDvA\",\n  \"d\": \"58GZDz9_opy-nEeaJ_cyEL63TO-l063aV5nLADCgsGY\"\n}\n</code></pre></li> <li>Sender kid (jwk thumbprint raw base64 URL encoded): <code>T1jGtZoU-Xa_5a1QKexUU0Jq9WKDtS7TCowVvjoFH04</code></li> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-256\",\n  \"x\": \"r9MRjEQ7CBxAgMyEG3ZjIlkGCuRX0rTaBdbkAcY17hA\",\n  \"y\": \"MRSgHQycDFPdSABGv5V0Qd-2q7ebs_x0_fNFyabGgXU\",\n  \"d\": \"LK9yfSxuET5n5uZDNO-64sJKWxJs7LTkqhA4mAuKQnE\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>dmfXisqWjRT-tFpODOD-G0CBF6zjHywNUjrrD3IFmcs</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILTFQVStYQzIwUEtXIiwiYXB1IjoiVkRGcVIzUmFiMVV0V0dGZk5XRXhVVXRsZUZWVk1FcHhPVmRMUkhSVE4xUkRiM2RXZG1wdlJrZ3dOQSIsImFwdiI6IlpHMW1XR2x6Y1ZkcVVsUXRkRVp3VDBSUFJDMUhNRU5DUmpaNmFraDVkMDVWYW5KeVJETkpSbTFqY3ciLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJjcnYiOiJQLTI1NiIsImt0eSI6IkVDIiwieCI6Ik5ZM3Zra04wYTFPRTBuZk1UaDR4U25IU1A2c0VianYycWp5T3J6Rm9TNnMiLCJ5IjoibUhOdnZYUmVmV0lHcU4zTC1ZWnctdElMTXZlUURWcEEzSk55V20tR21HUSJ9LCJraWQiOiJkbWZYaXNxV2pSVC10RnBPRE9ELUcwQ0JGNnpqSHl3TlVqcnJEM0lGbWNzIiwic2tpZCI6IlQxakd0Wm9VLVhhXzVhMVFLZXhVVTBKcTlXS0R0UzdUQ293VnZqb0ZIMDQiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"encrypted_key\": \"dXV4byLXvAHCGKSNqOT87cOwTmdlhn9665LvwXre0BJqSectrLZVQZ4udqKCccgdZAGwmIct5T-uwGYz_tLkOUQBbTXBxHDt\",\n  \"iv\": \"ULEzDlTLgPXfS3a-SfspZmD02o53DfTB\",\n  \"ciphertext\": \"8Z4TLHADLiuHmQEFMrU\",\n  \"tag\": \"oJgQoovq__wSPgzco1udpA\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILTFQVStYQzIwUEtXIiwiYXB1IjoiVkRGcVIzUmFiMVV0V0dGZk5XRXhVVXRsZUZWVk1FcHhPVmRMUkhSVE4xUkRiM2RXZG1wdlJrZ3dOQSIsImFwdiI6IlpHMW1XR2x6Y1ZkcVVsUXRkRVp3VDBSUFJDMUhNRU5DUmpaNmFraDVkMDVWYW5KeVJETkpSbTFqY3ciLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2IiwieCI6Ik5ZM3Zra04wYTFPRTBuZk1UaDR4U25IU1A2c0VianYycWp5T3J6Rm9TNnMiLCJ5IjoibUhOdnZYUmVmV0lHcU4zTC1ZWnctdElMTXZlUURWcEEzSk55V20tR21HUSJ9LCJraWQiOiJkbWZYaXNxV2pSVC10RnBPRE9ELUcwQ0JGNnpqSHl3TlVqcnJEM0lGbWNzIiwic2tpZCI6IlQxakd0Wm9VLVhhXzVhMVFLZXhVVTBKcTlXS0R0UzdUQ293VnZqb0ZIMDQiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0.dXV4byLXvAHCGKSNqOT87cOwTmdlhn9665LvwXre0BJqSectrLZVQZ4udqKCccgdZAGwmIct5T-uwGYz_tLkOUQBbTXBxHDt.ULEzDlTLgPXfS3a-SfspZmD02o53DfTB.8Z4TLHADLiuHmQEFMrU.oJgQoovq__wSPgzco1udpA</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-1PU+XC20PKW\",\n  \"apu\": \"VDFqR3Rab1UtWGFfNWExUUtleFVVMEpxOVdLRHRTN1RDb3dWdmpvRkgwNA\",\n  \"apv\": \"ZG1mWGlzcVdqUlQtdEZwT0RPRC1HMENCRjZ6akh5d05VanJyRDNJRm1jcw\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"XC20P\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-256\",\n    \"x\": \"NY3vkkN0a1OE0nfMTh4xSnHSP6sEbjv2qjyOrzFoS6s\",\n    \"y\": \"mHNvvXRefWIGqN3L-YZw-tILMveQDVpA3JNyWm-GmGQ\"\n  },\n  \"kid\": \"dmfXisqWjRT-tFpODOD-G0CBF6zjHywNUjrrD3IFmcs\",\n  \"skid\": \"T1jGtZoU-Xa_5a1QKexUU0Jq9WKDtS7TCowVvjoFH04\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#222-nist-p-384-key","title":"2.2.2 NIST P-384 key","text":"<ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"bfuATmVQ_jxLIgfuhKNYrNRNu-VnK4FzTCCVRvycgekS8fIuC4rZS9uQi6Q2Ujwd\",\n  \"y\": \"XkVJ93cLKpeZeCMEOsHRKk4rse1zXpzY6yUibEtwZG9nFWF05Ro8OQs5fZVK2TWC\",\n  \"d\": \"OVzGxGyyaHGJpx1MoSwPjmWPas28sfq1tj7UkYFoK3ENsujmzUduAW6HwyaBlXRW\"\n}\n</code></pre></li> <li>Sender kid (jwk thumbprint raw base64 URL encoded): <code>xXdnS3M4Bb497A0ko9c6H0D4NNbj1XpwGr4Tk9Fcw7k</code></li> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-384\",\n  \"x\": \"xhk5K7x4xw9OJpkFhmsY39jceQqx57psvcZstiNZmKbXD7kT9ajfGKFA6YA-ali5\",\n  \"y\": \"7Hj32-JDMNDYWRGy3f-0E9lbUGp6yURMaZ9M36Q_FPgljKgHa9i0Fn1ogr_zEmO3\",\n  \"d\": \"Pc3r6eg15XZeKgTDMPcGjf_SvImZxG4bDzgCh3QShClAwMdmoNbzPZGhBByNrlvO\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>aIlhDTWJmT-_Atad5EBbvbZPkPnz2IYT85I6T44kcE4</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILTFQVStYQzIwUEtXIiwiYXB1IjoiZUZoa2JsTXpUVFJDWWpRNU4wRXdhMjg1WXpaSU1FUTBUazVpYWpGWWNIZEhjalJVYXpsR1kzYzNhdyIsImFwdiI6IllVbHNhRVJVVjBwdFZDMWZRWFJoWkRWRlFtSjJZbHBRYTFCdWVqSkpXVlE0TlVrMlZEUTBhMk5GTkEiLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJjcnYiOiJQLTM4NCIsImt0eSI6IkVDIiwieCI6Inp1TjJhYTZBdmRHVVdjaHNyMTdBMENvOWFmcnlnRll6TjRxZlM0dnlNS05BTF83dVVhR1d2ZVBMNkpoc25MMnYiLCJ5IjoiZTJva1U5VWUzbE9CUWxEZnFVczE5NjFQU2tMTkg1d3U1V2NRd2ZuYzdEdmhsU2tXSU9iQWpoekhoVUVZUjRBZSJ9LCJraWQiOiJhSWxoRFRXSm1ULV9BdGFkNUVCYnZiWlBrUG56MklZVDg1STZUNDRrY0U0Iiwic2tpZCI6InhYZG5TM000QmI0OTdBMGtvOWM2SDBENE5OYmoxWHB3R3I0VGs5RmN3N2siLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"encrypted_key\": \"9bCR6CdqKSRLCFf_vShRhub1pNwoPRypHEqEMfamxy4ZcSp7y8SULzTs2rMmnBt8iJn1PiaBEYbsjsOgzgYamXQ-3OQeIg5z\",\n  \"iv\": \"ryiQAsZiEVcDqJb1jQpG9nQ0p50cXJSM\",\n  \"ciphertext\": \"xQiyTPTrLUFvTeVn9CI\",\n  \"tag\": \"b65D-L5AybH327bWsEIRUg\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILTFQVStYQzIwUEtXIiwiYXB1IjoiZUZoa2JsTXpUVFJDWWpRNU4wRXdhMjg1WXpaSU1FUTBUazVpYWpGWWNIZEhjalJVYXpsR1kzYzNhdyIsImFwdiI6IllVbHNhRVJVVjBwdFZDMWZRWFJoWkRWRlFtSjJZbHBRYTFCdWVqSkpXVlE0TlVrMlZEUTBhMk5GTkEiLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMzg0IiwieCI6Inp1TjJhYTZBdmRHVVdjaHNyMTdBMENvOWFmcnlnRll6TjRxZlM0dnlNS05BTF83dVVhR1d2ZVBMNkpoc25MMnYiLCJ5IjoiZTJva1U5VWUzbE9CUWxEZnFVczE5NjFQU2tMTkg1d3U1V2NRd2ZuYzdEdmhsU2tXSU9iQWpoekhoVUVZUjRBZSJ9LCJraWQiOiJhSWxoRFRXSm1ULV9BdGFkNUVCYnZiWlBrUG56MklZVDg1STZUNDRrY0U0Iiwic2tpZCI6InhYZG5TM000QmI0OTdBMGtvOWM2SDBENE5OYmoxWHB3R3I0VGs5RmN3N2siLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0.9bCR6CdqKSRLCFf_vShRhub1pNwoPRypHEqEMfamxy4ZcSp7y8SULzTs2rMmnBt8iJn1PiaBEYbsjsOgzgYamXQ-3OQeIg5z.ryiQAsZiEVcDqJb1jQpG9nQ0p50cXJSM.xQiyTPTrLUFvTeVn9CI.b65D-L5AybH327bWsEIRUg</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-1PU+XC20PKW\",\n  \"apu\": \"eFhkblMzTTRCYjQ5N0Ewa285YzZIMEQ0Tk5iajFYcHdHcjRUazlGY3c3aw\",\n  \"apv\": \"YUlsaERUV0ptVC1fQXRhZDVFQmJ2YlpQa1BuejJJWVQ4NUk2VDQ0a2NFNA\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"XC20P\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-384\",\n    \"x\": \"zuN2aa6AvdGUWchsr17A0Co9afrygFYzN4qfS4vyMKNAL_7uUaGWvePL6JhsnL2v\",\n    \"y\": \"e2okU9Ue3lOBQlDfqUs1961PSkLNH5wu5WcQwfnc7DvhlSkWIObAjhzHhUEYR4Ae\"\n  },\n  \"kid\": \"aIlhDTWJmT-_Atad5EBbvbZPkPnz2IYT85I6T44kcE4\",\n  \"skid\": \"xXdnS3M4Bb497A0ko9c6H0D4NNbj1XpwGr4Tk9Fcw7k\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#223-nist-p-521-key","title":"2.2.3 NIST P-521 key","text":"<ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"ACN9T83BbPNn1eRyo-TrL0GyC7kBNQvgUxk55fCeQKDSTVhbzCKia7WecCUshyEF-BOQbfEsOIUCq3g7xY3VEeth\",\n  \"y\": \"APDIfDv6abLQ-Zb_p8PxwJe1x3U0-PdgXLNbtS7evGuUROHt79SVkpfXcZ3UaEc6cMoFfd2oMvbmUjCMM4-Sgipn\",\n  \"d\": \"AXCGyR9uXY8vDr7D4HvMxep-d5biQzgHR6WsdOF4R5M9qYb8FhRIQCMbmDSZzCuqgGgXrPRMPm5-omvWVeYqwwa3\"\n}\n</code></pre></li> <li>Sender kid (jwk thumbprint raw base64 URL encoded): <code>bq3OI5517dSIMeD9K3lTqvkvvkmsRtifD6tvjlrKYsU</code></li> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"EC\",\n  \"crv\": \"P-521\",\n  \"x\": \"AZi-AxJkB09qw8dBnNrz53xM-wER0Y5IYXSEWSTtzI5Sdv_5XijQn9z-vGz1pMdww-C75GdpAzp2ghejZJSxbAd6\",\n  \"y\": \"AZzRvW8NBytGNbF3dyNOMHB0DHCOzGp8oYBv_ZCyJbQUUnq-TYX7j8-PlKe9Ce5acxZzrcUKVtJ4I8JgI5x9oXIW\",\n  \"d\": \"AHGOZNkAcQCdDZOpQRdbH-f89mpjY_kGmtEpTExd51CcRlHhXuuAr6jcgb8YStwy9FN7vCU1y5LnJfKhGUGrP2a4\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>7icoqReWFlpF16dzZD3rBgK1cJ265WzfF9sJJXqOe0M</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILTFQVStYQzIwUEtXIiwiYXB1IjoiWW5FelQwazFOVEUzWkZOSlRXVkVPVXN6YkZSeGRtdDJkbXR0YzFKMGFXWkVOblIyYW14eVMxbHpWUSIsImFwdiI6Ik4ybGpiM0ZTWlZkR2JIQkdNVFprZWxwRU0zSkNaMHN4WTBveU5qVlhlbVpHT1hOS1NsaHhUMlV3VFEiLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJjcnYiOiJQLTUyMSIsImt0eSI6IkVDIiwieCI6IkFJemJtMzBZRGVIV21sXy1zeHE2c2NHbEdDS3ZuRmttR2pkc1hKOXN6bm5JQzFMSndvc1hqYmRRd29EX2NjbmtkcUtpaU4tNVVFZGtPTEZldDdXbG83bC0iLCJ5IjoiQVdDendGVjJtUFdYMnpaZzN0SHRpVE11SlhGaEtucWhUT0hPWXBzRF9uRlhGRFhrTlRyd0QyblpVNi1hU2g5Q0NLajF2N0x5VlJ0UE0ybzM5bkt3WEhXWiJ9LCJraWQiOiI3aWNvcVJlV0ZscEYxNmR6WkQzckJnSzFjSjI2NVd6ZkY5c0pKWHFPZTBNIiwic2tpZCI6ImJxM09JNTUxN2RTSU1lRDlLM2xUcXZrdnZrbXNSdGlmRDZ0dmpscktZc1UiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"encrypted_key\": \"-cL11h9eF6CRycMYxvJ6Ksmlf-97Vg2s_ziVnFF5RueiGrvKFmgQp09GIyxrMdTG2so6IRmifOlpwF0YPuzyThhmxToTyfpr\",\n  \"iv\": \"Q0sk9bMraCAJhZyFi3sOAYMoTac4ZuGj\",\n  \"ciphertext\": \"O6OlFqFMz587083_OMU\",\n  \"tag\": \"TyXZ30wpVZ6nmj16evdBnA\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILTFQVStYQzIwUEtXIiwiYXB1IjoiWW5FelQwazFOVEUzWkZOSlRXVkVPVXN6YkZSeGRtdDJkbXR0YzFKMGFXWkVOblIyYW14eVMxbHpWUSIsImFwdiI6Ik4ybGpiM0ZTWlZkR2JIQkdNVFprZWxwRU0zSkNaMHN4WTBveU5qVlhlbVpHT1hOS1NsaHhUMlV3VFEiLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJrdHkiOiJFQyIsImNydiI6IlAtNTIxIiwieCI6IkFJemJtMzBZRGVIV21sXy1zeHE2c2NHbEdDS3ZuRmttR2pkc1hKOXN6bm5JQzFMSndvc1hqYmRRd29EX2NjbmtkcUtpaU4tNVVFZGtPTEZldDdXbG83bC0iLCJ5IjoiQVdDendGVjJtUFdYMnpaZzN0SHRpVE11SlhGaEtucWhUT0hPWXBzRF9uRlhGRFhrTlRyd0QyblpVNi1hU2g5Q0NLajF2N0x5VlJ0UE0ybzM5bkt3WEhXWiJ9LCJraWQiOiI3aWNvcVJlV0ZscEYxNmR6WkQzckJnSzFjSjI2NVd6ZkY5c0pKWHFPZTBNIiwic2tpZCI6ImJxM09JNTUxN2RTSU1lRDlLM2xUcXZrdnZrbXNSdGlmRDZ0dmpscktZc1UiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0.-cL11h9eF6CRycMYxvJ6Ksmlf-97Vg2s_ziVnFF5RueiGrvKFmgQp09GIyxrMdTG2so6IRmifOlpwF0YPuzyThhmxToTyfpr.Q0sk9bMraCAJhZyFi3sOAYMoTac4ZuGj.O6OlFqFMz587083_OMU.TyXZ30wpVZ6nmj16evdBnA</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-1PU+XC20PKW\",\n  \"apu\": \"YnEzT0k1NTE3ZFNJTWVEOUszbFRxdmt2dmttc1J0aWZENnR2amxyS1lzVQ\",\n  \"apv\": \"N2ljb3FSZVdGbHBGMTZkelpEM3JCZ0sxY0oyNjVXemZGOXNKSlhxT2UwTQ\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"XC20P\",\n  \"epk\": {\n    \"kty\": \"EC\",\n    \"crv\": \"P-521\",\n    \"x\": \"AIzbm30YDeHWml_-sxq6scGlGCKvnFkmGjdsXJ9sznnIC1LJwosXjbdQwoD_ccnkdqKiiN-5UEdkOLFet7Wlo7l-\",\n    \"y\": \"AWCzwFV2mPWX2zZg3tHtiTMuJXFhKnqhTOHOYpsD_nFXFDXkNTrwD2nZU6-aSh9CCKj1v7LyVRtPM2o39nKwXHWZ\"\n  },\n  \"kid\": \"7icoqReWFlpF16dzZD3rBgK1cJ265WzfF9sJJXqOe0M\",\n  \"skid\": \"bq3OI5517dSIMeD9K3lTqvkvvkmsRtifD6tvjlrKYsU\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0334-jwe-envelope/authcrypt-examples/#224-x25519-key","title":"2.2.4 X25519 key","text":"<ul> <li>Sender key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"g3Lpdd_DRgjK28qi0sR0-hI-zv7a1X52vpzKc6ZM1Qs\",\n  \"d\": \"cPU_Io7RRHNb_xkQ_D6u3ER4vSjvsILDCKwOj8kVHXQ\"\n}\n</code></pre></li> <li>Sender kid (jwk thumbprint raw base64 URL encoded): <code>j8E-tcw1Z_eOCoKEH-7a9T532r8zXfcavbPZlofN0Ek</code></li> <li>Single Recipient key JWK format: <pre><code>{\n  \"kty\": \"OKP\",\n  \"crv\": \"X25519\",\n  \"x\": \"VlhpUXj-oGs9ge-VLrmYF7Xuzy73YchIfckaYcQefBw\",\n  \"d\": \"QFHCCy0wzgJ_AlGMnjetTd0tnDaZ_7yqJODSV0d-kkg\"\n}\n</code></pre></li> <li>Single Recipient kid (jwk thumbprint raw base64 URL encoded): <code>_DHSbVaMeZxriDJn5VoHXYXo6BJacwZx_fGIBfCiJ5c</code></li> <li>Finally, packing the payload outputs the following flattened serialized JWE JSON: <pre><code>{\n  \"protected\": \"eyJhbGciOiJFQ0RILTFQVStYQzIwUEtXIiwiYXB1IjoiYWpoRkxYUmpkekZhWDJWUFEyOUxSVWd0TjJFNVZEVXpNbkk0ZWxobVkyRjJZbEJhYkc5bVRqQkZhdyIsImFwdiI6IlgwUklVMkpXWVUxbFduaHlhVVJLYmpWV2IwaFlXVmh2TmtKS1lXTjNXbmhmWmtkSlFtWkRhVW8xWXciLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJjcnYiOiJYMjU1MTkiLCJrdHkiOiJPS1AiLCJ4IjoiWmdZTkJwcDlRZkZMZFpBT05LaUYxWGdRTkZCdW4tdkx4V25TeTF3ZDRRdyJ9LCJraWQiOiJfREhTYlZhTWVaeHJpREpuNVZvSFhZWG82QkphY3daeF9mR0lCZkNpSjVjIiwic2tpZCI6Imo4RS10Y3cxWl9lT0NvS0VILTdhOVQ1MzJyOHpYZmNhdmJQWmxvZk4wRWsiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0\",\n  \"encrypted_key\": \"6AxohV0ygxzRGGxqKIMovkJf7rCyE1ymbVzxqVEVpioySTzd4Ociy8yTa4uo-wlVCFaKVxitFgD3bgtuidOw5J8r-CXjR42D\",\n  \"iv\": \"AEv2DrMR4rMV8preS0zndED_u11QNnQx\",\n  \"ciphertext\": \"c_RTSoNM5hFpOr3lEFU\",\n  \"tag\": \"m9GKNsP05SKYS9qdTvnsfA\"\n}\n</code></pre></li> <li>The compact serialization of this envelope is:   <code>eyJhbGciOiJFQ0RILTFQVStYQzIwUEtXIiwiYXB1IjoiYWpoRkxYUmpkekZhWDJWUFEyOUxSVWd0TjJFNVZEVXpNbkk0ZWxobVkyRjJZbEJhYkc5bVRqQkZhdyIsImFwdiI6IlgwUklVMkpXWVUxbFduaHlhVVJLYmpWV2IwaFlXVmh2TmtKS1lXTjNXbmhmWmtkSlFtWkRhVW8xWXciLCJjdHkiOiJhcHBsaWNhdGlvbi9kaWRjb21tLXBsYWluK2pzb24iLCJlbmMiOiJYQzIwUCIsImVwayI6eyJrdHkiOiJPS1AiLCJjcnYiOiJYMjU1MTkiLCJ4IjoiWmdZTkJwcDlRZkZMZFpBT05LaUYxWGdRTkZCdW4tdkx4V25TeTF3ZDRRdyJ9LCJraWQiOiJfREhTYlZhTWVaeHJpREpuNVZvSFhZWG82QkphY3daeF9mR0lCZkNpSjVjIiwic2tpZCI6Imo4RS10Y3cxWl9lT0NvS0VILTdhOVQ1MzJyOHpYZmNhdmJQWmxvZk4wRWsiLCJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIn0.6AxohV0ygxzRGGxqKIMovkJf7rCyE1ymbVzxqVEVpioySTzd4Ociy8yTa4uo-wlVCFaKVxitFgD3bgtuidOw5J8r-CXjR42D.AEv2DrMR4rMV8preS0zndED_u11QNnQx.c_RTSoNM5hFpOr3lEFU.m9GKNsP05SKYS9qdTvnsfA</code></li> <li>The single recipient's headers are merged into the <code>protected</code> header, which base64 URL decoded equals to (pretty printed for readability): <pre><code>{\n  \"alg\": \"ECDH-1PU+XC20PKW\",\n  \"apu\": \"ajhFLXRjdzFaX2VPQ29LRUgtN2E5VDUzMnI4elhmY2F2YlBabG9mTjBFaw\",\n  \"apv\": \"X0RIU2JWYU1lWnhyaURKbjVWb0hYWVhvNkJKYWN3WnhfZkdJQmZDaUo1Yw\",\n  \"cty\": \"application/didcomm-plain+json\",\n  \"enc\": \"XC20P\",\n  \"epk\": {\n    \"kty\": \"OKP\",\n    \"crv\": \"X25519\",\n    \"x\": \"ZgYNBpp9QfFLdZAONKiF1XgQNFBun-vLxWnSy1wd4Qw\"\n  },\n  \"kid\": \"_DHSbVaMeZxriDJn5VoHXYXo6BJacwZx_fGIBfCiJ5c\",\n  \"skid\": \"j8E-tcw1Z_eOCoKEH-7a9T532r8zXfcavbPZlofN0Ek\",\n  \"typ\": \"application/didcomm-encrypted+json\"\n}\n</code></pre></li> </ul>"},{"location":"features/0335-http-over-didcomm/","title":"0335: HTTP Over DIDComm","text":"<ul> <li>Authors: Filip Burlacu (SecureKey)</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes:</li> <li>Start Date: 2019-11-26</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0335-http-over-didcomm/#summary","title":"Summary","text":"<p>Allows HTTP traffic to be routed over a DIDComm channel, so applications built to communicate over HTTP can make use of DID-based communication.</p>"},{"location":"features/0335-http-over-didcomm/#motivation","title":"Motivation","text":"<p>This protocol allows a client-server system that doesn't use DIDs or DIDComm to piggyback on top of a DID-based infrastructure, gaining the benefits of DIDs by using agents as HTTP proxies.</p> <p>Example use case:  Carl wants to apply for a car loan from his friendly neighborhood used car dealer. The dealer wants a proof of his financial stability from his bank, but he doesn't want to expose the identity of his bank, and his bank doesn't want to develop a custom in-house system (using DIDs) for anonymity. HTTP over DIDComm allows Carl to introduce his car dealer to his bank, using Aries agents and protocols, while all they need to do is install a standard agent to carry arbitrary HTTP messages.</p> <p>HTTP over DIDComm turns a dev + ops problem, of redesigning and deploying your server and client to use DID communication, into an ops problem - deploying Aries infrastructure in front of your server and to your clients.</p> <p>Using HTTP over DIDComm as opposed to HTTPS between a client and server offers some key benefits: - The client and server can use methods provided by Aries agents to verify their trust in the other party - for example, by presenting verifiable credential proofs. In particular, this allows decentralized client verification and trust, as opposed to client certs. - The client and server can be blind to each others' identities (for example, using fresh peer DIDs and communicating through a router), even while using their agents to ensure trust.</p>"},{"location":"features/0335-http-over-didcomm/#tutorial","title":"Tutorial","text":""},{"location":"features/0335-http-over-didcomm/#name-and-version","title":"Name and Version","text":"<p>This is the HTTP over DIDComm protocol. It is uniquely identified by the URI:</p> <pre><code>\"https://didcomm.org/http-over-didcomm/1.0\"\n</code></pre>"},{"location":"features/0335-http-over-didcomm/#concepts","title":"Concepts","text":"<p>This RFC assumes that you are familiar with DID communication, and the <code>~purpose</code> decorator.</p> <p>This protocol introduces a new message type which carries an HTTP message, and a method by which an Aries agent can serve as an HTTP proxy. The Aries agent determines the target agent to route the HTTP message through (for example, by parsing the HTTP message's request target), and when the target agent receives the message, it serves the message over HTTP.</p> <p>The specifics of determining the target agent or route are not part of this specification, allowing room for a wide array of uses: -  A network of enterprise servers behind agents, with the agents being a known, managed pool, with message routing controlled by business logic. - A privacy mix network, with in-browser agents making requests, and routing agents sending messages on random walks through the network until an agent serves the request over the public internet. - A network of service providers behind a routing network, accessed by clients, with any provider able to handle the same class of requests, so routing is based on efficiency/load. - A network of service providers behind a routing network, accessed by clients, where the routing network hides the identity of the service provider and client from each other.</p>"},{"location":"features/0335-http-over-didcomm/#protocol-flow","title":"Protocol Flow","text":"<p>This protocol takes an HTTP request-response loop and stretches it out across DIDComm, with agents in the middle serving as DIDComm relays, passing along messages.</p> <p>The entities involved in this protocol are as follows: - The client and server: the HTTP client and server, which could communicate via HTTP, but in this protocol communicate over DIDComm. - The client agent: the aries agent which receives the HTTP request from the client, and converts it to a DIDComm message, which it sends to the server agent, and translates the reply from the server agent into an HTTP response. - The server agent: the aries agent which receives the DIDComm request message from the client agent, creates an HTTP request for the server, receives the HTTP response, and translates it into a DIDComm message which it sends to the client agent.</p> <p></p> <p>Before a message can be sent, the server must register with its agent using the <code>~purpose</code> decorator, registering on one or more purpose tags.</p> <p>When a client sends an HTTP request to a client agent, the agent may need to maintain an open connection, or store a record of the client's identity/IP address, so the client can receive the coming response.</p> <p>The client agent can include some logic to decide whether to send the message, and may need to include some logic to decide where to route the message (note that in some architectures, another agent along the route makes the decision, so the agent might always send to the same target). If it does, it constructs a request DIDComm message (defined below) and sends it to the chosen server agent.</p> <p>The route taken by the DIDComm message between the client and server agents is not covered by this RFC.</p> <p>The server agent receives the request DIDComm message. It can include some logic to decide whether to permit the message to continue to the server. If so, it makes an HTTP request using the data in the request DIDComm message, and sends it to the server.</p> <p>Note: in some use-cases, it might make sense for the server agent to act as a transparent proxy, so the server thinks its talking directly to the client, while in others it might make sense to override client identity information so the server thinks it's connecting to the server agent, for example, as a gateway. In this case, the client agent could anonymize the request, rather than leaving it up to the server agent.</p> <p>This same anonymization can be done in the other direction as well.</p> <p>The communication happens in reverse when the server sends an HTTP response to its agent, which may again decide whether to permit it to continue. If so, the contents of the HTTP response are encoded into a response DIDComm message (defined below), sent to the client agent, which also makes a go/no-go decision, does some logic (for example, looking up its thread-id to client database) to figure out where the original request in this thread came from, encodes the response data into an HTTP response, and sends that response to the client.</p>"},{"location":"features/0335-http-over-didcomm/#message-format","title":"Message Format","text":"<p>DIDComm messages for this protocol look as follows:</p>"},{"location":"features/0335-http-over-didcomm/#request","title":"<code>request</code>","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/http-over-didcomm/1.0/request\",\n  \"@id\": \"2a0ec6db-471d-42ed-84ee-f9544db9da4b\",\n  \"~purpose\": [],\n  \"method\": &lt;method&gt;,\n  \"resource-uri\": &lt;resource uri value&gt;,\n  \"version\": &lt;version&gt;,\n  \"headers\": [],\n  \"body\": b64enc(body)\n}\n</code></pre> <p>The <code>body</code> field is optional.</p> <p>The <code>resource-uri</code> field is also optional - if omitted, the server agent needs to set the uri based on the server that is being sent the message.</p> <p>Each element of the <code>headers</code> array is an object with two elements: <code>{\"name\": \"&lt;header-name&gt;\", \"value\": \"&lt;header-value&gt;\"}</code>.</p>"},{"location":"features/0335-http-over-didcomm/#response","title":"<code>response</code>","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/http-over-didcomm/1.0/response\",\n  \"@id\": \"63d6f6cf-b723-4eaf-874b-ae13f3e3e5c5\",\n  \"~thread\": {\n    \"thid\": \"2a0ec6db-471d-42ed-84ee-f9544db9da4b\",\n    \"sender_order\": 1\n  },\n  \"status\": {\n      \"code\":\"\",\n      \"string\":\"\"\n  },\n  \"version\": &lt;version&gt;,\n  \"headers\": [],\n  \"body\": b64enc(body)\n}\n</code></pre> <p>Responses need to indicate their target - the client who sent the request. Response DIDComm messages must include a <code>~thread</code> decorator so the client agent can correlate thread IDs with its stored HTTP connections.</p> <p>The <code>body</code> field is optional.</p> <p>Each element of the <code>headers</code> array is an object with two elements: <code>{\"name\": \"&lt;header-name&gt;\", \"value\": \"&lt;header-value&gt;\"}</code>.</p>"},{"location":"features/0335-http-over-didcomm/#receiving-http-messages-over-didcomm","title":"Receiving HTTP Messages Over DIDComm","text":"<p>Aries agents intended to receive HTTP-over-DIDComm messages have many options for how they handle them, with configuration dependent on intended use. For example: - Serve the message over the internet, configured to use a DNS, etc. - Send the message to a specific server, set in configuration, for an enterprise system where a single server is behind an agent. - Send the message to a server which registered for the message's purpose.</p> <p>In cases where a specific server or application is always the target of certain messages, the server/application should register with the server agent on the specific purpose decorator. In cases where the agent may need to invoke additional logic, the agent itself can register a custom handler.</p> <p>An agent may implement filtering to accept or reject requests based on any combination of the purpose, sender, and request contents.</p>"},{"location":"features/0335-http-over-didcomm/#purpose-value","title":"Purpose Value","text":"<p>The purpose values used in the message should be values whose meanings are agreed upon by the client and server. For example, the purpose value can:  - indicate the required capabilities of the server that handles a request  - contain an anonymous identifier for the server, which has previously been communicated to the client.</p> <p>For example, to support the use of DIDComm as a client-anonymizing proxy, agents could use a purpose value like \"web-proxy\" to indicate that the HTTP request  (received by the server agent) should be made on the web.</p>"},{"location":"features/0335-http-over-didcomm/#reference","title":"Reference","text":""},{"location":"features/0335-http-over-didcomm/#determining-the-recipient-did-by-the-resource-uri","title":"Determining the recipient DID by the Resource URI","text":"<p>In an instance of the HTTP over DIDComm protocol, it is assumed that the client agent has the necessary information to be able to determine the DID of the server agent based on the resource-uri provided in the request. It's reasonable to implement a configuration API to allow a sender or administrator to specify the DID to be used for a particular URI.</p>"},{"location":"features/0335-http-over-didcomm/#-alive-timeout","title":"-Alive &amp; Timeout","text":"<p>The client agent should respect the timeout parameter provided in a keep-alive header if the request header is a keep-alive connection.</p> <p>If a client making an HTTP request expects a response over the same HTTP connection, its agent should keep this connection alive while it awaits a DIDComm response from the server agent, which it should recognize by the <code>~thread</code> decorator in the response message. Timing information can be provided in an optional <code>~timing</code> decorator. </p> <p>Agents implementing this RFC can make use of the <code>~transport</code> decorator to enable response along the same transport.</p>"},{"location":"features/0335-http-over-didcomm/#when-the-client-agent-is-the-server-agent","title":"When the Client Agent is the Server Agent","text":"<p>There is a degenerate case of this protocol where the client and server agents are the same agent. In this case, instead of constructing DIDComm messages, sending them to yourself, and then unpacking them, it would be reasonable to take incoming HTTP messages, apply any pre-send logic (filtering, etc), apply any post-receive logic, and then send them out over HTTP, as a simple proxy.</p> <p>To support this optimization/simplification, the client agent should recognize if the recipient DID is its own, after determining the DID from the resource URI.</p>"},{"location":"features/0335-http-over-didcomm/#http-error-codes","title":"HTTP Error Codes","text":"<p>Failures within the DIDComm protocol can inform the status code returned to the client. </p> <p>If the client agent waits for the time specified in the request keep-alive timeout field, it should respond with a standard 504 gateway timeout status.</p> <p>Error codes which are returned by the server will be transported over DIDComm as normal.</p>"},{"location":"features/0335-http-over-didcomm/#why-http1x","title":"Why HTTP/1.x?","text":"<p>The DIDComm messages in this protocol wrap HTTP/1(.x) messages for a few reasons:  - Wire-level benefits of HTTP/2 are lost by wrapping in DIDComm and sending over another transport (which could itself be HTTP/2)  - DIDComm is not, generally, intended to be a streaming or latency-critical transport layer, so HTTP responses, for example, can be sent complete, including their bodies, instead of being split into frames which are sent over DIDComm separately.</p> <p>The agents are free to support communicating with the client/server using HTTP/2 - the agents simply wait until they've received a complete request or response, before sending it onwards over DIDComm.</p>"},{"location":"features/0335-http-over-didcomm/#https","title":"HTTPS","text":"<p>The client and server can use HTTPS to communicate with their agents - this protocol only specifies that the messages sent over DIDComm are HTTP, not HTTPS.</p>"},{"location":"features/0335-http-over-didcomm/#partial-use-of-http-over-didcomm","title":"Partial use of HTTP over DIDComm","text":"<p>This protocol specifies the behaviour of clients, servers, and their agents. However, the client-side and server-side are decoupled by design, meaning a custom server or client, which obeys all the semantics in this RFC while diverging on technical details, can interoperate with other compliant applications.</p> <p>For example, a client-side agent can construct <code>request</code> messages based on internal logic rather than a request from an external application. On the server side, an agent can handle requests and send responses directly by registering its own listener on a purpose value, rather than having a separate application register.</p>"},{"location":"features/0335-http-over-didcomm/#drawbacks","title":"Drawbacks","text":"<p>You might find the cost too high, with wrapping your messages into HTTP messages, and then wrapping those into DIDComm envelopes. This cost includes the time it takes to wrap and unwrap payloads, as well as the increase in message size. Small messages and simple formats would benefit from being encoded as JSON payloads within custom DIDComm message formats, instead of being wrapped in HTTP messages within DIDComm messages. Large data might benefit from being sent over another channel, encrypted, with identification, decryption, and authentication information sent over DIDComm.</p>"},{"location":"features/0335-http-over-didcomm/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>The main alternative to the method proposed in this RFC is to implement DIDComm in your non-DIDComm applications, if you want them to be able to communicate with each other over DIDComm.</p> <p>Another alternative to sending HTTP messages over DIDComm is sending HTTPS over DIDComm, by establishing a TLS connection between the client and server over the DIDComm transport. This offers some tradeoffs and drawbacks which make it an edge case - it identifies the server with a certificate, it breaks the anonymity offered by DIDComm, and it is not necessary for security since DIDComm itself is securely encrypted and authenticated, and DIDComm messages can be transported over HTTPS as well.</p>"},{"location":"features/0335-http-over-didcomm/#prior-art","title":"Prior art","text":"<p>VPNs and onion routing (like Tor) provide solutions for similar use cases, but none so far use DIDs, which enable more complex use cases with privacy preservation.</p> <p>TLS/HTTPS, being HTTP over TLS, provides a similar transport-layer secure channel to HTTP over DIDComm. Note, this is why this RFC doesn't specify a means to perform HTTPS over DIDComm - DIDComm serves the same role as TLS does in HTTPS, but offers additional benefits: - Verifiable yet anonymous authentication of the client, for example, using delegated credentials. - Access to DIDComm mechanisms, such as using the introduce protocol to connect the client and server.</p>"},{"location":"features/0335-http-over-didcomm/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>Likely some specifics of go/no-go or routing logic</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>The routing and logic specifics of certain use cases</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"features/0335-http-over-didcomm/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0347-proof-negotiation/","title":"Aries RFC 0347: Proof Negotiation","text":"<ul> <li>Authors: Philipp Rieblinger, Sebastian Weidenbach</li> <li>Status: PROPOSED</li> <li>Since: 2019-12-13</li> <li>Status Note: Initial proposal after discussion on rocketchat</li> <li>Supersedes: </li> <li>Start Date: 2019-09-09</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0347-proof-negotiation/#summary","title":"Summary","text":"<p>This RFC proposes an extension to Aries RFC 0037: Present Proof Protocol 1.0 by taking the concept of groups out of the DID credential manifest and including them in the present proof protocol. Additionally to the rules described in the credential manifest, an option to provide alternative attributes with a weight is being introduced here. Also, the possibility to include not only attributes, but also credentials and openids in a proof by using a \"type\" was taken from the DID credential manifest.  The goal of this is an approach to make proof presentation more flexible, allowing attributes to be required or optional as well as allowing a choose-from-a-list scenario.  So far, proof requests were to be replied to with a proof response that contained all attributes listed in the proof request. To this, this RFC adds a way to mark attributes as optional, so that they are communicated as nice-to-have to the user of a wallet.</p>"},{"location":"features/0347-proof-negotiation/#motivation","title":"Motivation","text":"<p>We see a need in corporate identity and access management for a login process handling not only user authentication against an application, but also determining which privileges the user is being granted inside the application and which data the user must or may provide. Aries can provide this by combining a proof request with proof negotiation.</p>"},{"location":"features/0347-proof-negotiation/#use-case-example","title":"Use Case Example","text":"<p>A bank needs a customer to prove they are credit-worthy using Aries-based Self-Sovereign Identity. For this, the bank wants to make the proof of credit-worthyness flexible, in that an identity owner can offer different sets and combinations of credentials. For instance, this can be a choice between a certificate of credit-worthiness from another trusted bank or alternatively a set of credentials proving ownership over real estate and a large fortune in a bank account, for example. Optionally, an Identity Owner can add certain credentials to the proof to further prove worthiness in order to be able to obtain larger loans.</p>"},{"location":"features/0347-proof-negotiation/#tutorial","title":"Tutorial","text":"<p>A proof request sent to an identity owner defines the attributes to be included in the proof response, i.e. the ones to prove. To add a degree of flexibility to the process, it is possible to request attributes as necessary (meaning they have to be included in the response for it to be valid) or to allow the identity owner to pick one of or several of multiple attributes from a list. Furthermore, attributes can be marked as optional. For users, this procedure may look like the example of a privacy-friendly access permission process shown in the manifesto of Okuna, an open-source social network that is still in development at the time of this writing (click on \"continue with Okuna\" to see said example). Backend-wise, this may be implemented as follows:</p>"},{"location":"features/0347-proof-negotiation/#proof-request-with-attribute-negotiation","title":"Proof Request with attribute negotiation","text":"<p>This feature can be implemented building on top of the credential manifest developed by the Decentralized Identity Foundation. One feature the above concept by the Decentralized Identity Foundation lacks is a way of assigning a weight to attributes within the category \"one of\". It is possible that future implementations using this concept will want to prefer certain attributes over others in the same group if both are given, so a way of assigning these different priorities to attributes should be possible. Below is an the above example of a proof request to which a rule \"pick_weighted\" and a group D were added. Furthermore, the categories \"groups_required\" and \"groups_optional\" were added to be able to differentiate between required and optional attributes which the credential manifest did not.</p> <p>Example of a proof presentation request (from verifier):</p> <p><pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/request-presentation\",\n    \"@id\": \"98fd8d82-81a6-4409-acc2-c35ea39d0f28\",\n    \"comment\": \"some comment\",\n    \"request_presentations~attach\": [\n        {\n            \"@id\": \"libindy-request-presentation-0\",\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;yaml-formatted string describing attachments, base64url-encoded because of libindy&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> The base64url-encoded content above decodes to the following data structure, a presentation preview: <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/presentation-preview\",\n    \"@context\": \"https://path.to/schemas/credentials\",\n    \"comment\":\"some comment\",\n    \"~thread\": {\n        \"thid\": \"98fd8d82-81a6-4409-acc2-c35ea39d0f28\",\n        \"sender_order\": 0\n    }\n    \"credential\":\"proof_request\", // verifiable claims elements\n    \"groups_required\": [ // these groups are the key feature to this RFC\n            {\n                \"rule\":\"all\",\n                \"from\": [\"A\", \"B\"]\n            },\n            {\n                \"rule\": \"pick\",\n                \"count\": 1,\n                \"from\": [\"C\"]\n            },\n            {\n                \"rule\": \"pick_weighted\",\n                \"count\": 1,\n                \"from\": [\"D\"]\n            }\n        ],\n        \"groups_optional\": [\n            {\n                \"rule\": \"all\",\n                \"from\": [\"D\"]\n            }\n        ],\n    \"inputs\": [\n        {\n            \"type\": \"data\",\n            \"name\": \"routing_number\",\n            \"group\": [\"A\"],\n            \"cred_def_id\": \"&lt;cred_def_id&gt;\",\n            // \"mime-type\": \"&lt;mime-type&gt;\" is missing, so this defaults to a json-formatted string; if it was non-null, 'value' would be interpreted as a base64url-encoded string representing a binary BLOB with mime-type telling how to interpret it after base64url-decoding\n            \"value\": {\n                \"type\": \"string\",\n                \"maxLength\": 9\n            },\n        },\n        {\n            \"type\": \"data\",\n            \"name\": \"account_number\",\n            \"group\": [\"A\"], \n            \"cred_def_id\": \"&lt;cred_def_id&gt;\",\n            \"value\": {\n                \"type\": \"string\",\n                \"value\": \"12345678\"\n        },\n        {\n            \"type\": \"data\",\n            \"name\": \"current_residence_duration\",\n            \"group\": [\"A\"],\n            \"cred_def_id\": \"&lt;cred_def_id&gt;\",\n            \"value\": {\n                \"type\": \"number\",\n                \"maximum\": 150\n            }\n        },\n        {\n            \"type\": \"credential\",\n            \"group\": [\"C\"],\n            \"schema\": \"https://eu.com/claims/IDCard\",\n            \"constraints\": {\n                \"subset\": [\"prop1\", \"prop2.foo.bar\"],\n                \"issuers\": [\"did:foo:gov1\", \"did:bar:gov2\"]\n            }\n        },\n        {\n            \"type\": \"credential\",\n            \"group\": [\"C\"],\n            \"schema\": \"hub://did:foo:123/Collections/schema.us.gov/Passport\",\n            \"constraints\": {\n                \"issuers\": [\"did:foo:gov1\", \"did:bar:gov2\"]\n            }\n\n        },\n        {\n            \"type\": \"credential\",\n            \"group\": [\"B\"],\n            \"schema\": [\"https://claims.linkedin.com/WorkHistory\", \"https://about.me/WorkHistory\"],\n            \"constraints\": {\n                \"issuers\": [\"did:foo:auditor1\", \"did:bar:auditor2\"]\n            }\n        },\n        {\n            \"type\": \"credential\",\n            \"group\": [\"B\"],\n            \"schema\": \"https://claims.fico.org/CreditHistory\",\n            \"constraints\": {\n                \"issuers\": [\"did:foo:bank1\", \"did:bar:bank2\"]\n            }\n        },\n        {\n            \"type\": \"openid\",\n            \"group\": [\"A\"],\n            \"redirect\": \"https://login.microsoftonline.com/oauth/\"\n            \"parameters\": {\n                \"client_id\": \"dhfiuhsdre\",\n                \"scope\": \"openid+profile\"                    \n            }\n        },\n        {\n            \"type\": \"credential\",\n            \"group\": [\"D\"],\n            \"schema\": \"https://some.login.com/someattribute\",\n            \"constraints\": {\n                \"issuers\": [\"did:foo:iss1\", \"did:foo:iss2\"]\n            },\n            \"weight\": 0.8\n        },\n        {\n            \"type\": \"credential\",\n            \"group\": [\"D\"],\n            \"schema\": \"https://some.otherlogin.com/someotherattribute\",\n            \"constraints\": {\n                \"issuers\": [\"did:foox:iss1\", \"did:foox:iss2\"]\n            },\n            \"weight\": 0.2\n        }\n    ],\n    \"predicates\": [\n        {\n            \"name\": \"&lt;attribute_name&gt;\",\n            \"cred_def_id\": \"&lt;cred_def_id&gt;\",\n            \"predicate\": \"&lt;predicate&gt;\",\n            \"threshold\": &lt;threshold&gt;\n        }\n    ]\n}\n</code></pre></p>"},{"location":"features/0347-proof-negotiation/#valid-proof-response-with-attribute-negotiation","title":"Valid Proof Response with attribute negotiation","text":"<p>The following data structure is an example for a valid answer to the above credential request. It contains all attributes from groups A and B as well as one credential from each C and D. Note that the provided credential from Group D is the one weighted 0.2 as the owner did not have or was not willing to provide the one weighted 0.8.</p> <p>Valid proof presentation: <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/proof-presentation\",\n    \"@id\": \"98fd8d82-81a6-4409-acc2-c35ea39d0f28\",\n    \"comment\": \"some comment\",\n    \"presentations~attach\": [\n        {\n            \"@id\": \"libindy-presentation-0\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;yaml-formatted string describing attachments, base64url-encoded because of libindy&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> The base64url-encoded content above would decode to this data: <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/presentation-preview\",\n    \"@context\": \"https://path.to/schemas/credentials\"\n    \"comment\":\"some comment\",\n    \"~thread\": {\n        \"thid\": \"98f38d22-71b6-4449-adc2-c33ea39d1f29\",\n        \"sender_order\": 1,\n        \"received_orders\": {did:sov:abcxyz\":1}\n    }\n    \"credential\":\"proof_response\", // verifiable claims elements\n    \"inputs_provided\": [\n        {\n            \"type\": \"data\",\n            \"field\": \"routing_number\",\n            \"value\": \"123456\"\n        },\n        {\n            \"type\": \"data\",\n            \"field\": \"account_number\",\n            \"value\": \"12345678\"\n        },\n        {\n            \"type\": \"data\",\n            \"field\": \"current_residence_duration\",\n            \"value\": 8\n        },      \n        {\n            \"type\": \"credential\",\n            \"schema\": [\"https://claims.linkedin.com/WorkHistory\", \"https://about.me/WorkHistory\"],\n            \"issuer\": \"did:foo:auditor1\"\n        },\n        {\n            \"type\": \"credential\",\n            \"schema\": \"https://claims.fico.org/CreditHistory\",\n            \"issuer\": \"did:foo:bank1\"\n        },\n        {\n            \"type\": \"openid\",\n            \"redirect\": \"https://login.microsoftonline.com/oauth/\"\n            \"client_id\": \"dhfiuhsdre\",\n            \"profile\": \"...\"\n        },\n        {\n            \"type\": \"credential\",\n            \"schema\": \"https://eu.com/claims/IDCard\"\n            \"issuer\": \"did:foo:gov1\"\n        },\n        {\n        \"type\": \"credential\",\n            \"group\": [\"D\"],\n            \"schema\": \"https://some.otherlogin.com/someotherattribute\",\n            \"issuer\": \"did:foox:iss1\"\n        }\n    ],\n    \"predicates\": [ // empty in this case\n    ]\n}\n</code></pre></p>"},{"location":"features/0347-proof-negotiation/#reference","title":"Reference","text":"<p>The \"@id\"-Tag and thread decorator in the above JSON-messages is taken from RFC 0008.</p>"},{"location":"features/0347-proof-negotiation/#drawbacks","title":"Drawbacks","text":"<p>If a user needs to choose from a list of credentials each time a proof request with a \"pick_one\"-rule is being requested, some users may dislike this, as this process requires a significant amount of user interaction and, thereby, time. This could be mitigated by an 'optional'-rule which requests all of the options the 'pick one'-rule offers. Wallets can then offer two pre-settings: \"privacy first\", which offers as little data and as many interactions with the user as possible, while \"usability first\" automatically selects the 'optional'-rule and sends more data, not asking the user before everytime. The example dialog from the Okuna manifesto referred to before shows a great way to implement this. It offers the user the most privacy-friendly option by default (which is what the GDPR requires) or the prividing of optional data. Futhermore, the optional data can be customized to include or exclude specific data.</p>"},{"location":"features/0347-proof-negotiation/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Not implementing proof negotiation would mean that Aries-based Distributed Ledgers would be limited to a binary yes-or-no approach to authentication and authorization of a user, while this proof negotiation would add flexibility. An alternative way of implementing the proof negotiation is performing it ahead of the proof request in a seperate request and response. The problem with not implementing this feature would be that a proof request may need to be repeated over and over again with a different list of requested attributes each time, until a list is transferred which the specific user can reply to. This process would be unnecessarily complicated and can be facilitated by implementing this here concept.</p>"},{"location":"features/0347-proof-negotiation/#prior-art","title":"Prior art","text":"<p>RFC0037-present-proof is the foundation which this RFC builds on using groups from the credential manifest by  the decentralized identity foundation, a \"format that normalizes the definition of requirements for the issuance of a credential\".</p>"},{"location":"features/0347-proof-negotiation/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>The above proof request includes a schema ID for every credential requests. This was taken from the DID credential manifest. It may make more sense to include a credential definition ID there, as a credential could potentially be built from one credential definition but this credential definition from several schemas.</li> <li>The exact layout and syntax of the proof request above is open to debate, it was designed to stick as close as possible to existing RFCs and ../../concepts.</li> <li>Can this feature be implemented in a way that does not break proof requests from anoncreds version 1.x?</li> <li>Writing this RFC rose the question if the length of a proof request is limited in any way. A JSON-message containing the attributes in the proof can theoretically be infinitely long. Is this being handled in any way? It may lead to overflows at some point.</li> <li>This RFC describes the negotiation of a proof inside the proof request itself. Depending on the functionality around proofs it may be more desirable to implement the proof negotiation as a seperate protocol which is used before the actual proof request.</li> <li>It might be possible to accomplish the goal of this RFC by extending the present-preview message and adding prover functionality that allows the prover to select credentials they have to satisfy the request, just as is done in the proof request/proof process, but with the specific goal of only sending back a proposal, not a proof </li> </ul>"},{"location":"features/0347-proof-negotiation/#implementations","title":"Implementations","text":"Name / Link Implementation Notes"},{"location":"features/0348-transition-msg-type-to-https/","title":"Aries RFC 0348: Transition Message Type to HTTPs","text":"<ul> <li>Authors: Stephen Curran</li> <li>Status: RETIRED</li> <li>Since: 2020-08-26</li> <li>Status Note: In step 2 - community is updating implementations to send new formats. Target Completion Date: 2020.10.15 </li> <li>Supersedes:</li> <li>Start Date: 2019-12-13</li> <li>Tags: feature, community-update</li> </ul>"},{"location":"features/0348-transition-msg-type-to-https/#summary","title":"Summary","text":"<p>Per issue #225, the Aries community has agreed to change the prefix for protocol message types that currently use <code>did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/</code> to use <code>https://didcomm.org/</code>. Examples of the two message types forms are:</p> <ul> <li>Before: <code>did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/notification/1.0/ack</code></li> <li>After: <code>https://didcomm.org/notification/1.0/ack</code></li> </ul> <p>This RFC follows the guidance in RFC 0345 about community-coordinated updates to (try to) ensure that independently deployed, interoperable agents remain interoperable throughout this transition.</p> <p>The transition from the old to new formats will occur in four steps:</p> <ul> <li>DONE Pre-work: where we agree on the transition plan outlined in this RFC.</li> <li>Any RFC updates related to this transition needed before starting the transition are completed.</li> <li> <p>To Do: Identify if there any prerequisite RFC changes to be made.</p> </li> <li>DONE Step 1: Agent builders MUST update all agent code bases and deployments to accept incoming message types in the old (did) and new (https) formats. During this step, agents MUST default to sending out messages in the old format.</li> <li>Each agent builder SHOULD notify the community they have completed Step 1 by submitting a PR to update their entry in the implementations accordingly.</li> <li>IN PROGRESS Step 2: Agent builders MUST update all agent code bases and deployments to send out all messages using the new (https) format. The old (did) format is deprecated but will still be accepted. An agent deployment MAY send out an old format message type upon receipt of a message containing an old format message type.</li> <li>Each agent builder SHOULD notify the community they have completed Step 2 by submitting a PR to update their entry in the implementations accordingly.</li> <li>Step 3: Agent builders SHOULD update their deployments to remove all support for receiving the old format and MUST NOT send out messages using the old message type format.</li> </ul> <p>Note: Any RFCs that already use the new \"https\" message type should continue to use the use new format in all cases\u2014accepting and sending. New protocols defined in new and updated RFCs should use the new \"https\" format.</p> <p>The community coordination triggers between the steps above will be as follows:</p> <ul> <li>Pre-work to Step 1 - a PR to this RFC is merged that sets the RFC status to ACCEPTED.</li> <li>The ACCEPTED version of this RFC is included in the current Aries Interop Profile version.</li> <li>Step 1 to Step 2 - the community agrees that the majority of the deployed agents have completed Step 1. A PR to this RFC is merged that sets the RFC status to ADOPTED.</li> <li>Agent builders indicate completion of Step 1 by updating the Implementations section of this RFC.</li> <li>All other RFCs in this repo are updated to use the new message type format.</li> <li>The ADOPTED version of this RFC is included in the current Aries Interop Profile version.</li> <li>Step 2 to Step 3 - the community agrees that the majority of the deployed agents have completed Step 2. A PR to this RFC is merged that sets the RFC status to RETIRED.</li> <li>Agent builders indicate completion of Step 2 by updating the Implementations section of this RFC.</li> </ul>"},{"location":"features/0348-transition-msg-type-to-https/#motivation","title":"Motivation","text":"<p>To enable agent builders to independently update their code bases and deployed agents while maintaining interoperability.</p>"},{"location":"features/0348-transition-msg-type-to-https/#tutorial","title":"Tutorial","text":"<p>The general mechanism for this type of transition is documented in RFC 0345 about community-coordinated updates.</p> <p>The specific sequence of events to make this particular transition is outlined in the summary section of this RFC.</p>"},{"location":"features/0348-transition-msg-type-to-https/#reference","title":"Reference","text":"<p>See the summary section of this RFC for the details of this transition.</p>"},{"location":"features/0348-transition-msg-type-to-https/#drawbacks","title":"Drawbacks","text":"<p>None identified.</p>"},{"location":"features/0348-transition-msg-type-to-https/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>This approach balances the speed of adoption with the need for independent deployment and interoperability.</p>"},{"location":"features/0348-transition-msg-type-to-https/#prior-art","title":"Prior art","text":"<p>The approach outlined in RFC 0345 about community-coordinated updates is a well-known pattern for using deprecation to make breaking changes in an ecosystem. That said, this is the first attempt to use this approach in Aries. Adjustments to the transition plan will be made as needed, and RFC 0345 will be updated based on lessons learned in executing this plan.</p>"},{"location":"features/0348-transition-msg-type-to-https/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Are any changes to existing RFCs needed before starting Step 1?</li> </ul>"},{"location":"features/0348-transition-msg-type-to-https/#implementations","title":"Implementations","text":"<p>The following table lists the status of various agent code bases and deployments with respect to the steps of this transition. Agent builders MUST update this table as they complete steps of the transition.</p> Name / Link Implementation Notes Aries Protocol Test Suite No steps completed Aries Toolbox Completed Step 1 code change. Aries Framework - .NET Completed Step 1 code change Trinsic.id No steps completed Aries Cloud Agent - Python Completed Step 1 code change Aries Static Agent - Python No steps completed Aries Framework - Go Completed Step 2 Connect.Me No steps completed Verity No steps completed Pico Labs Completed Step 2 even though deprecated IBM Completed Step 1 code change IBM Agent Completed Step 1 Aries Cloud Agent - Pico Completed Step 2 code change Aries Framework JavaScript Completed Step 2 code change"},{"location":"features/0351-purpose-decorator/","title":"Aries RFC 0351: Purpose Decorator","text":"<ul> <li>Authors: Filip Burlacu</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes:</li> <li>Start Date: 2019-12-05</li> <li>Tags: feature, decorator</li> </ul>"},{"location":"features/0351-purpose-decorator/#summary","title":"Summary","text":"<p>This RFC allows Aries agents to serve as mediators or relays for applications that don't use DIDComm. It introduces: - A new decorator, the <code>~purpose</code> decorator, which defines the intent, usage, or contents of a message - A means for a recipient, who is not DIDComm-enabled, to register with an agent for messages with a particular purpose - A means for a sender, who is not DIDComm-enabled, to send messages with a given purpose through its agent to a target agent - Guidance for creating a protocol which uses the <code>~purpose</code> decorator to relay messages over DIDComm for non-DIDComm applications</p>"},{"location":"features/0351-purpose-decorator/#motivation","title":"Motivation","text":"<p>This specification allows applications that aren't Aries agents to communicate JSON messages over DIDComm using Aries agents analogously to mediators. Any agent which implements this protocol can relay arbitrary new types of message for clients - without having to be updated and redeployed.</p> <p>The purpose decorator can be used to implement client interfaces for Aries agents. For example: - A client application built using an Aries framework can use the purpose decorator for client-level messaging and protocols - Multiple client applications can connect to an agent, for example to process different types of messages, or to log for auditing purposes - A server with a remote API can include an Aries agent using the purpose decorator to provide a remote API over DIDComm - Multiple client applications can use a single agent to perform transactions on the agent owner's identity</p>"},{"location":"features/0351-purpose-decorator/#tutorial","title":"Tutorial","text":"<p>This RFC assumes familiarity with mediators and relays, attachments, and message threading.</p>"},{"location":"features/0351-purpose-decorator/#the-purpose-decorator","title":"The <code>~purpose</code> Decorator","text":"<p>The <code>~purpose</code> decorator is a JSON array which describes the semantics of a message - the role it plays within a protocol implemented using this RFC, for example, or the meaning of the data contained within. The purpose is the mechanism for determining which recipient(s) should be sent a message.</p> <p>Example: <code>\"~purpose\": [\"team:01453\", \"delivery\", \"geotag\", \"cred\"]</code></p> <p>Each element of the purpose array is a string. An agent provides some means for recipients to register on a purpose, or class of purposes, by indicating the particular string values they are interested in.</p> <p>The particular registration semantics are TBD. Some possible formats include: - A tagging system, where if a recipient registers on a list <code>\"foo\", \"bar\"</code>, it will be forwarded messages with purposes <code>[\"foo\", \"quux\"]</code> and <code>[\"baz\", \"bar\"]</code> - A hierarchical system, where if a recipient registers on a list <code>\"foo\", \"bar\"</code>, it will receive any message with purpose <code>[\"foo\", \"bar\", ...]</code> but not <code>[\"foo\", \"baz\", ...]</code> or <code>[\"baz\", \"foo\", \"bar\", ...]</code> - A hierarchical system with wildcards: <code>\"*\", \"foo\"</code> might match any message with purpose <code>[..., \"foo\", ...]</code></p>"},{"location":"features/0351-purpose-decorator/#handling-multiple-listeners","title":"Handling Multiple Listeners","text":""},{"location":"features/0351-purpose-decorator/#priority","title":"Priority","text":"<p>When multiple applications register for overlapping purposes, the agent needs a means to determine which application should receive the message, or which should receive it first. When an application registers on a purpose, it should set an integer priority. When the agent receives a message, it compares the priority of all matching listeners, choosing the lowest number value.</p>"},{"location":"features/0351-purpose-decorator/#fall-through","title":"Fall-Through","text":"<p>In some cases, an application that received a message can allow other listeners to process after it. In these cases, when the application is handling the message, it can indicate to the agent that it can fall-through, in which case the agent will provide the message to the next listener.</p> <p>Optionally, agents can support an always-falls-through configuration, for applications which:  - Will always fall through on the messages they receive, and  - Can always safely process concurrently with subsequent applications handling the same message.</p> <p>This allows the agent to send the message to such listeners concurrently with the next highest-priority listener that does not always-fall-through.</p>"},{"location":"features/0351-purpose-decorator/#example-protocol","title":"Example Protocol","text":"<p>This is an example protocol which makes use of the <code>~purpose</code> decorator and other Aries ../../concepts to provide a message format that can carry arbitrary payloads for non-DIDComm edge applications.</p>"},{"location":"features/0351-purpose-decorator/#key-concepts","title":"Key Concepts","text":"<p>This RFC allows messages to be sent over DIDComm by applications that are not DIDComm-enabled, by using Aries agents as intermediaries. Both the sender and the recipient can be non-DIDComm applications.</p>"},{"location":"features/0351-purpose-decorator/#non-didcomm-sender","title":"Non-DIDComm Sender","text":"<p>If the sender of the message is not a DIDComm-enabled agent, then it must rely on an agent as a trusted intermediary. This agent is assumed to have configured settings for message timing, communication endpoints, etc. </p> <ol> <li>The sender constructs a JSON message, and provides this to its agent, alongside specifying the purpose, and likely some indication of the destination of the message.</li> <li>The agent determines the recipient agent - this could be by logic, for example, based on the purpose decorator, or a DID specified by the sender.</li> <li>The agent wraps the sender's message and purpose in a DIDComm message, and sends it to the recipient agent.</li> </ol>"},{"location":"features/0351-purpose-decorator/#non-didcomm-recipient","title":"Non-DIDComm Recipient","text":"<p>A non-DIDComm recipient relies on trusted agents to relay messages to it, and can register with any number of agents for any number of purposes.</p> <ol> <li>The recipient registers with a trusted agent on certain purpose values.</li> <li>The agent receives a DIDComm message, and sees it has a purpose decorator.</li> <li>The agent looks through its recipient registry for all recipients which registered on a matching purpose.</li> <li>The Agent reverses the wrapping done by the sender agent, and forwards the wrapped message to all matching registered recipients.</li> </ol>"},{"location":"features/0351-purpose-decorator/#message-format","title":"Message Format","text":"<p>A DIDComm message, for a protocol implemented using this RFC, requires:  - A means to wrap the payload message  - A <code>~purpose</code> decorator</p> <p>This example protocol wraps the message within the <code>data</code> field. </p> <pre><code>{\n  \"@id\": \"123456789\",\n  \"@type\": \"https://example.org/didcomm-message\",\n  \"~purpose\": [],\n  \"data\" : {}\n}\n</code></pre> <p>For example: <pre><code>{\n  \"@id\": \"123456789\",\n  \"@type\": \"https://example.org/didcomm-message\",\n  \"~purpose\": [\"metrics\", \"latency\"],\n  \"data\": {\"mean\": 346457, \"median\": 2344}\n}\n</code></pre></p>"},{"location":"features/0351-purpose-decorator/#reference","title":"Reference","text":"<p>This section provides guidance for implementing protocols using this decorator.</p>"},{"location":"features/0351-purpose-decorator/#threading-timing","title":"Threading &amp; Timing","text":"<p>If a protocol implemented using this RFC requires back and forth communication, use the <code>~thread</code> decorator and transport return routing. This allows the recipient's agent to relay replies from the recipient to the sender.</p> <p>For senders and recipients that aren't aries agents, their respective agent must maintain context to correlate the DIDComm message thread, and the message thread of the communication protocol with the non-DIDComm application.</p> <p>If a message is threaded, it can be useful to include a <code>~timing</code> decorator for timing information. The sender's agent can construct this decorator from timing parameters (eg, timeout) in the communication channel with the sender, or have preconfigured settings.</p>"},{"location":"features/0351-purpose-decorator/#communication-with-non-didcomm-edge-applications","title":"Communication with Non-DIDComm Edge Applications","text":"<p>An organization using agents to relay messages for non-DIDComm edge applications is expected to secure the connections between their relay agents and their non-DIDComm edge applications. For example, running the agent as a service in the same container. If it is necessary for the organization to have a separate endpoint or mediator agent, it is recommended to have a thin relay agent as close as possible to the edge application, so internal messages sent to the mediator are also secured by DIDComm.</p>"},{"location":"features/0351-purpose-decorator/#drawbacks","title":"Drawbacks","text":"<p>TODO</p>"},{"location":"features/0351-purpose-decorator/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Alternative: defining a standard protocol for wrapping messages sent or received by non-DIDComm applications. This was the original design, but we've moved away from it because it was an unnecessary layer of specification, since custom protocols can use their own <code>@type</code> strings to specify their message formats, instead of using a two-layer system of <code>@type</code> and <code>data-type</code>.</li> </ul>"},{"location":"features/0351-purpose-decorator/#prior-art","title":"Prior art","text":"<ul> <li>The DIF Identity Hub has a mechanism for sending objects with semantic descriptors to identities, whereas this RFC defines a method whereby agents can transact the sending and receiving of such objects on behalf of their non-aries edge apps.</li> <li>Compare against the basic-message protocol, which uses aries agents as relays for person-person (or machine-person) communication. In contrast, this protocol uses aries agents as relays for machine-machine communication.</li> <li>The purpose decorator (as opposed to type enforcement like MIME) is similar to Intents in Android development.</li> <li>The hierarchical example for the purpose decorator is similar to Topics in MQTT.</li> </ul>"},{"location":"features/0351-purpose-decorator/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>We need to define the semantics of the purpose decorator - the examples provided above are potential directions the standard can go.</li> <li>Are there further semantics to define in this RFC rather than leave for specific implementations?</li> </ul>"},{"location":"features/0351-purpose-decorator/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0360-use-did-key/","title":"Aries RFC 0360: did:key Usage","text":"<ul> <li>Authors: Tobias Looker, Stephen Curran</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Referenced in a number of Aries RFCs and formalized as part of AIP 2.0 did:key method is a W3C CCG work item</li> <li>Start Date: 2019-12-17</li> <li>Tags: feature</li> </ul>"},{"location":"features/0360-use-did-key/#summary","title":"Summary","text":"<p>A number of RFCs that have been defined reference what amounts to a \"naked\" public key, such that the sender relies on the receiver knowing what type the key is and how it can be used. The application of this RFC will result in the replacement of \"naked\" verkeys (public keys) in some DIDComm/Aries protocols with the did:key ledgerless DID method, a format that concisely conveys useful information about the use of the key, including the public key type. While <code>did:key</code> is less a DID method than a transformation from a public key and type to an opinionated DIDDoc, it provides a versioning mechanism for supporting new/different cryptographic formats and its use makes clear how a public key is intended to be used. The method also enables support for using standard DID resolution mechanisms that may simplify the use of the key. The use of a DID to represent a public key is seen as odd by some in the community. Should a representation be found that is has better properties than a plain public key but is constrained to being \"just a key\", then we will consider changing from the <code>did:key</code> representation.</p> <p>To Do: Update link DID Key Method link (above) from Digital Bazaar to W3C repositories when they are created and populated.</p> <p>While it is well known in the Aries community that <code>did:key</code> is fundamentally different from the did:peer method that is the basis of Aries protocols, it must be re-emphasized here. This RFC does NOT imply any changes to the use of <code>did:peer</code> in Aries, nor does it change the content of a <code>did:peer</code> DIDDoc. This RFC only changes references to plain public keys in the JSON of some RFCs to use <code>did:key</code> in place of a plain text string.</p> <p>Should this RFC be ACCEPTED, a community coordinated update will be used to apply updates to the agent code bases and impacted RFCs.</p>"},{"location":"features/0360-use-did-key/#motivation","title":"Motivation","text":"<p>When one Aries agent inserts a public key into the JSON of an Aries message (for example, the <code>~service</code> decorator), it assumes that the recipient agent will use the key in the intended way. At the time this RFC is being written, this is easy because only one key type is in use by all agents. However, in order to enable the use of different cryptography algorithms, the public references must be extended to at least include the key type. The preferred and concise way to do that is the use of the multicodec mechanism, which provides a registry of encodings for known key types that are prefixed to the public key in a standard and concise way. did:key extends that mechanism by providing a templated way to transform the combination of public key and key type into a DID-standard DIDDoc.</p> <p>At the cost of adding/building a did:key resolver we get a DID standard way to access the key and key type, including specific information on how the key can be used. The resolver may be trivial or complex. In a trivial version, the key type is assumed, and the key can be easily extracted from the string. In a more complete implementation, the key type can be checked, and standard DID URL handling can be used to extract parts of the DIDDoc for specific purposes. For example, in the ed25519 <code>did:key</code> DIDDoc, the existence of the <code>keyAgreement</code> entry implies that the key can be used in a Diffie-Hellman exchange, without the developer guessing, or using the key incorrectly.</p> <p>Note that simply knowing the key type is not necessarily sufficient to be able to use the key. The cryptography supporting the processing data using the key must also be available in the agent. However, the multicodec and did:key capabilities will simplify adding support for new key types in the future.</p>"},{"location":"features/0360-use-did-key/#tutorial","title":"Tutorial","text":"<p>An example of the use of the replacement of a verkey with <code>did:key</code> can be found in the ~service decorator RFC. Notably in the example at the beginning of the tutorial section, the verkeys in the <code>recipientKeys</code> and <code>routingKeys</code> items would be changed from native keys to use <code>did:key</code> as follows:</p> <pre><code>{\n    \"@type\": \"somemessagetype\",\n    \"~service\": {\n        \"recipientKeys\": [\"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"],\n        \"routingKeys\": [\"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"]\n        \"serviceEndpoint\": \"https://example.com/endpoint\"\n    }\n}\n</code></pre> <p>Thus, <code>8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K</code> becomes <code>did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th</code> using the following transformations:</p> <ul> <li>Start with the original (presumably) base58 ed25519 public key</li> <li>Since we have only a naked public key, we must assume the format</li> <li>Base58 decode the public key to get the hex version</li> <li>Multicodec: Prefix with the unsigned varint of the algorithm type. In this case, that means prefixing the string with <code>unsigned_varint(0xed)</code> (which is <code>0xed 0x01</code>) for the key type of ed25519,</li> <li>the <code>0xed</code> is per the multicodec table (search for  <code>ed25519</code>).</li> <li>Note that unsigned varint handling varies by key type prefix, so don't just assume the same handling (e.g. <code>code+0x01</code>) for other key type prefixes. For a broader discussion of this see this issue comment in the <code>did:key</code> repo.</li> <li>Multibase: Base58 encode the result and prefix that with \"z\" to indicate base58 encoding</li> <li>DID: Prefix that with the DID Method prefix <code>did:key:</code></li> </ul> <p>The transformation above is only for illustration within this RFC. The <code>did:key</code> specification is the definitive source for the appropriate transformations.</p> <p>The <code>did:key</code> method uses the strings that are the DID, public key and key type to construct (\"resolve\") a DIDDoc based on a template defined by the <code>did:key</code> specification. Further, the <code>did:key</code> resolver generates, in the case of an ed25519 public signing key, a key that can be used as part of a Diffie-Hellman exchange appropriate for encryption in the <code>keyAgreement</code> section of the DIDDoc. Presumably, as the <code>did:key</code> method supports other key types, similar DIDDoc templates will become part of the specification. Key types that don't support a signing/key exchange transformation would not have a <code>keyAgreement</code> entry in the resolved DIDDoc.</p> <p>The following currently implemented RFCs would be affected by acceptance of this RFC. In these RFCs, the JSON items that currently contain naked public keys (mostly the items <code>recipientKeys</code> and <code>routingKeys</code>) would be changed to use <code>did:key</code> references where applicable. Note that in these items public DIDs could also be used if applicable for a given use case.</p> <ul> <li>0023-did-exchange - Invitation Message</li> <li>0028-introduce</li> <li>0056-service-decorator</li> <li>0160-connection-protocol</li> <li>0434-out-of-band-protocols</li> <li>0211-mediator-coordination-protocol</li> </ul> <p>Service entries in <code>did:peer</code> DIDDocs (such as in RFCs 0094-cross-domain-messaging and 0067-didcomm-diddoc-conventions) should NOT use a <code>did:key</code> public key representation. Instead, service entries in the DIDDoc should reference keys defined internally in the DIDDoc where appropriate.</p> <p>To Do: Discuss the use of <code>did:key</code> (or not) in the context of encryption envelopes. This will be part of the ongoing discussion about JWEs and the upcoming discussions about JWMs\u2014a soon-to-be-proposed specification. That conversation will likely go on in the DIF DIDComm Working Group.</p>"},{"location":"features/0360-use-did-key/#reference","title":"Reference","text":"<p>See the <code>did:key</code> specification. Note that the specification is still evolving.</p>"},{"location":"features/0360-use-did-key/#drawbacks","title":"Drawbacks","text":"<p>The <code>did:key</code> standard is not finalized.</p> <p>The DIDDoc \"resolved\" from a <code>did:key</code> probably has more entries in it than are needed for DIDComm. That said, the entries in the DIDDoc make it clear to a developer how they can use the public key.</p>"},{"location":"features/0360-use-did-key/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>We should not stick with the status quo and assume that all agents will always know the type of keys being used and how to use them.</p> <p>We should at minimum move to a scheme like multicodecs such that the key is self documenting and supports the versioning of cryptographic algorithms. However, even if we do that, we still have to document for developers how they should (and not should not) use the public key.</p> <p>Another logical alternative is to use a JWK. However, that representation only adds the type of the key (same as multicodecs) at the cost of being significantly more verbose.</p>"},{"location":"features/0360-use-did-key/#prior-art","title":"Prior art","text":"<p>To do - there are other instances of this pattern being used. Insert those here.</p>"},{"location":"features/0360-use-did-key/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>How to transition to the use of <code>did:key</code>.</li> <li>What will the initial accepted version of <code>did:key</code> look like?  It's probably close to its final form, with an expected resolution of the open question of what  a DIDDoc looks like if the key type is not ed25519.</li> </ul>"},{"location":"features/0360-use-did-key/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes</p> Name / Link Implementation Notes"},{"location":"features/0418-rich-schema-encoding/","title":"Aries RFC 0418: Aries Rich Schema Encoding Objects","text":"<ul> <li>Author: Ken Ebert, Mike Lodder, Brent Zundel, Alexander Shcherbakov</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes:</li> <li>Start Date: 2019-03-19</li> <li>Tags: feature, rich-schemas</li> </ul>"},{"location":"features/0418-rich-schema-encoding/#summary","title":"Summary","text":"<p>The introduction of rich schemas and their associated greater range of possible attribute value data types require correspondingly rich transformation algorithms. The purpose of the new encoding object is to specify the algorithm used to perform transformations of each attribute value data type into a canonical data encoding in a deterministic way. </p> <p>The initial use for these will be the transformation of attribute value data into 256-bit integers so that they can be incorporated into the anonymous credential signature schemes we use. The transformation algorithms will also allow for extending the cryptographic schemes and various sizes of canonical data encodings (256-bit, 384-bit, etc.). The transformation algorithms will allow for broader use of predicate proofs, and avoid hashed values as much as possible, as they do not support predicate proofs.</p> <p>Encoding objects are processed in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0418-rich-schema-encoding/#motivation","title":"Motivation","text":"<p>All attribute values to be signed in anonymous credentials must be transformed into 256-bit integers in order to support the  [Camenisch-Lysyanskaya signature][CL-signatures] scheme.</p> <p>The current methods for creating a credential only accept attributes which are encoded as 256-bit integers. The current possible source attribute types are integers and strings. No configuration method exists at this time to specify which transformation method will be applied to a particular attribute. All encoded attribute values rely on an implicit understanding of how they were encoded.</p> <p>The current set of canonical encodings consists of integers and hashed strings. The introduction of encoding objects allows for a means of extending the current set of canonical encodings to include integer representations of dates, lengths, boolean values, and floating point numbers. All encoding objects describe how an input is transformed into an encoding of an attribute value according to the transformation algorithm selected by the issuer.</p>"},{"location":"features/0418-rich-schema-encoding/#tutorial","title":"Tutorial","text":""},{"location":"features/0418-rich-schema-encoding/#intro-to-encoding-objects","title":"Intro to Encoding Objects","text":"<p>Encoding objects are JSON objects that describe the input types, transformation algorithms, and output encodings. The encoding object is stored on the ledger.</p>"},{"location":"features/0418-rich-schema-encoding/#properties","title":"Properties","text":"<p>Encoding's properties follow the generic template defined in  Rich Schema Common.</p> <p>Encoding's <code>content</code> field is a JSON-serialized string with the following fields:</p> <ul> <li><code>input</code>: a description of the input value.</li> <li><code>output</code>: a description of the output value.</li> <li><code>algorithm</code>:</li> <li><code>documentation</code>: a URL which references a specific github commit of   the documentation that fully describes the transformation algorithm.</li> <li><code>implementation</code>: a URL that links to a reference implementation of the   transformation algorithm. It is not necessary to use the implementation   linked to here, as long as the implementation used implements the same   transformation algorithm.</li> <li><code>description</code>: a brief description of the transformation algorithm.</li> <li><code>testVectors</code>: a URL which references a specific github commit of a selection of test vectors that may be used to provide assurance that a transformation algorithm implementation is correct. </li> </ul>"},{"location":"features/0418-rich-schema-encoding/#example-encoding","title":"Example Encoding","text":"<p>An example of the <code>content</code> field of an Encoding object: <pre><code>{\n    \"input\": {\n        \"id\": \"DateRFC3339\",\n        \"type\": \"string\"\n    },\n    \"output\": {\n        \"id\": \"UnixTime\",\n        \"type\": \"256-bit integer\"\n    },\n    \"algorithm\": {\n        \"description\": \"This encoding transforms an\n            RFC3339-formatted datetime object into the number\n            of seconds since January 1, 1970 (the Unix epoch).\",\n        \"documentation\": URL to specific github commit,\n        \"implementation\": URL to implementation\n    },\n    \"testVectors\": URL to specific github commit\n}\n</code></pre></p>"},{"location":"features/0418-rich-schema-encoding/#transformation-algorithms","title":"Transformation Algorithms","text":"<p>The purpose of a transformation algorithm is to deterministically convert a value into a different encoding. For example, an attribute value may be a string representation of a date, but the CL-signature signing mechanism requires all inputs to be 256-bit integers. The transformation algorithm takes this string value as input, parses it, and encodes it as a 256-bit integer.  </p> <p>It is anticipated that the encodings used for CL signatures and their associated transformation algorithms will be used primarily by two entities. First, the issuer will use the transformation algorithm to prepare credential values for signing. Second, the verifier will use the transformation algorithm to verify that revealed values were correctly encoded and signed, and to properly transform values against which predicates may be evaluated.</p>"},{"location":"features/0418-rich-schema-encoding/#integer-representation","title":"Integer Representation","text":"<p>In order to properly encode values as integers for use in predicate proofs, a common 256-bit integer representation is needed. Predicate proofs are kept simple by requiring all inputs to be represented as positive integers. To accomplish this, we introduce a zero-offset and map all integer results onto a range from 9 to 2<sup>256</sup> - 10. The zero point in this range is 2<sup>255</sup>. </p> <p>Any transformation algorithm which outputs an integer value should use this representation.</p>"},{"location":"features/0418-rich-schema-encoding/#floating-point-representation","title":"Floating Point Representation","text":"<p>In order to retain the provided precision of floating point values, we use Q number format, a binary, fixed-point number format. We use 64 fractional bits.</p>"},{"location":"features/0418-rich-schema-encoding/#reserved-values","title":"Reserved Values","text":"<p>For integer and floating point representations, there are some reserved numeric strings which have a special meaning.</p> Special Value Representation Description -\u221e 8 The largest negative number.Always less than any other valid integer. \u221e 2<sup>256</sup> - 9 The largest positive number.Always greater than any other valid integer. NULL 7 Indicates that the value of a field is not supplied.Not a valid value for comparisons. NaN 2<sup>256</sup> - 8 Floating point NaN.Not a valid value for comparisons. reserved 1 to 6 Reserved for future use. reserved 2<sup>256</sup> - 7 to 2<sup>256</sup> - 1 Reserved for future use."},{"location":"features/0418-rich-schema-encoding/#documentation","title":"Documentation","text":"<p>The value of the documentation field is intended to be a URL which, when dereferenced, will provide specific information about the transformation algorithm such that it may be implemented. We recommend that the URL reference some immutable content, such as a specific github commit, an IPFS file, etc.</p>"},{"location":"features/0418-rich-schema-encoding/#implementation","title":"Implementation","text":"<p>The value of the implementation field is intended to be a URL which, when dereferenced, will provide a reference implementation of the transformation algorithm.</p>"},{"location":"features/0418-rich-schema-encoding/#test-vectors","title":"Test Vectors","text":"<p>Test vectors are very important. Although not comprehensive, a set of public test vectors allows for multiple implementations to verify adherence to the transformation algorithm for the set. Test vectors should consist of a set of comma-separated input/output pairs. The input values should be read from the file as strings. The output values should be byte strings encoded as hex values.</p> <p>The value of the test_vectors field is intended to be a URL which, when dereferenced, will provide the file of test vectors. We recommend that the URL reference some immutable content, such as a specific github commit, an IPFS file, etc.</p>"},{"location":"features/0418-rich-schema-encoding/#data-registry-storage","title":"Data Registry Storage","text":"<p>Aries will provide a means for writing contexts to and reading contexts from a verifiable data registry (such as a distributed ledger).</p> <p>An Encoding object will be written to the ledger in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0418-rich-schema-encoding/#aries-data-registry-interface","title":"Aries Data Registry Interface","text":"<p>Aries Data Registry Interface methods for adding and retrieving an Encoding object from the ledger comply with the generic approach described in Rich Schema Objects Common.</p> <p>This means the following methods can be used: - <code>write_rich_schema_object</code> - <code>read_rich_schema_object_by_id</code> - <code>read_rich_schema_object_by_metadata</code></p>"},{"location":"features/0418-rich-schema-encoding/#reference","title":"Reference","text":"<p>The following is a  reference implementation of various transformation algorithms.</p> <p>Here is the paper that defines Camenisch-Lysyanskaya signatures.</p> <ul> <li>0250: Rich Schema Objects</li> <li>0420: Rich Schema Objects Common </li> </ul>"},{"location":"features/0418-rich-schema-encoding/#drawbacks","title":"Drawbacks","text":"<p>This increases the complexity of issuing verifiable credentials and verifiying the accompanying verifiable presentations. </p>"},{"location":"features/0418-rich-schema-encoding/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Encoding attribute values as integers is already part of using anonymous credentials, however the current method is implicit, and relies on use of a common implementation library for uniformity. If we do not include encodings as part of the Rich Schema effort, we will be left with an incomplete set of possible predicates, a lack of explicit mechanisms for issuers to specify which encoding methods they used, and a corresponding lack of verifiablity of signed attribute values.</p> <p>In another design that was considered, the encoding on the ledger was actually a function an end user could call, with the ledger nodes performing the transformation algorithm and returning the encoded value. The benefit of such a design would have been the guarantee of uniformity across encoded values. This design was rejected because of the unfeasibility of using the ledger nodes for such calculations and the privacy implications of submitting attribute values to a public ledger.</p>"},{"location":"features/0418-rich-schema-encoding/#prior-art","title":"Prior art","text":"<p>A description of a prior effort to add encodings to Indy may be found in this jira ticket and  pull request.</p> <p>What the prior effort lacked was a corresponding enhancement of schema infrastructure which would have provided the necessary typing of attribute values.</p>"},{"location":"features/0418-rich-schema-encoding/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the proposed interface generic enough to support other data registries?</li> <li>We are not defining Rich Schema objects as DID DOCs for now. We may re-consider this in future once DID DOC format is finalized.</li> <li>It may make sense to extend DID specification to include using DID for referencing Rich Schema objects.</li> <li>The proposed canonicalization form of a content to be used for DID's id-string generation is in a Draft version, so we  may find a better way to do it.</li> </ul>"},{"location":"features/0418-rich-schema-encoding/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0428-prepare-issue-rich-credential/","title":"0428: Prerequisites to Issue Rich Credential","text":"<ul> <li>Authors: Brent Zundel, Ken Ebert</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes: </li> <li>Start Date: 2020-02-19 </li> <li>Tags: feature, rich-schemas</li> </ul>"},{"location":"features/0428-prepare-issue-rich-credential/#summary","title":"Summary","text":"<p>Describes the prerequisites an issuer must ensure are in place before issuing a rich credential.</p>"},{"location":"features/0428-prepare-issue-rich-credential/#motivation","title":"Motivation","text":"<p>To inform issuers of the steps they should take in order to make sure they have the necessary rich schema objects in place before they use them to issue credentials.</p>"},{"location":"features/0428-prepare-issue-rich-credential/#tutorial","title":"Tutorial","text":""},{"location":"features/0428-prepare-issue-rich-credential/#rich-schema-credential-workflow","title":"Rich Schema Credential Workflow","text":"<ol> <li>The issuer checks the ledger to see if the credential definition he wants to use is already present.</li> <li>If not, the issuer checks the ledger to see if the mapping he wants to use    is already present.<ol> <li>If not, the issuer checks the ledger to see if the schemas he wants to   use are already present.<ol> <li>If not, anchor the context used by each schema to the ledger.</li> <li>Anchor the schemas on the ledger. Schema objects may refer to one or  more context objects.</li> </ol> </li> <li>Anchor to the ledger the mapping object that associates each claim with   one or more encoding objects and a corresponding attribute. (The issuer   selects schema properties and associated encodings to be included as   claims in the credential. Encoding objects refer to transformation   algorithms, documentation, and code which implements the transformation.   The claim is the data; the attribute is the transformed data represented   as a 256 bit integer that is signed. The mapping object refers to the   schema objects and encoding objects.)</li> </ol> </li> <li>Anchor a credential definition that refers to a single mapping object. The    credential definition contains public keys for each attribute. The credential    definition refers to the issuer DID.</li> <li>Using the credential definition, mapping, and schema(s) issue to the holder a credential based on the credential definition and the supplied claim data. The Issue Credential Protocol 1.0 will be the model for another RFC containing minor modifications to issue a credential using the new rich schema objects. </li> </ol> <p>Subsequent credentials may be issued by repeating only the last step.</p> <p></p>"},{"location":"features/0428-prepare-issue-rich-credential/#reference","title":"Reference","text":"<ul> <li>RFC 0250: Rich Schema Objects</li> <li>RFC 0420: Rich Schema Objects Common</li> <li>RFC 0249: Aries Rich Schema Contexts</li> <li>RFC 0281: Aries Rich Schemas</li> <li>RFC XXXX: Aries Rich Schema Mappings</li> <li>RFC XXXX: Aries Rich Schema Credential Definitions</li> <li>RFC 0036: Issue Credential Protocol 1.0</li> </ul>"},{"location":"features/0428-prepare-issue-rich-credential/#unresolved-questions","title":"Unresolved questions","text":"<p>RFCs for Rich Schema Mappings and Rich Schema Credential Definitions are  incomplete.</p>"},{"location":"features/0428-prepare-issue-rich-credential/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0429-prepare-req-rich-pres/","title":"0429: Prerequisites to Request Rich Presentation","text":"<ul> <li>Authors: Brent Zundel, Ken Ebert</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes: </li> <li>Start Date: 2020-02-19 </li> <li>Tags: feature, rich-schemas</li> </ul>"},{"location":"features/0429-prepare-req-rich-pres/#summary","title":"Summary","text":"<p>Describes the prerequisites a verifier must ensure are in place before requesting a rich presentation.</p>"},{"location":"features/0429-prepare-req-rich-pres/#motivation","title":"Motivation","text":"<p>To inform verifiers of the steps they should take in order to make sure they have the necessary rich schema objects in place before they use them to request proofs.</p>"},{"location":"features/0429-prepare-req-rich-pres/#tutorial","title":"Tutorial","text":""},{"location":"features/0429-prepare-req-rich-pres/#rich-schema-presentation-definition-workflow","title":"Rich Schema Presentation Definition Workflow","text":"<ol> <li>The verifier checks his wallet or the ledger to see if the presentation definition already exists. (The verifier determines which attribute or predicates he needs a holder to present to satisfy the verifier's business rules. Presentation definitions specify desired attributes and predicates).</li> <li>If not, the verifier creates a new presentation definition and stores the    presentation definition in his wallet locally and, optionally, anchors it to    the verifiable data registry. (Anchoring the presentation definition to the    verifiable data registry allows other verifiers to easily use it. It can be done by writing the full presentation definition's content to the ledger, or just writing a digital fingerprint/hash of the content.)</li> <li>Using the presentation definition, request a presentation from the holder. The Present Proof Protocol 1.0 will be the model for another RFC containing minor modifications for presenting a proof based on verifiable credentials using the new rich schema objects.</li> </ol>"},{"location":"features/0429-prepare-req-rich-pres/#reference","title":"Reference","text":"<ul> <li>RFC 0250: Rich Schema Objects</li> <li>RFC 0420: Rich Schema Objects Common</li> <li>RFC XXXX: Aries Rich Schema Presentation Definitions</li> <li>RFC 0037: Present Proof Protocol 1.0</li> </ul>"},{"location":"features/0429-prepare-req-rich-pres/#unresolved-questions","title":"Unresolved questions","text":"<p>The RFC for Rich Schema Presentation Definitions is incomplete.</p>"},{"location":"features/0429-prepare-req-rich-pres/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0434-outofband/","title":"Aries RFC 0434: Out-of-Band Protocol 1.1","text":"<ul> <li>Authors: Ryan West, Daniel Bluhm, Matthew Hailstone, Stephen Curran, Sam Curren, George Aristy</li> <li>Status: ADOPTED</li> <li>Since: 2020-03-01</li> <li>Status Note: This RFC extracts the <code>invitation</code> messages from the DID Exchange protocol (and perhaps Connection), and replaces the combined <code>present_proof/1.0/request</code> combined with the <code>~service</code> decorator to define an ephemeral (connection-less) challenge.</li> <li>Supersedes: Invitation Message in 0160-Connections and Invitation Message in 0023-DID-Exchange.</li> <li>Start Date: 2020-03-01</li> <li>Tags: feature, protocol, test-anomaly</li> <li>URI: <code>https://didcomm.org/out-of-band/%VER</code></li> </ul>"},{"location":"features/0434-outofband/#summary","title":"Summary","text":"<p>The Out-of-band protocol is used when you wish to engage with another agent and you don't have a DIDComm connection to use for the interaction.</p>"},{"location":"features/0434-outofband/#motivation","title":"Motivation","text":"<p>The use of the <code>invitation</code> in the Connection and DID Exchange protocols has been relatively successful, but has some shortcomings, as follows.</p>"},{"location":"features/0434-outofband/#connection-reuse","title":"Connection Reuse","text":"<p>A common pattern we have seen in the early days of Aries agents is a user with a browser getting to a point where a connection is needed between the website's (enterprise) agent and the user's mobile agent. A QR invitation is displayed, scanned and a protocol is executed to establish a connection. Life is good!</p> <p>However, with the current invitation processes, when the same user returns to the same page, the same process is executed (QR code, scan, etc.) and a new connection is created between the two agents. There is no way for the user's agent to say \"Hey, I've already got a connection with you. Let's use that one!\"</p> <p>We need the ability to reuse a connection.</p>"},{"location":"features/0434-outofband/#connection-establishment-versioning","title":"Connection Establishment Versioning","text":"<p>In the existing Connections and DID Exchange <code>invitation</code> handling, the inviter dictates what connection establishment protocol all invitee's will use. A more sustainable approach is for the inviter to offer the invitee a list of supported protocols and allow the invitee to use one that it supports.</p>"},{"location":"features/0434-outofband/#handling-of-all-out-of-band-messages","title":"Handling of all Out-of-Band Messages","text":"<p>We currently have two sets of out-of-band messages that cannot be delivered via DIDComm because there is no channel. We'd like to align those messages into a single \"out-of-band\" protocol so that their handling can be harmonized inside an agent, and a common QR code handling mechanism can be used.</p>"},{"location":"features/0434-outofband/#urls-and-qr-code-handling","title":"URLs and QR Code Handling","text":"<p>We'd like to have the specification of QR handling harmonized into a single RFC (this one).</p>"},{"location":"features/0434-outofband/#tutorial","title":"Tutorial","text":""},{"location":"features/0434-outofband/#key-concepts","title":"Key Concepts","text":"<p>The Out-of-band protocol is used when an agent doesn't know if it has a connection with another agent. This could be because you are trying to establish a new connection with that agent, you have connections but don't know who the other party is, or if you want to have a connection-less interaction. Since there is no DIDComm connection to use for the messages of this protocol, the messages are plaintext and sent out-of-band, such as via a QR code, in an email message or any other available channel. Since the delivery of out-of-band messages will often be via QR codes, this RFC also covers the use of QR codes.</p> <p>Two well known use cases for using an out-of-band protocol are:</p> <ul> <li>A user on a web browser wants to execute a protocol (for example, to issue a verifiable credential) between the website operator's agent and a user's agent. To enable the execution of the protocol, the two agents must first have a connection. An out-of-band message is used to trigger the creation of a new, or the reuse an existing, connection.</li> <li>A website operator wants to request something from a user on their site where there is no (known) connection with the user's agent, and there is no need to create a connection.</li> </ul> <p>In both cases, there is only a single out-of-band protocol message sent. The message responding to the out-of-band message is a DIDComm message from an appropriate protocol.</p> <p>Note that the website-to-agent model is not the only such interaction enabled by the out-of-band protocol, and a QR code is not the only delivery mechanism for out-of-band messages. However, they are useful as examples of the purpose of the protocol.</p>"},{"location":"features/0434-outofband/#roles","title":"Roles","text":"<p>The out-of-band protocol has two roles: sender and receiver.</p>"},{"location":"features/0434-outofband/#sender","title":"sender","text":"<p>The agent that generates the out-of-band message and makes it available to the other party.</p>"},{"location":"features/0434-outofband/#receiver","title":"receiver","text":"<p>The agent that receives the out-of-band message and decides how to respond. There is no out-of-band protocol message with which the receiver will respond. Rather, if they respond, they will use a message from another protocol that the sender understands.</p>"},{"location":"features/0434-outofband/#states","title":"States","text":"<p>The state machines for the sender and receiver are a bit odd for the out-of-band protocol because it consists of a single message that kicks off a co-protocol and ends when evidence of the co-protocol's launch is received, in the form of some response. In the following state machine diagrams we generically describe the response message from the receiver as being a DIDComm message.</p> <p>The sender state machine is as follows:</p> <p></p> <p>Note the \"optional\" reference under the second event in the <code>await-response</code> state. That is to indicate that an out-of-band message might be a single use message with a transition to done, or reusable message (received by many receivers) with a transition back to <code>await-response</code>.</p> <p>The receiver state machine is as follows:</p> <p></p> <p>Worth noting is the first event of the <code>done</code> state, where the receiver may receive the message multiple times. This represents, for example, an agent returning to the same website and being greeted with instances of the same QR code each time.</p>"},{"location":"features/0434-outofband/#messages","title":"Messages","text":"<p>The out-of-band protocol a single message that is sent by the sender.</p>"},{"location":"features/0434-outofband/#invitation-httpsdidcommorgout-of-bandverinvitation","title":"Invitation: <code>https://didcomm.org/out-of-band/%VER/invitation</code>","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/invitation\",\n  \"@id\": \"&lt;id used for context as pthid&gt;\",\n  \"label\": \"Faber College\",\n  \"goal_code\": \"issue-vc\",\n  \"goal\": \"To issue a Faber College Graduate credential\",\n  \"accept\": [\n    \"didcomm/aip2;env=rfc587\",\n    \"didcomm/aip2;env=rfc19\"\n  ],\n  \"handshake_protocols\": [\n    \"https://didcomm.org/didexchange/1.0\",\n    \"https://didcomm.org/connections/1.0\"\n  ],\n  \"requests~attach\": [\n    {\n      \"@id\": \"request-0\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"json\": \"&lt;json of protocol message&gt;\"\n      }\n    }\n  ],\n  \"services\": [\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]\n}\n</code></pre> <p>The items in the message are:</p> <ul> <li><code>@type</code> - the DIDComm message type</li> <li><code>@id</code> - the unique ID of the message. The ID should be used as the parent thread ID (<code>pthid</code>) for the response message, rather than the more common thread ID (<code>thid</code>) of the response message. This enables multiple uses of a single out-of-band message.</li> <li><code>label</code> - [optional] a self-attested string that the receiver may want to display to the user, likely about who sent the out-of-band message.</li> <li><code>goal_code</code> - [optional] a self-attested code the receiver may want to display to the user or use in automatically deciding what to do with the out-of-band message.</li> <li><code>goal</code> - [optional] a self-attested string that the receiver may want to display to the user about the context-specific goal of the out-of-band message.</li> <li><code>accept</code> - [optional] an array of media (aka mime) types in the order of preference of the sender that the receiver can use in responding to the message. If <code>accept</code> is not specified, the receiver uses its preferred choice to respond to the message. RFC 0044 provides a general discussion of media types.</li> <li><code>handshake_protocols</code> - [optional] an array of protocols in the order of preference of the sender that the receiver can use in responding to the message in order to create or reuse a connection with the sender. These are not arbitrary protocols but rather protocols that result in the establishment of a connection. One or both of <code>handshake_protocols</code> and <code>requests~attach</code> MUST be included in the message.</li> <li><code>requests~attach</code> - [optional] an attachment decorator containing an array of request messages in order of preference that the receiver can using in responding to the message. One or both of <code>handshake_protocols</code> and <code>requests~attach</code> MUST be included in the message.</li> <li>While the JSON form of the attachment is used in the example above, the sender could choose to use the base64 form.</li> <li><code>services</code> - an array of union types that the receiver uses when responding to the message. Each item is either a DIDComm <code>service</code> object (as per RFC0067) or a DID (as per Decentralized Identifiers v1.0). Additional details below.</li> </ul> <p>If only the <code>handshake_protocols</code> item is included, the initial interaction will complete with the establishment (or reuse) of the connection. Either side may then use that connection for any purpose. A common use case (but not required) would be for the sender to initiate another protocol after the connection is established to accomplish some shared goal.</p> <p>If only the <code>requests~attach</code> item is included, no new connection is expected to be created, although one could be used if the receiver knows such a connection already exists. The receiver responds to one of the messages in the <code>requests~attach</code> array. The <code>requests~attach</code> item might include the first message of a protocol from the sender, or might be a please-play-the-role message requesting the receiver initiate a protocol. If the protocol requires a further response from the sender to the receiver, the receiver must include a <code>~service</code> decorator for the sender to use in responding.</p> <p>If both the <code>handshake_protocols</code> and <code>requests~attach</code> items are included in the message, the receiver should first establish a connection and then respond (using that connection) to one of the messages in the <code>requests~attach</code> message. If a connection already exists between the parties, the receiver may respond immediately to the <code>request-attach</code> message using the established connection.</p>"},{"location":"features/0434-outofband/#reuse-messages","title":"Reuse Messages","text":"<p>While the receiver is expected to respond with an initiating message from a <code>handshake_protocols</code> or <code>requests~attach</code> item using an offered service, the receiver may be able to respond by reusing an existing connection. Specifically, if a connection they have was created from an out-of-band <code>invitation</code> from the same <code>services</code> DID of a new <code>invitation</code> message, the connection MAY be reused. The receiver may choose to not reuse the existing connection for privacy purposes and repeat a handshake protocol to receive a redundant connection. </p> <p>If a message has a service block instead of a DID in the <code>services</code> list, you may enable reuse by encoding the key and endpoint of the service block in a Peer DID numalgo 2 and using that DID instead of a service block.</p> <p>If the receiver desires to reuse the existing connection and a <code>requests~attach</code> item is included in the message, the receiver SHOULD respond to one of the attached messages using the existing connection.</p> <p>If the receiver desires to reuse the existing connection and no <code>requests~attach</code> item is included in the message, the receiver SHOULD attempt to do so with the <code>reuse</code> and <code>reuse-accepted</code> messages. This will notify the inviter that the existing connection should be used, along with the context that can be used for follow-on interactions.</p> <p>While the <code>invitation</code> message is passed unencrypted and out-of-band, both the <code>handshake-reuse</code> and <code>handshake-reuse-accepted</code> messages MUST be encrypted and transmitted as normal DIDComm messages.</p>"},{"location":"features/0434-outofband/#reuse-httpsdidcommorgout-of-bandverhandshake-reuse","title":"Reuse: <code>https://didcomm.org/out-of-band/%VER/handshake-reuse</code>","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/handshake-reuse\",\n  \"@id\": \"&lt;id&gt;\",\n  \"~thread\": {\n    \"thid\": \"&lt;same as @id&gt;\",\n    \"pthid\": \"&lt;The @id of the Out-of-Band invitation&gt;\"\n  }\n}\n</code></pre> <p>The items in the message are:</p> <ul> <li><code>@type</code> - the DIDComm message type</li> <li><code>@id</code> - the unique ID of the message. </li> <li><code>pthid</code> - the @id of the invitation message. This provides the context link for the inviter to prompt additional protocol interactions.</li> </ul> <p>Sending or receiving this message does not change the state of the existing connection.</p> <p>When the inviter receives the <code>handshake-reuse</code> message, they MUST respond with a <code>handshake-reuse-accepted</code> message to notify that invitee that the request to reuse the existing connection is successful.</p>"},{"location":"features/0434-outofband/#reuse-accepted-httpsdidcommorgout-of-bandverhandshake-reuse-accepted","title":"Reuse Accepted:  <code>https://didcomm.org/out-of-band/%VER/handshake-reuse-accepted</code>","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/handshake-reuse-accepted\",\n  \"@id\": \"&lt;id&gt;\",\n  \"~thread\": {\n    \"thid\": \"&lt;The Message @id of the reuse message&gt;\",\n    \"pthid\": \"&lt;The @id of the Out-of-Band invitation&gt;\"\n  }\n}\n</code></pre> <p>The items in the message are:</p> <ul> <li><code>@type</code> - the DIDComm message type</li> <li><code>@id</code> - the unique ID of the message. </li> <li><code>pthid</code> - the @id of the invitation message. This and the <code>thid</code> provides context for the invitee to know the reuse attempt succeeded.</li> </ul> <p>If this message is not received by the invitee, they should use the regular process. This message is a mechanism by which the invitee can detect a situation where the inviter no longer has a record of the connection and is unable to decrypt and process the <code>handshake-reuse</code> message.</p> <p>After sending this message, the inviter may continue any desired protocol interactions based on the context matched by the <code>pthid</code> present in the <code>handshake-reuse</code> message.</p>"},{"location":"features/0434-outofband/#responses","title":"Responses","text":"<p>The following table summarizes the different forms of the out-of-band <code>invitation</code> message depending on the presence (or not) of the <code>handshake_protocols</code> item, the <code>requests~attach</code> item and whether or not a connection between the agents already exists.</p> <code>handshake_protocols</code> Present? <code>requests~attach</code> Present? Existing connection? Receiver action(s) No No No Impossible Yes No No Uses the first supported protocol from <code>handshake_protocols</code> to make a new connection using the first supported <code>services</code> entry. No Yes No Send a response to the first supported request message using the first supported <code>services</code> entry. Include a <code>~service</code> decorator if the sender is expected to respond. No No Yes Impossible Yes Yes No Use the first supported protocol from <code>handshake_protocols</code> to make a new connection using the first supported <code>services</code> entry, and then send a response message to the first supported attachment message using the new connection. Yes No Yes Send a <code>handshake-reuse</code> message. No Yes Yes Send a response message to the first supported request message using the existing connection. Yes Yes Yes Send a response message to the first supported request message using the existing connection. <p>Both the <code>goal_code</code> and <code>goal</code> fields SHOULD be used with the localization service decorator. The two fields are to enable both human and machine handling of the out-of-band message. <code>goal_code</code> is to specify a generic, protocol level outcome for sending the out-of-band message (e.g. issue verifiable credential, request proof, etc.) that is suitable for machine handling and possibly human display, while <code>goal</code> provides context specific guidance, targeting mainly a person controlling the receiver's agent. The list of <code>goal_code</code> values is provided in the Message Catalog section of this RFC.</p>"},{"location":"features/0434-outofband/#the-services-item","title":"The <code>services</code> Item","text":"<p>As mentioned in the description above, the <code>services</code> item array is intended to be analogous to the <code>service</code> block of a DIDDoc. When not reusing an existing connection, the receiver scans the array and selects (according to the rules described below) a service entry to use for the response to the out-of-band message.</p> <p>There are two forms of entries in the <code>services</code> item array:</p> <ul> <li>a DID that is resolved to retrieve it's DIDDoc service block, and</li> <li>an inline service block.</li> </ul> <p>The following is an example of a two entry array, one of each form:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/invitation\",\n  \"@id\": \"&lt;id used for context as pthid&gt;\",\n  \"label\": \"Faber College\",\n  \"handshake_protocols\": [\"https://didcomm.org/didexchange/1.0\"],\n  \"services\": [\n    {\n      \"id\": \"#inline\",\n      \"type\": \"did-communication\",\n      \"recipientKeys\": [\"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"],\n      \"routingKeys\": [],\n      \"serviceEndpoint\": \"https://example.com:5000\"\n    },\n    \"did:sov:LjgpST2rjsoxYegQDRm7EL\"\n  ]\n}\n</code></pre> <p>The processing rules for the <code>services</code> block are:</p> <ul> <li>Use only entries where the <code>type</code> is equal to <code>did-communication</code>.</li> <li>Entries without a <code>type</code> are assumed to be <code>did-communication</code>.</li> <li>The sender MUST put the array into their order of preference, and, as such, the receiver SHOULD prefer the entries in order.</li> </ul> <p>The attributes in the inline form parallel the attributes of a DID Document for increased meaning. The <code>recipientKeys</code> and <code>routingKeys</code> within the inline block decorator MUST be <code>did:key</code> references.</p> <p>As defined in the DIDComm Cross Domain Messaging RFC, if <code>routingKeys</code> is present and non-empty, additional forwarding wrapping are necessary in the response message.</p> <p>When considering routing and options for out-of-band messages, keep in mind that the more detail in the message, the longer the URL will be and (if used) the more dense (and harder to scan) the QR code will be.</p>"},{"location":"features/0434-outofband/#service-endpoint","title":"Service Endpoint","text":"<p>The service endpoint used to transmit the response is either present in the out-of-band message or available in the DID Document of a presented DID. If the endpoint is itself a DID, the <code>serviceEndpoint</code> in the DIDDoc of the resolved DID MUST be a URI, and the <code>recipientKeys</code> MUST contain a single key. That key is appended to the end of the list of <code>routingKeys</code> for processing. For more information about message forwarding and routing, see RFC 0094 Cross Domain Messaging.</p>"},{"location":"features/0434-outofband/#adoption-messages","title":"Adoption Messages","text":"<p>The <code>problem_report</code> message MAY be adopted by the out-of-band protocol if the agent wants to respond with problem reports to invalid messages, such as attempting to reuse a single-use invitation.</p>"},{"location":"features/0434-outofband/#constraints","title":"Constraints","text":"<p>An existing connection can only be reused based on a DID in the <code>services</code> list in an out-of-band message.</p>"},{"location":"features/0434-outofband/#reference","title":"Reference","text":""},{"location":"features/0434-outofband/#messages-reference","title":"Messages Reference","text":"<p>The full description of the message in this protocol can be found in the Tutorial section of this RFC.</p>"},{"location":"features/0434-outofband/#localization","title":"Localization","text":"<p>The <code>goal_code</code> and <code>goal</code> fields SHOULD have localization applied. See the purpose of those fields in the message type definitions section and the message catalog section (immediately below).</p>"},{"location":"features/0434-outofband/#message-catalog","title":"Message Catalog","text":""},{"location":"features/0434-outofband/#goal_code","title":"<code>goal_code</code>","text":"<p>The following values are defined for the <code>goal_code</code> field:</p> Code (cd) English (en) issue-vc To issue a credential request-proof To request a proof create-account To create an account with a service p2p-messaging To establish a peer-to-peer messaging relationship"},{"location":"features/0434-outofband/#goal","title":"<code>goal</code>","text":"<p>The <code>goal</code> localization values are use case specific and localization is left to the agent implementor to enable using the techniques defined in the ~l10n RFC.</p>"},{"location":"features/0434-outofband/#roles-reference","title":"Roles Reference","text":"<p>The roles are defined in the Tutorial section of this RFC.</p>"},{"location":"features/0434-outofband/#states-reference","title":"States Reference","text":""},{"location":"features/0434-outofband/#initial","title":"initial","text":"<p>No out-of-band messages have been sent.</p>"},{"location":"features/0434-outofband/#await-response","title":"await-response","text":"<p>The sender has shared an out-of-band message with the intended receiver(s), and the sender has not yet received all of the responses. For a single-use out-of-band message, there will be only one response; for a multi-use out-of-band message, there is no defined limit on the number of responses.</p>"},{"location":"features/0434-outofband/#prepare-response","title":"prepare-response","text":"<p>The receiver has received the out-of-band message and is preparing a response. The response will not be an out-of-band protocol message, but a message from another protocol chosen based on the contents of the out-of-band message.</p>"},{"location":"features/0434-outofband/#done","title":"done","text":"<p>The out-of-band protocol has been completed. Note that if the out-of-band message was intended to be available to many receivers (a multiple use message), the sender returns to the await-response state rather than going to the done state.</p>"},{"location":"features/0434-outofband/#errors","title":"Errors","text":"<p>There is an optional courtesy error message stemming from an out-of-band message that the sender could provide if they have sufficient recipient information. If the out-of-band message is a single use message and the sender receives multiple responses and each receiver's response includes a way for the sender to respond with a DIDComm message, all but the first MAY be answered with a <code>problem_report</code>.</p>"},{"location":"features/0434-outofband/#error-message-example","title":"Error Message Example","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/problem_report\",\n  \"@id\": \"5678876542345\",\n  \"~thread\": { \"pthid\": \"&lt;@id of the OutofBand message&gt;\" },\n  \"description\": {\n    \"en\": \"The invitation has expired.\",\n    \"code\": \"expired-invitation\"\n  },\n  \"impact\": \"thread\"\n}\n</code></pre> <p>See the problem-report protocol for details on the items in the example.</p>"},{"location":"features/0434-outofband/#flow-overview","title":"Flow Overview","text":"<p>In an out-of-band message the sender gives information to the receiver about the kind of DIDComm protocol response messages it can handle and how to deliver the response. The receiver uses that information to determine what DIDComm protocol/message to use in responding to the sender, and (from the service item or an existing connection) how to deliver the response to the sender.</p> <p>The handling of the response is specified by the protocol used.</p> <p>To Do: Make sure that the following remains in the DID Exchange/Connections RFCs</p> <p>Any Published DID that expresses support for DIDComm by defining a  <code>service</code> that follows the DIDComm conventions serves as an implicit invitation. If an invitee wishes to connect to any Published DID, they need not wait for an out-of-band invitation message. Rather, they can designate their own label and initiate the appropriate protocol (e.g. 0160-Connections or 0023-DID-Exchange) for establishing a connection.</p>"},{"location":"features/0434-outofband/#standard-out-of-band-message-encoding","title":"Standard Out-of-Band Message Encoding","text":"<p>Using a standard out-of-band message encoding allows for easier interoperability between multiple projects and software platforms. Using a URL for that standard encoding provides a built in fallback flow for users who are unable to automatically process the message. Those new users will load the URL in a browser as a default behavior, and may be presented with instructions on how to install software capable of processing the message. Already onboarded users will be able to process the message without loading in a browser via mobile app URL capture, or via capability detection after being loaded in a browser.</p> <p>The standard out-of-band message format is a URL with a Base64Url encoded json object as a query parameter.</p> <p>Please note the difference between Base64Url and Base64 encoding.</p> <p>The Base64URL encoded JSON object SHOULD NOT use padding, but the decoding implementation used MUST correctly decode padded and unpadded Base64URL encoded data.</p> <p>The URL format is as follows, with some elements described below:</p> <pre><code>https://&lt;domain&gt;/&lt;path&gt;?oob=&lt;outofbandMessage&gt;\n</code></pre> <p><code>&lt;domain&gt;</code> and <code>&lt;path&gt;</code> should be kept as short as possible, and the full URL SHOULD return human readable instructions when loaded in a browser. This is intended to aid new users. The <code>oob</code> query parameter is required and is reserved to contain the out-of-band message string. Additional path elements or query parameters are allowed, and can be leveraged to provide coupons or other promise of payment for new users.</p> <p>To do: We need to rationalize this approach <code>https://</code> approach with the use of a special protocol (e.g. <code>didcomm://</code>) that will enable handling of the URL on mobile devices to automatically invoke an installed app on both Android and iOS. A user must be able to process the out-of-band message on the device of the agent (e.g. when the mobile device can't scan the QR code because it is on a web page on device).</p> <p>The <code>&lt;outofbandMessage&gt;</code> is an agent plaintext message (not a DIDComm message) that has been Base64Url encoded such that the resulting string can be safely used in a URL.</p> <pre><code>outofband_message = base64UrlEncode(&lt;outofbandMessage&gt;)\n</code></pre> <p>During Base64Url encoding, whitespace from the JSON string SHOULD be eliminated to keep the resulting out-of-band message string as short as possible.</p>"},{"location":"features/0434-outofband/#example-out-of-band-message-encoding","title":"Example Out-of-Band Message Encoding","text":"<p>Invitation:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/1.0/invitation\",\n  \"@id\": \"69212a3a-d068-4f9d-a2dd-4741bca89af3\",\n  \"label\": \"Faber College\",\n  \"goal_code\": \"issue-vc\",\n  \"goal\": \"To issue a Faber College Graduate credential\",\n  \"handshake_protocols\": [\"https://didcomm.org/didexchange/1.0\", \"https://didcomm.org/connections/1.0\"],\n  \"services\": [\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]\n}\n</code></pre> <p>Whitespace removed:</p> <pre><code>{\"@type\":\"https://didcomm.org/out-of-band/1.0/invitation\",\"@id\":\"69212a3a-d068-4f9d-a2dd-4741bca89af3\",\"label\":\"Faber College\",\"goal_code\":\"issue-vc\",\"goal\":\"To issue a Faber College Graduate credential\",\"handshake_protocols\":[\"https://didcomm.org/didexchange/1.0\",\"https://didcomm.org/connections/1.0\"],\"services\":[\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]}\n</code></pre> <p>Base64Url encoded:</p> <pre><code>eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0\n</code></pre> <p>Example URL with Base64Url encoded message:</p> <pre><code>http://example.com/ssi?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0\n</code></pre> <p>Out-of-band message URLs can be transferred via any method that can send text, including an email, SMS, posting on a website, or QR Code.</p> <p>Example URL encoded as a QR Code:</p> <p></p> <p>Example Email Message:</p> <pre><code>To: alice@alum.faber.edu\nFrom: studentrecords@faber.edu\nSubject: Your request to connect and receive your graduate verifiable credential\n\nDear Alice,\n\nTo receive your Faber College graduation certificate, click here to [connect](http://example.com/ssi?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0) with us, or paste the following into your browser:\n\nhttp://example.com/ssi?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0\n\nIf you don't have an identity agent for holding credentials, you will be given instructions on how you can get one.\n\nThanks,\n\nFaber College\nKnowledge is Good\n</code></pre>"},{"location":"features/0434-outofband/#url-shortening","title":"URL Shortening","text":"<p>It seems inevitable that the length of some out-of-band message will be too long to produce a useable QR code. Techniques to avoid unusable QR codes have been presented above, including using attachment links for requests, minimizing the routing of the response and eliminating unnecessary whitespace in the JSON. However, at some point a sender may need generate a very long URL. In that case, a DIDComm specific URL shortener redirection should be implemented by the sender as follows:</p> <ul> <li>The sender generates a unique URL for each shortened out-of-band message.</li> <li>The unique URL often includes a unique id component as part of the path or in a query parameter.</li> <li>The following URLs are valid examples:</li> <li><code>https://example.com/ssi?id=5f0e3ffb-3f92-4648-9868-0d6f8889e6f3</code></li> <li><code>https://example.com/8E6nEcJ26TTE</code></li> <li><code>https://example.com/sky/event/8DcnUW2h8m4jcfPdQ2uMN7/work-laptop-bag/s/u</code></li> <li>On receipt of this form of message, the agent MUST perform an HTTP GET to retrieve the associated out-of-band message. The agent SHOULD include an <code>Accept</code> header requesting the <code>application/json</code> MIME type.</li> <li>The sender MAY include a <code>Content-Type</code> header specifying <code>application/json; charset=utf-8</code>, and in the case where the agent included an <code>Accept</code> header for the <code>application/json</code> MIME type, the sender MUST include the header. If so, the sender MUST return the invitation in JSON format in the response body with a <code>status_code</code> of <code>200</code>.</li> <li>The sender MAY respond with a <code>status_code</code> of <code>301</code> or <code>302</code> and include a <code>Location</code> header specifying the long out-of-band message URL.</li> <li>This redirect option operates like many commercial URL shorteners. </li> <li>The sender MUST invalidate the URL after message retrieval or after an expiration time to prevent unintended parties from retrieving a copy of the message.</li> <li>A sender MUST NOT use a commercial URL shortener unless it supports invalidating the URL.</li> </ul> <p>A usable QR code will always be able to be generated from the shortened form of the URL.</p>"},{"location":"features/0434-outofband/#url-shortening-caveats","title":"URL Shortening Caveats","text":"<p>Some HTTP libraries don't support stopping redirects from occuring on reception of a <code>301</code> or <code>302</code>, in this instance the redirect is automatically followed and will result in a response that MAY have a status of <code>200</code> and MAY contain a URL that can be processed as a normal <code>Out-of-Band</code> message.</p> <p>If the agent performs a HTTP GET with the <code>Accept</code> header requesting <code>application/json</code> MIME type the response can either contain the message in <code>json</code> or result in a redirect, processing of the response should attempt to determine which response type is received and process the message accordingly.</p>"},{"location":"features/0434-outofband/#out-of-band-message-publishing","title":"Out-of-Band Message Publishing","text":"<p>The sender will publish or transmit the out-of-band message URL in a manner available to the intended receiver. After publishing, the sender is in the await-response state, will the receiver is in the prepare-response state.</p>"},{"location":"features/0434-outofband/#out-of-band-message-processing","title":"Out-of-Band Message Processing","text":"<p>If the receiver receives an <code>out-of-band</code> message in the form of a QR code, the receiver should attempt to decode the QR code to an out-of-band message URL for processing.</p> <p>When the receiver receives the out-of-band message URL, there are two possible user flows, depending on whether the individual has an Aries agent. If the individual is new to Aries, they will likely load the URL in a browser. The resulting page SHOULD contain instructions on how to get started by installing an Aries agent. That install flow will transfer the out-of-band message to the newly installed software.</p> <p>A user that already has those steps accomplished will have the URL received by software directly. That software will attempt to base64URL decode the string and can read the out-of-band message directly out of the <code>oob</code> query parameter, without loading the URL. If this process fails then the software should attempt the steps to process a shortened URL. </p> <p>NOTE: In receiving the out-of-band message, the base64url decode implementation used MUST correctly decode padded and unpadded base64URL encoded data.</p> <p>If the receiver wants to respond to the out-of-band message, they will use the information in the message to prepare the request, including:</p> <ul> <li>the <code>handshake_protocols</code> or <code>requests~attach</code> to determine the acceptable response messages, and</li> <li>the <code>services</code> block to determine how to get the response to the sender.</li> </ul>"},{"location":"features/0434-outofband/#correlating-responses-to-out-of-band-messages","title":"Correlating responses to Out-of-Band messages","text":"<p>The response to an out-of-band message MUST set its <code>~thread.pthid</code> equal to the <code>@id</code> property of the out-of-band message.</p> <p>Example referencing an explicit invitation:</p> <pre><code>{\n  \"@id\": \"a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef\",\n  \"@type\": \"https://didcomm.org/didexchange/1.0/request\",\n  \"~thread\": { \"pthid\": \"032fbd19-f6fd-48c5-9197-ba9a47040470\" },\n  \"label\": \"Bob\",\n  \"did\": \"B.did@B:A\",\n  \"did_doc~attach\": {\n    \"base64\": \"eyJ0eXAiOiJKV1Qi... (bytes omitted)\",\n    \"jws\": {\n      \"header\": {\n        \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n      },\n      \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n      \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n    }\n  }\n}\n</code></pre>"},{"location":"features/0434-outofband/#response-transmission","title":"Response Transmission","text":"<p>The response message from the receiver is encoded according to the standards of the DIDComm encryption envelope, using the <code>service</code> block present in (or resolved from) the out-of-band invitation.</p>"},{"location":"features/0434-outofband/#reusing-connections","title":"Reusing Connections","text":"<p>If an out-of-band invitation has a DID in the <code>services</code> block, and the receiver determines it has previously established a connection with that DID, the receiver MAY send its response on the established connection. See Reuse Messages for details.</p>"},{"location":"features/0434-outofband/#receiver-error-handling","title":"Receiver Error Handling","text":"<p>If the receiver is unable to process the out-of-band message, the receiver may respond with a Problem Report identifying the problem using a DIDComm message. As with any response, the ~thread decorator of the <code>pthid</code> MUST be the <code>@id</code> of the out-of-band message. The problem report MUST be in the protocol of an expected response. An example of an error that might come up is that the receiver is not able to handle any of the proposed protocols in the out-of-band message. The receiver MAY include in the problem report a <code>~service</code> decorator that allows the sender to respond to the out-of-band message with a DIDComm message.</p>"},{"location":"features/0434-outofband/#response-processing","title":"Response processing","text":"<p>The sender MAY look up the corresponding out-of-band message identified in the response's <code>~thread.pthid</code> to determine whether it should accept the response. Information about the related out-of-band message protocol may be required to provide the sender with context about processing the response and what to do after the protocol completes.</p>"},{"location":"features/0434-outofband/#sender-error-handling","title":"Sender Error Handling","text":"<p>If the sender receives a Problem Report message from the receiver, the sender has several options for responding. The sender will receive the message as part of an offered protocol in the out-of-band message.</p> <p>If the receiver did not include a <code>~service</code> decorator in the response, the sender can only respond if it is still in session with the receiver. For example, if the sender is a website that displayed a QR code for the receiver to scan, the sender could create a new, presumably adjusted, out-of-band message, encode it and present it to the user in the same way as before.</p> <p>If the receiver included a <code>~service</code> decorator in the response, the sender can provide a new message to the receiver, even a new version of the original out-of-band message, and send it to the receiver. The new message MUST include a <code>~thread</code> decorator with the <code>thid</code> set to the <code>@id</code> from the problem report message.</p>"},{"location":"features/0434-outofband/#drawbacks","title":"Drawbacks","text":"<ul> <li>Publicly displayed out-of-band messages (say, a slide at the end of a presentation) all use the same DID. This is not a problem for institutions, and only provides a minor increase in correlation over sharing an endpoint, key, and routing information in a way that is observable by multiple parties.</li> </ul>"},{"location":"features/0434-outofband/#prior-art","title":"Prior art","text":"<ul> <li>The out-of-band message/response process is similar to other key exchange protocols.</li> <li>The Connections and DID Exchange protocols have (or had) their own <code>invitation</code> method.</li> <li>The <code>~service</code> decorator in combination with a request/response-type protocol message (such as present-proof/request) has previously used in place of the out-of-band <code>request</code> message.</li> </ul>"},{"location":"features/0434-outofband/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>None</li> </ul>"},{"location":"features/0434-outofband/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0445-rich-schema-mapping/","title":"Aries RFC 0445: Aries Rich Schema Mapping","text":"<ul> <li>Author: Alexander Shcherbakov, Ken Ebert, Brent Zundel</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes:</li> <li>Start Date: 2019-03-16</li> <li>Tags: feature, rich-schemas</li> </ul>"},{"location":"features/0445-rich-schema-mapping/#summary","title":"Summary","text":"<p>Mappings serve as a bridge between rich schemas and the flat array of signed integers. A mapping specifies the order in which attributes are transformed and signed. It consists of a set of graph paths and the encoding used for the attribute values specified by those graph paths. Each claim in a mapping has a reference to an encoding, and those encodings are defined in encoding objects.</p> <p>Mapping objects are processed in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0445-rich-schema-mapping/#motivation","title":"Motivation","text":"<p>Rich schemas are complex, hierarchical, and possibly nested objects. The Camenisch-Lysyanskaya signature scheme used by Indy requires the attributes to be represented by an array of 256-bit integers. Converting data specified by a rich schema into a flat array of integers requires a mapping object.</p>"},{"location":"features/0445-rich-schema-mapping/#tutorial","title":"Tutorial","text":""},{"location":"features/0445-rich-schema-mapping/#intro-to-mappings","title":"Intro to Mappings","text":"<p>Mappings are written to the ledger so they can be shared by multiple credential definitions.  A Credential Definition may only reference a single Mapping.</p> <p>One or more Mappings can be referenced by a Presentation Definition. The mappings serve as a vital part of the verification process. The verifier, upon receipt of a presentation must not only check that the array of integers signed by the issuer is valid, but that the attribute values were transformed and ordered according to the mapping referenced in the credential definition.</p> <p>A Mapping references one and only one Rich Schema object. If there is no Schema Object  a Mapping can reference, a new Schema must be created on the ledger. If a Mapping needs to map attributes from multiple Schemas, then a new Schema embedding the multiple Schemas  must be created and stored on the ledger.    </p> <p>Mappings need to be discoverable.</p> <p>Mapping is a JSON-LD object following the same structure (attributes and graph pathes)  as the corresponding Rich Schema. A Mapping may contain only a subset of the original Rich Schema's attributes.</p> <p>Every Mapping must have two default attributes required by any W3C compatible credential  (see W3C verifiable credential specification): <code>issuer</code> and <code>issuanceDate</code>.  Additionally, any other attributes that are considered optional by the W3C verifiable credential specification that will be included in the issued credential must be included in the Mapping. For example, <code>credentialStatus</code> or <code>expirationDate</code>. This allows the holder to selectively disclose these attributes in the same way as other attributes from the schema.</p> <p>The value of every schema attribute in a Mapping object is an array of the following pairs: - encoding object (referenced by its <code>id</code>) to be used for representation of the attribute as an integer - rank of the attribute to define the order in which the attribute is signed by the Issuer.</p> <p>The value is an array as the same attribute may be used in Credential Definition multiple times with different encodings. </p> <p>Note: The anonymous credential signature scheme currently used by Indy is Camenisch-Lysyanskaya signatures. It is the use of this signature scheme in combination with rich schema objects that necessitates a mapping object. If another signature scheme is used which does not have the same requirements, a mapping object may not be necessary or a different mapping object may need to be defined.</p>"},{"location":"features/0445-rich-schema-mapping/#properties","title":"Properties","text":"<p>Mapping's properties follow the generic template defined in  Rich Schema Common.</p> <p>Mapping's <code>content</code> field is a JSON-LD-serialized string with the following fields:</p>"},{"location":"features/0445-rich-schema-mapping/#id","title":"@id","text":"<p>A Mapping must have an <code>@id</code> property. The value of this property must be equal to the <code>id</code> field which is a DID (see Identification of Rich Schema Objects). </p>"},{"location":"features/0445-rich-schema-mapping/#type","title":"@type","text":"<p>A Mapping must have a <code>@type</code> property. The value of this property must be (or map to, via a context object) a URI. </p>"},{"location":"features/0445-rich-schema-mapping/#context","title":"@context","text":"<p>A Mapping may have a <code>@context</code> property. If present, the value of this property must be a context object or a URI which can be dereferenced to obtain a context object.</p>"},{"location":"features/0445-rich-schema-mapping/#schema","title":"schema","text":"<p>An <code>id</code> of the corresponding Rich Schema</p>"},{"location":"features/0445-rich-schema-mapping/#attributes","title":"attributes","text":"<p>A dict of all the schema attributes the Mapping object is going to map to encodings and use in credentials. An attribute may have nested attributes matching the schema structure.</p> <p>It must also contain the following default attributes required by any W3C compatible verifiable credential (plus any additional attributes that may have been included from the W3C verifiable credentials data model):   - <code>issuer</code>  - <code>issuanceDate</code>  - any additional attributes</p> <p>Every leaf attribute's value (including the default <code>issuer</code> and <code>issuanceDate</code> ones) is an array of the following pairs:</p> <ul> <li><code>enc</code> (string): Encoding object (referenced by its <code>id</code>) to be used for representation of the attribute as an integer. </li> <li><code>rank</code> (int): Rank of the attribute to define the order in which the attribute is signed by the Issuer. It is important that no two <code>rank</code> values may be identical.</li> </ul>"},{"location":"features/0445-rich-schema-mapping/#example-mapping","title":"Example Mapping","text":"<p>Let's consider a Rich Schema object with the following <code>content</code>: <pre><code>    '@id': \"did:sov:4e9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n    '@context': \"did:sov:2f9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n    '@type': \"rdfs:Class\",\n    \"rdfs:comment\": \"ISO18013 International Driver License\",\n    \"rdfs:label\": \"Driver License\",\n    \"rdfs:subClassOf\": {\n        \"@id\": \"sch:Thing\"\n    },\n    \"driver\": \"Driver\",\n    \"dateOfIssue\": \"Date\",\n    \"dateOfExpiry\": \"Date\",\n    \"issuingAuthority\": \"Text\",\n    \"licenseNumber\": \"Text\",\n    \"categoriesOfVehicles\": {\n        \"vehicleType\": \"Text\",\n        \"dateOfIssue\": \"Date\",\n        \"dateOfExpiry\": \"Date\",\n        \"restrictions\": \"Text\",\n    },\n    \"administrativeNumber\": \"Text\"\n</code></pre></p> <p>Then the corresponding Mapping object may have the following <code>content</code>.   Please note that we used all attributes from the original Schema except <code>dateOfExpiry</code>, <code>categoriesOfVehicles/dateOfExpiry</code> and <code>categoriesOfVehicles/restrictions</code>. Also, the <code>licenseNumber</code> attribute is used twice, but with different encodings.  It is important that no two <code>rank</code> values may be identical.  <pre><code>    '@id': \"did:sov:5e9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n    '@context': \"did:sov:2f9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n    '@type': \"rdfs:Class\",\n    \"schema\": \"did:sov:4e9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n    \"attributes\" : {\n        \"issuer\": [{\n            \"enc\": \"did:sov:9x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n            \"rank\": 1\n        }],\n        \"issuanceDate\": [{\n            \"enc\": \"did:sov:119F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n            \"rank\": 2\n        }],\n        \"expirationDate\": [{\n            \"enc\": \"did:sov:119F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n            \"rank\": 11\n        }],        \n        \"driver\": [{\n            \"enc\": \"did:sov:1x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n            \"rank\": 5\n        }],\n        \"dateOfIssue\": [{\n            \"enc\": \"did:sov:2x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n            \"rank\": 4\n        }],\n        \"issuingAuthority\": [{\n            \"enc\": \"did:sov:3x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n            \"rank\": 3\n        }],\n        \"licenseNumber\": [\n            {\n                \"enc\": \"did:sov:4x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n                \"rank\": 9\n            },\n            {\n                \"enc\": \"did:sov:5x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n                \"rank\": 10\n            },\n        ],\n        \"categoriesOfVehicles\": {\n            \"vehicleType\": [{\n                \"enc\": \"did:sov:6x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n                \"rank\": 6\n            }],\n            \"dateOfIssue\": [{\n             \"enc\": \"did:sov:7x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n                \"rank\": 7\n            }],\n        },\n        \"administrativeNumber\": [{\n            \"enc\": \"did:sov:8x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD\",\n            \"rank\": 8\n        }]\n    }\n</code></pre></p>"},{"location":"features/0445-rich-schema-mapping/#data-registry-storage","title":"Data Registry Storage","text":"<p>Aries will provide a means for writing contexts to and reading contexts from a verifiable data registry (such as a distributed ledger).</p> <p>A Mapping object will be written to the ledger in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0445-rich-schema-mapping/#aries-data-registry-interface","title":"Aries Data Registry Interface","text":"<p>Aries Data Registry Interface methods for adding and retrieving a Mapping object from the ledger comply with the generic approach described in Rich Schema Objects Common.</p> <p>This means the following methods can be used: - <code>write_rich_schema_object</code> - <code>read_rich_schema_object_by_id</code> - <code>read_rich_schema_object_by_metadata</code></p>"},{"location":"features/0445-rich-schema-mapping/#reference","title":"Reference","text":"<p>The following is a  reference implementation of various transformation algorithms.</p> <p>Here is the paper that defines Camenisch-Lysyanskaya signatures.</p> <ul> <li>0250: Rich Schema Objects</li> <li>0420: Rich Schema Objects Common </li> <li>W3C verifiable credential specification</li> </ul>"},{"location":"features/0445-rich-schema-mapping/#drawbacks","title":"Drawbacks","text":"<p>This increases the complexity of issuing verifiable credentials and verifiying the accompanying verifiable presentations. </p>"},{"location":"features/0445-rich-schema-mapping/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>A <code>schema</code> object is supported by the W3C Verifiable Credentials Data Model specification.</li> <li>It supports rich schema capabilities for credentials.</li> </ul>"},{"location":"features/0445-rich-schema-mapping/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the proposed interface generic enough to support other data registries?</li> <li>We are not defining Rich Schema objects as DID DOCs for now. We may re-consider this in future once DID DOC format is finalized.</li> <li>It may make sense to extend DID specification to include using DID for referencing Rich Schema objects.</li> <li>The proposed canonicalization form of a content to be used for DID's id-string generation is in a Draft version, so we  may find a better way to do it.</li> <li>We don't check if the specified <code>@context</code> is valid by resolving all external links.</li> </ul>"},{"location":"features/0445-rich-schema-mapping/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0446-rich-schema-cred-def/","title":"Aries RFC 0446: Aries Rich Schema Credential Definition","text":"<ul> <li>Author: Alexander Shcherbakov, Ken Ebert, Brent Zundel</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Supersedes:</li> <li>Start Date: 2019-03-16</li> <li>Tags: feature, rich-schemas</li> </ul>"},{"location":"features/0446-rich-schema-cred-def/#summary","title":"Summary","text":"<p>Credential Definition can be used by the Issuer to set public keys for a particular  Rich Schema   and Mapping. The public keys can be used for signing the credentials by the Issuer according to the order and encoding of attributes defined by the referenced Mapping.</p> <p>Credential Definition objects are processed in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0446-rich-schema-cred-def/#motivation","title":"Motivation","text":"<p>The current format for Indy credential definitions provides a method for issuers to specify a schema and provide public key data for credentials they issue. This ties the schema and public key data values to the issuer's DID. The verifier uses the credential definition to check the validity of each signed credential attribute presented to the verifier.</p> <p>The new credential definition object that uses rich schemas is a minor modification of the current Indy credential definition. The new format has the same public key data. In addition to referencing a schema, the new credential definition can also reference a mapping object.</p>"},{"location":"features/0446-rich-schema-cred-def/#tutorial","title":"Tutorial","text":""},{"location":"features/0446-rich-schema-cred-def/#intro-to-credential-definition","title":"Intro to Credential Definition","text":"<p>Credential definitions are written to the ledger so they can be used by holders and verifiers  in presentation protocol.</p> <p>A Credential Definition can reference a single Mapping and a single Rich Schema only.</p> <p>Credential Definition is a JSON object.</p> <p>Credential Definition should be immutable in most of the cases. Some application may consider it as a mutable object since the Issuer may rotate keys present there. However, rotation of Issuer's keys should be done carefully as it will invalidate all credentials issued for this key.</p>"},{"location":"features/0446-rich-schema-cred-def/#properties","title":"Properties","text":"<p>Credential definition's properties follow the generic template defined in  Rich Schema Common.</p> <p>Credential Definition's <code>content</code> field is a JSON-serialized string with the following fields:</p>"},{"location":"features/0446-rich-schema-cred-def/#signaturetype","title":"signatureType","text":"<p>Type of the signature. ZKP scheme <code>CL</code> (Camenisch-Lysyanskaya) is the only type currently supported in Indy. Other signature types, even those that do not support ZKPs, may still make use of the credential definition to link the issuer's public keys with the rich schema against which the verifiable credential was constructed.</p>"},{"location":"features/0446-rich-schema-cred-def/#mapping","title":"mapping","text":"<p>An <code>id</code> of the corresponding Mapping</p>"},{"location":"features/0446-rich-schema-cred-def/#schema","title":"schema","text":"<p>An <code>id</code> of the corresponding Rich Schema. The <code>mapping</code> must reference the same Schema.</p>"},{"location":"features/0446-rich-schema-cred-def/#publickey","title":"publicKey","text":"<p>Issuer's public keys. Consists of <code>primary</code> and <code>revocation</code> keys.</p>"},{"location":"features/0446-rich-schema-cred-def/#example-credential-definition","title":"Example Credential Definition","text":"<p>An example of the <code>content</code> field of a Credential Definition object: <pre><code>\"signatureType\": \"CL\",\n\"mapping\": \"did:sov:UVj5w8DRzcmPVDpUMr4AZhJ\",\n\"schema\": \"did:sov:U5x5w8DRzcmPVDpUMr4AZhJ\",\n\"publicKey\": {\n    \"primary\": \"...\",\n    \"revocation\": \"...\"\n}\n</code></pre></p>"},{"location":"features/0446-rich-schema-cred-def/#use-in-verifiable-credentials","title":"Use in Verifiable Credentials","text":"<p>A ZKP credential created according to the <code>CL</code> signature scheme must reference a Credential Definition used  for signing. A Credential Definition is referenced in the credentialSchema property. A Credential Definition is referenced by its <code>id</code>.</p>"},{"location":"features/0446-rich-schema-cred-def/#data-registry-storage","title":"Data Registry Storage","text":"<p>Aries will provide a means for writing contexts to and reading contexts from a verifiable data registry (such as a distributed ledger).</p> <p>A Credential Definition object will be written to the ledger in a generic way defined in  Rich Schema Objects Common.</p>"},{"location":"features/0446-rich-schema-cred-def/#aries-data-registry-interface","title":"Aries Data Registry Interface","text":"<p>Aries Data Registry Interface methods for adding and retrieving a Credential Definition object from the ledger comply with the generic approach described in Rich Schema Objects Common.</p> <p>This means the following methods can be used: - <code>write_rich_schema_object</code> - <code>read_rich_schema_object_by_id</code> - <code>read_rich_schema_object_by_metadata</code></p>"},{"location":"features/0446-rich-schema-cred-def/#reference","title":"Reference","text":"<p>The following is a  reference implementation of various transformation algorithms.</p> <p>Here is the paper that defines Camenisch-Lysyanskaya signatures.</p> <ul> <li>0250: Rich Schema Objects</li> <li>0420: Rich Schema Objects Common </li> </ul>"},{"location":"features/0446-rich-schema-cred-def/#drawbacks","title":"Drawbacks","text":"<p>This increases the complexity of issuing verifiable credentials and verifiying the accompanying verifiable presentations. </p>"},{"location":"features/0446-rich-schema-cred-def/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>A <code>credentialSchema</code> object is supported by the W3C Verifiable Credentials Data Model specification.</li> <li>It supports rich schema capabilities for credentials.</li> </ul>"},{"location":"features/0446-rich-schema-cred-def/#prior-art","title":"Prior art","text":"<p>Indy already has a Credential Definition support. </p> <p>What the prior effort lacked was a corresponding enhancement of schema infrastructure which would have provided the necessary typing of attribute values.</p>"},{"location":"features/0446-rich-schema-cred-def/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Is the proposed interface generic enough to support other data registries?</li> <li>Of all the Rich Schema objects, the CredDef most closely fits the format of a DID DOC.</li> <li>However, we are not defining Rich Schema objects as DID DOCs for now. We may re-consider this in future once DID DOC format is finalized.</li> <li>It may make sense to extend DID specification to include using DID for referencing Rich Schema objects.</li> <li>The proposed canonicalization form of a content to be used for DID's id-string generation is in a Draft version, so we  may find a better way to do it.</li> </ul>"},{"location":"features/0446-rich-schema-cred-def/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0453-issue-credential-v2/","title":"Aries RFC 0453: Issue Credential Protocol 2.0","text":"<ul> <li>Authors: Nikita Khateev, Stephen Klump, Stephen Curran</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note:  See RFC 0454 for the presentation part of using credentials.</li> <li>Supersedes: RFC 0036 Issue Credential v1.x</li> <li>Start Date: 2020-03-23</li> <li>Tags: feature, decorator, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0453-issue-credential-v2/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> <li>20240313: Version 2.0 is the current version</li> <li>20240311: Removed references to payments in the protocol to clarify to those new to the protocol that they have not been implemented by anyone.</li> </ul> <p>For a period of time, versions 2.1 and 2.2 where defined in this RFC. Those definitions were added prior to any implementations, and to date, there are no known implementations available or planned. An attempt at implementing version 2.1 was not merged into the main branch of Aries Cloud Agent Python, deemed overly complicated and not worth the effort for what amounts to an edge case (issuing multiple credentials of the same type in a single protocol instance). Further, there is a version 3.0 of this protocol that has been specified and implemented that does not include these capabilities. Thus, a decision was made that versions 2.1 and 2.2 be removed as being not accepted by the community and overly complicated to both implement and migrate from. Those interested in seeing how those capabilities were specified can look at this protocol before they were removed.</p>"},{"location":"features/0453-issue-credential-v2/#20propose-credential-and-identifiers","title":"2.0/propose-credential and identifiers","text":"<p>Version 2.0 of the protocol is introduced because of a breaking changes in the propose-credential message, replacing the (indy-specific) filtration criteria with a generalized filter attachment to align with the rest of the messages in the protocol. The previous version is 1.1/propose-credential. Version 2.0 also uses &lt;angle brackets&gt; explicitly to mark all values that may vary between instances, such as identifiers and comments.</p> <p>The \"formats\" field is added to all the messages to enable the linking the specific attachment IDs with the the format (credential format and version) of the attachment.</p> <p>The details that are part of each message type about the different attachment formats serves as a registry of the known formats and versions.</p>"},{"location":"features/0453-issue-credential-v2/#summary","title":"Summary","text":"<p>Formalizes messages used to issue a credential--whether the credential is JWT-oriented, JSON-LD-oriented, or ZKP-oriented. The general flow is similar, and this protocol intends to handle all of them. If you are using a credential type that doesn't fit this protocol, please raise a Github issue.</p>"},{"location":"features/0453-issue-credential-v2/#motivation","title":"Motivation","text":"<p>We need a standard protocol for issuing credentials. This is the basis of interoperability between Issuers and Holders.</p>"},{"location":"features/0453-issue-credential-v2/#tutorial","title":"Tutorial","text":""},{"location":"features/0453-issue-credential-v2/#name-and-version","title":"Name and Version","text":"<p><code>issue-credential</code>, version 2.0</p>"},{"location":"features/0453-issue-credential-v2/#roles","title":"Roles","text":"<p>There are two roles in this protocol: Issuer and Holder. Technically, the latter role is only potential until the protocol completes; that is, the second party becomes a Holder of a credential by completing the protocol. However, we will use the term Holder throughout, to keep things simple.</p> <p>Note: When a holder of credentials turns around and uses those credentials to prove something, they become a Prover. In the sister RFC to this one, 0454: Present Proof Protocol 2.0, the Holder is therefore renamed to Prover. Sometimes in casual conversation, the Holder role here might be called \"Prover\" as well, but more formally, \"Holder\" is the right term at this phase of the credential lifecycle.</p>"},{"location":"features/0453-issue-credential-v2/#goals","title":"Goals","text":"<p>When the goals of each role are not available because of context, goal codes may be specifically included in protocol messages. This is particularly helpful to differentiate between credentials passed between the same parties for several different reasons. A goal code included should be considered to apply to the entire thread and is not necessary to be repeated on each message. Changing the goal code may be done by including the new code in a message. All goal codes are optional, and without default.</p>"},{"location":"features/0453-issue-credential-v2/#states","title":"States","text":"<p>The choreography diagram below details how state evolves in this protocol, in a \"happy path.\" The states include</p>"},{"location":"features/0453-issue-credential-v2/#issuer-states","title":"Issuer States","text":"<ul> <li>proposal-received</li> <li>offer-sent</li> <li>request-received</li> <li>credential-issued</li> <li>done</li> </ul>"},{"location":"features/0453-issue-credential-v2/#holder-states","title":"Holder States","text":"<ul> <li>proposal-sent</li> <li>offer-received</li> <li>request-sent</li> <li>credential-received</li> <li>done</li> </ul> <p>Errors might occur in various places. For example, an Issuer might offer a credential for a price that the Holder is unwilling to pay. All errors are modeled with a <code>problem-report</code> message. Easy-to-anticipate errors reset the flow as shown in the diagrams, and use the code <code>issuance-abandoned</code>; more exotic errors (e.g., server crashed at Issuer headquarters in the middle of a workflow) may have different codes but still cause the flow to be abandoned in the same way. That is, in this version of the protocol, all errors cause the state of both parties (the sender and the receiver of the <code>problem-report</code>) to revert to <code>null</code> (meaning it is no longer engaged in the protocol at all). Future versions of the protocol may allow more granular choices (e.g., requesting and receiving a (re-)send of the <code>issue-credential</code> message if the Holder times out while waiting in the <code>request-sent</code> state).</p> <p>The state table outlines the protocol states and transitions.</p>"},{"location":"features/0453-issue-credential-v2/#messages","title":"Messages","text":"<p>The Issue Credential protocol consists of these messages:</p> <ul> <li><code>propose-credential</code> - potential Holder to Issuer (optional). Tells what the Holder hopes to receive.</li> <li><code>offer-credential</code> - Issuer to potential Holder (optional for some credential implementations; required for Hyperledger Indy). Tells what the Issuer intends to issue, and possibly, the price the Issuer expects to be paid.</li> <li><code>request-credential</code> - potential Holder to Issuer. If neither of the previous message types is used, this is the message that begins the protocol.</li> <li><code>issue-credential</code> - Issuer to new Holder. Attachment payload contains the actual credential.</li> </ul> <p>In addition, the <code>ack</code> and <code>problem-report</code> messages are adopted into the protocol for confirmation and error handling.</p>"},{"location":"features/0453-issue-credential-v2/#message-attachments","title":"Message Attachments","text":"<p>This protocol is about the messages that must be exchanged to issue verifiable credentials, NOT about the specifics of particular verifiable credential schemes. DIDComm attachments are deliberately used in messages to isolate the protocol flow/semantics from the credential artifacts themselves as separate constructs. Attachments allow credential formats and this protocol to evolve through versioning milestones independently instead of in lockstep. Links are provided in the message descriptions below, to describe how the protocol adapts to specific verifiable credential implementations.</p> <p>The attachment items in the messages are arrays. The arrays are provided to support the issuing of different credential formats (e.g. ZKP, JSON-LD JWT, or other) containing the same data (claims). The arrays are not to be used for issuing credentials with different claims. The <code>formats</code> field of each message associates each attachment with the format (and version) of the attachment.</p> <p>A registry of attachment formats is provided in this RFC within the message type sections. A sub-section should be added for each attachment format type (and optionally, each version). Updates to the attachment type formats does NOT impact the versioning of the Issue Credential protocol. Formats are flexibly defined. For example, the first definitions are for <code>hlindy/cred-abstract@v2.0</code> et al., assuming that all Hyperledger Indy implementations and ledgers will use a common format. However, if a specific instance of Indy uses a different format, another format value can be documented as a new registry entry.</p> <p>Any of the 0017-attachments RFC embedded inline attachments can be used. In the examples below, <code>base64</code> is used in most cases, but implementations MUST expect any of the formats.</p>"},{"location":"features/0453-issue-credential-v2/#choreography-diagram","title":"Choreography Diagram","text":"<p>Note: This diagram was made in draw.io. To make changes:</p> <ul> <li>upload the drawing HTML from this folder to the draw.io site (Import From...GitHub),</li> <li>make changes,</li> <li>export the picture and HTML to your local copy of this repo, and</li> <li>submit a pull request.</li> </ul> <p>The protocol has 3 alternative beginnings:</p> <ol> <li>The Issuer can begin with an offer.</li> <li>The Holder can begin with a proposal.</li> <li>the Holder can begin with a request.</li> </ol> <p>The offer and proposal messages are part of an optional negotiation phase and may trigger back-and-forth counters. A request is not subject to negotiation; it can only be accepted or rejected.</p> <p></p>"},{"location":"features/0453-issue-credential-v2/#propose-credential","title":"Propose Credential","text":"<p>An optional message sent by the potential Holder to the Issuer to initiate the protocol or in response to an <code>offer-credential</code> message when the Holder wants some adjustments made to the credential data offered by Issuer.</p>  Note: In Hyperledger Indy, where the `request-credential` message can **only** be sent in response to an `offer-credential` message, the `propose-credential` message is the only way for a potential Holder to initiate the workflow.  <p>Message format:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/propose-credential\",\n    \"@id\": \"&lt;uuid of propose-message&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\"\n        }\n    ],\n    \"filters~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Proposal, so the proposal can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>credential_preview</code> -- an optional JSON-LD object that represents the credential data that Prover wants to receive. It matches the schema of Credential Preview.</li> <li><code>formats</code> -- contains an entry for each <code>filters~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable credential format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>filters~attach</code> -- an array of attachments that further define the credential being proposed. This might be used to clarify which formats or format versions are wanted.</li> </ul>"},{"location":"features/0453-issue-credential-v2/#propose-attachment-registry","title":"Propose Attachment Registry","text":"Credential Format Format Value Link to Attachment Format Comment DIF Credential Manifest <code>dif/credential-manifest@v1.0</code> <code>propose-credential</code> attachment format Linked Data Proof VC Detail <code>aries/ld-proof-vc-detail@v1.0</code> <code>ld-proof-vc-detail</code> attachment format Hyperledger Indy Credential Filter <code>hlindy/cred-filter@v2.0</code> <code>cred filter</code> format Hyperledger AnonCreds Credential Filter <code>anoncreds/credential-filter@v1.0</code> <code>Credential Filter</code> format"},{"location":"features/0453-issue-credential-v2/#offer-credential","title":"Offer Credential","text":"<p>A message sent by the Issuer to the potential Holder, describing the credential they intend to offer and possibly the price they expect to be paid. In Hyperledger Indy, this message is required, because it forces the Issuer to make a cryptographic commitment to the set of fields in the final credential and thus prevents Issuers from inserting spurious data. In credential implementations where this message is optional, an Issuer can use the message to negotiate the issuing following receipt of a <code>request-credential</code> message.</p> <p>Message Format:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/offer-credential\",\n    \"@id\": \"&lt;uuid of offer message&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"replacement_id\": \"&lt;issuer unique id&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"offers~attach\": [\n        {\n            \"@id\": \"&lt;attach@id value&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>replacement_id</code> -- an optional field to help coordinate credential replacement. When this is present and matches the <code>replacement_id</code> of a previously issued credential, it may be used to inform the recipient that the offered credential is considered to be a replacement to the previous credential. This value is unique to the issuer. It must not be used in a credential presentation.</li> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Offer, so the offer can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>credential_preview</code> -- a JSON-LD object that represents the credential data that Issuer is willing to issue. It matches the schema of Credential Preview;</li> <li><code>formats</code> -- contains an entry for each <code>offers~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable credential format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>offers~attach</code> -- an array of attachments that further define the credential being offered. This might be used to clarify which formats or format versions will be issued.</li> </ul> <p>It is possible for an Issuer to add a <code>~timing.expires_time</code> decorator to this message to convey the idea that the offer will expire at a particular point in the future. Such behavior is not a special part of this protocol, and support for it is not a requirement of conforming implementations; the <code>~timing</code> decorator is simply a general possibility for any DIDComm message. We mention it here just to note that the protocol can be enriched in composable ways.</p>"},{"location":"features/0453-issue-credential-v2/#offer-attachment-registry","title":"Offer Attachment Registry","text":"Credential Format Format Value Link to Attachment Format Comment DIF Credential Manifest <code>dif/credential-manifest@v1.0</code> <code>offer-credential</code> attachment format Hyperledger Indy Credential Abstract <code>hlindy/cred-abstract@v2.0</code> <code>cred abstract</code> format Linked Data Proof VC Detail <code>aries/ld-proof-vc-detail@v1.0</code> <code>ld-proof-vc-detail</code> attachment format Hyperledger AnonCreds Credential Offer <code>anoncreds/credential-offer@v1.0</code> <code>Credential Offer</code> format W3C VC - Data Integrity Proof Credential Offer <code>didcomm/w3c-di-vc-offer@v0.1</code> <code>Credential Offer</code> format"},{"location":"features/0453-issue-credential-v2/#request-credential","title":"Request Credential","text":"<p>This is a message sent by the potential Holder to the Issuer, to request the issuance of a credential. Where circumstances do not require a preceding Offer Credential message (e.g., there is no cost to issuance that the Issuer needs to explain in advance, and there is no need for cryptographic negotiation), this message initiates the protocol. When using the Hyperledger Indy AnonCreds verifiable credential format, this message can only be sent in response to an <code>offer-credential</code> message.</p> <p>Message Format:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/request-credential\",\n    \"@id\": \"&lt;uuid of request message&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"requests~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        },\n    ]\n}\n</code></pre> <p>Description of Fields:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>comment</code> -- an optional field that provides human readable information about this Credential Request, so it can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>formats</code> -- contains an entry for each <code>requests~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable credential format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>requests~attach</code> -- an array of attachments defining the requested formats for the credential.</li> </ul>"},{"location":"features/0453-issue-credential-v2/#request-attachment-registry","title":"Request Attachment Registry","text":"Credential Format Format Value Link to Attachment Format Comment DIF Credential Manifest <code>dif/credential-manifest@v1.0</code> <code>request-credential</code> attachment format Hyperledger Indy Credential Request <code>hlindy/cred-req@v2.0</code> <code>cred request</code> format Linked Data Proof VC Detail <code>aries/ld-proof-vc-detail@v1.0</code> <code>ld-proof-vc-detail</code> attachment format Hyperledger AnonCreds Credential Request <code>anoncreds/credential-request@v1.0</code> <code>Credential Request</code> format W3C VC - Data Integrity Proof Credential Request <code>didcomm/w3c-di-vc-request@v0.1</code> <code>Credential Request</code> format"},{"location":"features/0453-issue-credential-v2/#issue-credential","title":"Issue Credential","text":"<p>This message contains a verifiable credential being issued as an attached payload. It is sent in response to a valid Request Credential message.</p> <p>Message Format:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/issue-credential\",\n    \"@id\": \"&lt;uuid of issue message&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"replacement_id\": \"&lt;issuer unique id&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"credentials~attach\": [\n        {\n            \"@id\": \"&lt;attachment-id&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>replacement_id</code> -- an optional field that provides an identifier used to manage credential replacement. When this value is present and matches the <code>replacement_id</code> of a previously issued credential, this credential may be considered as a replacement for that credential. This value is unique to the issuer. It must not be used in a credential presentation.</li> <li><code>comment</code> -- an optional field that provides human readable information about the issued credential, so it can be evaluated by human judgment. Follows DIDComm conventions for l10n.</li> <li><code>formats</code> -- contains an entry for each <code>credentials~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable credential format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>credentials~attach</code> -- an array of attachments containing the issued credentials.</li> </ul>"},{"location":"features/0453-issue-credential-v2/#credentials-attachment-registry","title":"Credentials Attachment Registry","text":"Credential Format Format Value Link to Attachment Format Comment Linked Data Proof VC <code>aries/ld-proof-vc@v1.0</code> <code>ld-proof-vc</code> attachment format Hyperledger Indy Credential <code>hlindy/cred@v2.0</code> credential format Hyperledger AnonCreds Credential <code>anoncreds/credential@v1.0</code> <code>Credential</code> format W3C VC - Data Integrity Proof Credential <code>didcomm/w3c-di-vc@v0.1</code> <code>Credential</code> format"},{"location":"features/0453-issue-credential-v2/#adopted-problem-report","title":"Adopted Problem Report","text":"<p>The problem-report message is adopted by this protocol. <code>problem-report</code> messages can be used by either party to indicate an error in the protocol.</p>"},{"location":"features/0453-issue-credential-v2/#preview-credential","title":"Preview Credential","text":"<p>This is not a message but an inner object for other messages in this protocol. It is used construct a preview of the data for the credential that is to be issued. Its schema follows:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/credential-preview\",\n    \"attributes\": [\n        {\n            \"name\": \"&lt;attribute name&gt;\",\n            \"mime-type\": \"&lt;type&gt;\",\n            \"value\": \"&lt;value&gt;\"\n        },\n        // more attributes\n    ]\n}\n</code></pre> <p>The main element is <code>attributes</code>. It is an array of (object) attribute specifications; the subsections below outline their semantics.</p>"},{"location":"features/0453-issue-credential-v2/#attribute-name","title":"Attribute Name","text":"<p>The mandatory <code>\"name\"</code> key maps to the attribute name as a string.</p>"},{"location":"features/0453-issue-credential-v2/#mime-type-and-value","title":"MIME Type and Value","text":"<p>The optional <code>mime-type</code> advises the issuer how to render a binary attribute, to judge its content for applicability before issuing a credential containing it. Its value parses case-insensitively in keeping with MIME type semantics of RFC 2045. If <code>mime-type</code> is missing, its value is null.</p> <p>The mandatory <code>value</code> holds the attribute value:</p> <ul> <li>if <code>mime-type</code> is missing (null), then <code>value</code> is a string. In other words, implementations interpret it the same as any other key+value pair in JSON</li> <li>if <code>mime-type</code> is not null, then <code>value</code> is always a base64url-encoded string that represents a binary BLOB, and <code>mime-type</code> tells how to interpret the BLOB after base64url-decoding.</li> </ul>"},{"location":"features/0453-issue-credential-v2/#threading","title":"Threading","text":"<p>Threading can be used to initiate a sub-protocol during an issue credential protocol instance. For example, during credential issuance, the Issuer may initiate a child message thread to execute the <code>Present Proof</code> sub-protocol to have the potential Holder (now acting as a Prover) prove attributes about themselves before issuing the credential. Depending on circumstances, this might be a best practice for preventing credential fraud at issuance time.</p> <p>If threading were added to all of the above messages, a <code>~thread</code> decorator would be present, and later messages in the flow would reference the <code>@id</code> of earlier messages to stitch the flow into a single coherent sequence. Details about threading can be found in the 0008: Message ID and Threading RFC.</p>"},{"location":"features/0453-issue-credential-v2/#limitations","title":"Limitations","text":"<p>Smart contracts may be missed in ecosystem, so operation \"issue credential after payment received\" is not atomic. It\u2019s possible case that malicious issuer will charge first and then will not issue credential in fact. But this situation should be easily detected and appropriate penalty should be applied in such type of networks.</p>"},{"location":"features/0453-issue-credential-v2/#negotiation-and-preview","title":"Negotiation and Preview","text":"<p>Negotiation prior to issuing the credential can be done using the <code>offer-credential</code> and <code>propose-credential</code> messages. A common negotiation use case would be about the data to go into the credential. For that, the <code>credential_preview</code> element is used.</p>"},{"location":"features/0453-issue-credential-v2/#drawbacks","title":"Drawbacks","text":"<p>None documented</p>"},{"location":"features/0453-issue-credential-v2/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Attention should be paid by the Aries community to other credential issuance protocols being proposed/used in other communities to ensure this RFC could support those protocols.</li> <li>Digital Bazaar has proposed the Credential Handler API (CHAPI) protocol that is being considered by the W3C Credentials Community Group.</li> </ul>"},{"location":"features/0453-issue-credential-v2/#prior-art","title":"Prior art","text":"<p>See RFC 0036 Issue Credential, v1.x.</p>"},{"location":"features/0453-issue-credential-v2/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>We might need to propose a new MIME type for credential (the same way as .docx is not processed as generic xml). See this issue against the W3C/vc-data-model.</li> </ul>"},{"location":"features/0453-issue-credential-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0454-present-proof-v2/","title":"Aries RFC 0454: Present Proof Protocol 2.0","text":"<ul> <li>Authors: Nikita Khateev, Stephen Curran</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note:  See RFC 0453 for the corresponding issue credential protocol.</li> <li>Supersedes: RFC 0037</li> <li>Start Date: 2020-05-27</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0454-present-proof-v2/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> <li>20240311: Version 2.0 is the current version</li> </ul> <p>For a period of time, versions 2.1 and 2.2 where defined in this RFC. Those definitions were added prior to any implementations, and to date, there are no known implementations available or planned. An attempt at implementing version 2.1 of the associated \"issue multiple credentials\" was not merged into the main branch of Aries Cloud Agent Python, deemed overly complicated and not worth the effort for what amounts to an edge case (presenting multiple presentations of the same type in a single protocol instance). Further, there is a version 3.0 of this protocol that has been specified and implemented that does not include these capabilities. Thus, a decision was made that versions 2.1 and 2.2 be removed as being not accepted by the community and overly complicated to both implement and migrate from. Those interested in seeing how those capabilities were specified can look at this protocol before they were removed.</p>"},{"location":"features/0454-present-proof-v2/#20-alignment-with-rfc-0453-issue-credential","title":"2.0 - Alignment with RFC 0453 Issue Credential","text":"<ul> <li>The \"formats\" field is added to all the messages to link the specific attachment IDs with the verifiable presentation format and version of the attachment.</li> <li>The details that are part of each message type about the different attachment formats serves as a registry of the known formats and versions.</li> <li>Version 2.0 uses &lt;angle brackets&gt; explicitly to mark all values that may vary between instances, such as identifiers and comments.</li> </ul>"},{"location":"features/0454-present-proof-v2/#summary","title":"Summary","text":"<p>A protocol supporting a general purpose verifiable presentation exchange regardless of the specifics of the underlying verifiable presentation request and verifiable presentation format.</p>"},{"location":"features/0454-present-proof-v2/#motivation","title":"Motivation","text":"<p>We need a standard protocol for a verifier to request a presentation from a prover, and for the prover to respond by presenting a proof to the verifier. When doing that exchange, we want to provide a mechanism for the participants to negotiate the underlying format and content of the proof.</p>"},{"location":"features/0454-present-proof-v2/#tutorial","title":"Tutorial","text":""},{"location":"features/0454-present-proof-v2/#name-and-version","title":"Name and Version","text":"<p><code>present-proof</code>, version 2.0</p>"},{"location":"features/0454-present-proof-v2/#key-concepts","title":"Key Concepts","text":"<p>This protocol is about the messages to support the presentation of verifiable claims, not about the specifics of particular verifiable presentation formats. DIDComm attachments are deliberately used in messages to make the protocol agnostic to specific verifiable presentation format payloads. Links are provided in the message data element descriptions to details of specific verifiable presentation implementation data structures.</p> <p>Diagrams in this protocol were made in draw.io. To make changes:</p> <ul> <li>upload the drawing HTML from this folder to the draw.io site (Import From...GitHub),</li> <li>make changes,</li> <li>export the picture and HTML to your local copy of this repo, and</li> <li>submit a pull request.</li> </ul>"},{"location":"features/0454-present-proof-v2/#roles","title":"Roles","text":"<p>The roles are <code>verifier</code> and <code>prover</code>.  The <code>verifier</code> requests the presentation of a proof and verifies the presentation, while the <code>prover</code> prepares the proof and presents it to the verifier. Optionally, although unlikely from a business sense, the <code>prover</code> may initiate an instance of the protocol using the <code>propose-presentation</code> message.</p>"},{"location":"features/0454-present-proof-v2/#goals","title":"Goals","text":"<p>When the goals of each role are not available because of context, goal codes may be specifically included in protocol messages. This is particularly helpful to differentiate between credentials passed between the same parties for several different reasons. A goal code included should be considered to apply to the entire thread and is not necessary to be repeated on each message. Changing the goal code may be done by including the new code in a message. All goal codes are optional, and without default.</p>"},{"location":"features/0454-present-proof-v2/#states","title":"States","text":"<p>The following states are defined and included in the state transition table below.</p>"},{"location":"features/0454-present-proof-v2/#states-for-verifier","title":"States for Verifier","text":"<ul> <li>request-sent</li> <li>proposal-received</li> <li>presentation-received</li> <li>abandoned</li> <li>done</li> </ul>"},{"location":"features/0454-present-proof-v2/#states-for-prover","title":"States for Prover","text":"<ul> <li>request-received</li> <li>proposal-sent</li> <li>presentation-sent</li> <li>abandoned</li> <li>done</li> </ul> <p>For the most part, these states map onto the transitions shown in both the state transition table above, and in the choreography diagram (below) in obvious ways. However, a few subtleties are worth highlighting:</p> <ul> <li> <p>The final states for both the prover and verifier are <code>done</code> or <code>abandoned</code>, and once reached, no further updates to the protocol instance are expected.</p> </li> <li> <p>The <code>ack-presentation</code> is sent or not based on the value of <code>will_confirm</code> in the <code>request-presentation</code>. Whether an <code>ack-presentation</code> is expected or not determines whether the states <code>presentation-sent</code> and <code>presentation-received</code> are used at all in a protocol instance.</p> </li> <li> <p>The <code>ack-presentation</code> message should reflect the business validation of the proof (does the proof satisfy the business need?) not just the cryptographic verification. Ideally, those are as tightly aligned as possible.</p> </li> <li> <p>When a Prover makes a (counter-)proposal, it transitions to the <code>proposal-sent</code> state. This state is only present by implication in the choreography diagram; it essentially equates to the null or begin state in that the Prover does nothing until a presentation request arrives, triggering the leftmost transition for the Prover.</p> </li> <li> <p>Errors might occur in various places. For example, a Prover might decide not to respond to a <code>presentation-request</code> or a verifier may time out waiting for the Prover to supply a <code>presentation</code>. Errors should trigger a <code>problem-report</code>. In this version of the protocol, all errors cause the state of both parties (the sender and the receiver of the <code>problem-report</code>) to transition to the terminal <code>abandoned</code> state (meaning it is no longer engaged in the protocol at all).</p> </li> </ul>"},{"location":"features/0454-present-proof-v2/#choreography-diagram","title":"Choreography Diagram","text":""},{"location":"features/0454-present-proof-v2/#messages","title":"Messages","text":"<p>The present proof protocol consists of these messages:</p> <ul> <li><code>propose-presentation</code> - Prover to Verifier (optional) - propose a presentation or send a counter-proposal in response to a <code>request-presentation</code> message</li> <li><code>request-presentation</code> - Verifier to Prover - request a presentation</li> <li><code>presentation</code> - Prover to Verifier - provide a presentation in response to a request</li> </ul> <p>In addition, the <code>ack</code> and <code>problem-report</code> messages are adopted into the protocol for confirmation and error handling.</p> <p>The messages that include <code>~attach</code> attachments may use any form of the embedded attachment. In the examples below, the forms of the attachment are arbitrary.</p> <p>The <code>~attach</code> array is to be used to enable a single presentation to be requested/delivered in different verifiable presentation formats. The ability to have multiple attachments must not be used to request/deliver multiple different presentations in a single instance of the protocol.</p>"},{"location":"features/0454-present-proof-v2/#propose-presentation","title":"Propose Presentation","text":"<p>An optional message sent by the prover to the verifier to initiate a proof presentation process, or in response to a <code>request-presentation</code> message when the prover wants to propose using a different presentation format or request. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/propose-presentation\",\n    \"@id\": \"&lt;uuid-propose-presentation&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"some comment\",\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"proposals~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"json\": \"&lt;json&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>comment</code> -- a field that provides some human readable information about the proposed presentation.</li> <li><code>formats</code> -- contains an entry for each <code>filter~attach</code> array entry, including an optional value of the attachment <code>@id</code> (if attachments are present) and the verifiable presentation format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format \"Attachment\" sections immediately below.</li> <li><code>proposals~attach</code> -- an optional array of attachments that further define the presentation request being proposed. This might be used to clarify which formats or format versions are wanted.</li> </ul> <p>If the <code>proposals~attach</code> is not provided, the <code>attach_id</code> item in the <code>formats</code> array should not be provided. That form of the <code>propose-presentation</code> message is to indicate the presentation formats supported by the prover, independent of the verifiable presentation request content.</p>"},{"location":"features/0454-present-proof-v2/#negotiation-and-preview","title":"Negotiation and Preview","text":"<p>Negotiation prior to the delivery of the presentation can be done using the <code>propose-presentation</code> and <code>request-presentation</code> messages. The common negotiation use cases would be about the claims to go into the presentation and the format of the verifiable presentation.</p>"},{"location":"features/0454-present-proof-v2/#propose-attachment-registry","title":"Propose Attachment Registry","text":"Presentation Format Format Value Link to Attachment Format Comment Hyperledger Indy Proof Req <code>hlindy/proof-req@v2.0</code> proof request format Used to propose as well as request proofs. DIF Presentation Exchange <code>dif/presentation-exchange/definitions@v1.0</code> <code>propose-presentation</code> attachment format Hyperledger AnonCreds Proof Request <code>anoncreds/proof-request@v1.0</code> <code>Proof Request</code> format Used to propose as well as request proofs."},{"location":"features/0454-present-proof-v2/#request-presentation","title":"Request Presentation","text":"<p>From a verifier to a prover, the <code>request-presentation</code> message describes values that need to be revealed and predicates that need to be fulfilled. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/request-presentation\",\n    \"@id\": \"&lt;uuid-request&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"some comment\",\n    \"will_confirm\": true,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"request_presentations~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;base64 data&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>comment</code> -- a field that provides some human readable information about this request for a presentation.</li> <li><code>will_confirm</code> -- an optional field that defaults to <code>false</code> to indicate that the verifier will or will not send a post-presentation confirmation <code>ack</code> message</li> <li><code>formats</code> -- contains an entry for each <code>request_presentations~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable presentation request format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format Attachment registry immediately below.</li> <li><code>request_presentations~attach</code> -- an array of attachments containing the acceptable verifiable presentation requests.</li> </ul>"},{"location":"features/0454-present-proof-v2/#presentation-request-attachment-registry","title":"Presentation Request Attachment Registry","text":"Presentation Format Format Value Link to Attachment Format Comment Hyperledger Indy Proof Req <code>hlindy/proof-req@v2.0</code> proof request format Used to propose as well as request proofs. DIF Presentation Exchange <code>dif/presentation-exchange/definitions@v1.0</code> <code>propose-presentation</code> attachment format Hyperledger AnonCreds Proof Request <code>anoncreds/proof-request@v1.0</code> <code>Proof Request</code> format Used to propose as well as request proofs."},{"location":"features/0454-present-proof-v2/#presentation","title":"Presentation","text":"<p>This message is a response to a Presentation Request message and contains signed presentations. Schema:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/presentation\",\n    \"@id\": \"&lt;uuid-presentation&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"some comment\",\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\" : \"&lt;format-and-version&gt;\",\n        }\n    ],\n    \"presentations~attach\": [\n        {\n            \"@id\": \"&lt;attachment identifier&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"sha256\": \"f8dca1d901d18c802e6a8ce1956d4b0d17f03d9dc5e4e1f618b6a022153ef373\",\n                \"links\": [\"https://ibb.co/TtgKkZY\"]\n            }\n        }\n    ]\n}\n</code></pre> <p>Description of fields:</p> <ul> <li><code>comment</code> -- a field that provides some human readable information about this presentation.</li> <li><code>goal_code</code> -- optional field that indicates the goal of the message sender.</li> <li><code>formats</code> -- contains an entry for each <code>presentations~attach</code> array entry, providing the the value of the attachment <code>@id</code> and the verifiable presentation format and version of the attachment. Accepted values for the <code>format</code> items are provided in the per format Attachment registry immediately below.</li> <li><code>presentations~attach</code> -- an array of attachments containing the presentation in the requested format(s).</li> </ul> <p>If the prover wants an acknowledgement that the presentation was accepted, this message may be decorated with the <code>~please-ack</code> decorator using the <code>OUTCOME</code> acknowledgement request. This is not necessary if the verifier has indicated it will send an <code>ack-presentation</code> using the <code>will_confirm</code> property. Outcome in the context of this protocol is the definition of \"successful\" as described in Ack Presentation. Note that this is different from the default behavior as described in 0317: Please ACK Decorator. It is then best practice for the new Verifier to respond with an explicit <code>ack</code> message as described in the please ack decorator RFC.</p>"},{"location":"features/0454-present-proof-v2/#presentations-attachment-registry","title":"Presentations Attachment Registry","text":"Presentation Format Format Value Link to Attachment Format Comment Hyperledger Indy Proof <code>hlindy/proof@v2.0</code> proof format DIF Presentation Exchange <code>dif/presentation-exchange/submission@v1.0</code> <code>propose-presentation</code> attachment format Hyperledger AnonCreds Proof <code>anoncreds/proof@v1.0</code> <code>Proof</code> format"},{"location":"features/0454-present-proof-v2/#ack-presentation","title":"Ack Presentation","text":"<p>A message from the verifier to the prover that the <code>Present Proof</code> protocol was completed successfully and is now in the <code>done</code> state. The message is an adopted <code>ack</code> from the RFC 0015 acks protocol. The definition of \"successful\" in this protocol means the acceptance of the presentation in whole, i.e. the proof is verified and the contents of the proof are acknowledged.</p>"},{"location":"features/0454-present-proof-v2/#problem-report","title":"Problem Report","text":"<p>A message from the verifier to the prover that follows the <code>presentation</code> message to indicate that the <code>Present Proof</code> protocol was completed unsuccessfully and is now in the <code>abandoned</code> state. The message is an adopted <code>problem-report</code> from the RFC 0015 report-problem protocol. The definition of \"unsuccessful\" from a business sense is up to the verifier. The elements of the <code>problem-report</code> message can provide information to the prover about why the protocol instance was unsuccessful.</p> <p>Either party may send a <code>problem-report</code> message earlier in the flow to terminate the protocol before its normal conclusion.</p>"},{"location":"features/0454-present-proof-v2/#reference","title":"Reference","text":"<p>Details are covered in the Tutorial section.</p>"},{"location":"features/0454-present-proof-v2/#drawbacks","title":"Drawbacks","text":"<p>The Indy format of the proposal attachment as proposed above does not allow nesting of logic along the lines of \"A and either B or C if D, otherwise A and B\", nor cross-credential options such as proposing a legal name issued by either (for example) a specific financial institution or government entity.</p> <p>The verifiable presentation standardization work being conducted in parallel to this in DIF and the W3C Credentials Community Group (CCG) should be included in at least the <code>Registry</code> tables of this document, and ideally used to eliminate the need for presentation format-specific options.</p>"},{"location":"features/0454-present-proof-v2/#rationale-and-alternatives","title":"Rationale and alternatives","text":""},{"location":"features/0454-present-proof-v2/#prior-art","title":"Prior art","text":"<p>The previous major version of this protocol is RFC 0037 Present Proof protocol and implementations.</p>"},{"location":"features/0454-present-proof-v2/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>There might need to be a way to associate a payment with the present proof protocol.</li> </ul>"},{"location":"features/0454-present-proof-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0482-coprotocol-protocol/","title":"Aries RFC 0482: Coprotocol Protocol 0.5","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: STALLED</li> <li>Since: 2024-04-03</li> <li>Status Note: No implementations have been created.</li> <li>Start Date: 2020-02-03</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0482-coprotocol-protocol/#summary","title":"Summary","text":"<p>Allows coprotocols to interact with one another.</p>"},{"location":"features/0482-coprotocol-protocol/#motivation","title":"Motivation","text":"<p>We need a standard way for one protocol to invoke another, giving it input, getting its output, detaching, and debugging.</p>"},{"location":"features/0482-coprotocol-protocol/#tutorial","title":"Tutorial","text":""},{"location":"features/0482-coprotocol-protocol/#name-and-version","title":"Name and Version","text":"<p>The name of this protocol is \"Coprotocol Protocol 0.5\" It is identified by the PIURI \"https://didcomm.org/coprotocol/0.5\".</p>"},{"location":"features/0482-coprotocol-protocol/#key-concepts","title":"Key Concepts","text":"<p>Please make sure you are familiar with the general concept of coprotocols, as set forth in Aries RFC 0478. A working knowledge of the terminology and mental model explained there are foundational.</p>"},{"location":"features/0482-coprotocol-protocol/#roles","title":"Roles","text":"<p>The <code>caller</code> role is played by the entity giving input and getting output. The <code>called</code> is the entity getting input and giving output.</p>"},{"location":"features/0482-coprotocol-protocol/#states","title":"States","text":"<p>The caller's normal state progression is <code>null</code> -&gt; <code>detached</code> -&gt; <code>attached</code> -&gt; <code>done</code>. It is also possible to return to a <code>detached</code> state without ever reaching <code>done</code>.</p> <p>The coprotocols normal state progression is <code>null</code> -&gt; <code>attached</code> -&gt; <code>done</code>.</p> <p></p>"},{"location":"features/0482-coprotocol-protocol/#messages","title":"Messages","text":"<p>Note: the discussion below is about how to launch and interact with any coprotocol. However, for concreteness we frame the walkthru in terms of a co-protocol that makes a payment. You can see an example definition of such a coprotocol in RFC 0478.</p> <p>The protocol consists of 5 messages: <code>bind</code>, <code>attach</code>, <code>input</code>, <code>output</code>, <code>detach</code> and the adopted <code>problem-report</code> (for propagating errors).</p> <p>The protocol begins with a <code>bind</code> message sent from <code>caller</code> to <code>called</code>. This message basically says, \"I would like to interact with a new coprotocol instance having the following characteristics and the following mapping of identifiers to roles.\" It might look like this: </p> <pre><code>{\n    \"@id\": \"4d116a88-1314-4af5-9b3c-848456b8b3dd\",\n    \"@type\": \"https://didcomm.org/coprotocol/1.0/bind\",\n    \"goal_code\": \"aries.buy.make-payment\",\n    \"co_binding_id\": null,\n    \"cast\": [\n        // Recipient of the bind message (id = null) should be payee.\n        {\"role\": \"payee\", \"id\": null},\n        // The payer will be did:peer:abc123.\n        {\"role\": \"payer\", \"id\": \"did:peer:abc123\" }\n    ]\n}\n</code></pre> <p>When a <code>called</code> agent receives this message, it should discover what protocol implementations are available that match the criteria, and sort the candidates by preference. (Note that additional criteria can be added besides those shown here; see the Reference section.) This could involve enumerating not-yet-loaded plugins. It could also involve negotiating a protocol with the remote party (e.g., the DID playing the role of <code>payer</code> in the example above) by querying its capabilities using the Discover Features Protocol. Of course, the capabilities of remote parties could also be cached to avoid this delay, or they could be predicted without confirmation, if circumstances suggest that's the best tradeoff. Once the candidates are sorted by preference, the best match should be selected. The coprotocol is NOT launched, but it is awaiting launch. The <code>called</code> agent should now generate an <code>attach</code> message that acknowledges the request to bind and tells the <code>caller</code> how to interact:</p> <pre><code>{\n    \"@id\": \"b3dd4d11-6a88-9b3c-4af5-848456b81314\",\n    \"@type\": \"https://didcomm.org/coprotocol/1.0/attach\",\n    \"~thread\": { \"pthid\": \"4d116a88-1314-4af5-9b3c-848456b8b3dd\"},\n    // This is the best match.\n    \"piuri\": \"https://didcomm.org/pay-with-venmo/1.3\"\n}\n</code></pre> <p>The <code>@id</code> of the <code>bind</code> message (also the <code>~thread.pthid</code> of the <code>attach</code> response) becomes a permanent identifier for the coprotocol binding. Both the caller and the coprotocol instance code can use it to lookup state as needed. The <code>caller</code> can now kick off/invoke the protocol with an <code>input</code> message:</p> <pre><code>{\n    \"@id\": \"56b81314-6a88-9b3c-4af5-b3dd4d118484\",\n    \"@type\": \"https://didcomm.org/coprotocol/1.0/input\",\n    \"~thread\": { \"pthid\": \"4d116a88-1314-4af5-9b3c-848456b8b3dd\"},\n    \"interaction_point\": \"invoke\",\n    \"data\": [\n        \"amount\": 1.23,\n        \"currency\": \"INR\",\n        \"bill_of_sale\": {\n            // describes what's being purchased\n        }\n    ]\n}\n</code></pre> <p>This allows the <code>caller</code> to invoke the bound coprotocol instance, and to pass it any number of named inputs.</p> <p>Later, when the coprotocol instance wants to emit an output from <code>called</code> to <code>caller</code>, it uses an <code>output</code> message (in this case, one matching the <code>preauth</code> interaction point declared in the sample coprotocol definition in RFC 0478):</p> <pre><code>{\n    \"@id\": \"9b3c56b8-6a88-f513-4a14-4d118484b3dd\",\n    \"@type\": \"https://didcomm.org/coprotocol/1.0/output\",\n    \"~thread\": { \"pthid\": \"4d116a88-1314-4af5-9b3c-848456b8b3dd\"},\n    \"interaction_point\": \"preauth\",\n    \"data\": [\n        \"code\": \"6a884d11-13149b3c\",\n    ]\n}\n</code></pre> <p>If a <code>caller</code> wants to detach, it uses a <code>detach</code> message. This leaves the coprotocol running on <code>called</code>; all inputs that it emits are sent to the bitbucket, and it advances on its normal state trajectory as if it were a wholly independent protocol:</p> <pre><code>{\n    \"@id\": \"7a3c56b8-5b88-d413-4a14-ca118484b3ee\",\n    \"@type\": \"https://didcomm.org/coprotocol/1.0/detach\",\n    \"~thread\": { \"pthid\": \"4d116a88-1314-4af5-9b3c-848456b8b3dd\"}\n}\n</code></pre> <p>A <code>caller</code> can re-attach by sending a new <code>bind</code> message; this time, the <code>co_binding_id</code> field should have the coprotocol binding id from the original <code>attach</code> message. Other fields in the message are optional; if present, they constitute a check that the binding in question has the properties the caller expects. The reattachment is confrimed by a new <code>attach</code> message.</p>"},{"location":"features/0482-coprotocol-protocol/#reference","title":"Reference","text":""},{"location":"features/0482-coprotocol-protocol/#bind","title":"<code>bind</code>","text":"<pre><code>{\n    \"@id\": \"4d116a88-1314-4af5-9b3c-848456b8b3dd\",\n    \"@type\": \"https://didcomm.org/coprotocol/1.0/bind\",\n    // I'd like to be bound to a coprotocol that achieves this goal.\n    \"goal_code\": \"aries.buy.make-payment\",\n    \"co_binding_id\": \n    // What is the intent about who plays which roles?\n    \"cast\": [\n        // Recipient of the bind message (id = null) should be payee.\n        {\"role\": \"payee\", \"id\": null},\n        // The payer will be did:peer:abc123.\n        {\"role\": \"payer\", \"id\": \"did:peer:abc123\" }\n    ],\n    // Optional and preferably omitted as it creates tight coupling;\n    // constrains bound coprotocol to just those that have a PIURI\n    // matching this wildcarded expression. \n    \"piuri_pat\": \"*/pay*\",\n    // If multiple matches are found, tells how to sort them to pick\n    // best match. \n    \"prefer\": [\n        // First prefer to bind a protocol that's often successful.\n        { \"attribute\": \"success_ratio\", \"direction\": \"d\" },\n        // Tie break by binding a protocol that's been run recently.\n        { \"attribute\": \"last_run_date\", \"direction\": \"d\" },\n        // Tie break by binding a protocol that's newer.\n        { \"attribute\": \"release_date\", \"direction\": \"d\" }\n        // Tie break by selecting protocols already running (false\n        // sorts before true).\n        { \"attribute\": \"running\", \"direction\": \"d\" }\n    ]\n}\n</code></pre>"},{"location":"features/0482-coprotocol-protocol/#attach","title":"<code>attach</code>","text":"<pre><code>{\n    \"@id\": \"b3dd4d11-6a88-9b3c-4af5-848456b81314\",\n    \"@type\": \"https://didcomm.org/coprotocol/1.0/attach\",\n    \"~thread\": { \"pthid\": \"4d116a88-1314-4af5-9b3c-848456b8b3dd\"},\n    // This is the best match.\n    \"piuri\": \"https://didcomm.org/pay-with-venmo/1.3\",\n    // Optional. Tells how long the caller has to take the next\n    // step binding will be held in an\n    // inactive state before being abandoned.\n    \"~timing.expires_time\": \"2020-06-23T18:42:07.124\"\n}\n</code></pre>"},{"location":"features/0482-coprotocol-protocol/#collateral","title":"Collateral","text":"<p>This section is optional. It could be used to reference files, code, relevant standards, oracles, test suites, or other artifacts that would be useful to an implementer. In general, collateral should be checked in with the RFC.</p>"},{"location":"features/0482-coprotocol-protocol/#drawbacks","title":"Drawbacks","text":"<p>Why should we not do this?</p>"},{"location":"features/0482-coprotocol-protocol/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?</li> <li>What other designs have been considered and what is the rationale for not choosing them?</li> <li>What is the impact of not doing this?</li> </ul>"},{"location":"features/0482-coprotocol-protocol/#prior-art","title":"Prior art","text":"<p>Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:</p> <ul> <li>Does this feature exist in other SSI ecosystems and what experience have their community had?</li> <li>For other teams: What lessons can we learn from other attempts?</li> <li>Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.</li> </ul> <p>This section is intended to encourage you as an author to think about the lessons from other implementers, provide readers of your proposal with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if they are an adaptation from other communities.</p> <p>Note that while precedent set by other communities is some motivation, it does not on its own motivate an enhancement proposal here. Please also take into consideration that Aries sometimes intentionally diverges from common identity ../../features.</p>"},{"location":"features/0482-coprotocol-protocol/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What parts of the design do you expect to resolve through the enhancement proposal process before this gets merged?</li> <li>What parts of the design do you expect to resolve through the implementation of this feature before stabilization?</li> <li>What related issues do you consider out of scope for this  proposal that could be addressed in the future independently of the solution that comes out of this doc?</li> </ul>"},{"location":"features/0482-coprotocol-protocol/#implementations","title":"Implementations","text":"<p>NOTE: This section should remain in the RFC as is on first release. Remove this note and leave the rest of the text as is. Template text in all other sections should be replace.</p> <p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0496-transition-to-oob-and-did-exchange/","title":"Aries RFC 0496: Transition to the Out of Band Protocol","text":"<ul> <li>Authors: Stephen Curran</li> <li>Status: ADOPTED</li> <li>Since: 2021-11-24</li> <li>Status Note: In step 2 - All systems using OOB. Target Completion Date: 2024-07-02</li> <li>Supersedes:</li> <li>Start Date: 2020-06-07</li> <li>Tags: feature, community-update, test-anomaly</li> </ul>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#summary","title":"Summary","text":"<p>The Aries community has agreed to transition from using the <code>invitation</code> messages in RFC 0160 Connections and RFC 0023 DID Exchange to using the plaintext <code>invitation</code> message in RFC 0434 Out of Band and from using RFC 0160 to RFC 0023 for establishing agent-to-agent connections. As well, the community has agreed to transition from using RFC 0056 Service Decorator to execute connection-less instances of the RFC 0037 Present Proof protocol to using the out-of-band invitation message.</p> <p>This RFC follows the guidance in RFC 0345 about community-coordinated updates to (try to) ensure that independently deployed, interoperable agents remain interoperable throughout this transition.</p> <p>The transition from the old to new messages will occur in four steps:</p> <ul> <li>Pre-work: Agent builders agree on the transition plan outlined in this RFC and the target date for completing Step 1.</li> <li>Any RFC updates related to this transition needed before starting the transition are completed.</li> <li>Step 1: Agent builders update all agent code bases and deployments to accept incoming out-of-band messages requesting equivalent-to-current functionality.</li> <li>Equivalent-to-current functionality includes:<ul> <li>RFC 160 Connections invitations</li> <li>Connection-less Present Proof protocol instances using the service decorator</li> </ul> </li> <li>See the section below on Step 1 out-of-band messages</li> <li>During Step 1, all agents should continue to send the current invitation and connection-less protocol messages.</li> <li>Each agent builder SHOULD notify the community they have completed Step 1 by submitting a PR to update their entry in the implementations section of this RFC.</li> <li>Step 2: Agent builders update all agent code bases and deployments to send out out-of-band invitations equivalent to the current invitation and connection-less protocol messages, and Agent builders add full out-of-band protocol support to all agent code bases and deployments.</li> <li>Messages from existing RFCs being replaced by the out-of-band protocol are marked as <code>deprecated</code>.</li> <li>Full out-of-band support is NOT required\u2014just support for the out-of-band equivalents of the old <code>invitation</code> messages.</li> <li>When sending or receiving <code>did:peer</code> DIDs, the DIDs MUST conform to the Peer DID Specification.</li> <li>Each agent builder SHOULD notify the community they have completed Step 2 by submitting a PR to update their entry in the implementations section.</li> <li>Step 3: Support for the current invitation and connection-less protocol messages can be removed from all implementations and deployments, and all out-of-band <code>invitation</code> capabilities that align with the then current Aries Interop Profile (AIP) may be offered.</li> </ul>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#step-1-out-of-band-messages","title":"Step 1 Out-of-Band Messages","text":"<p>The definition of Step 1 has been deliberately defined to limit the impact of the changes on existing code bases. An implementation may be able to do as little as convert an incoming out-of-band protocol message into its \"current format\" equivalent and process the message, thus deferring larger changes to the message handling code. The following examples show the equivalence between out-of-band and current messages and the constraints on the out-of-band invitations used in Step 2.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#connection-invitationinline-diddoc-service-entry","title":"Connection Invitation\u2014Inline DIDDoc Service Entry","text":"<p>The following is the out-of-band <code>invitation</code> message equivalent to an RFC 0160 Connections <code>invitation</code> message that may be used in Step 2.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/1.0/invitation\",\n  \"@id\": \"1234-1234-1234-1234\",\n  \"label\": \"Faber College\",\n  \"goal_code\": \"establish-connection\",\n  \"goal\": \"To establish a connection\",\n  \"handshake_protocols\": [\"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/invitation\"],\n  \"service\": [\n      {\n        \"id\": \"#inline\"\n        \"type\": \"did-communication\",\n        \"recipientKeys\": [\"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"],\n        \"routingKeys\": [],\n        \"serviceEndpoint\": \"https://example.com:5000\"\n      }\n  ]\n}\n</code></pre> <p>The constraints on this form of the out-of-band <code>invitation</code> sent during Step 2 are:</p> <ul> <li><code>goal_code</code> and <code>goal</code> are ignored.</li> <li><code>handshake_protocols</code> MUST have exactly one entry and that entry must be <code>did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/invitation</code>.</li> <li><code>request~attach</code> MUST NOT be present.</li> <li><code>service</code> MUST have exactly one entry and be in the form above or be a single DID (but not both).</li> </ul> <p>This out-of-band message can be transformed to the following RFC 0160 Connection <code>invitation</code> message.</p> <pre><code>{\n  \"@type\": \"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/invitation\",\n  \"@id\": \"1234-1234-1234-1234\",\n  \"label\": \"Faber College\",\n  \"recipientKeys\": [\"6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"],\n  \"serviceEndpoint\": \"https://example.com:5000\",\n  \"routingKeys\": []\n}\n</code></pre> <p>Note the use of <code>did:key</code> in the out-of-band message and the \"naked\" public key in the connection message. Ideally, full support for <code>did:key</code> will be added during Step 1. However, if there is not time for an agent builder to add full support, the transformation can be accomplished using simple text transformations between the <code>did:key</code> format and the (only) public key format used in current Aries agents.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#connection-invitationdid-service-entry","title":"Connection Invitation\u2014DID Service Entry","text":"<p>If the out-of-band message <code>service</code> item is a single DID, the resulting transformed message is comparably different. For example, this out-of-band <code>invitation</code> message:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/invitation\",\n  \"@id\": \"&lt;id used for context as pthid&gt;\",\n  \"label\": \"Faber College\",\n  \"goal_code\": \"issue-vc\",\n  \"goal\": \"To issue a Faber College Graduate credential\",\n  \"handshake_protocols\": [\"https://didcomm.org/connections/1.0\"],\n  \"service\": [\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]\n}\n</code></pre> <p>The <code>did</code> form of the connection invitation is implied, as shown here:</p> <pre><code>{\n  \"@type\": \"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/invitation\",\n  \"@id\": \"1234-1234-1234-1234\",\n  \"label\": \"Faber College\",\n  \"did\": [\"did:sov:LjgpST2rjsoxYegQDRm7EL\"]\n}\n</code></pre>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#connection-less-present-proof-request","title":"Connection-less Present Proof Request","text":"<p>The most common connection-less form being used in production is the <code>request-presentation</code> message from the RFC 0037 Present Proof protocol. The out-of-band invitation for that request looks like this, using the inline form of the service entry.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/out-of-band/%VER/invitation\",\n  \"@id\": \"1234-1234-1234-1234\",\n  \"label\": \"Faber College\",\n  \"goal_code\": \"present-proof\",\n  \"goal\": \"Request proof of some claims from verified credentials\",\n  \"request~attach\": [\n    {\n        \"@id\": \"request-0\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"json\": {\n                \"@type\": \"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/present-proof/1.0/request-presentation\",\n                \"@id\": \"&lt;uuid-request&gt;\",\n                \"comment\": \"some comment\",\n                \"request_presentations~attach\": [\n                    {\n                        \"@id\": \"libindy-request-presentation-0\",\n                        \"mime-type\": \"application/json\",\n                        \"data\":  {\n                            \"base64\": \"&lt;bytes for base64&gt;\"\n                        }\n                    }\n                ]\n            }\n        }\n    }\n  ],\n  \"service\": [\n      {\n        \"id\": \"#inline\",\n        \"type\": \"did-communication\",\n        \"recipientKeys\": [\"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"],\n        \"routingKeys\": [],\n        \"serviceEndpoint\": \"https://example.com:5000\"\n      }\n  ]\n}\n</code></pre> <p>The constraints on this form of the out-of-band <code>invitation</code> sent during Step 2 are:</p> <ul> <li><code>goal_code</code> is ignored and <code>goal</code> is used as the <code>comment</code>.</li> <li><code>handshake_protocols</code> MUST NOT be present.</li> <li><code>request~attach</code> MUST have exactly one entry and that entry must be a <code>request-presentation</code> message.</li> <li><code>service</code> MUST have exactly one entry and be in the form above or be a single DID (but not both).</li> </ul> <p>This out-of-band message can be transformed to the following RFC 0037 Present Proof <code>request-presentation</code> message with an RFC 0056 Service Decorator item.</p> <pre><code>{\n    \"@type\": \"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/present-proof/1.0/request-presentation\",\n    \"@id\": \"1234-1234-1234-1234\",\n    \"comment\": \"Request proof of some claims from verified credentials\",\n    \"~service\": {\n        \"recipientKeys\": [\"6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"],\n        \"routingKeys\": [],\n        \"serviceEndpoint\": \"https://example.com:5000\"\n    },\n    \"request_presentations~attach\": [\n        {\n            \"@id\": \"libindy-request-presentation-0\",\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>If the DID form of the out-of-band <code>invitation</code> message <code>service</code> entry was used, the <code>~service</code> item would be comparably altered.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#url-shortener-handling","title":"URL Shortener Handling","text":"<p>During Step 2 URL Shortening as defined in RFC 0434 Out of Band must be supported.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#between-step-triggers","title":"Between Step Triggers","text":"<p>The community coordination triggers between the steps above will be as follows:</p> <ul> <li>Pre-work to Step 1 - a PR to this RFC is merged that sets the RFC status to ACCEPTED.</li> <li>Step 1 to Step 2 - the community agrees that the majority of the deployed agents have completed Step 1. A PR to this RFC is merged that sets the RFC status to ADOPTED.</li> <li>Agent builders indicate completion of Step 1 by updating the Implementations section of this RFC.</li> <li>A PR to RFC 0160 Connections and RFC 0023 DID Exchange marks the <code>invitation</code> messages as deprecated.</li> <li>The ADOPTED version of this RFC is included in the then-current Aries Interop Profile version.</li> <li>Step 2 to Step 3 - the community agrees that the majority of the deployed agents have completed Step 2. A PR to this RFC is merged that sets the RFC status to RETIRED.</li> <li>Agent builders indicate completion of Step 2 by updating the Implementations section of this RFC.</li> </ul>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#motivation","title":"Motivation","text":"<p>To enable agent builders to independently update their code bases and deployed agents to support the out-of-band protocol while maintaining interoperability.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#tutorial","title":"Tutorial","text":"<p>The general mechanism for this type of transition is documented in RFC 0345 about community-coordinated updates.</p> <p>The specific sequence of events to make this particular transition is outlined in the summary section of this RFC.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#reference","title":"Reference","text":"<p>See the summary section of this RFC for the details of this transition.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#drawbacks","title":"Drawbacks","text":"<p>None identified.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>This approach balances the speed of adoption with the need for independent deployment and ongoing interoperability.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#prior-art","title":"Prior art","text":"<p>The approach outlined in RFC 0345 about community-coordinated updates is a well-known pattern for using deprecation to make breaking changes in an ecosystem. That said, this is the first attempt to use this approach in Aries. Adjustments to the transition plan will be made as needed, and RFC 0345 will be updated based on lessons learned in executing this plan.</p>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Are the constraints on the proposed \"equivalent to existing\" messages sufficiently clear?</li> <li>Does the community want to support the connection-less <code>Issue Credential</code> process to be supported in Step 2?</li> </ul>"},{"location":"features/0496-transition-to-oob-and-did-exchange/#implementations","title":"Implementations","text":"<p>The following table lists the status of various agent code bases and deployments with respect to Step 1 of this transition. Agent builders MUST update this table as they complete steps of the transition.</p> Name / Link Implementation Notes"},{"location":"features/0509-action-menu/","title":"Aries RFC 0509: Action Menu Protocol","text":"<ul> <li>Authors: [Andrew Whitehead],[Stephen Curran],[John Court]</li> <li>Status: DEMONSTRATED</li> <li>Since: 2020-07-02 </li> <li>Status Note: Implemented and demonstrated in the Aries Cloud Agent Python code base </li> <li>Supersedes: </li> <li>Start Date: 2020-06-24</li> <li>Tags: feature, protocol</li> <li>Protocol Name: action-menu</li> <li>Version: 1.0</li> <li>URI: <code>https://didcomm.org/action-menu/%VER</code></li> </ul>"},{"location":"features/0509-action-menu/#summary","title":"Summary","text":"<p>The action-menu protocol allows one Agent to present a set of heirarchical menus and actions to another user-facing Agent in a human friendly way. The protocol allows limited service discovery as well as simple data entry. While less flexible than HTML forms or a chat bot, it should be relatively easy to implement and provides a user interface which can be adapted for various platforms, including mobile agents.</p>"},{"location":"features/0509-action-menu/#motivation","title":"Motivation","text":"<p>Discovery of a peer Agent's capabilities or service offerings is currently reliant on knowledge obtained out-of-band.  There is no in-band DIDComm supported protocol for querying a peer to obtain a human freindly menu of their capabilities or service offerings. Whilst this protocol doesn't offer ledger wide discovery capabilities, it will allow one User Agent connected to another, to present a navigable menu and request offered services. The protocol also provides an interface definition language to define action menu display, selection and request submission.</p>"},{"location":"features/0509-action-menu/#tutorial","title":"Tutorial","text":""},{"location":"features/0509-action-menu/#name-and-version","title":"Name and Version","text":"<p><code>action-menu</code>, version 1.0</p>"},{"location":"features/0509-action-menu/#key-concepts","title":"Key Concepts","text":"<p>The action-menu protocol requires an active DIDComm connection before it can proceed.  One Agent behaves as a <code>requester</code> in the protocol whilst the other Agent represents a <code>responder</code>.  Conceptually the <code>responder</code> presents a list of actions which can be initiated by the <code>requester</code>. Actions are contained within a menu structure. Individual Actions may result in traversal to another menu or initiation of other Aries protocols such as a presentation request, an introduction proposal, a credential offer, an acknowledgement, or a problem report. </p> <p>The protocol can be initiated by either the <code>requester</code> asking for the root menu or the <code>responder</code> sending an unsolicited root menu.  The protocol ends when the <code>requester</code> issues a <code>perform</code> operation or an internal timeout on the <code>responder</code> causes it to discard menu context.  At any time a <code>requester</code> can reset the protocol by requesting the root menu from a <code>responder</code>.</p> <p>Whilst the protocol is defined here as uni-directional (i.e <code>requester</code> to <code>responder</code>), both Agents may support both <code>requester</code> and <code>responder</code> roles simultaneously. Such cases would result in two instances of the action-menu protocol operating in parrallel. </p>"},{"location":"features/0509-action-menu/#roles","title":"Roles","text":"<p>There are two roles in the action-menu protocol: <code>requester</code> and <code>responder</code>.</p> <p>The <code>requester</code> asks the <code>responder</code> for menu definitions, presents them to a user, and initiates subsequent action items from the menu through further requests to the <code>responder</code>.</p> <p>The <code>responder</code> presents an initial menu definition containing actionable elements to a <code>requestor</code> and then responds to subsequent action requests from the menu.  </p>"},{"location":"features/0509-action-menu/#states","title":"States","text":""},{"location":"features/0509-action-menu/#states-for-requester","title":"States for Requester","text":"State\u2003\u2003\u2003\u2003\u2003\u2003\u2003\u2003 Description null No menu has been requested or received awaiting-root-menu menu-request message has been sent and awaiting root menu response preparing-selection menu message has been received and a user selection is pending done perform message has been sent and protocol has finished. Perform actions can include requesting a new menu which will re-enter the state machine with the receive-menu event from the null state."},{"location":"features/0509-action-menu/#states-for-responder","title":"States for Responder","text":"State\u2003\u2003\u2003\u2003\u2003\u2003\u2003\u2003 Description null No menu has been requested or sent preparing-root-menu menu-request message has been received and preparing menu response for root menu awaiting-selection menu message has been sent and are awaiting a perform request done perform message has been received and protocol has finished. Perform actions can include requesting a new menu which will re-enter the state machine with the send-menu event from the null state."},{"location":"features/0509-action-menu/#messages","title":"Messages","text":""},{"location":"features/0509-action-menu/#menu","title":"menu","text":"<p>A <code>requestor</code> is expected to display only one active menu per connection when action menus are employed by the <code>responder</code>. A newly received menu is not expected to interrupt a user, but rather be made available for the user to inspect possible actions related to the <code>responder</code>.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/action-menu/%VER/menu\",\n  \"@id\": \"5678876542344\",\n  \"title\": \"Welcome to IIWBook\",\n  \"description\": \"IIWBook facilitates connections between attendees by verifying attendance and distributing connection invitations.\",\n  \"errormsg\": \"No IIWBook names were found.\",\n  \"options\": [\n    {\n      \"name\": \"obtain-email-cred\",\n      \"title\": \"Obtain a verified email credential\",\n      \"description\": \"Connect with the BC email verification service to obtain a verified email credential\"\n    },\n    {\n      \"name\": \"verify-email-cred\",\n      \"title\": \"Verify your participation\",\n      \"description\": \"Present a verified email credential to identify yourself\"\n    },\n    {\n      \"name\": \"search-introductions\",\n      \"title\": \"Search introductions\",\n      \"description\": \"Your email address must be verified to perform a search\",\n      \"disabled\": true\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0509-action-menu/#description-of-attributes","title":"Description of attributes","text":"<ul> <li><code>title</code> -- plain text string, should be displayed at the top of the menu</li> <li><code>description</code> -- plain text string, should be shown in smaller text below the title bar</li> <li><code>errormsg</code> -- optional plain text string sent to indicate that the last perform request did not work as expected. The text should be presented to the user in the title section</li> <li><code>options</code> -- one or more available actions which the <code>responder</code> supports and may be requested in a perform message.  </li> <li><code>disabled</code> -- optional indication that an option is unavailable due to certain requirements not yet being met</li> </ul>"},{"location":"features/0509-action-menu/#quick-forms","title":"Quick forms","text":"<p>Menu options may define a form property, which would direct the <code>requester</code> user to a client-generated form when the menu option is selected. The menu title should be shown at the top of the form, followed by the form description text if defined, followed by the list of form <code>params</code> in sequence. The form should also include a Cancel button to return to the menu, a Submit button (with an optional custom label defined by <code>submit-label</code>), and optionally a Clear button to reset the parameters to their default values.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/action-menu/%VER/menu\",\n  \"@id\": \"5678876542347\",\n  \"~thread\": {\n    \"thid\": \"5678876542344\"\n  },\n  \"title\": \"Attendance Verified\",\n  \"description\": \"\",\n  \"options\": [\n    {\n      \"name\": \"submit-invitation\",\n      \"title\": \"Submit an invitation\",\n      \"description\": \"Send an invitation for IIWBook to share with another participant\"\n    },\n    {\n      \"name\": \"search-introductions\",\n      \"title\": \"Search introductions\",\n      \"form\": {\n        \"description\": \"Enter a participant name below to perform a search.\",\n        \"params\": [\n          {\n            \"name\": \"query\",\n            \"title\": \"Participant name\",\n            \"default\": \"\",\n            \"description\": \"\",\n            \"required\": true,\n            \"type\": \"text\"\n          }\n        ],\n        \"submit-label\": \"Search\"\n      }\n    }\n  ]\n}\n</code></pre> <p>When the form is submitted, a perform message is generated containing values entered in the form. The <code>form</code> block may have an empty or missing <code>params</code> property in which case it acts as a simple confirmation dialog.</p> <p>Each entry in the <code>params</code> list must define a <code>name</code> and <code>title</code>. The <code>description</code> is optional (should be displayed as help text below the field) and the <code>type</code> defaults to \u2018text\u2019 if not provided (only the \u2018text\u2019 type is supported at this time). Parameters should default to <code>required</code> true, if not specified. Parameters may also define a <code>default</code> value (used when rendering or clearing the form).</p>"},{"location":"features/0509-action-menu/#menu-request","title":"menu-request","text":"<p>In addition to menus being pushed by the <code>responder</code>, the root menu can be re-requested at any time by the <code>requestor</code> sending a menu-request.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/action-menu/%VER/menu-request\",\n  \"@id\": \"5678876542345\"\n}\n</code></pre>"},{"location":"features/0509-action-menu/#perform","title":"perform","text":"<p>When the <code>requestor</code> user actions a menu option, a perform message is generated. It should be attached to the same thread as the menu. The active menu should close when an option is selected.</p> <p>The response to a perform message can be any type of agent message, including another menu message, a presentation request, an introduction proposal, a credential offer, an acknowledgement, or a problem report. Whatever the message type, it should normally reference the same message thread as the perform message.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/action-menu/%VER/perform\",\n  \"@id\": \"5678876542346\",\n  \"~thread\": {\n    \"thid\": \"5678876542344\"\n  },\n  \"name\": \"obtain-email-cred\",\n  \"params\": {}\n}\n</code></pre>"},{"location":"features/0509-action-menu/#description-of-attributes_1","title":"Description of attributes","text":"<ul> <li><code>name</code> -- the menu option being requested. This is taken from the <code>name</code> attribute of the <code>options</code> array elements in the menu </li> <li><code>params</code> -- optional dictionary containing any input parameters requested in a menu option <code>form</code> section.  The dictionary key values are taken from the <code>name</code> attributes of <code>params</code> array elements in the menu option <code>form</code>.</li> </ul>"},{"location":"features/0509-action-menu/#drawbacks","title":"Drawbacks","text":"<p>N/A </p>"},{"location":"features/0509-action-menu/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>N/A </p>"},{"location":"features/0509-action-menu/#prior-art","title":"Prior art","text":"<p>There are several existing RFCs that relate to the general problem of \"Discovery\" </p> <ul> <li>Aries RFC 0031 : Discover Features Protocol 1.0 -- This RFC provides Aries Protocol discovery between two Agents but no direction on user interface display or action handling.</li> <li>Aries RFC 0214 : \"Help Me Discover\" Protocol -- This RFC introduces the concept of a query language protocol between agents to obtain \"referal\" to a third agent. </li> </ul>"},{"location":"features/0509-action-menu/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>There needs to be some consideration around how the protocol may terminate due to <code>responder</code> side timeouts since maintaining menu context for connections consumes resources. Adoption of Aries RFC 0035 : Report Problem Protocol 1.0 is a viable solution</li> </ul>"},{"location":"features/0509-action-menu/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Aries Cloud Agent - Python MISSING test results"},{"location":"features/0510-dif-pres-exch-attach/","title":"Aries RFC 0510: Presentation-Exchange Attachment format for requesting and presenting proofs","text":"<ul> <li>Authors: George Aristy (SecureKey Technologies)</li> <li>Status: ADOPTED</li> <li>Since: 2020-07-21</li> <li>Status Note:  </li> <li>Supersedes: </li> <li>Start Date: 2020-07-21</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0510-dif-pres-exch-attach/#summary","title":"Summary","text":"<p>This RFC registers three attachment formats for use in the present-proof V2 protocol based on the Decentralized Identity Foundation's (DIF) Presentation Exchange specification (P-E). Two of these formats define containers for a presentation-exchange request object and another options object carrying additional parameters, while the third format is just a vessel for the final <code>presentation_submission</code> verifiable presentation transferred from the Prover to the Verifier.</p> <p>Presentation Exchange defines a data format capable of articulating a rich set of proof requirements from Verifiers, and also provides a means of describing the formats in which Provers must submit those proofs.</p> <p>A Verifier's defines their requirements in a <code>presentation_definition</code> containing <code>input_descriptors</code> that describe the credential(s) the proof(s) must be derived from as well as a rich set of operators that place <code>constraints</code> on those proofs (eg. \"must be issued from issuer X\" or \"<code>age</code> over X\", etc.).</p> <p>The Verifiable Presentation format of Presentation Submissions is used as opposed to OIDC tokens or CHAPI objects. For an alternative on how to tunnel OIDC messages over DIDComm, see HTTP-Over-DIDComm. CHAPI is an alternative transport to DIDComm.</p>"},{"location":"features/0510-dif-pres-exch-attach/#motivation","title":"Motivation","text":"<p>The Presentation Exchange specification (P-E) possesses a rich language for expressing a Verifier's criterion.</p> <p>P-E lends itself well to several transport mediums due to its limited scope as a data format, and is easily transported over DIDComm.</p> <p>It is furthermore desirable to make use of specifications developed in an open standards body.</p>"},{"location":"features/0510-dif-pres-exch-attach/#tutorial","title":"Tutorial","text":"<p>Complete examples of messages are provided in the reference section.</p> <p>The Verifier sends a <code>request-presentation</code> to the Prover containing a <code>presentation_definition</code>, along with a <code>domain</code> and <code>challenge</code> the Prover must sign over in the proof.</p> <p>The Prover can optionally respond to the Verifier's <code>request-presentation</code> with a <code>propose-presentation</code> message containing \"Input Descriptors\" that describe the proofs they can provide. The contents of the attachment is just the <code>input_descriptors</code> attribute of the <code>presentation_definition</code> object.</p> <p>The Prover responds with a <code>presentation</code> message containing a <code>presentation_submission</code>.</p>"},{"location":"features/0510-dif-pres-exch-attach/#reference","title":"Reference","text":""},{"location":"features/0510-dif-pres-exch-attach/#propose-presentation-attachment-format","title":"<code>propose-presentation</code> attachment format","text":"<p>Format identifier: <code>dif/presentation-exchange/definitions@v1.0</code></p>"},{"location":"features/0510-dif-pres-exch-attach/#examples-propose-presentation","title":"Examples: propose-presentation","text":"Complete message example <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/propose-presentation\",\n    \"@id\": \"fce30ed1-96f8-44c9-95cf-b274288009dc\",\n    \"comment\": \"some comment\",\n    \"formats\" : [{\n        \"attach_id\" : \"143c458d-1b1c-40c7-ab85-4d16808ddf0a\",\n        \"format\" : \"dif/presentation-exchange/definitions@v1.0\"\n    }],\n    \"proposal~attach\": [{\n        \"@id\": \"143c458d-1b1c-40c7-ab85-4d16808ddf0a\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"json\": {\n                \"input_descriptors\": [{\n                    \"id\": \"citizenship_input\",\n                    \"name\": \"US Passport\",\n                    \"group\": [\"A\"],\n                    \"schema\": [{\n                        \"uri\": \"hub://did:foo:123/Collections/schema.us.gov/passport.json\"\n                    }],\n                    \"constraints\": {\n                        \"fields\": [{\n                            \"path\": [\"$.credentialSubject.birth_date\", \"$.vc.credentialSubject.birth_date\", \"$.birth_date\"],\n                            \"filter\": {\n                                \"type\": \"date\",\n                                \"minimum\": \"1999-5-16\"\n                            }\n                        }]\n                    }\n                }]\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"features/0510-dif-pres-exch-attach/#request-presentation-attachment-format","title":"<code>request-presentation</code> attachment format","text":"<p>Format identifier: <code>dif/presentation-exchange/definitions@v1.0</code></p> <p>Since the format identifier defined above is the same as the one used in the <code>propose-presentation</code> message, it's recommended to consider both the message <code>@type</code> and the <code>format</code> to accuarately understand the contents of the attachment.</p> <p>The contents of the attachment is a JSON object containing the Verifier's presentation definition and an options object with proof options:</p> <pre><code>{\n    \"options\": {\n        \"challenge\": \"...\",\n        \"domain\": \"...\",\n    },\n    \"presentation_definition\": {\n        // presentation definition object\n    }\n}\n</code></pre>"},{"location":"features/0510-dif-pres-exch-attach/#the-options-object","title":"The options object","text":"<p>options is a container of additional parameters required for the Prover to fulfill the Verifier's request.</p> <p>Available options are:</p> Name Status Description <code>challenge</code> RECOMMENDED (for LD proofs) Random seed provided by the Verifier for LD Proofs. <code>domain</code> RECOMMENDED (for LD proofs) The operational domain of the requested LD proof."},{"location":"features/0510-dif-pres-exch-attach/#examples-request-presentation","title":"Examples: request-presentation","text":"Complete message example requesting a verifiable presentation with proof type Ed25519Signature2018 <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/request-presentation\",\n    \"@id\": \"0ac534c8-98ed-4fe3-8a41-3600775e1e92\",\n    \"comment\": \"some comment\",\n    \"formats\" : [{\n        \"attach_id\" : \"ed7d9b1f-9eed-4bde-b81c-3aa7485cf947\",\n        \"format\" : \"dif/presentation-exchange/definitions@v1.0\"\n    }],\n    \"request_presentations~attach\": [{\n        \"@id\": \"ed7d9b1f-9eed-4bde-b81c-3aa7485cf947\",\n        \"mime-type\": \"application/json\",\n        \"data\":  {\n            \"json\": {\n                \"options\": {\n                    \"challenge\": \"23516943-1d79-4ebd-8981-623f036365ef\",\n                    \"domain\": \"us.gov/DriversLicense\"\n                },\n                \"presentation_definition\": {\n                    \"input_descriptors\": [{\n                        \"id\": \"citizenship_input\",\n                        \"name\": \"US Passport\",\n                        \"group\": [\"A\"],\n                        \"schema\": [{\n                            \"uri\": \"hub://did:foo:123/Collections/schema.us.gov/passport.json\"\n                        }],\n                        \"constraints\": {\n                            \"fields\": [{\n                                \"path\": [\"$.credentialSubject.birth_date\", \"$.birth_date\"],\n                                \"filter\": {\n                                    \"type\": \"date\",\n                                    \"minimum\": \"1999-5-16\"\n                                }\n                            }]\n                        }\n                    }],\n                    \"format\": {\n                        \"ldp_vp\": {\n                            \"proof_type\": [\"Ed25519Signature2018\"]\n                        }\n                    }\n                }\n            }\n        }\n    }]\n}\n</code></pre> The same example but requesting the verifiable presentation with proof type BbsBlsSignatureProof2020 instead <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/request-presentation\",\n    \"@id\": \"0ac534c8-98ed-4fe3-8a41-3600775e1e92\",\n    \"comment\": \"some comment\",\n    \"formats\" : [{\n        \"attach_id\" : \"ed7d9b1f-9eed-4bde-b81c-3aa7485cf947\",\n        \"format\" : \"dif/presentation-exchange/definitions@v1.0\"\n    }],\n    \"request_presentations~attach\": [{\n        \"@id\": \"ed7d9b1f-9eed-4bde-b81c-3aa7485cf947\",\n        \"mime-type\": \"application/json\",\n        \"data\":  {\n            \"json\": {\n                \"options\": {\n                    \"challenge\": \"23516943-1d79-4ebd-8981-623f036365ef\",\n                    \"domain\": \"us.gov/DriversLicense\"\n                },\n                \"presentation_definition\": {\n                    \"input_descriptors\": [{\n                        \"id\": \"citizenship_input\",\n                        \"name\": \"US Passport\",\n                        \"group\": [\"A\"],\n                        \"schema\": [{\n                            \"uri\": \"hub://did:foo:123/Collections/schema.us.gov/passport.json\"\n                        }],\n                        \"constraints\": {\n                            \"fields\": [{\n                                \"path\": [\"$.credentialSubject.birth_date\", \"$.vc.credentialSubject.birth_date\", \"$.birth_date\"],\n                                \"filter\": {\n                                    \"type\": \"date\",\n                                    \"minimum\": \"1999-5-16\"\n                                }\n                            }],\n                            \"limit_disclosure\": \"required\"\n                        }\n                    }],\n                    \"format\": {\n                        \"ldp_vc\": {\n                            \"proof_type\": [\"BbsBlsSignatureProof2020\"]\n                        }\n                    }\n                }\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"features/0510-dif-pres-exch-attach/#presentation-attachment-format","title":"<code>presentation</code> attachment format","text":"<p>Format identifier: <code>dif/presentation-exchange/submission@v1.0</code></p> <p>The contents of the attachment is a Presentation Submission in a standard Verifiable Presentation format containing the proofs requested.</p>"},{"location":"features/0510-dif-pres-exch-attach/#examples-presentation","title":"Examples: presentation","text":"Complete message example <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/presentation\",\n    \"@id\": \"f1ca8245-ab2d-4d9c-8d7d-94bf310314ef\",\n    \"comment\": \"some comment\",\n    \"formats\" : [{\n        \"attach_id\" : \"2a3f1c4c-623c-44e6-b159-179048c51260\",\n        \"format\" : \"dif/presentation-exchange/submission@v1.0\"\n    }],\n    \"presentations~attach\": [{\n        \"@id\": \"2a3f1c4c-623c-44e6-b159-179048c51260\",\n        \"mime-type\": \"application/ld+json\",\n        \"data\": {\n            \"json\": {\n                \"@context\": [\n                    \"https://www.w3.org/2018/credentials/v1\",\n                    \"https://identity.foundation/presentation-exchange/submission/v1\"\n                ],\n                \"type\": [\n                    \"VerifiablePresentation\",\n                    \"PresentationSubmission\"\n                ],\n                \"presentation_submission\": {\n                    \"descriptor_map\": [{\n                        \"id\": \"citizenship_input\",\n                        \"path\": \"$.verifiableCredential.[0]\"\n                    }]\n                },\n                \"verifiableCredential\": [{\n                    \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n                    \"id\": \"https://eu.com/claims/DriversLicense\",\n                    \"type\": [\"EUDriversLicense\"],\n                    \"issuer\": \"did:foo:123\",\n                    \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n                    \"credentialSubject\": {\n                        \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n                        \"license\": {\n                            \"number\": \"34DGE352\",\n                            \"dob\": \"07/13/80\"\n                        }\n                    },\n                    \"proof\": {\n                        \"type\": \"RsaSignature2018\",\n                        \"created\": \"2017-06-18T21:19:10Z\",\n                        \"proofPurpose\": \"assertionMethod\",\n                        \"verificationMethod\": \"https://example.edu/issuers/keys/1\",\n                        \"jws\": \"...\"\n                    }\n                }],\n                \"proof\": {\n                    \"type\": \"RsaSignature2018\",\n                    \"created\": \"2018-09-14T21:19:10Z\",\n                    \"proofPurpose\": \"authentication\",\n                    \"verificationMethod\": \"did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1\",\n                    \"challenge\": \"1f44d55f-f161-4938-a659-f8026467f126\",\n                    \"domain\": \"4jt78h47fh47\",\n                    \"jws\": \"...\"\n                }\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"features/0510-dif-pres-exch-attach/#supported-features-of-presentation-exchange","title":"Supported Features of Presentation-Exchange","text":"<p>Level of support for Presentation-Exchange ../../features:</p> Feature Notes <code>presentation_definition.input_descriptors.id</code> <code>presentation_definition.input_descriptors.name</code> <code>presentation_definition.input_descriptors.purpose</code> <code>presentation_definition.input_descriptors.schema.uri</code> URI for the credential's schema. <code>presentation_definition.input_descriptors.constraints.fields.path</code> Array of JSONPath string expressions as defined in section 8. REQUIRED as per the spec. <code>presentation_definition.input_descriptors.constraints.fields.filter</code> JSONSchema descriptor. <code>presentation_definition.input_descriptors.constraints.limit_disclosure</code> <code>preferred</code> or <code>required</code> as defined in the spec and as supported by the Holder and Verifier proof mechanisms.Note that the Holder MUST have credentials with cryptographic proof suites that are capable of selective disclosure in order to respond to a request with <code>limit_disclosure: \"required\"</code>.See RFC0593 for appropriate crypto suites. <code>presentation_definition.input_descriptors.constraints.is_holder</code> <code>preferred</code> or <code>required</code> as defined in the spec.Note that this feature allows the Holder to present credentials with a different subject identifier than the DID used to establish the DIDComm connection with the Verifier. <code>presentation_definition.format</code> For JSONLD-based credentials: <code>ldp_vc</code> and <code>ldp_vp</code>. <code>presentation_definition.format.proof_type</code> For JSONLD-based credentials: <code>Ed25519Signature2018</code>, <code>BbsBlsSignature2020</code>, and <code>JsonWebSignature2020</code>. When specifying <code>ldp_vc</code>, <code>BbsBlsSignatureProof2020</code> may also be used."},{"location":"features/0510-dif-pres-exch-attach/#proof-formats","title":"Proof Formats","text":""},{"location":"features/0510-dif-pres-exch-attach/#constraints","title":"Constraints","text":"<p>Verifiable Presentations MUST be produced and consumed using the JSON-LD syntax.</p> <p>The proof types defined below MUST be registered in the Linked Data Cryptographic Suite Registry.</p> <p>The value of any <code>credentialSubject.id</code> in a credential MUST be a Dentralized Identifier (DID) conforming to the DID Syntax if present. This allows the Holder to authenticate as the credential's subject if required by the Verifier (see the <code>is_holder</code> property above). The Holder authenticates as the credential's subject by attaching an LD Proof on the enclosing Verifiable Presentation.</p>"},{"location":"features/0510-dif-pres-exch-attach/#proof-formats-on-credentials","title":"Proof Formats on Credentials","text":"<p>Aries agents implementing this RFC MUST support the formats outlined in RFC0593 for proofs on Verifiable Credentials.</p>"},{"location":"features/0510-dif-pres-exch-attach/#proof-formats-on-presentations","title":"Proof Formats on Presentations","text":"<p>Aries agents implementing this RFC MUST support the formats outlined below for proofs on Verifiable Presentations.</p>"},{"location":"features/0510-dif-pres-exch-attach/#ed25519signature2018","title":"Ed25519Signature2018","text":"<p>Specification.</p> <p>Request Parameters:</p> <ul> <li><code>presentation_definition.format</code>: <code>ldp_vp</code></li> <li><code>presentation_definition.format.proof_type</code>: <code>Ed25519Signature2018</code></li> <li><code>options.challenge</code>: (Optional) a random string value generated by the Verifier</li> <li><code>options.domain</code>: (Optional) a string value specified set by the Verifier</li> </ul> <p>Result:</p> <p>A Verifiable Presentation of type Presentation Submission containing the credentials requested under the <code>verifiableCredential</code> property and a <code>proof</code> property of type <code>Ed25519Signature2018</code>.</p> Example <pre><code>{\n    \"@context\": [\n        \"https://www.w3.org/2018/credentials/v1\",\n        \"https://identity.foundation/presentation-exchange/submission/v1\"\n    ],\n    \"type\": [\n        \"VerifiablePresentation\",\n        \"PresentationSubmission\"\n    ],\n    \"presentation_submission\": {\n        \"descriptor_map\": [{\n           \"id\": \"citizenship_input\",\n           \"path\": \"$.verifiableCredential.[0]\"\n        }]\n    },\n    \"verifiableCredential\": [{\n        \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n        \"id\": \"https://eu.com/claims/DriversLicense\",\n        \"type\": [\n            \"EUDriversLicense\"\n        ],\n        \"issuer\": \"did:foo:123\",\n        \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n        \"credentialSubject\": {\n            \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n            \"license\": {\n            \"number\": \"34DGE352\",\n            \"dob\": \"07/13/80\"\n          }\n        },\n        \"proof\": {\n            \"type\": \"RsaSignature2018\",\n            \"created\": \"2017-06-18T21:19:10Z\",\n            \"proofPurpose\": \"assertionMethod\",\n            \"verificationMethod\": \"https://example.edu/issuers/keys/1\",\n            \"jws\": \"...\"\n        }\n    }],\n    \"proof\": {\n      \"type\": \"Ed25519Signature2018\",\n      \"proofPurpose\": \"authentication\",\n      \"created\": \"2017-09-23T20:21:34Z\",\n      \"verificationMethod\": \"did:example:123456#key1\",\n      \"challenge\": \"2bbgh3dgjg2302d-d2b3gi423d42\",\n      \"domain\": \"example.org\",\n      \"jws\": \"eyJ0eXAiOiJK...gFWFOEjXk\"\n  }\n}\n</code></pre>"},{"location":"features/0510-dif-pres-exch-attach/#bbsblssignature2020","title":"BbsBlsSignature2020","text":"<p>Specification.</p> <p>Associated RFC: RFC0646.</p> <p>Request Parameters: * <code>presentation_definition.format</code>: <code>ldp_vp</code> * <code>presentation_definition.format.proof_type</code>: <code>BbsBlsSignature2020</code> * <code>options.challenge</code>: (Optional) a random string value generated by the Verifier * <code>options.domain</code>: (Optional) a string value specified set by the Verifier</p> <p>Result:</p> <p>A Verifiable Presentation of type Presentation Submission containing the credentials requested under the <code>verifiableCredential</code> property and a <code>proof</code> property of type <code>BbsBlsSignature2020</code>.</p> Example <pre><code>{\n    \"@context\": [\n        \"https://www.w3.org/2018/credentials/v1\",\n        \"https://w3id.org/security/v2\",\n        \"https://w3id.org/security/bbs/v1\",\n        \"https://identity.foundation/presentation-exchange/submission/v1\"\n    ],\n    \"type\": [\n        \"VerifiablePresentation\",\n        \"PresentationSubmission\"\n    ],\n    \"presentation_submission\": {\n        \"descriptor_map\": [{\n            \"id\": \"citizenship_input\",\n            \"path\": \"$.verifiableCredential.[0]\"\n        }]\n    },\n    \"verifiableCredential\": [{\n        \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n        \"id\": \"https://eu.com/claims/DriversLicense\",\n        \"type\": [\"EUDriversLicense\"],\n        \"issuer\": \"did:foo:123\",\n        \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n        \"credentialSubject\": {\n            \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n            \"license\": {\n                \"number\": \"34DGE352\",\n                \"dob\": \"07/13/80\"\n            }\n       },\n       \"proof\": {\n           \"type\": \"BbsBlsSignatureProof2020\",\n           \"created\": \"2020-04-25\",\n           \"verificationMethod\": \"did:example:489398593#test\",\n           \"proofPurpose\": \"assertionMethod\",\n           \"signature\": \"F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg==\"\n       }\n    }],\n    \"proof\": {\n        \"type\": \"BbsBlsSignature2020\",\n        \"created\": \"2020-04-25\",\n        \"verificationMethod\": \"did:example:489398593#test\",\n        \"proofPurpose\": \"authentication\",\n        \"proofValue\": \"F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg==\",\n        \"requiredRevealStatements\": [ 4, 5 ]\n    }\n}\n</code></pre> <p>Note: The above example is for illustrative purposes. In particular, note that whether a Verifier requests a <code>proof_type</code> of <code>BbsBlsSignature2020</code> has no bearing on whether the Holder is required to present credentials with proofs of type <code>BbsBlsSignatureProof2020</code>. The choice of proof types on the credentials is constrained by a) the available types registered in RFC0593 and b) additional constraints placed on them due to other aspects of the proof requested by the Verifier, such as requiring limited disclosure with the <code>limit_disclosure</code> property. In such a case, a proof type of <code>Ed25519Signature2018</code> in the credentials is not appropriate whereas <code>BbsBlsSignatureProof2020</code> is capable of selective disclosure.</p>"},{"location":"features/0510-dif-pres-exch-attach/#jsonwebsignature2020","title":"JsonWebSignature2020","text":"<p>Specification.</p> <p>Request Parameters:</p> <ul> <li><code>presentation_definition.format</code>: <code>ldp_vp</code></li> <li><code>presentation_definition.format.proof_type</code>: <code>JsonWebSignature2020</code></li> <li><code>options.challenge</code>: (Optional) a random string value generated by the Verifier</li> <li><code>options.domain</code>: (Optional) a string value specified set by the Verifier</li> </ul> <p>Result:</p> <p>A Verifiable Presentation of type Presentation Submission containing the credentials requested under the <code>verifiableCredential</code> property and a <code>proof</code> property of type <code>JsonWebSignature2020</code>.</p> Example <pre><code>{\n    \"@context\": [\n        \"https://www.w3.org/2018/credentials/v1\",\n        \"https://identity.foundation/presentation-exchange/submission/v1\"\n    ],\n    \"type\": [\n        \"VerifiablePresentation\",\n        \"PresentationSubmission\"\n    ],\n    \"presentation_submission\": {\n        \"descriptor_map\": [{\n           \"id\": \"citizenship_input\",\n           \"path\": \"$.verifiableCredential.[0]\"\n        }]\n    },\n    \"verifiableCredential\": [{\n        \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n        \"id\": \"https://eu.com/claims/DriversLicense\",\n        \"type\": [\n            \"EUDriversLicense\"\n        ],\n        \"issuer\": \"did:foo:123\",\n        \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n        \"credentialSubject\": {\n            \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n            \"license\": {\n            \"number\": \"34DGE352\",\n            \"dob\": \"07/13/80\"\n          }\n        },\n        \"proof\": {\n            \"type\": \"RsaSignature2018\",\n            \"created\": \"2017-06-18T21:19:10Z\",\n            \"proofPurpose\": \"assertionMethod\",\n            \"verificationMethod\": \"https://example.edu/issuers/keys/1\",\n            \"jws\": \"...\"\n        }\n    }],\n    \"proof\": {\n      \"type\": \"JsonWebSignature2020\",\n      \"proofPurpose\": \"authentication\",\n      \"created\": \"2017-09-23T20:21:34Z\",\n      \"verificationMethod\": \"did:example:123456#key1\",\n      \"challenge\": \"2bbgh3dgjg2302d-d2b3gi423d42\",\n      \"domain\": \"example.org\",\n      \"jws\": \"eyJ0eXAiOiJK...gFWFOEjXk\"\n  }\n}\n</code></pre> <p>Available JOSE key types are:</p> kty crv signature EC P-256 ES256 EC P-384 ES384"},{"location":"features/0510-dif-pres-exch-attach/#drawbacks","title":"Drawbacks","text":"<p>N/A</p>"},{"location":"features/0510-dif-pres-exch-attach/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>The <code>hlindy-zkp-v1.0</code> format is an alternative restricted to the Hyperledger Indy network.</li> </ul>"},{"location":"features/0510-dif-pres-exch-attach/#prior-art","title":"Prior art","text":"<ul> <li>OAuth 2.0 Rich Authorization Requests:   Provides a coarse object structure that implementers must extend to support their needs. Presentation Exchange   provides a rich set of operators out of the box.</li> </ul>"},{"location":"features/0510-dif-pres-exch-attach/#unresolved-questions","title":"Unresolved questions","text":"<p>TODO it is assumed the Verifier will initiate the protocol if they can transmit their presentation definition via an out-of-band channel  (eg. it is published on their website) with a <code>request-presentation</code> message, possibly delivered via an Out-of-Band invitation  (see RFC0434). For now, the Prover sends <code>propose-presentation</code> as a response to <code>request-presentation</code>.</p>"},{"location":"features/0510-dif-pres-exch-attach/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0511-dif-cred-manifest-attach/","title":"Aries RFC 0511: Credential-Manifest Attachment format for requesting and presenting credentials","text":"<ul> <li>Authors: George Aristy (SecureKey Technologies)</li> <li>Status: PROPOSED</li> <li>Since: 2020-07-22</li> <li>Status Note:</li> <li>Supersedes:</li> <li>Start Date: 2020-07-22</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0511-dif-cred-manifest-attach/#summary","title":"Summary","text":"<p>This RFC registers an attachment format for use in the issue-credential V2 based on the Decentralized Identity Foundation's (DIF) Credential Manifest specification. Credental Manifest describes a data format that specifies the inputs an Issuer requires for issuance of a credential. It relies on the closely-related Presentation Exchange specification to describe the required inputs and the format in which the Holder submits those inputs (a verifiable presentation).</p>"},{"location":"features/0511-dif-cred-manifest-attach/#motivation","title":"Motivation","text":"<p>The Credential Manifest specification lends itself well to several transport mediums due to its limited scope as a data format, and is easily transported over DIDComm.</p> <p>It is furthermore desirable to make use of specifications developed in an open standards body.</p>"},{"location":"features/0511-dif-cred-manifest-attach/#tutorial","title":"Tutorial","text":"<p>Complete examples of messages are provided in the reference section.</p> <p>Credential Manifests MAY be acquired by the Holder via out of band means, such as from a well-known location on the Issuer's website. This allows the Holder to initiate the <code>issue-credential</code> protocol with a <code>request-message</code> providing they also possess the requisite <code>challenge</code> and <code>domain</code> values. If they do not possess these values then the Issuer MAY respond with an <code>offer-credential</code> message.</p> <p>Otherwise the Holder MAY initiate the protocol with <code>propose-credential</code> in order to discover the Issuer's requirements.</p>"},{"location":"features/0511-dif-cred-manifest-attach/#reference","title":"Reference","text":""},{"location":"features/0511-dif-cred-manifest-attach/#propose-credential-attachment-format","title":"<code>propose-credential</code> attachment format","text":"<p>Format identifier: <code>dif/credential-manifest@v1.0</code></p> <p>The contents of the attachment is the minimal form of the Issuer's credential manifest describing the credential the Holder desires. It SHOULD contain the <code>issuer</code> and <code>credential</code> properties and no more.</p> <p>Complete message example:</p> <pre><code>{\n    \"@id\": \"8639505e-4ec5-41b9-bb31-ac6a7b800fe7\",\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/propose-credential\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\" : [{\n        \"attach_id\": \"b45ca1bc-5b3c-4672-a300-84ddf6fbbaea\",\n        \"format\": \"dif/credential-manifest@v1.0\"\n    }],\n    \"filters~attach\": [{\n        \"@id\": \"b45ca1bc-5b3c-4672-a300-84ddf6fbbaea\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"json\": {\n                \"issuer\": \"did:example:123\",\n                \"credential\": {\n                    \"name\": \"Washington State Class A Commercial Driver License\",\n                    \"schema\": \"ipfs:QmPXME1oRtoT627YKaDPDQ3PwA8tdP9rWuAAweLzqSwAWT\"\n                }\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"features/0511-dif-cred-manifest-attach/#offer-credential-attachment-format","title":"<code>offer-credential</code> attachment format","text":"<p>Format identifier: <code>dif/credential-manifest@v1.0</code></p> <p>The contents of the attachment is a JSON object containing the Issuer's credential manifest, a challenge and domain. All three attributes are REQUIRED.</p> <p>Example:</p> <pre><code>{\n    \"@id\": \"dfedaad3-bd7a-4c33-8337-fa94a547c0e2\",\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/offer-credential\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\" : [{\n        \"attach_id\" : \"76cd0d94-8eb6-4ef3-a094-af45d81e9528\",\n        \"format\" : \"dif/credential-manifest@v1.0\"\n    }],\n    \"offers~attach\": [{\n        \"@id\": \"76cd0d94-8eb6-4ef3-a094-af45d81e9528\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"json\": {\n                \"challenge\": \"1f44d55f-f161-4938-a659-f8026467f126\",\n                \"domain\": \"us.gov/DriverLicense\",\n                \"credential_manifest\": {\n                    // credential manifest object\n                }\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"features/0511-dif-cred-manifest-attach/#request-credential-attachment-format","title":"<code>request-credential</code> attachment format","text":"<p>Format identifier: <code>dif/credential-manifest@v1.0</code></p> <p>The contents of the attachment is a JSON object that describes the credential requested and provides the inputs the Issuer requires from the Holder before proceeding with issuance:</p> <pre><code>{\n    \"credential-manifest\": {\n        \"issuer\": \"did:example:123\",\n        \"credential\": {\n            \"name\": \"Washington State Class A Commercial Driver License\",\n            \"schema\": \"ipfs:QmPXME1oRtoT627YKaDPDQ3PwA8tdP9rWuAAweLzqSwAWT\"\n        }\n    },\n    \"presentation-submission\": {\n        // presentation submission object\n    }\n}\n</code></pre> <ul> <li><code>credential-manifest</code>: OPTIONAL. Required if the Holder starts the protocol with <code>request-credential</code>.</li> <li><code>presentation-submission</code>: OPTIONAL. Required as a response to the <code>presentation_definition</code> attribute in the Issuer's credential manifest, if present.</li> </ul> <p>If the Issuer's credential manifest does not include the <code>presentation_definition</code> attribute, and the Holder has initiated the protocol with <code>propose-credential</code>, then this attachment MAY be omitted entirely as the message thread provides sufficient context for this request.</p> <p>Implementors are STRONGLY discouraged from allowing BOTH <code>credential-manifest</code> and <code>presentation-submission</code>. The latter requires the Holder's knowledge of the necessary <code>challenge</code> and <code>domain</code>, both of which SHOULD provide sufficient context to the Issuer as to which credential is being requested.</p> <p>The following example shows a <code>request-credential</code> with a presentation submission. Notice the presentation's <code>proof</code> includes the <code>challenge</code> and <code>domain</code> acquired either through out-of-band means or via an <code>offer-credential</code> message.:</p> <pre><code>{\n    \"@id\": \"cf3a9301-6d4a-430f-ae02-b4a79ddc9706\",\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/request-credential\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\": [{\n        \"attach_id\": \"7cd11894-838a-45c0-a9ec-13e2d9d125a1\",\n        \"format\": \"dif/credential-manifest@v1.0\"\n    }],\n    \"requests~attach\": [{\n        \"@id\": \"7cd11894-838a-45c0-a9ec-13e2d9d125a1\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"json\": {\n                \"presentation-submission\": {\n                    \"@context\": [\n                        \"https://www.w3.org/2018/credentials/v1\",\n                        \"https://identity.foundation/presentation-exchange/submission/v1\"\n                    ],\n                    \"type\": [\n                        \"VerifiablePresentation\",\n                        \"PresentationSubmission\"\n                    ],\n                    \"presentation_submission\": {\n                        \"descriptor_map\": [{\n                            \"id\": \"citizenship_input\",\n                            \"path\": \"$.verifiableCredential.[0]\"\n                        }]\n                    },\n                    \"verifiableCredential\": [{\n                        \"@context\": \"https://www.w3.org/2018/credentials/v1\",\n                        \"id\": \"https://us.gov/claims/Passport/723c62ab-f2f0-4976-9ec1-39992e20c9b1\",\n                        \"type\": [\"USPassport\"],\n                        \"issuer\": \"did:foo:123\",\n                        \"issuanceDate\": \"2010-01-01T19:73:24Z\",\n                        \"credentialSubject\": {\n                            \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n                            \"birth_date\": \"2000-08-14\"\n                        },\n                        \"proof\": {\n                            \"type\": \"EcdsaSecp256k1VerificationKey2019\",\n                            \"created\": \"2017-06-18T21:19:10Z\",\n                            \"proofPurpose\": \"assertionMethod\",\n                            \"verificationMethod\": \"https://example.edu/issuers/keys/1\",\n                            \"jws\": \"...\"\n                        }\n                    }],\n                    \"proof\": {\n                        \"type\": \"RsaSignature2018\",\n                        \"created\": \"2018-09-14T21:19:10Z\",\n                        \"proofPurpose\": \"authentication\",\n                        \"verificationMethod\": \"did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1\",\n                        \"challenge\": \"1f44d55f-f161-4938-a659-f8026467f126\",\n                        \"domain\": \"us.gov/DriverLicense\",\n                        \"jws\": \"...\"\n                    }\n                }\n            }\n        }\n    }]\n}\n</code></pre>"},{"location":"features/0511-dif-cred-manifest-attach/#issue-credential-attachment-format","title":"<code>issue-credential</code> attachment format","text":"<p>This specification does not register any format identifier for the <code>issue-credential</code> message. The Issuer SHOULD set the <code>format</code> to the value that corresponds to the format the credentials are issued in.</p>"},{"location":"features/0511-dif-cred-manifest-attach/#drawbacks","title":"Drawbacks","text":"<p>N/A</p>"},{"location":"features/0511-dif-cred-manifest-attach/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>The <code>hlindy-zkp-v1.0</code> format is an alternative restricted to the Hyperledger Indy network.</li> </ul>"},{"location":"features/0511-dif-cred-manifest-attach/#prior-art","title":"Prior art","text":"<p>N/A</p>"},{"location":"features/0511-dif-cred-manifest-attach/#unresolved-questions","title":"Unresolved questions","text":"<p>N/A</p>"},{"location":"features/0511-dif-cred-manifest-attach/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0557-discover-features-v2/","title":"Aries RFC 0557: Discover Features Protocol v2.x","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Update to version 2.0 proposed in conjunction with DIDComm v2 efforts at DIF, where it became clear that we need to discover more than just protocol support of other agents. Included in AIP v2.0.</li> <li>Supersedes: version 1.0 of this protocol in RFC 0031, which was widely referenced in the Aries eocsystem in 2018 and 2019.</li> <li>Start Date: 2018-12-17</li> <li>URI: https://didcomm.org/discover-features/%VER</li> <li>Tags: feature, protocol, test-anomaly</li> </ul>"},{"location":"features/0557-discover-features-v2/#summary","title":"Summary","text":"<p>Describes how one agent can query another to discover which ../../features it supports, and to what extent.</p>"},{"location":"features/0557-discover-features-v2/#motivation","title":"Motivation","text":"<p>Though some agents will support just one feature and will be statically configured to interact with just one other party, many exciting uses of agents are more dynamic and unpredictable. When Alice and Bob meet, they won't know in advance which ../../features are supported by one another's agents. They need a way to find out.</p>"},{"location":"features/0557-discover-features-v2/#tutorial","title":"Tutorial","text":"<p>This is version 2.0 of the Discover Features protocol, and its fully qualified PIURI for the Discover Features protocol is:</p> <pre><code>https://didcomm.org/discover-features/2.0\n</code></pre> <p>This version is conceptually similar to version 1.0 of this protocol. It differs in its ability to ask about multiple feature types, and to ask multiple questions and receive multiple answers in a single round trip.</p>"},{"location":"features/0557-discover-features-v2/#roles","title":"Roles","text":"<p>There are two roles in the <code>discover-features</code> protocol: <code>requester</code> and <code>responder</code>. Normally, the requester asks the responder about the ../../features it supports, and the responder answers. Each role uses a single message type.</p> <p>It is also possible to proactively disclose ../../features; in this case a requester receives a response without asking for it. This may eliminate some chattiness in certain use cases (e.g., where two-way connectivity is limited).</p>"},{"location":"features/0557-discover-features-v2/#states","title":"States","text":"<p>The state progression is very simple. In the normal case, it is simple request-response; in a proactive disclosure, it's a simple one-way notification.</p>"},{"location":"features/0557-discover-features-v2/#requester","title":"Requester","text":""},{"location":"features/0557-discover-features-v2/#responder","title":"Responder","text":""},{"location":"features/0557-discover-features-v2/#messages","title":"Messages","text":""},{"location":"features/0557-discover-features-v2/#queries-message-type","title":"<code>queries</code> Message Type","text":"<p>A <code>discover-features/queries</code> message looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/2.0/queries\",\n  \"@id\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\",\n  \"queries\": [\n    { \"feature-type\": \"protocol\", \"match\": \"https://didcomm.org/tictactoe/1.*\" },\n    { \"feature-type\": \"goal-code\", \"match\": \"aries.*\" }\n  ]\n}\n</code></pre> <p>Queries messages contain one or more query objects in the <code>queries</code> array. Each query essentially says, \"Please tell me what ../../features of type X you support, where the feature identifiers match this (potentially wildcarded) string.\" This particular example asks an agent if it supports any 1.x versions of the tictactoe protocol, and if it supports any goal codes that begin with \"aries.\".</p> <p>Implementations of this protocol must recognize the following values for <code>feature-type</code>: <code>protocol</code>, <code>goal-code</code>, <code>gov-fw</code>, <code>didcomm-version</code>, and <code>decorator</code>/<code>header</code>. (The concept known as <code>decorator</code> in DIDComm v1 approximately maps to the concept known as <code>header</code> in DIDComm v2. The two values should be considered synonyms and must both be recognized.) Additional values of <code>feature-type</code> may be standardized by raising a PR against this RFC that defines the new type and increments the minor protocol version number; non-standardized values are also valid, but there is no guarantee that their semantics will be recognized.</p> <p>Identifiers for feature types vary. For protocols, identifiers are PIURIs. For goal codes, identifiers are goal code values. For governance frameworks, identifiers are URIs where the framework is published (typically the <code>data_uri</code> field if machine-readable. For DIDComm versions, identifiers are the URIs where DIDComm versions are developed (<code>https://github.com/hyperledger/aries-rfcs</code> for V1 and <code>https://github.com/decentralized-identity/didcomm-messaging</code> for V2; see \"Detecting DIDComm Versions\" in RFC 0044 for more details).</p> <p>The <code>match</code> field of a query descriptor may use the * wildcard. By itself, a <code>match</code> with just the wildcard says, \"I'm interested in anything you want to share with me.\" But usually, this wildcard will be to match a prefix that's a little more specific, as in the example that matches any 1.x version.</p> <p>Any agent may send another agent this message type at any time. Implementers of agents that intend to support dynamic relationships and rich ../../features are strongly encouraged to implement support for this message, as it is likely to be among the first messages exchanged with a stranger.</p>"},{"location":"features/0557-discover-features-v2/#disclosures-message-type","title":"<code>disclosures</code> Message Type","text":"<p>A <code>discover-features/disclosures</code> message looks like this:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/2.0/disclosures\",\n  \"~thread\": { \"thid\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\" },\n  \"disclosures\": [\n    {\n      \"feature-type\": \"protocol\",\n      \"id\": \"https://didcomm.org/tictactoe/1.0\",\n      \"roles\": [\"player\"]\n    },\n    {\n      \"feature-type\": \"goal-code\",\n      \"id\": \"aries.sell.goods.consumer\"\n    }\n  ]\n}\n</code></pre> <p>The <code>disclosures</code> field is a JSON array of zero or more disclosure objects that describe a feature. Each descriptor has a <code>feature-type</code> field that contains data corresponding to <code>feature-type</code> in a query object, and an <code>id</code> field that unambiguously identifies a single item of that feature type. When the item is a protocol, the disclosure object may also contain a <code>roles</code> array that enumerates the roles the responding agent can play in the associated protocol. Future feature types may add additional optional fields, though no other fields are being standardized with this version of the RFC.</p> <p>Disclosures messages say, \"Here are some ../../features I support (that matched your queries).\"</p>"},{"location":"features/0557-discover-features-v2/#sparse-disclosures","title":"Sparse Disclosures","text":"<p>Disclosures do not have to contain exhaustive detail. For example, the following response omits the optional <code>roles</code> field but may be just as useful as one that includes it:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/discover-features/2.0/disclosures\",\n  \"~thread\": { \"thid\": \"yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU\" },\n  \"disclosures\": [\n    {\"feature-type\": \"protocol\", \"id\": \"https://didcomm.org/tictactoe/1.0\"}\n  ]\n}\n</code></pre> <p>Less detail probably suffices because agents do not need to know everything about one another's implementations in order to start an interaction--usually the flow will organically reveal what's needed. For example, the <code>outcome</code> message in the <code>tictactoe</code> protocol isn't needed until the end, and is optional anyway. Alice can start a tictactoe game with Bob and will eventually see whether he has the right idea about <code>outcome</code> messages.</p> <p>The missing <code>roles</code> in this disclosure does not say, \"I support no roles in this protocol.\" It says, \"I support the protocol but I'm providing no detail about specific roles.\" Similar logic applies to any other omitted fields.</p> <p>An empty <code>disclosures</code> array does not say, \"I support no ../../features that match your query.\" It says, \"I'm not disclosing to you that I support any ../../features (that match your query).\" An agent might not tell another that it supports a feature for various reasons, including: the trust that it imputes to the other party based on cumulative interactions so far, whether it's in the middle of upgrading a plugin, whether it's currently under high load, and so forth. And responses to a <code>discover-features</code> query are not guaranteed to be true forever; agents can be upgraded or downgraded, although they probably won't churn in their feature profiles from moment to moment.</p>"},{"location":"features/0557-discover-features-v2/#privacy-considerations","title":"Privacy Considerations","text":"<p>Because the wildcards in a <code>queries</code> message can be very inclusive, the <code>discover-features</code> protocol could be used to mine information suitable for agent fingerprinting, in much the same way that browser fingerprinting works. This is antithetical to the ethos of our ecosystem, and represents bad behavior. Agents should use <code>discover-features</code> to answer legitimate questions, and not to build detailed profiles of one another. However, fingerprinting may be attempted anyway.</p> <p>For agents that want to maintain privacy, several best practices are recommended:</p>"},{"location":"features/0557-discover-features-v2/#follow-selective-disclosure","title":"Follow selective disclosure.","text":"<p>Only reveal supported ../../features based on trust in the relationship. Even if you support a protocol, you may not wish to use it in every relationship. Don't tell others about ../../features you do not plan to use with them.</p> <p>Patterns are easier to see in larger data samples. However, a pattern of ultra-minimal data is also a problem, so use good judgment about how forthcoming to be.</p>"},{"location":"features/0557-discover-features-v2/#vary-the-format-of-responses","title":"Vary the format of responses.","text":"<p>Sometimes, you might prettify your agent plaintext message one way, sometimes another.</p>"},{"location":"features/0557-discover-features-v2/#vary-the-order-of-items-in-the-disclosures-array","title":"Vary the order of items in the <code>disclosures</code> array.","text":"<p>If more than one key matches a query, do not always return them in alphabetical order or version order. If you do return them in order, do not always return them in ascending order.</p>"},{"location":"features/0557-discover-features-v2/#consider-adding-some-spurious-details","title":"Consider adding some spurious details.","text":"<p>If a query could match multiple ../../features, then occasionally you might add some made-up ../../features as matches. If a wildcard allows multiple versions of a protocol, then sometimes you might use some made-up versions. And sometimes not. (Doing this too aggressively might reveal your agent implementation, so use sparingly.)</p>"},{"location":"features/0557-discover-features-v2/#vary-how-you-query-too","title":"Vary how you query, too.","text":"<p>How you ask questions may also be fingerprintable.</p>"},{"location":"features/0557-discover-features-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0587-encryption-envelope-v2/","title":"Aries RFC 0587: Encryption Envelope v2","text":"<ul> <li>Authors: Baha A. Shaaban (SecureKey Technologies Inc.), Troy Ronda (SecureKey Technologies Inc.)</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Included as part of the \"prepare for DIDComm v2\" subtarget of AIP 2.0.</li> <li>Supersedes:</li> <li>Start Date: 2021-02-10</li> <li>Tags: feature</li> </ul>"},{"location":"features/0587-encryption-envelope-v2/#summary","title":"Summary","text":"<p>This RFC proposes that we support the definition of envelopes from DIDComm Messaging.</p>"},{"location":"features/0587-encryption-envelope-v2/#motivation","title":"Motivation","text":"<p>This RFC defines ciphersuites for envelopes such that we can achieve better compatability with DIDComm Messaging being specified at DIF. The ciphersuites defined in this RFC are a subset of the definitions in Aries RFC 0334-jwe-envelope.</p>"},{"location":"features/0587-encryption-envelope-v2/#encryption-algorithms","title":"Encryption Algorithms","text":"<p>DIDComm defines both the concept of authenticated sender encryption (aka <code>Authcrypt</code>) and anonymous sender encryption (aka <code>Anoncrypt</code>). In general, Aries RFCs and protocols use <code>Authcrypt</code> to exchange messages. In some limited scenarios (e.g., mediator and relays), an Aries RFC or protocol may define usage of <code>Anoncrypt</code>.</p> <p>ECDH-1PU draft 04 defines the JWE structure for <code>Authcrypt</code>. <code>ECDH-ES</code> from RFC 7518 defines the JWE structure for <code>Anoncrypt</code>. The following sections summarize the supported algorithms.</p>"},{"location":"features/0587-encryption-envelope-v2/#curves","title":"Curves","text":"<p>DIDComm Messaging (and this RFC) requires support for <code>X25519</code>, <code>P-256</code>, and <code>P-384</code>.</p> <ul> <li>P-256 (reference in RFC4492)</li> <li>P-384 (reference in RFC4492)</li> <li>P-521 (optional, reference in RFC4492)</li> <li>X25519 (reference in RFC7748)</li> </ul>"},{"location":"features/0587-encryption-envelope-v2/#content-encryption-algorithms","title":"Content Encryption Algorithms","text":"<p>DIDComm Messaging (and this RFC) requires support for both <code>XC20P</code> and <code>A256GCM</code> for Anoncrypt only and <code>A256CBC-HS512</code> for both Authcrypt and Anoncrypt.</p> <ul> <li>XC20P (XChaCha20Poly1305 - reference in xchacha draft 03)</li> <li>A256GCM (AES-GCM with a 256 bits key - reference in RFC7518 section 5.1 and more specifically RFC7518 section 5.3)</li> <li>A256CBC-HS512 (AES256-CBC+HMAC-SHA512 with a 512 bits key - reference in ECDH-1PU section 2.1 and RFC 7518 section 5.2.5) </li> </ul>"},{"location":"features/0587-encryption-envelope-v2/#key-wrapping-algorithms","title":"Key Wrapping Algorithms","text":"<p>DIDComm Messaging (and this RFC) requires support for <code>ECDH-1PU+A256KW</code> and <code>ECDH-ES+A256KW</code>.</p> <ul> <li>ECDH-1PU+A256KW (defined in ECDH-1PU draft 04)</li> <li>ECDH-ES+A256KW (defined in RFC 7518)</li> </ul>"},{"location":"features/0587-encryption-envelope-v2/#key-ids-kid-and-skid-headers-references-in-the-did-document","title":"Key IDs <code>kid</code> and <code>skid</code> headers references in the DID document","text":"<p>Keys used by DIDComm envelopes MUST be sourced from the DIDs exchanged between two agents. Specifically, both sender and recipients keys MUST be retrieved from the DID document's <code>KeyAgreement</code> verification section as per the DID Document Keys definition.</p> <p>When Alice is preparing an envelope intended for Bob, the packing process should use a key from both hers and Bob's DID document's <code>KeyAgreement</code> section.</p> <p>Assuming Alice has a DID Doc with the following <code>KeyAgreement</code> definition (source: DID V1 Example 17): <pre><code>{\n  \"@context\": \"https://www.w3.org/ns/did/v1\",\n  \"id\": \"did:example:123456789abcdefghi\",\n  ...\n  \"keyAgreement\": [\n    // this method can be used to perform key agreement as did:...fghi\n    \"did:example:123456789abcdefghi#keys-1\",\n    // this method is *only* approved for key agreement usage, it will not\n    // be used for any other verification relationship, so its full description is\n    // embedded here rather than using only a reference\n    {\n      \"id\": \"did:example:123#zC9ByQ8aJs8vrNXyDhPHHNNMSHPcaSgNpjjsBYpMMjsTdS\",\n      \"type\": \"X25519KeyAgreementKey2019\", // external (property value)\n      \"controller\": \"did:example:123\",\n      \"publicKeyBase58\": \"9hFgmPVfmBZwRvFEyniQDBkz9LmV7gDEqytWyGZLmDXE\"\n    }\n  ],\n  ...\n}\n</code></pre></p> <p>The envelope packing process should set the <code>skid</code> header with value <code>did:example:123456789abcdefghi#keys-1</code> in the envelope's protected headers and fetch the underlying key to execute ECDH-1PU key derivation for content key wrapping.</p> <p>Assuming she also has Bob's DID document which happens to include the following <code>KeyAgreement</code> section:</p> <pre><code>{\n  \"@context\": \"https://www.w3.org/ns/did/v1\",\n  \"id\": \"did:example:jklmnopqrstuvwxyz1\",\n  ...\n  \"keyAgreement\": [\n    {\n      \"id\": \"did:example:jklmnopqrstuvwxyz1#key-1\",\n      \"type\": \"X25519KeyAgreementKey2019\", // external (property value)\n      \"controller\": \"did:example:jklmnopqrstuvwxyz1\",\n      \"publicKeyBase58\": \"9hFgmPVfmBZwRvFEyniQDBkz9LmV7gDEqytWyGZLmDXE\"\n    }\n  ],\n  ...\n}\n</code></pre> <p>There should be only 1 entry in the recipients of the envelope, representing Bob. The corresponding <code>kid</code> header for this recipient MUST have <code>did:example:jklmnopqrstuvwxyz1#key-1</code> as value. The packing process MUST extract the public key bytes found in <code>publicKeyBase58</code> of Bob's DID Doc <code>KeyAgreement[0]</code> to execute the ECDH-1PU key derivation for content key wrapping.</p> <p>When Bob receives the envelope, the unpacking process on his end MUST resolve the <code>skid</code> protected header value using Alice's DID doc's <code>KeyAgreement[0]</code> in order to extract her public key. In Alice's DID Doc example above, <code>KeyAgreement[0]</code> is a reference id, it MUST be resolved from the main <code>VerificationMethod[]</code> of Alice's DID document (not shown in the example).</p> <p>Once resolved, the unpacker will then execute ECDH-1PU key derivation using this key and Bob's own recipient key found in the envelope's <code>recipients[0]</code> to unwrap the content encryption key.</p>"},{"location":"features/0587-encryption-envelope-v2/#protecting-the-skid-header","title":"Protecting the <code>skid</code> header","text":"<p>When the <code>skid</code> cannot be revealed in a plain-text JWE header (to avoid potentially leaking sender's key id), the <code>skid</code> MAY be encrypted for each recipient. In this case, instead of having a <code>skid</code> protected header in the envelope, each recipient MAY include an <code>encrypted_skid</code> header with a value based on the encryption of <code>skid</code> using ECDH-ES <code>Z</code> computation of the <code>epk</code> and the recipient's key as the encryption key.</p> <p>For applications that don't require this protection, they MAY use <code>skid</code> protected header directly without any additional recipient headers.</p> <p>Applications MUST use either <code>skid</code> protected header or <code>encrypted_skid</code> recipients header but not both in the same envelope.</p>"},{"location":"features/0587-encryption-envelope-v2/#ecdh-1pu-key-wrapping-and-common-protected-headers","title":"ECDH-1PU key wrapping and common protected headers","text":"<p>When using authcrypt, the 1PU draft requires mandates the use of AES_CBC_HMAC_SHA family of content encryption algorithms. To meet this requirement, JWE messages MUST use common <code>epk</code>, <code>apu</code>, <code>apv</code> and <code>alg</code> headers for all recipients. They MUST be set in the <code>protected</code> headers JWE section.</p> <p>As per this requirement, the JWE building must first encrypt the payload then use the resulting <code>tag</code> as part of the key derivation process when wrapping the <code>cek</code>.</p> <p>To meet this requirement, the above headers must be defined as follows: * <code>epk</code>: generated once for all recipients. It MUST be of the same type and curve as all recipient keys since kdf with the sender key must be on the same curve.  - Example: <code>\"epk\": {\"kty\": \"EC\",\"crv\": \"P-256\",\"x\": \"BVDo69QfyXAdl6fbK6-QBYIsxv0CsNMtuDDVpMKgDYs\",\"y\": \"G6bdoO2xblPHrKsAhef1dumrc0sChwyg7yTtTcfygHA\"}</code> * <code>apu</code>: similar to <code>skid</code>, this is the producer (sender) identifier, it MUST contain the <code>skid</code> value base64 RawURL (no padding) encoded. Note: this is base64URL(<code>skid</code> value).  - Example for <code>skid</code> mentioned in an earlier section above: <code>ZGlkOmV4YW1wbGU6MTIzNDU2Nzg5YWJjZGVmZ2hpI2tleXMtMQ</code> * <code>apv</code>: this represents the recipients' <code>kid</code> list. The list must be alphanumerically sorted, <code>kid</code> values will then be concatenated with a <code>.</code> and the final result MUST be base64 URL (no padding) encoding of the SHA256 hash of concatenated list. * <code>alg</code>: this is the key wrapping algorithm, ie: <code>ECDH-1PU+A256KW</code>.</p> <p>A final note about <code>skid</code> header: since the 1PU draft does not require this header, authcrypt implementations MUST be able to resolve the sender kid from the <code>APU</code> header if <code>skid</code> is not set.</p>"},{"location":"features/0587-encryption-envelope-v2/#media-type","title":"Media Type","text":"<p>The media type associated to this envelope is <code>application/didcomm-encrypted+json</code>. RFC 0044 provides a general discussion of media (aka mime) types.</p> <p>The media type of the envelope MUST be set in the <code>typ</code> property of the JWE and the media type of the payload MUST be set in the <code>cty</code> property of the JWE.</p> <p>For example, following the guidelines of RFC 0044, an encrypted envelope with a plaintext DIDComm v1 payload contains the <code>typ</code> property with the value <code>application/didcomm-encrypted+json</code> and <code>cty</code> property with the value <code>application/json;flavor=didcomm-msg</code>.</p> <p>As specified in IETF RFC 7515 and referenced in IETF RFC 7516, implementations  MUST also support media types that omit <code>application/</code>.  For example, <code>didcomm-encrypted+json</code> and <code>application/didcomm-encrypted+json</code> are treated as equivalent media types.</p> <p>As discussed in RFC 0434 and RFC 0067, the <code>accept</code> property is used to advertise supported media types. The <code>accept</code> property may contain an envelope media type or a combination of the envelope media type and the content media type. In cases where the content media type is not present, the expectation is that the appropriate content media type can be inferred. For example, <code>application/didcomm-envelope-enc</code> indicates both Envelope v1 and DIDComm v1 and <code>application/didcomm-encrypted+json</code> indicates both Envelope v2 and DIDComm v2. However, some agents may choose to support Envelope v2 with a DIDComm v1 message payload.</p> <p>In case the <code>accept</code> property is set in both the DID service block and the out-of-band message, the out-of-band property takes precedence.</p>"},{"location":"features/0587-encryption-envelope-v2/#didcomm-v2-transition","title":"DIDComm v2 Transition","text":"<p>As this RFC specifies the same envelope format as will be used in DIDComm v2, an implementor should detect if the payload contains DIDComm v1 content or the JWM from DIDComm v2. These payloads can be distinguished based on the <code>cty</code> property of the JWE.</p> <p>As discussed in RFC 0044, the content type for the plaintext DIDComm v1 message is <code>application/json;flavor=didcomm-msg</code>. When the <code>cty</code> property contains <code>application/json;flavor=didcomm-msg</code>, the payload is treated as DIDComm v1. DIDComm Messaging will specify appropriate media types for DIDComm v2. To advertise the combination of Envelope v2 with a DIDComm v1 message, the media type is <code>application/didcomm-encrypted+json;cty=application/json</code>.</p>"},{"location":"features/0587-encryption-envelope-v2/#additional-aip-impacts","title":"Additional AIP impacts","text":"<p>Implementors supporting an AIP sub-target that contains this RFC (e.g., <code>DIDCOMMV2PREP</code>) MAY choose to only support Envelope v2 without support for the original envelope declared in RFC 0019. In these cases, the <code>accept</code> property will not contain <code>didcomm/aip2;env=rfc19</code> media type.</p>"},{"location":"features/0587-encryption-envelope-v2/#drawbacks","title":"Drawbacks","text":"<p>The DIDComm v2 specification is a draft. However, the aries-framework-go project has already implemented the new envelope format.</p>"},{"location":"features/0587-encryption-envelope-v2/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Our approach for Authcrypt compliance is to use the NIST approved <code>One-Pass Unified Model for ECDH</code> scheme described in SP 800-56A Rev. 3. The JOSE version is defined as <code>ECDH-1PU</code> in this IETF draft.</p> <p>Aries agents currently use the envelope described in RFC0019. This envelope uses libsodium (NaCl) encryption/decryption, which is based on Salsa20Poly1305 algorithm.</p>"},{"location":"features/0587-encryption-envelope-v2/#prior-art","title":"Prior art","text":"<ul> <li>The JWE family of encryption methods.</li> <li>Aries RFC 0019-encryption-envelope suggested envelope formats will be superseded by this RFC.</li> <li>Aries RFC 0025-didcomm-transports for the content type used in the proposed envelopes.</li> <li>Aries RFC 0334-jwe-envelope.</li> <li>DIDComm Messaging.</li> <li>minimal-cipher implementation</li> <li>Public Key Authenticated Encryption for JOSE: ECDH-1PU</li> <li>NIST SP 800-56A Rev. 3 Recommendation for Pair-Wise Key-Establishment schemes Using Discrete Logarithm Cryptography</li> </ul>"},{"location":"features/0587-encryption-envelope-v2/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"features/0587-encryption-envelope-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0592-indy-attachments/","title":"Aries RFC 0592: Indy Attachment Formats for Requesting and Presenting Credentials","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Formalizes the Indy AnonCreds attachments for issuing credentials and presenting proofs. A part of the Indy AnonCreds subtarget of AIP v2.0.</li> <li>Supersedes: less formally documented Indy attachment formats documented in Aries RFC 0036, Aries RFC 0037, etc.</li> <li>Start Date: 2017-01-01</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0592-indy-attachments/#summary","title":"Summary","text":"<p>This RFC registers attachment formats used with Hyperledger Indy-style ZKP-oriented credentials in Issue Credential Protocol 2.0 and Present Proof Protocol 2.0. These formats are generally considered v2 formats, as they align with the \"anoncreds2\" work in Hyperledger Ursa and are a second generation implementation. They began to be used in production in 2018 and are in active deployment in 2021.</p>"},{"location":"features/0592-indy-attachments/#motivation","title":"Motivation","text":"<p>Allows Indy-style credentials to be used with credential-related protocols that take pluggable formats as payloads.</p>"},{"location":"features/0592-indy-attachments/#reference","title":"Reference","text":""},{"location":"features/0592-indy-attachments/#cred-filter-format","title":"cred filter format","text":"<p>The potential holder uses this format to propose criteria for a potential credential for the issuer to offer.</p> <p>The identifier for this format is <code>hlindy/cred-filter@v2.0</code>. It is a base64-encoded version of the data structure specifying zero or more criteria from the following (non-base64-encoded) structure:</p> <pre><code>{\n    \"schema_issuer_did\": \"&lt;schema_issuer_did&gt;\",\n    \"schema_name\": \"&lt;schema_name&gt;\",\n    \"schema_version\": \"&lt;schema_version&gt;\",\n    \"schema_id\": \"&lt;schema_identifier&gt;\",\n    \"issuer_did\": \"&lt;issuer_did&gt;\",\n    \"cred_def_id\": \"&lt;credential_definition_identifier&gt;\"\n}\n</code></pre> <p>The potential holder may not know, and need not specify, all of these criteria. For example, the holder might only know the schema name and the (credential) issuer DID. Recall that the potential holder may specify target attribute values and MIME types in the credential preview.</p> <p>For example, the JSON (non-base64-encoded) structure might look like this:</p> <pre><code>{\n    \"schema_issuer_did\": \"did:sov:4RW6QK2HZhHxa2tg7t1jqt\",\n    \"schema_name\": \"bcgov-mines-act-permit.bcgov-mines-permitting\",\n    \"issuer_did\": \"did:sov:4RW6QK2HZhHxa2tg7t1jqt\"\n}\n</code></pre> <p>A complete <code>propose-credential</code> message from the Issue Credential protocol 2.0 embeds this format at <code>/filters~attach/data/base64</code>:</p> <pre><code>{\n    \"@id\": \"&lt;uuid of propose message&gt;\",\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/propose-credential\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\" : [{\n        \"attach_id\": \"&lt;attach@id value&gt;\",\n        \"format\": \"hlindy/cred-filter@v2.0\"\n    }],\n    \"filters~attach\": [{\n        \"@id\": \"&lt;attach@id value&gt;\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"base64\": \"ewogICAgInNjaGVtYV9pc3N1ZXJfZGlkIjogImRpZDpzb3Y... (clipped)... LMkhaaEh4YTJ0Zzd0MWpxdCIKfQ==\"\n        }\n    }]\n}\n</code></pre>"},{"location":"features/0592-indy-attachments/#cred-abstract-format","title":"cred abstract format","text":"<p>This format is used to clarify the structure and semantics (but not the concrete data values) of a potential credential, in offers sent from issuer to potential holder.</p> <p>The identifier for this format is <code>hlindy/cred-abstract@v2.0</code>. It is a base64-encoded version of the data returned from <code>indy_issuer_create_credential_offer()</code>.</p> <p>The JSON (non-base64-encoded) structure might look like this:</p> <pre><code>{\n    \"schema_id\": \"4RW6QK2HZhHxa2tg7t1jqt:2:bcgov-mines-act-permit.bcgov-mines-permitting:0.2.0\",\n    \"cred_def_id\": \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    \"nonce\": \"57a62300-fbe2-4f08-ace0-6c329c5210e1\",\n    \"key_correctness_proof\" : &lt;key_correctness_proof&gt;\n}\n</code></pre> <p>A complete <code>offer-credential</code> message from the Issue Credential protocol 2.0 embeds this format at <code>/offers~attach/data/base64</code>:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/offer-credential\",\n    \"@id\": \"&lt;uuid of offer message&gt;\",\n    \"replacement_id\": \"&lt;issuer unique id&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\": \"hlindy/cred-abstract@v2.0\"\n        }\n    ],\n    \"offers~attach\": [\n        {\n            \"@id\": \"&lt;attach@id value&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"ewogICAgInNjaGVtYV9pZCI6ICI0Ulc2UUsySFpoS... (clipped)... jb3JyZWN0bmVzc19wcm9vZj4KfQ==\"\n            }\n        }\n    ]\n}\n</code></pre> <p>The same structure can be embedded at <code>/offers~attach/data/base64</code> in an <code>offer-credential</code> message. </p>"},{"location":"features/0592-indy-attachments/#cred-request-format","title":"cred request format","text":"<p>This format is used to formally request a credential. It differs from the credential abstract above in that it contains a cryptographic commitment to a link secret; an issuer can therefore use it to bind a concrete instance of an issued credential to the appropriate holder. (In contrast, the credential abstract describes the schema and cred def, but not enough information to actually issue to a specific holder.)</p> <p>The identifier for this format is <code>hlindy/cred-req@v2.0</code>. It is a base64-encoded version of the data returned from indy_prover_create_credential_req().</p> <p>The JSON (non-base64-encoded) structure might look like this:</p> <pre><code>{\n    \"prover_did\" : \"did:sov:abcxyz123\",\n    \"cred_def_id\" : \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    // Fields below can depend on Cred Def type\n    \"blinded_ms\" : &lt;blinded_master_secret&gt;,\n    \"blinded_ms_correctness_proof\" : &lt;blinded_ms_correctness_proof&gt;,\n    \"nonce\": \"fbe22300-57a6-4f08-ace0-9c5210e16c32\"\n}\n</code></pre> <p>A complete <code>request-credential</code> message from the Issue Credential protocol 2.0 embeds this format at <code>/requests~attach/data/base64</code>:</p> <pre><code>{\n    \"@id\": \"cf3a9301-6d4a-430f-ae02-b4a79ddc9706\",\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/request-credential\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"formats\": [{\n        \"attach_id\": \"7cd11894-838a-45c0-a9ec-13e2d9d125a1\",\n        \"format\": \"hlindy/cred-req@v2.0\"\n    }],\n    \"requests~attach\": [{\n        \"@id\": \"7cd11894-838a-45c0-a9ec-13e2d9d125a1\",\n        \"mime-type\": \"application/json\",\n        \"data\": {\n            \"base64\": \"ewogICAgInByb3Zlcl9kaWQiIDogImRpZDpzb3Y6YWJjeHl.. (clipped)... DAtNTdhNi00ZjA4LWFjZTAtOWM1MjEwZTE2YzMyIgp9\"\n        }\n    }]\n}\n</code></pre>"},{"location":"features/0592-indy-attachments/#credential-format","title":"credential format","text":"<p>A concrete, issued Indy credential may be transmitted over many protocols, but is specifically expected as the final message in Issuance Protocol 2.0. The identifier for its format is <code>hlindy/cred@v2.0</code>.</p> <p>This is a credential that's designed to be held but not shared directly. It is stored in the holder's wallet and used to derive a novel ZKP or W3C-compatible verifiable presentation just in time for each sharing of credential material.</p> <p>The encoded values of the credential MUST follow the encoding algorithm as described in Encoding Claims.</p> <p>This is the format emitted by libindy's indy_issuer_create_credential() function. It is JSON-based and might look like this:</p> <pre><code>{\n    \"schema_id\": \"4RW6QK2HZhHxa2tg7t1jqt:2:bcgov-mines-act-permit.bcgov-mines-permitting:0.2.0\",\n    \"cred_def_id\": \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    \"rev_reg_id\", \"EyN78DDGHyok8qw6W96UBY:4:EyN78DDGHyok8qw6W96UBY:3:CL:56389:CardossierOrgPerson:CL_ACCUM:1-1000\",\n    \"values\": {\n        \"attr1\" : {\"raw\": \"value1\", \"encoded\": \"value1_as_int\" },\n        \"attr2\" : {\"raw\": \"value2\", \"encoded\": \"value2_as_int\" }\n    },\n    // Fields below can depend on Cred Def type\n    \"signature\": &lt;signature&gt;,\n    \"signature_correctness_proof\": &lt;signature_correctness_proof&gt;\n    \"rev_reg\": &lt;revocation registry state&gt;\n    \"witness\": &lt;witness&gt;\n}\n</code></pre> <p>An exhaustive description of the format is out of scope here; it is more completely documented in white papers, source code, and other Indy materials.</p>"},{"location":"features/0592-indy-attachments/#proof-request-format","title":"proof request format","text":"<p>This format is used to formally request a verifiable presenation (proof) derived from an Indy-style ZKP-oriented credential. It can also be used by a holder to propose a presentation.</p> <p>The identifier for this format is <code>hlindy/proof-req@v2.0</code>. It is a base64-encoded version of the data returned from indy_prover_search_credentials_for_proof_req().</p> <p>Here is a sample proof request that embodies the following: \"Using a government-issued ID, disclose the credential holder\u2019s name and height, hide the credential holder\u2019s sex, get them to self-attest their phone number, and prove that their age is at least 18\":</p> <pre><code>{\n    \"nonce\": \u201c2934823091873049823740198370q23984710239847\u201d, \n    \"name\":\"proof_req_1\",\n    \"version\":\"0.1\",\n    \"requested_attributes\":{\n        \"attr1_referent\": {\"name\":\"sex\"},\n        \"attr2_referent\": {\"name\":\"phone\"},\n        \"attr3_referent\": {\"names\": [\"name\", \"height\"], \"restrictions\": &lt;restrictions specifying government-issued ID&gt;}\n    },\n    \"requested_predicates\":{\n        \"predicate1_referent\":{\"name\":\"age\",\"p_type\":\"&gt;=\",\"p_value\":18}\n    }\n}\n</code></pre>"},{"location":"features/0592-indy-attachments/#proof-format","title":"proof format","text":"<p>This is the format of an Indy-style ZKP. It plays the same role as a W3C-style verifiable presentation (VP) and can be mapped to one.</p> <p>The raw values encoded in the presentation SHOULD be verified against the encoded values using the encoding algorithm as described below in Encoding Claims.</p> <p>The identifier for this format is <code>hlindy/proof@v2.0</code>. It is a version of the (JSON-based) data emitted by libindy's indy_prover_create_proof()) function. A proof that responds to the previous proof request sample looks like this:</p> <pre><code>{\n  \"proof\":{\n    \"proofs\":[\n      {\n        \"primary_proof\":{\n          \"eq_proof\":{\n            \"revealed_attrs\":{\n              \"height\":\"175\",\n              \"name\":\"1139481716457488690172217916278103335\"\n            },\n            \"a_prime\":\"5817705...096889\",\n            \"e\":\"1270938...756380\",\n            \"v\":\"1138...39984052\",\n            \"m\":{\n              \"master_secret\":\"375275...0939395\",\n              \"sex\":\"3511483...897083518\",\n              \"age\":\"13430...63372249\"\n            },\n            \"m2\":\"1444497...2278453\"\n          },\n          \"ge_proofs\":[\n            {\n              \"u\":{\n                \"1\":\"152500...3999140\",\n                \"2\":\"147748...2005753\",\n                \"0\":\"8806...77968\",\n                \"3\":\"10403...8538260\"\n              },\n              \"r\":{\n                \"2\":\"15706...781609\",\n                \"3\":\"343...4378642\",\n                \"0\":\"59003...702140\",\n                \"DELTA\":\"9607...28201020\",\n                \"1\":\"180097...96766\"\n              },\n              \"mj\":\"134300...249\",\n              \"alpha\":\"827896...52261\",\n              \"t\":{\n                \"2\":\"7132...47794\",\n                \"3\":\"38051...27372\",\n                \"DELTA\":\"68025...508719\",\n                \"1\":\"32924...41082\",\n                \"0\":\"74906...07857\"\n              },\n              \"predicate\":{\n                \"attr_name\":\"age\",\n                \"p_type\":\"GE\",\n                \"value\":18\n              }\n            }\n          ]\n        },\n        \"non_revoc_proof\":null\n      }\n    ],\n    \"aggregated_proof\":{\n      \"c_hash\":\"108743...92564\",\n      \"c_list\":[ 6 arrays of 257 numbers between 0 and 255]\n    }\n  },\n  \"requested_proof\":{\n    \"revealed_attrs\":{\n      \"attr1_referent\":{\n        \"sub_proof_index\":0,\n        \"raw\":\"Alex\",\n        \"encoded\":\"1139481716457488690172217916278103335\"\n      }\n    },\n    \"revealed_attr_groups\":{\n      \"attr4_referent\":{\n        \"sub_proof_index\":0,\n        \"values\":{\n          \"name\":{\n            \"raw\":\"Alex\",\n            \"encoded\":\"1139481716457488690172217916278103335\"\n          },\n          \"height\":{\n            \"raw\":\"175\",\n            \"encoded\":\"175\"\n          }\n        }\n      }\n    },\n    \"self_attested_attrs\":{\n      \"attr3_referent\":\"8-800-300\"\n    },\n    \"unrevealed_attrs\":{\n      \"attr2_referent\":{\n        \"sub_proof_index\":0\n      }\n    },\n    \"predicates\":{\n      \"predicate1_referent\":{\n        \"sub_proof_index\":0\n      }\n    }\n  },\n  \"identifiers\":[\n    {\n      \"schema_id\":\"NcYxiDXkpYi6ov5FcYDi1e:2:gvt:1.0\",\n      \"cred_def_id\":\"NcYxi...cYDi1e:2:gvt:1.0:TAG_1\",\n      \"rev_reg_id\":null,\n      \"timestamp\":null\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0592-indy-attachments/#unrevealed-attributes","title":"Unrevealed Attributes","text":"<p>AnonCreds supports a holder responding to a proof request with some of the requested claims included in an <code>unrevealed_attrs</code> array, as seen in the example above, with <code>attr2_referent</code>. Assuming the rest of the proof is valid, AnonCreds will indicate that a proof with unrevealed attributes has been successfully verified. It is the responsibility of the verifier to determine if the purpose of the verification has been met if some of the attributes are not revealed.</p> <p>There are at least a few valid use cases for this approach:</p> <ul> <li>A verifier may ask for, but not require, that a prover provide all of the   requested attributes.</li> <li>A verifier may ask for claims from several credentials, expecting holders to   only have some of the credentials. The holders respond with claims from the   credentials they have, and leave the other attributes unrevealed.</li> <li>For example, a verifier may ask for a national identity card and an resident     card, knowing that most holders will have one or the other.</li> </ul>"},{"location":"features/0592-indy-attachments/#encoding-claims","title":"Encoding Claims","text":"<p>Claims in AnonCreds-based verifiable credentials are put into the credential in two forms, <code>raw</code> and <code>encoded</code>. <code>raw</code> is the actual data value, and <code>encoded</code> is the (possibly derived) integer value that is used in presentations. At this time, AnonCreds does not take an opinion on the method used for encoding the raw value.</p> <p>AnonCreds issuers and verifiers must agree on the encoding method so that the verifier can check that the <code>raw</code> value returned in a presentation corresponds to the proven <code>encoded</code> value. The following is the encoding algorithm that MUST be used by Issuers when creating credentials and SHOULD be verified by Verifiers receiving presentations:</p> <ul> <li>keep any 32-bit integer as is</li> <li>convert any string integer (e.g. <code>\"1234\"</code>) to be a 32-bit integer (e.g. <code>1234</code>)</li> <li>for data of any other type:</li> <li>convert to string (use string \"None\" for null)</li> <li>encode via utf-8 to bytes</li> <li>apply SHA-256 to digest the bytes</li> <li>convert the resulting digest bytes, big-endian, to integer</li> <li>stringify the integer as a decimal.</li> </ul> <p>An example implementation in Python can be found here.</p> <p>A gist of test value pairs can be found here.</p>"},{"location":"features/0592-indy-attachments/#notes-on-encoding-claims","title":"Notes on Encoding Claims","text":"<ul> <li>In converting any string integer to an integer, leading 0s in the string are (by definition) not part of the integer. The leading 0's remain in the (untouched) <code>raw</code> value.</li> <li>The use of AnonCreds predicates, such as proving \"older than 21\" based on a date of birth claim without sharing the date of birth, is based on an expression involving the <code>encoded</code> value. Thus, only <code>raw</code> integers or string integers can be used in AnonCreds predicates.</li> </ul>"},{"location":"features/0592-indy-attachments/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0593-json-ld-cred-attach/","title":"Aries RFC 0593: JSON-LD Credential Attachment format for requesting and issuing credentials","text":"<ul> <li>Authors: Timo Glastra (Animo Solutions), George Aristy (SecureKey Technologies)</li> <li>Status: ADOPTED</li> <li>Since: 2021-04-15</li> <li>Status Note: Included as part of the JSON-LD verifiable credentials subtarget of AIP v2.0.</li> <li>Supersedes:</li> <li>Start Date: 2021-02-17</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0593-json-ld-cred-attach/#summary","title":"Summary","text":"<p>This RFC registers an attachment format for use in the issue-credential V2 protocol based on JSON-LD credentials with Linked Data Proofs from the VC Data Model.</p> <p>It defines a minimal set of parameters needed to create a common understanding of the verifiable credential to issue. It is based on version 1.0 of the Verifiable Credentials Data Model which is a W3C recommendation since 19 November 2019.</p>"},{"location":"features/0593-json-ld-cred-attach/#motivation","title":"Motivation","text":"<p>The Issue Credential protocol needs an attachment format to be able to exchange JSON-LD credentials with Linked Data Proofs. It is desirable to make use of specifications developed in an open standards body, such as the Credential Manifest for which the attachment format is described in RFC 0511: Credential-Manifest Attachment format. However, the Credential Manifest is not finished and ready yet, and therefore there is a need to bridge the gap between standards.</p>"},{"location":"features/0593-json-ld-cred-attach/#tutorial","title":"Tutorial","text":"<p>Complete examples of messages are provided in the reference section.</p>"},{"location":"features/0593-json-ld-cred-attach/#reference","title":"Reference","text":""},{"location":"features/0593-json-ld-cred-attach/#ld-proof-vc-detail-attachment-format","title":"<code>ld-proof-vc-detail</code> attachment format","text":"<p>Format identifier: <code>aries/ld-proof-vc-detail@v1.0</code></p> <p>This format is used to formally propose, offer, or request a credential. The <code>credential</code> property should contain the credential as it is going to be issued, without the <code>proof</code> and <code>credentialStatus</code> properties. Options for these properties are specified in the <code>options</code> object.</p> <p>The JSON structure might look like this:</p> <pre><code>{\n  \"credential\": {\n    \"@context\": [\n      \"https://www.w3.org/2018/credentials/v1\",\n      \"https://www.w3.org/2018/credentials/examples/v1\"\n    ],\n    \"id\": \"urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5\",\n    \"type\": [\"VerifiableCredential\", \"UniversityDegreeCredential\"],\n    \"issuer\": \"did:key:z6MkodKV3mnjQQMB9jhMZtKD9Sm75ajiYq51JDLuRSPZTXrr\",\n    \"issuanceDate\": \"2020-01-01T19:23:24Z\",\n    \"expirationDate\": \"2021-01-01T19:23:24Z\",\n    \"credentialSubject\": {\n      \"id\": \"did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\",\n      \"degree\": {\n        \"type\": \"BachelorDegree\",\n        \"name\": \"Bachelor of Science and Arts\"\n      }\n    }\n  },\n  \"options\": {\n    \"proofPurpose\": \"assertionMethod\",\n    \"created\": \"2020-04-02T18:48:36Z\",\n    \"domain\": \"example.com\",\n    \"challenge\": \"9450a9c1-4db5-4ab9-bc0c-b7a9b2edac38\",\n    \"credentialStatus\": {\n      \"type\": \"CredentialStatusList2017\"\n    },\n    \"proofType\": \"Ed25519Signature2018\"\n  }\n}\n</code></pre> <p>A complete <code>request credential</code> message form the Issue Credential protocol 2.0 might look like this:</p> <pre><code>{\n  \"@id\": \"7293daf0-ed47-4295-8cc4-5beb513e500f\",\n  \"@type\": \"https://didcomm.org/issue-credential/%VER/request-credential\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"13a3f100-38ce-4e96-96b4-ea8f30250df9\",\n      \"format\": \"aries/ld-proof-vc-detail@v1.0\"\n    }\n  ],\n  \"requests~attach\": [\n    {\n      \"@id\": \"13a3f100-38ce-4e96-96b4-ea8f30250df9\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"ewogICJjcmVkZW50aWFsIjogewogICAgIkBjb250...(clipped)...IkVkMjU1MTlTaWduYXR1cmUyMDE4IgogIH0KfQ==\"\n      }\n    }\n  ]\n}\n</code></pre> <ul> <li> <p><code>credential</code> - Required. Detail of the JSON-LD Credential that will be issued. Properties MUST align with the Verifiable Credentials Data Model. This also means all properties required by the data model MUST be present. The properties listed below are formally supported, but additional properties MAY be included if it conforms with the data model.</p> </li> <li> <p><code>@context</code></p> </li> <li><code>id</code></li> <li><code>type</code></li> <li><code>issuer</code></li> <li><code>issuanceDate</code></li> <li><code>expirationDate</code></li> <li> <p><code>credentialSubject</code></p> </li> <li> <p><code>options</code> - Required. Options for specifying how the linked data proof is created.</p> </li> <li> <p><code>proofType</code> - Required string. The proof type used for the proof. Should match suites registered in the Linked Data Cryptographic Suite Registry.</p> </li> <li><code>proofPurpose</code> - Optional string, default <code>assertionMethod</code>. The proof purpose used for the proof. Should match proof purposes registered in the Linked Data Proofs Specification.</li> <li><code>created</code> - Optional string, default current system time. The date and time of the proof (with a maximum accuracy in seconds).</li> <li><code>challenge</code> - Optional string. A challenge to include in the proof. SHOULD be provided by the requesting party of the credential (=holder).</li> <li><code>domain</code> - Optional string. The intended domain of validity for the proof.</li> <li><code>credentialStatus</code> - Optional object. The credential status mechanism to use for the credential. Omitting the property indicates the issued credential will not include a credential status.<ul> <li><code>type</code> - Required string. Credential status method type to use for the credential. Should match status method registered in the Verifiable Credential Extension Registry</li> </ul> </li> </ul> <p>The format is closely related to the Verifiable Credentials HTTP API, but diverts on some places. The main differences are:</p> <ul> <li>The types in the VC HTTP API are more restrictive (.e.g. <code>@context</code> must be array of strings). This format allows all fields to use the full syntax as described by the verifiable credentials data model.</li> <li>Instead of specifying the exact <code>verificationMethod</code>, the <code>proofType</code> that will be used for the credential can be specified.</li> </ul>"},{"location":"features/0593-json-ld-cred-attach/#ld-proof-vc-attachment-format","title":"<code>ld-proof-vc</code> attachment format","text":"<p>Format identifier: <code>aries/ld-proof-vc@v1.0</code></p> <p>This format is used to transmit a verifiable credential with linked data proof. The contents of the attachment is a standard JSON-LD Verifiable Credential object with linked data proof as defined by the Verifiable Credentials Data Model and the Linked Data Proofs specification.</p> <p>The JSON structure might look like this:</p> <pre><code>{\n  \"@context\": [\n    \"https://www.w3.org/2018/credentials/v1\",\n    \"https://www.w3.org/2018/credentials/examples/v1\"\n  ],\n  \"id\": \"http://example.gov/credentials/3732\",\n  \"type\": [\"VerifiableCredential\", \"UniversityDegreeCredential\"],\n  \"issuer\": {\n    \"id\": \"did:web:vc.transmute.world\"\n  },\n  \"issuanceDate\": \"2020-03-10T04:24:12.164Z\",\n  \"credentialSubject\": {\n    \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n    \"degree\": {\n      \"type\": \"BachelorDegree\",\n      \"name\": \"Bachelor of Science and Arts\"\n    }\n  },\n  \"proof\": {\n    \"type\": \"JsonWebSignature2020\",\n    \"created\": \"2020-03-21T17:51:48Z\",\n    \"verificationMethod\": \"did:web:vc.transmute.world#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A\",\n    \"proofPurpose\": \"assertionMethod\",\n    \"jws\": \"eyJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdLCJhbGciOiJFZERTQSJ9..OPxskX37SK0FhmYygDk-S4csY_gNhCUgSOAaXFXDTZx86CmI5nU9xkqtLWg-f4cqkigKDdMVdtIqWAvaYx2JBA\"\n  }\n}\n</code></pre> <p>A complete <code>issue-credential</code> message from the Issue Credential protocol 2.0 might look like this:</p> <pre><code>{\n  \"@id\": \"284d3996-ba85-45d9-964b-9fd5805517b6\",\n  \"@type\": \"https://didcomm.org/issue-credential/%VER/issue-credential\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"5b38af88-d36f-4f77-bb7a-2f04ab806eb8\",\n      \"format\": \"aries/ld-proof-vc@v1.0\"\n    }\n  ],\n  \"credentials~attach\": [\n    {\n      \"@id\": \"5b38af88-d36f-4f77-bb7a-2f04ab806eb8\",\n      \"mime-type\": \"application/ld+json\",\n      \"data\": {\n        \"base64\": \"ewogICAgICAgICAgIkBjb250ZXogWwogICAgICAg...(clipped)...RNVmR0SXFXZhWXgySkJBIgAgfQogICAgICAgIH0=\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0593-json-ld-cred-attach/#supported-proof-types","title":"Supported Proof Types","text":"<p>Following are the Linked Data proof types on Verifiable Credentials that MUST be supported for compliance with this RFC. All suites listed in the following table MUST be registered in the Linked Data Cryptographic Suite Registry:</p> Suite Spec Enables Selective disclosure? Enables Zero-knowledge proofs? Optional Ed25519Signature2018 Link No No No BbsBlsSignature2020** Link Yes No No JsonWebSignature2020*** Link No No Yes <p>** Note: see RFC0646 for details on how BBS+ signatures are to be produced and consumed by Aries agents.</p> <p>*** Note: P-256 and P-384 curves are supported.</p>"},{"location":"features/0593-json-ld-cred-attach/#drawbacks","title":"Drawbacks","text":"<p>N/A</p>"},{"location":"features/0593-json-ld-cred-attach/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>The <code>hlindy-zkp-v1.0</code> format is an alternative restricted to the Hyperledger Indy network. The <code>dif/credential-manifest@v1.0</code> allows to issue JSON-LD credentials but is not ready yet for usage.</li> </ul>"},{"location":"features/0593-json-ld-cred-attach/#prior-art","title":"Prior art","text":"<p>N/A</p>"},{"location":"features/0593-json-ld-cred-attach/#unresolved-questions","title":"Unresolved questions","text":"<p>N/A</p>"},{"location":"features/0593-json-ld-cred-attach/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0627-static-peer-dids/","title":"Aries RFC 0627: Static Peer DIDs","text":"<ul> <li>Authors: Daniel Hardman</li> <li>Status: RETIRED</li> <li>Since: 2021-04-07</li> <li>Status Note: formally freezes a set of ../../features that have been relatively stable for about 18 months</li> <li>Start Date: 2021-03-24</li> <li>Tags: feature</li> </ul>"},{"location":"features/0627-static-peer-dids/#summary","title":"Summary","text":"<p>Formally documents a very crisp profile of peer DID functionality that can be referenced in Aries Interop Profiles.</p>"},{"location":"features/0627-static-peer-dids/#motivation","title":"Motivation","text":"<p>The Peer DID Spec includes a number of advanced ../../features that are still evolving. However, a subset of its functionality is easy to implement and would be helpful to freeze for the purpose of Aries interop.</p>"},{"location":"features/0627-static-peer-dids/#tutorial","title":"Tutorial","text":""},{"location":"features/0627-static-peer-dids/#spec-version","title":"Spec version","text":"<p>The Peer DID method spec is still undergoing minor evolution. However, it is relatively stable, particularly in the simpler ../../features.</p> <p>This Aries RFC targets the version of the spec that is dated April 2, 2021 in its rendered form, or github commit 202a913 in its source form. Note that the rendered form of the spec may update without warning, so the github commit is the better reference.</p>"},{"location":"features/0627-static-peer-dids/#targeted-layers","title":"Targeted layers","text":"<p>Support for peer DIDs is imagined to target configurable \"layers\" of interoperability:</p> <p></p> <p>For a careful definition of what these layers entail, please see https://identity.foundation/peer-did-method-spec/#layers-of-support.</p> <p>This Aries RFC targets Layers 1 and 2. That is, code that complies with this RFC would satisfy the required behaviors for Layer 1 and for Layer 2. Note, however, that Layer 2 is broken into accepting and giving static peer DIDs. An RFC-compliant implementation may choose to implement either side, or both.</p> <p>Support for Layer 3 (dynamic peer DIDs that have updatable state and that synchronize that state using Sync Connection Protocol as documented in Aries RFC 0030) is NOT required by this RFC. However, if there is an intent to support dynamic updates in the future, use of <code>numalgo</code> Method 1 is encouraged, as this allows static peer DIDs to acquire new state when dynamic support is added. (See next section.)</p>"},{"location":"features/0627-static-peer-dids/#targeted-generation-methods-numalgo","title":"Targeted Generation Methods (<code>numalgo</code>)","text":"<p>Peer DIDs can use several different algorithms to generate the entropy that constitutes their numeric basis. See https://identity.foundation/peer-did-method-spec/#generation-method for details.</p> <p>This RFC targets Method 0 (inception key without doc), Method 1 (genesis doc), and Method 2 (multiple inception keys). Code that complies with this RFC, and that intends to accept static DIDs at Layer 2a, MUST accept peer DIDs that use any of these methods. Code that intends to give peer DIDs (Layer 2b) MUST give peer DIDs that use at least one of these three methods.</p>"},{"location":"features/0627-static-peer-dids/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0641-linking-binary-objects-to-credentials/","title":"0641: Linking binary objects to credentials using hash based references","text":"<ul> <li>Authors: Berend Sliedrecht (Animo Solutions)</li> <li>Status: PROPOSED</li> <li>Since: 2021-04-22</li> <li>Status Note: Proposal</li> <li>Start Date: 2021-03-17</li> <li>Tags: feature, credentials</li> </ul>"},{"location":"features/0641-linking-binary-objects-to-credentials/#summary","title":"Summary","text":"<p>This RFC provides a solution for issuing and presenting credentials with external binary objects, after referred to as attachments. It is compatible with 0036: Issue Credential Protocol V1, 0453: Issue Credential Protocol V2, 0037: Present Proof V1 protocol and 0454: Present Proof V2 Protocol. These external attachments could consist of images, PDFs, zip files, movies, etc. Through the use of <code>DIDComm attachments</code>, 0017: Attachments, the data can be embedded directly into the attachment or externally hosted. In order to maintain integrity over these attachments, hashlinks are used as the checksum.</p>"},{"location":"features/0641-linking-binary-objects-to-credentials/#motivation","title":"Motivation","text":"<p>Many use cases, such as a rental agreement or medical data in a verifiable credential, rely on attachments, small or large. At this moment, it is possible to issue credentials with accompanying attachments. When the attachment is rather small, this will work fine. However, larger attachments cause inconsistent timing issues and are resource intensive.</p>"},{"location":"features/0641-linking-binary-objects-to-credentials/#tutorial","title":"Tutorial","text":"<p>It is already possible to issue and verify base64-encoded attachments in credentials. When a credential is getting larger and larger, it becomes more and more impractical as it has to be signed, which is time consuming and resource intensive. A solution for this is to use the attachments decorator. This decorator creates a way to externalize the attachment from the credential attributes. By allowing this, the signing will be faster and more consistent. However, DIDComm messages SHOULD stay small, like with SMTP or Bluetooth, as specified in 0017: Attachments. In the attachments decorator it is also possible to specify a list of URLs where the attachment might be located for download. This list of URLs is accompanied by a <code>sha256</code> tag that is a checksum over the file to maintain integrity. This <code>sha256</code> tag can only contain a sha256 hash and if another algorithm is preferred then the hashlink MUST be used as the checksum.</p> <p>When issuing and verifying a credential, messages have to be sent between the holder, issuer and verifier. In order to circumvent additional complexity, such as looking at previously sent credentials for the attachment, the attachments decorator, when containing an attachment, MUST be sent at all of the following steps:</p> <p>Issue Credential V1 &amp; V2</p> <ol> <li>Credential Proposal</li> <li>Credential Offer</li> <li>Credential Request</li> <li>Credential</li> </ol> <p>Present Proof V1 &amp; V2</p> <ol> <li>Presentation Proposal</li> <li>Presentation Request</li> <li>Presentation</li> </ol>"},{"location":"features/0641-linking-binary-objects-to-credentials/#linking","title":"Linking","text":"<p>When a credential is issued with an attachment in the attachments decorator, be it a base64-encoded file or a hosted file, the link has to be made between the credential and the attachment. The link MUST be made with the <code>attribute.value</code> of the credential and the <code>@id</code> tag of the attachment in the attachments decorator.</p>"},{"location":"features/0641-linking-binary-objects-to-credentials/#hashlink","title":"Hashlink","text":"<p>A hashlink, as specified in IETF: Cryptographic Hyperlinks, is a formatted hash that has a prefix of <code>hl:</code> and an optional suffix of metadata. The hash in the hashlink is a multihash, which means that according to the prefix of the hash it is possible to see which hashing algorithm and encoding algorithm has been chosen. An example of a hashlink would be:</p> <p><code>hl:zQmcWyBPyedDzHFytTX6CAjjpvqQAyhzURziwiBKDKgqx6R</code></p> <p>This example shows the prefix of <code>hl:</code> indicating that it is a hashlink and the hash after the prefix is a multihash.</p> <p>The hashlink also allows for opional metadata, such as; a list of URLs where the attachment is hosted and a MIME-type. These metadata values are encoded in the CBOR data format using the specified algortihm from section 3.1.2 in the IETF: Cryptographic Hyperlinks.</p> <p>When a holder receives a credential with hosted attachments, the holder MAY rehost these attachments. A holder would do this in order to prevent the phone-home problem. If a holder does not care about this issue, this is use case specific, this can be left out but should be considered.</p>"},{"location":"features/0641-linking-binary-objects-to-credentials/#inlined-attachments-as-a-credential-attribute","title":"Inlined Attachments as a Credential Attribute","text":"<p>Attachments can be inlined in the credential attribute as a base64-encoded string. With this, there is no need for the attachment decorator. Below is an example of embedding a base64-encoded file as a string in a credential attribute.</p> <pre><code>{\n  \"name\": \"Picture of a cat\",\n  \"mime-type\": \"image/png\",\n  \"value\": \"VGhpcyBpc ... (many bytes omitted) ... C4gSG93IG5pY2U=\"\n}\n</code></pre>"},{"location":"features/0641-linking-binary-objects-to-credentials/#attachments-inlined-in-the-attachment-decorator","title":"Attachments inlined in the Attachment Decorator","text":"<p>When the attachments decorator is used to issue a credential with a binary object, a link has to be made between the credential value and the corresponding attachment. This link MUST be a hash, specifically a hashlink based on the checksum of the attachment.</p> <p>As stated in 0008: message id and threading, the <code>@id</code> tag of the attachment MUST NOT contain a colon and MUST NOT be longer than 64 characters. because of this, the <code>@id</code> can not contain a hashlink and MUST contain the multihash with a maximum length of 64 characters. When a hash is longer than 64 character, use the first 64 characters.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/issue-credential/%VER/issue-credential\",\n  \"@id\": \"&lt;uuid of issue message&gt;\",\n  \"goal_code\": \"&lt;goal-code&gt;\",\n  \"replacement_id\": \"&lt;issuer unique id&gt;\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"&lt;attach@id value&gt;\",\n      \"format\": \"hlindy/cred@v2.0\"\n    }\n  ],\n  \"credentials~attach\": [\n    {\n      \"@id\": \"&lt;attachment-id&gt;\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"json\": {\n          \"schema_id\": \"4RW6QK2HZhHxa2tg7t1jqt:2:catSchema:0.3.0\",\n          \"cred_def_id\": \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58161:default\",\n          \"values\": {\n            \"pictureOfACat\": {\n              \"raw\": \"hl:zQmcWyBPyedDzHFytTX6CAjjpvqQAyhzURziwiBKDKgqx6R\",\n              \"encoded\": \"hl:zQmcWyBPyedDzHFytTX6CAjjpvqQAyhzURziwiBKDKgqx6R\"\n            }\n          },\n          \"signature\": \"&lt;signature&gt;\",\n          \"signature_correctness_proof\": \"&lt;signature_correctness_proof&gt;\"\n        }\n      }\n    }\n  ],\n  \"~attach\": [\n    {\n      \"@id\": \"zQmcWyBPyedDzHFytTX6CAjjpvqQAyhzURziwiBKDKgqx6R\",\n      \"mime-type\": \"image/png\",\n      \"filename\": \"cat.png\",\n      \"byte_count\": 2181,\n      \"lastmod_time\": \"2021-04-20 19:38:07Z\",\n      \"description\": \"Cute picture of a cat\",\n      \"data\": {\n        \"base64\": \"VGhpcyBpcyBhIGNv ... (many bytes omitted) ... R0ZXIgU0hJQkEgSU5VLg==\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0641-linking-binary-objects-to-credentials/#hosted-attachments","title":"Hosted attachments","text":"<p>The last method of adding a binary object in a credential is by using the attachments decorator in combination with external hosting. In the example below the attachment is hosted at two locations. These two URLs MUST point to the same file and match the integrity check with the <code>sha256</code> value. It is important to note that when an issuer hosts an attachment, and issues a credential with this attachment, that the holder rehosts this attachment to prevent the phone-home assosiation.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/issue-credential/%VER/issue-credential\",\n  \"@id\": \"&lt;uuid of issue message&gt;\",\n  \"goal_code\": \"&lt;goal-code&gt;\",\n  \"replacement_id\": \"&lt;issuer unique id&gt;\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"&lt;attach@id value&gt;\",\n      \"format\": \"hlindy/cred@v2.0\"\n    }\n  ],\n  \"credentials~attach\": [\n    {\n      \"@id\": \"&lt;attachment-id&gt;\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"json\": {\n          \"schema_id\": \"4RW6QK2HZhHxa2tg7t1jqt:2:catSchema:0.3.0\",\n          \"cred_def_id\": \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58161:default\",\n          \"values\": {\n            \"pictureOfACat\": {\n              \"raw\": \"hl:zQmcWyBPyedDzHFytTX6CAjjpvqQAyhzURziwiBKDKgqx6R\",\n              \"encoded\": \"hl:zQmcWyBPyedDzHFytTX6CAjjpvqQAyhzURziwiBKDKgqx6R\"\n            }\n          },\n          \"signature\": \"&lt;signature&gt;\",\n          \"signature_correctness_proof\": \"&lt;signature_correctness_proof&gt;\"\n        }\n      }\n    }\n  ],\n  \"~attach\": [\n    {\n      \"@id\": \"zQmcWyBPyedDzHFytTX6CAjjpvqQAyhzURziwiBKDKgqx6R\",\n      \"mime-type\": \"application/zip\",\n      \"filename\": \"cat.zip\",\n      \"byte_count\": 218187322,\n      \"lastmod_time\": \"2021-04-20 19:38:07Z\",\n      \"description\": \"Cute pictures of multiple cats\",\n      \"data\": {\n        \"links\": [\n          \"https://drive.google.com/kitty/cats.zip\",\n          \"s3://bucket/cats.zip\"\n        ]\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0641-linking-binary-objects-to-credentials/#matching","title":"Matching","text":"<p>Now that a link has been made between the attachment in the attachments decorator, it is possible to match the two together. When a credential is received and a value of an attribute starts with <code>hl:</code> it means that there is a linked attachment. To find the linked attachment to the credential attribute to following steps SHOULD be done:</p> <ol> <li>Extract the multihash from the credential attribute value</li> <li>Extract the first 64 characters of this multihash</li> <li>Loop over the <code>@id</code> tag of all the attachments in the attachment decorator</li> <li>Compare the value of the <code>@id</code> tag with the multihash</li> <li>If the <code>@id</code> tag matches with the multihash, then there is a link</li> <li>An integrity check can be done with the original, complete hashlink</li> </ol>"},{"location":"features/0641-linking-binary-objects-to-credentials/#reference","title":"Reference","text":"<p>When an issuer creates a value in a credential attribute with a prefix of <code>hl:</code>, but there is no attachment, a warning SHOULD be thrown.</p> <p>When DIDcomm V2 is implemented the attachment decorator will not contain the <code>sha256</code> tag anymore and it will be replaced by <code>hash</code> to allow for any algorithm. DIDcomm messaging Attachments</p>"},{"location":"features/0641-linking-binary-objects-to-credentials/#drawbacks","title":"Drawbacks","text":"<ul> <li>Hashlinks, multibase and multihash are not confirmed IETF RFCs yet</li> <li>Hosting some files at third party locations is not preferred</li> </ul>"},{"location":"features/0641-linking-binary-objects-to-credentials/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>The findings that large credentials are inconsistent and resource intensive are derived from issuing and verifying credentials of 100 kilobytes to 50 megabytes in Aries Framework JavaScript and Aries Cloudagent Python.</p> <p>The Identity Foundation is currently working on confidential storage, a way to allow access to your files based on DIDs. This storage would be a sleek fix for the last drawback.</p>"},{"location":"features/0641-linking-binary-objects-to-credentials/#prior-art","title":"Prior art","text":"<ul> <li>0017: Attachments discusses the attachments in DIDcomm messaging and formulates the attachment decorator.</li> <li>HIPE-0139: Image As Attribute Via Aries-0036 Issue-Credential Protocol has been written for the support of images in credentials. It points out that the attachment RFC and the issue credential RFC are separate and could drift apart.</li> <li>Linking and Exchanging Attachments with Verifiable Credentials describes the linking between the attachment the credential based on the <code>@id</code> tag.</li> </ul>"},{"location":"features/0641-linking-binary-objects-to-credentials/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>N/A</li> </ul>"},{"location":"features/0641-linking-binary-objects-to-credentials/#implementations","title":"Implementations","text":"Name / Link Implementation Notes"},{"location":"features/0646-bbs-credentials/","title":"0646: W3C Credential Exchange using BBS+ Signatures","text":"<ul> <li>Authors: Timo Glastra (Animo Solutions), Brent Zundel (Evernym)</li> <li>Status: ACCEPTED</li> <li>Since: 2021-04-28</li> <li>Status Note:</li> <li>Supersedes:</li> <li>Start Date: 2021-04-15</li> <li>Tags: feature</li> </ul>"},{"location":"features/0646-bbs-credentials/#summary","title":"Summary","text":"<p>This RFC describes how the Hyperledger Aries community should use BBS+ Signatures that conform with the Linked-Data Proofs Specification to perform exchange of credentials that comply with the W3C Verifiable Credential specification.</p> <p>Key ../../features include:</p> <ul> <li>zero-knowledge proofs (ZKPs),</li> <li>selective disclosure,</li> <li>private holder binding,</li> <li>signature blinding,</li> <li>compatibility with privacy preserving revocation.</li> </ul> <p>This RFC sets guidelines for their safe usage and describes privacy-enabling ../../features that should be incorporated.</p> <p>The usage of zero-knowledge proofs, selective disclosure and signature blinding are already supported using the specifications as described in this document. Support for private holder binding and privacy preserving revocation will be added in the future.</p>"},{"location":"features/0646-bbs-credentials/#motivation","title":"Motivation","text":"<p>Aries currently supports credential formats used by Indy (Anoncreds based on JSON) and Aries-Framework-Go. BBS+ signatures with JSON-LD Proofs provide a unified credential format that includes strong privacy protecting anti-correlation ../../features and wide interoperability with verifiable credentials outside the Aries ecosystem.</p>"},{"location":"features/0646-bbs-credentials/#tutorial","title":"Tutorial","text":""},{"location":"features/0646-bbs-credentials/#issuing-credentials","title":"Issuing Credentials","text":"<p>This section highlights the process of issuing credentials with BBS+ signatures. The first section (Creating BBS+ Credentials) highlights the process of creating credentials with BBS+ signatures, while the next section focusses on the the process of exchanging credentials with BBS+ signatures (Exchanging BBS+ Credentials).</p>"},{"location":"features/0646-bbs-credentials/#creating-bbs-credentials","title":"Creating BBS+ Credentials","text":"<p>The process to create verifiable credentials with BBS+ signatures is mostly covered by the VC Data Model and BBS+ LD-Proofs specifications. At the date of writing this RFC, the BBS+ LD-Proofs specification still has some unresolved issues. The issues are documented in the Issues with the BBS+ LD-Proofs specification section below.</p> <p>Aries implementations MUST use the BBS+ Signature Suite 2020 to create verifiable credentials with BBS+ signatures, identified by the <code>BbsBlsSignature2020</code> proof type.</p> <p>NOTE: Once the signature suites for bound signatures (private holder binding) are defined in the BBS+ LD-Proofs spec, the use of the <code>BbsBlsSignature2020</code> suite will be deprecated and superseded by the <code>BbsBlsBoundSignature2020</code> signature suite. See Private Holder Binding below for more information.</p>"},{"location":"features/0646-bbs-credentials/#identifiers-in-issued-credentials","title":"Identifiers in Issued Credentials","text":"<p>It is important to note that due to limitations of the underlying RDF canonicalization scheme, which is used by BBS+ LD-Proofs, issued credentials SHOULD NOT have any <code>id</code> properties, as the value of these properties will be revealed during the RDF canonicalization process, regardless of whether or not the holder chooses to disclose them.</p> <p>Credentials can make use of other identifier properties to create selectively disclosable identifiers. An example of this is the <code>identifier</code> property from the Citizenship Vocabulary</p>"},{"location":"features/0646-bbs-credentials/#private-holder-binding","title":"Private Holder Binding","text":"<p>A private holder binding allows the holder of a credential to authenticate itself without disclosing a correlating identifier (such as a DID) to the verifier. The current BBS+ LD-Proofs specification does not describe a mechanism yet to do private holder binding, but it is expected this will be done using two new signature suites: <code>BbsBlsBoundSignature2020</code> and <code>BbsBlsBoundSignatureProof2020</code>. Both suites feature a commitment to a private key held by the credential holder, for which they prove knowledge of when deriving proofs without ever directly revealing the private key, nor a unique identifier linked to the private key (e.g its complementary public pair).</p>"},{"location":"features/0646-bbs-credentials/#usage-of-credential-schema","title":"Usage of Credential Schema","text":"<p>The zero-knowledge proof section of the VC Data Model requires verifiable credentials used in zero-knowledge proof systems to include a credential definition using the <code>credentialSchema</code> property. Due to the nature of how BBS+ LD proofs work, it is NOT required to include the <code>credentialSchema</code> property. See Issue 726 in the VC Data Model.</p>"},{"location":"features/0646-bbs-credentials/#example-bbs-credential","title":"Example BBS+ Credential","text":"<p>Below is a complete example of a Verifiable Credential with BBS+ linked data proof.</p> <pre><code>{\n  \"@context\": [\n    \"https://www.w3.org/2018/credentials/v1\",\n    \"https://w3id.org/citizenship/v1\",\n    \"https://w3id.org/security/bbs/v1\" // &lt;-- BBS+ context\n  ],\n  \"id\": \"https://issuer.oidp.uscis.gov/credentials/83627465\",\n  \"type\": [\"VerifiableCredential\", \"PermanentResidentCard\"],\n  \"issuer\": \"did:example:489398593\",\n  \"identifier\": \"83627465\", // &lt;-- `identifier` property allows for seletively disclosable id property\n  \"name\": \"Permanent Resident Card\",\n  \"description\": \"Government of Example Permanent Resident Card.\",\n  \"issuanceDate\": \"2019-12-03T12:19:52Z\",\n  \"expirationDate\": \"2029-12-03T12:19:52Z\",\n  \"credentialSubject\": {\n    \"id\": \"did:example:b34ca6cd37bbf23\",\n    \"type\": [\"PermanentResident\", \"Person\"],\n    \"givenName\": \"JOHN\",\n    \"familyName\": \"SMITH\",\n    \"gender\": \"Male\",\n    \"image\": \"data:image/png;base64,iVBORw0KGgokJggg==\",\n    \"residentSince\": \"2015-01-01\",\n    \"lprCategory\": \"C09\",\n    \"lprNumber\": \"999-999-999\",\n    \"commuterClassification\": \"C1\",\n    \"birthCountry\": \"Bahamas\",\n    \"birthDate\": \"1958-07-17\"\n  },\n  \"proof\": {\n    \"type\": \"BbsBlsSignature2020\", // &lt;-- type must be `BbsBlsSignature2020`\n    \"created\": \"2020-10-16T23:59:31Z\",\n    \"proofPurpose\": \"assertionMethod\",\n    \"proofValue\": \"kAkloZSlK79ARnlx54tPqmQyy6G7/36xU/LZgrdVmCqqI9M0muKLxkaHNsgVDBBvYp85VT3uouLFSXPMr7Stjgq62+OCunba7bNdGfhM/FUsx9zpfRtw7jeE182CN1cZakOoSVsQz61c16zQikXM3w==\",\n    \"verificationMethod\": \"did:example:489398593#test\"\n  }\n}\n</code></pre>"},{"location":"features/0646-bbs-credentials/#exchanging-bbs-credentials","title":"Exchanging BBS+ Credentials","text":"<p>While the process of creating credentials with BBS+ signatures is defined in specifications outside of Aries, the process of exchanging credentials with BBS+ signatures is defined within Aries.</p> <p>Credentials with BBS+ signatures can be exchanged by following RFC 0453: Issue Credential Protocol 2.0. The Issue Credential 2.0 provides a registry of attachment formats that can be used for credential exchange. Currently, agents are expected to use the format as described in RFC 0593 (see below).</p> <p>NOTE: Once Credential Manifest v1.0 is released, RFC 0593 is expected to be deprecated and replaced by an updated version of RFC 0511: Credential-Manifest Attachment format</p>"},{"location":"features/0646-bbs-credentials/#0593-json-ld-credential-attachment-format","title":"0593: JSON-LD Credential Attachment format","text":"<p>RFC 0593: JSON-LD Credential Attachment format for requesting and issuing credentials defines a very simple, feature-poor attachment format for issuing JSON-LD credentials.</p> <p>The only requirement for exchanging BBS+ credentials, in addition to the requirements as specified in Creating BBS+ Credentials and RFC 0593, is the <code>options.proofType</code> in the <code>ld-proof-vc-detail</code> MUST be <code>BbsBlsSignature2020</code>.</p>"},{"location":"features/0646-bbs-credentials/#presenting-derived-credentials","title":"Presenting Derived Credentials","text":"<p>This section highlights the process of creating and presenting derived BBS+ credentials containing a BBS+ proof of knowledge.</p>"},{"location":"features/0646-bbs-credentials/#deriving-credentials","title":"Deriving Credentials","text":"<p>Deriving credentials should be done according to the BBS+ Signature Proof Suite 2020</p>"},{"location":"features/0646-bbs-credentials/#disclosing-required-properties","title":"Disclosing Required Properties","text":"<p>A verifiable presentation MUST NOT leak information that would enable the verifier to correlate the holder across multiple verifiable presentations.</p> <p>The above section from the VC Data Model may give the impression that it is allowed to omit required properties from a derived credential if this prevents correlation. However things the holder chooses to reveal are in a different category than things the holder MUST reveal. Derived credentials MUST disclose required properties, even if it can correlate them.</p> <p>E.g. a credential with <code>issuanceDate</code> of <code>2017-12-05T14:27:42Z</code> could create a correlating factor. However it is against the VC Data Model to not include the property. Take this into account when issuing credentials.</p>"},{"location":"features/0646-bbs-credentials/#transforming-blank-node-identifiers","title":"Transforming Blank Node Identifiers","text":"<p>This section will be removed once Issue 10 in the LD Proof BBS+ spec is resolved.</p> <p>For the verifier to be able to verify the signature of a derived credential it should be able to deterministically normalize the credentials statements for verification. RDF Dataset Canonicalization defines a way in which to allocate identifiers for blank nodes deterministically for normalization. However, the algorithm does not guarantee that the same blank node identifiers will be allocated in the event of modifications to the graph. Because selective disclosure of signed statements modifies the graph as presented to the verifier, the blank node identifiers must be transformed into actual node identifiers when presented to the verifier.</p> <p>The BBS+ LD-Proofs specification does not define a mechanism to transform blank node identifiers into actual identifiers. Current implementations use the mechanism as described in this Issue Comment. Some reference implementations:</p> <ul> <li>Aries Framework Go</li> <li>JSON-LD Signatures BBS</li> <li>Aries Cloud Agent Python</li> </ul>"},{"location":"features/0646-bbs-credentials/#verifying-presented-derived-credentials","title":"Verifying Presented Derived Credentials","text":""},{"location":"features/0646-bbs-credentials/#transforming-back-into-blank-node-identifiers","title":"Transforming Back into Blank Node Identifiers","text":"<p>This section will be removed once Issue 10 in the LD Proof BBS+ spec is resolved.</p> <p>Transforming the blank node identifiers into actual node identifiers in the derived credential means the verification data will be different from the verification data at issuance, invalidating the signature. Therefore the blank node identifier placeholders should be transformed back into blank node identifiers before verification.</p> <p>Same as with Transforming Blank Node Identifiers, current implementations use the mechanism as described in this Issue Comment. Some reference implementations:</p> <ul> <li>Aries Framework Go</li> <li>JSON-LD Signatures BBS</li> <li>Aries Cloud Agent Python</li> </ul>"},{"location":"features/0646-bbs-credentials/#exchanging-derived-credentials","title":"Exchanging Derived Credentials","text":"<p>The presentation of credentials with BBS+ signatures can be exchanged by following RFC 0454: Present Proof Protocol 2.0. The Present Proof Protocol 2.0 provides a registry of attachment formats that can be used for presentation exchange. Although agents can use any attachment format they want, agents are expected to use the format as described in RFC 0510 (see below).</p>"},{"location":"features/0646-bbs-credentials/#0510-presentation-exchange-attachment-format","title":"0510: Presentation-Exchange Attachment format","text":"<p>RFC 0510: Presentation-Exchange Attachment format for requesting and presenting proofs defines an attachment format based on the DIF Presentation Exchange specification.</p> <p>The following part of this section describes the requirements of exchanging derived credentials using the Presentation Exchange Attachment format, in addition to the requirements as specified above and in RFC 0510.</p> <p>The Presentation Exchange MUST include the <code>ldp_vp</code> Claim Format Designation. In turn the <code>proof_type</code> property of the <code>ldp_vp</code> claim format designation MUST include the <code>BbsBlsSignatureProof2020</code> proof type.</p>"},{"location":"features/0646-bbs-credentials/#example-bbs-derived-credential","title":"Example BBS+ Derived Credential","text":"<pre><code>{\n  \"@context\": [\n    \"https://www.w3.org/2018/credentials/v1\",\n    \"https://w3id.org/citizenship/v1\",\n    \"https://w3id.org/security/bbs/v1\" // BBS + Context\n  ],\n  \"id\": \"https://issuer.oidp.uscis.gov/credentials/83627465\",\n  \"type\": [\"PermanentResidentCard\", \"VerifiableCredential\"],\n  \"description\": \"Government of Example Permanent Resident Card.\",\n  \"identifier\": \"83627465\",\n  \"name\": \"Permanent Resident Card\",\n  \"credentialSubject\": {\n    \"id\": \"did:example:b34ca6cd37bbf23\",\n    \"type\": [\"Person\", \"PermanentResident\"],\n    \"familyName\": \"SMITH\",\n    \"gender\": \"Male\",\n    \"givenName\": \"JOHN\"\n  },\n  \"expirationDate\": \"2029-12-03T12:19:52Z\",\n  \"issuanceDate\": \"2019-12-03T12:19:52Z\",\n  \"issuer\": \"did:example:489398593\",\n  \"proof\": {\n    \"type\": \"BbsBlsSignatureProof2020\", // &lt;-- type must be `BbsBlsSignatureProof2020`\n    \"nonce\": \"wrmPiSRm+iBqnGBXz+/37LLYRZWirGgIORKHIkrgWVnHtb4fDe/4ZPZaZ+/RwGVJYYY=\",\n    \"proofValue\": \"ABkB/wbvt6213E9eJ+aRGbdG1IIQtx+IdAXALLNg2a5ENSGOIBxRGSoArKXwD/diieDWG6+0q8CWh7CViUqOOdEhYp/DonzmjoWbWECalE6x/qtyBeE7W9TJTXyK/yW6JKSKPz2ht4J0XLV84DZrxMF4HMrY7rFHvdE4xV7ULeC9vNmAmwYAqJfNwY94FG2erg2K2cg0AAAAdLfutjMuBO0JnrlRW6O6TheATv0xZZHP9kf1AYqPaxsYg0bq2XYzkp+tzMBq1rH3tgAAAAIDTzuPazvFHijdzuAgYg+Sg0ziF+Gw5Bz8r2cuvuSg1yKWqW1dM5GhGn6SZUpczTXuZuKGlo4cZrwbIg9wf4lBs3kQwWULRtQUXki9izmznt4Go98X/ElOguLLum4S78Gehe1ql6CXD1zS5PiDXjDzAAAACWz/sbigWpPmUqNA8YUczOuzBUvzmkpjVyL9aqf1e7rSZmN8CNa6dTGOzgKYgDGoIbSQR8EN8Ld7kpTIAdi4YvNZwEYlda/BR6oSrFCquafz7s/jeXyOYMsiVC53Zls9KEg64tG7n90XuZOyMk9RAdcxYRGligbFuG2Ap+rQ+rrELJaW7DWwFEI6cRnitZo6aS0hHmiOKKtJyA7KFbx27nBGd2y3JCvgYO6VUROQ//t3F4aRVI1U53e5N3MU+lt9GmFeL+Kv+2zV1WssScO0ZImDGDOvjDs1shnNSjIJ0RBNAo2YzhFKh3ExWd9WbiZ2/USSyomaSK4EzdTDqi2JCGdqS7IpooKSX/1Dp4K+d8HhPLGNLX4yfMoG9SnRfRQZZQ==\",\n    \"verificationMethod\": \"did:example:489398593#test\",\n    \"proofPurpose\": \"assertionMethod\",\n    \"created\": \"2020-10-16T23:59:31Z\"\n  }\n}\n</code></pre>"},{"location":"features/0646-bbs-credentials/#privacy-considerations","title":"Privacy Considerations","text":"<p>Private Holder Binding is an evolution of CL Signatures Linked Secrets.</p> <ul> <li><code>id</code> properties are always disclosed in derived credentials due to how JSON-LD works.</li> <li>Required properties from the VC Data Model MUST be disclosed in derived credentials.</li> <li>BBS+ credentials SHOULD not be used in conjunction with non-ZKP signature as this removes the privacy ../../features of BBS.</li> </ul>"},{"location":"features/0646-bbs-credentials/#reference","title":"Reference","text":""},{"location":"features/0646-bbs-credentials/#interoperability-with-existing-credential-formats","title":"Interoperability with Existing Credential Formats","text":"<p>We expect that many issuers will choose to shift exclusively to BBS+ credentials for the benefits described here. Accessing these benefits will require reissuing credentials that were previously in a different format.</p> <p>An issuer can issue duplicate credentials with both signature formats.</p> <p>A holder can hold both types of credentials. The holder wallet could display the two credentials as a single entry in their credential list if the data is the same (it\u2019s \u201cenhanced\u201d with both credential formats).</p> <p>A verifier can send a proof request for the formats that they choose to support.</p> <ul> <li>The holder wallet can provide the credential that fulfills that proof restriction. This allows old credentials to continue being used without being reissued.</li> <li>The verifier may accept credentials of multiple formats.</li> </ul>"},{"location":"features/0646-bbs-credentials/#issues-with-the-bbs-ld-proofs-specification","title":"Issues with the BBS+ LD-Proofs specification","text":"<ul> <li><code>requiredRevealStatements</code> will be removed (Issue 50)</li> <li><code>proofValue</code> and <code>nonce</code> must be base64 encoded (Issue 51)</li> <li><code>signature</code> must be updated to <code>proofValue</code> for the <code>BbsBlsSignature2020</code> suite (Issue 52)</li> <li>The application of blank node identifiers (Issue 10)</li> <li>Private holder binding (Issue 37)</li> </ul>"},{"location":"features/0646-bbs-credentials/#drawbacks","title":"Drawbacks","text":"<p>Existing implementations of BBS+ Signatures do not support ZKP proof predicates, but it is theoretically possible to support numeric date predicates. ZKP proof predicates are considered a key feature of CL signatures, and a migration to BBS+ LD-Proofs will lose this capability. The Indy maintainers consider this a reasonable trade-off to get the other benefits of BBS+ LD-Proofs. A mechanism to support predicates can hopefully be added in future work.</p> <p>As mentioned in the Private Holder Binding section, the BBS+ LD-Proofs specification does not define a mechanism for private holder binding yet. This means implementing this RFC does not provide all privacy-enabling ../../features that should be incorporated until the <code>BbsBlsBoundSignature2020</code> and <code>BbsBlsBoundSignatureProof2020</code> signature suites are formally defined.</p>"},{"location":"features/0646-bbs-credentials/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>BBS+ LD-Proofs is a reasonable evolution of CL Signatures, as it supports most of the same ../../features (with the exception of ZKP Proof Predicates), while producing smaller credentials that require less computation resources to validate (a key requirement for mobile use cases).</p> <p>BBS+ LD-Proofs are receiving broad support across the verifiable credentials implementation community, so supporting this signature format will be strategic for interoperability and allow Aries to promote the privacy preserving capabilities such as zero knowledge proofs and private holder binding.</p>"},{"location":"features/0646-bbs-credentials/#prior-art","title":"Prior art","text":"<p>Indy Anoncreds used CL Signatures to meet many of the use cases currently envisioned for BBS+ LD-Proofs.</p> <p>BBS+ Signatures were originally proposed by Boneh, Boyen, and Shacham in 2004.</p> <p>The approach was improved by Au, Susilo, and Mu in 2006.</p> <p>It was then further refined by Camenisch, Drijvers, and Lehmann in section 4.3 of this paper from 2016.</p> <p>In 2019, Evernym and Sovrin proposed BBS+ Signatures as the foundation for Indy Anoncreds 2.0, which in conjunction with Rich Schemas addressed a similar set of goals and capabilities as those addressed here, but were ultimately too heavy a solution.</p> <p>In 2020, Mattr provided a draft specification for BBS+ LD-Proofs that comply with the Linked Data proof specification in the W3C Credentials Community Group. The authors acknowledged that their approach did not support two key Anoncreds ../../features: proof predicates and link secrets.</p> <p>Aries RFC 593 describes the JSON-LD credential format.</p>"},{"location":"features/0646-bbs-credentials/#unresolved-questions","title":"Unresolved questions","text":"<p>See the above note in the Drawbacks Section about ZKP predicates.</p>"},{"location":"features/0646-bbs-credentials/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0685-pickup-v2/","title":"0685: Pickup Protocol 2.0","text":"<ul> <li>Authors: Sam Curren, James Ebert</li> <li>Status: ACCEPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Initial version</li> <li>Start Date: 2020-12-22</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0685-pickup-v2/#summary","title":"Summary","text":"<p>A protocol to facilitate an agent picking up messages held at a mediator.</p>"},{"location":"features/0685-pickup-v2/#motivation","title":"Motivation","text":"<p>Messages can be picked up simply by sending a message to the Mediator with a <code>return_route</code> decorator specified. This mechanism is implicit, and lacks some desired behavior made possible by more explicit messages.</p> <p>This protocol is the explicit companion to the implicit method of picking up messages.</p>"},{"location":"features/0685-pickup-v2/#tutorial","title":"Tutorial","text":""},{"location":"features/0685-pickup-v2/#roles","title":"Roles","text":"<p>Mediator - The agent that has messages waiting for pickup by the Recipient.</p> <p>Recipient - The agent who is picking up messages.</p>"},{"location":"features/0685-pickup-v2/#flow","title":"Flow","text":"<p>The <code>status-request</code> message is sent by the Recipient to the Mediator to query how many messages are pending.</p> <p>The <code>status</code> message is the response to <code>status-request</code> to communicate the state of the message queue.</p> <p>The <code>delivery-request</code> message is sent by the Recipient to request delivery of pending messages.</p> <p>The <code>message-received</code> message is sent by the Recipient to confirm receipt of delivered messages,  prompting the Mediator to clear messages from the queue.</p> <p>The <code>live-delivery-change</code> message is used to set the state of <code>live_delivery</code>. </p> <ul> <li>When Live Mode is enabled, messages that arrive when an existing connection exists are delivered over the connection immediately,  rather than being pushed to the queue. See Live Mode for more details.</li> </ul>"},{"location":"features/0685-pickup-v2/#reference","title":"Reference","text":"<p>Each message sent MUST use the <code>~transport</code> decorator as follows, which has been adopted from RFC 0092 transport return route protocol. This has been omitted from the examples for brevity.</p> <pre><code>\"~transport\": {\n    \"return_route\": \"all\"\n}\n</code></pre>"},{"location":"features/0685-pickup-v2/#message-types","title":"Message Types","text":""},{"location":"features/0685-pickup-v2/#status-request","title":"Status Request","text":"<p>Sent by the Recipient to the Mediator to request a <code>status</code> message.</p>"},{"location":"features/0685-pickup-v2/#example","title":"Example:","text":"<pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"https://didcomm.org/messagepickup/2.0/status-request\",\n    \"recipient_key\": \"&lt;key for messages&gt;\"\n}\n</code></pre> <p><code>recipient_key</code> is optional. When specified, the Mediator MUST only return status related to that recipient key. This allows the Recipient to discover if any messages are in the queue that were sent to a specific key. You can find more details about <code>recipient_key</code> and how it's managed in 0211-route-coordination.</p>"},{"location":"features/0685-pickup-v2/#status","title":"Status","text":"<p>Status details about waiting messages.</p>"},{"location":"features/0685-pickup-v2/#example_1","title":"Example:","text":"<pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"https://didcomm.org/messagepickup/2.0/status\",\n    \"recipient_key\": \"&lt;key for messages&gt;\",\n    \"message_count\": 7,\n    \"longest_waited_seconds\": 3600,\n    \"newest_received_time\": \"2019-05-01 12:00:00Z\",\n    \"oldest_received_time\": \"2019-05-01 12:00:01Z\",\n    \"total_bytes\": 8096,\n    \"live_delivery\": false\n}\n</code></pre> <p><code>message_count</code> is the only REQUIRED attribute. The others MAY be present if offered by the Mediator.</p> <p><code>longest_waited_seconds</code> is in seconds, and is the longest delay of any message in the queue.</p> <p><code>total_bytes</code> represents the total size of all messages.</p> <p>If a <code>recipient_key</code> was specified in the <code>status-request</code> message, the matching value MUST be specified  in the <code>recipient_key</code> attribute of the status message.</p> <p><code>live_delivery</code> state is also indicated in the status message. </p> <p>Note: due to the potential for confusing what the actual state of the message queue is, a status message MUST NOT be put on the pending message queue and MUST only be sent when the Recipient is actively connected (HTTP request awaiting response, WebSocket, etc.).</p>"},{"location":"features/0685-pickup-v2/#delivery-request","title":"Delivery Request","text":"<p>A request from the Recipient to the Mediator to have pending messages delivered. </p>"},{"location":"features/0685-pickup-v2/#examples","title":"Examples:","text":"<pre><code>{\n    \"@id\": \"123456781\",\n    \"@type\": \"https://didcomm.org/messagepickup/2.0/delivery-request\",\n    \"limit\": 10,\n    \"recipient_key\": \"&lt;key for messages&gt;\"\n}\n</code></pre> <pre><code>{\n    \"@type\": \"https://didcomm.org/messagepickup/2.0/delivery-request\",\n    \"limit\": 1\n}\n</code></pre> <p><code>limit</code> is a REQUIRED attribute, and after receipt of this message, the Mediator SHOULD deliver up to the <code>limit</code> indicated. </p> <p><code>recipient_key</code> is optional. When specified, the Mediator MUST only return messages sent to that recipient key.</p> <p>If no messages are available to be sent, a <code>status</code> message MUST be sent immediately.</p> <p>Delivered messages MUST NOT be deleted until delivery is acknowledged by a <code>messages-received</code> message.</p>"},{"location":"features/0685-pickup-v2/#message-delivery","title":"Message Delivery","text":"<p>Messages delivered from the queue must be delivered in a batch <code>delivery</code> message as attachments. The ID of each attachment is used to confirm receipt. The ID is an opaque value, and the Recipient should not infer anything from the value.</p> <p>The ONLY valid type of attachment for this message is a DIDComm Message in encrypted form.</p> <p>The <code>recipient_key</code> attribute is only included when responding to a <code>delivery-request</code> message that indicates a <code>recipient_key</code>.</p> <pre><code>{\n    \"@id\": \"123456781\",\n    \"~thread\": {\n        \"thid\": \"&lt;message id of delivery-request message&gt;\"\n      },\n    \"@type\": \"https://didcomm.org/messagepickup/2.0/delivery\",\n    \"recipient_key\": \"&lt;key for messages&gt;\",\n    \"~attach\": [{\n        \"@id\": \"&lt;messageid&gt;\",\n        \"data\": {\n            \"base64\": \"\"\n        }\n    }]\n}\n</code></pre> <p>This method of delivery does incur an encoding cost, but is much simpler to implement and a more robust interaction.</p>"},{"location":"features/0685-pickup-v2/#messages-received","title":"Messages Received","text":"<p>After receiving messages, the Recipient sends an ack message indiciating  which messages are safe to clear from the queue.</p>"},{"location":"features/0685-pickup-v2/#example_2","title":"Example:","text":"<pre><code>{\n    \"@type\": \"https://didcomm.org/messagepickup/2.0/messages-received\",\n    \"message_id_list\": [\"123\",\"456\"]\n}\n</code></pre> <p><code>message_id_list</code> is a list of ids of each message received. The id of each message is present in the attachment descriptor of each attached message of a <code>delivery</code> message.</p> <p>Upon receipt of this message, the Mediator knows which messages have been received, and can remove them from the collection of queued messages with confidence. The mediator SHOULD send an updated <code>status</code> message reflecting the changes to the queue.</p>"},{"location":"features/0685-pickup-v2/#multiple-recipients","title":"Multiple Recipients","text":"<p>If a message arrives at a Mediator addressed to multiple Recipients, the message MUST be queued for each Recipient independently. If one of the addressed Recipients retrieves a message and indicates it has been received, that message MUST still be held and then removed by the other addressed Recipients.</p>"},{"location":"features/0685-pickup-v2/#live-mode","title":"Live Mode","text":"<p>Live mode is the practice of delivering newly arriving messages directly to a connected Recipient. It is disabled by default and only activated by the Recipient. Messages that arrive when Live Mode is off MUST be stored in the queue for retrieval as described above. If Live Mode is active, and the connection is broken, a new inbound connection starts with Live Mode disabled.</p> <p>Messages already in the queue are not affected by Live Mode - they must still be requested with <code>delivery-request</code> messages.</p> <p>Live mode MUST only be enabled when a persistent transport is used, such as WebSockets.</p> <p>Recipients have three modes of possible operation for message delivery with various abilities and level of development complexity:</p> <ol> <li>Never activate live mode. Poll for new messages with a <code>status_request</code> message, and retrieve them when available.</li> <li>Retrieve all messages from queue, and then activate Live Mode. This simplifies message processing logic in the Recipient.</li> <li>Activate Live Mode immediately upon connecting to the Mediator. Retrieve messages from the queue as possible. When receiving a message delivered live, the queue may be queried for any waiting messages delivered to the same key for processing.</li> </ol>"},{"location":"features/0685-pickup-v2/#live-mode-change","title":"Live Mode Change","text":"<p>Live Mode is changed with a <code>live-delivery-change</code> message.</p>"},{"location":"features/0685-pickup-v2/#example_3","title":"Example:","text":"<pre><code>{\n    \"@type\": \"https://didcomm.org/messagepickup/2.0/live-delivery-change\",\n    \"live_delivery\": true\n}\n</code></pre> <p>Upon receiving the <code>live_delivery_change</code> message, the Mediator MUST respond with a <code>status</code> message.</p> <p>If sent with <code>live_delivery</code> set to <code>true</code> on a connection incapable of live delivery, a <code>problem_report</code> SHOULD be sent as follows:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/notification/1.0/problem-report\",\n  \"~thread\": {\n    \"pthid\": \"&lt;message id of offending live_delivery_change&gt;\"\n  },\n  \"description\": \"Connection does not support Live Delivery\"\n}\n</code></pre>"},{"location":"features/0685-pickup-v2/#prior-art","title":"Prior art","text":"<p>Version 1.0 of this protocol served as the main inspiration for this version. Version 1.0 suffered from not being very explicit, and an incomplete model of message delivery signaling.</p>"},{"location":"features/0685-pickup-v2/#alternatives","title":"Alternatives","text":"<ul> <li>An alternative to deriving a message ID is to wrap each message in a delivery wrapper. This would enable the mediator to include a mediator managed id and metadata along with the message itself, but carries the downside of double encrypting messages and extra processing.</li> </ul>"},{"location":"features/0685-pickup-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0693-credential-representation/","title":"0693: Cross-Platform Credential Representation","text":"<ul> <li>Authors: Horacio Nunez (Kiva Protocol)</li> <li>Status: PROPOSED</li> <li>Since: 2021-07-06</li> <li>Status Note:</li> <li>Supersedes:</li> <li>Start Date: 2021-02-10</li> <li>Tags: feature</li> </ul>"},{"location":"features/0693-credential-representation/#summary","title":"Summary","text":"<p>Aries Agent developers currently build end user products without a standard method of rendering credentials. This RFC proposes how the Aries community can reuse available open technologies to build such a rendering method.</p> <p>Key results include: - Feasibility of cross platform rendering. - Enable branding of credentials.</p> <p>This RFC also enumerate the specific challenges that by using this method could be tackled next.</p>"},{"location":"features/0693-credential-representation/#motivation","title":"Motivation","text":"<p>The human computer interaction between agents and their users will always gravitate around credentials. This interaction is more useful for users when their representation resembles that of their conventional  (physical) counterparts.</p> <p>Achieving effortless semiotic parity with analog credentials doesn't come easy or cheap.  In fact, when reviewing new Aries-base projects, is always the case that the rendering of  credentials with any form of branding is a demanding portion of the roadmap.</p> <p>Since the work required here is never declarative the work never stops feeling sysyphean. Indeed, the cost of writing code of representing a credential remains constant over time, no matter how many times we do it.</p> <p>Imagine if we achieve declarative while empowering branding.</p>"},{"location":"features/0693-credential-representation/#entering-svg","title":"Entering SVG","text":"<p>The solution we propose is to adopt SVG as the default format to describe how to represent SSI credentials, and to  introduce a convention to ensure that credentials values could be embedded in the final user interface.  The following images illustrates how this can work:</p> <p></p>"},{"location":"features/0693-credential-representation/#svg-credential-values","title":"SVG + Credential Values","text":"<p>We propose a notation of the form <code>{{credential.values.[AttributeName]}}</code> and <code>{{credential.names.[AttributeName]}}</code>. This way both values and attributes names can be used in branding activities.</p>"},{"location":"features/0693-credential-representation/#cross-platform","title":"Cross Platform","text":"<p>Since SVG is a web standard based on XML there isn't a shortage of existing tools to power brand and engineering needs  right away. Indeed, any implementation will be powered by native SVG renderer and XML parser.</p>"},{"location":"features/0693-credential-representation/#future-work","title":"Future work","text":"<ul> <li>(RFC) A default credential representation to serves as community baseline</li> <li>(RFC) How to communicate the designated credential representation among agents.</li> <li>(RFC) Expand metadata available to include Revocation status.</li> <li>(Dev Tool) Standalone desktop tool to help design/brand a credential stored in an agent.</li> </ul>"},{"location":"features/0699-push-notifications-apns/","title":"Aries RFC 0699: Push Notifications apns Protocol 1.0","text":"<ul> <li>Authors: Timo Glastra (Animo Solutions) &amp; Berend Sliedrecht (Animo Solutions)</li> <li>Status: PROPOSED</li> <li>Since: 2021-10-07</li> <li>Status Note: Initial version</li> <li>Start Date: 2021-05-05</li> <li>Tags: feature, protocol</li> </ul> <p>Note: This protocol is currently written to support native push notifications for iOS via Apple Push Notification Service. For the implementation for Android (using fcm), please refer to 0734: Push Notifications fcm</p>"},{"location":"features/0699-push-notifications-apns/#summary","title":"Summary","text":"<p>A protocol to coordinate a push notification configuration between two agents.</p>"},{"location":"features/0699-push-notifications-apns/#motivation","title":"Motivation","text":"<p>This protocol would give an agent enough information to send push notifications about specific events to an iOS device. This would be of great benefit for mobile wallets, as a holder can be notified when new messages are pending at the mediator. Mobile applications, such as wallets, are often killed and can not receive messages from the mediator anymore. Push notifications would resolve this problem.</p>"},{"location":"features/0699-push-notifications-apns/#tutorial","title":"Tutorial","text":""},{"location":"features/0699-push-notifications-apns/#name-and-version","title":"Name and Version","text":"<p>URI: <code>https://didcomm.org/push-notifications-apns/1.0</code></p> <p>Protocol Identifier: <code>push-notifications-apns</code></p> <p>Version: <code>1.0</code></p> <p>Since apns only supports iOS, no <code>-ios</code> or <code>-android</code> is required as it is implicit.</p>"},{"location":"features/0699-push-notifications-apns/#key-concepts","title":"Key Concepts","text":"<p>When an agent would like to receive push notifications at record event changes, e.g. incoming credential offer, incoming connection request, etc., the agent could initiate the protocol by sending a message to the other agent.</p> <p>This protocol only defines how an agent would get the token which is necessary for push notifications.</p> <p>Each platform is has its own protocol so that we can easily use 0031: Discover Features 1.0 and 0557: Discover Features 2.X to see which specific services are supported by the other agent.</p>"},{"location":"features/0699-push-notifications-apns/#roles","title":"Roles","text":"<p>notification-sender</p> <p>notification-receiver</p> <p>The notification-sender is an agent who will send the notification-receiver notifications. The notification-receiver can get and set their push notification configuration at the notification-sender.</p>"},{"location":"features/0699-push-notifications-apns/#services","title":"Services","text":"<p>This RFC focusses on configuring the data necessary for pushing notifications to iOS, via apns.</p> <p>In order to implement this protocol, the set-device-info and get-device-info messages MUST be implemented by the notification-sender and device-info message MUST be implemented by the notification-receiver.</p>"},{"location":"features/0699-push-notifications-apns/#supported-services","title":"Supported Services","text":"<p>The protocol currently supports the following push notification services</p> <ul> <li>apns for iOS devices</li> </ul>"},{"location":"features/0699-push-notifications-apns/#messages","title":"Messages","text":"<p>When a notification-receiver wants to receive push notifications from the notification-sender, the notification-receiver has to send the following message:</p>"},{"location":"features/0699-push-notifications-apns/#set-device-info","title":"Set Device Info","text":"<p>Message to set the device info using the native iOS device token for push notifications.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-apns/1.0/set-device-info\",\n  \"@id\": \"&lt;UUID&gt;\",\n  \"device_token\": \"&lt;DEVICE_TOKEN&gt;\"\n}\n</code></pre> <p>Description of the fields:</p> <ul> <li><code>device_token</code> -- The token that is required by the notification provider (string, null)</li> </ul> <p>It is important to note that the set device info message can be used to set, update and remove the device info. To set, and update, these values the normal messages as stated above can be used. To remove yourself from receiving push notifications, you can send the same message where all values MUST be <code>null</code>. If either value is <code>null</code> a <code>problem-report</code> MAY be sent back with <code>missing-value</code>.</p>"},{"location":"features/0699-push-notifications-apns/#get-device-info","title":"Get Device Info","text":"<p>When a notification-receiver wants to get their push-notification configuration, they can send the following message:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-apns/1.0/get-device-info\",\n  \"@id\": \"&lt;UUID&gt;\"\n}\n</code></pre>"},{"location":"features/0699-push-notifications-apns/#device-info","title":"Device Info","text":"<p>Response to the get device info:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-apns/1.0/device-info\",\n  \"device_token\": \"&lt;DEVICE_TOKEN&gt;\",\n  \"~thread\": {\n    \"thid\": \"&lt;GET_DEVICE_INFO_UUID&gt;\"\n  }\n}\n</code></pre> <p>This message can be used by the notification-receiver to receive their device info, e.g. <code>device_token</code>. If the notification-sender does not have this field for that connection, a <code>problem-report</code> MAY be used as a response with <code>not-registered-for-push-notifications</code>.</p>"},{"location":"features/0699-push-notifications-apns/#adopted-messages","title":"Adopted messages","text":"<p>In addition, the <code>ack</code> message is adopted into the protocol for confirmation by the notification-sender. The ack message SHOULD be sent in response to any of the set-device-info messages.</p>"},{"location":"features/0699-push-notifications-apns/#sending-push-notifications","title":"Sending Push Notifications","text":"<p>When an agent wants to send a push notification to another agent, the payload of the push notifications MUST include the <code>@type</code> property, and COULD include the <code>message_tag</code> property, to indicate the message is sent by the notification-sender. Guidelines on notification messages are not defined.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-apns\",\n  \"message_tag\": \"&lt;MESSAGE_TAG&gt;\",\n  \"message_id\": \"&lt;MESSAGE_ID&gt;\",\n  ...\n}\n</code></pre> <p>Description of the fields:</p> <ul> <li><code>@type</code> -- Indicator of what kind of notification it is. (This could help the notification-receiver with parsing if a notification comes from another agent, for example)</li> <li><code>message_tag</code> -- Optional field to connect the push notification to a DIDcomm message. As defined in 0334: jwe-envelope or 0019: encryption-envelope.</li> <li><code>message_id</code> -- Optional field to pickup the message from the mediator that the notification was linked to. As defined in 0685: Pickup Protocol 2.0.</li> </ul>"},{"location":"features/0699-push-notifications-apns/#drawbacks","title":"Drawbacks","text":"<p>Each service requires a considerable amount of domain knowledge. The RFC can be extended with new services over time.</p> <p>The <code>@type</code> property in the push notification payload currently doesn't indicate which agent the push notification came from. In e.g. the instance of using multiple mediators, this means the notification-receiver does not know which mediator to retrieve the message from.</p>"},{"location":"features/0699-push-notifications-apns/#prior-art","title":"Prior art","text":"<ul> <li>This RFC is based on the implementation of the <code>AddDeviceInfoMessage</code> in Aries Framework .NET</li> </ul>"},{"location":"features/0699-push-notifications-apns/#unresolved-questions","title":"Unresolved questions","text":"<p>None</p>"},{"location":"features/0699-push-notifications-apns/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0721-revocation-notification-v2/","title":"Aries RFC 0721: Revocation Notification 2.0","text":"<ul> <li>Authors: Keith Smith, Daniel Bluhm, James Ebert</li> <li>Status: ACCEPTED</li> <li>Since: 2024-05-01</li> <li>Status Note: Updates the credential identifiers format after discussions while implementing RFC 0183 Revocation Notification</li> <li>Supersedes: RFC 0183 Revocation Notification</li> <li>Start Date: 2021-11-01</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0721-revocation-notification-v2/#summary","title":"Summary","text":"<p>This RFC defines the message format which an issuer uses to notify a holder that a previously issued credential has been revoked.</p>"},{"location":"features/0721-revocation-notification-v2/#change-log","title":"Change Log","text":"<ul> <li>20240320: Clarification removing references to retired <code>~please_ack</code> decorator and RFC.</li> </ul>"},{"location":"features/0721-revocation-notification-v2/#motivation","title":"Motivation","text":"<p>We need a standard protocol for an issuer to notify a holder that a previously issued credential has been revoked or unrevoked.</p> <p>For example, suppose a passport agency revokes Alice's passport. The passport agency (an issuer) may want to notify Alice (a holder) that her passport has been revoked so that she knows that she will be unable to use her passport to travel.</p>"},{"location":"features/0721-revocation-notification-v2/#tutorial","title":"Tutorial","text":"<p>The Revocation Notification protocol is a very simple protocol consisting of two messages:</p> <ul> <li>Revoke - issuer to holder</li> <li>Unrevoke - issuer to holder</li> </ul> <p>This simple protocol allows an issuer to choose to notify a holder that a previously issued credential has been revoked or unrevoked.</p> <p>It is the issuer's prerogative whether or not to notify the holder that a credential has been (un)revoked.  It is not a security risk if the issuer does not notify the holder that the credential has been (un)revoked, nor if the message is lost.  The holder will still be unable to use a revoked credential without this notification.</p>"},{"location":"features/0721-revocation-notification-v2/#roles","title":"Roles","text":"<p>There are two parties involved in a Revocation Notification: <code>issuer</code> and <code>holder</code>. The <code>issuer</code> sends the <code>revoke</code> or <code>unrevoke</code> message to the <code>holder</code>.</p>"},{"location":"features/0721-revocation-notification-v2/#messages","title":"Messages","text":""},{"location":"features/0721-revocation-notification-v2/#revoke","title":"Revoke","text":"<p>The <code>revoke</code> message sent by the <code>issuer</code> to the <code>holder</code>. The holder should verify that the <code>revoke</code> message came from the connection that was originally used to issue the credential.</p> <p>Message format:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/revocation_notification/2.1/revoke\",\n  \"@id\": \"&lt;uuid-revocation-notification&gt;\",\n  \"revocation_format\": \"&lt;revocation_format&gt;\",\n  \"credential_id\": \"&lt;credential_id&gt;\",\n  \"comment\": \"Some comment\"\n}\n</code></pre> <p>Description of fields:</p> <ul> <li> <p><code>revocation_format</code> (required) -- the format of the credential revocation. Accepted values for the revocation format are provided in the \"Revocation Credential Identification Formats\" section immediately below.</p> </li> <li> <p><code>credential_id</code> (required) -- the individual credential identifier of a credential issued using the issue-credential-v2 protocol that has been revoked by the issuer. Accepted values for the credential id format are provided in the \"Revocation Credential Identification Formats\" section immediately below.</p> </li> <li> <p><code>comment</code> (optional) -- a field that provides some human readable information about the revocation notification.  This is typically the reason for the revocation as deemed appropriate by the issuer.</p> </li> </ul>"},{"location":"features/0721-revocation-notification-v2/#unrevoke","title":"Unrevoke","text":"<p>The <code>unrevoke</code> message sent by the <code>issuer</code> to the <code>holder</code>. The holder should verify that the <code>unrevoke</code> message came from the connection that was originally used to issue the credential.</p> <p>Message format:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/revocation_notification/2.1/unrevoke\",\n  \"@id\": \"&lt;uuid-revocation-notification&gt;\",\n  \"revocation_format\": \"&lt;revocation_format&gt;\",\n  \"credential_id\": \"&lt;credential_id&gt;\",\n  \"comment\": \"Some comment\"\n}\n</code></pre> <p>Description of fields:</p> <ul> <li> <p><code>revocation_format</code> (required) -- the format of the credential revocation. Accepted values for the revocation format are provided in the \"Revocation Credential Identification Formats\" section immediately below.</p> </li> <li> <p><code>credential_id</code> (required) -- the individual credential identifier of a credential issued using the issue-credential-v2 protocol that has been revoked by the issuer. Accepted values for the credential id format are provided in the \"Revocation Credential Identification Formats\" section immediately below.</p> </li> <li> <p><code>comment</code> (optional) -- a field that provides some human readable information about the revocation notification.  This is typically the reason for the revocation as deemed appropriate by the issuer.</p> </li> </ul>"},{"location":"features/0721-revocation-notification-v2/#revocation-credential-identification-formats","title":"Revocation Credential Identification Formats","text":"<p>In order to support multiple credential revocation formats, the following dictates the format of revocation formats and their credential ids. As additional credential revocation formats are determined their credential id formats should be added.</p> Revocation Format Credential Identifier Format Example <code>indy-anoncreds</code> <code>&lt;revocation-registry-id&gt;::&lt;credential-revocation-id&gt;</code> <code>AsB27X6KRrJFsqZ3unNAH6:4:AsB27X6KRrJFsqZ3unNAH6:3:cl:48187:default:CL_ACCUM:3b24a9b0-a979-41e0-9964-2292f2b1b7e9::1</code> <code>anoncreds</code> <code>&lt;revocation-registry-id&gt;::&lt;credential-revocation-id&gt;</code> <code>did:indy:sovrin:5nDyJVP1NrcPAttP3xwMB9/anoncreds/v0/REV_REG_DEF/56495/npdb/TAG1::1</code>"},{"location":"features/0721-revocation-notification-v2/#reference","title":"Reference","text":"<ul> <li>See the issue-credential-v2 protocol.</li> <li>See the Please ACK Decorator RFC.</li> </ul>"},{"location":"features/0721-revocation-notification-v2/#drawbacks","title":"Drawbacks","text":"<p>If we later added support for more general event subscription and notification message flows, this would be redundant.</p>"},{"location":"features/0721-revocation-notification-v2/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>Why is this design the best in the space of possible designs?  It is simple.</li> <li>What other designs have been considered and what is the rationale for not choosing them?  A more general event subscription and notification mechanism was considered but chose to keep this simple for the same reasons that the basic message was kept simple.</li> <li>What is the impact of not doing this?  There is no standard way of sending a revocation notification which is a common scenario.</li> </ul>"},{"location":"features/0721-revocation-notification-v2/#prior-art","title":"Prior art","text":""},{"location":"features/0721-revocation-notification-v2/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"features/0721-revocation-notification-v2/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0728-device-binding-attachments/","title":"Aries RFC 0728 : Device Binding Attachments","text":"<ul> <li>Authors: Paul Bastian, Sebastian Bickerle</li> <li>Status: PROPOSED</li> <li>Since: 2022-04-07</li> <li>Status Note: This is an initial draft</li> <li>Start Date: 2022-01-01</li> <li>Tags: feature</li> </ul>"},{"location":"features/0728-device-binding-attachments/#summary","title":"Summary","text":"<p>Extends existing present-proof protocols to allow proofing the control of a hardware bound key embedded within a verfiable credential.</p>"},{"location":"features/0728-device-binding-attachments/#motivation","title":"Motivation","text":"<p>To enable use-cases which require a high level of assurance a verifier must reach a high degree of confidence that a verifiable credential (VC) can only be used by the person it was issued for. One way to enforce this requirement is that the issuer additionally binds the VC to a hardware bound public key and therefore binding the credential to the device, as discussed in the DIF Wallet Security WG. The issaunce process, including the attestation of the wallet and the hardware bound key is off-scope for this Aries RFC. A valid presentation of the VC then requires an additional challenge which proofs that the presenter is in control of the corresponding private key. Since the proof of control must be part of legitimate presentation it makes sense to extend all current <code>present-proof</code> protocols.</p> <p>Note: The focus so far has been on AnonCreds, we will also look into device binding of W3C VC, however this is currently lacking in the examples.</p> <p>Warning: This concept is primarily meant for regulated, high-security usecases. Please review the drawbacks before considering using this.</p>"},{"location":"features/0728-device-binding-attachments/#tutorial","title":"Tutorial","text":"<p>To proof the control of a hardware bound key the holder must answer a challenge for one or more public keys embedded within verifiable credentials.</p>"},{"location":"features/0728-device-binding-attachments/#challenge","title":"Challenge","text":"<p>The following challenge object must be provided by the verifier.</p>"},{"location":"features/0728-device-binding-attachments/#device-binding-challenge","title":"device-binding-challenge","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/device-binding/%ver/device-binding-challenge\",\n  \"@id\": \"&lt;uuid-challenge-response&gt;\",\n  \"nonce\": \"&lt;nonce&gt;\", // recommend at least 128-bit unsigned integer\n  \"requests\": [\n    {\n      \"id\": \"libindy-request-presentation-0\",\n      \"path\": \"$.requested_attributes.attr2_referent.names.hardwareDid\"\n    }\n  ]\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>nonce</code> -- a nonce which has to be signed by the holder to proof control</li> <li><code>requests</code> -- an array of referenced presentation requests</li> <li><code>id</code> -- reference to an attached presentation request of <code>request-presentation</code> message (e.g. libindy request)</li> <li><code>path</code> -- JsonPath to a requested attribute which represents a public key of a hardware bound key pair - represented as did:key</li> </ul> <p>The <code>device-binding-challenge</code> must be attached to the <code>request-presentations~attach</code> array of the <code>request-presentation</code> message defined by RFC-0037 and RFC-0454.</p>"},{"location":"features/0728-device-binding-attachments/#example-request-presentation-messages","title":"Example request-presentation messages","text":"<p>The following represents a request-presentation message with an attached libindy presentation request and a corresponding device-binding-challenge.</p> <p>Present Proof v1</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/1.0/request-presentation\",\n    \"@id\": \"&lt;uuid-request&gt;\",\n    \"comment\": \"some comment\",\n    \"request_presentations~attach\": [\n        {\n            \"@id\": \"libindy-request-presentation-0\",\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;bytes for base64&gt;\"\n            }\n        }\n    ],\n    \"device_binding~attach\": [\n        {\n            \"@id\": \"device-binding-challenge-0\"\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;device-binding-challenge&gt;\"\n            }\n        }\n    ]\n}\n</code></pre> <p>Present Proof v2</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/2.0/request-presentation\",\n    \"@id\": \"&lt;uuid-request&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"some comment\",\n    \"will_confirm\": true,\n    \"present_multiple\": false,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"libindy-request-presentation-0\",\n            \"format\" : \"hlindy/proof-req@v2.0\",\n        }\n    ],\n    \"request_presentations~attach\": [\n        {\n            \"@id\": \"libindy-request-presentation-0\",\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;base64 data&gt;\"\n            }\n        }\n    ],\n    \"device_binding~attach\": [\n        {\n            \"@id\": \"device-binding-challenge-0\"\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;device-binding-challenge&gt;\" // inner object\n            }\n        }\n    ]\n}\n</code></pre>"},{"location":"features/0728-device-binding-attachments/#response","title":"Response","text":"<p>The following response must be generated by the holder of the VC.</p>"},{"location":"features/0728-device-binding-attachments/#device-binding-reponse","title":"device-binding-reponse","text":"<pre><code>{\n  \"@type\": \"https://didcomm.org/device-binding/%ver/device-binding-response\",\n  \"@id\": \"&lt;uuid-challenge-response&gt;\",\n  \"proofs\": [\n    {\n      \"id\": \"libindy-presentation-0\",\n      \"path\": \"$.requested_proof.revealed_attrs.attr1_referent.raw\"\n    }\n  ]\n}\n</code></pre> <p>Description of attributes:</p> <ul> <li><code>proofs</code> -- an array of proofs for different hardware keys which must match the <code>requests</code> array from the device-binding-challenge</li> <li><code>id</code> -- reference to presentation of VC with an embeded hardware bound key</li> <li><code>path</code> -- JsonPath to raw value of hardware bound public key within the attached presentation of the VC represented as did:key</li> </ul> <p>The <code>device-binding-response</code> must be attached to the <code>device_binding~attach</code> array of a <code>presentation</code> message defined by RFC-0037 or RFC-0454.</p> <ul> <li><code>jws</code> -- Nonce from device-binding-challenge signed with the corresponding private key as a Json Web Signature object, acording to Aries RFC-0017.</li> </ul>"},{"location":"features/0728-device-binding-attachments/#example-presentation-messages","title":"Example presentation messages","text":"<p>The following represents a presentation message with an attached libindy presentation and a corresponding device-binding-response.</p> <p>Present Proof v1</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/present-proof/1.0/presentation\",\n  \"@id\": \"&lt;uuid-presentation&gt;\",\n  \"comment\": \"some comment\",\n  \"presentations~attach\": [\n    {\n      \"@id\": \"libindy-presentation-0\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"&lt;bytes for base64&gt;\"\n      }\n    }\n  ],\n  \"device_binding~attach\": [\n    {\n      \"@id\": \"device-binding-response-0\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"&lt;device-binding-response&gt;\",\n        \"jws\": {\n          \"header\": {\n            \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n          },\n          \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n          \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n        }\n      }\n    }\n  ]\n}\n</code></pre> <p>Present Proof v2</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/present-proof/%VER/presentation\",\n    \"@id\": \"&lt;uuid-presentation&gt;\",\n    \"goal_code\": \"&lt;goal-code&gt;\",\n    \"comment\": \"some comment\",\n    \"last_presentation\": true,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"libindy-presentation-0\",\n            \"format\" : \"hlindy/proof-req@v2.0\",\n        }\n    ],\n    \"presentations~attach\": [\n        {\n            \"@id\": \"libindy-presentation-0\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"&lt;libindy presentation&gt;\"\n            }\n        }\n    ],\n    \"device_binding~attach\": [\n        {\n            \"@id\": \"device-binding-response-0\"\n            \"mime-type\": \"application/json\",\n            \"data\":  {\n                \"base64\": \"&lt;device-binding-response&gt;\",\n                \"jws\": {\n                    \"header\": {\n                        \"kid\": \"did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th\"\n                    },\n                    \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n                    \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n                }\n            }\n        }\n    ]\n}\n</code></pre>"},{"location":"features/0728-device-binding-attachments/#reference","title":"Reference","text":"<ul> <li>DIF Wallet Security Github Page</li> </ul>"},{"location":"features/0728-device-binding-attachments/#drawbacks","title":"Drawbacks","text":"<p>Including a hardware-bound public key (as an attribute) into a Verifiable Credential/AnonCred is necessary for this concept but introduces a globally unique and therefore trackable identifier. As this public key is revealed to the verifier, there is a higher risk of correlation. The Issuer must always use a hardware-bound key for a single credential and the Wallet should enforce to never reuse the key. Additionally, the holder should ideally be informed about the increased correlation risk by the wallet UX.</p>"},{"location":"features/0728-device-binding-attachments/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>The rationale behind this proposal is to formalize the way a holder wallet can proof the control of a (hardware-bound) key.</p> <p>This proposal tries to extend existing protocols to reduce the implementation effort for existing solutions. It might be reasonable to include this only in a new version of the present proof protocol (e.g. present-proof v3).</p>"},{"location":"features/0728-device-binding-attachments/#prior-art","title":"Prior art","text":"<p>None to our knowledge.</p>"},{"location":"features/0728-device-binding-attachments/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>What is the best way to reference hardware bound keys within VCs and presentations?</li> <li>Do we need a standardised attribute name for the hardware backed public key (e.g. \"HardwareDid\")</li> <li>Can we just reference the hardware key within the request object?</li> <li>Is it required to explicitly define the accepted signing algorithm within the <code>device-binding-challenge</code> object?</li> <li>What kind of key encoding do we choose?</li> <li>did:key, base64-encoded JWK and did:jwk in discussion</li> </ul>"},{"location":"features/0728-device-binding-attachments/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0734-push-notifications-fcm/","title":"Aries RFC 0734: Push Notifications fcm Protocol 1.0","text":"<ul> <li>Authors: Timo Glastra (Animo Solutions) &amp; Berend Sliedrecht (Animo Solutions)</li> <li>Status: PROPOSED</li> <li>Since: 2022-05-12</li> <li>Status Note: Initial version</li> <li>Start Date: 2022-05-12</li> <li>Tags: feature, protocol</li> </ul> <p>Note: This protocol is currently written to support native push notifications using fcm. For the implementation for iOS (via apns), please refer to 0699: Push Notifications apns</p>"},{"location":"features/0734-push-notifications-fcm/#summary","title":"Summary","text":"<p>A protocol to coordinate a push notification configuration between two agents.</p>"},{"location":"features/0734-push-notifications-fcm/#motivation","title":"Motivation","text":"<p>This protocol would give an agent enough information to send push notifications about specific events to a device that supports fcm. This would be of great benefit for mobile wallets, as a holder can be notified when new messages are pending at the mediator. Mobile applications, such as wallets, are often killed and can not receive messages from the mediator anymore. Push notifications would resolve this problem.</p>"},{"location":"features/0734-push-notifications-fcm/#tutorial","title":"Tutorial","text":""},{"location":"features/0734-push-notifications-fcm/#name-and-version","title":"Name and Version","text":"<p>URI: <code>https://didcomm.org/push-notifications-fcm/1.0</code></p> <p>Protocol Identifier: <code>push-notifications-fcm</code></p> <p>Version: <code>1.0</code></p>"},{"location":"features/0734-push-notifications-fcm/#key-concepts","title":"Key Concepts","text":"<p>When an agent would like to receive push notifications at record event changes, e.g. incoming credential offer, incoming connection request, etc., the agent could initiate the protocol by sending a message to the other agent.</p> <p>This protocol only defines how an agent would get the token and platform that is necessary for push notifications.</p> <p>Each platform has its own protocol so that we can easily use 0031: Discover Features 1.0 and 0557: Discover Features 2.X to see which specific services are supported by the other agent.</p>"},{"location":"features/0734-push-notifications-fcm/#roles","title":"Roles","text":"<p>notification-sender</p> <p>notification-receiver</p> <p>The notification-sender is an agent who will send the notification-receiver notifications. The notification-receiver can get and set their push notification configuration at the notification-sender.</p>"},{"location":"features/0734-push-notifications-fcm/#services","title":"Services","text":"<p>This RFC focuses on configuring the data necessary for pushing notifications via Firebase Cloud Messaging.</p> <p>In order to implement this protocol, the set-device-info and get-device-info messages MUST be implemented by the notification-sender and device-info message MUST be implemented by the notification-receiver.</p>"},{"location":"features/0734-push-notifications-fcm/#supported-services","title":"Supported Services","text":"<p>The protocol currently supports the following push notification services</p> <ul> <li>Firebase Cloud Messaging</li> </ul>"},{"location":"features/0734-push-notifications-fcm/#messages","title":"Messages","text":"<p>When a notification-receiver wants to receive push notifications from the notification-sender, the notification-receiver has to send the following message:</p>"},{"location":"features/0734-push-notifications-fcm/#set-device-info","title":"Set Device Info","text":"<p>Message to set the device info using the fcm device token and device platform for push notifications.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-fcm/1.0/set-device-info\",\n  \"@id\": \"&lt;UUID&gt;\",\n  \"device_token\": \"&lt;DEVICE_TOKEN&gt;\",\n  \"device_platform\": \"&lt;DEVICE_PLATFORM&gt;\"\n}\n</code></pre> <p>Description of the fields:</p> <ul> <li><code>device_token</code> -- The token that is required by the notification provider (string, null)</li> <li><code>device_platform</code> -- The platform used by the sender, e.g. Android / iOS / Linux / etc. (string, null)</li> </ul> <p>It is important to note that the set device info message can be used to set, update and remove the device info. To set, and update, these values the normal messages as stated above can be used. To remove yourself from receiving push notifications, you can send the same message where all values MUST be <code>null</code>. If either value is <code>null</code>, a <code>problem-report</code> MAY be sent back with <code>missing-value</code>.</p>"},{"location":"features/0734-push-notifications-fcm/#get-device-info","title":"Get Device Info","text":"<p>When a notification-receiver wants to get their push-notification configuration, they can send the following message:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-fcm/1.0/get-device-info\",\n  \"@id\": \"&lt;UUID&gt;\"\n}\n</code></pre>"},{"location":"features/0734-push-notifications-fcm/#device-info","title":"Device Info","text":"<p>Response to the get device info:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-fcm/1.0/device-info\",\n  \"device_token\": \"&lt;DEVICE_TOKEN&gt;\",\n  \"device_platform\": \"&lt;DEVICE_PLATFORM&gt;\",\n  \"~thread\": {\n    \"thid\": \"&lt;GET_DEVICE_INFO_UUID&gt;\"\n  }\n}\n</code></pre> <p>This message can be used by the notification-receiver to receive their device info, e.g. <code>device_token</code> and <code>device_platform</code>. If the notification-sender does not have this field for that connection, a <code>problem-report</code> MAY be used as a response with <code>not-registered-for-push-notifications</code>.</p>"},{"location":"features/0734-push-notifications-fcm/#adopted-messages","title":"Adopted messages","text":"<p>In addition, the <code>ack</code> message is adopted into the protocol for confirmation by the notification-sender. The ack message SHOULD be sent in response to any of the set-device-info messages.</p>"},{"location":"features/0734-push-notifications-fcm/#sending-push-notifications","title":"Sending Push Notifications","text":"<p>When an agent wants to send a push notification to another agent, the payload of the push notifications MUST include the <code>@type</code> property, and COULD include the <code>message_tags</code> property, to indicate the message is sent by the notification-sender. Guidelines on notification messages are not defined.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-fcm\",\n  \"message_tags\": [\"&lt;MESSAGE_TAG&gt;\"],\n  \"message_ids\": [\"&lt;MESSAGE_ID&gt;\"],\n  ...\n}\n</code></pre> <p>Description of the fields:</p> <ul> <li><code>@type</code> -- Indicator of what kind of notification it is. (This could help the notification-receiver with parsing if a notification comes from another agent, for example)</li> <li><code>message_tag</code> -- Optional list field to connect the push notification to a DIDcomm message, this can be used for batching multiple messages to a single notification. As defined in 0334: jwe-envelope or 0019: encryption-envelope.</li> <li><code>message_ids</code> -- Optional list field to pickup the message from the mediator that the notification was linked to, this can be used for batching multiple messages to a single notification. As defined in 0685: Pickup Protocol 2.0.</li> </ul>"},{"location":"features/0734-push-notifications-fcm/#drawbacks","title":"Drawbacks","text":"<p>Each service requires a considerable amount of domain knowledge. The RFC can be extended with new services over time.</p> <p>The <code>@type</code> property in the push notification payload currently doesn't indicate which agent the push notification came from. In e.g. the instance of using multiple mediators, this means the notification-receiver does not know which mediator to retrieve the message from.</p>"},{"location":"features/0734-push-notifications-fcm/#prior-art","title":"Prior art","text":"<ul> <li>This RFC is based on the implementation of the <code>AddDeviceInfoMessage</code> in Aries Framework .NET</li> </ul>"},{"location":"features/0734-push-notifications-fcm/#unresolved-questions","title":"Unresolved questions","text":"<p>None</p>"},{"location":"features/0734-push-notifications-fcm/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0745-push-notifications-expo/","title":"Aries RFC 0745: Push Notifications Expo Protocol 1.0","text":"<ul> <li>Authors: Timo Glastra (Animo Solutions) &amp; Berend Sliedrecht (Animo Solutions)</li> <li>Status: PROPOSED</li> <li>Since: 2022-07-26</li> <li>Status Note: Initial version</li> <li>Start Date: 2022-07-15</li> <li>Tags: feature, protocol</li> </ul> <p>Note: This protocol is currently written to support sending push notifications through Expo's push notification service. For sending push notification directly using APNS or FCM see the respective RFCs; 0734: Push Notifications fcm and 0699: Push Notifications apns.</p>"},{"location":"features/0745-push-notifications-expo/#summary","title":"Summary","text":"<p>Expo provides tools and services on top of React Native. This RFC defines a protocol to coordinate expo push notification configuration between two agents, allowing the notification-sender to send push notifications through Expo's push notification service to the notification-receiver.</p>"},{"location":"features/0745-push-notifications-expo/#motivation","title":"Motivation","text":"<p>When mobile edge agents are offline and messages are received at the mediator, it is desired that the mediator can inform the mobile agent of pending messages. A protocol to set the push notification device info at another agent allows the mediator to send updates to the mobile agent.</p>"},{"location":"features/0745-push-notifications-expo/#tutorial","title":"Tutorial","text":""},{"location":"features/0745-push-notifications-expo/#name-and-version","title":"Name and Version","text":"<p>URI: <code>https://didcomm.org/push-notifications-expo/1.0</code></p> <p>Protocol Identifier: <code>push-notifications-expo</code></p> <p>Version: <code>1.0</code></p>"},{"location":"features/0745-push-notifications-expo/#key-concepts","title":"Key Concepts","text":"<p>When an agent would like to receive push notifications of pending messages, e.g. when a forward message is received at the mediator, the notification-receiver can register for push notifications at the notification-sender using the <code>set-device-info</code> message.</p> <p>This protocol only defines how an agent would get the token which is necessary for push notifications.</p> <p>Each platform is has its own protocol so that we can easily use 0031: Discover Features 1.0 and 0557: Discover Features 2.X to see which specific services are supported by the other agent.</p>"},{"location":"features/0745-push-notifications-expo/#roles","title":"Roles","text":"<p>notification-sender</p> <p>notification-receiver</p> <p>The notification-sender is an agent who will send the notification-receiver notifications. The notification-receiver can get and set their push notification configuration at the notification-sender.</p>"},{"location":"features/0745-push-notifications-expo/#services","title":"Services","text":"<p>This RFC focusses on configuring the data necessary for pushing notifications to iOS and Android, via Expo's Push API</p>"},{"location":"features/0745-push-notifications-expo/#messages","title":"Messages","text":"<p>When a notification-receiver wants to receive push notifications from the notification-sender, the notification-receiver has to send the following message:</p>"},{"location":"features/0745-push-notifications-expo/#set-device-info","title":"Set Device Info","text":"<p>Message to set the device info using the Expo Push Token for push notifications.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-expo/1.0/set-device-info\",\n  \"@id\": \"&lt;UUID&gt;\",\n  \"device_token\": \"&lt;DEVICE_TOKEN&gt;\"\n}\n</code></pre> <p>Description of the fields:</p> <ul> <li><code>device_token</code> -- The token that is required by the notification provider. Usually has the format of <code>ExponentPushToken[xxxxxxxxxxxxxxxxxxxxxx]</code> (string, null)</li> </ul> <p>It is important to note that the set device info message can be used to set, update and remove the device info. To set, and update, these values the normal messages as stated above can be used. To remove yourself from receiving push notifications, you can send the same message where the <code>device_token</code> value is <code>null</code>.</p>"},{"location":"features/0745-push-notifications-expo/#get-device-info","title":"Get Device Info","text":"<p>When a notification-receiver wants to get their push-notification configuration, they can send the following message:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-expo/1.0/get-device-info\",\n  \"@id\": \"&lt;UUID&gt;\"\n}\n</code></pre>"},{"location":"features/0745-push-notifications-expo/#device-info","title":"Device Info","text":"<p>Response to the get device info:</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-expo/1.0/device-info\",\n  \"device_token\": \"&lt;DEVICE_TOKEN&gt;\",\n  \"~thread\": {\n    \"thid\": \"&lt;GET_DEVICE_INFO_UUID&gt;\"\n  }\n}\n</code></pre> <p>This message can be used by the notification-receiver to receive their device info, e.g. <code>device_token</code>. If the notification-sender does not have this field for that connection, a <code>problem-report</code> MAY be used as a response with <code>not-registered-for-push-notifications</code>.</p>"},{"location":"features/0745-push-notifications-expo/#adopted-messages","title":"Adopted messages","text":"<p>In addition, the <code>ack</code> message is adopted into the protocol for confirmation by the notification-sender. The ack message MUST be sent in response to any of the set-device-info messages.</p>"},{"location":"features/0745-push-notifications-expo/#sending-push-notifications","title":"Sending Push Notifications","text":"<p>When an agent wants to send a push notification to another agent, the payload of the push notifications MUST include the <code>@type</code> property, and COULD include the <code>message_tag</code> property, to indicate the message is sent by the notification-sender. Guidelines on notification messages are not defined.</p> <pre><code>{\n  \"@type\": \"https://didcomm.org/push-notifications-expo\",\n  \"message_tag\": \"&lt;MESSAGE_TAG&gt;\",\n  \"message_id\": \"&lt;MESSAGE_ID&gt;\",\n  ...\n}\n</code></pre> <p>Description of the fields:</p> <ul> <li><code>@type</code> -- Indicator of what kind of notification it is. (This could help the notification-receiver with parsing if a notification comes from another agent, for example)</li> <li><code>message_tag</code> -- Optional field to connect the push notification to a DIDcomm message. As defined in 0334: jwe-envelope or 0019: encryption-envelope.</li> <li><code>message_id</code> -- Optional field to pickup the message from the mediator that the notification was linked to. As defined in 0685: Pickup Protocol 2.0.</li> </ul>"},{"location":"features/0745-push-notifications-expo/#drawbacks","title":"Drawbacks","text":"<p>Each service requires a considerable amount of domain knowledge. The RFC can be extended with new services over time.</p> <p>The <code>@type</code> property in the push notification payload currently doesn't indicate which agent the push notification came from. In e.g. the instance of using multiple mediators, this means the notification-receiver does not know which mediator to retrieve the message from.</p>"},{"location":"features/0745-push-notifications-expo/#prior-art","title":"Prior art","text":"<ul> <li>This RFC is based on the implementation of the <code>AddDeviceInfoMessage</code> in Aries Framework .NET</li> </ul>"},{"location":"features/0745-push-notifications-expo/#unresolved-questions","title":"Unresolved questions","text":"<p>None</p>"},{"location":"features/0745-push-notifications-expo/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0748-n-wise-did-exchange/","title":"Aries RFC 0748: N-wise DID Exchange Protocol 1.0","text":"<ul> <li>Authors: Mikhail Lytaev, Pavel Minenkov</li> <li>Status: DEMONSTRATED</li> <li>Since: 2022-08-03</li> <li>Status Note: Under research</li> <li>Supersedes:</li> <li>Start Date: 2022-06-03</li> <li>Tags: feature, protocol</li> <li>URI: https://didcomm.org/n-wise/1.0</li> </ul>"},{"location":"features/0748-n-wise-did-exchange/#summary","title":"Summary","text":"<p>This RFC defines a protocol for creating and managing relationships within a group of SSI subjects. In a certain sense, this RFC is a generalization of the pairwise concept and protocols 0160-connection-protocol and 0023-did-exchange for an arbitrary number of parties (n-wise).</p>"},{"location":"features/0748-n-wise-did-exchange/#motivation","title":"Motivation","text":"<p>SSI subjects and agents representing them must have a way to establish relationships with each other in a trustful manner. In the simplest case, when only two participants are involved, this goal is achieved using 0023-did-exchange protocol by creating and securely sharing their DID Documents directly between agents. However, it is often desirable to organize an interaction involving more than two paries. The number of parties of such an interaction may change over time, and most of the agents may be mobile ones. The simplest and most frequently used example of such interaction is a group chat in instant messenger. The trusted nature of SSI technology makes it possible to use group relationships for holding legally significant unions, such as board of directors, territorial community or dissertation councils.</p>"},{"location":"features/0748-n-wise-did-exchange/#tutorial","title":"Tutorial","text":""},{"location":"features/0748-n-wise-did-exchange/#name-and-version","title":"Name and Version","text":"<p>n-wise, version 1.0</p> <p>URI: https://didcomm.org/n-wise/1.0</p>"},{"location":"features/0748-n-wise-did-exchange/#registry-of-n-wise-states","title":"Registry of n-wise states","text":"<p>The current state of n-wise is an up-to-date list of the parties' DID Documents. In pairwise relation the state is stored by the participants and updated by a direct notification of the other party. When there are more than two participants, the problem of synchronizing the state of this n-wise (i.e. consensus) arising. It should be borne in mind that the state may change occasionally: users may be added or deleted, DID Documents may be modified (when keys are rotated or endpoints are changed).</p> <p>In principle, any trusted repository can act as a registry of n-wise states. The following options for storing the n-wise state can be distinguished:</p> <ul> <li> <p>This approach is the closest to 0023-did-exchange protocol. However since there are more than two participants, an additional consensus procedure is required to correctly account for changes in the n-wise state. This option is suitable if the participants are represented by cloud agents which are (almost) always online. In this case, a consensus can be established between them using the well-known algorithms (RAFT, Paxos, BFT). However, if most of the agents are mobile and are online only occasionally, the mentioned consensus algorithms are not applicable. So it is preferable to use external solutions for storing and updating the n-wise states.</p> </li> <li> </li> <li> <p>In this case, the task of recording and storing the state is taken over by a third-party distributed network. The network can verify incoming transactions by executing a smart contract, or accept all incoming transactions, so transaction validation takes place only on the participating agents.</p> </li> <li> </li> </ul> <p>The concept of pluggable consensus implies choosing the most appropriate way to maintain a registry of states, depending on the needs.</p> <p>N-wise state update is performed by committing the corresponding transaction to the registry of n-wise states. To get the current n-wise state, the agent receives a list of transactions from the registry of states, verifies them and applies sequentially, starting with the <code>genesisTx</code>. Incorrect transactions (without a proper signature or missing the required fields) are ignored. Thus, n-wise can be considered as a replicated state machine, which is executed on each participant.</p> <p>The specifics of recording and receiving transactions depend on the particular method of maintaining the n-wise registry and on a particular ledger. This RFC DOES NOT DEFINE specific n-wise registry implementations.</p>"},{"location":"features/0748-n-wise-did-exchange/#directly-on-the-agents-side-edge-chain","title":"Directly on the agent's side (Edge chain)","text":""},{"location":"features/0748-n-wise-did-exchange/#public-or-private-distributed-ledger","title":"Public or private distributed ledger","text":""},{"location":"features/0748-n-wise-did-exchange/#centralized-storage","title":"Centralized storage","text":"<ul> <li>This case is applicable when security requirements allow participants to trust a centralized solution.</li> </ul>"},{"location":"features/0748-n-wise-did-exchange/#roles","title":"Roles","text":"<ul> <li> <p>The party of n-wise. Has the right to:</p> <ul> <li>Modify its DID Document;</li> <li>Remove himself from n-wise;</li> <li>Invite new parties.</li> </ul> </li> <li> </li> <li> <p>In addition to user's rights, has the right to:</p> <ul> <li>Remove other users from n-wise;</li> <li>Modify n-wise meta information;</li> <li>Transfer its role to another user.</li> </ul> </li> <li> <p>There can be only one owner in n-wise at a time.</p> </li> <li> </li> <li> <p>Creator of the n-wise and the author of <code>genesisTx</code>. </p> </li> <li> <p>The creator automatically becomes the owner of n-wise after creation.</p> </li> <li> </li> <li> <p>The n-wise participant who initiates the invitation of a new one.</p> </li> <li> </li> <li> <p>The participant accepting the invitation and connecting to n-wise. If successful, the participant becomes a user of n-wise.</p> </li> </ul>"},{"location":"features/0748-n-wise-did-exchange/#user","title":"User","text":""},{"location":"features/0748-n-wise-did-exchange/#owner","title":"Owner","text":""},{"location":"features/0748-n-wise-did-exchange/#creator","title":"Creator","text":""},{"location":"features/0748-n-wise-did-exchange/#inviter","title":"Inviter","text":""},{"location":"features/0748-n-wise-did-exchange/#invitee","title":"Invitee","text":""},{"location":"features/0748-n-wise-did-exchange/#actions","title":"Actions","text":""},{"location":"features/0748-n-wise-did-exchange/#n-wise-creation","title":"N-wise creation","text":"<p>The creation begins with the initialization of the n-wise registry. This RFC DOES NOT SPECIFY the procedure for n-wise registry creation. After creating the registry, the creator commits the <code>genesisTx</code> transaction. The creator automatically obtains the role of owner. The creator MUST generate a unique DID and DID Document for n-wise.</p>"},{"location":"features/0748-n-wise-did-exchange/#invitation-of-a-new-party","title":"Invitation of a new party","text":"<p>Any n-wise party can create an invitation to join n-wise. First, inviter generates a pair of public and private invitation keys according to Ed25519. The public key of the invitation is pushed to the registry using the <code>invitationTx</code> transaction. Then the <code>Invitation</code> message with the invitation private key is sent out-of-band to the invitee. The invitation key pair is unique for each invitee and can be used only once.</p>"},{"location":"features/0748-n-wise-did-exchange/#accepting-the-invitation","title":"Accepting the invitation","text":"<p>Once <code>Invitation</code> received, the invite generates a unique DID and DID Document for the n-wise and commits <code>AddParticipantTx</code> transaction to the registry. It is NOT ALLOWED to reuse DID from other relationships.</p> <p>The process of adding a new participant is shown in the figure below</p> <p></p>"},{"location":"features/0748-n-wise-did-exchange/#updating-did-document","title":"Updating DID Document","text":"<p>Updating the user's DID Document is required for the key rotation or endpoint updating. To update the associated DID Document, user commits the <code>updateParticipantTx</code> transaction to the registry.</p>"},{"location":"features/0748-n-wise-did-exchange/#removing-a-party-form-n-wise","title":"Removing a party form n-wise","text":"<p>Removing is performed using the <code>removeParticipantTx</code> transaction. The user can delete itself (the corresponding transaction is signed by the user's public key). The owner can delete any user (the corresponding transaction is signed by the owner's public key).</p>"},{"location":"features/0748-n-wise-did-exchange/#updating-n-wise-meta-information","title":"Updating n-wise meta information","text":"<p>Meta information can be updated by the owner using the <code>updateMetadataTx</code> transaction.</p>"},{"location":"features/0748-n-wise-did-exchange/#transferring-the-owner-role-to-other-user","title":"Transferring the owner role to other user","text":"<p>The owner can transfer control of the n-wise to other user. The old owner loses the corresponding privileges and becomes a regular user. The operation is performed using the <code>NewOwnerTx</code> transaction.</p>"},{"location":"features/0748-n-wise-did-exchange/#notification-on-n-wise-state-update","title":"Notification on n-wise state update","text":"<p>Just after committing the transaction to the n-wise registry, the participant MUST send the <code>ledger-update-notify</code> message to all other parties. The participant who received <code>ledger-update-notify</code> SHOULD fetch updates from the n-wise registry.</p>"},{"location":"features/0748-n-wise-did-exchange/#didcomm-messaging-within-n-wise","title":"DIDComm messaging within n-wise","text":"<p>It is allowed to exchange DIDComm messages of any type within n-wise. The belonging of the sender to a certain n-wise is determined by the sender's verkey.</p> <p>This RFC DOES NOT DEFINE a procedure of exchanging messages within n-wise. In the simplest case, this can be implemented as sending a message to each participant in turn. In case of a large number of parties, it is advisable to consider using a centralized coordinator who would be responsible for the ordering and guaranteed sending of messages from the sender to the rest of parties.</p>"},{"location":"features/0748-n-wise-did-exchange/#reference","title":"Reference","text":""},{"location":"features/0748-n-wise-did-exchange/#n-wise-registry-transactions","title":"N-wise registry transactions","text":"<p>N-wise state is modified using transactions in the following form</p> <pre><code>{\n  \"type\": \"transaction type\",\n  ...\n  \"proof\" {\n    \"type\": \"JcsEd25519Signature2020\",\n    \"verificationMethod\": \"did:alice#key1\",\n    \"signatureValue\": \"...\"\n\n  }\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes","title":"Attributes","text":"<ul> <li><code>type</code> - required attribute, type of transaction;</li> <li><code>proof</code> - required attribute, transaction signature in JSON-LD Proof format;</li> <li><code>verificationMethod</code> - required attribute, depends on the specific type of transaction and is defined below.</li> </ul>"},{"location":"features/0748-n-wise-did-exchange/#genesistx","title":"GenesisTx","text":"<p>'GenesisTx' is a mandatory initial transaction that defines the basic properties of the n-wise.</p> <pre><code>{\n  \"type\": \"genesisTx\",\n  \"label\": \"Council\",\n  \"creatorNickname\": \"Alice\",\n  \"creatorDid\": \"did:alice\",\n  \"creatorDidDoc\": {\n   ..\n  },\n  \"ledgerType\": \"iota@1.0\",\n  \"metaInfo\" {\n    ...\n  }\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes_1","title":"Attributes","text":"<ul> <li><code>label</code> - required attribute, n-wise name;</li> <li><code>creatorNickname</code> - required attribute, creator nickname;</li> <li><code>creatorDid</code> - required attribute, DID of the creator;</li> <li><code>creatorDidDoc</code> - required attribute, DID Document of the creator;</li> <li><code>ledgerType</code> - required attribute, n-wise registry type;</li> <li><code>metaInfo</code> - optional attribute, additional n-wise meta information; the format is determined by a particular n-wise state implementation;</li> </ul> <p>The <code>genesisTx</code> transaction MUST be signed by the creator's public key defined in his DID Document.</p>"},{"location":"features/0748-n-wise-did-exchange/#invitationtx","title":"InvitationTx","text":"<p>This transaction adds the invitation public keys to the n-wise registry.</p> <pre><code>{\n  \"type\": \"invitationTx\",\n  \"publicKey\": [\n    {\n      \"id\": \"invitationVerkeyForBob\",\n      \"type\": \"Ed25519VerificationKey2018\",\n      \"publicKeyBase58\": \"arekhj893yh3489qh\"\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes_2","title":"Attributes","text":"<ul> <li><code>publicKey</code> - required attribute, array of invitation public keys;</li> <li><code>id</code> - required attribute, invitation public key ID;</li> <li><code>type</code> - required attribute, key type;</li> <li><code>publicKeyBase58</code> - required attribute, base58 encoded public key.</li> </ul> <p>invitationTx` MUST be signed by the user's public key defined in it's DID Document.</p>"},{"location":"features/0748-n-wise-did-exchange/#invitation-message","title":"Invitation message","text":"<p>The message is intended to invite a new participant. It is sent via an arbitrary communication channel (pairwise, QR code, e-mail, etc.).</p> <pre><code>{\n  \"@id\": \"5678876542345\",\n  \"@type\": \"https://didcomm.org/n-wise/1.0/invitation\",\n  \"label\": \"Invitaion to join n-wise\",\n  \"invitationKeyId\": \"invitationVerkeyForBob\",\n  \"invitationPrivateKeyBase58\": \"qAue25rghuFRhrue....\",\n  \"ledgerType\": \"iota@1.0\",\n  \"ledger~attach\": [\n    {\n      \"@id\": \"attachment id\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"&lt;bytes for base64&gt;\"\n      }\n    }  \n  ]\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes_3","title":"Attributes","text":"<ul> <li><code>label</code> - optional attribute, human readable invitation text;</li> <li><code>invitationKeyId</code> - required attribute, invitation key ID;</li> <li><code>invitationPrivateKeyBase58</code>- required attribute, base58 encoded invitation private key;</li> <li><code>ledgerType</code> - required attribute, n-wise registry type;</li> <li><code>ledger~attach</code> - optional attribute, attachment with meta information, required for connection to n-wise registry; defined by a particular registry implementation.</li> </ul>"},{"location":"features/0748-n-wise-did-exchange/#addparticipanttx","title":"AddParticipantTx","text":"<p>The transaction is designed to add a new user to n-wise.</p> <pre><code>{\n  \"id\": \"addParticipantTx\",\n  \"nickname\": \"Bob\",\n  \"did\": \"did:bob\",\n  \"didDoc\": {\n    ...\n  }\n\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes_4","title":"Attributes","text":"<ul> <li><code>nickname</code> - required attribute, user nickname;</li> <li><code>did</code> - required attribute, user's DID;</li> <li><code>didDoc</code> - required attribute, user's DID Document.</li> </ul> <p><code>AddParticipantTx</code> transaction MUST be signed by the invitation private key  (<code>invitationPrivateKeyBase58</code>), received in <code>Invitation</code> message. As committing the <code>AddParticipantTx</code> transaction, the corresponding invitation key pair is considered deactivated (other invitations cannot be signed by it).</p> <p>The transaction executor MUST verify if the invitation key was indeed previously added. Execution of the transaction entails the addition of a new party to n-wise.</p>"},{"location":"features/0748-n-wise-did-exchange/#updateparticipanttx","title":"UpdateParticipantTx","text":"<p>The transaction is intended to update information about the participant.</p> <pre><code>{\n  \"type\": \"updateParticipantTx\",\n  \"did\": \"did:bob\",\n  \"nickname\": \"Updated Bob\",\n  \"didDoc\" {\n    ...\n  }\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes_5","title":"Attributes","text":"<ul> <li><code>did</code> - requred attribute, DID of the updating user;</li> <li><code>nickname</code> - optional attribute, new nickname;</li> <li><code>didDoc</code> - optional attribute, new DID document.</li> </ul> <p>Transaction MUST be signed by the public key of the user being updated. The specified public key MUST be defined in the previous version of the DID Document.</p> <p>Execution of the transaction entails updating information about the participant.</p>"},{"location":"features/0748-n-wise-did-exchange/#removeparticipanttx","title":"RemoveParticipantTx","text":"<p>The transaction is designed to remove a party from n-wise.</p> <pre><code>{\n  \"type\": \"removeParticipantTx\",\n  \"did\": \"did:bob\"\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes_6","title":"Attributes","text":"<ul> <li><code>did</code> - requred attribute, DID of the removing user;</li> </ul> <p>The execution of the transaction entails the removal of the user and his DID Document from the list of n-wise parties.</p> <p>The transaction MUST be signed by the public key of the user who is going to be removed from n-wise, or with the public key of the owner.</p>"},{"location":"features/0748-n-wise-did-exchange/#updatemetadatatx","title":"UpdateMetadataTx","text":"<p>The transaction is intended to update the meta-information about n-wise.</p> <pre><code>{\n    \"type\": \"updateMetadataTx\",\n    \"label\": \"Updated Council\"\n    \"metaInfo\": {\n      ...\n    }\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes_7","title":"Attributes","text":"<ul> <li><code>label</code> - optional attribute, new n-wise name;</li> <li><code>metaInfo</code> - optional attribute, new n-wise meta-information.</li> </ul> <p>The transaction MUST be signed by the owner's public key.</p>"},{"location":"features/0748-n-wise-did-exchange/#newownertx","title":"NewOwnerTx","text":"<p>The transaction is intended to transfer the owner role to another user. The old owner simultaneously becomes a regular user.</p> <pre><code>{\n    \"type\": \"newOwnerTx\",\n    \"did\": \"did:bob\"\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#attributes_8","title":"Attributes","text":"<ul> <li><code>did</code> required attribute, new owner's DID.</li> </ul> <p>The transaction MUST be signed by the owner's public key.</p>"},{"location":"features/0748-n-wise-did-exchange/#ledger-update-notify","title":"ledger-update-notify","text":"<p>The message is intended to notify participants about the  modifications of the n-wise state.</p> <pre><code>{\n  \"@id\": \"4287428424\",\n  \"@type\": \"https://didcomm.org/n-wise/1.0/ledger-update-notify\"\n}\n</code></pre>"},{"location":"features/0748-n-wise-did-exchange/#drawbacks","title":"Drawbacks","text":"<ul> <li>External DLT is required;</li> <li>The user hierarchy is quite primitive.</li> </ul>"},{"location":"features/0748-n-wise-did-exchange/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>Public DID methods use blockchain networks or other public storages for its DID Documents. Peer DID rejects the use of external storage, which is absolutely justified for a pairwise relationship, since a DID Document can be stored by the other participant. If there are more than two participants, consensus on the list of DID Documents is required. N-wise is  somewhat of a middle ground between a Peer DID (DID document is stored only by a partner) and a public DID (DID document is available to everyone in the internet). So, the concept of n-wise state registry was introduced in this RFC, and its specific implementations (consensus between participants or a third-party trusted registry) remain at the discretion of the  n-wise creator. The concept of microledger is also considerable to use for the n-wise state registry.</p> <p>One more promising high-level concept for building n-wise protocols is Gossyp.</p>"},{"location":"features/0748-n-wise-did-exchange/#prior-art","title":"Prior art","text":"<p>The term of n-wise was proposed in Peer DID specification, and previously discussed in document. However, no strict formalization of this process was proposed, as well as the need for consensus between the participants was not noted.</p>"},{"location":"features/0748-n-wise-did-exchange/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Who should be responsible for the order of transactions?</li> <li>How to define specific n-wise state registry implementations (separate RFCs?)</li> <li>How to make a flexible user hierarchy?</li> </ul>"},{"location":"features/0748-n-wise-did-exchange/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes Sirius SDK Java IOTA Ledger based implementation (IOTA n-wise registry spec). See a detailed example in Jupyter notebook."},{"location":"features/0755-oca-for-aries/","title":"0755: Overlays Capture Architecture (OCA) For Aries","text":"<ul> <li>Authors: Stephen Curran</li> <li>Status: DEMONSTRATED</li> <li>Since: 2024-03-02</li> <li>Status Note: Implemented in the Bifold Wallet</li> <li>Start Date: 2022-09-25</li> <li>Version: 1.0</li> <li>Tags: feature</li> </ul>"},{"location":"features/0755-oca-for-aries/#summary","title":"Summary","text":"<p>Overlays Capture Architecture (OCA) is, per the OCA specification, a \"standardized global solution for data capture and exchange.\" Given a data structure (such as a verifiable credential), OCA allows for the creation of purpose-specific overlays of information about that data structure. Each overlay provides some knowledge (human and machine-readable) about the overall data structure or the individual attributes within it. The information in the overlays makes it possible to create useful software for capturing data, displaying it and exchanging it. While the OCA website and OCA specification can be reviewed for a detailed background of OCA and its various purposes, in this RFC we'll focus on its purpose in Aries, which is quite constrained and pragmatic--a mechanism for an issuer to provide information about a verifiable credential to allow holder and verifier software to display the credential in a human-friendly way, including using the viewers preferred language, and the issuer's preferred branding. The image below shows an Aries mobile Wallet displaying the same credential without and with OCA overlays applied in two languages. All of the differences in the latter two screenshots from the first come from issuer-supplied OCA data.</p> <p></p> <p>This RFC formalizes how Aries verifiable credential issuers can make a JSON OCA Bundle (a set of related OCA overlays about a base data structure) available to holders and verifiers that includes the following information for each type of credential they issue.</p> <ul> <li>Metadata about the credential, such as the Classification system upon which   the credential is based.</li> <li>Metadata about the credential in multiple languages, such as its name,   description, the name and description of the issuer and so on.</li> <li>Type, format, encoding, standard and units information about the credential's raw   attribute data.</li> <li>Metadata about the attributes within the credential in multiple languages,   such as a label and help text.</li> <li>A set of branding elements (logo, background image, color and so on) that   holder and verifier software are expected to use in displaying the credential.</li> </ul> <p>The standard flow of data between participants is as follows:</p> <ul> <li>An issuer creates an OCA Bundle for each type of verifiable credential it issues.</li> <li>During credential issuance using [RFC 0453 Issue Credential V2 v2.2 (or later) protocol] the issuer MAY include in the protocol's <code>credential-offer</code> or <code>credential</code> messages the OCA Bundle for the credential type as an <code>oca-bundle</code> issue credential supplement.</li> <li>When provided, the holder software has full access to the OCA information published by that issuer and can use the OCA data to render the credential for its user(s) in the language of their choice, with credential branding from the issuer, based on the RFC0756 OCA for Aries Style Guide.</li> <li>The holder MAY share the OCA Bundle with a verifier by using [RFC 0453 Issue Credential V2 v2.2 (or later) protocol] to add the <code>oca-bundle</code> credential supplement received from the issuer.</li> <li>On receipt, the verifier software has full access to the OCA information published by that issuer and can use the OCA data to render the credential for its user(s) in the language of their choice, with credential branding from the issuer, based on the RFC0756 OCA for Aries Style Guide.</li> </ul> <p>While the issuer providing the OCA Bundle for a credential type using the credential supplement mechanism is the typical flow (as detailed in this RFC), other flows, outside of the scope of this RFC are possible. See the rationale and alternatives section of this RFC for some examples.</p>"},{"location":"features/0755-oca-for-aries/#motivation","title":"Motivation","text":"<p>The core data models for verifiable credentials are more concerned about the correct cryptographic processing of the credentials than about general processing of the attribute data, and the user experience of those using credentials. An AnonCreds verifiable credential contains the bare minimum of metadata about a credential--basically, just the developer-style names for the type of credential and the attributes within it. JSON-LD-based verifiable credentials has the capacity to add more information about the attributes in a credential, but the data is not easily accessed and is provided to enable machine processing rather than improving user experience.</p> <p>OCA allows credential issuers to declare information about the verifiable credential types it issues to improve the handling of those credentials by holder and verifier Aries agents, and to improve the on-screen display of the credentials, through the application of issuer-specified branding elements.</p>"},{"location":"features/0755-oca-for-aries/#tutorial","title":"Tutorial","text":"<p>The tutorial section of this RFC defines the coordination necessary for an the creation, publishing, retrieval and use of an OCA Bundle for a given type of verifiable credential.</p> <pre><code>In this overview, we assume the the use of OCA specifically for verifiable\ncredentials, and further, specifically for AnonCreds verifiable credentials. OCA\ncan also be used be applied to any data structure, not just verifiable\ncredentials, and for other verifiable credential models, such as those based on\nthe JSON-LD- or JWT-style verifiable credentials. As the Aries\ncommunity applies OCA to other styles of verifiable credential, we\nwill extend this RFC.\n</code></pre>"},{"location":"features/0755-oca-for-aries/#issuer-activities","title":"Issuer Activities","text":"<p>The use of OCA as defined in this RFC begins with an issuer preparing an OCA Bundle for each type of credential they issue. An OCA Bundle is a JSON data structure consisting of the Capture Base, and some additional overlays of different types (listed in the next section).</p> <p>While an OCA Bundle can be manually maintained in an OCA Bundle JSON file, a common method of maintaining OCA source data is to use a spreadsheet, and generating the OCA Bundle from the Excel source. See the section of this RFC called OCA Tooling for a link to an OCA Source spreadsheet, and information on tools available for managing the OCA Source data and generating a corresponding OCA Bundle.</p> <p>The creation of the OCA Bundle and the configuration of the issuer's Aries Framework to deliver the OCA Bundle during credential issuance should be all that a specific issuer needs to do in using OCA for Aries. An Aries Framework that supports OCA for Aries should handle the rest of the technical requirements.</p>"},{"location":"features/0755-oca-for-aries/#oca-specification-overlays","title":"OCA Specification Overlays","text":"<p>All OCA data is based on a Capture Base, which defines the data structure described in the overlays. For AnonCreds, the Capture Base attributes MUST be the list of attributes in the AnonCreds schema for the given credential type. The Capture Base also MUST contain:</p> <ul> <li>the type of each attribute, based on an enumerated list of types defined in   the OCA   specification</li> <li>a list of the base attributes that will hold Personally Identifiable Information (PII) in an issued credential. An issuer SHOULD use the Kantara Initiative's Blinding Identity Taxonomy to identify the attributes to flag as being PII.</li> </ul> <p>With the Capture Base defined, the following additional overlay types MAY be created by the Issuer and SHOULD be expected by holders and verifiers. Overlay types flagged \"multilingual\" may have multiple instances of the overlay, one for each issuer-supported language (e.g en for English, fr French, SP Spanish, etc.) or country-language (e.g., en-CA for Canadian English, fr-CA for Canadian French), as defined in the OCA Specification about languages.</p> <p>An OCA Bundle that contains overlay types that a holder or verifier does not expect MUST be processed, with the unexpected overlays ignored.</p> <ul> <li>The Character Encoding Overlay contains the encoding for each attribute in the capture base.</li> <li>The Format Overlay provides the input structure for each data attribute. The format may be useful to the holder (or verifier) in displaying the data in a style expected by the user, such as knowing that a given field of <code>type</code> binary is an image in <code>image/jpeg</code> format.</li> <li>The multilingual Label Overlay provides a label to be used for each attribute for a given language. The label overlay also includes labels for attributes with enumerated values (called categories in the OCA specification). For example, a data attribute containing the codes \"EN\", \"FR\", \"SP\" could have a category entries that indicate the codes correspond to \"English\", \"French\" and \"Spanish\", respectively.</li> <li>The multilingual Information Overlay provides a description or help text about each attribute for a given language. There will be one overlay per issuer-supported language.</li> <li>The multilingual Meta Overlay contains information about the credential itself. For Aries, the meta overlay SHOULD include the following additional name/value pairs, specific to the OCA for Aries use case:</li> <li><code>name</code> - the name of the credential.</li> <li><code>description</code> - a description of the credential.</li> <li><code>issuer</code> - the name of the issuer of the credential.</li> <li><code>issuer_description</code> - a description for the issuer of the credential.</li> <li><code>issuer_url</code> - a URL for the issuer of the credential.</li> <li><code>credential_help_text</code> - help text about the credential</li> <li><code>credential_support_url</code> - a URL for a service providing support in the use of the credential.</li> <li>The Unit Overlay   allows the issuer to declare the units of measurement for the attributes in   the overlay.</li> <li>The Standard Overlay indicates that some or all of the attributes use   specific data standards populating the attribute in a credential. This might   be used, for example, for defining the standard applied in populating a data   attribute with a date or date/time.</li> <li>The Entry Code Overlay contains a list of enumerated values for each   data attribute that uses enumerated values. An example might be a list of   regional jurisdiction (such as provinces or states) short forms that will be   placed in an attribute (e.g., NY, ND, AL, CA, etc.). The attributes in the   credential are expected to be populated with one of the enumerated values.</li> <li>The Entry Overlay contains a language-specific list of the meanings for   each enumerated value for each data attribute that uses enumerated values. For   our example of short forms of jurisdictions, the \"meanings\" would be the   expanded list per language supported (English, French, Spanish, etc.) of   jurisdictions (e.g., New York, North Dakota, Alabama, California, etc.).</li> </ul>"},{"location":"features/0755-oca-for-aries/#aries-specific-dates-in-the-oca-format-overlay","title":"Aries-Specific Dates in the OCA Format Overlay","text":"<p>In AnonCreds, zero-knowledge proof (ZKP) predicates (used, for example, to prove older than a given age based on date of birth without sharing the actual date of birth) must be based on integers. In the AnonCreds/Aries community, common ways for representing dates and date/times as integers so that they can be used in ZKP predicates are the <code>dateint</code> and <code>Unix Time</code> formats, respectively.</p> <ul> <li> <p>\"<code>dateint</code>\" is a credential attribute that uses the Aries <code>dateint</code> specification as described in Aries RFC 0592. Briefly, <code>dateint</code> is a date (YYYYMMDD) provided in a credential attribute as an integer (for example <code>September 29, 2022</code> is the integer <code>20220929</code> or <code>20,220,929</code>). <code>dateint</code> is also part of ISO standard 1989 for COBOL Programming Interfaces, described here in an IBM document.</p> </li> <li> <p>\"<code>Unix Time</code>\" is a credential attribute that is a date/time timestamp constructed according to the <code>Unix Time</code> Unix/POSIX data standard. Briefly, <code>Unix Time</code> is a date/time represented as the number of seconds since January 1, 1970 UTC.</p> </li> </ul> <p>In an OCA for Aries OCA Bundle, a <code>dateint</code> and <code>Unix Time</code> attributes MUST have the following values in the indicated overlays:</p> <ul> <li><code>dateint</code></li> <li>datatype <code>DateTime</code> in the Capture Base</li> <li>standard <code>urn:iso:std:iso:1989</code> in the Standard Overlay</li> <li>character encoding <code>utf-8</code> in the Character Encoding Overlay</li> <li>format <code>YYYYMMDD</code> in the Format Overlay</li> <li>Example: <code>20230114</code> for \"January 14, 2023\"</li> <li><code>Unix Time</code></li> <li>datatype <code>DateTime</code> in the Capture Base</li> <li>standard <code>urn:unix:unix-time</code> in the Standard Overlay</li> <li>character encoding <code>utf-8</code> in the Character Encoding Overlay</li> <li>format <code>epoch</code> in the Format Overlay</li> <li>Example: <code>1673715495</code> for \"Sat Jan 14 2023 16:58:15 GMT+0000\"</li> </ul> <p>A recipient of an OCA Bundle with the combination of overlay values referenced above for <code>dateint</code> and <code>Unix Time</code> SHOULD convert the integer attribute data into a date or date/time (respectively) and display the information as appropriate for the user. For example, a mobile app should display the data as a date or date/time based on the user's language/country setting and timezone, possibly combined with an app setting for showing the data in short, medium, long or full form.</p>"},{"location":"features/0755-oca-for-aries/#aries-specific-branding-overlay","title":"Aries Specific \"branding\" Overlay","text":"<p>In addition to the core OCA Overlays listed earlier, Aries issuers MAY include an additional Aries-specific extension overlay, the \"branding\" overlay, that gives the issuer a way to provide a set of data elements about the branding that they would like to see applied to a given type of credential. The <code>branding overlay</code> is similar to the multilanguage Meta overlay (e.g. ones for English, French and Spanish), with a specified set of name/value pairs. Holders (and verifiers) use the branding values from the issuer when rendering a credential of that type according the RFC0756 OCA for Aries Style Guide.</p> <p>An example of the use of the branding overlay is as follows, along with a definition of the name/value pair elements, and a sample image of how the elements are to be used. The sample is provide only to convey the concept of the branding overlay and how it is to be used. Issuers, holders and verifiers should refer to RFC0756 OCA for Aries Style Guide for details on how the elements are to be provided and used in displaying credentials.</p> <pre><code>{\n    \"type\": \"aries/overlays/branding/1.0\"\n    \"digest\": \"EBQbQEV6qSEGDzGLj1CqT4e6yzESjPimF-Swmyltw5jU\",\n    \"capture_base\": \"EKpcSmz06sJs0b4g24e0Jc7OerbJrGN2iMVEnwLYKBS8\",\n    \"logo\": \"https://raw.githubusercontent.com/hyperledger/aries-rfcs/oca4aries../../features/0755-oca-for-aries/best-bc-logo.png\",\n    \"background_image\": \"https://raw.githubusercontent.com/hyperledger/aries-rfcs/oca4aries../../features/best-bc-background-image.png\",\n    \"background_image_slice\": \"https://raw.githubusercontent.com/hyperledger/aries-rfcs/oca4aries../../features/best-bc-background-image-slice.png\",\n    \"primary_background_color\": \"#003366\",\n    \"secondary_background_color\": \"#003366\",\n    \"secondary_attribute\": \"given_names\",\n    \"primary_attribute\": \"family_name\",\n    \"secondary_attribute\": \"given_names\",\n    \"issued_date_attribute\": \"\",\n    \"expiry_date_attribute\": \"expiry_date_dateint\",\n}\n</code></pre> <p></p> <ul> <li>OCA Overlay-related items:</li> <li><code>type</code> - a the type of the overlay, using the <code>aries</code> namespace.</li> <li><code>digest</code> - the self-addressing identifier (SAID) for the overlay. Note that in this example, the SAID is not accurate for the data in the example.</li> <li><code>capture_base</code> - the self-addressing identifier (SAID) for the capture base to which this overlay applies.</li> <li><code>logo</code> - a URI for a logo to display on the credential in some contexts. The URI can be an HTTP URL, a hashlink or, to support inline images, a data URL (e.g.: <code>data:image/png;base64,...</code>) as defined by the Data URL Scheme. The logo MUST adhere to the logo properties defined in RFC0756 OCA for Aries Style Guide.</li> <li><code>background_image</code> - a URI for a background image to display with the credential in some contexts. The URI could be an HTTP URL, a hashlink or, to support inline images, a data URL (e.g.: <code>data:image/png;base64,...</code>) as defined by the Data URL Scheme. The image MUST adhere to the background image properties defined in RFC0756 OCA for Aries Style Guide.</li> <li><code>background_image_slice</code> - a URI for a background image slice to display with the credential in some contexts. The URI could be a HTTP URL, a hashlink or, to support inline images, a data URL (e.g.: <code>data:image/png;base64,...</code>) as defined by the Data URL Scheme. The image MUST adhere to the background image slice properties defined in RFC0756 OCA for Aries Style Guide.</li> <li><code>primary_background_color</code> - hex color code for the primary background color of the   credential to be used in some contexts.</li> <li><code>secondary_background_color</code> - hex color code for the secondary background color of the   credential to be used in some contexts.</li> <li><code>primary_attribute</code> - the name of a capture base attribute to be displayed on   the credential in some contexts.</li> <li><code>secondary_attribute</code> - the name of a capture base attribute to be displayed on   the credential in some contexts.</li> <li><code>issued_date_attribute</code> - the name of a capture base attribute that is the date   of issuance of the credential. If there is no such attribute, leave blank.</li> <li><code>expiry_date_attribute</code> - the name of a capture base attribute that is the   expiry date of the credential. If there is no such attribute, leave blank.</li> </ul> <p>It is deliberate that the credential branding defined in this RFC does not attempt to achieve pixel-perfect on screen rendering of the equivalent paper credential. There are two reasons for this:</p> <ul> <li>First, studies have shown that issuers do not want people to think that the digital credentials they have in their mobile wallet can be used as literal replacements for paper during person-to-person (non-digital) verifications by the holder showing their mobile device screen to the verifier. By showing verifiers their screen, the holder may be oversharing their personal data. As well, digital credentials are even easier to forge than paper credentials when they are to be verified by a human, and we want to discourage using digital credentials in that way.</li> <li>Second, having each issuer provide pixel-perfect layout guidance to Aries agents that supports a responsive user interface on a wide range of devices (laptops, tablets and thousands of mobile phones) is extraordinarily complex. Further, a wallet wanting to provide a consistent, helpful user experience will be severely hampered by displaying credentials with many (perhaps hundreds) of completely different credential layouts and styles.</li> </ul> <p>Instead, the guidance in this RFC and the RFC0756 OCA for Aries Style Guide gives the issuer a few ways to brand their credentials, and holder/verifier apps information on how to use those issuer-provided elements in a manner consistent for all issuers and all credentials.</p>"},{"location":"features/0755-oca-for-aries/#oca-issuer-tools","title":"OCA Issuer Tools","text":"<p>An Aries OCA Bundle can be managed as pure JSON as found in this sample OCA for Aries OCA Bundle. However, managing such multilingual content in JSON is not easy, particularly if the language translations come from team members not comfortable with working in JSON. An easier way to manage the data is to use an OCA source spreadsheet for most of the data, some in a source JSON file, and to use a converter to create the OCA Bundle JSON from the two sources. We recommend that an issuer maintain the spreadsheet file and source JSON in version control and use a pipeline action to generate the OCA Bundle when the source files are updated.</p> <p>The OCA Source Spreadsheet, an example of which is attached to this RFC, contains the following:</p> <ul> <li>An introductory tab about the OCA content in the spreadsheet.</li> <li>A tab with instructions on using the spreadsheet.</li> <li>A \"Main\" tab with the \"Capture Base\" data, along with data for other, non-multilingual overlays.</li> <li>A language or country-language code tab per country-language to be supported by the issuer   containing the source data for all multilingual overlays.</li> </ul> <p>The JSON Source file contains the Aries-specific Branding Overlay. Attached to this RFC is an example Branding Overlay JSON file that issuers can use to start.</p> <p>The following is how to create an OCA Source spreadsheet and from that, generate an OCA Bundle. Over time, we expect that this part of the RFC will be clarified as the tooling evolves.</p> <ul> <li>Creating/Maintaining the Excel File</li> <li>Make a copy of the latest OCA Template from the [Human Colossus Foundation].</li> <li>Fill in the \"Main\" tab with the attributes from the schema, completing the     relevant columns for each attribute. Current columns to complete:<ul> <li>CB-CL: Classification</li> <li>CB-AN: Attribute Name</li> <li>CB-AT: Attribute Type</li> <li>CB-FA: Flagged Attribute</li> <li>OL-CH: Character Encoding</li> <li>OL-FT: Format</li> <li>OL-ST: Standard</li> <li>OL-EC: Entry Codes</li> <li>OL-UT: Unit</li> </ul> </li> <li>As needed, populate the columns for \"dateint\" and \"Unix Time\" attributes as indicated in the Aries Specific Dates in the OCA Formats Overlay section of this document.</li> <li>Rename the sample language tab (<code>en</code>) to one of the language or language-country that as an issuer, you want to support.</li> <li>Fill in the data in columns other than C (which is automatically populated from the <code>Main</code> tab) for the first language as appropriate.</li> <li>Populate column A and B as follows:<ul> <li>In column A (<code>OL-MN: Meta [Attribute Name]</code>), add the values:</li> <li>\"name\"</li> <li>\"description\"</li> <li>\"issuer\"</li> <li>\"issuer_description\"</li> <li>\"issuer_url\"</li> <li>\"credential_help_text\"</li> <li>\"credential_support_url\"</li> <li>\"watermark\"<ul> <li>The \"watermark\" is used to mark non-production credentials, as described in the \"non-production watermark\" section of RFC0756 OCA for Aries Style Guide</li> </ul> </li> <li>Complete column B (<code>OL-MV: Meta [Attribute Value]</code>) as appropriate for each column A name (listed above).</li> </ul> </li> <li>Duplicate and rename the initial language tab for each language or language-country that as an issuer, you want to support.</li> <li>Update each additional language tab.</li> <li>Creating/Maintaining the Branding JSON file</li> <li>Make a copy of the attached example branding JSON file, and update the values for the credential you are issuing.</li> <li>Generating the OCA Bundle from the OCA for Aries Source files:</li> <li>Use the open source OCA Parser from the Human Colossus Foundation to convert the     spreadsheet to JSON. The current command to use is <code>parser parse oca --path &lt;OCA Excel File&gt; &gt; &lt;output Excel JSON OCA Bundle&gt;</code></li> <li>Use the open source jq utility to add the <code>branding.json</code> file to the JSON Excel output to produce the OCA Bundle with the following command, replacing the file names in the command with the ones for your use:<ul> <li><code>jq \".[].overlays += $(cat BRANDING-JSON-FILE)\" OCA-EXCEL-FILE &gt; OCA-BUNDLE-JSON-FILE</code></li> <li>From a command line in this folder, the following command can be run to generate the OCA Bundle JSON to standard output:</li> <li><code>jq \".[].overlays += $(cat branding.json)\" OCA4AriesExcel.json</code></li> </ul> </li> </ul> <p>NOTE: The <code>capture_base</code> and <code>digest</code> fields in the branding overlay of the resulting OCA Bundle JSON file will not be updated to be proper self-addressing identifiers (SAIDs) as required by the OCA Specification. We are looking into how to automate the updating of those data elements.</p> <p>Scripting the generation process should be relatively simple, and our expectation is that the community will evolve the [Parser from the Human Colossus Foundation] to simplify the process further.</p> <p>Over time, we expect to see other tooling become available--notably, a tool for issuers to see what credentials will look like when their OCA Bundle is applied.</p>"},{"location":"features/0755-oca-for-aries/#issuing-a-credential","title":"Issuing A Credential","text":"<p>This section of the specification remains under consideration. The use of the <code>credential supplement</code> as currently described here is somewhat problematic for a number of reasons.</p> <ul> <li>The issuer has no way to update the OCA Bundle for a given holder after   issueance. We see this as a likely use case to enable, for example, an   issuer supporting additional languages over time.</li> <li>The \"External Attachments\" risk, as described in this section of this   RFC.</li> <li>The complicated way for a verifier to get an OCA Bundle when needed after a   presentation.</li> </ul> <p>We are currently investigating if an OCA Bundle can be published to the same VDR as holds an AnonCreds Schema or Credential Definition. We think that would overcome each of those concerns and make it easier to both publish and retrieve OCA Bundles.</p> <p>The currently preferred mechanism for an issuer to provide an OCA Bundle to a holder is when issuing a credential using RFC0453 Issue Credential, version 2.2 or later, the issuer provides, in the credential offer message, an OCA Bundle as a credential supplement.</p> <ul> <li>The supplement type MUST be <code>oca-bundle</code>.</li> <li>The OCA Bundle MUST be in the JSON form of an OCA Bundle, not the ZIP format.</li> <li>The attachment MUST be signed by the issuer, and may be of type <code>base64url</code>, meaning the OCA Bundle is embedded in the message, or of type <code>link</code>.</li> </ul> <p>The reason OCA Bundle attachment must be signed by the issuer so that if the holder passes the OCA Bundle on to the verifier, the verifier can be certain that the issuer provided the OCA Bundle, and that it was not created by a malicious holder.</p> <p>Issuers should be aware that to ensure that the signature on a linked OCA Bundle (using the attachment type <code>link</code>) remains verifiable, the content resolved by the link must not change over time. For example, an Issuer might publish their OCA Bundles in a public GitHub repository, and send a link to the OCA Bundle during issuance. In that case the Issuer is advised to send a commit-based GitHub URL, rather than a branch-based reference. The Issuer may update the OCA Bundle sent to different holders over time, but once issued, each OCA Bundle MUST remain accessible.</p>"},{"location":"features/0755-oca-for-aries/#warning-external-attachments","title":"Warning: External Attachments","text":"<p>The use of an attachment of type <code>link</code> for the OCA Bundle itself, or the use of external references to the images in the branding Overlay could provide malicious issuers with a mechanism for tracking the use of a holder's verifiable credential. Specifically, the issuer could:</p> <ul> <li>Make any or all of the OCA bundle external references a unique identifier for   the holder.</li> <li>When the holder retrieves the OCA bundle, the issuer does not learn anything   useful as they already know they have issued a credential to that holder.</li> <li>If the holder passes the OCA bundle to verifiers and the verifiers resolve the   external references, the malicious issuer would learn that the holder has used   their verifiable credential in a presentation, and perhaps, with what verifier.</li> </ul> <p>A holder MAY choose not to attach an OCA Bundle to a verifier if it contains any external references. Non-malicious issuers are encouraged to not use external references in their OCA Bundles and as such, to minimize the inlined images in the branding overlay.</p>"},{"location":"features/0755-oca-for-aries/#holder-activities","title":"Holder Activities","text":"<p>Before processing a credential and an associated OCA Bundle, the holder SHOULD determine if the issuer is known in an ecosystem and has a sufficiently positive reputation. For example, the holder might determine if the issuer is in a suitable Trust Registry or request a presentation from the issuer about their identity.</p> <p>On receipt of a credential with an OCA Bundle supplement, the holder SHOULD retrieve the OCA Bundle attachment, verify the signature is from the issuer's public DID, verify the signature, and verify that the [OCA Capture Base] is for the credential being offered or issued to the holder. If verified, the holder should associate the OCA Bundle with the credential, including the signature.</p> <p>The holder SHOULD take appropriate security precautions in handling the remainder of the OCA data, especially the images as they could contain a malicious payload. The security risk is comparable to a browser receiving a web page containing images.</p> <p>Holder software should be implemented to use the OCA Bundle when processing and displaying the credential as noted in the list below. Developers of holder software should be familiar with the overlays the issuer is likely to provide (see list here) and how to use them according to RFC0756 OCA for Aries Style Guide.</p> <ul> <li>Check the country and language settings of the current user and use the appropriate multilingual overlays to respect those settings in displaying credential metadata and attributes (labels, etc.).</li> <li>Consider adding multilingual informational popups in your app using the per   attribute data in the \"information\" overlay.</li> <li>Consider using the PII flag in the Capture Base to provide guidance to the   user about the sharing of PII.</li> <li>Use the branding overlay and RFC0756 OCA for Aries Style Guide in   displaying the credential in various contexts (e.g., in a credential offer   prompt, in a list, selected from a list, alone on a page, etc.).</li> <li>Process the attribute data using the <code>type</code>, <code>character encoding</code>, <code>format</code>,   <code>unit</code> and <code>standard</code> overlays and display tha attributes appropriately for a   given user. For example, display dates in a form suitable for the language and   country settings of the user.</li> <li>Where enumerated names are used for credential attributes, retrieve and use   the name-value pairs in the Entry Code Overlay and Entry Overlay to display the data.</li> <li>Use the OCA-provide metadata about the credential, such as the   name/description of the issuer, name/description of the credential type.</li> </ul> <p>A recommended tactic when adding OCA support to a holder is when a credential is issued without an associated OCA Bundle, generate an OCA Bundle for the credential using the information available about the type of the credential, default images, and randomly generated colors. That allows for the creation of screens that assume an OCA Bundle is available. The RFC0756 OCA for Aries Style Guide contains guidelines for doing that.</p>"},{"location":"features/0755-oca-for-aries/#adding-oca-bundles-to-present-proof-messages","title":"Adding OCA Bundles to Present Proof Messages","text":"<p>Once a holder has an OCA Bundle that was issued with the credential, it MAY pass the OCA Bundle to a verifier when a presenting a proof that includes claims from that credential. This can be done via the present proof credential supplements approach, similar to what used when the credential was issued to the holder. When constructing the <code>present_proof</code> message to hold a proof, the holder would iterate through the credentials in the proof, and if there is an issuer-supplied OCA Bundle for the credentials, add the OCA Bundle as a supplement to the message. The signature from the Issuer MUST be included with the supplement.</p> <p>A holder SHOULD NOT send an OCA Bundle to a verifier if the OCA Bundle is a link, or if any of the data items in the OCA Bundle are links, as noted in the in the warning about external attachments in OCA Bundles.</p>"},{"location":"features/0755-oca-for-aries/#verifier-activities","title":"Verifier Activities","text":"<p>On receipt of a presentation with OCA Bundle supplements, the verifier SHOULD retrieve the OCA Bundle attachments, verify the signatures are from the credential issuers' public DIDs, verify the signatures, and verify that the [OCA Capture Base] is for the credentials being presented to the verifier. If verified, the verifier should associate the OCA Bundle with the source credential from the presentation.</p> <p>On receipt of a presentation with OCA Bundle supplements, the verifier MAY process the OCA Bundle attachment and verify the issuer's signature. If it verifies, the verifier should associate the OCA Bundle with the source credential from the presentation. The verifier SHOULD take appropriate security precautions in handling the data, especially the images. The holder software should be implemented to use the OCA Bundle when processing and displaying the credential as noted in the list below.</p> <p>Developers of verifier software should be familiar with the overlays the issuer is likely to provide (see list here) and how to use them according to RFC0756 OCA for Aries Style Guide. The list of how to use the OCA Bundle as a holder applies equally to verifiers.</p>"},{"location":"features/0755-oca-for-aries/#reference","title":"Reference","text":"<ul> <li>The OCA Specification</li> <li>RFC0756 OCA for Aries Style Guide</li> </ul>"},{"location":"features/0755-oca-for-aries/#drawbacks","title":"Drawbacks","text":"<ul> <li>The use of credential supplements might not be the best way to publish OCA   Bundles. The Aries community is currently investigating if OCA Bundles can be   published to the Verifiable Data Registry upon which the schema and credential   definition are published.</li> <li>As noted in this warning, the use of links   either for OCA Bundles or for the images that are embedded in OCA Bundles are   both extremely useful and problematic. It would be nice to be able to allow   links for/in the OCA Bundles without the potential of being used to track the   holder.</li> <li>If the OCA Bundle is passed to the holder as a link, the issuer must continue   to make that content available for as long as the holder might retain the   credential. Putting the OCA Bundle on a verifiable data registry (such as a   ledger/blockchain) might be a good way to publish such data.</li> <li>The processing of an OCA Bundle, and particularly the processing of images in   the branding overlay, provide an attack vector for malicious issuers.   Developers of holder software SHOULD take precautions in handling and   displaying the data.</li> </ul>"},{"location":"features/0755-oca-for-aries/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<ul> <li>The OCA architecture seems well suited to the Aries verifiable credential use case, supporting the important capabilities of data formats, accessibility support, multilingual support and the desire for issuers to brand their credentials.</li> <li>The use of JSON-LD could provide some of the required capabilities covered by OCA (such as multilingual labels), but that solution requires adding considerable overhead and far more complicated processing to achieve a minimum of the capabilities available through OCA.</li> <li>The current situation of having almost no metadata about credentials is extremely limiting.</li> <li>Extracting best available metadata from the Schema and Credential Definition     objects, converting developer attribute/credential names of human friendly     (e.g. \"given_name\" to Given Name, or \"ssn\" to \"Ssn\") and using that for the     display of a credential.</li> <li>The random generation of a background color for a given credential for use   when displaying a credential.</li> <li>There are other flows that could be used to get an OCA Bundle to holders and verifiers.</li> <li>A publisher of a schema might also publish an OCA Bundle based on the schema, for anyone to use.</li> <li>An Aries agent vendor (such as the creator of an Aries mobile wallet) might create a repository of OCA Bundles of common credential types for deployments of their agent.</li> <li>When using such alternatives, agents retrieving an OCA Bundle should have a way to verify the source of the OCA Bundle, such as having a cryptographic signature over the OCA Bundle from the designated publisher.</li> </ul>"},{"location":"features/0755-oca-for-aries/#prior-art","title":"Prior art","text":"<p>None, as far as we are aware.</p>"},{"location":"features/0755-oca-for-aries/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Are there better ways for issuers to publish OCA Bundles for consumption by   holders/verifiers?</li> <li>How do we balance the prevention of possible tracking by issuers, and the use   of links to OCA Bundles or assets within OCA Bundles.</li> </ul>"},{"location":"features/0755-oca-for-aries/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0756-oca-for-aries-style-guide/","title":"0756: OCA for Aries Style Guide","text":"<ul> <li>Authors: Stephen Curran</li> <li>Status: DEMONSTRATED</li> <li>Since: 2023-01-05</li> <li>Status Note: Implemented in the Bifold Wallet</li> <li>Supersedes: N/A</li> <li>Start Date: 2022-11-15</li> <li>Versions: 1.0 and 1.1</li> <li>Tags: feature</li> </ul>"},{"location":"features/0756-oca-for-aries-style-guide/#summary","title":"Summary","text":"<p>Support for credential branding in Aries agents is provided by information provided from the issuer of a given credential type using Overlays Capture Architecture (OCA) overlays. Aries agents (software) use the issuer-provided OCA data when displaying (rendering) the issuer\u2019s credential on screens. This style guide is for issuers to know what information to include in the OCA overlays and how those elements will be used by holders and verifiers. The style guide is also for Aries holder and verifier software makers about how to use the OCA data provided from issuers for a given credential type. It is up to the software makers to use OCA data provided by the issuers as outlined in this guide.</p> <p>There are 2 versions of the OCA that can be used. Version 1.1 does not remove version 1.0, but rather propose a different view for credential layout. It is to the wallet maintainer to chose which one would be used in their application.</p> <p>For more information about the use of OCA in Aries, please see RFC0755 OCA for Aries</p>"},{"location":"features/0756-oca-for-aries-style-guide/#motivation","title":"Motivation","text":"<p>OCA Bundles is intended to be used by ALL Aries issuers and ALL Aries Holders. Some Aries verifiers might also use OCA Bundles. This Style Guide provides guidance for issuers about what overlays to populate and with what information, and guidance for holders (and verifiers) about how to use the OCA Bundle data provided by the issuers when rendering Credentials on screen.</p> <ul> <li>Issuers SHOULD follow this Style Guide in preparing an OCA Bundle for each   credential type they issue. Holders (and verifiers) expect issuers to follow   the guidance provided in this RFC.</li> <li>Holder creators (and verifiers) SHOULD follow this Style Guide in   rendering credentials for users. Issuers expect holders (and verifiers) to   follow the guidance provided in this RFC.</li> </ul> <p>Issuers, holders and verifiers expect other issuers, holders and verifiers to follow this Style Guide. Issuers, holders and verifiers not following this Style Guide will likely cause end users to see unpredictable and potential \"unfriendly\" results when credentials are displayed.</p> <p>It is in the best interest of the Aries community as a whole for those writing Aries agent software to use OCA Bundles and to follow this Style Guide in displaying credentials.</p>"},{"location":"features/0756-oca-for-aries-style-guide/#tutorial","title":"Tutorial","text":"<p>Before reviewing this Style Guide, please review and be familiar with RFC0755 OCA for Aries. It provides the technical details about OCA, the issuer role in creating an OCA Bundle and delivering to holders (and optionally, from holders to verifiers) and the holders role in extracting information from the OCA Bundle about a held credential. This Style Guide provides the details about what each participant is expected to do in creating OCA Bundles and using the data in OCA Bundles to render credentials on screen.</p>"},{"location":"features/0756-oca-for-aries-style-guide/#oca-for-aries-style-guide","title":"OCA for Aries Style Guide","text":"<p>A Credential User Interface (UI) pulls from a issuer-provided OCA Bundle the following elements:</p> <ul> <li>Meta Overlays (multilingual):<ul> <li>Credential name</li> <li>Issuer name</li> <li>Issuer description</li> <li>Issuer URL</li> <li>Credential help text</li> <li>Credential support URL</li> <li>Non-Production watermark</li> </ul> </li> <li>\u201cbranding\u201d Overlay:<ul> <li>logo - a URI for an inline or external logo image to display with the credential. See details below about the use and requirements for the image.</li> <li>background_image -  a URI for an inline or external background image to display with the credential. See details below about the use and requirements for the image.</li> <li>background_image_slice -  a URI for an inline or external background image slice to display with the credential. See details below about the use and requirements for the image.</li> <li>primary_background_color - an RGB color code for the credential background</li> <li>secondary_background_color - an RGB color code for the credential background highlight background color.</li> <li>primary_attribute - the name of the primary capture base attribute to display \\ on the credential.</li> <li>secondary_attribute - the name of the secondary capture base attribute to \\ display on the credential.</li> <li>issued_date_attribute - the name of a capture base attribute that is the date of issuance of the credential. If there is no such attribute, leave it blank.</li> <li>expiry_date_attribute - the name of a capture base attribute that is the expiry date of the credential. If there is no such attribute, leave it blank.</li> </ul> </li> </ul>"},{"location":"features/0756-oca-for-aries-style-guide/#credential-layouts","title":"Credential Layouts","text":"<p>This style guide defines three layouts for credentials, the credential list layout, the stacked list layout, and the single credential layout. Holders and verifiers SHOULD display credentials using only these layouts in the context of a screen containing either a list of credentials or a single credential, respectively. Holders and verifiers MAY display other relevant information on the page along with one of the layouts.</p> <p>The stacked list is the same as the credential layout, with the credentials that are stacked cutoff between elements 6 and 7. Examples of the stacked layout can be seen in the Stacking section of this document. In the Stacked layout, one of the credentials in the stack may be displayed using the full credential list layout.</p> <p>Version 1.0</p> Credential List Layout Single Credential Layout <p>Version 1.1</p> Credential List Layout Single Credential Layout <p>Figure: Credential Layouts</p> <p>The numbered items in the layouts are as follows. In the list, the OCA data element(s) is provided first, and, where the needed data element(s) is not available through an OCA Bundle, a calculation for a fallback is defined. It is good practice to have code that populates a per credential data structure with data from the credential\u2019s OCA Bundle if available, and if not, populated by the fallbacks. That way, the credentials are displayed in the same way with or without an OCA Bundle per credential. Unless noted, all of the data elements come from the \u201cbranding\u201d overlay. Items 10 and 11 are not included in the layouts but are included to document the fallbacks for those values.</p> <ol> <li><code>logo</code><ul> <li>Fallback: First letter of the alias of the DIDComm connection</li> </ul> </li> <li><code>background_image_slice</code> if present, else <code>secondary_background_color</code><ul> <li>Fallback: Black overlay at 24% opacity</li> </ul> </li> <li><code>primary_background_color</code><ul> <li>Fallback: Randomly generated color</li> </ul> </li> <li>Credential Status derived from revocation status and expiry date (if available)<ul> <li>Fallback: Empty</li> </ul> </li> <li>Meta overlay item <code>issuer_name</code><ul> <li>Fallback: Alias of the DIDComm connection</li> </ul> </li> <li>Meta overlay item <code>name</code><ul> <li>Fallback: The AnonCreds Credential Definition <code>tag</code>, unless the value is either <code>credential</code> or <code>default</code>, otherwise the AnonCreds <code>schema_name</code> attribute from the AnonCreds schema</li> </ul> </li> <li><code>primary_attribute</code><ul> <li>Fallback: Empty</li> </ul> </li> <li><code>secondary_attribute</code><ul> <li>Fallback: Empty</li> </ul> </li> <li><code>background_image</code> if present, else <code>secondary_background_color</code><ul> <li>Fallback: Black overlay at 24% opacity (default)</li> </ul> </li> <li><code>issued_date_attribute</code><ul> <li>Fallback: If tracked, the date the credential was received by the Holder, else empty.</li> </ul> </li> <li><code>expiry_date_attribute</code><ul> <li>Fallback: Empty</li> </ul> </li> </ol> <p>added with version 1.1</p> <ol> <li><code>Contact detail button</code><ul> <li>Fallback: Empty</li> </ul> </li> </ol> <p>Version 1.0</p> <p></p> <p>Version 1.1 </p> <p>Figure: Template layers</p> <p>The font color is either black or white, as determined by calculating contrast levels (following Web Content Accessibility Guidelines) against the background colors from either the OCA Bundle or the generated defaults.</p> <p>Version 1.0</p> <p>Version 1.1</p> <p>Figure: example of a credential with no override specifications</p>"},{"location":"features/0756-oca-for-aries-style-guide/#logo-image-specifications","title":"Logo Image Specifications","text":"<p>This space should not be used for anything other than the issuer logo. The logo image may be masked to fit within a rounded square with varying corner radii. Thus, the logo must be a square image (aspect ratio 1:1), as noted in the table below. The background is default white, therefore logo files with a transparent background will overlay a white background.</p> <p>For version 1.0, the issuer logo is located at the top left of the credential.</p> <p>With version 1.1, the issuer logo is located on the bottom of the credential, left of the issuer's name.</p> <p>The following are the specifications for the credential logo for issuers. </p> <p>Images should be as small as possible to balance quality and download speed. To ensure image quality on all devices, it is recommended to use vector based file types such as SVG. </p> Preferred file type     SVG, JPG, PNG with transparent background,      Aspect ratio     1:1     Recommended image size     240x240 px     Color space     RGB"},{"location":"features/0756-oca-for-aries-style-guide/#background-image-slice-specifications","title":"Background Image Slice Specifications","text":"<p>For issuers to better represent their brand, issuers may specify an image slice that will be used as outlined in the samples below. Note the use of the image in a long, narrow space and the dynamic height. The image slice will be top aligned, scaled (preserving aspect ratio) and cropped as needed to fill the space.</p> <p>Credential height is dependent on the content and can be unpredictable. Different languages (English, French, etc.) will add more length to names, OS level settings such as font changes or text enlargement will unpredictably change the height of the credential. The recommended image size below is suggested to accommodate for most situations. Note that since the image is top aligned, the top area of the image is certain to be displayed, while the bottom section of the image may not always be visible. </p> <p>Version 1.0</p> <p></p> <p>Version 1.1</p> <p></p> <p>Figure: Examples of the image slice behavior</p> <p>Types of images best used in this area are abstract images or graphical art. Do not use images that are difficult to interpret when cropped.</p> <p>Version 1.0</p> Do <p> Use an abstract image that can work even when cropped unexpectedly.      Don\u2019t <p> Use images that are hard to interpret when cropped. Avoid words     <p>Version 1.1</p> Do <p> Use an abstract image that can work even when cropped unexpectedly.      Don\u2019t <p> Use images that are hard to interpret when cropped. Avoid words     <p>Figure: Background image slice Do\u2019s and Don\u2019ts</p> Preferred file type     SVG, PNG, JPG     Aspect ratio     1:10     Recommended image size     120x1200 px     Color space     RGB"},{"location":"features/0756-oca-for-aries-style-guide/#background-image-specifications","title":"Background Image Specifications","text":"<p>The background image is to give issuers more opportunities to represent their brand and is used in some credential display screens. Avoid text in the background image.</p> <p>Version 1.0</p> Do <p> Use an image that represents your brand.     Don\u2019t <p> Use this image as a marketing platform. Avoid the use of text.     <p>Version 1.1</p> Do <p> Use an image that represents your brand.     Don\u2019t <p> Use this image as a marketing platform. Avoid the use of text.     <p>Figure: Background image Do\u2019s and Don\u2019ts</p> Preferred file type     SVG, PNG, JPG     Aspect ratio     3:1     Recommended image size     1080x360 px     Color space     RGB"},{"location":"features/0756-oca-for-aries-style-guide/#credential-status","title":"Credential Status","text":"<p>To reduce visual clutter, the issued date (if present), expiry date (if present), and revocation status (if applicable) may be interpreted by an icon at the top right corner when:</p> <ul> <li>A new credential has been added, based on issued_date_attribute, if set, or for a holder agent/wallet, the date the credential was received.</li> <li>A credential is revoked, if the credential is revocable and is known to have been revoked.</li> <li>A credential is expiring soon or expired, based on expiry_date_attribute, if set.</li> </ul> <p>Version 1.0</p> <p></p> <p>Version 1.1</p> <p></p> <p>Figure: An example demonstrating how the revocation date, expiry date or issued date may be represented.</p> <p>The interpretation of the issued date, expiry date and revocation status may be dependent on the holder software, such as a wallet. For example, the specific icons used may vary by wallet, or the full status data may be printed over the credential.</p>"},{"location":"features/0756-oca-for-aries-style-guide/#credential-name-and-issuer-name-guidelines","title":"Credential name and Issuer name guidelines","text":"<p>Issuers should be mindful of the length of text on the credential as lengthy text will dynamically change the height of the credential. Expansive credentials risk reducing the number of fully visible credentials in a list.</p> <p>Version 1.0 </p> <p></p> <p>Version 1.1 </p> <p></p> <p>Figure: An example demonstrating how lengthy credentials can limit the number of visible credentials.</p> <p>Be mindful of other factors that may increase the length of text and hence, the height of the credential such as translated languages or the font size configured at the OS level.</p> <p>Version 1.0</p> <p></p> <p>Version 1.1</p> <p></p> <p>Figure: Examples showing the treatment of lengthy names</p>"},{"location":"features/0756-oca-for-aries-style-guide/#primary-and-secondary-attribute-guidelines","title":"Primary and Secondary Attribute Guidelines","text":"<p>If issuers expect people to hold multiples of their credentials of the same type, they may want to specify a primary and secondary attribute to display on the card face. </p> <p>Note that wallet builders or holders may limit the visibility of the primary and secondary attributes on the card face to mitigate privacy concerns. Issuers can expect that these attributes may be fully visible, redacted, or hidden.</p> <p>To limit personal information from being displayed on a card face, only specify what is absolutely necessary for wallet holders to differentiate between credentials of the same type. Do not display private information such as medical related attributes.</p> <p>Version 1.0</p> Do <p> Use attributes that help users identify their credentials. Always consider if a primary and secondary attribute is absolutely necessary.     Don\u2019t <p> Display attributes that contain private information.     <p>Version 1.1</p> Do <p> Use attributes that help users identify their credentials. Always consider if a primary and secondary attribute is absolutely necessary.     Don\u2019t <p> Display attributes that contain private information.     <p>Figure: Primary/secondary attribute Do\u2019s and Don\u2019ts</p>"},{"location":"features/0756-oca-for-aries-style-guide/#non-production-watermark","title":"Non-production watermark","text":"<p>To identify non-production credentials, issuers can add a watermark to their credentials. The watermark is a simple line of text that can be customized depending on the issuer needs. The line of text will also appear as a prefix to the credential name. The line of text should be succinct to ensure legibility. This watermark is not intended to be used for any other purpose than to mark non-production credentials. Ensure proper localization to the watermark is present in all languages.</p> <p>Example text include:</p> <ul> <li>DEMO</li> <li>SAMPLE</li> <li>NON-PRODUCTION</li> <li>TEST</li> <li>DEVELOPMENT</li> <li>DO NOT USE </li> </ul> <p>Version 1.0</p> Do <p> Use succinct words to describe the type of issued credential. This ensures legibility and does not increase the size of the credential unnecessarily.     Don\u2019t <p> Use long works or words that do not describe non-production credentials.     <p>Version 1.1</p> Do <p> Use succinct words to describe the type of issued credential. This ensures legibility and does not increase the size of the credential unnecessarily.     Don\u2019t <p> Use long works or words that do not describe non-production credentials."},{"location":"features/0756-oca-for-aries-style-guide/#credential-resizing","title":"Credential resizing","text":"<p>Credential size depends on the content of the credential and the size of the device. Text areas are resized according to the width. </p> <p>Version 1.0</p> <p></p> <p>Version 1.1</p> <p></p> <p>Figure: Treatment of the credential template on different devices</p> <p>Version 1.0</p> <p></p> <p>Version 1.1</p> <p></p> <p>Figure: An example of credential on different devices</p>"},{"location":"features/0756-oca-for-aries-style-guide/#stacking","title":"Stacking","text":"<p>Credentials may be stacked to overlap each other to increase the number of visible credentials in the viewport. The header remains unchanged. The issuer name, logo and credential name will always be visible, but the primary and secondary attributes and the image slice will be obscured. </p> <p>In version 1.1, the credential name will always be visible. The issuer name, logo, attributes and the image slice will be obscured. </p> <p>Version 1.0</p> <p></p> <p>Version 1.1</p> <p></p> <p>Figure: An example of stacked credentials with default and enlarged text.</p>"},{"location":"features/0756-oca-for-aries-style-guide/#accessibility","title":"Accessibility","text":"<p>The alt-tags for the logo and background images come from the multilingual OCA Meta Overlay for the issuer name and credential type name. </p>"},{"location":"features/0756-oca-for-aries-style-guide/#more-variations","title":"More Variations","text":"<p>To view more credential variations using this template, view the Adobe XD file.</p>"},{"location":"features/0756-oca-for-aries-style-guide/#drawbacks","title":"Drawbacks","text":"<p>Defining and requesting adherence to a style guide is a lofty goal. With so many independent issuers, holders and verifiers using Aries, it is a challenge to get everyone to agree on a single way to display credentials for users. However, the alternative of everyone \"doing their own thing\", perhaps in small groups, will result in a poor experience for users, and be frustrating to both issuers trying to convey their brand, and holders (and verifiers) trying to create a beautiful experience for their users.</p>"},{"location":"features/0756-oca-for-aries-style-guide/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>In coming up with this Style Guide, we consider how much control to give issuers, ultimately deciding that given them too much control (e.g., pixel precise layout of their credential) creates a usage/privacy risk (people using their credentials by showing them on screen, with all private data showing), is technical extremely difficult given the variations of holder devices, and likely to result in a very poor user experience.</p> <p>A user experience group in Canada came up with the core design, and the Aries Working Group reviewed and approved of the Style Guide.</p>"},{"location":"features/0756-oca-for-aries-style-guide/#prior-art","title":"Prior art","text":"<p>The basic concept of giving issuers a small set of parameters that they could control in branding of their data is used in many applications and communities. Relevant to the credential use case is the application of this concept in the Apple Wallet and Google Wallet. Core to this is the setting of expectations of all of the participants of how their data will be used, and how to use the data provided. In the Aries holder (and verifier) case, unlike that of the Apple Wallet and Google Wallet, is that there is not just one holder that is using the data from many issuers to render the data on screen, but many holders that are expected to adhere to this Style Guide.</p>"},{"location":"features/0756-oca-for-aries-style-guide/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>A challenge will be in evolving this Style Guide based on new input from those that use it over time. We expect the Aries RFC version process to be sufficient. However, this is the first time that this process has been applied to a user experience \"protocol\", as opposed to a technical, messaging protocol.</li> </ul>"},{"location":"features/0756-oca-for-aries-style-guide/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0771-anoncreds-attachments/","title":"Aries RFC 0771: AnonCreds Attachment Formats for Requesting and Presenting Credentials","text":"<ul> <li>Authors: Timo Glastra, Daniel Hardman</li> <li>Status: PROPOSED</li> <li>Since: 2023-02-24</li> <li>Status Note: Formalizes the AnonCreds attachments for issuing credentials and presenting proofs over DIDComm.</li> <li>Supersedes: Hyperledger Indy specific AnonCreds attachment formats documented in Aries RFC 0592.</li> <li>Start Date: 2023-02-24</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0771-anoncreds-attachments/#summary","title":"Summary","text":"<p>This RFC registers attachment formats used with Hyperledger AnonCreds ZKP-oriented credentials in the Issue Credential Protocol 2.0 and Present Proof Protocol 2.0. If not specified otherwise, this follows the rules as defined in the AnonCreds Specification.</p>"},{"location":"features/0771-anoncreds-attachments/#motivation","title":"Motivation","text":"<p>Allows AnonCreds credentials to be used with credential-related protocols that take pluggable formats as payloads.</p>"},{"location":"features/0771-anoncreds-attachments/#reference","title":"Reference","text":""},{"location":"features/0771-anoncreds-attachments/#credential-filter-format","title":"Credential Filter format","text":"<p>The potential holder uses this format to propose criteria for a potential credential for the issuer to offer. The format defined here is not part of the AnonCreds spec, but is a Hyperledger Aries-specific message.</p> <p>The identifier for this format is <code>anoncreds/credential-filter@v1.0</code>. The data structure allows specifying zero or more criteria from the following structure:</p> <pre><code>{\n  \"schema_issuer_id\": \"&lt;schema_issuer_id&gt;\",\n  \"schema_name\": \"&lt;schema_name&gt;\",\n  \"schema_version\": \"&lt;schema_version&gt;\",\n  \"schema_id\": \"&lt;schema_identifier&gt;\",\n  \"issuer_id\": \"&lt;issuer_id&gt;\",\n  \"cred_def_id\": \"&lt;credential_definition_identifier&gt;\"\n}\n</code></pre> <p>The potential holder may not know, and need not specify, all of these criteria. For example, the holder might only know the schema name and the (credential) issuer id. Recall that the potential holder may specify target attribute values and MIME types in the credential preview.</p> <p>For example, the JSON structure might look like this:</p> <pre><code>{\n  \"schema_issuer_id\": \"did:sov:4RW6QK2HZhHxa2tg7t1jqt\",\n  \"schema_name\": \"bcgov-mines-act-permit.bcgov-mines-permitting\",\n  \"issuer_id\": \"did:sov:4RW6QK2HZhHxa2tg7t1jqt\"\n}\n</code></pre> <p>A complete <code>propose-credential</code> message from the Issue Credential protocol 2.0 embeds this format as an attachment in the <code>filters~attach</code> array:</p> <pre><code>{\n  \"@id\": \"&lt;uuid of propose message&gt;\",\n  \"@type\": \"https://didcomm.org/issue-credential/%VER/propose-credential\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"&lt;attach@id value&gt;\",\n      \"format\": \"anoncreds/credential-filter@v1.0\"\n    }\n  ],\n  \"filters~attach\": [\n    {\n      \"@id\": \"&lt;attach@id value&gt;\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"ewogICAgInNjaGVtYV9pc3N1ZXJfZGlkIjogImRpZDpzb3Y... (clipped)... LMkhaaEh4YTJ0Zzd0MWpxdCIKfQ==\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0771-anoncreds-attachments/#credential-offer-format","title":"Credential Offer format","text":"<p>This format is used to clarify the structure and semantics (but not the concrete data values) of a potential credential, in offers sent from issuer to potential holder.</p> <p>The identifier for this format is <code>anoncreds/credential-offer@v1.0</code>. It must follow the structure of a Credential Offer as defined in the AnonCreds specification.</p> <p>The JSON structure might look like this:</p> <pre><code>{\n    \"schema_id\": \"4RW6QK2HZhHxa2tg7t1jqt:2:bcgov-mines-act-permit.bcgov-mines-permitting:0.2.0\",\n    \"cred_def_id\": \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    \"nonce\": \"57a62300-fbe2-4f08-ace0-6c329c5210e1\",\n    \"key_correctness_proof\" : &lt;key_correctness_proof&gt;\n}\n</code></pre> <p>A complete <code>offer-credential</code> message from the Issue Credential protocol 2.0 embeds this format as an attachment in the <code>offers~attach</code> array:</p> <pre><code>{\n    \"@type\": \"https://didcomm.org/issue-credential/%VER/offer-credential\",\n    \"@id\": \"&lt;uuid of offer message&gt;\",\n    \"replacement_id\": \"&lt;issuer unique id&gt;\",\n    \"comment\": \"&lt;some comment&gt;\",\n    \"credential_preview\": &lt;json-ld object&gt;,\n    \"formats\" : [\n        {\n            \"attach_id\" : \"&lt;attach@id value&gt;\",\n            \"format\": \"anoncreds/credential-offer@v1.0\"\n        }\n    ],\n    \"offers~attach\": [\n        {\n            \"@id\": \"&lt;attach@id value&gt;\",\n            \"mime-type\": \"application/json\",\n            \"data\": {\n                \"base64\": \"ewogICAgInNjaGVtYV9pZCI6ICI0Ulc2UUsySFpoS... (clipped)... jb3JyZWN0bmVzc19wcm9vZj4KfQ==\"\n            }\n        }\n    ]\n}\n</code></pre>"},{"location":"features/0771-anoncreds-attachments/#credential-request-format","title":"Credential Request format","text":"<p>This format is used to formally request a credential. It differs from the Credential Offer above in that it contains a cryptographic commitment to a link secret; an issuer can therefore use it to bind a concrete instance of an issued credential to the appropriate holder. (In contrast, the credential offer describes the schema and cred definition, but not enough information to actually issue to a specific holder.)</p> <p>The identifier for this format is <code>anoncreds/credential-request@v1.0</code>. It must follow the structure of a Credential Request as defined in the AnonCreds specification.</p> <p>The JSON structure might look like this:</p> <pre><code>{\n    \"entropy\" : \"e7bc23ad-1ac8-4dbc-92dd-292ec80c7b77\",\n    \"cred_def_id\" : \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    // Fields below can depend on Cred Def type\n    \"blinded_ms\" : &lt;blinded_master_secret&gt;,\n    \"blinded_ms_correctness_proof\" : &lt;blinded_ms_correctness_proof&gt;,\n    \"nonce\": \"fbe22300-57a6-4f08-ace0-9c5210e16c32\"\n}\n</code></pre> <p>A complete <code>request-credential</code> message from the Issue Credential protocol 2.0 embeds this format as an attachment in the <code>requests~attach</code> array:</p> <pre><code>{\n  \"@id\": \"cf3a9301-6d4a-430f-ae02-b4a79ddc9706\",\n  \"@type\": \"https://didcomm.org/issue-credential/%VER/request-credential\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"7cd11894-838a-45c0-a9ec-13e2d9d125a1\",\n      \"format\": \"anoncreds/credential-request@v1.0\"\n    }\n  ],\n  \"requests~attach\": [\n    {\n      \"@id\": \"7cd11894-838a-45c0-a9ec-13e2d9d125a1\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"ewogICAgInByb3Zlcl9kaWQiIDogImRpZDpzb3Y6YWJjeHl.. (clipped)... DAtNTdhNi00ZjA4LWFjZTAtOWM1MjEwZTE2YzMyIgp9\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0771-anoncreds-attachments/#credential-format","title":"Credential format","text":"<p>A concrete, issued AnonCreds credential may be transmitted over many protocols, but is specifically expected as the final message in Issuance Protocol 2.0. The identifier for this format is <code>anoncreds/credential@v1.0</code>.</p> <p>This is a credential that's designed to be held but not shared directly. It is stored in the holder's wallet and used to derive a novel ZKP or W3C-compatible verifiable presentation just in time for each sharing of credential material.</p> <p>The encoded values of the credential MUST follow the encoding algorithm as described in Encoding Attribute Data. It must follow the structure of a Credential as defined in the AnonCreds specification.</p> <p>The JSON structure might look like this:</p> <pre><code>{\n    \"schema_id\": \"4RW6QK2HZhHxa2tg7t1jqt:2:bcgov-mines-act-permit.bcgov-mines-permitting:0.2.0\",\n    \"cred_def_id\": \"4RW6QK2HZhHxa2tg7t1jqt:3:CL:58160:default\",\n    \"rev_reg_id\", \"EyN78DDGHyok8qw6W96UBY:4:EyN78DDGHyok8qw6W96UBY:3:CL:56389:CardossierOrgPerson:CL_ACCUM:1-1000\",\n    \"values\": {\n        \"attr1\" : {\"raw\": \"value1\", \"encoded\": \"value1_as_int\" },\n        \"attr2\" : {\"raw\": \"value2\", \"encoded\": \"value2_as_int\" }\n    },\n    // Fields below can depend on Cred Def type\n    \"signature\": &lt;signature&gt;,\n    \"signature_correctness_proof\": &lt;signature_correctness_proof&gt;\n    \"rev_reg\": &lt;revocation registry state&gt;\n    \"witness\": &lt;witness&gt;\n}\n</code></pre> <p>An exhaustive description of the format is out of scope here; it is more completely documented in the AnonCreds Specification.</p>"},{"location":"features/0771-anoncreds-attachments/#proof-request-format","title":"Proof Request format","text":"<p>This format is used to formally request a verifiable presenation (proof) derived from an AnonCreds-style ZKP-oriented credential.</p> <p>The format can also be used to propose a presentation, in this case the <code>nonce</code> field MUST NOT be provided. The <code>nonce</code> field is required when the proof request is used to request a proof.</p> <p>The identifier for this format is <code>anoncreds/proof-request@v1.0</code>. It must follow the structure of a Proof as defined in the AnonCreds specification.</p> <p>Here is a sample proof request that embodies the following: \"Using a government-issued ID, disclose the credential holder\u2019s name and height, hide the credential holder\u2019s sex, get them to self-attest their phone number, and prove that their age is at least 18\":</p> <pre><code>{\n    \"nonce\": \"2934823091873049823740198370q23984710239847\",\n    \"name\":\"proof_req_1\",\n    \"version\":\"0.1\",\n    \"requested_attributes\":{\n        \"attr1_referent\": {\"name\":\"sex\"},\n        \"attr2_referent\": {\"name\":\"phone\"},\n        \"attr3_referent\": {\"names\": [\"name\", \"height\"], \"restrictions\": &lt;restrictions specifying government-issued ID&gt;}\n    },\n    \"requested_predicates\":{\n        \"predicate1_referent\":{\"name\":\"age\",\"p_type\":\"&gt;=\",\"p_value\":18}\n    }\n}\n</code></pre>"},{"location":"features/0771-anoncreds-attachments/#proof-format","title":"Proof format","text":"<p>This is the format of an AnonCreds-style ZKP. The raw values encoded in the presentation MUST be verified against the encoded values using the encoding algorithm as described in Encoding Attribute Data</p> <p>The identifier for this format is <code>anoncreds/proof@v1.0</code>. It must follow the structure of a Presentation as defined in the AnonCreds specification.</p> <p>A proof that responds to the previous proof request sample looks like this:</p> <pre><code>{\n  \"proof\":{\n    \"proofs\":[\n      {\n        \"primary_proof\":{\n          \"eq_proof\":{\n            \"revealed_attrs\":{\n              \"height\":\"175\",\n              \"name\":\"1139481716457488690172217916278103335\"\n            },\n            \"a_prime\":\"5817705...096889\",\n            \"e\":\"1270938...756380\",\n            \"v\":\"1138...39984052\",\n            \"m\":{\n              \"master_secret\":\"375275...0939395\",\n              \"sex\":\"3511483...897083518\",\n              \"age\":\"13430...63372249\"\n            },\n            \"m2\":\"1444497...2278453\"\n          },\n          \"ge_proofs\":[\n            {\n              \"u\":{\n                \"1\":\"152500...3999140\",\n                \"2\":\"147748...2005753\",\n                \"0\":\"8806...77968\",\n                \"3\":\"10403...8538260\"\n              },\n              \"r\":{\n                \"2\":\"15706...781609\",\n                \"3\":\"343...4378642\",\n                \"0\":\"59003...702140\",\n                \"DELTA\":\"9607...28201020\",\n                \"1\":\"180097...96766\"\n              },\n              \"mj\":\"134300...249\",\n              \"alpha\":\"827896...52261\",\n              \"t\":{\n                \"2\":\"7132...47794\",\n                \"3\":\"38051...27372\",\n                \"DELTA\":\"68025...508719\",\n                \"1\":\"32924...41082\",\n                \"0\":\"74906...07857\"\n              },\n              \"predicate\":{\n                \"attr_name\":\"age\",\n                \"p_type\":\"GE\",\n                \"value\":18\n              }\n            }\n          ]\n        },\n        \"non_revoc_proof\":null\n      }\n    ],\n    \"aggregated_proof\":{\n      \"c_hash\":\"108743...92564\",\n      \"c_list\":[ 6 arrays of 257 numbers between 0 and 255]\n    }\n  },\n  \"requested_proof\":{\n    \"revealed_attrs\":{\n      \"attr1_referent\":{\n        \"sub_proof_index\":0,\n        \"raw\":\"Alex\",\n        \"encoded\":\"1139481716457488690172217916278103335\"\n      }\n    },\n    \"revealed_attr_groups\":{\n      \"attr4_referent\":{\n        \"sub_proof_index\":0,\n        \"values\":{\n          \"name\":{\n            \"raw\":\"Alex\",\n            \"encoded\":\"1139481716457488690172217916278103335\"\n          },\n          \"height\":{\n            \"raw\":\"175\",\n            \"encoded\":\"175\"\n          }\n        }\n      }\n    },\n    \"self_attested_attrs\":{\n      \"attr3_referent\":\"8-800-300\"\n    },\n    \"unrevealed_attrs\":{\n      \"attr2_referent\":{\n        \"sub_proof_index\":0\n      }\n    },\n    \"predicates\":{\n      \"predicate1_referent\":{\n        \"sub_proof_index\":0\n      }\n    }\n  },\n  \"identifiers\":[\n    {\n      \"schema_id\":\"NcYxiDXkpYi6ov5FcYDi1e:2:gvt:1.0\",\n      \"cred_def_id\":\"NcYxi...cYDi1e:2:gvt:1.0:TAG_1\",\n      \"rev_reg_id\":null,\n      \"timestamp\":null\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0771-anoncreds-attachments/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> Name / Link Implementation Notes"},{"location":"features/0780-data-urls-images/","title":"RFC 0780: Use Data URLs for Images and More in Credential Attributes","text":"<ul> <li>Authors: Stephen Curran, Clecio Varjao</li> <li>Status: DEMONSTRATED</li> <li>Since: 2024-03-02</li> <li>Status Note: Implemented in the Bifold Wallet</li> <li>Supersedes: None</li> <li>Start Date: 2023-03-31</li> <li>Tags: feature</li> </ul>"},{"location":"features/0780-data-urls-images/#summary","title":"Summary","text":"<p>Some credentials include attributes that are not simple strings or numbers, such as images or JSON data structures. When complex data is put in an attribute the issuer SHOULD issue the attribute as a Data URL, as defined in IETF RFC 2397, and whose use is described in this Mozilla Developer Documentation article.</p> <p>On receipt of all credentials and presentations, holders and verifiers SHOULD check all string attributes to determine if they are Data URLs. If so, they SHOULD securely process the data according to the metadata information in the Data URL, including:</p> <ul> <li>the MIME type of the data (such as <code>image/png</code> or <code>application/json</code>)</li> <li>whether the data is base64 encoded.</li> </ul> <p>This allows, for example, an Aries Mobile Wallet to detect that a data element is an image and how it is encoded, and display it for the user as an image, not as a long (long) string of gibberish.</p>"},{"location":"features/0780-data-urls-images/#motivation","title":"Motivation","text":"<p>Holders and verifiers want to enable a delightful user experience when an issuer issues attributes that contain other than strings or numbers, such as an image or a JSON data structure. In such cases, the holder and verifiers need a way to know the format of the data so it can be processed appropriately and displayed usefully. While the Aries community encourages the use of the Overlays Capture Architecture specification as outlined in RFC 0755 OCA for Aries for such information, there will be times where an OCA Bundle is not available for a given credential. In the absence of an OCA Bundle, the holders and verifiers of such attributes need data type information for processing and displaying the attributes.</p>"},{"location":"features/0780-data-urls-images/#tutorial","title":"Tutorial","text":"<p>An issuer wants to issue a verifiable credential that contains an image, such as a photo of the holder to which the credential is issued. Issuing such an attribute is typically done by converting the image to a base64 string. This is handled by the various verifiable credential formats supported by Aries issuers. The challenge is to convey to the holder and verifiers that the attribute is not \"just another string\" that can be displayed on screen to the user. By making the attribute a Data URL, the holder and verifiers can detect the type and encoding of the attribute, process it, and display it correctly.</p> <p>For example, this image (from the IETF 2793 specification):</p> <p></p> <p>can be issued as the attribute <code>photo</code> in a verifiable credential with its value a Data URL as follows:</p> <pre><code>{\n\"photo\": \"data:image/png;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAwAAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFzByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSpa/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJlZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uisF81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PHhhx4dbgYKAAA7\"\n}\n</code></pre> <p>The syntax of a Data URL is described in IETF RFC 2397. The \\ version is: <ul> <li><code>data:</code> -- hardcoded.</li> <li><code>&lt;MIME type&gt;</code> -- optional, the MIME type of the data.</li> <li><code>;base64</code> -- optional, if present, the data is base64 encoded.</li> <li><code>,</code> -- hardcoded separator.</li> <li><code>&lt;data&gt;</code> -- the attribute data in the specified encoding.</li> </ul> <p>A holder or verifier receiving a credential or presentation MUST check each attribute is a string, and if so, if it is a Data URL (likely by using a regular expression). If it is a Data URL it should be securely processed accordingly.</p> <p>Aries Data URL verifiable credential attributes MUST include the <code>&lt;MIME type&gt;</code>.</p>"},{"location":"features/0780-data-urls-images/#image-size","title":"Image Size","text":"<p>A separate issue from the use of Data URLs is how large an image (or other data type) can be put into an attribute and issued as a verifiable credential. That is an issue that is dependent on the verifiable credential implementation and other factors. For AnonCreds credentials, the attribute will be treated as a string, a hash will be calculated over the string, and the resulting number will be signed--just as for any string. The size of the image does not matter. However, there may be other components in your deployment that might impact how big an attribute in a credential can be. Many in the community have successfully experimented with the use of images in credentials, so consulting others on the question might be helpful.</p> <p>For the purpose of this RFC, the amount of data in the attribute is not relevant.</p>"},{"location":"features/0780-data-urls-images/#security","title":"Security","text":"<p>As noted in this Mozilla Developer Documentation and this Mozilla Security Blog Post about Data URLs, Data URLs are blocked from being used in the Address Bar of all major browsers. That is because Data URLs may contain HTML that can contain anything, including HTML forms that collect data from users. Since Aries holder and verifier agents are not general purpose content presentation engines (as are browsers) the use of Data URLs are less of a security risk. Regardless, holders and verifiers MUST limit their processing of attributes containing Data URLs to displaying the data, and not executing the data. Further, Aries holders and verifiers MUST stay up on dependency vulnerabilities, such as images constructed to exploit vulnerabilities in libraries that display images.</p>"},{"location":"features/0780-data-urls-images/#reference","title":"Reference","text":"<p>References for implementing this RFC are:</p> <ul> <li>IETF RFC 2397</li> <li>Mozilla Developer Documentation</li> <li>Stack Overflow Article on a Data URL Regex</li> <li>A GitHub Gist of JavaScript to detect a data URL</li> </ul>"},{"location":"features/0780-data-urls-images/#drawbacks","title":"Drawbacks","text":"<p>The Aries community is moving to the use of the [Overlay Capture Architecture Specification] to provide a more generalized way to accomplish the same thing (understanding the meaning, format and encoding of attributes), so this RFC is duplicating a part of that capability. That said, it is easier and faster for issuers to start using, and for holders and verifiers to detect and use.</p> <p>Issuers may choose to issue Data URLs with MIME types not commonly known to Aries holder and verifier components. In such cases, the holder or verifier MUST NOT display the data.</p> <p>Even if the MIME type of the data is known to the holders and verifiers, it may not be obvious how to present the data on screen in a useful way. For example, an attribute holding a JSON data structure with an array of values may not easily be displayed.</p>"},{"location":"features/0780-data-urls-images/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>We considered using the same approach as is used in RFC 0441 Present Proof Best Practices of a special suffix (<code>_img</code>) for the attribute name in a credential to indicate that the attribute held an image. However, that provides far less information than this approach (e.g., what type of image?), and its use is limited to images. This RFC defines a far more complete, standard, and useful approach.</p> <p>As noted in the drawbacks section, this same functionality can (and should) be achieved with the broad deployment of [Overlay Capture Architecture Specification] and RFC 0755 OCA for Aries. However, the full deployment of RFC 0755 OCA for Aries will take some time, and in the meantime, this is a \"quick and easy\" alternate solution that is useful alongside OCA for Aries.</p>"},{"location":"features/0780-data-urls-images/#prior-art","title":"Prior art","text":"<p>In the use cases of which we are aware of issuers putting images and JSON structures into attributes, there was no indicator of the attribute content, and the holders and verifiers were assumed to either \"know\" about the data content based on the type of credential, or they just displayed the data as a string.</p>"},{"location":"features/0780-data-urls-images/#unresolved-questions","title":"Unresolved questions","text":"<p>Should this RFC define a list (or the location of a list) of MIME types that Aries issuers can use in credential attributes?</p> <p>For supported MIME types that do not have obvious display methods (such as JSON), should there be a convention for how to display the data?</p>"},{"location":"features/0780-data-urls-images/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0793-unqualfied-dids-transition/","title":"Aries RFC 0793: Unqualified DID Transition","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: ACCEPTED</li> <li>Since: 2023-07-11</li> <li>Status Note: In Step 1 - Target Deployment Date: 2024-07-02 </li> <li>Supersedes:</li> <li>Start Date: 2023-07-11</li> <li>Tags: feature, community-update</li> </ul>"},{"location":"features/0793-unqualfied-dids-transition/#summary","title":"Summary","text":"<p>Historically, Aries use of the Indy SDK's wallet included the use of 'unqualified DIDs' or DIDs without a did: prefix and method.  This transition documents the process of migrating any such DIDs still in use to fully qualified DIDs.</p> <p>This process involves the adoption of the Rotate DID protocol and algorithm 4 of the Peer DID Method, then the rotation from the unqualified DIDs to any fully qualified DID, with preference for did:peer:4.</p> <p>The adoption of these specs will further prepare the Aries community for adoption of DIDComm v2 by providing an avenue for adding DIDComm v2 compatible endpoints.</p> <p>Codebases that do not use unqualified DIDs MUST still adopt DID Rotation and did:peer:4 as part of this process, even if no unqualified DIDs must be rotated.</p> <p>This RFC follows the guidance in RFC 0345 about community-coordinated updates to (try to) ensure that independently deployed, interoperable agents remain interoperable throughout this transition.</p> <p>The transition from the unqualified to qualified DIDs will occur in four steps:</p> <ul> <li>Pre-work: where we agree on the transition plan outlined in this RFC.</li> <li>Finalize did:peer:4 details, including feature discovery support of did:peer:4.</li> <li>Verify transisiton plan and code.</li> <li>Step 1: Agent builders MUST update all agent code bases and deployments to support DID Rotation and did:peer:4. </li> <li>Each agent builder SHOULD notify the community they have completed Step 1 by submitting a PR to update their entry in the implementations accordingly.</li> <li>Target Date for code update: 2024-05-01</li> <li>Target Date for deployment update: 2024-07-02</li> <li>Step 2: Agent builders using unqualified DIDs MUST no longer use new unqualified DIDs, and MUST use DID Rotation to rotate to a fully qualified DID.</li> <li>Each agent builder SHOULD notify the community they have completed Step 2 by submitting a PR to update their entry in the implementations accordingly.</li> <li>Target Date for finishing step 2: 2024-11-01</li> <li>Step 3: Agent builders SHOULD update their deployments to remove all support for receiving unqualified DIDs from other agents.</li> </ul> <p>The community coordination triggers between the steps above will be as follows:</p> <ul> <li>Pre-work to Step 1 - a PR to this RFC is merged that sets the RFC status to ACCEPTED.</li> <li>The ACCEPTED version of this RFC is included in the current Aries Interop Profile version.</li> <li>Step 1 to Step 2 - the community agrees that the majority of the deployed agents have completed Step 1. A PR to this RFC is merged that sets the RFC status to ADOPTED.</li> <li>Agent builders indicate completion of Step 1 by updating the Implementations section of this RFC.</li> <li>All other RFCs in this repo are updated to use the new message type format.</li> <li>The ADOPTED version of this RFC is included in the current Aries Interop Profile version.</li> <li>Step 2 to Step 3 - the community agrees that the majority of the deployed agents have completed Step 2. A PR to this RFC is merged that sets the RFC status to RETIRED.</li> <li>Agent builders indicate completion of Step 2 by updating the Implementations section of this RFC.</li> </ul>"},{"location":"features/0793-unqualfied-dids-transition/#motivation","title":"Motivation","text":"<p>To enable agent builders to independently update their code bases and deployed agents while maintaining interoperability.</p>"},{"location":"features/0793-unqualfied-dids-transition/#tutorial","title":"Tutorial","text":"<p>The general mechanism for this type of transition is documented in RFC 0345 about community-coordinated updates.</p> <p>The specific sequence of events to make this particular transition is outlined in the summary section of this RFC.</p>"},{"location":"features/0793-unqualfied-dids-transition/#reference","title":"Reference","text":"<p>See the summary section of this RFC for the details of this transition.</p>"},{"location":"features/0793-unqualfied-dids-transition/#drawbacks","title":"Drawbacks","text":"<p>None identified.</p>"},{"location":"features/0793-unqualfied-dids-transition/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>This approach balances the speed of adoption with the need for independent deployment and interoperability.</p>"},{"location":"features/0793-unqualfied-dids-transition/#prior-art","title":"Prior art","text":"<p>The approach outlined in RFC 0345 about community-coordinated updates is a well-known pattern for using deprecation to make breaking changes in an ecosystem. That said, this is the first attempt to use this approach in Aries. Adjustments to the transition plan will be made as needed, and RFC 0345 will be updated based on lessons learned in executing this plan.</p>"},{"location":"features/0793-unqualfied-dids-transition/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Are any changes to existing RFCs needed before starting Step 1?</li> </ul>"},{"location":"features/0793-unqualfied-dids-transition/#implementations","title":"Implementations","text":"<p>The following table lists the status of various agent code bases and deployments with respect to the steps of this transition. Agent builders MUST update this table as they complete steps of the transition.</p> Name / Link Implementation Notes Aries Protocol Test Suite No steps completed Aries Framework - .NET No steps completed Trinsic.id No steps completed Aries Cloud Agent - Python No steps completed Aries Static Agent - Python No steps completed Aries Framework - Go No steps completed Connect.Me No steps completed Verity No steps completed Pico Labs No steps completed IBM No steps completed IBM Agent No steps completed Aries Cloud Agent - Pico No steps completed Aries Framework JavaScript No steps completed"},{"location":"features/0794-did-rotate/","title":"Aries RFC 0794: DID Rotate 1.0","text":"<ul> <li>Authors: Sam Curren</li> <li>Status: ACCEPTED</li> <li>Since: 2024-03-02</li> <li>Status Note: Implemented in the Aries Cloud Agent Python</li> <li>Start Date: 2023-08-18 </li> <li>Tags: feature, protocol</li> <li>URI: https://didcomm.org/did-rotate/1.0</li> </ul>"},{"location":"features/0794-did-rotate/#summary","title":"Summary","text":"<p>This protocol signals the change of DID in use between parties.</p> <p>This protocol is only applicable to DIDComm v1 - in DIDComm v2 use the more efficient DID Rotation header.</p>"},{"location":"features/0794-did-rotate/#motivation","title":"Motivation","text":"<p>This mechanism allows a party in a relationship to change the DID they use to identify themselves in that relationship. This may be used to switch DID methods, but also to switch to a new DID within the same DID method. For non-updatable DID methods, this allows updating DID Doc attributes such as service endpoints. Inspired by (but different from) the DID rotation feature of the DIDComm Messaging (DIDComm v2) spec.</p>"},{"location":"features/0794-did-rotate/#implications-for-software-implementations","title":"Implications for Software Implementations","text":"<p>Implementations will need to consider how data (public keys, DIDs and the ID for the relationship) related to the relationship is managed. If the relationship DIDs are used as identifiers, those identifiers may need to be updated during the rotation to maintain data integrity. For example, both parties might have to retain and be able to use as identifiers for the relationship the existing DID and the rotated to DID, and their related keys for a period of time until the rotation is complete.</p>"},{"location":"features/0794-did-rotate/#tutorial","title":"Tutorial","text":""},{"location":"features/0794-did-rotate/#name-and-version","title":"Name and Version","text":"<p>DID Rotate 1.0</p> <p>URI: https://didcomm.org/did-rotate/1.0/"},{"location":"features/0794-did-rotate/#roles","title":"Roles","text":"<p>rotating_party: this party is rotating the DID in use for this relationship. They send the <code>rotate</code> message.</p> <p>observing_party: this party is notified of the DID rotation</p>"},{"location":"features/0794-did-rotate/#messages","title":"Messages","text":""},{"location":"features/0794-did-rotate/#rotate","title":"Rotate","text":"<p>Message Type URI: https://didcomm.org/did-rotate/1.0/rotate</p> <p><code>to_did</code>: The new DID to be used to identify the rotating_party</p> <pre><code>{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/did-rotate/1.0/rotate\",\n    \"to_did\": \"did:example:newdid\",\n\n}\n</code></pre> <p>The rotating_party is expected to receive messages on both the existing and new DIDs and their associated keys for a reasonable period that MUST extend at least until the following <code>ack</code> message has been received.</p> <p>This message MUST be sent using AuthCrypt or as a signed message in order to establish the provenance of the new DID. In Aries implementations, messages sent within the context of a relationship are by default sent using AuthCrypt. Proper provenance prevents injection attacks that seek to take over a relationship. Any rotate message received without being authcrypted or signed MUST be discarded and not processed.</p> <p>DIDComm v1 uses public keys as the outer message identifiers. This means that rotation to a new DID using the same public key will not result in a change for new inbound messages. The observing_party must not assume that the new DID uses the same keys as the existing relationship.</p>"},{"location":"features/0794-did-rotate/#ack","title":"Ack","text":"<p>Message Type URI: https://didcomm.org/did-rotate/1.0/ack</p> <p>This message has been adopted from [the <code>ack</code> protocol] (https://github.com/hyperledger/aries-rfcs/tree/main../../features/0015-acks).</p> <p>This message is still sent to the prior DID to acknowledge the receipt of the rotation. Following messages will be sent to the new DID.</p> <p>In order to correctly process out of order messages, the The observing_party may choose to receive messages from the old DID for a reasonable period. This allows messages sent before rotation but received after rotation in the case of out of order message delivery.</p> <p>In this message, the <code>thid</code> (Thread ID) MUST be included to allow the <code>rotating_party</code> to correlate it with the sent <code>rotate</code> message.</p> <pre><code>{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/did-rotate/1.0/ack\",\n      \"~thread\"          : {\n        \"thid\": \"&lt;id of rotate message&gt;\"\n    },\n\n}\n</code></pre>"},{"location":"features/0794-did-rotate/#problem-report","title":"Problem Report","text":"<p>Message Type URI: https://didcomm.org/did-rotate/1.0/problem-report</p> <p>This message has been adopted from [the <code>report-problem</code> protocol] (https://github.com/hyperledger/aries-rfcs/blob/main../../features/0035-report-problem/README.md).</p> <p>If the observing_party receives a <code>rotate</code> message with a DID that they cannot resolve, they MUST return a problem-report message.</p> <p>The <code>description</code> <code>code</code> must be set to one of the following: - e.did.unresolvable - used for a DID who's method is supported, but will not resolve - e.did.method_unsupported - used for a DID method for which the <code>observing_party</code> does not support resolution. - e.did.doc_unsupported - used for a DID for which the <code>observing_party</code> does not find information sufficient for a DIDComm connection in the resolved DID Document. This would include compatible key types and a DIDComm capable service endpoint.</p> <p>Upon receiving this message, the <code>rotating_party</code> must not complete the rotation and resolve the issue. Further rotation attempts must happen in a new thread.</p> <pre><code>{\n  \"@type\"            : \"https://didcomm.org/did-rotate/1.0/problem-report\",\n  \"@id\"              : \"an identifier that can be used to discuss this error message\",\n  \"~thread\"          : {\n        \"pthid\": \"&lt;id of rotate message&gt;\"\n    },\n  \"description\"      : { \"en\": \"DID Unresolvable\", \"code\": \"e.did.unresolvable\" },\n  \"problem_items\"    : [ {\"did\": \"&lt;did_passed_in_rotate&gt;\"} ],\n}\n</code></pre>"},{"location":"features/0794-did-rotate/#hangup","title":"Hangup","text":"<p>Message Type URI: https://didcomm.org/did-rotate/1.0/hangup</p> <p>This message is sent by the rotating_party to inform the observing_party that they are done with the relationship and will no longer be responding.</p> <p>There is no response message.</p> <p>Use of this message does not require or indicate that all data has been deleted by either party, just that interaction has ceased.</p> <pre><code>{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/did-rotate/1.0/hangup\"\n}\n</code></pre>"},{"location":"features/0794-did-rotate/#prior-art","title":"Prior art","text":"<p>This protocol is inspired by the rotation feature of DIDComm Messaging (DIDComm v2). The implementation differs in important ways. The DIDComm v2 method is a post rotate operation: the first message sent AFTER the rotation contains the prior DID and a signature authorizing the rotation. This is efficient, but requires the use of a message header and a higher level of integration with message processing. This protocol is a pre rotate operation: notifying the other party of the new DID in advance is a less efficient but simpler approach. This was done to minimize adoption pain. The pending move to DIDComm v2 will provide the efficiency.</p>"},{"location":"features/0794-did-rotate/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0804-didcomm-rpc/","title":"0804: DIDComm Remote Procedure Call (DRPC)","text":"<ul> <li>Authors: Clecio Varjao (BC Gov), Stephen Curran (BC Gov), Akiff Manji (BC Gov)</li> <li>Status: DEMONSTRATED</li> <li>Since: 2024-03-02</li> <li>Status Note: Implemented in an Aries Cloud Agent Python plugin, and Credo TS</li> <li>Supersedes:</li> <li>Start Date: 2023-11-29</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0804-didcomm-rpc/#summary","title":"Summary","text":"<p>The DIDComm Remote Procedure Call (DRPC) protocol enables a JSON-RPC-based request-response interaction to be carried out across a DIDComm channel. The protocol is designed to enable custom interactions between connected agents, and to allow for the rapid prototyping of experimental DIDComm protocols. An agent sends a DIDComm message to request a JSON-RPC service be invoked by another agent, and gets back the JSON-RPC-format response in subsequent DIDComm message. The protocol enables any request to be conveyed that the other agent understands. Out of scope of this protocol is how the requesting agent discovers the services available from the responding agent, and how the two agents know the semantics of the specified JSON-RPC requests and responses. By using DIDComm between the requesting and responding agents, the security and privacy benefits of DIDComm are accomplished, and the generic parameters of the requests allow for flexibility in how and where the protocol can be used.</p>"},{"location":"features/0804-didcomm-rpc/#motivation","title":"Motivation","text":"<p>There are several use cases that are driving the initial need for this protocol.</p>"},{"location":"features/0804-didcomm-rpc/#app-attestation","title":"App Attestation","text":"<p>A mobile wallet needs to get an app attestation verifiable credential from the wallet publisher. To do that, the wallet and publisher need to exchange information specific to to the attestation process with the Google and Apple stores. The sequence is as follows:</p> <ul> <li>The wallet decides (for some reason) it needs an App Attestation credential   from its publisher.</li> <li>If not already available, a DIDComm connection between the wallet and the   attestation service is created.</li> <li>The wallet uses the DRPC protocol to request a nonce from the service to be   used in the attestation. The service responds with the nonce.</li> <li>The wallet uses a new instance of the DRPC protocol to request the attestation   be performed. The service responds with the status of the attestation process.</li> <li>The service completes the business process by initiating an Issue Credential   process to issue an attestation verifiable credential.</li> </ul> <p>The wallet and service are using instances of three protocols (two DRPC and one Issue Credential) to carry out a full business process. Each participant must have knowledge of the full business process--there is nothing inherent in the DRPC protocol about this process, or how it is being used. The DRPC protocol is included to provide a generic request-response mechanism that alleviates the need for formalizing special purpose protocols.</p> <p>App attestation is a likely candidate for a having its own DIDComm protocol. This use of DRPC is ideal for developing and experimenting with the necessary agent interactions before deciding on if a use-specific protocol is needed and its semantics.</p>"},{"location":"features/0804-didcomm-rpc/#video-verification-service","title":"Video Verification Service","text":"<p>A second example is using the DRPC protocol is to implement a custom video verification service that is used by a specific mobile wallet implementation and a proprietary backend service prior to issuing a credential to the wallet. Since the interactions are to a proprietary service, so an open specification does not make sense, but the use of DIDComm is valuable. In this example, the wallet communicates over DIDComm to a Credential Issuer agent that (during verification) proxies the requests/responses to a backend (\"behind the firewall\") service. The wallet is implemented to use DRPC protocol instances to initiate the verification and receive the actions needed to carry out the steps of the verification (take picture, take video, instruct movements, etc.), sending to the Issuer agent the necessary data. The Issuer conveys the requests to the verification service and the responses back to the mobile wallet. At the end of the process, the Issuer can see the result of the process, and decide on the next actions between it and the mobile wallet, such as issuing a credential.</p> <p>Again, after using the DRPC protocol for developing and experimenting with the implementation, the creators of the protocol can decide to formalize their own custom, end-to-end protocol, or continue to use the DRPC protocol instances. Important is that they can begin development without doing any Aries frameworks customizations or plugins by using DRPC.</p>"},{"location":"features/0804-didcomm-rpc/#tutorial","title":"Tutorial","text":""},{"location":"features/0804-didcomm-rpc/#name-and-version","title":"Name and Version","text":"<p>This is the DRPC protocol. It is uniquely identified by the URI:</p> <pre><code>\"https://didcomm.org/drpc/1.0\"\n</code></pre>"},{"location":"features/0804-didcomm-rpc/#key-concepts","title":"Key Concepts","text":"<p>This RFC assumes that you are familiar with DID communication.</p> <p>The protocol consists of a DIDComm <code>request</code> message carrying an arbitrary JSON-RPC request to a responding agent, and a second message that carries the result of processing the request back to the client of the first message. The interpretation of the request, how to carry out the request, the content of the response, and the interpretation of the response, are all up to the business logic (controllers) of the participating agents. There is no discovery of remote services offered by agents--it is assumed that the two participants are aware of the DRPC capabilities of one another through some other means. For example, from the App Attestation use case, functionality to carry out the app attestation process, and the service to use it is built into the mobile wallet.</p> <p>Those unfamiliar with JSON-RPC, the <code>&lt;tl;dr&gt;</code> is that it is a very simple request response protocol using JSON where the only data shared is:</p> <ul> <li>a <code>method</code> that defines what needs to be done,</li> <li>some <code>params</code> in JSON that are up to the requester/server to agree on, and</li> <li>an (optional) <code>id</code> to connect the response to the request.</li> </ul> <p>The response is likewise simple:</p> <ul> <li>a <code>result</code> item if the invocation completed successful containing the return results,</li> <li>an <code>error</code> item if the invocation failed, containing details about the failure, and</li> <li>the <code>id</code> from the request.</li> </ul> <p>An example of a simple JSON-RPC request/response pair from the specification is:</p> <pre><code>--&gt; {\"jsonrpc\": \"2.0\", \"method\": \"subtract\", \"params\": [42, 23], \"id\": 1}\n&lt;-- {\"jsonrpc\": \"2.0\", \"result\": 19, \"id\": 1}\n</code></pre> <p>A JSON-RPC request may be a batch of requests, each with a different <code>id</code> value, and the response a similar array, with an entry for each of the requests.</p> <p>JSON-RPC follows a similar \"parameters defined by the message type\" pattern as DIDComm. As a result, in this protocol we do not need to add any special handling around the <code>params</code> such as Base64 encoding, signing, headers and so on, as the parties interacting with the protocol by definition must have a shared understanding of the content of the <code>params</code> and can define any special handling needed amongst themselves.</p> <p>It is expected (although not required) that an Aries Framework receiving a DRPC message will simply pass to its associated \"business logic\" (controller) the request from the client, and wait on the controller to provide the response content to be sent back to the original client. Apart from the messaging processing applied to all inbound and outbound messages, the Aries Framework will not perform any of the actual processing of the request.</p>"},{"location":"features/0804-didcomm-rpc/#roles","title":"Roles","text":"<p>There are two roles, adopted from the JSON-RPC specification, in the protocol <code>client</code> and <code>server</code>:</p> <ul> <li>The <code>client</code> initiates the protocol, sending a request to the <code>server</code>.</li> <li>The <code>server</code> carries out the request however they see fit. The <code>server</code>   may process the request themselves, or might invoke another service to process   the request. The <code>server</code> might be unable or unwilling to carry out the   request.</li> <li>The <code>server</code> returns the response from the request in a message to the <code>client</code>.</li> </ul>"},{"location":"features/0804-didcomm-rpc/#states","title":"States","text":""},{"location":"features/0804-didcomm-rpc/#client-states","title":"Client States","text":"<p>The <code>client</code> agent goes through the following states:</p> <ul> <li>request-sent</li> <li>completed</li> </ul> <p>The state transition table for the <code>client</code> is:</p> State / Events Send Request Receive Response Start Transition to request-sent request-sent Transition to complete completed problem-report received Transition to abandoned abandoned"},{"location":"features/0804-didcomm-rpc/#server-states","title":"Server States","text":"<p>The <code>server</code> agent goes through the following states:</p> <ul> <li>request-received</li> <li>completed</li> </ul> <p>The state transition table for the <code>server</code> is:</p> State / Events Receive Request Send Response or Problem Report Start Transition to request-received request-received Transition to complete completed"},{"location":"features/0804-didcomm-rpc/#messages","title":"Messages","text":"<p>The following are the messages in the DRPC protocol. The <code>response</code> message handles all positive responses, so the <code>ack</code> (RFC 0015 ACKs) message is NOT adopted by this protocol. The RFC 0035 Report Problem is adopted by this protocol in the event that a <code>request</code> is not recognizable as a JSON-RPC message and as such, a JSON-RPC response message cannot be created. See the details below in the Problem Report Message section.</p>"},{"location":"features/0804-didcomm-rpc/#request-message","title":"Request Message","text":"<p>The <code>request</code> message is sent by the <code>client</code> to initiate the protocol. The message contains the JSON-RPC information necessary for the <code>server</code> to process the request, prepare the response, and send the response message back to the <code>client</code>. It is assumed the <code>client</code> knows what types of requests the <code>server</code> is prepared to receive and process. If the <code>server</code> does not know how to process the error, JSON-RPC has a standard response, outlined in the response message section below. How the <code>client</code> and <code>server</code> coordinate that understanding is out of scope of this protocol.</p> <p>The <code>request</code> message uses the same JSON items as JSON-RPC, skipping the <code>id</code> in favor of the existing DIDComm <code>@id</code> and thread handling.</p> <pre><code>  {\n    \"@type\": \"https://didcomm.org/drpc/1.0/request\",\n    \"@id\": \"2a0ec6db-471d-42ed-84ee-f9544db9da4b\",\n    \"request\" : {\"jsonrpc\": \"2.0\", \"method\": \"subtract\", \"params\": [42, 23], \"id\": 1}\n  }\n</code></pre> <p>The items in the message are as follows:</p> <ul> <li><code>@type</code> -- required, must be as above</li> <li><code>@id</code> -- required, must be as defined in [RFC 0005 DIDComm]</li> <li><code>request</code> -- required, an item containing a JSON-RPC request JSON structure.</li> <li><code>request</code> MUST be either a single JSON-RPC request, or an array of JSON-RPC requests.</li> <li>Each JSON-RPC request MUST have the <code>jsonrpc</code> and <code>method</code> items.</li> <li>Each JSON-RPC request MAY have the <code>params</code> and <code>id</code> items.<ul> <li>See the details below about the handling of <code>notification</code> JSON-RPC requests, requests where the <code>id</code> field is omitted.</li> </ul> </li> <li>See the JSON-RPC specification for details about the <code>jsonrpc</code>, <code>method</code>, <code>params</code> and <code>id</code> JSON items.</li> </ul> <p>Per the JSON-RPC specification, if the <code>id</code> field of a JSON-RPC request is omitted, the <code>server</code> should not respond. In this DRPC DIDComm protocol, the <code>server</code> is always expected to send a <code>response</code>, but MUST NOT include a JSON-RPC response for any JSON-RPC request for which the <code>id</code> is omitted. This is covered further in the response message section (below).</p>"},{"location":"features/0804-didcomm-rpc/#response-message","title":"Response Message","text":"<p>A <code>response</code> message is sent by the <code>server</code> to following the processing of the request to convey the output of the processing to the <code>client</code>. As with the <code>request</code> the format mostly exactly that of a JSON-RPC response.</p> <p>If the <code>request</code> is unrecognizable as a JSON-RPC message such that a JSON-RPC message cannot be generated, the <code>server</code> SHOULD send a RFC 0035 Report Problem message to the <code>client</code>.</p> <p>It is assumed the <code>client</code> understands what the contents of the <code>response</code> message means in the context of the protocol instance. How the <code>client</code> and <code>server</code> coordinate that understanding is out of scope of this protocol.</p> <pre><code>  {\n    \"@type\": \"https://didcomm.org/drpc/1.0/response\",\n    \"@id\": \"63d6f6cf-b723-4eaf-874b-ae13f3e3e5c5\",\n    \"response\": {\"jsonrpc\": \"2.0\", \"result\": 19, \"id\": 1}\n  }\n</code></pre> <p>The items in the message are as follows:</p> <ul> <li><code>@type</code> -- required, must be as above</li> <li><code>@id</code> -- required, must be as defined in [RFC 0005 DIDComm]</li> <li><code>response</code> -- required, an item containing a JSON-RPC response JSON structure.</li> <li><code>response</code> MUST be either single (possibly empty) JSON-RPC response,     or an array of JSON-RPC responses.<ul> <li>If all of the JSON-RPC requests in the <code>request</code> message are   notifications (e.g., the <code>id</code> item is omitted), the DIDComm <code>response</code>   message MUST be sent back with the value: <code>\"response\" : {}</code>.</li> </ul> </li> <li>Each JSON-RPC response MUST have the <code>jsonrpc</code> and <code>id</code> items, and either a <code>result</code> or <code>error</code> item.<ul> <li>See the JSON-RPC specification for details about the <code>jsonrpc</code>, <code>id</code>, <code>result</code> and <code>error</code> JSON items.</li> </ul> </li> </ul> <p>As with all DIDComm messages that are not the first in a protocol instance, a <code>~thread</code> decorator MUST be included in the <code>response</code> message.</p> <p>The special handling of the \"all JSON-RPC requests are notifications\" described above is to simplify the DRPC handling to know when a DRPC protocol instance is complete. If a <code>response</code> message is not always required, the DRPC handler would have to inspect the <code>request</code> message to look for <code>id</code>s to determine when the protocol completes.</p> <p>If the <code>server</code> does not understand how to process a given JSON-RPC request, a <code>response</code> error SHOULD be returned (as per the JSON-RPC specification) with:</p> <ul> <li><code>error.code</code> value <code>-32601</code>,</li> <li><code>error.message</code> set to <code>Method not found</code>, and</li> <li>no <code>error.data</code> item.</li> </ul>"},{"location":"features/0804-didcomm-rpc/#problem-report-message","title":"Problem Report Message","text":"<p>A RFC 0035 Report Problem message SHOULD be sent by the <code>server</code> instead of a <code>response</code> message only if the <code>request</code> is unrecognizable as a JSON-RPC message. An JSON-RPC errors MUST be provided to the <code>client</code> by the <code>server</code> via the <code>response</code> message, not a <code>problem-report</code>. The <code>client</code> MUST NOT respond to a <code>response</code> message, even if the <code>response</code> message is not a valid JSON-RPC response.  This is because once the <code>server</code> sends the <code>response</code>, the protocol is in the <code>completed</code> state (from the <code>server</code>'s perspective) and so is subject to deletion. As such, a follow up <code>problem-report</code> message would have an invalid <code>thid</code> (thread ID) and (at best) be thrown away by the <code>server</code>.</p>"},{"location":"features/0804-didcomm-rpc/#constraints","title":"Constraints","text":"<p>The primary constraint with this protocol is that the two parties using the protocol must understand one another--what JSON-RPC request(s) to use, what parameters to provide, how to process the those requests, what the <code>response</code> means, and so on. It is not a protocol to be used between arbitrary parties, but rather one where the parties have knowledge outside of DIDComm of one another and their mutual capabilities.</p> <p>On the other hand, that constraint enables great flexibility for explicitly collaborating agents (such as a mobile wallet and the agent of its manufacturer) to accomplish request-response transactions over DIDComm without needing to define additional DIDComm protocols. More complex interactions can be accomplished by carrying out a sequence of DRPC protocol instances between agents.</p> <p>The flexibility the DRPC protocol allows for experimenting with specific interactions between agents that could later evolve into formal DIDComm \"fit for purpose\" protocols.</p>"},{"location":"features/0804-didcomm-rpc/#reference","title":"Reference","text":""},{"location":"features/0804-didcomm-rpc/#codes-catalog","title":"Codes Catalog","text":"<p>A JSON-RPC request codes catalog could be developed over time and be included in this part of the RFC. This might an intermediate step in transitioning a given interaction implemented using DRPC into formally specified interaction. On the other hand, simply defining a full DIDComm protocol will often be a far better approach.</p> <p>At this time, there are no codes to be cataloged.</p>"},{"location":"features/0804-didcomm-rpc/#drawbacks","title":"Drawbacks","text":"<p>Anything that can be done by using the DRPC protocol can be accomplished by a formally defined protocol specific to the task to be accomplished. The advantage of the DRPC protocol is that pairs of agent instances that are explicitly collaborating can use this protocol without having to first define a task-specific protocol.</p>"},{"location":"features/0804-didcomm-rpc/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>We considered not supporting the notification and batch forms of the JSON-RPC specification, and decided it made sense to allow for the full support of the JSON-RPC specification, including requests of those forms. That said, we also found that the concept of not having a DRPC <code>response</code> message in some (likely, rare) cases based on the contents of the <code>request</code> JSON item (e.g., when all of the <code>id</code>s are omitted from the JSON-RPC requests) would unnecessarily complicate the DIDComm protocol instance handling about when it is complete. As a result, a DRPC <code>response</code> message is always required.</p> <p>This design builds on the experience of implementations of this kind of feature using RFC 0095 Basic Message and RFC 0335 HTTP Over DIDComm. This design tries to build off the learnings gained from both of those implementations.</p> <p>Based on feedback to an original version of the RFC, we looked as well at using gRPC as the core of this protocol, versus JSON-RPC. Our assessment was that gRPC was a much heavier weight mechanism that required more effort between parties to define and implement what will often be a very simple request-response transaction -- at the level of defining a DIDComm protocol.</p> <p>The use of <code>params</code> and leaving the content and semantics of the params up to the <code>client</code> and <code>server</code> means that they can define the appropriate handling of the parameters. This eliminates the need for the protocol to define, for example, that some data needs to be Base64 encoding for transmission, or if some values need to be cryptographically signed. Such details are left to the participants and how they are using the protocol.</p>"},{"location":"features/0804-didcomm-rpc/#prior-art","title":"Prior art","text":"<p>This protocol has similar goals to the RFC 0335 HTTP Over DIDComm protocol, but takes a lighter weight, more flexible approach. We expect that implementing HTTP over DIDComm using this protocol will be as easy as using RFC 0335 HTTP Over DIDComm, where the JSON-RPC request's <code>params</code> data structure holds the <code>headers</code> and <code>body</code> elements for the HTTP request. On the other hand, using the explicit RFC 0335 HTTP Over DIDComm is might be a better choice if it is available and exactly what is needed.</p> <p>One of the example use cases for this protocol has been implemented by \"hijacking\" the RFC 0095 Basic Message protocol to carry out the needed request/response actions. This approach is less than ideal in that:</p> <ul> <li>That is not the intended use of RFC 0095 Basic Message, which is to send a   basic, human consumable message to the other agent.</li> <li>The request method and parameters have to be encoded into the basic message.</li> <li>The RFC 0095 Basic Message protocol is a single message protocols, so each   request-response interaction requires two instances of the protocol, and for   the controllers to manage connecting the interactions together.</li> </ul>"},{"location":"features/0804-didcomm-rpc/#unresolved-questions","title":"Unresolved questions","text":"<ul> <li>Should we include the idea of a <code>request</code> having a goal code (RFC 0519 Goal Codes)?</li> </ul>"},{"location":"features/0804-didcomm-rpc/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"},{"location":"features/0809-w3c-data-integrity-credential-attachment/","title":"Aries RFC 0809: W3C Verifiable Credential Data Integrity Attachment format for requesting and issuing credentials","text":"<ul> <li>Authors: Timo Glastra (Animo Solutions)</li> <li>Status: DEMONSTRATED</li> <li>Since: 2024-01-10</li> <li>Status Note: Implemented in Aries Cloud Agent Python and Credo</li> <li>Supersedes: Aries RFC 0593: JSON-LD Credential Attachment</li> <li>Start Date: 2023-12-18</li> <li>Tags: feature, protocol, credentials, test-anomaly</li> </ul>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#summary","title":"Summary","text":"<p>This RFC registers an attachment format for use in the issue-credential V2 protocol based on W3C Verifiable Credentials with Data Integrity Proofs from the VC Data Model.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#motivation","title":"Motivation","text":"<p>The Issue Credential protocol needs an attachment format to be able to exchange W3C verifiable credentials. It is desirable to make use of specifications developed in an open standards body, such as the Credential Manifest for which the attachment format is described in RFC 0511: Credential-Manifest Attachment format. However, the Credential Manifest is not finished and ready yet, and therefore there is a need to bridge the gap between standards.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#tutorial","title":"Tutorial","text":"<p>Complete examples of messages are provided in the reference section.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#reference","title":"Reference","text":""},{"location":"features/0809-w3c-data-integrity-credential-attachment/#credential-offer-attachment-format","title":"Credential Offer Attachment Format","text":"<p>Format identifier: <code>didcomm/w3c-di-vc-offer@v0.1</code></p> <pre><code>{\n  \"data_model_versions_supported\": [\"1.1\", \"2.0\"],\n  \"binding_required\": true,\n  \"binding_method\": {\n    \"anoncreds_link_secret\": {\n      \"nonce\": \"1234\",\n      \"cred_def_id\": \"did:key:z6MkwXG2WjeQnNxSoynSGYU8V9j3QzP3JSqhdmkHc6SaVWoT/credential-definition\",\n      \"key_correctness_proof\": \"&lt;key_correctness_proof&gt;\"\n    },\n    \"didcomm_signed_attachment\": {\n      \"algs_supported\": [\"EdDSA\"],\n      \"did_methods_supported\": [\"key\", \"web\"],\n      \"nonce\": \"1234\"\n    }\n  },\n  \"credential\": {\n    \"@context\": [\n      \"https://www.w3.org/2018/credentials/v1\",\n      \"https://w3id.org/security/data-integrity/v2\",\n      {\n        \"@vocab\": \"https://www.w3.org/ns/credentials/issuer-dependent#\"\n      }\n    ],\n    \"type\": [\"VerifiableCredential\"],\n    \"issuer\": \"did:key:z6MkwXG2WjeQnNxSoynSGYU8V9j3QzP3JSqhdmkHc6SaVWoT\",\n    \"issuanceDate\": \"2024-01-10T04:44:29.563418Z\",\n    \"credentialSubject\": {\n      \"height\": 175,\n      \"age\": 28,\n      \"name\": \"Alex\",\n      \"sex\": \"male\"\n    }\n  }\n}\n</code></pre> <ul> <li><code>data_model_versions_supported</code> - Required. List of strings indicating the supported VC Data Model versions. The list MUST contain at least one value. The values MUST be a valid data model version. Current supported values include <code>1.1</code> and <code>2.0</code>.</li> <li><code>binding_required</code> - Optional. Boolean indicating whether the credential MUST be bound to the holder. If omitted, the credential is not required to be bound to the holder. If set to <code>true</code>, the credential MUST be bound to the holder using at least one of the binding methods defined in <code>binding_method</code>.</li> <li><code>binding_method</code> - Required if <code>binding_required</code> is true. Object containing key-value pairs of binding methods supported by the issuer to bind the credential to a holder. If the value is omitted, this indicates the issuer does not support any binding methods for issuance of the credential. See Binding Methods for a registry of default binding methods supported as part of this RFC.</li> <li><code>credential</code> - Required. The credential to be issued. The credential MUST be compliant with the first <code>data_model_versions_supported</code> entry version of VC Data Model, except for the omission of a set required keys that may only be known at the time of issuance. See Credential Offer Exceptions for a list of exceptions. The credential MUST NOT contain any proofs. Some properties MAY be omitted if they will only be available at time of issuance, such as <code>issuanceDate</code>, <code>issuer</code>, <code>credentialSubject.id</code>, <code>credentialStatus</code>, <code>credentialStatus.id</code>.</li> </ul>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#credential-offer-exceptions","title":"Credential Offer Exceptions","text":"<p>To allow for validation of the <code>credential</code> according to the corresponding VC Data Model version, the <code>credential</code> in the offer MUST be conformant to the corresponding VC Data Model version, except for the exceptions listed below. This still allows the credential to be validated, knowing which deviations are possible.</p> <p>The list of exception is as follows:</p> <ul> <li><code>issuanceDate</code> (v1.1) or <code>validFrom</code> (v2.0) can be omitted, or set to a placeholder value.</li> <li><code>issuer</code> (or <code>issuer.id</code> if issuer is an object) can be omitted</li> <li><code>credentialSubject.id</code> can be omitted</li> <li><code>credentialStatus</code></li> <li>Either the whole <code>credentialStatus</code> can be omitted</li> <li>OR the <code>credentialStatus.type</code> can be present, but other required fields that are dynamic can be omitted (such as the <code>statusListIndex</code> and <code>statusListCredential</code> in case of Bitstring Status List)</li> </ul>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#credential-request-attachment-format","title":"Credential Request Attachment Format","text":"<p>Format identifier: <code>didcomm/w3c-di-vc-request@v0.1</code></p> <p>This format is used to request a verifiable credential. The JSON structure might look like this:</p> <pre><code>{\n  \"data_model_version\": \"2.0\",\n  \"binding_proof\": {\n    \"anoncreds_link_secret\": {\n      \"entropy\": \"&lt;random-entropy&gt;\",\n      \"cred_def_id\": \"did:key:z6MkwXG2WjeQnNxSoynSGYU8V9j3QzP3JSqhdmkHc6SaVWoT/credential-definition\",\n      \"blinded_ms\": {},\n      \"blinded_ms_corectness_proof\": {},\n      \"nonce\": \"&lt;random-nonce&gt;\"\n    },\n    \"didcomm_signed_attachment\": {\n      \"attachment_id\": \"&lt;@id of the attachment&gt;\"\n    }\n  }\n}\n</code></pre> <ul> <li><code>data_model_version</code> - Required. The data model version of the credential to be issued. The value MUST be a valid data model version and match one of the values from the <code>data_model_versions_supported</code> offer.</li> <li><code>binding_proof</code> - Required if <code>binding_required</code> is <code>true</code> in the offer. Object containing key-value pairs of proofs for the binding to the holder. The keys MUST match keys of the <code>binding_method</code> object from the offer. See Binding Methods for a registry of default binding methods supported as part of this RFC.</li> </ul>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#credential-attachment-format","title":"Credential Attachment Format","text":"<p>Format identifier: <code>didcomm/w3c-di-vc@v0.1</code></p> <p>This format is used to transmit a verifiable credential. The JSON structure might look like this:</p> <pre><code>{\n  \"credential\": {\n    // vc with proof object or array\n  }\n}\n</code></pre> <ul> <li><code>credential</code> - The signed credential. MUST be a valid verifiable credential object with one or more proofs and MUST conform to VC Data Model version as defined in the <code>data_model_version</code> of the request.</li> </ul> <p>It is up to the issuer to the pick an appropriate cryptographic suite to sign the credential. The issuer may use the cryptographic binding material provided by the holder to select the cryptographic suite. For example, when the <code>anoncreds_link_secret</code> binding method is used, the issuer should use an <code>DataIntegrityProof</code> with the <code>anoncredsvc-2023</code> cryptographic suite. When a holder provides a signed attachment as part of the binding proof using the <code>EdDSA</code> JWA alg, the issuer could use a <code>DateIntegrityProof</code> with the <code>eddsa-rdfc-2022</code> cryptographic suite. However, it is not required for the cryptographic suite used for the signature on the credential to be in any way related to the cryptographic suite used for the binding proof, unless the binding method explicitly requires this (for example the <code>anoncreds_link_secret</code> binding method).</p> <p>A complete <code>issue-credential</code> message from the Issue Credential protocol 2.0 might look like this:</p> <pre><code>{\n  \"@id\": \"284d3996-ba85-45d9-964b-9fd5805517b6\",\n  \"@type\": \"https://didcomm.org/issue-credential/2.0/issue-credential\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"5b38af88-d36f-4f77-bb7a-2f04ab806eb8\",\n      \"format\": \"didcomm/w3c-di-vc@v0.1\"\n    }\n  ],\n  \"credentials~attach\": [\n    {\n      \"@id\": \"5b38af88-d36f-4f77-bb7a-2f04ab806eb8\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"ewogICAgICAgICAgIkBjb250ZXogWwogICAgICAg...(clipped)...RNVmR0SXFXZhWXgySkJBIgAgfQogICAgICAgIH0=\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#binding-methods","title":"Binding Methods","text":"<p>The attachment format supports different methods to bind the credential to the receiver of the credential. In the offer message the issuer can indicate which binding methods are supported in the <code>binding_methods</code> object. Each key represents the id of the supported binding method.</p> <p>This section defines a set of binding methods supported by this attachment format, but other binding methods may be used. Based on the binding method, the request needs to include a <code>binding_proof</code> object where the key matches the key of the binding method from the offer.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#anoncreds-link-secret","title":"AnonCreds Link Secret","text":"<p>Identifier: <code>anoncreds_link_secret</code></p> <p>This binding method is intended to be used in combination with a credential containing an AnonCreds proof.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#binding-method-in-offer","title":"Binding Method in Offer","text":"<p>The structure of the binding method in the offer MUST match the structure of the Credential Offer as defiend in the AonCreds specification, with the exclusion of the <code>schema_id</code> key.</p> <pre><code>{\n  \"nonce\": \"1234\",\n  \"cred_def_id\": \"did:key:z6MkwXG2WjeQnNxSoynSGYU8V9j3QzP3JSqhdmkHc6SaVWoT/credential-definition\",\n  \"key_correctness_proof\": {\n    /* key correctness proof object */\n  }\n}\n</code></pre>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#binding-proof-in-request","title":"Binding Proof in Request","text":"<p>The structure of the binding proof in the request MUST match the structure of the Credential Request as defined in the AnonCreds specification.</p> <pre><code>{\n  \"anoncreds_link_secret\": {\n    \"entropy\": \"&lt;random-entropy&gt;\",\n    \"blinded_ms\": {\n      /* blinded ms object */\n    },\n    \"blinded_ms_corectness_proof\": {\n      /* blinded ms correctness proof object */\n    },\n    \"nonce\": \"&lt;random-nonce&gt;\"\n  }\n}\n</code></pre>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#binding-in-credential","title":"Binding in Credential","text":"<p>The issued credential should be bound to the holder by including the blinded link secret in the credential as defined in the Issue Credential section of the AnonCreds specification. Credential bound using the AnonCreds link secret binding method MUST contain an proof with <code>proof.type</code> value of <code>DataIntegrityProof</code> and <code>cryptosuite</code> value of <code>anoncredsvc-2023</code>, and conform to the AnonCreds W3C Verifiable Credential Representation.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#didcomm-signed-attachment","title":"DIDComm Signed Attachment","text":"<p>Identifier: <code>didcomm_signed_attachment</code></p> <p>This binding method leverages DIDComm signed attachments to bind a credential to a specific key and/or identifier.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#binding-method-in-offer_1","title":"Binding Method in Offer","text":"<pre><code>{\n  \"didcomm_signed_attachment\": {\n    \"algs_supported\": [\"EdDSA\"],\n    \"did_methods_supported\": [\"key\"],\n    \"nonce\": \"b19439b0-4dc9-4c28-b796-99d17034fb5c\"\n  }\n}\n</code></pre> <ul> <li><code>algs_supported</code> - Required. List of strings indicating the Json Web Algorithms supported by the issuer for verifying the signed attachment. The list MUST contain at least one value. The values MUST be a valid algorithm identifier as defined in the JSON Web Signature and Encryption Algorithms registry.</li> <li><code>did_methods_supported</code> - Required. List of strings indicating which did methods are supported by the issuer for binding the credential to the holder. The list MUST contain at least one value. Values should ONLY include the method identifier of the did method. Examples values include <code>key</code> or <code>web</code>.</li> <li><code>nonce</code> - Required. Nonce to be used in the request to prevent replay attacks of the signed attachment.</li> </ul>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#binding-proof-in-request_1","title":"Binding Proof in Request","text":"<p>The binding proof in the request points to an appended attachment containing the signed attachment.</p> <pre><code>{\n  \"didcomm_signed_attachment\": {\n    \"attachment_id\": \"&lt;@id of the attachment&gt;\"\n  }\n}\n</code></pre> <ul> <li><code>attachment_id</code> - The id of the appended attachment included in the request message that contains the signed attachment.</li> </ul>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#signed-attachment-content","title":"Signed Attachment Content","text":"<p>The attachment MUST be signed by including a signature in the <code>jws</code> field of the attachment. The data MUST be a JSON document encoded in the <code>base64</code> field of the attachment. The structure of the signed attachment is described below.</p> <p>JWS Payload</p> <pre><code>{\n  \"nonce\": \"&lt;request_nonce&gt;\",\n}\n</code></pre> <ul> <li><code>nonce</code> - Required. The <code>nonce</code> from the <code>didcomm_signed_attachment</code> object within <code>binding_method</code> from the credential offer</li> </ul> <p>Protected Header</p> <pre><code>{\n  \"alg\": \"EdDSA\",\n  \"kid\": \"did:key:z6MkkwiqX7BvkBbi37aNx2vJkCEYSKgHd2Jcgh4AUhi4YY1u#z6MkkwiqX7BvkBbi37aNx2vJkCEYSKgHd2Jcgh4AUhi4YY1u\"\n}\n</code></pre> <ul> <li><code>alg</code>: REQUIRED. A digital signature algorithm identifier such as per IANA \"JSON Web Signature and Encryption Algorithms\" registry. MUST NOT be none or an identifier for a symmetric algorithm (MAC). MUST match one of the <code>algs_supported</code> entries from the offer <code>binding_method</code> object.</li> <li><code>kid</code>: REQUIRED. JOSE Header containing the DID URL pointing to a specific key in a did document. The did method of the DID URL MUST match with one of the <code>did_methods_supported</code> from the offer <code>binding_method</code> object.</li> </ul> <p>A signed binding request attachment appended to a request message might look like this:</p> <pre><code>{\n  \"@id\": \"284d3996-ba85-45d9-964b-9fd5805517b6\",\n  \"@type\": \"https://didcomm.org/issue-credential/2.0/request-credential\",\n  \"comment\": \"&lt;some comment&gt;\",\n  \"formats\": [\n    {\n      \"attach_id\": \"5b38af88-d36f-4f77-bb7a-2f04ab806eb8\",\n      \"format\": \"didcomm/w3c-di-vc-request@v0.1\"\n    }\n  ],\n  \"~attach\": [\n    {\n      \"@id\": \"123\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"&lt;base64-encoded-json-attachment-content&gt;\",\n        \"jws\": {\n          \"protected\": \"eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)\",\n          \"signature\": \"3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)\"\n        }\n      }\n    }\n  ],\n  \"credentials~attach\": [\n    {\n      \"@id\": \"5b38af88-d36f-4f77-bb7a-2f04ab806eb8\",\n      \"mime-type\": \"application/json\",\n      \"data\": {\n        \"base64\": \"ewogICAgICAgICAgIkBjb250ZXogWwogICAgICAg...(clipped)...RNVmR0SXFXZhWXgySkJBIgAgfQogICAgICAgIH0=\"\n      }\n    }\n  ]\n}\n</code></pre>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#binding-in-credential_1","title":"Binding in Credential","text":"<p>The issued credential should be bound to the holder by including the did in the credential as <code>credentialSubject.id</code> or <code>holder</code>.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#drawbacks","title":"Drawbacks","text":"<ul> <li>While it has a similar setup and structure compared to OpenID for Verifiable Credential Issuance, this attachment format only focuses on issuance of W3C Verifiable Credentials. Therefore another (but probably quite similar) attachment format needs to be defined to support issuance of non-W3C VCs</li> <li>There is currently no way for an issuer or holder to indicate which cryptographic suites they support for the signature of the credential. Currently it's at the discretion of the issuer to decide which cryptographic suite to use. In a future (minor) version we can add an optional way for a) the issuer to indicate which cryptographic suites they support, and b) the holder to indicate which cryptographic suites they support.</li> <li>There is currently no attachment format defined for a credential proposal. This makes it impossible for a holder to initiate the issuance of a credential using this attachment format. In a future (minor) version the proposal attachment format can be added.</li> </ul>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>RFC 0593: JSON-LD Credential Attachment, W3C VC API allows issuance of credentials using only linked data signatures, while RFC 0592: Indy Attachment supports issuance of AnonCreds credentials. This attachment format aims to support issuance of both previous attachment formats (while for AnonCreds it now being in the W3C model), as well as supporting additional ../../features such as issuance W3C JWT VCs, credentials with multiple proofs, and cryptographic binding of the credential to the holder.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#prior-art","title":"Prior art","text":"<p>The attachment format in this RFC is heavily inspired by RFC 0593: JSON-LD Credential Attachment, W3C VC API and OpenID for Verifiable Credential Issuance.</p>"},{"location":"features/0809-w3c-data-integrity-credential-attachment/#unresolved-questions","title":"Unresolved questions","text":""},{"location":"features/0829-VDR-Proxy/","title":"0829: VDR Proxy","text":"<ul> <li>Authors: Stephen Curran (BC Gov)</li> <li>Status: PROPOSED</li> <li>Since: 2024-05-09</li> <li>Status Note: Proposed</li> <li>Supersedes: N/A</li> <li>Start Date: 2024-05-09</li> <li>Tags: feature, protocol</li> </ul>"},{"location":"features/0829-VDR-Proxy/#summary","title":"Summary","text":"<p>A VDR (verifiable data registry) is a place where DIDs and objects related to DIDs (such as Hyperledger AnonCreds objects) are stored such that they can be resolved. The VDR Proxy protocol defined by this RFC is a DIDComm protocol that can be used by a DIDComm agent to request another agent resolve VDR URIs (Uniform Resource Identifiers) and return the resolved objects to the requesting agent. The protocol is a simple client/server protocol, supporting the ability to request and receive back multiple resolutions in a single exchange.</p>"},{"location":"features/0829-VDR-Proxy/#motivation","title":"Motivation","text":"<p>There are several use cases that are driving the initial need for this protocol.</p>"},{"location":"features/0829-VDR-Proxy/#firewall-issues-for-agents-accessing-indy-networks","title":"Firewall Issues for Agents Accessing Indy Networks","text":"<p>Directly accessing an Indy network requires an Aries agent to use ZMQ which in turn uses an atypical set of IP ports (in the 9700 range). Since an Aries agent makes an outbound request to interact with the ledger, that is normally not a problem. However, some enterprises, and even some ISPs, prevent the use of \"non-standard\" ports, blocking them with at an outbound firewall. Such organizations only permit the outbound use of the HTTP/HTTPS ports of 80 and 443. When an Aries user, such as someone with a mobile wallet, is on a network that limits outbound port access they cannot access the Indy networks to retrieve ledger objects needed to process the credentials and presentations they are receiving/generating. When direct access to the ledger is blocked, an agent can detect the problem and fallback to use a configured VDR Proxy service using this protocol. The initial use is for a mobile agent to use its DIDComm mediator as a proxy, but the protocol is not restricted to that case.</p>"},{"location":"features/0829-VDR-Proxy/#fetching-revocation-data","title":"Fetching Revocation Data","text":"<p>Another use case for this protocol is when a holder needs verification data when preparing a verifiable presentation. Some VDRs, such as the did:web DID Method can be setup with the issuer hosting such data, especially the revocation-related data. When the holder is required to collect revocation data for preparing a verifiable presentation, as is the case with Hyperledger AnonCreds, we don't want the holder directly contacting the issuer to get the necessary data. That enables either tracking or the perception of tracking by the issuer, which is undesirable. By using the VDR Proxy protocol, the holder can have another party, such as the verifier, the holder's mediator, or another agent altogether, resolve the revocation data and provide it to the holder.</p>"},{"location":"features/0829-VDR-Proxy/#tutorial","title":"Tutorial","text":""},{"location":"features/0829-VDR-Proxy/#name-and-version","title":"Name and Version","text":"<p>This is the VDR Proxy protocol. It is uniquely identified by the URI:</p> <pre><code>\"https://didcomm.org/vdrproxy/1.0\"\n</code></pre>"},{"location":"features/0829-VDR-Proxy/#key-concepts","title":"Key Concepts","text":"<p>This RFC assumes that the reader is familiar with DID communication.</p> <p>The protocol consists of a DIDComm <code>request</code> message from a client carrying an array of URIs to be resolved by the proxy server, and a second message that carries the result of resolving those URIs back to the client. The intention is that the URIs refer to resolvable objects held in a VDR.</p> <p>The server may or may not be able to resolve the requested URI(s). For example, the server will be configured to resolve certain DID and AnonCreds methods (types of VDRs) and will only resolve URIs for those methods/VDRs.</p> <p>On receipt of a request, the server SHOULD attempt to resolve each URI passed, returning for each an array entry containing either the resolved content, encoded as a data URI, or an error status. A server MAY be configured to not to resolve some requested URIs, either because they can't or don't want to for some business reason. In such cases, the server SHOULD respond with an error code per unprocessed URI.  If the <code>request</code> itself is incorrectly structured, the server SHOULD send a [Problem Report] to the client.</p>"},{"location":"features/0829-VDR-Proxy/#role","title":"Role","text":"<p>There are two roles in the protocol <code>client</code> and <code>server</code>:</p> <ul> <li>The <code>client</code> initiates the protocol, sending a request message to the <code>server</code>.</li> <li>The <code>server</code> carries out the request however they see fit. The <code>server</code> SHOULD resolve the URIs. The <code>server</code> might be unable or unwilling to   resolve some or all of the URIs.</li> <li>The <code>server</code> returns the resolution objects in a message to the <code>client</code>.</li> </ul>"},{"location":"features/0829-VDR-Proxy/#states","title":"States","text":""},{"location":"features/0829-VDR-Proxy/#client-states","title":"Client States","text":"<p>The <code>client</code> agent goes through the following states:</p> <ul> <li>request-sent</li> <li>completed</li> </ul> <p>The state transition table for the <code>client</code> is:</p> State / Events Send Request Receive Response Start Transition to request-sent request-sent Transition to complete completed problem-report received Transition to abandoned abandoned"},{"location":"features/0829-VDR-Proxy/#server-states","title":"Server States","text":"<p>The <code>server</code> agent goes through the following states:</p> <ul> <li>request-received</li> <li>completed</li> </ul> <p>The state transition table for the <code>server</code> is:</p> State / Events Receive Request Send Response or Problem Report Start Transition to request-received request-received Transition to complete completed"},{"location":"features/0829-VDR-Proxy/#messages","title":"Messages","text":"<p>The following are the messages in the VDR Proxy protocol. The <code>response</code> message handles all completed responses, so the <code>ack</code> (RFC 0015 ACKs) message is NOT adopted by this protocol. The RFC 0035 Report Problem is adopted by this protocol in the event that a <code>request</code> is not recognizable as a VDR Proxy message and as such, a response message cannot be created. See the details below in the Problem Report Message section.</p>"},{"location":"features/0829-VDR-Proxy/#request-message","title":"Request Message","text":"<p>The <code>request</code> message is sent by the <code>client</code> to initiate the protocol. The message contains the array of URIs for the <code>server</code> to resolve and send the resolved objects back to the <code>client</code>. It is assumed the <code>client</code> knows what types of URIs the <code>server</code> is prepared to resolve. The <code>server</code> returns an error status for any URIs it does not know how to resolve. </p> <p>The <code>request</code> message uses the following format:</p> <pre><code>  {\n    \"@type\": \"https://didcomm.org/vdrproxy/1.0/request\",\n    \"@id\": \"2a0ec6db-471d-42ed-84ee-f9544db9da4b\",\n    \"request\" : [\n      {\n        \"id\": \"&lt;id&gt;\",\n        \"uri\" : \"&lt;uri&gt;\"\n      }\n    ]\n  }\n</code></pre> <p>The items in the message are as follows:</p> <ul> <li><code>@type</code> -- required, must be as above</li> <li><code>@id</code> -- required, must be as defined in [RFC 0005 DIDComm]</li> <li><code>request</code> -- required, an item containing an array of URIs to be resolved.</li> <li><code>request</code> MUST be an array of requests.</li> <li>Each request item MUST have an <code>id</code>, that is unique with the <code>request</code> item, typically the index of the array (\"1\", \"2\", \"3\", etc.).</li> <li>Each request items MUST have a URI to be resolved.</li> </ul> <p>On receipt, the server verifies the format of the request, and iterates through the <code>request</code> array, resolving (or not) each URI and preparing the response message.</p>"},{"location":"features/0829-VDR-Proxy/#response-message","title":"Response Message","text":"<p>A <code>response</code> message is sent by the <code>server</code> to following the processing of the request to convey the output of the processing to the <code>client</code>.</p> <p>If the <code>request</code> content is unrecognizable, the <code>server</code> SHOULD send a RFC 0035 Report Problem message to the <code>client</code>.</p> <pre><code>  {\n    \"@type\": \"https://didcomm.org/vdrproxy/1.0/response\",\n    \"@id\": \"63d6f6cf-b723-4eaf-874b-ae13f3e3e5c5\",\n    \"response\": [\n      {\n        \"id\": \"&lt;id&gt;\",\n        \"status\" : \"&lt;status code&gt;\",\n        \"result\" : \"&lt;data uri&gt;\"\n      }\n    ]\n  }\n</code></pre> <p>The items in the message are as follows:</p> <ul> <li><code>@type</code> -- required, must be as above</li> <li><code>@id</code> -- required, must be as defined in [RFC 0005 DIDComm]</li> <li><code>response</code> -- required, an item containing an array of resolution results.</li> <li><code>response</code> MUST be an array of resolution results the same length and with the same <code>id</code>s as the request.</li> <li><code>id</code> -- the <code>id</code> from the <code>request</code> message from the corresponding <code>request</code> item.</li> <li><code>status</code> -- either a <code>501</code> (meaning \"Service Unavailable\") if the server refuses to <code>resolve</code> the URI, or the status code resulting from attempting to resolve the URI.</li> <li><code>result</code> -- optional, included only if the resolution was attempted, and the resolution returned a result. If included, the value MUST be the result of the resolution in data URI format. For example, if the result of the resolution is a JSON object, the data URL would likely look like this: <code>data:application/json;base64,&lt;base64 encoded JSON data&gt;</code>.</li> </ul> <p>As with all DIDComm messages that are not the first in a protocol instance, a <code>~thread</code> decorator MUST be included in the <code>response</code> message.</p> <p>Caching of resolved objects may be done by both the client and the server as they see fit to improve the performance of using (or not needing to use) a VDR Proxy. Caching strategies depend by the proxied VDR and are out of scope of this protocol.</p>"},{"location":"features/0829-VDR-Proxy/#problem-report-message","title":"Problem Report Message","text":"<p>A RFC 0035 Report Problem message SHOULD be sent by the <code>server</code> instead of a <code>response</code> message only if the <code>request</code> is not an array of URIs. All resolution errors MUST be provided to the <code>client</code> by the <code>server</code> via the <code>response</code> message, not a <code>problem-report</code>. The <code>client</code> MUST NOT respond to a <code>response</code> message, even if the <code>response</code> message is not a valid response.  This is because once the <code>server</code> sends the <code>response</code>, the protocol is in the <code>completed</code> state (from the <code>server</code>'s perspective) and so is subject to deletion. As such, a follow up <code>problem-report</code> message would have an invalid <code>thid</code> (thread ID) and (at best) be thrown away by the <code>server</code>.</p>"},{"location":"features/0829-VDR-Proxy/#constraints","title":"Constraints","text":"<p>The primary constraint with this protocol is that the two parties using the protocol must understand what types of VDRs the server is willing to proxy.</p>"},{"location":"features/0829-VDR-Proxy/#reference","title":"Reference","text":"<p>None.</p>"},{"location":"features/0829-VDR-Proxy/#drawbacks","title":"Drawbacks","text":"<p>None defined.</p>"},{"location":"features/0829-VDR-Proxy/#rationale-and-alternatives","title":"Rationale and alternatives","text":"<p>None defined.</p>"},{"location":"features/0829-VDR-Proxy/#prior-art","title":"Prior art","text":"<p>This protocol borrows much from the [RFC 0809 DIDComm Remote Producer Call], including the request/response handling, arrays of requests, and the Problem Report handling.</p>"},{"location":"features/0829-VDR-Proxy/#unresolved-questions","title":"Unresolved questions","text":"<p>What status should be returned from the server if it refuses to resolve a URI? The chosen status is listed. It would be helpful if the client could differentiate between a status returned directly from the server or one proxied from the VDR.</p>"},{"location":"features/0829-VDR-Proxy/#implementations","title":"Implementations","text":"<p>The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the \"Name\" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.</p> <p>Implementation Notes may need to include a link to test results.</p> Name / Link Implementation Notes"}]}
\ No newline at end of file
diff --git a/main/sitemap.xml.gz b/main/sitemap.xml.gz
index f15bab117..dd12af1f0 100644
Binary files a/main/sitemap.xml.gz and b/main/sitemap.xml.gz differ
diff --git a/main/tags/index.html b/main/tags/index.html
index 303942a3f..f385a006f 100644
--- a/main/tags/index.html
+++ b/main/tags/index.html
@@ -12,7 +12,7 @@
       
       
       <link rel="icon" href="https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/collateral/favicon.ico">
-      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.39">
+      <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.5.49">
     
     
       
@@ -20,7 +20,7 @@
       
     
     
-      <link rel="stylesheet" href="../assets/stylesheets/main.8c3ca2c6.min.css">
+      <link rel="stylesheet" href="../assets/stylesheets/main.6f8fc17f.min.css">
       
         
         <link rel="stylesheet" href="../assets/stylesheets/palette.06af60db.min.css">
@@ -189,7 +189,7 @@
         <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -407,7 +407,7 @@
       <a href="https://github.com/hyperledger/aries-rfcs" title="Go to repository" class="md-source" data-md-component="source">
   <div class="md-source__icon md-icon">
     
-    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.6.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.7.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2024 Fonticons, Inc.--><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6m-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3m44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9M244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8M97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1m-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7m32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1m-11.4-14.7c-1.6 1-1.6 3.6 0 5.9s4.3 3.3 5.6 2.3c1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2"/></svg>
   </div>
   <div class="md-source__repository">
     hyperledger/aries-rfcs
@@ -751,7 +751,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0003 Protocols
+    0003 Protocols
   </span>
   
 
@@ -772,7 +772,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0004 Agents
+    0004 Agents
   </span>
   
 
@@ -793,7 +793,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0005 DID Communication
+    0005 DID Communication
   </span>
   
 
@@ -814,7 +814,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0008 Message ID and Threading
+    0008 Message ID and Threading
   </span>
   
 
@@ -835,7 +835,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0011 Decorators
+    0011 Decorators
   </span>
   
 
@@ -856,7 +856,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0015 ACKs
+    0015 ACKs
   </span>
   
 
@@ -877,7 +877,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0017 Attachments
+    0017 Attachments
   </span>
   
 
@@ -898,7 +898,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0019 Encryption Envelope
+    0019 Encryption Envelope
   </span>
   
 
@@ -919,7 +919,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0020 Message Types
+    0020 Message Types
   </span>
   
 
@@ -940,7 +940,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0023 DID Exchange Protocol 1.0
+    0023 DID Exchange Protocol 1.0
   </span>
   
 
@@ -961,7 +961,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0025 DIDComm Transports
+    0025 DIDComm Transports
   </span>
   
 
@@ -982,7 +982,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0035 Report Problem Protocol 1.0
+    0035 Report Problem Protocol 1.0
   </span>
   
 
@@ -1003,7 +1003,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0044 DIDComm File and MIME Types
+    0044 DIDComm File and MIME Types
   </span>
   
 
@@ -1024,7 +1024,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0046 Mediators and Relays
+    0046 Mediators and Relays
   </span>
   
 
@@ -1045,7 +1045,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0047 JSON-LD Compatibility
+    0047 JSON-LD Compatibility
   </span>
   
 
@@ -1066,7 +1066,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0048 Trust Ping Protocol 1.0
+    0048 Trust Ping Protocol 1.0
   </span>
   
 
@@ -1087,7 +1087,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0050 Wallets
+    0050 Wallets
   </span>
   
 
@@ -1108,7 +1108,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0092 Transports Return Route
+    0092 Transports Return Route
   </span>
   
 
@@ -1129,7 +1129,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0094 Cross-Domain Messaging
+    0094 Cross-Domain Messaging
   </span>
   
 
@@ -1150,7 +1150,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0095 Basic Message Protocol 1.0
+    0095 Basic Message Protocol 1.0
   </span>
   
 
@@ -1171,7 +1171,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0183 Revocation Notification 1.0
+    0183 Revocation Notification 1.0
   </span>
   
 
@@ -1213,7 +1213,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0360 did:key Usage
+    0360 did:key Usage
   </span>
   
 
@@ -1234,7 +1234,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0434 Out-of-Band Protocol 1.1
+    0434 Out-of-Band Protocol 1.1
   </span>
   
 
@@ -1276,7 +1276,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0453 Issue Credential Protocol 2.0
+    0453 Issue Credential Protocol 2.0
   </span>
   
 
@@ -1297,7 +1297,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0454 Present Proof Protocol 2.0
+    0454 Present Proof Protocol 2.0
   </span>
   
 
@@ -1318,7 +1318,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0510 Presentation-Exchange Attachment format for requesting and presenting proofs
+    0510 Presentation-Exchange Attachment format for requesting and presenting proofs
   </span>
   
 
@@ -1360,7 +1360,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0557 Discover Features Protocol v2.x
+    0557 Discover Features Protocol v2.x
   </span>
   
 
@@ -1381,7 +1381,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0592 Indy Attachment Formats for Requesting and Presenting Credentials
+    0592 Indy Attachment Formats for Requesting and Presenting Credentials
   </span>
   
 
@@ -1402,7 +1402,7 @@
         
   
   <span class="md-ellipsis">
-    Aries RFC 0593 JSON-LD Credential Attachment format for requesting and issuing credentials
+    0593 JSON-LD Credential Attachment format for requesting and issuing credentials
   </span>
   
 
@@ -3307,6 +3307,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0535-email-access-governance-framework/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0535 Email Access Governance Framework
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0559-pppu/" class="md-nav__link">
         
@@ -3475,6 +3496,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../features/0745-push-notifications-expo/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0745 Push Notifications Expo Protocol 1.0
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0757-push-notification/" class="md-nav__link">
         
@@ -3517,6 +3559,27 @@
   
   
   
+    <li class="md-nav__item">
+      <a href="../concepts/0781-trust-input-protocol/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0781 Trust Input Protocol
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
     <li class="md-nav__item">
       <a href="../concepts/0799-long-term-support/" class="md-nav__link">
         
@@ -3532,6 +3595,48 @@
 
               
             
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../concepts/0812-compression-dictionary/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0812 Compressing DIDComm messages using dictionaries
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
+              
+                
+  
+  
+  
+  
+    <li class="md-nav__item">
+      <a href="../features/0829-VDR-Proxy/" class="md-nav__link">
+        
+  
+  <span class="md-ellipsis">
+    0829 VDR Proxy
+  </span>
+  
+
+      </a>
+    </li>
+  
+
+              
+            
           </ul>
         </nav>
       
@@ -4542,7 +4647,7 @@ <h3 id="test-anomaly"><code>test-anomaly</code><a class="headerlink" href="#test
     <script id="__config" type="application/json">{"base": "..", "features": ["content.code.copy", "navigation.expand", "navigation.footer", "navigation.instant", "navigation.tabs", "navigation.tabs.sticky", "navigation.top", "navigation.tracking", "toc.follow"], "search": "../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script>
     
     
-      <script src="../assets/javascripts/bundle.525ec568.min.js"></script>
+      <script src="../assets/javascripts/bundle.88dd0f4e.min.js"></script>
       
     
   </body>